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