| Message ID | 20130711221527.547.46447.stgit@srivatsabhat.in.ibm.com (mailing list archive) |
|---|---|
| State | Accepted, archived |
| Headers | show |
On 12 July 2013 03:45, Srivatsa S. Bhat <srivatsa.bhat@linux.vnet.ibm.com> wrote: > commit a66b2e (cpufreq: Preserve sysfs files across suspend/resume) has > unfortunately caused several things in the cpufreq subsystem to break subtly > after a suspend/resume cycle. > > The intention of that patch was to retain the file permissions of the > cpufreq related sysfs files across suspend/resume. To achieve that, the commit > completely removed the calls to cpufreq_add_dev() and __cpufreq_remove_dev() > during suspend/resume transitions. But the problem is that those functions > do 2 kinds of things: > 1. Low-level initialization/tear-down that are critical to the correct > functioning of cpufreq-core. > 2. Kobject and sysfs related initialization/teardown. > > Ideally we should have reorganized the code to cleanly separate these two > responsibilities, and skipped only the sysfs related parts during > suspend/resume. Since we skipped the entire callbacks instead (which also > included some CPU and cpufreq-specific critical components), cpufreq > subsystem started behaving erratically after suspend/resume. > > So revert the commit to fix the regression. We'll revisit and address the > original goal of that commit separately, since it involves quite a bit of > careful code reorganization and appears to be non-trivial. > > (While reverting the commit, note that another commit f51e1eb "cpufreq: > Fix cpufreq regression after suspend/resume" already reverted part of the > original set of changes. So revert only the remaining ones). > > Cc: stable@vger.kernel.org > Signed-off-by: Srivatsa S. Bhat <srivatsa.bhat@linux.vnet.ibm.com> > --- > > drivers/cpufreq/cpufreq.c | 4 +++- > drivers/cpufreq/cpufreq_stats.c | 6 ++---- > 2 files changed, 5 insertions(+), 5 deletions(-) Acked-by: Viresh Kumar <viresh.kumar@linaro.org> -- To unsubscribe from this list: send the line "unsubscribe linux-pm" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Fri, 2013-07-12 at 12:48 +0530, Viresh Kumar wrote: > On 12 July 2013 03:45, Srivatsa S. Bhat > <srivatsa.bhat@linux.vnet.ibm.com> wrote: > > commit a66b2e (cpufreq: Preserve sysfs files across suspend/resume) has > > unfortunately caused several things in the cpufreq subsystem to break subtly > > after a suspend/resume cycle. > > > > The intention of that patch was to retain the file permissions of the > > cpufreq related sysfs files across suspend/resume. To achieve that, the commit > > completely removed the calls to cpufreq_add_dev() and __cpufreq_remove_dev() > > during suspend/resume transitions. But the problem is that those functions > > do 2 kinds of things: > > 1. Low-level initialization/tear-down that are critical to the correct > > functioning of cpufreq-core. > > 2. Kobject and sysfs related initialization/teardown. > > > > Ideally we should have reorganized the code to cleanly separate these two > > responsibilities, and skipped only the sysfs related parts during > > suspend/resume. Since we skipped the entire callbacks instead (which also > > included some CPU and cpufreq-specific critical components), cpufreq > > subsystem started behaving erratically after suspend/resume. > > > > So revert the commit to fix the regression. We'll revisit and address the > > original goal of that commit separately, since it involves quite a bit of > > careful code reorganization and appears to be non-trivial. > > > > (While reverting the commit, note that another commit f51e1eb "cpufreq: > > Fix cpufreq regression after suspend/resume" already reverted part of the > > original set of changes. So revert only the remaining ones). > > > > Cc: stable@vger.kernel.org > > Signed-off-by: Srivatsa S. Bhat <srivatsa.bhat@linux.vnet.ibm.com> > > --- > > > > drivers/cpufreq/cpufreq.c | 4 +++- > > drivers/cpufreq/cpufreq_stats.c | 6 ++---- > > 2 files changed, 5 insertions(+), 5 deletions(-) > > Acked-by: Viresh Kumar <viresh.kumar@linaro.org> This seems to fix the "core stuck at some frequency after resume" issue I ran into since v3.10. So: Tested-by: Paul Bolle <pebolle@tiscali.nl> Paul Bolle -- To unsubscribe from this list: send the line "unsubscribe linux-pm" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On 07/13/2013 06:16 PM, Paul Bolle wrote: > On Fri, 2013-07-12 at 12:48 +0530, Viresh Kumar wrote: >> On 12 July 2013 03:45, Srivatsa S. Bhat >> <srivatsa.bhat@linux.vnet.ibm.com> wrote: >>> commit a66b2e (cpufreq: Preserve sysfs files across suspend/resume) has >>> unfortunately caused several things in the cpufreq subsystem to break subtly >>> after a suspend/resume cycle. >>> >>> The intention of that patch was to retain the file permissions of the >>> cpufreq related sysfs files across suspend/resume. To achieve that, the commit >>> completely removed the calls to cpufreq_add_dev() and __cpufreq_remove_dev() >>> during suspend/resume transitions. But the problem is that those functions >>> do 2 kinds of things: >>> 1. Low-level initialization/tear-down that are critical to the correct >>> functioning of cpufreq-core. >>> 2. Kobject and sysfs related initialization/teardown. >>> >>> Ideally we should have reorganized the code to cleanly separate these two >>> responsibilities, and skipped only the sysfs related parts during >>> suspend/resume. Since we skipped the entire callbacks instead (which also >>> included some CPU and cpufreq-specific critical components), cpufreq >>> subsystem started behaving erratically after suspend/resume. >>> >>> So revert the commit to fix the regression. We'll revisit and address the >>> original goal of that commit separately, since it involves quite a bit of >>> careful code reorganization and appears to be non-trivial. >>> >>> (While reverting the commit, note that another commit f51e1eb "cpufreq: >>> Fix cpufreq regression after suspend/resume" already reverted part of the >>> original set of changes. So revert only the remaining ones). >>> >>> Cc: stable@vger.kernel.org >>> Signed-off-by: Srivatsa S. Bhat <srivatsa.bhat@linux.vnet.ibm.com> >>> --- >>> >>> drivers/cpufreq/cpufreq.c | 4 +++- >>> drivers/cpufreq/cpufreq_stats.c | 6 ++---- >>> 2 files changed, 5 insertions(+), 5 deletions(-) >> >> Acked-by: Viresh Kumar <viresh.kumar@linaro.org> > > This seems to fix the "core stuck at some frequency after resume" issue > I ran into since v3.10. So: > > Tested-by: Paul Bolle <pebolle@tiscali.nl> > Thanks Paul! Regards, Srivatsa S. Bhat -- To unsubscribe from this list: send the line "unsubscribe linux-pm" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
diff --git a/drivers/cpufreq/cpufreq.c b/drivers/cpufreq/cpufreq.c index 6a015ad..ccc6eab 100644 --- a/drivers/cpufreq/cpufreq.c +++ b/drivers/cpufreq/cpufreq.c @@ -1941,13 +1941,15 @@ static int __cpuinit cpufreq_cpu_callback(struct notifier_block *nfb, if (dev) { switch (action) { case CPU_ONLINE: + case CPU_ONLINE_FROZEN: cpufreq_add_dev(dev, NULL); break; case CPU_DOWN_PREPARE: - case CPU_UP_CANCELED_FROZEN: + case CPU_DOWN_PREPARE_FROZEN: __cpufreq_remove_dev(dev, NULL); break; case CPU_DOWN_FAILED: + case CPU_DOWN_FAILED_FROZEN: cpufreq_add_dev(dev, NULL); break; } diff --git a/drivers/cpufreq/cpufreq_stats.c b/drivers/cpufreq/cpufreq_stats.c index cd9e817..12225d1 100644 --- a/drivers/cpufreq/cpufreq_stats.c +++ b/drivers/cpufreq/cpufreq_stats.c @@ -353,13 +353,11 @@ static int __cpuinit cpufreq_stat_cpu_callback(struct notifier_block *nfb, cpufreq_update_policy(cpu); break; case CPU_DOWN_PREPARE: + case CPU_DOWN_PREPARE_FROZEN: cpufreq_stats_free_sysfs(cpu); break; case CPU_DEAD: - cpufreq_stats_free_table(cpu); - break; - case CPU_UP_CANCELED_FROZEN: - cpufreq_stats_free_sysfs(cpu); + case CPU_DEAD_FROZEN: cpufreq_stats_free_table(cpu); break; }
commit a66b2e (cpufreq: Preserve sysfs files across suspend/resume) has unfortunately caused several things in the cpufreq subsystem to break subtly after a suspend/resume cycle. The intention of that patch was to retain the file permissions of the cpufreq related sysfs files across suspend/resume. To achieve that, the commit completely removed the calls to cpufreq_add_dev() and __cpufreq_remove_dev() during suspend/resume transitions. But the problem is that those functions do 2 kinds of things: 1. Low-level initialization/tear-down that are critical to the correct functioning of cpufreq-core. 2. Kobject and sysfs related initialization/teardown. Ideally we should have reorganized the code to cleanly separate these two responsibilities, and skipped only the sysfs related parts during suspend/resume. Since we skipped the entire callbacks instead (which also included some CPU and cpufreq-specific critical components), cpufreq subsystem started behaving erratically after suspend/resume. So revert the commit to fix the regression. We'll revisit and address the original goal of that commit separately, since it involves quite a bit of careful code reorganization and appears to be non-trivial. (While reverting the commit, note that another commit f51e1eb "cpufreq: Fix cpufreq regression after suspend/resume" already reverted part of the original set of changes. So revert only the remaining ones). Cc: stable@vger.kernel.org Signed-off-by: Srivatsa S. Bhat <srivatsa.bhat@linux.vnet.ibm.com> --- drivers/cpufreq/cpufreq.c | 4 +++- drivers/cpufreq/cpufreq_stats.c | 6 ++---- 2 files changed, 5 insertions(+), 5 deletions(-) -- To unsubscribe from this list: send the line "unsubscribe linux-pm" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html