On 9/27/26 19:55, Marek Vasut wrote:
> On 9/25/26 6:17 PM, Patrice CHOTARD wrote:
>>
>>
>> On 9/17/26 16:26, Marek Vasut wrote:
>>> On 9/17/26 10:58 AM, Patrice Chotard wrote:
>>>> On STM32MP157C-DK2, when aborting the command "ums" using CTRL-C
>>>> it may take a while to get the control back on the console,
>>>> sometimes around 1 second.
>>>>
>>>> By removing the if (k == 10) test, it increases the CTRL+C responsiveness.
>>>>
>>>> Tested on STM32MP157C-DK board.
>>> I still have two questions:
>>>
>>> First, do you have actual timing figures here -- how long did it take from
>>> one ctrl_c() invocation to the next ctrl_c() invocation. Use e.g.
>>> get_timer_us() to time this.
>>>
>>> Second, does this increase in break condition checking impact throughput of
>>> the UMS ?
>>
>> Hi Marek
>>
>> Time between 2 ctrl_c() invocation is around 100us, way to fast in my
>> opinion.
>>
>> UMS throughput is slightly impacted :
>> before : 7.35 MB/s
>> after : 7.17 MB/s
>>
>> A better balance can be obtained with the following update :
>>
>> static int sleep_thread(struct fsg_common *common)
>> {
>> int rc = 0;
>> - int i = 0, k = 0;
>> + int i = 0;
>> /* Wait until a signal arrives or we are woken up */
>> for (;;) {
>> if (common->thread_wakeup_needed)
>> break;
>> if (++i == 20000) {
>> busy_indicator();
>> i = 0;
>> - k++;
>> - }
>> - if (k == 10) {
>> /* Handle START-STOP UNIT */
>> if (common->eject)
>> return -EPIPE;
>> /* Handle CTRL+C */
>> if (ctrlc())
>> return -EPIPE;
>> /* Check cable connection */
>> if (!g_dnl_board_usb_cable_connected())
>> return -EIO;
>> -
>> - k = 0;
>
> If k is not reset here, then the ++i==20000 above triggers only once ?
variable k is no more used, everything is triggered when ++i==20000.
>
>> }
>> schedule();
>> dm_usb_gadget_handle_interrupts(udcdev);
>> }
>>
>> Time between 2 ctrl_c() invocation is around 28ms.
>> UMS throughput is not impacted (still around 7.35 MB/s)
>>
>> I will send a v2.
>>
>> Patrice
>
>
