ro.ril.power.collapse= 1 or 0

ro.ril.power.collapse= 1 or 0 - HTC Wildfire S

ro.ril.power.collapse=1 or 0
I googled it . Some use 1 and some use 0
Which is best option for better battery life?

Anyone?

From "marvel-s-gb-mr-2.6.35-696f19b\arch\arm\mach-msm\acpuclock-arm11.c"
Code:
unsigned long acpuclk_power_collapse(int from_idle)
{
int ret = acpuclk_get_rate();
[B]ret *= 1000;[/B]
if ([B]ret > drv_state.power_collapse_khz[/B]) {
if (from_idle)
acpuclk_set_rate([B]drv_state.power_collapse_khz * 1000[/B],
SETRATE_PC_IDLE);
else
acpuclk_set_rate([B]drv_state.power_collapse_khz * 1000[/B],
SETRATE_PC);
}
return ret;
}
I don't know what the power collapse is and I don't care. But it seems that when that **** is enabled the cpu clock rate will be always lesser than the standard one in the something called "power collapse state". It means the less power consuption.
So: IMHO
ro.ril.power.collapse=1 or ro.ril.disable.power.collapse=0

Related

Smarreflex - Values explained +1350mv calibration fix

Ok dears, I accidentally came across this. Now there is nothing smart about smartreflex.
voltage.h contains values about min and max range for smartreflex calibrations for CORE IVA and MPU, that we already knew...
Now I found this:
http://gitorious.org/pandroid/kerne...a10c87d6445/arch/arm/mach-omap2/smartreflex.c
Let's quit fooling around:
/* Default steps added for 1G volt is 5 in uV */
static unsigned long sr_margin_steps_1g = 62500;
/* Default steps added for less than 1G OPP's is 3 in uV*/
static unsigned long sr_margin_steps = 37500;
Click to expand...
Click to collapse
Does this explain enough for you? Below 1ghz each step is 3.7500, above it is 6.25
You don't get it?
static void sr_add_margin_steps(struct omap_sr *sr)
{
int i;
/*
* Add 5 steps for 1g and 3 steps for other OPP's by default
* REVISIT: Make it configurable through sysfs dynamically
*/
for (i = 1; i <= 3; i++)
sr1_opp_margin = sr_margin_steps;
sr1_opp_margin[4] = sr_margin_steps_1g;
for (i = 1; i <= MAX_VDD1_OPP; i++) {
printk(KERN_INFO "sr1_opp_margin[%d]=%ld\n", i,
sr1_opp_margin);
mpu_opps.sr_vsr_step_vsel = 0x0;
mpu_opps.sr_adjust_vsel = 0x0;
}
printk(KERN_INFO "steps added, volt will be"
"recaliberated automatically\n");
}
Click to expand...
Click to collapse
How did that translate for you? Is that just hardcoded to read the OPP table??? The first three elements in the MPU OPP table are below 1GHZ: 350, 700, 920
The rest is above...
I hope I helped some developers with this.

Since I'm no programmer I'm having a hard time to understand this.
Does it mean smartreflex is not good at all?
For me I hate smartreflex. I always get better battery uptime (especially in standby I get around 0.5% usage per hour) when I undervolt by myself.
When I use smartreflex my usage in standby is about 3 to 5%.
In my opinion smartreflex is for noobs who don't wanna fool around themselves...
Gesendet von meinem Galaxy Nexus mit Tapatalk 2

Smartreflex - how to improve the algorithm

Hey everyone, lets get this thing started.
One of the big problems in this device is the Smartreflex calibration on higher than stock frequencies (because thats what we hackers do here at XDA). I haven't tried to improve the algorithm just yet but I would be very happy to start discussion on this matter and if anyone has ideas, code snippets. Just bring it so we can discuss it properly. I will be contributing with code soon when I have time to take a deep look on the driver.
I won't tolerate off-topic, or questions like "My dog ate my kitten, is that kernel's fault?", so this will be VERY heavily moderated.

franciscofranco said:
Hey everyone, lets get this thing started.
One of the big problems in this device is the Smartreflex calibration on higher than stock frequencies (because thats what we hackers do here at XDA). I haven't tried to improve the algorithm just yet but I would be very happy to start discussion on this matter and if anyone has ideas, code snippets. Just bring it so we can discuss it properly. I will be contributing with code soon when I have time to take a deep look on the driver.
I won't tolerate off-topic, or questions like "My dog ate my kitten, is that kernel's fault?", so this will be VERY heavily moderated.
Click to expand...
Click to collapse
honestly, id rather just have smart reflex gone. i feel more comfortable being in control then letting an algorithm decide.

simms22 said:
honestly, id rather just have smart reflex gone. i feel more comfortable being in control then letting an algorithm decide.
Click to expand...
Click to collapse
Why? That way we would have to hardcode all the voltages and we would have to set the values a little bit higher than what SR usually calibrates to prevent **** going haywire with some poor hardware devices. SR does a good job and mostly never misses a good sweet spot between stability and battery savings.
Do you have any set of voltage values you would recommend that would work on 99% of the devices?

franciscofranco said:
Why? That way we would have to hardcode all the voltages and we would have to set values a little bit higher than what SR usually calibrates to prevent **** going haywire with some poor hardware devices. SR does a good job and mostly never misses a good sweet spot between stability and battery savings.
Do you have any set of voltage values you would recommend that would work on 99% of the devices?
Click to expand...
Click to collapse
true.
since all of our devices seem to like different values, i guess there isnt a value that would work on 99% of our devices, unfortunately. so it would have to be a range of values. i guess i was looking at it from a users point of view, and not from the developers side.

simms22 said:
true.
since all of our devices seem to like different values, i guess there isnt a value that would work on 99% of our devices, unfortunately. so it would have to be a range of values. i guess i was looking at it from a users point of view, and not from the developers side.
Click to expand...
Click to collapse
Maybe we can try both, trying to hardcore them and let users find their own sweet spot and at the same time perfect the algorithm, I believe theres margin for improvement. If you find some good values feel free to share here.
I also hope some other good developers come here and throw out their ideas.
Small off-topic but related to this new forum, can you create a new topic about your SoD experience (the email you sent us how you could reproduce the issue) would be very nice we could discuss that as well in a specific topic.

smartreflex
I do not know if the code is optimized or not I have no basis to evaluate.
From my experience I have seen that in order to avoid problems related to the various soc, I decided to let users tinker with voltages and smartreflex.
This is why in some cases I raised the voltages.
From that day problems with my kernel is greatly decreased. :fingers-crossed:

anarkia1976 said:
I do not know if the code is optimized or not I have no basis to evaluate.
From my experience I have seen that in order to avoid problems related to the various soc, I decided to let users tinker with voltages and smartreflex.
This is why in some cases I raised the voltages.
From that day problems with my kernel is greatly decreased. :fingers-crossed:
Click to expand...
Click to collapse
What do you mean by tinkering with voltages and smartreflex? Thats what I have in my kernel at the moment: custom voltage interface (from Ezekeel) and SR is also active, so I dunno what you mean.

Franco, would you mind sharing the code of SR in here and let us have a look at it?
I haven't seen it so far plus I am in no way a kernel dev, but I'd like to see it and throw something at the thread whichever comes to my mind, always ontopic of course :laugh:

