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