On 2/11/22 00:02, Simon Glass wrote:
Hi Marek,
On Thu, 10 Feb 2022 at 14:42, Marek Vasut <ma...@denx.de> wrote:
On 2/10/22 22:13, Thomas Watson wrote:
Using the XHCI driver, the function `usb_kbd_poll_for_event` takes
30-40ms to run. The exact time is dependent on the polling interval the
keyboard requests in its descriptor, and likely cannot be significantly
reduced without major rework to the XHCI driver.
The U-Boot EFI console service sets a timer to poll the keyboard every 5
microseconds, and this timer is checked every time a block is read off
disk. The net effect is that, on my system, loading a ~40MiB kernel and
initrd takes about 62 seconds with a slower keyboard and 53 seconds
with a faster one, with the vast majority of the time spent polling the
keyboard.
To solve this problem, this patch adds a 20ms delay between consecutive
calls to `usb_kbd_poll_for_event`. This is sufficient to reduce the
total loading time to under half a second for both keyboards, and does
not impact the perceived keystroke latency.
Signed-off-by: Thomas Watson <twatso...@icloud.com>
---
This revision fixes a sandbox test failure by honoring the test's
request to skip delays.
common/usb_kbd.c | 31 ++++++++++++++++++++++++++-----
1 file changed, 26 insertions(+), 5 deletions(-)
We don't want to delay the CI tests which take enough time as it is.
So time needs to be faked.
It could be an if() though, rather than #if, perhaps?
Since there are multiple instances of the ifdef already , subsequent
patch to clean them up would be fine.
