svn commit: r195960 - in head/sys/dev/usb: . controller input

Bruce Evans brde at optusnet.com.au
Mon Aug 3 17:46:32 UTC 2009


On Mon, 3 Aug 2009, M. Warner Losh wrote:

> In message: <200908030827.21108.hselasky at c2i.net>
> : I see two solutions:
> :
> : 1) Disable the timekeeping if no keys are pressed.
> :
> : 2) Second option is to use getmicrotime. Actually what I need is just a
> : millisecond time reference so I know when to repeat the last key.
> :
> : Any opinions? DELAY() or getmicrotime() ?

DELAY(1) is somewhet usable.

getmicrotime() is unusable because apart from the problems from it using
microtime() (actually binuptime()), getmicrotime() has is only updated
every 1/HZ seconds and depends on interrupts for the update.  1/HZ may
usefully be as high as 1/10 seconds, and the update would never occur
in ddb mode.

microtime() is not a supported API in ddb or panic mode, but it works
for short delays in most cases.  Short means however long it takes for
the hardware counter to wrap.  See another reply for more details.

binuptime() is better than microtime() for most purposes.  Another
problem with microtime() is that it is not guaranteed to be monotonic.

The patch using microtime() has mounds of style bugs (mainly an empty
line after almost every comment and statement).

> I'd note the state at each poll, and if > 1ms has passed since the
> down event, I'd repeat.  I wouldn't use DELAY at all to see if you
> needed to repeat: I'd let the clocking of the polling drive you here
> (eg, you know that someone else will call it a lot, so leverage that
> to avoid the delay).

Determining whether 1 mS has elapsed is not supported in ddb or panic
mode by any API, except microtime() usually works (see above).

For polled console input (not necessarily in ddb or panic mode).  It
shouldn't be necessary for the low-level driver to spin internally,
since cngetc() spins externally.  ddb mode is the only mode that
actually works almost right here: ddb disables all interrupts and stops
all other CPUs, so interrupts and other CPUs can't eat the input.
However, state changes to set up for polling, if any, should occur at
a higher level (on entry to ddb for ddb mode), not on every call to
cncheckc() or even on every call to cngetc().  The changes would be
device-specific and wouldn't depend on disabling all interrupts and
stopping all other CPUs.  Then all modes would work (of fail) similarly
to ddb mode.

Bruce


More information about the svn-src-head mailing list