17 May, 2014

1 commit


21 Mar, 2014

1 commit


14 May, 2013

1 commit


04 Jul, 2012

1 commit


30 Jan, 2012

1 commit

  • The current device suspend/resume phases during system-wide power
    transitions appear to be insufficient for some platforms that want
    to use the same callback routines for saving device states and
    related operations during runtime suspend/resume as well as during
    system suspend/resume. In principle, they could point their
    .suspend_noirq() and .resume_noirq() to the same callback routines
    as their .runtime_suspend() and .runtime_resume(), respectively,
    but at least some of them require device interrupts to be enabled
    while the code in those routines is running.

    It also makes sense to have device suspend-resume callbacks that will
    be executed with runtime PM disabled and with device interrupts
    enabled in case someone needs to run some special code in that
    context during system-wide power transitions.

    Apart from this, .suspend_noirq() and .resume_noirq() were introduced
    as a workaround for drivers using shared interrupts and failing to
    prevent their interrupt handlers from accessing suspended hardware.
    It appears to be better not to use them for other porposes, or we may
    have to deal with some serious confusion (which seems to be happening
    already).

    For the above reasons, introduce new device suspend/resume phases,
    "late suspend" and "early resume" (and analogously for hibernation)
    whose callback will be executed with runtime PM disabled and with
    device interrupts enabled and whose callback pointers generally may
    point to runtime suspend/resume routines.

    Signed-off-by: Rafael J. Wysocki
    Reviewed-by: Mark Brown
    Reviewed-by: Kevin Hilman

    Rafael J. Wysocki
     

22 Dec, 2011

1 commit

  • Make the PM core execute driver PM callbacks directly if the
    corresponding subsystem callbacks are not present.

    There are three reasons for doing that. First, it reflects the
    behavior of drivers/base/dd.c:really_probe() that runs the driver's
    .probe() callback directly if the bus type's one is not defined, so
    this change will remove one arbitrary difference between the PM core
    and the remaining parts of the driver core. Second, it will allow
    some subsystems, whose PM callbacks don't do anything except for
    executing driver callbacks, to be simplified quite a bit by removing
    those "forward-only" callbacks. Finally, it will allow us to remove
    one level of indirection in the system suspend and resume code paths
    where it is not necessary, which is going to lead to less debug noise
    with initcall_debug passed in the kernel command line (messages won't
    be printed for driverless devices whose subsystems don't provide
    PM callbacks among other things).

    Signed-off-by: Rafael J. Wysocki

    Rafael J. Wysocki
     

29 Nov, 2011

3 commits


17 Oct, 2011

2 commits

  • There is a problem with the current ordering of hibernate code which
    leads to deadlocks in some filesystems' memory shrinkers. Namely,
    some filesystems use freezable kernel threads that are inactive when
    the hibernate memory preallocation is carried out. Those same
    filesystems use memory shrinkers that may be triggered by the
    hibernate memory preallocation. If those memory shrinkers wait for
    the frozen kernel threads, the hibernate process deadlocks (this
    happens with XFS, for one example).

    Apparently, it is not technically viable to redesign the filesystems
    in question to avoid the situation described above, so the only
    possible solution of this issue is to defer the freezing of kernel
    threads until the hibernate memory preallocation is done, which is
    implemented by this change.

    Unfortunately, this requires the memory preallocation to be done
    before the "prepare" stage of device freeze, so after this change the
    only way drivers can allocate additional memory for their freeze
    routines in a clean way is to use PM notifiers.

    Reported-by: Christoph
    Signed-off-by: Rafael J. Wysocki

    Rafael J. Wysocki
     
  • This patch (as1485) documents a change to the kernel's default wakeup
    policy. Devices that forward wakeup requests between buses should be
    enabled for wakeup by default.

    Signed-off-by: Alan Stern
    Signed-off-by: Rafael J. Wysocki

    Alan Stern
     

02 Jul, 2011

