[Galaxy S III Android Development] ZaneZam:
CPU Governor ZZMoove Changelog

ZZMoove Governor 0.8

(cool down baby!)

Changelog:

- 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 [MENTION=5071121]OldBoy.Gr[/MENTION] 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: https://github.com/ktoonsez/KT-SGS4/commits/aosp4.4/drivers/cpufreq/cpufreq_ktoonservativeq.c

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 disbale, 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 disbale, 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_freg -> 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

ZZMoove Governor 1.0 Final

(EOL)

Changelog:

EOL commit: https://github.com/zanezam/cpufreq-governor-zzmoove/commit/b22eed13461fbb59b8e9e0121656582d6ef10696

Governor: https://github.com/zanezam/cpufreq-governor-zzmoove/blob/snapdragon/CHANGELOG.txt

Profiles: https://github.com/zanezam/cpufreq-governor-zzmoove/blob/snapdragon/CHANGELOG_PROFILES.txt

Current Test-Versions (obsolete but kept for reference):

Version 1.0 beta8

(outbreak)

Changelog:

https://github.com/zanezam/cpufreq-governor-zzmoove/commit/bef4355a652fdfc268b774e874b355bd269dbc07

Version 1.0 beta7a (bugfix)

(outbreak)

Changelog:

https://github.com/zanezam/cpufreq-governor-zzmoove/commit/1ce22579b0e6dfce0d9916b9f0644e7d707d8587

Version 1.0 beta7 (sync)

(outbreak)

Changelog:

https://github.com/zanezam/cpufreq-governor-zzmoove/commit/52ad61b169c24258ec1b0e6a630bbab5142faa67

Version 1.0 beta6a (Andip71 aka Lord Boeffla)

(outbreak)

Changelog (credits to Andip71):

https://github.com/zanezam/cpufreq-governor-zzmoove/commit/9b01250eb988e86c98d289dabe6773ba748f58dd

Version 1.0 beta6 (feature preview, for opo only atm.)

(outbreak)

Changelog:

https://github.com/zanezam/cpufreq-governor-zzmoove/commit/75c431aeff8354f224e4c688faa1559ac463ab8a

Version 1.0 beta5

(outbreak)

Changelog:

https://github.com/zanezam/cpufreq-governor-zzmoove/commit/1d2727cb9cefe0484573ace9e0dc9b55ba6c26f6

Version 1.0 beta4 (sync)

(outbreak)

Changelog:

- use again the conservative governor usual canceling of dbs work syncron instead of asyncron when exiting the governor as this change was

only needed in combination with older hotplug implementations. as also done in opo version removed again all previously merged kernel crash

fix attempts and precautions as they were not really needed

- bump version to beta4 to bring opo/i9300 versions in sync again

Version 1.0 beta3 (bugfix for opo-bacon)

(outbreak)

Changelog:

- changed back canceling of dbs work to syncron instead of asyncron in dbs_timer_exit function to avoid random kernel chrashes (again oops in smp.c)

when using this governor with the cpufreq implementation of kernel versions 3.10+. problem was initiated by governor restarts during hotplugging

- as an additional precaution check if a core is online before doing critical stuff in dbs_check_cpu main function (might be removeable at a later

time, more analyses/tests will show)

profile header file (Version 0.3 beta2 OPO)

- corrected/adjusted sampling rate values in settings where they were lower than the minimal possible value of 60000

Version 1.0 beta2

(outbreak)

Changelog:

- avoid kernel crash (usually a oops in smp.c) by checking if a core is online before putting work on it: this problem appeared on opo qualcomm

platform with proprietary mpdecision hotplugging service. assumption is that there is a delay between initiating hotplugging events from 'userland'

and gathering core state info in 'kernel land' so under some rare circumestances the governor doesn't 'know about' a changed core state and tries to

put work on a meanwhile offline core or that hotplug event happend during putting work on a core in the governor.

Version 1.0 beta1

(outbreak)

Changelog:

- bump version to 1.0 beta1 because of brought forward plan 'outbreak'

- reworked scaling logic:

removed unessesary calls of external cpufreq function and use a static variable instead to hold the system freq table during runtime fixed frequency stuck on max hard and soft frequency limit (under some circumstances freq was out of scope for the main search loop) and added precautions to avoid problems when for what ever reason the freq table is 'messed' or even not available for the governor fixed not properly working scaling with descend ordered frequency table like it is for example on qualcomm platform added additional propotional scaling mode (mode '1' as usual decide and use the lowest freq, new mode '2' use only propotional frequencies like ondemand governor does - switchable as before in 'scaling_proportional' tuneable)

- use static frequency table variable in all frequency checks agains system frequency table in the governor

- fixed 'update_ts_time_stat idle accounting' (kernel patch for kernel version 3.0.x needed, example available in github zzmoove repository)

