ePAPR 1.1 to do list

ePAPR 1.1 to do list

[Yoder Stuart-B08248]

I've consolidated what I am aware of with respect to errors found in
1.0,
clarifications needed, and new mechanisms to go into ePAPR 1.1 into
a single list.

Let me know if you are aware of anything else.

ePAPR 1.1 To Do
---------------

1. Fix typos, misc cleanup

   -device_type="simple-bus" in 8572 soc node example (p.96)
   -p.51, line 27-- ET_EXEC is 0x2 not 0x1
   -p.41, broken cross reference
   -missing period on virtual reg on ns16550

2. Representation of hw threads in device trees

   -proposal:
 
<http://lists.ozlabs.org/pipermail/devicetree-discuss/2010-March/001927.
html>

3. Provide way for client program to determine type of
   MMU, without parsing device tree

     -proposal:
       -specify an enum value in R8
       -convey MMU type in dev tree as well

4. Define new spin table enable method that specifies
   that spin table is mapped cacheable and coherent
     -proposal:
        -"spin-table-v2"

5. more compact/consolidated representation of CPU nodes
   -if there are 16 or 64 identical CPUs specifying all
    properties in each can get very verbose
   -proposal:
      -move common properties to /cpus

6. Provide mechanism on CPU node to convey non-probeable
   aspects of which Power arch categories are implemented

7. For IMAs clarify
     -some places say virt must equal phys
     -but requirements on p.53 don't say that
     -how do OSes determine the physical address of the IMA
        -initial-mapped-area is optional

8. For DMA devices, define standard property that conveys the
   the address width a device is capable of?  e.g. a PCI
   device that can only address 32-bits.

9. stdout/stdin alias

10. ns16550 binding
   -why is number of interrupt specifiers undefined?

11. Multi-level caches (p. 18)
   -comment saying cache nodes must/shall be under a cpu node
    necessarily doesn't make sense
       -should qualify it saying-- it the node does not have another
place
        to stick it, use one of the cpu nodes

12. "label" property
   -make is standard

Regards,
Stuart

Re: [Power.org:parch] ePAPR 1.1 to do list

[Scott Wood]

On Mon, 30 Aug 2010 14:34:44 -0700
Yoder Stuart-B08248 <B08248-KZfg59tc24xl57MIdRCFDg@public.gmane.org> wrote:

> I've consolidated what I am aware of with respect to errors found in
> 1.0,
> clarifications needed, and new mechanisms to go into ePAPR 1.1 into
> a single list.
> 
> Let me know if you are aware of anything else.

2.2.1.1 should perhaps have a stronger connection between unit addresses
and reg -- if you don't have the latter, you can't have the former.
This is required for bindings to work on real Open Firmware.  David
Gibson just posted a patch to dtc yesterday that verifies this.

Disambiguation without reg can still be achieved by appending numbers
to the node names, without @.

One use case to consider is nodes that have no reg, but do have
ranges, such as the somewhat misnamed "soc" nodes.  The unit address
mechanism has similar advantages here as with reg (a standardized way
to disambiguate based on child-bus address, and ability to omit the unit
address to get the first one).  We could make the rule be "first reg
address, if no reg then first ranges child-bus address, if no reg or
ranges then no unit address".

Such unit addresses may not work on true OF as is, but bindings should
not require the use of unit addresses -- and if people using real OF
find them useful, it doesn't seem like it would be unreasonable to
modify OF to support ranges-based unit addresses in the absence of reg.

-Scott

Re: [Power.org:parch] ePAPR 1.1 to do list

[David Gibson]

On Mon, Aug 30, 2010 at 05:33:14PM -0500, Scott Wood wrote:
> On Mon, 30 Aug 2010 14:34:44 -0700
> Yoder Stuart-B08248 <B08248-KZfg59tc24xl57MIdRCFDg@public.gmane.org> wrote:
> 
> > I've consolidated what I am aware of with respect to errors found in
> > 1.0,
> > clarifications needed, and new mechanisms to go into ePAPR 1.1 into
> > a single list.
> > 
> > Let me know if you are aware of anything else.
> 
> 2.2.1.1 should perhaps have a stronger connection between unit addresses
> and reg -- if you don't have the latter, you can't have the former.
> This is required for bindings to work on real Open Firmware.  David
> Gibson just posted a patch to dtc yesterday that verifies this.

