| Message ID | 20220525074019.946607-1-sr@denx.de |
|---|---|
| Headers | show |
| Series | Add support for cyclic function execution infrastruture | expand |
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. Thanks, Stefan > Aaron Williams (1): > mips: octeon_nic23: Add PCIe FLR fixup via cyclic infrastructure > > Stefan Roese (6): > time: Import time_after64() and friends from Linux > cyclic: Add basic support for cyclic function execution infrastruture > cyclic: Integrate cyclic infrastructure into WATCHDOG_RESET > cyclic: Integrate cyclic functionality at bootup in board_r/f > cyclic: Add 'cyclic list' command > sandbox: Add cyclic demo function > > MAINTAINERS | 7 + > board/Marvell/octeon_nic23/board.c | 197 +++++++++++++++++++++++++++++ > board/sandbox/sandbox.c | 15 +++ > cmd/Kconfig | 6 + > cmd/Makefile | 1 + > cmd/cyclic.c | 40 ++++++ > common/Kconfig | 22 ++++ > common/Makefile | 1 + > common/board_f.c | 2 + > common/board_r.c | 2 + > common/cyclic.c | 112 ++++++++++++++++ > configs/octeon_nic23_defconfig | 3 + > configs/sandbox_defconfig | 2 + > fs/cramfs/uncompress.c | 2 +- > include/cyclic.h | 84 ++++++++++++ > include/time.h | 19 +++ > include/watchdog.h | 23 +++- > 17 files changed, 534 insertions(+), 4 deletions(-) > create mode 100644 cmd/cyclic.c > create mode 100644 common/cyclic.c > create mode 100644 include/cyclic.h > Viele Grüße, Stefan Roese
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: https://source.denx.de/u-boot/u-boot/-/jobs/471828