On Thursday 14 June 2012, Jon Hunter wrote: > > On 06/14/2012 06:48 AM, Arnd Bergmann wrote: > > On Wednesday 13 June 2012, Jon Hunter wrote: > >> So in that case, I don't see why the first cell after the phandle could > >> not be an index which could be either a direction or request-id and then > >> the next cell after that be a secondary match variable. > >> > >> So simple case with just a index (either req-id or direction) ... > >> > >> dmas = <&dmac0 index> > >> > >> More complex case ... > >> > >> dmas = <&dmac0 index match> > >> > >> For example, for OMAP index = req-id and match = direction ... > >> > >> dmas = <&dmac0 req-id direction> > >> > >> Or am I way off the page? > > > > The intention was instead to remove the need for the /index/ in those > > cases, because having a client-specific index in here makes it inconsistent > > with other similar bindings (reg, interrupts, gpios, ...) that people > > are familiar with. They use an implicit index by counting the > > fields in the respective properties. > > So maybe "index" was not the right term to use here. What I meant was > that this is really the req/chan-id associated with this device. It is > not an arbitrary index that in turn gets resolved into the req-id. So in > other words, just like gpio where you have the gpio number, here you > have the dma req-id. Ok, we're on the same page then. I got confused because you were quoting Stephen's example of multiple dmacs: dmas = <0 &dmac1 xxx 0 &dmac2 zzz 1 &dmac1 yyy>; which used an aribitrary slave-side index (0, 1), the dmaengine phandle and the dmaengine specific request id (xxx,yyy,zzz). Leaving out the index means that we require at least one of "dma-names" strings or adding the direction. > > The existing method we have for avoiding index numbers is to use > > named fields, like > > > > dmas = <&dmac0 matchA>, <dmac1 matchB>, <dmac2 matchC>; > > dma-names = "rx", "rx", "tx"; > > > > This is similar to how we use named interrupt and mmio resources, but > > it requires that we always request the dma lines by name, which is > > slightly more complex than we might want it to be. > > Ok, but how do you get the req-id from the above binding? Doesn't it > need to be stored there somewhere even for the most simplest case? Or > are you saying that in this case you are just returning a name and the > dma driver resolves that into a req-id? the req-id is what I called matchA, matchB, matchC here, it could be a set of multiple cells, the number of which gets determined by the dmaengine's #dma-cells property. > > Because the vast majority of cases just use a single channel, or one > > channel per direction, my idea was to encode the direction in the > > dmas property, which lets us request a dma channel by direction from > > the driver side, without explicitly encoding the name. > > Yes, thats fine and so the direction is really the match criteria in > this case. No, it's not :( > > This would let us handle the following cases very easily: > > > > 1. one read-write channel > > > > dmas = <&dmac 0x3 match>; > > Where 0x3 is the req-id? Just to confirm ;-) > > Why not have match after the phandle to be consistent with the simple > example using name fields above? The 0x3 is the direction, 1 for read, 2 for write, and 3 for read-write in this example. Sorry for being unclear. The direction has to come before the dma-engine specific request ID data so that the common code can interpret it, while the variable-length data after it is only interpreted by the dmaengine driver. Arnd -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
