Re: [RFC 4/7] ASoC: Add dmaengine PCM helper functions

[Russell King - ARM Linux <linux@arm.linux.org.uk>]

On Wed, Feb 22, 2012 at 01:39:39PM +0000, Mark Brown wrote:
> Well, Vinod seemed to also think that dmaengine ought to be able to cope
> with emulating this and I really don't see why it shouldn't be.  It does
> know the capabilities of the underlying driver and it gets to look at
> all the calls going into the driver before the driver does.  If ASoC can
> interpose itself I don't see why dmaengine can't.

Have you ever looked at the DMA engine drivers?  It's a total mess.
Even something as basic as the DMA engine driver assigning a cookie to
the descriptor is implemented in each driver in their own unique way.

Completion of DMA descriptors is a similar thing - every driver implements
this in their own unique way.

The only really common thing in the DMA engine drivers is that they all
share the same API.  Nothing much more than that is shared.

It's something I have been chipping away at for a while, trying to extract
out common parts into a library, but it's really not that easy.

So, there's no way in hell that I want to see any more stuff pushed down
into the DMA engine drivers until we have a proper DMA engine library in
place to stop all this idiotic code duplication throughout every driver.
Especially if it means everyone will be implementing their own cyclic
emulation in their individual drivers.

And lets not forget that it's not just a question of "oh we can just queue
up buffer after buffer".  Doing it properly for audio does need to ensure
that the DMA engine driver is capable of getting the next buffer chained
into the hardware before the previous buffer has completed, so the transfer
continues across a buffer boundary without needing the intervention of an
interrupt handler.  Otherwise you get glitches in the audio.

So, there's a lot more here that DMA engine stuff needs to get fixed than
just a simple "layer on top".