-----Original Message----- From: Sit, Michael Wei Hong Sent: Thursday, 10 December, 2020 4:24 PM To: Sia, Jee Heng jee.heng.sia@intel.com; Pierre-Louis Bossart pierre-louis.bossart@linux.intel.com; Lars-Peter Clausen lars@metafoo.de; 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
-----Original Message----- From: Sia, Jee Heng jee.heng.sia@intel.com Sent: Tuesday, 8 December, 2020 11:21 AM To: Pierre-Louis Bossart pierre-louis.bossart@linux.intel.com; Lars-Peter Clausen lars@metafoo.de; Sit, Michael Wei Hong michael.wei.hong.sit@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
-----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.
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.