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

[Segher Boessenkool <segher@kernel.crashing.org>]

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

=93external-control=94 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 =93Optional
	Facilities and Instructions=94 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?

>> =46rom 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@80000000 {
>>>> +		device_type =3D "pci";
>>>> +		compatible =3D "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