From: Will Deacon <will.deacon@arm.com>
To: Olav Haugan <ohaugan@codeaurora.org>
Cc: Mark Rutland <Mark.Rutland@arm.com>,
"devicetree@vger.kernel.org" <devicetree@vger.kernel.org>,
"linux-samsung-soc@vger.kernel.org"
<linux-samsung-soc@vger.kernel.org>,
Arnd Bergmann <arnd@arndb.de>, Pawel Moll <Pawel.Moll@arm.com>,
Ian Campbell <ijc+devicetree@hellion.org.uk>,
Grant Grundler <grundler@chromium.org>,
Joerg Roedel <joro@8bytes.org>,
Stephen Warren <swarren@wwwdotorg.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
Marc Zyngier <Marc.Zyngier@arm.com>,
Linux IOMMU <iommu@lists.linux-foundation.org>,
Rob Herring <robh+dt@kernel.org>,
Thierry Reding <thierry.reding@gmail.com>,
Kumar Gala <galak@codeaurora.org>,
"linux-tegra@vger.kernel.org" <linux-tegra@vger.kernel.org>,
Cho KyongHo <pullip.cho@samsung.com>,
"mitchelh@codeaurora.org" <mitchelh@codeaurora.org>,
Dave P Martin <Dave.Martin@arm.com>,
linux-arm-kernel@lists.infradead.or
Subject: Re: [PATCH v2] devicetree: Add generic IOMMU device tree bindings
Date: Fri, 11 Jul 2014 13:24:25 +0100 [thread overview]
Message-ID: <20140711122425.GD12899@arm.com> (raw)
In-Reply-To: <53BF1470.1000704@codeaurora.org>
On Thu, Jul 10, 2014 at 11:32:16PM +0100, Olav Haugan wrote:
> On 7/9/2014 3:54 AM, Will Deacon wrote:
> > On Wed, Jul 09, 2014 at 02:07:38AM +0100, Olav Haugan wrote:
> >> So how does an algorithm figure this out in both my examples? The
> >> algorithm would have to know about both (all) bus masters and their
> >> stream IDs for a specific SMMU. If the algorithm operates on the set of
> >> stream IDs for one bus master at a time the algorithm has no way of
> >> knowing which bits can be ignored since it doesn't know the value of the
> >> other stream IDs for the other bus masters and thus could potentially
> >> create a mask that could cause a stream ID to match in two different
> >> entries.
> >
> > Complete knowledge of the system topology (i.e. all bus masters) is a
> > requirement for being able to configure the SMMU correctly if you want to
> > guarantee that you don't have SMR aliasing issues.
>
> So you agree that an algorithm needs to know about all the bus
> masters/stream IDs for a specific IOMMU before it can figure out the
> StreamID masks and how many SMRs can be allocated to a specific bus
> master? Andreas's algorithm does not know about the other bus
> masters/stream IDs. It operates on one bus master at a time.
Right, but it can certainly be improved. There are certain things you can do
without complete knowledge, as I mentioned previously (if you can have
densely packed power-of-2 aligned/sized regions).
> >>>> I am not familiar with Andreas's proposal. Do you have a link?
> >>>
> >>> http://marc.info/?l=linux-arm-kernel&m=139110598005846&w=2
> >>
> >> Unless I am mistaken the algorithm works on one bus master at a time. I
> >> don't think that will work.
> >
> > IIRC, it works for densely packed SIDs on the master, so it tries to build
> > up power-of-2 sized groups for that master then mops up the rest with
> > individual entries.
>
> I ran the algorithm through a few trivial cases:
>
> 1)
> Stream IDs: 0x21, 0x22, 0x23, 0x24, 0x25, 0x26, 0x27, 0x28
> Number of SMRs: 9
>
> In this case the algorithm decided to set mask to 0 for all entries
> using up 8 of the SMRs.
Well think about what it's doing... we don't know about SID 0x20, for
example so there's not much it can do.
> 2) Same Stream IDs but only 2 SMRs.
> The algorithm gave an error saying I did not have enough SMRs.
There's a reason this didn't get merged, and it would be great if you could
try to improve the situation ;).
Will
WARNING: multiple messages have this Message-ID (diff)
From: will.deacon@arm.com (Will Deacon)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH v2] devicetree: Add generic IOMMU device tree bindings
Date: Fri, 11 Jul 2014 13:24:25 +0100 [thread overview]
Message-ID: <20140711122425.GD12899@arm.com> (raw)
In-Reply-To: <53BF1470.1000704@codeaurora.org>
On Thu, Jul 10, 2014 at 11:32:16PM +0100, Olav Haugan wrote:
> On 7/9/2014 3:54 AM, Will Deacon wrote:
> > On Wed, Jul 09, 2014 at 02:07:38AM +0100, Olav Haugan wrote:
> >> So how does an algorithm figure this out in both my examples? The
> >> algorithm would have to know about both (all) bus masters and their
> >> stream IDs for a specific SMMU. If the algorithm operates on the set of
> >> stream IDs for one bus master at a time the algorithm has no way of
> >> knowing which bits can be ignored since it doesn't know the value of the
> >> other stream IDs for the other bus masters and thus could potentially
> >> create a mask that could cause a stream ID to match in two different
> >> entries.
> >
> > Complete knowledge of the system topology (i.e. all bus masters) is a
> > requirement for being able to configure the SMMU correctly if you want to
> > guarantee that you don't have SMR aliasing issues.
>
> So you agree that an algorithm needs to know about all the bus
> masters/stream IDs for a specific IOMMU before it can figure out the
> StreamID masks and how many SMRs can be allocated to a specific bus
> master? Andreas's algorithm does not know about the other bus
> masters/stream IDs. It operates on one bus master at a time.
Right, but it can certainly be improved. There are certain things you can do
without complete knowledge, as I mentioned previously (if you can have
densely packed power-of-2 aligned/sized regions).
> >>>> I am not familiar with Andreas's proposal. Do you have a link?
> >>>
> >>> http://marc.info/?l=linux-arm-kernel&m=139110598005846&w=2
> >>
> >> Unless I am mistaken the algorithm works on one bus master at a time. I
> >> don't think that will work.
> >
> > IIRC, it works for densely packed SIDs on the master, so it tries to build
> > up power-of-2 sized groups for that master then mops up the rest with
> > individual entries.
>
> I ran the algorithm through a few trivial cases:
>
> 1)
> Stream IDs: 0x21, 0x22, 0x23, 0x24, 0x25, 0x26, 0x27, 0x28
> Number of SMRs: 9
>
> In this case the algorithm decided to set mask to 0 for all entries
> using up 8 of the SMRs.
Well think about what it's doing... we don't know about SID 0x20, for
example so there's not much it can do.
> 2) Same Stream IDs but only 2 SMRs.
> The algorithm gave an error saying I did not have enough SMRs.
There's a reason this didn't get merged, and it would be great if you could
try to improve the situation ;).
Will
WARNING: multiple messages have this Message-ID (diff)
From: Will Deacon <will.deacon@arm.com>
To: Olav Haugan <ohaugan@codeaurora.org>
Cc: Mark Rutland <Mark.Rutland@arm.com>,
"devicetree@vger.kernel.org" <devicetree@vger.kernel.org>,
"linux-samsung-soc@vger.kernel.org"
<linux-samsung-soc@vger.kernel.org>,
Arnd Bergmann <arnd@arndb.de>, Pawel Moll <Pawel.Moll@arm.com>,
Ian Campbell <ijc+devicetree@hellion.org.uk>,
Grant Grundler <grundler@chromium.org>,
Joerg Roedel <joro@8bytes.org>,
Stephen Warren <swarren@wwwdotorg.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
Marc Zyngier <Marc.Zyngier@arm.com>,
Linux IOMMU <iommu@lists.linux-foundation.org>,
Rob Herring <robh+dt@kernel.org>,
Thierry Reding <thierry.reding@gmail.com>,
Kumar Gala <galak@codeaurora.org>,
"linux-tegra@vger.kernel.org" <linux-tegra@vger.kernel.org>,
Cho KyongHo <pullip.cho@samsung.com>,
"mitchelh@codeaurora.org" <mitchelh@codeaurora.org>,
Dave P Martin <Dave.Martin@arm.com>,
"linux-arm-kernel@lists.infradead.org"
<linux-arm-kernel@lists.infradead.org>,
Hiroshi Doyu <hdoyu@nvidia.com>
Subject: Re: [PATCH v2] devicetree: Add generic IOMMU device tree bindings
Date: Fri, 11 Jul 2014 13:24:25 +0100 [thread overview]
Message-ID: <20140711122425.GD12899@arm.com> (raw)
In-Reply-To: <53BF1470.1000704@codeaurora.org>
On Thu, Jul 10, 2014 at 11:32:16PM +0100, Olav Haugan wrote:
> On 7/9/2014 3:54 AM, Will Deacon wrote:
> > On Wed, Jul 09, 2014 at 02:07:38AM +0100, Olav Haugan wrote:
> >> So how does an algorithm figure this out in both my examples? The
> >> algorithm would have to know about both (all) bus masters and their
> >> stream IDs for a specific SMMU. If the algorithm operates on the set of
> >> stream IDs for one bus master at a time the algorithm has no way of
> >> knowing which bits can be ignored since it doesn't know the value of the
> >> other stream IDs for the other bus masters and thus could potentially
> >> create a mask that could cause a stream ID to match in two different
> >> entries.
> >
> > Complete knowledge of the system topology (i.e. all bus masters) is a
> > requirement for being able to configure the SMMU correctly if you want to
> > guarantee that you don't have SMR aliasing issues.
>
> So you agree that an algorithm needs to know about all the bus
> masters/stream IDs for a specific IOMMU before it can figure out the
> StreamID masks and how many SMRs can be allocated to a specific bus
> master? Andreas's algorithm does not know about the other bus
> masters/stream IDs. It operates on one bus master at a time.
Right, but it can certainly be improved. There are certain things you can do
without complete knowledge, as I mentioned previously (if you can have
densely packed power-of-2 aligned/sized regions).
> >>>> I am not familiar with Andreas's proposal. Do you have a link?
> >>>
> >>> http://marc.info/?l=linux-arm-kernel&m=139110598005846&w=2
> >>
> >> Unless I am mistaken the algorithm works on one bus master at a time. I
> >> don't think that will work.
> >
> > IIRC, it works for densely packed SIDs on the master, so it tries to build
> > up power-of-2 sized groups for that master then mops up the rest with
> > individual entries.
>
> I ran the algorithm through a few trivial cases:
>
> 1)
> Stream IDs: 0x21, 0x22, 0x23, 0x24, 0x25, 0x26, 0x27, 0x28
> Number of SMRs: 9
>
> In this case the algorithm decided to set mask to 0 for all entries
> using up 8 of the SMRs.
Well think about what it's doing... we don't know about SID 0x20, for
example so there's not much it can do.
> 2) Same Stream IDs but only 2 SMRs.
> The algorithm gave an error saying I did not have enough SMRs.
There's a reason this didn't get merged, and it would be great if you could
try to improve the situation ;).
Will
next prev parent reply other threads:[~2014-07-11 12:24 UTC|newest]
Thread overview: 211+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-05-23 20:33 [PATCH v2] devicetree: Add generic IOMMU device tree bindings 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
[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-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 [this message]
2014-07-11 12:24 ` Will Deacon
2014-07-11 12:24 ` Will Deacon
-- strict thread matches above, loose matches on Subject: below --
2014-05-23 20:36 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
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
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
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=20140711122425.GD12899@arm.com \
--to=will.deacon@arm.com \
--cc=Dave.Martin@arm.com \
--cc=Marc.Zyngier@arm.com \
--cc=Mark.Rutland@arm.com \
--cc=Pawel.Moll@arm.com \
--cc=arnd@arndb.de \
--cc=devicetree@vger.kernel.org \
--cc=galak@codeaurora.org \
--cc=grundler@chromium.org \
--cc=ijc+devicetree@hellion.org.uk \
--cc=iommu@lists.linux-foundation.org \
--cc=joro@8bytes.org \
--cc=linux-arm-kernel@lists.infradead.or \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-samsung-soc@vger.kernel.org \
--cc=linux-tegra@vger.kernel.org \
--cc=mitchelh@codeaurora.org \
--cc=ohaugan@codeaurora.org \
--cc=pullip.cho@samsung.com \
--cc=robh+dt@kernel.org \
--cc=swarren@wwwdotorg.org \
--cc=thierry.reding@gmail.com \
/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.