Re: [RFC] Fix Device Power Management States

[Benjamin Herrenschmidt]

> 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@xxxxxxxxxxxxxxxxxxx>

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/