public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Adrian Bunk <bunk@fs.tum.de>
To: Robert Schwebel <robert@schwebel.de>
Cc: "Richard B. Johnson" <root@chaos.analogic.com>,
	Juergen Beisert <jbeisert@eurodsn.de>,
	cliff white <cliffw@osdl.org>,
	piggin@cyberone.com.au, mpm@selenic.com,
	linux-kernel@vger.kernel.org
Subject: Re: [1/4] better i386 CPU selection
Date: Tue, 20 Jan 2004 23:10:25 +0100	[thread overview]
Message-ID: <20040120221025.GI12027@fs.tum.de> (raw)
In-Reply-To: <20040117091337.GZ5139@pengutronix.de>

On Sat, Jan 17, 2004 at 10:13:37AM +0100, Robert Schwebel wrote:

> Hi, 

Hi Robert,

> On Sat, Jan 17, 2004 at 03:15:32AM +0100, Adrian Bunk wrote:
> > Besides the AMD Elan cpufreq driver I see nothing where CONFIG_MELAN
> > gave you any real difference (except your highest goal is to avoid a
> > recompilation when switching from the Pentium 4 to the AMD Elan - but I
> > doubt the really "prevents development").
> > 
> > But I'm not religious about this issue. Let Robert decide, the Elan 
> > support is his child.
> > 
> > > > > - added optimizing CFLAGS for the AMD Elan
> > > 
> > > There are no such different "optimizations" for ELAN.
> > 
> > What's wrong wih the -march=i486 Robert suggested?
> 
> I've not followed the 2.6 development regarding the arch selection that
> closely; let's collect arguments: 
> 
> - Is it still possible to run a -march=i486 built kernel on a pentium? 
>   IMHO It would be good to optimize the code for i486, but I'm not that 
>   familiar with how good gcc optimizes for 486 that I can comment this.

yes, since a Pentium supports a superset of the 486 gcc can't optimize 
for a 486 in a way that the code won't run on a Pentium.

> - I personally work with lots of cross architectures like ARM, so cross
>   compiling for an embedded system is no problem for me. But if people
>   want to test stuff on their pentiums I also have no problem with that.
> 
> Other arguments? 

The only reason why I sent the patch to make the AMD Elan a separate 
subarch was the CLOCK_TICK_RATE #ifdef in include/asm-i386/timex.h .

It should be possible to change it to a variable (as with 
CONFIG_X86_PC9800) if both the Elan and a different cpu are supported if 
this is really a required use.

If this is the solution you prefer, how would you do runtime detection 
for the AMD Elan?

> Robert

cu
Adrian

-- 

       "Is there not promise of rain?" Ling Tan asked suddenly out
        of the darkness. There had been need of rain for many days.
       "Only a promise," Lao Er said.
                                       Pearl S. Buck - Dragon Seed


  reply	other threads:[~2004-01-20 22:12 UTC|newest]

Thread overview: 34+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-01-06  5:48 2.6.1-rc1-tiny2 Matt Mackall
2004-01-06  6:33 ` 2.6.1-rc1-tiny2 Nick Piggin
2004-01-06  6:46   ` 2.6.1-rc1-tiny2 Matt Mackall
2004-01-06  7:08     ` 2.6.1-rc1-tiny2 Nick Piggin
2004-01-10  0:46       ` 2.6.1-rc1-tiny2 Adrian Bunk
2004-01-10  0:50         ` [0/4] better i386 CPU selection Adrian Bunk
2004-01-10  0:52         ` [1/4] " Adrian Bunk
2004-01-10 11:04           ` Wichert Akkerman
2004-01-11  3:13             ` Adrian Bunk
2004-01-14 20:49               ` [-mm patch] " Adrian Bunk
2004-01-16 19:15           ` [1/4] " cliff white
2004-01-16 19:32             ` Richard B. Johnson
2004-01-17  0:01               ` Andrew Morton
2004-01-17  2:57                 ` Adrian Bunk
2004-01-19 15:14                   ` John Stoffel
2004-01-19 23:42                     ` Nick Piggin
2004-01-17  2:15               ` Adrian Bunk
2004-01-17  9:13                 ` Robert Schwebel
2004-01-20 22:10                   ` Adrian Bunk [this message]
2004-01-20 22:31                     ` Richard B. Johnson
2004-01-20 22:47                     ` George Anzinger
2004-01-17 10:01                 ` aeriksson
2004-01-10  0:57         ` [2/4] move "struct movsl_mask movsl_mask" to usercopy.c Adrian Bunk
2004-01-10  0:57         ` [3/4] proof of concept: make arch/i386/kernel/cpu/Makefile CPU specific Adrian Bunk
2004-01-10  0:58         ` [4/4] proof of concept: make arch/i386/kernel/cpu/mtrr/Makefile " Adrian Bunk
2004-01-10 22:14         ` 2.6.1-rc1-tiny2 Matt Mackall
2004-01-12  2:20           ` 2.6.1-rc1-tiny2 Nick Piggin
2004-01-07 14:06 ` 2.6.1-rc1-tiny2 Jens Axboe
2004-01-07 18:50   ` 2.6.1-rc1-tiny2 Matt Mackall
2004-01-07 19:27     ` 2.6.1-rc1-tiny2 Mitchell Blank Jr
2004-01-07 20:10       ` 2.6.1-rc1-tiny2 Matt Mackall
2004-01-07 21:41         ` 2.6.1-rc1-tiny2 Trond Myklebust
2004-01-07 21:10     ` 2.6.1-rc1-tiny2 Jens Axboe
2004-01-07 21:30       ` 2.6.1-rc1-tiny2 Matt Mackall

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=20040120221025.GI12027@fs.tum.de \
    --to=bunk@fs.tum.de \
    --cc=cliffw@osdl.org \
    --cc=jbeisert@eurodsn.de \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mpm@selenic.com \
    --cc=piggin@cyberone.com.au \
    --cc=robert@schwebel.de \
    --cc=root@chaos.analogic.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