From: Zhou Wang <wangzhou1@hisilicon.com>
To: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>,
linux-acpi@vger.kernel.org, nwatters@codeaurora.org
Cc: Catalin Marinas <catalin.marinas@arm.com>,
Sudeep Holla <sudeep.holla@arm.com>,
Will Deacon <will.deacon@arm.com>,
Alex Williamson <alex.williamson@redhat.com>,
Hanjun Guo <hanjun.guo@linaro.org>,
linux-pci@vger.kernel.org, Robin Murphy <robin.murphy@arm.com>,
linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH v2] ACPI/IORT: Fix PCI ACS enablement
Date: Mon, 9 Oct 2017 16:40:10 +0800 [thread overview]
Message-ID: <59DB35EA.7010301@hisilicon.com> (raw)
In-Reply-To: <20171003124843.GA16134@red-moon>
On 2017/10/3 20:48, Lorenzo Pieralisi wrote:
> [+Nate]
>
> Zhou, Nate,
>
> On Mon, Oct 02, 2017 at 06:28:44PM +0100, Lorenzo Pieralisi wrote:
>> commit f6810c15cf97 ("iommu/arm-smmu: Clean up early-probing
>> workarounds") removed kernel code that was allowing to initialize
>> and probe the SMMU devices early (ie earlier than PCI devices, through
>> linker script callback entries) in the boot process because it was not
>> needed any longer in that the SMMU devices/drivers now support deferred
>> probing.
>>
>> Since the SMMUs probe routines are also in charge of requesting global
>> PCI ACS kernel enablement, commit f6810c15cf97 ("iommu/arm-smmu: Clean
>> up early-probing workarounds") also postponed PCI ACS enablement to
>> SMMUs devices probe time, which is too late given that PCI devices needs
>> to detect if PCI ACS is enabled to init the respective capability
>> through the following call path:
>>
>> pci_device_add()
>> -> pci_init_capabilities()
>> -> pci_enable_acs()
>>
>> Add code in the ACPI IORT SMMU platform devices initialization path
>> (that is called before ACPI PCI enumeration) to detect if there
>> exists firmware mappings to map root complexes ids to SMMU ids
>> and if so enable ACS for the system.
>>
>> Fixes: f6810c15cf97 ("iommu/arm-smmu: Clean up early-probing
>> Signed-workarounds")
>> Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
>> Cc: Will Deacon <will.deacon@arm.com>
>> Cc: Hanjun Guo <hanjun.guo@linaro.org>
>> Cc: Sudeep Holla <sudeep.holla@arm.com>
>> Cc: Catalin Marinas <catalin.marinas@arm.com>
>> Cc: Robin Murphy <robin.murphy@arm.com>
>> Cc: Zhou Wang <wangzhou1@hisilicon.com>
>> Cc: Alex Williamson <alex.williamson@redhat.com>
>> ---
>> v1 -> v2:
>>
>> - Reworked ACS enablement logic and based on root complex to SMMU
>> ids firmware mapping detection
>> - Rebased against v4.14-rc3
>>
>> v1: https://marc.info/?l=linux-acpi&m=150584059818925&w=2
>>
>> drivers/acpi/arm64/iort.c | 35 +++++++++++++++++++++++++++++++++++
>> 1 file changed, 35 insertions(+)
>
> I have reworked the enablement logic wrt v1, dou you mind testing it
> please, I would like to get it merged since I have 4.15 patches depending
> on it.
Hi Lorenzo,
Sorry for late, I was in my National Day holiday.
I tested this patch in HiSilicon Hip08 based board, it works well in RC->SMMU->ITS and
RC->ITS maps.
Tested-by: Zhou Wang <wangzhou1@hisilicon.com>
Thanks,
Zhou
>
> Thanks,
> Lorenzo
>
>> diff --git a/drivers/acpi/arm64/iort.c b/drivers/acpi/arm64/iort.c
>> index 9565d57..de56394 100644
>> --- a/drivers/acpi/arm64/iort.c
>> +++ b/drivers/acpi/arm64/iort.c
>> @@ -1178,12 +1178,44 @@ static int __init iort_add_smmu_platform_device(struct acpi_iort_node *node)
>> return ret;
>> }
>>
>> +static bool __init iort_enable_acs(struct acpi_iort_node *iort_node)
>> +{
>> + if (iort_node->type == ACPI_IORT_NODE_PCI_ROOT_COMPLEX) {
>> + struct acpi_iort_node *parent;
>> + struct acpi_iort_id_mapping *map;
>> + int i;
>> +
>> + map = ACPI_ADD_PTR(struct acpi_iort_id_mapping, iort_node,
>> + iort_node->mapping_offset);
>> +
>> + for (i = 0; i < iort_node->mapping_count; i++, map++) {
>> + if (!map->output_reference)
>> + continue;
>> +
>> + parent = ACPI_ADD_PTR(struct acpi_iort_node,
>> + iort_table, map->output_reference);
>> + /*
>> + * If we detect a RC->SMMU mapping, make sure
>> + * we enable ACS on the system.
>> + */
>> + if ((parent->type == ACPI_IORT_NODE_SMMU) ||
>> + (parent->type == ACPI_IORT_NODE_SMMU_V3)) {
>> + pci_request_acs();
>> + return true;
>> + }
>> + }
>> + }
>> +
>> + return false;
>> +}
>> +
>> static void __init iort_init_platform_devices(void)
>> {
>> struct acpi_iort_node *iort_node, *iort_end;
>> struct acpi_table_iort *iort;
>> struct fwnode_handle *fwnode;
>> int i, ret;
>> + bool acs_enabled = false;
>>
>> /*
>> * iort_table and iort both point to the start of IORT table, but
>> @@ -1203,6 +1235,9 @@ static void __init iort_init_platform_devices(void)
>> return;
>> }
>>
>> + if (!acs_enabled)
>> + acs_enabled = iort_enable_acs(iort_node);
>> +
>> if ((iort_node->type == ACPI_IORT_NODE_SMMU) ||
>> (iort_node->type == ACPI_IORT_NODE_SMMU_V3)) {
>>
>> --
>> 2.4.12
>>
>
> .
>
WARNING: multiple messages have this Message-ID (diff)
From: Zhou Wang <wangzhou1@hisilicon.com>
To: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>,
<linux-acpi@vger.kernel.org>, <nwatters@codeaurora.org>
Cc: Catalin Marinas <catalin.marinas@arm.com>,
Sudeep Holla <sudeep.holla@arm.com>,
Will Deacon <will.deacon@arm.com>,
Alex Williamson <alex.williamson@redhat.com>,
Hanjun Guo <hanjun.guo@linaro.org>,
linux-pci@vger.kernel.org, Robin Murphy <robin.murphy@arm.com>,
linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH v2] ACPI/IORT: Fix PCI ACS enablement
Date: Mon, 9 Oct 2017 16:40:10 +0800 [thread overview]
Message-ID: <59DB35EA.7010301@hisilicon.com> (raw)
In-Reply-To: <20171003124843.GA16134@red-moon>
On 2017/10/3 20:48, Lorenzo Pieralisi wrote:
> [+Nate]
>
> Zhou, Nate,
>
> On Mon, Oct 02, 2017 at 06:28:44PM +0100, Lorenzo Pieralisi wrote:
>> commit f6810c15cf97 ("iommu/arm-smmu: Clean up early-probing
>> workarounds") removed kernel code that was allowing to initialize
>> and probe the SMMU devices early (ie earlier than PCI devices, through
>> linker script callback entries) in the boot process because it was not
>> needed any longer in that the SMMU devices/drivers now support deferred
>> probing.
>>
>> Since the SMMUs probe routines are also in charge of requesting global
>> PCI ACS kernel enablement, commit f6810c15cf97 ("iommu/arm-smmu: Clean
>> up early-probing workarounds") also postponed PCI ACS enablement to
>> SMMUs devices probe time, which is too late given that PCI devices needs
>> to detect if PCI ACS is enabled to init the respective capability
>> through the following call path:
>>
>> pci_device_add()
>> -> pci_init_capabilities()
>> -> pci_enable_acs()
>>
>> Add code in the ACPI IORT SMMU platform devices initialization path
>> (that is called before ACPI PCI enumeration) to detect if there
>> exists firmware mappings to map root complexes ids to SMMU ids
>> and if so enable ACS for the system.
>>
>> Fixes: f6810c15cf97 ("iommu/arm-smmu: Clean up early-probing
>> Signed-workarounds")
>> Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
>> Cc: Will Deacon <will.deacon@arm.com>
>> Cc: Hanjun Guo <hanjun.guo@linaro.org>
>> Cc: Sudeep Holla <sudeep.holla@arm.com>
>> Cc: Catalin Marinas <catalin.marinas@arm.com>
>> Cc: Robin Murphy <robin.murphy@arm.com>
>> Cc: Zhou Wang <wangzhou1@hisilicon.com>
>> Cc: Alex Williamson <alex.williamson@redhat.com>
>> ---
>> v1 -> v2:
>>
>> - Reworked ACS enablement logic and based on root complex to SMMU
>> ids firmware mapping detection
>> - Rebased against v4.14-rc3
>>
>> v1: https://marc.info/?l=linux-acpi&m=150584059818925&w=2
>>
>> drivers/acpi/arm64/iort.c | 35 +++++++++++++++++++++++++++++++++++
>> 1 file changed, 35 insertions(+)
>
> I have reworked the enablement logic wrt v1, dou you mind testing it
> please, I would like to get it merged since I have 4.15 patches depending
> on it.
Hi Lorenzo,
Sorry for late, I was in my National Day holiday.
I tested this patch in HiSilicon Hip08 based board, it works well in RC->SMMU->ITS and
RC->ITS maps.
Tested-by: Zhou Wang <wangzhou1@hisilicon.com>
Thanks,
Zhou
>
> Thanks,
> Lorenzo
>
>> diff --git a/drivers/acpi/arm64/iort.c b/drivers/acpi/arm64/iort.c
>> index 9565d57..de56394 100644
>> --- a/drivers/acpi/arm64/iort.c
>> +++ b/drivers/acpi/arm64/iort.c
>> @@ -1178,12 +1178,44 @@ static int __init iort_add_smmu_platform_device(struct acpi_iort_node *node)
>> return ret;
>> }
>>
>> +static bool __init iort_enable_acs(struct acpi_iort_node *iort_node)
>> +{
>> + if (iort_node->type == ACPI_IORT_NODE_PCI_ROOT_COMPLEX) {
>> + struct acpi_iort_node *parent;
>> + struct acpi_iort_id_mapping *map;
>> + int i;
>> +
>> + map = ACPI_ADD_PTR(struct acpi_iort_id_mapping, iort_node,
>> + iort_node->mapping_offset);
>> +
>> + for (i = 0; i < iort_node->mapping_count; i++, map++) {
>> + if (!map->output_reference)
>> + continue;
>> +
>> + parent = ACPI_ADD_PTR(struct acpi_iort_node,
>> + iort_table, map->output_reference);
>> + /*
>> + * If we detect a RC->SMMU mapping, make sure
>> + * we enable ACS on the system.
>> + */
>> + if ((parent->type == ACPI_IORT_NODE_SMMU) ||
>> + (parent->type == ACPI_IORT_NODE_SMMU_V3)) {
>> + pci_request_acs();
>> + return true;
>> + }
>> + }
>> + }
>> +
>> + return false;
>> +}
>> +
>> static void __init iort_init_platform_devices(void)
>> {
>> struct acpi_iort_node *iort_node, *iort_end;
>> struct acpi_table_iort *iort;
>> struct fwnode_handle *fwnode;
>> int i, ret;
>> + bool acs_enabled = false;
>>
>> /*
>> * iort_table and iort both point to the start of IORT table, but
>> @@ -1203,6 +1235,9 @@ static void __init iort_init_platform_devices(void)
>> return;
>> }
>>
>> + if (!acs_enabled)
>> + acs_enabled = iort_enable_acs(iort_node);
>> +
>> if ((iort_node->type == ACPI_IORT_NODE_SMMU) ||
>> (iort_node->type == ACPI_IORT_NODE_SMMU_V3)) {
>>
>> --
>> 2.4.12
>>
>
> .
>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
WARNING: multiple messages have this Message-ID (diff)
From: wangzhou1@hisilicon.com (Zhou Wang)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH v2] ACPI/IORT: Fix PCI ACS enablement
Date: Mon, 9 Oct 2017 16:40:10 +0800 [thread overview]
Message-ID: <59DB35EA.7010301@hisilicon.com> (raw)
In-Reply-To: <20171003124843.GA16134@red-moon>
On 2017/10/3 20:48, Lorenzo Pieralisi wrote:
> [+Nate]
>
> Zhou, Nate,
>
> On Mon, Oct 02, 2017 at 06:28:44PM +0100, Lorenzo Pieralisi wrote:
>> commit f6810c15cf97 ("iommu/arm-smmu: Clean up early-probing
>> workarounds") removed kernel code that was allowing to initialize
>> and probe the SMMU devices early (ie earlier than PCI devices, through
>> linker script callback entries) in the boot process because it was not
>> needed any longer in that the SMMU devices/drivers now support deferred
>> probing.
>>
>> Since the SMMUs probe routines are also in charge of requesting global
>> PCI ACS kernel enablement, commit f6810c15cf97 ("iommu/arm-smmu: Clean
>> up early-probing workarounds") also postponed PCI ACS enablement to
>> SMMUs devices probe time, which is too late given that PCI devices needs
>> to detect if PCI ACS is enabled to init the respective capability
>> through the following call path:
>>
>> pci_device_add()
>> -> pci_init_capabilities()
>> -> pci_enable_acs()
>>
>> Add code in the ACPI IORT SMMU platform devices initialization path
>> (that is called before ACPI PCI enumeration) to detect if there
>> exists firmware mappings to map root complexes ids to SMMU ids
>> and if so enable ACS for the system.
>>
>> Fixes: f6810c15cf97 ("iommu/arm-smmu: Clean up early-probing
>> Signed-workarounds")
>> Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
>> Cc: Will Deacon <will.deacon@arm.com>
>> Cc: Hanjun Guo <hanjun.guo@linaro.org>
>> Cc: Sudeep Holla <sudeep.holla@arm.com>
>> Cc: Catalin Marinas <catalin.marinas@arm.com>
>> Cc: Robin Murphy <robin.murphy@arm.com>
>> Cc: Zhou Wang <wangzhou1@hisilicon.com>
>> Cc: Alex Williamson <alex.williamson@redhat.com>
>> ---
>> v1 -> v2:
>>
>> - Reworked ACS enablement logic and based on root complex to SMMU
>> ids firmware mapping detection
>> - Rebased against v4.14-rc3
>>
>> v1: https://marc.info/?l=linux-acpi&m=150584059818925&w=2
>>
>> drivers/acpi/arm64/iort.c | 35 +++++++++++++++++++++++++++++++++++
>> 1 file changed, 35 insertions(+)
>
> I have reworked the enablement logic wrt v1, dou you mind testing it
> please, I would like to get it merged since I have 4.15 patches depending
> on it.
Hi Lorenzo,
Sorry for late, I was in my National Day holiday.
I tested this patch in HiSilicon Hip08 based board, it works well in RC->SMMU->ITS and
RC->ITS maps.
Tested-by: Zhou Wang <wangzhou1@hisilicon.com>
Thanks,
Zhou
>
> Thanks,
> Lorenzo
>
>> diff --git a/drivers/acpi/arm64/iort.c b/drivers/acpi/arm64/iort.c
>> index 9565d57..de56394 100644
>> --- a/drivers/acpi/arm64/iort.c
>> +++ b/drivers/acpi/arm64/iort.c
>> @@ -1178,12 +1178,44 @@ static int __init iort_add_smmu_platform_device(struct acpi_iort_node *node)
>> return ret;
>> }
>>
>> +static bool __init iort_enable_acs(struct acpi_iort_node *iort_node)
>> +{
>> + if (iort_node->type == ACPI_IORT_NODE_PCI_ROOT_COMPLEX) {
>> + struct acpi_iort_node *parent;
>> + struct acpi_iort_id_mapping *map;
>> + int i;
>> +
>> + map = ACPI_ADD_PTR(struct acpi_iort_id_mapping, iort_node,
>> + iort_node->mapping_offset);
>> +
>> + for (i = 0; i < iort_node->mapping_count; i++, map++) {
>> + if (!map->output_reference)
>> + continue;
>> +
>> + parent = ACPI_ADD_PTR(struct acpi_iort_node,
>> + iort_table, map->output_reference);
>> + /*
>> + * If we detect a RC->SMMU mapping, make sure
>> + * we enable ACS on the system.
>> + */
>> + if ((parent->type == ACPI_IORT_NODE_SMMU) ||
>> + (parent->type == ACPI_IORT_NODE_SMMU_V3)) {
>> + pci_request_acs();
>> + return true;
>> + }
>> + }
>> + }
>> +
>> + return false;
>> +}
>> +
>> static void __init iort_init_platform_devices(void)
>> {
>> struct acpi_iort_node *iort_node, *iort_end;
>> struct acpi_table_iort *iort;
>> struct fwnode_handle *fwnode;
>> int i, ret;
>> + bool acs_enabled = false;
>>
>> /*
>> * iort_table and iort both point to the start of IORT table, but
>> @@ -1203,6 +1235,9 @@ static void __init iort_init_platform_devices(void)
>> return;
>> }
>>
>> + if (!acs_enabled)
>> + acs_enabled = iort_enable_acs(iort_node);
>> +
>> if ((iort_node->type == ACPI_IORT_NODE_SMMU) ||
>> (iort_node->type == ACPI_IORT_NODE_SMMU_V3)) {
>>
>> --
>> 2.4.12
>>
>
> .
>
next prev parent reply other threads:[~2017-10-09 8:40 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-10-02 17:28 [PATCH v2] ACPI/IORT: Fix PCI ACS enablement Lorenzo Pieralisi
2017-10-02 17:28 ` Lorenzo Pieralisi
2017-10-03 12:48 ` Lorenzo Pieralisi
2017-10-03 12:48 ` Lorenzo Pieralisi
2017-10-03 12:48 ` Lorenzo Pieralisi
2017-10-03 19:08 ` Nate Watterson
2017-10-03 19:08 ` Nate Watterson
2017-10-09 8:40 ` Zhou Wang [this message]
2017-10-09 8:40 ` Zhou Wang
2017-10-09 8:40 ` Zhou Wang
2017-10-03 13:47 ` Robin Murphy
2017-10-03 13:47 ` Robin Murphy
2017-10-03 14:45 ` John Garry
2017-10-03 14:45 ` John Garry
2017-10-03 14:45 ` John Garry
2017-10-03 16:53 ` Lorenzo Pieralisi
2017-10-03 16:53 ` Lorenzo Pieralisi
2017-10-03 16:53 ` Lorenzo Pieralisi
2017-10-04 16:36 ` Catalin Marinas
2017-10-04 16:36 ` Catalin Marinas
2017-10-04 16:36 ` Catalin Marinas
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=59DB35EA.7010301@hisilicon.com \
--to=wangzhou1@hisilicon.com \
--cc=alex.williamson@redhat.com \
--cc=catalin.marinas@arm.com \
--cc=hanjun.guo@linaro.org \
--cc=linux-acpi@vger.kernel.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-pci@vger.kernel.org \
--cc=lorenzo.pieralisi@arm.com \
--cc=nwatters@codeaurora.org \
--cc=robin.murphy@arm.com \
--cc=sudeep.holla@arm.com \
--cc=will.deacon@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.