Re: [RFC] Fix Device Power Management States
From: Benjamin Herrenschmidt (benh_at_kernel.crashing.org)
Date: 08/10/04
- Previous message: Peter Schaefer: "Re: [VIA-RHINE] Timeouts on EP-HDA3+ Motherboard"
- In reply to: Patrick Mochel: "Re: [RFC] Fix Device Power Management States"
- Next in thread: Pavel Machek: "Re: [RFC] Fix Device Power Management States"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
To: Patrick Mochel <mochel@digitalimplant.org> 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/
- Previous message: Peter Schaefer: "Re: [VIA-RHINE] Timeouts on EP-HDA3+ Motherboard"
- In reply to: Patrick Mochel: "Re: [RFC] Fix Device Power Management States"
- Next in thread: Pavel Machek: "Re: [RFC] Fix Device Power Management States"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
|
