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
next prev parent 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