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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi,

On Tue, Feb 15, 2011 at 01:25:34PM +0200, Tomi Valkeinen wrote:
> > 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.

Exactly the kind of thing irq_chip would help you :-)

> 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 the HW is different anyway. On OMAP3 you're connect to a DSS irq
demuxer, on OMAP4 you have dedicated lines straight from OMAP's INTC.

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

ok, I have to agree. :-) But you will be allowing for that to happen. If
you don't IRQF_SHARED, request_irq() will fail on the second call with
-EBUSY I believe.

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


[Index of Archives]     [Linux Arm (vger)]     [ARM Kernel]     [ARM MSM]     [Linux Tegra]     [Linux WPAN Networking]     [Linux Wireless Networking]     [Maemo Users]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite Trails]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux