linux-arm-kernel.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: lorenzo.pieralisi@arm.com (Lorenzo Pieralisi)
To: linux-arm-kernel@lists.infradead.org
Subject: [RFC PATCH 4/4] ACPI: IORT: Add SMMUv3 MSI support
Date: Fri, 11 Aug 2017 10:33:48 +0100	[thread overview]
Message-ID: <20170811093348.GC26039@red-moon> (raw)
In-Reply-To: <1502276017-63108-5-git-send-email-guohanjun@huawei.com>

On Wed, Aug 09, 2017 at 06:53:37PM +0800, Hanjun Guo wrote:
> From: Hanjun Guo <hanjun.guo@linaro.org>
> 
> Since we have a mapping index for SMMUv3 MSI, we can
> directly use that index to get the map entry, then
> retrieve dev ID and ITS parent to add SMMUv3 MSI
> support.
> 
> Signed-off-by: Hanjun Guo <hanjun.guo@linaro.org>
> ---
>  drivers/acpi/arm64/iort.c | 46 ++++++++++++++++++++++++++++++++++++----------
>  1 file changed, 36 insertions(+), 10 deletions(-)
> 
> diff --git a/drivers/acpi/arm64/iort.c b/drivers/acpi/arm64/iort.c
> index 9439f02..ce03298 100644
> --- a/drivers/acpi/arm64/iort.c
> +++ b/drivers/acpi/arm64/iort.c
> @@ -313,7 +313,8 @@ static int iort_id_map(struct acpi_iort_id_mapping *map, u8 type, u32 rid_in,
>  	/* Single mapping does not care for input id */
>  	if (map->flags & ACPI_IORT_ID_SINGLE_MAPPING) {
>  		if (type == ACPI_IORT_NODE_NAMED_COMPONENT ||
> -		    type == ACPI_IORT_NODE_PCI_ROOT_COMPLEX) {
> +		    type == ACPI_IORT_NODE_PCI_ROOT_COMPLEX ||
> +		    type == ACPI_IORT_NODE_SMMU_V3) {
>  			*rid_out = map->output_base;
>  			return 0;
>  		}
> @@ -357,7 +358,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;
>  		}
> @@ -549,9 +551,21 @@ int iort_pmsi_get_dev_id(struct device *dev, u32 *dev_id)
>  	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))
> +	if (node->type == ACPI_IORT_NODE_SMMU_V3) {
> +		u32 index;
> +
> +		if (iort_get_smmu_v3_id_mapping_index(node, &index))
> +			return -ENODEV;
> +
> +		if (iort_node_map_platform_id(node, dev_id, IORT_MSI_TYPE,
> +		    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;
> @@ -626,20 +640,30 @@ static struct irq_domain *iort_get_platform_device_domain(struct device *dev)
>  	struct acpi_iort_node *node, *msi_parent;
>  	struct fwnode_handle *iort_fwnode;
>  	struct acpi_iort_its_group *its;
> -	int i;
>  
>  	/* find its associated iort node */
> -	node = iort_scan_node(ACPI_IORT_NODE_NAMED_COMPONENT,
> -			      iort_match_node_callback, dev);
> +	node = iort_find_dev_node(dev);
>  	if (!node)
>  		return NULL;
>  
>  	/* then find its msi parent node */
> -	for (i = 0; i < node->mapping_count; i++) {
> +	if (node->type == ACPI_IORT_NODE_SMMU_V3) {
> +		u32 index;
> +
> +		if (iort_get_smmu_v3_id_mapping_index(node, &index))
> +			return NULL;
> +
>  		msi_parent = iort_node_map_platform_id(node, NULL,
> +						       IORT_MSI_TYPE, index);
> +	} else {
> +		int i;
> +
> +		for (i = 0; i < node->mapping_count; i++) {
> +			msi_parent = iort_node_map_platform_id(node, NULL,
>  						       IORT_MSI_TYPE, i);
> -		if (msi_parent)
> -			break;
> +			if (msi_parent)
> +				break;
> +		}
>  	}
>  
>  	if (!msi_parent)
> @@ -1233,6 +1257,8 @@ static int __init iort_add_smmu_platform_device(struct acpi_iort_node *node)
>  	/* Configure DMA for the page table walker */
>  	acpi_dma_configure(&pdev->dev, attr);
>  
> +	acpi_configure_pmsi_domain(&pdev->dev);

I think this is just overkill. There are two separate things to solve
here:

1) Make single mappings valid for SMMUv3 (and PMCG); that's fair enough
   and goes with the logic to skip the ITS DeviceID index for "normal"
   mappings, I can live with that
2) Find the MSI domain for an SMMUv3 (or any other IORT table node); I
   do not think you need all this complexity to do it via
   acpi_configure_pmsi_domain(), it can be done in a easier way with
   an ad-hoc stub (it does not even have to be SMMUv3 specific)

My worry is that we are peppering the generic IORT mapping code with
node types specific kludges and it is becoming a mess.

I can rework the patch to show you what I have in mind, please let
me know.

Thanks,
Lorenzo

> +
>  	ret = platform_device_add(pdev);
>  	if (ret)
>  		goto dma_deconfigure;
> -- 
> 1.7.12.4
> 

  reply	other threads:[~2017-08-11  9:33 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-08-09 10:53 [RFC PATCH 0/4] SMMUv3 MSI support Hanjun Guo
2017-08-09 10:53 ` [RFC PATCH 1/4] ACPICA: Add SMMUv3 device ID mapping index support Hanjun Guo
2017-08-09 10:53 ` [RFC PATCH 2/4] ACPI: IORT: lookup iort node via fwnode Hanjun Guo
2017-08-09 10:53 ` [RFC PATCH 3/4] ACPI: IORT: Skip SMMUv3 device ID map for two steps mappings Hanjun Guo
2017-08-09 11:50   ` Robin Murphy
2017-08-09 14:48     ` Hanjun Guo
2017-08-09 17:12       ` Lorenzo Pieralisi
2017-08-10  9:41         ` Hanjun Guo
2017-08-15 17:13   ` Lorenzo Pieralisi
2017-08-09 10:53 ` [RFC PATCH 4/4] ACPI: IORT: Add SMMUv3 MSI support Hanjun Guo
2017-08-11  9:33   ` Lorenzo Pieralisi [this message]
2017-08-11 13:56     ` Hanjun Guo
2017-08-15 17:15       ` Lorenzo Pieralisi
2017-08-17  7:49         ` Hanjun Guo
2017-08-17 13:01           ` Lorenzo Pieralisi
2017-09-12  3:27             ` Hanjun Guo
2017-09-12 15:51               ` 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=20170811093348.GC26039@red-moon \
    --to=lorenzo.pieralisi@arm.com \
    --cc=linux-arm-kernel@lists.infradead.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;
as well as URLs for NNTP newsgroup(s).