gpio_key: Workaround for BN home button resume
-code from the Nook HD
Increase LCD refresh rate
Remove MMC_PM_KEEP_POWER from wl1271 mmc interface

This was a workaround for suspend/resume issues with wifi on, which
appear to have been solved by one or more of the various PM patches
that's gone into the kernel since.  Remove the workaround, which should
reduce system power consumption in suspend.
led: add early suspend to the led driver
boxer: updated boxer driver from Nook HD
issue resolved: the device may fail to reboot when "adb reboot" is executed
                and the display is off
encore: disable SmartReflex calibration for OPP5 when overclocking

It appears the SR class 1.5 calibration process itself is causing
problems for some users at the non-standard 1100/1200 MHz overclocks.
Disable the calibration process for OPP5, effectively locking the
voltage for that OPP to 1.375 V.
encore: bump OPP4 nominal voltage up a step when overclocking

This might possibly improve stability at 1 GHz for a handful of really
poor chips, and SmartReflex will ensure that it won't actually increase
the operating voltage for anyone who doesn't need it.
Revert "OMAP PM: Optimize cpufreq transition latency"

This has been reported to cause "PM: Device omap-dsp failed to suspend:
error -1" errors, and also appears to hurt GPU performance.

This reverts commit bfe1903ccee1009f13e6e7b38a81e5b168184930.
Revert "SmartReflex: use nominal voltage if safe + margin > nominal"

To be superseded by "OMAP3630+: SmartReflex 1p5: remove voltage clamp
down".

This reverts commit 2064279e23a728fbb810a6a6d5c5a81c77231af9.
OMAP3630+: SmartReflex 1p5: remove voltage clamp down

Vnom is almost never an exact multiple of PMIC voltage used.
Depending on age, process and PMIC used, it is possible that
the safe adjusted voltage after SR calibration and convergence
is higher than Vnom on few OPPs on certain corner lot samples.

By clamping down on voltage, we essentially force the voltage
to a lower than safe value which can result in not enough
margin on the sample for that specific OPP resulting in device
failures.

Change-Id: I6ce2d1a87a512364c9c278c84ebaa76f7575cf08
Reported-by: Michael Wagner <mwagner@ti.com>
Signed-off-by: Nishanth Menon <nm@ti.com>
OMAP3630+: PM: LDO: ABB: ensure transition complete

Currently when we configure ABB LDO, we do the following:
clear interrupt status
program new ABB
clear interrupt status

This does not guarentee that the ABB LDO has achieved the
desired configuration, and in cases where we are moving to
high performance OPP such as OPP NitroSB, this could result
in undeterministic failures on few corner lots.

Fix to ensure the right sequence as:
clear interrupt status
program new ABB
wait for interrupt
clear interrupt status (even if wait failed.)

Change-Id: Ida9320b9249a134f0ae33adf20ec2be81c806682
Reported-by: Vincent Bour <v-bour@ti.com>
Signed-off-by: Nishanth Menon <nm@ti.com>
SmartReflex 1p5: ensure SR-disable margin never gets added to voltage

Since c268e7f... ("OMAP3630+: SmartReflex 1p5: remove voltage clamp
down"), SmartReflex will gladly attempt to add any margin to the
SR-calibrated voltage -- even a "margin" which is really a value with
SR1P5_MARGIN_DISABLE_SR (the high bit) set.  This behavior should never
happen and has not been observed in the wild, but needless to say, could
potentially be disastrous.  Guard against it by refusing to use a margin
value with the SR1P5_MARGIN_DISABLE_SR flag set.
encore: fix DSP OPP4 when overclocking

The DSP OPPs should line up in voltage with the MPU OPPs, but currently,
when CONFIG_ENCORE_MPU_[12]00MHZ is enabled, the DSP's OPP4 ends up a
step above the MPU's OPP4 in voltage.  Fix this.
mmc: ifdef mmc_card_can_sleep
-mmc_card_can_sleep was ifdef'd in the .32 kernel
Revert "SmartReflex 1p5: ensure SR-disable margin never gets added to voltage"

We're reverting the commit which introduced the SR-disable margin.

This reverts commit 7f31b96313c83caa360c3face018a65b2851e4dc.
Revert "encore: disable SmartReflex calibration for OPP5 when overclocking"

XDA user samcoinc reported that recent kernels were crashing when
playing back video using the DSP and failing to resume from sleep.
Bisection identified this patch as the problem commit.

No obvious reason occurs to me as to why this patch is causing problems,
but reality trumps theory and stability at stock clocks is more
important than overclocking headroom in the stock kernel, so back it
out.

This reverts commit 847a54b50015f4bfa0cc8258f93d46d0fa49601d.