[PM] 25/08/10 - Minutes for the Power Management WG weekly call

Sundar sunder.svit at gmail.com
Mon Sep 6 20:16:12 BST 2010

Hi Amit,

Thanx for the generous response :)

On Mon, Sep 6, 2010 at 12:58 PM, Amit Kucheria <amit.kucheria at linaro.org> wrote:
> The currently proposed bindings are documented on the DeviceTree wiki[1].
> Please understand that these are Device tree bindings, and it seems that we

Okay. This seems more like moving out the current platform regulator
bindings to the dtb.
Please correct me if I am wrong.

> might not need a new framework to track power domains since a lot of the work
> is already handled by the regulator framework.

Just to be sure, by a power domain, I refer to the domain on a SoC or
a CPU. The bindings
which I see here are basically regulators on the board. But on most
ARM SoCs available like
OMAP, U8500, different peripherals are grouped into different power
domains aka "SoC regulators".

I had a discussion with the regulator maintainers some time ago at

Based on the discussion, it felt that the current regulator framework
cannot be moderated upon
a the SoC power domain types. and hence my curiousity.

> What are your interests?

The above thread holds most of the discussion that we had. My idea is like

- a generic framework that allows modelling of SoC power domains,
hoping to integrate both clocks and regulators.
There are platforms that dont implement DVS, hence a clock approach
makes sense; A DVS only platfom has it easier to implement via
regulators and so on.

- able to manage dependencies on power domains in terms of constraints
from children to parent domains, ability to manage independent power
state transitions via specific SoC configurations

Also, I am curious about few PM techniques that IMO can be exploited
like Run time OPP management for peripherals based on use cases; like
Hw accelerators that may run at half the voltage/clocking for reduced
loads; storage devices running at reduced loads when the overall QoS
parameters may signify a power-save mode vs performance mode etc.

Please do let me know of your views on the above.


More information about the Linaro-dev mailing list