public inbox for linux-pm@vger.kernel.org
 help / color / mirror / Atom feed
From: Dmitry Torokhov <dtor@insightbb.com>
To: Alan Stern <stern@rowland.harvard.edu>
Cc: Linux-pm mailing list <linux-pm@lists.linux-foundation.org>
Subject: Re: Suspend without the freezer
Date: Mon, 30 Jul 2007 23:52:55 -0400	[thread overview]
Message-ID: <200707302352.56033.dtor@insightbb.com> (raw)
In-Reply-To: <Pine.LNX.4.44L0.0707301634250.2546-100000@iolanthe.rowland.org>

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...

-- 
Dmitry

  reply	other threads:[~2007-07-31  3:52 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-07-30 20:48 Suspend without the freezer Alan Stern
2007-07-31  3:52 ` Dmitry Torokhov [this message]
2007-07-31  9:05   ` Rafael J. Wysocki
2007-07-31 15:24     ` Alan Stern
2007-07-31 19:08       ` Rafael J. Wysocki
2007-07-31 20:48         ` [RFC 1/2] PM: merge drivers/base/power/{main, suspend, resume}.c Alan Stern
2007-07-31 22:15           ` Rafael J. Wysocki
2007-07-31 20:51         ` [RFC 2/2] PM: Lock all devices during suspend/hibernate Alan Stern
2007-07-31 22:20           ` Rafael J. Wysocki
2007-08-01 14:11             ` Alan Stern
2007-08-01 15:37               ` Rafael J. Wysocki
2007-08-01 17:58                 ` Alan Stern
2007-08-01 18:59                   ` Rafael J. Wysocki
2007-08-01  3:50       ` Re: Suspend without the freezer Paul Mackerras
2007-08-01 14:33         ` Alan Stern
2007-08-01 19:08           ` Rafael J. Wysocki
2007-08-01 20:16             ` Alan Stern
2007-07-31 14:58   ` Alan Stern

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=200707302352.56033.dtor@insightbb.com \
    --to=dtor@insightbb.com \
    --cc=linux-pm@lists.linux-foundation.org \
    --cc=stern@rowland.harvard.edu \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox