board-tuna-sensors.c: merge Kalim fix to toroplus compass bug.

Signed-off-by: franciscofranco <franciscofranco.1990@gmail.com>
Signed-off-by: Francisco Franco <franciscofranco.1990@gmail.com>
Signed-off-by: Dan Trifan <jimsth@gmail.com>
board-tuna-connector.c: fix a bug on the dock mode of this device. Originally reported by cynewulf - more information here: http://rootzwiki.com/topic/29281-howto-reenable-hdmi-mirroring-on-gnexus-portrait-dock-for-android-403-and-up/

Signed-off-by: franciscofranco <franciscofranco.1990@gmail.com>
Signed-off-by: Francisco Franco <franciscofranco.1990@gmail.com>
Signed-off-by: Dan Trifan <jimsth@gmail.com>
omap44xx: cpuidle: Update target residencies to saner values

The current values are insane.

There is no possible way power saving
can be attained by heading into C4 for not much more than 1ms. The average
values are in the 20ms range, so why do we need to even entertain entering
at much lower values when we will use more power than we save in doing so.

The actual recommended values are shown in 79e796f7b993bd82ad108fa488c35ddd1b9387eb
but for some obscure reason, in 16385c726d55f9e84bbc60ff9e329a84d56a13a3 and
22e2193661b6bffcfdc1a4d17f6af0d1782ba860 they were updated to match the exit_latency.

This seems horribly wrong to me as there comes a point when the target residency is
so low that you use more power actually entering the state than you gain from the
insignificant amount of time you spend there.

With the values in this commit, C4 state is used for >95% of the time when the screen
is off, with C3 picking up the remainder.
During audio playback, C4 is used ~50% of the time, C3 is used ~25% of the time and C2
picks up whatever is left.

Signed-off-by: franciscofranco <franciscofranco.1990@gmail.com>
Signed-off-by: Francisco Franco <franciscofranco.1990@gmail.com>
Signed-off-by: Dan Trifan <jimsth@gmail.com>
OMAP4: cpuidle: don't touch mpu and core state until CPU1 is off

MPU/Core logic and PD states shouldn't be changed until CPU1 is
completely off

Change-Id: Ia90126776e7bd7108c7b885c622df36323982cb0
Signed-off-by: Lianwei Wang <lian-wei.wang@motorola.com>
Signed-off-by: suilunlam <a0868997@ti.com>
Signed-off-by: Grygorii Strashko <grygorii.strashko@ti.com>
Signed-off-by: franciscofranco <franciscofranco.1990@gmail.com>
Signed-off-by: Dan Trifan <jimsth@gmail.com>
omap4: cpuidle: Some obvious optimisations to the code path

Signed-off-by: franciscofranco <franciscofranco.1990@gmail.com>
Signed-off-by: Dan Trifan <jimsth@gmail.com>
OMAP4: cpuidle: Add last_residency trace event for residency profiling

Signed-off-by: Dan Trifan <jimsth@gmail.com>
OMAP4: Workaround the OCP synchronisation issue with 32K synctimer.

Backport from:
http://git.kernel.org/?p=linux/kernel/git/tmlind/linux-omap.git;
a=commitdiff;h=68523f4233de5f233478dde0a63047b4efb710b8

Original comment:
On OMAP4, recently a synchronisation bug is discovered by hardware
team, which leads to incorrect timer value read from 32K sync timer
IP when the IP is comming out of idle.

The issue is due to the synchronization methodology used in the SYNCTIMER IP.
The value of the counter register in 32kHz domain is synchronized to the OCP
domain register only at count up event, and if the OCP clock is switched off,
the OCP register gets out of synch until the first count up event after the
clock is switched back -at the next falling edge of the 32kHz clock.

Further investigation revealed that it applies to gptimer1 and watchdog timer2
as well which may run on 32KHz. This patch fixes the issue for all the
applicable modules.

The BUG has not made it yet to the OMAP errata list and it is applicable to
OMAP1/2/3/4/5. OMAP1/2/3 it is taken care indirectly by autodeps.

By enabling static depedency of wakeup clockdomain with MPU, as soon as MPU
is woken up from lowpower state(idle) or whenever MPU is active, PRCM forces
the OCP clock to be running and allow the counter value to be updated properly
in the OCP clock domain.

The bug is going to fixed in future OMAP versions.

Change-Id: I3c7ff239c3dcac180fcae50c1b909d417b2b8e16
Reported-Tested-by: dave.long@linaro.org
[dave.long@linaro.org: Reported the oprofile time stamp issue with synctimer
and helped to test this patch]
Signed-off-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
Signed-off-by: Kevin Hilman <khilman@ti.com>
Signed-off-by: Andrii Tseglytskyi <andrii.tseglytskyi@ti.com>
(cherry picked from commit 73152a98a25392a451bb0d588a1fbe2796b3c909)

Signed-off-by: Dan Trifan <jimsth@gmail.com>
Added Custom Voltage version 3.

Signed-off-by: Dan Trifan <jimsth@gmail.com>

Conflicts:
	arch/arm/mach-omap2/omap2plus-cpufreq.c
	drivers/misc/Makefile

Signed-off-by: Dan Trifan <jimsth@gmail.com>
defconfig: enable custom voltage

Signed-off-by: Dan Trifan <jimsth@gmail.com>
Added Battery Life eXtender (BLX) version 1.

Signed-off-by: Dan Trifan <jimsth@gmail.com>
defconfig: enable BLX

Signed-off-by: Dan Trifan <jimsth@gmail.com>
arch: omap: add userspace export of the current GPU clock. Works mostly like scaling_cur_freq.

Signed-off-by: franciscofranco <franciscofranco.1990@gmail.com>
Signed-off-by: Francisco Franco <franciscofranco.1990@gmail.com>
Signed-off-by: Dan Trifan <jimsth@gmail.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>
Signed-off-by: Dan Trifan <jimsth@gmail.com>
omap2plus-cpufreq.c: Set cpuinfo.transition_latency = 30 * 1000

Signed-off-by: Dan Trifan <jimsth@gmail.com>
Add ROW I/O Scheduler by Qualcomm.

Signed-off-by: franciscofranco <franciscofranco.1990@gmail.com>
Signed-off-by: Francisco Franco <franciscofranco.1990@gmail.com>
Signed-off-by: Dan Trifan <jimsth@gmail.com>
block: row: fix compatibility with 3.0 Kernel code.

Signed-off-by: franciscofranco <franciscofranco.1990@gmail.com>
Signed-off-by: Francisco Franco <franciscofranco.1990@gmail.com>
Signed-off-by: Dan Trifan <jimsth@gmail.com>
defconfig: enable ROW

Signed-off-by: Dan Trifan <jimsth@gmail.com>
Added optimized ARM RWSEM algorithm.

Signed-off-by: Dan Trifan <jimsth@gmail.com>
Added optimized CRC32 algorithm.

Signed-off-by: Dan Trifan <jimsth@gmail.com>
defconfig: enable optimized RWSEM and CRC32 algorithms

Signed-off-by: Dan Trifan <jimsth@gmail.com>