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-ra... 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.