[U-Boot] [PATCH v3 1/2] console: usbkbd: Improve TFTP booting performance

[Jim Lin <jilin@nvidia.com>]

On Fri, 2013-06-28 at 02:20 +0800, Stephen Warren wrote:
> 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.
In my case it takes about 95 ms on Tegra20 and Tegra114 for
usb_kbd_testc() to be called periodically.
So I set CONFIG_USBKB_TESTC_PERIOD to 100.
Like I said, if CONFIG_USBKB_TESTC_PERIOD ms < T < 1000 ms
we reduce polling (send command to USB keyboard to check is there
any key pressed) to every second.

> 
> 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?
To fix in usb_kbd_testc() is easier because this issue happens only when
USB keyboard is installed and CONFIG_USB_KEYBOARD is defined.

--
nvpublic