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

[Sia, Jee Heng]

> -----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.