OMAP4: PRM: fix RSTTIME and RSTST offsets

RSTTIME is offset 0x8 and RSTST is offset 0x04 for OMAP4430 and
OMAP4460.

Change-Id: I6626f4f0a5b1704b755181635d47a5eb5cbf6254
Signed-off-by: Nishanth Menon <nm@ti.com>
OMAP4: PRM: improve cold reset logic

Cold reset logic currently could return back and invoke the
'BUG()' call which was supposed to be triggered if coldreset
was'nt functioning, even though the cold reset is eventually
triggered in h/w this gives a misconception that the cold
reset was'nt really functioning.

In OMAP4, the reset logic could take close to 100uSec before
the cold reset is percolated down from PRCM. Unfortunately,
we dont seem to have a status bit to check exactly when the
PRCM decides to send out cold reset signal to rest of h/w.

The delay is pretty much long enough for kernel messages to
be populated with the 'BUG()' call from pm44xx.c.

Further, it is mandatory that Power On reset bit is cleared
by s/w before cold reset is invoked. This is currently being
done by bootloader/PPA.

Change-Id: I886c420b6532e594b67da6a12122cac785ed6df6
Signed-off-by: Nishanth Menon <nm@ti.com>
OMAP3+: PM: VP: dereference voltdm after checking valid voltdm

voltdm should be dereferenced only after voltdm has been checked
for NULL parameters.

Reported-by; Hoon Heo <ryan.heo@samsung.com>
Signed-off-by: Nishanth Menon <nm@ti.com>

Change-Id: I61792933b6a33121dc2e7855e6c0b75f24a0d03b
OMAP2+: PM: Voltage: allow software margin per OPP

Allow per OPP software margin to be defined in OPP table
for the voltage definitions.

Note: OMAP4460 has currently recommended 10mV margin to be added.

