lkml.org 
[lkml]   [2004]   [Aug]   [10]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    SubjectRe: [RFC] Fix Device Power Management States
    From
    Date

    > 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/

    \
     
     \ /
      Last update: 2005-03-22 14:05    [W:4.020 / U:0.752 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site