[PATCH 3/3] First cut at PReP support for arch/powerpc

[Segher Boessenkool]

>>>> +			external-control;
>>>>
>>>> Really?
>>>
>>> Well, is anybody actually using eciwx/ecowx?
>>
>> That's not the point -- the device tree should only
>> say "external-control" if the CPU actually supports
>> it; AFAIK, that's 601 only.
>
> I wonder whether you are mixing up external control
> and direct-store segments (the "T" bit in segment registers).

“external-control” prop-encoded-array: <none>
	This property, if present, indicates that the PowerPC
	microprocessor defined by this CPU node implements the
	External Control Facility as described in the “Optional
	Facilities and Instructions” appendix of Book II of [2].
	The absence of his property indicates that the PowerPC
	microprocessor defined by this CPU node does not support
	the External Control Facility.

No, I don't think I'm mixing up anything.  G2 CPUs don't
support this stuff, do they?

>> From my docs, external control has been supported by many
> processors, up to many variants of the 750 and even 7440/7450.

Hrm I don't think so...  </me looks>...  erm yeah.  It's just
that it isn't usable on any of those systems ;-)

> Now I've never seen any hardware which could make use of these
> instructions (you'd need a device on the processor bus that
> reacts to the special bus cycles generated by the ec[io]wx
> instructions, since no host bridge I've ever met handles them.

Yeah exactly.

> I've not seen support for external control in the Linux kernel
> either (you'd need to setup the EAR SPR and probablly to modify
> it on context switches).
>
> OTOH, the direct-store segments were only implemented in the
> original 601, 603 (not 603e) and 604 processors (can't remember
> about the 604e) and even then the 601 had special features
> in this area.

Yah.

>>>> +	pci at 80000000 {
>>>> +		device_type = "pci";
>>>> +		compatible = "prep";
>>>>
>>>> Is that specific enough?
>>>
>>> On the MVME5100, actually the mapping is more CHRP like, and PCI I/O
>>> space is smaller and at a higher address.
>>
>> Right, so it's not; "compatible" should specify the
>> model of PCI host bridge, instead.
>
> Well, the PCI host bridge is reprogrammable in a very flexible way
> and  and I actually wrote a boot loader that reprograms it the
> way I wanted address space to look like.

"compatible" should just say what exactly the hardware is;
"prep" isn't good enough to describe a certain PCI host
bridge (it doesn't say it is a PHB, to start with!)

> I shall send it to
> you in a PM (it is quite big, it includes an x86 emulator
> which is able to initialize the VGA PMC modules I have by
> running the BIOS).

Hrm I'm not sure what I should do with that?


Segher