zillinder said:
Franco, would you mind sharing the code of SR in here and let us have a look at it?
I haven't seen it so far plus I am in no way a kernel dev, but I'd like to see it and throw something at the thread whichever comes to my mind, always ontopic of course :laugh:
Click to expand...
Click to collapse
Code:
/*
* Smart reflex Class 1.5 specific implementations
*
* Copyright (C) 2010-2011 Texas Instruments, Inc.
* Nishanth Menon <[email protected]>
*
* Smart reflex class 1.5 is also called periodic SW Calibration
* Some of the highlights are as follows:
* – Host CPU triggers OPP calibration when transitioning to non calibrated
* OPP
* – SR-AVS + VP modules are used to perform calibration
* – Once completed, the SmartReflex-AVS module can be disabled
* – Enables savings based on process, supply DC accuracy and aging
*
* This program is free software; you can redistribute it and/or modify
* it under the terms of the GNU General Public License version 2 as
* published by the Free Software Foundation.
*/
#include <linux/kernel.h>
#include <linux/delay.h>
#include <linux/err.h>
#include <linux/io.h>
#include <linux/fs.h>
#include <linux/uaccess.h>
#include <linux/kobject.h>
#include <linux/workqueue.h>
#include <linux/slab.h>
#include <linux/opp.h>
#include "smartreflex.h"
#include "voltage.h"
#include "dvfs.h"
#define MAX_VDDS 3
#define SR1P5_SAMPLING_DELAY_MS 1
#define SR1P5_STABLE_SAMPLES 10
#define SR1P5_MAX_TRIGGERS 5
/*
* We expect events in 10uS, if we don't receive it in twice as long,
* we stop waiting for the event and use the current value
*/
#define MAX_CHECK_VPTRANS_US 20
/**
* struct sr_class1p5_work_data - data meant to be used by calibration work
* @work: calibration work
* @voltdm: voltage domain for which we are triggering
* @vdata: voltage data we are calibrating
* @num_calib_triggers: number of triggers from calibration loop
* @num_osc_samples: number of samples collected by isr
* @u_volt_samples: private data for collecting voltage samples in
* case oscillations. filled by the notifier and
* consumed by the work item.
* @work_active: have we scheduled a work item?
*/
struct sr_class1p5_work_data {
struct delayed_work work;
struct voltagedomain *voltdm;
struct omap_volt_data *vdata;
u8 num_calib_triggers;
u8 num_osc_samples;
unsigned long u_volt_samples[SR1P5_STABLE_SAMPLES];
bool work_active;
};
#if CONFIG_OMAP_SR_CLASS1P5_RECALIBRATION_DELAY
/* recal_work: recalibration calibration work */
static struct delayed_work recal_work;
#endif
/**
* sr_class1p5_notify() - isr notifier for status events
* @voltdm: voltage domain for which we were triggered
* @voltdm_cdata: voltage domain specific private class data
* @status: notifier event to use
*
* This basically collects data for the work to use.
*/
static int sr_class1p5_notify(struct voltagedomain *voltdm,
void *voltdm_cdata,
u32 status)
{
struct sr_class1p5_work_data *work_data;
int idx = 0;
if (IS_ERR_OR_NULL(voltdm)) {
pr_err("%s: bad parameters!\n", __func__);
return -EINVAL;
}
work_data = (struct sr_class1p5_work_data *)voltdm_cdata;
if (IS_ERR_OR_NULL(work_data)) {
pr_err("%s:%s no work data!!\n", __func__, voltdm->name);
return -EINVAL;
}
/* Wait for transdone so that we know the voltage to read */
do {
if (omap_vp_is_transdone(voltdm))
break;
idx++;
/* get some constant delay */
udelay(1);
} while (idx < MAX_CHECK_VPTRANS_US);
/*
* NOTE:
* If we timeout, we still read the data,
* if we are oscillating+irq latencies are too high, we could
* have scenarios where we miss transdone event. since
* we waited long enough, it is still safe to read the voltage
* as we would have waited long enough - Dont warn for this.
*/
idx = (work_data->num_osc_samples) % SR1P5_STABLE_SAMPLES;
work_data->u_volt_samples[idx] = omap_vp_get_curr_volt(voltdm);
work_data->num_osc_samples++;
omap_vp_clear_transdone(voltdm);
return 0;
}
/**
* sr_class1p5_calib_work() - work which actually does the calibration
* @work: pointer to the work
*
* calibration routine uses the following logic:
* on the first trigger, we start the isr to collect sr voltages
* wait for stabilization delay (reschdule self instead of sleeping)
* after the delay, see if we collected any isr events
* if none, we have calibrated voltage.
* if there are any, we retry untill we giveup.
* on retry timeout, select a voltage to use as safe voltage.
*/
static void sr_class1p5_calib_work(struct work_struct *work)
{
struct sr_class1p5_work_data *work_data =
container_of(work, struct sr_class1p5_work_data, work.work);
unsigned long u_volt_safe = 0, u_volt_current = 0, u_volt_margin;
struct omap_volt_data *volt_data;
struct voltagedomain *voltdm;
int idx = 0;
if (!work) {
pr_err("%s: ooops.. null work_data?\n", __func__);
return;
}
/*
* Handle the case where we might have just been scheduled AND
* 1.5 disable was called.
*/
if (!mutex_trylock(&omap_dvfs_lock)) {
schedule_delayed_work(&work_data->work,
msecs_to_jiffies(SR1P5_SAMPLING_DELAY_MS *
SR1P5_STABLE_SAMPLES));
return;
}
voltdm = work_data->voltdm;
/*
* In the unlikely case that we did get through when unplanned,
* flag and return.
*/
if (unlikely(!work_data->work_active)) {
pr_err("%s:%s unplanned work invocation!\n", __func__,
voltdm->name);
mutex_unlock(&omap_dvfs_lock);
return;
}
volt_data = work_data->vdata;
work_data->num_calib_triggers++;
/* if we are triggered first time, we need to start isr to sample */
if (work_data->num_calib_triggers == 1) {
/* We could be interrupted many times, so, only for debug */
pr_debug("%s: %s: Calibration start: Voltage Nominal=%d\n",
__func__, voltdm->name, volt_data->volt_nominal);
goto start_sampling;
}
/* Stop isr from interrupting our measurements :) */
sr_notifier_control(voltdm, false);
/*
* Quit sampling
* a) if we have oscillations
* b) if we have nominal voltage as the voltage
*/
if (work_data->num_calib_triggers == SR1P5_MAX_TRIGGERS)
goto stop_sampling;
/* if there are no samples captured.. SR is silent, aka stability! */
if (!work_data->num_osc_samples) {
/* Did we interrupt too early? */
u_volt_current = omap_vp_get_curr_volt(voltdm);
if (u_volt_current >= volt_data->volt_nominal)
goto start_sampling;
u_volt_safe = u_volt_current;
goto done_calib;
}
/* we have potential oscillations/first sample */
start_sampling:
work_data->num_osc_samples = 0;
/* Clear transdone events so that we can go on. */
do {
if (!omap_vp_is_transdone(voltdm))
break;
idx++;
/* get some constant delay */
udelay(1);
omap_vp_clear_transdone(voltdm);
} while (idx < MAX_CHECK_VPTRANS_US);
if (idx >= MAX_CHECK_VPTRANS_US)
pr_warning("%s: timed out waiting for transdone clear!!\n",
__func__);
/* Clear pending events */
sr_notifier_control(voltdm, false);
/* trigger sampling */
sr_notifier_control(voltdm, true);
schedule_delayed_work(&work_data->work,
msecs_to_jiffies(SR1P5_SAMPLING_DELAY_MS *
SR1P5_STABLE_SAMPLES));
mutex_unlock(&omap_dvfs_lock);
return;
stop_sampling:
/*
* We are here for Oscillations due to two scenarios:
* a) SR is attempting to adjust voltage lower than VLIMITO
* which VP will ignore, but SR will re-attempt
* b) actual oscillations
* NOTE: For debugging, enable debug to see the samples.
*/
pr_warning("%s: %s Stop sampling: Voltage Nominal=%d samples=%d\n",
__func__, work_data->voltdm->name,
volt_data->volt_nominal, work_data->num_osc_samples);
/* pick up current voltage */
u_volt_current = omap_vp_get_curr_volt(voltdm);
/* Just in case we got more interrupts than our tiny buffer */
if (work_data->num_osc_samples > SR1P5_STABLE_SAMPLES)
idx = SR1P5_STABLE_SAMPLES;
else
idx = work_data->num_osc_samples;
/* Index at 0 */
idx -= 1;
u_volt_safe = u_volt_current;
/* Grab the max of the samples as the stable voltage */
for (; idx >= 0; idx--) {
pr_debug("%s: osc_v[%d]=%ld, safe_v=%ld\n", __func__, idx,
work_data->u_volt_samples[idx], u_volt_safe);
if (work_data->u_volt_samples[idx] > u_volt_safe)
u_volt_safe = work_data->u_volt_samples[idx];
}
/* Use the nominal voltage as the safe voltage to recover bad osc */
if (u_volt_safe > volt_data->volt_nominal)
u_volt_safe = volt_data->volt_nominal;
/* Fall through to close up common stuff */
done_calib:
sr_disable_errgen(voltdm);
omap_vp_disable(voltdm);
sr_disable(voltdm);
/* Add margin if needed */
if (volt_data->volt_margin) {
struct omap_voltdm_pmic *pmic = voltdm->pmic;
/* Convert to rounded to PMIC step level if available */
if (pmic && pmic->vsel_to_uv && pmic->uv_to_vsel) {
/*
* To ensure conversion works:
* use a proper base voltage - we use the current volt
* then convert it with pmic routine to vsel and back
* to voltage, and finally remove the base voltage
*/
u_volt_margin = u_volt_current + volt_data->volt_margin;
u_volt_margin = pmic->uv_to_vsel(u_volt_margin);
u_volt_margin = pmic->vsel_to_uv(u_volt_margin);
u_volt_margin -= u_volt_current;
} else {
u_volt_margin = volt_data->volt_margin;
}
/* Add margin IF we are lower than nominal */
if ((u_volt_safe + u_volt_margin) < volt_data->volt_nominal) {
u_volt_safe += u_volt_margin;
} else {
pr_err("%s: %s could not add %ld[%d] margin"
"to vnom %d curr_v=%ld\n",
__func__, voltdm->name, u_volt_margin,
volt_data->volt_margin, volt_data->volt_nominal,
u_volt_current);
}
}
volt_data->volt_calibrated = u_volt_safe;
/* Setup my dynamic voltage for the next calibration for this opp */
volt_data->volt_dynamic_nominal = omap_get_dyn_nominal(volt_data);
/*
* if the voltage we decided as safe is not the current voltage,
* switch
*/
if (volt_data->volt_calibrated != u_volt_current) {
pr_debug("%s: %s reconfiguring to voltage %d\n",
__func__, voltdm->name, volt_data->volt_calibrated);
voltdm_scale(voltdm, volt_data);
}
pr_info("%s: %s: Calibration complete: Voltage:Nominal=%d,"
"Calib=%d,margin=%d\n",
__func__, voltdm->name, volt_data->volt_nominal,
volt_data->volt_calibrated, volt_data->volt_margin);
/*
* TODO: Setup my wakeup voltage to allow immediate going to OFF and
* on - Pending twl and voltage layer cleanups.
* This is necessary, as this is not done as part of regular
* Dvfs flow.
* vc_setup_on_voltage(voltdm, volt_data->volt_calibrated);
*/
work_data->work_active = false;
mutex_unlock(&omap_dvfs_lock);
}
#if CONFIG_OMAP_SR_CLASS1P5_RECALIBRATION_DELAY
/**
* sr_class1p5_voltdm_recal() - Helper routine to reset calibration.
* @voltdm: Voltage domain to reset calibration for
* @user: unused
*
* NOTE: Appropriate locks must be held by calling path to ensure mutual
* exclusivity
*/
static int sr_class1p5_voltdm_recal(struct voltagedomain *voltdm,
void *user)
{
struct omap_volt_data *vdata;
/*
* we need to go no further if sr is not enabled for this domain or
* voltage processor is not present for this voltage domain
* (example vdd_wakeup). Class 1.5 requires Voltage processor
* to function.
*/
if (!voltdm->vp || !is_sr_enabled(voltdm))
return 0;
vdata = omap_voltage_get_curr_vdata(voltdm);
if (!vdata) {
pr_err("%s: unable to find current voltage for vdd_%s\n",
__func__, voltdm->name);
return -ENXIO;
}
omap_sr_disable(voltdm);
omap_voltage_calib_reset(voltdm);
voltdm_reset(voltdm);
omap_sr_enable(voltdm, vdata);
pr_info("%s: %s: calibration reset\n", __func__, voltdm->name);
return 0;
}
/**
* sr_class1p5_recal_work() - work which actually does the calibration
* @work: pointer to the work
*
* on a periodic basis, we come and reset our calibration setup
* so that a recalibration of the OPPs take place. This takes
* care of aging factor in the system.
*/
static void sr_class1p5_recal_work(struct work_struct *work)
{
mutex_lock(&omap_dvfs_lock);
if (voltdm_for_each(sr_class1p5_voltdm_recal, NULL))
pr_err("%s: Recalibration failed\n", __func__);
mutex_unlock(&omap_dvfs_lock);
/* We come back again after time the usual delay */
schedule_delayed_work(&recal_work,
msecs_to_jiffies
(CONFIG_OMAP_SR_CLASS1P5_RECALIBRATION_DELAY));
}
#endif /* CONFIG_OMAP_SR_CLASS1P5_RECALIBRATION_DELAY */
/**
* sr_class1p5_enable() - class 1.5 mode of enable for a voltage domain
* @voltdm: voltage domain to enable SR for
* @voltdm_cdata: voltage domain specific private class data
* @volt_data: voltdata for the current OPP being transitioned to
*
* when this gets called, we use the h/w loop to setup our voltages
* to an calibrated voltage, detect any oscillations, recover from the same
* and finally store the optimized voltage as the calibrated voltage in the
* system.
*
* NOTE: Appropriate locks must be held by calling path to ensure mutual
* exclusivity
*/
static int sr_class1p5_enable(struct voltagedomain *voltdm,
void *voltdm_cdata,
struct omap_volt_data *volt_data)
{
int r;
struct sr_class1p5_work_data *work_data;
if (IS_ERR_OR_NULL(voltdm) || IS_ERR_OR_NULL(volt_data)) {
pr_err("%s: bad parameters!\n", __func__);
return -EINVAL;
}
/* If already calibrated, nothing to do here.. */
if (volt_data->volt_calibrated)
return 0;
work_data = (struct sr_class1p5_work_data *)voltdm_cdata;
if (IS_ERR_OR_NULL(work_data)) {
pr_err("%s: bad work data??\n", __func__);
return -EINVAL;
}
if (work_data->work_active)
return 0;
omap_vp_enable(voltdm);
r = sr_enable(voltdm, volt_data);
if (r) {
pr_err("%s: sr[%s] failed\n", __func__, voltdm->name);
sr_disable_errgen(voltdm);
omap_vp_disable(voltdm);
return r;
}
work_data->vdata = volt_data;
work_data->work_active = true;
work_data->num_calib_triggers = 0;
/* program the workqueue and leave it to calibrate offline.. */
schedule_delayed_work(&work_data->work,
msecs_to_jiffies(SR1P5_SAMPLING_DELAY_MS *
SR1P5_STABLE_SAMPLES));
return 0;
}
/**
* sr_class1p5_disable() - disable 1.5 mode for a voltage domain
* @voltdm: voltage domain for the sr which needs disabling
* @volt_data: voltage data for current OPP to disable
* @voltdm_cdata: voltage domain specific private class data
* @is_volt_reset: reset the voltage?
*
* This function has the necessity to either disable SR alone OR disable SR
* and reset voltage to appropriate level depending on is_volt_reset parameter.
*
* Disabling SR H/w loop:
* If calibration is complete or not yet triggered, we have no need to disable
* SR h/w loop.
* If calibration is complete, we would have already disabled SR AVS at the end
* of calibration and h/w loop is inactive when this is called.
* If it was never calibrated before, H/w loop was never enabled in the first
* place to disable.
* If calibration is underway, we cancel the work queue and disable SR. This is
* to provide priority to DVFS transition as such transitions cannot wait
* without impacting user experience.
*
* Resetting voltage:
* If we have already completed calibration, then resetting to nominal voltage
* is not required as we are functioning at safe voltage levels.
* If we have not started calibration, we would like to reset to nominal voltage
* If calibration is underway and we are attempting to reset voltage as
* well, it implies we are in idle/suspend paths where we give priority
* to calibration activity and a retry will be attempted.
*
* NOTE: Appropriate locks must be held by calling path to ensure mutual
* exclusivity
*/
static int sr_class1p5_disable(struct voltagedomain *voltdm,
void *voltdm_cdata,
struct omap_volt_data *volt_data,
int is_volt_reset)
{
struct sr_class1p5_work_data *work_data;
if (IS_ERR_OR_NULL(voltdm) || IS_ERR_OR_NULL(volt_data)) {
pr_err("%s: bad parameters!\n", __func__);
return -EINVAL;
}
work_data = (struct sr_class1p5_work_data *)voltdm_cdata;
if (IS_ERR_OR_NULL(work_data)) {
pr_err("%s: bad work data??\n", __func__);
return -EINVAL;
}
if (work_data->work_active) {
/* if volt reset and work is active, we dont allow this */
if (is_volt_reset)
return -EBUSY;
/* flag work is dead and remove the old work */
work_data->work_active = false;
cancel_delayed_work_sync(&work_data->work);
sr_notifier_control(voltdm, false);
sr_disable_errgen(voltdm);
omap_vp_disable(voltdm);
sr_disable(voltdm);
}
/* If already calibrated, don't need to reset voltage */
if (volt_data->volt_calibrated)
return 0;
if (is_volt_reset)
voltdm_reset(voltdm);
return 0;
}
/**
* sr_class1p5_configure() - configuration function
* @voltdm: configure for which voltage domain
* @voltdm_cdata: voltage domain specific private class data
*
* we dont do much here other than setup some registers for
* the sr module involved.
*/
static int sr_class1p5_configure(struct voltagedomain *voltdm,
void *voltdm_cdata)
{
if (IS_ERR_OR_NULL(voltdm)) {
pr_err("%s: bad parameters!\n", __func__);
return -EINVAL;
}
return sr_configure_errgen(voltdm);
}
/**
* sr_class1p5_init() - class 1p5 init
* @voltdm: sr voltage domain
* @voltdm_cdata: voltage domain specific private class data
* allocated by class init with work item data
* freed by deinit.
* @class_priv_data: private data for the class (unused)
*
* we do class specific initialization like creating sysfs/debugfs entries
* needed, spawning of a kthread if needed etc.
*/
static int sr_class1p5_init(struct voltagedomain *voltdm,
void **voltdm_cdata, void *class_priv_data)
{
struct sr_class1p5_work_data *work_data;
if (IS_ERR_OR_NULL(voltdm) || IS_ERR_OR_NULL(voltdm_cdata)) {
pr_err("%s: bad parameters!\n", __func__);
return -EINVAL;
}
if (!IS_ERR_OR_NULL(*voltdm_cdata)) {
pr_err("%s: ooopps.. class already initialized for %s! bug??\n",
__func__, voltdm->name);
return -EINVAL;
}
/* setup our work params */
work_data = kzalloc(sizeof(struct sr_class1p5_work_data), GFP_KERNEL);
if (!work_data) {
pr_err("%s: no memory to allocate work data on domain %s\n",
__func__, voltdm->name);
return -ENOMEM;
}
work_data->voltdm = voltdm;
INIT_DELAYED_WORK_DEFERRABLE(&work_data->work, sr_class1p5_calib_work);
*voltdm_cdata = (void *)work_data;
return 0;
}
/**
* sr_class1p5_deinit() - class 1p5 deinitialization
* @voltdm: voltage domain for which to do this.
* @voltdm_cdata: voltage domain specific private class data
* allocated by class init with work item data
* freed by deinit.
* @class_priv_data: class private data for deinitialiation (unused)
*
* currently only resets the calibrated voltage forcing DVFS voltages
* to be used in the system
*
* NOTE: Appropriate locks must be held by calling path to ensure mutual
* exclusivity
*/
static int sr_class1p5_deinit(struct voltagedomain *voltdm,
void **voltdm_cdata, void *class_priv_data)
{
struct sr_class1p5_work_data *work_data;
if (IS_ERR_OR_NULL(voltdm) || IS_ERR_OR_NULL(voltdm_cdata)) {
pr_err("%s: bad parameters!\n", __func__);
return -EINVAL;
}
if (IS_ERR_OR_NULL(*voltdm_cdata)) {
pr_err("%s: ooopps.. class not initialized for %s! bug??\n",
__func__, voltdm->name);
return -EINVAL;
}
work_data = (struct sr_class1p5_work_data *) *voltdm_cdata;
/*
* we dont have SR periodic calib anymore.. so reset calibs
* we are already protected by appropriate locks, so no lock needed
* here.
*/
if (work_data->work_active)
sr_class1p5_disable(voltdm, work_data, work_data->vdata, 0);
/* Ensure worker canceled. */
cancel_delayed_work_sync(&work_data->work);
omap_voltage_calib_reset(voltdm);
voltdm_reset(voltdm);
*voltdm_cdata = NULL;
kfree(work_data);
return 0;
}
/* SR class1p5 structure */
static struct omap_sr_class_data class1p5_data = {
.enable = sr_class1p5_enable,
.disable = sr_class1p5_disable,
.configure = sr_class1p5_configure,
.class_type = SR_CLASS1P5,
.init = sr_class1p5_init,
.deinit = sr_class1p5_deinit,
.notify = sr_class1p5_notify,
/*
* trigger for bound - this tells VP that SR has a voltage
* change. we should try and ensure transdone is set before reading
* vp voltage.
*/
.notify_flags = SR_NOTIFY_MCUBOUND,
};
/**
* sr_class1p5_driver_init() - register class 1p5 as default
*
* board files call this function to use class 1p5, we register with the
* smartreflex subsystem
*/
static int __init sr_class1p5_driver_init(void)
{
int r;
/* Enable this class only for OMAP3630 and OMAP4 */
if (!(cpu_is_omap3630() || cpu_is_omap44xx()))
return -EINVAL;
r = sr_register_class(&class1p5_data);
if (r) {
pr_err("SmartReflex class 1.5 driver: "
"failed to register with %d\n", r);
} else {
#if CONFIG_OMAP_SR_CLASS1P5_RECALIBRATION_DELAY
INIT_DELAYED_WORK_DEFERRABLE(&recal_work,
sr_class1p5_recal_work);
schedule_delayed_work(&recal_work,
msecs_to_jiffies
(CONFIG_OMAP_SR_CLASS1P5_RECALIBRATION_DELAY));
#endif
pr_info("SmartReflex class 1.5 driver: initialized (%dms)\n",
CONFIG_OMAP_SR_CLASS1P5_RECALIBRATION_DELAY);
}
return r;
}
late_initcall(sr_class1p5_driver_init);

