On Thu, May 27, 2010 at 3:23 PM, Alan Cox <alan@xxxxxxxxxxxxxxxxxxx> wrote: > On Thu, 27 May 2010 23:09:49 +0100 > Matthew Garrett <mjg59@xxxxxxxxxxxxx> wrote: > >> On Thu, May 27, 2010 at 11:08:06PM +0100, Alan Cox wrote: >> >> > This is I believe robust (and has been implemented on some non x86 >> > boxes). It depends on not forcing running tasks into suspend. That is the >> > key. >> >> We've already established that ACPI systems require us to force running >> tasks into suspend. How do we avoid the race in that situation? > > Android phones do not have ACPI. Embedded platforms do not have ACPI. MID > x86 devices do not have ACPI. > Android does not only run on phones. It is possible that no android devices have ACPI, but I don't know that for a fact. What I do know is that people want to run Android on x86 hardware and supporting suspend could be very benficial. > I would imagine the existing laptops will handle power management limited > by the functionality they have available. Just like any other piece of > hardware. I think existing laptops (and desktops) can benefit from opportunistic suspend support. If opportunistic suspend is used for auto-sleep after inactivity instead of forced suspend, the user space suspend blocker api will allow an application to delay this auto sleep until for instance a download completes. This part could also be done with a user-space IPC call, but having a standard kernel interface for it may make it more common. A less common case, but more critical, is RTC alarms. I know my desktops can wakeup at a specific time by programming an RTC alarm, but without suspend blockers how do you ensure that the system does not suspend right after the alarm triggered? I have a system that wakes up at specific times requested by my DVR application, but I cannot use this system for anything else unless I manually turn off the DVR application's auto-sleep feature. With suspend blockers and something like the android alarm driver, I could use this system for more than one application that have scheduled tasks and it would be more usable for interactive applications. -- Arve Hjønnevåg -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
