[PATCH 1/4] Add DMA sector to Documentation/powerpc/booting-without-of.txt file.

[Segher Boessenkool]

>>> that if we really wanted to we could describe as a
>>> second reg resource in each channel, combined with a channel-ID   
>>> property.
>> You cannot describe one register in two different nodes.
>
> Why not?  It's read-only.

Because a register belongs to one, and only one, device
node.  There is no such concept as "read-only registers"
in Open Firmware btw.  How a device (or a driver for a
device) uses the registers is its own business; OF merely
describes what devices uses what address range.

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

It is in the original proposed tree already.  I see no reason
to take it out.

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

There's a full sync after every I/O read.  Anyway, it doesn't
matter; the register is there, why not describe it.

>>> 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  channel".
>> I would expect it to mean "this is the 8548 DMA controller".
>
> What if the mem-to-mem channels were explicitly labelled  
> fsl,mpc8548-dma-mem-to-mem?

Why would you?  Why would you put _any_ compatible property in
the individual channels, even; they aren't separate devices
after all.

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

Yes, but also the case where it _can_.

>> 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,

I'm not sure that would cleanly work in all cases, I'll have to
think about it.

> then the mem-to-mem driver leaves it alone.

Yeah that would work.  There are much simpler solutions though.

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

The SCC is the same; if there was a node describing just the SCC
part, like we have nodes describing _just_ the DMA channel part
here, it would be the same situation.


Segher