Messages in this thread | | | Subject | Re: [RFC] Fix Device Power Management States | From | Benjamin Herrenschmidt <> | Date | Tue, 10 Aug 2004 16:52:30 +1000 |
| |
> 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 <benh@kernel.crashing.org>
- 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/
| |