On 02/03/2012 02:48 PM, Mark Brown wrote:
So, we're getting more and more drivers converted over to dmaengine (I've CCed a random selection of people working on relevant drivers and Vinod). This means we're getting a bunch of drivers that talk to the ALSA API on the top and the dmaengine API on the bottom and seem to need to implement very similar code patterns (like this tasklet to push the DMA through). This feels like we need some sort of abstraction to factor out some code here, either library code or perhaps a framework driver with callbacks that fill in the platform specifics - if the APIs are providing useful abstractions then presumably a large part of this is just translating between them.
If that's not doable then what are the problems?
Yes, I was faced with the task of writing yet another dmaengine based ASoC PCM driver last week. At first I thought it might be a good idea to come up with a common ASoC PCM driver which could be used by all platforms using DMA engine. Unfortunately this turned out to be not feasible due to how dmaengine works. Each dmaengine driver has it's custom API for configuring the DMA controller. :/
So what I have come up with so far is a set of helper functions which can be used to implement a dmaengine based ASoC PCM driver. Right now I'm in the process of converting imx, mxs and ep93xx to this set of functions.
These platforms have in common that their dmaengine driver implements device_prep_dma_cyclic function, which prepares a continuous transfer for cyclic buffer. The other ASoC platforms using dmaengine for their PCM driver (including the one in this patch series) don't have this function implemented and so the PCM drivers manually have to setup the cyclic SG lists. So while we could add a common set up functions for this to ASoC or ALSA I think the better place for this is in the dmaengine framework and implement device_prep_dma_cyclic for those drivers which don't do yet.
I'll try to send patches and some further explanations next week.
- Lars