All of lore.kernel.org
 help / color / mirror / Atom feed
From: Thierry Reding <thierry.reding-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
To: Arnd Bergmann <arnd-r2nGTMty4D4@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>,
	Ian Campbell
	<ijc+devicetree-KcIKpvwj1kUDXYZnReoRVg@public.gmane.org>,
	Grant Grundler <grundler-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org>,
	Stephen Warren <swarren-3lzwWm7+Weoh9ZMKESR00Q@public.gmane.org>,
	Will Deacon <will.deacon-5wv7dgnIgG8@public.gmane.org>,
	"linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org"
	<linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
	Marc Zyngier <marc.zyngier-5wv7dgnIgG8@public.gmane.org>,
	Linux IOMMU
	<iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org>,
	Rob Herring <robh+dt-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>,
	Rob Herring <robherring2-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 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: Wed, 4 Jun 2014 15:44:03 +0200	[thread overview]
Message-ID: <20140604134400.GE28484@ulmo> (raw)
In-Reply-To: <4462924.8iRbdkOPp7@wuerfel>


[-- Attachment #1.1: Type: text/plain, Size: 2671 bytes --]

On Fri, May 30, 2014 at 09:54:37PM +0200, Arnd Bergmann wrote:
> On Friday 30 May 2014 22:29:13 Hiroshi Doyu wrote:
> > 
> > IIUC the original problem, "a master with 8 streamIDs" means something
> > like below, where some devices have multiple IDs but some have a
> > single. A sinle #address-cells cannot afford those 2 masters at once.
> > 
> >        iommu {
> >                /* the specifier represents the ID of the master */
> >                #address-cells = <1>;
> >                #size-cells = <0>;
> >        };
> > 
> >         master@a {
> >                 ...
> >                 iommus = <&smmu 1 2 3>; # 3 IDs
> >         };
> > 
> >         master@b {
> >                 ...
> >                 iommus = <&smmu 4>;     # 1 ID
> >         };
> 
> This would not be the usual format really. It should instead be
> 
> 		iommus = <&smmu 1>, <&smmu 2>, <&smmu 3>;
> 
> which can be tedious to type.

"Tedious to type" doesn't sound like a good argument to me. I don't see
why the above would necessarily be a bad notation. It's very much up to
the point and very explicit. This very obviously translates to:

	This device has three master interfaces, one for smmu ID 1, one
	for smmu ID 2 and one for smmu ID 3.

> > Tegra,SMMU has a similar problem and we have used a fixed size bitmap(64
> > bit) to afford 64 stream IDs so that a single device can hold multiple
> > IDs. If we apply the same bitmap to the above exmaple:
> > 
> >        iommu {
> >                /* the specifier represents the ID of the master */
> >                #address-cells = <1>;
> >                #size-cells = <0>;
> >        };
> > 
> >         master@a {
> >                 ...
> >                 iommus = <&smmu (BIT(1) | BIT(2) | BIT(3))>; # IDs 1 2 3
> >         };
> > 
> >         master@b {
> >                 ...
> >                 iommus = <&smmu BIT(4)>;     # ID 4
> >         };
> > 
> > The disadvantage of this is that this limits the max number of streamIDs
> > to support. If # of streamID is increased later more than 64, this
> > format cannot cover any more. You have to predict the max # of streamIDs
> > in advance if steamID is statically assigned.
> > 
> 
> Well, the iommu specific binding could allow a variable #address-cells.
> That way, you just need to know the number of stream IDs for that instance
> of the iommu.

That sounds fairly complicated to me. I don't see what that buys us over
the clarity and simplicity that the above explicit notation gives us. Is
it not more common for a device to have a single master rather than a
whole bunch of them?

Thierry

[-- Attachment #1.2: Type: application/pgp-signature, Size: 836 bytes --]

[-- Attachment #2: Type: text/plain, Size: 0 bytes --]



WARNING: multiple messages have this Message-ID (diff)
From: Thierry Reding <thierry.reding@gmail.com>
To: Arnd Bergmann <arnd@arndb.de>
Cc: Hiroshi Doyu <hdoyu@nvidia.com>,
	Rob Herring <robherring2@gmail.com>,
	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>,
	Dave Martin <Dave.Martin@arm.com>,
	Marc Zyngier <marc.zyngier@arm.com>,
	Will Deacon <will.deacon@arm.com>, Joerg Roedel <joro@8bytes.org>,
	Stephen Warren <swarren@wwwdotorg.org>,
	"devicetree@vger.kernel.org" <devicetree@vger.kernel.org>,
	Linux IOMMU <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 15:44:03 +0200	[thread overview]
Message-ID: <20140604134400.GE28484@ulmo> (raw)
In-Reply-To: <4462924.8iRbdkOPp7@wuerfel>

[-- Attachment #1: Type: text/plain, Size: 2671 bytes --]

On Fri, May 30, 2014 at 09:54:37PM +0200, Arnd Bergmann wrote:
> On Friday 30 May 2014 22:29:13 Hiroshi Doyu wrote:
> > 
> > IIUC the original problem, "a master with 8 streamIDs" means something
> > like below, where some devices have multiple IDs but some have a
> > single. A sinle #address-cells cannot afford those 2 masters at once.
> > 
> >        iommu {
> >                /* the specifier represents the ID of the master */
> >                #address-cells = <1>;
> >                #size-cells = <0>;
> >        };
> > 
> >         master@a {
> >                 ...
> >                 iommus = <&smmu 1 2 3>; # 3 IDs
> >         };
> > 
> >         master@b {
> >                 ...
> >                 iommus = <&smmu 4>;     # 1 ID
> >         };
> 
> This would not be the usual format really. It should instead be
> 
> 		iommus = <&smmu 1>, <&smmu 2>, <&smmu 3>;
> 
> which can be tedious to type.

"Tedious to type" doesn't sound like a good argument to me. I don't see
why the above would necessarily be a bad notation. It's very much up to
the point and very explicit. This very obviously translates to:

	This device has three master interfaces, one for smmu ID 1, one
	for smmu ID 2 and one for smmu ID 3.

> > Tegra,SMMU has a similar problem and we have used a fixed size bitmap(64
> > bit) to afford 64 stream IDs so that a single device can hold multiple
> > IDs. If we apply the same bitmap to the above exmaple:
> > 
> >        iommu {
> >                /* the specifier represents the ID of the master */
> >                #address-cells = <1>;
> >                #size-cells = <0>;
> >        };
> > 
> >         master@a {
> >                 ...
> >                 iommus = <&smmu (BIT(1) | BIT(2) | BIT(3))>; # IDs 1 2 3
> >         };
> > 
> >         master@b {
> >                 ...
> >                 iommus = <&smmu BIT(4)>;     # ID 4
> >         };
> > 
> > The disadvantage of this is that this limits the max number of streamIDs
> > to support. If # of streamID is increased later more than 64, this
> > format cannot cover any more. You have to predict the max # of streamIDs
> > in advance if steamID is statically assigned.
> > 
> 
> Well, the iommu specific binding could allow a variable #address-cells.
> That way, you just need to know the number of stream IDs for that instance
> of the iommu.

That sounds fairly complicated to me. I don't see what that buys us over
the clarity and simplicity that the above explicit notation gives us. Is
it not more common for a device to have a single master rather than a
whole bunch of them?

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 15:44:03 +0200	[thread overview]
Message-ID: <20140604134400.GE28484@ulmo> (raw)
In-Reply-To: <4462924.8iRbdkOPp7@wuerfel>

On Fri, May 30, 2014 at 09:54:37PM +0200, Arnd Bergmann wrote:
> On Friday 30 May 2014 22:29:13 Hiroshi Doyu wrote:
> > 
> > IIUC the original problem, "a master with 8 streamIDs" means something
> > like below, where some devices have multiple IDs but some have a
> > single. A sinle #address-cells cannot afford those 2 masters at once.
> > 
> >        iommu {
> >                /* the specifier represents the ID of the master */
> >                #address-cells = <1>;
> >                #size-cells = <0>;
> >        };
> > 
> >         master at a {
> >                 ...
> >                 iommus = <&smmu 1 2 3>; # 3 IDs
> >         };
> > 
> >         master at b {
> >                 ...
> >                 iommus = <&smmu 4>;     # 1 ID
> >         };
> 
> This would not be the usual format really. It should instead be
> 
> 		iommus = <&smmu 1>, <&smmu 2>, <&smmu 3>;
> 
> which can be tedious to type.

"Tedious to type" doesn't sound like a good argument to me. I don't see
why the above would necessarily be a bad notation. It's very much up to
the point and very explicit. This very obviously translates to:

	This device has three master interfaces, one for smmu ID 1, one
	for smmu ID 2 and one for smmu ID 3.

> > Tegra,SMMU has a similar problem and we have used a fixed size bitmap(64
> > bit) to afford 64 stream IDs so that a single device can hold multiple
> > IDs. If we apply the same bitmap to the above exmaple:
> > 
> >        iommu {
> >                /* the specifier represents the ID of the master */
> >                #address-cells = <1>;
> >                #size-cells = <0>;
> >        };
> > 
> >         master at a {
> >                 ...
> >                 iommus = <&smmu (BIT(1) | BIT(2) | BIT(3))>; # IDs 1 2 3
> >         };
> > 
> >         master at b {
> >                 ...
> >                 iommus = <&smmu BIT(4)>;     # ID 4
> >         };
> > 
> > The disadvantage of this is that this limits the max number of streamIDs
> > to support. If # of streamID is increased later more than 64, this
> > format cannot cover any more. You have to predict the max # of streamIDs
> > in advance if steamID is statically assigned.
> > 
> 
> Well, the iommu specific binding could allow a variable #address-cells.
> That way, you just need to know the number of stream IDs for that instance
> of the iommu.

That sounds fairly complicated to me. I don't see what that buys us over
the clarity and simplicity that the above explicit notation gives us. Is
it not more common for a device to have a single master rather than a
whole bunch of them?

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/8714474f/attachment.sig>

  parent reply	other threads:[~2014-06-04 13:44 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 [this message]
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
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=20140604134400.GE28484@ulmo \
    --to=thierry.reding-re5jqeeqqe8avxtiumwx3w@public.gmane.org \
    --cc=Dave.Martin-5wv7dgnIgG8@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=marc.zyngier-5wv7dgnIgG8@public.gmane.org \
    --cc=mark.rutland-5wv7dgnIgG8@public.gmane.org \
    --cc=pawel.moll-5wv7dgnIgG8@public.gmane.org \
    --cc=pullip.cho-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org \
    --cc=robh+dt-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org \
    --cc=robherring2-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org \
    --cc=swarren-3lzwWm7+Weoh9ZMKESR00Q@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.