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.
omap4: cpuidle: Some obvious optimisations to the code path
OMAP4: EMIF: code cleanup and clarification

Removed unused fields of emif_regs structure and
functions that initialize or change them.

Also changed few names of emif_regs members
to match register names.

This made the code easier to understand and read
as well as made it a little bit faster

Change-Id: I0485a01b7f03e922b5a2e69bfb03c2ed941fcf3b
Signed-off-by: Ruslan Bilovol <ruslan.bilovol@ti.com>
ARM: OMAP2+: clockdomain/hwmod: add workaround for EMU clockdomain idle problems

The idle status of the IP blocks and clocks inside the EMU clockdomain
isn't taken into account by the PRCM hardware when deciding whether
the clockdomain is idle.  Add a workaround flag in the clockdomain
code, CLKDM_MISSING_IDLE_REPORTING, to deal with this problem, and add
the code necessary to support it.

If CLKDM_MISSING_IDLE_REPORTING is set on a clockdomain, the
clockdomain will be forced active whenever an IP block inside that
clockdomain is in use, even if the clockdomain supports
hardware-supervised idle.  When the kernel indicates that the last
active IP block inside the clockdomain is no longer used, the
clockdomain will be forced idle, or, if that mode is not supported in
the hardware, it will be placed into hardware-supervised idle.

This patch is an equal collaboration with Jon Hunter
<jon-hunter@ti.com>.  Ming Lei <ming.lei@canonical.com>, Will Deacon
<will.deacon@arm.com>, Madhav Vij <mvij@ti.com>, Kevin Hilman
<khilman@ti.com>, Benoît Cousson <b-cousson@ti.com>, and Santosh
Shilimkar <santosh.shilimkar@ti.com> all made essential contributions
to the understanding of EMU clockdomain power management on OMAP.

[steven@steven676.net: squash in cf956d9 ("ARM: OMAP3: fix workaround
for EMU clockdomain")]

Signed-off-by: Paul Walmsley <paul@pwsan.com>
Cc: Jon Hunter <jon-hunter@ti.com>
Cc: Ming Lei <ming.lei@canonical.com>
Cc: Will Deacon <will.deacon@arm.com>
Cc: Madhav Vij <mvij@ti.com>
Cc: Kevin Hilman <khilman@ti.com>
Cc: Benoît Cousson <b-cousson@ti.com>
Cc: Santosh Shilimkar <santosh.shilimkar@ti.com>
Tested-by: Jon Hunter <jon-hunter@ti.com>
[steven@steven676.net: backport to p-android-omap3-3.0]
OMAP4: DPLL cascading: remove unused CM_SHADOW_FREQ_CONFIG2

The value from CM_SHADOW_FREQ_CONFIG2 can't be applied because
GPMC is always active and can't be entered in idle state.

The GPMC is always active because on OMAP4, CPU accesses on
unmapped addresses are redirected to GPMC by L3 interconnect.
CPU is speculative nature and such accesses are possible which
can lead to indirect access to GPMC and if it's clock is
not running, it can result in hang/abort on the platform.
See path d60565948468b for more information.

Change-Id: Ia62d8bf8c59ac3a06445b6f5f9e08ad0c9369c5b
Signed-off-by: Eugen Mandrenko <ievgen.mandrenko@ti.com>
OMAP PM: Optimize cpufreq transition latency

Currently cpufreq transition latency value does not really reflect the actual
OMAP OPP transition delay. This patch has the actual latency value.
I did profile the DVFS latency on OMAP3430, OMAP3630 and OMAP4 for worstcase(MPU and Core together) and found that in none of these platforms, transiton value
goes beyong 10ms. Added a buffer of 20ms to avoid too frequent ondemand timer
expiry.
With this change, performance of ondemand governor is improved when tested
using cpufreqbench tool. Without this patch, cpufreq-bench reported ondemand
performance as 40% of performance governor, and with this patch it's around 70%
(using below procedure).

cpufreq-bench:
http://lwn.net/Articles/339862/
http://ftp.riken.go.jp/archives/Linux/suse/people/ckornacker/cpufreq-bench/

Command used for performance testing:
cpufreq-bench -l 50000 -s 100000 -x 50000 -y 100000 -g ondemand -r 5 -n 5 -v

Signed-off-by: Vishwanath BS <vishwanath.bs@ti.com>
Dug-out-from-archives-by: Keyodi <zeusomighty@hotmail.com>
Found-in: http://lists.linaro.org/pipermail/linaro-dev/2010-November/001636.html
[steven@steven676.net: make apply to p-android-omap3-3.0]

Conflicts:

	arch/arm/mach-omap2/omap2plus-cpufreq.c