Linux MIPS Architecture development
 help / color / mirror / Atom feed
From: Ralf Baechle <ralf@linux-mips.org>
To: Jim Gifford <maillist@jg555.com>
Cc: Kumba <kumba@gentoo.org>,
	Linux MIPS List <linux-mips@linux-mips.org>,
	Peter Horton <pdh@colonel-panic.org>
Subject: Re: MIPS - 64bit woes
Date: Fri, 18 Nov 2005 17:17:07 +0000	[thread overview]
Message-ID: <20051118171706.GD2707@linux-mips.org> (raw)
In-Reply-To: <437D2C97.8070804@jg555.com>

On Thu, Nov 17, 2005 at 05:21:27PM -0800, Jim Gifford wrote:

> Got a fix for 2.6.14, http://ftp.jg555.com/cobalt/fix-2.6.14.
> 
> Ralf, I know this is probably not the fix you would like to see, any 
> suggestions.
> 
> diff -Naur linux-mips-2.6.14.orig/arch/mips/kernel/cpu-probe.c 
> linux-mips-2.6.14/arch/mips/kernel/cpu-probe.c
> --- linux-mips-2.6.14.orig/arch/mips/kernel/cpu-probe.c    2005-11-17 
> 11:42:19.000000000 -0800
> +++ linux-mips-2.6.14/arch/mips/kernel/cpu-probe.c    2005-11-17 
> 15:00:11.000000000 -0800
> @@ -121,7 +105,6 @@
>     case CPU_24K:
>     case CPU_25KF:
>     case CPU_34K:
> -     case CPU_PR4450:
>         cpu_wait = r4k_wait;
>         printk(" available.\n");
>         break;

Ehhh?

As for the remainder of your patch - the fact that this actually works
made me notice that there is no cpu-features-override.h for Cobalt which
means that Cobalt kernels carry a rather heavyweight generic cachecode
including spinlocks and all sorts of atomic operations that will at
runtime select between ll/sc and non-ll/sc variants.  That's slow and
I would rather suggest you get rid of that overhead by simply
pretending not to have ll/sc at all on Cobalt but putting something like

#ifdef CONFIG_64BIT
#define cpu_has_llsc            0
#else
#define cpu_has_llsc            1
#endif

into the Cobalt cpu-features-override.h.

  Ralf

  reply	other threads:[~2005-11-18 17:16 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-11-05 18:56 MIPS - 64bit woes Jim Gifford
2005-11-05 23:19 ` Kumba
2005-11-07 22:22   ` Jim Gifford
2005-11-08  1:41     ` Stuart Anderson
2005-11-07 11:46 ` Maciej W. Rozycki
2005-11-08  0:51   ` Kumba
2005-11-09  8:51   ` Jim Gifford
2005-11-09 13:36     ` Kumba
2005-11-09 17:22       ` Jim Gifford
2005-11-15 15:17         ` Jim Gifford
2005-11-17 22:57           ` Jim Gifford
2005-11-18  1:21             ` Jim Gifford
2005-11-18 17:17               ` Ralf Baechle [this message]
2005-11-18 17:24                 ` Jim Gifford
2005-11-18 17:29                   ` Ralf Baechle
2005-11-19 17:36                     ` mips iomap.c (Was: Re: MIPS - 64bit woes) Atsushi Nemoto

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=20051118171706.GD2707@linux-mips.org \
    --to=ralf@linux-mips.org \
    --cc=kumba@gentoo.org \
    --cc=linux-mips@linux-mips.org \
    --cc=maillist@jg555.com \
    --cc=pdh@colonel-panic.org \
    /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