Re: OMAP: DSS2: Common IRQ handler for all OMAPs

[Tomi Valkeinen <tomi.valkeinen@ti.com>]

On Tue, 2011-02-15 at 04:57 -0600, Balbi, Felipe wrote:
> 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 ?

Currently we have a single interrupt handler, which then calls either
dispc and/or dsi handler. Dispc and dsi are always ready to handle
those.

I don't think it would be a good solution if irq_chip would be used only
for omap3. Then we'd have totally different solutions for different omap
versions. But if irq_chip can be easily used for all omap versions, then
perhaps.

But then again, using IRQF_SHARED should (I think) solve the problem
quite easily without big changes to the code. irq_chip sounds like a
bigger change.

> > 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 ?

Are you asking what happens if we have a bug in kernel code? Anything
can happen =). But I don't see that as a reason not to use IRQF_SHARED.

 Tomi