[PATCH 1/4] Add DMA sector to Documentation/powerpc/booting-without-of.txt file.
scottwood at freescale.com
Thu Jul 12 05:03:38 EST 2007
Segher Boessenkool wrote:
>> that if we really wanted to we could describe as a
>> second reg resource in each channel, combined with a channel-ID
> You cannot describe one register in two different nodes.
Why not? It's read-only.
>> I'm not inclined to bother, though -- not because we don't currently use
>> it, but because I have a hard time seeing anyone needing to use it.
> Unless you're sure no one ever wants to use it, it should be in
> the device tree.
There are lots of registers that are used that aren't in the device
tree. This one's pretty low on the priority list to get added, IMHO.
>> There is no information in that register that is not the individual
>> channels' registers.
> People use it to get the status of all registers at once. I/O reads
> aren't cheap...
On-chip I/O reads shouldn't be all that slow...
>> It's by far the simplest way to tell the generic DMA driver "do not
>> touch". "fsl,mpc8548-dma" says "this is a generic, mem-to-mem DMA
> I would expect it to mean "this is the 8548 DMA controller".
What if the mem-to-mem channels were explicitly labelled
>> "fsl,mpc8548-audio-dma" says "this is a non-generic DMA channel,
>> hooked up to an audio codec".
> So this DMA channel cannot be used for general purpose stuff
> at all?
I don't know if it *can* or not, though it'd be a pretty unusual way of
using it. In any case, the device tree should be able to handle the
case where it can't.
> Sure, we agree on this. It is prudent to describe in the sound
> node which DMA channel is associated with the sound thing though,
> even if this is a SoC and all that. It is just describing the
> hardware; if your sound driver wants to hardcode the DMA stuff,
> that's fine with me, but that's no reason to not describe the
> relation in the device tree.
Sure, I was never saying that there shouldn't be phandle linkage from
the sound node to the dma channel node. I just don't want the
mem-to-mem driver to have to go to great lengths to figure out whether
it owns the channel.
Phandle linkage the other way could work, though; if the channel has a
phandle set in an attached-device property, then the mem-to-mem driver
leaves it alone.
> I see no reason to pretend the non-mem-to-mem channels are somehow
> different from the mem-to-mem channels.
But they are different, just like an SCC UART is different from an SCC
ethernet, even though they both go through the SCC.
More information about the Linuxppc-dev