From: will.deacon@arm.com (Will Deacon)
To: linux-arm-kernel@lists.infradead.org
Subject: [RFC PATCH v3 5/7] dma-mapping: detect and configure IOMMU in of_dma_configure
Date: Mon, 27 Oct 2014 10:51:59 +0000 [thread overview]
Message-ID: <20141027105158.GE8768@arm.com> (raw)
In-Reply-To: <4572757.M4IDlCz5Vc@avalon>
On Tue, Oct 14, 2014 at 01:53:59PM +0100, Laurent Pinchart wrote:
> Hi Will,
Hi Laurent,
> On Monday 22 September 2014 18:50:27 Will Deacon wrote:
> > On Mon, Sep 22, 2014 at 10:29:10AM +0100, Thierry Reding wrote:
> > > Agreed. I wonder how useful it is to know the set of IOMMU instances
> > > that each device can master through. Wouldn't it be more useful to keep
> > > a list of master interfaces for each device? The set of IOMMU instances
> > > can trivially be derived from that.
> >
> > I'm struggling to think how that would look. What do you mean by `master
> > interfaces' in terms of the code we have in Linux? At the end of the day,
> > the list of IOMMU instances (i.e. iommu_dma_mapping) exists because you
> > and Laurent have use-cases involving devices mastering through multiple
> > IOMMUs. If it doesn't work for you, it might be best for you to send me
> > the patch ;)
>
> Just for the record, I've brought up the topic of masters being served by
> multiple IOMMUs, but don't have a use case for it (yet at least). I do have
> masters served through multiple streams with separate stream IDs, but all by
> the same IOMMU.
Ok. I spoke to Arnd, David and Joerg at LPC and the consensus was that the
DMA-mapping API should *not* be exposed to the details of masters that
master through multiple IOMMUs. Instead, that should be abstracted by the
device API by exposing that device as a single struct device.
So, that's certainly an area that needs more work and I'll drop the limited
support I'd cooked up from this patch set in the next version.
Will
next prev parent reply other threads:[~2014-10-27 10:51 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
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 [this message]
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=20141027105158.GE8768@arm.com \
--to=will.deacon@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).