From owner-freebsd-current@FreeBSD.ORG Tue Nov 11 05:03:52 2003 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C6C4D16A4CE; Tue, 11 Nov 2003 05:03:52 -0800 (PST) Received: from oslonett.no (imail.oslonett.no [194.234.215.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id AECCF43FEC; Tue, 11 Nov 2003 05:03:49 -0800 (PST) (envelope-from mail@morten-johansen.net) Received: from morten-johansen.net [213.234.112.58] by oslonett.no with ESMTP (SMTPD32-8.01) id AE2E33DE00F8; Tue, 11 Nov 2003 14:03:42 +0100 Message-ID: <3FB0DE2F.2090200@morten-johansen.net> Date: Tue, 11 Nov 2003 14:03:43 +0100 From: Morten Johansen User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.4) Gecko/20030817 X-Accept-Language: no, nb, en-us, en MIME-Version: 1.0 To: Scott Long 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> In-Reply-To: <3FB08453.8040300@freebsd.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Declude-Sender: mail@morten-johansen.net [213.234.112.58] X-Declude-Spoolname: Dde2e33de00f8b0dd.SMD X-Note: This E-mail was scanned by Declude JunkMail (www.declude.com) for spam. cc: freebsd-current@FreeBSD.org Subject: Re: the PS/2 mouse problem X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Nov 2003 13:03:53 -0000 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