> Date: Wed, 8 Feb 2023 19:45:36 +0100 > From: Michal Suchánek <msucha...@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.