Linux Plumbers Conf 2013

One Line Summary

Abstract

The Linux Kernel currently supports two different methods for drivers to register their power management interfaces. The older method is the Legacy PM ops which is still used by several drivers. The newer method is the dev_pm_ops. Legacy PM ops are not expandable, whereas dev_pm_ops can be extended to add new interfaces as needed when new devices with new power management capabilities get supported. Converting drivers from using Legacy PM ops into using the new dev_pm_ops will allow support for Legacy PM ops to be discontinued and allow older drivers to support new devices that could benefit from dev_pm_ops interfaces.

I am working on converting legacy dev_ops to dev_pm_ops starting at the class level and working my way through bus and driver levels.

Summary of observations and issues I have been encountering:

1. Inconsistent use of CONFIG_PM, CONFIG_SLEEP_PM and CONFIG_PM_RUNTIME in driver code. In some cases suspend and resume routines are defined in CONFIG_PM scope and not in CONFIG_PM_SLEEP scope. All of this leads to warning messages such as the one in this example:

tpm_tis / PM: Fix unused function warning for CONFIG_PM_SLEEP – http://lkml.indiana.edu/hypermail/linux/kernel/1208.1/00528.html

2. Legacy pm_ops suspend is invoked for PM_EVENT_SUSPEND and PM_EVENT_FREEZE. In the dev_pm_ops, PM_EVENT_FREEZE case is handled by the freeze ops. In several cases, adding a new freeze dev_ops is necessary when converting from legacy pm_ops to dev_pm_ops. That is the easy part, and in some cases, when a common routine handles suspend and freeze cases, a writing new suspend and freeze dev_ops that call into the existing common suspend and freeze is necessary. In addition to that freeze ops is executed only when CONFIG_HIBERNATE_CALLBACKS is enabled. For the most part, CONFIG_HIBERNATE_CALLBACKS is enabled, however, yet another thing that adds to the confusion to the inconsistent use of all these PM related config options.

3. For the most part, I have been able to find ways to hook into dev_pm_ops without changes existing data structures. However, I came across some cases that might more difficult and will need changes to enbale access to dev_pm_ops.

I would like to add this topic for discussion to:

1. Increase awareness of the conversion work that is in progress.

2. Discuss how to avoid further proliferation of the inconsistent use of the various PM config options.

3. Discuss how to avoid new legacy pm_ops usages.

4. Discuss how to hook into dev_pm_ops in cases that is not straight forward.

Presentation Materials

Speaker

• 

  Shuah Khan

  Samsung
  • Twitter: ShuahKhan

  Biography

  Shuah Khan is a Senior Linux Kernel Developer at Samsung’s Open Source Group. She is a Linux Kernel Contributor who focuses on IOMMU, DMA, Linux Power Management, and PCIe, in addition to helping with stable release kernel maintenance testing and bug fixes. Shuah has several years of Unix kernel development experience. She has also contributed to OpenHPI, and LLDP projects. She has presented at several internal conferences, and will be speaking at the upcoming LinuxCon America New Orleans, LA.

  Sessions

  • * Power Management Discussions and Lessons Learned: Converting legacy_pm to dev_pm_ops
    • Title: Power Management Discussions and Lessons Learned: Converting legacy_pm to dev_pm_ops
    • Microconference: ACPI/PM, PCI subsystems I
    • Time: 10:40am
    • One Line Summary:

      Discussion on current status, issues and challeges faced, and observations made in converting legacy pm_ops to dev_pm_ops

    • slides
    • Speakers: Shuah Khan