On Tuesday 04 December 2007, Kevin Hilman wrote:
> The hack below allows me to get the above idea working, but I'm
> looking for better suggestions on how to rework the locking here so
> that the handler might be changed from within the irq_chip's set_type
> handler.
>
> Any ideas?
As I'm sure you know, this problem can show up on most platforms.
It's not limited to OMAP; more generic solutions are needed.
One solution would have the irq_chip.set_type() method just call
/* caller has locked the irq_desc and both params are valid */
static inline void __set_irq_handler_unlocked(int irq, irq_flow_handler_t handler)
{
irq_desc[irq].handler = handler;
}
Another solution, limited to chained handlers, is to have the
chaining handler call the right handler (edge or level) directly
instead of calling generic_handle_irq():
if (desc->status & IRQ_LEVEL)
handle_level_irq(irq, desc);
else
handle_edge_irq(irq, desc);
Of course that requires set_type() to maintain that status flag,
which currently isn't handled by the genirq core. Equivalently
it might mask against (IRQ_TYPE_LEVEL_HIGH|IRQ_TYPE_LEVEL_LOW),
which again isn't handled by the genirq core but is handled by
the GPIO logic in the OMAP tree.
- Dave
-
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
