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