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

+               aux...@0c005000 {
+                       compatible = "nintendo,flipper-auxram";
+                       reg = <0x0c005000 0x200>; /* DSP */
+                       interrupts = <6>;
+                       interrupt-parent = <&pic>;
+               };
+
+               au...@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

_______________________________________________
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Reply via email to