2 commits

  • The documents describing the interactions between runtime PM and
    system sleep generally refer to the model in which the system sleep
    state is entered through a global firmware or hardware operation.
    As a result, some recommendations given in there are not entirely
    suitable for systems in which this is not the case. Update the
    documentation to take the existence of those systems into account.

    Signed-off-by: Rafael J. Wysocki
    Reviewed-by: Kevin Hilman

    Rafael J. Wysocki
     
  • The naming convention used by commit 7538e3db6e015e890825fbd9f86599b
    (PM: Add support for device power domains), which introduced the
    struct dev_power_domain type for representing device power domains,
    evidently confuses some developers who tend to think that objects
    of this type must correspond to "power domains" as defined by
    hardware, which is not the case. Namely, at the kernel level, a
    struct dev_power_domain object can represent arbitrary set of devices
    that are mutually dependent power management-wise and need not belong
    to one hardware power domain. To avoid that confusion, rename struct
    dev_power_domain to struct dev_pm_domain and rename the related
    pointers in struct device and struct pm_clk_notifier_block from
    pwr_domain to pm_domain.

    Signed-off-by: Rafael J. Wysocki
    Acked-by: Kevin Hilman

    Rafael J. Wysocki
     

22 Jun, 2011

2 commits

  • Commit 4d27e9dcff00a6425d779b065ec8892e4f391661 (PM: Make power
    domain callbacks take precedence over subsystem ones) forgot to
    update the device power management documentation to take changes
    made by it into account. Correct that mistake.

    Signed-off-by: Rafael J. Wysocki

    Rafael J. Wysocki
     
  • The part of Documentation/power/devices.txt regarding sysdevs is not
    valid any more after commit 2e711c04dbbf7a7732a3f7073b1fc285d12b369d
    (PM: Remove sysdev suspend, resume and shutdown operations), so
    remove it.

    Signed-off-by: Rafael J. Wysocki

    Rafael J. Wysocki
     

18 May, 2011

1 commit

  • If device drivers allocate substantial amounts of memory (above 1 MB)
    in their hibernate .freeze() callbacks (or in their legacy suspend
    callbcks during hibernation), the subsequent creation of hibernate
    image may fail due to the lack of memory. This is the case, because
    the drivers' .freeze() callbacks are executed after the hibernate
    memory preallocation has been carried out and the preallocated amount
    of memory may be too small to cover the new driver allocations.
    Unfortunately, the drivers' .prepare() callbacks also are executed
    after the hibernate memory preallocation has completed, so they are
    not suitable for allocating additional memory either. Thus the only
    way a driver can safely allocate memory during hibernation is to use
    a hibernate/suspend notifier. However, the notifiers are called
    before the freezing of user space and the drivers wanting to use them
    for allocating additional memory may not know how much memory needs
    to be allocated at that point.

    To let device drivers overcome this difficulty rework the hibernation
    sequence so that the memory preallocation is carried out after the
    drivers' .prepare() callbacks have been executed, so that the
    .prepare() callbacks can be used for allocating additional memory
    to be used by the drivers' .freeze() callbacks. Update documentation
    to match the new behavior of the code.

    Signed-off-by: Rafael J. Wysocki

    Rafael J. Wysocki
     

31 Mar, 2011

1 commit


15 Mar, 2011

