On Fri, Sep 19, 2014 at 9:28 AM, Sugar <[email protected]> wrote: -------------------
Thanks for that explanation, so the A20 DMA works like most other common DMA engines. It would be good if you put this description you just wrote into the manual and replaced this one: ------------------------------------------- 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. ---------------------- The current description in the manual says that only one channel can be active which is not correct. The problem is that 'active' is ambiguous in that sentence - is 'active' referring to the whole transfer, or just the DMA burst? Turns out that it is referring to a DMA burst. On Fri, Sep 19, 2014 at 9:28 AM, Sugar <[email protected]> wrote: > Hi all, > About normal DMA questions, I try to describe its working mechanism. > Hope it can helpful to you. > First, you can turn on more than two normal DMA transfers at the same > moment. For example, we turn on A,B,C channel to memcpy. It will enable all > three channels. > Second, inside DMA controller, all normal DMA channels share the same > one bus port and fifo. DMA controller will poll every burst transfer of > every channel, util all channels finished. Here is its timing: > Suppose we have some following burst transfers(eg. A1, B1, C1....). > > A: A1, A2, .... \ > B: B1, B2, B3, ... --fifo-- bus-port > C: C1, C2, .... / > > It maybe have the such as sequence, B1->C1->A1->B2->C2->A2->B3.... > Yes, normal DMA channels should share the resources average. DMA > controller transfer every burst one by one. It consider that all normal > channels is transferring at moment, form users side. > > > On 2014/9/17 23:53, Maxime Ripard wrote: > >> 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 >> >> > -- > 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.
