Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S264314AbUASW0G (ORCPT ); Mon, 19 Jan 2004 17:26:06 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S264391AbUASW0F (ORCPT ); Mon, 19 Jan 2004 17:26:05 -0500 Received: from twilight.ucw.cz ([81.30.235.3]:3456 "EHLO midnight.ucw.cz") by vger.kernel.org with ESMTP id S264314AbUASWZ6 (ORCPT ); Mon, 19 Jan 2004 17:25:58 -0500 Date: Mon, 19 Jan 2004 23:25:55 +0100 From: Vojtech Pavlik To: Peter Berg Larsen Cc: Gunter =?iso-8859-1?Q?K=F6nigsmann?= , linux-kernel@vger.kernel.org, Dmitry Torokhov Subject: Re: Synaptics Touchpad workaround for strange behavior after Sync loss (With Patch). Message-ID: <20040119222555.GA589@ucw.cz> References: <20040111081046.GA25497@ucw.cz> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.1i Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2235 Lines: 52 On Sun, Jan 11, 2004 at 01:46:41PM +0100, Peter Berg Larsen wrote: > > On Sun, 11 Jan 2004, Vojtech Pavlik wrote: > > > > I dont have a machine with active multiplexing so the the patch is > > > untested. It warns when the mouse is removed, and tries to recover > > > if multiplexing is disabled. > > > > It's nice, but er definitely shouldn't call i8042_enable_mux() from the > > interrupt handler, because i8042_command() waits for characters arriving > > in the interrupt handler, so we could get into rather nasty recursions. > > Are you sure? The i8042_command does spin_lock_irqsave(&i8042_lock, > flags), i8042_wait_read, i8042_read_data and unlock. It seems a good place > for me as the 8042s buffer is just flush by the interrupt. Well except for > the fact it is in the interrupt handler :) You're right, it's quite safe, but still not very nice, since the lock fortunately isn't held at the time we would call i8042_command. However, since i8042_command doesn't disable interrupts globally (only locally), an interrupt generated by the controller when it acks our command still can happen on a second CPU. It'll spin on the lock, though. > I cannot see a simple/fast solution: All data read in the interrupt must > be processed otherwise kbd data might be lost. I dont want > I8042_BUFFER_SIZE calls to serio_rescan/reconnect, as serio is not smart > enought to only do it once. Check my current version at bk://kernel.bkbits.net/vojtech/input, there isn't I8042_BUFFER_SIZE cycle in the interrupt routine anymore. > The mux port number(s) must be remembered if > serio is called after the loop. I dont like any further calls to > i8042_flush as it troughs away both kbd and aux data. > > hmm, I actually want the handler to look something like: > > if (str & I8042_STR_MUXERR) > i8042_handle_aux_data > else > i8042_handle_kbd_data > > That way i8042_flush can call handle_*_data depending on what to flush. -- Vojtech Pavlik SuSE Labs, SuSE CR - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/