omap: clock: implement clock notifier registration infrastructure

This patch implements notifier registration and unregistration
functions for clock rate changes.

The implementation is via a blocking notifier, called with the
clockfw spinlock held.  Callback functions must not re-enter the
clock framework.

There are likely to be few users of these notifiers, compared to
the total number of clocks.  So, rather than storing one notifier
per struct clk, notifiers are stored in a separate, dynamically
allocated list, effectively trading execution speed (in terms of
a sequential scan of the notifier list) for memory savings. The
implementation is completely hidden from the callbacks and can
be easily changed.

Until prototypes for these functions are made available in
include/linux/clk.h, drivers should pass function pointers to
clk_notifier_register() and clk_notifier_unregister() via their
platform_data struct.

Ported from kernel 35.

Change-Id: I30279a72ce04831d6ec88354a6215539be674fc3
Signed-off-by: Paul Walmsley <paul@pwsan.com>
Signed-off-by: Mike Turquette <mturquette@ti.com>
Signed-off-by: Margarita Olaya <magi.olaya@ti.com>
omap: clock: add pre/post clock notifiers

This patch was adapted from Paul Walmsley's original patch introducting
clock notifiers: https://patchwork.kernel.org/patch/13320/

The original comment message is below:

"Call clock notifier blocks before and after rate and parent changes.
If the rate change fails for any reason after the notifier is called with
a pre-rate-change message, call the notifier again with an abort message.

Pre-rate-change notifiers are passed the current clock rate and the
desired clock rate.  For this to work with parent changes, additional
architecture-specific support was needed to predict the clock rate
after the parent change, so a "clk_round_rate_parent" function pointer
was added to struct clk_functions for this purpose, and this was
defined for the OMAP2/3 architecture.

(To minimize performance and code impact, post-rate-change notifiers,
however, are passed only the desired clock rate, i.e., the clock rate
after the rate change.)

The notifiers are called even if the clock rate does not change.  This
is because reprogramming a clock's parent or rate may briefly disrupt
the clock."

Changes to the original patchset include using a new "speculate" function
pointer to walk the list for the PRE change notifier instead of a temporary
storage in struct clk, as well as re-use of some existing clock framework
APIs for determining fieldvals properly.

Change-Id: Ic28fb7349c6a7ca85bb4a05cf5fae4516358ebdb
Signed-off-by: Mike Turquette <mturquette@ti.com>
Signed-off-by: Margarita Olaya <magi.olaya@ti.com>
omap: clock: not all clocks have .round_rate

Protect clk_set_rate function from the case where a clock does
not have a round_rate function pointer.  In such a case we simply
continue with the assumption that the rate passed into clk_set_rate
is OK.

This seems a bit dubious but if a clock does not have a round_rate
it is assumed it also does not have a set_rate function and will be
handled properly by clk_set_rate.

Change-Id: Ib0cce595fe42bbb450cb91196727b14823900bfe
Signed-off-by: Mike Turquette <mturquette@ti.com>
Signed-off-by: Margarita Olaya <magi.olaya@ti.com>
omap: clock: populate "speculate" function ptrs

Every clock must now support the "speculate" function pointer if
it is going to use the new clock notifier framework.  This patch
exports the speculate function and populates the pointer for every
OMAP4 clock.

Change-Id: I4724f0f33886e4ed0bf06164e1743cd98e24e413
Signed-off-by: Mike Turquette <mturquette@ti.com>
Signed-off-by: Margarita Olaya <magi.olaya@ti.com>
OMAP3+: LDO: ensure that right ABB type is selected

since target_volt converted by omap_voltage_get_voltdata to get to
abb type for the OPP voltage level, we can have a scenario as follows:
OPP100 Vnom=1.2V, Vcalib = 0V(not calibrated) ABB type - bypass
OPPNitro Vnom=1.375, Vcalib = 1.2V ABB type = FBB
in this case, voltdm_scale will first gets the operational_voltage
of oppNitro and recieves 1.2V, sends it down to abb_prescale function
which in turn converts it back into vdata using omap_voltage_get_voltdata
however, omap_voltage_get_voltdata walks through the volt_data array
and finds the first match of OPP100 where Vnom = 1.2V and returns
the volt_data pointer for OPP100, this causes ABB logic to think
that it is attempting to go to an OPP with bypass, which in effect
crashes the device once frequency is set to OPPNitro, but ABB is in
bypass mode.

To solve this, we should pass the exact volt_data pointer down to
the abb prescale and postscale handlers so that this back and forth
conversion error does not take place.

Signed-off-by: Nishanth Menon <nm@ti.com>
OMAP3+: VP/VC: ensure vp errgen is configured for the right OPP

Since target_volt converted by omap_voltage_get_voltdata to get to
vp_errgain for the OPP voltage level, we can have a scenario as follows:
OPP100 Vnom=1.2V, Vcalib = 0V(not calibrated) vp_errgain=0x16
OPPNitro Vnom=1.375, Vcalib = 1.2V vp_errgain=0x27
When a request to vc_bypass or vp_forceupdate is provided to OPPNitro
volt_data pointer, it in turn calls vc_prescale with 1.2V, this gets
passed down to vp_errgen_configure, who converts it back into vdata
using omap_voltage_get_voltdata

However, omap_voltage_get_voltdata walks through the volt_data array
and finds the first match of OPP100 where Vnom = 1.2V and returns
the volt_data pointer for OPP100, this causes 0x16 to be selected
for VP errgain instead of 0x27, causing instability for voltage scale
operation.

Instead, pass the volt_data pointer straight to vc_prescale and down
to vp_errgen_configure to ensure that the right configuration parameters
are used.

Signed-off-by: Nishanth Menon <nm@ti.com>
OMAP3+: voltage: omap_voltage_get_voltdata searches only for Vnom

Operational voltage comparisons are wrong in this search since we can
end up with scenarios such as the following:
OPP1 Volt_nominal == OPP2 Volt_calibrated
if the search for Volt_calibrated of OPP2 is done, if OPP1 appears
earlier in the array, this will result in returning the OPP1's
volt_data pointer which is wrong. In such a double match, there is no
real "correct selection" possible.

The current users of this function omap_voltage_get_voltdata are
dvfs.c and pm.c (setting up boot voltage) - both these use Vnom
for search, so it is safe to remove the check for operational voltage
and search for a match only for Vnom.

Signed-off-by: Nishanth Menon <nm@ti.com>