Re: [markgross@thengar.org: [RFC] wake up notifications and suspend blocking (aka more wakelock stuff)]

[mark gross <markgross@thegnar.org>]

On Thu, Oct 13, 2011 at 11:06:35AM -0400, Alan Stern wrote:
> On Wed, 12 Oct 2011, mark gross wrote:
> 
> > > > > sometimes devices that are not wake up sources need critical sections
> > > > > where suspend is a problem.
> > > 
> > > Mark, can you give some examples?  This isn't the same as the firmware 
> > > update thing, is it?  That deserves to be handled by a completely 
> > > separate mechanism.
> > 
> > The biggest example I know of is any usb gadget implementation while
> > connected to a USB host.  If the device is connected to the USB bus then
> > it needs to not suspend because it cannot respond to the USB commands
> > for bus power.  i.e. if its connected to a laptop and the suspend the
> > laptop the gadget needs to handle the USB protocol packets.
> > 
> > Also, when charging battery under OS control we don't want to suspend
> > because it will be hard to respond to thermal events  or changing
> > battery conditions if the system is in suspend.
> 
> This is like the firmware update problem -- it has nothing to do with 
> wakeups.  It could be handled very easily either by abusing a wakeup 
> source as Neil suggested or by adding a different mechanism for 
> preventing system sleeps.

yes.  This is just another mechanism to prevent sleeps.

> > > Although many of these problems could be solved by adopting a suitable
> > > protocol in userspace, currently there is no such protocol.  Even if
> > > one did exist, the process of getting all the relevant programs to
> > > adopt it would take quite a while.  This is a case where a problem can
> > > be solved either in the kernel or in userspace, and the in-kernel
> > > solution may be simpler.
> > 
> > I do think a better solution would involve some kernel coordination.
> > 
> > I don't want to split hairs on if its 100% possible to implement a
> > correct solution only in user mode.  but, I think there are corner cases
> > that may be hard or impossible to get right with only user mode.  See
> > gadget issue above.  Not all gadgets have a user mode daemon backing up
> > the kernel part do they?
> 
> I don't know.  But if they don't have some sort of userspace component
> for power management then they never go into suspend, because the
> kernel doesn't initiate suspends by itself.

yes, but the kernel can / does block user initiated suspends from
various user mode initiators.  All this is for is to block suspend entry
until the driver is ok with it.  this patch is nothing more than that
really.

--mark