From mboxrd@z Thu Jan 1 00:00:00 1970 From: Dmitry Torokhov Subject: Re: Suspend without the freezer Date: Mon, 30 Jul 2007 23:52:55 -0400 Message-ID: <200707302352.56033.dtor@insightbb.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: Content-Disposition: inline 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: Linux-pm mailing list List-Id: linux-pm@vger.kernel.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