From: Paul M. <le...@li...> - 2007-08-14 00:58:57
|
On Mon, Aug 13, 2007 at 11:49:21AM +0900, Magnus Damm wrote: > On 8/10/07, EXTERNAL Brunner Markus (Praktikant; ST-FIR/Eng) > <ext...@de...> wrote: > > It was caused by the smc911x driver it requested the irq with > > IRQF_TRIGGER_FALLING and overwrote my settings in the board setup. > > After changing this to LOW it worked. > > I wonder if it would make sense to extend the interrupt api to provide > a bitmap of all supported sense configurations supported by the > driver... That way the driver would tell the interrupt controller > which configurations it supports and it's up to the interrupt > controller pick one of them. Then the driver reads back which > configuration that was selected by the interrupt controller and sets > up the hardware it controls accordingly. > > Or maybe that is too complicated, I'm not sure. But the current > framework seems a bit too limited IMO, especially if the interrupt > controller only supports a certain sense configuration. > > The best solution may be the other way around though, where the > interrupt controller provides a bitmap of supported sense > configurations that the driver may choose from... > The current API works fine for this. the trigger flag is going to be board-specific in the terms of most drivers, and conventional wisdom dictates that the pin said peripheral's interrupt line is connected to is able to do sense selection based on what the peripheral mandates. There are of course cases where folks take edge-triggered devices and plug them in to a level-only line or some combination thereof, but that's not an API problem. The driver already has to know at request_irq() time what trigger type it requires. |