Re: [Zaurus-devel] [suspend/resume] Re: userspace notification from module
On Friday 15 January 2010, Pavel Machek wrote: > On Sat 2010-01-09 14:40:46, Rafael J. Wysocki wrote: > > On Saturday 09 January 2010, Pavel Machek wrote: > > > > > Perhaps I don't understand correctly what you're trying to achieve, but > > > > at the > > > > moment suspend is always started from user space, this way or another, > > > > and on > > > > > > At least zaurus (arm) suspends from kernel on battery critical. > > > > I wasn't aware of this. > > > > That may be a good reason for adding kernel-based suspend notification, > > although I'd prefer ARM to notify the user space about the critical battery > > status allowing it to decide what to do. > > Hard to do, without breaking compatibility that goes down to 2.4.X. Sending a battery-critical notification to the user space is not equivalent to removing the existing kernel-based mechanism. They can exist both at the same time if the notification is sent earlier than the kernel suspends everything. > > IMhO automatic suspend without something like the Android's wakelocks hurts > > more than it helps. > > It really makes sense on zaurus. Those machines are simple, no > smartbattery and no embedded controller subsystems. Battery will not > protect itself, and its kernel job. (Should work on init=/bin/bash). > > As power-off consumption is same as suspend power consumption (I > beleive zaurus simply does not have true power off), suspend on > critical makes some sense. (Note that it is set lower than on pcs, and > that we declare battery critical sooner than that.) The problem with that is it catches at least some applications unprepared and notifying them that "we're suspending right now" doesn't really help, because they won't have any time to react anyway. Rafael ___ Zaurus-devel mailing list Zaurus-devel@lists.linuxtogo.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/zaurus-devel
Re: [Zaurus-devel] [suspend/resume] Re: userspace notification from module
Eric Miao wrote: > And the other way we may need to look into what API the current userland > apps on zaurus is depending on this 2.4 compatibility and make changes > slowly to those apps. I guess that 2.4 compatibility is not an issue. Most modern Zaurus distributions are even unable to run Sharp ROM compatible binaries. Distributions either stay on 2.4 kernel or use modern systems based on modern kernel 2.6 API. Distributions that decided to migrate to kernel 2.6 are far from finished state. Any change that allows to use modern applications using standard kernel API is welcome. Stanislav Brabec http://www.penguin.cz/~utx/zaurus ___ Zaurus-devel mailing list Zaurus-devel@lists.linuxtogo.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/zaurus-devel
Re: [Zaurus-devel] [suspend/resume] Re: userspace notification from module
Hi! > > > I wasn't aware of this. > > > > > > That may be a good reason for adding kernel-based suspend notification, > > > although I'd prefer ARM to notify the user space about the critical > > > battery > > > status allowing it to decide what to do. > > > > Hard to do, without breaking compatibility that goes down to 2.4.X. > > Sending a battery-critical notification to the user space is not equivalent to > removing the existing kernel-based mechanism. They can exist both at the > same time if the notification is sent earlier than the kernel suspends > everything. Yes, and obviously sending notification early is ok with me. > > It really makes sense on zaurus. Those machines are simple, no > > smartbattery and no embedded controller subsystems. Battery will not > > protect itself, and its kernel job. (Should work on init=/bin/bash). > > > > As power-off consumption is same as suspend power consumption (I > > beleive zaurus simply does not have true power off), suspend on > > critical makes some sense. (Note that it is set lower than on pcs, and > > that we declare battery critical sooner than that.) > > The problem with that is it catches at least some applications unprepared and > notifying them that "we're suspending right now" doesn't really help, because > they won't have any time to react anyway. Agreed, but so what? On PC, machine would power off at that point. That would surprise the apps, too. Basically new enough userland should not make battery run low enough for either emergency power off or emergency suspend. IOW "nothing to see here, problem does not exist". Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html ___ Zaurus-devel mailing list Zaurus-devel@lists.linuxtogo.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/zaurus-devel
Re: [Zaurus-devel] [suspend/resume] Re: userspace notification from module
Hi!
> >> > That may be a good reason for adding kernel-based suspend notification,
> >> > although I'd prefer ARM to notify the user space about the critical
> >> > battery
> >> > status allowing it to decide what to do.
> >>
> >> Hard to do, without breaking compatibility that goes down to 2.4.X.
> >
> > Sending a battery-critical notification to the user space is not equivalent
> > to
> > removing the existing kernel-based mechanism. They can exist both at the
> > same time if the notification is sent earlier than the kernel suspends
> > everything.
>
> I'd agree with Rafael that we need to move battery management forward to
> a more standard way though we can keep the compatibility atm. The code
> of sharpsl-pm.c is no way clean and maintainable. Having a battery driver
> instead would be a better way to go in a long run.
Something like below? Yes, I'd like to get something like that pushed.
> And the other way we may need to look into what API the current userland
> apps on zaurus is depending on this 2.4 compatibility and make changes
> slowly to those apps.
Well, emergency suspend/poweroff should still work in init=/bin/bash
mode. And doing emergency poweroff when we are capable of suspend
seems wrong.
Pavel
--- ./drivers/power.ofic/Makefile 2009-10-06 13:51:29.0 +0200
+++ ./drivers/power/Makefile2009-10-11 16:12:09.0 +0200
@@ -24,6 +24,7 @@
obj-$(CONFIG_BATTERY_PMU) += pmu_battery.o
obj-$(CONFIG_BATTERY_OLPC) += olpc_battery.o
obj-$(CONFIG_BATTERY_TOSA) += tosa_battery.o
+obj-m += spitz_battery.o
obj-$(CONFIG_BATTERY_WM97XX) += wm97xx_battery.o
obj-$(CONFIG_BATTERY_BQ27x00) += bq27x00_battery.o
obj-$(CONFIG_BATTERY_DA9030) += da9030_battery.o
diff -ur ./drivers/power.ofic/power_supply_sysfs.c
./drivers/power/power_supply_sysfs.c
--- ./drivers/power.ofic/power_supply_sysfs.c 2009-10-06 13:51:29.0
+0200
+++ ./drivers/power/power_supply_sysfs.c2009-10-15 05:45:46.0
+0200
@@ -39,7 +39,8 @@
static ssize_t power_supply_show_property(struct device *dev,
struct device_attribute *attr,
- char *buf) {
+ char *buf)
+{
static char *status_text[] = {
"Unknown", "Charging", "Discharging", "Not charging", "Full"
};
@@ -135,7 +136,8 @@
static ssize_t power_supply_show_static_attrs(struct device *dev,
struct device_attribute *attr,
- char *buf) {
+ char *buf)
+{
static char *type_text[] = { "Battery", "UPS", "Mains", "USB" };
struct power_supply *psy = dev_get_drvdata(dev);
diff -ur ./drivers/power.ofic/spitz_battery.c ./drivers/power/spitz_battery.c
--- ./drivers/power.ofic/spitz_battery.c2009-10-11 16:14:11.0
+0200
+++ ./drivers/power/spitz_battery.c 2009-10-22 07:27:52.0 +0200
@@ -0,0 +1,430 @@
+/*
+ * Battery and Power Management code for the Sharp SL-3000c
+ *
+ * Copyright (c) 2009 Pavel Machek
+ *
+ * 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.
+ *
+ * Li-ion batteries are angry beasts, and they like to explode.
+ * If angry lithium comes your way, the hw was misdesigned.
+ *
+ */
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include
+#include
+#include
+#include
+
+#include "../../arch/arm/mach-pxa/sharpsl.h"
+
+extern struct sharpsl_pm_status sharpsl_pm;
+
+
+struct spitz_bat {
+ struct power_supply psy;
+
+ bool (*is_present)(struct spitz_bat *bat);
+};
+
+static struct spitz_bat spitz_bat_main, spitz_ac;
+
+extern int sharpsl_pm_pxa_read_max(int channel);
+
+int basic_current = 125; /* miliAmp */
+int battery_resistance = 422; /* miliOhm */
+
+/* 422 seems to be suitable for very old, 1Ah battery.
+ 2Ah battery probably has better resistance */
+
+/* Unfortunately, resistance depends on state of charge, current
+ * direction and temperature.
+ *
+ * Ouch, and dependency is actually _not_ too simple. It is lowest
+ * at 3.55V, very slowly rises at 4V (approximately linear dependency),
+ * and quickly rises towards 3.2V (in something exponential-looking).
+ *
+ * It is about same at 25Celsius and 40Celsius, and about 2.5x the value
+ * on 0Celsius, rising _very_ sharply.
+ *
+ * Li-ion should only be charged between 0 and 45 Celsius, and discharged
+ * between -20 and 60 celsius.
+ */
+
+extern int backlight_current;
+
+int battery_current(void)
+{
+ int intensity = sharpsl_pm.machinfo->backlight_get_status ?
sharpsl_pm.machinfo->backlight_get_status() : 0;
+
+ return basic_current + backlight
Re: [Zaurus-devel] [suspend/resume] Re: userspace notification from module
On Sat 2010-01-16 18:00:58, Stanislav Brabec wrote: > Eric Miao wrote: > > > And the other way we may need to look into what API the current userland > > apps on zaurus is depending on this 2.4 compatibility and make changes > > slowly to those apps. > > I guess that 2.4 compatibility is not an issue. Most modern Zaurus > distributions are even unable to run Sharp ROM compatible binaries. > > Distributions either stay on 2.4 kernel or use modern systems based on > modern kernel 2.6 API. > > Distributions that decided to migrate to kernel 2.6 are far from > finished state. Any change that allows to use modern applications using > standard kernel API is welcome. There is no API involved. It is just ... if you leave zaurus in init=/bin/bash mode, it must not kill the battery. Smart and currently implemented way to do that is to suspend. That's counterexample to rjw, but it does not matter -- reasonable userland should never ever hit that, in a same way PCs should not hit emergency power cut... Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html ___ Zaurus-devel mailing list Zaurus-devel@lists.linuxtogo.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/zaurus-devel
Re: [Zaurus-devel] [suspend/resume] Re: userspace notification from module
On Saturday 16 January 2010, Pavel Machek wrote: > On Sat 2010-01-16 18:00:58, Stanislav Brabec wrote: > > Eric Miao wrote: > > > > > And the other way we may need to look into what API the current userland > > > apps on zaurus is depending on this 2.4 compatibility and make changes > > > slowly to those apps. > > > > I guess that 2.4 compatibility is not an issue. Most modern Zaurus > > distributions are even unable to run Sharp ROM compatible binaries. > > > > Distributions either stay on 2.4 kernel or use modern systems based on > > modern kernel 2.6 API. > > > > Distributions that decided to migrate to kernel 2.6 are far from > > finished state. Any change that allows to use modern applications using > > standard kernel API is welcome. > > There is no API involved. It is just ... if you leave zaurus in > init=/bin/bash mode, it must not kill the battery. Smart and > currently implemented way to do that is to suspend. IMHO it should just plain shutdown in that case. Suspending doesn't really solve the problem, because the battery is going to drain still. Unless you mean suspend=hibernate, but I guess you don't. > That's counterexample to rjw, but it does not matter -- reasonable > userland should never ever hit that, in a same way PCs should not hit > emergency power cut... I don't really understand what you mean. The user space doesn't know the battery state if the kernel doesn't tell it, AFAICS, so how exactly can it predict the critical battery condition without the kernel notifying it? Rafael ___ Zaurus-devel mailing list Zaurus-devel@lists.linuxtogo.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/zaurus-devel
Re: [Zaurus-devel] [suspend/resume] Re: userspace notification from module
On Saturday 16 January 2010, Pavel Machek wrote: > Hi! > > > > > I wasn't aware of this. > > > > > > > > That may be a good reason for adding kernel-based suspend notification, > > > > although I'd prefer ARM to notify the user space about the critical > > > > battery > > > > status allowing it to decide what to do. > > > > > > Hard to do, without breaking compatibility that goes down to 2.4.X. > > > > Sending a battery-critical notification to the user space is not equivalent > > to > > removing the existing kernel-based mechanism. They can exist both at the > > same time if the notification is sent earlier than the kernel suspends > > everything. > > Yes, and obviously sending notification early is ok with me. > > > > It really makes sense on zaurus. Those machines are simple, no > > > smartbattery and no embedded controller subsystems. Battery will not > > > protect itself, and its kernel job. (Should work on init=/bin/bash). > > > > > > As power-off consumption is same as suspend power consumption (I > > > beleive zaurus simply does not have true power off), suspend on > > > critical makes some sense. (Note that it is set lower than on pcs, and > > > that we declare battery critical sooner than that.) > > > > The problem with that is it catches at least some applications unprepared > > and > > notifying them that "we're suspending right now" doesn't really help, > > because > > they won't have any time to react anyway. > > Agreed, but so what? On PC, machine would power off at that > point. That would surprise the apps, too. > > Basically new enough userland should not make battery run low enough > for either emergency power off or emergency suspend. I wonder how it is supposed to achieve that without knowing the current battery status. Do you mean it should poll the battery driver? Rafael ___ Zaurus-devel mailing list Zaurus-devel@lists.linuxtogo.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/zaurus-devel
Re: [Zaurus-devel] [suspend/resume] Re: userspace notification from module
Hi! > > Agreed, but so what? On PC, machine would power off at that > > point. That would surprise the apps, too. > > > > Basically new enough userland should not make battery run low enough > > for either emergency power off or emergency suspend. > > I wonder how it is supposed to achieve that without knowing the current > battery > status. Do you mean it should poll the battery driver? That's besides point, is it? Usual kernel<->user interfaces should apply here. Zaurus provides /proc/apm emulation, and I'm writing drivers/power/ driver. Not sure it has event interface... Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html ___ Zaurus-devel mailing list Zaurus-devel@lists.linuxtogo.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/zaurus-devel
Re: [Zaurus-devel] [suspend/resume] Re: userspace notification from module
On Sat 2010-01-16 23:05:56, Rafael J. Wysocki wrote: > On Saturday 16 January 2010, Pavel Machek wrote: > > On Sat 2010-01-16 18:00:58, Stanislav Brabec wrote: > > > Eric Miao wrote: > > > > > > > And the other way we may need to look into what API the current userland > > > > apps on zaurus is depending on this 2.4 compatibility and make changes > > > > slowly to those apps. > > > > > > I guess that 2.4 compatibility is not an issue. Most modern Zaurus > > > distributions are even unable to run Sharp ROM compatible binaries. > > > > > > Distributions either stay on 2.4 kernel or use modern systems based on > > > modern kernel 2.6 API. > > > > > > Distributions that decided to migrate to kernel 2.6 are far from > > > finished state. Any change that allows to use modern applications using > > > standard kernel API is welcome. > > > > There is no API involved. It is just ... if you leave zaurus in > > init=/bin/bash mode, it must not kill the battery. Smart and > > currently implemented way to do that is to suspend. > > IMHO it should just plain shutdown in that case. Suspending doesn't really > solve the problem, because the battery is going to drain still. Unless you > mean suspend=hibernate, but I guess you don't. As I explained before, power consumption on suspend and hibernate and poweroff is equivalent on zaurus (7mA in all the cases -- sorry if I said uA before). And because it has 1800mAh battery, it means that even empty battery is going to last for a while. In practice, it works very well. (There are other reasons, having to do with internal li-ion resistances in aged and cold batteries.) > > That's counterexample to rjw, but it does not matter -- reasonable > > userland should never ever hit that, in a same way PCs should not hit > > emergency power cut... > > I don't really understand what you mean. The user space doesn't know the > battery state if the kernel doesn't tell it, AFAICS, so how exactly can it > predict the critical battery condition without the kernel notifying it? That was not the point I was trying to discuss. Yes, we need kernel<->user notification of battery critical. But on zaurus, correct action is to suspend (not hibernate and not poweroff) when battery is no longer able to supply enough power to keep system alive. Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html ___ Zaurus-devel mailing list Zaurus-devel@lists.linuxtogo.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/zaurus-devel
Re: [Zaurus-devel] [suspend/resume] Re: userspace notification from module
On Saturday 16 January 2010, Pavel Machek wrote: > Hi! > > > > Agreed, but so what? On PC, machine would power off at that > > > point. That would surprise the apps, too. > > > > > > Basically new enough userland should not make battery run low enough > > > for either emergency power off or emergency suspend. > > > > I wonder how it is supposed to achieve that without knowing the current > > battery > > status. Do you mean it should poll the battery driver? > > That's besides point, is it? Well, mentioned that first. :-) > Usual kernel<->user interfaces should apply here. And we're talking about the design of these, aren't we? The notification about the critical battery status sent to the user space is a part of the kernel-user space interface too, after all. Rafael ___ Zaurus-devel mailing list Zaurus-devel@lists.linuxtogo.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/zaurus-devel
Re: [Zaurus-devel] [suspend/resume] Re: userspace notification from module
On Saturday 16 January 2010, Pavel Machek wrote: > On Sat 2010-01-16 23:05:56, Rafael J. Wysocki wrote: > > On Saturday 16 January 2010, Pavel Machek wrote: > > > On Sat 2010-01-16 18:00:58, Stanislav Brabec wrote: > > > > Eric Miao wrote: > > > > > > > > > And the other way we may need to look into what API the current > > > > > userland > > > > > apps on zaurus is depending on this 2.4 compatibility and make changes > > > > > slowly to those apps. > > > > > > > > I guess that 2.4 compatibility is not an issue. Most modern Zaurus > > > > distributions are even unable to run Sharp ROM compatible binaries. > > > > > > > > Distributions either stay on 2.4 kernel or use modern systems based on > > > > modern kernel 2.6 API. > > > > > > > > Distributions that decided to migrate to kernel 2.6 are far from > > > > finished state. Any change that allows to use modern applications using > > > > standard kernel API is welcome. > > > > > > There is no API involved. It is just ... if you leave zaurus in > > > init=/bin/bash mode, it must not kill the battery. Smart and > > > currently implemented way to do that is to suspend. > > > > IMHO it should just plain shutdown in that case. Suspending doesn't really > > solve the problem, because the battery is going to drain still. Unless you > > mean suspend=hibernate, but I guess you don't. > > As I explained before, power consumption on suspend and hibernate and > poweroff is equivalent on zaurus (7mA in all the cases -- sorry if I > said uA before). And because it has 1800mAh battery, it means that > even empty battery is going to last for a while. In practice, it works > very well. > > (There are other reasons, having to do with internal li-ion resistances > in aged and cold batteries.) > > > > That's counterexample to rjw, but it does not matter -- reasonable > > > userland should never ever hit that, in a same way PCs should not hit > > > emergency power cut... > > > > I don't really understand what you mean. The user space doesn't know the > > battery state if the kernel doesn't tell it, AFAICS, so how exactly can it > > predict the critical battery condition without the kernel notifying it? > > That was not the point I was trying to discuss. Yes, we need > kernel<->user notification of battery critical. > > But on zaurus, correct action is to suspend (not hibernate and not > poweroff) when battery is no longer able to supply enough power to > keep system alive. Why not to poweroff (just asking, I don't know that hardware)? I guess we should at least do our best to keep filesystems in a consistent state and suspend doesn't really guarantee this if the system remains on battery power afterwards. Rafael ___ Zaurus-devel mailing list Zaurus-devel@lists.linuxtogo.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/zaurus-devel
Re: [Zaurus-devel] [suspend/resume] Re: userspace notification from module
> > IMHO it should just plain shutdown in that case. Suspending doesn't really > > solve the problem, because the battery is going to drain still. Unless you > > mean suspend=hibernate, but I guess you don't. BTW I was talking spitz before, but there's collie, too. It was shipped in configuration where all user data was in RAM and RAMdisk -- no writable flash. On such machine, shutdown is never option. (And yes, such design was very common in windowsCE days). Spitz got disk, but inherited that powermanagement design; and it works very well. And now, if you want collie for a year (or two), you can have mine... it still works and battery still lasted for 5 hours 2 years ago -- not bad for 10 year old battery. You'll note that it is very different design from PC. Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html ___ Zaurus-devel mailing list Zaurus-devel@lists.linuxtogo.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/zaurus-devel
Re: [Zaurus-devel] [suspend/resume] Re: userspace notification from module
On Saturday 16 January 2010, Pavel Machek wrote: > > > IMHO it should just plain shutdown in that case. Suspending doesn't > > > really > > > solve the problem, because the battery is going to drain still. Unless > > > you > > > mean suspend=hibernate, but I guess you don't. > > BTW I was talking spitz before, but there's collie, too. It was > shipped in configuration where all user data was in RAM and RAMdisk -- > no writable flash. On such machine, shutdown is never option. (And > yes, such design was very common in windowsCE days). > > Spitz got disk, but inherited that powermanagement design; and it > works very well. > > And now, if you want collie for a year (or two), you can have > mine... it still works and battery still lasted for 5 hours 2 years > ago -- not bad for 10 year old battery. You'll note that it is very > different design from PC. Well, I guess I wouldn't have the time to study it anyway, so thanks. :-) All in all, it looks like these particular platforms are just specific design having special requirements. And even on these platforms sending a battery critical notification to the user space before the kernel emergency suspends (or shuts down or whatever) the system seems to be a good idea in general. Rafael ___ Zaurus-devel mailing list Zaurus-devel@lists.linuxtogo.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/zaurus-devel
Re: [Zaurus-devel] [suspend/resume] Re: userspace notification from module
On Sat, Jan 16, 2010 at 11:05:56PM +0100, Rafael J. Wysocki wrote: > On Saturday 16 January 2010, Pavel Machek wrote: > > On Sat 2010-01-16 18:00:58, Stanislav Brabec wrote: > > > Eric Miao wrote: > > > > > > > And the other way we may need to look into what API the current userland > > > > apps on zaurus is depending on this 2.4 compatibility and make changes > > > > slowly to those apps. > > > > > > I guess that 2.4 compatibility is not an issue. Most modern Zaurus > > > distributions are even unable to run Sharp ROM compatible binaries. > > > > > > Distributions either stay on 2.4 kernel or use modern systems based on > > > modern kernel 2.6 API. > > > > > > Distributions that decided to migrate to kernel 2.6 are far from > > > finished state. Any change that allows to use modern applications using > > > standard kernel API is welcome. > > > > There is no API involved. It is just ... if you leave zaurus in > > init=/bin/bash mode, it must not kill the battery. Smart and > > currently implemented way to do that is to suspend. > > IMHO it should just plain shutdown in that case. Suspending doesn't really > solve the problem, because the battery is going to drain still. Unless you > mean suspend=hibernate, but I guess you don't. FYI, most handheld/palm-based devices don't have a "power off" mode, short of opening them up and disconnecting the battery. The "on/off" button is really just a "suspend/resume" button. So, when the battery gets critically low, your only option is to suspend. If the battery continues to be drained, and it's a properly manufacturered li-ion battery, it will have a discharge protection circuit inside the battery which will effectively disconnect the battery until it's recharged. There is no warning of this event. The whole idea here is in a low battery sitution, is to place the system into as low power state as possible to try to retain the users data. (Some protection circuits monitor each li-ion cell, which means if you have a single weak cell, it can trip before you get the critical suspend notification.) There are also some SoCs which have a battery fault input, which forces a transition to suspend mode with no software intervention what so ever, placing the SDRAM into self-refresh (data retention) mode. Wakeup from such a mode can only be done by total SoC reset once the fault input has been removed. Either way, the issue here is that when you get a critical low battery notification, there may be seconds of power left if the system is fully operational, and you must suspend as quickly as possible before the hardware does something more destructive to your state. Probably the best way of thinking about this is a layered set of notifications: - monitor battery level, cleanly suspend when down to N% - if ignored, you get a critical low battery notification which forces an unclean suspend transition, retaining most device, CPU and RAM state. - if ignored, a hardware initiated suspend transition occurs, retaining just RAM state. - if that doesn't work, the battery itself cuts power and all state is lost. ___ Zaurus-devel mailing list Zaurus-devel@lists.linuxtogo.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/zaurus-devel
