linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Robin Murphy <robin.murphy@arm.com>
To: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>,
	iommu@lists.linux-foundation.org
Cc: Will Deacon <will.deacon@arm.com>, Joerg Roedel <joro@8bytes.org>,
	Marc Zyngier <marc.zyngier@arm.com>,
	"Rafael J. Wysocki" <rjw@rjwysocki.net>,
	Tomasz Nowicki <tn@semihalf.com>,
	Hanjun Guo <hanjun.guo@linaro.org>, Jon Masters <jcm@redhat.com>,
	Eric Auger <eric.auger@redhat.com>,
	Sinan Kaya <okaya@codeaurora.org>,
	Nate Watterson <nwatters@codeaurora.org>,
	Prem Mallappa <prem.mallappa@broadcom.com>,
	Dennis Chen <dennis.chen@arm.com>,
	linux-acpi@vger.kernel.org, linux-pci@vger.kernel.org,
	linux-kernel@vger.kernel.org,
	linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH v8 13/16] drivers: iommu: arm-smmu: add IORT configuration
Date: Fri, 18 Nov 2016 17:36:46 +0000	[thread overview]
Message-ID: <83df7dba-8d04-96ae-f59b-b0d484085e12@arm.com> (raw)
In-Reply-To: <20161116152936.22955-14-lorenzo.pieralisi@arm.com>

On 16/11/16 15:29, Lorenzo Pieralisi wrote:
> In ACPI bases systems, in order to be able to create platform

          based?

