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

Cousson, Benoit
2011-02-15T10:23:15Z

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