> -----Original Message----- > From: Vinod Koul <vkoul@xxxxxxxxxx> > Sent: 18 November 2020 12:41 PM > To: Sia, Jee Heng <jee.heng.sia@xxxxxxxxx> > Cc: Shevchenko, Andriy <andriy.shevchenko@xxxxxxxxx>; Sit, Michael Wei Hong > <michael.wei.hong.sit@xxxxxxxxx>; alsa-devel@xxxxxxxxxxxxxxxx; tiwai@xxxxxxxx; > broonie@xxxxxxxxxx; pierre-louis.bossart@xxxxxxxxxxxxxxx; Rojewski, Cezary > <cezary.rojewski@xxxxxxxxx>; liam.r.girdwood@xxxxxxxxxxxxxxx; lars@xxxxxxxxxx > Subject: Re: [RFC PATCH 2/4] ASoC: soc-generic-dmaengine-pcm: Add custom > prepare and submit function > > 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 [>>] Noted. > > > > 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 > > And this link is not accessible freely! [>>] Sorry, perhaps need to apply the access. > > > 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 [>>] Yes, it is 1024 items/blocks > > > 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 [>>] Got it. A separate patch shall be submitted to AxiDMA to split the linked-list. Hope the rest of folks are fine with this approach. > > -- > ~Vinod
