On Wed, Dec 9, 2009 at 9:58 AM, Dmitry Torokhov <dmitry.torokhov@xxxxxxxxx> wrote: > On Wed, Dec 09, 2009 at 08:15:26AM -0800, Cory Maccarrone wrote: >> On Wed, Dec 9, 2009 at 3:32 AM, Ferenc Wagner <wferi@xxxxxxx> wrote: >> >> I'm fairly certain it wouldn't. Each of the interrupts on my hardware >> has a corresponding bit in a control register that determines if it's >> rising or falling-edge triggered -- thus the need for my patch. To >> capture both directions, it's necessary to modify the control register >> when a falling edge is detected, so that the corresponding rising edge >> can be collected afterward. > > This kind of ugliness should be hidden in irqchip driver. See > mfd/asic3.c for an example. > I would agree with that -- it should be possible to hide that away as part of the functionality of the interrupt driver. Perhaps a fix to the OMAP1 IRQ handling is warranted. I know there are some interrupts that can do both directions out of the box, but that shouldn't be the responsibility of each driver to know. >> May I ask why you're thinking of >> converting to level-triggering? >> >> Perhaps it would be better to provide an option in the platform_device >> structure to set edge- or level-triggering, similar to the change I'm >> proposing for interrupts that can only signal one way at a time. >> > > Yes, we need a way fro platform code to specify desired interrupt flags > but I don't believe we should be reconfiguring them on the fly. > If the ability to handle this type of interrupt transparently was added to our board IRQ chip driver, this whole thing would be a non-issue, as gpio-keys could request edge triggered falling and rising at the same time, and the driver would Just Work. I'll take a look and see how possible that would be to do. Looking through the code for OMAP1's GPIO IRQ handlers, there's a note that OMAP1 only supports edge triggering, so if gpio-keys were to move exclusively to that, itwould stop working with those boards. But, it may be possible to do the trigger flip in the chip driver, which would make this patch unnecessary. - Cory -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
