public inbox for linux-omap@vger.kernel.org
 help / color / mirror / Atom feed
From: Tony Lindgren <tony@atomide.com>
To: "Syed Mohammed, Khasim" <x0khasim@ti.com>
Cc: Linux OMAP <linux-omap-open-source@linux.omap.com>
Subject: Re: [PATCH 5/11] Adding OMAP3430 support to mach-omap2
Date: Tue, 29 May 2007 13:23:01 -0700	[thread overview]
Message-ID: <20070529202301.GA27603@atomide.com> (raw)
In-Reply-To: <9C23CDD79DA20A479D4615857B2E2C47FF12A7@dlee13.ent.ti.com>

* Syed Mohammed, Khasim <x0khasim@ti.com> [070529 12:49]:
> Hi Tony,
> 
> One quick clarification,
> 
> >> diff -purN linux-omap/arch/arm/mach-omap2/io.c
> >val_3430_GIT/arch/arm/mach-omap2/io.c
> >> --- linux-omap/arch/arm/mach-omap2/io.c	2007-05-16 
> >>
> <snip>
> >> +#if defined(CONFIG_ARCH_OMAP24XX)
> >> +
> >> +#define L3_VIRT		L3_24XX_VIRT
> >> +#define L3_PHYS		L3_24XX_PHYS
> >> +#define L3_SIZE		L3_24XX_SIZE
> >> +
> >> +#define L4_VIRT		L4_24XX_VIRT
> >> +#define L4_PHYS		L4_24XX_PHYS
> >> +#define L4_SIZE		L4_24XX_SIZE
> >> +
> >> +#define L4_WK_VIRT	L4_WK_243X_VIRT
> >> +#define L4_WK_PHYS	L4_WK_243X_PHYS
> >> +#define L4_WK_SIZE	L4_WK_243X_SIZE
> >> +
> <snip>
> >> +#elif defined(CONFIG_ARCH_OMAP34XX)
> >> +
> >> +#define L3_VIRT		L3_34XX_VIRT
> >> +#define L3_PHYS		L3_34XX_PHYS
> >> +#define L3_SIZE		L3_34XX_SIZE
> >> +
> >> +#define L4_VIRT		L4_34XX_VIRT
> >> +#define L4_PHYS		L4_34XX_PHYS
> >> +#define L4_SIZE		L4_34XX_SIZE
> >> +
> >> +#define L4_PER_VIRT	L4_PER_34XX_VIRT
> >> +#define L4_PER_PHYS	L4_PER_34XX_PHYS
> >> +#define L4_PER_SIZE	L4_PER_34XX_SIZE
> >> +
> >> +#define L4_WK_VIRT	L4_WK_34XX_VIRT
> >> +#define L4_WK_PHYS	L4_WK_34XX_PHYS
> >> +#define L4_WK_SIZE	L4_WK_34XX_SIZE
> >> +
> >> +
> <snip>
> >> +#endif
> >
> >Let's rather change the #elif to #if to potentially compile in both
> >(altought unoptimized). 
> If we try to opt for different map descriptor table for OMAP2 and OMAP3 then these definitions might not be needed at all.

True.

> >I guess that also means changing L3_VIRT to be
> >L3_VIRT_34XX and so on.
> >
> >
> The reason these definitions were defined was to re-use the common fields (between 2430 / 3430) in map descriptor table.
> 
> If we change L3_VIRT to be L3_VIRT_34XX, this will make the map descriptor table look more redundant in code... 
> 
> Did you mean creating a two separate map descriptor tables?

Yeah, that is the best solution in the long run to support various
processors. That could also be a pre-3430 patch, and that will shrink
down the actual 3430 patch.

Regards,

Tony

  reply	other threads:[~2007-05-29 20:23 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-05-29  6:21 [PATCH 5/11] Adding OMAP3430 support to mach-omap2 Syed Mohammed, Khasim
2007-05-29 16:49 ` Tony Lindgren
2007-05-29 17:33   ` Syed Mohammed, Khasim
2007-05-29 18:16     ` Tony Lindgren
2007-05-29 19:49   ` Syed Mohammed, Khasim
2007-05-29 20:23     ` Tony Lindgren [this message]
2007-05-30 17:02 ` Khem Raj
2007-05-31  1:01   ` Nishanth Menon
2007-05-31  3:29     ` Syed Mohammed, Khasim

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=20070529202301.GA27603@atomide.com \
    --to=tony@atomide.com \
    --cc=linux-omap-open-source@linux.omap.com \
    --cc=x0khasim@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