This patch-set provides fixes for the qcom-cpufreq-hw driver regarding
LMH irqs configurations and (un)plugging CPUs.
commit ffd6cc92ab9c ("arm64: dts: qcom: sm8250: add description of dcvsh interrupts")
enables DCVS (Dynamic Clock and Voltage Scaling) for sm8250 chips
(so rb5 included). As no LMH (Limits Management Hardware) interrupts
were seen, the firmware used for testing should not be able support
them.
The patch-set was tested on a rb5 with an old firmware version:
UEFI Ver : 5.0.210817.BOOT.XF.3.2-00354-SM8250-1
Build Info : 64b Aug 17 2021 23:35:39
This patch-set should still contain relevant modifications regarding
LMH interrupts and CPU hotplug. Still, it would be good to test
it on a platform which actually uses LMH interrupts.
LMH irqs can be identified with:
cat /proc/interrupts | grep "dcvsh\-irq"
and their configuration can be seen at:
/proc/irqs/XXX/*
Pierre Gondois (4):
cpufreq: qcom-hw: Reset cancel_throttle when policy is re-enabled
cpufreq: qcom-hw: Disable LMH irq when disabling policy
cpufreq: qcom-hw: Remove deprecated irq_set_affinity_hint() call
cpufreq: Change order of online() CB and policy->cpus modification
drivers/cpufreq/cpufreq.c | 6 +++---
drivers/cpufreq/qcom-cpufreq-hw.c | 16 ++++++++++++----
2 files changed, 15 insertions(+), 7 deletions(-)
--
2.25.1
From a state where all policy->related_cpus are offline, putting one
of the policy's CPU back online re-activates the policy by:
1. Calling cpufreq_driver->online()
2. Setting the CPU in policy->cpus
qcom_cpufreq_hw_cpu_online() makes use of policy->cpus. Thus 1. and 2.
should be inverted to avoid having a policy->cpus empty. The
qcom-cpufreq-hw is the only driver affected by this.
Fixes: a1eb080a0447 ("cpufreq: qcom-hw: provide online/offline operations")
Signed-off-by: Pierre Gondois <[email protected]>
---
drivers/cpufreq/cpufreq.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/cpufreq/cpufreq.c b/drivers/cpufreq/cpufreq.c
index 2cad42774164..36043be16d8e 100644
--- a/drivers/cpufreq/cpufreq.c
+++ b/drivers/cpufreq/cpufreq.c
@@ -1350,15 +1350,15 @@ static int cpufreq_online(unsigned int cpu)
}
if (!new_policy && cpufreq_driver->online) {
+ /* Recover policy->cpus using related_cpus */
+ cpumask_copy(policy->cpus, policy->related_cpus);
+
ret = cpufreq_driver->online(policy);
if (ret) {
pr_debug("%s: %d: initialization failed\n", __func__,
__LINE__);
goto out_exit_policy;
}
-
- /* Recover policy->cpus using related_cpus */
- cpumask_copy(policy->cpus, policy->related_cpus);
} else {
cpumask_copy(policy->cpus, cpumask_of(cpu));
--
2.25.1
On 15-06-22, 16:43, Pierre Gondois wrote:
> >From a state where all policy->related_cpus are offline, putting one
> of the policy's CPU back online re-activates the policy by:
> 1. Calling cpufreq_driver->online()
> 2. Setting the CPU in policy->cpus
>
> qcom_cpufreq_hw_cpu_online() makes use of policy->cpus. Thus 1. and 2.
> should be inverted to avoid having a policy->cpus empty. The
> qcom-cpufreq-hw is the only driver affected by this.
>
> Fixes: a1eb080a0447 ("cpufreq: qcom-hw: provide online/offline operations")
> Signed-off-by: Pierre Gondois <[email protected]>
> ---
> drivers/cpufreq/cpufreq.c | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/cpufreq/cpufreq.c b/drivers/cpufreq/cpufreq.c
> index 2cad42774164..36043be16d8e 100644
> --- a/drivers/cpufreq/cpufreq.c
> +++ b/drivers/cpufreq/cpufreq.c
> @@ -1350,15 +1350,15 @@ static int cpufreq_online(unsigned int cpu)
> }
>
> if (!new_policy && cpufreq_driver->online) {
> + /* Recover policy->cpus using related_cpus */
> + cpumask_copy(policy->cpus, policy->related_cpus);
> +
> ret = cpufreq_driver->online(policy);
> if (ret) {
> pr_debug("%s: %d: initialization failed\n", __func__,
> __LINE__);
> goto out_exit_policy;
> }
> -
> - /* Recover policy->cpus using related_cpus */
> - cpumask_copy(policy->cpus, policy->related_cpus);
> } else {
> cpumask_copy(policy->cpus, cpumask_of(cpu));
Acked-by: Viresh Kumar <[email protected]>
--
viresh
On 04-07-22, 11:55, Pierre Gondois wrote:
> Hello,
> I saw that:
> https://lore.kernel.org/all/20220617064421.l4vshytmqtittzee@vireshk-i7/
>
> was applied, so this patch-set would need to be rebased. Please let me
> know if you think it requires modifications before it gets rebased,
Everything else looks fine, just rebase and resend. Thanks.
--
viresh
Hello,
I saw that:
https://lore.kernel.org/all/20220617064421.l4vshytmqtittzee@vireshk-i7/
was applied, so this patch-set would need to be rebased. Please let me
know if you think it requires modifications before it gets rebased,
Regards,
Pierre
On 6/15/22 16:43, Pierre Gondois wrote:
> This patch-set provides fixes for the qcom-cpufreq-hw driver regarding
> LMH irqs configurations and (un)plugging CPUs.
> commit ffd6cc92ab9c ("arm64: dts: qcom: sm8250: add description of dcvsh interrupts")
> enables DCVS (Dynamic Clock and Voltage Scaling) for sm8250 chips
> (so rb5 included). As no LMH (Limits Management Hardware) interrupts
> were seen, the firmware used for testing should not be able support
> them.
>
> The patch-set was tested on a rb5 with an old firmware version:
> UEFI Ver : 5.0.210817.BOOT.XF.3.2-00354-SM8250-1
> Build Info : 64b Aug 17 2021 23:35:39
>
> This patch-set should still contain relevant modifications regarding
> LMH interrupts and CPU hotplug. Still, it would be good to test
> it on a platform which actually uses LMH interrupts.
>
> LMH irqs can be identified with:
> cat /proc/interrupts | grep "dcvsh\-irq"
> and their configuration can be seen at:
> /proc/irqs/XXX/*
>
> Pierre Gondois (4):
> cpufreq: qcom-hw: Reset cancel_throttle when policy is re-enabled
> cpufreq: qcom-hw: Disable LMH irq when disabling policy
> cpufreq: qcom-hw: Remove deprecated irq_set_affinity_hint() call
> cpufreq: Change order of online() CB and policy->cpus modification
>
> drivers/cpufreq/cpufreq.c | 6 +++---
> drivers/cpufreq/qcom-cpufreq-hw.c | 16 ++++++++++++----
> 2 files changed, 15 insertions(+), 7 deletions(-)
>