From patchwork Fri Nov 15 10:12:29 2013 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Viresh Kumar X-Patchwork-Id: 3187511 Return-Path: X-Original-To: patchwork-linux-pm@patchwork.kernel.org Delivered-To: patchwork-parsemail@patchwork1.web.kernel.org Received: from mail.kernel.org (mail.kernel.org [198.145.19.201]) by patchwork1.web.kernel.org (Postfix) with ESMTP id EDF2F9F39E for ; Fri, 15 Nov 2013 10:12:54 +0000 (UTC) Received: from mail.kernel.org (localhost [127.0.0.1]) by mail.kernel.org (Postfix) with ESMTP id 31B9120956 for ; Fri, 15 Nov 2013 10:12:50 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 0281E2094D for ; Fri, 15 Nov 2013 10:12:45 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1758404Ab3KOKMo (ORCPT ); Fri, 15 Nov 2013 05:12:44 -0500 Received: from mail-qa0-f54.google.com ([209.85.216.54]:35654 "EHLO mail-qa0-f54.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1757789Ab3KOKMm (ORCPT ); Fri, 15 Nov 2013 05:12:42 -0500 Received: by mail-qa0-f54.google.com with SMTP id j7so416116qaq.6 for ; Fri, 15 Nov 2013 02:12:40 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:cc:subject:date:message-id; bh=Dk4IT96P3TSotyxktZvTiLxd0GDQWlGzHPEEBwAnUvE=; b=aUDO/sg8eAYVQnf6advxSGspE/5o6fkRuy9wnb58xcphJ7rg9dLo0qO9OiiYS+LkhI cxHVGbYiU58kAjU5IFXKabLMwEzWRz2dqAyTJBzJD2bfwyIxfqTLtr+Q7WOfSmCysPOm 017NBf2tC6hYYdnQdLASW9nNubIqYEaJtYM2zGsdxqs34l0ILpUTcGmTuiXN+awn7Px6 Z++uttYuf2g1p1CAbAblDIXsF0bc0BfUhF7/3rt4aB1SDwrHFgQsygvwifh5xfKXDJtr 9f2TWFtiH9MbXNW5sPAXCRkSeQjx4jvSA8Wcy0CXNI8uNVdDNsFGTJh/CRmVoRrSbpFZ kHOw== X-Gm-Message-State: ALoCoQkdu1hKzpg2TBFG7N7DBZnN7VukDVUaqy7b9/Ga4oFZ/uyx/9srAtNftm9qwEAjO/lCCxXY X-Received: by 10.224.54.202 with SMTP id r10mr7700925qag.8.1384510360322; Fri, 15 Nov 2013 02:12:40 -0800 (PST) Received: from localhost (git.linaro.org. [54.235.93.228]) by mx.google.com with ESMTPSA id u3sm4745553qej.8.2013.11.15.02.12.35 for (version=TLSv1.2 cipher=RC4-SHA bits=128/128); Fri, 15 Nov 2013 02:12:39 -0800 (PST) From: Viresh Kumar To: rjw@sisk.pl Cc: linaro-kernel@lists.linaro.org, patches@linaro.org, cpufreq@vger.kernel.org, linux-pm@vger.kernel.org, linux-kernel@vger.kernel.org, tianyu.lan@intel.com, nm@ti.com, jinchoi@broadcom.com, sebastian.capella@linaro.org, Viresh Kumar Subject: [PATCH] cpufreq: suspend/resume governors with PM notifiers Date: Fri, 15 Nov 2013 15:42:29 +0530 Message-Id: <0e476d16e0ae4b001f5dd4f9ac191f899095928a.1384510171.git.viresh.kumar@linaro.org> X-Mailer: git-send-email 1.7.12.rc2.18.g61b472e Sender: linux-pm-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-pm@vger.kernel.org X-Spam-Status: No, score=-6.9 required=5.0 tests=BAYES_00, RCVD_IN_DNSWL_HI, RP_MATCHES_RCVD, UNPARSEABLE_RELAY autolearn=unavailable version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on mail.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP This patch adds PM notifiers for handling suspend/resume of cpufreq governors. This is required for early suspend and late resume of governors. There are multiple reasons that support this patch: - Firstly it looks very much logical to stop governors when we know we are going into suspend. But the question is when? Is PM notifiers the right place? Following reasons are the supporting hands for this decision. - Nishanth Menon (TI) found an interesting problem on his platform, OMAP. His board wasn't working well with suspend/resume as calls for removing non-boot CPUs was turning out into a call to drivers ->target() which then tries to play with regulators. But regulators and their I2C bus were already suspended and this resulted in a failure. This is why we need a PM notifier here. - Lan Tianyu (Intel) & Jinhyuk Choi (Broadcom) found another issue where tunables configuration for clusters/sockets with non-boot CPUs was getting lost after suspend/resume, as we were notifying governors with CPUFREQ_GOV_POLICY_EXIT on removal of the last cpu for that policy and so deallocating memory for tunables. All above problems get fixed with having a PM notifier in place which will stop any operation on governor. Hence no need to do any special handling of variables like (frozen) in suspend/resume paths. Reported-by: Lan Tianyu Reported-by: Nishanth Menon Reported-by: Jinhyuk Choi Signed-off-by: Viresh Kumar Tested-by: Nishanth Menon Tested-by: Lan Tianyu --- Hi Guys, Can you please verify if this fixes issues reported by you? I have tested this for multiple suspend-resumes on my thinkpad. It doesn't crash :) drivers/cpufreq/cpufreq.c | 63 +++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 63 insertions(+) diff --git a/drivers/cpufreq/cpufreq.c b/drivers/cpufreq/cpufreq.c index 02d534d..c87ced9 100644 --- a/drivers/cpufreq/cpufreq.c +++ b/drivers/cpufreq/cpufreq.c @@ -26,6 +26,7 @@ #include #include #include +#include #include #include #include @@ -47,6 +48,9 @@ static LIST_HEAD(cpufreq_policy_list); static DEFINE_PER_CPU(char[CPUFREQ_NAME_LEN], cpufreq_cpu_governor); #endif +/* Flag to suspend/resume CPUFreq governors */ +static bool cpufreq_suspended; + static inline bool has_target(void) { return cpufreq_driver->target_index || cpufreq_driver->target; @@ -1462,6 +1466,54 @@ static struct subsys_interface cpufreq_interface = { .remove_dev = cpufreq_remove_dev, }; +/* + * PM Notifier for suspending governors as some platforms can't change frequency + * after this point in suspend cycle. Because some of the devices (like: i2c, + * regulators, etc) they use for changing frequency are suspended quickly after + * this point. + */ +static int cpufreq_pm_notify(struct notifier_block *nb, unsigned long action, + void *data) +{ + struct cpufreq_policy *policy; + unsigned long flags; + + if (!has_target()) + return NOTIFY_OK; + + if (action == PM_SUSPEND_PREPARE) { + 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); + + write_lock_irqsave(&cpufreq_driver_lock, flags); + cpufreq_suspended = true; + write_unlock_irqrestore(&cpufreq_driver_lock, flags); + } else if (action == PM_POST_SUSPEND) { + pr_debug("%s: Resuming Governors\n", __func__); + + write_lock_irqsave(&cpufreq_driver_lock, flags); + cpufreq_suspended = false; + write_unlock_irqrestore(&cpufreq_driver_lock, flags); + + list_for_each_entry(policy, &cpufreq_policy_list, policy_list) + if (__cpufreq_governor(policy, CPUFREQ_GOV_START) || + __cpufreq_governor(policy, + CPUFREQ_GOV_LIMITS)) + pr_err("%s: Failed to start governor for policy: %p\n", + __func__, policy); + } + + return NOTIFY_OK; +} + +static struct notifier_block cpufreq_pm_notifier = { + .notifier_call = cpufreq_pm_notify, +}; + /** * cpufreq_bp_suspend - Prepare the boot CPU for system suspend. * @@ -1752,6 +1804,8 @@ EXPORT_SYMBOL_GPL(cpufreq_driver_target); static int __cpufreq_governor(struct cpufreq_policy *policy, unsigned int event) { + unsigned long flags; + bool is_suspended; int ret; /* Only must be defined when default governor is known to have latency @@ -1764,6 +1818,14 @@ static int __cpufreq_governor(struct cpufreq_policy *policy, struct cpufreq_governor *gov = NULL; #endif + /* Don't start any governor operations if we are entering suspend */ + read_lock_irqsave(&cpufreq_driver_lock, flags); + is_suspended = cpufreq_suspended; + read_unlock_irqrestore(&cpufreq_driver_lock, flags); + + if (is_suspended) + return 0; + if (policy->governor->max_transition_latency && policy->cpuinfo.transition_latency > policy->governor->max_transition_latency) { @@ -2222,6 +2284,7 @@ static int __init cpufreq_core_init(void) cpufreq_global_kobject = kobject_create(); BUG_ON(!cpufreq_global_kobject); register_syscore_ops(&cpufreq_syscore_ops); + register_pm_notifier(&cpufreq_pm_notifier); return 0; }