| Message ID | c6c53fee017018869c7524a487688edf902c1413.1398412138.git.viresh.kumar@linaro.org |
|---|---|
| State | New |
| Headers | show |
On 04/25/2014 01:22 PM, Viresh Kumar wrote: > CPUFREQ_ASYNC_NOTIFICATION was initially designed for drivers which don't want > core to send notifications for them as they wouldn't finish frequency > transitions in ->target_index(). > And let's keep it that way. Overloading ASYNC_NOTIFICATION with other meanings is a bad idea. > But there were other kinds of drivers as well who don't have straight forward > implementations of ->target_index() routines and wanted to handle notifications > themselves. > Looking at longhaul, powernow-k6 and powernow-k7, I think we can safely remove the extra notifications from them and let them depend on the cpufreq core's set of notifications. The patchset I posted just now uses that design. Regards, Srivatsa S. Bhat -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
diff --git a/drivers/cpufreq/longhaul.c b/drivers/cpufreq/longhaul.c index d00e5d1..41f3d28 100644 --- a/drivers/cpufreq/longhaul.c +++ b/drivers/cpufreq/longhaul.c @@ -909,6 +909,7 @@ static int longhaul_cpu_init(struct cpufreq_policy *policy) } static struct cpufreq_driver longhaul_driver = { + .flags = CPUFREQ_ASYNC_NOTIFICATION, .verify = cpufreq_generic_frequency_table_verify, .target_index = longhaul_target, .get = longhaul_get, diff --git a/drivers/cpufreq/powernow-k6.c b/drivers/cpufreq/powernow-k6.c index 49f120e..080bbb9 100644 --- a/drivers/cpufreq/powernow-k6.c +++ b/drivers/cpufreq/powernow-k6.c @@ -242,6 +242,7 @@ static unsigned int powernow_k6_get(unsigned int cpu) } static struct cpufreq_driver powernow_k6_driver = { + .flags = CPUFREQ_ASYNC_NOTIFICATION, .verify = cpufreq_generic_frequency_table_verify, .target_index = powernow_k6_target, .init = powernow_k6_cpu_init, diff --git a/drivers/cpufreq/powernow-k7.c b/drivers/cpufreq/powernow-k7.c index f911645..fccfc25 100644 --- a/drivers/cpufreq/powernow-k7.c +++ b/drivers/cpufreq/powernow-k7.c @@ -677,6 +677,7 @@ static int powernow_cpu_exit(struct cpufreq_policy *policy) } static struct cpufreq_driver powernow_driver = { + .flags = CPUFREQ_ASYNC_NOTIFICATION, .verify = cpufreq_generic_frequency_table_verify, .target_index = powernow_target, .get = powernow_get,
CPUFREQ_ASYNC_NOTIFICATION was initially designed for drivers which don't want core to send notifications for them as they wouldn't finish frequency transitions in ->target_index(). But there were other kinds of drivers as well who don't have straight forward implementations of ->target_index() routines and wanted to handle notifications themselves. Patch: 7dbf694 (cpufreq: distinguish drivers that do asynchronous notifications) missed addressing these drivers and that caused these drivers to send double notifications. Initially cpufreq core sends a notification for these and then the drivers themselves. It might not cause a big problem for kernels (3.13/3.14) which doesn't have this patch in: 12478cf (cpufreq: Make sure frequency transitions are serialized), as this came in v3.15-rc1. Reason being, we are sending an extra notification for the same frequency, and so other kernel code that depends on it shouldn't behave badly. Above patch broke things as it forces serialization of notifications, so that we aren't configuring same hardware registers simultaneously. Reported-by: Meelis Roos <mroos@linux.ee> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> --- Hi Rafael, This one is for rc3 surely :) Also, as I mentioned above it might not create any problems for 3.13 and 3.14. And so I havne't cc'd stable for those kernels. Please add them in case you feel its still better to get it fixed. drivers/cpufreq/longhaul.c | 1 + drivers/cpufreq/powernow-k6.c | 1 + drivers/cpufreq/powernow-k7.c | 1 + 3 files changed, 3 insertions(+)