From: Viresh Kumar <viresh.kumar@linaro.org>
To: Rafael Wysocki <rjw@rjwysocki.net>
Cc: linaro-kernel@lists.linaro.org, linux-pm@vger.kernel.org,
prarit@redhat.com, skannan@codeaurora.org,
Viresh Kumar <viresh.kumar@linaro.org>
Subject: [PATCH 14/17] cpufreq: check cpufreq_policy_list instead of scanning policies for all CPUs
Date: Fri, 2 Jan 2015 12:34:35 +0530 [thread overview]
Message-ID: <c7ce73584f4946ced7923f89538f312383cad1e2.1420181916.git.viresh.kumar@linaro.org> (raw)
In-Reply-To: <cover.1420181916.git.viresh.kumar@linaro.org>
In-Reply-To: <cover.1420181916.git.viresh.kumar@linaro.org>
CPUFREQ_STICKY flag is set by drivers which don't want to get unregistered even
if cpufreq-core isn't able to initialize policy for any CPU.
When this flag isn't set, we try to unregister the driver. To find out which
CPUs are registered and which are not, we try to check per_cpu cpufreq_cpu_data
for all CPUs. Because we have a list of valid policies available now, we better
check if the list is empty or not instead of the 'for' loop. That will be much
more efficient.
Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
---
drivers/cpufreq/cpufreq.c | 21 +++++----------------
1 file changed, 5 insertions(+), 16 deletions(-)
diff --git a/drivers/cpufreq/cpufreq.c b/drivers/cpufreq/cpufreq.c
index 74169ad47546..09426671eb79 100644
--- a/drivers/cpufreq/cpufreq.c
+++ b/drivers/cpufreq/cpufreq.c
@@ -2442,23 +2442,12 @@ int cpufreq_register_driver(struct cpufreq_driver *driver_data)
if (ret)
goto err_boost_unreg;
- if (!(cpufreq_driver->flags & CPUFREQ_STICKY)) {
- int i;
- ret = -ENODEV;
-
- /* check for at least one working CPU */
- for (i = 0; i < nr_cpu_ids; i++)
- if (cpu_possible(i) && per_cpu(cpufreq_cpu_data, i)) {
- ret = 0;
- break;
- }
-
+ if (!(cpufreq_driver->flags & CPUFREQ_STICKY) &&
+ list_empty(&cpufreq_policy_list)) {
/* if all ->init() calls failed, unregister */
- if (ret) {
- pr_debug("no CPU initialized for driver %s\n",
- driver_data->name);
- goto err_if_unreg;
- }
+ pr_debug("%s: No CPU initialized for driver %s\n", __func__,
+ driver_data->name);
+ goto err_if_unreg;
}
register_hotcpu_notifier(&cpufreq_cpu_notifier);
--
2.2.0
next prev parent reply other threads:[~2015-01-02 7:05 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-01-02 7:04 [PATCH 00/17] cpufreq: trivial cleanups Viresh Kumar
2015-01-02 7:04 ` [PATCH 01/17] cpufreq: remove dangling comment Viresh Kumar
2015-01-02 7:04 ` [PATCH 02/17] cpufreq: remove extra parenthesis Viresh Kumar
2015-01-02 7:04 ` [PATCH 03/17] cpufreq: don't need line break in show_scaling_cur_freq() Viresh Kumar
2015-01-02 7:04 ` [PATCH 04/17] cpufreq: merge 'if' blocks in __cpufreq_remove_dev_prepare() Viresh Kumar
2015-01-02 7:04 ` [PATCH 05/17] cpufreq: s/__find_governor/find_governor Viresh Kumar
2015-01-02 7:04 ` [PATCH 06/17] cpufreq: No need to check for has_target() Viresh Kumar
2015-01-02 7:04 ` [PATCH 07/17] cpufreq: pass policy to cpufreq_out_of_sync Viresh Kumar
2015-01-02 7:04 ` [PATCH 08/17] cpufreq: pass policy to __cpufreq_get() Viresh Kumar
2015-01-02 7:04 ` [PATCH 09/17] cpufreq: update driver_data->flags only if we are registering driver Viresh Kumar
2015-01-02 7:04 ` [PATCH 10/17] cpufreq: get rid of CONFIG_{HOTPLUG_CPU|SMP} mess Viresh Kumar
2015-01-02 7:04 ` [PATCH 11/17] cpufreq: get rid of 'tpolicy' from __cpufreq_add_dev() Viresh Kumar
2015-01-02 7:04 ` [PATCH 12/17] cpufreq: use light-weight cpufreq_cpu_get_raw() in __cpufreq_add_dev Viresh Kumar
2015-01-02 7:04 ` [PATCH 13/17] cpufreq: limit the scope of l_p_j variables Viresh Kumar
2015-01-02 7:04 ` Viresh Kumar [this message]
2015-01-02 7:04 ` [PATCH 15/17] cpufreq: don't check if cpu > nr_cpu_ids Viresh Kumar
2015-01-02 7:04 ` [PATCH 16/17] cpufreq: remove check for cpufreq_disabled() from cpufreq_cpu_{get|put}() Viresh Kumar
2015-01-25 13:24 ` Viresh Kumar
2015-01-26 0:39 ` Rafael J. Wysocki
2015-01-27 3:47 ` Viresh Kumar
2015-01-02 7:04 ` [PATCH 17/17] cpufreq: move some initialization stuff to cpufreq_policy_alloc() Viresh Kumar
2015-01-12 6:11 ` [PATCH 00/17] cpufreq: trivial cleanups Viresh Kumar
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=c7ce73584f4946ced7923f89538f312383cad1e2.1420181916.git.viresh.kumar@linaro.org \
--to=viresh.kumar@linaro.org \
--cc=linaro-kernel@lists.linaro.org \
--cc=linux-pm@vger.kernel.org \
--cc=prarit@redhat.com \
--cc=rjw@rjwysocki.net \
--cc=skannan@codeaurora.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).