From mboxrd@z Thu Jan 1 00:00:00 1970 From: =?ISO-8859-1?Q?Arve_Hj=F8nnev=E5g?= Subject: Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8) Date: Thu, 27 May 2010 19:47:18 -0700 Message-ID: References: <20100527222514.0a1710bf@lxorguk.ukuu.org.uk> <20100527230806.4deb6de3@lxorguk.ukuu.org.uk> <20100527220949.GB10602@srcf.ucam.org> <20100527232357.6d14fdb2@lxorguk.ukuu.org.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: QUOTED-PRINTABLE Return-path: Received: from mail-px0-f174.google.com ([209.85.212.174]:52542 "EHLO mail-px0-f174.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755257Ab0E1CrV convert rfc822-to-8bit (ORCPT ); Thu, 27 May 2010 22:47:21 -0400 In-Reply-To: <20100527232357.6d14fdb2@lxorguk.ukuu.org.uk> Sender: linux-omap-owner@vger.kernel.org List-Id: linux-omap@vger.kernel.org To: Alan Cox Cc: Matthew Garrett , Alan Stern , Thomas Gleixner , Peter Zijlstra , LKML , Florian Mickler , felipe.balbi@nokia.com, Linux OMAP Mailing List , Linux PM On Thu, May 27, 2010 at 3:23 PM, Alan Cox wr= ote: > On Thu, 27 May 2010 23:09:49 +0100 > Matthew Garrett 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 runn= ing >> 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 lim= ited > by the functionality they have available. Just like any other piece o= f > 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. --=20 Arve Hj=F8nnev=E5g -- To unsubscribe from this list: send the line "unsubscribe linux-omap" i= n the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html