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]

 




> -----Original Message-----
> From: Lars-Peter Clausen <lars@xxxxxxxxxx>
> Sent: 01 December 2020 4:22 PM
> To: Shevchenko, Andriy <andriy.shevchenko@xxxxxxxxx>
> Cc: Sit, Michael Wei Hong <michael.wei.hong.sit@xxxxxxxxx>; Sia, Jee
> Heng <jee.heng.sia@xxxxxxxxx>; pierre-louis.bossart@xxxxxxxxxxxxxxx;
> Rojewski, Cezary <cezary.rojewski@xxxxxxxxx>;
> liam.r.girdwood@xxxxxxxxxxxxxxx; vkoul@xxxxxxxxxx; tiwai@xxxxxxxx;
> broonie@xxxxxxxxxx; alsa-devel@xxxxxxxxxxxxxxxx
> 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





[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