3 commits

  • The code handling system-wide power transitions (eg. suspend-to-RAM)
    can in theory execute callbacks provided by the device's bus type,
    device type and class in each phase of the power transition. In
    turn, the runtime PM core code only calls one of those callbacks at
    a time, preferring bus type callbacks to device type or class
    callbacks and device type callbacks to class callbacks.

    It seems reasonable to make them both behave in the same way in that
    respect. Moreover, even though a device may belong to two subsystems
    (eg. bus type and device class) simultaneously, in practice power
    management callbacks for system-wide power transitions are always
    provided by only one of them (ie. if the bus type callbacks are
    defined, the device class ones are not and vice versa). Thus it is
    possible to modify the code handling system-wide power transitions
    so that it follows the core runtime PM code (ie. treats the
    subsystem callbacks as mutually exclusive).

    On the other hand, the core runtime PM code will choose to execute,
    for example, a runtime suspend callback provided by the device type
    even if the bus type's struct dev_pm_ops object exists, but the
    runtime_suspend pointer in it happens to be NULL. This is confusing,
    because it may lead to the execution of callbacks from different
    subsystems during different operations (eg. the bus type suspend
    callback may be executed during runtime suspend of the device, while
    the device type callback will be executed during system suspend).

    Make all of the power management code treat subsystem callbacks in
    a consistent way, such that:
    (1) If the device's type is defined (eg. dev->type is not NULL)
    and its pm pointer is not NULL, the callbacks from dev->type->pm
    will be used.
    (2) If dev->type is NULL or dev->type->pm is NULL, but the device's
    class is defined (eg. dev->class is not NULL) and its pm pointer
    is not NULL, the callbacks from dev->class->pm will be used.
    (3) If dev->type is NULL or dev->type->pm is NULL and dev->class is
    NULL or dev->class->pm is NULL, the callbacks from dev->bus->pm
    will be used provided that both dev->bus and dev->bus->pm are
    not NULL.

    Signed-off-by: Rafael J. Wysocki
    Acked-by: Kevin Hilman
    Reasoning-sounds-sane-to: Grant Likely
    Acked-by: Greg Kroah-Hartman

    Rafael J. Wysocki
     
  • The platform bus type is often used to handle Systems-on-a-Chip (SoC)
    where all devices are represented by objects of type struct
    platform_device. In those cases the same "platform" device driver
    may be used with multiple different system configurations, but the
    actions needed to put the devices it handles into a low-power state
    and back into the full-power state may depend on the design of the
    given SoC. The driver, however, cannot possibly include all the
    information necessary for the power management of its device on all
    the systems it is used with. Moreover, the device hierarchy in its
    current form also is not suitable for representing this kind of
    information.

    The patch below attempts to address this problem by introducing
    objects of type struct dev_power_domain that can be used for
    representing power domains within a SoC. Every struct
    dev_power_domain object provides a sets of device power
    management callbacks that can be used to perform what's needed for
    device power management in addition to the operations carried out by
    the device's driver and subsystem.

    Namely, if a struct dev_power_domain object is pointed to by the
    pwr_domain field in a struct device, the callbacks provided by its
    ops member will be executed in addition to the corresponding
    callbacks provided by the device's subsystem and driver during all
    power transitions.

    Signed-off-by: Rafael J. Wysocki
    Tested-and-acked-by: Kevin Hilman

    Rafael J. Wysocki
     
  • Currently, wakeup sysfs attributes are created for all devices,
    regardless of whether or not they are wakeup-capable. This is
    excessive and complicates wakeup device identification from user
    space (i.e. to identify wakeup-capable devices user space has to read
    /sys/devices/.../power/wakeup for all devices and see if they are not
    empty).

    Fix this issue by avoiding to create wakeup sysfs files for devices
    that cannot wake up the system from sleep states (i.e. whose
    power.can_wakeup flags are unset during registration) and modify
    device_set_wakeup_capable() so that it adds (or removes) the relevant
    sysfs attributes if a device's wakeup capability status is changed.

    Signed-off-by: Rafael J. Wysocki

    Rafael J. Wysocki
     

11 May, 2010

2 commits


13 Jun, 2009

1 commit

  • Remove the ->suspend_late() and ->resume_early() callbacks
    from struct bus_type V2. These callbacks are legacy stuff
    at this point and since there seem to be no in-tree users
    we may as well remove them. New users should use dev_pm_ops.

    Signed-off-by: Magnus Damm
    Acked-by: Pavel Machek
    Acked-by: Greg Kroah-Hartman
    Signed-off-by: Rafael J. Wysocki

    Magnus Damm
     

20 Apr, 2008