- fixed non setting of scaling down threshold tuneables under some circumstances (issue on kernel 3.4 when running multible zzmoove instances)

- changed some variable names in scaling range evaluation and debugging tuneable

- added compatibility for kernel version 3.4 (or higher, but only tested on 3.4.0 yet)

- added compatibility for cpufreq implementation used since kernel version 3.10 (NOTE: for backports u can use the macro CPU_IDLE_TIME_IN_CPUFREQ)

- added support for powersuspend (used on some platforms since kernel version 3.4)

- added support for opo specific 'backlight ext control' (kernel patch for opo bacon devices needed, example available in github zzmoove repository)

- added macros to exclude hotplugging functionality (default in this version is enabled=uncommented)

profile header file (Version 0.3 beta1)

- bump version to 0.3 beta1 because of brought forward plan 'outbreak'

- removed dynamic freq scaling tuneable leftovers

- added macros to switch code depending of used power management implementation

or used supend/resume backlight hook (opo specific)

- added macros to be able to disable hotplugging

Version 0.9 beta4

(slimline)

Changelog:

- removed 'freq_step' functionality as it never had any function in this governor. it was a left over from mialwes 'smoove' governor and also

had no function in his governor back then. so yeah all the 'feelings' about it's influence were placebo :)

- introduced 'proportional scaling' for more 'connectivity' to current load, this should give more 'balanced' frequencies

in general. when enabled all targeted frequencies in scaling logic will be compared with the ones from system table method and at the end

the lowest of them both will be used. so all used scaling frequencies will be 'tentential' lower in both directions

