Date: Mon, 11 Sep 1995 17:57:23 +1000 From: Bruce Evans <bde@zeta.org.au> To: hosokawa@mt.cs.keio.ac.jp, sos@FreeBSD.org Cc: freebsd-hackers@FreeBSD.org Subject: Re: Are DELAY()'s of keyboard driver insufficient?? Message-ID: <199509110757.RAA01864@godzilla.zeta.org.au>
next in thread | raw e-mail | index | archive | help
>Hmm, it almost sounds as if our DELAY() function is not stable on >fast hardware ?? DELAY(n) only delays for (n - 20) us on infinitely fast hardware. >Anyway I have no problem with raising the delays, I just would like >to know why ?? I have problems with them. 1) They shouldn't be used on multi-tasking systems except for initialization. kbd_cmd() previously could busy-wait for up to 5 seconds. Increasing the delays by a factor of 10 without adjusting the retry counts would allow it to wait up to 50 seconds (less on infinitely fast hardware :-). Commands should be given by using timeouts if necessary to wait for previous commands to finish and the command results should be read asynchronously like ordinary keystrokes. Only pccngetc() should poll. 2) Some delays are missing or in the wrong place. I think the spec is a 7 us delay between reading the status register and reading the data register. This is clearly implemented in pcvt and in the syscons reset code, but in syscons there is no delay for reading ordinary keystrokes in scgetc(). The first time after entering the interrupt handler there is less likely to be a problem because it takes several us to enter the interrupt handler. Looping may cause problems. The problem is also reduced by the loop beginning with a bogus (?) call to kbd_wait(). kbd_wait() is related to doing output and seems to be being used only for its side effects here. I don't know if a similar delay is required for output. There isn't one, because kbd_wait() returns immediately after reading a ready status and kbd_cmd() doesn't delay any more before doing the output. Bruce
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199509110757.RAA01864>