Hi, On Tue, Feb 15, 2011 at 10:37:37AM +0200, Tomi Valkeinen wrote: > > This approach looks clean, but isn't IRQF_SHARED used the other way > > around. One irq line and multiple handlers? > > That is the case here, isn't it (on omap3)? One interrupt line (the DSS > irq, the same returned both from dsi.pdev and dispc.pdev), and two > handlers, one in dispc and one in dsi? Or what do you mean? IMO, for omap3 it would be better to have irq_chip there. Then you can keep e.g. DISPC IRQ disabled until dispc.c calls request_irq(). What happens today if you have IRQ enabled but dispc isn't ready to act on those ? > On omap2 there's no dsi code ran, so dispc is the only one requesting > the irq, and thus IRQF_SHARED is extra. In omap4 there are separate irq > lines (dsi.pdev and dispc.pdev return different irqs), and so > IRQF_SHARED is again extra. But I don't see any harm in IRQF_SHARED even > in omap2/4. What if another HW requests the wrong IRQ number and it ends up being your dispc IRQ line ? -- balbi -- 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
