Reapply "cpufreq: schedutil: Always process remote callback with slow switching"

This reverts commit f7b03e2cd6f829a4fe1be4284ce5b9098eec4f74.

diff --git a/kernel/sched/cpufreq_schedutil.c b/kernel/sched/cpufreq_schedutil.c
index cca814d5670c223dcc45b0a131c5c77aad0a15fe..e3d779620708c7e91a10dc3a71b6549608e7a491 100644 (file)
--- a/kernel/sched/cpufreq_schedutil.c
+++ b/kernel/sched/cpufreq_schedutil.c
@@ -105,13 +105,18 @@ static bool sugov_should_update_freq(struct sugov_policy *sg_policy, u64 time)
         *
         * However, drivers cannot in general deal with cross-cpu
         * requests, so while get_next_freq() will work, our
-        * sugov_update_commit() call may not.
+        * sugov_update_commit() call may not for the fast switching platforms.
         *
         * Hence stop here for remote requests if they aren't supported
         * by the hardware, as calculating the frequency is pointless if
         * we cannot in fact act on it.
+        *
+        * For the slow switching platforms, the kthread is always scheduled on
+        * the right set of CPUs and any CPU can find the next frequency and
+        * schedule the kthread.
         */
-       if (!cpufreq_can_do_remote_dvfs(sg_policy->policy))
+       if (sg_policy->policy->fast_switch_enabled &&
+           !cpufreq_can_do_remote_dvfs(sg_policy->policy))
                return false;
 
        if (sg_policy->work_in_progress)