| Message ID | 20220122035421.4086618-1-f.fainelli@gmail.com (mailing list archive) |
|---|---|
| Headers | show |
| Series | Broadcom STB PM PSCI extensions | expand |
On 1/21/2022 7:54 PM, Florian Fainelli wrote: > Hi all, > > This patch series contains the Broadcom STB PSCI extensions which adds > some additional functions on top of the existing standard PSCI interface > which is the reason for having the driver implement a custom > suspend_ops. > > These platforms have traditionally supported a mode that is akin to > ACPI's S2 with the CPU in WFI and all of the chip being clock gated > which is entered with "echo standby > /sys/power/state". Additional a > true suspend to DRAM as defined in ACPI by S3 is implemented with "echo > mem > /sys/power/state". > > These platforms also may have an external Broadcom PMIC chip which can > cause the SoC to be powercycled assuming that we communicate that intent > via a vendor specific PSCI SYSTEM_RESET2. > > Since it is desirable to get any new functionality added to the kernel > to be loadable as a module as part of shipping said products in a Google > Kernel Image (GKI) environment, we need to export a couple of symbols from > drivers/firmware/psci/psci.c. > > Thanks for your feedback. I will be sending a v2 addressing the kbuild robot failures reported but would prefer to get some feedback first so it can be addressed simultaneously. Thanks! > > Florian Fainelli (4): > firmware: psci: Export a couple of suspend symbols > soc: bcm: brcmstb: Make legacy PM code depend on !ARM_PSCI_FW > soc: bcm: brcmstb: Added support for PSCI system suspend operations > Documentation: ABI: Document Broadcom STB PSCI firmware files > > .../ABI/testing/sysfs-firmware-brcmstb | 16 + > drivers/firmware/psci/psci.c | 9 +- > drivers/soc/bcm/brcmstb/Kconfig | 4 +- > drivers/soc/bcm/brcmstb/pm/Makefile | 3 + > drivers/soc/bcm/brcmstb/pm/pm-psci.c | 315 ++++++++++++++++++ > include/linux/psci.h | 2 + > include/linux/soc/brcmstb/brcmstb-smccc.h | 84 +++++ > 7 files changed, 430 insertions(+), 3 deletions(-) > create mode 100644 Documentation/ABI/testing/sysfs-firmware-brcmstb > create mode 100644 drivers/soc/bcm/brcmstb/pm/pm-psci.c > create mode 100644 include/linux/soc/brcmstb/brcmstb-smccc.h >
On Fri, Jan 21, 2022 at 07:54:17PM -0800, Florian Fainelli wrote: > Hi all, Hi Florian, > This patch series contains the Broadcom STB PSCI extensions which adds > some additional functions on top of the existing standard PSCI interface > which is the reason for having the driver implement a custom > suspend_ops. I *really* don't like the idea of having non-standard PSCI extensions, because it somewhat defeats the point of PSCI being a standard, and opens the door for the zoo of mechanisms we had on 32-bit. I think this needs a fair amount more explanation and justification. > These platforms have traditionally supported a mode that is akin to > ACPI's S2 with the CPU in WFI and all of the chip being clock gated > which is entered with "echo standby > /sys/power/state". Additional a > true suspend to DRAM as defined in ACPI by S3 is implemented with "echo > mem > /sys/power/state". Why isn't a combination of CPU_SUSPEND and SYSTEM_SUSPEND sufficient here? What specifically *can't* you do with standard PSCI calls? > These platforms also may have an external Broadcom PMIC chip which can > cause the SoC to be powercycled assuming that we communicate that intent > via a vendor specific PSCI SYSTEM_RESET2. > > Since it is desirable to get any new functionality added to the kernel > to be loadable as a module as part of shipping said products in a Google > Kernel Image (GKI) environment, we need to export a couple of symbols from > drivers/firmware/psci/psci.c. I really don't want to export the guts of psci.c. Thanks, Mark. > Thanks for your feedback. > > Florian Fainelli (4): > firmware: psci: Export a couple of suspend symbols > soc: bcm: brcmstb: Make legacy PM code depend on !ARM_PSCI_FW > soc: bcm: brcmstb: Added support for PSCI system suspend operations > Documentation: ABI: Document Broadcom STB PSCI firmware files > > .../ABI/testing/sysfs-firmware-brcmstb | 16 + > drivers/firmware/psci/psci.c | 9 +- > drivers/soc/bcm/brcmstb/Kconfig | 4 +- > drivers/soc/bcm/brcmstb/pm/Makefile | 3 + > drivers/soc/bcm/brcmstb/pm/pm-psci.c | 315 ++++++++++++++++++ > include/linux/psci.h | 2 + > include/linux/soc/brcmstb/brcmstb-smccc.h | 84 +++++ > 7 files changed, 430 insertions(+), 3 deletions(-) > create mode 100644 Documentation/ABI/testing/sysfs-firmware-brcmstb > create mode 100644 drivers/soc/bcm/brcmstb/pm/pm-psci.c > create mode 100644 include/linux/soc/brcmstb/brcmstb-smccc.h > > -- > 2.25.1 >
On Fri, Jan 21, 2022 at 07:54:17PM -0800, Florian Fainelli wrote: > Hi all, > > This patch series contains the Broadcom STB PSCI extensions which adds > some additional functions on top of the existing standard PSCI interface > which is the reason for having the driver implement a custom > suspend_ops. > > These platforms have traditionally supported a mode that is akin to > ACPI's S2 with the CPU in WFI and all of the chip being clock gated > which is entered with "echo standby > /sys/power/state". Additional a > true suspend to DRAM as defined in ACPI by S3 is implemented with "echo > mem > /sys/power/state". How different is the above "standby" state compare to the standard "idle" (a.k.a suspend-to-idle which is different from system-to-ram/S3) ? Suspend to idle takes all the CPUs to lowest possible power state instead of cpu-hotplug in S2R. Also I assume some userspace has to identify when to enter "standby" vs "mem" right ? I am trying to see how addition of "idle" changes that(if it does). Sorry for too many questions.
On 2/3/2022 3:14 AM, Sudeep Holla wrote: > On Fri, Jan 21, 2022 at 07:54:17PM -0800, Florian Fainelli wrote: >> Hi all, >> >> This patch series contains the Broadcom STB PSCI extensions which adds >> some additional functions on top of the existing standard PSCI interface >> which is the reason for having the driver implement a custom >> suspend_ops. >> >> These platforms have traditionally supported a mode that is akin to >> ACPI's S2 with the CPU in WFI and all of the chip being clock gated >> which is entered with "echo standby > /sys/power/state". Additional a >> true suspend to DRAM as defined in ACPI by S3 is implemented with "echo >> mem > /sys/power/state". > > How different is the above "standby" state compare to the standard "idle" > (a.k.a suspend-to-idle which is different from system-to-ram/S3) ? There are a few differences: - s2idle does not power gate the secondary CPUs - s2idle requires the use of in-band interrupts for wake-up The reasons for implementing "standby" are largely two fold: - we need to achieve decent power savings (typically below 0.5W for the whole system while allowing Wake-on-WLAN, GPIO, RTC, infrared, etc.) - we have a security subsystem that requires the CPUs to be either power gated or idle in order the hardware state machine that lets the system enter such a state and allows the out of band interrupts from being wake-up sources > Suspend to idle takes all the CPUs to lowest possible power state instead > of cpu-hotplug in S2R. Also I assume some userspace has to identify when > to enter "standby" vs "mem" right ? I am trying to see how addition of > "idle" changes that(if it does). Sorry for too many questions. > Right that user-space in our case is either custom (like RDK, or completely custom), or is Android. For Android it looks like we are carrying a patch that makes "mem" de-generate into "standby" but this is largely because we had historically problems with "mem" that are being addressed (completely orthogonal). I did not consider it as a viable option at the time, but if we were to implement "standby" in drivers/firmware/psci/psci.c would that be somewhat acceptable?
Hello Mark, On 2/3/2022 2:47 AM, Mark Rutland wrote: > On Fri, Jan 21, 2022 at 07:54:17PM -0800, Florian Fainelli wrote: >> Hi all, > > Hi Florian, > >> This patch series contains the Broadcom STB PSCI extensions which adds >> some additional functions on top of the existing standard PSCI interface >> which is the reason for having the driver implement a custom >> suspend_ops. > > I *really* don't like the idea of having non-standard PSCI extensions, because > it somewhat defeats the point of PSCI being a standard, and opens the door for > the zoo of mechanisms we had on 32-bit. > > I think this needs a fair amount more explanation and justification. > >> These platforms have traditionally supported a mode that is akin to >> ACPI's S2 with the CPU in WFI and all of the chip being clock gated >> which is entered with "echo standby > /sys/power/state". Additional a >> true suspend to DRAM as defined in ACPI by S3 is implemented with "echo >> mem > /sys/power/state". > > Why isn't a combination of CPU_SUSPEND and SYSTEM_SUSPEND sufficient here? This is exactly what we are using, just the use of CPU_SUSPEND is not done via the CPU IDLE framework because our platforms did not wire up the ARM GIC power controller interrupt signals back to the power management controller of the system, but via registering a "standby" state into suspend_ops instead. > > What specifically *can't* you do with standard PSCI calls? Since you looked at the patches now, nothing at all, everything we do (with the exception of the funky SIP calls which are not strictly mandatory for system suspend operations) is done by using standard PSCI calls and leveraging the existing vendor space when needed (as with SYSTEM_RESET2 for instance). > >> These platforms also may have an external Broadcom PMIC chip which can >> cause the SoC to be powercycled assuming that we communicate that intent >> via a vendor specific PSCI SYSTEM_RESET2. >> >> Since it is desirable to get any new functionality added to the kernel >> to be loadable as a module as part of shipping said products in a Google >> Kernel Image (GKI) environment, we need to export a couple of symbols from >> drivers/firmware/psci/psci.c. > > I really don't want to export the guts of psci.c. I can appreciate that, and really the sticking point that required me to export the couple of symbols needed was because the alternatives would be to: - to not make this code modular in the first place but that won't fly in the Google Kernel Image grand scheme of things where *everything* that is not necessary for boot must be a loadable module - not support the "standby" mode which is not really an option since we rely on it to achieve our power targets - export cpu_suspend from arch/*/kernel/suspend.c which is probably going to be a no-go plus duplicate the entire set of PSCI function calls to re-implement the psci_system_suspend_enter() functions Thanks for taking a look!
Correction: it is known as "freeze" rather than "idle" in terms of values as per /sys/power/state. Sorry for referring it as "idle" and creating any confusion. On Thu, Feb 03, 2022 at 09:36:28AM -0800, Florian Fainelli wrote: > > > On 2/3/2022 3:14 AM, Sudeep Holla wrote: > > On Fri, Jan 21, 2022 at 07:54:17PM -0800, Florian Fainelli wrote: > > > Hi all, > > > > > > This patch series contains the Broadcom STB PSCI extensions which adds > > > some additional functions on top of the existing standard PSCI interface > > > which is the reason for having the driver implement a custom > > > suspend_ops. > > > > > > These platforms have traditionally supported a mode that is akin to > > > ACPI's S2 with the CPU in WFI and all of the chip being clock gated > > > which is entered with "echo standby > /sys/power/state". Additional a > > > true suspend to DRAM as defined in ACPI by S3 is implemented with "echo > > > mem > /sys/power/state". > > > > How different is the above "standby" state compare to the standard "idle" > > (a.k.a suspend-to-idle which is different from system-to-ram/S3) ? > > There are a few differences: > > - s2idle does not power gate the secondary CPUs > Not sure what you mean by that ? S2I takes CPUs to deepest idle state. If you want shallower states, one possible option is the disable deeper states from the userspace. > - s2idle requires the use of in-band interrupts for wake-up > I am not sure if that is true. S2I behaves very similar to S2R except it has low wake latency as all secondaries CPUs are not hotplugged out. > The reasons for implementing "standby" are largely two fold: > > - we need to achieve decent power savings (typically below 0.5W for the > whole system while allowing Wake-on-WLAN, GPIO, RTC, infrared, etc.) > I fail to understand how that is a problem from S2I. It is probably worth checking if there are any unnecessary IRQF_NO_SUSPEND users. Check section IRQF_NO_SUSPEND and enable_irq_wake() in [1]. I don't see any issues other wise in terms of unnecessary/spurious wakeup by in-band(to be precise no-wake up) interrupts. > - we have a security subsystem that requires the CPUs to be either power > gated or idle in order the hardware state machine that lets the system enter > such a state and allows the out of band interrupts from being wake-up > sources > It should work unless I have completely misunderstood how S2I works. > > Suspend to idle takes all the CPUs to lowest possible power state instead > > of cpu-hotplug in S2R. Also I assume some userspace has to identify when > > to enter "standby" vs "mem" right ? I am trying to see how addition of > > "idle" changes that(if it does). Sorry for too many questions. > > > > Right that user-space in our case is either custom (like RDK, or completely > custom), or is Android. For Android it looks like we are carrying a patch > that makes "mem" de-generate into "standby" but this is largely because we > had historically problems with "mem" that are being addressed (completely > orthogonal). > Thanks for the info. > I did not consider it as a viable option at the time, but if we were to > implement "standby" in drivers/firmware/psci/psci.c would that be somewhat > acceptable? > We have been pointing anyone needing standby so far to S2I and so far no one has shouted that it doesn't suffice. Let me know what is missing.
On 2/3/2022 10:52 AM, Sudeep Holla wrote: > Correction: it is known as "freeze" rather than "idle" in terms of values > as per /sys/power/state. Sorry for referring it as "idle" and creating any > confusion. > > On Thu, Feb 03, 2022 at 09:36:28AM -0800, Florian Fainelli wrote: >> >> >> On 2/3/2022 3:14 AM, Sudeep Holla wrote: >>> On Fri, Jan 21, 2022 at 07:54:17PM -0800, Florian Fainelli wrote: >>>> Hi all, >>>> >>>> This patch series contains the Broadcom STB PSCI extensions which adds >>>> some additional functions on top of the existing standard PSCI interface >>>> which is the reason for having the driver implement a custom >>>> suspend_ops. >>>> >>>> These platforms have traditionally supported a mode that is akin to >>>> ACPI's S2 with the CPU in WFI and all of the chip being clock gated >>>> which is entered with "echo standby > /sys/power/state". Additional a >>>> true suspend to DRAM as defined in ACPI by S3 is implemented with "echo >>>> mem > /sys/power/state". >>> >>> How different is the above "standby" state compare to the standard "idle" >>> (a.k.a suspend-to-idle which is different from system-to-ram/S3) ? >> >> There are a few differences: >> >> - s2idle does not power gate the secondary CPUs >> > > Not sure what you mean by that ? S2I takes CPUs to deepest idle state. > If you want shallower states, one possible option is the disable deeper > states from the userspace. What I mean is that we do not get to call PSCI CPU_OFF here so the CPUs are idle, but not power gated. Those CPUs do not have any other idle state other than WFI because the HW designers sort of forgot or rather did not know that wiring up the ARM GIC power controller back to the power gating logic of the CPU was a good idea. > >> - s2idle requires the use of in-band interrupts for wake-up >> > > I am not sure if that is true. S2I behaves very similar to S2R except it > has low wake latency as all secondaries CPUs are not hotplugged out. OK, the fact that secondary CPUs are not hot-plugged could be remedied by doing this ahead of entering s2idle by user-space so this is not a valid argument from me anymore. > >> The reasons for implementing "standby" are largely two fold: >> >> - we need to achieve decent power savings (typically below 0.5W for the >> whole system while allowing Wake-on-WLAN, GPIO, RTC, infrared, etc.) >> > > I fail to understand how that is a problem from S2I. It is probably worth > checking if there are any unnecessary IRQF_NO_SUSPEND users. Check section > IRQF_NO_SUSPEND and enable_irq_wake() in [1]. I don't see any issues other > wise in terms of unnecessary/spurious wakeup by in-band(to be precise > no-wake up) interrupts. I don't think your hyperlink referenced by [1] was provided, but my quick testing with: echo s2idle > /sys/power/mem_sleep echo mem > /sys/power/state appears to work to some extent when I use peripherals that can generate in-band interrupts. It looks like we have s2idle_ops that allows a platform to override some of the operations before/after entering s2idle, however the actual s2idle idle loop is still within the kernel, so we will not call into the ARM Trusted Firmware and engage the power management state machine. This means that there will not be any of the clock gating that only the hardware state machine is capable of performing, the DRAM controller as a result will not enter self refresh power down, and in addition the side band wake-up interrupts will not be activate because the interrupt controller that aggregates them only outputs to the ARM GIC when the state machine has been engaged. Essentially, what we need for our systems is a controlled system entry with semantics similar if not identical to that of S2R but with a shallower state that does not cut the power to 90% of the SoC (unlike S2R) such that we have a quicker suspend and resume latency. Years ago when we only had MIPS-based and 32-bit ARM SoCs, we did come up with using "standby" (see drivers/soc/bcm/brcmstb/pm/*) and we naturally mapped that when we switched over to ARMv8 capable devices. > >> - we have a security subsystem that requires the CPUs to be either power >> gated or idle in order the hardware state machine that lets the system enter >> such a state and allows the out of band interrupts from being wake-up >> sources >> > > It should work unless I have completely misunderstood how S2I works. > >>> Suspend to idle takes all the CPUs to lowest possible power state instead >>> of cpu-hotplug in S2R. Also I assume some userspace has to identify when >>> to enter "standby" vs "mem" right ? I am trying to see how addition of >>> "idle" changes that(if it does). Sorry for too many questions. >>> >> >> Right that user-space in our case is either custom (like RDK, or completely >> custom), or is Android. For Android it looks like we are carrying a patch >> that makes "mem" de-generate into "standby" but this is largely because we >> had historically problems with "mem" that are being addressed (completely >> orthogonal). >> > > Thanks for the info. > >> I did not consider it as a viable option at the time, but if we were to >> implement "standby" in drivers/firmware/psci/psci.c would that be somewhat >> acceptable? >> > > We have been pointing anyone needing standby so far to S2I and so far no one > has shouted that it doesn't suffice. Let me know what is missing. >
On Thu, Feb 03, 2022 at 11:33:26AM -0800, Florian Fainelli wrote: > > > On 2/3/2022 10:52 AM, Sudeep Holla wrote: > > Correction: it is known as "freeze" rather than "idle" in terms of values > > as per /sys/power/state. Sorry for referring it as "idle" and creating any > > confusion. > > > > On Thu, Feb 03, 2022 at 09:36:28AM -0800, Florian Fainelli wrote: > > > > > > > > > On 2/3/2022 3:14 AM, Sudeep Holla wrote: > > > > On Fri, Jan 21, 2022 at 07:54:17PM -0800, Florian Fainelli wrote: > > > > > Hi all, > > > > > > > > > > This patch series contains the Broadcom STB PSCI extensions which adds > > > > > some additional functions on top of the existing standard PSCI interface > > > > > which is the reason for having the driver implement a custom > > > > > suspend_ops. > > > > > > > > > > These platforms have traditionally supported a mode that is akin to > > > > > ACPI's S2 with the CPU in WFI and all of the chip being clock gated > > > > > which is entered with "echo standby > /sys/power/state". Additional a > > > > > true suspend to DRAM as defined in ACPI by S3 is implemented with "echo > > > > > mem > /sys/power/state". > > > > > > > > How different is the above "standby" state compare to the standard "idle" > > > > (a.k.a suspend-to-idle which is different from system-to-ram/S3) ? > > > > > > There are a few differences: > > > > > > - s2idle does not power gate the secondary CPUs > > > > > > > Not sure what you mean by that ? S2I takes CPUs to deepest idle state. > > If you want shallower states, one possible option is the disable deeper > > states from the userspace. > > What I mean is that we do not get to call PSCI CPU_OFF here so the CPUs are > idle, but not power gated. Those CPUs do not have any other idle state other > than WFI because the HW designers sort of forgot or rather did not know that > wiring up the ARM GIC power controller back to the power gating logic of the > CPU was a good idea. > Nice
On 2/7/22 8:27 AM, Sudeep Holla wrote: > On Thu, Feb 03, 2022 at 11:33:26AM -0800, Florian Fainelli wrote: >> >> >> On 2/3/2022 10:52 AM, Sudeep Holla wrote: >>> Correction: it is known as "freeze" rather than "idle" in terms of values >>> as per /sys/power/state. Sorry for referring it as "idle" and creating any >>> confusion. >>> >>> On Thu, Feb 03, 2022 at 09:36:28AM -0800, Florian Fainelli wrote: >>>> >>>> >>>> On 2/3/2022 3:14 AM, Sudeep Holla wrote: >>>>> On Fri, Jan 21, 2022 at 07:54:17PM -0800, Florian Fainelli wrote: >>>>>> Hi all, >>>>>> >>>>>> This patch series contains the Broadcom STB PSCI extensions which adds >>>>>> some additional functions on top of the existing standard PSCI interface >>>>>> which is the reason for having the driver implement a custom >>>>>> suspend_ops. >>>>>> >>>>>> These platforms have traditionally supported a mode that is akin to >>>>>> ACPI's S2 with the CPU in WFI and all of the chip being clock gated >>>>>> which is entered with "echo standby > /sys/power/state". Additional a >>>>>> true suspend to DRAM as defined in ACPI by S3 is implemented with "echo >>>>>> mem > /sys/power/state". >>>>> >>>>> How different is the above "standby" state compare to the standard "idle" >>>>> (a.k.a suspend-to-idle which is different from system-to-ram/S3) ? >>>> >>>> There are a few differences: >>>> >>>> - s2idle does not power gate the secondary CPUs >>>> >>> >>> Not sure what you mean by that ? S2I takes CPUs to deepest idle state. >>> If you want shallower states, one possible option is the disable deeper >>> states from the userspace. >> >> What I mean is that we do not get to call PSCI CPU_OFF here so the CPUs are >> idle, but not power gated. Those CPUs do not have any other idle state other >> than WFI because the HW designers sort of forgot or rather did not know that >> wiring up the ARM GIC power controller back to the power gating logic of the >> CPU was a good idea. >> > > Nice