From: Hanjun Guo <guohanjun@huawei.com>
To: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Cc: Marc Zyngier <marc.zyngier@arm.com>,
"Rafael J. Wysocki" <rjw@rjwysocki.net>,
Linuxarm <linuxarm@huawei.com>,
"linux-acpi@vger.kernel.org" <linux-acpi@vger.kernel.org>,
Hanjun Guo <hanjun.guo@linaro.org>,
Robin Murphy <robin.murphy@arm.com>,
"linux-arm-kernel@lists.infradead.org"
<linux-arm-kernel@lists.infradead.org>,
Lv Zheng <lv.zheng@intel.com>
Subject: Re: [PATCH 3/4] ACPI: IORT: Skip SMMUv3 device ID map for two steps mappings
Date: Thu, 12 Oct 2017 15:30:10 +0800 [thread overview]
Message-ID: <59DF1A02.9040008@huawei.com> (raw)
In-Reply-To: <20171011102424.GA10795@red-moon>
On 2017/10/11 18:24, Lorenzo Pieralisi wrote:
> On Wed, Oct 11, 2017 at 01:26:10PM +0800, Hanjun Guo wrote:
>> On 2017/10/10 17:20, Lorenzo Pieralisi wrote:
>>> On Tue, Oct 10, 2017 at 02:47:53PM +0800, Hanjun Guo wrote:
>>>> Hi Lorenzo,
>>>>
>>>> Sorry for the late reply, holidays in China for the past week.
>>>>
>>>> At 2017/9/27 21:54, Lorenzo Pieralisi wrote:
>>>>> Hi Hanjun,
>>>>>
>>>>> On Wed, Sep 27, 2017 at 09:20:14AM +0800, Hanjun Guo wrote:
>>>>>> 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.
>>>>> Is this actually true ? I think that currently we would simply skip
>>>>> the entry and print an error log but we can't get a wrong ITS parent.
>>>> So the only valid single mapping under type SMMUv3 is SMMUv3's dev id
>>>> mapping, we need to fix the IORT spec as well.
>>>>
>>>>> I am rewriting this commit (I will probably split it), it is doing the
>>>>> right thing but the commit log is stale (probably caused by code
>>>>> reshuffling).
>>>> Do I need to resend another version, or you can help to update it?
>>>> please let me know.
>>> I reworked the patches, you can repost/retest them I made them available
>>> in the branch below, we will have to add a guard around ACPICA smmu
>>> struct (unfortunately I think we will have to use the ACPICA version as
>>> a guard) or I can ask Rafael to pull the series if ACPICA goes via ACPI
>>> tree (and your patch made it into the release - I will check ACPICA
>>> upstream).
>> Bob already merged my pull request yesterday, I think it will be ready for
>> acpica release for this month.
> That's good, mind updating the patch series with an ACPICA guard in IORT
> code in preparation for the pull request ?
Do you mean drop the acpica patch in this patch set and adding the code below?
diff --git a/drivers/acpi/arm64/iort.c b/drivers/acpi/arm64/iort.c
index 37a1b9f..a883bec 100644
--- a/drivers/acpi/arm64/iort.c
+++ b/drivers/acpi/arm64/iort.c
@@ -366,6 +366,7 @@ static struct acpi_iort_node *iort_node_get_id(struct acpi_iort_node *node,
return NULL;
}
+#if (ACPI_CA_VERSION > 0x20170929)
static int iort_get_id_mapping_index(struct acpi_iort_node *node)
{
struct acpi_iort_smmu_v3 *smmu;
@@ -399,6 +400,12 @@ static int iort_get_id_mapping_index(struct acpi_iort_node *node)
return -EINVAL;
}
}
+#else
+static int iort_get_id_mapping_index(struct acpi_iort_node *node)
+{
+ return -EINVAL;
+}
+#endif
Thanks
Hanjun
next prev parent reply other threads:[~2017-10-12 7:30 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-09-27 1:20 [PATCH 0/4] IORT SMMUv3 MSI support Hanjun Guo
2017-09-27 1:20 ` [PATCH 1/4] ACPICA: Add SMMUv3 device ID mapping index support Hanjun Guo
2017-09-27 1:20 ` [PATCH 2/4] ACPI: IORT: lookup iort node via fwnode Hanjun Guo
2017-09-27 1:20 ` [PATCH 3/4] ACPI: IORT: Skip SMMUv3 device ID map for two steps mappings Hanjun Guo
2017-09-27 13:54 ` Lorenzo Pieralisi
2017-10-10 6:47 ` Hanjun Guo
2017-10-10 9:20 ` Lorenzo Pieralisi
2017-10-11 5:26 ` Hanjun Guo
2017-10-11 10:24 ` Lorenzo Pieralisi
2017-10-12 7:30 ` Hanjun Guo [this message]
2017-10-12 9:50 ` Lorenzo Pieralisi
2017-09-27 1:20 ` [PATCH 4/4] ACPI: IORT: SMMUv3 nodes MSI support Hanjun Guo
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=59DF1A02.9040008@huawei.com \
--to=guohanjun@huawei.com \
--cc=hanjun.guo@linaro.org \
--cc=linux-acpi@vger.kernel.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linuxarm@huawei.com \
--cc=lorenzo.pieralisi@arm.com \
--cc=lv.zheng@intel.com \
--cc=marc.zyngier@arm.com \
--cc=rjw@rjwysocki.net \
--cc=robin.murphy@arm.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).