linux-arm-kernel.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: laurent.pinchart@ideasonboard.com (Laurent Pinchart)
To: linux-arm-kernel@lists.infradead.org
Subject: [RFC PATCH v3 4/7] iommu: provide helper function to configure an IOMMU for an of master
Date: Thu, 18 Sep 2014 14:13:13 +0300	[thread overview]
Message-ID: <4801495.ovhjCBfpBC@avalon> (raw)
In-Reply-To: <1410539695-29128-5-git-send-email-will.deacon@arm.com>

Hi Will,

Thank you for the patch.

On Friday 12 September 2014 17:34:52 Will Deacon wrote:
> The generic IOMMU device-tree bindings can be used to add arbitrary OF
> masters to an IOMMU with a compliant binding.
> 
> This patch introduces of_iommu_configure, which does exactly that. A
> list of iommu_dma_mapping structures are created for each device, which
> represent the set of IOMMU instances through which the device can
> master. The list is protected by a kref count and freed when no users
> remain. It is expected that DMA-mapping code will take a reference if it
> wishes to make use of the IOMMU information.
> 
> Signed-off-by: Will Deacon <will.deacon@arm.com>
> ---
>  drivers/iommu/Kconfig       |  2 +-
>  drivers/iommu/of_iommu.c    | 70 ++++++++++++++++++++++++++++++++++++++++++
>  include/linux/dma-mapping.h |  8 ++++++
>  include/linux/of_iommu.h    | 10 +++++++
>  4 files changed, 89 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/iommu/Kconfig b/drivers/iommu/Kconfig
> index dd5112265cc9..6d13f962f156 100644
> --- a/drivers/iommu/Kconfig
> +++ b/drivers/iommu/Kconfig
> @@ -15,7 +15,7 @@ if IOMMU_SUPPORT
> 
>  config OF_IOMMU
>         def_bool y
> -       depends on OF
> +       depends on OF && IOMMU_API
> 
>  config FSL_PAMU
>  	bool "Freescale IOMMU support"
> diff --git a/drivers/iommu/of_iommu.c b/drivers/iommu/of_iommu.c
> index 13d800c4ce25..8656b63f27ee 100644
> --- a/drivers/iommu/of_iommu.c
> +++ b/drivers/iommu/of_iommu.c
> @@ -18,9 +18,11 @@
>   */
> 
>  #include <linux/export.h>
> +#include <linux/iommu.h>
>  #include <linux/limits.h>
>  #include <linux/of.h>
>  #include <linux/of_iommu.h>
> +#include <linux/slab.h>
> 
>  /**
>   * of_get_dma_window - Parse *dma-window property and returns 0 if found.
> @@ -90,6 +92,74 @@ int of_get_dma_window(struct device_node *dn, const char
> *prefix, int index, }
>  EXPORT_SYMBOL_GPL(of_get_dma_window);
> 
> +struct iommu_dma_mapping *of_iommu_configure(struct device *dev)
> +{
> +	struct of_phandle_args iommu_spec;
> +	struct iommu_dma_mapping *mapping;
> +	struct device_node *np;
> +	struct iommu_data *iommu = NULL;
> +	int idx = 0;
> +
> +	/*
> +	 * We don't currently walk up the tree looking for a parent IOMMU.
> +	 * See the `Notes:' section of
> +	 * Documentation/devicetree/bindings/iommu/iommu.txt
> +	 */
> +	while (!of_parse_phandle_with_args(dev->of_node, "iommus",
> +					   "#iommu-cells", idx,
> +					   &iommu_spec)) {
> +		struct iommu_data *data;
> +
> +		np = iommu_spec.np;
> +		data = of_iommu_get_data(np);
> +
> +		if (!data || !data->ops || !data->ops->of_xlate)
> +			goto err_put_node;
> +
> +		if (!iommu) {
> +			iommu = data;
> +		} else if (iommu != data) {
> +			/* We don't currently support multi-IOMMU masters */
> +			pr_warn("Rejecting device %s with multiple IOMMU instances\n",
> +				dev_name(dev));
> +			goto err_put_node;
> +		}
> +
> +		if (!data->ops->of_xlate(dev, &iommu_spec))
> +			goto err_put_node;
> +
> +		of_node_put(np);
> +		idx++;
> +	}
> +
> +	if (!iommu)
> +		return NULL;
> +
> +	mapping = kzalloc(sizeof(*mapping), GFP_KERNEL);
> +	if (!mapping)
> +		return NULL;
> +
> +	kref_init(&mapping->kref);
> +	INIT_LIST_HEAD(&mapping->node);

