Date: Tue, 11 Nov 2003 14:03:43 +0100 From: Morten Johansen <mail@morten-johansen.net> To: Scott Long <scottl@freebsd.org> Cc: freebsd-current@FreeBSD.org Subject: Re: the PS/2 mouse problem Message-ID: <3FB0DE2F.2090200@morten-johansen.net> In-Reply-To: <3FB08453.8040300@freebsd.org> References: <3FA966B2.9040704@morten-johansen.net> <20031105202947.A43448@pooker.samsco.home> <3FAA2CEB.6000403@morten-johansen.net> <3FAAF50B.9030105@morten-johansen.net> <20031107230107.O3769@gamplex.bde.org> <3FACB0DC.7020802@freebsd.org> <3FACEC1B.2040903@morten-johansen.net> <20031110205212.V2817@gamplex.bde.org> <3FB08453.8040300@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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
>>>> into
>>>> 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.
>
> Scott
>
FWIW, this is what the Linux (2.6) driver does:
static inline int i8042_read_data(void)
{
return inb(I8042_DATA_REG);
}
static inline int i8042_read_status(void)
{
return inb(I8042_STATUS_REG);
}
... 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?
Morten
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3FB0DE2F.2090200>