From patchwork Sat May 13 09:47:24 2017 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Shameerali Kolothum Thodi X-Patchwork-Id: 99743 Delivered-To: patch@linaro.org Received: by 10.140.96.100 with SMTP id j91csp700136qge; Sat, 13 May 2017 02:52:06 -0700 (PDT) X-Received: by 10.98.105.132 with SMTP id e126mr8795126pfc.201.1494669126006; Sat, 13 May 2017 02:52:06 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1494669126; cv=none; d=google.com; s=arc-20160816; b=o5AFiPR0CvXN6S7xBZ5GeX5qoi8iWpY88tEPT0hgVY64Vgyp38I1qIoy7Na6pcPC6U rx+Jy4gqff+A7Cus0tcQ8UJHJVIgP7vSplBOTTtHmaaXzpN6KiaXna0eJzUK/oRvjHVo Bc5PUDjKu2JdsJqs7kuH/3/gy6tatepcEhC1Wr31OPoBRp87/dBLebolU/N2xuL5PoTD Q9Q/xkZOe+iXeo5mRjYw0iXk13+CMM+lEOPFVZ+TF88FV7lw5Oj9bouI/H7yIlwX4ysU EybG3UdkplMLWkguhbRt8utW2uAVKC96k1C704N6H0qo8ikLBvCi30qaUd+g9JxvHgrQ kAcw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:mime-version:message-id:date:subject:cc :to:from:arc-authentication-results; bh=vOcy9lhIDntESGgSkZfTrGBel8nNf9U4hTWN+e+y3Iw=; b=q2I7qpF6wBB7mLWcc/23mmjc1QmVl7IANXYmwu1gi1qvfF1IcogrPN2AADiSg9Ouqk 1p4/nGqNC4As4cDEwEsl74esI4FB7PjbOTPaXPAQl2DMEIimUqS1WmxPyGg1Eyp6+ca3 hJa9z4gNR8FiYPT4iT/2B84o6wOQK5F8XdhdCIOnq6lqK1KVVqlgfdL/sbrMWvl/gXGT TKHs+WLaQrNUhLf71XQFd5h0WvwzuY58xSI04VEWlJHZGLx+43V2sTf7j9yg5aveHpQN fPIUsdUL0NYpzSpfmOvM62POkPuXA5iCUiz5X1GZWSD/Q/svfGIZKeNHOswvMyu7Wz// Q0tA== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-acpi-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-acpi-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id s184si5787295pfb.65.2017.05.13.02.52.05; Sat, 13 May 2017 02:52:05 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-acpi-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-acpi-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-acpi-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752010AbdEMJwC (ORCPT + 8 others); Sat, 13 May 2017 05:52:02 -0400 Received: from szxga03-in.huawei.com ([45.249.212.189]:5945 "EHLO szxga03-in.huawei.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752028AbdEMJwB (ORCPT ); Sat, 13 May 2017 05:52:01 -0400 Received: from 172.30.72.54 (EHLO DGGEML404-HUB.china.huawei.com) ([172.30.72.54]) by dggrg03-dlp.huawei.com (MOS 4.4.6-GA FastPath queued) with ESMTP id ANM88402; Sat, 13 May 2017 17:51:24 +0800 (CST) Received: from S00345302A-PC.china.huawei.com (10.47.91.84) by DGGEML404-HUB.china.huawei.com (10.3.17.39) with Microsoft SMTP Server id 14.3.301.0; Sat, 13 May 2017 17:50:45 +0800 From: shameer To: , , , , CC: , , , , , , , , , , shameer Subject: [RFC v1 0/7] iommu/smmu-v3: Workaround for hisilicon 161010801 erratum(reserve HW MSI) Date: Sat, 13 May 2017 10:47:24 +0100 Message-ID: <20170513094731.3676-1-shameerali.kolothum.thodi@huawei.com> X-Mailer: git-send-email 2.12.0.windows.1 MIME-Version: 1.0 X-Originating-IP: [10.47.91.84] X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020204.5916D71C.00C9, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=0.0.0.0, so=2014-11-16 11:51:01, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: d69e5be4c5eef19af6d69514d076ef3a Sender: linux-acpi-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-acpi@vger.kernel.org On certain HiSilicon platforms (Hip06/Hip07) the GIC ITS and PCIe RC deviates from the standard implementation and this breaks PCIe MSI functionality when SMMU is enabled. The HiSilicon erratum 161010801 describes this limitation of certain HiSilicon platforms to support the SMMU mappings for MSI transactions. On these platforms GICv3 ITS translator is presented with the deviceID by extending the MSI payload data to 64 bits to include the deviceID. Hence, the PCIe controller on this platforms has to differentiate the MSI payload against other DMA payload and has to modify the MSI payload. This basically makes it difficult for this platforms to have a SMMU translation for MSI. This patch implements a ACPI table based quirk to reserve the hw msi regions in the smmu-v3 driver which means these address regions will not be translated and will be excluded from iova alloactions. To implement this quirk, the following changes are incorporated into smmu-v3: 1. Added a general erratum framework based on arm_arch_timer erratum framework. The intention is to have a common framework for dt and acpi based quirk implementations. 2. Replaced the existing hisilicon, broken_prefetch_cmd quirk using the new erratum framework (erratum-161010701) 3. Introduced a ACPI based quirk for erratum-161010801. 4. ACPI CSRT vendor specific blobs are used to pass the reserve address region info on these platforms. Also please note that this patchset is based on Robin's patch series "acpica: iort: Update SMMU models for IORT rev. C". https://lkml.org/lkml/2017/5/12/211 Thanks, Shameer shameer (7): iommu/arm-smmu-v3: Add erratum framework structures iommu/arm-smmu-v3: Add erratum framework functions iommu/arm-smmu-v3: Replace the device tree binding for hisilicon broken prefetch cmd with erratum id iommu/arm-smmu-v3: Enable HiSilicon erratum 161010701 iommu/arm-smmu-v3: Enable ACPI based HiSilicon erratum 161010701 iommu/arm-smmu-v3: Rearrange msi resv alloc functions iommu/arm-smmu-v3: Enable ACPI based HiSilicon erratum 161010801 .../devicetree/bindings/iommu/arm,smmu-v3.txt | 2 +- arch/arm64/Kconfig | 20 +- drivers/iommu/arm-smmu-v3.c | 225 ++++++++++++++++++--- 3 files changed, 218 insertions(+), 29 deletions(-) -- 2.5.0 -- To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html