> -----Original Message----- > From: Sit, Michael Wei Hong > Sent: Thursday, 10 December, 2020 4:24 PM > To: Sia, Jee Heng <jee.heng.sia@xxxxxxxxx>; Pierre-Louis Bossart > <pierre-louis.bossart@xxxxxxxxxxxxxxx>; Lars-Peter Clausen > <lars@xxxxxxxxxx>; Shevchenko, Andriy > <andriy.shevchenko@xxxxxxxxx> > Cc: Rojewski, Cezary <cezary.rojewski@xxxxxxxxx>; alsa- > devel@xxxxxxxxxxxxxxxx; 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 > > > > > -----Original Message----- > > From: Sia, Jee Heng <jee.heng.sia@xxxxxxxxx> > > Sent: Tuesday, 8 December, 2020 11:21 AM > > To: Pierre-Louis Bossart <pierre-louis.bossart@xxxxxxxxxxxxxxx>; > > Lars-Peter Clausen <lars@xxxxxxxxxx>; Sit, Michael Wei Hong > > <michael.wei.hong.sit@xxxxxxxxx>; Shevchenko, Andriy > > <andriy.shevchenko@xxxxxxxxx> > > Cc: Rojewski, Cezary <cezary.rojewski@xxxxxxxxx>; alsa- > > devel@xxxxxxxxxxxxxxxx; 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 > > > > > > > > > -----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. > > 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.
