[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-Id: <1418771379-24369-1-git-send-email-dtor@chromium.org>
Date: Tue, 16 Dec 2014 15:09:35 -0800
From: Dmitry Torokhov <dtor@...omium.org>
To: "Rafael J. Wysocki" <rjw@...ysocki.net>,
Viresh Kumar <viresh.kumar@...aro.org>
Cc: Thomas Petazzoni <thomas.petazzoni@...e-electrons.com>,
Geert Uytterhoeven <geert+renesas@...der.be>,
Stefan Wahren <stefan.wahren@...e.com>,
Paul Gortmaker <paul.gortmaker@...driver.com>,
Nishanth Menon <nm@...com>, linux-pm@...r.kernel.org,
linux-kernel@...r.kernel.org
Subject: [PATCH 0/4] Allow cpufreq-dt to defer probe if OPP table is not ready
[ Resending as my previous attempt appears to be messed up... ]
This series change cpufreq-dt driver to return -EPROBE_DEFER in case OPP table
is not ready by the time it gets to initialize. The use case is for platforms
that use platform code (or maybe a different driver altogether) to provide OPP
tables.
In addition to changes to cpufreq-dt there are assorted changes to OPP code to
make it work a bit better.
Note that I am not happy with OPP code: dev_pm_opp_init_cpufreq_table() is
wrong in it's assumption that taking RCU lock will guarantee that number of
OPPs will not change - we can remove OPP from list just fine, and then
initialization will fail. I also think that we shoudl change API so users should
get a reference to their OPP table and then pass opaque dev_opp pointer to
accessor APIs instead of re-scanning the global list over and over and over.
Thanks,
Dmitry
Dmitry Torokhov (4):
PM / OPP: add some lockdep annotations
PM / OPP: fix warning in of_free_opp_table
PM / OPP: take RCU lock in dev_pm_opp_get_opp_count
cpufreq-dt: defer probing if OPP table is not ready
drivers/base/power/opp.c | 39 +++++++++++++++++++++++++++++++--------
drivers/cpufreq/cpufreq-dt.c | 11 +++++++++++
2 files changed, 42 insertions(+), 8 deletions(-)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists