From patchwork Wed Aug 9 10:53:36 2017 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Hanjun Guo X-Patchwork-Id: 109710 Delivered-To: patch@linaro.org Received: by 10.140.95.78 with SMTP id h72csp702130qge; Wed, 9 Aug 2017 04:00:58 -0700 (PDT) X-Received: by 10.99.62.75 with SMTP id l72mr7143196pga.316.1502276458453; Wed, 09 Aug 2017 04:00:58 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1502276458; cv=none; d=google.com; s=arc-20160816; b=sBrXw4xiH3m2TSi+ZBuHanbeKQ3cH5OECEwIKwUs3/P+gAYZKsPxZCJERF51k8PawN 3bhg28FZAS94oXr3l5br47UCllDYfClgLUlocYvDdvaYOEKn0ArpNjj2/4xxDPHUnfkj LnovW9MrkvinVAeZ6UWs5GeM/GNsxfHt2W7CaepiexCveHKQYBH+tY1p7XAFUZuE1xme +ujf2IjOO4JCDCXdh/xPPhkr25NgxmGuLT08o6ANduosPnrLqBp9lEvrOOQrTuMXCrAZ hOb32CGYk+O/RieBydYVAX7+TgZwEBsRPeMfyINVTG0Jhs6r3CJGmxZ/umWyV7fa2tvF L14w== 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=ERvE9xu9WnOP+zONJNuMRakbiNjZEMfQ85QQkhHlX7I=; b=luaPDo1f22rIc34NkEHE2G5/I0IbpvKILzafTU6b4NuyrBc4+Bu/EJO+K2zVNr585Z Ymldql1R3e06Qw4VpbW0iuTXoE/WbIwtJXNh53fs1PfBFmiTnMRu8typKaLM+mVA6Bmf EkheluNkekSDL+TPt+j79RmBUY/9oSs3/4H8BCDgKjyh49Gg5h7RS24xHza5FnDdDxCV RXnqv135ObMOf0e5UUT5k0TpJ/EWwSv/1b8kFYPeoxDA9Z3LOX8LoGugmzvxqMoiMtsr dPZPX6905lJU7wXwX6vU1LStCoSzjr7x1O5k1hRA5IpWr0BKwJEsOlK7kIVKfX7MwNOZ 6lsA== 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 p125si2216902pga.768.2017.08.09.04.00.58; Wed, 09 Aug 2017 04:00:58 -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 S1752023AbdHILA5 (ORCPT + 7 others); Wed, 9 Aug 2017 07:00:57 -0400 Received: from szxga04-in.huawei.com ([45.249.212.190]:3480 "EHLO szxga04-in.huawei.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751872AbdHILA5 (ORCPT ); Wed, 9 Aug 2017 07:00:57 -0400 Received: from 172.30.72.59 (EHLO DGGEMS411-HUB.china.huawei.com) ([172.30.72.59]) by dggrg04-dlp.huawei.com (MOS 4.4.6-GA FastPath queued) with ESMTP id DEU08682; Wed, 09 Aug 2017 19:00:42 +0800 (CST) Received: from linux-ibm.site (10.175.102.37) by DGGEMS411-HUB.china.huawei.com (10.3.19.211) with Microsoft SMTP Server id 14.3.301.0; Wed, 9 Aug 2017 19:00:33 +0800 From: Hanjun Guo To: Lorenzo Pieralisi CC: , , , Sinan Kaya , "Rafael J. Wysocki" , Marc Zyngier , Hanjun Guo Subject: [RFC PATCH 3/4] ACPI: IORT: Skip SMMUv3 device ID map for two steps mappings Date: Wed, 9 Aug 2017 18:53:36 +0800 Message-ID: <1502276017-63108-4-git-send-email-guohanjun@huawei.com> X-Mailer: git-send-email 1.7.12.4 In-Reply-To: <1502276017-63108-1-git-send-email-guohanjun@huawei.com> References: <1502276017-63108-1-git-send-email-guohanjun@huawei.com> MIME-Version: 1.0 X-Originating-IP: [10.175.102.37] X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020202.598AEB5B.0015, 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: a4fd5c54077771bfe64bcab8605a44cb Sender: linux-acpi-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-acpi@vger.kernel.org From: Hanjun Guo IORT revision C introduced SMMUv3 MSI support which adding a device ID mapping index in SMMUv3 sub table, to get the SMMUv3 device ID mapping for the output ID (dev ID for ITS) and the link to which ITS. So if a platform supports SMMUv3 MSI for control interrupt, there will be a additional single map entry under SMMU, this will not introduce any difference for devices just use one step map to get its output ID and parent (ITS or SMMU), such as PCI/NC/PMCG ---> ITS or PCI/NC ---> SMMU, but we need to do the spcial handling for two steps map case such as PCI/NC--->SMMUv3--->ITS. Take a PCI hostbridge for example, |----------------------| | Root Complex Node | |----------------------| | map entry[x] | |----------------------| | id value | | output_reference | |---|------------------| | | |----------------------| |-->| SMMUv3 | |----------------------| | SMMU dev ID | | mapping index 0 | |----------------------| | map entry[0] | |----------------------| | id value | | output_reference-----------> ITS 1 (SMMU MSI domain) |----------------------| | map entry[1] | |----------------------| | id value | | output_reference-----------> ITS 2 (PCI MSI domain) |----------------------| When the SMMU dev ID mapping index is 0, there is entry[0] to map to a ITS, we need to skip that map entry for PCI or NC (named component), or we may get the wrong ITS parent. For now we have two APIs for ID mapping, iort_node_map_id() and iort_node_map_platform_id(), and iort_node_map_id() is used for optional two steps mapping, so we just need to skip the map entry in iort_node_map_id() for non-SMMUv3 devices. Signed-off-by: Hanjun Guo --- drivers/acpi/arm64/iort.c | 37 ++++++++++++++++++++++++++++++++++++- 1 file changed, 36 insertions(+), 1 deletion(-) -- 1.7.12.4 -- 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 Signed-off-by: Hanjun Guo diff --git a/drivers/acpi/arm64/iort.c b/drivers/acpi/arm64/iort.c index 32bd4a4..9439f02 100644 --- a/drivers/acpi/arm64/iort.c +++ b/drivers/acpi/arm64/iort.c @@ -366,6 +366,28 @@ struct acpi_iort_node *iort_node_get_id(struct acpi_iort_node *node, return NULL; } +static int iort_get_smmu_v3_id_mapping_index(struct acpi_iort_node *node, + u32 *index) +{ + struct acpi_iort_smmu_v3 *smmu; + + /* + * SMMUv3 dev ID mapping index was introdueced in revision 1 + * table, not avaible in revision 0 + */ + if (node->revision < 1) + return -EINVAL; + + smmu = (struct acpi_iort_smmu_v3 *)node->node_data; + /* if any of the gsi for control interrupts is not 0, ignore the MSI */ + if (smmu->event_gsiv || smmu->pri_gsiv || smmu->gerr_gsiv + || smmu->sync_gsiv) + return -EINVAL; + + *index = smmu->id_mapping_index; + return 0; +} + static struct acpi_iort_node *iort_node_map_id(struct acpi_iort_node *node, u32 id_in, u32 *id_out, u8 type_mask) @@ -375,7 +397,9 @@ static struct acpi_iort_node *iort_node_map_id(struct acpi_iort_node *node, /* Parse the ID mapping tree to find specified node type */ while (node) { struct acpi_iort_id_mapping *map; - int i; + int i, ret = -EINVAL; + /* big enough for an invalid id index in practical */ + u32 index = U32_MAX; if (IORT_TYPE_MASK(node->type) & type_mask) { if (id_out) @@ -396,8 +420,19 @@ static struct acpi_iort_node *iort_node_map_id(struct acpi_iort_node *node, goto fail_map; } + /* + * we need to get SMMUv3 dev ID mapping index and skip its + * associated ID map for single mapping cases. + */ + if (node->type == ACPI_IORT_NODE_SMMU_V3) + ret = iort_get_smmu_v3_id_mapping_index(node, &index); + /* Do the ID translation */ for (i = 0; i < node->mapping_count; i++, map++) { + /* if it's a SMMUv3 device id mapping index, skip it */ + if (!ret && i == index) + continue; + if (!iort_id_map(map, node->type, id, &id)) break; }