[alsa-devel] [PATCH] ASoC: generic-dmaengine-pcm: Add an interface to override its functions

[Lars-Peter Clausen]

On 10/15/2013 11:23 AM, Nicolin Chen wrote:
> On Tue, Oct 15, 2013 at 11:02:44AM +0200, Lars-Peter Clausen wrote:
>>> If this modification to sound/core/pcm_dmaengine.c is not fair,
>>> what about moving the modification to soc-gerneric-dmaengine-pcm.c?
>>>
>>> For example, instead of using snd_dmaengine_pcm_trigger() directly
>>> in gerneric soc dmaengine driver, we create a new one inside gerneric
>>> soc dmaengine driver and check the override:
>>>
>>> static int snd_soc_dmaengine_pcm_trigger(substream, cmd) {
>>> 	if (config->driver->ops->trigger)
>>> 		return config->driver->ops->trigger(substream, cmd);
>>> 		
>>> 	return snd_dmaengine_pcm_trigger(substream, cmd);
>>> }
>>>
>>> Since it happens inside generic dmaengine pcm ASoC driver, it won't break
>>> those helper functions.
>>>
>>> I'm trying this just because I hope generic dmaengine can be more flexible
>>> Admittedly, using helper functions might be more plausible way in current
>>> ASoC structure. However, there might be so much change for an generic soc
>>> dmaengine implementation even if it just wants to override one single func.
>>
>> Well the idea of the generic dmaengine driver is to be generic and not
>> require SoC specific hacks since those should not be necessary if things are
>> done right. What exactly do you want to implement in the overwritten ops?
>>
>> - Lars
> 
> Just like I mentioned in the commit comments, using on-chip memory would
> need an alternative memory allocating function to replace the default one
> from external DDR. imx-pcm-dma.c is now using ASoC generic dmaengine, so
> if we turn it back to helper functions way, all cpu dai drivers might have
> to be turned back as well.
> 
> ASoC generic dmaengine is quite concise and well-developed for us to use.
> But after using it, its own limitation might make user waver to choose the
> old fashion helper functions. So I just wish it could provide a back door
> for an easy trick. Then we can continue to enjoy the convenience from it
> and also be able to tackle these uncommon cases.

Wanting to use on-chip memory for the audio buffers is not that uncommon.
I'd rather see this implemented generically in the generic driver instead of
each SoC implementing its own version.

- Lars