I might be pointing out the obvious here but sometimes the obvious isn't so obvious...has anyone contacted Nishanth Menon that is named in the code header to see if TI has a latest and greatest SR? I would assume they would since phones are coming out now with higher CPU speeds then what the current SR could handle around two years ago. I see the guy is pretty active online with posting stuff to open source sites and still deals with smart reflex related things as this site shows: http://marc.info/?a=124043331500007&r=1&w=2
I dunno what that site is or know what any of that stuff means but I just stumbled upon it and just wanted to show he is active with TI and smart reflex work, among other things

As I've always seen it, the limitations/problems with SmartReflex are as follows:
- Can't calibrate to a lower voltage than 830mV (problematic when 384MHz generally does fine at 775mV and 192MHz generally does fine at 725mV).
- Does not handle frequencies above 1305 well at all (calibrates them the same as 1228, so it must be an upper limit to its bracketing/range, almost as though it sees it as the same as 1228).
- Could definitely be a bit more aggressive safely when everyone can UV the SR values by another 50-100mV (so I'd say another 50mV safely across the board).
No idea how to proceed on any of those, but I thought it might help to make the limitations a bit more clear. I'm looking forward to following the progress of this thread. Great idea, Francisco.

Smartreflex improvement
osm0sis said:
As I've always seen it, the limitations/problems with SmartReflex are as follows:
- Can't calibrate to a lower voltage than 830mV (problematic when 384MHz generally does fine at 775mV and 192MHz generally does fine at 725mV).
- Does not handle frequencies above 1305 well at all (calibrates them the same as 1228, so it must be an upper limit to its bracketing/range, almost as though it sees it as the same as 1228).
- Could definitely be a bit more aggressive safely when everyone can UV the SR values by another 50-100mV (so I'd say another 50mV safely across the board).
No idea how to proceed on any of those, but I thought it might help to make the limitations a bit more clear. I'm looking forward to following the progress of this thread. Great idea, Francisco.
Click to expand...
Click to collapse
So you mean the Lean's 1.6Ghz SR does also do the same, 1.6GHz calibrates as 1.2GHz range instead of the real application ??
and it would be great if we could overcome the 2nd limitation .

Most kernels (probably all but I haven't personally checked) disable SR for frequencies above 1305, but yes I believe that's why it doesn't work. Franco used to have the cutoff for SR be voltage based and on my device 1536 UV's by 100mV stably, so if I left SR on and lowered it too much (75mV) SR would act on it and calibrate it to the same voltage as 1228, which of course was too low and froze and crashed. So yeah, its as though it needs new brackets/ranges added for higher voltages.

Has amazon released the kernel source for the kindle fire hd 8.9? That uses a ti omap clocked at 1.5ghz stock. Maybe a look at the smart reflex code on that would shed some light.

supernova_00 said:
I might be pointing out the obvious here but sometimes the obvious isn't so obvious...has anyone contacted Nishanth Menon that is named in the code header to see if TI has a latest and greatest SR? I would assume they would since phones are coming out now with higher CPU speeds then what the current SR could handle around two years ago. I see the guy is pretty active online with posting stuff to open source sites and still deals with smart reflex related things as this site shows: http://marc.info/?a=124043331500007&r=1&w=2
I dunno what that site is or know what any of that stuff means but I just stumbled upon it and just wanted to show he is active with TI and smart reflex work, among other things
Click to expand...
Click to collapse
blackhand1001 said:
Has amazon released the kernel source for the kindle fire hd 8.9? That uses a ti omap clocked at 1.5ghz stock. Maybe a look at the smart reflex code on that would shed some light.
Click to expand...
Click to collapse
Both good ideas!

osm0sis said:
Most kernels (probably all but I haven't personally checked) disable SR for frequencies above 1305, but yes I believe that's why it doesn't work. Franco used to have the cutoff for SR be voltage based and on my device 1536 UV's by 100mV stably, so if I left SR on and lowered it too much (75mV) SR would act on it and calibrate it to the same voltage as 1228, which of course was too low and froze and crashed. So yeah, its as though it needs new brackets/ranges added for higher voltages.
Click to expand...
Click to collapse
According to SR v1 by Imoseyon & his explanation says he had modified the SR code to override the below limits
1) VDDMIN - 830mV for all three domains,
2) VDDMAX - 1410mV for MPU, 1260mV for IVA, and 1200mV for CORE.
So, i think do already have a better version of SR over the TI's stock SR from Lean but only a few phones can handle the SR calibration for the 1.5+ GHz freq .

Ashtrix said:
According to SR v1 by Imoseyon & his explanation says he had modified the SR code to override the below limits
1) VDDMIN - 830mV for all three domains,
2) VDDMAX - 1410mV for MPU, 1260mV for IVA, and 1200mV for CORE.
So, i think do already have a better version of SR over the TI's stock SR from Lean but only a few phones can handle the SR calibration for the 1.5+ GHz freq .
Click to expand...
Click to collapse
That's because it doesn't seem to actually calibrate properly for 1.5ghz. That's why I suggested looking at device like the kndl fire hd 8.9 which is 1.5 GHz stock. TI most likely modified the smartreflex code to work with that frequency.
Sent from my Galaxy Nexus using xda premium

Did you guys already give up the discussion or is there nothing more to discuss?
Sent from my Galaxy Nexus with Tapatalk 2

The Kindle Fire has source code released: http://www.amazon.com/gp/help/customer/display.html?nodeId=200203720
Inside the downloaded tar are multiple tars, the kernel is in omap.tar
There appears to be a few difference in the SR code, but it doesn't look like much. EDIT: This was through a simple compare of the 1p5 file, I'll check the other possibly relevant files.
EDIT2: Yeah I didn't notice much of a change in the SR stuff, however I'm not as familiar with this code as some other people here might be, so don't trust my judgement!

