From: Tomi Valkeinen <tomi.valkeinen@ti.com>
To: "Balbi, Felipe" <balbi@ti.com>
Cc: "Taneja, Archit" <archit@ti.com>,
"linux-omap@vger.kernel.org" <linux-omap@vger.kernel.org>
Subject: Re: OMAP: DSS2: Common IRQ handler for all OMAPs
Date: Tue, 15 Feb 2011 09:45:11 +0200 [thread overview]
Message-ID: <1297755911.2289.28.camel@deskari> (raw)
In-Reply-To: <20110214143001.GK2549@legolas.emea.dhcp.ti.com>
On Mon, 2011-02-14 at 08:30 -0600, Balbi, Felipe wrote:
> Hi,
>
> On Mon, Feb 14, 2011 at 04:21:47PM +0200, Tomi Valkeinen wrote:
> > On Wed, 2011-02-02 at 08:56 +0000, archit taneja wrote:
> > > OMAP2 has an irq line dedicated for DISPC interrupts, there is no DSI
> > > on omap2.
> > > OMAP3 has a common irq line for DISPC and DSI interrupts.
> > > OMAP4 has seperate irq lines for DISPC and DSI Interrupts.
> > >
> > > Use dss_features to have a common DSS irq handler for all OMAP revisions.
> > >
> > > Also, use a member of the global dss structure to store the irq number
> > > as it is used in 2 functions.
> >
> > It's good to remove the cpu_is_xxxx() calls, but I'm not quite sure
> > about this patch...
> >
> > Could we use shared interrupt handlers here, so that dss.c would handle
> > only DISPC interrupts (or should it be even in dispc.c?) and dsi.c would
> > handle DSI interrupts?
> >
> > On OMAP3 both dss.c and dsi.c would register to the same interrupt, and
> > they would need to check if the interrupt was really for them. On OMAP4
> > the code could be the same, even though the check is unnecessary.
> >
> > Also, as I mentioned in the email I sent some minutes ago, this patch
> > fixes the free_irq call in dss_exit. Things like that should never be
> > fixed silently, even if it's trivial like in this case.
>
> does it make sense to install an irq_chip for that ? I mean, can you
> mask/unmask dss and or dsi IRQs ? If you can, then it might make sense
> to take a look into GENIRQ and install an irq_chip for that. Then both
> dsi and dss would be able to use standard request_irq() API.
>
> Take a look at drivers/mfd/twl*irq.c and drivers/cbus/retu.c (the last
> one on linux-omap only) there are examples of how that should be
> implemented. Actually twl*irq.c is wrong, as it bypasses the threaded
> IRQ stuff. I have some patches for those, but I'm not sure they are
> working correctly yet, needs more testing. My twl4030-irq patches are
> available at [1] for reference.
I'm not familiar with genirq/irq_chip. But yes, as Archit said, we can
mask/unmask DSS interrupts. I mean, there's only one interrupt line, but
DSS has irqstatus and irqenable registers that can be used.
If I understood correctly, irq_chip could be used to manage DSS and DSI
interrupts, but I don't know right away what that would mean in
practice, and would it make things easier or not. But this could be
something that needs more study, as there's a custom isr handling system
in DSS, and it would be nice if that could be replaced with genirq.
But I guess the main problem still remains with genirqs also: we have
one interrupt line on omap3, used by two separate modules. And one irq
on omap2, used by one module, and two irqs on omap4, used by two
modules.
Tomi
next prev parent reply other threads:[~2011-02-15 7:45 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-02-02 8:56 [PATCH] OMAP: DSS2: Common IRQ handler for all OMAPs Archit Taneja
2011-02-14 14:21 ` Tomi Valkeinen
2011-02-14 14:30 ` Felipe Balbi
2011-02-15 4:28 ` archit taneja
2011-02-15 7:27 ` Tomi Valkeinen
2011-02-15 8:30 ` archit taneja
2011-02-15 8:37 ` Tomi Valkeinen
2011-02-15 8:47 ` archit taneja
2011-02-15 9:25 ` archit taneja
2011-02-15 10:23 ` Cousson, Benoit
2011-02-15 10:28 ` Semwal, Sumit
2011-02-15 10:50 ` Cousson, Benoit
2011-02-15 12:43 ` archit taneja
2011-02-15 12:56 ` Cousson, Benoit
2011-02-15 10:57 ` Felipe Balbi
2011-02-15 11:25 ` Tomi Valkeinen
2011-02-15 11:42 ` Felipe Balbi
2011-02-15 8:05 ` Felipe Balbi
2011-02-15 8:20 ` archit taneja
2011-02-15 8:23 ` Felipe Balbi
2011-02-15 7:45 ` Tomi Valkeinen [this message]
2011-02-15 8:03 ` archit taneja
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1297755911.2289.28.camel@deskari \
--to=tomi.valkeinen@ti.com \
--cc=archit@ti.com \
--cc=balbi@ti.com \
--cc=linux-omap@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox