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.villem...@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.
--
Ansuel
