From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S267449AbUHJG4N (ORCPT ); Tue, 10 Aug 2004 02:56:13 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S267450AbUHJG4N (ORCPT ); Tue, 10 Aug 2004 02:56:13 -0400 Received: from gate.crashing.org ([63.228.1.57]:22998 "EHLO gate.crashing.org") by vger.kernel.org with ESMTP id S267449AbUHJG4F (ORCPT ); Tue, 10 Aug 2004 02:56:05 -0400 Subject: Re: [RFC] Fix Device Power Management States From: Benjamin Herrenschmidt To: Patrick Mochel Cc: Linux Kernel list , Pavel Machek , David Brownell In-Reply-To: References: <1092098425.14102.69.camel@gaston> Content-Type: text/plain Message-Id: <1092120750.14102.95.camel@gaston> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Tue, 10 Aug 2004 16:52:30 +1000 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org > It's easy enough to change which order things get stopped/started in. What > matters more is the conceptual shift in responsibility for who > stops/starts the devices, or rather their interfaces. > > It also requires a mapping from struct device -> struct class_device that > the drivers will have to initialize. Yup, but class devices don't follow the bus topology, do they ? > > What about passing the previous state to restore ? could be useful... > > It's saved in dev->power.pm_resume, so drivers can check it. > > > Who calls it ? It's the driver calling it's bus or what ? It make no > > sense to power manage a device before suspending activity... I agree it > > may be worth splitting dev_start/stop from PM transitions proper, that > > would help dealing with various policies, however, there are still some > > dependencies between those, and they all need to be tied to the bus > > topology. > > The driver core calls it in device_power_down() (as was in the patch ;), > in physical topological order. The ordering of the calls is up the power > management core, but it just wouldn't make sense to power down a device > that wasn't stopped. Would be easy enough to add a check for it.. > > Note it would make sense to power down a device without stopping, if the > device had no device driver bound to it (e.g. unclaimed devices that are > in D0 unnecessarily; or unclaimed devices that need to be powered down > during a suspend transition). Ok, just be careful with that as some "platform" devices may not have a driver bound and still don't want to be powered down... but we could create fake drivers... > > What about partial tree ? We need to suspend childs first and we need to > > tied PM transition with dev_start/stop (or have some way to indicate the > > device we want it to auto-resume when it gets a request, or something). > > We need to work out policy a bit more here I suppose... > > Policy can come later; we have to have a working model first. > > As far as partial trees go, it can be done using the posted patch. Think > about why you want to suspend/resume a partial tree - to use a particular > leaf device. You know what device it is, and by virtue of the driver > model, you know each of its ancestors. So, you walk the tree up to the > root, and restart all the way down. Then, you re-stop it all the way back > up. Should be ~10 lines of code that is left as an exercise against the > posted patch. :) > > > Pat -- Benjamin Herrenschmidt