[PATCH 0/7] Add support for cyclic function execution infrastruture

Tom Rini trini at konsulko.com
Tue Jul 26 00:00:09 CEST 2022

On Mon, Jul 25, 2022 at 10:39:11AM +0200, Stefan Roese wrote:
> Hi Tom,
> On 25.05.22 09:40, Stefan Roese wrote:
> > This patchset adds the basic infrastructure to periodically execute
> > code, e.g. all 100ms. Examples for such functions might be LED blinking
> > etc. The functions that are hooked into this cyclic list should be
> > small timewise as otherwise the execution of the other code that relies
> > on a high frequent polling (e.g. UART rx char ready check) might be
> > delayed too much. This patch also adds the Kconfig option
> > CONFIG_CYCLIC_MAX_CPU_TIME_US, which configures the max allowed time
> > for such a cyclic function. If it's execution time exceeds this time,
> > this cyclic function will get removed from the cyclic list.
> > 
> > How is this cyclic functionality executed?
> > This patchset integrates the main function responsible for calling all
> > registered cyclic functions cyclic_run() into the common WATCHDOG_RESET
> > macro. This guarantees that cyclic_run() is executed very often, which
> > is necessary for the cyclic functions to get scheduled and executed at
> > their configured periods.
> > 
> > This cyclic infrastructure will be used by a board specific function on
> > the NIC23 MIPS Octeon board, which needs to check periodically, if a
> > PCIe FLR has occurred.
> > 
> > Ideas how to continue:
> > One idea is to rename WATCHDOG_RESET to something like SCHEDULE and
> > move the watchdog_reset call into this cyclic infrastructure as well.
> > Or to perhaps move the shell UART RX ready polling to a cyclic
> > function.
> > 
> > It's also possible to extend the "cyclic" command, to support the
> > creation of periodically executed shell commands (for testing etc).
> > 
> > Thanks,
> > Stefan
> Tom, did you find the time to take a look at this series? What are
> you ideas / plans with it? I would very much like to get it merged
> as one of it's pro's is, providing the base for bigger cleanups in
> the current WATCHDOG_RESET mess in U-Boot at some time.

Sorry, I had intended to chime in sooner.  Conceptually, OK, lets see
where this takes us.  Implementation-wise, this fails to build on
sandbox_spl and maybe others:

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 659 bytes
Desc: not available
URL: <https://lists.denx.de/pipermail/u-boot/attachments/20220725/051ac0c9/attachment.sig>

More information about the U-Boot mailing list