Message ID | 20191204093255.11849-1-psampat@linux.ibm.com (mailing list archive) |
---|---|
Headers | show |
Series | Integrate Support for self-save and determine | expand |
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
Thanks for your comments Ram, >> 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. > Sure thing, I'll mention that. >> 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? > This information will be conveyed through the device tree. I'll frame a sentence that makes this more explicit. >> :-----------------------------------+----------------------------------------: >> | 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