Related
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
Hey guys, as things started to get out of control in the CM10 development thread about CPU settings I thought I'd start a
thread for this purpose.
This is not a guide, it's just for general discussion, everyone can share their settings/experience, though I ask everybody
to share the ROM used for those settings!
I do not take any responsibility for any harm done by applying these settings/tweak, use them on your own
risk!
So, let's get to it:
Here are two things which everyone should read before asking questions:
Governors, modules, schedulers, tweaks: http://forum.xda-developers.com/showthread.php?t=1369817
Voltage, Vsel, MHz: http://androidunderground.blogspot.hu/2011/05/setvsel-overclock-and-undervolt-your.html
GOVERNORS:
Here's what I know about Quarx and Epsylon3 roms:
There has been a general fuzz about the smartassv2 governor, which turns out to already be implemented in both roms named
'boosted', although the preferences of the governor might differ from what the ported droidx governor has.
Just to avoid confusion: Quarx did NOT change anything in the 04/08 build, he only set the default governor to boosted and
i/o scheduler to 1, which is SIO (so far it was Noop).
Default boosted preferences:
Code:
bst_awake_ideal_freq: 800000
bst_debug_mask: 0
bst_down_rate_us: 97000
bst_max_cpu_load: 70
bst_min_cpu_load: 40
bst_ramp_down_step: 160000
bst_ramp_up_step: 160000
bst_sample_rate_jiffies: 2
bst_sleep_ideal_freq: 300000
bst_sleep_wakeup_freq: 300000
bst_up_rate_us: 52000
The difference between boosted and the ported smartassv2 is in the preferences.
Here are the settings I use: (it gives me smoother experience than the default ones, although it might drain the battery a
bit more)
Code:
bst_awake_ideal_freq: 800000
bst_debug_mask: 0
bst_down_rate_us: 99000
bst_max_cpu_load: 75
bst_min_cpu_load: 45
bst_ramp_down_step: 0
bst_ramp_up_step: 0
bst_sample_rate_jiffies: 2
bst_sleep_ideal_freq: 200000
bst_sleep_wakeup_freq: 800000
bst_up_rate_us: 24000
I/O SCHEDULERS:
There are three schedulers available on the defy by default: Noop, Cfq and SIO.
The default one can not be changed from bootmenu (at least not on the 30/07 Quarx MB526 build), but you can download Voltage Control from Play Store which enables you to change I/O schedulers and governors.
You can check which scheduler is the default one in /sys/block/mmcblk0/queue/scheduler (the default is the one in brackets).
VSEL/MHZ VALUES:
WARNING! Changing the default vsel values may harm your CPU or cause system lags, freezes, reboots! Use them with caution!
The settings one uses might not be good for others, everyone test their settings thoroughly before using it long term!
Here's the formula for calculating actual voltage from vsel:
V = 0.0125*VSel + 0.6
The default values for each frequency are the following:
[email protected]
[email protected]
[email protected]
[email protected]
These are without a doubt quite a bit higher than needed, probably to make sure all CPUs run stable.
This means that the Defy/Defy+ can be seriously undervolted without any harm (too much undervoolting does no harm to the cpu,
the device simply reboots).
Here is a formula for calculating the vsel from the frequency, which is proved to be stable for most (not all!): (MHz/20)+2
This gives the following settings:
[email protected]
[email protected]
[email protected]
[email protected]
I have been using these settings for almost a year now along with others, never had any trouble with it, but again,
this might not work for everyone.
You can test each value with an app called 'StabilityTest' from Play Store.
Run it for 15 minutes, and if the phone doesn't reboot, then it will most likely work.
For the lazy ones, here's an app that calculates the needed vsels with the formula above:
http://forum.xda-developers.com/showthread.php?t=1815142
Again, this is not a guide, and do not rely 100% on anything written here (I don't want to mislead anybody, I'm no expert,
just a regular user with a hunger for knowledge )
If I have missed something or have written false data, please PM me and I will correct/add it!
My settings:
17/300
26/600
38/800
Using SetVsel with SmartassV2 governor.
dm-0 sio
dm-1 sio
dm-2 sio
mmcblk0 sio
mmcblk1 sio
Above sio settings can be attained by running the KickAssKernelizer script from zeppelinrox and select KAK option.
And 100% V6 superCharged of course from RC11 test 4 script.
Martijn1971 said:
dm-0 sio
dm-1 sio
dm-2 sio
mmcblk0 sio
mmcblk1 sio
Above sio settings can be attained by running the KickAssKernelizer script from zeppelinrox and select KAK option.
Click to expand...
Click to collapse
what are these exactly?
sent from my jellybean defy...
An overview from the KAK script to tweak I/O schedulers. Ther're all sio now. Before running the script, some were cfg.
-edit already set iosched_sio to 1 before in CWM cpu settings but the KAK script does the real trick.
kickasskernelizer is already included in zeppelinrocks new supercharger rc (update9-rc11), at least while running the .sh it wrote that kickasskernelizer is being installed or something like that...
undervolting values for battery time
hardware: motorola mb525 jordan, green lense soc;
governer = ondemand;
clock/vsel = 300/18; 550/30; 800/42;
up_threshold = 99;
sampling_rate = 100000;
has served me well, for almost a year on miui (gb from miuiandroid.com)
and since then on cm10 (jb from quarx)
with stable performance and great battery time
though i must admit it might disappoint some
on the interaction smoothness front
now that i have four values to deal with in the new kernel
i have to rise from slumber and try find new values to sleep with
will (probably) report back when i have them
hope this helps, good luck
Boosted Governor Tunable Parameters
Thought this info from the Repo might help some:
Code:
/******************** Tunable parameters: ********************/
/*
* The "ideal" frequency to use when awake. The governor will ramp up faster
* towards the ideal frequency and slower after it has passed it. Similarly,
* lowering the frequency towards the ideal frequency is faster than below it.
*/
#define DEFAULT_AWAKE_IDEAL_FREQ 500000
static unsigned int awake_ideal_freq;
/*
* The "ideal" frequency to use when suspended.
* When set to 0, the governor will not track the suspended state (meaning
* that practically when sleep_ideal_freq==0 the awake_ideal_freq is used
* also when suspended).
*/
#define DEFAULT_SLEEP_IDEAL_FREQ 200000
static unsigned int sleep_ideal_freq;
/*
* Frequency delta when ramping up above the ideal frequency.
* Zero disables and causes to always jump straight to max frequency.
* When below the ideal frequency we always ramp up to the ideal freq.
*/
#define DEFAULT_RAMP_UP_STEP 160000
static unsigned int ramp_up_step;
/*
* Frequency delta when ramping down below the ideal frequency.
* Zero disables and will calculate ramp down according to load heuristic.
* When above the ideal frequency we always ramp down to the ideal freq.
*/
#define DEFAULT_RAMP_DOWN_STEP 160000
static unsigned int ramp_down_step;
/*
* CPU freq will be increased if measured load > max_cpu_load;
*/
#define DEFAULT_MAX_CPU_LOAD 70
static unsigned long max_cpu_load;
/*
* CPU freq will be decreased if measured load < min_cpu_load;
*/
#define DEFAULT_MIN_CPU_LOAD 40
static unsigned long min_cpu_load;
/*
* The minimum amount of time to spend at a frequency before we can ramp up.
* Notice we ignore this when we are below the ideal frequency.
*/
#define DEFAULT_UP_RATE_US 52000;
static unsigned long up_rate_us;
/*
* The minimum amount of time to spend at a frequency before we can ramp down.
* Notice we ignore this when we are above the ideal frequency.
*/
#define DEFAULT_DOWN_RATE_US 97000;
static unsigned long down_rate_us;
/*
* The frequency to set when waking up from sleep.
* When sleep_ideal_freq=0 this will have no effect.
*/
#define DEFAULT_SLEEP_WAKEUP_FREQ 300000
static unsigned int sleep_wakeup_freq;
/*
* Sampling rate, I highly recommend to leave it at 2.
*/
#define DEFAULT_SAMPLE_RATE_JIFFIES 2
static unsigned int sample_rate_jiffies;
i have the following settings
Clock/vsel
300-17
600-32
800-42
1100-57
Governor-Boosted
Scheduler-sio
and this has been very good for me. Getting good performance as well as Battery life with these values on my Cm10(18-10-2012) build.
thanx man! for that grt post!
I want 500/700/900/1200
my rom is jelly bean 4.1.2
whats vsel use??
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
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.
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