Hi Arnd, On 06/08/2012 07:04 PM, Arnd Bergmann wrote: > 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. I agree with putting the &dmac phandle first, that makes sense. > 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. Ok, so you are saying that there are some DMA controllers where there is no channel/request ID and only a direction is needed? So an even simpler case than what I had imagined. 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? Cheers Jon -- 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
