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

[Sia, Jee Heng]

> -----Original Message-----
> From: Shevchenko, Andriy <andriy.shevchenko at intel.com>
> Sent: 18 November 2020 10:51 PM
> To: Sia, Jee Heng <jee.heng.sia at intel.com>
> Cc: Sit, Michael Wei Hong <michael.wei.hong.sit at intel.com>; alsa-devel at alsa-
> project.org; tiwai at suse.com; broonie at kernel.org; pierre-
> louis.bossart at linux.intel.com; Rojewski, Cezary <cezary.rojewski at intel.com>;
> liam.r.girdwood at linux.intel.com; vkoul at kernel.org; lars at metafoo.de
> Subject: Re: [RFC PATCH 2/4] ASoC: soc-generic-dmaengine-pcm: Add custom
> prepare and submit function
> 
> On Wed, Nov 18, 2020 at 02:34:22AM +0200, Sia, Jee Heng wrote:
> > > From: Andy Shevchenko <andriy.shevchenko at intel.com>
> > > Sent: 17 November 2020 11:51 PM
> > > On Tue, Nov 17, 2020 at 04:03:48PM +0800, Michael Sit Wei Hong wrote:
> > > > Enabling custom prepare and submit function to overcome DMA limitation.
> > > >
> > > > In the Intel KeemBay solution, the DW AXI-based DMA has a
> > > > limitation on the number of DMA blocks per transfer. In the case
> > > > of 16 bit audio ASoC would allocate blocks exceeding the DMA block limitation.
> > >
> > > I'm still not sure the hardware has such a limitation.
> > >
> > > The Synopsys IP supports linked list (LLI) transfers and I hardly
> > > can imagine the list has any limitation. Even though, one can always
> > > emulate LLI in software how it's done in the DesignWare AHB DMA driver.
> > >
> > > I have briefly read chapter 4.6 "AXI_DMA" of Keem Bay TRM and didn't
> > > find any errata or limits like this.
> > [>>] Intel KeemBay datasheet can be found at below link:
> > https://www.intel.com/content/www/us/en/secure/design/confidential/pro
> > ducts-and-solutions/processors-and-chipsets/keem-bay/technical-library
> > .html?grouping=EMT_Content%20Type&sort=title:asc
> > Pg783, "Programmable transfer length (block length), max 1024". Sub-list can't
> exceed 1024 blocks.
> > BTW, I think the 16bits audio could be a confusion because it is not about the
> number of bits, but rather the constraint of the block length. Base on my
> understanding, Audio needs a period larger than 10ms, regardless of the bit depth.
> > The questions here are:
> > 1. Should DMAEngine expose a new API to constraint the block_length (instead of
> size in bytes)?
> > 2. Should DMA client re-split the linked-list before passing the linked-list to
> DMAEngine.
> > 3. Should DMA controller driver re-split the linked-list before execution.
> 
> Since we have DMA slave capabilities, the consumer may ask for them and prepare
> the SG list accordingly.
> 
> Above limitation is a block size (value of 1023 is a maximum, meaning 1024
> maximum items in the block of given transfer width). So, like DesignWare DMA
> (AHB) has up to 4095 (but I saw hardware with 2047) or iDMA 32- and 64-bit have
> 131071. There is no limitation for amount of blocks of given maximum length in the
> LLI!
> 
> No hacks are needed, really.
[>>] Hi All, can we have the agreement that DMA clients should optimize the linked-list
[>>] by retrieve the DMA capabilities from the DMA controller?
[>>] I noticed that Vinod voted #3 but Andy voted #2. 
[>>] We need your decision to move on.
> 
> --
> With Best Regards,
> Andy Shevchenko
>