[RFC PATCH 04/19] powerpc: wii: device tree

[Segher Boessenkool]

>> +/memreserve/ 0x01800000 0xe800000;	/* memory hole (includes I/O  
>> area) */
>> +/memreserve/ 0x10000000 0x0004000;	/* DSP RAM */
>
> Weird layout... nothing you can do about I suppose.
>
> Out of curiosity, what is that DSP RAM ? Some actual DSP core  
> somewhere
> in the IO chip setup to use memory from up there ?

It's an actual DSP yes, and it seems it uses that fixed address range
(at the start of the 64MB GDDR3 memory) always.  So we have to stay
away from that memory range.

>> +	memory {
>> +		device_type = "memory";
>> +		/* MEM1 + memory hole + MEM2 - firmware/buffers area */
>> +		reg = <0x00000000 0x133e0000>;
>> +	};
>
> So we do have a nasty hole here in the middle. How bad it is if you  
> try
> to just have two ranges in there (ie as if it was discontiguous) ?

Not bad at all.  There is no "as if" -- it _is_ discontiguous memory,
they are totally different memory technology even.

>> +		/* Team Twiizers' 'mini' firmware IPC */
>
> Out of curiosity, what are these ? :-)

There is an embedded ARM9 in the Hollywood.  It is "the boss" of the
system, not the PowerPC.  "mini" is the name of the code we run on it.

There is a hardware IPC interface between the ARM and the PowerPC (just
a bunch of doorbells and general purpose regs).

> Similar comment as before, could the above be dynamically probed ? If
> you are not a hacker you may not need that at all to use some linux
> based piece of SW on the wii right ?

Yeah.  Well, after any other drivers have been merged, anyway, heh :-)

>> +		ohci1 at 0d060000 {
>
> Why the "1" ?

Right, call them both just "ohci" please.  Or "usb" even.

>> +		PIC1: pic1 at 0d800030 {
>> +			#interrupt-cells = <1>;
>> +			compatible = "nintendo,hollywood-pic";
>> +			reg = <0x0d800030 0x8>;
>> +			interrupt-controller;
>> +			interrupts = <14>;
>> +			interrupt-parent = <&PIC0>;
>> +		};
>
> Ah, a cascaded PIC, fun fun fun

Well at least this cascaded PIC is sane, the root PIC is less so :-P

>> +		hollywood-ahbprot at 0d800064 {
>> +			compatible = "nintendo,hollywood-ahbprot";
>> +			reg = <0x0d800064 0x4>;
>> +		};
>
> What is this ?

Most of the devices new in Hollywood (AES engine, NAND engine, USB,
SD, etc.) sit on an AHB bus.  The AHBPROT register is used to configure
which of these can be accessed from the PowerPC.

Modern "mini" always gives us full control.  Also, there is no reason
to single out the AHBPROT reg in the device tree like this, anyway.


Segher