![]() | |||||||||||||
Messages in this thread |
On Tue, 10 Aug 2004, Benjamin Herrenschmidt wrote: > > This is implemented by iterating through the list of struct classes, > > then through each of their struct class_device's. The class_device is > > the only argument to those functions. > > Hrm... I don't agree, that iteration should be done in bus ordering too. > > For example, if you stop operation of a USB host controller, you have to > do that after you have stopped operation of child devices. Same goes > with the ATA disk vs. controller. The ordering requirements for stopping > operations are the same as for PM 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. > What about passing the previous state to restore ? could be useful... It's saved in dev->power.pm_resume, so drivers can check it. > > - To struct bus_type: > > > > int (*pm_power)(struct device *, struct pm_state *); > > > > This method is used to do all power transitions, including both > > shutdown/reset and device power management states. > > 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). > 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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ | ||||||||||||
| Last update: 2005-03-22 14:05 [from the cache] ©2003-2008 | |||||||||||||