fix for build
 fix for linaro
 env setup
Revert " env setup"

This reverts commit 3750d725f9de6453e934c2e6e3b7ba2b93132d62.
 env setup II
 Upstream from 3.0.93 to 3.0.94
Add lulzactiveq governor (tweaked)

credits to Gokhanmoral, Roberto, Tegrak and AndiP71
cpufreq & hotplug updates

CPU hotplug, writeback: Don't call writeback_set_ratelimit() too often 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>
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>
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>
YankasusQ governor

It's a one to one copy of PegasusQ with only a few parameters changed for now.

Main goal is to provide a playing ground for experimenting without "breaking" close to stockness by keeping PegasusQ unchanged
YankasusQ governor

Based on PegasusQ. Introducing cpu frequency limitations based on the number of cores online.

sysfs additions :

- cpu_max_freq_1 : max. freq. applied when running on 1 core (defaults to 1.0GHz)
- cpu_max_freq_2 : max. freq. applied when running on 2 cores (defaults to 1.1GHz)
- cpu_max_freq_3 : max. freq. applied when running on 3 cores (defaults to 1.2GHz)
- cpu_max_freq_4 : max. freq. applied when running on 4 cores (defaults to 1.4GHz)
- cpu_max_freq_current : currently applied max. frequency (read-only)

NB: hotplug frequencies and rq thresholds have been revised up to keep the device running on as little cores as possible.
YankasusQ governor updated

Based on PegasusQ. Introducing cpu frequency limitations based on the number of cores online, stanby frequency and online cores limitations.

sysfs additions :

- cpu_max_freq_stdby : max. freq. applied when screen off (defaults to 800MHz)
- max_cpu_lock_stdby : max. cores online when screen off (defaults to 1)

sysfs interface :

- cpu_max_freq_1 : max. freq. applied when running on 1 core (defaults to 1.0GHz)
- cpu_max_freq_2 : max. freq. applied when running on 2 cores (defaults to 1.1GHz)
- cpu_max_freq_3 : max. freq. applied when running on 3 cores (defaults to 1.2GHz)
- cpu_max_freq_4 : max. freq. applied when running on 4 cores (defaults to 1.4GHz)
- cpu_max_freq_current : currently applied max. frequency (read-only)

NB: hotplug frequencies and rq thresholds have been revised up to keep the device running on as little cores as possible.

Thanx to ZaneZam for inspiring me for these changes !
Added support for scaling_available_frequencies sysfs interface
block: ROW & blk-core

block: ROW: Correct minimum values of ROW tunable parameters

The ROW scheduling algorithm exposes several tunable parameters.
This patch updates the minimum allowed values for those parameters.

Change-Id: I5ec19d54b694e2e83ad5376bd99cc91f084967f5
Signed-off-by: Tatyana Brokhman <tlinder@codeaurora.org>
block: Add support for reinsert a dispatched req

Add support for reinserting a dispatched request back to the
scheduler's internal data structures.
This capability is used by the device driver when it chooses to
interrupt the current request transmission and execute another (more
urgent) pending request. For example: interrupting long write in order
to handle pending read. The device driver re-inserts the
remaining write request back to the scheduler, to be rescheduled
for transmission later on.

Add API for verifying whether the current scheduler
supports reinserting requests mechanism. If reinsert mechanism isn't
supported by the scheduler, this code path will never be activated.

Change-Id: I5c982a66b651ebf544aae60063ac8a340d79e67f
Signed-off-by: Tatyana Brokhman <tlinder@codeaurora.org>
block: add support for Linux 3.0.x for reinsert a dispatched req

Signed-off-by: Paul Reioux <reioux@gmail.com>
block: Add API for urgent request handling

This patch add support in block & elevator layers for handling
urgent requests. The decision if a request is urgent or not is taken
by the scheduler. Urgent request notification is passed to the underlying
block device driver (eMMC for example). Block device driver may decide to
interrupt the currently running low priority request to serve the new
urgent request. By doing so READ latency is greatly reduced in read&write
collision scenarios.

Note that if the current scheduler doesn't implement the urgent request
mechanism, this code path is never activated.

Change-Id: I8aa74b9b45c0d3a2221bd4e82ea76eb4103e7cfa
Signed-off-by: Tatyana Brokhman <tlinder@codeaurora.org>
block/blk-core: add support for Linux 3.0.x for urgent request handling

