On Wed, Feb 22, 2012 at 01:32:07PM +0000, Russell King - ARM Linux wrote:
I think you're making the assumption that other people need cyclic transfers. I've seen little evidence that anyone other than sound needs such things, so I don't think there's justification to push this code into every DMA engine driver.
The idea was to have the library code to do this in the dmaengine core rather in drivers. Doing it in the drivers would be silly, it should be in library code somewhere. If we are going to librify it then pushing the code as far up the stack as we can seems like a smart move.
Remember, there's no common code to a DMA engine driver at all, everyone implements their own way with their own bugs. I would agree with you if there was some decent DMA engine infrastructure to abstract out such things, but there isn't.
So what you're asking is for N different ways of doing this, instead of having one centralized way.
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.