Thread (1 message) 1 message, 1 author, 2014-11-13

[PATCH v10 2/3] power-domain: rockchip: add power doamin driver

From: khilman@kernel.org (Kevin Hilman)
Date: 2014-11-13 20:24:53
Also in: linux-devicetree, lkml

Heiko St?bner [off-list ref] writes:
Am Dienstag, 11. November 2014, 08:53:13 schrieb Kevin Hilman:
quoted
Caesar Wang [off-list ref] writes:
quoted
In order to meet high performance and low power requirements, a power
management unit is designed or saving power when RK3288 in low power mode.
The RK3288 PMU is dedicated for managing the power ot the whole chip.

Signed-off-by: Jack Dai <redacted>
Signed-off-by: jinkun.hong <redacted>
Signed-off-by: Caesar Wang <redacted>

---

Changes in v10:
    - this switches over domain infos to use masks instead of recomputing
    
      them each time and also gets rid of custom domain translator and
      uses standard onecell on.

Changes in v9:
    - fix v8 changes as follows:
    - This reconciles the v2 and v7 code so that we power domain have
    
      lists of clocks they toggle on and off during power transitions and
      independently from power domains clocks we attach clocks to devices
      comprising power domain and prepare them so they are turn on and off
      by runtime PM.
I still don't like having lists of clocks in the power-domain DT.

DT is supposed to describe the hardware, and clocks are properties of
devices, not power-domains, so the DT description should follow from that.
on the policy side one could argue that if the clock needs to be enabled to 
achieve sucessful domain state-changes, that it is also a property of the 
domain itself in addition to the device.
You could, but from a hardware perspective, the clock is a property of
the device.
And on the pratical side we don't have drivers nor bindings for a big part of 
the domain users - and this will probably be true for quite some time. This of 
course makes it very impractical (or impossible) to collect the clocks for 
parts like the gpu (mali), hevc, vcodec (video encoder/decoder), rga (2d 
stuff), iep, isp.
This doesn't sound impossible at all.

You have to collect the clocks anyways.  The only debate is whether to
list them in the device node or the power-domain node.  

Even for devices without drivers, you just need a minimal node in the DT if
which lists the clocks and has a phandle to the parent power domain.

Sounds rather simple to me, and since the DT is supposed to describe the
hardware, doing it this way makes looking at the DT actually help
understand the hardware.

Kevin
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help