Re: [RFC/RFT] Remove polling timer from i8042

[Vojtech Pavlik <vojtech@suse.cz>]

On Fri, Jul 28, 2006 at 10:20:00AM -0400, Dmitry Torokhov wrote:
> On 7/28/06, Vojtech Pavlik <vojtech@suse.cz> wrote:
> >On Fri, Jul 28, 2006 at 08:57:31AM -0400, Dmitry Torokhov wrote:
> >
> >> On 7/27/06, Vojtech Pavlik <vojtech@suse.cz> wrote:
> >> >On Thu, Jul 27, 2006 at 12:29:04AM -0400, Dmitry Torokhov wrote:
> >> >> Hi,
> >> >>
> >> >> OK, I had it in works for quite some time and Dave's talk in Ottawa
> >> >> made me finish it ;)
> >> >
> >> >Good work.
> >> >
> >> >However I believe you need to test the AUX IRQ in this case before you
> >> >use it, otherwise you'll have a lot of people with non-working keyboards
> >> >(the input queue is shared), and probably also non-working PCI cards
> >> >(BIOSes like to assign IRQ12 to PCI if no mouse is detected by the
> >> >BIOS).
> >> >
> >>
> >> What do you mean by testing AUX IRQ? Use I8042_CMD_AUX_LOOP to see if
> >> interrupt fires off? The new code releases IRQ if it can't find a
> >> working AUX port...
> >
> >Exactly. Not that a character arrives and can be polled for, but that
> >the interrupt actually gets raised. It can be routed to nowhere and
> >we'll never know, our buffers will be full and keyboard will be stuck.
> >
> 
> Riiiight. OK, I'll add this check - should be simple enough if we just
> have interrupt handler set a flag when it sees AUX irq and have
> probing code sleep for a 1/4 of a second in 50 msec intervals to see
> if the flag was set. Don't want to use completion in main IRQ
> handler... Or do you think it is better to initially register
> i8042_aux_test_irq() that would signal completion and after successful
> testing for IRQ delivery free_irq/request_irq with normal handler?
> Tooo bad we don't have replace_irq...
 
I would go for the second option. Regarding the missing replace_irq(),
it's not a big deal for us - if the second request_irq() fails, we want
to bail out anyway.

-- 
Vojtech Pavlik
Director SuSE Labs