Messages in this thread | | | Date | Fri, 3 Nov 2006 09:08:47 -0500 | From | "Dmitry Torokhov" <> | Subject | Re: [RFT/PATCH] i8042: remove polling timer (v6) |
| |
On 11/3/06, Vojtech Pavlik <vojtech@suse.cz> wrote: > On Fri, Nov 03, 2006 at 12:56:02AM -0500, Dmitry Torokhov wrote: > > On Monday 30 October 2006 09:22, Dave Neuer wrote: > > > On 10/30/06, Dave Neuer <mr.fred.smoothie@pobox.com> wrote: > > > > > > > > Maybe I'm missing something, (well actually I'm sure I'm missing > > > > somethng). Looking at the code again, it's unclear to me why there is > > > > even a call to the ISR in i8042_aux_write, since the latter function > > > > already calls i8042_read_data. > > > > > > > > > > Whoops, sorry. I meant i8042_command, which is called by > > > i8042_aux_write before the call to i8042_interrupt, already calls > > > i8042_read_data. > > > > > > > It only calls i8042_read_data() if command is supposed to return data. > > Neither I8042_CMD_AUX_SEND nor I8042_CMD_MUX_SEND wait fotr data to come > > back. > > > > Anyway, I removed call to i8042_interrupt() from i8042_aux_write() because > > it is indeed unnecessary. > > It was there because some older i8042's will report an error byte (=> > data) even though no device is connected, not just set error flags. > > The unflushed byte in the FIFO then caused problems later on. > > It may be that now it'll get disposed of correctly, I haven't looked at > the code for a while. >
By the time serio ports are registered and there are potential users of i8042_aux_write() we already requested AUX IRQ and I believe any arriving data should be automatically disposed through irq handler. It wasn't the case before, when we postponed requesting IRQ until the port was opened...
-- Dmitry - 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/
| |