[RFC PATCH 2/4] ASoC: soc-generic-dmaengine-pcm: Add custom prepare and submit function

[Sit, Michael Wei Hong]

> -----Original Message-----
> From: Sit, Michael Wei Hong
> Sent: Thursday, 10 December, 2020 4:24 PM
> To: Sia, Jee Heng <jee.heng.sia at intel.com>; Pierre-Louis Bossart
> <pierre-louis.bossart at linux.intel.com>; Lars-Peter Clausen
> <lars at metafoo.de>; Shevchenko, Andriy
> <andriy.shevchenko at intel.com>
> Cc: Rojewski, Cezary <cezary.rojewski at intel.com>; alsa-
> devel at alsa-project.org; tiwai at suse.com;
> liam.r.girdwood at linux.intel.com; vkoul at kernel.org;
> broonie at kernel.org
> Subject: RE: [RFC PATCH 2/4] ASoC: soc-generic-dmaengine-pcm:
> Add custom prepare and submit function
> 
> 
> 
> > -----Original Message-----
> > From: Sia, Jee Heng <jee.heng.sia at intel.com>
> > Sent: Tuesday, 8 December, 2020 11:21 AM
> > To: Pierre-Louis Bossart <pierre-louis.bossart at linux.intel.com>;
> > Lars-Peter Clausen <lars at metafoo.de>; Sit, Michael Wei Hong
> > <michael.wei.hong.sit at intel.com>; Shevchenko, Andriy
> > <andriy.shevchenko at intel.com>
> > Cc: Rojewski, Cezary <cezary.rojewski at intel.com>; alsa-
> > devel at alsa-project.org; tiwai at suse.com;
> > liam.r.girdwood at linux.intel.com; vkoul at kernel.org;
> broonie at kernel.org
> > Subject: RE: [RFC PATCH 2/4] ASoC: soc-generic-dmaengine-pcm:
> > Add custom prepare and submit function
> >
> >
> >
> > > -----Original Message-----
> > > From: Pierre-Louis Bossart <pierre-
> > louis.bossart at linux.intel.com>
> > > Sent: 07 December 2020 11:36 PM
> > > To: Lars-Peter Clausen <lars at metafoo.de>; Sit, Michael Wei
> > Hong
> > > <michael.wei.hong.sit at intel.com>; Sia, Jee Heng
> > > <jee.heng.sia at intel.com>; Shevchenko, Andriy
> > > <andriy.shevchenko at intel.com>
> > > Cc: Rojewski, Cezary <cezary.rojewski at intel.com>; alsa-
> > devel at alsa-
> > > project.org; tiwai at suse.com;
> liam.r.girdwood at linux.intel.com;
> > > vkoul at kernel.org; broonie at kernel.org
> > > Subject: Re: [RFC PATCH 2/4] ASoC: soc-generic-dmaengine-
> > pcm: Add
> > > custom prepare and submit function
> > >
> > >
> > >
> > >
> > > > If you really want to limit your period size you need to install
> a
> > > > range constraint on the
> > SNDRV_PCM_HW_PARAM_PERIOD_SIZE
> > > parameter.
> > > >
> > > > But I'd highly recommend against it and just split the
> transfer
> > into
> > > > multiple segments in the DMA driver. Needlessly limiting the
> > period
> > > > size will increase the number of interrupts during audio
> > > > playback/recording and hurt the power efficiency of your
> > system.
> > >
> > > Yes that was also an objection from me, the fix should be in
> the
> > DMA
> > > level. The 1024 block limitation would mean restricting the
> > period
> > > size to be at most 5.3 or 10.6ms (16 and 32-bit cases). That's
> way
> > to small.
> > [>>] Seems like complexity increases if splitting the segments in
> > ASoC. This is not a framework issue nor architecture issue.
> > If introducing new API to DMAENGINE to constraint the number
> of items
> > is not recommended, then lets split the segments in DMA driver.
> 
> With the increased complexity of introducing new APIs can we
> move the segment splitting to the DMA driver?
> Anymore concerns with doing so?

If there are no more comments on this, I will start cleaning up the code to remove the DMA splitting in the ASoC layer, and push the code for review soon.
The DMA segment splitting will be done in the DMA driver instead.