Signed-off-by: Paul Reioux <reioux@gmail.com>
row: Adding support for reinsert already dispatched req

Add support for reinserting already dispatched request back to the
schedulers internal data structures.
The request will be reinserted back to the queue (head) it was
dispatched from as if it was never dispatched.

Change-Id: I70954df300774409c25b5821465fb3aa33d8feb5
Signed-off-by: Tatyana Brokhman <tlinder@codeaurora.org>
block:row: fix idling mechanism in ROW

This patch addresses the following issues found in the ROW idling
mechanism:
1. Fix the delay passed to queue_delayed_work (pass actual delay
   and not the time when to start the work)
2. Change the idle time and the idling-trigger frequency to be
   HZ dependent (instead of using msec_to_jiffies())
3. Destroy idle_workqueue() in queue_exit

Change-Id: If86513ad6b4be44fb7a860f29bd2127197d8d5bf
Signed-off-by: Tatyana Brokhman <tlinder@codeaurora.org>
row: Add support for urgent request handling

This patch adds support for handling urgent requests.
ROW queue can be marked as "urgent" so if it was un-served in last
dispatch cycle and a request was added to it - it will trigger
issuing an urgent-request-notification to the block device driver.
The block device driver may choose at stop the transmission of current
ongoing request to handle the urgent one. Foe example: long WRITE may
be stopped to handle an urgent READ. This decreases READ latency.

Change-Id: I84954c13f5e3b1b5caeadc9fe1f9aa21208cb35e
Signed-off-by: Tatyana Brokhman <tlinder@codeaurora.org>
block: row: Add some debug information on ROW queues

1. Add a counter for number of requests on queue.
2. Add function to print queues status (number requests
   currently on queue and number of already dispatched requests
   in current dispatch cycle).

Change-Id: I1e98b9ca33853e6e6a8ddc53240f6cd6981e6024
Signed-off-by: Tatyana Brokhman <tlinder@codeaurora.org>
block: row: Insert dispatch_quantum into struct row_queue

There is really no point in keeping the dispatch quantum
of a queue outside of it. By inserting it to the row_queue
structure we spare extra level in accessing it.

Change-Id: Ic77571818b643e71f9aafbb2ca93d0a92158b199
Signed-off-by: Tatyana Brokhman <tlinder@codeaurora.org>
block: row: fix sysfs functions - idle_time conversion

idle_time was updated to be stored in msec instead of jiffies.
So there is no need to convert the value when reading from user or
displaying the value to him.

Change-Id: I58e074b204e90a90536d32199ac668112966e9cf
Signed-off-by: Tatyana Brokhman <tlinder@codeaurora.org>
block: row: Aggregate row_queue parameters to one structure

Each ROW queues has several parameters which default values are defined
in separate arrays. This patch aggregates all default values into one
array.
The values in question are:
 - is idling enabled for the queue
 - queue quantum
 - can the queue notify on urgent request

Change-Id: I3821b0a042542295069b340406a16b1000873ec6
Signed-off-by: Tatyana Brokhman <tlinder@codeaurora.org>
Version 0.1 - first release

