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 mement. 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.
