From mboxrd@z Thu Jan  1 00:00:00 1970
From: robherring2@gmail.com (Rob Herring)
Date: Tue, 30 Jul 2013 07:42:49 -0500
Subject: [PATCH 1/7] dt: update PSCI binding documentation for v0.2
In-Reply-To: <20130730094920.GC28716@e106331-lin.cambridge.arm.com>
References: <20130730094920.GC28716@e106331-lin.cambridge.arm.com>
Message-ID: <51F7B4C9.2060500@gmail.com>
To: linux-arm-kernel@lists.infradead.org
List-Id: linux-arm-kernel.lists.infradead.org

On 07/30/2013 04:49 AM, Mark Rutland wrote:
> On Mon, Jul 29, 2013 at 09:18:43PM +0100, Rob Herring wrote:
>> On 07/29/2013 05:13 AM, Mark Rutland wrote:
>>> Hi Rob,
>>>
>>> On Sun, Jul 28, 2013 at 10:56:32PM +0100, Rob Herring wrote:
>>>> From: Rob Herring <rob.herring@calxeda.com>

[snip]

>>> One of the things changed in PSCI 0.2 was the SMC calling convention,
>>> though this isn't clear in the PSCI document. The function IDs for 32bit
>>> and 64bit callers may differ, and we need to support describing an
>>> arbitrary configuration of the two (same ID for both, different across
>>> 32-bit/64-bit, only supported for 64-bit, only supported for 32-bit).
>>>
>>> I'd like to ensure the binding can deal with that from the start. We
>>> could do this by having -32 and -64 variants of each function id (e.g.
>>> cpu_off-64) , if the IDs actually differ, and use the regular combined
>>> ID if they don't.
>>
>> Uggg. I guess I should have read the SMC calling convention doc... I was
>> simply documenting what is already in the PSCI doc, but obviously that
>> is not fully flushed out.
>>
>> How about something like this (for the complicated case of both 32 and
>> 64 bit):
>>
>> 	method		= "smc", "smc64";
>> 	psci_version	= <0x84000000 0xc4000000>;
>> 	cpu_suspend	= <0x84000001 0xc4000001>;
>> 	cpu_off		= <0x84000002 0xc4000002>;
>> 	cpu_on		= <0x84000003 0xc4000003>;
>>
>> "smc" is a synonym for smc32 for compatibility. The number and order of
>> methods determines the number and order of function IDs.
> 
> While this may be compatible with the arm implementation, it won't be
> compatible with the arm64 implementation, which assumes smc64 by
> default.
> 
> As far as I am aware, the implementations currently in use (KVM and Xen)
> use the same ID for both, so I think "smc" should cover an ID valid for
> a native register width calling convention, and "smc64" and "smc32"
> describing values only valid for 64-bit wide and 32-bit wide calling
> conventions respectively.

The problem is that does not work for a 32-bit kernel on 64-bit h/w as
native from the dts perspective is smc64. Just like the cpu bindings,
the binding cannot change based on 32 or 64 bit OS. I don't think we
really have to deal with that here. We can simply say "smc" is only for
"arm,psci" and deprecated for "arm,psci-0.2".

> I've added Christoffer, Marc, and Stefano to Cc in case they have any
> comments.
> 
>>
>> A variation on this would be keep method as is and add a "#psci-cells"
>> property to specify the number of function IDs. You can determine the
>> 64-bit vs. 32-bit support based on the function ID itself.
> 
> I don't think that's a good idea - part of the reasoning for specifying
> the IDs is to cater for those not aligned with the ID guidelines in the
> spec, so we can't assume their choice of ID value gives us any useful
> information as to how they may be used.

Kind of pointless to encode information into the IDs if you cannot rely
on that...

Rob