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