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