Develop Bugs

dBm instead of signal bars? (similarly to supercircle battery)

Hi all,
I would love to have something similar to the supercircle battery mod, but for the signal strength indicator (instead of the usual four bars).
Do you know if there is already some mod for doing this?
Do you think it is hard to develop something in that direction?
Maybe, the dev of the supercircle battery mod can give us some hint?
Best,
Wally
P.S. I am aware that the cyanogen Rom already has dBm on the tray, but what about all the others?
Sent from my HTC Desire using XDA App

wally80 said:
Hi all,
I would love to have something similar to the supercircle battery mod, but for the signal strength indicator (instead of the usual four bars).
Do you know if there is already some mod for doing this?
Do you think it is hard to develop something in that direction?
Maybe, the dev of the supercircle battery mod can give us some hint?
Best,
Wally
P.S. I am aware that the cyanogen Rom already has dBm on the tray, but what about all the others?
Sent from my HTC Desire using XDA App
Click to expand...
Click to collapse
OpenDesire and DeFrost have it too.

BlackDragonBE said:
OpenDesire and DeFrost have it too.
Click to expand...
Click to collapse
Because they are based on cyanogenmod, right?
Unfortunately I love HTC sense. :-(
Anyway, in cyanogenmod there is just a number that shows up in addition to the legacy bars.
This would even be OK for me, I would be very happy to have it in my leedroid.
But the idea I was posting is about something that REPLACES the bars and put a circle (with some more levels? don't know, maybe 8?) and the dBm value in the center. Exactly as the super circle battery.

wally80 said:
Because they are based on cyanogenmod, right?
Unfortunately I love HTC sense. :-(
Anyway, in cyanogenmod there is just a number that shows up in addition to the legacy bars.
This would even be OK for me, I would be very happy to have it in my leedroid.
But the idea I was posting is about something that REPLACES the bars and put a circle (with some more levels? don't know, maybe 8?) and the dBm value in the center. Exactly as the super circle battery.
Click to expand...
Click to collapse
No cake for you.
Sent from my HTC Desire using XDA App

I would also like this mod
Sent from my HTC Desire using XDA App

wardy277 said:
I would also like this mod
Sent from my HTC Desire using XDA App
Click to expand...
Click to collapse
No cake for you too.
Sent from my HTC Desire using XDA App

K900 said:
No cake for you.
Sent from my HTC Desire using XDA App
Click to expand...
Click to collapse
What do you mean?

me too would like to have this feature on sense roms
and I don't like cake
Sent from my HTC Desire using XDA App

+1 for this, but maybe a triangle or a square? to differ it from the battery, otherwise the create confuse.. so NO circle, but go for other shape

I meant it is not possible. Circle battery is based on the thing that Sense allows for a custom icon for every battery level (from 0% to 100%) and every icon of that set is replaced. It doesn't read anything from the system, it's just a pack of icons. And the signal level icon has 5 or so states, so it will require modding Sense to have more icons for signal strength, and I don't even know if it knows the dBm and doesn't get precalculated signal levels from the kernel/radio.
Sent from my HTC Desire using XDA App

I was thinking about that but it needs changing only 1 file in the sources codes:
The file is: services/java/com/android/server/status/StatusBarPolicy.java
Code:
......
122 //***** Signal strength icons
123 private IconData mPhoneData;
124 //GSM/UMTS
125 private static final int[] sSignalImages = new int[] {
126 com.android.internal.R.drawable.stat_sys_signal_0,
127 com.android.internal.R.drawable.stat_sys_signal_1,
128 com.android.internal.R.drawable.stat_sys_signal_2,
129 com.android.internal.R.drawable.stat_sys_signal_3,
130 com.android.internal.R.drawable.stat_sys_signal_4
131 };
......
This is for the icons in the code above and below the number of bars depends on the signal strength. There is no rule about setting signal strenght VS nb. of bars and so Apple and Google *could* cheat for overestimating the number of bars ^^
Code:
996 // ASU ranges from 0 to 31 - TS 27.007 Sec 8.5
997 // asu = 0 (-113dB or less) is very weak
998 // signal, its better to show 0 bars to the user in such cases.
999 // asu = 99 is a special case, where the signal strength is unknown.
1000 if (asu <= 2 || asu == 99) iconLevel = 0;
1001 else if (asu >= 12) iconLevel = 4;
1002 else if (asu >= 8) iconLevel = 3;
1003 else if (asu >= 5) iconLevel = 2;
1004 else iconLevel = 1;
The source file is located here:
http://android.git.kernel.org/?p=pl...f9b9cb71b1f057b4904c660318e20eff;hb=HEAD#l131
Otherwise, the services.jar can be edited but you need modifying the StatusBarPolicy.smali (if decompiled with smali tool)
I already tried the last method but it seems if I modify it a lot, my phone would end in a bootloop
So we need an expert for doing that.
PS: For your culture, look at the page 87 of the pdf to see how the dBm is converted to ASU:
http://www.quintillion.co.jp/3GPP/Specs/27007-940.pdf
... and the 3GPP specification
http://3gpp.org/ftp/Specs./html-info/27007.htm

Fightspit said:
I was thinking about that but it needs changing only 1 file in the sources codes:
The file is: services/java/com/android/server/status/StatusBarPolicy.java
Code:
......
122 //***** Signal strength icons
123 private IconData mPhoneData;
124 //GSM/UMTS
125 private static final int[] sSignalImages = new int[] {
126 com.android.internal.R.drawable.stat_sys_signal_0,
127 com.android.internal.R.drawable.stat_sys_signal_1,
128 com.android.internal.R.drawable.stat_sys_signal_2,
129 com.android.internal.R.drawable.stat_sys_signal_3,
130 com.android.internal.R.drawable.stat_sys_signal_4
131 };
......
This is for the icons in the code above and below the number of bars depends on the signal strength. There is no rule about setting signal strenght VS nb. of bars and so Apple and Google *could* cheat for overestimating the number of bars ^^
Code:
996 // ASU ranges from 0 to 31 - TS 27.007 Sec 8.5
997 // asu = 0 (-113dB or less) is very weak
998 // signal, its better to show 0 bars to the user in such cases.
999 // asu = 99 is a special case, where the signal strength is unknown.
1000 if (asu = 12) iconLevel = 4;
1002 else if (asu >= 8) iconLevel = 3;
1003 else if (asu >= 5) iconLevel = 2;
1004 else iconLevel = 1;
The source file is located here:
http://android.git.kernel.org/?p=pl...f9b9cb71b1f057b4904c660318e20eff;hb=HEAD#l131
Otherwise, the services.jar can be edited but you need modifying the StatusBarPolicy.smali (if decompiled with smali tool)
I already tried the last method but it seems if I modify it a lot, my phone would end in a bootloop
So we need an expert for doing that.
PS: For your culture, look at the page 87 of the pdf to see how the dBm is converted to ASU:
http://www.quintillion.co.jp/3GPP/Specs/27007-940.pdf
... and the 3GPP specification
http://3gpp.org/ftp/Specs./html-info/27007.htm
Click to expand...
Click to collapse
Nice find Though I don't really know if that will work with Sense
Sent from my HTC Desire using XDA App

ro.ril.power.collapse= 1 or 0

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

Smarreflex - Values explained +1350mv calibration fix

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

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

Smartreflex - how to improve the algorithm

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

GPS problem, losing all satellites at once

Hello.
I found that my GPS location service works incorrect after 6 april 2019 GPS rollover
I use GPS Test app to check it, and it looks like my phone finds few satellites, fixes my position just fine for some time, and then after a minute or two just resets all GPS connection and loses all satellites at once. All signal bars just disappear at one moment. Then it starts finding satellites again, and this circle goes over and over again. Also, if I check Time tab in GPS Test app, it shows incorrect date and time, like 2-Sep-01. So it looks like our phone was affected by GPS rollover. Or is the problem only with my phone? I'm not sure is it software or hardware problem.
I tried to: flash a new ROM, backup stock ROM 4.1.2, clear and tighten GPS antenna contacts, update gps.conf file with my local NTP server address. Nothing worked.
If you have any suggestions about what is happening with my phone, please let me know. Also it will be great if you could say whether your Note 2 GPS works fine or you experiencing the same problem.
Thanks!

esseth said:
Hello.
I found that my GPS location service works incorrect after 6 april 2019 GPS rollover
I use GPS Test app to check it, and it looks like my phone finds few satellites, fixes my position just fine for some time, and then after a minute or two just resets all GPS connection and loses all satellites at once. All signal bars just disappear at one moment. Then it starts finding satellites again, and this circle goes over and over again. Also, if I check Time tab in GPS Test app, it shows incorrect date and time, like 2-Sep-01. So it looks like our phone was affected by GPS rollover. Or is the problem only with my phone? I'm not sure is it software or hardware problem.
I tried to: flash a new ROM, backup stock ROM 4.1.2, clear and tighten GPS antenna contacts, update gps.conf file with my local NTP server address. Nothing worked.
If you have any suggestions about what is happening with my phone, please let me know. Also it will be great if you could say whether your Note 2 GPS works fine or you experiencing the same problem.
Thanks!
Click to expand...
Click to collapse
Hi, a relative has exactly the same problem on an N7100 Galaxy Note II.
As of the 6th April it struggles to hold GPS lock. On a cycle ride it could stop logging position for 14 minutes. Then it would get a few positions then lose it again. His strada track was like he was in a very slow helicopter.
The data it does get is recorded as being in 1999, which made it disappear when loaded onto a cycling site. Eventually we found it loaded as circa 20 years ago! In theory you can record position and edit the data to correct the dates - perhaps more trouble than its worth - BUT the very intermittent position makes it almost useless.
There's a similar report on phonandroid (in French). They had samsung actually acknowledge the "date bug" but everyone is surprised at the loss of gps lock.
My hypothesis is either:
a. the device is using the gps-date to optimise some calculations - so they go wrong.
b. the device notices the mismatch between the gps-date and the more detailed parts of the gps data, which probably have the real date. So it resets itself to clear the anomaly (maybe thinking its been turned off for a long time!). But each time the mismatch occures.
I've just read that the full set of GPS data frames are quite big and take something like 12.5 minutes to arrive at 50 bits/second. This might fit with the 14 minute gap we saw.

ReaderK said:
Hi, a relative has exactly the same problem on an N7100 Galaxy Note II.
As of the 6th April it struggles to hold GPS lock. On a cycle ride it could stop logging position for 14 minutes. Then it would get a few positions then lose it again. His strada track was like he was in a very slow helicopter.
The data it does get is recorded as being in 1999, which made it disappear when loaded onto a cycling site. Eventually we found it loaded as circa 20 years ago! In theory you can record position and edit the data to correct the dates - perhaps more trouble than its worth - BUT the very intermittent position makes it almost useless.
There's a similar report on phonandroid (in French). They had samsung actually acknowledge the "date bug" but everyone is surprised at the loss of gps lock.
My hypothesis is either:
a. the device is using the gps-date to optimise some calculations - so they go wrong.
b. the device notices the mismatch between the gps-date and the more detailed parts of the gps data, which probably have the real date. So it resets itself to clear the anomaly (maybe thinking its been turned off for a long time!). But each time the mismatch occures.
I've just read that the full set of GPS data frames are quite big and take something like 12.5 minutes to arrive at 50 bits/second. This might fit with the 14 minute gap we saw.
Click to expand...
Click to collapse
Thanks for your reply. Now I see that the problem is not only for my phone, but for Note 2 model in general.
How do you think, is it any way to make some kind of fix for this? I hope there may be a way to make few changes in our GPS firmware, but I need an advice or instruction from somebody who knows exactly how this things work.

I have galaxy note 2 international model. I have Stock rom but rooted. Same problem with here.wego navigation app.
Samsung says navigations app developers are responsible for : https://www.samsung.com/us/support/troubleshooting/TSG01200843/
Please fix this hateful issue.

Hi to all!
Does anybody find a solution for the GPS bug?
Is there a suitable ROM to fix the problem?
I'm a software developer, so its possible for me to help for some reviews in the sources.
But my experience in the android system is very poor.
Did anybody knows the difference to the GPS of the Samsung Galaxy S III i9300?
The problem doesn't occur on the i9300.
Thanks in advance

From my point of view it's just the problem of the GPS device inside the phone, namely its firmware (which I don't know anybody can access or fix). I think there is no way any custom ROM can fix this since this is out of reach of the ROM.
N7100 as it is is useless as a GPS since the april 2019 due to the rollover bug. The only solution is to use external GPS module (connected through USB or bluetooth) until someone is able to fix it (which in my opinion will not ever happen). I have several N7100s and all of them is affected by this bug regardless of the rom installed (I tried many). And I have an old Mio GPS from 2003 or so and it still works - is not affected by the rollover bug). I am therefore moving to another phone and use those old N7100s as some special devices (sort of small tablets for kids, security cameras or so). No more usable as a phone with working GPS (withou additional hardware attached). Sad but that's just the way it is.

I would like to keep my good old trustworthy note2 as a fully functional tool and don´t want to buy one of those shiny glas-things with all that blingbling.
I found this post with a java script
https://stackoverflow.com/questions/56147606/wrong-date-returned-from-location-gettime-after-6-april-2019-week-number-rollov/57339828#57339828
In my view this leads into the right direction ...
Adapt the gps-time to the system-time.
Is this possible for a rooted phone ?
Although I have no clue about coding at all ..
I think the code is not correct ... logically and technically ...
You cannot always add constant 1024 weeks to the actual gps-time.
If you are for example one week away from the switching-date you have to add one week less
to get to the correct system-time ... correct ?
There are already apps which adpat the system-time to the gps-time.
But in this case we would need it the other way round ... i think.
I already tried to implement the java-script from above with droidscript.
But as I´ve said ... I have really no clue what I am doing
Maybe tasker could also be a way .... to start a fixing-routine always before using a navigation app
Maybe we could pile up some donations for a good programmer who is willing to take on the quest
to keep the note2 alive ?!
Let me know
what do you think ...
This cannot be the end of the NOTE2 !
Cheers ...
Christian

This code from stackexchange would have to be implemented into the navigation app. Also, I do think it is as simple as just adding 1024 weeks.
From what I know from other devices, Broadcom (Note2 uses BCM47521 GPS chip) uses an external wrapper/binary blob to translate the GPS data into time and location data. Therefor, to fix the root issue, one would need a fixed wrapper from Broadcom. Maybe this could be extracted from other devices, maybe wrappers from newer chips could also work with the old one?
On a TomTom PNA I was able to write second wrapper that redirects the output of the original wrapper, then corrects the date and writes it to the correct location. However, a smartphone with internet connection probably interacts a bit more with the chip. Not sure if my solution could work on the Note2 as well.
EDIT: /bin/gpsd seems to be the responsible wrapper. Though the name suggests to be the open source GNU gpsd, it seems this is a special Broadcom closed-source file just by the same name. Or...maybe it's in the sources of the Note2 open source files.

I write the problem and simple solution (add 1024 week) to here.wego, maps.me, google maps and yandex maps developers. And also to all note 2 rom developers on xda ( @dr.ketan, @transi1 , @makorn645 , @ComicoX , @ibrahimal63 @hgunduz295 ...). Still no solution for gps rollover. I think solution is simple for our developers but our phones and rom's sources are old and maybe can be ignored for them.
Please fix this issue by wrapper or anyway and be a hero @treysis

Now that I think about it, maybe even the app developers are out of luck. I think they will just rely on some location api provided by the phone. So it has to be in the firmware. I.e. even one level higher than the ROM. But like I said, maybe it's possible to fix this with a wrapper. Unfortunately, I don't own a Note2, so it's difficult for me to test.
You could try to find an app that logs NMEA messages on your Note2 and see what date is presented inside them. That would be already a bit helpful.

I think actually our rom developers should make corrections simple by adding 1024 week to wrong date.
However, location app developers can still fix it by adding 1024 week to wrong date provided by the rom inside their apps.
it's not necessary logs for NMEA messages, already it seems wrong date at gps testing app on our Note 2's.
Maybe you can help to our developers for wrapper method on their roms by xda private messages.
thanks a lot.

xda-dvlprs said:
I think actually our rom developers should make corrections simple by adding 1024 week to wrong date.
Click to expand...
Click to collapse
The question is, how easy is that to do? Where do you add those 1024 weeks? In "LocationManager.java"? Where does LocationManager.java take the date from? Does it do the conversion itself from binary data or does it rely on NMEA to extract the date? Does a wrong date already confuse the LocationManager enough to drop the GPS fix? Why does it drop the fix in the first place? Is there a comparison between GPS date and mobile network date?
However, location app developers can still fix it by adding 1024 week to wrong date provided by the rom inside their apps.
Click to expand...
Click to collapse
They can't! They just take the data from the LocationProvider. And if the LocationProvider says that the GPS signal is lost, the app can't do much about it. Unless it reads NMEA data from the GPS chip itself. I don't know if this is even possible with the permission framework.
it's not necessary logs for NMEA messages, already it seems wrong date at gps testing app on our Note 2's.
Click to expand...
Click to collapse
What do you mean with GPS testing app? Which app exactly are you referring to? How do you know it doesn't read NMEA?
Maybe you can help to our developers for wrapper method on their roms by xda private messages.
Click to expand...
Click to collapse
I don't know if there are any developers still active for NoteII and if they actually compile the java android stuff at all or just take it precompiled?

yes, we have active developers as i said before. for example @ComicoX . maybe help you this source code by crdroid rom for .java wrapper. https://github.com/crdroidandroid
thanks a lot.

xda-dvlprs said:
maybe help you this source code by crdroid rom for .java wrapper. https://github.com/crdroidandroid
thanks a lot.
Click to expand...
Click to collapse
Seems the right place to look, but I have no idea where exactly you would have to insert the patch.

I'm not android developer but I thinks to place the patch you need to look at line 538 and below.
https://github.com/crdroidandroid/a.../location/java/android/location/Location.java

@xda-dvlprs I had a bit a look around...I was even provided with some NMEA logfiles from the Note2. It seems to me this is the direct output of the /bin/gpsd driver. This is a proprietary closed source binary by Broadcom and has nothing to do with the open source BSD-licensed gpsd project. And the unfortunate thing is that the problem already exists at that level. So, we would need to find a working gpsd, and I doubt Broadcom would do anything in that direction, and furthermore it would have to be adapted by Samsung as well, which is even more unlikely. F*** Broadcom. This is exactly why OpenMoko decided to back away from using Broadcom back in 2007/2008.

WNRO 2019
Firstly thank @treysis for effort about WNRO. I see the gps date error before gps is reset when I look at the crdroid logs. So I think it is still a situation that can be corrected at the android operating system level.
Hopefully a good note 2 developer will take the time and correct it maybe simple by adding 1024 weeks.
treysis said:
@xda-dvlprs I had a bit a look around...I was even provided with some NMEA logfiles from the Note2. It seems to me this is the direct output of the /bin/gpsd driver. This is a proprietary closed source binary by Broadcom and has nothing to do with the open source BSD-licensed gpsd project. And the unfortunate thing is that the problem already exists at that level. So, we would need to find a working gpsd, and I doubt Broadcom would do anything in that direction, and furthermore it would have to be adapted by Samsung as well, which is even more unlikely. F*** Broadcom. This is exactly why OpenMoko decided to back away from using Broadcom back in 2007/2008.
Click to expand...
Click to collapse

Thanks ... for looking into it.

xda-dvlprs said:
Firstly thank @treysis for effort about WNRO. I see the gps date error before gps is reset when I look at the crdroid logs. So I think it is still a situation that can be corrected at the android operating system level.
Hopefully a good note 2 developer will take the time and correct it maybe simple by adding 1024 weeks.
Click to expand...
Click to collapse
Adding 1024 weeks doesn't help: if there is no satfix, there is no date to add 1024 weeks to. I compared with S3, which has predecessor GPS chip (BCM47511, Note2 uses BCM4752) and it also supplies a wrong date, but doesn't lose satfix.
But you day you see the error before WNRO in crdroid logs? Can you give me a link?

WNRO log
treysis said:
Adding 1024 weeks doesn't help: if there is no satfix, there is no date to add 1024 weeks to. I compared with S3, which has predecessor GPS chip (BCM47511, Note2 uses BCM4752) and it also supplies a wrong date, but doesn't lose satfix.
But you day you see the error before WNRO in crdroid logs? Can you give me a link?
Click to expand...
Click to collapse
here is my log : (attention this : GL_STOP_BAD_TIME)
---- Oct 15, 2019 17:57:09 ----
10-15 17:53:51.709 2395 3265 I ActivityManager: START u0 {flg=0x10804000 cmp=com.android.systemui/.recents.RecentsActivity} from uid 10037 on display 0
10-15 17:53:52.026 2395 2405 I art : Background partial concurrent mark sweep GC freed 5935(297KB) AllocSpace objects, 3(148KB) LOS objects, 33% free, 11MB/17MB, paused 2.181ms total 175.842ms
10-15 17:53:52.786 2395 3256 E ActivityManager: applyOptionsLocked: Unknown animationType=0
10-15 17:53:52.811 2395 2866 I GnssLocationProvider: WakeLock acquired by sendMessage(3, 0, [email protected]b7a)
10-15 17:53:52.820 2395 2416 I libgps : disarming wakeLockTimer
10-15 17:53:52.841 2395 2416 I GnssLocationProvider: WakeLock released by handleMessage(3, 0, [email protected]b7a)
10-15 17:53:53.110 2395 7663 I libgps : OnGpsExtensionMessage: MSG_REQUEST_LOCATION_ID
10-15 17:53:53.110 2395 7663 I libgps : disarming wakeLockTimer
10-15 17:53:53.110 2395 7663 I libgps : [proxy_gps_acquire_wakelock_cb][line = 696]: acquire_wakelock(1)
10-15 17:53:54.255 2395 7663 I libgps : OnGpsExtensionMessage: MSG_REQUEST_LOCATION_ID
10-15 17:53:56.062 2395 2498 I ActivityManager: START u0 {flg=0x10804000 cmp=com.android.systemui/.recents.RecentsActivity} from uid 10037 on display 0
10-15 17:53:56.237 2395 3255 I GnssLocationProvider: WakeLock acquired by sendMessage(3, 0, [email protected]c34)
10-15 17:53:56.286 2395 2416 I GnssLocationProvider: WakeLock released by handleMessage(3, 0, [email protected]c34)
10-15 17:53:56.335 2607 2623 I art : Background partial concurrent mark sweep GC freed 23236(1303KB) AllocSpace objects, 3(236KB) LOS objects, 39% free, 9MB/15MB, paused 1.105ms total 144.787ms
10-15 17:53:56.381 2395 2405 I art : Background partial concurrent mark sweep GC freed 6326(392KB) AllocSpace objects, 6(296KB) LOS objects, 33% free, 11MB/17MB, paused 2.288ms total 216.223ms
10-15 17:53:57.202 2395 3247 E ActivityManager: applyOptionsLocked: Unknown animationType=0
10-15 17:53:59.862 2395 3249 I ActivityManager: START u0 {flg=0x10804000 cmp=com.android.systemui/.recents.RecentsActivity} from uid 10037 on display 0
10-15 17:54:00.176 2395 2405 I art : Background partial concurrent mark sweep GC freed 5049(291KB) AllocSpace objects, 5(276KB) LOS objects, 33% free, 11MB/17MB, paused 2.130ms total 155.934ms
10-15 17:54:00.288 2607 2607 W IInputConnectionWrapper: reportFullscreenMode on inexistent InputConnection
10-15 17:54:00.951 2395 2406 E ActivityManager: applyOptionsLocked: Unknown animationType=0
10-15 17:54:00.972 2395 3256 I GnssLocationProvider: WakeLock acquired by sendMessage(3, 0, [email protected]72a)
10-15 17:54:00.974 2395 2416 I libgps : disarming wakeLockTimer
10-15 17:54:00.983 2395 7663 I libgps : OnGpsExtensionMessage: MSG_REQUEST_LOCATION_ID
10-15 17:54:01.007 2395 2416 I GnssLocationProvider: WakeLock released by handleMessage(3, 0, [email protected]72a)
10-15 17:54:02.193 2395 7663 I libgps : OnGpsExtensionMessage: MSG_REQUEST_LOCATION_ID
10-15 17:54:17.026 8302 8307 I art : Do full code cache collection, code=100KB, data=118KB
10-15 17:54:17.028 8302 8307 I art : Starting a blocking GC JitCodeCache
10-15 17:54:17.028 8302 8307 I art : After code cache collection, code=81KB, data=80KB
10-15 17:54:31.756 2078 2078 I perfprofd: profile collection skipped (missing semaphore file)
10-15 17:55:04.452 2395 2420 E BatteryStatsService: power: Missing API
10-15 17:55:04.462 2395 2420 E BatteryStatsService: no controller energy info supplied
10-15 17:55:04.462 2395 2420 E BatteryStatsService: no controller energy info supplied
10-15 17:55:06.464 2395 2420 W BatteryStatsService: Timeout reading modem stats
10-15 17:55:09.925 2079 2079 E gpsd : ASSERT in /tmp/12818784_188647/customers/samsung/T0EVOandroid/../../../proprietary/deliverables/android/gps_interface/../gpsd/common/GlGpsdInterface.cpp:953: GL_STOP_BAD_TIME
10-15 17:55:09.927 2079 2079 E gpsd : LogJava: Cannot flush log buffer. Skipped bytes: 307
10-15 17:55:09.934 2395 7663 I libgps : disarming wakeLockTimer
10-15 17:55:09.934 2395 7663 I libgps : [proxy_gps_release_wakelock_cb][line = 706]: release_wakelock(0)
10-15 17:55:09.934 2395 7663 I libgps : [reset_wakelock][line = 720]: release_wakelock. reset acq_count
10-15 17:55:09.970 8564 8564 W sh : type=1400 audit(0.0:58): avc: denied { read } for name="overcommit_memory" dev=proc ino=73244 scontext=u:r:gpsd:s0 tcontext=ubject_rroc:s0 tclass=file permissive=0
10-15 17:55:10.008 8565 8565 W linker : Non position independent executable (non PIE) allowed: /system/bin/gpsd
10-15 17:55:10.034 8565 8565 W linker : /system/bin/gpsd has text relocations. This is wasting memory and prevents security hardening. Please fix.
10-15 17:55:10.114 8565 8565 W linker : /system/lib/libsec-ril.so has text relocations. This is wasting memory and prevents security hardening. Please fix.
10-15 17:55:10.145 8565 8565 W gpsd : type=1400 audit(0.0:59): avc: denied { read } for name="overcommit_memory" dev=proc ino=73244 scontext=u:r:gpsd:s0 tcontext=ubject_rroc:s0 tclass=file permissive=0
10-15 17:55:10.157 8565 8565 I libdmitry: Nexus 10 GPS interposition library loaded. Your GPS should work in M now.
10-15 17:55:10.163 2395 7663 I libgps : Restore: type=1, hostname=supl.google.com, port=7276, ssl=0, ssl_version=0, ssl_type=0
10-15 17:55:10.163 2395 7663 I libgps : Save: type=1, hostname=supl.google.com, port=7276, ssl=0, ssl_version=0, ssl_type=0
10-15 17:55:10.160 8565 8565 W gpsd : type=1400 audit(0.0:60): avc: denied { connectto } for path=004D756C7469636C69656E74 scontext=u:r:gpsd:s0 tcontext=u:r:rild:s0 tclass=unix_stream_socket permissive=0
10-15 17:55:11.160 8565 8565 W gpsd : type=1400 audit(0.0:61): avc: denied { connectto } for path=004D756C7469636C69656E74 scontext=u:r:gpsd:s0 tcontext=u:r:rild:s0 tclass=unix_stream_socket permissive=0
10-15 17:55:12.160 8565 8565 W gpsd : type=1400 audit(0.0:62): avc: denied { connectto } for path=004D756C7469636C69656E74 scontext=u:r:gpsd:s0 tcontext=u:r:rild:s0 tclass=unix_stream_socket permissive=0
10-15 17:55:13.165 8565 8565 W gpsd : type=1400 audit(0.0:63): avc: denied { connectto } for path=004D756C7469636C69656E74 scontext=u:r:gpsd:s0 tcontext=u:r:rild:s0 tclass=unix_stream_socket permissive=0
10-15 17:55:14.165 8565 8565 W gpsd : type=1400 audit(0.0:64): avc: denied { connectto } for path=004D756C7469636C69656E74 scontext=u:r:gpsd:s0 tcontext=u:r:rild:s0 tclass=unix_stream_socket permissive=0
10-15 17:55:15.165 8565 8565 W gpsd : type=1400 audit(0.0:65): avc: denied { connectto } for path=004D756C7469636C69656E74 scontext=u:r:gpsd:s0 tcontext=u:r:rild:s0 tclass=unix_stream_socket permissive=0
10-15 17:55:16.165 8565 8565 W gpsd : type=1400 audit(0.0:66): avc: denied { connectto } for path=004D756C7469636C69656E74 scontext=u:r:gpsd:s0 tcontext=u:r:rild:s0 tclass=unix_stream_socket permissive=0
10-15 17:55:17.165 8565 8565 W gpsd : type=1400 audit(0.0:67): avc: denied { connectto } for path=004D756C7469636C69656E74 scontext=u:r:gpsd:s0 tcontext=u:r:rild:s0 tclass=unix_stream_socket permissive=0
10-15 17:55:18.170 8565 8565 W gpsd : type=1400 audit(0.0:68): avc: denied { connectto } for path=004D756C7469636C69656E74 scontext=u:r:gpsd:s0 tcontext=u:r:rild:s0 tclass=unix_stream_socket permissive=0
10-15 17:55:19.165 8565 8565 W gpsd : type=1400 audit(0.0:69): avc: denied { connectto } for path=004D756C7469636C69656E74 scontext=u:r:gpsd:s0 tcontext=u:r:rild:s0 tclass=unix_stream_socket permissive=0
10-15 17:55:20.170 8565 8565 W gpsd : type=1400 audit(0.0:70): avc: denied { connectto } for path=004D756C7469636C69656E74 scontext=u:r:gpsd:s0 tcontext=u:r:rild:s0 tclass=unix_stream_socket permissive=0
10-15 17:55:21.170 8565 8565 W gpsd : type=1400 audit(0.0:71): avc: denied { connectto } for path=004D756C7469636C69656E74 scontext=u:r:gpsd:s0 tcontext=u:r:rild:s0 tclass=unix_stream_socket permissive=0
10-15 17:55:22.170 8565 8565 W gpsd : type=1400 audit(0.0:72): avc: denied { connectto } for path=004D756C7469636C69656E74 scontext=u:r:gpsd:s0 tcontext=u:r:rild:s0 tclass=unix_stream_socket permissive=0
10-15 17:55:23.175 8565 8565 W gpsd : type=1400 audit(0.0:73): avc: denied { connectto } for path=004D756C7469636C69656E74 scontext=u:r:gpsd:s0 tcontext=u:r:rild:s0 tclass=unix_stream_socket permissive=0
10-15 17:55:24.170 8565 8565 W gpsd : type=1400 audit(0.0:74): avc: denied { connectto } for path=004D756C7469636C69656E74 scontext=u:r:gpsd:s0 tcontext=u:r:rild:s0 tclass=unix_stream_socket permissive=0
10-15 17:55:25.449 2395 7663 I libgps : disarming wakeLockTimer
10-15 17:55:25.449 2395 7663 I libgps : [proxy_gps_acquire_wakelock_cb][line = 696]: acquire_wakelock(1)
10-15 17:55:29.685 2395 3249 I ActivityManager: START u0 {flg=0x10804000 cmp=com.android.systemui/.recents.RecentsActivity} from uid 10037 on display 0
10-15 17:55:29.843 2395 3265 I GnssLocationProvider: WakeLock acquired by sendMessage(3, 0, [email protected]eda)
10-15 17:55:29.856 2395 2416 I GnssLocationProvider: WakeLock released by handleMessage(3, 0, [email protected]eda)
10-15 17:55:29.976 2395 2405 I art : Background partial concurrent mark sweep GC freed 47812(2MB) AllocSpace objects, 10(392KB) LOS objects, 33% free, 11MB/17MB, paused 2.440ms total 149.816ms
10-15 17:55:31.177 2395 3255 E ActivityManager: applyOptionsLocked: Unknown animationType=0
---- Oct 15, 2019 17:57:09 ----