From macro@ds2.pg.gda.pl Tue Apr 2 12:32:46 2002 Received: (uucp@localhost) by guadalquivir.fnet.fr (8.8.8/97.02.12/Guadalquivir); id MAA07961; Tue, 2 Apr 2002 12:32:46 +0200 (MET DST) Received-Date: Tue, 2 Apr 2002 12:32:46 +0200 (MET DST) Received: from delta.ds2.pg.gda.pl(213.192.72.1) via SMTP by guadalquivir.fnet.fr, id smtpd007959; Tue Apr 2 12:32:39 2002 Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id MAA26298; Tue, 2 Apr 2002 12:32:44 +0200 (MET DST) Date: Tue, 2 Apr 2002 12:32:43 +0200 (MET DST) From: "Maciej W. Rozycki" To: Harald Koerfgen cc: Dave Airlie , Ralf Baechle , linux-mips@fnet.fr, linux-mips@oss.sgi.com Subject: Re: [patch] linux: declance multicast filter fixes In-Reply-To: Message-ID: Organization: Technical University of Gdansk MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Content-Length: 1250 Lines: 30 On Fri, 29 Mar 2002, Harald Koerfgen wrote: > > Why couldn't it do the same for the LANCE? > > Host memory addresses are generated on behalf of the LANCE by the I/O ASIC > > anyway. > > Probably because this would have made the IOASIC 0.0034 cents more expensive? I don't think that mattered to DEC that much. DEC customers were technically oriented and the design and engineering quality mattered much to them. The network performance certainly did. DECstations were not PCs. The reason might have been the lack of time or appropriate people available for the task. Or simply an oversight. > > Of course not all designers have a clue, sigh... A brief study of > > available documentation suggests no merging mode was implemented for the > > LANCE and bit 0 of addresses generated is simply hardwired to 0. :-( > > That's my interpretation as well. But we do not have a definite and complete I/O ASIC reference specs. Also note that the chip consists partly of general-purpose circuits which operation depends on the actual wiring. -- + Maciej W. Rozycki, Technical University of Gdansk, Poland + +--------------------------------------------------------------+ + e-mail: macro@ds2.pg.gda.pl, PGP key available + From nemoto@toshiba-tops.co.jp Thu Apr 4 04:56:35 2002 Received: (uucp@localhost) by guadalquivir.fnet.fr (8.8.8/97.02.12/Guadalquivir); id EAA03014; Thu, 4 Apr 2002 04:56:35 +0200 (MET DST) Received-Date: Thu, 4 Apr 2002 04:56:35 +0200 (MET DST) Received: from topsns.toshiba-tops.co.jp(202.230.225.5) via SMTP by guadalquivir.fnet.fr, id smtpd003012; Thu Apr 4 04:56:33 2002 Received: from inside-ms1.toshiba-tops.co.jp by topsns.toshiba-tops.co.jp via smtpd (for guadalquivir.fnet.fr [193.104.112.133]) with SMTP; 4 Apr 2002 02:56:31 UT Received: from srd2sd.toshiba-tops.co.jp (gw-chiba7.toshiba-tops.co.jp [172.17.244.27]) by topsms.toshiba-tops.co.jp (Postfix) with ESMTP id 4A8F4B474; Thu, 4 Apr 2002 11:56:23 +0900 (JST) Received: by srd2sd.toshiba-tops.co.jp (8.9.3/3.5Wbeta-srd2sd) with ESMTP id LAA26309; Thu, 4 Apr 2002 11:56:23 +0900 (JST) Date: Thu, 04 Apr 2002 11:56:18 +0900 (JST) Message-Id: <20020404.115618.74756287.nemoto@toshiba-tops.co.jp> To: linux-mips@oss.sgi.com, linux-mips@fnet.fr Subject: gcc 2.95.3 optimization bug From: Atsushi Nemoto X-Fingerprint: EC 9D B9 17 2E 89 D2 25 CE F5 5D 3D 12 29 2A AD X-Pgp-Public-Key: http://pgp.nic.ad.jp/cgi-bin/pgpsearchkey.pl?op=get&search=0xB6D728B1 Organization: TOSHIBA Personal Computer System Corporation X-Mailer: Mew version 2.2 on Emacs 20.7 / Mule 4.1 (AOI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Length: 1912 Lines: 124 I found gcc 2.95.3 generates bad code when optimizing redundant switch statement. I'm using RPM package (gcc-2.95.3-19.mipsel.rpm or gcc-2.95.3-22.mipsel.rpm) by Maciej W. Rozycki (Thank you). Here is a sample source code. Compiling this with -O2 generates bad result (-O1 is OK). --- foo.c --- int foo(int a, int b, int c) { int t; switch(c) { case 0: case 1: case 3: t = 4; break; case 2: t = 1; break; case 4: t = 3; break; default: return 0; } return a * b; } --- foo.c --- This is output of "gcc -o foo.s -O2 -S foo.s". Obviously this codes is wrong. Neither "mult" nor "j $31" exist in this function!! --- foo.s (-O2) --- .file 1 "foo.c" .abicalls .version "01.01" gcc2_compiled.: .text .align 2 .globl foo .ent foo foo: .frame $sp,0,$31 # vars= 0, regs= 0/0, args= 0, extra= 0 .mask 0x00000000,0 .fmask 0x00000000,0 .set noreorder .cpload $25 .set reorder sltu $6,$6,5 .end foo --- foo.s (-O2) --- This is output of "gcc -o foo.s -O1 -S foo.s". This looks fine. --- foo.s (-O1) --- .file 1 "foo.c" .abicalls .version "01.01" gcc2_compiled.: .text .align 2 .globl foo .ent foo foo: .frame $sp,0,$31 # vars= 0, regs= 0/0, args= 0, extra= 0 .mask 0x00000000,0 .fmask 0x00000000,0 .set noreorder .cpload $25 .set reorder sltu $2,$6,5 .set noreorder .set nomacro beq $2,$0,$L9 sll $2,$6,2 .set macro .set reorder lw $2,$L10($2) .set noreorder .set nomacro j $L12 mult $4,$5 .set macro .set reorder .rdata .align 3 $L10: .gpword $L3 .gpword $L3 .gpword $L3 .gpword $L3 .gpword $L3 .text $L9: .set noreorder .set nomacro j $31 move $2,$0 .set macro .set reorder $L3: mult $4,$5 $L12: mflo $2 #nop j $31 .end foo --- foo.s (-O1) --- I tested with a cross compiler (mipsel-linux-gcc-2.95.3-22.i386.rpm) and got same results. Also gcc-2.96-99 (packaged by H.J.Lu) seems not have this problem. --- Atsushi Nemoto From macro@ds2.pg.gda.pl Mon Apr 8 19:40:49 2002 Received: (uucp@localhost) by guadalquivir.fnet.fr (8.8.8/97.02.12/Guadalquivir); id TAA15718; Mon, 8 Apr 2002 19:40:49 +0200 (MET DST) Received-Date: Mon, 8 Apr 2002 19:40:49 +0200 (MET DST) Received: from delta.ds2.pg.gda.pl(213.192.72.1) via SMTP by guadalquivir.fnet.fr, id smtpdb15709; Mon Apr 8 19:40:47 2002 Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id SAA08007; Mon, 8 Apr 2002 18:37:30 +0200 (MET DST) Date: Mon, 8 Apr 2002 18:37:30 +0200 (MET DST) From: "Maciej W. Rozycki" To: Ralf Baechle cc: linux-mips@fnet.fr, linux-mips@oss.sgi.com Subject: [patch] linux: A correct implementation of barriers Message-ID: Organization: Technical University of Gdansk MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Content-Length: 6395 Lines: 246 Hello, Here is the barrier patch again. It was discussed quite extensively a few weeks ago. It makes rmb(), wmb() and mb() use sync as needed (Tx39xx included) and take writeback buffers into account (no Tx39xx code here -- someone interested in such a system should add it). It also adds iob() for code that needs to assure not only the order of the preceding and the following operations but also the completion of the preceding ones as well (from the CPU's point of view). Please apply. Maciej -- + Maciej W. Rozycki, Technical University of Gdansk, Poland + +--------------------------------------------------------------+ + e-mail: macro@ds2.pg.gda.pl, PGP key available + patch-mips-2.4.17-20020129-mb-wb-6 diff -up --recursive --new-file linux-mips-2.4.17-20020129.macro/arch/mips/config.in linux-mips-2.4.17-20020129/arch/mips/config.in --- linux-mips-2.4.17-20020129.macro/arch/mips/config.in Fri Jan 25 05:26:34 2002 +++ linux-mips-2.4.17-20020129/arch/mips/config.in Thu Feb 21 21:31:42 2002 @@ -384,6 +384,11 @@ else fi fi fi +if [ "$CONFIG_CPU_R3000" = "y" ]; then + define_bool CONFIG_CPU_HAS_SYNC n +else + define_bool CONFIG_CPU_HAS_SYNC y +fi endmenu mainmenu_option next_comment diff -up --recursive --new-file linux-mips-2.4.17-20020129.macro/include/asm-mips/system.h linux-mips-2.4.17-20020129/include/asm-mips/system.h --- linux-mips-2.4.17-20020129.macro/include/asm-mips/system.h Sun Jan 27 05:27:59 2002 +++ linux-mips-2.4.17-20020129/include/asm-mips/system.h Thu Feb 21 21:33:54 2002 @@ -18,9 +18,12 @@ #include #include -#include + #include +#include +#include + __asm__ ( ".macro\t__sti\n\t" ".set\tpush\n\t" @@ -166,32 +169,58 @@ extern void __global_restore_flags(unsig #define local_irq_disable() __cli(); #define local_irq_enable() __sti(); -/* - * These are probably defined overly paranoid ... - */ +#ifdef CONFIG_CPU_HAS_SYNC +#define __sync() \ + __asm__ __volatile__( \ + ".set push\n\t" \ + ".set noreorder\n\t" \ + ".set mips2\n\t" \ + "sync\n\t" \ + ".set pop" \ + : /* no output */ \ + : /* no input */ \ + : "memory") +#else +#define __sync() do { } while(0) +#endif + +#define __fast_iob() \ + __asm__ __volatile__( \ + ".set push\n\t" \ + ".set noreorder\n\t" \ + "lw $0,%0\n\t" \ + "nop\n\t" \ + ".set pop" \ + : /* no output */ \ + : "m" (*(int *)KSEG1) \ + : "memory") + +#define fast_wmb() __sync() +#define fast_rmb() __sync() +#define fast_mb() __sync() +#define fast_iob() \ + do { \ + __sync(); \ + __fast_iob(); \ + } while (0) + #ifdef CONFIG_CPU_HAS_WB #include -#define rmb() do { } while(0) -#define wmb() wbflush() -#define mb() wbflush() - -#else /* CONFIG_CPU_HAS_WB */ - -#define mb() \ -__asm__ __volatile__( \ - "# prevent instructions being moved around\n\t" \ - ".set\tnoreorder\n\t" \ - "# 8 nops to fool the R4400 pipeline\n\t" \ - "nop;nop;nop;nop;nop;nop;nop;nop\n\t" \ - ".set\treorder" \ - : /* no output */ \ - : /* no input */ \ - : "memory") -#define rmb() mb() -#define wmb() mb() -#endif /* CONFIG_CPU_HAS_WB */ +#define wmb() fast_wmb() +#define rmb() fast_rmb() +#define mb() wbflush(); +#define iob() wbflush(); + +#else /* !CONFIG_CPU_HAS_WB */ + +#define wmb() fast_wmb() +#define rmb() fast_rmb() +#define mb() fast_mb() +#define iob() fast_iob() + +#endif /* !CONFIG_CPU_HAS_WB */ #ifdef CONFIG_SMP #define smp_mb() mb() diff -up --recursive --new-file linux-mips-2.4.17-20020129.macro/include/asm-mips/wbflush.h linux-mips-2.4.17-20020129/include/asm-mips/wbflush.h --- linux-mips-2.4.17-20020129.macro/include/asm-mips/wbflush.h Fri Sep 7 04:26:33 2001 +++ linux-mips-2.4.17-20020129/include/asm-mips/wbflush.h Mon Feb 4 02:52:11 2002 @@ -6,29 +6,30 @@ * for more details. * * Copyright (c) 1998 Harald Koerfgen + * Copyright (C) 2002 Maciej W. Rozycki */ #ifndef __ASM_MIPS_WBFLUSH_H #define __ASM_MIPS_WBFLUSH_H #include -#if defined(CONFIG_CPU_HAS_WB) -/* - * R2000 or R3000 - */ -extern void (*__wbflush) (void); +#ifdef CONFIG_CPU_HAS_WB -#define wbflush() __wbflush() +extern void (*__wbflush)(void); +extern void wbflush_setup(void); -#else -/* - * we don't need no stinkin' wbflush - */ +#define wbflush() \ + do { \ + __sync(); \ + __wbflush(); \ + } while (0) -#define wbflush() do { } while(0) +#else /* !CONFIG_CPU_HAS_WB */ -#endif +#define wbflush_setup() do { } while (0) -extern void wbflush_setup(void); +#define wbflush() fast_iob() + +#endif /* !CONFIG_CPU_HAS_WB */ #endif /* __ASM_MIPS_WBFLUSH_H */ diff -up --recursive --new-file linux-mips-2.4.17-20020129.macro/include/asm-mips64/system.h linux-mips-2.4.17-20020129/include/asm-mips64/system.h --- linux-mips-2.4.17-20020129.macro/include/asm-mips64/system.h Sun Jan 27 05:27:59 2002 +++ linux-mips-2.4.17-20020129/include/asm-mips64/system.h Mon Feb 4 02:12:27 2002 @@ -11,12 +11,13 @@ #define _ASM_SYSTEM_H #include - #include -#include #include +#include +#include + __asm__ ( ".macro\t__sti\n\t" ".set\tpush\n\t" @@ -163,20 +164,32 @@ extern void __global_restore_flags(unsig #define local_irq_disable() __cli(); #define local_irq_enable() __sti(); -/* - * These are probably defined overly paranoid ... - */ -#define mb() \ -__asm__ __volatile__( \ - "# prevent instructions being moved around\n\t" \ - ".set\tnoreorder\n\t" \ - "sync\n\t" \ - ".set\treorder" \ - : /* no output */ \ - : /* no input */ \ - : "memory") -#define rmb() mb() -#define wmb() mb() +#define __sync() \ + __asm__ __volatile__( \ + ".set push\n\t" \ + ".set noreorder\n\t" \ + "sync\n\t" \ + ".set pop" \ + : /* no output */ \ + : /* no input */ \ + : "memory") + +#define wmb() __sync() +#define rmb() __sync() +#define mb() __sync() +#define iob() \ + do { \ + __sync(); \ + __asm__ __volatile__( \ + ".set push\n\t" \ + ".set noreorder\n\t" \ + "lw $0,%0\n\t" \ + "nop\n\t" \ + ".set pop" \ + : /* no output */ \ + : "m" (*(int *)KSEG1) \ + : "memory"); \ + } while (0) #ifdef CONFIG_SMP #define smp_mb() mb() From macro@ds2.pg.gda.pl Mon Apr 8 19:40:49 2002 Received: (uucp@localhost) by guadalquivir.fnet.fr (8.8.8/97.02.12/Guadalquivir); id TAA15717; Mon, 8 Apr 2002 19:40:49 +0200 (MET DST) Received-Date: Mon, 8 Apr 2002 19:40:49 +0200 (MET DST) Received: from delta.ds2.pg.gda.pl(213.192.72.1) via SMTP by guadalquivir.fnet.fr, id smtpda15709; Mon Apr 8 19:40:44 2002 Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id TAA08632; Mon, 8 Apr 2002 19:04:13 +0200 (MET DST) Date: Mon, 8 Apr 2002 19:04:12 +0200 (MET DST) From: "Maciej W. Rozycki" To: Ralf Baechle cc: linux-mips@fnet.fr, linux-mips@oss.sgi.com Subject: [patch] linux: New style IRQs for DECstation Message-ID: Organization: Technical University of Gdansk MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Content-Length: 1616 Lines: 38 Hello, Here is code that implements new style IRQ handlers for DECstation. Beside obvious things, like mask/unmask, etc. functions it adds IRQ routing tables for individual systems (including somewhat more complete basic support for the 5100) so that device drivers for onboard devices do not have to code IRQ guesswork based on model types. I tried to make hardware documentation more complete as well as its external sources are scarce to say at least, so it might be best to keep bits described within the code that deals with them. Also included there are a few updates to generic code: 1. A few clean-ups to arch/mips/kernel/irq_cpu.c. Just a five minute approach to fix obvious things. A deeper action is needed, in particular locking is missing altogether. 2. A new mips_cpu option to denote the dedicated FPU exception is present as there is currently no sane way to conclude whether it's available or not. 3. A few missing header inclusions. Actually the code is nothing new, but since I'm resubmitting it and a few people confirmed their interest in the DECstation port since the previous submission, I'm making the patch available to the public. I'm running the code since mid January successfully with only a few minor fixes since then. Due to a relatively large size the patch is available here: 'ftp://ftp.ds2.pg.gda.pl/pub/macro/linux/patch-mips-2.4.18-20020402-irq-48.gz'. Maciej -- + Maciej W. Rozycki, Technical University of Gdansk, Poland + +--------------------------------------------------------------+ + e-mail: macro@ds2.pg.gda.pl, PGP key available + From macro@ds2.pg.gda.pl Mon Apr 8 19:40:49 2002 Received: (uucp@localhost) by guadalquivir.fnet.fr (8.8.8/97.02.12/Guadalquivir); id TAA15716; Mon, 8 Apr 2002 19:40:49 +0200 (MET DST) Received-Date: Mon, 8 Apr 2002 19:40:49 +0200 (MET DST) Received: from delta.ds2.pg.gda.pl(213.192.72.1) via SMTP by guadalquivir.fnet.fr, id smtpd015709; Mon Apr 8 19:40:27 2002 Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id TAA08974; Mon, 8 Apr 2002 19:16:06 +0200 (MET DST) Date: Mon, 8 Apr 2002 19:16:05 +0200 (MET DST) From: "Maciej W. Rozycki" To: Ralf Baechle cc: linux-mips@fnet.fr, linux-mips@oss.sgi.com Subject: [patch] linux: A wbflush() rework Message-ID: Organization: Technical University of Gdansk MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Content-Length: 14570 Lines: 460 Hello, Here is a rework of the wbflush() that makes code use iob() and possibly fast_iob() where appropriate. Additionally the DECstation __wbflush() backends are updated to match reality, yielding better and reliability performance for I/O ASIC systems. The code is needed specifically for R4k not to generate an excessive number of spurious interrupts on DECstation. The code applies on top of the "mb-wb" and "irq" patches. Please apply. Maciej -- + Maciej W. Rozycki, Technical University of Gdansk, Poland + +--------------------------------------------------------------+ + e-mail: macro@ds2.pg.gda.pl, PGP key available + patch-mips-2.4.18-20020323-wbflush-3 diff -up --recursive --new-file linux-mips-2.4.18-20020323.macro/arch/mips/dec/Makefile linux-mips-2.4.18-20020323/arch/mips/dec/Makefile --- linux-mips-2.4.18-20020323.macro/arch/mips/dec/Makefile Tue Jan 22 07:32:00 2002 +++ linux-mips-2.4.18-20020323/arch/mips/dec/Makefile Mon Feb 4 01:06:32 2002 @@ -17,9 +17,10 @@ all: dec.o export-objs := setup.o wbflush.o obj-y := int-handler.o ioasic-irq.o kn02-irq.o reset.o rtc-dec.o setup.o \ - time.o wbflush.o + time.o obj-$(CONFIG_PROM_CONSOLE) += promcon.o +obj-$(CONFIG_CPU_HAS_WB) += wbflush.o int-handler.o: int-handler.S diff -up --recursive --new-file linux-mips-2.4.18-20020323.macro/arch/mips/dec/ioasic-irq.c linux-mips-2.4.18-20020323/arch/mips/dec/ioasic-irq.c --- linux-mips-2.4.18-20020323.macro/arch/mips/dec/ioasic-irq.c Tue Jan 22 06:44:47 2002 +++ linux-mips-2.4.18-20020323/arch/mips/dec/ioasic-irq.c Mon Feb 4 01:00:53 2002 @@ -84,6 +84,7 @@ static inline void ack_ioasic_irq(unsign spin_lock(&ioasic_lock); mask_ioasic_irq(irq); spin_unlock(&ioasic_lock); + fast_iob(); } static inline void end_ioasic_irq(unsigned int irq) @@ -119,6 +120,7 @@ static struct hw_interrupt_type ioasic_i static inline void end_ioasic_dma_irq(unsigned int irq) { clear_ioasic_irq(irq); + fast_iob(); end_ioasic_irq(irq); } @@ -142,6 +144,7 @@ void __init init_ioasic_irqs(int base) /* Mask interrupts. */ ioasic_write(SIMR, 0); + fast_iob(); for (i = base; i < base + IO_INR_DMA; i++) { irq_desc[i].status = IRQ_DISABLED; diff -up --recursive --new-file linux-mips-2.4.18-20020323.macro/arch/mips/dec/kn02-irq.c linux-mips-2.4.18-20020323/arch/mips/dec/kn02-irq.c --- linux-mips-2.4.18-20020323.macro/arch/mips/dec/kn02-irq.c Tue Jan 22 06:47:34 2002 +++ linux-mips-2.4.18-20020323/arch/mips/dec/kn02-irq.c Mon Feb 4 01:01:59 2002 @@ -83,6 +83,7 @@ static void ack_kn02_irq(unsigned int ir spin_lock(&kn02_lock); mask_kn02_irq(irq); spin_unlock(&kn02_lock); + iob(); } static void end_kn02_irq(unsigned int irq) @@ -113,6 +114,7 @@ void __init init_kn02_irqs(int base) /* Mask interrupts and preset write-only bits. */ cached_kn02_csr = (*csr & ~0xff0000) | 0xff; *csr = cached_kn02_csr; + iob(); for (i = base; i < base + KN02_IRQ_LINES; i++) { irq_desc[i].status = IRQ_DISABLED; diff -up --recursive --new-file linux-mips-2.4.18-20020323.macro/arch/mips/dec/setup.c linux-mips-2.4.18-20020323/arch/mips/dec/setup.c --- linux-mips-2.4.18-20020323.macro/arch/mips/dec/setup.c Tue Jan 22 07:31:08 2002 +++ linux-mips-2.4.18-20020323/arch/mips/dec/setup.c Mon Feb 4 01:10:36 2002 @@ -24,6 +24,7 @@ #include #include #include +#include #include #include @@ -87,8 +88,6 @@ static struct irqaction fpuirq = {NULL, static struct irqaction haltirq = {dec_intr_halt, 0, 0, "halt", NULL, NULL}; - -extern void wbflush_setup(void); extern struct rtc_ops dec_rtc_ops; diff -up --recursive --new-file linux-mips-2.4.18-20020323.macro/arch/mips/dec/wbflush.c linux-mips-2.4.18-20020323/arch/mips/dec/wbflush.c --- linux-mips-2.4.18-20020323.macro/arch/mips/dec/wbflush.c Tue Nov 6 05:26:15 2001 +++ linux-mips-2.4.18-20020323/arch/mips/dec/wbflush.c Mon Feb 4 01:03:17 2002 @@ -11,15 +11,18 @@ * for more details. * * Copyright (C) 1998 Harald Koerfgen + * Copyright (C) 2002 Maciej W. Rozycki */ -#include #include +#include +#include +#include + static void wbflush_kn01(void); static void wbflush_kn210(void); -static void wbflush_kn02ba(void); -static void wbflush_kn03(void); +static void wbflush_mips(void); void (*__wbflush) (void); @@ -27,28 +30,23 @@ void __init wbflush_setup(void) { switch (mips_machtype) { case MACH_DS23100: - __wbflush = wbflush_kn01; - break; - case MACH_DS5100: /* DS5100 MIPSMATE */ - __wbflush = wbflush_kn210; - break; case MACH_DS5000_200: /* DS5000 3max */ - __wbflush = wbflush_kn01; - break; + __wbflush = wbflush_kn01; + break; + case MACH_DS5100: /* DS5100 MIPSMATE */ + __wbflush = wbflush_kn210; + break; case MACH_DS5000_1XX: /* DS5000/100 3min */ - __wbflush = wbflush_kn02ba; - break; - case MACH_DS5000_2X0: /* DS5000/240 3max+ */ - __wbflush = wbflush_kn03; - break; case MACH_DS5000_XX: /* Personal DS5000/2x */ - __wbflush = wbflush_kn02ba; - break; + case MACH_DS5000_2X0: /* DS5000/240 3max+ */ + default: + __wbflush = wbflush_mips; + break; } } /* - * For the DS3100 and DS5000/200 the writeback buffer functions + * For the DS3100 and DS5000/200 the R2020/R3220 writeback buffer functions * as part of Coprocessor 0. */ static void wbflush_kn01(void) @@ -78,29 +76,16 @@ static void wbflush_kn210(void) "mtc0\t$2,$12\n\t" "nop\n\t" ".set\tpop" - : : :"$2", "$3"); -} - -/* - * Looks like some magic with the System Interrupt Mask Register - * in the famous IOASIC for kmins and maxines. - */ -static void wbflush_kn02ba(void) -{ - asm(".set\tpush\n\t" - ".set\tnoreorder\n\t" - "lui\t$2,0xbc04\n\t" - "lw\t$3,0x120($2)\n\t" - "lw\t$3,0x120($2)\n\t" - ".set\tpop" - : : :"$2", "$3"); + : : : "$2", "$3"); } /* - * The DS500/2x0 doesnt need to write back the WB. + * I/O ASIC systems use a standard writeback buffer that gets flushed + * upon an uncached read. */ -static void wbflush_kn03(void) +static void wbflush_mips(void) { + __fast_iob(); } #include diff -up --recursive --new-file linux-mips-2.4.18-20020323.macro/arch/mips/mm/c-r3k.c linux-mips-2.4.18-20020323/arch/mips/mm/c-r3k.c --- linux-mips-2.4.18-20020323.macro/arch/mips/mm/c-r3k.c Tue Feb 19 05:28:14 2002 +++ linux-mips-2.4.18-20020323/arch/mips/mm/c-r3k.c Sun Mar 24 21:16:14 2002 @@ -19,7 +19,6 @@ #include #include #include -#include #include #include @@ -314,7 +313,7 @@ static void r3k_flush_cache_sigtramp(uns static void r3k_dma_cache_wback_inv(unsigned long start, unsigned long size) { - wbflush(); + iob(); r3k_flush_dcache_range(start, start + size); } diff -up --recursive --new-file linux-mips-2.4.18-20020323.macro/arch/mips/mm/c-tx39.c linux-mips-2.4.18-20020323/arch/mips/mm/c-tx39.c --- linux-mips-2.4.18-20020323.macro/arch/mips/mm/c-tx39.c Sat Dec 1 05:26:01 2001 +++ linux-mips-2.4.18-20020323/arch/mips/mm/c-tx39.c Mon Feb 4 01:12:41 2002 @@ -20,7 +20,6 @@ #include #include #include -#include #include #include @@ -63,8 +62,8 @@ static void tx39h_flush_icache_all(void) static void tx39h_dma_cache_wback_inv(unsigned long addr, unsigned long size) { unsigned long end, a; - wbflush(); + iob(); a = addr & ~(dcache_lsize - 1); end = (addr + size) & ~(dcache_lsize - 1); while (1) { diff -up --recursive --new-file linux-mips-2.4.18-20020323.macro/arch/mips/mm/tlb-r3k.c linux-mips-2.4.18-20020323/arch/mips/mm/tlb-r3k.c --- linux-mips-2.4.18-20020323.macro/arch/mips/mm/tlb-r3k.c Fri Jan 18 05:28:05 2002 +++ linux-mips-2.4.18-20020323/arch/mips/mm/tlb-r3k.c Mon Feb 4 00:59:46 2002 @@ -19,7 +19,6 @@ #include #include #include -#include #include #include diff -up --recursive --new-file linux-mips-2.4.18-20020323.macro/drivers/char/dz.c linux-mips-2.4.18-20020323/drivers/char/dz.c --- linux-mips-2.4.18-20020323.macro/drivers/char/dz.c Sun Jan 20 21:37:53 2002 +++ linux-mips-2.4.18-20020323/drivers/char/dz.c Mon Feb 4 01:13:30 2002 @@ -35,7 +35,6 @@ #include #include #include -#include #include #include @@ -53,6 +52,8 @@ #include #include +#include + #define CONSOLE_LINE (3) /* for definition of struct console */ extern int (*prom_printf) (char *,...); @@ -1420,7 +1421,7 @@ int __init dz_init(void) #ifndef CONFIG_SERIAL_CONSOLE dz_out(info, DZ_CSR, DZ_CLR); while ((tmp = dz_in(info, DZ_CSR)) & DZ_CLR); - wbflush(); + iob(); /* enable scanning */ dz_out(info, DZ_CSR, DZ_MSE); diff -up --recursive --new-file linux-mips-2.4.18-20020323.macro/drivers/net/declance.c linux-mips-2.4.18-20020323/drivers/net/declance.c --- linux-mips-2.4.18-20020323.macro/drivers/net/declance.c Sun Mar 24 20:58:18 2002 +++ linux-mips-2.4.18-20020323/drivers/net/declance.c Sun Mar 24 21:16:14 2002 @@ -60,7 +60,7 @@ static char *lancestr = "lance"; #include #include #include -#include +#include #include #include @@ -306,7 +306,7 @@ int dec_lance_debug = 2; static inline void writereg(volatile unsigned short *regptr, short value) { *regptr = value; - wbflush(); + iob(); } /* Load the CSR registers */ @@ -386,7 +386,7 @@ void cp_to_buf(void *to, const void *fro } } - wbflush(); + iob(); } void cp_from_buf(void *to, unsigned char *from, int len) @@ -514,7 +514,7 @@ static void lance_init_ring(struct net_d if (i < 3 && ZERO) printk("%d: 0x%8.8x(0x%8.8x)\n", i, leptr, (int) lp->rx_buf_ptr_cpu[i]); } - wbflush(); + iob(); } static int init_restart_lance(struct lance_private *lp) @@ -1084,7 +1084,7 @@ static int __init dec_lance_init(struct lp->dma_ptr_reg = (unsigned long *) (system_base + IOCTL + LANCE_DMA_P); *(lp->dma_ptr_reg) = PHYSADDR(dev->mem_start) << 3; *(unsigned long *) (system_base + IOCTL + SSR) |= (1 << 16); - wbflush(); + fast_iob(); break; case PMAD_LANCE: diff -up --recursive --new-file linux-mips-2.4.18-20020323.macro/drivers/scsi/NCR53C9x.h linux-mips-2.4.18-20020323/drivers/scsi/NCR53C9x.h --- linux-mips-2.4.18-20020323.macro/drivers/scsi/NCR53C9x.h Fri Oct 19 04:29:11 2001 +++ linux-mips-2.4.18-20020323/drivers/scsi/NCR53C9x.h Mon Feb 4 01:14:34 2002 @@ -144,12 +144,7 @@ #ifndef MULTIPLE_PAD_SIZES -#ifdef CONFIG_CPU_HAS_WB -#include -#define esp_write(__reg, __val) do{(__reg) = (__val); wbflush();} while(0) -#else -#define esp_write(__reg, __val) ((__reg) = (__val)) -#endif +#define esp_write(__reg, __val) do{(__reg) = (__val); iob();} while(0) #define esp_read(__reg) (__reg) struct ESP_regs { diff -up --recursive --new-file linux-mips-2.4.18-20020323.macro/drivers/scsi/dec_esp.c linux-mips-2.4.18-20020323/drivers/scsi/dec_esp.c --- linux-mips-2.4.18-20020323.macro/drivers/scsi/dec_esp.c Tue Jan 22 03:06:51 2002 +++ linux-mips-2.4.18-20020323/drivers/scsi/dec_esp.c Mon Feb 4 01:15:48 2002 @@ -46,6 +46,8 @@ #include #include +#include + /* * Once upon a time the pmaz code used to be working but * it hasn't been maintained for quite some time. @@ -308,17 +310,9 @@ static void scsi_dma_err_int(int irq, vo static void scsi_dma_int(int irq, void *dev_id, struct pt_regs *regs) { - volatile unsigned int *dummy = (volatile unsigned int *)KSEG1; - /* next page */ *scsi_next_ptr = ((*scsi_dma_ptr + PAGE_SIZE) & PAGE_MASK) << 3; - - /* - * This routine will only work on IOASIC machines - * so we can avoid an indirect function call here - * and flush the writeback buffer the fast way - */ - *dummy; + fast_iob(); } static int dma_bytes_sent(struct NCR_ESP *esp, int fifo_count) @@ -370,8 +364,6 @@ static void dma_dump_state(struct NCR_ES static void dma_init_read(struct NCR_ESP *esp, __u32 vaddress, int length) { - volatile unsigned int *dummy = (volatile unsigned int *)KSEG1; - if (vaddress & 3) panic("dec_efs.c: unable to handle partial word transfers, yet..."); @@ -384,17 +376,11 @@ static void dma_init_read(struct NCR_ESP /* prepare for next page */ *scsi_next_ptr = ((vaddress + PAGE_SIZE) & PAGE_MASK) << 3; *ioasic_ssr |= (SCSI_DMA_DIR | SCSI_DMA_EN); - - /* - * see above - */ - *dummy; + fast_iob(); } static void dma_init_write(struct NCR_ESP *esp, __u32 vaddress, int length) { - volatile unsigned int *dummy = (volatile unsigned int *)KSEG1; - if (vaddress & 3) panic("dec_efs.c: unable to handle partial word transfers, yet..."); @@ -407,11 +393,7 @@ static void dma_init_write(struct NCR_ES /* prepare for next page */ *scsi_next_ptr = ((vaddress + PAGE_SIZE) & PAGE_MASK) << 3; *ioasic_ssr |= SCSI_DMA_EN; - - /* - * see above - */ - *dummy; + fast_iob(); } static void dma_ints_off(struct NCR_ESP *esp) diff -up --recursive --new-file linux-mips-2.4.18-20020323.macro/drivers/tc/zs.c linux-mips-2.4.18-20020323/drivers/tc/zs.c --- linux-mips-2.4.18-20020323.macro/drivers/tc/zs.c Sun Mar 24 21:02:44 2002 +++ linux-mips-2.4.18-20020323/drivers/tc/zs.c Sun Mar 24 21:16:14 2002 @@ -67,7 +67,6 @@ #include #include #include -#include #include #ifdef CONFIG_DECSTATION #include @@ -276,7 +275,7 @@ static inline unsigned char read_zsreg(s if (reg != 0) { *channel->control = reg & 0xf; - wbflush(); RECOVERY_DELAY; + fast_iob(); RECOVERY_DELAY; } retval = *channel->control; RECOVERY_DELAY; @@ -288,10 +287,10 @@ static inline void write_zsreg(struct de { if (reg != 0) { *channel->control = reg & 0xf; - wbflush(); RECOVERY_DELAY; + fast_iob(); RECOVERY_DELAY; } *channel->control = value; - wbflush(); RECOVERY_DELAY; + fast_iob(); RECOVERY_DELAY; return; } @@ -308,7 +307,7 @@ static inline void write_zsdata(struct d unsigned char value) { *channel->data = value; - wbflush(); RECOVERY_DELAY; + fast_iob(); RECOVERY_DELAY; return; } From jsun@mvista.com Mon Apr 8 19:49:00 2002 Received: (uucp@localhost) by guadalquivir.fnet.fr (8.8.8/97.02.12/Guadalquivir); id TAA18365; Mon, 8 Apr 2002 19:49:00 +0200 (MET DST) Received-Date: Mon, 8 Apr 2002 19:49:00 +0200 (MET DST) Received: from gateway-1237.mvista.com(12.44.186.158), claiming to be "av.mvista.com" via SMTP by guadalquivir.fnet.fr, id smtpd018182; Mon Apr 8 19:48:52 2002 Received: from mvista.com (av [127.0.0.1]) by av.mvista.com (8.9.3/8.9.3) with ESMTP id SAA20739; Mon, 8 Apr 2002 18:58:31 -0700 Message-ID: <3CB1D7E6.5010804@mvista.com> Date: Mon, 08 Apr 2002 10:48:22 -0700 From: Jun Sun User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.4) Gecko/20011126 Netscape6/6.2.1 X-Accept-Language: en-us MIME-Version: 1.0 To: "Maciej W. Rozycki" CC: Ralf Baechle , linux-mips@fnet.fr, linux-mips@oss.sgi.com Subject: Re: [patch] linux: New style IRQs for DECstation References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Length: 1668 Lines: 45 What is the intention of introducing MIPS_CPU_FPUEX? It seems an overkill if it is just needed by DecStation. How many CPUs really need this? Jun Maciej W. Rozycki wrote: > Hello, > > Here is code that implements new style IRQ handlers for DECstation. > Beside obvious things, like mask/unmask, etc. functions it adds IRQ > routing tables for individual systems (including somewhat more complete > basic support for the 5100) so that device drivers for onboard devices do > not have to code IRQ guesswork based on model types. I tried to make > hardware documentation more complete as well as its external sources are > scarce to say at least, so it might be best to keep bits described within > the code that deals with them. > > Also included there are a few updates to generic code: > > 1. A few clean-ups to arch/mips/kernel/irq_cpu.c. Just a five minute > approach to fix obvious things. A deeper action is needed, in particular > locking is missing altogether. > > 2. A new mips_cpu option to denote the dedicated FPU exception is present > as there is currently no sane way to conclude whether it's available or > not. > > 3. A few missing header inclusions. > > Actually the code is nothing new, but since I'm resubmitting it and a few > people confirmed their interest in the DECstation port since the previous > submission, I'm making the patch available to the public. I'm running the > code since mid January successfully with only a few minor fixes since > then. > > Due to a relatively large size the patch is available here: > 'ftp://ftp.ds2.pg.gda.pl/pub/macro/linux/patch-mips-2.4.18-20020402-irq-48.gz'. > > Maciej > > From macro@ds2.pg.gda.pl Mon Apr 8 20:03:38 2002 Received: (uucp@localhost) by guadalquivir.fnet.fr (8.8.8/97.02.12/Guadalquivir); id UAA20854; Mon, 8 Apr 2002 20:03:38 +0200 (MET DST) Received-Date: Mon, 8 Apr 2002 20:03:38 +0200 (MET DST) Received: from delta.ds2.pg.gda.pl(213.192.72.1) via SMTP by guadalquivir.fnet.fr, id smtpd020852; Mon Apr 8 20:03:33 2002 Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id UAA10414; Mon, 8 Apr 2002 20:03:45 +0200 (MET DST) Date: Mon, 8 Apr 2002 20:03:43 +0200 (MET DST) From: "Maciej W. Rozycki" To: Jun Sun cc: Ralf Baechle , linux-mips@fnet.fr, linux-mips@oss.sgi.com Subject: Re: [patch] linux: New style IRQs for DECstation In-Reply-To: <3CB1D7E6.5010804@mvista.com> Message-ID: Organization: Technical University of Gdansk MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Content-Length: 924 Lines: 21 On Mon, 8 Apr 2002, Jun Sun wrote: > What is the intention of introducing MIPS_CPU_FPUEX? It seems an overkill if > it is just needed by DecStation. How many CPUs really need this? It's needed by any system using a (logically) external FPU. If set it means there is no need to install a special FPU exception handler using a general-purpose interrupt line. It's a generic flag. Even if it's only of limited use now, it is not an excuse for not writing clean code. I'm afraid the current mess within the MIPS port is a result of people trying to think locally and I'm trying to avoid it. Are there any trade-offs of this flags you see and I don't? I'm willing to change the code if there really are. Maciej -- + Maciej W. Rozycki, Technical University of Gdansk, Poland + +--------------------------------------------------------------+ + e-mail: macro@ds2.pg.gda.pl, PGP key available + From jsun@mvista.com Mon Apr 8 20:26:08 2002 Received: (uucp@localhost) by guadalquivir.fnet.fr (8.8.8/97.02.12/Guadalquivir); id UAA21954; Mon, 8 Apr 2002 20:26:08 +0200 (MET DST) Received-Date: Mon, 8 Apr 2002 20:26:08 +0200 (MET DST) Received: from gateway-1237.mvista.com(12.44.186.158), claiming to be "av.mvista.com" via SMTP by guadalquivir.fnet.fr, id smtpd021952; Mon Apr 8 20:26:05 2002 Received: from mvista.com (av [127.0.0.1]) by av.mvista.com (8.9.3/8.9.3) with ESMTP id TAA22017; Mon, 8 Apr 2002 19:36:03 -0700 Message-ID: <3CB1E0B2.8020707@mvista.com> Date: Mon, 08 Apr 2002 11:25:54 -0700 From: Jun Sun User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.4) Gecko/20011126 Netscape6/6.2.1 X-Accept-Language: en-us MIME-Version: 1.0 To: "Maciej W. Rozycki" CC: Ralf Baechle , linux-mips@fnet.fr, linux-mips@oss.sgi.com Subject: Re: [patch] linux: New style IRQs for DECstation References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Length: 1257 Lines: 35 Maciej W. Rozycki wrote: > On Mon, 8 Apr 2002, Jun Sun wrote: > > >>What is the intention of introducing MIPS_CPU_FPUEX? It seems an overkill if >>it is just needed by DecStation. How many CPUs really need this? >> > > It's needed by any system using a (logically) external FPU. If set it > means there is no need to install a special FPU exception handler using a > general-purpose interrupt line. It's a generic flag. > > Even if it's only of limited use now, it is not an excuse for not writing > clean code. I'm afraid the current mess within the MIPS port is a result > of people trying to think locally and I'm trying to avoid it. Are there > any trade-offs of this flags you see and I don't? I'm willing to change > the code if there really are. > Generally interrupt dispatching belongs to machine/board-specific code. So I think FPU exeption through an interrupt is probably best handled within DEC's code, instead of being generalized to the common code. In addition, conceptional you might have a system where FPU exception is handled through an interrupt and yet CPU has FPU exception. Of course abstraction and generalization can happen later when it becomes obvious. It is just not obvious, at least to me. Jun From macro@ds2.pg.gda.pl Tue Apr 9 16:55:21 2002 Received: (uucp@localhost) by guadalquivir.fnet.fr (8.8.8/97.02.12/Guadalquivir); id QAA03440; Tue, 9 Apr 2002 16:55:21 +0200 (MET DST) Received-Date: Tue, 9 Apr 2002 16:55:21 +0200 (MET DST) Received: from delta.ds2.pg.gda.pl(213.192.72.1) via SMTP by guadalquivir.fnet.fr, id smtpd003436; Tue Apr 9 16:55:13 2002 Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id QAA08554; Tue, 9 Apr 2002 16:41:36 +0200 (MET DST) Date: Tue, 9 Apr 2002 16:41:33 +0200 (MET DST) From: "Maciej W. Rozycki" To: Jun Sun cc: Ralf Baechle , linux-mips@fnet.fr, linux-mips@oss.sgi.com Subject: Re: [patch] linux: New style IRQs for DECstation In-Reply-To: <3CB1E0B2.8020707@mvista.com> Message-ID: Organization: Technical University of Gdansk MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Content-Length: 2127 Lines: 43 On Mon, 8 Apr 2002, Jun Sun wrote: > Generally interrupt dispatching belongs to machine/board-specific code. So I > think FPU exeption through an interrupt is probably best handled within DEC's > code, instead of being generalized to the common code. The dispatching of the FPU interrupt for the DECstation is local to DEC-specific code (note that it's so mainly due to performance reasons anyway -- there is no problem with making dispatcher's code common with appropriate backends installed for different IRQ types, like it is already done in generic controller-based IRQ handling code). Any other system using a CPU/FPU in such a configuration has to provide its own dispatcher. The handler for the FPU interrupt is the very same handler used for the FPU exception; only a different entry point is used to accomodate the fact registers are already saved on the stack. And for safety you don't want the FPU exception handler to be enabled for FPUs that report exceptions via an FPU interrupt. For such systems a spurious FPU exception should be treated as a system error. > In addition, conceptional you might have a system where FPU exception is > handled through an interrupt and yet CPU has FPU exception. Not quite. The FPU exception is not maskable, so you can't make a choice at the run time. It has to be hardwired. > Of course abstraction and generalization can happen later when it becomes > obvious. It is just not obvious, at least to me. MIPS_CPU_FPUEX is specific to the CPU not to the system. IDT R3081 is another example (mysterious R3400 used in DECstation 5000/240 being the first one) of a CPU with an integrated FPU unit which is logically external and uses an interrupt to report FPU exceptions. And all R2k/R3k setups using a physically separate FPU deliver FPU exceptions via an interrupt line. I can't see a reason why to handle this option in system-specific code. Maciej -- + Maciej W. Rozycki, Technical University of Gdansk, Poland + +--------------------------------------------------------------+ + e-mail: macro@ds2.pg.gda.pl, PGP key available + From jsun@mvista.com Tue Apr 9 19:36:52 2002 Received: (uucp@localhost) by guadalquivir.fnet.fr (8.8.8/97.02.12/Guadalquivir); id TAA05704; Tue, 9 Apr 2002 19:36:52 +0200 (MET DST) Received-Date: Tue, 9 Apr 2002 19:36:52 +0200 (MET DST) Received: from gateway-1237.mvista.com(12.44.186.158), claiming to be "av.mvista.com" via SMTP by guadalquivir.fnet.fr, id smtpd005702; Tue Apr 9 19:36:41 2002 Received: from mvista.com (av [127.0.0.1]) by av.mvista.com (8.9.3/8.9.3) with ESMTP id SAA20052; Tue, 9 Apr 2002 18:46:25 -0700 Message-ID: <3CB32694.1010503@mvista.com> Date: Tue, 09 Apr 2002 10:36:20 -0700 From: Jun Sun User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.4) Gecko/20011126 Netscape6/6.2.1 X-Accept-Language: en-us MIME-Version: 1.0 To: "Maciej W. Rozycki" CC: Ralf Baechle , linux-mips@fnet.fr, linux-mips@oss.sgi.com Subject: Re: [patch] linux: New style IRQs for DECstation References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Length: 739 Lines: 23 Maciej W. Rozycki wrote: > I can't see a reason why to handle this option in > system-specific code. > How about "there will be likely no such CPUs/systems in the future"? Your patch will force every new CPU to add FPUEX option to the cpu_option, where apparently no place really need to use it. Leaving FPU exception enabled for a CPU that does not generate FPU exception is acceptable. (because it does *not* generate FPU exceptions). And hooking up/dispatching the FPU exception interrupt is system-specific already anyway. It, however, makes sense to provide a common wrapper code for fpu interrupt to jump to fpu exception handling code. Over-abstraction can make the picture cloudy rather than clear. My 2 cents. Jun From macro@ds2.pg.gda.pl Wed Apr 10 15:31:55 2002 Received: (uucp@localhost) by guadalquivir.fnet.fr (8.8.8/97.02.12/Guadalquivir); id PAA15702; Wed, 10 Apr 2002 15:31:55 +0200 (MET DST) Received-Date: Wed, 10 Apr 2002 15:31:55 +0200 (MET DST) Received: from delta.ds2.pg.gda.pl(213.192.72.1) via SMTP by guadalquivir.fnet.fr, id smtpd015700; Wed Apr 10 15:31:22 2002 Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id PAA06262; Wed, 10 Apr 2002 15:31:08 +0200 (MET DST) Date: Wed, 10 Apr 2002 15:31:07 +0200 (MET DST) From: "Maciej W. Rozycki" To: Jun Sun cc: Ralf Baechle , linux-mips@fnet.fr, linux-mips@oss.sgi.com Subject: Re: [patch] linux: New style IRQs for DECstation In-Reply-To: <3CB32694.1010503@mvista.com> Message-ID: Organization: Technical University of Gdansk MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Content-Length: 1769 Lines: 43 On Tue, 9 Apr 2002, Jun Sun wrote: > How about "there will be likely no such CPUs/systems in the future"? Does it mean code needs to be dirty? There is no performance hit for new CPUs and the code bloat is minimal and even that is discarded after boot. > Your patch will force every new CPU to add FPUEX option to the cpu_option, > where apparently no place really need to use it. Well, I agree to some extent here. I may negate the flag, so it's not needed for most CPUs. > Leaving FPU exception enabled for a CPU that does not generate FPU exception > is acceptable. (because it does *not* generate FPU exceptions). And hooking You never know. You may get one due to a hardware fault. It's better to trap it and panic then, than to try to pretend nothing special happened. > up/dispatching the FPU exception interrupt is system-specific already anyway. But pretty generic -- you just need to grab the right IRQ line. See the top of decstation_handle_int in arch/mips/dec/int-handler.S -- nothing system-specific until after the FPU path branch. You may cut and paste it for any other system. > It, however, makes sense to provide a common wrapper code for fpu interrupt to > jump to fpu exception handling code. No additional code is actually generated -- only a label for a second entry point is added. > Over-abstraction can make the picture cloudy rather than clear. My 2 cents. I appreciate your point of view. You haven't convinced me, though. Apart from the negation of MIPS_CPU_FPUEX, which sounds reasonable indeed. Maciej -- + Maciej W. Rozycki, Technical University of Gdansk, Poland + +--------------------------------------------------------------+ + e-mail: macro@ds2.pg.gda.pl, PGP key available + From macro@ds2.pg.gda.pl Mon Apr 15 15:53:20 2002 Received: (uucp@localhost) by guadalquivir.fnet.fr (8.8.8/97.02.12/Guadalquivir); id PAA01555; Mon, 15 Apr 2002 15:53:20 +0200 (MET DST) Received-Date: Mon, 15 Apr 2002 15:53:20 +0200 (MET DST) Received: from delta.ds2.pg.gda.pl(213.192.72.1) via SMTP by guadalquivir.fnet.fr, id smtpd001553; Mon Apr 15 15:53:17 2002 Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id PAA23063; Mon, 15 Apr 2002 15:53:25 +0200 (MET DST) Date: Mon, 15 Apr 2002 15:53:25 +0200 (MET DST) From: "Maciej W. Rozycki" Reply-To: "Maciej W. Rozycki" To: Ralf Baechle , Jun Sun cc: linux-mips@fnet.fr, linux-mips@oss.sgi.com Subject: [patch] linux 2.4: FPU exception updates Message-ID: Organization: Technical University of Gdansk MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Content-Length: 9689 Lines: 246 Hello, Here are updates to negate the FPU exception presence flag. Tested on an R3400 and an R4400SC. FPU-less configurations not tested but they should work as the changes are straightforward. Ralf, please apply. Maciej -- + Maciej W. Rozycki, Technical University of Gdansk, Poland + +--------------------------------------------------------------+ + e-mail: macro@ds2.pg.gda.pl, PGP key available + patch-mips-2.4.18-20020412-irq-49 diff -up --recursive --new-file linux-mips-2.4.18-20020412.macro/arch/mips/dec/setup.c linux-mips-2.4.18-20020412/arch/mips/dec/setup.c --- linux-mips-2.4.18-20020412.macro/arch/mips/dec/setup.c 2002-04-10 02:58:33.000000000 +0000 +++ linux-mips-2.4.18-20020412/arch/mips/dec/setup.c 2002-04-13 01:42:32.000000000 +0000 @@ -733,7 +733,7 @@ void __init init_IRQ(void) set_except_vector(0, decstation_handle_int); /* Free the FPU interrupt if the exception is present. */ - if (mips_cpu.options & MIPS_CPU_FPUEX) { + if (!(mips_cpu.options & MIPS_CPU_NOFPUEX)) { cpu_fpu_mask = 0; dec_interrupt[DEC_IRQ_FPU] = -1; } diff -up --recursive --new-file linux-mips-2.4.18-20020412.macro/arch/mips/kernel/setup.c linux-mips-2.4.18-20020412/arch/mips/kernel/setup.c --- linux-mips-2.4.18-20020412.macro/arch/mips/kernel/setup.c 2002-04-10 02:58:36.000000000 +0000 +++ linux-mips-2.4.18-20020412/arch/mips/kernel/setup.c 2002-04-13 01:47:38.000000000 +0000 @@ -234,7 +234,7 @@ static inline void cpu_probe(void) case PRID_IMP_R2000: mips_cpu.cputype = CPU_R2000; mips_cpu.isa_level = MIPS_CPU_ISA_I; - mips_cpu.options = MIPS_CPU_TLB; + mips_cpu.options = MIPS_CPU_TLB | MIPS_CPU_NOFPUEX; if (cpu_has_fpu()) mips_cpu.options |= MIPS_CPU_FPU; mips_cpu.tlbsize = 64; @@ -248,7 +248,7 @@ static inline void cpu_probe(void) else mips_cpu.cputype = CPU_R3000; mips_cpu.isa_level = MIPS_CPU_ISA_I; - mips_cpu.options = MIPS_CPU_TLB; + mips_cpu.options = MIPS_CPU_TLB | MIPS_CPU_NOFPUEX; if (cpu_has_fpu()) mips_cpu.options |= MIPS_CPU_FPU; mips_cpu.tlbsize = 64; @@ -261,7 +261,7 @@ static inline void cpu_probe(void) mips_cpu.isa_level = MIPS_CPU_ISA_III; mips_cpu.options = R4K_OPTS | MIPS_CPU_FPU | MIPS_CPU_32FPR | MIPS_CPU_WATCH | - MIPS_CPU_VCE | MIPS_CPU_FPUEX; + MIPS_CPU_VCE; mips_cpu.tlbsize = 48; break; case PRID_IMP_VR41XX: @@ -274,14 +274,13 @@ static inline void cpu_probe(void) mips_cpu.cputype = CPU_R4300; mips_cpu.isa_level = MIPS_CPU_ISA_III; mips_cpu.options = R4K_OPTS | MIPS_CPU_FPU | - MIPS_CPU_32FPR | MIPS_CPU_FPUEX; + MIPS_CPU_32FPR; mips_cpu.tlbsize = 32; break; case PRID_IMP_R4600: mips_cpu.cputype = CPU_R4600; mips_cpu.isa_level = MIPS_CPU_ISA_III; - mips_cpu.options = R4K_OPTS | MIPS_CPU_FPU | - MIPS_CPU_FPUEX; + mips_cpu.options = R4K_OPTS | MIPS_CPU_FPU; mips_cpu.tlbsize = 48; break; #if 0 @@ -294,8 +293,7 @@ static inline void cpu_probe(void) */ mips_cpu.cputype = CPU_R4650; mips_cpu.isa_level = MIPS_CPU_ISA_III; - mips_cpu.options = R4K_OPTS | MIPS_CPU_FPU | - MIPS_CPU_FPUEX; + mips_cpu.options = R4K_OPTS | MIPS_CPU_FPU; mips_cpu.tlbsize = 48; break; #endif @@ -329,14 +327,14 @@ static inline void cpu_probe(void) mips_cpu.cputype = CPU_R4700; mips_cpu.isa_level = MIPS_CPU_ISA_III; mips_cpu.options = R4K_OPTS | MIPS_CPU_FPU | - MIPS_CPU_32FPR | MIPS_CPU_FPUEX; + MIPS_CPU_32FPR; mips_cpu.tlbsize = 48; break; case PRID_IMP_TX49: mips_cpu.cputype = CPU_TX49XX; mips_cpu.isa_level = MIPS_CPU_ISA_III; mips_cpu.options = R4K_OPTS | MIPS_CPU_FPU | - MIPS_CPU_32FPR | MIPS_CPU_FPUEX; + MIPS_CPU_32FPR; mips_cpu.tlbsize = 48; mips_cpu.icache.ways = 4; mips_cpu.dcache.ways = 4; @@ -345,31 +343,28 @@ static inline void cpu_probe(void) mips_cpu.cputype = CPU_R5000; mips_cpu.isa_level = MIPS_CPU_ISA_IV; mips_cpu.options = R4K_OPTS | MIPS_CPU_FPU | - MIPS_CPU_32FPR | MIPS_CPU_FPUEX; + MIPS_CPU_32FPR; mips_cpu.tlbsize = 48; break; case PRID_IMP_R5432: mips_cpu.cputype = CPU_R5432; mips_cpu.isa_level = MIPS_CPU_ISA_IV; mips_cpu.options = R4K_OPTS | MIPS_CPU_FPU | - MIPS_CPU_32FPR | MIPS_CPU_WATCH | - MIPS_CPU_FPUEX; + MIPS_CPU_32FPR | MIPS_CPU_WATCH; mips_cpu.tlbsize = 48; break; case PRID_IMP_R5500: mips_cpu.cputype = CPU_R5500; mips_cpu.isa_level = MIPS_CPU_ISA_IV; mips_cpu.options = R4K_OPTS | MIPS_CPU_FPU | - MIPS_CPU_32FPR | MIPS_CPU_WATCH | - MIPS_CPU_FPUEX; + MIPS_CPU_32FPR | MIPS_CPU_WATCH; mips_cpu.tlbsize = 48; break; case PRID_IMP_NEVADA: mips_cpu.cputype = CPU_NEVADA; mips_cpu.isa_level = MIPS_CPU_ISA_IV; mips_cpu.options = R4K_OPTS | MIPS_CPU_FPU | - MIPS_CPU_32FPR | MIPS_CPU_DIVEC | - MIPS_CPU_FPUEX; + MIPS_CPU_32FPR | MIPS_CPU_DIVEC; mips_cpu.tlbsize = 48; mips_cpu.icache.ways = 2; mips_cpu.dcache.ways = 2; @@ -377,22 +372,20 @@ static inline void cpu_probe(void) case PRID_IMP_R6000: mips_cpu.cputype = CPU_R6000; mips_cpu.isa_level = MIPS_CPU_ISA_II; - mips_cpu.options = MIPS_CPU_TLB | MIPS_CPU_FPU | - MIPS_CPU_FPUEX; + mips_cpu.options = MIPS_CPU_TLB | MIPS_CPU_FPU; mips_cpu.tlbsize = 32; break; case PRID_IMP_R6000A: mips_cpu.cputype = CPU_R6000A; mips_cpu.isa_level = MIPS_CPU_ISA_II; - mips_cpu.options = MIPS_CPU_TLB | MIPS_CPU_FPU | - MIPS_CPU_FPUEX; + mips_cpu.options = MIPS_CPU_TLB | MIPS_CPU_FPU; mips_cpu.tlbsize = 32; break; case PRID_IMP_RM7000: mips_cpu.cputype = CPU_RM7000; mips_cpu.isa_level = MIPS_CPU_ISA_IV; mips_cpu.options = R4K_OPTS | MIPS_CPU_FPU | - MIPS_CPU_32FPR | MIPS_CPU_FPUEX; + MIPS_CPU_32FPR; /* * Undocumented RM7000: Bit 29 in the info register of * the RM7000 v2.0 indicates if the TLB has 48 or 64 @@ -407,8 +400,7 @@ static inline void cpu_probe(void) mips_cpu.cputype = CPU_R8000; mips_cpu.isa_level = MIPS_CPU_ISA_IV; mips_cpu.options = MIPS_CPU_TLB | MIPS_CPU_4KEX | - MIPS_CPU_FPU | MIPS_CPU_32FPR | - MIPS_CPU_FPUEX; + MIPS_CPU_FPU | MIPS_CPU_32FPR; mips_cpu.tlbsize = 384; /* has wierd TLB: 3-way x 128 */ break; case PRID_IMP_R10000: @@ -416,8 +408,7 @@ static inline void cpu_probe(void) mips_cpu.isa_level = MIPS_CPU_ISA_IV; mips_cpu.options = MIPS_CPU_TLB | MIPS_CPU_4KEX | MIPS_CPU_FPU | MIPS_CPU_32FPR | - MIPS_CPU_COUNTER | MIPS_CPU_WATCH | - MIPS_CPU_FPUEX; + MIPS_CPU_COUNTER | MIPS_CPU_WATCH; mips_cpu.tlbsize = 64; break; default: @@ -452,8 +443,7 @@ cpu_4kc: if (config1 & (1 << 2)) mips_cpu.options |= MIPS_CPU_MIPS16; if (config1 & 1) - mips_cpu.options |= MIPS_CPU_FPU | - MIPS_CPU_FPUEX; + mips_cpu.options |= MIPS_CPU_FPU; mips_cpu.scache.flags = MIPS_CACHE_NOT_PRESENT; break; case PRID_IMP_5KC: @@ -470,8 +460,7 @@ cpu_4kc: if (config1 & (1 << 2)) mips_cpu.options |= MIPS_CPU_MIPS16; if (config1 & 1) - mips_cpu.options |= MIPS_CPU_FPU | - MIPS_CPU_FPUEX; + mips_cpu.options |= MIPS_CPU_FPU; mips_cpu.scache.flags = MIPS_CACHE_NOT_PRESENT; break; default: @@ -497,8 +486,7 @@ cpu_4kc: if (config1 & (1 << 2)) mips_cpu.options |= MIPS_CPU_MIPS16; if (config1 & 1) - mips_cpu.options |= MIPS_CPU_FPU | - MIPS_CPU_FPUEX; + mips_cpu.options |= MIPS_CPU_FPU; mips_cpu.scache.flags = MIPS_CACHE_NOT_PRESENT; break; default: @@ -517,8 +505,7 @@ cpu_4kc: MIPS_CPU_MCHECK; #ifndef CONFIG_SB1_PASS_1_WORKAROUNDS /* FPU in pass1 is known to have issues. */ - mips_cpu.options |= MIPS_CPU_FPU | - MIPS_CPU_FPUEX; + mips_cpu.options |= MIPS_CPU_FPU; #endif break; default: diff -up --recursive --new-file linux-mips-2.4.18-20020412.macro/arch/mips/kernel/traps.c linux-mips-2.4.18-20020412/arch/mips/kernel/traps.c --- linux-mips-2.4.18-20020412.macro/arch/mips/kernel/traps.c 2002-04-10 02:58:40.000000000 +0000 +++ linux-mips-2.4.18-20020412/arch/mips/kernel/traps.c 2002-04-13 02:01:40.000000000 +0000 @@ -916,7 +916,8 @@ void __init trap_init(void) set_except_vector(12, handle_ov); set_except_vector(13, handle_tr); - if (mips_cpu.options & MIPS_CPU_FPUEX) + if ((mips_cpu.options & MIPS_CPU_FPU) && + !(mips_cpu.options & MIPS_CPU_NOFPUEX)) set_except_vector(15, handle_fpe); if (mips_cpu.options & MIPS_CPU_MCHECK) set_except_vector(24, handle_mcheck); diff -up --recursive --new-file linux-mips-2.4.18-20020412.macro/include/asm-mips/cpu.h linux-mips-2.4.18-20020412/include/asm-mips/cpu.h --- linux-mips-2.4.18-20020412.macro/include/asm-mips/cpu.h 2002-04-10 02:59:00.000000000 +0000 +++ linux-mips-2.4.18-20020412/include/asm-mips/cpu.h 2002-04-13 01:51:39.000000000 +0000 @@ -159,6 +159,6 @@ enum cputype { #define MIPS_CPU_CACHE_CDEX 0x00000800 /* Create_Dirty_Exclusive CACHE op */ #define MIPS_CPU_MCHECK 0x00001000 /* Machine check exception */ #define MIPS_CPU_EJTAG 0x00002000 /* EJTAG exception */ -#define MIPS_CPU_FPUEX 0x00004000 /* FPU exception */ +#define MIPS_CPU_NOFPUEX 0x00004000 /* no FPU exception */ #endif /* _ASM_CPU_H */ From macro@ds2.pg.gda.pl Thu Apr 18 09:43:21 2002 Received: (uucp@localhost) by guadalquivir.fnet.fr (8.8.8/97.02.12/Guadalquivir); id JAA24826; Thu, 18 Apr 2002 09:43:21 +0200 (MET DST) Received-Date: Thu, 18 Apr 2002 09:43:21 +0200 (MET DST) Received: from delta.ds2.pg.gda.pl(213.192.72.1) via SMTP by guadalquivir.fnet.fr, id smtpd024824; Thu Apr 18 09:43:15 2002 Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id JAA20496; Thu, 18 Apr 2002 09:43:30 +0200 (MET DST) Date: Thu, 18 Apr 2002 09:43:30 +0200 (MET DST) From: "Maciej W. Rozycki" To: Ralf Baechle , linux-mips@fnet.fr, linux-mips@oss.sgi.com Subject: [patch] linux: Export the DECstation's "system slot" address Message-ID: Organization: Technical University of Gdansk MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Content-Length: 868 Lines: 24 Hello, Here is a trivial patch to export the base address of the "system slot" of TURBOchannel systems. Needed if the declance driver is to be modularized. Ralf, please apply. Maciej -- + Maciej W. Rozycki, Technical University of Gdansk, Poland + +--------------------------------------------------------------+ + e-mail: macro@ds2.pg.gda.pl, PGP key available + diff -up --recursive --new-file linux-mips-2.4.18-20020412.macro/drivers/tc/tc.c linux-mips-2.4.18-20020412/drivers/tc/tc.c --- linux-mips-2.4.18-20020412.macro/drivers/tc/tc.c 2002-04-10 02:58:49.000000000 +0000 +++ linux-mips-2.4.18-20020412/drivers/tc/tc.c 2002-04-17 00:53:43.000000000 +0000 @@ -247,4 +247,4 @@ EXPORT_SYMBOL(release_tc_card); EXPORT_SYMBOL(get_tc_base_addr); EXPORT_SYMBOL(get_tc_irq_nr); EXPORT_SYMBOL(get_tc_speed); - +EXPORT_SYMBOL(system_base); From macro@ds2.pg.gda.pl Thu Apr 18 10:02:21 2002 Received: (uucp@localhost) by guadalquivir.fnet.fr (8.8.8/97.02.12/Guadalquivir); id KAA26297; Thu, 18 Apr 2002 10:02:21 +0200 (MET DST) Received-Date: Thu, 18 Apr 2002 10:02:21 +0200 (MET DST) Received: from delta.ds2.pg.gda.pl(213.192.72.1) via SMTP by guadalquivir.fnet.fr, id smtpd026295; Thu Apr 18 10:02:16 2002 Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id KAA20923; Thu, 18 Apr 2002 10:02:35 +0200 (MET DST) Date: Thu, 18 Apr 2002 10:02:34 +0200 (MET DST) From: "Maciej W. Rozycki" Reply-To: "Maciej W. Rozycki" To: Ralf Baechle , Dave Airlie , linux-mips@fnet.fr, linux-mips@oss.sgi.com Subject: [patch] linux: declance: add module support, miscellanea Message-ID: Organization: Technical University of Gdansk MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Content-Length: 990 Lines: 28 Hello, I've made several updates to the declance driver: 1. Module support. Tested for an I/O ASIC setup (/240). Changes seem to work well both as a module and when built-in. 2. Multiple interface support. While it should work in principle, its operation is impossible until PMAD-xx support is fixed. 3. Various fixes and clean-ups, including preparations to merge PMAD-xx changes by Dave. Due to a considerable size of the patch I'm not including it here. It's available at: 'ftp://ftp.ds2.pg.gda.pl/pub/macro/linux/patch-mips-2.4.18-20020412-declance-11.gz'. For module support the "system_base" patch is required. It was sent to the list and is also available at the above address. I'd be pleased to hear from 2100/3100 users if the driver works fine for them. Maciej -- + Maciej W. Rozycki, Technical University of Gdansk, Poland + +--------------------------------------------------------------+ + e-mail: macro@ds2.pg.gda.pl, PGP key available +