lkml.org 
[lkml]   [2013]   [Nov]   [26]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: [PATCH V3 1/6] cpufreq: suspend governors on system suspend/hibernate
Date
On Tuesday, November 26, 2013 07:56:19 AM Viresh Kumar wrote:
> On 26 November 2013 04:59, Rafael J. Wysocki <rjw@rjwysocki.net> wrote:
> >> @@ -1259,6 +1262,8 @@ int dpm_suspend(pm_message_t state)
> >>
> >> might_sleep();
> >>
> >> + cpufreq_suspend();
> >> +
> >>
> >> mutex_lock(&dpm_list_mtx);
> >> pm_transition = state;
> >> async_error = 0;
> >
> > Shouldn't it do cpufreq_resume() on errors?
>
> Yes and this is already done I believe. In case dpm_suspend() fails,
> dpm_resume() gets called. Isn't it?

OK

> >> diff --git a/drivers/cpufreq/cpufreq.c b/drivers/cpufreq/cpufreq.c
> >> +void cpufreq_suspend(void)
> >> +{
> >> + struct cpufreq_policy *policy;
> >> +
> >> + if (!has_target())
> >> + return;
> >> +
> >> + pr_debug("%s: Suspending Governors\n", __func__);
> >> +
> >> + list_for_each_entry(policy, &cpufreq_policy_list, policy_list)
> >> + if (__cpufreq_governor(policy, CPUFREQ_GOV_STOP))
> >> + pr_err("%s: Failed to stop governor for policy: %p\n",
> >> + __func__, policy);
> >
> > This appears to be racy. Is it really racy, or just seemingly?
>
> Why does it look racy to you? Userspace should be frozen by now,
> policy_list should be stable as well as nobody would touch it.

You're stopping governors while they may be in use in principle. Do we have
suitable synchronization in place for that?

Rafael



\
 
 \ /
  Last update: 2013-11-26 21:41    [W:0.537 / U:0.016 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site