-----Original Message----- From: Vinod Koul vkoul@kernel.org Sent: 18 November 2020 12:41 PM To: Sia, Jee Heng jee.heng.sia@intel.com Cc: Shevchenko, Andriy andriy.shevchenko@intel.com; Sit, Michael Wei Hong michael.wei.hong.sit@intel.com; alsa-devel@alsa-project.org; tiwai@suse.com; broonie@kernel.org; pierre-louis.bossart@linux.intel.com; Rojewski, Cezary cezary.rojewski@intel.com; liam.r.girdwood@linux.intel.com; lars@metafoo.de 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@intel.com Sent: 17 November 2020 11:51 PM To: Sit, Michael Wei Hong michael.wei.hong.sit@intel.com Cc: alsa-devel@alsa-project.org; tiwai@suse.com; broonie@kernel.org; pierre- louis.bossart@linux.intel.com; Rojewski, Cezary cezary.rojewski@intel.com; liam.r.girdwood@linux.intel.com; Sia, Jee Heng jee.heng.sia@intel.com; vkoul@kernel.org; lars@metafoo.de 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:
- 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