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

[Benjamin Herrenschmidt]

> > 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- ? :-)

I haven't looked at that for years, but we used to have a subtle issue
if you happen to take a hash miss on the kernel text or data in the
wrong time, such as when SRR0/SRR1 are modified and before a subsequent
rfi. This is very very hard to trigger and maybe impossible without SMP
but to keep in mind.

Paulus added some code ages ago to close most of these by using the
MSR:RI bit so that the hash code could detect the situation and branch
to some "recovery" code, but from memory, while that dealt with missing
D-BATs, we still had a potential window of problem if the kernel text
itself wasn't entirely covered.

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.

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

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

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.

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.

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 ?

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

Cheers,
Ben.

> > Cheers,
> > Ben.
> > 
> 
> Thanks,
> Albert