[PATCH v3] console: usb: kbd: Limit poll frequency to improve performance

[Filip Žaludek]

On 2/8/23 20:01, Mark Kettenis wrote:
>> Date: Wed, 8 Feb 2023 19:45:36 +0100
>> From: Michal Suchánek <msuchanek at suse.de>
>>
>> Hello,
>>
>> On Wed, Jan 18, 2023 at 05:01:12PM +0100, Filip Žaludek wrote:
>>>
>>>
>>> Hi Michal,
>>>
>>>   thanks for testing! Do you consider keyboard as working once it is detected without
>>> 'usb_kbd usb_kbd: Timeout poll on interrupt endpoint', or judging from subsequent
>>> typing? Note that issue is reproducible only in about 20% of reboots.
>>
>> I rely on keyboard input to boot so if it was 20% broken I would notice.
>> I don't use the rPi all that much so if it was broken only a few
>> % of the time there is a chance I would miss it.
>>
>> However, for me not typing on the keyboard during usb detection it is
>> 100% not detected, typing on it during usb detection it is 100%
>> detected.
>>
>> The timeout is limitation of the dwc2 controller handling of usb hubs.
>>
>> There might be a possibility to improve the driver so that it handles
>> the condition but it might be that the Linux driver relies on a separate
>> thread handling the controller which is not acceptable for u-boot.
>>
>> I am not usb expert and definitely not dwc2 expert so I cannot do more
>> than workaround the current driver limitation.
>>
>>> For me I can always enter 'U-Boot>' shell, but then keyboard usually does not work.
>>> And yes, resetting the usb controller with pressing a key afterwards will
>>> finally break the keyboard. ('usb reset' typed from keyboard)
>>> If you are Prague located I am ready to demonstrate what I am talking about.
>>>
>>>   Simon's keyboard detection is somewhat interfered by 'SanDisk USB Extreme Pro' detection,
>>> printed complaints but keyboard still works..
>>> 'usb_kbd usb_kbd: Timeout poll on interrupt endpoint' and 'Failed to get keyboard state from device 0c40:8000'
>>> Btw. why from 0c40:8000 (ELMCU 2.4GHz receiver) when wired keyboard is 046d:c31c (Logitech Keyboard K120)?
>>>
>>>   What is supposed scenario for RPi3/u-boot/grub usb keyboard equipped users wanting to boot non-default?
>>> Enter 'U-Boot>' shell to detect keyboard; type boot; select desired grub entry..?
>>>
>>> Reverting either from the two makes it non issue for me:
>>> 'dwc2: use the nonblock argument in submit_int_msg'
>>> commit 9dcab2c4d2cb50ab1864c818b82a72393c160236
>>
>> Without this booting from USB is not feasible because reading every
>> block from the USB drive waits for the keyboard to time out.
>>
>>> 'console: usb: kbd: Limit poll frequency to improve performance'
>>> commit 96991e652f541323a03c5b7e075d54a117091618
>>
>> No idea about this one, for me it doea not give any substantial
>> difference in behavior.
> 
> Reverting that commit leads to a significant slowdown loading a kernel
> from disk with a usb keyboard connected.  The slowdown is somewhat
> hardware dependent but on some systems loading the OpenBSD/arm64
> kernel would take minutes instead of seconds.


Hello,
   I am about to dig more into this issue with proper tools, but failed to
configure/compile trace functionality on RPi3 due to missing references
to timer_early_get_count() and timer_early_get_rate().

  Is it possible/feasible to implement calls in CONFIG_SYS_ARCH_TIMER
and/or CONFIG_SP804_TIMER?

  I would be grateful even for trace to generate function traces without
timestamps. Is such nasty hack without timestamping supposed to work?
Basically my intention is to trace 'usb reset'.

Appreciate any hints/outlines how to proceed.


Kind regards,
Filip