some users were able to run 4460 @1.5GHz with smartreflex enabled. luckily Hashcode had one too and did this http://forum.xda-developers.com/showpost.php?p=41847005&postcount=93

[KERNEL] Bricked-Kernel Hammerhead | Sweep2wake | KnockKnock/Dt2w

Welcome to the most customizable N5 kernel on xda
Bricked-Kernel Nexus 5 (hammerhead)
Features:
* Based upon Google's msm 3.4 source
* Various fixes, improvements and optimizatios (look @ github)
* Compiled with gcc4.7.2 toolchain (linaro 09.12)
* -O3+ optimized
* Snapdragon & CortexA15 optimizations
* replaced qcom's hotplug binary with msm_mpdecision (IN-KERNEL, better battery life + performance)
* Extensive sysfs interface for mpdecision with all the tuneables you want (/sys/kernel/msm_mpdecision/)
* replaced qcom's thermal binary with my IN-KERNEL solution. (/sys/kernel/msm_thermal/)
* export krait version to: /sys/kernel/debug/krait_variant
* Allow OC up to 2,5Ghz
* Allow UC to 96Mhz
* Undervolting (faux123)
* F2FS Support
* Multirom Support
* KCAL (savoca) & Gamma Control (faux123)
* Sound Control (faux123)
* Default clocks: 300 Mhz min & 2265,6 Mhz max
Zip features:
*** ON-THE-FLY-RAMDISK EDITS!
*** THIS KERNEL USES YOUR RAMDISK, it will just modify it on the fly while flashing. These changes are not creating any incompatibilities with roms/other kernels.
* removes min freq overrides from the ramdisk
* removes governor overrides from the ramdisk
* adds init.d support to your ramdisk (if not already supported)
* modifies stock ondemand settings
* add module insertion
Check the compare links for the rest 
Where is tha Changelog???
There will be no more changelogs.
Instead the download pages were outfitted with compare links to github for each download.
What is sweep2wake?
Disabled as default, activate through an app like KControl or over sysfs: echo 1 > /sys/android_touch/sweep2wake
What is doubletap2wake / knock knock?
Disabled as default, activate through an app like KControl or over sysfs: echo 1 > /sys/android_touch/doubletap2wake
How to install?
Flash through recovery. #done.
How to uninstall?
Flash this:
http://bricked.de/downloads/kernel/hammerhead/bricked_uninstaller_hammerhead.zip
You are done. Bye.
Where to complain about errors/bugs?
Please use the Issuetracker for bugs/errors/feature wishes!
Issuetracker @ https://github.com/showp1984/bricked-hammerhead/issues
[email protected]
IRC Chat: Freenode IRC #bricked
Download:
No Guarantees! If it kills your grandmother or your device, I am NOT responsible! If you understand this:
(If you download, please hit Thanks below my post! Thank you!)
>>> DOWNLOAD <<<
Donation Hall-of-Fame:
> Hall of fame <
Thank you very much!
Stock 4.4 Nexus5 boot.img - flash this if you come from another kernel coming with it's own ramdisk (eg: zip contains a *.img file) ONLY FLASH ON 4.4
Source:

What is msm_thermal?
Kernel based 3-phase thermal control!
This replaces your /system/bin/thermal-engine-hh binary which is renamed by the installer to thermal-engine-hh_bck.
It will throttle your cpu speed to keep it cool and unleash it if the cpu has cooled down enough. (3 phases: low, mid and high)
Check /sys/kernel/msm_thermal/conf/ for the thermal configuration
allowed_max_high = highest threshold (phase 3)
allowed_max_low = remove the throttling if we cooled down to this (clr_thrshold)
allowed_max_freq = max frequency if throttled (limit)
[...]mid[...] = same as above, just for phase 2
[...]low[...] = Lowest threshold (phase 1)
check_interval_ms = how often shall we check? (sampling rate)
shutdown_temp = if we reach this shut down the device!
If you want to see msm_thermal doing it's job:
Code:
adb shell
cat /proc/kmsg | grep 'thermal'
What is msm_mpdecision?
100% kernel based multi core decision! (should cpu1/2/3 be online or not?)
This replaces your /system/bin/mpdecision binary which is renamed by the installer to mpdecision_bck.
Check /sys/kernel/msm_mpdecision/conf/ for the configuration.
startdelay = time until mpdecision starts doing it's magic (20000)
delay = time between checks (130)
pause = if something else plugs in the cpu, fall asleep for 10000ms (10 secs)
scroff_single_core = if the screen is off, don't plug in cpu1/2/3. Additionally: Unplug all cpus except cpu0 when screen is turned off (1)
enabled = enable(1) or disable(0) mpdecision. This does not affect scroff_single_core!
min_cpus = min cpus to be online, cannot be < 1. Default: 1
max_cpus = max cpus to be online, cannot be > 4. (if you set it to 2 and min_cpus to 1 you will basically have a dualcore) Default: 4
idle_freq = a value against that will be checked if a core +/- is requested. (499200)
If cpu0 is below that value and a core up of another cpu is requested, nothing will happen.
If any other cpu is above that value and a core down of that cpu is requested, nothing will happen. (otherwise it would now put down that cpu even though it is still working, which isn't what we want)
Hot plug thresholds (aka now it gets 'complicated')
This small formula calculates which value will be used: (number_of_cpus_online - 1) * 2
The result of this formula will be the nwns_threshold where a new cpu is hotplugged.
The result of this formula + 1 will be the nwns_threshold where a cpu is unplugged.
nwns_threshold_x = runqueue threshold, if this is reached cpuX will be hot/unplugged
twts_threshold_x = time threshold, this amount of time must have passed for the related action to be taken (hot/unplug)
Example:
One cpu is online.
(1 - 1) * 2 = 0 ergo:
nwns_threshold_0 = cpu1 will be hotplugged at this value
((1 - 1) * 2) + 1 = 1
nwns_threshold_1 = cpu0 will be unplugged at this value
Since we can't unplug cpu0 this is '0'.
Two cpus are online.
(2 - 1) * 2 = 2 ergo:
nwns_threshold_2 = cpu2 will be hotplugged at this value
((2 - 1) * 2) + 1 = 3
nwns_threshold_3 = cpu1 will be unplugged at this value
etc...
Some values are:
NwNs_Threshold: 12, 0, 25, 20, 32, 28, 0, 35
TwTs_Threshold: 140, 0, 140, 190, 140, 190, 0, 190
Where the position and function of the number equals the result of the above explained formula.
(all times are in ms)
If you want to see the mpdecision magic happening:
Code:
adb shell
cat /proc/kmsg | grep 'MPDEC'
mpdecision's input event boost, aka project butter
This will boost your min cpu speed if you touch the screen or press a button and gives you full control.
In those events the min cpu freq will be risen to a predefined value (look below) on every online cpu. This boosts overall reaction times and smoothness a lot. (works similar to the qcom mpdecision binary)
Configuration files:
[email protected]:/sys/kernel/msm_mpdecision/conf # ls | grep boost
boost_enabled
boost_freqs
boost_time
All of them work like the usual sysfs files, except one special case:
boost_freqs will list all frequencies from cpu 0 to cpu x. Cpu 3 and any following cpu will share one frequency.
To change those frequencies echo the cpu number + the frequency in khz.
Example: To change the boost freq of cpu3 (and 4,5,6,7,8, etc) the echo would look as follows:
Code:
echo "3 960000" > /sys/kernel/msm_mpdecision/conf/boost_freqs
for cpu0:
Code:
echo "0 960000" > /sys/kernel/msm_mpdecision/conf/boost_freqs
Defaults:
Code:
cat /sys/kernel/msm_mpdecision/conf/boost_freqs
960000
960000
729600
576000
Why do I have no WLAN?
Due to this kernels very high optimization settings it is too big for our boot.img with WLAN included into the kernel, so it is built as a module. That means it needs to be inserted into the kernel upon boot up, which needs to be automated for maximum comfort.
The zip adds module insertion to your ramdisk, if that fails for some reason the wlan module cannot be inserted.
if
Code:
adb shell lsmod
doesn't show this:
Code:
tun 14701 0 - Live 0x00000000
cifs 275399 0 - Live 0x00000000
bcmdhd 2964650 0 - Live 0x00000000 (C)
Then something went horribly wrong.
Chances are that I broke it and this should never happen.
One post in the issue tracker will probably fix it with the next release
You can restore wlan for your current bootup by executing:
Code:
adb shell
su
insmod /system/lib/modules/bcmdhd.ko
Is there an app available to customize this pure bodacious and awesome kernel?
Yes there is: KControl. It's in the Google Playstore.

A few benchmark results:
Vellamo Metal:
http://vellamo2.quicinc.com/api/v2/app/plot/Metal/submission/PEE3B604B-8C49-69F5-001E-6BCA76DF491D
(usually ranges from 11xx-12xx. Depending on system background load, thermal status, air pressure, weather, world hunger, etc...)
Antutu:
https://plus.google.com/u/0/108262968419038009038/posts/VJbxpMoFJPN
(usually ranges from 28.xxx - 30.xxx. Depending on system background load, thermal status, air pressure, weather, world hunger, etc...)
3DMark Icestorm unlimited: (the others are maxed out)
https://plus.google.com/u/0/108262968419038009038/posts/N24t9ssoBcL
(17xxx)

FIRST! o yes!!! mwhahahah!! and so it begins

Finally a Bricked thread! :victory: No more F5 spamming the kernel website

Good stuff, you've finally joined the party.
Sent from my Nexus 5 using Tapatalk

Woot! first page!

+1
10 char

Ngo93 said:
Finally a Bricked thread! :victory: No more F5 spamming the kernel website
Click to expand...
Click to collapse
If you are familiar with rss, all kernel download pages have a little rss symbol, if you click it you get here:
http://bricked.de/kernelrss.php?action=krss&device=hammerhead&release=stable&type=aosp
Just something to consider instead of spamming F5
unforgivenmercy said:
Good stuff, you've finally joined the party.
Click to expand...
Click to collapse
If you take a look at the dates on my homepage you might notice that the party ended about 2 days ago. The after party on the other hand starts now!
faux123 said:
Woot! first page!
Click to expand...
Click to collapse
Indeed! Well the thread isn't that old yet

OBI ONE is here aweseome !!! Always a pleasure to hang around in ur threads

n3ocort3x said:
OBI ONE is here aweseome !!! Always a pleasure to hang around in ur threads
Click to expand...
Click to collapse
left something on github for you

I saw, many thanks for that, but i think i have to ask u a bit about this, already in bed now, but tomorrow is another day 5star and subscribed as always

show-p1984 said:
left something on github for you
Click to expand...
Click to collapse
In the op it just says to install. So no wiping of cache or D cache correct? Sorry just re assuring
Sent from my Nexus 5 using Tapatalk

Wiping cache is redundant and you don't have to do it with kernels.
Sent from my Nexus 5 using Tapatalk

Carbajal3009 said:
In the op it just says to install. So no wiping of cache or D cache correct? Sorry just re assuring
Sent from my Nexus 5 using Tapatalk
Click to expand...
Click to collapse
The zip does it for you.
However, if it gives you a warm and fuzzy feeling you are free to do it again (so twice then ^^).

Wow, finally it is here. Flashing now.

Has anyone actually demonstrated (scientifically or otherwise) anything wrong with the qcom mpdecision binary? Im not taking anything away from kernel developers who write their own mpdecision (especially those who also provides sources), but I am curious as to whether they are actually better than those provided by qcom. Surely they know more about the capabilities of their own cpus better than anyone no?

jazzor said:
Has anyone actually demonstrated (scientifically or otherwise) anything wrong with the qcom mpdecision binary? Im not taking anything away from kernel developers who write their own mpdecision (especially those who also provides sources), but I am curious as to whether they are actually better than those provided by qcom. Surely they know more about the capabilities of their own cpus better than anyone no?
Click to expand...
Click to collapse
A fair question, I imagine there is something sacrificed using either or.
Sent from my Nexus 5 using XDA Premium 4 mobile app

jazzor said:
Has anyone actually demonstrated (scientifically or otherwise) anything wrong with the qcom mpdecision binary? Im not taking anything away from kernel developers who write their own mpdecision (especially those who also provides sources), but I am curious as to whether they are actually better than those provided by qcom. Surely they know more about the capabilities of their own cpus better than anyone no?
Click to expand...
Click to collapse
It's not that complicated (there is no black voodoo magic), that's why bricked kernel was the first to introduce this feature back on the pyramid.
CPUs need to be plugged in / unplugged based on load, there is nothing more qcom can know that we can't also see inside of the kernel.
There is one HUGE thing that is wrong with qcom's mpdecision: It's closed. It's a black box. We don't have any idea what is going on in there. Literally, none. It's not even configurable. It could contain secret nsa code, or send dirty sms to your girlfriend (who might actually enjoy that, idk...)
If we would have source, hell, awesome. I wouldn't have spent over a year (first commit: Date: Thu, 21 Jun 2012 06:06:47 +0200, see here) to get my msm_mpdecision solution to the point where it is a) awesome and b) a lot better than the binary. It can be configured in any way you might need to. It features statistics on how often and how long a cpu is hotplugged. It has the input event boost. It's the full package deal.
If you compare my kernel with the stock kernel you will see huge performance improvements and battery savings on bricked. Those are not only because of my msm_mpdecision but certainly related. Furthermore: we can completely customize it, over sysfs, on a running kernel, without reflashing.
That's what I would have expected from qcom in the first place.
Another thing wrong with qcom's binary: It's static. Meaning: If you change your min freq on stock it will always reset back to defaults. Same with their thermal binary. That's just annoying.
msm_mpdecision will notice it if you change your min frequency and dynamically work with that from there on. It will also prevent hotplug wars between apps and it: eg: an app plugs in cpus to grab some cpu data (like frequencies, etc. That is only available if the cpu is plugged in). Qcom's mpdecision would now raise hell to keep that cpu unplugged, my msm_mpdecision just sits back and chills for 10 seconds to avoid those wars. (again, even that delay is fully configurable)
There are also a bunch of boring advantages as to why it is better to let something crucial to the system run in kernel space and not in user space, but that would most certainly explode the context of this thread by the factor of 4.
My solution is not inferior to that binary in any way, in fact it has been vastly superior in my testing up until now, otherwise I would a) improve it or b) ditch it. I don't keep around bad stuff just for the point of having it or because I wrote it. If it sucks I will say that and act accordingly.

