the PS/2 mouse problem
mail at morten-johansen.net
Tue Nov 11 05:03:53 PST 2003
Scott Long wrote:
> Bruce Evans wrote:
>> On Sat, 8 Nov 2003, Morten Johansen wrote:
>>> Scott Long wrote:
>>>> Bruce Evans wrote:
>>>>> [... possibly too much trimmed]
>>>> The problem here is that the keyboard controller driver tries to be too
>>>> smart. If it detects that the hardware FIFO is full, it'll drain it
>>>> a per-softc, per-function ring buffer. So having psm(4) just directly
>>>> read the hardware is insufficient in this scheme.
>> What is the per-function part? (I'm not very familar with psm, but once
>> understood simpler versions of the keyboard driver.) Several layers of
>> buffering might not be too bad for slow devices. The i/o times tend to
>> dominate unless you do silly things like a context switch to move each
>> character from one buffer to other, and even that can be fast enough
>> (I believe it is normal for interactive input on ptys; then there's often
>> a remote IPC or two per character as well).
> The atkbdc (keyboard controller, not keyboard) contains two 'kqueue'
> objects, one for the keyboard device and one for the 'aux' device.
> This 'kqueue' is a linked list of buffers for holding characters when
> the driver detects that the hardware FIFO is full. Unfortunately, it
> checks all over the place, and tends to check both the 'kbd' and 'aux'
> ports at the same time (the 'aux' port is for psm, presumably). So,
> this complicates the locking of psm quite a bit since it calls
> read_aux_data_no_wait() which looks at the aux kqueue and also services
> the keyboard queue at the same time.
> My gut feeling is that by making the kbd and psm drivers be INTR_FAST
> (or INTR_DIRECT as it should be called), there is little chance that the
> hardware fifo will overflow before the isr can run. The driver
> interrupt handlers can then have their own private queues with some
> simple locking or atomic lists that get serviced by a taskqueue.
> However, I'm not sure if my assumption is correct on very old hardware
> like 486/586 and old Alphas. Also, I'm unclear on whether you need
> to read the status register before reading the data register. Hanging
> out for 7us in the isr in order to do the back-to-back reads doesn't
> thrill me.
FWIW, this is what the Linux (2.6) driver does:
static inline int i8042_read_data(void)
static inline int i8042_read_status(void)
... and in the isr:
while (j < I8042_BUFFER_SIZE &&
(buffer[j].str = i8042_read_status()) & I8042_STR_OBF)
buffer[j++].data = i8042_read_data();
... this isr then figures out if it's kbd or aux data (based on status
register) and calls the appropriate "sub"-isr (i.e. ps/2) with the data.
There are noe delays as far as I can see.
Why did we need the delays? Can they be removed?
More information about the freebsd-current