Re: [PATCH] [RFC] dmaengine: add fifo_size member

[Jon Hunter <jonathanh@nvidia.com>]

On 06/06/2019 07:41, Sameer Pujar wrote:
> 
> On 6/6/2019 11:30 AM, Peter Ujfalusi wrote:
>> Hi Sameer,
>>
>> On 06/06/2019 6.49, Sameer Pujar wrote:
>>> Sorry for late reply.
>>> [Resending the reply since delivery failed for few recipients]
>>> I discussed this internally with HW folks and below is the reason why
>>> DMA needs
>>> to know FIFO size.
>>>
>>> - FIFOs reside in peripheral device(ADMAIF), which is the ADMA interface
>>> to the audio sub-system.
>>> - ADMAIF has multiple channels and share FIFO buffer for individual
>>> operations. There is a provision
>>>    to allocate specific fifo size for each individual ADMAIF channel
>>> from
>>> the shared buffer.
>>> - Tegra Audio DMA(ADMA) architecture is different from the usual DMA
>>> engines, which you described earlier.
>> It is not really different than what other DMAs are doing.
>>
>>> - The flow control logic is placed inside ADMA. Slave peripheral
>>> device(ADMAIF) signals ADMA whenever a
>>>    read or write happens on the FIFO(per WORD basis). Please note that
>>> the signaling is per channel. There is
>>>    no other signaling present from ADMAIF to ADMA.
>>> - ADMA keeps a counter related to above signaling. Whenever a sufficient
>>> space is available, it initiates a transfer.
>>>    But the question is, how does it know when to transfer. This is the
>>> reason, why ADMA has to be aware of FIFO
>>>    depth of ADMAIF channel. Depending on the counters and FIFO depth, it
>>> knows exactly when a free space is available
>>>    in the context of a specific channel. On ADMA, FIFO_SIZE is just a
>>> value which should match to actual FIFO_DEPTH/SIZE
>>>    of ADMAIF channel.
>>> - Now consider two cases based on above logic,
>>>    * Case 1: when DMA_FIFO_SIZE > SLAVE_FIFO_SIZE
>>>      In this case, ADMA thinks that there is enough space available for
>>> transfer, when actually the FIFO data
>>>      on slave is not consumed yet. It would result in OVERRUN.
>>>    * Case 2: when DMA_FIFO_SIZE < SLAVE_FIFO_SIZE
>>>      This is case where ADMA won’t transfer, even though sufficient
>>> space
>>> is available, resulting in UNDERRUN.
>>> - The guideline is to program, DMA_FIFO_SIZE(on ADMA side) =
>>> SLAVE_FIFO_SIZE(on ADMAIF side) and hence we need a
>>>    way to communicate fifo size info to ADMA.
>> The src_maxburst / dst_maxburst is exactly for this reason. To
>> communicate how much data should be transferred per DMA request to/from
>> peripheral.
>>
>> In TI land we have now 3 DMA engines servicing McASP. McASP has FIFO
>> which is dynamically configured (you can see the AFIFO of McASP as a
>> small DMA: on McASP side it services the peripheral, on the other side
>> it interacts with the given system DMA used by the SoC - EDMA, sDMA or
>> UDMAP). All DMAs needs a bit different configuration, but the AFIFO
>> depth on the McASP side is coming in via the src/dst_maxburst and the
>> drivers just need to interpret it correctly.
>>
>> It does sounds like that FIFO_SIZE == src/dst_maxburst in your case as
>> well.
> Not exactly equal.
> ADMA burst_size can range from 1(WORD) to 16(WORDS)
> FIFO_SIZE can be adjusted from 16(WORDS) to 1024(WORDS) [can vary in
> multiples of 16]

So I think that the key thing to highlight here, is that the as Sameer
highlighted above for the Tegra ADMA there are two values that need to
be programmed; the DMA client FIFO size and the max burst size. The ADMA
has register fields for both of these.

As you can see from the above the FIFO size can be much greater than the
burst size and so ideally both of these values would be passed to the DMA.

We could get by with just passing the FIFO size (as the max burst size)
and then have the DMA driver set the max burst size depending on this,
but this does feel quite correct for this DMA. Hence, ideally, we would
like to pass both.

We are also open to other ideas.

Cheers
Jon

-- 
nvpublic