On Fri, 7 Oct 2011, Tony Lindgren wrote: > * Nicolas Pitre <nico@xxxxxxxxxxx> [111007 12:41]: > > On Thu, 6 Oct 2011, Tony Lindgren wrote: > > > > > * S, Venkatraman <svenkatr@xxxxxx> [110825 07:23]: > > > > On Thu, Aug 25, 2011 at 5:19 PM, Cousson, Benoit <b-cousson@xxxxxx> 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. Sure, if you know what you are doing (which I'm sure you do). Otherwise using NR_IRQS is more or less a functional no-op wrt the current situation, and therefore what I would have used myself because I don't know much about the various OMAP boards. Nicolas
