* [PATCH Cobalt 1/1] 64-bit fix
@ 2005-04-14 18:59 Peter Horton
2005-04-15 9:20 ` [OFF-TOPIC] Cobalt 64-bit, what for? (was: 64-bit fix) Dominique Quatravaux
2006-01-16 15:45 ` [PATCH Cobalt 1/1] 64-bit fix Martin Michlmayr
0 siblings, 2 replies; 15+ messages in thread
From: Peter Horton @ 2005-04-14 18:59 UTC (permalink / raw)
To: linux-mips; +Cc: ralf
This patch adds detection of broken 64-bit mode LL/SC on Cobalt units.
With this patch my Qube2700 boots a 64-bit build fine. The later units
have some problems with the Tulip driver.
P.
--
Index: linux/arch/mips/kernel/cpu-probe.c
===================================================================
--- linux.orig/arch/mips/kernel/cpu-probe.c 2005-04-11 23:19:17.000000000 +0100
+++ linux/arch/mips/kernel/cpu-probe.c 2005-04-11 23:35:06.000000000 +0100
@@ -131,6 +131,58 @@
check_wait();
}
+#ifdef CONFIG_MIPS64
+
+/*
+ * On RM5230/5231 all accesses to XKPHYS by LL(D) are forced
+ * to be uncached, bits 61-59 of the address are ignored.
+ *
+ * Apparently fixed on RM5230A/5231A.
+ */
+static inline int check_lld(void)
+{
+ unsigned long flags, value, match, phys, *addr;
+
+ printk("Checking for lld bug... ");
+
+ /* hope the stack is in the low 512MB */
+ phys = CPHYSADDR((unsigned long) &value);
+
+ /* write value to memory */
+ value = 0xfedcba9876543210;
+ addr = (unsigned long *) PHYS_TO_XKPHYS(K_CALG_UNCACHED, phys);
+ *addr = value;
+
+ /* stop spurious flushes */
+ local_irq_save(flags);
+
+ /* flip cached value */
+ value = ~value;
+
+ /* read value, supposedly from cache */
+ addr = (unsigned long *) PHYS_TO_XKPHYS(K_CALG_NONCOHERENT, phys);
+ asm volatile("lld %0, %1" : "=r" (match) : "m" (*addr));
+
+ local_irq_restore(flags);
+
+ match ^= value;
+
+ switch ((long) match) {
+ case 0:
+ printk("no.\n");
+ break;
+ case -1:
+ printk("yes.\n");
+ break;
+ default:
+ printk("yikes yes! (%lx/%lx@%p)\nPlease report to <linux-mips@linux-mips.org>.", value, match, &value);
+ }
+
+ return !match;
+}
+
+#endif
+
/*
* Probe whether cpu has config register by trying to play with
* alternate cache bit and see whether it matters.
@@ -347,7 +399,11 @@
c->cputype = CPU_NEVADA;
c->isa_level = MIPS_CPU_ISA_IV;
c->options = R4K_OPTS | MIPS_CPU_FPU | MIPS_CPU_32FPR |
- MIPS_CPU_DIVEC | MIPS_CPU_LLSC;
+ MIPS_CPU_DIVEC;
+#ifdef CONFIG_MIPS64
+ if (check_lld())
+#endif
+ c->options |= MIPS_CPU_LLSC;
c->tlbsize = 48;
break;
case PRID_IMP_R6000:
Index: linux/include/asm-mips/addrspace.h
===================================================================
--- linux.orig/include/asm-mips/addrspace.h 2005-04-11 23:19:17.000000000 +0100
+++ linux/include/asm-mips/addrspace.h 2005-04-11 23:19:20.000000000 +0100
@@ -120,7 +120,7 @@
#define PHYS_TO_XKSEG_UNCACHED(p) PHYS_TO_XKPHYS(K_CALG_UNCACHED,(p))
#define PHYS_TO_XKSEG_CACHED(p) PHYS_TO_XKPHYS(K_CALG_COH_SHAREABLE,(p))
#define XKPHYS_TO_PHYS(p) ((p) & TO_PHYS_MASK)
-#define PHYS_TO_XKPHYS(cm,a) (0x8000000000000000 | ((cm)<<59) | (a))
+#define PHYS_TO_XKPHYS(cm,a) (0x8000000000000000 | ((unsigned long)(cm)<<59) | (a))
#if defined (CONFIG_CPU_R4300) \
|| defined (CONFIG_CPU_R4X00) \
^ permalink raw reply [flat|nested] 15+ messages in thread* [OFF-TOPIC] Cobalt 64-bit, what for? (was: 64-bit fix) 2005-04-14 18:59 [PATCH Cobalt 1/1] 64-bit fix Peter Horton @ 2005-04-15 9:20 ` Dominique Quatravaux 2005-04-15 10:14 ` Ralf Baechle 2006-01-16 15:45 ` [PATCH Cobalt 1/1] 64-bit fix Martin Michlmayr 1 sibling, 1 reply; 15+ messages in thread From: Dominique Quatravaux @ 2005-04-15 9:20 UTC (permalink / raw) To: Peter Horton; +Cc: linux-mips, ralf Peter Horton wrote: >This patch adds detection of broken 64-bit mode LL/SC on Cobalt units. >With this patch my Qube2700 boots a 64-bit build fine. The later units >have some problems with the Tulip driver. > > Just out of curiosity, is there any practical interest in going 64bit on Cobalt besides the fun of it? One cannot possibly squeeze more than 4 Gb of RAM into a Cobalt box right? And doesn't 64 bit mode have costs of its own (doubled i-fetch bandwidth for starters)? -- << Tout n'y est pas parfait, mais on y honore certainement les jardiniers >> Dominique Quatravaux <dom@kilimandjaro.dyndns.org> ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [OFF-TOPIC] Cobalt 64-bit, what for? (was: 64-bit fix) 2005-04-15 9:20 ` [OFF-TOPIC] Cobalt 64-bit, what for? (was: 64-bit fix) Dominique Quatravaux @ 2005-04-15 10:14 ` Ralf Baechle 2005-04-15 10:18 ` Dominic Sweetman 0 siblings, 1 reply; 15+ messages in thread From: Ralf Baechle @ 2005-04-15 10:14 UTC (permalink / raw) To: Dominique Quatravaux; +Cc: Peter Horton, linux-mips On Fri, Apr 15, 2005 at 11:20:54AM +0200, Dominique Quatravaux wrote: > Just out of curiosity, is there any practical interest in going 64bit on > Cobalt besides the fun of it? Second hand Cobalt MIPS hardware is available fairly cheaply so it's being used by various Linux developers for doing development work, including 64-bit work. > One cannot possibly squeeze more than 4 Gb of RAM into a Cobalt box right? No, the limit is significantly less. 64-bit kernels are advantagous if - running N32 or N64 software is desired - anything that takes advantage of 64-bit registers or the 32/32 fpr model - software is using large amounts of virtual address space. Process size is limited to 2GB which is tight for some of todays codes which do their I/O by memory mapping files. - and of the course there is the "more inches" factor ;-) > And doesn't 64 bit mode have costs of its own (doubled i-fetch bandwidth > for starters)? Fortunately not double and caches will further blurr the picture - but on a system with a 32-bit processor and memory bus there will be very noticable impact. We're using a bunch of tricks to keep the overhead under control. Ralf ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [OFF-TOPIC] Cobalt 64-bit, what for? (was: 64-bit fix) 2005-04-15 10:14 ` Ralf Baechle @ 2005-04-15 10:18 ` Dominic Sweetman 2005-04-15 10:25 ` Ralf Baechle 0 siblings, 1 reply; 15+ messages in thread From: Dominic Sweetman @ 2005-04-15 10:18 UTC (permalink / raw) To: Ralf Baechle; +Cc: Dominique Quatravaux, Peter Horton, linux-mips Ralf Baechle (ralf@linux-mips.org) writes: > > And doesn't 64 bit mode have costs of its own (doubled i-fetch bandwidth > > for starters)? 64-bit MIPS CPUs still have 32-bit instructions... it's the registers and addressing range which grow, not the instructions. Program data segments tend to grow when you use 64-bit pointers (N64 does, but N32 - paradoxically still a 64-bit ABI - doesn't) -- Dominic Sweetman MIPS Technologies ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [OFF-TOPIC] Cobalt 64-bit, what for? (was: 64-bit fix) 2005-04-15 10:18 ` Dominic Sweetman @ 2005-04-15 10:25 ` Ralf Baechle 0 siblings, 0 replies; 15+ messages in thread From: Ralf Baechle @ 2005-04-15 10:25 UTC (permalink / raw) To: Dominic Sweetman; +Cc: Dominique Quatravaux, Peter Horton, linux-mips On Fri, Apr 15, 2005 at 11:18:08AM +0100, Dominic Sweetman wrote: > > > And doesn't 64 bit mode have costs of its own (doubled i-fetch bandwidth > > > for starters)? > > 64-bit MIPS CPUs still have 32-bit instructions... it's the registers > and addressing range which grow, not the instructions. True - but number of instructions will grow, thus the bandwidth needed to fetch them. > Program data segments tend to grow when you use 64-bit pointers (N64 > does, but N32 - paradoxically still a 64-bit ABI - doesn't) N32 is an ILP32 ABI so I'd count it as 32-bit. Ralf ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [PATCH Cobalt 1/1] 64-bit fix 2005-04-14 18:59 [PATCH Cobalt 1/1] 64-bit fix Peter Horton 2005-04-15 9:20 ` [OFF-TOPIC] Cobalt 64-bit, what for? (was: 64-bit fix) Dominique Quatravaux @ 2006-01-16 15:45 ` Martin Michlmayr 2006-01-16 16:32 ` Jim Gifford 2006-01-17 13:29 ` Ralf Baechle 1 sibling, 2 replies; 15+ messages in thread From: Martin Michlmayr @ 2006-01-16 15:45 UTC (permalink / raw) To: Peter Horton; +Cc: linux-mips, ralf * Peter Horton <pdh@colonel-panic.org> [2005-04-14 19:59]: > This patch adds detection of broken 64-bit mode LL/SC on Cobalt units. > With this patch my Qube2700 boots a 64-bit build fine. The later units > have some problems with the Tulip driver. Ralf, is this patch appropriate? Can you please apply it or provide some feedback. > P. > > -- > > Index: linux/arch/mips/kernel/cpu-probe.c > =================================================================== > --- linux.orig/arch/mips/kernel/cpu-probe.c 2005-04-11 23:19:17.000000000 +0100 > +++ linux/arch/mips/kernel/cpu-probe.c 2005-04-11 23:35:06.000000000 +0100 > @@ -131,6 +131,58 @@ > check_wait(); > } > > +#ifdef CONFIG_MIPS64 > + > +/* > + * On RM5230/5231 all accesses to XKPHYS by LL(D) are forced > + * to be uncached, bits 61-59 of the address are ignored. > + * > + * Apparently fixed on RM5230A/5231A. > + */ > +static inline int check_lld(void) > +{ > + unsigned long flags, value, match, phys, *addr; > + > + printk("Checking for lld bug... "); > + > + /* hope the stack is in the low 512MB */ > + phys = CPHYSADDR((unsigned long) &value); > + > + /* write value to memory */ > + value = 0xfedcba9876543210; > + addr = (unsigned long *) PHYS_TO_XKPHYS(K_CALG_UNCACHED, phys); > + *addr = value; > + > + /* stop spurious flushes */ > + local_irq_save(flags); > + > + /* flip cached value */ > + value = ~value; > + > + /* read value, supposedly from cache */ > + addr = (unsigned long *) PHYS_TO_XKPHYS(K_CALG_NONCOHERENT, phys); > + asm volatile("lld %0, %1" : "=r" (match) : "m" (*addr)); > + > + local_irq_restore(flags); > + > + match ^= value; > + > + switch ((long) match) { > + case 0: > + printk("no.\n"); > + break; > + case -1: > + printk("yes.\n"); > + break; > + default: > + printk("yikes yes! (%lx/%lx@%p)\nPlease report to <linux-mips@linux-mips.org>.", value, match, &value); > + } > + > + return !match; > +} > + > +#endif > + > /* > * Probe whether cpu has config register by trying to play with > * alternate cache bit and see whether it matters. > @@ -347,7 +399,11 @@ > c->cputype = CPU_NEVADA; > c->isa_level = MIPS_CPU_ISA_IV; > c->options = R4K_OPTS | MIPS_CPU_FPU | MIPS_CPU_32FPR | > - MIPS_CPU_DIVEC | MIPS_CPU_LLSC; > + MIPS_CPU_DIVEC; > +#ifdef CONFIG_MIPS64 > + if (check_lld()) > +#endif > + c->options |= MIPS_CPU_LLSC; > c->tlbsize = 48; > break; > case PRID_IMP_R6000: > Index: linux/include/asm-mips/addrspace.h > =================================================================== > --- linux.orig/include/asm-mips/addrspace.h 2005-04-11 23:19:17.000000000 +0100 > +++ linux/include/asm-mips/addrspace.h 2005-04-11 23:19:20.000000000 +0100 > @@ -120,7 +120,7 @@ > #define PHYS_TO_XKSEG_UNCACHED(p) PHYS_TO_XKPHYS(K_CALG_UNCACHED,(p)) > #define PHYS_TO_XKSEG_CACHED(p) PHYS_TO_XKPHYS(K_CALG_COH_SHAREABLE,(p)) > #define XKPHYS_TO_PHYS(p) ((p) & TO_PHYS_MASK) > -#define PHYS_TO_XKPHYS(cm,a) (0x8000000000000000 | ((cm)<<59) | (a)) > +#define PHYS_TO_XKPHYS(cm,a) (0x8000000000000000 | ((unsigned long)(cm)<<59) | (a)) > > #if defined (CONFIG_CPU_R4300) \ > || defined (CONFIG_CPU_R4X00) \ -- Martin Michlmayr http://www.cyrius.com/ ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [PATCH Cobalt 1/1] 64-bit fix 2006-01-16 15:45 ` [PATCH Cobalt 1/1] 64-bit fix Martin Michlmayr @ 2006-01-16 16:32 ` Jim Gifford 2006-01-16 16:50 ` Martin Michlmayr 2006-01-17 13:51 ` Ralf Baechle 2006-01-17 13:29 ` Ralf Baechle 1 sibling, 2 replies; 15+ messages in thread From: Jim Gifford @ 2006-01-16 16:32 UTC (permalink / raw) To: Martin Michlmayr; +Cc: Peter Horton, linux-mips, ralf Here's a link to the updated patch. Works under 2.6.15 http://www.linuxfromscratch.org/patches/downloads/linux/linux-2.6.15-mips_fix-1.patch This include the iomap.c, which is not accepted by Ralf. Submitted By: Jim Gifford (patches at jg555 dot com) Date: 2006-01-09 Initial Package Version: 2.6.15 Origin: Jim Gifford Upstream Status: Not Accepted Description: Various Fixes for MIPS architectures diff -Naur linux-2.6.15.orig/arch/mips/lib/Makefile linux-2.6.15/arch/mips/lib/Makefile --- linux-2.6.15.orig/arch/mips/lib/Makefile 2006-01-09 21:32:16.000000000 +0000 +++ linux-2.6.15/arch/mips/lib/Makefile 2006-01-09 21:37:56.000000000 +0000 @@ -5,4 +5,6 @@ lib-y += csum_partial_copy.o memcpy.o promlib.o strlen_user.o strncpy_user.o \ strnlen_user.o uncached.o +obj-y += iomap.o + EXTRA_AFLAGS := $(CFLAGS) diff -Naur linux-2.6.15.orig/arch/mips/lib/iomap.c linux-2.6.15/arch/mips/lib/iomap.c --- linux-2.6.15.orig/arch/mips/lib/iomap.c 1970-01-01 00:00:00.000000000 +0000 +++ linux-2.6.15/arch/mips/lib/iomap.c 2006-01-09 21:37:56.000000000 +0000 @@ -0,0 +1,78 @@ +/* + * iomap.c, Memory Mapped I/O routines for MIPS architecture. + * + * This code is based on lib/iomap.c, by Linus Torvalds. + * + * Copyright (C) 2004-2005 Yoichi Yuasa <yuasa@hh.iij4u.or.jp> + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License as published by + * the Free Software Foundation; either version 2 of the License, or + * (at your option) any later version. + * + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + * + * You should have received a copy of the GNU General Public License + * along with this program; if not, write to the Free Software + * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA + */ +#include <linux/ioport.h> +#include <linux/module.h> +#include <linux/pci.h> + +#include <asm/io.h> + +void __iomem *ioport_map(unsigned long port, unsigned int nr) +{ + unsigned long end; + + end = port + nr - 1UL; + if (ioport_resource.start > port || + ioport_resource.end < end || port > end) + return NULL; + + return (void __iomem *)(mips_io_port_base + port); +} + +void ioport_unmap(void __iomem *addr) +{ +} +EXPORT_SYMBOL(ioport_map); +EXPORT_SYMBOL(ioport_unmap); + +void __iomem *pci_iomap(struct pci_dev *dev, int bar, unsigned long maxlen) +{ + unsigned long start, len, flags; + + if (dev == NULL) + return NULL; + + start = pci_resource_start(dev, bar); + len = pci_resource_len(dev, bar); + if (!start || !len) + return NULL; + + if (maxlen != 0 && len > maxlen) + len = maxlen; + + flags = pci_resource_flags(dev, bar); + if (flags & IORESOURCE_IO) + return ioport_map(start, len); + if (flags & IORESOURCE_MEM) { + if (flags & IORESOURCE_CACHEABLE) + return ioremap_cacheable_cow(start, len); + return ioremap_nocache(start, len); + } + + return NULL; +} + +void pci_iounmap(struct pci_dev *dev, void __iomem *addr) +{ + iounmap(addr); +} +EXPORT_SYMBOL(pci_iomap); +EXPORT_SYMBOL(pci_iounmap); diff -Naur linux-2.6.15.orig/include/asm-mips/addrspace.h linux-2.6.15/include/asm-mips/addrspace.h --- linux-2.6.15.orig/include/asm-mips/addrspace.h 2006-01-03 03:21:10.000000000 +0000 +++ linux-2.6.15/include/asm-mips/addrspace.h 2006-01-09 20:47:10.000000000 +0000 @@ -124,7 +124,7 @@ #define PHYS_TO_XKSEG_CACHED(p) PHYS_TO_XKPHYS(K_CALG_COH_SHAREABLE,(p)) #define XKPHYS_TO_PHYS(p) ((p) & TO_PHYS_MASK) #define PHYS_TO_XKPHYS(cm,a) (_LLCONST_(0x8000000000000000) | \ - ((cm)<<59) | (a)) + ((unsigned long)(cm)<<59) | (a)) #if defined (CONFIG_CPU_R4300) \ || defined (CONFIG_CPU_R4X00) \ diff -Naur linux-2.6.15.orig/include/asm-mips/cobalt/cpu-feature-overrides.h linux-2.6.15/include/asm-mips/cobalt/cpu-feature-overrides.h --- linux-2.6.15.orig/include/asm-mips/cobalt/cpu-feature-overrides.h 1970-01-01 00:00:00.000000000 +0000 +++ linux-2.6.15/include/asm-mips/cobalt/cpu-feature-overrides.h 2006-01-09 20:52:18.000000000 +0000 @@ -0,0 +1,17 @@ +/* + * This file is subject to the terms and conditions of the GNU General Public + * License. See the file "COPYING" in the main directory of this archive + * for more details. + * + * Copyright (C) 2006 Ralf Baechle + */ +#ifndef __ASM_COBALT_CPU_FEATURE_OVERRIDES_H +#define __ASM_COBALT_CPU_FEATURE_OVERRIDES_H + +#ifdef CONFIG_64BIT +#define cpu_has_llsc 0 +#else +#define cpu_has_llsc 1 +#endif + +#endif /* __ASM_COBALT_CPU_FEATURE_OVERRIDES_H */ diff -Naur linux-2.6.15.orig/include/asm-mips/cobalt/ide.h linux-2.6.15/include/asm-mips/cobalt/ide.h --- linux-2.6.15.orig/include/asm-mips/cobalt/ide.h 1970-01-01 00:00:00.000000000 +0000 +++ linux-2.6.15/include/asm-mips/cobalt/ide.h 2006-01-09 20:47:10.000000000 +0000 @@ -0,0 +1,83 @@ + +/* + * PIO "in" transfers can cause D-cache lines to be allocated + * to the data being read. If the target is the page cache then + * the kernel can create a user space mapping of the same page + * without flushing it from the D-cache. This has large potential + * to create cache aliases. The Cobalts seem to trigger this + * problem easily. + * + * MIPs doesn't have a flush_dcache_range() so we roll + * our own. + * + * -- pdh + */ + +#define MAX_HWIFS 2 + +#include <asm/r4kcache.h> + +static inline void __flush_dcache(void) +{ + unsigned long dc_size, dc_line, addr, end; + + dc_size = current_cpu_data.dcache.ways << current_cpu_data.dcache.waybit; + dc_line = current_cpu_data.dcache.linesz; + + addr = CKSEG0; + end = addr + dc_size; + + for (; addr < end; addr += dc_line) + flush_dcache_line_indexed(addr); +} + +static inline void __flush_dcache_range(unsigned long start, unsigned long end) +{ + unsigned long dc_size, dc_line, addr; + + dc_size = current_cpu_data.dcache.ways << current_cpu_data.dcache.waybit; + dc_line = current_cpu_data.dcache.linesz; + + addr = start & ~(dc_line - 1); + end += dc_line - 1; + + if (end - addr < dc_size) + for (; addr < end; addr += dc_line) + flush_dcache_line(addr); + else + __flush_dcache(); +} + +static inline void __ide_insw(unsigned long port, void *addr, unsigned int count) +{ + insw(port, addr, count); + + __flush_dcache_range((unsigned long) addr, (unsigned long) addr + count * 2); +} + +static inline void __ide_insl(unsigned long port, void *addr, unsigned int count) +{ + insl(port, addr, count); + + __flush_dcache_range((unsigned long) addr, (unsigned long) addr + count * 4); +} + +static inline void __ide_mm_insw(volatile void __iomem *port, void *addr, unsigned int count) +{ + readsw(port, addr, count); + + __flush_dcache_range((unsigned long) addr, (unsigned long) addr + count * 2); +} + +static inline void __ide_mm_insl(volatile void __iomem *port, void *addr, unsigned int count) +{ + readsl(port, addr, count); + + __flush_dcache_range((unsigned long) addr, (unsigned long) addr + count * 4); +} + +#define insw __ide_insw +#define insl __ide_insl + +#define __ide_mm_outsw writesw +#define __ide_mm_outsl writesl diff -Naur linux-2.6.15.orig/include/asm-mips/io.h linux-2.6.15/include/asm-mips/io.h --- linux-2.6.15.orig/include/asm-mips/io.h 2006-01-09 21:32:18.000000000 +0000 +++ linux-2.6.15/include/asm-mips/io.h 2006-01-09 20:47:10.000000000 +0000 @@ -535,6 +535,62 @@ } /* + * Memory Mapped I/O + */ +#define ioread8(addr) readb(addr) +#define ioread16(addr) readw(addr) +#define ioread32(addr) readl(addr) + +#define iowrite8(b,addr) writeb(b,addr) +#define iowrite16(w,addr) writew(w,addr) +#define iowrite32(l,addr) writel(l,addr) + +#define ioread8_rep(a,b,c) readsb(a,b,c) +#define ioread16_rep(a,b,c) readsw(a,b,c) +#define ioread32_rep(a,b,c) readsl(a,b,c) + +#define iowrite8_rep(a,b,c) writesb(a,b,c) +#define iowrite16_rep(a,b,c) writesw(a,b,c) +#define iowrite32_rep(a,b,c) writesl(a,b,c) + +/* Create a virtual mapping cookie for an IO port range */ +extern void __iomem *ioport_map(unsigned long port, unsigned int nr); +extern void ioport_unmap(void __iomem *); + +/* Create a virtual mapping cookie for a PCI BAR (memory or IO) */ +struct pci_dev; +extern void __iomem *pci_iomap(struct pci_dev *dev, int bar, unsigned long max); +extern void pci_iounmap(struct pci_dev *dev, void __iomem *); + +/* + * Memory Mapped I/O + */ +#define ioread8(addr) readb(addr) +#define ioread16(addr) readw(addr) +#define ioread32(addr) readl(addr) + +#define iowrite8(b,addr) writeb(b,addr) +#define iowrite16(w,addr) writew(w,addr) +#define iowrite32(l,addr) writel(l,addr) + +#define ioread8_rep(a,b,c) readsb(a,b,c) +#define ioread16_rep(a,b,c) readsw(a,b,c) +#define ioread32_rep(a,b,c) readsl(a,b,c) + +#define iowrite8_rep(a,b,c) writesb(a,b,c) +#define iowrite16_rep(a,b,c) writesw(a,b,c) +#define iowrite32_rep(a,b,c) writesl(a,b,c) + +/* Create a virtual mapping cookie for an IO port range */ +extern void __iomem *ioport_map(unsigned long port, unsigned int nr); +extern void ioport_unmap(void __iomem *); + +/* Create a virtual mapping cookie for a PCI BAR (memory or IO) */ +struct pci_dev; +extern void __iomem *pci_iomap(struct pci_dev *dev, int bar, unsigned long max); +extern void pci_iounmap(struct pci_dev *dev, void __iomem *); + +/* * ISA space is 'always mapped' on currently supported MIPS systems, no need * to explicitly ioremap() it. The fact that the ISA IO space is mapped * to PAGE_OFFSET is pure coincidence - it does not mean ISA values -- ---- Jim Gifford maillist@jg555.com ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [PATCH Cobalt 1/1] 64-bit fix 2006-01-16 16:32 ` Jim Gifford @ 2006-01-16 16:50 ` Martin Michlmayr 2006-01-16 16:50 ` Martin Michlmayr 2006-01-17 13:51 ` Ralf Baechle 1 sibling, 1 reply; 15+ messages in thread From: Martin Michlmayr @ 2006-01-16 16:50 UTC (permalink / raw) Cc: Peter Horton, linux-mips * Jim Gifford <maillist@jg555.com> [2006-01-16 08:32]: > This include the iomap.c, which is not accepted by Ralf. I suppose that's just an omission. Here's Yuasa's patch again (with a minor change so it applies to 2.6.15). iomap implementation for Linux/MIPS Signed-off-by: Yoichi Yuasa <yuasa@hh.iij4u.or.jp> diff -urN linux-mips/arch/mips/lib/Makefile new/arch/mips/lib/Makefile --- linux-mips/arch/mips/lib/Makefile 2006-01-10 11:21:15.000000000 +0000 +++ new/arch/mips/lib/Makefile 2006-01-16 16:45:26.000000000 +0000 @@ -2,7 +2,7 @@ # Makefile for MIPS-specific library files.. # -lib-y += csum_partial_copy.o memcpy.o promlib.o strlen_user.o strncpy_user.o \ - strnlen_user.o uncached.o +lib-y += csum_partial_copy.o iomap.o memcpy.o promlib.o strlen_user.o \ + strncpy_user.o strnlen_user.o uncached.o EXTRA_AFLAGS := $(CFLAGS) diff -urN linux-mips/arch/mips/lib/iomap.c new/arch/mips/lib/iomap.c --- linux-mips/arch/mips/lib/iomap.c 1970-01-01 01:00:00.000000000 +0100 +++ new/arch/mips/lib/iomap.c 2006-01-16 16:45:35.000000000 +0000 @@ -0,0 +1,78 @@ +/* + * iomap.c, Memory Mapped I/O routines for MIPS architecture. + * + * This code is based on lib/iomap.c, by Linus Torvalds. + * + * Copyright (C) 2004-2005 Yoichi Yuasa <yuasa@hh.iij4u.or.jp> + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License as published by + * the Free Software Foundation; either version 2 of the License, or + * (at your option) any later version. + * + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + * + * You should have received a copy of the GNU General Public License + * along with this program; if not, write to the Free Software + * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA + */ +#include <linux/ioport.h> +#include <linux/module.h> +#include <linux/pci.h> + +#include <asm/io.h> + +void __iomem *ioport_map(unsigned long port, unsigned int nr) +{ + unsigned long end; + + end = port + nr - 1UL; + if (ioport_resource.start > port || + ioport_resource.end < end || port > end) + return NULL; + + return (void __iomem *)(mips_io_port_base + port); +} + +void ioport_unmap(void __iomem *addr) +{ +} +EXPORT_SYMBOL(ioport_map); +EXPORT_SYMBOL(ioport_unmap); + +void __iomem *pci_iomap(struct pci_dev *dev, int bar, unsigned long maxlen) +{ + unsigned long start, len, flags; + + if (dev == NULL) + return NULL; + + start = pci_resource_start(dev, bar); + len = pci_resource_len(dev, bar); + if (!start || !len) + return NULL; + + if (maxlen != 0 && len > maxlen) + len = maxlen; + + flags = pci_resource_flags(dev, bar); + if (flags & IORESOURCE_IO) + return ioport_map(start, len); + if (flags & IORESOURCE_MEM) { + if (flags & IORESOURCE_CACHEABLE) + return ioremap_cacheable_cow(start, len); + return ioremap_nocache(start, len); + } + + return NULL; +} + +void pci_iounmap(struct pci_dev *dev, void __iomem *addr) +{ + iounmap(addr); +} +EXPORT_SYMBOL(pci_iomap); +EXPORT_SYMBOL(pci_iounmap); diff -urN linux-mips/include/asm-mips/io.h new/include/asm-mips/io.h --- linux-mips/include/asm-mips/io.h 2006-01-10 11:21:59.000000000 +0000 +++ new/include/asm-mips/io.h 2006-01-16 16:45:35.000000000 +0000 @@ -535,6 +535,34 @@ } /* + * Memory Mapped I/O + */ +#define ioread8(addr) readb(addr) +#define ioread16(addr) readw(addr) +#define ioread32(addr) readl(addr) + +#define iowrite8(b,addr) writeb(b,addr) +#define iowrite16(w,addr) writew(w,addr) +#define iowrite32(l,addr) writel(l,addr) + +#define ioread8_rep(a,b,c) readsb(a,b,c) +#define ioread16_rep(a,b,c) readsw(a,b,c) +#define ioread32_rep(a,b,c) readsl(a,b,c) + +#define iowrite8_rep(a,b,c) writesb(a,b,c) +#define iowrite16_rep(a,b,c) writesw(a,b,c) +#define iowrite32_rep(a,b,c) writesl(a,b,c) + +/* Create a virtual mapping cookie for an IO port range */ +extern void __iomem *ioport_map(unsigned long port, unsigned int nr); +extern void ioport_unmap(void __iomem *); + +/* Create a virtual mapping cookie for a PCI BAR (memory or IO) */ +struct pci_dev; +extern void __iomem *pci_iomap(struct pci_dev *dev, int bar, unsigned long max); +extern void pci_iounmap(struct pci_dev *dev, void __iomem *); + +/* * ISA space is 'always mapped' on currently supported MIPS systems, no need * to explicitly ioremap() it. The fact that the ISA IO space is mapped * to PAGE_OFFSET is pure coincidence - it does not mean ISA values -- Martin Michlmayr http://www.cyrius.com/ ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [PATCH Cobalt 1/1] 64-bit fix 2006-01-16 16:50 ` Martin Michlmayr @ 2006-01-16 16:50 ` Martin Michlmayr 0 siblings, 0 replies; 15+ messages in thread From: Martin Michlmayr @ 2006-01-16 16:50 UTC (permalink / raw) Cc: Peter Horton, linux-mips * Jim Gifford <maillist@jg555.com> [2006-01-16 08:32]: > This include the iomap.c, which is not accepted by Ralf. I suppose that's just an omission. Here's Yuasa's patch again (with a minor change so it applies to 2.6.15). iomap implementation for Linux/MIPS Signed-off-by: Yoichi Yuasa <yuasa@hh.iij4u.or.jp> diff -urN linux-mips/arch/mips/lib/Makefile new/arch/mips/lib/Makefile --- linux-mips/arch/mips/lib/Makefile 2006-01-10 11:21:15.000000000 +0000 +++ new/arch/mips/lib/Makefile 2006-01-16 16:45:26.000000000 +0000 @@ -2,7 +2,7 @@ # Makefile for MIPS-specific library files.. # -lib-y += csum_partial_copy.o memcpy.o promlib.o strlen_user.o strncpy_user.o \ - strnlen_user.o uncached.o +lib-y += csum_partial_copy.o iomap.o memcpy.o promlib.o strlen_user.o \ + strncpy_user.o strnlen_user.o uncached.o EXTRA_AFLAGS := $(CFLAGS) diff -urN linux-mips/arch/mips/lib/iomap.c new/arch/mips/lib/iomap.c --- linux-mips/arch/mips/lib/iomap.c 1970-01-01 01:00:00.000000000 +0100 +++ new/arch/mips/lib/iomap.c 2006-01-16 16:45:35.000000000 +0000 @@ -0,0 +1,78 @@ +/* + * iomap.c, Memory Mapped I/O routines for MIPS architecture. + * + * This code is based on lib/iomap.c, by Linus Torvalds. + * + * Copyright (C) 2004-2005 Yoichi Yuasa <yuasa@hh.iij4u.or.jp> + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License as published by + * the Free Software Foundation; either version 2 of the License, or + * (at your option) any later version. + * + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + * + * You should have received a copy of the GNU General Public License + * along with this program; if not, write to the Free Software + * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA + */ +#include <linux/ioport.h> +#include <linux/module.h> +#include <linux/pci.h> + +#include <asm/io.h> + +void __iomem *ioport_map(unsigned long port, unsigned int nr) +{ + unsigned long end; + + end = port + nr - 1UL; + if (ioport_resource.start > port || + ioport_resource.end < end || port > end) + return NULL; + + return (void __iomem *)(mips_io_port_base + port); +} + +void ioport_unmap(void __iomem *addr) +{ +} +EXPORT_SYMBOL(ioport_map); +EXPORT_SYMBOL(ioport_unmap); + +void __iomem *pci_iomap(struct pci_dev *dev, int bar, unsigned long maxlen) +{ + unsigned long start, len, flags; + + if (dev == NULL) + return NULL; + + start = pci_resource_start(dev, bar); + len = pci_resource_len(dev, bar); + if (!start || !len) + return NULL; + + if (maxlen != 0 && len > maxlen) + len = maxlen; + + flags = pci_resource_flags(dev, bar); + if (flags & IORESOURCE_IO) + return ioport_map(start, len); + if (flags & IORESOURCE_MEM) { + if (flags & IORESOURCE_CACHEABLE) + return ioremap_cacheable_cow(start, len); + return ioremap_nocache(start, len); + } + + return NULL; +} + +void pci_iounmap(struct pci_dev *dev, void __iomem *addr) +{ + iounmap(addr); +} +EXPORT_SYMBOL(pci_iomap); +EXPORT_SYMBOL(pci_iounmap); diff -urN linux-mips/include/asm-mips/io.h new/include/asm-mips/io.h --- linux-mips/include/asm-mips/io.h 2006-01-10 11:21:59.000000000 +0000 +++ new/include/asm-mips/io.h 2006-01-16 16:45:35.000000000 +0000 @@ -535,6 +535,34 @@ } /* + * Memory Mapped I/O + */ +#define ioread8(addr) readb(addr) +#define ioread16(addr) readw(addr) +#define ioread32(addr) readl(addr) + +#define iowrite8(b,addr) writeb(b,addr) +#define iowrite16(w,addr) writew(w,addr) +#define iowrite32(l,addr) writel(l,addr) + +#define ioread8_rep(a,b,c) readsb(a,b,c) +#define ioread16_rep(a,b,c) readsw(a,b,c) +#define ioread32_rep(a,b,c) readsl(a,b,c) + +#define iowrite8_rep(a,b,c) writesb(a,b,c) +#define iowrite16_rep(a,b,c) writesw(a,b,c) +#define iowrite32_rep(a,b,c) writesl(a,b,c) + +/* Create a virtual mapping cookie for an IO port range */ +extern void __iomem *ioport_map(unsigned long port, unsigned int nr); +extern void ioport_unmap(void __iomem *); + +/* Create a virtual mapping cookie for a PCI BAR (memory or IO) */ +struct pci_dev; +extern void __iomem *pci_iomap(struct pci_dev *dev, int bar, unsigned long max); +extern void pci_iounmap(struct pci_dev *dev, void __iomem *); + +/* * ISA space is 'always mapped' on currently supported MIPS systems, no need * to explicitly ioremap() it. The fact that the ISA IO space is mapped * to PAGE_OFFSET is pure coincidence - it does not mean ISA values -- Martin Michlmayr http://www.cyrius.com/ ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [PATCH Cobalt 1/1] 64-bit fix 2006-01-16 16:32 ` Jim Gifford 2006-01-16 16:50 ` Martin Michlmayr @ 2006-01-17 13:51 ` Ralf Baechle 2006-01-17 14:23 ` Atsushi Nemoto 2006-01-17 17:09 ` Jim Gifford 1 sibling, 2 replies; 15+ messages in thread From: Ralf Baechle @ 2006-01-17 13:51 UTC (permalink / raw) To: Jim Gifford; +Cc: Martin Michlmayr, Peter Horton, linux-mips On Mon, Jan 16, 2006 at 08:32:46AM -0800, Jim Gifford wrote: > Content-Type: text/plain; charset=ISO-8859-1; format=flowed > > Here's a link to the updated patch. Works under 2.6.15 > http://www.linuxfromscratch.org/patches/downloads/linux/linux-2.6.15-mips_fix-1.patch > > This include the iomap.c, which is not accepted by Ralf. Yes - and the reasons are archived on this list. Reposting the patch leaves me entirely unimpressed. Ralf ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [PATCH Cobalt 1/1] 64-bit fix 2006-01-17 13:51 ` Ralf Baechle @ 2006-01-17 14:23 ` Atsushi Nemoto 2006-01-18 17:59 ` Jim Gifford 2006-01-17 17:09 ` Jim Gifford 1 sibling, 1 reply; 15+ messages in thread From: Atsushi Nemoto @ 2006-01-17 14:23 UTC (permalink / raw) To: ralf; +Cc: maillist, tbm, pdh, linux-mips >>>>> On Tue, 17 Jan 2006 13:51:45 +0000, Ralf Baechle <ralf@linux-mips.org> said: >> This include the iomap.c, which is not accepted by Ralf. ralf> Yes - and the reasons are archived on this list. Reposting the ralf> patch leaves me entirely unimpressed. Ralf, is this the reason? > Subject: Re: MIPS - 64bit woes > From: Ralf Baechle <ralf@linux-mips.org> > Date: Fri, 18 Nov 2005 17:29:48 +0000 > > No. It's broken for machines with multiple PCI busses and I've explicitly > rejected the patch which is in kernel.org before. It seems a bit obscured for me --- and perhaps for some other people. So I asked: > Subject: mips iomap.c (Was: Re: MIPS - 64bit woes) > From: Atsushi Nemoto <anemo@mba.ocn.ne.jp> > Date: Sun, 20 Nov 2005 02:36:41 +0900 (JST) > > Could you explain a bit _how_ broken current kernel.org's > arch/mips/lib/iomap.c ? Is it a single mips_io_port_base issue? > > I suppose it works as well as traditional way (request_region + > in[bwl] for IO resource, request_mem_region + iomap + read[bwl] for > MEM resource). > > I think it is better than generic iomap.c (except that > ioremap_cacheable_cow which is not available for R3000 is used). But got no response at that time. So I ask again. Could you tell us how the iomap patch broken verbosely, please? --- Atsushi Nemoto ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [PATCH Cobalt 1/1] 64-bit fix 2006-01-17 14:23 ` Atsushi Nemoto @ 2006-01-18 17:59 ` Jim Gifford 2006-01-19 16:35 ` Atsushi Nemoto 0 siblings, 1 reply; 15+ messages in thread From: Jim Gifford @ 2006-01-18 17:59 UTC (permalink / raw) To: Atsushi Nemoto; +Cc: ralf, tbm, pdh, linux-mips Atsushi Nemoto wrote: > But got no response at that time. So I ask again. Could you tell us > how the iomap patch broken verbosely, please? > > How can we get this resolved, this issue has been open a long time. Can we all work together to get a working solution in place that everyone will accept? We all need to understand the concerns with the current method. The only issue I see from Ralf is the following: Broken on multiple PCI busses. Now the way I understand the issue is the current iomap.c only handles a single bus, Ralf's point is that if there are multiple busses this patch may not work properly. Is that a correct statement Ralf. So can't we have one iomap.c for single pci bus systems and one for multiple pci bus systems? Just a thought. -- ---- Jim Gifford maillist@jg555.com ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [PATCH Cobalt 1/1] 64-bit fix 2006-01-18 17:59 ` Jim Gifford @ 2006-01-19 16:35 ` Atsushi Nemoto 0 siblings, 0 replies; 15+ messages in thread From: Atsushi Nemoto @ 2006-01-19 16:35 UTC (permalink / raw) To: maillist; +Cc: ralf, tbm, pdh, linux-mips >>>>> On Wed, 18 Jan 2006 09:59:54 -0800, Jim Gifford <maillist@jg555.com> said: jim> We all need to understand the concerns with the current jim> method. The only issue I see from Ralf is the following: jim> Broken on multiple PCI busses. Yes, it is an only reason I have ever seen. jim> Now the way I understand the issue is the current iomap.c jim> only handles a single bus, Ralf's point is that if there are jim> multiple busses this patch may not work properly. Is that a jim> correct statement Ralf. I think the current iomap can handle multiple busses. The traditional way (ioremap + read[bwl] for memory space and in[bwl] for IO space) can be used on multiple PCI busses if pci resources were properly configured. (Though IO space address might be a bit strange value due to single global mips_io_port_base, it works anyway.) The current iomap basically do same jobs. --- Atsushi Nemoto ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [PATCH Cobalt 1/1] 64-bit fix 2006-01-17 13:51 ` Ralf Baechle 2006-01-17 14:23 ` Atsushi Nemoto @ 2006-01-17 17:09 ` Jim Gifford 1 sibling, 0 replies; 15+ messages in thread From: Jim Gifford @ 2006-01-17 17:09 UTC (permalink / raw) To: Ralf Baechle; +Cc: Martin Michlmayr, Peter Horton, linux-mips [-- Attachment #1: Type: text/plain, Size: 124 bytes --] As per our conversation Ralf, here is the patch without the iomap stuff in it. -- ---- Jim Gifford maillist@jg555.com [-- Attachment #2: linux-2.6.15.1-mips_fix-1.patch --] [-- Type: text/x-diff, Size: 4174 bytes --] Submitted By: Jim Gifford (patches at jg555 dot com) Date: 2006-01-09 Initial Package Version: 2.6.15 Origin: Jim Gifford Upstream Status: Not Accepted Description: Various Fixes for MIPS architectures diff -Naur linux-2.6.15.orig/include/asm-mips/addrspace.h linux-2.6.15/include/asm-mips/addrspace.h --- linux-2.6.15.orig/include/asm-mips/addrspace.h 2006-01-03 03:21:10.000000000 +0000 +++ linux-2.6.15/include/asm-mips/addrspace.h 2006-01-09 20:47:10.000000000 +0000 @@ -124,7 +124,7 @@ #define PHYS_TO_XKSEG_CACHED(p) PHYS_TO_XKPHYS(K_CALG_COH_SHAREABLE,(p)) #define XKPHYS_TO_PHYS(p) ((p) & TO_PHYS_MASK) #define PHYS_TO_XKPHYS(cm,a) (_LLCONST_(0x8000000000000000) | \ - ((cm)<<59) | (a)) + ((unsigned long)(cm)<<59) | (a)) #if defined (CONFIG_CPU_R4300) \ || defined (CONFIG_CPU_R4X00) \ diff -Naur linux-2.6.15.orig/include/asm-mips/cobalt/cpu-feature-overrides.h linux-2.6.15/include/asm-mips/cobalt/cpu-feature-overrides.h --- linux-2.6.15.orig/include/asm-mips/cobalt/cpu-feature-overrides.h 1970-01-01 00:00:00.000000000 +0000 +++ linux-2.6.15/include/asm-mips/cobalt/cpu-feature-overrides.h 2006-01-09 20:52:18.000000000 +0000 @@ -0,0 +1,17 @@ +/* + * This file is subject to the terms and conditions of the GNU General Public + * License. See the file "COPYING" in the main directory of this archive + * for more details. + * + * Copyright (C) 2006 Ralf Baechle + */ +#ifndef __ASM_COBALT_CPU_FEATURE_OVERRIDES_H +#define __ASM_COBALT_CPU_FEATURE_OVERRIDES_H + +#ifdef CONFIG_64BIT +#define cpu_has_llsc 0 +#else +#define cpu_has_llsc 1 +#endif + +#endif /* __ASM_COBALT_CPU_FEATURE_OVERRIDES_H */ diff -Naur linux-2.6.15.orig/include/asm-mips/cobalt/ide.h linux-2.6.15/include/asm-mips/cobalt/ide.h --- linux-2.6.15.orig/include/asm-mips/cobalt/ide.h 1970-01-01 00:00:00.000000000 +0000 +++ linux-2.6.15/include/asm-mips/cobalt/ide.h 2006-01-09 20:47:10.000000000 +0000 @@ -0,0 +1,83 @@ + +/* + * PIO "in" transfers can cause D-cache lines to be allocated + * to the data being read. If the target is the page cache then + * the kernel can create a user space mapping of the same page + * without flushing it from the D-cache. This has large potential + * to create cache aliases. The Cobalts seem to trigger this + * problem easily. + * + * MIPs doesn't have a flush_dcache_range() so we roll + * our own. + * + * -- pdh + */ + +#define MAX_HWIFS 2 + +#include <asm/r4kcache.h> + +static inline void __flush_dcache(void) +{ + unsigned long dc_size, dc_line, addr, end; + + dc_size = current_cpu_data.dcache.ways << current_cpu_data.dcache.waybit; + dc_line = current_cpu_data.dcache.linesz; + + addr = CKSEG0; + end = addr + dc_size; + + for (; addr < end; addr += dc_line) + flush_dcache_line_indexed(addr); +} + +static inline void __flush_dcache_range(unsigned long start, unsigned long end) +{ + unsigned long dc_size, dc_line, addr; + + dc_size = current_cpu_data.dcache.ways << current_cpu_data.dcache.waybit; + dc_line = current_cpu_data.dcache.linesz; + + addr = start & ~(dc_line - 1); + end += dc_line - 1; + + if (end - addr < dc_size) + for (; addr < end; addr += dc_line) + flush_dcache_line(addr); + else + __flush_dcache(); +} + +static inline void __ide_insw(unsigned long port, void *addr, unsigned int count) +{ + insw(port, addr, count); + + __flush_dcache_range((unsigned long) addr, (unsigned long) addr + count * 2); +} + +static inline void __ide_insl(unsigned long port, void *addr, unsigned int count) +{ + insl(port, addr, count); + + __flush_dcache_range((unsigned long) addr, (unsigned long) addr + count * 4); +} + +static inline void __ide_mm_insw(volatile void __iomem *port, void *addr, unsigned int count) +{ + readsw(port, addr, count); + + __flush_dcache_range((unsigned long) addr, (unsigned long) addr + count * 2); +} + +static inline void __ide_mm_insl(volatile void __iomem *port, void *addr, unsigned int count) +{ + readsl(port, addr, count); + + __flush_dcache_range((unsigned long) addr, (unsigned long) addr + count * 4); +} + +#define insw __ide_insw +#define insl __ide_insl + +#define __ide_mm_outsw writesw +#define __ide_mm_outsl writesl ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [PATCH Cobalt 1/1] 64-bit fix 2006-01-16 15:45 ` [PATCH Cobalt 1/1] 64-bit fix Martin Michlmayr 2006-01-16 16:32 ` Jim Gifford @ 2006-01-17 13:29 ` Ralf Baechle 1 sibling, 0 replies; 15+ messages in thread From: Ralf Baechle @ 2006-01-17 13:29 UTC (permalink / raw) To: Martin Michlmayr; +Cc: Peter Horton, linux-mips On Mon, Jan 16, 2006 at 03:45:43PM +0000, Martin Michlmayr wrote: > * Peter Horton <pdh@colonel-panic.org> [2005-04-14 19:59]: > > This patch adds detection of broken 64-bit mode LL/SC on Cobalt units. > > With this patch my Qube2700 boots a 64-bit build fine. The later units > > have some problems with the Tulip driver. > > Ralf, is this patch appropriate? Can you please apply it or provide > some feedback. Runtime testing for that bug is fairly expensive as it adds a branch to every instance of every type of atomic operation. So we really want cpu_has_llsc to be a constant so the compiler can optimize that. So I suggest something like this in cpu-feature-overrides.h: [...] /* * R5000 has an interesting "restriction": ll(d)/sc(d) * instructions to XKPHYS region simply do uncached bus * requests. This breaks all the atomic bitops functions. * so, for 64bit IP32 kernel we just don't use ll/sc. * This does not affect luserland. */ #ifdef CONFIG_64BIT #define cpu_has_llsc 0 #else #define cpu_has_llsc 1 #endif [...] The probe would upset the IP27 cache coherency logic and crash them btw. Ralf ^ permalink raw reply [flat|nested] 15+ messages in thread
end of thread, other threads:[~2006-01-19 16:32 UTC | newest] Thread overview: 15+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2005-04-14 18:59 [PATCH Cobalt 1/1] 64-bit fix Peter Horton 2005-04-15 9:20 ` [OFF-TOPIC] Cobalt 64-bit, what for? (was: 64-bit fix) Dominique Quatravaux 2005-04-15 10:14 ` Ralf Baechle 2005-04-15 10:18 ` Dominic Sweetman 2005-04-15 10:25 ` Ralf Baechle 2006-01-16 15:45 ` [PATCH Cobalt 1/1] 64-bit fix Martin Michlmayr 2006-01-16 16:32 ` Jim Gifford 2006-01-16 16:50 ` Martin Michlmayr 2006-01-16 16:50 ` Martin Michlmayr 2006-01-17 13:51 ` Ralf Baechle 2006-01-17 14:23 ` Atsushi Nemoto 2006-01-18 17:59 ` Jim Gifford 2006-01-19 16:35 ` Atsushi Nemoto 2006-01-17 17:09 ` Jim Gifford 2006-01-17 13:29 ` Ralf Baechle
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox