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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 11/30/20 10:57 AM, Sit, Michael Wei Hong wrote:

-----Original Message-----
From: Sia, Jee Heng <jee.heng.sia@xxxxxxxxx>
Sent: Tuesday, 24 November, 2020 11:51 AM
To: Shevchenko, Andriy <andriy.shevchenko@xxxxxxxxx>
Cc: 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; vkoul@xxxxxxxxxx;
lars@xxxxxxxxxx
Subject: RE: [RFC PATCH 2/4] ASoC: soc-generic-dmaengine-pcm:
Add custom prepare and submit function



-----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/con
fidential/p
ro
ducts-and-solutions/processors-and-chipsets/keem-
bay/technical-libra
ry .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

Hi everyone,

Is there anymore comment on this RFC?
We will be using the ASoC framework to split the linked-list, since resplitting the linked-list in DMA is a no go.
If there isn't any more comments, we will push these patches for review and merging.

Hi,

Why is splitting the list in the DMAengine framework a no go?

The whole idea of the DMAengine framework is to hide hardware specifics. It offers an API with certain semantics and it is up to the driver to provide an implementation that implements these semantics. There does not necessarily have to be a 1-to-1 mapping to hardware primitives in such an implementation.

- Lars




[Index of Archives]     [ALSA User]     [Linux Audio Users]     [Pulse Audio]     [Kernel Archive]     [Asterisk PBX]     [Photo Sharing]     [Linux Sound]     [Video 4 Linux]     [Gimp]     [Yosemite News]

  Powered by Linux