Runtime PM deployment for ARM systems

Registered by Linus Walleij on 2012-11-03

During Linaro Connect in Copenhagen it was brought to attention that while runtime PM is considered the way forward for fine-grained power management on ARM, some details remain to iron out.

Currently the only architectures considered to do things right when it comes to runtime PM is OMAP and the SH family.

Instead of using runtime PM with PM domains, many archs have started to sprinkle voltage domain, silicon clock (pclk) and pin control PM handling all over drivers the driver/* subtree. This needs to be resolved by a joint effort of cleaning up and centralizing runtime PM for all member platforms.

BACKGROUND:

The basic paradigm of the people who invented runtime PM (Kevin Hilman, Magnus Damm, Rafael Wysocki) is as far as I can understand that anything that is specific to the SoC interconnect or layout shall be handled in the PM domains.

That includes:

- Voltage domains
- Silicon block clocks, i.e. the gate logic clock, not e.g a clock for an external UART or SPI bus
- Pin multiplexing and biasing (pinctrl)

The basic question is: will this part of the driver be a set of quirks for every other chip it's instatiated on? E.g. for the drivers/tty/serial/amba-pl011.c which is used for maybe
5 or 6 totally different SoCs from different vendors, will it end up with a field in platform data (or directly in the device tree) like .is_soc_a .is_soc_b, ... then it should instead be handled at the PM domain level.

Currently what is happening in the kernel can be described as two different approaches:

- A centralized approach to anything SoC-specific, such as clocks, voltage, pins, handled in PM domains, drivers will only take care of the reference counting. (OMAP, SH)
- A decentralized approach: each driver takes care of clocks, voltage, pins for it's own silicon block, using SoC-specific quirks if need be.

The assumption of the blueprint is that the first approach is the right one, but I'm very very uncertain about this, and if you check the linked discussion you can see that many subsystem maintainers disagree on the way forward.

For subsystem maintainers discussing the "right" approach, see:
http://marc.info/?l=linux-input&w=2&r=1&s=omap4-keypad&q=b

Blueprint information

Status:
Not started
Approver:
Amit Kucheria
Priority:
Undefined
Drafter:
Linus Walleij
Direction:
Needs approval
Assignee:
None
Definition:
New
Series goal:
None
Implementation:
Unknown
Milestone target:
None

Related branches

Sprints

Whiteboard

(?)

Work Items

Work items:
Create a TSC card for this blueprint and its subtask because it will be major: TODO
Get OK and priority from TSC before doing further work: TODO

This blueprint contains Public information 
Everyone can see this information.