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
