* [PATCH v32 0/6] Multicolor Framework v32
@ 2020-07-22 15:31 Dan Murphy
2020-07-22 15:31 ` [PATCH v32 1/6] dt: bindings: lp50xx: Introduce the lp50xx family of RGB drivers Dan Murphy
` (5 more replies)
0 siblings, 6 replies; 23+ messages in thread
From: Dan Murphy @ 2020-07-22 15:31 UTC (permalink / raw)
To: jacek.anaszewski, pavel, robh, marek.behun
Cc: devicetree, linux-leds, linux-kernel, linux-arm-kernel, Dan Murphy
Hello
This is the remaining patches in the multicolor framework series. Only the
LP50xx driver has been updated per the review comment here
https://lore.kernel.org/patchwork/patch/1274070/
In addition to these fixes fixes for the enable/disable and reset functions have
also been updated.
Summary:
Converted links from http->https
Fixed comment style
Fixed enable/disable function
Refactored probe_dt code
Fixed checkpatch style issues
Fixed issues when building with W=1 C=1
Dan Murphy (6):
dt: bindings: lp50xx: Introduce the lp50xx family of RGB drivers
leds: lp50xx: Add the LP50XX family of the RGB LED driver
ARM: defconfig: u8500: Add LP55XX_COMMON config flag
ARM: dts: n900: Add reg property to the LP5523 channel node
ARM: dts: imx6dl-yapp4: Add reg property to the lp5562 channel node
ARM: dts: ste-href: Add reg property to the LP5521 channel nodes
.../devicetree/bindings/leds/leds-lp50xx.yaml | 130 +++
arch/arm/boot/dts/imx6dl-yapp4-common.dtsi | 14 +-
arch/arm/boot/dts/omap3-n900.dts | 29 +-
arch/arm/boot/dts/ste-href.dtsi | 22 +-
arch/arm/configs/u8500_defconfig | 1 +
drivers/leds/Kconfig | 11 +
drivers/leds/Makefile | 1 +
drivers/leds/leds-lp50xx.c | 791 ++++++++++++++++++
8 files changed, 980 insertions(+), 19 deletions(-)
create mode 100644 Documentation/devicetree/bindings/leds/leds-lp50xx.yaml
create mode 100644 drivers/leds/leds-lp50xx.c
--
2.27.0
^ permalink raw reply [flat|nested] 23+ messages in thread* [PATCH v32 1/6] dt: bindings: lp50xx: Introduce the lp50xx family of RGB drivers 2020-07-22 15:31 [PATCH v32 0/6] Multicolor Framework v32 Dan Murphy @ 2020-07-22 15:31 ` Dan Murphy 2020-07-28 13:39 ` Dan Murphy 2020-08-11 10:20 ` Pavel Machek 2020-07-22 15:31 ` [PATCH v32 2/6] leds: lp50xx: Add the LP50XX family of the RGB LED driver Dan Murphy ` (4 subsequent siblings) 5 siblings, 2 replies; 23+ messages in thread From: Dan Murphy @ 2020-07-22 15:31 UTC (permalink / raw) To: jacek.anaszewski, pavel, robh, marek.behun Cc: devicetree, linux-leds, linux-kernel, linux-arm-kernel, Dan Murphy 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 Reviewed-by: Rob Herring <robh@kernel.org> Acked-by: Jacek Anaszewski <jacek.anaszewski@gmail.com> Signed-off-by: Dan Murphy <dmurphy@ti.com> --- .../devicetree/bindings/leds/leds-lp50xx.yaml | 130 ++++++++++++++++++ 1 file changed, 130 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..b2dd1672f12a --- /dev/null +++ b/Documentation/devicetree/bindings/leds/leds-lp50xx.yaml @@ -0,0 +1,130 @@ +# 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@ti.com> + +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: + https://www.ti.com/lit/ds/symlink/lp5012.pdf + https://www.ti.com/lit/ds/symlink/lp5024.pdf + https://www.ti.com/lit/ds/symlink/lp5036.pdf + +properties: + 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. + +patternProperties: + '^multi-led@[0-9a-f]$': + type: object + allOf: + - $ref: leds-class-multicolor.yaml# + properties: + reg: + minItems: 1 + maxItems: 12 + description: + This property denotes the LED module number(s) that is used on the + for the child node. The LED modules can either be used stand alone + or grouped into a module bank. + + patternProperties: + "(^led-[0-9a-f]$|led)": + type: object + $ref: common.yaml# + +required: + - compatible + - reg + +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 = <0x1>; + color = <LED_COLOR_ID_MULTI>; + function = LED_FUNCTION_CHARGING; + + led-0 { + color = <LED_COLOR_ID_RED>; + }; + + led-1 { + color = <LED_COLOR_ID_GREEN>; + }; + + led-2 { + color = <LED_COLOR_ID_BLUE>; + }; + }; + + multi-led@2 { + #address-cells = <1>; + #size-cells = <2>; + reg = <0x2 0x3 0x5>; + color = <LED_COLOR_ID_MULTI>; + function = LED_FUNCTION_STANDBY; + + led-6 { + color = <LED_COLOR_ID_RED>; + }; + + led-7 { + color = <LED_COLOR_ID_GREEN>; + }; + + led-8 { + color = <LED_COLOR_ID_BLUE>; + }; + }; + }; + }; + +... -- 2.27.0 ^ permalink raw reply related [flat|nested] 23+ messages in thread
* Re: [PATCH v32 1/6] dt: bindings: lp50xx: Introduce the lp50xx family of RGB drivers 2020-07-22 15:31 ` [PATCH v32 1/6] dt: bindings: lp50xx: Introduce the lp50xx family of RGB drivers Dan Murphy @ 2020-07-28 13:39 ` Dan Murphy 2020-08-04 19:55 ` Dan Murphy 2020-08-11 10:20 ` Pavel Machek 1 sibling, 1 reply; 23+ messages in thread From: Dan Murphy @ 2020-07-28 13:39 UTC (permalink / raw) To: jacek.anaszewski, pavel, robh, marek.behun Cc: devicetree, linux-leds, linux-kernel, linux-arm-kernel Pavel On 7/22/20 10:31 AM, 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. Were you going to pull this in as a user of the Multicolor framework? Dan > > 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 > > Reviewed-by: Rob Herring <robh@kernel.org> > Acked-by: Jacek Anaszewski <jacek.anaszewski@gmail.com> > Signed-off-by: Dan Murphy <dmurphy@ti.com> > --- > .../devicetree/bindings/leds/leds-lp50xx.yaml | 130 ++++++++++++++++++ > 1 file changed, 130 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..b2dd1672f12a > --- /dev/null > +++ b/Documentation/devicetree/bindings/leds/leds-lp50xx.yaml > @@ -0,0 +1,130 @@ > +# 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@ti.com> > + > +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: > + https://www.ti.com/lit/ds/symlink/lp5012.pdf > + https://www.ti.com/lit/ds/symlink/lp5024.pdf > + https://www.ti.com/lit/ds/symlink/lp5036.pdf > + > +properties: > + 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. > + > +patternProperties: > + '^multi-led@[0-9a-f]$': > + type: object > + allOf: > + - $ref: leds-class-multicolor.yaml# > + properties: > + reg: > + minItems: 1 > + maxItems: 12 > + description: > + This property denotes the LED module number(s) that is used on the > + for the child node. The LED modules can either be used stand alone > + or grouped into a module bank. > + > + patternProperties: > + "(^led-[0-9a-f]$|led)": > + type: object > + $ref: common.yaml# > + > +required: > + - compatible > + - reg > + > +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 = <0x1>; > + color = <LED_COLOR_ID_MULTI>; > + function = LED_FUNCTION_CHARGING; > + > + led-0 { > + color = <LED_COLOR_ID_RED>; > + }; > + > + led-1 { > + color = <LED_COLOR_ID_GREEN>; > + }; > + > + led-2 { > + color = <LED_COLOR_ID_BLUE>; > + }; > + }; > + > + multi-led@2 { > + #address-cells = <1>; > + #size-cells = <2>; > + reg = <0x2 0x3 0x5>; > + color = <LED_COLOR_ID_MULTI>; > + function = LED_FUNCTION_STANDBY; > + > + led-6 { > + color = <LED_COLOR_ID_RED>; > + }; > + > + led-7 { > + color = <LED_COLOR_ID_GREEN>; > + }; > + > + led-8 { > + color = <LED_COLOR_ID_BLUE>; > + }; > + }; > + }; > + }; > + > +... ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: [PATCH v32 1/6] dt: bindings: lp50xx: Introduce the lp50xx family of RGB drivers 2020-07-28 13:39 ` Dan Murphy @ 2020-08-04 19:55 ` Dan Murphy 2020-08-07 13:42 ` Dan Murphy 0 siblings, 1 reply; 23+ messages in thread From: Dan Murphy @ 2020-08-04 19:55 UTC (permalink / raw) To: jacek.anaszewski, pavel, robh, marek.behun Cc: devicetree, linux-leds, linux-kernel, linux-arm-kernel Pavel On 7/28/20 8:39 AM, Dan Murphy wrote: > Pavel > > On 7/22/20 10:31 AM, 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. > > Were you going to pull this in as a user of the Multicolor framework? > Gentle ping. I saw you were going to push the Omnia these should be ready too > Dan > > >> >> 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 >> >> Reviewed-by: Rob Herring <robh@kernel.org> >> Acked-by: Jacek Anaszewski <jacek.anaszewski@gmail.com> >> Signed-off-by: Dan Murphy <dmurphy@ti.com> >> --- >> .../devicetree/bindings/leds/leds-lp50xx.yaml | 130 ++++++++++++++++++ >> 1 file changed, 130 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..b2dd1672f12a >> --- /dev/null >> +++ b/Documentation/devicetree/bindings/leds/leds-lp50xx.yaml >> @@ -0,0 +1,130 @@ >> +# 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@ti.com> >> + >> +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: >> + https://www.ti.com/lit/ds/symlink/lp5012.pdf >> + https://www.ti.com/lit/ds/symlink/lp5024.pdf >> + https://www.ti.com/lit/ds/symlink/lp5036.pdf >> + >> +properties: >> + 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. >> + >> +patternProperties: >> + '^multi-led@[0-9a-f]$': >> + type: object >> + allOf: >> + - $ref: leds-class-multicolor.yaml# >> + properties: >> + reg: >> + minItems: 1 >> + maxItems: 12 >> + description: >> + This property denotes the LED module number(s) that is >> used on the >> + for the child node. The LED modules can either be used >> stand alone >> + or grouped into a module bank. >> + >> + patternProperties: >> + "(^led-[0-9a-f]$|led)": >> + type: object >> + $ref: common.yaml# >> + >> +required: >> + - compatible >> + - reg >> + >> +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 = <0x1>; >> + color = <LED_COLOR_ID_MULTI>; >> + function = LED_FUNCTION_CHARGING; >> + >> + led-0 { >> + color = <LED_COLOR_ID_RED>; >> + }; >> + >> + led-1 { >> + color = <LED_COLOR_ID_GREEN>; >> + }; >> + >> + led-2 { >> + color = <LED_COLOR_ID_BLUE>; >> + }; >> + }; >> + >> + multi-led@2 { >> + #address-cells = <1>; >> + #size-cells = <2>; >> + reg = <0x2 0x3 0x5>; >> + color = <LED_COLOR_ID_MULTI>; >> + function = LED_FUNCTION_STANDBY; >> + >> + led-6 { >> + color = <LED_COLOR_ID_RED>; >> + }; >> + >> + led-7 { >> + color = <LED_COLOR_ID_GREEN>; >> + }; >> + >> + led-8 { >> + color = <LED_COLOR_ID_BLUE>; >> + }; >> + }; >> + }; >> + }; >> + >> +... ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: [PATCH v32 1/6] dt: bindings: lp50xx: Introduce the lp50xx family of RGB drivers 2020-08-04 19:55 ` Dan Murphy @ 2020-08-07 13:42 ` Dan Murphy 2020-08-11 10:32 ` Pavel Machek 0 siblings, 1 reply; 23+ messages in thread From: Dan Murphy @ 2020-08-07 13:42 UTC (permalink / raw) To: jacek.anaszewski, pavel, robh, marek.behun Cc: devicetree, linux-leds, linux-kernel, linux-arm-kernel Pavel On 8/4/20 2:55 PM, Dan Murphy wrote: > Pavel > > On 7/28/20 8:39 AM, Dan Murphy wrote: >> Pavel >> >> On 7/22/20 10:31 AM, 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. >> >> Were you going to pull this in as a user of the Multicolor framework? >> > Gentle ping. I saw you were going to push the Omnia these should be > ready too > Did you need me to rebase these patches and add the Ack from Linus on the defconfig patch? Dan ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: [PATCH v32 1/6] dt: bindings: lp50xx: Introduce the lp50xx family of RGB drivers 2020-08-07 13:42 ` Dan Murphy @ 2020-08-11 10:32 ` Pavel Machek 0 siblings, 0 replies; 23+ messages in thread From: Pavel Machek @ 2020-08-11 10:32 UTC (permalink / raw) To: Dan Murphy Cc: jacek.anaszewski, robh, marek.behun, devicetree, linux-leds, linux-kernel, linux-arm-kernel [-- Attachment #1: Type: text/plain, Size: 1313 bytes --] On Fri 2020-08-07 08:42:32, Dan Murphy wrote: > Pavel > > On 8/4/20 2:55 PM, Dan Murphy wrote: > > Pavel > > > > On 7/28/20 8:39 AM, Dan Murphy wrote: > > > Pavel > > > > > > On 7/22/20 10:31 AM, 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. > > > > > > Were you going to pull this in as a user of the Multicolor framework? > > > > > Gentle ping. I saw you were going to push the Omnia these should be > > ready too > > > Did you need me to rebase these patches and add the Ack from Linus on the > defconfig patch? The patches look quite close, yes. If you could fix review comments/adds acks... I'm not sure about the defconfig patch, I may not be right person to take it. Best regards, Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 195 bytes --] ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: [PATCH v32 1/6] dt: bindings: lp50xx: Introduce the lp50xx family of RGB drivers 2020-07-22 15:31 ` [PATCH v32 1/6] dt: bindings: lp50xx: Introduce the lp50xx family of RGB drivers Dan Murphy 2020-07-28 13:39 ` Dan Murphy @ 2020-08-11 10:20 ` Pavel Machek 2020-08-11 17:07 ` Dan Murphy 1 sibling, 1 reply; 23+ messages in thread From: Pavel Machek @ 2020-08-11 10:20 UTC (permalink / raw) To: Dan Murphy Cc: jacek.anaszewski, robh, marek.behun, devicetree, linux-leds, linux-kernel, linux-arm-kernel [-- Attachment #1: Type: text/plain, Size: 1307 bytes --] Hi! On Wed 2020-07-22 10:31:41, 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 > > Reviewed-by: Rob Herring <robh@kernel.org> > Acked-by: Jacek Anaszewski <jacek.anaszewski@gmail.com> > Signed-off-by: Dan Murphy <dmurphy@ti.com> Acked-by: Pavel Machek <pavel@ucw.cz> > + multi-led@1 { > + #address-cells = <1>; > + #size-cells = <0>; > + reg = <0x1>; > + color = <LED_COLOR_ID_MULTI>; > + function = LED_FUNCTION_CHARGING; These are just examples, but we should really separate "MULTI" colors and "RGB". Best regards, Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 195 bytes --] ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: [PATCH v32 1/6] dt: bindings: lp50xx: Introduce the lp50xx family of RGB drivers 2020-08-11 10:20 ` Pavel Machek @ 2020-08-11 17:07 ` Dan Murphy 0 siblings, 0 replies; 23+ messages in thread From: Dan Murphy @ 2020-08-11 17:07 UTC (permalink / raw) To: Pavel Machek Cc: jacek.anaszewski, robh, marek.behun, devicetree, linux-leds, linux-kernel, linux-arm-kernel Pavel On 8/11/20 5:20 AM, Pavel Machek wrote: > Hi! > On Wed 2020-07-22 10:31:41, 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 >> >> Reviewed-by: Rob Herring <robh@kernel.org> >> Acked-by: Jacek Anaszewski <jacek.anaszewski@gmail.com> >> Signed-off-by: Dan Murphy <dmurphy@ti.com> > Acked-by: Pavel Machek <pavel@ucw.cz> > >> + multi-led@1 { >> + #address-cells = <1>; >> + #size-cells = <0>; >> + reg = <0x1>; >> + color = <LED_COLOR_ID_MULTI>; >> + function = LED_FUNCTION_CHARGING; > These are just examples, but we should really separate "MULTI" colors > and "RGB". If we do then the LP55xx was not updated when the change was made. I will change it to RGB since I have to touch this file and probably submit the LP55xx patch as well. Dan > Best regards, > Pavel ^ permalink raw reply [flat|nested] 23+ messages in thread
* [PATCH v32 2/6] leds: lp50xx: Add the LP50XX family of the RGB LED driver 2020-07-22 15:31 [PATCH v32 0/6] Multicolor Framework v32 Dan Murphy 2020-07-22 15:31 ` [PATCH v32 1/6] dt: bindings: lp50xx: Introduce the lp50xx family of RGB drivers Dan Murphy @ 2020-07-22 15:31 ` Dan Murphy 2020-08-11 10:29 ` Pavel Machek ` (2 more replies) 2020-07-22 15:31 ` [PATCH v32 3/6] ARM: defconfig: u8500: Add LP55XX_COMMON config flag Dan Murphy ` (3 subsequent siblings) 5 siblings, 3 replies; 23+ messages in thread From: Dan Murphy @ 2020-07-22 15:31 UTC (permalink / raw) To: jacek.anaszewski, pavel, robh, marek.behun Cc: devicetree, linux-leds, linux-kernel, linux-arm-kernel, Dan Murphy Introduce the LP5036/30/24/18/12/9 RGB LED driver. The difference in these parts are the number of LED outputs where the: LP5036 can control 36 LEDs LP5030 can control 30 LEDs LP5024 can control 24 LEDs LP5018 can control 18 LEDs LP5012 can control 12 LEDs LP5009 can control 9 LEDs The device has the ability to group LED outputs into control banks so that multiple LED banks can be controlled with the same mixing and brightness. Or the LED outputs can also be controlled independently. Acked-by: Jacek Anaszewski <jacek.anaszewski@gmail.com> Signed-off-by: Dan Murphy <dmurphy@ti.com> --- drivers/leds/Kconfig | 11 + drivers/leds/Makefile | 1 + drivers/leds/leds-lp50xx.c | 791 +++++++++++++++++++++++++++++++++++++ 3 files changed, 803 insertions(+) create mode 100644 drivers/leds/leds-lp50xx.c diff --git a/drivers/leds/Kconfig b/drivers/leds/Kconfig index b9002850b5fa..c03016f8f09e 100644 --- a/drivers/leds/Kconfig +++ b/drivers/leds/Kconfig @@ -384,6 +384,17 @@ config LEDS_LP3952 To compile this driver as a module, choose M here: the module will be called leds-lp3952. +config LEDS_LP50XX + tristate "LED Support for TI LP5036/30/24/18/12/9 LED driver chip" + depends on LEDS_CLASS && REGMAP_I2C + depends on LEDS_CLASS_MULTICOLOR || !LEDS_CLASS_MULTICOLOR + help + If you say yes here you get support for the Texas Instruments + LP5036, LP5030, LP5024, LP5018, LP5012 and LP5009 LED driver. + + To compile this driver as a module, choose M here: the + module will be called leds-lp50xx. + config LEDS_LP55XX_COMMON tristate "Common Driver for TI/National LP5521/5523/55231/5562/8501" depends on LEDS_CLASS_MULTICOLOR || !LEDS_CLASS_MULTICOLOR diff --git a/drivers/leds/Makefile b/drivers/leds/Makefile index d684bc76d2b2..0231070602a6 100644 --- a/drivers/leds/Makefile +++ b/drivers/leds/Makefile @@ -49,6 +49,7 @@ obj-$(CONFIG_LEDS_LM3697) += leds-lm3697.o obj-$(CONFIG_LEDS_LOCOMO) += leds-locomo.o obj-$(CONFIG_LEDS_LP3944) += leds-lp3944.o obj-$(CONFIG_LEDS_LP3952) += leds-lp3952.o +obj-$(CONFIG_LEDS_LP50XX) += leds-lp50xx.o obj-$(CONFIG_LEDS_LP5521) += leds-lp5521.o obj-$(CONFIG_LEDS_LP5523) += leds-lp5523.o obj-$(CONFIG_LEDS_LP5562) += leds-lp5562.o diff --git a/drivers/leds/leds-lp50xx.c b/drivers/leds/leds-lp50xx.c new file mode 100644 index 000000000000..f4ef9b7f21b2 --- /dev/null +++ b/drivers/leds/leds-lp50xx.c @@ -0,0 +1,791 @@ +// SPDX-License-Identifier: GPL-2.0 +// TI LP50XX LED chip family driver +// Copyright (C) 2018 Texas Instruments Incorporated - https://www.ti.com/ + +#include <linux/gpio/consumer.h> +#include <linux/i2c.h> +#include <linux/init.h> +#include <linux/leds.h> +#include <linux/module.h> +#include <linux/mutex.h> +#include <linux/of.h> +#include <linux/of_gpio.h> +#include <linux/regmap.h> +#include <linux/regulator/consumer.h> +#include <linux/slab.h> +#include <uapi/linux/uleds.h> + +#include <linux/led-class-multicolor.h> + +#include "leds.h" + +#define LP50XX_DEV_CFG0 0x00 +#define LP50XX_DEV_CFG1 0x01 +#define LP50XX_LED_CFG0 0x02 + +/* LP5009 and LP5012 registers */ +#define LP5012_BNK_BRT 0x03 +#define LP5012_BNKA_CLR 0x04 +#define LP5012_BNKB_CLR 0x05 +#define LP5012_BNKC_CLR 0x06 +#define LP5012_LED0_BRT 0x07 +#define LP5012_LED1_BRT 0x08 +#define LP5012_LED2_BRT 0x09 +#define LP5012_LED3_BRT 0x0a +#define LP5012_OUT0_CLR 0x0b +#define LP5012_OUT1_CLR 0x0c +#define LP5012_OUT2_CLR 0x0d +#define LP5012_OUT3_CLR 0x0e +#define LP5012_OUT4_CLR 0x0f +#define LP5012_OUT5_CLR 0x10 +#define LP5012_OUT6_CLR 0x11 +#define LP5012_OUT7_CLR 0x12 +#define LP5012_OUT8_CLR 0x13 +#define LP5012_OUT9_CLR 0x14 +#define LP5012_OUT10_CLR 0x15 +#define LP5012_OUT11_CLR 0x16 +#define LP5012_RESET 0x17 + +/* LP5018 and LP5024 registers */ +#define LP5024_BNK_BRT 0x03 +#define LP5024_BNKA_CLR 0x04 +#define LP5024_BNKB_CLR 0x05 +#define LP5024_BNKC_CLR 0x06 +#define LP5024_LED0_BRT 0x07 +#define LP5024_LED1_BRT 0x08 +#define LP5024_LED2_BRT 0x09 +#define LP5024_LED3_BRT 0x0a +#define LP5024_LED4_BRT 0x0b +#define LP5024_LED5_BRT 0x0c +#define LP5024_LED6_BRT 0x0d +#define LP5024_LED7_BRT 0x0e + +#define LP5024_OUT0_CLR 0x0f +#define LP5024_OUT1_CLR 0x10 +#define LP5024_OUT2_CLR 0x11 +#define LP5024_OUT3_CLR 0x12 +#define LP5024_OUT4_CLR 0x13 +#define LP5024_OUT5_CLR 0x14 +#define LP5024_OUT6_CLR 0x15 +#define LP5024_OUT7_CLR 0x16 +#define LP5024_OUT8_CLR 0x17 +#define LP5024_OUT9_CLR 0x18 +#define LP5024_OUT10_CLR 0x19 +#define LP5024_OUT11_CLR 0x1a +#define LP5024_OUT12_CLR 0x1b +#define LP5024_OUT13_CLR 0x1c +#define LP5024_OUT14_CLR 0x1d +#define LP5024_OUT15_CLR 0x1e +#define LP5024_OUT16_CLR 0x1f +#define LP5024_OUT17_CLR 0x20 +#define LP5024_OUT18_CLR 0x21 +#define LP5024_OUT19_CLR 0x22 +#define LP5024_OUT20_CLR 0x23 +#define LP5024_OUT21_CLR 0x24 +#define LP5024_OUT22_CLR 0x25 +#define LP5024_OUT23_CLR 0x26 +#define LP5024_RESET 0x27 + +/* LP5030 and LP5036 registers */ +#define LP5036_LED_CFG1 0x03 +#define LP5036_BNK_BRT 0x04 +#define LP5036_BNKA_CLR 0x05 +#define LP5036_BNKB_CLR 0x06 +#define LP5036_BNKC_CLR 0x07 +#define LP5036_LED0_BRT 0x08 +#define LP5036_LED1_BRT 0x09 +#define LP5036_LED2_BRT 0x0a +#define LP5036_LED3_BRT 0x0b +#define LP5036_LED4_BRT 0x0c +#define LP5036_LED5_BRT 0x0d +#define LP5036_LED6_BRT 0x0e +#define LP5036_LED7_BRT 0x0f +#define LP5036_LED8_BRT 0x10 +#define LP5036_LED9_BRT 0x11 +#define LP5036_LED10_BRT 0x12 +#define LP5036_LED11_BRT 0x13 + +#define LP5036_OUT0_CLR 0x14 +#define LP5036_OUT1_CLR 0x15 +#define LP5036_OUT2_CLR 0x16 +#define LP5036_OUT3_CLR 0x17 +#define LP5036_OUT4_CLR 0x18 +#define LP5036_OUT5_CLR 0x19 +#define LP5036_OUT6_CLR 0x1a +#define LP5036_OUT7_CLR 0x1b +#define LP5036_OUT8_CLR 0x1c +#define LP5036_OUT9_CLR 0x1d +#define LP5036_OUT10_CLR 0x1e +#define LP5036_OUT11_CLR 0x1f +#define LP5036_OUT12_CLR 0x20 +#define LP5036_OUT13_CLR 0x21 +#define LP5036_OUT14_CLR 0x22 +#define LP5036_OUT15_CLR 0x23 +#define LP5036_OUT16_CLR 0x24 +#define LP5036_OUT17_CLR 0x25 +#define LP5036_OUT18_CLR 0x26 +#define LP5036_OUT19_CLR 0x27 +#define LP5036_OUT20_CLR 0x28 +#define LP5036_OUT21_CLR 0x29 +#define LP5036_OUT22_CLR 0x2a +#define LP5036_OUT23_CLR 0x2b +#define LP5036_OUT24_CLR 0x2c +#define LP5036_OUT25_CLR 0x2d +#define LP5036_OUT26_CLR 0x2e +#define LP5036_OUT27_CLR 0x2f +#define LP5036_OUT28_CLR 0x30 +#define LP5036_OUT29_CLR 0x31 +#define LP5036_OUT30_CLR 0x32 +#define LP5036_OUT31_CLR 0x33 +#define LP5036_OUT32_CLR 0x34 +#define LP5036_OUT33_CLR 0x35 +#define LP5036_OUT34_CLR 0x36 +#define LP5036_OUT35_CLR 0x37 +#define LP5036_RESET 0x38 + +#define LP50XX_SW_RESET 0xff +#define LP50XX_CHIP_EN BIT(6) + +/* There are 3 LED outputs per bank */ +#define LP50XX_LEDS_PER_MODULE 3 + +#define LP5009_MAX_LED_MODULES 2 +#define LP5012_MAX_LED_MODULES 4 +#define LP5018_MAX_LED_MODULES 6 +#define LP5024_MAX_LED_MODULES 8 +#define LP5030_MAX_LED_MODULES 10 +#define LP5036_MAX_LED_MODULES 12 + +#define LP5009_MAX_LEDS (LP5009_MAX_LED_MODULES * LP50XX_LEDS_PER_MODULE) +#define LP5012_MAX_LEDS (LP5012_MAX_LED_MODULES * LP50XX_LEDS_PER_MODULE) +#define LP5018_MAX_LEDS (LP5018_MAX_LED_MODULES * LP50XX_LEDS_PER_MODULE) +#define LP5024_MAX_LEDS (LP5024_MAX_LED_MODULES * LP50XX_LEDS_PER_MODULE) +#define LP5030_MAX_LEDS (LP5030_MAX_LED_MODULES * LP50XX_LEDS_PER_MODULE) +#define LP5036_MAX_LEDS (LP5036_MAX_LED_MODULES * LP50XX_LEDS_PER_MODULE) + +static const struct reg_default lp5012_reg_defs[] = { + {LP50XX_DEV_CFG0, 0x0}, + {LP50XX_DEV_CFG1, 0x3c}, + {LP50XX_LED_CFG0, 0x0}, + {LP5012_BNK_BRT, 0xff}, + {LP5012_BNKA_CLR, 0x0f}, + {LP5012_BNKB_CLR, 0x0f}, + {LP5012_BNKC_CLR, 0x0f}, + {LP5012_LED0_BRT, 0x0f}, + {LP5012_LED1_BRT, 0xff}, + {LP5012_LED2_BRT, 0xff}, + {LP5012_LED3_BRT, 0xff}, + {LP5012_OUT0_CLR, 0x0f}, + {LP5012_OUT1_CLR, 0x00}, + {LP5012_OUT2_CLR, 0x00}, + {LP5012_OUT3_CLR, 0x00}, + {LP5012_OUT4_CLR, 0x00}, + {LP5012_OUT5_CLR, 0x00}, + {LP5012_OUT6_CLR, 0x00}, + {LP5012_OUT7_CLR, 0x00}, + {LP5012_OUT8_CLR, 0x00}, + {LP5012_OUT9_CLR, 0x00}, + {LP5012_OUT10_CLR, 0x00}, + {LP5012_OUT11_CLR, 0x00}, + {LP5012_RESET, 0x00} +}; + +static const struct reg_default lp5024_reg_defs[] = { + {LP50XX_DEV_CFG0, 0x0}, + {LP50XX_DEV_CFG1, 0x3c}, + {LP50XX_LED_CFG0, 0x0}, + {LP5024_BNK_BRT, 0xff}, + {LP5024_BNKA_CLR, 0x0f}, + {LP5024_BNKB_CLR, 0x0f}, + {LP5024_BNKC_CLR, 0x0f}, + {LP5024_LED0_BRT, 0x0f}, + {LP5024_LED1_BRT, 0xff}, + {LP5024_LED2_BRT, 0xff}, + {LP5024_LED3_BRT, 0xff}, + {LP5024_LED4_BRT, 0xff}, + {LP5024_LED5_BRT, 0xff}, + {LP5024_LED6_BRT, 0xff}, + {LP5024_LED7_BRT, 0xff}, + {LP5024_OUT0_CLR, 0x0f}, + {LP5024_OUT1_CLR, 0x00}, + {LP5024_OUT2_CLR, 0x00}, + {LP5024_OUT3_CLR, 0x00}, + {LP5024_OUT4_CLR, 0x00}, + {LP5024_OUT5_CLR, 0x00}, + {LP5024_OUT6_CLR, 0x00}, + {LP5024_OUT7_CLR, 0x00}, + {LP5024_OUT8_CLR, 0x00}, + {LP5024_OUT9_CLR, 0x00}, + {LP5024_OUT10_CLR, 0x00}, + {LP5024_OUT11_CLR, 0x00}, + {LP5024_OUT12_CLR, 0x00}, + {LP5024_OUT13_CLR, 0x00}, + {LP5024_OUT14_CLR, 0x00}, + {LP5024_OUT15_CLR, 0x00}, + {LP5024_OUT16_CLR, 0x00}, + {LP5024_OUT17_CLR, 0x00}, + {LP5024_OUT18_CLR, 0x00}, + {LP5024_OUT19_CLR, 0x00}, + {LP5024_OUT20_CLR, 0x00}, + {LP5024_OUT21_CLR, 0x00}, + {LP5024_OUT22_CLR, 0x00}, + {LP5024_OUT23_CLR, 0x00}, + {LP5024_RESET, 0x00} +}; + +static const struct reg_default lp5036_reg_defs[] = { + {LP50XX_DEV_CFG0, 0x0}, + {LP50XX_DEV_CFG1, 0x3c}, + {LP50XX_LED_CFG0, 0x0}, + {LP5036_LED_CFG1, 0x0}, + {LP5036_BNK_BRT, 0xff}, + {LP5036_BNKA_CLR, 0x0f}, + {LP5036_BNKB_CLR, 0x0f}, + {LP5036_BNKC_CLR, 0x0f}, + {LP5036_LED0_BRT, 0x0f}, + {LP5036_LED1_BRT, 0xff}, + {LP5036_LED2_BRT, 0xff}, + {LP5036_LED3_BRT, 0xff}, + {LP5036_LED4_BRT, 0xff}, + {LP5036_LED5_BRT, 0xff}, + {LP5036_LED6_BRT, 0xff}, + {LP5036_LED7_BRT, 0xff}, + {LP5036_OUT0_CLR, 0x0f}, + {LP5036_OUT1_CLR, 0x00}, + {LP5036_OUT2_CLR, 0x00}, + {LP5036_OUT3_CLR, 0x00}, + {LP5036_OUT4_CLR, 0x00}, + {LP5036_OUT5_CLR, 0x00}, + {LP5036_OUT6_CLR, 0x00}, + {LP5036_OUT7_CLR, 0x00}, + {LP5036_OUT8_CLR, 0x00}, + {LP5036_OUT9_CLR, 0x00}, + {LP5036_OUT10_CLR, 0x00}, + {LP5036_OUT11_CLR, 0x00}, + {LP5036_OUT12_CLR, 0x00}, + {LP5036_OUT13_CLR, 0x00}, + {LP5036_OUT14_CLR, 0x00}, + {LP5036_OUT15_CLR, 0x00}, + {LP5036_OUT16_CLR, 0x00}, + {LP5036_OUT17_CLR, 0x00}, + {LP5036_OUT18_CLR, 0x00}, + {LP5036_OUT19_CLR, 0x00}, + {LP5036_OUT20_CLR, 0x00}, + {LP5036_OUT21_CLR, 0x00}, + {LP5036_OUT22_CLR, 0x00}, + {LP5036_OUT23_CLR, 0x00}, + {LP5036_OUT24_CLR, 0x00}, + {LP5036_OUT25_CLR, 0x00}, + {LP5036_OUT26_CLR, 0x00}, + {LP5036_OUT27_CLR, 0x00}, + {LP5036_OUT28_CLR, 0x00}, + {LP5036_OUT29_CLR, 0x00}, + {LP5036_OUT30_CLR, 0x00}, + {LP5036_OUT31_CLR, 0x00}, + {LP5036_OUT32_CLR, 0x00}, + {LP5036_OUT33_CLR, 0x00}, + {LP5036_OUT34_CLR, 0x00}, + {LP5036_OUT35_CLR, 0x00}, + {LP5036_RESET, 0x00} +}; + +static const struct regmap_config lp5012_regmap_config = { + .reg_bits = 8, + .val_bits = 8, + + .max_register = LP5012_RESET, + .reg_defaults = lp5012_reg_defs, + .num_reg_defaults = ARRAY_SIZE(lp5012_reg_defs), + .cache_type = REGCACHE_RBTREE, +}; + +static const struct regmap_config lp5024_regmap_config = { + .reg_bits = 8, + .val_bits = 8, + + .max_register = LP5024_RESET, + .reg_defaults = lp5024_reg_defs, + .num_reg_defaults = ARRAY_SIZE(lp5024_reg_defs), + .cache_type = REGCACHE_RBTREE, +}; + +static const struct regmap_config lp5036_regmap_config = { + .reg_bits = 8, + .val_bits = 8, + + .max_register = LP5036_RESET, + .reg_defaults = lp5036_reg_defs, + .num_reg_defaults = ARRAY_SIZE(lp5036_reg_defs), + .cache_type = REGCACHE_RBTREE, +}; + +enum lp50xx_model { + LP5009, + LP5012, + LP5018, + LP5024, + LP5030, + LP5036, +}; + +/** + * struct lp50xx_chip_info - + * @lp50xx_regmap_config: regmap register configuration + * @model_id: LED device model + * @max_modules: total number of supported LED modules + * @num_leds: number of LED outputs available on the device + * @led_brightness0_reg: first brightness register of the device + * @mix_out0_reg: first color mix register of the device + * @bank_brt_reg: bank brightness register + * @bank_mix_reg: color mix register + * @reset_reg: device reset register + */ +struct lp50xx_chip_info { + const struct regmap_config *lp50xx_regmap_config; + int model_id; + u8 max_modules; + u8 num_leds; + u8 led_brightness0_reg; + u8 mix_out0_reg; + u8 bank_brt_reg; + u8 bank_mix_reg; + u8 reset_reg; +}; + +static const struct lp50xx_chip_info lp50xx_chip_info_tbl[] = { + [LP5009] = { + .model_id = LP5009, + .max_modules = LP5009_MAX_LED_MODULES, + .num_leds = LP5009_MAX_LEDS, + .led_brightness0_reg = LP5012_LED0_BRT, + .mix_out0_reg = LP5012_OUT0_CLR, + .bank_brt_reg = LP5012_BNK_BRT, + .bank_mix_reg = LP5012_BNKA_CLR, + .reset_reg = LP5012_RESET, + .lp50xx_regmap_config = &lp5012_regmap_config, + }, + [LP5012] = { + .model_id = LP5012, + .max_modules = LP5012_MAX_LED_MODULES, + .num_leds = LP5012_MAX_LEDS, + .led_brightness0_reg = LP5012_LED0_BRT, + .mix_out0_reg = LP5012_OUT0_CLR, + .bank_brt_reg = LP5012_BNK_BRT, + .bank_mix_reg = LP5012_BNKA_CLR, + .reset_reg = LP5012_RESET, + .lp50xx_regmap_config = &lp5012_regmap_config, + }, + [LP5018] = { + .model_id = LP5018, + .max_modules = LP5018_MAX_LED_MODULES, + .num_leds = LP5018_MAX_LEDS, + .led_brightness0_reg = LP5024_LED0_BRT, + .mix_out0_reg = LP5024_OUT0_CLR, + .bank_brt_reg = LP5024_BNK_BRT, + .bank_mix_reg = LP5024_BNKA_CLR, + .reset_reg = LP5024_RESET, + .lp50xx_regmap_config = &lp5024_regmap_config, + }, + [LP5024] = { + .model_id = LP5024, + .max_modules = LP5024_MAX_LED_MODULES, + .num_leds = LP5024_MAX_LEDS, + .led_brightness0_reg = LP5024_LED0_BRT, + .mix_out0_reg = LP5024_OUT0_CLR, + .bank_brt_reg = LP5024_BNK_BRT, + .bank_mix_reg = LP5024_BNKA_CLR, + .reset_reg = LP5024_RESET, + .lp50xx_regmap_config = &lp5024_regmap_config, + }, + [LP5030] = { + .model_id = LP5030, + .max_modules = LP5030_MAX_LED_MODULES, + .num_leds = LP5030_MAX_LEDS, + .led_brightness0_reg = LP5036_LED0_BRT, + .mix_out0_reg = LP5036_OUT0_CLR, + .bank_brt_reg = LP5036_BNK_BRT, + .bank_mix_reg = LP5036_BNKA_CLR, + .reset_reg = LP5036_RESET, + .lp50xx_regmap_config = &lp5036_regmap_config, + }, + [LP5036] = { + .model_id = LP5036, + .max_modules = LP5036_MAX_LED_MODULES, + .num_leds = LP5036_MAX_LEDS, + .led_brightness0_reg = LP5036_LED0_BRT, + .mix_out0_reg = LP5036_OUT0_CLR, + .bank_brt_reg = LP5036_BNK_BRT, + .bank_mix_reg = LP5036_BNKA_CLR, + .reset_reg = LP5036_RESET, + .lp50xx_regmap_config = &lp5036_regmap_config, + }, +}; + +struct lp50xx_led { + struct led_classdev_mc mc_cdev; + struct lp50xx *priv; + unsigned long bank_modules; + int led_intensity[LP50XX_LEDS_PER_MODULE]; + u8 ctrl_bank_enabled; + int led_number; +}; + +/** + * struct lp50xx - + * @enable_gpio: hardware enable gpio + * @regulator: LED supply regulator pointer + * @client: pointer to the I2C client + * @regmap: device register map + * @dev: pointer to the devices device struct + * @lock: lock for reading/writing the device + * @chip_info: chip specific information (ie num_leds) + * @num_of_banked_leds: holds the number of banked LEDs + * @leds: array of LED strings + */ +struct lp50xx { + struct gpio_desc *enable_gpio; + struct regulator *regulator; + struct i2c_client *client; + struct regmap *regmap; + struct device *dev; + struct mutex lock; + const struct lp50xx_chip_info *chip_info; + int num_of_banked_leds; + + /* This needs to be at the end of the struct */ + struct lp50xx_led leds[]; +}; + +static struct lp50xx_led *mcled_cdev_to_led(struct led_classdev_mc *mc_cdev) +{ + return container_of(mc_cdev, struct lp50xx_led, mc_cdev); +} + +static int lp50xx_brightness_set(struct led_classdev *cdev, + enum led_brightness brightness) +{ + struct led_classdev_mc *mc_dev = lcdev_to_mccdev(cdev); + struct lp50xx_led *led = mcled_cdev_to_led(mc_dev); + const struct lp50xx_chip_info *led_chip = led->priv->chip_info; + u8 led_offset, reg_val; + int ret = 0; + int i; + + mutex_lock(&led->priv->lock); + if (led->ctrl_bank_enabled) + reg_val = led_chip->bank_brt_reg; + else + reg_val = led_chip->led_brightness0_reg + + led->led_number; + + ret = regmap_write(led->priv->regmap, reg_val, brightness); + if (ret) { + dev_err(&led->priv->client->dev, + "Cannot write brightness value %d\n", ret); + goto out; + } + + for (i = 0; i < led->mc_cdev.num_colors; i++) { + if (led->ctrl_bank_enabled) { + reg_val = led_chip->bank_mix_reg + i; + } else { + led_offset = (led->led_number * 3) + i; + reg_val = led_chip->mix_out0_reg + led_offset; + } + + ret = regmap_write(led->priv->regmap, reg_val, + mc_dev->subled_info[i].intensity); + if (ret) { + dev_err(&led->priv->client->dev, + "Cannot write intensity value %d\n", ret); + goto out; + } + } +out: + mutex_unlock(&led->priv->lock); + return ret; +} + +static int lp50xx_set_banks(struct lp50xx *priv, u32 led_banks[]) +{ + u8 led_config_lo, led_config_hi; + u32 bank_enable_mask = 0; + int ret; + int i; + + for (i = 0; i < priv->chip_info->max_modules; i++) { + if (led_banks[i]) + bank_enable_mask |= (1 << led_banks[i]); + } + + led_config_lo = (u8)(bank_enable_mask & 0xff); + led_config_hi = (u8)(bank_enable_mask >> 8) & 0xff; + + ret = regmap_write(priv->regmap, LP50XX_LED_CFG0, led_config_lo); + if (ret) + return ret; + + if (priv->chip_info->model_id >= LP5030) + ret = regmap_write(priv->regmap, LP5036_LED_CFG1, led_config_hi); + + return ret; +} + +static int lp50xx_reset(struct lp50xx *priv) +{ + return regmap_write(priv->regmap, priv->chip_info->reset_reg, LP50XX_SW_RESET); +} + +static int lp50xx_enable_disable(struct lp50xx *priv, int enable_disable) +{ + int ret; + + if (priv->enable_gpio) { + ret = gpiod_direction_output(priv->enable_gpio, enable_disable); + if (ret) + return ret; + } + + if (enable_disable) + return regmap_write(priv->regmap, LP50XX_DEV_CFG0, LP50XX_CHIP_EN); + else + return regmap_write(priv->regmap, LP50XX_DEV_CFG0, 0); + +} + +static int lp50xx_probe_leds(struct fwnode_handle *child, struct lp50xx *priv, + struct lp50xx_led *led, int num_leds) +{ + u32 led_banks[LP5036_MAX_LED_MODULES] = {0}; + int led_number; + int ret; + + if (num_leds > 1) { + if (num_leds > priv->chip_info->max_modules) { + dev_err(&priv->client->dev, "reg property is invalid\n"); + return -EINVAL; + } + + priv->num_of_banked_leds = num_leds; + + ret = fwnode_property_read_u32_array(child, "reg", led_banks, num_leds); + if (ret) { + dev_err(&priv->client->dev, "reg property is missing\n"); + return ret; + } + + ret = lp50xx_set_banks(priv, led_banks); + if (ret) { + dev_err(&priv->client->dev, "Cannot setup banked LEDs\n"); + return ret; + } + + led->ctrl_bank_enabled = 1; + } else { + ret = fwnode_property_read_u32(child, "reg", &led_number); + if (ret) { + dev_err(&priv->client->dev, "led reg property missing\n"); + return ret; + } + + if (led_number > priv->chip_info->num_leds) { + dev_err(&priv->client->dev, "led-sources property is invalid\n"); + return -EINVAL; + } + + led->led_number = led_number; + } + + return 0; +} + +static int lp50xx_probe_dt(struct lp50xx *priv) +{ + struct fwnode_handle *child = NULL; + struct fwnode_handle *led_node = NULL; + struct led_init_data init_data = {}; + struct led_classdev *led_cdev; + struct mc_subled *mc_led_info; + struct lp50xx_led *led; + int num_colors; + u32 color_id; + size_t i = 0; + int ret = -EINVAL; + + priv->enable_gpio = devm_gpiod_get_optional(priv->dev, "enable", GPIOD_OUT_LOW); + if (IS_ERR(priv->enable_gpio)) { + ret = PTR_ERR(priv->enable_gpio); + dev_err(&priv->client->dev, "Failed to get enable gpio: %d\n", + ret); + return ret; + } + + priv->regulator = devm_regulator_get(priv->dev, "vled"); + if (IS_ERR(priv->regulator)) + priv->regulator = NULL; + + device_for_each_child_node(priv->dev, child) { + led = &priv->leds[i]; + ret = fwnode_property_count_u32(child, "reg"); + if (ret < 0) { + dev_err(&priv->client->dev, "reg property is invalid\n"); + goto child_out; + } + + ret = lp50xx_probe_leds(child, priv, led, ret); + if (ret) + goto child_out; + + init_data.fwnode = child; + num_colors = 0; + + /* + * There are only 3 LEDs per module otherwise they should be + * banked which also is presented as 3 LEDs. + */ + mc_led_info = devm_kcalloc(priv->dev, LP50XX_LEDS_PER_MODULE, + sizeof(*mc_led_info), GFP_KERNEL); + if (!mc_led_info) + return -ENOMEM; + + fwnode_for_each_child_node(child, led_node) { + ret = fwnode_property_read_u32(led_node, "color", + &color_id); + if (ret) { + dev_err(priv->dev, "Cannot read color\n"); + goto child_out; + } + + mc_led_info[num_colors].color_index = color_id; + num_colors++; + } + + led->priv = priv; + led->mc_cdev.num_colors = num_colors; + led->mc_cdev.subled_info = mc_led_info; + led_cdev = &led->mc_cdev.led_cdev; + led_cdev->brightness_set_blocking = lp50xx_brightness_set; + + fwnode_property_read_string(child, "linux,default-trigger", + &led_cdev->default_trigger); + + ret = devm_led_classdev_multicolor_register_ext(&priv->client->dev, + &led->mc_cdev, + &init_data); + if (ret) { + dev_err(&priv->client->dev, "led register err: %d\n", + ret); + goto child_out; + } + i++; + } + + return 0; + +child_out: + fwnode_handle_put(child); + return ret; +} + +static int lp50xx_probe(struct i2c_client *client, + const struct i2c_device_id *id) +{ + struct lp50xx *led; + int count; + int ret; + + count = device_get_child_node_count(&client->dev); + if (!count) { + dev_err(&client->dev, "LEDs are not defined in device tree!"); + return -ENODEV; + } + + led = devm_kzalloc(&client->dev, struct_size(led, leds, count), + GFP_KERNEL); + if (!led) + return -ENOMEM; + + mutex_init(&led->lock); + led->client = client; + led->dev = &client->dev; + led->chip_info = &lp50xx_chip_info_tbl[id->driver_data]; + i2c_set_clientdata(client, led); + led->regmap = devm_regmap_init_i2c(client, + led->chip_info->lp50xx_regmap_config); + if (IS_ERR(led->regmap)) { + ret = PTR_ERR(led->regmap); + dev_err(&client->dev, "Failed to allocate register map: %d\n", + ret); + return ret; + } + + ret = lp50xx_reset(led); + if (ret) + return ret; + + ret = lp50xx_enable_disable(led, 1); + if (ret) + return ret; + + return lp50xx_probe_dt(led); +} + +static int lp50xx_remove(struct i2c_client *client) +{ + struct lp50xx *led = i2c_get_clientdata(client); + int ret; + + ret = lp50xx_enable_disable(led, 0); + if (ret) { + dev_err(&led->client->dev, "Failed to disable chip\n"); + return ret; + } + + if (led->regulator) { + ret = regulator_disable(led->regulator); + if (ret) + dev_err(&led->client->dev, + "Failed to disable regulator\n"); + } + + mutex_destroy(&led->lock); + + return 0; +} + +static const struct i2c_device_id lp50xx_id[] = { + { "lp5009", LP5009 }, + { "lp5012", LP5012 }, + { "lp5018", LP5018 }, + { "lp5024", LP5024 }, + { "lp5030", LP5030 }, + { "lp5036", LP5036 }, + { } +}; +MODULE_DEVICE_TABLE(i2c, lp50xx_id); + +static const struct of_device_id of_lp50xx_leds_match[] = { + { .compatible = "ti,lp5009", .data = (void *)LP5009 }, + { .compatible = "ti,lp5012", .data = (void *)LP5012 }, + { .compatible = "ti,lp5018", .data = (void *)LP5018 }, + { .compatible = "ti,lp5024", .data = (void *)LP5024 }, + { .compatible = "ti,lp5030", .data = (void *)LP5030 }, + { .compatible = "ti,lp5036", .data = (void *)LP5036 }, + {}, +}; +MODULE_DEVICE_TABLE(of, of_lp50xx_leds_match); + +static struct i2c_driver lp50xx_driver = { + .driver = { + .name = "lp50xx", + .of_match_table = of_lp50xx_leds_match, + }, + .probe = lp50xx_probe, + .remove = lp50xx_remove, + .id_table = lp50xx_id, +}; +module_i2c_driver(lp50xx_driver); + +MODULE_DESCRIPTION("Texas Instruments LP50XX LED driver"); +MODULE_AUTHOR("Dan Murphy <dmurphy@ti.com>"); +MODULE_LICENSE("GPL v2"); -- 2.27.0 ^ permalink raw reply related [flat|nested] 23+ messages in thread
* Re: [PATCH v32 2/6] leds: lp50xx: Add the LP50XX family of the RGB LED driver 2020-07-22 15:31 ` [PATCH v32 2/6] leds: lp50xx: Add the LP50XX family of the RGB LED driver Dan Murphy @ 2020-08-11 10:29 ` Pavel Machek 2020-08-11 10:31 ` Pavel Machek 2020-08-11 10:54 ` Pavel Machek 2 siblings, 0 replies; 23+ messages in thread From: Pavel Machek @ 2020-08-11 10:29 UTC (permalink / raw) To: Dan Murphy Cc: jacek.anaszewski, robh, marek.behun, devicetree, linux-leds, linux-kernel, linux-arm-kernel [-- Attachment #1: Type: text/plain, Size: 4801 bytes --] Hi! > Introduce the LP5036/30/24/18/12/9 RGB LED driver. > The difference in these parts are the number of > LED outputs where the: > > LP5036 can control 36 LEDs > LP5030 can control 30 LEDs > LP5024 can control 24 LEDs > LP5018 can control 18 LEDs > LP5012 can control 12 LEDs > LP5009 can control 9 LEDs > > The device has the ability to group LED outputs into control banks > so that multiple LED banks can be controlled with the same mixing and > brightness. Or the LED outputs can also be controlled independently. > > diff --git a/drivers/leds/leds-lp50xx.c b/drivers/leds/leds-lp50xx.c > new file mode 100644 > index 000000000000..f4ef9b7f21b2 > --- /dev/null > +++ b/drivers/leds/leds-lp50xx.c > @@ -0,0 +1,791 @@ > +// SPDX-License-Identifier: GPL-2.0 > +// TI LP50XX LED chip family driver > +// Copyright (C) 2018 Texas Instruments Incorporated - https://www.ti.com/ I assume 2018-2020 > +#define LP5012_OUT0_CLR 0x0b > +#define LP5012_OUT1_CLR 0x0c > +#define LP5012_OUT2_CLR 0x0d > +#define LP5012_OUT3_CLR 0x0e > +#define LP5012_OUT4_CLR 0x0f > +#define LP5012_OUT5_CLR 0x10 > +#define LP5012_OUT6_CLR 0x11 > +#define LP5012_OUT7_CLR 0x12 > +#define LP5012_OUT8_CLR 0x13 > +#define LP5012_OUT9_CLR 0x14 > +#define LP5012_OUT10_CLR 0x15 > +#define LP5012_OUT11_CLR 0x16 > + > +#define LP5024_OUT0_CLR 0x0f > +#define LP5024_OUT1_CLR 0x10 > +#define LP5024_OUT2_CLR 0x11 > +#define LP5024_OUT3_CLR 0x12 > +#define LP5024_OUT4_CLR 0x13 > +#define LP5024_OUT5_CLR 0x14 > +#define LP5024_OUT6_CLR 0x15 > +#define LP5024_OUT7_CLR 0x16 > +#define LP5024_OUT8_CLR 0x17 > +#define LP5024_OUT9_CLR 0x18 > +#define LP5024_OUT10_CLR 0x19 > +#define LP5024_OUT11_CLR 0x1a > +#define LP5024_OUT12_CLR 0x1b > +#define LP5024_OUT13_CLR 0x1c > +#define LP5024_OUT14_CLR 0x1d > +#define LP5024_OUT15_CLR 0x1e > +#define LP5024_OUT16_CLR 0x1f > +#define LP5024_OUT17_CLR 0x20 > +#define LP5024_OUT18_CLR 0x21 > +#define LP5024_OUT19_CLR 0x22 > +#define LP5024_OUT20_CLR 0x23 > +#define LP5024_OUT21_CLR 0x24 > +#define LP5024_OUT22_CLR 0x25 > +#define LP5024_OUT23_CLR 0x26 > +#define LP5036_OUT0_CLR 0x14 > +#define LP5036_OUT1_CLR 0x15 > +#define LP5036_OUT2_CLR 0x16 > +#define LP5036_OUT3_CLR 0x17 > +#define LP5036_OUT4_CLR 0x18 > +#define LP5036_OUT5_CLR 0x19 > +#define LP5036_OUT6_CLR 0x1a > +#define LP5036_OUT7_CLR 0x1b > +#define LP5036_OUT8_CLR 0x1c > +#define LP5036_OUT9_CLR 0x1d > +#define LP5036_OUT10_CLR 0x1e > +#define LP5036_OUT11_CLR 0x1f > +#define LP5036_OUT12_CLR 0x20 > +#define LP5036_OUT13_CLR 0x21 > +#define LP5036_OUT14_CLR 0x22 > +#define LP5036_OUT15_CLR 0x23 > +#define LP5036_OUT16_CLR 0x24 > +#define LP5036_OUT17_CLR 0x25 > +#define LP5036_OUT18_CLR 0x26 > +#define LP5036_OUT19_CLR 0x27 > +#define LP5036_OUT20_CLR 0x28 > +#define LP5036_OUT21_CLR 0x29 > +#define LP5036_OUT22_CLR 0x2a > +#define LP5036_OUT23_CLR 0x2b > +#define LP5036_OUT24_CLR 0x2c > +#define LP5036_OUT25_CLR 0x2d > +#define LP5036_OUT26_CLR 0x2e > +#define LP5036_OUT27_CLR 0x2f > +#define LP5036_OUT28_CLR 0x30 > +#define LP5036_OUT29_CLR 0x31 > +#define LP5036_OUT30_CLR 0x32 > +#define LP5036_OUT31_CLR 0x33 > +#define LP5036_OUT32_CLR 0x34 > +#define LP5036_OUT33_CLR 0x35 > +#define LP5036_OUT34_CLR 0x36 > +#define LP5036_OUT35_CLR 0x37 These are really useless. Please get rid of them. > +#define LP5009_MAX_LED_MODULES 2 > +#define LP5012_MAX_LED_MODULES 4 > +#define LP5018_MAX_LED_MODULES 6 > +#define LP5024_MAX_LED_MODULES 8 > +#define LP5030_MAX_LED_MODULES 10 > +#define LP5036_MAX_LED_MODULES 12 > + > +#define LP5009_MAX_LEDS (LP5009_MAX_LED_MODULES * LP50XX_LEDS_PER_MODULE) > +#define LP5012_MAX_LEDS (LP5012_MAX_LED_MODULES * LP50XX_LEDS_PER_MODULE) > +#define LP5018_MAX_LEDS (LP5018_MAX_LED_MODULES * LP50XX_LEDS_PER_MODULE) > +#define LP5024_MAX_LEDS (LP5024_MAX_LED_MODULES * LP50XX_LEDS_PER_MODULE) > +#define LP5030_MAX_LEDS (LP5030_MAX_LED_MODULES * LP50XX_LEDS_PER_MODULE) > +#define LP5036_MAX_LEDS (LP5036_MAX_LED_MODULES * LP50XX_LEDS_PER_MODULE) As are these. In general, when define is used just once, please think if we really need it. > +static int lp50xx_probe_dt(struct lp50xx *priv) > +{ > + struct fwnode_handle *child = NULL; > + struct fwnode_handle *led_node = NULL; > + struct led_init_data init_data = {}; > + struct led_classdev *led_cdev; > + struct mc_subled *mc_led_info; > + struct lp50xx_led *led; > + int num_colors; > + u32 color_id; > + size_t i = 0; No reason this has to be size_t. Int? Best regards, Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 195 bytes --] ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: [PATCH v32 2/6] leds: lp50xx: Add the LP50XX family of the RGB LED driver 2020-07-22 15:31 ` [PATCH v32 2/6] leds: lp50xx: Add the LP50XX family of the RGB LED driver Dan Murphy 2020-08-11 10:29 ` Pavel Machek @ 2020-08-11 10:31 ` Pavel Machek 2020-08-11 10:54 ` Pavel Machek 2 siblings, 0 replies; 23+ messages in thread From: Pavel Machek @ 2020-08-11 10:31 UTC (permalink / raw) To: Dan Murphy Cc: jacek.anaszewski, robh, marek.behun, devicetree, linux-leds, linux-kernel, linux-arm-kernel [-- Attachment #1: Type: text/plain, Size: 1666 bytes --] Hi! > Introduce the LP5036/30/24/18/12/9 RGB LED driver. > The difference in these parts are the number of > LED outputs where the: > > LP5036 can control 36 LEDs > LP5030 can control 30 LEDs > LP5024 can control 24 LEDs > LP5018 can control 18 LEDs > LP5012 can control 12 LEDs > LP5009 can control 9 LEDs > > + fwnode_for_each_child_node(child, led_node) { > + ret = fwnode_property_read_u32(led_node, "color", > + &color_id); > + if (ret) { > + dev_err(priv->dev, "Cannot read color\n"); > + goto child_out; > + } > + > + mc_led_info[num_colors].color_index = color_id; > + num_colors++; > + } > + > + led->priv = priv; > + led->mc_cdev.num_colors = num_colors; > + led->mc_cdev.subled_info = mc_led_info; > + led_cdev = &led->mc_cdev.led_cdev; > + led_cdev->brightness_set_blocking = lp50xx_brightness_set; > + > + fwnode_property_read_string(child, "linux,default-trigger", > + &led_cdev->default_trigger); > + > + ret = devm_led_classdev_multicolor_register_ext(&priv->client->dev, > + &led->mc_cdev, > + &init_data); > + if (ret) { > + dev_err(&priv->client->dev, "led register err: %d\n", > + ret); > + goto child_out; > + } > + i++; > + } > + > + return 0; > + > +child_out: > + fwnode_handle_put(child); > + return ret; > +} Are you really sure fwnode_handle_put() handling is okay here? In particular, where does that happen in non-error path? Best regards, Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 195 bytes --] ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: [PATCH v32 2/6] leds: lp50xx: Add the LP50XX family of the RGB LED driver 2020-07-22 15:31 ` [PATCH v32 2/6] leds: lp50xx: Add the LP50XX family of the RGB LED driver Dan Murphy 2020-08-11 10:29 ` Pavel Machek 2020-08-11 10:31 ` Pavel Machek @ 2020-08-11 10:54 ` Pavel Machek 2020-08-11 17:27 ` Dan Murphy 2 siblings, 1 reply; 23+ messages in thread From: Pavel Machek @ 2020-08-11 10:54 UTC (permalink / raw) To: Dan Murphy Cc: jacek.anaszewski, robh, marek.behun, devicetree, linux-leds, linux-kernel, linux-arm-kernel [-- Attachment #1: Type: text/plain, Size: 6696 bytes --] Hi! > +/* LP5009 and LP5012 registers */ > +#define LP5012_BNK_BRT 0x03 > +#define LP5012_BNKA_CLR 0x04 > +#define LP5012_BNKB_CLR 0x05 > +#define LP5012_BNKC_CLR 0x06 > +#define LP5012_LED0_BRT 0x07 > +#define LP5012_LED1_BRT 0x08 > +#define LP5012_LED2_BRT 0x09 > +#define LP5012_LED3_BRT 0x0a > +#define LP5012_OUT0_CLR 0x0b > +#define LP5012_OUT1_CLR 0x0c > +#define LP5012_OUT2_CLR 0x0d > +#define LP5012_OUT3_CLR 0x0e > +#define LP5012_OUT4_CLR 0x0f > +#define LP5012_OUT5_CLR 0x10 > +#define LP5012_OUT6_CLR 0x11 > +#define LP5012_OUT7_CLR 0x12 > +#define LP5012_OUT8_CLR 0x13 > +#define LP5012_OUT9_CLR 0x14 > +#define LP5012_OUT10_CLR 0x15 > +#define LP5012_OUT11_CLR 0x16 > +#define LP5012_RESET 0x17 > + > +/* LP5018 and LP5024 registers */ > +#define LP5024_BNK_BRT 0x03 > +#define LP5024_BNKA_CLR 0x04 > +#define LP5024_BNKB_CLR 0x05 > +#define LP5024_BNKC_CLR 0x06 > +#define LP5024_LED0_BRT 0x07 > +#define LP5024_LED1_BRT 0x08 > +#define LP5024_LED2_BRT 0x09 > +#define LP5024_LED3_BRT 0x0a > +#define LP5024_LED4_BRT 0x0b > +#define LP5024_LED5_BRT 0x0c > +#define LP5024_LED6_BRT 0x0d > +#define LP5024_LED7_BRT 0x0e > + > +#define LP5024_OUT0_CLR 0x0f > +#define LP5024_OUT1_CLR 0x10 > +#define LP5024_OUT2_CLR 0x11 > +#define LP5024_OUT3_CLR 0x12 > +#define LP5024_OUT4_CLR 0x13 > +#define LP5024_OUT5_CLR 0x14 > +#define LP5024_OUT6_CLR 0x15 > +#define LP5024_OUT7_CLR 0x16 > +#define LP5024_OUT8_CLR 0x17 > +#define LP5024_OUT9_CLR 0x18 > +#define LP5024_OUT10_CLR 0x19 > +#define LP5024_OUT11_CLR 0x1a > +#define LP5024_OUT12_CLR 0x1b > +#define LP5024_OUT13_CLR 0x1c > +#define LP5024_OUT14_CLR 0x1d > +#define LP5024_OUT15_CLR 0x1e > +#define LP5024_OUT16_CLR 0x1f > +#define LP5024_OUT17_CLR 0x20 > +#define LP5024_OUT18_CLR 0x21 > +#define LP5024_OUT19_CLR 0x22 > +#define LP5024_OUT20_CLR 0x23 > +#define LP5024_OUT21_CLR 0x24 > +#define LP5024_OUT22_CLR 0x25 > +#define LP5024_OUT23_CLR 0x26 > +#define LP5024_RESET 0x27 > + > +/* LP5030 and LP5036 registers */ > +#define LP5036_LED_CFG1 0x03 > +#define LP5036_BNK_BRT 0x04 > +#define LP5036_BNKA_CLR 0x05 > +#define LP5036_BNKB_CLR 0x06 > +#define LP5036_BNKC_CLR 0x07 > +#define LP5036_LED0_BRT 0x08 > +#define LP5036_LED1_BRT 0x09 > +#define LP5036_LED2_BRT 0x0a > +#define LP5036_LED3_BRT 0x0b > +#define LP5036_LED4_BRT 0x0c > +#define LP5036_LED5_BRT 0x0d > +#define LP5036_LED6_BRT 0x0e > +#define LP5036_LED7_BRT 0x0f > +#define LP5036_LED8_BRT 0x10 > +#define LP5036_LED9_BRT 0x11 > +#define LP5036_LED10_BRT 0x12 > +#define LP5036_LED11_BRT 0x13 > + > +#define LP5036_OUT0_CLR 0x14 > +#define LP5036_OUT1_CLR 0x15 > +#define LP5036_OUT2_CLR 0x16 > +#define LP5036_OUT3_CLR 0x17 > +#define LP5036_OUT4_CLR 0x18 > +#define LP5036_OUT5_CLR 0x19 > +#define LP5036_OUT6_CLR 0x1a > +#define LP5036_OUT7_CLR 0x1b > +#define LP5036_OUT8_CLR 0x1c > +#define LP5036_OUT9_CLR 0x1d > +#define LP5036_OUT10_CLR 0x1e > +#define LP5036_OUT11_CLR 0x1f > +#define LP5036_OUT12_CLR 0x20 > +#define LP5036_OUT13_CLR 0x21 > +#define LP5036_OUT14_CLR 0x22 > +#define LP5036_OUT15_CLR 0x23 > +#define LP5036_OUT16_CLR 0x24 > +#define LP5036_OUT17_CLR 0x25 > +#define LP5036_OUT18_CLR 0x26 > +#define LP5036_OUT19_CLR 0x27 > +#define LP5036_OUT20_CLR 0x28 > +#define LP5036_OUT21_CLR 0x29 > +#define LP5036_OUT22_CLR 0x2a > +#define LP5036_OUT23_CLR 0x2b > +#define LP5036_OUT24_CLR 0x2c > +#define LP5036_OUT25_CLR 0x2d > +#define LP5036_OUT26_CLR 0x2e > +#define LP5036_OUT27_CLR 0x2f > +#define LP5036_OUT28_CLR 0x30 > +#define LP5036_OUT29_CLR 0x31 > +#define LP5036_OUT30_CLR 0x32 > +#define LP5036_OUT31_CLR 0x33 > +#define LP5036_OUT32_CLR 0x34 > +#define LP5036_OUT33_CLR 0x35 > +#define LP5036_OUT34_CLR 0x36 > +#define LP5036_OUT35_CLR 0x37 > +#define LP5036_RESET 0x38 > +static const struct reg_default lp5012_reg_defs[] = { ... > + {LP5012_OUT1_CLR, 0x00}, > + {LP5012_OUT2_CLR, 0x00}, > + {LP5012_OUT3_CLR, 0x00}, > + {LP5012_OUT4_CLR, 0x00}, > + {LP5012_OUT5_CLR, 0x00}, > + {LP5012_OUT6_CLR, 0x00}, > + {LP5012_OUT7_CLR, 0x00}, > + {LP5012_OUT8_CLR, 0x00}, > + {LP5012_OUT9_CLR, 0x00}, > + {LP5012_OUT10_CLR, 0x00}, > + {LP5012_OUT11_CLR, 0x00}, > + {LP5012_RESET, 0x00} > +}; > + > +static const struct reg_default lp5024_reg_defs[] = { ... > + {LP5024_OUT1_CLR, 0x00}, > + {LP5024_OUT2_CLR, 0x00}, > + {LP5024_OUT3_CLR, 0x00}, > + {LP5024_OUT4_CLR, 0x00}, > + {LP5024_OUT5_CLR, 0x00}, > + {LP5024_OUT6_CLR, 0x00}, > + {LP5024_OUT7_CLR, 0x00}, > + {LP5024_OUT8_CLR, 0x00}, > + {LP5024_OUT9_CLR, 0x00}, > + {LP5024_OUT10_CLR, 0x00}, > + {LP5024_OUT11_CLR, 0x00}, > + {LP5024_OUT12_CLR, 0x00}, > + {LP5024_OUT13_CLR, 0x00}, > + {LP5024_OUT14_CLR, 0x00}, > + {LP5024_OUT15_CLR, 0x00}, > + {LP5024_OUT16_CLR, 0x00}, > + {LP5024_OUT17_CLR, 0x00}, > + {LP5024_OUT18_CLR, 0x00}, > + {LP5024_OUT19_CLR, 0x00}, > + {LP5024_OUT20_CLR, 0x00}, > + {LP5024_OUT21_CLR, 0x00}, > + {LP5024_OUT22_CLR, 0x00}, > + {LP5024_OUT23_CLR, 0x00}, > + {LP5024_RESET, 0x00} > +}; > + > +static const struct reg_default lp5036_reg_defs[] = { > + {LP5036_OUT1_CLR, 0x00}, > + {LP5036_OUT2_CLR, 0x00}, > + {LP5036_OUT3_CLR, 0x00}, > + {LP5036_OUT4_CLR, 0x00}, > + {LP5036_OUT5_CLR, 0x00}, > + {LP5036_OUT6_CLR, 0x00}, > + {LP5036_OUT7_CLR, 0x00}, > + {LP5036_OUT8_CLR, 0x00}, > + {LP5036_OUT9_CLR, 0x00}, > + {LP5036_OUT10_CLR, 0x00}, > + {LP5036_OUT11_CLR, 0x00}, > + {LP5036_OUT12_CLR, 0x00}, > + {LP5036_OUT13_CLR, 0x00}, > + {LP5036_OUT14_CLR, 0x00}, > + {LP5036_OUT15_CLR, 0x00}, > + {LP5036_OUT16_CLR, 0x00}, > + {LP5036_OUT17_CLR, 0x00}, > + {LP5036_OUT18_CLR, 0x00}, > + {LP5036_OUT19_CLR, 0x00}, > + {LP5036_OUT20_CLR, 0x00}, > + {LP5036_OUT21_CLR, 0x00}, > + {LP5036_OUT22_CLR, 0x00}, > + {LP5036_OUT23_CLR, 0x00}, > + {LP5036_OUT24_CLR, 0x00}, > + {LP5036_OUT25_CLR, 0x00}, > + {LP5036_OUT26_CLR, 0x00}, > + {LP5036_OUT27_CLR, 0x00}, > + {LP5036_OUT28_CLR, 0x00}, > + {LP5036_OUT29_CLR, 0x00}, > + {LP5036_OUT30_CLR, 0x00}, > + {LP5036_OUT31_CLR, 0x00}, > + {LP5036_OUT32_CLR, 0x00}, > + {LP5036_OUT33_CLR, 0x00}, > + {LP5036_OUT34_CLR, 0x00}, > + {LP5036_OUT35_CLR, 0x00}, > + {LP5036_RESET, 0x00} > +}; Actually... This is quite impressive ammount of code to zero-initialize few registers. Could the regmap be told to set the range to zero, or use loops to reduce ammount of code? Thanks, Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 195 bytes --] ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: [PATCH v32 2/6] leds: lp50xx: Add the LP50XX family of the RGB LED driver 2020-08-11 10:54 ` Pavel Machek @ 2020-08-11 17:27 ` Dan Murphy 2020-08-11 22:01 ` Pavel Machek 0 siblings, 1 reply; 23+ messages in thread From: Dan Murphy @ 2020-08-11 17:27 UTC (permalink / raw) To: Pavel Machek Cc: jacek.anaszewski, robh, marek.behun, devicetree, linux-leds, linux-kernel, linux-arm-kernel Hello On 8/11/20 5:54 AM, Pavel Machek wrote: > Hi! > >> +/* LP5009 and LP5012 registers */ >> +#define LP5012_BNK_BRT 0x03 >> +#define LP5012_BNKA_CLR 0x04 >> +#define LP5012_BNKB_CLR 0x05 >> +#define LP5012_BNKC_CLR 0x06 >> +#define LP5012_LED0_BRT 0x07 >> +#define LP5012_LED1_BRT 0x08 >> +#define LP5012_LED2_BRT 0x09 >> +#define LP5012_LED3_BRT 0x0a >> +#define LP5012_OUT0_CLR 0x0b >> +#define LP5012_OUT1_CLR 0x0c >> +#define LP5012_OUT2_CLR 0x0d >> +#define LP5012_OUT3_CLR 0x0e >> +#define LP5012_OUT4_CLR 0x0f >> +#define LP5012_OUT5_CLR 0x10 >> +#define LP5012_OUT6_CLR 0x11 >> +#define LP5012_OUT7_CLR 0x12 >> +#define LP5012_OUT8_CLR 0x13 >> +#define LP5012_OUT9_CLR 0x14 >> +#define LP5012_OUT10_CLR 0x15 >> +#define LP5012_OUT11_CLR 0x16 >> +#define LP5012_RESET 0x17 >> + >> +/* LP5018 and LP5024 registers */ >> +#define LP5024_BNK_BRT 0x03 >> +#define LP5024_BNKA_CLR 0x04 >> +#define LP5024_BNKB_CLR 0x05 >> +#define LP5024_BNKC_CLR 0x06 >> +#define LP5024_LED0_BRT 0x07 >> +#define LP5024_LED1_BRT 0x08 >> +#define LP5024_LED2_BRT 0x09 >> +#define LP5024_LED3_BRT 0x0a >> +#define LP5024_LED4_BRT 0x0b >> +#define LP5024_LED5_BRT 0x0c >> +#define LP5024_LED6_BRT 0x0d >> +#define LP5024_LED7_BRT 0x0e >> + >> +#define LP5024_OUT0_CLR 0x0f >> +#define LP5024_OUT1_CLR 0x10 >> +#define LP5024_OUT2_CLR 0x11 >> +#define LP5024_OUT3_CLR 0x12 >> +#define LP5024_OUT4_CLR 0x13 >> +#define LP5024_OUT5_CLR 0x14 >> +#define LP5024_OUT6_CLR 0x15 >> +#define LP5024_OUT7_CLR 0x16 >> +#define LP5024_OUT8_CLR 0x17 >> +#define LP5024_OUT9_CLR 0x18 >> +#define LP5024_OUT10_CLR 0x19 >> +#define LP5024_OUT11_CLR 0x1a >> +#define LP5024_OUT12_CLR 0x1b >> +#define LP5024_OUT13_CLR 0x1c >> +#define LP5024_OUT14_CLR 0x1d >> +#define LP5024_OUT15_CLR 0x1e >> +#define LP5024_OUT16_CLR 0x1f >> +#define LP5024_OUT17_CLR 0x20 >> +#define LP5024_OUT18_CLR 0x21 >> +#define LP5024_OUT19_CLR 0x22 >> +#define LP5024_OUT20_CLR 0x23 >> +#define LP5024_OUT21_CLR 0x24 >> +#define LP5024_OUT22_CLR 0x25 >> +#define LP5024_OUT23_CLR 0x26 >> +#define LP5024_RESET 0x27 >> + >> +/* LP5030 and LP5036 registers */ >> +#define LP5036_LED_CFG1 0x03 >> +#define LP5036_BNK_BRT 0x04 >> +#define LP5036_BNKA_CLR 0x05 >> +#define LP5036_BNKB_CLR 0x06 >> +#define LP5036_BNKC_CLR 0x07 >> +#define LP5036_LED0_BRT 0x08 >> +#define LP5036_LED1_BRT 0x09 >> +#define LP5036_LED2_BRT 0x0a >> +#define LP5036_LED3_BRT 0x0b >> +#define LP5036_LED4_BRT 0x0c >> +#define LP5036_LED5_BRT 0x0d >> +#define LP5036_LED6_BRT 0x0e >> +#define LP5036_LED7_BRT 0x0f >> +#define LP5036_LED8_BRT 0x10 >> +#define LP5036_LED9_BRT 0x11 >> +#define LP5036_LED10_BRT 0x12 >> +#define LP5036_LED11_BRT 0x13 >> + >> +#define LP5036_OUT0_CLR 0x14 >> +#define LP5036_OUT1_CLR 0x15 >> +#define LP5036_OUT2_CLR 0x16 >> +#define LP5036_OUT3_CLR 0x17 >> +#define LP5036_OUT4_CLR 0x18 >> +#define LP5036_OUT5_CLR 0x19 >> +#define LP5036_OUT6_CLR 0x1a >> +#define LP5036_OUT7_CLR 0x1b >> +#define LP5036_OUT8_CLR 0x1c >> +#define LP5036_OUT9_CLR 0x1d >> +#define LP5036_OUT10_CLR 0x1e >> +#define LP5036_OUT11_CLR 0x1f >> +#define LP5036_OUT12_CLR 0x20 >> +#define LP5036_OUT13_CLR 0x21 >> +#define LP5036_OUT14_CLR 0x22 >> +#define LP5036_OUT15_CLR 0x23 >> +#define LP5036_OUT16_CLR 0x24 >> +#define LP5036_OUT17_CLR 0x25 >> +#define LP5036_OUT18_CLR 0x26 >> +#define LP5036_OUT19_CLR 0x27 >> +#define LP5036_OUT20_CLR 0x28 >> +#define LP5036_OUT21_CLR 0x29 >> +#define LP5036_OUT22_CLR 0x2a >> +#define LP5036_OUT23_CLR 0x2b >> +#define LP5036_OUT24_CLR 0x2c >> +#define LP5036_OUT25_CLR 0x2d >> +#define LP5036_OUT26_CLR 0x2e >> +#define LP5036_OUT27_CLR 0x2f >> +#define LP5036_OUT28_CLR 0x30 >> +#define LP5036_OUT29_CLR 0x31 >> +#define LP5036_OUT30_CLR 0x32 >> +#define LP5036_OUT31_CLR 0x33 >> +#define LP5036_OUT32_CLR 0x34 >> +#define LP5036_OUT33_CLR 0x35 >> +#define LP5036_OUT34_CLR 0x36 >> +#define LP5036_OUT35_CLR 0x37 >> +#define LP5036_RESET 0x38 >> +static const struct reg_default lp5012_reg_defs[] = { > ... >> + {LP5012_OUT1_CLR, 0x00}, >> + {LP5012_OUT2_CLR, 0x00}, >> + {LP5012_OUT3_CLR, 0x00}, >> + {LP5012_OUT4_CLR, 0x00}, >> + {LP5012_OUT5_CLR, 0x00}, >> + {LP5012_OUT6_CLR, 0x00}, >> + {LP5012_OUT7_CLR, 0x00}, >> + {LP5012_OUT8_CLR, 0x00}, >> + {LP5012_OUT9_CLR, 0x00}, >> + {LP5012_OUT10_CLR, 0x00}, >> + {LP5012_OUT11_CLR, 0x00}, >> + {LP5012_RESET, 0x00} >> +}; >> + >> +static const struct reg_default lp5024_reg_defs[] = { > ... >> + {LP5024_OUT1_CLR, 0x00}, >> + {LP5024_OUT2_CLR, 0x00}, >> + {LP5024_OUT3_CLR, 0x00}, >> + {LP5024_OUT4_CLR, 0x00}, >> + {LP5024_OUT5_CLR, 0x00}, >> + {LP5024_OUT6_CLR, 0x00}, >> + {LP5024_OUT7_CLR, 0x00}, >> + {LP5024_OUT8_CLR, 0x00}, >> + {LP5024_OUT9_CLR, 0x00}, >> + {LP5024_OUT10_CLR, 0x00}, >> + {LP5024_OUT11_CLR, 0x00}, >> + {LP5024_OUT12_CLR, 0x00}, >> + {LP5024_OUT13_CLR, 0x00}, >> + {LP5024_OUT14_CLR, 0x00}, >> + {LP5024_OUT15_CLR, 0x00}, >> + {LP5024_OUT16_CLR, 0x00}, >> + {LP5024_OUT17_CLR, 0x00}, >> + {LP5024_OUT18_CLR, 0x00}, >> + {LP5024_OUT19_CLR, 0x00}, >> + {LP5024_OUT20_CLR, 0x00}, >> + {LP5024_OUT21_CLR, 0x00}, >> + {LP5024_OUT22_CLR, 0x00}, >> + {LP5024_OUT23_CLR, 0x00}, >> + {LP5024_RESET, 0x00} >> +}; >> + >> +static const struct reg_default lp5036_reg_defs[] = { >> + {LP5036_OUT1_CLR, 0x00}, >> + {LP5036_OUT2_CLR, 0x00}, >> + {LP5036_OUT3_CLR, 0x00}, >> + {LP5036_OUT4_CLR, 0x00}, >> + {LP5036_OUT5_CLR, 0x00}, >> + {LP5036_OUT6_CLR, 0x00}, >> + {LP5036_OUT7_CLR, 0x00}, >> + {LP5036_OUT8_CLR, 0x00}, >> + {LP5036_OUT9_CLR, 0x00}, >> + {LP5036_OUT10_CLR, 0x00}, >> + {LP5036_OUT11_CLR, 0x00}, >> + {LP5036_OUT12_CLR, 0x00}, >> + {LP5036_OUT13_CLR, 0x00}, >> + {LP5036_OUT14_CLR, 0x00}, >> + {LP5036_OUT15_CLR, 0x00}, >> + {LP5036_OUT16_CLR, 0x00}, >> + {LP5036_OUT17_CLR, 0x00}, >> + {LP5036_OUT18_CLR, 0x00}, >> + {LP5036_OUT19_CLR, 0x00}, >> + {LP5036_OUT20_CLR, 0x00}, >> + {LP5036_OUT21_CLR, 0x00}, >> + {LP5036_OUT22_CLR, 0x00}, >> + {LP5036_OUT23_CLR, 0x00}, >> + {LP5036_OUT24_CLR, 0x00}, >> + {LP5036_OUT25_CLR, 0x00}, >> + {LP5036_OUT26_CLR, 0x00}, >> + {LP5036_OUT27_CLR, 0x00}, >> + {LP5036_OUT28_CLR, 0x00}, >> + {LP5036_OUT29_CLR, 0x00}, >> + {LP5036_OUT30_CLR, 0x00}, >> + {LP5036_OUT31_CLR, 0x00}, >> + {LP5036_OUT32_CLR, 0x00}, >> + {LP5036_OUT33_CLR, 0x00}, >> + {LP5036_OUT34_CLR, 0x00}, >> + {LP5036_OUT35_CLR, 0x00}, >> + {LP5036_RESET, 0x00} >> +}; > Actually... This is quite impressive ammount of code to > zero-initialize few registers. Could the regmap be told to set the > range to zero, or use loops to reduce ammount of code? I am not aware of any regmap calls that will set a range of registers to a certain value. Well it depends on where we want to create the default cache values. Either we run through a for..loop during driver probe and delay device start up or we keep the simple arrays and increase the driver total size. I am not seeing an advantage or disadvantage of one over the other. This is a simpler and more clear way to init the registers versus a loop. Dan > Thanks, > Pavel > > ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: [PATCH v32 2/6] leds: lp50xx: Add the LP50XX family of the RGB LED driver 2020-08-11 17:27 ` Dan Murphy @ 2020-08-11 22:01 ` Pavel Machek 2020-08-11 22:16 ` Dan Murphy 0 siblings, 1 reply; 23+ messages in thread From: Pavel Machek @ 2020-08-11 22:01 UTC (permalink / raw) To: Dan Murphy Cc: jacek.anaszewski, robh, marek.behun, devicetree, linux-leds, linux-kernel, linux-arm-kernel [-- Attachment #1: Type: text/plain, Size: 780 bytes --] Hi! > >Actually... This is quite impressive ammount of code to > >zero-initialize few registers. Could the regmap be told to set the > >range to zero, or use loops to reduce ammount of code? > > I am not aware of any regmap calls that will set a range of registers to a > certain value. > > Well it depends on where we want to create the default cache values. > > Either we run through a for..loop during driver probe and delay device start > up or we keep the simple arrays and increase the driver total size. for loop will be better. Plus, REGCACHE_RBTREE is very likely overkill. Best regards, Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html [-- Attachment #2: Digital signature --] [-- Type: application/pgp-signature, Size: 181 bytes --] ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: [PATCH v32 2/6] leds: lp50xx: Add the LP50XX family of the RGB LED driver 2020-08-11 22:01 ` Pavel Machek @ 2020-08-11 22:16 ` Dan Murphy 2020-08-11 22:26 ` Pavel Machek 0 siblings, 1 reply; 23+ messages in thread From: Dan Murphy @ 2020-08-11 22:16 UTC (permalink / raw) To: Pavel Machek Cc: jacek.anaszewski, robh, marek.behun, devicetree, linux-leds, linux-kernel, linux-arm-kernel Pavel On 8/11/20 5:01 PM, Pavel Machek wrote: > Hi! > >>> Actually... This is quite impressive ammount of code to >>> zero-initialize few registers. Could the regmap be told to set the >>> range to zero, or use loops to reduce ammount of code? >> I am not aware of any regmap calls that will set a range of registers to a >> certain value. >> >> Well it depends on where we want to create the default cache values. >> >> Either we run through a for..loop during driver probe and delay device start >> up or we keep the simple arrays and increase the driver total size. > for loop will be better. > > Plus, REGCACHE_RBTREE is very likely overkill. Well if I eliminate the reg_cache then I can eliminate the defaults too. Dan > Best regards, > > Pavel ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: [PATCH v32 2/6] leds: lp50xx: Add the LP50XX family of the RGB LED driver 2020-08-11 22:16 ` Dan Murphy @ 2020-08-11 22:26 ` Pavel Machek 2020-08-12 16:00 ` Dan Murphy 0 siblings, 1 reply; 23+ messages in thread From: Pavel Machek @ 2020-08-11 22:26 UTC (permalink / raw) To: Dan Murphy Cc: jacek.anaszewski, robh, marek.behun, devicetree, linux-leds, linux-kernel, linux-arm-kernel [-- Attachment #1: Type: text/plain, Size: 630 bytes --] Hi! > >>Well it depends on where we want to create the default cache values. > >> > >>Either we run through a for..loop during driver probe and delay device start > >>up or we keep the simple arrays and increase the driver total size. > >for loop will be better. > > > >Plus, REGCACHE_RBTREE is very likely overkill. > > Well if I eliminate the reg_cache then I can eliminate the defaults too. I'm not asking for that. But please investigate REGCACHE_FLAT. Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html [-- Attachment #2: Digital signature --] [-- Type: application/pgp-signature, Size: 181 bytes --] ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: [PATCH v32 2/6] leds: lp50xx: Add the LP50XX family of the RGB LED driver 2020-08-11 22:26 ` Pavel Machek @ 2020-08-12 16:00 ` Dan Murphy 0 siblings, 0 replies; 23+ messages in thread From: Dan Murphy @ 2020-08-12 16:00 UTC (permalink / raw) To: Pavel Machek Cc: jacek.anaszewski, robh, marek.behun, devicetree, linux-leds, linux-kernel, linux-arm-kernel Pavel On 8/11/20 5:26 PM, Pavel Machek wrote: > Hi! > >>>> Well it depends on where we want to create the default cache values. >>>> >>>> Either we run through a for..loop during driver probe and delay device start >>>> up or we keep the simple arrays and increase the driver total size. >>> for loop will be better. >>> >>> Plus, REGCACHE_RBTREE is very likely overkill. >> Well if I eliminate the reg_cache then I can eliminate the defaults too. > I'm not asking for that. But please investigate REGCACHE_FLAT. > > Pavel After looking at this a loop makes no sense here. The regmap call back values are determined at build time not during runtime. Adding a loop here makes the code more complex just to reduce the overall LoC. In adding the loop the reg_default array will have to be re-allocated and copied at run time and then be expanded to include the additional values. And the regmap defaults call backs will need to be updated to reflect the new values. And these are part of a const struct because the devm_regmap_init declares the config as a const. .reg_defaults = lp5012_reg_defs, .num_reg_defaults = ARRAY_SIZE(lp5012_reg_defs), So I am not sure that adding a loop here just to eliminate some LoC is adding any value here. I can remove the #defines for the unused runtime registers and hard code the additional register addresses in the default array. That will at least eliminate some LoC and reduce the object size. I have no issue with using the REGCACHE_FLAT so I will make that change. Dan ^ permalink raw reply [flat|nested] 23+ messages in thread
* [PATCH v32 3/6] ARM: defconfig: u8500: Add LP55XX_COMMON config flag 2020-07-22 15:31 [PATCH v32 0/6] Multicolor Framework v32 Dan Murphy 2020-07-22 15:31 ` [PATCH v32 1/6] dt: bindings: lp50xx: Introduce the lp50xx family of RGB drivers Dan Murphy 2020-07-22 15:31 ` [PATCH v32 2/6] leds: lp50xx: Add the LP50XX family of the RGB LED driver Dan Murphy @ 2020-07-22 15:31 ` Dan Murphy 2020-07-28 13:38 ` Dan Murphy 2020-08-03 23:14 ` Linus Walleij 2020-07-22 15:31 ` [PATCH v32 4/6] ARM: dts: n900: Add reg property to the LP5523 channel node Dan Murphy ` (2 subsequent siblings) 5 siblings, 2 replies; 23+ messages in thread From: Dan Murphy @ 2020-07-22 15:31 UTC (permalink / raw) To: jacek.anaszewski, pavel, robh, marek.behun Cc: devicetree, linux-leds, linux-kernel, linux-arm-kernel, Dan Murphy The dependencies for the LP55XX LED drivers have been updated so that the child devices (i.e. LP5521) now depends on the LP55XX_COMMON config flag as opposed to the device selecting the LP55XX_COMMON flag. The LP55XX_COMMON needs to be set in the defconfig. Signed-off-by: Dan Murphy <dmurphy@ti.com> --- arch/arm/configs/u8500_defconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/arm/configs/u8500_defconfig b/arch/arm/configs/u8500_defconfig index 28dd7cf56048..dea599e1c17e 100644 --- a/arch/arm/configs/u8500_defconfig +++ b/arch/arm/configs/u8500_defconfig @@ -113,6 +113,7 @@ CONFIG_NEW_LEDS=y CONFIG_LEDS_CLASS=y CONFIG_LEDS_LM3530=y CONFIG_LEDS_GPIO=y +CONFIG_LEDS_LP55XX_COMMON=y CONFIG_LEDS_LP5521=y CONFIG_LEDS_TRIGGER_HEARTBEAT=y CONFIG_RTC_CLASS=y -- 2.27.0 ^ permalink raw reply related [flat|nested] 23+ messages in thread
* Re: [PATCH v32 3/6] ARM: defconfig: u8500: Add LP55XX_COMMON config flag 2020-07-22 15:31 ` [PATCH v32 3/6] ARM: defconfig: u8500: Add LP55XX_COMMON config flag Dan Murphy @ 2020-07-28 13:38 ` Dan Murphy 2020-08-03 23:14 ` Linus Walleij 1 sibling, 0 replies; 23+ messages in thread From: Dan Murphy @ 2020-07-28 13:38 UTC (permalink / raw) To: jacek.anaszewski, pavel, Russell King - ARM Linux admin, Linus Walleij Cc: devicetree, linux-leds, linux-kernel, linux-arm-kernel Russel and Linus On 7/22/20 10:31 AM, Dan Murphy wrote: > The dependencies for the LP55XX LED drivers have been updated so that > the child devices (i.e. LP5521) now depends on the LP55XX_COMMON config > flag as opposed to the device selecting the LP55XX_COMMON flag. The > LP55XX_COMMON needs to be set in the defconfig. > > Signed-off-by: Dan Murphy <dmurphy@ti.com> > --- > arch/arm/configs/u8500_defconfig | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/arch/arm/configs/u8500_defconfig b/arch/arm/configs/u8500_defconfig > index 28dd7cf56048..dea599e1c17e 100644 > --- a/arch/arm/configs/u8500_defconfig > +++ b/arch/arm/configs/u8500_defconfig > @@ -113,6 +113,7 @@ CONFIG_NEW_LEDS=y > CONFIG_LEDS_CLASS=y > CONFIG_LEDS_LM3530=y > CONFIG_LEDS_GPIO=y > +CONFIG_LEDS_LP55XX_COMMON=y > CONFIG_LEDS_LP5521=y > CONFIG_LEDS_TRIGGER_HEARTBEAT=y > CONFIG_RTC_CLASS=y I missed adding you to the patch. Can you kindly review this change? Dan ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: [PATCH v32 3/6] ARM: defconfig: u8500: Add LP55XX_COMMON config flag 2020-07-22 15:31 ` [PATCH v32 3/6] ARM: defconfig: u8500: Add LP55XX_COMMON config flag Dan Murphy 2020-07-28 13:38 ` Dan Murphy @ 2020-08-03 23:14 ` Linus Walleij 1 sibling, 0 replies; 23+ messages in thread From: Linus Walleij @ 2020-08-03 23:14 UTC (permalink / raw) To: Dan Murphy Cc: Jacek Anaszewski, Pavel Machek, Rob Herring, Marek Behún, open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS, Linux LED Subsystem, linux-kernel, Linux ARM On Wed, Jul 22, 2020 at 5:32 PM Dan Murphy <dmurphy@ti.com> wrote: > The dependencies for the LP55XX LED drivers have been updated so that > the child devices (i.e. LP5521) now depends on the LP55XX_COMMON config > flag as opposed to the device selecting the LP55XX_COMMON flag. The > LP55XX_COMMON needs to be set in the defconfig. > > Signed-off-by: Dan Murphy <dmurphy@ti.com> OK then I guess you have good reasons to have it like this. Acked-by: Linus Walleij <linus.walleij@linaro.org> Yours, Linus Walleij ^ permalink raw reply [flat|nested] 23+ messages in thread
* [PATCH v32 4/6] ARM: dts: n900: Add reg property to the LP5523 channel node 2020-07-22 15:31 [PATCH v32 0/6] Multicolor Framework v32 Dan Murphy ` (2 preceding siblings ...) 2020-07-22 15:31 ` [PATCH v32 3/6] ARM: defconfig: u8500: Add LP55XX_COMMON config flag Dan Murphy @ 2020-07-22 15:31 ` Dan Murphy 2020-07-22 15:31 ` [PATCH v32 5/6] ARM: dts: imx6dl-yapp4: Add reg property to the lp5562 " Dan Murphy 2020-07-22 15:31 ` [PATCH v32 6/6] ARM: dts: ste-href: Add reg property to the LP5521 channel nodes Dan Murphy 5 siblings, 0 replies; 23+ messages in thread From: Dan Murphy @ 2020-07-22 15:31 UTC (permalink / raw) To: jacek.anaszewski, pavel, robh, marek.behun Cc: devicetree, linux-leds, linux-kernel, linux-arm-kernel, Dan Murphy, Tony Lindgren, Benoît Cousson Add the reg property to each channel node. This update is to accommodate the multicolor framework. In addition to the accommodation this allows the LEDs to be placed on any channel and allow designs to skip channels as opposed to requiring sequential order. Signed-off-by: Dan Murphy <dmurphy@ti.com> Acked-by: Tony Lindgren <tony@atomide.com> CC: Tony Lindgren <tony@atomide.com> CC: "Benoît Cousson" <bcousson@baylibre.com> Acked-by: Pavel Machek <pavel@ucw.cz> --- arch/arm/boot/dts/omap3-n900.dts | 29 ++++++++++++++++++++--------- 1 file changed, 20 insertions(+), 9 deletions(-) diff --git a/arch/arm/boot/dts/omap3-n900.dts b/arch/arm/boot/dts/omap3-n900.dts index 4089d97405c9..ebe93b06b4f7 100644 --- a/arch/arm/boot/dts/omap3-n900.dts +++ b/arch/arm/boot/dts/omap3-n900.dts @@ -618,63 +618,74 @@ indicator { }; lp5523: lp5523@32 { + #address-cells = <1>; + #size-cells = <0>; compatible = "national,lp5523"; reg = <0x32>; clock-mode = /bits/ 8 <0>; /* LP55XX_CLOCK_AUTO */ enable-gpio = <&gpio2 9 GPIO_ACTIVE_HIGH>; /* 41 */ - chan0 { + chan@0 { chan-name = "lp5523:kb1"; led-cur = /bits/ 8 <50>; max-cur = /bits/ 8 <100>; + reg = <0>; }; - chan1 { + chan@1 { chan-name = "lp5523:kb2"; led-cur = /bits/ 8 <50>; max-cur = /bits/ 8 <100>; + reg = <1>; }; - chan2 { + chan@2 { chan-name = "lp5523:kb3"; led-cur = /bits/ 8 <50>; max-cur = /bits/ 8 <100>; + reg = <2>; }; - chan3 { + chan@3 { chan-name = "lp5523:kb4"; led-cur = /bits/ 8 <50>; max-cur = /bits/ 8 <100>; + reg = <3>; }; - chan4 { + chan@4 { chan-name = "lp5523:b"; led-cur = /bits/ 8 <50>; max-cur = /bits/ 8 <100>; + reg = <4>; }; - chan5 { + chan@5 { chan-name = "lp5523:g"; led-cur = /bits/ 8 <50>; max-cur = /bits/ 8 <100>; + reg = <5>; }; - chan6 { + chan@6 { chan-name = "lp5523:r"; led-cur = /bits/ 8 <50>; max-cur = /bits/ 8 <100>; + reg = <6>; }; - chan7 { + chan@7 { chan-name = "lp5523:kb5"; led-cur = /bits/ 8 <50>; max-cur = /bits/ 8 <100>; + reg = <7>; }; - chan8 { + chan@8 { chan-name = "lp5523:kb6"; led-cur = /bits/ 8 <50>; max-cur = /bits/ 8 <100>; + reg = <8>; }; }; -- 2.27.0 ^ permalink raw reply related [flat|nested] 23+ messages in thread
* [PATCH v32 5/6] ARM: dts: imx6dl-yapp4: Add reg property to the lp5562 channel node 2020-07-22 15:31 [PATCH v32 0/6] Multicolor Framework v32 Dan Murphy ` (3 preceding siblings ...) 2020-07-22 15:31 ` [PATCH v32 4/6] ARM: dts: n900: Add reg property to the LP5523 channel node Dan Murphy @ 2020-07-22 15:31 ` Dan Murphy 2020-07-22 15:31 ` [PATCH v32 6/6] ARM: dts: ste-href: Add reg property to the LP5521 channel nodes Dan Murphy 5 siblings, 0 replies; 23+ messages in thread From: Dan Murphy @ 2020-07-22 15:31 UTC (permalink / raw) To: jacek.anaszewski, pavel, robh, marek.behun Cc: devicetree, linux-leds, linux-kernel, linux-arm-kernel, Dan Murphy, Shawn Guo, Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam, NXP Linux Team Add the reg property to each channel node. This update is to accommodate the multicolor framework. In addition to the accommodation this allows the LEDs to be placed on any channel and allow designs to skip channels as opposed to requiring sequential order. Acked-by: Pavel Machek <pavel@ucw.cz> Signed-off-by: Dan Murphy <dmurphy@ti.com> CC: Shawn Guo <shawnguo@kernel.org> CC: Sascha Hauer <s.hauer@pengutronix.de> CC: Pengutronix Kernel Team <kernel@pengutronix.de> CC: Fabio Estevam <festevam@gmail.com> CC: NXP Linux Team <linux-imx@nxp.com> --- arch/arm/boot/dts/imx6dl-yapp4-common.dtsi | 14 ++++++++++---- 1 file changed, 10 insertions(+), 4 deletions(-) diff --git a/arch/arm/boot/dts/imx6dl-yapp4-common.dtsi b/arch/arm/boot/dts/imx6dl-yapp4-common.dtsi index 2b9423d55c37..77aa90640052 100644 --- a/arch/arm/boot/dts/imx6dl-yapp4-common.dtsi +++ b/arch/arm/boot/dts/imx6dl-yapp4-common.dtsi @@ -258,29 +258,35 @@ leds: led-controller@30 { reg = <0x30>; clock-mode = /bits/ 8 <1>; status = "disabled"; + #address-cells = <1>; + #size-cells = <0>; - chan0 { + chan@0 { chan-name = "R"; led-cur = /bits/ 8 <0x20>; max-cur = /bits/ 8 <0x60>; + reg = <0>; }; - chan1 { + chan@1 { chan-name = "G"; led-cur = /bits/ 8 <0x20>; max-cur = /bits/ 8 <0x60>; + reg = <1>; }; - chan2 { + chan@2 { chan-name = "B"; led-cur = /bits/ 8 <0x20>; max-cur = /bits/ 8 <0x60>; + reg = <2>; }; - chan3 { + chan@3 { chan-name = "W"; led-cur = /bits/ 8 <0x0>; max-cur = /bits/ 8 <0x0>; + reg = <3>; }; }; -- 2.27.0 ^ permalink raw reply related [flat|nested] 23+ messages in thread
* [PATCH v32 6/6] ARM: dts: ste-href: Add reg property to the LP5521 channel nodes 2020-07-22 15:31 [PATCH v32 0/6] Multicolor Framework v32 Dan Murphy ` (4 preceding siblings ...) 2020-07-22 15:31 ` [PATCH v32 5/6] ARM: dts: imx6dl-yapp4: Add reg property to the lp5562 " Dan Murphy @ 2020-07-22 15:31 ` Dan Murphy 5 siblings, 0 replies; 23+ messages in thread From: Dan Murphy @ 2020-07-22 15:31 UTC (permalink / raw) To: jacek.anaszewski, pavel, robh, marek.behun Cc: devicetree, linux-leds, linux-kernel, linux-arm-kernel, Dan Murphy, Linus Walleij Add the reg property to each channel node. This update is to accommodate the multicolor framework. In addition to the accommodation this allows the LEDs to be placed on any channel and allow designs to skip channels as opposed to requiring sequential order. Signed-off-by: Dan Murphy <dmurphy@ti.com> CC: Linus Walleij <linus.walleij@linaro.org> Acked-by: Pavel Machek <pavel@ucw.cz> --- arch/arm/boot/dts/ste-href.dtsi | 22 ++++++++++++++++------ 1 file changed, 16 insertions(+), 6 deletions(-) diff --git a/arch/arm/boot/dts/ste-href.dtsi b/arch/arm/boot/dts/ste-href.dtsi index 33e3b0b3c53d..ff47cbf6ed3b 100644 --- a/arch/arm/boot/dts/ste-href.dtsi +++ b/arch/arm/boot/dts/ste-href.dtsi @@ -58,16 +58,21 @@ lp5521@33 { reg = <0x33>; label = "lp5521_pri"; clock-mode = /bits/ 8 <2>; - chan0 { + #address-cells = <1>; + #size-cells = <0>; + chan@0 { + reg = <0>; led-cur = /bits/ 8 <0x2f>; max-cur = /bits/ 8 <0x5f>; linux,default-trigger = "heartbeat"; }; - chan1 { + chan@1 { + reg = <1>; led-cur = /bits/ 8 <0x2f>; max-cur = /bits/ 8 <0x5f>; }; - chan2 { + chan@2 { + reg = <2>; led-cur = /bits/ 8 <0x2f>; max-cur = /bits/ 8 <0x5f>; }; @@ -77,15 +82,20 @@ lp5521@34 { reg = <0x34>; label = "lp5521_sec"; clock-mode = /bits/ 8 <2>; - chan0 { + #address-cells = <1>; + #size-cells = <0>; + chan@0 { + reg = <0>; led-cur = /bits/ 8 <0x2f>; max-cur = /bits/ 8 <0x5f>; }; - chan1 { + chan@1 { + reg = <1>; led-cur = /bits/ 8 <0x2f>; max-cur = /bits/ 8 <0x5f>; }; - chan2 { + chan@2 { + reg = <2>; led-cur = /bits/ 8 <0x2f>; max-cur = /bits/ 8 <0x5f>; }; -- 2.27.0 ^ permalink raw reply related [flat|nested] 23+ messages in thread
end of thread, other threads:[~2020-08-12 16:00 UTC | newest] Thread overview: 23+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2020-07-22 15:31 [PATCH v32 0/6] Multicolor Framework v32 Dan Murphy 2020-07-22 15:31 ` [PATCH v32 1/6] dt: bindings: lp50xx: Introduce the lp50xx family of RGB drivers Dan Murphy 2020-07-28 13:39 ` Dan Murphy 2020-08-04 19:55 ` Dan Murphy 2020-08-07 13:42 ` Dan Murphy 2020-08-11 10:32 ` Pavel Machek 2020-08-11 10:20 ` Pavel Machek 2020-08-11 17:07 ` Dan Murphy 2020-07-22 15:31 ` [PATCH v32 2/6] leds: lp50xx: Add the LP50XX family of the RGB LED driver Dan Murphy 2020-08-11 10:29 ` Pavel Machek 2020-08-11 10:31 ` Pavel Machek 2020-08-11 10:54 ` Pavel Machek 2020-08-11 17:27 ` Dan Murphy 2020-08-11 22:01 ` Pavel Machek 2020-08-11 22:16 ` Dan Murphy 2020-08-11 22:26 ` Pavel Machek 2020-08-12 16:00 ` Dan Murphy 2020-07-22 15:31 ` [PATCH v32 3/6] ARM: defconfig: u8500: Add LP55XX_COMMON config flag Dan Murphy 2020-07-28 13:38 ` Dan Murphy 2020-08-03 23:14 ` Linus Walleij 2020-07-22 15:31 ` [PATCH v32 4/6] ARM: dts: n900: Add reg property to the LP5523 channel node Dan Murphy 2020-07-22 15:31 ` [PATCH v32 5/6] ARM: dts: imx6dl-yapp4: Add reg property to the lp5562 " Dan Murphy 2020-07-22 15:31 ` [PATCH v32 6/6] ARM: dts: ste-href: Add reg property to the LP5521 channel nodes Dan Murphy
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).