On Sat, Jan 28, 2012 at 11:06:02AM -0700, Grant Likely wrote: > This makes the assumption that dma specifiers will only ever be 1 > cell. I think to be generally useful, the full dma specifier needs to > be either handed to the dma controller to get a cookie or passed back > to the caller in its entirety. More to the point, who says that the DMA specifier is even an integer? When people are using DMA engines, it (probably) isn't an integer at all. Several platforms I know of use strings for this. Some platforms can even select between two or more DMA engines for handling the same peripheral - I believe Samsung do this depending on their individual workloads. However, the opaque DMA engine API for requesting a channel doesn't lend itself well to DT, as the match data and match function are entirely left to the individual DMA engine driver and/or platform itself. As far as creating another linear number space for DMA stuff, I'd really suggest against that - you're going to need some additional code in place to manage that numberspace. If you at least use a two- paid cookie, eg 'dma controller phandle + request signal' then that makes all the stuff we're starting to see with the IRQ subsystem, IRQ domains etc become completely unnecessary. I guess what I'm saying is ignore the flat number space, and go straight to some kind of 'dma domains' solution from the start. -- 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
