Skip to content


Subversion checkout URL

You can clone with
Download ZIP
Commits on Jul 25, 2014
  1. @PRJosh

    mach-exynos: cpufreq: Show list of available frequencies

    Donggeun Kim committed with PRJosh
    This patch enables 'scaling_available_frequencies' attribute
    showing list of available frequencies.
    Change-Id: I9b6ad786ffaaba8ad6fe5aa9045fd793c095b5ae
Commits on Jul 12, 2014
  1. @sbrissen

    smdk4412: update mali driver

    sbrissen committed with Gerrit Code Review
    from GT-N7100_SEA_KK_Opensource
    smdk4412: fix build
    smdk4412: fix kona bootloop
    Change-Id: I13b726da8d78d8d720d7e4f47343d793d131ab02
    Signed-off-by: Josue Rivera <>
  2. Fix CVE-2014-3153

    Thomas Gleixner committed with Gerrit Code Review
    futex-prevent-requeue-pi-on-same-futex.patch futex:
    Forbid uaddr == uaddr2 in futex_requeue(..., requeue_pi=1)
    If uaddr == uaddr2, then we have broken the rule of only requeueing from
    a non-pi futex to a pi futex with this call.  If we attempt this, then
    dangling pointers may be left for rt_waiter resulting in an exploitable
    This change brings futex_requeue() in line with futex_wait_requeue_pi()
    which performs the same check as per commit 6f7b0a2a5c0f ("futex: Forbid
    uaddr == uaddr2 in futex_wait_requeue_pi()")
    [ tglx: Compare the resulting keys as well, as uaddrs might be
      	different depending on the mapping ]
    Change-Id: Ibe6195215657c86bf2e39305656fdacf7230389d
    Reported-by: Pinkie Pie
    Signed-off-by: Will Drewry <>
    Signed-off-by: Kees Cook <>
    Signed-off-by: Thomas Gleixner <>
    Reviewed-by: Darren Hart <>
    Signed-off-by: Linus Torvalds <>
  3. @sbrissen

    smdk4412: cypress-touchkey - add keydisabler

    sbrissen committed with Gerrit Code Review
    Change-Id: I85efd4c5b2d6a7283c430f5eca2a730ef6b03d18
  4. @sbrissen

    synaptics_s7301: add disabling keypad

    sbrissen committed with Gerrit Code Review
    Change-Id: I5af258d2245024918f08a1a7c93c6efcc4d177b3
Commits on Jul 10, 2014
  1. @PRJosh

    N7100: Enable zzmoove and interactive

    PRJosh committed
    Change-Id: Ie95d7626ce62d49c10f62c6bf9709c3f642f75a0
    Signed-off-by: Josue Rivera <>
Commits on May 18, 2014
  1. @PRJosh

    Revert TouchWake squash

    PRJosh committed
      * Touch Wake seems to be causing strange problems while in call.
      * This squashes TouchWake reverts
    Revert "Touch Wake : bump to v1.1a ("
    This reverts commit d79606c.
    Revert "Touch Wake : bump to v1.1 ("
    This reverts commit 79d5690.
    Revert "Touch Wake : bump to v1.1  ("
    This reverts commit a64a770.
    Revert "Touch to wake: Different infinite mode handling (AndiP71)"
    This reverts commit 0ab93f1.
    Revert "Touch Wake : disabled if incall (fix)"
    This reverts commit e525e1c.
    Revert "Touch Wake implementation"
    This reverts commit f23449a.
    Change-Id: I42e846533389c8bd69fcb3fb5bf08103a869fe48
    Signed-off-by: Josue Rivera <>
  2. @nicklovell23 @PRJosh

    i925: Enable ZZMOVE governor

    nicklovell23 committed with PRJosh
    Change-Id: I27e4d294055d77b5577fc71b4a4e79b7b0cf0090
  3. @PRJosh

    Tolte & I9300: Enable ZZMOVE governor

    PRJosh committed
    Change-Id: Id2e1e28fe13c5c98ade5346edb0e36efb54b0a8d
    Signed-off-by: Josue Rivera <>
  4. @zanezam

    Version 0.8 - cool down baby

    zanezam committed with Gerrit Code Review
    - indroduced scaling block cycles (in normal and legacy mode) to reduce unwanted jumps to higher frequencies (how high depends on settings)
      when a load comes up just for a short peroid of time or is hitting the scaling up threshold more often because it is within some higher
      to mid load range. reducing these jumps lowers CPU temperature in general and may also save some juice. so with this function u can influence
      the little bit odd scaling behaving when you are running apps like for example games which are constantly 'holding' system load in
      some range and the freq is scaled up too high for that range. in fact it just looks like so, monitoring apps are mostly too slow to catch load in
      realtime so you are watching almost only 'the past'. so actually it's not really odd it's more like: an app is stressing the system and holding
      it on a higher load level, due to this load level scaling up threshold is more often reached (even if monitoring shows a lower load
      than up_threshold) the governor scales up very fast (usual zzmoove behaving) and almost never scales down again (even if monitoring shows
      a lower load than down_threshold). now in patricular these scaling block cycles are throttling up scaling by just skipping it
      for the amount of cycles that you have set up and after that are making a forced scale down in addition for the same amount of cycles. this
      should bring us down to a 'appropriate' frequency when load is hanging around near up threshold.
    - indroduced (D)ynamic (S)ampling (R)ate - thx to hellsgod for having the same idea at the same time and pointing me to an example. even though
      at the end i did 'my way' :) DSR switches between two sampling rates depending on the given load threshold from an 'idle' to a 'normal' one.
    - added read only tuneable 'sampling_rate_current' for DSR to show current SR and internally use this sampling rate instead of automatically
      changing 'sampling_rate' tuneable in DSR. this keeps things more compatible and avoids problems when governor tuneables are set with tuning
      apps which are saving actual shown values.
    - changed setting of sampling rate in governor from 'sampling_rate' to 'sampling_rate_current' and the value at suspend to 'sampling_rate_idle'
      value instead of using current active sampling rate to avoid accidentally setting of 'normal operation' sampling rate in sampling rate idle mode
      which has usually a much lower value
    - indroduced build-in profiles in seperate header file (credits to Yank555 for idea and prototype header file)
      you can switch between multible build in profiles by just piping a number into the tuneable 'profile_number'. all tuneable values of the set
      profile will be applied on-the-fly then. if a profile is active and you change any tuneable value from it to a custom one the profile will
      switch to '0' in 'profile_number' and 'custom' in 'profile' for information. with this profiles support developers can simplify their governor
      settings handling by adding all their desired and well proven governor settings into the governor itself instead of having to fiddle around with
      init.d scripts or tuning apps. NOTE: this is just an optional feature, you can still set all tuneables as usual just pay attention that the
      tuneable 'profile_number' is set to '0' then to avoid overwriting values by any build-in profile. for further details about profiles and
      adding own ones check provided 'cpufreq_zzmoove_profiles.h' file.
    - added 'profiles_version' tuneable to be able to show seperate profiles header file version
    - added enabling of offline cores on governor exit to avoid cores 'stucking' in offline state when switching to a non-hotplug-able governor
      and by the way reduced reduntant code by using an inline function for switching cores on and using the better 'sheduled_work_on-way'
      at all needed places in the code for that purpose
    - moved some code parts to legacy mode macro which has only relevance when including the legacy mode in the governor and in addition
      excluded it during runtime if legacy mode is disabled.
    - improved freq limit handling in tuneables and in dbs_check_cpu function
    - changed value restriction from '11' to '1' in hotplug down threshold and grad up tuneables as this restriction is only nessesary in
      scaling down tuneable
    - added missing fast scaling down/normal scaling up mode to fast scaling functionality (value range 9-12 and only available in non-legacy mode
      thx OldBoy.Gr for pointing me to that missing mode)
    - added auto fast scaling aka 'insane' scaling mode to fast scaling functionality - lucky number 13 enables this mode in fast_scaling tuneable
      NOTE: a really funny mode, try it :) but keep in mind setting this in combination with a set freq limit (at sleep or awake)would not make much
      sense as there is not enough frequency range available to jump around then.
    - back from the precautious 'mutex_try_lock' to normal 'mutex_lock' in governor 'LIMIT' case -> this should be save again,
      no deadlocks expected any more since hotplug logic has significantly changed in zzmoove version 0.6
    - removed also the no longer required and precautious skipping of hotplugging and dbs_check_cpu on multiple places in code and removed
      the mutex locks at governor stop and early suspend/late resume
    - added hotlug freq thresholds to legacy scaling mode (same usage as in normal scaling mode)
    - seperated hotplug down and up block cycles to be more flexible. this replaces 'hotplug_block_cycles' with 'hotplug_block_up_cycles' tuneable
      and adds one new tunable 'hotplug_block_down_cycles'. functionality is the same as before but u can now differentiate the up and down value.
    - added 'early demand sleep' combined with automatic fast scaling (fixed to scaling up mode 2) and if not set already automatic
      (depending on load) switching of sampling rate sleep multiplier to a fixed minimum possible multiplier of 2.
      this should avoid mostly audio or general device connection problems with 'resource hungrier' apps like some music players,
      skype, navigation apps etc. and/or in combination with using bluetooth equipment during screen is off.
      NOTE: this overwrites a possible fast 'scaling_sleep' setting so use either this or 'fast_scaling_sleep'
    - added some missing governor tunebable default value definitions
    - removed tuneable apply order exception and removed analog value checks in hotplug threshold and hotplug frequency tuneables to avoid
      tuneable values not changing issues. NOTE: keep in mind that all 'down' values should be lower then the analog 'up' values and vice versa.
    - removed 200 mhz up hotplugging restriction, so up hotplugging starts at 200 mhz now
    - removed some unnecessary macros in scaling logic
    - added maximum fast scaling and frequency boost to late resume to react wakeup lags
    - merged some improvements from ktoonservativeq governor version for the SGS4 (credits to ktoonsez)
      changes from here:
      Use dedicated high-priority workqueues
      Use NEW high-priority workqueue for hotplugging
      Improved hotplugging in general by reducing calls to plugging functions if they are currently running,
      by reducing calls to external function in up plugging and by changing the down plug loop to an optimized one
    - added hotplug boost switch to early demand functionality and up hotplugging function
    - added 'hotplug_idle_freq' tuneable to be able to adjust at which frequency idle should begin
    - transfered code for frequency table order detection and limit optimisation into a inline function
      and use this function in START,LIMIT case and early suspend/late resume instead of using redundant code
    - execute table order detection and freq limit optimization calculations at 'START' and 'LIMIT' case to avoid possible wrong setting of freq
      max after governor start (currently set max frequency value was sometimes not applied) and a wrong soft limit optimization setting
      after undercutting the soft limit with a lower hard limit value
    - minor optimisation in hotplug, hotplug block and in all freq search logic parts
    - added debugging sysfs interface (can be included/excluded using #define ZZMOOVE_DEBUG) - credits to Yank555
    - added some missing annotation as a prepareation and mainly to avoid some errors when compiling zzmoove in combination with 3.4+ kernel sources
    - fixed hotplugging issues when cpufreq limit was set under one or more hotplugging frequency thresholds
      NOTE: now hotplugging frequency thresholds will be completely disabled and a fall back to normal load thresholds will happen
      if the maximal possible frequency will undercut any frequency thresholds
    - fixed stopping of up scaling at 100% load when up threshold tuneable is set to the max value of 100
    - fixed smooth up not active at 100% load when smooth up tuneable is set to the max value of 100
    - fixed many code style and dokumentation issues and made a massive code re-arrangement
    for this functions following new tuneables were indroduced:
    early_demand_sleep -> same function as early demand on awake but in addition combined with fast scaling and sampling rate
    switch and only active at sleep. (possible values 0 disable or 1 enable, default is 1)
    grad_up_threshold_sleep -> 2 way functionality: early demand sleep grad up (load gradient) threshold and at the same time load threshold
    for switching internally (tuneables are staying at set values) sampling_rate_sleep_multiplier to 2 and
    fast_scaling to 2 (possible values from 1 to 100, default is 35)
    hotplug_block_up_cycles -> (replaces hotplug_block_cycles) slow down up hotplugging by waiting a given amount of cycles before plugging.
    possible values 0 disable, any values above 0 (default is 0)
    hotplug_block_down_cycles -> (replaces hotplug_block_cycles) slow down down hotplugging by waiting a given amount of cycles before plugging.
    possible values 0 disable, any values above 0 (default is 0)
    hotplug_idle_freq -> freq at which the idle should be active (possible values 0 disable and any possible scaling freq, default is 0)
    sampling_rate_current -> read only and shows currently active sampling rate
    sampling_rate_idle -> sampling rate which should be used at 'idle times'
    (possible values are any sampling rate > 'min_sampling_rate', 0 to disable whole function, default is 0)
    sampling_rate_idle_delay -> delay in cycles for switching from idle to normal sampling rate and vice versa
    (possible values are any value and 0 to disable delay, default is 0)
    sampling_rate_idle_threshold -> threshold under which idle sampling rate should be active
    (possible values 1 to 100, 0 to disable function, default is 0)
    scaling_block_cycles -> amount of gradients which should be counted (if block threshold is set) and at the same time up scaling should be
    blocked and after that a forced down scaling should happen (possible values are any value, 0 to disable that
    function, default is 0)
    scaling_bock_freq -> frequency at and above the blocking should be active
    (possible values are any possible scaling freq, 0 to enable blocking permanently at every frequency, default is 0)
    scaling_block_threshold -> gradient (min value) of load in both directions (up/down) to count-up cycles
    (possible value are 1 to 100, 0 to disable gradient counting)
    scaling_block_force_down -> multiplicator for the maximal amount of forced down scaling cycles (force down cycles = block_cycles * force_down)
    therefore the forced down scaling duration (possible value are 2 to any value, 0 to disable forced down scaling
    and use only scaling up blocks)
    profile -> read only and shows name of currently active profile ('none' = no profile, 'custom' = a profile value has changed)
    profile_number -> switches profile (possible value depends on amount of profiles in cpufreq_zzmoove_profiles.h file,
    please check this file for futher details) 0 no profile set = tuneable mode, default 0)
    version_profiles -> read only and shows version of profile header file
    if ZZMOOVE_DEBUG is defined:
    debug -> read only and shows various usefull debugging infos
    Change-Id: I575cd9a881d531201260341933207e2d7f7e4d46
  5. @zanezam

    Version 0.7d - broken things

    zanezam committed with Gerrit Code Review
        - fixed hotplug up threshold tuneables to be able again to disable cores manually via sysfs by setting them to 0
        - fixed the problem caused by a wrong tuneable apply order of non sticking values in hotplug down threshold tuneables when
          hotplug up values are lower than down values during apply.
          NOTE: due to this change right after start of the governor the full validation of given values to these tuneables is disabled till
          all the tuneables were set for the first time. so if you set them for example with an init.d script or let them set automatically
          with any tuning app be aware that there are illogical value combinations possible then which might not work properly!
          simply be sure that all up values are higher than the down values and vice versa. after first set full validation checks are enabled
          again and setting of values manually will be checked again.
        - fixed a typo in hotplug threshold tuneable macros (would have been only a issue in 8-core mode)
        - fixed unwanted disabling of cores when setting hotplug threshold tuneables to lowest or highest possible value
          which would be a load of 100%/11% in up/down_hotplug_threshold and/or scaling frequency min/max in up/down_hotplug_threshold_freq
    Change-Id: Ie4bbd0e5d1282efbf9995b84a7c0f75856c59760
  6. @zanezam

    Version 0.7c - again compatibility and optimisations

    zanezam committed with Gerrit Code Review
            - frequency search optimisation now fully compatible with ascending ordered system frequency tables (thx to psndna88 for testing)
            - again minor optimisations at multiple points in dbs_check_cpu function
            - code cleaning - removed some unnecessary things and whitespaces nuked (sry for the bigger diff but from now on it will be clean ;))
            - corrected changelog for previous version regarding limits
    Change-Id: Id20f14d03d64c06632aba7906a7d6dd11bbbff12
  7. @zanezam

    Version 0.7b - compatibility improved and forgotten things

    zanezam committed with Gerrit Code Review
            - fixed stuck at max scaling frequency when using stock kernel sources with unmodified cpufreq driver and without any oc capabilities.
            - readded forgotten frequency search optimisation in scaling logic (only effective when using governor soft frequency limit)
            - readded forgotten minor optimisation in dbs_check_cpu function
            - as forgotten to switch in last version Legacy Mode now again disabled by default
            - minor code format and comment fixes
    Change-Id: I8a1b6ad49b45eaaa2f64ef4298e56bf6908b8c94
  8. @zanezam

    Version 0.7a - little fix

    zanezam committed with Gerrit Code Review
            - fixed a glitch in hotplug freq threshold tuneables which prevented setting of values in hotplug down freq thresholds when hotplug
              up freq thresholds were set to 0
    Change-Id: I2d407de8ec8dc73ece244a9be0a76c086ef6129d
  9. @zanezam

    Version 0.7 - slow down (in cooperation with Yank555)

    zanezam committed with Gerrit Code Review
            - reindroduced the 'old way' of hotplugging and scaling in form of the 'Legacy Mode' (macros for enabling/disabling this done by Yank555, thx)
              NOTE: this mode can only handle 4 cores and a scaling max frequency up to 1800mhz.
            - added hotplug idle threshold for a balanced load at CPU idle to reduce possible higher idle temperatures when running on just one core.
              (inspired by JustArchi's observations, thx)
            - added hotplug block cycles to reduce possible hotplugging overhead (credits to ktoonsez)
            - added possibility to disable hotplugging only at suspend (inspired by a request of STAticKY, thx for the idea)
            - introduced hotplug frequency thresholds (credits to Yank555)
            - hotplug tuneables handling optimized (credits to Yank555)
            - added version information tuneable (credits to Yank555)
              for this functions following new tuneables were indroduced:
              legacy_mode                   -> for switching to the 'old' method of scaling/hotplugging. possible values 0 to disable,
                                               any values above 0 to enable (default is 0)
                                               NOTE: the legacy mode has to be enabled by uncommenting the macro ENABLE_LEGACY_MODE below
              hotplug_idle_threshold        -> amount of load under which hotplugging should be disabled at idle times (respectively at scaling minimum).
                                               possible values 0 disable, from 1 to 100 (default is 0)
              hotplug_block_cycles          -> slow down hotplugging by waiting a given amount of cycles before plugging.
                                               possible values 0 disbale, any values above 0 (default is 0)
              disable_hotplug_sleep         -> same as disable_hotplug but will only take effect at suspend.
                                               possible values 0 disable, any values above 0 to enable (default is 0)
              up_threshold_hotplug_freq1    -> hotplug up frequency threshold for core1.
                                               possible values 0 disable and range from over down_threshold_hotplug_freq1 to max scaling freqency (default is 0)
              up_threshold_hotplug_freq2    -> hotplug up frequency threshold for core2.
                                               possible values 0 disable and range from over down_threshold_hotplug_freq2 to max scaling freqency (default is 0)
              up_threshold_hotplug_freq3    -> hotplug up frequency threshold for core3.
                                               possible values 0 disable and range from over down_threshold_hotplug_freq3 to max scaling freqency (default is 0)
              down_threshold_hotplug_freq1  -> hotplug down frequency threshold for core1.
                                               possible values 0 disable and range from min saling to under up_threshold_hotplug_freq1 freqency (default is 0)
              down_threshold_hotplug_freq2  -> hotplug down frequency threshold for core2.
                                               possible values 0 disable and range from min saling to under up_threshold_hotplug_freq2 freqency (default is 0)
              down_threshold_hotplug_freq3  -> hotplug down frequency threshold for core3.
                                               possible values 0 disable and range from min saling to under up_threshold_hotplug_freq3 freqency (default is 0)
              version                       -> show the version of zzmoove governor
    Change-Id: Ia1d5ccef16a6fd04c53c93687309c3bda1836c51
  10. @zanezam

    Version 0.6a - scaling logic felxibility (in cooperation with Yank555)

    zanezam committed with Gerrit Code Review
      - added check if CPU freq. table is in ascending or descending order and scale accordingly
        (compatibility for systems with 'inverted' frequency table like it is on OMAP4 platform)
        thanks and credits to Yank555
    Change-Id: Iedad88e73d2011fd462f563533a6b0b769ebedf7
  11. @zanezam

    Version 0.6 - flexibility (in cooperation with Yank555)

    zanezam committed with Gerrit Code Review
           - removed fixed scaling lookup tables and use the system frequency table instead
             changed scaling logic accordingly for this modification (thx and credits to Yank555)
           - reduced new hotplug logic loop to a minimum
           - again try to fix stuck issues by using seperate hotplug functions out of dbs_check_cpu (credits to ktoonesz)
           - added support for 2 and 8 core systems and added automatic detection of cores were it is needed
             (for setting the different core modes you can use the macro 'MAX_CORES'. possible values are: 2,4 or 8, default are 4 cores)
             reduced core threshold defaults to only one up/down default and use an array to hold all threshold values
           - fixed some mistakes in 'frequency tuneables' (Yank555):
             stop looping once the frequency has been found
             return invalid error if new frequency is not found in the frequency table
    Change-Id: Ifa4d66f3ef87c3026c6fdee68b5ca77d7abcf402
  12. @zanezam

    Version 0.5.1b - bugfixes and more optimisations (in cooperation with…

    zanezam committed with Gerrit Code Review
    … Yank555)
        - 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!
    Change-Id: Icc0e495c0bff0d91f9a9db34131cbf086c47bfd8
  13. @zanezam

    Version 0.5 - performance and fixes

    zanezam committed with Gerrit Code Review
        - 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:
        - re-enabled broken conservative sampling down factor functionality ('down skip' method).
          originated by Stratosk - upstream kernel 3.10rc1:

        - changed down threshold check to act like it should.
          originated by Stratosk - upstream kernel 3.10rc1:

        - implemented/ported 'early demand' from ondemand governor.
          originated by Stratosk - more info:
        - implemented/ported 'sampling down momentum' from ondemand governor.
          originated by Stratosk - more info:
        - modified some original conservative code parts regarding frequency scaling which should work better now.
          originated by DerTeufel1980: DerTeufel/android_kernel_samsung_smdk4412@6bab622
        - 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 : ktoonsez/KT747-JB@a5931be
          description in lulzactive governor:

        - 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: AndreiLux/Perseus-S3@3476799
          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
    Change-Id: I082c6658994769d60664ec4bba65adce471188c9
  14. @zanezam

    Version 0.4 - limits

    zanezam committed with Gerrit Code Review
          - 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
    Change-Id: I7ad37573a184e75127250d8b72ea924a949f8291
  15. @zanezam

    Version 0.3 - more improvements

    zanezam committed with Gerrit Code Review
           - 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
    Change-Id: I58608938f01cf84574bb892d5bd78f56894e6c9e
  16. @zanezam

    Version 0.2 - improved

    zanezam committed with Gerrit Code Review
           - 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)
    Change-Id: If4afa0cf75bf007f09efec42e094a82b5319a312
  17. @zanezam

    Version 0.1 - first release

    zanezam committed with Gerrit Code Review
           - codebase latest smoove governor version from midnight kernel (
           - 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
    Change-Id: Ic00efb4c9acbcf01500e49b0eb32c0caa4f3b244
    Signed-off-by: Josue Rivera <>
  18. @PRJosh

    T0lte & I9300: Set default governer to Interactive

    PRJosh committed
    Change-Id: I809ed8a9faa7fe7ae363d882a001ed1dbe3460f1
    Signed-off-by: Josue Rivera <>
Commits on May 12, 2014
  1. @PRJosh

    Smdk4412: Re-add I777 audio hack

    PRJosh committed with Gerrit Code Review
      * I777 microphone configuration is swapped compared to I9100
      * It was reverted in the update sound soc and codecs from i9305 drop
    Change-Id: Id9260effeb28e383b4a31e76d36a7ccf4b4ef832
    Signed-off-by: Josue Rivera <>
Commits on May 9, 2014
  1. @nicklovell23

    Add Slim_i925

    nicklovell23 committed
    Change-Id: I6cdb5f3d335a7f6d054cd474e8e5bb86c172d40c
Commits on May 7, 2014
  1. @yank555-lu

    cypress-touchkey : add sysfs interface to enable/disable lighting har…

    yank555-lu committed with Gerrit Code Review
    …dwarekey backlight on screen touch (
    - prevent h/w keys to light up on late_resume as well if disabled
    Change-Id: I2e9f6a32579cdb43f9d8f2e5b1751af19d008a60
  2. @yank555-lu

    cypress-touchkey : add sysfs interface to enable/disable lighting har…

    yank555-lu committed with Gerrit Code Review
    …dwarekey backlight on screen touch (
    Change-Id: I363fa3e92140a5028dcb45e784dac87d1db64fac
  3. @PRJosh

    Revert "cypress-touchkey: remove backlight timeout feature"

    PRJosh committed with Gerrit Code Review
      * We still use device settings
    This reverts commit a64df5b.
    Change-Id: Ia5d4b44b1627d4c4e965f7a5514de9c8932ff4f3
    Signed-off-by: Josue Rivera <>
  4. @markcs

    smdk4412: update sound soc and codecs

    markcs committed with Gerrit Code Review
    Includes updated kernel source from i9305
    Change-Id: I91ae18b30d02de037701250c46a457d035da56e1
  5. dm crypt: optionally support discard requests

    Milan Broz committed with Gerrit Code Review
    Add optional parameter field to dmcrypt table and support
    "allow_discards" option.
    Discard requests bypass crypt queue processing. Bio is simple remapped
    to underlying device.
    Note that discard will be never enabled by default because of security
    consequences.  It is up to the administrator to enable it for encrypted
    (Note that userspace cryptsetup does not understand new optional
    parameters yet.  Support for this will come later.  Until then, you
    should use 'dmsetup' to enable and disable this.)
    Change-Id: I915777ae6022ae0f75804a40f1f32a1cf33a444a
    Signed-off-by: Milan Broz <>
    Signed-off-by: Alasdair G Kergon <>
  6. @snitm

    dm table: share target argument parsing functions

    snitm committed with Gerrit Code Review
    Move multipath target argument parsing code into dm-table so other
    targets can share it.
    Change-Id: I2502ec126cedd2f661c2a489f89cf096d0243460
    Signed-off-by: Mike Snitzer <>
    Signed-off-by: Alasdair G Kergon <>
  7. dm: ignore merge_bvec for snapshots when safe

    Mikulas Patocka committed with Gerrit Code Review
    Add a new flag DMF_MERGE_IS_OPTIONAL to struct mapped_device to indicate
    whether the device can accept bios larger than the size its merge
    function returns.  When set, use this to send large bios to snapshots
    which can split them if necessary.  Snapshot I/O may be significantly
    fragmented and this approach seems to improve peformance.
    Before the patch, dm_set_device_limits restricted bio size to page size
    if the underlying device had a merge function and the target didn't
    provide a merge function.  After the patch, dm_set_device_limits
    restricts bio size to page size if the underlying device has a merge
    function, doesn't have DMF_MERGE_IS_OPTIONAL flag and the target doesn't
    provide a merge function.
    The snapshot target can't provide a merge function because when the merge
    function is called, it is impossible to determine where the bio will be
    remapped.  Previously this led us to impose a 4k limit, which we can
    now remove if the snapshot store is located on a device without a merge
    function.  Together with another patch for optimizing full chunk writes,
    it improves performance from 29MB/s to 40MB/s when writing to the
    filesystem on snapshot store.
    If the snapshot store is placed on a non-dm device with a merge function
    (such as md-raid), device mapper still limits all bios to page size.
    Change-Id: I7f53e7200c9587a9c13acf97b87e93df7e4ea79b
    Signed-off-by: Mikulas Patocka <>
    Signed-off-by: Alasdair G Kergon <>
  8. @kergon

    dm: suppress endian warnings

    kergon committed with Gerrit Code Review
    Suppress sparse warnings about cpu_to_le32() by using __le32 types for
    on-disk data etc.
    Change-Id: I999de9d2966d16cebe8a06a226c02f2785f95927
    Signed-off-by: Alasdair G Kergon <>
Commits on May 5, 2014
  1. @tejkkarani

    Add Support For Note 8.0 (n5100/n5110/n5120)

    tejkkarani committed
    Change-Id: I20baadecbc8eb1be76ed79b685c37fbfd60853dc
Something went wrong with that request. Please try again.