[Power.org:parch] cpu nodes and Power ISA categories
David Gibson
dwg at au1.ibm.com
Tue Sep 21 12:57:59 EST 2010
On Sun, Sep 19, 2010 at 11:35:40PM -0700, Dan Hettena wrote:
> > > 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.
Um.. why? I thought the name of the actual architecture was "PowerPC"
and that "power" was just an IBM brand name (where POWER3 and later in
the line are PowerPC architecture compliant).
> > > (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.
Yeah. Well.. almost never would the *board* errata all be known. The
cpu errata might, if plenty of other boards have been made with it
first. But still.
> 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.
Uh, sorry. I didn't mean who decides what errata a particular device
advertises. I mean who manages the database of what each errata
string means.
> 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.
Indeed. Or the theoretically similar approach of having a general
driver occasionally check for more specific compatible strings in
order to switch workarounds on or off.
It's ugly, but I think inevitable, and at least pretty flexible. I
think we can only reasonably aim for "best effort" in providing
complete and correct information in the device tree. Code workarounds
for the odd mis-specified thing is unavoidable, alas, we just want to
make them as infrequent as we can within the bounds of reasonable
effort.
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
More information about the devicetree-discuss
mailing list