On 6 February 2013 07:36, Dirk Brandewie <[email protected]> wrote: > On 02/05/2013 05:47 PM, Viresh Kumar wrote: >> >> On Tue, Feb 5, 2013 at 11:54 PM, <[email protected]> wrote: >>> >>> From: Dirk Brandewie <[email protected]> >>> >>> Scaling drivers that implement cpufreq_driver.setpolicy() have >>> internal governors and may/will change the current operating frequency >>> very frequently this will cause cpufreq_out_of_sync() to be called >>> every time. Only call cpufreq_driver.get() for drivers that implement >>> cpufreq_driver.target() >>> >>> Signed-off-by: Dirk Brandewie <[email protected]> >>> --- >>> drivers/cpufreq/cpufreq.c | 2 +- >>> 1 files changed, 1 insertions(+), 1 deletions(-) >>> >>> diff --git a/drivers/cpufreq/cpufreq.c b/drivers/cpufreq/cpufreq.c >>> index 96bc302..d8daa4b 100644 >>> --- a/drivers/cpufreq/cpufreq.c >>> +++ b/drivers/cpufreq/cpufreq.c >>> @@ -1787,7 +1787,7 @@ int cpufreq_update_policy(unsigned int cpu) >>> >>> /* BIOS might change freq behind our back >>> -> ask driver for current freq and notify governors about a >>> change */ >>> - if (cpufreq_driver->get) { >>> + if (cpufreq_driver->get && cpufreq_driver->target) { >>> policy.cur = cpufreq_driver->get(cpu); >>> if (!data->cur) { >>> pr_debug("Driver did not initialize current >>> freq"); >> >> >> I am really not liking copy-pasting my older comments here :( >> >> "This would mean policy->cur has a garbage value. I don't really know >> how would other routine behave on this. Would it make sense to make >> policy->cur zero atleast? >> " >> > The driver implements get() and will return a valid value but the other > components that track the current frequency will not have been notified > about any change so there is nothing to be out of sync with. There is no > reason to call cpufreq_out_of_sync() where the driver being used implements > an internal > governor.
Not sure if we are discussing the same issue. What i am saying is, with your patch we aren't calling following line: >>> policy.cur = cpufreq_driver->get(cpu); and policy was a local variable. Hence policy->cur is having a garbage value. policy->cur is used at multiple places in cpufreq.c . Please check everywhere if this garbage value doesn't break set_policy() type systems. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
