Hi Jon, Sameer, On 06/06/2019 10.14, Jon Hunter wrote: > > 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. How does the ADMA uses the 'client FIFO size' and 'max burst size' values and what is the relation of these values to the peripheral side (ADMAIF)? > 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. I can not find public documentation (I think they are walled off by registration), but correct me if I'm wrong: ADMAIF - peripheral side - kind of a small DMA for audio preipheral(s)? - Variable FIFO size - sends DMA request to ADMA per words ADMA - system DMA - receives the DMA requests from ADMAIF - counts the requests - based on some threshold of the counter it will send/read from ADMAIF? - maxburst number of words probably? ADMA needs to know the ADMAIF's FIFO size because, it is the one who is managing that FIFO from the outside, making sure that it does not over or underrun? And it is the one who sets the pace (in effect the DMA burst size - how many bytes the DMA jumps between refills) of refills to the ADMAIF's FIFO? - Péter Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