1 commit

  • Modify the PM core to protect its data structures, specifically the
    dpm_active list, from being corrupted if a child of the currently
    suspending device is registered concurrently with its ->suspend()
    callback. In that case, since the new device (the child) is added
    to dpm_active after its parent, the PM core will attempt to
    suspend it after the parent, which is wrong.

    Introduce a new member of struct dev_pm_info, called 'sleeping',
    and use it to check if the parent of the device being added to
    dpm_active has been suspended, in which case the device registration
    fails. Also, use 'sleeping' for checking if the ordering of devices
    on dpm_active is correct.

    Introduce variable 'all_sleeping' that will be set to 'true' once all
    devices have been suspended and make new device registrations fail
    until 'all_sleeping' is reset to 'false', in order to avoid having
    unsuspended devices around while the system is going into a sleep state.

    Remove pm_sleep_rwsem which is not necessary any more.

    Special thanks to Alan Stern for discussions and suggestions that
    lead to the creation of this patch.

    Signed-off-by: Rafael J. Wysocki
    Acked-by: Pavel Machek
    Signed-off-by: Greg Kroah-Hartman

    Rafael J. Wysocki
     

24 Feb, 2008

1 commit

  • During the last step of hibernation in the "platform" mode (with the
    help of ACPI) we use the suspend code, including the devices'
    ->suspend() methods, to prepare the system for entering the ACPI S4
    system sleep state.

    But at least for some devices the operations performed by the
    ->suspend() callback in that case must be different from its operations
    during regular suspend.

    For this reason, introduce the new PM event type PM_EVENT_HIBERNATE and
    pass it to the device drivers' ->suspend() methods during the last phase
    of hibernation, so that they can distinguish this case and handle it as
    appropriate. Modify the drivers that handle PM_EVENT_SUSPEND in a
    special way and need to handle PM_EVENT_HIBERNATE in the same way.

    These changes are necessary to fix a hibernation regression related
    to the i915 driver (ref. http://lkml.org/lkml/2008/2/22/488).

    Signed-off-by: Rafael J. Wysocki
    Acked-by: Pavel Machek
    Tested-by: Jeff Chua
    Signed-off-by: Linus Torvalds

    Rafael J. Wysocki
     

02 Feb, 2008

1 commit

  • The /sys/devices/.../power/state files have been gone for a while
    now, but I just noticed some documentation that still refers to
    them. (Fortunately described as DEPRECATED and WILL REMOVE).

    Time to remove that obsolete documentation too ...

    Signed-off-by: David Brownell
    Acked-by: Pavel Machek
    Signed-off-by: Rafael J. Wysocki
    Signed-off-by: Len Brown

    David Brownell
     

26 Sep, 2006

1 commit

  • This turned into a rewrite of Documentation/power/devices.txt:

    - Provide more of the "big picture"

    - Fixup some of the horribly ancient/obsolete description of device suspend()
    semantics; lots of text just got deleted.

    - Add a decent description of PM_EVENT_* codes, including the new PRETHAW code
    needed in some swsusp scenarios.

    - Describe the new PM factorization from Linus:
    * class suspend, current suspend, then suspend_late
    * NOT suspend_prepare, it wasn't really usable
    * resume_early, current resume, class resume.

    - Updates power/state docs to be correct, and deprecate its usage except for
    driver testing.

    Signed-off-by: David Brownell
    Signed-off-by: Greg Kroah-Hartman

    David Brownell
     

22 Jun, 2006

1 commit


18 May, 2005

1 commit

  • The driver model has a "detach_state" mechanism that:

    - Has never been used by any in-kernel drive;
    - Is superfluous, since driver remove() methods can do the same thing;
    - Became buggy when the suspend() parameter changed semantics and type;
    - Could self-deadlock when called from certain suspend contexts;
    - Is effectively wasted documentation, object code, and headspace.

    This removes that "detach_state" mechanism; net code shrink, as well
    as a per-device saving in the driver model and sysfs.

    Signed-off-by: David Brownell
    Signed-off-by: Greg Kroah-Hartman

    David Brownell
     

17 Apr, 2005

1 commit

  • Initial git repository build. I'm not bothering with the full history,
    even though we have it. We can create a separate "historical" git
    archive of that later if we want to, and in the meantime it's about
    3.2GB when imported into git - space that would just make the early
    git days unnecessarily complicated, when we don't have a lot of good
    infrastructure for it.

    Let it rip!

    Linus Torvalds