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
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??
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
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.
[size=+1]Welcome to Skatter Kernel forum.[/size]
Today I am very proud to release the Skatter Kernel to you guys, I've done hundreds of tests to see what features function well, and which one's don't. The idea behind this kernel is to be able to customize it the way you want, with the best battery possible
Now... let's take a look and see what's inside this bad boy.
Click to expand...
Click to collapse
Skatter Kernel-v2 is a complete rewrite of v1. What makes this version of the kernel so special?
It's faster, even more stable, and has the ability to run any governor from a 3.10.y kernel.
I've ran many tests and can say, these governors have been playing very nicely with our d2 device. I have not added any junk commits, or any that would cause any battery drain. Also I'm sorry for anyone on marshmallow... but kernel from now on is only going to be nougat and up.
Also I would like to make an introduction to my "Skateractive" governor! :victory:
What does the Skateractive governor do anyways?
Code:
This governor is based on the linux 3.10.y Interactive governor.
I've written it to be mostly a "screen-off profiling" governor.
Meaning, I've added tunables that allow you to customize the governor while the screen is off.
These are...
Timer_rate_multiplier: Name speaks for itself, how many times to multiply timer_rate on screen off. Max number is 10.
Screen_off_maxfreq: Set the limit the max frequency can be reached on screen off.
Screen_off_maxfreq_single_core: If you're like me and use hotplugs you'll notice it can get a bit laggy with music playback when one core is online & max freq is 702mhz. So add a frequency limit for when only one core is online and the screen is off. :good:
* Not a tunable: But enabled powersave bias on screen off & on screen-on back to normal.
Also stripped governor of any unneeded code. For best performance.
Features
* Compiled with a highly optimized Uber 7.x TC
* Tons of optimizations (-Ofast, Graphite, Cortex-A15) and lots more :good:
* CPU UC/OC from 162MHz to 1836Mhz
* Set to Permissive
* Net Speed Tweak
* Decreased time to enter deep sleep
* Optimized GPU
* Enabled Low Power Memory Mode
* Quick Wakeup Driver
* Some Aggressive Seeder Tweaks
* Optimized Square Root Algorithm
* More memory from loggers (Cause the more RAM, the better)
* Screen Tweaks for filling blank spots with more color
* Voltage Table, for your UV/OV Needs
* Tweak to disable Powersuspend when State Notifier is enabled.
* Set standby frequency to 54Mhz.
* Tweaked to lower Thermal throttle on screen off.
* UKSM for better ram, set to not consume so much battery.
* Frandom.
Decimalman's features
* Overclocked GPU to 600, modded & upped to 750Mhz.
* And his super badass tierservative & freelunch governors :good:
* Fast charge patch, no need to diconnect :good:
* Tiered GPU Governor, very nice with frequencies.
Faux123's Features
* Fauxsound
* Powersuspend v1.7
* Dynamic Fsync
* Simple GPU Governor
I/O Schedulers
* Sio
* Sioplus
* V(r)
* Noop
* Zen
* Fifo
* TripNDroid
* Fiops
* Maple
Hotplugs
* MPDecision
* Bricked Hotplug
* Blu_Plug
* Thunderplug v5.4
* AutoSMP
* Intelliplug
* Alucard
* State Helper
* MSM Hotplug
* Skater Hotplug
x MSM Sleeper
x Zen Decision
CPU Governors
* Alucard
* Blu_Active (Latest version)
* Chill
* Conservative (3.10.y version)
* Cultivation
* Cyan (For those gamers, do not use with hotplugs.)
* Darkness
* Despair
* ElementalX v2
* Freelunch
* Interactive
* Lionfish
* Lionheart
* NIghtmare
* Ondemand (3.10.y version)
* Performance
* Powersave
* Relaxed
* Skateractive (Default)
* Skatter_Core
* Smartmax
* Smartmax_EPS
* Tierservative.
Instructions
1.) Make... a... [size=+1]BACKUP[/size]
2.) Download kernel & copy it to sdcard
3.) Flash
4.) Wipe dalvik-cache & cache
5.) Most importantly, Enjoy :good:
Downloads
Right Here
Modded Kernel Adiutor
Right Here
* If anyone needs a mirror link, just ask and I will upload
Contributors
* A special thanks to @bthorne79 for helping me get started on this
* Another special thanks to the beast himself @decimalman
for helping me with a ton of noob questions & especially for the patchs:good:
@faux123 for all his awesome features
@neobuddy for helping me out with the blu_plug driver
@invisiblek for keeping this awesome device alive
@canodroid15 for running my test builds :highfive:
Everyone at CM & everyone else who I forgot
Disclaimer:
Code:
/*
* Your warranty is now void.
*
* I am not responsible for bricked devices, dead SD cards,
* thermonuclear war, or you getting fired because the alarm app failed. Please
* do some research if you have any concerns about features included in this ROM
* before flashing it! YOU are choosing to make these modifications, and if
* you point the finger at me for messing up your device, I will laugh at you. Hard. A lot.
*/
XDA:DevDB Information
Skatter Kernel, Kernel for the Sprint Samsung Galaxy S III
Contributors
Lonelyskatter12, bthorne79, decimalman
Kernel Special Features:
Version Information
Status: Stable
Stable Release Date: 2017-11-02
Created 2016-09-29
Last Updated 2017-11-03
FIRST!!! Downloading now
Edit:
Installed and am getting some random reboots, will thoroughly test soon.
RDChase said:
FIRST!!! Downloading now
Edit:
Installed and am getting some random reboots, will thoroughly test soon.
Click to expand...
Click to collapse
What ROM are you using?
I've tested this on 5 different ROMs, and no reboots here
Kernel seems to be working fine atm, has a int.d script that sets selinux to permissive which is nice when using other mods, currently overclocked device to 1.6 on cpu and 480 on gpu, will push it farther later. Thanks for creating this!
Edit 2: My particular cpu wont go past 1.62 but no biggie there, 600mhz works fine on the gpu so cardboard works better, only one problem thus far. Not sure if it's because of resurrection rom or this kernel since it's my first time trying both out but when taking a vr panorama the final output is all garbled and green. Taking and viewing Photospheres work fine and so do other gpu games and applications. I also noticed this problem when doing a screen recording and looking at thumbnails of videos in quickpic.
lonelyskatter12 said:
what rom are you using?
I've tested this on 5 different roms, and no reboots here
Click to expand...
Click to collapse
pac rom 6.0
RDChase said:
pac rom 6.0
Click to expand...
Click to collapse
Hasn't happened to me yet with that ROM.
I tried this on multiple roms. Only issue was battery life
Sent from my SPH-L710 using Tapatalk
shekinahsmoke said:
I tried this on multiple roms. Only issue was battery life
Sent from my SPH-L710 using Tapatalk
Click to expand...
Click to collapse
Try a different setup, there's lots of governors and hotplugs to help out for that :good:
bug invalid network mode
cm13 nightly
Update.
[size=+1]Changelog[/size]
* Added 2 governors (Intellidemand & Ondemandplus)
* Added Power Efficient Workqueues
* Added The Intelli_plug 5.2 driver
* In sync with CM
* Added OOM throttle
* A few hotplug fixes. Still have more to do but this'll do until they're are more stable.
* Added toggle for Gentle Fair Sleepers & Arch Power
[size=+1]Note:[/size]
*** Even tho linux version still says 3.4.112 it has the necessary patches for the "Dirty COW" exploit. Linux version will remain 3.4.112 as I have chosen to wait until CM officially merges 3.4.113 ***
thanks to @canodroid15 for notifying me & @decimalman for confirming the patch is in the kernel :highfive:
Woot!
Nice work, keeping this old beast of a phone kicking
[size=+1]Changelog 12/01/2016[/size]
* Enabled MSM Ultrasound
* Disabled MP-Decision and enabled Intelliplug by default.
* Improved faster Integer square root algorithm 3x
* Added very very very experimental 750 GPU steps.
* Synced with CM
* Compiled with the latest Uber-6.x toolchain.
* Disabled logger on boot.
* Added a missing Power Efficient Workqueue patch
* Replaced Bricked hotplug, with a modified version.
- Still no fix for the green thumbnails, but still looking into it.
As always, enjoy :good:
Does this work for android version 4.4.2?
dogma421 said:
Does this work for android version 4.4.2?
Click to expand...
Click to collapse
Highly doubt it
[size=+1]*** Changelog ***[/size]
* Now, support for nougat :good:
* Up-to-date with CM
* Fixed the State Notifier driver, screen shouldn't take too long to turn on when the driver is active now.
* Fixed a few more power efficient workqueue commits, now even more power efficient.
* Faster proc/vmstats
* Added Alucard Hotplug driver
* Added Dynamic Hotplug driver
any screenshots for this Rom?
Death_Gun said:
any screenshots for this Rom?
Click to expand...
Click to collapse
Its not a ROM, it a kernel
[size=+1]*** Changelog ***[/size]
* Synced up with LineageOS
* Fixed State Notifier, lagging when enabled with Powersuspend.
* Lowered the value of thermal driver from 70 to 50. Also made it a bit more agressive, will get a bit laggy just raise the limit to start throttling, but values will keep the phone cooler longer.
* Green screen recording/thumbnail bug is fixed. Finally. :highfive:
* Fixed a small issue with voltages.
* New experimental values for Umbrella_core governor.
- Nougat kernel only, MM kernel will be up later
As always, enjoy :good:
Lonelyskatter12 said:
*** Changelog ***
* Synced up with LineageOS
* Fixed State Notifier, lagging when enabled with Powersuspend.
* Lowered the value of thermal driver from 70 to 50. Also made it a bit more agressive, will get a bit laggy just raise the limit to start throttling, but values will keep the phone cooler longer.
* Green screen recording/thumbnail bug is fixed. Finally. :highfive:
* Fixed a small issue with voltages.
* New experimental values for Umbrella_core governor.
- Nougat kernel only, MM kernel will be up later
As always, enjoy :good:
Click to expand...
Click to collapse
I'm one the latest kernel on the latest lineage os, it won't let me push the frequency past 1188 with every tool I've tried, which tool would you suggest to attempt an overclock?