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

[Sameer Pujar]

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 without this RFC patch, I need to do following.
- pass FIFO_SIZE via src/dst_maxburst (from peripheral ADMAIF driver)
- DMA driver can have following code,
 * Program DMA_FIFO_SIZE value from src/dst_maxburst
 * Add below logic
ÂÂÂ if (src/dst_maxburst > 16)
ÂÂÂÂÂÂÂ program ADMA burst_size = 16
ÂÂÂ else
ÂÂÂÂÂÂÂ program ADMA burst_size = 8 (1/2 of minimum FIFO depth of 
ADMAIF channel)

With above, the flexibility to program ADMA burst_size to any of the 
required values in the specified range is not there.
Hence ideally would have liked to have independent control over 
burst_size and fifo_size on ADMA side.
If there is no merit in this, I will update ADMA/ADMAIF driver as 
mentioned above.

Thanks,
Sameer.

> - PÃter
>
> Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
> Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki