Hi,
On 2/8/23 19:45, Michal Suchánek wrote:
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.
Common denominator here is most likely dwc2 controller on RPi3.
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.
There are 3 states:
Keyboard not detected, keyboard detected but does not work, keyboard detected
and works.
If keyboard is not detected/does not work then subsequent grub timeout is
misleading/pointless..
The timeout is limitation of the dwc2 controller handling of usb hubs.
Michal, can you please elaborate more [pointers to docs, discussions] why/how
is the timeout
limitation of the dwc2 controller handling of usb hubs?
I am trying to dissect it more by printing single character from myriad of
places what actually
works as a workaround, but when substituting with mdelay(x) exceeding printing
does not.
[common/usb.c, common/usb_hub.c, drivers/core/device.c,
drivers/usb/host/dwc2.c, drivers/usb/host/usb-uclass.c]
Thanks,
Filip
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.
Thanks
Michal
