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.
--
balbi
--
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
