From: Arnd Bergmann <arnd@arndb.de> To: Jon Hunter <jon-hunter@ti.com> Cc: Stephen Warren <swarren@wwwdotorg.org>, Jassi Brar <jaswinder.singh@linaro.org>, 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>, 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: Sat, 9 Jun 2012 00:04:09 +0000 [thread overview] Message-ID: <201206090004.10086.arnd@arndb.de> (raw) In-Reply-To: <4FD24CC3.50700@ti.com> On Friday 08 June 2012, Jon Hunter wrote: > On 05/21/2012 03:32 PM, Stephen Warren wrote: > > On 05/21/2012 12:18 PM, Arnd Bergmann wrote: > >> On Monday 21 May 2012, Stephen Warren wrote: > >>> > >>> If so, that seems a little odd; you have to request a DMA channel for > >>> "TX", but then end up having the common code check all the entries in > >>> the dmas property since it can't know which are TX, and then have the > >>> wrong ones almost accidentally fail, since the DMAC will then determine > >>> that it can't support TX on the RX DMA request IDs. > >> > >> I think the direction must be encoded in a way that does not depend on > >> the binding for the specific controller. There are two ways I can see > >> how we might do it: > >> > >> 1. have separate property names for tx and rx channels, and probably > >> one for combined rx/tx channels > > > >> 2. define the second cell in each channel specifier to be the direction > >> in a predefined format, followed by the other (controller specific) > >> attributes, if any. > > > > In this option, lets say bit 0 is 0==TX, 1==RX (or perhaps 2 bits if > > combined TX/RX is needed) > > > > Then, we could reserve say bits 7:1 as client DMA request ID. > > > > And then have bits 31:8 as DMAC specific data. > > > > Wouldn't that allow us to have our cake and eat it? > > Sorry for not responding sooner. > > It seems to me we were pretty close on alignment. In fact, I was quite > happy with Steven's 2nd to last proposal of ... > > simple 1 req: > dmas = <0 &dmac1 xxx>; > > simple 2 req: > dmas = <0 &dmac1 xxx 1 &dmac1 yyy>; > > multiple dmacs: > dmas = <0 &dmac1 xxx 0 &dmac2 zzz 1 &dmac1 yyy>; > > Arnd, I know that you had some concerns. However, in the above case I > would expect that the 3rd parameter be optional and it can be some sort > of match variable. In other words, we don't care how the 32-bits are > encoded or what they represent but they would be used appropriately by > the xlate function being used. So the xlate and this "match" variable > would have to speak the same language. I would at least put the &dmac part first to be consistent with other bindings that refer to some node. That controller should then be able to specify the number of additional cells used to describe the dma request. We can define that the first cell after the controller phandle is always the same thing, e.g. the direction (in/out/inout) or a client-specific ID or a combination of that with other predefined bits that are not dependent on dma controller specifics. As I said previously, I think just encoding the direction but not the client specific ID (meaning we would have to disambiguate the more complex cases that Stephen mentioned using a dma-names property) would be the best because it keeps the common case simple, but I could live with other things going in there too. > I think that I prefer the idea of having a 3rd optional match variable > than encoding the DMA request ID and match data together in 1 32-bit > variable. However, not a big deal either way. I agree on that part, I would usually prefer to encode different things in separate cells rather than putting them together into a single cell just because they require less than 32 bits combined. Arnd
WARNING: multiple messages have this Message-ID (diff)
From: arnd@arndb.de (Arnd Bergmann) To: linux-arm-kernel@lists.infradead.org Subject: [PATCH V3 1/2] of: Add generic device tree DMA helpers Date: Sat, 9 Jun 2012 00:04:09 +0000 [thread overview] Message-ID: <201206090004.10086.arnd@arndb.de> (raw) In-Reply-To: <4FD24CC3.50700@ti.com> On Friday 08 June 2012, Jon Hunter wrote: > On 05/21/2012 03:32 PM, Stephen Warren wrote: > > On 05/21/2012 12:18 PM, Arnd Bergmann wrote: > >> On Monday 21 May 2012, Stephen Warren wrote: > >>> > >>> If so, that seems a little odd; you have to request a DMA channel for > >>> "TX", but then end up having the common code check all the entries in > >>> the dmas property since it can't know which are TX, and then have the > >>> wrong ones almost accidentally fail, since the DMAC will then determine > >>> that it can't support TX on the RX DMA request IDs. > >> > >> I think the direction must be encoded in a way that does not depend on > >> the binding for the specific controller. There are two ways I can see > >> how we might do it: > >> > >> 1. have separate property names for tx and rx channels, and probably > >> one for combined rx/tx channels > > > >> 2. define the second cell in each channel specifier to be the direction > >> in a predefined format, followed by the other (controller specific) > >> attributes, if any. > > > > In this option, lets say bit 0 is 0==TX, 1==RX (or perhaps 2 bits if > > combined TX/RX is needed) > > > > Then, we could reserve say bits 7:1 as client DMA request ID. > > > > And then have bits 31:8 as DMAC specific data. > > > > Wouldn't that allow us to have our cake and eat it? > > Sorry for not responding sooner. > > It seems to me we were pretty close on alignment. In fact, I was quite > happy with Steven's 2nd to last proposal of ... > > simple 1 req: > dmas = <0 &dmac1 xxx>; > > simple 2 req: > dmas = <0 &dmac1 xxx 1 &dmac1 yyy>; > > multiple dmacs: > dmas = <0 &dmac1 xxx 0 &dmac2 zzz 1 &dmac1 yyy>; > > Arnd, I know that you had some concerns. However, in the above case I > would expect that the 3rd parameter be optional and it can be some sort > of match variable. In other words, we don't care how the 32-bits are > encoded or what they represent but they would be used appropriately by > the xlate function being used. So the xlate and this "match" variable > would have to speak the same language. I would at least put the &dmac part first to be consistent with other bindings that refer to some node. That controller should then be able to specify the number of additional cells used to describe the dma request. We can define that the first cell after the controller phandle is always the same thing, e.g. the direction (in/out/inout) or a client-specific ID or a combination of that with other predefined bits that are not dependent on dma controller specifics. As I said previously, I think just encoding the direction but not the client specific ID (meaning we would have to disambiguate the more complex cases that Stephen mentioned using a dma-names property) would be the best because it keeps the common case simple, but I could live with other things going in there too. > I think that I prefer the idea of having a 3rd optional match variable > than encoding the DMA request ID and match data together in 1 32-bit > variable. However, not a big deal either way. I agree on that part, I would usually prefer to encode different things in separate cells rather than putting them together into a single cell just because they require less than 32 bits combined. Arnd
next prev parent reply other threads:[~2012-06-09 0:04 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 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 [this message] 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=201206090004.10086.arnd@arndb.de \ --to=arnd@arndb.de \ --cc=b-cousson@ti.com \ --cc=devicetree-discuss@lists.ozlabs.org \ --cc=grant.likely@secretlab.ca \ --cc=jaswinder.singh@linaro.org \ --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.