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

[robherring2@gmail.com (Rob Herring)]

On 03/28/2013 10:39 AM, Nicolas Pitre wrote:
> On Thu, 28 Mar 2013, Rob Herring wrote:
> 
>> On 03/28/2013 09:51 AM, Nicolas Pitre wrote:
>>> On Thu, 28 Mar 2013, Stefano Stabellini wrote:
>>>
>>>> - the interface to bring up secondary cpus is different and based on
>>>> PSCI, in fact Xen is going to add a PSCI node to the device tree so that
>>>> Dom0 can use it.
>>>>
>>>> Oh wait, Dom0 is not going to use the PSCI interface even if the node is
>>>> present on device tree because it's going to prefer the platform smp_ops
>>>> instead.
>>>
>>> Waitaminute...  I must have missed this part.
>>>
>>> Who said platform specific methods must be used in preference to PSCI?
>>
>> I did. Specifically, I said the platform should be allowed to provide
>> its own smp_ops. A platform may need to do addtional things on top of
>> PSCI for example.
> 
> Then the platform should have its special hook that would override the 
> default PSCI methods.  But, by *default* the PSCI methods should be used 
> if the related DT information is present.

Agreed. The special hook to override is setting mach desc smp_ops, right?

>>> If DT does provide PSCI description, then PSCI should be used.  Doing 
>>> otherwise is senseless.  If PSCI is not to be used, then it should not 
>>> be present in DT.
>>
>> You can't assume the DT and kernel are in-sync. For example, I've added
>> PSCI in the firmware and DTB (part of the firmware), but the highbank
>> kernel may or may not use it depending if I convert it.
> 
> If the kernel does not understand PSCI bindings in the DT, it naturally 
> won't use PSCI, right?  Conversely, if the firmware and therefore 
> provided DT don't have PSCI, then the PSCI enabled kernel won't use PSCI 
> either. So what is the problem?

I'm distinguishing the kernel in general is enabled for PSCI and a
platform is enabled. The kernel may have PSCI smp_ops and the DTB may
have PSCI data, but that alone should not make a platform use the
default PSCI smp_ops. The platform has to make the decision and it
cannot be just based on the platform's dtb having PSCI data.

I have firmware (dtb is part of the firmware) with PSCI support and
older firmware without. Old/existing kernels are fine on both firmware
versions and don't use PSCI. New kernels with default PSCI ops should
continue to work with both versions. When/If I convert highbank to use
PSCI in the kernel, only then will new kernels require the new firmware
version. Or perhaps I need to support both in the kernel for a while
before ripping out non PSCI code. There is enough lag in distro kernels
that I don't think this is necessary.

Rob