public inbox for linux-acpi@vger.kernel.org
 help / color / mirror / Atom feed
From: Will Deacon <will.deacon-5wv7dgnIgG8@public.gmane.org>
To: Jean-Philippe Brucker
	<jean-philippe.brucker-5wv7dgnIgG8@public.gmane.org>
Cc: zhongmiao-C8/M+/jPZTeaMJb+Lgu22Q@public.gmane.org,
	okaya-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org,
	rjw-LthD3rsA81gm4RdzfppkhA@public.gmane.org,
	linux-acpi-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
	iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org,
	sudeep.holla-5wv7dgnIgG8@public.gmane.org,
	robin.murphy-5wv7dgnIgG8@public.gmane.org,
	linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org,
	lenb-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org
Subject: Re: [PATCH v2 1/7] ACPI/IORT: Check ATS capability in root complex nodes
Date: Mon, 15 Apr 2019 14:21:08 +0100	[thread overview]
Message-ID: <20190415132108.GB15023@fuggles.cambridge.arm.com> (raw)
In-Reply-To: <20190409165245.26500-2-jean-philippe.brucker-5wv7dgnIgG8@public.gmane.org>

On Tue, Apr 09, 2019 at 05:52:39PM +0100, Jean-Philippe Brucker wrote:
> Root complex node in IORT has a bit telling whether it supports ATS or
> not. Store this bit in the IOMMU fwspec when setting up a device, so it
> can be accessed later by an IOMMU driver.
> 
> Use the negative version (NO_ATS) at the moment because it's not clear
> if/how the bit needs to be integrated in other firmware descriptions. The
> SMMU has a feature bit telling if it supports ATS, which might be
> sufficient in most systems for deciding whether or not we should enable
> the ATS capability in endpoints.

Hmm, the SMMUv3 architecture manual is pretty explicit about this:

  | It [SMMU_IDR0.ATS] does not guarantee that client devices and intermediate
  | components also support ATS and this must be determined separately.

so we may need to extend the PCI bindings to describe this. I think the
negative logic is likely to get in the way if that's the case.

> Signed-off-by: Jean-Philippe Brucker <jean-philippe.brucker-5wv7dgnIgG8@public.gmane.org>
> ---
>  drivers/acpi/arm64/iort.c | 11 +++++++++++
>  include/linux/iommu.h     |  4 ++++
>  2 files changed, 15 insertions(+)
> 
> diff --git a/drivers/acpi/arm64/iort.c b/drivers/acpi/arm64/iort.c
> index e48894e002ba..7f2c1c9c6b38 100644
> --- a/drivers/acpi/arm64/iort.c
> +++ b/drivers/acpi/arm64/iort.c
> @@ -1028,6 +1028,14 @@ void iort_dma_setup(struct device *dev, u64 *dma_addr, u64 *dma_size)
>  	dev_dbg(dev, "dma_pfn_offset(%#08llx)\n", offset);
>  }
>  
> +static bool iort_pci_rc_supports_ats(struct acpi_iort_node *node)
> +{
> +	struct acpi_iort_root_complex *pci_rc;
> +
> +	pci_rc = (struct acpi_iort_root_complex *)node->node_data;
> +	return pci_rc->ats_attribute & ACPI_IORT_ATS_SUPPORTED;
> +}

Do we need to worry about the "noats" command-line option here? It feels
like we should be checking with the PCI subsystem before telling the SMMU
we're good to go.

I'll need Lorenzo's ack on this.

Will

WARNING: multiple messages have this Message-ID (diff)
From: Will Deacon <will.deacon@arm.com>
To: Jean-Philippe Brucker <jean-philippe.brucker@arm.com>
Cc: iommu@lists.linux-foundation.org,
	linux-arm-kernel@lists.infradead.org, linux-acpi@vger.kernel.org,
	robin.murphy@arm.com, joro@8bytes.org, hanjun.guo@linaro.org,
	lorenzo.pieralisi@arm.com, sudeep.holla@arm.com,
	rjw@rjwysocki.net, lenb@kernel.org, okaya@kernel.org,
	zhongmiao@hisilicon.com, eric.auger@redhat.com