Changelog:

       - codebase latest smoove governor version from midnight kernel (https://github.com/mialwe/mngb/)
       - modified frequency tables to match I9300 standard frequency range 200-1400 mhz
       - added cpu hotplug functionality with strictly cpu switching
         (modifications partially taken from ktoonservative governor from
         ktoonsez KT747-JB kernel https://github.com/ktoonsez/KT747-JB)
First commit. Adding a README.
Version 0.2 - improved

Changelog:

       - added tuneables to be able to adjust values on early suspend (screen off) via sysfs instead
         of using only hardcoded defaults
       - modified hotplug implementation to be able to tune threshold range per core indepentently
         and to be able to manually turn cores offline

         for this functions following new tuneables were indroduced:

         sampling_rate_sleep_multiplier -> sampling rate multiplier on early suspend (possible values 1 or 2, default: 2)
         up_threshold_sleep             -> up threshold on early suspend (possible range from above 'down_threshold_sleep' up to 100, default: 90)
         down_threshold_sleep           -> down threshold on early suspend (possible range from 11 to 'under up_threshold_sleep', default: 44)
         smooth_up_sleep                -> smooth up scaling on early suspend (possible range from 1 to 100, default: 100)
         up_threshold_hotplug1          -> hotplug threshold for cpu1 (0 disable core1, possible range from 'down_threshold' up to 100, default: 68)
         up_threshold_hotplug2          -> hotplug threshold for cpu2 (0 disable core2, possible range from 'down_threshold' up to 100, default: 68)
         up_threshold_hotplug3          -> hotplug threshold for cpu3 (0 disable core3, possible range from 'down_threshold' up to 100, default: 68)
         down_threshold_hotplug1        -> hotplug threshold for cpu1 (possible range from 11 to under 'up_threshold', default: 55)
         down_threshold_hotplug2        -> hotplug threshold for cpu2 (possible range from 11 to under 'up_threshold', default: 55)
         down_threshold_hotplug3        -> hotplug threshold for cpu3 (possible range from 11 to under 'up_threshold', default: 55)
Version 0.3 - more improvements

Changelog:

       - added tuneable 'hotplug_sleep' to be able to turn cores offline only on early suspend (screen off) via sysfs
         possible values: 0 do not touch hotplug-settings on early suspend, values 1, 2 or 3 are equivalent to
         cores which should be online at early suspend
       - modified scaling frequency table to match 'overclock' freqencies to max 1600 mhz
       - fixed black screen of dead problem in hotplug logic due to missing mutexing on 3-core and 2-core settings
       - code cleaning and documentation
Version 0.4 - limits

Changelog:

      - added 'soft'-freqency-limit. the term 'soft' means here that this is unfortuneately not a hard limit. a hard limit is only possible with
        cpufreq driver which is the freqency 'giver' the governor is only the 'consultant'. So now the governor will scale up to only the given up
        limit on higher system load but if the cpufreq driver 'wants' to go above that limit the freqency will go up there. u can see this for
        example with touchboost or wake up freqencies (1000 and 800 mhz) where the governor obviously will be 'bypassed' by the cpufreq driver.
        but nevertheless this soft-limit will now reduce the use of freqencies higer than given limit and therefore it will reduce power consumption.

        for this function following new tuneables were indroduced:

        freq_limit_sleep               -> limit freqency on early suspend (possible values 0 disable limit, 200-1600, default: 0)
        freq_limit                     -> limit freqency on awake (possible values 0 disable limit, 200-1600, default: 0)

      - added scaling frequencies to frequency tables for a faster up/down scaling. This should bring more performance but on the other hand it
        can be of course a little bit more power consumptive.

        for this function following new tuneables were indroduced:

        fast_scaling                   -> fast scaling on awake (possible values 0 disable or 1 enable, default: 0)
        fast_scaling_sleep (sysfs)     -> fast scaling on early suspend (possible values 0 disable or 1 enable, default: 0)

      - added tuneable 'freq_step_sleep' for setting the freq step at early suspend (possible values same as freq_step 0 to 100, default 5)
      - added DEF_FREQ_STEP and IGNORE_NICE macros
      - changed downscaling cpufreq relation to the 'lower way'
      - code/documentation cleaning
Version 0.5 - performance and fixes

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.

      for this functions following new tuneables were indroduced:

      Early Demand:
      -------------
      early_demand          -> switch to enable/disable early demand functionality (possible values 0 disable or 1 enable, default: 0)
      grad_up_threshold     -> scale up frequency if the load goes up in one step of grad up value (possible range from 11 to 100, default 50)
                               little example for understanding: when the load rises up in one big 50% step then the
                               frequency will be scaled up immediately instead of wating till up_threshold is reached.

      Fast Scaling (improved):
      ------------------------
      Fast scaling has now 8 levels which at the same time have 2 modes included. Values from 1-4 equals to scaling jumps in the frequency table
      and uses the Fast Scaling up but normal scaling down mode. Values from 5-8 equals to 1-4 scaling jumps but uses the fast scaling up and fast
      scaling down mode.

      Hotplugging switch:
      -------------------
      disable_hotplug       -> switch to enable/disable hotplugging (possible values are any value above 0 to disable hotplugging and 0 to
                               enable it, default 0)

      Sampling Down Factor and Sampling Down Momentum:
      ------------------------------------------------
      Description: From the original author of ondemand_sampling_factor David Niemi:
      'This improves performance by reducing the overhead of load evaluation and helping the CPU stay
      at its top speed when truly busy, rather than shifting back and forth in speed.'

      And that 'Sampling Down Momentum' function from stratosk does this dynamicly now! ;)

      sampling_down_max_momentum          -> max sampling down factor which should be set by momentum (0 disable momentum, possible range from
                                             sampling_down_factor up to MAX_SAMPLING_DOWN_FACTOR, default 0 disabled)
      sampling_down_momentum_sensitivity  -> how fast the sampling down factor should be switched (possible values from 1 to 500, default 50)
      sampling_down_factor                -> depending on which mode is active the factor for sampling rate multiplier which influences the whole
                                             sampling rate or the value for stock 'down skip' functionality which influences only the down scaling
                                             mechanism (possible values are from 1 to MAX_SMPLING_DOWN_FACTOR, default 1 disabled)

      Original conservative 'down skip' or 'stock' method can be enabled by setting the momentum tuneable to 0. so if momentum is inactive there will
      be a fallback to the stock method. as the name 'down skip' says this method works 'slightly' different from the ondemand stock sampling down method
      (on which momentum was based on). It just skips the scaling down code for the given samples. if u want to completely disable the sampling down
      functionality u can achieve this by setting sampling down factor to 1. so concluded: setting sampling_down_momentum = 0 and sampling_down_factor = 1
      will disable sampling down completely (that is also the governor default setting)

      Dynamic Screen Frequency Scaling:
      --------------------------------
      Dynamicly switches the screen frequency to 40hz or 60hz depending on cpu scaling and hotplug settings.
      For compiling and enabling this functionality u have to do some more modification to the kernel sources, please take a look at AndreiLux Perseus
      repository and there at following commit: https://github.com/AndreiLux/Perseus-S3/commit/3476799587d93189a091ba1db26a36603ee43519
      After adding this patch u can enable the feature by setting 'CPU_FREQ_LCD_FREQ_DFS=y' in your kernel config and if u want to check if it is
      really working at runtime u can also enable the accounting which AndreiLux added by setting LCD_FREQ_SWITCH_ACCOUNTING=y in the kernel config.
      If all goes well and u have the DFS up and running u can use following tuneables to do some screen magic:
      (thx to Yank555 for highly extend and improving this)

      lcdfreq_enable                     -> to enable/disable LCDFreq scaling (possible values 0 disable or 1 enable, default: 0)
      lcdfreq_kick_in_down_delay         -> the amount of samples to wait below the threshold frequency before entering low display frequency mode (40hz)
      lcdfreq_kick_in_up_delay           -> the amount of samples to wait over the threshold frequency before entering high display frequency mode (60hz)
      lcdfreq_kick_in_freq               -> the frequency threshold - below this cpu frequency the low display frequency will be active
      lcdfreq_kick_in_cores              -> the number of cores which should be online before switching will be active. (also useable in combination
                                            with kickin_freq)

      So this version is a kind of 'featured by' release as i took (again *g*) some ideas and work from other projects and even some of that work
      comes directly from other devs so i wanna thank and give credits:

      First of all to stratosk for his great work 'sampling down momentum' and 'early demand' and for all the code fixes which found their way into
      the upstream kernel version of conservative governor! congrats and props on that stratos, happy to see such a nice and talented dev directly
      contibuting to the upstream kernel, that is a real enrichment for all of us!

      Second to Yank555 for coming up with the idea and improving/completeing (leaves nothing to be desired now *g*) my first
      rudimentary implementation of Dynamic Screen Frequency Scaling from AndreiLux (credits for the idea/work also to him at this point).

      Third to DerTeufel1980 for his first implementation of stratosk's early demand functionality into version 0.3 of zzmoove governor
      (even though i had to modify the original implementation a 'little bit' to get it working properly ;)) and for some code optimizations/fixes
      regarding scaling.

      Last but not least again to ktoonsez - I 'cherry picked' again some code parts of his ktoonservative governor which should improve this governor
      too.
Version 0.5.1b - bugfixes and more optimisations (in cooperation with Yank555)

Changelog:

    - highly optimised scaling logic (thx and credits to Yank555)
    - simplified some tuneables by using already available stuff instead of using redundant code (thx Yank555)
    - reduced/optimised hotplug logic and preperation for automatic detection of available cores
      (maybe this fixes also the scaling/core stuck problems)
    - finally fixed the freezing issue on governor stop!