-----Original Message----- From: Pierre-Louis Bossart pierre-louis.bossart@linux.intel.com Sent: 07 December 2020 11:36 PM To: Lars-Peter Clausen lars@metafoo.de; Sit, Michael Wei Hong michael.wei.hong.sit@intel.com; Sia, Jee Heng jee.heng.sia@intel.com; Shevchenko, Andriy andriy.shevchenko@intel.com Cc: Rojewski, Cezary cezary.rojewski@intel.com; alsa-devel@alsa- project.org; tiwai@suse.com; liam.r.girdwood@linux.intel.com; vkoul@kernel.org; broonie@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.