* Felipe Balbi <balbi@xxxxxx> [110103 12:49]: > Hi, > > On Mon, Jan 03, 2011 at 05:19:45PM +0000, Russell King - ARM Linux wrote: > >> Frankly speaking, I doubt that drivers/dma/ will have place for the > >>purely MUSB specific DMA engines such as the named ones (there's no TUSB > >>DMA BTW -- it uses OMAP DMA). > > > >Long term, we need to kill off all these platform private DMA interfaces. > >There's a growing amount of IP that's being shared not only between ARM > >silicon vendors, but also across architectures, and having to re-implement > >drivers because the underlying DMA engine is different is not feasible. > > > >For example, we're seeing ARMs primecells being used with various > >different DMA controllers in various different ARM SoCs. I've heard > >rumours of them appearing in MIPS or PPC stuff as well. We're seeing > >PXA peripheral IP appearing in x86 stuff too. > > > >We can't have drivers tied to their SoC DMA engines, and we can't continue > >having SoC DMA engines implementing their own unique APIs. We do need to > >get on top of this before it becomes a major problem (if it hasn't > >already). > > > >The DMA engine API is still evolving, and should not be taken as concrete > >- I've recently been bringing up a number of points with Dan on various > >aspects of the API, some of which ultimately will lead to changes to the > >async-tx API, and others which hopefully will mean that the DMA slave > >API is better documented. > > I couldn't agree more with you Russell. If the API isn't enough > currently, we can always propose an extension. > > Having all sorts of SoC-specific "APIs" has already caused enough > problems and it still does (non-generic IRQ handling on > twl?030, menelaus, cbus - which isn't in mainline yet -, etc, > non-generic McBSP usage, non-generic GPMC usage, etc etc). So, if we can > plan for making use of generic APIs, let's do so. Yes I too agree with this. We just need to do whatever it takes to make the DMA engine suitable for all drivers. Regards, Tony -- 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
