Re: [PATCH] cpufreq: Do not schedule policy update work in cpufreq_resume()

From	"Rafael J. Wysocki" <rafael@kernel.org>
Newsgroups	linux.kernel
Subject	Re: [PATCH] cpufreq: Do not schedule policy update work in cpufreq_resume()
Date	2016-03-16 13:30 +0100
Message-ID	<rdiKm-rP-7@gated-at.bofh.it> (permalink)
References	<rbHa9-7jY-3@gated-at.bofh.it> <rcQuJ-6Fh-1@gated-at.bofh.it> <rcW78-1Xi-5@gated-at.bofh.it> <rd7YC-1nQ-9@gated-at.bofh.it> <rdbIT-3R6-11@gated-at.bofh.it>
Organization	linux.* mail to news gateway

Show all headers | View raw

On Wed, Mar 16, 2016 at 5:52 AM, Viresh Kumar <viresh.kumar@linaro.org> wrote:
> On 16-03-16, 01:51, Rafael J. Wysocki wrote:
>> OK, so the problem with doing that in syscore ops is that the I2C bus
>> needed for it may not be available at that point, which is fair
>> enough.
>
> Not just that. We wouldn't call syscore-ops for the boot-cpu. It never went
> away.

Yes, we would.

We actually call syscore ops *only* on that CPU.

>> Still, though, the way it is done now is really awful and has to go.
>>
>> I guess something along the lines of cpufreq_update_policy() might be
>> done in cpufreq_resume() before governors are started, but it might
>> even be better to set policy->cur from scratch when starting the
>> governors.  Just do driver->get() and set policy->cur to what that
>> returns (or just use the average of min and max if ->get is not
>> available).  And that unconditionally, regardless of the reason why
>> the governors are started.
>
> I think doing it from a somewhat centric location would make more sense then
> pushing this for the governors.

I'm not talking about doing that in governors, but in
cpufreq_governor() when the event is _START.

> Maybe the beginning of cpufreq_resume() is good enough for that.

Is that really the only case, though?

Thread

[PATCH] cpufreq: Do not schedule policy update work in cpufreq_resume() "Rafael J. Wysocki" <rjw@rjwysocki.net> - 2016-03-12 03:10 +0100
  Re: [PATCH] cpufreq: Do not schedule policy update work in  cpufreq_resume() Viresh Kumar <viresh.kumar@linaro.org> - 2016-03-15 07:20 +0100
    Re: [PATCH] cpufreq: Do not schedule policy update work in cpufreq_resume() "Rafael J. Wysocki" <rafael@kernel.org> - 2016-03-15 13:20 +0100
      Re: [PATCH] cpufreq: Do not schedule policy update work in cpufreq_resume() "Rafael J. Wysocki" <rafael@kernel.org> - 2016-03-16 02:00 +0100
        Re: [PATCH] cpufreq: Do not schedule policy update work in  cpufreq_resume() Viresh Kumar <viresh.kumar@linaro.org> - 2016-03-16 06:00 +0100
          Re: [PATCH] cpufreq: Do not schedule policy update work in cpufreq_resume() "Rafael J. Wysocki" <rafael@kernel.org> - 2016-03-16 13:30 +0100
            Re: [PATCH] cpufreq: Do not schedule policy update work in  cpufreq_resume() Viresh Kumar <viresh.kumar@linaro.org> - 2016-03-17 07:50 +0100
      Re: [PATCH] cpufreq: Do not schedule policy update work in  cpufreq_resume() Viresh Kumar <viresh.kumar@linaro.org> - 2016-03-16 05:50 +0100
        Re: [PATCH] cpufreq: Do not schedule policy update work in cpufreq_resume() "Rafael J. Wysocki" <rafael@kernel.org> - 2016-03-16 14:20 +0100
          Re: [PATCH] cpufreq: Do not schedule policy update work in  cpufreq_resume() Viresh Kumar <viresh.kumar@linaro.org> - 2016-03-17 07:40 +0100

csiph-web