On 18-11-20, 00:34, Sia, Jee Heng wrote: > > > > -----Original Message----- > > From: Andy Shevchenko <andriy.shevchenko@xxxxxxxxx> > > Sent: 17 November 2020 11:51 PM > > To: Sit, Michael Wei Hong <michael.wei.hong.sit@xxxxxxxxx> > > Cc: alsa-devel@xxxxxxxxxxxxxxxx; tiwai@xxxxxxxx; broonie@xxxxxxxxxx; pierre- > > louis.bossart@xxxxxxxxxxxxxxx; Rojewski, Cezary <cezary.rojewski@xxxxxxxxx>; > > liam.r.girdwood@xxxxxxxxxxxxxxx; Sia, Jee Heng <jee.heng.sia@xxxxxxxxx>; > > vkoul@xxxxxxxxxx; lars@xxxxxxxxxx > > Subject: Re: [RFC PATCH 2/4] ASoC: soc-generic-dmaengine-pcm: Add custom > > prepare and submit function > > > > 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: ** Please wrap your replies to 80 chars ** I have reflown below > https://www.intel.com/content/www/us/en/secure/design/confidential/products-and-solutions/processors-and-chipsets/keem-bay/technical-library.html?grouping=EMT_Content%20Type&sort=title:asc And this link is not accessible freely! > Pg783, "Programmable transfer length (block length), max 1024". Okay so block length cant be more than 1024, and IIUC that is 1024 items and not bytes right > 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. I would go with 3, this is not a fwk issue and can be easily handled in the dma driver. It knows the limitation on block and can split a period into multiple blocks and set the interrupt on last block. I do not see why that will not work -- ~Vinod