I might be missing something, but that doesn't seem to match the commit 
message. This creates a single iommu_dma_mapping per device, where is the list 
supposed to be populated ?

> +	mapping->iommu = iommu;
> +	return mapping;
> +
> +err_put_node:
> +	of_node_put(np);
> +	return NULL;
> +}
> +
> +void of_iommu_deconfigure(struct kref *kref)
> +{
> +	struct iommu_dma_mapping *mapping, *curr, *next;
> +
> +	mapping = container_of(kref, struct iommu_dma_mapping, kref);
> +	list_for_each_entry_safe(curr, next, &mapping->node, node) {
> +		list_del(&curr->node);
> +		kfree(curr);
> +	}

Don't you need to also kfree(mapping) here ?

> +}
> +

Do you expect other users of of_iommu_deconfigure() than kref_put() ? If not, 
how about exposing an of_iommu_put(struct iommu_dma_mapping *) that would call 
kref_put() internally, and hiding of_iommu_deconfigure() ?

>  void __init of_iommu_init(void)
>  {
>  	struct device_node *np;
> diff --git a/include/linux/dma-mapping.h b/include/linux/dma-mapping.h
> index 1e944e77d38d..e60e52d82db9 100644
> --- a/include/linux/dma-mapping.h
> +++ b/include/linux/dma-mapping.h
> @@ -62,6 +62,14 @@ struct dma_map_ops {
>  	int is_phys;
>  };
> 
> +struct iommu_data;
> +
> +struct iommu_dma_mapping {
> +	struct iommu_data *iommu;
> +	struct list_head node;
> +	struct kref kref;
> +};

Could you please document the structure with kerneldoc ?

> +
>  #define DMA_BIT_MASK(n)	(((n) == 64) ? ~0ULL : ((1ULL<<(n))-1))
> 
>  #define DMA_MASK_NONE	0x0ULL
> diff --git a/include/linux/of_iommu.h b/include/linux/of_iommu.h
> index 0a685e0ab33e..af6179557005 100644
> --- a/include/linux/of_iommu.h
> +++ b/include/linux/of_iommu.h
> @@ -1,9 +1,12 @@
>  #ifndef __OF_IOMMU_H
>  #define __OF_IOMMU_H
> 
> +#include <linux/device.h>
>  #include <linux/iommu.h>
>  #include <linux/of.h>
> 
> +struct iommu_dma_mapping;
> +
>  #ifdef CONFIG_OF_IOMMU
> 
>  extern int of_get_dma_window(struct device_node *dn, const char *prefix,
> @@ -11,6 +14,8 @@ extern int of_get_dma_window(struct device_node *dn, const
> char *prefix, size_t *size);
> 
>  extern void of_iommu_init(void);
> +extern struct iommu_dma_mapping *of_iommu_configure(struct device *dev);
> +extern void of_iommu_deconfigure(struct kref *kref);
> 
>  #else
> 
> @@ -22,6 +27,11 @@ static inline int of_get_dma_window(struct device_node
> *dn, const char *prefix, }
> 
>  static inline void of_iommu_init(void) { }
> +static inline struct iommu_dma_mapping *of_iommu_configure(struct device
> *dev) +{
> +	return NULL;
> +}
> +static inline void of_iommu_deconfigure(struct kref *kref) { }
> 
>  #endif	/* CONFIG_OF_IOMMU */

-- 
Regards,

Laurent Pinchart

  reply	other threads:[~2014-09-18 11:13 UTC|newest]

Thread overview: 52+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-09-12 16:34 [RFC PATCH v3 0/7] Introduce automatic DMA configuration for IOMMU masters Will Deacon
2014-09-12 16:34 ` [RFC PATCH v3 1/7] iommu: provide early initialisation hook for IOMMU drivers Will Deacon
2014-09-18 14:31   ` Robin Murphy
2014-09-22 17:35     ` Will Deacon
2014-09-12 16:34 ` [RFC PATCH v3 2/7] dma-mapping: replace set_arch_dma_coherent_ops with arch_setup_dma_ops Will Deacon
2014-09-12 16:34 ` [RFC PATCH v3 3/7] iommu: add new iommu_ops callback for adding an OF device Will Deacon
2014-09-15 11:57   ` Marek Szyprowski
2014-09-17  1:39     ` Will Deacon
2014-09-12 16:34 ` [RFC PATCH v3 4/7] iommu: provide helper function to configure an IOMMU for an of master Will Deacon
2014-09-18 11:13   ` Laurent Pinchart [this message]
2014-09-22 17:13     ` Will Deacon
2014-10-14 13:12       ` Laurent Pinchart
2014-09-12 16:34 ` [RFC PATCH v3 5/7] dma-mapping: detect and configure IOMMU in of_dma_configure Will Deacon
2014-09-18 11:17   ` Laurent Pinchart
2014-09-22  9:29     ` Thierry Reding
2014-09-22 17:50       ` Will Deacon
2014-10-14 12:53         ` Laurent Pinchart
2014-10-27 10:51           ` Will Deacon
2014-10-27 11:12             ` Marek Szyprowski
2014-10-27 11:30             ` Laurent Pinchart
2014-10-27 16:02               ` Will Deacon
2014-10-27 16:33                 ` jroedel at suse.de
2014-09-22 17:46     ` Will Deacon
2014-09-12 16:34 ` [RFC PATCH v3 6/7] arm: call iommu_init before of_platform_populate Will Deacon
2014-09-22  9:36   ` Thierry Reding
2014-09-22 11:08     ` Arnd Bergmann
2014-09-22 11:40       ` Thierry Reding
2014-09-22 16:03         ` Arnd Bergmann
2014-09-23  7:02           ` Thierry Reding
2014-09-23  7:44             ` Arnd Bergmann
2014-09-23  8:59               ` Thierry Reding
2014-10-14 13:07               ` Laurent Pinchart
2014-10-14 13:20                 ` Arnd Bergmann
2014-10-14 13:37                   ` Thierry Reding
2014-10-14 15:01                     ` Laurent Pinchart
2014-10-14 15:05                       ` Thierry Reding
2014-10-14 15:10                         ` Laurent Pinchart
2014-09-12 16:34 ` [RFC PATCH v3 7/7] arm: dma-mapping: plumb our iommu mapping ops into arch_setup_dma_ops Will Deacon
2014-09-22  9:19   ` Thierry Reding
2014-09-22  9:22     ` Laurent Pinchart
2014-09-22 17:43     ` Will Deacon
2014-09-23  7:14       ` Thierry Reding
2014-09-24 16:33         ` Will Deacon
2014-09-25  6:40           ` Thierry Reding
2014-09-30 16:00             ` Will Deacon
2014-10-01  8:46               ` Thierry Reding
2014-10-03 15:08                 ` Will Deacon
2014-10-06  9:52                   ` Thierry Reding
2014-10-06 10:50                     ` Laurent Pinchart
2014-10-06 13:05                       ` Thierry Reding
2014-09-16 11:40 ` [RFC PATCH v3 0/7] Introduce automatic DMA configuration for IOMMU masters Robin Murphy
2014-09-17  1:19   ` 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=4801495.ovhjCBfpBC@avalon \
    --to=laurent.pinchart@ideasonboard.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).