[Power.org:parch] cpu nodes and Power ISA categories

[Dan Hettena]

> > In section 3.7.1 (General Properties of CPU nodes), add the following
> properties to the table in ePAPR 1.1:
> >
> > (1)
> >
> > Property Name: power-isa-impl-version
> > Usage: O
> > Value Type: <string>
> > Definition: Specifies the architecture version number (e.g., "2.06")
> with which this cpu is compliant.
> ...
> Rather than a separate property, I'd suggest here we define a
> convention for strings which can go into the compatible property of
> the cpu nodes.  So for example:
> 	cpu at 0 {
> 		compatible = "ibm,POWER6", "powerpc,ISA-2.06";
> 		....
> 	};
> 
> (I'm not sure if that example is actually correct, but you get the idea).

That would be fine if powerpc were changed to power.

> > (2)
> >
> > Property Name: power-isa-impl-categories
> > Usage: O
> > Value Type: <stringlist>
> > Definition: Specifies all the implemented architectural categories,
> > in their abbreviated form, as specified in Book I of the selected
> > ISA version (e.g., "B","E","ECL","E.HV").
> 
> This sounds ok, but I'd suggest some minor changes to the naming.  It
> seems to me to make sense to treat "powerpc" as a quasi-vendor, and I
> think we want to avoid abbreviations in property name.  So perhaps:
> 	powerpc,implementation-categories = "E.HV";
> 
> I'm not really familiar with the Book I defined categories, so I can't
> comment on the content encoding at this point.

Again, change powerpc to power and I'm happy.

> > (3) For my amusement...
> >
> > Property Name: power-isa-impl-errata
> > Usage: O
> > Value Type: <stringlist>
> > Definition: Specifies a list of exceptions to the cpu's compliance
> > with the architecture. Each exception consists of a pair of strings
> > where the first string in the pair is the most general architectural
> > category impacted by the exception and the second string is a name
> > for the erratum. For example, a cpu node for an e500v1 core might
> > include "ECL","fsl-icbtls-isync-itlb-miss" to indicate that
> > undefined behavior can result if the execution of an icbtls
> > instruction is not separated from a subsequent ITLB miss by an isync
> > instruction. An OS may choose to avoid making use of a category if
> > it does not have workarounds for all listed errata.
> 
> Interesting idea, not sure if it's practical or not.  I think we'd
> need to pin down a bit more where the errata defintions would reside /
> who'd be responsible for the official list of defined errata and so
> forth.

I doubt it's practical. The biggest problem I see is that device trees ship (or at least always ought to ship) with hardware, and hardware tends to ship before all errata are known.

There is a general problem here though: Devices often fail to comply fully with the specifications implied by their "compatible" properties, so a generic driver for a device might not work unless there's some way to tell it what functionality of the device to avoid.

As to your question, the provider of the device (and thus the device tree node) would have to be responsible for specifying the errata, and I imagine there would be various pressures not to do that. Not everyone even makes their errata public.

I suspect the only real solution to this problem is the one we're used to: If the generic driver can't work with the device because the device is broken, then use a driver more specific to the device that knows how to get it to behave.

Dan