Hi Benoit,
On Tue, Feb 15, 2011 at 3:53 PM, Cousson, Benoit <b-cous...@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.
How is hwmod data for these cases handled today? [shared IRQ,
different platform devices?]
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 majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
