On Fri, Apr 26, 2013 at 03:51:10AM +0100, Rob Herring wrote:
> On Wed, Apr 24, 2013 at 12:28 PM, Lorenzo Pieralisi
> <lorenzo.pieral...@arm.com> wrote:
> > In order to extend the current cpu nodes bindings to newer CPUs
> > inclusive of AArch64 and to update support for older ARM CPUs this
> > patch updates device tree documentation for the cpu nodes bindings.
> >
> > Main changes:
> >     - adds 64-bit bindings
> >     - define usage of #address-cells
> >     - define 32/64 dts compatibility settings
> >     - defines behaviour on pre and post v7 uniprocessor systems
> >     - adds ARM 11MPcore specific reg property definition
> >
> > Signed-off-by: Lorenzo Pieralisi <lorenzo.pieral...@arm.com>
> > ---
> 
> [...]
> 
> > +       - enable-method
> > +               Value type: <stringlist>
> > +               Usage and definition depend on ARM architecture version and
> > +               configuration:
> > +                       # On ARM v8 64-bit systems running the OS in 
> > AArch64,
> > +                         this property is required and must be 
> > "spin-table".
> 
> What about PSCI?

I should add it, at least for ARM v8.

> I don't think the ePAPR spin-table definition is sufficient for ARM.
> How do you define wake up by SGI or sev instruction.

I think Will described the wfe/sev mechanism in:

Documentation/arm64/booting.txt

and the ePAPR does the same in 5.5.2.2/5.5.2.3. Since this is a document
describing cpus/cpu nodes bindings I assume that description does not
belong here. Question is: do we need to specify an ARM implementation
specific enable-method to describe SGI/sev wake-up (ePAPR 5.5.3) ?

> > +                       # On ARM 32-bit systems or ARM v8 systems running
> > +                         the OS in AArch32 this property is prohibited.
> 
> Why?

Because if we define it optional with no possible set of values basically
it can be whatever string. I could define it optional with the same
allowed values as ARM v8 even if it is currently ignored, at least in Linux,
until PSCI implementations get merged.

Thanks,
Lorenzo

_______________________________________________
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss

Reply via email to