On 9/11/26 23:47, Marek Vasut wrote:
> 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 ?
Currently ctrlc() is called every 700ms
>
> How come this trips the watchdog timeout ? What is the watchdog timeout delay
> set to in your case ?
In our case, watchdog is set to 32 seconds on STM32MP157c-DK2.
For information, this patch is superseeded by
https://patchwork.ozlabs.org/project/uboot/patch/20260817-move_schedule_inside_sleep_thread-v1-2-0023194e8...@foss.st.com/
Patrice
