From patchwork Wed Sep 27 01:20:14 2017 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Hanjun Guo X-Patchwork-Id: 114309 Delivered-To: patch@linaro.org Received: by 10.140.106.117 with SMTP id d108csp4470921qgf; Tue, 26 Sep 2017 18:20:42 -0700 (PDT) X-Received: by 10.159.204.147 with SMTP id t19mr12193896plo.7.1506475242099; Tue, 26 Sep 2017 18:20:42 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1506475242; cv=none; d=google.com; s=arc-20160816; b=a/6EhgmIeL0JUUCWjZe1VBC5efM3pqz5XaXC5lxS6SORMuTn9ocWj6APeuOjMb8xbJ 63w3jJBmcDGgrWAQyKCmwrpc7EYQ10qGEYMyM8MP6F7SVFsIxN9PalWWM7bVDveeVnuY twozXumy5pS4+27/03DvAF0qvXUmONBVIHsP19XIdjRvybMEkVn4m7jcuFeFuBCbBiPy Pq/sMGHTFLMhddG9YfU8u1MCaul/rSBkeeYHdta9cxejrvHsss7DqX/1vScCxrzB8COJ QlzWCZY/LDS68uUwocXhPknpvoCAkbokOa7hzwMpAUmsR6SVv40pw330QoPf4F87L5XZ eWbg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:references:in-reply-to:message-id:date :subject:cc:to:from:dkim-signature:arc-authentication-results; bh=4YJIcV34J5NVqK3siQNtTvPd0umcVdI6fu96WxoIvOQ=; b=PwwzlNvd/isS0ODmcIqqns50BjIxItlQXj8Kbgnhprwtw40bRMpjhODGPkMmHx13NM KSE/uZ+je1xgRX9csqSvklpBeINPDsqHoahqATBbNwmGxHl2Y2phvXNzomx0iAmDXx8x 7p6LBalVIBmHklLfhZqnjVXIIAHDBRzVsgaNt1p9TCAsahayn9UY+QnY4onDrif4si8p /wf+3c2qM+REcEUWy39oo8zQKdMM6xTocBZH8BRHURmaV2L4O1WeXbYO0gWr435ez29K /FG5ciUNV9n60yMxqsAUGGRy4pYiKLSVkG6y38h9PEyUg8+Nep0UnaBkwKmVn7wraDRI kvgA== ARC-Authentication-Results: i=1; mx.google.com; dkim=neutral (body hash did not verify) header.i=@linaro.org header.s=google header.b=B9aYNe3h; 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; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=linaro.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id j18si2494136pfa.558.2017.09.26.18.20.41; Tue, 26 Sep 2017 18:20:42 -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; dkim=neutral (body hash did not verify) header.i=@linaro.org header.s=google header.b=B9aYNe3h; 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; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=linaro.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S965519AbdI0BUk (ORCPT + 7 others); Tue, 26 Sep 2017 21:20:40 -0400 Received: from mail-pg0-f45.google.com ([74.125.83.45]:47765 "EHLO mail-pg0-f45.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S969162AbdI0BUh (ORCPT ); Tue, 26 Sep 2017 21:20:37 -0400 Received: by mail-pg0-f45.google.com with SMTP id d8so6875389pgt.4 for ; Tue, 26 Sep 2017 18:20:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=from:to:cc:subject:date:message-id:in-reply-to:references; bh=LCrVw/tMCQA9Z3zMu4C/+3jm0PyjF+UcxwnmGZ5oECs=; b=B9aYNe3hqoMHMHsNfFATvLVwb+YZIwDSKlP2POGCswd9YZ1IEeY2k9XdCc9opJ+BEA lO2aBcUx2F6ICA1lJ85cQOElEvoyJW9v5E98OfhiiaN/Ea5Ua9T399Xkk3Jd76Kt4bJa OOjYgtp+oNUDVGAsu1rqP3xS7gi8wyI1ctYG0= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to :references; bh=LCrVw/tMCQA9Z3zMu4C/+3jm0PyjF+UcxwnmGZ5oECs=; b=Srx6NsXzDgEeHMFsVKuI85Y2YIU7XwSku/4UYlRQ0o9lIwrTpGVkQp00Fx44BHZuf2 KgvMZsvH6Mexh2ilsFZ4e9lrUA99ax+PxXFxAyXq48bfp2SFFZ1k2g2SgP2GnMAfl0Jz esw/n/WQZsam1NAX54pX695mBmrVmaJEuG/YodvbFFTOQ5M8Sgqn87aJBDt1n1AcZ1WD qc59DUBl1Pg5R/jBkEZU3pqeLQd0TDjdXAnUKDs4HrzBJXjRWtutP3bn5l1zO8aDAwUp dpSrpoUD3o+nfAaEsZN2fdxGFiiN4faey1V3YuFo6hz0Ll4P1lwbxj1mhBcYIJS5/g4B dgFQ== X-Gm-Message-State: AHPjjUjZsUqThD7yttrqczgPcL3ARnf0+fRMo0KnTMx7+q6Wu2j5x+B7 l0u6Ys3QyiifAD0JR/4paqbYlg== X-Google-Smtp-Source: AOwi7QDEzAqThiAjVuW/ET+0J8lct/4fBTp3u44ZU7qRpx0UpZJWET6FaIR+lt4yE3i31go7DcoUHA== X-Received: by 10.101.78.12 with SMTP id r12mr12634008pgt.289.1506475237381; Tue, 26 Sep 2017 18:20:37 -0700 (PDT) Received: from localhost ([70.35.39.2]) by smtp.googlemail.com with ESMTPSA id s27sm18510873pgo.59.2017.09.26.18.20.36 (version=TLS1_2 cipher=AES128-SHA bits=128/128); Tue, 26 Sep 2017 18:20:36 -0700 (PDT) From: Hanjun Guo To: Lorenzo Pieralisi , Robin Murphy Cc: "Rafael J. Wysocki" , Marc Zyngier , Lv Zheng , linux-acpi@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linuxarm@huawei.com, Hanjun Guo Subject: [PATCH 3/4] ACPI: IORT: Skip SMMUv3 device ID map for two steps mappings Date: Wed, 27 Sep 2017 09:20:14 +0800 Message-Id: <1506475215-2731-4-git-send-email-hanjun.guo@linaro.org> X-Mailer: git-send-email 1.9.1 In-Reply-To: <1506475215-2731-1-git-send-email-hanjun.guo@linaro.org> References: <1506475215-2731-1-git-send-email-hanjun.guo@linaro.org> Sender: linux-acpi-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-acpi@vger.kernel.org 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 special 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. Introduce iort_get_id_mapping_index() to get the index then skip the map entry in iort_node_map_id(), also to get the dev ID directly for iort_pmsi_get_dev_id() for ITS platform MSI preparation. Signed-off-by: Hanjun Guo --- drivers/acpi/arm64/iort.c | 64 +++++++++++++++++++++++++++++++++++++++++++---- 1 file changed, 59 insertions(+), 5 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/acpi/arm64/iort.c b/drivers/acpi/arm64/iort.c index db71d7f..1c1160e 100644 --- a/drivers/acpi/arm64/iort.c +++ b/drivers/acpi/arm64/iort.c @@ -357,7 +357,8 @@ struct acpi_iort_node *iort_node_get_id(struct acpi_iort_node *node, if (map->flags & ACPI_IORT_ID_SINGLE_MAPPING) { if (node->type == ACPI_IORT_NODE_NAMED_COMPONENT || - node->type == ACPI_IORT_NODE_PCI_ROOT_COMPLEX) { + node->type == ACPI_IORT_NODE_PCI_ROOT_COMPLEX || + node->type == ACPI_IORT_NODE_SMMU_V3) { *id_out = map->output_base; return parent; } @@ -366,6 +367,40 @@ struct acpi_iort_node *iort_node_get_id(struct acpi_iort_node *node, return NULL; } +static int iort_get_id_mapping_index(struct acpi_iort_node *node) +{ + struct acpi_iort_smmu_v3 *smmu; + + switch (node->type) { + case ACPI_IORT_NODE_SMMU_V3: + /* + * SMMUv3 dev ID mapping index was introdueced in revision 1 + * table, not available in revision 0 + */ + if (node->revision < 1) + return -EINVAL; + + smmu = (struct acpi_iort_smmu_v3 *)node->node_data; + /* + * ID mapping index is only ignored if all interrupts are + * GSIV based + */ + if (smmu->event_gsiv && smmu->pri_gsiv && smmu->gerr_gsiv + && smmu->sync_gsiv) + return -EINVAL; + + if (smmu->id_mapping_index >= node->mapping_count) { + pr_err(FW_BUG "[node %p type %d] ID mapping index overflows valid mappings\n", + node, node->type); + return -EINVAL; + } + + return smmu->id_mapping_index; + default: + return -EINVAL; + } +} + 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 +410,7 @@ 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, index; if (IORT_TYPE_MASK(node->type) & type_mask) { if (id_out) @@ -396,8 +431,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, error value + * returned for index will be an invalid value in practical. + */ + index = iort_get_id_mapping_index(node); + /* 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 (i == index) + continue; + if (!iort_id_map(map, node->type, id, &id)) break; } @@ -507,16 +553,24 @@ u32 iort_msi_map_rid(struct device *dev, u32 req_id) */ int iort_pmsi_get_dev_id(struct device *dev, u32 *dev_id) { - int i; + int i, index; struct acpi_iort_node *node; node = iort_find_dev_node(dev); if (!node) return -ENODEV; - for (i = 0; i < node->mapping_count; i++) { - if (iort_node_map_platform_id(node, dev_id, IORT_MSI_TYPE, i)) + index = iort_get_id_mapping_index(node); + /* if there is a valid index, go get the dev_id directly */ + if (index >= 0) { + if (iort_node_get_id(node, dev_id, index)) return 0; + } else { + for (i = 0; i < node->mapping_count; i++) { + if (iort_node_map_platform_id(node, dev_id, + IORT_MSI_TYPE, i)) + return 0; + } } return -ENODEV;