[PATCH 0/2] [RFC] reentrancy in the common clk framework
Mike Turquette
mturquette at linaro.org
Fri Jul 13 20:16:39 EDT 2012
Hi all,
This RFC series is meant to kick off some discussion around two related
problems in the current clk framework implementation.
First, clk_prepare for i2c devices might result in nested calls to
clk_prepare (for preparing the clocks of the i2c controller). So
basically we need to make clk_prepare reentrant for these cases. Due to
the global prepare_lock mutex this currently results in a deadlock.
Second, dynamic voltage and frequency scaling (dvfs) through the clock
framework suffers from a similar issue as describe above. To date
several folks have expressed the desire to put voltage scaling logic
into the clk rate change notifier handlers as a way to implement dvfs
without creating a new driver-level api. There are many benefits to
this approach, but on many platforms it is likely that calling
regulator_set_voltage within a rate change notifier handler will
generate a call to clk_prepare while clk_set_rate is holding the global
prepare_lock mutex. This also results in a deadlock.
The first patch in this series is an attempt to solve the locking
problem via per-clock locks. I do not like per-clock locks, but after
some experimentation it held more promise than other approaches. The
implementation is only partially complete. If you have any alternative
ideas to that sort of approach please let me know as per-clock locks are
really painful.
The second patch in this series simply demonstrates dvfs via clk rate
change notifiers. The patch modifies the .target callback in OMAP's
cpufreq driver by removing direct calls to regulator_set_voltage and
instead registers a clk rate change notifier handler to do the same.
And whaddaya know it works! In a perfect world any cpufreq or devfreq
driver would only need to call clk_set_rate within the .target callback
and everything would Just Work(tm).
Thanks in advance for any feedback, ideas or flames about how I don't
understand lockdep and broke everything and per-clock locking is stupid,
etc.
Mike Turquette (2):
[RFC] clk: reentrancy via per-clock locking
[RFC] cpufreq: omap: scale regulator from clk notifier
drivers/clk/clk.c | 202 +++++++++++++++++++++++++++++-----------
drivers/cpufreq/omap-cpufreq.c | 154 ++++++++++++++++++------------
include/linux/clk-private.h | 5 +
3 files changed, 250 insertions(+), 111 deletions(-)
--
1.7.9.5
More information about the linux-arm-kernel
mailing list