Thanks for the very informative post. I suppose there are advantages in avoiding qcom's mpdecision. Though i'd like to point out that the Android framework (msm power HAL) does use some of the interfaces provided by the binary (see hardware/qcom/power/). With the nexus 4, this will spam a lot of stuff to logcat if you are missing this interface, not sure if this is the same with the nexus 5, but judging by the sources it seems it will. Maybe you could provide some notification about this side effect.
Similarly, this could apply to the thermal side of things as well.

[KERNEL][INTL][TW 4.4][12/08/2014] KT-NOTE4 - NIH - KTweaker

Ktoonsez presents:
{
"lightbox_close": "Close",
"lightbox_next": "Next",
"lightbox_previous": "Previous",
"lightbox_error": "The requested content cannot be loaded. Please try again later.",
"lightbox_start_slideshow": "Start slideshow",
"lightbox_stop_slideshow": "Stop slideshow",
"lightbox_full_screen": "Full screen",
"lightbox_thumbnails": "Thumbnails",
"lightbox_download": "Download",
"lightbox_share": "Share",
"lightbox_zoom": "Zoom",
"lightbox_new_window": "New window",
"lightbox_toggle_sidebar": "Toggle sidebar"
}

KT-NOTE4 kernel features
•Must have a Note 4 model N910F or N910G
•Must have a Touchwiz Rooted ROM
•Must have CWM/TWRP based recovery installed
•Samsung open source
•Optimized kernel configuration
•unsecure root adb
•Voltage interface
•KTweaker app for kernel control
•KTweaker Widgets
•Schedulers (CFQ, BFQ, VR, SIO, NOOP, DEADLINE, ROW, FIFO, FIOPS)
•GOVERNORS (ktoonservativeq, intellidemand, msm-dcvs, wheatley, userspace, smartassh3, slp, powersave, pegasuq, nightmare, interactive, dancedance, conservative, badass, asswax, adaptive, abyssplug, performance, ondemand
•exFAT for Touchwiz
Click to expand...
Click to collapse
Touchwiz Kitkat 4.4 VERSION:
12.08.2014: http://goo.gl/CzCxtx
Click to expand...
Click to collapse
Always do the following AFTER installing the kernel:
1. Clear cache
2. Clear dalvik
Post #2 will be reserved for change logs
Post #3 will be reserved for MY Settings, Extras and FAQ's
Sources can be found here:
https://github.com/ktoonsez/KTNOTE4

Go to my original thread to view Change logs:
http://forum.xda-developers.com/showpost.php?p=56676105&postcount=2

ktoonservativeq explained:
***** NOTES *****
Any item with the word cycle in it refers to how many sampling_rate's have occurred.
Examples:
A "boost_hold_cycles" of 22 and a sampling_rate of 45000 equates to 1 seconds of holding your Mhz at the boost level.
A block_cycles_offline_screen_on of 11 and a sampling_rate of 45000 equates to a half of a second block before it takes cores offline.
***** NOTES *****
block_cycles_offline_screen_off =1
How many sampling_rate cycles need to occur before a core is allowed to go OFFLINE while the screen is OFF.
block_cycles_offline_screen_on = 11
How many sampling_rate cycles need to occur before a core is allowed to go OFFLINE while the screen is ON.
block_cycles_online_screen_off = 11
How many sampling_rate cycles need to occur before a core is allowed to go ONLINE while the screen is OFF.
block_cycles_online_screen_on = 3
How many sampling_rate cycles need to occur before a core is allowed to go ONLINE while the screen is ON.
block_cycles_raise_screen_off = 11
How many sampling_rate cycles need to occur before the current Mhz is allowed to be raised while the screen is OFF.
block_cycles_raise_screen_on = 3
How many sampling_rate cycles need to occur before the current Mhz is allowed to be raised while the screen is ON.
boost_2nd_core_on_button_screen_off = 1
When this item is a 1, it will turn on the 2nd core when a button any hard button is pressed while the screen is OFF. 0 leaves the core in its current state.
boost_2nd_core_on_button_screen_on = 1
When this item is a 1, it will turn on the 2nd core when a button any hard button is pressed while the screen is ON. 0 leaves the core in its current state.
boost_3rd_core_on_button_screen_off = 0
When this item is a 1, it will turn on the 3nd core when a button any hard button is pressed while the screen is OFF. 0 leaves the core in its current state.
boost_3rd_core_on_button_screen_on = 0
When this item is a 1, it will turn on the 3nd core when a button any hard button is pressed while the screen is ON. 0 leaves the core in its current state.
boost_4th_core_on_button_screen_off = 0
When this item is a 1, it will turn on the 4nd core when a button any hard button is pressed while the screen is OFF. 0 leaves the core in its current state.
boost_4th_core_on_button_screen_on = 0
When this item is a 1, it will turn on the 4nd core when a button any hard button is pressed while the screen is ON. 0 leaves the core in its current state.
boost_hold_cycles = 22
How many sampling_rate cycles need to occur before going out of CPU/GPU boost mode
disable_hotplug = 0
When this item is a 1, it disables hotplugging so all cores stay on full time. 0 lets all cores turn on and off when needed.
disable_hotplug_bt = 0
When this item is a 1, it disables hotplugging so all cores stay on full time while paired to a bluetooth device and doing bluetooth activities like playing music, transfering files.... 0 doesn't do anything extra to the cores when doing bluetooth functions.
disable_hotplug_chrg = 0
When this item is a 1, it disables hotplugging so all cores stay on full time while charging the device. 0 doesn't do anything extra to the cores while charging.
disable_hotplug_media = 0
When this item is a 1, it disables hotplugging so all cores stay on full time while playing music or movies. 0 doesn't do anything extra to the cores while music or movies are playing.
down_threshold_screen_off = 52
A percentage of CPU utilization that needs to occur before the current Mhz begins to lower while screen is OFF.
down_threshold_screen_off_hotplug_1 = 35
A percentage of CPU utilization that needs to occur before the 2nd core is taken offline while screen is OFF.
down_threshold_screen_off_hotplug_2 = 45
A percentage of CPU utilization that needs to occur before the 3rd core is taken offline while screen is OFF.
down_threshold_screen_off_hotplug_3 = 55
A percentage of CPU utilization that needs to occur before the 4th core is taken offline while screen is OFF.
down_threshold_screen_on = 52
A percentage of CPU utilization that needs to occur before the current Mhz begins to lower while screen is ON.
down_threshold_screen_on_hotplug_1 = 35
A percentage of CPU utilization that needs to occur before the 2nd core is taken offline while screen is ON.
down_threshold_screen_on_hotplug_2 = 45
A percentage of CPU utilization that needs to occur before the 3rd core is taken offline while screen is ON.
down_threshold_screen_on_hotplug_3 = 55
A percentage of CPU utilization that needs to occur before the 4th core is taken offline while screen is ON.
freq_step_lower_screen_off = 8
How many steps from the Mhz table (the entire Mhz table can bee seen in the CPU Voltage screen) it skips when lowering the current Mhz while the screen is OFF.
freq_step_lower_screen_on = 2
How many steps from the Mhz table (the entire Mhz table can bee seen in the CPU Voltage screen) it skips when lowering the current Mhz while the screen is ON.
freq_step_raise_screen_off = 1
How many steps from the Mhz table (the entire Mhz table can bee seen in the CPU Voltage screen) it skips when raising the current Mhz while the screen is OFF.
freq_step_raise_screen_on = 5
How many steps from the Mhz table (the entire Mhz table can bee seen in the CPU Voltage screen) it skips when raising the current Mhz while the screen is ON.
ignore_nice_load = 0
If this value is "1," the system will ignore "Nice" processes when deciding to scale up or down. Nice processes are used by the IO scheduler to designate a low-priority process. Ignore nice load basically tells a governor to disregard processes with higher nice values.
lockout_2nd_core_hotplug_screen_off = 0
This is a 3 way option. While the screen is OFF, 0 = Hotplug Normal so the core will go on and off as needed, 1 = Lock this core always ON, 2 = Lock this core always OFF.
lockout_2nd_core_hotplug_screen_on = 0
This is a 3 way option. While the screen is ON, 0 = Hotplug Normal so the core will go on and off as needed, 1 = Lock this core always ON, 2 = Lock this core always OFF.
lockout_3rd_core_hotplug_screen_off = 0
This is a 3 way option. While the screen is OFF, 0 = Hotplug Normal so the core will go on and off as needed, 1 = Lock this core always ON, 2 = Lock this core always OFF.
lockout_3rd_core_hotplug_screen_on = 0
This is a 3 way option. While the screen is ON, 0 = Hotplug Normal so the core will go on and off as needed, 1 = Lock this core always ON, 2 = Lock this core always OFF.
lockout_4th_core_hotplug_screen_off = 0
This is a 3 way option. While the screen is OFF, 0 = Hotplug Normal so the core will go on and off as needed, 1 = Lock this core always ON, 2 = Lock this core always OFF.
lockout_4th_core_hotplug_screen_on = 0
This is a 3 way option. While the screen is ON, 0 = Hotplug Normal so the core will go on and off as needed, 1 = Lock this core always ON, 2 = Lock this core always OFF.
no_extra_cores_screen_off = 1
When set to a 1, this option keeps all extra CPU cores offline while the screen is OFF. 0 lets it hotplug them on and off as needed
sampling_down_factor = 1
NOT USED!
sampling_rate = 45000
The amount of milliseconds that the governor will analyze the CPU usage and adjust for changes in load while the screen is ON.
sampling_rate_min = 10000
READ-ONLY value that specifies the lower value that "sampling_rate" and "sampling_rate_screen_off" will accept.
sampling_rate_screen_off = 45000
The amount of milliseconds that the governor will analyze the CPU usage and adjust for changes in load while the screen is OFF.
super_conservative_screen_off = 0
With the screen OFF: When set to a 1, this option will explicitly obey your block cycles settings to be a super battery saver (Setting a 1 will slow down the UI a little bit). When set to a 0 it uses fuzzy logic on the "block cycle" items.
super_conservative_screen_on = 0
With the screen ON: When set to a 1, this option will explicitly obey your block cycles settings to be a super battery saver (Setting a 1 will slow down the UI a little bit). When set to a 0 it uses fuzzy logic on the "block cycle" items to create a smooooooth UI experience.
sync_extra_cores_screen_off = 0
With the screen OFF: When set to a 1, all online cores will be sync'd to the same speed as core 0. When set to a 0, all cores will operate at speeds independant of each other.
sync_extra_cores_screen_on = 0
With the screen ON: When set to a 1, all online cores will be sync'd to the same speed as core 0. When set to a 0, all cores will operate at speeds independant of each other.
touch_boost_2nd_core = 1
When set to a 1, this option turns on the 2nd core when the screen is touched. When set to a 0 it doesn't do anything extra to the cores.
touch_boost_3rd_core = 0
When set to a 1, this option turns on the 3rd core when the screen is touched. When set to a 0 it doesn't do anything extra to the cores.
touch_boost_4th_core = 0
When set to a 1, this option turns on the 4th core when the screen is touched. When set to a 0 it doesn't do anything extra to the cores.
touch_boost_cpu = 1804800
The Mhz that you want the online CPU's to jump to when the screen is touched.
touch_boost_cpu_all_cores = 0
When set to a 1, this option sets the current Mhz on all online cores to the selected touch_boost_cpu value.
touch_boost_gpu = 462400
This value specifies what Mhz the GPU should jump to when the screen is touched.
up_threshold_screen_off = 57
A percentage of CPU utilization that needs to occur before the current Mhz begins to raise while screen is OFF.
up_threshold_screen_off_hotplug_1 = 58
A percentage of CPU utilization that needs to occur before the 2nd core is put online while screen is OFF.
up_threshold_screen_off_hotplug_2 = 68
A percentage of CPU utilization that needs to occur before the 3rd core is put online while screen is OFF.
up_threshold_screen_off_hotplug_3 = 78
A percentage of CPU utilization that needs to occur before the 4th core is put online while screen is OFF.
up_threshold_screen_on = 57
A percentage of CPU utilization that needs to occur before the current Mhz begins to raise while screen is ON.
up_threshold_screen_on_hotplug_1 = 58
A percentage of CPU utilization that needs to occur before the 2nd core is put online while screen is ON.
up_threshold_screen_on_hotplug_2 = 68
A percentage of CPU utilization that needs to occur before the 3rd core is put online while screen is ON.
up_threshold_screen_on_hotplug_3 = 78
A percentage of CPU utilization that needs to occur before the 4th core is put online while screen is ON.
Other Governors and schedulers explained:
http://forum.xda-developers.com/showthread.php?t=1687578
http://forum.xda-developers.com/showthread.php?t=1369817
http://tinzdroid.blogspot.com/2012/07/android-kernel-governors-modules-io.html
http://forum.xda-developers.com/showpost.php?p=21638852&postcount=56

Need testers!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

Welcome KToons - i was a huge fan of your Galaxy S4 Kernel. Glad to see you joining the Note 4 endeavor !!!

@ktoonsez
wow!!! welcome mate!! glad and happy to see you here!! What a surprise , you got note 4 ? I was using kt kernel on my s4 for a very long time, now you have given me a reson to root my device earlier

Oh nice! Testing now.

poczynek said:
Oh nice! Testing now.
Click to expand...
Click to collapse
I need o PM u th link unless u already found it on my Tmobile thread???

ktoonsez said:
I need o PM u th link unless u already found it on my Tmobile thread???
Click to expand...
Click to collapse
Yes a pm would be great. Thanks.

poczynek said:
Yes a pm would be great. Thanks.
Click to expand...
Click to collapse
PM Sent :good: :highfive:

bala_gamer said:
@ktoonsez
wow!!! welcome mate!! glad and happy to see you here!! What a surprise , you got note 4 ? I was using kt kernel on my s4 for a very long time, now you have given me a reson to root my device earlier
Click to expand...
Click to collapse
Got the S5 right now and the devices are nearly identical and so many people asked me to PLEEEEEEEEEASE build one so I am getting a head start while I save up and sharing

Anybody with the N910F want to test, so far the N910G does not want to boot.

ktoonsez said:
Anybody with the N910F want to test, so far the N910G does not want to boot.
Click to expand...
Click to collapse
oops thats bad, i was about to root my device for testing this on my 910g, can u pm me the link? let me give it a try as it wont hard brick my device

bala_gamer said:
oops thats bad, i was about to root my device for testing this on my 910g, can u pm me the link? let me give it a try as it wont hard brick my device
Click to expand...
Click to collapse
PM Sent :good: :highfive:

Oh my god KT you're here! !
---------- Post added at 03:59 PM ---------- Previous post was at 03:58 PM ----------
I've got a G model bro

rlorange said:
Oh my god KT you're here! !
---------- Post added at 03:59 PM ---------- Previous post was at 03:58 PM ----------
I've got a G model bro
Click to expand...
Click to collapse
Good to see u man!!!!!!!!!! PM sent.

I'm glad to see you here. If You want me to test the kernel I have a N910F.

mcreego said:
I'm glad to see you here. If You want me to test the kernel I have a N910F.
Click to expand...
Click to collapse
What ROM are you on mate?

mcreego said:
I'm glad to see you here. If You want me to test the kernel I have a N910F.
Click to expand...
Click to collapse
So far nobody can boot it on the "G" or "F", all other devices are working like:
SM-N910A
SM-N910S
SM-N910P
SM-N910T
SM-N910V
SM-N910W8

Echoe slim rom

Advanced Interactive Governor For Le Pro 3 (EX Kernel Manager) 2/19

Brief background on the idea. I was originally inspired by soniCron and their work with the SD808. I created a custom profile for my LG G4, which allowed me to get more SOT.
>
Suggestions for the Advanced section in EX Kernel Manager:
sched_upmigrate_min_nice = 0
sched_upmigrate = 95
sched_restrict_cluster_spill = 1
sched_downmigrate = 65
Under Misc, enable "wq_power_saving" too.
>
What's Required
1. Root
2. Kernel tuner app (Preferrably EX Kernel manager, as it can use the profiles, otherwise you need to input them manually)
3. Interactive Governor for both clusters
>
Steps
1. Download a profile
2. Unzip it, put the file (not folder) into the EX Kernel directory for profiles
(/ElementalX/gov_profiles)
3. Alternatively, put the values yourself if using a different app such as Kernel Auditor
>
Profiles
Bifrost v1: Tries to keep the frequencies low, avoids aggressive ramping up to the max freq on either cluster
View attachment Bifrost.zip
Bifrost v6
View attachment Bifrost_v6.zip
Beast Mode v1: Performance profile
View attachment Beast_Mode.zip
>
Manual Input
Bifrost v1:
/sys/devices/system/cpu/cpu0/cpufreq/interactive/go_hispeed_load 98
/sys/devices/system/cpu/cpu0/cpufreq/interactive/above_hispeed_delay 0
/sys/devices/system/cpu/cpu0/cpufreq/interactive/hispeed_freq_hysteresis 0
/sys/devices/system/cpu/cpu0/cpufreq/interactive/timer_rate 250000
/sys/devices/system/cpu/cpu0/cpufreq/interactive/hispeed_freq 537600
/sys/devices/system/cpu/cpu0/cpufreq/interactive/timer_slack 384000
/sys/devices/system/cpu/cpu0/cpufreq/interactive/target_loads 85 307200:39 384000:55 460000:64 537600:69 614400:74 768000:78 864000:81 902000:84 979200:87 1056000:90 1132800:91 1209600:92 1286400:93 1362000:94 1440000:95 1516800:98 1593600:99
/sys/devices/system/cpu/cpu0/cpufreq/interactive/min_sample_time 0
/sys/devices/system/cpu/cpu0/cpufreq/interactive/ignore_hispeed_on_notif 1
/sys/devices/system/cpu/cpu0/cpufreq/interactive/boost 0
/sys/devices/system/cpu/cpu0/cpufreq/interactive/fast_ramp_down 1
/sys/devices/system/cpu/cpu0/cpufreq/interactive/align_windows 1
/sys/devices/system/cpu/cpu0/cpufreq/interactive/use_migration_notif 1
/sys/devices/system/cpu/cpu0/cpufreq/interactive/use_sched_load 0
/sys/devices/system/cpu/cpu0/cpufreq/interactive/is_skip_max_logic 0
/sys/devices/system/cpu/cpu0/cpufreq/interactive/max_freq_hysteresis 0
/sys/devices/system/cpu/cpu0/cpufreq/interactive/boostpulse_duration 0
(Big cluster)
/sys/devices/system/cpu/cpu2/cpufreq/interactive/go_hispeed_load 99
/sys/devices/system/cpu/cpu2/cpufreq/interactive/above_hispeed_delay 60000 700000:70000 800000:80000 1000000:100000 1400000:140000 1500000:150000 1700000:170000 1800000:180000 1900000:190000 2100000:200000 2200000:220000 2300000:230000
/sys/devices/system/cpu/cpu2/cpufreq/interactive/hispeed_freq_hysteresis 0
/sys/devices/system/cpu/cpu2/cpufreq/interactive/timer_rate 480000
/sys/devices/system/cpu/cpu2/cpufreq/interactive/hispeed_freq 460800
/sys/devices/system/cpu/cpu2/cpufreq/interactive/timer_slack 384000
/sys/devices/system/cpu/cpu2/cpufreq/interactive/target_loads 95 307200:28 384000:33 480000:41 537600:46 614400:51 748800:58 825600:62 902400:67 1056000:70 1132800:72 1209600:74 1286400:76 1363200:78 1440000:80 1516800:82 1593600:85 1670400:87 1747200:89 1824000:92 1900800:94 1977600:96 2054400:97 2150400:98 2246400:99 2342400:100
/sys/devices/system/cpu/cpu2/cpufreq/interactive/min_sample_time 20000
/sys/devices/system/cpu/cpu2/cpufreq/interactive/ignore_hispeed_on_notif 1
/sys/devices/system/cpu/cpu2/cpufreq/interactive/boost 0
/sys/devices/system/cpu/cpu2/cpufreq/interactive/fast_ramp_down 1
/sys/devices/system/cpu/cpu2/cpufreq/interactive/align_windows 0
/sys/devices/system/cpu/cpu2/cpufreq/interactive/use_migration_notif 1
/sys/devices/system/cpu/cpu2/cpufreq/interactive/use_sched_load 1
/sys/devices/system/cpu/cpu2/cpufreq/interactive/is_skip_max_logic 0
/sys/devices/system/cpu/cpu2/cpufreq/interactive/max_freq_hysteresis 0
/sys/devices/system/cpu/cpu2/cpufreq/interactive/boostpulse_duration 0
Bifrost v6:
(small cluster)
/sys/devices/system/cpu/cpu0/cpufreq/interactive/go_hispeed_load 99
/sys/devices/system/cpu/cpu0/cpufreq/interactive/above_hispeed_delay 0
/sys/devices/system/cpu/cpu0/cpufreq/interactive/hispeed_freq_hysteresis 0
/sys/devices/system/cpu/cpu0/cpufreq/interactive/timer_rate 250000
/sys/devices/system/cpu/cpu0/cpufreq/interactive/hispeed_freq 460800
/sys/devices/system/cpu/cpu0/cpufreq/interactive/timer_slack 384000
/sys/devices/system/cpu/cpu0/cpufreq/interactive/target_loads 95 307200:35 384000:45 460000:55 537600:61 614400:66 768000:71 864000:76 902000:81 979200:86 1056000:90 1132800:91 1209600:92 1286400:93 1362000:94 1440000:96 1516800:98 1593600:99
/sys/devices/system/cpu/cpu0/cpufreq/interactive/min_sample_time 10000
/sys/devices/system/cpu/cpu0/cpufreq/interactive/ignore_hispeed_on_notif 1
/sys/devices/system/cpu/cpu0/cpufreq/interactive/boost 0
/sys/devices/system/cpu/cpu0/cpufreq/interactive/fast_ramp_down 1
/sys/devices/system/cpu/cpu0/cpufreq/interactive/align_windows 1
/sys/devices/system/cpu/cpu0/cpufreq/interactive/use_migration_notif 1
/sys/devices/system/cpu/cpu0/cpufreq/interactive/use_sched_load 0
/sys/devices/system/cpu/cpu0/cpufreq/interactive/is_skip_max_logic 0
/sys/devices/system/cpu/cpu0/cpufreq/interactive/max_freq_hysteresis 0
/sys/devices/system/cpu/cpu0/cpufreq/interactive/boostpulse_duration 0
(big cluster)
/sys/devices/system/cpu/cpu2/cpufreq/interactive/go_hispeed_load 200
/sys/devices/system/cpu/cpu2/cpufreq/interactive/above_hispeed_delay 40000 537600:60000 748800:80000 1056000:110000 1286400:140000 1440000:170000 1747200:200000 1900800:220000 2150400:250000 2342400:270000
/sys/devices/system/cpu/cpu2/cpufreq/interactive/hispeed_freq_hysteresis 0
/sys/devices/system/cpu/cpu2/cpufreq/interactive/timer_rate 200000
/sys/devices/system/cpu/cpu2/cpufreq/interactive/hispeed_freq 460800
/sys/devices/system/cpu/cpu2/cpufreq/interactive/timer_slack 384000
/sys/devices/system/cpu/cpu2/cpufreq/interactive/target_loads 95 307200:28 384000:33 480000:41 537600:46 614400:51 748800:58 825600:62 902400:67 1056000:70 1132800:72 1209600:74 1286400:76 1363200:78 1440000:80 1516800:82 1593600:85 1670400:87 1747200:89 1824000:92 1900800:94 1977600:96 2054400:97 2150400:98 2246400:99 2342400:100
/sys/devices/system/cpu/cpu2/cpufreq/interactive/min_sample_time 10000
/sys/devices/system/cpu/cpu2/cpufreq/interactive/ignore_hispeed_on_notif 1
/sys/devices/system/cpu/cpu2/cpufreq/interactive/boost 0
/sys/devices/system/cpu/cpu2/cpufreq/interactive/fast_ramp_down 1
/sys/devices/system/cpu/cpu2/cpufreq/interactive/align_windows 0
/sys/devices/system/cpu/cpu2/cpufreq/interactive/use_migration_notif 1
/sys/devices/system/cpu/cpu2/cpufreq/interactive/use_sched_load 1
/sys/devices/system/cpu/cpu2/cpufreq/interactive/is_skip_max_logic 0
/sys/devices/system/cpu/cpu2/cpufreq/interactive/max_freq_hysteresis 0
/sys/devices/system/cpu/cpu2/cpufreq/interactive/boostpulse_duration 0
Beast v1:
/sys/devices/system/cpu/cpu0/cpufreq/interactive/go_hispeed_load 200
/sys/devices/system/cpu/cpu0/cpufreq/interactive/above_hispeed_delay 0
/sys/devices/system/cpu/cpu0/cpufreq/interactive/hispeed_freq_hysteresis 0
/sys/devices/system/cpu/cpu0/cpufreq/interactive/timer_rate 50000
/sys/devices/system/cpu/cpu0/cpufreq/interactive/hispeed_freq 768000
/sys/devices/system/cpu/cpu0/cpufreq/interactive/timer_slack -1
/sys/devices/system/cpu/cpu0/cpufreq/interactive/target_loads 80 307200:25 384000:38 460000:46 537600:50 614400:54 768000:58 864000:62 902000:65 979200:70 1056000:80 1132800:85 1209600:89 1286400:92 1362000:94 1440000:96 1516800:98 1593600:99 2188800:100
/sys/devices/system/cpu/cpu0/cpufreq/interactive/min_sample_time 0
/sys/devices/system/cpu/cpu0/cpufreq/interactive/ignore_hispeed_on_notif 1
/sys/devices/system/cpu/cpu0/cpufreq/interactive/boost 0
/sys/devices/system/cpu/cpu0/cpufreq/interactive/fast_ramp_down 0
/sys/devices/system/cpu/cpu0/cpufreq/interactive/align_windows 1
/sys/devices/system/cpu/cpu0/cpufreq/interactive/use_migration_notif 1
/sys/devices/system/cpu/cpu0/cpufreq/interactive/use_sched_load 0
/sys/devices/system/cpu/cpu0/cpufreq/interactive/is_skip_max_logic 0
/sys/devices/system/cpu/cpu0/cpufreq/interactive/max_freq_hysteresis 0
/sys/devices/system/cpu/cpu0/cpufreq/interactive/boostpulse_duration 0
/sys/devices/system/cpu/cpu2/cpufreq/interactive/go_hispeed_load 200
/sys/devices/system/cpu/cpu2/cpufreq/interactive/above_hispeed_delay 0
/sys/devices/system/cpu/cpu2/cpufreq/interactive/hispeed_freq_hysteresis 0
/sys/devices/system/cpu/cpu2/cpufreq/interactive/timer_rate 40000
/sys/devices/system/cpu/cpu2/cpufreq/interactive/hispeed_freq 825600
/sys/devices/system/cpu/cpu2/cpufreq/interactive/timer_slack -1
/sys/devices/system/cpu/cpu2/cpufreq/interactive/target_loads 90 307200:28 384000:30 480000:40 537600:45 614400:60 748800:65 825600:69 902400:70 1056000:72 1132800:74 1209600:76 1286400:77 1363200:78 1440000:80 1516800:82 1593600:85 1670400:87 1747200:89 1824000:92 1900800:94 1977600:96 2054400:97 2150400:98 2246400:99 2342400:100
/sys/devices/system/cpu/cpu2/cpufreq/interactive/min_sample_time 20000
/sys/devices/system/cpu/cpu2/cpufreq/interactive/ignore_hispeed_on_notif 1
/sys/devices/system/cpu/cpu2/cpufreq/interactive/boost 0
/sys/devices/system/cpu/cpu2/cpufreq/interactive/fast_ramp_down 0
/sys/devices/system/cpu/cpu2/cpufreq/interactive/align_windows 0
/sys/devices/system/cpu/cpu2/cpufreq/interactive/use_migration_notif 1
/sys/devices/system/cpu/cpu2/cpufreq/interactive/use_sched_load 1
/sys/devices/system/cpu/cpu2/cpufreq/interactive/is_skip_max_logic 0
/sys/devices/system/cpu/cpu2/cpufreq/interactive/max_freq_hysteresis 0
/sys/devices/system/cpu/cpu2/cpufreq/interactive/boostpulse_duration 0
>
Benchmarks (Beast v1 & Bifrost v1 compared)
{
"lightbox_close": "Close",
"lightbox_next": "Next",
"lightbox_previous": "Previous",
"lightbox_error": "The requested content cannot be loaded. Please try again later.",
"lightbox_start_slideshow": "Start slideshow",
"lightbox_stop_slideshow": "Stop slideshow",
"lightbox_full_screen": "Full screen",
"lightbox_thumbnails": "Thumbnails",
"lightbox_download": "Download",
"lightbox_share": "Share",
"lightbox_zoom": "Zoom",
"lightbox_new_window": "New window",
"lightbox_toggle_sidebar": "Toggle sidebar"
}

Honestly, I find it strange that you are claiming 11+ SOT when the actual usage is very low. What sorts of activities did you do over those 11 hours period? I am guessing more standby time and just glancing at notifications, email etc? 11 hours period should maximize the battery capacity of Le Pro 3 so we should be seeing at least 3500+ computed power usage here.
Here is a typical medium usage on the Le Pro 3 and its SOT.

Joms_US said:
Honestly, I find it strange that you are claiming 11+ SOT when the actual usage is very low. What sorts of activities did you do over those 11 hours period? I am guessing more standby time and just glancing at notifications, email etc? 11 hours period should maximize the battery capacity of Le Pro 3 so we should be seeing at least 3500+ computed power usage here.
Here is a typical medium usage on the Le Pro 3 and its SOT.
Click to expand...
Click to collapse
Voice calls, messaging (Textra or kik), Feedly, mail (Inbox+Alto), browsing (Opera Mini & CS Beta), ~20-30mins YouTube, XDA app, updating apps, various shopping apps (Amazon, eBay, etc), and Google Keep for notes/to-do list. Sometimes I might take a few pictures, but no video recording. Do I play games? Yes, but not often. I have quite a few intensive games. Again, I'll update the post with recent stats.
Edit: If you check the original thread by soniCron you'll see that many users have seen the benefit of using a custom profile.

Ace42 said:
Voice calls, messaging (Textra or kik), Feedly, mail (Inbox+Alto), browsing (Opera Mini & CS Beta), ~20-30mins YouTube, XDA app, updating apps, various shopping apps (Amazon, eBay, etc), and Google Keep for notes/to-do list. Sometimes I might take a few pictures, but no video recording. Do I play games? Yes, but not often. I have quite a few intensive games. Again, I'll update the post with recent stats.
Edit: If you check the original thread by soniCron you'll see that many users have seen the benefit of using a custom profile.
Click to expand...
Click to collapse
Would you please charge it at 100% and run PCMark Work Battery Life? This will be a very good indicator on how effective your profile is. Set the display brightness to about 40% (200 nits) TIA

If you want to try more profiles there is a HUUUUGE thread over at OP3 forums. Lots of profiles. As a OP3 owner I can tell you that these profiles do make a difference. I wish we can get a custom kernel that lets us turn off input boost so we can save more power with these profiles.
https://forum.xda-developers.com/oneplus-3/how-to/advanced-interactive-governor-tweaks-t3476589

Joms_US said:
Would you please charge it at 100% and run PCMark Work Battery Life? This will be a very good indicator on how effective your profile is. Set the display brightness to about 40% (200 nits) TIA
Click to expand...
Click to collapse
Sure. I'll compare both profiles to see if there's a difference.
Tikerz said:
If you want to try more profiles there is a HUUUUGE thread over at OP3 forums. Lots of profiles. As a OP3 owner I can tell you that these profiles do make a difference. I wish we can get a custom kernel that lets us turn off input boost so we can save more power with these profiles.
https://forum.xda-developers.com/oneplus-3/how-to/advanced-interactive-governor-tweaks-t3476589
Click to expand...
Click to collapse
The frequency table is a bit different from the OP3.

Ace42 said:
Brief background on the idea. I was originally inspired by soniCron and their work with the SD808. I created a custom profile for my LG G4, which allowed me to get 6-7hrs SOT using interactive.
Now, I have a Pro 3, which uses the SD821. I've been doing various battery related tests on this phone too. The highest SOT I've seen on this phone was nearly 12hrs by using less than the battery's full capacity (strictly use 90-20%, equating to 70% of the capacity. Imagine 13-14+ with a full discharge). I can't promise that the experience will be the same for you, but my screenshots basically show the effectiveness of custom parameters.
So far I've focused on a battery efficient profile, as I don't care as much about having the best performance. However, I will create a perf profile by testing it with games later on.
>
What's Required
1. Root
2. Kernel tuner app (Preferrably EX Kernel manager, as it can use the profiles, otherwise you need to input them manually)
3. Interactive Governor for both clusters
4. MUST disable touchboost (Don't know if any app besides EX has this feature YMMV)
>
Steps
1. Download a profile
2. Unzip it, put the file (not folder) into the EX Kernel directory for profiles
(/ElementalX/gov_profiles)
3. Alternatively, put the values yourself if using a different app such as Kernel Auditor
>
Profiles
Bifrost v1: Tries to keep the frequencies low, avoids aggressive ramping up to the max freq on either cluster
View attachment 3992868
Beast Mode v1: Performance profile
View attachment 3992995
>
Manual Input
Bifrost:
/sys/devices/system/cpu/cpu0/cpufreq/interactive/go_hispeed_load 98
/sys/devices/system/cpu/cpu0/cpufreq/interactive/above_hispeed_delay 0
/sys/devices/system/cpu/cpu0/cpufreq/interactive/hispeed_freq_hysteresis 0
/sys/devices/system/cpu/cpu0/cpufreq/interactive/timer_rate 250000
/sys/devices/system/cpu/cpu0/cpufreq/interactive/hispeed_freq 537600
/sys/devices/system/cpu/cpu0/cpufreq/interactive/timer_slack 384000
/sys/devices/system/cpu/cpu0/cpufreq/interactive/target_loads 85 307200:39 384000:55 460000:64 537600:69 614400:74 768000:78 864000:81 902000:84 979200:87 1056000:90 1132800:91 1209600:92 1286400:93 1362000:94 1440000:95 1516800:98 1593600:99
/sys/devices/system/cpu/cpu0/cpufreq/interactive/min_sample_time 0
/sys/devices/system/cpu/cpu0/cpufreq/interactive/ignore_hispeed_on_notif 1
/sys/devices/system/cpu/cpu0/cpufreq/interactive/boost 0
/sys/devices/system/cpu/cpu0/cpufreq/interactive/fast_ramp_down 1
/sys/devices/system/cpu/cpu0/cpufreq/interactive/align_windows 1
/sys/devices/system/cpu/cpu0/cpufreq/interactive/use_migration_notif 1
/sys/devices/system/cpu/cpu0/cpufreq/interactive/use_sched_load 0
/sys/devices/system/cpu/cpu0/cpufreq/interactive/is_skip_max_logic 0
/sys/devices/system/cpu/cpu0/cpufreq/interactive/max_freq_hysteresis 0
/sys/devices/system/cpu/cpu0/cpufreq/interactive/boostpulse_duration 0
(Big cluster)
/sys/devices/system/cpu/cpu2/cpufreq/interactive/go_hispeed_load 99
/sys/devices/system/cpu/cpu2/cpufreq/interactive/above_hispeed_delay 60000 700000:70000 800000:80000 1000000:100000 1400000:140000 1500000:150000 1700000:170000 1800000:180000 1900000:190000 2100000:200000 2200000:220000 2300000:230000
/sys/devices/system/cpu/cpu2/cpufreq/interactive/hispeed_freq_hysteresis 0
/sys/devices/system/cpu/cpu2/cpufreq/interactive/timer_rate 480000
/sys/devices/system/cpu/cpu2/cpufreq/interactive/hispeed_freq 460800
/sys/devices/system/cpu/cpu2/cpufreq/interactive/timer_slack 384000
/sys/devices/system/cpu/cpu2/cpufreq/interactive/target_loads 95 307200:28 384000:33 480000:41 537600:46 614400:51 748800:58 825600:62 902400:67 1056000:70 1132800:72 1209600:74 1286400:76 1363200:78 1440000:80 1516800:82 1593600:85 1670400:87 1747200:89 1824000:92 1900800:94 1977600:96 2054400:97 2150400:98 2246400:99 2342400:100
/sys/devices/system/cpu/cpu2/cpufreq/interactive/min_sample_time 20000
/sys/devices/system/cpu/cpu2/cpufreq/interactive/ignore_hispeed_on_notif 1
/sys/devices/system/cpu/cpu2/cpufreq/interactive/boost 0
/sys/devices/system/cpu/cpu2/cpufreq/interactive/fast_ramp_down 1
/sys/devices/system/cpu/cpu2/cpufreq/interactive/align_windows 0
/sys/devices/system/cpu/cpu2/cpufreq/interactive/use_migration_notif 1
/sys/devices/system/cpu/cpu2/cpufreq/interactive/use_sched_load 1
/sys/devices/system/cpu/cpu2/cpufreq/interactive/is_skip_max_logic 0
/sys/devices/system/cpu/cpu2/cpufreq/interactive/max_freq_hysteresis 0
/sys/devices/system/cpu/cpu2/cpufreq/interactive/boostpulse_duration 0
Beast:
/sys/devices/system/cpu/cpu0/cpufreq/interactive/go_hispeed_load 200
/sys/devices/system/cpu/cpu0/cpufreq/interactive/above_hispeed_delay 0
/sys/devices/system/cpu/cpu0/cpufreq/interactive/hispeed_freq_hysteresis 0
/sys/devices/system/cpu/cpu0/cpufreq/interactive/timer_rate 50000
/sys/devices/system/cpu/cpu0/cpufreq/interactive/hispeed_freq 768000
/sys/devices/system/cpu/cpu0/cpufreq/interactive/timer_slack -1
/sys/devices/system/cpu/cpu0/cpufreq/interactive/target_loads 80 307200:25 384000:38 460000:46 537600:50 614400:54 768000:58 864000:62 902000:65 979200:70 1056000:80 1132800:85 1209600:89 1286400:92 1362000:94 1440000:96 1516800:98 1593600:99 2188800:100
/sys/devices/system/cpu/cpu0/cpufreq/interactive/min_sample_time 0
/sys/devices/system/cpu/cpu0/cpufreq/interactive/ignore_hispeed_on_notif 1
/sys/devices/system/cpu/cpu0/cpufreq/interactive/boost 0
/sys/devices/system/cpu/cpu0/cpufreq/interactive/fast_ramp_down 0
/sys/devices/system/cpu/cpu0/cpufreq/interactive/align_windows 1
/sys/devices/system/cpu/cpu0/cpufreq/interactive/use_migration_notif 1
/sys/devices/system/cpu/cpu0/cpufreq/interactive/use_sched_load 0
/sys/devices/system/cpu/cpu0/cpufreq/interactive/is_skip_max_logic 0
/sys/devices/system/cpu/cpu0/cpufreq/interactive/max_freq_hysteresis 0
/sys/devices/system/cpu/cpu0/cpufreq/interactive/boostpulse_duration 0
/sys/devices/system/cpu/cpu2/cpufreq/interactive/go_hispeed_load 200
/sys/devices/system/cpu/cpu2/cpufreq/interactive/above_hispeed_delay 0
/sys/devices/system/cpu/cpu2/cpufreq/interactive/hispeed_freq_hysteresis 0
/sys/devices/system/cpu/cpu2/cpufreq/interactive/timer_rate 40000
/sys/devices/system/cpu/cpu2/cpufreq/interactive/hispeed_freq 825600
/sys/devices/system/cpu/cpu2/cpufreq/interactive/timer_slack -1
/sys/devices/system/cpu/cpu2/cpufreq/interactive/target_loads 90 307200:28 384000:30 480000:40 537600:45 614400:60 748800:65 825600:69 902400:70 1056000:72 1132800:74 1209600:76 1286400:77 1363200:78 1440000:80 1516800:82 1593600:85 1670400:87 1747200:89 1824000:92 1900800:94 1977600:96 2054400:97 2150400:98 2246400:99 2342400:100
/sys/devices/system/cpu/cpu2/cpufreq/interactive/min_sample_time 20000
/sys/devices/system/cpu/cpu2/cpufreq/interactive/ignore_hispeed_on_notif 1
/sys/devices/system/cpu/cpu2/cpufreq/interactive/boost 0
/sys/devices/system/cpu/cpu2/cpufreq/interactive/fast_ramp_down 0
/sys/devices/system/cpu/cpu2/cpufreq/interactive/align_windows 0
/sys/devices/system/cpu/cpu2/cpufreq/interactive/use_migration_notif 1
/sys/devices/system/cpu/cpu2/cpufreq/interactive/use_sched_load 1
/sys/devices/system/cpu/cpu2/cpufreq/interactive/is_skip_max_logic 0
/sys/devices/system/cpu/cpu2/cpufreq/interactive/max_freq_hysteresis 0
/sys/devices/system/cpu/cpu2/cpufreq/interactive/boostpulse_duration 0
>
Benchmarks (Bifrost & Beast compared)
View attachment 3992996View attachment 3992997
>
Screenshots
View attachment 3992859View attachment 3992860View attachment 3992861View attachment 3992862
(Taken on 20s EUI, stock. Will put newer ones for LTE/HSPA usage at some point)
Click to expand...
Click to collapse
Sorry i am unable to locate disable touchboost?
Where is it in EX Kernel ?

saraprobe said:
Sorry i am unable to locate disable touchboost?
Where is it in EX Kernel ?
Click to expand...
Click to collapse
It's here. It's located at:
/Sys/module/cpu_boost/parameters

Ace42 said:
Sure. I'll compare both profiles to see if there's a difference.
The frequency table is a bit different from the OP3.
Click to expand...
Click to collapse
We can edit them to suit our SD 821 better.

Tikerz said:
We can edit them to suit our SD 821 better.
Click to expand...
Click to collapse
I know, but I wanted to use the profile I had with my G4 and Flex 2. And I just like testing different configs.

Ace42 said:
It's here. It's located at:
/Sys/module/cpu_boost/parameters
Click to expand...
Click to collapse
That's input boost, we don't want to touch that. That's the configurable part of the profiles.
Touchboost is the one you want to disable but we can't because the stock kernel doesn't give the option.
---------- Post added at 10:41 AM ---------- Previous post was at 10:39 AM ----------
Ace42 said:
I know, but I wanted to use the profile I had with my G4 and Flex 2. And I just like testing different configs.
Click to expand...
Click to collapse
You should try burnout from the OP3 thread.

If we had the option to disable Touchboost it would look like this in EX Kernel Manager. We need a custom kernel badly. You can still play around with these profiles but their full potential wouldn't be realized unless we can disable Touchboost.

Ace42 said:
It's here. It's located at:
/Sys/module/cpu_boost/parameters
Click to expand...
Click to collapse
So turn this on as highlighted

saraprobe said:
So turn this on as highlighted
Click to expand...
Click to collapse
No, don't touch it. That's input boost, not touchboost. See my post above.

Tikerz said:
No, don't touch it. That's input boost, not touchboost. See my post above.
Click to expand...
Click to collapse
No worries. Is that Leeco Le pro 3 or a different phone?

Tikerz said:
If we had the option to disable Touchboost it would look like this in EX Kernel Manager. We need a custom kernel badly. You can still play around with these profiles but their full potential wouldn't be realized unless we can disable Touchboost.
Click to expand...
Click to collapse
The directory for touch boost is present (msm_performance), but the file isn't. I'll still play around with input boost to see if it affects battery significantly, or user experience. The profiles don't actually mess with input boost though.

saraprobe said:
No worries. Is that Leeco Le pro 3 or a different phone?
Click to expand...
Click to collapse
My screenshot is from a different phone.
---------- Post added at 10:53 AM ---------- Previous post was at 10:52 AM ----------
Ace42 said:
The directory for touch boost is present (msm_performance), but the file isn't. I'll still play around with input boost to see if it affects battery significantly, or user experience.
Click to expand...
Click to collapse
So if it's not there does that mean it's off? That would be great. It would mean that Le Eco didn't implement Touchboost in their kernel. So we don't have to worry about turning it off.

Tikerz said:
My screenshot is from a different phone.
---------- Post added at 10:53 AM ---------- Previous post was at 10:52 AM ----------
So if it's not there does that mean it's off?
Click to expand...
Click to collapse
thought so cant find here
---------- Post added at 05:56 PM ---------- Previous post was at 05:54 PM ----------
So boost millisecond on or off?

saraprobe said:
thought so cant find here
---------- Post added at 05:56 PM ---------- Previous post was at 05:54 PM ----------
So boost millisecond on or off?
Click to expand...
Click to collapse
Don't touch anything there. Just load the profile. All the settings you see are from the profile.

Tikerz said:
My screenshot is from a different phone.
---------- Post added at 10:53 AM ---------- Previous post was at 10:52 AM ----------
So if it's not there does that mean it's off? That would be great. It would mean that Le Eco didn't implement Touchboost in their kernel. So we don't have to worry about turning it off.
Click to expand...
Click to collapse
I think it's possible, unless they implemented the feature in another way. Usually the CPU jumps to a high freq with touch boost, but the Pro 3 only changes slightly.

Develop Bugs

welcome