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

[Albert Herranz]

Benjamin Herrenschmidt wrote:
>>> Good point. I can't even guarantee that the kernel will work reliably
>>> with nobats :-) At least you really want the kernel .text to be fully
>>> covered by an IBAT.
>>>
>> It works with nobats.
> 
> But does it work -reliably- ? :-)
> 

It does AFAICT. My Wii is a 24x7 linux box although it is not stressed in any way usually.

> Any ways, not a big deal right now, as I said, we really want the BATs
> for performances anyways, so we should probably just add some kind of
> hack in mmu_mapin_ram() for the time being.
> 

Yup. The idea is to map the first 16MB of MEM1 with a BAT.
Mapping the whole 24MB with BATs may not be possible because we want the framebuffer in MEM1 for performance reasons.

>> I must say that all the patches posted (and the device drivers, which haven't
>> been posted yet) are tested and working code.
> 
> That was my impression too, but in this case, I'm talking about a
> potential very hard to hit problem that you may well have never managed
> to actually trigger.
> 

I haven't actually, if that applies :)

>> There you can find the hardware interface that supports the IPC mechanism.
>> It is made up of a pair of registers to pass data between the processors and a
>> pair of control/flags registers.
>> The hardware can interrupt the PowerPC side when there is data available for it.
> 
> Ok. So the right way to do that would be to have a node purely
> representing the HW IPC, unrelated to whatever is running on the
> secondary processor.
> 

Totally agreed.

> However, it's ok to have -below- that node, a set of device nodes or a
> node with properties or whatever representing the FW in there and the
> function it exposes.
> 
> That can be discussed later tho. I'm not that keen on having those info
> be in the .dts coming with the kernel since those functions essentially
> depend on what FW is loaded on the aux. processor.
> 

I think we can leave this for later as you said.

> What might do however is to have a way for that FW itself to provide you
> with the nodes and properties for the functions it provides :-) Then you
> can have the boot wrapper or the kernel platform init code use some well
> defined (and as stable as possible) IPC API to identify the FW there and
> expose all that stuff.
> 

Segher was playing with an OF implementation...

> Of course that wouldn't work with FW we don't have control on. Can Linux
> run on the wii with the original N. FW on the aux. processor ? Can we
> detect what is running there ? Do we care ?
> 

Yes, it can. And it is done. But I think we don't care/need that in mainline.

>> It is what Nintendo calls the "Serial Interface" (SI) which is a proprietary
>> serial hardware to drive the gamepads (and a custom keyboard too, once available
>> for an RPG game).
> 
> So I would give it a different name than "serial" then. Make it gpsi
> maybe ? (game pad serial interface ?) :-) Or invent something else...
> 

I'd choose "gcnsi" with a compatible like "nintendo,gamecube-si" :)

(gcn is the official short abbreviation for the Nintendo GameCube)

> Cheers,
> Ben.
> 

Thanks,
Albert