> -----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
