mirror of
https://xff.cz/git/u-boot/
synced 2025-10-31 10:26:10 +01:00
008c4b3c31
There are of course not a whole lot of examples in-tree yet, but
before they appear, let's make this API change: Instead of separately
allocating a 'struct cyclic_info', make the users embed such an
instance in their own structure, and make the convention that the
callback simply receives the 'struct cyclic_info *', from which the
clients can get their own data using the container_of() macro.
This has a number of advantages.
First, it means cyclic_register() simply cannot fail, simplifying the
code. The necessary storage will simply be allocated automatically
when the client's own structure is allocated (often via
uclass_priv_auto or similar).
Second, code for which CONFIG_CYCLIC is just an option can more easily
be written without #ifdefs, if we just provide an empty struct
cyclic_info {}. For example, the nested CONFIG_IS_ENABLED()s in
https://lore.kernel.org/u-boot/20240316201416.211480-1-marek.vasut+renesas@mailbox.org/
are mostly due to the existence of the 'struct cyclic_info *' member
being guarded by #ifdef CONFIG_CYCLIC.
And we do probably want to avoid the extra memory overhead of that
member when !CONFIG_CYCLIC. But that is automatic if, instead of a
'struct cyclic_info *', one simply embeds a 'struct cyclic_info',
which will have size 0 when !CONFIG_CYCLIC. Also, the no-op
cyclic_register() function can just unconditionally be called, and the
compiler will see that (1) the callback is referenced, so not emit a
warning for a maybe-unused function and (2) see that it can actually
never be reached, so not emit any code for it.
Reviewed-by: Stefan Roese <sr@denx.de>
Signed-off-by: Rasmus Villemoes <rasmus.villemoes@prevas.dk>
57 lines
1.9 KiB
ReStructuredText
57 lines
1.9 KiB
ReStructuredText
.. SPDX-License-Identifier: GPL-2.0+
|
|
|
|
Cyclic functions
|
|
================
|
|
|
|
The cyclic function execution infrastruture provides a way to periodically
|
|
execute code, e.g. every 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. To detect cyclic functions with an excessive execution
|
|
time, the Kconfig option `CONFIG_CYCLIC_MAX_CPU_TIME_US` was introduced.
|
|
It defines the maximum allowable execution time for such a cyclic function. The
|
|
first time the execution of a cyclic function exceeds this interval, a warning
|
|
will be displayed indicating the problem to the user.
|
|
|
|
Registering a cyclic function
|
|
-----------------------------
|
|
|
|
To register a cyclic function, use something like this::
|
|
|
|
struct donkey {
|
|
struct cyclic_info cyclic;
|
|
void (*say)(const char *s);
|
|
};
|
|
|
|
static void cyclic_demo(struct cyclic_info *c)
|
|
{
|
|
struct donkey *donkey = container_of(c, struct donkey, cyclic);
|
|
|
|
donkey->say("Are we there yet?");
|
|
}
|
|
|
|
int donkey_init(void)
|
|
{
|
|
struct donkey *donkey;
|
|
|
|
/* Initialize donkey ... */
|
|
|
|
/* Register demo cyclic function */
|
|
cyclic_register(&donkey->cyclic, cyclic_demo, 10 * 1000, "cyclic_demo");
|
|
|
|
return 0;
|
|
}
|
|
|
|
This will register the function `cyclic_demo()` to be periodically
|
|
executed all 10ms.
|
|
|
|
How is this cyclic functionality integrated / executed?
|
|
--------------------------------------------------------
|
|
|
|
The cyclic infrastructure 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.
|