On 05/21/2012 12:18 PM, Arnd Bergmann wrote: > On Monday 21 May 2012, Stephen Warren wrote: >>> >>> The point with the direction was that it covers most cases and makes >>> them rather simple, while for the rare case where you need more than >>> two channels, you just use the otherwise optional named interface >>> rather than the numbered one. My feeling is that this also makes a >>> lot of sense at the driver API level: most dirvers just ask for the >>> read and write channels using a very simple interface, and those drivers >>> that have more than two will want to name them anyway. >> >> How are you thinking of representing the direction in DT - as part of >> the DMA request specifier, so in a DMAC-specific way? >> >> 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? -- 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
