All of lore.kernel.org
 help / color / mirror / Atom feed
From: Tony Lindgren <tony@atomide.com>
To: Nicolas Pitre <nico@fluxnic.net>
Cc: "S, Venkatraman" <svenkatr@ti.com>,
	"linux-omap@vger.kernel.org" <linux-omap@vger.kernel.org>,
	"Cousson, Benoit" <b-cousson@ti.com>,
	"linux-arm-kernel@lists.infradead.org"
	<linux-arm-kernel@lists.infradead.org>
Subject: Re: [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

--
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

WARNING: multiple messages have this Message-ID (diff)
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: 18+ 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 ` Venkatraman S
2011-08-24 19:46 ` [PATCH 1/2] omap2+: Populate " Venkatraman S
2011-08-24 19:46   ` Venkatraman S
2011-08-24 19:46 ` [PATCH 2/2] omap1: " Venkatraman S
2011-08-24 19:46   ` Venkatraman S
2011-08-25 11:49 ` [PATCH 0/2] OMAP: Update " Cousson, Benoit
2011-08-25 11:49   ` Cousson, Benoit
2011-08-25 14:55   ` S, Venkatraman
2011-08-25 14:55     ` S, Venkatraman
2011-10-06 19:50     ` Tony Lindgren
2011-10-06 19:50       ` Tony Lindgren
2011-10-07 20:15       ` Nicolas Pitre
2011-10-07 20:15         ` Nicolas Pitre
2011-10-07 20:51         ` Tony Lindgren [this message]
2011-10-07 20:51           ` Tony Lindgren
2011-10-07 22:18           ` Nicolas Pitre
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=b-cousson@ti.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-omap@vger.kernel.org \
    --cc=nico@fluxnic.net \
    --cc=svenkatr@ti.com \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.