[PATCH v3] [RFC] arm: use PSCI if available

[Rob Herring]

On 03/27/2013 01:12 PM, Will Deacon wrote:
> On Wed, Mar 27, 2013 at 05:50:51PM +0000, Arnd Bergmann wrote:
>> On Wednesday 27 March 2013, Will Deacon wrote:
>>> The channel is common, sure, but I wouldn't expect the semantics of each
>>> call to be identical between firmware implementations (going back to my
>>> previous examples of CPU IDs and implementation-defined state parameters).
>>>
>>> If a platform happens to have an id-mapping from smp_operations to psci,
>>> then I still think there should be an indirection in there so that we have
>>> the flexibility to change the smp_operations if we wish and not give
>>> platforms the false impression that these two things are equivalent.
>>
>> I think the only reasonably implementation for psci is if we can assume
>> that each callback with a specific property name has a well-defined behavior,
>> and we should mandate that every platform that implements the callbacks
>> we need for SMP actually implements them according to the spec.
>>
>> What would be the point of a standard psci interface if the specific
>> implementation are not required to follow the same semantics?
> 
> The interface *is* standard. The functions have well-defined headers and can
> be called in the same way between implementations. The difference is in the
> semantics of the parameters. For example:
> 
>   int cpu_off(u32 power_state);
> 
> If you look at the power_state parameter, it's actually a struct (see struct
> psci_power_state) with a u16 id field. The current specification describes
> that field as `This is platform specific, the number is understood by the
> firmware, and used to program the power controller.'.
> 
> So unless we get everybody to agree on the definition of that field, we
> can't blindly plug the interfaces together. Furthermore, there are other
> parameters like this and, as new functions are specified, I would expect
> them to grow.

Which is why I've said I think the ID field is a bad idea. I've used it
in my implementation, but only in the case of system level reset,
power-off, and suspend. I don't see how it would be used otherwise.

I guess you could define a value of 0 must be supported at a minimum and
then default implementation would at least work to some level.

Rob