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: 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>

Conflicts:

	arch/arm/mach-omap2/cpuidle44xx.c
Code cleanup.

Conflicts:

	arch/arm/mach-omap2/opp4xxx_data.c
Variable GPU OC: sysfs interface to cycle through different top gpu speeds

- /sys/devices/system/cpu/cpu0/cpufreq/gpu_oc
- for now: 0 = 307mhz, 1 = 384mhz, 2 = 512mhz
- changes take effect immediately of course.

Conflicts:

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