Unsurprisingly, I also think this would be a good idea.

> Disambiguation without reg can still be achieved by appending numbers
> to the node names, without @.

And since this is already a standard practice in a bunch of 4xx device
trees, we should at least include mention of it as a programmer's note
in ePAPR.

> One use case to consider is nodes that have no reg, but do have
> ranges, such as the somewhat misnamed "soc" nodes.  The unit address
> mechanism has similar advantages here as with reg (a standardized way
> to disambiguate based on child-bus address, and ability to omit the unit
> address to get the first one).  We could make the rule be "first reg
> address, if no reg then first ranges child-bus address, if no reg or
> ranges then no unit address".
> 
> Such unit addresses may not work on true OF as is, but bindings should
> not require the use of unit addresses -- and if people using real OF
> find them useful, it doesn't seem like it would be unreasonable to
> modify OF to support ranges-based unit addresses in the absence of reg.

Yeah, the ranges-based unit address convention is already used in some
fsl trees.  Some IBM firmware people (with something that has both
real OF and ePAPR aspects) came up with an interesting approach to
this one.  On a bus bridge with no-MMIO they created a dummy 'reg'
property with zero length (at the same address as the first 'ranges'
entry, IIRC).  This had the advantage of Just Working with the
existing internal OF code, and doesn't appear to confuse anything, so
far.

Not sure which way is the better option for estabishing a firm
convention.

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

Re: [Power.org:parch] ePAPR 1.1 to do list

[Scott Wood]

On Mon, 30 Aug 2010 14:34:44 -0700
Yoder Stuart-B08248 <B08248-KZfg59tc24xl57MIdRCFDg@public.gmane.org> wrote:

> I've consolidated what I am aware of with respect to errors found in
> 1.0,
> clarifications needed, and new mechanisms to go into ePAPR 1.1 into
> a single list.
> 
> Let me know if you are aware of anything else.
> 
> ePAPR 1.1 To Do
> ---------------
> 
> 1. Fix typos, misc cleanup
> 
>    -device_type="simple-bus" in 8572 soc node example (p.96)
>    -p.51, line 27-- ET_EXEC is 0x2 not 0x1
>    -p.41, broken cross reference
>    -missing period on virtual reg on ns16550

2.3.11 says device_type should only be present for cpu and memory
nodes, but the example trees in the appendices contain device_type =
"serial", "network", "pci", and "open-pic" (as well as the simple-bus
error mentioned above).

In general the examples should be checked for compliance and current
best practices (e.g. the 8572ds tree has a node named "soc8572") -- and
perhaps should show what the tree looks like after "filled in by
u-boot" has taken place.

-Scott

Re: [Power.org:parch] ePAPR 1.1 to do list

[David Gibson]

On Mon, Sep 13, 2010 at 01:17:52PM -0500, Scott Wood wrote:
> On Mon, 30 Aug 2010 14:34:44 -0700
> Yoder Stuart-B08248 <B08248-KZfg59tc24xl57MIdRCFDg@public.gmane.org> wrote:
> 
> > I've consolidated what I am aware of with respect to errors found in
> > 1.0,
> > clarifications needed, and new mechanisms to go into ePAPR 1.1 into
> > a single list.
> > 
> > Let me know if you are aware of anything else.
> > 
> > ePAPR 1.1 To Do
> > ---------------
> > 
> > 1. Fix typos, misc cleanup
> > 
> >    -device_type="simple-bus" in 8572 soc node example (p.96)
> >    -p.51, line 27-- ET_EXEC is 0x2 not 0x1
> >    -p.41, broken cross reference
> >    -missing period on virtual reg on ns16550
> 
> 2.3.11 says device_type should only be present for cpu and memory
> nodes, but the example trees in the appendices contain device_type =
> "serial", "network", "pci", and "open-pic" (as well as the simple-bus
> error mentioned above).

Ugh, yeah.  This is a little complicated.  So, the rule of thumb we've
been using in the wild is slightly more nuanced than ePAPR states.  It
is basically:
	- *do* use device_type on cpu and memory nodes
	- use of existing real-OF defined device types ("serial",
"network" and "pci") is acceptable, but not required.  It's quite
likely that existing OSes may use "pci" in particular, so this is
somewhat important for compatibility with OF practice
	- absolutely *don't* define and use any new, not already OF
