From: Thierry Reding <thierry.reding@gmail.com>
To: Dave Martin <Dave.Martin@arm.com>
Cc: Stephen Warren <swarren@wwwdotorg.org>,
Arnd Bergmann <arnd@arndb.de>, Rob Herring <robh+dt@kernel.org>,
Pawel Moll <Pawel.Moll@arm.com>,
Mark Rutland <Mark.Rutland@arm.com>,
Ian Campbell <ijc+devicetree@hellion.org.uk>,
Kumar Gala <galak@codeaurora.org>,
Cho KyongHo <pullip.cho@samsung.com>,
Grant Grundler <grundler@chromium.org>,
Marc Zyngier <Marc.Zyngier@arm.com>,
Will Deacon <Will.Deacon@arm.com>, Joerg Roedel <joro@8bytes.org>,
Hiroshi Doyu <hdoyu@nvidia.com>,
"devicetree@vger.kernel.org" <devicetree@vger.kernel.org>,
"iommu@lists.linux-foundation.org"
<iommu@lists.linux-foundation.org>,
"linux-arm-kernel@lists.infradead.org"
<linux-arm-kernel@lists.infradead.org>,
"linux-tegra@vger.kernel.org" <linux-tegra@vger.kernel.org>,
"linux-samsung-soc@vger.kernel.org"
<linux-samsung-soc@vger.kernel.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH v2] devicetree: Add generic IOMMU device tree bindings
Date: Wed, 4 Jun 2014 23:12:38 +0200 [thread overview]
Message-ID: <20140604211237.GC18710@mithrandir> (raw)
In-Reply-To: <20140530112728.GB3949@e103592.cambridge.arm.com>
[-- Attachment #1: Type: text/plain, Size: 1936 bytes --]
On Fri, May 30, 2014 at 12:27:28PM +0100, Dave Martin wrote:
> On Fri, May 30, 2014 at 08:30:08AM +0100, Thierry Reding wrote:
[...]
> > Arnd, can you take another look at this binding and see if there's
> > anything else missing? If not I'll go through the document again and
> > update all #address-cells/#size-cells references with #iommu-cells as
> > appropriate and submit v3.
>
> How do you envisage propagation of the master ID bits downstream of the
> IOMMU would be described?
>
> We will definitely need a way to describe this for GICv3. How those
> values are propagated is likely to vary between related SoCs and doesn't
> feel like it should be baked into a driver, especially for the ARM SMMU
> which may get reused in radically different SoC families from different
> vendors.
Well, we've had cases like these in the past (power sequences come to
mind). Some concepts are just too difficult or unwieldy to be put into
device tree. I think that this is one of them.
> The most likely types of remapping are the adding of a base offset or
> some extra bits to the ID -- because not all MSIs to the GIC will
> necessarily pass through the IOMMU. It's also possible that we might
> see ID squashing or folding in some systems.
It can easily be argued that if the algorithm used to remap the ID
varies, the compatibility of the device changes. Therefore I would
expect any variant of the GICv3 that deviates from the "standard"
mapping (if there is such a thing) to have its own compatible string.
At that point there are two possibilities: a) handle the remapping in
code hooked into the driver via matching of the compatible string or
b) specifying a different specifier for each of these and keep the
description in DT. From an implementation point of view, variant b) is
likely going to be very similar to a), though (I'm thinking .of_xlate
type of functions here).
Thierry
[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]
WARNING: multiple messages have this Message-ID (diff)
From: thierry.reding@gmail.com (Thierry Reding)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH v2] devicetree: Add generic IOMMU device tree bindings
Date: Wed, 4 Jun 2014 23:12:38 +0200 [thread overview]
Message-ID: <20140604211237.GC18710@mithrandir> (raw)
In-Reply-To: <20140530112728.GB3949@e103592.cambridge.arm.com>
On Fri, May 30, 2014 at 12:27:28PM +0100, Dave Martin wrote:
> On Fri, May 30, 2014 at 08:30:08AM +0100, Thierry Reding wrote:
[...]
> > Arnd, can you take another look at this binding and see if there's
> > anything else missing? If not I'll go through the document again and
> > update all #address-cells/#size-cells references with #iommu-cells as
> > appropriate and submit v3.
>
> How do you envisage propagation of the master ID bits downstream of the
> IOMMU would be described?
>
> We will definitely need a way to describe this for GICv3. How those
> values are propagated is likely to vary between related SoCs and doesn't
> feel like it should be baked into a driver, especially for the ARM SMMU
> which may get reused in radically different SoC families from different
> vendors.
Well, we've had cases like these in the past (power sequences come to
mind). Some concepts are just too difficult or unwieldy to be put into
device tree. I think that this is one of them.
> The most likely types of remapping are the adding of a base offset or
> some extra bits to the ID -- because not all MSIs to the GIC will
> necessarily pass through the IOMMU. It's also possible that we might
> see ID squashing or folding in some systems.
It can easily be argued that if the algorithm used to remap the ID
varies, the compatibility of the device changes. Therefore I would
expect any variant of the GICv3 that deviates from the "standard"
mapping (if there is such a thing) to have its own compatible string.
At that point there are two possibilities: a) handle the remapping in
code hooked into the driver via matching of the compatible string or
b) specifying a different specifier for each of these and keep the
description in DT. From an implementation point of view, variant b) is
likely going to be very similar to a), though (I'm thinking .of_xlate
type of functions here).
Thierry
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20140604/d7163784/attachment.sig>
next prev parent reply other threads:[~2014-06-04 21:12 UTC|newest]
Thread overview: 215+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-05-23 20:36 [PATCH v2] devicetree: Add generic IOMMU device tree bindings Thierry Reding
2014-05-23 20:36 ` Thierry Reding
2014-05-23 20:36 ` Thierry Reding
[not found] ` <1400877395-4235-1-git-send-email-thierry.reding-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2014-05-29 15:52 ` Stephen Warren
2014-05-29 15:52 ` Stephen Warren
2014-05-29 15:52 ` Stephen Warren
2014-05-30 7:30 ` Thierry Reding
2014-05-30 7:30 ` Thierry Reding
2014-05-30 11:27 ` Dave Martin
2014-05-30 11:27 ` Dave Martin
2014-05-30 11:27 ` Dave Martin
[not found] ` <20140530112728.GB3949-M5GwZQ6tE7x5pKCnmE3YQBJ8xKzm50AiAL8bYrjMMd8@public.gmane.org>
2014-05-30 19:11 ` Arnd Bergmann
2014-05-30 19:11 ` Arnd Bergmann
2014-05-30 19:11 ` Arnd Bergmann
2014-06-02 10:56 ` Dave Martin
2014-06-02 10:56 ` Dave Martin
2014-06-02 10:56 ` Dave Martin
2014-06-04 21:12 ` Thierry Reding [this message]
2014-06-04 21:12 ` Thierry Reding
2014-06-04 21:12 ` Thierry Reding
2014-06-16 12:57 ` Will Deacon
2014-06-16 12:57 ` Will Deacon
2014-06-16 12:57 ` Will Deacon
2014-06-17 11:58 ` Thierry Reding
2014-06-17 11:58 ` Thierry Reding
2014-06-17 11:58 ` Thierry Reding
2014-06-17 12:18 ` Will Deacon
2014-06-17 12:18 ` Will Deacon
2014-06-17 12:18 ` Will Deacon
2014-06-17 23:37 ` Thierry Reding
2014-06-17 23:37 ` Thierry Reding
2014-06-17 23:37 ` Thierry Reding
2014-06-18 10:14 ` Will Deacon
2014-06-18 10:14 ` Will Deacon
2014-06-18 10:14 ` Will Deacon
[not found] ` <20140618101439.GF32699-5wv7dgnIgG8@public.gmane.org>
2014-06-20 15:53 ` Arnd Bergmann
2014-06-20 15:53 ` Arnd Bergmann
2014-06-20 15:53 ` Arnd Bergmann
2014-06-20 17:50 ` Will Deacon
2014-06-20 17:50 ` Will Deacon
2014-06-20 17:50 ` Will Deacon
2014-06-20 18:55 ` Arnd Bergmann
2014-06-20 18:55 ` Arnd Bergmann
2014-06-20 18:55 ` Arnd Bergmann
2014-05-30 11:22 ` Dave Martin
2014-05-30 11:22 ` Dave Martin
2014-05-30 11:22 ` Dave Martin
[not found] ` <20140530112226.GA3949-M5GwZQ6tE7x5pKCnmE3YQBJ8xKzm50AiAL8bYrjMMd8@public.gmane.org>
2014-05-30 19:01 ` Arnd Bergmann
2014-05-30 19:01 ` Arnd Bergmann
2014-05-30 19:01 ` Arnd Bergmann
2014-06-02 11:44 ` Dave Martin
2014-06-02 11:44 ` Dave Martin
2014-06-02 11:44 ` Dave Martin
2014-06-04 21:32 ` Thierry Reding
2014-06-04 21:32 ` Thierry Reding
2014-06-04 21:32 ` Thierry Reding
2014-06-05 9:42 ` Arnd Bergmann
2014-06-05 9:42 ` Arnd Bergmann
2014-06-05 9:42 ` Arnd Bergmann
-- strict thread matches above, loose matches on Subject: below --
2014-06-06 22:45 Thierry Reding
2014-06-06 22:45 ` Thierry Reding
2014-06-07 13:22 ` Arnd Bergmann
2014-06-07 13:22 ` Arnd Bergmann
2014-06-07 13:22 ` Arnd Bergmann
2014-06-09 10:49 ` Thierry Reding
2014-06-09 10:49 ` Thierry Reding
2014-06-09 10:49 ` Thierry Reding
2014-05-23 20:33 Thierry Reding
[not found] ` <1400877218-4113-1-git-send-email-thierry.reding-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2014-05-30 13:16 ` Rob Herring
2014-05-30 13:16 ` Rob Herring
2014-05-30 13:16 ` Rob Herring
[not found] ` <CAL_JsqKumG1PSFoVfeGpLLG+MjXFeF4aUjun=vv1BJpaxk0Byg-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2014-05-30 19:06 ` Arnd Bergmann
2014-05-30 19:06 ` Arnd Bergmann
2014-05-30 19:06 ` Arnd Bergmann
2014-05-30 19:29 ` Hiroshi Doyu
2014-05-30 19:29 ` Hiroshi Doyu
2014-05-30 19:29 ` Hiroshi Doyu
2014-05-30 19:54 ` Arnd Bergmann
2014-05-30 19:54 ` Arnd Bergmann
2014-05-30 19:54 ` Arnd Bergmann
2014-06-01 9:55 ` Will Deacon
2014-06-01 9:55 ` Will Deacon
2014-06-01 9:55 ` Will Deacon
[not found] ` <20140601095546.GA8625-5wv7dgnIgG8@public.gmane.org>
2014-06-04 13:39 ` Thierry Reding
2014-06-04 13:39 ` Thierry Reding
2014-06-04 13:39 ` Thierry Reding
2014-06-04 13:44 ` Thierry Reding
2014-06-04 13:44 ` Thierry Reding
2014-06-04 13:44 ` Thierry Reding
2014-06-04 13:53 ` Arnd Bergmann
2014-06-04 13:53 ` Arnd Bergmann
2014-06-04 13:53 ` Arnd Bergmann
2014-06-04 13:56 ` Will Deacon
2014-06-04 13:56 ` Will Deacon
2014-06-04 13:56 ` Will Deacon
[not found] ` <20140604135600.GD6644-5wv7dgnIgG8@public.gmane.org>
2014-06-04 14:01 ` Arnd Bergmann
2014-06-04 14:01 ` Arnd Bergmann
2014-06-04 14:01 ` Arnd Bergmann
2014-06-04 16:39 ` Will Deacon
2014-06-04 16:39 ` Will Deacon
2014-06-04 16:39 ` Will Deacon
2014-05-30 19:31 ` Rob Herring
2014-05-30 19:31 ` Rob Herring
2014-05-30 19:31 ` Rob Herring
[not found] ` <CAL_Jsq+tkFNpjSEZboT+o69B_Z3a8e-ZVKaYDmLwtkyYoPy6VQ-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2014-05-30 19:49 ` Arnd Bergmann
2014-05-30 19:49 ` Arnd Bergmann
2014-05-30 19:49 ` Arnd Bergmann
2014-06-02 10:41 ` Dave Martin
2014-06-02 10:41 ` Dave Martin
2014-06-02 10:41 ` Dave Martin
[not found] ` <20140602104104.GD3855-M5GwZQ6tE7x5pKCnmE3YQBJ8xKzm50AiAL8bYrjMMd8@public.gmane.org>
2014-06-04 14:35 ` Thierry Reding
2014-06-04 14:35 ` Thierry Reding
2014-06-04 14:35 ` Thierry Reding
2014-06-04 16:41 ` Will Deacon
2014-06-04 16:41 ` Will Deacon
2014-06-04 16:41 ` Will Deacon
[not found] ` <20140604164132.GF6644-5wv7dgnIgG8@public.gmane.org>
2014-06-04 21:00 ` Thierry Reding
2014-06-04 21:00 ` Thierry Reding
2014-06-04 21:00 ` Thierry Reding
2014-06-05 19:10 ` Varun Sethi
2014-06-05 19:10 ` Varun Sethi
2014-06-05 19:10 ` Varun Sethi
2014-06-16 15:27 ` Will Deacon
2014-06-16 15:27 ` Will Deacon
2014-06-16 15:27 ` Will Deacon
[not found] ` <20140616152739.GS16758-5wv7dgnIgG8@public.gmane.org>
2014-06-16 16:56 ` Stuart Yoder
2014-06-16 16:56 ` Stuart Yoder
2014-06-16 16:56 ` Stuart Yoder
[not found] ` <8b0492b4697943a0b1f276ef42cc8223-ufbTtyGzTTT8GZusEWM6WuO6mTEJWrR4XA4E9RH9d+qIuWR1G4zioA@public.gmane.org>
2014-06-16 17:04 ` Will Deacon
2014-06-16 17:04 ` Will Deacon
2014-06-16 17:04 ` Will Deacon
[not found] ` <20140616170416.GA16758-5wv7dgnIgG8@public.gmane.org>
2014-06-16 17:30 ` Arnd Bergmann
2014-06-16 17:30 ` Arnd Bergmann
2014-06-16 17:30 ` Arnd Bergmann
2014-06-16 18:53 ` Stuart Yoder
2014-06-16 18:53 ` Stuart Yoder
2014-06-16 18:53 ` Stuart Yoder
[not found] ` <419e67f783524d208ab3be16bcd94bd9-ufbTtyGzTTT8GZusEWM6WuO6mTEJWrR4XA4E9RH9d+qIuWR1G4zioA@public.gmane.org>
2014-06-17 10:26 ` Varun Sethi
2014-06-17 10:26 ` Varun Sethi
2014-06-17 10:26 ` Varun Sethi
[not found] ` <0587e1f4894546398be0798d2bc2c84f-AZ66ij2kwaacCcN9WK45f+O6mTEJWrR4XA4E9RH9d+qIuWR1G4zioA@public.gmane.org>
2014-06-17 10:43 ` Will Deacon
2014-06-17 10:43 ` Will Deacon
2014-06-17 10:43 ` Will Deacon
[not found] ` <20140617104304.GD13808-5wv7dgnIgG8@public.gmane.org>
2014-06-17 11:21 ` Varun Sethi
2014-06-17 11:21 ` Varun Sethi
2014-06-17 11:21 ` Varun Sethi
[not found] ` <32165315f0b84be9948f489fd87bf6a9-AZ66ij2kwaacCcN9WK45f+O6mTEJWrR4XA4E9RH9d+qIuWR1G4zioA@public.gmane.org>
2014-06-17 14:50 ` Stuart Yoder
2014-06-17 14:50 ` Stuart Yoder
2014-06-17 14:50 ` Stuart Yoder
2014-06-18 9:29 ` Will Deacon
2014-06-18 9:29 ` Will Deacon
2014-06-18 9:29 ` Will Deacon
2014-06-17 14:39 ` Stuart Yoder
2014-06-17 14:39 ` Stuart Yoder
2014-06-17 14:39 ` Stuart Yoder
2014-06-20 23:16 ` Olav Haugan
2014-06-20 23:16 ` Olav Haugan
2014-06-20 23:16 ` Olav Haugan
2014-06-24 9:18 ` Will Deacon
2014-06-24 9:18 ` Will Deacon
2014-06-24 9:18 ` Will Deacon
[not found] ` <20140624091808.GC26013-5wv7dgnIgG8@public.gmane.org>
2014-06-24 17:57 ` Olav Haugan
2014-06-24 17:57 ` Olav Haugan
2014-06-24 17:57 ` Olav Haugan
2014-06-24 18:11 ` Will Deacon
2014-06-24 18:11 ` Will Deacon
2014-06-24 18:11 ` Will Deacon
[not found] ` <20140624181150.GB4067-5wv7dgnIgG8@public.gmane.org>
2014-06-24 18:20 ` Arnd Bergmann
2014-06-24 18:20 ` Arnd Bergmann
2014-06-24 18:20 ` Arnd Bergmann
2014-06-25 9:17 ` Will Deacon
2014-06-25 9:17 ` Will Deacon
2014-06-25 9:17 ` Will Deacon
2014-06-25 9:27 ` Arnd Bergmann
2014-06-25 9:27 ` Arnd Bergmann
2014-06-25 9:27 ` Arnd Bergmann
2014-06-25 9:38 ` Will Deacon
2014-06-25 9:38 ` Will Deacon
2014-06-25 9:38 ` Will Deacon
2014-06-25 9:48 ` Arnd Bergmann
2014-06-25 9:48 ` Arnd Bergmann
2014-06-25 9:48 ` Arnd Bergmann
2014-06-25 9:57 ` Will Deacon
2014-06-25 9:57 ` Will Deacon
2014-06-25 9:57 ` Will Deacon
[not found] ` <20140625095735.GI6153-5wv7dgnIgG8@public.gmane.org>
2014-06-25 10:12 ` Arnd Bergmann
2014-06-25 10:12 ` Arnd Bergmann
2014-06-25 10:12 ` Arnd Bergmann
2014-06-25 10:14 ` Will Deacon
2014-06-25 10:14 ` Will Deacon
2014-06-25 10:14 ` Will Deacon
2014-06-24 21:35 ` Olav Haugan
2014-06-24 21:35 ` Olav Haugan
2014-06-24 21:35 ` Olav Haugan
[not found] ` <53A9EF3A.2070704-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org>
2014-06-25 9:18 ` Will Deacon
2014-06-25 9:18 ` Will Deacon
2014-06-25 9:18 ` Will Deacon
[not found] ` <20140625091858.GG6153-5wv7dgnIgG8@public.gmane.org>
2014-06-27 22:23 ` Olav Haugan
2014-06-27 22:23 ` Olav Haugan
2014-06-27 22:23 ` Olav Haugan
[not found] ` <53ADEEDF.7060902-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org>
2014-06-30 9:52 ` Will Deacon
2014-06-30 9:52 ` Will Deacon
2014-06-30 9:52 ` Will Deacon
2014-07-09 1:07 ` Olav Haugan
2014-07-09 1:07 ` Olav Haugan
2014-07-09 1:07 ` Olav Haugan
[not found] ` <53BC95DA.1010500-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org>
2014-07-09 10:54 ` Will Deacon
2014-07-09 10:54 ` Will Deacon
2014-07-09 10:54 ` Will Deacon
[not found] ` <20140709105441.GE9485-5wv7dgnIgG8@public.gmane.org>
2014-07-10 22:32 ` Olav Haugan
2014-07-10 22:32 ` Olav Haugan
2014-07-10 22:32 ` Olav Haugan
2014-07-11 12:24 ` Will Deacon
2014-07-11 12:24 ` Will Deacon
2014-07-11 12:24 ` 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=20140604211237.GC18710@mithrandir \
--to=thierry.reding@gmail.com \
--cc=Dave.Martin@arm.com \
--cc=Marc.Zyngier@arm.com \
--cc=Mark.Rutland@arm.com \
--cc=Pawel.Moll@arm.com \
--cc=Will.Deacon@arm.com \
--cc=arnd@arndb.de \
--cc=devicetree@vger.kernel.org \
--cc=galak@codeaurora.org \
--cc=grundler@chromium.org \
--cc=hdoyu@nvidia.com \
--cc=ijc+devicetree@hellion.org.uk \
--cc=iommu@lists.linux-foundation.org \
--cc=joro@8bytes.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-samsung-soc@vger.kernel.org \
--cc=linux-tegra@vger.kernel.org \
--cc=pullip.cho@samsung.com \
--cc=robh+dt@kernel.org \
--cc=swarren@wwwdotorg.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.