On Wed, Aug 12, 2020 at 10:58:48AM +0200, Linus Walleij wrote:
Let's use a common.yaml include for the backlight like we do with the LEDs. The LEDs are inherently incompatible so their bindings cannot be reused for backlight.
Cc: devicetree@vger.kernel.org Suggested-by: Sam Ravnborg sam@ravnborg.org Signed-off-by: Linus Walleij linus.walleij@linaro.org
ChangeLog v1->v2:
- New patch as suggested by Sam.
.../bindings/leds/backlight/common.yaml | 42 +++++++++++++++++++ 1 file changed, 42 insertions(+) create mode 100644 Documentation/devicetree/bindings/leds/backlight/common.yaml
diff --git a/Documentation/devicetree/bindings/leds/backlight/common.yaml b/Documentation/devicetree/bindings/leds/backlight/common.yaml new file mode 100644 index 000000000000..8ae7e3818b0d --- /dev/null +++ b/Documentation/devicetree/bindings/leds/backlight/common.yaml @@ -0,0 +1,42 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/leds/backlight/common.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml#
+title: Common backlight properties
+maintainers:
- Lee Jones lee.jones@linaro.org
- Daniel Thompson daniel.thompson@linaro.org
- Jingoo Han jingoohan1@gmail.com
+description: |
- Backlight devices provide backlight for different types of graphical
- displays. They are typically but not necessarilt implemented using a white
- LED powered by a boost converter.
+properties:
- default-on:
- description:
The initial state of the backlight can be set to be on with thisproperty. This is a state applied by the operating system so that thebacklight is always turned on at boot.
Is default-on really a common property? I would describe it as legacy that emerged when we added the gpio bindings and didn't spell default-brightness correctly!
Currently I think this is only implemented for GPIO and it is simply not needed for most hardware. More specifically, for hardware that is capable of flicker-free handover (bootloader -> kernel) by examining the hardware state at handover then we don't want a DT property. It is duplicative and can only result in bad handovers.
Daniel.