2009/7/22 David Brownell <david-b@xxxxxxxxxxx>: > On Wednesday 22 July 2009, Arve Hjønnevåg wrote: >> It would also be useful to mask an edge triggered interrupt until the >> thread handler has finished. The touchscreen on the G1 is connected to >> an edge triggered interrupt, and the touchscreen may toggle the >> interrupt line while reading its registers. > > To clarify: if it does toggle, do you want that event to be > queued up so the IRQ is re-issued -- or not? That "oneshot" > mechanism does some of that, though it's for level triggers. For this driver yes the event should normally be queued up. If there is an error detected though, there is no need to queue up interrupts that are generated during the reinit. Also, if you implement a keypad matrix driver using a threaded interrupt handler, you will not want the interrupt to be re-issues unless it occured after the last key was released since the scan itself always generated more interrupts. This is not specific to threaded interrupt handlers though, and could be handled by adding a clear-interrupt function. > > Parts of that might be appropriate to handle in the threaded > IRQ handler itself. It seems a bit device-specific. Yes, the driver could request a threaded one-shot interrupt so that it will work when it is connected to a level triggered interrupt, and also call disable_interrupt/enable_interrrupt in the handler to avoid extra interrupts when it is connected to an edge triggered source. But, it would be nicer if requesting a one-shot interrupt always works. Also, waiting until the threaded handler runs before masking the interrupt would not work well if the interrupt line needs software debouncing. -- Arve Hjønnevåg -- To unsubscribe from this list: send the line "unsubscribe linux-input" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
