resend-- RFC: representation of CPUs/threads in device trees

[Yoder Stuart-B08248]

There is no standard binding for how hardware threads
(which in most cases share an MMU) for the Power 
architecture are represented in device trees.

The IBM SPAPR uses the ibm,ppc-interrupt-server#s.
property, which is an array with 1 element per thread.  The
number is used in addressing by the interrupt controller.

The question of how/if a CPU or thread's PIR value is
represented is also relevant.  Some CPUs have an unmodifiable
PIR number space that is distinct from the number space
addressed from the interrupt controller.

The proposal below outlines a general approach.  If there
is consensus, this would eventually get written up in a
more formal form and added to the ePAPR.

Regards, Stuart Yoder

=============================================================

-CPUs and threads are numbered through a unified
 number-space  that should match as closely as possible
 the interrupt controller's numbering of CPUs/threads

-What goes under a CPU node?

  -generally, a CPU node represents a hardware
   execution block that is sufficiently independent that
   it is capable of running an operating system without
   interfering with other CPUs possibly running other
   operating systems.

  -threads that share an MMU would generally be
   represented under 1 CPU node

  -If other more complex CPU topographies
   are designed the CPU binding must describe the
   topology (e.g. threads that don't share an MMU).

-If a CPU/thread can be the target of an external
 interrupt the "reg" property value must contain a unique
 CPU/thread id that is addressable by the interrupt
 controller

-If a CPU/thread cannot be the target of an external
 interrupt, then "reg" must be unique and out of bounds
 of the range addressed by the interrupt controller

-If a CPU supports more than one thread (i.e. multiple
 streams of execution) the "reg" property is an array with
 1  element per thread

-The #address-cells property on the "cpus" container
 specifies  how many cells each element of the "reg"
 property array takes

-Software can determine the number of threads by dividing
 the size of "reg" by "#address-cells"

-If a CPU/thread's PIR is modifiable it should be modified
 to match the "reg" property value.  If PIR cannot be
 modified and the PIR value is distinct from the interrupt
 controller numberspace, the CPUs binding may define a
 binding-specific representation of PIR values if desired.

-Regarding a standardized way to start secondary threads--

   -The current spin table mechanism is not thread safe and
    is insufficient for starting threads.

   -Given the variety of implementations in IBM and
    Freescale roadmaps, it is highly questionable whether
    a common thread release mechanism can be defined for
    all threaded CPUs.  Specific release methods for
    different processors most likely needs to be created
    and defined in processor bindings.