> devices and initialize them for ARM SMMU components, the IORT
> kernel implementation requires a set of static functions to be
> used by the IORT kernel layer to configure platform devices for
> ARM SMMU components.
> 
> Add static configuration functions to the IORT kernel layer for
> the ARM SMMU components, so that the ARM SMMU driver can
> initialize its respective platform device by relying on the IORT
> kernel infrastructure and by adding a corresponding ACPI device
> early probe section entry.
> 
> Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
> Reviewed-by: Tomasz Nowicki <tn@semihalf.com>
> Tested-by: Hanjun Guo <hanjun.guo@linaro.org>
> Tested-by: Tomasz Nowicki <tn@semihalf.com>
> Cc: Will Deacon <will.deacon@arm.com>
> Cc: Robin Murphy <robin.murphy@arm.com>
> Cc: Joerg Roedel <joro@8bytes.org>
> ---
>  drivers/acpi/arm64/iort.c | 81 +++++++++++++++++++++++++++++++++++++++++++++
>  drivers/iommu/arm-smmu.c  | 83 ++++++++++++++++++++++++++++++++++++++++++++++-
>  include/linux/acpi_iort.h |  3 ++
>  3 files changed, 166 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/acpi/arm64/iort.c b/drivers/acpi/arm64/iort.c
> index fd52e4c..4708806 100644
> --- a/drivers/acpi/arm64/iort.c
> +++ b/drivers/acpi/arm64/iort.c
> @@ -548,6 +548,78 @@ static bool __init arm_smmu_v3_is_coherent(struct acpi_iort_node *node)
>  	return smmu->flags & ACPI_IORT_SMMU_V3_COHACC_OVERRIDE;
>  }
>  
> +static int __init arm_smmu_count_resources(struct acpi_iort_node *node)
> +{
> +	struct acpi_iort_smmu *smmu;
> +	int num_irqs;
> +	u64 *glb_irq;
> +
> +	/* Retrieve SMMU specific data */
> +	smmu = (struct acpi_iort_smmu *)node->node_data;
> +
> +	glb_irq = ACPI_ADD_PTR(u64, node, smmu->global_interrupt_offset);
> +	if (!IORT_IRQ_MASK(glb_irq[1]))	/* 0 means not implemented */
> +		num_irqs = 1;
> +	else
> +		num_irqs = 2;

Do we actually need this - I mean, the configuration access interrupt is
of somewhat limited utility, implementation-defined, and we don't have
any handling for it. Nor should it, if present, ever happen anyway,
since it's not like anyone else should be randomly poking our SMMU in
invalid ways. Can we simply ignore it?

> +
> +	num_irqs += smmu->context_interrupt_count;
> +
> +	return num_irqs + 1;
> +}
> +
> +static void __init arm_smmu_init_resources(struct resource *res,
> +					   struct acpi_iort_node *node)
> +{
> +	struct acpi_iort_smmu *smmu;
> +	int i, hw_irq, trigger, num_res = 0;
> +	u64 *ctx_irq, *glb_irq;
> +
> +	/* Retrieve SMMU specific data */
> +	smmu = (struct acpi_iort_smmu *)node->node_data;
> +
> +	res[num_res].start = smmu->base_address;
> +	res[num_res].end = smmu->base_address + smmu->span - 1;
> +	res[num_res].flags = IORESOURCE_MEM;
> +	num_res++;
> +
> +	glb_irq = ACPI_ADD_PTR(u64, node, smmu->global_interrupt_offset);
> +	/* Global IRQs */
> +	hw_irq = IORT_IRQ_MASK(glb_irq[0]);
> +	trigger = IORT_IRQ_TRIGGER_MASK(glb_irq[0]);
> +
> +	acpi_iort_register_irq(hw_irq, "arm-smmu-global", trigger,
> +				     &res[num_res++]);
> +
> +	/* Global IRQs */
> +	hw_irq = IORT_IRQ_MASK(glb_irq[1]);
> +	if (hw_irq) {
> +		trigger = IORT_IRQ_TRIGGER_MASK(glb_irq[1]);
> +		acpi_iort_register_irq(hw_irq, "arm-smmu-global", trigger,
> +					     &res[num_res++]);
> +	}

Related to the above, I think the driver generally assumes these to be
the global fault interrupt. If we *are* going to claim the config
interrupt as well, we should probably disambiguate them, although
admittedly we can't really do that retrospectively on the DT side.

> +
> +	/* Context IRQs */
> +	ctx_irq = ACPI_ADD_PTR(u64, node, smmu->context_interrupt_offset);
> +	for (i = 0; i < smmu->context_interrupt_count; i++) {
> +		hw_irq = IORT_IRQ_MASK(ctx_irq[i]);
> +		trigger = IORT_IRQ_TRIGGER_MASK(ctx_irq[i]);
> +
> +		acpi_iort_register_irq(hw_irq, "arm-smmu-context", trigger,
> +				       &res[num_res++]);
> +	}
> +}
> +
> +static bool __init arm_smmu_is_coherent(struct acpi_iort_node *node)
> +{
> +	struct acpi_iort_smmu *smmu;
> +
> +	/* Retrieve SMMU specific data */
> +	smmu = (struct acpi_iort_smmu *)node->node_data;
> +
> +	return smmu->flags & ACPI_IORT_SMMU_COHERENT_WALK;
> +}
> +
>  struct iort_iommu_config {
>  	const char *name;
>  	int (*iommu_init)(struct acpi_iort_node *node);
> @@ -564,12 +636,21 @@ static const struct iort_iommu_config iort_arm_smmu_v3_cfg __initconst = {
>  	.iommu_init_resources = arm_smmu_v3_init_resources
>  };
>  
> +static const struct iort_iommu_config iort_arm_smmu_cfg __initconst = {
> +	.name = "arm-smmu",
> +	.iommu_is_coherent = arm_smmu_is_coherent,
> +	.iommu_count_resources = arm_smmu_count_resources,
> +	.iommu_init_resources = arm_smmu_init_resources
> +};
> +
>  static __init
>  const struct iort_iommu_config *iort_get_iommu_cfg(struct acpi_iort_node *node)
>  {
>  	switch (node->type) {
>  	case ACPI_IORT_NODE_SMMU_V3:
>  		return &iort_arm_smmu_v3_cfg;
> +	case ACPI_IORT_NODE_SMMU:
> +		return &iort_arm_smmu_cfg;
>  	default:
>  		return NULL;
>  	}
> diff --git a/drivers/iommu/arm-smmu.c b/drivers/iommu/arm-smmu.c
> index 573b2b6..21d1892 100644
> --- a/drivers/iommu/arm-smmu.c
> +++ b/drivers/iommu/arm-smmu.c
> @@ -28,6 +28,8 @@
>  
>  #define pr_fmt(fmt) "arm-smmu: " fmt
>  
> +#include <linux/acpi.h>
> +#include <linux/acpi_iort.h>
>  #include <linux/atomic.h>
>  #include <linux/delay.h>
>  #include <linux/dma-iommu.h>
> @@ -1904,6 +1906,70 @@ static const struct of_device_id arm_smmu_of_match[] = {
>  };
>  MODULE_DEVICE_TABLE(of, arm_smmu_of_match);
>  
> +#ifdef CONFIG_ACPI
> +static int acpi_smmu_get_data(u32 model, u32 *version, u32 *impl)
> +{
> +	int ret = 0;
> +
> +	switch (model) {
> +	case ACPI_IORT_SMMU_V1:
> +	case ACPI_IORT_SMMU_CORELINK_MMU400:
> +		*version = ARM_SMMU_V1;
> +		*impl = GENERIC_SMMU;

Further to Will's comment, I'd say just pass the smmu pointer in and set
the fields explicitly here.

Robin.

> +		break;
> +	case ACPI_IORT_SMMU_V2:
> +		*version = ARM_SMMU_V2;
> +		*impl = GENERIC_SMMU;
> +		break;
> +	case ACPI_IORT_SMMU_CORELINK_MMU500:
> +		*version = ARM_SMMU_V2;
> +		*impl = ARM_MMU500;
> +		break;
> +	default:
> +		ret = -ENODEV;
> +	}
> +
> +	return ret;
> +}
> +
> +static int arm_smmu_device_acpi_probe(struct platform_device *pdev,
> +				      struct arm_smmu_device *smmu)
> +{
> +	struct device *dev = smmu->dev;
> +	struct acpi_iort_node *node =
> +		*(struct acpi_iort_node **)dev_get_platdata(dev);
> +	struct acpi_iort_smmu *iort_smmu;
> +	u64 *glb_irq;
> +	int ret;
> +
> +	/* Retrieve SMMU1/2 specific data */
> +	iort_smmu = (struct acpi_iort_smmu *)node->node_data;
> +
> +	ret = acpi_smmu_get_data(iort_smmu->model, &smmu->version,
> +						   &smmu->model);
> +	if (ret < 0)
> +		return ret;
> +
> +	glb_irq = ACPI_ADD_PTR(u64, node, iort_smmu->global_interrupt_offset);
> +
> +	if (!IORT_IRQ_MASK(glb_irq[1]))	/* 0 means not implemented */
> +		smmu->num_global_irqs = 1;
> +	else
> +		smmu->num_global_irqs = 2;
> +
> +	if (iort_smmu->flags & ACPI_IORT_SMMU_COHERENT_WALK)
> +		smmu->features |= ARM_SMMU_FEAT_COHERENT_WALK;
> +
> +	return 0;
> +}
> +#else
> +static inline int arm_smmu_device_acpi_probe(struct platform_device *pdev,
> +					     struct arm_smmu_device *smmu)
> +{
> +	return -ENODEV;
> +}
> +#endif
> +
>  static int arm_smmu_device_dt_probe(struct platform_device *pdev,
>  				    struct arm_smmu_device *smmu)
>  {
> @@ -1955,7 +2021,11 @@ static int arm_smmu_device_probe(struct platform_device *pdev)
>  	}
>  	smmu->dev = dev;
>  
> -	err = arm_smmu_device_dt_probe(pdev, smmu);
> +	if (dev->of_node)
> +		err = arm_smmu_device_dt_probe(pdev, smmu);
> +	else
> +		err = arm_smmu_device_acpi_probe(pdev, smmu);
> +
>  	if (err)
>  		return err;
>  
> @@ -2103,6 +2173,17 @@ IOMMU_OF_DECLARE(arm_mmu401, "arm,mmu-401", arm_smmu_of_init);
>  IOMMU_OF_DECLARE(arm_mmu500, "arm,mmu-500", arm_smmu_of_init);
>  IOMMU_OF_DECLARE(cavium_smmuv2, "cavium,smmu-v2", arm_smmu_of_init);
>  
> +#ifdef CONFIG_ACPI
> +static int __init arm_smmu_acpi_init(struct acpi_table_header *table)
> +{
> +	if (iort_node_match(ACPI_IORT_NODE_SMMU))
> +		return arm_smmu_init();
> +
> +	return 0;
> +}
> +IORT_ACPI_DECLARE(arm_smmu, ACPI_SIG_IORT, arm_smmu_acpi_init);
> +#endif
> +
>  MODULE_DESCRIPTION("IOMMU API for ARM architected SMMU implementations");
>  MODULE_AUTHOR("Will Deacon <will.deacon@arm.com>");
>  MODULE_LICENSE("GPL v2");
> diff --git a/include/linux/acpi_iort.h b/include/linux/acpi_iort.h
> index 17bb078..79ba1bb 100644
> --- a/include/linux/acpi_iort.h
> +++ b/include/linux/acpi_iort.h
> @@ -23,6 +23,9 @@
>  #include <linux/fwnode.h>
>  #include <linux/irqdomain.h>
>  
> +#define IORT_IRQ_MASK(irq)		(irq & 0xffffffffULL)
> +#define IORT_IRQ_TRIGGER_MASK(irq)	((irq >> 32) & 0xffffffffULL)
> +
>  int iort_register_domain_token(int trans_id, struct fwnode_handle *fw_node);
>  void iort_deregister_domain_token(int trans_id);
>  struct fwnode_handle *iort_find_domain_token(int trans_id);
> 

  parent reply	other threads:[~2016-11-18 17:36 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-11-16 15:29 [PATCH v8 00/16] ACPI IORT ARM SMMU support Lorenzo Pieralisi
2016-11-16 15:29 ` [PATCH v8 01/16] drivers: acpi: add FWNODE_ACPI_STATIC fwnode type Lorenzo Pieralisi
2016-11-16 15:29 ` [PATCH v8 02/16] drivers: acpi: iort: introduce linker section for IORT entries probing Lorenzo Pieralisi
2016-11-16 15:29 ` [PATCH v8 03/16] drivers: acpi: iort: add support for IOMMU fwnode registration Lorenzo Pieralisi
2016-11-16 15:29 ` [PATCH v8 04/16] drivers: iommu: make of_iommu_set/get_ops() DT agnostic Lorenzo Pieralisi
2016-11-18 14:49   ` Will Deacon
2016-11-16 15:29 ` [PATCH v8 05/16] drivers: iommu: arm-smmu: convert struct device of_node to fwnode usage Lorenzo Pieralisi
2016-11-18 14:49   ` Will Deacon
2016-11-16 15:29 ` [PATCH v8 06/16] drivers: iommu: arm-smmu-v3: " Lorenzo Pieralisi
2016-11-18 14:50   ` Will Deacon
2016-11-16 15:29 ` [PATCH v8 07/16] drivers: acpi: implement acpi_dma_configure Lorenzo Pieralisi
2016-11-16 15:29 ` [PATCH v8 08/16] drivers: acpi: iort: add node match function Lorenzo Pieralisi
2016-11-16 15:29 ` [PATCH v8 09/16] drivers: acpi: iort: add support for ARM SMMU platform devices creation Lorenzo Pieralisi
2016-11-16 15:29 ` [PATCH v8 10/16] drivers: iommu: arm-smmu-v3: split probe functions into DT/generic portions Lorenzo Pieralisi
2016-11-18 15:44   ` Will Deacon
2016-11-16 15:29 ` [PATCH v8 11/16] drivers: iommu: arm-smmu-v3: add IORT configuration Lorenzo Pieralisi
2016-11-18 15:55   ` Will Deacon
2016-11-16 15:29 ` [PATCH v8 12/16] drivers: iommu: arm-smmu: split probe functions into DT/generic portions Lorenzo Pieralisi
2016-11-18 16:00   ` Will Deacon
2016-11-18 16:43     ` Robin Murphy
2016-11-16 15:29 ` [PATCH v8 13/16] drivers: iommu: arm-smmu: add IORT configuration Lorenzo Pieralisi
2016-11-18 16:08   ` Will Deacon
2016-11-18 17:36   ` Robin Murphy [this message]
2016-11-18 18:03     ` Lorenzo Pieralisi
2016-11-16 15:29 ` [PATCH v8 14/16] drivers: acpi: iort: replace rid map type with type mask Lorenzo Pieralisi
2016-11-16 15:29 ` [PATCH v8 15/16] drivers: acpi: iort: add single mapping function Lorenzo Pieralisi
2016-11-16 15:29 ` [PATCH v8 16/16] drivers: acpi: iort: introduce iort_iommu_configure Lorenzo Pieralisi

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=83df7dba-8d04-96ae-f59b-b0d484085e12@arm.com \
    --to=robin.murphy@arm.com \
    --cc=dennis.chen@arm.com \
    --cc=eric.auger@redhat.com \
    --cc=hanjun.guo@linaro.org \
    --cc=iommu@lists.linux-foundation.org \
    --cc=jcm@redhat.com \
    --cc=joro@8bytes.org \
    --cc=linux-acpi@vger.kernel.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pci@vger.kernel.org \
    --cc=lorenzo.pieralisi@arm.com \
    --cc=marc.zyngier@arm.com \
    --cc=nwatters@codeaurora.org \
    --cc=okaya@codeaurora.org \
    --cc=prem.mallappa@broadcom.com \
    --cc=rjw@rjwysocki.net \
    --cc=tn@semihalf.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 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).