Subject: Re: [PATCH v2 1/7] ACPI/IORT: Check ATS capability in root complex nodes
Date: Mon, 15 Apr 2019 14:21:08 +0100	[thread overview]
Message-ID: <20190415132108.GB15023@fuggles.cambridge.arm.com> (raw)
Message-ID: <20190415132108.Egtykyvn7AOzm85ptbA2zTWdBOdsLH3vGPzB9838Lpo@z> (raw)
In-Reply-To: <20190409165245.26500-2-jean-philippe.brucker@arm.com>

On Tue, Apr 09, 2019 at 05:52:39PM +0100, Jean-Philippe Brucker wrote:
> Root complex node in IORT has a bit telling whether it supports ATS or
> not. Store this bit in the IOMMU fwspec when setting up a device, so it
> can be accessed later by an IOMMU driver.
> 
> Use the negative version (NO_ATS) at the moment because it's not clear
> if/how the bit needs to be integrated in other firmware descriptions. The
> SMMU has a feature bit telling if it supports ATS, which might be
> sufficient in most systems for deciding whether or not we should enable
> the ATS capability in endpoints.

Hmm, the SMMUv3 architecture manual is pretty explicit about this:

  | It [SMMU_IDR0.ATS] does not guarantee that client devices and intermediate
  | components also support ATS and this must be determined separately.

so we may need to extend the PCI bindings to describe this. I think the
negative logic is likely to get in the way if that's the case.

> Signed-off-by: Jean-Philippe Brucker <jean-philippe.brucker@arm.com>
> ---
>  drivers/acpi/arm64/iort.c | 11 +++++++++++
>  include/linux/iommu.h     |  4 ++++
>  2 files changed, 15 insertions(+)
> 
> diff --git a/drivers/acpi/arm64/iort.c b/drivers/acpi/arm64/iort.c
> index e48894e002ba..7f2c1c9c6b38 100644
> --- a/drivers/acpi/arm64/iort.c
> +++ b/drivers/acpi/arm64/iort.c
> @@ -1028,6 +1028,14 @@ void iort_dma_setup(struct device *dev, u64 *dma_addr, u64 *dma_size)
>  	dev_dbg(dev, "dma_pfn_offset(%#08llx)\n", offset);
>  }
>  
> +static bool iort_pci_rc_supports_ats(struct acpi_iort_node *node)
> +{
> +	struct acpi_iort_root_complex *pci_rc;
> +
> +	pci_rc = (struct acpi_iort_root_complex *)node->node_data;
> +	return pci_rc->ats_attribute & ACPI_IORT_ATS_SUPPORTED;
> +}

Do we need to worry about the "noats" command-line option here? It feels
like we should be checking with the PCI subsystem before telling the SMMU
we're good to go.

I'll need Lorenzo's ack on this.

Will

  parent reply	other threads:[~2019-04-15 13:21 UTC|newest]

Thread overview: 32+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-04-09 16:52 [PATCH v2 0/7] Add PCI ATS support to Arm SMMUv3 Jean-Philippe Brucker
2019-04-09 16:52 ` Jean-Philippe Brucker
     [not found] ` <20190409165245.26500-1-jean-philippe.brucker-5wv7dgnIgG8@public.gmane.org>
2019-04-09 16:52   ` [PATCH v2 1/7] ACPI/IORT: Check ATS capability in root complex nodes Jean-Philippe Brucker
2019-04-09 16:52     ` Jean-Philippe Brucker
     [not found]     ` <20190409165245.26500-2-jean-philippe.brucker-5wv7dgnIgG8@public.gmane.org>
2019-04-15 13:21       ` Will Deacon [this message]
2019-04-15 13:21         ` Will Deacon
     [not found]         ` <20190415132108.GB15023-UDVVEH7NWB15pKCnmE3YQBJ8xKzm50AiAL8bYrjMMd8@public.gmane.org>
