display: capability for CPU frequency based LCD freq scaling - credits to AndreiLux

Signed-off-by: ZaneZam <cyxman@yahoo.com>
cpufreq: zzmoove governor v0.5

Changelog:

- completely reworked fast scaling functionality. now using a 'line jump' logic instead of fixed freq 'colums'.
  fast scaling now in 4 steps and 2 modes possible (mode 1: only fast scaling up and mode2: fast scaling up/down)
- added support for 'Dynamic Screen Frequency Scaling' (original implementation into zzmoove governor highly improved by Yank555)
  originated by AndreiLux more info: http://forum.xda-developers.com/showpost.php?p=38499071&postcount=3
- re-enabled broken conservative sampling down factor functionality ('down skip' method).
  originated by Stratosk - upstream kernel 3.10rc1:
  https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/log/?id=refs%2Ftags%2Fv3.10-rc1&qt=author&q=Stratos+Ka
- changed down threshold check to act like it should.
  originated by Stratosk - upstream kernel 3.10rc1:
  https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/log/?id=refs%2Ftags%2Fv3.10-rc1&qt=author&q=Stratos+Ka
- implemented/ported 'early demand' from ondemand governor.
  originated by Stratosk - more info: http://www.semaphore.gr/80-latests/98-ondemand-early-demand
- implemented/ported 'sampling down momentum' from ondemand governor.
  originated by Stratosk - more info: http://www.semaphore.gr/80-latests/80-sampling-down-momentum
- modified some original conservative code parts regarding frequency scaling which should work better now.
  originated by DerTeufel1980: https://github.com/DerTeufel/android_kernel_samsung_smdk4412/commit/6bab622344c548be853db19adf28c3917896f0a0
- added the possibility to use sampling down momentum or conservative 'down skip' method.
- increased possible max sampling rate sleep multiplier to 4 and sampling down factor to 100000
  accordingly to sampling down momentum implementation.
- added frequency search limit for more efficient frequency searching in scaling 'table' and for improving
  frequency 'hard' and 'soft' limit handling.
- added cpu idle exit time handling like it is in lulzactive
  again work from ktoonsez : https://github.com/ktoonsez/KT747-JB/commit/a5931bee6ea9e69f386a340229745da6f2443b78
  description in lulzactive governor:
  https://github.com/ktoonsez/KT747-JB/blob/a5931bee6ea9e69f386a340229745da6f2443b78/drivers/cpufreq/cpufreq_lulzactive.c
- fixed a little scaling step mistake and added overclocking frequencies up to 1800 mhz in scaling frequency 'tables'.
- fixed possible freezes during start/stop/reload of governor and frequency limit change.
- fixed hotplugging logic at online core 0+3 or 0+2 situations and improved hotplugging in general by
  removing mutex locks and skipping hotplugging when it is not needed.
- added possibility to disable hotplugging (that's a debugging relict but i thought maybe someone will find that usefull so i didn't remove it)
- try to fix lags when coming from suspend if hotplug limitation at sleep was active by enabling all offline cores during resume.
- code cleaning and documentation.

Signed-off-by: ZaneZam <cyxman@yahoo.com>
boeffla ramfs: zzmoove governor v0.5 init scripts

Signed-off-by: ZaneZam <cyxman@yahoo.com>
cpufreq: Resolve CPUFREQ_NOTIFY issue

When the cpufreq_stat receives the frequency policy notification,
it checks if the frequency table and stats table are present for the cpu.
If both are present, it returns with -EBUSY error to the notification.
Due to this, none of the other registered modules receive this
notification.

If the stat table and sysfs nodes are already created, return 0 instead
of returning EBUSY error.

Change-Id: I1fd4a46e6a65edfc6253c4271288f10912ae2ad7
Signed-off-by: Archana Sathyakumar <asathyak@codeaurora.org>
Signed-off-by: ZaneZam <cyxman@yahoo.com>
cpufreq: Retain only online cpus in managed_policy->cpus

cpufreq's handling of cpu online event can incorrectly initialize
managed_policy->cpus to include offline cpus. This causes cpufreq
governors to include offline cpus in their idle time computation, which
causes frequency to shoot up beyond normal levels (on systems where 2 or
more cpus need to be synchronized wrt frequency change).

This frequency shootup was not seen prior to commit 21111be8 which
changed idle time accounting for offline cpus. Prior to commit 21111be8,
idle time statistics for offline cpus would include their offline time
as well. Post commit 21111be8, offline time is not included in a cpu's
idle time statistics.

As a result, ondemand (or other cpufreq) governors would see unchanged
idle time for offline cpus, causing them to interpret those (offline)
cpus as 100% busy, which is wrong.

This patch fixes the issue by modifying cpufreq's hotplug handling to
retain only online cpus in managed_policy->cpus field. cpufreq governors
would then skip such offline cpus from idle time calculations.

Change-Id: Id2eba8c0ec3367609369b2e42a4e1386ff2e7ab5
Signed-off-by: Srivatsa Vaddagiri <vatsa@codeaurora.org>
Signed-off-by: ZaneZam <cyxman@yahoo.com>
CPU hotplug, writeback: Don't call writeback_set_ratelimit() too ofte… …n during hotplug

The CPU hotplug callback related to writeback calls writeback_set_ratelimit()
during every state change in the hotplug sequence. This is unnecessary
since num_online_cpus() changes only once during the entire hotplug operation.

So invoke the function only once per hotplug, thereby avoiding the
unnecessary repetition of those costly calculations.

Change-Id: I9d13e74a60632bf079faebb80477ce86121f1a8c
Signed-off-by: Srivatsa S. Bhat <srivatsa.bhat@linux.vnet.ibm.com>
Signed-off-by: Francisco Franco <franciscofranco.1990@gmail.com>
Signed-off-by: ZaneZam <cyxman@yahoo.com>