Runtime Power Management in the PCI Subsystem

Session information has not yet been published for this event.

Scheduled: Thursday, November 4, 2010 from 11:40am – 12:25pm in President's Ballroom

One Line Summary

I will describe the implementation of runtime power management support in the Linux kernel's PCI subsystem and the related modifications of the ACPI subsystem.


The core runtime power management (runtime PM) framework for I/O devices, introduced into the Linux kernel last year, can only be used by individual device drivers if it is supported by the subsystems they rely on, such as the PCI bus type. I have recently added the necessary code to the PCI subsystem and it was shipped in the 2.6.34 kernel. The 2.6.35 kernel will include a few PCI drivers using it.

The PCI bus type supports the device runtime PM by providing subsystem-level callbacks that execute driver ruintime PM callbacks, put devices into low-power states and set them up to signal wakeup through the PCI Power Management Event (PME) mechanism. The PME signaling is particularly important, because it allows devices in low-power states to notify the CPU of conditions in which they should be put into the full-power state, but unfortunately it is also complicated. Namely, the PME signal is out-of-band for parallel PCI devices, so it has to be delivered directly to the system core logic that should cause an interrupt to be generated in response to it. On systems following the ACPI specification the ACPI GPE (General Purpose Event) mechanism is used for this purpose. In turn, PCI Express devices use special in-band messages for PME signalling, causing Root Ports to generate interrupts. In some hardware and BIOS configurations these messages are also converted to ACPI GPEs, but if that does not happen, the PME interrupts generated by PCI Express Root Ports need to be processed by a dedicated interrupt handler.

To take the native PCI Express PME signaling into account it was necessary to add a PME service driver for PCI Express Root Ports. Moreover, to make the ACPI-based PME signaling work, the kernel’s ACPI subsystem had to be modified quite significantly, since it made the assumption that GPEs used for waking up the system from sleep states would not be used at run time, which was not correct any more for the GPEs used to signal PCI PMEs. It also assumed that the “runtime” GPEs would not be shared, which was not correct either, because the GPEs used for PME signaling tended to be used by ACPI-based PCI hot-plug at the same time.

I am going to describe the changes made in order to implement the PCI bus type’s device runtime PM support, both in the PCI and the ACPI kernel subsystems. I am also going to give examples of PCI device driver code using it. This should be interesting to PCI device driver writers as well as to people working on user space power management utilities, because they are supposed to control the power management of devices through the interfaces provided by the core I/O runtime PM framework.

I am the author of the majority of code the core I/O runtime PM framework consists of and the PCI bus type’s runtime PM code as well as the supporting ACPI code, so my experience in this area is first-hand.


PCI, runtime PM, ACPI, PME, GPE

Presentation Materials



  • Dr_rafael_wysocki_lks08

    Rafael Wysocki

    University of Warsaw, Faculty of Physics / SUSE Labs, Novell Inc


    I am the maintainer of the Linux kernel’s core power management subsystem. I work at the University of Warsaw, Faculty of Physics, as a Senior Lecturer. I have been working at the university for over 7 years teaching IT and programming and administering computer systems. I also work for SUSE Labs, Novell Inc., as a kernel developer. I have been actively working on the Linux kernel since 2005, mostly on the suspend and hibernate subsystem as well as on power management in general. I also developed the set of user space hibernate utilities called uswsusp that nowadays is widely used by Linux distributions. I am the maintainer of it and a few other PM-related utilities, including the suspend utility called s2ram. Apart from my university lecturer’s speaking experience I was a speaker at multiple conferences, recently at the Linux Symposium 2009 and the Kernel Summit in 2008 and 2009.

Leave a private comment to organizers about this proposal