Re: Re: [2008.testing] GPS after resume
Further tests show that 1. after resume, Navit does not get another GPS fix 2. leaving Navit open, and on forcing a cold start with agpsui, agpsui does not even see the time signal (I assume Navit blocks it), but this is enough for Navit to get a fix So at least there is a workaround. It would be nice if there was some primitive GPS UI built into Navit. Regards Jeff ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [2008.testing] GPS after resume
jeffrey.ratcli...@gmail.com wrote:
Further tests show that
1. after resume, Navit does not get another GPS fix
2. leaving Navit open, and on forcing a cold start with agpsui, agpsui
does not even see the time signal (I assume Navit blocks it), but this
is enough for Navit to get a fix
So at least there is a workaround.
As I wrote already, there is a bug in kernel GPS suspend/resume code which
leads to GPS not being powered after resume. Simply re-enable it manually via
Settings, or apply my patch sent to kernel list (but still not merged into git)
- http://lists.openmoko.org/pipermail/openmoko-kernel/2009-January/007447.html
I'm attaching also a version against stable.git for those still running 2.6.24..
Regards,
Vladimir
It would be nice if there was some primitive GPS UI built into Navit.
Regards
Jeff
___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community
commit 98c1e4301f98d977443104d6206d8ebc91b18bf3
Author: Vladimir Koutny vl...@ksp.sk
Date: Mon Jan 5 14:16:01 2009 +0100
Fix re-enabling of GPS on resume
The call to gps_pwron_set(0) during suspend would clear power_was_on
flag so the on/off status was always lost
Signed-off-by: Vladimir Koutny vl...@ksp.sk
diff --git a/arch/arm/plat-s3c24xx/neo1973_pm_gps.c b/arch/arm/plat-s3c24xx/neo1973_pm_gps.c
index 73337fa..5ca6691 100644
--- a/arch/arm/plat-s3c24xx/neo1973_pm_gps.c
+++ b/arch/arm/plat-s3c24xx/neo1973_pm_gps.c
@@ -300,8 +300,6 @@ static void gps_pwron_set(int on)
if ((!on) (neo1973_gps.power_was_on))
regulator_disable(neo1973_gps.regulator);
}
-
- neo1973_gps.power_was_on = !!on;
}
static int gps_pwron_get(void)
@@ -358,13 +356,12 @@ static ssize_t power_gps_write(struct device *dev,
{
unsigned long on = simple_strtoul(buf, NULL, 10);
- if (!strcmp(attr-attr.name, pwron))
-#ifdef CONFIG_MACH_NEO1973_GTA01
-{
-#endif
+ if (!strcmp(attr-attr.name, pwron)) {
gps_pwron_set(on);
+ neo1973_gps.power_was_on = !!on;
+ }
#ifdef CONFIG_MACH_NEO1973_GTA01
- } else if (!strcmp(attr-attr.name, power_avdd_3v)) {
+ else if (!strcmp(attr-attr.name, power_avdd_3v)) {
gps_power_3v_set(on);
} else if (!strcmp(attr-attr.name, power_tcxo_2v8)) {
gps_power_2v8_set(on);
commit e96e0fbc123a1b6cbd8cef6f82dc559124cbcad5
Author: Vladimir Koutny vl...@ksp.sk
Date: Mon Jan 5 22:35:35 2009 +0100
Fix re-enabling of GPS on resume
The call to gps_pwron_set(0) during suspend would clear power_was_on
flag so the on/off status was always lost
Signed-off-by: Vladimir Koutny vl...@ksp.sk
diff --git a/arch/arm/plat-s3c24xx/neo1973_pm_gps.c b/arch/arm/plat-s3c24xx/neo1973_pm_gps.c
index a21b763..7d56562 100644
--- a/arch/arm/plat-s3c24xx/neo1973_pm_gps.c
+++ b/arch/arm/plat-s3c24xx/neo1973_pm_gps.c
@@ -271,9 +271,6 @@ static int gps_power_1v5_get(void)
/* This is the POWERON pin */
static void gps_pwron_set(int on)
{
-
- neo1973_gps.power_was_on = !!on;
-
#ifdef CONFIG_MACH_NEO1973_GTA01
if (machine_is_neo1973_gta01())
neo1973_gpb_setpin(GTA01_GPIO_GPS_PWRON, on);
@@ -393,6 +390,7 @@ static ssize_t power_gps_write(struct device *dev,
} else if (!strcmp(attr-attr.name, power_avdd_3v)) {
gps_power_3v_set(on);
} else if (!strcmp(attr-attr.name, pwron)) {
+ neo1973_gps.power_was_on = !!on;
gps_pwron_set(on);
} else if (!strcmp(attr-attr.name, reset)) {
gps_rst_set(on);
signature.asc
Description: OpenPGP digital signature
___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community
Re: [2008.testing] GPS after resume
2009/1/12 Vladimir Koutny vl...@moko.ksp.sk: As I wrote already, there is a bug in kernel GPS suspend/resume code which leads to GPS not being powered after resume. Simply re-enable it manually via Settings, or apply my patch sent to kernel list (but still not merged into git) - http://lists.openmoko.org/pipermail/openmoko-kernel/2009-January/007447.html Ah. I hadn't spotted that. Thanks for the info. Regards Jeff ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [2008.testing] GPS after resume
On Monday 05 January 2009, Jeffrey Ratcliffe wrote: 2009/1/5 Al Johnson openm...@mazikeen.demon.co.uk: Yes, and I think ogpsd is supposed to do this. Almanac and ephemeris is saved when preparing for suspend, and loaded on resume, along with current time. If things haven't changed too much while suspend then resume should be faster than from cold. Is this only available in FSO? i.e. not 2008.12? It's in FSO, SHR and Debian, and according to another thread it is an option in the testing branch of 2008.x though I haven't checked that myself. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [2008.testing] GPS after resume
Yes, and I think ogpsd is supposed to do this. Almanac and ephemeris is saved when preparing for suspend, and loaded on resume, along with current time. If things haven't changed too much while suspend then resume should be faster than from cold. On Sunday 04 January 2009, Yorick Moko wrote: nice! but would it not be possible to let the gps poweroff and artificially feed it the last known sattelite positions? so that i can get a hot-start after suspend, without using more power? anyway, thanks for your contribution! y On Sun, Jan 4, 2009 at 11:17 AM, Vladimir Koutny vl...@moko.ksp.sk wrote: i was thinking about this the other day. the gps has it's own processor, correct, and can act independently of the cpu? i'm wondering if it's possible for the gps to keep it's fix while the main cpu is in suspend. power usage will be higher than a full suspend, but the phone will have a fix as soon as it resumes. is there any reason why this can't happen? I wrote attached patch for this few days ago - it is against mwester's stable kernel so probably still needs some tweaks for 2.6.28 series. Simply 'echo 1 /sys/bus/i2c/devices/0-0073/neo1973-pm-gps.0/keep_on_in_suspend' and it will stay alive during suspend (echo 0 to turn it off - this is also the default). It also fixes a bug with re-enabling GPS on resume when it was on before (keep_on_in_suspend=0). I'm going to split this into 2 patches and send it to devel soon. vlado ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [2008.testing] GPS after resume
2009/1/5 Al Johnson openm...@mazikeen.demon.co.uk: Yes, and I think ogpsd is supposed to do this. Almanac and ephemeris is saved when preparing for suspend, and loaded on resume, along with current time. If things haven't changed too much while suspend then resume should be faster than from cold. Is this only available in FSO? i.e. not 2008.12? Regards Jeff ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [2008.testing] GPS after resume
Hi, Jeffrey Ratcliffe jeffrey.ratcli...@gmail.com writes: 2009/1/5 Al Johnson openm...@mazikeen.demon.co.uk: Yes, and I think ogpsd is supposed to do this. Almanac and ephemeris is saved when preparing for suspend, and loaded on resume, along with current time. If things haven't changed too much while suspend then resume should be faster than from cold. Is this only available in FSO? i.e. not 2008.12? It's implemented partially in FSO for a long time. Every time the GPS is turned off, the important data is saved to the file and loaded after turning on the next time. The problem is that sometimes loading ephemeris really hurts time-to-fix. That's why this code is commented out in FSO. If anyone has any ideas, suggestions or _experience_with_loading_ ephemeris_, please contribute to http://trac.freesmartphone.org/ticket/261 (especially, if you're not using FSO, as it might help to find why FSO implementation doesn't work as expected). -- Be free, use free (http://www.gnu.org/philosophy/free-sw.html) software! mailto:fercer...@gmail.com ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [2008.testing] GPS after resume
nice! but would it not be possible to let the gps poweroff and artificially feed it the last known sattelite positions? so that i can get a hot-start after suspend, without using more power? anyway, thanks for your contribution! y On Sun, Jan 4, 2009 at 11:17 AM, Vladimir Koutny vl...@moko.ksp.sk wrote: i was thinking about this the other day. the gps has it's own processor, correct, and can act independently of the cpu? i'm wondering if it's possible for the gps to keep it's fix while the main cpu is in suspend. power usage will be higher than a full suspend, but the phone will have a fix as soon as it resumes. is there any reason why this can't happen? I wrote attached patch for this few days ago - it is against mwester's stable kernel so probably still needs some tweaks for 2.6.28 series. Simply 'echo 1 /sys/bus/i2c/devices/0-0073/neo1973-pm-gps.0/keep_on_in_suspend' and it will stay alive during suspend (echo 0 to turn it off - this is also the default). It also fixes a bug with re-enabling GPS on resume when it was on before (keep_on_in_suspend=0). I'm going to split this into 2 patches and send it to devel soon. vlado ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [2008.testing] GPS after resume
i was thinking about this the other day. the gps has it's own
processor, correct, and can act independently of the cpu? i'm
wondering if it's possible for the gps to keep it's fix while the main
cpu is in suspend. power usage will be higher than a full suspend, but
the phone will have a fix as soon as it resumes. is there any reason
why this can't happen?
I wrote attached patch for this few days ago - it is against mwester's stable
kernel so probably still needs some tweaks for 2.6.28 series.
Simply 'echo 1
/sys/bus/i2c/devices/0-0073/neo1973-pm-gps.0/keep_on_in_suspend'
and it will stay alive during suspend (echo 0 to turn it off - this is also the
default).
It also fixes a bug with re-enabling GPS on resume when it was on before
(keep_on_in_suspend=0).
I'm going to split this into 2 patches and send it to devel soon.
vlado
diff -Naur knife-kernel-orig/arch/arm/mach-s3c2440/mach-gta02.c knife-kernel/arch/arm/mach-s3c2440/mach-gta02.c
--- knife-kernel-orig/arch/arm/mach-s3c2440/mach-gta02.c 2008-11-18 02:15:36.0 +0100
+++ knife-kernel/arch/arm/mach-s3c2440/mach-gta02.c 2009-01-01 10:56:31.0 +0100
@@ -714,6 +714,7 @@
PMU_VRAIL_F_UNUSED;
gta02_pcf_pdata.rails[PCF50633_REGULATOR_LDO5] = ((struct pmu_voltage_rail) {
.name = rf_3v,
+ .flags = PMU_VRAIL_F_SUSPEND_ON,
.voltage = {
.init = 0,
.max = 3000,
diff -Naur knife-kernel-orig/arch/arm/plat-s3c24xx/neo1973_pm_gps.c knife-kernel/arch/arm/plat-s3c24xx/neo1973_pm_gps.c
--- knife-kernel-orig/arch/arm/plat-s3c24xx/neo1973_pm_gps.c 2008-11-18 02:15:36.0 +0100
+++ knife-kernel/arch/arm/plat-s3c24xx/neo1973_pm_gps.c 2009-01-03 16:29:05.0 +0100
@@ -35,6 +35,7 @@
struct neo1973_pm_gps_data {
int power_was_on;
+ int keep_on_in_suspend;
};
static struct neo1973_pm_gps_data neo1973_gps;
@@ -271,9 +272,6 @@
/* This is the POWERON pin */
static void gps_pwron_set(int on)
{
-
- neo1973_gps.power_was_on = !!on;
-
#ifdef CONFIG_MACH_NEO1973_GTA01
if (machine_is_neo1973_gta01())
neo1973_gpb_setpin(GTA01_GPIO_GPS_PWRON, on);
@@ -354,6 +352,17 @@
return 0;
}
+/* This is the flag for keeping gps ON during suspend */
+static void gps_keep_on_in_suspend_set(int on)
+{
+ neo1973_gps.keep_on_in_suspend = on;
+}
+
+static int gps_keep_on_in_suspend_get(void)
+{
+ return neo1973_gps.keep_on_in_suspend;
+}
+
static ssize_t power_gps_read(struct device *dev,
struct device_attribute *attr, char *buf)
{
@@ -374,6 +383,8 @@
} else if (!strcmp(attr-attr.name, power_core_1v5) ||
!strcmp(attr-attr.name, power_vdd_core_1v5)) {
ret = gps_power_1v5_get();
+ } else if (!strcmp(attr-attr.name, keep_on_in_suspend)) {
+ ret = gps_keep_on_in_suspend_get();
}
if (ret)
@@ -393,6 +404,7 @@
} else if (!strcmp(attr-attr.name, power_avdd_3v)) {
gps_power_3v_set(on);
} else if (!strcmp(attr-attr.name, pwron)) {
+ neo1973_gps.power_was_on = !!on;
gps_pwron_set(on);
} else if (!strcmp(attr-attr.name, reset)) {
gps_rst_set(on);
@@ -403,6 +415,8 @@
} else if (!strcmp(attr-attr.name, power_core_1v5) ||
!strcmp(attr-attr.name, power_vdd_core_1v5)) {
gps_power_1v5_set(on);
+ } else if (!strcmp(attr-attr.name, keep_on_in_suspend)) {
+ gps_keep_on_in_suspend_set(on);
}
return count;
@@ -496,6 +510,7 @@
static DEVICE_ATTR(power_vdd_core_1v5, 0644, power_gps_read, power_gps_write);
static DEVICE_ATTR(power_sequence, 0644, power_sequence_read,
power_sequence_write);
+static DEVICE_ATTR(keep_on_in_suspend, 0644, power_gps_read, power_gps_write);
#ifdef CONFIG_PM
static int gta01_pm_gps_suspend(struct platform_device *pdev,
@@ -509,8 +524,14 @@
#endif /* CONFIG_MACH_NEO1973_GTA01 */
#ifdef CONFIG_MACH_NEO1973_GTA02
- if (machine_is_neo1973_gta02())
- gps_pwron_set(0);
+ if (machine_is_neo1973_gta02()) {
+ if (!neo1973_gps.keep_on_in_suspend ||
+ !neo1973_gps.power_was_on)
+ gps_pwron_set(0);
+ else
+ dev_warn(pdev-dev, GTA02: keeping gps ON
+ during suspend\n);
+ }
#endif /* CONFIG_MACH_NEO1973_GTA02 */
return 0;
@@ -526,7 +547,7 @@
#ifdef CONFIG_MACH_NEO1973_GTA02
if (machine_is_neo1973_gta02())
- if (neo1973_gps.power_was_on)
+ if (!neo1973_gps.keep_on_in_suspend neo1973_gps.power_was_on)
gps_pwron_set(1);
#endif /* CONFIG_MACH_NEO1973_GTA02 */
@@ -556,6 +577,7 @@
static struct attribute *gta02_gps_sysfs_entries[] = {
dev_attr_pwron.attr,
+ dev_attr_keep_on_in_suspend.attr,
NULL
};
signature.asc
Description: OpenPGP digital signature
___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community
Re: [2008.testing] GPS after resume
2009/1/2 Marco Trevisan (Treviño) m...@3v1n0.net: I figure that this should be controlled by the kernel side. Simply the GPS chip is turned off and then on on suspend/resume. That's why on resuming it's like you've done a cold reset. There should be a thread about this on the kernel list... Maybe, but even agpsui doesn't play well on resume - the cold/warm/hot reset button do nothing. Restarting the application gets a normal cold start. Regards Jeff ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [2008.testing] GPS after resume
2009/1/3 Marco Trevisan (Treviño) m...@3v1n0.net: Jeffrey Ratcliffe wrote: Having installed navit on my GTA02v5, it seems that it loses GPS after resuming. I haven't finished playing around to see if this is a GPS problem or a navit problem, but while I do, has anyone else noticed? Found a solution? I figure that this should be controlled by the kernel side. Simply the GPS chip is turned off and then on on suspend/resume. That's why on resuming it's like you've done a cold reset. i was thinking about this the other day. the gps has it's own processor, correct, and can act independently of the cpu? i'm wondering if it's possible for the gps to keep it's fix while the main cpu is in suspend. power usage will be higher than a full suspend, but the phone will have a fix as soon as it resumes. is there any reason why this can't happen? cheers ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
[2008.testing] GPS after resume
Having installed navit on my GTA02v5, it seems that it loses GPS after resuming. I haven't finished playing around to see if this is a GPS problem or a navit problem, but while I do, has anyone else noticed? Found a solution? Regards Jeff ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [2008.testing] GPS after resume
Jeffrey Ratcliffe wrote: Having installed navit on my GTA02v5, it seems that it loses GPS after resuming. I haven't finished playing around to see if this is a GPS problem or a navit problem, but while I do, has anyone else noticed? Found a solution? I figure that this should be controlled by the kernel side. Simply the GPS chip is turned off and then on on suspend/resume. That's why on resuming it's like you've done a cold reset. There should be a thread about this on the kernel list... -- Treviño's World - Life and Linux http://www.3v1n0.net/ ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