This also introduces /sys/kernel/debug/voltage/*/curr_margin_volt
to show the current voltage margin used.

Change-Id: Id49185ffb224d03ac05a41780ad35b1c7a20f4a0
Signed-off-by: Nishanth Menon <nm@ti.com>
OMAP3630+: SmartReflex: use margins per volt_data

Instead of using a generic margin for all volt_data instances
use customized margin per OPP's volt_data instance.

Change-Id: Ic2e144c57747776a075b29130055f72eaba23e74
Signed-off-by: Nishanth Menon <nm@ti.com>
OMAP4460: TWL/TPS data: update retention voltages to spec rev 0.3

Update retention voltages from Operating Conditions Data Manual
Addendum Revision 0.3 (August 2011).

OFF voltage is also updated as per requirement of 4460 OFF mode
conditions.

Change-Id: I558f0a483911b2616d0a19f9272a03258e35904a
Signed-off-by: Nishanth Menon <nm@ti.com>
OMAP4430: TWL data: update retention voltages to spec rev 0.6

Update retention voltages from Operating Conditions Data Manual
Addendum Revision 0.6 (August 2011).

Note: vdd_iva is used as TWL's vcore2 is common between OMAP4430
and OMAP4460 - hence the update is done for 4460 as well(follow
on patch updates rest of the domain voltages to the same voltage
for OMAP4460).

Change-Id: I68a561049f3faf54b877a4d6293682829ee99b62
Signed-off-by: Nishanth Menon <nm@ti.com>
OMAP3630+: PM: LDO: Add support for Reverse Body Bias(RBB)

Reverse Body Bias is a supported feature in the ABB(Adaptive Body Bias)
hardware block. Even though this has been enabled in OMAP4460 for the
first time, support is introduced SoC generic manner.

Just like FBB(Forward Body Bias) mode, RBB mode allows the ABB block
to control the bias voltage supplied to internal IP blocks on a certain
voltage domain.

While invoking DVFS transitions among various OPPs, the API call sequence
is as follows
scaling DOWN	| scaling UP
------------------------------
FREQ		| abb_PRESCALE
abb_PRESCALE	| voltage_scale
voltage_scale	| abb_POSTSCALE
abb_POSTSCALE	| FREQ

By ensuring the values are incremental, we enforce the following
transition triggers:
			TO
		--------------------------------------
		| ABB type	Nominal	| slow	| fast
		|		----------------------
	From	| nominal	| NOP	| post	| post
		| slow		| pre	| NOP	| post
		| fast		| pre	| pre	| NOP
		--------------------------------------

Key:
From - indicates the transition from which type of OPP 'TO' indicates
to which type
nominal, slow and fast are the type of OPP's ABB type
NOP - no action
post, pre shows in which notifier the trigger takes place.

Since we support all three supported modes of ABB, we should
ensure that ABB mode is configured appropriately and LDOs be
moved in and out of bypass as recommended by the TRM.

Change-Id: If8a137de012ebf18b8cbd2a5f03ec347d6577cd4

[axelhaslam@ti.com, nm@ti.com: fixes, cleanups]
Signed-off-by: Nishanth Menon <nm@ti.com>
Signed-off-by: Axel Haslam <axelhaslam@ti.com>
Signed-off-by: Mike Turquette <mturquette@ti.com>
OMAP4460: OPP: update ABB for MPU OPP turbo

On 4460 all OPPs have pre-determined states for VDD_MPU's ABB LDO,
except for OPP_TURBO.  OPP_TURBO may require bypass, FBB or RBB
depending on a combination of characterisation data blown into eFuse
register CONTROL_STD_FUSE_OPP_DPLL_1.

Bits 18 & 19 of that register signify DPLL_MPU trim (see
arch/arm/mach-omap2/omap4-trim-quirks.c).  OPP_TURBO might put MPU's ABB
LDO into bypass or FBB based on this value.

Bit 20 siginifies if RBB should be enabled.  If set it will always
override the values from bits 18 & 19.

The table below captures the valid combinations:

Bit 18 | Bit 19 | Bit 20 | ABB type
0        0        0        bypass
0        1        0        bypass  (invalid combo)
1        0        0        FBB     (2.4GHz DPLL_MPU)
1        1        0        FBB     (3GHz DPLL_MPU)
0        0        1        RBB
0        1        1        RBB     (invalid combo)
1        0        1        RBB     (2.4GHz DPLL_MPU)
1        1        1        RBB     (3GHz DPLL_MPU)

This patch introduces ABB type detection into the OPP init code.

Change-Id: I6140dff1be0f2b9e667160da957c8e1dbabf3e8f
[nm@ti.com: movement of code to central opp update]
Signed-off-by: Nishanth Menon <nm@ti.com>
[mturquette@ti.com: original author]
Signed-off-by: Mike Turquette <mturquette@ti.com>
OMAP4460: OPP: update ABB for IVA OPP turbo

On 4460 all OPPs have pre-determined states for VDD_IVA's ABB LDO,
except for OPP_TURBO.  OPP_TURBO may require bypass or RBB.
depending on a characterisation data blown into eFuse
register CONTROL_STD_FUSE_OPP_DPLL_1.

Bit 21 of that register signify DPLL_IVA trim OPP_TURBO might put
IVA's ABB LDO into bypass or RBB based on this value.

This patch introduces ABB type detection into the OPP init code.

Change-Id: Ie2f49652fda667943a7a9ac76d529c6a594b8755
Signed-off-by: Nishanth Menon <nm@ti.com>
OMAP4460: ID: Add high IVA OPPs identification

As per OMAP Data Manual Operating Conditions Addendum Rev 0.4, Dec 2011,
OMAP4460 devices support IVA OPPTurbo, OPPNT and OPPSB depending on the
type of device. Add flags to identify this feature.

Change-Id: I13eb44e84c2d4e7177976fb8e49cd3b3e0a1c876
[nm@ti.com: specific to OMAP4460]
Signed-off-by: Nishanth Menon <nm@ti.com>
[taras@ti.com: original author]
Signed-off-by: Taras Kondratiuk <taras@ti.com>
OMAP4: OPP: make omap4_mpu_opp_enable generic

Make omap4_mpu_opp_enable generic using the omap_hwmod_name_get_dev api
so that we can reuse it for other devices as well. As part of this,
rename it to omap4_opp_enable.

Change-Id: I1f47e21e1441dbe0ce49e0d470651140bb787940
Signed-off-by: Nishanth Menon <nm@ti.com>
OMAP4: OPP: enable all higher OPPs for vdd_IVA

The standard PMIC used with OMAP4430/4460 is TWL6030. OMAP4430 hooks vdd_iva
to VCORE3 and on OMAP4460, it is hooked on VCORE1.

As per the TWL6030's updated data sheet SWCS045A (Apr 2011):
Iout-ext is 1.1A for VCORE2 and VCORE3, 1.6A for VCORE1.
Iout is 800mA for VCORE2 and VCORE3, 1.5A for VCORE1.

As per OMAP Data Manual, vdd_IVA absolute max rating is:
(OMAP4460: SWPS042J, Nov 2011): 1A
(OMAP4430: SWPS040P, Oct 2011): 700mA

This definitely allows us to enable higher OPPs on vdd_IVA and enables the
possibility of doing better performing DVFS on IVA intensive usecases.

On OMAP4460, vdd_IVA has DSP and IVA devices which allows the OPP Turbo and
OPP Nitro to be enabled for 1.2GHz+ devices while the OPP Nitro SB can be
enabled for 1.5GHz samples.

on OMAP4430, we can enable OPP Turbo for all devices.

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