2019-04-15 18:00           ` Jean-Philippe Brucker
2019-04-15 18:00             ` Jean-Philippe Brucker
2019-04-15 18:31     ` Robin Murphy
2019-04-15 18:31       ` Robin Murphy
     [not found]       ` <c10c7adb-c7f6-f8c6-05cc-f4f143427a2d-5wv7dgnIgG8@public.gmane.org>
2019-04-16 16:27         ` Jean-Philippe Brucker
2019-04-16 16:27           ` Jean-Philippe Brucker
2019-04-09 16:52   ` [PATCH v2 2/7] iommu/arm-smmu-v3: Rename arm_smmu_master_data to arm_smmu_master Jean-Philippe Brucker
2019-04-09 16:52     ` Jean-Philippe Brucker
2019-04-09 16:52   ` [PATCH v2 3/7] iommu/arm-smmu-v3: Store SteamIDs in master Jean-Philippe Brucker
2019-04-09 16:52     ` Jean-Philippe Brucker
2019-04-09 16:52   ` [PATCH v2 4/7] iommu/arm-smmu-v3: Add a master->domain pointer Jean-Philippe Brucker
2019-04-09 16:52     ` Jean-Philippe Brucker
2019-04-09 16:52   ` [PATCH v2 5/7] iommu/arm-smmu-v3: Link domains and devices Jean-Philippe Brucker
2019-04-09 16:52     ` Jean-Philippe Brucker
2019-04-09 16:52   ` [PATCH v2 6/7] iommu/arm-smmu-v3: Add support for PCI ATS Jean-Philippe Brucker
2019-04-09 16:52     ` Jean-Philippe Brucker
     [not found]     ` <20190409165245.26500-7-jean-philippe.brucker-5wv7dgnIgG8@public.gmane.org>
2019-04-15 13:21       ` Will Deacon
2019-04-15 13:21         ` Will Deacon
     [not found]         ` <20190415132121.GC15023-UDVVEH7NWB15pKCnmE3YQBJ8xKzm50AiAL8bYrjMMd8@public.gmane.org>
2019-04-15 18:00           ` Jean-Philippe Brucker
2019-04-15 18:00             ` Jean-Philippe Brucker
     [not found]             ` <0b9b600f-60e0-0740-e1db-6b684bf5a195-5wv7dgnIgG8@public.gmane.org>
2019-04-16 10:00               ` Will Deacon
2019-04-16 10:00                 ` Will Deacon
2019-04-09 16:52   ` [PATCH v2 7/7] iommu/arm-smmu-v3: Disable tagged pointers Jean-Philippe Brucker
2019-04-09 16:52     ` Jean-Philippe Brucker
2019-04-15 13:20   ` [PATCH v2 0/7] Add PCI ATS support to Arm SMMUv3 Will Deacon
2019-04-15 13:20     ` Will Deacon

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=20190415132108.GB15023@fuggles.cambridge.arm.com \
    --to=will.deacon-5wv7dgnigg8@public.gmane.org \
    --cc=iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org \
    --cc=jean-philippe.brucker-5wv7dgnIgG8@public.gmane.org \
    --cc=lenb-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org \
    --cc=linux-acpi-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
    --cc=linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org \
    --cc=okaya-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org \
    --cc=rjw-LthD3rsA81gm4RdzfppkhA@public.gmane.org \
    --cc=robin.murphy-5wv7dgnIgG8@public.gmane.org \
    --cc=sudeep.holla-5wv7dgnIgG8@public.gmane.org \
    --cc=zhongmiao-C8/M+/jPZTeaMJb+Lgu22Q@public.gmane.org \
    /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