From mboxrd@z Thu Jan 1 00:00:00 1970 From: Suravee Suthikulanit Subject: Re: [PATCH 3/4] xen/arm: Add PSCI system_off and system_reset support Date: Wed, 1 Oct 2014 12:58:27 -0500 Message-ID: <542C40C3.4040604@amd.com> References: <1412150877-4090-1-git-send-email-suravee.suthikulpanit@amd.com> <1412150877-4090-4-git-send-email-suravee.suthikulpanit@amd.com> <1412159166.4861.5.camel@citrix.com> <542C0C7F.7040306@amd.com> <1412174800.4861.40.camel@citrix.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; Format="flowed" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <1412174800.4861.40.camel@citrix.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Ian Campbell Cc: julien.grall@linaro.org, xen-devel@lists.xen.org, Stefano Stabellini List-Id: xen-devel@lists.xenproject.org On 10/1/2014 9:46 AM, Ian Campbell wrote: > On Wed, 2014-10-01 at 09:15 -0500, Suravee Suthikulpanit wrote: >> >> On 10/01/2014 05:26 AM, Ian Campbell wrote: >>> On Wed, 2014-10-01 at 11:07 +0100, Stefano Stabellini wrote: >>>>> diff --git a/xen/arch/arm/psci.c b/xen/arch/arm/psci.c >>>>> index b6360d5..b0d94a8 100644 >>>>> --- a/xen/arch/arm/psci.c >>>>> +++ b/xen/arch/arm/psci.c >>>>> @@ -58,6 +58,16 @@ int call_psci_cpu_on(int cpu) >>>>> cpu_logical_map(cpu), __pa(init_secondary), 0); >>>>> } >>>>> >>>>> +void call_psci_system_off(void) >>>>> +{ >>>>> + __invoke_psci_fn_smc(PSCI_0_2_FN_SYSTEM_OFF, 0, 0, 0); >>>>> +} >>>>> + >>>>> +void call_psci_system_reset(void) >>>>> +{ >>>>> + __invoke_psci_fn_smc(PSCI_0_2_FN_SYSTEM_RESET, 0, 0, 0); >>>>> +} >>>> >>>> This assumes PSCI 0.2 but actually the cpu_on function is still reading >>>> the id from device tree. >>>> Could you please change that too for uniformity? >> >> Sure, I can add that. >> >>> >>> There's actually quite a bit more required, detecting the DT compat >>> string for v0.2 and following the updated bindings for that case. >>> >>> Having done that we need to use the 0.2 function ids for the existing >>> calls too. And these new calls need to check that 0.2 is present and >>> fail on 0.1. >>> >>> Ian. >>> >> >> So, it seems that minimally, we would need support for all PSCI-0.2 >> functions except MIGRATION. Also, once the system uses "arm,psci-0.2", >> the power_off and reset code path should hook into the PSCI interface by >> default.Does this sound right? > > Yes. > >> However, for Seattle, I would still need to provide the >> "platform.[reset|poweroff] ops since it's not full PSCI-0.2 (yet). > > OOI is it also PSCI-0.1 compatible? > > Implementing the full PSCI 0.2 support is the thing I'm more worried > about wrt the release, since it is likely to be the large bit of new > work and it might not meet with Release Manager approval. > > Ian. > No, the only functions the firmware handles are just the system_off / system_reset (work in progress). If you concern about changes to the PSCI subsystem, I could probably just making SMC call directly the platforms/seattle.c, until we have full PSCI-0.2 support ready in the arch/arm/psci.c Suravee