established device_type values

"open-pic" has its own complications.  It's very nasty to have it in
an ePAPR context, but of course the open-pic binding is an old real-OF
binding that will specify "device_type", and existing open-pic drivers
may expect it.

I'm not sure how best to deal with these.

> In general the examples should be checked for compliance and current
> best practices (e.g. the 8572ds tree has a node named "soc8572") -- and
> perhaps should show what the tree looks like after "filled in by
> u-boot" has taken place.

I think such a general audit is a very good idea, though.

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

RE: [Power.org:parch] ePAPR 1.1 to do list

[Yoder Stuart-B08248]

> -----Original Message-----
> From: Wood Scott-B07421
> Sent: Monday, September 13, 2010 1:18 PM
> To: Yoder Stuart-B08248
> Cc: parch-QRwYI7m9GJLYtjvyW6yDsg@public.gmane.org; devicetree-discuss
> Subject: Re: [Power.org:parch] ePAPR 1.1 to do list
> 
> On Mon, 30 Aug 2010 14:34:44 -0700
> Yoder Stuart-B08248 <B08248-KZfg59tc24xl57MIdRCFDg@public.gmane.org> wrote:
> 
> > I've consolidated what I am aware of with respect to errors found in
> > 1.0, clarifications needed, and new mechanisms to go into ePAPR 1.1
> > into a single list.
> >
> > Let me know if you are aware of anything else.
> >
> > ePAPR 1.1 To Do
> > ---------------
> >
> > 1. Fix typos, misc cleanup
> >
> >    -device_type="simple-bus" in 8572 soc node example (p.96)
> >    -p.51, line 27-- ET_EXEC is 0x2 not 0x1
> >    -p.41, broken cross reference
> >    -missing period on virtual reg on ns16550
> 
> 2.3.11 says device_type should only be present for cpu and memory nodes,
> but the example trees in the appendices contain device_type = "serial",
> "network", "pci", and "open-pic" (as well as the simple-bus error mentioned
> above).

Note-- the upstream device tree still has those device_type properties.
Should we still remove them from the example?

Stuart

Re: [Power.org:parch] ePAPR 1.1 to do list

[Scott Wood]

On Tue, 11 Jan 2011 16:14:53 -0600
Yoder Stuart-B08248 <B08248-KZfg59tc24xl57MIdRCFDg@public.gmane.org> wrote:

> 
> 
> > -----Original Message-----
> > From: Wood Scott-B07421
> > Sent: Monday, September 13, 2010 1:18 PM
> > To: Yoder Stuart-B08248
> > Cc: parch-QRwYI7m9GJLYtjvyW6yDsg@public.gmane.org; devicetree-discuss
> > Subject: Re: [Power.org:parch] ePAPR 1.1 to do list
> > 
> > On Mon, 30 Aug 2010 14:34:44 -0700
> > Yoder Stuart-B08248 <B08248-KZfg59tc24xl57MIdRCFDg@public.gmane.org> wrote:
> > 
> > > I've consolidated what I am aware of with respect to errors found in
> > > 1.0, clarifications needed, and new mechanisms to go into ePAPR 1.1
> > > into a single list.
> > >
> > > Let me know if you are aware of anything else.
> > >
> > > ePAPR 1.1 To Do
> > > ---------------
> > >
> > > 1. Fix typos, misc cleanup
> > >
> > >    -device_type="simple-bus" in 8572 soc node example (p.96)
> > >    -p.51, line 27-- ET_EXEC is 0x2 not 0x1
> > >    -p.41, broken cross reference
> > >    -missing period on virtual reg on ns16550
> > 
> > 2.3.11 says device_type should only be present for cpu and memory nodes,
> > but the example trees in the appendices contain device_type = "serial",
> > "network", "pci", and "open-pic" (as well as the simple-bus error mentioned
> > above).
> 
> Note-- the upstream device tree still has those device_type properties.
> Should we still remove them from the example?

How about we remove them from upstream, and fix any code that relies on
it?

-Scott