OMAP4: ABB: add RBB support

Adds support for Reverse Body Bias.
Some OMAP4460 devices may require RBB for OPP_TURBO on MPU and IVA
domains.

This is a porting from TI Android 3.0 kernel, several code layers and
patches iterations from:
Mike Turquette <mturquette@ti.com>
Taras Kondratiuk <taras@ti.com>
Nishanth Menon <nm@ti.com>

Signed-off-by: Sebastien Jan <s-jan@ti.com>
OMAP4460: ABB: add trim support

Adds support for trimming: OMAP4460 devices may require some ABB
triming for OPP_TURBO on MPU and IVA domains.
Detect device requirements, and dynamically update the target ABB mode
for impacted OPPs.

This is a porting from TI Android 3.0 kernel, several code layers and
patches iterations from:
Mike Turquette <mturquette@ti.com>
Taras Kondratiuk <taras@ti.com>
Nishanth Menon <nm@ti.com>

Signed-off-by: Sebastien Jan <s-jan@ti.com>
OMAP4: ABB: enforce transition handling sequence

Enforce following policies wrt/ ABB:

1) ABB should be in bypass state during voltage scale:

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

So in abb_PRESCALE call ABB should be always put to bypass.
And then in abb_POSTSCALE call it can be configured to target state.

2) RBB can be enabled only after a SmartReflex convergence:

In case of SR 1.5 the fact that SR convergence is finished can be
easily checked by looking into calibrated voltage.
Unfortunatelly there is no simple solution for SR 3.0, so for now
this patch addresses only SR 1.5.

This is the porting of the following patch from TI Android k3.0:
5e9ba2be1 - OMAP3630+: PM: LDO: Change ABB handling sequence
Author: Mike Turquette <mturquette@ti.com>
... and also including contributions from Nishanth Menon <nm@ti.com>,
Axel Haslam <axelhaslam@ti.com>, Taras Kondratiuk <taras@ti.com>

Signed-off-by: Sebastien Jan <s-jan@ti.com>
OMAP4: LDO: LPDDR and Smart IO override for all units

This patch is to override LPDDR and Smart IO to the unique
recomended value LPDDR and Smart IO for all OMAP4 silicon revs
to avoid instabilities.

[nm@ti.com: cleanups for handling it without hacking in the code
into pm and voltage layer as these are specific quirk handling
for ldos]
Signed-off-by: Nishanth Menon <nm@ti.com>
Signed-off-by: Praneeth Bajjuri <praneeth@ti.com>
[s-jan@ti.com: rebase on k3.4]
Signed-off-by: Sebastien Jan <s-jan@ti.com>
OMAP4: trim quirk: Fix incorrect CPU revision check

Fix incorrect check CPU revision during check for eFUSE trim
as some early samples of CPUs revs ES 2.2 and ES 2.3 4430 and
4460s also need the "s/w workaround".

Since untrimmed parts are not really supposed to be seen on
the field, put a message on log to search for.

[nm@ti.com: pulled back into k3.0 from k35]
Signed-off-by: Nishanth Menon <nm@ti.com>
Signed-off-by: Volodymyr Riazantsev <x0153367@ti.com>
OMAP4: PM: restore the trim settings on OFF

S/w programmed trim overrides are lost in OFF mode. so reconfigure
the trim settings.

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

[s-jan@ti.com: rebase and adaptedt to k3.4]
Signed-off-by: Sebastien Jan <s-jan@ti.com>
OMAP4: trim_quirks: Update trim s/w override based on bgap

As per latest h/w recommendation, a unit with bandgap (bgap) trim bits different
from 0x0 is sufficient condition to determine if the LDO has been trimmed
even though VSET value is null.
Override the trim setting based on bgap register value.

Also, update CONTROL_EFUSE_[1/2] trim settings as per latest recommendation.

Signed-off-by: Girish S G <girishsg@ti.com>
OMAP4: trim_quirks: Use omap4_ctrl_pad_writel for setting PAD_CORE_EFUSE registers

omap_ctrl_writel uses omap4_globals->ctrl which is initialized to
OMAP443X_SCM_BASE (0x4a002000) while omap4_ctrl_pad_writel uses
omap4_globals->ctrl_pad initialized to OMAP443X_CTRL_BASE (0x4a100000)

To access the right CORE_CONTROL_EFUSE_x register, we should be using
the omap4_ctrl_pad_writel.

Change-Id: If3ac2743a3d2a0be722412f440397a00bdbb5819
Signed-off-by: Girish S G <girishsg@ti.com>
OMAP4: trim_quirks: optimize the override logic

