Added kernel config option 'OMAP_OVERRIDE_MPUTRIM'.

Conflicts:
	arch/arm/mach-omap2/Kconfig

Conflicts:
	arch/arm/configs/tuna_ak_defconfig

Conflicts:
	arch/arm/configs/tuna_ak_defconfig
force enable this
build fix
omap2plus-cpufreq.c: only use maximum CPU overclock frequency if target frequency if above stock CPU maximum

If for example the highest CPU OPP (1.5 GHz) is enabled, all the below
frequencies are used as well, which increases the total number of
scaling steps and may hinder responsiveness. This patch only uses the
actual set maximum CPU frequency, if the requested frequency is above
the stock maximum frequency of 1.2 GHz.

Conflicts:
	arch/arm/mach-omap2/omap2plus-cpufreq.c
Revert "OMAP3630+: SmartReflex 1p5: remove voltage clamp down"

This reverts commit afadff82e7b2041498c95f266b76b21dda04e703.
smartreflex-class1p5: custom voltage: fix unusable voltage corridor for control fuses that are used for more than one OPP
Previously, when using volt_margins to differentiate voltages for different OPPs
using the same control fuse, the usage of the full voltage spectrum was barred.
This patch fixes the issue.

Signed-off-by: Boy Petersen <boypetersen@gmail.com>
OMAP4: PM: fix overconsumption on OFF mode

The wrong value of CM_L3INIT_CLKSTCTRL.CLKTRCTRL = 2 (SW_WKUP)
has been stored in SAR during omap4_sar_save() execution and
causes power over consumption on OFF mode due to C2C operation.
It happens because the L3INIT CD need to be enabled during
omap4_sar_save() execution for proper USBHOST module context storing.

Problematic use case:
1) OMAP goes to sleep,
2) modem wakeup the C2C, the EMIF but the MPU is still sleeping
(as expected)
3) Modem release all his constraints, C2C is turned to OFF.
4) but OMAP never reach again OFF while we don't wakeup the CPU
(by a keypress for example), sys_clk is already ON and voltages
are not equal to 0. (OPP 50 for CORE_3 and retention voltages
for both VCORE1 and VCORE2).

As WA overwrite CM_L3INIT_CLKSTCTRL.CLKTRCTRL = 0x1 (SW_SLEEP).

Change-Id: I2e453c07f61bab28a7213dd66044fd41a021961b
Signed-off-by: Arthur Cassegrain <a-cassegrain@ti.com>
Signed-off-by: Grygorii Strashko <grygorii.strashko@ti.com>

Patch Set 1
OMAP2+: clock: Fix DPLL clock rounding

Function omap2_dpll_round_rate() succeeds only if it can find exact frequency.
But in current implmentations there are some frequencies that can't be rounded.
Function iterates frequencies that always lower than requested one.
For example 550MHz can be obtain from 38.4MHz reference by M=1375 and N=96,
but the closest MN pair that is tried is 1374/96.

It happens because of flooring scaled_rt_rp variable insted of rounding.
This patch should fix the issue.

Change-Id: Iceadcc695ac3376372b2fdaf29afe8f9454b891f
Signed-off-by: Taras Kondratiuk <taras@ti.com>
OMAP2+: clock: Round clock to the closest possible frequency.

Currently clock is always rounded to frequency that is <= required.
It leads to not the best divider selection if requested frequncy is
slightly lower than the closest possible frequency.

This patch makes the best possible divider to be choosen.

Change-Id: I732dbf3e2c910b041434ded0df78dd6f85b7c7f4
Signed-off-by: Taras Kondratiuk <taras@ti.com>
omap2plus: cpufreq: Modify lpj recalculation logic

Somethimes "mdelay" function provide delay
that several times shorter than it should be.

This happens because recalculating lpj
performed after switching OPP. In this case,
for short period of time, when OPP on MPU
was switched but lpj was not recalculated,
"udelay" function can provide incorrect
delay - upto 5 times shorter
(if OPP was switched from lowest to highest).

This patch changes lpj recalculation logic to:
if OPP will be switched to higher - recalculate lpj before switching OPP,
if OPP will be switched to lower - recalculate lpj after switching OPP.

Change-Id: I3258e756c471fd0258a849d712ab00f4e1279ea9
Signed-off-by: Sergii Postulga <x0153364@ti.com>