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 4/7] iommu: provide helper function to configure an IOMMU for an of master
Date: Tue, 02 Sep 2014 22:08:58 +0300	[thread overview]
Message-ID: <1706598.u5HumTdOPu@avalon> (raw)
In-Reply-To: <20140902110340.GI25379@arm.com>

Hi Will,

On Tuesday 02 September 2014 12:03:40 Will Deacon wrote:
> On Tue, Sep 02, 2014 at 11:51:54AM +0100, Laurent Pinchart wrote:
> > On Friday 29 August 2014 16:54:27 Will Deacon wrote:

[snip]

> > > diff --git a/drivers/iommu/of_iommu.c b/drivers/iommu/of_iommu.c
> > > index f9209666157c..a7d3b3a13b83 100644
> > > --- a/drivers/iommu/of_iommu.c
> > > +++ b/drivers/iommu/of_iommu.c

[snip]

> > > @@ -90,6 +91,41 @@ int of_get_dma_window(struct device_node *dn, const
> > > char
> > > *prefix, int index, }
> > > 
> > >  EXPORT_SYMBOL_GPL(of_get_dma_window);
> > > 
> > > +int of_iommu_configure(struct device *dev)
> > > +{
> > > +	struct of_phandle_args iommu_spec;
> > > +	struct bus_type *bus = dev->bus;
> > > +	const struct iommu_ops *ops = bus->iommu_ops;
> > > +	int ret = -EINVAL, idx = 0;
> > > +
> > > +	if (!iommu_present(bus))
> > > +		return -ENODEV;
> > > +
> > > +	/*
> > > +	 * 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)) {
> > > +		void *data = of_iommu_get_data(iommu_spec.np);
> > > +
> > > +		of_node_put(iommu_spec.np);
> > > +		if (!ops->add_device_master_ids)
> > > +			return -ENODEV;
> > 
> > Can't you move this outside of the loop ?
> 
> Yup, done.
> 
> > > +
> > > +		ret = ops->add_device_master_ids(dev, iommu_spec.args_count,
> > > +						 iommu_spec.args, data);
> > 
> > I'm curious, how do you envision support for devices connected to multiple
> > IOMMUs ? IOMMU drivers usually allocate a per-device archdata structure in
> > the add_device operation and store it in the dev->archdata.iommu field.
> > How would that work with multiple invocations of add_device or
> > add_device_master_ids ?
>
> Even devices with a single IOMMU could have multiple callbacks, since the
> IOMMU gets called back once per ID in reality. That means the IOMMU drivers
> will need to be tolerant of adding a master they already know about (by
> looking up the device and adding the additional IDs).

That wouldn't be too difficult to implement in IOMMU drivers, but I have a 
feeling we would duplicate the same logic in several drivers. Adding fields to 
struct iommu (possibly with a couple of helper functions) as mentioned below 
might help. Another option would be to call the add_device_master_ids a single 
time with a list of all ids, but the core code might become pretty ugly.

> Once I've reworked the data argument to be a struct iommu, we can add fields
> there if they're generally useful.

-- 
Regards,

Laurent Pinchart

  reply	other threads:[~2014-09-02 19:08 UTC|newest]

Thread overview: 51+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-08-29 15:54 [RFC PATCH 0/7] Introduce automatic DMA configuration for IOMMU masters Will Deacon
2014-08-29 15:54 ` [RFC PATCH 1/7] iommu: provide early initialisation hook for IOMMU drivers Will Deacon
2014-09-01  7:52   ` Thierry Reding
2014-09-01 14:31     ` Arnd Bergmann
2014-09-01 16:36       ` Will Deacon
2014-09-02  6:56     ` Laurent Pinchart
2014-09-02 14:47   ` Varun Sethi
2014-09-02 15:04     ` Arnd Bergmann
2014-08-29 15:54 ` [RFC PATCH 2/7] dma-mapping: replace set_arch_dma_coherent_ops with arch_setup_dma_ops Will Deacon
2014-09-01 14:27   ` Arnd Bergmann
2014-09-01 16:20     ` Will Deacon
2014-08-29 15:54 ` [RFC PATCH 3/7] iommu: add new iommu_ops callback for adding a device with a set of IDs Will Deacon
2014-09-01  8:13   ` Thierry Reding
2014-09-01 14:39     ` Arnd Bergmann
2014-09-01 16:34       ` Will Deacon
2014-09-01 17:18         ` Arnd Bergmann
2014-08-29 15:54 ` [RFC PATCH 4/7] iommu: provide helper function to configure an IOMMU for an of master Will Deacon
2014-09-01  8:29   ` Thierry Reding
2014-09-01 14:46     ` Arnd Bergmann
2014-09-01 16:40       ` Will Deacon
2014-09-01 20:18         ` Arnd Bergmann
2014-09-02 10:03           ` Will Deacon
2014-09-02 12:15             ` Arnd Bergmann
2014-09-02 13:05               ` Will Deacon
2014-09-02 14:01                 ` Arnd Bergmann
2014-09-02 20:59                   ` jroedel at suse.de
2014-09-03  9:45                     ` Will Deacon
2014-09-02 15:03               ` Varun Sethi
2014-09-02 15:08                 ` Arnd Bergmann
2014-09-02 10:23       ` Laurent Pinchart
2014-09-02 10:51   ` Laurent Pinchart
2014-09-02 11:03     ` Will Deacon
2014-09-02 19:08       ` Laurent Pinchart [this message]
2014-09-02 14:55   ` Varun Sethi
2014-08-29 15:54 ` [RFC PATCH 5/7] dma-mapping: detect and configure IOMMU in of_dma_configure Will Deacon
2014-09-01 14:53   ` Arnd Bergmann
2014-08-29 15:54 ` [RFC PATCH 6/7] arm: call iommu_init before of_platform_populate Will Deacon
2014-08-29 15:54 ` [RFC PATCH 7/7] arm: dma-mapping: plumb our iommu mapping ops into arch_setup_dma_ops Will Deacon
2014-09-02  6:26 ` [RFC PATCH 0/7] Introduce automatic DMA configuration for IOMMU masters Marek Szyprowski
2014-09-02  8:31   ` Will Deacon
2014-09-02  8:48     ` Marek Szyprowski
2014-09-02  8:56       ` Arnd Bergmann
2014-09-02 10:42         ` Marek Szyprowski
2014-09-02 10:57           ` Will Deacon
2014-09-02 12:24             ` Marek Szyprowski
2014-09-02 12:43               ` Arnd Bergmann
2014-09-02 21:50                 ` Laurent Pinchart
2014-09-02 12:22           ` Arnd Bergmann
2014-09-02 12:30             ` Marek Szyprowski
2014-09-02 12:46               ` Arnd Bergmann
2014-09-02 13:11                 ` Marek Szyprowski

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=1706598.u5HumTdOPu@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).