trim override logic is used in suspend/resume path in addition
to init, by doing all the necessary checks at boot, we can
save ourselves the redundant checks on suspend path.

Signed-off-by: Nishanth Menon <nm@ti.com>
Signed-off-by: Sebastien Jan <s-jan@ti.com>
OMAP4: trim_quirks: remove redundant AVDAC override

AVDAC override is partially(and wrongly done) before being
updated with proper values. remove the redundant code.

Change-Id: I69e3af28cc132657660c7a2414f54b5d17b6e2e6
Signed-off-by: Nishanth Menon <nm@ti.com>
OMAP4: trim_quirks: update mpu_dpll trim override for new production lots

Newer production lots will have trim programmed in by default. we do not
need to put in s/w override for the lots. At the same time, we need to
detect on the fly if we are running on older lots and use trim override
if necessary h/w trim programmation was not done.

Change-Id: Id821324c6fb120218c752b0a7273d5e5811c098f
Signed-off-by: Nishanth Menon <nm@ti.com>
OMAP4: Correct Errata i684 WA

OMAP4470 not impacted of Errata i684.
Errata WA should not be applied for this CPU type.

Errata i684:
  Due to trimming program issue but also due to architecture limitation,
the LPDDR I/O and Smart I/O can not be trimmed correctly. The default
value in CONTROL_EFUSE_2 is not correct.

Workaround:
  For all units, the value of CONTROL_EFUSE_2 must be overwritten
with 0x00084000.

Change-Id: I7003d3097d3a8fdd3aa203513d1e9bf4582eee1d
Signed-off-by: Volodymyr Riazantsev <v.riazantsev@ti.com>
ARM: OMAP4470: DSS: AVDAC removed

The access to AVDAC registes was removed for OMAP4470.

Signed-off-by: K.Shlyakhovoy <x0155534@ti.com>
Change-Id: I4c3aa87cae8b2775f7ff2043679fd2f054754c0d
OMAP4: trim_quirks: Fix wrong implementation of erratum i684

OMAP4430 erratum i684:
Due to trimming program issue and a related architectural issue,
the LPDDR I/O and Smart I/O was not trimmed correctly on certain
OMAP4430 revisions. The default value in CONTROL_EFUSE_2 is not
correct and requires to be over-ridden by software.
Units with ProdID[51:50]=11 are not impacted by this issue.

Workaround:
For all affected OMAP4430 units, the value of CONTROL_EFUSE_2 must
be overwritten with 0x004E4000.

Current implementation impacts all OMAP4, hence the fix
restricts to implement the WA only for OMAP4430 affected units. The
wrong value overriden to SoCs not impacted such as OMAP4460 can
cause memory instability in samples as the override
trim value was purposed purely for erratum impacted samples.

Change-Id: I747181ce25eb2574e2b91b5a0a102c538f43b632
Signed-off-by: Konstantin Shlyakhovoy <x0155534@ti.com>
OMAP4: dpll: errata i700: Do not use DCC on omap4460 devices

CPU random hang can happen during 1.2 and 1.5 GHz OPP changes when DCC
is implied. This applies to OMAP4460, not OMAP4470.

for OMAP4460, disable DCC usage.
Rely on trimming for DPLL locking at 2.4GHz or 3GHz. For non-trimmed
units, apply a SW override up to 2.4GHz.

This is documented as errata i700.

Based these patches from TI Android kernel 3.0 tree:
0e8f21325 - ARM: omap4: dpll44xx: Don't use DCC at 1.2GHz
4746a1dbf - OMAP4: clock: Use DCC in 4470 for OPPs higher than 1GHz
by:
Vishwanath BS <vishwanath.bs@ti.com>
Colin Cross <ccross@android.com>
Taras Kondratiuk <taras@ti.com>

[s-jan@ti.com: porting to k3.4, update and rewording]
Signed-off-by: Sebastien Jan <s-jan@ti.com>
ARM: SDP4430: Fix HDMI display on Blaze

We need to have the HPD related GPIOs always requested so that
HPD detection can work.

Also, toggling HDMI OE pin using request/free_gpio is dumb.
The GPIO should infact be always reserved for HDMI use and OE must
be toggled using gpio_set_value(). The patch also adresses this.

Signed-off-by: Roger Quadros <rogerq@ti.com>
Panda: add cam2pwr regulator

Signed-off-by: Hervé Fache <h-fache@ti.com>
Panda: register regulators to resource manager

Signed-off-by: Hervé Fache <h-fache@ti.com>
CMA: removing buffers from LRU when migrating

based on the fix provided by Laura Abbott :
https://lkml.org/lkml/2012/8/31/313
remoteproc: fixing debugfs removal issue