[RFC PATCH 02/19] powerpc: gamecube: device tree
Segher Boessenkool
segher at kernel.crashing.org
Fri Nov 27 23:07:11 EST 2009
>>> + soc {
>>> + #address-cells = <1>;
>>> + #size-cells = <1>;
>>> + #interrupt-cells = <1>;
>>
>> This isn't an interrupt controller, don't put #interrupt-cells
>> here.
>
> Isn't this needed to define what is to be expected in the
> "interrupts" properties of the child nodes?
Nope. Only interrupt controllers have a #interrupt-cells. When
interpreting the "interrupts" property of some node, you walk the
interrupt tree (which can be the same as the device tree, or fully
separate, or share some things; and doesn't have to be a tree either)
up to the next interrupt controller, and use the #interrupt-cells
from that. (This is simplified a little bit).
>>> + auxram at 0c005000 {
>>> + compatible = "nintendo,flipper-auxram";
>>> + reg = <0x0c005000 0x200>; /* DSP */
>>> + interrupts = <6>;
>>> + interrupt-parent = <&pic>;
>>> + };
>>> +
>>> + audio at 0c005000 {
>>> + compatible = "nintendo,flipper-audio";
>>> + reg = <0x0c005000 0x200 /* DSP */
>>> + 0x0c006c00 0x20>; /* AI */
>>> + interrupts = <6>;
>>> + interrupt-parent = <&pic>;
>>> + };
>>
>> These two have the same address, not good. Just remove the
>> auxram node?
>
> The DSP and the ARAM control/status bits share some registers in
> the same block.
>
> How should I match the aram block driver if I remove the auxram node?
You can make aram a child node of dsp, which allows you to show
its size as well. I.e. you do #a-cells=1 #s-cells=1 in the dsp
node, and reg=<0 01000000> in the aram node.
Or you can do a simple property in the dsp node saying how big
the aram is, and assume the driver(s) that match know(s) how to
drive it. You have to assume this anyway, you're not putting
e.g. bytecode drivers in the device tree ;-)
>> ...and all the applicable things I mentioned in my Wii dev tree
>> reply, of course.
>>
>> Wow, it wasn't as bad as I expected actually. But you cheated,
>> you omitted most devices from the device trees :-)
>
> You're welcome to add them too if you have information about them :)
I'll do that later, yes. It's not so big a problem if the device
tree doesn't describe devices you do not support at all.
Segher
More information about the Linuxppc-dev
mailing list