Date:	Tue, 25 May 2010 17:26:13 -0700
From:	Dmitry Torokhov <dmitry.torokhov@...il.com>
To:	Arve Hjønnevåg <arve@...roid.com>
Cc:	Alan Stern <stern@...land.harvard.edu>,
	Linux-pm mailing list <linux-pm@...ts.linux-foundation.org>,
	Kernel development list <linux-kernel@...r.kernel.org>,
	"Rafael J. Wysocki" <rjw@...k.pl>, Len Brown <len.brown@...el.com>,
	Pavel Machek <pavel@....cz>,
	Randy Dunlap <rdunlap@...otime.net>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Andi Kleen <ak@...ux.intel.com>,
	Cornelia Huck <cornelia.huck@...ibm.com>,
	Tejun Heo <tj@...nel.org>,
	Jesse Barnes <jbarnes@...tuousgeek.org>,
	Nigel Cunningham <nigel@...onice.net>,
	Ming Lei <tom.leiming@...il.com>,
	Wu Fengguang <fengguang.wu@...el.com>,
	Maxim Levitsky <maximlevitsky@...il.com>,
	linux-doc@...r.kernel.org
Subject: Re: [PATCH 1/8] PM: Opportunistic suspend support.

On Tue, May 25, 2010 at 04:54:34PM -0700, Arve Hjønnevåg wrote:
> 2010/5/25 Dmitry Torokhov <dmitry.torokhov@...il.com>:
> > On Tue, May 25, 2010 at 04:13:35PM -0700, Arve Hjønnevåg wrote:
> >>
> >> You are missing the point. There are no event pending. The kernel
> >> reported the key down event, it was handled, but the keypad driver is
> >> still scanning to see if the user presses another key,
> >
> > Employ reasonable timeout.
> 
> Timeout for what? Stop trying to suspend altogether, stop scanning for
> key changes, or a more "reasonable" poll interval?

Stop trying to suspend for a fraction of a second to see if user wants
to press another key.

> 
> >
> >> or releases the
> >> currently held key.
> >>
> >
> > Userspace consumer should wait for the key release and retract "busy"
> > once event is received and handled.
> >
> 
> No it should not. User-space does not know if the key is coming from a
> keypad driver that needs to actively scan the matrix while keys are
> pressed.

OTOH nor does kernel driver know whether system suspend should be
blocked while it is scanning. What should happen in I press KEY_SUSPEND?
Do we always want to wait till user releases it?

> 
> >> >
> >> > 2. Wait a tiny bit after last application notified you that it finished
> >> > processing events.
> >> >
> >> > So basically the difference is that with in-kernel suspend blockers,
> >> > there is a tiny window where we haven't started the suspend yet but are
> >> > about to the driver has a chance to prevent entire system from starting
> >> > sleep.
> >>
> >> No, the difference is that if a driver needs to prevent suspend for an
> >> extended period of time, you don't have user space continuously
> >> polling to see if it can suspend.
> >
> > Why would a driver, on its own, prevent suspend for extended periods of
> > time? I think that the decision should originate from userspace, kernel
> > is here just to serve the requests.
> >
> 
> A driver prevents suspend if suspend would prevent it from working.
> For instance, the gpio keypad matrix code prevents suspend when a key
> is help down, since it has to activly scan the keypad for changes.
> Only no-keys-pressed versus one-or-more-keys-pressed can be detected
> with an interrupt.
> 
> >>
> >> >
> >> > Without the blocker we may start suspending and will stop midcycle. We
> >> > may be even better off in the end since we could leave some devices
> >> > still powered down after aborting system-wide suspend.
> >> >
> >>
> >> That does not sound right.
> >
> > Why doesn't it? If a device implements runtime PM it may chose remain in
> > powered-down mode even if system is awake.
> >
> 
> If the device implements runtime PM it should already be powered-down
> if it is not in use.

It could have been in use but userspace-initiated suspend accelerated it
entering low power state.

-- 
Dmitry
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists