[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <20200103230551.GB5562@oc0525413822.ibm.com>
Date: Fri, 3 Jan 2020 15:05:51 -0800
From: Ram Pai <linuxram@...ibm.com>
To: Pratik Rajesh Sampat <psampat@...ux.ibm.com>
Cc: linux-kernel@...r.kernel.org, linuxppc-dev@...abs.org,
mpe@...erman.id.au, svaidy@...ux.ibm.com, ego@...ux.vnet.ibm.com,
pratik.sampat@...ibm.com
Subject: Re: [RFC 0/3] Integrate Support for self-save and determine
On Wed, Dec 04, 2019 at 03:02:52PM +0530, Pratik Rajesh Sampat wrote:
> Currently the stop-api supports a mechanism called as self-restore
> which allows us to restore the values of certain SPRs on wakeup from a
> deep-stop state to a desired value. To use this, the Kernel makes an
> OPAL call passing the PIR of the CPU, the SPR number and the value to
> which the SPR should be restored when that CPU wakes up from a deep
> stop state.
>
> Recently, a new feature, named self-save has been enabled in the
> stop-api, which is an alternative mechanism to do the same, except
> that self-save will save the current content of the SPR before
> entering a deep stop state and also restore the content back on
> waking up from a deep stop state.
>
> This patch series aims at introducing and leveraging the self-save feature in
> the kernel.
>
> Now, as the kernel has a choice to prefer one mode over the other and
> there can be registers in both the save/restore SPR list which are sent
> from the device tree, a new interface has been defined for the seamless
> handing of the modes for each SPR.
>
> A list of preferred SPRs are maintained in the kernel which contains two
> properties:
> 1. supported_mode: Helps in identifying if it strictly supports self
> save or restore or both.
Will be good to capture the information that, 'supported_mode' gets
initialized using the information from the device tree.
> 2. preferred_mode: Calls out what mode is preferred for each SPR. It
> could be strictly self save or restore, or it can also
> determine the preference of mode over the other if both
> are present by encapsulating the other in bitmask from
> LSB to MSB.
and 'preferred_mode' is statically initialized.
> Below is a table to show the Scenario::Consequence when the self save and
> self restore modes are available or disabled in different combinations as
> perceived from the device tree thus giving complete backwards compatibly
> regardless of an older firmware running a newer kernel or vise-versa.
>
> SR = Self restore; SS = Self save
>
> .-----------------------------------.----------------------------------------.
> | Scenario | Consequence |
> :-----------------------------------+----------------------------------------:
> | Legacy Firmware. No SS or SR node | Self restore is called for all |
> | | supported SPRs |
> :-----------------------------------+----------------------------------------:
> | SR: !active SS: !active | Deep stop states disabled |
> :-----------------------------------+----------------------------------------:
> | SR: active SS: !active | Self restore is called for all |
> | | supported SPRs |
> :-----------------------------------+----------------------------------------:
> | SR: active SS: active | Goes through the preferences for each |
> | | SPR and executes of the modes |
> | | accordingly. Currently, Self restore is|
> | | called for all the SPRs except PSSCR |
> | | which is self saved |
> :-----------------------------------+----------------------------------------:
> | SR: active(only HID0) SS: active | Self save called for all supported |
> | | registers expect HID0 (as HID0 cannot |
> | | be self saved currently) |
Not clear, how this will be conveyed to the hypervisor? Through the
device tree or through some other means?
> :-----------------------------------+----------------------------------------:
> | SR: !active SS: active | currently will disable deep states as |
> | | HID0 is needed to be self restored and |
> | | cannot be self saved |
> '-----------------------------------'----------------------------------------'
>
> Pratik Rajesh Sampat (3):
> powerpc/powernv: Interface to define support and preference for a SPR
> powerpc/powernv: Introduce Self save support
> powerpc/powernv: Parse device tree, population of SPR support
>
> arch/powerpc/include/asm/opal-api.h | 3 +-
> arch/powerpc/include/asm/opal.h | 1 +
> arch/powerpc/platforms/powernv/idle.c | 431 ++++++++++++++++++---
> arch/powerpc/platforms/powernv/opal-call.c | 1 +
> 4 files changed, 379 insertions(+), 57 deletions(-)
>
> --
> 2.21.0
--
Ram Pai
Powered by blists - more mailing lists