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

["Cousson, Benoit" <b-cousson@ti.com>]

Hi Sumit,

On 2/15/2011 11:28 AM, Semwal, Sumit wrote:
> Hi Benoit,
>
> On Tue, Feb 15, 2011 at 3:53 PM, Cousson, Benoit<b-cousson@ti.com>  wrote:
>> 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.
> I guess what Archit wanted to say is, for hw IPs DISPC and DSI, on
> OMAP3, have a common IRQ line, so could both their hwmod databases
> have the same IRQ added for them? This would us call, for a common IRQ
> line shared w/ DISPC and DSI, like
> mentioned in Tomi's sample code above.

OK, thanks for the clarification, actually I missed a little bit the 
point :-(

So in fact the 2 modules share that same IRQ today, and you just want to 
populate both hwmod with the same input.
If this is a real OR between the two IRQ lines, meaning the dispc cannot 
mask the dsi IRQ or the opposite, then having the same IRQ number in the 
two different hwmods is a correct representation of the HW.

Then both devices with get the same IRQ number during the 
platform_get_irq, so if the driver is aware of that it is fine.

> How is hwmod data for these cases handled today? [shared IRQ,
> different platform devices?]

I don't think we have such case today at least on OMAP4. Or maybe it is 
just not properly documented, so only one hwmod is mapped to the IRQ line.

Regards,
Benoit

>
> Best regards,
> ~Sumit.
>>
>> 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@vger.kernel.org
>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>>