FROMLIST: cpuidle: Deny idle entry when CPU already have IPI pending#883
Open
smankad-oss wants to merge 10 commits intoqualcomm-linux:tech/pm/powerfrom
Open
FROMLIST: cpuidle: Deny idle entry when CPU already have IPI pending#883smankad-oss wants to merge 10 commits intoqualcomm-linux:tech/pm/powerfrom
smankad-oss wants to merge 10 commits intoqualcomm-linux:tech/pm/powerfrom
Conversation
Devres APIs are intended for use in drivers, and they should be avoided in shared subsystem code which is being used by multiple drivers. Avoid using devres based allocations in the reboot-mode subsystem and manually free the resources. Replace devm_kzalloc with kzalloc and handle memory cleanup explicitly. Fixes: 4fcd504 ("power: reset: add reboot mode driver") Signed-off-by: Shivendra Pratap <shivendra.pratap@oss.qualcomm.com> Link: https://lore.kernel.org/r/20251109-arm-psci-system_reset2-vendor-reboots-v17-1-46e085bca4cc@oss.qualcomm.com
The reboot-mode driver does not have a strict requirement for device-based registration. It primarily uses the device's of_node to read mode-<cmd> properties. Remove the dependency on struct device and introduce support for firmware node (fwnode) based registration. This enables drivers that are not associated with a struct device to leverage the reboot-mode framework. Signed-off-by: Shivendra Pratap <shivendra.pratap@oss.qualcomm.com> Link: https://lore.kernel.org/r/20251109-arm-psci-system_reset2-vendor-reboots-v17-2-46e085bca4cc@oss.qualcomm.com
Current reboot-mode supports a single 32-bit argument for any supported mode. Some reboot-mode based drivers may require passing two independent 32-bit arguments during a reboot sequence, for uses-cases, where a mode requires an additional argument. Such drivers may not be able to use the reboot-mode driver. For example, ARM PSCI vendor-specific resets, need two arguments for its operation – reset_type and cookie, to complete the reset operation. If a driver wants to implement this firmware-based reset, it cannot use reboot-mode framework. Introduce 64-bit magic values in reboot-mode driver to accommodate dual 32-bit arguments when specified via device tree. In cases, where no second argument is passed from device tree, keep the upper 32-bit of magic un-changed(0) to maintain backward compatibility. Update the current drivers using reboot-mode for a 64-bit magic value. Reviewed-by: Umang Chheda <umang.chheda@oss.qualcomm.com> Reviewed-by: Nirmesh Kumar Singh <nirmesh.singh@oss.qualcomm.com> Signed-off-by: Shivendra Pratap <shivendra.pratap@oss.qualcomm.com> Link: https://lore.kernel.org/r/20251109-arm-psci-system_reset2-vendor-reboots-v17-3-46e085bca4cc@oss.qualcomm.com
Add ABI documentation for /sys/class/reboot-mode/*/reboot_modes, a read-only sysfs attribute exposing the list of supported reboot-mode arguments. This file is created by reboot-mode framework and provides a user-readable interface to query available reboot-mode arguments. Reviewed-by: Sebastian Reichel <sebastian.reichel@collabora.com> Signed-off-by: Shivendra Pratap <shivendra.pratap@oss.qualcomm.com> Link: https://lore.kernel.org/r/20251109-arm-psci-system_reset2-vendor-reboots-v17-4-46e085bca4cc@oss.qualcomm.com
Currently, there is no standardized mechanism for userspace to discover which reboot-modes are supported on a given platform. This limitation forces tools and scripts to rely on hardcoded assumptions about the supported reboot-modes. Create a class 'reboot-mode' and a device under it to expose a sysfs interface to show the available reboot mode arguments to userspace. Use the driver_name field of the struct reboot_mode_driver to create the device. For device-based drivers, configure the device driver name as driver_name. This results in the creation of: /sys/class/reboot-mode/<driver>/reboot_modes This read-only sysfs file will exposes the list of supported reboot modes arguments provided by the driver, enabling userspace to query the list of arguments. Signed-off-by: Shivendra Pratap <shivendra.pratap@oss.qualcomm.com> Link: https://lore.kernel.org/r/20251109-arm-psci-system_reset2-vendor-reboots-v17-5-46e085bca4cc@oss.qualcomm.com
SoC vendors have different types of resets which are controlled through various hardware registers. For instance, Qualcomm SoC may have a requirement that reboot with “bootloader” command should reboot the device to bootloader flashing mode and reboot with “edl” should reboot the device into Emergency flashing mode. Setting up such reboots on Qualcomm devices can be inconsistent across SoC platforms and may require setting different HW registers, where some of these registers may not be accessible to HLOS. These knobs evolve over product generations and require more drivers. PSCI spec defines, SYSTEM_RESET2, vendor-specific reset which can help align this requirement. Add support for PSCI SYSTEM_RESET2, vendor-specific resets and align the implementation to allow user-space initiated reboots to trigger these resets. Implement the PSCI vendor-specific resets by registering to the reboot-mode framework. As psci init is done at early kernel init, reboot-mode registration cannot be done at the time of psci init. This is because reboot-mode creates a “reboot-mode” class for exposing sysfs, which can fail at early kernel init. To overcome this, introduce a late_initcall to register PSCI vendor-specific resets as reboot modes. Implement a reboot-mode write function that sets reset_type and cookie values during the reboot notifier callback. Introduce a firmware-based call for SYSTEM_RESET2 vendor-specific reset in the psci_sys_reset path, using reset_type and cookie if supported by secure firmware. Register a panic notifier and clear vendor_reset valid status during panic. This is needed for any kernel panic that occurs post reboot_notifiers. By using the above implementation, userspace will be able to issue such resets using the reboot() system call with the "*arg" parameter as a string based command. The commands can be defined in PSCI device tree node under “reboot-mode” and are based on the reboot-mode based commands. Reviewed-by: Umang Chheda <umang.chheda@oss.qualcomm.com> Reviewed-by: Kathiravan Thirumoorthy <kathiravan.thirumoorthy@oss.qualcomm.com> Reviewed-by: Nirmesh Kumar Singh <nirmesh.singh@oss.qualcomm.com> Signed-off-by: Shivendra Pratap <shivendra.pratap@oss.qualcomm.com> Link: https://lore.kernel.org/r/20251109-arm-psci-system_reset2-vendor-reboots-v17-7-46e085bca4cc@oss.qualcomm.com
…nd QMP Document PDC reg to configure pass through or secondary controller mode for GPIO IRQs. Document QMP handle for action concerning global resources. Link: https://lore.kernel.org/r/20260312-hamoa_pdc-v1-2-760c8593ce50@oss.qualcomm.com Signed-off-by: Maulik Shah <maulik.shah@oss.qualcomm.com> Signed-off-by: Sneh Mankad <sneh.mankad@oss.qualcomm.com>
There are two modes PDC irqchip supports pass through mode and secondary controller mode. All PDC irqchip supports pass through mode in which both Direct SPIs and GPIO IRQs (as SPIs) are sent to GIC without latching at PDC. Newer PDCs (v3.0 onwards) also support additional secondary controller mode where PDC latches GPIO IRQs and sends to GIC as level type IRQ. Direct SPIs still works same as pass through mode without latching at PDC even in secondary controller mode. All the SoCs so far default uses pass through mode with the exception of x1e. x1e PDC may be set to secondary controller mode for builds on CRD boards whereas it may be set to pass through mode for IoT-EVK. There is no way to read which current mode it is set to and make PDC work in respective mode as the read access is not opened up for non secure world. There is though write access opened up via SCM write API to set the mode. Configure PDC mode to pass through mode for all x1e based boards via SCM write. Link: https://lore.kernel.org/r/20260312-hamoa_pdc-v1-3-760c8593ce50@oss.qualcomm.com Co-developed-by: Sneh Mankad <sneh.mankad@oss.qualcomm.com> Signed-off-by: Sneh Mankad <sneh.mankad@oss.qualcomm.com> Signed-off-by: Maulik Shah <maulik.shah@oss.qualcomm.com>
…100 PDC Purwa shares the Hamoa (X1E80100) PDC device, but the hardware register bug addressed in commit e9a48ea ("irqchip/qcom-pdc: Workaround hardware register bug on X1E80100") is already fixed in Purwa silicon. Hamoa compatible forces the software workaround. Add PDC compatible for purwa as "qcom,x1p42100-pdc" to remove the workaround from Purwa. Fixes: f08edb5 ("arm64: dts: qcom: Add X1P42100 SoC and CRD") Link: https://lore.kernel.org/r/20251231-purwa_pdc-v1-1-2b4979dd88ad@oss.qualcomm.com Signed-off-by: Maulik Shah <maulik.shah@oss.qualcomm.com> Signed-off-by: Sneh Mankad <sneh.mankad@oss.qualcomm.com>
…t pending CPU can get IPI interrupt from another CPU while it is executing cpuidle_select() or about to execute same. The selection do not account for pending interrupts and may continue to enter selected idle state only to exit immediately. Example trace collected when there is cross CPU IPI. [000] 154.892148: sched_waking: comm=sugov:4 pid=491 prio=-1 target_cpu=007 [000] 154.892148: ipi_raise: target_mask=00000000,00000080 (Function call interrupts) [007] 154.892162: cpu_idle: state=2 cpu_id=7 [007] 154.892208: cpu_idle: state=4294967295 cpu_id=7 [007] 154.892211: irq_handler_entry: irq=2 name=IPI [007] 154.892211: ipi_entry: (Function call interrupts) [007] 154.892213: sched_wakeup: comm=sugov:4 pid=491 prio=-1 target_cpu=007 [007] 154.892214: ipi_exit: (Function call interrupts) This impacts performance and the above count increments. commit ccde652 ("smp: Introduce a helper function to check for pending IPIs") already introduced a helper function to check the pending IPIs and it is used in pmdomain governor to deny the cluster level idle state when there is a pending IPI on any of cluster CPUs. This however does not stop CPU to enter CPU level idle state. Make use of same at CPUidle to deny the idle entry when there is already IPI pending. With change observing glmark2 [1] off screen scores improving in the range of 25% to 30% on Qualcomm lemans-evk board which is arm64 based having two clusters each with 4 CPUs. [1] https://github.com/glmark2/glmark2 Link: https://lore.kernel.org/r/20260403-cpuidle_ipi-v2-1-b3e44b032e2c@oss.qualcomm.com Signed-off-by: Maulik Shah <maulik.shah@oss.qualcomm.com> Signed-off-by: Sneh Mankad <sneh.mankad@oss.qualcomm.com>
maulik-k-shah
force-pushed
the
tech/pm/power
branch
from
25fc1b7 to
823e2c5
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
CPU can get IPI interrupt from another CPU while it is executing cpuidle_select() or about to execute same. The selection do not account for pending interrupts and may continue to enter selected idle state only to exit immediately.
This impacts performance and the above count increments.
commit ccde652 ("smp: Introduce a helper function to check for pending IPIs") already introduced a helper function to check the pending IPIs and it is used in pmdomain governor to deny the cluster level idle state when there is a pending IPI on any of cluster CPUs.
This however does not stop CPU to enter CPU level idle state. Make use of same at CPUidle to deny the idle entry when there is already IPI pending.
With change observing glmark2 [1] off screen scores improving in the range of 25% to 30% on Qualcomm lemans-evk board which is arm64 based having two clusters each with 4 CPUs.
[1] https://github.com/glmark2/glmark2
Link: https://lore.kernel.org/r/20260403-cpuidle_ipi-v2-1-b3e44b032e2c@oss.qualcomm.com
Signed-off-by: Maulik Shah maulik.shah@oss.qualcomm.com
Signed-off-by: Sneh Mankad sneh.mankad@oss.qualcomm.com