On Wed, 2012-02-22 at 14:22 +0000, Russell King - ARM Linux wrote:
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".
I would agree with Russell that some of dma drivers are messy, but then were also a victim of ambiguous API. Now at least we have a clear direction of what is expected out of dma driver and what is not. Except for channel mapping stuff, rest has a clarity.
So the new drivers and fixes now are going in the right direction (hopefully you will agree with me on this) and we are frankly in much better state then we were one year back.
Said that, we still have lot of work to do to improve :) And I see this as another opportunity. Having a common library for these kind of common subsystem operations forces people to write proper driver and forces them to fix existing issue. Now, new support for DMAengine in asoc wont come without using this library and if it does work on a particular driver that is precondition for fixes as well.
Similarly I would really love to see such libraries in other subsystems which would help us in making the usage of dmaengine and dmac standard and straight forward for users.