On Tue, Oct 15, 2013 at 11:40:10AM +0200, Lars-Peter Clausen wrote:
> 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
Is that so? Actually, I did as you said in my internal branch, but I just
fear that might not be easy to upstream, so I tried to figure out another
plausible way. It looks like I took a detour :)
Thank you for the advice.
Nicolin Chen