Re: [PATCH v26 04/15] dt: bindings: lp50xx: Introduce the lp50xx family of RGB drivers

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Rob

On 6/4/20 5:59 PM, Rob Herring wrote:
On Thu, Jun 04, 2020 at 07:04:53AM -0500, Dan Murphy wrote:
Introduce the bindings for the Texas Instruments LP5036, LP5030, LP5024,
LP5018, LP5012 and LP5009 RGB LED device driver.  The LP5036/30/24/18/12/9
can control RGB LEDs individually or as part of a control bank group.
These devices have the ability to adjust the mixing control for the RGB
LEDs to obtain different colors independent of the overall brightness of
the LED grouping.

Datasheet:
http://www.ti.com/lit/ds/symlink/lp5012.pdf
http://www.ti.com/lit/ds/symlink/lp5024.pdf
http://www.ti.com/lit/ds/symlink/lp5036.pdf

Acked-by: Jacek Anaszewski <jacek.anaszewski@xxxxxxxxx>
Signed-off-by: Dan Murphy <dmurphy@xxxxxx>
---
  .../devicetree/bindings/leds/leds-lp50xx.yaml | 136 ++++++++++++++++++
  1 file changed, 136 insertions(+)
  create mode 100644 Documentation/devicetree/bindings/leds/leds-lp50xx.yaml

diff --git a/Documentation/devicetree/bindings/leds/leds-lp50xx.yaml b/Documentation/devicetree/bindings/leds/leds-lp50xx.yaml
new file mode 100644
index 000000000000..02fcdc13262f
--- /dev/null
+++ b/Documentation/devicetree/bindings/leds/leds-lp50xx.yaml
@@ -0,0 +1,136 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/leds/leds-lp50xx.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: LED driver for LP50XX RGB LED from Texas Instruments.
+
+maintainers:
+  - Dan Murphy <dmurphy@xxxxxx>
+
+description: |
+  The LP50XX is multi-channel, I2C RGB LED Drivers that can group RGB LEDs into
+  a LED group or control them individually.
+
+  The difference in these RGB LED drivers is the number of supported RGB
+  modules.
+
+  For more product information please see the link below:
+  http://www.ti.com/lit/ds/symlink/lp5012.pdf
+  http://www.ti.com/lit/ds/symlink/lp5024.pdf
+  http://www.ti.com/lit/ds/symlink/lp5036.pdf
+
+properties:
+  #allOf:
+    #- $ref: "common.yaml#"
+    #- $ref: "leds-class-multicolor.yaml#"
These describe properties in the 'multi-led' nodes, so the $ref goes
there. And you only need the 2nd one because it already references the
1st one (or it should once you fix patch 1).
Got it
+
+  compatible:
+    enum:
+      - ti,lp5009
+      - ti,lp5012
+      - ti,lp5018
+      - ti,lp5024
+      - ti,lp5030
+      - ti,lp5036
+
+  reg:
+    maxItems: 1
+    description:
+      I2C slave address
+      lp5009/12 - 0x14, 0x15, 0x16, 0x17
+      lp5018/24 - 0x28, 0x29, 0x2a, 0x2b
+      lp5030/36 - 0x30, 0x31, 0x32, 0x33
+
+  enable-gpios:
+    maxItems: 1
+    description: GPIO pin to enable/disable the device.
+
+  vled-supply:
+    description: LED supply.
+
+  child-node:
I guess you didn't understand what I said on this. What you need is:

patternProperties:
   '^multi-led@[0-9]$':
     type: object
     $ref: leds-class-multicolor.yaml#
     properties:
       ...

     patternProperties:
       '^led@[0-9]$':
         type: object
         $ref: common.yaml#

Adjust '[0-9]' based on how many possible child addresses there can be.
It's hex if more than 10.

Most we can have are 12 modules
+    properties:
+      ti,led-bank:
+        description:
+          This property denotes the LED module numbers that will be controlled as
+          a single RGB cluster.  Each LED module number will be controlled by a
+          single LED class instance.
+          There can only be one instance of the ti,led-bank
+          property for each device node.  This is a required node if the LED
+          modules are to be banked.
+        $ref: /schemas/types.yaml#definitions/uint32-array
+
+required:
+  - compatible
+  - reg
additionalProperties: false

This causes a binding check failure for

leds/leds-lp50xx.example.dt.yaml: led-controller@14: '#address-cells', '#size-cells' do not match any of the regexes: '^multi-led@[0-9a-f]$', 'pinctrl-[0-9]+'

+
+examples:
+  - |
+   #include <dt-bindings/gpio/gpio.h>
+   #include <dt-bindings/leds/common.h>
+
+   i2c {
+       #address-cells = <1>;
+       #size-cells = <0>;
+
+       led-controller@14 {
+           compatible = "ti,lp5009";
+           reg = <0x14>;
+           #address-cells = <1>;
+           #size-cells = <0>;
+           enable-gpios = <&gpio1 16>;
+
+           multi-led@1 {
+               #address-cells = <1>;
+               #size-cells = <0>;
+               reg = <1>;
+               color = <LED_COLOR_ID_MULTI>;
+               function = LED_FUNCTION_CHARGING;
+
+               led@0 {
+                   reg = <0>;
+                   color = <LED_COLOR_ID_RED>;
+               };
+
+               led@1 {
+                   reg = <1>;
+                   color = <LED_COLOR_ID_GREEN>;
+               };
+
+               led@2 {
+                   reg = <2>;
+                   color = <LED_COLOR_ID_BLUE>;
+               };
+          };
+
+          multi-led@2 {
+            #address-cells = <1>;
+            #size-cells = <0>;
+            reg = <2>;
+            color = <LED_COLOR_ID_MULTI>;
+            function = LED_FUNCTION_STANDBY;
+            ti,led-bank = <2 3 5>;
I still don't understand why 'reg = <2 3 5>;' with the 1st entry being
the control bank. Is '2' in reg not the same thing as '2' here?

I changed this.

Now reg is the module numbers that can either stand alone or be grouped.

Dan




[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Security]     [Bugtraq]     [Linux OMAP]     [Linux MIPS]     [ECOS]     [Asterisk Internet PBX]     [Linux API]

  Powered by Linux