From: Hiroshi Miura <miura@da-cha.org>
To: davej@suse.de, miura@da-cha.org
Cc: hpa@zytor.com, linux-kernel@vger.kernel.org, alan@redhat.com
Subject: Re: NatSemi Geode improvement
Date: Fri, 18 Oct 2002 11:29:01 +0900 (JST) [thread overview]
Message-ID: <20021018022901.CA2D811782A@triton2> (raw)
In-Reply-To: Dave Jones's message of "Thu, 17 Oct 2002 19:20:41 +0200" <20021017192041.B17285@suse.de>
In message "Re: NatSemi Geode improvement"
on 02/10/17, Dave Jones <davej@suse.de> writes:
> On Fri, Oct 18, 2002 at 02:12:17AM +0900, Hiroshi Miura wrote:
>
> > NatSemi Geode has a several feature to speed up,
> > but reset defalut value is set to slow side.
> >
> > I make a patch to speed up Geode about 20-40%!!
> > the benchmark result is downloadable from http://www.da-cha.org/geode/geode_graph.sxc.
> > that is openoffice format.
> >
> > I use this patch with 2.4.18, 2.4.19 in 4 month, I think it is stable enough.
>
> Previously these tweaks were done in userspace with the set6x86 utility.
> Is there any reason that these need to be done in the kernel apart from
> convenience ?
I try now using set6x86 to set these registers, then can do most of these
except for set_cx86_memwb().
To set the memory write-back, I need to set the CR0 which needs special previlleges.
set6x86 cannot set CR0.
the set_cx86_memwb() need to be done in the kernel
the others has no reason to do that.
it is ok?
the follows are the set_cx86_memwb() code.
diff -urB -x .config -x '*.[oasS]' -x '*.in' -x '*.rej' -x '*.orig' linux-2.5.43-orig/arch/i386/kernel/apm.c linux-2.5.43/arch/i386/kernel/apm.c
diff -urB -x .config -x '*.[oasS]' -x '*.in' -x '*.rej' -x '*.orig' linux-2.5.43-orig/arch/i386/kernel/cpu/cyrix.c linux-2.5.43/arch/i386/kernel/cpu/cyrix.c
--- linux-2.5.43-orig/arch/i386/kernel/cpu/cyrix.c 2002-10-12 13:21:34.000000000 +0900
+++ linux-2.5.43/arch/i386/kernel/cpu/cyrix.c 2002-10-14 21:34:57.000000000 +0900
@@ -1,3 +1,7 @@
+/*
+ * NSC Geode improvments
+ * Hiroshi Miura <miura@da-cha.org>, June, 2002.
+ */
#include <linux/init.h>
#include <linux/bitops.h>
#include <linux/delay.h>
@@ -105,6 +109,27 @@
}
}
+static void __init set_cx86_memwb(void)
+{
+ unsigned long cr0;
+ unsigned long flags;
+
+ printk(KERN_INFO "Enable Memory-Write-back mode on Cyrix/NSC processor.\n");
+ local_irq_save(flags);
+ /* CCR2 bit 2: unlock NW bit */
+ setCx86(CX86_CCR2, getCx86(CX86_CCR2) & ~0x04);
+ /* set 'Not Write-through' */
+ cr0 = 0x20000000;
+ __asm__("movl %%cr0,%%eax\n\t"
+ "orl %0,%%eax\n\t"
+ "movl %%eax,%%cr0\n"
+ : : "r" (cr0)
+ :"ax");
+ /* CCR2 bit 2: lock NW bit and set WT1 */
+ setCx86(CX86_CCR2, getCx86(CX86_CCR2) | 0x14 );
+ local_irq_restore(flags);
+}
+
static void __init init_cyrix(struct cpuinfo_x86 *c)
{
unsigned char dir0, dir0_msn, dir0_lsn, dir1 = 0;
@@ -170,7 +233,7 @@
c->coma_bug = 1;
break;
- case 4: /* MediaGX/GXm */
+ case 4: /* MediaGX/GXm or Geode GXM/GXLV/GX1 */
#ifdef CONFIG_PCI
/* It isn't really a PCI quirk directly, but the cure is the
same. The MediaGX has deep magic SMM stuff that handles the
@@ -191,26 +250,30 @@
/* GXm supports extended cpuid levels 'ala' AMD */
if (c->cpuid_level == 2) {
- /* Enable Natsemi MMX extensions */
- setCx86(CX86_CCR7, getCx86(CX86_CCR7) | 1);
+ if (((0x54 >= dir1) && (dir1 >= 0x50))
+ || (dir1 >= 0x63)) { /* NSC Geode GXlv/GXm/GX1 */
+ set_cx86_memwb(); /* L2 cache write-back mode */
+ }
+ /* Enable cxMMX extensions (GX1 Datasheet 54) */
+ setCx86(CX86_CCR7, getCx86(CX86_CCR7)|1);
get_model_name(c); /* get CPU marketing name */
/*
* The 5510/5520 companion chips have a funky PIT
* that breaks the TSC synchronizing, so turn it off
*/
if (pci_find_device(PCI_VENDOR_ID_CYRIX, PCI_DEVICE_ID_CYRIX_5510, NULL) ||
pci_find_device(PCI_VENDOR_ID_CYRIX, PCI_DEVICE_ID_CYRIX_5520, NULL))
clear_bit(X86_FEATURE_TSC, c->x86_capability);
return;
}
else { /* MediaGX */
Cx86_cb[2] = (dir0_lsn & 1) ? '3' : '4';
p = Cx86_cb+2;
c->x86_model = (dir1 & 0x20) ? 1 : 2;
#ifndef CONFIG_CS5520
clear_bit(X86_FEATURE_TSC, c->x86_capability);
#endif
}
break;
--
Hiroshi Miura --- http://www.da-cha.org/
NTTDATA Corp. Marketing & Business Strategy Planning Dept. --- miurahr@nttdata.co.jp
Key fingerprint = 9117 9407 5684 FBF1 4063 15B4 401D D077 04AB 8617
-- My hacking life is happy as the day is long
next prev parent reply other threads:[~2002-10-18 2:23 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2002-10-17 17:12 Hiroshi Miura
2002-10-17 17:20 ` Dave Jones
2002-10-18 2:29 ` Hiroshi Miura [this message]
2002-10-18 12:10 ` Dave Jones
2002-10-18 17:32 ` H. Peter Anvin
2002-10-22 21:14 ` Alan Cox
2002-10-19 16:24 ` Bernhard Wesely
2002-10-21 14:06 ` Alan Cox
2002-10-22 0:12 ` Hiroshi Miura
2002-10-22 10:00 ` Alan Cox
[not found] <C0D45ABB3F45D5118BBC00508BC292DB9D427A@imgserv04>
2002-10-26 7:43 ` Hiroshi Miura
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=20021018022901.CA2D811782A@triton2 \
--to=miura@da-cha.org \
--cc=alan@redhat.com \
--cc=davej@suse.de \
--cc=hpa@zytor.com \
--cc=linux-kernel@vger.kernel.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
all inboxes | Powered by JetHome®