Revert "OMAP PM: Optimize cpufreq transition latency"

It's causing "PM: Device omap-dsp failed to suspend: error -1"
when ondemand is used.

This reverts commit c5f5b3706fb836ebd770c26e1e8724045bd04355.
drivers: input: yamaha: dont't change device position in sysfs tree
latona: power: don't detect full charge with CHG_ING GPIO

CHG_ING is high when the battery is fully charged, but we
may want to stop charging before that.
Fix also the recharging conditions to prevent too frequent
battery recharges which were previously limited by CHG_ING.
latona: power: set low SOC alert threshold properly
drivers: max17040: use adjusted soc values only for uevents
omapfb: allow to show a progress bar on boot
omapfb: progressbar: tweak for latona

Make the progressbar faster when booting to recovery and don't show
it at all when booting to charging mode.
defconfig: show progressbar on boot
ARM: OMAP3+: Implement timer workaround for errata i103 and i767

Errata Titles:
i103: Delay needed to read some GP timer, WD timer and sync timer
      registers after wakeup (OMAP3/4)
i767: Delay needed to read some GP timer registers after wakeup (OMAP5)

Description (i103/i767):
If a General Purpose Timer (GPTimer) is in posted mode
(TSICR [2].POSTED=1), due to internal resynchronizations, values read in
TCRR, TCAR1 and TCAR2 registers right after the timer interface clock
(L4) goes from stopped to active may not return the expected values. The
most common event leading to this situation occurs upon wake up from
idle.

GPTimer non-posted synchronization mode is not impacted by this
limitation.

Workarounds:
1). Disable posted mode
2). Use static dependency between timer clock domain and MPUSS clock
    domain
3). Use no-idle mode when the timer is active

Workarounds #2 and #3 are not pratical from a power standpoint and so
workaround #1 has been implemented. Disabling posted mode adds some CPU
overhead for configuring and reading the timers as the CPU has to wait
for accesses to be re-synchronised within the timer. However, disabling
posted mode guarantees correct operation.

Please note that it is safe to use posted mode for timers if the counter
(TCRR) and capture (TCARx) registers will never be read. An example of
this is the clock-event system timer. This is used by the kernel to
schedule events however, the timers counter is never read and capture
registers are not used. Given that the kernel configures this timer
often yet never reads the counter register it is safe to enable posted
mode in this case. Hence, for the timer used for kernel clock-events,
posted mode is enabled by overriding the errata for devices that are
impacted by this defect.

For drivers using the timers that do not read the counter or capture
registers and wish to use posted mode, can override the errata and
enable posted mode by making the following function calls.

	__omap_dm_timer_override_errata(timer, OMAP_TIMER_ERRATA_I103_I767);
	__omap_dm_timer_enable_posted(timer);

Both dmtimers and watchdogs are impacted by this defect this patch only
implements the workaround for the dmtimer. Currently the watchdog driver
does not read the counter register and so no workaround is necessary.

Posted mode will be disabled for all OMAP2+ devices (including AM33xx)
using a GP timer as a clock-source timer to guarantee correct operation.
This is not necessary for OMAP24xx devices but the default clock-source
timer for OMAP24xx devices is the 32k-sync timer and not the GP timer
and so should not have any impact. This should be re-visited for future
devices if this errata is fixed.

Confirmed with Vaibhav Hiremath that this bug also impacts AM33xx
devices.

Signed-off-by: Jon Hunter <jon-hunter@ti.com>
Acked-by: Santosh Shilimkar <santosh.shilimkar@ti.com>

Change-Id: Id10648050492d8c91ea22093127584f02ec3655b
usb:gadget:android: avoid sending extra uevents

Don't schedule a uevet from android_disconnect
if there is no change in the connection state
and if the DISCONNECT event was already sent.
This patch will avoid these unecessary messages:

android_work: did not send uevent (0 0   (null))

Change-Id: I074d9fb712a18b2f805d4e46a4f6a5412b682ffe
Signed-off-by: Moiz Sonasath <m-sonasath@ti.com>
Signed-off-by: Arun Joseph <arunjoseph@ti.com>
Revert "OMAP:DSS: SW workaround for HW scaler overread issue"

This reverts commit 0e11c5b311d2c7436756f80c35c8aef4cd0d911b.

The SW workaround is no longer needed as a hardware workaround
exists, and the SW workaround created artifacts.

Change-Id: I5d8a601b24502a3ac5d4c1f17fcb3936ba8e7e10
Signed-off-by: Sathya Prakash M R <a0393677@ti.com>
Signed-off-by: Lajos Molnar <lajos@ti.com>
mach: opp: re-enable L3 OPP1 for latona

It's not causing any issue, there's no need to disable it.
mmc: port changes from latona 2.6.35 [1/2]
mmc: port changes from latona 2.6.35 [2/2]
mmc: card: Skip secure erase on MoviNAND; causes unrecoverable corruption.

commit 3550ccdb9d8d350e526b809bf3dd92b550a74fe1 upstream.

For several MoviNAND eMMC parts, there are known issues with secure
erase and secure trim.  For these specific MoviNAND devices, we skip
these operations.

Specifically, there is a bug in the eMMC firmware that causes
unrecoverable corruption when the MMC is erased with MMC_CAP_ERASE
enabled.

References:

http://forum.xda-developers.com/showthread.php?t=1644364
https://plus.google.com/111398485184813224730/posts/21pTYfTsCkB#111398485184813224730/posts/21pTYfTsCkB

Signed-off-by: Ian Chen <ian.cy.chen@samsung.com>
Reviewed-by: Namjae Jeon <linkinjeon@gmail.com>
Acked-by: Jaehoon Chung <jh80.chung@samsung.com>
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Chris Ball <cjb@laptop.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
[steven@steven676.net: make apply to 3.0]
Patch the firmware of certain Samsung emmc parts to fix a bug

Patch the firmware in certain Samsung emmc chips after every power-on
to workaround a bug in the wear leveling code.  Patch provided by Samsung
Semiconductor, and the code to apply the patch was originally written
by Jeonghwan Min of Samsung.

Change-Id: Id40cfb8f68842fc4a47f60ae032f1b49c0fcb65e
Signed-off-by: Ken Sumrall <ksumrall@android.com>
omapfb: start drawing the progressbar on display init
omapfb: progressbar: update
latona: vibrator: add missing omap_dm_timer_disable

It was preventing core_pwrdm from entering target state 0.
Merge branch 'jellybean' of git://github.com/sconosciuto/android_kernel_samsung_latona-3.0 into cm-10.2

Signed-off-by: David Rodero <david@codiguiel.net>

Conflicts:
	drivers/mmc/core/mmc.c
	drivers/mmc/core/quirks.c
	include/linux/mmc/card.h

Change-Id: Ib8a9c5db054c8110885defbbd83785c9e572f3f6