Messages in this thread | | | From | Chunyan Zhang <> | Date | Thu, 23 Apr 2020 10:41:07 +0800 | Subject | Re: [PATCH] PM: sleep: call devfreq_suspend/resume and cpufreq_suspend/resume in pairs. |
| |
On Wed, 22 Apr 2020 at 22:21, Rafael J. Wysocki <rafael@kernel.org> wrote: > > On Wed, Apr 22, 2020 at 1:19 PM Chunyan Zhang <zhang.lyra@gmail.com> wrote: > > > > Hi Rafael, > > > > (Behalf Of Vincent Wang) > > > > Thanks for your comments, please see my answers below. > > > > On Wed, 22 Apr 2020 at 17:05, Rafael J. Wysocki <rafael@kernel.org> wrote: > > > > > > On Wed, Apr 22, 2020 at 7:15 AM Chunyan Zhang <zhang.lyra@gmail.com> wrote: > > > > > > > > From: Vincent Wang <vincent.wang@unisoc.com> > > > > > > > > If dpm_prepare() fails in dpm_suspend_start(), dpm_suspend() can't be > > > > called. > > > > > > That's correct. > > > > > > > And then, devfreq_suspend() and cpufreq_suspend() will not be > > > > called in the suspend flow. > > > > > > Right. > > > > > > > But in the resiume flow, devfreq_resume() and cpufreq_resume() will > > > > be called. > > > > > > Right, and they are expected to cope with the situation. > > > > > > > This patch will ensure that devfreq_suspend/devfreq_resume and > > > > cpufreq_suspend/cpufreq_resume are called in pairs. > > > > > > So why is it better to do this than to make devfreq_resume() meet the > > > expectations? > > > > Yes,we found an issue with cpufreq schedutil governor on kernel4.14, > > and I think the issue should haven't been changed on the latest > > version of kernel. > > > > In the function dpm_suspend_start(), dpm_suspend() would not be > > exceuted if return error from device_prepare() [1]. So > > cpufreq_cpufreq() will not be called, > > I guess you mean cpufreq_suspend(). > > That should be OK . > > > then cpufreq_remove_update_util_hook() will not be called either, and so > > cpufreq_update_util_data will not be NULL. > > > > In the dpm resume flow, sugov_start() will be called, in which > > sg_cpu.update_util will be set to 0. > > Which code patch does this? > > Surely not cpufreq_resume(), because that checks cpufreq_suspended which > cannot be set if cpufreq_suspend() has not been called (because it is the only > place setting cpufreq_suspended).
Right, I saw that, then there's no issue indeed. I just need to backport the patch which added checking of cpufreq_suspended to cpufreq_resume.
Thanks for your review!
| |