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

[Sia, Jee Heng]

> -----Original Message-----
> From: Lars-Peter Clausen <lars at metafoo.de>
> Sent: 01 December 2020 4:22 PM
> To: Shevchenko, Andriy <andriy.shevchenko at intel.com>
> Cc: Sit, Michael Wei Hong <michael.wei.hong.sit at intel.com>; Sia, Jee
> Heng <jee.heng.sia at intel.com>; pierre-louis.bossart at linux.intel.com;
> Rojewski, Cezary <cezary.rojewski at intel.com>;
> liam.r.girdwood at linux.intel.com; vkoul at kernel.org; tiwai at suse.com;
> broonie at kernel.org; alsa-devel at alsa-project.org
> Subject: Re: [RFC PATCH 2/4] ASoC: soc-generic-dmaengine-pcm: Add
> custom prepare and submit function
> 
> On 11/30/20 12:09 PM, Shevchenko, Andriy wrote:
> > On Mon, Nov 30, 2020 at 11:45:17AM +0100, Lars-Peter Clausen
> wrote:
> >> On 11/30/20 10:57 AM, Sit, Michael Wei Hong wrote:
> >>> 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.
> >> 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.
> > I would say it's not desirable.
> >
> > Why should we split than resplit if we may do it in one go?
> > Why then we have DMA capabilities returned to the consumers.
> >
> > So, I have that we need to optimize DMA SG list preparation in a way
> > that consumer gets SG list cooked in accordance with DMA
> limitations / requirements.
> 
> The API that the audio drivers use request a period DMA transfer for
> length N split into M segments with the callback being called after
> each segment.
> 
> How that is implemented internally in the DMA does not matter as
> long as it matches those semantics. E.g. if the segment is longer than
> what the DMA can handle it can split it into two segments internally
> and call the callback every second segment.
> 
> The way this API works there isn't even really a possibility for the client
> side to split periodic transfers.
> 
> Btw. 1024 beats per segment seems excessively small, I don't
> understand how somebody would design such an DMA. Was the
> assumption that the DMA will never transfer more than PAGE_SIZE of
> contiguous memory? Or do we not understand the documentation
> correctly?
[>>] The segment size is 1024 items. The item size could be 8bits,
16bits or 32bits. So, set_max_seg_size() is set to 1024*4bytes.
 

> 
> - Lars