- added support for exynos4 CPU temperature reading (patches available in zzmoove repositories: https://github.com/zanezam)

this must be enabled via 'CONFIG_EXYNOS4_EXPORT_TEMP=y' in the config of a kernel which has exynos4 CPU temperature export

implementation

included. the default temp polling interval is 1000 ms and can be set with DEF_TMU_READ_DELAY. however the TMU driver has it's own polling

interval which is 10 seconds, so leaving it at the default value of 1 second is recommended temperature reading will only be enabled if the

tuneable 'scaling_block_temp' is set and will be disabled whenever early suspend is entered

- if exynos4 CPU temperature reading is enabled in the code use current CPU temperature in scaling block functionality to be able to 'hold' the cpu

temperatue to the given one in 'scaling_block_temp'. this function is used in combination with the already existent tuneable 'scaling_block_freq'

so u have to set both to enable it. the possible temperature range is 30°C to 80°C (lower temps are making no sense and higher temps would reach

into exynos4 TMU driver trottling range)

- if exynos4 CPU temperature reading is enabled added current CPU temperature to debug info tuneable

- added auto adjustment of all available frequency thresholds when scaling max limit has changed

- again some code style and comment changes/fixes

profile header file (Version 0.2 beta3):

- added scaling block temperature tuneable to all profiles if CONFIG_EXYNOS4_EXPORT_TEMP is defined

- use CPU temperature treshold of 65°C instead of 15 scaling block cycles in game profile if

CONFIG_EXYNOS4_EXPORT_TEMP is defined

- added proportional frequency tuneable to all profiles

- added auto adjust freq thresholds to all profiles (disabled by default)

- enabled scaling proportional in ybat, ybatext, zzbat, zzbatp, zzmod and zzgame profile

- enabled scaling fast down over 1200MHz and resposiveness over 400Mhz with up threshold of 20

in ybat, ybatext, zzbat, zzbatp, and zzmod profile

- added core macros to exclude not used code like it is in governor

- removed freq_step tuneable from all profiles

Version 0.9 beta3

(slimline)

Changelog:

merged some changes originated by ffolkes (all credits and thx to him)

(source https://github.com/ffolkes/android_...44e1e3190d5/drivers/cpufreq/cpufreq_zzmoove.c

- reordered sysfs attributes

description by ffolkes: some apps set tuneables by the order in which they are listed in the filesystem. this causes problems when one

tuneable needs another set first in order to correctly validate. (e.g. you cannot set down_threshold properly until you have first set up_threshold)

- added 'fast down' functionality (based on commits to pegasusq in perseus by andreilux and extended for this version by ZaneZam)

description by ffolkes: fastdown dynamically applies a (presumably) higher up_threshold and down_threshold after a frequency threshold has been reached. the goal is to encourage less time spent on the highest frequencies

- added 'hotplug engage' functionality

description by ffolkes: when set >0, will not bring any cores online until this frequency is met or exceeded

goal: reduce unnecessary cores online at low loads

- added 'scaling responsiveness' functioniality

description by ffolkes: similar to 'frequency for responsiveness' in other governors

defines a frequency below which we use a different up_threshold to help eliminate lag when starting tasks

- instead of failing when set too high in down_threshold tuneables set the value to the highest it can safely go

- increased possible sampling rate sleep multiplier value to a max of 8 (ZaneZam)

- added missing error handling to some tuneables (ZaneZam)

- fixed non setting of 'hotplug_sleep' tuneable when applying profiles (ZaneZam)

- added up/down threshold to debug tuneable (ZaneZam)

- some code style and comment changes/fixes (ZaneZam)

for this functions following new tuneables were introduced:

scaling_fastdown_freq-> will be enabled once this frequency has been met or exceeded (0 to disable, all possible system frequencies, default is 0)

scaling_fastdown_up_threshold-> once the above frequency threshold has been met, this will become the new up_threshold until we fall below the scaling_fastdown_freq again. (range from over fastdown_down_threshold to 100, default is 95)

scaling_fastdown_down_threshold-> once the above frequency threshold has been met, this will become the new down_threshold until we fall below the scaling_fastdown_freq again. (range from 11 to under fastdown_up_threshold, default is 90)

scaling_responsiveness_freq-> will be enabled once this frequency has been met or exceeded (0 to disable, all possible system frequencies, default is 0)

scaling_responsiveness_up_threshold-> the up_threshold that will take effect if scaling_responsiveness_freq is set (range from 11 to 100, default is 30)

hotplug_engage_freq -> will not bring any cores online until this frequency is met or exceeded (0 to disable, any possible system frequencies, default is 0)

profile header file (Version 0.2 beta2):

- added values for following new tuneables (credits to ffolkes):

hotplug_engage_freq (disabled by default in all profiles)

scaling_fastdown_freq (disabled by default in all profiles)

scaling_fastdown_up_threshold (default to 95 in all profiles)

scaling_fastdown_down_threshold (default to 90 in all profiles)

scaling_responsiveness_freq (disabled by default in all profiles)

scaling_responsiveness_up_threshold (default to 30 in all profiles)

- adjusted up/down thresholds for core 2 in moderate setting

- changed sampling rate sleep multiplier from 4 to 6 in all settings (except in default setting)

Version 0.9 beta2

(slimline)

Changelog:

- support for setting a default settings profile at governor start without the need of using the tuneable 'profile_number'

a default profile can be set with the already available macro 'DEF_PROFILE_NUMBER' check zzmoove_profiles.h for details about

which profile numbers are possible. this functionality was only half baken in previous versions, now any given profile will be really

applied when the governor starts. the value '0' (=profile name 'none') in 'DEF_PROFILE_NUMBER' disables this profile hardcoding and

that's also the default in the source. u still can (with or without enabling a default profile in the macro) as usual use the tuneable

'profile_number' to switch to a desired profile via sysfs at any later time after governor has started

- added 'blocking' of sysfs in all tuneables during apply of a settings profile to avoid a possible and unwanted overwriting/double

setting of tuneables mostly in combination with tuning apps where the tuneable apply order isn't influenceable

- added tuneable 'profile_list' for printing out a list of all profiles which are available in the profile header file

- fixed non setting of 'scaling_block_force_down' tuneable when applying profiles

- some documentation added and a little bit of source cleaning

Version 0.9 beta1

(slimline)

Changelog:

- bump version to beta for public

- added/corrected version informations and removed obsolete ones

profile header file (Version 0.2 beta1):

- bump version to beta for public

- corrected version informations

Version 0.9 alpha-2

Changelog:

- added auto fast scaling step tuneables:

afs_threshold1 for step one (range from 1 to 100)

afs_threshold2 for step two (range from 1 to 100)

afs_threshold3 for step three (range from 1 to 100)

afs_threshold4 for step four (range from 1 to 100)

profile header file (Version 0.2alpha-2):

- corrected documentation

- corrected version information

- added auto fast scaling step tuneables and values to all profiles

Version 0.9 alpha1 (Yank555.lu)

Changelog (credits to Yank555!):

- splitted fast_scaling into two separate tunables fast_scaling_up and fast_scaling_down so each can be set individually

to 0-4 (skip 0-4 frequency steps) or 5 to use autoscaling.

- splitted fast_scaling_sleep into two separate tunables fast_scaling_sleep_up and fast_scaling_sleep_down so each

can be set individually to 0-4 (skip 0-4 frequency steps) or 5 to use autoscaling.

- removed legacy mode (necessary to be able to split fast_scaling tunable)

- removed LCD frequency DFS

profile header file (Version 0.2):

- split fast_scaling and fast_scaling_sleep into fast_scaling_up/fast_scaling_down and

fast_scaling_sleep_up/fast_scaling_sleep_down

- adjusted values for profiles Yank Battery and Yank Battery Extreme

Currently in the Workshop:

working on Current versions of ZZMoove big.LITTLE Edition (bLE)