From: Jassi Brar <jaswinder.singh@linaro.org> To: Stephen Warren <swarren@wwwdotorg.org> Cc: Arnd Bergmann <arnd@arndb.de>, Stephen Warren <swarren@nvidia.com>, Benoit Cousson <b-cousson@ti.com>, device-tree <devicetree-discuss@lists.ozlabs.org>, Nicolas Ferre <nicolas.ferre@atmel.com>, Rob Herring <rob.herring@calxeda.com>, Grant Likely <grant.likely@secretlab.ca>, Jon Hunter <jon-hunter@ti.com>, Russell King <linux@arm.linux.org.uk>, linux-omap <linux-omap@vger.kernel.org>, linux-arm <linux-arm-kernel@lists.infradead.org> Subject: Re: [PATCH V3 1/2] of: Add generic device tree DMA helpers Date: Thu, 10 May 2012 03:08:57 +0530 [thread overview] Message-ID: <CAJe_Zhcrr2QqoY=H3=3EJLPQBjC3Yc43EDjqYXaNok9-T+=0yw@mail.gmail.com> (raw) In-Reply-To: <4FAAC111.9020308@wwwdotorg.org> On 10 May 2012 00:40, Stephen Warren <swarren@wwwdotorg.org> wrote: > On 05/08/2012 01:09 PM, Jassi Brar wrote: >> >> There is important difference between providing data via clients >> during runtime vs providing info about every client to the dmac driver >> at one go during its probe. > > I certainly see that there is a difference. > > I don't understand why it's an important difference; I think everything > needs to be handled at run-time no matter what: > > Just because there is information in the DT that "this client DT node > uses this channel/request-ID/... of this DMA controller" doesn't mean > that the driver for the client is going to be loaded, or that SW running > on the system is going to cause that driver to actually be opened and do > any DMA. As such, any resource allocation rules etc. must be evaluated > only if/when a driver actually requests/uses a DMA channel, so having > "all the information up front" doesn't seem like a theoretically > possible thing anyway. > One point is about 'qos' here.... something like bandwidth allocation. If the dmac driver knew up-front the max possible clients that could be active simultaneously, it could "divide the bandwidth" accordingly. Again, the example of PL330 employing 2physical channels for better service - LLI (you got it right), where even 1 physical channel would also have served only not as reliably. I believe there would be more such scenarios. Another minor benefit could be that the dmac driver populate only as many "struct dma_chan" as there are actually clients on the machine (and this population has to be done during probe). It could mean ~8 instead of ~40 channels populated on a machine. Note, a PL330 dmac can have 32 channels, OMAP's has 128.... Most importantly, I just think it's a cleaner approach. > Very similar to this, in order to support your point that a given client > could potentially use a channel from either of 2 different DMA > controller instances, you don't know until run-time which controller > will be used, so can't have up-front information in this scenario > either, even if the DMA does actually take place. > Sorry, perhaps I wasn't clear enough. A client sees _no_ difference between the two channels that could serve it. And it can't start using two, if two are available. Client just needs one suitable channel on whichever dmac that might be. If the channel for a client is to be switched runtime, that decision should lie with the dmac driver, not the client. And I am not really after implementing that runtime decision support. > Solving (b) seems to require something very roughly like: > > dma-controller@0 { > compatible = "foo,dmac-xxx"; > dma-requests = < > &client0 0 // DMAC req 0 is client0's 0th req output > &client0 1 > &client1 0 > &client1 1 > &client2 0 > ...>; > }; > > dma-controller@1 { > compatible = "bar,dmac-yyy"; > dma-requests = < > // Supports some client modules, but not the same ones > &client0 0 > &client1 0 > &client3 0 > ...>; > }; > > client0: i2s { > /* has 2 DMA request output signals: 0, 1 */ > }; > > client1: spdif { > /* has 2 DMA request signals: 0, 1 */ > }; > > client2: foo { > /* has 1 DMA request signal: 0 */ > }; > > client3: bar { > /* has 1 DMA request signal: 0 */ > }; > > and then having the core DMA code have an API like: > > channel = dma_request(clients_dma_req_output_id) > > which looks in each DMA controller's dma-requests list for the client's > phandle and matching dma_req_output_id. > Almost what I proposed in my third post in this thread !! The minor difference being, you use the {request-signal, phandle} pair to find the right channel, I used only 'token'. Please note, with this method we specify info about every client at one go and via dmac's DT node - hence those benefits. Also note that, a client's dma specifier becomes perfectly general and future-proof client1: spdif { dma_tx = <278> dma_rx = <723> }; otherwise the following representation client1: spdif { dma = <&sdma 2 1 &sdma 3 2>; }; could break with some weird dma setups (IIANW Russell already finds it wouldn't work for him). I am arguing for (b) for the above mentioned reasons, and not because I want to have clients switching channels in runtime. Thanks, Jassi -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
WARNING: multiple messages have this Message-ID (diff)
From: jaswinder.singh@linaro.org (Jassi Brar) To: linux-arm-kernel@lists.infradead.org Subject: [PATCH V3 1/2] of: Add generic device tree DMA helpers Date: Thu, 10 May 2012 03:08:57 +0530 [thread overview] Message-ID: <CAJe_Zhcrr2QqoY=H3=3EJLPQBjC3Yc43EDjqYXaNok9-T+=0yw@mail.gmail.com> (raw) In-Reply-To: <4FAAC111.9020308@wwwdotorg.org> On 10 May 2012 00:40, Stephen Warren <swarren@wwwdotorg.org> wrote: > On 05/08/2012 01:09 PM, Jassi Brar wrote: >> >> There is important difference between providing data via clients >> during runtime vs providing info about every client to the dmac driver >> at one go during its probe. > > I certainly see that there is a difference. > > I don't understand why it's an important difference; I think everything > needs to be handled at run-time no matter what: > > Just because there is information in the DT that "this client DT node > uses this channel/request-ID/... of this DMA controller" doesn't mean > that the driver for the client is going to be loaded, or that SW running > on the system is going to cause that driver to actually be opened and do > any DMA. As such, any resource allocation rules etc. must be evaluated > only if/when a driver actually requests/uses a DMA channel, so having > "all the information up front" doesn't seem like a theoretically > possible thing anyway. > One point is about 'qos' here.... something like bandwidth allocation. If the dmac driver knew up-front the max possible clients that could be active simultaneously, it could "divide the bandwidth" accordingly. Again, the example of PL330 employing 2physical channels for better service - LLI (you got it right), where even 1 physical channel would also have served only not as reliably. I believe there would be more such scenarios. Another minor benefit could be that the dmac driver populate only as many "struct dma_chan" as there are actually clients on the machine (and this population has to be done during probe). It could mean ~8 instead of ~40 channels populated on a machine. Note, a PL330 dmac can have 32 channels, OMAP's has 128.... Most importantly, I just think it's a cleaner approach. > Very similar to this, in order to support your point that a given client > could potentially use a channel from either of 2 different DMA > controller instances, you don't know until run-time which controller > will be used, so can't have up-front information in this scenario > either, even if the DMA does actually take place. > Sorry, perhaps I wasn't clear enough. A client sees _no_ difference between the two channels that could serve it. And it can't start using two, if two are available. Client just needs one suitable channel on whichever dmac that might be. If the channel for a client is to be switched runtime, that decision should lie with the dmac driver, not the client. And I am not really after implementing that runtime decision support. > Solving (b) seems to require something very roughly like: > > dma-controller at 0 { > ? ?compatible = "foo,dmac-xxx"; > ? ?dma-requests = < > ? ? ? ? ? ? ? ?&client0 0 // DMAC req 0 is client0's 0th req output > ? ? ? ? ? ? ? ?&client0 1 > ? ? ? ? ? ? ? ?&client1 0 > ? ? ? ? ? ? ? ?&client1 1 > ? ? ? ? ? ? ? ?&client2 0 > ? ? ? ? ? ? ? ?...>; > }; > > dma-controller at 1 { > ? ?compatible = "bar,dmac-yyy"; > ? ?dma-requests = < > ? ? ? ? ? ? ? ?// Supports some client modules, but not the same ones > ? ? ? ? ? ? ? ?&client0 0 > ? ? ? ? ? ? ? ?&client1 0 > ? ? ? ? ? ? ? ?&client3 0 > ? ? ? ? ? ? ? ?...>; > }; > > client0: i2s { > ? ?/* has 2 DMA request output signals: 0, 1 */ > }; > > client1: spdif { > ? ?/* has 2 DMA request signals: 0, 1 */ > }; > > client2: foo { > ? ?/* has 1 DMA request signal: 0 */ > }; > > client3: bar { > ? ?/* has 1 DMA request signal: 0 */ > }; > > and then having the core DMA code have an API like: > > channel = dma_request(clients_dma_req_output_id) > > which looks in each DMA controller's dma-requests list for the client's > phandle and matching dma_req_output_id. > Almost what I proposed in my third post in this thread !! The minor difference being, you use the {request-signal, phandle} pair to find the right channel, I used only 'token'. Please note, with this method we specify info about every client at one go and via dmac's DT node - hence those benefits. Also note that, a client's dma specifier becomes perfectly general and future-proof client1: spdif { dma_tx = <278> dma_rx = <723> }; otherwise the following representation client1: spdif { dma = <&sdma 2 1 &sdma 3 2>; }; could break with some weird dma setups (IIANW Russell already finds it wouldn't work for him). I am arguing for (b) for the above mentioned reasons, and not because I want to have clients switching channels in runtime. Thanks, Jassi
next prev parent reply other threads:[~2012-05-09 21:38 UTC|newest] Thread overview: 258+ messages / expand[flat|nested] mbox.gz Atom feed top 2012-04-30 21:17 [PATCH V3 1/2] of: Add generic device tree DMA helpers Jon Hunter 2012-04-30 21:17 ` Jon Hunter 2012-05-03 22:26 ` Stephen Warren 2012-05-03 22:26 ` Stephen Warren [not found] ` <4FA30604.1030401-3lzwWm7+Weoh9ZMKESR00Q@public.gmane.org> 2012-05-03 23:25 ` Russell King - ARM Linux 2012-05-03 23:25 ` Russell King - ARM Linux 2012-05-04 12:39 ` Arnd Bergmann 2012-05-04 12:39 ` Arnd Bergmann 2012-05-04 15:06 ` Jon Hunter 2012-05-04 15:06 ` Jon Hunter [not found] ` <4FA3F08D.7030603-l0cyMroinI0@public.gmane.org> 2012-05-04 15:14 ` Russell King - ARM Linux 2012-05-04 15:14 ` Russell King - ARM Linux 2012-05-04 18:21 ` Stephen Warren 2012-05-04 18:21 ` Stephen Warren 2012-05-04 19:19 ` Jon Hunter 2012-05-04 19:19 ` Jon Hunter 2012-05-04 6:56 ` Jassi Brar 2012-05-04 6:56 ` Jassi Brar 2012-05-04 15:17 ` Jon Hunter 2012-05-04 15:17 ` Jon Hunter 2012-05-04 19:01 ` Jassi Brar 2012-05-04 19:01 ` Jassi Brar 2012-05-04 19:23 ` Arnd Bergmann 2012-05-04 19:23 ` Arnd Bergmann 2012-05-05 17:10 ` Jassi Brar 2012-05-05 17:10 ` Jassi Brar 2012-05-07 15:53 ` Stephen Warren 2012-05-07 15:53 ` Stephen Warren 2012-05-07 17:19 ` Jassi Brar 2012-05-07 17:19 ` Jassi Brar 2012-05-08 16:35 ` Stephen Warren 2012-05-08 16:35 ` Stephen Warren 2012-05-08 19:09 ` Jassi Brar 2012-05-08 19:09 ` Jassi Brar 2012-05-09 12:30 ` Arnd Bergmann 2012-05-09 12:30 ` Arnd Bergmann 2012-05-09 19:10 ` Stephen Warren 2012-05-09 19:10 ` Stephen Warren 2012-05-09 21:38 ` Jassi Brar [this message] 2012-05-09 21:38 ` Jassi Brar 2012-05-10 17:00 ` Stephen Warren 2012-05-10 17:00 ` Stephen Warren 2012-05-10 19:59 ` Jassi Brar 2012-05-10 19:59 ` Jassi Brar 2012-05-11 19:28 ` Stephen Warren 2012-05-11 19:28 ` Stephen Warren 2012-05-11 21:06 ` Jassi Brar 2012-05-11 21:06 ` Jassi Brar 2012-05-11 23:51 ` Stephen Warren 2012-05-11 23:51 ` Stephen Warren 2012-05-12 13:40 ` Jassi Brar 2012-05-12 13:40 ` Jassi Brar 2012-05-16 1:05 ` Jon Hunter 2012-05-16 1:05 ` Jon Hunter 2012-05-17 13:18 ` Russell King - ARM Linux 2012-05-17 13:18 ` Russell King - ARM Linux 2012-05-07 17:21 ` Arnd Bergmann 2012-05-07 17:21 ` Arnd Bergmann 2012-05-16 1:11 ` Jon Hunter 2012-05-16 1:11 ` Jon Hunter 2012-05-16 12:37 ` Jassi Brar 2012-05-16 12:37 ` Jassi Brar 2012-05-16 13:15 ` Jon Hunter 2012-05-16 13:15 ` Jon Hunter 2012-05-16 15:44 ` Stephen Warren 2012-05-16 15:44 ` Stephen Warren 2012-05-16 16:04 ` Jon Hunter 2012-05-16 16:04 ` Jon Hunter 2012-05-16 16:01 ` Jon Hunter 2012-05-16 16:01 ` Jon Hunter 2012-05-16 16:15 ` Stephen Warren 2012-05-16 16:15 ` Stephen Warren 2012-05-16 16:22 ` Jassi Brar 2012-05-16 16:22 ` Jassi Brar 2012-05-16 17:09 ` Jon Hunter 2012-05-16 17:09 ` Jon Hunter 2012-05-16 19:42 ` Arnd Bergmann 2012-05-16 19:42 ` Arnd Bergmann 2012-05-16 21:16 ` Jassi Brar 2012-05-16 21:16 ` Jassi Brar 2012-05-17 19:32 ` Stephen Warren 2012-05-17 19:32 ` Stephen Warren 2012-05-18 17:12 ` Jassi Brar 2012-05-18 17:12 ` Jassi Brar 2012-05-18 21:04 ` Arnd Bergmann 2012-05-18 21:04 ` Arnd Bergmann 2012-05-16 23:59 ` Stephen Warren 2012-05-16 23:59 ` Stephen Warren 2012-05-17 4:05 ` Jassi Brar 2012-05-17 4:05 ` Jassi Brar 2012-05-18 20:49 ` Arnd Bergmann 2012-05-18 20:49 ` Arnd Bergmann 2012-05-18 21:07 ` Stephen Warren 2012-05-18 21:07 ` Stephen Warren 2012-05-18 21:43 ` Arnd Bergmann 2012-05-18 21:43 ` Arnd Bergmann 2012-05-18 22:20 ` Stephen Warren 2012-05-18 22:20 ` Stephen Warren 2012-05-19 8:44 ` Arnd Bergmann 2012-05-19 8:44 ` Arnd Bergmann 2012-05-21 17:33 ` Stephen Warren 2012-05-21 17:33 ` Stephen Warren 2012-05-21 18:18 ` Arnd Bergmann 2012-05-21 18:18 ` Arnd Bergmann 2012-05-21 20:32 ` Stephen Warren 2012-05-21 20:32 ` Stephen Warren 2012-06-08 19:04 ` Jon Hunter 2012-06-08 19:04 ` Jon Hunter 2012-06-09 0:04 ` Arnd Bergmann 2012-06-09 0:04 ` Arnd Bergmann 2012-06-13 22:32 ` Jon Hunter 2012-06-13 22:32 ` Jon Hunter 2012-06-14 4:45 ` Jassi Brar 2012-06-14 4:45 ` Jassi Brar 2012-06-14 11:48 ` Arnd Bergmann 2012-06-14 11:48 ` Arnd Bergmann 2012-06-14 15:39 ` Jon Hunter 2012-06-14 15:39 ` Jon Hunter 2012-06-15 8:40 ` Arnd Bergmann 2012-06-15 8:40 ` Arnd Bergmann 2012-06-22 22:52 ` Jon Hunter 2012-06-22 22:52 ` Jon Hunter [not found] ` <4FE4F718.3080204-l0cyMroinI0@public.gmane.org> 2012-06-22 23:12 ` Russell King - ARM Linux 2012-06-22 23:12 ` Russell King - ARM Linux 2012-06-25 16:51 ` Jon Hunter 2012-06-25 16:51 ` Jon Hunter 2012-06-25 18:04 ` Vinod Koul 2012-06-25 18:04 ` Vinod Koul 2012-06-25 20:30 ` Arnd Bergmann 2012-06-25 20:30 ` Arnd Bergmann 2012-06-26 9:40 ` Vinod Koul 2012-06-26 9:40 ` Vinod Koul 2012-06-26 14:59 ` Arnd Bergmann 2012-06-26 14:59 ` Arnd Bergmann 2012-06-26 17:50 ` Vinod Koul 2012-06-26 17:50 ` Vinod Koul 2012-06-26 20:27 ` Arnd Bergmann 2012-06-26 20:27 ` Arnd Bergmann 2012-06-27 13:45 ` Vinod Koul 2012-06-27 13:45 ` Vinod Koul 2012-06-27 15:20 ` Arnd Bergmann 2012-06-27 15:20 ` Arnd Bergmann 2012-07-13 6:45 ` Vinod Koul 2012-07-13 6:45 ` Vinod Koul 2012-07-13 21:52 ` Guennadi Liakhovetski 2012-07-13 21:52 ` Guennadi Liakhovetski 2012-07-17 19:24 ` Arnd Bergmann 2012-07-17 19:24 ` Arnd Bergmann 2012-07-20 4:00 ` Vinod Koul 2012-07-20 4:00 ` Vinod Koul 2012-07-20 8:39 ` Arnd Bergmann 2012-07-20 8:39 ` Arnd Bergmann 2012-07-20 9:37 ` Vinod Koul 2012-07-20 9:37 ` Vinod Koul 2012-07-24 19:07 ` Jon Hunter 2012-07-24 19:07 ` Jon Hunter 2012-07-24 19:27 ` Arnd Bergmann 2012-07-24 19:27 ` Arnd Bergmann 2012-07-26 6:42 ` Vinod Koul 2012-07-26 6:42 ` Vinod Koul 2012-07-26 7:14 ` Arnd Bergmann 2012-07-26 7:14 ` Arnd Bergmann 2012-07-26 11:28 ` Vinod Koul 2012-07-26 11:28 ` Vinod Koul 2012-07-26 15:53 ` Jon Hunter 2012-07-26 15:53 ` Jon Hunter [not found] ` <5011680A.6040400-l0cyMroinI0@public.gmane.org> 2012-07-31 11:06 ` Vinod Koul 2012-07-31 11:06 ` Vinod Koul 2012-07-26 17:43 ` Jon Hunter 2012-07-26 17:43 ` Jon Hunter 2012-07-31 11:12 ` Vinod Koul 2012-07-31 11:12 ` Vinod Koul 2012-08-01 20:43 ` Jon Hunter 2012-08-01 20:43 ` Jon Hunter 2012-08-03 9:55 ` Vinod Koul 2012-08-03 9:55 ` Vinod Koul 2012-07-20 9:08 ` Robert Jarzmik 2012-07-20 9:08 ` Robert Jarzmik 2012-07-20 9:41 ` Vinod Koul 2012-07-20 9:41 ` Vinod Koul 2012-07-26 4:56 ` zhangfei gao 2012-07-26 4:56 ` zhangfei gao 2012-07-23 21:29 ` Stephen Warren 2012-07-23 21:29 ` Stephen Warren 2012-07-24 7:19 ` Arnd Bergmann 2012-07-24 7:19 ` Arnd Bergmann 2012-07-24 16:04 ` Stephen Warren 2012-07-24 16:04 ` Stephen Warren 2012-07-24 18:55 ` Arnd Bergmann 2012-07-24 18:55 ` Arnd Bergmann 2012-07-24 12:54 ` Sergei Shtylyov 2012-07-24 12:54 ` Sergei Shtylyov 2012-07-06 11:36 ` Guennadi Liakhovetski 2012-07-06 11:36 ` Guennadi Liakhovetski [not found] ` <Pine.LNX.4.64.1207061315470.29809-0199iw4Nj15frtckUFj5Ag@public.gmane.org> 2012-07-06 15:28 ` Arnd Bergmann 2012-07-06 15:28 ` Arnd Bergmann [not found] ` <201207061528.58291.arnd-r2nGTMty4D4@public.gmane.org> 2012-07-06 15:43 ` Guennadi Liakhovetski 2012-07-06 15:43 ` Guennadi Liakhovetski 2012-07-06 17:31 ` Arnd Bergmann 2012-07-06 17:31 ` Arnd Bergmann 2012-07-06 21:01 ` Russell King - ARM Linux 2012-07-06 21:01 ` Russell King - ARM Linux 2012-07-06 20:57 ` Russell King - ARM Linux 2012-07-06 20:57 ` Russell King - ARM Linux 2012-07-06 22:49 ` Guennadi Liakhovetski 2012-07-06 22:49 ` Guennadi Liakhovetski 2012-07-13 6:51 ` Vinod Koul 2012-07-13 6:51 ` Vinod Koul 2012-06-14 15:17 ` Guennadi Liakhovetski 2012-06-14 15:17 ` Guennadi Liakhovetski 2012-06-14 21:52 ` Jon Hunter 2012-06-14 21:52 ` Jon Hunter 2012-06-15 8:41 ` Guennadi Liakhovetski 2012-06-15 8:41 ` Guennadi Liakhovetski 2012-06-15 9:00 ` Arnd Bergmann 2012-06-15 9:00 ` Arnd Bergmann 2012-06-15 9:18 ` Guennadi Liakhovetski 2012-06-15 9:18 ` Guennadi Liakhovetski 2012-06-15 11:27 ` Arnd Bergmann 2012-06-15 11:27 ` Arnd Bergmann [not found] ` <201206151127.24386.arnd-r2nGTMty4D4@public.gmane.org> 2012-06-15 16:11 ` Mitch Bradley 2012-06-15 16:11 ` Mitch Bradley [not found] ` <4FDB5ECF.3000701-D5eQfiDGL7eakBO8gow8eQ@public.gmane.org> 2012-06-16 6:56 ` Arnd Bergmann 2012-06-16 6:56 ` Arnd Bergmann 2012-06-21 11:21 ` Guennadi Liakhovetski 2012-06-21 11:21 ` Guennadi Liakhovetski 2012-06-21 14:56 ` Arnd Bergmann 2012-06-21 14:56 ` Arnd Bergmann [not found] ` <201205161942.20296.arnd-r2nGTMty4D4@public.gmane.org> 2012-05-17 13:22 ` Russell King - ARM Linux 2012-05-17 13:22 ` Russell King - ARM Linux 2012-05-17 13:52 ` Mark Brown 2012-05-17 13:52 ` Mark Brown 2012-05-17 14:16 ` Russell King - ARM Linux 2012-05-17 14:16 ` Russell King - ARM Linux 2012-05-16 16:16 ` Jassi Brar 2012-05-16 16:16 ` Jassi Brar 2012-05-16 17:12 ` Jon Hunter 2012-05-16 17:12 ` Jon Hunter 2012-05-16 17:24 ` Jassi Brar 2012-05-16 17:24 ` Jassi Brar 2012-05-16 17:37 ` Jon Hunter 2012-05-16 17:37 ` Jon Hunter 2012-05-16 17:46 ` Stephen Warren 2012-05-16 17:46 ` Stephen Warren 2012-05-16 18:03 ` Jon Hunter 2012-05-16 18:03 ` Jon Hunter 2012-05-04 15:22 ` Jon Hunter 2012-05-04 15:22 ` Jon Hunter 2012-05-04 15:56 ` Arnd Bergmann 2012-05-04 15:56 ` Arnd Bergmann 2012-05-04 17:19 ` Jon Hunter 2012-05-04 17:19 ` Jon Hunter 2012-05-04 19:06 ` Arnd Bergmann 2012-05-04 19:06 ` Arnd Bergmann 2012-05-04 19:26 ` Jon Hunter 2012-05-04 19:26 ` Jon Hunter 2012-05-04 18:30 ` Stephen Warren 2012-05-04 18:30 ` Stephen Warren
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='CAJe_Zhcrr2QqoY=H3=3EJLPQBjC3Yc43EDjqYXaNok9-T+=0yw@mail.gmail.com' \ --to=jaswinder.singh@linaro.org \ --cc=arnd@arndb.de \ --cc=b-cousson@ti.com \ --cc=devicetree-discuss@lists.ozlabs.org \ --cc=grant.likely@secretlab.ca \ --cc=jon-hunter@ti.com \ --cc=linux-arm-kernel@lists.infradead.org \ --cc=linux-omap@vger.kernel.org \ --cc=linux@arm.linux.org.uk \ --cc=nicolas.ferre@atmel.com \ --cc=rob.herring@calxeda.com \ --cc=swarren@nvidia.com \ --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: linkBe 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.