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

[Scott Wood <scottwood@freescale.com>]

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

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

-Scott