Revert "OMAP4: Clock: Force a DPLL clkdm/pwrdm ON before a relock"

This reverts commit eb54eda.

Linux 3.0.17 update without commit 772aed4 which breaks pm_suspend.

This one took me hours to track down. Sigh..

cpufreq: updated to Linux 3.3 (up to d08de0c)

    [CPUFREQ] update lpj only if frequency has changed
    [CPUFREQ] cpufreq:userspace: fix cpu_cur_freq updation
    [CPUFREQ] Remove wall variable from cpufreq_gov_dbs_init()

slub: 73736e0 (memleak fix) and 4c493a5 (add missed accounting)

omap: dispc: force L3_2 CD to NOSLEEP when dispc module is active

It has been identified that in addition to L3_1, L3_2 clock domain is
also suspetible to the erratum  (erratum ID is pending) described below.

Issue: Mstandby and disconnect protocol issue
impacts: all OMAP4 devices
Simplfied Description:
issue #1: The handshake between IP modules on L3_1 and L3_2 peripherals with
PRCM has a limitation in a certain time window of L4 clock cycle. Due to the
fact that a wrong variant of stall signal was used in circuit of PRCM, the
intitator-interconnect protocol is broken when the time window is hit where
the PRCM requires the interconnect to go to idle while intitator asks to
wakeup.
Issue #2: DISPC asserts a sub-mstandby signal for a short period. In this
time interval, IP block requests disconnection of Master port, and results
in Mstandby and wait request to PRCM. In parallel, if mstandby is de-asserted
by DISPC simultaneously, interconnect requests for a reconnect for one cycle
alone resulting in a disconnect protocol violation and a deadlock of the
system.

Workaround:
L3_1 clock domain must not be programmed in HW_AUTO if
Static dependency with DSS is enabled and DSS clock domain
is ON. Same for L3_2.

Patch with changeID I28ae362ad330a79a493927575c9570462c4303a7
(omap: dispc: force L3_1 CD to NOSLEEP when dispc module is active)
already introduces the work around for L3_1. Here we add L3_2
clock domain as well + update the comments and wrap the WA under
an OMAP4 flag.

Change-Id: I476eedbac34e1876d413a15a524c3b4bb3732b9f
Signed-off-by: Akash Choudhari <[email protected]>
Signed-off-by: Mahesh Renduchintala <[email protected]>
CC: Todd Poynor <[email protected]>
CC: Colin Cross <[email protected]>
CC: Nishanth Menon <[email protected]>
CC: Girish S G <[email protected]>
CC: Dandawate Saket <[email protected]>
CC: Lajos Molnar <[email protected]>

omap2plus-cpufreq.c: user voltage control more fine-tuning

running calibration twice seems to be more accurate.
Still no go on 1.35ghz.

OMAP4: Clock: Put USB_DPLL in stop low power mode explicitly

Normally, USB DPLL stop is h/w auto controlled. We instead put
USB_DPLL in stop mode explicitly when it is disabled instead
of depending on the h/w handshake mechanism and any yet unknown
risks associated with timing of operations to handshake.

Change-Id: I1251eabb6d562d61be90f7ba7f0bc21bd1e3afa9
Signed-off-by: Wenbiao Wang <[email protected]>

Bug fixes for the user undervolt code. Replaced a lot of ugly code

with more ugly code. HAHA

There was a rather crazy bug where at boot it could calibrate the
350 and lower freqs to super high voltages. It seems SmartReflex
is cable of pushing a lot of juice at any frequency and you don't
want to force calibration when that happens. Bad JUJU.

At least that's what I think based on my limited understanding.
:-)

Linux 3.2

Not actually sure why i made this chage. Reverted.