On 9/11/26 7:40 PM, Patrice CHOTARD wrote:
On 9/9/26 04:38, Marek Vasut wrote:
On 8/18/26 10:52 AM, Patrice CHOTARD wrote:
Hello Patrice,
Yes, It's possible to optimize schedule() call.
Since commit 4b6a3e860878 ("usb: gadget: f_mass_storage: Add schedule() in
sleep_thread()")
schedule is called on every for() loop iteration.
Schedule() can be called only if needed, ie if
g_dnl_board_usb_cable_connected() is not overloaded.
I well send a patch for this.
My question is, whether it is possible for the schedule() call to determine
whether or not it has to do (a lot of, lengthy, expensive) work or not, instead
of patching the USB stack.
To remind you, initially, it was to avoid a watchdog timeout in case
g_dnl_board_usb_cable_connected()
is not overloaded and no USB cable plugged.
As now watchdog is managed by schedule(), we have no choice to call schedule()
to ensure watchdog's reset.
even if schedule performs other cyclic things (led blinking, card detect,
video_sync....).
Recently schedule() has already been optimized (more precisely cyclic_run()),
currently i didn't see any
better optimization.
The schedule() call should be effectively a no-op in case the next event is not
yet due (whatever that next event is), so what does take so long in schedule()
that it takes so long (70ms) to complete ?
Hi Marek
schedule() execution doesn't takes 70ms.
Moving schedule() from main loop to same level that ctrlc(), it allows to call
ctrlc() every ~70ms.
In the current state, the ctrlc() is called every ... how many ... ms ?
How come this trips the watchdog timeout ? What is the watchdog timeout
delay set to in your case ?
