From patchwork Wed May 31 14:32:13 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: 100788 Delivered-To: patch@linaro.org Received: by 10.140.96.100 with SMTP id j91csp353093qge; Wed, 31 May 2017 07:34:14 -0700 (PDT) X-Received: by 10.98.200.23 with SMTP id z23mr30956220pff.18.1496241253940; Wed, 31 May 2017 07:34:13 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1496241253; cv=none; d=google.com; s=arc-20160816; b=NBk5yPWqR9M0XMQGizi+/cPPH+PTg6Ban7kvHotlzbPMfaI8sCVW/RqE66WRQsqEVA rR+I7IH3/FXNebrqySi0Ur/faPtIO/CStUmIjdQpdP27WXb2ZTfrgT2IK6nBmhneZqP8 LXuiRJJKomrAW+ISjf8ztLQTXyOYYwm545A6FiIcqxolIE3jjJplsBdWpN/ETcD49T9m E9EgcdQWLn5hG/O4J/1tWteFzgXYmLwy3WvzdCOIKK8TUcSAUxWTY3zyJQSebfJbac7T wYEoq9Zz8P4fErdJeuKTXkUVGZJJpJzWvl94FVemFn9niEZyWeJLXI8gXrs01qKAJ45c IrdA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:arc-authentication-results; bh=psViun5Km+akRZ8gyOyfi4NXuf8LTnu5Z7H6Xjzv6UE=; b=rcrC3qQ5am4TQ7SuKbeYqS1P2TrTmX8kCuK+FDSFUKDwBUgHQGsUW/kJkl7uhXI53A Kvc1V2NXWLLQawq0zXwJoL0AcxeZArWCD27Ndpght0YGM60j3dlOG2Cu65P+p+1cq457 r3HLrOCuvPYU6SFfwPKKqSqbDETLX4rcloCTfqU17ftEnlUwPWKCh6WvDqFl/V0ehPPx KoEfXH28uFNv0n6SY+FyWlm9bLquy1pK9q2kJ91lTzt1xznbi35IlEheUwTfV/5Bb/ah FZANKuJeDmKhCrpIc8fEy/zLwyla68gXJSzJsOrvgghzxxlZBPVUUHj7Izpj35RQD/A2 pdhg== 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 f64si16579419pfg.362.2017.05.31.07.34.13; Wed, 31 May 2017 07:34:13 -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 S1751067AbdEaOeM (ORCPT + 8 others); Wed, 31 May 2017 10:34:12 -0400 Received: from szxga03-in.huawei.com ([45.249.212.189]:6929 "EHLO szxga03-in.huawei.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751011AbdEaOeM (ORCPT ); Wed, 31 May 2017 10:34:12 -0400 Received: from 172.30.72.54 (EHLO dggeml405-hub.china.huawei.com) ([172.30.72.54]) by dggrg03-dlp.huawei.com (MOS 4.4.6-GA FastPath queued) with ESMTP id AOP20893; Wed, 31 May 2017 22:34:05 +0800 (CST) Received: from S00345302A-PC.china.huawei.com (10.203.177.212) by dggeml405-hub.china.huawei.com (10.3.17.49) with Microsoft SMTP Server id 14.3.301.0; Wed, 31 May 2017 22:33:55 +0800 From: shameer To: , , , , , CC: , , , , , , , , , shameer Subject: [RFCv2 2/2] iommu/arm-smmu-v3:Enable ACPI based HiSilicon erratum 161010801 Date: Wed, 31 May 2017 15:32:13 +0100 Message-ID: <20170531143213.82100-3-shameerali.kolothum.thodi@huawei.com> X-Mailer: git-send-email 2.12.0.windows.1 In-Reply-To: <20170531143213.82100-1-shameerali.kolothum.thodi@huawei.com> References: <20170531143213.82100-1-shameerali.kolothum.thodi@huawei.com> MIME-Version: 1.0 X-Originating-IP: [10.203.177.212] X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020201.592ED45E.001A, 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: 3353111ed35acc79e0a3f0c2ea9bec25 Sender: linux-acpi-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-acpi@vger.kernel.org The HiSilicon erratum 161010801 describes the limitation of HiSilicon platforms Hip06/Hip07 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 allocations. The HW ITS address region associated with the dev is retrieved using a new helper function added in the IORT code. Signed-off-by: shameer --- drivers/iommu/arm-smmu-v3.c | 49 ++++++++++++++++++++++++++++++++++++++++++--- 1 file changed, 46 insertions(+), 3 deletions(-) -- 1.9.1 -- 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 diff --git a/drivers/iommu/arm-smmu-v3.c b/drivers/iommu/arm-smmu-v3.c index abe4b88..3767526 100644 --- a/drivers/iommu/arm-smmu-v3.c +++ b/drivers/iommu/arm-smmu-v3.c @@ -597,6 +597,7 @@ struct arm_smmu_device { u32 features; #define ARM_SMMU_OPT_SKIP_PREFETCH (1 << 0) +#define ARM_SMMU_OPT_RESV_HW_MSI (1 << 1) u32 options; struct arm_smmu_cmdq cmdq; @@ -1755,6 +1756,38 @@ static bool arm_smmu_sid_in_range(struct arm_smmu_device *smmu, u32 sid) static struct iommu_ops arm_smmu_ops; +#ifdef CONFIG_ACPI +static struct iommu_resv_region *arm_smmu_acpi_alloc_hw_msi(struct device *dev) +{ + struct iommu_resv_region *region; + struct irq_domain *irq_dom; + int prot = IOMMU_WRITE | IOMMU_NOEXEC | IOMMU_MMIO; + u64 base; + + irq_dom = pci_msi_get_device_domain(to_pci_dev(dev)); + if (irq_dom) { + int ret; + u32 rid; + + rid = pci_msi_domain_get_msi_rid(irq_dom, to_pci_dev(dev)); + ret = iort_dev_find_its_base(dev, rid, 0, &base); + if (!ret) { + dev_info(dev, "SMMUv3:HW MSI resv addr 0x%pa\n", &base); + region = iommu_alloc_resv_region(base, SZ_128K, + prot, IOMMU_RESV_MSI); + return region; + } + } + + return NULL; +} +#else +static struct iommu_resv_region *arm_smmu_acpi_alloc_hw_msi(struct device *dev) +{ + return NULL; +} +#endif + static int arm_smmu_add_device(struct device *dev) { int i, ret; @@ -1903,11 +1936,20 @@ static int arm_smmu_of_xlate(struct device *dev, struct of_phandle_args *args) static void arm_smmu_get_resv_regions(struct device *dev, struct list_head *head) { - struct iommu_resv_region *region; + struct iommu_fwspec *fwspec = dev->iommu_fwspec; + struct iommu_resv_region *region = NULL; int prot = IOMMU_WRITE | IOMMU_NOEXEC | IOMMU_MMIO; + struct arm_smmu_device *smmu; + + smmu = arm_smmu_get_by_fwnode(fwspec->iommu_fwnode); - region = iommu_alloc_resv_region(MSI_IOVA_BASE, MSI_IOVA_LENGTH, - prot, IOMMU_RESV_SW_MSI); + if (smmu && (smmu->options & ARM_SMMU_OPT_RESV_HW_MSI) && + dev_is_pci(dev)) + region = arm_smmu_acpi_alloc_hw_msi(dev); + + if (!region) + region = iommu_alloc_resv_region(MSI_IOVA_BASE, MSI_IOVA_LENGTH, + prot, IOMMU_RESV_SW_MSI); if (!region) return; @@ -2611,6 +2653,7 @@ static void parse_driver_acpi_options(struct acpi_iort_smmu_v3 *iort_smmu, switch (iort_smmu->model) { case ACPI_IORT_SMMU_HISILICON_HI161X: smmu->options |= ARM_SMMU_OPT_SKIP_PREFETCH; + smmu->options |= ARM_SMMU_OPT_RESV_HW_MSI; break; default: break;