On Mon, Jul 08, 2019 at 12:26:59PM +0200, Jean-Jacques Hiblot wrote: > Add DT binding for led-backlight. > > Signed-off-by: Jean-Jacques Hiblot <jjhiblot@xxxxxx> > --- > .../bindings/leds/backlight/led-backlight.txt | 29 +++++++++++++++++++ > 1 file changed, 29 insertions(+) > create mode 100644 Documentation/devicetree/bindings/leds/backlight/led-backlight.txt > > diff --git a/Documentation/devicetree/bindings/leds/backlight/led-backlight.txt b/Documentation/devicetree/bindings/leds/backlight/led-backlight.txt > new file mode 100644 > index 000000000000..4f545316b288 > --- /dev/null > +++ b/Documentation/devicetree/bindings/leds/backlight/led-backlight.txt > @@ -0,0 +1,29 @@ > +led-backlight bindings > + > +This binding is used to describe a basic backlight device made of LEDs. > +It can also be used to describe a backlight device controlled by the output of > +a LED driver. > + > +Required properties: > + - compatible: "led-backlight" > + - leds: a list of LEDs > + > +Optional properties: > + - brightness-levels: Array of distinct brightness levels. These > + are in the range from 0 to 255. The actual brightness > + level programmed in each LED will be adjusted based on > + its maximum brightness: > + led brightness = (level * maximum brightness) / 255 8-bits is a narrow range and likely to make animated backlight effects impossible because the stepping artefacts would be too obvious. I'd rather see the brightness-levels table expressed in the native steps of the LEDs in the leds list. I know this means that the LEDs must have identical ranges but I think it is OK. A backlight design whose LEDs are connected to non-identical drivers is either badly broken or sufficiently exotic to need to special purpose driver. The driver can therefore fail to probe if the LEDs are mismatched. > + > + - default-brightness-level: The default brightness level (index into the > + array defined by the "brightness-levels" property). The brightness-levels property is optional... this text needs to be updated. Daniel.
