From: Stuart Yoder <stuart.yoder-KZfg59tc24xl57MIdRCFDg@public.gmane.org>
To: Will Deacon <will.deacon-5wv7dgnIgG8@public.gmane.org>,
Varun Sethi <Varun.Sethi-KZfg59tc24xl57MIdRCFDg@public.gmane.org>
Cc: Mark Rutland <Mark.Rutland-5wv7dgnIgG8@public.gmane.org>,
"devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org"
<devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
"linux-samsung-soc-u79uwXL29TY76Z2rM5mHXA@public.gmane.org"
<linux-samsung-soc-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
Pawel Moll <Pawel.Moll-5wv7dgnIgG8@public.gmane.org>,
Arnd Bergmann <arnd-r2nGTMty4D4@public.gmane.org>,
Ian Campbell
<ijc+devicetree-KcIKpvwj1kUDXYZnReoRVg@public.gmane.org>,
Grant Grundler <grundler-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org>,
Stephen Warren <swarren-3lzwWm7+Weoh9ZMKESR00Q@public.gmane.org>,
"linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org"
<linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
Rob Herring <robh+dt-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>,
Marc Zyngier <Marc.Zyngier-5wv7dgnIgG8@public.gmane.org>,
Linux IOMMU
<iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org>,
Thierry Reding
<thierry.reding-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>,
Kumar Gala <galak-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org>,
"linux-tegra-u79uwXL29TY76Z2rM5mHXA@public.gmane.org"
<linux-tegra-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
Cho KyongHo <pullip.cho-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org>,
Dave P Martin <Dave.Martin-5wv7dgnIgG8@public.gmane.org>,
"linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org"
<linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org>
Subject: RE: [PATCH v2] devicetree: Add generic IOMMU device tree bindings
Date: Mon, 16 Jun 2014 16:56:32 +0000 [thread overview]
Message-ID: <8b0492b4697943a0b1f276ef42cc8223@DM2PR03MB352.namprd03.prod.outlook.com> (raw)
In-Reply-To: <20140616152739.GS16758-5wv7dgnIgG8@public.gmane.org>
> -----Original Message-----
> From: Will Deacon [mailto:will.deacon-5wv7dgnIgG8@public.gmane.org]
> Sent: Monday, June 16, 2014 10:28 AM
> To: Sethi Varun-B16395
> Cc: Thierry Reding; Mark Rutland; devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org; linux-
> samsung-soc-u79uwXL29TY76Z2rM5mHXA@public.gmane.org; Pawel Moll; Arnd Bergmann; Ian Campbell;
> Grant Grundler; Stephen Warren; linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org; Marc
> Zyngier; Linux IOMMU; Rob Herring; Kumar Gala; linux-
> tegra-u79uwXL29TY76Z2rM5mHXA@public.gmane.org; Cho KyongHo; Dave P Martin; linux-arm-
> kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org; Yoder Stuart-B08248
> Subject: Re: [PATCH v2] devicetree: Add generic IOMMU device tree
> bindings
>
> Hi Varun,
>
> On Thu, Jun 05, 2014 at 08:10:19PM +0100, Varun Sethi wrote:
> > > The set of StreamIDs that can be generated by a master is fixed in
> the
> > > hardware. The SMMU can then be programmed to map these incoming IDs
> onto
> > > a context ID (or a set of context IDs), which are the IDs used
> internally
> > > by the SMMU to find the page tables etc.
> > >
> > > The StreamID -> ContextID mapping is dynamic and controlled by
> software.
> > > The Master -> StreamIDs mapping is fixed in the hardware.
> > The Master -> StreamIDs mapping may not always be fixed in the
> hardware.
> > At, least in our case we plan to program these via software. PCI
> devices
> > is one place where this mapping would have to be dynamic (based on the
> > topology i.e. if the devices are connected to a bridge etc). Also, we
> have
> > a hot plug device architecture where the stream ID is software
> > programmable.
> >
> > Other than that, based on the isolation requirements (iommu domain)
> > software programmability offers greater flexibility.
>
> For the sake of consistency, I'd really like to treat the master ->
> streamIDs mapping as fixed. If that means setting it once during boot in
> your case, then so be it (ideally in the firmware). That way, we just
> describe the fixed mapping to the kernel and the driver doesn't have to
> worry about changing the mapping, especially given that that's likely to
> be
> highly error-prone once the SMMU is in us.
>
> Do you have use-cases where you really need to change these mappings
> dynamically?
Yes. In the case of a PCI bus-- you may not know in advance how many
PCI devices there are until you probe the bus. We have another FSL
proprietary bus we call the "fsl-mc" bus that is similar.
Another thing to consider-- starting with SMMUv2, as you know, there
is a new distributed architecture with multiple TBUs and a centralized
TCU that walks the SMMU page tables. So instead of sprinkling multiple
SMMUs all over an SoC you now have the option a 1 central TCU and sprinkling
multiple TBUs around. However, this means that the stream ID namespace
is now global and can be pretty limited. In the SMMU implementation we
have there are only 64 stream ID total for our Soc. But we have many more
masters than that.
So we look at stream IDs as really corresponding to an 'isolation context'
and not to a bus master. An isolation context is the domain you are
trying to isolate with the SMMU. Devices that all belong to the same
'isolation context' can share the same stream ID, since they share
the same domain and page tables.
So, perhaps by default some/most SMMU masters may have a default stream ID
of 0x0 that is used by the host...and that could be represented
statically in the device tree.
But, we absolutely will need to dynamically set new stream IDs
into masters when a new IOMMU 'domain' is created and devices
are added to it. All the devices in a domain will share
the same stream ID.
So whatever we do, let's please have an architecture flexible enough
to allow for this.
Thanks,
Stuart
WARNING: multiple messages have this Message-ID (diff)
From: Stuart Yoder <stuart.yoder@freescale.com>
To: Will Deacon <will.deacon@arm.com>,
Varun Sethi <Varun.Sethi@freescale.com>
Cc: Thierry Reding <thierry.reding@gmail.com>,
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>,
Pawel Moll <Pawel.Moll@arm.com>, "Arnd Bergmann" <arnd@arndb.de>,
Ian Campbell <ijc+devicetree@hellion.org.uk>,
"Grant Grundler" <grundler@chromium.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>,
Kumar Gala <galak@codeaurora.org>,
"linux-tegra@vger.kernel.org" <linux-tegra@vger.kernel.org>,
Cho KyongHo <pullip.cho@samsung.com>,
Dave P Martin <Dave.Martin@arm.com>,
"linux-arm-kernel@lists.infradead.org"
<linux-arm-kernel@lists.infradead.org>
Subject: RE: [PATCH v2] devicetree: Add generic IOMMU device tree bindings
Date: Mon, 16 Jun 2014 16:56:32 +0000 [thread overview]
Message-ID: <8b0492b4697943a0b1f276ef42cc8223@DM2PR03MB352.namprd03.prod.outlook.com> (raw)
In-Reply-To: <20140616152739.GS16758@arm.com>
> -----Original Message-----
> From: Will Deacon [mailto:will.deacon@arm.com]
> Sent: Monday, June 16, 2014 10:28 AM
> To: Sethi Varun-B16395
> Cc: Thierry Reding; Mark Rutland; devicetree@vger.kernel.org; linux-
> samsung-soc@vger.kernel.org; Pawel Moll; Arnd Bergmann; Ian Campbell;
> Grant Grundler; Stephen Warren; linux-kernel@vger.kernel.org; Marc
> Zyngier; Linux IOMMU; Rob Herring; Kumar Gala; linux-
> tegra@vger.kernel.org; Cho KyongHo; Dave P Martin; linux-arm-
> kernel@lists.infradead.org; Yoder Stuart-B08248
> Subject: Re: [PATCH v2] devicetree: Add generic IOMMU device tree
> bindings
>
> Hi Varun,
>
> On Thu, Jun 05, 2014 at 08:10:19PM +0100, Varun Sethi wrote:
> > > The set of StreamIDs that can be generated by a master is fixed in
> the
> > > hardware. The SMMU can then be programmed to map these incoming IDs
> onto
> > > a context ID (or a set of context IDs), which are the IDs used
> internally
> > > by the SMMU to find the page tables etc.
> > >
> > > The StreamID -> ContextID mapping is dynamic and controlled by
> software.
> > > The Master -> StreamIDs mapping is fixed in the hardware.
> > The Master -> StreamIDs mapping may not always be fixed in the
> hardware.
> > At, least in our case we plan to program these via software. PCI
> devices
> > is one place where this mapping would have to be dynamic (based on the
> > topology i.e. if the devices are connected to a bridge etc). Also, we
> have
> > a hot plug device architecture where the stream ID is software
> > programmable.
> >
> > Other than that, based on the isolation requirements (iommu domain)
> > software programmability offers greater flexibility.
>
> For the sake of consistency, I'd really like to treat the master ->
> streamIDs mapping as fixed. If that means setting it once during boot in
> your case, then so be it (ideally in the firmware). That way, we just
> describe the fixed mapping to the kernel and the driver doesn't have to
> worry about changing the mapping, especially given that that's likely to
> be
> highly error-prone once the SMMU is in us.
>
> Do you have use-cases where you really need to change these mappings
> dynamically?
Yes. In the case of a PCI bus-- you may not know in advance how many
PCI devices there are until you probe the bus. We have another FSL
proprietary bus we call the "fsl-mc" bus that is similar.
Another thing to consider-- starting with SMMUv2, as you know, there
is a new distributed architecture with multiple TBUs and a centralized
TCU that walks the SMMU page tables. So instead of sprinkling multiple
SMMUs all over an SoC you now have the option a 1 central TCU and sprinkling
multiple TBUs around. However, this means that the stream ID namespace
is now global and can be pretty limited. In the SMMU implementation we
have there are only 64 stream ID total for our Soc. But we have many more
masters than that.
So we look at stream IDs as really corresponding to an 'isolation context'
and not to a bus master. An isolation context is the domain you are
trying to isolate with the SMMU. Devices that all belong to the same
'isolation context' can share the same stream ID, since they share
the same domain and page tables.
So, perhaps by default some/most SMMU masters may have a default stream ID
of 0x0 that is used by the host...and that could be represented
statically in the device tree.
But, we absolutely will need to dynamically set new stream IDs
into masters when a new IOMMU 'domain' is created and devices
are added to it. All the devices in a domain will share
the same stream ID.
So whatever we do, let's please have an architecture flexible enough
to allow for this.
Thanks,
Stuart
WARNING: multiple messages have this Message-ID (diff)
From: stuart.yoder@freescale.com (Stuart Yoder)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH v2] devicetree: Add generic IOMMU device tree bindings
Date: Mon, 16 Jun 2014 16:56:32 +0000 [thread overview]
Message-ID: <8b0492b4697943a0b1f276ef42cc8223@DM2PR03MB352.namprd03.prod.outlook.com> (raw)
In-Reply-To: <20140616152739.GS16758@arm.com>
> -----Original Message-----
> From: Will Deacon [mailto:will.deacon at arm.com]
> Sent: Monday, June 16, 2014 10:28 AM
> To: Sethi Varun-B16395
> Cc: Thierry Reding; Mark Rutland; devicetree at vger.kernel.org; linux-
> samsung-soc at vger.kernel.org; Pawel Moll; Arnd Bergmann; Ian Campbell;
> Grant Grundler; Stephen Warren; linux-kernel at vger.kernel.org; Marc
> Zyngier; Linux IOMMU; Rob Herring; Kumar Gala; linux-
> tegra at vger.kernel.org; Cho KyongHo; Dave P Martin; linux-arm-
> kernel at lists.infradead.org; Yoder Stuart-B08248
> Subject: Re: [PATCH v2] devicetree: Add generic IOMMU device tree
> bindings
>
> Hi Varun,
>
> On Thu, Jun 05, 2014 at 08:10:19PM +0100, Varun Sethi wrote:
> > > The set of StreamIDs that can be generated by a master is fixed in
> the
> > > hardware. The SMMU can then be programmed to map these incoming IDs
> onto
> > > a context ID (or a set of context IDs), which are the IDs used
> internally
> > > by the SMMU to find the page tables etc.
> > >
> > > The StreamID -> ContextID mapping is dynamic and controlled by
> software.
> > > The Master -> StreamIDs mapping is fixed in the hardware.
> > The Master -> StreamIDs mapping may not always be fixed in the
> hardware.
> > At, least in our case we plan to program these via software. PCI
> devices
> > is one place where this mapping would have to be dynamic (based on the
> > topology i.e. if the devices are connected to a bridge etc). Also, we
> have
> > a hot plug device architecture where the stream ID is software
> > programmable.
> >
> > Other than that, based on the isolation requirements (iommu domain)
> > software programmability offers greater flexibility.
>
> For the sake of consistency, I'd really like to treat the master ->
> streamIDs mapping as fixed. If that means setting it once during boot in
> your case, then so be it (ideally in the firmware). That way, we just
> describe the fixed mapping to the kernel and the driver doesn't have to
> worry about changing the mapping, especially given that that's likely to
> be
> highly error-prone once the SMMU is in us.
>
> Do you have use-cases where you really need to change these mappings
> dynamically?
Yes. In the case of a PCI bus-- you may not know in advance how many
PCI devices there are until you probe the bus. We have another FSL
proprietary bus we call the "fsl-mc" bus that is similar.
Another thing to consider-- starting with SMMUv2, as you know, there
is a new distributed architecture with multiple TBUs and a centralized
TCU that walks the SMMU page tables. So instead of sprinkling multiple
SMMUs all over an SoC you now have the option a 1 central TCU and sprinkling
multiple TBUs around. However, this means that the stream ID namespace
is now global and can be pretty limited. In the SMMU implementation we
have there are only 64 stream ID total for our Soc. But we have many more
masters than that.
So we look at stream IDs as really corresponding to an 'isolation context'
and not to a bus master. An isolation context is the domain you are
trying to isolate with the SMMU. Devices that all belong to the same
'isolation context' can share the same stream ID, since they share
the same domain and page tables.
So, perhaps by default some/most SMMU masters may have a default stream ID
of 0x0 that is used by the host...and that could be represented
statically in the device tree.
But, we absolutely will need to dynamically set new stream IDs
into masters when a new IOMMU 'domain' is created and devices
are added to it. All the devices in a domain will share
the same stream ID.
So whatever we do, let's please have an architecture flexible enough
to allow for this.
Thanks,
Stuart
next prev parent reply other threads:[~2014-06-16 16:56 UTC|newest]
Thread overview: 215+ 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
2014-06-16 15:27 ` Will Deacon
[not found] ` <20140616152739.GS16758-5wv7dgnIgG8@public.gmane.org>
2014-06-16 16:56 ` Stuart Yoder [this message]
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
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-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=8b0492b4697943a0b1f276ef42cc8223@DM2PR03MB352.namprd03.prod.outlook.com \
--to=stuart.yoder-kzfg59tc24xl57midrcfdg@public.gmane.org \
--cc=Dave.Martin-5wv7dgnIgG8@public.gmane.org \
--cc=Marc.Zyngier-5wv7dgnIgG8@public.gmane.org \
--cc=Mark.Rutland-5wv7dgnIgG8@public.gmane.org \
--cc=Pawel.Moll-5wv7dgnIgG8@public.gmane.org \
--cc=Varun.Sethi-KZfg59tc24xl57MIdRCFDg@public.gmane.org \
--cc=arnd-r2nGTMty4D4@public.gmane.org \
--cc=devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=galak-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org \
--cc=grundler-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org \
--cc=ijc+devicetree-KcIKpvwj1kUDXYZnReoRVg@public.gmane.org \
--cc=iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org \
--cc=linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org \
--cc=linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=linux-samsung-soc-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=linux-tegra-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=pullip.cho-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org \
--cc=robh+dt-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org \
--cc=swarren-3lzwWm7+Weoh9ZMKESR00Q@public.gmane.org \
--cc=thierry.reding-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org \
--cc=will.deacon-5wv7dgnIgG8@public.gmane.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.