On Tue, Sep 16, 2014 at 08:12:35AM -0300, Emilio López 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.
Well, different transactions will use different channels. I don't see how you could end up in a situation where you have data transfered in the wrong order, that would mean going backward into the LLI, which is not something we can do, do we? Even if there is some "preemption" from the DMA controller on an ongoing transaction, it will just resume where it left. So the worst thing that could occur is an underrun I guess. > 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. > > If it turns out to be an issue we'll need a smarter scheduler (or a > clarification on the hardware one). I'd say we need both. Being able to program 8 channels at the same time, while more than 8 DMA clients can request a channel. Maxime -- Maxime Ripard, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com
signature.asc
Description: Digital signature
