arch: arm: omap4: bump 307MHz GPU to 384MHz without increasing the voltages and add an extra OPP with 512MHz to compensate for the weak GPU and low memory bandwidth, which is, in this device's case, its major bottleneck.

Signed-off-by: franciscofranco <franciscofranco.1990@gmail.com>
sync.c: add a module_param to fsync() calls. fsync is still disabled by default but users will have the choice of having a faster build or a safer build (for data integrity). Props for simms for busting my ass off with this one :)
Increase the maximum temperature treshold.

Signed-off-by: franciscofranco <franciscofranco.1990@gmail.com>
omap4_trimp_quirks.c: enable trimp_override to allow >= 1.4Ghz frequencies without lagging the device

Signed-off-by: franciscofranco <franciscofranco.1990@gmail.com>
DPLL_CORE_M6_OPP100_RATE should be 266666666 -  from Ezekeel

Signed-off-by: franciscofranco <franciscofranco.1990@gmail.com>
arch: arm: omap4: use 1350MHz instead of 1200MHz without using more voltage.

Signed-off-by: franciscofranco <franciscofranco.1990@gmail.com>
Add C4 state again since TI guys added it to omapzoom - big props to Ezekeel that discovered this patch before and TI used it on their own official tree.
arch: arm: omap4: add rebased MPU frequencies; make it working with trim; set specifics when booting.

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

Signed-off-by: franciscofranco <franciscofranco.1990@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>
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>
omap4: cpuidle: Some obvious optimisations to the code path

Signed-off-by: franciscofranco <franciscofranco.1990@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: franciscofranco <franciscofranco.1990@gmail.com>
Revert "OMAP3630+: SmartReflex 1p5: remove voltage clamp down"

This reverts commit afadff82e7b2041498c95f266b76b21dda04e703.

Signed-off-by: franciscofranco <franciscofranco.1990@gmail.com>
Added simple sysfs interface to force adapters that are detected as
USB to charge as AC.

Signed-off-by: franciscofranco <franciscofranco.1990@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>

Conflicts:

	arch/arm/mach-omap2/omap2plus-cpufreq.c
Increase panel pixel clock.

Signed-off-by: franciscofranco <franciscofranco.1990@gmail.com>
drivers: wifi: add wifi_pm toggle.

Signed-off-by: franciscofranco <franciscofranco.1990@gmail.com>

Conflicts:

	drivers/net/wireless/bcmdhd/dhd_linux.c
Revert "DPLL_CORE_M6_OPP100_RATE should be 266666666 -  from Ezekeel"

This reverts commit a6e010dd4c5ed6aaf649579269d0e1694464e45a.
SMC errors fixed.

Signed-off-by: franciscofranco <franciscofranco.1990@gmail.com>