From: will.deacon@arm.com (Will Deacon)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH v6 6/8] dma-mapping: detect and configure IOMMU in of_dma_configure
Date: Wed, 17 Dec 2014 17:20:00 +0000 [thread overview]
Message-ID: <20141217172000.GC30307@arm.com> (raw)
In-Reply-To: <1926348.VsVWqO766S@wuerfel>
On Wed, Dec 17, 2014 at 03:38:22PM +0000, Arnd Bergmann wrote:
> On Wednesday 17 December 2014 15:01:58 Will Deacon wrote:
> > On Wed, Dec 17, 2014 at 02:27:30PM +0000, Robin Murphy wrote:
> > > I thoroughly dislike the idea, but one /could/ simply abuse the generic
> > > bindings well within the current framework, e.g.
> > >
> > > #1: iommus = <&smmu 0 streamID 0 0>, <&smmu 0 streamID 0 0>, ...;
> > > #2: iommus = <&smmu 1 mask value 0>;
> > > #3: iommus = <&smmu 2 start end offset>;
> > >
> > > and have a big complicated of_xlate that knows the secret. I don't think
> > > it would be unreasonable to constrain all masters on the same SMMU to
> > > use the same format either - that way you can lose the type indicator
> > > and the padding and the driver simply inspects #iommu-cells in
> > > of_iommu_init and sets up that instance to take the right path in its
> > > of_xlate calls later. Having a handful of single-stream-ID masters
> > > behind the same SMMU as a whacking great bus controller with a massive
> > > range seems like the kind of system-designer-insanity we should
> > > emphatically NOT be looking to accommodate if we can possibly help it.
> > >
> > > That said, for the time being I see definite use-cases for #1, which
> > > already works, and #3, for which I really think we should be looking to
> > > add a parallel generic "iommu-ranges" or "iommu-bus-range" binding for
> > > bus controllers, rather than trying to overload "iommus" beyond
> > > describing actual bus masters.
> >
> > Yeah, let's avoid overloading the current bindings too much. Adding the
> > ranges property makes perfect sense, I'm just trying to to straighten
> > out how the "iommus" property should differ depending on the presence of
> > SMR groups.
>
> Is a range something that is defined in the hardware spec, or is that
> just what you expect the PCI host controllers to use?
The range would be a Linux-ism for converting a bus ID on bus foo (e.g. a
requester ID on a PCI bus) into a master ID for the IOMMU for that bus
(e.g. a stream ID for an ARM SMMU). However, I don't think the code doing
that mapping really needs knowledge about what the IDs represent.
Will
next prev parent reply other threads:[~2014-12-17 17:20 UTC|newest]
Thread overview: 110+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-12-01 16:57 [PATCH v6 0/8] Introduce automatic DMA configuration for IOMMU masters Will Deacon
2014-12-01 16:57 ` [PATCH v6 1/8] iommu: provide early initialisation hook for IOMMU drivers Will Deacon
2014-12-01 23:54 ` Rob Herring
2014-12-02 9:23 ` Marek Szyprowski
2014-12-02 9:36 ` Arnd Bergmann
2014-12-02 9:43 ` Will Deacon
2014-12-02 12:05 ` Thierry Reding
2014-12-02 10:30 ` Pantelis Antoniou
2014-12-02 14:16 ` Grant Likely
2014-12-03 19:57 ` Arnd Bergmann
2014-12-04 9:49 ` Will Deacon
2014-12-04 10:10 ` Arnd Bergmann
2014-12-04 10:21 ` Will Deacon
2014-12-04 11:19 ` Arnd Bergmann
2014-12-04 11:25 ` Grant Likely
2014-12-04 11:52 ` Will Deacon
2014-12-04 12:43 ` Grant Likely
2014-12-04 12:26 ` Robin Murphy
2014-12-04 12:42 ` Grant Likely
2014-12-04 13:43 ` Robin Murphy
2014-12-04 13:58 ` Grant Likely
2014-12-04 14:49 ` Thierry Reding
2014-12-04 17:42 ` Robin Murphy
2014-12-04 17:58 ` Grant Likely
2014-12-04 19:42 ` Robin Murphy
2014-12-05 12:10 ` Will Deacon
2014-12-05 12:21 ` Arnd Bergmann
2014-12-05 12:35 ` Robin Murphy
2014-12-05 13:06 ` Grant Likely
2014-12-05 13:18 ` Thierry Reding
2014-12-05 13:21 ` Grant Likely
2014-12-05 13:31 ` Thierry Reding
2014-12-05 13:49 ` Marek Szyprowski
2014-12-04 12:51 ` Arnd Bergmann
2014-12-01 16:57 ` [PATCH v6 2/8] dma-mapping: replace set_arch_dma_coherent_ops with arch_setup_dma_ops Will Deacon
2014-12-01 22:58 ` Rob Herring
2014-12-02 9:16 ` Arnd Bergmann
2014-12-01 16:57 ` [PATCH v6 3/8] iommu: add new iommu_ops callback for adding an OF device Will Deacon
2014-12-01 16:57 ` [PATCH v6 4/8] iommu: provide helper function to configure an IOMMU for an of master Will Deacon
2014-12-01 16:57 ` [PATCH v6 5/8] iommu: fix initialization without 'add_device' callback Will Deacon
2014-12-01 16:57 ` [PATCH v6 6/8] dma-mapping: detect and configure IOMMU in of_dma_configure Will Deacon
2014-12-01 23:06 ` Rob Herring
2014-12-10 14:52 ` Rob Clark
2014-12-10 15:08 ` Will Deacon
2014-12-10 15:54 ` Robin Murphy
2014-12-10 15:56 ` Laurent Pinchart
2014-12-14 15:49 ` Laurent Pinchart
2014-12-14 15:59 ` Laurent Pinchart
2014-12-15 17:10 ` Will Deacon
2014-12-15 16:40 ` Will Deacon
2014-12-15 17:16 ` Laurent Pinchart
2014-12-15 18:09 ` Will Deacon
2014-12-16 12:08 ` Arnd Bergmann
2014-12-17 12:09 ` Will Deacon
2014-12-17 14:15 ` Arnd Bergmann
2014-12-17 14:45 ` Will Deacon
2014-12-17 15:35 ` Arnd Bergmann
2014-12-17 17:17 ` Will Deacon
2014-12-17 19:48 ` Arnd Bergmann
2014-12-21 10:04 ` Will Deacon
2014-12-22 13:36 ` Arnd Bergmann
2015-01-07 18:57 ` Will Deacon
2015-01-07 19:29 ` Arnd Bergmann
2015-01-08 10:53 ` Will Deacon
2014-12-17 14:27 ` Robin Murphy
2014-12-17 15:01 ` Will Deacon
2014-12-17 15:38 ` Arnd Bergmann
2014-12-17 17:20 ` Will Deacon [this message]
2014-12-17 0:05 ` Laurent Pinchart
2014-12-14 15:51 ` Laurent Pinchart
2014-12-15 11:32 ` Will Deacon
2014-12-17 0:19 ` Laurent Pinchart
2014-12-17 11:14 ` Will Deacon
2014-12-01 16:57 ` [PATCH v6 7/8] arm: call iommu_init before of_platform_populate Will Deacon
2014-12-01 16:57 ` [PATCH v6 8/8] arm: dma-mapping: plumb our iommu mapping ops into arch_setup_dma_ops Will Deacon
2015-01-14 9:00 ` Alexandre Courbot
2015-01-14 10:46 ` Will Deacon
2015-01-14 13:51 ` Heiko Stübner
2015-01-14 19:17 ` Will Deacon
2015-01-15 8:30 ` Thierry Reding
2015-01-15 11:13 ` Will Deacon
2015-01-15 2:57 ` Alexandre Courbot
2015-01-15 8:28 ` Thierry Reding
2015-01-15 11:12 ` Will Deacon
2015-01-15 23:18 ` Laurent Pinchart
2015-01-18 6:54 ` Alexandre Courbot
2015-01-18 11:18 ` Laurent Pinchart
2015-01-19 11:12 ` Will Deacon
2015-01-19 11:34 ` Laurent Pinchart
2015-01-19 12:31 ` Thierry Reding
2015-01-20 15:14 ` Laurent Pinchart
2015-01-20 15:19 ` Will Deacon
2015-01-20 15:21 ` Will Deacon
2015-01-20 15:35 ` Laurent Pinchart
2015-01-19 12:43 ` Thierry Reding
2015-01-19 12:50 ` Will Deacon
2015-01-19 13:36 ` Thierry Reding
2015-01-20 13:50 ` Laurent Pinchart
2015-01-19 16:13 ` Arnd Bergmann
2015-01-20 16:41 ` Laurent Pinchart
2015-01-19 12:36 ` Thierry Reding
2015-01-19 15:52 ` Arnd Bergmann
2015-01-19 16:21 ` Thierry Reding
2015-01-19 17:02 ` Arnd Bergmann
2015-01-20 13:47 ` Laurent Pinchart
2015-01-19 12:49 ` Thierry Reding
2015-01-20 14:05 ` Laurent Pinchart
2014-12-05 7:12 ` [PATCH v6 0/8] Introduce automatic DMA configuration for IOMMU masters Olof Johansson
2014-12-05 12:11 ` Will Deacon
2014-12-15 0:24 ` [PATCH/RFC] iommu/ipmmu-vmsa: Use DT-based instantiation Laurent Pinchart
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=20141217172000.GC30307@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).