[PATCH 06/13] DMAENGINE: driver for the ARM PL080/PL081 PrimeCells
Linus Walleij
linus.walleij at linaro.org
Thu Mar 13 04:17:04 EDT 2014
Trying to understand this, bear with me if I'm thinking sidewise...
On Mon, Mar 10, 2014 at 3:52 PM, David Woodhouse <dwmw2 at infradead.org> wrote:
> Actually, if it's really true that the *kernel* is supposed to tell the
> DMA controller which source-id to use for a given channel, instead of it
> being programmed in advance by the BIOS, then ACPI doesn't solve that
> for us in this case either.
So what exactly is a source-id in this case? I'm thinking something
like a logical signal number, like 0x18 is a certain PCM device or
something. That is usually just the number of a rail routed in silicon from
the DMAC to the peripheral in question and doesn't have much to do
with how memory is mapped and data transferred in bursts or single
requests.
> The whole thing seems to be designed such
> that the DMA just *does* appear to come from the slave, not the DMA
> controller.
This sounds like the tag on the bus is set such that the transactions get
some number (maybe the above source-id) transmitted on a few bits
depending on bus arbitration protocol, during transactions making it
appear as if that device is driving the transaction.
Again as Russell stated that doesn't necessarily influence any memory
coherency or the physical address pointer written into the DMAC
hardware at all, does it? The transfers can still happen between the
peripheral and DMAC, and the IOMMU can still be sitting in the middle
of things, in front of the DMAC not the device, needing to be flushed etc.
Sorry if I don't get it... maybe this is one of these funny Intel things
I cannot wrap my head around properly.
Yours,
Linus Walleij
More information about the linux-arm-kernel
mailing list