On Sun, Nov 11, 2012 at 2:16 PM, Shiraz Hashim shiraz.linux.kernel@gmail.com wrote:

On Sun, Nov 11, 2012 at 2:02 AM, Linus Walleij linus.walleij@linaro.org wrote:

...

• At Connect Kevin Hilman from TI kindly took time to explain to me and Ulf how runtime PM is to be done right. So what needs to be done is major and will require commitment from Linaro member companies, and I've filed a blueprint for it. https://blueprints.launchpad.net/linux-linaro/+spec/runtime-pm Amit K is informed.

I went through the blue print but couldn't get complete picture. Do you say that runtime pm should only be modelled around power domains.

I'm connecting Kevin Hilman to this discussion since it's mainly takeaways from his session.

The basic paradigm of the people who invented runtime PM (Kevin, 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.

From blueprint,

(i,e. for new readers:) https://blueprints.launchpad.net/linux-linaro/+spec/runtime-pm

...

Instead of using runtime PM and 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.

Can you please explain this little more. There were patches from Ulf targetting some cleanup in pl022 spi runtime pm implementation (mainly around clk usage) and then he suggested it to be carried in amba bus (as pclk is handled there).

This is for Ulf to answer but basically the AMBA (PrimeCell) bus is a special case since it supports autodetection, so it needs to read some special registers before the driver is even probed, and thus the voltage domain and silicon block clock needs to be on before the device driver is even probed.

So it is impossible to handle the block clock inside the drivers themselves.

Assuming the above paradigm, this clock handling should actually be moved to the PM domains and handled there since it is SoC-specific.

What is the correct approach to handle runtime PM.

This depends on who you ask. The concepts and mechanisms are well described in Documentation/power/runtime_pm.txt but how it is to be deployed is a different question,

The problem right now is that since there is not one entity driving this across subsystems and since there is no "police", different approaches are being done.

The blueprint is about setting a standard for how this should be done across all subsystems by doing a good example for a set of SoCs.

Currently it 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.

- 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.

Currently I'm a bit worried that the centralized approach appears to use bus notifiers and thus cannot defer any probes if resources are not ready.

Yours, Linus Walleij

Hi Linus,

On Sun, Nov 11, 2012 at 11:16 PM, Linus Walleij linus.walleij@linaro.org wrote:

The blueprint is about setting a standard for how this should be done across all subsystems by doing a good example for a set of SoCs.

Currently it 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.

• 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.

Currently I'm a bit worried that the centralized approach appears to use bus notifiers and thus cannot defer any probes if resources are not ready.

Thanks for explaining. It is lot more clear now. I would also go through link provided by you.