clk: allow reentrant calls into the clk framework

Reentrancy into the clock framework from the clk.h api is highly
desirable.  This feature is necessary for clocks that are prepared and
unprepared via i2c_transfer (which includes many PMICs and discrete
audio chips) and it is also necessary for performing dynamic voltage &
frequency scaling via clock rate-change notifiers.

This patch implements reentrancy by adding a global atomic_t which
tracks the context of the current caller.  Context in this case is the
return value from get_current().  The clk.h api implementations are
modified to first see if the relevant global lock is already held and if
so compare the global context (set by whoever is holding the lock)
against their own context (via a call to get_current()).  If the two
match then this function is a nested call from the one already holding
the lock and we procede.  If the context does not match then procede to
call mutex_lock and busy-wait for the existing task to complete.

Thus this patch set does not increase concurrency for unrelated calls
into the clock framework.  Instead it simply allows reentrancy by the
single task which is currently holding the global clock framework lock.

Thanks to Rajagoapl Venkat for the original idea to use get_current()
and to David Brown for the suggestion to replace my previous rwlock
scheme with atomic operations during code review at ELC 2013.

Signed-off-by: Mike Turquette <mturquette@linaro.org>
Cc: Rajagopal Venkat <rajagopal.venkat@linaro.org>
Cc: David Brown <davidb@codeaurora.org>
clk: notifier handler for dynamic voltage scaling

Dynamic voltage and frequency scaling (dvfs) is a common power saving
technique in many of today's modern processors.  This patch introduces a
common clk rate-change notifier handler which scales voltage
appropriately whenever clk_set_rate is called on an affected clock.

There are three prerequisites to using this feature:

1) the affected clocks must be using the common clk framework
2) voltage must be scaled using the regulator framework
3) clock frequency and regulator voltage values must be paired via the
OPP library

If a platform or device meets these requirements then using the notifier
handler is straightforward.  A struct device is used as the basis for
performing initial look-ups for clocks via clk_get and regulators via
regulator_get.  This means that notifiers are subscribed on a per-device
basis and multiple devices can have notifiers subscribed to the same
clock.  Put another way, the voltage chosen for a rail during a call to
clk_set_rate is a function of the device, not the clock.

Signed-off-by: Mike Turquette <mturquette@linaro.org>
cpufreq: omap: scale regulator from clk notifier

This patch moves direct control of the MPU voltage regulator out of the
cpufreq driver .target callback and instead uses the common dvfs clk
rate-change notifier infrastructure.

Ideally it would be nice to reduce the .target callback for omap's
cpufreq driver to a simple call to clk_set_rate.  For now there is still
some other stuff needed there (jiffies per loop, rounding the rate, etc
etc).

Signed-off-by: Mike Turquette <mturquette@linaro.org>
HACK: set_parent callback for OMAP4 non-core DPLLs

This is a silly patch that demonstrates calling clk_set_parent from
within a .set_rate callback, which itself was called by clk_set_rate.
It may make your board burst into flames or otherwise void various
warrantees.

I do not suggest that the OMAP folks take this approach in unless they
really want to.  Instead it was a way for me to increase code coverage
while testing the reentrancy changes to the core clock framework.

Changes in this patch include removing __clk_prepare and __clk_unprepare
from omap3_noncore_dpll_set_rate and using the (now reentrant)
clk_prepare & clk_unprepare versions.  Most importantly this patch
introduces omap3_noncore_dpll_set_parent and adds it to the clk_ops for
all OMAP3+ DPLLs.

The net gain is that on OMAP4 platforms it is now possible to call
clk_set_parent(some_dpll_ck, ...) in order to change the PLL input from
the reference clock to the bypass clock, and vice versa.

omap3_noncore_dpll_set_rate is modified to call clk_set_parent when
appropriate as a way to test reentrancy.

Not-signed-off-by: Mike Turquette <mturquette@linaro.org>
HACK: omap: opp: add fake 400MHz OPP to bypass MPU

The following is another silly patch which was done to test calling
clk_set_parent from within a call to clk_set_rate.  It may make your
board burst into flames or otherwise void various warrantees.

This patch introduces a 400MHz OPP for the MPU, which happens to
correspond to the bypass clk rate on the 4430 Panda board and 4460 Panda
ES board, both using a 38.4MHz SYS_CLK oscillator rate.

One may test this by using the cpufreq-userspace governor and executing:
echo 400000 > /sys/devices/system/cpu/cpu0/cpufreq/scaling_setspeed

On Panda ES validation can be done via:
$ find /debug/clk/ -iname "dpll_mpu_ck"
/debug/clk/virt_38400000_ck/sys_clkin_ck/dpll_mpu_ck
$ echo 400000 > scaling_setspeed
$ find /debug/clk/ -iname "dpll_mpu_ck"
/debug/clk/virt_38400000_ck/sys_clkin_ck/dpll_core_ck/dpll_core_x2_ck/dpll_core_m5x2_ck/div_mpu_hs_clk/dpll_mpu_ck
$ cat /proc/cpuinfo
...
BogoMIPS        : 794.26
...
$ cat /sys/class/regulator/regulator.3/microvolts
1200000

Not-signed-off-by: Mike Turquette <mturquette@ti.com>