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

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

 



Hi Archit,

On 2/15/2011 10:25 AM, Taneja, Archit wrote:
Copying Benoit,

On Tuesday 15 February 2011 02:07 PM, Valkeinen, Tomi wrote:
On Tue, 2011-02-15 at 02:30 -0600, Taneja, Archit wrote:
Hi,

On Tuesday 15 February 2011 12:57 PM, Valkeinen, Tomi wrote:

<snip>

I meant something like this:

dispc.c:

dispc_init()
{
	/* did we have a pdev for dispc? if not, this needs to be dss.pdev */
	request_irq(platform_get_irq(dispc.pdev, 0), irq_handler, IRQF_SHARED, "dispc irq", foo);
}

irq_handler()
{
	if (irq_can_be_shared) {
		check if the irq is for us. exit if not;
	}

	handle;
}

dsi.c:

dsi_init()
{
	request_irq(platform_get_irq(dsi.pdev, 0), irq_handler, IRQF_SHARED, "dsi irq", foo);
}

irq_handler()
{
	if (irq_can_be_shared) {
		check if the irq is for us. exit if not;
	}

	handle;
}


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?

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.

   Tomi


Benoit,

Is it okay to have the same irq entry for 2 different hwmods?
This requirement comes from OMAP3 where dispc and dsi have a common irq
line, where as on OMAP4 dispc and dsi have separate irq lines.

Well, no. I explained that in one of my comment about hwmod modification. The hwmod data are reflecting the exact HW capabilities.
So, if there is a change in the HW, the hwmod will be different.
It is up to the driver to adapt to this change.

The driver has to evolve to handle properly the new HW capabilities while keeping the old stuff working.

We basically want to get rid of a central dss irq handler (hence, remove
irq entries for dss_core hwmod) and instead have separate irq handlers
for each module which may or may not share an irq line.

Then you need to hack your driver but not the hwmod data:-(

Regards,
Benoit

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