public inbox for linux-omap@vger.kernel.org
 help / color / mirror / Atom feed
From: Tony Lindgren <tony@atomide.com>
To: "Shilimkar, Santosh" <santosh.shilimkar@ti.com>
Cc: "linux-omap@vger.kernel.org" <linux-omap@vger.kernel.org>
Subject: Re: [PATCH 3/7][RFC] OMAP4: Update common omap platform headers.
Date: Wed, 22 Apr 2009 23:22:59 -0700	[thread overview]
Message-ID: <20090423062259.GF25864@atomide.com> (raw)
In-Reply-To: <EAF47CD23C76F840A9E7FCE10091EFAB02B3D8FADF@dbde02.ent.ti.com>

* Shilimkar, Santosh <santosh.shilimkar@ti.com> [090422 22:18]:
> 
> > > > This ifdef we don't want to do as it blocks the compile
> > > > for multi-omap.
> > > Not sure why this should break multi-omap. As I mentioned 
> > in one of the patch OMAP4 may not be
> > > able to support multi-omap because of major differences on 
> > Memory controller and Interrupt handling.
> > > This macro ensures that only for OMAP4 all the IRQ lines 
> > are offseted by 32 and for rest of the OMAPs the offset is 
> > zero. Because that's the only change necessary.
> > > 
> > > May be I haven't understood your point here.
> > 
> > It makes the irq lines wrong if CONFIG_ARCH_OMAP4 and 
> > CONFIG_ARCH_OMAP3
> > are selected.
> 
> Agree. My assumption was OMAP3 and OMAP4 both won't get selected together. If they are then it's straight makes IRQ lines wrong. 
> > > > 
> > > > How about just add extra + 32 to the omap4 specific
> > > > defines? Something like this maybe:
> > > > 
> > > > #define OMAP4_GIC_OFFSET	32
> > > > #define INT_44XX_SP15_IRQ (69 + IRQ_GIC_START + OMAP4_GIC_OFFSET)
> > > > 
> > > > It's OK to define the numbers separately for each processors:
> > > 
> > > I thought about this but this will have impact on the 
> > drivers as well. In every driver you need to put different 
> > IRQ line macros depending on the OMAP2/3/4.
> > 
> > No. The interrupt numbers are coming from platform_data. You always
> > have separate platform_data for different processors.
> > 
> > > Just as an example UART1 uses "INT_24XX_UART1_IRQ" as the 
> > IRQ line number for OMAP2, OMAP3 and now for OMAP4 ( just 
> > offseted by 32).
> > 
> > This needs to be fixed in the serial code. I believe that's already
> > in Kevin's patches.
> > 
> > > If we define separate macros for each processor, we would 
> > be unnecessarily polluting the driver code with switches. 
> > Secondly, in this file itself we will be adding around 100 + 
> > lines of code just to take care of 32 offset.
> > 
> > The numbers are not the same. It's OK to add separate defines for
> > data that is not the same. The unused defines just will not be
> > used anywhere.
> If we agree to cleanup the driver platform structures wherever needed, then no issues with separate lines. In that case no #ifdef necessary. Bye the way 
> #define INT_44XX_SP15_IRQ (69 + OMAP4_GIC_OFFSET) is sufficient. Any particul;ar reason you want it this way.
> #define INT_44XX_SP15_IRQ (69 + IRQ_GIC_START + OMAP4_GIC_OFFSET) ?

No reason, unless there's some logic to the numbering where the
offset makes things easier to read :)

Tony

  reply	other threads:[~2009-04-23  6:23 UTC|newest]

Thread overview: 30+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-04-21 13:08 [PATCH 1/7][RFC] OMAP4: Create architecture macros and config entries Santosh Shilimkar
2009-04-21 13:08 ` [PATCH 2/7][RFC] OMAP4: Create board support for OMAP_4430SDP Santosh Shilimkar
2009-04-21 13:08   ` [PATCH 3/7][RFC] OMAP4: Update common omap platform headers Santosh Shilimkar
2009-04-21 13:08     ` [PATCH 4/7][RFC] OMAP4: Update common omap platform common sources Santosh Shilimkar
2009-04-21 13:08       ` [PATCH 5/7][RFC] OMAP4: Update common omap machine specific sources Santosh Shilimkar
2009-04-21 13:08         ` [PATCH 6/7][RFC] OMAP4: Clock hack since clock management framework not in Santosh Shilimkar
2009-04-21 13:08           ` [PATCH 7/7][RFC] OMAP4: Enable basic build support Santosh Shilimkar
2009-04-21 18:39             ` Tony Lindgren
2009-04-22  4:55               ` Shilimkar, Santosh
2009-04-22 19:04                 ` [PATCH] ARM: OMAP2/3: Reorganize Makefile to add omap4 support (Re: [PATCH 7/7][RFC] OMAP4: Enable basic build support.) Tony Lindgren
2009-04-23  5:07                   ` Shilimkar, Santosh
2009-04-23  6:21                     ` Tony Lindgren
2009-04-23  6:30                       ` Shilimkar, Santosh
2009-04-21 18:37           ` [PATCH 6/7][RFC] OMAP4: Clock hack since clock management framework not in Tony Lindgren
2009-04-21 13:24         ` [PATCH 5/7][RFC] OMAP4: Update common omap machine specific sources Dasgupta, Romit
2009-04-21 16:23         ` Kevin Hilman
2009-04-21 18:36         ` Tony Lindgren
2009-04-22  4:40           ` Shilimkar, Santosh
2009-04-21 13:21       ` [PATCH 4/7][RFC] OMAP4: Update common omap platform common sources Premi, Sanjeev
2009-04-21 13:34         ` Shilimkar, Santosh
2009-04-21 13:38           ` Shilimkar, Santosh
2009-04-21 18:33       ` Tony Lindgren
2009-04-21 18:26     ` [PATCH 3/7][RFC] OMAP4: Update common omap platform headers Tony Lindgren
2009-04-22  4:10       ` Shilimkar, Santosh
2009-04-22 19:11         ` Tony Lindgren
2009-04-23  5:17           ` Shilimkar, Santosh
2009-04-23  6:22             ` Tony Lindgren [this message]
2009-04-21 18:14   ` [PATCH 2/7][RFC] OMAP4: Create board support for OMAP_4430SDP Tony Lindgren
2009-04-22  4:47     ` Shilimkar, Santosh
2009-04-21 16:41 ` [PATCH 1/7][RFC] OMAP4: Create architecture macros and config entries Kevin Hilman

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=20090423062259.GF25864@atomide.com \
    --to=tony@atomide.com \
    --cc=linux-omap@vger.kernel.org \
    --cc=santosh.shilimkar@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox