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