From: Tomi Valkeinen <tomi.valkeinen@ti.com>
To: "Taneja, Archit" <archit@ti.com>
Cc: "linux-omap@vger.kernel.org" <linux-omap@vger.kernel.org>,
"Cousson, Benoit" <b-cousson@ti.com>
Subject: Re: [PATCH] OMAP: DSS2: Have separate irq handlers for DISPC and DSI
Date: Fri, 18 Feb 2011 12:00:23 +0200 [thread overview]
Message-ID: <1298023223.24062.24.camel@deskari> (raw)
In-Reply-To: <4D5E3D35.9000902@ti.com>
On Fri, 2011-02-18 at 03:34 -0600, Taneja, Archit wrote:
> Hi,
>
> On Friday 18 February 2011 02:40 PM, Valkeinen, Tomi wrote:
> > Hi,
> >
> > On Thu, 2011-02-17 at 08:25 -0600, Taneja, Archit wrote:
> >> Currently, the core DSS platform device requests for an irq line for OMAP2 and
> >> OMAP3. Make DISPC and DSI platform devices request for a shared IRQ line.
> >>
> >> On OMAP3, the logical OR of DSI and DISPC interrupt lines goes to the MPU. There
> >> is a register DSS_IRQSTATUS which tells if the interrupt came from DISPC or DSI.
> >>
> >> On OMAP2, there is no DSI, only DISPC interrupts goto the MPU. There is no
> >> DSS_IRQSTATUS register.
> >>
> >> Hence, it makes more sense to have separate irq handlers corresponding to the
> >> DSS sub modules instead of having a common handler.
> >>
> >> Since on OMAP3 the logical OR of the lines goes to MPU, the irq line is shared
> >> among the IRQ handlers.
> >>
> >> The hwmod irq info has been removed for DSS to DISPC and DSI for OMAP2 and OMAP3
> >> hwmod databases. The Probes of DISPC and DSI now request for irq handlers. A dss
> >> feature is also added to tell whether the irq lines is shared between DISPC and
> >> DSI or not.
> >
> > Yes, I think this looks much cleaner.
> >
> > However, I'm not sure if it's necessary to check the DSS_IRQSTATUS. It
> > depends a bit on how DSS_IRQSTATUS works. If it just mirrors the
> > DISPC/DSI_IRQSTATUS (ie, if there's any bit up in DSI_IRQSTATUS, the DSI
> > bit in DSS_IRQSTATUS is up), we can do without it.
> >
> > For example let's say we haven't enabled any interrupts in DSI, so
> > preferably we want to spend as little time in the dsi irq handler as
> > possible.
> >
> > Now, if DSI_IRQSTATUS is all zeroes, and thus DSS_IRQSTATUS.DSI is also
> > zero, we can skip the DSI handler by checking DSS_IRQSTATUS.DSI as you
> > do in this patch. But we could as well check DSI_IRQSTATUS, and exit if
> > it's all zeroes.
> >
> > If, on the other hand, DSI_IRQSTATUS has any bit up, then also
> > DSS_IRQSTATUS.DSI is up, and we have to check the DSI interrupts anyway.
> >
> > So in both cases the end result is the same, and we can do with less
> > code by not using DSS_IRQSTATUS.
> >
> > However, I'm not 100% sure DSS_IRQSTATUS works like that, but it would
> > sound logical and I don't know how could it work otherwise.
>
> I can give it a try.
>
> There is a figure in the OMAP3 TRM titled "DISPC and DSS Interrupts
> tree" which shows its logical OR. How the bits are set in DSS_IRQSTATUS
> is not mentioned anywhere though
Well, if DSS_IRQSTATUS doesn't work as I described above, in the worst
case we will just run a few more lines of code in the irq handler, as we
check for registered interrupts. But that would only happen if either
DISPC or DSI has no interrupts enabled, which is... never?
So I think it should work fine anyway.
Tomi
next prev parent reply other threads:[~2011-02-18 10:00 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-02-17 14:25 [PATCH] OMAP: DSS2: Have separate irq handlers for DISPC and DSI Archit Taneja
2011-02-18 9:10 ` Valkeinen, Tomi
2011-02-18 9:34 ` archit taneja
2011-02-18 9:45 ` Turquette, Mike
2011-02-18 9:50 ` Tomi Valkeinen
2011-02-18 10:25 ` archit taneja
2011-02-18 10:00 ` Tomi Valkeinen [this message]
2011-02-18 11:05 ` archit taneja
2011-02-18 11:11 ` Tomi Valkeinen
-- strict thread matches above, loose matches on Subject: below --
2011-02-21 6:00 Archit Taneja
2011-02-21 6: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=1298023223.24062.24.camel@deskari \
--to=tomi.valkeinen@ti.com \
--cc=archit@ti.com \
--cc=b-cousson@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