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