From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756984AbXD0S1h (ORCPT ); Fri, 27 Apr 2007 14:27:37 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1756985AbXD0S1h (ORCPT ); Fri, 27 Apr 2007 14:27:37 -0400 Received: from ogre.sisk.pl ([217.79.144.158]:58001 "EHLO ogre.sisk.pl" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754288AbXD0S1g (ORCPT ); Fri, 27 Apr 2007 14:27:36 -0400 From: "Rafael J. Wysocki" To: David Brownell Subject: Re: [linux-pm] driver power operations (was Re: suspend2 merge) Date: Fri, 27 Apr 2007 20:31:39 +0200 User-Agent: KMail/1.9.5 Cc: linux-pm@lists.linux-foundation.org, Johannes Berg , Pavel Machek , Nick Piggin , Andrew Morton , Mike Galbraith , linux-kernel@vger.kernel.org, Con Kolivas , Adrian Bunk , suspend2-devel@lists.suspend2.net, Thomas Gleixner , Linus Torvalds , Ingo Molnar , Arjan van de Ven References: <1177669279.7828.55.camel@johannes.berg> <200704270856.42524.david-b@pacbell.net> In-Reply-To: <200704270856.42524.david-b@pacbell.net> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200704272031.41215.rjw@sisk.pl> Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org On Friday, 27 April 2007 17:56, David Brownell wrote: > On Friday 27 April 2007, Johannes Berg wrote: > > > > * FREEZE Quiesce operations so that a consistent image can be saved; > > * but do NOT otherwise enter a low power device state, and do > > * NOT emit system wakeup events. > > * > > * PRETHAW Quiesce as if for FREEZE; additionally, prepare for restoring > > * the system from a snapshot taken after an earlier FREEZE. > > * Some drivers will need to reset their hardware state instead > > * of preserving it, to ensure that it's never mistaken for the > > * state which that earlier snapshot had set up. > > > > Why is prethaw even necessary? > > Read the patch comments for the patch adding that transition. Briefly, > adding that transition to swsusp resume was a significant bugfix for > all drivers that rely on controller state to determine how to resume. > > (That's mostly drivers that are intelligent about wakeup events... so > unless you're working with such drivers, the issue may be unclear.) > > > > As far as I can tell it's only necessary > > because resume() can't tell you whether you just want to thaw or need to > > reset since it doesn't tell you at what point it's invoked. > > More like: because swsusp overloaded the suspend()/resume() code paths > to do double duty. > > Instead of just putting devices into low power states (just *which* state > is another discussion), they evolved into support for swsusp transitions... > causing trouble (and sometimes breakage) for non-swsusp models. > > > > Having ->freeze(), ->thaw() and ->restart() (can somebody come up with a > > better name?) that are called at the appropriate places (with > > freeze/thaw around preparing the image and freeze/restart around > > restoring would go a long way of clearing up the confusion in all the > > drivers. Of course, it'd have to be documented that freeze/thaw isn't > > the only valid combination but that freeze/restart is used too, but > > that's not hard to do nor hard to understand. > > I suspect that after snapshot resume restart() should always be used. > That shouldn't be hard to understand at all. It'd be sub-optimal in > the same cases today's system resume is sub-optimal: devices that > were in low power states before system suspend wouldn't be that way > after system resume. > > > > And, incidentally, it could possibly make both suspend and hibernate > > work much faster too. The comments there talk about "minimally power > > management aware" drivers which always do the wrong thing for suspend, > > in that they always reset everything... > > That comment was purely about existing practice ... and was mostly > about resume() processing, not suspend() paths. > > It's an unfortunate reality that most device drivers are stupid in > terms of power management, so we need to be clear about just how > stupid they're allowed to be without being terminally broken. > > Additionally, it would be a Good Thing if changes to clean up the > swsusp-related code paths didn't make "real suspend" more painful. > > > > Of course, some drivers will > > actually need to do that, but if freeze/suspend and thaw/restart/resume > > have the same prototypes (probably just int (void)) then > > drivers can trivially assign the same there. > > And hibernate would benefit since a lot of drivers could do a lot less > > work for freeze/thaw. > > That actually gets into discussions from a while back about wanting > to be able to quiesce() devices, as separate from actually putting > them into low power states. Yes, exactly. Moreover, I think we should separate the current suspend code from the hibernation (aka STD) code paths we're discussing. I mean, we need hibernation-specific equivalents of drivers/base/power/suspend.c etc. Greetings, Rafael