| Message ID | 20240611231435.10366-1-ansuelsmth@gmail.com |
|---|---|
| Headers | show |
| Series | misc: introduce STATUS LED activity function | expand |
On Wed, Jun 12, 2024 at 01:14:15AM +0200, Christian Marangi wrote: > This series expand the STATUS LED framework with a new color > and a big new feature. One thing that many device need is a way > to communicate to the user that the device is actually doing > something. > > This is especially useful for recovery steps where an > user (for example) insert an USB drive, keep a button pressed > and the device autorecover. > > There is currently no way to signal the user externally that > the bootloader is processing/recoverying aside from setting > a LED on. > > A solid LED on is not enough and won't actually signal any > kind of progress. > Solution is the good old blinking LED but uboot doesn't > suggest (and support) interrupts and almost all the LED > are usually GPIO LED that doesn't support HW blink. > > To fix this and handle the problem of device not supporting > HW blink, expand the STATUS LED framework with new API. > > We introduce a new config LED_STATUS_ACTIVITY, that similar > to the RED, GREEN and others, takes the LED ID set in > the LED_STATUS config and is used as the global LED for activity > operations. > > We add status_led_activity_start/stop() used to turn the > activity LED on and register a cyclic to make it blink. > LED will continue to blink until _stop() is called. > > Function that will start some kind of action will first call > _start() and then at the end will call stop(). > If (on the broken implementation) a _start() is called before > calling a _stop(), the Cyclic is first unregister and is > registered again. > > Support for this is initially added to the tftp, mtd and ubi > command. > > This also contains a big fixup for the gpio_led driver that > currently deviates from the Documentation and make the > coloured status led feature unusable. A number of platforms now fail to build: https://source.denx.de/u-boot/u-boot/-/jobs/854228#L1455 and please rebase on top of current next as well. To make world build testing easier you may wish to read over https://docs.u-boot.org/en/latest/develop/ci_testing.html but please note that there are sometimes spurious failures due to the cyclic framework and applying https://patchwork.ozlabs.org/project/uboot/patch/20240524210817.1953298-1-rasmus.villemoes@prevas.dk/ temporarily is likely the quickest path forward at this time.
On Wed, Jun 19, 2024 at 08:44:21AM -0600, Tom Rini wrote: > On Wed, Jun 12, 2024 at 01:14:15AM +0200, Christian Marangi wrote: > > > This series expand the STATUS LED framework with a new color > > and a big new feature. One thing that many device need is a way > > to communicate to the user that the device is actually doing > > something. > > > > This is especially useful for recovery steps where an > > user (for example) insert an USB drive, keep a button pressed > > and the device autorecover. > > > > There is currently no way to signal the user externally that > > the bootloader is processing/recoverying aside from setting > > a LED on. > > > > A solid LED on is not enough and won't actually signal any > > kind of progress. > > Solution is the good old blinking LED but uboot doesn't > > suggest (and support) interrupts and almost all the LED > > are usually GPIO LED that doesn't support HW blink. > > > > To fix this and handle the problem of device not supporting > > HW blink, expand the STATUS LED framework with new API. > > > > We introduce a new config LED_STATUS_ACTIVITY, that similar > > to the RED, GREEN and others, takes the LED ID set in > > the LED_STATUS config and is used as the global LED for activity > > operations. > > > > We add status_led_activity_start/stop() used to turn the > > activity LED on and register a cyclic to make it blink. > > LED will continue to blink until _stop() is called. > > > > Function that will start some kind of action will first call > > _start() and then at the end will call stop(). > > If (on the broken implementation) a _start() is called before > > calling a _stop(), the Cyclic is first unregister and is > > registered again. > > > > Support for this is initially added to the tftp, mtd and ubi > > command. > > > > This also contains a big fixup for the gpio_led driver that > > currently deviates from the Documentation and make the > > coloured status led feature unusable. > > A number of platforms now fail to build: > https://source.denx.de/u-boot/u-boot/-/jobs/854228#L1455 > and please rebase on top of current next as well. To make world build > testing easier you may wish to read over > https://docs.u-boot.org/en/latest/develop/ci_testing.html but please > note that there are sometimes spurious failures due to the cyclic > framework and applying > https://patchwork.ozlabs.org/project/uboot/patch/20240524210817.1953298-1-rasmus.villemoes@prevas.dk/ > temporarily is likely the quickest path forward at this time. > Hi Tom, no idea I had to target next. I just sent v4 (require moderation approval). I rebased the thing and fixed the errors catched by the azure pipeline. Hope the gitlab tests doesn't have additional target that I might have missed. I also had to use the suggested testing patch for the tests.
On Wed, 12 Jun 2024 at 03:33, Christian Marangi <ansuelsmth@gmail.com> wrote: > > This series expand the STATUS LED framework with a new color > and a big new feature. One thing that many device need is a way > to communicate to the user that the device is actually doing > something. > > This is especially useful for recovery steps where an > user (for example) insert an USB drive, keep a button pressed > and the device autorecover. > > There is currently no way to signal the user externally that > the bootloader is processing/recoverying aside from setting > a LED on. > > A solid LED on is not enough and won't actually signal any > kind of progress. > Solution is the good old blinking LED but uboot doesn't > suggest (and support) interrupts and almost all the LED > are usually GPIO LED that doesn't support HW blink. > > To fix this and handle the problem of device not supporting > HW blink, expand the STATUS LED framework with new API. > > We introduce a new config LED_STATUS_ACTIVITY, that similar > to the RED, GREEN and others, takes the LED ID set in > the LED_STATUS config and is used as the global LED for activity > operations. > > We add status_led_activity_start/stop() used to turn the > activity LED on and register a cyclic to make it blink. > LED will continue to blink until _stop() is called. > > Function that will start some kind of action will first call > _start() and then at the end will call stop(). > If (on the broken implementation) a _start() is called before > calling a _stop(), the Cyclic is first unregister and is > registered again. > > Support for this is initially added to the tftp, mtd and ubi > command. > > This also contains a big fixup for the gpio_led driver that > currently deviates from the Documentation and make the > coloured status led feature unusable. > > Changes v3: > - Add log on Status LED error conditions > Changes v2: > - Add Documentation conversion > - Rework to Cyclic and simplify implementation > > Christian Marangi (9): > misc: gpio_led: fix broken coloured LED status functions > led: status_led: add support for white LED colour > led: status_led: add function to toggle a status LED > led: status_led: add warning when an invalid Status LED ID is used > led: status_led: add new activity LED config and functions > tftp: implement support for LED status activity > mtd: implement support for LED status activity > ubi: implement support for LED status activity > doc: convert README.LED to .rst documentation > > cmd/legacy_led.c | 6 + > cmd/mtd.c | 19 ++++ > cmd/ubi.c | 15 ++- > common/board_f.c | 2 + > doc/README.LED | 77 ------------- > doc/api/index.rst | 1 + > doc/api/status_led.rst | 35 ++++++ > drivers/led/Kconfig | 30 +++++ > drivers/misc/gpio_led.c | 41 +++++-- Does it make sense to move misc/gpio_led.c to drivers/led as that's where the Kconfig is? > drivers/misc/status_led.c | 75 ++++++++++++- > include/status_led.h | 231 +++++++++++++++++++++++++++++++++++++- > net/tftp.c | 7 ++ > 12 files changed, 440 insertions(+), 99 deletions(-) > delete mode 100644 doc/README.LED > create mode 100644 doc/api/status_led.rst > > -- > 2.43.0 >