On 06/27/2013 03:45 AM, Jim Lin wrote:
TFTP booting is observed a little bit slow, especially when a USB keyboard is installed. The fix is to move polling to every second if we sense that other task like TFTP boot is running.
diff --git a/common/usb_kbd.c b/common/usb_kbd.c
+#ifdef CONFIG_USBKB_TESTC_PERIOD
- /*
* T is the time between two calls of usb_kbd_testc().* If CONFIG_USBKB_TESTC_PERIOD ms < T < 1000 ms,* it implies other task like TFTP boot is running,* then we reduce polling to every second* to improve TFTP booting performance.*/- if ((get_timer(kbd_testc_tms) >=
(CONFIG_USBKB_TESTC_PERIOD * CONFIG_SYS_HZ / 1000)) &&(get_timer(kbd_testc_tms) < CONFIG_SYS_HZ))return 0;- else
kbd_testc_tms = get_timer(0);+#endif
I have a hard time understanding why the fact that "some other task is running" implies anything at all re: how often usb_kbd_testc() would be called.
It's quite possible that "some other task" is extremely fine-grained, and calls usb_kbd_testc() every 0.1ms, and would be severely negatively affected by usb_kbd_testc() taking a long time to execute.
Conversly, it's quite possible that "some other task" is quite granular, and calls usb_kbd_testc() a wide intervals, say every 200ms.
So, I think this change keys of entirely the wrong thing.
Shouldn't the TFTP process (or use of USB networking?) or other long-running tasks that do check for keyboard IO simply set some flag to indicate to usb_kbd_testc() that it should run at a reduced rate, or even just have those long-running processses call usb_kbd_testc() at a reduced rate themselves?