From mboxrd@z Thu Jan 1 00:00:00 1970 From: =?ISO-8859-1?Q?Arve_Hj=F8nnev=E5g?= Subject: Re: [RFC][PATCH 00/11] Android PM extensions Date: Mon, 2 Feb 2009 15:10:10 -0800 Message-ID: References: <200902021200.59992.u.luckas@road.de> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Return-path: In-Reply-To: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: linux-pm-bounces@lists.linux-foundation.org Errors-To: linux-pm-bounces@lists.linux-foundation.org To: Alan Stern Cc: Brian Swetland , linux-pm@lists.linux-foundation.org, Uli Luckas , Nigel Cunningham List-Id: linux-pm@vger.kernel.org On Mon, Feb 2, 2009 at 7:09 AM, Alan Stern wrot= e: > On Mon, 2 Feb 2009, Uli Luckas wrote: >> Except you always want early-suspend and auto-suspend at the same time. = The >> idea is, if all display of system states is off (early-suspend), we can >> enable or disable the cpu at will (auto-suspend) because nobody will not= ice. > > Why should the kernel have to get involved? Why can't userspace manage > both early-suspend and auto-suspend? The kernel does not need to be involved in early-suspend. We use early-suspend as a simple way to shut down the framebuffer and some input devices. If by auto-suspend you mean suspend after user inactivity (usually after a number of seconds or minutes), then the kernel does not need to be involved, but if you mean suspending when all wakelocks are unlocked, the kernel needs to be involved to avoid delays. If the last wakelock to be unlocked is a kernel wakelock, then user-space would not know that it needs to re-attempt suspend. > That is, consider the following: Userspace initiates an early-suspend > by using a runtime PM interface to turn off the screen and some other > devices. After a short time, if they are still off, then userspace can > initiate an auto-suspend by writing "auto-mem" to /sys/power/state. Why do you want a delay? Also, what do you mean by a runtime PM interface? > All the kernel would need to know is the difference between > auto-suspend and normal suspend: one respects wakelocks and the other > doesn't. If by normal suspend you mean what is supported in the kernel now, then OK. We can support existing userspace code by ignoring wakelocks. My intention was that you only enable the WAKELOCK config option when using it, but I agree that it is better to allow the kernel to be built with support for both modes. What do you think should happen if user-space tries to use both interfaces? -- = Arve Hj=F8nnev=E5g