| Message ID | 20240616215226.2112-1-ansuelsmth@gmail.com |
|---|---|
| Headers | show |
| Series | leds: leds-lp55xx: overhaul driver | expand |
On Thu, Jun 20, 2024 at 05:09:07PM +0100, Lee Jones wrote: > On Sun, 16 Jun 2024, Christian Marangi wrote: > > > This long series is (as requested) a big overhaul of the lp55xx based > > LED driver. > > > > As notice for these kind of LED chip there was the bad habit of copy > > the old driver and just modify it enough to make it work with the new > > model. Till v4 I was also doing the same by following the pattern and > > the code format of previous driver. > > > > Since Lee didn't like this, here is the BIG series that generalize > > pretty much anything in the 4 model currently supported. > > > > Indeed, although the LED chip have fundamental difference (page > > support), things can be generalized and produce slimmer drivers by > > putting everything in the lp55xx-common shared module. > > > > This result in the new model lp5569 being very small with only the > > selftest portion to be custom. > > > > Lee also wasn't clear by the meaning of ENGINE in these LED driver, > > so here some simple explaination. This is very common on these TI LED > > chip. The ENGINE (there are always 3) is just some kind of processor > > that execute a program (precompiled code ASM like) loaded in the SRAM. > > Sysfs is used to load the pattern, and to start and stop the engine. > > > > These pattern can do all kind of complex thing with LEDs. Old LED chip > > had 32bytes of space for the pattern but newer one (like lp5569) have > > pages and if correctly configured can have massive pattern. > > These pattern can do all kind of magic like loops that make the LED > > pulse, change color and all kind of stuff. > > > > (For Lee, sorry if you will have to repeat some review that I might > > have missed in the lp5569 driver) > > > > Changes v6: > > - Fix compilation warning for ret unused in read_poll_timeout > > (no idea why this is flagged only on some particular arch...) > > - Fix missing bitfield.h in lp55x-common.c (again it seems this > > header gets included in the flow if the arch use them or not...) > > Changes v5: > > - Big generalization patch > > - Rework lp5569 driver with new generalized functions > > - Drop all copyright header in lp5569 as the driver got reworked > > entirely and it's not based on previous one anymore. > > Changes v4: > > - Fix reported buffer overflow due to a copypaste error > > - Add comments to describe fw size logic > > Changes v3: > > - Add ACK tag to DT patch > > - Enlarge and support program size up to 128bytes > > Changes v2: > > - Add ACK tag to DT patch > > - Fix compilation error with target that doesn't > > include bitfield.h > > > > Christian Marangi (20): > > dt-bindings: leds-lp55xx: limit pwr-sel property to ti,lp8501 > > dt-bindings: leds-lp55xx: Add new ti,lp5569 compatible > > leds: leds-lp55xx: generalize stop_all_engine OP > > leds: leds-lp55xx: generalize probe/remove functions > > leds: leds-lp55xx: generalize load_engine function > > leds: leds-lp55xx: generalize load_engine_and_select_page function > > leds: leds-lp55xx: generalize run_engine function > > leds: leds-lp55xx: generalize update_program_memory function > > leds: leds-lp55xx: generalize firmware_loaded function > > leds: leds-lp55xx: generalize led_brightness function > > leds: leds-lp55xx: generalize multicolor_brightness function > > leds: leds-lp55xx: generalize set_led_current function > > leds: leds-lp55xx: generalize turn_off_channels function > > leds: leds-lp55xx: generalize stop_engine function > > leds: leds-lp55xx: generalize sysfs engine_load and engine_mode > > leds: leds-lp55xx: generalize sysfs engine_leds > > leds: leds-lp55xx: generalize sysfs master_fader > > leds: leds-lp55xx: support ENGINE program up to 128 bytes > > leds: leds-lp55xx: drop deprecated defines > > leds: leds-lp5569: Add support for Texas Instruments LP5569 > > > > .../devicetree/bindings/leds/leds-lp55xx.yaml | 11 + > > drivers/leds/Kconfig | 16 +- > > drivers/leds/Makefile | 1 + > > drivers/leds/leds-lp5521.c | 405 +--------- > > drivers/leds/leds-lp5523.c | 728 ++--------------- > > drivers/leds/leds-lp5562.c | 261 +------ > > drivers/leds/leds-lp5569.c | 542 +++++++++++++ > > drivers/leds/leds-lp55xx-common.c | 730 +++++++++++++++++- > > drivers/leds/leds-lp55xx-common.h | 133 +++- > > drivers/leds/leds-lp8501.c | 313 +------- > > 10 files changed, 1523 insertions(+), 1617 deletions(-) > > create mode 100644 drivers/leds/leds-lp5569.c > > Generally, I love it - what a difference! > > Couple of small things within the patches and few general points. > > * Ensure scripts/checkpatch.pl is happy before resubmitting. Eh I always run patch with checkpatch.pl --strict but this time is quite problematic to fix the single error for the complex macro. I will check what I can do but I think I'm really stretching the C precompiler there... That is really one of the very few case where error might be acceptable. If I manage to mute that error, it might result in very bad code... If you are referring to other warning and check just tell me. > * Please place my Suggested-by in all of the consolidation patches. Ok will add the suggested in all the generalization patch > * Subject titles should always match that of the subsystem > - In our case the first letter of the description should be uppercase Ok missed that. > > Thanks for doing this, it's great work. > > -- > Lee Jones [李琼斯]
On Thu, Jun 20, 2024 at 05:49:22PM +0100, Lee Jones wrote: > On Sun, 16 Jun 2024 23:51:59 +0200, Christian Marangi wrote: > > This long series is (as requested) a big overhaul of the lp55xx based > > LED driver. > > > > As notice for these kind of LED chip there was the bad habit of copy > > the old driver and just modify it enough to make it work with the new > > model. Till v4 I was also doing the same by following the pattern and > > the code format of previous driver. > > > > [...] > > Applied, thanks! Mh? What happen? I'm preparing v7 with the changes requested :( > > [01/20] dt-bindings: leds-lp55xx: limit pwr-sel property to ti,lp8501 > commit: 08a9d2e79140ea1b40c107ea4c025bb8b71aa4b5 > [02/20] dt-bindings: leds-lp55xx: Add new ti,lp5569 compatible > commit: 75e28e4b32dda36c4a015cf2f9c4955d9024234a > [03/20] leds: leds-lp55xx: generalize stop_all_engine OP > commit: e2176c637856cd206bf06b5bbba89b2cf45f7dca > [04/20] leds: leds-lp55xx: generalize probe/remove functions > (no commit info) > [05/20] leds: leds-lp55xx: generalize load_engine function > (no commit info) > [06/20] leds: leds-lp55xx: generalize load_engine_and_select_page function > (no commit info) > [07/20] leds: leds-lp55xx: generalize run_engine function > (no commit info) > [08/20] leds: leds-lp55xx: generalize update_program_memory function > (no commit info) > [09/20] leds: leds-lp55xx: generalize firmware_loaded function > (no commit info) > [10/20] leds: leds-lp55xx: generalize led_brightness function > (no commit info) > [11/20] leds: leds-lp55xx: generalize multicolor_brightness function > (no commit info) > [12/20] leds: leds-lp55xx: generalize set_led_current function > (no commit info) > [13/20] leds: leds-lp55xx: generalize turn_off_channels function > (no commit info) > [14/20] leds: leds-lp55xx: generalize stop_engine function > (no commit info) > [15/20] leds: leds-lp55xx: generalize sysfs engine_load and engine_mode > (no commit info) > [16/20] leds: leds-lp55xx: generalize sysfs engine_leds > (no commit info) > [17/20] leds: leds-lp55xx: generalize sysfs master_fader > (no commit info) > [18/20] leds: leds-lp55xx: support ENGINE program up to 128 bytes > (no commit info) > [19/20] leds: leds-lp55xx: drop deprecated defines > (no commit info) > [20/20] leds: leds-lp5569: Add support for Texas Instruments LP5569 > (no commit info) > > -- > Lee Jones [李琼斯] >
On Sun, 16 Jun 2024, Christian Marangi wrote: > This long series is (as requested) a big overhaul of the lp55xx based > LED driver. > > As notice for these kind of LED chip there was the bad habit of copy > the old driver and just modify it enough to make it work with the new > model. Till v4 I was also doing the same by following the pattern and > the code format of previous driver. > > Since Lee didn't like this, here is the BIG series that generalize > pretty much anything in the 4 model currently supported. > > Indeed, although the LED chip have fundamental difference (page > support), things can be generalized and produce slimmer drivers by > putting everything in the lp55xx-common shared module. > > This result in the new model lp5569 being very small with only the > selftest portion to be custom. > > Lee also wasn't clear by the meaning of ENGINE in these LED driver, > so here some simple explaination. This is very common on these TI LED > chip. The ENGINE (there are always 3) is just some kind of processor > that execute a program (precompiled code ASM like) loaded in the SRAM. > Sysfs is used to load the pattern, and to start and stop the engine. > > These pattern can do all kind of complex thing with LEDs. Old LED chip > had 32bytes of space for the pattern but newer one (like lp5569) have > pages and if correctly configured can have massive pattern. > These pattern can do all kind of magic like loops that make the LED > pulse, change color and all kind of stuff. > > (For Lee, sorry if you will have to repeat some review that I might > have missed in the lp5569 driver) > > Changes v6: > - Fix compilation warning for ret unused in read_poll_timeout > (no idea why this is flagged only on some particular arch...) > - Fix missing bitfield.h in lp55x-common.c (again it seems this > header gets included in the flow if the arch use them or not...) > Changes v5: > - Big generalization patch > - Rework lp5569 driver with new generalized functions > - Drop all copyright header in lp5569 as the driver got reworked > entirely and it's not based on previous one anymore. > Changes v4: > - Fix reported buffer overflow due to a copypaste error > - Add comments to describe fw size logic > Changes v3: > - Add ACK tag to DT patch > - Enlarge and support program size up to 128bytes > Changes v2: > - Add ACK tag to DT patch > - Fix compilation error with target that doesn't > include bitfield.h > > Christian Marangi (20): > dt-bindings: leds-lp55xx: limit pwr-sel property to ti,lp8501 > dt-bindings: leds-lp55xx: Add new ti,lp5569 compatible > leds: leds-lp55xx: generalize stop_all_engine OP > leds: leds-lp55xx: generalize probe/remove functions > leds: leds-lp55xx: generalize load_engine function > leds: leds-lp55xx: generalize load_engine_and_select_page function > leds: leds-lp55xx: generalize run_engine function > leds: leds-lp55xx: generalize update_program_memory function > leds: leds-lp55xx: generalize firmware_loaded function > leds: leds-lp55xx: generalize led_brightness function > leds: leds-lp55xx: generalize multicolor_brightness function > leds: leds-lp55xx: generalize set_led_current function > leds: leds-lp55xx: generalize turn_off_channels function > leds: leds-lp55xx: generalize stop_engine function > leds: leds-lp55xx: generalize sysfs engine_load and engine_mode > leds: leds-lp55xx: generalize sysfs engine_leds > leds: leds-lp55xx: generalize sysfs master_fader > leds: leds-lp55xx: support ENGINE program up to 128 bytes > leds: leds-lp55xx: drop deprecated defines > leds: leds-lp5569: Add support for Texas Instruments LP5569 > > .../devicetree/bindings/leds/leds-lp55xx.yaml | 11 + > drivers/leds/Kconfig | 16 +- > drivers/leds/Makefile | 1 + > drivers/leds/leds-lp5521.c | 405 +--------- > drivers/leds/leds-lp5523.c | 728 ++--------------- > drivers/leds/leds-lp5562.c | 261 +------ > drivers/leds/leds-lp5569.c | 542 +++++++++++++ > drivers/leds/leds-lp55xx-common.c | 730 +++++++++++++++++- > drivers/leds/leds-lp55xx-common.h | 133 +++- > drivers/leds/leds-lp8501.c | 313 +------- > 10 files changed, 1523 insertions(+), 1617 deletions(-) > create mode 100644 drivers/leds/leds-lp5569.c Generally, I love it - what a difference! Couple of small things within the patches and few general points. * Ensure scripts/checkpatch.pl is happy before resubmitting. * Please place my Suggested-by in all of the consolidation patches. * Subject titles should always match that of the subsystem - In our case the first letter of the description should be uppercase Thanks for doing this, it's great work.
On Sun, 16 Jun 2024 23:51:59 +0200, Christian Marangi wrote: > This long series is (as requested) a big overhaul of the lp55xx based > LED driver. > > As notice for these kind of LED chip there was the bad habit of copy > the old driver and just modify it enough to make it work with the new > model. Till v4 I was also doing the same by following the pattern and > the code format of previous driver. > > [...] Applied, thanks! [01/20] dt-bindings: leds-lp55xx: limit pwr-sel property to ti,lp8501 commit: 08a9d2e79140ea1b40c107ea4c025bb8b71aa4b5 [02/20] dt-bindings: leds-lp55xx: Add new ti,lp5569 compatible commit: 75e28e4b32dda36c4a015cf2f9c4955d9024234a [03/20] leds: leds-lp55xx: generalize stop_all_engine OP commit: e2176c637856cd206bf06b5bbba89b2cf45f7dca [04/20] leds: leds-lp55xx: generalize probe/remove functions (no commit info) [05/20] leds: leds-lp55xx: generalize load_engine function (no commit info) [06/20] leds: leds-lp55xx: generalize load_engine_and_select_page function (no commit info) [07/20] leds: leds-lp55xx: generalize run_engine function (no commit info) [08/20] leds: leds-lp55xx: generalize update_program_memory function (no commit info) [09/20] leds: leds-lp55xx: generalize firmware_loaded function (no commit info) [10/20] leds: leds-lp55xx: generalize led_brightness function (no commit info) [11/20] leds: leds-lp55xx: generalize multicolor_brightness function (no commit info) [12/20] leds: leds-lp55xx: generalize set_led_current function (no commit info) [13/20] leds: leds-lp55xx: generalize turn_off_channels function (no commit info) [14/20] leds: leds-lp55xx: generalize stop_engine function (no commit info) [15/20] leds: leds-lp55xx: generalize sysfs engine_load and engine_mode (no commit info) [16/20] leds: leds-lp55xx: generalize sysfs engine_leds (no commit info) [17/20] leds: leds-lp55xx: generalize sysfs master_fader (no commit info) [18/20] leds: leds-lp55xx: support ENGINE program up to 128 bytes (no commit info) [19/20] leds: leds-lp55xx: drop deprecated defines (no commit info) [20/20] leds: leds-lp5569: Add support for Texas Instruments LP5569 (no commit info) -- Lee Jones [李琼斯]
On Thu, 20 Jun 2024, Christian Marangi wrote: > On Thu, Jun 20, 2024 at 05:09:07PM +0100, Lee Jones wrote: > > On Sun, 16 Jun 2024, Christian Marangi wrote: > > > > > This long series is (as requested) a big overhaul of the lp55xx based > > > LED driver. > > > > > > As notice for these kind of LED chip there was the bad habit of copy > > > the old driver and just modify it enough to make it work with the new > > > model. Till v4 I was also doing the same by following the pattern and > > > the code format of previous driver. > > > > > > Since Lee didn't like this, here is the BIG series that generalize > > > pretty much anything in the 4 model currently supported. > > > > > > Indeed, although the LED chip have fundamental difference (page > > > support), things can be generalized and produce slimmer drivers by > > > putting everything in the lp55xx-common shared module. > > > > > > This result in the new model lp5569 being very small with only the > > > selftest portion to be custom. > > > > > > Lee also wasn't clear by the meaning of ENGINE in these LED driver, > > > so here some simple explaination. This is very common on these TI LED > > > chip. The ENGINE (there are always 3) is just some kind of processor > > > that execute a program (precompiled code ASM like) loaded in the SRAM. > > > Sysfs is used to load the pattern, and to start and stop the engine. > > > > > > These pattern can do all kind of complex thing with LEDs. Old LED chip > > > had 32bytes of space for the pattern but newer one (like lp5569) have > > > pages and if correctly configured can have massive pattern. > > > These pattern can do all kind of magic like loops that make the LED > > > pulse, change color and all kind of stuff. > > > > > > (For Lee, sorry if you will have to repeat some review that I might > > > have missed in the lp5569 driver) > > > > > > Changes v6: > > > - Fix compilation warning for ret unused in read_poll_timeout > > > (no idea why this is flagged only on some particular arch...) > > > - Fix missing bitfield.h in lp55x-common.c (again it seems this > > > header gets included in the flow if the arch use them or not...) > > > Changes v5: > > > - Big generalization patch > > > - Rework lp5569 driver with new generalized functions > > > - Drop all copyright header in lp5569 as the driver got reworked > > > entirely and it's not based on previous one anymore. > > > Changes v4: > > > - Fix reported buffer overflow due to a copypaste error > > > - Add comments to describe fw size logic > > > Changes v3: > > > - Add ACK tag to DT patch > > > - Enlarge and support program size up to 128bytes > > > Changes v2: > > > - Add ACK tag to DT patch > > > - Fix compilation error with target that doesn't > > > include bitfield.h > > > > > > Christian Marangi (20): > > > dt-bindings: leds-lp55xx: limit pwr-sel property to ti,lp8501 > > > dt-bindings: leds-lp55xx: Add new ti,lp5569 compatible > > > leds: leds-lp55xx: generalize stop_all_engine OP > > > leds: leds-lp55xx: generalize probe/remove functions > > > leds: leds-lp55xx: generalize load_engine function > > > leds: leds-lp55xx: generalize load_engine_and_select_page function > > > leds: leds-lp55xx: generalize run_engine function > > > leds: leds-lp55xx: generalize update_program_memory function > > > leds: leds-lp55xx: generalize firmware_loaded function > > > leds: leds-lp55xx: generalize led_brightness function > > > leds: leds-lp55xx: generalize multicolor_brightness function > > > leds: leds-lp55xx: generalize set_led_current function > > > leds: leds-lp55xx: generalize turn_off_channels function > > > leds: leds-lp55xx: generalize stop_engine function > > > leds: leds-lp55xx: generalize sysfs engine_load and engine_mode > > > leds: leds-lp55xx: generalize sysfs engine_leds > > > leds: leds-lp55xx: generalize sysfs master_fader > > > leds: leds-lp55xx: support ENGINE program up to 128 bytes > > > leds: leds-lp55xx: drop deprecated defines > > > leds: leds-lp5569: Add support for Texas Instruments LP5569 > > > > > > .../devicetree/bindings/leds/leds-lp55xx.yaml | 11 + > > > drivers/leds/Kconfig | 16 +- > > > drivers/leds/Makefile | 1 + > > > drivers/leds/leds-lp5521.c | 405 +--------- > > > drivers/leds/leds-lp5523.c | 728 ++--------------- > > > drivers/leds/leds-lp5562.c | 261 +------ > > > drivers/leds/leds-lp5569.c | 542 +++++++++++++ > > > drivers/leds/leds-lp55xx-common.c | 730 +++++++++++++++++- > > > drivers/leds/leds-lp55xx-common.h | 133 +++- > > > drivers/leds/leds-lp8501.c | 313 +------- > > > 10 files changed, 1523 insertions(+), 1617 deletions(-) > > > create mode 100644 drivers/leds/leds-lp5569.c > > > > Generally, I love it - what a difference! > > > > Couple of small things within the patches and few general points. > > > > * Ensure scripts/checkpatch.pl is happy before resubmitting. > > Eh I always run patch with checkpatch.pl --strict but this time is quite > problematic to fix the single error for the complex macro. > > I will check what I can do but I think I'm really stretching the C > precompiler there... That is really one of the very few case where error > might be acceptable. > > If I manage to mute that error, it might result in very bad code... Just do whatever you think is the right thing and we'll roll with it.
On Thu, 20 Jun 2024, Christian Marangi wrote: > On Thu, Jun 20, 2024 at 05:49:22PM +0100, Lee Jones wrote: > > On Sun, 16 Jun 2024 23:51:59 +0200, Christian Marangi wrote: > > > This long series is (as requested) a big overhaul of the lp55xx based > > > LED driver. > > > > > > As notice for these kind of LED chip there was the bad habit of copy > > > the old driver and just modify it enough to make it work with the new > > > model. Till v4 I was also doing the same by following the pattern and > > > the code format of previous driver. > > > > > > [...] > > > > Applied, thanks! > > Mh? What happen? I'm preparing v7 with the changes requested :( Tooling issue, please ignore.