public inbox for linux-omap@vger.kernel.org
 help / color / mirror / Atom feed
From: Tony Lindgren <tony@atomide.com>
To: Jarkko Nikula <jarkko.nikula@nokia.com>
Cc: ext Paul Walmsley <paul@pwsan.com>,
	linux-omap-open-source@linux.omap.com
Subject: Re: [PATCH RESEND 0/4] Runtime constants: define (some) OMAP address bases at runtime rather than compile time for multiboot
Date: Fri, 23 Nov 2007 14:08:48 -0800	[thread overview]
Message-ID: <20071123220848.GP559@atomide.com> (raw)
In-Reply-To: <20071121095605.a929f07d.jarkko.nikula@nokia.com>

* Jarkko Nikula <jarkko.nikula@nokia.com> [071120 23:55]:
> On Wed, 21 Nov 2007 00:13:17 -0700 (MST)
> "ext Paul Walmsley" <paul@pwsan.com> wrote:
> 
> > > How about calling omap2_set_globals_242x() from
> > > arch/arm/mach-omap2/io.c: omap2_map_common_io() in order to avoid
> > > modifications to n board files?
> > 
> > We could do that, but we'd still need to modify the board files to
> > pass in the OMAP type to omap2_map_common_io().  
> > 
> > In an ideal world, we could just use omap2_check_revision() to
> > determine the CPU type at runtime, but the TAP base address is not
> > the same across all OMAPs, and must therefore itself be modified for
> > multiboot :-(
> > 
> Ah, yes, I see. Chicken and egg problem.
> 
> void __init omap2_map_common_io(void)
> {
> ...
> 	/* revision? TAP base ?*/
> 	omap2_check_revision();
> ...
> 
> I think at this point it is better to modify n board files, as your set
> is doing, instead of modifying omap2_map_common_io() API? At least both
> add & possible clean-up patches will be just one liners only.

I guess later on we could try autodetect the TAP base :)

Pushing today, like you said improvments to CPU detection will be
trivial patches. And we may want to have both functions in place
so we can printk warnings if CPU detection code does not match what's
set in the board files.

Regards,

Tony

      reply	other threads:[~2007-11-23 22:08 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-11-21  0:16 [PATCH RESEND 0/4] Runtime constants: define (some) OMAP address bases at runtime rather than compile time for multiboot Paul Walmsley
2007-11-21  0:16 ` [PATCH RESEND 1/4] Runtime constants: introduce omap2_set_globals_*() Paul Walmsley
2007-11-21  0:16 ` [PATCH RESEND 2/4] Runtime constants: use runtime-computed SDRC base Paul Walmsley
2007-11-21  0:16 ` [PATCH RESEND 3/4] Runtime constants: use runtime-computed SMS base Paul Walmsley
2007-11-21  0:16 ` [PATCH RESEND 4/4] Runtime constants: use runtime-computed system control module base Paul Walmsley
2007-11-21  7:03 ` [PATCH RESEND 0/4] Runtime constants: define (some) OMAP address bases at runtime rather than compile time for multiboot Jarkko Nikula
2007-11-21  7:13   ` Paul Walmsley
2007-11-21  7:56     ` Jarkko Nikula
2007-11-23 22:08       ` Tony Lindgren [this message]

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=20071123220848.GP559@atomide.com \
    --to=tony@atomide.com \
    --cc=jarkko.nikula@nokia.com \
    --cc=linux-omap-open-source@linux.omap.com \
    --cc=paul@pwsan.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