diff mbox series

[RFC,v2,5/6] drivers: boot_constraint: Add initial DT bindings

Message ID 0610277aef9830cff53b7b53cf41cc54886fdc7f.1499770771.git.viresh.kumar@linaro.org
State New
Headers show
Series drivers: Boot Constraints core | expand

Commit Message

Viresh Kumar July 12, 2017, 6:34 a.m. UTC 
This adds device tree bindings for boot constraints. Only power supply
constraint types are supported currently.

Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>

---
 .../devicetree/bindings/boot-constraints.txt       | 68 ++++++++++++++++++++++
 1 file changed, 68 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/boot-constraints.txt

-- 
2.13.0.71.gd7076ec9c9cb

Comments

Viresh Kumar July 13, 2017, 9:36 a.m. UTC | #1 
On 12-07-17, 16:28, Rob Herring wrote:
> Display is a pretty well known use case here. Do you have other

> examples in mind?


No, I don't.

@Stephen: Do you have more cases like this for your Qcom products ?

> Other cases I've seen are automotive with keeping

> the backup camera going and CAN bus handling. Though my new car has a

> flicker shortly after coming on, so I guess the handoff doesn't have

> to be completely seemless. :)


:)

> [...]

> 

> > +       mmc: mmc@0x0 {

> > +               ...

> > +               ...

> > +               vmmc-supply = <&twl_reg1>;

> > +               vmmcaux-supply = <&twl_reg2>;

> > +               boot-constraint-supplies = "vmmc", "vmmcaux";

> > +               boot-constraint-uV = <1800000 2000000>, /* vmmc */

> > +                                    <2000000 2000000>; /* vmmcaux */

> 

> No. I don't like how this is going to extend to all the other bindings

> people are going to want constraints for. We don't need a parallel set

> of properties for each type of binding.


Fair enough.

> I'm not convinced that we need a general solution for what's probably

> a handful of things that need a handoff versus just re-initialize.


What about keeping the first four patches (mostly) as it is and adding
these constraints from a platform specific constraints driver ?

Will that be acceptable ?

-- 
viresh
Viresh Kumar July 13, 2017, 9:51 a.m. UTC | #2 
On 13-07-17, 17:46, Chen-Yu Tsai wrote:
> This makes more sense. The LCD being able to do DVFS was missing from the last

> discussion. I assume this is for power saving purposes?


Yeah.

> Otherwise one could just

> say you should not use the lower part of the voltage range. And DVFS is for the

> controller's core logic and not I/O?


Yeah.

But for many such cases in different platforms, the LCD controller may
not do DVFS. But we still need to make sure its clk, regulator and
power domain are enabled until the time the driver comes up. This
series would also help in doing proxy-voting for all such resources,
so that they don't get disabled while being used.

-- 
viresh
diff mbox series

Patch

diff --git a/Documentation/devicetree/bindings/boot-constraints.txt b/Documentation/devicetree/bindings/boot-constraints.txt
new file mode 100644
index 000000000000..9a01ea1e6e72
--- /dev/null
+++ b/Documentation/devicetree/bindings/boot-constraints.txt
@@ -0,0 +1,68 @@ 
+BOOT CONSTRAINTS
+================
+
+Some devices are powered ON by the bootloader before the bootloader handovers
+control to the Operating System (OS). It maybe important for those devices to
+keep working until the time the OS takes over and starts configuring the devices
+again.
+
+A typical example of that can be the LCD controller, which is used by the
+bootloaders to show image(s) while the platform is booting into the Operating
+System. The LCD controller can be using some resources, like clk, supplies, etc,
+that are shared between several devices. These shared resources should be
+configured to satisfy need of all the users. If another device's (X) driver gets
+probed before the LCD controller driver in this case, then it may end up
+reconfiguring these resources to ranges satisfying the current users (only
+device X) and that can make the LCD screen unstable.
+
+This document describes the binding used to specify such boot constraints to the
+OS.
+
+Power Supply Constraints:
+-------------------------
+
+This describes the binding of constraints for the power supply resources. These
+must be present directly in the consumer device's node.
+
+Required properties:
+- boot-constraint-supplies:
+
+  This contains an array of (one or more) strings, each of which must match with
+  the <name> of a corresponding <name>-supply property in the same device node.
+  This is required for the OS to know about the power supplies that are
+  configured (and enabled) by the bootloader for the consumer device.
+
+  It is assumed that the power supply is already enabled by the bootloader.
+
+- boot-constraint-uV:
+
+  This contains an array of {min max} microvolt tuples for the power supplies in
+  the same order in which they are present in "boot-constraint-supplies"
+  property. Here, min is the smallest and max is the largest voltage that the
+  consumer (corresponding to the device node where this property is present) may
+  set.
+
+Example of a consumer device node (mmc) referencing two regulators and setting
+their boot constraints (twl_reg1 and twl_reg2):
+
+	twl_reg1: regulator@0 {
+		...
+		...
+		...
+	};
+
+	twl_reg2: regulator@1 {
+		...
+		...
+		...
+	};
+
+	mmc: mmc@0x0 {
+		...
+		...
+		vmmc-supply = <&twl_reg1>;
+		vmmcaux-supply = <&twl_reg2>;
+		boot-constraint-supplies = "vmmc", "vmmcaux";
+		boot-constraint-uV = <1800000 2000000>, /* vmmc */
+				     <2000000 2000000>; /* vmmcaux */
+	};