On 2023-01-12 12:34:35 [+0100], Krzysztof Kozlowski wrote: > On 12/01/2023 12:09, Sebastian Andrzej Siewior wrote: > > On 2022-12-19 16:15:01 [+0100], Krzysztof Kozlowski wrote: > >> diff --git a/drivers/cpuidle/cpuidle-psci.c b/drivers/cpuidle/cpuidle-psci.c > >> index 57bc3e3ae391..9d971cc4b12b 100644 > >> --- a/drivers/cpuidle/cpuidle-psci.c > >> +++ b/drivers/cpuidle/cpuidle-psci.c > >> @@ -72,7 +72,7 @@ static int __psci_enter_domain_idle_state(struct cpuidle_device *dev, > >> ct_irq_enter_irqson(); > >> if (s2idle) > >> dev_pm_genpd_suspend(pd_dev); > >> - else > >> + else if (!IS_ENABLED(CONFIG_PREEMPT_RT)) > >> pm_runtime_put_sync_suspend(pd_dev); > > > > So based on the commit description you run into a sleeping lock in > > pm_runtime_put_sync_suspend() while the CPU is in an IRQ-off region. > > Why is it okay to skip it on PREEMPT_RT? > > It is okay to skip it everywhere, you just don't get a suspended CPU. > Why PREEMPT_RT is different here - having suspended CPU is a great way > to have longer or even unpredictable (as it goes to firmware which is > out of control of Linux) latencies. On X86 C1 has a latency of less than 5us and this is exposed by the firmware. C1E and everything that follows has a much higher entry/ exit latency which makes not usable. The entry/exit latency seems not to be exposed by PSCI. My understanding is that the driver is now enabled but not doing any suspending, right? If so, why isn't it completely disabled? > Best regards, > Krzysztof Sebastian
