SImos, can we get a clarification out of Allwinner on how the DMA hardware works?
I'm hoping it doesn't work the way the manual is implying because if it does the DMA hardware is badly broken. On Tue, Sep 16, 2014 at 7:12 AM, Emilio López <[email protected]> wrote: > Hi Maxime, Jon, > > El 16/09/14 a las 07:18, Maxime Ripard escibió: > > Hi Jon, >> >> On Mon, Sep 15, 2014 at 09:19:01AM -0400, [email protected] wrote: >> >>> How do you interpret this? >>> >>> 1.12. DMA >>> 1.12.1. Overview >>> >>> There are two kinds of DMA in the chip. One is Normal DMA with 8 >>> channels, >>> the other is Dedicated DMA with 8 channels . >>> >>> For normal DMA, only one channel can be active and the sequence is in >>> line >>> with the priority level. While for the dedicated DMA, at most 8-channel >>> can >>> be active at the same time if their source or destination has no >>> conflict. >>> The dedicated DMA can only transfer data between the DRAM and the module. >>> >>> ------------------------------------ >>> >>> Emilio interpreted it to mean that we can't turn on two normal DMA >>> transfers at the same time. That's a real mess if one of those transfers >>> sits around waiting for a couple seconds to fulfill the request. ALSA >>> could >>> write 256K to the I2S buffer which would take 1.5 seconds to slowly spool >>> out to the audio hardware. >>> >>> But this doesn't make sense on normal DMA, what is the point of making >>> eight sets of normal DMA registers if only one can be active? Why can't I >>> have two DMA requests setup and waiting for data to arrive? >>> >>> This might mean that if one of the eight normal channels asserts DRQ it >>> will only service that DRQ until it deasserts. In other words it won't >>> service multiple active DRQs and round robin between them. That makes >>> more >>> sense - there is only one set of transfer hardware in the normal DMA >>> engine. Each dedicated DMA has its own transfer hardware. >>> >>> It should be legal to have two cyclic requests sitting there, and then it >>> makes sense that only one of the two can be actively moving data. The >>> FIFOs >>> will mask this. >>> >>> So how does this hardware work? >>> >> >> That would have been my understanding too, but I never looked that >> much into the sun4i DMA controller. >> > > The manual says > > """ > There are two kinds of DMA, namely, Normal DMA and Dedicated DMA. For > Normal DMA, ONLY one channel can be activated and the sequence is > determined by the priority level. For Dedicated DMA, at most 8-channels can > be activated at the same time as long as there is conflict of their source > or destination. > """ > > So my understanding is that there can only be one operation running at a > time on normal DMA. You may configure up to 8 on the hardware and the > hardware will run them in series according to the "priority level", which > is completely undocumented, so we can't rely on that unless we get a > clarification on what it is - otherwise we may get data DMA'd on an > incorrect order or things like that. Given that, we do all the scheduling > ourselves in the driver. > If it works this way it is useless hardware. For example I have setup DMA before on ADC operations used for logging where the DMA gets one sample per second and a DMA transfer can take hours to complete. > > As a side effect of this, and per the definition of cyclic transfer, when > you implement and issue a cyclic normal transfer it will hog the only > available "worker" on the engine with it. As the engine signals you that it > "finished" the operation, the ISR will see it was cyclic and just reprogram > it, over and over. > That's a another example of this hardware being useless. Once cyclic transfer and now nothing else can do normal DMA. You can't even have two cyclic transfers - one for play and one for capture. This hardware can't be that badly broken. Allwinner needs to clarify this. We also need to know how this priority works. > > If it turns out to be an issue we'll need a smarter scheduler (or a > clarification on the hardware one). But first we'd need to be supporting > normal DMA cyclic transfers (the driver currently does dedicated ones, as > that's what the codec and friends use) > > Cheers, > > Emilio > > -- > You received this message because you are subscribed to the Google Groups > "linux-sunxi" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > For more options, visit https://groups.google.com/d/optout. > -- Jon Smirl [email protected] -- You received this message because you are subscribed to the Google Groups "linux-sunxi" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
