Runtime PM deployment for ARM systems

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