[PATCH v2 2/2] Documentation: devicetree: Add PL310 PM bindings

On Wed, Apr 20, 2016 at 09:04:39AM -0500, Rob Herring wrote:

On Tue, Apr 19, 2016 at 5:41 PM, Russell King - ARM Linux
[off-list ref] wrote:

quoted

On Tue, Apr 19, 2016 at 04:38:14PM -0500, Rob Herring wrote:

quoted

On Mon, Apr 18, 2016 at 4:36 PM, Brad Mouring [off-list ref] wrote:

quoted

Document the DT bindings for controlling ARM PL310 Power Control
settings.

Signed-off-by: Brad Mouring <redacted>

What happened to Josh's ack?

quoted

---
 Documentation/devicetree/bindings/arm/l2c2x0.txt | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/Documentation/devicetree/bindings/arm/l2c2x0.txt b/Documentation/devicetree/bindings/arm/l2c2x0.txt
index fe0398c..c1c756e 100644
--- a/Documentation/devicetree/bindings/arm/l2c2x0.txt
+++ b/Documentation/devicetree/bindings/arm/l2c2x0.txt

@@ -84,6 +84,10 @@ Optional properties:
 - prefetch-instr : Instruction prefetch. Value: <0> (forcibly disable),
   <1> (forcibly enable), property absent (retain settings set by
   firmware)
+- arm,dynamic-clock-gating : L2 dynamic clock gating. Value: <0> (forcibly
+  disable), <1> or property absent (forcibly enable)
+- arm,standby-mode: L2 standby mode enable. Value <0> (forcibly disable),
+  <1>  or property absent (forcibly enable)

What happened to "retain settings set by firmware"?

I said we shouldn't.  Current behaviour is that we enable these features,
and moving to missing-means-retain means that everything today ends up
with these features disabled.  IOW, it's yet another change of actual
behaviour that every platform would see.

Right, but then the properties are different from prefetch-instr and
others IIRC. We're letting the OS define the binding. If BSD doesn't
enable these settings currently, then there is a mismatch between the
binding and actual behavior. Saying "retain firmware settings" also
defines specific OS behavior. I think absent should mean OS is free to
do whatever it wants which could be retain firmware settings, enable
or disable. In other words, it is undefined as this ship has already
sailed.

I agree with "the ship has already sailed" but I disagree with the
rest of your comment.  The ship has already sailed in that we have
an established behaviour which has been there for 18 months.  Given
the time period, it's not something I'm going to change at this
stage, sorry.

Why?  Such a change will go unnoticed, and it's particularly hard
to debug why battery life has reduced.

I guess we need to find a way to ensure that the default behaviour
stays.  Whether that's by _everyone_ updating their DT files with
the new properties or some other way, I don't care.  I only care
that we retain the behaviour we've had for the last 18 months.

-- 
RMK's Patch system: http://www.arm.linux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.