linux-arm-kernel.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: tony@atomide.com (Tony Lindgren)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH 0/2] OMAP: Update nr_irqs field in machine descriptors
Date: Fri, 7 Oct 2011 13:51:45 -0700	[thread overview]
Message-ID: <20111007205145.GA2293@atomide.com> (raw)
In-Reply-To: <alpine.LFD.2.02.1110071612380.6390@xanadu.home>

* Nicolas Pitre <nico@fluxnic.net> [111007 12:41]:
> On Thu, 6 Oct 2011, Tony Lindgren wrote:
> 
> > * S, Venkatraman <svenkatr@ti.com> [110825 07:23]:
> > > On Thu, Aug 25, 2011 at 5:19 PM, Cousson, Benoit <b-cousson@ti.com> wrote:
> > > > Hi Venkat,
> > > >
> > > > On 8/24/2011 9:46 PM, S, Venkatraman wrote:
> > > >>
> > > >> As part of an effort to get single ARM kernel binary [1],
> > > >> multiple ?definitions of NR_IRQS under various platforms
> > > >> have to be reconciled and abstracted away from common code.
> > > >>
> > > >> This patch series takes the small step of populating the
> > > >> machine descriptors with the pre-existing nr_irqs field.
> > > >> Eventually, the common irq handler code will only look at this
> > > >> field and not the compile time constant.
> > > >
> > > > Not related to this patch, but still on that topic. The current NR_IRQS
> > > > depends as well on board stuff, like for example : the Phoenix
> > > > IRQs:TWL6030_IRQ_BASE, TWL6040_CODEC_IRQ_BASE.
> > > > Is there a plan to get rid of this static defines?
> > > >
> > > 
> > > Currently, the goal is to get rid of the singleton nature
> > > of NR_IRQS. Then it just becomes a property of the
> > > platform, and the arm common code should not see this define.
> > > This cleanup has to be done across multiple SoCs, not just OMAP.
> > > 
> > > After I get to complete some meaningful cleanup of NR_IRQS,
> > > I can look into the static defines that you mention.
> > 
> > I suggest we wait on this patch as the NR_IRQS should be the
> > board specific true number of interrupts including chained
> > interrupts from external devices like twl. So just setting
> > it to NR_IRQS does not help much. Also, the board-*.c files
> > will be going aways with device tree at some point.
> 
> This is prerequisite to some other cleanup orthogonal to DT being worked 
> in parallel.  I would prefer if DT wasn't a serialization point for 
> this.

I see. How about let's populate the real number of interrupts for the
known boards then while at it.

Tony

  reply	other threads:[~2011-10-07 20:51 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-08-24 19:46 [PATCH 0/2] OMAP: Update nr_irqs field in machine descriptors Venkatraman S
2011-08-24 19:46 ` [PATCH 1/2] omap2+: Populate " Venkatraman S
2011-08-24 19:46 ` [PATCH 2/2] omap1: " Venkatraman S
2011-08-25 11:49 ` [PATCH 0/2] OMAP: Update " Cousson, Benoit
2011-08-25 14:55   ` S, Venkatraman
2011-10-06 19:50     ` Tony Lindgren
2011-10-07 20:15       ` Nicolas Pitre
2011-10-07 20:51         ` Tony Lindgren [this message]
2011-10-07 22:18           ` Nicolas Pitre

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=20111007205145.GA2293@atomide.com \
    --to=tony@atomide.com \
    --cc=linux-arm-kernel@lists.infradead.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;
as well as URLs for NNTP newsgroup(s).