Re: Re: Suspend without the freezer

["Rafael J. Wysocki" <rjw@sisk.pl>]

Hi,

On Tuesday, 31 July 2007 05:52, Dmitry Torokhov wrote:
> Hi Alan,
> 
> On Monday 30 July 2007 16:48, Alan Stern wrote:
> > Dmitry:
> > 
> > I'm trying to help eliminate the need for the freezer during suspend.  
> > For it to work, we have to prevent threads which otherwise would have 
> > been frozen from trying to bind drivers to suspended devices or trying 
> > to register new devices whose parents are already suspended.
> > 
> > To help accomplish this, the PM core can acquire the device semaphores
> > for all existing devices before suspending any of them.  That will
> > prevent attempts at binding.  It would also prevent registration of new
> > children, _if_ the driver doing the registration had to acquire the
> > parent's semaphore first.  But many drivers don't do this.
> > 
> > One thought was to have the PM core acquire and hold the dpm_list_mutex 
> > throughout the suspend.  This would block registration attempts at the 
> > point where the new device is added to the PM core's device-list.
> >
> 
> I think blocking at this point is too late - many drivers muck with
> the device in different ways before registering the "result" with
> driver core. The device may be half-awaken by then.
>   
> > Unfortunately it creates several lockdep violations.  For example, the 
> > serio core holds serio->drv_mutex while input_register_device is 
> > called (which acquires dpm_list_mutex), and it acquires 
> > serio->drv_mutex in serio_suspend and serio_resume (which would be 
> > called while the PM core holds dpm_list_mutex).
> > 
> > I'm having trouble coming up with a way to block registrations during 
> > suspend that won't create a possibility for deadlock.  Do you have any 
> > suggestions?  A scheme that would work for the input layer ought to be 
> > generally applicable.
> >
> 
> One option would be to have a separate thread running registration/binding/
> unbinding (like serio core does). You can stop this thead during suspend
> and resume so that requests are queued up and you process them later, when
> you are ready...

Sounds good.

An alternative could be to have a rwsem taken for writing by the PM core and
for reading by registration/binding/unbinding (and other suspend-sensitive code
paths).

Greetings,
Rafael


-- 
"Premature optimization is the root of all evil." - Donald Knuth