From rpurdie@rpsys.net Mon Oct 1 00:30:05 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 01 Oct 2007 00:30:13 +0100 (BST) Received: from tim.rpsys.net ([194.106.48.114]:35987 "EHLO tim.rpsys.net") by ftp.linux-mips.org with ESMTP id S20023807AbXI3XaF (ORCPT ); Mon, 1 Oct 2007 00:30:05 +0100 Received: from localhost (localhost [127.0.0.1]) by tim.rpsys.net (8.13.6/8.13.8) with ESMTP id l8UNU48P008715; Mon, 1 Oct 2007 00:30:04 +0100 Received: from tim.rpsys.net ([127.0.0.1]) by localhost (tim.rpsys.net [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 08468-06; Mon, 1 Oct 2007 00:29:58 +0100 (BST) Received: from [192.168.1.15] (max.rpnet.com [192.168.1.15]) (authenticated bits=0) by tim.rpsys.net (8.13.6/8.13.8) with ESMTP id l8UNTuoq008698 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Mon, 1 Oct 2007 00:29:56 +0100 Subject: Re: [PATCH] led: update Cobalt Qube series front LED support From: Richard Purdie To: Ralf Baechle Cc: Yoichi Yuasa , linux-mips In-Reply-To: <20070927114602.GB22657@linux-mips.org> References: <200709270851.l8R8peE9025629@po-mbox303.hop.2iij.net> <20070927114602.GB22657@linux-mips.org> Content-Type: text/plain Date: Mon, 01 Oct 2007 00:29:55 +0100 Message-Id: <1191194995.6115.34.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.10.1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: amavisd-new at rpsys.net Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 16747 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: rpurdie@rpsys.net Precedence: bulk X-list: linux-mips On Thu, 2007-09-27 at 12:46 +0100, Ralf Baechle wrote: > On Thu, Sep 27, 2007 at 05:51:17PM +0900, Yoichi Yuasa wrote: > > > Update Cobalt Qube series front LED support. > > > > Signed-off-by: Yoichi Yuasa > > Same, Acked-by: Ralf Baechle Queued in the led tree, thanks. Richard From rpurdie@rpsys.net Mon Oct 1 00:33:13 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 01 Oct 2007 00:33:23 +0100 (BST) Received: from tim.rpsys.net ([194.106.48.114]:37779 "EHLO tim.rpsys.net") by ftp.linux-mips.org with ESMTP id S20025055AbXI3XdN (ORCPT ); Mon, 1 Oct 2007 00:33:13 +0100 Received: from localhost (localhost [127.0.0.1]) by tim.rpsys.net (8.13.6/8.13.8) with ESMTP id l8UNU4On008710; Mon, 1 Oct 2007 00:30:04 +0100 Received: from tim.rpsys.net ([127.0.0.1]) by localhost (tim.rpsys.net [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 08480-05; Mon, 1 Oct 2007 00:29:58 +0100 (BST) Received: from [192.168.1.15] (max.rpnet.com [192.168.1.15]) (authenticated bits=0) by tim.rpsys.net (8.13.6/8.13.8) with ESMTP id l8UNTqq1008697 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Mon, 1 Oct 2007 00:29:52 +0100 Subject: Re: [PATCH] led: add Cobalt Raq series LEDs support From: Richard Purdie To: Ralf Baechle Cc: Yoichi Yuasa , linux-mips In-Reply-To: <20070927114543.GA22657@linux-mips.org> References: <20070927175105.cf0ccb10.yoichi_yuasa@tripeaks.co.jp> <20070927114543.GA22657@linux-mips.org> Content-Type: text/plain Date: Mon, 01 Oct 2007 00:29:51 +0100 Message-Id: <1191194991.6115.32.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.10.1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: amavisd-new at rpsys.net Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 16748 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: rpurdie@rpsys.net Precedence: bulk X-list: linux-mips On Thu, 2007-09-27 at 12:45 +0100, Ralf Baechle wrote: > On Thu, Sep 27, 2007 at 05:51:05PM +0900, Yoichi Yuasa wrote: > > > Add Cobalt Raq series LEDs support. > > > > Signed-off-by: Yoichi Yuasa > > Looks fine to me, Acked-by: Ralf Baechle Queued in the led tree, thanks. Richard From ralf@linux-mips.org Mon Oct 1 03:53:56 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 01 Oct 2007 03:53:59 +0100 (BST) Received: from localhost.localdomain ([127.0.0.1]:51135 "EHLO dl5rb.ham-radio-op.net") by ftp.linux-mips.org with ESMTP id S20023587AbXJACx4 (ORCPT ); Mon, 1 Oct 2007 03:53:56 +0100 Received: from denk.linux-mips.net (denk.linux-mips.net [127.0.0.1]) by dl5rb.ham-radio-op.net (8.14.1/8.13.8) with ESMTP id l912rqjn017709; Mon, 1 Oct 2007 03:53:52 +0100 Received: (from ralf@localhost) by denk.linux-mips.net (8.14.1/8.14.1/Submit) id l912reID017708; Mon, 1 Oct 2007 03:53:40 +0100 Date: Mon, 1 Oct 2007 03:53:40 +0100 From: Ralf Baechle To: Fuxin Zhang Cc: linux-mips@linux-mips.org Subject: Re: cmpxchg broken in some situation Message-ID: <20071001025340.GA7091@linux-mips.org> References: <46FF7BC2.5050905@ict.ac.cn> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <46FF7BC2.5050905@ict.ac.cn> User-Agent: Mutt/1.5.14 (2007-02-12) Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 16749 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: ralf@linux-mips.org Precedence: bulk X-list: linux-mips On Sun, Sep 30, 2007 at 06:34:42PM +0800, Fuxin Zhang wrote: > hi, > Today I run across a possible bug of cmpxchg implementation. When > playing with DRM on our Fulong, the following function > (drivers/char/drm/drm_lock.c) is not working correctly in 64BIT mips: > cmpxchg failed to set *lock to new value. (return 0 with *lock unchanged) > It is probably due to type conversions between unisigned int and > unsigned long. When I change cmpxchg to mycmpxchg(attached below), > problem disappeared. Below a patch to implement the get_user() style big solution to type safety in cmpxchg. Can you test it? Thanks, Ralf Signed-off-by: Ralf Baechle include/asm-mips/cmpxchg.h | 104 ++++++++++++++++++ include/asm-mips/local.h | 1 include/asm-mips/system.h | 261 -------------------------------------------- 3 files changed, 106 insertions(+), 260 deletions(-) diff --git a/include/asm-mips/cmpxchg.h b/include/asm-mips/cmpxchg.h new file mode 100644 index 0000000..d1523dd --- /dev/null +++ b/include/asm-mips/cmpxchg.h @@ -0,0 +1,104 @@ +/* + * 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) 2003, 06, 07 by Ralf Baechle (ralf@linux-mips.org) + */ +#ifndef __ASM_CMPXCHG_H +#define __ASM_CMPXCHG_H + +#include + +#define __HAVE_ARCH_CMPXCHG 1 + +#define __cmpxchg(ld, st, m, old, new) \ +({ \ + __typeof(*(m)) __ret; \ + \ + if (cpu_has_llsc && R10000_LLSC_WAR) { \ + __asm__ __volatile__( \ + " .set push \n" \ + " .set noat \n" \ + " .set mips3 \n" \ + "1: " ld " %0, %2 # __cmpxchg_u32 \n" \ + " bne %0, %z3, 2f \n" \ + " .set mips0 \n" \ + " move $1, %z4 \n" \ + " .set mips3 \n" \ + " " st " $1, %1 \n" \ + " beqzl $1, 1b \n" \ + "2: \n" \ + " .set pop \n" \ + : "=&r" (__ret), "=R" (*m) \ + : "R" (*m), "Jr" (old), "Jr" (new) \ + : "memory"); \ + } else if (cpu_has_llsc) { \ + __asm__ __volatile__( \ + " .set push \n" \ + " .set noat \n" \ + " .set mips3 \n" \ + "1: " ld " %0, %2 # __cmpxchg_u32 \n" \ + " bne %0, %z3, 2f \n" \ + " .set mips0 \n" \ + " move $1, %z4 \n" \ + " .set mips3 \n" \ + " " st " $1, %1 \n" \ + " beqz $1, 3f \n" \ + "2: \n" \ + " .subsection 2 \n" \ + "3: b 1b \n" \ + " .previous \n" \ + " .set pop \n" \ + : "=&r" (__ret), "=R" (*m) \ + : "R" (*m), "Jr" (old), "Jr" (new) \ + : "memory"); \ + } else { \ + unsigned long __flags; \ + \ + raw_local_irq_save(__flags); \ + __ret = *m; \ + if (__ret == old) \ + *m = new; \ + raw_local_irq_restore(__flags); \ + } \ + \ + smp_llsc_mb(); \ + \ + __ret; \ +}) + +/* + * This function doesn't exist, so you'll get a linker error + * if something tries to do an invalid cmpxchg(). + */ +extern void __cmpxchg_called_with_bad_pointer(void); + +#define cmpxchg(ptr,old,new) \ +({ \ + __typeof__(ptr) __ptr = (ptr); \ + __typeof__(*(ptr)) __old = (old); \ + __typeof__(*(ptr)) __new = (new); \ + __typeof__(*(ptr)) __res = 0; \ + \ + switch (sizeof(__ptr)) { \ + case 4: \ + __res = __cmpxchg("ll", "sc", __ptr, __old, __new); \ + break; \ + case 8: \ + if (sizeof(long) == 8) { \ + __res = __cmpxchg("lld", "scd", __ptr, \ + __old, __new); \ + break; \ + } \ + default: \ + __cmpxchg_called_with_bad_pointer(); \ + break; \ + } \ + \ + __res; \ +}) + +#define cmpxchg_local(ptr, old, new) cmpxchg(ptr, old, new) + +#endif /* __ASM_CMPXCHG_H */ diff --git a/include/asm-mips/local.h b/include/asm-mips/local.h index ed882c8..7034a01 100644 --- a/include/asm-mips/local.h +++ b/include/asm-mips/local.h @@ -4,6 +4,7 @@ #include #include #include +#include #include typedef struct diff --git a/include/asm-mips/system.h b/include/asm-mips/system.h index 357251f..480b574 100644 --- a/include/asm-mips/system.h +++ b/include/asm-mips/system.h @@ -17,6 +17,7 @@ #include #include +#include #include #include #include @@ -194,266 +195,6 @@ static inline unsigned long __xchg(unsigned long x, volatile void * ptr, int siz #define xchg(ptr,x) ((__typeof__(*(ptr)))__xchg((unsigned long)(x),(ptr),sizeof(*(ptr)))) -#define __HAVE_ARCH_CMPXCHG 1 - -static inline unsigned long __cmpxchg_u32(volatile int * m, unsigned long old, - unsigned long new) -{ - __u32 retval; - - if (cpu_has_llsc && R10000_LLSC_WAR) { - __asm__ __volatile__( - " .set push \n" - " .set noat \n" - " .set mips3 \n" - "1: ll %0, %2 # __cmpxchg_u32 \n" - " bne %0, %z3, 2f \n" - " .set mips0 \n" - " move $1, %z4 \n" - " .set mips3 \n" - " sc $1, %1 \n" - " beqzl $1, 1b \n" - "2: \n" - " .set pop \n" - : "=&r" (retval), "=R" (*m) - : "R" (*m), "Jr" (old), "Jr" (new) - : "memory"); - } else if (cpu_has_llsc) { - __asm__ __volatile__( - " .set push \n" - " .set noat \n" - " .set mips3 \n" - "1: ll %0, %2 # __cmpxchg_u32 \n" - " bne %0, %z3, 2f \n" - " .set mips0 \n" - " move $1, %z4 \n" - " .set mips3 \n" - " sc $1, %1 \n" - " beqz $1, 3f \n" - "2: \n" - " .subsection 2 \n" - "3: b 1b \n" - " .previous \n" - " .set pop \n" - : "=&r" (retval), "=R" (*m) - : "R" (*m), "Jr" (old), "Jr" (new) - : "memory"); - } else { - unsigned long flags; - - raw_local_irq_save(flags); - retval = *m; - if (retval == old) - *m = new; - raw_local_irq_restore(flags); /* implies memory barrier */ - } - - smp_llsc_mb(); - - return retval; -} - -static inline unsigned long __cmpxchg_u32_local(volatile int * m, - unsigned long old, unsigned long new) -{ - __u32 retval; - - if (cpu_has_llsc && R10000_LLSC_WAR) { - __asm__ __volatile__( - " .set push \n" - " .set noat \n" - " .set mips3 \n" - "1: ll %0, %2 # __cmpxchg_u32 \n" - " bne %0, %z3, 2f \n" - " .set mips0 \n" - " move $1, %z4 \n" - " .set mips3 \n" - " sc $1, %1 \n" - " beqzl $1, 1b \n" - "2: \n" - " .set pop \n" - : "=&r" (retval), "=R" (*m) - : "R" (*m), "Jr" (old), "Jr" (new) - : "memory"); - } else if (cpu_has_llsc) { - __asm__ __volatile__( - " .set push \n" - " .set noat \n" - " .set mips3 \n" - "1: ll %0, %2 # __cmpxchg_u32 \n" - " bne %0, %z3, 2f \n" - " .set mips0 \n" - " move $1, %z4 \n" - " .set mips3 \n" - " sc $1, %1 \n" - " beqz $1, 1b \n" - "2: \n" - " .set pop \n" - : "=&r" (retval), "=R" (*m) - : "R" (*m), "Jr" (old), "Jr" (new) - : "memory"); - } else { - unsigned long flags; - - local_irq_save(flags); - retval = *m; - if (retval == old) - *m = new; - local_irq_restore(flags); /* implies memory barrier */ - } - - return retval; -} - -#ifdef CONFIG_64BIT -static inline unsigned long __cmpxchg_u64(volatile int * m, unsigned long old, - unsigned long new) -{ - __u64 retval; - - if (cpu_has_llsc && R10000_LLSC_WAR) { - __asm__ __volatile__( - " .set push \n" - " .set noat \n" - " .set mips3 \n" - "1: lld %0, %2 # __cmpxchg_u64 \n" - " bne %0, %z3, 2f \n" - " move $1, %z4 \n" - " scd $1, %1 \n" - " beqzl $1, 1b \n" - "2: \n" - " .set pop \n" - : "=&r" (retval), "=R" (*m) - : "R" (*m), "Jr" (old), "Jr" (new) - : "memory"); - } else if (cpu_has_llsc) { - __asm__ __volatile__( - " .set push \n" - " .set noat \n" - " .set mips3 \n" - "1: lld %0, %2 # __cmpxchg_u64 \n" - " bne %0, %z3, 2f \n" - " move $1, %z4 \n" - " scd $1, %1 \n" - " beqz $1, 3f \n" - "2: \n" - " .subsection 2 \n" - "3: b 1b \n" - " .previous \n" - " .set pop \n" - : "=&r" (retval), "=R" (*m) - : "R" (*m), "Jr" (old), "Jr" (new) - : "memory"); - } else { - unsigned long flags; - - raw_local_irq_save(flags); - retval = *m; - if (retval == old) - *m = new; - raw_local_irq_restore(flags); /* implies memory barrier */ - } - - smp_llsc_mb(); - - return retval; -} - -static inline unsigned long __cmpxchg_u64_local(volatile int * m, - unsigned long old, unsigned long new) -{ - __u64 retval; - - if (cpu_has_llsc && R10000_LLSC_WAR) { - __asm__ __volatile__( - " .set push \n" - " .set noat \n" - " .set mips3 \n" - "1: lld %0, %2 # __cmpxchg_u64 \n" - " bne %0, %z3, 2f \n" - " move $1, %z4 \n" - " scd $1, %1 \n" - " beqzl $1, 1b \n" - "2: \n" - " .set pop \n" - : "=&r" (retval), "=R" (*m) - : "R" (*m), "Jr" (old), "Jr" (new) - : "memory"); - } else if (cpu_has_llsc) { - __asm__ __volatile__( - " .set push \n" - " .set noat \n" - " .set mips3 \n" - "1: lld %0, %2 # __cmpxchg_u64 \n" - " bne %0, %z3, 2f \n" - " move $1, %z4 \n" - " scd $1, %1 \n" - " beqz $1, 1b \n" - "2: \n" - " .set pop \n" - : "=&r" (retval), "=R" (*m) - : "R" (*m), "Jr" (old), "Jr" (new) - : "memory"); - } else { - unsigned long flags; - - local_irq_save(flags); - retval = *m; - if (retval == old) - *m = new; - local_irq_restore(flags); /* implies memory barrier */ - } - - return retval; -} - -#else -extern unsigned long __cmpxchg_u64_unsupported_on_32bit_kernels( - volatile int * m, unsigned long old, unsigned long new); -#define __cmpxchg_u64 __cmpxchg_u64_unsupported_on_32bit_kernels -extern unsigned long __cmpxchg_u64_local_unsupported_on_32bit_kernels( - volatile int * m, unsigned long old, unsigned long new); -#define __cmpxchg_u64_local __cmpxchg_u64_local_unsupported_on_32bit_kernels -#endif - -/* This function doesn't exist, so you'll get a linker error - if something tries to do an invalid cmpxchg(). */ -extern void __cmpxchg_called_with_bad_pointer(void); - -static inline unsigned long __cmpxchg(volatile void * ptr, unsigned long old, - unsigned long new, int size) -{ - switch (size) { - case 4: - return __cmpxchg_u32(ptr, old, new); - case 8: - return __cmpxchg_u64(ptr, old, new); - } - __cmpxchg_called_with_bad_pointer(); - return old; -} - -static inline unsigned long __cmpxchg_local(volatile void * ptr, - unsigned long old, unsigned long new, int size) -{ - switch (size) { - case 4: - return __cmpxchg_u32_local(ptr, old, new); - case 8: - return __cmpxchg_u64_local(ptr, old, new); - } - __cmpxchg_called_with_bad_pointer(); - return old; -} - -#define cmpxchg(ptr,old,new) \ - ((__typeof__(*(ptr)))__cmpxchg((ptr), \ - (unsigned long)(old), (unsigned long)(new),sizeof(*(ptr)))) - -#define cmpxchg_local(ptr,old,new) \ - ((__typeof__(*(ptr)))__cmpxchg_local((ptr), \ - (unsigned long)(old), (unsigned long)(new),sizeof(*(ptr)))) - extern void set_handler (unsigned long offset, void *addr, unsigned long len); extern void set_uncached_handler (unsigned long offset, void *addr, unsigned long len); From ddaney@avtrex.com Mon Oct 1 04:57:31 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 01 Oct 2007 04:57:40 +0100 (BST) Received: from smtp1.dnsmadeeasy.com ([205.234.170.144]:4795 "EHLO smtp1.dnsmadeeasy.com") by ftp.linux-mips.org with ESMTP id S20021445AbXJAD5b (ORCPT ); Mon, 1 Oct 2007 04:57:31 +0100 Received: from smtp1.dnsmadeeasy.com (localhost [127.0.0.1]) by smtp1.dnsmadeeasy.com (Postfix) with ESMTP id B8145309B4B; Mon, 1 Oct 2007 03:56:54 +0000 (UTC) X-Authenticated-Name: js.dnsmadeeasy X-Transit-System: In case of SPAM please contact abuse@dnsmadeeasy.com Received: from avtrex.com (unknown [67.116.42.147]) by smtp1.dnsmadeeasy.com (Postfix) with ESMTP; Mon, 1 Oct 2007 03:56:54 +0000 (UTC) Received: from [192.168.7.224] ([192.168.7.224]) by avtrex.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 30 Sep 2007 20:56:52 -0700 Message-ID: <47007003.2050905@avtrex.com> Date: Sun, 30 Sep 2007 20:56:51 -0700 From: David Daney User-Agent: Thunderbird 1.5.0.12 (X11/20070719) MIME-Version: 1.0 To: Ralf Baechle Cc: Fuxin Zhang , linux-mips@linux-mips.org Subject: Re: cmpxchg broken in some situation References: <46FF7BC2.5050905@ict.ac.cn> <20071001025340.GA7091@linux-mips.org> In-Reply-To: <20071001025340.GA7091@linux-mips.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 01 Oct 2007 03:56:52.0577 (UTC) FILETIME=[19D0E510:01C803DF] Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 16750 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: ddaney@avtrex.com Precedence: bulk X-list: linux-mips Ralf Baechle wrote: > + } else if (cpu_has_llsc) { \ > + __asm__ __volatile__( \ > + " .set push \n" \ > + " .set noat \n" \ > + " .set mips3 \n" \ > + "1: " ld " %0, %2 # __cmpxchg_u32 \n" \ > + " bne %0, %z3, 2f \n" \ > + " .set mips0 \n" \ > + " move $1, %z4 \n" \ > + " .set mips3 \n" \ > + " " st " $1, %1 \n" \ > + " beqz $1, 3f \n" \ > + "2: \n" \ > + " .subsection 2 \n" \ > + "3: b 1b \n" \ > + " .previous \n" \ > + " .set pop \n" \ > + : "=&r" (__ret), "=R" (*m) \ > + : "R" (*m), "Jr" (old), "Jr" (new) \ > + : "memory"); \ > Is a 'sync' needed after the 'sc'? According to this message: http://www.linux-mips.org/cgi-bin/mesg.cgi?a=linux-mips&i=20070919084515.GM9972%40networkno.de it would seem so. David Daney From ddaney@avtrex.com Mon Oct 1 04:59:46 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 01 Oct 2007 04:59:55 +0100 (BST) Received: from smtp1.dnsmadeeasy.com ([205.234.170.144]:20156 "EHLO smtp1.dnsmadeeasy.com") by ftp.linux-mips.org with ESMTP id S20021445AbXJAD7q (ORCPT ); Mon, 1 Oct 2007 04:59:46 +0100 Received: from smtp1.dnsmadeeasy.com (localhost [127.0.0.1]) by smtp1.dnsmadeeasy.com (Postfix) with ESMTP id D07CE309B4B; Mon, 1 Oct 2007 03:59:10 +0000 (UTC) X-Authenticated-Name: js.dnsmadeeasy X-Transit-System: In case of SPAM please contact abuse@dnsmadeeasy.com Received: from avtrex.com (unknown [67.116.42.147]) by smtp1.dnsmadeeasy.com (Postfix) with ESMTP; Mon, 1 Oct 2007 03:59:10 +0000 (UTC) Received: from [192.168.7.224] ([192.168.7.224]) by avtrex.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 30 Sep 2007 20:59:08 -0700 Message-ID: <4700708B.8070708@avtrex.com> Date: Sun, 30 Sep 2007 20:59:07 -0700 From: David Daney User-Agent: Thunderbird 1.5.0.12 (X11/20070719) MIME-Version: 1.0 To: Ralf Baechle Cc: Fuxin Zhang , linux-mips@linux-mips.org Subject: Re: cmpxchg broken in some situation References: <46FF7BC2.5050905@ict.ac.cn> <20071001025340.GA7091@linux-mips.org> <47007003.2050905@avtrex.com> In-Reply-To: <47007003.2050905@avtrex.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 01 Oct 2007 03:59:08.0231 (UTC) FILETIME=[6AAC0D70:01C803DF] Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 16751 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: ddaney@avtrex.com Precedence: bulk X-list: linux-mips David Daney wrote: > Ralf Baechle wrote: >> + } else if (cpu_has_llsc) { \ >> + __asm__ __volatile__( \ >> + " .set push \n" \ >> + " .set noat \n" \ >> + " .set mips3 \n" \ >> + "1: " ld " %0, %2 # __cmpxchg_u32 \n" \ >> + " bne %0, %z3, 2f \n" \ >> + " .set mips0 \n" \ >> + " move $1, %z4 \n" \ >> + " .set mips3 \n" \ >> + " " st " $1, %1 \n" \ >> + " beqz $1, 3f \n" \ >> + "2: \n" \ >> + " .subsection 2 \n" \ >> + "3: b 1b \n" \ >> + " .previous \n" \ >> + " .set pop \n" \ >> + : "=&r" (__ret), "=R" (*m) \ >> + : "R" (*m), "Jr" (old), "Jr" (new) \ >> + : "memory"); \ >> > Is a 'sync' needed after the 'sc'? > > According to this message: > http://www.linux-mips.org/cgi-bin/mesg.cgi?a=linux-mips&i=20070919084515.GM9972%40networkno.de > > it would seem so. Drat, I probably posted too soon. That is the smp_llsc_mb(); isn't it. David Daney From veerasena_b@yahoo.co.in Mon Oct 1 10:11:39 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 01 Oct 2007 10:11:48 +0100 (BST) Received: from n6.bullet.mud.yahoo.com ([216.252.100.57]:36949 "HELO n6.bullet.mud.yahoo.com") by ftp.linux-mips.org with SMTP id S20022052AbXJAJLj (ORCPT ); Mon, 1 Oct 2007 10:11:39 +0100 Received: from [68.142.194.244] by n6.bullet.mud.yahoo.com with NNFMP; 01 Oct 2007 09:10:17 -0000 Received: from [209.191.119.163] by t2.bullet.mud.yahoo.com with NNFMP; 01 Oct 2007 09:10:17 -0000 Received: from [127.0.0.1] by omp102.mail.mud.yahoo.com with NNFMP; 01 Oct 2007 09:10:17 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 130687.14103.bm@omp102.mail.mud.yahoo.com Received: (qmail 35417 invoked by uid 60001); 1 Oct 2007 09:04:33 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.co.in; h=X-YMail-OSG:Received:Date:From:Subject:To:MIME-Version:Content-Type:Content-Transfer-Encoding:Message-ID; b=lUVapiL1EKJnQozhcUV8Go1a4BzqxjAdmJst7d0WMrogji9z0oVMERAXx+UfrPvswLbvpLf0XOZ+w1tVryHaTjv8c3sM6Zv/onTj/4igs0/ESJNfAOBRkcDZNRbsLhMZpz2WEjS1p0SEIvzxLxc4AnKs0gM6tTACvHc1QatGQFg=; X-YMail-OSG: OvqjJSIVM1k_lSVRAynBOP_A43iN1H_VzB1zKuh_Bsd6U_rNdd8hCJ7YDDBBBSvEl6mpv3CG8S3CblaZVZjTJfBgdqq9I4fWKvzRWeEnf3bX9SghKLoaIpCUk2P1HQ-- Received: from [199.239.167.162] by web8401.mail.in.yahoo.com via HTTP; Mon, 01 Oct 2007 10:04:32 BST Date: Mon, 1 Oct 2007 10:04:32 +0100 (BST) From: veerasena reddy Subject: linux cache routines for Write-back cache policy on MIPS24KE To: linux-mips , "linux-kernel.org" MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Message-ID: <119374.35234.qm@web8401.mail.in.yahoo.com> Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 16752 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: veerasena_b@yahoo.co.in Precedence: bulk X-list: linux-mips Hi, I have ported Linux-2.6.18 kernel on MIPS24KE processor. I am using write back cache policy. Could you please guide me under what cases the below cache API's are being used: - dma_cache_wback_inv() : Could you explain what exactly this function does - dma_cache_wback() : This function write back the cache data to memory - dma_cache_inv : This function invalidate the cache tags. so subsequent access will fetch from memory. Once I looked the above function definitions in linux-2.6.18/arch/mips/mm/c-r4k.c. All these function's implemetation are same except bc_wbak_inv() is called in both dma_cache_wback-inv() and dma_cache_wback(), where as bc_inv() is called in case of dma_cache_inv. Also, bc_inv()/bc_wbak_inv are define as null implementation for R4000. That means all three functions are doing same functionality in case of R4000. What are the difference between these three functions. Under what cases these functions are used. Please guide me if you have any links which will explain these API's. Thanks in advance. Regards, Veerasena. Forgot the famous last words? Access your message archive online at http://in.messenger.yahoo.com/webmessengerpromo.php From geert@linux-m68k.org Mon Oct 1 10:23:07 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 01 Oct 2007 10:23:16 +0100 (BST) Received: from ananke.telenet-ops.be ([195.130.137.78]:38632 "EHLO ananke.telenet-ops.be") by ftp.linux-mips.org with ESMTP id S20022064AbXJAJXH (ORCPT ); Mon, 1 Oct 2007 10:23:07 +0100 Received: from localhost (localhost.localdomain [127.0.0.1]) by ananke.telenet-ops.be (Postfix) with SMTP id 60738392442; Mon, 1 Oct 2007 11:23:06 +0200 (CEST) Received: from anakin.of.borg (d54C15D55.access.telenet.be [84.193.93.85]) by ananke.telenet-ops.be (Postfix) with ESMTP id 426C13923D0; Mon, 1 Oct 2007 11:23:06 +0200 (CEST) Received: from anakin.of.borg (geert@localhost [127.0.0.1]) by anakin.of.borg (8.14.1/8.14.1/Debian-9) with ESMTP id l919N5Ys020958 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 1 Oct 2007 11:23:05 +0200 Received: from localhost (geert@localhost) by anakin.of.borg (8.14.1/8.14.1/Submit) with ESMTP id l919N5mA020955; Mon, 1 Oct 2007 11:23:05 +0200 X-Authentication-Warning: anakin.of.borg: geert owned process doing -bs Date: Mon, 1 Oct 2007 11:23:05 +0200 (CEST) From: Geert Uytterhoeven To: veerasena reddy cc: linux-mips , "linux-kernel.org" Subject: Re: linux cache routines for Write-back cache policy on MIPS24KE In-Reply-To: <119374.35234.qm@web8401.mail.in.yahoo.com> Message-ID: References: <119374.35234.qm@web8401.mail.in.yahoo.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 16753 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: geert@linux-m68k.org Precedence: bulk X-list: linux-mips On Mon, 1 Oct 2007, veerasena reddy wrote: > I have ported Linux-2.6.18 kernel on MIPS24KE > processor. I am using write back cache policy. > > Could you please guide me under what cases the below > cache API's are being used: > - dma_cache_wback_inv() : Could you explain what > exactly this function does It does both write back and invalidate. > - dma_cache_wback() : This function write back the > cache data to memory > - dma_cache_inv : This function invalidate the cache > tags. so subsequent access will fetch from memory. Note that 2.6.18 is old. The above functions are intended to be removed. Gr{oetje,eeting}s, Geert -- Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say "programmer" or something like that. -- Linus Torvalds From ralf@linux-mips.org Mon Oct 1 11:24:39 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 01 Oct 2007 11:24:41 +0100 (BST) Received: from localhost.localdomain ([127.0.0.1]:8862 "EHLO dl5rb.ham-radio-op.net") by ftp.linux-mips.org with ESMTP id S20022158AbXJAKYj (ORCPT ); Mon, 1 Oct 2007 11:24:39 +0100 Received: from denk.linux-mips.net (denk.linux-mips.net [127.0.0.1]) by dl5rb.ham-radio-op.net (8.14.1/8.13.8) with ESMTP id l91AOZv3023296; Mon, 1 Oct 2007 11:24:35 +0100 Received: (from ralf@localhost) by denk.linux-mips.net (8.14.1/8.14.1/Submit) id l91AOXAv023295; Mon, 1 Oct 2007 11:24:33 +0100 Date: Mon, 1 Oct 2007 11:24:33 +0100 From: Ralf Baechle To: David Daney Cc: Fuxin Zhang , linux-mips@linux-mips.org Subject: Re: cmpxchg broken in some situation Message-ID: <20071001102433.GA20219@linux-mips.org> References: <46FF7BC2.5050905@ict.ac.cn> <20071001025340.GA7091@linux-mips.org> <47007003.2050905@avtrex.com> <4700708B.8070708@avtrex.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4700708B.8070708@avtrex.com> User-Agent: Mutt/1.5.14 (2007-02-12) Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 16754 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: ralf@linux-mips.org Precedence: bulk X-list: linux-mips On Sun, Sep 30, 2007 at 08:59:07PM -0700, David Daney wrote: > David Daney wrote: > >Ralf Baechle wrote: > >>+ } else if (cpu_has_llsc) { \ > >>+ __asm__ __volatile__( \ > >>+ " .set push \n" \ > >>+ " .set noat \n" \ > >>+ " .set mips3 \n" \ > >>+ "1: " ld " %0, %2 # __cmpxchg_u32 \n" \ > >>+ " bne %0, %z3, 2f \n" \ > >>+ " .set mips0 \n" \ > >>+ " move $1, %z4 \n" \ > >>+ " .set mips3 \n" \ > >>+ " " st " $1, %1 \n" \ > >>+ " beqz $1, 3f \n" \ > >>+ "2: \n" \ > >>+ " .subsection 2 \n" \ > >>+ "3: b 1b \n" \ > >>+ " .previous \n" \ > >>+ " .set pop \n" \ > >>+ : "=&r" (__ret), "=R" (*m) \ > >>+ : "R" (*m), "Jr" (old), "Jr" (new) \ > >>+ : "memory"); \ > >> > >Is a 'sync' needed after the 'sc'? > > > >According to this message: > >http://www.linux-mips.org/cgi-bin/mesg.cgi?a=linux-mips&i=20070919084515.GM9972%40networkno.de > > > >it would seem so. > > Drat, I probably posted too soon. That is the smp_llsc_mb(); isn't it. Yes - and the answer to your original question is a clear and definate maybe ;-) In the kernel we can afford to optimize for every piece of silicon on earth. In userspace we can't make that sort of compile time choices as easily so it's a better idea to just litter a few SYNCs over the code. Ralf From ralf@linux-mips.org Mon Oct 1 11:44:04 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 01 Oct 2007 11:44:06 +0100 (BST) Received: from localhost.localdomain ([127.0.0.1]:31714 "EHLO dl5rb.ham-radio-op.net") by ftp.linux-mips.org with ESMTP id S20022183AbXJAKoE (ORCPT ); Mon, 1 Oct 2007 11:44:04 +0100 Received: from denk.linux-mips.net (denk.linux-mips.net [127.0.0.1]) by dl5rb.ham-radio-op.net (8.14.1/8.13.8) with ESMTP id l914Miss022359 for ; Mon, 1 Oct 2007 05:22:44 +0100 Received: (from ralf@localhost) by denk.linux-mips.net (8.14.1/8.14.1/Submit) id l914Mh1b022358; Mon, 1 Oct 2007 05:22:43 +0100 Date: Mon, 1 Oct 2007 05:22:43 +0100 From: Ralf Baechle To: Mark Zhan Cc: i2c@lm-sensors.org, linux-mips@linux-mips.org, rtc-linux@googlegroups.com, a.zummo@towertech.it Subject: Re: [PATCH 4/4] MIPS: Remove the legacy RTC codes of MIPS sibyte boards Message-ID: <20071001042243.GA22342@linux-mips.org> References: <46FF7283.7050702@windriver.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <46FF7283.7050702@windriver.com> User-Agent: Mutt/1.5.14 (2007-02-12) Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 16755 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: ralf@linux-mips.org Precedence: bulk X-list: linux-mips On Sun, Sep 30, 2007 at 05:55:15PM +0800, Mark Zhan wrote: > This patch removes the legacy RTC codes of MIPS sibyte boards, > which are replaced by new RTC class drivers. And a board init > routine is added to register sibyte platform devices. > > Signed-off-by: Mark Zhan > --- > arch/mips/sibyte/swarm/Makefile | 2 > arch/mips/sibyte/swarm/rtc_m41t81.c | 232 > --------------------------------- > arch/mips/sibyte/swarm/rtc_xicor1241.c | 209 ----------------------------- > arch/mips/sibyte/swarm/setup.c | 56 +++++-- > 4 files changed, 37 insertions(+), 462 deletions(-) Patch looks okay but does not apply to the top of the -queue tree due to the dyntick patches which basically turn every piece of time code on MIPS upside down. Can you respin this patch against the -queue tree? Thanks, Ralf From yoichi_yuasa@tripeaks.co.jp Mon Oct 1 11:49:30 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 01 Oct 2007 11:49:38 +0100 (BST) Received: from mo32.po.2iij.NET ([210.128.50.17]:53064 "EHLO mo32.po.2iij.net") by ftp.linux-mips.org with ESMTP id S20022266AbXJAKta (ORCPT ); Mon, 1 Oct 2007 11:49:30 +0100 Received: by mo.po.2iij.net (mo32) id l91AnRpB098352; Mon, 1 Oct 2007 19:49:27 +0900 (JST) Received: from localhost (65.126.232.202.bf.2iij.net [202.232.126.65]) by mbox.po.2iij.net (po-mbox303) id l91AnPrF030544 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 1 Oct 2007 19:49:26 +0900 Message-Id: <200710011049.l91AnPrF030544@po-mbox303.hop.2iij.net> Date: Mon, 1 Oct 2007 19:48:31 +0900 From: Yoichi Yuasa To: Ralf Baechle Cc: yoichi_yuasa@tripeaks.co.jp, linux-mips , Richard Purdie Subject: [PATCH][3/3] add LED support to cobalt_defconfig References: <20071001194505.979185df.yoichi_yuasa@tripeaks.co.jp> Organization: TriPeaks Corporation X-Mailer: Sylpheed version 2.3.0beta5 (GTK+ 2.8.20; x86_64-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 16756 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: yoichi_yuasa@tripeaks.co.jp Precedence: bulk X-list: linux-mips Add LED support to cobalt_defconfig. Signed-off-by: Yoichi Yuasa diff -pruN -X mips/Documentation/dontdiff mips-orig/arch/mips/configs/cobalt_defconfig mips/arch/mips/configs/cobalt_defconfig --- mips-orig/arch/mips/configs/cobalt_defconfig 2007-09-06 13:09:26.597218500 +0900 +++ mips/arch/mips/configs/cobalt_defconfig 2007-09-06 13:21:20.681846000 +0900 @@ -1,7 +1,7 @@ # # Automatically generated make config: don't edit -# Linux kernel version: 2.6.23-rc2 -# Tue Aug 7 22:12:54 2007 +# Linux kernel version: 2.6.23-rc5 +# Thu Sep 6 13:14:29 2007 # CONFIG_MIPS=y @@ -55,12 +55,14 @@ CONFIG_DMA_NONCOHERENT=y CONFIG_DMA_NEED_PCI_MAP_STATE=y CONFIG_EARLY_PRINTK=y CONFIG_SYS_HAS_EARLY_PRINTK=y +# CONFIG_HOTPLUG_CPU is not set CONFIG_I8259=y # CONFIG_NO_IOPORT is not set # CONFIG_CPU_BIG_ENDIAN is not set CONFIG_CPU_LITTLE_ENDIAN=y CONFIG_SYS_SUPPORTS_LITTLE_ENDIAN=y CONFIG_IRQ_CPU=y +CONFIG_IRQ_GT641XX=y CONFIG_PCI_GT64XXX_PCI0=y CONFIG_MIPS_L1_CACHE_SHIFT=5 @@ -235,6 +237,7 @@ CONFIG_TRAD_SIGNALS=y # Power management options # # CONFIG_PM is not set +CONFIG_SUSPEND_UP_POSSIBLE=y # # Networking @@ -844,7 +847,21 @@ CONFIG_USB_MON=y # # CONFIG_USB_GADGET is not set # CONFIG_MMC is not set -# CONFIG_NEW_LEDS is not set +CONFIG_NEW_LEDS=y +CONFIG_LEDS_CLASS=y + +# +# LED drivers +# +CONFIG_LEDS_COBALT_QUBE=y +CONFIG_LEDS_COBALT_RAQ=y + +# +# LED Triggers +# +CONFIG_LEDS_TRIGGERS=y +# CONFIG_LEDS_TRIGGER_TIMER is not set +# CONFIG_LEDS_TRIGGER_HEARTBEAT is not set # CONFIG_INFINIBAND is not set CONFIG_RTC_LIB=y CONFIG_RTC_CLASS=y From yoichi_yuasa@tripeaks.co.jp Mon Oct 1 11:49:59 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 01 Oct 2007 11:50:02 +0100 (BST) Received: from mo32.po.2iij.NET ([210.128.50.17]:52296 "EHLO mo32.po.2iij.net") by ftp.linux-mips.org with ESMTP id S20022268AbXJAKta (ORCPT ); Mon, 1 Oct 2007 11:49:30 +0100 Received: by mo.po.2iij.net (mo32) id l91AnQhN098339; Mon, 1 Oct 2007 19:49:26 +0900 (JST) Received: from localhost (65.126.232.202.bf.2iij.net [202.232.126.65]) by mbox.po.2iij.net (po-mbox302) id l91AnPFR003670 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 1 Oct 2007 19:49:25 +0900 Message-Id: <200710011049.l91AnPFR003670@po-mbox302.po.2iij.net> Date: Mon, 1 Oct 2007 19:46:50 +0900 From: Yoichi Yuasa To: Ralf Baechle Cc: yoichi_yuasa@tripeaks.co.jp, linux-mips , Richard Purdie Subject: [PATCH][2/3] add Cobalt Qube series front LED support to platform register In-Reply-To: <20071001194505.979185df.yoichi_yuasa@tripeaks.co.jp> References: <20071001194505.979185df.yoichi_yuasa@tripeaks.co.jp> Organization: TriPeaks Corporation X-Mailer: Sylpheed version 2.3.0beta5 (GTK+ 2.8.20; x86_64-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 16757 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: yoichi_yuasa@tripeaks.co.jp Precedence: bulk X-list: linux-mips Add Cobalt Qube series front LED support to platform register. Signed-off-by: Yoichi Yuasa diff -pruN -X mips/Documentation/dontdiff mips-orig/arch/mips/cobalt/led.c mips/arch/mips/cobalt/led.c --- mips-orig/arch/mips/cobalt/led.c 2007-09-21 13:05:53.812412000 +0900 +++ mips/arch/mips/cobalt/led.c 2007-09-21 13:20:02.105427000 +0900 @@ -22,6 +22,8 @@ #include #include +#include + static struct resource cobalt_led_resource __initdata = { .start = 0x1c000000, .end = 0x1c000000, @@ -33,7 +35,11 @@ static __init int cobalt_led_add(void) struct platform_device *pdev; int retval; - pdev = platform_device_alloc("cobalt-raq-leds", -1); + if (cobalt_board_id == COBALT_BRD_ID_QUBE1 || + cobalt_board_id == COBALT_BRD_ID_QUBE2) + pdev = platform_device_alloc("cobalt-qube-leds", -1); + else + pdev = platform_device_alloc("cobalt-raq-leds", -1); if (!pdev) return -ENOMEM; From ralf@linux-mips.org Mon Oct 1 11:50:23 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 01 Oct 2007 11:50:26 +0100 (BST) Received: from localhost.localdomain ([127.0.0.1]:51114 "EHLO dl5rb.ham-radio-op.net") by ftp.linux-mips.org with ESMTP id S20022277AbXJAKuF (ORCPT ); Mon, 1 Oct 2007 11:50:05 +0100 Received: from denk.linux-mips.net (denk.linux-mips.net [127.0.0.1]) by dl5rb.ham-radio-op.net (8.14.1/8.13.8) with ESMTP id l91Ao45W031932; Mon, 1 Oct 2007 11:50:04 +0100 Received: (from ralf@localhost) by denk.linux-mips.net (8.14.1/8.14.1/Submit) id l91Ao3MJ031931; Mon, 1 Oct 2007 11:50:03 +0100 Date: Mon, 1 Oct 2007 11:50:03 +0100 From: Ralf Baechle To: KokHow.Teh@infineon.com Cc: linux-mips@linux-mips.org Subject: Re: Linux-2.6.20 malta board build with GCC-4.0.0 build error Message-ID: <20071001105003.GA23647@linux-mips.org> References: <31E09F73562D7A4D82119D7F6C17298602667FE0@sinse303.ap.infineon.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <31E09F73562D7A4D82119D7F6C17298602667FE0@sinse303.ap.infineon.com> User-Agent: Mutt/1.5.14 (2007-02-12) Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 16758 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: ralf@linux-mips.org Precedence: bulk X-list: linux-mips On Sun, Sep 30, 2007 at 05:18:39PM +0800, KokHow.Teh@infineon.com wrote: > I am using eldk-4.1 with gcc-4.0.0 to build linux-2.6.20 for > Malta board little-endian. I bump into following build error with > mipsel-linux-ld: Odd. All I can tell you is the linuxel-mips target of SDE and the vanilla GNU toolchain builds are working right out of the box. But keepfiners away from binutils 2.18 which will produce a bad executable, something I still haven't managed to enquire. Ralf From yoichi_yuasa@tripeaks.co.jp Mon Oct 1 11:50:47 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 01 Oct 2007 11:50:57 +0100 (BST) Received: from mo31.po.2iij.NET ([210.128.50.54]:11025 "EHLO mo31.po.2iij.net") by ftp.linux-mips.org with ESMTP id S20022268AbXJAKuq (ORCPT ); Mon, 1 Oct 2007 11:50:46 +0100 Received: by mo.po.2iij.net (mo31) id l91AnS44099021; Mon, 1 Oct 2007 19:49:28 +0900 (JST) Received: from localhost (65.126.232.202.bf.2iij.net [202.232.126.65]) by mbox.po.2iij.net (po-mbox301) id l91AnOQ5021292 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 1 Oct 2007 19:49:25 +0900 Date: Mon, 1 Oct 2007 19:45:05 +0900 From: Yoichi Yuasa To: Ralf Baechle Cc: yoichi_yuasa@tripeaks.co.jp, linux-mips , Richard Purdie Subject: [PATCH][1/3] add Cobalt Raq LED platform register and power off trigger Message-Id: <20071001194505.979185df.yoichi_yuasa@tripeaks.co.jp> Organization: TriPeaks Corporation X-Mailer: Sylpheed version 2.3.0beta5 (GTK+ 2.8.20; x86_64-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 16759 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: yoichi_yuasa@tripeaks.co.jp Precedence: bulk X-list: linux-mips Hi Ralf, The Cobalt LED drivers have already been queued for 2.6.24. Please queue these patches too. Yoichi --- Add Cobalt Raq LED platform register and power off trigger. Signed-off-by: Yoichi Yuasa diff -pruN -X mips/Documentation/dontdiff mips-orig/arch/mips/cobalt/Makefile mips/arch/mips/cobalt/Makefile --- mips-orig/arch/mips/cobalt/Makefile 2007-09-21 10:24:16.864636000 +0900 +++ mips/arch/mips/cobalt/Makefile 2007-09-21 11:25:43.384914000 +0900 @@ -2,7 +2,7 @@ # Makefile for the Cobalt micro systems family specific parts of the kernel # -obj-y := buttons.o irq.o reset.o rtc.o serial.o setup.o +obj-y := buttons.o irq.o led.o reset.o rtc.o serial.o setup.o obj-$(CONFIG_PCI) += pci.o obj-$(CONFIG_EARLY_PRINTK) += console.o diff -pruN -X mips/Documentation/dontdiff mips-orig/arch/mips/cobalt/led.c mips/arch/mips/cobalt/led.c --- mips-orig/arch/mips/cobalt/led.c 1970-01-01 09:00:00.000000000 +0900 +++ mips/arch/mips/cobalt/led.c 2007-09-21 11:26:18.519109750 +0900 @@ -0,0 +1,56 @@ +/* + * Registration of Cobalt LED platform device. + * + * Copyright (C) 2007 Yoichi Yuasa + * + * 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., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA + */ +#include +#include +#include +#include + +static struct resource cobalt_led_resource __initdata = { + .start = 0x1c000000, + .end = 0x1c000000, + .flags = IORESOURCE_MEM, +}; + +static __init int cobalt_led_add(void) +{ + struct platform_device *pdev; + int retval; + + pdev = platform_device_alloc("cobalt-raq-leds", -1); + + if (!pdev) + return -ENOMEM; + + retval = platform_device_add_resources(pdev, &cobalt_led_resource, 1); + if (retval) + goto err_free_device; + + retval = platform_device_add(pdev); + if (retval) + goto err_free_device; + + return 0; + +err_free_device: + platform_device_put(pdev); + + return retval; +} +device_initcall(cobalt_led_add); diff -pruN -X mips/Documentation/dontdiff mips-orig/arch/mips/cobalt/reset.c mips/arch/mips/cobalt/reset.c --- mips-orig/arch/mips/cobalt/reset.c 2007-09-21 10:24:16.864636000 +0900 +++ mips/arch/mips/cobalt/reset.c 2007-09-21 11:25:43.616928500 +0900 @@ -8,31 +8,37 @@ * Copyright (C) 1995, 1996, 1997 by Ralf Baechle * Copyright (C) 2001 by Liam Davies (ldavies@agile.tv) */ +#include #include - -#include -#include +#include #include +DEFINE_LED_TRIGGER(power_off_led_trigger); + +static int __init ledtrig_power_off_init(void) +{ + led_trigger_register_simple("power-off", &power_off_led_trigger); + return 0; +} +device_initcall(ledtrig_power_off_init); + void cobalt_machine_halt(void) { int state, last, diff; unsigned long mark; /* - * turn off bar on Qube, flash power off LED on RaQ (0.5Hz) + * turn on power off LED on RaQ * * restart if ENTER and SELECT are pressed */ last = COBALT_KEY_PORT; - for (state = 0;;) { - - state ^= COBALT_LED_POWER_OFF; - COBALT_LED_PORT = state; + led_trigger_event(power_off_led_trigger, LED_FULL); + for (state = 0;;) { diff = COBALT_KEY_PORT ^ last; last ^= diff; From ralf@linux-mips.org Mon Oct 1 11:59:56 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 01 Oct 2007 11:59:59 +0100 (BST) Received: from localhost.localdomain ([127.0.0.1]:56012 "EHLO dl5rb.ham-radio-op.net") by ftp.linux-mips.org with ESMTP id S20022280AbXJAK74 (ORCPT ); Mon, 1 Oct 2007 11:59:56 +0100 Received: from denk.linux-mips.net (denk.linux-mips.net [127.0.0.1]) by dl5rb.ham-radio-op.net (8.14.1/8.13.8) with ESMTP id l91AxtPV013546; Mon, 1 Oct 2007 11:59:55 +0100 Received: (from ralf@localhost) by denk.linux-mips.net (8.14.1/8.14.1/Submit) id l91AxsUN013495; Mon, 1 Oct 2007 11:59:54 +0100 Date: Mon, 1 Oct 2007 11:59:54 +0100 From: Ralf Baechle To: veerasena reddy Cc: linux-mips , "linux-kernel.org" Subject: Re: linux cache routines for Write-back cache policy on MIPS24KE Message-ID: <20071001105954.GB23647@linux-mips.org> References: <119374.35234.qm@web8401.mail.in.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <119374.35234.qm@web8401.mail.in.yahoo.com> User-Agent: Mutt/1.5.14 (2007-02-12) Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 16760 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: ralf@linux-mips.org Precedence: bulk X-list: linux-mips On Mon, Oct 01, 2007 at 10:04:32AM +0100, veerasena reddy wrote: > I have ported Linux-2.6.18 kernel on MIPS24KE > processor. I am using write back cache policy. > > Could you please guide me under what cases the below > cache API's are being used: > - dma_cache_wback_inv() : Could you explain what > exactly this function does > - dma_cache_wback() : This function write back the > cache data to memory > - dma_cache_inv : This function invalidate the cache > tags. so subsequent access will fetch from memory. > > Once I looked the above function definitions in > linux-2.6.18/arch/mips/mm/c-r4k.c. > All these function's implemetation are same except > bc_wbak_inv() is called in both dma_cache_wback-inv() > and dma_cache_wback(), where as bc_inv() is called in > case of dma_cache_inv. > > Also, bc_inv()/bc_wbak_inv are define as null > implementation for R4000. > That means all three functions are doing same > functionality in case of R4000. > > What are the difference between these three functions. > Under what cases these functions are used. An internal only interface to be used with I/O cache coherency. > Please guide me if you have any links which will > explain these API's. Easy answer, don't use them, for 2.6.24 I've queued a patch to kill this API. Documentation/DMA-API.txt documents how to properly deal with I/O coherency in Linux. Ralf From aurel32@hall.aurel32.net Mon Oct 1 12:36:18 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 01 Oct 2007 12:36:25 +0100 (BST) Received: from hall.aurel32.net ([88.191.38.19]:32728 "EHLO hall.aurel32.net") by ftp.linux-mips.org with ESMTP id S20022557AbXJALgR (ORCPT ); Mon, 1 Oct 2007 12:36:17 +0100 Received: from aurel32 by hall.aurel32.net with local (Exim 4.63) (envelope-from ) id 1IcJWJ-0008IG-I9 for linux-mips@linux-mips.org; Mon, 01 Oct 2007 13:33:03 +0200 Date: Mon, 1 Oct 2007 13:33:03 +0200 From: Aurelien Jarno To: linux-mips@linux-mips.org Subject: Config file Message-ID: <20071001113303.GB31557@hall.aurel32.net> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="2oS5YaxWCcQjTEyO" Content-Disposition: inline X-Mailer: Mutt 1.5.13 (2006-08-11) User-Agent: Mutt/1.5.13 (2006-08-11) Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 16761 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: aurelien@aurel32.net Precedence: bulk X-list: linux-mips --2oS5YaxWCcQjTEyO Content-Type: text/plain; charset=iso-8859-15 Content-Disposition: inline Please find attached the configuration file I used to test dyntick on QEMU/Malta. -- .''`. Aurelien Jarno | GPG: 1024D/F1BCDB73 : :' : Debian developer | Electrical Engineer `. `' aurel32@debian.org | aurelien@aurel32.net `- people.debian.org/~aurel32 | www.aurel32.net --2oS5YaxWCcQjTEyO Content-Type: application/octet-stream Content-Disposition: attachment; filename="config-mipsel-malta-r4k.gz" Content-Transfer-Encoding: base64 H4sICJraAEcCA2NvbmZpZy1taXBzZWwtbWFsdGEtcjRrAIxc7XPbKLf/vn+Fpntn7u7Mbuv3 ODuTDwghm1oSBJBf+kXjJm7r2zTO4zi7+/z39yDJNpIBd6ZNHM4POMDhvAH+9ZdfA/R22P1Y H7YP66en/wZfN8+b/fqweQx+rL9vgofd85ft17+Cx93z/x6CzeP2ADWS7fPbv8H3zf558xT8 vdm/bnfPfwW996P3vf6f+4cxQNLdc8AeDkHQDTrdv/rDvzq9oNfp3Pzy6y+YZTGdFCnl8u6/ v0ABoNcP37bPm+B187R5OEBrZ9gnlpEiShFAfw2OVRGeFijBU5Kugu1r8Lw7QNXDGRAimRBR kCWmitgROB3cLJdWmuaswCxEibLTdfcRwVIhRVnmxnxEnz5ZqQmSyN52QlKmSBHnCcsmbu6Q giZMsklMgfHmfOlSSVDkblDS1DEOMSM0k+5BzsWg65hIni3Hw2Gn+BhKL12qcNzt2CEpLlLJ nbQVkyR1LfI9SXMrQU5oQXmv5yPeeIh9R00armDxsJjSjHgRSKQkudIG87dxFSAX0IsPkFCl EiJz4W2FZIpJ5INwdbWrkE6c/WS0cFSGjqc0RMXHVPRvHQtyxIhQLQc/B+qPraCFKDiIlGVX iQUIWTEhGREUF5LTLGF4Zu4wJGAnTJEsaMImvSJ3CEgbNhpYejv2E9MsKjKyVDB7CjprkacL QidTCwGjhIYCwaxHJEErC0BzT+awsPKSqGhKLFVSJoucR9DqmShBAQOHTP9jsAmLWKAUxIHR TBFhTs+JZyQiKu6lrlFErIDPlgkoZylFK4DPoTmYiQifewVbANUzzKZEwBBaBAIccUyhOi+0 fjbYJUgkq4IL4G5mDGIlyxVpUU+sT5niST4pMM8trNJxb3h7bqxUpSHLqGKjQas4ldhsF2aA Ms6E8kgAlaht+oANvZkKkkUUZZa6GlBt7BrTHKrMue5UGo04AI5GYMl0HxdjhpWVmvEzQS/D RI0Gy+VSf+4Y/SxgdSiDnYSwsUAhY6ogSdzvtVpPuiDUIGwF7OJY3Q0rp0GviMVhUBTPClCN Elbu3A5M9/TT+c8pbJ1CEFmKu5DtGU4YWF/Jsp5jgjVX/V4huu2KR4J9+x8RowFUvYpwtyH6 nU7HSVXL/q3DIGuyx16XbQ/6nrbFYOnteeDrWQx9bIvhoO8Z8shXNyNzFCF35bG3427HS05v /ORbH1mGXYsMHZVOW5Y85J6bXIqTnVxNjJ1WDexMO/d2WdZu/6Ql+j0wTsWMiIwkDshoYIOU k+Nopdzesyq8OPz3ZXPe3CXQ3HRl45YZ5mgC6oJ+IsVgFpoVzoTxLLS7lSdEd3QVMho0ISdV BvoQDKTWWi1lVg68RdBlelm4IDFReNo2HaqIwBaECYku3HqgyZS7HfuSrrBDCE8rkOaJomoq IEig2eSilzkHd5GhiAiHRtTcJ0nTxB3LJQQRSjfjqStXGbb4OLW/cEnRZogLFhKHRGkFn5LU IZInjs700umIE6SgFhg9PdlGZZIQrAogMbEqUhaZknyslKIsR4k5AbBo8EnRyZlsd4E5EuBh WkHNTpq9glWLSFHV42bH5wbLGNW6+hwMPLju2hfUUyfvBuf6YBlZLjCRzv11DMs1H5O77lnu 88w06XMqFHjfRZg3bOz0UzGwO+FA6TrUqSb1xhZegNAbdlrt94YjTwfuHjq9wbW9goTWVg13 4tMdcHDSPYKQlOvVyUhD9dTlc5bkmULCnruoUVbajCwJtosQwZg19cAxowALHBF+ZN8QaoXw TAlwwS5pEYmP1alUd+8+PG0/f/ixe3x72rx++J88036+gE2BJPnwvsoRvavU9qTMHz1pDt5e zoqbLDns2xQcdmRsnVCwGcnAW9M6zPAxwYGGPTiHmdYMQGhx1+8Z40HJHJw2yrK7d++M1IlB KFCumG0dF4g3dMKccnxRoH9jZfDJmaTLIr3PSW76qzLSOgi2CcgExspNKeZ9UxAUkjO9Me1Z kVwSUWQ2ZYnyyIwE6az6cFlSdn4uhmATdmBcu8/dgTHcWMJag8hhCJUaxkXo2NFm2ZIZ1JiX aySi5ppB+AftVaqjsTQYF4yDq60tZsxEaTrtu6wx7SQNSRSRqLFAgCh/ocRAzuAvuUobSuZY BrIHnIHNlrY5reM7Y61bAWJoEiE6KTATphDAFtDpOtMg5IosDcsCegCmB1S1YW4IZ2YVSScZ SmJjpGV8bhbIpj2bpxUE2Ml1uG20LRPUcHlkktvdGJkwm/MCKjvVQyCN6VQ0W1VM2KRCzwJY VRjTSQ2CmcwTc8xVQZFn2pO4KAa5wFZivaUbzNR1pMCnDZ/YzOYMgMZatdM2SWhPiZ6EnBWl grSnamXsrRzKRgK31I6UBfLh20br0f3rWTtSdsylMFMN1qVIXpZF4KglNCOXFBzfN3wQEiPw 7QpkVzZH8rE9yxweIY6GNc+eWjVbd+8evvynNhHh22uwe9FR+2vwG8f0j4DjFFP0R0DAy/0j KH8o/Pt5fqaLyj3GtJFeaOYaIpYi2hST0qk7+7iS2lLmqZHM0Pmc/jEC4RiD/6lZ1Nx9wOv9 I7D+e/D69vKy2x+qJMSx/xJqdSrqBBKweCEO5N/Nw9th/flpE3zZ6h+7/Y/1wRCMkGZxWiZF zGHVpSm4l5YBgcRGtUI5HbDw3T+bffBj/bz+uvmxeT4c578xBtvGlrnkJIuKnGsjKGnlFpfV ss3hn93++/b565nfjKhLstHZKX7CM2JYsupvWArTOucZXTYyZkSHiDabRDOzMcqraAYj2SxF 0RyBdxoVguVVgvIoJnKm6TENtZhNzU7rYiWobWs0K7X656CglI4jZINWdl4jkJpaaKDSQiZJ iw2e2aM8PS2UUx9xIhzMp2WHDRY4TWVazLu2wl5zb/HIasMzMElsRpvWQy9RgaZWJksacRzy 0GoIbee2SV/GIi1UnmWOQ5USdI1eNqJjO72DMtnOzTrBP91sSIinxYiiiW03Yw7zmU1O0nte mBMppI24+1SO85Daw4UTZEGkWjAW+VFT+HQFIa9DVmGC/JA5mTjs1AmiHT+9qfyohF/rKGN+ xIo4pPWEoAkYTEalx/i1FuZkSZ3rckQ4J/wIcM/UEeFd2SNItOahRT6O9e7d5+3Du+YcpNEQ jIxdnnkxlw7KfOTcAqOf2scjHwDoIB3E5goCacHETEfK+lDbOBogKqZJ68TqVAhzARHAheXG u/1Gmzgw2wewrLgMgd/26/oswtKOZo1mMzvbOqrIMu1rzurkU3QV6JqAur9lZXsuXVD+188w DmsInZURr2uNgU75ZS8tCNgJPybCDlkHGkR7jp0MJsF+xKrsZ8mhoNHEPpR5grJi3Ol17x17 BWfElgNLksbuhj97jnEsHayixL6Ky97QcW+E2yM5Ar8dxmUBg6scngtRuN/JYP38+GG3D76s t/vgP2+bt03bn6uOeRvbRReB4xOzo693X1f8UAc3VRsNL0RXweG900vR9KkK/fRYYi8AYnfm BQjhJ7u2XU2XsX8AitwnfkAYe+mTaxxEOnU980LgN0m9CJpBP/JSNeCn9evr9sv2Yd08UtX1 cCLbzjgU6cCfutdEIxSmWUSWXkwpnwMvJF54ya4bF6ce5JxfBYzsZqMgKWocypzLqiSqzk42 GqyJOHX3WUMyfT3mGsg3uBqSEoWuYRRZKscI9QwgrNorDEUQ9iUUu1nUkAn88AJSKnyCXXZD IupvRNLUv4SXnJqBaHDYvB4sionP1ITYblJMUQqRND0pOb5++L45BGL9uN0FL/vdYfewe2pE 0Milt6lwnE6H9iGjuBBLwW3RvY43RZ1XK/tebPebp81rgxEcT7Q9sx09L6jO28syK9q6U3lR 5cw/IcRNFfGMJm69d8svliTa/L192ATRfvt3lQc7Hx1sH+rigLWzBrDXsgglzMx6cVFlQWMq 0gUSEGTlNGkksuOF5eTynALVB+IrTsScSmaHaIeLYOWgpipyHBELZwRZZwgdh7YSayJIsi2y oJEZruvTP7Qspgsa6/O7dvYyOuVq+NNm/arv18Kk7x7edAqo1PEfto+b94d/DzrzFHzbPL18 2D5/2QW75wAqB496IRqCZTRdSNRUOZeQiMpGurUuqpIfZUzsz76C5xVdQyjEr7YSJ4zz1TWU xM38oMl2eWRTUIZVYl+U8sSliE+7Uk/fw7ftC6CO+cIPn9++ftn+uzHzvlCxPtE2s9Qnlho5 zurvQk61mFNxf0GB/2EuCyaiZixzbJDFcXkvwbNoZ2Yua3NFR73ulRVPUZ2Ytc1weV6s0/yR a541gmXJSouJd70QwaOe467RCZPQ7nDZ92PS6GbQbKeFwGk0GixtI1KCxgnx84BX4x4e3fqZ wHI47HWuQvodD5tTrvpNNquS8iQUpvVK1dHINsKPKcXCccP9iJG42+v4OOOUWqePqnGv65+Y EuKf4EyObwbdoa//CPc6ICsFaxqGU3mYC6l+poGMLGwDkfPFTHrqS0pTNCHWqgm+7ZDRyDtE JdLerV885hSBnC2vbAiFxyPc6XSdWq51i9u6g9sKHXYsnYfefqfRhQdQKtvHyg2wnKcIRCOI j5Wwzauua95ClrR9S7YsUxO79S2JlmyMSW5p85Lbms3yRlrw2+P29fsfwWH9svkjwNGfgqW/ 2wyltKs6PBUVWXnJTErl33zC3/zET8bTy4XZ/diYq/Ma/LZ5//U9jDH4v7fvm8+7f08HYMGP t6fD9uVpEyR5ZvppegYrGw+E1krBZ+3HmVfPy/KETSbVzTOzVGKUFah5OawkLBBVJfXuh7FE ar9+ftWsNZyWqiVOLwWqCYnxNQQtf14BSX0VjoYSeTAJWyTguCauvJDdNbzcRvGbfnsV6PtC 7s0U59L1TKki6cnxkWPsrYwsSUYIGIJu/3YQ/BZDfKJjFOu5KbjtREckzqijbMNK7DF7LFv7 zq1Qti6txNKT1YztmizKU9dTM5bpG5Ou91E6t2jP2N3n4J98coQlKs9cD0hceT4+XYHUuTIY aqov1yrzYmnDS0PL8fjm1nFlDoH3nBLX5cU8mzjyTRhJSTPq4AnitoiJoo9ZanIyh6jJ4VSp FZ8yhyRHF/ewja5UnlDePInpdTsDRy8a7MgED5b2AH9BMy0IxXjQcXHX7diTONDbsDeyszLl XeeYWvcfoMi8uF0XFBnizXVOo3G329UCYRewCHFFsI61RezamOHAvicr397VtML94bhrn79o 4tCohIApdt0IJS5CDMKaOVKOSOkXg45sRW/WvqdxIo5BFTkOKjRJMeZ4ACdvXexzil0jgF0V 6eNe+0y6lAq4gYXn8SG+7XX6XafaLC/GNoQFk8x1UJn0Zs41sQ8JPPX+2BHmTJF+S2qf+BVJ wFzG1D5kMe6Obl0z33W4zXLmOAqSs5XjaefsdpxQ96yDLWeYqpXjsGrCMkekky3tHd4nqO/y 55FKrqxiYxnxlCRSX2VzvDk6ku0c0uXEcXuw5zhsSVeCdjsTZ854SbLCJVdpshyUNyytF5sa sUeYMscpcZgmdm3SBxVkFxaVyv64oy7PyI7p1QD23NnFXegjQy6qpGgj8lCC2q7DLY5njN3m tZ5Fz6UBNK3noIGhJ0I5HEyw9KnjtFW/IUgct86pTIcDxw02sAbWQZUPA43TySwlEbU7r9Mo cWkSbPMQ4iiirbsTjt0gZ7GNuSnlTdMnGIqEvjpgd7k4545LstYF1SY4biTKJPhJxHm+qOMe ljj3hL4O7Myga6IOnJSAD44uqIwyh1/YeideOejPL2+Hy5jhdM+C56p5fQsKijjWj02S1tFh C6SZbSW3yx7z183+af38GGyfD5v9l/VDIxFaVk1ZLsF/mJu3ys3ygkuUL51UiQUB1bK80484 /JjV3c1o3Ob8I1u5svIVQEk/ncyv0W1XSaqluDgSadSckVWZujVuvNclsKdnYSOvdaKADzFz XHA+YZLZVchSXYVkZKEcfvmZG8UWaIHs9zdPa9S85A0FsOZ2A1lRJRHUEZhUgLkEK4qQs1dY dKmfDJsdH8sKlKGE2WO7M6YfXQFE1A/ALBTID5nEDnfrjBCOoKWBKNJroJwm5XeQ+GHlC3/X qe8JJWkE0X3mOns74VQa4Sv9laGFH7NAQlB2pSudiE1c7vOZcf0wnYnwJ1AhcijuM0xRiJCv TcGCRvCHH6QVVG595FXrJ33PSrX1o2I5nlZ6r3FL9FwMIipvxoOR47szzrg4/0iVzK/iJnn2 iVxFgct8FZOWf1yHzW66vasoTrJUv5a5Ciw/C/31Gj8HXTgiAxOY47A7cPl6lQJs3ecvrcN0 vX/8Z73fBPQDC46pzdOjP1FeTzD/LOi4M2hc1K6K4afj2yYqOoS9oGnbjYGjWZW2WhPIfh1n glLS7qbK931b79cP+sZhnVY+j2JuSOxcFbWjZDyuXBhl56BLGQT9IsKZhatMhH6NWV0gEJbT iM1+u36qzrv3rQmGquPqeell4SWzJrGRoTEJmShyJJRxZG9SwUfV30rhg5ClIlnUfLBn0lOU rYry0YtjvY9A8zDZ2lJElH75bP+ilgbXEp1efuye/9RlAC2ntTwruPAx68rN13RGoW3Ra/JH aTum0u9FbscFV6tG8jchE4RXZbEjzkppMQXBSKyP2xf66lTEGk/ij2UgU+DQsPxS3Bfrw8O3 x93XS7fuPBYWq1NLFw2A7Pz5ef26eTw3pd8fNR/swJbFthbOjEbKlc6CzSNg0Cy1PgBsBDai fzuyR4aI84RiZs/+Ro5vdQLdATQ6d6W+Mfy3vkUC57p+pWycAlxqTH2YcSlt3NyLXH9BkKyu fJ/qpOvX+kb0Yb97eoKPtlWDqiFVIcom1o55fS+sbu2iLlKOK2KaCP9dAYQmq4SMeku7BVnY czucLYgoX8AlNsd7ukhZwykoC4o5jRyaFHakkAWCGcgnuch/DtX3wuKb7rgzjL0YqsY3XkCS 3nS8AI7HN/3Rdcyg5+9IUjkc3g79mFTiwU3a/QlQ2L/19zenaDQeIT9GdV1X886Qca/vhyzG /VHvZhr/BIg4UJX0lA8mCjyl3HK4/Lx9eA3k9mn78P+NXUtz4jgQ/iupuW/N8ErgsAdZtkGD X7FsEubiYggzoTYDKQhbm3+/LckGyVbbPlCU1W213upWtz4fD3fOZvvP+9vmoAG8cO7oFw1v BeBOI7dQuJ9/XQ4SAKo6y3hpztnQB+sznJhxD7cc/uxe9htNLdHOdV0vRgP13JWDHVS68v61 imk8bd5fRZ0bK5JD6DIQKmYRUFdDYLhtXJBMA8J5GQ5ovXZd5aEzVrLd/Rla97PFM+wyngRk XUm3n27PiQRSQ46+RRPBDij01/KEynaY52i346tITc9lZqCmU7iIHQgkCj8fbNPUQ6zOkofG yRpyJ208MhzHCRiakYgK7RImeLqECZ5+wmIrOo5oEs/3RPB0ITV94z3omZrHVyeHhIoIS47R r2PHLlfeWFx4QWJACwAhY4GsTqaiNVQYwmnzZ3f38/LrF+yar5XFYpmKogNYmuZoqZJwiPbc 2vHSIeZdAgbCWcBIhDY0C3mG98LAHaAOF6BHMNQZ2tGgzhC8I2BWoPmmBGZQhFYpW9cwb2pU tDojlEJWBPHNCCpDuybyYhjKDJ2hy3UaY7SR66MtsIpjN44HKDmb3g/R2mQprEB4l2N3ZeRI QzMVqEU1GKby0t/hfHyDgV0trCpQvbG0w8S0mqxgiIh4GaH4cyrO8p3aNT492qRpW0p4TSf3 YUGwZW8hV+ZbksIqlNo0QNtLaayAjY3MYW23rlCQXkz/m2qlVCkDI6A0iOexRRu4HF60rT/O I7daUcjLv5vDFswfhTUtWe/Iafu6/9htPy6nnaFYR02TPn7fHcrX+Ceo4n9M2wtEyVaxT4QF c1v3xBy0lDZ6GGJ3op7AHnUx94nPIgaWhWs3ycRhjGGWZVRt+83rFSG58w6/JaJ2fWyKeE0v mivokCs3fdvvDvrRkryRHhKdx21qSOIYOICdiWS1COOrx+f8vtnKsyv9tZw1B4Mv8C/OsqfO OmxUNlRxmGZC8SyC8JrJCqiJ0KBJ4h7NU5at9Sa85mZ18QF1VBc+sgsf4cJHLcLHwiXl2+bV d9OnA4/Ni8jVhONF6FSAghp+E+NeCjTfPtq+N0i37PSK3O6k4nnNfT7EaDFtIYYw4J8xYhqH WBlZFGfMX+sn3TJBYmfdUh/z2ARCfxSwKSv7VqNoNsRXmY0BTOVe5d+OQvIsxltIUccY2Ree KmtNK7xD1RlqEslo46/uypWT5jZnNF9wPLu//4ZJy12/RlJzPOZffZJ9hd0UyTfkwIPluoJ3 MVqUNZpGnXKdd5eXo8S+aUz9Wwi2nrA0zwtlWh02TMKaaTAZYdJ4tA/xRT73ssCR8J62NVjA mxmBNfLPXrVwf97u3oRxe7ycazXUou1ahoyP0zyarhO0tRf4i0BKghwlOx7+qtNSHGye0kaT rVqWkUWC0x6j5zFOFbh96Gi39091K1TuO7w++CL5knbjF54lhp/xbK71Mm1sPrtMmJCm6Qbp LobTqGP2wWMjPxDYBGsUBBqH6ijvFj+YGsiG8rmYc95IE76TkSYH0mC7EqzFMnUmxqZyI/Fk iSjQPHSwvqAMWyBogr4TuwSfI/ZlZXP62MtDoezz3dRYEpJmLJOAcSWejg0STK5zV9arX2Pz Afr+XbA5/L5sfsOoqetWUaAPmYBXOCp/f9mfj9PpZPbXQANREQxQOU+CCY9H9nNAg+mhF9PD pJtpOvnWh2nYh6mXuB4Fn973KdP9oA9Tn4Lfj/owjfsw9WkC5JJXjWnWzTQb9chp1qeDZ6Me 7TQb9yjT9AFvJ9BGxNgvpt3ZDIZ9ig1c+CAgnDLWWZZBJ8ewk2PUydHdJpNOjvtOjodOjll3 e3RXZtBdmwFenWXMpkXaTs5Rcp7506a+uj9/nPY/L+JbVcFx+89dKOENT8YBdxA2d4fTEdQx gUvYMI5BnfRZUANAj1VqM4ayRKh/3WxNEESFqczSR4GNzW1H+wpjVn58wmZ3SgCoIsx5JoKz qYZVJQ/ghLqjX//OIxHcCKmhE5soLcoVg6lbnkBF4EoEct9FvK5g+e17cxpzLqD5as1TkUOF UfrlSxVmsb2c9h+fTUDIpWc67cVzKV6p/d7aHspwNatrKRXcl4VCSUIc6OWM6ciMVzL3oMx6 lGmdIr9TAsoBCfvwFCsS5N4NFbfBWSL7t+TlipuCOjBsg4Os5I2drKU+qptT7xHaMysLNTDw w032chCWaGmVJoNhj5vvSiCWtesUFThvSJ6t1gEYMVr8knouSDAnure+THaCJWXJQrfvS4oJ v1kmhiSCvcLCHBLzIwUq+Zk6FBnikh7lQdBGD90xWkMBlWcRyRdk0JYl0DEQ+xvHBAl7Kzme kg6GbJ4OZq0cc38wnIZ5a+096uC1h5a11D7paPAgfWojyz8XF+qaN0DLVF/+t+XryKtGfNHa Zk9xF4uItsPcEtUwR1xzVQUJzyZdDK2jI0P8kpX8lI7b6MsF+YF8MbDKIcod1loJAb2CuY6r ucHogniB+G/vbzoatnOQ0AsCRtqbhLf2yeKpsckH+5+nzenz7nS8fOwPOwObORPgQ6kZtA4F LShlGSaHDrBOowXL8iKzjmk6GtaEPGAXg5otpX89oAk38wPeEb6HwPhYWiK/+3CLwRTfrIsN AHqVZJ5EiDTlNfgf53bOK1l0AAA= --2oS5YaxWCcQjTEyO-- From ralf@linux-mips.org Mon Oct 1 12:37:04 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 01 Oct 2007 12:37:06 +0100 (BST) Received: from localhost.localdomain ([127.0.0.1]:35507 "EHLO dl5rb.ham-radio-op.net") by ftp.linux-mips.org with ESMTP id S20022559AbXJALhE (ORCPT ); Mon, 1 Oct 2007 12:37:04 +0100 Received: from denk.linux-mips.net (denk.linux-mips.net [127.0.0.1]) by dl5rb.ham-radio-op.net (8.14.1/8.13.8) with ESMTP id l91Bb2Om028733; Mon, 1 Oct 2007 12:37:02 +0100 Received: (from ralf@localhost) by denk.linux-mips.net (8.14.1/8.14.1/Submit) id l91Bb0I8028720; Mon, 1 Oct 2007 12:37:00 +0100 Date: Mon, 1 Oct 2007 12:37:00 +0100 From: Ralf Baechle To: Yoichi Yuasa Cc: linux-mips , Richard Purdie Subject: Re: [PATCH][1/3] add Cobalt Raq LED platform register and power off trigger Message-ID: <20071001113700.GA27376@linux-mips.org> References: <20071001194505.979185df.yoichi_yuasa@tripeaks.co.jp> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20071001194505.979185df.yoichi_yuasa@tripeaks.co.jp> User-Agent: Mutt/1.5.14 (2007-02-12) Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 16762 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: ralf@linux-mips.org Precedence: bulk X-list: linux-mips On Mon, Oct 01, 2007 at 07:45:05PM +0900, Yoichi Yuasa wrote: > Add Cobalt Raq LED platform register and power off trigger. Queued for 2.6.24. Thanks! Ralf From ralf@linux-mips.org Mon Oct 1 12:37:27 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 01 Oct 2007 12:37:30 +0100 (BST) Received: from localhost.localdomain ([127.0.0.1]:58803 "EHLO dl5rb.ham-radio-op.net") by ftp.linux-mips.org with ESMTP id S20022609AbXJALhU (ORCPT ); Mon, 1 Oct 2007 12:37:20 +0100 Received: from denk.linux-mips.net (denk.linux-mips.net [127.0.0.1]) by dl5rb.ham-radio-op.net (8.14.1/8.13.8) with ESMTP id l91BbJLB028740; Mon, 1 Oct 2007 12:37:19 +0100 Received: (from ralf@localhost) by denk.linux-mips.net (8.14.1/8.14.1/Submit) id l91BbJuV028739; Mon, 1 Oct 2007 12:37:19 +0100 Date: Mon, 1 Oct 2007 12:37:19 +0100 From: Ralf Baechle To: Yoichi Yuasa Cc: linux-mips , Richard Purdie Subject: Re: [PATCH][2/3] add Cobalt Qube series front LED support to platform register Message-ID: <20071001113719.GB27376@linux-mips.org> References: <20071001194505.979185df.yoichi_yuasa@tripeaks.co.jp> <200710011049.l91AnPFR003670@po-mbox302.po.2iij.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200710011049.l91AnPFR003670@po-mbox302.po.2iij.net> User-Agent: Mutt/1.5.14 (2007-02-12) Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 16763 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: ralf@linux-mips.org Precedence: bulk X-list: linux-mips On Mon, Oct 01, 2007 at 07:46:50PM +0900, Yoichi Yuasa wrote: Queued for 2.6.24. Thanks! Ralf From ralf@linux-mips.org Mon Oct 1 12:37:51 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 01 Oct 2007 12:37:54 +0100 (BST) Received: from localhost.localdomain ([127.0.0.1]:32692 "EHLO dl5rb.ham-radio-op.net") by ftp.linux-mips.org with ESMTP id S20022729AbXJALhd (ORCPT ); Mon, 1 Oct 2007 12:37:33 +0100 Received: from denk.linux-mips.net (denk.linux-mips.net [127.0.0.1]) by dl5rb.ham-radio-op.net (8.14.1/8.13.8) with ESMTP id l91BbXu6028746; Mon, 1 Oct 2007 12:37:33 +0100 Received: (from ralf@localhost) by denk.linux-mips.net (8.14.1/8.14.1/Submit) id l91BbWxV028745; Mon, 1 Oct 2007 12:37:32 +0100 Date: Mon, 1 Oct 2007 12:37:32 +0100 From: Ralf Baechle To: Yoichi Yuasa Cc: linux-mips , Richard Purdie Subject: Re: [PATCH][3/3] add LED support to cobalt_defconfig Message-ID: <20071001113732.GC27376@linux-mips.org> References: <20071001194505.979185df.yoichi_yuasa@tripeaks.co.jp> <200710011049.l91AnPrF030544@po-mbox303.hop.2iij.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200710011049.l91AnPrF030544@po-mbox303.hop.2iij.net> User-Agent: Mutt/1.5.14 (2007-02-12) Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 16764 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: ralf@linux-mips.org Precedence: bulk X-list: linux-mips On Mon, Oct 01, 2007 at 07:48:31PM +0900, Yoichi Yuasa wrote: Queued for 2.6.24. Thanks! Ralf From geert@linux-m68k.org Mon Oct 1 12:42:45 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 01 Oct 2007 12:42:54 +0100 (BST) Received: from agave.telenet-ops.be ([195.130.137.77]:19948 "EHLO agave.telenet-ops.be") by ftp.linux-mips.org with ESMTP id S20022998AbXJALmp (ORCPT ); Mon, 1 Oct 2007 12:42:45 +0100 Received: from localhost (localhost.localdomain [127.0.0.1]) by agave.telenet-ops.be (Postfix) with SMTP id 2F8FD67D69; Mon, 1 Oct 2007 13:42:35 +0200 (CEST) Received: from anakin.of.borg (d54C15D55.access.telenet.be [84.193.93.85]) by agave.telenet-ops.be (Postfix) with ESMTP id 11E1167D5A; Mon, 1 Oct 2007 13:42:35 +0200 (CEST) Received: from anakin.of.borg (geert@localhost [127.0.0.1]) by anakin.of.borg (8.14.1/8.14.1/Debian-9) with ESMTP id l91BgYuU023078 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 1 Oct 2007 13:42:34 +0200 Received: from localhost (geert@localhost) by anakin.of.borg (8.14.1/8.14.1/Submit) with ESMTP id l91BgYxo023075; Mon, 1 Oct 2007 13:42:34 +0200 X-Authentication-Warning: anakin.of.borg: geert owned process doing -bs Date: Mon, 1 Oct 2007 13:42:34 +0200 (CEST) From: Geert Uytterhoeven To: veerasena reddy cc: linux-mips , "linux-kernel.org" Subject: Re: linux cache routines for Write-back cache policy on MIPS24KE In-Reply-To: <302271.86305.qm@web8404.mail.in.yahoo.com> Message-ID: References: <302271.86305.qm@web8404.mail.in.yahoo.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 16765 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: geert@linux-m68k.org Precedence: bulk X-list: linux-mips On Mon, 1 Oct 2007, veerasena reddy wrote: > In linux-2.6.18 (for MIPS24KE processor): > suppose if i want to do flush only then which API i > should use? `flush' is fuzzy terminology: some people mean invalidate, others mean write back, others mean both. > Similarly, if i want to do invalidation only which API > i should use? dma_cache_inv(). > --- Geert Uytterhoeven wrote: > > > On Mon, 1 Oct 2007, veerasena reddy wrote: > > > I have ported Linux-2.6.18 kernel on MIPS24KE > > > processor. I am using write back cache policy. > > > > > > Could you please guide me under what cases the > > below > > > cache API's are being used: > > > - dma_cache_wback_inv() : Could you explain what > > > exactly this function does > > > > It does both write back and invalidate. > > > > > - dma_cache_wback() : This function write back the > > > cache data to memory > > > - dma_cache_inv : This function invalidate the > > cache > > > tags. so subsequent access will fetch from memory. > > > > Note that 2.6.18 is old. The above functions are > > intended to be removed. Gr{oetje,eeting}s, Geert -- Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say "programmer" or something like that. -- Linus Torvalds From florian.fainelli@telecomint.eu Mon Oct 1 12:52:54 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 01 Oct 2007 12:53:03 +0100 (BST) Received: from smtp1.int-evry.fr ([157.159.10.44]:50657 "EHLO smtp1.int-evry.fr") by ftp.linux-mips.org with ESMTP id S20023184AbXJALwy (ORCPT ); Mon, 1 Oct 2007 12:52:54 +0100 Received: from smtp-ext.int-evry.fr (smtp-ext.int-evry.fr [157.159.11.17]) by smtp1.int-evry.fr (Postfix) with ESMTP id 9FD858E6806 for ; Mon, 1 Oct 2007 13:52:11 +0200 (CEST) Received: from [157.159.47.53] (unknown [157.159.47.53]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp-ext.int-evry.fr (Postfix) with ESMTP id 8B892D0E31B for ; Mon, 1 Oct 2007 13:52:11 +0200 (CEST) From: Florian Fainelli To: linux-mips@linux-mips.org Subject: [PATCH take 2] mtx1 default config Date: Mon, 1 Oct 2007 13:52:38 +0200 User-Agent: KMail/1.9.7 References: <200709301256.57130.florian.fainelli@telecomint.eu> In-Reply-To: <200709301256.57130.florian.fainelli@telecomint.eu> MIME-Version: 1.0 Content-Type: Multipart/Mixed; boundary="Boundary-00=_G+NAHqScz0T7Yf7" Message-Id: <200710011352.38845.florian.fainelli@telecomint.eu> X-int-MailScanner-Information: Please contact the ISP for more information X-int-MailScanner: Found to be clean X-int-MailScanner-SpamCheck: X-int-MailScanner-From: florian.fainelli@telecomint.eu Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 16766 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: florian.fainelli@telecomint.eu Precedence: bulk X-list: linux-mips --Boundary-00=_G+NAHqScz0T7Yf7 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Hi all, This patch adds a default kernel configuration for MTX-1 boards which is currently missing. Signed-off-by: Florian Fainelli -- --Boundary-00=_G+NAHqScz0T7Yf7 Content-Type: text/plain; charset="iso-8859-1"; name="mtx1_defconfig.patch" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="mtx1_defconfig.patch" diff --git a/arch/mips/configs/mtx1_defconfig b/arch/mips/configs/mtx1_defconfig new file mode 100644 index 0000000..0280ef3 --- /dev/null +++ b/arch/mips/configs/mtx1_defconfig @@ -0,0 +1,3115 @@ +# +# Automatically generated make config: don't edit +# Linux kernel version: 2.6.23-rc8 +# Sun Sep 30 12:56:10 2007 +# +CONFIG_MIPS=y + +# +# Machine selection +# +CONFIG_MACH_ALCHEMY=y +# CONFIG_BASLER_EXCITE is not set +# CONFIG_MIPS_COBALT is not set +# CONFIG_MACH_DECSTATION is not set +# CONFIG_MACH_JAZZ is not set +# CONFIG_LEMOTE_FULONG is not set +# CONFIG_MIPS_ATLAS is not set +# CONFIG_MIPS_MALTA is not set +# CONFIG_MIPS_SEAD is not set +# CONFIG_MIPS_SIM is not set +# CONFIG_MARKEINS is not set +# CONFIG_MACH_VR41XX is not set +# CONFIG_PNX8550_JBS is not set +# CONFIG_PNX8550_STB810 is not set +# CONFIG_PMC_MSP is not set +# CONFIG_PMC_YOSEMITE is not set +# CONFIG_QEMU is not set +# CONFIG_SGI_IP22 is not set +# CONFIG_SGI_IP27 is not set +# CONFIG_SGI_IP32 is not set +# CONFIG_SIBYTE_CRHINE is not set +# CONFIG_SIBYTE_CARMEL is not set +# CONFIG_SIBYTE_CRHONE is not set +# CONFIG_SIBYTE_RHONE is not set +# CONFIG_SIBYTE_SWARM is not set +# CONFIG_SIBYTE_LITTLESUR is not set +# CONFIG_SIBYTE_SENTOSA is not set +# CONFIG_SIBYTE_PTSWARM is not set +# CONFIG_SIBYTE_BIGSUR is not set +# CONFIG_SNI_RM is not set +# CONFIG_TOSHIBA_JMR3927 is not set +# CONFIG_TOSHIBA_RBTX4927 is not set +# CONFIG_TOSHIBA_RBTX4938 is not set +# CONFIG_WR_PPMC is not set +CONFIG_MIPS_MTX1=y +# CONFIG_MIPS_BOSPORUS is not set +# CONFIG_MIPS_DB1000 is not set +# CONFIG_MIPS_DB1100 is not set +# CONFIG_MIPS_DB1200 is not set +# CONFIG_MIPS_DB1500 is not set +# CONFIG_MIPS_DB1550 is not set +# CONFIG_MIPS_MIRAGE is not set +# CONFIG_MIPS_PB1000 is not set +# CONFIG_MIPS_PB1100 is not set +# CONFIG_MIPS_PB1200 is not set +# CONFIG_MIPS_PB1500 is not set +# CONFIG_MIPS_PB1550 is not set +# CONFIG_MIPS_XXS1500 is not set +CONFIG_SOC_AU1500=y +CONFIG_SOC_AU1X00=y +CONFIG_RWSEM_GENERIC_SPINLOCK=y +# CONFIG_ARCH_HAS_ILOG2_U32 is not set +# CONFIG_ARCH_HAS_ILOG2_U64 is not set +CONFIG_GENERIC_FIND_NEXT_BIT=y +CONFIG_GENERIC_HWEIGHT=y +CONFIG_GENERIC_CALIBRATE_DELAY=y +CONFIG_GENERIC_TIME=y +CONFIG_SCHED_NO_NO_OMIT_FRAME_POINTER=y +# CONFIG_GENERIC_HARDIRQS_NO__DO_IRQ is not set +CONFIG_DMA_NONCOHERENT=y +CONFIG_DMA_NEED_PCI_MAP_STATE=y +# CONFIG_HOTPLUG_CPU is not set +# CONFIG_NO_IOPORT is not set +# CONFIG_CPU_BIG_ENDIAN is not set +CONFIG_CPU_LITTLE_ENDIAN=y +CONFIG_SYS_SUPPORTS_APM_EMULATION=y +CONFIG_SYS_SUPPORTS_LITTLE_ENDIAN=y +CONFIG_MIPS_L1_CACHE_SHIFT=5 + +# +# CPU selection +# +# CONFIG_CPU_LOONGSON2 is not set +CONFIG_CPU_MIPS32_R1=y +# CONFIG_CPU_MIPS32_R2 is not set +# CONFIG_CPU_MIPS64_R1 is not set +# CONFIG_CPU_MIPS64_R2 is not set +# CONFIG_CPU_R3000 is not set +# CONFIG_CPU_TX39XX is not set +# CONFIG_CPU_VR41XX is not set +# CONFIG_CPU_R4300 is not set +# CONFIG_CPU_R4X00 is not set +# CONFIG_CPU_TX49XX is not set +# CONFIG_CPU_R5000 is not set +# CONFIG_CPU_R5432 is not set +# CONFIG_CPU_R6000 is not set +# CONFIG_CPU_NEVADA is not set +# CONFIG_CPU_R8000 is not set +# CONFIG_CPU_R10000 is not set +# CONFIG_CPU_RM7000 is not set +# CONFIG_CPU_RM9000 is not set +# CONFIG_CPU_SB1 is not set +CONFIG_SYS_HAS_CPU_MIPS32_R1=y +CONFIG_CPU_MIPS32=y +CONFIG_CPU_MIPSR1=y +CONFIG_SYS_SUPPORTS_32BIT_KERNEL=y +CONFIG_CPU_SUPPORTS_32BIT_KERNEL=y + +# +# Kernel type +# +CONFIG_32BIT=y +# CONFIG_64BIT is not set +CONFIG_PAGE_SIZE_4KB=y +# CONFIG_PAGE_SIZE_8KB is not set +# CONFIG_PAGE_SIZE_16KB is not set +# CONFIG_PAGE_SIZE_64KB is not set +CONFIG_CPU_HAS_PREFETCH=y +CONFIG_MIPS_MT_DISABLED=y +# CONFIG_MIPS_MT_SMP is not set +# CONFIG_MIPS_MT_SMTC is not set +CONFIG_64BIT_PHYS_ADDR=y +CONFIG_CPU_HAS_LLSC=y +CONFIG_CPU_HAS_SYNC=y +CONFIG_GENERIC_HARDIRQS=y +CONFIG_GENERIC_IRQ_PROBE=y +CONFIG_CPU_SUPPORTS_HIGHMEM=y +CONFIG_ARCH_FLATMEM_ENABLE=y +CONFIG_SELECT_MEMORY_MODEL=y +CONFIG_FLATMEM_MANUAL=y +# CONFIG_DISCONTIGMEM_MANUAL is not set +# CONFIG_SPARSEMEM_MANUAL is not set +CONFIG_FLATMEM=y +CONFIG_FLAT_NODE_MEM_MAP=y +# CONFIG_SPARSEMEM_STATIC is not set +CONFIG_SPLIT_PTLOCK_CPUS=4 +CONFIG_RESOURCES_64BIT=y +CONFIG_ZONE_DMA_FLAG=0 +CONFIG_VIRT_TO_BUS=y +# CONFIG_HZ_48 is not set +# CONFIG_HZ_100 is not set +# CONFIG_HZ_128 is not set +CONFIG_HZ_250=y +# CONFIG_HZ_256 is not set +# CONFIG_HZ_1000 is not set +# CONFIG_HZ_1024 is not set +CONFIG_SYS_SUPPORTS_ARBIT_HZ=y +CONFIG_HZ=250 +# CONFIG_PREEMPT_NONE is not set +CONFIG_PREEMPT_VOLUNTARY=y +# CONFIG_PREEMPT is not set +# CONFIG_KEXEC is not set +CONFIG_SECCOMP=y +CONFIG_LOCKDEP_SUPPORT=y +CONFIG_STACKTRACE_SUPPORT=y +CONFIG_DEFCONFIG_LIST="/lib/modules/$UNAME_RELEASE/.config" + +# +# General setup +# +CONFIG_EXPERIMENTAL=y +CONFIG_BROKEN_ON_SMP=y +CONFIG_INIT_ENV_ARG_LIMIT=32 +CONFIG_LOCALVERSION="" +# CONFIG_LOCALVERSION_AUTO is not set +CONFIG_SWAP=y +CONFIG_SYSVIPC=y +CONFIG_SYSVIPC_SYSCTL=y +CONFIG_POSIX_MQUEUE=y +CONFIG_BSD_PROCESS_ACCT=y +CONFIG_BSD_PROCESS_ACCT_V3=y +# CONFIG_TASKSTATS is not set +# CONFIG_USER_NS is not set +CONFIG_AUDIT=y +# CONFIG_IKCONFIG is not set +CONFIG_LOG_BUF_SHIFT=17 +CONFIG_SYSFS_DEPRECATED=y +CONFIG_RELAY=y +CONFIG_BLK_DEV_INITRD=y +CONFIG_INITRAMFS_SOURCE="" +# CONFIG_CC_OPTIMIZE_FOR_SIZE is not set +CONFIG_SYSCTL=y +CONFIG_EMBEDDED=y +CONFIG_SYSCTL_SYSCALL=y +CONFIG_KALLSYMS=y +# CONFIG_KALLSYMS_EXTRA_PASS is not set +CONFIG_HOTPLUG=y +CONFIG_PRINTK=y +CONFIG_BUG=y +CONFIG_ELF_CORE=y +CONFIG_BASE_FULL=y +CONFIG_FUTEX=y +CONFIG_ANON_INODES=y +CONFIG_EPOLL=y +CONFIG_SIGNALFD=y +CONFIG_EVENTFD=y +CONFIG_SHMEM=y +CONFIG_VM_EVENT_COUNTERS=y +CONFIG_SLAB=y +# CONFIG_SLUB is not set +# CONFIG_SLOB is not set +CONFIG_RT_MUTEXES=y +# CONFIG_TINY_SHMEM is not set +CONFIG_BASE_SMALL=0 +CONFIG_MODULES=y +CONFIG_MODULE_UNLOAD=y +# CONFIG_MODULE_FORCE_UNLOAD is not set +CONFIG_MODVERSIONS=y +CONFIG_MODULE_SRCVERSION_ALL=y +CONFIG_KMOD=y +CONFIG_BLOCK=y +CONFIG_LBD=y +# CONFIG_BLK_DEV_IO_TRACE is not set +# CONFIG_LSF is not set +# CONFIG_BLK_DEV_BSG is not set + +# +# IO Schedulers +# +CONFIG_IOSCHED_NOOP=y +CONFIG_IOSCHED_AS=y +CONFIG_IOSCHED_DEADLINE=y +CONFIG_IOSCHED_CFQ=y +# CONFIG_DEFAULT_AS is not set +# CONFIG_DEFAULT_DEADLINE is not set +CONFIG_DEFAULT_CFQ=y +# CONFIG_DEFAULT_NOOP is not set +CONFIG_DEFAULT_IOSCHED="cfq" + +# +# Bus options (PCI, PCMCIA, EISA, ISA, TC) +# +CONFIG_HW_HAS_PCI=y +CONFIG_PCI=y +# CONFIG_ARCH_SUPPORTS_MSI is not set +CONFIG_MMU=y + +# +# PCCARD (PCMCIA/CardBus) support +# +CONFIG_PCCARD=m +# CONFIG_PCMCIA_DEBUG is not set +CONFIG_PCMCIA=m +CONFIG_PCMCIA_LOAD_CIS=y +CONFIG_PCMCIA_IOCTL=y +CONFIG_CARDBUS=y + +# +# PC-card bridges +# +CONFIG_YENTA=m +CONFIG_YENTA_O2=y +CONFIG_YENTA_RICOH=y +CONFIG_YENTA_TI=y +CONFIG_YENTA_ENE_TUNE=y +CONFIG_YENTA_TOSHIBA=y +CONFIG_PD6729=m +CONFIG_I82092=m +# CONFIG_PCMCIA_AU1X00 is not set +CONFIG_PCCARD_NONSTATIC=m +# CONFIG_HOTPLUG_PCI is not set + +# +# Executable file formats +# +CONFIG_BINFMT_ELF=y +CONFIG_BINFMT_MISC=m +CONFIG_TRAD_SIGNALS=y + +# +# Power management options +# +CONFIG_PM=y +# CONFIG_PM_LEGACY is not set +# CONFIG_PM_DEBUG is not set +CONFIG_PM_SLEEP=y +CONFIG_SUSPEND_UP_POSSIBLE=y +CONFIG_SUSPEND=y +# CONFIG_APM_EMULATION is not set + +# +# Networking +# +CONFIG_NET=y + +# +# Networking options +# +CONFIG_PACKET=m +CONFIG_PACKET_MMAP=y +CONFIG_UNIX=y +CONFIG_XFRM=y +CONFIG_XFRM_USER=m +# CONFIG_XFRM_SUB_POLICY is not set +# CONFIG_XFRM_MIGRATE is not set +CONFIG_NET_KEY=m +# CONFIG_NET_KEY_MIGRATE is not set +CONFIG_INET=y +CONFIG_IP_MULTICAST=y +CONFIG_IP_ADVANCED_ROUTER=y +CONFIG_ASK_IP_FIB_HASH=y +# CONFIG_IP_FIB_TRIE is not set +CONFIG_IP_FIB_HASH=y +CONFIG_IP_MULTIPLE_TABLES=y +CONFIG_IP_ROUTE_MULTIPATH=y +CONFIG_IP_ROUTE_VERBOSE=y +# CONFIG_IP_PNP is not set +CONFIG_NET_IPIP=m +CONFIG_NET_IPGRE=m +CONFIG_NET_IPGRE_BROADCAST=y +CONFIG_IP_MROUTE=y +CONFIG_IP_PIMSM_V1=y +CONFIG_IP_PIMSM_V2=y +# CONFIG_ARPD is not set +CONFIG_SYN_COOKIES=y +CONFIG_INET_AH=m +CONFIG_INET_ESP=m +CONFIG_INET_IPCOMP=m +CONFIG_INET_XFRM_TUNNEL=m +CONFIG_INET_TUNNEL=m +CONFIG_INET_XFRM_MODE_TRANSPORT=m +CONFIG_INET_XFRM_MODE_TUNNEL=m +CONFIG_INET_XFRM_MODE_BEET=m +CONFIG_INET_DIAG=y +CONFIG_INET_TCP_DIAG=y +# CONFIG_TCP_CONG_ADVANCED is not set +CONFIG_TCP_CONG_CUBIC=y +CONFIG_DEFAULT_TCP_CONG="cubic" +# CONFIG_TCP_MD5SIG is not set +CONFIG_IP_VS=m +# CONFIG_IP_VS_DEBUG is not set +CONFIG_IP_VS_TAB_BITS=12 + +# +# IPVS transport protocol load balancing support +# +CONFIG_IP_VS_PROTO_TCP=y +CONFIG_IP_VS_PROTO_UDP=y +CONFIG_IP_VS_PROTO_ESP=y +CONFIG_IP_VS_PROTO_AH=y + +# +# IPVS scheduler +# +CONFIG_IP_VS_RR=m +CONFIG_IP_VS_WRR=m +CONFIG_IP_VS_LC=m +CONFIG_IP_VS_WLC=m +CONFIG_IP_VS_LBLC=m +CONFIG_IP_VS_LBLCR=m +CONFIG_IP_VS_DH=m +CONFIG_IP_VS_SH=m +CONFIG_IP_VS_SED=m +CONFIG_IP_VS_NQ=m + +# +# IPVS application helper +# +CONFIG_IP_VS_FTP=m +CONFIG_IPV6=m +CONFIG_IPV6_PRIVACY=y +# CONFIG_IPV6_ROUTER_PREF is not set +# CONFIG_IPV6_OPTIMISTIC_DAD is not set +CONFIG_INET6_AH=m +CONFIG_INET6_ESP=m +CONFIG_INET6_IPCOMP=m +# CONFIG_IPV6_MIP6 is not set +CONFIG_INET6_XFRM_TUNNEL=m +CONFIG_INET6_TUNNEL=m +CONFIG_INET6_XFRM_MODE_TRANSPORT=m +CONFIG_INET6_XFRM_MODE_TUNNEL=m +CONFIG_INET6_XFRM_MODE_BEET=m +CONFIG_INET6_XFRM_MODE_ROUTEOPTIMIZATION=m +CONFIG_IPV6_SIT=m +CONFIG_IPV6_TUNNEL=m +# CONFIG_IPV6_MULTIPLE_TABLES is not set +# CONFIG_NETLABEL is not set +CONFIG_NETWORK_SECMARK=y +CONFIG_NETFILTER=y +# CONFIG_NETFILTER_DEBUG is not set +CONFIG_BRIDGE_NETFILTER=y + +# +# Core Netfilter Configuration +# +CONFIG_NETFILTER_NETLINK=m +CONFIG_NETFILTER_NETLINK_QUEUE=m +CONFIG_NETFILTER_NETLINK_LOG=m +# CONFIG_NF_CONNTRACK_ENABLED is not set +# CONFIG_NF_CONNTRACK is not set +CONFIG_NETFILTER_XTABLES=m +CONFIG_NETFILTER_XT_TARGET_CLASSIFY=m +CONFIG_NETFILTER_XT_TARGET_DSCP=m +CONFIG_NETFILTER_XT_TARGET_MARK=m +CONFIG_NETFILTER_XT_TARGET_NFQUEUE=m +# CONFIG_NETFILTER_XT_TARGET_NFLOG is not set +# CONFIG_NETFILTER_XT_TARGET_TRACE is not set +CONFIG_NETFILTER_XT_TARGET_SECMARK=m +# CONFIG_NETFILTER_XT_TARGET_TCPMSS is not set +CONFIG_NETFILTER_XT_MATCH_COMMENT=m +CONFIG_NETFILTER_XT_MATCH_DCCP=m +CONFIG_NETFILTER_XT_MATCH_DSCP=m +CONFIG_NETFILTER_XT_MATCH_ESP=m +CONFIG_NETFILTER_XT_MATCH_LENGTH=m +CONFIG_NETFILTER_XT_MATCH_LIMIT=m +CONFIG_NETFILTER_XT_MATCH_MAC=m +CONFIG_NETFILTER_XT_MATCH_MARK=m +CONFIG_NETFILTER_XT_MATCH_POLICY=m +CONFIG_NETFILTER_XT_MATCH_MULTIPORT=m +CONFIG_NETFILTER_XT_MATCH_PHYSDEV=m +CONFIG_NETFILTER_XT_MATCH_PKTTYPE=m +CONFIG_NETFILTER_XT_MATCH_QUOTA=m +CONFIG_NETFILTER_XT_MATCH_REALM=m +CONFIG_NETFILTER_XT_MATCH_SCTP=m +CONFIG_NETFILTER_XT_MATCH_STATISTIC=m +CONFIG_NETFILTER_XT_MATCH_STRING=m +CONFIG_NETFILTER_XT_MATCH_TCPMSS=m +# CONFIG_NETFILTER_XT_MATCH_U32 is not set +# CONFIG_NETFILTER_XT_MATCH_HASHLIMIT is not set + +# +# IP: Netfilter Configuration +# +CONFIG_IP_NF_QUEUE=m +CONFIG_IP_NF_IPTABLES=m +CONFIG_IP_NF_MATCH_IPRANGE=m +CONFIG_IP_NF_MATCH_TOS=m +CONFIG_IP_NF_MATCH_RECENT=m +CONFIG_IP_NF_MATCH_ECN=m +CONFIG_IP_NF_MATCH_AH=m +CONFIG_IP_NF_MATCH_TTL=m +CONFIG_IP_NF_MATCH_OWNER=m +CONFIG_IP_NF_MATCH_ADDRTYPE=m +CONFIG_IP_NF_FILTER=m +CONFIG_IP_NF_TARGET_REJECT=m +CONFIG_IP_NF_TARGET_LOG=m +CONFIG_IP_NF_TARGET_ULOG=m +CONFIG_IP_NF_MANGLE=m +CONFIG_IP_NF_TARGET_TOS=m +CONFIG_IP_NF_TARGET_ECN=m +CONFIG_IP_NF_TARGET_TTL=m +CONFIG_IP_NF_RAW=m +CONFIG_IP_NF_ARPTABLES=m +CONFIG_IP_NF_ARPFILTER=m +CONFIG_IP_NF_ARP_MANGLE=m + +# +# IPv6: Netfilter Configuration (EXPERIMENTAL) +# +CONFIG_IP6_NF_QUEUE=m +CONFIG_IP6_NF_IPTABLES=m +CONFIG_IP6_NF_MATCH_RT=m +CONFIG_IP6_NF_MATCH_OPTS=m +CONFIG_IP6_NF_MATCH_FRAG=m +CONFIG_IP6_NF_MATCH_HL=m +CONFIG_IP6_NF_MATCH_OWNER=m +CONFIG_IP6_NF_MATCH_IPV6HEADER=m +CONFIG_IP6_NF_MATCH_AH=m +# CONFIG_IP6_NF_MATCH_MH is not set +CONFIG_IP6_NF_MATCH_EUI64=m +CONFIG_IP6_NF_FILTER=m +CONFIG_IP6_NF_TARGET_LOG=m +CONFIG_IP6_NF_TARGET_REJECT=m +CONFIG_IP6_NF_MANGLE=m +CONFIG_IP6_NF_TARGET_HL=m +CONFIG_IP6_NF_RAW=m + +# +# DECnet: Netfilter Configuration +# +CONFIG_DECNET_NF_GRABULATOR=m + +# +# Bridge: Netfilter Configuration +# +CONFIG_BRIDGE_NF_EBTABLES=m +CONFIG_BRIDGE_EBT_BROUTE=m +CONFIG_BRIDGE_EBT_T_FILTER=m +CONFIG_BRIDGE_EBT_T_NAT=m +CONFIG_BRIDGE_EBT_802_3=m +CONFIG_BRIDGE_EBT_AMONG=m +CONFIG_BRIDGE_EBT_ARP=m +CONFIG_BRIDGE_EBT_IP=m +CONFIG_BRIDGE_EBT_LIMIT=m +CONFIG_BRIDGE_EBT_MARK=m +CONFIG_BRIDGE_EBT_PKTTYPE=m +CONFIG_BRIDGE_EBT_STP=m +CONFIG_BRIDGE_EBT_VLAN=m +CONFIG_BRIDGE_EBT_ARPREPLY=m +CONFIG_BRIDGE_EBT_DNAT=m +CONFIG_BRIDGE_EBT_MARK_T=m +CONFIG_BRIDGE_EBT_REDIRECT=m +CONFIG_BRIDGE_EBT_SNAT=m +CONFIG_BRIDGE_EBT_LOG=m +CONFIG_BRIDGE_EBT_ULOG=m +CONFIG_IP_DCCP=m +CONFIG_INET_DCCP_DIAG=m +CONFIG_IP_DCCP_ACKVEC=y + +# +# DCCP CCIDs Configuration (EXPERIMENTAL) +# +CONFIG_IP_DCCP_CCID2=m +# CONFIG_IP_DCCP_CCID2_DEBUG is not set +CONFIG_IP_DCCP_CCID3=m +CONFIG_IP_DCCP_TFRC_LIB=m +# CONFIG_IP_DCCP_CCID3_DEBUG is not set +CONFIG_IP_DCCP_CCID3_RTO=100 +CONFIG_IP_SCTP=m +# CONFIG_SCTP_DBG_MSG is not set +# CONFIG_SCTP_DBG_OBJCNT is not set +# CONFIG_SCTP_HMAC_NONE is not set +# CONFIG_SCTP_HMAC_SHA1 is not set +CONFIG_SCTP_HMAC_MD5=y +CONFIG_TIPC=m +# CONFIG_TIPC_ADVANCED is not set +# CONFIG_TIPC_DEBUG is not set +CONFIG_ATM=y +CONFIG_ATM_CLIP=y +# CONFIG_ATM_CLIP_NO_ICMP is not set +CONFIG_ATM_LANE=m +CONFIG_ATM_MPOA=m +CONFIG_ATM_BR2684=m +# CONFIG_ATM_BR2684_IPFILTER is not set +CONFIG_BRIDGE=m +CONFIG_VLAN_8021Q=m +CONFIG_DECNET=m +# CONFIG_DECNET_ROUTER is not set +CONFIG_LLC=y +CONFIG_LLC2=m +CONFIG_IPX=m +# CONFIG_IPX_INTERN is not set +CONFIG_ATALK=m +CONFIG_DEV_APPLETALK=m +CONFIG_IPDDP=m +CONFIG_IPDDP_ENCAP=y +CONFIG_IPDDP_DECAP=y +CONFIG_X25=m +CONFIG_LAPB=m +CONFIG_ECONET=m +CONFIG_ECONET_AUNUDP=y +CONFIG_ECONET_NATIVE=y +CONFIG_WAN_ROUTER=m + +# +# QoS and/or fair queueing +# +CONFIG_NET_SCHED=y +CONFIG_NET_SCH_FIFO=y + +# +# Queueing/Scheduling +# +CONFIG_NET_SCH_CBQ=m +CONFIG_NET_SCH_HTB=m +CONFIG_NET_SCH_HFSC=m +CONFIG_NET_SCH_ATM=m +CONFIG_NET_SCH_PRIO=m +# CONFIG_NET_SCH_RR is not set +CONFIG_NET_SCH_RED=m +CONFIG_NET_SCH_SFQ=m +CONFIG_NET_SCH_TEQL=m +CONFIG_NET_SCH_TBF=m +CONFIG_NET_SCH_GRED=m +CONFIG_NET_SCH_DSMARK=m +CONFIG_NET_SCH_NETEM=m +CONFIG_NET_SCH_INGRESS=m + +# +# Classification +# +CONFIG_NET_CLS=y +CONFIG_NET_CLS_BASIC=m +CONFIG_NET_CLS_TCINDEX=m +CONFIG_NET_CLS_ROUTE4=m +CONFIG_NET_CLS_ROUTE=y +CONFIG_NET_CLS_FW=m +CONFIG_NET_CLS_U32=m +# CONFIG_CLS_U32_PERF is not set +CONFIG_CLS_U32_MARK=y +CONFIG_NET_CLS_RSVP=m +CONFIG_NET_CLS_RSVP6=m +CONFIG_NET_EMATCH=y +CONFIG_NET_EMATCH_STACK=32 +CONFIG_NET_EMATCH_CMP=m +CONFIG_NET_EMATCH_NBYTE=m +CONFIG_NET_EMATCH_U32=m +CONFIG_NET_EMATCH_META=m +CONFIG_NET_EMATCH_TEXT=m +CONFIG_NET_CLS_ACT=y +CONFIG_NET_ACT_POLICE=y +# CONFIG_NET_ACT_GACT is not set +# CONFIG_NET_ACT_MIRRED is not set +# CONFIG_NET_ACT_IPT is not set +# CONFIG_NET_ACT_PEDIT is not set +# CONFIG_NET_ACT_SIMP is not set +CONFIG_NET_CLS_POLICE=y +# CONFIG_NET_CLS_IND is not set + +# +# Network testing +# +CONFIG_NET_PKTGEN=m +CONFIG_HAMRADIO=y + +# +# Packet Radio protocols +# +CONFIG_AX25=m +# CONFIG_AX25_DAMA_SLAVE is not set +CONFIG_NETROM=m +CONFIG_ROSE=m + +# +# AX.25 network device drivers +# +CONFIG_MKISS=m +CONFIG_6PACK=m +CONFIG_BPQETHER=m +CONFIG_BAYCOM_SER_FDX=m +CONFIG_BAYCOM_SER_HDX=m +CONFIG_BAYCOM_PAR=m +CONFIG_BAYCOM_EPP=m +CONFIG_YAM=m +CONFIG_IRDA=m + +# +# IrDA protocols +# +CONFIG_IRLAN=m +CONFIG_IRNET=m +CONFIG_IRCOMM=m +CONFIG_IRDA_ULTRA=y + +# +# IrDA options +# +CONFIG_IRDA_CACHE_LAST_LSAP=y +CONFIG_IRDA_FAST_RR=y +CONFIG_IRDA_DEBUG=y + +# +# Infrared-port device drivers +# + +# +# SIR device drivers +# +CONFIG_IRTTY_SIR=m + +# +# Dongle support +# +CONFIG_DONGLE=y +CONFIG_ESI_DONGLE=m +CONFIG_ACTISYS_DONGLE=m +CONFIG_TEKRAM_DONGLE=m +# CONFIG_TOIM3232_DONGLE is not set +CONFIG_LITELINK_DONGLE=m +CONFIG_MA600_DONGLE=m +CONFIG_GIRBIL_DONGLE=m +CONFIG_MCP2120_DONGLE=m +CONFIG_OLD_BELKIN_DONGLE=m +CONFIG_ACT200L_DONGLE=m +# CONFIG_KINGSUN_DONGLE is not set + +# +# Old SIR device drivers +# +# CONFIG_IRPORT_SIR is not set + +# +# Old Serial dongle support +# + +# +# FIR device drivers +# +CONFIG_USB_IRDA=m +CONFIG_SIGMATEL_FIR=m +CONFIG_TOSHIBA_FIR=m +CONFIG_VLSI_FIR=m +CONFIG_MCS_FIR=m +CONFIG_BT=m +CONFIG_BT_L2CAP=m +CONFIG_BT_SCO=m +CONFIG_BT_RFCOMM=m +CONFIG_BT_RFCOMM_TTY=y +CONFIG_BT_BNEP=m +CONFIG_BT_BNEP_MC_FILTER=y +CONFIG_BT_BNEP_PROTO_FILTER=y +CONFIG_BT_CMTP=m +CONFIG_BT_HIDP=m + +# +# Bluetooth device drivers +# +CONFIG_BT_HCIUSB=m +CONFIG_BT_HCIUSB_SCO=y +CONFIG_BT_HCIUART=m +CONFIG_BT_HCIUART_H4=y +CONFIG_BT_HCIUART_BCSP=y +CONFIG_BT_HCIBCM203X=m +CONFIG_BT_HCIBPA10X=m +CONFIG_BT_HCIBFUSB=m +CONFIG_BT_HCIDTL1=m +CONFIG_BT_HCIBT3C=m +CONFIG_BT_HCIBLUECARD=m +CONFIG_BT_HCIBTUART=m +CONFIG_BT_HCIVHCI=m +CONFIG_AF_RXRPC=m +# CONFIG_AF_RXRPC_DEBUG is not set +# CONFIG_RXKAD is not set +CONFIG_FIB_RULES=y + +# +# Wireless +# +# CONFIG_CFG80211 is not set +CONFIG_WIRELESS_EXT=y +# CONFIG_MAC80211 is not set +CONFIG_IEEE80211=m +# CONFIG_IEEE80211_DEBUG is not set +CONFIG_IEEE80211_CRYPT_WEP=m +CONFIG_IEEE80211_CRYPT_CCMP=m +CONFIG_IEEE80211_CRYPT_TKIP=m +CONFIG_IEEE80211_SOFTMAC=m +# CONFIG_IEEE80211_SOFTMAC_DEBUG is not set +# CONFIG_RFKILL is not set +# CONFIG_NET_9P is not set + +# +# Device Drivers +# + +# +# Generic Driver Options +# +CONFIG_STANDALONE=y +CONFIG_PREVENT_FIRMWARE_BUILD=y +CONFIG_FW_LOADER=y +# CONFIG_SYS_HYPERVISOR is not set +CONFIG_CONNECTOR=m +CONFIG_MTD=m +# CONFIG_MTD_DEBUG is not set +CONFIG_MTD_CONCAT=m +CONFIG_MTD_PARTITIONS=y +CONFIG_MTD_REDBOOT_PARTS=m +CONFIG_MTD_REDBOOT_DIRECTORY_BLOCK=-1 +# CONFIG_MTD_REDBOOT_PARTS_UNALLOCATED is not set +# CONFIG_MTD_REDBOOT_PARTS_READONLY is not set + +# +# User Modules And Translation Layers +# +CONFIG_MTD_CHAR=m +CONFIG_MTD_BLKDEVS=m +CONFIG_MTD_BLOCK=m +CONFIG_MTD_BLOCK_RO=m +CONFIG_FTL=m +CONFIG_NFTL=m +CONFIG_NFTL_RW=y +CONFIG_INFTL=m +CONFIG_RFD_FTL=m +CONFIG_SSFDC=m + +# +# RAM/ROM/Flash chip drivers +# +CONFIG_MTD_CFI=m +CONFIG_MTD_JEDECPROBE=m +CONFIG_MTD_GEN_PROBE=m +# CONFIG_MTD_CFI_ADV_OPTIONS is not set +CONFIG_MTD_MAP_BANK_WIDTH_1=y +CONFIG_MTD_MAP_BANK_WIDTH_2=y +CONFIG_MTD_MAP_BANK_WIDTH_4=y +# CONFIG_MTD_MAP_BANK_WIDTH_8 is not set +# CONFIG_MTD_MAP_BANK_WIDTH_16 is not set +# CONFIG_MTD_MAP_BANK_WIDTH_32 is not set +CONFIG_MTD_CFI_I1=y +CONFIG_MTD_CFI_I2=y +# CONFIG_MTD_CFI_I4 is not set +# CONFIG_MTD_CFI_I8 is not set +CONFIG_MTD_CFI_INTELEXT=m +CONFIG_MTD_CFI_AMDSTD=m +CONFIG_MTD_CFI_STAA=m +CONFIG_MTD_CFI_UTIL=m +CONFIG_MTD_RAM=m +CONFIG_MTD_ROM=m +CONFIG_MTD_ABSENT=m + +# +# Mapping drivers for chip access +# +CONFIG_MTD_COMPLEX_MAPPINGS=y +CONFIG_MTD_PHYSMAP=m +CONFIG_MTD_PHYSMAP_START=0x8000000 +CONFIG_MTD_PHYSMAP_LEN=0x4000000 +CONFIG_MTD_PHYSMAP_BANKWIDTH=2 +# CONFIG_MTD_ALCHEMY is not set +# CONFIG_MTD_MTX1 is not set +CONFIG_MTD_PCI=m +CONFIG_MTD_PLATRAM=m + +# +# Self-contained MTD device drivers +# +CONFIG_MTD_PMC551=m +# CONFIG_MTD_PMC551_BUGFIX is not set +# CONFIG_MTD_PMC551_DEBUG is not set +CONFIG_MTD_DATAFLASH=m +CONFIG_MTD_M25P80=m +CONFIG_MTD_SLRAM=m +CONFIG_MTD_PHRAM=m +CONFIG_MTD_MTDRAM=m +CONFIG_MTDRAM_TOTAL_SIZE=4096 +CONFIG_MTDRAM_ERASE_SIZE=128 +CONFIG_MTD_BLOCK2MTD=m + +# +# Disk-On-Chip Device Drivers +# +CONFIG_MTD_DOC2000=m +CONFIG_MTD_DOC2001=m +CONFIG_MTD_DOC2001PLUS=m +CONFIG_MTD_DOCPROBE=m +CONFIG_MTD_DOCECC=m +# CONFIG_MTD_DOCPROBE_ADVANCED is not set +CONFIG_MTD_DOCPROBE_ADDRESS=0 +CONFIG_MTD_NAND=m +# CONFIG_MTD_NAND_VERIFY_WRITE is not set +# CONFIG_MTD_NAND_ECC_SMC is not set +# CONFIG_MTD_NAND_MUSEUM_IDS is not set +CONFIG_MTD_NAND_IDS=m +CONFIG_MTD_NAND_DISKONCHIP=m +# CONFIG_MTD_NAND_DISKONCHIP_PROBE_ADVANCED is not set +CONFIG_MTD_NAND_DISKONCHIP_PROBE_ADDRESS=0 +# CONFIG_MTD_NAND_DISKONCHIP_BBTWRITE is not set +# CONFIG_MTD_NAND_CAFE is not set +CONFIG_MTD_NAND_NANDSIM=m +# CONFIG_MTD_NAND_PLATFORM is not set +CONFIG_MTD_ONENAND=m +CONFIG_MTD_ONENAND_VERIFY_WRITE=y +# CONFIG_MTD_ONENAND_OTP is not set + +# +# UBI - Unsorted block images +# +# CONFIG_MTD_UBI is not set +CONFIG_PARPORT=m +CONFIG_PARPORT_PC=m +CONFIG_PARPORT_SERIAL=m +CONFIG_PARPORT_PC_FIFO=y +CONFIG_PARPORT_PC_SUPERIO=y +CONFIG_PARPORT_PC_PCMCIA=m +# CONFIG_PARPORT_GSC is not set +CONFIG_PARPORT_AX88796=m +CONFIG_PARPORT_1284=y +CONFIG_PARPORT_NOT_PC=y +CONFIG_BLK_DEV=y +CONFIG_PARIDE=m + +# +# Parallel IDE high-level drivers +# +CONFIG_PARIDE_PD=m +CONFIG_PARIDE_PCD=m +CONFIG_PARIDE_PF=m +CONFIG_PARIDE_PT=m +CONFIG_PARIDE_PG=m + +# +# Parallel IDE protocol modules +# +CONFIG_PARIDE_ATEN=m +CONFIG_PARIDE_BPCK=m +CONFIG_PARIDE_BPCK6=m +CONFIG_PARIDE_COMM=m +CONFIG_PARIDE_DSTR=m +CONFIG_PARIDE_FIT2=m +CONFIG_PARIDE_FIT3=m +CONFIG_PARIDE_EPAT=m +CONFIG_PARIDE_EPATC8=y +CONFIG_PARIDE_EPIA=m +CONFIG_PARIDE_FRIQ=m +CONFIG_PARIDE_FRPW=m +CONFIG_PARIDE_KBIC=m +CONFIG_PARIDE_KTTI=m +CONFIG_PARIDE_ON20=m +CONFIG_PARIDE_ON26=m +CONFIG_BLK_CPQ_DA=m +CONFIG_BLK_CPQ_CISS_DA=m +CONFIG_CISS_SCSI_TAPE=y +CONFIG_BLK_DEV_DAC960=m +CONFIG_BLK_DEV_UMEM=m +# CONFIG_BLK_DEV_COW_COMMON is not set +CONFIG_BLK_DEV_LOOP=m +CONFIG_BLK_DEV_CRYPTOLOOP=m +CONFIG_BLK_DEV_NBD=m +CONFIG_BLK_DEV_SX8=m +# CONFIG_BLK_DEV_UB is not set +CONFIG_BLK_DEV_RAM=y +CONFIG_BLK_DEV_RAM_COUNT=16 +CONFIG_BLK_DEV_RAM_SIZE=65536 +CONFIG_BLK_DEV_RAM_BLOCKSIZE=1024 +CONFIG_CDROM_PKTCDVD=m +CONFIG_CDROM_PKTCDVD_BUFFERS=8 +# CONFIG_CDROM_PKTCDVD_WCACHE is not set +CONFIG_ATA_OVER_ETH=m +CONFIG_MISC_DEVICES=y +# CONFIG_PHANTOM is not set +# CONFIG_EEPROM_93CX6 is not set +CONFIG_SGI_IOC4=m +CONFIG_TIFM_CORE=m +CONFIG_TIFM_7XX1=m +CONFIG_IDE=y +CONFIG_IDE_MAX_HWIFS=4 +CONFIG_BLK_DEV_IDE=y + +# +# Please see Documentation/ide.txt for help/info on IDE drives +# +# CONFIG_BLK_DEV_IDE_SATA is not set +CONFIG_BLK_DEV_IDEDISK=m +# CONFIG_IDEDISK_MULTI_MODE is not set +CONFIG_BLK_DEV_IDECS=m +# CONFIG_BLK_DEV_DELKIN is not set +CONFIG_BLK_DEV_IDECD=m +CONFIG_BLK_DEV_IDETAPE=m +CONFIG_BLK_DEV_IDEFLOPPY=m +CONFIG_BLK_DEV_IDESCSI=m +# CONFIG_IDE_TASK_IOCTL is not set +CONFIG_IDE_PROC_FS=y + +# +# IDE chipset support/bugfixes +# +CONFIG_IDE_GENERIC=m +CONFIG_BLK_DEV_IDEPCI=y +CONFIG_IDEPCI_SHARE_IRQ=y +CONFIG_IDEPCI_PCIBUS_ORDER=y +# CONFIG_BLK_DEV_OFFBOARD is not set +CONFIG_BLK_DEV_GENERIC=m +CONFIG_BLK_DEV_OPTI621=m +CONFIG_BLK_DEV_IDEDMA_PCI=y +# CONFIG_BLK_DEV_IDEDMA_FORCED is not set +# CONFIG_IDEDMA_ONLYDISK is not set +CONFIG_BLK_DEV_AEC62XX=m +CONFIG_BLK_DEV_ALI15X3=m +# CONFIG_WDC_ALI15X3 is not set +CONFIG_BLK_DEV_AMD74XX=m +CONFIG_BLK_DEV_CMD64X=m +CONFIG_BLK_DEV_TRIFLEX=m +CONFIG_BLK_DEV_CY82C693=m +# CONFIG_BLK_DEV_CS5520 is not set +CONFIG_BLK_DEV_CS5530=m +CONFIG_BLK_DEV_HPT34X=m +# CONFIG_HPT34X_AUTODMA is not set +CONFIG_BLK_DEV_HPT366=m +# CONFIG_BLK_DEV_JMICRON is not set +CONFIG_BLK_DEV_SC1200=m +CONFIG_BLK_DEV_PIIX=m +# CONFIG_BLK_DEV_IT8213 is not set +CONFIG_BLK_DEV_IT821X=m +CONFIG_BLK_DEV_NS87415=m +CONFIG_BLK_DEV_PDC202XX_OLD=m +CONFIG_PDC202XX_BURST=y +CONFIG_BLK_DEV_PDC202XX_NEW=m +CONFIG_BLK_DEV_SVWKS=m +CONFIG_BLK_DEV_SIIMAGE=m +# CONFIG_BLK_DEV_SLC90E66 is not set +CONFIG_BLK_DEV_TRM290=m +# CONFIG_BLK_DEV_VIA82CXXX is not set +# CONFIG_BLK_DEV_TC86C001 is not set +# CONFIG_IDE_ARM is not set +CONFIG_BLK_DEV_IDEDMA=y +# CONFIG_IDEDMA_IVB is not set +# CONFIG_BLK_DEV_HD is not set + +# +# SCSI device support +# +CONFIG_RAID_ATTRS=m +CONFIG_SCSI=m +CONFIG_SCSI_DMA=y +# CONFIG_SCSI_TGT is not set +CONFIG_SCSI_NETLINK=y +CONFIG_SCSI_PROC_FS=y + +# +# SCSI support type (disk, tape, CD-ROM) +# +CONFIG_BLK_DEV_SD=m +CONFIG_CHR_DEV_ST=m +CONFIG_CHR_DEV_OSST=m +CONFIG_BLK_DEV_SR=m +# CONFIG_BLK_DEV_SR_VENDOR is not set +CONFIG_CHR_DEV_SG=m +CONFIG_CHR_DEV_SCH=m + +# +# Some SCSI devices (e.g. CD jukebox) support multiple LUNs +# +CONFIG_SCSI_MULTI_LUN=y +CONFIG_SCSI_CONSTANTS=y +CONFIG_SCSI_LOGGING=y +# CONFIG_SCSI_SCAN_ASYNC is not set +CONFIG_SCSI_WAIT_SCAN=m + +# +# SCSI Transports +# +CONFIG_SCSI_SPI_ATTRS=m +CONFIG_SCSI_FC_ATTRS=m +CONFIG_SCSI_ISCSI_ATTRS=m +CONFIG_SCSI_SAS_ATTRS=m +CONFIG_SCSI_SAS_LIBSAS=m +# CONFIG_SCSI_SAS_ATA is not set +# CONFIG_SCSI_SAS_LIBSAS_DEBUG is not set +CONFIG_SCSI_LOWLEVEL=y +CONFIG_ISCSI_TCP=m +CONFIG_BLK_DEV_3W_XXXX_RAID=m +CONFIG_SCSI_3W_9XXX=m +CONFIG_SCSI_ACARD=m +CONFIG_SCSI_AACRAID=m +CONFIG_SCSI_AIC7XXX=m +CONFIG_AIC7XXX_CMDS_PER_DEVICE=8 +CONFIG_AIC7XXX_RESET_DELAY_MS=15000 +CONFIG_AIC7XXX_DEBUG_ENABLE=y +CONFIG_AIC7XXX_DEBUG_MASK=0 +CONFIG_AIC7XXX_REG_PRETTY_PRINT=y +# CONFIG_SCSI_AIC7XXX_OLD is not set +CONFIG_SCSI_AIC79XX=m +CONFIG_AIC79XX_CMDS_PER_DEVICE=32 +CONFIG_AIC79XX_RESET_DELAY_MS=15000 +CONFIG_AIC79XX_DEBUG_ENABLE=y +CONFIG_AIC79XX_DEBUG_MASK=0 +CONFIG_AIC79XX_REG_PRETTY_PRINT=y +CONFIG_SCSI_AIC94XX=m +# CONFIG_AIC94XX_DEBUG is not set +CONFIG_SCSI_DPT_I2O=m +CONFIG_SCSI_ARCMSR=m +CONFIG_MEGARAID_NEWGEN=y +CONFIG_MEGARAID_MM=m +CONFIG_MEGARAID_MAILBOX=m +CONFIG_MEGARAID_LEGACY=m +CONFIG_MEGARAID_SAS=m +CONFIG_SCSI_HPTIOP=m +CONFIG_SCSI_DMX3191D=m +CONFIG_SCSI_FUTURE_DOMAIN=m +CONFIG_SCSI_IPS=m +CONFIG_SCSI_INITIO=m +# CONFIG_SCSI_INIA100 is not set +CONFIG_SCSI_PPA=m +CONFIG_SCSI_IMM=m +# CONFIG_SCSI_IZIP_EPP16 is not set +# CONFIG_SCSI_IZIP_SLOW_CTR is not set +CONFIG_SCSI_STEX=m +CONFIG_SCSI_SYM53C8XX_2=m +CONFIG_SCSI_SYM53C8XX_DMA_ADDRESSING_MODE=1 +CONFIG_SCSI_SYM53C8XX_DEFAULT_TAGS=16 +CONFIG_SCSI_SYM53C8XX_MAX_TAGS=64 +CONFIG_SCSI_SYM53C8XX_MMIO=y +CONFIG_SCSI_IPR=m +# CONFIG_SCSI_IPR_TRACE is not set +# CONFIG_SCSI_IPR_DUMP is not set +CONFIG_SCSI_QLOGIC_1280=m +CONFIG_SCSI_QLA_FC=m +CONFIG_SCSI_QLA_ISCSI=m +CONFIG_SCSI_LPFC=m +CONFIG_SCSI_DC395x=m +CONFIG_SCSI_DC390T=m +CONFIG_SCSI_NSP32=m +CONFIG_SCSI_DEBUG=m +# CONFIG_SCSI_SRP is not set +# CONFIG_SCSI_LOWLEVEL_PCMCIA is not set +CONFIG_ATA=m +# CONFIG_ATA_NONSTANDARD is not set +CONFIG_SATA_AHCI=m +CONFIG_SATA_SVW=m +CONFIG_ATA_PIIX=m +CONFIG_SATA_MV=m +CONFIG_SATA_NV=m +CONFIG_PDC_ADMA=m +CONFIG_SATA_QSTOR=m +CONFIG_SATA_PROMISE=m +CONFIG_SATA_SX4=m +CONFIG_SATA_SIL=m +CONFIG_SATA_SIL24=m +CONFIG_SATA_SIS=m +CONFIG_SATA_ULI=m +CONFIG_SATA_VIA=m +CONFIG_SATA_VITESSE=m +# CONFIG_SATA_INIC162X is not set +# CONFIG_PATA_ALI is not set +# CONFIG_PATA_AMD is not set +# CONFIG_PATA_ARTOP is not set +# CONFIG_PATA_ATIIXP is not set +# CONFIG_PATA_CMD640_PCI is not set +# CONFIG_PATA_CMD64X is not set +CONFIG_PATA_CS5520=m +# CONFIG_PATA_CS5530 is not set +# CONFIG_PATA_CYPRESS is not set +CONFIG_PATA_EFAR=m +CONFIG_ATA_GENERIC=m +# CONFIG_PATA_HPT366 is not set +# CONFIG_PATA_HPT37X is not set +# CONFIG_PATA_HPT3X2N is not set +# CONFIG_PATA_HPT3X3 is not set +# CONFIG_PATA_IT821X is not set +# CONFIG_PATA_IT8213 is not set +CONFIG_PATA_JMICRON=m +CONFIG_PATA_TRIFLEX=m +# CONFIG_PATA_MARVELL is not set +CONFIG_PATA_MPIIX=m +# CONFIG_PATA_OLDPIIX is not set +CONFIG_PATA_NETCELL=m +# CONFIG_PATA_NS87410 is not set +# CONFIG_PATA_OPTI is not set +# CONFIG_PATA_OPTIDMA is not set +CONFIG_PATA_PCMCIA=m +# CONFIG_PATA_PDC_OLD is not set +# CONFIG_PATA_RADISYS is not set +CONFIG_PATA_RZ1000=m +# CONFIG_PATA_SC1200 is not set +# CONFIG_PATA_SERVERWORKS is not set +CONFIG_PATA_PDC2027X=m +CONFIG_PATA_SIL680=m +CONFIG_PATA_SIS=m +CONFIG_PATA_VIA=m +CONFIG_PATA_WINBOND=m +# CONFIG_PATA_PLATFORM is not set +CONFIG_MD=y +CONFIG_BLK_DEV_MD=m +CONFIG_MD_LINEAR=m +CONFIG_MD_RAID0=m +CONFIG_MD_RAID1=m +CONFIG_MD_RAID10=m +CONFIG_MD_RAID456=m +# CONFIG_MD_RAID5_RESHAPE is not set +CONFIG_MD_MULTIPATH=m +CONFIG_MD_FAULTY=m +CONFIG_BLK_DEV_DM=m +# CONFIG_DM_DEBUG is not set +CONFIG_DM_CRYPT=m +CONFIG_DM_SNAPSHOT=m +CONFIG_DM_MIRROR=m +CONFIG_DM_ZERO=m +CONFIG_DM_MULTIPATH=m +CONFIG_DM_MULTIPATH_EMC=m +# CONFIG_DM_MULTIPATH_RDAC is not set +# CONFIG_DM_DELAY is not set + +# +# Fusion MPT device support +# +CONFIG_FUSION=y +CONFIG_FUSION_SPI=m +CONFIG_FUSION_FC=m +CONFIG_FUSION_SAS=m +CONFIG_FUSION_MAX_SGE=128 +CONFIG_FUSION_CTL=m +CONFIG_FUSION_LAN=m +# CONFIG_FUSION_LOGGING is not set + +# +# IEEE 1394 (FireWire) support +# +# CONFIG_FIREWIRE is not set +CONFIG_IEEE1394=m + +# +# Subsystem Options +# +# CONFIG_IEEE1394_VERBOSEDEBUG is not set + +# +# Controllers +# +CONFIG_IEEE1394_PCILYNX=m +CONFIG_IEEE1394_OHCI1394=m + +# +# Protocols +# +CONFIG_IEEE1394_VIDEO1394=m +CONFIG_IEEE1394_SBP2=m +# CONFIG_IEEE1394_SBP2_PHYS_DMA is not set +CONFIG_IEEE1394_ETH1394_ROM_ENTRY=y +CONFIG_IEEE1394_ETH1394=m +CONFIG_IEEE1394_DV1394=m +CONFIG_IEEE1394_RAWIO=m +CONFIG_I2O=m +CONFIG_I2O_LCT_NOTIFY_ON_CHANGES=y +CONFIG_I2O_EXT_ADAPTEC=y +CONFIG_I2O_CONFIG=m +CONFIG_I2O_CONFIG_OLD_IOCTL=y +CONFIG_I2O_BUS=m +CONFIG_I2O_BLOCK=m +CONFIG_I2O_SCSI=m +CONFIG_I2O_PROC=m +CONFIG_NETDEVICES=y +# CONFIG_NETDEVICES_MULTIQUEUE is not set +# CONFIG_IFB is not set +CONFIG_DUMMY=m +CONFIG_BONDING=m +# CONFIG_MACVLAN is not set +CONFIG_EQUALIZER=m +CONFIG_TUN=m +CONFIG_ARCNET=m +CONFIG_ARCNET_1201=m +CONFIG_ARCNET_1051=m +CONFIG_ARCNET_RAW=m +CONFIG_ARCNET_CAP=m +CONFIG_ARCNET_COM90xx=m +CONFIG_ARCNET_COM90xxIO=m +CONFIG_ARCNET_RIM_I=m +CONFIG_ARCNET_COM20020=m +CONFIG_ARCNET_COM20020_PCI=m +CONFIG_PHYLIB=m + +# +# MII PHY device drivers +# +CONFIG_MARVELL_PHY=m +CONFIG_DAVICOM_PHY=m +CONFIG_QSEMI_PHY=m +CONFIG_LXT_PHY=m +CONFIG_CICADA_PHY=m +CONFIG_VITESSE_PHY=m +CONFIG_SMSC_PHY=m +# CONFIG_BROADCOM_PHY is not set +# CONFIG_ICPLUS_PHY is not set +CONFIG_FIXED_PHY=m +# CONFIG_FIXED_MII_10_FDX is not set +# CONFIG_FIXED_MII_100_FDX is not set +CONFIG_NET_ETHERNET=y +CONFIG_MII=m +# CONFIG_AX88796 is not set +# CONFIG_MIPS_AU1X00_ENET is not set +CONFIG_HAPPYMEAL=m +CONFIG_SUNGEM=m +CONFIG_CASSINI=m +CONFIG_NET_VENDOR_3COM=y +CONFIG_VORTEX=m +CONFIG_TYPHOON=m +# CONFIG_SMC91X is not set +# CONFIG_DM9000 is not set +CONFIG_NET_TULIP=y +CONFIG_DE2104X=m +CONFIG_TULIP=m +# CONFIG_TULIP_MWI is not set +# CONFIG_TULIP_MMIO is not set +# CONFIG_TULIP_NAPI is not set +CONFIG_DE4X5=m +CONFIG_WINBOND_840=m +CONFIG_DM9102=m +CONFIG_ULI526X=m +CONFIG_PCMCIA_XIRCOM=m +# CONFIG_PCMCIA_XIRTULIP is not set +CONFIG_HP100=m +CONFIG_NET_PCI=y +CONFIG_PCNET32=m +# CONFIG_PCNET32_NAPI is not set +CONFIG_AMD8111_ETH=m +# CONFIG_AMD8111E_NAPI is not set +CONFIG_ADAPTEC_STARFIRE=m +# CONFIG_ADAPTEC_STARFIRE_NAPI is not set +CONFIG_B44=m +CONFIG_FORCEDETH=m +# CONFIG_FORCEDETH_NAPI is not set +# CONFIG_TC35815 is not set +CONFIG_DGRS=m +CONFIG_EEPRO100=m +CONFIG_E100=m +CONFIG_FEALNX=m +CONFIG_NATSEMI=m +CONFIG_NE2K_PCI=m +CONFIG_8139CP=m +CONFIG_8139TOO=m +# CONFIG_8139TOO_PIO is not set +# CONFIG_8139TOO_TUNE_TWISTER is not set +CONFIG_8139TOO_8129=y +# CONFIG_8139_OLD_RX_RESET is not set +CONFIG_SIS900=m +CONFIG_EPIC100=m +CONFIG_SUNDANCE=m +# CONFIG_SUNDANCE_MMIO is not set +CONFIG_TLAN=m +CONFIG_VIA_RHINE=m +# CONFIG_VIA_RHINE_MMIO is not set +# CONFIG_VIA_RHINE_NAPI is not set +# CONFIG_SC92031 is not set +CONFIG_NET_POCKET=y +CONFIG_DE600=m +CONFIG_DE620=m +CONFIG_NETDEV_1000=y +CONFIG_ACENIC=m +# CONFIG_ACENIC_OMIT_TIGON_I is not set +CONFIG_DL2K=m +CONFIG_E1000=m +# CONFIG_E1000_NAPI is not set +# CONFIG_E1000_DISABLE_PACKET_SPLIT is not set +CONFIG_NS83820=m +CONFIG_HAMACHI=m +CONFIG_YELLOWFIN=m +CONFIG_R8169=m +# CONFIG_R8169_NAPI is not set +CONFIG_R8169_VLAN=y +CONFIG_SIS190=m +CONFIG_SKGE=m +CONFIG_SKY2=m +CONFIG_SK98LIN=m +CONFIG_VIA_VELOCITY=m +CONFIG_TIGON3=m +CONFIG_BNX2=m +CONFIG_QLA3XXX=m +# CONFIG_ATL1 is not set +CONFIG_NETDEV_10000=y +CONFIG_CHELSIO_T1=m +# CONFIG_CHELSIO_T1_1G is not set +CONFIG_CHELSIO_T1_NAPI=y +# CONFIG_CHELSIO_T3 is not set +CONFIG_IXGB=m +# CONFIG_IXGB_NAPI is not set +CONFIG_S2IO=m +# CONFIG_S2IO_NAPI is not set +CONFIG_MYRI10GE=m +# CONFIG_NETXEN_NIC is not set +# CONFIG_MLX4_CORE is not set +CONFIG_TR=y +CONFIG_IBMOL=m +CONFIG_IBMLS=m +CONFIG_3C359=m +CONFIG_TMS380TR=m +CONFIG_TMSPCI=m +CONFIG_ABYSS=m + +# +# Wireless LAN +# +# CONFIG_WLAN_PRE80211 is not set +# CONFIG_WLAN_80211 is not set + +# +# USB Network Adapters +# +CONFIG_USB_CATC=m +CONFIG_USB_KAWETH=m +CONFIG_USB_PEGASUS=m +CONFIG_USB_RTL8150=m +CONFIG_USB_USBNET_MII=m +CONFIG_USB_USBNET=m +CONFIG_USB_NET_AX8817X=m +CONFIG_USB_NET_CDCETHER=m +# CONFIG_USB_NET_DM9601 is not set +CONFIG_USB_NET_GL620A=m +CONFIG_USB_NET_NET1080=m +CONFIG_USB_NET_PLUSB=m +CONFIG_USB_NET_MCS7830=m +CONFIG_USB_NET_RNDIS_HOST=m +CONFIG_USB_NET_CDC_SUBSET=m +CONFIG_USB_ALI_M5632=y +CONFIG_USB_AN2720=y +CONFIG_USB_BELKIN=y +CONFIG_USB_ARMLINUX=y +CONFIG_USB_EPSON2888=y +# CONFIG_USB_KC2190 is not set +CONFIG_USB_NET_ZAURUS=m +CONFIG_NET_PCMCIA=y +CONFIG_PCMCIA_3C589=m +CONFIG_PCMCIA_3C574=m +CONFIG_PCMCIA_FMVJ18X=m +CONFIG_PCMCIA_PCNET=m +CONFIG_PCMCIA_NMCLAN=m +CONFIG_PCMCIA_SMC91C92=m +CONFIG_PCMCIA_XIRC2PS=m +CONFIG_PCMCIA_AXNET=m +CONFIG_ARCNET_COM20020_CS=m +CONFIG_PCMCIA_IBMTR=m +CONFIG_WAN=y +CONFIG_LANMEDIA=m +CONFIG_HDLC=m +CONFIG_HDLC_RAW=m +CONFIG_HDLC_RAW_ETH=m +CONFIG_HDLC_CISCO=m +CONFIG_HDLC_FR=m +CONFIG_HDLC_PPP=m +CONFIG_HDLC_X25=m +CONFIG_PCI200SYN=m +CONFIG_WANXL=m +CONFIG_PC300=m +CONFIG_PC300_MLPPP=y + +# +# Cyclades-PC300 MLPPP support is disabled. +# + +# +# Refer to the file README.mlppp, provided by PC300 package. +# +# CONFIG_PC300TOO is not set +CONFIG_FARSYNC=m +CONFIG_DSCC4=m +CONFIG_DSCC4_PCISYNC=y +CONFIG_DSCC4_PCI_RST=y +CONFIG_DLCI=m +CONFIG_DLCI_MAX=8 +CONFIG_WAN_ROUTER_DRIVERS=m +CONFIG_CYCLADES_SYNC=m +CONFIG_CYCLOMX_X25=y +CONFIG_LAPBETHER=m +CONFIG_X25_ASY=m +CONFIG_ATM_DRIVERS=y +# CONFIG_ATM_DUMMY is not set +CONFIG_ATM_TCP=m +CONFIG_ATM_LANAI=m +CONFIG_ATM_ENI=m +# CONFIG_ATM_ENI_DEBUG is not set +# CONFIG_ATM_ENI_TUNE_BURST is not set +CONFIG_ATM_FIRESTREAM=m +CONFIG_ATM_ZATM=m +# CONFIG_ATM_ZATM_DEBUG is not set +CONFIG_ATM_NICSTAR=m +# CONFIG_ATM_NICSTAR_USE_SUNI is not set +# CONFIG_ATM_NICSTAR_USE_IDT77105 is not set +CONFIG_ATM_IDT77252=m +# CONFIG_ATM_IDT77252_DEBUG is not set +# CONFIG_ATM_IDT77252_RCV_ALL is not set +CONFIG_ATM_IDT77252_USE_SUNI=y +CONFIG_ATM_AMBASSADOR=m +# CONFIG_ATM_AMBASSADOR_DEBUG is not set +CONFIG_ATM_HORIZON=m +# CONFIG_ATM_HORIZON_DEBUG is not set +CONFIG_ATM_IA=m +# CONFIG_ATM_IA_DEBUG is not set +CONFIG_ATM_FORE200E_MAYBE=m +CONFIG_ATM_FORE200E_PCA=y +CONFIG_ATM_FORE200E_PCA_DEFAULT_FW=y +# CONFIG_ATM_FORE200E_USE_TASKLET is not set +CONFIG_ATM_FORE200E_TX_RETRY=16 +CONFIG_ATM_FORE200E_DEBUG=0 +CONFIG_ATM_FORE200E=m +CONFIG_ATM_HE=m +CONFIG_ATM_HE_USE_SUNI=y +CONFIG_FDDI=y +CONFIG_DEFXX=m +# CONFIG_DEFXX_MMIO is not set +CONFIG_SKFP=m +CONFIG_HIPPI=y +CONFIG_ROADRUNNER=m +# CONFIG_ROADRUNNER_LARGE_RINGS is not set +CONFIG_PLIP=m +CONFIG_PPP=m +CONFIG_PPP_MULTILINK=y +CONFIG_PPP_FILTER=y +CONFIG_PPP_ASYNC=m +CONFIG_PPP_SYNC_TTY=m +CONFIG_PPP_DEFLATE=m +CONFIG_PPP_BSDCOMP=m +CONFIG_PPP_MPPE=m +CONFIG_PPPOE=m +CONFIG_PPPOATM=m +# CONFIG_PPPOL2TP is not set +CONFIG_SLIP=m +CONFIG_SLIP_COMPRESSED=y +CONFIG_SLHC=m +CONFIG_SLIP_SMART=y +CONFIG_SLIP_MODE_SLIP6=y +CONFIG_NET_FC=y +CONFIG_SHAPER=m +CONFIG_NETCONSOLE=m +CONFIG_NETPOLL=y +# CONFIG_NETPOLL_TRAP is not set +CONFIG_NET_POLL_CONTROLLER=y +CONFIG_ISDN=m +CONFIG_ISDN_I4L=m +CONFIG_ISDN_PPP=y +CONFIG_ISDN_PPP_VJ=y +CONFIG_ISDN_MPP=y +CONFIG_IPPP_FILTER=y +CONFIG_ISDN_PPP_BSDCOMP=m +CONFIG_ISDN_AUDIO=y +CONFIG_ISDN_TTY_FAX=y +CONFIG_ISDN_X25=y + +# +# ISDN feature submodules +# +# CONFIG_ISDN_DRV_LOOP is not set +CONFIG_ISDN_DIVERSION=m + +# +# ISDN4Linux hardware drivers +# + +# +# Passive cards +# +CONFIG_ISDN_DRV_HISAX=m + +# +# D-channel protocol features +# +CONFIG_HISAX_EURO=y +CONFIG_DE_AOC=y +# CONFIG_HISAX_NO_SENDCOMPLETE is not set +# CONFIG_HISAX_NO_LLC is not set +# CONFIG_HISAX_NO_KEYPAD is not set +CONFIG_HISAX_1TR6=y +CONFIG_HISAX_NI1=y +CONFIG_HISAX_MAX_CARDS=8 + +# +# HiSax supported cards +# +CONFIG_HISAX_16_3=y +CONFIG_HISAX_TELESPCI=y +CONFIG_HISAX_S0BOX=y +CONFIG_HISAX_FRITZPCI=y +CONFIG_HISAX_AVM_A1_PCMCIA=y +CONFIG_HISAX_ELSA=y +CONFIG_HISAX_DIEHLDIVA=y +CONFIG_HISAX_SEDLBAUER=y +CONFIG_HISAX_NETJET=y +CONFIG_HISAX_NETJET_U=y +CONFIG_HISAX_NICCY=y +CONFIG_HISAX_BKM_A4T=y +CONFIG_HISAX_SCT_QUADRO=y +CONFIG_HISAX_GAZEL=y +CONFIG_HISAX_HFC_PCI=y +CONFIG_HISAX_W6692=y +CONFIG_HISAX_HFC_SX=y +CONFIG_HISAX_ENTERNOW_PCI=y +# CONFIG_HISAX_DEBUG is not set + +# +# HiSax PCMCIA card service modules +# +CONFIG_HISAX_SEDLBAUER_CS=m +CONFIG_HISAX_ELSA_CS=m +CONFIG_HISAX_AVM_A1_CS=m +CONFIG_HISAX_TELES_CS=m + +# +# HiSax sub driver modules +# +CONFIG_HISAX_ST5481=m +CONFIG_HISAX_HFCUSB=m +CONFIG_HISAX_HFC4S8S=m +CONFIG_HISAX_FRITZ_PCIPNP=m +CONFIG_HISAX_HDLC=y + +# +# Active cards +# +# CONFIG_HYSDN is not set +CONFIG_ISDN_DRV_GIGASET=m +CONFIG_GIGASET_BASE=m +CONFIG_GIGASET_M105=m +# CONFIG_GIGASET_M101 is not set +# CONFIG_GIGASET_DEBUG is not set +# CONFIG_GIGASET_UNDOCREQ is not set +CONFIG_ISDN_CAPI=m +CONFIG_ISDN_DRV_AVMB1_VERBOSE_REASON=y +CONFIG_CAPI_TRACE=y +CONFIG_ISDN_CAPI_MIDDLEWARE=y +CONFIG_ISDN_CAPI_CAPI20=m +CONFIG_ISDN_CAPI_CAPIFS_BOOL=y +CONFIG_ISDN_CAPI_CAPIFS=m +CONFIG_ISDN_CAPI_CAPIDRV=m + +# +# CAPI hardware drivers +# +CONFIG_CAPI_AVM=y +CONFIG_ISDN_DRV_AVMB1_B1PCI=m +CONFIG_ISDN_DRV_AVMB1_B1PCIV4=y +CONFIG_ISDN_DRV_AVMB1_B1PCMCIA=m +CONFIG_ISDN_DRV_AVMB1_AVM_CS=m +CONFIG_ISDN_DRV_AVMB1_T1PCI=m +CONFIG_ISDN_DRV_AVMB1_C4=m +CONFIG_CAPI_EICON=y +CONFIG_ISDN_DIVAS=m +CONFIG_ISDN_DIVAS_BRIPCI=y +CONFIG_ISDN_DIVAS_PRIPCI=y +CONFIG_ISDN_DIVAS_DIVACAPI=m +CONFIG_ISDN_DIVAS_USERIDI=m +CONFIG_ISDN_DIVAS_MAINT=m +CONFIG_PHONE=m +CONFIG_PHONE_IXJ=m +CONFIG_PHONE_IXJ_PCMCIA=m + +# +# Input device support +# +CONFIG_INPUT=y +CONFIG_INPUT_FF_MEMLESS=m +# CONFIG_INPUT_POLLDEV is not set + +# +# Userland interfaces +# +CONFIG_INPUT_MOUSEDEV=y +CONFIG_INPUT_MOUSEDEV_PSAUX=y +CONFIG_INPUT_MOUSEDEV_SCREEN_X=1024 +CONFIG_INPUT_MOUSEDEV_SCREEN_Y=768 +CONFIG_INPUT_JOYDEV=m +CONFIG_INPUT_TSDEV=m +CONFIG_INPUT_TSDEV_SCREEN_X=240 +CONFIG_INPUT_TSDEV_SCREEN_Y=320 +CONFIG_INPUT_EVDEV=m +CONFIG_INPUT_EVBUG=m + +# +# Input Device Drivers +# +CONFIG_INPUT_KEYBOARD=y +CONFIG_KEYBOARD_ATKBD=y +CONFIG_KEYBOARD_SUNKBD=m +CONFIG_KEYBOARD_LKKBD=m +CONFIG_KEYBOARD_XTKBD=m +CONFIG_KEYBOARD_NEWTON=m +CONFIG_KEYBOARD_STOWAWAY=m +CONFIG_INPUT_MOUSE=y +CONFIG_MOUSE_PS2=m +CONFIG_MOUSE_PS2_ALPS=y +CONFIG_MOUSE_PS2_LOGIPS2PP=y +CONFIG_MOUSE_PS2_SYNAPTICS=y +CONFIG_MOUSE_PS2_LIFEBOOK=y +CONFIG_MOUSE_PS2_TRACKPOINT=y +# CONFIG_MOUSE_PS2_TOUCHKIT is not set +CONFIG_MOUSE_SERIAL=m +# CONFIG_MOUSE_APPLETOUCH is not set +CONFIG_MOUSE_VSXXXAA=m +CONFIG_INPUT_JOYSTICK=y +CONFIG_JOYSTICK_ANALOG=m +CONFIG_JOYSTICK_A3D=m +CONFIG_JOYSTICK_ADI=m +CONFIG_JOYSTICK_COBRA=m +CONFIG_JOYSTICK_GF2K=m +CONFIG_JOYSTICK_GRIP=m +CONFIG_JOYSTICK_GRIP_MP=m +CONFIG_JOYSTICK_GUILLEMOT=m +CONFIG_JOYSTICK_INTERACT=m +CONFIG_JOYSTICK_SIDEWINDER=m +CONFIG_JOYSTICK_TMDC=m +CONFIG_JOYSTICK_IFORCE=m +CONFIG_JOYSTICK_IFORCE_USB=y +CONFIG_JOYSTICK_IFORCE_232=y +CONFIG_JOYSTICK_WARRIOR=m +CONFIG_JOYSTICK_MAGELLAN=m +CONFIG_JOYSTICK_SPACEORB=m +CONFIG_JOYSTICK_SPACEBALL=m +CONFIG_JOYSTICK_STINGER=m +CONFIG_JOYSTICK_TWIDJOY=m +CONFIG_JOYSTICK_DB9=m +CONFIG_JOYSTICK_GAMECON=m +CONFIG_JOYSTICK_TURBOGRAFX=m +CONFIG_JOYSTICK_JOYDUMP=m +# CONFIG_JOYSTICK_XPAD is not set +# CONFIG_INPUT_TABLET is not set +CONFIG_INPUT_TOUCHSCREEN=y +CONFIG_TOUCHSCREEN_ADS7846=m +# CONFIG_TOUCHSCREEN_FUJITSU is not set +CONFIG_TOUCHSCREEN_GUNZE=m +CONFIG_TOUCHSCREEN_ELO=m +CONFIG_TOUCHSCREEN_MTOUCH=m +CONFIG_TOUCHSCREEN_MK712=m +CONFIG_TOUCHSCREEN_PENMOUNT=m +CONFIG_TOUCHSCREEN_TOUCHRIGHT=m +CONFIG_TOUCHSCREEN_TOUCHWIN=m +# CONFIG_TOUCHSCREEN_UCB1400 is not set +# CONFIG_TOUCHSCREEN_USB_COMPOSITE is not set +CONFIG_INPUT_MISC=y +CONFIG_INPUT_PCSPKR=m +# CONFIG_INPUT_ATI_REMOTE is not set +# CONFIG_INPUT_ATI_REMOTE2 is not set +# CONFIG_INPUT_KEYSPAN_REMOTE is not set +# CONFIG_INPUT_POWERMATE is not set +# CONFIG_INPUT_YEALINK is not set +CONFIG_INPUT_UINPUT=m + +# +# Hardware I/O ports +# +CONFIG_SERIO=y +CONFIG_SERIO_I8042=y +CONFIG_SERIO_SERPORT=m +CONFIG_SERIO_PARKBD=m +CONFIG_SERIO_PCIPS2=m +CONFIG_SERIO_LIBPS2=y +CONFIG_SERIO_RAW=m +CONFIG_GAMEPORT=m +CONFIG_GAMEPORT_NS558=m +CONFIG_GAMEPORT_L4=m +CONFIG_GAMEPORT_EMU10K1=m +CONFIG_GAMEPORT_FM801=m + +# +# Character devices +# +CONFIG_VT=y +CONFIG_VT_CONSOLE=y +CONFIG_HW_CONSOLE=y +CONFIG_VT_HW_CONSOLE_BINDING=y +CONFIG_SERIAL_NONSTANDARD=y +# CONFIG_COMPUTONE is not set +CONFIG_ROCKETPORT=m +CONFIG_CYCLADES=m +# CONFIG_CYZ_INTR is not set +CONFIG_DIGIEPCA=m +# CONFIG_MOXA_INTELLIO is not set +CONFIG_MOXA_SMARTIO=m +# CONFIG_MOXA_SMARTIO_NEW is not set +# CONFIG_ISI is not set +CONFIG_SYNCLINKMP=m +CONFIG_SYNCLINK_GT=m +CONFIG_N_HDLC=m +# CONFIG_RISCOM8 is not set +CONFIG_SPECIALIX=m +# CONFIG_SPECIALIX_RTSCTS is not set +CONFIG_SX=m +# CONFIG_RIO is not set +CONFIG_STALDRV=y +# CONFIG_STALLION is not set +# CONFIG_ISTALLION is not set + +# +# Serial drivers +# +CONFIG_SERIAL_8250=m +CONFIG_SERIAL_8250_PCI=m +CONFIG_SERIAL_8250_CS=m +CONFIG_SERIAL_8250_NR_UARTS=48 +CONFIG_SERIAL_8250_RUNTIME_UARTS=4 +CONFIG_SERIAL_8250_EXTENDED=y +CONFIG_SERIAL_8250_MANY_PORTS=y +CONFIG_SERIAL_8250_SHARE_IRQ=y +# CONFIG_SERIAL_8250_DETECT_IRQ is not set +CONFIG_SERIAL_8250_RSA=y +# CONFIG_SERIAL_8250_AU1X00 is not set + +# +# Non-8250 serial port support +# +CONFIG_SERIAL_CORE=m +CONFIG_SERIAL_JSM=m +CONFIG_UNIX98_PTYS=y +CONFIG_LEGACY_PTYS=y +CONFIG_LEGACY_PTY_COUNT=256 +CONFIG_PRINTER=m +# CONFIG_LP_CONSOLE is not set +CONFIG_PPDEV=m +CONFIG_TIPAR=m +CONFIG_IPMI_HANDLER=m +# CONFIG_IPMI_PANIC_EVENT is not set +CONFIG_IPMI_DEVICE_INTERFACE=m +CONFIG_IPMI_SI=m +CONFIG_IPMI_WATCHDOG=m +CONFIG_IPMI_POWEROFF=m +CONFIG_WATCHDOG=y +# CONFIG_WATCHDOG_NOWAYOUT is not set + +# +# Watchdog Device Drivers +# +CONFIG_SOFT_WATCHDOG=m +# CONFIG_WDT_MTX1 is not set + +# +# PCI-based Watchdog Cards +# +CONFIG_PCIPCWATCHDOG=m +CONFIG_WDTPCI=m +CONFIG_WDT_501_PCI=y + +# +# USB-based Watchdog Cards +# +CONFIG_USBPCWATCHDOG=m +CONFIG_HW_RANDOM=y +CONFIG_RTC=y +CONFIG_R3964=m +CONFIG_APPLICOM=m +CONFIG_DRM=m +CONFIG_DRM_TDFX=m +CONFIG_DRM_R128=m +CONFIG_DRM_RADEON=m +CONFIG_DRM_MGA=m +CONFIG_DRM_VIA=m +CONFIG_DRM_SAVAGE=m + +# +# PCMCIA character devices +# +CONFIG_SYNCLINK_CS=m +CONFIG_CARDMAN_4000=m +CONFIG_CARDMAN_4040=m +CONFIG_RAW_DRIVER=m +CONFIG_MAX_RAW_DEVS=256 +CONFIG_TCG_TPM=m +CONFIG_TCG_ATMEL=m +CONFIG_DEVPORT=y +CONFIG_I2C=m +CONFIG_I2C_BOARDINFO=y +CONFIG_I2C_CHARDEV=m + +# +# I2C Algorithms +# +CONFIG_I2C_ALGOBIT=m +CONFIG_I2C_ALGOPCF=m +CONFIG_I2C_ALGOPCA=m + +# +# I2C Hardware Bus support +# +CONFIG_I2C_ALI1535=m +CONFIG_I2C_ALI1563=m +CONFIG_I2C_ALI15X3=m +CONFIG_I2C_AMD756=m +CONFIG_I2C_AMD756_S4882=m +CONFIG_I2C_AMD8111=m +CONFIG_I2C_I801=m +CONFIG_I2C_I810=m +CONFIG_I2C_PIIX4=m +CONFIG_I2C_NFORCE2=m +CONFIG_I2C_OCORES=m +CONFIG_I2C_PARPORT=m +CONFIG_I2C_PARPORT_LIGHT=m +CONFIG_I2C_PROSAVAGE=m +CONFIG_I2C_SAVAGE4=m +# CONFIG_I2C_SIMTEC is not set +CONFIG_I2C_SIS5595=m +CONFIG_I2C_SIS630=m +CONFIG_I2C_SIS96X=m +# CONFIG_I2C_TAOS_EVM is not set +CONFIG_I2C_STUB=m +# CONFIG_I2C_TINY_USB is not set +CONFIG_I2C_VIA=m +CONFIG_I2C_VIAPRO=m +CONFIG_I2C_VOODOO3=m + +# +# Miscellaneous I2C Chip support +# +CONFIG_SENSORS_DS1337=m +CONFIG_SENSORS_DS1374=m +# CONFIG_DS1682 is not set +CONFIG_SENSORS_EEPROM=m +CONFIG_SENSORS_PCF8574=m +CONFIG_SENSORS_PCA9539=m +CONFIG_SENSORS_PCF8591=m +CONFIG_SENSORS_MAX6875=m +# CONFIG_SENSORS_TSL2550 is not set +# CONFIG_I2C_DEBUG_CORE is not set +# CONFIG_I2C_DEBUG_ALGO is not set +# CONFIG_I2C_DEBUG_BUS is not set +# CONFIG_I2C_DEBUG_CHIP is not set + +# +# SPI support +# +CONFIG_SPI=y +CONFIG_SPI_MASTER=y + +# +# SPI Master Controller Drivers +# +CONFIG_SPI_BITBANG=m +CONFIG_SPI_BUTTERFLY=m +# CONFIG_SPI_LM70_LLP is not set + +# +# SPI Protocol Masters +# +# CONFIG_SPI_AT25 is not set +# CONFIG_SPI_SPIDEV is not set +# CONFIG_SPI_TLE62X0 is not set +CONFIG_W1=m +CONFIG_W1_CON=y + +# +# 1-wire Bus Masters +# +CONFIG_W1_MASTER_MATROX=m +CONFIG_W1_MASTER_DS2490=m +CONFIG_W1_MASTER_DS2482=m + +# +# 1-wire Slaves +# +CONFIG_W1_SLAVE_THERM=m +CONFIG_W1_SLAVE_SMEM=m +CONFIG_W1_SLAVE_DS2433=m +# CONFIG_W1_SLAVE_DS2433_CRC is not set +# CONFIG_W1_SLAVE_DS2760 is not set +# CONFIG_POWER_SUPPLY is not set +CONFIG_HWMON=y +CONFIG_HWMON_VID=m +CONFIG_SENSORS_ABITUGURU=m +# CONFIG_SENSORS_ABITUGURU3 is not set +# CONFIG_SENSORS_AD7418 is not set +CONFIG_SENSORS_ADM1021=m +CONFIG_SENSORS_ADM1025=m +CONFIG_SENSORS_ADM1026=m +# CONFIG_SENSORS_ADM1029 is not set +CONFIG_SENSORS_ADM1031=m +CONFIG_SENSORS_ADM9240=m +CONFIG_SENSORS_ASB100=m +CONFIG_SENSORS_ATXP1=m +CONFIG_SENSORS_DS1621=m +CONFIG_SENSORS_F71805F=m +CONFIG_SENSORS_FSCHER=m +CONFIG_SENSORS_FSCPOS=m +CONFIG_SENSORS_GL518SM=m +CONFIG_SENSORS_GL520SM=m +CONFIG_SENSORS_IT87=m +CONFIG_SENSORS_LM63=m +CONFIG_SENSORS_LM70=m +CONFIG_SENSORS_LM75=m +CONFIG_SENSORS_LM77=m +CONFIG_SENSORS_LM78=m +CONFIG_SENSORS_LM80=m +CONFIG_SENSORS_LM83=m +CONFIG_SENSORS_LM85=m +CONFIG_SENSORS_LM87=m +CONFIG_SENSORS_LM90=m +CONFIG_SENSORS_LM92=m +# CONFIG_SENSORS_LM93 is not set +CONFIG_SENSORS_MAX1619=m +# CONFIG_SENSORS_MAX6650 is not set +CONFIG_SENSORS_PC87360=m +# CONFIG_SENSORS_PC87427 is not set +CONFIG_SENSORS_SIS5595=m +# CONFIG_SENSORS_DME1737 is not set +CONFIG_SENSORS_SMSC47M1=m +CONFIG_SENSORS_SMSC47M192=m +CONFIG_SENSORS_SMSC47B397=m +# CONFIG_SENSORS_THMC50 is not set +CONFIG_SENSORS_VIA686A=m +CONFIG_SENSORS_VT1211=m +CONFIG_SENSORS_VT8231=m +CONFIG_SENSORS_W83781D=m +CONFIG_SENSORS_W83791D=m +CONFIG_SENSORS_W83792D=m +# CONFIG_SENSORS_W83793 is not set +CONFIG_SENSORS_W83L785TS=m +CONFIG_SENSORS_W83627HF=m +CONFIG_SENSORS_W83627EHF=m +# CONFIG_HWMON_DEBUG_CHIP is not set + +# +# Multifunction device drivers +# +# CONFIG_MFD_SM501 is not set + +# +# Multimedia devices +# +CONFIG_VIDEO_DEV=m +CONFIG_VIDEO_V4L1=y +CONFIG_VIDEO_V4L1_COMPAT=y +CONFIG_VIDEO_V4L2=y +CONFIG_VIDEO_CAPTURE_DRIVERS=y +# CONFIG_VIDEO_ADV_DEBUG is not set +CONFIG_VIDEO_HELPER_CHIPS_AUTO=y +CONFIG_VIDEO_TVAUDIO=m +CONFIG_VIDEO_TDA7432=m +CONFIG_VIDEO_TDA9840=m +CONFIG_VIDEO_TDA9875=m +CONFIG_VIDEO_TEA6415C=m +CONFIG_VIDEO_TEA6420=m +CONFIG_VIDEO_MSP3400=m +CONFIG_VIDEO_WM8775=m +CONFIG_VIDEO_BT819=m +CONFIG_VIDEO_BT856=m +CONFIG_VIDEO_KS0127=m +CONFIG_VIDEO_SAA7110=m +CONFIG_VIDEO_SAA7111=m +CONFIG_VIDEO_SAA7114=m +CONFIG_VIDEO_SAA711X=m +CONFIG_VIDEO_TVP5150=m +CONFIG_VIDEO_VPX3220=m +CONFIG_VIDEO_CX25840=m +CONFIG_VIDEO_CX2341X=m +CONFIG_VIDEO_SAA7185=m +CONFIG_VIDEO_ADV7170=m +CONFIG_VIDEO_ADV7175=m +CONFIG_VIDEO_VIVI=m +CONFIG_VIDEO_BT848=m +CONFIG_VIDEO_BT848_DVB=y +CONFIG_VIDEO_SAA6588=m +CONFIG_VIDEO_BWQCAM=m +CONFIG_VIDEO_CQCAM=m +CONFIG_VIDEO_W9966=m +CONFIG_VIDEO_CPIA=m +CONFIG_VIDEO_CPIA_PP=m +CONFIG_VIDEO_CPIA_USB=m +CONFIG_VIDEO_CPIA2=m +CONFIG_VIDEO_SAA5246A=m +CONFIG_VIDEO_SAA5249=m +CONFIG_TUNER_3036=m +# CONFIG_TUNER_TEA5761 is not set +CONFIG_VIDEO_STRADIS=m +CONFIG_VIDEO_ZORAN_ZR36060=m +CONFIG_VIDEO_ZORAN=m +CONFIG_VIDEO_ZORAN_BUZ=m +CONFIG_VIDEO_ZORAN_DC10=m +CONFIG_VIDEO_ZORAN_DC30=m +CONFIG_VIDEO_ZORAN_LML33=m +CONFIG_VIDEO_ZORAN_LML33R10=m +CONFIG_VIDEO_ZORAN_AVS6EYES=m +CONFIG_VIDEO_SAA7134=m +CONFIG_VIDEO_SAA7134_ALSA=m +CONFIG_VIDEO_SAA7134_OSS=m +CONFIG_VIDEO_SAA7134_DVB=m +CONFIG_VIDEO_MXB=m +CONFIG_VIDEO_DPC=m +CONFIG_VIDEO_HEXIUM_ORION=m +CONFIG_VIDEO_HEXIUM_GEMINI=m +CONFIG_VIDEO_CX88=m +CONFIG_VIDEO_CX88_ALSA=m +CONFIG_VIDEO_CX88_BLACKBIRD=m +CONFIG_VIDEO_CX88_DVB=m +CONFIG_VIDEO_CX88_VP3054=m +# CONFIG_VIDEO_IVTV is not set +# CONFIG_VIDEO_CAFE_CCIC is not set +CONFIG_V4L_USB_DRIVERS=y +CONFIG_VIDEO_PVRUSB2=m +CONFIG_VIDEO_PVRUSB2_29XXX=y +CONFIG_VIDEO_PVRUSB2_24XXX=y +CONFIG_VIDEO_PVRUSB2_SYSFS=y +# CONFIG_VIDEO_PVRUSB2_DEBUGIFC is not set +CONFIG_VIDEO_EM28XX=m +# CONFIG_VIDEO_USBVISION is not set +CONFIG_VIDEO_USBVIDEO=m +CONFIG_USB_VICAM=m +CONFIG_USB_IBMCAM=m +CONFIG_USB_KONICAWC=m +CONFIG_USB_QUICKCAM_MESSENGER=m +CONFIG_USB_ET61X251=m +CONFIG_VIDEO_OVCAMCHIP=m +CONFIG_USB_W9968CF=m +# CONFIG_USB_OV511 is not set +CONFIG_USB_SE401=m +CONFIG_USB_SN9C102=m +CONFIG_USB_STV680=m +CONFIG_USB_ZC0301=m +CONFIG_USB_PWC=m +# CONFIG_USB_PWC_DEBUG is not set +# CONFIG_USB_ZR364XX is not set +CONFIG_RADIO_ADAPTERS=y +CONFIG_RADIO_GEMTEK_PCI=m +CONFIG_RADIO_MAXIRADIO=m +CONFIG_RADIO_MAESTRO=m +CONFIG_USB_DSBR=m +CONFIG_DVB_CORE=m +CONFIG_DVB_CORE_ATTACH=y +CONFIG_DVB_CAPTURE_DRIVERS=y + +# +# Supported SAA7146 based PCI Adapters +# +CONFIG_DVB_AV7110=m +CONFIG_DVB_AV7110_OSD=y +CONFIG_DVB_BUDGET=m +CONFIG_DVB_BUDGET_CI=m +CONFIG_DVB_BUDGET_AV=m +CONFIG_DVB_BUDGET_PATCH=m + +# +# Supported USB Adapters +# +CONFIG_DVB_USB=m +# CONFIG_DVB_USB_DEBUG is not set +CONFIG_DVB_USB_A800=m +CONFIG_DVB_USB_DIBUSB_MB=m +CONFIG_DVB_USB_DIBUSB_MB_FAULTY=y +CONFIG_DVB_USB_DIBUSB_MC=m +CONFIG_DVB_USB_DIB0700=m +CONFIG_DVB_USB_UMT_010=m +CONFIG_DVB_USB_CXUSB=m +# CONFIG_DVB_USB_M920X is not set +# CONFIG_DVB_USB_GL861 is not set +# CONFIG_DVB_USB_AU6610 is not set +CONFIG_DVB_USB_DIGITV=m +CONFIG_DVB_USB_VP7045=m +CONFIG_DVB_USB_VP702X=m +CONFIG_DVB_USB_GP8PSK=m +CONFIG_DVB_USB_NOVA_T_USB2=m +# CONFIG_DVB_USB_TTUSB2 is not set +CONFIG_DVB_USB_DTT200U=m +# CONFIG_DVB_USB_OPERA1 is not set +# CONFIG_DVB_USB_AF9005 is not set +CONFIG_DVB_TTUSB_BUDGET=m +CONFIG_DVB_TTUSB_DEC=m +CONFIG_DVB_CINERGYT2=m +CONFIG_DVB_CINERGYT2_TUNING=y +CONFIG_DVB_CINERGYT2_STREAM_URB_COUNT=32 +CONFIG_DVB_CINERGYT2_STREAM_BUF_SIZE=512 +CONFIG_DVB_CINERGYT2_QUERY_INTERVAL=250 +CONFIG_DVB_CINERGYT2_ENABLE_RC_INPUT_DEVICE=y +CONFIG_DVB_CINERGYT2_RC_QUERY_INTERVAL=100 + +# +# Supported FlexCopII (B2C2) Adapters +# +CONFIG_DVB_B2C2_FLEXCOP=m +CONFIG_DVB_B2C2_FLEXCOP_PCI=m +CONFIG_DVB_B2C2_FLEXCOP_USB=m +# CONFIG_DVB_B2C2_FLEXCOP_DEBUG is not set + +# +# Supported BT878 Adapters +# +CONFIG_DVB_BT8XX=m + +# +# Supported Pluto2 Adapters +# +CONFIG_DVB_PLUTO2=m + +# +# Supported DVB Frontends +# + +# +# Customise DVB Frontends +# +# CONFIG_DVB_FE_CUSTOMISE is not set + +# +# DVB-S (satellite) frontends +# +CONFIG_DVB_STV0299=m +CONFIG_DVB_CX24110=m +CONFIG_DVB_CX24123=m +CONFIG_DVB_TDA8083=m +CONFIG_DVB_MT312=m +CONFIG_DVB_VES1X93=m +CONFIG_DVB_S5H1420=m +CONFIG_DVB_TDA10086=m + +# +# DVB-T (terrestrial) frontends +# +CONFIG_DVB_SP8870=m +CONFIG_DVB_SP887X=m +CONFIG_DVB_CX22700=m +CONFIG_DVB_CX22702=m +CONFIG_DVB_L64781=m +CONFIG_DVB_TDA1004X=m +CONFIG_DVB_NXT6000=m +CONFIG_DVB_MT352=m +CONFIG_DVB_ZL10353=m +CONFIG_DVB_DIB3000MB=m +CONFIG_DVB_DIB3000MC=m +CONFIG_DVB_DIB7000M=m +CONFIG_DVB_DIB7000P=m + +# +# DVB-C (cable) frontends +# +CONFIG_DVB_VES1820=m +CONFIG_DVB_TDA10021=m +CONFIG_DVB_TDA10023=m +CONFIG_DVB_STV0297=m + +# +# ATSC (North American/Korean Terrestrial/Cable DTV) frontends +# +CONFIG_DVB_NXT200X=m +CONFIG_DVB_OR51211=m +CONFIG_DVB_OR51132=m +CONFIG_DVB_BCM3510=m +CONFIG_DVB_LGDT330X=m + +# +# Tuners/PLL support +# +CONFIG_DVB_PLL=m +CONFIG_DVB_TDA826X=m +CONFIG_DVB_TDA827X=m +# CONFIG_DVB_TUNER_QT1010 is not set +CONFIG_DVB_TUNER_MT2060=m + +# +# Miscellaneous devices +# +CONFIG_DVB_LNBP21=m +CONFIG_DVB_ISL6421=m +CONFIG_DVB_TUA6100=m +CONFIG_VIDEO_SAA7146=m +CONFIG_VIDEO_SAA7146_VV=m +CONFIG_VIDEO_TUNER=m +CONFIG_VIDEO_BUF=m +CONFIG_VIDEO_BUF_DVB=m +CONFIG_VIDEO_BTCX=m +CONFIG_VIDEO_IR_I2C=m +CONFIG_VIDEO_IR=m +CONFIG_VIDEO_TVEEPROM=m +CONFIG_DAB=y +CONFIG_USB_DABUSB=m + +# +# Graphics support +# +CONFIG_BACKLIGHT_LCD_SUPPORT=y +CONFIG_LCD_CLASS_DEVICE=m +CONFIG_BACKLIGHT_CLASS_DEVICE=y + +# +# Display device support +# +# CONFIG_DISPLAY_SUPPORT is not set +CONFIG_VGASTATE=m +CONFIG_VIDEO_OUTPUT_CONTROL=m +CONFIG_FB=y +CONFIG_FIRMWARE_EDID=y +CONFIG_FB_DDC=m +CONFIG_FB_CFB_FILLRECT=m +CONFIG_FB_CFB_COPYAREA=m +CONFIG_FB_CFB_IMAGEBLIT=m +# CONFIG_FB_SYS_FILLRECT is not set +# CONFIG_FB_SYS_COPYAREA is not set +# CONFIG_FB_SYS_IMAGEBLIT is not set +# CONFIG_FB_SYS_FOPS is not set +CONFIG_FB_DEFERRED_IO=y +# CONFIG_FB_SVGALIB is not set +# CONFIG_FB_MACMODES is not set +CONFIG_FB_BACKLIGHT=y +CONFIG_FB_MODE_HELPERS=y +CONFIG_FB_TILEBLITTING=y + +# +# Frame buffer hardware drivers +# +CONFIG_FB_CIRRUS=m +CONFIG_FB_PM2=m +CONFIG_FB_PM2_FIFO_DISCONNECT=y +CONFIG_FB_CYBER2000=m +# CONFIG_FB_ASILIANT is not set +# CONFIG_FB_IMSTT is not set +CONFIG_FB_S1D13XXX=m +CONFIG_FB_NVIDIA=m +CONFIG_FB_NVIDIA_I2C=y +# CONFIG_FB_NVIDIA_DEBUG is not set +CONFIG_FB_NVIDIA_BACKLIGHT=y +CONFIG_FB_RIVA=m +CONFIG_FB_RIVA_I2C=y +# CONFIG_FB_RIVA_DEBUG is not set +CONFIG_FB_RIVA_BACKLIGHT=y +CONFIG_FB_MATROX=m +CONFIG_FB_MATROX_MILLENIUM=y +CONFIG_FB_MATROX_MYSTIQUE=y +CONFIG_FB_MATROX_G=y +CONFIG_FB_MATROX_I2C=m +CONFIG_FB_MATROX_MAVEN=m +CONFIG_FB_MATROX_MULTIHEAD=y +CONFIG_FB_RADEON=m +CONFIG_FB_RADEON_I2C=y +CONFIG_FB_RADEON_BACKLIGHT=y +# CONFIG_FB_RADEON_DEBUG is not set +CONFIG_FB_ATY128=m +CONFIG_FB_ATY128_BACKLIGHT=y +CONFIG_FB_ATY=m +CONFIG_FB_ATY_CT=y +CONFIG_FB_ATY_GENERIC_LCD=y +CONFIG_FB_ATY_GX=y +CONFIG_FB_ATY_BACKLIGHT=y +# CONFIG_FB_S3 is not set +CONFIG_FB_SAVAGE=m +CONFIG_FB_SAVAGE_I2C=y +CONFIG_FB_SAVAGE_ACCEL=y +CONFIG_FB_SIS=m +CONFIG_FB_SIS_300=y +CONFIG_FB_SIS_315=y +CONFIG_FB_NEOMAGIC=m +CONFIG_FB_KYRO=m +CONFIG_FB_3DFX=m +# CONFIG_FB_3DFX_ACCEL is not set +CONFIG_FB_VOODOO1=m +# CONFIG_FB_VT8623 is not set +CONFIG_FB_TRIDENT=m +# CONFIG_FB_TRIDENT_ACCEL is not set +# CONFIG_FB_ARK is not set +# CONFIG_FB_PM3 is not set +# CONFIG_FB_VIRTUAL is not set + +# +# Console display driver support +# +CONFIG_VGA_CONSOLE=y +# CONFIG_VGACON_SOFT_SCROLLBACK is not set +CONFIG_DUMMY_CONSOLE=y +CONFIG_FRAMEBUFFER_CONSOLE=m +# CONFIG_FRAMEBUFFER_CONSOLE_DETECT_PRIMARY is not set +# CONFIG_FRAMEBUFFER_CONSOLE_ROTATION is not set +# CONFIG_FONTS is not set +CONFIG_FONT_8x8=y +CONFIG_FONT_8x16=y +# CONFIG_LOGO is not set + +# +# Sound +# +CONFIG_SOUND=m + +# +# Advanced Linux Sound Architecture +# +CONFIG_SND=m +CONFIG_SND_TIMER=m +CONFIG_SND_PCM=m +CONFIG_SND_HWDEP=m +CONFIG_SND_RAWMIDI=m +CONFIG_SND_SEQUENCER=m +CONFIG_SND_SEQ_DUMMY=m +CONFIG_SND_OSSEMUL=y +CONFIG_SND_MIXER_OSS=m +CONFIG_SND_PCM_OSS=m +CONFIG_SND_PCM_OSS_PLUGINS=y +CONFIG_SND_SEQUENCER_OSS=y +CONFIG_SND_RTCTIMER=m +CONFIG_SND_SEQ_RTCTIMER_DEFAULT=y +CONFIG_SND_DYNAMIC_MINORS=y +CONFIG_SND_SUPPORT_OLD_API=y +CONFIG_SND_VERBOSE_PROCFS=y +# CONFIG_SND_VERBOSE_PRINTK is not set +# CONFIG_SND_DEBUG is not set + +# +# Generic devices +# +CONFIG_SND_MPU401_UART=m +CONFIG_SND_OPL3_LIB=m +CONFIG_SND_VX_LIB=m +CONFIG_SND_AC97_CODEC=m +CONFIG_SND_DUMMY=m +CONFIG_SND_VIRMIDI=m +CONFIG_SND_MTPAV=m +CONFIG_SND_MTS64=m +CONFIG_SND_SERIAL_U16550=m +CONFIG_SND_MPU401=m +# CONFIG_SND_PORTMAN2X4 is not set + +# +# PCI devices +# +CONFIG_SND_AD1889=m +CONFIG_SND_ALS300=m +CONFIG_SND_ALI5451=m +CONFIG_SND_ATIIXP=m +CONFIG_SND_ATIIXP_MODEM=m +CONFIG_SND_AU8810=m +CONFIG_SND_AU8820=m +CONFIG_SND_AU8830=m +CONFIG_SND_AZT3328=m +CONFIG_SND_BT87X=m +# CONFIG_SND_BT87X_OVERCLOCK is not set +CONFIG_SND_CA0106=m +CONFIG_SND_CMIPCI=m +CONFIG_SND_CS4281=m +CONFIG_SND_CS46XX=m +CONFIG_SND_CS46XX_NEW_DSP=y +CONFIG_SND_DARLA20=m +CONFIG_SND_GINA20=m +CONFIG_SND_LAYLA20=m +CONFIG_SND_DARLA24=m +CONFIG_SND_GINA24=m +CONFIG_SND_LAYLA24=m +CONFIG_SND_MONA=m +CONFIG_SND_MIA=m +CONFIG_SND_ECHO3G=m +CONFIG_SND_INDIGO=m +CONFIG_SND_INDIGOIO=m +CONFIG_SND_INDIGODJ=m +CONFIG_SND_EMU10K1=m +CONFIG_SND_EMU10K1X=m +CONFIG_SND_ENS1370=m +CONFIG_SND_ENS1371=m +CONFIG_SND_ES1938=m +CONFIG_SND_ES1968=m +CONFIG_SND_FM801=m +CONFIG_SND_FM801_TEA575X_BOOL=y +CONFIG_SND_FM801_TEA575X=m +CONFIG_SND_HDA_INTEL=m +CONFIG_SND_HDSP=m +CONFIG_SND_HDSPM=m +CONFIG_SND_ICE1712=m +CONFIG_SND_ICE1724=m +CONFIG_SND_INTEL8X0=m +CONFIG_SND_INTEL8X0M=m +CONFIG_SND_KORG1212=m +CONFIG_SND_KORG1212_FIRMWARE_IN_KERNEL=y +CONFIG_SND_MAESTRO3=m +CONFIG_SND_MAESTRO3_FIRMWARE_IN_KERNEL=y +CONFIG_SND_MIXART=m +CONFIG_SND_NM256=m +CONFIG_SND_PCXHR=m +CONFIG_SND_RIPTIDE=m +CONFIG_SND_RME32=m +CONFIG_SND_RME96=m +CONFIG_SND_RME9652=m +CONFIG_SND_SONICVIBES=m +CONFIG_SND_TRIDENT=m +CONFIG_SND_VIA82XX=m +CONFIG_SND_VIA82XX_MODEM=m +CONFIG_SND_VX222=m +CONFIG_SND_YMFPCI=m +CONFIG_SND_YMFPCI_FIRMWARE_IN_KERNEL=y +# CONFIG_SND_AC97_POWER_SAVE is not set + +# +# ALSA MIPS devices +# +# CONFIG_SND_AU1X00 is not set + +# +# USB devices +# +CONFIG_SND_USB_AUDIO=m +# CONFIG_SND_USB_CAIAQ is not set + +# +# PCMCIA devices +# +CONFIG_SND_VXPOCKET=m +CONFIG_SND_PDAUDIOCF=m + +# +# System on Chip audio support +# +# CONFIG_SND_SOC is not set + +# +# SoC Audio support for SuperH +# + +# +# Open Sound System +# +CONFIG_SOUND_PRIME=m +CONFIG_SOUND_TRIDENT=m +# CONFIG_SOUND_MSNDCLAS is not set +# CONFIG_SOUND_MSNDPIN is not set +CONFIG_AC97_BUS=m +CONFIG_HID_SUPPORT=y +CONFIG_HID=y +# CONFIG_HID_DEBUG is not set + +# +# USB Input Devices +# +CONFIG_USB_HID=m +CONFIG_USB_HIDINPUT_POWERBOOK=y +# CONFIG_HID_FF is not set +CONFIG_USB_HIDDEV=y + +# +# USB HID Boot Protocol drivers +# +CONFIG_USB_KBD=m +CONFIG_USB_MOUSE=m +CONFIG_USB_SUPPORT=y +CONFIG_USB_ARCH_HAS_HCD=y +CONFIG_USB_ARCH_HAS_OHCI=y +CONFIG_USB_ARCH_HAS_EHCI=y +CONFIG_USB=m +# CONFIG_USB_DEBUG is not set + +# +# Miscellaneous USB options +# +CONFIG_USB_DEVICEFS=y +CONFIG_USB_DEVICE_CLASS=y +# CONFIG_USB_DYNAMIC_MINORS is not set +CONFIG_USB_SUSPEND=y +# CONFIG_USB_PERSIST is not set +# CONFIG_USB_OTG is not set + +# +# USB Host Controller Drivers +# +CONFIG_USB_EHCI_HCD=m +CONFIG_USB_EHCI_SPLIT_ISO=y +CONFIG_USB_EHCI_ROOT_HUB_TT=y +CONFIG_USB_EHCI_TT_NEWSCHED=y +# CONFIG_USB_ISP116X_HCD is not set +CONFIG_USB_OHCI_HCD=m +# CONFIG_USB_OHCI_BIG_ENDIAN_DESC is not set +# CONFIG_USB_OHCI_BIG_ENDIAN_MMIO is not set +CONFIG_USB_OHCI_LITTLE_ENDIAN=y +CONFIG_USB_UHCI_HCD=m +CONFIG_USB_U132_HCD=m +CONFIG_USB_SL811_HCD=m +CONFIG_USB_SL811_CS=m +# CONFIG_USB_R8A66597_HCD is not set + +# +# USB Device Class drivers +# +CONFIG_USB_ACM=m +CONFIG_USB_PRINTER=m + +# +# NOTE: USB_STORAGE enables SCSI, and 'SCSI disk support' +# + +# +# may also be needed; see USB_STORAGE Help for more information +# +CONFIG_USB_STORAGE=m +# CONFIG_USB_STORAGE_DEBUG is not set +CONFIG_USB_STORAGE_DATAFAB=y +CONFIG_USB_STORAGE_FREECOM=y +CONFIG_USB_STORAGE_ISD200=y +CONFIG_USB_STORAGE_DPCM=y +CONFIG_USB_STORAGE_USBAT=y +CONFIG_USB_STORAGE_SDDR09=y +CONFIG_USB_STORAGE_SDDR55=y +CONFIG_USB_STORAGE_JUMPSHOT=y +CONFIG_USB_STORAGE_ALAUDA=y +CONFIG_USB_STORAGE_KARMA=y +CONFIG_USB_LIBUSUAL=y + +# +# USB Imaging devices +# +CONFIG_USB_MDC800=m +CONFIG_USB_MICROTEK=m +CONFIG_USB_MON=y + +# +# USB port drivers +# +CONFIG_USB_USS720=m + +# +# USB Serial Converter support +# +CONFIG_USB_SERIAL=m +CONFIG_USB_SERIAL_GENERIC=y +CONFIG_USB_SERIAL_AIRCABLE=m +CONFIG_USB_SERIAL_AIRPRIME=m +CONFIG_USB_SERIAL_ARK3116=m +CONFIG_USB_SERIAL_BELKIN=m +CONFIG_USB_SERIAL_WHITEHEAT=m +CONFIG_USB_SERIAL_DIGI_ACCELEPORT=m +CONFIG_USB_SERIAL_CP2101=m +CONFIG_USB_SERIAL_CYPRESS_M8=m +CONFIG_USB_SERIAL_EMPEG=m +CONFIG_USB_SERIAL_FTDI_SIO=m +CONFIG_USB_SERIAL_FUNSOFT=m +CONFIG_USB_SERIAL_VISOR=m +CONFIG_USB_SERIAL_IPAQ=m +CONFIG_USB_SERIAL_IR=m +CONFIG_USB_SERIAL_EDGEPORT=m +CONFIG_USB_SERIAL_EDGEPORT_TI=m +CONFIG_USB_SERIAL_GARMIN=m +CONFIG_USB_SERIAL_IPW=m +CONFIG_USB_SERIAL_KEYSPAN_PDA=m +CONFIG_USB_SERIAL_KEYSPAN=m +# CONFIG_USB_SERIAL_KEYSPAN_MPR is not set +# CONFIG_USB_SERIAL_KEYSPAN_USA28 is not set +# CONFIG_USB_SERIAL_KEYSPAN_USA28X is not set +# CONFIG_USB_SERIAL_KEYSPAN_USA28XA is not set +# CONFIG_USB_SERIAL_KEYSPAN_USA28XB is not set +# CONFIG_USB_SERIAL_KEYSPAN_USA19 is not set +# CONFIG_USB_SERIAL_KEYSPAN_USA18X is not set +# CONFIG_USB_SERIAL_KEYSPAN_USA19W is not set +# CONFIG_USB_SERIAL_KEYSPAN_USA19QW is not set +# CONFIG_USB_SERIAL_KEYSPAN_USA19QI is not set +# CONFIG_USB_SERIAL_KEYSPAN_USA49W is not set +# CONFIG_USB_SERIAL_KEYSPAN_USA49WLC is not set +CONFIG_USB_SERIAL_KLSI=m +CONFIG_USB_SERIAL_KOBIL_SCT=m +CONFIG_USB_SERIAL_MCT_U232=m +CONFIG_USB_SERIAL_MOS7720=m +CONFIG_USB_SERIAL_MOS7840=m +CONFIG_USB_SERIAL_NAVMAN=m +CONFIG_USB_SERIAL_PL2303=m +# CONFIG_USB_SERIAL_OTI6858 is not set +CONFIG_USB_SERIAL_HP4X=m +CONFIG_USB_SERIAL_SAFE=m +# CONFIG_USB_SERIAL_SAFE_PADDED is not set +CONFIG_USB_SERIAL_SIERRAWIRELESS=m +CONFIG_USB_SERIAL_TI=m +CONFIG_USB_SERIAL_CYBERJACK=m +CONFIG_USB_SERIAL_XIRCOM=m +CONFIG_USB_SERIAL_OPTION=m +CONFIG_USB_SERIAL_OMNINET=m +# CONFIG_USB_SERIAL_DEBUG is not set +CONFIG_USB_EZUSB=y + +# +# USB Miscellaneous drivers +# +CONFIG_USB_EMI62=m +CONFIG_USB_EMI26=m +CONFIG_USB_ADUTUX=m +CONFIG_USB_AUERSWALD=m +CONFIG_USB_RIO500=m +CONFIG_USB_LEGOTOWER=m +CONFIG_USB_LCD=m +# CONFIG_USB_BERRY_CHARGE is not set +CONFIG_USB_LED=m +CONFIG_USB_CYPRESS_CY7C63=m +CONFIG_USB_CYTHERM=m +CONFIG_USB_PHIDGET=m +CONFIG_USB_PHIDGETKIT=m +CONFIG_USB_PHIDGETMOTORCONTROL=m +CONFIG_USB_PHIDGETSERVO=m +CONFIG_USB_IDMOUSE=m +CONFIG_USB_FTDI_ELAN=m +CONFIG_USB_APPLEDISPLAY=m +CONFIG_USB_SISUSBVGA=m +# CONFIG_USB_SISUSBVGA_CON is not set +CONFIG_USB_LD=m +CONFIG_USB_TRANCEVIBRATOR=m +# CONFIG_USB_IOWARRIOR is not set +CONFIG_USB_TEST=m + +# +# USB DSL modem support +# +CONFIG_USB_ATM=m +CONFIG_USB_SPEEDTOUCH=m +CONFIG_USB_CXACRU=m +CONFIG_USB_UEAGLEATM=m +CONFIG_USB_XUSBATM=m + +# +# USB Gadget Support +# +CONFIG_USB_GADGET=m +# CONFIG_USB_GADGET_DEBUG_FILES is not set +CONFIG_USB_GADGET_SELECTED=y +# CONFIG_USB_GADGET_AMD5536UDC is not set +# CONFIG_USB_GADGET_FSL_USB2 is not set +CONFIG_USB_GADGET_NET2280=y +CONFIG_USB_NET2280=m +# CONFIG_USB_GADGET_PXA2XX is not set +# CONFIG_USB_GADGET_M66592 is not set +# CONFIG_USB_GADGET_GOKU is not set +# CONFIG_USB_GADGET_LH7A40X is not set +# CONFIG_USB_GADGET_OMAP is not set +# CONFIG_USB_GADGET_S3C2410 is not set +# CONFIG_USB_GADGET_AT91 is not set +# CONFIG_USB_GADGET_DUMMY_HCD is not set +CONFIG_USB_GADGET_DUALSPEED=y +CONFIG_USB_ZERO=m +CONFIG_USB_ETH=m +CONFIG_USB_ETH_RNDIS=y +CONFIG_USB_GADGETFS=m +CONFIG_USB_FILE_STORAGE=m +# CONFIG_USB_FILE_STORAGE_TEST is not set +CONFIG_USB_G_SERIAL=m +CONFIG_USB_MIDI_GADGET=m +CONFIG_MMC=m +# CONFIG_MMC_DEBUG is not set +# CONFIG_MMC_UNSAFE_RESUME is not set + +# +# MMC/SD Card Drivers +# +CONFIG_MMC_BLOCK=m +CONFIG_MMC_BLOCK_BOUNCE=y + +# +# MMC/SD Host Controller Drivers +# +CONFIG_MMC_SDHCI=m +CONFIG_MMC_TIFM_SD=m +CONFIG_NEW_LEDS=y +CONFIG_LEDS_CLASS=m + +# +# LED drivers +# + +# +# LED Triggers +# +# CONFIG_LEDS_TRIGGERS is not set +CONFIG_INFINIBAND=m +CONFIG_INFINIBAND_USER_MAD=m +CONFIG_INFINIBAND_USER_ACCESS=m +CONFIG_INFINIBAND_USER_MEM=y +CONFIG_INFINIBAND_ADDR_TRANS=y +CONFIG_INFINIBAND_MTHCA=m +CONFIG_INFINIBAND_MTHCA_DEBUG=y +CONFIG_INFINIBAND_AMSO1100=m +CONFIG_INFINIBAND_AMSO1100_DEBUG=y +# CONFIG_MLX4_INFINIBAND is not set +CONFIG_INFINIBAND_IPOIB=m +# CONFIG_INFINIBAND_IPOIB_CM is not set +CONFIG_INFINIBAND_IPOIB_DEBUG=y +# CONFIG_INFINIBAND_IPOIB_DEBUG_DATA is not set +CONFIG_INFINIBAND_SRP=m +CONFIG_INFINIBAND_ISER=m +CONFIG_RTC_LIB=m +CONFIG_RTC_CLASS=m + +# +# RTC interfaces +# +CONFIG_RTC_INTF_SYSFS=y +CONFIG_RTC_INTF_PROC=y +CONFIG_RTC_INTF_DEV=y +CONFIG_RTC_INTF_DEV_UIE_EMUL=y +CONFIG_RTC_DRV_TEST=m + +# +# I2C RTC drivers +# +CONFIG_RTC_DRV_DS1307=m +CONFIG_RTC_DRV_DS1672=m +# CONFIG_RTC_DRV_MAX6900 is not set +CONFIG_RTC_DRV_RS5C372=m +CONFIG_RTC_DRV_ISL1208=m +CONFIG_RTC_DRV_X1205=m +CONFIG_RTC_DRV_PCF8563=m +CONFIG_RTC_DRV_PCF8583=m +# CONFIG_RTC_DRV_M41T80 is not set + +# +# SPI RTC drivers +# +CONFIG_RTC_DRV_RS5C348=m +CONFIG_RTC_DRV_MAX6902=m + +# +# Platform RTC drivers +# +# CONFIG_RTC_DRV_CMOS is not set +CONFIG_RTC_DRV_DS1553=m +# CONFIG_RTC_DRV_STK17TA8 is not set +CONFIG_RTC_DRV_DS1742=m +CONFIG_RTC_DRV_M48T86=m +# CONFIG_RTC_DRV_M48T59 is not set +CONFIG_RTC_DRV_V3020=m + +# +# on-CPU RTC drivers +# + +# +# DMA Engine support +# +CONFIG_DMA_ENGINE=y + +# +# DMA Clients +# +CONFIG_NET_DMA=y + +# +# DMA Devices +# +CONFIG_INTEL_IOATDMA=m +# CONFIG_AUXDISPLAY is not set + +# +# Userspace I/O +# +# CONFIG_UIO is not set + +# +# File systems +# +CONFIG_EXT2_FS=m +CONFIG_EXT2_FS_XATTR=y +CONFIG_EXT2_FS_POSIX_ACL=y +CONFIG_EXT2_FS_SECURITY=y +# CONFIG_EXT2_FS_XIP is not set +CONFIG_EXT3_FS=m +CONFIG_EXT3_FS_XATTR=y +CONFIG_EXT3_FS_POSIX_ACL=y +CONFIG_EXT3_FS_SECURITY=y +# CONFIG_EXT4DEV_FS is not set +CONFIG_JBD=m +# CONFIG_JBD_DEBUG is not set +CONFIG_FS_MBCACHE=m +CONFIG_REISERFS_FS=m +# CONFIG_REISERFS_CHECK is not set +# CONFIG_REISERFS_PROC_INFO is not set +CONFIG_REISERFS_FS_XATTR=y +CONFIG_REISERFS_FS_POSIX_ACL=y +CONFIG_REISERFS_FS_SECURITY=y +CONFIG_JFS_FS=m +CONFIG_JFS_POSIX_ACL=y +CONFIG_JFS_SECURITY=y +# CONFIG_JFS_DEBUG is not set +CONFIG_JFS_STATISTICS=y +CONFIG_FS_POSIX_ACL=y +CONFIG_XFS_FS=m +CONFIG_XFS_QUOTA=y +CONFIG_XFS_SECURITY=y +CONFIG_XFS_POSIX_ACL=y +CONFIG_XFS_RT=y +# CONFIG_GFS2_FS is not set +# CONFIG_OCFS2_FS is not set +CONFIG_MINIX_FS=m +CONFIG_ROMFS_FS=m +CONFIG_INOTIFY=y +CONFIG_INOTIFY_USER=y +CONFIG_QUOTA=y +CONFIG_QFMT_V1=m +CONFIG_QFMT_V2=m +CONFIG_QUOTACTL=y +CONFIG_DNOTIFY=y +CONFIG_AUTOFS_FS=m +CONFIG_AUTOFS4_FS=m +CONFIG_FUSE_FS=m + +# +# CD-ROM/DVD Filesystems +# +CONFIG_ISO9660_FS=m +CONFIG_JOLIET=y +CONFIG_ZISOFS=y +CONFIG_UDF_FS=m +CONFIG_UDF_NLS=y + +# +# DOS/FAT/NT Filesystems +# +CONFIG_FAT_FS=m +CONFIG_MSDOS_FS=m +CONFIG_VFAT_FS=m +CONFIG_FAT_DEFAULT_CODEPAGE=437 +CONFIG_FAT_DEFAULT_IOCHARSET="iso8859-1" +CONFIG_NTFS_FS=m +# CONFIG_NTFS_DEBUG is not set +# CONFIG_NTFS_RW is not set + +# +# Pseudo filesystems +# +CONFIG_PROC_FS=y +CONFIG_PROC_KCORE=y +CONFIG_PROC_SYSCTL=y +CONFIG_SYSFS=y +CONFIG_TMPFS=y +# CONFIG_TMPFS_POSIX_ACL is not set +# CONFIG_HUGETLB_PAGE is not set +CONFIG_RAMFS=y +CONFIG_CONFIGFS_FS=m + +# +# Miscellaneous filesystems +# +CONFIG_ADFS_FS=m +# CONFIG_ADFS_FS_RW is not set +CONFIG_AFFS_FS=m +CONFIG_ECRYPT_FS=m +CONFIG_HFS_FS=m +CONFIG_HFSPLUS_FS=m +CONFIG_BEFS_FS=m +# CONFIG_BEFS_DEBUG is not set +CONFIG_BFS_FS=m +CONFIG_EFS_FS=m +CONFIG_JFFS2_FS=m +CONFIG_JFFS2_FS_DEBUG=0 +CONFIG_JFFS2_FS_WRITEBUFFER=y +# CONFIG_JFFS2_SUMMARY is not set +# CONFIG_JFFS2_FS_XATTR is not set +# CONFIG_JFFS2_COMPRESSION_OPTIONS is not set +CONFIG_JFFS2_ZLIB=y +CONFIG_JFFS2_RTIME=y +# CONFIG_JFFS2_RUBIN is not set +CONFIG_CRAMFS=y +CONFIG_VXFS_FS=m +CONFIG_HPFS_FS=m +CONFIG_QNX4FS_FS=m +CONFIG_SYSV_FS=m +CONFIG_UFS_FS=m +# CONFIG_UFS_FS_WRITE is not set +# CONFIG_UFS_DEBUG is not set + +# +# Network File Systems +# +CONFIG_NFS_FS=m +CONFIG_NFS_V3=y +# CONFIG_NFS_V3_ACL is not set +CONFIG_NFS_V4=y +CONFIG_NFS_DIRECTIO=y +CONFIG_NFSD=m +CONFIG_NFSD_V3=y +# CONFIG_NFSD_V3_ACL is not set +CONFIG_NFSD_V4=y +CONFIG_NFSD_TCP=y +CONFIG_LOCKD=m +CONFIG_LOCKD_V4=y +CONFIG_EXPORTFS=m +CONFIG_NFS_COMMON=y +CONFIG_SUNRPC=m +CONFIG_SUNRPC_GSS=m +# CONFIG_SUNRPC_BIND34 is not set +CONFIG_RPCSEC_GSS_KRB5=m +CONFIG_RPCSEC_GSS_SPKM3=m +CONFIG_SMB_FS=m +# CONFIG_SMB_NLS_DEFAULT is not set +CONFIG_CIFS=m +# CONFIG_CIFS_STATS is not set +# CONFIG_CIFS_WEAK_PW_HASH is not set +# CONFIG_CIFS_XATTR is not set +# CONFIG_CIFS_DEBUG2 is not set +# CONFIG_CIFS_EXPERIMENTAL is not set +CONFIG_NCP_FS=m +CONFIG_NCPFS_PACKET_SIGNING=y +CONFIG_NCPFS_IOCTL_LOCKING=y +CONFIG_NCPFS_STRONG=y +CONFIG_NCPFS_NFS_NS=y +CONFIG_NCPFS_OS2_NS=y +# CONFIG_NCPFS_SMALLDOS is not set +CONFIG_NCPFS_NLS=y +CONFIG_NCPFS_EXTRAS=y +CONFIG_CODA_FS=m +# CONFIG_CODA_FS_OLD_API is not set +CONFIG_AFS_FS=m +# CONFIG_AFS_DEBUG is not set + +# +# Partition Types +# +CONFIG_PARTITION_ADVANCED=y +CONFIG_ACORN_PARTITION=y +# CONFIG_ACORN_PARTITION_CUMANA is not set +# CONFIG_ACORN_PARTITION_EESOX is not set +CONFIG_ACORN_PARTITION_ICS=y +# CONFIG_ACORN_PARTITION_ADFS is not set +# CONFIG_ACORN_PARTITION_POWERTEC is not set +CONFIG_ACORN_PARTITION_RISCIX=y +CONFIG_OSF_PARTITION=y +CONFIG_AMIGA_PARTITION=y +CONFIG_ATARI_PARTITION=y +CONFIG_MAC_PARTITION=y +CONFIG_MSDOS_PARTITION=y +CONFIG_BSD_DISKLABEL=y +CONFIG_MINIX_SUBPARTITION=y +CONFIG_SOLARIS_X86_PARTITION=y +CONFIG_UNIXWARE_DISKLABEL=y +CONFIG_LDM_PARTITION=y +# CONFIG_LDM_DEBUG is not set +CONFIG_SGI_PARTITION=y +CONFIG_ULTRIX_PARTITION=y +CONFIG_SUN_PARTITION=y +CONFIG_KARMA_PARTITION=y +CONFIG_EFI_PARTITION=y +# CONFIG_SYSV68_PARTITION is not set + +# +# Native Language Support +# +CONFIG_NLS=y +CONFIG_NLS_DEFAULT="cp437" +CONFIG_NLS_CODEPAGE_437=m +CONFIG_NLS_CODEPAGE_737=m +CONFIG_NLS_CODEPAGE_775=m +CONFIG_NLS_CODEPAGE_850=m +CONFIG_NLS_CODEPAGE_852=m +CONFIG_NLS_CODEPAGE_855=m +CONFIG_NLS_CODEPAGE_857=m +CONFIG_NLS_CODEPAGE_860=m +CONFIG_NLS_CODEPAGE_861=m +CONFIG_NLS_CODEPAGE_862=m +CONFIG_NLS_CODEPAGE_863=m +CONFIG_NLS_CODEPAGE_864=m +CONFIG_NLS_CODEPAGE_865=m +CONFIG_NLS_CODEPAGE_866=m +CONFIG_NLS_CODEPAGE_869=m +CONFIG_NLS_CODEPAGE_936=m +CONFIG_NLS_CODEPAGE_950=m +CONFIG_NLS_CODEPAGE_932=m +CONFIG_NLS_CODEPAGE_949=m +CONFIG_NLS_CODEPAGE_874=m +CONFIG_NLS_ISO8859_8=m +CONFIG_NLS_CODEPAGE_1250=m +CONFIG_NLS_CODEPAGE_1251=m +CONFIG_NLS_ASCII=m +CONFIG_NLS_ISO8859_1=m +CONFIG_NLS_ISO8859_2=m +CONFIG_NLS_ISO8859_3=m +CONFIG_NLS_ISO8859_4=m +CONFIG_NLS_ISO8859_5=m +CONFIG_NLS_ISO8859_6=m +CONFIG_NLS_ISO8859_7=m +CONFIG_NLS_ISO8859_9=m +CONFIG_NLS_ISO8859_13=m +CONFIG_NLS_ISO8859_14=m +CONFIG_NLS_ISO8859_15=m +CONFIG_NLS_KOI8_R=m +CONFIG_NLS_KOI8_U=m +CONFIG_NLS_UTF8=m + +# +# Distributed Lock Manager +# +CONFIG_DLM=m +# CONFIG_DLM_DEBUG is not set + +# +# Profiling support +# +CONFIG_PROFILING=y +CONFIG_OPROFILE=m + +# +# Kernel hacking +# +CONFIG_TRACE_IRQFLAGS_SUPPORT=y +# CONFIG_PRINTK_TIME is not set +# CONFIG_ENABLE_MUST_CHECK is not set +CONFIG_MAGIC_SYSRQ=y +# CONFIG_UNUSED_SYMBOLS is not set +# CONFIG_DEBUG_FS is not set +# CONFIG_HEADERS_CHECK is not set +# CONFIG_DEBUG_KERNEL is not set +# CONFIG_CROSSCOMPILE is not set +CONFIG_CMDLINE="" +CONFIG_SYS_SUPPORTS_KGDB=y + +# +# Security options +# +CONFIG_KEYS=y +# CONFIG_KEYS_DEBUG_PROC_KEYS is not set +CONFIG_SECURITY=y +CONFIG_SECURITY_NETWORK=y +# CONFIG_SECURITY_NETWORK_XFRM is not set +CONFIG_SECURITY_CAPABILITIES=m +CONFIG_SECURITY_ROOTPLUG=m +CONFIG_SECURITY_SELINUX=y +CONFIG_SECURITY_SELINUX_BOOTPARAM=y +CONFIG_SECURITY_SELINUX_BOOTPARAM_VALUE=0 +CONFIG_SECURITY_SELINUX_DISABLE=y +CONFIG_SECURITY_SELINUX_DEVELOP=y +CONFIG_SECURITY_SELINUX_AVC_STATS=y +CONFIG_SECURITY_SELINUX_CHECKREQPROT_VALUE=1 +# CONFIG_SECURITY_SELINUX_ENABLE_SECMARK_DEFAULT is not set +# CONFIG_SECURITY_SELINUX_POLICYDB_VERSION_MAX is not set +CONFIG_XOR_BLOCKS=m +CONFIG_ASYNC_CORE=m +CONFIG_ASYNC_MEMCPY=m +CONFIG_ASYNC_XOR=m +CONFIG_CRYPTO=y +CONFIG_CRYPTO_ALGAPI=y +CONFIG_CRYPTO_BLKCIPHER=m +CONFIG_CRYPTO_HASH=y +CONFIG_CRYPTO_MANAGER=y +CONFIG_CRYPTO_HMAC=y +# CONFIG_CRYPTO_XCBC is not set +CONFIG_CRYPTO_NULL=m +CONFIG_CRYPTO_MD4=m +CONFIG_CRYPTO_MD5=y +CONFIG_CRYPTO_SHA1=m +CONFIG_CRYPTO_SHA256=m +CONFIG_CRYPTO_SHA512=m +CONFIG_CRYPTO_WP512=m +CONFIG_CRYPTO_TGR192=m +# CONFIG_CRYPTO_GF128MUL is not set +CONFIG_CRYPTO_ECB=m +CONFIG_CRYPTO_CBC=m +CONFIG_CRYPTO_PCBC=m +# CONFIG_CRYPTO_LRW is not set +# CONFIG_CRYPTO_CRYPTD is not set +CONFIG_CRYPTO_DES=m +# CONFIG_CRYPTO_FCRYPT is not set +CONFIG_CRYPTO_BLOWFISH=m +CONFIG_CRYPTO_TWOFISH=m +CONFIG_CRYPTO_TWOFISH_COMMON=m +CONFIG_CRYPTO_SERPENT=m +CONFIG_CRYPTO_AES=m +CONFIG_CRYPTO_CAST5=m +CONFIG_CRYPTO_CAST6=m +CONFIG_CRYPTO_TEA=m +CONFIG_CRYPTO_ARC4=m +CONFIG_CRYPTO_KHAZAD=m +CONFIG_CRYPTO_ANUBIS=m +CONFIG_CRYPTO_DEFLATE=m +CONFIG_CRYPTO_MICHAEL_MIC=m +CONFIG_CRYPTO_CRC32C=m +# CONFIG_CRYPTO_CAMELLIA is not set +CONFIG_CRYPTO_TEST=m +CONFIG_CRYPTO_HW=y + +# +# Library routines +# +CONFIG_BITREVERSE=y +CONFIG_CRC_CCITT=m +CONFIG_CRC16=m +# CONFIG_CRC_ITU_T is not set +CONFIG_CRC32=y +# CONFIG_CRC7 is not set +CONFIG_LIBCRC32C=m +CONFIG_AUDIT_GENERIC=y +CONFIG_ZLIB_INFLATE=y +CONFIG_ZLIB_DEFLATE=m +CONFIG_REED_SOLOMON=m +CONFIG_REED_SOLOMON_DEC16=y +CONFIG_TEXTSEARCH=y +CONFIG_TEXTSEARCH_KMP=m +CONFIG_TEXTSEARCH_BM=m +CONFIG_TEXTSEARCH_FSM=m +CONFIG_PLIST=y +CONFIG_HAS_IOMEM=y +CONFIG_HAS_IOPORT=y +CONFIG_HAS_DMA=y +CONFIG_CHECK_SIGNATURE=y --Boundary-00=_G+NAHqScz0T7Yf7-- From macro@linux-mips.org Mon Oct 1 13:24:11 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 01 Oct 2007 13:24:19 +0100 (BST) Received: from cerber.ds.pg.gda.pl ([153.19.208.18]:40102 "EHLO cerber.ds.pg.gda.pl") by ftp.linux-mips.org with ESMTP id S20023622AbXJAMYL (ORCPT ); Mon, 1 Oct 2007 13:24:11 +0100 Received: from localhost (unknown [127.0.0.17]) by cerber.ds.pg.gda.pl (Postfix) with ESMTP id 893BE400F9; Mon, 1 Oct 2007 14:24:11 +0200 (CEST) X-Virus-Scanned: amavisd-new at cerber.ds.pg.gda.pl Received: from cerber.ds.pg.gda.pl ([153.19.208.18]) by localhost (cerber.ds.pg.gda.pl [153.19.208.18]) (amavisd-new, port 10024) with ESMTP id jw-SqJE5WLew; Mon, 1 Oct 2007 14:24:05 +0200 (CEST) Received: from piorun.ds.pg.gda.pl (piorun.ds.pg.gda.pl [153.19.208.8]) by cerber.ds.pg.gda.pl (Postfix) with ESMTP id D559C40040; Mon, 1 Oct 2007 14:24:05 +0200 (CEST) Received: from blysk.ds.pg.gda.pl (macro@blysk.ds.pg.gda.pl [153.19.208.6]) by piorun.ds.pg.gda.pl (8.13.8/8.13.8) with ESMTP id l91CO81V000438; Mon, 1 Oct 2007 14:24:08 +0200 Date: Mon, 1 Oct 2007 13:24:04 +0100 (BST) From: "Maciej W. Rozycki" To: Ralf Baechle cc: linux-mips@linux-mips.org Subject: [PATCH][URGENT] kernel/vmlinux.lds.S: Handle note sections Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: ClamAV 0.91.2/4445/Mon Oct 1 10:32:46 2007 on piorun.ds.pg.gda.pl X-Virus-Status: Clean Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 16767 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: macro@linux-mips.org Precedence: bulk X-list: linux-mips Store any note sections after the exception tables like the other architectures do. This is required for .note.gnu.build-id emitted from binutils 2.18 onwards if nothing else. Signed-off-by: Maciej W. Rozycki --- Ralf, Without it a binary with a layout like this is created: $ readelf -l vmlinux Elf file type is EXEC (Executable file) Entry point 0xffffffff804cc000 There are 3 program headers, starting at offset 64 Program Headers: Type Offset VirtAddr PhysAddr FileSiz MemSiz Flags Align LOAD 0x00000000000000e8 0x0000000000000000 0x0000000000000000 0x0000000000000024 0x0000000000000024 R 4 LOAD 0x0000000000004000 0xffffffff80040000 0xffffffff80040000 0x00000000004bead8 0x0000000000642980 RWE 4000 NOTE 0x00000000000000e8 0x0000000000000000 0x0000000000000000 0x0000000000000024 0x0000000000000024 R 4 Section to Segment mapping: Segment Sections... 00 .note.gnu.build-id 01 .text __ex_table __dbe_table .rodata __ksymtab __ksymtab_gpl __ksymtab_strings __param .data .data.cacheline_aligned .init.text .init.data .init.setup .initcall.init .con_initcall.init .exit.text .bss 02 .note.gnu.build-id which does not quite work as the first segment is in the KUSEG. Please apply ASAP. Maciej patch-mips-2.6.23-rc5-20070904-mips-notes-0 diff -up --recursive --new-file linux-mips-2.6.23-rc5-20070904.macro/arch/mips/kernel/vmlinux.lds.S linux-mips-2.6.23-rc5-20070904/arch/mips/kernel/vmlinux.lds.S --- linux-mips-2.6.23-rc5-20070904.macro/arch/mips/kernel/vmlinux.lds.S 2007-09-04 04:55:19.000000000 +0000 +++ linux-mips-2.6.23-rc5-20070904/arch/mips/kernel/vmlinux.lds.S 2007-10-01 04:16:44.000000000 +0000 @@ -45,6 +45,8 @@ SECTIONS __dbe_table : { *(__dbe_table) } __stop___dbe_table = .; + NOTES + RODATA /* writeable */ From ralf@linux-mips.org Mon Oct 1 14:11:03 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 01 Oct 2007 14:11:06 +0100 (BST) Received: from localhost.localdomain ([127.0.0.1]:16768 "EHLO dl5rb.ham-radio-op.net") by ftp.linux-mips.org with ESMTP id S20023873AbXJANLD (ORCPT ); Mon, 1 Oct 2007 14:11:03 +0100 Received: from denk.linux-mips.net (denk.linux-mips.net [127.0.0.1]) by dl5rb.ham-radio-op.net (8.14.1/8.13.8) with ESMTP id l91DB3uN012677; Mon, 1 Oct 2007 14:11:03 +0100 Received: (from ralf@localhost) by denk.linux-mips.net (8.14.1/8.14.1/Submit) id l91DB3KA012676; Mon, 1 Oct 2007 14:11:03 +0100 Date: Mon, 1 Oct 2007 14:11:03 +0100 From: Ralf Baechle To: "Maciej W. Rozycki" Cc: linux-mips@linux-mips.org Subject: Re: [PATCH][URGENT] kernel/vmlinux.lds.S: Handle note sections Message-ID: <20071001131103.GA10452@linux-mips.org> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.14 (2007-02-12) Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 16768 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: ralf@linux-mips.org Precedence: bulk X-list: linux-mips On Mon, Oct 01, 2007 at 01:24:04PM +0100, Maciej W. Rozycki wrote: > Store any note sections after the exception tables like the other > architectures do. This is required for .note.gnu.build-id emitted from > binutils 2.18 onwards if nothing else. Thanks for looking into this. I knew the problem but didn't get around to looking into it yet ... Patch applied. Ralf From khali@linux-fr.org Mon Oct 1 14:26:46 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 01 Oct 2007 14:26:55 +0100 (BST) Received: from smtp-101-monday.nerim.net ([62.4.16.101]:22762 "EHLO kraid.nerim.net") by ftp.linux-mips.org with ESMTP id S20023829AbXJAN0q (ORCPT ); Mon, 1 Oct 2007 14:26:46 +0100 Received: from hyperion.delvare (jdelvare.pck.nerim.net [62.212.121.182]) by kraid.nerim.net (Postfix) with ESMTP id 3F836CF12E; Mon, 1 Oct 2007 15:26:13 +0200 (CEST) Date: Mon, 1 Oct 2007 15:26:13 +0200 From: Jean Delvare To: Mark Zhan Cc: i2c@lm-sensors.org, linux-mips@linux-mips.org, rtc-linux@googlegroups.com, a.zummo@towertech.it, ralf@linux-mips.org Subject: Re: [i2c] [PATCH 1/4] i2c sibyte adapter driver is rewritten with 2.6.x style binding model Message-ID: <20071001152613.4c2be23c@hyperion.delvare> In-Reply-To: <46FF7262.9060802@windriver.com> References: <46FF7262.9060802@windriver.com> X-Mailer: Sylpheed-Claws 2.5.5 (GTK+ 2.10.6; x86_64-suse-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 16769 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: khali@linux-fr.org Precedence: bulk X-list: linux-mips Hi Mark, On Sun, 30 Sep 2007 17:54:42 +0800, Mark Zhan wrote: > This patch re-writes the sibyte i2c adapter driver with 2.6.x style > binding model. > > Signed-off-by: Mark Zhan > --- > drivers/i2c/busses/i2c-sibyte.c | 150 ++++++++++++++-------------------------- > 1 file changed, 55 insertions(+), 95 deletions(-) > > --- a/drivers/i2c/busses/i2c-sibyte.c > +++ b/drivers/i2c/busses/i2c-sibyte.c > @@ -1,4 +1,5 @@ > /* > + * Copyright (C) 2007 Wind River Inc. Mark Zhan > * Copyright (C) 2004 Steven J. Hill > * Copyright (C) 2001,2002,2003 Broadcom Corporation > * Copyright (C) 1995-2000 Simon G. Vogl Patch doesn't apply. It seems that your mailer added a leading space on all context lines? Please address the problem and resend the patch(es). I volunteer to review patches 1 and 2, once I can apply them. -- Jean Delvare From khali@linux-fr.org Mon Oct 1 15:00:09 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 01 Oct 2007 15:00:18 +0100 (BST) Received: from smtp-101-monday.nerim.net ([62.4.16.101]:64481 "EHLO kraid.nerim.net") by ftp.linux-mips.org with ESMTP id S20023988AbXJAOAJ (ORCPT ); Mon, 1 Oct 2007 15:00:09 +0100 Received: from hyperion.delvare (jdelvare.pck.nerim.net [62.212.121.182]) by kraid.nerim.net (Postfix) with ESMTP id 7026ACF0A7; Mon, 1 Oct 2007 15:59:38 +0200 (CEST) Date: Mon, 1 Oct 2007 15:59:38 +0200 From: Jean Delvare To: Mark Zhan Cc: i2c@lm-sensors.org, linux-mips@linux-mips.org, rtc-linux@googlegroups.com, a.zummo@towertech.it, ralf@linux-mips.org Subject: Re: [i2c] [PATCH 3/4] RTC: add Xicor 1241 driver Message-ID: <20071001155938.0590fc3a@hyperion.delvare> In-Reply-To: <46FF7279.3020102@windriver.com> References: <46FF7279.3020102@windriver.com> X-Mailer: Sylpheed-Claws 2.5.5 (GTK+ 2.10.6; x86_64-suse-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 16770 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: khali@linux-fr.org Precedence: bulk X-list: linux-mips Hi Mark, On Sun, 30 Sep 2007 17:55:05 +0800, Mark Zhan wrote: > This patch add the Xicor 1241 RTC driver which is used in > MIPS Sibyte 1250/1480 boards. So this chip is using two-byte register addressing, which isn't compatible with SMBus. Which explains why the register reads and writes in your driver look strange. I don't think it's quite correct. > +/* > + * Register Offset > + */ > +#define X1241_SEC 0x30 /* Seconds */ > +#define X1241_MIN 0x31 /* Minutes */ > +#define X1241_HOUR 0x32 /* Hours */ > +#define X1241_MDAY 0x33 /* Day of month */ > +#define X1241_MON 0x34 /* Month */ > +#define X1241_YEAR 0x35 /* Year */ > +#define X1241_WDAY 0x36 /* Day of Week */ > +#define X1241_Y2K 0x37 /* Year 2K */ > +#define X1241_SR 0x3F /* Status register */ > + > +DEFINE_SPINLOCK(xicor1241_lock); > + > +static int xicor1241_get_time(struct device *dev, struct rtc_time *tm) > +{ > + struct i2c_client *client = to_i2c_client(dev); > + unsigned int y2k, year, mon, mday, wday, hour, min, sec; > + unsigned long flags; > + > + spin_lock_irqsave(&xicor1241_lock, flags); > + > + i2c_smbus_write_byte_data(client, X1241_SEC, X1241_SEC); If I read the datasheet properly, this should be: i2c_smbus_write_byte_data(client, 0, X1241_SEC); The SC register is at 0x0030, not 0x3030. > + sec = i2c_smbus_read_byte_data(client, X1241_SEC); > + min = i2c_smbus_read_byte_data(client, X1241_MIN); > + hour = i2c_smbus_read_byte_data(client, X1241_HOUR); > + mday = i2c_smbus_read_byte_data(client, X1241_MDAY); > + mon = i2c_smbus_read_byte_data(client, X1241_MON); > + year = i2c_smbus_read_byte_data(client, X1241_YEAR); > + wday = i2c_smbus_read_byte_data(client, X1241_WDAY); > + y2k = i2c_smbus_read_byte_data(client, X1241_Y2K); You are using the "Current Address Read" mode here, right? If so, you aren't supposed to send any address information at all, i.e. you should use i2c_smbus_read_byte() instead of i2c_smbus_read_byte_data(). You are probably just lucky that the chip ignores the extra byte you're sending. > (...) > +static int xicor1241_set_time(struct device *dev, struct rtc_time *tm) > +{ > (...) > + /* unlock writes to the CCR */ > + i2c_smbus_write_word_data(client, X1241_SR, > + (X1241_SR_WEL << 8) | X1241_SR); > + i2c_smbus_write_word_data(client, X1241_SR, > + ((X1241_SR_WEL | X1241_SR_RWEL) << 8) | X1241_SR); > + > + i2c_smbus_write_word_data(client, X1241_SEC, (sec << 8) | X1241_SEC); > + i2c_smbus_write_word_data(client, X1241_MIN, (min << 8) | X1241_MIN); > + i2c_smbus_write_word_data(client, X1241_HOUR, (hour << 8) | X1241_HOUR); > + i2c_smbus_write_word_data(client, X1241_MDAY, (mday << 8) | X1241_MDAY); > + i2c_smbus_write_word_data(client, X1241_WDAY, (wday << 8) | X1241_WDAY); > + i2c_smbus_write_word_data(client, X1241_MON, (mon << 8) | X1241_MON); > + i2c_smbus_write_word_data(client, X1241_YEAR, (year << 8) | X1241_YEAR); > + i2c_smbus_write_word_data(client, X1241_Y2K, (y2k << 8) | X1241_Y2K); > + > + i2c_smbus_write_word_data(client, X1241_SR, (0 << 8) | X1241_SR); Here again I am surprised. I expected: i2c_smbus_write_word_data(client, 0, (sec << 8) | X1241_SEC); So that you write to register 0x0030, not 0x3030. Same for all the other register writes. Or am I misreading the datasheet? > + > + spin_unlock_irqrestore(&xicor1241_lock, flags); > + return 0; > +} > + > +static const struct rtc_class_ops xicor1241_rtc_ops = { > + .read_time = xicor1241_get_time, > + .set_time = xicor1241_set_time, > +}; > + > +static int __devinit xicor1241_rtc_probe(struct i2c_client *client) > +{ > + struct rtc_device *rtc; > + > + if (!i2c_check_functionality(client->adapter, I2C_FUNC_SMBUS_BYTE_DATA)) { > + dev_dbg(&client->dev, "I2C adapter function check failure!\n"); > + return -ENODEV; > + } This check isn't sufficient, you must check for I2C_FUNC_SMBUS_WRITE_WORD_DATA as well, and possibly I2C_FUNC_SMBUS_READ_BYTE if my comment above is correct. -- Jean Delvare From anemo@mba.ocn.ne.jp Mon Oct 1 16:04:41 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 01 Oct 2007 16:04:49 +0100 (BST) Received: from mba.ocn.ne.jp ([122.1.235.107]:46033 "HELO smtp.mba.ocn.ne.jp") by ftp.linux-mips.org with SMTP id S20024075AbXJAPEl (ORCPT ); Mon, 1 Oct 2007 16:04:41 +0100 Received: from localhost (p1055-ipad306funabasi.chiba.ocn.ne.jp [123.217.171.55]) by smtp.mba.ocn.ne.jp (Postfix) with ESMTP id 41665F169; Tue, 2 Oct 2007 00:04:35 +0900 (JST) Date: Tue, 02 Oct 2007 00:06:16 +0900 (JST) Message-Id: <20071002.000616.31638007.anemo@mba.ocn.ne.jp> To: rongkai.zhan@windriver.com Cc: i2c@lm-sensors.org, linux-mips@linux-mips.org, rtc-linux@googlegroups.com, ralf@linux-mips.org, a.zummo@towertech.it Subject: Re: [PATCH 2/4] RTC: make m41t80 driver can work with the SMBus adapters From: Atsushi Nemoto In-Reply-To: <46FF726E.4020200@windriver.com> References: <46FF726E.4020200@windriver.com> X-Fingerprint: 6ACA 1623 39BD 9A94 9B1A B746 CA77 FE94 2874 D52F X-Pgp-Public-Key: http://wwwkeys.pgp.net/pks/lookup?op=get&search=0x2874D52F X-Mailer: Mew version 5.2 on Emacs 21.4 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 16771 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: anemo@mba.ocn.ne.jp Precedence: bulk X-list: linux-mips On Sun, 30 Sep 2007 17:54:54 +0800, Mark Zhan wrote: > This patch makes m41t80 RTC driver also can work with the SMBus adapters, > which doesn't i2c_transfer() method. > > Signed-off-by: Mark Zhan As Jean already said, your mailer corrupted your patch. Also, please keep in mind the 80 column rule. > +static int m41t80_i2c_read(struct i2c_client *client, struct i2c_msg *msgs, int num) > +{ > + int i, rc; > + u8 dt_addr = msgs[0].buf[0]; > + > + if (num < 2) > + return -1; > + > + if (i2c_check_functionality(client->adapter, I2C_FUNC_I2C) && > + i2c_transfer(client->adapter, msgs, 2) < 0) { > + dev_err(&client->dev, "read error\n"); > + return -EIO; > + } else { > + for (i = 0; i < msgs[1].len; i++) { > + rc = i2c_smbus_read_byte_data(client, dt_addr + i); > + if (rc < 0) > + return -EIO; > + msgs[1].buf[i] = (u8)rc; > + } > + } > + > + return 0; > +} You must ensure time values are consistent. The RTC might update its time data between each I2C transfer. It seems the original rtc_m41t81.c:m41t81_get_time() tries to solve this issue by reading sec/min in loop, but it would not be enough. For example, if the function was called at 23:59:59, the sec (and min) might wrap just before reading the hour, then you might get 00:59:59. The old m41t00 i2c driver once did it right with smbus, but current m41t00 driver (and rtc-m41t80 driver) dropped that feature a while ago. You can see the old code at: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=blob;f=drivers/i2c/chips/m41t00.c;hb=e931b8d8a428f87e6ea488d2fd80007bb66b3ea8 > +static int m41t80_i2c_write(struct i2c_client *client, struct i2c_msg *msg) > +{ > + int i, rc; > + u8 *wbuf = msg->buf; > + u8 *buf = wbuf + 1; > + > + if (i2c_check_functionality(client->adapter, I2C_FUNC_I2C) && > + i2c_transfer(client->adapter, msg, 1) < 0) { > + dev_err(&client->dev, "write error\n"); > + return -EIO; > + } else { > + for (i = 0; i < msg[0].len - 1; i++) { > + rc = i2c_smbus_write_byte_data(client, wbuf[0]+i, buf[i]); > + if (rc < 0) > + return -EIO; > + } > + } > + > + return 0; > +} Writing to the RTC by multiple I2C transfers might have same consistency problem. But it would not be a real problem if you wrote the sec register first. Here is a comment in rtc_m41t81.c:m41t81_set_time(): /* * Note the write order matters as it ensures the correctness. * When we write sec, 10th sec is clear. It is reasonable to * believe we should finish writing min within a second. */ I think this comment is worth to import. Other parts looks good for me. --- Atsushi Nemoto From macro@linux-mips.org Mon Oct 1 16:05:18 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 01 Oct 2007 16:05:26 +0100 (BST) Received: from cerber.ds.pg.gda.pl ([153.19.208.18]:51413 "EHLO cerber.ds.pg.gda.pl") by ftp.linux-mips.org with ESMTP id S20024112AbXJAPFS (ORCPT ); Mon, 1 Oct 2007 16:05:18 +0100 Received: from localhost (unknown [127.0.0.17]) by cerber.ds.pg.gda.pl (Postfix) with ESMTP id 35997400A9; Mon, 1 Oct 2007 17:05:19 +0200 (CEST) X-Virus-Scanned: amavisd-new at cerber.ds.pg.gda.pl Received: from cerber.ds.pg.gda.pl ([153.19.208.18]) by localhost (cerber.ds.pg.gda.pl [153.19.208.18]) (amavisd-new, port 10024) with ESMTP id EO8orWgHOkgA; Mon, 1 Oct 2007 17:05:13 +0200 (CEST) Received: from piorun.ds.pg.gda.pl (piorun.ds.pg.gda.pl [153.19.208.8]) by cerber.ds.pg.gda.pl (Postfix) with ESMTP id 6E7E040040; Mon, 1 Oct 2007 17:05:13 +0200 (CEST) Received: from blysk.ds.pg.gda.pl (macro@blysk.ds.pg.gda.pl [153.19.208.6]) by piorun.ds.pg.gda.pl (8.13.8/8.13.8) with ESMTP id l91F5Hc0027231; Mon, 1 Oct 2007 17:05:17 +0200 Date: Mon, 1 Oct 2007 16:05:11 +0100 (BST) From: "Maciej W. Rozycki" To: Giuseppe Sacco cc: linux-mips@linux-mips.org Subject: Re: Using PCI bridges on sgi-ip32 [was: Re: Tests of 2.6.23-rc8 on SGI O2] In-Reply-To: <1191141276.7160.44.camel@scarafaggio> Message-ID: References: <1190973427.11251.17.camel@scarafaggio> <1191141276.7160.44.camel@scarafaggio> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: ClamAV 0.91.2/4445/Mon Oct 1 10:32:46 2007 on piorun.ds.pg.gda.pl X-Virus-Status: Clean Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 16772 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: macro@linux-mips.org Precedence: bulk X-list: linux-mips On Sun, 30 Sep 2007, Giuseppe Sacco wrote: > So, should I debug the PCI controller for ip32 (MACE)? What could be the > problem here? Should I report this kind of problem to a different > mailing list? I suggest you rebuild with CONFIG_PCI_DEBUG enabled and if you are unable to deduce the reason from the resulting verbose bootstrap log, then send it here so that others may have a look. Maciej From fxzhang@ict.ac.cn Mon Oct 1 16:09:50 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 01 Oct 2007 16:09:58 +0100 (BST) Received: from webmail.ict.ac.cn ([159.226.39.7]:31197 "EHLO ict.ac.cn") by ftp.linux-mips.org with ESMTP id S20024201AbXJAPJu (ORCPT ); Mon, 1 Oct 2007 16:09:50 +0100 Received: (qmail 24622 invoked by uid 507); 1 Oct 2007 23:08:00 +0800 Received: from unknown (HELO ?192.168.1.8?) (fxzhang@222.92.8.142) by ict.ac.cn with SMTP; 1 Oct 2007 23:08:00 +0800 Message-ID: <47010E15.7060109@ict.ac.cn> Date: Mon, 01 Oct 2007 23:11:17 +0800 From: Fuxin Zhang User-Agent: IceDove 1.5.0.10 (X11/20070329) MIME-Version: 1.0 To: Ralf Baechle CC: linux-mips@linux-mips.org Subject: Re: cmpxchg broken in some situation References: <46FF7BC2.5050905@ict.ac.cn> <20071001025340.GA7091@linux-mips.org> In-Reply-To: <20071001025340.GA7091@linux-mips.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 16773 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: fxzhang@ict.ac.cn Precedence: bulk X-list: linux-mips Sorry that it seems not work: the kernel oops at sysfs_open_file->sysfs_get_active with unaligned access(last seen exception on screen, no serial console by hand so it may not be the first exception). It is probably caused by "atomic_cmpxchg" there. And keep the old kernel using new modules with patched cmpxchg also lead to glxgears die(should be lock problem like before). Ralf Baechle 写é“: > On Sun, Sep 30, 2007 at 06:34:42PM +0800, Fuxin Zhang wrote: > > >> hi, >> Today I run across a possible bug of cmpxchg implementation. When >> playing with DRM on our Fulong, the following function >> (drivers/char/drm/drm_lock.c) is not working correctly in 64BIT mips: >> cmpxchg failed to set *lock to new value. (return 0 with *lock unchanged) >> It is probably due to type conversions between unisigned int and >> unsigned long. When I change cmpxchg to mycmpxchg(attached below), >> problem disappeared. >> > > Below a patch to implement the get_user() style big solution to type > safety in cmpxchg. Can you test it? Thanks, > > Ralf > > Signed-off-by: Ralf Baechle > > include/asm-mips/cmpxchg.h | 104 ++++++++++++++++++ > include/asm-mips/local.h | 1 > include/asm-mips/system.h | 261 -------------------------------------------- > 3 files changed, 106 insertions(+), 260 deletions(-) > > diff --git a/include/asm-mips/cmpxchg.h b/include/asm-mips/cmpxchg.h > new file mode 100644 > index 0000000..d1523dd > --- /dev/null > +++ b/include/asm-mips/cmpxchg.h > @@ -0,0 +1,104 @@ > +/* > + * 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) 2003, 06, 07 by Ralf Baechle (ralf@linux-mips.org) > + */ > +#ifndef __ASM_CMPXCHG_H > +#define __ASM_CMPXCHG_H > + > +#include > + > +#define __HAVE_ARCH_CMPXCHG 1 > + > +#define __cmpxchg(ld, st, m, old, new) \ > +({ \ > + __typeof(*(m)) __ret; \ > + \ > + if (cpu_has_llsc && R10000_LLSC_WAR) { \ > + __asm__ __volatile__( \ > + " .set push \n" \ > + " .set noat \n" \ > + " .set mips3 \n" \ > + "1: " ld " %0, %2 # __cmpxchg_u32 \n" \ > + " bne %0, %z3, 2f \n" \ > + " .set mips0 \n" \ > + " move $1, %z4 \n" \ > + " .set mips3 \n" \ > + " " st " $1, %1 \n" \ > + " beqzl $1, 1b \n" \ > + "2: \n" \ > + " .set pop \n" \ > + : "=&r" (__ret), "=R" (*m) \ > + : "R" (*m), "Jr" (old), "Jr" (new) \ > + : "memory"); \ > + } else if (cpu_has_llsc) { \ > + __asm__ __volatile__( \ > + " .set push \n" \ > + " .set noat \n" \ > + " .set mips3 \n" \ > + "1: " ld " %0, %2 # __cmpxchg_u32 \n" \ > + " bne %0, %z3, 2f \n" \ > + " .set mips0 \n" \ > + " move $1, %z4 \n" \ > + " .set mips3 \n" \ > + " " st " $1, %1 \n" \ > + " beqz $1, 3f \n" \ > + "2: \n" \ > + " .subsection 2 \n" \ > + "3: b 1b \n" \ > + " .previous \n" \ > + " .set pop \n" \ > + : "=&r" (__ret), "=R" (*m) \ > + : "R" (*m), "Jr" (old), "Jr" (new) \ > + : "memory"); \ > + } else { \ > + unsigned long __flags; \ > + \ > + raw_local_irq_save(__flags); \ > + __ret = *m; \ > + if (__ret == old) \ > + *m = new; \ > + raw_local_irq_restore(__flags); \ > + } \ > + \ > + smp_llsc_mb(); \ > + \ > + __ret; \ > +}) > + > +/* > + * This function doesn't exist, so you'll get a linker error > + * if something tries to do an invalid cmpxchg(). > + */ > +extern void __cmpxchg_called_with_bad_pointer(void); > + > +#define cmpxchg(ptr,old,new) \ > +({ \ > + __typeof__(ptr) __ptr = (ptr); \ > + __typeof__(*(ptr)) __old = (old); \ > + __typeof__(*(ptr)) __new = (new); \ > + __typeof__(*(ptr)) __res = 0; \ > + \ > + switch (sizeof(__ptr)) { \ > + case 4: \ > + __res = __cmpxchg("ll", "sc", __ptr, __old, __new); \ > + break; \ > + case 8: \ > + if (sizeof(long) == 8) { \ > + __res = __cmpxchg("lld", "scd", __ptr, \ > + __old, __new); \ > + break; \ > + } \ > + default: \ > + __cmpxchg_called_with_bad_pointer(); \ > + break; \ > + } \ > + \ > + __res; \ > +}) > + > +#define cmpxchg_local(ptr, old, new) cmpxchg(ptr, old, new) > + > +#endif /* __ASM_CMPXCHG_H */ > diff --git a/include/asm-mips/local.h b/include/asm-mips/local.h > index ed882c8..7034a01 100644 > --- a/include/asm-mips/local.h > +++ b/include/asm-mips/local.h > @@ -4,6 +4,7 @@ > #include > #include > #include > +#include > #include > > typedef struct > diff --git a/include/asm-mips/system.h b/include/asm-mips/system.h > index 357251f..480b574 100644 > --- a/include/asm-mips/system.h > +++ b/include/asm-mips/system.h > @@ -17,6 +17,7 @@ > > #include > #include > +#include > #include > #include > #include > @@ -194,266 +195,6 @@ static inline unsigned long __xchg(unsigned long x, volatile void * ptr, int siz > > #define xchg(ptr,x) ((__typeof__(*(ptr)))__xchg((unsigned long)(x),(ptr),sizeof(*(ptr)))) > > -#define __HAVE_ARCH_CMPXCHG 1 > - > -static inline unsigned long __cmpxchg_u32(volatile int * m, unsigned long old, > - unsigned long new) > -{ > - __u32 retval; > - > - if (cpu_has_llsc && R10000_LLSC_WAR) { > - __asm__ __volatile__( > - " .set push \n" > - " .set noat \n" > - " .set mips3 \n" > - "1: ll %0, %2 # __cmpxchg_u32 \n" > - " bne %0, %z3, 2f \n" > - " .set mips0 \n" > - " move $1, %z4 \n" > - " .set mips3 \n" > - " sc $1, %1 \n" > - " beqzl $1, 1b \n" > - "2: \n" > - " .set pop \n" > - : "=&r" (retval), "=R" (*m) > - : "R" (*m), "Jr" (old), "Jr" (new) > - : "memory"); > - } else if (cpu_has_llsc) { > - __asm__ __volatile__( > - " .set push \n" > - " .set noat \n" > - " .set mips3 \n" > - "1: ll %0, %2 # __cmpxchg_u32 \n" > - " bne %0, %z3, 2f \n" > - " .set mips0 \n" > - " move $1, %z4 \n" > - " .set mips3 \n" > - " sc $1, %1 \n" > - " beqz $1, 3f \n" > - "2: \n" > - " .subsection 2 \n" > - "3: b 1b \n" > - " .previous \n" > - " .set pop \n" > - : "=&r" (retval), "=R" (*m) > - : "R" (*m), "Jr" (old), "Jr" (new) > - : "memory"); > - } else { > - unsigned long flags; > - > - raw_local_irq_save(flags); > - retval = *m; > - if (retval == old) > - *m = new; > - raw_local_irq_restore(flags); /* implies memory barrier */ > - } > - > - smp_llsc_mb(); > - > - return retval; > -} > - > -static inline unsigned long __cmpxchg_u32_local(volatile int * m, > - unsigned long old, unsigned long new) > -{ > - __u32 retval; > - > - if (cpu_has_llsc && R10000_LLSC_WAR) { > - __asm__ __volatile__( > - " .set push \n" > - " .set noat \n" > - " .set mips3 \n" > - "1: ll %0, %2 # __cmpxchg_u32 \n" > - " bne %0, %z3, 2f \n" > - " .set mips0 \n" > - " move $1, %z4 \n" > - " .set mips3 \n" > - " sc $1, %1 \n" > - " beqzl $1, 1b \n" > - "2: \n" > - " .set pop \n" > - : "=&r" (retval), "=R" (*m) > - : "R" (*m), "Jr" (old), "Jr" (new) > - : "memory"); > - } else if (cpu_has_llsc) { > - __asm__ __volatile__( > - " .set push \n" > - " .set noat \n" > - " .set mips3 \n" > - "1: ll %0, %2 # __cmpxchg_u32 \n" > - " bne %0, %z3, 2f \n" > - " .set mips0 \n" > - " move $1, %z4 \n" > - " .set mips3 \n" > - " sc $1, %1 \n" > - " beqz $1, 1b \n" > - "2: \n" > - " .set pop \n" > - : "=&r" (retval), "=R" (*m) > - : "R" (*m), "Jr" (old), "Jr" (new) > - : "memory"); > - } else { > - unsigned long flags; > - > - local_irq_save(flags); > - retval = *m; > - if (retval == old) > - *m = new; > - local_irq_restore(flags); /* implies memory barrier */ > - } > - > - return retval; > -} > - > -#ifdef CONFIG_64BIT > -static inline unsigned long __cmpxchg_u64(volatile int * m, unsigned long old, > - unsigned long new) > -{ > - __u64 retval; > - > - if (cpu_has_llsc && R10000_LLSC_WAR) { > - __asm__ __volatile__( > - " .set push \n" > - " .set noat \n" > - " .set mips3 \n" > - "1: lld %0, %2 # __cmpxchg_u64 \n" > - " bne %0, %z3, 2f \n" > - " move $1, %z4 \n" > - " scd $1, %1 \n" > - " beqzl $1, 1b \n" > - "2: \n" > - " .set pop \n" > - : "=&r" (retval), "=R" (*m) > - : "R" (*m), "Jr" (old), "Jr" (new) > - : "memory"); > - } else if (cpu_has_llsc) { > - __asm__ __volatile__( > - " .set push \n" > - " .set noat \n" > - " .set mips3 \n" > - "1: lld %0, %2 # __cmpxchg_u64 \n" > - " bne %0, %z3, 2f \n" > - " move $1, %z4 \n" > - " scd $1, %1 \n" > - " beqz $1, 3f \n" > - "2: \n" > - " .subsection 2 \n" > - "3: b 1b \n" > - " .previous \n" > - " .set pop \n" > - : "=&r" (retval), "=R" (*m) > - : "R" (*m), "Jr" (old), "Jr" (new) > - : "memory"); > - } else { > - unsigned long flags; > - > - raw_local_irq_save(flags); > - retval = *m; > - if (retval == old) > - *m = new; > - raw_local_irq_restore(flags); /* implies memory barrier */ > - } > - > - smp_llsc_mb(); > - > - return retval; > -} > - > -static inline unsigned long __cmpxchg_u64_local(volatile int * m, > - unsigned long old, unsigned long new) > -{ > - __u64 retval; > - > - if (cpu_has_llsc && R10000_LLSC_WAR) { > - __asm__ __volatile__( > - " .set push \n" > - " .set noat \n" > - " .set mips3 \n" > - "1: lld %0, %2 # __cmpxchg_u64 \n" > - " bne %0, %z3, 2f \n" > - " move $1, %z4 \n" > - " scd $1, %1 \n" > - " beqzl $1, 1b \n" > - "2: \n" > - " .set pop \n" > - : "=&r" (retval), "=R" (*m) > - : "R" (*m), "Jr" (old), "Jr" (new) > - : "memory"); > - } else if (cpu_has_llsc) { > - __asm__ __volatile__( > - " .set push \n" > - " .set noat \n" > - " .set mips3 \n" > - "1: lld %0, %2 # __cmpxchg_u64 \n" > - " bne %0, %z3, 2f \n" > - " move $1, %z4 \n" > - " scd $1, %1 \n" > - " beqz $1, 1b \n" > - "2: \n" > - " .set pop \n" > - : "=&r" (retval), "=R" (*m) > - : "R" (*m), "Jr" (old), "Jr" (new) > - : "memory"); > - } else { > - unsigned long flags; > - > - local_irq_save(flags); > - retval = *m; > - if (retval == old) > - *m = new; > - local_irq_restore(flags); /* implies memory barrier */ > - } > - > - return retval; > -} > - > -#else > -extern unsigned long __cmpxchg_u64_unsupported_on_32bit_kernels( > - volatile int * m, unsigned long old, unsigned long new); > -#define __cmpxchg_u64 __cmpxchg_u64_unsupported_on_32bit_kernels > -extern unsigned long __cmpxchg_u64_local_unsupported_on_32bit_kernels( > - volatile int * m, unsigned long old, unsigned long new); > -#define __cmpxchg_u64_local __cmpxchg_u64_local_unsupported_on_32bit_kernels > -#endif > - > -/* This function doesn't exist, so you'll get a linker error > - if something tries to do an invalid cmpxchg(). */ > -extern void __cmpxchg_called_with_bad_pointer(void); > - > -static inline unsigned long __cmpxchg(volatile void * ptr, unsigned long old, > - unsigned long new, int size) > -{ > - switch (size) { > - case 4: > - return __cmpxchg_u32(ptr, old, new); > - case 8: > - return __cmpxchg_u64(ptr, old, new); > - } > - __cmpxchg_called_with_bad_pointer(); > - return old; > -} > - > -static inline unsigned long __cmpxchg_local(volatile void * ptr, > - unsigned long old, unsigned long new, int size) > -{ > - switch (size) { > - case 4: > - return __cmpxchg_u32_local(ptr, old, new); > - case 8: > - return __cmpxchg_u64_local(ptr, old, new); > - } > - __cmpxchg_called_with_bad_pointer(); > - return old; > -} > - > -#define cmpxchg(ptr,old,new) \ > - ((__typeof__(*(ptr)))__cmpxchg((ptr), \ > - (unsigned long)(old), (unsigned long)(new),sizeof(*(ptr)))) > - > -#define cmpxchg_local(ptr,old,new) \ > - ((__typeof__(*(ptr)))__cmpxchg_local((ptr), \ > - (unsigned long)(old), (unsigned long)(new),sizeof(*(ptr)))) > - > extern void set_handler (unsigned long offset, void *addr, unsigned long len); > extern void set_uncached_handler (unsigned long offset, void *addr, unsigned long len); > > > > > From macro@linux-mips.org Mon Oct 1 16:10:46 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 01 Oct 2007 16:10:54 +0100 (BST) Received: from cerber.ds.pg.gda.pl ([153.19.208.18]:57291 "EHLO cerber.ds.pg.gda.pl") by ftp.linux-mips.org with ESMTP id S20024201AbXJAPKq (ORCPT ); Mon, 1 Oct 2007 16:10:46 +0100 Received: from localhost (unknown [127.0.0.17]) by cerber.ds.pg.gda.pl (Postfix) with ESMTP id 45110400A9; Mon, 1 Oct 2007 17:10:47 +0200 (CEST) X-Virus-Scanned: amavisd-new at cerber.ds.pg.gda.pl Received: from cerber.ds.pg.gda.pl ([153.19.208.18]) by localhost (cerber.ds.pg.gda.pl [153.19.208.18]) (amavisd-new, port 10024) with ESMTP id Gkc+ZNB09VqQ; Mon, 1 Oct 2007 17:10:40 +0200 (CEST) Received: from piorun.ds.pg.gda.pl (piorun.ds.pg.gda.pl [153.19.208.8]) by cerber.ds.pg.gda.pl (Postfix) with ESMTP id 53C4940040; Mon, 1 Oct 2007 17:10:40 +0200 (CEST) Received: from blysk.ds.pg.gda.pl (macro@blysk.ds.pg.gda.pl [153.19.208.6]) by piorun.ds.pg.gda.pl (8.13.8/8.13.8) with ESMTP id l91FAhFA027946; Mon, 1 Oct 2007 17:10:43 +0200 Date: Mon, 1 Oct 2007 16:10:38 +0100 (BST) From: "Maciej W. Rozycki" To: Mark Zhan cc: i2c@lm-sensors.org, linux-mips@linux-mips.org, rtc-linux@googlegroups.com, ralf@linux-mips.org, a.zummo@towertech.it Subject: Re: [PATCH 4/4] MIPS: Remove the legacy RTC codes of MIPS sibyte boards In-Reply-To: <46FF7283.7050702@windriver.com> Message-ID: References: <46FF7283.7050702@windriver.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: ClamAV 0.91.2/4445/Mon Oct 1 10:32:46 2007 on piorun.ds.pg.gda.pl X-Virus-Status: Clean Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 16774 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: macro@linux-mips.org Precedence: bulk X-list: linux-mips On Sun, 30 Sep 2007, Mark Zhan wrote: > This patch removes the legacy RTC codes of MIPS sibyte boards, > which are replaced by new RTC class drivers. And a board init > routine is added to register sibyte platform devices. Is the system time still set correctly from the RTC chip upon bootstrap with your changes? I cannot immediately infer it from the patches and my suspicion is it may not anymore. Maciej From ralf@linux-mips.org Mon Oct 1 16:26:24 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 01 Oct 2007 16:26:26 +0100 (BST) Received: from localhost.localdomain ([127.0.0.1]:28098 "EHLO dl5rb.ham-radio-op.net") by ftp.linux-mips.org with ESMTP id S20024221AbXJAP0Y (ORCPT ); Mon, 1 Oct 2007 16:26:24 +0100 Received: from denk.linux-mips.net (denk.linux-mips.net [127.0.0.1]) by dl5rb.ham-radio-op.net (8.14.1/8.13.8) with ESMTP id l91FQMbw028844; Mon, 1 Oct 2007 16:26:22 +0100 Received: (from ralf@localhost) by denk.linux-mips.net (8.14.1/8.14.1/Submit) id l91FQKMb028843; Mon, 1 Oct 2007 16:26:20 +0100 Date: Mon, 1 Oct 2007 16:26:20 +0100 From: Ralf Baechle To: Fuxin Zhang Cc: linux-mips@linux-mips.org Subject: Re: cmpxchg broken in some situation Message-ID: <20071001152620.GB15820@linux-mips.org> References: <46FF7BC2.5050905@ict.ac.cn> <20071001025340.GA7091@linux-mips.org> <47010E15.7060109@ict.ac.cn> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <47010E15.7060109@ict.ac.cn> User-Agent: Mutt/1.5.14 (2007-02-12) Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 16775 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: ralf@linux-mips.org Precedence: bulk X-list: linux-mips On Mon, Oct 01, 2007 at 11:11:17PM +0800, Fuxin Zhang wrote: > Sorry that it seems not work: > the kernel oops at sysfs_open_file->sysfs_get_active with unaligned > access(last seen exception on screen, no serial console by hand so it > may not be the first exception). It is probably caused by > "atomic_cmpxchg" there. > And keep the old kernel using new modules with patched cmpxchg also lead > to glxgears die(should be lock problem like before). Can you look at the disassembly of the generated code? It should hopefully be relativly obvious in the disassembly. Ralf From anemo@mba.ocn.ne.jp Mon Oct 1 16:28:43 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 01 Oct 2007 16:28:52 +0100 (BST) Received: from mba.ocn.ne.jp ([122.1.235.107]:7403 "HELO smtp.mba.ocn.ne.jp") by ftp.linux-mips.org with SMTP id S20024225AbXJAP2n (ORCPT ); Mon, 1 Oct 2007 16:28:43 +0100 Received: from localhost (p1055-ipad306funabasi.chiba.ocn.ne.jp [123.217.171.55]) by smtp.mba.ocn.ne.jp (Postfix) with ESMTP id A5AB9CC9D; Tue, 2 Oct 2007 00:28:38 +0900 (JST) Date: Tue, 02 Oct 2007 00:30:20 +0900 (JST) Message-Id: <20071002.003020.21363605.anemo@mba.ocn.ne.jp> To: macro@linux-mips.org Cc: rongkai.zhan@windriver.com, i2c@lm-sensors.org, linux-mips@linux-mips.org, rtc-linux@googlegroups.com, ralf@linux-mips.org, a.zummo@towertech.it Subject: Re: [PATCH 4/4] MIPS: Remove the legacy RTC codes of MIPS sibyte boards From: Atsushi Nemoto In-Reply-To: References: <46FF7283.7050702@windriver.com> X-Fingerprint: 6ACA 1623 39BD 9A94 9B1A B746 CA77 FE94 2874 D52F X-Pgp-Public-Key: http://wwwkeys.pgp.net/pks/lookup?op=get&search=0x2874D52F X-Mailer: Mew version 5.2 on Emacs 21.4 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 16776 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: anemo@mba.ocn.ne.jp Precedence: bulk X-list: linux-mips On Mon, 1 Oct 2007 16:10:38 +0100 (BST), "Maciej W. Rozycki" wrote: > > This patch removes the legacy RTC codes of MIPS sibyte boards, > > which are replaced by new RTC class drivers. And a board init > > routine is added to register sibyte platform devices. > > Is the system time still set correctly from the RTC chip upon bootstrap > with your changes? I cannot immediately infer it from the patches and my > suspicion is it may not anymore. CONFIG_RTC_HCTOSYS=y can do it, isn't it? Mark, please update defconfig files appropriately with your patch. --- Atsushi Nemoto From veerasena_b@yahoo.co.in Mon Oct 1 17:09:11 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 01 Oct 2007 17:09:21 +0100 (BST) Received: from n7.bullet.mud.yahoo.com ([216.252.100.58]:64341 "HELO n7.bullet.mud.yahoo.com") by ftp.linux-mips.org with SMTP id S20024120AbXJAQJL (ORCPT ); Mon, 1 Oct 2007 17:09:11 +0100 Received: from [209.191.108.97] by n7.bullet.mud.yahoo.com with NNFMP; 01 Oct 2007 16:07:50 -0000 Received: from [209.191.119.183] by t4.bullet.mud.yahoo.com with NNFMP; 01 Oct 2007 16:07:50 -0000 Received: from [127.0.0.1] by omp106.mail.mud.yahoo.com with NNFMP; 01 Oct 2007 11:32:24 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 781489.37541.bm@omp106.mail.mud.yahoo.com Received: (qmail 87513 invoked by uid 60001); 1 Oct 2007 10:51:21 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.co.in; h=X-YMail-OSG:Received:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding:Message-ID; b=yH0p7Xa53FkejCSpJUeKL3g42t+2nG6tFElL5c8IsJMCXKsUovDpNTAKrCBNXC0yQJcFnShPZtB54q0NbKDYVn9UETirap+cTUSZ5peNoLjY0VR2jBPS0OzvA/N6g/32sOgKmlZLWFqzSRznRagVWnKBkMozHAeKJAPzYOg1Rd8=; X-YMail-OSG: .bDNJ.cVM1nCsqTQWPXUQNTfz8Q0objiHDXBlBFh1kqOdT6YeEiXu6JJIK0gLRMBwg-- Received: from [199.239.167.162] by web8404.mail.in.yahoo.com via HTTP; Mon, 01 Oct 2007 11:51:21 BST Date: Mon, 1 Oct 2007 11:51:21 +0100 (BST) From: veerasena reddy Subject: Re: linux cache routines for Write-back cache policy on MIPS24KE To: Geert Uytterhoeven Cc: linux-mips , "linux-kernel.org" In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Message-ID: <302271.86305.qm@web8404.mail.in.yahoo.com> Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 16777 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: veerasena_b@yahoo.co.in Precedence: bulk X-list: linux-mips Hi Geert, Thanks for your repsonse. In linux-2.6.18 (for MIPS24KE processor): suppose if i want to do flush only then which API i should use? Similarly, if i want to do invalidation only which API i should use? Thanks again. Regards, Veerasena. --- Geert Uytterhoeven wrote: > On Mon, 1 Oct 2007, veerasena reddy wrote: > > I have ported Linux-2.6.18 kernel on MIPS24KE > > processor. I am using write back cache policy. > > > > Could you please guide me under what cases the > below > > cache API's are being used: > > - dma_cache_wback_inv() : Could you explain what > > exactly this function does > > It does both write back and invalidate. > > > - dma_cache_wback() : This function write back the > > cache data to memory > > - dma_cache_inv : This function invalidate the > cache > > tags. so subsequent access will fetch from memory. > > Note that 2.6.18 is old. The above functions are > intended to be removed. > > Gr{oetje,eeting}s, > > Geert > > -- > Geert Uytterhoeven -- There's lots of Linux beyond > ia32 -- geert@linux-m68k.org > > In personal conversations with technical people, I > call myself a hacker. But > when I'm talking to journalists I just say > "programmer" or something like that. > -- Linus Torvalds > Get the freedom to save as many mails as you wish. To know how, go to http://help.yahoo.com/l/in/yahoo/mail/yahoomail/tools/tools-08.html From veerasena_b@yahoo.co.in Mon Oct 1 19:48:26 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 01 Oct 2007 19:48:57 +0100 (BST) Received: from n6.bullet.mud.yahoo.com ([216.252.100.57]:13493 "HELO n6.bullet.mud.yahoo.com") by ftp.linux-mips.org with SMTP id S20021761AbXJASs0 (ORCPT ); Mon, 1 Oct 2007 19:48:26 +0100 Received: from [68.142.194.243] by n6.bullet.mud.yahoo.com with NNFMP; 01 Oct 2007 18:47:04 -0000 Received: from [209.191.119.164] by t1.bullet.mud.yahoo.com with NNFMP; 01 Oct 2007 18:47:04 -0000 Received: from [127.0.0.1] by omp103.mail.mud.yahoo.com with NNFMP; 01 Oct 2007 16:36:33 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 364363.43167.bm@omp103.mail.mud.yahoo.com Received: (qmail 96203 invoked by uid 60001); 1 Oct 2007 12:13:48 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.co.in; h=X-YMail-OSG:Received:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding:Message-ID; b=WJZfArM1nFJ48nLF8v7s7JncM0/nshX7nOj1MfLlSRPboVcdskjfnpLKx1l9iTlbaHa3hvZYYqobJrpQsCXCmCMsfc7saFoy+IiliwAYlylzH8DxwNkT+d6fYp+izB6zBGNyWDuL2NWyMZBSJzslKFapy/b0lJj6osrHjqS7rPE=; X-YMail-OSG: seURp90VM1lCQ9NKSyRWx4lTNpcVIUWDCYzqjgtlf9Y62jSectMGExqe.Mdiqp3y2mDz8iIyApuLugd88KlDl_bJCgoLCGoRYI0ndEW9vBk3e0Us1Y6_dqpS0IbJXQ-- Received: from [199.239.167.162] by web8402.mail.in.yahoo.com via HTTP; Mon, 01 Oct 2007 13:13:47 BST Date: Mon, 1 Oct 2007 13:13:47 +0100 (BST) From: veerasena reddy Subject: Re: linux cache routines for Write-back cache policy on MIPS24KE To: Geert Uytterhoeven Cc: linux-mips , "linux-kernel.org" In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Message-ID: <900355.95714.qm@web8402.mail.in.yahoo.com> Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 16778 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: veerasena_b@yahoo.co.in Precedence: bulk X-list: linux-mips hi Geert, here i mean 'flush' is 'write-back only' Regards, Veerasena. --- Geert Uytterhoeven wrote: > On Mon, 1 Oct 2007, veerasena reddy wrote: > > In linux-2.6.18 (for MIPS24KE processor): > > suppose if i want to do flush only then which API > i > > should use? > > `flush' is fuzzy terminology: some people mean > invalidate, others mean > write back, others mean both. > > > Similarly, if i want to do invalidation only which > API > > i should use? > > dma_cache_inv(). > > > --- Geert Uytterhoeven > wrote: > > > > > On Mon, 1 Oct 2007, veerasena reddy wrote: > > > > I have ported Linux-2.6.18 kernel on MIPS24KE > > > > processor. I am using write back cache policy. > > > > > > > > Could you please guide me under what cases the > > > below > > > > cache API's are being used: > > > > - dma_cache_wback_inv() : Could you explain > what > > > > exactly this function does > > > > > > It does both write back and invalidate. > > > > > > > - dma_cache_wback() : This function write back > the > > > > cache data to memory > > > > - dma_cache_inv : This function invalidate > the > > > cache > > > > tags. so subsequent access will fetch from > memory. > > > > > > Note that 2.6.18 is old. The above functions are > > > intended to be removed. > > Gr{oetje,eeting}s, > > Geert > > -- > Geert Uytterhoeven -- There's lots of Linux beyond > ia32 -- geert@linux-m68k.org > > In personal conversations with technical people, I > call myself a hacker. But > when I'm talking to journalists I just say > "programmer" or something like that. > -- Linus Torvalds > > Forgot the famous last words? Access your message archive online at http://in.messenger.yahoo.com/webmessengerpromo.php From macro@linux-mips.org Mon Oct 1 20:09:34 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 01 Oct 2007 20:09:42 +0100 (BST) Received: from cerber.ds.pg.gda.pl ([153.19.208.18]:25275 "EHLO cerber.ds.pg.gda.pl") by ftp.linux-mips.org with ESMTP id S20021799AbXJATJe (ORCPT ); Mon, 1 Oct 2007 20:09:34 +0100 Received: from localhost (unknown [127.0.0.17]) by cerber.ds.pg.gda.pl (Postfix) with ESMTP id D6492400A9; Mon, 1 Oct 2007 21:09:05 +0200 (CEST) X-Virus-Scanned: amavisd-new at cerber.ds.pg.gda.pl Received: from cerber.ds.pg.gda.pl ([153.19.208.18]) by localhost (cerber.ds.pg.gda.pl [153.19.208.18]) (amavisd-new, port 10024) with ESMTP id hOPhRCtRomdI; Mon, 1 Oct 2007 21:08:59 +0200 (CEST) Received: from piorun.ds.pg.gda.pl (piorun.ds.pg.gda.pl [153.19.208.8]) by cerber.ds.pg.gda.pl (Postfix) with ESMTP id 893F840040; Mon, 1 Oct 2007 21:08:59 +0200 (CEST) Received: from blysk.ds.pg.gda.pl (macro@blysk.ds.pg.gda.pl [153.19.208.6]) by piorun.ds.pg.gda.pl (8.13.8/8.13.8) with ESMTP id l91J92iJ006517; Mon, 1 Oct 2007 21:09:03 +0200 Date: Mon, 1 Oct 2007 20:08:55 +0100 (BST) From: "Maciej W. Rozycki" To: Atsushi Nemoto cc: rongkai.zhan@windriver.com, i2c@lm-sensors.org, linux-mips@linux-mips.org, rtc-linux@googlegroups.com, ralf@linux-mips.org, a.zummo@towertech.it Subject: Re: [PATCH 4/4] MIPS: Remove the legacy RTC codes of MIPS sibyte boards In-Reply-To: <20071002.003020.21363605.anemo@mba.ocn.ne.jp> Message-ID: References: <46FF7283.7050702@windriver.com> <20071002.003020.21363605.anemo@mba.ocn.ne.jp> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: ClamAV 0.91.2/4445/Mon Oct 1 10:32:46 2007 on piorun.ds.pg.gda.pl X-Virus-Status: Clean Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 16779 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: macro@linux-mips.org Precedence: bulk X-list: linux-mips On Tue, 2 Oct 2007, Atsushi Nemoto wrote: > > Is the system time still set correctly from the RTC chip upon bootstrap > > with your changes? I cannot immediately infer it from the patches and my > > suspicion is it may not anymore. > > CONFIG_RTC_HCTOSYS=y can do it, isn't it? Hmm, I wonder whether this shouldn't be enabled via a reverse dependency. Or even unconditionally perhaps -- if the initial system time gets set from incorrect RTC time (e.g. because it is not battery-backed) it does not get less correct than it would be otherwise, does it? Any reason for not doing either of these? Maciej From veerasena_b@yahoo.co.in Mon Oct 1 21:33:30 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 01 Oct 2007 21:33:39 +0100 (BST) Received: from n7.bullet.mud.yahoo.com ([216.252.100.58]:39785 "HELO n7.bullet.mud.yahoo.com") by ftp.linux-mips.org with SMTP id S20021983AbXJAUda (ORCPT ); Mon, 1 Oct 2007 21:33:30 +0100 Received: from [68.142.194.244] by n7.bullet.mud.yahoo.com with NNFMP; 01 Oct 2007 20:33:23 -0000 Received: from [209.191.119.153] by t2.bullet.mud.yahoo.com with NNFMP; 01 Oct 2007 20:33:23 -0000 Received: from [127.0.0.1] by omp100.mail.mud.yahoo.com with NNFMP; 01 Oct 2007 20:08:15 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 842743.27969.bm@omp100.mail.mud.yahoo.com Received: (qmail 48437 invoked by uid 60001); 1 Oct 2007 12:10:59 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.co.in; h=X-YMail-OSG:Received:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding:Message-ID; b=JFI93gjpzOHlXrYO0qKiBrK2exRN0OUN5mgune/EHusbnjKGeS2+sEvK9Tn0eMPo1KvwogV0XtXLOa8+OtabFNg6kjPzE6/DBzH/XSkEeYxjkQACFOyyLaFoaEyO6w9yo/TykbbTHV1rzLQEClIKfNh61EHkhDIwEPLSFCcJVpE=; X-YMail-OSG: 2Ig8bTcVM1nO9td6myIxXt9.FpWVrwmpuK_jDH2VK_Z13tLNAiMLCRCEa2vgXw9UmqssKi2L8wJOBb2MetWIWOxLM0VENOwBoLeO8r.4zPTX.bC6fUVqfh4iVQ-- Received: from [199.239.167.162] by web8403.mail.in.yahoo.com via HTTP; Mon, 01 Oct 2007 13:10:59 BST Date: Mon, 1 Oct 2007 13:10:59 +0100 (BST) From: veerasena reddy Subject: Re: linux cache routines for Write-back cache policy on MIPS24KE To: Ralf Baechle Cc: linux-mips , "linux-kernel.org" In-Reply-To: <20071001105954.GB23647@linux-mips.org> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Message-ID: <535696.48077.qm@web8403.mail.in.yahoo.com> Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 16780 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: veerasena_b@yahoo.co.in Precedence: bulk X-list: linux-mips Hi Ralf, Thanks for the reply. Is there any problem if we use the below API's in linxu-2.6.18 - dma_cache_wback_inv() - dma_cache_wback() - dma_cache_inv() functionality wise, especially in r4k.c i dont see any difference between the implementation of these APIs. Can we apply the 2.6.24 patch to kill these APIs on 2.6.18 kernel? In this case what APIs i can use for writeback, invalidation or both? I couldn't find any info. related to the above API in DMA-API.txt. Could you please give some pointers on the usage/working of these APIs. Regards, Veerasena. --- Ralf Baechle wrote: > On Mon, Oct 01, 2007 at 10:04:32AM +0100, veerasena > reddy wrote: > > > I have ported Linux-2.6.18 kernel on MIPS24KE > > processor. I am using write back cache policy. > > > > Could you please guide me under what cases the > below > > cache API's are being used: > > - dma_cache_wback_inv() : Could you explain what > > exactly this function does > > - dma_cache_wback() : This function write back the > > cache data to memory > > - dma_cache_inv : This function invalidate the > cache > > tags. so subsequent access will fetch from memory. > > > > Once I looked the above function definitions in > > linux-2.6.18/arch/mips/mm/c-r4k.c. > > All these function's implemetation are same except > > bc_wbak_inv() is called in both > dma_cache_wback-inv() > > and dma_cache_wback(), where as bc_inv() is called > in > > case of dma_cache_inv. > > > > Also, bc_inv()/bc_wbak_inv are define as null > > implementation for R4000. > > That means all three functions are doing same > > functionality in case of R4000. > > > > What are the difference between these three > functions. > > Under what cases these functions are used. > > An internal only interface to be used with I/O cache > coherency. > > > Please guide me if you have any links which will > > explain these API's. > > Easy answer, don't use them, for 2.6.24 I've queued > a patch to kill this > API. Documentation/DMA-API.txt documents how to > properly deal with I/O > coherency in Linux. > > Ralf > Save all your chat conversations. Find them online at http://in.messenger.yahoo.com/webmessengerpromo.php From giuseppe@eppesuigoccas.homedns.org Tue Oct 2 02:04:49 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 02 Oct 2007 02:04:58 +0100 (BST) Received: from host104-225-dynamic.0-79-r.retail.telecomitalia.it ([79.0.225.104]:11174 "EHLO eppesuigoccas.homedns.org") by ftp.linux-mips.org with ESMTP id S20021491AbXJBBEt (ORCPT ); Tue, 2 Oct 2007 02:04:49 +0100 Received: from localhost ([127.0.0.1] helo=sgi) by eppesuigoccas.homedns.org with smtp (Exim 4.63) (envelope-from ) id 1IcW8k-00010C-U4 for linux-mips@linux-mips.org; Tue, 02 Oct 2007 03:01:36 +0200 Date: Tue, 2 Oct 2007 03:01:33 +0200 From: Giuseppe Sacco To: linux-mips@linux-mips.org Subject: Re: Using PCI bridges on sgi-ip32: CONFIG_PCI_DEBUG Message-Id: <20071002030133.fd5f6315.giuseppe@eppesuigoccas.homedns.org> In-Reply-To: References: <1190973427.11251.17.camel@scarafaggio> <1191141276.7160.44.camel@scarafaggio> X-Mailer: Sylpheed version 2.3.0beta5 (GTK+ 2.8.20; mips-unknown-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 16781 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: giuseppe@eppesuigoccas.homedns.org Precedence: bulk X-list: linux-mips Hi Maciej, On Mon, 1 Oct 2007 16:05:11 +0100 (BST) "Maciej W. Rozycki" wrote: [...] > I suggest you rebuild with CONFIG_PCI_DEBUG enabled and if you are unable > to deduce the reason from the resulting verbose bootstrap log, then send > it here so that others may have a look. Thanks for this suggestion. Here is the relevant log: [...] MACE PCI rev 1 registering PCI controller with io_map_base unset SCSI subsystem initialized PCI: Scanning bus 0000:00 PCI: Found 0000:00:01.0 [9004/8078] 000100 00 PCI: Found 0000:00:02.0 [9004/8078] 000100 00 PCI: Found 0000:00:03.0 [9710/9250] 000604 01 PCI: Calling quirk ffffffff801da1e0 for 0000:00:03.0 PCI: Fixups for bus 0000:00 PCI: Scanning behind PCI bridge 0000:00:03.0, config ffffff, pass 0 PCI: Scanning behind PCI bridge 0000:00:03.0, config 000000, pass 1 PCI: Scanning bus 0000:01 PCI: Fixups for bus 0000:01 PCI: Bus scan for 0000:01 returning with max=01 PCI: Bus scan for 0000:00 returning with max=01 got res [280000000:28000ffff] bus [80000000:8000ffff] flags 7200 for BAR 6 of 0000:00:01.0 got res [280010000:28001ffff] bus [80010000:8001ffff] flags 7200 for BAR 6 of 0000:00:02.0 got res [280020000:280020fff] bus [80020000:80020fff] flags 200 for BAR 1 of 0000:00:01.0 PCI: moved device 0000:00:01.0 resource 1 (200) to 80020000 got res [280021000:280021fff] bus [80021000:80021fff] flags 200 for BAR 1 of 0000:00:02.0 PCI: moved device 0000:00:02.0 resource 1 (200) to 80021000 got res [1000:10ff] bus [1000:10ff] flags 101 for BAR 0 of 0000:00:01.0 PCI: moved device 0000:00:01.0 resource 0 (101) to 1000 got res [1400:14ff] bus [1400:14ff] flags 101 for BAR 0 of 0000:00:02.0 PCI: moved device 0000:00:02.0 resource 0 (101) to 1400 PCI: Bridge: 0000:00:03.0 IO window: disabled. MEM window: disabled. PREFETCH window: disabled. PCI: Enabling bus mastering for device 0000:00:03.0 PCI: Setting latency timer of device 0000:00:03.0 to 64 PCI: fixup irq: (0000:00:01.0) got 9 PCI: fixup irq: (0000:00:02.0) got 10 PCI: fixup irq: (0000:00:03.0) got 0 [...] PCI: Calling quirk ffffffff801db928 for 0000:00:01.0 PCI: Calling quirk ffffffff80262f70 for 0000:00:01.0 PCI: Calling quirk ffffffff801db928 for 0000:00:02.0 PCI: Calling quirk ffffffff80262f70 for 0000:00:02.0 PCI: Calling quirk ffffffff801db928 for 0000:00:03.0 PCI: Calling quirk ffffffff80262f70 for 0000:00:03.0 [...] PCI: Enabling device 0000:00:01.0 (0046 -> 0047) [...] PCI: Enabling device 0000:00:02.0 (0046 -> 0047) [...] From fxzhang@ict.ac.cn Tue Oct 2 10:33:14 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 02 Oct 2007 10:33:22 +0100 (BST) Received: from webmail.ict.ac.cn ([159.226.39.7]:19099 "EHLO ict.ac.cn") by ftp.linux-mips.org with ESMTP id S20023756AbXJBJdO (ORCPT ); Tue, 2 Oct 2007 10:33:14 +0100 Received: (qmail 20744 invoked by uid 507); 2 Oct 2007 17:31:33 +0800 Received: from unknown (HELO ?192.168.1.8?) (fxzhang@222.92.8.142) by ict.ac.cn with SMTP; 2 Oct 2007 17:31:33 +0800 Message-ID: <470210B4.8020902@ict.ac.cn> Date: Tue, 02 Oct 2007 17:34:44 +0800 From: Fuxin Zhang User-Agent: IceDove 1.5.0.10 (X11/20070329) MIME-Version: 1.0 To: Ralf Baechle CC: linux-mips@linux-mips.org Subject: Re: cmpxchg broken in some situation References: <46FF7BC2.5050905@ict.ac.cn> <20071001025340.GA7091@linux-mips.org> <47010E15.7060109@ict.ac.cn> <20071001152620.GB15820@linux-mips.org> In-Reply-To: <20071001152620.GB15820@linux-mips.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 16782 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: fxzhang@ict.ac.cn Precedence: bulk X-list: linux-mips The problem is here: switch (sizeof(__ptr)) { // --> should be sizeof(*(__ptr)) case 4: ... Recompiling.. Ralf Baechle 写é“: > On Mon, Oct 01, 2007 at 11:11:17PM +0800, Fuxin Zhang wrote: > > >> Sorry that it seems not work: >> the kernel oops at sysfs_open_file->sysfs_get_active with unaligned >> access(last seen exception on screen, no serial console by hand so it >> may not be the first exception). It is probably caused by >> "atomic_cmpxchg" there. >> And keep the old kernel using new modules with patched cmpxchg also lead >> to glxgears die(should be lock problem like before). >> > > Can you look at the disassembly of the generated code? It should hopefully > be relativly obvious in the disassembly. > > Ralf > > > > From ralf@linux-mips.org Tue Oct 2 11:35:53 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 02 Oct 2007 11:35:56 +0100 (BST) Received: from localhost.localdomain ([127.0.0.1]:13797 "EHLO dl5rb.ham-radio-op.net") by ftp.linux-mips.org with ESMTP id S20023860AbXJBKfx (ORCPT ); Tue, 2 Oct 2007 11:35:53 +0100 Received: from denk.linux-mips.net (denk.linux-mips.net [127.0.0.1]) by dl5rb.ham-radio-op.net (8.14.1/8.13.8) with ESMTP id l92AZrxE010920; Tue, 2 Oct 2007 11:35:53 +0100 Received: (from ralf@localhost) by denk.linux-mips.net (8.14.1/8.14.1/Submit) id l92AZpj2010919; Tue, 2 Oct 2007 11:35:51 +0100 Date: Tue, 2 Oct 2007 11:35:51 +0100 From: Ralf Baechle To: Fuxin Zhang Cc: linux-mips@linux-mips.org Subject: Re: cmpxchg broken in some situation Message-ID: <20071002103551.GB5152@linux-mips.org> References: <46FF7BC2.5050905@ict.ac.cn> <20071001025340.GA7091@linux-mips.org> <47010E15.7060109@ict.ac.cn> <20071001152620.GB15820@linux-mips.org> <470210B4.8020902@ict.ac.cn> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <470210B4.8020902@ict.ac.cn> User-Agent: Mutt/1.5.14 (2007-02-12) Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 16783 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: ralf@linux-mips.org Precedence: bulk X-list: linux-mips On Tue, Oct 02, 2007 at 05:34:44PM +0800, Fuxin Zhang wrote: > The problem is here: > > switch (sizeof(__ptr)) { // --> should be sizeof(*(__ptr)) > case 4: > ... > Recompiling.. There was another small kink, cmpxchg_local() does not imply a memory barrier so I optimized that case. And I don't complain about it being 151 lines shorter ;-) Ralf From: Ralf Baechle [MIPS] Typeproof reimplementation of cmpxchg. Signed-off-by: Ralf Baechle diff --git a/include/asm-mips/cmpxchg.h b/include/asm-mips/cmpxchg.h new file mode 100644 index 0000000..46bac47 --- /dev/null +++ b/include/asm-mips/cmpxchg.h @@ -0,0 +1,107 @@ +/* + * 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) 2003, 06, 07 by Ralf Baechle (ralf@linux-mips.org) + */ +#ifndef __ASM_CMPXCHG_H +#define __ASM_CMPXCHG_H + +#include + +#define __HAVE_ARCH_CMPXCHG 1 + +#define __cmpxchg_asm(ld, st, m, old, new) \ +({ \ + __typeof(*(m)) __ret; \ + \ + if (cpu_has_llsc && R10000_LLSC_WAR) { \ + __asm__ __volatile__( \ + " .set push \n" \ + " .set noat \n" \ + " .set mips3 \n" \ + "1: " ld " %0, %2 # __cmpxchg_u32 \n" \ + " bne %0, %z3, 2f \n" \ + " .set mips0 \n" \ + " move $1, %z4 \n" \ + " .set mips3 \n" \ + " " st " $1, %1 \n" \ + " beqzl $1, 1b \n" \ + "2: \n" \ + " .set pop \n" \ + : "=&r" (__ret), "=R" (*m) \ + : "R" (*m), "Jr" (old), "Jr" (new) \ + : "memory"); \ + } else if (cpu_has_llsc) { \ + __asm__ __volatile__( \ + " .set push \n" \ + " .set noat \n" \ + " .set mips3 \n" \ + "1: " ld " %0, %2 # __cmpxchg_u32 \n" \ + " bne %0, %z3, 2f \n" \ + " .set mips0 \n" \ + " move $1, %z4 \n" \ + " .set mips3 \n" \ + " " st " $1, %1 \n" \ + " beqz $1, 3f \n" \ + "2: \n" \ + " .subsection 2 \n" \ + "3: b 1b \n" \ + " .previous \n" \ + " .set pop \n" \ + : "=&r" (__ret), "=R" (*m) \ + : "R" (*m), "Jr" (old), "Jr" (new) \ + : "memory"); \ + } else { \ + unsigned long __flags; \ + \ + raw_local_irq_save(__flags); \ + __ret = *m; \ + if (__ret == old) \ + *m = new; \ + raw_local_irq_restore(__flags); \ + } \ + \ + smp_llsc_mb(); \ + \ + __ret; \ +}) + +/* + * This function doesn't exist, so you'll get a linker error + * if something tries to do an invalid cmpxchg(). + */ +extern void __cmpxchg_called_with_bad_pointer(void); + +#define __cmpxchg(ptr,old,new,barrier) \ +({ \ + __typeof__(ptr) __ptr = (ptr); \ + __typeof__(*(ptr)) __old = (old); \ + __typeof__(*(ptr)) __new = (new); \ + __typeof__(*(ptr)) __res = 0; \ + \ + switch (sizeof(*(__ptr))) { \ + case 4: \ + __res = __cmpxchg_asm("ll", "sc", __ptr, __old, __new); \ + break; \ + case 8: \ + if (sizeof(long) == 8) { \ + __res = __cmpxchg_asm("lld", "scd", __ptr, \ + __old, __new); \ + break; \ + } \ + default: \ + __cmpxchg_called_with_bad_pointer(); \ + break; \ + } \ + \ + barrier; \ + \ + __res; \ +}) + +#define cmpxchg(ptr, old, new) __cmpxchg(ptr, old, new, smp_llsc_mb()) +#define cmpxchg_local(ptr, old, new) __cmpxchg(ptr, old, new,) + +#endif /* __ASM_CMPXCHG_H */ diff --git a/include/asm-mips/local.h b/include/asm-mips/local.h index ed882c8..7034a01 100644 --- a/include/asm-mips/local.h +++ b/include/asm-mips/local.h @@ -4,6 +4,7 @@ #include #include #include +#include #include typedef struct diff --git a/include/asm-mips/system.h b/include/asm-mips/system.h index 357251f..480b574 100644 --- a/include/asm-mips/system.h +++ b/include/asm-mips/system.h @@ -17,6 +17,7 @@ #include #include +#include #include #include #include @@ -194,266 +195,6 @@ static inline unsigned long __xchg(unsigned long x, volatile void * ptr, int siz #define xchg(ptr,x) ((__typeof__(*(ptr)))__xchg((unsigned long)(x),(ptr),sizeof(*(ptr)))) -#define __HAVE_ARCH_CMPXCHG 1 - -static inline unsigned long __cmpxchg_u32(volatile int * m, unsigned long old, - unsigned long new) -{ - __u32 retval; - - if (cpu_has_llsc && R10000_LLSC_WAR) { - __asm__ __volatile__( - " .set push \n" - " .set noat \n" - " .set mips3 \n" - "1: ll %0, %2 # __cmpxchg_u32 \n" - " bne %0, %z3, 2f \n" - " .set mips0 \n" - " move $1, %z4 \n" - " .set mips3 \n" - " sc $1, %1 \n" - " beqzl $1, 1b \n" - "2: \n" - " .set pop \n" - : "=&r" (retval), "=R" (*m) - : "R" (*m), "Jr" (old), "Jr" (new) - : "memory"); - } else if (cpu_has_llsc) { - __asm__ __volatile__( - " .set push \n" - " .set noat \n" - " .set mips3 \n" - "1: ll %0, %2 # __cmpxchg_u32 \n" - " bne %0, %z3, 2f \n" - " .set mips0 \n" - " move $1, %z4 \n" - " .set mips3 \n" - " sc $1, %1 \n" - " beqz $1, 3f \n" - "2: \n" - " .subsection 2 \n" - "3: b 1b \n" - " .previous \n" - " .set pop \n" - : "=&r" (retval), "=R" (*m) - : "R" (*m), "Jr" (old), "Jr" (new) - : "memory"); - } else { - unsigned long flags; - - raw_local_irq_save(flags); - retval = *m; - if (retval == old) - *m = new; - raw_local_irq_restore(flags); /* implies memory barrier */ - } - - smp_llsc_mb(); - - return retval; -} - -static inline unsigned long __cmpxchg_u32_local(volatile int * m, - unsigned long old, unsigned long new) -{ - __u32 retval; - - if (cpu_has_llsc && R10000_LLSC_WAR) { - __asm__ __volatile__( - " .set push \n" - " .set noat \n" - " .set mips3 \n" - "1: ll %0, %2 # __cmpxchg_u32 \n" - " bne %0, %z3, 2f \n" - " .set mips0 \n" - " move $1, %z4 \n" - " .set mips3 \n" - " sc $1, %1 \n" - " beqzl $1, 1b \n" - "2: \n" - " .set pop \n" - : "=&r" (retval), "=R" (*m) - : "R" (*m), "Jr" (old), "Jr" (new) - : "memory"); - } else if (cpu_has_llsc) { - __asm__ __volatile__( - " .set push \n" - " .set noat \n" - " .set mips3 \n" - "1: ll %0, %2 # __cmpxchg_u32 \n" - " bne %0, %z3, 2f \n" - " .set mips0 \n" - " move $1, %z4 \n" - " .set mips3 \n" - " sc $1, %1 \n" - " beqz $1, 1b \n" - "2: \n" - " .set pop \n" - : "=&r" (retval), "=R" (*m) - : "R" (*m), "Jr" (old), "Jr" (new) - : "memory"); - } else { - unsigned long flags; - - local_irq_save(flags); - retval = *m; - if (retval == old) - *m = new; - local_irq_restore(flags); /* implies memory barrier */ - } - - return retval; -} - -#ifdef CONFIG_64BIT -static inline unsigned long __cmpxchg_u64(volatile int * m, unsigned long old, - unsigned long new) -{ - __u64 retval; - - if (cpu_has_llsc && R10000_LLSC_WAR) { - __asm__ __volatile__( - " .set push \n" - " .set noat \n" - " .set mips3 \n" - "1: lld %0, %2 # __cmpxchg_u64 \n" - " bne %0, %z3, 2f \n" - " move $1, %z4 \n" - " scd $1, %1 \n" - " beqzl $1, 1b \n" - "2: \n" - " .set pop \n" - : "=&r" (retval), "=R" (*m) - : "R" (*m), "Jr" (old), "Jr" (new) - : "memory"); - } else if (cpu_has_llsc) { - __asm__ __volatile__( - " .set push \n" - " .set noat \n" - " .set mips3 \n" - "1: lld %0, %2 # __cmpxchg_u64 \n" - " bne %0, %z3, 2f \n" - " move $1, %z4 \n" - " scd $1, %1 \n" - " beqz $1, 3f \n" - "2: \n" - " .subsection 2 \n" - "3: b 1b \n" - " .previous \n" - " .set pop \n" - : "=&r" (retval), "=R" (*m) - : "R" (*m), "Jr" (old), "Jr" (new) - : "memory"); - } else { - unsigned long flags; - - raw_local_irq_save(flags); - retval = *m; - if (retval == old) - *m = new; - raw_local_irq_restore(flags); /* implies memory barrier */ - } - - smp_llsc_mb(); - - return retval; -} - -static inline unsigned long __cmpxchg_u64_local(volatile int * m, - unsigned long old, unsigned long new) -{ - __u64 retval; - - if (cpu_has_llsc && R10000_LLSC_WAR) { - __asm__ __volatile__( - " .set push \n" - " .set noat \n" - " .set mips3 \n" - "1: lld %0, %2 # __cmpxchg_u64 \n" - " bne %0, %z3, 2f \n" - " move $1, %z4 \n" - " scd $1, %1 \n" - " beqzl $1, 1b \n" - "2: \n" - " .set pop \n" - : "=&r" (retval), "=R" (*m) - : "R" (*m), "Jr" (old), "Jr" (new) - : "memory"); - } else if (cpu_has_llsc) { - __asm__ __volatile__( - " .set push \n" - " .set noat \n" - " .set mips3 \n" - "1: lld %0, %2 # __cmpxchg_u64 \n" - " bne %0, %z3, 2f \n" - " move $1, %z4 \n" - " scd $1, %1 \n" - " beqz $1, 1b \n" - "2: \n" - " .set pop \n" - : "=&r" (retval), "=R" (*m) - : "R" (*m), "Jr" (old), "Jr" (new) - : "memory"); - } else { - unsigned long flags; - - local_irq_save(flags); - retval = *m; - if (retval == old) - *m = new; - local_irq_restore(flags); /* implies memory barrier */ - } - - return retval; -} - -#else -extern unsigned long __cmpxchg_u64_unsupported_on_32bit_kernels( - volatile int * m, unsigned long old, unsigned long new); -#define __cmpxchg_u64 __cmpxchg_u64_unsupported_on_32bit_kernels -extern unsigned long __cmpxchg_u64_local_unsupported_on_32bit_kernels( - volatile int * m, unsigned long old, unsigned long new); -#define __cmpxchg_u64_local __cmpxchg_u64_local_unsupported_on_32bit_kernels -#endif - -/* This function doesn't exist, so you'll get a linker error - if something tries to do an invalid cmpxchg(). */ -extern void __cmpxchg_called_with_bad_pointer(void); - -static inline unsigned long __cmpxchg(volatile void * ptr, unsigned long old, - unsigned long new, int size) -{ - switch (size) { - case 4: - return __cmpxchg_u32(ptr, old, new); - case 8: - return __cmpxchg_u64(ptr, old, new); - } - __cmpxchg_called_with_bad_pointer(); - return old; -} - -static inline unsigned long __cmpxchg_local(volatile void * ptr, - unsigned long old, unsigned long new, int size) -{ - switch (size) { - case 4: - return __cmpxchg_u32_local(ptr, old, new); - case 8: - return __cmpxchg_u64_local(ptr, old, new); - } - __cmpxchg_called_with_bad_pointer(); - return old; -} - -#define cmpxchg(ptr,old,new) \ - ((__typeof__(*(ptr)))__cmpxchg((ptr), \ - (unsigned long)(old), (unsigned long)(new),sizeof(*(ptr)))) - -#define cmpxchg_local(ptr,old,new) \ - ((__typeof__(*(ptr)))__cmpxchg_local((ptr), \ - (unsigned long)(old), (unsigned long)(new),sizeof(*(ptr)))) - extern void set_handler (unsigned long offset, void *addr, unsigned long len); extern void set_uncached_handler (unsigned long offset, void *addr, unsigned long len); From ralf@linux-mips.org Tue Oct 2 12:04:39 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 02 Oct 2007 12:04:41 +0100 (BST) Received: from localhost.localdomain ([127.0.0.1]:32454 "EHLO dl5rb.ham-radio-op.net") by ftp.linux-mips.org with ESMTP id S20023900AbXJBLEj (ORCPT ); Tue, 2 Oct 2007 12:04:39 +0100 Received: from denk.linux-mips.net (denk.linux-mips.net [127.0.0.1]) by dl5rb.ham-radio-op.net (8.14.1/8.13.8) with ESMTP id l92B4cua006726; Tue, 2 Oct 2007 12:04:38 +0100 Received: (from ralf@localhost) by denk.linux-mips.net (8.14.1/8.14.1/Submit) id l92B4c97006725; Tue, 2 Oct 2007 12:04:38 +0100 Date: Tue, 2 Oct 2007 12:04:38 +0100 From: Ralf Baechle To: linux-kernel@vger.kernel.org, linux-mips@linux-mips.org Subject: What's in linux-mips.git for 2.6.24? Message-ID: <20071002110438.GA21065@linux-mips.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.14 (2007-02-12) Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 16784 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: ralf@linux-mips.org Precedence: bulk X-list: linux-mips The by far biggest item is support for tickless kernels on MIPS and the rewrite for many of the timer devices previously used as clocksources and clockevents. Various cleanups, including some moving of code and support for 32-bit Broadcom BCM47XX processors, the return of support for LASAT which isn't quite as unused as previously thought ... Ralf http://www.linux-mips.org/git?p=linux-queue.git;a=shortlog;h=queue Ahmed S. Darwish (1): [MIPS] Replace deprecated SA_* IRQ flags with modern IRQF_ variants. Atsushi Nemoto (2): [MIPS] tx4927: Cleanup unused macros and non-standard IO accessors. [MIPS] Kill redundant EXTRA_AFLAGS Aurelien Jarno (6): [MIPS] Add support for BCM47XX CPUs. [MIPS] Move CFE code into arch/mips/fw/cfe [MIPS] Move ARC code into arch/mips/fw/arc [MIPS] Add CFE support to BCM47XX [MIPS] Add gpio support to the BCM47XX platform [MIPS] GPIO LED driver for the WGT634U machine Brian Murphy (1): [MIPS] Add back support for LASAT platforms Florian Fainelli (1): [MIPS] MTX1: Add defconfig file Franck Bui-Huu (4): [MIPS] Remove '-mno-explicit-relocs' option when CONFIG_BUILD_ELF64 [MIPS] Automatically set CONFIG_BUILD_ELF64 [MIPS] Rename CONFIG_BUILD_ELF64 into KBUILD_64BIT_SYM32 [MIPS] Don't abort the build process if '-msym32' isn't supported Kevin D. Kissell (1): [MIPS] IRQ Affinity Support for SMTC on Malta Platform Maciej W. Rozycki (2): [MIPS] R3000 setup for kernel_thread() [MIPS] dec/time.c: Remove a leftover inclusion Ralf Baechle (25): [MIPS] SMTC: Microoptimize atomic_postincrement for non-weak consistency. [MIPS] PCI: Always enable CONFIG_PCI_DOMAINS [MIPS] floppy: Rewrite fd_cacheflush() to use dma_cache_sync(). [MIPS] Kill useless volatile keyword [MIPS] Sibyte: cleanup static inline forward declarations. [MIPS] Alchemy: remove useless prototypes. [MIPS] Sibyte: Replace SB1 cachecode with standard R4000 class cache code. [MIPS] Remove IP27 specific structures from struct cpuinfo_mips [MIPS] Split up war.h [MIPS] ARC: Convert mach_table[] to ISO C initializers. [MIPS] ARC: Get rid of mips_machgroup [MIPS] Use generic NTP code for all MIPS platforms [MIPS] Deforest the function pointer jungle in the time code. [MIPS] Switch from to_tm to rtc_time_to_tm [MIPS] Consolidate all variants of MIPS cp0 timer interrupt handlers. [MIPS] Implement clockevents for R4000-style cp0 count/compare interrupt [MIPS] Dyntick support for SMTC: [MIPS] Jazz clockevent driver [MIPS] IP27: Add clocksource drivers [MIPS] i8253 PIT clocksource and clockevent drivers [MIPS] Clockevent driver for BCM1250 [MIPS] Clockevent driver for BCM1480 [MIPS] Avoid indexed cacheops. [MIPS] Optimize __alloc_zeroed_user_highpage implementation. [MIPS] Optimize branch prediction in cmpxchg_local Sam Ravnborg (1): [MIPS] Introduce a consistent style for vmlinux.lds. Thiemo Seufer (1): [MIPS] Define known MIPS ISA overrides for Sibyte and Excite boards. Thomas Bogendoerfer (1): [MIPS] JAZZ fixes Thomas Gleixner (1): [MIPS] cleanup struct irqaction initializers Yoichi Yuasa (12): [MIPS] vr41xx: add cpu_wait [MIPS] VR41xx: Add default restart routine. [MIPS] VR41xx: replace infinite loop with hibernate [MIPS] IP27: remove duplicate extern dump_tlb_all() prototype [MIPS] remove unused include/asm-mips/ip32/machine.h [MIPS] fix ABI check in include/asm-mips/arv/hinv.h [MIPS] i8295 cleanups. [MIPS] GT64120: Remove unused definitions [MIPS] Add GT641xx IRQ routines. [MIPS] Cobalt: Add Cobalt Raq LED platform register and power off trigger [MIPS] Cobalt: Add Qube series front LED support to platform register [MIPS] Cobalt: Add LED support to cobalt_defconfig arch/mips/Kconfig | 98 arch/mips/Makefile | 48 arch/mips/au1000/common/irq.c | 15 arch/mips/au1000/common/setup.c | 2 arch/mips/au1000/common/time.c | 44 arch/mips/au1000/db1x00/init.c | 2 arch/mips/au1000/mtx-1/init.c | 1 arch/mips/au1000/pb1000/init.c | 1 arch/mips/au1000/pb1100/init.c | 1 arch/mips/au1000/pb1200/init.c | 1 arch/mips/au1000/pb1500/init.c | 1 arch/mips/au1000/pb1550/init.c | 1 arch/mips/au1000/xxs1500/init.c | 1 arch/mips/basler/excite/excite_prom.c | 1 arch/mips/basler/excite/excite_setup.c | 5 arch/mips/bcm47xx/Makefile | 6 arch/mips/bcm47xx/gpio.c | 79 arch/mips/bcm47xx/irq.c | 55 arch/mips/bcm47xx/prom.c | 158 + arch/mips/bcm47xx/serial.c | 52 arch/mips/bcm47xx/setup.c | 123 + arch/mips/bcm47xx/time.c | 55 arch/mips/bcm47xx/wgt634u.c | 64 arch/mips/cobalt/Makefile | 2 arch/mips/cobalt/irq.c | 116 - arch/mips/cobalt/led.c | 62 arch/mips/cobalt/reset.c | 22 arch/mips/cobalt/rtc.c | 5 arch/mips/cobalt/serial.c | 7 arch/mips/cobalt/setup.c | 17 arch/mips/configs/bigsur_defconfig | 1 arch/mips/configs/cobalt_defconfig | 23 arch/mips/configs/lasat_defconfig | 828 ++++ arch/mips/configs/mtx1_defconfig | 3115 +++++++++++++++ arch/mips/configs/sb1250-swarm_defconfig | 1 arch/mips/dec/prom/identify.c | 3 arch/mips/dec/setup.c | 4 arch/mips/dec/time.c | 13 arch/mips/emma2rh/common/prom.c | 2 arch/mips/emma2rh/markeins/setup.c | 4 arch/mips/fw/arc/Makefile | 0 arch/mips/fw/arc/arc_con.c | 0 arch/mips/fw/arc/cmdline.c | 0 arch/mips/fw/arc/env.c | 2 arch/mips/fw/arc/file.c | 2 arch/mips/fw/arc/identify.c | 82 arch/mips/fw/arc/init.c | 0 arch/mips/fw/arc/memory.c | 0 arch/mips/fw/arc/misc.c | 2 arch/mips/fw/arc/promlib.c | 0 arch/mips/fw/arc/salone.c | 0 arch/mips/fw/arc/time.c | 2 arch/mips/fw/arc/tree.c | 2 arch/mips/fw/cfe/Makefile | 5 arch/mips/fw/cfe/cfe_api.c | 2 arch/mips/fw/cfe/cfe_api_int.h | 0 arch/mips/gt64120/wrppmc/setup.c | 5 arch/mips/gt64120/wrppmc/time.c | 2 arch/mips/jazz/Makefile | 2 arch/mips/jazz/irq.c | 142 - arch/mips/jazz/jazz-platform.c | 60 arch/mips/jazz/jazzdma.c | 47 arch/mips/jazz/setup.c | 128 + arch/mips/jmr3927/rbhma3100/init.c | 1 arch/mips/jmr3927/rbhma3100/irq.c | 8 arch/mips/jmr3927/rbhma3100/setup.c | 4 arch/mips/kernel/Makefile | 2 arch/mips/kernel/cpu-probe.c | 28 arch/mips/kernel/i8253.c | 213 + arch/mips/kernel/i8259.c | 21 arch/mips/kernel/irq-gt641xx.c | 131 + arch/mips/kernel/proc.c | 2 arch/mips/kernel/process.c | 7 arch/mips/kernel/setup.c | 2 arch/mips/kernel/smp.c | 2 arch/mips/kernel/smtc.c | 132 - arch/mips/kernel/time.c | 414 +- arch/mips/kernel/traps.c | 10 arch/mips/kernel/vmlinux.lds.S | 339 +- arch/mips/lasat/Kconfig | 15 arch/mips/lasat/Makefile | 16 arch/mips/lasat/at93c.c | 149 + arch/mips/lasat/at93c.h | 18 arch/mips/lasat/ds1603.c | 183 + arch/mips/lasat/ds1603.h | 31 arch/mips/lasat/image/Makefile | 54 arch/mips/lasat/image/head.S | 31 arch/mips/lasat/image/romscript.normal | 23 arch/mips/lasat/interrupt.c | 130 + arch/mips/lasat/lasat_board.c | 280 + arch/mips/lasat/lasat_models.h | 67 arch/mips/lasat/picvue.c | 244 + arch/mips/lasat/picvue.h | 48 arch/mips/lasat/picvue_proc.c | 191 + arch/mips/lasat/prom.c | 126 + arch/mips/lasat/prom.h | 7 arch/mips/lasat/reset.c | 61 arch/mips/lasat/serial.c | 94 arch/mips/lasat/setup.c | 154 + arch/mips/lasat/sysctl.c | 456 ++ arch/mips/lasat/sysctl.h | 24 arch/mips/lemote/lm2e/Makefile | 1 arch/mips/lemote/lm2e/prom.c | 1 arch/mips/lemote/lm2e/setup.c | 7 arch/mips/mips-boards/atlas/atlas_setup.c | 5 arch/mips/mips-boards/generic/time.c | 141 - arch/mips/mips-boards/malta/malta_setup.c | 4 arch/mips/mips-boards/malta/malta_smtc.c | 50 arch/mips/mips-boards/sead/sead_setup.c | 3 arch/mips/mipssim/sim_setup.c | 2 arch/mips/mipssim/sim_time.c | 74 arch/mips/mm/Makefile | 2 arch/mips/mm/c-r4k.c | 96 arch/mips/mm/c-sb1.c | 535 --- arch/mips/mm/cache.c | 9 arch/mips/mm/pg-sb1.c | 8 arch/mips/mm/tlbex.c | 2 arch/mips/pci/Makefile | 2 arch/mips/pci/fixup-cobalt.c | 23 arch/mips/pci/ops-nile4.c | 147 + arch/mips/pci/ops-pmcmsp.c | 2 arch/mips/pci/pci-lasat.c | 91 arch/mips/philips/pnx8550/common/setup.c | 3 arch/mips/philips/pnx8550/common/time.c | 7 arch/mips/philips/pnx8550/jbs/init.c | 1 arch/mips/philips/pnx8550/stb810/prom_init.c | 1 arch/mips/pmc-sierra/msp71xx/msp_hwbutton.c | 2 arch/mips/pmc-sierra/msp71xx/msp_setup.c | 18 arch/mips/pmc-sierra/msp71xx/msp_time.c | 3 arch/mips/pmc-sierra/yosemite/prom.c | 1 arch/mips/pmc-sierra/yosemite/setup.c | 26 arch/mips/qemu/q-irq.c | 4 arch/mips/qemu/q-setup.c | 10 arch/mips/sgi-ip22/ip22-int.c | 5 arch/mips/sgi-ip22/ip22-setup.c | 2 arch/mips/sgi-ip22/ip22-time.c | 35 arch/mips/sgi-ip27/ip27-berr.c | 2 arch/mips/sgi-ip27/ip27-init.c | 6 arch/mips/sgi-ip27/ip27-smp.c | 2 arch/mips/sgi-ip27/ip27-timer.c | 38 arch/mips/sgi-ip32/ip32-irq.c | 18 arch/mips/sgi-ip32/ip32-setup.c | 12 arch/mips/sibyte/Kconfig | 13 arch/mips/sibyte/bcm1480/irq.c | 13 arch/mips/sibyte/bcm1480/setup.c | 78 arch/mips/sibyte/bcm1480/time.c | 118 - arch/mips/sibyte/cfe/Makefile | 2 arch/mips/sibyte/cfe/console.c | 4 arch/mips/sibyte/cfe/setup.c | 5 arch/mips/sibyte/cfe/smp.c | 4 arch/mips/sibyte/common/Makefile | 1 arch/mips/sibyte/sb1250/irq.c | 50 arch/mips/sibyte/sb1250/prom.c | 1 arch/mips/sibyte/sb1250/setup.c | 74 arch/mips/sibyte/sb1250/time.c | 198 + arch/mips/sibyte/swarm/rtc_m41t81.c | 3 arch/mips/sibyte/swarm/rtc_xicor1241.c | 3 arch/mips/sibyte/swarm/setup.c | 56 arch/mips/sni/pcimt.c | 1 arch/mips/sni/pcit.c | 1 arch/mips/sni/rm200.c | 1 arch/mips/sni/setup.c | 2 arch/mips/sni/time.c | 11 arch/mips/tx4927/common/tx4927_dbgio.c | 1 arch/mips/tx4927/common/tx4927_prom.c | 12 arch/mips/tx4927/common/tx4927_setup.c | 20 .../tx4927/toshiba_rbtx4927/toshiba_rbtx4927_irq.c | 31 .../toshiba_rbtx4927/toshiba_rbtx4927_prom.c | 2 .../toshiba_rbtx4927/toshiba_rbtx4927_setup.c | 32 arch/mips/tx4938/common/setup.c | 9 arch/mips/tx4938/toshiba_rbtx4938/prom.c | 1 arch/mips/tx4938/toshiba_rbtx4938/setup.c | 3 arch/mips/vr41xx/common/init.c | 8 arch/mips/vr41xx/common/pmu.c | 36 arch/mips/vr41xx/nec-cmbvr4133/setup.c | 1 drivers/video/logo/logo.c | 10 include/asm-mips/bootinfo.h | 41 include/asm-mips/cpu-features.h | 3 include/asm-mips/cpu-info.h | 18 include/asm-mips/cpu.h | 47 include/asm-mips/floppy.h | 4 include/asm-mips/fw/arc/hinv.h | 5 include/asm-mips/fw/arc/types.h | 0 include/asm-mips/fw/cfe/cfe_api.h | 0 include/asm-mips/fw/cfe/cfe_error.h | 0 include/asm-mips/hw_irq.h | 7 include/asm-mips/i8253.h | 30 include/asm-mips/i8259.h | 5 include/asm-mips/ip32/machine.h | 20 include/asm-mips/irq.h | 67 include/asm-mips/irq_gt641xx.h | 60 include/asm-mips/jazz.h | 40 include/asm-mips/jazzdma.h | 1 include/asm-mips/lasat/ds1603.h | 18 include/asm-mips/lasat/eeprom.h | 17 include/asm-mips/lasat/head.h | 22 include/asm-mips/lasat/lasat.h | 256 + include/asm-mips/lasat/lasatint.h | 12 include/asm-mips/lasat/picvue.h | 15 include/asm-mips/lasat/serial.h | 13 include/asm-mips/linkage.h | 2 include/asm-mips/mach-au1x00/war.h | 25 include/asm-mips/mach-bcm47xx/bcm47xx.h | 25 include/asm-mips/mach-bcm47xx/gpio.h | 59 include/asm-mips/mach-bcm47xx/war.h | 25 include/asm-mips/mach-cobalt/cobalt.h | 26 .../asm-mips/mach-cobalt/cpu-feature-overrides.h | 1 include/asm-mips/mach-cobalt/irq.h | 58 include/asm-mips/mach-cobalt/war.h | 25 include/asm-mips/mach-dec/war.h | 25 include/asm-mips/mach-emma2rh/war.h | 25 .../asm-mips/mach-excite/cpu-feature-overrides.h | 5 include/asm-mips/mach-excite/war.h | 25 include/asm-mips/mach-ip22/war.h | 29 include/asm-mips/mach-ip27/irq.h | 2 include/asm-mips/mach-ip27/topology.h | 20 include/asm-mips/mach-ip27/war.h | 25 include/asm-mips/mach-ip32/war.h | 25 include/asm-mips/mach-jazz/mc146818rtc.h | 10 include/asm-mips/mach-jazz/war.h | 25 include/asm-mips/mach-jmr3927/war.h | 25 include/asm-mips/mach-lasat/mach-gt64120.h | 27 include/asm-mips/mach-lasat/war.h | 25 include/asm-mips/mach-lemote/war.h | 25 include/asm-mips/mach-mips/mach-gt64120.h | 9 include/asm-mips/mach-mips/war.h | 25 include/asm-mips/mach-mipssim/war.h | 25 include/asm-mips/mach-pnx8550/war.h | 25 include/asm-mips/mach-qemu/war.h | 25 include/asm-mips/mach-rm/war.h | 29 .../asm-mips/mach-sibyte/cpu-feature-overrides.h | 7 include/asm-mips/mach-sibyte/war.h | 37 include/asm-mips/mach-tx49xx/war.h | 25 include/asm-mips/mach-vr41xx/war.h | 25 include/asm-mips/mach-wrppmc/mach-gt64120.h | 1 include/asm-mips/mach-wrppmc/war.h | 25 include/asm-mips/mach-yosemite/war.h | 25 include/asm-mips/nile4.h | 310 + include/asm-mips/pci.h | 4 include/asm-mips/pgtable-64.h | 2 include/asm-mips/qemu.h | 2 include/asm-mips/sgiarcs.h | 2 include/asm-mips/smtc_ipi.h | 1 include/asm-mips/sn/arch.h | 4 include/asm-mips/sn/klconfig.h | 4 include/asm-mips/stackframe.h | 12 include/asm-mips/system.h | 16 include/asm-mips/time.h | 41 include/asm-mips/tx4927/toshiba_rbtx4927.h | 8 include/asm-mips/tx4927/tx4927.h | 439 -- include/asm-mips/tx4927/tx4927_mips.h | 4177 -------------------- include/asm-mips/war.h | 127 - 252 files changed, 11104 insertions(+), 7049 deletions(-) create mode 100644 arch/mips/bcm47xx/Makefile create mode 100644 arch/mips/bcm47xx/gpio.c create mode 100644 arch/mips/bcm47xx/irq.c create mode 100644 arch/mips/bcm47xx/prom.c create mode 100644 arch/mips/bcm47xx/serial.c create mode 100644 arch/mips/bcm47xx/setup.c create mode 100644 arch/mips/bcm47xx/time.c create mode 100644 arch/mips/bcm47xx/wgt634u.c create mode 100644 arch/mips/cobalt/led.c create mode 100644 arch/mips/configs/lasat_defconfig create mode 100644 arch/mips/configs/mtx1_defconfig rename arch/mips/{arc/Makefile => fw/arc/Makefile} (100%) rename arch/mips/{arc/arc_con.c => fw/arc/arc_con.c} (100%) rename arch/mips/{arc/cmdline.c => fw/arc/cmdline.c} (100%) rename arch/mips/{arc/env.c => fw/arc/env.c} (95%) rename arch/mips/{arc/file.c => fw/arc/file.c} (98%) rename arch/mips/{arc/identify.c => fw/arc/identify.c} (65%) rename arch/mips/{arc/init.c => fw/arc/init.c} (100%) rename arch/mips/{arc/memory.c => fw/arc/memory.c} (100%) rename arch/mips/{arc/misc.c => fw/arc/misc.c} (98%) rename arch/mips/{arc/promlib.c => fw/arc/promlib.c} (100%) rename arch/mips/{arc/salone.c => fw/arc/salone.c} (100%) rename arch/mips/{arc/time.c => fw/arc/time.c} (94%) rename arch/mips/{arc/tree.c => fw/arc/tree.c} (99%) create mode 100644 arch/mips/fw/cfe/Makefile rename arch/mips/{sibyte/cfe/cfe_api.c => fw/cfe/cfe_api.c} (100%) rename arch/mips/{sibyte/cfe/cfe_api_int.h => fw/cfe/cfe_api_int.h} (100%) delete mode 100644 arch/mips/jazz/jazz-platform.c create mode 100644 arch/mips/kernel/i8253.c create mode 100644 arch/mips/kernel/irq-gt641xx.c create mode 100644 arch/mips/lasat/Kconfig create mode 100644 arch/mips/lasat/Makefile create mode 100644 arch/mips/lasat/at93c.c create mode 100644 arch/mips/lasat/at93c.h create mode 100644 arch/mips/lasat/ds1603.c create mode 100644 arch/mips/lasat/ds1603.h create mode 100644 arch/mips/lasat/image/Makefile create mode 100644 arch/mips/lasat/image/head.S create mode 100644 arch/mips/lasat/image/romscript.normal create mode 100644 arch/mips/lasat/interrupt.c create mode 100644 arch/mips/lasat/lasat_board.c create mode 100644 arch/mips/lasat/lasat_models.h create mode 100644 arch/mips/lasat/picvue.c create mode 100644 arch/mips/lasat/picvue.h create mode 100644 arch/mips/lasat/picvue_proc.c create mode 100644 arch/mips/lasat/prom.c create mode 100644 arch/mips/lasat/prom.h create mode 100644 arch/mips/lasat/reset.c create mode 100644 arch/mips/lasat/serial.c create mode 100644 arch/mips/lasat/setup.c create mode 100644 arch/mips/lasat/sysctl.c create mode 100644 arch/mips/lasat/sysctl.h delete mode 100644 arch/mips/mm/c-sb1.c create mode 100644 arch/mips/pci/ops-nile4.c create mode 100644 arch/mips/pci/pci-lasat.c rename include/asm-mips/{arc/hinv.h => fw/arc/hinv.h} (97%) rename include/asm-mips/{arc/types.h => fw/arc/types.h} (100%) rename arch/mips/sibyte/cfe/cfe_api.h => include/asm-mips/fw/cfe/cfe_api.h (100%) rename arch/mips/sibyte/cfe/cfe_error.h => include/asm-mips/fw/cfe/cfe_error.h (100%) create mode 100644 include/asm-mips/i8253.h delete mode 100644 include/asm-mips/ip32/machine.h create mode 100644 include/asm-mips/irq_gt641xx.h create mode 100644 include/asm-mips/lasat/ds1603.h create mode 100644 include/asm-mips/lasat/eeprom.h create mode 100644 include/asm-mips/lasat/head.h create mode 100644 include/asm-mips/lasat/lasat.h create mode 100644 include/asm-mips/lasat/lasatint.h create mode 100644 include/asm-mips/lasat/picvue.h create mode 100644 include/asm-mips/lasat/serial.h create mode 100644 include/asm-mips/mach-au1x00/war.h create mode 100644 include/asm-mips/mach-bcm47xx/bcm47xx.h create mode 100644 include/asm-mips/mach-bcm47xx/gpio.h create mode 100644 include/asm-mips/mach-bcm47xx/war.h create mode 100644 include/asm-mips/mach-cobalt/irq.h create mode 100644 include/asm-mips/mach-cobalt/war.h create mode 100644 include/asm-mips/mach-dec/war.h create mode 100644 include/asm-mips/mach-emma2rh/war.h create mode 100644 include/asm-mips/mach-excite/war.h create mode 100644 include/asm-mips/mach-ip22/war.h create mode 100644 include/asm-mips/mach-ip27/war.h create mode 100644 include/asm-mips/mach-ip32/war.h create mode 100644 include/asm-mips/mach-jazz/war.h create mode 100644 include/asm-mips/mach-jmr3927/war.h create mode 100644 include/asm-mips/mach-lasat/mach-gt64120.h create mode 100644 include/asm-mips/mach-lasat/war.h create mode 100644 include/asm-mips/mach-lemote/war.h create mode 100644 include/asm-mips/mach-mips/war.h create mode 100644 include/asm-mips/mach-mipssim/war.h create mode 100644 include/asm-mips/mach-pnx8550/war.h create mode 100644 include/asm-mips/mach-qemu/war.h create mode 100644 include/asm-mips/mach-rm/war.h create mode 100644 include/asm-mips/mach-sibyte/war.h create mode 100644 include/asm-mips/mach-tx49xx/war.h create mode 100644 include/asm-mips/mach-vr41xx/war.h create mode 100644 include/asm-mips/mach-wrppmc/war.h create mode 100644 include/asm-mips/mach-yosemite/war.h create mode 100644 include/asm-mips/nile4.h delete mode 100644 include/asm-mips/tx4927/tx4927_mips.h From macro@linux-mips.org Tue Oct 2 12:39:37 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 02 Oct 2007 12:39:46 +0100 (BST) Received: from cerber.ds.pg.gda.pl ([153.19.208.18]:46314 "EHLO cerber.ds.pg.gda.pl") by ftp.linux-mips.org with ESMTP id S20023881AbXJBLjh (ORCPT ); Tue, 2 Oct 2007 12:39:37 +0100 Received: from localhost (unknown [127.0.0.17]) by cerber.ds.pg.gda.pl (Postfix) with ESMTP id EBEF5400FE; Tue, 2 Oct 2007 13:39:36 +0200 (CEST) X-Virus-Scanned: amavisd-new at cerber.ds.pg.gda.pl Received: from cerber.ds.pg.gda.pl ([153.19.208.18]) by localhost (cerber.ds.pg.gda.pl [153.19.208.18]) (amavisd-new, port 10024) with ESMTP id cziddk+uzHvj; Tue, 2 Oct 2007 13:39:32 +0200 (CEST) Received: from piorun.ds.pg.gda.pl (piorun.ds.pg.gda.pl [153.19.208.8]) by cerber.ds.pg.gda.pl (Postfix) with ESMTP id 9E20240040; Tue, 2 Oct 2007 13:39:32 +0200 (CEST) Received: from blysk.ds.pg.gda.pl (macro@blysk.ds.pg.gda.pl [153.19.208.6]) by piorun.ds.pg.gda.pl (8.13.8/8.13.8) with ESMTP id l92BdZ89024317; Tue, 2 Oct 2007 13:39:36 +0200 Date: Tue, 2 Oct 2007 12:39:31 +0100 (BST) From: "Maciej W. Rozycki" To: Giuseppe Sacco cc: linux-mips@linux-mips.org Subject: Re: Using PCI bridges on sgi-ip32: CONFIG_PCI_DEBUG In-Reply-To: <20071002030133.fd5f6315.giuseppe@eppesuigoccas.homedns.org> Message-ID: References: <1190973427.11251.17.camel@scarafaggio> <1191141276.7160.44.camel@scarafaggio> <20071002030133.fd5f6315.giuseppe@eppesuigoccas.homedns.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: ClamAV 0.91.2/4452/Tue Oct 2 07:03:17 2007 on piorun.ds.pg.gda.pl X-Virus-Status: Clean Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 16785 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: macro@linux-mips.org Precedence: bulk X-list: linux-mips On Tue, 2 Oct 2007, Giuseppe Sacco wrote: > PCI: Fixups for bus 0000:00 > PCI: Scanning behind PCI bridge 0000:00:03.0, config ffffff, pass 0 > PCI: Scanning behind PCI bridge 0000:00:03.0, config 000000, pass 1 > PCI: Scanning bus 0000:01 > PCI: Fixups for bus 0000:01 > PCI: Bus scan for 0000:01 returning with max=01 > PCI: Bus scan for 0000:00 returning with max=01 So it looks like the generic PCI code does scan behind the bridge at 0000:00:03.0, but nothing is found. So the first obvious question is: "Does your host bridge (or actually code that handles it) correctly generate type 1 PCI configuration cycles?" It looks like arch/mips/pci/ops-mace.c is the place to look for possible breakage. Well, actually chkslot() there is the obvious answer. It is probably easy to fix, but for somebody with documentation or at least the right piece of hardware, so I do not qualify, I am afraid. Sorry. Failing anybody else, you may be able to figure it out yourself -- you probably need to stick bus->number into mace->pci.config_addr somewhere. Try bits 23:16 as the obvious first guess. Maciej From macro@linux-mips.org Tue Oct 2 14:47:28 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 02 Oct 2007 14:47:37 +0100 (BST) Received: from cerber.ds.pg.gda.pl ([153.19.208.18]:59550 "EHLO cerber.ds.pg.gda.pl") by ftp.linux-mips.org with ESMTP id S20024135AbXJBNr2 (ORCPT ); Tue, 2 Oct 2007 14:47:28 +0100 Received: from localhost (unknown [127.0.0.17]) by cerber.ds.pg.gda.pl (Postfix) with ESMTP id D46EE400FD; Tue, 2 Oct 2007 15:47:28 +0200 (CEST) X-Virus-Scanned: amavisd-new at cerber.ds.pg.gda.pl Received: from cerber.ds.pg.gda.pl ([153.19.208.18]) by localhost (cerber.ds.pg.gda.pl [153.19.208.18]) (amavisd-new, port 10024) with ESMTP id gXEBWqqOTnWo; Tue, 2 Oct 2007 15:47:23 +0200 (CEST) Received: from piorun.ds.pg.gda.pl (piorun.ds.pg.gda.pl [153.19.208.8]) by cerber.ds.pg.gda.pl (Postfix) with ESMTP id 2480240040; Tue, 2 Oct 2007 15:47:23 +0200 (CEST) Received: from blysk.ds.pg.gda.pl (macro@blysk.ds.pg.gda.pl [153.19.208.6]) by piorun.ds.pg.gda.pl (8.13.8/8.13.8) with ESMTP id l92DlQur013790; Tue, 2 Oct 2007 15:47:27 +0200 Date: Tue, 2 Oct 2007 14:47:22 +0100 (BST) From: "Maciej W. Rozycki" To: Ralf Baechle , Thiemo Seufer cc: linux-mips@linux-mips.org Subject: [PATCH] mm/pg-r4k.c: Fix a typo in an R4600 v2 erratum workaround Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: ClamAV 0.91.2/4452/Tue Oct 2 07:03:17 2007 on piorun.ds.pg.gda.pl X-Virus-Status: Clean Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 16786 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: macro@linux-mips.org Precedence: bulk X-list: linux-mips Restore a load from KSEG1 done as a workaround for an R4600 v2 erratum, dropped with 211be16de99a7424e66c0b6c0d00e2c970508ac2. Signed-off-by: Maciej W. Rozycki --- Thiemo, It reverts your change of Sep 1st, 2005; given the way the code is written, I am assuming the change was accidental, correct? At the moment the load never happens. Ralf, please apply. Maciej patch-mips-2.6.23-rc5-20070904-pg-r4k-r4600-0 diff -up --recursive --new-file linux-mips-2.6.23-rc5-20070904.macro/arch/mips/mm/pg-r4k.c linux-mips-2.6.23-rc5-20070904/arch/mips/mm/pg-r4k.c --- linux-mips-2.6.23-rc5-20070904.macro/arch/mips/mm/pg-r4k.c 2007-02-05 16:38:47.000000000 +0000 +++ linux-mips-2.6.23-rc5-20070904/arch/mips/mm/pg-r4k.c 2007-10-02 00:15:33.000000000 +0000 @@ -209,7 +209,7 @@ static inline void build_cdex_p(void) } if (R4600_V2_HIT_CACHEOP_WAR && cpu_is_r4600_v2_x()) - build_insn_word(0x3c01a000); /* lui $at, 0xa000 */ + build_insn_word(0x8c200000); /* lw $zero, ($at) */ mi.c_format.opcode = cache_op; mi.c_format.rs = 4; /* $a0 */ From macro@linux-mips.org Tue Oct 2 14:54:22 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 02 Oct 2007 14:54:30 +0100 (BST) Received: from cerber.ds.pg.gda.pl ([153.19.208.18]:18923 "EHLO cerber.ds.pg.gda.pl") by ftp.linux-mips.org with ESMTP id S20024233AbXJBNyW (ORCPT ); Tue, 2 Oct 2007 14:54:22 +0100 Received: from localhost (unknown [127.0.0.17]) by cerber.ds.pg.gda.pl (Postfix) with ESMTP id 527174010F; Tue, 2 Oct 2007 15:54:22 +0200 (CEST) X-Virus-Scanned: amavisd-new at cerber.ds.pg.gda.pl Received: from cerber.ds.pg.gda.pl ([153.19.208.18]) by localhost (cerber.ds.pg.gda.pl [153.19.208.18]) (amavisd-new, port 10024) with ESMTP id CCQEDd23Xd9C; Tue, 2 Oct 2007 15:54:16 +0200 (CEST) Received: from piorun.ds.pg.gda.pl (piorun.ds.pg.gda.pl [153.19.208.8]) by cerber.ds.pg.gda.pl (Postfix) with ESMTP id 5837B40040; Tue, 2 Oct 2007 15:54:16 +0200 (CEST) Received: from blysk.ds.pg.gda.pl (macro@blysk.ds.pg.gda.pl [153.19.208.6]) by piorun.ds.pg.gda.pl (8.13.8/8.13.8) with ESMTP id l92DsKoK014880; Tue, 2 Oct 2007 15:54:20 +0200 Date: Tue, 2 Oct 2007 14:54:15 +0100 (BST) From: "Maciej W. Rozycki" To: Ralf Baechle , Thiemo Seufer cc: linux-mips@linux-mips.org Subject: [PATCH] mm/pg-r4k.c: Dump the generated code Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: ClamAV 0.91.2/4452/Tue Oct 2 07:03:17 2007 on piorun.ds.pg.gda.pl X-Virus-Status: Clean Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 16787 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: macro@linux-mips.org Precedence: bulk X-list: linux-mips Dump the generated code for clear/copy page calls like it is done for TLB fault handlers. Useful for debugging. Signed-off-by: Maciej W. Rozycki --- Thiemo, It was your change to add ".set noreorder", etc. to the TLB fault handlers -- what is it needed for? I have thought gas does not try to outsmart the user at the moment and does not reorder ".word" directives. Ralf, please apply. Maciej patch-mips-2.6.23-rc5-20070904-pg-r4k-dump-0 diff -up --recursive --new-file linux-mips-2.6.23-rc5-20070904.macro/arch/mips/mm/pg-r4k.c linux-mips-2.6.23-rc5-20070904/arch/mips/mm/pg-r4k.c --- linux-mips-2.6.23-rc5-20070904.macro/arch/mips/mm/pg-r4k.c 2007-02-05 16:38:47.000000000 +0000 +++ linux-mips-2.6.23-rc5-20070904/arch/mips/mm/pg-r4k.c 2007-10-01 22:50:13.000000000 +0000 @@ -347,6 +347,7 @@ void __init build_clear_page(void) { unsigned int loop_start; unsigned long off; + int i; epc = (unsigned int *) &clear_page_array; instruction_pending = 0; @@ -434,12 +435,22 @@ dest = label(); build_jr_ra(); BUG_ON(epc > clear_page_array + ARRAY_SIZE(clear_page_array)); + + pr_info("Synthesized clear page handler (%u instructions).\n", + (unsigned int)(epc - clear_page_array)); + + pr_debug("\t.set push\n"); + pr_debug("\t.set noreorder\n"); + for (i = 0; i < (epc - clear_page_array); i++) + pr_debug("\t.word 0x%08x\n", clear_page_array[i]); + pr_debug("\t.set pop\n"); } void __init build_copy_page(void) { unsigned int loop_start; unsigned long off; + int i; epc = (unsigned int *) ©_page_array; store_offset = load_offset = 0; @@ -515,4 +526,13 @@ dest = label(); build_jr_ra(); BUG_ON(epc > copy_page_array + ARRAY_SIZE(copy_page_array)); + + pr_info("Synthesized copy page handler (%u instructions).\n", + (unsigned int)(epc - copy_page_array)); + + pr_debug("\t.set push\n"); + pr_debug("\t.set noreorder\n"); + for (i = 0; i < (epc - copy_page_array); i++) + pr_debug("\t.word 0x%08x\n", copy_page_array[i]); + pr_debug("\t.set pop\n"); } From ths@networkno.de Tue Oct 2 15:11:33 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 02 Oct 2007 15:11:41 +0100 (BST) Received: from mail.bawue.net ([193.7.176.63]:993 "EHLO mail.bawue.net") by ftp.linux-mips.org with ESMTP id S20023827AbXJBOLd (ORCPT ); Tue, 2 Oct 2007 15:11:33 +0100 Received: from lagash (intrt.mips-uk.com [194.74.144.130]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by mail.bawue.net (Postfix) with ESMTP id EE2B2E0060; Tue, 2 Oct 2007 16:11:37 +0200 (CEST) Received: from ths by lagash with local (Exim 4.67) (envelope-from ) id 1IciT8-0003Kq-4a; Tue, 02 Oct 2007 15:11:26 +0100 Date: Tue, 2 Oct 2007 15:11:26 +0100 From: Thiemo Seufer To: "Maciej W. Rozycki" Cc: Ralf Baechle , linux-mips@linux-mips.org Subject: Re: [PATCH] mm/pg-r4k.c: Dump the generated code Message-ID: <20071002141125.GC16772@networkno.de> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.16 (2007-06-11) Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 16788 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: ths@networkno.de Precedence: bulk X-list: linux-mips Maciej W. Rozycki wrote: > Dump the generated code for clear/copy page calls like it is done for TLB > fault handlers. Useful for debugging. > > Signed-off-by: Maciej W. Rozycki > --- > Thiemo, > > It was your change to add ".set noreorder", etc. to the TLB fault > handlers -- what is it needed for? I have thought gas does not try to > outsmart the user at the moment and does not reorder ".word" directives. It is not strictly needed, but it is a hint to the user that he looks at raw instructions. Thiemo From ths@networkno.de Tue Oct 2 15:22:18 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 02 Oct 2007 15:22:28 +0100 (BST) Received: from mail.bawue.net ([193.7.176.63]:60909 "EHLO mail.bawue.net") by ftp.linux-mips.org with ESMTP id S20023830AbXJBOWS (ORCPT ); Tue, 2 Oct 2007 15:22:18 +0100 Received: from lagash (intrt.mips-uk.com [194.74.144.130]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by mail.bawue.net (Postfix) with ESMTP id 86D80E0051; Tue, 2 Oct 2007 16:22:21 +0200 (CEST) Received: from ths by lagash with local (Exim 4.67) (envelope-from ) id 1IcidW-0003NT-Dg; Tue, 02 Oct 2007 15:22:10 +0100 Date: Tue, 2 Oct 2007 15:22:10 +0100 From: Thiemo Seufer To: Ralf Baechle Cc: Fuxin Zhang , linux-mips@linux-mips.org Subject: Re: cmpxchg broken in some situation Message-ID: <20071002142210.GD16772@networkno.de> References: <46FF7BC2.5050905@ict.ac.cn> <20071001025340.GA7091@linux-mips.org> <47010E15.7060109@ict.ac.cn> <20071001152620.GB15820@linux-mips.org> <470210B4.8020902@ict.ac.cn> <20071002103551.GB5152@linux-mips.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20071002103551.GB5152@linux-mips.org> User-Agent: Mutt/1.5.16 (2007-06-11) Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 16789 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: ths@networkno.de Precedence: bulk X-list: linux-mips Ralf Baechle wrote: > On Tue, Oct 02, 2007 at 05:34:44PM +0800, Fuxin Zhang wrote: > > > The problem is here: > > > > switch (sizeof(__ptr)) { // --> should be sizeof(*(__ptr)) > > case 4: > > ... > > Recompiling.. > > There was another small kink, cmpxchg_local() does not imply a memory > barrier so I optimized that case. > > And I don't complain about it being 151 lines shorter ;-) > > Ralf > > From: Ralf Baechle > > [MIPS] Typeproof reimplementation of cmpxchg. > > Signed-off-by: Ralf Baechle > > diff --git a/include/asm-mips/cmpxchg.h b/include/asm-mips/cmpxchg.h > new file mode 100644 > index 0000000..46bac47 > --- /dev/null > +++ b/include/asm-mips/cmpxchg.h > @@ -0,0 +1,107 @@ > +/* > + * 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) 2003, 06, 07 by Ralf Baechle (ralf@linux-mips.org) > + */ > +#ifndef __ASM_CMPXCHG_H > +#define __ASM_CMPXCHG_H > + > +#include > + > +#define __HAVE_ARCH_CMPXCHG 1 > + > +#define __cmpxchg_asm(ld, st, m, old, new) \ > +({ \ > + __typeof(*(m)) __ret; \ > + \ > + if (cpu_has_llsc && R10000_LLSC_WAR) { \ > + __asm__ __volatile__( \ > + " .set push \n" \ > + " .set noat \n" \ > + " .set mips3 \n" \ > + "1: " ld " %0, %2 # __cmpxchg_u32 \n" \ > + " bne %0, %z3, 2f \n" \ > + " .set mips0 \n" \ > + " move $1, %z4 \n" \ > + " .set mips3 \n" \ > + " " st " $1, %1 \n" \ > + " beqzl $1, 1b \n" \ > + "2: \n" \ > + " .set pop \n" \ > + : "=&r" (__ret), "=R" (*m) \ > + : "R" (*m), "Jr" (old), "Jr" (new) \ > + : "memory"); \ > + } else if (cpu_has_llsc) { \ > + __asm__ __volatile__( \ > + " .set push \n" \ > + " .set noat \n" \ > + " .set mips3 \n" \ > + "1: " ld " %0, %2 # __cmpxchg_u32 \n" \ > + " bne %0, %z3, 2f \n" \ > + " .set mips0 \n" \ > + " move $1, %z4 \n" \ > + " .set mips3 \n" \ > + " " st " $1, %1 \n" \ > + " beqz $1, 3f \n" \ > + "2: \n" \ > + " .subsection 2 \n" \ > + "3: b 1b \n" \ > + " .previous \n" \ > + " .set pop \n" \ > + : "=&r" (__ret), "=R" (*m) \ > + : "R" (*m), "Jr" (old), "Jr" (new) \ > + : "memory"); \ > + } else { \ > + unsigned long __flags; \ > + \ > + raw_local_irq_save(__flags); \ > + __ret = *m; \ > + if (__ret == old) \ > + *m = new; \ > + raw_local_irq_restore(__flags); \ > + } \ > + \ > + smp_llsc_mb(); \ I think this line is surplus. > + \ > + __ret; \ > +}) > + > +/* > + * This function doesn't exist, so you'll get a linker error > + * if something tries to do an invalid cmpxchg(). > + */ > +extern void __cmpxchg_called_with_bad_pointer(void); > + > +#define __cmpxchg(ptr,old,new,barrier) \ > +({ \ > + __typeof__(ptr) __ptr = (ptr); \ > + __typeof__(*(ptr)) __old = (old); \ > + __typeof__(*(ptr)) __new = (new); \ > + __typeof__(*(ptr)) __res = 0; \ Maybe we need an acquire barrier here for some systems. > + switch (sizeof(*(__ptr))) { \ > + case 4: \ > + __res = __cmpxchg_asm("ll", "sc", __ptr, __old, __new); \ > + break; \ > + case 8: \ > + if (sizeof(long) == 8) { \ > + __res = __cmpxchg_asm("lld", "scd", __ptr, \ > + __old, __new); \ > + break; \ > + } \ > + default: \ > + __cmpxchg_called_with_bad_pointer(); \ > + break; \ > + } \ > + \ > + barrier; \ > + \ > + __res; \ > +}) > + > +#define cmpxchg(ptr, old, new) __cmpxchg(ptr, old, new, smp_llsc_mb()) > +#define cmpxchg_local(ptr, old, new) __cmpxchg(ptr, old, new,) > + > +#endif /* __ASM_CMPXCHG_H */ Thiemo From yoichi_yuasa@tripeaks.co.jp Tue Oct 2 15:22:48 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 02 Oct 2007 15:22:58 +0100 (BST) Received: from mo31.po.2iij.NET ([210.128.50.54]:20770 "EHLO mo31.po.2iij.net") by ftp.linux-mips.org with ESMTP id S20024265AbXJBOWn (ORCPT ); Tue, 2 Oct 2007 15:22:43 +0100 Received: by mo.po.2iij.net (mo31) id l92EMdKP098203; Tue, 2 Oct 2007 23:22:39 +0900 (JST) Received: from delta (221.25.30.125.dy.iij4u.or.jp [125.30.25.221]) by mbox.po.2iij.net (po-mbox301) id l92EMb0Z000570 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 2 Oct 2007 23:22:38 +0900 Date: Tue, 2 Oct 2007 23:21:36 +0900 From: Yoichi Yuasa To: Ralf Baechle Cc: yoichi_yuasa@tripeaks.co.jp, linux-mips Subject: [PATCH][4/4] remove cobalt_machine_power_off() Message-Id: <20071002232136.8afe738d.yoichi_yuasa@tripeaks.co.jp> In-Reply-To: <20071002231738.78779515.yoichi_yuasa@tripeaks.co.jp> References: <20071002225441.63d935eb.yoichi_yuasa@tripeaks.co.jp> <20071002231317.0fbaf7bb.yoichi_yuasa@tripeaks.co.jp> <20071002231738.78779515.yoichi_yuasa@tripeaks.co.jp> Organization: TriPeaks Corporation X-Mailer: Sylpheed 2.4.0 (GTK+ 2.10.11; i486-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 16790 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: yoichi_yuasa@tripeaks.co.jp Precedence: bulk X-list: linux-mips Remove cobalt_machine_power_off(). It's same as cobalt_machine_halt(). Signed-off-by: Yoichi Yuasa diff -pruN -X mips/Documentation/dontdiff mips-orig/arch/mips/cobalt/reset.c mips/arch/mips/cobalt/reset.c --- mips-orig/arch/mips/cobalt/reset.c 2007-10-01 17:52:43.870115250 +0900 +++ mips/arch/mips/cobalt/reset.c 2007-10-01 17:52:51.622599750 +0900 @@ -61,12 +61,3 @@ void cobalt_machine_restart(char *comman /* we should never get here */ cobalt_machine_halt(); } - -/* - * This triggers the luser mode device driver for the power switch ;-) - */ -void cobalt_machine_power_off(void) -{ - printk("You can switch the machine off now.\n"); - cobalt_machine_halt(); -} diff -pruN -X mips/Documentation/dontdiff mips-orig/arch/mips/cobalt/setup.c mips/arch/mips/cobalt/setup.c --- mips-orig/arch/mips/cobalt/setup.c 2007-10-01 17:03:49.370720500 +0900 +++ mips/arch/mips/cobalt/setup.c 2007-10-01 17:52:51.634600500 +0900 @@ -25,7 +25,6 @@ extern void cobalt_machine_restart(char *command); extern void cobalt_machine_halt(void); -extern void cobalt_machine_power_off(void); const char *get_system_type(void) { @@ -96,7 +95,7 @@ void __init plat_mem_setup(void) _machine_restart = cobalt_machine_restart; _machine_halt = cobalt_machine_halt; - pm_power_off = cobalt_machine_power_off; + pm_power_off = cobalt_machine_halt; set_io_port_base(CKSEG1ADDR(GT_DEF_PCI0_IO_BASE)); From yoichi_yuasa@tripeaks.co.jp Tue Oct 2 15:23:55 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 02 Oct 2007 15:24:03 +0100 (BST) Received: from mo31.po.2iij.NET ([210.128.50.54]:62991 "EHLO mo31.po.2iij.net") by ftp.linux-mips.org with ESMTP id S20024272AbXJBOXz (ORCPT ); Tue, 2 Oct 2007 15:23:55 +0100 Received: by mo.po.2iij.net (mo31) id l92EMb5d098181; Tue, 2 Oct 2007 23:22:37 +0900 (JST) Received: from delta (221.25.30.125.dy.iij4u.or.jp [125.30.25.221]) by mbox.po.2iij.net (po-mbox303) id l92EMam7007234 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 2 Oct 2007 23:22:36 +0900 Date: Tue, 2 Oct 2007 23:17:38 +0900 From: Yoichi Yuasa To: Ralf Baechle Cc: yoichi_yuasa@tripeaks.co.jp, linux-mips Subject: [PATCH][3/4] move Cobalt reset port definition to arch/mips/cobalt/reset.c Message-Id: <20071002231738.78779515.yoichi_yuasa@tripeaks.co.jp> In-Reply-To: <20071002231317.0fbaf7bb.yoichi_yuasa@tripeaks.co.jp> References: <20071002225441.63d935eb.yoichi_yuasa@tripeaks.co.jp> <20071002231317.0fbaf7bb.yoichi_yuasa@tripeaks.co.jp> Organization: TriPeaks Corporation X-Mailer: Sylpheed 2.4.0 (GTK+ 2.10.11; i486-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 16791 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: yoichi_yuasa@tripeaks.co.jp Precedence: bulk X-list: linux-mips Move Cobalt reset port definition to arch/mips/cobalt/reset.c. It's only used in arch/mips/cobalt/reset.c. Signed-off-by: Yoichi Yuasa diff -pruN -X mips/Documentation/dontdiff mips-orig/arch/mips/cobalt/reset.c mips/arch/mips/cobalt/reset.c --- mips-orig/arch/mips/cobalt/reset.c 2007-09-30 21:09:22.860275250 +0900 +++ mips/arch/mips/cobalt/reset.c 2007-09-30 21:13:17.078913000 +0900 @@ -9,11 +9,15 @@ * Copyright (C) 2001 by Liam Davies (ldavies@agile.tv) */ #include +#include #include #include #include +#define RESET_PORT ((void __iomem *)CKSEG1ADDR(0x1c000000)) +#define RESET 0x0f + DEFINE_LED_TRIGGER(power_off_led_trigger); static int __init ledtrig_power_off_init(void) @@ -43,7 +47,7 @@ void cobalt_machine_halt(void) last ^= diff; if((diff & (COBALT_KEY_ENTER | COBALT_KEY_SELECT)) && !(~last & (COBALT_KEY_ENTER | COBALT_KEY_SELECT))) - COBALT_LED_PORT = COBALT_LED_RESET; + writeb(RESET, RESET_PORT); for (mark = jiffies; jiffies - mark < HZ;) ; @@ -52,7 +56,7 @@ void cobalt_machine_halt(void) void cobalt_machine_restart(char *command) { - COBALT_LED_PORT = COBALT_LED_RESET; + writeb(RESET, RESET_PORT); /* we should never get here */ cobalt_machine_halt(); diff -pruN -X mips/Documentation/dontdiff mips-orig/include/asm-mips/mach-cobalt/cobalt.h mips/include/asm-mips/mach-cobalt/cobalt.h --- mips-orig/include/asm-mips/mach-cobalt/cobalt.h 2007-09-30 21:10:04.230860750 +0900 +++ mips/include/asm-mips/mach-cobalt/cobalt.h 2007-09-30 21:11:01.626447750 +0900 @@ -22,13 +22,6 @@ extern int cobalt_board_id; #define COBALT_BRD_ID_QUBE2 0x5 #define COBALT_BRD_ID_RAQ2 0x6 -#define COBALT_LED_PORT (*(volatile unsigned char *) CKSEG1ADDR(0x1c000000)) -# define COBALT_LED_BAR_LEFT (1 << 0) /* Qube */ -# define COBALT_LED_BAR_RIGHT (1 << 1) /* Qube */ -# define COBALT_LED_WEB (1 << 2) /* RaQ */ -# define COBALT_LED_POWER_OFF (1 << 3) /* RaQ */ -# define COBALT_LED_RESET 0x0f - #define COBALT_KEY_PORT ((~*(volatile unsigned int *) CKSEG1ADDR(0x1d000000) >> 24) & COBALT_KEY_MASK) # define COBALT_KEY_CLEAR (1 << 1) # define COBALT_KEY_LEFT (1 << 2) From yoichi_yuasa@tripeaks.co.jp Tue Oct 2 15:24:24 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 02 Oct 2007 15:24:32 +0100 (BST) Received: from mo30.po.2iij.NET ([210.128.50.53]:22790 "EHLO mo30.po.2iij.net") by ftp.linux-mips.org with ESMTP id S20024277AbXJBOXz (ORCPT ); Tue, 2 Oct 2007 15:23:55 +0100 Received: by mo.po.2iij.net (mo30) id l92EMbt4093754; Tue, 2 Oct 2007 23:22:37 +0900 (JST) Received: from delta (221.25.30.125.dy.iij4u.or.jp [125.30.25.221]) by mbox.po.2iij.net (po-mbox303) id l92EMX8N007181 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 2 Oct 2007 23:22:33 +0900 Date: Tue, 2 Oct 2007 22:54:41 +0900 From: Yoichi Yuasa To: Ralf Baechle Cc: yoichi_yuasa@tripeaks.co.jp, linux-mips Subject: [PATCH][1/4] move Cobalt PCI definitions to arch/mips/pci/fixup-cobalt.c Message-Id: <20071002225441.63d935eb.yoichi_yuasa@tripeaks.co.jp> Organization: TriPeaks Corporation X-Mailer: Sylpheed 2.4.0 (GTK+ 2.10.11; i486-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 16792 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: yoichi_yuasa@tripeaks.co.jp Precedence: bulk X-list: linux-mips Move Cobalt PCI definitions to arch/mips/pci/fixup-cobalt.c. These PCI definitions are only used in arch/mips/pci/fixup-cobalt.c. Signed-off-by: Yoichi Yuasa diff -pruN -X mips/Documentation/dontdiff mips-orig/arch/mips/pci/fixup-cobalt.c mips/arch/mips/pci/fixup-cobalt.c --- mips-orig/arch/mips/pci/fixup-cobalt.c 2007-09-14 14:24:04.932503500 +0900 +++ mips/arch/mips/pci/fixup-cobalt.c 2007-09-14 14:25:01.604045250 +0900 @@ -20,6 +20,23 @@ #include #include +/* + * PCI slot numbers + */ +#define COBALT_PCICONF_CPU 0x06 +#define COBALT_PCICONF_ETH0 0x07 +#define COBALT_PCICONF_RAQSCSI 0x08 +#define COBALT_PCICONF_VIA 0x09 +#define COBALT_PCICONF_PCISLOT 0x0A +#define COBALT_PCICONF_ETH1 0x0C + +/* + * The Cobalt board ID information. The boards have an ID number wired + * into the VIA that is available in the high nibble of register 94. + */ +#define VIA_COBALT_BRD_ID_REG 0x94 +#define VIA_COBALT_BRD_REG_to_ID(reg) ((unsigned char)(reg) >> 4) + static void qube_raq_galileo_early_fixup(struct pci_dev *dev) { if (dev->devfn == PCI_DEVFN(0, 0) && diff -pruN -X mips/Documentation/dontdiff mips-orig/include/asm-mips/mach-cobalt/cobalt.h mips/include/asm-mips/mach-cobalt/cobalt.h --- mips-orig/include/asm-mips/mach-cobalt/cobalt.h 2007-09-14 14:24:04.952504750 +0900 +++ mips/include/asm-mips/mach-cobalt/cobalt.h 2007-09-14 14:21:49.180019500 +0900 @@ -13,37 +13,15 @@ #define __ASM_COBALT_H /* - * PCI configuration space manifest constants. These are wired into - * the board layout according to the PCI spec to enable the software - * to probe the hardware configuration space in a well defined manner. - * - * The PCI_DEVSHFT() macro transforms these values into numbers - * suitable for passing as the dev parameter to the various - * pcibios_read/write_config routines. + * The Cobalt board ID information. */ -#define COBALT_PCICONF_CPU 0x06 -#define COBALT_PCICONF_ETH0 0x07 -#define COBALT_PCICONF_RAQSCSI 0x08 -#define COBALT_PCICONF_VIA 0x09 -#define COBALT_PCICONF_PCISLOT 0x0A -#define COBALT_PCICONF_ETH1 0x0C - +extern int cobalt_board_id; -/* - * The Cobalt board id information. The boards have an ID number wired - * into the VIA that is available in the high nibble of register 94. - * This register is available in the VIA configuration space through the - * interface routines qube_pcibios_read/write_config. See cobalt/pci.c - */ -#define VIA_COBALT_BRD_ID_REG 0x94 -#define VIA_COBALT_BRD_REG_to_ID(reg) ((unsigned char) (reg) >> 4) #define COBALT_BRD_ID_QUBE1 0x3 #define COBALT_BRD_ID_RAQ1 0x4 #define COBALT_BRD_ID_QUBE2 0x5 #define COBALT_BRD_ID_RAQ2 0x6 -extern int cobalt_board_id; - #define COBALT_LED_PORT (*(volatile unsigned char *) CKSEG1ADDR(0x1c000000)) # define COBALT_LED_BAR_LEFT (1 << 0) /* Qube */ # define COBALT_LED_BAR_RIGHT (1 << 1) /* Qube */ From yoichi_yuasa@tripeaks.co.jp Tue Oct 2 15:24:52 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 02 Oct 2007 15:25:01 +0100 (BST) Received: from mo32.po.2iij.NET ([210.128.50.17]:5162 "EHLO mo32.po.2iij.net") by ftp.linux-mips.org with ESMTP id S20024285AbXJBOXz (ORCPT ); Tue, 2 Oct 2007 15:23:55 +0100 Received: by mo.po.2iij.net (mo32) id l92EMbbE094930; Tue, 2 Oct 2007 23:22:37 +0900 (JST) Received: from delta (221.25.30.125.dy.iij4u.or.jp [125.30.25.221]) by mbox.po.2iij.net (po-mbox301) id l92EMYxl000527 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 2 Oct 2007 23:22:35 +0900 Date: Tue, 2 Oct 2007 23:13:17 +0900 From: Yoichi Yuasa To: Ralf Baechle Cc: yoichi_yuasa@tripeaks.co.jp, linux-mips Subject: [PATCH][2/4] move Cobalt UART base definition to arch/mips/cobalt/console.c Message-Id: <20071002231317.0fbaf7bb.yoichi_yuasa@tripeaks.co.jp> In-Reply-To: <20071002225441.63d935eb.yoichi_yuasa@tripeaks.co.jp> References: <20071002225441.63d935eb.yoichi_yuasa@tripeaks.co.jp> Organization: TriPeaks Corporation X-Mailer: Sylpheed 2.4.0 (GTK+ 2.10.11; i486-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 16793 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: yoichi_yuasa@tripeaks.co.jp Precedence: bulk X-list: linux-mips Move Cobalt UART base definition to arch/mips/cobalt/console.c. It's only used in arch/mips/cobalt/console.c. Signed-off-by: Yoichi Yuasa diff -pruN -X mips/Documentation/dontdiff mips-orig/arch/mips/cobalt/console.c mips/arch/mips/cobalt/console.c --- mips-orig/arch/mips/cobalt/console.c 2007-09-30 21:21:39.610319250 +0900 +++ mips/arch/mips/cobalt/console.c 2007-09-30 21:26:10.135226000 +0900 @@ -1,16 +1,15 @@ /* * (C) P. Horton 2006 */ +#include #include -#include - -#include +#define UART_BASE ((void __iomem *)CKSEG1ADDR(0x1c800000)) void prom_putchar(char c) { - while(!(COBALT_UART[UART_LSR] & UART_LSR_THRE)) + while(!(readb(UART_BASE + UART_LSR) & UART_LSR_THRE)) ; - COBALT_UART[UART_TX] = c; + writeb(c, UART_BASE + UART_TX); } diff -pruN -X mips/Documentation/dontdiff mips-orig/include/asm-mips/mach-cobalt/cobalt.h mips/include/asm-mips/mach-cobalt/cobalt.h --- mips-orig/include/asm-mips/mach-cobalt/cobalt.h 2007-09-30 21:25:01.586942000 +0900 +++ mips/include/asm-mips/mach-cobalt/cobalt.h 2007-09-30 21:21:46.170729250 +0900 @@ -39,6 +39,4 @@ extern int cobalt_board_id; # define COBALT_KEY_SELECT (1 << 7) # define COBALT_KEY_MASK 0xfe -#define COBALT_UART ((volatile unsigned char *) CKSEG1ADDR(0x1c800000)) - #endif /* __ASM_COBALT_H */ From ths@networkno.de Tue Oct 2 15:36:19 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 02 Oct 2007 15:36:29 +0100 (BST) Received: from mail.bawue.net ([193.7.176.63]:18319 "EHLO mail.bawue.net") by ftp.linux-mips.org with ESMTP id S20024285AbXJBOgT (ORCPT ); Tue, 2 Oct 2007 15:36:19 +0100 Received: from lagash (intrt.mips-uk.com [194.74.144.130]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by mail.bawue.net (Postfix) with ESMTP id 8778CE0047; Tue, 2 Oct 2007 16:36:24 +0200 (CEST) Received: from ths by lagash with local (Exim 4.67) (envelope-from ) id 1Icir6-0003Pr-DS; Tue, 02 Oct 2007 15:36:12 +0100 Date: Tue, 2 Oct 2007 15:36:12 +0100 From: Thiemo Seufer To: "Maciej W. Rozycki" Cc: Ralf Baechle , linux-mips@linux-mips.org Subject: Re: [PATCH] mm/pg-r4k.c: Fix a typo in an R4600 v2 erratum workaround Message-ID: <20071002143612.GE16772@networkno.de> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.16 (2007-06-11) Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 16794 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: ths@networkno.de Precedence: bulk X-list: linux-mips Maciej W. Rozycki wrote: > Restore a load from KSEG1 done as a workaround for an R4600 v2 > erratum, dropped with 211be16de99a7424e66c0b6c0d00e2c970508ac2. > > Signed-off-by: Maciej W. Rozycki > --- > Thiemo, > > It reverts your change of Sep 1st, 2005; given the way the code is > written, I am assuming the change was accidental, correct? At the moment > the load never happens. That's correct. Thiemo From ralf@linux-mips.org Tue Oct 2 16:49:19 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 02 Oct 2007 16:49:21 +0100 (BST) Received: from localhost.localdomain ([127.0.0.1]:13521 "EHLO dl5rb.ham-radio-op.net") by ftp.linux-mips.org with ESMTP id S20024323AbXJBPtT (ORCPT ); Tue, 2 Oct 2007 16:49:19 +0100 Received: from denk.linux-mips.net (denk.linux-mips.net [127.0.0.1]) by dl5rb.ham-radio-op.net (8.14.1/8.13.8) with ESMTP id l92FnIoI014139; Tue, 2 Oct 2007 16:49:18 +0100 Received: (from ralf@localhost) by denk.linux-mips.net (8.14.1/8.14.1/Submit) id l92FnIOP014138; Tue, 2 Oct 2007 16:49:18 +0100 Date: Tue, 2 Oct 2007 16:49:18 +0100 From: Ralf Baechle To: Thiemo Seufer Cc: "Maciej W. Rozycki" , linux-mips@linux-mips.org Subject: Re: [PATCH] mm/pg-r4k.c: Dump the generated code Message-ID: <20071002154918.GA11312@linux-mips.org> References: <20071002141125.GC16772@networkno.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20071002141125.GC16772@networkno.de> User-Agent: Mutt/1.5.14 (2007-02-12) Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 16795 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: ralf@linux-mips.org Precedence: bulk X-list: linux-mips On Tue, Oct 02, 2007 at 03:11:26PM +0100, Thiemo Seufer wrote: > Maciej W. Rozycki wrote: > > Dump the generated code for clear/copy page calls like it is done for TLB > > fault handlers. Useful for debugging. > > > > Signed-off-by: Maciej W. Rozycki > > --- > > Thiemo, > > > > It was your change to add ".set noreorder", etc. to the TLB fault > > handlers -- what is it needed for? I have thought gas does not try to > > outsmart the user at the moment and does not reorder ".word" directives. > > It is not strictly needed, but it is a hint to the user that he looks > at raw instructions. I have a patch which makes the generated code accessible through a procfs file. That can easily be converted back into a .o file and then be disassembled. So it's now a question of which variant is preferable. I don't mind - it's just that I've never been a friend of leaving much debugging code or features around. 99% of the time it is just make the code harder to read and maintain. Ralf From ths@networkno.de Tue Oct 2 17:04:00 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 02 Oct 2007 17:04:09 +0100 (BST) Received: from mail.bawue.net ([193.7.176.63]:56218 "EHLO mail.bawue.net") by ftp.linux-mips.org with ESMTP id S20024338AbXJBQEA (ORCPT ); Tue, 2 Oct 2007 17:04:00 +0100 Received: from lagash (intrt.mips-uk.com [194.74.144.130]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by mail.bawue.net (Postfix) with ESMTP id A8506E014B; Tue, 2 Oct 2007 18:03:35 +0200 (CEST) Received: from ths by lagash with local (Exim 4.67) (envelope-from ) id 1IckDT-00049Q-Qs; Tue, 02 Oct 2007 17:03:23 +0100 Date: Tue, 2 Oct 2007 17:03:23 +0100 From: Thiemo Seufer To: Ralf Baechle Cc: "Maciej W. Rozycki" , linux-mips@linux-mips.org Subject: Re: [PATCH] mm/pg-r4k.c: Dump the generated code Message-ID: <20071002160323.GF16772@networkno.de> References: <20071002141125.GC16772@networkno.de> <20071002154918.GA11312@linux-mips.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20071002154918.GA11312@linux-mips.org> User-Agent: Mutt/1.5.16 (2007-06-11) Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 16796 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: ths@networkno.de Precedence: bulk X-list: linux-mips Ralf Baechle wrote: > On Tue, Oct 02, 2007 at 03:11:26PM +0100, Thiemo Seufer wrote: > > > Maciej W. Rozycki wrote: > > > Dump the generated code for clear/copy page calls like it is done for TLB > > > fault handlers. Useful for debugging. > > > > > > Signed-off-by: Maciej W. Rozycki > > > --- > > > Thiemo, > > > > > > It was your change to add ".set noreorder", etc. to the TLB fault > > > handlers -- what is it needed for? I have thought gas does not try to > > > outsmart the user at the moment and does not reorder ".word" directives. > > > > It is not strictly needed, but it is a hint to the user that he looks > > at raw instructions. > > I have a patch which makes the generated code accessible through a > procfs file. That can easily be converted back into a .o file and then > be disassembled. So it's now a question of which variant is preferable. I prefer output at startup. If you are interested in the disassembly you probably don't have access to /proc. :-) Thiemo From macro@linux-mips.org Tue Oct 2 17:08:12 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 02 Oct 2007 17:08:20 +0100 (BST) Received: from cerber.ds.pg.gda.pl ([153.19.208.18]:18146 "EHLO cerber.ds.pg.gda.pl") by ftp.linux-mips.org with ESMTP id S20024340AbXJBQIM (ORCPT ); Tue, 2 Oct 2007 17:08:12 +0100 Received: from localhost (unknown [127.0.0.17]) by cerber.ds.pg.gda.pl (Postfix) with ESMTP id CB9594010F; Tue, 2 Oct 2007 18:08:12 +0200 (CEST) X-Virus-Scanned: amavisd-new at cerber.ds.pg.gda.pl Received: from cerber.ds.pg.gda.pl ([153.19.208.18]) by localhost (cerber.ds.pg.gda.pl [153.19.208.18]) (amavisd-new, port 10024) with ESMTP id Imiqcdi56dWo; Tue, 2 Oct 2007 18:08:06 +0200 (CEST) Received: from piorun.ds.pg.gda.pl (piorun.ds.pg.gda.pl [153.19.208.8]) by cerber.ds.pg.gda.pl (Postfix) with ESMTP id C473640040; Tue, 2 Oct 2007 18:08:06 +0200 (CEST) Received: from blysk.ds.pg.gda.pl (macro@blysk.ds.pg.gda.pl [153.19.208.6]) by piorun.ds.pg.gda.pl (8.13.8/8.13.8) with ESMTP id l92G8Bpd007977; Tue, 2 Oct 2007 18:08:11 +0200 Date: Tue, 2 Oct 2007 17:08:05 +0100 (BST) From: "Maciej W. Rozycki" To: Ralf Baechle cc: Thiemo Seufer , linux-mips@linux-mips.org Subject: Re: [PATCH] mm/pg-r4k.c: Dump the generated code In-Reply-To: <20071002154918.GA11312@linux-mips.org> Message-ID: References: <20071002141125.GC16772@networkno.de> <20071002154918.GA11312@linux-mips.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: ClamAV 0.91.2/4453/Tue Oct 2 13:38:38 2007 on piorun.ds.pg.gda.pl X-Virus-Status: Clean Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 16797 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: macro@linux-mips.org Precedence: bulk X-list: linux-mips On Tue, 2 Oct 2007, Ralf Baechle wrote: > I have a patch which makes the generated code accessible through a > procfs file. That can easily be converted back into a .o file and then > be disassembled. So it's now a question of which variant is preferable. There is no need to go through such hassle even: $ objdump -b binary -m mips:4000 -d /proc/foo or suchlike should work (the program seems to be sensitive to the file size though, so it better be non-zero). > I don't mind - it's just that I've never been a friend of leaving much > debugging code or features around. 99% of the time it is just make the > code harder to read and maintain. In this case I would let these bits stay in though. The bootstrap log always works and can be captured with the serial console or read from the screen, and if there is a subtle breakage in these generated bits then the system may never get far enough for procfs to be accessible. It is these moments it matters the most. Maciej From alessandro.zummo@towertech.it Tue Oct 2 20:13:28 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 02 Oct 2007 20:13:38 +0100 (BST) Received: from mx0.towertech.it ([213.215.222.73]:60594 "HELO mx0.towertech.it") by ftp.linux-mips.org with SMTP id S20022204AbXJBTN2 (ORCPT ); Tue, 2 Oct 2007 20:13:28 +0100 Received: (qmail 6658 invoked from network); 2 Oct 2007 21:13:17 +0200 Received: from unknown (HELO i1501.lan.towertech.it) (81.208.60.204) by mx0.towertech.it with SMTP; 2 Oct 2007 21:13:17 +0200 Date: Tue, 2 Oct 2007 15:14:15 +0200 From: Alessandro Zummo To: rtc-linux@googlegroups.com Cc: macro@linux-mips.org, Atsushi Nemoto , rongkai.zhan@windriver.com, i2c@lm-sensors.org, linux-mips@linux-mips.org, ralf@linux-mips.org, a.zummo@towertech.it Subject: Re: [rtc-linux] Re: [PATCH 4/4] MIPS: Remove the legacy RTC codes of MIPS sibyte boards Message-ID: <20071002151415.672d0a1e@i1501.lan.towertech.it> In-Reply-To: References: <46FF7283.7050702@windriver.com> <20071002.003020.21363605.anemo@mba.ocn.ne.jp> Organization: Tower Technologies X-Mailer: Sylpheed Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 16798 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: alessandro.zummo@towertech.it Precedence: bulk X-list: linux-mips On Mon, 1 Oct 2007 20:08:55 +0100 (BST) "Maciej W. Rozycki" wrote: > > > Is the system time still set correctly from the RTC chip upon bootstrap > > > with your changes? I cannot immediately infer it from the patches and my > > > suspicion is it may not anymore. > > > > CONFIG_RTC_HCTOSYS=y can do it, isn't it? > > Hmm, I wonder whether this shouldn't be enabled via a reverse dependency. > Or even unconditionally perhaps -- if the initial system time gets set > from incorrect RTC time (e.g. because it is not battery-backed) it does > not get less correct than it would be otherwise, does it? > > Any reason for not doing either of these? CONFIG_RTC_HCTOSYS defaults to YES, it should be enough...? -- Best regards, Alessandro Zummo, Tower Technologies - Torino, Italy http://www.towertech.it From alessandro.zummo@towertech.it Tue Oct 2 20:14:29 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 02 Oct 2007 20:14:38 +0100 (BST) Received: from mx0.towertech.it ([213.215.222.73]:44942 "HELO mx0.towertech.it") by ftp.linux-mips.org with SMTP id S20022204AbXJBTO3 (ORCPT ); Tue, 2 Oct 2007 20:14:29 +0100 Received: (qmail 6675 invoked from network); 2 Oct 2007 21:13:19 +0200 Received: from unknown (HELO i1501.lan.towertech.it) (81.208.60.204) by mx0.towertech.it with SMTP; 2 Oct 2007 21:13:19 +0200 Date: Tue, 2 Oct 2007 15:16:24 +0200 From: Alessandro Zummo To: rtc-linux@googlegroups.com Cc: anemo@mba.ocn.ne.jp, rongkai.zhan@windriver.com, i2c@lm-sensors.org, linux-mips@linux-mips.org, ralf@linux-mips.org Subject: Re: [rtc-linux] Re: [PATCH 2/4] RTC: make m41t80 driver can work with the SMBus adapters Message-ID: <20071002151624.24ff7bb1@i1501.lan.towertech.it> In-Reply-To: <20071002.000616.31638007.anemo@mba.ocn.ne.jp> References: <46FF726E.4020200@windriver.com> <20071002.000616.31638007.anemo@mba.ocn.ne.jp> Organization: Tower Technologies X-Mailer: Sylpheed Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 16799 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: alessandro.zummo@towertech.it Precedence: bulk X-list: linux-mips On Tue, 02 Oct 2007 00:06:16 +0900 (JST) Atsushi Nemoto wrote: > > On Sun, 30 Sep 2007 17:54:54 +0800, Mark Zhan wrote: > > This patch makes m41t80 RTC driver also can work with the SMBus adapters, > > which doesn't i2c_transfer() method. > > > > Signed-off-by: Mark Zhan > > As Jean already said, your mailer corrupted your patch. > Also, please keep in mind the 80 column rule. [...] fwiw, I agree with Atsushi's comments. -- Best regards, Alessandro Zummo, Tower Technologies - Torino, Italy http://www.towertech.it From cd@moon.ketl.com Tue Oct 2 20:18:02 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 02 Oct 2007 20:18:10 +0100 (BST) Received: from [64.94.143.173] ([64.94.143.173]:61382 "HELO moon.ketl.com") by ftp.linux-mips.org with SMTP id S20022268AbXJBTSC (ORCPT ); Tue, 2 Oct 2007 20:18:02 +0100 Received: (qmail 18819 invoked by uid 1006); 2 Oct 2007 18:44:35 -0000 Date: Tue, 2 Oct 2007 11:44:35 -0700 From: Chris David To: linux-mips@linux-mips.org Subject: 2.6 Patch for AMD MIPS Alchemy au1550 I2C interface I2C Message-ID: <20071002184435.GB18766@moon.ketl.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.13 (2006-08-11) Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 16800 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: cd@chrisdavid.com Precedence: bulk X-list: linux-mips Hello, Please CC me on replies. Here is a trivial patch to fix a "mis-used register" problem on the AMD MIPS Alchemy au1550 I2C interface. In summary, The programmable serial controller seem to hang the kernel when I sent a single an 'address' byte on the I2C bus. The patch essentially uses the PSC_SMBSTAT register's TE (transmit FIFO empty) bit to check when the transmit FIFO is empty, instead of using the PSC_SMBEVNT register's TU (transmit underflow) bit. Using the TE bit fixed the hang problem. I tested this on kernel 2.6.16, and confirmed the patch updates the 2.6.22 kernel correctly. If someone else can test this, that would be great. And I think it should be included in the kernel. Again, please CC me on replies. Thanks, -Chris Signed-off-by: Chris David --- diff -Naur linux-2.6.16-orig/drivers/i2c/busses/i2c-au1550.c linux-2.6.16/drivers/i2c/busses/i2c-au1550.c --- linux-2.6.16-orig/drivers/i2c/busses/i2c-au1550.c 2007-09-26 08:38:45.000000000 -0700 +++ linux-2.6.16/drivers/i2c/busses/i2c-au1550.c 2007-09-26 08:43:43.000000000 -0700 @@ -61,17 +61,14 @@ sp = (volatile psc_smb_t *)(adap->psc_base); - /* Wait for Tx FIFO Underflow. + /* Wait for Tx Buffer Empty */ for (i = 0; i < adap->xfer_timeout; i++) { - stat = sp->psc_smbevnt; + stat = sp->psc_smbstat; au_sync(); - if ((stat & PSC_SMBEVNT_TU) != 0) { - /* Clear it. */ - sp->psc_smbevnt = PSC_SMBEVNT_TU; - au_sync(); + if ((stat & PSC_SMBSTAT_TE) != 0) return 0; - } + udelay(1); } From aurel32@hall.aurel32.net Tue Oct 2 21:09:59 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 02 Oct 2007 21:10:07 +0100 (BST) Received: from hall.aurel32.net ([88.191.38.19]:5004 "EHLO hall.aurel32.net") by ftp.linux-mips.org with ESMTP id S20022720AbXJBUJ7 (ORCPT ); Tue, 2 Oct 2007 21:09:59 +0100 Received: from aurel32 by hall.aurel32.net with local (Exim 4.63) (envelope-from ) id 1Ico0y-0005uU-Lc; Tue, 02 Oct 2007 22:06:44 +0200 Date: Tue, 2 Oct 2007 22:06:44 +0200 From: Aurelien Jarno To: linux-mips@linux-mips.org, qemu-devel@nongnu.org Subject: QEMU/MIPS & dyntick kernel Message-ID: <20071002200644.GA19140@hall.aurel32.net> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="Dxnq1zWXvFF0Q93v" Content-Disposition: inline X-Mailer: Mutt 1.5.13 (2006-08-11) User-Agent: Mutt/1.5.13 (2006-08-11) Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 16801 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: aurelien@aurel32.net Precedence: bulk X-list: linux-mips --Dxnq1zWXvFF0Q93v Content-Type: text/plain; charset=iso-8859-15 Content-Disposition: inline Hi, As announced by Ralf Baechle, dyntick is now available on MIPS. I gave a try on QEMU/MIPS, and unfortunately it doesn't work correctly. In some cases the kernel schedules an event very near in the future, which means the timer is scheduled a few cycles only from its current value. Unfortunately under QEMU, the timer runs too fast compared to the speed at which instructions are execution. This causes a lockup of the kernel. This can be triggered by running hwclock --hctosys in the guest (which is run at boot time by most distributions). Until now, I haven't found any other way to trigger the bug. The problematic code in the kernel from arch/mips/kernel/time.c is the following: cnt = read_c0_count(); cnt += delta; write_c0_compare(cnt); res = ((long)(read_c0_count() - cnt ) > 0) ? -ETIME : 0; Note that there is a minimum value for delta (currently set to 48) to avoid lockup. In QEMU, the emulated kernel runs at 100 MHz, ie very fast, which means that more than 48 timer cycles happen between the two calls of read_c0_count(). The code returns -ETIME, and the routine is called again with 48 and so on. I have tried to reduce the speed of the timer, the problem disappears when running at 1MHz (on my machine). Here are a few proposed ways to fix the problem (they are not exclusive): 1) Improve the emulation speed for timer instructions. This is what I did with the attached patch. I see no obvious reason of stopping the translation after a write to CP0_Compare, so I removed that part. I also reduced the code that emulates timer accesses. That helps but that is clearly not enough. With this patch the maximum timer speed is 5MHz. 2) Increase the minimum value for delta. For a 100MHz timer 48 cycles means 480ns. On the other side a kernel running at 250Hz (default on MIPS) is scheduling tasks with a 4ms resolution. Increasing it to about 10 microseconds should have no impact on the scheduling, even on real hardware. 3) Reduce the timer speed. As the timer is supposed to run at half the speed of the CPU, that would mean the kernel would see a 2 to 10MHz CPU. 4) Add a hack to QEMU to make the timer slower within a translation block (like increasing it by 1 at each access), without changing the overall speed. This might break other parts or other OSeS. Any thoughts or other ideas? Bye, Aurelien [1] http://www.linux-mips.org/archives/linux-mips/2007-09/msg00372.html -- .''`. Aurelien Jarno | GPG: 1024D/F1BCDB73 : :' : Debian developer | Electrical Engineer `. `' aurel32@debian.org | aurelien@aurel32.net `- people.debian.org/~aurel32 | www.aurel32.net --Dxnq1zWXvFF0Q93v Content-Type: text/x-diff; charset=iso-8859-15 Content-Disposition: attachment; filename="mips-qemu-timer.diff" Index: hw/mips_timer.c =================================================================== RCS file: /sources/qemu/qemu/hw/mips_timer.c,v retrieving revision 1.8 diff -u -d -p -r1.8 mips_timer.c --- hw/mips_timer.c 25 Sep 2007 16:53:15 -0000 1.8 +++ hw/mips_timer.c 2 Oct 2007 10:20:37 -0000 @@ -1,5 +1,7 @@ #include "vl.h" +#define TIMER_FREQ 100 * 1000 * 1000 + void cpu_mips_irqctrl_init (void) { } @@ -22,49 +24,41 @@ uint32_t cpu_mips_get_count (CPUState *e else return env->CP0_Count + (uint32_t)muldiv64(qemu_get_clock(vm_clock), - 100 * 1000 * 1000, ticks_per_sec); + TIMER_FREQ, ticks_per_sec); } -void cpu_mips_store_count (CPUState *env, uint32_t count) +static void cpu_mips_timer_update(CPUState *env) { uint64_t now, next; - uint32_t tmp; - uint32_t compare = env->CP0_Compare; + uint32_t wait; - tmp = count; - if (count == compare) - tmp++; now = qemu_get_clock(vm_clock); - next = now + muldiv64(compare - tmp, ticks_per_sec, 100 * 1000 * 1000); - if (next == now) - next++; -#if 0 - if (logfile) { - fprintf(logfile, "%s: 0x%08" PRIx64 " %08x %08x => 0x%08" PRIx64 "\n", - __func__, now, count, compare, next - now); - } -#endif - /* Store new count and compare registers */ - env->CP0_Compare = compare; - env->CP0_Count = - count - (uint32_t)muldiv64(now, 100 * 1000 * 1000, ticks_per_sec); - /* Adjust timer */ + wait = env->CP0_Compare - env->CP0_Count - + (uint32_t)muldiv64(now, TIMER_FREQ, ticks_per_sec); + next = now + muldiv64(wait, ticks_per_sec, TIMER_FREQ); qemu_mod_timer(env->timer, next); } -static void cpu_mips_update_count (CPUState *env, uint32_t count) +void cpu_mips_store_count (CPUState *env, uint32_t count) { if (env->CP0_Cause & (1 << CP0Ca_DC)) - return; - - cpu_mips_store_count(env, count); + env->CP0_Count = count; + else { + /* Store new count register */ + env->CP0_Count = + count - (uint32_t)muldiv64(qemu_get_clock(vm_clock), + TIMER_FREQ, ticks_per_sec); + /* Update timer timer */ + cpu_mips_timer_update(env); + } } void cpu_mips_store_compare (CPUState *env, uint32_t value) { env->CP0_Compare = value; - cpu_mips_update_count(env, cpu_mips_get_count(env)); - if ((env->CP0_Config0 & (0x7 << CP0C0_AR)) == (1 << CP0C0_AR)) + if (!(env->CP0_Cause & (1 << CP0Ca_DC))) + cpu_mips_timer_update(env); + if (env->insn_flags & ISA_MIPS32R2) env->CP0_Cause &= ~(1 << CP0Ca_TI); qemu_irq_lower(env->irq[(env->CP0_IntCtl >> CP0IntCtl_IPTI) & 0x7]); } @@ -78,7 +72,7 @@ void cpu_mips_stop_count(CPUState *env) { /* Store the current value */ env->CP0_Count += (uint32_t)muldiv64(qemu_get_clock(vm_clock), - 100 * 1000 * 1000, ticks_per_sec); + TIMER_FREQ, ticks_per_sec); } static void mips_timer_cb (void *opaque) @@ -95,8 +89,8 @@ static void mips_timer_cb (void *opaque) if (env->CP0_Cause & (1 << CP0Ca_DC)) return; - cpu_mips_update_count(env, cpu_mips_get_count(env)); - if ((env->CP0_Config0 & (0x7 << CP0C0_AR)) == (1 << CP0C0_AR)) + cpu_mips_timer_update(env); + if (env->insn_flags & ISA_MIPS32R2) env->CP0_Cause |= 1 << CP0Ca_TI; qemu_irq_raise(env->irq[(env->CP0_IntCtl >> CP0IntCtl_IPTI) & 0x7]); } @@ -105,5 +99,5 @@ void cpu_mips_clock_init (CPUState *env) { env->timer = qemu_new_timer(vm_clock, &mips_timer_cb, env); env->CP0_Compare = 0; - cpu_mips_update_count(env, 1); + cpu_mips_store_count(env, 1); } Index: target-mips/translate.c =================================================================== RCS file: /sources/qemu/qemu/target-mips/translate.c,v retrieving revision 1.104 diff -u -d -p -r1.104 translate.c --- target-mips/translate.c 30 Sep 2007 01:58:33 -0000 1.104 +++ target-mips/translate.c 2 Oct 2007 10:20:38 -0000 @@ -2763,8 +2763,6 @@ static void gen_mtc0 (CPUState *env, Dis default: goto die; } - /* Stop translation as we may have switched the execution mode */ - ctx->bstate = BS_STOP; break; case 12: switch (sel) { --Dxnq1zWXvFF0Q93v-- From ralf@linux-mips.org Tue Oct 2 21:15:02 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 02 Oct 2007 21:15:04 +0100 (BST) Received: from localhost.localdomain ([127.0.0.1]:56785 "EHLO dl5rb.ham-radio-op.net") by ftp.linux-mips.org with ESMTP id S20022930AbXJBUPC (ORCPT ); Tue, 2 Oct 2007 21:15:02 +0100 Received: from denk.linux-mips.net (denk.linux-mips.net [127.0.0.1]) by dl5rb.ham-radio-op.net (8.14.1/8.13.8) with ESMTP id l92KF1w8025138; Tue, 2 Oct 2007 21:15:01 +0100 Received: (from ralf@localhost) by denk.linux-mips.net (8.14.1/8.14.1/Submit) id l92KEwhE025132; Tue, 2 Oct 2007 21:14:58 +0100 Date: Tue, 2 Oct 2007 21:14:58 +0100 From: Ralf Baechle To: Yoichi Yuasa Cc: linux-mips Subject: Re: [PATCH][2/4] move Cobalt UART base definition to arch/mips/cobalt/console.c Message-ID: <20071002201458.GA16476@linux-mips.org> References: <20071002225441.63d935eb.yoichi_yuasa@tripeaks.co.jp> <20071002231317.0fbaf7bb.yoichi_yuasa@tripeaks.co.jp> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20071002231317.0fbaf7bb.yoichi_yuasa@tripeaks.co.jp> User-Agent: Mutt/1.5.14 (2007-02-12) Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 16802 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: ralf@linux-mips.org Precedence: bulk X-list: linux-mips On Tue, Oct 02, 2007 at 11:13:17PM +0900, Yoichi Yuasa wrote: > diff -pruN -X mips/Documentation/dontdiff mips-orig/arch/mips/cobalt/console.c mips/arch/mips/cobalt/console.c > --- mips-orig/arch/mips/cobalt/console.c 2007-09-30 21:21:39.610319250 +0900 > +++ mips/arch/mips/cobalt/console.c 2007-09-30 21:26:10.135226000 +0900 > @@ -1,16 +1,15 @@ > /* > * (C) P. Horton 2006 > */ > +#include > #include > > -#include > - > -#include > +#define UART_BASE ((void __iomem *)CKSEG1ADDR(0x1c800000)) > > void prom_putchar(char c) > { > - while(!(COBALT_UART[UART_LSR] & UART_LSR_THRE)) > + while(!(readb(UART_BASE + UART_LSR) & UART_LSR_THRE)) ^^^ missing space. Aside of that looks ok, so I fixed that up and queued all four patches for 2.6.24. Thanks, Ralf From avi@qumranet.com Tue Oct 2 21:27:31 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 02 Oct 2007 21:27:39 +0100 (BST) Received: from il.qumranet.com ([82.166.9.18]:9345 "EHLO il.qumranet.com") by ftp.linux-mips.org with ESMTP id S20022629AbXJBU1b (ORCPT ); Tue, 2 Oct 2007 21:27:31 +0100 Received: from [10.64.7.18] (unknown [10.64.7.18]) by il.qumranet.com (Postfix) with ESMTP id AF838250D39; Tue, 2 Oct 2007 22:27:41 +0200 (IST) Message-ID: <4702A99B.7020008@qumranet.com> Date: Tue, 02 Oct 2007 22:27:07 +0200 From: Avi Kivity User-Agent: Thunderbird 2.0.0.5 (X11/20070727) MIME-Version: 1.0 To: qemu-devel@nongnu.org CC: linux-mips@linux-mips.org Subject: Re: [Qemu-devel] QEMU/MIPS & dyntick kernel References: <20071002200644.GA19140@hall.aurel32.net> In-Reply-To: <20071002200644.GA19140@hall.aurel32.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 16803 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: avi@qumranet.com Precedence: bulk X-list: linux-mips Aurelien Jarno wrote: > Hi, > > As announced by Ralf Baechle, dyntick is now available on MIPS. I gave a > try on QEMU/MIPS, and unfortunately it doesn't work correctly. > > In some cases the kernel schedules an event very near in the future, > which means the timer is scheduled a few cycles only from its current > value. Unfortunately under QEMU, the timer runs too fast compared to the > speed at which instructions are execution. Sounds like a kernel bug. Can't there conceivably exist real hardware (or a real timeout) that exhibits the same timing? Especially today with variable clock frequencies, I don't see how the kernel can rely on exact timing. -- Any sufficiently difficult bug is indistinguishable from a feature. From aurelien@aurel32.net Tue Oct 2 21:37:40 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 02 Oct 2007 21:37:48 +0100 (BST) Received: from hall.aurel32.net ([88.191.38.19]:27089 "EHLO hall.aurel32.net") by ftp.linux-mips.org with ESMTP id S20023069AbXJBUhk (ORCPT ); Tue, 2 Oct 2007 21:37:40 +0100 Received: from volta.aurel32.net ([2001:618:400:fc13:216:d3ff:fe17:fd00]) by hall.aurel32.net with esmtpsa (TLS-1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from ) id 1IcoUp-0006Ad-66; Tue, 02 Oct 2007 22:37:35 +0200 Received: from localhost.localdomain ([127.0.0.1] ident=aurel32) by volta.aurel32.net with esmtp (Exim 4.67) (envelope-from ) id 1IcoUq-0004sY-AR; Tue, 02 Oct 2007 22:37:36 +0200 Message-ID: <4702AC0F.1000906@aurel32.net> Date: Tue, 02 Oct 2007 22:37:35 +0200 From: Aurelien Jarno User-Agent: IceDove 1.5.0.10 (X11/20070328) MIME-Version: 1.0 To: qemu-devel@nongnu.org CC: linux-mips@linux-mips.org Subject: Re: [Qemu-devel] QEMU/MIPS & dyntick kernel References: <20071002200644.GA19140@hall.aurel32.net> <4702A99B.7020008@qumranet.com> In-Reply-To: <4702A99B.7020008@qumranet.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 16804 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: aurelien@aurel32.net Precedence: bulk X-list: linux-mips Avi Kivity a écrit : > Aurelien Jarno wrote: >> Hi, >> >> As announced by Ralf Baechle, dyntick is now available on MIPS. I gave a >> try on QEMU/MIPS, and unfortunately it doesn't work correctly. >> >> In some cases the kernel schedules an event very near in the future, >> which means the timer is scheduled a few cycles only from its current >> value. Unfortunately under QEMU, the timer runs too fast compared to the >> speed at which instructions are execution. > > Sounds like a kernel bug. Can't there conceivably exist real hardware > (or a real timeout) that exhibits the same timing? > > Especially today with variable clock frequencies, I don't see how the > kernel can rely on exact timing. > Well on real hardware, the instruction rate and the timer are linked: the timer run at half the speed of the CPU. As the corresponding assembly code is very small, only uses registers and is run in kernel mode, you know for sure that 48 cycles is more than enough. -- .''`. Aurelien Jarno | GPG: 1024D/F1BCDB73 : :' : Debian developer | Electrical Engineer `. `' aurel32@debian.org | aurelien@aurel32.net `- people.debian.org/~aurel32 | www.aurel32.net From ed.stafford@gmail.com Tue Oct 2 21:41:39 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 02 Oct 2007 21:41:49 +0100 (BST) Received: from fk-out-0910.google.com ([209.85.128.184]:21971 "EHLO fk-out-0910.google.com") by ftp.linux-mips.org with ESMTP id S20023078AbXJBUlj (ORCPT ); Tue, 2 Oct 2007 21:41:39 +0100 Received: by fk-out-0910.google.com with SMTP id f40so4292502fka for ; Tue, 02 Oct 2007 13:41:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; bh=2s0FBm7boKqIqrmxJG+LhChC1OOrUoPRgmDNf27IYWw=; b=fdm5Oy4qjiHi3nimyixydx8LIP37N/sGXWpikrNB+rYcI/94hCbPQN0d9jeuSsbERC8pNsZ2IeoUAeYXAI4YBnemh+PE0twnny06fJm3XvUbkXie/Fnxoxp1LpcPcuyKxNpsPaTIaldfEFRlkJ08W60eytb+zkOSIifddsaBEDY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; b=odnS2l3aecbNXw2FL9N4zZJ3Fpqv0UyA5EsuKbYjeKZ3yOKxLma0H+8AYo/oSn2S/EcDYyN7L93/I9MGAexTA4KVxVqSx+wGCXdF3HYN2EZykCznPjCBLnAjuGM094cW0zOjPTNv2NTn1EB5GsrPH5aD0aw203Y581f5tEka2n8= Received: by 10.82.189.6 with SMTP id m6mr11803830buf.1191357681235; Tue, 02 Oct 2007 13:41:21 -0700 (PDT) Received: by 10.141.129.12 with HTTP; Tue, 2 Oct 2007 13:41:21 -0700 (PDT) Message-ID: <41370a610710021341g749742dejec06b3a38477fd47@mail.gmail.com> Date: Tue, 2 Oct 2007 15:41:21 -0500 From: "Ed Stafford" To: linux-mips@linux-mips.org Subject: What is the current state of the Octane/IP30 support? MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 16805 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: ed.stafford@gmail.com Precedence: bulk X-list: linux-mips I have a single-proc Octane at home that I've decided should be running with Linux, but I have been reading up online about the Experimental nature of the kernel in relation to the hardware. Since most of the info I found was dated 2006, I wanted to ask your (as a group) opinion on how stable / usable the Octane is today with the current kernel. I'm not adverse to bleeding edge, I just want to know whether or not I'll be struggling on something that just doesn't have enough drivers written for it to make it usable. Just in case anyone asks, I'll probably be using Gentoo, but I'm not glued to that distro. (I'm very agnostic and just prefer it to work the best vs. distro-warring..) Thanks a bunch! Ed From alan@lxorguk.ukuu.org.uk Tue Oct 2 21:43:19 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 02 Oct 2007 21:43:27 +0100 (BST) Received: from outpipe-village-512-1.bc.nu ([81.2.110.250]:9105 "EHLO the-village.bc.nu") by ftp.linux-mips.org with ESMTP id S20023160AbXJBUnT (ORCPT ); Tue, 2 Oct 2007 21:43:19 +0100 Received: from the-village.bc.nu (localhost.localdomain [127.0.0.1]) by the-village.bc.nu (8.14.1/8.13.8) with ESMTP id l92KmQL2007284; Tue, 2 Oct 2007 21:48:26 +0100 Date: Tue, 2 Oct 2007 21:48:26 +0100 From: Alan Cox To: Aurelien Jarno Cc: qemu-devel@nongnu.org, linux-mips@linux-mips.org Subject: Re: [Qemu-devel] QEMU/MIPS & dyntick kernel Message-ID: <20071002214826.7ee2fae8@the-village.bc.nu> In-Reply-To: <4702AC0F.1000906@aurel32.net> References: <20071002200644.GA19140@hall.aurel32.net> <4702A99B.7020008@qumranet.com> <4702AC0F.1000906@aurel32.net> X-Mailer: Claws Mail 2.10.0 (GTK+ 2.10.14; i386-redhat-linux-gnu) Organization: Red Hat UK Cyf., Amberley Place, 107-111 Peascod Street, Windsor, Berkshire, SL4 1TE, Y Deyrnas Gyfunol. Cofrestrwyd yng Nghymru a Lloegr o'r rhif cofrestru 3798903 Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 16806 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: alan@lxorguk.ukuu.org.uk Precedence: bulk X-list: linux-mips > Well on real hardware, the instruction rate and the timer are linked: > the timer run at half the speed of the CPU. As the corresponding > assembly code is very small, only uses registers and is run in kernel > mode, you know for sure that 48 cycles is more than enough. What happens on NMI or if you take an ECC exception and scrubbing stall off the memory controller while loading part of that cache line of code into memory ? Alan From aurelien@aurel32.net Tue Oct 2 21:57:29 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 02 Oct 2007 21:57:37 +0100 (BST) Received: from hall.aurel32.net ([88.191.38.19]:35767 "EHLO hall.aurel32.net") by ftp.linux-mips.org with ESMTP id S20023478AbXJBU53 (ORCPT ); Tue, 2 Oct 2007 21:57:29 +0100 Received: from volta.aurel32.net ([2001:618:400:fc13:216:d3ff:fe17:fd00]) by hall.aurel32.net with esmtpsa (TLS-1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from ) id 1Iconz-0006Rx-GP; Tue, 02 Oct 2007 22:57:23 +0200 Received: from localhost.localdomain ([127.0.0.1] ident=aurel32) by volta.aurel32.net with esmtp (Exim 4.67) (envelope-from ) id 1Icoo0-0004vB-Fi; Tue, 02 Oct 2007 22:57:24 +0200 Message-ID: <4702B0B4.6080909@aurel32.net> Date: Tue, 02 Oct 2007 22:57:24 +0200 From: Aurelien Jarno User-Agent: IceDove 1.5.0.10 (X11/20070328) MIME-Version: 1.0 To: Alan Cox CC: qemu-devel@nongnu.org, linux-mips@linux-mips.org Subject: Re: [Qemu-devel] QEMU/MIPS & dyntick kernel References: <20071002200644.GA19140@hall.aurel32.net> <4702A99B.7020008@qumranet.com> <4702AC0F.1000906@aurel32.net> <20071002214826.7ee2fae8@the-village.bc.nu> In-Reply-To: <20071002214826.7ee2fae8@the-village.bc.nu> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 16807 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: aurelien@aurel32.net Precedence: bulk X-list: linux-mips Alan Cox a écrit : >> Well on real hardware, the instruction rate and the timer are linked: >> the timer run at half the speed of the CPU. As the corresponding >> assembly code is very small, only uses registers and is run in kernel >> mode, you know for sure that 48 cycles is more than enough. > > What happens on NMI or if you take an ECC exception and scrubbing stall > off the memory controller while loading part of that cache line of code > into memory ? > The code returns -ETIME, and the function is run again with the minimum delay. So as long as you don't have an exception every time, the code works. -- .''`. Aurelien Jarno | GPG: 1024D/F1BCDB73 : :' : Debian developer | Electrical Engineer `. `' aurel32@debian.org | aurelien@aurel32.net `- people.debian.org/~aurel32 | www.aurel32.net From ralf@linux-mips.org Tue Oct 2 23:35:50 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 02 Oct 2007 23:35:52 +0100 (BST) Received: from localhost.localdomain ([127.0.0.1]:18075 "EHLO dl5rb.ham-radio-op.net") by ftp.linux-mips.org with ESMTP id S20023614AbXJBWfu (ORCPT ); Tue, 2 Oct 2007 23:35:50 +0100 Received: from denk.linux-mips.net (denk.linux-mips.net [127.0.0.1]) by dl5rb.ham-radio-op.net (8.14.1/8.13.8) with ESMTP id l92MZnKN022102; Tue, 2 Oct 2007 23:35:49 +0100 Received: (from ralf@localhost) by denk.linux-mips.net (8.14.1/8.14.1/Submit) id l92MZlER022100; Tue, 2 Oct 2007 23:35:47 +0100 Date: Tue, 2 Oct 2007 23:35:47 +0100 From: Ralf Baechle To: Aurelien Jarno Cc: Alan Cox , qemu-devel@nongnu.org, linux-mips@linux-mips.org Subject: Re: [Qemu-devel] QEMU/MIPS & dyntick kernel Message-ID: <20071002223547.GA21687@linux-mips.org> References: <20071002200644.GA19140@hall.aurel32.net> <4702A99B.7020008@qumranet.com> <4702AC0F.1000906@aurel32.net> <20071002214826.7ee2fae8@the-village.bc.nu> <4702B0B4.6080909@aurel32.net> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <4702B0B4.6080909@aurel32.net> User-Agent: Mutt/1.5.14 (2007-02-12) Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 16808 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: ralf@linux-mips.org Precedence: bulk X-list: linux-mips On Tue, Oct 02, 2007 at 10:57:24PM +0200, Aurelien Jarno wrote: > From: Aurelien Jarno > Date: Tue, 02 Oct 2007 22:57:24 +0200 > To: Alan Cox > CC: qemu-devel@nongnu.org, linux-mips@linux-mips.org > Subject: Re: [Qemu-devel] QEMU/MIPS & dyntick kernel > Content-Type: text/plain; charset=ISO-8859-1 > > Alan Cox a écrit : > >> Well on real hardware, the instruction rate and the timer are linked: > >> the timer run at half the speed of the CPU. As the corresponding > >> assembly code is very small, only uses registers and is run in kernel > >> mode, you know for sure that 48 cycles is more than enough. > > > > What happens on NMI or if you take an ECC exception and scrubbing stall > > off the memory controller while loading part of that cache line of code > > into memory ? > > > > The code returns -ETIME, and the function is run again with the minimum > delay. > > So as long as you don't have an exception every time, the code works. The current setting should be safe on real hardware - but a value of just 48 cycles for max_delta_ns is probably lower than the lowest useful value, so I don't mind raising it. This number really is a tunable. Ralf From fxzhang@ict.ac.cn Tue Oct 2 23:47:58 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 02 Oct 2007 23:48:07 +0100 (BST) Received: from webmail.ict.ac.cn ([159.226.39.7]:63410 "EHLO ict.ac.cn") by ftp.linux-mips.org with ESMTP id S20023728AbXJBWr6 (ORCPT ); Tue, 2 Oct 2007 23:47:58 +0100 Received: (qmail 12941 invoked by uid 507); 3 Oct 2007 06:45:22 +0800 Received: from unknown (HELO ?192.168.1.8?) (fxzhang@222.92.8.142) by ict.ac.cn with SMTP; 3 Oct 2007 06:45:22 +0800 Message-ID: <4702CABC.40600@ict.ac.cn> Date: Wed, 03 Oct 2007 06:48:28 +0800 From: Fuxin Zhang User-Agent: IceDove 1.5.0.10 (X11/20070329) MIME-Version: 1.0 To: Ralf Baechle CC: linux-mips@linux-mips.org Subject: Re: cmpxchg broken in some situation References: <46FF7BC2.5050905@ict.ac.cn> <20071001025340.GA7091@linux-mips.org> <47010E15.7060109@ict.ac.cn> <20071001152620.GB15820@linux-mips.org> <470210B4.8020902@ict.ac.cn> <20071002103551.GB5152@linux-mips.org> In-Reply-To: <20071002103551.GB5152@linux-mips.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 16809 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: fxzhang@ict.ac.cn Precedence: bulk X-list: linux-mips And the comment "# cmpxchg_u32" is out of date too:) Ralf Baechle 写é“: > On Tue, Oct 02, 2007 at 05:34:44PM +0800, Fuxin Zhang wrote: > > >> The problem is here: >> >> switch (sizeof(__ptr)) { // --> should be sizeof(*(__ptr)) >> case 4: >> ... >> Recompiling.. >> > > There was another small kink, cmpxchg_local() does not imply a memory > barrier so I optimized that case. > > And I don't complain about it being 151 lines shorter ;-) > > Ralf > > From: Ralf Baechle > > [MIPS] Typeproof reimplementation of cmpxchg. > > Signed-off-by: Ralf Baechle > > diff --git a/include/asm-mips/cmpxchg.h b/include/asm-mips/cmpxchg.h > new file mode 100644 > index 0000000..46bac47 > --- /dev/null > +++ b/include/asm-mips/cmpxchg.h > @@ -0,0 +1,107 @@ > +/* > + * 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) 2003, 06, 07 by Ralf Baechle (ralf@linux-mips.org) > + */ > +#ifndef __ASM_CMPXCHG_H > +#define __ASM_CMPXCHG_H > + > +#include > + > +#define __HAVE_ARCH_CMPXCHG 1 > + > +#define __cmpxchg_asm(ld, st, m, old, new) \ > +({ \ > + __typeof(*(m)) __ret; \ > + \ > + if (cpu_has_llsc && R10000_LLSC_WAR) { \ > + __asm__ __volatile__( \ > + " .set push \n" \ > + " .set noat \n" \ > + " .set mips3 \n" \ > + "1: " ld " %0, %2 # __cmpxchg_u32 \n" \ > + " bne %0, %z3, 2f \n" \ > + " .set mips0 \n" \ > + " move $1, %z4 \n" \ > + " .set mips3 \n" \ > + " " st " $1, %1 \n" \ > + " beqzl $1, 1b \n" \ > + "2: \n" \ > + " .set pop \n" \ > + : "=&r" (__ret), "=R" (*m) \ > + : "R" (*m), "Jr" (old), "Jr" (new) \ > + : "memory"); \ > + } else if (cpu_has_llsc) { \ > + __asm__ __volatile__( \ > + " .set push \n" \ > + " .set noat \n" \ > + " .set mips3 \n" \ > + "1: " ld " %0, %2 # __cmpxchg_u32 \n" \ > + " bne %0, %z3, 2f \n" \ > + " .set mips0 \n" \ > + " move $1, %z4 \n" \ > + " .set mips3 \n" \ > + " " st " $1, %1 \n" \ > + " beqz $1, 3f \n" \ > + "2: \n" \ > + " .subsection 2 \n" \ > + "3: b 1b \n" \ > + " .previous \n" \ > + " .set pop \n" \ > + : "=&r" (__ret), "=R" (*m) \ > + : "R" (*m), "Jr" (old), "Jr" (new) \ > + : "memory"); \ > + } else { \ > + unsigned long __flags; \ > + \ > + raw_local_irq_save(__flags); \ > + __ret = *m; \ > + if (__ret == old) \ > + *m = new; \ > + raw_local_irq_restore(__flags); \ > + } \ > + \ > + smp_llsc_mb(); \ > + \ > + __ret; \ > +}) > + > +/* > + * This function doesn't exist, so you'll get a linker error > + * if something tries to do an invalid cmpxchg(). > + */ > +extern void __cmpxchg_called_with_bad_pointer(void); > + > +#define __cmpxchg(ptr,old,new,barrier) \ > +({ \ > + __typeof__(ptr) __ptr = (ptr); \ > + __typeof__(*(ptr)) __old = (old); \ > + __typeof__(*(ptr)) __new = (new); \ > + __typeof__(*(ptr)) __res = 0; \ > + \ > + switch (sizeof(*(__ptr))) { \ > + case 4: \ > + __res = __cmpxchg_asm("ll", "sc", __ptr, __old, __new); \ > + break; \ > + case 8: \ > + if (sizeof(long) == 8) { \ > + __res = __cmpxchg_asm("lld", "scd", __ptr, \ > + __old, __new); \ > + break; \ > + } \ > + default: \ > + __cmpxchg_called_with_bad_pointer(); \ > + break; \ > + } \ > + \ > + barrier; \ > + \ > + __res; \ > +}) > + > +#define cmpxchg(ptr, old, new) __cmpxchg(ptr, old, new, smp_llsc_mb()) > +#define cmpxchg_local(ptr, old, new) __cmpxchg(ptr, old, new,) > + > +#endif /* __ASM_CMPXCHG_H */ > diff --git a/include/asm-mips/local.h b/include/asm-mips/local.h > index ed882c8..7034a01 100644 > --- a/include/asm-mips/local.h > +++ b/include/asm-mips/local.h > @@ -4,6 +4,7 @@ > #include > #include > #include > +#include > #include > > typedef struct > diff --git a/include/asm-mips/system.h b/include/asm-mips/system.h > index 357251f..480b574 100644 > --- a/include/asm-mips/system.h > +++ b/include/asm-mips/system.h > @@ -17,6 +17,7 @@ > > #include > #include > +#include > #include > #include > #include > @@ -194,266 +195,6 @@ static inline unsigned long __xchg(unsigned long x, volatile void * ptr, int siz > > #define xchg(ptr,x) ((__typeof__(*(ptr)))__xchg((unsigned long)(x),(ptr),sizeof(*(ptr)))) > > -#define __HAVE_ARCH_CMPXCHG 1 > - > -static inline unsigned long __cmpxchg_u32(volatile int * m, unsigned long old, > - unsigned long new) > -{ > - __u32 retval; > - > - if (cpu_has_llsc && R10000_LLSC_WAR) { > - __asm__ __volatile__( > - " .set push \n" > - " .set noat \n" > - " .set mips3 \n" > - "1: ll %0, %2 # __cmpxchg_u32 \n" > - " bne %0, %z3, 2f \n" > - " .set mips0 \n" > - " move $1, %z4 \n" > - " .set mips3 \n" > - " sc $1, %1 \n" > - " beqzl $1, 1b \n" > - "2: \n" > - " .set pop \n" > - : "=&r" (retval), "=R" (*m) > - : "R" (*m), "Jr" (old), "Jr" (new) > - : "memory"); > - } else if (cpu_has_llsc) { > - __asm__ __volatile__( > - " .set push \n" > - " .set noat \n" > - " .set mips3 \n" > - "1: ll %0, %2 # __cmpxchg_u32 \n" > - " bne %0, %z3, 2f \n" > - " .set mips0 \n" > - " move $1, %z4 \n" > - " .set mips3 \n" > - " sc $1, %1 \n" > - " beqz $1, 3f \n" > - "2: \n" > - " .subsection 2 \n" > - "3: b 1b \n" > - " .previous \n" > - " .set pop \n" > - : "=&r" (retval), "=R" (*m) > - : "R" (*m), "Jr" (old), "Jr" (new) > - : "memory"); > - } else { > - unsigned long flags; > - > - raw_local_irq_save(flags); > - retval = *m; > - if (retval == old) > - *m = new; > - raw_local_irq_restore(flags); /* implies memory barrier */ > - } > - > - smp_llsc_mb(); > - > - return retval; > -} > - > -static inline unsigned long __cmpxchg_u32_local(volatile int * m, > - unsigned long old, unsigned long new) > -{ > - __u32 retval; > - > - if (cpu_has_llsc && R10000_LLSC_WAR) { > - __asm__ __volatile__( > - " .set push \n" > - " .set noat \n" > - " .set mips3 \n" > - "1: ll %0, %2 # __cmpxchg_u32 \n" > - " bne %0, %z3, 2f \n" > - " .set mips0 \n" > - " move $1, %z4 \n" > - " .set mips3 \n" > - " sc $1, %1 \n" > - " beqzl $1, 1b \n" > - "2: \n" > - " .set pop \n" > - : "=&r" (retval), "=R" (*m) > - : "R" (*m), "Jr" (old), "Jr" (new) > - : "memory"); > - } else if (cpu_has_llsc) { > - __asm__ __volatile__( > - " .set push \n" > - " .set noat \n" > - " .set mips3 \n" > - "1: ll %0, %2 # __cmpxchg_u32 \n" > - " bne %0, %z3, 2f \n" > - " .set mips0 \n" > - " move $1, %z4 \n" > - " .set mips3 \n" > - " sc $1, %1 \n" > - " beqz $1, 1b \n" > - "2: \n" > - " .set pop \n" > - : "=&r" (retval), "=R" (*m) > - : "R" (*m), "Jr" (old), "Jr" (new) > - : "memory"); > - } else { > - unsigned long flags; > - > - local_irq_save(flags); > - retval = *m; > - if (retval == old) > - *m = new; > - local_irq_restore(flags); /* implies memory barrier */ > - } > - > - return retval; > -} > - > -#ifdef CONFIG_64BIT > -static inline unsigned long __cmpxchg_u64(volatile int * m, unsigned long old, > - unsigned long new) > -{ > - __u64 retval; > - > - if (cpu_has_llsc && R10000_LLSC_WAR) { > - __asm__ __volatile__( > - " .set push \n" > - " .set noat \n" > - " .set mips3 \n" > - "1: lld %0, %2 # __cmpxchg_u64 \n" > - " bne %0, %z3, 2f \n" > - " move $1, %z4 \n" > - " scd $1, %1 \n" > - " beqzl $1, 1b \n" > - "2: \n" > - " .set pop \n" > - : "=&r" (retval), "=R" (*m) > - : "R" (*m), "Jr" (old), "Jr" (new) > - : "memory"); > - } else if (cpu_has_llsc) { > - __asm__ __volatile__( > - " .set push \n" > - " .set noat \n" > - " .set mips3 \n" > - "1: lld %0, %2 # __cmpxchg_u64 \n" > - " bne %0, %z3, 2f \n" > - " move $1, %z4 \n" > - " scd $1, %1 \n" > - " beqz $1, 3f \n" > - "2: \n" > - " .subsection 2 \n" > - "3: b 1b \n" > - " .previous \n" > - " .set pop \n" > - : "=&r" (retval), "=R" (*m) > - : "R" (*m), "Jr" (old), "Jr" (new) > - : "memory"); > - } else { > - unsigned long flags; > - > - raw_local_irq_save(flags); > - retval = *m; > - if (retval == old) > - *m = new; > - raw_local_irq_restore(flags); /* implies memory barrier */ > - } > - > - smp_llsc_mb(); > - > - return retval; > -} > - > -static inline unsigned long __cmpxchg_u64_local(volatile int * m, > - unsigned long old, unsigned long new) > -{ > - __u64 retval; > - > - if (cpu_has_llsc && R10000_LLSC_WAR) { > - __asm__ __volatile__( > - " .set push \n" > - " .set noat \n" > - " .set mips3 \n" > - "1: lld %0, %2 # __cmpxchg_u64 \n" > - " bne %0, %z3, 2f \n" > - " move $1, %z4 \n" > - " scd $1, %1 \n" > - " beqzl $1, 1b \n" > - "2: \n" > - " .set pop \n" > - : "=&r" (retval), "=R" (*m) > - : "R" (*m), "Jr" (old), "Jr" (new) > - : "memory"); > - } else if (cpu_has_llsc) { > - __asm__ __volatile__( > - " .set push \n" > - " .set noat \n" > - " .set mips3 \n" > - "1: lld %0, %2 # __cmpxchg_u64 \n" > - " bne %0, %z3, 2f \n" > - " move $1, %z4 \n" > - " scd $1, %1 \n" > - " beqz $1, 1b \n" > - "2: \n" > - " .set pop \n" > - : "=&r" (retval), "=R" (*m) > - : "R" (*m), "Jr" (old), "Jr" (new) > - : "memory"); > - } else { > - unsigned long flags; > - > - local_irq_save(flags); > - retval = *m; > - if (retval == old) > - *m = new; > - local_irq_restore(flags); /* implies memory barrier */ > - } > - > - return retval; > -} > - > -#else > -extern unsigned long __cmpxchg_u64_unsupported_on_32bit_kernels( > - volatile int * m, unsigned long old, unsigned long new); > -#define __cmpxchg_u64 __cmpxchg_u64_unsupported_on_32bit_kernels > -extern unsigned long __cmpxchg_u64_local_unsupported_on_32bit_kernels( > - volatile int * m, unsigned long old, unsigned long new); > -#define __cmpxchg_u64_local __cmpxchg_u64_local_unsupported_on_32bit_kernels > -#endif > - > -/* This function doesn't exist, so you'll get a linker error > - if something tries to do an invalid cmpxchg(). */ > -extern void __cmpxchg_called_with_bad_pointer(void); > - > -static inline unsigned long __cmpxchg(volatile void * ptr, unsigned long old, > - unsigned long new, int size) > -{ > - switch (size) { > - case 4: > - return __cmpxchg_u32(ptr, old, new); > - case 8: > - return __cmpxchg_u64(ptr, old, new); > - } > - __cmpxchg_called_with_bad_pointer(); > - return old; > -} > - > -static inline unsigned long __cmpxchg_local(volatile void * ptr, > - unsigned long old, unsigned long new, int size) > -{ > - switch (size) { > - case 4: > - return __cmpxchg_u32_local(ptr, old, new); > - case 8: > - return __cmpxchg_u64_local(ptr, old, new); > - } > - __cmpxchg_called_with_bad_pointer(); > - return old; > -} > - > -#define cmpxchg(ptr,old,new) \ > - ((__typeof__(*(ptr)))__cmpxchg((ptr), \ > - (unsigned long)(old), (unsigned long)(new),sizeof(*(ptr)))) > - > -#define cmpxchg_local(ptr,old,new) \ > - ((__typeof__(*(ptr)))__cmpxchg_local((ptr), \ > - (unsigned long)(old), (unsigned long)(new),sizeof(*(ptr)))) > - > extern void set_handler (unsigned long offset, void *addr, unsigned long len); > extern void set_uncached_handler (unsigned long offset, void *addr, unsigned long len); > > > > > From ralf@linux-mips.org Tue Oct 2 23:52:54 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 02 Oct 2007 23:52:56 +0100 (BST) Received: from localhost.localdomain ([127.0.0.1]:478 "EHLO dl5rb.ham-radio-op.net") by ftp.linux-mips.org with ESMTP id S20023750AbXJBWwy (ORCPT ); Tue, 2 Oct 2007 23:52:54 +0100 Received: from denk.linux-mips.net (denk.linux-mips.net [127.0.0.1]) by dl5rb.ham-radio-op.net (8.14.1/8.13.8) with ESMTP id l92MqqsT022422; Tue, 2 Oct 2007 23:52:52 +0100 Received: (from ralf@localhost) by denk.linux-mips.net (8.14.1/8.14.1/Submit) id l92MqooA022421; Tue, 2 Oct 2007 23:52:50 +0100 Date: Tue, 2 Oct 2007 23:52:50 +0100 From: Ralf Baechle To: Fuxin Zhang Cc: linux-mips@linux-mips.org Subject: Re: cmpxchg broken in some situation Message-ID: <20071002225250.GB21687@linux-mips.org> References: <46FF7BC2.5050905@ict.ac.cn> <20071001025340.GA7091@linux-mips.org> <47010E15.7060109@ict.ac.cn> <20071001152620.GB15820@linux-mips.org> <470210B4.8020902@ict.ac.cn> <20071002103551.GB5152@linux-mips.org> <4702CABC.40600@ict.ac.cn> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4702CABC.40600@ict.ac.cn> User-Agent: Mutt/1.5.14 (2007-02-12) Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 16810 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: ralf@linux-mips.org Precedence: bulk X-list: linux-mips On Wed, Oct 03, 2007 at 06:48:28AM +0800, Fuxin Zhang wrote: > And the comment "# cmpxchg_u32" is out of date too:) I've seen worse bugs ;-) Ralf From fxzhang@ict.ac.cn Wed Oct 3 00:08:45 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 03 Oct 2007 00:08:54 +0100 (BST) Received: from webmail.ict.ac.cn ([159.226.39.7]:17593 "EHLO ict.ac.cn") by ftp.linux-mips.org with ESMTP id S20023808AbXJBXIp (ORCPT ); Wed, 3 Oct 2007 00:08:45 +0100 Received: (qmail 920 invoked by uid 507); 3 Oct 2007 07:04:51 +0800 Received: from unknown (HELO ?192.168.1.8?) (fxzhang@222.92.8.142) by ict.ac.cn with SMTP; 3 Oct 2007 07:04:51 +0800 Message-ID: <4702CF4A.8050609@ict.ac.cn> Date: Wed, 03 Oct 2007 07:07:54 +0800 From: Fuxin Zhang User-Agent: IceDove 1.5.0.10 (X11/20070329) MIME-Version: 1.0 To: Ralf Baechle CC: linux-mips@linux-mips.org Subject: Re: cmpxchg broken in some situation References: <46FF7BC2.5050905@ict.ac.cn> <20071001025340.GA7091@linux-mips.org> <47010E15.7060109@ict.ac.cn> <20071001152620.GB15820@linux-mips.org> <470210B4.8020902@ict.ac.cn> <20071002103551.GB5152@linux-mips.org> <4702CABC.40600@ict.ac.cn> <20071002225250.GB21687@linux-mips.org> In-Reply-To: <20071002225250.GB21687@linux-mips.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 16811 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: fxzhang@ict.ac.cn Precedence: bulk X-list: linux-mips en? It seems that it is working for my case now. Ralf Baechle 写é“: > On Wed, Oct 03, 2007 at 06:48:28AM +0800, Fuxin Zhang wrote: > > >> And the comment "# cmpxchg_u32" is out of date too:) >> > > I've seen worse bugs ;-) > > Ralf > > > > > From ralf@linux-mips.org Wed Oct 3 00:15:49 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 03 Oct 2007 00:15:52 +0100 (BST) Received: from localhost.localdomain ([127.0.0.1]:61162 "EHLO dl5rb.ham-radio-op.net") by ftp.linux-mips.org with ESMTP id S20023858AbXJBXPt (ORCPT ); Wed, 3 Oct 2007 00:15:49 +0100 Received: from denk.linux-mips.net (denk.linux-mips.net [127.0.0.1]) by dl5rb.ham-radio-op.net (8.14.1/8.13.8) with ESMTP id l92NFmXJ003645; Wed, 3 Oct 2007 00:15:48 +0100 Received: (from ralf@localhost) by denk.linux-mips.net (8.14.1/8.14.1/Submit) id l92NFmre003644; Wed, 3 Oct 2007 00:15:48 +0100 Date: Wed, 3 Oct 2007 00:15:48 +0100 From: Ralf Baechle To: Thiemo Seufer Cc: Fuxin Zhang , linux-mips@linux-mips.org Subject: Re: cmpxchg broken in some situation Message-ID: <20071002231548.GA1240@linux-mips.org> References: <46FF7BC2.5050905@ict.ac.cn> <20071001025340.GA7091@linux-mips.org> <47010E15.7060109@ict.ac.cn> <20071001152620.GB15820@linux-mips.org> <470210B4.8020902@ict.ac.cn> <20071002103551.GB5152@linux-mips.org> <20071002142210.GD16772@networkno.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20071002142210.GD16772@networkno.de> User-Agent: Mutt/1.5.14 (2007-02-12) Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 16812 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: ralf@linux-mips.org Precedence: bulk X-list: linux-mips On Tue, Oct 02, 2007 at 03:22:10PM +0100, Thiemo Seufer wrote: > > +#define __cmpxchg(ptr,old,new,barrier) \ > > +({ \ > > + __typeof__(ptr) __ptr = (ptr); \ > > + __typeof__(*(ptr)) __old = (old); \ > > + __typeof__(*(ptr)) __new = (new); \ > > + __typeof__(*(ptr)) __res = 0; \ > > Maybe we need an acquire barrier here for some systems. Release you meant. The acquire lock would be at the end. Documentation and actual implmeentations of cmpxchg seem to differ. It's a relativly rarely used primitve so I think I err on the side of paranoia for now and throw in the additional SYNC you suggest. Ralf From ralf@linux-mips.org Wed Oct 3 01:04:26 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 03 Oct 2007 01:04:28 +0100 (BST) Received: from localhost.localdomain ([127.0.0.1]:65260 "EHLO dl5rb.ham-radio-op.net") by ftp.linux-mips.org with ESMTP id S20023995AbXJCAE0 (ORCPT ); Wed, 3 Oct 2007 01:04:26 +0100 Received: from denk.linux-mips.net (denk.linux-mips.net [127.0.0.1]) by dl5rb.ham-radio-op.net (8.14.1/8.13.8) with ESMTP id l9304POp012588; Wed, 3 Oct 2007 01:04:25 +0100 Received: (from ralf@localhost) by denk.linux-mips.net (8.14.1/8.14.1/Submit) id l9304PZx012587; Wed, 3 Oct 2007 01:04:25 +0100 Date: Wed, 3 Oct 2007 01:04:25 +0100 From: Ralf Baechle To: "Maciej W. Rozycki" Cc: Thiemo Seufer , linux-mips@linux-mips.org Subject: Re: [PATCH] mm/pg-r4k.c: Fix a typo in an R4600 v2 erratum workaround Message-ID: <20071003000425.GA11833@linux-mips.org> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.14 (2007-02-12) Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 16813 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: ralf@linux-mips.org Precedence: bulk X-list: linux-mips On Tue, Oct 02, 2007 at 02:47:22PM +0100, Maciej W. Rozycki wrote: > Restore a load from KSEG1 done as a workaround for an R4600 v2 > erratum, dropped with 211be16de99a7424e66c0b6c0d00e2c970508ac2. > > Signed-off-by: Maciej W. Rozycki > --- > Thiemo, > > It reverts your change of Sep 1st, 2005; given the way the code is > written, I am assuming the change was accidental, correct? At the moment > the load never happens. But it should ... So this seems to be the right thing, no? Ralf diff --git a/arch/mips/mm/pg-r4k.c b/arch/mips/mm/pg-r4k.c index dc795be..66921fb 100644 --- a/arch/mips/mm/pg-r4k.c +++ b/arch/mips/mm/pg-r4k.c @@ -208,8 +208,10 @@ static inline void build_cdex_p(void) build_nop(); } - if (R4600_V2_HIT_CACHEOP_WAR && cpu_is_r4600_v2_x()) + if (R4600_V2_HIT_CACHEOP_WAR && cpu_is_r4600_v2_x()) { build_insn_word(0x3c01a000); /* lui $at, 0xa000 */ + build_insn_word(0x8c200000); /* lw $zero, ($at) */ + } mi.c_format.opcode = cache_op; mi.c_format.rs = 4; /* $a0 */ @@ -390,8 +392,10 @@ void __init build_clear_page(void) } else build_addiu_a2_a0(off); - if (R4600_V2_HIT_CACHEOP_WAR && cpu_is_r4600_v2_x()) + if (R4600_V2_HIT_CACHEOP_WAR && cpu_is_r4600_v2_x()) { build_insn_word(0x3c01a000); /* lui $at, 0xa000 */ + build_insn_word(0x8c200000); /* lw $zero, ($at) */ + } dest = label(); do { @@ -452,8 +456,10 @@ void __init build_copy_page(void) } else build_addiu_a2_a0(off); - if (R4600_V2_HIT_CACHEOP_WAR && cpu_is_r4600_v2_x()) + if (R4600_V2_HIT_CACHEOP_WAR && cpu_is_r4600_v2_x()) { build_insn_word(0x3c01a000); /* lui $at, 0xa000 */ + build_insn_word(0x8c200000); /* lw $zero, ($at) */ + } dest = label(); loop_start = store_offset; From ralf@linux-mips.org Wed Oct 3 01:21:20 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 03 Oct 2007 01:21:22 +0100 (BST) Received: from localhost.localdomain ([127.0.0.1]:62413 "EHLO dl5rb.ham-radio-op.net") by ftp.linux-mips.org with ESMTP id S20024040AbXJCAVU (ORCPT ); Wed, 3 Oct 2007 01:21:20 +0100 Received: from denk.linux-mips.net (denk.linux-mips.net [127.0.0.1]) by dl5rb.ham-radio-op.net (8.14.1/8.13.8) with ESMTP id l930LIQA012991; Wed, 3 Oct 2007 01:21:18 +0100 Received: (from ralf@localhost) by denk.linux-mips.net (8.14.1/8.14.1/Submit) id l930LIoR012990; Wed, 3 Oct 2007 01:21:18 +0100 Date: Wed, 3 Oct 2007 01:21:18 +0100 From: Ralf Baechle To: "Maciej W. Rozycki" Cc: Thiemo Seufer , linux-mips@linux-mips.org Subject: Re: [PATCH] mm/pg-r4k.c: Fix a typo in an R4600 v2 erratum workaround Message-ID: <20071003002118.GA12964@linux-mips.org> References: <20071003000425.GA11833@linux-mips.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20071003000425.GA11833@linux-mips.org> User-Agent: Mutt/1.5.14 (2007-02-12) Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 16814 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: ralf@linux-mips.org Precedence: bulk X-list: linux-mips On Wed, Oct 03, 2007 at 01:04:25AM +0100, Ralf Baechle wrote: > > Restore a load from KSEG1 done as a workaround for an R4600 v2 > > erratum, dropped with 211be16de99a7424e66c0b6c0d00e2c970508ac2. > > > > Signed-off-by: Maciej W. Rozycki > > --- > > Thiemo, > > > > It reverts your change of Sep 1st, 2005; given the way the code is > > written, I am assuming the change was accidental, correct? At the moment > > the load never happens. > > But it should ... So this seems to be the right thing, no? Ah, I see. So I applied your patch. Ralf From ralf@linux-mips.org Wed Oct 3 02:00:54 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 03 Oct 2007 02:00:56 +0100 (BST) Received: from localhost.localdomain ([127.0.0.1]:36320 "EHLO dl5rb.ham-radio-op.net") by ftp.linux-mips.org with ESMTP id S20024228AbXJCBAy (ORCPT ); Wed, 3 Oct 2007 02:00:54 +0100 Received: from denk.linux-mips.net (denk.linux-mips.net [127.0.0.1]) by dl5rb.ham-radio-op.net (8.14.1/8.13.8) with ESMTP id l9310r1u025772; Wed, 3 Oct 2007 02:00:53 +0100 Received: (from ralf@localhost) by denk.linux-mips.net (8.14.1/8.14.1/Submit) id l9310r6s025771; Wed, 3 Oct 2007 02:00:53 +0100 Date: Wed, 3 Oct 2007 02:00:53 +0100 From: Ralf Baechle To: "Maciej W. Rozycki" Cc: Thiemo Seufer , linux-mips@linux-mips.org Subject: Re: [PATCH] mm/pg-r4k.c: Dump the generated code Message-ID: <20071003010053.GA25603@linux-mips.org> References: <20071002141125.GC16772@networkno.de> <20071002154918.GA11312@linux-mips.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.14 (2007-02-12) Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 16815 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: ralf@linux-mips.org Precedence: bulk X-list: linux-mips On Tue, Oct 02, 2007 at 05:08:05PM +0100, Maciej W. Rozycki wrote: > > I have a patch which makes the generated code accessible through a > > procfs file. That can easily be converted back into a .o file and then > > be disassembled. So it's now a question of which variant is preferable. > > There is no need to go through such hassle even: > > $ objdump -b binary -m mips:4000 -d /proc/foo > > or suchlike should work (the program seems to be sensitive to the file > size though, so it better be non-zero). > > > I don't mind - it's just that I've never been a friend of leaving much > > debugging code or features around. 99% of the time it is just make the > > code harder to read and maintain. > > In this case I would let these bits stay in though. The bootstrap log > always works and can be captured with the serial console or read from the > screen, and if there is a subtle breakage in these generated bits then the > system may never get far enough for procfs to be accessible. It is these > moments it matters the most. I originally wrote my variant as a tool for optimization. Anyway, queued for 2.6.24. That is if 2.6.23 is ever released ;-) Ralf From kumba@gentoo.org Wed Oct 3 07:06:57 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 03 Oct 2007 07:07:06 +0100 (BST) Received: from alnrmhc12.comcast.net ([204.127.225.92]:14776 "EHLO alnrmhc12.comcast.net") by ftp.linux-mips.org with ESMTP id S20022205AbXJCGG5 (ORCPT ); Wed, 3 Oct 2007 07:06:57 +0100 Received: from [192.168.1.4] (c-69-140-18-238.hsd1.md.comcast.net[69.140.18.238]) by comcast.net (alnrmhc12) with ESMTP id <20071003060614b1200m1ra0e>; Wed, 3 Oct 2007 06:06:14 +0000 Message-ID: <47033156.7090703@gentoo.org> Date: Wed, 03 Oct 2007 02:06:14 -0400 From: Kumba User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Ed Stafford CC: linux-mips@linux-mips.org Subject: Re: What is the current state of the Octane/IP30 support? References: <41370a610710021341g749742dejec06b3a38477fd47@mail.gmail.com> In-Reply-To: <41370a610710021341g749742dejec06b3a38477fd47@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 16816 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: kumba@gentoo.org Precedence: bulk X-list: linux-mips Ed Stafford wrote: > I have a single-proc Octane at home that I've decided should be > running with Linux, but I have been reading up online about the > Experimental nature of the kernel in relation to the hardware. Since > most of the info I found was dated 2006, I wanted to ask your (as a > group) opinion on how stable / usable the Octane is today with the > current kernel. > > I'm not adverse to bleeding edge, I just want to know whether or not > I'll be struggling on something that just doesn't have enough drivers > written for it to make it usable. > > Just in case anyone asks, I'll probably be using Gentoo, but I'm not > glued to that distro. (I'm very agnostic and just prefer it to work > the best vs. distro-warring..) > > Thanks a bunch! Right now, Gentoo does have the best support for them (mine is running 2.6.23-rc5 about 3.5ft from me as I type). But I do believe the debian guys have been working on a debian install image for them too (tbm/ths, am I right on this?) For the most part, Impact-based systems run great. You get X, unaccelerated, no 3D, and a framebuffer. VPro, framebuffer, but no X. USB kinda weorks if you have a PCI-Card Cage and a OHCI chipsets (UHCI is dead last I checked), and I think EHCI works fine. Haven't tried much else beyond those PCI devices. A lot of the other XIO Boards, outside of the Impact or Vpro boards, are wholly untested, and likely won't work at all. Nor do I think dual head will work if you have a second Impact card kicking around. For gentoo, we have an "RC6" livecd. I've played with building an RC7 several times, but that got sidetracked about 2-3 months ago. I hope to resume work on it soon. You can find that and the current netboots on your local gentoo mirror, in the experimental/mips sub-folders. Further gentoo questions regarding this system should be directed to the gentoo-mips ML; linux-mips here is more for distro-agnostic development. Have fun! (and what Proc, btw?) --Kumba -- Gentoo/MIPS Team Lead "Such is oft the course of deeds that move the wheels of the world: small hands do them because they must, while the eyes of the great are elsewhere." --Elrond From geert@linux-m68k.org Wed Oct 3 08:02:51 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 03 Oct 2007 08:03:22 +0100 (BST) Received: from asia.telenet-ops.be ([195.130.137.74]:1428 "EHLO asia.telenet-ops.be") by ftp.linux-mips.org with ESMTP id S20022471AbXJCHCv (ORCPT ); Wed, 3 Oct 2007 08:02:51 +0100 Received: from localhost (localhost.localdomain [127.0.0.1]) by asia.telenet-ops.be (Postfix) with SMTP id 5B97FD41B0; Wed, 3 Oct 2007 09:02:50 +0200 (CEST) Received: from anakin.of.borg (d54C15D55.access.telenet.be [84.193.93.85]) by asia.telenet-ops.be (Postfix) with ESMTP id 3CF85D41CB; Wed, 3 Oct 2007 09:02:47 +0200 (CEST) Received: from anakin.of.borg (geert@localhost [127.0.0.1]) by anakin.of.borg (8.14.1/8.14.1/Debian-9) with ESMTP id l9372kMD019964 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 3 Oct 2007 09:02:46 +0200 Received: from localhost (geert@localhost) by anakin.of.borg (8.14.1/8.14.1/Submit) with ESMTP id l9372keA019961; Wed, 3 Oct 2007 09:02:46 +0200 X-Authentication-Warning: anakin.of.borg: geert owned process doing -bs Date: Wed, 3 Oct 2007 09:02:46 +0200 (CEST) From: Geert Uytterhoeven To: Kumba Cc: Ed Stafford , linux-mips@linux-mips.org Subject: Re: What is the current state of the Octane/IP30 support? In-Reply-To: <47033156.7090703@gentoo.org> Message-ID: References: <41370a610710021341g749742dejec06b3a38477fd47@mail.gmail.com> <47033156.7090703@gentoo.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 16817 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: geert@linux-m68k.org Precedence: bulk X-list: linux-mips On Wed, 3 Oct 2007, Kumba wrote: > For the most part, Impact-based systems run great. You get X, unaccelerated, > no 3D, and a framebuffer. VPro, framebuffer, but no X. USB kinda weorks if ^^^^^^^^^^^^^^^^^^^^^ What's the reason for not having X? X doesn't support the frame buffer layout? Gr{oetje,eeting}s, Geert -- Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say "programmer" or something like that. -- Linus Torvalds From geert@linux-m68k.org Wed Oct 3 08:05:54 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 03 Oct 2007 08:06:03 +0100 (BST) Received: from astra.telenet-ops.be ([195.130.132.58]:50585 "EHLO astra.telenet-ops.be") by ftp.linux-mips.org with ESMTP id S20022481AbXJCHFy (ORCPT ); Wed, 3 Oct 2007 08:05:54 +0100 Received: from localhost (localhost.localdomain [127.0.0.1]) by astra.telenet-ops.be (Postfix) with SMTP id F1F90380E4; Wed, 3 Oct 2007 09:05:43 +0200 (CEST) Received: from anakin.of.borg (d54C15D55.access.telenet.be [84.193.93.85]) by astra.telenet-ops.be (Postfix) with ESMTP id D0754380D0; Wed, 3 Oct 2007 09:05:43 +0200 (CEST) Received: from anakin.of.borg (geert@localhost [127.0.0.1]) by anakin.of.borg (8.14.1/8.14.1/Debian-9) with ESMTP id l9375h1g019997 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 3 Oct 2007 09:05:43 +0200 Received: from localhost (geert@localhost) by anakin.of.borg (8.14.1/8.14.1/Submit) with ESMTP id l9375heA019994; Wed, 3 Oct 2007 09:05:43 +0200 X-Authentication-Warning: anakin.of.borg: geert owned process doing -bs Date: Wed, 3 Oct 2007 09:05:43 +0200 (CEST) From: Geert Uytterhoeven To: Ralf Baechle Cc: "Maciej W. Rozycki" , Thiemo Seufer , linux-mips@linux-mips.org Subject: Re: [PATCH] mm/pg-r4k.c: Dump the generated code In-Reply-To: <20071003010053.GA25603@linux-mips.org> Message-ID: References: <20071002141125.GC16772@networkno.de> <20071002154918.GA11312@linux-mips.org> <20071003010053.GA25603@linux-mips.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 16818 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: geert@linux-m68k.org Precedence: bulk X-list: linux-mips On Wed, 3 Oct 2007, Ralf Baechle wrote: > Anyway, queued for 2.6.24. That is if 2.6.23 is ever released ;-) Any scripts relying on -rcX being single-digit? ;-) Gr{oetje,eeting}s, Geert -- Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say "programmer" or something like that. -- Linus Torvalds From tbm@cyrius.com Wed Oct 3 09:12:32 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 03 Oct 2007 09:12:40 +0100 (BST) Received: from sorrow.cyrius.com ([65.19.161.204]:32016 "EHLO sorrow.cyrius.com") by ftp.linux-mips.org with ESMTP id S20022747AbXJCIMc (ORCPT ); Wed, 3 Oct 2007 09:12:32 +0100 Received: by sorrow.cyrius.com (Postfix, from userid 10) id 6ADB8D8DA; Wed, 3 Oct 2007 08:11:55 +0000 (UTC) Received: by deprecation.cyrius.com (Postfix, from userid 1000) id 3D56C542CF; Wed, 3 Oct 2007 10:11:39 +0200 (CEST) Date: Wed, 3 Oct 2007 10:11:39 +0200 From: Martin Michlmayr To: Ed Stafford , linux-mips@linux-mips.org Subject: Re: What is the current state of the Octane/IP30 support? Message-ID: <20071003081139.GE22424@deprecation.cyrius.com> References: <41370a610710021341g749742dejec06b3a38477fd47@mail.gmail.com> <47033156.7090703@gentoo.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <47033156.7090703@gentoo.org> User-Agent: Mutt/1.5.16 (2007-06-11) Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 16819 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: tbm@cyrius.com Precedence: bulk X-list: linux-mips * Kumba [2007-10-03 02:06]: > Right now, Gentoo does have the best support for them (mine is > running 2.6.23-rc5 about 3.5ft from me as I type). But I do believe > the debian guys have been working on a debian install image for them > too (tbm/ths, am I right on this?) We don't really have any official support for Octane in Debian at the moment. -- Martin Michlmayr http://www.cyrius.com/ From ralf@linux-mips.org Wed Oct 3 11:32:08 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 03 Oct 2007 11:32:10 +0100 (BST) Received: from localhost.localdomain ([127.0.0.1]:57062 "EHLO dl5rb.ham-radio-op.net") by ftp.linux-mips.org with ESMTP id S20022395AbXJCKcI (ORCPT ); Wed, 3 Oct 2007 11:32:08 +0100 Received: from denk.linux-mips.net (denk.linux-mips.net [127.0.0.1]) by dl5rb.ham-radio-op.net (8.14.1/8.13.8) with ESMTP id l93AW7L5029479; Wed, 3 Oct 2007 11:32:07 +0100 Received: (from ralf@localhost) by denk.linux-mips.net (8.14.1/8.14.1/Submit) id l93AW6je029478; Wed, 3 Oct 2007 11:32:06 +0100 Date: Wed, 3 Oct 2007 11:32:06 +0100 From: Ralf Baechle To: Geert Uytterhoeven Cc: "Maciej W. Rozycki" , Thiemo Seufer , linux-mips@linux-mips.org Subject: Re: [PATCH] mm/pg-r4k.c: Dump the generated code Message-ID: <20071003103206.GA29244@linux-mips.org> References: <20071002141125.GC16772@networkno.de> <20071002154918.GA11312@linux-mips.org> <20071003010053.GA25603@linux-mips.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.14 (2007-02-12) Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 16820 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: ralf@linux-mips.org Precedence: bulk X-list: linux-mips On Wed, Oct 03, 2007 at 09:05:43AM +0200, Geert Uytterhoeven wrote: > On Wed, 3 Oct 2007, Ralf Baechle wrote: > > Anyway, queued for 2.6.24. That is if 2.6.23 is ever released ;-) > > Any scripts relying on -rcX being single-digit? ;-) if ($tag =~ /linux-([0-9]+\.[0-9]).*-.*/) { $final = "/pub/linux/mips/kernel/v$1/testing/$tag.tar.gz"; } elsif ($tag =~ /linux-([0-9]+\.[0-9])/) { $final = "/pub/linux/mips/kernel/v$1/$tag.tar.gz"; No :-) Ralf From ralf@linux-mips.org Wed Oct 3 11:57:51 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 03 Oct 2007 11:57:53 +0100 (BST) Received: from localhost.localdomain ([127.0.0.1]:51341 "EHLO dl5rb.ham-radio-op.net") by ftp.linux-mips.org with ESMTP id S20022592AbXJCK5v (ORCPT ); Wed, 3 Oct 2007 11:57:51 +0100 Received: from denk.linux-mips.net (denk.linux-mips.net [127.0.0.1]) by dl5rb.ham-radio-op.net (8.14.1/8.13.8) with ESMTP id l93AvpQb030146; Wed, 3 Oct 2007 11:57:51 +0100 Received: (from ralf@localhost) by denk.linux-mips.net (8.14.1/8.14.1/Submit) id l93AvpcH030145; Wed, 3 Oct 2007 11:57:51 +0100 Date: Wed, 3 Oct 2007 11:57:51 +0100 From: Ralf Baechle To: veerasena reddy Cc: linux-mips , "linux-kernel.org" Subject: Re: linux cache routines for Write-back cache policy on MIPS24KE Message-ID: <20071003105751.GD29244@linux-mips.org> References: <20071001105954.GB23647@linux-mips.org> <535696.48077.qm@web8403.mail.in.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <535696.48077.qm@web8403.mail.in.yahoo.com> User-Agent: Mutt/1.5.14 (2007-02-12) Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 16821 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: ralf@linux-mips.org Precedence: bulk X-list: linux-mips On Mon, Oct 01, 2007 at 01:10:59PM +0100, veerasena reddy wrote: > Is there any problem if we use the below API's in > linxu-2.6.18 > - dma_cache_wback_inv() > - dma_cache_wback() > - dma_cache_inv() > > functionality wise, especially in r4k.c i dont see any > difference between the implementation of these APIs. > > Can we apply the 2.6.24 patch to kill these APIs on > 2.6.18 kernel? In this case what APIs i can use for > writeback, invalidation or both? > > I couldn't find any info. related to the above API in > DMA-API.txt. Could you please give some pointers on > the usage/working of these APIs. dma_cache_* were never documented. They respresent the earliest attempt at coming up with an API that enables portable drivers and it has a few shortcomings and like so many early things it was never formally documented, so don't expect any well defined semantics. The functions never got formally retired probably because it somehow managed to stay under the radar. Any drivers should use the APIs documented in Documentation/DMA-API.txt only. The almost equivalent operation for dma_cache_* would be dma_sync_single and dma_sync_sg. Don't even dream about using dma_cache_* for anything but DMA coherency. They're all internal low level APIs which know nothing about Linux's virtual memory system. Anyway, it would be much easier to help you if we knew what you are trying to achieve with these functions. Ralf From vagabon.xyz@gmail.com Wed Oct 3 13:20:46 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 03 Oct 2007 13:20:54 +0100 (BST) Received: from mu-out-0910.google.com ([209.85.134.187]:46605 "EHLO mu-out-0910.google.com") by ftp.linux-mips.org with ESMTP id S20023203AbXJCMUq (ORCPT ); Wed, 3 Oct 2007 13:20:46 +0100 Received: by mu-out-0910.google.com with SMTP id w1so5288115mue for ; Wed, 03 Oct 2007 05:20:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding; bh=LEjw1IGxUb19AsCD24Asb8F76gLImol6AkB5lPCw0x8=; b=QqeYP0C7KbHgCI9Jwvt5lOf3+OHS0chknOrhDR8d6Sbc3o5LJ1dMPF2SAJxqV9dgaVrssdvH3D9dCLX2kR872AlZp/ODOuh3VcyjCBgqgUnFOlGB1IFSo+pSLa3vlK5y2BypniKzDJe8cP3lMSnS9pXZMHYVQTAZFvswVN3szIs= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding; b=LjFC8q/9PIYrNeAekU3Il0QJuie0TTWmAfsW02PYrA8muAmz3fQGc409pOkoQ6ZiBJpfEM/9VT2OC8eO2sM2xfXdBJtkxxnqThBSXdg1zlT994zYokpswchWZmxiGKWO4aQDvtqdyRQD3M8hxC5g9o7GUlCBBPB7rc8WTnEy5tk= Received: by 10.82.189.6 with SMTP id m6mr13789874buf.1191414028199; Wed, 03 Oct 2007 05:20:28 -0700 (PDT) Received: from ?192.168.0.1? ( [82.235.205.153]) by mx.google.com with ESMTPS id y6sm697078mug.2007.10.03.05.20.27 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 03 Oct 2007 05:20:27 -0700 (PDT) Message-ID: <47038874.9050704@gmail.com> Date: Wed, 03 Oct 2007 14:17:56 +0200 From: Franck Bui-Huu User-Agent: Thunderbird 2.0.0.5 (X11/20070719) MIME-Version: 1.0 To: Ralf Baechle CC: Thiemo Seufer , "Maciej W. Rozycki" , linux-mips@linux-mips.org Subject: Re: [PATCH] mm/pg-r4k.c: Dump the generated code References: <20071002141125.GC16772@networkno.de> <20071002154918.GA11312@linux-mips.org> In-Reply-To: <20071002154918.GA11312@linux-mips.org> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 16822 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: vagabon.xyz@gmail.com Precedence: bulk X-list: linux-mips Ralf Baechle wrote: > I don't mind - it's just that I've never been a friend of leaving much > debugging code or features around. 99% of the time it is just make the > code harder to read and maintain. > Yeah this kind of code is really hard to follow and therefore hard to maintain I guess. I'm wondering if we couldn't try to implement such code generator by using a tools/scripts during the build process. This tool could emit the assembler code during the early phase of the build into an assembler file and then it could compiled like any other one. I see a 3 main benefits: - It would simplify a lot the kernel code. - Decrease the size of the kernel - Easy to read the generated disassembly One issue to deal with is that some instructions need to be emitted according to the type of the cpu which can only be determined at run time. In this case we could leave some rooms into the generated code for additional instructions which could be filled/patched during the boot time by using a 'patch table'. If the cpu doesn't need to patch the generated code then the useless space would be discarded when installing the handler in its final place. Just a thought but I'm probably missing something. Franck From ed.stafford@gmail.com Wed Oct 3 14:04:32 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 03 Oct 2007 14:04:41 +0100 (BST) Received: from el-out-1112.google.com ([209.85.162.182]:51629 "EHLO el-out-1112.google.com") by ftp.linux-mips.org with ESMTP id S20023983AbXJCNEc (ORCPT ); Wed, 3 Oct 2007 14:04:32 +0100 Received: by el-out-1112.google.com with SMTP id n30so997981elf for ; Wed, 03 Oct 2007 06:03:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=Vog8NQcvnqtL55mvMYvpNDHLvWw0uO8Z27PGwORJvR8=; b=RoiYGxZuWVtKka+QbGw+rD/LRDymQsjpdXstBtPhl0ZQlu6edgCabyFRyiz5r6LFCoHyXlCM/xf8kPn8r8IDVH6bVar+8LGz1g7hRviTwvr9RPPGgMV0QpoV6rMiam8HQUs5fFMuje7rXAEj4w4cCxO+Hl8z6HnHZAAzmW9E7eY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=di/Kk0iKARlmAUcONoKxin59v6OMjOOn/bk8cS9VNrlk5DGt4SEZCYEhmhx8a8kfj3vOEcp7iKUDB+zecPH0b6hLQ1gzzXZlGz1c8+OQE2mc2mSPJpPj1HsH2JU3a3wViuHO5o/oDNTyuX5rckqVVCtBQy2i4vHMjRMeldESFBs= Received: by 10.142.111.14 with SMTP id j14mr664890wfc.1191416215487; Wed, 03 Oct 2007 05:56:55 -0700 (PDT) Received: by 10.141.129.12 with HTTP; Wed, 3 Oct 2007 05:56:55 -0700 (PDT) Message-ID: <41370a610710030556k5435b547sfc0e8210fe3966a5@mail.gmail.com> Date: Wed, 3 Oct 2007 07:56:55 -0500 From: "Ed Stafford" To: Kumba Subject: Re: What is the current state of the Octane/IP30 support? Cc: linux-mips@linux-mips.org In-Reply-To: <47033156.7090703@gentoo.org> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <41370a610710021341g749742dejec06b3a38477fd47@mail.gmail.com> <47033156.7090703@gentoo.org> Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 16823 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: ed.stafford@gmail.com Precedence: bulk X-list: linux-mips On 10/3/07, Kumba wrote: > Right now, Gentoo does have the best support for them (mine is running > 2.6.23-rc5 about 3.5ft from me as I type). But I do believe the debian guys > have been working on a debian install image for them too (tbm/ths, am I right on > this?) > > For the most part, Impact-based systems run great. You get X, unaccelerated, no > 3D, and a framebuffer. VPro, framebuffer, but no X. USB kinda weorks if you > have a PCI-Card Cage and a OHCI chipsets (UHCI is dead last I checked), and I > think EHCI works fine. Haven't tried much else beyond those PCI devices. I had wondered about being able to use any PCI card in that cage.. I'll have to give that a shot. > A lot of the other XIO Boards, outside of the Impact or Vpro boards, are wholly > untested, and likely won't work at all. Nor do I think dual head will work if > you have a second Impact card kicking around. > > For gentoo, we have an "RC6" livecd. I've played with building an RC7 several > times, but that got sidetracked about 2-3 months ago. I hope to resume work on > it soon. You can find that and the current netboots on your local gentoo > mirror, in the experimental/mips sub-folders. > > Further gentoo questions regarding this system should be directed to the > gentoo-mips ML; linux-mips here is more for distro-agnostic development. > > Have fun! (and what Proc, btw?) Single 195MHz. I've been looking at a dual-360MHz, but it's tough to win those auctions! Ed From ths@networkno.de Wed Oct 3 14:12:06 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 03 Oct 2007 14:12:15 +0100 (BST) Received: from mail.bawue.net ([193.7.176.63]:8881 "EHLO mail.bawue.net") by ftp.linux-mips.org with ESMTP id S20024026AbXJCNMG (ORCPT ); Wed, 3 Oct 2007 14:12:06 +0100 Received: from lagash (intrt.mips-uk.com [194.74.144.130]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by mail.bawue.net (Postfix) with ESMTP id 47CE3E0154; Wed, 3 Oct 2007 15:12:12 +0200 (CEST) Received: from ths by lagash with local (Exim 4.67) (envelope-from ) id 1Id418-000581-Hk; Wed, 03 Oct 2007 14:11:58 +0100 Date: Wed, 3 Oct 2007 14:11:58 +0100 From: Thiemo Seufer To: Franck Bui-Huu Cc: Ralf Baechle , "Maciej W. Rozycki" , linux-mips@linux-mips.org Subject: Re: [PATCH] mm/pg-r4k.c: Dump the generated code Message-ID: <20071003131158.GL16772@networkno.de> References: <20071002141125.GC16772@networkno.de> <20071002154918.GA11312@linux-mips.org> <47038874.9050704@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <47038874.9050704@gmail.com> User-Agent: Mutt/1.5.16 (2007-06-11) Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 16824 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: ths@networkno.de Precedence: bulk X-list: linux-mips Franck Bui-Huu wrote: > Ralf Baechle wrote: > > I don't mind - it's just that I've never been a friend of leaving much > > debugging code or features around. 99% of the time it is just make the > > code harder to read and maintain. > > > > Yeah this kind of code is really hard to follow and therefore hard to > maintain I guess. > > I'm wondering if we couldn't try to implement such code generator by > using a tools/scripts during the build process. > > This tool could emit > the assembler code during the early phase of the build into an > assembler file and then it could compiled like any other one. I see a > 3 main benefits: > > - It would simplify a lot the kernel code. > - Decrease the size of the kernel > - Easy to read the generated disassembly > > One issue to deal with is that some instructions need to be emitted > according to the type of the cpu which can only be determined at run > time. In this case we could leave some rooms into the generated code > for additional instructions which could be filled/patched during the > boot time by using a 'patch table'. If the cpu doesn't need to patch > the generated code then the useless space would be discarded when > installing the handler in its final place. Then you have the worst of both approaches: The nicely readable disassembly will change under you feet, and you still need relocation annotations etc. for CPU-specific fixups. The end-result is likely more complicated and opaque than what we have now. Thiemo From ralf@linux-mips.org Wed Oct 3 14:42:00 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 03 Oct 2007 14:42:02 +0100 (BST) Received: from localhost.localdomain ([127.0.0.1]:23981 "EHLO dl5rb.ham-radio-op.net") by ftp.linux-mips.org with ESMTP id S20021491AbXJCNmA (ORCPT ); Wed, 3 Oct 2007 14:42:00 +0100 Received: from denk.linux-mips.net (denk.linux-mips.net [127.0.0.1]) by dl5rb.ham-radio-op.net (8.14.1/8.13.8) with ESMTP id l93DfxVY028851; Wed, 3 Oct 2007 14:41:59 +0100 Received: (from ralf@localhost) by denk.linux-mips.net (8.14.1/8.14.1/Submit) id l93DfwY7028850; Wed, 3 Oct 2007 14:41:58 +0100 Date: Wed, 3 Oct 2007 14:41:58 +0100 From: Ralf Baechle To: Franck Bui-Huu Cc: Thiemo Seufer , "Maciej W. Rozycki" , linux-mips@linux-mips.org Subject: Re: [PATCH] mm/pg-r4k.c: Dump the generated code Message-ID: <20071003134158.GA28742@linux-mips.org> References: <20071002141125.GC16772@networkno.de> <20071002154918.GA11312@linux-mips.org> <47038874.9050704@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <47038874.9050704@gmail.com> User-Agent: Mutt/1.5.14 (2007-02-12) Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 16825 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: ralf@linux-mips.org Precedence: bulk X-list: linux-mips On Wed, Oct 03, 2007 at 02:17:56PM +0200, Franck Bui-Huu wrote: > Ralf Baechle wrote: > > I don't mind - it's just that I've never been a friend of leaving much > > debugging code or features around. 99% of the time it is just make the > > code harder to read and maintain. > > > > Yeah this kind of code is really hard to follow and therefore hard to > maintain I guess. > > I'm wondering if we couldn't try to implement such code generator by > using a tools/scripts during the build process. This tool could emit > the assembler code during the early phase of the build into an > assembler file and then it could compiled like any other one. I see a > 3 main benefits: > > - It would simplify a lot the kernel code. > - Decrease the size of the kernel > - Easy to read the generated disassembly > > One issue to deal with is that some instructions need to be emitted > according to the type of the cpu which can only be determined at run > time. In this case we could leave some rooms into the generated code > for additional instructions which could be filled/patched during the > boot time by using a 'patch table'. If the cpu doesn't need to patch > the generated code then the useless space would be discarded when > installing the handler in its final place. > > Just a thought but I'm probably missing something. We went for the runtime generation because this is about the only sane way we can get support for the widest range of cores yet not compromise on performance. Maintaining the previous generation of that code which was like a dozen variants of page clearing, copying and TLB exception handlers was definately more tedious than this. Ralf From macro@linux-mips.org Wed Oct 3 14:51:17 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 03 Oct 2007 14:51:25 +0100 (BST) Received: from cerber.ds.pg.gda.pl ([153.19.208.18]:25504 "EHLO cerber.ds.pg.gda.pl") by ftp.linux-mips.org with ESMTP id S20021528AbXJCNvR (ORCPT ); Wed, 3 Oct 2007 14:51:17 +0100 Received: from localhost (unknown [127.0.0.17]) by cerber.ds.pg.gda.pl (Postfix) with ESMTP id DB734400A8; Wed, 3 Oct 2007 15:51:16 +0200 (CEST) X-Virus-Scanned: amavisd-new at cerber.ds.pg.gda.pl Received: from cerber.ds.pg.gda.pl ([153.19.208.18]) by localhost (cerber.ds.pg.gda.pl [153.19.208.18]) (amavisd-new, port 10024) with ESMTP id geuztPUpQRF2; Wed, 3 Oct 2007 15:51:10 +0200 (CEST) Received: from piorun.ds.pg.gda.pl (piorun.ds.pg.gda.pl [153.19.208.8]) by cerber.ds.pg.gda.pl (Postfix) with ESMTP id 9DF9B400D8; Wed, 3 Oct 2007 15:51:10 +0200 (CEST) Received: from blysk.ds.pg.gda.pl (macro@blysk.ds.pg.gda.pl [153.19.208.6]) by piorun.ds.pg.gda.pl (8.13.8/8.13.8) with ESMTP id l93DpECn029224; Wed, 3 Oct 2007 15:51:14 +0200 Date: Wed, 3 Oct 2007 14:51:10 +0100 (BST) From: "Maciej W. Rozycki" To: Thiemo Seufer cc: Franck Bui-Huu , Ralf Baechle , linux-mips@linux-mips.org Subject: Re: [PATCH] mm/pg-r4k.c: Dump the generated code In-Reply-To: <20071003131158.GL16772@networkno.de> Message-ID: References: <20071002141125.GC16772@networkno.de> <20071002154918.GA11312@linux-mips.org> <47038874.9050704@gmail.com> <20071003131158.GL16772@networkno.de> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: ClamAV 0.91.2/4461/Wed Oct 3 10:50:48 2007 on piorun.ds.pg.gda.pl X-Virus-Status: Clean Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 16826 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: macro@linux-mips.org Precedence: bulk X-list: linux-mips On Wed, 3 Oct 2007, Thiemo Seufer wrote: > Then you have the worst of both approaches: The nicely readable > disassembly will change under you feet, and you still need relocation > annotations etc. for CPU-specific fixups. The end-result is likely > more complicated and opaque than what we have now. Well, to be honest what we have now is very good. One trouble at the beginning, just after we switched from the old approach, was limited ability to get at what really is generated and therefore tough time to determine what was going on if something was wrong. With these debug dumps in place it is gone now too. There is one limitation though -- unlike with ready-writted assembly to debug this code you typically need to have a specific system that shows a problem. If you do not have one chances are you can miss a condition somewhere and therefore the problem. Once you have the right piece of hardware, debugging is easy -- it took me half of a day if not less to sort out all the issues with the R3000 TLB handlers that we had once I got my hands on a suitable system. And as with everything, there is still room for improvement though. For example I have noticed for the 64-bit TLB refill handler the path for vmalloc()ed pages may fit entirely in half of the space available. Which means whatever is emitted after "eret" may be shifted to the TLB refill space at 0x80000000 saving the branch from the XTLB space at its end. That is probably doable with reasonably little effort given that we have support for "relocations". Maciej From macro@linux-mips.org Wed Oct 3 14:55:20 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 03 Oct 2007 14:55:28 +0100 (BST) Received: from cerber.ds.pg.gda.pl ([153.19.208.18]:45246 "EHLO cerber.ds.pg.gda.pl") by ftp.linux-mips.org with ESMTP id S20021561AbXJCNzT (ORCPT ); Wed, 3 Oct 2007 14:55:19 +0100 Received: from localhost (unknown [127.0.0.17]) by cerber.ds.pg.gda.pl (Postfix) with ESMTP id 3DF3B4012E; Wed, 3 Oct 2007 15:55:20 +0200 (CEST) X-Virus-Scanned: amavisd-new at cerber.ds.pg.gda.pl Received: from cerber.ds.pg.gda.pl ([153.19.208.18]) by localhost (cerber.ds.pg.gda.pl [153.19.208.18]) (amavisd-new, port 10024) with ESMTP id XRvdaZQS4jvP; Wed, 3 Oct 2007 15:55:14 +0200 (CEST) Received: from piorun.ds.pg.gda.pl (piorun.ds.pg.gda.pl [153.19.208.8]) by cerber.ds.pg.gda.pl (Postfix) with ESMTP id 9AB48400FE; Wed, 3 Oct 2007 15:55:14 +0200 (CEST) Received: from blysk.ds.pg.gda.pl (macro@blysk.ds.pg.gda.pl [153.19.208.6]) by piorun.ds.pg.gda.pl (8.13.8/8.13.8) with ESMTP id l93DtFKg029802; Wed, 3 Oct 2007 15:55:16 +0200 Date: Wed, 3 Oct 2007 14:55:11 +0100 (BST) From: "Maciej W. Rozycki" To: Alessandro Zummo cc: rtc-linux@googlegroups.com, Atsushi Nemoto , rongkai.zhan@windriver.com, i2c@lm-sensors.org, linux-mips@linux-mips.org, ralf@linux-mips.org, a.zummo@towertech.it Subject: Re: [rtc-linux] Re: [PATCH 4/4] MIPS: Remove the legacy RTC codes of MIPS sibyte boards In-Reply-To: <20071002151415.672d0a1e@i1501.lan.towertech.it> Message-ID: References: <46FF7283.7050702@windriver.com> <20071002.003020.21363605.anemo@mba.ocn.ne.jp> <20071002151415.672d0a1e@i1501.lan.towertech.it> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: ClamAV 0.91.2/4461/Wed Oct 3 10:50:48 2007 on piorun.ds.pg.gda.pl X-Virus-Status: Clean Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 16827 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: macro@linux-mips.org Precedence: bulk X-list: linux-mips On Tue, 2 Oct 2007, Alessandro Zummo wrote: > CONFIG_RTC_HCTOSYS defaults to YES, it should be enough...? Well, yes, probably... Maciej From hjl@lucon.org Wed Oct 3 18:12:27 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 03 Oct 2007 18:12:37 +0100 (BST) Received: from alnrmhc14.comcast.net ([206.18.177.54]:37879 "EHLO alnrmhc14.comcast.net") by ftp.linux-mips.org with ESMTP id S20025118AbXJCRMU (ORCPT ); Wed, 3 Oct 2007 18:12:20 +0100 Received: from lucon.org ([24.6.230.138]) by comcast.net (alnrmhc14) with ESMTP id <20071003171134b1400op7hce>; Wed, 3 Oct 2007 17:11:35 +0000 Received: by lucon.org (Postfix, from userid 500) id 6ED01F82AF; Wed, 3 Oct 2007 10:11:34 -0700 (PDT) Date: Wed, 3 Oct 2007 10:11:34 -0700 From: "H.J. Lu" To: linux-gcc@vger.kernel.org, gcc@gcc.gnu.org, GNU C Library Cc: Mat Hostetter , Warner Losh , linux-mips@linux-mips.org, Ralf Baechle , linux-vax@pergamentum.com Subject: The Linux binutils 2.18.50.0.2 is released Message-ID: <20071003171134.GA21069@lucon.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.14 (2007-02-12) Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 16828 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: hjl@lucon.org Precedence: bulk X-list: linux-mips This is the beta release of binutils 2.18.50.0.2 for Linux, which is based on binutils 2007 1001 in CVS on sourceware.org plus various changes. It is purely for Linux. All relevant patches in patches have been applied to the source tree. You can take a look at patches/README to see what have been applied and in what order they have been applied. Starting from the 2.17.50.0.4 release, the default output section LMA (load memory address) has changed for allocatable sections from being equal to VMA (virtual memory address), to keeping the difference between LMA and VMA the same as the previous output section in the same region. For .data.init_task : { *(.data.init_task) } LMA of .data.init_task section is equal to its VMA with the old linker. With the new linker, it depends on the previous output section. You can use .data.init_task : AT (ADDR(.data.init_task)) { *(.data.init_task) } to ensure that LMA of .data.init_task section is always equal to its VMA. The linker script in the older 2.6 x86-64 kernel depends on the old behavior. You can add AT (ADDR(section)) to force LMA of .data.init_task section equal to its VMA. It will work with both old and new linkers. The x86-64 kernel linker script in kernel 2.6.13 and above is OK. The new x86_64 assembler no longer accepts monitor %eax,%ecx,%edx You should use monitor %rax,%ecx,%edx or monitor which works with both old and new x86_64 assemblers. They should generate the same opcode. The new i386/x86_64 assemblers no longer accept instructions for moving between a segment register and a 32bit memory location, i.e., movl (%eax),%ds movl %ds,(%eax) To generate instructions for moving between a segment register and a 16bit memory location without the 16bit operand size prefix, 0x66, mov (%eax),%ds mov %ds,(%eax) should be used. It will work with both new and old assemblers. The assembler starting from 2.16.90.0.1 will also support movw (%eax),%ds movw %ds,(%eax) without the 0x66 prefix. Patches for 2.4 and 2.6 Linux kernels are available at http://www.kernel.org/pub/linux/devel/binutils/linux-2.4-seg-4.patch http://www.kernel.org/pub/linux/devel/binutils/linux-2.6-seg-5.patch The ia64 assembler is now defaulted to tune for Itanium 2 processors. To build a kernel for Itanium 1 processors, you will need to add ifeq ($(CONFIG_ITANIUM),y) CFLAGS += -Wa,-mtune=itanium1 AFLAGS += -Wa,-mtune=itanium1 endif to arch/ia64/Makefile in your kernel source tree. Please report any bugs related to binutils 2.18.50.0.2 to hjl@lucon.org and http://www.sourceware.org/bugzilla/ Changes from binutils 2.18.50.0.1: 1. Update from binutils 2007 1001. 2. Speed up hash table lookup in linker. 3. Add -c/--archive-index option to readelf. 4. Fix an readelf crash. PR 5011. 5. Fix an x86 assembler Intel mode bug. PR 5080. 6. Add EIP support in x86 assembler. 7. Add fake index registers, EIZ/RIZ, to x86 assembler/disassembler. 8. Improve x86 assembler error message for truncated values. PR 5026. 9. Remove a COFF assertion in COFF assembler. PR 5035. 10. Add AMD SSE5 support to x86 assembler/disassembler. 11. Fix x86 assembler for extrq/insertq in Intel mode. 12. Fix x86 disassembler for invalid opcodes in 64bit. PR 5072. 13. Fix auto-import in PE-COFF linker. PR 4844. 14. Correct -z now in ELF linker. 15. Fix a --build-id linker crash. PR 5025. 16. Improved x86 assembler/disassembler infrastructure for new instruction support. 17. Fix various m68k bugs. 18. Fix various ppc bugs. 19. Fix various spu bugs. Changes from binutils 2.17.50.0.18: 1. Update from binutils 2007 0908. 2. Fix an ELF linker for SHT_NOBITS sections. PR 2864/5006. 3. Improve TLS transition check in i386 and x86-64 linkers. 4. Fix a GD->LE/LD->LE TLS transition bug in i386 and x86-64 linkers. PR 4918. 5. Update ELF linker to dump segment map when a section can't be allocated in segment. PR 4909. 6. Clean up x86 disassembler to remove fixups and make it more table driven. 7. Fix x86 disassember for SSE instructions in Intel mode. PR 4834. 8. Properly handle bss segments in ELF linker. 9. Add --string-dump to readelf. 10. Fix objcopy -R .debug_* --only-keep-debug regression. PR 4888. 11. Change x86 assembler to follow SVME specification. 12. Fix x86 assembler for cmpxchg8b, pextrb and pinsrb in Intel mode. 13. Update x86 assembler to better handle expressions with @GOT suffix. PR 4079. 14. Properly handle section alignment >= 128 byte for PECOFF. 15. Fix an ELF linker --build-id option crash. PR 4923. 16. Fix binutils build on HP-UX. PR 4875. 17. Fix a regression of the a.out linker -N option. PR 4515. 18. Update x86 disassembler for invlpg, fxsave, fxrstor, ldmxcsr and stmxcsr in Intel mode. 19. Fix x86 assembler for SSE4 instructions in Intel mode. 20. Fix various arm bugs. 21. Fix various mips bugs. 22. Fix various ppc bugs. 23. Fix various spu bugs. 24. Fix various xtensa bugs. Changes from binutils 2.17.50.0.17: 1. Update from binutils 2007 0731. 2. Switching from GPLv2 to GPLv3. 3. Add a new ELF linker option, --build-id, to generate a unique per-binary identifier embedded in a note section. 4. Remove COFF/x86-64 from PE-COFF/x86-64. 5. Fix a "nm -l" crash on DWARF info. PR 4797. 6. Match symbol type when creating symbol aliase in ELF shared library. 7. Fix addr2line on relocatable linux kernel. PR 4756. 8. Change disassembler to print addend as signed. 9. Support section alignment from 128 to 8192 bytes for PE-COFF. 10. Add attribute section to ELF linker. 11. Fix ELF linker to meet gABI alignment requirement. PR 4701. 12. Add support for reading in debug information via a .gnu_debuglink section. 13. Fix string merge for ia64 linker. PR 4590. 14. Add --common to size to display total size for *COM* syms. 15. Fix "strip --strip-unneeded" on relocatable files. PR 4716. 16. Fix "objcopy/strip --only-keep-debug" for SHT_NOTE sections. 17. Fix objdump -S with unit-at-a-time. 18. Properly handle "-shared -pie" in linker. PR 4409. 19. Fix x86 disassembler in Intel mode for various SIMD instruction. PRs 4667/4834. 20. Update x86-64 assembler to long nop sequence by default. 21. Fix --32 for x86-64 mingw assembler. 22. Fix a memory corruption in assembler. PR 4722. 22. Properly support 64bit PE-COFF on hosts where long isn't 64bit. 23. Add #line in generated linker source files. 24. Fix linker crash on SIZEOF. PR 4782. 27. Add CR16 support. 28. Add windmc tool for Windows. 29. Generate x86 instruction/register definitions from ascii tables. 30. Fix strip for Solaris. PR 4712. 31. Fix various mips bugs. 32. Fix various ppc bugs. 33. Fix various spu bugs. 34. Fix various xtensa bugs. Changes from binutils 2.17.50.0.16: 1. Update from binutils 2007 0615. 2. Preserve section alignment for copy relocation. PR 4504. 3. Properly fix regression with objcopy --only-keep-debug. PR 4479. 4. Fix ELF eh frame handling. PR 4497. 5. Fix ia64 string merge. PR 4590. 5. Don't use PE target on EFI files nor EFI target on PE files. 6. Speed up linker with many input files. 7. Support cross compiling windres. PR 2737. 8. Fix various windres bugs. 9. Fix various arms bugs. 10. Fix various m68k bugs. 11. Fix various mips bugs. 12. Fix various ppc bugs. 13. Fix various sparc bugs. 14. Fix various spu bugs. 15. Fix various xtensa bugs. Changes from binutils 2.17.50.0.15: 1. Update from binutils 2007 0511. 2. Fix objcopy --only-keep-debug and linker multiple BSS sections handling. PR 4479. 3. Fix "readelf -s -D" for gnu hash. PR 4476. 4. Fix ia64 linker crash with --unresolved-symbols=ignore-all. PR 4409. 5. Improve crc32 support in x86 assembler/dissassembler. 6. Improve displacement handling in x86 dissassembler. PR 4430. 7. Correct PC relative displacement handling in x86-64 dissassembler for Intel mode. PR 4429. 8. Fix various PPC bugs. 9. Fix various SPU bugs. 10. Fix various ARM bugs. 11. Fix various m68k bugs. 12. Fix various xtensa bugs. Changes from binutils 2.17.50.0.14: 1. Update from binutils 2007 0418. 2. Support Intel SSE4 instructions. 3. Fix linker --fatal-warnings for --warn-shared-textrel. PR 4304. 4. Improve linker error message to identify linker script error location. PR 4090. 5. Fix objcopy to allow removing all sections. PR 4348. 6. Don't print addresses of 32-bit targets as 64-bit values on 64bit host. PR 4292. 7. Improve checking for corrupted input files. PR 4110. 8. Improve alpha linker performance. 9. Add a new linker option, -l:foo. 10. Fix a PPC linker bug. PR 4267. 11. Misc vxworks bug fixes. 12. Misc SH bug fixes. 13. Misc SPU bug fixes. 14. Misc ARM bug fixes. 15. Misc MIPS bug fixes. 16. Misc xtensa bug fixes. Changes from binutils 2.17.50.0.13: 1. Update from binutils 2007 0322. 2. Fix >16byte nop padding regression in x86 assembler. 3. Fix x86-64 disassembler for xchg. PR 4218. 4. Optimize opcode for x86-64 xchg. 5. Allow register operand with x86 nop. 6. Properly handle holes between sections for PE-COFF. PR 4210. 7. Print more PE-COFF info for objdump -p. 8. Report missing matching LO16 relocation for HI16 relocation in mips linker. 9. Use PC-relative relocation for Win64. 10. Fix strip for Solaris. PR 3535. 11. Fix a C++ demangler crash. 12. Some m32c update. 13. Fix misc ARM bugs. Changes from binutils 2.17.50.0.12: 1. Update from binutils 2007 0315. 2. Add EFI/x86-64 support. 3. Fix ELF linker for relocation against STN_UNDEF. PR 3958. 4. Fix ELF linker for SHT_NOBITS section whose VMA > page size. PR 4144. 5. Make assembler and disassembler consistent for "test %eax,%ebx". PR 4027. 6. Fix i386 32bit address wraparound. PR 3966. 7. Allow Linux/i386 linker to read FreeBSD/i386 object files. 8. Fix ELF linker crash upon use of .gnu.warning. sections. PR 3953. 9. Fix ELF linker to issue an error on bad section in segment. PR 4007. 10. Support enabling both x86_64-mingw32 and i386-mingw32. PR 3945. 11. Fix assembler to stabilize .gcc_except_table relaxation. PR 4029. 12. Fix a MIPS linker crash. PR 3852. 13. Fix readelf for h8300-elf. PR 3800. 14. Fix strip for Solaris. PR 3535. 15. Misc xtensa bug fixes. 16. Misc PPC bug fixes. 17. Misc SPU bug fixes. 18. Add support for Toshiba MeP. Changes from binutils 2.17.50.0.11: 1. Update from binutils 2007 0128. 2. Remove duplicate code in x86 assembler. 3. Fix 32bit and 64bit HPPA/ELF. Changes from binutils 2.17.50.0.10: 1. Update from binutils 2007 0125. 2. Support environment variables, LD_SYMBOLIC for -Bsymbolic and LD_SYMBOLIC_FUNCTIONS for -Bsymbolic-functions. 3. Build binutils rpm with LD_SYMBOLIC_FUNCTIONS=1 and reduce PLT relocations in libfd.so by 84%. 4. Enable sharable sections only for ia32, x86-64 and ia64. 5. Properly handle PT_GNU_RELRO segment for objcopy. Changes from binutils 2.17.50.0.9: 1. Update from binutils 2007 0122. 2. Implement sharable section proposal for ia32, x86-64 and ia64: http://groups-beta.google.com/group/generic-abi 3. Implement linker enhancement, -Bsymbolic-functions, --dynamic-list-cpp-new and --dynamic-list-data. PR 3831. 4. Implement new linker switch, --default-script=FILE/-dT FILE. 5. Check EI_OSABI when reading ELF files. PR 3826. 6. Fix x86 assembler error message. PR 3830. 7. Fix a bug in ld testsuite. PR 1283. 8. Don't include archive64.o for 32bit target. PR 3631. 9. Support -z max-page-size and -z common-page-size in user provided linker script. 10. Fix 32bit library support for GNU/kFreeBSD/x86-64. PR 3843. 11. Fix some bugs in Score assembler. PR 3871. 12. Fix various bugs in ARM assembler. PR 3707 and more. 13. Add Fido support. Changes from binutils 2.17.50.0.8: 1. Update from binutils 2007 0103. 2. Fix --wrap linker bug. 3. Improve handling ELF binaries generated by foreign ELF linkers. 4. Various ELF M68K bug fixes. 5. Score bug fixes. 6. Don't read past end of archive elements. PR 3704. 7. Improve .eh_frame_hdr section handling. 8. Fix symbol visibility with comdat/linkonce sections in ELF linker. PR 3666. 9. Fix 4 operand instruction handling in x86 assembler. 10. Properly check the 4th operand in x86 assembler. PR 3712. 11. Fix .cfi_endproc handling in assembler. PR 3607. 12. Various ARM bug fixes. 13. Various PE linker fixes. 14. Improve x86 dissassembler for cmpxchg16b. Changes from binutils 2.17.50.0.7: 1. Update from binutils 2006 1201. 2. Fix "objcopy --only-keep-debug" crash. PR 3609. 3. Fix various ARM ELF bugs. 4. Fix various xtensa bugs. 5. Update x86 disassembler. Changes from binutils 2.17.50.0.6: 1. Update from binutils 2006 1127. 2. Properly set ELF output segment address when the first section in input segment is removed. 3. Better merging of CIEs in linker .eh_frame optimizations. 4. Support .cfi_personality and .cfi_lsda assembler directives. 5. Fix an ARM linker crash. PR 3532. 6. Fix various PPC64 ELF bugs. 7. Mark discarded debug info more thoroughly in linker output. 8. Fix various MIPS ELF bugs. 9. Fix readelf to display program interpreter path > 64 chars. PR 3384. 10. Add support for PowerPC SPU. 11. Properly handle cloned symbols used in relocations in assembler. PR 3469. 12. Update opcode for POPCNT in amdfam10 architecture. Changes from binutils 2.17.50.0.5: 1. Update from binutils 2006 1020. 2. Don't make debug symbol dynamic. PR 3290. 3. Don't page align empty SHF_ALLOC sections, which leads to very large executables. PR 3314. 4. Use a different section index for section relative symbols against removed empty sections. 5. Fix a few ELF EH frame handling bugs. 6. Don't ignore relocation overflow on branches to undefweaks for x86-64. PR 3283. 7. Rename MNI to SSSE3. 8. Properly append symbol list for --dynamic-list. lists. 9. Various ARM ELF fixes. 10. Correct 64bit library search path for Linux/x86 linker with 64bit support. 11. Fix ELF linker to copy OS/PROC specific flags from input section to output section. 12. Fix DW_FORM_ref_addr handling in linker dwarf reader. PR 3191. 13. Fix ELF indirect symbol handling. PR 3351. 14. Fix PT_GNU_RELRO segment handling for SHF_TLS sections. Don't add PT_GNU_RELRO segment when there are no relro sections. PR 3281. 15. Various MIPS ELF fixes. 16. Various Sparc ELF fixes. 17. Various Xtensa ELF fixes. Changes from binutils 2.17.50.0.4: 1. Update from binutils 2006 0927. 2. Fix linker regressions of section address and section relative symbol with empty output section. PR 3223/3267. 3. Fix "strings -T". PR 3257. 4. Fix "objcopy --only-keep-debug". PR 3262. 5. Add Intell iwmmxt2 support. 6. Fix an x86 disassembler bug. PR 3100. Changes from binutils 2.17.50.0.3: 1. Update from binutils 2006 0924. 2. Speed up linker on .o files with debug info on linkonce sections. PR 3111. 3. Added x86-64 PE support. 4. Fix objcopy/strip on .o files with section groups. PR 3181. 5. Fix "ld --hash-style=gnu" crash with gcc 3.4.6. PR 3197. 6. Fix "strip --strip-debug" on .o files generated with "gcc -feliminate-dwarf2-dups". PR 3186. 7. Fix "ld -r" on .o files generated with "gcc -feliminate-dwarf2-dups". PR 3249. 8. Add --dynamic-list to linker to make global symbols dynamic. 9. Fix magic number for EFI ia64. PR 3171. 10. Remove PT_NULL segment for "ld -z relro". PR 3015. 11. Make objcopy to perserve the file formats in archive elements. PR 3110. 12. Optimize x86-64 assembler and fix disassembler for "add32 mov xx,$eax". PR 3235. 13. Improve linker diagnostics. PR 3107. 14. Fix "ld --sort-section name". PR 3009. 15. Updated an x86 disassembler bug. PR 3000. 16. Various updates for PPC, ARM, MIPS, SH, Xtensa. 17. Added Score support. Changes from binutils 2.17.50.0.2: 1. Update from binutils 2006 0715. 2. Add --hash-style to ELF linker with DT_GNU_HASH and SHT_GNU_HASH. 3. Fix a visibility bug in ELF linker (PR 2884). 4. Properly fix the i386 TLS linker bug (PR 2513). 5. Add assembler and dissassembler support for Pentium Pro nops. 6. Optimize x86 nops for Pentium Pro and above. 7. Add -march=/-mtune= to x86 assembler. 8. Fix an ELF linker with TLS common symbols. 9. Improve program header allocation in ELF linker. 10. Improve MIPS, M68K and ARM support. 11. Fix an ELF linker crash when reporting alignment change (PR 2735). 12. Remove unused ELF section symbols (PR 2723). 13. Add --localize-hidden to objcopy. 14. Add AMD SSE4a and ABM new instruction support. 15. Properly handle illegal x86 instructions in group 11 (PR 2829). 16. Add "-z max-page-size=" and "-z common-page-size=" to ELF linker. 17. Fix objcopy for .tbss sections. Changes from binutils 2.17.50.0.1: 1. Update from binutils 2006 0526. 2. Change the x86-64 maximum page size to 2MB. 3. Support --enable-targets=all for 64bit target and host (PR 1485). 4. Properly update CIE/FDE length and align section for .eh_frame section (PR 2655/2657). 5. Properly handle removed ELF section symbols. 6. Fix an ELF linker regression introduced on 2006-04-21. 7. Fix an segfault in PPC ELF linker (PR 2658). 8. Speed up the ELF linker by caching the result of kept section check. 9. Properly create stabs section for ELF. 10. Preserve ELF program header when copying ELF files. 11. Properly handle ELF SHN_LOPROC/SHN_HIOS when checking section index (PR 2607). 12. Misc mips updates. 13. Misc arm updates. 14. Misc xtensa updates. 15. Fix an alpha assembler warning (PR 2598). 16. Fix assembler buffer overflow. 17. Properly disassemble sgdt/sidt for x86-64. Changes from binutils 2.16.91.0.7: 1. Update from binutils 2006 0427. 2. Fix an objcopy regression (PR 2593). 3. Reduce ar memory usage (PR 2467). 4. Allow application specific ELF sections (PR 2537). 5. Fix an i386 TLS linker bug (PR 2513). 6. Speed up ia64 linker by 1300X in some cases (PR 2442). 7. Check illegal immediate register operand in i386 assembler (PR 2533). 8. Fix a strings bug (PR 2584). 9. Better handle corrupted ELF files (PR 2257). 10. Fix a MIPS linker bug (PR 2267). Changes from binutils 2.16.91.0.6: 1. Update from binutils 2006 0317. 2. Support Intel Merom New Instructions in assembler/disassembler. 3. Support Intel new instructions in Montecito. 4. Fix linker "--as-needed" (PR 2434). 5. Fix linker "-s" regression (PR 2462). 6. Fix REP prefix for string instructions in x86 disassembler (PR 2428). 7. Fix the weak undefined symbols in PIE (PR 2218). 8. Fix 2 DWARF reader bugs (PRs 2443, 2338). 9. Improve ELF linker error message (PR 2322). 10. Avoid abort with dynamic symbols in >64K sections (PR 2411). 11. Handle mismatched symbol types for executables (PR 2404). 12. Avoid a linker linkonce regression (PR 2342). Changes from binutils 2.16.91.0.5: 1. Update from binutils 2006 0212. 2. Correct Linux linker search order for DT_NEEDED entries (PR 2290). 3. Fix the x86-64 disassembler for control/debug register moves. 4. Properly handle ELF strip/objcopy with unmodified program header (PR 2258). 5. Improve ELF linker error handling when there are not enough room for program headers (PR 2322). 6. Properly handle weak undefined symbols in PIE (PR 2218). 7. Support new i386/x86-64 TLS relocations. 8. Fix addr2line for linux kernel (PR 2096). 9. Fix an assembler memory leak with --statistics. 10. Avoid an ia64 assembler regression (PR 2117). Changes from binutils 2.16.91.0.4: 1. Update from binutils 2005 1219. 2. Fix a MIPS linker regression (PR 1932). 3. Fix an objcopy bug for ia64 (PR 1991). 4. Fix a linker crash on bad input (PR 2008). 5. Fix 64bit monitor and mwait (PR 1874). Changes from binutils 2.16.91.0.3: 1. Update from binutils 2005 1111. 2. Fix ELF orphan section handling (PR 1467) 3. Fix ELF section attribute handleing (PR 1487). 4. Fix IA64 unwind info dump for relocatable files. (PR 1436). 5. Add DWARF info dump to objdump. 6. Fix SHF_LINK_ORDER handling (PR 1321). 7. Don't allow "ld --just-symbols" on DSO (PR 1263). 8. Fix a "ld -u" crash on TLS symbol (PR 1301). 9. Fix an IA64 linker crash (PR 1247). 10. Fix a MIPS linker bug (PR 1150). 11. Fix a M68K linker bug (PR 1775). 12. Fix an ELF symbol versioning linker bug (PR 1540). 13. Improve linker error handling (PR 1208). 14. Add new SPARC processors to SunOS for objcopy (PR 1472). 15. Add "@file" to read options from a file. 16. Add assembler weakref support. Changes from binutils 2.16.91.0.2: 1. Update from binutils 2005 0821. 2. Support x86-64 medium model. 3. Fix "objdump -S --adjust-vma=xxx" (PR 1179). 4. Reduce R_IA64_NONE relocations from R_IA64_LDXMOV relaxation. 5. Fix x86 linker regression for dosemu. 6. Add "readelf -t/--section-details" to display section details. 7. Fix "as -al=file" regression (PR 1118). Changes from binutils 2.16.91.0.1: 1. Update from binutils 2005 0720. 2. Add Intel VMX support. 3. Add AMD SVME support. 4. Add x86-64 new relocations for medium model. 5. Fix a PIE regression (PR 975). 6. Fix an x86_64 signed 32bit displacement regression. 7. Fix PPC PLT (PR 1004). 8. Improve empty section removal. Changes from binutils 2.16.90.0.3: 1. Update from binutils 2005 0622. 2. Fix a linker versioning bug exposed by gcc 4 (PR 1022/1023/1025). 3. Optimize ia64 br->brl relaxation (PR 834). 4. Improve linker empty section removal. 5. Fix DWARF 2 line number reporting (PR 990). 6. Fix DWARF 2 line number reporting regression on assembly file (PR 1000). Changes from binutils 2.16.90.0.2: 1. Update from binutils 2005 0510. 2. Update ia64 assembler to support comdat group section generated by gcc 4 (PR 940). 3. Fix a linker crash on bad input (PR 939). 4. Fix a sh64 assembler regression (PR 936). 5. Support linker script on executable (PR 882). 6. Fix the linker -pie regression (PR 878). 7. Fix an x86_64 disassembler bug (PR 843). 8. Fix a PPC linker regression. 9. Misc speed up. Changes from binutils 2.16.90.0.1: 1. Update from binutils 2005 0429. 2. Fix an ELF linker regression (PR 815). 3. Fix an empty section removal related bug. 4. Fix an ia64 linker regression (PR 855). 5. Don't allow local symbol to be equated common/undefined symbols (PR 857). 6. Fix the ia64 linker to handle local dynamic symbol error reporting. 7. Make non-debugging reference to discarded section an error (PR 858). 8. Support Sparc/TLS. 9. Support rpm build with newer rpm. 10. Fix an alpha linker regression. 11. Fix the non-gcc build regression. Changes from binutils 2.15.94.0.2.2: 1. Update from binutils 2005 0408. 2. The i386/x86_64 assemblers no longer accept instructions for moving between a segment register and a 32bit memory location. 3. The x86_64 assembler now allows movq between a segment register and a 64bit general purpose register. 4. 20x Speed up linker for input files with >64K sections. 5. Properly report ia64 linker relaxation failures. 6. Support tuning ia64 assembler for Itanium 2 processors. 7. Linker will remove empty unused output sections. 8. Add -N to readelf to display full section names. 9. Fix the ia64 linker to support linkonce text sections without unwind sections. 10. More unwind directive checkings in the ia64 assembler. 11. Speed up linker with wildcard handling. 12. Fix readelf to properly dump .debug_ranges and .debug_loc sections. Changes from binutils 2.15.94.0.2: 1. Fix greater than 64K section support in linker. 2. Properly handle i386 and x86_64 protected symbols in linker. 3. Fix readelf for LEB128 on 64bit hosts. 4. Speed up readelf for section group process. 5. Include ia64 texinfo pages. 6. Change ia64 assembler to check hint.b for Montecito. 7. Improve relaxation failure report in ia64 linker. 8. Fix ia64 linker to allow relax backward branch in the same section. Changes from binutils 2.15.94.0.1: 1. Update from binutils 2004 1220. 2. Fix strip for TLS symbol references. Changes from binutils 2.15.92.0.2: 1. Update from binutils 2004 1121. 2. Put ia64 .ctors/.dtors sections next to small data section for Intel ia64 compiler. 3. Fix -Bdynamic/-Bstatic handling for linker script. 4. Provide more information on relocation overflow. 5. Add --sort-section to linker. 6. Support icc 8.1 unwind info in readelf. 7. Fix the infinite loop bug on bad input in the ia64 assembler. 8. Fix ia64 SECREL relocation in linker. 9. Fix a section group memory leak in readelf. Changes from binutils 2.15.91.0.2: 1. Update from binutils 2004 0927. 2. Work around a section header bug in Intel ia64 compiler. 3. Fix an unwind directive bug in the ia64 assembler. 4. Fix various PPC bugs. 5. Update ARM support. 6. Fix an x86-64 linker warning while building Linux kernel. Changes from binutils 2.15.91.0.1: 1. Update from binutils 2004 0727. 2. Fix the x86_64 linker to prevent non-PIC code in shared library. 3. Fix the ia64 linker to warn the relotable files which can't be relaxed. 4. Fix the comdat group support. Allow mix single-member comdat group with linkonce section. 5. Added --add-needed/--no-add-needed options to linker. 6. Fix the SHF_LINK_ORDER support. 7. Fix the ia64 assembler for multiple sections with the same name and SHT_IA_64_UNWIND sections. 8. Fix the ia64 assembler for merge section and relaxation. Changes from binutils 2.15.90.0.3: 1. Update from binutils 2004 0527. 2. Fix -x auto option in the ia64 assembler. 3. Add the AR check in the ia64 assembler. 4. Fix the section group support. 5. Add a new -z relro linker option. 6. Fix an exception section placement bug in linker. 7. Add .serialize.data and .serialize.instruction to the ia64 assembler. Changes from binutils 2.15.90.0.2: 1. Update from binutils 2004 0415. 2. Fix the linker for weak undefined symbol handling. 3. Fix the ELF/Sparc and ELF/Sparc64 linker for statically linking PIC code. Changes from binutils 2.15.90.0.1.1: 1. Update from binutils 2004 0412. 2. Add --as-needed/--no-as-needed to linker. 3. Fix -z defs in linker. 4. Always reserve the memory for ia64 dynamic linker. 5. Fix a race condition in ia64 lazy binding. Changes from binutils 2.15.90.0.1: 1. Fixed an ia64 assembler bug. 2. Install the assembler man page. Changes from binutils 2.14.90.0.8: 1. Update from binutils 2004 0303. 2. Fixed linker for undefined symbols with non-default visibility. 3. Sped up linker weakdef symbol handling. 4. Fixed mixing ELF32 and ELF64 object files in archive. 5. Added ia64 linker brl optimization. 6. Fixed ia64 linker to disallow invalid dynamic relocations. 7. Fixed DT_TEXTREL handling in ia64 linker. 8. Fixed alignment handling in ia64 assembler. 9. Improved ia64 assembler unwind table handling. Changes from binutils 2.14.90.0.7: 1. Update from binutils 2004 0114. 2. Fixed an ia64 assembler unwind table bug. 3. Better handle IPF linker relaxation overflow. 4. Fixed misc PPC bugs. Changes from binutils 2.14.90.0.6: 1. Update from binutils 2003 1029. 2. Allow type changes for undefined symbols. 3. Fix EH frame optimization. 4. Fix the check for undefined versioned symbol with wildcard. 5. Support generating code for Itanium. 6. Detect and warn bad symbol index. 7. Update IPF assemebler DV check. Changes from binutils 2.14.90.0.5: 1. Update from binutils 2003 0820. 2. No longer use section names for ELF section types nor flags. 3. Fix some ELF/IA64 linker bugs. 4. Fix some ELF/ppc bugs. 5. Add archive support to readelf. Changes from binutils 2.14.90.0.4.1: 1. Update from binutils 2003 0722. 2. Fix an ELF/mips linker bug. 3. Fix an ELF/hpppa linker bug. 4. Fix an ELF/ia64 assembler bug. 5. Fix a linkonce support with C++ debug. 6. A new working C++ demangler. 7. Various alpha, mips, ia64, ... bug fixes. 8. Support for the current gcc and glibc. Changes from binutils 2.14.90.0.4: 1. Fix an ia64 assembler hint@pause bug. 2. Support Intel Prescott New Instructions. Changes from binutils 2.14.90.0.3: 1. Work around the brain dead libtool. Changes from binutils 2.14.90.0.2: 1. Update from binutils 2003 0523. 2. Fix 2 ELF visibility bugs. 3. Fix ELF/ppc linker bugs. Changes from binutils 2.14.90.0.1: 1. Update from binutils 2003 0515. 2. Fix various ELF visibility bugs. 3. Fix some ia64 linker bugs. 4. Add more IAS compatibilities to ia64 assembler. Changes from binutils 2.13.90.0.20: 1. Update from binutils 2003 0505. 2. Fix various ELF visibility bugs. 3. Fix some ia64 linker bugs. 4. Fix some ia64 assembler bugs. 5. Add some IAS compatibilities to ia64 assembler. 6. Fix ELF common symbol alignment. 7. Fix ELF weak symbol handling. Changes from binutils 2.13.90.0.18: 1. Update from binutils 2003 0319. 2. Fix an ia64 linker brl relaxation bug. 3. Fix some ELF/ppc linker bugs. Changes from binutils 2.13.90.0.16: 1. Update from binutils 2003 0121. 2. Fix an ia64 gas bug. 3. Fix some TLS bugs. 4. Fix some ELF/ppc bugs. 5. Fix an ELF/m68k bug. 2. Include /usr/bin/c++filt. Changes from binutils 2.13.90.0.14: 1. Update from binutils 2002 1126. 2. Include /usr/bin/c++filt. 3. Fix "ld -r" with execption handling. Changes from binutils 2.13.90.0.10: 1. Update from binutils 2002 1114. 2. Fix ELF/alpha bugs. 3. Fix an ELF/i386 assembler bug. Changes from binutils 2.13.90.0.4: 1. Update from binutils 2002 1010. 2. More ELF/PPC linker bug fixes. 3. Fix an ELF/alpha linker bug. 4. Fix an ELF/sparc linker bug to support Solaris. 5. More TLS updates. Changes from binutils 2.13.90.0.3: 1. Update from binutils 2002 0814. 2. Fix symbol versioning bugs for gcc 3.2. 3. Fix mips gas. Changes from binutils 2.13.90.0.2: 1. Update from binutils 2002 0809. 2. Fix a mips gas compatibility bug. 3. Fix an x86 TLS bfd bug. 4. Fix an x86 PIC gas bug. 5. Improve symbol versioning support. The file list: 1. binutils-2.18.50.0.2.tar.bz2. Source code. 2. binutils-2.18.50.0.1-2.18.50.0.2.diff.bz2. Patch against the previous beta source code. 3. binutils-2.18.50.0.2.i686.tar.bz2. IA-32 binary tar ball for RedHat EL 4. 4. binutils-2.18.50.0.2.ia64.tar.bz2. IA-64 binary tar ball for RedHat EL 4. 5. binutils-2.18.50.0.2.x86_64.tar.bz2. X64_64 binary tar ball for RedHat EL 4. The primary sites for the beta Linux binutils are: 1. http://www.kernel.org/pub/linux/devel/binutils/ Thanks. H.J. Lu hjl@lucon.org 10/03/2007 From wim@iguana.be Wed Oct 3 20:18:54 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 03 Oct 2007 20:19:02 +0100 (BST) Received: from mailrelay004.isp.belgacom.be ([195.238.6.170]:32019 "EHLO mailrelay004.isp.belgacom.be") by ftp.linux-mips.org with ESMTP id S20025638AbXJCTSy (ORCPT ); Wed, 3 Oct 2007 20:18:54 +0100 Received: from 226.218-64-87.adsl-dyn.isp.belgacom.be (HELO infomag.iguana.be) ([87.64.218.226]) by mailrelay004.isp.belgacom.be with ESMTP; 03 Oct 2007 21:18:45 +0200 Received: from 226.218-64-87.adsl-dyn.isp.belgacom.be (HELO infomag.iguana.be) ([87.64.218.226]) by mailrelay004.isp.belgacom.be with ESMTP; 03 Oct 2007 21:18:45 +0200 Received: from 226.218-64-87.adsl-dyn.isp.belgacom.be (HELO infomag.iguana.be) ([87.64.218.226]) by mailrelay004.isp.belgacom.be with ESMTP; 03 Oct 2007 21:18:45 +0200 Received: from 226.218-64-87.adsl-dyn.isp.belgacom.be (HELO infomag.iguana.be) ([87.64.218.226]) by mailrelay004.isp.belgacom.be with ESMTP; 03 Oct 2007 21:18:45 +0200 X-Belgacom-Dynamic: yes Received: from infomag.iguana.be (localhost.localdomain [127.0.0.1]) by infomag.iguana.be (8.13.8/8.12.11) with ESMTP id l93JOKqh007629; Wed, 3 Oct 2007 21:24:20 +0200 Received: (from wim@localhost) by infomag.iguana.be (8.13.8/8.13.8/Submit) id l93JOEuF007627; Wed, 3 Oct 2007 21:24:14 +0200 Date: Wed, 3 Oct 2007 21:24:14 +0200 From: Wim Van Sebroeck To: Matteo Croce Cc: linux-mips@linux-mips.org, Nicolas Thill , Enrik Berkhan , Christer Weinigel , Andrew Morton Subject: Re: [PATCH][MIPS][5/7] AR7: watchdog timer Message-ID: <20071003192414.GA7543@infomag.infomag.iguana.be> References: <200709201728.10866.technoboy85@gmail.com> <200709201806.41942.technoboy85@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200709201806.41942.technoboy85@gmail.com> User-Agent: Mutt/1.4.2.1i Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 16829 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: wim@iguana.be Precedence: bulk X-list: linux-mips Hi Matteo, Sorry for the late response. Some personal/work issues prevented me in reacting faster. > +static int ar7_wdt_open(struct inode *inode, struct file *file) > +{ > + /* only allow one at a time */ > + if (down_trylock(&open_semaphore)) > + return -EBUSY; > + ar7_wdt_enable_wdt(); > + expect_close = 0; > + > + return 0; > +} The /dev/watchdog device is a VFS (Virtual File System). We thus use a: return nonseekable_open(inode, file); > +static ssize_t ar7_wdt_write(struct file *file, const char *data, > + size_t len, loff_t *ppos) > +{ > + if (*ppos != file->f_pos) > + return -ESPIPE; > + Since we use the nonseekable_open we don't need the if (*ppos != file->f_pos) return -ESPIPE; > +static int __init ar7_wdt_init(void) > +{ ... > + rc = misc_register(&ar7_wdt_miscdev); > + if (rc) { > + printk(KERN_ERR DRVNAME ": unable to register misc device\n"); > + goto out_alloc; > + } > + > + rc = register_reboot_notifier(&ar7_wdt_notifier); > + if (rc) { > + printk(KERN_ERR DRVNAME > + ": unable to register reboot notifier\n"); > + goto out_register; > + } > + goto out; > + > +out_register: > + misc_deregister(&ar7_wdt_miscdev); > +out_alloc: > + release_mem_region(ar7_regs_wdt, sizeof(struct ar7_wdt)); > +out: > + return rc; > +} It's better to first register the reboot-notifier instead of registering the misc-device. The misc-device gives userspace allready access to the device and that's something that you want to do as the last action to prevent problems. For the rest: all OK. If you want I'll add it to the linux-2.6-watchdog-mm tree with the above mentioned changes. Greetings, Wim. From vagabon.xyz@gmail.com Wed Oct 3 20:47:58 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 03 Oct 2007 20:48:06 +0100 (BST) Received: from ug-out-1314.google.com ([66.249.92.172]:50520 "EHLO ug-out-1314.google.com") by ftp.linux-mips.org with ESMTP id S20025725AbXJCTr6 (ORCPT ); Wed, 3 Oct 2007 20:47:58 +0100 Received: by ug-out-1314.google.com with SMTP id u2so235577uge for ; Wed, 03 Oct 2007 12:47:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding; bh=wBaLFP0lfnx1FAcT4YjMW+TTCpdClKW+ZrInFq4+dFM=; b=iPJqUHkDG+ZJiAZ6EefglT1ypwYvQ6xz9SbA1VyhMjqsDDRBeV7UvIPq5RFaYQRK1UCstnt9tdN2lisiiHb93DEqH0SJh0JoaXYej4hFFcK01/NPewOuxcyBsA21QPmq//8xEH+JCcVqyIvpdmmJV6CXQQ6/eXhfqAfdB/tb2n8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding; b=Kv8FL0QGhqc8/6QlWbT98A3vyXVGw12A2snQuxFj/rMSn806nWhAwt7bu7DfD3S6/qN4r7XD8hhUQqS9rWq8EQlFYFH2aVGaKSgMS9N0bjwudc0i3kEjUaFZZLOwf+TfS32K+0ahK297ikJPWhIrPGuemnwUe3+ww8IPCEQ1H9Q= Received: by 10.66.243.2 with SMTP id q2mr1007918ugh.1191440877532; Wed, 03 Oct 2007 12:47:57 -0700 (PDT) Received: from ?192.168.0.1? ( [82.235.205.153]) by mx.google.com with ESMTPS id w7sm1506880mue.2007.10.03.12.47.56 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 03 Oct 2007 12:47:56 -0700 (PDT) Message-ID: <4703F155.4000301@gmail.com> Date: Wed, 03 Oct 2007 21:45:25 +0200 From: Franck Bui-Huu User-Agent: Thunderbird 2.0.0.5 (X11/20070719) MIME-Version: 1.0 To: Thiemo Seufer CC: Ralf Baechle , "Maciej W. Rozycki" , linux-mips@linux-mips.org Subject: Re: [PATCH] mm/pg-r4k.c: Dump the generated code References: <20071002141125.GC16772@networkno.de> <20071002154918.GA11312@linux-mips.org> <47038874.9050704@gmail.com> <20071003131158.GL16772@networkno.de> In-Reply-To: <20071003131158.GL16772@networkno.de> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 16830 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: vagabon.xyz@gmail.com Precedence: bulk X-list: linux-mips Thiemo Seufer wrote: > > Then you have the worst of both approaches: The nicely readable > disassembly will change under you feet, and you still need > relocation annotations etc. for CPU-specific fixups. The end-result > is likely more complicated and opaque than what we have now. Let say we generate handlers with all possible cpu fixups. Very few instructions would be removed so the disassembly should be quite similar after patching. And by emitting some nice comments in the generated code, it should be fairly obvious to get an idea of the final code. All fixups would be listed in a table with some flags to identify them and a list of instructions which need to be relocated. It seems to me that the kernel code would be much simpler than what we have now. Regarding the script used to generate the assembly code, if think it would be too. Thanks, Franck From ths@networkno.de Wed Oct 3 21:18:06 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 03 Oct 2007 21:18:14 +0100 (BST) Received: from mail.bawue.net ([193.7.176.63]:60561 "EHLO mail.bawue.net") by ftp.linux-mips.org with ESMTP id S20025736AbXJCUSG (ORCPT ); Wed, 3 Oct 2007 21:18:06 +0100 Received: from lagash (88-106-176-50.dynamic.dsl.as9105.com [88.106.176.50]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by mail.bawue.net (Postfix) with ESMTP id 1472EE011F; Wed, 3 Oct 2007 22:18:12 +0200 (CEST) Received: from ths by lagash with local (Exim 4.67) (envelope-from ) id 1IdAfQ-00083F-8L; Wed, 03 Oct 2007 21:18:00 +0100 Date: Wed, 3 Oct 2007 21:18:00 +0100 From: Thiemo Seufer To: Franck Bui-Huu Cc: Ralf Baechle , "Maciej W. Rozycki" , linux-mips@linux-mips.org Subject: Re: [PATCH] mm/pg-r4k.c: Dump the generated code Message-ID: <20071003201800.GP16772@networkno.de> References: <20071002141125.GC16772@networkno.de> <20071002154918.GA11312@linux-mips.org> <47038874.9050704@gmail.com> <20071003131158.GL16772@networkno.de> <4703F155.4000301@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4703F155.4000301@gmail.com> User-Agent: Mutt/1.5.16 (2007-06-11) Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 16831 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: ths@networkno.de Precedence: bulk X-list: linux-mips Franck Bui-Huu wrote: > Thiemo Seufer wrote: > > > > Then you have the worst of both approaches: The nicely readable > > disassembly will change under you feet, and you still need > > relocation annotations etc. for CPU-specific fixups. The end-result > > is likely more complicated and opaque than what we have now. > > Let say we generate handlers with all possible cpu fixups. Very few > instructions would be removed so the disassembly should be quite > similar after patching. No way. Just check the possible variations: 64bit, highmem, SMP, and so on. > And by emitting some nice comments in the > generated code, it should be fairly obvious to get an idea of the > final code. > > All fixups would be listed in a table with some flags to identify them > and a list of instructions which need to be relocated. At that point you have invented something which effectively emits the sourcecode for tlbex.c. > It seems to me that the kernel code would be much simpler than what we > have now. Regarding the script used to generate the assembly code, if > think it would be too. I doubt that. Thiemo From technoboy85@gmail.com Wed Oct 3 21:18:35 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 03 Oct 2007 21:18:44 +0100 (BST) Received: from ag-out-0708.google.com ([72.14.246.240]:20578 "EHLO ag-out-0708.google.com") by ftp.linux-mips.org with ESMTP id S20025722AbXJCUSL (ORCPT ); Wed, 3 Oct 2007 21:18:11 +0100 Received: by ag-out-0708.google.com with SMTP id 33so2589671agc for ; Wed, 03 Oct 2007 13:17:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=eDQ28wdb8rCuymqOJ9RUoerhaBEua/51uc6GXGql3LY=; b=k5QWphMSK6hzo9wCeEBz3G9RbZIXQn30Fw7X5eWPm2RpNDpTk3iGOV0r3JMOkJBNj/NL5nszZ+TVC32xHpZMRLugHykp/tMSjQ+yMST8jU4mzv1w31gVnFhIdnDK4y5wlD7guo3+U+I7bjHt3jvu9l3GHFXp9e6kea7kSDpa5Rc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=iTj9UovDEdR/wfjh0oR5A9e8oKKWcIu81CNxL8sP9Z6nCcH7pvIQsTIHSdqDIejQCoD1hGBD6gVaTbrDlE9wFrz4Ng8DpMcvM4akReg2q5TQT7MxJC2WrOynrfWa3YRyFQt8aFxVuz0PqghIz3jdL3kAE8JuekPYgT0MPj6rO+4= Received: by 10.90.90.3 with SMTP id n3mr209084agb.1191442672979; Wed, 03 Oct 2007 13:17:52 -0700 (PDT) Received: by 10.90.83.9 with HTTP; Wed, 3 Oct 2007 13:17:52 -0700 (PDT) Message-ID: <40101cc30710031317n360ea4c7y6491f549c62e3edb@mail.gmail.com> Date: Wed, 3 Oct 2007 22:17:52 +0200 From: "Matteo Croce" To: "Wim Van Sebroeck" Subject: Re: [PATCH][MIPS][5/7] AR7: watchdog timer Cc: linux-mips@linux-mips.org, "Nicolas Thill" , "Enrik Berkhan" , "Christer Weinigel" , "Andrew Morton" In-Reply-To: <20071003192414.GA7543@infomag.infomag.iguana.be> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <200709201728.10866.technoboy85@gmail.com> <200709201806.41942.technoboy85@gmail.com> <20071003192414.GA7543@infomag.infomag.iguana.be> Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 16832 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: technoboy85@gmail.com Precedence: bulk X-list: linux-mips > If you want I'll add it to the linux-2.6-watchdog-mm tree with > the above mentioned changes. Yes, please Cheers From vagabon.xyz@gmail.com Thu Oct 4 08:36:02 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 04 Oct 2007 08:36:12 +0100 (BST) Received: from nf-out-0910.google.com ([64.233.182.189]:40225 "EHLO nf-out-0910.google.com") by ftp.linux-mips.org with ESMTP id S20022516AbXJDHgC (ORCPT ); Thu, 4 Oct 2007 08:36:02 +0100 Received: by nf-out-0910.google.com with SMTP id c10so65044nfd for ; Thu, 04 Oct 2007 00:35:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding; bh=NY7yn15/xxRye/FirViXaW2c9AwQLnIItbl67y6I6Rs=; b=UEnN2XR9tL58J/vFL++ts4S4YnJ/jdyt/O6To4gxbrbrbY5icYW1ehuAOS0t88AcktvfMEkg99gXlE0VjIP3xOeD61QxqgkggsZXM/heuYmjcSk6l0xoYh9Bl3ETrnA8JhIvQikAvG+mzYFFLhdY0xo6xXIPWzUN7nPw7gzL+Bo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding; b=pPWtXsEpJVD2ln8eQhlq7tqPzhq4dWVEzqvIDyitrQYiDrCpFMKW01sEP6FkWhyD9tdBKKz2+jy2Cud+rSmMYdXw4F9ZkrfmpoPqcjAD5Pys6MhEwDRCHl1vw6uXyP6GuzzXniTpaBz2DtrnAX0ibYA48dJZIi1vWLehwjFozNw= Received: by 10.86.86.12 with SMTP id j12mr1210794fgb.1191483344821; Thu, 04 Oct 2007 00:35:44 -0700 (PDT) Received: from ?192.168.0.1? ( [82.235.205.153]) by mx.google.com with ESMTPS id j9sm2570407mue.2007.10.04.00.35.42 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 04 Oct 2007 00:35:43 -0700 (PDT) Message-ID: <47049734.6050802@gmail.com> Date: Thu, 04 Oct 2007 09:33:08 +0200 From: Franck Bui-Huu User-Agent: Thunderbird 2.0.0.5 (X11/20070719) MIME-Version: 1.0 To: Thiemo Seufer CC: Ralf Baechle , "Maciej W. Rozycki" , linux-mips@linux-mips.org Subject: Re: [PATCH] mm/pg-r4k.c: Dump the generated code References: <20071002141125.GC16772@networkno.de> <20071002154918.GA11312@linux-mips.org> <47038874.9050704@gmail.com> <20071003131158.GL16772@networkno.de> <4703F155.4000301@gmail.com> <20071003201800.GP16772@networkno.de> In-Reply-To: <20071003201800.GP16772@networkno.de> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 16833 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: vagabon.xyz@gmail.com Precedence: bulk X-list: linux-mips Thiemo Seufer wrote: > Franck Bui-Huu wrote: >> Thiemo Seufer wrote: >>> Then you have the worst of both approaches: The nicely readable >>> disassembly will change under you feet, and you still need >>> relocation annotations etc. for CPU-specific fixups. The end-result >>> is likely more complicated and opaque than what we have now. >> Let say we generate handlers with all possible cpu fixups. Very few >> instructions would be removed so the disassembly should be quite >> similar after patching. > > No way. Just check the possible variations: 64bit, highmem, SMP, > and so on. > You just listed some variations that are known at compile time. What I meant by "all possible cpu fixups" is all fixups for a specific cpu which can be known only at runtime. >> And by emitting some nice comments in the >> generated code, it should be fairly obvious to get an idea of the >> final code. >> >> All fixups would be listed in a table with some flags to identify them >> and a list of instructions which need to be relocated. > > At that point you have invented something which effectively emits > the sourcecode for tlbex.c. > Not really, I would say it's just an idea to remove tlbex.c from the kernel code and to make it a tool called during compile time to generate a handler skeleton which would be finalized by the kernel. Thanks, Franck From veerasena_b@yahoo.co.in Thu Oct 4 11:13:24 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 04 Oct 2007 11:13:33 +0100 (BST) Received: from web8408.mail.in.yahoo.com ([202.43.219.156]:64377 "HELO web8408.mail.in.yahoo.com") by ftp.linux-mips.org with SMTP id S20024696AbXJDKNY (ORCPT ); Thu, 4 Oct 2007 11:13:24 +0100 Received: (qmail 51544 invoked by uid 60001); 4 Oct 2007 10:12:16 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.co.in; h=X-YMail-OSG:Received:Date:From:Subject:To:MIME-Version:Content-Type:Content-Transfer-Encoding:Message-ID; b=mDS6HF5YgniWNe6qHchj1YFWcg1Cx3Z/oa1B0ZMTAyO+/sxhZ9EPYawAOIcs1Ihn1jE06qg9HWEZk+C5jcnD7CN151IytMSZ3TpBBk7iJmlKBSxW9x+PZFNCKmAHH7TSYHZHImqcJthYcaw5Vrm6BWnPLriQabvpLaLNKFkiJ7w=; X-YMail-OSG: Et3xM6gVM1lBqhII.7EvY_7.97tfd61BpJw358sR8E1VXPZsXZTlxTgQpSU59V1rm.XT7M5yrLz5yCyy9uoFikPsBbj9y9Kvq9duyE9sa.6qF0P9AINd7xBeEz1gKQ-- Received: from [199.239.167.162] by web8408.mail.in.yahoo.com via HTTP; Thu, 04 Oct 2007 11:12:16 BST Date: Thu, 4 Oct 2007 11:12:16 +0100 (BST) From: veerasena reddy Subject: unresoved symbol _gp_disp To: linux-mips , "linux-kernel.org" MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Message-ID: <230962.51223.qm@web8408.mail.in.yahoo.com> Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 16834 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: veerasena_b@yahoo.co.in Precedence: bulk X-list: linux-mips Hi, I am using buildroot to build toolchain (GCC ver 3.4.3, binutil-1.15 and ucLibc-0.9.28, linux-2.6.18 kernel) for MIPS processor with soft float option enabled. I have written a loadble module ( which gets complied along with kernel) which does some floating point operation. When i try to load the module i get the following error "unresoved symbol _gp_disp". =================================================== below is from MIPS FAQ which also doesn't help: Insmod complains about the _gp_disp symbol being undefined _gp_disp is a magic symbol used with PIC code on MIPS. Be happy, this error message saved you from crashing your system. You should use the same compiler options to compile a kernel module as the kernel makefiles do. In particular the options -mno-pic -mno-abicalls -G 0 are important. =================================================== In fact i tried with -mno-abicalls -fno-pic compiler options still i see the same problem. Could you please give me some pointers on this issue. BTW, How to compile libgcc.a with "-G 0" options. In which file of buildroot i shoul added these options to get effective. Thanks in advance. Regards, Veerasena. Unlimited freedom, unlimited storage. Get it now, on http://help.yahoo.com/l/in/yahoo/mail/yahoomail/tools/tools-08.html/ From macro@linux-mips.org Thu Oct 4 11:30:20 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 04 Oct 2007 11:30:29 +0100 (BST) Received: from cerber.ds.pg.gda.pl ([153.19.208.18]:38345 "EHLO cerber.ds.pg.gda.pl") by ftp.linux-mips.org with ESMTP id S20024745AbXJDKaU (ORCPT ); Thu, 4 Oct 2007 11:30:20 +0100 Received: from localhost (unknown [127.0.0.17]) by cerber.ds.pg.gda.pl (Postfix) with ESMTP id B0B4E400A8; Thu, 4 Oct 2007 12:30:20 +0200 (CEST) X-Virus-Scanned: amavisd-new at cerber.ds.pg.gda.pl Received: from cerber.ds.pg.gda.pl ([153.19.208.18]) by localhost (cerber.ds.pg.gda.pl [153.19.208.18]) (amavisd-new, port 10024) with ESMTP id STB2gi5AeZY3; Thu, 4 Oct 2007 12:30:16 +0200 (CEST) Received: from piorun.ds.pg.gda.pl (piorun.ds.pg.gda.pl [153.19.208.8]) by cerber.ds.pg.gda.pl (Postfix) with ESMTP id 92759400C8; Thu, 4 Oct 2007 12:30:16 +0200 (CEST) Received: from blysk.ds.pg.gda.pl (macro@blysk.ds.pg.gda.pl [153.19.208.6]) by piorun.ds.pg.gda.pl (8.13.8/8.13.8) with ESMTP id l94AUJjf007694; Thu, 4 Oct 2007 12:30:19 +0200 Date: Thu, 4 Oct 2007 11:30:15 +0100 (BST) From: "Maciej W. Rozycki" To: Franck Bui-Huu cc: Thiemo Seufer , Ralf Baechle , linux-mips@linux-mips.org Subject: Re: [PATCH] mm/pg-r4k.c: Dump the generated code In-Reply-To: <47049734.6050802@gmail.com> Message-ID: References: <20071002141125.GC16772@networkno.de> <20071002154918.GA11312@linux-mips.org> <47038874.9050704@gmail.com> <20071003131158.GL16772@networkno.de> <4703F155.4000301@gmail.com> <20071003201800.GP16772@networkno.de> <47049734.6050802@gmail.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: ClamAV 0.91.2/4469/Thu Oct 4 08:56:38 2007 on piorun.ds.pg.gda.pl X-Virus-Status: Clean Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 16835 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: macro@linux-mips.org Precedence: bulk X-list: linux-mips On Thu, 4 Oct 2007, Franck Bui-Huu wrote: > Not really, I would say it's just an idea to remove tlbex.c from the > kernel code and to make it a tool called during compile time to > generate a handler skeleton which would be finalized by the kernel. Thanks for volunteering. When you finally come up with an implementation of a solution that is much better than the current one I am absolutely sure it will be accepted eagerly. Maciej From giuseppe@eppesuigoccas.homedns.org Thu Oct 4 11:35:59 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 04 Oct 2007 11:36:07 +0100 (BST) Received: from host191-212-dynamic.8-87-r.retail.telecomitalia.it ([87.8.212.191]:58349 "EHLO eppesuigoccas.homedns.org") by ftp.linux-mips.org with ESMTP id S20024695AbXJDKf7 (ORCPT ); Thu, 4 Oct 2007 11:35:59 +0100 Received: from giuseppe by eppesuigoccas.homedns.org with local (Exim 4.63) (envelope-from ) id 1IdO0a-0000n7-Cg; Thu, 04 Oct 2007 12:32:44 +0200 To: Ralf Baechle Subject: [PATCH] enable PCI bridges in MIPS ip32 Cc: linux-mips@linux-mips.org Message-Id: From: Giuseppe Sacco Date: Thu, 04 Oct 2007 12:32:44 +0200 Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 16836 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: giuseppe@eppesuigoccas.homedns.org Precedence: bulk X-list: linux-mips Use bus numbering when addressing device with MACE chipset in order to support PCI bridges. Changes in chkslot() and mkaddr() #defines. Signed-off-by: Giuseppe Sacco --- Hi Ralf, I managed to create a patch against current 2.6.23-rc9 git tree for supporting PCI bridges on SGI ip32 machines. This is my first kernel patch, so I am usure about the correct way to send a patch. Please let me know if anything is wrong. Bye, Giuseppe diff --git a/arch/mips/pci/ops-mace.c b/arch/mips/pci/ops-mace.c index 8008e31..18a7159 100644 --- a/arch/mips/pci/ops-mace.c +++ b/arch/mips/pci/ops-mace.c @@ -31,20 +31,21 @@ #define chkslot(_bus,_devfn) \ do { \ - if ((_bus)->number > 0 || PCI_SLOT (_devfn) < 1 \ - || PCI_SLOT (_devfn) > 3) \ + if ((_bus)->number > 1 || \ + ((_bus)->number == 0 && (PCI_SLOT (_devfn) < 1 \ + || PCI_SLOT (_devfn) > 3))) \ return PCIBIOS_DEVICE_NOT_FOUND; \ } while (0) -#define mkaddr(_devfn, _reg) \ -((((_devfn) & 0xffUL) << 8) | ((_reg) & 0xfcUL)) +#define mkaddr(_bus, _devfn, _reg) \ +((((_bus)->number & 0xffUL) << 16) | (((_devfn) & 0xffUL) << 8) | ((_reg) & 0xfcUL)) static int mace_pci_read_config(struct pci_bus *bus, unsigned int devfn, int reg, int size, u32 *val) { chkslot(bus, devfn); - mace->pci.config_addr = mkaddr(devfn, reg); + mace->pci.config_addr = mkaddr(bus, devfn, reg); switch (size) { case 1: *val = mace->pci.config_data.b[(reg & 3) ^ 3]; @@ -67,7 +68,7 @@ mace_pci_write_config(struct pci_bus *bus, unsigned int devfn, int reg, int size, u32 val) { chkslot(bus, devfn); - mace->pci.config_addr = mkaddr(devfn, reg); + mace->pci.config_addr = mkaddr(bus, devfn, reg); switch (size) { case 1: mace->pci.config_data.b[(reg & 3) ^ 3] = val; From ralf@linux-mips.org Thu Oct 4 13:15:58 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 04 Oct 2007 13:16:02 +0100 (BST) Received: from localhost.localdomain ([127.0.0.1]:50561 "EHLO dl5rb.ham-radio-op.net") by ftp.linux-mips.org with ESMTP id S20026000AbXJDMP6 (ORCPT ); Thu, 4 Oct 2007 13:15:58 +0100 Received: from denk.linux-mips.net (denk.linux-mips.net [127.0.0.1]) by dl5rb.ham-radio-op.net (8.14.1/8.13.8) with ESMTP id l94CFvr7005417; Thu, 4 Oct 2007 13:15:58 +0100 Received: (from ralf@localhost) by denk.linux-mips.net (8.14.1/8.14.1/Submit) id l94CFvo2005416; Thu, 4 Oct 2007 13:15:57 +0100 Date: Thu, 4 Oct 2007 13:15:57 +0100 From: Ralf Baechle To: Franck Bui-Huu Cc: Thiemo Seufer , "Maciej W. Rozycki" , linux-mips@linux-mips.org Subject: Re: [PATCH] mm/pg-r4k.c: Dump the generated code Message-ID: <20071004121557.GA28928@linux-mips.org> References: <20071002141125.GC16772@networkno.de> <20071002154918.GA11312@linux-mips.org> <47038874.9050704@gmail.com> <20071003131158.GL16772@networkno.de> <4703F155.4000301@gmail.com> <20071003201800.GP16772@networkno.de> <47049734.6050802@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <47049734.6050802@gmail.com> User-Agent: Mutt/1.5.14 (2007-02-12) Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 16837 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: ralf@linux-mips.org Precedence: bulk X-list: linux-mips On Thu, Oct 04, 2007 at 09:33:08AM +0200, Franck Bui-Huu wrote: > Not really, I would say it's just an idea to remove tlbex.c from the > kernel code and to make it a tool called during compile time to > generate a handler skeleton which would be finalized by the kernel. IRIX was assembling its TLB exception handler from a few such skeletons or rather a few fractions. That works reasonably well as long as there are not too many variants - but Linux supports about anything on earth. Another disadvantage of the IRIX approach was that the fragments are written in assembler but the tacking together happens in C code so the code is split in a somewhat unnatural way over a few files. Ralf From redhatter@gentoo.org Thu Oct 4 13:26:04 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 04 Oct 2007 13:26:13 +0100 (BST) Received: from [203.94.56.252] ([203.94.56.252]:59520 "EHLO longlandclan.hopto.org") by ftp.linux-mips.org with ESMTP id S20022366AbXJDM0E (ORCPT ); Thu, 4 Oct 2007 13:26:04 +0100 Received: (qmail 7132 invoked from network); 4 Oct 2007 12:24:55 -0000 Received: from unknown (HELO ?IPv6:2001:388:c116:1:2e0:4dff:fe01:536?) (2001:388:c116:1:2e0:4dff:fe01:536) by 2001:388:c116:1::1 with ESMTPS (DHE-RSA-AES256-SHA encrypted); 4 Oct 2007 12:24:55 -0000 Message-ID: <4704DB98.1070905@gentoo.org> Date: Thu, 04 Oct 2007 22:24:56 +1000 From: Stuart Longland User-Agent: Thunderbird 2.0.0.0 (X11/20070512) MIME-Version: 1.0 To: Geert Uytterhoeven CC: Kumba , Ed Stafford , linux-mips@linux-mips.org Subject: Re: What is the current state of the Octane/IP30 support? References: <41370a610710021341g749742dejec06b3a38477fd47@mail.gmail.com> <47033156.7090703@gentoo.org> In-Reply-To: X-Enigmail-Version: 0.95.0 OpenPGP: id=63264AB9; url=http://dev.gentoo.org/%7Eredhatter/gpgkey.asc Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="------------enig9CDA26EDC92FD680444C5095" Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 16838 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: redhatter@gentoo.org Precedence: bulk X-list: linux-mips This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig9CDA26EDC92FD680444C5095 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Geert Uytterhoeven wrote: > On Wed, 3 Oct 2007, Kumba wrote: >> For the most part, Impact-based systems run great. You get X, unaccel= erated, >> no 3D, and a framebuffer. VPro, framebuffer, but no X. USB kinda weo= rks if > ^^^^^^^^^^^^^^^^^^^^^ > What's the reason for not having X? X doesn't support the frame buffer = layout? >=20 > Gr{oetje,eeting}s, My understanding, is there are two problems: o VPro (and IMPACT) have its own dedicated memory separate from the system memory, thus one cannot use fbdev to run X. ("framebuffer" perhaps is bad terminology) o No-one except SGI seems to know how to load images into the video memory using DMA. Thus the shadowfb approach used to construct the IMPACT X11 driver, isn't possible for VPro. If someone could figure the latter problem out... we could have full VPro support, including OpenGL, which would be sweet. But apparently this has been less than trivial to achieve. Certainly well beyond my limited skills. ;-) Regards, --=20 Stuart Longland (aka Redhatter) .'''. Gentoo Linux/MIPS Cobalt and Docs Developer '.'` : =2E . . . . . . . . . . . . . . . . . . . . . .'.' http://dev.gentoo.org/~redhatter :.' I haven't lost my mind... ...it's backed up on a tape somewhere. --------------enig9CDA26EDC92FD680444C5095 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHBNuZuarJ1mMmSrkRCt9dAJ4zmNzbgrJ8SMgq6mPT+vp/k0OEcQCeL9z5 5xXuzwslmOQohgUlgWC99x4= =DJXO -----END PGP SIGNATURE----- --------------enig9CDA26EDC92FD680444C5095-- From macro@linux-mips.org Thu Oct 4 13:27:52 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 04 Oct 2007 13:28:00 +0100 (BST) Received: from cerber.ds.pg.gda.pl ([153.19.208.18]:56202 "EHLO cerber.ds.pg.gda.pl") by ftp.linux-mips.org with ESMTP id S20022366AbXJDM1w (ORCPT ); Thu, 4 Oct 2007 13:27:52 +0100 Received: from localhost (unknown [127.0.0.17]) by cerber.ds.pg.gda.pl (Postfix) with ESMTP id C2B27400AA; Thu, 4 Oct 2007 14:27:52 +0200 (CEST) X-Virus-Scanned: amavisd-new at cerber.ds.pg.gda.pl Received: from cerber.ds.pg.gda.pl ([153.19.208.18]) by localhost (cerber.ds.pg.gda.pl [153.19.208.18]) (amavisd-new, port 10024) with ESMTP id 3-h0JOB6wWsp; Thu, 4 Oct 2007 14:27:48 +0200 (CEST) Received: from piorun.ds.pg.gda.pl (piorun.ds.pg.gda.pl [153.19.208.8]) by cerber.ds.pg.gda.pl (Postfix) with ESMTP id 902C5400A8; Thu, 4 Oct 2007 14:27:48 +0200 (CEST) Received: from blysk.ds.pg.gda.pl (macro@blysk.ds.pg.gda.pl [153.19.208.6]) by piorun.ds.pg.gda.pl (8.13.8/8.13.8) with ESMTP id l94CRpoN031582; Thu, 4 Oct 2007 14:27:51 +0200 Date: Thu, 4 Oct 2007 13:27:47 +0100 (BST) From: "Maciej W. Rozycki" To: Giuseppe Sacco cc: Ralf Baechle , linux-mips@linux-mips.org Subject: Re: [PATCH] enable PCI bridges in MIPS ip32 In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: ClamAV 0.91.2/4469/Thu Oct 4 08:56:38 2007 on piorun.ds.pg.gda.pl X-Virus-Status: Clean Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 16839 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: macro@linux-mips.org Precedence: bulk X-list: linux-mips On Thu, 4 Oct 2007, Giuseppe Sacco wrote: > I managed to create a patch against current 2.6.23-rc9 git tree > for supporting PCI bridges on SGI ip32 machines. > This is my first kernel patch, so I am usure about the correct way > to send a patch. Please let me know if anything is wrong. I am glad you have succeeded. A couple of minor notes below. > @@ -31,20 +31,21 @@ > > #define chkslot(_bus,_devfn) \ > do { \ > - if ((_bus)->number > 0 || PCI_SLOT (_devfn) < 1 \ > - || PCI_SLOT (_devfn) > 3) \ > + if ((_bus)->number > 1 || \ > + ((_bus)->number == 0 && (PCI_SLOT (_devfn) < 1 \ > + || PCI_SLOT (_devfn) > 3))) \ > return PCIBIOS_DEVICE_NOT_FOUND; \ I think you should allow any bus numbers, not only 0 and 1 -- while possibly unlikely, you may have a tree of bridges on an option card. The generic code should handle it fine -- you need not care. > -#define mkaddr(_devfn, _reg) \ > -((((_devfn) & 0xffUL) << 8) | ((_reg) & 0xfcUL)) > +#define mkaddr(_bus, _devfn, _reg) \ > +((((_bus)->number & 0xffUL) << 16) | (((_devfn) & 0xffUL) << 8) | ((_reg) & 0xfcUL)) Please fit your lines in 80 characters. > - mace->pci.config_addr = mkaddr(devfn, reg); > + mace->pci.config_addr = mkaddr(bus, devfn, reg); It may be more consistent if you pass just "bus->number". You may neatly avoid the line wrap above this way too. Have you run your change through `scripts/checkpatch.pl'? Maciej From giuseppe@eppesuigoccas.homedns.org Thu Oct 4 13:48:33 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 04 Oct 2007 13:48:43 +0100 (BST) Received: from host191-212-dynamic.8-87-r.retail.telecomitalia.it ([87.8.212.191]:3981 "EHLO eppesuigoccas.homedns.org") by ftp.linux-mips.org with ESMTP id S20023250AbXJDMsd (ORCPT ); Thu, 4 Oct 2007 13:48:33 +0100 Received: from [81.30.2.2] (helo=[192.168.12.252]) by eppesuigoccas.homedns.org with esmtpsa (TLS-1.0:RSA_ARCFOUR_MD5:16) (Exim 4.63) (envelope-from ) id 1IdQ7r-00081C-Ca; Thu, 04 Oct 2007 14:48:25 +0200 Subject: kernel bug using 2.6.23-rc9 From: Giuseppe Sacco To: linux-mips@linux-mips.org Content-Type: text/plain Date: Thu, 04 Oct 2007 14:49:13 +0200 Message-Id: <1191502153.10050.15.camel@scarafaggio> Mime-Version: 1.0 X-Mailer: Evolution 2.10.3 Content-Transfer-Encoding: 7bit Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 16840 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: giuseppe@eppesuigoccas.homedns.org Precedence: bulk X-list: linux-mips Hi, while testing the latest kernel on SGI O2 I got may kernel bugs like this: Kernel bug detected[#9]: Cpu 0 $ 0 : 0000000000000000 ffffffff9001fce0 0000000000000001 0000000000000f18 $ 4 : 980000000111b4b8 000000007f955f18 ffffffff80400000 0000000000003fff $ 8 : 00000000000050f1 000000007f955f18 9800000006073d68 9800000006073d60 $12 : 0000000000000010 ffffffff80000008 ffffffff80091680 0000000000000000 $16 : 980000000111b4b8 980000000768ddd0 000000000000000e 000000007f955f18 $20 : 9800000000581908 9800000007898080 9800000006073d68 9800000006073d60 $24 : 0000000000478284 000000002ac30580 $28 : 9800000006070000 9800000006073cd0 0000000000000000 ffffffff8001b390 Hi : 000000000000f2d3 Lo : 00000000000050f1 epc : ffffffff8001c800 kmap_coherent+0x10/0x118 Tainted: G D ra : ffffffff8001b390 __flush_anon_page+0x70/0x90 Status: 9001fce3 KX SX UX KERNEL EXL IE Cause : 00000034 PrId : 00002321 Modules linked in: ppp_deflate zlib_deflate bsd_comp iptable_filter ipt_MASQUERADE xt_tcpudp iptable_nat nf_nat nf_conntrack_ipv4 nf_conntrack nfnetlink ppp_async crc_ccitt ip_tables x_tables ppp_generic slhc dm_snapshot dm_mirror dm_mod ehci_hcd ohci_hcd r8169 usbcore evdev Process ps (pid: 30124, threadinfo=9800000006070000, task=98000000076c5908) Stack : ffffffff80079dcc ffffffff80079b6c 0000000000000010 0000000000000000 0000000000000001 9800000006073d68 9800000006073d60 0000000000000000 9800000007898080 000000007f955f18 98000000015b0000 000000000000000f 9800000007898080 0000000000000000 9800000000581908 9800000006073d68 9800000000000000 ffffffff8007a11c 0000000000000000 980000000111b4b8 98000000078980e0 98000000015b0000 9800000007898080 98000000015b0000 000000000000000f 0000000000000000 9800000000581908 9800000006073e88 0000000000001000 0000000000000000 0000000000000040 ffffffff800e0098 98000000015b0000 9800000000581908 fffffffffffffff4 980000000164d6c0 00000000000007ff 9800000006073e88 000000007fd4cce8 ffffffff800e25dc ... Call Trace: [] kmap_coherent+0x10/0x118 [] __flush_anon_page+0x70/0x90 [] get_user_pages+0x2dc/0x510 [] access_process_vm+0x11c/0x218 [] proc_pid_cmdline+0xa8/0x170 [] proc_info_read+0x13c/0x180 [] vfs_read+0xc0/0x160 [] sys_read+0x4c/0x90 [] handle_sys+0x114/0x130 Code: 0002127a 00021000 30420001 <00028036> 8f820024 3c038048 24420001 af820024 dc62f100 From giuseppe@eppesuigoccas.homedns.org Thu Oct 4 13:49:30 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 04 Oct 2007 13:49:36 +0100 (BST) Received: from host191-212-dynamic.8-87-r.retail.telecomitalia.it ([87.8.212.191]:5005 "EHLO eppesuigoccas.homedns.org") by ftp.linux-mips.org with ESMTP id S20022483AbXJDMt3 (ORCPT ); Thu, 4 Oct 2007 13:49:29 +0100 Received: from [81.30.2.2] (helo=[192.168.12.252]) by eppesuigoccas.homedns.org with esmtpsa (TLS-1.0:RSA_ARCFOUR_MD5:16) (Exim 4.63) (envelope-from ) id 1IdQ8r-00082W-6M for linux-mips@linux-mips.org; Thu, 04 Oct 2007 14:49:27 +0200 Subject: Re: [PATCH] enable PCI bridges in MIPS ip32 From: Giuseppe Sacco To: linux-mips@linux-mips.org In-Reply-To: References: Content-Type: text/plain Date: Thu, 04 Oct 2007 14:50:19 +0200 Message-Id: <1191502219.10050.16.camel@scarafaggio> Mime-Version: 1.0 X-Mailer: Evolution 2.10.3 Content-Transfer-Encoding: 7bit Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 16841 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: giuseppe@eppesuigoccas.homedns.org Precedence: bulk X-list: linux-mips Hi Maciej, Il giorno gio, 04/10/2007 alle 13.27 +0100, Maciej W. Rozycki ha scritto: [...] > It may be more consistent if you pass just "bus->number". You may neatly > avoid the line wrap above this way too. > > Have you run your change through `scripts/checkpatch.pl'? I'll provide a new patch tomorrow. Thanks, Giuseppe From ralf@linux-mips.org Thu Oct 4 14:03:19 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 04 Oct 2007 14:03:22 +0100 (BST) Received: from localhost.localdomain ([127.0.0.1]:11459 "EHLO dl5rb.ham-radio-op.net") by ftp.linux-mips.org with ESMTP id S20024220AbXJDNDT (ORCPT ); Thu, 4 Oct 2007 14:03:19 +0100 Received: from denk.linux-mips.net (denk.linux-mips.net [127.0.0.1]) by dl5rb.ham-radio-op.net (8.14.1/8.13.8) with ESMTP id l94D3ISH006638; Thu, 4 Oct 2007 14:03:18 +0100 Received: (from ralf@localhost) by denk.linux-mips.net (8.14.1/8.14.1/Submit) id l94D3I6w006637; Thu, 4 Oct 2007 14:03:18 +0100 Date: Thu, 4 Oct 2007 14:03:18 +0100 From: Ralf Baechle To: "Maciej W. Rozycki" Cc: Giuseppe Sacco , linux-mips@linux-mips.org Subject: Re: [PATCH] enable PCI bridges in MIPS ip32 Message-ID: <20071004130318.GC28928@linux-mips.org> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.14 (2007-02-12) Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 16842 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: ralf@linux-mips.org Precedence: bulk X-list: linux-mips On Thu, Oct 04, 2007 at 01:27:47PM +0100, Maciej W. Rozycki wrote: > On Thu, 4 Oct 2007, Giuseppe Sacco wrote: > > > I managed to create a patch against current 2.6.23-rc9 git tree > > for supporting PCI bridges on SGI ip32 machines. > > This is my first kernel patch, so I am usure about the correct way > > to send a patch. Please let me know if anything is wrong. > > I am glad you have succeeded. A couple of minor notes below. > > > @@ -31,20 +31,21 @@ > > > > #define chkslot(_bus,_devfn) \ > > do { \ > > - if ((_bus)->number > 0 || PCI_SLOT (_devfn) < 1 \ > > - || PCI_SLOT (_devfn) > 3) \ > > + if ((_bus)->number > 1 || \ > > + ((_bus)->number == 0 && (PCI_SLOT (_devfn) < 1 \ > > + || PCI_SLOT (_devfn) > 3))) \ > > return PCIBIOS_DEVICE_NOT_FOUND; \ > > I think you should allow any bus numbers, not only 0 and 1 -- while > possibly unlikely, you may have a tree of bridges on an option card. The > generic code should handle it fine -- you need not care. I think historically we had something like chkslot() first in the code for the Galileo/Marvell bridges where it's needed due the brainddead abuse of device 31 - any access to that will crash the system. From that point on chkslot checking spread across the PCI code like the measles in a kindergarden. Another stylistic comment is about the return statement in the macro. That sort of construct should be avoided, it's quite unobvious to the reader who isn't familiar with the macro definition. Another thing the historically extremly widespread use of macros in the Linux kernel. Macros tend to be harder to read and maintain but historically gcc was doing a rather bad job at optimizing inline functions because inlining happend rather late in the compilation process when many of the optimizations already had been performed. That is no longer true for modern gcc so these days functions are prefered. So adding this all up: static inline int chkslot(struct pci_bus *bus, unsigned int devfn) { return bus->number > 1 || (bus->number == 0 && (PCI_SLOT(devfn) < 1 || PCI_SLOT(devfn) > 3)); } static inline int mkaddr(struct pci_bus *bus, unsigned int devfn, unsigned int reg) { return ((bus->number & 0xff) << 16) | ((devfn & 0xff) << 8) | (reg & 0xfc); } static int mace_pci_read_config(struct pci_bus *bus, unsigned int devfn, int reg, int size, u32 *val) { if (chkslot(bus, devfn) return PCIBIOS_DEVICE_NOT_FOUND; mace->pci.config_addr = mkaddr(bus, devfn, reg); [...] (of course this all goes far beyond Giuseppe's patch - but the whole ops-mace.c file like so much of the other code in arch/mips/pci isn't exactly an example to be copied. Ah, one final formality - when sending a patch please add a Signed-off-by: line. See Documentation/SubmittingPatches in the kernel tree for what this means. So Giuseppe, I'm happy to apply your patch because it makes sense and doesn't add new badness. Cheers, Ralf From macro@linux-mips.org Thu Oct 4 15:13:06 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 04 Oct 2007 15:13:15 +0100 (BST) Received: from cerber.ds.pg.gda.pl ([153.19.208.18]:23207 "EHLO cerber.ds.pg.gda.pl") by ftp.linux-mips.org with ESMTP id S20024713AbXJDONG (ORCPT ); Thu, 4 Oct 2007 15:13:06 +0100 Received: from localhost (unknown [127.0.0.17]) by cerber.ds.pg.gda.pl (Postfix) with ESMTP id B85184012E; Thu, 4 Oct 2007 16:13:06 +0200 (CEST) X-Virus-Scanned: amavisd-new at cerber.ds.pg.gda.pl Received: from cerber.ds.pg.gda.pl ([153.19.208.18]) by localhost (cerber.ds.pg.gda.pl [153.19.208.18]) (amavisd-new, port 10024) with ESMTP id jB5i+qmguZ+u; Thu, 4 Oct 2007 16:13:02 +0200 (CEST) Received: from piorun.ds.pg.gda.pl (piorun.ds.pg.gda.pl [153.19.208.8]) by cerber.ds.pg.gda.pl (Postfix) with ESMTP id 5C8E140095; Thu, 4 Oct 2007 16:13:02 +0200 (CEST) Received: from blysk.ds.pg.gda.pl (macro@blysk.ds.pg.gda.pl [153.19.208.6]) by piorun.ds.pg.gda.pl (8.13.8/8.13.8) with ESMTP id l94ED5YL018017; Thu, 4 Oct 2007 16:13:05 +0200 Date: Thu, 4 Oct 2007 15:13:01 +0100 (BST) From: "Maciej W. Rozycki" To: Ralf Baechle cc: Giuseppe Sacco , linux-mips@linux-mips.org Subject: Re: [PATCH] enable PCI bridges in MIPS ip32 In-Reply-To: <20071004130318.GC28928@linux-mips.org> Message-ID: References: <20071004130318.GC28928@linux-mips.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: ClamAV 0.91.2/4471/Thu Oct 4 15:22:27 2007 on piorun.ds.pg.gda.pl X-Virus-Status: Clean Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 16843 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: macro@linux-mips.org Precedence: bulk X-list: linux-mips On Thu, 4 Oct 2007, Ralf Baechle wrote: > I think historically we had something like chkslot() first in the code > for the Galileo/Marvell bridges where it's needed due the brainddead > abuse of device 31 - any access to that will crash the system. From that > point on chkslot checking spread across the PCI code like the measles in > a kindergarden. Does the Galileo/Marvell do anything else with the device #31 than what is recommended by the PCI spec as a way to issue special cycles? We need to be careful about the device #31 in general; it is seldom used anyway as there are only 20 IDSEL lines defined by the standard and they are usually mapped starting from the device #0. > Another stylistic comment is about the return statement in the macro. > That sort of construct should be avoided, it's quite unobvious to the > reader who isn't familiar with the macro definition. [etc... about macros] Very true indeed -- I sort of slipped over the issue unconsciously as it is outside the scope of the fix itself. It is usually a good idea to separate clean-ups from changes to the semantics. > Ah, one final formality - when sending a patch please add a > Signed-off-by: line. See Documentation/SubmittingPatches in the kernel > tree for what this means. Well, there was one actually in the submission. :-) And `checkpatch.pl' would remind about it otherwise. Maciej From giuseppe@eppesuigoccas.homedns.org Thu Oct 4 15:32:45 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 04 Oct 2007 15:32:53 +0100 (BST) Received: from host191-212-dynamic.8-87-r.retail.telecomitalia.it ([87.8.212.191]:52415 "EHLO eppesuigoccas.homedns.org") by ftp.linux-mips.org with ESMTP id S20025722AbXJDOcp (ORCPT ); Thu, 4 Oct 2007 15:32:45 +0100 Received: from [81.30.2.2] (helo=[192.168.12.252]) by eppesuigoccas.homedns.org with esmtpsa (TLS-1.0:RSA_ARCFOUR_MD5:16) (Exim 4.63) (envelope-from ) id 1IdRkl-0003ez-5a; Thu, 04 Oct 2007 16:32:41 +0200 Subject: Re: [PATCH] enable PCI bridges in MIPS ip32 From: Giuseppe Sacco To: Ralf Baechle Cc: "Maciej W. Rozycki" , linux-mips@linux-mips.org In-Reply-To: <20071004130318.GC28928@linux-mips.org> References: <20071004130318.GC28928@linux-mips.org> Content-Type: text/plain Date: Thu, 04 Oct 2007 16:33:33 +0200 Message-Id: <1191508413.10050.26.camel@scarafaggio> Mime-Version: 1.0 X-Mailer: Evolution 2.10.3 Content-Transfer-Encoding: 7bit Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 16844 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: giuseppe@eppesuigoccas.homedns.org Precedence: bulk X-list: linux-mips Il giorno gio, 04/10/2007 alle 14.03 +0100, Ralf Baechle ha scritto: [...] > (of course this all goes far beyond Giuseppe's patch - but the whole > ops-mace.c file like so much of the other code in arch/mips/pci isn't > exactly an example to be copied. > > Ah, one final formality - when sending a patch please add a > Signed-off-by: line. See Documentation/SubmittingPatches in the kernel > tree for what this means. I'll provide a new patch tomorrow, using inline functions instead of macros. About the maximum number of PCI buses, I used 1 since the ip32 only have 1 slot. If this maximum value should be changed, please let me know. Bye, Giuseppe From macro@linux-mips.org Thu Oct 4 16:03:55 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 04 Oct 2007 16:04:04 +0100 (BST) Received: from cerber.ds.pg.gda.pl ([153.19.208.18]:29399 "EHLO cerber.ds.pg.gda.pl") by ftp.linux-mips.org with ESMTP id S20026204AbXJDPDz (ORCPT ); Thu, 4 Oct 2007 16:03:55 +0100 Received: from localhost (unknown [127.0.0.17]) by cerber.ds.pg.gda.pl (Postfix) with ESMTP id C7E27400A8; Thu, 4 Oct 2007 17:03:55 +0200 (CEST) X-Virus-Scanned: amavisd-new at cerber.ds.pg.gda.pl Received: from cerber.ds.pg.gda.pl ([153.19.208.18]) by localhost (cerber.ds.pg.gda.pl [153.19.208.18]) (amavisd-new, port 10024) with ESMTP id XcuYlHWymnUt; Thu, 4 Oct 2007 17:03:51 +0200 (CEST) Received: from piorun.ds.pg.gda.pl (piorun.ds.pg.gda.pl [153.19.208.8]) by cerber.ds.pg.gda.pl (Postfix) with ESMTP id 6CCAB40095; Thu, 4 Oct 2007 17:03:51 +0200 (CEST) Received: from blysk.ds.pg.gda.pl (macro@blysk.ds.pg.gda.pl [153.19.208.6]) by piorun.ds.pg.gda.pl (8.13.8/8.13.8) with ESMTP id l94F3tEu027882; Thu, 4 Oct 2007 17:03:55 +0200 Date: Thu, 4 Oct 2007 16:03:50 +0100 (BST) From: "Maciej W. Rozycki" To: Giuseppe Sacco cc: Ralf Baechle , linux-mips@linux-mips.org Subject: Re: [PATCH] enable PCI bridges in MIPS ip32 In-Reply-To: <1191508413.10050.26.camel@scarafaggio> Message-ID: References: <20071004130318.GC28928@linux-mips.org> <1191508413.10050.26.camel@scarafaggio> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: ClamAV 0.91.2/4471/Thu Oct 4 15:22:27 2007 on piorun.ds.pg.gda.pl X-Virus-Status: Clean Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 16845 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: macro@linux-mips.org Precedence: bulk X-list: linux-mips On Thu, 4 Oct 2007, Giuseppe Sacco wrote: > I'll provide a new patch tomorrow, using inline functions instead of > macros. About the maximum number of PCI buses, I used 1 since the ip32 > only have 1 slot. If this maximum value should be changed, please let me > know. You can have more than one bridge on a card. Or if you have e.g. a PCI-HyperTransport bridge on a PCI card, then who knows what may lie beyond. In any case there is no need to do this check here and it is even harmful in the sense it just bumps the unnecessary limitation by one rather than removing it altogether -- the generic PCI code that we have in drivers/pci/ will scan the bus behind the bridge and find out whether there are any others and act accordingly. In general you need not do any range checking here, even for the root bus, unless the host bridge is broken somehow and produces unexpected behaviour when an inexistent device is accessed with a configuration cycle. Normally such a transaction should result with a Master Abort and be handled gracefully by the originating host bridge. This is not always the case, sometimes because of a flaw in hardware and sometimes because of misconfiguration -- unfortunately the quality of bootstrap firmware varies and fixing it up requires bridge-specific knowledge, which we sometimes have and use (grep for MSC01_PCI_CFG_MAXRTRY_MSK for an example), but sometimes we do not. Maciej From vagabon.xyz@gmail.com Thu Oct 4 16:04:25 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 04 Oct 2007 16:04:34 +0100 (BST) Received: from nf-out-0910.google.com ([64.233.182.185]:4539 "EHLO nf-out-0910.google.com") by ftp.linux-mips.org with ESMTP id S20026190AbXJDPEO (ORCPT ); Thu, 4 Oct 2007 16:04:14 +0100 Received: by nf-out-0910.google.com with SMTP id c10so166530nfd for ; Thu, 04 Oct 2007 08:04:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding; bh=WW9vwBbz0Appz4k7pA1LHZb3HMzywlxwBKOrlDXWZ5g=; b=PCfBb6ivYiJJuKxrWv7wNJhyUFotTlOYDqWJRA6u09oNp7rm0kGi2+jizpuk+gaVlEDBZjCurh1bQJLOxgl/cJladym8vPLfOKe2XSxigvaDRguB7r/6A9Bd6eg5s34gghrI65P6VfOogL1SLS+Ds6NIXaTLyEN882KdX44+jn0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding; b=FbYiqFLu8uHWf1jaQzIBCxI2NLAvWFZfx7NVVj5m98WUdk/LzxH489lkIOOf+X7kOIP5QxGNAGP8G0HRUGCg8Dl4zoEDnFn3rO7r9AI+Dq1cBTHjdJyYCw+UB3YAnPXBFk923gcdliwMtH6Igqg+7MiNBx3MmX4XYNtpXUhohEA= Received: by 10.86.77.5 with SMTP id z5mr1554549fga.1191510253519; Thu, 04 Oct 2007 08:04:13 -0700 (PDT) Received: from ?192.168.0.1? ( [82.235.205.153]) by mx.google.com with ESMTPS id e9sm3449273muf.2007.10.04.08.04.09 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 04 Oct 2007 08:04:11 -0700 (PDT) Message-ID: <4705004C.5000705@gmail.com> Date: Thu, 04 Oct 2007 17:01:32 +0200 From: Franck Bui-Huu User-Agent: Thunderbird 2.0.0.5 (X11/20070719) MIME-Version: 1.0 To: Ralf Baechle CC: Thiemo Seufer , "Maciej W. Rozycki" , linux-mips@linux-mips.org Subject: Re: [PATCH] mm/pg-r4k.c: Dump the generated code References: <20071002141125.GC16772@networkno.de> <20071002154918.GA11312@linux-mips.org> <47038874.9050704@gmail.com> <20071003131158.GL16772@networkno.de> <4703F155.4000301@gmail.com> <20071003201800.GP16772@networkno.de> <47049734.6050802@gmail.com> <20071004121557.GA28928@linux-mips.org> In-Reply-To: <20071004121557.GA28928@linux-mips.org> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 16846 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: vagabon.xyz@gmail.com Precedence: bulk X-list: linux-mips Ralf Baechle wrote: > On Thu, Oct 04, 2007 at 09:33:08AM +0200, Franck Bui-Huu wrote: > >> Not really, I would say it's just an idea to remove tlbex.c from the >> kernel code and to make it a tool called during compile time to >> generate a handler skeleton which would be finalized by the kernel. > > IRIX was assembling its TLB exception handler from a few such skeletons > or rather a few fractions. That works reasonably well as long as there are > not too many variants - but Linux supports about anything on earth. > Another disadvantage of the IRIX approach was that the fragments are > written in assembler but the tacking together happens in C code so the > code is split in a somewhat unnatural way over a few files. > That's what I was thinking too. It may require a lot of (ugly ?) tricks to link the whole thing together. And if the idea was previously used and showed it was inferior than what we have now, it's just a bad idea. It's just a bit sad to see my TLB handler generated at each boot and to embed the whole tlbex generator inside the kernel which is quite big: $ mipsel-linux-size arch/mips/mm/tlbex.o text data bss dec hex filename 10116 3904 1568 15588 3ce4 arch/mips/mm/tlbex.o specially if my cpu doesn't have any bugs. Maybe having, 2 default implementations in tlbex-r3k.S, tlbex-r4k.S for good cpus (the ones which needn't any fixups at all) and otherwise the tlbex.c is used. And with luck the majority of the cpus are good... OK, probably a bad idea (again) ... Thanks Franck From ralf@linux-mips.org Thu Oct 4 16:19:52 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 04 Oct 2007 16:19:54 +0100 (BST) Received: from localhost.localdomain ([127.0.0.1]:58563 "EHLO dl5rb.ham-radio-op.net") by ftp.linux-mips.org with ESMTP id S20026235AbXJDPTw (ORCPT ); Thu, 4 Oct 2007 16:19:52 +0100 Received: from denk.linux-mips.net (denk.linux-mips.net [127.0.0.1]) by dl5rb.ham-radio-op.net (8.14.1/8.13.8) with ESMTP id l94FJpxe010194; Thu, 4 Oct 2007 16:19:51 +0100 Received: (from ralf@localhost) by denk.linux-mips.net (8.14.1/8.14.1/Submit) id l94FJpaf010193; Thu, 4 Oct 2007 16:19:51 +0100 Date: Thu, 4 Oct 2007 16:19:51 +0100 From: Ralf Baechle To: Giuseppe Sacco Cc: "Maciej W. Rozycki" , linux-mips@linux-mips.org Subject: Re: [PATCH] enable PCI bridges in MIPS ip32 Message-ID: <20071004151951.GD6897@linux-mips.org> References: <20071004130318.GC28928@linux-mips.org> <1191508413.10050.26.camel@scarafaggio> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1191508413.10050.26.camel@scarafaggio> User-Agent: Mutt/1.5.14 (2007-02-12) Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 16847 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: ralf@linux-mips.org Precedence: bulk X-list: linux-mips On Thu, Oct 04, 2007 at 04:33:33PM +0200, Giuseppe Sacco wrote: > Il giorno gio, 04/10/2007 alle 14.03 +0100, Ralf Baechle ha scritto: > [...] > > (of course this all goes far beyond Giuseppe's patch - but the whole > > ops-mace.c file like so much of the other code in arch/mips/pci isn't > > exactly an example to be copied. > > > > Ah, one final formality - when sending a patch please add a > > Signed-off-by: line. See Documentation/SubmittingPatches in the kernel > > tree for what this means. > > I'll provide a new patch tomorrow, using inline functions instead of > macros. About the maximum number of PCI buses, I used 1 since the ip32 > only have 1 slot. If this maximum value should be changed, please let me > know. The entire testing done by chkslot() is probably not needed, so I suggest you try to simply dump the thing entirely and test. Ralf From macro@linux-mips.org Thu Oct 4 16:24:17 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 04 Oct 2007 16:24:25 +0100 (BST) Received: from cerber.ds.pg.gda.pl ([153.19.208.18]:24005 "EHLO cerber.ds.pg.gda.pl") by ftp.linux-mips.org with ESMTP id S20026235AbXJDPYR (ORCPT ); Thu, 4 Oct 2007 16:24:17 +0100 Received: from localhost (unknown [127.0.0.17]) by cerber.ds.pg.gda.pl (Postfix) with ESMTP id DB80E400A8; Thu, 4 Oct 2007 17:23:47 +0200 (CEST) X-Virus-Scanned: amavisd-new at cerber.ds.pg.gda.pl Received: from cerber.ds.pg.gda.pl ([153.19.208.18]) by localhost (cerber.ds.pg.gda.pl [153.19.208.18]) (amavisd-new, port 10024) with ESMTP id Q3wR2IbOty0X; Thu, 4 Oct 2007 17:23:43 +0200 (CEST) Received: from piorun.ds.pg.gda.pl (piorun.ds.pg.gda.pl [153.19.208.8]) by cerber.ds.pg.gda.pl (Postfix) with ESMTP id 9283740095; Thu, 4 Oct 2007 17:23:43 +0200 (CEST) Received: from blysk.ds.pg.gda.pl (macro@blysk.ds.pg.gda.pl [153.19.208.6]) by piorun.ds.pg.gda.pl (8.13.8/8.13.8) with ESMTP id l94FNlN8031779; Thu, 4 Oct 2007 17:23:47 +0200 Date: Thu, 4 Oct 2007 16:23:42 +0100 (BST) From: "Maciej W. Rozycki" To: Franck Bui-Huu cc: Ralf Baechle , Thiemo Seufer , linux-mips@linux-mips.org Subject: Re: [PATCH] mm/pg-r4k.c: Dump the generated code In-Reply-To: <4705004C.5000705@gmail.com> Message-ID: References: <20071002141125.GC16772@networkno.de> <20071002154918.GA11312@linux-mips.org> <47038874.9050704@gmail.com> <20071003131158.GL16772@networkno.de> <4703F155.4000301@gmail.com> <20071003201800.GP16772@networkno.de> <47049734.6050802@gmail.com> <20071004121557.GA28928@linux-mips.org> <4705004C.5000705@gmail.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: ClamAV 0.91.2/4471/Thu Oct 4 15:22:27 2007 on piorun.ds.pg.gda.pl X-Virus-Status: Clean Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 16848 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: macro@linux-mips.org Precedence: bulk X-list: linux-mips On Thu, 4 Oct 2007, Franck Bui-Huu wrote: > It's just a bit sad to see my TLB handler generated at each boot and > to embed the whole tlbex generator inside the kernel which is quite > big: > > $ mipsel-linux-size arch/mips/mm/tlbex.o > text data bss dec hex filename > 10116 3904 1568 15588 3ce4 arch/mips/mm/tlbex.o > > specially if my cpu doesn't have any bugs. Well, most systems are there to work and not to be rebooted repeatedly all the time. ;-) All of tlbex.o is discarded after bootstrap. > Maybe having, 2 default implementations in tlbex-r3k.S, tlbex-r4k.S > for good cpus (the ones which needn't any fixups at all) and otherwise > the tlbex.c is used. And with luck the majority of the cpus are > good... Well, most of the differences are not due to CPU bugs, but different cp0 hazards. The MIPS32r2 and MIPS64r2 architecture specs introduce the "ehb" and "jr.hb" instructions to sort them out, but most of the processors we support predate them. The existence of the definitions in is there so that workarounds for CPU bugs are optimised away at the kernel build time if not activated. I agree the inclusion both R3k and R4k handlers at the same time even though any configuration predetermines which of the two is only going to be needed is a bit suboptimal indeed. Maciej From macro@linux-mips.org Thu Oct 4 16:28:01 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 04 Oct 2007 16:28:10 +0100 (BST) Received: from cerber.ds.pg.gda.pl ([153.19.208.18]:21192 "EHLO cerber.ds.pg.gda.pl") by ftp.linux-mips.org with ESMTP id S20026256AbXJDP2B (ORCPT ); Thu, 4 Oct 2007 16:28:01 +0100 Received: from localhost (unknown [127.0.0.17]) by cerber.ds.pg.gda.pl (Postfix) with ESMTP id B03AE400A8; Thu, 4 Oct 2007 17:28:02 +0200 (CEST) X-Virus-Scanned: amavisd-new at cerber.ds.pg.gda.pl Received: from cerber.ds.pg.gda.pl ([153.19.208.18]) by localhost (cerber.ds.pg.gda.pl [153.19.208.18]) (amavisd-new, port 10024) with ESMTP id rxmxG2Udf8BZ; Thu, 4 Oct 2007 17:27:58 +0200 (CEST) Received: from piorun.ds.pg.gda.pl (piorun.ds.pg.gda.pl [153.19.208.8]) by cerber.ds.pg.gda.pl (Postfix) with ESMTP id A879D40095; Thu, 4 Oct 2007 17:27:58 +0200 (CEST) Received: from blysk.ds.pg.gda.pl (macro@blysk.ds.pg.gda.pl [153.19.208.6]) by piorun.ds.pg.gda.pl (8.13.8/8.13.8) with ESMTP id l94FS2Ps032729; Thu, 4 Oct 2007 17:28:02 +0200 Date: Thu, 4 Oct 2007 16:27:57 +0100 (BST) From: "Maciej W. Rozycki" To: Ralf Baechle cc: Giuseppe Sacco , linux-mips@linux-mips.org Subject: Re: [PATCH] enable PCI bridges in MIPS ip32 In-Reply-To: <20071004151951.GD6897@linux-mips.org> Message-ID: References: <20071004130318.GC28928@linux-mips.org> <1191508413.10050.26.camel@scarafaggio> <20071004151951.GD6897@linux-mips.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: ClamAV 0.91.2/4471/Thu Oct 4 15:22:27 2007 on piorun.ds.pg.gda.pl X-Virus-Status: Clean Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 16849 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: macro@linux-mips.org Precedence: bulk X-list: linux-mips On Thu, 4 Oct 2007, Ralf Baechle wrote: > The entire testing done by chkslot() is probably not needed, so I suggest > you try to simply dump the thing entirely and test. Exactly what I wrote too. :-) Though I would imagine it was introduced for a reason, like a bug in the host bridge or something, as already suggested. Otherwise what would the point have been? Maciej From ralf@linux-mips.org Thu Oct 4 16:30:09 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 04 Oct 2007 16:30:11 +0100 (BST) Received: from localhost.localdomain ([127.0.0.1]:40934 "EHLO dl5rb.ham-radio-op.net") by ftp.linux-mips.org with ESMTP id S20026288AbXJDPaJ (ORCPT ); Thu, 4 Oct 2007 16:30:09 +0100 Received: from denk.linux-mips.net (denk.linux-mips.net [127.0.0.1]) by dl5rb.ham-radio-op.net (8.14.1/8.13.8) with ESMTP id l94FU8tr010473; Thu, 4 Oct 2007 16:30:08 +0100 Received: (from ralf@localhost) by denk.linux-mips.net (8.14.1/8.14.1/Submit) id l94FU8ir010472; Thu, 4 Oct 2007 16:30:08 +0100 Date: Thu, 4 Oct 2007 16:30:08 +0100 From: Ralf Baechle To: "Maciej W. Rozycki" Cc: Franck Bui-Huu , Thiemo Seufer , linux-mips@linux-mips.org Subject: Re: [PATCH] mm/pg-r4k.c: Dump the generated code Message-ID: <20071004153008.GE6897@linux-mips.org> References: <20071002141125.GC16772@networkno.de> <20071002154918.GA11312@linux-mips.org> <47038874.9050704@gmail.com> <20071003131158.GL16772@networkno.de> <4703F155.4000301@gmail.com> <20071003201800.GP16772@networkno.de> <47049734.6050802@gmail.com> <20071004121557.GA28928@linux-mips.org> <4705004C.5000705@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.14 (2007-02-12) Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 16850 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: ralf@linux-mips.org Precedence: bulk X-list: linux-mips On Thu, Oct 04, 2007 at 04:23:42PM +0100, Maciej W. Rozycki wrote: > The existence of the definitions in is there so that > workarounds for CPU bugs are optimised away at the kernel build time if > not activated. > > I agree the inclusion both R3k and R4k handlers at the same time even > though any configuration predetermines which of the two is only going to > be needed is a bit suboptimal indeed. I guess one of the goals was to slowly clean up the stuff that forces us to have different kernels for R2000 and R4000 class TLBs. Ralf From ralf@linux-mips.org Thu Oct 4 16:32:17 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 04 Oct 2007 16:32:20 +0100 (BST) Received: from localhost.localdomain ([127.0.0.1]:59352 "EHLO dl5rb.ham-radio-op.net") by ftp.linux-mips.org with ESMTP id S20026236AbXJDPcR (ORCPT ); Thu, 4 Oct 2007 16:32:17 +0100 Received: from denk.linux-mips.net (denk.linux-mips.net [127.0.0.1]) by dl5rb.ham-radio-op.net (8.14.1/8.13.8) with ESMTP id l94FWHIA010546; Thu, 4 Oct 2007 16:32:17 +0100 Received: (from ralf@localhost) by denk.linux-mips.net (8.14.1/8.14.1/Submit) id l94FWHft010545; Thu, 4 Oct 2007 16:32:17 +0100 Date: Thu, 4 Oct 2007 16:32:17 +0100 From: Ralf Baechle To: "Maciej W. Rozycki" Cc: Giuseppe Sacco , linux-mips@linux-mips.org Subject: Re: [PATCH] enable PCI bridges in MIPS ip32 Message-ID: <20071004153217.GF6897@linux-mips.org> References: <20071004130318.GC28928@linux-mips.org> <1191508413.10050.26.camel@scarafaggio> <20071004151951.GD6897@linux-mips.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.14 (2007-02-12) Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 16851 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: ralf@linux-mips.org Precedence: bulk X-list: linux-mips On Thu, Oct 04, 2007 at 04:27:57PM +0100, Maciej W. Rozycki wrote: > On Thu, 4 Oct 2007, Ralf Baechle wrote: > > > The entire testing done by chkslot() is probably not needed, so I suggest > > you try to simply dump the thing entirely and test. > > Exactly what I wrote too. :-) Though I would imagine it was introduced > for a reason, like a bug in the host bridge or something, as already > suggested. Otherwise what would the point have been? I suspect cut-and-paste-o-mania, probably originally started by the necessity of doing so for the Galileo chips. Ralf From macro@linux-mips.org Thu Oct 4 16:36:14 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 04 Oct 2007 16:36:45 +0100 (BST) Received: from cerber.ds.pg.gda.pl ([153.19.208.18]:47840 "EHLO cerber.ds.pg.gda.pl") by ftp.linux-mips.org with ESMTP id S20026310AbXJDPgN (ORCPT ); Thu, 4 Oct 2007 16:36:13 +0100 Received: from localhost (unknown [127.0.0.17]) by cerber.ds.pg.gda.pl (Postfix) with ESMTP id 44CD2400A8; Thu, 4 Oct 2007 17:35:44 +0200 (CEST) X-Virus-Scanned: amavisd-new at cerber.ds.pg.gda.pl Received: from cerber.ds.pg.gda.pl ([153.19.208.18]) by localhost (cerber.ds.pg.gda.pl [153.19.208.18]) (amavisd-new, port 10024) with ESMTP id VwSTIO4Kfaxq; Thu, 4 Oct 2007 17:35:40 +0200 (CEST) Received: from piorun.ds.pg.gda.pl (piorun.ds.pg.gda.pl [153.19.208.8]) by cerber.ds.pg.gda.pl (Postfix) with ESMTP id 30CFA40095; Thu, 4 Oct 2007 17:35:40 +0200 (CEST) Received: from blysk.ds.pg.gda.pl (macro@blysk.ds.pg.gda.pl [153.19.208.6]) by piorun.ds.pg.gda.pl (8.13.8/8.13.8) with ESMTP id l94FZiaG001655; Thu, 4 Oct 2007 17:35:44 +0200 Date: Thu, 4 Oct 2007 16:35:39 +0100 (BST) From: "Maciej W. Rozycki" To: Ralf Baechle cc: Franck Bui-Huu , Thiemo Seufer , linux-mips@linux-mips.org Subject: Re: [PATCH] mm/pg-r4k.c: Dump the generated code In-Reply-To: <20071004153008.GE6897@linux-mips.org> Message-ID: References: <20071002141125.GC16772@networkno.de> <20071002154918.GA11312@linux-mips.org> <47038874.9050704@gmail.com> <20071003131158.GL16772@networkno.de> <4703F155.4000301@gmail.com> <20071003201800.GP16772@networkno.de> <47049734.6050802@gmail.com> <20071004121557.GA28928@linux-mips.org> <4705004C.5000705@gmail.com> <20071004153008.GE6897@linux-mips.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: ClamAV 0.91.2/4471/Thu Oct 4 15:22:27 2007 on piorun.ds.pg.gda.pl X-Virus-Status: Clean Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 16852 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: macro@linux-mips.org Precedence: bulk X-list: linux-mips On Thu, 4 Oct 2007, Ralf Baechle wrote: > > I agree the inclusion both R3k and R4k handlers at the same time even > > though any configuration predetermines which of the two is only going to > > be needed is a bit suboptimal indeed. > > I guess one of the goals was to slowly clean up the stuff that forces us > to have different kernels for R2000 and R4000 class TLBs. Well, we had a plan to support multiple systems with a "generic" kernel too; at least ones that have a compatible load address. Which would help distributions create their bootstrap disks for example. I have thought all of this got abandoned at one point, mostly due to the maintenance effort required to keep it going long-term. The Alpha port did it many years ago, but they have a compatible bootstrap environment and their number of system variations is limited, especially as compared to ours. Maciej From ralf@linux-mips.org Thu Oct 4 16:46:34 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 04 Oct 2007 16:46:38 +0100 (BST) Received: from localhost.localdomain ([127.0.0.1]:33230 "EHLO dl5rb.ham-radio-op.net") by ftp.linux-mips.org with ESMTP id S20026435AbXJDPnx (ORCPT ); Thu, 4 Oct 2007 16:43:53 +0100 Received: from denk.linux-mips.net (denk.linux-mips.net [127.0.0.1]) by dl5rb.ham-radio-op.net (8.14.1/8.13.8) with ESMTP id l94FgF5F010796; Thu, 4 Oct 2007 16:42:15 +0100 Received: (from ralf@localhost) by denk.linux-mips.net (8.14.1/8.14.1/Submit) id l94FgFmc010795; Thu, 4 Oct 2007 16:42:15 +0100 Date: Thu, 4 Oct 2007 16:42:15 +0100 From: Ralf Baechle To: "Maciej W. Rozycki" Cc: Franck Bui-Huu , Thiemo Seufer , linux-mips@linux-mips.org Subject: Re: [PATCH] mm/pg-r4k.c: Dump the generated code Message-ID: <20071004154215.GA10682@linux-mips.org> References: <47038874.9050704@gmail.com> <20071003131158.GL16772@networkno.de> <4703F155.4000301@gmail.com> <20071003201800.GP16772@networkno.de> <47049734.6050802@gmail.com> <20071004121557.GA28928@linux-mips.org> <4705004C.5000705@gmail.com> <20071004153008.GE6897@linux-mips.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.14 (2007-02-12) Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 16853 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: ralf@linux-mips.org Precedence: bulk X-list: linux-mips On Thu, Oct 04, 2007 at 04:35:39PM +0100, Maciej W. Rozycki wrote: > > > I agree the inclusion both R3k and R4k handlers at the same time even > > > though any configuration predetermines which of the two is only going to > > > be needed is a bit suboptimal indeed. > > > > I guess one of the goals was to slowly clean up the stuff that forces us > > to have different kernels for R2000 and R4000 class TLBs. > > Well, we had a plan to support multiple systems with a "generic" kernel > too; at least ones that have a compatible load address. Which would help > distributions create their bootstrap disks for example. I have thought > all of this got abandoned at one point, mostly due to the maintenance > effort required to keep it going long-term. The Alpha port did it many > years ago, but they have a compatible bootstrap environment and their > number of system variations is limited, especially as compared to ours. Anything in excessive amounts is toxic and that includes compatibility. A true MIPS generic kernel would be hard to do. But we have kernels that can support all variants of the Malta even though Malta has more CPU options than any other system. Or for your personal toy project, all DECs wouldn't be too hard either, or? Ralf From ralf@linux-mips.org Thu Oct 4 17:55:47 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 04 Oct 2007 17:55:50 +0100 (BST) Received: from localhost.localdomain ([127.0.0.1]:20962 "EHLO dl5rb.ham-radio-op.net") by ftp.linux-mips.org with ESMTP id S20026363AbXJDQzr (ORCPT ); Thu, 4 Oct 2007 17:55:47 +0100 Received: from denk.linux-mips.net (denk.linux-mips.net [127.0.0.1]) by dl5rb.ham-radio-op.net (8.14.1/8.13.8) with ESMTP id l94Gtksx026970; Thu, 4 Oct 2007 17:55:46 +0100 Received: (from ralf@localhost) by denk.linux-mips.net (8.14.1/8.14.1/Submit) id l94GtkOA026966; Thu, 4 Oct 2007 17:55:46 +0100 Date: Thu, 4 Oct 2007 17:55:46 +0100 From: Ralf Baechle To: "Maciej W. Rozycki" Cc: Giuseppe Sacco , linux-mips@linux-mips.org Subject: Re: [PATCH] enable PCI bridges in MIPS ip32 Message-ID: <20071004165546.GA23610@linux-mips.org> References: <20071004130318.GC28928@linux-mips.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.14 (2007-02-12) Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 16854 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: ralf@linux-mips.org Precedence: bulk X-list: linux-mips On Thu, Oct 04, 2007 at 03:13:01PM +0100, Maciej W. Rozycki wrote: > > I think historically we had something like chkslot() first in the code > > for the Galileo/Marvell bridges where it's needed due the brainddead > > abuse of device 31 - any access to that will crash the system. From that > > point on chkslot checking spread across the PCI code like the measles in > > a kindergarden. > > Does the Galileo/Marvell do anything else with the device #31 than what > is recommended by the PCI spec as a way to issue special cycles? We need > to be careful about the device #31 in general; it is seldom used anyway as > there are only 20 IDSEL lines defined by the standard and they are usually > mapped starting from the device #0. It's documented somewhere in their specs. Whatever, it ends crashing the system so device 31 is hands off. Ralf From macro@linux-mips.org Thu Oct 4 18:34:41 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 04 Oct 2007 18:34:50 +0100 (BST) Received: from cerber.ds.pg.gda.pl ([153.19.208.18]:50567 "EHLO cerber.ds.pg.gda.pl") by ftp.linux-mips.org with ESMTP id S20026391AbXJDRel (ORCPT ); Thu, 4 Oct 2007 18:34:41 +0100 Received: from localhost (unknown [127.0.0.17]) by cerber.ds.pg.gda.pl (Postfix) with ESMTP id 2A67340111; Thu, 4 Oct 2007 19:34:13 +0200 (CEST) X-Virus-Scanned: amavisd-new at cerber.ds.pg.gda.pl Received: from cerber.ds.pg.gda.pl ([153.19.208.18]) by localhost (cerber.ds.pg.gda.pl [153.19.208.18]) (amavisd-new, port 10024) with ESMTP id t7JIx7N7wKfX; Thu, 4 Oct 2007 19:34:05 +0200 (CEST) Received: from piorun.ds.pg.gda.pl (piorun.ds.pg.gda.pl [153.19.208.8]) by cerber.ds.pg.gda.pl (Postfix) with ESMTP id C384340095; Thu, 4 Oct 2007 19:34:05 +0200 (CEST) Received: from blysk.ds.pg.gda.pl (macro@blysk.ds.pg.gda.pl [153.19.208.6]) by piorun.ds.pg.gda.pl (8.13.8/8.13.8) with ESMTP id l94HYAxn026265; Thu, 4 Oct 2007 19:34:10 +0200 Date: Thu, 4 Oct 2007 18:34:04 +0100 (BST) From: "Maciej W. Rozycki" To: Ralf Baechle cc: Franck Bui-Huu , Thiemo Seufer , linux-mips@linux-mips.org Subject: Re: [PATCH] mm/pg-r4k.c: Dump the generated code In-Reply-To: <20071004154215.GA10682@linux-mips.org> Message-ID: References: <47038874.9050704@gmail.com> <20071003131158.GL16772@networkno.de> <4703F155.4000301@gmail.com> <20071003201800.GP16772@networkno.de> <47049734.6050802@gmail.com> <20071004121557.GA28928@linux-mips.org> <4705004C.5000705@gmail.com> <20071004153008.GE6897@linux-mips.org> <20071004154215.GA10682@linux-mips.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: ClamAV 0.91.2/4471/Thu Oct 4 15:22:27 2007 on piorun.ds.pg.gda.pl X-Virus-Status: Clean Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 16855 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: macro@linux-mips.org Precedence: bulk X-list: linux-mips On Thu, 4 Oct 2007, Ralf Baechle wrote: > Anything in excessive amounts is toxic and that includes compatibility. > A true MIPS generic kernel would be hard to do. But we have kernels that > can support all variants of the Malta even though Malta has more CPU options Have the issues been fixed? I recall there was a problem with FPU context switching which would not let a MIPS IV Malta kernel (needed for all the old QED CPU core cards) run with a MIPS32r2 core. > than any other system. Or for your personal toy project, all DECs wouldn't > be too hard either, or? The DECs should be reletively easy if we finally managed to get rid of all the 64-bit-isms in the 32-bit kernel even if built for MIPS III or above. Which, given the recent commitment to 32-bit cores is what I would actually expect. Maciej From sjhill@real.realitydiluted.com Thu Oct 4 18:39:52 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 04 Oct 2007 18:40:01 +0100 (BST) Received: from real.realitydiluted.com ([66.43.201.61]:8095 "EHLO real.realitydiluted.com") by ftp.linux-mips.org with ESMTP id S20026399AbXJDRjw (ORCPT ); Thu, 4 Oct 2007 18:39:52 +0100 Received: from sjhill by real.realitydiluted.com with local (Exim 4.67) (envelope-from ) id 1IdUfY-0008L3-S6; Thu, 04 Oct 2007 12:39:28 -0500 Date: Thu, 4 Oct 2007 12:39:28 -0500 From: "Steven J. Hill" To: veerasena reddy Cc: linux-mips , "linux-kernel.org" Subject: Re: unresoved symbol _gp_disp Message-ID: <20071004173928.GA32033@real.realitydiluted.com> References: <230962.51223.qm@web8408.mail.in.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <230962.51223.qm@web8408.mail.in.yahoo.com> User-Agent: Mutt/1.5.13 (2006-08-11) Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 16856 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: sjhill@realitydiluted.com Precedence: bulk X-list: linux-mips > I have written a loadble module ( which gets complied > along with kernel) which does some floating point > operation. > NO FLOATING POINT in the kernel PERIOD. Either use integer operations, or redo your software architecture and do the floating point in userspace. -Steve From ddaney@avtrex.com Thu Oct 4 18:47:44 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 04 Oct 2007 18:47:52 +0100 (BST) Received: from smtp1.dnsmadeeasy.com ([205.234.170.144]:33227 "EHLO smtp1.dnsmadeeasy.com") by ftp.linux-mips.org with ESMTP id S20026398AbXJDRro (ORCPT ); Thu, 4 Oct 2007 18:47:44 +0100 Received: from smtp1.dnsmadeeasy.com (localhost [127.0.0.1]) by smtp1.dnsmadeeasy.com (Postfix) with ESMTP id C265630C7E0; Thu, 4 Oct 2007 17:47:47 +0000 (UTC) X-Authenticated-Name: js.dnsmadeeasy X-Transit-System: In case of SPAM please contact abuse@dnsmadeeasy.com Received: from avtrex.com (unknown [67.116.42.147]) by smtp1.dnsmadeeasy.com (Postfix) with ESMTP; Thu, 4 Oct 2007 17:47:46 +0000 (UTC) Received: from [192.168.7.26] ([192.168.7.26]) by avtrex.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 4 Oct 2007 10:47:26 -0700 Message-ID: <4705272D.7050801@avtrex.com> Date: Thu, 04 Oct 2007 10:47:25 -0700 From: David Daney User-Agent: Thunderbird 1.5.0.12 (X11/20070719) MIME-Version: 1.0 To: "Steven J. Hill" Cc: veerasena reddy , linux-mips , "linux-kernel.org" Subject: Re: unresoved symbol _gp_disp References: <230962.51223.qm@web8408.mail.in.yahoo.com> <20071004173928.GA32033@real.realitydiluted.com> In-Reply-To: <20071004173928.GA32033@real.realitydiluted.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 04 Oct 2007 17:47:26.0092 (UTC) FILETIME=[A02514C0:01C806AE] Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 16857 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: ddaney@avtrex.com Precedence: bulk X-list: linux-mips Steven J. Hill wrote: >> I have written a loadble module ( which gets complied >> along with kernel) which does some floating point >> operation. >> > NO FLOATING POINT in the kernel PERIOD. Unless you compile your code with -msoft-float *and* also have a version of libgcc compiled with -mlong-calls -mno-abicalls -G0. If you do it that way, floating point works fine in the kernel (as long as you don't try to call sprintf with floating point parameters). > Either use integer > operations, or redo your software architecture and do the > floating point in userspace. > > -Steve > From sjhill@real.realitydiluted.com Thu Oct 4 18:50:21 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 04 Oct 2007 18:50:30 +0100 (BST) Received: from real.realitydiluted.com ([66.43.201.61]:29350 "EHLO real.realitydiluted.com") by ftp.linux-mips.org with ESMTP id S20026403AbXJDRuV (ORCPT ); Thu, 4 Oct 2007 18:50:21 +0100 Received: from sjhill by real.realitydiluted.com with local (Exim 4.67) (envelope-from ) id 1IdUsj-0008Md-VW; Thu, 04 Oct 2007 12:53:06 -0500 Date: Thu, 4 Oct 2007 12:53:05 -0500 From: "Steven J. Hill" To: David Daney Cc: "Steven J. Hill" , veerasena reddy , linux-mips Subject: Re: unresoved symbol _gp_disp Message-ID: <20071004175305.GB32033@real.realitydiluted.com> References: <230962.51223.qm@web8408.mail.in.yahoo.com> <20071004173928.GA32033@real.realitydiluted.com> <4705272D.7050801@avtrex.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4705272D.7050801@avtrex.com> User-Agent: Mutt/1.5.13 (2006-08-11) Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 16858 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: sjhill@realitydiluted.com Precedence: bulk X-list: linux-mips > Unless you compile your code with -msoft-float *and* also have a version > of libgcc compiled with -mlong-calls -mno-abicalls -G0. If you do it > that way, floating point works fine in the kernel (as long as you don't > try to call sprintf with floating point parameters). > I won't even concede that solution. It's bad practice and design to have floating point in the kernel. -Steve From ak@suse.de Thu Oct 4 19:31:06 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 04 Oct 2007 19:31:13 +0100 (BST) Received: from ns2.suse.de ([195.135.220.15]:29636 "EHLO mx2.suse.de") by ftp.linux-mips.org with ESMTP id S20026465AbXJDSbG (ORCPT ); Thu, 4 Oct 2007 19:31:06 +0100 Received: from Relay2.suse.de (mail2.suse.de [195.135.221.8]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx2.suse.de (Postfix) with ESMTP id 3B02622EBC; Thu, 4 Oct 2007 20:30:00 +0200 (CEST) To: "Steven J. Hill" Cc: veerasena reddy , linux-mips , "linux-kernel.org" Subject: Re: unresoved symbol _gp_disp References: <230962.51223.qm@web8408.mail.in.yahoo.com> <20071004173928.GA32033@real.realitydiluted.com> From: Andi Kleen Date: 04 Oct 2007 20:29:59 +0200 In-Reply-To: <20071004173928.GA32033@real.realitydiluted.com> Message-ID: Lines: 22 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.3 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 16859 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: andi@firstfloor.org Precedence: bulk X-list: linux-mips "Steven J. Hill" writes: > > I have written a loadble module ( which gets complied > > along with kernel) which does some floating point > > operation. > > > NO FLOATING POINT in the kernel PERIOD. Either use integer > operations, or redo your software architecture and do the > floating point in userspace. You can use floating point; you just have to make sure to save the FP context explicitely and disable preemption. Details on how to do this vary by architecture. The problem is that FP code typically takes often a lot of CPU time and it is quite antisocial to disable preemption for a long time because that impacts real time latency for everybody. Besides many uses can be relatively easily rewritten to fixed point. -Andi From ddaney@avtrex.com Thu Oct 4 19:33:19 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 04 Oct 2007 19:33:27 +0100 (BST) Received: from smtp1.dnsmadeeasy.com ([205.234.170.144]:40409 "EHLO smtp1.dnsmadeeasy.com") by ftp.linux-mips.org with ESMTP id S20026469AbXJDSdT (ORCPT ); Thu, 4 Oct 2007 19:33:19 +0100 Received: from smtp1.dnsmadeeasy.com (localhost [127.0.0.1]) by smtp1.dnsmadeeasy.com (Postfix) with ESMTP id DFB4D30C9D3; Thu, 4 Oct 2007 18:33:22 +0000 (UTC) X-Authenticated-Name: js.dnsmadeeasy X-Transit-System: In case of SPAM please contact abuse@dnsmadeeasy.com Received: from avtrex.com (unknown [67.116.42.147]) by smtp1.dnsmadeeasy.com (Postfix) with ESMTP; Thu, 4 Oct 2007 18:33:21 +0000 (UTC) Received: from [192.168.7.26] ([192.168.7.26]) by avtrex.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 4 Oct 2007 11:32:59 -0700 Message-ID: <470531DB.6090507@avtrex.com> Date: Thu, 04 Oct 2007 11:32:59 -0700 From: David Daney User-Agent: Thunderbird 1.5.0.12 (X11/20070719) MIME-Version: 1.0 To: "Steven J. Hill" Cc: veerasena reddy , linux-mips Subject: Re: unresoved symbol _gp_disp References: <230962.51223.qm@web8408.mail.in.yahoo.com> <20071004173928.GA32033@real.realitydiluted.com> <4705272D.7050801@avtrex.com> <20071004175305.GB32033@real.realitydiluted.com> In-Reply-To: <20071004175305.GB32033@real.realitydiluted.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 04 Oct 2007 18:32:59.0539 (UTC) FILETIME=[FD67FE30:01C806B4] Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 16860 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: ddaney@avtrex.com Precedence: bulk X-list: linux-mips Steven J. Hill wrote: >> Unless you compile your code with -msoft-float *and* also have a version >> of libgcc compiled with -mlong-calls -mno-abicalls -G0. If you do it >> that way, floating point works fine in the kernel (as long as you don't >> try to call sprintf with floating point parameters). >> > I won't even concede that solution. It's bad practice and design to have > floating point in the kernel. I agree that floating point in the kernel is bad practice. However under some circumstances, the most expedient solution does not conform to best practice. David Daney From giuseppe@eppesuigoccas.homedns.org Thu Oct 4 22:09:16 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 04 Oct 2007 22:09:24 +0100 (BST) Received: from host191-212-dynamic.8-87-r.retail.telecomitalia.it ([87.8.212.191]:35799 "EHLO eppesuigoccas.homedns.org") by ftp.linux-mips.org with ESMTP id S20026575AbXJDVJQ (ORCPT ); Thu, 4 Oct 2007 22:09:16 +0100 Received: from giuseppe by eppesuigoccas.homedns.org with local (Exim 4.63) (envelope-from ) id 1IdXwW-0004Ja-08; Thu, 04 Oct 2007 23:09:12 +0200 To: Ralf Baechle Subject: [PATCH] mips/ip32: enable PCI bridges Cc: linux-mips@linux-mips.org Message-Id: From: Giuseppe Sacco Date: Thu, 04 Oct 2007 23:09:12 +0200 Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 16861 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: giuseppe@eppesuigoccas.homedns.org Precedence: bulk X-list: linux-mips Fixes MACE PCI addressing adding the bus number parameter. Remove check of the used slot since every slot should be valid. Converted mkaddr from #define to inline function. Signed-off-by: Giuseppe Sacco --- Hi Ralf and linux-mips list, I managed to create a second patch, still against current .6.23-rc9 git tree, for supporting PCI bridges on SGI ip32 machines. It include your suggestion on moving from #define to inline. Bye, Giuseppe diff --git a/arch/mips/pci/ops-mace.c b/arch/mips/pci/ops-mace.c index 8008e31..2025f1f 100644 --- a/arch/mips/pci/ops-mace.c +++ b/arch/mips/pci/ops-mace.c @@ -29,22 +29,20 @@ * 4 N/C */ -#define chkslot(_bus,_devfn) \ -do { \ - if ((_bus)->number > 0 || PCI_SLOT (_devfn) < 1 \ - || PCI_SLOT (_devfn) > 3) \ - return PCIBIOS_DEVICE_NOT_FOUND; \ -} while (0) +static inline int mkaddr(struct pci_bus *bus, unsigned int devfn, + unsigned int reg) +{ + return ((bus->number & 0xff) << 16) | + (devfn & 0xff) << 8) | + (reg & 0xfc); +} -#define mkaddr(_devfn, _reg) \ -((((_devfn) & 0xffUL) << 8) | ((_reg) & 0xfcUL)) static int mace_pci_read_config(struct pci_bus *bus, unsigned int devfn, int reg, int size, u32 *val) { - chkslot(bus, devfn); - mace->pci.config_addr = mkaddr(devfn, reg); + mace->pci.config_addr = mkaddr(bus, devfn, reg); switch (size) { case 1: *val = mace->pci.config_data.b[(reg & 3) ^ 3]; @@ -66,8 +64,7 @@ static int mace_pci_write_config(struct pci_bus *bus, unsigned int devfn, int reg, int size, u32 val) { - chkslot(bus, devfn); - mace->pci.config_addr = mkaddr(devfn, reg); + mace->pci.config_addr = mkaddr(bus, devfn, reg); switch (size) { case 1: mace->pci.config_data.b[(reg & 3) ^ 3] = val; From giuseppe@eppesuigoccas.homedns.org Fri Oct 5 06:34:03 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 05 Oct 2007 06:34:11 +0100 (BST) Received: from host160-223-dynamic.15-87-r.retail.telecomitalia.it ([87.15.223.160]:9370 "EHLO eppesuigoccas.homedns.org") by ftp.linux-mips.org with ESMTP id S20022347AbXJEFeD (ORCPT ); Fri, 5 Oct 2007 06:34:03 +0100 Received: from localhost ([127.0.0.1] helo=sgi) by eppesuigoccas.homedns.org with smtp (Exim 4.63) (envelope-from ) id 1Idfou-000151-P8; Fri, 05 Oct 2007 07:33:54 +0200 Date: Fri, 5 Oct 2007 07:33:49 +0200 From: Giuseppe Sacco To: Ralf Baechle Cc: "Maciej W. Rozycki" , linux-mips@linux-mips.org Subject: Re: [PATCH] enable PCI bridges in MIPS ip32 Message-Id: <20071005073349.4a95ac75.giuseppe@eppesuigoccas.homedns.org> In-Reply-To: <20071004153217.GF6897@linux-mips.org> References: <20071004130318.GC28928@linux-mips.org> <1191508413.10050.26.camel@scarafaggio> <20071004151951.GD6897@linux-mips.org> <20071004153217.GF6897@linux-mips.org> X-Mailer: Sylpheed version 2.3.0beta5 (GTK+ 2.8.20; mips-unknown-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 16862 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: giuseppe@eppesuigoccas.homedns.org Precedence: bulk X-list: linux-mips On Thu, 4 Oct 2007 16:32:17 +0100 Ralf Baechle wrote: > On Thu, Oct 04, 2007 at 04:27:57PM +0100, Maciej W. Rozycki wrote: > > On Thu, 4 Oct 2007, Ralf Baechle wrote: > > > The entire testing done by chkslot() is probably not needed, so I suggest > > > you try to simply dump the thing entirely and test. > > > > Exactly what I wrote too. :-) Though I would imagine it was introduced > > for a reason, like a bug in the host bridge or something, as already > > suggested. Otherwise what would the point have been? > > I suspect cut-and-paste-o-mania, probably originally started by the > necessity of doing so for the Galileo chips. After removing the chkslot() call, I get these errors when booting: [...] SCSI subsystem initialized MACEPCI: Master abort at 0x00000000 (C) MACEPCI: Master abort at 0x00008000 (C) MACEPCI: Master abort at 0x00010000 (C) MACEPCI: Master abort at 0x00020000 (C) MACEPCI: Master abort at 0x00000000 (C) MACEPCI: Master abort at 0x00000000 (C) MACEPCI: Master abort at 0x00000000 (C) MACEPCI: Master abort at 0x00000000 (C) MACEPCI: Master abort at 0x00000000 (C) MACEPCI: Master abort at 0x00000000 (C) MACEPCI: Master abort at 0x00000000 (C) MACEPCI: Master abort at 0x00000000 (C) MACEPCI: Master abort at 0x00000000 (C) MACEPCI: Master abort at 0x00000000 (C) MACEPCI: Master abort at 0x00000000 (C) MACEPCI: Master abort at 0x00000000 (C) MACEPCI: Master abort at 0x00000000 (C) MACEPCI: Master abort at 0x00000000 (C) MACEPCI: Master abort at 0x00000000 (C) MACEPCI: Master abort at 0x00000000 (C) MACEPCI: Master abort at 0x00000000 (C) MACEPCI: Master abort at 0x00000000 (C) MACEPCI: Master abort at 0x00000000 (C) MACEPCI: Master abort at 0x00000000 (C) MACEPCI: Master abort at 0x00000000 (C) MACEPCI: Master abort at 0x00000000 (C) MACEPCI: Master abort at 0x00000000 (C) MACEPCI: Master abort at 0x00000000 (C) MACEPCI: Master abort at 0x00000000 (C) PCI: Bridge: 0000:00:03.0 IO window: 1000-1fff MEM window: 80000000-800fffff PREFETCH window: 80100000-801fffff PCI: Enabling device 0000:00:03.0 (0000 -> 0003) [...] It seems all probes to devfn=0 fails. There is even a call on bus=2, that I really don't understand. the current lspci output is: 00:01.0 SCSI storage controller: Adaptec AIC-7880U 00:02.0 SCSI storage controller: Adaptec AIC-7880U 00:03.0 PCI bridge: NetMos Technology Unknown device 9250 (rev 01) 01:08.0 USB Controller: NEC Corporation USB (rev 43) 01:08.1 USB Controller: NEC Corporation USB (rev 43) 01:08.2 USB Controller: NEC Corporation USB 2.0 (rev 04) 01:09.0 FireWire (IEEE 1394): Agere Systems FW323 (rev 61) 01:0a.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL-8169 Gigabit Ethernet (rev 10) So probably, the test was correct. Should I restore the same check or only check for devfn==0? Bye, Giueppe From vagabon.xyz@gmail.com Fri Oct 5 09:04:13 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 05 Oct 2007 09:04:21 +0100 (BST) Received: from nf-out-0910.google.com ([64.233.182.186]:38611 "EHLO nf-out-0910.google.com") by ftp.linux-mips.org with ESMTP id S20023400AbXJEIEN (ORCPT ); Fri, 5 Oct 2007 09:04:13 +0100 Received: by nf-out-0910.google.com with SMTP id c10so368840nfd for ; Fri, 05 Oct 2007 01:03:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding; bh=qf2OZ+ojxHJa5g4iqPXY3ldH/5iWER/ReDlCpN5YiW4=; b=Gkjir32f8jtH9Iz0OrxV739i4uwZcbRdDDEB7JdqOg011S9zgUxlkukUOx3v/Rc1XyJuPJLXBY1mQNs4xtnikL2JcPzUDgZalEXX8i6wsuojH61cU5CR91DZOua4LoxjG5oED0oMBbYCqDngvkV1volo1RsE7XvHdu5UDW/FDlA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding; b=W5t4TbPFd70ncXMApXZ3ITxj0jk+fn9rD5VarW5dIcVZ+7BZ4s0HYOW3Wknlw888Vz6EegxMxKBKfTLP6LB+PKa4uQ+XsjqmenR2kDZO+tWjHkEdK83VAxqBAiCLy8kNkDCV9OzWb9Dm/A516Pr29KzJTTysKl3T6ziE4Kf+yDI= Received: by 10.86.62.3 with SMTP id k3mr2245479fga.1191571435220; Fri, 05 Oct 2007 01:03:55 -0700 (PDT) Received: from ?192.168.0.1? ( [82.235.205.153]) by mx.google.com with ESMTPS id f31sm4979063fkf.2007.10.05.01.03.53 (version=TLSv1/SSLv3 cipher=RC4-MD5); Fri, 05 Oct 2007 01:03:54 -0700 (PDT) Message-ID: <4705EFE5.7090704@gmail.com> Date: Fri, 05 Oct 2007 10:03:49 +0200 From: Franck Bui-Huu User-Agent: Thunderbird 2.0.0.5 (X11/20070719) MIME-Version: 1.0 To: "Maciej W. Rozycki" CC: Ralf Baechle , Thiemo Seufer , linux-mips@linux-mips.org Subject: Re: [PATCH] mm/pg-r4k.c: Dump the generated code References: <20071002141125.GC16772@networkno.de> <20071002154918.GA11312@linux-mips.org> <47038874.9050704@gmail.com> <20071003131158.GL16772@networkno.de> <4703F155.4000301@gmail.com> <20071003201800.GP16772@networkno.de> <47049734.6050802@gmail.com> <20071004121557.GA28928@linux-mips.org> <4705004C.5000705@gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 16863 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: vagabon.xyz@gmail.com Precedence: bulk X-list: linux-mips Maciej W. Rozycki wrote: > On Thu, 4 Oct 2007, Franck Bui-Huu wrote: > >> It's just a bit sad to see my TLB handler generated at each boot and >> to embed the whole tlbex generator inside the kernel which is quite >> big: >> >> $ mipsel-linux-size arch/mips/mm/tlbex.o >> text data bss dec hex filename >> 10116 3904 1568 15588 3ce4 arch/mips/mm/tlbex.o >> >> specially if my cpu doesn't have any bugs. > > Well, most systems are there to work and not to be rebooted repeatedly > all the time. ;-) All of tlbex.o is discarded after bootstrap. > Yes, but some systems out there have some constraints on their boot time and others have ones on their persistent storage device size. >> Maybe having, 2 default implementations in tlbex-r3k.S, tlbex-r4k.S >> for good cpus (the ones which needn't any fixups at all) and otherwise >> the tlbex.c is used. And with luck the majority of the cpus are >> good... > > Well, most of the differences are not due to CPU bugs, but different cp0 > hazards. The MIPS32r2 and MIPS64r2 architecture specs introduce the "ehb" > and "jr.hb" instructions to sort them out, but most of the processors we > support predate them. > > The existence of the definitions in is there so that > workarounds for CPU bugs are optimised away at the kernel build time if > not activated. > Just to be sure I haven't missed anything, it seems that we _could_ generate the whole tlb handler at compile time since the CPU type is known at that time, no need to have any fixups at runtime, isn't it ? Franck From geert@linux-m68k.org Fri Oct 5 10:09:41 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 05 Oct 2007 10:09:51 +0100 (BST) Received: from adicia.telenet-ops.be ([195.130.132.56]:61926 "EHLO adicia.telenet-ops.be") by ftp.linux-mips.org with ESMTP id S20026952AbXJEJJl (ORCPT ); Fri, 5 Oct 2007 10:09:41 +0100 Received: from localhost (localhost.localdomain [127.0.0.1]) by adicia.telenet-ops.be (Postfix) with SMTP id 4C6792300C1; Fri, 5 Oct 2007 11:09:41 +0200 (CEST) Received: from anakin.of.borg (d54C15D55.access.telenet.be [84.193.93.85]) by adicia.telenet-ops.be (Postfix) with ESMTP id 059DF2300E9; Fri, 5 Oct 2007 11:09:40 +0200 (CEST) Received: from anakin.of.borg (geert@localhost [127.0.0.1]) by anakin.of.borg (8.14.1/8.14.1/Debian-9) with ESMTP id l9599eJX032425 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 5 Oct 2007 11:09:40 +0200 Received: from localhost (geert@localhost) by anakin.of.borg (8.14.1/8.14.1/Submit) with ESMTP id l9599e4F032422; Fri, 5 Oct 2007 11:09:40 +0200 X-Authentication-Warning: anakin.of.borg: geert owned process doing -bs Date: Fri, 5 Oct 2007 11:09:40 +0200 (CEST) From: Geert Uytterhoeven To: Franck Bui-Huu Cc: "Maciej W. Rozycki" , Ralf Baechle , Thiemo Seufer , linux-mips@linux-mips.org Subject: Re: [PATCH] mm/pg-r4k.c: Dump the generated code In-Reply-To: <4705EFE5.7090704@gmail.com> Message-ID: References: <20071002141125.GC16772@networkno.de> <20071002154918.GA11312@linux-mips.org> <47038874.9050704@gmail.com> <20071003131158.GL16772@networkno.de> <4703F155.4000301@gmail.com> <20071003201800.GP16772@networkno.de> <47049734.6050802@gmail.com> <20071004121557.GA28928@linux-mips.org> <4705004C.5000705@gmail.com> <4705EFE5.7090704@gmail.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 16864 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: geert@linux-m68k.org Precedence: bulk X-list: linux-mips On Fri, 5 Oct 2007, Franck Bui-Huu wrote: > Maciej W. Rozycki wrote: > > On Thu, 4 Oct 2007, Franck Bui-Huu wrote: > > > >> It's just a bit sad to see my TLB handler generated at each boot and > >> to embed the whole tlbex generator inside the kernel which is quite > >> big: > >> > >> $ mipsel-linux-size arch/mips/mm/tlbex.o > >> text data bss dec hex filename > >> 10116 3904 1568 15588 3ce4 arch/mips/mm/tlbex.o > >> > >> specially if my cpu doesn't have any bugs. > > > > Well, most systems are there to work and not to be rebooted repeatedly > > all the time. ;-) All of tlbex.o is discarded after bootstrap. > > > > Yes, but some systems out there have some constraints on their boot time > and others have ones on their persistent storage device size. > > >> Maybe having, 2 default implementations in tlbex-r3k.S, tlbex-r4k.S > >> for good cpus (the ones which needn't any fixups at all) and otherwise > >> the tlbex.c is used. And with luck the majority of the cpus are > >> good... > > > > Well, most of the differences are not due to CPU bugs, but different cp0 > > hazards. The MIPS32r2 and MIPS64r2 architecture specs introduce the "ehb" > > and "jr.hb" instructions to sort them out, but most of the processors we > > support predate them. > > > > The existence of the definitions in is there so that > > workarounds for CPU bugs are optimised away at the kernel build time if > > not activated. > > Just to be sure I haven't missed anything, it seems that we _could_ generate > the whole tlb handler at compile time since the CPU type is known at that > time, no need to have any fixups at runtime, isn't it ? For specialized systems, you can always introduce the option to generate the TLB handler at compile time: - Enhance tlbex.c to be able to compile it for the host, and generate a fixed TLB handler, based on CONFIG_* options, if CONFIG_STATIC_TLB_HANDLER (buried deep in depends on EMBEDDED && ADVANCED && I_KNOW_WHAT_I_AM_DOING) is set. - Let the dynamic runtime generator print the required CONFIG_* options for the system it runs on, so you know which one to set in your .config (a bit like calibrate_delay() prints the lpj=N value to pass to avoid calibrating the delay loop) Gr{oetje,eeting}s, Geert -- Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say "programmer" or something like that. -- Linus Torvalds From ralf@linux-mips.org Fri Oct 5 11:52:13 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 05 Oct 2007 11:52:15 +0100 (BST) Received: from localhost.localdomain ([127.0.0.1]:18821 "EHLO dl5rb.ham-radio-op.net") by ftp.linux-mips.org with ESMTP id S20027168AbXJEKwN (ORCPT ); Fri, 5 Oct 2007 11:52:13 +0100 Received: from denk.linux-mips.net (denk.linux-mips.net [127.0.0.1]) by dl5rb.ham-radio-op.net (8.14.1/8.13.8) with ESMTP id l95AqBdP002216; Fri, 5 Oct 2007 11:52:11 +0100 Received: (from ralf@localhost) by denk.linux-mips.net (8.14.1/8.14.1/Submit) id l95Aq9Uk002215; Fri, 5 Oct 2007 11:52:09 +0100 Date: Fri, 5 Oct 2007 11:52:09 +0100 From: Ralf Baechle To: Andi Kleen Cc: "Steven J. Hill" , veerasena reddy , linux-mips , "linux-kernel.org" Subject: Re: unresoved symbol _gp_disp Message-ID: <20071005105209.GB1404@linux-mips.org> References: <230962.51223.qm@web8408.mail.in.yahoo.com> <20071004173928.GA32033@real.realitydiluted.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.14 (2007-02-12) Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 16865 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: ralf@linux-mips.org Precedence: bulk X-list: linux-mips On Thu, Oct 04, 2007 at 08:29:59PM +0200, Andi Kleen wrote: > From: Andi Kleen > Date: 04 Oct 2007 20:29:59 +0200 > To: "Steven J. Hill" > Cc: veerasena reddy , > linux-mips , > "linux-kernel.org" > Subject: Re: unresoved symbol _gp_disp > Content-Type: text/plain; charset=us-ascii > > "Steven J. Hill" writes: > > > > I have written a loadble module ( which gets complied > > > along with kernel) which does some floating point > > > operation. > > > > > NO FLOATING POINT in the kernel PERIOD. Either use integer > > operations, or redo your software architecture and do the > > floating point in userspace. > > You can use floating point; you just have to make sure to > save the FP context explicitely and disable preemption. Details > on how to do this vary by architecture. > > The problem is that FP code typically takes often a lot of CPU time > and it is quite antisocial to disable preemption for a long time > because that impacts real time latency for everybody. > > Besides many uses can be relatively easily rewritten to fixed > point. He said he was using software floating point which from a kernel perspective really just is integer stuff anyway. Hardware floating point in a MIPS kernel would be require solving a few interesting problems; the kernel floating point assist software is only designed to support userspace. Or alternativle well written FP code that avoids all the corner cases which would normally be handled by the kernel fp software. The biggest argument against floating point use in the kernel is that most of the time it's an indicator for poor division of work between kernel and userspace. Ralf From ralf@linux-mips.org Fri Oct 5 12:51:53 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 05 Oct 2007 12:51:56 +0100 (BST) Received: from localhost.localdomain ([127.0.0.1]:62100 "EHLO dl5rb.ham-radio-op.net") by ftp.linux-mips.org with ESMTP id S20027228AbXJELvx (ORCPT ); Fri, 5 Oct 2007 12:51:53 +0100 Received: from denk.linux-mips.net (denk.linux-mips.net [127.0.0.1]) by dl5rb.ham-radio-op.net (8.14.1/8.13.8) with ESMTP id l95Bppeg019142; Fri, 5 Oct 2007 12:51:51 +0100 Received: (from ralf@localhost) by denk.linux-mips.net (8.14.1/8.14.1/Submit) id l95Bppds019131; Fri, 5 Oct 2007 12:51:51 +0100 Date: Fri, 5 Oct 2007 12:51:51 +0100 From: Ralf Baechle To: Franck Bui-Huu Cc: Thiemo Seufer , "Maciej W. Rozycki" , linux-mips@linux-mips.org Subject: Re: [PATCH] mm/pg-r4k.c: Dump the generated code Message-ID: <20071005115151.GA16145@linux-mips.org> References: <20071002141125.GC16772@networkno.de> <20071002154918.GA11312@linux-mips.org> <47038874.9050704@gmail.com> <20071003131158.GL16772@networkno.de> <4703F155.4000301@gmail.com> <20071003201800.GP16772@networkno.de> <47049734.6050802@gmail.com> <20071004121557.GA28928@linux-mips.org> <4705004C.5000705@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4705004C.5000705@gmail.com> User-Agent: Mutt/1.5.14 (2007-02-12) Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 16866 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: ralf@linux-mips.org Precedence: bulk X-list: linux-mips On Thu, Oct 04, 2007 at 05:01:32PM +0200, Franck Bui-Huu wrote: (Hitting the send key now so nobody notices I wrote this email at 3am ;-) > It's just a bit sad to see my TLB handler generated at each boot and > to embed the whole tlbex generator inside the kernel which is quite > big: > > $ mipsel-linux-size arch/mips/mm/tlbex.o > text data bss dec hex filename > 10116 3904 1568 15588 3ce4 arch/mips/mm/tlbex.o > > specially if my cpu doesn't have any bugs. So I did a few experiments. This is the size of tlbex for a malta_defconfig build with gcc 4.2.1: text data bss dec hex filename 10468 3904 1568 15940 3e44 arch/mips/mm/tlbex.o After replacing current_cpu_data.cputype with a new macro current_cpu_type that expands to the constant CPU type value, I picked CPU_4KC: text data bss dec hex filename 6088 3904 1568 11560 2d28 arch/mips/mm/tlbex.o And after also changing r45k_bvahwbug, r4k_250MHZhwbug, bcm1250_m3_war, r10000_llsc_war and m4kc_tlbp_war into inline functions: text data bss dec hex filename 5608 3904 1568 11080 2b48 arch/mips/mm/tlbex.o So I applied the inlining change to the queue tree and came up with a generalized version of the current_cpu_type. This are the sizes I get for a malta kernel without and with hardwiring the CPU type to 4Kc: text data bss dec hex filename 3273876 142324 140944 3557144 364718 vmlinux 3267048 142324 140944 3550316 362c6c vmlinux 6828 bytes isn't totally amazing but since the optimization is reasonable clean I'm going to queue this one also. Ralf From macro@linux-mips.org Fri Oct 5 12:54:06 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 05 Oct 2007 12:54:16 +0100 (BST) Received: from cerber.ds.pg.gda.pl ([153.19.208.18]:50609 "EHLO cerber.ds.pg.gda.pl") by ftp.linux-mips.org with ESMTP id S20027229AbXJELyG (ORCPT ); Fri, 5 Oct 2007 12:54:06 +0100 Received: from localhost (unknown [127.0.0.17]) by cerber.ds.pg.gda.pl (Postfix) with ESMTP id 28C53400CD; Fri, 5 Oct 2007 13:54:07 +0200 (CEST) X-Virus-Scanned: amavisd-new at cerber.ds.pg.gda.pl Received: from cerber.ds.pg.gda.pl ([153.19.208.18]) by localhost (cerber.ds.pg.gda.pl [153.19.208.18]) (amavisd-new, port 10024) with ESMTP id J0zcmgbW69np; Fri, 5 Oct 2007 13:53:58 +0200 (CEST) Received: from piorun.ds.pg.gda.pl (piorun.ds.pg.gda.pl [153.19.208.8]) by cerber.ds.pg.gda.pl (Postfix) with ESMTP id 0AF6E40095; Fri, 5 Oct 2007 13:53:58 +0200 (CEST) Received: from blysk.ds.pg.gda.pl (macro@blysk.ds.pg.gda.pl [153.19.208.6]) by piorun.ds.pg.gda.pl (8.13.8/8.13.8) with ESMTP id l95Bs0Sl002637; Fri, 5 Oct 2007 13:54:00 +0200 Date: Fri, 5 Oct 2007 12:53:56 +0100 (BST) From: "Maciej W. Rozycki" To: Giuseppe Sacco cc: Ralf Baechle , linux-mips@linux-mips.org Subject: Re: [PATCH] enable PCI bridges in MIPS ip32 In-Reply-To: <20071005073349.4a95ac75.giuseppe@eppesuigoccas.homedns.org> Message-ID: References: <20071004130318.GC28928@linux-mips.org> <1191508413.10050.26.camel@scarafaggio> <20071004151951.GD6897@linux-mips.org> <20071004153217.GF6897@linux-mips.org> <20071005073349.4a95ac75.giuseppe@eppesuigoccas.homedns.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: ClamAV 0.91.2/4475/Fri Oct 5 10:56:58 2007 on piorun.ds.pg.gda.pl X-Virus-Status: Clean Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 16867 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: macro@linux-mips.org Precedence: bulk X-list: linux-mips On Fri, 5 Oct 2007, Giuseppe Sacco wrote: > After removing the chkslot() call, I get these errors when booting: > [...] > SCSI subsystem initialized > MACEPCI: Master abort at 0x00000000 (C) > MACEPCI: Master abort at 0x00008000 (C) > MACEPCI: Master abort at 0x00010000 (C) [...] Well, these are not errors in this context even though they seem to be reported as such -- these Master Aborts are expected to happen for non occupied slots (device numbers). And reporting them to the user in this context seems silly (unless debugging). I can see the are coming from the MACE error interrupt handler -- either the Master-Abort interrupt should be masked for the duration of the configuration space access or, if impossible or the way to do so is unknown, the handler should recognise the context and silently ack the interrupt and pass the error up somehow. It is up to code handling the host bridge in question to get it right -- see arch/mips/pci/ops-bonito64.c for an example. > PCI: Bridge: 0000:00:03.0 > IO window: 1000-1fff > MEM window: 80000000-800fffff > PREFETCH window: 80100000-801fffff > PCI: Enabling device 0000:00:03.0 (0000 -> 0003) > [...] > > It seems all probes to devfn=0 fails. There is even a call on bus=2, > that I really don't understand. the current lspci output is: Well, perhaps the initial setup of the PCI-to-PCI bridge reports the subordinate bus to be 2 or something. If you post the whole PCI probe log, someone may be able to provide an explanation. And devfn=0 failing probably means the host bridge does not want to report itself in the PCI configuration space; that is a valid approach (seen with the Alphas too, for example), although personally I do not like it very much. > So probably, the test was correct. Should I restore the same check or > only check for devfn==0? The handling of Master Aborts should be fixed instead. It looks like MACEPCI_CONTROL_MAR_INT might be the right mask bit -- do we have a spec for the chip anywhere or is the only source? Maciej From macro@linux-mips.org Fri Oct 5 13:10:41 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 05 Oct 2007 13:10:50 +0100 (BST) Received: from cerber.ds.pg.gda.pl ([153.19.208.18]:59786 "EHLO cerber.ds.pg.gda.pl") by ftp.linux-mips.org with ESMTP id S20021515AbXJEMKl (ORCPT ); Fri, 5 Oct 2007 13:10:41 +0100 Received: from localhost (unknown [127.0.0.17]) by cerber.ds.pg.gda.pl (Postfix) with ESMTP id 46A5B400CD; Fri, 5 Oct 2007 14:10:42 +0200 (CEST) X-Virus-Scanned: amavisd-new at cerber.ds.pg.gda.pl Received: from cerber.ds.pg.gda.pl ([153.19.208.18]) by localhost (cerber.ds.pg.gda.pl [153.19.208.18]) (amavisd-new, port 10024) with ESMTP id NA7PDFyOvYot; Fri, 5 Oct 2007 14:10:33 +0200 (CEST) Received: from piorun.ds.pg.gda.pl (piorun.ds.pg.gda.pl [153.19.208.8]) by cerber.ds.pg.gda.pl (Postfix) with ESMTP id D0F2740095; Fri, 5 Oct 2007 14:10:33 +0200 (CEST) Received: from blysk.ds.pg.gda.pl (macro@blysk.ds.pg.gda.pl [153.19.208.6]) by piorun.ds.pg.gda.pl (8.13.8/8.13.8) with ESMTP id l95CAaiF004885; Fri, 5 Oct 2007 14:10:36 +0200 Date: Fri, 5 Oct 2007 13:10:33 +0100 (BST) From: "Maciej W. Rozycki" To: Ralf Baechle cc: Giuseppe Sacco , linux-mips@linux-mips.org Subject: Re: [PATCH] enable PCI bridges in MIPS ip32 In-Reply-To: <20071004165546.GA23610@linux-mips.org> Message-ID: References: <20071004130318.GC28928@linux-mips.org> <20071004165546.GA23610@linux-mips.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: ClamAV 0.91.2/4475/Fri Oct 5 10:56:58 2007 on piorun.ds.pg.gda.pl X-Virus-Status: Clean Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 16868 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: macro@linux-mips.org Precedence: bulk X-list: linux-mips On Thu, 4 Oct 2007, Ralf Baechle wrote: > It's documented somewhere in their specs. Whatever, it ends crashing > the system so device 31 is hands off. OK, found it -- it is the GT-64120A erratum FEr#19 leading to a hang of the device; perhaps we should mention it briefly in the source code. While the PCI spec says reads from the device #31, function #7 for host bridges implementing the recommended special cycle generation mechanism have undefined results, this behaviour is certainly "undefined" in a very silly way and then, according to the spec, it must not happen for the function #0, which is the only one probed by Linux by default for single-function devices. Maciej From ralf@linux-mips.org Fri Oct 5 13:18:43 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 05 Oct 2007 13:18:46 +0100 (BST) Received: from localhost.localdomain ([127.0.0.1]:41102 "EHLO dl5rb.ham-radio-op.net") by ftp.linux-mips.org with ESMTP id S20021857AbXJEMSn (ORCPT ); Fri, 5 Oct 2007 13:18:43 +0100 Received: from denk.linux-mips.net (denk.linux-mips.net [127.0.0.1]) by dl5rb.ham-radio-op.net (8.14.1/8.13.8) with ESMTP id l95CIgdk022302; Fri, 5 Oct 2007 13:18:42 +0100 Received: (from ralf@localhost) by denk.linux-mips.net (8.14.1/8.14.1/Submit) id l95CIfoq022301; Fri, 5 Oct 2007 13:18:41 +0100 Date: Fri, 5 Oct 2007 13:18:41 +0100 From: Ralf Baechle To: David Daney Cc: "Steven J. Hill" , veerasena reddy , linux-mips Subject: Re: unresoved symbol _gp_disp Message-ID: <20071005121841.GC1404@linux-mips.org> References: <230962.51223.qm@web8408.mail.in.yahoo.com> <20071004173928.GA32033@real.realitydiluted.com> <4705272D.7050801@avtrex.com> <20071004175305.GB32033@real.realitydiluted.com> <470531DB.6090507@avtrex.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <470531DB.6090507@avtrex.com> User-Agent: Mutt/1.5.14 (2007-02-12) Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 16869 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: ralf@linux-mips.org Precedence: bulk X-list: linux-mips On Thu, Oct 04, 2007 at 11:32:59AM -0700, David Daney wrote: > Steven J. Hill wrote: > >>Unless you compile your code with -msoft-float *and* also have a version > >>of libgcc compiled with -mlong-calls -mno-abicalls -G0. If you do it > >>that way, floating point works fine in the kernel (as long as you don't > >>try to call sprintf with floating point parameters). > >> > >I won't even concede that solution. It's bad practice and design to have > >floating point in the kernel. > > I agree that floating point in the kernel is bad practice. However > under some circumstances, the most expedient solution does not conform > to best practice. I also feel deeply unfriendly if I send somebody along a path that's full of interesting corner cases ... Ralf From macro@linux-mips.org Fri Oct 5 13:19:30 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 05 Oct 2007 13:19:39 +0100 (BST) Received: from cerber.ds.pg.gda.pl ([153.19.208.18]:53945 "EHLO cerber.ds.pg.gda.pl") by ftp.linux-mips.org with ESMTP id S20021874AbXJEMTa (ORCPT ); Fri, 5 Oct 2007 13:19:30 +0100 Received: from localhost (unknown [127.0.0.17]) by cerber.ds.pg.gda.pl (Postfix) with ESMTP id 51FE7400CD; Fri, 5 Oct 2007 14:19:31 +0200 (CEST) X-Virus-Scanned: amavisd-new at cerber.ds.pg.gda.pl Received: from cerber.ds.pg.gda.pl ([153.19.208.18]) by localhost (cerber.ds.pg.gda.pl [153.19.208.18]) (amavisd-new, port 10024) with ESMTP id rc5TSeooEPfI; Fri, 5 Oct 2007 14:19:24 +0200 (CEST) Received: from piorun.ds.pg.gda.pl (piorun.ds.pg.gda.pl [153.19.208.8]) by cerber.ds.pg.gda.pl (Postfix) with ESMTP id E37B5400E7; Fri, 5 Oct 2007 14:19:17 +0200 (CEST) Received: from blysk.ds.pg.gda.pl (macro@blysk.ds.pg.gda.pl [153.19.208.6]) by piorun.ds.pg.gda.pl (8.13.8/8.13.8) with ESMTP id l95CJKHv006666; Fri, 5 Oct 2007 14:19:20 +0200 Date: Fri, 5 Oct 2007 13:19:17 +0100 (BST) From: "Maciej W. Rozycki" To: Franck Bui-Huu cc: Ralf Baechle , Thiemo Seufer , linux-mips@linux-mips.org Subject: Re: [PATCH] mm/pg-r4k.c: Dump the generated code In-Reply-To: <4705EFE5.7090704@gmail.com> Message-ID: References: <20071002141125.GC16772@networkno.de> <20071002154918.GA11312@linux-mips.org> <47038874.9050704@gmail.com> <20071003131158.GL16772@networkno.de> <4703F155.4000301@gmail.com> <20071003201800.GP16772@networkno.de> <47049734.6050802@gmail.com> <20071004121557.GA28928@linux-mips.org> <4705004C.5000705@gmail.com> <4705EFE5.7090704@gmail.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: ClamAV 0.91.2/4475/Fri Oct 5 10:56:58 2007 on piorun.ds.pg.gda.pl X-Virus-Status: Clean Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 16870 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: macro@linux-mips.org Precedence: bulk X-list: linux-mips On Fri, 5 Oct 2007, Franck Bui-Huu wrote: > Just to be sure I haven't missed anything, it seems that we _could_ generate > the whole tlb handler at compile time since the CPU type is known at that > time, no need to have any fixups at runtime, isn't it ? The exact CPU type is not known at the moment. For example CPU_R4X00 and CPU_MIPS32_R1 cover whole ranges that have subtle differences. It may be possible to provide all the variations as a selection to the user, but it may be unfeasible -- I don't know. Compare what we have in arch/mips/Kconfig with . Maciej From ralf@linux-mips.org Fri Oct 5 13:21:24 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 05 Oct 2007 13:21:26 +0100 (BST) Received: from localhost.localdomain ([127.0.0.1]:62904 "EHLO dl5rb.ham-radio-op.net") by ftp.linux-mips.org with ESMTP id S20022005AbXJEMVY (ORCPT ); Fri, 5 Oct 2007 13:21:24 +0100 Received: from denk.linux-mips.net (denk.linux-mips.net [127.0.0.1]) by dl5rb.ham-radio-op.net (8.14.1/8.13.8) with ESMTP id l95CLM84022371; Fri, 5 Oct 2007 13:21:22 +0100 Received: (from ralf@localhost) by denk.linux-mips.net (8.14.1/8.14.1/Submit) id l95CLMqO022370; Fri, 5 Oct 2007 13:21:22 +0100 Date: Fri, 5 Oct 2007 13:21:22 +0100 From: Ralf Baechle To: Giuseppe Sacco Cc: linux-mips@linux-mips.org Subject: Re: [PATCH] mips/ip32: enable PCI bridges Message-ID: <20071005122122.GA22239@linux-mips.org> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.14 (2007-02-12) Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 16871 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: ralf@linux-mips.org Precedence: bulk X-list: linux-mips On Thu, Oct 04, 2007 at 11:09:12PM +0200, Giuseppe Sacco wrote: > Fixes MACE PCI addressing adding the bus number parameter. > Remove check of the used slot since every slot should be valid. > Converted mkaddr from #define to inline function. > > Signed-off-by: Giuseppe Sacco Thanks, applied. Ralf From ralf@linux-mips.org Fri Oct 5 13:25:45 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 05 Oct 2007 13:25:47 +0100 (BST) Received: from localhost.localdomain ([127.0.0.1]:20922 "EHLO dl5rb.ham-radio-op.net") by ftp.linux-mips.org with ESMTP id S20022065AbXJEMZp (ORCPT ); Fri, 5 Oct 2007 13:25:45 +0100 Received: from denk.linux-mips.net (denk.linux-mips.net [127.0.0.1]) by dl5rb.ham-radio-op.net (8.14.1/8.13.8) with ESMTP id l95CPiLF022536; Fri, 5 Oct 2007 13:25:44 +0100 Received: (from ralf@localhost) by denk.linux-mips.net (8.14.1/8.14.1/Submit) id l95CPhtd022535; Fri, 5 Oct 2007 13:25:43 +0100 Date: Fri, 5 Oct 2007 13:25:43 +0100 From: Ralf Baechle To: Giuseppe Sacco Cc: linux-mips@linux-mips.org Subject: Re: kernel bug using 2.6.23-rc9 Message-ID: <20071005122543.GB22239@linux-mips.org> References: <1191502153.10050.15.camel@scarafaggio> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1191502153.10050.15.camel@scarafaggio> User-Agent: Mutt/1.5.14 (2007-02-12) Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 16872 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: ralf@linux-mips.org Precedence: bulk X-list: linux-mips On Thu, Oct 04, 2007 at 02:49:13PM +0200, Giuseppe Sacco wrote: > Hi, while testing the latest kernel on SGI O2 I got may kernel bugs like > this: > > Kernel bug detected[#9]: > Cpu 0 > $ 0 : 0000000000000000 ffffffff9001fce0 0000000000000001 0000000000000f18 > $ 4 : 980000000111b4b8 000000007f955f18 ffffffff80400000 0000000000003fff > $ 8 : 00000000000050f1 000000007f955f18 9800000006073d68 9800000006073d60 > $12 : 0000000000000010 ffffffff80000008 ffffffff80091680 0000000000000000 > $16 : 980000000111b4b8 980000000768ddd0 000000000000000e 000000007f955f18 > $20 : 9800000000581908 9800000007898080 9800000006073d68 9800000006073d60 > $24 : 0000000000478284 000000002ac30580 > $28 : 9800000006070000 9800000006073cd0 0000000000000000 ffffffff8001b390 > Hi : 000000000000f2d3 > Lo : 00000000000050f1 > epc : ffffffff8001c800 kmap_coherent+0x10/0x118 Tainted: G D > ra : ffffffff8001b390 __flush_anon_page+0x70/0x90 Very interesting. Can you describe me your setup or maybe even come up with a test case for this? Ralf From macro@linux-mips.org Fri Oct 5 13:28:04 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 05 Oct 2007 13:28:13 +0100 (BST) Received: from cerber.ds.pg.gda.pl ([153.19.208.18]:31386 "EHLO cerber.ds.pg.gda.pl") by ftp.linux-mips.org with ESMTP id S20022072AbXJEM2E (ORCPT ); Fri, 5 Oct 2007 13:28:04 +0100 Received: from localhost (unknown [127.0.0.17]) by cerber.ds.pg.gda.pl (Postfix) with ESMTP id 4BE53400CD; Fri, 5 Oct 2007 14:27:35 +0200 (CEST) X-Virus-Scanned: amavisd-new at cerber.ds.pg.gda.pl Received: from cerber.ds.pg.gda.pl ([153.19.208.18]) by localhost (cerber.ds.pg.gda.pl [153.19.208.18]) (amavisd-new, port 10024) with ESMTP id hpcDpU4LTP3W; Fri, 5 Oct 2007 14:27:27 +0200 (CEST) Received: from piorun.ds.pg.gda.pl (piorun.ds.pg.gda.pl [153.19.208.8]) by cerber.ds.pg.gda.pl (Postfix) with ESMTP id 58AA940095; Fri, 5 Oct 2007 14:27:27 +0200 (CEST) Received: from blysk.ds.pg.gda.pl (macro@blysk.ds.pg.gda.pl [153.19.208.6]) by piorun.ds.pg.gda.pl (8.13.8/8.13.8) with ESMTP id l95CRTvt008670; Fri, 5 Oct 2007 14:27:29 +0200 Date: Fri, 5 Oct 2007 13:27:26 +0100 (BST) From: "Maciej W. Rozycki" To: Ralf Baechle cc: Giuseppe Sacco , linux-mips@linux-mips.org Subject: Re: [PATCH] enable PCI bridges in MIPS ip32 In-Reply-To: Message-ID: References: <20071004130318.GC28928@linux-mips.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: ClamAV 0.91.2/4475/Fri Oct 5 10:56:58 2007 on piorun.ds.pg.gda.pl X-Virus-Status: Clean Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 16873 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: macro@linux-mips.org Precedence: bulk X-list: linux-mips On Thu, 4 Oct 2007, Maciej W. Rozycki wrote: > to be careful about the device #31 in general; it is seldom used anyway as > there are only 20 IDSEL lines defined by the standard and they are usually > mapped starting from the device #0. Just to correct myself not to confuse anybody -- there are actually 21 IDSEL lines which map from bits 31:11 of the address provided for Type 0 configuration access cycles -- at most one bit from that range is ever set for such cycles. The issuing bridge is free to set no bits for device numbers it has no assigned IDSEL line for; such transactions will never be claimed by any device and thus will always terminate with Master-Abort. Maciej From ddaney@avtrex.com Fri Oct 5 16:58:04 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 05 Oct 2007 16:58:14 +0100 (BST) Received: from smtp1.dnsmadeeasy.com ([205.234.170.144]:65217 "EHLO smtp1.dnsmadeeasy.com") by ftp.linux-mips.org with ESMTP id S20024220AbXJEP6E (ORCPT ); Fri, 5 Oct 2007 16:58:04 +0100 Received: from smtp1.dnsmadeeasy.com (localhost [127.0.0.1]) by smtp1.dnsmadeeasy.com (Postfix) with ESMTP id A6724309C66; Fri, 5 Oct 2007 15:57:38 +0000 (UTC) X-Authenticated-Name: js.dnsmadeeasy X-Transit-System: In case of SPAM please contact abuse@dnsmadeeasy.com Received: from avtrex.com (unknown [67.116.42.147]) by smtp1.dnsmadeeasy.com (Postfix) with ESMTP; Fri, 5 Oct 2007 15:57:38 +0000 (UTC) Received: from [192.168.7.26] ([192.168.7.26]) by avtrex.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 5 Oct 2007 08:57:25 -0700 Message-ID: <47065EE4.8030402@avtrex.com> Date: Fri, 05 Oct 2007 08:57:24 -0700 From: David Daney User-Agent: Thunderbird 1.5.0.12 (X11/20070719) MIME-Version: 1.0 To: Ralf Baechle Cc: Giuseppe Sacco , linux-mips@linux-mips.org Subject: Re: kernel bug using 2.6.23-rc9 References: <1191502153.10050.15.camel@scarafaggio> <20071005122543.GB22239@linux-mips.org> In-Reply-To: <20071005122543.GB22239@linux-mips.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 05 Oct 2007 15:57:25.0814 (UTC) FILETIME=[6C7C5560:01C80768] Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 16874 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: ddaney@avtrex.com Precedence: bulk X-list: linux-mips Ralf Baechle wrote: > On Thu, Oct 04, 2007 at 02:49:13PM +0200, Giuseppe Sacco wrote: > >> Hi, while testing the latest kernel on SGI O2 I got may kernel bugs like >> this: >> >> Kernel bug detected[#9]: >> Cpu 0 >> $ 0 : 0000000000000000 ffffffff9001fce0 0000000000000001 0000000000000f18 >> $ 4 : 980000000111b4b8 000000007f955f18 ffffffff80400000 0000000000003fff >> $ 8 : 00000000000050f1 000000007f955f18 9800000006073d68 9800000006073d60 >> $12 : 0000000000000010 ffffffff80000008 ffffffff80091680 0000000000000000 >> $16 : 980000000111b4b8 980000000768ddd0 000000000000000e 000000007f955f18 >> $20 : 9800000000581908 9800000007898080 9800000006073d68 9800000006073d60 >> $24 : 0000000000478284 000000002ac30580 >> $28 : 9800000006070000 9800000006073cd0 0000000000000000 ffffffff8001b390 >> Hi : 000000000000f2d3 >> Lo : 00000000000050f1 >> epc : ffffffff8001c800 kmap_coherent+0x10/0x118 Tainted: G D >> ra : ffffffff8001b390 __flush_anon_page+0x70/0x90 > > Very interesting. Can you describe me your setup or maybe even come up > with a test case for this? > Perhaps: 'cat /proc/self/cmdline' As we were hacking O_DIRECT support into 2.6.15, I found what seems like a very similar situation. It seems that all users of get_user_pages() *except* /proc/*/[cmdline|environ] call get_user_pages() with addresses aligned on page boundaries. I am not sure if that is the problem here, but it seems similar. David Daney. From giuseppe@eppesuigoccas.homedns.org Sat Oct 6 08:08:17 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Sat, 06 Oct 2007 08:08:25 +0100 (BST) Received: from host160-223-dynamic.15-87-r.retail.telecomitalia.it ([87.15.223.160]:40405 "EHLO eppesuigoccas.homedns.org") by ftp.linux-mips.org with ESMTP id S20022156AbXJFHIR (ORCPT ); Sat, 6 Oct 2007 08:08:17 +0100 Received: from localhost ([127.0.0.1] helo=sgi) by eppesuigoccas.homedns.org with smtp (Exim 4.63) (envelope-from ) id 1Ie3li-0000Zb-OH for linux-mips@linux-mips.org; Sat, 06 Oct 2007 09:08:12 +0200 Date: Sat, 6 Oct 2007 09:08:09 +0200 From: Giuseppe Sacco To: linux-mips@linux-mips.org Subject: Re: kernel bug using 2.6.23-rc9 Message-Id: <20071006090809.bb738bab.giuseppe@eppesuigoccas.homedns.org> In-Reply-To: <20071005122543.GB22239@linux-mips.org> References: <1191502153.10050.15.camel@scarafaggio> <20071005122543.GB22239@linux-mips.org> X-Mailer: Sylpheed version 2.3.0beta5 (GTK+ 2.8.20; mips-unknown-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 16875 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: giuseppe@eppesuigoccas.homedns.org Precedence: bulk X-list: linux-mips On Fri, 5 Oct 2007 13:25:43 +0100 Ralf Baechle wrote: > On Thu, Oct 04, 2007 at 02:49:13PM +0200, Giuseppe Sacco wrote: > > > Hi, while testing the latest kernel on SGI O2 I got may kernel bugs like > > this: [...] > Very interesting. Can you describe me your setup or maybe even come up > with a test case for this? I may reproduce it without problems. The failing command is "ps aux". Once the command starts, the kernel log the bug and the command stay blocked: no shell prompt, no control-c working. Since the ps command does not work, I cannot check the prosess status :-) This is a new log: Code: 0002127a 00021000 30420001 <00028036> 8f820024 00052b3a 24420001 af820024 3c0236db Kernel bug detected[#2]: Cpu 0 $ 0 : 0000000000000000 ffffffff804a0000 0000000000000001 0000000000002f18 $ 4 : 980000000101cff8 000000007f94bf18 000000007f94bf18 6800000000000000 $ 8 : 0000000000000849 000000007f94bf18 980000000461bd68 980000000461bd60 $12 : 0000000000000010 ffffffff80000008 ffffffff800a3810 0000000000000000 $16 : 980000000101cff8 98000000035a3dd0 000000000000000e 000000007f94bf18 $20 : 98000000005d4048 9800000000506360 980000000461bd68 980000000461bd60 $24 : 0000000000000000 000000002abcc580 $28 : 9800000004618000 980000000461bcd0 0000000000000000 ffffffff8001da30 Hi : 00000000000018db Lo : 0000000000000849 epc : ffffffff8001f1e0 kmap_coherent+0x10/0x128 Tainted: G D ra : ffffffff8001da30 __flush_anon_page+0x90/0xc0 Status: 9001fce3 KX SX UX KERNEL EXL IE Cause : 00000034 PrId : 00002321 Modules linked in: parport_pc lp parport ppp_deflate zlib_deflate bsd_comp ppp_async crc_ccitt ip_tables x_table s ipv6 ppp_generic slhc dm_snapshot dm_mirror dm_mod ehci_hcd ohci_hcd r8169 usbcore sg evdev Process pidof (pid: 26867, threadinfo=9800000004618000, task=9800000001ea4cc8) Stack : ffffffff80089844 ffffffff80089424 0000000000000010 0000000000000000 0000000000000001 980000000461bd68 980000000461bd60 0000000000000000 9800000000506360 000000007f94bf18 9800000005dfb000 000000000000000f 9800000000506360 0000000000000000 98000000005d4048 980000000461bd68 9800000000000000 ffffffff80089a0c 0000000000000000 980000000101cff8 98000000005063c0 9800000005dfb000 9800000000506360 9800000005dfb000 000000000000000f 0000000000000000 98000000005d4048 980000000461be88 0000000000001000 000000007ff77c40 000000007ff77b40 ffffffff800f82f8 9800000005dfb000 98000000005d4048 fffffffffffffff4 98000000078516d8 0000000000000400 980000000461be88 000000002aac0000 ffffffff800faaec ... Call Trace: [] kmap_coherent+0x10/0x128 [] __flush_anon_page+0x90/0xc0 [] get_user_pages+0x49c/0x538 [] access_process_vm+0x12c/0x228 [] proc_pid_cmdline+0xa8/0x170 [] proc_info_read+0x13c/0x180 [] vfs_read+0xf0/0x190 [] sys_read+0x4c/0x90 [] handle_sys+0x134/0x150 Code: 0002127a 00021000 30420001 <00028036> 8f820024 00052b3a 24420001 af820024 3c0236db In order to collect more information, I tried "strace ps aux". The last lines printed are: stat("/proc/313", {st_mode=S_IFDIR|0555, st_size=0, ...}) = 0 open("/proc/313/stat", O_RDONLY) = 6 read(6, "313 (kjournald) S 2 0 0 0 -1 328"..., 1023) = 157 close(6) = 0 open("/proc/313/status", O_RDONLY) = 6 read(6, "Name:\tkjournald\nState:\tS (sleepi"..., 1023) = 489 close(6) = 0 open("/proc/313/cmdline", O_RDONLY) = 6 read(6, "", 2047) = 0 close(6) = 0 stat64(0x2aca5318, 0x7fd6e228) = 0 write(1, "root 313 0.0 0.0 0 "..., 77root 313 0.0 0.0 0 0 ? S< Oct05 0:15 [kjournald] ) = 77 stat("/proc/422", {st_mode=S_IFDIR|0555, st_size=0, ...}) = 0 open("/proc/422/stat", O_RDONLY) = 6 read(6, "422 (udevd) D 1 422 422 0 -1 420"..., 1023) = 217 close(6) = 0 open("/proc/422/status", O_RDONLY) = 6 read(6, "Name:\tudevd\nState:\tD (disk sleep"..., 1023) = 677 close(6) = 0 open("/proc/422/cmdline", O_RDONLY) = 6 From giuseppe@eppesuigoccas.homedns.org Sat Oct 6 18:58:15 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Sat, 06 Oct 2007 18:58:24 +0100 (BST) Received: from host79-217-dynamic.0-79-r.retail.telecomitalia.it ([79.0.217.79]:42936 "EHLO eppesuigoccas.homedns.org") by ftp.linux-mips.org with ESMTP id S20025923AbXJFR6P (ORCPT ); Sat, 6 Oct 2007 18:58:15 +0100 Received: from giuseppe by eppesuigoccas.homedns.org with local (Exim 4.63) (envelope-from ) id 1IeDrj-0002u6-2B; Sat, 06 Oct 2007 19:55:03 +0200 To: Ralf Baechle Subject: [PATCH]v2 mips/ip32: enable PCI bridges Cc: linux-mips@linux-mips.org Message-Id: From: Giuseppe Sacco Date: Sat, 06 Oct 2007 19:55:03 +0200 Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 16876 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: giuseppe@eppesuigoccas.homedns.org Precedence: bulk X-list: linux-mips Correct a typo in previous patch. Signed-off-by: Giuseppe Sacco --- Hi Ralf and linux-mips list, I recompiled the kernel once again, after having update my git repository and figured out an error in my previous patch. This should fix it. Bye, Giuseppe diff --git a/arch/mips/pci/ops-mace.c b/arch/mips/pci/ops-mace.c index 2025f1f..fe54514 100644 --- a/arch/mips/pci/ops-mace.c +++ b/arch/mips/pci/ops-mace.c @@ -33,7 +33,7 @@ static inline int mkaddr(struct pci_bus *bus, unsigned int devfn, unsigned int reg) { return ((bus->number & 0xff) << 16) | - (devfn & 0xff) << 8) | + ((devfn & 0xff) << 8) | (reg & 0xfc); } From ralf@linux-mips.org Sat Oct 6 22:27:22 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Sat, 06 Oct 2007 22:27:24 +0100 (BST) Received: from localhost.localdomain ([127.0.0.1]:62654 "EHLO dl5rb.ham-radio-op.net") by ftp.linux-mips.org with ESMTP id S20026432AbXJFV1W (ORCPT ); Sat, 6 Oct 2007 22:27:22 +0100 Received: from denk.linux-mips.net (denk.linux-mips.net [127.0.0.1]) by dl5rb.ham-radio-op.net (8.14.1/8.13.8) with ESMTP id l96LRLwB004770; Sat, 6 Oct 2007 22:27:21 +0100 Received: (from ralf@localhost) by denk.linux-mips.net (8.14.1/8.14.1/Submit) id l96LRKOY004769; Sat, 6 Oct 2007 22:27:20 +0100 Date: Sat, 6 Oct 2007 22:27:20 +0100 From: Ralf Baechle To: Giuseppe Sacco Cc: linux-mips@linux-mips.org Subject: Re: [PATCH]v2 mips/ip32: enable PCI bridges Message-ID: <20071006212720.GA4091@linux-mips.org> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.14 (2007-02-12) Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 16877 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: ralf@linux-mips.org Precedence: bulk X-list: linux-mips On Sat, Oct 06, 2007 at 07:55:03PM +0200, Giuseppe Sacco wrote: > Correct a typo in previous patch. Okay, applied. Thanks, Ralf From tanzy@gmx.de Sun Oct 7 00:52:11 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Sun, 07 Oct 2007 00:52:19 +0100 (BST) Received: from mail.gmx.net ([213.165.64.20]:19414 "HELO mail.gmx.net") by ftp.linux-mips.org with SMTP id S20028963AbXJFXwL (ORCPT ); Sun, 7 Oct 2007 00:52:11 +0100 Received: (qmail invoked by alias); 06 Oct 2007 23:51:05 -0000 Received: from p548B08F8.dip0.t-ipconnect.de (EHLO [192.168.120.22]) [84.139.8.248] by mail.gmx.net (mp032) with SMTP; 07 Oct 2007 01:51:05 +0200 X-Authenticated: #16080105 X-Provags-ID: V01U2FsdGVkX18YId5DHHkYrWQ/lnvNwUANaUV/REfwHzHFIZhiih hYZv7DXNsBAiOz Message-ID: <47081F68.2030907@gmx.de> Date: Sun, 07 Oct 2007 01:51:04 +0200 From: Johannes Dickgreber User-Agent: Thunderbird 1.5.0.12 (X11/20060911) MIME-Version: 1.0 To: linux-mips@linux-mips.org Subject: [PATCH] On a SGI Octane not all ARCS Memory if freed for kernel use X-Enigmail-Version: 0.95.2 Content-Type: multipart/mixed; boundary="------------040404070406020901070209" X-Y-GMX-Trusted: 0 Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 16878 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: tanzy@gmx.de Precedence: bulk X-list: linux-mips This is a multi-part message in MIME format. --------------040404070406020901070209 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Hi Only tested on a SGI Octane, i dont know if it works on JAZZ SNI_RM or SGI O2. It frees only 60KB. There is an ARCMemoryRegisterDump in the attached file. Signed-off-by: Johannes Dickgreber tanzy@gmx.de --- On a SGI Octane not all ARCS Memory is freed for kernel use --- linux-2.6.22.6/arch/mips/arc/memory.c 2007-07-09 01:32:17 +0200 +++ linux-octane-2/arch/mips/arc/memory.c 2007-10-06 22:04:07 +0200 @@ -70,11 +70,11 @@ static inline int memtype_classify_arcs case arcs_free: return BOOT_MEM_RAM; case arcs_atmp: + case arcs_prog: return BOOT_MEM_ROM_DATA; case arcs_eblock: case arcs_rvpage: case arcs_bmem: - case arcs_prog: case arcs_aperm: return BOOT_MEM_RESERVED; default: @@ -90,11 +90,11 @@ static inline int memtype_classify_arc ( case arc_fcontig: return BOOT_MEM_RAM; case arc_atmp: + case arc_prog: return BOOT_MEM_ROM_DATA; case arc_eblock: case arc_rvpage: case arc_bmem: - case arc_prog: case arc_aperm: return BOOT_MEM_RESERVED; default: --------------040404070406020901070209 Content-Type: text/plain; name="ARC_MEMORY.msg" Content-Transfer-Encoding: base64 Content-Disposition: inline; filename="ARC_MEMORY.msg" T2N0ICA1IDEzOjU3OjMxIHJhY2VyIExpbnV4IHZlcnNpb24gMi42LjIyLW9jdGFuZS0yIChy b290QHJhY2VyKSAoZ2NjIHZlcnNpb24gNC4xLjEgKEdlbnRvbyA0LjEuMS1yMyBwMS4xMCkp ICMxMSBGcmkgT2N0IDUgMTM6NTQ6NTIgQ0VTVCAyMDA3Ck9jdCAgNSAxMzo1NzozMSByYWNl ciBBUkNIOiBTR0ktSVAzMApPY3QgIDUgMTM6NTc6MzEgcmFjZXIgUFJPTUxJQjogQVJDIGZp cm13YXJlIFZlcnNpb24gNjQgUmV2aXNpb24gMApPY3QgIDUgMTM6NTc6MzEgcmFjZXIgQVJD UyBNRU1PUlkgREVTQ1JJUFRPUiBkdW1wOgpPY3QgIDUgMTM6NTc6MzEgcmFjZXIgWzAsYTgw MDAwMDAyMGYzMmM5MF06IGJhc2U8MDAwMDAwMDA+IHBhZ2VzPDAwMDAwMDAxPiB0eXBlPEV4 Y2VwdGlvbiBCbG9jaz4KT2N0ICA1IDEzOjU3OjMxIHJhY2VyIFsxLGE4MDAwMDAwMjBmMzJk MTBdOiBiYXNlPDAwMDAwMDAxPiBwYWdlczwwMDAwMDAwMT4gdHlwZTxBUkNTIFJvbXZlYyBQ YWdlPgpPY3QgIDUgMTM6NTc6MzEgcmFjZXIgWzIsYTgwMDAwMDAyMGYzMmNkMF06IGJhc2U8 MDAwMDAwMDI+IHBhZ2VzPDAwMDAwMDAyPiB0eXBlPEFSQ1MgUGVybWFuZW50IFN0b3JhZ2Ug QXJlYT4KT2N0ICA1IDEzOjU3OjMxIHJhY2VyIFszLGE4MDAwMDAwMjBmMzJhMTBdOiBiYXNl PDAwMDIwMDA0PiBwYWdlczwwMDAwMGVmYz4gdHlwZTxHZW5lcmljIEZyZWUgUkFNPgpPY3Qg IDUgMTM6NTc6MzEgcmFjZXIgWzQsYTgwMDAwMDAyMGYzNGExMF06IGJhc2U8MDAwMjBmMDA+ IHBhZ2VzPDAwMDAwMTAwPiB0eXBlPEFSQ1MgVGVtcCBTdG9yYWdlIEFyZWE+Ck9jdCAgNSAx Mzo1NzozMSByYWNlciBbNSxhODAwMDAwMDIwZjM0OWQwXTogYmFzZTwwMDAyMTAwMD4gcGFn ZXM8MDAwM2VmZjA+IHR5cGU8R2VuZXJpYyBGcmVlIFJBTT4KT2N0ICA1IDEzOjU3OjMxIHJh Y2VyIFs2LGE4MDAwMDAwMjBmMzRiZDBdOiBiYXNlPDAwMDVmZmYwPiBwYWdlczwwMDAwMDAw Zj4gdHlwZTxTdGFuZGFsb25lIFByb2dyYW0gUGFnZXM+Ck9jdCAgNSAxMzo1NzozMSByYWNl ciBbNyxhODAwMDAwMDIwZjM0YjkwXTogYmFzZTwwMDA1ZmZmZj4gcGFnZXM8MDAwMDAwMDE+ IHR5cGU8R2VuZXJpYyBGcmVlIFJBTT4KT2N0ICA1IDEzOjU3OjMxIHJhY2VyIENQVSByZXZp c2lvbiBpczogMDAwMDBlMjMKT2N0ICA1IDEzOjU3OjMxIHJhY2VyIEZQVSByZXZpc2lvbiBp czogMDAwMDA5MDAKT2N0ICA1IDEzOjU3OjMxIHJhY2VyIFNpbGljb24gR3JhcGhpY3MgT2N0 YW5lIChJUDMwKSBzdXBwb3J0OiAoYykgMjAwNC0yMDA3IFN0YW5pc2xhdyBTa293cm9uZWsu Ck9jdCAgNSAxMzo1NzozMSByYWNlciBEZXRlY3RlZCAxMDI0IE1CIG9mIHBoeXNpY2FsIG1l bW9yeS4KT2N0ICA1IDEzOjU3OjMxIHJhY2VyIERldGVybWluZWQgcGh5c2ljYWwgUkFNIG1h cDoKT2N0ICA1IDEzOjU3OjMxIHJhY2VyIG1lbW9yeTogMDAwMDAwMDAwMDAwNDAwMCBAIDAw MDAwMDAwMDAwMDAwMDAgKHJlc2VydmVkKQpPY3QgIDUgMTM6NTc6MzEgcmFjZXIgbWVtb3J5 OiAwMDAwMDAwMDAwZWZjMDAwIEAgMDAwMDAwMDAyMDAwNDAwMCAodXNhYmxlKQpPY3QgIDUg MTM6NTc6MzEgcmFjZXIgbWVtb3J5OiAwMDAwMDAwMDAwMTAwMDAwIEAgMDAwMDAwMDAyMGYw MDAwMCAoUk9NIGRhdGEpCk9jdCAgNSAxMzo1NzozMSByYWNlciBtZW1vcnk6IDAwMDAwMDAw M2VmZjAwMDAgQCAwMDAwMDAwMDIxMDAwMDAwICh1c2FibGUpCk9jdCAgNSAxMzo1NzozMSBy YWNlciBtZW1vcnk6IDAwMDAwMDAwMDAwMGYwMDAgQCAwMDAwMDAwMDVmZmYwMDAwIChyZXNl cnZlZCkKT2N0ICA1IDEzOjU3OjMxIHJhY2VyIG1lbW9yeTogMDAwMDAwMDAwMDAwMTAwMCBA IDAwMDAwMDAwNWZmZmYwMDAgKHVzYWJsZSkKT2N0ICA1IDEzOjU3OjMxIHJhY2VyIFdhc3Rp bmcgNzM0MDI1NiBieXRlcyBmb3IgdHJhY2tpbmcgMTMxMDc2IHVudXNlZCBwYWdlcwpPY3Qg IDUgMTM6NTc6MzEgcmFjZXIgT24gbm9kZSAwIHRvdGFscGFnZXM6IDM5MzIxNgpPY3QgIDUg MTM6NTc6MzEgcmFjZXIgRE1BIHpvbmU6IDUzNzYgcGFnZXMgdXNlZCBmb3IgbWVtbWFwCk9j dCAgNSAxMzo1NzozMSByYWNlciBETUEgem9uZTogMCBwYWdlcyByZXNlcnZlZApPY3QgIDUg MTM6NTc6MzEgcmFjZXIgRE1BIHpvbmU6IDM4Nzg0MCBwYWdlcywgTElGTyBiYXRjaDozMQpP Y3QgIDUgMTM6NTc6MzEgcmFjZXIgTm9ybWFsIHpvbmU6IDAgcGFnZXMgdXNlZCBmb3IgbWVt bWFwCk9jdCAgNSAxMzo1NzozMSByYWNlciBCdWlsdCAxIHpvbmVsaXN0cy4gIFRvdGFsIHBh Z2VzOiAzODc4NDAK --------------040404070406020901070209-- From ralf@linux-mips.org Sun Oct 7 00:55:00 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Sun, 07 Oct 2007 00:55:02 +0100 (BST) Received: from localhost.localdomain ([127.0.0.1]:51426 "EHLO dl5rb.ham-radio-op.net") by ftp.linux-mips.org with ESMTP id S20029011AbXJFXzA (ORCPT ); Sun, 7 Oct 2007 00:55:00 +0100 Received: from denk.linux-mips.net (denk.linux-mips.net [127.0.0.1]) by dl5rb.ham-radio-op.net (8.14.1/8.13.8) with ESMTP id l96NsuZN014533; Sun, 7 Oct 2007 00:54:56 +0100 Received: (from ralf@localhost) by denk.linux-mips.net (8.14.1/8.14.1/Submit) id l96NstDD014532; Sun, 7 Oct 2007 00:54:55 +0100 Date: Sun, 7 Oct 2007 00:54:55 +0100 From: Ralf Baechle To: Giuseppe Sacco Cc: linux-mips@linux-mips.org Subject: Re: kernel bug using 2.6.23-rc9 Message-ID: <20071006235455.GA14319@linux-mips.org> References: <1191502153.10050.15.camel@scarafaggio> <20071005122543.GB22239@linux-mips.org> <20071006090809.bb738bab.giuseppe@eppesuigoccas.homedns.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20071006090809.bb738bab.giuseppe@eppesuigoccas.homedns.org> User-Agent: Mutt/1.5.14 (2007-02-12) Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 16879 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: ralf@linux-mips.org Precedence: bulk X-list: linux-mips On Sat, Oct 06, 2007 at 09:08:09AM +0200, Giuseppe Sacco wrote: > I may reproduce it without problems. The failing command is "ps aux". Once the command starts, the kernel log the bug and the command stay blocked: no shell prompt, no control-c working. Since the ps command does not work, I cannot check the prosess status :-) ps does a few very specific things in the memory managment. So that's probably already all the information I need to deal with this one, thanks! Ralf From tanzy@gmx.de Sun Oct 7 20:37:46 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Sun, 07 Oct 2007 20:37:55 +0100 (BST) Received: from mail.gmx.net ([213.165.64.20]:19618 "HELO mail.gmx.net") by ftp.linux-mips.org with SMTP id S20024178AbXJGThq (ORCPT ); Sun, 7 Oct 2007 20:37:46 +0100 Received: (qmail invoked by alias); 07 Oct 2007 19:37:40 -0000 Received: from p548B21B5.dip0.t-ipconnect.de (EHLO [192.168.120.22]) [84.139.33.181] by mail.gmx.net (mp056) with SMTP; 07 Oct 2007 21:37:40 +0200 X-Authenticated: #16080105 X-Provags-ID: V01U2FsdGVkX19HcSlVM+5HxdRveiAcSyc09W5Ig8wnXG3QlwWDTX olc5qZvLhNukPS Message-ID: <47093583.6010407@gmx.de> Date: Sun, 07 Oct 2007 21:37:39 +0200 From: Johannes Dickgreber User-Agent: Thunderbird 1.5.0.12 (X11/20060911) MIME-Version: 1.0 To: Ralf Baechle CC: Kumba , linux-mips@linux-mips.org Subject: [PATCH] arch/mips/pci/ioc3.c X-Enigmail-Version: 0.95.2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 16880 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: tanzy@gmx.de Precedence: bulk X-list: linux-mips Hi I tried to use the mainline ioc3 meta driver with my Octane and got it working. But i needed to change a dual_irq test, which i think would not work with ia64. Maybe this is a solution. This is a Patch against the MIPS version. It does the job on my Octane Signed-off-by: Johannes Dickgreber tanzy@gmx.de --- Changed: Ethernet submodule is always submodule NR 0 expected in subdrivers if idd->active[id] is 1 ioc3_submodules[id] is a valid ioc3_submodule In the ethernet submodule ioc3_submodules[0]->intr is a valid interrupt routine In other submodules, if ioc3_submodules[id]->irq_mask is set ioc3_submodules[id]->intr is a valid interrupt routine kmalloc to kzalloc all IRQ are cleared in the probe routine --- linux-2.6.22.6-mips20070902-ip30/arch/mips/pci/ioc3.c 2007-09-12 21:54:59 +0200 +++ linux-octane-2/arch/mips/pci/ioc3.c 2007-10-07 20:34:37 +0200 @@ -26,8 +26,9 @@ static LIST_HEAD(ioc3_devices); static int ioc3_counter; static DECLARE_RWSEM(ioc3_devices_rwsem); +/* ethernet submodule is always 0 */ +#define ETH_ID 0 static struct ioc3_submodule *ioc3_submodules[IOC3_MAX_SUBMODULES]; -static struct ioc3_submodule *ioc3_ethernet; static DEFINE_RWLOCK(ioc3_submodules_lock); @@ -426,30 +427,29 @@ static irqreturn_t ioc3_intr_io(int irq, { unsigned long flags; struct ioc3_driver_data *idd = (struct ioc3_driver_data *)arg; - int handled = 1, id; + int handled = 0, id; unsigned int pending; read_lock_irqsave(&ioc3_submodules_lock, flags); - - if (!idd->dual_irq && readb(idd->vma->eisr)) /* send Ethernet IRQ to the driver */ - if (ioc3_ethernet && idd->active[ioc3_ethernet->id] && - ioc3_ethernet->intr) - handled = handled && !ioc3_ethernet->intr(ioc3_ethernet, - idd, 0); - - pending = get_pending_intrs(idd); /* look at the IO IRQs */ - for (id = 0; id < IOC3_MAX_SUBMODULES; id++) - if (idd->active[id] && ioc3_submodules[id] && - (pending & ioc3_submodules[id]->irq_mask) && - ioc3_submodules[id]->intr) - { - write_ireg(idd, ioc3_submodules[id]->irq_mask, IOC3_W_IEC); - if (!ioc3_submodules[id]->intr(ioc3_submodules[id], idd, - (pending & - ioc3_submodules[id]->irq_mask))) - pending &=~ ioc3_submodules[id]->irq_mask; - write_ireg(idd, ioc3_submodules[id]->irq_mask, IOC3_W_IES); - } + /* send Ethernet IRQ to the driver */ + if (idd->active[ETH_ID] && !idd->dual_irq) + if (readl(&idd->vma->eisr)) + handled = !ioc3_submodules[ETH_ID]->intr(ioc3_submodules[ETH_ID], idd, 0); + + /* look at the IO IRQs */ + pending = get_pending_intrs(idd); + for (id = 1; id < IOC3_MAX_SUBMODULES; id++) + if (idd->active[id]) + if (pending & ioc3_submodules[id]->irq_mask) { + write_ireg(idd, ioc3_submodules[id]->irq_mask, IOC3_W_IEC); + if (!ioc3_submodules[id]->intr(ioc3_submodules[id], idd, + (pending & + ioc3_submodules[id]->irq_mask))) { + pending &= ~ioc3_submodules[id]->irq_mask; + handled = 1; + } + write_ireg(idd, ioc3_submodules[id]->irq_mask, IOC3_W_IES); + } read_unlock_irqrestore(&ioc3_submodules_lock, flags); if (pending) { @@ -459,6 +459,7 @@ static irqreturn_t ioc3_intr_io(int irq, write_ireg(idd, pending, IOC3_W_IEC); handled = 1; } + return handled ? IRQ_HANDLED : IRQ_NONE; } @@ -466,15 +467,13 @@ static irqreturn_t ioc3_intr_eth(int irq { unsigned long flags; struct ioc3_driver_data *idd = (struct ioc3_driver_data *)arg; - int handled = 1; - - if (!idd->dual_irq) - return IRQ_NONE; + int handled = 0; read_lock_irqsave(&ioc3_submodules_lock, flags); - if (ioc3_ethernet && idd->active[ioc3_ethernet->id] && ioc3_ethernet->intr) - handled = handled && !ioc3_ethernet->intr(ioc3_ethernet, idd, 0); + if (idd->active[ETH_ID] && idd->dual_irq) + handled = !ioc3_submodules[ETH_ID]->intr(ioc3_submodules[ETH_ID], idd, 0); read_unlock_irqrestore(&ioc3_submodules_lock, flags); + return handled ? IRQ_HANDLED : IRQ_NONE; } @@ -524,7 +523,7 @@ void ioc3_gpio(struct ioc3_driver_data * static int find_slot(void **tab, int max) { int i; - for (i = 0; i < max; i++) + for (i = 1; i < max; i++) if (!(tab[i])) return i; return -1; @@ -538,23 +537,26 @@ int ioc3_register_submodule(struct ioc3_ unsigned long flags; write_lock_irqsave(&ioc3_submodules_lock, flags); - alloc_id = find_slot((void **)ioc3_submodules, IOC3_MAX_SUBMODULES); - if (alloc_id != -1) { - ioc3_submodules[alloc_id] = is; - if (is->ethernet) { - if (ioc3_ethernet == NULL) - ioc3_ethernet = is; - else - printk(KERN_WARNING - "IOC3 Ethernet module already registered!\n"); - } - } + if (is->ethernet) + if (ioc3_submodules[ETH_ID] == NULL) + alloc_id = ETH_ID; + else + alloc_id = -2; + else + alloc_id = find_slot((void **)ioc3_submodules, IOC3_MAX_SUBMODULES); + + if (alloc_id >= 0) + ioc3_submodules[alloc_id] = is; write_unlock_irqrestore(&ioc3_submodules_lock, flags); if (alloc_id == -1) { printk(KERN_WARNING "Increase IOC3_MAX_SUBMODULES!\n"); return -ENOMEM; } + if (alloc_id == -2) { + printk(KERN_WARNING "IOC3 Ethernet module already registered!\n"); + return -ENODEV; + } is->id=alloc_id; @@ -585,8 +587,6 @@ void ioc3_unregister_submodule(struct io else printk(KERN_WARNING "IOC3 submodule %s has wrong ID.\n", is->name); - if (ioc3_ethernet == is) - ioc3_ethernet = NULL; write_unlock_irqrestore(&ioc3_submodules_lock, flags); /* Remove submodule for each IOC3 */ @@ -670,7 +670,7 @@ static int ioc3_probe(struct pci_dev *pd } /* Set up per-IOC3 data */ - idd = kmalloc(sizeof(struct ioc3_driver_data), GFP_KERNEL); + idd = kzalloc(sizeof(struct ioc3_driver_data), GFP_KERNEL); if (!idd) { printk(KERN_WARNING "%s: Failed to allocate IOC3 data for pci_dev %s.\n", @@ -678,7 +678,7 @@ static int ioc3_probe(struct pci_dev *pd ret = -ENODEV; goto out_idd; } - memset(idd, 0, sizeof(struct ioc3_driver_data)); + spin_lock_init(&idd->ir_lock); spin_lock_init(&idd->gpio_lock); idd->pdev = pdev; @@ -733,16 +733,18 @@ static int ioc3_probe(struct pci_dev *pd pci_write_config_dword(pdev, PCI_COMMAND, pcmd | PCI_COMMAND_PARITY | PCI_COMMAND_SERR); + /* Clear IRQs */ write_ireg(idd, ~0, IOC3_W_IEC); writel(~0, &idd->vma->sio_ir); + writel(0, &idd->vma->emcr); /* Shutup */ + writel(0, &idd->vma->eier); /* Disable interrupts */ + (void) readl(&idd->vma->eier); /* Flush */ + /* Set up IRQs */ if (idd->class == IOC3_CLASS_BASE_IP30 || idd->class == IOC3_CLASS_BASE_IP27) { - writel(0, &idd->vma->eier); - writel(~0, &idd->vma->eisr); - idd->dual_irq = 1; if (!request_irq(pdev->irq, ioc3_intr_eth, IRQF_SHARED, "ioc3-eth", (void *)idd)) { From wim@iguana.be Sun Oct 7 21:27:22 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Sun, 07 Oct 2007 21:27:30 +0100 (BST) Received: from mailrelay003.isp.belgacom.be ([195.238.6.53]:48570 "EHLO mailrelay003.isp.belgacom.be") by ftp.linux-mips.org with ESMTP id S20024774AbXJGU1W (ORCPT ); Sun, 7 Oct 2007 21:27:22 +0100 X-Belgacom-Dynamic: yes Received: from 150.2-200-80.adsl-dyn.isp.belgacom.be (HELO infomag.iguana.be) ([80.200.2.150]) by relay.skynet.be with ESMTP; 07 Oct 2007 22:26:15 +0200 Received: from infomag.iguana.be (localhost.localdomain [127.0.0.1]) by infomag.iguana.be (8.13.8/8.12.11) with ESMTP id l97KVuRq003439; Sun, 7 Oct 2007 22:31:56 +0200 Received: (from wim@localhost) by infomag.iguana.be (8.13.8/8.13.8/Submit) id l97KVrxN003438; Sun, 7 Oct 2007 22:31:53 +0200 Date: Sun, 7 Oct 2007 22:31:53 +0200 From: Wim Van Sebroeck To: Matteo Croce Cc: linux-mips@linux-mips.org, Nicolas Thill , Enrik Berkhan , Christer Weinigel , Andrew Morton Subject: Re: [PATCH][MIPS][5/7] AR7: watchdog timer Message-ID: <20071007203153.GA2666@infomag.infomag.iguana.be> References: <200709201728.10866.technoboy85@gmail.com> <200709201806.41942.technoboy85@gmail.com> <20071003192414.GA7543@infomag.infomag.iguana.be> <40101cc30710031317n360ea4c7y6491f549c62e3edb@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <40101cc30710031317n360ea4c7y6491f549c62e3edb@mail.gmail.com> User-Agent: Mutt/1.4.2.1i Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 16881 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: wim@iguana.be Precedence: bulk X-list: linux-mips Hi Matteo, > > If you want I'll add it to the linux-2.6-watchdog-mm tree with > > the above mentioned changes. > Yes, please It's in the linux-2.6-watchdog-mm tree. I added an extra iounmap in the errorhandling of the init procedure. Please test. Thanks, Wim. From macro@linux-mips.org Mon Oct 8 14:27:11 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 08 Oct 2007 14:27:20 +0100 (BST) Received: from cerber.ds.pg.gda.pl ([153.19.208.18]:3228 "EHLO cerber.ds.pg.gda.pl") by ftp.linux-mips.org with ESMTP id S20030010AbXJHN1L (ORCPT ); Mon, 8 Oct 2007 14:27:11 +0100 Received: from localhost (unknown [127.0.0.17]) by cerber.ds.pg.gda.pl (Postfix) with ESMTP id DE5D74023B; Mon, 8 Oct 2007 15:27:11 +0200 (CEST) X-Virus-Scanned: amavisd-new at cerber.ds.pg.gda.pl Received: from cerber.ds.pg.gda.pl ([153.19.208.18]) by localhost (cerber.ds.pg.gda.pl [153.19.208.18]) (amavisd-new, port 10024) with ESMTP id LzVxHPelrcR0; Mon, 8 Oct 2007 15:27:05 +0200 (CEST) Received: from piorun.ds.pg.gda.pl (piorun.ds.pg.gda.pl [153.19.208.8]) by cerber.ds.pg.gda.pl (Postfix) with ESMTP id 695564023F; Mon, 8 Oct 2007 15:27:05 +0200 (CEST) Received: from blysk.ds.pg.gda.pl (macro@blysk.ds.pg.gda.pl [153.19.208.6]) by piorun.ds.pg.gda.pl (8.13.8/8.13.8) with ESMTP id l98DR81P027902; Mon, 8 Oct 2007 15:27:08 +0200 Date: Mon, 8 Oct 2007 14:27:04 +0100 (BST) From: "Maciej W. Rozycki" To: Giuseppe Sacco cc: Ralf Baechle , linux-mips@linux-mips.org Subject: Re: [PATCH]v2 mips/ip32: enable PCI bridges In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: ClamAV 0.91.2/4502/Mon Oct 8 03:52:34 2007 on piorun.ds.pg.gda.pl X-Virus-Status: Clean Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 16882 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: macro@linux-mips.org Precedence: bulk X-list: linux-mips On Sat, 6 Oct 2007, Giuseppe Sacco wrote: > @@ -33,7 +33,7 @@ static inline int mkaddr(struct pci_bus *bus, unsigned int devfn, > unsigned int reg) > { > return ((bus->number & 0xff) << 16) | > - (devfn & 0xff) << 8) | > + ((devfn & 0xff) << 8) | > (reg & 0xfc); > } Bad formatting -- using correct one would make the typo more obvious (ditto about the function's header). Maciej From veerasena_b@yahoo.co.in Mon Oct 8 14:58:44 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 08 Oct 2007 14:58:54 +0100 (BST) Received: from n7.bullet.mud.yahoo.com ([216.252.100.58]:7507 "HELO n7.bullet.mud.yahoo.com") by ftp.linux-mips.org with SMTP id S20021379AbXJHN6o (ORCPT ); Mon, 8 Oct 2007 14:58:44 +0100 Received: from [68.142.194.244] by n7.bullet.mud.yahoo.com with NNFMP; 08 Oct 2007 13:58:38 -0000 Received: from [209.191.119.184] by t2.bullet.mud.yahoo.com with NNFMP; 08 Oct 2007 13:58:38 -0000 Received: from [127.0.0.1] by omp107.mail.mud.yahoo.com with NNFMP; 08 Oct 2007 13:58:38 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 148456.87901.bm@omp107.mail.mud.yahoo.com Received: (qmail 89963 invoked by uid 60001); 8 Oct 2007 13:58:32 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.co.in; h=X-YMail-OSG:Received:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding:Message-ID; b=zWL3Bv8aPMxsYEpXcvgJVbyUyTKfLiHMelCx6s0gyx0GdusxEQZGbSOWHa7uWVTRttVzcoslZfpJkxFZ/vwIO/DouxPOj1BvBCoz9zuZHZrxQOwsUbSf2PqXVEeMdwctGazCHTkQgbsnfD68dztvncRV/uC0K84SbinIS8K14PY=; X-YMail-OSG: o.WehNUVM1nCqtNo2s_FEJxt3stXJhD4Xp27Yc9bA1mQfkb2hN2WldYED82ZO_LlKoJ7uzMeiDsm4REqm5x97a4PFTKXfb_biPwZLzQg.II.oH8BplM7fL0BbQ-- Received: from [199.239.167.162] by web8402.mail.in.yahoo.com via HTTP; Mon, 08 Oct 2007 14:58:31 BST Date: Mon, 8 Oct 2007 14:58:31 +0100 (BST) From: veerasena reddy Subject: Re: linux cache routines for Write-back cache policy on MIPS24KE To: Ralf Baechle Cc: linux-mips , "linux-kernel.org" In-Reply-To: <20071003105751.GD29244@linux-mips.org> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Message-ID: <953878.89810.qm@web8402.mail.in.yahoo.com> Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 16883 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: veerasena_b@yahoo.co.in Precedence: bulk X-list: linux-mips Ralf, thanks for the detailed information. > Anyway, it would be much easier to help you if we > knew what you are trying > to achieve with these functions. Basically our target has a MIPS24KE host processor on which Linux runs and a networking processor (NP) which sits between the EMAC contoller and the host processor to receive/transmit the data/packets. This peripheral networking processor uses the physical addresses only. We are using write-back caching policy on MIPS24KE. So, 1. when we want to transmit the packet from the host to peripheral processor, we need to convert packet buffer into physical address (CPHYSADDR) and put it into the NP's Tx queue, which will be sent to EMAC. Before converting into physical address we need to flush the corresponding cache entries. Which API should be used to achieve the above functionlaity in Linux-2.6.18 kernel? 2.Similarly in receivng path, the peripheral processor gives the physical address of the buffer containing the received packet. So, on host we need to convert this physical address into cached address (KSEG0ADDR). Before converting to cached address we need to invalidate the corresponding cache entries. Which API should be used to achieve the above functionlaity in Linux-2.6.18 kernel? currently we are using dma_cache_wback_inv() to achieve above two functionalities. Could you please suggest us the right API to be used? Thanks in advance. Regards, Veerasena. --- Ralf Baechle wrote: > On Mon, Oct 01, 2007 at 01:10:59PM +0100, veerasena > reddy wrote: > > > Is there any problem if we use the below API's in > > linxu-2.6.18 > > - dma_cache_wback_inv() > > - dma_cache_wback() > > - dma_cache_inv() > > > > functionality wise, especially in r4k.c i dont see > any > > difference between the implementation of these > APIs. > > > > Can we apply the 2.6.24 patch to kill these APIs > on > > 2.6.18 kernel? In this case what APIs i can use > for > > writeback, invalidation or both? > > > > I couldn't find any info. related to the above API > in > > DMA-API.txt. Could you please give some pointers > on > > the usage/working of these APIs. > > dma_cache_* were never documented. They respresent > the earliest attempt > at coming up with an API that enables portable > drivers and it has a few > shortcomings and like so many early things it was > never formally documented, > so don't expect any well defined semantics. The > functions never got > formally retired probably because it somehow managed > to stay under the > radar. > > Any drivers should use the APIs documented in > Documentation/DMA-API.txt > only. The almost equivalent operation for > dma_cache_* would be > dma_sync_single and dma_sync_sg. > > Don't even dream about using dma_cache_* for > anything but DMA coherency. > They're all internal low level APIs which know > nothing about Linux's > virtual memory system. > > Anyway, it would be much easier to help you if we > knew what you are trying > to achieve with these functions. > > Ralf > Chat on a cool, new interface. No download required. Go to http://in.messenger.yahoo.com/webmessengerpromo.php From vagabon.xyz@gmail.com Mon Oct 8 15:12:18 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 08 Oct 2007 15:12:27 +0100 (BST) Received: from nf-out-0910.google.com ([64.233.182.189]:40602 "EHLO nf-out-0910.google.com") by ftp.linux-mips.org with ESMTP id S20021488AbXJHOMS (ORCPT ); Mon, 8 Oct 2007 15:12:18 +0100 Received: by nf-out-0910.google.com with SMTP id c10so937810nfd for ; Mon, 08 Oct 2007 07:12:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding; bh=jyNnqhqwmVhGNOlWKsvHm68xu0pghzIrJOi2NGT66gk=; b=OI18PudzGevWRBMyUIlTWqvxubZ5Eu0TCr2mLBXjpY85FYLEa0bTwFOUQ3DHsZ3GuOUolbpOAYBepkRjFnA3CFB6CBk5R3JKwwv1I+uHKsmca4ISQf0TB3prohoHD7pCtwNdgSCsbMFoF/ILc6sG1Pde/hd330ATOawVb5f2Pxg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding; b=s445rPReu+ZfJt7qsewhTtgmt0qlXsZYrhdHbWyzq7Elxi1xhxp5yJbOk4Sn/k354dBAL9K6Yc8WyZKFKGgd7H+bXz5vU7Uf4d58NXhSg+kxVEEBsf8BFgHGlUBtFNUkKDnL5knBwXLGNkLOdVaB/Rfufgo9FIM5PuBD1iBo5gI= Received: by 10.86.50.8 with SMTP id x8mr5163746fgx.1191852721089; Mon, 08 Oct 2007 07:12:01 -0700 (PDT) Received: from ?192.168.0.1? ( [82.235.205.153]) by mx.google.com with ESMTPS id p38sm11604050fke.2007.10.08.07.11.58 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 08 Oct 2007 07:11:58 -0700 (PDT) Message-ID: <470A3AA7.7030700@gmail.com> Date: Mon, 08 Oct 2007 16:11:51 +0200 From: Franck Bui-Huu User-Agent: Thunderbird 2.0.0.5 (X11/20070719) MIME-Version: 1.0 To: Ralf Baechle CC: Thiemo Seufer , "Maciej W. Rozycki" , linux-mips@linux-mips.org Subject: Re: [PATCH] mm/pg-r4k.c: Dump the generated code References: <20071002141125.GC16772@networkno.de> <20071002154918.GA11312@linux-mips.org> <47038874.9050704@gmail.com> <20071003131158.GL16772@networkno.de> <4703F155.4000301@gmail.com> <20071003201800.GP16772@networkno.de> <47049734.6050802@gmail.com> <20071004121557.GA28928@linux-mips.org> <4705004C.5000705@gmail.com> <20071005115151.GA16145@linux-mips.org> In-Reply-To: <20071005115151.GA16145@linux-mips.org> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 16884 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: vagabon.xyz@gmail.com Precedence: bulk X-list: linux-mips Ralf Baechle wrote: > 6828 bytes isn't totally amazing but since the optimization is reasonable > clean I'm going to queue this one also. > Yes and maybe it worths to queue this on top of your patch ? --- 8< --- From: Franck Bui-Huu Subject: [PATCH] Verify CPU type when it's hardwiring Signed-off-by: Franck Bui-Huu --- arch/mips/kernel/cpu-probe.c | 8 ++++++++ 1 files changed, 8 insertions(+), 0 deletions(-) diff --git a/arch/mips/kernel/cpu-probe.c b/arch/mips/kernel/cpu-probe.c index 06448a9..cf0b566 100644 --- a/arch/mips/kernel/cpu-probe.c +++ b/arch/mips/kernel/cpu-probe.c @@ -817,6 +817,14 @@ __init void cpu_probe(void) default: c->cputype = CPU_UNKNOWN; } + + /* + * Platform code can force the cpu type to optimize code + * generation. In that case be sure the cpu type is correctly + * manually setup otherwise it could trigger some nasty bugs. + */ + BUG_ON(current_cpu_type() != c->cputype); + if (c->options & MIPS_CPU_FPU) { c->fpu_id = cpu_get_fpu_id(); -- 1.5.3.3 From ralf@linux-mips.org Mon Oct 8 15:42:24 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 08 Oct 2007 15:42:26 +0100 (BST) Received: from localhost.localdomain ([127.0.0.1]:21666 "EHLO dl5rb.ham-radio-op.net") by ftp.linux-mips.org with ESMTP id S20022194AbXJHOmY (ORCPT ); Mon, 8 Oct 2007 15:42:24 +0100 Received: from denk.linux-mips.net (denk.linux-mips.net [127.0.0.1]) by dl5rb.ham-radio-op.net (8.14.1/8.13.8) with ESMTP id l98EfmY5026824; Mon, 8 Oct 2007 15:41:48 +0100 Received: (from ralf@localhost) by denk.linux-mips.net (8.14.1/8.14.1/Submit) id l98Ef6ro026805; Mon, 8 Oct 2007 15:41:06 +0100 Date: Mon, 8 Oct 2007 15:41:06 +0100 From: Ralf Baechle To: Franck Bui-Huu Cc: Thiemo Seufer , "Maciej W. Rozycki" , linux-mips@linux-mips.org Subject: Re: [PATCH] mm/pg-r4k.c: Dump the generated code Message-ID: <20071008144106.GA11142@linux-mips.org> References: <20071002154918.GA11312@linux-mips.org> <47038874.9050704@gmail.com> <20071003131158.GL16772@networkno.de> <4703F155.4000301@gmail.com> <20071003201800.GP16772@networkno.de> <47049734.6050802@gmail.com> <20071004121557.GA28928@linux-mips.org> <4705004C.5000705@gmail.com> <20071005115151.GA16145@linux-mips.org> <470A3AA7.7030700@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <470A3AA7.7030700@gmail.com> User-Agent: Mutt/1.5.14 (2007-02-12) Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 16885 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: ralf@linux-mips.org Precedence: bulk X-list: linux-mips On Mon, Oct 08, 2007 at 04:11:51PM +0200, Franck Bui-Huu wrote: > Ralf Baechle wrote: > > 6828 bytes isn't totally amazing but since the optimization is reasonable > > clean I'm going to queue this one also. > > > > Yes and maybe it worths to queue this on top of your patch ? Well, if they're lucky enough they make it to the BUG_ON(). But for many of the missconfiguration scenarios the sympthoms would be more subtle. Queued for 2.6.24. Thanks, Ralf From vagabon.xyz@gmail.com Mon Oct 8 15:49:07 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 08 Oct 2007 15:49:17 +0100 (BST) Received: from fk-out-0910.google.com ([209.85.128.191]:8762 "EHLO fk-out-0910.google.com") by ftp.linux-mips.org with ESMTP id S20021819AbXJHOtH (ORCPT ); Mon, 8 Oct 2007 15:49:07 +0100 Received: by fk-out-0910.google.com with SMTP id f40so1342031fka for ; Mon, 08 Oct 2007 07:48:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding; bh=3ciqaoc3CzR/n3x/FO6ThGy/0NRhNX6zZSAIpCcZifs=; b=QOtk07NmEJ91Y7g+Rg4GcZ/WImK5piW6vaBtA8Cs7oAXf8wjLZj6joUp9yr1gBgcOqmqf2QWjWOmSeDe5a6FtVwQ2SYci0NpUfxa34PZVHXdTkX2Lsh3zzymCCshUOadcR4zr3b11VozvR94XTFX8Orayt3z/dhvlimwxZ1clp4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding; b=XzCtEoWNNmFcm+G3sx+w68OHerOdURtBkIpe2TvvTRcJEmo+RBCCLctifxBaBlyqXOaGBu7d1bRUQIvyvE3ANzdrIrns0rAu8yJYDrvMDdH3FoQdNQakEztWIDxBy0ZnOwAWbh3iyhQQ5iDw76gpO7S0dPW7Il0Y+bRRFl363xw= Received: by 10.82.138.6 with SMTP id l6mr5612952bud.1191854929604; Mon, 08 Oct 2007 07:48:49 -0700 (PDT) Received: from ?192.168.0.1? ( [82.235.205.153]) by mx.google.com with ESMTPS id e9sm8673311muf.2007.10.08.07.48.48 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 08 Oct 2007 07:48:49 -0700 (PDT) Message-ID: <470A4349.9090301@gmail.com> Date: Mon, 08 Oct 2007 16:48:41 +0200 From: Franck Bui-Huu User-Agent: Thunderbird 2.0.0.5 (X11/20070719) MIME-Version: 1.0 To: "Maciej W. Rozycki" CC: Ralf Baechle , Thiemo Seufer , linux-mips@linux-mips.org Subject: Re: [PATCH] mm/pg-r4k.c: Dump the generated code References: <20071002141125.GC16772@networkno.de> <20071002154918.GA11312@linux-mips.org> <47038874.9050704@gmail.com> <20071003131158.GL16772@networkno.de> <4703F155.4000301@gmail.com> <20071003201800.GP16772@networkno.de> <47049734.6050802@gmail.com> <20071004121557.GA28928@linux-mips.org> <4705004C.5000705@gmail.com> <4705EFE5.7090704@gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 16886 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: vagabon.xyz@gmail.com Precedence: bulk X-list: linux-mips Maciej W. Rozycki wrote: > The exact CPU type is not known at the moment. For example CPU_R4X00 and > CPU_MIPS32_R1 cover whole ranges that have subtle differences. It may be > possible to provide all the variations as a selection to the user, but it > may be unfeasible -- I don't know. Compare what we have in > arch/mips/Kconfig with . > OK, I see. Well, having all cpu variations in Kconfig should be technically possible. The user needs to know what exact cpu is running on which doesn't sound impossible and we could add some sanity checkings to ensure he doesn't messed up its configuration. BTW, we could pass more cpu compiler options for optimization this way. For example, when using a '4ksd' cpu, we currently can't pass '-march=4ksd' to gcc since the cpu type used for it is 'mips32r2'. And I guess it's true for all cpu types which cover a range of slightly different processors (r4x00 comes in mind). OTOH, I don't know if it can work on SMP: if the system needs 2 different implementations of the handler (I don't know if it can happen though), we must be able to select 2 different cpu types in Kconfig... Do you see any other points that we should consider before trying to use static handlers ? Some other cpu features influencing the tlb handler generations and that can be found only at runtime ? thanks, Franck From vagabon.xyz@gmail.com Mon Oct 8 16:02:20 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 08 Oct 2007 16:02:29 +0100 (BST) Received: from nf-out-0910.google.com ([64.233.182.185]:14290 "EHLO nf-out-0910.google.com") by ftp.linux-mips.org with ESMTP id S20021826AbXJHPCU (ORCPT ); Mon, 8 Oct 2007 16:02:20 +0100 Received: by nf-out-0910.google.com with SMTP id c10so950298nfd for ; Mon, 08 Oct 2007 08:02:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding; bh=lOR8VbnmHH7Rh8hzyz6WybuvTHCMIbp4lFPnpwX/k7M=; b=RtnVHc3v+1tBMCt3NWmiOHYaRbxDNZB5Ur1oOysNhrnc/pCNERfdWp5I7yM8rXYw5hkc0w1SqQXkJSxKrI3U6EoqomYCmk9lLNIwyak+y+lXhfjUR7KP9ULi/sMOy91V64FK2g7tlRp6kKZroBVckXwyEq/n7nr8HYO5vvPBTJY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding; b=JSFwQI8oXzfxdNQZidFu7MxmmAMcO3lrm8dY2bFNpskbJ0qKkEOTi/y/HMg/FscHGWbDoVI0wLcmbSZP2ZdKJnz1l25fUvw5GEI5kepx+aVjErZDSSr1J6JVLKIQRdcffTnDXKpmM+l4m1kJ/7xhdesK9RAQlXfhYgL4eQDFgmk= Received: by 10.82.165.13 with SMTP id n13mr25861934bue.1191855739835; Mon, 08 Oct 2007 08:02:19 -0700 (PDT) Received: from ?192.168.0.1? ( [82.235.205.153]) by mx.google.com with ESMTPS id u9sm8794768muf.2007.10.08.08.02.18 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 08 Oct 2007 08:02:18 -0700 (PDT) Message-ID: <470A4673.30604@gmail.com> Date: Mon, 08 Oct 2007 17:02:11 +0200 From: Franck Bui-Huu User-Agent: Thunderbird 2.0.0.5 (X11/20070719) MIME-Version: 1.0 To: Geert Uytterhoeven CC: "Maciej W. Rozycki" , Ralf Baechle , Thiemo Seufer , linux-mips@linux-mips.org Subject: Re: [PATCH] mm/pg-r4k.c: Dump the generated code References: <20071002141125.GC16772@networkno.de> <20071002154918.GA11312@linux-mips.org> <47038874.9050704@gmail.com> <20071003131158.GL16772@networkno.de> <4703F155.4000301@gmail.com> <20071003201800.GP16772@networkno.de> <47049734.6050802@gmail.com> <20071004121557.GA28928@linux-mips.org> <4705004C.5000705@gmail.com> <4705EFE5.7090704@gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 16887 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: vagabon.xyz@gmail.com Precedence: bulk X-list: linux-mips Geert Uytterhoeven wrote: > For specialized systems, you can always introduce the option to generate > the TLB handler at compile time: What do you mean by "specialized system" ? If for some platforms we could generate the TLB handlers at compile time, we could do it for all platforms, specially if the handler only depends on the cpu type, no ? > - Enhance tlbex.c to be able to compile it for the host, and generate > a fixed TLB handler, based on CONFIG_* options, if > CONFIG_STATIC_TLB_HANDLER (buried deep in depends on EMBEDDED && > ADVANCED && I_KNOW_WHAT_I_AM_DOING) is set. It may mean putting a lot of hacks in tlbex.c making it just a PITA to enhance and to maintain. IMHO, just have a static TLB handler generator is simpler specially if we don't need to patch the handler later. But we need to be sure nothing can be discover at runtime only for current and future supported cpus... thanks, Franck From geert@linux-m68k.org Mon Oct 8 16:22:07 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 08 Oct 2007 16:22:16 +0100 (BST) Received: from hoboe2bl1.telenet-ops.be ([195.130.137.73]:60635 "EHLO hoboe2bl1.telenet-ops.be") by ftp.linux-mips.org with ESMTP id S20022194AbXJHPWH (ORCPT ); Mon, 8 Oct 2007 16:22:07 +0100 Received: from localhost (localhost.localdomain [127.0.0.1]) by hoboe2bl1.telenet-ops.be (Postfix) with SMTP id E4E7812403D; Mon, 8 Oct 2007 17:21:56 +0200 (CEST) Received: from anakin.of.borg (d54C15D55.access.telenet.be [84.193.93.85]) by hoboe2bl1.telenet-ops.be (Postfix) with ESMTP id C337112402B; Mon, 8 Oct 2007 17:21:56 +0200 (CEST) Received: from anakin.of.borg (geert@localhost [127.0.0.1]) by anakin.of.borg (8.14.1/8.14.1/Debian-9) with ESMTP id l98FLubQ006449 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 8 Oct 2007 17:21:56 +0200 Received: from localhost (geert@localhost) by anakin.of.borg (8.14.1/8.14.1/Submit) with ESMTP id l98FLu5j006446; Mon, 8 Oct 2007 17:21:56 +0200 X-Authentication-Warning: anakin.of.borg: geert owned process doing -bs Date: Mon, 8 Oct 2007 17:21:56 +0200 (CEST) From: Geert Uytterhoeven To: Franck Bui-Huu Cc: "Maciej W. Rozycki" , Ralf Baechle , Thiemo Seufer , linux-mips@linux-mips.org Subject: Re: [PATCH] mm/pg-r4k.c: Dump the generated code In-Reply-To: <470A4673.30604@gmail.com> Message-ID: References: <20071002141125.GC16772@networkno.de> <20071002154918.GA11312@linux-mips.org> <47038874.9050704@gmail.com> <20071003131158.GL16772@networkno.de> <4703F155.4000301@gmail.com> <20071003201800.GP16772@networkno.de> <47049734.6050802@gmail.com> <20071004121557.GA28928@linux-mips.org> <4705004C.5000705@gmail.com> <4705EFE5.7090704@gmail.com> <470A4673.30604@gmail.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 16888 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: geert@linux-m68k.org Precedence: bulk X-list: linux-mips On Mon, 8 Oct 2007, Franck Bui-Huu wrote: > Geert Uytterhoeven wrote: > > For specialized systems, you can always introduce the option to generate > > the TLB handler at compile time: > > What do you mean by "specialized system" ? Embedded. > If for some platforms we could generate the TLB handlers at compile > time, we could do it for all platforms, specially if the handler only > depends on the cpu type, no ? Can't you currently compile a kernel that run on e.g. all O2s, irrespective of the actual CPU type? Gr{oetje,eeting}s, Geert -- Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say "programmer" or something like that. -- Linus Torvalds From ralf@linux-mips.org Mon Oct 8 16:24:01 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 08 Oct 2007 16:24:03 +0100 (BST) Received: from localhost.localdomain ([127.0.0.1]:50106 "EHLO dl5rb.ham-radio-op.net") by ftp.linux-mips.org with ESMTP id S20022374AbXJHPYB (ORCPT ); Mon, 8 Oct 2007 16:24:01 +0100 Received: from denk.linux-mips.net (denk.linux-mips.net [127.0.0.1]) by dl5rb.ham-radio-op.net (8.14.1/8.13.8) with ESMTP id l98FO1pj005369; Mon, 8 Oct 2007 16:24:01 +0100 Received: (from ralf@localhost) by denk.linux-mips.net (8.14.1/8.14.1/Submit) id l98FO0j9005368; Mon, 8 Oct 2007 16:24:01 +0100 Date: Mon, 8 Oct 2007 16:24:00 +0100 From: Ralf Baechle To: Franck Bui-Huu Cc: "Maciej W. Rozycki" , Thiemo Seufer , linux-mips@linux-mips.org Subject: Re: [PATCH] mm/pg-r4k.c: Dump the generated code Message-ID: <20071008152400.GA1317@linux-mips.org> References: <20071003131158.GL16772@networkno.de> <4703F155.4000301@gmail.com> <20071003201800.GP16772@networkno.de> <47049734.6050802@gmail.com> <20071004121557.GA28928@linux-mips.org> <4705004C.5000705@gmail.com> <4705EFE5.7090704@gmail.com> <470A4349.9090301@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <470A4349.9090301@gmail.com> User-Agent: Mutt/1.5.14 (2007-02-12) Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 16889 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: ralf@linux-mips.org Precedence: bulk X-list: linux-mips On Mon, Oct 08, 2007 at 04:48:41PM +0200, Franck Bui-Huu wrote: > Maciej W. Rozycki wrote: > > The exact CPU type is not known at the moment. For example CPU_R4X00 and > > CPU_MIPS32_R1 cover whole ranges that have subtle differences. It may be > > possible to provide all the variations as a selection to the user, but it > > may be unfeasible -- I don't know. Compare what we have in > > arch/mips/Kconfig with . > > > > OK, I see. > > Well, having all cpu variations in Kconfig should be technically > possible. The user needs to know what exact cpu is running on which > doesn't sound impossible and we could add some sanity checkings to > ensure he doesn't messed up its configuration. I don't consider this much of a problem. The machines which either have one or multiple of the R4000 family or a mix of of R10000 family processors simply shouldn't hardwire the CPU types. The R4000 machines can afford the few bytes of kernel executable and the R10000 machines often come with ridiculous amounts of memory anyway. > BTW, we could pass more cpu compiler options for optimization this > way. For example, when using a '4ksd' cpu, we currently can't pass > '-march=4ksd' to gcc since the cpu type used for it is 'mips32r2'. And > I guess it's true for all cpu types which cover a range of slightly > different processors (r4x00 comes in mind). > > OTOH, I don't know if it can work on SMP: if the system needs 2 > different implementations of the handler (I don't know if it can > happen though), we must be able to select 2 different cpu types in > Kconfig... The currently only multiprocessor systems which allow mixing of different processors are the SGI machines and there we have the restriction to at least the same family of processors, see above. One which I sooner or later expect to see is CMP systems with different clock rates per processor. > Do you see any other points that we should consider before trying to > use static handlers ? Some other cpu features influencing the tlb > handler generations and that can be found only at runtime ? Ralf From ralf@linux-mips.org Mon Oct 8 16:26:26 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 08 Oct 2007 16:26:28 +0100 (BST) Received: from localhost.localdomain ([127.0.0.1]:55987 "EHLO dl5rb.ham-radio-op.net") by ftp.linux-mips.org with ESMTP id S20022468AbXJHP0Z (ORCPT ); Mon, 8 Oct 2007 16:26:25 +0100 Received: from denk.linux-mips.net (denk.linux-mips.net [127.0.0.1]) by dl5rb.ham-radio-op.net (8.14.1/8.13.8) with ESMTP id l98FQPA7005456; Mon, 8 Oct 2007 16:26:25 +0100 Received: (from ralf@localhost) by denk.linux-mips.net (8.14.1/8.14.1/Submit) id l98FQPU8005452; Mon, 8 Oct 2007 16:26:25 +0100 Date: Mon, 8 Oct 2007 16:26:25 +0100 From: Ralf Baechle To: Geert Uytterhoeven Cc: Franck Bui-Huu , "Maciej W. Rozycki" , Thiemo Seufer , linux-mips@linux-mips.org Subject: Re: [PATCH] mm/pg-r4k.c: Dump the generated code Message-ID: <20071008152625.GB1317@linux-mips.org> References: <4703F155.4000301@gmail.com> <20071003201800.GP16772@networkno.de> <47049734.6050802@gmail.com> <20071004121557.GA28928@linux-mips.org> <4705004C.5000705@gmail.com> <4705EFE5.7090704@gmail.com> <470A4673.30604@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.14 (2007-02-12) Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 16890 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: ralf@linux-mips.org Precedence: bulk X-list: linux-mips On Mon, Oct 08, 2007 at 05:21:56PM +0200, Geert Uytterhoeven wrote: > > If for some platforms we could generate the TLB handlers at compile > > time, we could do it for all platforms, specially if the handler only > > depends on the cpu type, no ? > > Can't you currently compile a kernel that run on e.g. all O2s, > irrespective of the actual CPU type? Sortof. There are O2s with R5000, RM523x, RM7000, R10000 and R12000 processors. Supporting all from a single kernel would be trivial if the R1x000 processors were not such bitches in non-coherent systems, so the latter are still unsupported, not even in special kernel configs. Ralf From macro@linux-mips.org Mon Oct 8 16:39:47 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 08 Oct 2007 16:39:55 +0100 (BST) Received: from cerber.ds.pg.gda.pl ([153.19.208.18]:48269 "EHLO cerber.ds.pg.gda.pl") by ftp.linux-mips.org with ESMTP id S20022520AbXJHPjq (ORCPT ); Mon, 8 Oct 2007 16:39:46 +0100 Received: from localhost (unknown [127.0.0.17]) by cerber.ds.pg.gda.pl (Postfix) with ESMTP id 60A0840252; Mon, 8 Oct 2007 17:39:47 +0200 (CEST) X-Virus-Scanned: amavisd-new at cerber.ds.pg.gda.pl Received: from cerber.ds.pg.gda.pl ([153.19.208.18]) by localhost (cerber.ds.pg.gda.pl [153.19.208.18]) (amavisd-new, port 10024) with ESMTP id xFTIAh8YG1wV; Mon, 8 Oct 2007 17:39:39 +0200 (CEST) Received: from piorun.ds.pg.gda.pl (piorun.ds.pg.gda.pl [153.19.208.8]) by cerber.ds.pg.gda.pl (Postfix) with ESMTP id A22EB4024F; Mon, 8 Oct 2007 17:39:39 +0200 (CEST) Received: from blysk.ds.pg.gda.pl (macro@blysk.ds.pg.gda.pl [153.19.208.6]) by piorun.ds.pg.gda.pl (8.13.8/8.13.8) with ESMTP id l98Fdhwf016336; Mon, 8 Oct 2007 17:39:43 +0200 Date: Mon, 8 Oct 2007 16:39:38 +0100 (BST) From: "Maciej W. Rozycki" To: Franck Bui-Huu cc: Ralf Baechle , Thiemo Seufer , linux-mips@linux-mips.org Subject: Re: [PATCH] mm/pg-r4k.c: Dump the generated code In-Reply-To: <470A4349.9090301@gmail.com> Message-ID: References: <20071002141125.GC16772@networkno.de> <20071002154918.GA11312@linux-mips.org> <47038874.9050704@gmail.com> <20071003131158.GL16772@networkno.de> <4703F155.4000301@gmail.com> <20071003201800.GP16772@networkno.de> <47049734.6050802@gmail.com> <20071004121557.GA28928@linux-mips.org> <4705004C.5000705@gmail.com> <4705EFE5.7090704@gmail.com> <470A4349.9090301@gmail.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: ClamAV 0.91.2/4503/Mon Oct 8 15:16:03 2007 on piorun.ds.pg.gda.pl X-Virus-Status: Clean Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 16891 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: macro@linux-mips.org Precedence: bulk X-list: linux-mips On Mon, 8 Oct 2007, Franck Bui-Huu wrote: > Well, having all cpu variations in Kconfig should be technically > possible. The user needs to know what exact cpu is running on which > doesn't sound impossible and we could add some sanity checkings to > ensure he doesn't messed up its configuration. As long as the user is indeed capable of knowing what the exact CPU type is. I have been told replacing R4X00 with a choice like R4000, R4400, R4600, R4700 may already be too much of a hassle. Frankly I am not entirely confident much choice beyond the ISA level is actually a good idea. We do have it, because lots of bits depend on preprocessor conditionals even though they not necessarily should. There are probably some historical reasons too. But essentially we have about eight ISA variations (I - IV and four MIPS Architecture ISAs) and about four privileged resource architecture variations (R2000, R6000, R4000, R8000); not all combinations making sense and some of the choices actually not supported at all. CPU variations matter performance-wise, but the use of "-mtune=" is irrelevant in this context. > BTW, we could pass more cpu compiler options for optimization this > way. For example, when using a '4ksd' cpu, we currently can't pass > '-march=4ksd' to gcc since the cpu type used for it is 'mips32r2'. And > I guess it's true for all cpu types which cover a range of slightly > different processors (r4x00 comes in mind). What would be the gain for the kernel from using "-march=4ksd" rather than "-march=mips32r2"? > OTOH, I don't know if it can work on SMP: if the system needs 2 > different implementations of the handler (I don't know if it can > happen though), we must be able to select 2 different cpu types in > Kconfig... I do not think we happen to handle this scenario -- the more interesting configurations that could benefit do not support the cp0.ebase register making per-CPU handlers quite a challenge (i.e. the cost would exceed the benefit). > Do you see any other points that we should consider before trying to > use static handlers ? Some other cpu features influencing the tlb > handler generations and that can be found only at runtime ? What if you want to run a single kernel image regardless of the CPU installed in the system. Rebuilding the kernel (or having to keep a large collection of binaries) just because you want to swap the CPU does not seem like a terribly attractive idea. Some systems come with their CPU(s) on a daughtercard (each), you know... Maciej From macro@linux-mips.org Mon Oct 8 16:46:58 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 08 Oct 2007 16:47:07 +0100 (BST) Received: from cerber.ds.pg.gda.pl ([153.19.208.18]:9680 "EHLO cerber.ds.pg.gda.pl") by ftp.linux-mips.org with ESMTP id S20022568AbXJHPq6 (ORCPT ); Mon, 8 Oct 2007 16:46:58 +0100 Received: from localhost (unknown [127.0.0.17]) by cerber.ds.pg.gda.pl (Postfix) with ESMTP id 052E14024F; Mon, 8 Oct 2007 17:46:29 +0200 (CEST) X-Virus-Scanned: amavisd-new at cerber.ds.pg.gda.pl Received: from cerber.ds.pg.gda.pl ([153.19.208.18]) by localhost (cerber.ds.pg.gda.pl [153.19.208.18]) (amavisd-new, port 10024) with ESMTP id 7p3A6af1Bwrd; Mon, 8 Oct 2007 17:46:22 +0200 (CEST) Received: from piorun.ds.pg.gda.pl (piorun.ds.pg.gda.pl [153.19.208.8]) by cerber.ds.pg.gda.pl (Postfix) with ESMTP id 9E82E40251; Mon, 8 Oct 2007 17:46:18 +0200 (CEST) Received: from blysk.ds.pg.gda.pl (macro@blysk.ds.pg.gda.pl [153.19.208.6]) by piorun.ds.pg.gda.pl (8.13.8/8.13.8) with ESMTP id l98FkMwW017415; Mon, 8 Oct 2007 17:46:22 +0200 Date: Mon, 8 Oct 2007 16:46:17 +0100 (BST) From: "Maciej W. Rozycki" To: Ralf Baechle cc: Franck Bui-Huu , Thiemo Seufer , linux-mips@linux-mips.org Subject: Re: [PATCH] mm/pg-r4k.c: Dump the generated code In-Reply-To: Message-ID: References: <47038874.9050704@gmail.com> <20071003131158.GL16772@networkno.de> <4703F155.4000301@gmail.com> <20071003201800.GP16772@networkno.de> <47049734.6050802@gmail.com> <20071004121557.GA28928@linux-mips.org> <4705004C.5000705@gmail.com> <20071004153008.GE6897@linux-mips.org> <20071004154215.GA10682@linux-mips.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: ClamAV 0.91.2/4503/Mon Oct 8 15:16:03 2007 on piorun.ds.pg.gda.pl X-Virus-Status: Clean Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 16892 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: macro@linux-mips.org Precedence: bulk X-list: linux-mips On Thu, 4 Oct 2007, Maciej W. Rozycki wrote: > > than any other system. Or for your personal toy project, all DECs wouldn't > > be too hard either, or? > > The DECs should be reletively easy if we finally managed to get rid of > all the 64-bit-isms in the 32-bit kernel even if built for MIPS III or > above. Which, given the recent commitment to 32-bit cores is what I would > actually expect. On the second thought though -- I am afraid is still the big showstopper. Or actually the design around it. That does not mean it is undoable, but I shall defer it for now. Maciej From ralf@linux-mips.org Mon Oct 8 17:41:31 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 08 Oct 2007 17:41:33 +0100 (BST) Received: from localhost.localdomain ([127.0.0.1]:50406 "EHLO dl5rb.ham-radio-op.net") by ftp.linux-mips.org with ESMTP id S20022957AbXJHQlb (ORCPT ); Mon, 8 Oct 2007 17:41:31 +0100 Received: from denk.linux-mips.net (denk.linux-mips.net [127.0.0.1]) by dl5rb.ham-radio-op.net (8.14.1/8.13.8) with ESMTP id l98GfU9I007634; Mon, 8 Oct 2007 17:41:30 +0100 Received: (from ralf@localhost) by denk.linux-mips.net (8.14.1/8.14.1/Submit) id l98GfUDg007633; Mon, 8 Oct 2007 17:41:30 +0100 Date: Mon, 8 Oct 2007 17:41:30 +0100 From: Ralf Baechle To: "Maciej W. Rozycki" Cc: Franck Bui-Huu , Thiemo Seufer , linux-mips@linux-mips.org Subject: Re: [PATCH] mm/pg-r4k.c: Dump the generated code Message-ID: <20071008164130.GA7538@linux-mips.org> References: <20071003201800.GP16772@networkno.de> <47049734.6050802@gmail.com> <20071004121557.GA28928@linux-mips.org> <4705004C.5000705@gmail.com> <20071004153008.GE6897@linux-mips.org> <20071004154215.GA10682@linux-mips.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.14 (2007-02-12) Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 16893 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: ralf@linux-mips.org Precedence: bulk X-list: linux-mips On Mon, Oct 08, 2007 at 04:46:17PM +0100, Maciej W. Rozycki wrote: > > The DECs should be reletively easy if we finally managed to get rid of > > all the 64-bit-isms in the 32-bit kernel even if built for MIPS III or > > above. Which, given the recent commitment to 32-bit cores is what I would > > actually expect. > > On the second thought though -- I am afraid is still > the big showstopper. Or actually the design around it. That does not > mean it is undoable, but I shall defer it for now. There will be a few more issues so I guess we best tackle this step by step. Ralf From macro@linux-mips.org Mon Oct 8 17:45:55 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 08 Oct 2007 17:46:03 +0100 (BST) Received: from cerber.ds.pg.gda.pl ([153.19.208.18]:8161 "EHLO cerber.ds.pg.gda.pl") by ftp.linux-mips.org with ESMTP id S20023164AbXJHQpz (ORCPT ); Mon, 8 Oct 2007 17:45:55 +0100 Received: from localhost (unknown [127.0.0.17]) by cerber.ds.pg.gda.pl (Postfix) with ESMTP id 3A2C040256; Mon, 8 Oct 2007 18:45:56 +0200 (CEST) X-Virus-Scanned: amavisd-new at cerber.ds.pg.gda.pl Received: from cerber.ds.pg.gda.pl ([153.19.208.18]) by localhost (cerber.ds.pg.gda.pl [153.19.208.18]) (amavisd-new, port 10024) with ESMTP id QmLWiisNsVte; Mon, 8 Oct 2007 18:45:45 +0200 (CEST) Received: from piorun.ds.pg.gda.pl (piorun.ds.pg.gda.pl [153.19.208.8]) by cerber.ds.pg.gda.pl (Postfix) with ESMTP id 767764024E; Mon, 8 Oct 2007 18:45:45 +0200 (CEST) Received: from blysk.ds.pg.gda.pl (macro@blysk.ds.pg.gda.pl [153.19.208.6]) by piorun.ds.pg.gda.pl (8.13.8/8.13.8) with ESMTP id l98GjnRk029328; Mon, 8 Oct 2007 18:45:49 +0200 Date: Mon, 8 Oct 2007 17:45:44 +0100 (BST) From: "Maciej W. Rozycki" To: Ralf Baechle cc: Franck Bui-Huu , Thiemo Seufer , linux-mips@linux-mips.org Subject: Re: [PATCH] mm/pg-r4k.c: Dump the generated code In-Reply-To: <20071008164130.GA7538@linux-mips.org> Message-ID: References: <20071003201800.GP16772@networkno.de> <47049734.6050802@gmail.com> <20071004121557.GA28928@linux-mips.org> <4705004C.5000705@gmail.com> <20071004153008.GE6897@linux-mips.org> <20071004154215.GA10682@linux-mips.org> <20071008164130.GA7538@linux-mips.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: ClamAV 0.91.2/4503/Mon Oct 8 15:16:03 2007 on piorun.ds.pg.gda.pl X-Virus-Status: Clean Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 16894 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: macro@linux-mips.org Precedence: bulk X-list: linux-mips On Mon, 8 Oct 2007, Ralf Baechle wrote: > > On the second thought though -- I am afraid is still > > the big showstopper. Or actually the design around it. That does not > > mean it is undoable, but I shall defer it for now. > > There will be a few more issues so I guess we best tackle this step by > step. OK, you first! Maciej From ralf@linux-mips.org Mon Oct 8 17:53:17 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 08 Oct 2007 17:53:19 +0100 (BST) Received: from localhost.localdomain ([127.0.0.1]:64668 "EHLO dl5rb.ham-radio-op.net") by ftp.linux-mips.org with ESMTP id S20023368AbXJHQxR (ORCPT ); Mon, 8 Oct 2007 17:53:17 +0100 Received: from denk.linux-mips.net (denk.linux-mips.net [127.0.0.1]) by dl5rb.ham-radio-op.net (8.14.1/8.13.8) with ESMTP id l98GrGP4007850; Mon, 8 Oct 2007 17:53:16 +0100 Received: (from ralf@localhost) by denk.linux-mips.net (8.14.1/8.14.1/Submit) id l98Gr6ZT007843; Mon, 8 Oct 2007 17:53:06 +0100 Date: Mon, 8 Oct 2007 17:53:06 +0100 From: Ralf Baechle To: "Maciej W. Rozycki" Cc: Franck Bui-Huu , Thiemo Seufer , linux-mips@linux-mips.org Subject: Re: [PATCH] mm/pg-r4k.c: Dump the generated code Message-ID: <20071008165306.GC7538@linux-mips.org> References: <20071004121557.GA28928@linux-mips.org> <4705004C.5000705@gmail.com> <20071004153008.GE6897@linux-mips.org> <20071004154215.GA10682@linux-mips.org> <20071008164130.GA7538@linux-mips.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.14 (2007-02-12) Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 16895 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: ralf@linux-mips.org Precedence: bulk X-list: linux-mips On Mon, Oct 08, 2007 at 05:45:44PM +0100, Maciej W. Rozycki wrote: > > > On the second thought though -- I am afraid is still > > > the big showstopper. Or actually the design around it. That does not > > > mean it is undoable, but I shall defer it for now. > > > > There will be a few more issues so I guess we best tackle this step by > > step. > > OK, you first! You got the R3000 :-) Ralf From share.kt@gmail.com Tue Oct 9 07:45:05 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 09 Oct 2007 07:45:14 +0100 (BST) Received: from py-out-1112.google.com ([64.233.166.180]:60252 "EHLO py-out-1112.google.com") by ftp.linux-mips.org with ESMTP id S20022897AbXJIGpF (ORCPT ); Tue, 9 Oct 2007 07:45:05 +0100 Received: by py-out-1112.google.com with SMTP id p76so2928916pyb for ; Mon, 08 Oct 2007 23:44:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:references; bh=kICjZkZ3KAaVvHDEruu88ErmE3XFJKxAHiGh86F6MNQ=; b=lm/4CpbEx7Awq8xvr8ReY+EQ4SPau3eNN6SiIOumK0HVPcucrexoepnoLSLhM5LiZYnY9v/4Ewm5jZrTxkxtQr2mjgO1mOTEvXlC/esCGppFjtnFHNkAW1lUqUkeLjWcWOmSrKecv4YpkEIKumAYRiVwMLReudGm4A0fSXLaJe8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:references; b=GmkCQbhvpHgrq8Ds+g+zpfbsbjB7/ADXNYtpKwss7TVPeoCZzQG1QuxPQqCmwoZc4nsINEqZcm0wLbVF+Pu6taXtrKzb/Xi2f0RE6zKAPH8+smwg9Aths1/KKKKM4OEMZX3xlvPY5Pg8sEvGBI5WwGjB5SYuoL/EpOJyjBGVuC8= Received: by 10.35.131.13 with SMTP id i13mr19413948pyn.1191912286773; Mon, 08 Oct 2007 23:44:46 -0700 (PDT) Received: by 10.35.39.19 with HTTP; Mon, 8 Oct 2007 23:44:46 -0700 (PDT) Message-ID: Date: Tue, 9 Oct 2007 12:14:46 +0530 From: kaka To: linux-mips@linux-mips.org, linux-git@linux-mips.org Subject: Fwd: Error opening framebuffer device In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_47923_13726289.1191912286764" References: Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 16896 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: share.kt@gmail.com Precedence: bulk X-list: linux-mips ------=_Part_47923_13726289.1191912286764 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline *Hi All,* *While running the cross compiled directFB example on MIPS chip,* * We tried to install the framebuffer driver(command given below) and we have already created the node fb0.* *We are getting the following error, * *Can anybody throw some light on it?* *Thanks in Advance.* *While running the following command in MIPS chip, we are getting the following error.* # insmod brcmstfb.ko brcmstfb: Unknown symbol unregister_framebuffer brcmstfb: Unknown symbol BKNI_EnterCriticalSection_tagged brcmstfb: Unknown symbol printf brcmstfb: Unknown symbol BKNI_DestroyEventGroup brcmstfb: Unknown symbol BKNI_WaitForEvent_tagged brcmstfb: Unknown symbol BKNI_Printf brcmstfb: Unknown symbol __divsf3 brcmstfb: Unknown symbol BKNI_Vprintf brcmstfb: Unknown symbol BKNI_Memset brcmstfb: Unknown symbol bnetif_dma_data brcmstfb: Unknown symbol bnetif_dma_delete_filter brcmstfb: Unknown symbol cleanup_bnetif_dma brcmstfb: Unknown symbol BKNI_AcquireMutex_tagged brcmstfb: Unknown symbol malloc brcmstfb: Unknown symbol BKNI_DestroyMutex brcmstfb: Unknown symbol framebuffer_alloc brcmstfb: Unknown symbol BKNI_RemoveEventGroup brcmstfb: Unknown symbol BKNI_Malloc_tagged brcmstfb: Unknown symbol BKNI_CreateEventGroup brcmstfb: Unknown symbol BKNI_WaitForGroup brcmstfb: Unknown symbol __extendsfdf2 brcmstfb: Unknown symbol BKNI_SetEvent_tagged brcmstfb: Unknown symbol BKNI_Memcpy brcmstfb: Unknown symbol BKNI_LinuxKernel_SetIsrTasklet brcmstfb: Unknown symbol BKNI_Memcmp brcmstfb: Unknown symbol fb_find_mode brcmstfb: Unknown symbol fb_dealloc_cmap brcmstfb: Unknown symbol bnetif_dma_stop brcmstfb: Unknown symbol BKNI_ResetEvent_tagged brcmstfb: Unknown symbol BKNI_CreateMutex brcmstfb: Unknown symbol BKNI_CreateEvent_tagged brcmstfb: Unknown symbol __floatsisf brcmstfb: Unknown symbol brcm_dir_entry brcmstfb: Unknown symbol register_framebuffer brcmstfb: Unknown symbol BKNI_Fail brcmstfb: Unknown symbol fb_alloc_cmap brcmstfb: Unknown symbol BKNI_Snprintf brcmstfb: Unknown symbol BKNI_Delay_tagged brcmstfb: Unknown symbol BKNI_LeaveCriticalSection_tagged brcmstfb: Unknown symbol BKNI_Sleep_tagged brcmstfb: Unknown symbol bnetif_dma_add_filter brcmstfb: Unknown symbol BKNI_Free_tagged brcmstfb: Unknown symbol BKNI_DestroyEvent_tagged brcmstfb: Unknown symbol init_bnetif_dma brcmstfb: Unknown symbol framebuffer_release brcmstfb: Unknown symbol BKNI_AddEventGroup brcmstfb: Unknown symbol BKNI_ReleaseMutex_tagged brcmstfb: Unknown symbol __addsf3 brcmstfb: Unknown symbol free insmod: cannot insert `brcmstfb.ko': Unknown symbol in module (2): No such file or directory # # ../../cross_directfb/simple_mips =======================| DirectFB 1.0.0 |======================= (c) 2001-2007 The DirectFB Organization (directfb.org) (c) 2000-2004 Convergence (integrated media) GmbH ------------------------------------------------------------ (*) DirectFB/Core: Single Application Core. (2007-10-05 14:17) (!) Direct/Util: opening '/dev/fb0' failed --> No such device or address (!) DirectFB/FBDev: Error opening framebuffer device! (!) DirectFB/FBDev: Use 'fbdev' option or set FRAMEBUFFER environment variable. (!) DirectFB/Core: Could not initialize 'system' core! --> Initialization error!simple.c <96>: (#) DirectFBError [DirectFBCreate (&dfb)]: Initialization error! # # ------=_Part_47923_13726289.1191912286764 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline 
Hi All,
While running  the cross compiled directFB example on MIPS chip,


We tried to install the framebuffer driver(command given below) and we have already created the node fb0.
We are getting the following error, 

Can anybody throw some light on it?
Thanks in Advance.
While running the following command in MIPS chip, we are getting the following error.

# insmod brcmstfb.ko
brcmstfb: Unknown symbol unregister_framebuffer
brcmstfb: Unknown symbol BKNI_EnterCriticalSection_tagged
brcmstfb: Unknown symbol printf
brcmstfb: Unknown symbol BKNI_DestroyEventGroup
brcmstfb: Unknown symbol BKNI_WaitForEvent_tagged
brcmstfb: Unknown symbol BKNI_Printf
brcmstfb: Unknown symbol __divsf3
brcmstfb: Unknown symbol BKNI_Vprintf
brcmstfb: Unknown symbol BKNI_Memset
brcmstfb: Unknown symbol bnetif_dma_data
brcmstfb: Unknown symbol bnetif_dma_delete_filter
brcmstfb: Unknown symbol cleanup_bnetif_dma
brcmstfb: Unknown symbol BKNI_AcquireMutex_tagged
brcmstfb: Unknown symbol malloc
brcmstfb: Unknown symbol BKNI_DestroyMutex
brcmstfb: Unknown symbol framebuffer_alloc
brcmstfb: Unknown symbol BKNI_RemoveEventGroup
brcmstfb: Unknown symbol BKNI_Malloc_tagged
brcmstfb: Unknown symbol BKNI_CreateEventGroup
brcmstfb: Unknown symbol BKNI_WaitForGroup
brcmstfb: Unknown symbol __extendsfdf2
brcmstfb: Unknown symbol BKNI_SetEvent_tagged
brcmstfb: Unknown symbol BKNI_Memcpy
brcmstfb: Unknown symbol BKNI_LinuxKernel_SetIsrTasklet
brcmstfb: Unknown symbol BKNI_Memcmp
brcmstfb: Unknown symbol fb_find_mode
brcmstfb: Unknown symbol fb_dealloc_cmap
brcmstfb: Unknown symbol bnetif_dma_stop
brcmstfb: Unknown symbol BKNI_ResetEvent_tagged
brcmstfb: Unknown symbol BKNI_CreateMutex
brcmstfb: Unknown symbol BKNI_CreateEvent_tagged
brcmstfb: Unknown symbol __floatsisf
brcmstfb: Unknown symbol brcm_dir_entry
brcmstfb: Unknown symbol register_framebuffer
brcmstfb: Unknown symbol BKNI_Fail
brcmstfb: Unknown symbol fb_alloc_cmap
brcmstfb: Unknown symbol BKNI_Snprintf
brcmstfb: Unknown symbol BKNI_Delay_tagged
brcmstfb: Unknown symbol BKNI_LeaveCriticalSection_tagged
brcmstfb: Unknown symbol BKNI_Sleep_tagged
brcmstfb: Unknown symbol bnetif_dma_add_filter
brcmstfb: Unknown symbol BKNI_Free_tagged
brcmstfb: Unknown symbol BKNI_DestroyEvent_tagged
brcmstfb: Unknown symbol init_bnetif_dma
brcmstfb: Unknown symbol framebuffer_release
brcmstfb: Unknown symbol BKNI_AddEventGroup
brcmstfb: Unknown symbol BKNI_ReleaseMutex_tagged
brcmstfb: Unknown symbol __addsf3
brcmstfb: Unknown symbol free
insmod: cannot insert `brcmstfb.ko': Unknown symbol in module (2): No such file or directory
#

# ../../cross_directfb/simple_mips
                                                                                                                             
     =======================|  DirectFB 1.0.0  |=======================
          (c) 2001-2007  The DirectFB Organization (directfb.org)
          (c) 2000-2004  Convergence (integrated media) GmbH
        ------------------------------------------------------------
                                                                                                                             
(*) DirectFB/Core: Single Application Core. (2007-10-05 14:17)
(!) Direct/Util: opening '/dev/fb0' failed
    --> No such device or address
(!) DirectFB/FBDev: Error opening framebuffer device!
(!) DirectFB/FBDev: Use 'fbdev' option or set FRAMEBUFFER environment variable.
(!) DirectFB/Core: Could not initialize 'system' core!
    --> Initialization error!
simple.c <96>:
        (#) DirectFBError [DirectFBCreate (&dfb)]: Initialization error!
#

#
 
------=_Part_47923_13726289.1191912286764-- From yoichi_yuasa@tripeaks.co.jp Tue Oct 9 08:07:46 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 09 Oct 2007 08:07:55 +0100 (BST) Received: from mo32.po.2iij.net ([210.128.50.17]:19245 "EHLO mo32.po.2iij.net") by ftp.linux-mips.org with ESMTP id S20022966AbXJIHHq (ORCPT ); Tue, 9 Oct 2007 08:07:46 +0100 Received: by mo.po.2iij.net (mo32) id l9977g5n003691; Tue, 9 Oct 2007 16:07:42 +0900 (JST) Received: from localhost (65.126.232.202.bf.2iij.net [202.232.126.65]) by mbox.po.2iij.net (po-mbox302) id l9977fj0003902 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 9 Oct 2007 16:07:41 +0900 Date: Tue, 9 Oct 2007 16:07:43 +0900 From: Yoichi Yuasa To: Ralf Baechle Cc: yoichi_yuasa@tripeaks.co.jp, linux-mips Subject: a garbage character in syscall.c Message-Id: <20071009160743.5cba9b34.yoichi_yuasa@tripeaks.co.jp> Organization: TriPeaks Corporation X-Mailer: Sylpheed version 2.3.0beta5 (GTK+ 2.8.20; x86_64-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 16897 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: yoichi_yuasa@tripeaks.co.jp Precedence: bulk X-list: linux-mips Hi Ralf, This commit contains a garbage character. linux-queue.git: http://www.linux-mips.org/git?p=linux-queue.git;a=commit;h=81c6bb39250146e5db5365f843ed9c4b7604f3bd Please remove it from your patch, or apply this patch. Yoichi --- Remove a garbage character from arch/mips/kernel/syscall.c. Signed-off-by: Yoichi Yuasa diff -pruN -X mips/Documentation/dontdiff mips-orig/arch/mips/kernel/syscall.c mips/arch/mips/kernel/syscall.c --- mips-orig/arch/mips/kernel/syscall.c 2007-10-07 20:19:46.581632250 +0900 +++ mips/arch/mips/kernel/syscall.c 2007-10-08 13:41:03.265637500 +0900 @@ -361,7 +361,7 @@ asmlinkage int sys_ipc(unsigned int call default: return sys_msgrcv(first, (struct msgbuf __user *) ptr, - $B!-(B second, fifth, third); + second, fifth, third); } case MSGGET: return sys_msgget((key_t) first, second); From share.kt@gmail.com Tue Oct 9 09:46:07 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 09 Oct 2007 09:46:16 +0100 (BST) Received: from py-out-1112.google.com ([64.233.166.179]:7990 "EHLO py-out-1112.google.com") by ftp.linux-mips.org with ESMTP id S20023335AbXJIIqH (ORCPT ); Tue, 9 Oct 2007 09:46:07 +0100 Received: by py-out-1112.google.com with SMTP id p76so2975892pyb for ; Tue, 09 Oct 2007 01:45:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:references; bh=ZgWU+w8pv5/C6TP/tcsokgwyZ8Uqnahqn6v3ld3F7Ss=; b=dvQDuD3GTHQK1q4dny0son60qL6FRNEw3QNz+G7t8sqnie/9PZ2T5goqyCSVJKxI+uk3l1HL9yquNmbo6IRWaBrQnhjR7NOVp48dvI5QJU+ad0/3XudfC3RH/+qWEWTEAEG7Z/1RKzILqku9JXmHrJd4OUlJBied3IorUHt5Ey8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:references; b=TigO0+7W8OZ3mLsoV/giSBBo6DjErpHI82WZtIYS2OxPquYOcRPUYzXvRUawHaIG5QaBrDe1RHYV2M8xV0S6uC+pccd2TyrkRTeqbV0VQ3s4mvOvcQiz0bjJuHvQAUGxnHtOKRJ4bI8HRAPB4D/2l9m2bHnSPG9Om4GF5K5UlaI= Received: by 10.35.65.17 with SMTP id s17mr6495933pyk.1191919544022; Tue, 09 Oct 2007 01:45:44 -0700 (PDT) Received: by 10.35.39.19 with HTTP; Tue, 9 Oct 2007 01:45:43 -0700 (PDT) Message-ID: Date: Tue, 9 Oct 2007 14:15:43 +0530 From: kaka To: linux-mips@linux-mips.org Subject: Error opening framebuffer device In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_48235_25691707.1191919544014" References: Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 16898 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: share.kt@gmail.com Precedence: bulk X-list: linux-mips ------=_Part_48235_25691707.1191919544014 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline *Hi All,* *While running the cross compiled directFB example on MIPS chip,* * We tried to install the framebuffer driver(command given at the bottom) and we have already created the node fb0.* *We are getting the following error, * *Can anybody throw some light on it?* *Thanks in Advance.* # ../../cross_directfb/simple_mips =======================| DirectFB 1.0.0 |======================= (c) 2001-2007 The DirectFB Organization (directfb.org) (c) 2000-2004 Convergence (integrated media) GmbH ------------------------------------------------------------ (*) DirectFB/Core: Single Application Core. (2007-10-05 14:17) (!) Direct/Util: opening '/dev/fb0' failed --> No such device or address (!) DirectFB/FBDev: Error opening framebuffer device! (!) DirectFB/FBDev: Use 'fbdev' option or set FRAMEBUFFER environment variable. (!) DirectFB/Core: Could not initialize 'system' core! --> Initialization error!simple.c <96>: (#) DirectFBError [DirectFBCreate (&dfb)]: Initialization error! # *While running the following command in MIPS chip, we are getting the following error.* # insmod brcmstfb.ko brcmstfb: Unknown symbol unregister_framebuffer brcmstfb: Unknown symbol BKNI_EnterCriticalSection_tagged brcmstfb: Unknown symbol printf brcmstfb: Unknown symbol BKNI_DestroyEventGroup brcmstfb: Unknown symbol BKNI_WaitForEvent_tagged brcmstfb: Unknown symbol BKNI_Printf brcmstfb: Unknown symbol __divsf3 brcmstfb: Unknown symbol BKNI_Vprintf brcmstfb: Unknown symbol BKNI_Memset brcmstfb: Unknown symbol bnetif_dma_data brcmstfb: Unknown symbol bnetif_dma_delete_filter brcmstfb: Unknown symbol cleanup_bnetif_dma brcmstfb: Unknown symbol BKNI_AcquireMutex_tagged brcmstfb: Unknown symbol malloc brcmstfb: Unknown symbol BKNI_DestroyMutex brcmstfb: Unknown symbol framebuffer_alloc brcmstfb: Unknown symbol BKNI_RemoveEventGroup brcmstfb: Unknown symbol BKNI_Malloc_tagged brcmstfb: Unknown symbol BKNI_CreateEventGroup brcmstfb: Unknown symbol BKNI_WaitForGroup brcmstfb: Unknown symbol __extendsfdf2 brcmstfb: Unknown symbol BKNI_SetEvent_tagged brcmstfb: Unknown symbol BKNI_Memcpy brcmstfb: Unknown symbol BKNI_LinuxKernel_SetIsrTasklet brcmstfb: Unknown symbol BKNI_Memcmp brcmstfb: Unknown symbol fb_find_mode brcmstfb: Unknown symbol fb_dealloc_cmap brcmstfb: Unknown symbol bnetif_dma_stop brcmstfb: Unknown symbol BKNI_ResetEvent_tagged brcmstfb: Unknown symbol BKNI_CreateMutex brcmstfb: Unknown symbol BKNI_CreateEvent_tagged brcmstfb: Unknown symbol __floatsisf brcmstfb: Unknown symbol brcm_dir_entry brcmstfb: Unknown symbol register_framebuffer brcmstfb: Unknown symbol BKNI_Fail brcmstfb: Unknown symbol fb_alloc_cmap brcmstfb: Unknown symbol BKNI_Snprintf brcmstfb: Unknown symbol BKNI_Delay_tagged brcmstfb: Unknown symbol BKNI_LeaveCriticalSection_tagged brcmstfb: Unknown symbol BKNI_Sleep_tagged brcmstfb: Unknown symbol bnetif_dma_add_filter brcmstfb: Unknown symbol BKNI_Free_tagged brcmstfb: Unknown symbol BKNI_DestroyEvent_tagged brcmstfb: Unknown symbol init_bnetif_dma brcmstfb: Unknown symbol framebuffer_release brcmstfb: Unknown symbol BKNI_AddEventGroup brcmstfb: Unknown symbol BKNI_ReleaseMutex_tagged brcmstfb: Unknown symbol __addsf3 brcmstfb: Unknown symbol free insmod: cannot insert `brcmstfb.ko': Unknown symbol in module (2): No such file or directory # # ------=_Part_48235_25691707.1191919544014 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline 
Hi All,
While running  the cross compiled directFB example on MIPS chip,


We tried to install the framebuffer driver(command given at the bottom) and we have already created the node fb0.
We are getting the following error, 


Can anybody throw some light on it?
Thanks in Advance.
# ../../cross_directfb/simple_mips
                                                                                                                             
     =======================|  DirectFB 1.0.0  |=======================
          (c) 2001-2007  The DirectFB Organization (directfb.org)
          (c) 2000-2004  Convergence (integrated media) GmbH
        ------------------------------------------------------------
                                                                                                                             
(*) DirectFB/Core: Single Application Core. (2007-10-05 14:17)
(!) Direct/Util: opening '/dev/fb0' failed
    --> No such device or address
(!) DirectFB/FBDev: Error opening framebuffer device!
(!) DirectFB/FBDev: Use 'fbdev' option or set FRAMEBUFFER environment variable.
(!) DirectFB/Core: Could not initialize 'system' core!
    --> Initialization error!
simple.c <96>:
        (#) DirectFBError [DirectFBCreate (&dfb)]: Initialization error!
#

While running the following command in MIPS chip, we are getting the following error.
# insmod brcmstfb.ko
brcmstfb: Unknown symbol unregister_framebuffer
brcmstfb: Unknown symbol BKNI_EnterCriticalSection_tagged
brcmstfb: Unknown symbol printf
brcmstfb: Unknown symbol BKNI_DestroyEventGroup
brcmstfb: Unknown symbol BKNI_WaitForEvent_tagged
brcmstfb: Unknown symbol BKNI_Printf
brcmstfb: Unknown symbol __divsf3
brcmstfb: Unknown symbol BKNI_Vprintf
brcmstfb: Unknown symbol BKNI_Memset
brcmstfb: Unknown symbol bnetif_dma_data
brcmstfb: Unknown symbol bnetif_dma_delete_filter
brcmstfb: Unknown symbol cleanup_bnetif_dma
brcmstfb: Unknown symbol BKNI_AcquireMutex_tagged
brcmstfb: Unknown symbol malloc
brcmstfb: Unknown symbol BKNI_DestroyMutex
brcmstfb: Unknown symbol framebuffer_alloc
brcmstfb: Unknown symbol BKNI_RemoveEventGroup
brcmstfb: Unknown symbol BKNI_Malloc_tagged
brcmstfb: Unknown symbol BKNI_CreateEventGroup
brcmstfb: Unknown symbol BKNI_WaitForGroup
brcmstfb: Unknown symbol __extendsfdf2
brcmstfb: Unknown symbol BKNI_SetEvent_tagged
brcmstfb: Unknown symbol BKNI_Memcpy
brcmstfb: Unknown symbol BKNI_LinuxKernel_SetIsrTasklet
brcmstfb: Unknown symbol BKNI_Memcmp
brcmstfb: Unknown symbol fb_find_mode
brcmstfb: Unknown symbol fb_dealloc_cmap
brcmstfb: Unknown symbol bnetif_dma_stop
brcmstfb: Unknown symbol BKNI_ResetEvent_tagged
brcmstfb: Unknown symbol BKNI_CreateMutex
brcmstfb: Unknown symbol BKNI_CreateEvent_tagged
brcmstfb: Unknown symbol __floatsisf
brcmstfb: Unknown symbol brcm_dir_entry
brcmstfb: Unknown symbol register_framebuffer
brcmstfb: Unknown symbol BKNI_Fail
brcmstfb: Unknown symbol fb_alloc_cmap
brcmstfb: Unknown symbol BKNI_Snprintf
brcmstfb: Unknown symbol BKNI_Delay_tagged
brcmstfb: Unknown symbol BKNI_LeaveCriticalSection_tagged
brcmstfb: Unknown symbol BKNI_Sleep_tagged
brcmstfb: Unknown symbol bnetif_dma_add_filter
brcmstfb: Unknown symbol BKNI_Free_tagged
brcmstfb: Unknown symbol BKNI_DestroyEvent_tagged
brcmstfb: Unknown symbol init_bnetif_dma
brcmstfb: Unknown symbol framebuffer_release
brcmstfb: Unknown symbol BKNI_AddEventGroup
brcmstfb: Unknown symbol BKNI_ReleaseMutex_tagged
brcmstfb: Unknown symbol __addsf3
brcmstfb: Unknown symbol free
insmod: cannot insert `brcmstfb.ko': Unknown symbol in module (2): No such file or directory
#
#
 
------=_Part_48235_25691707.1191919544014-- From florian.fainelli@telecomint.eu Tue Oct 9 10:05:13 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 09 Oct 2007 10:05:21 +0100 (BST) Received: from smtp2.int-evry.fr ([157.159.10.45]:40156 "EHLO smtp2.int-evry.fr") by ftp.linux-mips.org with ESMTP id S20029463AbXJIJFN (ORCPT ); Tue, 9 Oct 2007 10:05:13 +0100 Received: from meteor.local (unknown [157.159.47.35]) by smtp2.int-evry.fr (Postfix) with ESMTP id E591D3EF3F8; Tue, 9 Oct 2007 11:05:05 +0200 (CEST) From: Florian Fainelli To: kaka Subject: Re: Error opening framebuffer device Date: Tue, 9 Oct 2007 11:07:49 +0200 User-Agent: KMail/1.9.6 Cc: linux-mips@linux-mips.org References: In-Reply-To: MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <200710091107.49453.florian.fainelli@telecomint.eu> X-int-MailScanner-Information: Please contact the ISP for more information X-int-MailScanner: Found to be clean X-int-MailScanner-SpamCheck: X-int-MailScanner-From: florian.fainelli@telecomint.eu Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 16899 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: florian.fainelli@telecomint.eu Precedence: bulk X-list: linux-mips Hi, On Tuesday 09 October 2007 10:45:43 kaka wrote: > *Hi All,* > > *While running the cross compiled directFB example on MIPS chip,* > > * > We tried to install the framebuffer driver(command given at the > bottom) and we have already created the node fb0.* Looking at the insmod below, I think the framebuffer did not register correctly, so creating the device will not help if the driver is not registered. > # insmod brcmstfb.ko > brcmstfb: Unknown symbol unregister_framebuffer > brcmstfb: Unknown symbol BKNI_EnterCriticalSection_tagged > brcmstfb: Unknown symbol printf > brcmstfb: Unknown symbol BKNI_DestroyEventGroup > brcmstfb: Unknown symbol BKNI_WaitForEvent_tagged > brcmstfb: Unknown symbol BKNI_Printf > brcmstfb: Unknown symbol __divsf3 > brcmstfb: Unknown symbol BKNI_Vprintf > brcmstfb: Unknown symbol BKNI_Memset > brcmstfb: Unknown symbol bnetif_dma_data > brcmstfb: Unknown symbol bnetif_dma_delete_filter > brcmstfb: Unknown symbol cleanup_bnetif_dma > brcmstfb: Unknown symbol BKNI_AcquireMutex_tagged > brcmstfb: Unknown symbol malloc > brcmstfb: Unknown symbol BKNI_DestroyMutex > brcmstfb: Unknown symbol framebuffer_alloc > brcmstfb: Unknown symbol BKNI_RemoveEventGroup > brcmstfb: Unknown symbol BKNI_Malloc_tagged > brcmstfb: Unknown symbol BKNI_CreateEventGroup > brcmstfb: Unknown symbol BKNI_WaitForGroup > brcmstfb: Unknown symbol __extendsfdf2 > brcmstfb: Unknown symbol BKNI_SetEvent_tagged > brcmstfb: Unknown symbol BKNI_Memcpy > brcmstfb: Unknown symbol BKNI_LinuxKernel_SetIsrTasklet > brcmstfb: Unknown symbol BKNI_Memcmp > brcmstfb: Unknown symbol fb_find_mode > brcmstfb: Unknown symbol fb_dealloc_cmap > brcmstfb: Unknown symbol bnetif_dma_stop > brcmstfb: Unknown symbol BKNI_ResetEvent_tagged > brcmstfb: Unknown symbol BKNI_CreateMutex > brcmstfb: Unknown symbol BKNI_CreateEvent_tagged > brcmstfb: Unknown symbol __floatsisf > brcmstfb: Unknown symbol brcm_dir_entry > brcmstfb: Unknown symbol register_framebuffer > brcmstfb: Unknown symbol BKNI_Fail > brcmstfb: Unknown symbol fb_alloc_cmap > brcmstfb: Unknown symbol BKNI_Snprintf > brcmstfb: Unknown symbol BKNI_Delay_tagged > brcmstfb: Unknown symbol BKNI_LeaveCriticalSection_tagged > brcmstfb: Unknown symbol BKNI_Sleep_tagged > brcmstfb: Unknown symbol bnetif_dma_add_filter > brcmstfb: Unknown symbol BKNI_Free_tagged > brcmstfb: Unknown symbol BKNI_DestroyEvent_tagged > brcmstfb: Unknown symbol init_bnetif_dma > brcmstfb: Unknown symbol framebuffer_release > brcmstfb: Unknown symbol BKNI_AddEventGroup > brcmstfb: Unknown symbol BKNI_ReleaseMutex_tagged > brcmstfb: Unknown symbol __addsf3 > brcmstfb: Unknown symbol free > insmod: cannot insert `brcmstfb.ko': Unknown symbol in module (2): No > such file or directory > # Did you compile framebuffer support for your kernel ? Because if yes, most symbols (I did not check all) used by your drivers seems to be exported with EXPORT_SYMBOL, and not EXPORT_SYMBOL_GPL, so your driver, even with a proprietary license should be able to access them. I would recommend you mention your linux version, and the relevant kernel configuration parts. From geert@linux-m68k.org Tue Oct 9 10:18:35 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 09 Oct 2007 10:18:43 +0100 (BST) Received: from adicia.telenet-ops.be ([195.130.132.56]:46753 "EHLO adicia.telenet-ops.be") by ftp.linux-mips.org with ESMTP id S20025583AbXJIJSf (ORCPT ); Tue, 9 Oct 2007 10:18:35 +0100 Received: from localhost (localhost.localdomain [127.0.0.1]) by adicia.telenet-ops.be (Postfix) with SMTP id 75D44230114; Tue, 9 Oct 2007 11:18:34 +0200 (CEST) Received: from anakin.of.borg (d54C15D55.access.telenet.be [84.193.93.85]) by adicia.telenet-ops.be (Postfix) with ESMTP id 48D47230111; Tue, 9 Oct 2007 11:18:34 +0200 (CEST) Received: from anakin.of.borg (geert@localhost [127.0.0.1]) by anakin.of.borg (8.14.1/8.14.1/Debian-9) with ESMTP id l999IYWP025930 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 9 Oct 2007 11:18:34 +0200 Received: from localhost (geert@localhost) by anakin.of.borg (8.14.1/8.14.1/Submit) with ESMTP id l999IXFB025927; Tue, 9 Oct 2007 11:18:34 +0200 X-Authentication-Warning: anakin.of.borg: geert owned process doing -bs Date: Tue, 9 Oct 2007 11:18:33 +0200 (CEST) From: Geert Uytterhoeven To: kaka Cc: linux-mips@linux-mips.org, linux-git@linux-mips.org Subject: Re: Fwd: Error opening framebuffer device In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 16900 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: geert@linux-m68k.org Precedence: bulk X-list: linux-mips On Tue, 9 Oct 2007, kaka wrote: > # insmod brcmstfb.ko > brcmstfb: Unknown symbol unregister_framebuffer Try `modprobe brcmstfb', which will also load the modules it depends on. > brcmstfb: Unknown symbol printf Ugh, printf()? There's no printf() in our kernel. > brcmstfb: Unknown symbol malloc There's no malloc() in our kernel. Gr{oetje,eeting}s, Geert -- Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say "programmer" or something like that. -- Linus Torvalds From ralf@linux-mips.org Tue Oct 9 10:58:48 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 09 Oct 2007 10:58:50 +0100 (BST) Received: from localhost.localdomain ([127.0.0.1]:42465 "EHLO dl5rb.ham-radio-op.net") by ftp.linux-mips.org with ESMTP id S20029986AbXJIJ6s (ORCPT ); Tue, 9 Oct 2007 10:58:48 +0100 Received: from denk.linux-mips.net (denk.linux-mips.net [127.0.0.1]) by dl5rb.ham-radio-op.net (8.14.1/8.13.8) with ESMTP id l999wmCL029254; Tue, 9 Oct 2007 10:58:48 +0100 Received: (from ralf@localhost) by denk.linux-mips.net (8.14.1/8.14.1/Submit) id l999wibe029253; Tue, 9 Oct 2007 10:58:44 +0100 Date: Tue, 9 Oct 2007 10:58:44 +0100 From: Ralf Baechle To: Yoichi Yuasa Cc: linux-mips Subject: Re: a garbage character in syscall.c Message-ID: <20071009095844.GA20698@linux-mips.org> References: <20071009160743.5cba9b34.yoichi_yuasa@tripeaks.co.jp> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20071009160743.5cba9b34.yoichi_yuasa@tripeaks.co.jp> User-Agent: Mutt/1.5.14 (2007-02-12) Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 16901 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: ralf@linux-mips.org Precedence: bulk X-list: linux-mips On Tue, Oct 09, 2007 at 04:07:43PM +0900, Yoichi Yuasa wrote: > linux-queue.git: > http://www.linux-mips.org/git?p=linux-queue.git;a=commit;h=81c6bb39250146e5db5365f843ed9c4b7604f3bd > > Please remove it from your patch, or apply this patch. Thanks, fixed. For the -queue branch I usually prefer to fold fixes into the patches that did introduce them. Ralf From ralf@linux-mips.org Tue Oct 9 12:00:36 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 09 Oct 2007 12:00:38 +0100 (BST) Received: from localhost.localdomain ([127.0.0.1]:1258 "EHLO dl5rb.ham-radio-op.net") by ftp.linux-mips.org with ESMTP id S20021525AbXJILAg (ORCPT ); Tue, 9 Oct 2007 12:00:36 +0100 Received: from denk.linux-mips.net (denk.linux-mips.net [127.0.0.1]) by dl5rb.ham-radio-op.net (8.14.1/8.13.8) with ESMTP id l99B0ZnW005080; Tue, 9 Oct 2007 12:00:35 +0100 Received: (from ralf@localhost) by denk.linux-mips.net (8.14.1/8.14.1/Submit) id l99B0ZJW005079; Tue, 9 Oct 2007 12:00:35 +0100 Date: Tue, 9 Oct 2007 12:00:35 +0100 From: Ralf Baechle To: kaka Cc: linux-mips@linux-mips.org, linux-git@linux-mips.org Subject: Re: Fwd: Error opening framebuffer device Message-ID: <20071009110035.GA4852@linux-mips.org> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.14 (2007-02-12) Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 16902 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: ralf@linux-mips.org Precedence: bulk X-list: linux-mips On Tue, Oct 09, 2007 at 12:14:46PM +0530, kaka wrote: > # insmod brcmstfb.ko > brcmstfb: Unknown symbol unregister_framebuffer It would help tremendously to enable framebuffer support. > brcmstfb: Unknown symbol BKNI_EnterCriticalSection_tagged > brcmstfb: Unknown symbol printf > brcmstfb: Unknown symbol BKNI_DestroyEventGroup > brcmstfb: Unknown symbol BKNI_WaitForEvent_tagged > brcmstfb: Unknown symbol BKNI_Printf > brcmstfb: Unknown symbol __divsf3 Floating point in the kernel that doesn't quite fly - unless you do softfloat. Ralf From ralf@linux-mips.org Tue Oct 9 14:25:30 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 09 Oct 2007 14:25:33 +0100 (BST) Received: from localhost.localdomain ([127.0.0.1]:481 "EHLO dl5rb.ham-radio-op.net") by ftp.linux-mips.org with ESMTP id S20022481AbXJINZa (ORCPT ); Tue, 9 Oct 2007 14:25:30 +0100 Received: from denk.linux-mips.net (denk.linux-mips.net [127.0.0.1]) by dl5rb.ham-radio-op.net (8.14.1/8.13.8) with ESMTP id l99DPTv2028973; Tue, 9 Oct 2007 14:25:29 +0100 Received: (from ralf@localhost) by denk.linux-mips.net (8.14.1/8.14.1/Submit) id l99DPSXP028972; Tue, 9 Oct 2007 14:25:28 +0100 Date: Tue, 9 Oct 2007 14:25:28 +0100 From: Ralf Baechle To: linux-kernel@vger.kernel.org, linux-mips@linux-mips.org Subject: What's in linux-mips.git for Linux 2.6.24? Message-ID: <20071009132528.GA28924@linux-mips.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.14 (2007-02-12) Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 16903 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: ralf@linux-mips.org Precedence: bulk X-list: linux-mips The biggest actual changes are the support for tickless kernels on MIPS and the rewrite for many of the timer devices previously used as clocksources and clockevents. Various cleanups, including some moving of code and support for 32-bit Broadcom BCM47XX processors, the return of support for LASAT which isn't quite as unused as previously thought ... The number of patch lines and files is inflated by two large whitespace cleanup patches. Ralf Ahmed S. Darwish (1): [MIPS] Replace deprecated SA_* IRQ flags with modern IRQF_ variants. Atsushi Nemoto (2): [MIPS] tx4927: Cleanup unused macros and non-standard IO accessors. [MIPS] Kill redundant EXTRA_AFLAGS Aurelien Jarno (6): [MIPS] Add support for BCM47XX CPUs. [MIPS] Move CFE code into arch/mips/fw/cfe [MIPS] Move ARC code into arch/mips/fw/arc [MIPS] Add CFE support to BCM47XX [MIPS] Add gpio support to the BCM47XX platform [MIPS] GPIO LED driver for the WGT634U machine Brian Murphy (1): [MIPS] Add back support for LASAT platforms Florian Fainelli (1): [MIPS] MTX1: Add defconfig file Franck Bui-Huu (5): [MIPS] Remove '-mno-explicit-relocs' option when CONFIG_BUILD_ELF64 [MIPS] Automatically set CONFIG_BUILD_ELF64 [MIPS] Rename CONFIG_BUILD_ELF64 into KBUILD_64BIT_SYM32 [MIPS] Don't abort the build process if '-msym32' isn't supported [MIPS] Add BUG_ON assertion for attempt to run kernel on the wrong CPU type. Kevin D. Kissell (1): [MIPS] IRQ Affinity Support for SMTC on Malta Platform Maciej W. Rozycki (3): [MIPS] R3000 setup for kernel_thread() [MIPS] dec/time.c: Remove no longer needed inclusion of . [MIPS] pg-r4k.c: Dump the generated code Paolo 'Blaisorblade' Giarrusso (1): [MIPS] Alchemy: Fix USB initialization. Ralf Baechle (35): [MIPS] SMTC: Microoptimize atomic_postincrement for non-weak consistency. [MIPS] PCI: Always enable CONFIG_PCI_DOMAINS [MIPS] floppy: Rewrite fd_cacheflush() to use dma_cache_sync(). [MIPS] Kill useless volatile keyword [MIPS] Sibyte: cleanup static inline forward declarations. [MIPS] Alchemy: remove useless prototypes. [MIPS] Sibyte: Replace SB1 cachecode with standard R4000 class cache code. [MIPS] Remove IP27 specific structures from struct cpuinfo_mips [MIPS] Split up war.h [MIPS] ARC: Convert mach_table[] to ISO C initializers. [MIPS] ARC: Get rid of mips_machgroup [MIPS] Use generic NTP code for all MIPS platforms [MIPS] Deforest the function pointer jungle in the time code. [MIPS] Switch from to_tm to rtc_time_to_tm [MIPS] Consolidate all variants of MIPS cp0 timer interrupt handlers. [MIPS] Implement clockevents for R4000-style cp0 count/compare interrupt [MIPS] Dyntick support for SMTC: [MIPS] Jazz clockevent driver [MIPS] IP27: Add clocksource drivers [MIPS] i8253 PIT clocksource and clockevent drivers [MIPS] Clockevent driver for BCM1250 [MIPS] Clockevent driver for BCM1480 [MIPS] Avoid indexed cacheops. [MIPS] Optimize __alloc_zeroed_user_highpage implementation. [MIPS] tlbex: Size optimize code by declaring a few functions inline. [MIPS] Allow hardwiring of the CPU type to a single type for optimization. [MIPS] Fix "no space between function name and open parenthesis" warnings. [MIPS] checkfiles: Fix "need space after that ','" errors. [MIPS] Optimize get_unaligned / put_unaligned implementations. [MIPS] Convert list of CPU types from #define to enum. [MIPS] Make facility to convert CPU types to strings generally available. [MIPS] SMP: Implement smp_call_function_mask(). [MIPS] Kill num_online_cpus() loops. [MIPS] SMP: Kill useless casts. [MIPS] SMP: Use ISO C struct initializer for local structs. Sam Ravnborg (1): [MIPS] Introduce a consistent style for vmlinux.lds. Thiemo Seufer (1): [MIPS] Define known MIPS ISA overrides for Sibyte and Excite boards. Thomas Bogendoerfer (1): [MIPS] JAZZ fixes Thomas Gleixner (2): [MIPS] cleanup struct irqaction initializers clockevents: fix bogus next_event reset for oneshot broadcast devices Yoichi Yuasa (16): [MIPS] vr41xx: add cpu_wait [MIPS] VR41xx: Add default restart routine. [MIPS] VR41xx: replace infinite loop with hibernate [MIPS] IP27: remove duplicate extern dump_tlb_all() prototype [MIPS] remove unused include/asm-mips/ip32/machine.h [MIPS] fix ABI check in include/asm-mips/arv/hinv.h [MIPS] i8295 cleanups. [MIPS] GT64120: Remove unused definitions [MIPS] Add GT641xx IRQ routines. [MIPS] Cobalt: Add Cobalt Raq LED platform register and power off trigger [MIPS] Cobalt: Add Qube series front LED support to platform register [MIPS] Cobalt: Add LED support to cobalt_defconfig [MIPS] Cobalt: Move PCI definitions to arch/mips/pci/fixup-cobalt.c. [MIPS] Cobalt: Move UART base definition to arch/mips/cobalt/console.c [MIPS] Cobalt: Move reset port definition to arch/mips/cobalt/reset.c [MIPS] Cobalt: Remove cobalt_machine_power_off() arch/mips/Kconfig | 98 arch/mips/Makefile | 48 arch/mips/au1000/common/dbdma.c | 6 arch/mips/au1000/common/dbg_io.c | 2 arch/mips/au1000/common/irq.c | 15 arch/mips/au1000/common/power.c | 2 arch/mips/au1000/common/reset.c | 2 arch/mips/au1000/common/setup.c | 2 arch/mips/au1000/common/time.c | 46 arch/mips/au1000/db1x00/board_setup.c | 2 arch/mips/au1000/db1x00/init.c | 8 arch/mips/au1000/mtx-1/board_setup.c | 2 arch/mips/au1000/mtx-1/init.c | 1 arch/mips/au1000/pb1000/board_setup.c | 8 arch/mips/au1000/pb1000/init.c | 1 arch/mips/au1000/pb1100/board_setup.c | 6 arch/mips/au1000/pb1100/init.c | 1 arch/mips/au1000/pb1200/board_setup.c | 8 arch/mips/au1000/pb1200/init.c | 1 arch/mips/au1000/pb1200/irqmap.c | 2 arch/mips/au1000/pb1500/board_setup.c | 8 arch/mips/au1000/pb1500/init.c | 1 arch/mips/au1000/pb1550/board_setup.c | 2 arch/mips/au1000/pb1550/init.c | 1 arch/mips/au1000/xxs1500/board_setup.c | 2 arch/mips/au1000/xxs1500/init.c | 1 arch/mips/basler/excite/excite_prom.c | 1 arch/mips/basler/excite/excite_setup.c | 17 arch/mips/bcm47xx/Makefile | 6 arch/mips/bcm47xx/gpio.c | 79 arch/mips/bcm47xx/irq.c | 55 arch/mips/bcm47xx/prom.c | 158 + arch/mips/bcm47xx/serial.c | 52 arch/mips/bcm47xx/setup.c | 123 + arch/mips/bcm47xx/time.c | 55 arch/mips/bcm47xx/wgt634u.c | 64 arch/mips/boot/addinitrd.c | 60 arch/mips/boot/elf2ecoff.c | 2 arch/mips/cobalt/Makefile | 2 arch/mips/cobalt/console.c | 9 arch/mips/cobalt/irq.c | 116 - arch/mips/cobalt/led.c | 62 arch/mips/cobalt/reset.c | 39 arch/mips/cobalt/rtc.c | 5 arch/mips/cobalt/serial.c | 7 arch/mips/cobalt/setup.c | 20 arch/mips/configs/bigsur_defconfig | 1 arch/mips/configs/cobalt_defconfig | 23 arch/mips/configs/lasat_defconfig | 828 ++++ arch/mips/configs/mtx1_defconfig | 3115 +++++++++++++++ arch/mips/configs/sb1250-swarm_defconfig | 1 arch/mips/dec/ecc-berr.c | 2 arch/mips/dec/kn02xa-berr.c | 2 arch/mips/dec/prom/identify.c | 3 arch/mips/dec/prom/init.c | 8 arch/mips/dec/setup.c | 4 arch/mips/dec/time.c | 13 arch/mips/emma2rh/common/prom.c | 2 arch/mips/emma2rh/markeins/setup.c | 4 arch/mips/fw/arc/Makefile | 0 arch/mips/fw/arc/arc_con.c | 0 arch/mips/fw/arc/cmdline.c | 0 arch/mips/fw/arc/env.c | 2 arch/mips/fw/arc/file.c | 2 arch/mips/fw/arc/identify.c | 82 arch/mips/fw/arc/init.c | 0 arch/mips/fw/arc/memory.c | 6 arch/mips/fw/arc/misc.c | 2 arch/mips/fw/arc/promlib.c | 0 arch/mips/fw/arc/salone.c | 0 arch/mips/fw/arc/time.c | 2 arch/mips/fw/arc/tree.c | 2 arch/mips/fw/cfe/Makefile | 5 arch/mips/fw/cfe/cfe_api.c | 2 arch/mips/fw/cfe/cfe_api_int.h | 0 arch/mips/gt64120/wrppmc/setup.c | 5 arch/mips/gt64120/wrppmc/time.c | 2 arch/mips/jazz/Makefile | 2 arch/mips/jazz/irq.c | 142 - arch/mips/jazz/jazz-platform.c | 60 arch/mips/jazz/jazzdma.c | 47 arch/mips/jazz/reset.c | 4 arch/mips/jazz/setup.c | 134 + arch/mips/jmr3927/rbhma3100/init.c | 1 arch/mips/jmr3927/rbhma3100/irq.c | 8 arch/mips/jmr3927/rbhma3100/setup.c | 4 arch/mips/kernel/Makefile | 2 arch/mips/kernel/binfmt_elfo32.c | 2 arch/mips/kernel/cpu-bugs64.c | 2 arch/mips/kernel/cpu-probe.c | 129 + arch/mips/kernel/gdb-stub.c | 26 arch/mips/kernel/i8253.c | 213 + arch/mips/kernel/i8259.c | 37 arch/mips/kernel/irixelf.c | 40 arch/mips/kernel/irixinv.c | 42 arch/mips/kernel/irixioctl.c | 2 arch/mips/kernel/irixsig.c | 8 arch/mips/kernel/irq-gt641xx.c | 131 + arch/mips/kernel/irq-msc01.c | 4 arch/mips/kernel/irq.c | 4 arch/mips/kernel/kspd.c | 12 arch/mips/kernel/linux32.c | 24 arch/mips/kernel/mips-mt.c | 2 arch/mips/kernel/proc.c | 73 arch/mips/kernel/process.c | 11 arch/mips/kernel/ptrace.c | 50 arch/mips/kernel/ptrace32.c | 16 arch/mips/kernel/setup.c | 2 arch/mips/kernel/signal.c | 4 arch/mips/kernel/signal32.c | 44 arch/mips/kernel/signal_n32.c | 4 arch/mips/kernel/smp-mt.c | 2 arch/mips/kernel/smp.c | 104 arch/mips/kernel/smtc.c | 146 - arch/mips/kernel/syscall.c | 60 arch/mips/kernel/sysirix.c | 22 arch/mips/kernel/time.c | 416 +- arch/mips/kernel/traps.c | 45 arch/mips/kernel/unaligned.c | 2 arch/mips/kernel/vmlinux.lds.S | 339 +- arch/mips/kernel/vpe.c | 2 arch/mips/lasat/Kconfig | 15 arch/mips/lasat/Makefile | 16 arch/mips/lasat/at93c.c | 149 + arch/mips/lasat/at93c.h | 18 arch/mips/lasat/ds1603.c | 183 + arch/mips/lasat/ds1603.h | 31 arch/mips/lasat/image/Makefile | 54 arch/mips/lasat/image/head.S | 31 arch/mips/lasat/image/romscript.normal | 23 arch/mips/lasat/interrupt.c | 130 + arch/mips/lasat/lasat_board.c | 280 + arch/mips/lasat/lasat_models.h | 67 arch/mips/lasat/picvue.c | 244 + arch/mips/lasat/picvue.h | 48 arch/mips/lasat/picvue_proc.c | 191 + arch/mips/lasat/prom.c | 126 + arch/mips/lasat/prom.h | 7 arch/mips/lasat/reset.c | 61 arch/mips/lasat/serial.c | 94 arch/mips/lasat/setup.c | 154 + arch/mips/lasat/sysctl.c | 456 ++ arch/mips/lasat/sysctl.h | 24 arch/mips/lemote/lm2e/Makefile | 1 arch/mips/lemote/lm2e/prom.c | 1 arch/mips/lemote/lm2e/setup.c | 7 arch/mips/lib/ucmpdi2.c | 2 arch/mips/math-emu/cp1emu.c | 32 arch/mips/math-emu/dp_mul.c | 2 arch/mips/math-emu/ieee754.c | 12 arch/mips/math-emu/ieee754dp.h | 12 arch/mips/math-emu/ieee754int.h | 30 arch/mips/math-emu/ieee754sp.h | 12 arch/mips/mips-boards/atlas/atlas_gdb.c | 2 arch/mips/mips-boards/atlas/atlas_int.c | 22 arch/mips/mips-boards/atlas/atlas_setup.c | 7 arch/mips/mips-boards/generic/init.c | 12 arch/mips/mips-boards/generic/memory.c | 4 arch/mips/mips-boards/generic/pci.c | 2 arch/mips/mips-boards/generic/time.c | 147 - arch/mips/mips-boards/malta/malta_int.c | 36 arch/mips/mips-boards/malta/malta_setup.c | 16 arch/mips/mips-boards/malta/malta_smtc.c | 50 arch/mips/mips-boards/sead/sead_int.c | 2 arch/mips/mips-boards/sead/sead_setup.c | 5 arch/mips/mipssim/sim_int.c | 2 arch/mips/mipssim/sim_mem.c | 4 arch/mips/mipssim/sim_setup.c | 2 arch/mips/mipssim/sim_time.c | 76 arch/mips/mm/Makefile | 2 arch/mips/mm/c-r3k.c | 12 arch/mips/mm/c-r4k.c | 116 - arch/mips/mm/c-sb1.c | 535 --- arch/mips/mm/c-tx39.c | 6 arch/mips/mm/cache.c | 9 arch/mips/mm/cerr-sb1.c | 24 arch/mips/mm/dma-default.c | 4 arch/mips/mm/pg-r4k.c | 22 arch/mips/mm/pg-sb1.c | 12 arch/mips/mm/pgtable.c | 8 arch/mips/mm/sc-mips.c | 2 arch/mips/mm/tlb-r4k.c | 2 arch/mips/mm/tlb-r8k.c | 2 arch/mips/mm/tlbex.c | 114 - arch/mips/oprofile/common.c | 2 arch/mips/oprofile/op_model_mipsxx.c | 6 arch/mips/oprofile/op_model_rm9000.c | 2 arch/mips/pci/Makefile | 2 arch/mips/pci/fixup-atlas.c | 6 arch/mips/pci/fixup-cobalt.c | 40 arch/mips/pci/ops-au1000.c | 2 arch/mips/pci/ops-nile4.c | 147 + arch/mips/pci/ops-pmcmsp.c | 2 arch/mips/pci/ops-sni.c | 22 arch/mips/pci/pci-bcm1480.c | 6 arch/mips/pci/pci-bcm1480ht.c | 4 arch/mips/pci/pci-lasat.c | 91 arch/mips/pci/pci-sb1250.c | 4 arch/mips/pci/pci-vr41xx.c | 2 arch/mips/philips/pnx8550/common/proc.c | 36 arch/mips/philips/pnx8550/common/setup.c | 3 arch/mips/philips/pnx8550/common/time.c | 7 arch/mips/philips/pnx8550/jbs/init.c | 1 arch/mips/philips/pnx8550/stb810/prom_init.c | 1 arch/mips/pmc-sierra/msp71xx/msp_hwbutton.c | 2 arch/mips/pmc-sierra/msp71xx/msp_serial.c | 8 arch/mips/pmc-sierra/msp71xx/msp_setup.c | 18 arch/mips/pmc-sierra/msp71xx/msp_time.c | 3 arch/mips/pmc-sierra/msp71xx/msp_usb.c | 8 arch/mips/pmc-sierra/yosemite/ht.c | 2 arch/mips/pmc-sierra/yosemite/prom.c | 1 arch/mips/pmc-sierra/yosemite/setup.c | 26 arch/mips/qemu/q-firmware.c | 2 arch/mips/qemu/q-irq.c | 4 arch/mips/qemu/q-setup.c | 10 arch/mips/sgi-ip22/ip22-eisa.c | 2 arch/mips/sgi-ip22/ip22-int.c | 7 arch/mips/sgi-ip22/ip22-setup.c | 2 arch/mips/sgi-ip22/ip22-time.c | 35 arch/mips/sgi-ip27/ip27-berr.c | 2 arch/mips/sgi-ip27/ip27-init.c | 6 arch/mips/sgi-ip27/ip27-smp.c | 4 arch/mips/sgi-ip27/ip27-timer.c | 38 arch/mips/sgi-ip32/crime.c | 6 arch/mips/sgi-ip32/ip32-irq.c | 44 arch/mips/sgi-ip32/ip32-memory.c | 4 arch/mips/sgi-ip32/ip32-setup.c | 12 arch/mips/sibyte/Kconfig | 13 arch/mips/sibyte/bcm1480/irq.c | 21 arch/mips/sibyte/bcm1480/setup.c | 78 arch/mips/sibyte/bcm1480/time.c | 118 - arch/mips/sibyte/cfe/Makefile | 2 arch/mips/sibyte/cfe/console.c | 6 arch/mips/sibyte/cfe/setup.c | 7 arch/mips/sibyte/cfe/smp.c | 4 arch/mips/sibyte/common/Makefile | 1 arch/mips/sibyte/common/sb_tbprof.c | 4 arch/mips/sibyte/sb1250/irq.c | 58 arch/mips/sibyte/sb1250/prom.c | 3 arch/mips/sibyte/sb1250/setup.c | 74 arch/mips/sibyte/sb1250/time.c | 198 + arch/mips/sibyte/swarm/dbg_io.c | 4 arch/mips/sibyte/swarm/rtc_m41t81.c | 3 arch/mips/sibyte/swarm/rtc_xicor1241.c | 3 arch/mips/sibyte/swarm/setup.c | 56 arch/mips/sni/a20r.c | 6 arch/mips/sni/pcimt.c | 5 arch/mips/sni/pcit.c | 27 arch/mips/sni/reset.c | 2 arch/mips/sni/rm200.c | 11 arch/mips/sni/setup.c | 8 arch/mips/sni/sniprom.c | 8 arch/mips/sni/time.c | 27 arch/mips/tx4927/common/tx4927_dbgio.c | 1 arch/mips/tx4927/common/tx4927_prom.c | 12 arch/mips/tx4927/common/tx4927_setup.c | 20 .../tx4927/toshiba_rbtx4927/toshiba_rbtx4927_irq.c | 33 .../toshiba_rbtx4927/toshiba_rbtx4927_prom.c | 2 .../toshiba_rbtx4927/toshiba_rbtx4927_setup.c | 36 arch/mips/tx4938/common/setup.c | 9 arch/mips/tx4938/toshiba_rbtx4938/prom.c | 1 arch/mips/tx4938/toshiba_rbtx4938/setup.c | 7 arch/mips/vr41xx/common/bcu.c | 8 arch/mips/vr41xx/common/cmu.c | 16 arch/mips/vr41xx/common/giu.c | 2 arch/mips/vr41xx/common/icu.c | 76 arch/mips/vr41xx/common/init.c | 8 arch/mips/vr41xx/common/pmu.c | 40 arch/mips/vr41xx/common/rtc.c | 2 arch/mips/vr41xx/common/siu.c | 2 arch/mips/vr41xx/nec-cmbvr4133/init.c | 6 arch/mips/vr41xx/nec-cmbvr4133/m1535plus.c | 6 arch/mips/vr41xx/nec-cmbvr4133/setup.c | 1 drivers/net/jazzsonic.c | 6 drivers/video/logo/logo.c | 10 include/asm-mips/addrspace.h | 6 include/asm-mips/asm.h | 66 include/asm-mips/asmmacro.h | 12 include/asm-mips/atomic.h | 28 include/asm-mips/bitops.h | 12 include/asm-mips/bootinfo.h | 41 include/asm-mips/byteorder.h | 4 include/asm-mips/cmpxchg.h | 4 include/asm-mips/cpu-features.h | 8 include/asm-mips/cpu-info.h | 21 include/asm-mips/cpu.h | 160 - include/asm-mips/delay.h | 2 include/asm-mips/elf.h | 2 include/asm-mips/fixmap.h | 4 include/asm-mips/floppy.h | 6 include/asm-mips/futex.h | 2 include/asm-mips/fw/arc/hinv.h | 5 include/asm-mips/fw/arc/types.h | 0 include/asm-mips/fw/cfe/cfe_api.h | 24 include/asm-mips/fw/cfe/cfe_error.h | 0 include/asm-mips/hazards.h | 2 include/asm-mips/hw_irq.h | 7 include/asm-mips/i8253.h | 30 include/asm-mips/i8259.h | 5 include/asm-mips/inventory.h | 4 include/asm-mips/io.h | 18 include/asm-mips/ioctl.h | 16 include/asm-mips/ioctls.h | 12 include/asm-mips/ip32/machine.h | 20 include/asm-mips/irq.h | 67 include/asm-mips/irq_gt641xx.h | 60 include/asm-mips/irqflags.h | 10 include/asm-mips/jazz.h | 40 include/asm-mips/jazzdma.h | 1 include/asm-mips/jmr3927/tx3927.h | 32 include/asm-mips/lasat/ds1603.h | 18 include/asm-mips/lasat/eeprom.h | 17 include/asm-mips/lasat/head.h | 22 include/asm-mips/lasat/lasat.h | 256 + include/asm-mips/lasat/lasatint.h | 12 include/asm-mips/lasat/picvue.h | 15 include/asm-mips/lasat/serial.h | 13 include/asm-mips/linkage.h | 2 include/asm-mips/local.h | 20 include/asm-mips/mach-au1x00/au1000.h | 622 +-- include/asm-mips/mach-au1x00/au1xxx_dbdma.h | 14 include/asm-mips/mach-au1x00/au1xxx_ide.h | 2 include/asm-mips/mach-au1x00/war.h | 25 include/asm-mips/mach-bcm47xx/bcm47xx.h | 25 include/asm-mips/mach-bcm47xx/gpio.h | 59 include/asm-mips/mach-bcm47xx/war.h | 25 include/asm-mips/mach-cobalt/cobalt.h | 61 .../asm-mips/mach-cobalt/cpu-feature-overrides.h | 1 include/asm-mips/mach-cobalt/irq.h | 58 include/asm-mips/mach-cobalt/war.h | 25 include/asm-mips/mach-dec/war.h | 25 include/asm-mips/mach-emma2rh/war.h | 25 .../asm-mips/mach-excite/cpu-feature-overrides.h | 5 include/asm-mips/mach-excite/war.h | 25 include/asm-mips/mach-generic/mangle-port.h | 32 include/asm-mips/mach-ip22/war.h | 29 include/asm-mips/mach-ip27/irq.h | 2 include/asm-mips/mach-ip27/mangle-port.h | 16 include/asm-mips/mach-ip27/topology.h | 20 include/asm-mips/mach-ip27/war.h | 25 include/asm-mips/mach-ip32/kmalloc.h | 2 include/asm-mips/mach-ip32/mangle-port.h | 16 include/asm-mips/mach-ip32/war.h | 25 include/asm-mips/mach-jazz/mc146818rtc.h | 10 include/asm-mips/mach-jazz/war.h | 25 include/asm-mips/mach-jmr3927/mangle-port.h | 16 include/asm-mips/mach-jmr3927/war.h | 25 include/asm-mips/mach-lasat/mach-gt64120.h | 27 include/asm-mips/mach-lasat/war.h | 25 include/asm-mips/mach-lemote/war.h | 25 include/asm-mips/mach-mips/mach-gt64120.h | 9 include/asm-mips/mach-mips/war.h | 25 include/asm-mips/mach-mipssim/war.h | 25 include/asm-mips/mach-pb1x00/pb1000.h | 56 include/asm-mips/mach-pb1x00/pb1100.h | 60 include/asm-mips/mach-pnx8550/kernel-entry-init.h | 26 include/asm-mips/mach-pnx8550/uart.h | 2 include/asm-mips/mach-pnx8550/war.h | 25 include/asm-mips/mach-qemu/war.h | 25 include/asm-mips/mach-rm/war.h | 29 .../asm-mips/mach-sibyte/cpu-feature-overrides.h | 7 include/asm-mips/mach-sibyte/war.h | 37 include/asm-mips/mach-tx49xx/war.h | 25 include/asm-mips/mach-vr41xx/war.h | 25 include/asm-mips/mach-wrppmc/mach-gt64120.h | 1 include/asm-mips/mach-wrppmc/war.h | 25 include/asm-mips/mach-yosemite/war.h | 25 include/asm-mips/mc146818-time.h | 4 include/asm-mips/mips-boards/bonito64.h | 20 include/asm-mips/mips-boards/malta.h | 2 include/asm-mips/mipsmtregs.h | 60 include/asm-mips/mipsregs.h | 4 include/asm-mips/mmu_context.h | 8 include/asm-mips/nile4.h | 310 + include/asm-mips/paccess.h | 8 include/asm-mips/page.h | 2 include/asm-mips/parport.h | 6 include/asm-mips/pci.h | 4 include/asm-mips/pci/bridge.h | 2 include/asm-mips/pgalloc.h | 6 include/asm-mips/pgtable-32.h | 2 include/asm-mips/pgtable-64.h | 6 include/asm-mips/pgtable.h | 4 include/asm-mips/prctl.h | 2 include/asm-mips/qemu.h | 2 include/asm-mips/r4kcache.h | 6 include/asm-mips/semaphore.h | 8 include/asm-mips/sgiarcs.h | 36 include/asm-mips/sibyte/bcm1480_int.h | 22 include/asm-mips/sibyte/bcm1480_l2c.h | 102 include/asm-mips/sibyte/bcm1480_mc.h | 644 ++- include/asm-mips/sibyte/bcm1480_regs.h | 18 include/asm-mips/sibyte/bcm1480_scd.h | 102 include/asm-mips/sibyte/board.h | 4 include/asm-mips/sibyte/sb1250_defs.h | 14 include/asm-mips/sibyte/sb1250_dma.h | 246 + include/asm-mips/sibyte/sb1250_genbus.h | 322 +- include/asm-mips/sibyte/sb1250_int.h | 22 include/asm-mips/sibyte/sb1250_l2c.h | 64 include/asm-mips/sibyte/sb1250_ldt.h | 194 - include/asm-mips/sibyte/sb1250_mac.h | 284 + include/asm-mips/sibyte/sb1250_mc.h | 306 + include/asm-mips/sibyte/sb1250_regs.h | 32 include/asm-mips/sibyte/sb1250_scd.h | 306 + include/asm-mips/sibyte/sb1250_smbus.h | 62 include/asm-mips/sibyte/sb1250_syncser.h | 16 include/asm-mips/sibyte/sb1250_uart.h | 70 include/asm-mips/siginfo.h | 4 include/asm-mips/sim.h | 4 include/asm-mips/smp.h | 9 include/asm-mips/smtc_ipi.h | 1 include/asm-mips/sn/addrs.h | 50 include/asm-mips/sn/arch.h | 4 include/asm-mips/sn/io.h | 2 include/asm-mips/sn/klconfig.h | 6 include/asm-mips/sn/kldir.h | 2 include/asm-mips/sn/sn0/addrs.h | 8 include/asm-mips/sni.h | 18 include/asm-mips/stackframe.h | 20 include/asm-mips/system.h | 10 include/asm-mips/time.h | 41 include/asm-mips/timex.h | 2 include/asm-mips/tlbflush.h | 4 include/asm-mips/tx4927/toshiba_rbtx4927.h | 8 include/asm-mips/tx4927/tx4927.h | 439 -- include/asm-mips/tx4927/tx4927_mips.h | 4177 -------------------- include/asm-mips/tx4938/rbtx4938.h | 2 include/asm-mips/tx4938/tx4938.h | 44 include/asm-mips/tx4938/tx4938_mips.h | 8 include/asm-mips/uaccess.h | 58 include/asm-mips/unaligned.h | 27 include/asm-mips/vga.h | 4 include/asm-mips/war.h | 127 - include/asm-mips/xtalk/xtalk.h | 2 kernel/time/tick-broadcast.c | 2 435 files changed, 14274 insertions(+), 10196 deletions(-) create mode 100644 arch/mips/bcm47xx/Makefile create mode 100644 arch/mips/bcm47xx/gpio.c create mode 100644 arch/mips/bcm47xx/irq.c create mode 100644 arch/mips/bcm47xx/prom.c create mode 100644 arch/mips/bcm47xx/serial.c create mode 100644 arch/mips/bcm47xx/setup.c create mode 100644 arch/mips/bcm47xx/time.c create mode 100644 arch/mips/bcm47xx/wgt634u.c create mode 100644 arch/mips/cobalt/led.c create mode 100644 arch/mips/configs/lasat_defconfig create mode 100644 arch/mips/configs/mtx1_defconfig rename arch/mips/{arc/Makefile => fw/arc/Makefile} (100%) rename arch/mips/{arc/arc_con.c => fw/arc/arc_con.c} (100%) rename arch/mips/{arc/cmdline.c => fw/arc/cmdline.c} (100%) rename arch/mips/{arc/env.c => fw/arc/env.c} (95%) rename arch/mips/{arc/file.c => fw/arc/file.c} (98%) rename arch/mips/{arc/identify.c => fw/arc/identify.c} (65%) rename arch/mips/{arc/init.c => fw/arc/init.c} (100%) rename arch/mips/{arc/memory.c => fw/arc/memory.c} (94%) rename arch/mips/{arc/misc.c => fw/arc/misc.c} (98%) rename arch/mips/{arc/promlib.c => fw/arc/promlib.c} (100%) rename arch/mips/{arc/salone.c => fw/arc/salone.c} (100%) rename arch/mips/{arc/time.c => fw/arc/time.c} (94%) rename arch/mips/{arc/tree.c => fw/arc/tree.c} (99%) create mode 100644 arch/mips/fw/cfe/Makefile rename arch/mips/{sibyte/cfe/cfe_api.c => fw/cfe/cfe_api.c} (100%) rename arch/mips/{sibyte/cfe/cfe_api_int.h => fw/cfe/cfe_api_int.h} (100%) delete mode 100644 arch/mips/jazz/jazz-platform.c create mode 100644 arch/mips/kernel/i8253.c create mode 100644 arch/mips/kernel/irq-gt641xx.c create mode 100644 arch/mips/lasat/Kconfig create mode 100644 arch/mips/lasat/Makefile create mode 100644 arch/mips/lasat/at93c.c create mode 100644 arch/mips/lasat/at93c.h create mode 100644 arch/mips/lasat/ds1603.c create mode 100644 arch/mips/lasat/ds1603.h create mode 100644 arch/mips/lasat/image/Makefile create mode 100644 arch/mips/lasat/image/head.S create mode 100644 arch/mips/lasat/image/romscript.normal create mode 100644 arch/mips/lasat/interrupt.c create mode 100644 arch/mips/lasat/lasat_board.c create mode 100644 arch/mips/lasat/lasat_models.h create mode 100644 arch/mips/lasat/picvue.c create mode 100644 arch/mips/lasat/picvue.h create mode 100644 arch/mips/lasat/picvue_proc.c create mode 100644 arch/mips/lasat/prom.c create mode 100644 arch/mips/lasat/prom.h create mode 100644 arch/mips/lasat/reset.c create mode 100644 arch/mips/lasat/serial.c create mode 100644 arch/mips/lasat/setup.c create mode 100644 arch/mips/lasat/sysctl.c create mode 100644 arch/mips/lasat/sysctl.h delete mode 100644 arch/mips/mm/c-sb1.c create mode 100644 arch/mips/pci/ops-nile4.c create mode 100644 arch/mips/pci/pci-lasat.c rename include/asm-mips/{arc/hinv.h => fw/arc/hinv.h} (97%) rename include/asm-mips/{arc/types.h => fw/arc/types.h} (100%) rename arch/mips/sibyte/cfe/cfe_api.h => include/asm-mips/fw/cfe/cfe_api.h (90%) rename arch/mips/sibyte/cfe/cfe_error.h => include/asm-mips/fw/cfe/cfe_error.h (100%) create mode 100644 include/asm-mips/i8253.h delete mode 100644 include/asm-mips/ip32/machine.h create mode 100644 include/asm-mips/irq_gt641xx.h create mode 100644 include/asm-mips/lasat/ds1603.h create mode 100644 include/asm-mips/lasat/eeprom.h create mode 100644 include/asm-mips/lasat/head.h create mode 100644 include/asm-mips/lasat/lasat.h create mode 100644 include/asm-mips/lasat/lasatint.h create mode 100644 include/asm-mips/lasat/picvue.h create mode 100644 include/asm-mips/lasat/serial.h create mode 100644 include/asm-mips/mach-au1x00/war.h create mode 100644 include/asm-mips/mach-bcm47xx/bcm47xx.h create mode 100644 include/asm-mips/mach-bcm47xx/gpio.h create mode 100644 include/asm-mips/mach-bcm47xx/war.h create mode 100644 include/asm-mips/mach-cobalt/irq.h create mode 100644 include/asm-mips/mach-cobalt/war.h create mode 100644 include/asm-mips/mach-dec/war.h create mode 100644 include/asm-mips/mach-emma2rh/war.h create mode 100644 include/asm-mips/mach-excite/war.h create mode 100644 include/asm-mips/mach-ip22/war.h create mode 100644 include/asm-mips/mach-ip27/war.h create mode 100644 include/asm-mips/mach-ip32/war.h create mode 100644 include/asm-mips/mach-jazz/war.h create mode 100644 include/asm-mips/mach-jmr3927/war.h create mode 100644 include/asm-mips/mach-lasat/mach-gt64120.h create mode 100644 include/asm-mips/mach-lasat/war.h create mode 100644 include/asm-mips/mach-lemote/war.h create mode 100644 include/asm-mips/mach-mips/war.h create mode 100644 include/asm-mips/mach-mipssim/war.h create mode 100644 include/asm-mips/mach-pnx8550/war.h create mode 100644 include/asm-mips/mach-qemu/war.h create mode 100644 include/asm-mips/mach-rm/war.h create mode 100644 include/asm-mips/mach-sibyte/war.h create mode 100644 include/asm-mips/mach-tx49xx/war.h create mode 100644 include/asm-mips/mach-vr41xx/war.h create mode 100644 include/asm-mips/mach-wrppmc/war.h create mode 100644 include/asm-mips/mach-yosemite/war.h create mode 100644 include/asm-mips/nile4.h delete mode 100644 include/asm-mips/tx4927/tx4927_mips.h From ralf@linux-mips.org Tue Oct 9 14:35:04 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 09 Oct 2007 14:35:06 +0100 (BST) Received: from localhost.localdomain ([127.0.0.1]:39365 "EHLO dl5rb.ham-radio-op.net") by ftp.linux-mips.org with ESMTP id S20022564AbXJINfD (ORCPT ); Tue, 9 Oct 2007 14:35:03 +0100 Received: from denk.linux-mips.net (denk.linux-mips.net [127.0.0.1]) by dl5rb.ham-radio-op.net (8.14.1/8.13.8) with ESMTP id l99DZ3pD001879; Tue, 9 Oct 2007 14:35:03 +0100 Received: (from ralf@localhost) by denk.linux-mips.net (8.14.1/8.14.1/Submit) id l99DZ3gi001878; Tue, 9 Oct 2007 14:35:03 +0100 Date: Tue, 9 Oct 2007 14:35:03 +0100 From: Ralf Baechle To: Johannes Dickgreber Cc: Kumba , linux-mips@linux-mips.org Subject: Re: [PATCH] arch/mips/pci/ioc3.c Message-ID: <20071009133503.GA1788@linux-mips.org> References: <47093583.6010407@gmx.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <47093583.6010407@gmx.de> User-Agent: Mutt/1.5.14 (2007-02-12) Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 16904 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: ralf@linux-mips.org Precedence: bulk X-list: linux-mips On Sun, Oct 07, 2007 at 09:37:39PM +0200, Johannes Dickgreber wrote: > From: Johannes Dickgreber > Date: Sun, 07 Oct 2007 21:37:39 +0200 > To: Ralf Baechle > CC: Kumba , linux-mips@linux-mips.org > Subject: [PATCH] arch/mips/pci/ioc3.c > Content-Type: text/plain; charset=UTF-8 Kumba, are you collecting Johannes' Octane patches? They don't apply to the main MIPS tree. Ralf From yoichi_yuasa@tripeaks.co.jp Tue Oct 9 16:02:50 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 09 Oct 2007 16:02:59 +0100 (BST) Received: from mo31.po.2iij.net ([210.128.50.54]:49941 "EHLO mo31.po.2iij.net") by ftp.linux-mips.org with ESMTP id S20023308AbXJIPCu (ORCPT ); Tue, 9 Oct 2007 16:02:50 +0100 Received: by mo.po.2iij.net (mo31) id l99F1VVB062109; Wed, 10 Oct 2007 00:01:31 +0900 (JST) Received: from delta (221.25.30.125.dy.iij4u.or.jp [125.30.25.221]) by mbox.po.2iij.net (po-mbox303) id l99F1PTx018407 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 10 Oct 2007 00:01:25 +0900 Date: Wed, 10 Oct 2007 00:01:24 +0900 From: Yoichi Yuasa To: Ralf Baechle Cc: yoichi_yuasa@tripeaks.co.jp, linux-mips Subject: fix cpu_type_enum Message-Id: <20071010000124.c1f995bc.yoichi_yuasa@tripeaks.co.jp> Organization: TriPeaks Corporation X-Mailer: Sylpheed 2.4.0 (GTK+ 2.10.11; i486-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 16905 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: yoichi_yuasa@tripeaks.co.jp Precedence: bulk X-list: linux-mips Hi Ralf, You forgot a colon after CPU_BCM4710. http://www.linux-mips.org/git?p=linux-queue.git;a=commit;h=74b4db70cfaa5809eb684bccd5e57150e5149b1d Yoichi From yoichi_yuasa@tripeaks.co.jp Tue Oct 9 16:28:33 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 09 Oct 2007 16:28:42 +0100 (BST) Received: from mo30.po.2iij.NET ([210.128.50.53]:8012 "EHLO mo30.po.2iij.net") by ftp.linux-mips.org with ESMTP id S20022992AbXJIP2d (ORCPT ); Tue, 9 Oct 2007 16:28:33 +0100 Received: by mo.po.2iij.net (mo30) id l99FSUqL058502; Wed, 10 Oct 2007 00:28:30 +0900 (JST) Received: from delta (221.25.30.125.dy.iij4u.or.jp [125.30.25.221]) by mbox.po.2iij.net (po-mbox303) id l99FSRws005770 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 10 Oct 2007 00:28:27 +0900 Date: Wed, 10 Oct 2007 00:28:26 +0900 From: Yoichi Yuasa To: Ralf Baechle Cc: yoichi_yuasa@tripeaks.co.jp, linux-mips Subject: [PATCH][MIPS] cleanup WRPPMC include files Message-Id: <20071010002826.5a85efc5.yoichi_yuasa@tripeaks.co.jp> Organization: TriPeaks Corporation X-Mailer: Sylpheed 2.4.0 (GTK+ 2.10.11; i486-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 16906 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: yoichi_yuasa@tripeaks.co.jp Precedence: bulk X-list: linux-mips Cleanup WRPPMC include files. Signed-off-by: Yoichi Yuasa diff -pruN -X mips/Documentation/dontdiff mips-orig/arch/mips/gt64120/wrppmc/irq.c mips/arch/mips/gt64120/wrppmc/irq.c --- mips-orig/arch/mips/gt64120/wrppmc/irq.c 2007-10-09 23:49:54.264557000 +0900 +++ mips/arch/mips/gt64120/wrppmc/irq.c 2007-10-09 23:50:40.935473750 +0900 @@ -9,26 +9,13 @@ * Free Software Foundation; either version 2 of the License, or (at your * option) any later version. */ -#include +#include #include -#include -#include -#include -#include -#include -#include -#include -#include -#include -#include -#include -#include -#include -#include -#include -#include -#include +#include + #include +#include +#include asmlinkage void plat_irq_dispatch(void) { diff -pruN -X mips/Documentation/dontdiff mips-orig/arch/mips/gt64120/wrppmc/pci.c mips/arch/mips/gt64120/wrppmc/pci.c --- mips-orig/arch/mips/gt64120/wrppmc/pci.c 2007-10-09 23:49:54.264557000 +0900 +++ mips/arch/mips/gt64120/wrppmc/pci.c 2007-10-09 23:50:00.764963250 +0900 @@ -8,9 +8,10 @@ * for more details. */ #include +#include #include #include -#include + #include extern struct pci_ops gt64xxx_pci0_ops; diff -pruN -X mips/Documentation/dontdiff mips-orig/arch/mips/gt64120/wrppmc/reset.c mips/arch/mips/gt64120/wrppmc/reset.c --- mips-orig/arch/mips/gt64120/wrppmc/reset.c 2007-10-09 23:49:54.264557000 +0900 +++ mips/arch/mips/gt64120/wrppmc/reset.c 2007-10-09 23:50:00.824967000 +0900 @@ -5,14 +5,10 @@ * * Copyright (C) 1997 Ralf Baechle */ -#include -#include -#include -#include -#include -#include -#include +#include + #include +#include void wrppmc_machine_restart(char *command) { diff -pruN -X mips/Documentation/dontdiff mips-orig/arch/mips/gt64120/wrppmc/time.c mips/arch/mips/gt64120/wrppmc/time.c --- mips-orig/arch/mips/gt64120/wrppmc/time.c 2007-10-09 23:49:54.268557250 +0900 +++ mips/arch/mips/gt64120/wrppmc/time.c 2007-10-09 23:50:00.824967000 +0900 @@ -11,18 +11,11 @@ * Copyright (C) 2006, Wind River System Inc. */ #include -#include -#include -#include /* for HZ */ -#include -#include #include +#include -#include -#include -#include -#include #include +#include #define WRPPMC_CPU_CLK_FREQ 40000000 /* 40MHZ */ From ralf@linux-mips.org Tue Oct 9 16:34:18 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 09 Oct 2007 16:34:20 +0100 (BST) Received: from localhost.localdomain ([127.0.0.1]:48872 "EHLO dl5rb.ham-radio-op.net") by ftp.linux-mips.org with ESMTP id S20024082AbXJIPeS (ORCPT ); Tue, 9 Oct 2007 16:34:18 +0100 Received: from denk.linux-mips.net (denk.linux-mips.net [127.0.0.1]) by dl5rb.ham-radio-op.net (8.14.1/8.13.8) with ESMTP id l99FYIn6027970; Tue, 9 Oct 2007 16:34:18 +0100 Received: (from ralf@localhost) by denk.linux-mips.net (8.14.1/8.14.1/Submit) id l99FYHqv027969; Tue, 9 Oct 2007 16:34:17 +0100 Date: Tue, 9 Oct 2007 16:34:17 +0100 From: Ralf Baechle To: Yoichi Yuasa Cc: linux-mips Subject: Re: fix cpu_type_enum Message-ID: <20071009153417.GA27963@linux-mips.org> References: <20071010000124.c1f995bc.yoichi_yuasa@tripeaks.co.jp> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20071010000124.c1f995bc.yoichi_yuasa@tripeaks.co.jp> User-Agent: Mutt/1.5.14 (2007-02-12) Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 16907 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: ralf@linux-mips.org Precedence: bulk X-list: linux-mips On Wed, Oct 10, 2007 at 12:01:24AM +0900, Yoichi Yuasa wrote: > http://www.linux-mips.org/git?p=linux-queue.git;a=commit;h=74b4db70cfaa5809eb684bccd5e57150e5149b1d Thanks, fixed. Ralf From ralf@linux-mips.org Tue Oct 9 16:47:09 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 09 Oct 2007 16:47:12 +0100 (BST) Received: from localhost.localdomain ([127.0.0.1]:2764 "EHLO dl5rb.ham-radio-op.net") by ftp.linux-mips.org with ESMTP id S20024213AbXJIPrJ (ORCPT ); Tue, 9 Oct 2007 16:47:09 +0100 Received: from denk.linux-mips.net (denk.linux-mips.net [127.0.0.1]) by dl5rb.ham-radio-op.net (8.14.1/8.13.8) with ESMTP id l99Fl7s8018547; Tue, 9 Oct 2007 16:47:07 +0100 Received: (from ralf@localhost) by denk.linux-mips.net (8.14.1/8.14.1/Submit) id l99Fl7IT018504; Tue, 9 Oct 2007 16:47:07 +0100 Date: Tue, 9 Oct 2007 16:47:07 +0100 From: Ralf Baechle To: Yoichi Yuasa Cc: linux-mips Subject: Re: [PATCH][MIPS] cleanup WRPPMC include files Message-ID: <20071009154706.GB27963@linux-mips.org> References: <20071010002826.5a85efc5.yoichi_yuasa@tripeaks.co.jp> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20071010002826.5a85efc5.yoichi_yuasa@tripeaks.co.jp> User-Agent: Mutt/1.5.14 (2007-02-12) Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 16908 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: ralf@linux-mips.org Precedence: bulk X-list: linux-mips On Wed, Oct 10, 2007 at 12:28:26AM +0900, Yoichi Yuasa wrote: Thanks, queued up ... Ralf From vagabon.xyz@gmail.com Tue Oct 9 21:18:34 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 09 Oct 2007 21:18:42 +0100 (BST) Received: from nf-out-0910.google.com ([64.233.182.184]:12694 "EHLO nf-out-0910.google.com") by ftp.linux-mips.org with ESMTP id S20022028AbXJIUSe (ORCPT ); Tue, 9 Oct 2007 21:18:34 +0100 Received: by nf-out-0910.google.com with SMTP id c10so1323285nfd for ; Tue, 09 Oct 2007 13:18:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding; bh=rIwpyXM1p+lsUdds5T3eihybHiUr7fN5fzLPfuEWi3c=; b=Pq/gD/oddRuHqT9MLDg9d7UpSxsaY0eyMKHgzaKMuAzl66XdHq+JKrEhejNKK03nkVDVnKKUgfC5OosLkgnbnxkBaF/Na+a3sPht9gSCFzbOHmwmD+dfev60gntbNeTOn14ZOCzFDDacOsPq6tHBn8Xcrx4bxVkbUR+daum3y64= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding; b=l54EMSsYdEDJZJxqaXcPjzt47Fto/Czqsc55au8x7/x+tVvtnjQjjr9tKtLZhrwV4reZDGB22OuTBxKb6J5Ygt2vZLM78YbszkriSj4uWzpfZSoX96nqEtVoDuLCbitmrxTEle4AXbgrhGWLqqWwsQWxWHqRDSs69BHHku2/D+4= Received: by 10.86.28.5 with SMTP id b5mr6277600fgb.1191961096131; Tue, 09 Oct 2007 13:18:16 -0700 (PDT) Received: from ?192.168.0.1? ( [82.235.205.153]) by mx.google.com with ESMTPS id m1sm14342779fke.2007.10.09.13.18.14 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 09 Oct 2007 13:18:14 -0700 (PDT) Message-ID: <470BE1F4.3070800@gmail.com> Date: Tue, 09 Oct 2007 22:17:56 +0200 From: Franck Bui-Huu User-Agent: Thunderbird 2.0.0.5 (X11/20070719) MIME-Version: 1.0 To: "Maciej W. Rozycki" CC: Ralf Baechle , Thiemo Seufer , linux-mips@linux-mips.org Subject: Re: [PATCH] mm/pg-r4k.c: Dump the generated code References: <20071002141125.GC16772@networkno.de> <20071002154918.GA11312@linux-mips.org> <47038874.9050704@gmail.com> <20071003131158.GL16772@networkno.de> <4703F155.4000301@gmail.com> <20071003201800.GP16772@networkno.de> <47049734.6050802@gmail.com> <20071004121557.GA28928@linux-mips.org> <4705004C.5000705@gmail.com> <4705EFE5.7090704@gmail.com> <470A4349.9090301@gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 16909 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: vagabon.xyz@gmail.com Precedence: bulk X-list: linux-mips Maciej W. Rozycki wrote: > What would be the gain for the kernel from using "-march=4ksd" rather > than "-march=mips32r2"? > It actually results in a kernel image ~30kbytes smaller for the former case. It has been discussed sometimes ago on this list. I'm sorry but I don't know why... > > What if you want to run a single kernel image regardless of the CPU > installed in the system. Rebuilding the kernel (or having to keep a large > collection of binaries) just because you want to swap the CPU does not > seem like a terribly attractive idea. Some systems come with their CPU(s) > on a daughtercard (each), you know... > ok, I wasn't aware about this. You could have started by this point ;) So now I think the right direction is to stick with tlbex.c and make it smaller like Ralf did. Thanks, Franck From vagabon.xyz@gmail.com Tue Oct 9 21:20:42 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 09 Oct 2007 21:20:50 +0100 (BST) Received: from nf-out-0910.google.com ([64.233.182.188]:38049 "EHLO nf-out-0910.google.com") by ftp.linux-mips.org with ESMTP id S20022087AbXJIUUm (ORCPT ); Tue, 9 Oct 2007 21:20:42 +0100 Received: by nf-out-0910.google.com with SMTP id c10so1323819nfd for ; Tue, 09 Oct 2007 13:20:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding; bh=CW3hLTrKrKfGQAFKGRXrvTOOhS1usIbfwtC6yXxO9oo=; b=jN7uOUGr94tYTMd3APfSxFSjEb3mi7LafFNOFOYiuyC31HDXA8iQwsUWFUnaaaG8OGOnUHIDEplkI7MVZZw1HunnuZdH5z/U6MMmX7gGTpIUIOI0un1Ey95bLhNtYkxQnSk8tcXfKLON7GHyw1Zw/M56xdVsBHcml5ZZP9nDT0Q= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding; b=qF4UgqB/ZR2dveetDMfiA1yzhk6BYDXxQ5gP/JevWyI2eVLQmEB+lHjw0OJcEQnpCRtpx62L/SjKW5R5OTekont2dBa4SXWKDoxs2v7tZS/rqshwxT8rW4zWL2xIBVmOyqyI0ySftmG44hnkP1c/sl1qiQn4AzxFCLyYFg68sm4= Received: by 10.86.80.5 with SMTP id d5mr6295224fgb.1191961224532; Tue, 09 Oct 2007 13:20:24 -0700 (PDT) Received: from ?192.168.0.1? ( [82.235.205.153]) by mx.google.com with ESMTPS id 22sm14366850fkr.2007.10.09.13.20.23 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 09 Oct 2007 13:20:23 -0700 (PDT) Message-ID: <470BE276.8050200@gmail.com> Date: Tue, 09 Oct 2007 22:20:06 +0200 From: Franck Bui-Huu User-Agent: Thunderbird 2.0.0.5 (X11/20070719) MIME-Version: 1.0 To: Geert Uytterhoeven CC: "Maciej W. Rozycki" , Ralf Baechle , Thiemo Seufer , linux-mips@linux-mips.org Subject: Re: [PATCH] mm/pg-r4k.c: Dump the generated code References: <20071002141125.GC16772@networkno.de> <20071002154918.GA11312@linux-mips.org> <47038874.9050704@gmail.com> <20071003131158.GL16772@networkno.de> <4703F155.4000301@gmail.com> <20071003201800.GP16772@networkno.de> <47049734.6050802@gmail.com> <20071004121557.GA28928@linux-mips.org> <4705004C.5000705@gmail.com> <4705EFE5.7090704@gmail.com> <470A4673.30604@gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 16910 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: vagabon.xyz@gmail.com Precedence: bulk X-list: linux-mips Geert Uytterhoeven wrote: > Can't you currently compile a kernel that run on e.g. all O2s, > irrespective of the actual CPU type? > It seems so, I've just been teached about it actually. So I think we just have to stick with tlbex.c and perhaps make it smaller... Thanks, Franck From andy.sharp@onstor.com Tue Oct 9 21:27:25 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 09 Oct 2007 21:27:34 +0100 (BST) Received: from mail.onstor.com ([66.201.51.107]:45713 "EHLO mail.onstor.com") by ftp.linux-mips.org with ESMTP id S20022131AbXJIU1Z (ORCPT ); Tue, 9 Oct 2007 21:27:25 +0100 Received: from onstor-exch02.onstor.net ([66.201.51.106]) by mail.onstor.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 9 Oct 2007 13:26:57 -0700 Received: from ripper.onstor.net ([10.0.0.42]) by onstor-exch02.onstor.net with Microsoft SMTPSVC(6.0.3790.1830); Tue, 9 Oct 2007 13:26:57 -0700 Date: Tue, 9 Oct 2007 13:26:57 -0700 From: Andrew Sharp To: linux-mips@linux-mips.org Subject: paging problem with ide-cs driver Message-ID: <20071009132657.64ec9158@ripper.onstor.net> Organization: Onstor X-Mailer: Sylpheed-Claws 2.6.0 (GTK+ 2.8.20; x86_64-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 09 Oct 2007 20:26:57.0426 (UTC) FILETIME=[BD2B7F20:01C80AB2] Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 16911 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: andy.sharp@onstor.com Precedence: bulk X-list: linux-mips I'm having a problem with paging through the ide-cs driver. As best I can tell right now, the kernel thinks the data is present and valid when it actually isn't. This is lmo 2.6.22.3, on a sibyte 1125H, but I had the same problem with 2.6.20.something on an R9k based machine. I can make a filesystem (ext3) on the CF card, mount it, read and write to it. But I can't chroot to it, can't set LD_LIBRARY_PATH to it, can't use it as the root filesystem. The chroot failure is the most telling. When I try to chroot to it, I get various segfault, bus error, illegal instruction, etc. But if I continue to try it, after 10-12 tries, it succeeds. This tells me that the data eventually arrives, it's just that the kernel tries to use a page before the data is valid. Before I dive into this, does any of this ring a bell for anyone? I'm using the ide-cs driver, TI yenta cardbus adapter driver, and sibyte everything else. I can provide kernel output if anyone is interested in that. But there isn't any kernel output when the failure occurs, the thread just dies with one of the various mentioned errors. coolcat:~# cat /etc/fstab proc /proc proc defaults 0 0 10.0.0.42:/var/nfsroot/cougar / nfs defaults 0 0 tmpfs /tmp tmpfs defaults,size=12m 0 0 coolcat:~# chroot /mnt Illegal instruction coolcat:~# chroot /mnt Illegal instruction coolcat:~# chroot /mnt Segmentation fault coolcat:~# chroot /mnt Segmentation fault coolcat:~# chroot /mnt Illegal instruction coolcat:~# chroot /mnt Illegal instruction coolcat:~# chroot /mnt Illegal instruction coolcat:~# chroot /mnt Segmentation fault coolcat:~# chroot /mnt Segmentation fault coolcat:~# chroot /mnt coolcat:/# coolcat:/# cat /etc/fstab Segmentation fault coolcat:/# cat /etc/fstab proc /proc proc defaults 0 0 /dev/hda2 / ext3 defaults 0 0 tmpfs /tmp tmpfs defaults,size=12m 0 0 coolcat:/# exit From fbuihuu@gmail.com Tue Oct 9 21:33:35 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 09 Oct 2007 21:33:43 +0100 (BST) Received: from nf-out-0910.google.com ([64.233.182.190]:1515 "EHLO nf-out-0910.google.com") by ftp.linux-mips.org with ESMTP id S20022034AbXJIUdf (ORCPT ); Tue, 9 Oct 2007 21:33:35 +0100 Received: by nf-out-0910.google.com with SMTP id c10so1327054nfd for ; Tue, 09 Oct 2007 13:33:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:x-enigmail-version:content-type:content-transfer-encoding; bh=xxpWjs4qdvcJTHzLRUhaXSsLQAXgP5cePMqzI8LmVxM=; b=GHCaJNfaB7JWff/kTB6YIJyTJ9ngmfdsA0dsUPxWIacimhRJHSXjq4KKzzWcRFpM8QiYm3s8/q2Yg0f4F1N7v62vWnRAoPdaa9J+HzHBwHCoxKgCDVivqB0dfkP50CCpKmn1FGxhz/n9gAI2467lK5moIVE9UG8GQJJnxKjFUCQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:x-enigmail-version:content-type:content-transfer-encoding; b=CALsqpDQpeaft/lHNRH64BITBHh88GWa/LX0uJMjeIq2n3bbhVdT+6FKgWIzfZqjeHPzV0JYAE2QyrDpbbFyE6UCYYvIFqI+j5yYoKaiYOBAGQOr9bxaSwMz1ij6jWdLkVnzZKL714M12wFSNpSmH0jLRiXgvKcKRTYMg2PLiT4= Received: by 10.86.78.4 with SMTP id a4mr6304494fgb.1191962014146; Tue, 09 Oct 2007 13:33:34 -0700 (PDT) Received: from ?192.168.0.1? ( [82.235.205.153]) by mx.google.com with ESMTPS id o11sm9142698fkf.2007.10.09.13.33.32 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 09 Oct 2007 13:33:32 -0700 (PDT) Message-ID: <470BE58A.9070709@gmail.com> Date: Tue, 09 Oct 2007 22:33:14 +0200 From: Franck Bui-Huu User-Agent: Thunderbird 2.0.0.5 (X11/20070719) MIME-Version: 1.0 To: Ralf Baechle CC: Thiemo Seufer , "Maciej W. Rozycki" , linux-mips@linux-mips.org Subject: Re: [PATCH] mm/pg-r4k.c: Dump the generated code References: <20071002141125.GC16772@networkno.de> <20071002154918.GA11312@linux-mips.org> <47038874.9050704@gmail.com> <20071003131158.GL16772@networkno.de> <4703F155.4000301@gmail.com> <20071003201800.GP16772@networkno.de> <47049734.6050802@gmail.com> <20071004121557.GA28928@linux-mips.org> <4705004C.5000705@gmail.com> <20071005115151.GA16145@linux-mips.org> In-Reply-To: <20071005115151.GA16145@linux-mips.org> X-Enigmail-Version: 0.95.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 16912 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: fbuihuu@gmail.com Precedence: bulk X-list: linux-mips Ralf Baechle wrote: > So I did a few experiments. This is the size of tlbex for a malta_defconfig I did too and it results into the patchset I'm going to send. Basically it removes all arrays from the init.data section and make them automatic variables. So it's pretty extreme and maybe if the stack pressure is too high, we could balance it. This is done by patch 2,3,4. text data bss dec hex filename 9840 3904 1568 15312 3bd0 arch/mips/mm/tlbex.o~before 9776 576 1568 11920 2e90 arch/mips/mm/tlbex.o~after While I was at it, I did some trivial cleanups witch patch 1,5,6. Thanks, Franck From fbuihuu@gmail.com Tue Oct 9 21:35:07 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 09 Oct 2007 21:35:17 +0100 (BST) Received: from nf-out-0910.google.com ([64.233.182.189]:36083 "EHLO nf-out-0910.google.com") by ftp.linux-mips.org with ESMTP id S20022194AbXJIUfH (ORCPT ); Tue, 9 Oct 2007 21:35:07 +0100 Received: by nf-out-0910.google.com with SMTP id c10so1327345nfd for ; Tue, 09 Oct 2007 13:34:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:x-enigmail-version:content-type:content-transfer-encoding; bh=IK3KMqki2pK2uKp/1qvU7CvvR5hAco/Ou9PAFH6gX6E=; b=QhT1rEvW2I4uDtGJw3yeVMQ8hhVUHw9J7prUv8TKnHg4obuMDN14uDLjGjoCaYN03SlcaY2INIbehyVoE8hpgpF6tyrgwpPzmfswvtKI3KEFX4TZnvttFEsmcmLkUX7226mNgYJVAt2x5SrN377UvDO1XHfZMY4zDV7xUpbT6tE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:x-enigmail-version:content-type:content-transfer-encoding; b=dp+aSxgfxZJcvz1A/Krk+gmrCv8boaXKeb8sUdFtnho+QEokeKe2GCH/s70U2cVuQm/tc04bL3jk3sy2PS6u8ZK5O1Pcade8fsXJHzQBiluuhhbgiNJuHBsD+QkBHYxU/2u1vQ1NrmSBYFPl41yFzMuR7getP4234Ler29/mVaU= Received: by 10.86.70.8 with SMTP id s8mr6302986fga.1191962089502; Tue, 09 Oct 2007 13:34:49 -0700 (PDT) Received: from ?192.168.0.1? ( [82.235.205.153]) by mx.google.com with ESMTPS id e32sm14347464fke.2007.10.09.13.34.43 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 09 Oct 2007 13:34:44 -0700 (PDT) Message-ID: <470BE5D2.50101@gmail.com> Date: Tue, 09 Oct 2007 22:34:26 +0200 From: Franck Bui-Huu User-Agent: Thunderbird 2.0.0.5 (X11/20070719) MIME-Version: 1.0 To: Franck Bui-Huu CC: Ralf Baechle , Thiemo Seufer , "Maciej W. Rozycki" , linux-mips@linux-mips.org Subject: [PATCH 1/6] tlbex.c: Cleanup __init usages. References: <20071002141125.GC16772@networkno.de> <20071002154918.GA11312@linux-mips.org> <47038874.9050704@gmail.com> <20071003131158.GL16772@networkno.de> <4703F155.4000301@gmail.com> <20071003201800.GP16772@networkno.de> <47049734.6050802@gmail.com> <20071004121557.GA28928@linux-mips.org> <4705004C.5000705@gmail.com> <20071005115151.GA16145@linux-mips.org> <470BE58A.9070709@gmail.com> In-Reply-To: <470BE58A.9070709@gmail.com> X-Enigmail-Version: 0.95.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 16913 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: fbuihuu@gmail.com Precedence: bulk X-list: linux-mips Signed-off-by: Franck Bui-Huu --- arch/mips/mm/tlbex.c | 96 +++++++++++++++++++++++++------------------------- 1 files changed, 48 insertions(+), 48 deletions(-) diff --git a/arch/mips/mm/tlbex.c b/arch/mips/mm/tlbex.c index a61246d..01b0961 100644 --- a/arch/mips/mm/tlbex.c +++ b/arch/mips/mm/tlbex.c @@ -66,7 +66,7 @@ static inline int __maybe_unused r10000_llsc_war(void) * why; it's not an issue caused by the core RTL. * */ -static __init int __attribute__((unused)) m4kc_tlbp_war(void) +static int __init m4kc_tlbp_war(void) { return (current_cpu_data.processor_id & 0xffff00) == (PRID_COMP_MIPS | PRID_IMP_4KC); @@ -140,7 +140,7 @@ struct insn { | (e) << RE_SH \ | (f) << FUNC_SH) -static __initdata struct insn insn_table[] = { +static struct insn insn_table[] __initdata = { { insn_addiu, M(addiu_op, 0, 0, 0, 0, 0), RS | RT | SIMM }, { insn_addu, M(spec_op, 0, 0, 0, 0, addu_op), RS | RT | RD }, { insn_and, M(spec_op, 0, 0, 0, 0, and_op), RS | RT | RD }, @@ -193,7 +193,7 @@ static __initdata struct insn insn_table[] = { #undef M -static __init u32 build_rs(u32 arg) +static u32 __init build_rs(u32 arg) { if (arg & ~RS_MASK) printk(KERN_WARNING "TLB synthesizer field overflow\n"); @@ -201,7 +201,7 @@ static __init u32 build_rs(u32 arg) return (arg & RS_MASK) << RS_SH; } -static __init u32 build_rt(u32 arg) +static u32 __init build_rt(u32 arg) { if (arg & ~RT_MASK) printk(KERN_WARNING "TLB synthesizer field overflow\n"); @@ -209,7 +209,7 @@ static __init u32 build_rt(u32 arg) return (arg & RT_MASK) << RT_SH; } -static __init u32 build_rd(u32 arg) +static u32 __init build_rd(u32 arg) { if (arg & ~RD_MASK) printk(KERN_WARNING "TLB synthesizer field overflow\n"); @@ -217,7 +217,7 @@ static __init u32 build_rd(u32 arg) return (arg & RD_MASK) << RD_SH; } -static __init u32 build_re(u32 arg) +static u32 __init build_re(u32 arg) { if (arg & ~RE_MASK) printk(KERN_WARNING "TLB synthesizer field overflow\n"); @@ -225,7 +225,7 @@ static __init u32 build_re(u32 arg) return (arg & RE_MASK) << RE_SH; } -static __init u32 build_simm(s32 arg) +static u32 __init build_simm(s32 arg) { if (arg > 0x7fff || arg < -0x8000) printk(KERN_WARNING "TLB synthesizer field overflow\n"); @@ -233,7 +233,7 @@ static __init u32 build_simm(s32 arg) return arg & 0xffff; } -static __init u32 build_uimm(u32 arg) +static u32 __init build_uimm(u32 arg) { if (arg & ~IMM_MASK) printk(KERN_WARNING "TLB synthesizer field overflow\n"); @@ -241,7 +241,7 @@ static __init u32 build_uimm(u32 arg) return arg & IMM_MASK; } -static __init u32 build_bimm(s32 arg) +static u32 __init build_bimm(s32 arg) { if (arg > 0x1ffff || arg < -0x20000) printk(KERN_WARNING "TLB synthesizer field overflow\n"); @@ -252,7 +252,7 @@ static __init u32 build_bimm(s32 arg) return ((arg < 0) ? (1 << 15) : 0) | ((arg >> 2) & 0x7fff); } -static __init u32 build_jimm(u32 arg) +static u32 __init build_jimm(u32 arg) { if (arg & ~((JIMM_MASK) << 2)) printk(KERN_WARNING "TLB synthesizer field overflow\n"); @@ -260,7 +260,7 @@ static __init u32 build_jimm(u32 arg) return (arg >> 2) & JIMM_MASK; } -static __init u32 build_func(u32 arg) +static u32 __init build_func(u32 arg) { if (arg & ~FUNC_MASK) printk(KERN_WARNING "TLB synthesizer field overflow\n"); @@ -268,7 +268,7 @@ static __init u32 build_func(u32 arg) return arg & FUNC_MASK; } -static __init u32 build_set(u32 arg) +static u32 __init build_set(u32 arg) { if (arg & ~SET_MASK) printk(KERN_WARNING "TLB synthesizer field overflow\n"); @@ -315,69 +315,69 @@ static void __init build_insn(u32 **buf, enum opcode opc, ...) } #define I_u1u2u3(op) \ - static inline void __init i##op(u32 **buf, unsigned int a, \ + static inline void i##op(u32 **buf, unsigned int a, \ unsigned int b, unsigned int c) \ { \ build_insn(buf, insn##op, a, b, c); \ } #define I_u2u1u3(op) \ - static inline void __init i##op(u32 **buf, unsigned int a, \ + static inline void i##op(u32 **buf, unsigned int a, \ unsigned int b, unsigned int c) \ { \ build_insn(buf, insn##op, b, a, c); \ } #define I_u3u1u2(op) \ - static inline void __init i##op(u32 **buf, unsigned int a, \ + static inline void i##op(u32 **buf, unsigned int a, \ unsigned int b, unsigned int c) \ { \ build_insn(buf, insn##op, b, c, a); \ } #define I_u1u2s3(op) \ - static inline void __init i##op(u32 **buf, unsigned int a, \ + static inline void i##op(u32 **buf, unsigned int a, \ unsigned int b, signed int c) \ { \ build_insn(buf, insn##op, a, b, c); \ } #define I_u2s3u1(op) \ - static inline void __init i##op(u32 **buf, unsigned int a, \ + static inline void i##op(u32 **buf, unsigned int a, \ signed int b, unsigned int c) \ { \ build_insn(buf, insn##op, c, a, b); \ } #define I_u2u1s3(op) \ - static inline void __init i##op(u32 **buf, unsigned int a, \ + static inline void i##op(u32 **buf, unsigned int a, \ unsigned int b, signed int c) \ { \ build_insn(buf, insn##op, b, a, c); \ } #define I_u1u2(op) \ - static inline void __init i##op(u32 **buf, unsigned int a, \ + static inline void i##op(u32 **buf, unsigned int a, \ unsigned int b) \ { \ build_insn(buf, insn##op, a, b); \ } #define I_u1s2(op) \ - static inline void __init i##op(u32 **buf, unsigned int a, \ + static inline void i##op(u32 **buf, unsigned int a, \ signed int b) \ { \ build_insn(buf, insn##op, a, b); \ } #define I_u1(op) \ - static inline void __init i##op(u32 **buf, unsigned int a) \ + static inline void i##op(u32 **buf, unsigned int a) \ { \ build_insn(buf, insn##op, a); \ } #define I_0(op) \ - static inline void __init i##op(u32 **buf) \ + static inline void i##op(u32 **buf) \ { \ build_insn(buf, insn##op); \ } @@ -457,7 +457,7 @@ struct label { enum label_id lab; }; -static __init void build_label(struct label **lab, u32 *addr, +static void __init build_label(struct label **lab, u32 *addr, enum label_id l) { (*lab)->addr = addr; @@ -526,34 +526,34 @@ L_LA(_r3000_write_probe_fail) #define i_ehb(buf) i_sll(buf, 0, 0, 3) #ifdef CONFIG_64BIT -static __init int __maybe_unused in_compat_space_p(long addr) +static int __init __maybe_unused in_compat_space_p(long addr) { /* Is this address in 32bit compat space? */ return (((addr) & 0xffffffff00000000L) == 0xffffffff00000000L); } -static __init int __maybe_unused rel_highest(long val) +static int __init __maybe_unused rel_highest(long val) { return ((((val + 0x800080008000L) >> 48) & 0xffff) ^ 0x8000) - 0x8000; } -static __init int __maybe_unused rel_higher(long val) +static int __init __maybe_unused rel_higher(long val) { return ((((val + 0x80008000L) >> 32) & 0xffff) ^ 0x8000) - 0x8000; } #endif -static __init int rel_hi(long val) +static int __init rel_hi(long val) { return ((((val + 0x8000L) >> 16) & 0xffff) ^ 0x8000) - 0x8000; } -static __init int rel_lo(long val) +static int __init rel_lo(long val) { return ((val & 0xffff) ^ 0x8000) - 0x8000; } -static __init void i_LA_mostly(u32 **buf, unsigned int rs, long addr) +static void __init i_LA_mostly(u32 **buf, unsigned int rs, long addr) { #ifdef CONFIG_64BIT if (!in_compat_space_p(addr)) { @@ -571,7 +571,7 @@ static __init void i_LA_mostly(u32 **buf, unsigned int rs, long addr) i_lui(buf, rs, rel_hi(addr)); } -static __init void __maybe_unused i_LA(u32 **buf, unsigned int rs, +static void __init __maybe_unused i_LA(u32 **buf, unsigned int rs, long addr) { i_LA_mostly(buf, rs, addr); @@ -589,7 +589,7 @@ struct reloc { enum label_id lab; }; -static __init void r_mips_pc16(struct reloc **rel, u32 *addr, +static void __init r_mips_pc16(struct reloc **rel, u32 *addr, enum label_id l) { (*rel)->addr = addr; @@ -614,7 +614,7 @@ static inline void __resolve_relocs(struct reloc *rel, struct label *lab) } } -static __init void resolve_relocs(struct reloc *rel, struct label *lab) +static void __init resolve_relocs(struct reloc *rel, struct label *lab) { struct label *l; @@ -624,7 +624,7 @@ static __init void resolve_relocs(struct reloc *rel, struct label *lab) __resolve_relocs(rel, l); } -static __init void move_relocs(struct reloc *rel, u32 *first, u32 *end, +static void __init move_relocs(struct reloc *rel, u32 *first, u32 *end, long off) { for (; rel->lab != label_invalid; rel++) @@ -632,7 +632,7 @@ static __init void move_relocs(struct reloc *rel, u32 *first, u32 *end, rel->addr += off; } -static __init void move_labels(struct label *lab, u32 *first, u32 *end, +static void __init move_labels(struct label *lab, u32 *first, u32 *end, long off) { for (; lab->lab != label_invalid; lab++) @@ -640,7 +640,7 @@ static __init void move_labels(struct label *lab, u32 *first, u32 *end, lab->addr += off; } -static __init void copy_handler(struct reloc *rel, struct label *lab, +static void __init copy_handler(struct reloc *rel, struct label *lab, u32 *first, u32 *end, u32 *target) { long off = (long)(target - first); @@ -651,7 +651,7 @@ static __init void copy_handler(struct reloc *rel, struct label *lab, move_labels(lab, first, end, off); } -static __init int __maybe_unused insn_has_bdelay(struct reloc *rel, +static int __init __maybe_unused insn_has_bdelay(struct reloc *rel, u32 *addr) { for (; rel->lab != label_invalid; rel++) { @@ -743,11 +743,11 @@ il_bgez(u32 **p, struct reloc **r, unsigned int reg, enum label_id l) * We deliberately chose a buffer size of 128, so we won't scribble * over anything important on overflow before we panic. */ -static __initdata u32 tlb_handler[128]; +static u32 tlb_handler[128] __initdata; /* simply assume worst case size for labels and relocs */ -static __initdata struct label labels[128]; -static __initdata struct reloc relocs[128]; +static struct label labels[128] __initdata; +static struct reloc relocs[128] __initdata; /* * The R3000 TLB handler is simple. @@ -801,7 +801,7 @@ static void __init build_r3000_tlb_refill_handler(void) * other one.To keep things simple, we first assume linear space, * then we relocate it to the final handler layout as needed. */ -static __initdata u32 final_handler[64]; +static u32 final_handler[64] __initdata; /* * Hazards @@ -825,7 +825,7 @@ static __initdata u32 final_handler[64]; * * As if we MIPS hackers wouldn't know how to nop pipelines happy ... */ -static __init void __maybe_unused build_tlb_probe_entry(u32 **p) +static void __init __maybe_unused build_tlb_probe_entry(u32 **p) { switch (current_cpu_type()) { /* Found by experiment: R4600 v2.0 needs this, too. */ @@ -849,7 +849,7 @@ static __init void __maybe_unused build_tlb_probe_entry(u32 **p) */ enum tlb_write_entry { tlb_random, tlb_indexed }; -static __init void build_tlb_write_entry(u32 **p, struct label **l, +static void __init build_tlb_write_entry(u32 **p, struct label **l, struct reloc **r, enum tlb_write_entry wmode) { @@ -993,7 +993,7 @@ static __init void build_tlb_write_entry(u32 **p, struct label **l, * TMP and PTR are scratch. * TMP will be clobbered, PTR will hold the pmd entry. */ -static __init void +static void __init build_get_pmde64(u32 **p, struct label **l, struct reloc **r, unsigned int tmp, unsigned int ptr) { @@ -1054,7 +1054,7 @@ build_get_pmde64(u32 **p, struct label **l, struct reloc **r, * BVADDR is the faulting address, PTR is scratch. * PTR will hold the pgd for vmalloc. */ -static __init void +static void __init build_get_pgd_vmalloc64(u32 **p, struct label **l, struct reloc **r, unsigned int bvaddr, unsigned int ptr) { @@ -1118,7 +1118,7 @@ build_get_pgd_vmalloc64(u32 **p, struct label **l, struct reloc **r, * TMP and PTR are scratch. * TMP will be clobbered, PTR will hold the pgd entry. */ -static __init void __maybe_unused +static void __init __maybe_unused build_get_pgde32(u32 **p, unsigned int tmp, unsigned int ptr) { long pgdc = (long)pgd_current; @@ -1153,7 +1153,7 @@ build_get_pgde32(u32 **p, unsigned int tmp, unsigned int ptr) #endif /* !CONFIG_64BIT */ -static __init void build_adjust_context(u32 **p, unsigned int ctx) +static void __init build_adjust_context(u32 **p, unsigned int ctx) { unsigned int shift = 4 - (PTE_T_LOG2 + 1) + PAGE_SHIFT - 12; unsigned int mask = (PTRS_PER_PTE / 2 - 1) << (PTE_T_LOG2 + 1); @@ -1179,7 +1179,7 @@ static __init void build_adjust_context(u32 **p, unsigned int ctx) i_andi(p, ctx, ctx, mask); } -static __init void build_get_ptep(u32 **p, unsigned int tmp, unsigned int ptr) +static void __init build_get_ptep(u32 **p, unsigned int tmp, unsigned int ptr) { /* * Bug workaround for the Nevada. It seems as if under certain @@ -1204,7 +1204,7 @@ static __init void build_get_ptep(u32 **p, unsigned int tmp, unsigned int ptr) i_ADDU(p, ptr, ptr, tmp); /* add in offset */ } -static __init void build_update_entries(u32 **p, unsigned int tmp, +static void __init build_update_entries(u32 **p, unsigned int tmp, unsigned int ptep) { /* From fbuihuu@gmail.com Tue Oct 9 21:36:22 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 09 Oct 2007 21:36:30 +0100 (BST) Received: from mu-out-0910.google.com ([209.85.134.187]:62212 "EHLO mu-out-0910.google.com") by ftp.linux-mips.org with ESMTP id S20022204AbXJIUgW (ORCPT ); Tue, 9 Oct 2007 21:36:22 +0100 Received: by mu-out-0910.google.com with SMTP id w1so2123556mue for ; Tue, 09 Oct 2007 13:36:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:user-agent:mime-version:cc:subject:references:in-reply-to:x-enigmail-version:content-type:content-transfer-encoding; bh=Y7t3E1Z2CnqTWGuDKAfp836D9SeIropPChYkJFyKpoo=; b=ap86wPGJrYc45JycIoGExftu50v3T/wSND1/VweiHpYU2YPDqVWFVN8uFORUB4Gm0CokVE8HgMvQABxaG1NANGAnBiFhnVMrkadobPCqYZY1l3nQ3pFL34VSjZoA1yL3eCUmKW8Dll97ULDhhtNkTr8peCFBMDH9B33Jw2sYlK0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:user-agent:mime-version:cc:subject:references:in-reply-to:x-enigmail-version:content-type:content-transfer-encoding; b=HRfrbbDjHqeYdBKVaQwKg5R7JdOhA7qnDdVy/vnxD1wVrWLnwwSCb/5SAPVyQEbe+Nm9J33M/ZH2EvNRgKQSlEhjKTqGLP1tWK/ohzpwEF3tKr7SgHR3sfQVjO1mJcoiGotN+A8CjaOW5sCJuxW21BmLZh5x3kVkXDVtbCWFJrM= Received: by 10.82.134.12 with SMTP id h12mr8659161bud.1191962163091; Tue, 09 Oct 2007 13:36:03 -0700 (PDT) Received: from ?192.168.0.1? ( [82.235.205.153]) by mx.google.com with ESMTPS id i5sm16667672mue.2007.10.09.13.36.00 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 09 Oct 2007 13:36:01 -0700 (PDT) Message-ID: <470BE61F.5020108@gmail.com> Date: Tue, 09 Oct 2007 22:35:43 +0200 From: Franck Bui-Huu User-Agent: Thunderbird 2.0.0.5 (X11/20070719) MIME-Version: 1.0 CC: Ralf Baechle , Thiemo Seufer , "Maciej W. Rozycki" , linux-mips@linux-mips.org Subject: [PATCH 2/6] tlbex.c: Remove relocs[] and labels[] from the init.data section References: <20071002141125.GC16772@networkno.de> <20071002154918.GA11312@linux-mips.org> <47038874.9050704@gmail.com> <20071003131158.GL16772@networkno.de> <4703F155.4000301@gmail.com> <20071003201800.GP16772@networkno.de> <47049734.6050802@gmail.com> <20071004121557.GA28928@linux-mips.org> <4705004C.5000705@gmail.com> <20071005115151.GA16145@linux-mips.org> <470BE58A.9070709@gmail.com> In-Reply-To: <470BE58A.9070709@gmail.com> X-Enigmail-Version: 0.95.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit To: unlisted-recipients:; (no To-header on input) Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 16914 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: fbuihuu@gmail.com Precedence: bulk X-list: linux-mips This patch reduces the kernel image size by making these 2 arrays automatic variables. tlbex.o~old => tlbex.o text: 9840 9812 -28 0% data: 3904 1344 -2560 -65% bss: 1568 1568 0 0% total: 15312 12724 -2588 -16% It increases the stack pressure a lot (more than 2500 bytes) but at this stage in the boot process, it shouldn't matter. Futhermore the TLB handler generator code doesn't have any deep call graph and probably won't. Signed-off-by: Franck Bui-Huu --- arch/mips/mm/tlbex.c | 32 ++++++++++++++------------------ 1 files changed, 14 insertions(+), 18 deletions(-) diff --git a/arch/mips/mm/tlbex.c b/arch/mips/mm/tlbex.c index 01b0961..ae1bf81 100644 --- a/arch/mips/mm/tlbex.c +++ b/arch/mips/mm/tlbex.c @@ -745,10 +745,6 @@ il_bgez(u32 **p, struct reloc **r, unsigned int reg, enum label_id l) */ static u32 tlb_handler[128] __initdata; -/* simply assume worst case size for labels and relocs */ -static struct label labels[128] __initdata; -static struct reloc relocs[128] __initdata; - /* * The R3000 TLB handler is simple. */ @@ -1250,8 +1246,8 @@ static void __init build_update_entries(u32 **p, unsigned int tmp, static void __init build_r4000_tlb_refill_handler(void) { u32 *p = tlb_handler; - struct label *l = labels; - struct reloc *r = relocs; + struct label labels[128], *l = labels; + struct reloc relocs[128], *r = relocs; u32 *f; unsigned int final_len; int i; @@ -1598,8 +1594,8 @@ build_r3000_tlbchange_handler_head(u32 **p, unsigned int pte, static void __init build_r3000_tlb_load_handler(void) { u32 *p = handle_tlbl; - struct label *l = labels; - struct reloc *r = relocs; + struct label labels[FASTPATH_SIZE], *l = labels; + struct reloc relocs[FASTPATH_SIZE], *r = relocs; int i; memset(handle_tlbl, 0, sizeof(handle_tlbl)); @@ -1633,8 +1629,8 @@ static void __init build_r3000_tlb_load_handler(void) static void __init build_r3000_tlb_store_handler(void) { u32 *p = handle_tlbs; - struct label *l = labels; - struct reloc *r = relocs; + struct label labels[FASTPATH_SIZE], *l = labels; + struct reloc relocs[FASTPATH_SIZE], *r = relocs; int i; memset(handle_tlbs, 0, sizeof(handle_tlbs)); @@ -1668,8 +1664,8 @@ static void __init build_r3000_tlb_store_handler(void) static void __init build_r3000_tlb_modify_handler(void) { u32 *p = handle_tlbm; - struct label *l = labels; - struct reloc *r = relocs; + struct label labels[FASTPATH_SIZE], *l = labels; + struct reloc relocs[FASTPATH_SIZE], *r = relocs; int i; memset(handle_tlbm, 0, sizeof(handle_tlbm)); @@ -1748,8 +1744,8 @@ build_r4000_tlbchange_handler_tail(u32 **p, struct label **l, static void __init build_r4000_tlb_load_handler(void) { u32 *p = handle_tlbl; - struct label *l = labels; - struct reloc *r = relocs; + struct label labels[FASTPATH_SIZE], *l = labels; + struct reloc relocs[FASTPATH_SIZE], *r = relocs; int i; memset(handle_tlbl, 0, sizeof(handle_tlbl)); @@ -1793,8 +1789,8 @@ static void __init build_r4000_tlb_load_handler(void) static void __init build_r4000_tlb_store_handler(void) { u32 *p = handle_tlbs; - struct label *l = labels; - struct reloc *r = relocs; + struct label labels[FASTPATH_SIZE], *l = labels; + struct reloc relocs[FASTPATH_SIZE], *r = relocs; int i; memset(handle_tlbs, 0, sizeof(handle_tlbs)); @@ -1829,8 +1825,8 @@ static void __init build_r4000_tlb_store_handler(void) static void __init build_r4000_tlb_modify_handler(void) { u32 *p = handle_tlbm; - struct label *l = labels; - struct reloc *r = relocs; + struct label labels[FASTPATH_SIZE], *l = labels; + struct reloc relocs[FASTPATH_SIZE], *r = relocs; int i; memset(handle_tlbm, 0, sizeof(handle_tlbm)); -- 1.5.3.3 From fbuihuu@gmail.com Tue Oct 9 21:37:21 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 09 Oct 2007 21:37:30 +0100 (BST) Received: from nf-out-0910.google.com ([64.233.182.184]:50952 "EHLO nf-out-0910.google.com") by ftp.linux-mips.org with ESMTP id S20022184AbXJIUhV (ORCPT ); Tue, 9 Oct 2007 21:37:21 +0100 Received: by nf-out-0910.google.com with SMTP id c10so1327870nfd for ; Tue, 09 Oct 2007 13:37:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:user-agent:mime-version:cc:subject:references:in-reply-to:x-enigmail-version:content-type:content-transfer-encoding; bh=W0WiNFuklsWmjOQ/okiqxMmXDfJObYtAVu995qdt/+I=; b=hVSnwlKJW0bZSL6OOtmbgesvTPhh6UoMJ4z5pZ8WoKGK4Q6kl8jOkL5ZsmaL+1Z7t0uedASP8Hp1t20ecGzpDOqm99zLeIkRJnD4Xu7GRJVt1ozcFC+tSheagIAZytjJE/9Hq4hFD4+f/M1EZg2oAe/sUZhCzrf+SVT8C4NZ7Z4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:user-agent:mime-version:cc:subject:references:in-reply-to:x-enigmail-version:content-type:content-transfer-encoding; b=SyEC5Og5gjDHPK4qg652UH9nBh9vf9lK6VmA5c7FLGD3lcVXXWAGpQrFdRYyavs8JOyXqc85qTyrEdKfutingeF4Ky9ZaULqeJ18kr4I8+I386QofCTf4wVFLaIteMFCFLpUvfRWtQo7Gx/pRF1jkHQ+mvyYfCWMpEWFRrWtAcM= Received: by 10.86.86.12 with SMTP id j12mr6292113fgb.1191962223983; Tue, 09 Oct 2007 13:37:03 -0700 (PDT) Received: from ?192.168.0.1? ( [82.235.205.153]) by mx.google.com with ESMTPS id g8sm16645767muf.2007.10.09.13.37.02 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 09 Oct 2007 13:37:03 -0700 (PDT) Message-ID: <470BE65C.9030407@gmail.com> Date: Tue, 09 Oct 2007 22:36:44 +0200 From: Franck Bui-Huu User-Agent: Thunderbird 2.0.0.5 (X11/20070719) MIME-Version: 1.0 CC: Ralf Baechle , Thiemo Seufer , "Maciej W. Rozycki" , linux-mips@linux-mips.org Subject: [PATCH 3/6] tlbex.c: remove tlb_handler[] from init.data section References: <20071002141125.GC16772@networkno.de> <20071002154918.GA11312@linux-mips.org> <47038874.9050704@gmail.com> <20071003131158.GL16772@networkno.de> <4703F155.4000301@gmail.com> <20071003201800.GP16772@networkno.de> <47049734.6050802@gmail.com> <20071004121557.GA28928@linux-mips.org> <4705004C.5000705@gmail.com> <20071005115151.GA16145@linux-mips.org> <470BE58A.9070709@gmail.com> In-Reply-To: <470BE58A.9070709@gmail.com> X-Enigmail-Version: 0.95.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit To: unlisted-recipients:; (no To-header on input) Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 16915 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: fbuihuu@gmail.com Precedence: bulk X-list: linux-mips This patch makes it an automatic variable instead therefore it still increases the stack pressure by 512 bytes. It results in the following size decrease: tlbex.o~old => tlbex.o text: 9812 9780 -32 0% data: 1344 832 -512 -38% bss: 1568 1568 0 0% total: 12724 12180 -544 -4% Signed-off-by: Franck Bui-Huu --- arch/mips/mm/tlbex.c | 50 +++++++++++++++++++++++++++++--------------------- 1 files changed, 29 insertions(+), 21 deletions(-) diff --git a/arch/mips/mm/tlbex.c b/arch/mips/mm/tlbex.c index ae1bf81..cbcb320 100644 --- a/arch/mips/mm/tlbex.c +++ b/arch/mips/mm/tlbex.c @@ -735,27 +735,23 @@ il_bgez(u32 **p, struct reloc **r, unsigned int reg, enum label_id l) # define GET_CONTEXT(buf, reg) i_MFC0(buf, reg, C0_CONTEXT) #endif -/* The worst case length of the handler is around 18 instructions for - * R3000-style TLBs and up to 63 instructions for R4000-style TLBs. - * Maximum space available is 32 instructions for R3000 and 64 - * instructions for R4000. - * - * We deliberately chose a buffer size of 128, so we won't scribble - * over anything important on overflow before we panic. - */ -static u32 tlb_handler[128] __initdata; - /* * The R3000 TLB handler is simple. + * + * The worst case length of the handler is around 18 instructions for + * R3000-style TLBs and the maximum space available for it is 32 + * instructions. + * + * We deliberately chose a buffer size of 64, so we won't scribble + * over anything important on overflow before we panic. */ static void __init build_r3000_tlb_refill_handler(void) { + u32 tlb_handler[64], *p = tlb_handler; long pgdc = (long)pgd_current; - u32 *p; int i; memset(tlb_handler, 0, sizeof(tlb_handler)); - p = tlb_handler; i_mfc0(&p, K0, C0_BADVADDR); i_lui(&p, K1, rel_hi(pgdc)); /* cp0 delay */ @@ -787,17 +783,19 @@ static void __init build_r3000_tlb_refill_handler(void) pr_debug("\t.word 0x%08x\n", tlb_handler[i]); pr_debug("\t.set pop\n"); - memcpy((void *)ebase, tlb_handler, 0x80); + memcpy((void *)ebase, tlb_handler, 32); } /* - * The R4000 TLB handler is much more complicated. We have two - * consecutive handler areas with 32 instructions space each. - * Since they aren't used at the same time, we can overflow in the - * other one.To keep things simple, we first assume linear space, - * then we relocate it to the final handler layout as needed. + * The R4000 TLB handler. + * + * The worst case length of the handler is up to 63 instructions for + * R4000-style TLBs and the maximum space available for it is 64 + * instructions. + * + * We deliberately chose a buffer size of 128, so we won't scribble + * over anything important on overflow before we panic. */ -static u32 final_handler[64] __initdata; /* * Hazards @@ -1243,9 +1241,19 @@ static void __init build_update_entries(u32 **p, unsigned int tmp, #endif } +/* + * The R4000 TLB handler is much more complicated. We have two + * consecutive handler areas with 32 instructions space each. + * Since they aren't used at the same time, we can overflow in the + * other one.To keep things simple, we first assume linear space, + * then we relocate it to the final handler layout as needed. + */ +static u32 final_handler[64] __initdata; + + static void __init build_r4000_tlb_refill_handler(void) { - u32 *p = tlb_handler; + u32 tlb_handler[128], *p = tlb_handler; struct label labels[128], *l = labels; struct reloc relocs[128], *r = relocs; u32 *f; @@ -1365,7 +1373,7 @@ static void __init build_r4000_tlb_refill_handler(void) pr_debug("\t.word 0x%08x\n", f[i]); pr_debug("\t.set pop\n"); - memcpy((void *)ebase, final_handler, 0x100); + memcpy((void *)ebase, final_handler, 64); } /* -- 1.5.3.3 From fbuihuu@gmail.com Tue Oct 9 21:37:58 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 09 Oct 2007 21:38:07 +0100 (BST) Received: from nf-out-0910.google.com ([64.233.182.187]:52479 "EHLO nf-out-0910.google.com") by ftp.linux-mips.org with ESMTP id S20022227AbXJIUh6 (ORCPT ); Tue, 9 Oct 2007 21:37:58 +0100 Received: by nf-out-0910.google.com with SMTP id c10so1328075nfd for ; Tue, 09 Oct 2007 13:37:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:user-agent:mime-version:cc:subject:references:in-reply-to:x-enigmail-version:content-type:content-transfer-encoding; bh=Z/eRmMHZpeqIRWklbGNgVwZEv7NzUHEYQ3a4maj/vOU=; b=mA/smiZKCNovDlfAeZks+H8PkcXVrcYB6b+4urg2Jk8EAMEyWqa1EJPUcas5nT7eqr6a2Jk9rAyWCGCTO+7Q33G/aAmQDXnYHPXSV3zfiiALu296D0pSxJBUJ8h6tZn40jS8nxNuq2iMW/PRve1zWl9dpNs6LgMpK35DFCKDxX0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:user-agent:mime-version:cc:subject:references:in-reply-to:x-enigmail-version:content-type:content-transfer-encoding; b=txbOfI3SJocryiU55VevgjWwk11tmDlPXFoJfskeUXO5FZC9y2kFq6P/9BhsQRf0anmVNc5Hau0RJmkqBCtQ6yBiKKzvNwjioLQNc2a//VCRATxZ3C8LKepViL8phg9euTrUvgePDW2MbOGYY4TDN5kypZVjXVThDxeU3B/lzuM= Received: by 10.86.70.8 with SMTP id s8mr6292840fga.1191962276176; Tue, 09 Oct 2007 13:37:56 -0700 (PDT) Received: from ?192.168.0.1? ( [82.235.205.153]) by mx.google.com with ESMTPS id o11sm9149813fkf.2007.10.09.13.37.52 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 09 Oct 2007 13:37:53 -0700 (PDT) Message-ID: <470BE68F.5090000@gmail.com> Date: Tue, 09 Oct 2007 22:37:35 +0200 From: Franck Bui-Huu User-Agent: Thunderbird 2.0.0.5 (X11/20070719) MIME-Version: 1.0 CC: Ralf Baechle , Thiemo Seufer , "Maciej W. Rozycki" , linux-mips@linux-mips.org Subject: [PATCH 4/6] tlbex.c: remove final_handler[] from init.data section References: <20071002141125.GC16772@networkno.de> <20071002154918.GA11312@linux-mips.org> <47038874.9050704@gmail.com> <20071003131158.GL16772@networkno.de> <4703F155.4000301@gmail.com> <20071003201800.GP16772@networkno.de> <47049734.6050802@gmail.com> <20071004121557.GA28928@linux-mips.org> <4705004C.5000705@gmail.com> <20071005115151.GA16145@linux-mips.org> <470BE58A.9070709@gmail.com> In-Reply-To: <470BE58A.9070709@gmail.com> X-Enigmail-Version: 0.95.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit To: unlisted-recipients:; (no To-header on input) Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 16916 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: fbuihuu@gmail.com Precedence: bulk X-list: linux-mips This patch uses 256 stack bytes and decreases the kernel image of the same size. Signed-off-by: Franck Bui-Huu --- arch/mips/mm/tlbex.c | 5 +---- 1 files changed, 1 insertions(+), 4 deletions(-) diff --git a/arch/mips/mm/tlbex.c b/arch/mips/mm/tlbex.c index cbcb320..6991b89 100644 --- a/arch/mips/mm/tlbex.c +++ b/arch/mips/mm/tlbex.c @@ -1248,15 +1248,12 @@ static void __init build_update_entries(u32 **p, unsigned int tmp, * other one.To keep things simple, we first assume linear space, * then we relocate it to the final handler layout as needed. */ -static u32 final_handler[64] __initdata; - - static void __init build_r4000_tlb_refill_handler(void) { u32 tlb_handler[128], *p = tlb_handler; + u32 final_handler[64], *f; struct label labels[128], *l = labels; struct reloc relocs[128], *r = relocs; - u32 *f; unsigned int final_len; int i; -- 1.5.3.3 From fbuihuu@gmail.com Tue Oct 9 21:38:43 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 09 Oct 2007 21:38:50 +0100 (BST) Received: from nf-out-0910.google.com ([64.233.182.189]:50953 "EHLO nf-out-0910.google.com") by ftp.linux-mips.org with ESMTP id S20022234AbXJIUin (ORCPT ); Tue, 9 Oct 2007 21:38:43 +0100 Received: by nf-out-0910.google.com with SMTP id c10so1328077nfd for ; Tue, 09 Oct 2007 13:38:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:user-agent:mime-version:cc:subject:references:in-reply-to:x-enigmail-version:content-type:content-transfer-encoding; bh=jr/jAoD0826yLhobjZCssUIs8EEKQB0NIIsbmW9RvF4=; b=FQYGGcDbDRmpfxm7Nl52NQgsX2lDAbuU0SXccyFZREkY/Azpf1m+wFOmWpdY9/2fcb8IbAfg6Oj1BGSBacMFkXl1BSoUV9t+xW30aKKhpx3lH+A0F2qox0YjuzfOkl/7RNAM78PlBgQd3cW/s56l7ZN2j6FKKXpT62Os2dWY13U= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:user-agent:mime-version:cc:subject:references:in-reply-to:x-enigmail-version:content-type:content-transfer-encoding; b=P07p1PbnT+Mat18Rr/SrdyR+App7P8alE0idvf3q8/k8cmfDmKonJ6DAkMMCasmhVrUX9eKz2uXJAD/59909SV3XteAgyYqsgmHFPzUb/2srdX/OU/dJH0z7e8cFHdzYp5iR1H1KBNrz5Yz3gF0TvAFOh55pG3TYZqwGuzebciI= Received: by 10.86.81.8 with SMTP id e8mr6319409fgb.1191962322729; Tue, 09 Oct 2007 13:38:42 -0700 (PDT) Received: from ?192.168.0.1? ( [82.235.205.153]) by mx.google.com with ESMTPS id 31sm8952681fkt.2007.10.09.13.38.40 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 09 Oct 2007 13:38:41 -0700 (PDT) Message-ID: <470BE6BF.7090405@gmail.com> Date: Tue, 09 Oct 2007 22:38:23 +0200 From: Franck Bui-Huu User-Agent: Thunderbird 2.0.0.5 (X11/20070719) MIME-Version: 1.0 CC: Ralf Baechle , Thiemo Seufer , "Maciej W. Rozycki" , linux-mips@linux-mips.org Subject: [PATCH 5/6] tlbex.c: cleanup debug code References: <20071002141125.GC16772@networkno.de> <20071002154918.GA11312@linux-mips.org> <47038874.9050704@gmail.com> <20071003131158.GL16772@networkno.de> <4703F155.4000301@gmail.com> <20071003201800.GP16772@networkno.de> <47049734.6050802@gmail.com> <20071004121557.GA28928@linux-mips.org> <4705004C.5000705@gmail.com> <20071005115151.GA16145@linux-mips.org> <470BE58A.9070709@gmail.com> In-Reply-To: <470BE58A.9070709@gmail.com> X-Enigmail-Version: 0.95.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit To: unlisted-recipients:; (no To-header on input) Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 16917 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: fbuihuu@gmail.com Precedence: bulk X-list: linux-mips Signed-off-by: Franck Bui-Huu --- arch/mips/mm/tlbex.c | 83 +++++++++++++++---------------------------------- 1 files changed, 26 insertions(+), 57 deletions(-) diff --git a/arch/mips/mm/tlbex.c b/arch/mips/mm/tlbex.c index 6991b89..e725072 100644 --- a/arch/mips/mm/tlbex.c +++ b/arch/mips/mm/tlbex.c @@ -714,6 +714,22 @@ il_bgez(u32 **p, struct reloc **r, unsigned int reg, enum label_id l) i_bgez(p, reg, 0); } +/* + * For debug purposes. + */ +static inline void dump_handler(const u32 *handler, int count) +{ + int i; + + pr_debug("\t.set push\n"); + pr_debug("\t.set noreorder\n"); + + for (i = 0; i < count; i++) + pr_debug("\t%p\t.word 0x%08x\n", &handler[i], handler[i]); + + pr_debug("\t.set pop\n"); +} + /* The only general purpose registers allowed in TLB handlers. */ #define K0 26 #define K1 27 @@ -749,7 +765,6 @@ static void __init build_r3000_tlb_refill_handler(void) { u32 tlb_handler[64], *p = tlb_handler; long pgdc = (long)pgd_current; - int i; memset(tlb_handler, 0, sizeof(tlb_handler)); @@ -777,13 +792,9 @@ static void __init build_r3000_tlb_refill_handler(void) pr_info("Synthesized TLB refill handler (%u instructions).\n", (unsigned int)(p - tlb_handler)); - pr_debug("\t.set push\n"); - pr_debug("\t.set noreorder\n"); - for (i = 0; i < (p - tlb_handler); i++) - pr_debug("\t.word 0x%08x\n", tlb_handler[i]); - pr_debug("\t.set pop\n"); - memcpy((void *)ebase, tlb_handler, 32); + + dump_handler((u32 *)ebase, 32); } /* @@ -1255,7 +1266,6 @@ static void __init build_r4000_tlb_refill_handler(void) struct label labels[128], *l = labels; struct reloc relocs[128], *r = relocs; unsigned int final_len; - int i; memset(tlb_handler, 0, sizeof(tlb_handler)); memset(labels, 0, sizeof(labels)); @@ -1357,20 +1367,9 @@ static void __init build_r4000_tlb_refill_handler(void) pr_info("Synthesized TLB refill handler (%u instructions).\n", final_len); - f = final_handler; -#if defined(CONFIG_64BIT) && !defined(CONFIG_CPU_LOONGSON2) - if (final_len > 32) - final_len = 64; - else - f = final_handler + 32; -#endif /* CONFIG_64BIT */ - pr_debug("\t.set push\n"); - pr_debug("\t.set noreorder\n"); - for (i = 0; i < final_len; i++) - pr_debug("\t.word 0x%08x\n", f[i]); - pr_debug("\t.set pop\n"); - memcpy((void *)ebase, final_handler, 64); + + dump_handler((u32 *)ebase, 64); } /* @@ -1601,7 +1600,6 @@ static void __init build_r3000_tlb_load_handler(void) u32 *p = handle_tlbl; struct label labels[FASTPATH_SIZE], *l = labels; struct reloc relocs[FASTPATH_SIZE], *r = relocs; - int i; memset(handle_tlbl, 0, sizeof(handle_tlbl)); memset(labels, 0, sizeof(labels)); @@ -1624,11 +1622,7 @@ static void __init build_r3000_tlb_load_handler(void) pr_info("Synthesized TLB load handler fastpath (%u instructions).\n", (unsigned int)(p - handle_tlbl)); - pr_debug("\t.set push\n"); - pr_debug("\t.set noreorder\n"); - for (i = 0; i < (p - handle_tlbl); i++) - pr_debug("\t.word 0x%08x\n", handle_tlbl[i]); - pr_debug("\t.set pop\n"); + dump_handler(handle_tlbl, ARRAY_SIZE(handle_tlbl)); } static void __init build_r3000_tlb_store_handler(void) @@ -1636,7 +1630,6 @@ static void __init build_r3000_tlb_store_handler(void) u32 *p = handle_tlbs; struct label labels[FASTPATH_SIZE], *l = labels; struct reloc relocs[FASTPATH_SIZE], *r = relocs; - int i; memset(handle_tlbs, 0, sizeof(handle_tlbs)); memset(labels, 0, sizeof(labels)); @@ -1659,11 +1652,7 @@ static void __init build_r3000_tlb_store_handler(void) pr_info("Synthesized TLB store handler fastpath (%u instructions).\n", (unsigned int)(p - handle_tlbs)); - pr_debug("\t.set push\n"); - pr_debug("\t.set noreorder\n"); - for (i = 0; i < (p - handle_tlbs); i++) - pr_debug("\t.word 0x%08x\n", handle_tlbs[i]); - pr_debug("\t.set pop\n"); + dump_handler(handle_tlbs, ARRAY_SIZE(handle_tlbs)); } static void __init build_r3000_tlb_modify_handler(void) @@ -1671,7 +1660,6 @@ static void __init build_r3000_tlb_modify_handler(void) u32 *p = handle_tlbm; struct label labels[FASTPATH_SIZE], *l = labels; struct reloc relocs[FASTPATH_SIZE], *r = relocs; - int i; memset(handle_tlbm, 0, sizeof(handle_tlbm)); memset(labels, 0, sizeof(labels)); @@ -1694,11 +1682,7 @@ static void __init build_r3000_tlb_modify_handler(void) pr_info("Synthesized TLB modify handler fastpath (%u instructions).\n", (unsigned int)(p - handle_tlbm)); - pr_debug("\t.set push\n"); - pr_debug("\t.set noreorder\n"); - for (i = 0; i < (p - handle_tlbm); i++) - pr_debug("\t.word 0x%08x\n", handle_tlbm[i]); - pr_debug("\t.set pop\n"); + dump_handler(handle_tlbm, ARRAY_SIZE(handle_tlbm)); } /* @@ -1751,7 +1735,6 @@ static void __init build_r4000_tlb_load_handler(void) u32 *p = handle_tlbl; struct label labels[FASTPATH_SIZE], *l = labels; struct reloc relocs[FASTPATH_SIZE], *r = relocs; - int i; memset(handle_tlbl, 0, sizeof(handle_tlbl)); memset(labels, 0, sizeof(labels)); @@ -1784,11 +1767,7 @@ static void __init build_r4000_tlb_load_handler(void) pr_info("Synthesized TLB load handler fastpath (%u instructions).\n", (unsigned int)(p - handle_tlbl)); - pr_debug("\t.set push\n"); - pr_debug("\t.set noreorder\n"); - for (i = 0; i < (p - handle_tlbl); i++) - pr_debug("\t.word 0x%08x\n", handle_tlbl[i]); - pr_debug("\t.set pop\n"); + dump_handler(handle_tlbl, ARRAY_SIZE(handle_tlbl)); } static void __init build_r4000_tlb_store_handler(void) @@ -1796,7 +1775,6 @@ static void __init build_r4000_tlb_store_handler(void) u32 *p = handle_tlbs; struct label labels[FASTPATH_SIZE], *l = labels; struct reloc relocs[FASTPATH_SIZE], *r = relocs; - int i; memset(handle_tlbs, 0, sizeof(handle_tlbs)); memset(labels, 0, sizeof(labels)); @@ -1820,11 +1798,7 @@ static void __init build_r4000_tlb_store_handler(void) pr_info("Synthesized TLB store handler fastpath (%u instructions).\n", (unsigned int)(p - handle_tlbs)); - pr_debug("\t.set push\n"); - pr_debug("\t.set noreorder\n"); - for (i = 0; i < (p - handle_tlbs); i++) - pr_debug("\t.word 0x%08x\n", handle_tlbs[i]); - pr_debug("\t.set pop\n"); + dump_handler(handle_tlbs, ARRAY_SIZE(handle_tlbs)); } static void __init build_r4000_tlb_modify_handler(void) @@ -1832,7 +1806,6 @@ static void __init build_r4000_tlb_modify_handler(void) u32 *p = handle_tlbm; struct label labels[FASTPATH_SIZE], *l = labels; struct reloc relocs[FASTPATH_SIZE], *r = relocs; - int i; memset(handle_tlbm, 0, sizeof(handle_tlbm)); memset(labels, 0, sizeof(labels)); @@ -1857,11 +1830,7 @@ static void __init build_r4000_tlb_modify_handler(void) pr_info("Synthesized TLB modify handler fastpath (%u instructions).\n", (unsigned int)(p - handle_tlbm)); - pr_debug("\t.set push\n"); - pr_debug("\t.set noreorder\n"); - for (i = 0; i < (p - handle_tlbm); i++) - pr_debug("\t.word 0x%08x\n", handle_tlbm[i]); - pr_debug("\t.set pop\n"); + dump_handler(handle_tlbm, ARRAY_SIZE(handle_tlbm)); } void __init build_tlb_refill_handler(void) -- 1.5.3.3 From fbuihuu@gmail.com Tue Oct 9 21:39:38 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 09 Oct 2007 21:39:43 +0100 (BST) Received: from nf-out-0910.google.com ([64.233.182.189]:44049 "EHLO nf-out-0910.google.com") by ftp.linux-mips.org with ESMTP id S20022290AbXJIUji (ORCPT ); Tue, 9 Oct 2007 21:39:38 +0100 Received: by nf-out-0910.google.com with SMTP id c10so1328417nfd for ; Tue, 09 Oct 2007 13:39:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:user-agent:mime-version:cc:subject:references:in-reply-to:x-enigmail-version:content-type:content-transfer-encoding; bh=fQk79EeXC0qM1iUetlh6tm7MpJyTlvCpv4VIa92ZDH0=; b=gc7krg8k27K8OMPXR+LS42ocdqssascYR+Y0d0OFIZdkZC7vv+5JVC1DoE3AWeBT9ah3brQdJf54wicOlT2Tv3tNsgw/wVpmOGKNYRJSvsbQZKwSdk7K09Bfdfxe/NqXjCRf7bN6403M7rd+7XgCVtpGRta4tphEekmAz2X5K04= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:user-agent:mime-version:cc:subject:references:in-reply-to:x-enigmail-version:content-type:content-transfer-encoding; b=IMua0hwIo4JcjOjJeUMFEgmbIKwNfwNaw+0lTK7BHafoCbCqGgmfPI1OxJB+lAttVgt/JcMMou0R96bjgfVDGD3LBFaO4QPHcn3fU9kQl01xeMGgnc3mfyYleCqxhWDjmALfe8XgaYMol0vk/OtkVJ2vD33cTavIpK0zdHYNpKs= Received: by 10.86.100.7 with SMTP id x7mr6294559fgb.1191962360842; Tue, 09 Oct 2007 13:39:20 -0700 (PDT) Received: from ?192.168.0.1? ( [82.235.205.153]) by mx.google.com with ESMTPS id 28sm9065597fkx.2007.10.09.13.39.18 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 09 Oct 2007 13:39:19 -0700 (PDT) Message-ID: <470BE6E5.2060707@gmail.com> Date: Tue, 09 Oct 2007 22:39:01 +0200 From: Franck Bui-Huu User-Agent: Thunderbird 2.0.0.5 (X11/20070719) MIME-Version: 1.0 CC: Ralf Baechle , Thiemo Seufer , "Maciej W. Rozycki" , linux-mips@linux-mips.org Subject: [PATCH 6/6] tlbex.c: cleanup include files References: <20071002141125.GC16772@networkno.de> <20071002154918.GA11312@linux-mips.org> <47038874.9050704@gmail.com> <20071003131158.GL16772@networkno.de> <4703F155.4000301@gmail.com> <20071003201800.GP16772@networkno.de> <47049734.6050802@gmail.com> <20071004121557.GA28928@linux-mips.org> <4705004C.5000705@gmail.com> <20071005115151.GA16145@linux-mips.org> <470BE58A.9070709@gmail.com> In-Reply-To: <470BE58A.9070709@gmail.com> X-Enigmail-Version: 0.95.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit To: unlisted-recipients:; (no To-header on input) Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 16918 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: fbuihuu@gmail.com Precedence: bulk X-list: linux-mips Signed-off-by: Franck Bui-Huu --- arch/mips/mm/tlbex.c | 9 --------- 1 files changed, 0 insertions(+), 9 deletions(-) diff --git a/arch/mips/mm/tlbex.c b/arch/mips/mm/tlbex.c index e725072..05dc390 100644 --- a/arch/mips/mm/tlbex.c +++ b/arch/mips/mm/tlbex.c @@ -19,20 +19,11 @@ * (Condolences to Napoleon XIV) */ -#include - -#include #include -#include -#include -#include -#include -#include #include #include #include -#include #include static inline int r45k_bvahwbug(void) -- 1.5.3.3 From alan@lxorguk.ukuu.org.uk Tue Oct 9 22:00:28 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 09 Oct 2007 22:00:37 +0100 (BST) Received: from outpipe-village-512-1.bc.nu ([81.2.110.250]:18395 "EHLO the-village.bc.nu") by ftp.linux-mips.org with ESMTP id S20022016AbXJIVA2 (ORCPT ); Tue, 9 Oct 2007 22:00:28 +0100 Received: from the-village.bc.nu (localhost.localdomain [127.0.0.1]) by the-village.bc.nu (8.14.1/8.13.8) with ESMTP id l99L5Uew018056; Tue, 9 Oct 2007 22:05:31 +0100 Date: Tue, 9 Oct 2007 22:05:30 +0100 From: Alan Cox To: Andrew Sharp Cc: linux-mips@linux-mips.org Subject: Re: paging problem with ide-cs driver Message-ID: <20071009220530.0416792b@the-village.bc.nu> In-Reply-To: <20071009132657.64ec9158@ripper.onstor.net> References: <20071009132657.64ec9158@ripper.onstor.net> X-Mailer: Claws Mail 2.10.0 (GTK+ 2.10.14; i386-redhat-linux-gnu) Organization: Red Hat UK Cyf., Amberley Place, 107-111 Peascod Street, Windsor, Berkshire, SL4 1TE, Y Deyrnas Gyfunol. Cofrestrwyd yng Nghymru a Lloegr o'r rhif cofrestru 3798903 Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 16919 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: alan@lxorguk.ukuu.org.uk Precedence: bulk X-list: linux-mips > Before I dive into this, does any of this ring a bell for anyone? > I'm using the ide-cs driver, TI yenta cardbus adapter driver, and sibyte > everything else. That has cache coherency painted all over it in bright flashing letters. Can you build and try the libata drivers and the libata pata_pcmcia driver. The two are essentially the same at the hardware management level but go up via different stacks which should give clues depending on how/if the libata one fails in comparison. From andy.sharp@onstor.com Tue Oct 9 22:41:30 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 09 Oct 2007 22:42:01 +0100 (BST) Received: from mail.onstor.com ([66.201.51.107]:32944 "EHLO mail.onstor.com") by ftp.linux-mips.org with ESMTP id S20022088AbXJIVla (ORCPT ); Tue, 9 Oct 2007 22:41:30 +0100 Received: from onstor-exch02.onstor.net ([66.201.51.106]) by mail.onstor.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 9 Oct 2007 14:41:02 -0700 Received: from ripper.onstor.net ([10.0.0.42]) by onstor-exch02.onstor.net with Microsoft SMTPSVC(6.0.3790.1830); Tue, 9 Oct 2007 14:41:01 -0700 Date: Tue, 9 Oct 2007 14:41:01 -0700 From: Andrew Sharp To: Alan Cox Cc: linux-mips@linux-mips.org Subject: Re: paging problem with ide-cs driver Message-ID: <20071009144101.511d4370@ripper.onstor.net> In-Reply-To: <20071009220530.0416792b@the-village.bc.nu> References: <20071009132657.64ec9158@ripper.onstor.net> <20071009220530.0416792b@the-village.bc.nu> Organization: Onstor X-Mailer: Sylpheed-Claws 2.6.0 (GTK+ 2.8.20; x86_64-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 09 Oct 2007 21:41:01.0874 (UTC) FILETIME=[16447120:01C80ABD] Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 16920 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: andy.sharp@onstor.com Precedence: bulk X-list: linux-mips On Tue, 9 Oct 2007 22:05:30 +0100 Alan Cox wrote: > > Before I dive into this, does any of this ring a bell for anyone? > > I'm using the ide-cs driver, TI yenta cardbus adapter driver, and > > sibyte everything else. > > That has cache coherency painted all over it in bright flashing > letters. > > Can you build and try the libata drivers and the libata pata_pcmcia > driver. The two are essentially the same at the hardware management > level but go up via different stacks which should give clues > depending on how/if the libata one fails in comparison. > OK, went and tried that, same results. a From paulacjd@spinnakers.com Wed Oct 10 04:22:41 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 10 Oct 2007 04:22:50 +0100 (BST) Received: from [61.254.231.156] ([61.254.231.156]:43018 "HELO spinnakers.com") by ftp.linux-mips.org with SMTP id S20021613AbXJJDWl (ORCPT ); Wed, 10 Oct 2007 04:22:41 +0100 Received: from smtp2.sageinternet.com (smtp2.sageinternet.com [64.141.0.68]) by 61.254.231.156 (Postfix) with ESMTP id X2VUayDS6H1y for ; Tue, 9 Oct 2007 22:22:27 +0200 Received: from unknown (49.64.158.22) by smtp2.sageinternet.com with ESMTP (Exim 4.05) id KJBfYzDu32DM for ; Tue, 9 Oct 2007 22:22:27 +0200 Date: Tue, 9 Oct 2007 22:22:27 +0200 From: Latoya Napier Reply-To: Latoya Napier Message-ID: <933532882415.218298441470@spinnakers.com> To: Subject: Linux-mips your free password MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 16921 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: paulacjd@spinnakers.com Precedence: bulk X-list: linux-mips FreeLifetime Ad@lt Pass www shewantyou cn hospitals blathery construed leis From sknauert@wesleyan.edu Wed Oct 10 04:39:55 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 10 Oct 2007 04:40:05 +0100 (BST) Received: from post1.wesleyan.edu ([129.133.6.131]:30886 "EHLO post1.wesleyan.edu") by ftp.linux-mips.org with ESMTP id S20021700AbXJJDjz (ORCPT ); Wed, 10 Oct 2007 04:39:55 +0100 Received: from webmail.wesleyan.edu (pony1.wesleyan.edu [129.133.6.192]) by courier1.wesleyan.edu (8.13.6/8.13.6) with ESMTP id l9A3dk4E013524 for ; Tue, 9 Oct 2007 23:39:46 -0400 Received: from 129.133.92.31 (SquirrelMail authenticated user sknauert) by webmail.wesleyan.edu with HTTP; Tue, 9 Oct 2007 23:39:46 -0400 (EDT) Message-ID: <33485.129.133.92.31.1191987586.squirrel@webmail.wesleyan.edu> Date: Tue, 9 Oct 2007 23:39:46 -0400 (EDT) Subject: PCI video on SGI O2 From: sknauert@wesleyan.edu To: linux-mips@linux-mips.org User-Agent: SquirrelMail/1.4.10a MIME-Version: 1.0 Content-Type: text/plain;charset=UTF-8 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal X-Wesleyan-MailScanner-Information: Please contact the ISP for more information X-Wesleyan-MailScanner: Found to be clean X-MailScanner-From: sknauert@wesleyan.edu Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 16922 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: sknauert@wesleyan.edu Precedence: bulk X-list: linux-mips Okay, sorry to bring this up yet again, but I recently found out the PCI legacy offset for the O2 was 0x8000000 and so I tried my original patch as posted here: http://www.linux-mips.org/archives/linux-mips/2007-06/msg00164.html again with the proper offset. Atsushi had made some suggestions (you can browse the thread), but when I tried them the /sysfs files no longer appeared. Sadly, I don't know why, his comments seemed reasonable. Anyway... I got some results, X.org seemed to see the video card, its ROM, and some registers. I still can't get it initialized, but maybe someone here might be able to tell if this is a kernel or X.org/ Int10 problem. I do understand that in theory /dev/mem does provides enough access to POST the card but X.org doesn't seem to use that API, while it does use the sysfs one. Thus, if there is an easy way to get X on Linux MIPS by just adding a kernel API that exists on other platforms, it seems like something reasonable to try. Here is the relevant part of my Xorg.0.log: [(II) ATI: Candidate "Device" section "Generic Video Card". (--) Chipset ATI Radeon 7500 QW (AGP/PCI) found (II) resource ranges after xf86ClaimFixedResources() call: [0] -1 0 0x00100000 - 0x3fffffff (0x3ff00000) MX[B]E(B) [1] -1 0 0x000f0000 - 0x000fffff (0x10000) MX[B] [2] -1 0 0x000c0000 - 0x000effff (0x30000) MX[B] [3] -1 0 0x00000000 - 0x0009ffff (0xa0000) MX[B] [4] -1 0 0x0000ffff - 0x0000ffff (0x1) IX[B] [5] -1 0 0x00000000 - 0x000000ff (0x100) IX[B] [6] -1 0 0x00001400 - 0x000014ff (0x100) IX[B] [7] -1 0 0x00001000 - 0x000010ff (0x100) IX[B] [8] -1 0 0x00001800 - 0x000018ff (0x100) IX[B](B) (II) Loading sub module "radeon" (II) LoadModule: "radeon" (II) Loading /usr/lib/xorg/modules/drivers/radeon_drv.so (II) Module radeon: vendor="X.Org Foundation" compiled for 7.1.1, module version = 4.2.0 Module class: X.Org Video Driver ABI class: X.Org Video Driver, version 1.0 (EE) end of block range 0xfef < begin 0xfffffff0 (EE) end of block range 0xfef < begin 0xfffffff0 (EE) end of block range 0xffef < begin 0xfffffff0 (EE) end of block range 0x7ffffef < begin 0xfffffff0 (EE) end of block range 0xffef < begin 0xfffffff0 (EE) end of block range 0xffef < begin 0xfffffff0 (II) resource ranges after probing: [0] -1 0 0x00100000 - 0x3fffffff (0x3ff00000) MX[B]E(B) [1] -1 0 0x000f0000 - 0x000fffff (0x10000) MX[B] [2] -1 0 0x000c0000 - 0x000effff (0x30000) MX[B] [3] -1 0 0x00000000 - 0x0009ffff (0xa0000) MX[B] [4] 0 0 0x000a0000 - 0x000affff (0x10000) MS[B] [5] 0 0 0x000b0000 - 0x000b7fff (0x8000) MS[B] [6] 0 0 0x000b8000 - 0x000bffff (0x8000) MS[B] [7] -1 0 0x0000ffff - 0x0000ffff (0x1) IX[B] [8] -1 0 0x00000000 - 0x000000ff (0x100) IX[B] [9] -1 0 0x00001400 - 0x000014ff (0x100) IX[B] [10] -1 0 0x00001000 - 0x000010ff (0x100) IX[B] [11] -1 0 0x00001800 - 0x000018ff (0x100) IX[B](B) [12] 0 0 0x000003b0 - 0x000003bb (0xc) IS[B] [13] 0 0 0x000003c0 - 0x000003df (0x20) IS[B] (II) Setting vga for screen 0. (**) RADEON(0): RADEONPreInit (II) RADEON(0): MMIO registers at 0x88040000: size 64KB Fatal server error: xf86MapVidMem: Could not mmap framebuffer (0xfffffff0,0x10000) (Value too large for defined data type) Any comments or suggestions would be helpful. Thanks in advance, - Scott From ralf@linux-mips.org Wed Oct 10 10:54:28 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 10 Oct 2007 10:54:30 +0100 (BST) Received: from localhost.localdomain ([127.0.0.1]:1229 "EHLO dl5rb.ham-radio-op.net") by ftp.linux-mips.org with ESMTP id S20021828AbXJJJy2 (ORCPT ); Wed, 10 Oct 2007 10:54:28 +0100 Received: from denk.linux-mips.net (denk.linux-mips.net [127.0.0.1]) by dl5rb.ham-radio-op.net (8.14.1/8.13.8) with ESMTP id l9A8rhcS000315; Wed, 10 Oct 2007 09:53:44 +0100 Received: (from ralf@localhost) by denk.linux-mips.net (8.14.1/8.14.1/Submit) id l9A8rhca000314; Wed, 10 Oct 2007 09:53:43 +0100 Date: Wed, 10 Oct 2007 09:53:43 +0100 From: Ralf Baechle To: "Maciej W. Rozycki" Cc: Franck Bui-Huu , Thiemo Seufer , linux-mips@linux-mips.org Subject: Re: [PATCH] mm/pg-r4k.c: Dump the generated code Message-ID: <20071010085343.GA31184@linux-mips.org> References: <4703F155.4000301@gmail.com> <20071003201800.GP16772@networkno.de> <47049734.6050802@gmail.com> <20071004121557.GA28928@linux-mips.org> <4705004C.5000705@gmail.com> <4705EFE5.7090704@gmail.com> <470A4349.9090301@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.14 (2007-02-12) Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 16923 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: ralf@linux-mips.org Precedence: bulk X-list: linux-mips On Mon, Oct 08, 2007 at 04:39:38PM +0100, Maciej W. Rozycki wrote: > > Well, having all cpu variations in Kconfig should be technically > > possible. The user needs to know what exact cpu is running on which > > doesn't sound impossible and we could add some sanity checkings to > > ensure he doesn't messed up its configuration. > > As long as the user is indeed capable of knowing what the exact CPU type > is. I have been told replacing R4X00 with a choice like R4000, R4400, > R4600, R4700 may already be too much of a hassle. Four choices is too much; after all these four marketing names are really just 4 variants of two fairly similar processors. Doable? Yes. A useful improvment? I doubt, otoh users of those old machines count every cycle by hand still ;-) Another problem with the enormous and continuously growing number of processors is that few users know about all the compatibility issues between the choices offered in Kconfig. Alot of bug reports were caused for example because users took MIPS32 to mean 32-bit MIPS - but R3000 processors clearly disagree with that view ;-) One of the things I'm trying to achieve is to get rid of all the use of CONFIG_CPU_MIPS32_R1 and similar processor symbols in code coming to a point where selection of one of those symbols in Kconfig only means to optimize a kernel for the selected core without sacrificing compatibility. (But of course the few machines that support processors with multiple ISAs spoil that plan a little ..) > Frankly I am not entirely confident much choice beyond the ISA level is > actually a good idea. We do have it, because lots of bits depend on > preprocessor conditionals even though they not necessarily should. There > are probably some historical reasons too. But essentially we have about > eight ISA variations (I - IV and four MIPS Architecture ISAs) and about > four privileged resource architecture variations (R2000, R6000, R4000, > R8000); not all combinations making sense and some of the choices actually > not supported at all. > > CPU variations matter performance-wise, but the use of "-mtune=" is > irrelevant in this context. > > > BTW, we could pass more cpu compiler options for optimization this > > way. For example, when using a '4ksd' cpu, we currently can't pass > > '-march=4ksd' to gcc since the cpu type used for it is 'mips32r2'. And > > I guess it's true for all cpu types which cover a range of slightly > > different processors (r4x00 comes in mind). > > What would be the gain for the kernel from using "-march=4ksd" rather > than "-march=mips32r2"? One looks fancier ;-) > > OTOH, I don't know if it can work on SMP: if the system needs 2 > > different implementations of the handler (I don't know if it can > > happen though), we must be able to select 2 different cpu types in > > Kconfig... > > I do not think we happen to handle this scenario -- the more interesting > configurations that could benefit do not support the cp0.ebase register > making per-CPU handlers quite a challenge (i.e. the cost would exceed the > benefit). It's doable but there is little point. Ebase is an R2 feature and who on earth would mix pre-R2 and R2 cores in a SOC now that R2 is established for a few years? > > Do you see any other points that we should consider before trying to > > use static handlers ? Some other cpu features influencing the tlb > > handler generations and that can be found only at runtime ? > > What if you want to run a single kernel image regardless of the CPU > installed in the system. Rebuilding the kernel (or having to keep a large > collection of binaries) just because you want to swap the CPU does not > seem like a terribly attractive idea. Some systems come with their CPU(s) > on a daughtercard (each), you know... Or an FPGAs. I can swap CPUs on my Malta from the other side of earth in few seconds by downloading another bitfile. And it's damn useful to be able to use the same kernel binary, keeps another 10min from going down the drain for just a rebuild. Ralf From share.kt@gmail.com Wed Oct 10 11:01:58 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 10 Oct 2007 11:02:07 +0100 (BST) Received: from py-out-1112.google.com ([64.233.166.183]:14131 "EHLO py-out-1112.google.com") by ftp.linux-mips.org with ESMTP id S20022052AbXJJKB6 (ORCPT ); Wed, 10 Oct 2007 11:01:58 +0100 Received: by py-out-1112.google.com with SMTP id p76so282951pyb for ; Wed, 10 Oct 2007 03:01:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:mime-version:content-type; bh=SJWwjpylsBmkv/FrwH874el0pwsFER/AGTiVBQQE3GU=; b=WVerdxmSlfGUvMPPbZVyYmGSXwoBdOsq5s9BZ3eMHBxo8CnSKhw57Gm+X/S1LyE/KyJ/gDd9f03CQyFViHD5UTVbd57ZltJgjKbjzx4scmsKQnF+DmgcB9LOxt4jptNTSImbQxK//5A42AcZ+IGRabWWu+50fC/9ZAq8d9MYmlk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:mime-version:content-type; b=txieATFF3KwZVRPuuyRP/8bIcq6LIjPodIFV5XFBQS3dk+TJWeoJZIIFUAty4m0xCRGBTqVg3ajqkVpuRLS6WA74FVxWyG5Ihk8GGtGyCjRnqiDJvqXDYUlkNOiM+09bL0XV/rmpqmXXE7YpgPa+dCFtxOeYwJurARYf5VKoG1w= Received: by 10.35.109.2 with SMTP id l2mr626763pym.1192010494573; Wed, 10 Oct 2007 03:01:34 -0700 (PDT) Received: by 10.35.39.19 with HTTP; Wed, 10 Oct 2007 03:01:34 -0700 (PDT) Message-ID: Date: Wed, 10 Oct 2007 15:31:34 +0530 From: kaka To: linux-mips@linux-mips.org Subject: cross compiling kernel image for MIPS platform in Linux Intel box MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_53617_628129.1192010494573" Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 16924 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: share.kt@gmail.com Precedence: bulk X-list: linux-mips ------=_Part_53617_628129.1192010494573 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Hi All, I have cross compiled kernel image for MIPS platform in Linux Intel box. But when i am booting the image in the MIPS board. There are 2 problems. 1. Could not load vmlinuz:I/O error 2. The size of the image is huge. Can somebody help in this regard? If somebody have proper config file or steps for building the kernel image for MIPS, then please mail me. Thanks in advance. -- Thanks & Regards, kaka ------=_Part_53617_628129.1192010494573 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline
Hi All,
 
I have cross compiled kernel image for MIPS platform in Linux Intel box.
But when i am booting the image in the MIPS board.
There are 2 problems.
1.  Could not load vmlinuz:I/O error
2. The size of the image is huge.
 
Can somebody help in this regard?
If somebody have proper config file or steps for building the kernel image for MIPS, then please mail me.
Thanks in advance.

--
Thanks & Regards,
kaka
------=_Part_53617_628129.1192010494573-- From freddy@dusktilldawn.nl Wed Oct 10 11:23:49 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 10 Oct 2007 11:23:57 +0100 (BST) Received: from tool.snarl.nl ([82.95.241.19]:31755 "EHLO tool.snarl.nl") by ftp.linux-mips.org with ESMTP id S20021989AbXJJKXt (ORCPT ); Wed, 10 Oct 2007 11:23:49 +0100 Received: from localhost (tool.local.snarl.nl [127.0.0.1]) by tool.snarl.nl (Postfix) with ESMTP id E39495E1E6; Wed, 10 Oct 2007 12:23:42 +0200 (CEST) Received: from tool.snarl.nl ([127.0.0.1]) by localhost (tool.local.snarl.nl [127.0.0.1]) (amavisd-new, port 10024) with LMTP id SuFaY+teJ+u8; Wed, 10 Oct 2007 12:23:42 +0200 (CEST) Received: by tool.snarl.nl (Postfix, from userid 1000) id 293365DFD5; Wed, 10 Oct 2007 12:23:42 +0200 (CEST) Date: Wed, 10 Oct 2007 12:23:42 +0200 From: Freddy Spierenburg To: kaka Cc: linux-mips@linux-mips.org Subject: Re: cross compiling kernel image for MIPS platform in Linux Intel box Message-ID: <20071010102341.GN22574@dusktilldawn.nl> References: MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="+2GlJm56SCtLHYlr" Content-Disposition: inline In-Reply-To: X-User-Agent-Feature: All mail clients suck. This one just sucks less. X-GPG-Key: http://snarl.nl/~freddy/keys/freddyPublicKey.gpg User-Agent: Mutt/1.5.16 (2007-06-11) Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 16925 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: freddy@dusktilldawn.nl Precedence: bulk X-list: linux-mips --+2GlJm56SCtLHYlr Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi Kaka, On Wed, Oct 10, 2007 at 03:31:34PM +0530, kaka wrote: > 1. Could not load vmlinuz:I/O error This can be a problem of all kind. Please be more specific. How do you load the image? What is your environment? For instance, an objcopy step is needed for loading with yamon. Because yamon needs an srec file to load. > 2. The size of the image is huge. Try to use modules. --=20 $ cat ~/.signature Freddy Spierenburg http://freddy.snarl.nl/ GnuPG: 0x7941D1E1=3DC948 5851 26D2 FA5C 39F1 E588 6F17 FD5D 7941 D1E1 $ # Please read http://www.ietf.org/rfc/rfc2015.txt before complain! --+2GlJm56SCtLHYlr Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFHDKgtbxf9XXlB0eERAmLmAKCZ9tkIHPyejsUb4Jk3YzUFRT9VbgCg5hhA f06IUdlU2V87B7EwDVCrz4U= =Hh7b -----END PGP SIGNATURE----- --+2GlJm56SCtLHYlr-- From Geert.Uytterhoeven@sonycom.com Wed Oct 10 12:19:02 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 10 Oct 2007 12:19:11 +0100 (BST) Received: from vervifontaine.sonytel.be ([80.88.33.193]:60607 "EHLO vervifontaine.sonycom.com") by ftp.linux-mips.org with ESMTP id S20022066AbXJJLTC (ORCPT ); Wed, 10 Oct 2007 12:19:02 +0100 Received: from pademelon.sonytel.be (piraat.sonytel.be [43.221.60.197]) by vervifontaine.sonycom.com (Postfix) with ESMTP id 9E92B58ABD; Wed, 10 Oct 2007 13:18:22 +0200 (MEST) Date: Wed, 10 Oct 2007 13:18:22 +0200 (CEST) From: Geert Uytterhoeven To: kaka cc: CE Linux Developers List , Linux/MIPS Development , debian-mips@lists.debian.org Subject: Re: [Celinux-dev] cross compiling kernel image for MIPS platform in Linux Intel box In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="-584337861-854486875-1192015102=:29913" Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 16926 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: Geert.Uytterhoeven@sonycom.com Precedence: bulk X-list: linux-mips This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. ---584337861-854486875-1192015102=:29913 Content-Type: TEXT/PLAIN; charset=UTF-8 Content-Transfer-Encoding: 8BIT On Wed, 10 Oct 2007, kaka wrote: > Hi All, Please do not post all your questions to multiple individual mailing lists. Just choose the one (or two, using CC) that's most appropriate. Thanks! With kind regards, Geert Uytterhoeven Software Architect Sony Network and Software Technology Center Europe The Corporate Village · Da Vincilaan 7-D1 · B-1935 Zaventem · Belgium Phone: +32 (0)2 700 8453 Fax: +32 (0)2 700 8622 E-mail: Geert.Uytterhoeven@sonycom.com Internet: http://www.sony-europe.com/ Sony Network and Software Technology Center Europe A division of Sony Service Centre (Europe) N.V. Registered office: Technologielaan 7 · B-1840 Londerzeel · Belgium VAT BE 0413.825.160 · RPR Brussels Fortis Bank Zaventem · Swift GEBABEBB08A · IBAN BE39001382358619 ---584337861-854486875-1192015102=:29913-- From ralf@linux-mips.org Wed Oct 10 12:25:52 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 10 Oct 2007 12:25:54 +0100 (BST) Received: from localhost.localdomain ([127.0.0.1]:38048 "EHLO dl5rb.ham-radio-op.net") by ftp.linux-mips.org with ESMTP id S20021942AbXJJLZw (ORCPT ); Wed, 10 Oct 2007 12:25:52 +0100 Received: from denk.linux-mips.net (denk.linux-mips.net [127.0.0.1]) by dl5rb.ham-radio-op.net (8.14.1/8.13.8) with ESMTP id l9ABPpH7005971; Wed, 10 Oct 2007 12:25:51 +0100 Received: (from ralf@localhost) by denk.linux-mips.net (8.14.1/8.14.1/Submit) id l9ABPpjV005970; Wed, 10 Oct 2007 12:25:51 +0100 Date: Wed, 10 Oct 2007 12:25:51 +0100 From: Ralf Baechle To: Alan Cox Cc: Andrew Sharp , linux-mips@linux-mips.org Subject: Re: paging problem with ide-cs driver Message-ID: <20071010112550.GA1780@linux-mips.org> References: <20071009132657.64ec9158@ripper.onstor.net> <20071009220530.0416792b@the-village.bc.nu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20071009220530.0416792b@the-village.bc.nu> User-Agent: Mutt/1.5.14 (2007-02-12) Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 16927 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: ralf@linux-mips.org Precedence: bulk X-list: linux-mips On Tue, Oct 09, 2007 at 10:05:30PM +0100, Alan Cox wrote: > > Before I dive into this, does any of this ring a bell for anyone? > > I'm using the ide-cs driver, TI yenta cardbus adapter driver, and sibyte > > everything else. > > That has cache coherency painted all over it in bright flashing letters. The Sibyte SOCs have hardware cache coherency and physically indeded D-caches which makes I/O pretty much a nobrainer. I-cache coherency is the thing that really needs babysitting on Sibyte and the Sibyte I-caches are of a somewhat rare kind by being VIVT plus an additional address space tag. Mostly because of code duplication the Sibyte cachecode has its nice damp and dark corner where it did bitrot away for a while. Thiemo and I recently found the standard R4000 cache code to work more reliable for Sibyte so we're getting rid of it for 2.6.24. The patch is in 06e523e89ec0322c4abcf41533d5380dfcd81f73. It can easily be backported to older kernels so I suggest trying this one. (As collateral damage 06e523e89ec0322c4abcf41533d5380dfcd81f73 breaks support for pass 1 BCM1250 parts. But it seems I'm the last one with one of those ...) Ralf From macro@linux-mips.org Wed Oct 10 12:59:35 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 10 Oct 2007 12:59:43 +0100 (BST) Received: from cerber.ds.pg.gda.pl ([153.19.208.18]:63375 "EHLO cerber.ds.pg.gda.pl") by ftp.linux-mips.org with ESMTP id S20022032AbXJJL7f (ORCPT ); Wed, 10 Oct 2007 12:59:35 +0100 Received: from localhost (unknown [127.0.0.17]) by cerber.ds.pg.gda.pl (Postfix) with ESMTP id C61304016A; Wed, 10 Oct 2007 13:59:04 +0200 (CEST) X-Virus-Scanned: amavisd-new at cerber.ds.pg.gda.pl Received: from cerber.ds.pg.gda.pl ([153.19.208.18]) by localhost (cerber.ds.pg.gda.pl [153.19.208.18]) (amavisd-new, port 10024) with ESMTP id 59WYxs-H6VI0; Wed, 10 Oct 2007 13:58:57 +0200 (CEST) Received: from piorun.ds.pg.gda.pl (piorun.ds.pg.gda.pl [153.19.208.8]) by cerber.ds.pg.gda.pl (Postfix) with ESMTP id 554AF400BA; Wed, 10 Oct 2007 13:58:57 +0200 (CEST) Received: from blysk.ds.pg.gda.pl (macro@blysk.ds.pg.gda.pl [153.19.208.6]) by piorun.ds.pg.gda.pl (8.13.8/8.13.8) with ESMTP id l9ABwxod009526; Wed, 10 Oct 2007 13:58:59 +0200 Date: Wed, 10 Oct 2007 12:58:56 +0100 (BST) From: "Maciej W. Rozycki" To: Franck Bui-Huu cc: Ralf Baechle , Thiemo Seufer , linux-mips@linux-mips.org Subject: Re: [PATCH] mm/pg-r4k.c: Dump the generated code In-Reply-To: <470BE1F4.3070800@gmail.com> Message-ID: References: <20071002141125.GC16772@networkno.de> <20071002154918.GA11312@linux-mips.org> <47038874.9050704@gmail.com> <20071003131158.GL16772@networkno.de> <4703F155.4000301@gmail.com> <20071003201800.GP16772@networkno.de> <47049734.6050802@gmail.com> <20071004121557.GA28928@linux-mips.org> <4705004C.5000705@gmail.com> <4705EFE5.7090704@gmail.com> <470A4349.9090301@gmail.com> <470BE1F4.3070800@gmail.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: ClamAV 0.91.2/4521/Wed Oct 10 09:58:01 2007 on piorun.ds.pg.gda.pl X-Virus-Status: Clean Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 16928 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: macro@linux-mips.org Precedence: bulk X-list: linux-mips On Tue, 9 Oct 2007, Franck Bui-Huu wrote: > > What would be the gain for the kernel from using "-march=4ksd" rather > > than "-march=mips32r2"? > > > > It actually results in a kernel image ~30kbytes smaller for the former > case. It has been discussed sometimes ago on this list. I'm sorry but > I don't know why... Perhaps the pipeline description for the 4KSd CPU is different from the default for the MIPS32r2 ISA. Barring a study of GCC sources, if that really troubles you, you could build the same version of the kernel with these options: 1. "-march=mips32r2" 2. "-march=4ksd" 3. "-march=mips32r2 -mtune=4ksd" and compare the results. I expect the results of #2 and #3 to be the same and it would just back up my suggestion about keeping CPU-specific optimisations separate from the CPU selection. Please also note that our optimisation model is for speed (-O2) rather than size (-Os), so if "-mtune=4ksd" yields smaller code than "-mtune=mips32r2", it just means it is safe for this CPU to shrink code where appropriate without losing performance. One obvious place for such a choice is the use of the hardware multiplier vs shifts and additions where one multiplicand is a constant. > > What if you want to run a single kernel image regardless of the CPU > > installed in the system. Rebuilding the kernel (or having to keep a large > > collection of binaries) just because you want to swap the CPU does not > > seem like a terribly attractive idea. Some systems come with their CPU(s) > > on a daughtercard (each), you know... > > > > ok, I wasn't aware about this. You could have started by this point ;) Well, daughtercards for CPUs are so common for me -- the vast majority of MIPS-based systems I use have them -- that I have assumed, obviously incorrectly, that you see a benefit from such a rewrite of the TLB exception handlers which is large enough to justify the inconvenience of limiting the kernel to a given CPU card. > So now I think the right direction is to stick with tlbex.c and > make it smaller like Ralf did. That is certainly a good idea. Maciej From nigel@mips.com Wed Oct 10 13:08:54 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 10 Oct 2007 13:09:02 +0100 (BST) Received: from dmz.mips-uk.com ([194.74.144.194]:40978 "EHLO dmz.mips-uk.com") by ftp.linux-mips.org with ESMTP id S20021968AbXJJMIy (ORCPT ); Wed, 10 Oct 2007 13:08:54 +0100 Received: from internal-mx1 ([192.168.192.240] helo=ukservices1.mips.com) by dmz.mips-uk.com with esmtp (Exim 3.35 #1 (Debian)) id 1IfaMv-0008EJ-00; Wed, 10 Oct 2007 13:08:53 +0100 Received: from southgate.mips.com ([192.168.192.171]) by ukservices1.mips.com with esmtp (Exim 3.36 #1 (Debian)) id 1IfaMo-0001f1-00; Wed, 10 Oct 2007 13:08:46 +0100 Message-ID: <470CC0CE.9080303@mips.com> Date: Wed, 10 Oct 2007 13:08:46 +0100 From: Nigel Stephens Organization: MIPS Technologies User-Agent: IceDove 1.5.0.12 (X11/20070606) MIME-Version: 1.0 To: "Maciej W. Rozycki" CC: Franck Bui-Huu , Ralf Baechle , Thiemo Seufer , linux-mips@linux-mips.org Subject: Re: [SPAM?] Re: [PATCH] mm/pg-r4k.c: Dump the generated code References: <20071002141125.GC16772@networkno.de> <20071002154918.GA11312@linux-mips.org> <47038874.9050704@gmail.com> <20071003131158.GL16772@networkno.de> <4703F155.4000301@gmail.com> <20071003201800.GP16772@networkno.de> <47049734.6050802@gmail.com> <20071004121557.GA28928@linux-mips.org> <4705004C.5000705@gmail.com> <4705EFE5.7090704@gmail.com> <470A4349.9090301@gmail.com> <470BE1F4.3070800@gmail.com> In-Reply-To: X-Enigmail-Version: 0.94.2.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit X-MIPS-Technologies-UK-MailScanner: Found to be clean X-MIPS-Technologies-UK-MailScanner-From: nigel@mips.com Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 16929 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: nigel@mips.com Precedence: bulk X-list: linux-mips Maciej W. Rozycki wrote: > On Tue, 9 Oct 2007, Franck Bui-Huu wrote: > > >>> What would be the gain for the kernel from using "-march=4ksd" rather >>> than "-march=mips32r2"? >>> >>> >> It actually results in a kernel image ~30kbytes smaller for the former >> case. It has been discussed sometimes ago on this list. I'm sorry but >> I don't know why... >> > > Perhaps the pipeline description for the 4KSd CPU is different from the > default for the MIPS32r2 ISA. Barring a study of GCC sources, if that > really troubles you, you could build the same version of the kernel with > these options: > > 1. "-march=mips32r2" > > 2. "-march=4ksd" > > 3. "-march=mips32r2 -mtune=4ksd" > > and compare the results. > I expect the results of #2 and #3 to be the same > and it would just back up my suggestion about keeping CPU-specific > optimisations separate from the CPU selection. Actually the -march=4ksd option will allow gcc to use of the SmartMIPS lwxs (indexed load) instruction, which could save a few instructions here and there. > Please also note that our > optimisation model is for speed (-O2) rather than size (-Os), so if > "-mtune=4ksd" yields smaller code than "-mtune=mips32r2", it just means it > is safe for this CPU to shrink code where appropriate without losing > performance. One obvious place for such a choice is the use of the > hardware multiplier vs shifts and additions where one multiplicand is a > constant. > > Yes, that's also worth testing. Nigel From macro@linux-mips.org Wed Oct 10 13:18:13 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 10 Oct 2007 13:18:21 +0100 (BST) Received: from cerber.ds.pg.gda.pl ([153.19.208.18]:33167 "EHLO cerber.ds.pg.gda.pl") by ftp.linux-mips.org with ESMTP id S20022111AbXJJMSN (ORCPT ); Wed, 10 Oct 2007 13:18:13 +0100 Received: from localhost (unknown [127.0.0.17]) by cerber.ds.pg.gda.pl (Postfix) with ESMTP id 1B3F240175; Wed, 10 Oct 2007 14:17:40 +0200 (CEST) X-Virus-Scanned: amavisd-new at cerber.ds.pg.gda.pl Received: from cerber.ds.pg.gda.pl ([153.19.208.18]) by localhost (cerber.ds.pg.gda.pl [153.19.208.18]) (amavisd-new, port 10024) with ESMTP id GuJ0ApsPWLrd; Wed, 10 Oct 2007 14:17:33 +0200 (CEST) Received: from piorun.ds.pg.gda.pl (piorun.ds.pg.gda.pl [153.19.208.8]) by cerber.ds.pg.gda.pl (Postfix) with ESMTP id 46EF5400BA; Wed, 10 Oct 2007 14:17:33 +0200 (CEST) Received: from blysk.ds.pg.gda.pl (macro@blysk.ds.pg.gda.pl [153.19.208.6]) by piorun.ds.pg.gda.pl (8.13.8/8.13.8) with ESMTP id l9ACHZtS012927; Wed, 10 Oct 2007 14:17:35 +0200 Date: Wed, 10 Oct 2007 13:17:31 +0100 (BST) From: "Maciej W. Rozycki" To: Ralf Baechle cc: Franck Bui-Huu , Thiemo Seufer , linux-mips@linux-mips.org Subject: Re: [PATCH] mm/pg-r4k.c: Dump the generated code In-Reply-To: <20071010085343.GA31184@linux-mips.org> Message-ID: References: <4703F155.4000301@gmail.com> <20071003201800.GP16772@networkno.de> <47049734.6050802@gmail.com> <20071004121557.GA28928@linux-mips.org> <4705004C.5000705@gmail.com> <4705EFE5.7090704@gmail.com> <470A4349.9090301@gmail.com> <20071010085343.GA31184@linux-mips.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: ClamAV 0.91.2/4521/Wed Oct 10 09:58:01 2007 on piorun.ds.pg.gda.pl X-Virus-Status: Clean Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 16930 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: macro@linux-mips.org Precedence: bulk X-list: linux-mips On Wed, 10 Oct 2007, Ralf Baechle wrote: > > As long as the user is indeed capable of knowing what the exact CPU type > > is. I have been told replacing R4X00 with a choice like R4000, R4400, > > R4600, R4700 may already be too much of a hassle. > > Four choices is too much; after all these four marketing names are really > just 4 variants of two fairly similar processors. Doable? Yes. A useful > improvment? I doubt, otoh users of those old machines count every cycle > by hand still ;-) Except from the note on cycle counting ;-) I do agree these days and about the only place that cares about the subtleties of the R4k models are the TLB handlers which we have now solved with the current approach. > One of the things I'm trying to achieve is to get rid of all the use of > CONFIG_CPU_MIPS32_R1 and similar processor symbols in code coming to a > point where selection of one of those symbols in Kconfig only means to > optimize a kernel for the selected core without sacrificing compatibility. Well, these options should really be used to select the "-march=" option only. We have some places, such as , where the dependency is tough to eliminate, but that is definitely the right direction. > (But of course the few machines that support processors with multiple ISAs > spoil that plan a little ..) Well, they have cp0.prid and cp0.config* registers at their disposal. > > I do not think we happen to handle this scenario -- the more interesting > > configurations that could benefit do not support the cp0.ebase register > > making per-CPU handlers quite a challenge (i.e. the cost would exceed the > > benefit). > > It's doable but there is little point. Ebase is an R2 feature and who > on earth would mix pre-R2 and R2 cores in a SOC now that R2 is established > for a few years? I have actually thought of one of your pet SGI machine setups -- where the CPUs are mixed and are either MIPS III or MIPS IV each. I do not recall you mentioning the exception vector range of RAM being local to the CPU cards, so I am assuming the handlers are always shared. Maciej From ricmm@kanux.com Wed Oct 10 13:31:58 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 10 Oct 2007 13:32:07 +0100 (BST) Received: from rs25s3.datacenter.cha.cantv.net ([200.44.33.4]:44982 "EHLO rs25s3.datacenter.cha.cantv.net") by ftp.linux-mips.org with ESMTP id S20021823AbXJJMb6 (ORCPT ); Wed, 10 Oct 2007 13:31:58 +0100 Received: from [192.168.0.2] (dC9D0EE2C.dslam-04-10-6-02-1-01.apr.dsl.cantv.net [201.208.238.44]) by rs25s3.datacenter.cha.cantv.net (8.13.8/8.13.0/3.0) with ESMTP id l9ACUp9i025370 for ; Wed, 10 Oct 2007 08:30:52 -0400 X-Matched-Lists: [] Message-ID: <470C8F8E.3010301@kanux.com> Date: Wed, 10 Oct 2007 04:38:38 -0400 From: Ricardo Mendoza User-Agent: Thunderbird 2.0.0.0 (X11/20070601) MIME-Version: 1.0 To: linux-mips@linux-mips.org Subject: O2 KGDB problem Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.91.2/4480/Fri Oct 5 10:51:39 2007 clamav-milter version 0.91.2 on 10.128.1.88 X-Virus-Status: Clean Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 16931 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: ricmm@kanux.com Precedence: bulk X-list: linux-mips Been messing around with the O2 and KGDB and well, theres a problem that I don't quite know how to tackle, when building a 64-bit kernel with mips64 target toolchain and with CONFIG_BUILD_ELF64 and then trying to start remote gdb with that image I get a Segfault from gdb. What do you think is the cause of this? I guess its just file format mixup confusing gdb? any pointer from a gdb guru towards making this work? Ricardo From share.kt@gmail.com Wed Oct 10 13:45:51 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 10 Oct 2007 13:45:59 +0100 (BST) Received: from py-out-1112.google.com ([64.233.166.182]:35238 "EHLO py-out-1112.google.com") by ftp.linux-mips.org with ESMTP id S20022181AbXJJMpv (ORCPT ); Wed, 10 Oct 2007 13:45:51 +0100 Received: by py-out-1112.google.com with SMTP id p76so349758pyb for ; Wed, 10 Oct 2007 05:45:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:mime-version:content-type; bh=CQyB/BzZ7Y6tIhEq0r9aEiqZ14Dpywy7BB4Z9IBzPjg=; b=K8Thad1Dm5rhUdAH1cUqhGWOuSfe1RGGYcrQg0nInDnYENhmfN45wfG9bNVKqsiUbJ1arE+fhA6S1GAksxLDBIjRqt2G7+EA4uMCfk1+YgI/3OBfyWl5SfssdYYvPl8W6BIaD8dSWu7zIQLMem6xxrPQk4dfXxbIuaS7lKMFXX4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:mime-version:content-type; b=XmmkZNgovwFpkYlbMl0VivecW5Ov0NoY4WulYGwOZ34izxj+W9QB7wFGMZ2GL3ZO0p6b8fc6egmHmyTpWm7VnFSUap8QJah8IXEM9X5MdwTvZKeNXUSysDyokKDTUIDgXystieK5zvZxVFLfpbXHRyod4ciDyBoC7KBfbzpGX2k= Received: by 10.35.96.11 with SMTP id y11mr798761pyl.1192020330039; Wed, 10 Oct 2007 05:45:30 -0700 (PDT) Received: by 10.35.39.19 with HTTP; Wed, 10 Oct 2007 05:45:29 -0700 (PDT) Message-ID: Date: Wed, 10 Oct 2007 18:15:29 +0530 From: kaka To: linux-mips@linux-mips.org Subject: Unknown symbol errors in insmod MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_54036_31414549.1192020330030" Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 16932 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: share.kt@gmail.com Precedence: bulk X-list: linux-mips ------=_Part_54036_31414549.1192020330030 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Hi All, WHile installing framebuffer driver for BCM chip in MIPS platform(cross compiled in intel 86). I am getting the following error. Can somebody help in this regard? Thanks in Advance. # insmod brcmstfb.ko brcmstfb: Unknown symbol unregister_framebuffer brcmstfb: Unknown symbol printf brcmstfb: Unknown symbol __make_dp brcmstfb: Unknown symbol malloc brcmstfb: Unknown symbol framebuffer_alloc brcmstfb: Unknown symbol fb_find_mode brcmstfb: Unknown symbol fb_dealloc_cmap brcmstfb: Unknown symbol brcm_dir_entry brcmstfb: Unknown symbol register_framebuffer brcmstfb: Unknown symbol fb_alloc_cmap brcmstfb: Unknown symbol framebuffer_release brcmstfb: Unknown symbol free -- Thanks & Regards, kaka ------=_Part_54036_31414549.1192020330030 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline
Hi All,
 
WHile installing framebuffer driver for BCM chip in MIPS platform(cross compiled in intel 86).
I am getting the following error.
Can somebody help in this regard?
Thanks in Advance.
 
# insmod brcmstfb.ko
brcmstfb: Unknown symbol unregister_framebuffer
brcmstfb: Unknown symbol printf
brcmstfb: Unknown symbol __make_dp
brcmstfb: Unknown symbol malloc
brcmstfb: Unknown symbol framebuffer_alloc
brcmstfb: Unknown symbol fb_find_mode
brcmstfb: Unknown symbol fb_dealloc_cmap
brcmstfb: Unknown symbol brcm_dir_entry
brcmstfb: Unknown symbol register_framebuffer
brcmstfb: Unknown symbol fb_alloc_cmap
brcmstfb: Unknown symbol framebuffer_release
brcmstfb: Unknown symbol free

--
Thanks & Regards,
kaka
------=_Part_54036_31414549.1192020330030-- From drow@false.org Wed Oct 10 13:56:27 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 10 Oct 2007 13:56:36 +0100 (BST) Received: from NaN.false.org ([208.75.86.248]:31164 "EHLO nan.false.org") by ftp.linux-mips.org with ESMTP id S20021877AbXJJM41 (ORCPT ); Wed, 10 Oct 2007 13:56:27 +0100 Received: from nan.false.org (localhost [127.0.0.1]) by nan.false.org (Postfix) with ESMTP id C9A079833B; Wed, 10 Oct 2007 12:55:54 +0000 (GMT) Received: from caradoc.them.org (22.svnf5.xdsl.nauticom.net [209.195.183.55]) by nan.false.org (Postfix) with ESMTP id B1E3298339; Wed, 10 Oct 2007 12:55:54 +0000 (GMT) Received: from drow by caradoc.them.org with local (Exim 4.68) (envelope-from ) id 1Ifb6P-00052U-Ma; Wed, 10 Oct 2007 08:55:53 -0400 Date: Wed, 10 Oct 2007 08:55:53 -0400 From: Daniel Jacobowitz To: Ricardo Mendoza Cc: linux-mips@linux-mips.org Subject: Re: O2 KGDB problem Message-ID: <20071010125553.GA18207@caradoc.them.org> References: <470C8F8E.3010301@kanux.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <470C8F8E.3010301@kanux.com> User-Agent: Mutt/1.5.15 (2007-04-09) Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 16933 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: dan@debian.org Precedence: bulk X-list: linux-mips On Wed, Oct 10, 2007 at 04:38:38AM -0400, Ricardo Mendoza wrote: > Been messing around with the O2 and KGDB and well, theres a problem that > I don't quite know how to tackle, when building a 64-bit kernel with > mips64 target toolchain and with CONFIG_BUILD_ELF64 and then trying to > start remote gdb with that image I get a Segfault from gdb. What do you > think is the cause of this? > > I guess its just file format mixup confusing gdb? any pointer from a gdb > guru > towards making this work? I believe a CVS snapshot of GDB will "work" but refuse to show you line numbers, and if you use a CVS snapshot of gas too then things will work OK. gas was doing something horribly wrong to the .debug_line sections it generated. -- Daniel Jacobowitz CodeSourcery From florian.fainelli@telecomint.eu Wed Oct 10 14:05:47 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 10 Oct 2007 14:05:56 +0100 (BST) Received: from mx1.minet.net ([157.159.40.25]:9698 "EHLO mx1.minet.net") by ftp.linux-mips.org with ESMTP id S20022194AbXJJNFr (ORCPT ); Wed, 10 Oct 2007 14:05:47 +0100 Received: from localhost (unknown [192.168.1.97]) by mx1.minet.net (Postfix) with ESMTP id 84BCF5CD1C for ; Wed, 10 Oct 2007 15:04:59 +0200 (CEST) X-Virus-Scanned: by amavisd-new using ClamAV at minet.net Received: from smtp.minet.net (imap.minet.net [192.168.1.27]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.minet.net (Postfix) with ESMTP id 5BD375CD25 for ; Wed, 10 Oct 2007 14:55:42 +0200 (CEST) Received: from [157.159.47.53] (unknown [157.159.47.53]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: florian) by smtp.minet.net (Postfix) with ESMTP id AF17BD338 for ; Wed, 10 Oct 2007 04:11:13 +0200 (CEST) From: Florian Fainelli Date: Wed, 10 Oct 2007 14:55:55 +0200 Subject: [PATCH] Add missing generic GPIO option support for au1000 To: linux-mips@linux-mips.org MIME-Version: 1.0 X-UID: 104 X-Length: 1275 Content-Type: Multipart/Mixed; boundary="Boundary-00=_evMDHXZ9IbR0RL6" Message-Id: <200710101455.58249.florian.fainelli@telecomint.eu> Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 16934 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: florian.fainelli@telecomint.eu Precedence: bulk X-list: linux-mips This is a multi-part message in MIME format. --Boundary-00=_evMDHXZ9IbR0RL6 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Content-Disposition: inline With the generic GPIO support for au1000, we do not select it in the kernel configuration. Signed-off-by: Florian Fainelli --- arch/mips/au1000/Kconfig | 1 + 1 files changed, 1 insertions(+), 0 deletions(-) --Boundary-00=_evMDHXZ9IbR0RL6 Content-Type: text/plain; charset="utf-8"; name="8dea23a2b6dae52267b3a969e715d3f0753acf47.diff" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="8dea23a2b6dae52267b3a969e715d3f0753acf47.diff" diff --git a/arch/mips/au1000/Kconfig b/arch/mips/au1000/Kconfig index 29c95d9..f03b2eb 100644 --- a/arch/mips/au1000/Kconfig +++ b/arch/mips/au1000/Kconfig @@ -141,3 +141,4 @@ config SOC_AU1X00 select SYS_SUPPORTS_32BIT_KERNEL select SYS_SUPPORTS_APM_EMULATION select SYS_SUPPORTS_KGDB + select GENERIC_GPIO --Boundary-00=_evMDHXZ9IbR0RL6-- From ralf@linux-mips.org Wed Oct 10 14:35:21 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 10 Oct 2007 14:35:23 +0100 (BST) Received: from localhost.localdomain ([127.0.0.1]:6635 "EHLO dl5rb.ham-radio-op.net") by ftp.linux-mips.org with ESMTP id S20023175AbXJJNfV (ORCPT ); Wed, 10 Oct 2007 14:35:21 +0100 Received: from denk.linux-mips.net (denk.linux-mips.net [127.0.0.1]) by dl5rb.ham-radio-op.net (8.14.1/8.13.8) with ESMTP id l9ADZJgf006395; Wed, 10 Oct 2007 14:35:19 +0100 Received: (from ralf@localhost) by denk.linux-mips.net (8.14.1/8.14.1/Submit) id l9ADZJMD006394; Wed, 10 Oct 2007 14:35:19 +0100 Date: Wed, 10 Oct 2007 14:35:19 +0100 From: Ralf Baechle To: Andrew Morton Cc: linux-kernel@vger.kernel.org, linux-mips@linux-mips.org Subject: [PATCH] Add assembler equivalents to __init{,date}_refok Message-ID: <20071010133519.GA6237@linux-mips.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.14 (2007-02-12) Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 16935 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: ralf@linux-mips.org Precedence: bulk X-list: linux-mips --- I need __INIT_REFOK to fix a MODPOST warning for a few MIPS configs which have to call init code from .text very early in the game due to bootloader issues. __INITDATA_REFOK is just for consistency. include/linux/init.h | 2 ++ 1 file changed, 2 insertions(+) diff --git a/include/linux/init.h b/include/linux/init.h index 74b1f43..031edcc 100644 --- a/include/linux/init.h +++ b/include/linux/init.h @@ -66,8 +66,10 @@ /* For assembly routines */ #define __INIT .section ".init.text","ax" +#define __INIT_REFOK .section ".text.init.refok","ax" #define __FINIT .previous #define __INITDATA .section ".init.data","aw" +#define __INITDATA_REFOK .section ".data.init.refok","aw" #ifndef __ASSEMBLY__ /* From ralf@linux-mips.org Wed Oct 10 14:55:22 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 10 Oct 2007 14:55:24 +0100 (BST) Received: from localhost.localdomain ([127.0.0.1]:15777 "EHLO dl5rb.ham-radio-op.net") by ftp.linux-mips.org with ESMTP id S20023332AbXJJNzW (ORCPT ); Wed, 10 Oct 2007 14:55:22 +0100 Received: from denk.linux-mips.net (denk.linux-mips.net [127.0.0.1]) by dl5rb.ham-radio-op.net (8.14.1/8.13.8) with ESMTP id l9ADtM4E006923; Wed, 10 Oct 2007 14:55:22 +0100 Received: (from ralf@localhost) by denk.linux-mips.net (8.14.1/8.14.1/Submit) id l9ADtLhQ006922; Wed, 10 Oct 2007 14:55:21 +0100 Date: Wed, 10 Oct 2007 14:55:21 +0100 From: Ralf Baechle To: Florian Fainelli Cc: linux-mips@linux-mips.org Subject: Re: [PATCH] Add missing generic GPIO option support for au1000 Message-ID: <20071010135521.GA26832@linux-mips.org> References: <200710101455.58249.florian.fainelli@telecomint.eu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200710101455.58249.florian.fainelli@telecomint.eu> User-Agent: Mutt/1.5.14 (2007-02-12) Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 16936 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: ralf@linux-mips.org Precedence: bulk X-list: linux-mips On Wed, Oct 10, 2007 at 02:55:55PM +0200, Florian Fainelli wrote: > With the generic GPIO support for au1000, we do not > select it in the kernel configuration. So I wonder how this one went unnoticed for so long unnoticed - turns out your previous GPIO patch's Kconfig segment for Alchemy from May 22 looks different in GIT than what you mailed out and I think that was a class case of quilt using patch with by default has the bl**dy fuzz factor enabled ... I'll fix this one ... Ralf From florian.fainelli@telecomint.eu Wed Oct 10 15:06:53 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 10 Oct 2007 15:07:02 +0100 (BST) Received: from mx1.minet.net ([157.159.40.25]:4782 "EHLO mx1.minet.net") by ftp.linux-mips.org with ESMTP id S20023306AbXJJOGx (ORCPT ); Wed, 10 Oct 2007 15:06:53 +0100 Received: by mx1.minet.net (Postfix, from userid 101) id 389405CD39; Wed, 10 Oct 2007 16:05:48 +0200 (CEST) Received: from smtp.minet.net (imap.minet.net [192.168.1.27]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.minet.net (Postfix) with ESMTP id 9D4E45CD94 for ; Wed, 10 Oct 2007 15:55:18 +0200 (CEST) Received: from [157.159.47.53] (unknown [157.159.47.53]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: florian) by smtp.minet.net (Postfix) with ESMTP id 446A3D338 for ; Wed, 10 Oct 2007 05:10:50 +0200 (CEST) From: Florian Fainelli Date: Wed, 10 Oct 2007 15:55:44 +0200 Subject: [PATCH] Remove select GENERIC_GPIO for PNX8550 MIME-Version: 1.0 X-UID: 107 X-Length: 1290 To: linux-mips@linux-mips.org Content-Type: Multipart/Mixed; boundary="Boundary-00=_gnNDHpT6Aotx6ka" Message-Id: <200710101555.44586.florian.fainelli@telecomint.eu> Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 16937 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: florian.fainelli@telecomint.eu Precedence: bulk X-list: linux-mips This is a multi-part message in MIME format. --Boundary-00=_gnNDHpT6Aotx6ka Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Content-Disposition: inline This patch removes the selection of GENERIC_GPIO for PNX8550 which was accidentally introduced with commit 524022f507c1158adbcc2259671af01e6117dd5e Signed-off-by: Florian Fainelli --- arch/mips/Kconfig | 1 - 1 files changed, 0 insertions(+), 1 deletions(-) --Boundary-00=_gnNDHpT6Aotx6ka Content-Type: text/plain; charset="utf-8"; name="cb644a00b290a2671730c98666d60e130f8be7e2.diff" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="cb644a00b290a2671730c98666d60e130f8be7e2.diff" diff --git a/arch/mips/Kconfig b/arch/mips/Kconfig index f775d8c..6c67fec 100644 --- a/arch/mips/Kconfig +++ b/arch/mips/Kconfig @@ -860,7 +860,6 @@ config SOC_PNX8550 select SYS_SUPPORTS_32BIT_KERNEL select GENERIC_HARDIRQS_NO__DO_IRQ select SYS_SUPPORTS_KGDB - select GENERIC_GPIO config SWAP_IO_SPACE bool --Boundary-00=_gnNDHpT6Aotx6ka-- From ralf@linux-mips.org Wed Oct 10 15:27:56 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 10 Oct 2007 15:27:59 +0100 (BST) Received: from localhost.localdomain ([127.0.0.1]:23736 "EHLO dl5rb.ham-radio-op.net") by ftp.linux-mips.org with ESMTP id S20024151AbXJJO14 (ORCPT ); Wed, 10 Oct 2007 15:27:56 +0100 Received: from denk.linux-mips.net (denk.linux-mips.net [127.0.0.1]) by dl5rb.ham-radio-op.net (8.14.1/8.13.8) with ESMTP id l9AERtns009436; Wed, 10 Oct 2007 15:27:55 +0100 Received: (from ralf@localhost) by denk.linux-mips.net (8.14.1/8.14.1/Submit) id l9AERtJc009435; Wed, 10 Oct 2007 15:27:55 +0100 Date: Wed, 10 Oct 2007 15:27:55 +0100 From: Ralf Baechle To: Franck Bui-Huu Cc: Thiemo Seufer , "Maciej W. Rozycki" , linux-mips@linux-mips.org Subject: Re: [PATCH 2/6] tlbex.c: Remove relocs[] and labels[] from the init.data section Message-ID: <20071010142755.GA9325@linux-mips.org> References: <47038874.9050704@gmail.com> <20071003131158.GL16772@networkno.de> <4703F155.4000301@gmail.com> <20071003201800.GP16772@networkno.de> <47049734.6050802@gmail.com> <20071004121557.GA28928@linux-mips.org> <4705004C.5000705@gmail.com> <20071005115151.GA16145@linux-mips.org> <470BE58A.9070709@gmail.com> <470BE61F.5020108@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <470BE61F.5020108@gmail.com> User-Agent: Mutt/1.5.14 (2007-02-12) Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 16938 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: ralf@linux-mips.org Precedence: bulk X-list: linux-mips On Tue, Oct 09, 2007 at 10:35:43PM +0200, Franck Bui-Huu wrote: > This patch reduces the kernel image size by making these 2 arrays > automatic variables. > > tlbex.o~old => tlbex.o > text: 9840 9812 -28 0% > data: 3904 1344 -2560 -65% > bss: 1568 1568 0 0% > total: 15312 12724 -2588 -16% > > It increases the stack pressure a lot (more than 2500 bytes) but > at this stage in the boot process, it shouldn't matter. Even more for 64-bit kernel - and I would really like to keep reduce the kernel stack for 64-bit kernels, THREAD_SIZE_ORDER 2 is already slightly painful when memory becomes fragmented. The other issue is that with CPU plugging (halfbreed patches to add that to MIPS are around) this code can be called at any time, not only during early startup when at most a timer interrupt may strike. Bootmem maybe? Ralf From macro@linux-mips.org Wed Oct 10 17:17:35 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 10 Oct 2007 17:17:44 +0100 (BST) Received: from cerber.ds.pg.gda.pl ([153.19.208.18]:33451 "EHLO cerber.ds.pg.gda.pl") by ftp.linux-mips.org with ESMTP id S20021378AbXJJQRf (ORCPT ); Wed, 10 Oct 2007 17:17:35 +0100 Received: from localhost (unknown [127.0.0.17]) by cerber.ds.pg.gda.pl (Postfix) with ESMTP id 8745F400BA; Wed, 10 Oct 2007 18:17:36 +0200 (CEST) X-Virus-Scanned: amavisd-new at cerber.ds.pg.gda.pl Received: from cerber.ds.pg.gda.pl ([153.19.208.18]) by localhost (cerber.ds.pg.gda.pl [153.19.208.18]) (amavisd-new, port 10024) with ESMTP id 5QaC4lV7Wgml; Wed, 10 Oct 2007 18:17:30 +0200 (CEST) Received: from piorun.ds.pg.gda.pl (piorun.ds.pg.gda.pl [153.19.208.8]) by cerber.ds.pg.gda.pl (Postfix) with ESMTP id 75322400D3; Wed, 10 Oct 2007 18:17:25 +0200 (CEST) Received: from blysk.ds.pg.gda.pl (macro@blysk.ds.pg.gda.pl [153.19.208.6]) by piorun.ds.pg.gda.pl (8.13.8/8.13.8) with ESMTP id l9AGHTcn030980; Wed, 10 Oct 2007 18:17:29 +0200 Date: Wed, 10 Oct 2007 17:17:24 +0100 (BST) From: "Maciej W. Rozycki" To: Ralf Baechle cc: Franck Bui-Huu , Thiemo Seufer , linux-mips@linux-mips.org Subject: Re: [PATCH 2/6] tlbex.c: Remove relocs[] and labels[] from the init.data section In-Reply-To: <20071010142755.GA9325@linux-mips.org> Message-ID: References: <47038874.9050704@gmail.com> <20071003131158.GL16772@networkno.de> <4703F155.4000301@gmail.com> <20071003201800.GP16772@networkno.de> <47049734.6050802@gmail.com> <20071004121557.GA28928@linux-mips.org> <4705004C.5000705@gmail.com> <20071005115151.GA16145@linux-mips.org> <470BE58A.9070709@gmail.com> <470BE61F.5020108@gmail.com> <20071010142755.GA9325@linux-mips.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: ClamAV 0.91.2/4521/Wed Oct 10 09:58:01 2007 on piorun.ds.pg.gda.pl X-Virus-Status: Clean Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 16939 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: macro@linux-mips.org Precedence: bulk X-list: linux-mips On Wed, 10 Oct 2007, Ralf Baechle wrote: > > It increases the stack pressure a lot (more than 2500 bytes) but > > at this stage in the boot process, it shouldn't matter. > > Even more for 64-bit kernel - and I would really like to keep reduce > the kernel stack for 64-bit kernels, THREAD_SIZE_ORDER 2 is already > slightly painful when memory becomes fragmented. I think the right fix is to implement "__initbss" along the lines of "__initdata". Maciej From ralf@linux-mips.org Wed Oct 10 17:42:38 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 10 Oct 2007 17:42:40 +0100 (BST) Received: from localhost.localdomain ([127.0.0.1]:45003 "EHLO dl5rb.ham-radio-op.net") by ftp.linux-mips.org with ESMTP id S20021563AbXJJQmi (ORCPT ); Wed, 10 Oct 2007 17:42:38 +0100 Received: from denk.linux-mips.net (denk.linux-mips.net [127.0.0.1]) by dl5rb.ham-radio-op.net (8.14.1/8.13.8) with ESMTP id l9AGgbfn013007; Wed, 10 Oct 2007 17:42:37 +0100 Received: (from ralf@localhost) by denk.linux-mips.net (8.14.1/8.14.1/Submit) id l9AGgaTM013006; Wed, 10 Oct 2007 17:42:36 +0100 Date: Wed, 10 Oct 2007 17:42:36 +0100 From: Ralf Baechle To: "Maciej W. Rozycki" Cc: Franck Bui-Huu , Thiemo Seufer , linux-mips@linux-mips.org Subject: Re: [PATCH 2/6] tlbex.c: Remove relocs[] and labels[] from the init.data section Message-ID: <20071010164236.GB10243@linux-mips.org> References: <4703F155.4000301@gmail.com> <20071003201800.GP16772@networkno.de> <47049734.6050802@gmail.com> <20071004121557.GA28928@linux-mips.org> <4705004C.5000705@gmail.com> <20071005115151.GA16145@linux-mips.org> <470BE58A.9070709@gmail.com> <470BE61F.5020108@gmail.com> <20071010142755.GA9325@linux-mips.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.14 (2007-02-12) Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 16940 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: ralf@linux-mips.org Precedence: bulk X-list: linux-mips On Wed, Oct 10, 2007 at 05:17:24PM +0100, Maciej W. Rozycki wrote: > > > It increases the stack pressure a lot (more than 2500 bytes) but > > > at this stage in the boot process, it shouldn't matter. > > > > Even more for 64-bit kernel - and I would really like to keep reduce > > the kernel stack for 64-bit kernels, THREAD_SIZE_ORDER 2 is already > > slightly painful when memory becomes fragmented. > > I think the right fix is to implement "__initbss" along the lines of > "__initdata". Indeed. Doesn't even look so hard and would likely generally be welcome. Ralf From geert@linux-m68k.org Wed Oct 10 17:55:55 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 10 Oct 2007 17:56:04 +0100 (BST) Received: from hoboe1bl1.telenet-ops.be ([195.130.137.72]:44440 "EHLO hoboe1bl1.telenet-ops.be") by ftp.linux-mips.org with ESMTP id S20021607AbXJJQzz (ORCPT ); Wed, 10 Oct 2007 17:55:55 +0100 Received: from localhost (localhost.localdomain [127.0.0.1]) by hoboe1bl1.telenet-ops.be (Postfix) with SMTP id 7331AD401B; Wed, 10 Oct 2007 18:55:54 +0200 (CEST) Received: from anakin.of.borg (d54C15D55.access.telenet.be [84.193.93.85]) by hoboe1bl1.telenet-ops.be (Postfix) with ESMTP id 34AE8D402B; Wed, 10 Oct 2007 18:55:52 +0200 (CEST) Received: from anakin.of.borg (geert@localhost [127.0.0.1]) by anakin.of.borg (8.14.1/8.14.1/Debian-9) with ESMTP id l9AGtn8I024229 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 10 Oct 2007 18:55:50 +0200 Received: from localhost (geert@localhost) by anakin.of.borg (8.14.1/8.14.1/Submit) with ESMTP id l9AGtkIh024216; Wed, 10 Oct 2007 18:55:46 +0200 X-Authentication-Warning: anakin.of.borg: geert owned process doing -bs Date: Wed, 10 Oct 2007 18:55:45 +0200 (CEST) From: Geert Uytterhoeven To: Ralf Baechle Cc: "Maciej W. Rozycki" , Franck Bui-Huu , Thiemo Seufer , linux-mips@linux-mips.org Subject: Re: [PATCH 2/6] tlbex.c: Remove relocs[] and labels[] from the init.data section In-Reply-To: <20071010164236.GB10243@linux-mips.org> Message-ID: References: <4703F155.4000301@gmail.com> <20071003201800.GP16772@networkno.de> <47049734.6050802@gmail.com> <20071004121557.GA28928@linux-mips.org> <4705004C.5000705@gmail.com> <20071005115151.GA16145@linux-mips.org> <470BE58A.9070709@gmail.com> <470BE61F.5020108@gmail.com> <20071010142755.GA9325@linux-mips.org> <20071010164236.GB10243@linux-mips.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 16941 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: geert@linux-m68k.org Precedence: bulk X-list: linux-mips On Wed, 10 Oct 2007, Ralf Baechle wrote: > On Wed, Oct 10, 2007 at 05:17:24PM +0100, Maciej W. Rozycki wrote: > > > > It increases the stack pressure a lot (more than 2500 bytes) but > > > > at this stage in the boot process, it shouldn't matter. > > > > > > Even more for 64-bit kernel - and I would really like to keep reduce > > > the kernel stack for 64-bit kernels, THREAD_SIZE_ORDER 2 is already > > > slightly painful when memory becomes fragmented. > > > > I think the right fix is to implement "__initbss" along the lines of > > "__initdata". Or e.g. static struct label labels[128] __initdata = { 0, }; Cfr. the old rule `always initialize initdata, even if it must be 0'. > Indeed. Doesn't even look so hard and would likely generally be welcome. That's a valid alternative, of course... Gr{oetje,eeting}s, Geert -- Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say "programmer" or something like that. -- Linus Torvalds From macro@linux-mips.org Wed Oct 10 18:01:31 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 10 Oct 2007 18:01:39 +0100 (BST) Received: from cerber.ds.pg.gda.pl ([153.19.208.18]:43393 "EHLO cerber.ds.pg.gda.pl") by ftp.linux-mips.org with ESMTP id S20021607AbXJJRBb (ORCPT ); Wed, 10 Oct 2007 18:01:31 +0100 Received: from localhost (unknown [127.0.0.17]) by cerber.ds.pg.gda.pl (Postfix) with ESMTP id 667AB4017E; Wed, 10 Oct 2007 19:01:32 +0200 (CEST) X-Virus-Scanned: amavisd-new at cerber.ds.pg.gda.pl Received: from cerber.ds.pg.gda.pl ([153.19.208.18]) by localhost (cerber.ds.pg.gda.pl [153.19.208.18]) (amavisd-new, port 10024) with ESMTP id FuyifmDpMEiJ; Wed, 10 Oct 2007 19:01:26 +0200 (CEST) Received: from piorun.ds.pg.gda.pl (piorun.ds.pg.gda.pl [153.19.208.8]) by cerber.ds.pg.gda.pl (Postfix) with ESMTP id 4F1AA400BA; Wed, 10 Oct 2007 19:01:26 +0200 (CEST) Received: from blysk.ds.pg.gda.pl (macro@blysk.ds.pg.gda.pl [153.19.208.6]) by piorun.ds.pg.gda.pl (8.13.8/8.13.8) with ESMTP id l9AH1Vud007776; Wed, 10 Oct 2007 19:01:31 +0200 Date: Wed, 10 Oct 2007 18:01:25 +0100 (BST) From: "Maciej W. Rozycki" To: Geert Uytterhoeven cc: Ralf Baechle , Franck Bui-Huu , Thiemo Seufer , linux-mips@linux-mips.org Subject: Re: [PATCH 2/6] tlbex.c: Remove relocs[] and labels[] from the init.data section In-Reply-To: Message-ID: References: <4703F155.4000301@gmail.com> <20071003201800.GP16772@networkno.de> <47049734.6050802@gmail.com> <20071004121557.GA28928@linux-mips.org> <4705004C.5000705@gmail.com> <20071005115151.GA16145@linux-mips.org> <470BE58A.9070709@gmail.com> <470BE61F.5020108@gmail.com> <20071010142755.GA9325@linux-mips.org> <20071010164236.GB10243@linux-mips.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: ClamAV 0.91.2/4521/Wed Oct 10 09:58:01 2007 on piorun.ds.pg.gda.pl X-Virus-Status: Clean Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 16942 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: macro@linux-mips.org Precedence: bulk X-list: linux-mips On Wed, 10 Oct 2007, Geert Uytterhoeven wrote: > Or e.g. static struct label labels[128] __initdata = { 0, }; > Cfr. the old rule `always initialize initdata, even if it must be 0'. But this will not reduce the size of the kernel image, which is the objective here. Maciej From geert@linux-m68k.org Wed Oct 10 18:09:22 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 10 Oct 2007 18:09:31 +0100 (BST) Received: from ananke.telenet-ops.be ([195.130.137.78]:6546 "EHLO ananke.telenet-ops.be") by ftp.linux-mips.org with ESMTP id S20021686AbXJJRJW (ORCPT ); Wed, 10 Oct 2007 18:09:22 +0100 Received: from localhost (localhost.localdomain [127.0.0.1]) by ananke.telenet-ops.be (Postfix) with SMTP id 4208F3923F4; Wed, 10 Oct 2007 19:09:12 +0200 (CEST) Received: from anakin.of.borg (d54C15D55.access.telenet.be [84.193.93.85]) by ananke.telenet-ops.be (Postfix) with ESMTP id D7CE83923D2; Wed, 10 Oct 2007 19:09:09 +0200 (CEST) Received: from anakin.of.borg (geert@localhost [127.0.0.1]) by anakin.of.borg (8.14.1/8.14.1/Debian-9) with ESMTP id l9AH99fW028259 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 10 Oct 2007 19:09:09 +0200 Received: from localhost (geert@localhost) by anakin.of.borg (8.14.1/8.14.1/Submit) with ESMTP id l9AH99RD028256; Wed, 10 Oct 2007 19:09:09 +0200 X-Authentication-Warning: anakin.of.borg: geert owned process doing -bs Date: Wed, 10 Oct 2007 19:09:09 +0200 (CEST) From: Geert Uytterhoeven To: "Maciej W. Rozycki" cc: Ralf Baechle , Franck Bui-Huu , Thiemo Seufer , linux-mips@linux-mips.org Subject: Re: [PATCH 2/6] tlbex.c: Remove relocs[] and labels[] from the init.data section In-Reply-To: Message-ID: References: <4703F155.4000301@gmail.com> <20071003201800.GP16772@networkno.de> <47049734.6050802@gmail.com> <20071004121557.GA28928@linux-mips.org> <4705004C.5000705@gmail.com> <20071005115151.GA16145@linux-mips.org> <470BE58A.9070709@gmail.com> <470BE61F.5020108@gmail.com> <20071010142755.GA9325@linux-mips.org> <20071010164236.GB10243@linux-mips.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 16943 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: geert@linux-m68k.org Precedence: bulk X-list: linux-mips On Wed, 10 Oct 2007, Maciej W. Rozycki wrote: > On Wed, 10 Oct 2007, Geert Uytterhoeven wrote: > > Or e.g. static struct label labels[128] __initdata = { 0, }; > > Cfr. the old rule `always initialize initdata, even if it must be 0'. > > But this will not reduce the size of the kernel image, which is the > objective here. That's true. Gr{oetje,eeting}s, Geert -- Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say "programmer" or something like that. -- Linus Torvalds From ths@networkno.de Wed Oct 10 18:11:08 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 10 Oct 2007 18:11:17 +0100 (BST) Received: from relay01.mx.bawue.net ([193.7.176.67]:35989 "EHLO relay01.mx.bawue.net") by ftp.linux-mips.org with ESMTP id S20021541AbXJJRLI (ORCPT ); Wed, 10 Oct 2007 18:11:08 +0100 Received: from lagash (intrt.mips-uk.com [194.74.144.130]) by relay01.mx.bawue.net (Postfix) with ESMTP id DE3E448BCA; Wed, 10 Oct 2007 19:10:19 +0200 (CEST) Received: from ths by lagash with local (Exim 4.67) (envelope-from ) id 1Iff4p-00034U-9g; Wed, 10 Oct 2007 18:10:31 +0100 Date: Wed, 10 Oct 2007 18:10:31 +0100 From: Thiemo Seufer To: kaka Cc: linux-mips@linux-mips.org Subject: Re: Unknown symbol errors in insmod Message-ID: <20071010171030.GB3379@networkno.de> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.16 (2007-06-11) Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 16944 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: ths@networkno.de Precedence: bulk X-list: linux-mips kaka wrote: > Hi All, > > WHile installing framebuffer driver for BCM chip in MIPS platform(cross > compiled in intel 86). > I am getting the following error. > Can somebody help in this regard? > Thanks in Advance. > > # insmod brcmstfb.ko > brcmstfb: Unknown symbol unregister_framebuffer > brcmstfb: Unknown symbol printf > brcmstfb: Unknown symbol __make_dp > brcmstfb: Unknown symbol malloc > brcmstfb: Unknown symbol framebuffer_alloc > brcmstfb: Unknown symbol fb_find_mode > brcmstfb: Unknown symbol fb_dealloc_cmap > brcmstfb: Unknown symbol brcm_dir_entry > brcmstfb: Unknown symbol register_framebuffer > brcmstfb: Unknown symbol fb_alloc_cmap > brcmstfb: Unknown symbol framebuffer_release > brcmstfb: Unknown symbol free Ask the supplier of "brcmstfb.ko" what they did there. printf/malloc/free aren't functions which are normally available from kernel proper. Thiemo From fbuihuu@gmail.com Wed Oct 10 20:29:35 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 10 Oct 2007 20:29:43 +0100 (BST) Received: from nf-out-0910.google.com ([64.233.182.188]:62695 "EHLO nf-out-0910.google.com") by ftp.linux-mips.org with ESMTP id S20030240AbXJJT3e (ORCPT ); Wed, 10 Oct 2007 20:29:34 +0100 Received: by nf-out-0910.google.com with SMTP id c10so269269nfd for ; Wed, 10 Oct 2007 12:29:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:x-enigmail-version:content-type:content-transfer-encoding; bh=Cj1KA0ycsMPyEvaMnAGSvMmYD95SZaqjXpQrUxGpBc0=; b=uguyX1bb6zhhbMqinaPTqvOuq9J+O6clq/To9xiCUN26y38KdPDt6Rb4zz3+RW+qpPbtR+38BDkJ2XdWlEC2hoJ9Fj1/tKTOoLxUUexstyqLWXafXIsNoXmsZkBCRQxjRXPmsR0RjwR4K4mJX2R4LFJGeVZBdyuogVv4WdBgRI4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:x-enigmail-version:content-type:content-transfer-encoding; b=MiGuOwbcJY9PeeUNGpqQU+F3MEmLcByVZ4hjxDFIB8IJseinCNmnXMuviLVl451Ln6TahQ5oZarVAGABMyg3eqIE/ZPEsI04r6lwVIFGq4SbW1V2RCaCEuhd7rMagu3cTXqTNg4MZNiPOrMqsbWiaf4BQ05Sn8ZSR3L0mjq78WY= Received: by 10.86.76.16 with SMTP id y16mr803452fga.1192044571220; Wed, 10 Oct 2007 12:29:31 -0700 (PDT) Received: from ?192.168.0.1? ( [82.235.205.153]) by mx.google.com with ESMTPS id v23sm2041141fkd.2007.10.10.12.29.29 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 10 Oct 2007 12:29:30 -0700 (PDT) Message-ID: <470D2804.2090107@gmail.com> Date: Wed, 10 Oct 2007 21:29:08 +0200 From: Franck Bui-Huu User-Agent: Thunderbird 2.0.0.5 (X11/20070719) MIME-Version: 1.0 To: "Maciej W. Rozycki" CC: Ralf Baechle , Thiemo Seufer , linux-mips@linux-mips.org Subject: Re: [PATCH 2/6] tlbex.c: Remove relocs[] and labels[] from the init.data section References: <47038874.9050704@gmail.com> <20071003131158.GL16772@networkno.de> <4703F155.4000301@gmail.com> <20071003201800.GP16772@networkno.de> <47049734.6050802@gmail.com> <20071004121557.GA28928@linux-mips.org> <4705004C.5000705@gmail.com> <20071005115151.GA16145@linux-mips.org> <470BE58A.9070709@gmail.com> <470BE61F.5020108@gmail.com> <20071010142755.GA9325@linux-mips.org> In-Reply-To: X-Enigmail-Version: 0.95.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 16945 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: fbuihuu@gmail.com Precedence: bulk X-list: linux-mips Maciej W. Rozycki wrote: > On Wed, 10 Oct 2007, Ralf Baechle wrote: > >>> It increases the stack pressure a lot (more than 2500 bytes) but >>> at this stage in the boot process, it shouldn't matter. >> Even more for 64-bit kernel - and I would really like to keep reduce >> the kernel stack for 64-bit kernels, THREAD_SIZE_ORDER 2 is already >> slightly painful when memory becomes fragmented. > > I think the right fix is to implement "__initbss" along the lines of > "__initdata". > yes I think so. Franck From fbuihuu@gmail.com Wed Oct 10 20:59:40 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 10 Oct 2007 20:59:49 +0100 (BST) Received: from fk-out-0910.google.com ([209.85.128.189]:22069 "EHLO fk-out-0910.google.com") by ftp.linux-mips.org with ESMTP id S20030337AbXJJT7k (ORCPT ); Wed, 10 Oct 2007 20:59:40 +0100 Received: by fk-out-0910.google.com with SMTP id f40so295950fka for ; Wed, 10 Oct 2007 12:59:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:x-enigmail-version:content-type:content-transfer-encoding; bh=742hgTHZyqZEaHYqWIcMnWI+kyryZhI9IYXAEMApRLs=; b=aKLJ0vk9x6XoXHaYk1MV1PVd8xdFMPKl1ZTJ8ECR1yEef0ttNeGREmqa1I2FzMjUKuwfE26oq3pSUEUaK7qTrMfn+XkVCpgvGsAGzt9HAqw+aiJ5XGehUaJQ3tUY6CmhgpIrUduqZINjFm9oki9EqDbUqWvob8iPwhW8ByMUibY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:x-enigmail-version:content-type:content-transfer-encoding; b=eTEAmgpY2YvMo/tWTa61GOOYmhQtyVx4YJy5oQELvtSrgF1/t6JYPpU4WfyWe5khs79YheAAuVzyaV9TZUg0Yqs9r+1bNlUw8YxOoWvx21MAq7w78Nlf2s8Gor+SzDN1B4SY7G35re4IDqcEMgTuADGj+r5MK66oHE/UltXZ/Xk= Received: by 10.82.165.13 with SMTP id n13mr2279012bue.1192046362869; Wed, 10 Oct 2007 12:59:22 -0700 (PDT) Received: from ?192.168.0.1? ( [82.235.205.153]) by mx.google.com with ESMTPS id w5sm2628465mue.2007.10.10.12.59.19 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 10 Oct 2007 12:59:20 -0700 (PDT) Message-ID: <470D2F03.10406@gmail.com> Date: Wed, 10 Oct 2007 21:58:59 +0200 From: Franck Bui-Huu User-Agent: Thunderbird 2.0.0.5 (X11/20070719) MIME-Version: 1.0 To: Geert Uytterhoeven CC: Ralf Baechle , "Maciej W. Rozycki" , Thiemo Seufer , linux-mips@linux-mips.org Subject: Re: [PATCH 2/6] tlbex.c: Remove relocs[] and labels[] from the init.data section References: <4703F155.4000301@gmail.com> <20071003201800.GP16772@networkno.de> <47049734.6050802@gmail.com> <20071004121557.GA28928@linux-mips.org> <4705004C.5000705@gmail.com> <20071005115151.GA16145@linux-mips.org> <470BE58A.9070709@gmail.com> <470BE61F.5020108@gmail.com> <20071010142755.GA9325@linux-mips.org> <20071010164236.GB10243@linux-mips.org> In-Reply-To: X-Enigmail-Version: 0.95.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 16946 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: fbuihuu@gmail.com Precedence: bulk X-list: linux-mips Geert Uytterhoeven wrote: > Or e.g. static struct label labels[128] __initdata = { 0, }; > Cfr. the old rule `always initialize initdata, even if it must be 0'. > I also noticed that init data aren't initialized as they should be, but they're still part of initdata not bss. Franck From m.jancar@satca.net Wed Oct 10 21:53:18 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 10 Oct 2007 21:53:26 +0100 (BST) Received: from unassigned-81-90-243-194.ujezd.net ([81.90.243.194]:30167 "EHLO skerikoff.satca.net") by ftp.linux-mips.org with ESMTP id S20030184AbXJJUxS (ORCPT ); Wed, 10 Oct 2007 21:53:18 +0100 Received: from localhost (unknown [127.0.0.1]) by skerikoff.satca.net (Postfix) with ESMTP id 1488CE410B8; Wed, 10 Oct 2007 20:29:58 +0000 (UTC) X-Virus-Scanned: amavisd-new at satca.net Received: from skerikoff.satca.net ([127.0.0.1]) by localhost (skerikoff.satca.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kQaBHKriK5MX; Wed, 10 Oct 2007 22:29:56 +0200 (CEST) Received: from [10.1.1.70] (unknown [192.168.51.95]) by skerikoff.satca.net (Postfix) with ESMTP id 5BCB3E41090; Wed, 10 Oct 2007 20:29:56 +0000 (UTC) Message-ID: <470D3A94.9090401@satca.net> Date: Wed, 10 Oct 2007 22:48:20 +0200 From: Marian Jancar User-Agent: Thunderbird 2.0.0.5 (X11/20070719) MIME-Version: 1.0 To: linux-mips@linux-mips.org CC: juhosg@openwrt.org Subject: Linux 2.6.22 on ADM5120 X-Enigmail-Version: 0.95.2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 16947 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: m.jancar@satca.net Precedence: bulk X-list: linux-mips Hi, I'm trying to boot current Linux kernel with patches from OpenWRT on an Infineon Easy5120-RT but without the LZMA loader. Hence I mimic what patches from http://nano.gmxhome.de/linux-2.6.17.11-adm5120-patch.diff.gz and http://www.student.tue.nl/Q/t.f.a.wilms/adm5120/files/linux-2.6.12-rc1-adm.diff (I have verified myself that the later boots, as also the 2.6.22 with the LZMA does) do - use 0x80002000 as LOADDADD instead of 0x80001000, and fill to 0x6d8 + jump to kernel_entry in head.S, but the resulting vmlinuz doesn't boot. There is some info at http://www.linux-mips.org/wiki/Adm5120#Linux_Support diff -urNdp linux-2.6.22.9-vanilla/arch/mips/Makefile linux-2.6.22.9/arch/mips/Makefile --- linux-2.6.22.9-vanilla/arch/mips/Makefile 2007-09-26 20:03:01.000000000 +0200 +++ linux-2.6.22.9/arch/mips/Makefile 2007-10-10 20:44:24.000000000 +0200 @@ -165,6 +165,13 @@ cflags-$(CONFIG_MACH_JAZZ) += -Iinclude/ load-$(CONFIG_MACH_JAZZ) += 0xffffffff80080000 # +# ADMtek 5120 +# + +core-$(CONFIG_MIPS_ADM5120) += arch/mips/adm5120/ +load-$(CONFIG_MIPS_ADM5120) += 0xffffffff80002000 + +# # Common Alchemy Au1x00 stuff # core-$(CONFIG_SOC_AU1X00) += arch/mips/au1000/common/ diff -urNdp linux-2.6.22.9-vanilla/arch/mips/kernel/head.S linux-2.6.22.9/arch/mips/kernel/head.S --- linux-2.6.22.9-vanilla/arch/mips/kernel/head.S 2007-09-26 20:03:01.000000000 +0200 +++ linux-2.6.22.9/arch/mips/kernel/head.S 2007-10-10 20:44:24.000000000 +0200 @@ -134,6 +134,11 @@ * Necessary for machines which link their kernels at KSEG0. */ .fill 0x400 +#ifdef CONFIG_MIPS_ADM5120 + /* ADM5120 bootloader jumps to 0x6d8 */ + .fill 0x2d8 + j kernel_entry +#endif EXPORT(stext) # used for profiling EXPORT(_stext) Any clues what I am missing or what I do wrong? Marian From technoboy85@gmail.com Thu Oct 11 01:48:54 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 11 Oct 2007 01:49:03 +0100 (BST) Received: from wx-out-0506.google.com ([66.249.82.238]:30266 "EHLO wx-out-0506.google.com") by ftp.linux-mips.org with ESMTP id S20021373AbXJKAsy (ORCPT ); Thu, 11 Oct 2007 01:48:54 +0100 Received: by wx-out-0506.google.com with SMTP id h30so378468wxd for ; Wed, 10 Oct 2007 17:48:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:from:to:subject:date:user-agent:cc:mime-version:content-type:content-transfer-encoding:content-disposition:message-id; bh=TsyJmUrjpSlKhbulh0yzMN1aXMmK2mXfuiFPv0UW1XI=; b=QpwkQ2fn4xHfrr8w18B5O6GJq+9xdSwAihpjTQ2mGI0dfeJlWjm52FQFT04AwF2J+TZVg88yIS2gFNt+gztNu8xkVQjQJ8P24QnnJT3osYM8ifmb3p3633Ip9pPp3cQAK07LdDpEw3VrESsr863vY1OfAdZaXn8bpqELliVLqUg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:from:to:subject:date:user-agent:cc:mime-version:content-type:content-transfer-encoding:content-disposition:message-id; b=GJMs1eOnEiJWLGChOmSBvpWaRbpHMuJZeUOqebnTHt2qP2WPGcrcrMy+nc+iKzlJpOpvoLE0DY0XtejFXW07Fxa+Bbhq72L8Txjz3PVdPbjth7uGTuiOlBbkv7uzYDHStHUwfmaMEEGlhDRcCJlYuL+UzgC6UlUb+blGFmjPtag= Received: by 10.70.9.8 with SMTP id 8mr2184552wxi.1192063715932; Wed, 10 Oct 2007 17:48:35 -0700 (PDT) Received: from ?192.168.0.3? ( [87.18.114.61]) by mx.google.com with ESMTPS id h10sm1796768wxd.2007.10.10.17.48.32 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 10 Oct 2007 17:48:34 -0700 (PDT) From: Matteo Croce To: linux-mips@linux-mips.org Subject: [PATCH][MIPS][0/6] AR7: AR7 strikes back Date: Thu, 11 Oct 2007 02:48:32 +0200 User-Agent: KMail/1.9.6 (enterprise 0.20070907.709405) Cc: nico@openwrt.org, nbd@openwrt.org, florian@openwrt.org, openwrt-devel@lists.openwrt.org, Andrew Morton MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200710110248.33028.technoboy85@gmail.com> Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 16948 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: technoboy85@gmail.com Precedence: bulk X-list: linux-mips Here are the new patches made against latest 2.6.23 git tree From technoboy85@gmail.com Thu Oct 11 01:54:50 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 11 Oct 2007 01:54:59 +0100 (BST) Received: from wx-out-0506.google.com ([66.249.82.227]:48199 "EHLO wx-out-0506.google.com") by ftp.linux-mips.org with ESMTP id S20021451AbXJKAyu (ORCPT ); Thu, 11 Oct 2007 01:54:50 +0100 Received: by wx-out-0506.google.com with SMTP id h30so379538wxd for ; Wed, 10 Oct 2007 17:54:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:from:to:subject:date:user-agent:references:in-reply-to:cc:mime-version:content-type:content-transfer-encoding:content-disposition:message-id; bh=6WelgObsaivyhElCDFUN84ynCDw+ZYiI5ejW82AogHQ=; b=H7rWAHzUbORrxYVqB8/P0Enl97niYHCSOaHW/hKu56rbVurBnQ+3xOMLYnxKqoFdBVE+V9iEVDnjqUHqVEzL4gIZFTW/Z3zlLzu0q4JsRhvB9Z9ikxpfvv9i7dcLlqwtS7bk9gU5g3h4EXVFz769rq7Nh32YH1M6KJRbPv0juro= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:from:to:subject:date:user-agent:references:in-reply-to:cc:mime-version:content-type:content-transfer-encoding:content-disposition:message-id; b=FwCYFKNYkhPLQOqR3omMSjV4Ot6jjbG0A7wsB2zGaXUdRoP3+TyUSAtFGqo/8RBOSNoiMFzEGzUa8zeftz8AYzvG6P1Ct5qqLdrKR8ASi11xle0xFx0L2TL3XzgwPrLJ/LUv+BaaOWVm+Nd9OP4o5JSL/c1L6jUPpfmJ2HxzCJ4= Received: by 10.70.65.5 with SMTP id n5mr1945377wxa.1192064071622; Wed, 10 Oct 2007 17:54:31 -0700 (PDT) Received: from ?192.168.0.3? ( [87.18.114.61]) by mx.google.com with ESMTPS id i13sm1801092wxd.2007.10.10.17.54.28 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 10 Oct 2007 17:54:30 -0700 (PDT) From: Matteo Croce To: linux-mips@linux-mips.org Subject: [PATCH][MIPS][2/6] AR7: VLYNQ bus Date: Thu, 11 Oct 2007 02:54:28 +0200 User-Agent: KMail/1.9.6 (enterprise 0.20070907.709405) References: <200710110248.33028.technoboy85@gmail.com> In-Reply-To: <200710110248.33028.technoboy85@gmail.com> Cc: Eugene Konev , Andrew Morton MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200710110254.28506.technoboy85@gmail.com> Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 16949 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: technoboy85@gmail.com Precedence: bulk X-list: linux-mips Support for the Texas Instrument VLYNQ interconnect bus Signed-off-by: Matteo Croce Signed-off-by: Eugene Konev diff --git a/drivers/vlynq/Kconfig b/drivers/vlynq/Kconfig new file mode 100644 index 0000000..2c8ffe0 --- /dev/null +++ b/drivers/vlynq/Kconfig @@ -0,0 +1,13 @@ +menu "TI VLYNQ" + +config VLYNQ + bool "TI VLYNQ bus support" + depends on AR7 && EXPERIMENTAL + help + Support for the TI VLYNQ bus + + The module will be called vlynq + + If unsure, say N + +endmenu diff --git a/drivers/vlynq/Makefile b/drivers/vlynq/Makefile new file mode 100644 index 0000000..b3f6114 --- /dev/null +++ b/drivers/vlynq/Makefile @@ -0,0 +1,5 @@ +# +# Makefile for kernel vlynq drivers +# + +obj-$(CONFIG_VLYNQ) += vlynq.o diff --git a/drivers/vlynq/vlynq.c b/drivers/vlynq/vlynq.c new file mode 100644 index 0000000..0dd6c18 --- /dev/null +++ b/drivers/vlynq/vlynq.c @@ -0,0 +1,670 @@ +/* + * Copyright (C) 2006, 2007 OpenWrt.org + * + * 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., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA + */ + +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include + +#include + +#define VLYNQ_CTRL_PM_ENABLE 0x80000000 +#define VLYNQ_CTRL_CLOCK_INT 0x00008000 +#define VLYNQ_CTRL_CLOCK_DIV(x) (((x) & 7) << 16) +#define VLYNQ_CTRL_INT_LOCAL 0x00004000 +#define VLYNQ_CTRL_INT_ENABLE 0x00002000 +#define VLYNQ_CTRL_INT_VECTOR(x) (((x) & 0x1f) << 8) +#define VLYNQ_CTRL_INT2CFG 0x00000080 +#define VLYNQ_CTRL_RESET 0x00000001 + +#define VLYNQ_INT_OFFSET 0x00000014 +#define VLYNQ_REMOTE_OFFSET 0x00000080 + +#define VLYNQ_STATUS_LINK 0x00000001 +#define VLYNQ_STATUS_LERROR 0x00000080 +#define VLYNQ_STATUS_RERROR 0x00000100 + +#define VINT_ENABLE 0x00000100 +#define VINT_TYPE_EDGE 0x00000080 +#define VINT_LEVEL_LOW 0x00000040 +#define VINT_VECTOR(x) ((x) & 0x1f) +#define VINT_OFFSET(irq) (8 * ((irq) % 4)) + +#define VLYNQ_AUTONEGO_V2 0x00010000 + +struct vlynq_regs { + u32 revision; + u32 control; + u32 status; + u32 int_prio; + u32 int_status; + u32 int_pending; + u32 int_ptr; + u32 tx_offset; + struct vlynq_mapping rx_mapping[4]; + u32 chip; + u32 autonego; + u32 unused[6]; + u32 int_device[8]; +} __attribute__ ((packed)); + +#define vlynq_reg_read(reg) readl(&(reg)) +#define vlynq_reg_write(reg, val) writel(val, &(reg)) + +static int __vlynq_enable_device(struct vlynq_device *dev); + +#ifdef VLYNQ_DEBUG +static void vlynq_dump_regs(struct vlynq_device *dev) +{ + int i; + printk(KERN_DEBUG "VLYNQ local=%p remote=%p\n", + dev->local, dev->remote); + for (i = 0; i < 32; i++) { + printk(KERN_DEBUG "VLYNQ: local %d: %08x\n", + i + 1, ((u32 *)dev->local)[i]); + printk(KERN_DEBUG "VLYNQ: remote %d: %08x\n", + i + 1, ((u32 *)dev->remote)[i]); + } +} + +static void vlynq_dump_mem(u32 *base, int count) +{ + int i; + for (i = 0; i < (count + 3) / 4; i++) { + if (i % 4 == 0) printk(KERN_DEBUG "\nMEM[0x%04x]:", i * 4); + printk(KERN_DEBUG " 0x%08x", *(base + i)); + } + printk(KERN_DEBUG "\n"); +} +#endif + +int vlynq_linked(struct vlynq_device *dev) +{ + int i; + + for (i = 0; i < 100; i++) + if (vlynq_reg_read(dev->local->status) & VLYNQ_STATUS_LINK) + return 1; + else + cpu_relax(); + + return 0; +} + +static void vlynq_irq_unmask(unsigned int irq) +{ + u32 val; + struct vlynq_device *dev = get_irq_chip_data(irq); + int virq; + + BUG_ON(!dev); + virq = irq - dev->irq_start; + val = vlynq_reg_read(dev->remote->int_device[virq >> 2]); + val |= (VINT_ENABLE | virq) << VINT_OFFSET(virq); + vlynq_reg_write(dev->remote->int_device[virq >> 2], val); +} + +static void vlynq_irq_mask(unsigned int irq) +{ + u32 val; + struct vlynq_device *dev = get_irq_chip_data(irq); + int virq; + + BUG_ON(!dev); + virq = irq - dev->irq_start; + val = vlynq_reg_read(dev->remote->int_device[virq >> 2]); + val &= ~(VINT_ENABLE << VINT_OFFSET(virq)); + vlynq_reg_write(dev->remote->int_device[virq >> 2], val); +} + +static int vlynq_irq_type(unsigned int irq, unsigned int flow_type) +{ + u32 val; + struct vlynq_device *dev = get_irq_chip_data(irq); + int virq; + + BUG_ON(!dev); + virq = irq - dev->irq_start; + val = vlynq_reg_read(dev->remote->int_device[virq >> 2]); + switch (flow_type & IRQ_TYPE_SENSE_MASK) { + case IRQ_TYPE_EDGE_RISING: + case IRQ_TYPE_EDGE_FALLING: + case IRQ_TYPE_EDGE_BOTH: + val |= VINT_TYPE_EDGE << VINT_OFFSET(virq); + val &= ~(VINT_LEVEL_LOW << VINT_OFFSET(virq)); + break; + case IRQ_TYPE_LEVEL_HIGH: + val &= ~(VINT_TYPE_EDGE << VINT_OFFSET(virq)); + val &= ~(VINT_LEVEL_LOW << VINT_OFFSET(virq)); + break; + case IRQ_TYPE_LEVEL_LOW: + val &= ~(VINT_TYPE_EDGE << VINT_OFFSET(virq)); + val |= VINT_LEVEL_LOW << VINT_OFFSET(virq); + break; + default: + return -EINVAL; + } + vlynq_reg_write(dev->remote->int_device[virq >> 2], val); + return 0; +} + +static void vlynq_local_ack(unsigned int irq) +{ + struct vlynq_device *dev = get_irq_chip_data(irq); + u32 status = vlynq_reg_read(dev->local->status); + if (printk_ratelimit()) + printk(KERN_DEBUG "%s: local status: 0x%08x\n", + dev->dev.bus_id, status); + vlynq_reg_write(dev->local->status, status); +} + +static void vlynq_remote_ack(unsigned int irq) +{ + struct vlynq_device *dev = get_irq_chip_data(irq); + u32 status = vlynq_reg_read(dev->remote->status); + if (printk_ratelimit()) + printk(KERN_DEBUG "%s: remote status: 0x%08x\n", + dev->dev.bus_id, status); + vlynq_reg_write(dev->remote->status, status); +} + +static irqreturn_t vlynq_irq(int irq, void *dev_id) +{ + struct vlynq_device *dev = dev_id; + u32 status; + int virq = 0; + + status = vlynq_reg_read(dev->local->int_status); + vlynq_reg_write(dev->local->int_status, status); + + if (unlikely(!status)) + spurious_interrupt(); + + while (status) { + if (status & 1) + do_IRQ(dev->irq_start + virq); + status >>= 1; + virq++; + } + + return IRQ_HANDLED; +} + +static struct irq_chip vlynq_irq_chip = { + .name = "vlynq", + .unmask = vlynq_irq_unmask, + .mask = vlynq_irq_mask, + .set_type = vlynq_irq_type, +}; + +static struct irq_chip vlynq_local_chip = { + .name = "vlynq local error", + .unmask = vlynq_irq_unmask, + .mask = vlynq_irq_mask, + .ack = vlynq_local_ack, +}; + +static struct irq_chip vlynq_remote_chip = { + .name = "vlynq local error", + .unmask = vlynq_irq_unmask, + .mask = vlynq_irq_mask, + .ack = vlynq_remote_ack, +}; + +static int vlynq_setup_irq(struct vlynq_device *dev) +{ + u32 val; + int i, virq; + + if (dev->local_irq == dev->remote_irq) { + printk(KERN_ERR + "%s: local vlynq irq should be different from remote\n", + dev->dev.bus_id); + return -EINVAL; + } + + /* Clear local and remote error bits */ + vlynq_reg_write(dev->local->status, vlynq_reg_read(dev->local->status)); + vlynq_reg_write(dev->remote->status, + vlynq_reg_read(dev->remote->status)); + + /* Now setup interrupts */ + val = VLYNQ_CTRL_INT_VECTOR(dev->local_irq); + val |= VLYNQ_CTRL_INT_ENABLE | VLYNQ_CTRL_INT_LOCAL | + VLYNQ_CTRL_INT2CFG; + val |= vlynq_reg_read(dev->local->control); + vlynq_reg_write(dev->local->int_ptr, VLYNQ_INT_OFFSET); + vlynq_reg_write(dev->local->control, val); + + val = VLYNQ_CTRL_INT_VECTOR(dev->remote_irq); + val |= VLYNQ_CTRL_INT_ENABLE; + val |= vlynq_reg_read(dev->remote->control); + vlynq_reg_write(dev->remote->int_ptr, VLYNQ_INT_OFFSET); + vlynq_reg_write(dev->remote->control, val); + + for (i = dev->irq_start; i <= dev->irq_end; i++) { + virq = i - dev->irq_start; + if (virq == dev->local_irq) { + set_irq_chip_and_handler(i, &vlynq_local_chip, + handle_level_irq); + set_irq_chip_data(i, dev); + } else if (virq == dev->remote_irq) { + set_irq_chip_and_handler(i, &vlynq_remote_chip, + handle_level_irq); + set_irq_chip_data(i, dev); + } else { + set_irq_chip_and_handler(i, &vlynq_irq_chip, + handle_simple_irq); + set_irq_chip_data(i, dev); + vlynq_reg_write(dev->remote->int_device[virq >> 2], 0); + } + } + + if (request_irq(dev->irq, vlynq_irq, IRQF_SHARED, "vlynq", dev)) { + printk(KERN_ERR "%s: request_irq failed\n", dev->dev.bus_id); + return -EAGAIN; + } + + return 0; +} + +static void vlynq_device_release(struct device *dev) +{ + struct vlynq_device *vdev = to_vlynq_device(dev); + kfree(vdev); +} + +static int vlynq_device_match(struct device *dev, + struct device_driver *drv) +{ + struct vlynq_device *vdev = to_vlynq_device(dev); + struct vlynq_driver *vdrv = to_vlynq_driver(drv); + struct plat_vlynq_ops *ops = dev->platform_data; + struct vlynq_device_id *ids = vdrv->id_table; + u32 id = 0; + int result; + + while (ids->id) { + vdev->divisor = ids->divisor; + result = __vlynq_enable_device(vdev); + if (result == 0) { + id = vlynq_reg_read(vdev->remote->chip); + ops->off(vdev); + if (ids->id == id) { + vlynq_set_drvdata(vdev, ids); + return 1; + } + } + ids++; + } + return 0; +} + +static int vlynq_device_probe(struct device *dev) +{ + struct vlynq_device *vdev = to_vlynq_device(dev); + struct vlynq_driver *drv = to_vlynq_driver(dev->driver); + struct vlynq_device_id *id = vlynq_get_drvdata(vdev); + int result = -ENODEV; + + get_device(dev); + if (drv && drv->probe) + result = drv->probe(vdev, id); + if (result) + put_device(dev); + return result; +} + +static int vlynq_device_remove(struct device *dev) +{ + struct vlynq_driver *drv = to_vlynq_driver(dev->driver); + if (drv && drv->remove) + drv->remove(to_vlynq_device(dev)); + put_device(dev); + return 0; +} + +int __vlynq_register_driver(struct vlynq_driver *driver, struct module *owner) +{ + driver->driver.name = driver->name; + driver->driver.bus = &vlynq_bus_type; + return driver_register(&driver->driver); +} +EXPORT_SYMBOL(__vlynq_register_driver); + +void vlynq_unregister_driver(struct vlynq_driver *driver) +{ + driver_unregister(&driver->driver); +} +EXPORT_SYMBOL(vlynq_unregister_driver); + +static int __vlynq_enable_device(struct vlynq_device *dev) +{ + int i, result; + struct plat_vlynq_ops *ops = dev->dev.platform_data; + + result = ops->on(dev); + if (result) + return result; + + switch (dev->divisor) { + case vlynq_div_auto: + /* Only try locally supplied clock, others cause problems */ + vlynq_reg_write(dev->remote->control, 0); + for (i = vlynq_ldiv1; i <= vlynq_ldiv8; i++) { + vlynq_reg_write(dev->local->control, + VLYNQ_CTRL_CLOCK_INT | + VLYNQ_CTRL_CLOCK_DIV(i - vlynq_ldiv1)); + if (vlynq_linked(dev)) { + printk(KERN_DEBUG + "%s: using local clock divisor %d\n", + dev->dev.bus_id, i - vlynq_ldiv1 + 1); + dev->divisor = i; + return 0; + } + } + case vlynq_ldiv1: case vlynq_ldiv2: case vlynq_ldiv3: case vlynq_ldiv4: + case vlynq_ldiv5: case vlynq_ldiv6: case vlynq_ldiv7: case vlynq_ldiv8: + vlynq_reg_write(dev->remote->control, 0); + vlynq_reg_write(dev->local->control, + VLYNQ_CTRL_CLOCK_INT | + VLYNQ_CTRL_CLOCK_DIV(dev->divisor - + vlynq_ldiv1)); + if (vlynq_linked(dev)) { + printk(KERN_DEBUG + "%s: using local clock divisor %d\n", + dev->dev.bus_id, dev->divisor - vlynq_ldiv1 + 1); + return 0; + } + break; + case vlynq_rdiv1: case vlynq_rdiv2: case vlynq_rdiv3: case vlynq_rdiv4: + case vlynq_rdiv5: case vlynq_rdiv6: case vlynq_rdiv7: case vlynq_rdiv8: + vlynq_reg_write(dev->local->control, 0); + vlynq_reg_write(dev->remote->control, + VLYNQ_CTRL_CLOCK_INT | + VLYNQ_CTRL_CLOCK_DIV(dev->divisor - + vlynq_rdiv1)); + if (vlynq_linked(dev)) { + printk(KERN_DEBUG + "%s: using remote clock divisor %d\n", + dev->dev.bus_id, dev->divisor - vlynq_rdiv1 + 1); + return 0; + } + break; + case vlynq_div_external: + vlynq_reg_write(dev->local->control, 0); + vlynq_reg_write(dev->remote->control, 0); + if (vlynq_linked(dev)) { + printk(KERN_DEBUG "%s: using external clock\n", + dev->dev.bus_id); + return 0; + } + break; + } + + ops->off(dev); + return -ENODEV; +} + +int vlynq_enable_device(struct vlynq_device *dev) +{ + struct plat_vlynq_ops *ops = dev->dev.platform_data; + int result = -ENODEV; + + result = __vlynq_enable_device(dev); + if (result) + return result; + + result = vlynq_setup_irq(dev); + if (result) + ops->off(dev); + + dev->enabled = !result; + return result; +} +EXPORT_SYMBOL(vlynq_enable_device); + + +void vlynq_disable_device(struct vlynq_device *dev) +{ + struct plat_vlynq_ops *ops = dev->dev.platform_data; + + dev->enabled = 0; + free_irq(dev->irq, dev); + ops->off(dev); +} +EXPORT_SYMBOL(vlynq_disable_device); + +int vlynq_set_local_mapping(struct vlynq_device *dev, u32 tx_offset, + struct vlynq_mapping *mapping) +{ + int i; + + if (!dev->enabled) + return -ENXIO; + + vlynq_reg_write(dev->local->tx_offset, tx_offset); + for (i = 0; i < 4; i++) { + vlynq_reg_write(dev->local->rx_mapping[i].offset, + mapping[i].offset); + vlynq_reg_write(dev->local->rx_mapping[i].size, + mapping[i].size); + } + return 0; +} +EXPORT_SYMBOL(vlynq_set_local_mapping); + +int vlynq_set_remote_mapping(struct vlynq_device *dev, u32 tx_offset, + struct vlynq_mapping *mapping) +{ + int i; + + if (!dev->enabled) + return -ENXIO; + + vlynq_reg_write(dev->remote->tx_offset, tx_offset); + for (i = 0; i < 4; i++) { + vlynq_reg_write(dev->remote->rx_mapping[i].offset, + mapping[i].offset); + vlynq_reg_write(dev->remote->rx_mapping[i].size, + mapping[i].size); + } + return 0; +} +EXPORT_SYMBOL(vlynq_set_remote_mapping); + +int vlynq_set_local_irq(struct vlynq_device *dev, int virq) +{ + int irq = dev->irq_start + virq; + if (dev->enabled) + return -EBUSY; + + if ((irq < dev->irq_start) || (irq > dev->irq_end)) + return -EINVAL; + + if (virq == dev->remote_irq) + return -EINVAL; + + dev->local_irq = virq; + + return 0; +} +EXPORT_SYMBOL(vlynq_set_local_irq); + +int vlynq_set_remote_irq(struct vlynq_device *dev, int virq) +{ + int irq = dev->irq_start + virq; + if (dev->enabled) + return -EBUSY; + + if ((irq < dev->irq_start) || (irq > dev->irq_end)) + return -EINVAL; + + if (virq == dev->local_irq) + return -EINVAL; + + dev->remote_irq = virq; + + return 0; +} +EXPORT_SYMBOL(vlynq_set_remote_irq); + +static int vlynq_probe(struct platform_device *pdev) +{ + struct vlynq_device *dev; + struct resource *regs_res, *mem_res, *irq_res; + int len, result; + + regs_res = platform_get_resource_byname(pdev, IORESOURCE_MEM, "regs"); + if (!regs_res) + return -ENODEV; + + mem_res = platform_get_resource_byname(pdev, IORESOURCE_MEM, "mem"); + if (!mem_res) + return -ENODEV; + + irq_res = platform_get_resource_byname(pdev, IORESOURCE_IRQ, "devirq"); + if (!irq_res) + return -ENODEV; + + dev = kzalloc(sizeof(*dev), GFP_KERNEL); + if (!dev) { + printk(KERN_ERR + "vlynq: failed to allocate device structure\n"); + return -ENOMEM; + } + + dev->id = pdev->id; + dev->dev.bus = &vlynq_bus_type; + dev->dev.parent = &pdev->dev; + snprintf(dev->dev.bus_id, BUS_ID_SIZE, "vlynq%d", dev->id); + dev->dev.bus_id[BUS_ID_SIZE - 1] = 0; + dev->dev.platform_data = pdev->dev.platform_data; + dev->dev.release = vlynq_device_release; + + dev->regs_start = regs_res->start; + dev->regs_end = regs_res->end; + dev->mem_start = mem_res->start; + dev->mem_end = mem_res->end; + + len = regs_res->end - regs_res->start; + if (!request_mem_region(regs_res->start, len, dev->dev.bus_id)) { + printk(KERN_ERR "%s: Can't request vlynq registers\n", + dev->dev.bus_id); + result = -ENXIO; + goto fail_request; + } + + dev->local = ioremap(regs_res->start, len); + if (!dev->local) { + printk(KERN_ERR "%s: Can't remap vlynq registers\n", + dev->dev.bus_id); + result = -ENXIO; + goto fail_remap; + } + + dev->remote = (struct vlynq_regs *)((void *)dev->local + + VLYNQ_REMOTE_OFFSET); + + dev->irq = platform_get_irq_byname(pdev, "irq"); + dev->irq_start = irq_res->start; + dev->irq_end = irq_res->end; + dev->local_irq = dev->irq_end - dev->irq_start; + dev->remote_irq = dev->local_irq - 1; + + if (device_register(&dev->dev)) + goto fail_register; + platform_set_drvdata(pdev, dev); + + printk(KERN_INFO "%s: regs 0x%p, irq %d, mem 0x%p\n", + dev->dev.bus_id, (void *)dev->regs_start, dev->irq, + (void *)dev->mem_start); + + return 0; + +fail_register: + iounmap(dev->local); +fail_remap: +fail_request: + release_mem_region(regs_res->start, len); + kfree(dev); + return result; +} + +static int vlynq_remove(struct platform_device *pdev) +{ + struct vlynq_device *dev = platform_get_drvdata(pdev); + + device_unregister(&dev->dev); + iounmap(dev->local); + release_mem_region(dev->regs_start, dev->regs_end - dev->regs_start); + + kfree(dev); + + return 0; +} + +static struct platform_driver vlynq_driver = { + .driver.name = "vlynq", + .probe = vlynq_probe, + .remove = __devexit_p(vlynq_remove), +}; + +struct bus_type vlynq_bus_type = { + .name = "vlynq", + .match = vlynq_device_match, + .probe = vlynq_device_probe, + .remove = vlynq_device_remove, +}; +EXPORT_SYMBOL(vlynq_bus_type); + +static int __devinit vlynq_init(void) +{ + int res = 0; + + res = bus_register(&vlynq_bus_type); + if (res) + goto fail_bus; + + res = platform_driver_register(&vlynq_driver); + if (res) + goto fail_platform; + + return 0; + +fail_platform: + bus_unregister(&vlynq_bus_type); +fail_bus: + return res; +} + +static void __devexit vlynq_exit(void) +{ + platform_driver_unregister(&vlynq_driver); + bus_unregister(&vlynq_bus_type); +} + +module_init(vlynq_init); +module_exit(vlynq_exit); diff --git a/include/linux/vlynq.h b/include/linux/vlynq.h new file mode 100644 index 0000000..b3f2474 --- /dev/null +++ b/include/linux/vlynq.h @@ -0,0 +1,161 @@ +/* + * Copyright (C) 2006, 2007 OpenWrt.org + * + * 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., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA + */ + +#ifndef __VLYNQ_H__ +#define __VLYNQ_H__ + +#include +#include +#include + +#define VLYNQ_NUM_IRQS 32 + +struct vlynq_mapping { + u32 size; + u32 offset; +}; + +enum vlynq_divisor { + vlynq_div_auto = 0, + vlynq_ldiv1, + vlynq_ldiv2, + vlynq_ldiv3, + vlynq_ldiv4, + vlynq_ldiv5, + vlynq_ldiv6, + vlynq_ldiv7, + vlynq_ldiv8, + vlynq_rdiv1, + vlynq_rdiv2, + vlynq_rdiv3, + vlynq_rdiv4, + vlynq_rdiv5, + vlynq_rdiv6, + vlynq_rdiv7, + vlynq_rdiv8, + vlynq_div_external +}; + +struct vlynq_device_id { + u32 id; + enum vlynq_divisor divisor; + unsigned long driver_data; +}; + +struct vlynq_regs; +struct vlynq_device { + u32 id; + int local_irq; + int remote_irq; + enum vlynq_divisor divisor; + u32 regs_start, regs_end; + u32 mem_start, mem_end; + u32 irq_start, irq_end; + int irq; + int enabled; + struct vlynq_regs *local; + struct vlynq_regs *remote; + struct device dev; +}; + +struct vlynq_driver { + char *name; + struct vlynq_device_id *id_table; + int (*probe)(struct vlynq_device *dev, struct vlynq_device_id *id); + void (*remove)(struct vlynq_device *dev); + struct device_driver driver; +}; + +struct plat_vlynq_ops { + int (*on)(struct vlynq_device *dev); + void (*off)(struct vlynq_device *dev); +}; + +static inline struct vlynq_driver *to_vlynq_driver(struct device_driver *drv) +{ + return container_of(drv, struct vlynq_driver, driver); +} + +static inline struct vlynq_device *to_vlynq_device(struct device *device) +{ + return container_of(device, struct vlynq_device, dev); +} + +extern struct bus_type vlynq_bus_type; + +extern int __vlynq_register_driver(struct vlynq_driver *driver, + struct module *owner); + +static inline int vlynq_register_driver(struct vlynq_driver *driver) +{ + return __vlynq_register_driver(driver, THIS_MODULE); +} + +static inline void *vlynq_get_drvdata(struct vlynq_device *dev) +{ + return dev_get_drvdata(&dev->dev); +} + +static inline void vlynq_set_drvdata(struct vlynq_device *dev, void *data) +{ + dev_set_drvdata(&dev->dev, data); +} + +static inline u32 vlynq_mem_start(struct vlynq_device *dev) +{ + return dev->mem_start; +} + +static inline u32 vlynq_mem_end(struct vlynq_device *dev) +{ + return dev->mem_end; +} + +static inline u32 vlynq_mem_len(struct vlynq_device *dev) +{ + return dev->mem_end - dev->mem_start + 1; +} + +static inline int vlynq_virq_to_irq(struct vlynq_device *dev, int virq) +{ + int irq = dev->irq_start + virq; + if ((irq < dev->irq_start) || (irq > dev->irq_end)) + return -EINVAL; + + return irq; +} + +static inline int vlynq_irq_to_virq(struct vlynq_device *dev, int irq) +{ + if ((irq < dev->irq_start) || (irq > dev->irq_end)) + return -EINVAL; + + return irq - dev->irq_start; +} + +extern void vlynq_unregister_driver(struct vlynq_driver *driver); +extern int vlynq_enable_device(struct vlynq_device *dev); +extern void vlynq_disable_device(struct vlynq_device *dev); +extern int vlynq_set_local_mapping(struct vlynq_device *dev, u32 tx_offset, + struct vlynq_mapping *mapping); +extern int vlynq_set_remote_mapping(struct vlynq_device *dev, u32 tx_offset, + struct vlynq_mapping *mapping); +extern int vlynq_set_local_irq(struct vlynq_device *dev, int virq); +extern int vlynq_set_remote_irq(struct vlynq_device *dev, int virq); + +#endif /* __VLYNQ_H__ */ From technoboy85@gmail.com Thu Oct 11 01:56:16 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 11 Oct 2007 01:56:26 +0100 (BST) Received: from wx-out-0506.google.com ([66.249.82.234]:29005 "EHLO wx-out-0506.google.com") by ftp.linux-mips.org with ESMTP id S20021451AbXJKA4Q (ORCPT ); Thu, 11 Oct 2007 01:56:16 +0100 Received: by wx-out-0506.google.com with SMTP id h30so379802wxd for ; Wed, 10 Oct 2007 17:55:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:from:to:subject:date:user-agent:references:in-reply-to:cc:mime-version:content-type:content-transfer-encoding:content-disposition:message-id; bh=tsFtNtWhb89WEXQM3iaOOHp2vmJU1wIum+gtmEEa35M=; b=WqE6947X5duM8iIsXshNbKpVr/Euf4XpDIG4epS9Pum6mR0/LigB53H2Xz6nnSRxKK8GJz7nfeIqmn3WpvGPpFKEZaoJCo7dcR0zLlko0sddqj6FWC8Khifk21LiCW5fjnH7/3/1upbY9BHD5nFdlRdeXUuGQaE40UMj4Ln3fo8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:from:to:subject:date:user-agent:references:in-reply-to:cc:mime-version:content-type:content-transfer-encoding:content-disposition:message-id; b=ot8Il3cNF40WP/k08SB6anXJXONi+SuVOYdhrrhncNqcIqwbNC2BPET7bTktkjx35pabVo/zsAsOYf57U5Us3sKninEyGAj92rSQ0eEjMrHdW9eoAJX2lB0cQQNuR4f4C6UmMnUl5sh1k7PCj3bVE6kFXJXZKTeJrgIu541au80= Received: by 10.70.17.16 with SMTP id 16mr2139347wxq.1192064158517; Wed, 10 Oct 2007 17:55:58 -0700 (PDT) Received: from ?192.168.0.3? ( [87.18.114.61]) by mx.google.com with ESMTPS id h7sm1789268wxd.2007.10.10.17.55.55 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 10 Oct 2007 17:55:57 -0700 (PDT) From: Matteo Croce To: linux-mips@linux-mips.org Subject: [PATCH][MIPS][3/6] AR7: mtd partition map Date: Thu, 11 Oct 2007 02:55:55 +0200 User-Agent: KMail/1.9.6 (enterprise 0.20070907.709405) References: <200710110248.33028.technoboy85@gmail.com> In-Reply-To: <200710110248.33028.technoboy85@gmail.com> Cc: Felix Fietkau , Eugene Konev , dwmw2@infradead.org, linux-mtd@lists.infradead.org, Andrew Morton MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200710110255.55917.technoboy85@gmail.com> Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 16950 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: technoboy85@gmail.com Precedence: bulk X-list: linux-mips Signed-off-by: Matteo Croce Signed-off-by: Felix Fietkau Signed-off-by: Eugene Konev diff --git a/drivers/mtd/Kconfig b/drivers/mtd/Kconfig index fbec8cd..c1b2508 100644 --- a/drivers/mtd/Kconfig +++ b/drivers/mtd/Kconfig @@ -150,6 +150,12 @@ config MTD_AFS_PARTS for your particular device. It won't happen automatically. The 'armflash' map driver (CONFIG_MTD_ARMFLASH) does this, for example. +config MTD_AR7_PARTS + tristate "TI AR7 partitioning support" + depends on MTD_PARTITIONS + ---help--- + TI AR7 partitioning support + comment "User Modules And Translation Layers" config MTD_CHAR diff --git a/drivers/mtd/Makefile b/drivers/mtd/Makefile index 6d958a4..8451c64 100644 --- a/drivers/mtd/Makefile +++ b/drivers/mtd/Makefile @@ -11,6 +11,7 @@ obj-$(CONFIG_MTD_CONCAT) += mtdconcat.o obj-$(CONFIG_MTD_REDBOOT_PARTS) += redboot.o obj-$(CONFIG_MTD_CMDLINE_PARTS) += cmdlinepart.o obj-$(CONFIG_MTD_AFS_PARTS) += afs.o +obj-$(CONFIG_MTD_AR7_PARTS) += ar7part.o # 'Users' - code which presents functionality to userspace. obj-$(CONFIG_MTD_CHAR) += mtdchar.o diff --git a/drivers/mtd/ar7part.c b/drivers/mtd/ar7part.c new file mode 100644 index 0000000..3d160d4 --- /dev/null +++ b/drivers/mtd/ar7part.c @@ -0,0 +1,146 @@ +/* + * Copyright (C) 2007 Eugene Konev + * + * 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., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA + * + * TI AR7 flash partition table. + * Based on ar7 map by Felix Fietkau + * + */ + +#include +#include + +#include +#include +#include +#include + +#define AR7_PARTS 4 +#define ROOT_OFFSET 0xe0000 + +#define LOADER_MAGIC1 le32_to_cpu(0xfeedfa42) +#define LOADER_MAGIC2 le32_to_cpu(0xfeed1281) + +struct ar7_bin_rec { + unsigned int checksum; + unsigned int length; + unsigned int address; +}; + +static struct mtd_partition ar7_parts[AR7_PARTS]; + +static int create_mtd_partitions(struct mtd_info *master, + struct mtd_partition **pparts, + unsigned long origin) +{ + struct ar7_bin_rec header; + unsigned int offset, len; + unsigned int pre_size = master->erasesize, post_size = 0; + unsigned int root_offset = ROOT_OFFSET; + + int retries = 10; + + ar7_parts[0].name = "loader"; + ar7_parts[0].offset = 0; + ar7_parts[0].size = master->erasesize; + ar7_parts[0].mask_flags = MTD_WRITEABLE; + + ar7_parts[1].name = "config"; + ar7_parts[1].offset = 0; + ar7_parts[1].size = master->erasesize; + ar7_parts[1].mask_flags = 0; + + do { /* Try 10 blocks starting from master->erasesize */ + offset = pre_size; + master->read(master, offset, + sizeof(header), &len, (u8 *)&header); + if (!strncmp((char *)&header, "TIENV0.8", 8)) + ar7_parts[1].offset = pre_size; + if (header.checksum == LOADER_MAGIC1) + break; + if (header.checksum == LOADER_MAGIC2) + break; + pre_size += master->erasesize; + } while (retries--); + + pre_size = offset; + + if (!ar7_parts[1].offset) { + ar7_parts[1].offset = master->size - master->erasesize; + post_size = master->erasesize; + } + + switch (header.checksum) { + case LOADER_MAGIC1: + while (header.length) { + offset += sizeof(header) + header.length; + master->read(master, offset, sizeof(header), + &len, (u8 *)&header); + } + root_offset = offset + sizeof(header) + 4; + break; + case LOADER_MAGIC2: + while (header.length) { + offset += sizeof(header) + header.length; + master->read(master, offset, sizeof(header), + &len, (u8 *)&header); + } + root_offset = offset + sizeof(header) + 4 + 0xff; + root_offset &= ~(u32)0xff; + break; + default: + printk(KERN_WARNING "Unknown magic: %08x\n", header.checksum); + break; + } + + master->read(master, root_offset, + sizeof(header), &len, (u8 *)&header); + if (header.checksum != SQUASHFS_MAGIC) { + root_offset += master->erasesize - 1; + root_offset &= ~(master->erasesize - 1); + } + + ar7_parts[2].name = "linux"; + ar7_parts[2].offset = pre_size; + ar7_parts[2].size = master->size - pre_size - post_size; + ar7_parts[2].mask_flags = 0; + + ar7_parts[3].name = "rootfs"; + ar7_parts[3].offset = root_offset; + ar7_parts[3].size = master->size - root_offset - post_size; + ar7_parts[3].mask_flags = 0; + + *pparts = ar7_parts; + return AR7_PARTS; +} + +static struct mtd_part_parser ar7_parser = { + .owner = THIS_MODULE, + .parse_fn = create_mtd_partitions, + .name = "ar7part", +}; + +static int __init ar7_parser_init(void) +{ + return register_mtd_parser(&ar7_parser); +} + +module_init(ar7_parser_init); + +MODULE_LICENSE("GPL"); +MODULE_AUTHOR( "Felix Fietkau , " + "Eugene Konev "); +MODULE_DESCRIPTION("MTD partitioning for TI AR7"); From technoboy85@gmail.com Thu Oct 11 01:57:26 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 11 Oct 2007 01:57:34 +0100 (BST) Received: from wx-out-0506.google.com ([66.249.82.230]:53071 "EHLO wx-out-0506.google.com") by ftp.linux-mips.org with ESMTP id S20021451AbXJKA5Z (ORCPT ); Thu, 11 Oct 2007 01:57:25 +0100 Received: by wx-out-0506.google.com with SMTP id h30so380128wxd for ; Wed, 10 Oct 2007 17:57:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:from:to:subject:date:user-agent:references:in-reply-to:cc:mime-version:content-type:content-transfer-encoding:content-disposition:message-id; bh=Llj4yJz+loDgyPdyPq7hGB7tGbm7Rvu1ZAk8lLAR7k8=; b=bQfWQhDma/BDlJLTYgncKSkep+LADK7pzPifRMgOcVLlj16ubBCR7P/w35kC2t+kaZXmcCR08+vKELuth12X2FLpnNEwNn8qZXHeoa8QCmoM7urUy1yP/96BHV4sxc4Ie2vGcC22EHYZ9GB+UA2Xh8QbXIcDlO2t1HsW9q7oBoI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:from:to:subject:date:user-agent:references:in-reply-to:cc:mime-version:content-type:content-transfer-encoding:content-disposition:message-id; b=bl8E29MtB3DHXUh2beJzOdKtlF2wXdJfmRqnQCBme2fX0xVKlYlspFeJL2czBHxt5VgaX6SlwVGXTFCMODeVpWKNc28rKQbkRU40uksR0VvlnxFUDzqs1yFaWXETCLCOsrFoq3vVU4FXMzbfBkOydsYWYLVHqn8B0dm8C7DnTPg= Received: by 10.70.31.8 with SMTP id e8mr2178139wxe.1192064244447; Wed, 10 Oct 2007 17:57:24 -0700 (PDT) Received: from ?192.168.0.3? ( [87.18.114.61]) by mx.google.com with ESMTPS id h8sm1814538wxd.2007.10.10.17.57.22 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 10 Oct 2007 17:57:23 -0700 (PDT) From: Matteo Croce To: linux-mips@linux-mips.org Subject: [PATCH][MIPS][4/6] AR7: gpio char device Date: Thu, 11 Oct 2007 02:57:22 +0200 User-Agent: KMail/1.9.6 (enterprise 0.20070907.709405) References: <200710110248.33028.technoboy85@gmail.com> In-Reply-To: <200710110248.33028.technoboy85@gmail.com> Cc: Nicolas Thill , Andrew Morton MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200710110257.22750.technoboy85@gmail.com> Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 16951 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: technoboy85@gmail.com Precedence: bulk X-list: linux-mips Signed-off-by: Matteo Croce Signed-off-by: Nicolas Thill diff --git a/drivers/char/Kconfig b/drivers/char/Kconfig index b391776..b98aedf 100644 --- a/drivers/char/Kconfig +++ b/drivers/char/Kconfig @@ -928,6 +928,15 @@ config MWAVE To compile this driver as a module, choose M here: the module will be called mwave. +config AR7_GPIO + tristate "TI AR7 GPIO Support" + depends on AR7 + help + Give userspace access to the GPIO pins on the Texas Instruments AR7 + processors. + + If compiled as a module, it will be called ar7_gpio. + config SCx200_GPIO tristate "NatSemi SCx200 GPIO Support" depends on SCx200 diff --git a/drivers/char/Makefile b/drivers/char/Makefile index c78ff26..3d7c2af 100644 --- a/drivers/char/Makefile +++ b/drivers/char/Makefile @@ -89,6 +89,7 @@ obj-$(CONFIG_COBALT_LCD) += lcd.o obj-$(CONFIG_PPDEV) += ppdev.o obj-$(CONFIG_NWBUTTON) += nwbutton.o obj-$(CONFIG_NWFLASH) += nwflash.o +obj-$(CONFIG_AR7_GPIO) += ar7_gpio.o obj-$(CONFIG_SCx200_GPIO) += scx200_gpio.o obj-$(CONFIG_PC8736x_GPIO) += pc8736x_gpio.o obj-$(CONFIG_NSC_GPIO) += nsc_gpio.o diff --git a/drivers/char/ar7_gpio.c b/drivers/char/ar7_gpio.c new file mode 100644 index 0000000..16460cd --- /dev/null +++ b/drivers/char/ar7_gpio.c @@ -0,0 +1,158 @@ +/* + * Copyright (C) 2007 Nicolas Thill + * + * 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., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA + */ + +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include + +#define DRVNAME "ar7_gpio" +#define LONGNAME "TI AR7 GPIOs Driver" + +MODULE_AUTHOR("Nicolas Thill "); +MODULE_DESCRIPTION(LONGNAME); +MODULE_LICENSE("GPL"); + +static int ar7_gpio_major; + +static ssize_t ar7_gpio_write(struct file *file, const char __user *buf, + size_t len, loff_t *ppos) +{ + int pin = iminor(file->f_dentry->d_inode); + size_t i; + + for (i = 0; i < len; ++i) { + char c; + if (get_user(c, buf + i)) + return -EFAULT; + switch (c) { + case '0': + gpio_set_value(pin, 0); + break; + case '1': + gpio_set_value(pin, 1); + break; + case 'd': + case 'D': + ar7_gpio_disable(pin); + break; + case 'e': + case 'E': + ar7_gpio_enable(pin); + break; + case 'i': + case 'I': + case '<': + gpio_direction_input(pin); + break; + case 'o': + case 'O': + case '>': + gpio_direction_output(pin, 0); + break; + default: + return -EINVAL; + } + } + + return len; +} + +static ssize_t ar7_gpio_read(struct file *file, char __user *buf, + size_t len, loff_t *ppos) +{ + int pin = iminor(file->f_dentry->d_inode); + int value; + + value = gpio_get_value(pin); + if (put_user(value ? '1' : '0', buf)) + return -EFAULT; + + return 1; +} + +static int ar7_gpio_open(struct inode *inode, struct file *file) +{ + int m = iminor(inode); + + if (m >= AR7_GPIO_MAX) + return -EINVAL; + + return nonseekable_open(inode, file); +} + +static int ar7_gpio_release(struct inode *inode, struct file *file) +{ + return 0; +} + +static const struct file_operations ar7_gpio_fops = { + .owner = THIS_MODULE, + .write = ar7_gpio_write, + .read = ar7_gpio_read, + .open = ar7_gpio_open, + .release = ar7_gpio_release, + .llseek = no_llseek, +}; + +static struct platform_device *ar7_gpio_device; + +static int __init ar7_gpio_init(void) +{ + int rc; + + ar7_gpio_device = platform_device_alloc(DRVNAME, -1); + if (!ar7_gpio_device) + return -ENOMEM; + + rc = platform_device_add(ar7_gpio_device); + if (rc < 0) + goto out_put; + + rc = register_chrdev(ar7_gpio_major, DRVNAME, &ar7_gpio_fops); + if (rc < 0) + goto out_put; + + ar7_gpio_major = rc; + + rc = 0; + + goto out; + +out_put: + platform_device_put(ar7_gpio_device); +out: + return rc; +} + +static void __exit ar7_gpio_exit(void) +{ + unregister_chrdev(ar7_gpio_major, DRVNAME); + platform_device_unregister(ar7_gpio_device); +} + +module_init(ar7_gpio_init); +module_exit(ar7_gpio_exit); From technoboy85@gmail.com Thu Oct 11 01:57:54 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 11 Oct 2007 01:58:07 +0100 (BST) Received: from wx-out-0506.google.com ([66.249.82.225]:61260 "EHLO wx-out-0506.google.com") by ftp.linux-mips.org with ESMTP id S20021460AbXJKA5c (ORCPT ); Thu, 11 Oct 2007 01:57:32 +0100 Received: by wx-out-0506.google.com with SMTP id h30so380099wxd for ; Wed, 10 Oct 2007 17:57:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:from:to:subject:date:user-agent:references:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:message-id; bh=INqnNW+I2tTRfS31xcVBBbod2ZREtJs24h/ew81FqCQ=; b=ggL7WM71egSBUYWo5C7CKNQzdohf+2mid8pLpoIaDfkfvYpnuljeTMkYND9EYeUA46KtqJ5dZuJVxOkhX0lTzvopcKTmRH8rKZADgL5WlTweMieS9qiCsUsixCsIUxmN57Z3YkocclwBfNgpjEEQB4yTZQThjQo3ak2PferVoJY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:from:to:subject:date:user-agent:references:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:message-id; b=dHRWS8wQ2HVol5ua/n734B5d0MOnbCZsn6uni6D2K2w+s7w2qY+PBPfowEQ2LMfV27Dgr8Zk6Jkb4xkHkubZ5cb25JLrltVkS2QQ1KkcHrY00qIUaqCrjAC5SS21IPw4JqlMt0gv3zZWCxRAU7sLMdbqI3JEKckoa+UiIk28cVs= Received: by 10.70.108.18 with SMTP id g18mr2191689wxc.1192063856903; Wed, 10 Oct 2007 17:50:56 -0700 (PDT) Received: from ?192.168.0.3? ( [87.18.114.61]) by mx.google.com with ESMTPS id h39sm3558862wxd.2007.10.10.17.50.52 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 10 Oct 2007 17:50:55 -0700 (PDT) From: Matteo Croce To: linux-mips@linux-mips.org Subject: [PATCH][MIPS][1/6] AR7: core support Date: Thu, 11 Oct 2007 02:50:53 +0200 User-Agent: KMail/1.9.6 (enterprise 0.20070907.709405) References: <200710110248.33028.technoboy85@gmail.com> In-Reply-To: <200710110248.33028.technoboy85@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200710110250.53553.technoboy85@gmail.com> Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 16952 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: technoboy85@gmail.com Precedence: bulk X-list: linux-mips Signed-off-by: Matteo Croce Signed-off-by: Florian Fainelli Signed-off-by: Felix Fietkau Signed-off-by: Eugene Konev Signed-off-by: Nicolas Thill diff --git a/arch/mips/Kconfig b/arch/mips/Kconfig index f943736..a207a8b 100644 --- a/arch/mips/Kconfig +++ b/arch/mips/Kconfig @@ -16,6 +16,22 @@ choice prompt "System type" default SGI_IP22 +config AR7 + bool "Texas Instruments AR7" + select BOOT_ELF32 + select DMA_NONCOHERENT + select IRQ_CPU + select NO_EXCEPT_FILL + select SWAP_IO_SPACE + select SYS_HAS_CPU_MIPS32_R1 + select SYS_HAS_EARLY_PRINTK + select SYS_SUPPORTS_32BIT_KERNEL + select SYS_SUPPORTS_KGDB + select SYS_SUPPORTS_LITTLE_ENDIAN + select SYS_SUPPORTS_BIG_ENDIAN + select GENERIC_GPIO + select GENERIC_HARDIRQS_NO__DO_IRQ + config MACH_ALCHEMY bool "Alchemy processor based machines" diff --git a/arch/mips/Makefile b/arch/mips/Makefile index ebd5d02..905d06a 100644 --- a/arch/mips/Makefile +++ b/arch/mips/Makefile @@ -157,6 +157,13 @@ libs-$(CONFIG_SIBYTE_CFE) += arch/mips/sibyte/cfe/ # # +# Texas Instruments AR7 +# +core-$(CONFIG_AR7) += arch/mips/ar7/ +cflags-$(CONFIG_AR7) += -Iinclude/asm-mips/ar7 +load-$(CONFIG_AR7) += 0xffffffff94100000 + +# # Acer PICA 61, Mips Magnum 4000 and Olivetti M700. # core-$(CONFIG_MACH_JAZZ) += arch/mips/jazz/ diff --git a/arch/mips/ar7/Makefile b/arch/mips/ar7/Makefile new file mode 100644 index 0000000..7435e44 --- /dev/null +++ b/arch/mips/ar7/Makefile @@ -0,0 +1,10 @@ + +obj-y := \ + prom.o \ + setup.o \ + memory.o \ + irq.o \ + time.o \ + platform.o \ + gpio.o \ + clock.o diff --git a/arch/mips/ar7/clock.c b/arch/mips/ar7/clock.c new file mode 100644 index 0000000..ecbcbf0 --- /dev/null +++ b/arch/mips/ar7/clock.c @@ -0,0 +1,485 @@ +/* + * Copyright (C) 2007 Felix Fietkau, Eugene Konev + * + * 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., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA + */ + +#include +#include +#include +#include +#include +#include +#include + +#define BOOT_PLL_SOURCE_MASK 0x3 +#define CPU_PLL_SOURCE_SHIFT 16 +#define BUS_PLL_SOURCE_SHIFT 14 +#define USB_PLL_SOURCE_SHIFT 18 +#define DSP_PLL_SOURCE_SHIFT 22 +#define BOOT_PLL_SOURCE_AFE 0 +#define BOOT_PLL_SOURCE_BUS 0 +#define BOOT_PLL_SOURCE_REF 1 +#define BOOT_PLL_SOURCE_XTAL 2 +#define BOOT_PLL_SOURCE_CPU 3 +#define BOOT_PLL_BYPASS 0x00000020 +#define BOOT_PLL_ASYNC_MODE 0x02000000 +#define BOOT_PLL_2TO1_MODE 0x00008000 + +#define TNETD7200_CLOCK_ID_CPU 0 +#define TNETD7200_CLOCK_ID_DSP 1 +#define TNETD7200_CLOCK_ID_USB 2 + +#define TNETD7200_DEF_CPU_CLK 211000000 +#define TNETD7200_DEF_DSP_CLK 125000000 +#define TNETD7200_DEF_USB_CLK 48000000 + +struct tnetd7300_clock { + volatile u32 ctrl; +#define PREDIV_MASK 0x001f0000 +#define PREDIV_SHIFT 16 +#define POSTDIV_MASK 0x0000001f + u32 unused1[3]; + volatile u32 pll; +#define MUL_MASK 0x0000f000 +#define MUL_SHIFT 12 +#define PLL_MODE_MASK 0x00000001 +#define PLL_NDIV 0x00000800 +#define PLL_DIV 0x00000002 +#define PLL_STATUS 0x00000001 + u32 unused2[3]; +} __packed; + +struct tnetd7300_clocks { + struct tnetd7300_clock bus; + struct tnetd7300_clock cpu; + struct tnetd7300_clock usb; + struct tnetd7300_clock dsp; +} __packed; + +struct tnetd7200_clock { + volatile u32 ctrl; + u32 unused1[3]; +#define DIVISOR_ENABLE_MASK 0x00008000 + volatile u32 mul; + volatile u32 prediv; + volatile u32 postdiv; + volatile u32 postdiv2; + u32 unused2[6]; + volatile u32 cmd; + volatile u32 status; + volatile u32 cmden; + u32 padding[15]; +} __packed; + +struct tnetd7200_clocks { + struct tnetd7200_clock cpu; + struct tnetd7200_clock dsp; + struct tnetd7200_clock usb; +} __packed; + +int ar7_cpu_clock = 150000000; +EXPORT_SYMBOL(ar7_cpu_clock); +int ar7_bus_clock = 125000000; +EXPORT_SYMBOL(ar7_bus_clock); +int ar7_dsp_clock; +EXPORT_SYMBOL(ar7_dsp_clock); + +static int gcd(int a, int b) +{ + int c; + + if (a < b) { + c = a; + a = b; + b = c; + } + while ((c = (a % b))) { + a = b; + b = c; + } + return b; +} + +static void approximate(int base, int target, int *prediv, + int *postdiv, int *mul) +{ + int i, j, k, freq, res = target; + for (i = 1; i <= 16; i++) + for (j = 1; j <= 32; j++) + for (k = 1; k <= 32; k++) { + freq = abs(base / j * i / k - target); + if (freq < res) { + res = freq; + *mul = i; + *prediv = j; + *postdiv = k; + } + } +} + +static void calculate(int base, int target, int *prediv, int *postdiv, + int *mul) +{ + int tmp_gcd, tmp_base, tmp_freq; + + for (*prediv = 1; *prediv <= 32; (*prediv)++) { + tmp_base = base / *prediv; + tmp_gcd = gcd(target, tmp_base); + *mul = target / tmp_gcd; + *postdiv = tmp_base / tmp_gcd; + if ((*mul < 1) || (*mul >= 16)) + continue; + if ((*postdiv > 0) & (*postdiv <= 32)) + break; + } + + if (base / (*prediv) * (*mul) / (*postdiv) != target) { + approximate(base, target, prediv, postdiv, mul); + tmp_freq = base / (*prediv) * (*mul) / (*postdiv); + printk(KERN_WARNING + "Adjusted requested frequency %d to %d\n", + target, tmp_freq); + } + + printk(KERN_DEBUG "Clocks: prediv: %d, postdiv: %d, mul: %d\n", + *prediv, *postdiv, *mul); +} + +static int tnetd7300_dsp_clock(void) +{ + u32 didr1, didr2; + u8 rev = ar7_chip_rev(); + didr1 = readl((void *)KSEG1ADDR(AR7_REGS_GPIO + 0x18)); + didr2 = readl((void *)KSEG1ADDR(AR7_REGS_GPIO + 0x1c)); + if (didr2 & (1 << 23)) + return 0; + if ((rev >= 0x23) && (rev != 0x57)) + return 250000000; + if ((((didr2 & 0x1fff) << 10) | ((didr1 & 0xffc00000) >> 22)) + > 4208000) + return 250000000; + return 0; +} + +static int tnetd7300_get_clock(u32 shift, struct tnetd7300_clock *clock, + u32 *bootcr, u32 bus_clock) +{ + int product; + int base_clock = AR7_REF_CLOCK; + u32 ctrl = clock->ctrl; + u32 pll = clock->pll; + int prediv = ((ctrl & PREDIV_MASK) >> PREDIV_SHIFT) + 1; + int postdiv = (ctrl & POSTDIV_MASK) + 1; + int divisor = prediv * postdiv; + int mul = ((pll & MUL_MASK) >> MUL_SHIFT) + 1; + + switch ((*bootcr & (BOOT_PLL_SOURCE_MASK << shift)) >> shift) { + case BOOT_PLL_SOURCE_BUS: + base_clock = bus_clock; + break; + case BOOT_PLL_SOURCE_REF: + base_clock = AR7_REF_CLOCK; + break; + case BOOT_PLL_SOURCE_XTAL: + base_clock = AR7_XTAL_CLOCK; + break; + case BOOT_PLL_SOURCE_CPU: + base_clock = ar7_cpu_clock; + break; + } + + if (*bootcr & BOOT_PLL_BYPASS) + return base_clock / divisor; + + if ((pll & PLL_MODE_MASK) == 0) + return (base_clock >> (mul / 16 + 1)) / divisor; + + if ((pll & (PLL_NDIV | PLL_DIV)) == (PLL_NDIV | PLL_DIV)) { + product = (mul & 1) ? + (base_clock * mul) >> 1 : + (base_clock * (mul - 1)) >> 2; + return product / divisor; + } + + if (mul == 16) + return base_clock / divisor; + + return base_clock * mul / divisor; +} + +static void tnetd7300_set_clock(u32 shift, struct tnetd7300_clock *clock, + u32 *bootcr, u32 frequency) +{ + u32 status; + int prediv, postdiv, mul; + int base_clock = ar7_bus_clock; + + switch ((*bootcr & (BOOT_PLL_SOURCE_MASK << shift)) >> shift) { + case BOOT_PLL_SOURCE_BUS: + base_clock = ar7_bus_clock; + break; + case BOOT_PLL_SOURCE_REF: + base_clock = AR7_REF_CLOCK; + break; + case BOOT_PLL_SOURCE_XTAL: + base_clock = AR7_XTAL_CLOCK; + break; + case BOOT_PLL_SOURCE_CPU: + base_clock = ar7_cpu_clock; + break; + } + + calculate(base_clock, frequency, &prediv, &postdiv, &mul); + + clock->ctrl = ((prediv - 1) << PREDIV_SHIFT) | (postdiv - 1); + mdelay(1); + clock->pll = 4; + do + status = clock->pll; + while (status & PLL_STATUS); + clock->pll = ((mul - 1) << MUL_SHIFT) | (0xff << 3) | 0x0e; + mdelay(75); +} + +static void __init tnetd7300_init_clocks(void) +{ + u32 *bootcr = (u32 *)ioremap_nocache(AR7_REGS_DCL, 4); + struct tnetd7300_clocks *clocks = + (struct tnetd7300_clocks *) + ioremap_nocache(AR7_REGS_POWER + 0x20, + sizeof(struct tnetd7300_clocks)); + + ar7_bus_clock = tnetd7300_get_clock(BUS_PLL_SOURCE_SHIFT, + &clocks->bus, bootcr, AR7_AFE_CLOCK); + + if (*bootcr & BOOT_PLL_ASYNC_MODE) + ar7_cpu_clock = tnetd7300_get_clock(CPU_PLL_SOURCE_SHIFT, + &clocks->cpu, bootcr, AR7_AFE_CLOCK); + else + ar7_cpu_clock = ar7_bus_clock; +/* + tnetd7300_set_clock(USB_PLL_SOURCE_SHIFT, &clocks->usb, + bootcr, 48000000); +*/ + if (ar7_dsp_clock == 250000000) + tnetd7300_set_clock(DSP_PLL_SOURCE_SHIFT, &clocks->dsp, + bootcr, ar7_dsp_clock); + + iounmap(clocks); + iounmap(bootcr); +} + +static int tnetd7200_get_clock(int base, struct tnetd7200_clock *clock, + u32 *bootcr, u32 bus_clock) +{ + int divisor = ((clock->prediv & 0x1f) + 1) * + ((clock->postdiv & 0x1f) + 1); + + if (*bootcr & BOOT_PLL_BYPASS) + return base / divisor; + + return base * ((clock->mul & 0xf) + 1) / divisor; +} + + +static void tnetd7200_set_clock(int base, struct tnetd7200_clock *clock, + int prediv, int postdiv, int postdiv2, int mul, u32 frequency) +{ + printk(KERN_INFO + "Clocks: base = %d, frequency = %u, prediv = %d, " + "postdiv = %d, postdiv2 = %d, mul = %d\n", + base, frequency, prediv, postdiv, postdiv2, mul); + + clock->ctrl = 0; + clock->prediv = DIVISOR_ENABLE_MASK | ((prediv - 1) & 0x1F); + clock->mul = ((mul - 1) & 0xF); + + for (mul = 0; mul < 2000; mul++) /* nop */; + + while (clock->status & 0x1) /* nop */; + + clock->postdiv = DIVISOR_ENABLE_MASK | ((postdiv - 1) & 0x1F); + + clock->cmden |= 1; + clock->cmd |= 1; + + while (clock->status & 0x1) /* nop */; + + clock->postdiv2 = DIVISOR_ENABLE_MASK | ((postdiv2 - 1) & 0x1F); + + clock->cmden |= 1; + clock->cmd |= 1; + + while (clock->status & 0x1) /* nop */; + + clock->ctrl |= 1; +} + +static int tnetd7200_get_clock_base(int clock_id, u32 *bootcr) +{ + if (*bootcr & BOOT_PLL_ASYNC_MODE) + /* Async */ + switch (clock_id) { + case TNETD7200_CLOCK_ID_DSP: + return AR7_REF_CLOCK; + default: + return AR7_AFE_CLOCK; + } + else + /* Sync */ + if (*bootcr & BOOT_PLL_2TO1_MODE) + /* 2:1 */ + switch (clock_id) { + case TNETD7200_CLOCK_ID_DSP: + return AR7_REF_CLOCK; + default: + return AR7_AFE_CLOCK; + } + else + /* 1:1 */ + return AR7_REF_CLOCK; +} + + +static void __init tnetd7200_init_clocks(void) +{ + u32 *bootcr = (u32 *)ioremap_nocache(AR7_REGS_DCL, 4); + struct tnetd7200_clocks *clocks = + (struct tnetd7200_clocks *) + ioremap_nocache(AR7_REGS_POWER + 0x80, + sizeof(struct tnetd7200_clocks)); + int cpu_base, cpu_mul, cpu_prediv, cpu_postdiv; + int dsp_base, dsp_mul, dsp_prediv, dsp_postdiv; + int usb_base, usb_mul, usb_prediv, usb_postdiv; + +/* + Log from Fritz!Box 7170 Annex B: + + CPU revision is: 00018448 + Clocks: Async mode + Clocks: Setting DSP clock + Clocks: prediv: 1, postdiv: 1, mul: 5 + Clocks: base = 25000000, frequency = 125000000, prediv = 1, + postdiv = 2, postdiv2 = 1, mul = 10 + Clocks: Setting CPU clock + Adjusted requested frequency 211000000 to 211968000 + Clocks: prediv: 1, postdiv: 1, mul: 6 + Clocks: base = 35328000, frequency = 211968000, prediv = 1, + postdiv = 1, postdiv2 = -1, mul = 6 + Clocks: Setting USB clock + Adjusted requested frequency 48000000 to 48076920 + Clocks: prediv: 13, postdiv: 1, mul: 5 + Clocks: base = 125000000, frequency = 48000000, prediv = 13, + postdiv = 1, postdiv2 = -1, mul = 5 + + DSL didn't work if you didn't set the postdiv 2:1 postdiv2 combination, + driver hung on startup. + Haven't tested this on a synchronous board, + neither do i know what to do with ar7_dsp_clock +*/ + + cpu_base = tnetd7200_get_clock_base(TNETD7200_CLOCK_ID_CPU, bootcr); + dsp_base = tnetd7200_get_clock_base(TNETD7200_CLOCK_ID_DSP, bootcr); + + if (*bootcr & BOOT_PLL_ASYNC_MODE) { + printk(KERN_INFO "Clocks: Async mode\n"); + + printk(KERN_INFO "Clocks: Setting DSP clock\n"); + calculate(dsp_base, TNETD7200_DEF_DSP_CLK, + &dsp_prediv, &dsp_postdiv, &dsp_mul); + ar7_bus_clock = + ((dsp_base / dsp_prediv) * dsp_mul) / dsp_postdiv; + tnetd7200_set_clock(dsp_base, &clocks->dsp, + dsp_prediv, dsp_postdiv * 2, dsp_postdiv, dsp_mul * 2, + ar7_bus_clock); + + printk(KERN_INFO "Clocks: Setting CPU clock\n"); + calculate(cpu_base, TNETD7200_DEF_CPU_CLK, &cpu_prediv, + &cpu_postdiv, &cpu_mul); + ar7_cpu_clock = + ((cpu_base / cpu_prediv) * cpu_mul) / cpu_postdiv; + tnetd7200_set_clock(cpu_base, &clocks->cpu, + cpu_prediv, cpu_postdiv, -1, cpu_mul, + ar7_cpu_clock); + + } else + if (*bootcr & BOOT_PLL_2TO1_MODE) { + printk(KERN_INFO "Clocks: Sync 2:1 mode\n"); + + printk(KERN_INFO "Clocks: Setting CPU clock\n"); + calculate(cpu_base, TNETD7200_DEF_CPU_CLK, &cpu_prediv, + &cpu_postdiv, &cpu_mul); + ar7_cpu_clock = ((cpu_base / cpu_prediv) * cpu_mul) + / cpu_postdiv; + tnetd7200_set_clock(cpu_base, &clocks->cpu, + cpu_prediv, cpu_postdiv, -1, cpu_mul, + ar7_cpu_clock); + + printk(KERN_INFO "Clocks: Setting DSP clock\n"); + calculate(dsp_base, TNETD7200_DEF_DSP_CLK, &dsp_prediv, + &dsp_postdiv, &dsp_mul); + ar7_bus_clock = ar7_cpu_clock / 2; + tnetd7200_set_clock(dsp_base, &clocks->dsp, + dsp_prediv, dsp_postdiv * 2, dsp_postdiv, + dsp_mul * 2, ar7_bus_clock); + } else { + printk(KERN_INFO "Clocks: Sync 1:1 mode\n"); + + printk(KERN_INFO "Clocks: Setting DSP clock\n"); + calculate(dsp_base, TNETD7200_DEF_CPU_CLK, &dsp_prediv, + &dsp_postdiv, &dsp_mul); + ar7_bus_clock = ((dsp_base / dsp_prediv) * dsp_mul) + / dsp_postdiv; + tnetd7200_set_clock(dsp_base, &clocks->dsp, + dsp_prediv, dsp_postdiv * 2, dsp_postdiv, + dsp_mul * 2, ar7_bus_clock); + + ar7_cpu_clock = ar7_bus_clock; + } + + printk(KERN_INFO "Clocks: Setting USB clock\n"); + usb_base = ar7_bus_clock; + calculate(usb_base, TNETD7200_DEF_USB_CLK, &usb_prediv, + &usb_postdiv, &usb_mul); + tnetd7200_set_clock(usb_base, &clocks->usb, + usb_prediv, usb_postdiv, -1, usb_mul, + TNETD7200_DEF_USB_CLK); + + #warning FIXME + ar7_dsp_clock = ar7_cpu_clock; + + iounmap(clocks); + iounmap(bootcr); +} + +void __init ar7_init_clocks(void) +{ + switch (ar7_chip_id()) { + case AR7_CHIP_7100: +#warning FIXME: Check if the new 7200 clock init works for 7100 + tnetd7200_init_clocks(); + break; + case AR7_CHIP_7200: + tnetd7200_init_clocks(); + break; + case AR7_CHIP_7300: + ar7_dsp_clock = tnetd7300_dsp_clock(); + tnetd7300_init_clocks(); + break; + default: + break; + } +} diff --git a/arch/mips/ar7/gpio.c b/arch/mips/ar7/gpio.c new file mode 100644 index 0000000..7ca7dc9 --- /dev/null +++ b/arch/mips/ar7/gpio.c @@ -0,0 +1,48 @@ +/* + * Copyright (C) 2007 Felix Fietkau, Eugene Konev + * + * 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., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA + */ + +#include + +#include + +static const char *ar7_gpio_list[AR7_GPIO_MAX] = { 0, }; + +int gpio_request(unsigned gpio, const char *label) +{ + if (gpio >= AR7_GPIO_MAX) + return -EINVAL; + + if (ar7_gpio_list[gpio]) + return -EBUSY; + + if (label) { + ar7_gpio_list[gpio] = label; + } else { + ar7_gpio_list[gpio] = "busy"; + } + + return 0; +} +EXPORT_SYMBOL(gpio_request); + +void gpio_free(unsigned gpio) +{ + BUG_ON(!ar7_gpio_list[gpio]); + ar7_gpio_list[gpio] = NULL; +} +EXPORT_SYMBOL(gpio_free); diff --git a/arch/mips/ar7/irq.c b/arch/mips/ar7/irq.c new file mode 100644 index 0000000..e9e0b15 --- /dev/null +++ b/arch/mips/ar7/irq.c @@ -0,0 +1,182 @@ +/* + * Copyright (C) 2006, 2007 Felix Fietkau, Eugene Konev + * + * 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., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA + */ + +#include +#include + +#include +#include +#include + +#define EXCEPT_OFFSET 0x80 +#define PACE_OFFSET 0xA0 +#define CHNLS_OFFSET 0x200 + +#define REG_OFFSET(irq, reg) ((irq) / 32 * 0x4 + reg * 0x10) +#define SEC_REG_OFFSET(reg) (EXCEPT_OFFSET + reg * 0x8) +#define SEC_SR_OFFSET (SEC_REG_OFFSET(0)) /* 0x80 */ +#define CR_OFFSET(irq) (REG_OFFSET(irq, 1)) /* 0x10 */ +#define SEC_CR_OFFSET (SEC_REG_OFFSET(1)) /* 0x88 */ +#define ESR_OFFSET(irq) (REG_OFFSET(irq, 2)) /* 0x20 */ +#define SEC_ESR_OFFSET (SEC_REG_OFFSET(2)) /* 0x90 */ +#define ECR_OFFSET(irq) (REG_OFFSET(irq, 3)) /* 0x30 */ +#define SEC_ECR_OFFSET (SEC_REG_OFFSET(3)) /* 0x98 */ +#define PIR_OFFSET (0x40) +#define MSR_OFFSET (0x44) +#define PM_OFFSET(irq) (REG_OFFSET(irq, 5)) /* 0x50 */ +#define TM_OFFSET(irq) (REG_OFFSET(irq, 6)) /* 0x60 */ + +#define REG(addr) ((u32 *)(KSEG1ADDR(AR7_REGS_IRQ) + addr)) + +#define CHNL_OFFSET(chnl) (CHNLS_OFFSET + (chnl * 4)) + +static void ar7_unmask_irq(unsigned int irq_nr); +static void ar7_mask_irq(unsigned int irq_nr); +static void ar7_ack_irq(unsigned int irq_nr); +static void ar7_unmask_sec_irq(unsigned int irq_nr); +static void ar7_mask_sec_irq(unsigned int irq_nr); +static void ar7_ack_sec_irq(unsigned int irq_nr); +static void ar7_cascade(void); +static void ar7_irq_init(int base); +static int ar7_irq_base; + +static struct irq_chip ar7_irq_type = { + .name = "AR7", + .unmask = ar7_unmask_irq, + .mask = ar7_mask_irq, + .ack = ar7_ack_irq +}; + +static struct irq_chip ar7_sec_irq_type = { + .name = "AR7", + .unmask = ar7_unmask_sec_irq, + .mask = ar7_mask_sec_irq, + .ack = ar7_ack_sec_irq, +}; + +static struct irqaction ar7_cascade_action = { + .handler = no_action, + .name = "AR7 cascade interrupt" +}; + +static void ar7_unmask_irq(unsigned int irq) +{ + writel(1 << ((irq - ar7_irq_base) % 32), + REG(ESR_OFFSET(irq - ar7_irq_base))); +} + +static void ar7_mask_irq(unsigned int irq) +{ + writel(1 << ((irq - ar7_irq_base) % 32), + REG(ECR_OFFSET(irq - ar7_irq_base))); +} + +static void ar7_ack_irq(unsigned int irq) +{ + writel(1 << ((irq - ar7_irq_base) % 32), + REG(CR_OFFSET(irq - ar7_irq_base))); +} + +static void ar7_unmask_sec_irq(unsigned int irq) +{ + writel(1 << (irq - ar7_irq_base - 40), REG(SEC_ESR_OFFSET)); +} + +static void ar7_mask_sec_irq(unsigned int irq) +{ + writel(1 << (irq - ar7_irq_base - 40), REG(SEC_ECR_OFFSET)); +} + +static void ar7_ack_sec_irq(unsigned int irq) +{ + writel(1 << (irq - ar7_irq_base - 40), REG(SEC_CR_OFFSET)); +} + +void __init arch_init_irq(void) { + mips_cpu_irq_init(); + ar7_irq_init(8); +} + +static void __init ar7_irq_init(int base) +{ + int i; + /* + * Disable interrupts and clear pending + */ + writel(0xffffffff, REG(ECR_OFFSET(0))); + writel(0xff, REG(ECR_OFFSET(32))); + writel(0xffffffff, REG(SEC_ECR_OFFSET)); + writel(0xffffffff, REG(CR_OFFSET(0))); + writel(0xff, REG(CR_OFFSET(32))); + writel(0xffffffff, REG(SEC_CR_OFFSET)); + + ar7_irq_base = base; + + for (i = 0; i < 40; i++) { + writel(i, REG(CHNL_OFFSET(i))); + /* Primary IRQ's */ + set_irq_chip_and_handler(base + i, &ar7_irq_type, + handle_level_irq); + /* Secondary IRQ's */ + if (i < 32) + set_irq_chip_and_handler(base + i + 40, + &ar7_sec_irq_type, + handle_level_irq); + } + + setup_irq(2, &ar7_cascade_action); + setup_irq(ar7_irq_base, &ar7_cascade_action); + set_c0_status(IE_IRQ0); +} + +static void ar7_cascade(void) +{ + u32 status; + int i, irq; + + /* Primary IRQ's */ + irq = readl(REG(PIR_OFFSET)) & 0x3f; + if (irq) { + do_IRQ(ar7_irq_base + irq); + return; + } + + /* Secondary IRQ's are cascaded through primary '0' */ + writel(1, REG(CR_OFFSET(irq))); + status = readl(REG(SEC_SR_OFFSET)); + for (i = 0; i < 32; i++) { + if (status & 1) { + do_IRQ(ar7_irq_base + i + 40); + return; + } + status >>= 1; + } + + spurious_interrupt(); +} + +asmlinkage void plat_irq_dispatch(void) +{ + unsigned int pending = read_c0_status() & read_c0_cause() & ST0_IM; + if (pending & STATUSF_IP7) /* cpu timer */ + do_IRQ(7); + else if (pending & STATUSF_IP2) /* int0 hardware line */ + ar7_cascade(); + else + spurious_interrupt(); +} diff --git a/arch/mips/ar7/memory.c b/arch/mips/ar7/memory.c new file mode 100644 index 0000000..65a094c --- /dev/null +++ b/arch/mips/ar7/memory.c @@ -0,0 +1,73 @@ +/* + * Copyright (C) 2007 OpenWrt.org + * + * Based on arch/mips/mm/init.c + * Copyright (C) 1994 - 2000 Ralf Baechle + * Copyright (C) 1999, 2000 Silicon Graphics, Inc. + * Kevin D. Kissell, kevink@mips.com and Carsten Langgaard, carstenl@mips.com + * Copyright (C) 2000 MIPS Technologies, Inc. All rights reserved. + * + * 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., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA + */ +#include +#include +#include +#include +#include +#include +#include +#include + +#include +#include +#include + +#include + +static int __init memsize(void) +{ + u32 size = (64 << 20); + volatile u32 *addr = (u32 *)KSEG1ADDR(0x14000000 + size - 4); + u32 *kernel_end = (u32 *)KSEG1ADDR(CPHYSADDR((u32)&_end)); + + while (addr > kernel_end) { + *addr = (u32)addr; + size >>= 1; + addr -= size >> 2; + } + + do { + addr += size >> 2; + if (*addr != (u32)addr) + break; + size <<= 1; + } while (size < (64 << 20)); + + return size; +} + +void __init prom_meminit(void) +{ + unsigned long pages; + + pages = memsize() >> PAGE_SHIFT; + add_memory_region(PHYS_OFFSET, pages << PAGE_SHIFT, + BOOT_MEM_RAM); +} + +void __init prom_free_prom_memory(void) +{ + return; +} diff --git a/arch/mips/ar7/platform.c b/arch/mips/ar7/platform.c new file mode 100644 index 0000000..5b345a5 --- /dev/null +++ b/arch/mips/ar7/platform.c @@ -0,0 +1,494 @@ +/* + * Copyright (C) 2006, 2007 Felix Fietkau, Eugene Konev + * + * 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., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA + */ + +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#if LINUX_VERSION_CODE >= KERNEL_VERSION(2,6,23) +#include +#endif + +#include +#include +#include +#include + +struct plat_vlynq_data { + struct plat_vlynq_ops ops; + int gpio_bit; + int reset_bit; +}; + + +static int vlynq_on(struct vlynq_device *dev) +{ + int result; + struct plat_vlynq_data *pdata = dev->dev.platform_data; + + if ((result = gpio_request(pdata->gpio_bit, "vlynq"))) + goto out; + + ar7_device_reset(pdata->reset_bit); + + if ((result = ar7_gpio_disable(pdata->gpio_bit))) + goto out_enabled; + + if ((result = ar7_gpio_enable(pdata->gpio_bit))) + goto out_enabled; + + if ((result = gpio_direction_output(pdata->gpio_bit, 0))) + goto out_gpio_enabled; + + mdelay(50); + + gpio_set_value(pdata->gpio_bit, 1); + mdelay(50); + + return 0; + +out_gpio_enabled: + ar7_gpio_disable(pdata->gpio_bit); +out_enabled: + ar7_device_disable(pdata->reset_bit); + gpio_free(pdata->gpio_bit); +out: + return result; +} + +static void vlynq_off(struct vlynq_device *dev) +{ + struct plat_vlynq_data *pdata = dev->dev.platform_data; + ar7_gpio_disable(pdata->gpio_bit); + gpio_free(pdata->gpio_bit); + ar7_device_disable(pdata->reset_bit); +} + +static struct resource physmap_flash_resource = { + .name = "mem", + .flags = IORESOURCE_MEM, + .start = 0x10000000, + .end = 0x107fffff, +}; + +static struct resource cpmac_low_res[] = { + { + .name = "regs", + .flags = IORESOURCE_MEM, + .start = AR7_REGS_MAC0, + .end = AR7_REGS_MAC0 + 0x7ff, + }, + { + .name = "irq", + .flags = IORESOURCE_IRQ, + .start = 27, + .end = 27, + }, +}; + +static struct resource cpmac_high_res[] = { + { + .name = "regs", + .flags = IORESOURCE_MEM, + .start = AR7_REGS_MAC1, + .end = AR7_REGS_MAC1 + 0x7ff, + }, + { + .name = "irq", + .flags = IORESOURCE_IRQ, + .start = 41, + .end = 41, + }, +}; + +static struct resource vlynq_low_res[] = { + { + .name = "regs", + .flags = IORESOURCE_MEM, + .start = AR7_REGS_VLYNQ0, + .end = AR7_REGS_VLYNQ0 + 0xff, + }, + { + .name = "irq", + .flags = IORESOURCE_IRQ, + .start = 29, + .end = 29, + }, + { + .name = "mem", + .flags = IORESOURCE_MEM, + .start = 0x04000000, + .end = 0x04ffffff, + }, + { + .name = "devirq", + .flags = IORESOURCE_IRQ, + .start = 80, + .end = 111, + }, +}; + +static struct resource vlynq_high_res[] = { + { + .name = "regs", + .flags = IORESOURCE_MEM, + .start = AR7_REGS_VLYNQ1, + .end = AR7_REGS_VLYNQ1 + 0xff, + }, + { + .name = "irq", + .flags = IORESOURCE_IRQ, + .start = 33, + .end = 33, + }, + { + .name = "mem", + .flags = IORESOURCE_MEM, + .start = 0x0c000000, + .end = 0x0cffffff, + }, + { + .name = "devirq", + .flags = IORESOURCE_IRQ, + .start = 112, + .end = 143, + }, +}; + +static struct resource usb_res[] = { + { + .name = "regs", + .flags = IORESOURCE_MEM, + .start = AR7_REGS_USB, + .end = AR7_REGS_USB + 0xff, + }, + { + .name = "irq", + .flags = IORESOURCE_IRQ, + .start = 32, + .end = 32, + }, + { + .name = "mem", + .flags = IORESOURCE_MEM, + .start = 0x03400000, + .end = 0x034001fff, + }, +}; + +static struct physmap_flash_data physmap_flash_data = { + .width = 2, +}; + +static struct plat_cpmac_data cpmac_low_data = { + .reset_bit = 17, + .power_bit = 20, + .phy_mask = 0x80000000, +}; + +static struct plat_cpmac_data cpmac_high_data = { + .reset_bit = 21, + .power_bit = 22, + .phy_mask = 0x7fffffff, +}; + +static struct plat_vlynq_data vlynq_low_data = { + .ops.on = vlynq_on, + .ops.off = vlynq_off, + .reset_bit = 20, + .gpio_bit = 18, +}; + +static struct plat_vlynq_data vlynq_high_data = { + .ops.on = vlynq_on, + .ops.off = vlynq_off, + .reset_bit = 16, + .gpio_bit = 19, +}; + +static struct platform_device physmap_flash = { + .id = 0, + .name = "physmap-flash", + .dev.platform_data = &physmap_flash_data, + .resource = &physmap_flash_resource, + .num_resources = 1, +}; + +static u64 cpmac_dma_mask = DMA_32BIT_MASK; +static struct platform_device cpmac_low = { + .id = 0, + .name = "cpmac", + .dev = { + .dma_mask = &cpmac_dma_mask, + .coherent_dma_mask = DMA_32BIT_MASK, + .platform_data = &cpmac_low_data, + }, + .resource = cpmac_low_res, + .num_resources = ARRAY_SIZE(cpmac_low_res), +}; + +static struct platform_device cpmac_high = { + .id = 1, + .name = "cpmac", + .dev = { + .dma_mask = &cpmac_dma_mask, + .coherent_dma_mask = DMA_32BIT_MASK, + .platform_data = &cpmac_high_data, + }, + .resource = cpmac_high_res, + .num_resources = ARRAY_SIZE(cpmac_high_res), +}; + +static struct platform_device vlynq_low = { + .id = 0, + .name = "vlynq", + .dev.platform_data = &vlynq_low_data, + .resource = vlynq_low_res, + .num_resources = ARRAY_SIZE(vlynq_low_res), +}; + +static struct platform_device vlynq_high = { + .id = 1, + .name = "vlynq", + .dev.platform_data = &vlynq_high_data, + .resource = vlynq_high_res, + .num_resources = ARRAY_SIZE(vlynq_high_res), +}; + + +/* This is proper way to define uart ports, but they are then detected + * as xscale and, obviously, don't work... + */ +#if !defined(CONFIG_SERIAL_8250) + +static struct plat_serial8250_port uart0_data = { + .mapbase = AR7_REGS_UART0, + .irq = AR7_IRQ_UART0, + .regshift = 2, + .iotype = UPIO_MEM, + .flags = UPF_BOOT_AUTOCONF | UPF_IOREMAP, +}; + +static struct plat_serial8250_port uart1_data = { + .mapbase = UR8_REGS_UART1, + .irq = AR7_IRQ_UART1, + .regshift = 2, + .iotype = UPIO_MEM, + .flags = UPF_BOOT_AUTOCONF | UPF_IOREMAP, +}; + +static struct plat_serial8250_port uart_data[] = { + uart0_data, + uart1_data, + { .flags = 0 } +}; + +static struct plat_serial8250_port uart_data_single[] = { + uart0_data, + { .flags = 0 } +}; + +static struct platform_device uart = { + .id = 0, + .name = "serial8250", + .dev.platform_data = uart_data_single +}; +#endif + +#if LINUX_VERSION_CODE >= KERNEL_VERSION(2,6,23) +static struct gpio_led default_leds[] = { + { .name = "status", .gpio = 8, .active_low = 1, }, +}; + +static struct gpio_led fb_leds[] = { + { .name = "1", .gpio = 7, }, + { .name = "2", .gpio = 13, .active_low = 1, }, + { .name = "3", .gpio = 10, .active_low = 1, }, + { .name = "4", .gpio = 12, .active_low = 1, }, + { .name = "5", .gpio = 9, .active_low = 1, }, +}; + +static struct gpio_led fb_fon_leds[] = { + { .name = "1", .gpio = 8, }, + { .name = "2", .gpio = 3, .active_low = 1, }, + { .name = "3", .gpio = 5, }, + { .name = "4", .gpio = 4, .active_low = 1, }, + { .name = "5", .gpio = 11, .active_low = 1, }, +}; + +static struct gpio_led_platform_data ar7_led_data; + +static struct platform_device ar7_gpio_leds = { + .name = "leds-gpio", + .id = -1, + .dev = { + .platform_data = &ar7_led_data, + } +}; +#endif + +static struct platform_device ar7_udc = { + .id = -1, + .name = "ar7_udc", + .resource = usb_res, + .num_resources = ARRAY_SIZE(usb_res), +}; + +static inline unsigned char char2hex(char h) +{ + switch (h) { + case '0': case '1': case '2': case '3': case '4': + case '5': case '6': case '7': case '8': case '9': + return h - '0'; + case 'A': case 'B': case 'C': case 'D': case 'E': case 'F': + return h - 'A' + 10; + case 'a': case 'b': case 'c': case 'd': case 'e': case 'f': + return h - 'a' + 10; + default: + return 0; + } +} + +static void cpmac_get_mac(int instance, unsigned char *dev_addr) +{ + int i; + char name[5], default_mac[] = "00:00:00:12:34:56", *mac; + + mac = NULL; + sprintf(name, "mac%c", 'a' + instance); + mac = prom_getenv(name); + if (!mac) { + sprintf(name, "mac%c", 'a'); + mac = prom_getenv(name); + } + if (!mac) + mac = default_mac; + for (i = 0; i < 6; i++) + dev_addr[i] = (char2hex(mac[i * 3]) << 4) + + char2hex(mac[i * 3 + 1]); +} + +static int __init ar7_register_devices(void) +{ + int res; + +#ifdef CONFIG_SERIAL_8250 + + static struct uart_port uart_port[2]; + + memset(uart_port, 0, sizeof(struct uart_port) * 2); + + uart_port[0].type = PORT_AR7; + uart_port[0].line = 0; + uart_port[0].irq = AR7_IRQ_UART0; + uart_port[0].uartclk = ar7_bus_freq() / 2; + uart_port[0].iotype = UPIO_MEM; + uart_port[0].mapbase = AR7_REGS_UART0; + uart_port[0].membase = ioremap(uart_port[0].mapbase, 256); + uart_port[0].regshift = 2; + res = early_serial_setup(&uart_port[0]); + if (res) + return res; + + + /* Only TNETD73xx have a second serial port */ + if (ar7_has_second_uart()) { + uart_port[1].type = PORT_AR7; + uart_port[1].line = 1; + uart_port[1].irq = AR7_IRQ_UART1; + uart_port[1].uartclk = ar7_bus_freq() / 2; + uart_port[1].iotype = UPIO_MEM; + uart_port[1].mapbase = UR8_REGS_UART1; + uart_port[1].membase = ioremap(uart_port[1].mapbase, 256); + uart_port[1].regshift = 2; + res = early_serial_setup(&uart_port[1]); + if (res) + return res; + } + +#else /* !CONFIG_SERIAL_8250 */ + + uart_data[0].uartclk = ar7_bus_freq() / 2; + uart_data[1].uartclk = uart_data[0].uartclk; + + /* Only TNETD73xx have a second serial port */ + if (ar7_has_second_uart()) + uart.dev.platform_data = uart_data; + + res = platform_device_register(&uart); + if (res) + return res; + +#endif /* CONFIG_SERIAL_8250 */ + + res = platform_device_register(&physmap_flash); + if (res) + return res; + + res = platform_device_register(&vlynq_low); + if (res) + return res; + + ar7_device_disable(vlynq_low_data.reset_bit); + if (ar7_has_high_vlynq()) { + ar7_device_disable(vlynq_high_data.reset_bit); + res = platform_device_register(&vlynq_high); + if (res) + return res; + } + + if (ar7_has_high_cpmac()) { + cpmac_get_mac(1, cpmac_high_data.dev_addr); + res = platform_device_register(&cpmac_high); + if (res) + return res; + } else { + cpmac_low_data.phy_mask = 0xffffffff; + } + + cpmac_get_mac(0, cpmac_low_data.dev_addr); + res = platform_device_register(&cpmac_low); + if (res) + return res; + +#if LINUX_VERSION_CODE >= KERNEL_VERSION(2,6,23) +#warning FIXME: add model detection + ar7_led_data.num_leds = ARRAY_SIZE(default_leds); + ar7_led_data.leds = default_leds; + res = platform_device_register(&ar7_gpio_leds); +#endif + if (res) + return res; + + res = platform_device_register(&ar7_udc); + + return res; +} + + +arch_initcall(ar7_register_devices); diff --git a/arch/mips/ar7/prom.c b/arch/mips/ar7/prom.c new file mode 100644 index 0000000..65fe0c0 --- /dev/null +++ b/arch/mips/ar7/prom.c @@ -0,0 +1,324 @@ +/* + * Copyright (C) 2006, 2007 OpenWrt.org + * + * Carsten Langgaard, carstenl@mips.com + * Copyright (C) 1999,2000 MIPS Technologies, Inc. All rights reserved. + * + * This program is free software; you can distribute it and/or modify it + * under the terms of the GNU General Public License (Version 2) as + * published by the Free Software Foundation. + * + * This program is distributed in the hope 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. + * + * Putting things on the screen/serial line using YAMONs facilities. + */ +#include +#include +#include +#include +#include +#include +#include +#include +#include + +#include +#include + +#define MAX_ENTRY 80 + +struct env_var { + char *name; + char *value; +}; + +static struct env_var adam2_env[MAX_ENTRY] = { { 0, }, }; + +char *prom_getenv(char *name) +{ + int i; + for (i = 0; (i < MAX_ENTRY) && adam2_env[i].name; i++) + if (!strcmp(name, adam2_env[i].name)) + return adam2_env[i].value; + + return NULL; +} +EXPORT_SYMBOL(prom_getenv); + +char * __init prom_getcmdline(void) +{ + return &(arcs_cmdline[0]); +} + +static void __init ar7_init_cmdline(int argc, char *argv[]) +{ + char *cp; + int actr; + + actr = 1; /* Always ignore argv[0] */ + + cp = &(arcs_cmdline[0]); + while (actr < argc) { + strcpy(cp, argv[actr]); + cp += strlen(argv[actr]); + *cp++ = ' '; + actr++; + } + if (cp != &(arcs_cmdline[0])) { + /* get rid of trailing space */ + --cp; + *cp = '\0'; + } +} + +struct psbl_rec { + u32 psbl_size; + u32 env_base; + u32 env_size; + u32 ffs_base; + u32 ffs_size; +}; + +static __initdata char psp_env_version[] = "TIENV0.8"; + +struct psp_env_chunk { + u8 num; + u8 ctrl; + u16 csum; + u8 len; + char data[11]; +} __attribute__ ((packed)); + +struct psp_var_map_entry { + u8 num; + char *value; +}; + +static struct psp_var_map_entry psp_var_map[] = { + { 1, "cpufrequency" }, + { 2, "memsize" }, + { 3, "flashsize" }, + { 4, "modetty0" }, + { 5, "modetty1" }, + { 8, "maca" }, + { 9, "macb" }, + { 28, "sysfrequency" }, + { 38, "mipsfrequency" }, +}; + +/* + +Well-known variable (num is looked up in table above for matching variable name) +Example: cpufrequency=211968000 ++----+----+----+----+----+----+----+----+----+----+----+----+----+----+----+--- +| 01 |CTRL|CHECKSUM | 01 | _2 | _1 | _1 | _9 | _6 | _8 | _0 | _0 | _0 | \0 | FF ++----+----+----+----+----+----+----+----+----+----+----+----+----+----+----+--- + +Name=Value pair in a single chunk +Example: NAME=VALUE ++----+----+----+----+----+----+----+----+----+----+----+----+----+----+----+--- +| 00 |CTRL|CHECKSUM | 01 | _N | _A | _M | _E | _0 | _V | _A | _L | _U | _E | \0 ++----+----+----+----+----+----+----+----+----+----+----+----+----+----+----+--- + +Name=Value pair in 2 chunks (len is the number of chunks) +Example: bootloaderVersion=1.3.7.15 ++----+----+----+----+----+----+----+----+----+----+----+----+----+----+----+--- +| 00 |CTRL|CHECKSUM | 02 | _b | _o | _o | _t | _l | _o | _a | _d | _e | _r | _V ++----+----+----+----+----+----+----+----+----+----+----+----+----+----+----+--- +| _e | _r | _s | _i | _o | _n | \0 | _1 | _. | _3 | _. | _7 | _. | _1 | _5 | \0 ++----+----+----+----+----+----+----+----+----+----+----+----+----+----+----+--- + +Data is padded with 0xFF + +*/ + +#define PSP_ENV_SIZE 4096 + +static char psp_env_data[PSP_ENV_SIZE] = { 0, }; + +static char * __init lookup_psp_var_map(u8 num) +{ + int i; + + for (i = 0; i < sizeof(psp_var_map); i++) + if (psp_var_map[i].num == num) + return psp_var_map[i].value; + + return NULL; +} + +static void __init add_adam2_var(char *name, char *value) +{ + int i; + for (i = 0; i < MAX_ENTRY; i++) { + if (!adam2_env[i].name) { + adam2_env[i].name = name; + adam2_env[i].value = value; + return; + } else if (!strcmp(adam2_env[i].name, name)) { + adam2_env[i].value = value; + return; + } + } +} + +static int __init parse_psp_env(void *psp_env_base) +{ + int i, n; + char *name, *value; + struct psp_env_chunk *chunks = (struct psp_env_chunk *)psp_env_data; + + memcpy_fromio(chunks, psp_env_base, PSP_ENV_SIZE); + + i = 1; + n = PSP_ENV_SIZE / sizeof(struct psp_env_chunk); + while (i < n) { + if ((chunks[i].num == 0xff) || ((i + chunks[i].len) > n)) + break; + value = chunks[i].data; + if (chunks[i].num) { + name = lookup_psp_var_map(chunks[i].num); + } else { + name = value; + value += strlen(name) + 1; + } + if (name) + add_adam2_var(name, value); + i += chunks[i].len; + } + return 0; +} + +static void __init ar7_init_env(struct env_var *env) +{ + int i; + struct psbl_rec *psbl = (struct psbl_rec *)(KSEG1ADDR(0x14000300)); + void *psp_env = (void *)KSEG1ADDR(psbl->env_base); + + if (strcmp(psp_env, psp_env_version) == 0) { + parse_psp_env(psp_env); + } else { + for (i = 0; i < MAX_ENTRY; i++, env++) + if (env->name) + add_adam2_var(env->name, env->value); + } +} + +static void __init console_config(void) +{ +#ifdef CONFIG_SERIAL_8250_CONSOLE + char console_string[40]; + int baud = 0; + char parity = '\0', bits = '\0', flow = '\0'; + char *s, *p; + + if (strstr(prom_getcmdline(), "console=")) + return; + +#ifdef CONFIG_KGDB + if (!strstr(prom_getcmdline(), "nokgdb")) { + strcat(prom_getcmdline(), " console=kgdb"); + kgdb_enabled = 1; + return; + } +#endif + + if ((s = prom_getenv("modetty0"))) { + baud = simple_strtoul(s, &p, 10); + s = p; + if (*s == ',') s++; + if (*s) parity = *s++; + if (*s == ',') s++; + if (*s) bits = *s++; + if (*s == ',') s++; + if (*s == 'h') flow = 'r'; + } + + if (baud == 0) + baud = 38400; + if (parity != 'n' && parity != 'o' && parity != 'e') + parity = 'n'; + if (bits != '7' && bits != '8') + bits = '8'; + + if (flow == 'r') + sprintf(console_string, " console=ttyS0,%d%c%c%c", baud, + parity, bits, flow); + else + sprintf(console_string, " console=ttyS0,%d%c%c", baud, parity, + bits); + strcat(prom_getcmdline(), console_string); +#endif +} + +void __init prom_init(void) +{ + ar7_init_cmdline(fw_arg0, (char **)fw_arg1); + ar7_init_env((struct env_var *)fw_arg2); + console_config(); +} + +#define PORT(offset) (KSEG1ADDR(AR7_REGS_UART0 + (offset * 4))) +static inline unsigned int serial_in(int offset) +{ + return readb((void *)PORT(offset)); +} + +static inline void serial_out(int offset, int value) +{ + writeb(value, (void *)PORT(offset)); +} + +char prom_getchar(void) +{ + while (!(serial_in(UART_LSR) & UART_LSR_DR)); + return serial_in(UART_RX); +} + +int prom_putchar(char c) +{ + while ((serial_in(UART_LSR) & UART_LSR_TEMT) == 0); + serial_out(UART_TX, c); + return 1; +} + +/* from adm5120/prom.c */ +void prom_printf(char *fmt, ...) +{ + va_list args; + int l; + char *p, *buf_end; + char buf[1024]; + + va_start(args, fmt); + l = vsprintf(buf, fmt, args); /* hopefully i < sizeof(buf) */ + va_end(args); + + buf_end = buf + l; + + for (p = buf; p < buf_end; p++) { + /* Crude cr/nl handling is better than none */ + if (*p == '\n') + prom_putchar('\r'); + prom_putchar(*p); + } +} + +#ifdef CONFIG_KGDB +int putDebugChar(char c) +{ + return prom_putchar(c); +} + +char getDebugChar(void) +{ + return prom_getchar(); +} +#endif diff --git a/arch/mips/ar7/setup.c b/arch/mips/ar7/setup.c new file mode 100644 index 0000000..793f37c --- /dev/null +++ b/arch/mips/ar7/setup.c @@ -0,0 +1,106 @@ +/* + * Carsten Langgaard, carstenl@mips.com + * Copyright (C) 2000 MIPS Technologies, Inc. All rights reserved. + * + * This program is free software; you can distribute it and/or modify it + * under the terms of the GNU General Public License (Version 2) as + * published by the Free Software Foundation. + * + * This program is distributed in the hope 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 +#include +#include + +#include +#include +#include +#include + +extern void ar7_time_init(void); +static void ar7_machine_restart(char *command); +static void ar7_machine_halt(void); +static void ar7_machine_power_off(void); + +static void ar7_machine_restart(char *command) +{ + u32 *softres_reg = (u32 *)ioremap(AR7_REGS_RESET + + AR7_RESET_SOFTWARE, 1); + writel(1, softres_reg); +} + +static void ar7_machine_halt(void) +{ + while (1); +} + +static void ar7_machine_power_off(void) +{ + u32 *power_reg = (u32 *)ioremap(AR7_REGS_POWER, 1); + u32 power_state = readl(power_reg) | (3 << 30); + writel(power_state, power_reg); + ar7_machine_halt(); +} + +const char *get_system_type(void) +{ + u16 chip_id = ar7_chip_id(); + switch (chip_id) { + case AR7_CHIP_7300: + return "TI AR7 (TNETD7300)"; + case AR7_CHIP_7100: + return "TI AR7 (TNETD7100)"; + case AR7_CHIP_7200: + return "TI AR7 (TNETD7200)"; + default: + return "TI AR7 (Unknown)"; + } +} + +static int __init ar7_init_console(void) +{ + return 0; +} + +/* + * Initializes basic routines and structures pointers, memory size (as + * given by the bios and saves the command line. + */ + +extern void ar7_init_clocks(void); + +void __init plat_mem_setup(void) +{ + unsigned long io_base; + + _machine_restart = ar7_machine_restart; + _machine_halt = ar7_machine_halt; + pm_power_off = ar7_machine_power_off; + board_time_init = ar7_time_init; + panic_timeout = 3; + + io_base = (unsigned long)ioremap(AR7_REGS_BASE, 0x10000); + if (!io_base) panic("Can't remap IO base!\n"); + set_io_port_base(io_base); + + prom_meminit(); + ar7_init_clocks(); + + ioport_resource.start = 0; + ioport_resource.end = ~0; + iomem_resource.start = 0; + iomem_resource.end = ~0; + + printk(KERN_INFO "%s, ID: 0x%04x, Revision: 0x%02x\n", + get_system_type(), + ar7_chip_id(), ar7_chip_rev()); +} + +console_initcall(ar7_init_console); diff --git a/arch/mips/ar7/time.c b/arch/mips/ar7/time.c new file mode 100644 index 0000000..4be2895 --- /dev/null +++ b/arch/mips/ar7/time.c @@ -0,0 +1,32 @@ +/* + * Carsten Langgaard, carstenl@mips.com + * Copyright (C) 1999,2000 MIPS Technologies, Inc. All rights reserved. + * + * This program is free software; you can distribute it and/or modify it + * under the terms of the GNU General Public License (Version 2) as + * published by the Free Software Foundation. + * + * This program is distributed in the hope 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. + * + * Setting up the clock on the MIPS boards. + */ + +#include +#include + +void __init ar7_time_init(void) +{ + mips_hpt_frequency = ar7_cpu_freq() / 2; +} + +void __init plat_timer_setup(struct irqaction *irq) +{ + setup_irq(7, irq); +} diff --git a/arch/mips/kernel/traps.c b/arch/mips/kernel/traps.c index 632bce1..3795c06 100644 --- a/arch/mips/kernel/traps.c +++ b/arch/mips/kernel/traps.c @@ -1076,9 +1076,22 @@ void *set_except_vector(int n, void *addr) exception_handlers[n] = handler; if (n == 0 && cpu_has_divec) { - *(u32 *)(ebase + 0x200) = 0x08000000 | - (0x03ffffff & (handler >> 2)); - flush_icache_range(ebase + 0x200, ebase + 0x204); + if ((handler ^ (ebase + 4)) & 0xfc000000) { + /* lui k0, 0x0000 */ + *(u32 *)(ebase + 0x200) = 0x3c1a0000 | (handler >> 16); + /* ori k0, 0x0000 */ + *(u32 *)(ebase + 0x204) = + 0x375a0000 | (handler & 0xffff); + /* jr k0 */ + *(u32 *)(ebase + 0x208) = 0x03400008; + /* nop */ + *(u32 *)(ebase + 0x20C) = 0x00000000; + flush_icache_range(ebase + 0x200, ebase + 0x210); + } else { + *(volatile u32 *)(ebase + 0x200) = + 0x08000000 | (0x03ffffff & (handler >> 2)); + flush_icache_range(ebase + 0x200, ebase + 0x204); + } } return (void *)old_handler; } diff --git a/include/asm-mips/ar7/ar7.h b/include/asm-mips/ar7/ar7.h new file mode 100644 index 0000000..4f90eb1 --- /dev/null +++ b/include/asm-mips/ar7/ar7.h @@ -0,0 +1,169 @@ +/* + * Copyright (C) 2006, 2007 Felix Fietkau, Eugene Konev + * + * 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., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA + */ + +#ifndef __AR7_H__ +#define __AR7_H__ + +#include +#include +#include + +#define AR7_REGS_BASE 0x08610000 + +#define AR7_REGS_MAC0 (AR7_REGS_BASE + 0x0000) +#define AR7_REGS_GPIO (AR7_REGS_BASE + 0x0900) +/* 0x08610A00 - 0x08610BFF (512 bytes, 128 bytes / clock) */ +#define AR7_REGS_POWER (AR7_REGS_BASE + 0x0a00) +#define AR7_REGS_UART0 (AR7_REGS_BASE + 0x0e00) +#define AR7_REGS_USB (AR7_REGS_BASE + 0x1200) +#define AR7_REGS_RESET (AR7_REGS_BASE + 0x1600) +#define AR7_REGS_VLYNQ0 (AR7_REGS_BASE + 0x1800) +#define AR7_REGS_DCL (AR7_REGS_BASE + 0x1a00) +#define AR7_REGS_VLYNQ1 (AR7_REGS_BASE + 0x1c00) +#define AR7_REGS_MDIO (AR7_REGS_BASE + 0x1e00) +#define AR7_REGS_IRQ (AR7_REGS_BASE + 0x2400) +#define AR7_REGS_MAC1 (AR7_REGS_BASE + 0x2800) + +#define AR7_REGS_WDT (AR7_REGS_BASE + 0x1f00) +#define UR8_REGS_WDT (AR7_REGS_BASE + 0x0b00) +#define UR8_REGS_UART1 (AR7_REGS_BASE + 0x0f00) + +#define AR7_RESET_PEREPHERIAL 0x0 +#define AR7_RESET_SOFTWARE 0x4 +#define AR7_RESET_STATUS 0x8 + +#define AR7_RESET_BIT_CPMAC_LO 17 +#define AR7_RESET_BIT_CPMAC_HI 21 +#define AR7_RESET_BIT_MDIO 22 +#define AR7_RESET_BIT_EPHY 26 + +/* GPIO control registers */ +#define AR7_GPIO_INPUT 0x0 +#define AR7_GPIO_OUTPUT 0x4 +#define AR7_GPIO_DIR 0x8 +#define AR7_GPIO_ENABLE 0xc + +#define AR7_CHIP_7100 0x18 +#define AR7_CHIP_7200 0x2b +#define AR7_CHIP_7300 0x05 + +/* Interrupts */ +#define AR7_IRQ_UART0 15 +#define AR7_IRQ_UART1 16 + +/* Clocks */ +#define AR7_AFE_CLOCK 35328000 +#define AR7_REF_CLOCK 25000000 +#define AR7_XTAL_CLOCK 24000000 + +struct plat_cpmac_data { + int reset_bit; + int power_bit; + u32 phy_mask; + char dev_addr[6]; +}; + +struct plat_dsl_data { + int reset_bit_dsl; + int reset_bit_sar; +}; + +extern int ar7_cpu_clock, ar7_bus_clock, ar7_dsp_clock; + +static inline u16 ar7_chip_id(void) +{ + return readl((void *)KSEG1ADDR(AR7_REGS_GPIO + 0x14)) & 0xffff; +} + +static inline u8 ar7_chip_rev(void) +{ + return (readl((void *)KSEG1ADDR(AR7_REGS_GPIO + 0x14)) >> 16) & 0xff; +} + +static inline int ar7_cpu_freq(void) +{ + return ar7_cpu_clock; +} + +static inline int ar7_bus_freq(void) +{ + return ar7_bus_clock; +} + +static inline int ar7_vbus_freq(void) +{ + return ar7_bus_clock / 2; +} +#define ar7_cpmac_freq ar7_vbus_freq + +static inline int ar7_dsp_freq(void) +{ + return ar7_dsp_clock; +} + +static inline int ar7_has_high_cpmac(void) +{ + u16 chip_id = ar7_chip_id(); + switch (chip_id) { + case AR7_CHIP_7100: + case AR7_CHIP_7200: + return 0; + default: + return 1; + } +} +#define ar7_has_high_vlynq ar7_has_high_cpmac +#define ar7_has_second_uart ar7_has_high_cpmac + +static inline void ar7_device_enable(u32 bit) +{ + void *reset_reg = + (void *)KSEG1ADDR(AR7_REGS_RESET + AR7_RESET_PEREPHERIAL); + writel(readl(reset_reg) | (1 << bit), reset_reg); + mdelay(20); +} + +static inline void ar7_device_disable(u32 bit) +{ + void *reset_reg = + (void *)KSEG1ADDR(AR7_REGS_RESET + AR7_RESET_PEREPHERIAL); + writel(readl(reset_reg) & ~(1 << bit), reset_reg); + mdelay(20); +} + +static inline void ar7_device_reset(u32 bit) +{ + ar7_device_disable(bit); + ar7_device_enable(bit); +} + +static inline void ar7_device_on(u32 bit) +{ + void *power_reg = (void *)KSEG1ADDR(AR7_REGS_POWER); + writel(readl(power_reg) | (1 << bit), power_reg); + mdelay(20); +} + +static inline void ar7_device_off(u32 bit) +{ + void *power_reg = (void *)KSEG1ADDR(AR7_REGS_POWER); + writel(readl(power_reg) & ~(1 << bit), power_reg); + mdelay(20); +} + +#endif /* __AR7_H__ */ diff --git a/include/asm-mips/ar7/gpio.h b/include/asm-mips/ar7/gpio.h new file mode 100644 index 0000000..4fe9496 --- /dev/null +++ b/include/asm-mips/ar7/gpio.h @@ -0,0 +1,121 @@ +/* + * Copyright (C) 2007 Florian Fainelli + * + * 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., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA + */ + +#ifndef __AR7_GPIO_H__ +#define __AR7_GPIO_H__ +#include + +#define AR7_GPIO_MAX 32 + +extern int gpio_request(unsigned gpio, const char *label); +extern void gpio_free(unsigned gpio); + +/* Common GPIO layer */ +static inline int gpio_get_value(unsigned gpio) +{ + void __iomem *gpio_in = + (void __iomem *)KSEG1ADDR(AR7_REGS_GPIO + AR7_GPIO_INPUT); + + if (gpio >= AR7_GPIO_MAX) + return -EINVAL; + + return ((readl(gpio_in) & (1 << gpio)) != 0); +} + +static inline void gpio_set_value(unsigned gpio, int value) +{ + void __iomem *gpio_out = + (void __iomem *)KSEG1ADDR(AR7_REGS_GPIO + AR7_GPIO_OUTPUT); + volatile unsigned tmp; + + if (gpio >= AR7_GPIO_MAX) + return; + + tmp = readl(gpio_out) & ~(1 << gpio); + if (value) + tmp |= 1 << gpio; + writel(tmp, gpio_out); +} + +static inline int gpio_direction_input(unsigned gpio) +{ + void __iomem *gpio_dir = + (void __iomem *)KSEG1ADDR(AR7_REGS_GPIO + AR7_GPIO_DIR); + + if (gpio >= AR7_GPIO_MAX) + return -EINVAL; + + writel(readl(gpio_dir) | (1 << gpio), gpio_dir); + + return 0; +} + +static inline int gpio_direction_output(unsigned gpio, int value) +{ + void __iomem *gpio_dir = + (void __iomem *)KSEG1ADDR(AR7_REGS_GPIO + AR7_GPIO_DIR); + + if (gpio >= AR7_GPIO_MAX) + return -EINVAL; + + gpio_set_value(gpio, value); + writel(readl(gpio_dir) & ~(1 << gpio), gpio_dir); + + return 0; +} + +static inline int gpio_to_irq(unsigned gpio) +{ + return -EINVAL; +} + +static inline int irq_to_gpio(unsigned irq) +{ + return -EINVAL; +} + +/* Board specific GPIO functions */ +static inline int ar7_gpio_enable(unsigned gpio) +{ + void __iomem *gpio_en = + (void __iomem *)KSEG1ADDR(AR7_REGS_GPIO + AR7_GPIO_ENABLE); + + if (gpio >= AR7_GPIO_MAX) + return -EINVAL; + + writel(readl(gpio_en) | (1 << gpio), gpio_en); + + return 0; +} + +static inline int ar7_gpio_disable(unsigned gpio) +{ + void __iomem *gpio_en = + (void __iomem *)KSEG1ADDR(AR7_REGS_GPIO + AR7_GPIO_ENABLE); + + if (gpio >= AR7_GPIO_MAX) + return -EINVAL; + + writel(readl(gpio_en) & ~(1 << gpio), gpio_en); + + return 0; +} + +#include + +#endif diff --git a/include/asm-mips/ar7/irq.h b/include/asm-mips/ar7/irq.h new file mode 100644 index 0000000..39e9757 --- /dev/null +++ b/include/asm-mips/ar7/irq.h @@ -0,0 +1,16 @@ +/* + * 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. + * + * Shamelessly copied from asm-mips/mach-emma2rh/ + * Copyright (C) 2003 by Ralf Baechle + */ +#ifndef __ASM_AR7_IRQ_H +#define __ASM_AR7_IRQ_H + +#define NR_IRQS 256 + +#include_next + +#endif /* __ASM_AR7_IRQ_H */ diff --git a/include/asm-mips/ar7/prom.h b/include/asm-mips/ar7/prom.h new file mode 100644 index 0000000..62d7d5c --- /dev/null +++ b/include/asm-mips/ar7/prom.h @@ -0,0 +1,25 @@ +/* + * Copyright (C) 2006, 2007 Florian Fainelli + * + * 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., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA + */ + +#ifndef __PROM_H__ +#define __PROM_H__ + +extern char *prom_getenv(char *name); +extern void prom_printf(char *fmt, ...); + +#endif /* __PROM_H__ */ diff --git a/include/asm-mips/ar7/spaces.h b/include/asm-mips/ar7/spaces.h new file mode 100644 index 0000000..f4d1237 --- /dev/null +++ b/include/asm-mips/ar7/spaces.h @@ -0,0 +1,32 @@ +/* + * 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) 1994 - 1999, 2000, 03, 04 Ralf Baechle + * Copyright (C) 2000, 2002 Maciej W. Rozycki + * Copyright (C) 1990, 1999, 2000 Silicon Graphics, Inc. + */ +#ifndef _ASM_AR7_SPACES_H +#define _ASM_AR7_SPACES_H + +#define CAC_BASE 0x80000000 +#define IO_BASE 0xa0000000 +#define UNCAC_BASE 0xa0000000 +#define MAP_BASE 0xc0000000 + +/* + * This handles the memory map. + * We handle pages at KSEG0 for kernels with 32 bit address space. + */ +#define PAGE_OFFSET 0x94000000UL +#define PHYS_OFFSET 0x14000000UL + +/* + * Memory above this physical address will be considered highmem. + */ +#ifndef HIGHMEM_START +#define HIGHMEM_START 0x40000000UL +#endif + +#endif /* __ASM_AR7_SPACES_H */ diff --git a/include/asm-mips/page.h b/include/asm-mips/page.h index d2ea983..8fda483 100644 --- a/include/asm-mips/page.h +++ b/include/asm-mips/page.h @@ -184,8 +184,10 @@ typedef struct { unsigned long pgprot; } pgprot_t; #define VM_DATA_DEFAULT_FLAGS (VM_READ | VM_WRITE | VM_EXEC | \ VM_MAYREAD | VM_MAYWRITE | VM_MAYEXEC) -#define UNCAC_ADDR(addr) ((addr) - PAGE_OFFSET + UNCAC_BASE) -#define CAC_ADDR(addr) ((addr) - UNCAC_BASE + PAGE_OFFSET) +#define UNCAC_ADDR(addr) ((addr) - PAGE_OFFSET + UNCAC_BASE + \ + PHYS_OFFSET) +#define CAC_ADDR(addr) ((addr) - UNCAC_BASE + PAGE_OFFSET - \ + PHYS_OFFSET) #include #include From technoboy85@gmail.com Thu Oct 11 02:00:13 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 11 Oct 2007 02:00:22 +0100 (BST) Received: from wx-out-0506.google.com ([66.249.82.236]:20818 "EHLO wx-out-0506.google.com") by ftp.linux-mips.org with ESMTP id S20021460AbXJKBAN (ORCPT ); Thu, 11 Oct 2007 02:00:13 +0100 Received: by wx-out-0506.google.com with SMTP id h30so380518wxd for ; Wed, 10 Oct 2007 17:59:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:from:to:subject:date:user-agent:references:in-reply-to:cc:mime-version:content-type:content-transfer-encoding:content-disposition:message-id; bh=XQSJQXJGlCK4ddcGdT67jUX5oae5ZQ93Ujm0pms90Ww=; b=WxibhXNm4ZvizWKNQHiQYHhCJZrpR2o/Z54b07zvVtLb7jdKdINPKDrdMqqDoK/30Rnt2ngypTBLeK/7ZpudQdHeeblaD0hefhJ16XCaMWXQFFflxKKx1JEmiETr/dSjU1lDxffRlrg41PP3GkPidIm6VDTa8pW4LNgfW2F/Obk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:from:to:subject:date:user-agent:references:in-reply-to:cc:mime-version:content-type:content-transfer-encoding:content-disposition:message-id; b=tLAgwXop8UGXuWZi5iqke4fABHusp4qCY4rGpz8quCvf19741FLNcnMJv0yNwc92m6J4Qb8+2ghbasEqLA9o6rWxTo+g3qF7/ViHOlHND7MM0BSipLrllmPu04Ez4m2uLtqnggW37/hMErU+wNn3sVUT8Odfu/gdYZKPYOQXJXU= Received: by 10.70.18.11 with SMTP id 11mr2151442wxr.1192064394366; Wed, 10 Oct 2007 17:59:54 -0700 (PDT) Received: from ?192.168.0.3? ( [87.18.114.61]) by mx.google.com with ESMTPS id h8sm1817106wxd.2007.10.10.17.59.51 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 10 Oct 2007 17:59:53 -0700 (PDT) From: Matteo Croce To: linux-mips@linux-mips.org Subject: [PATCH][MIPS][5/6] AR7: serial hack Date: Thu, 11 Oct 2007 02:59:52 +0200 User-Agent: KMail/1.9.6 (enterprise 0.20070907.709405) References: <200710110248.33028.technoboy85@gmail.com> In-Reply-To: <200710110248.33028.technoboy85@gmail.com> Cc: Florian Fainelli , Felix Fietkau , Nicolas Thill , linux-serial@vger.kernel.org, Andrew Morton MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200710110259.52498.technoboy85@gmail.com> Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 16953 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: technoboy85@gmail.com Precedence: bulk X-list: linux-mips Signed-off-by: Matteo Croce Signed-off-by: Florian Fainelli Signed-off-by: Felix Fietkau Signed-off-by: Nicolas Thill diff --git a/drivers/serial/8250.c b/drivers/serial/8250.c index f94109c..94253b7 100644 --- a/drivers/serial/8250.c +++ b/drivers/serial/8250.c @@ -267,6 +267,13 @@ static const struct serial8250_config uart_config[] = { .fcr = UART_FCR_ENABLE_FIFO | UART_FCR_R_TRIG_10, .flags = UART_CAP_FIFO, }, + [PORT_AR7] = { + .name = "TI-AR7", + .fifo_size = 16, + .tx_loadsz = 16, + .fcr = UART_FCR_ENABLE_FIFO | UART_FCR_R_TRIG_00, + .flags = UART_CAP_FIFO | UART_CAP_AFE, + }, }; #if defined (CONFIG_SERIAL_8250_AU1X00) @@ -2453,7 +2460,11 @@ static void serial8250_console_putchar(struct uart_port *port, int ch) { struct uart_8250_port *up = (struct uart_8250_port *)port; +#ifdef CONFIG_AR7 + wait_for_xmitr(up, BOTH_EMPTY); +#else wait_for_xmitr(up, UART_LSR_THRE); +#endif serial_out(up, UART_TX, ch); } diff --git a/include/linux/serialP.h b/include/linux/serialP.h index e811a61..cf71de9 100644 --- a/include/linux/serialP.h +++ b/include/linux/serialP.h @@ -135,6 +135,10 @@ struct rs_multiport_struct { * the interrupt line _up_ instead of down, so if we register the IRQ * while the UART is in that state, we die in an IRQ storm. */ #define ALPHA_KLUDGE_MCR (UART_MCR_OUT2) +#elif defined(CONFIG_AR7) +/* This is how it is set up by bootloader... */ +#define ALPHA_KLUDGE_MCR (UART_MCR_OUT2 | UART_MCR_OUT1 \ + | UART_MCR_RTS | UART_MCR_DTR) #else #define ALPHA_KLUDGE_MCR 0 #endif diff --git a/include/linux/serial_core.h b/include/linux/serial_core.h index 09d17b0..8ad2c3b 100644 --- a/include/linux/serial_core.h +++ b/include/linux/serial_core.h @@ -40,6 +40,7 @@ #define PORT_NS16550A 14 #define PORT_XSCALE 15 #define PORT_RM9000 16 /* PMC-Sierra RM9xxx internal UART */ +#define PORT_AR7 16 #define PORT_MAX_8250 16 /* max port ID */ /* From technoboy85@gmail.com Thu Oct 11 02:01:53 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 11 Oct 2007 02:02:01 +0100 (BST) Received: from wx-out-0506.google.com ([66.249.82.226]:4951 "EHLO wx-out-0506.google.com") by ftp.linux-mips.org with ESMTP id S20021460AbXJKBBx (ORCPT ); Thu, 11 Oct 2007 02:01:53 +0100 Received: by wx-out-0506.google.com with SMTP id h30so380839wxd for ; Wed, 10 Oct 2007 18:01:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:from:to:subject:date:user-agent:references:in-reply-to:cc:mime-version:content-type:content-transfer-encoding:content-disposition:message-id; bh=UrLYN2qwcSd9xJ8OLjxx1yFSkLhNRmnFS+cniSKNbUo=; b=IkToxRUeEg7y117Gvj8+m4ef1DlyOVN/s5qO8p6SpmBh6wqftnqM7zKI23TVQp84BWR/bPMwGese2+ODt/lvhJr0GkjAWA4LcsNWnQNU6yNBkaU3GiJ2uZhvwTMrd4ERPpwAL+nsDjsoavjT4ylzC9B9Y1UftbsrCh003YxqNcY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:from:to:subject:date:user-agent:references:in-reply-to:cc:mime-version:content-type:content-transfer-encoding:content-disposition:message-id; b=dSj5jSj9pKvGyNW9hwI+E8a3qJi3xvMmoZAnfUExgbHWjCm4j47NkN576GUXgaKFY/KYl/ltmokGzG64SJ0Ge8ibWenwm9dy5cq4srI1uK5ltIip4gz5EHodJX6KvOzZgdrWduwV7xqNilFGGUxbjfjDWSyYP4LIDgIzZCI5Ogc= Received: by 10.70.118.4 with SMTP id q4mr2170590wxc.1192064494717; Wed, 10 Oct 2007 18:01:34 -0700 (PDT) Received: from ?192.168.0.3? ( [87.18.114.61]) by mx.google.com with ESMTPS id h12sm1801849wxd.2007.10.10.18.01.30 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 10 Oct 2007 18:01:34 -0700 (PDT) From: Matteo Croce To: linux-mips@linux-mips.org Subject: Re: [PATCH][MIPS][6/6] AR7: leds driver Date: Thu, 11 Oct 2007 03:01:30 +0200 User-Agent: KMail/1.9.6 (enterprise 0.20070907.709405) References: <200710110248.33028.technoboy85@gmail.com> In-Reply-To: <200710110248.33028.technoboy85@gmail.com> Cc: Eugene Konev , netdev@vger.kernel.org, davem@davemloft.net, kuznet@ms2.inr.ac.ru, pekkas@netcore.fi, jmorris@namei.org, yoshfuji@linux-ipv6.org, kaber@coreworks.de, Andrew Morton , Jeff Garzik MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200710110301.31223.technoboy85@gmail.com> Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 16954 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: technoboy85@gmail.com Precedence: bulk X-list: linux-mips The new led driver, uses leds-gpio now Signed-off-by: Matteo Croce Signed-off-by: Nicolas Thill diff --git a/drivers/leds/leds-ar7.c b/drivers/leds/leds-ar7.c new file mode 100644 index 0000000..72b958a --- /dev/null +++ b/drivers/leds/leds-ar7.c @@ -0,0 +1,130 @@ +/* + * Copyright (C) 2007 Nicolas Thill + * + * 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., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA + */ + + +#include +#include +#include +#include +#include +#include +#include + +#define DRVNAME "ar7-leds" +#define LONGNAME "TI AR7 LEDs driver" +#define AR7_GPIO_BIT_STATUS_LED 8 + +MODULE_AUTHOR("Nicolas Thill "); +MODULE_DESCRIPTION(LONGNAME); +MODULE_LICENSE("GPL"); + +static void ar7_status_led_set(struct led_classdev *pled, + enum led_brightness value) +{ + gpio_set_value(AR7_GPIO_BIT_STATUS_LED, value ? 0 : 1); +} + +static struct led_classdev ar7_status_led = { + .name = "ar7:status", + .brightness_set = ar7_status_led_set, +}; + +#ifdef CONFIG_PM +static int ar7_leds_suspend(struct platform_device *dev, + pm_message_t state) +{ + led_classdev_suspend(&ar7_status_led); + return 0; +} + +static int ar7_leds_resume(struct platform_device *dev) +{ + led_classdev_resume(&ar7_status_led); + return 0; +} +#else /* CONFIG_PM */ +#define ar7_leds_suspend NULL +#define ar7_leds_resume NULL +#endif /* CONFIG_PM */ + +static int ar7_leds_probe(struct platform_device *pdev) +{ + int rc; + + rc = led_classdev_register(&pdev->dev, &ar7_status_led); + if (rc < 0) + goto out; + + ar7_gpio_enable(AR7_GPIO_BIT_STATUS_LED); + gpio_direction_output(AR7_GPIO_BIT_STATUS_LED, 0); + +out: + return rc; +} + +static int ar7_leds_remove(struct platform_device *pdev) +{ + led_classdev_unregister(&ar7_status_led); + + return 0; +} + +static struct platform_device *ar7_leds_device; + +static struct platform_driver ar7_leds_driver = { + .probe = ar7_leds_probe, + .remove = ar7_leds_remove, + .suspend = ar7_leds_suspend, + .resume = ar7_leds_resume, + .driver = { + .name = DRVNAME, + }, +}; + +static int __init ar7_leds_init(void) +{ + int rc; + + ar7_leds_device = platform_device_alloc(DRVNAME, -1); + if (!ar7_leds_device) + return -ENOMEM; + + rc = platform_device_add(ar7_leds_device); + if (rc < 0) + goto out_put; + + rc = platform_driver_register(&ar7_leds_driver); + if (rc < 0) + goto out_put; + + goto out; + +out_put: + platform_device_put(ar7_leds_device); +out: + return rc; +} + +static void __exit ar7_leds_exit(void) +{ + platform_driver_unregister(&ar7_leds_driver); + platform_device_unregister(ar7_leds_device); +} + +module_init(ar7_leds_init); +module_exit(ar7_leds_exit); From vagabon.xyz@gmail.com Thu Oct 11 10:53:15 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 11 Oct 2007 10:53:45 +0100 (BST) Received: from mu-out-0910.google.com ([209.85.134.190]:17729 "EHLO mu-out-0910.google.com") by ftp.linux-mips.org with ESMTP id S20021470AbXJKJxP (ORCPT ); Thu, 11 Oct 2007 10:53:15 +0100 Received: by mu-out-0910.google.com with SMTP id w1so569111mue for ; Thu, 11 Oct 2007 02:52:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:user-agent:mime-version:to:cc:subject:content-type:content-transfer-encoding; bh=w2ThYS9RQI6HuRrAWw6Ha9mrJISrzZ5HulZc/31dcFY=; b=DS5HZHkSdnpevxA9rHz9BXyokilD1VX8YBmWGDt6UsNitDfTU6HZQaL/Ft4CtZNdyPBO/3bUMU7THkkX/Hf2B0u3f7Gn9Vg4qSYO3fkaK3uwTf+WhYs9YNZaxgyNPMo4l+mhUDaTRNXW3TSLm0yxrBxRzoXQPtJ66O6KaDaVIiE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:user-agent:mime-version:to:cc:subject:content-type:content-transfer-encoding; b=OFlvwu1nX4QGZoXMd/D7D0l07RAw5YjOMWKuEaH0Gk9AGoQ8YUuogdFStAna7uIF6XKZr63j9tIx53piaK+NH26UTDq9IRxSUIjLvLBpkcpMCQG9uQDXXfXSTCROtP83+Jol+jQFA4m76ONE7jqwNW5IQl5SC2kVBQDhEy7DX1M= Received: by 10.82.175.17 with SMTP id x17mr3456886bue.1192096377515; Thu, 11 Oct 2007 02:52:57 -0700 (PDT) Received: from ?192.168.0.1? ( [82.235.205.153]) by mx.google.com with ESMTPS id g1sm4040270muf.2007.10.11.02.52.55 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 11 Oct 2007 02:52:55 -0700 (PDT) Message-ID: <470DF25E.60009@gmail.com> Date: Thu, 11 Oct 2007 11:52:30 +0200 From: Franck Bui-Huu User-Agent: Thunderbird 2.0.0.5 (X11/20070719) MIME-Version: 1.0 To: Ralf Baechle , "Maciej W. Rozycki" , Geert Uytterhoeven CC: linux-mips Subject: [RFC] Add __initbss section Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 16955 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: vagabon.xyz@gmail.com Precedence: bulk X-list: linux-mips Hi, As discussed previously, it seems a good idea to create a new init section .init.bss that store uninitialized data used only at boot time. That way, we can avoid to embed these uninitialized data in the Linux image since it's totaly useless. As a good candidate for using this, is tlbex.c. This file allocates a couple of big arrays that don't need to be part of the init data section since they're not initialized and they're currently only used at boot time. So this patchset does this but the result looks weird: I tried to apply this patch on top of the patchset: ---8<--- diff --git a/arch/mips/mm/tlbex.c b/arch/mips/mm/tlbex.c index a61246d..8271eab 100644 --- a/arch/mips/mm/tlbex.c +++ b/arch/mips/mm/tlbex.c @@ -743,11 +743,11 @@ il_bgez(u32 **p, struct reloc **r, unsigned int reg, enum label_id l) * We deliberately chose a buffer size of 128, so we won't scribble * over anything important on overflow before we panic. */ -static __initdata u32 tlb_handler[128]; +static __initbss u32 tlb_handler[128]; /* simply assume worst case size for labels and relocs */ -static __initdata struct label labels[128]; -static __initdata struct reloc relocs[128]; +static __initbss struct label labels[128]; +static __initbss struct reloc relocs[128]; --->8--- and the kernel image is bigger after the patch is applied ! $ ls -l vmlinux* -rwxrwxr-x 1 fbuihuu fbuihuu 2503324 2007-10-11 11:41 vmlinux* -rwxrwxr-x 1 fbuihuu fbuihuu 2503264 2007-10-11 11:41 vmlinux~old* Could anybody explain me why ? The time is missing and I probably couldn't investigate into this until this weekend. Also not that with the current patchset applied, there are now 2 segments that need to be loaded, hopefully it won't cause any issues with any bootloaders out there that would assume that an image has only one segment... Other question: I noticed that the exit.data section is not discarded. Could anybody give me the reason why ? Franck From vagabon.xyz@gmail.com Thu Oct 11 10:54:55 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 11 Oct 2007 10:55:03 +0100 (BST) Received: from mu-out-0910.google.com ([209.85.134.191]:54853 "EHLO mu-out-0910.google.com") by ftp.linux-mips.org with ESMTP id S20021525AbXJKJyz (ORCPT ); Thu, 11 Oct 2007 10:54:55 +0100 Received: by mu-out-0910.google.com with SMTP id w1so569561mue for ; Thu, 11 Oct 2007 02:54:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding; bh=2EKZZqxR/gAYwzGTd1koyw5PhBuGixGo1v05dD8kGxM=; b=sCtl9AzrWd1rOwVXRXQB1lxps+6+7MR9BijJ1Nj46hEmg7sRyxisKrkhNjati6I53ojwGdl5aN6A4fdvuYmQIM9msiS7cxPd12ylpBuA/BSQ9PDV53alek6i7kWh+LL6eITknaZhI8qH6lSjE7NVe2AJewkuRZ9+d8OIS9LRKac= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding; b=esdUQgKN7HBmwZekJG4tj7Fua4YAiWibc0Re8tL3RsEKcnq5PYIlNqeL70H8PBzrCDEB6UjakWRUqsOPUU7YdmM0dYHZmgBZeVjdFrKOcjCSaApv0djG5ZhMI48idZzslQzPWOPyKMf8pK4kksWf5+Uw8nFvKAk/tUnbs24Y6C4= Received: by 10.82.162.14 with SMTP id k14mr3474975bue.1192096477289; Thu, 11 Oct 2007 02:54:37 -0700 (PDT) Received: from ?192.168.0.1? ( [82.235.205.153]) by mx.google.com with ESMTPS id e8sm4046074muf.2007.10.11.02.54.36 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 11 Oct 2007 02:54:36 -0700 (PDT) Message-ID: <470DF2C4.8050604@gmail.com> Date: Thu, 11 Oct 2007 11:54:12 +0200 From: Franck Bui-Huu User-Agent: Thunderbird 2.0.0.5 (X11/20070719) MIME-Version: 1.0 To: Ralf Baechle , "Maciej W. Rozycki" , Geert Uytterhoeven CC: linux-mips Subject: [PATCH 1/2] Add .init.bss section References: <470DF25E.60009@gmail.com> In-Reply-To: <470DF25E.60009@gmail.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 16956 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: vagabon.xyz@gmail.com Precedence: bulk X-list: linux-mips This patch creates a new init section called .init.bss. This section is similar to .init.data but doesn't consume any space in the vmlinux image. All data marked as part of this section must not be initialized, of course. Signed-off-by: Franck Bui-Huu --- include/linux/init.h | 24 ++++++++++++++++-------- 1 files changed, 16 insertions(+), 8 deletions(-) diff --git a/include/linux/init.h b/include/linux/init.h index 74b1f43..9fda0ec 100644 --- a/include/linux/init.h +++ b/include/linux/init.h @@ -43,6 +43,8 @@ #define __init __attribute__ ((__section__ (".init.text"))) __cold #define __initdata __attribute__ ((__section__ (".init.data"))) #define __exitdata __attribute__ ((__section__(".exit.data"))) +#define __initbss __attribute__ ((__section__ (".init.bss"))) +#define __exitbss __attribute__ ((__section__ (".exit.bss"))) #define __exit_call __attribute_used__ __attribute__ ((__section__ (".exitcall.exit"))) /* modpost check for section mismatches during the kernel build. @@ -257,10 +259,12 @@ void __init parse_early_param(void); #define __devexit #define __devexitdata #else -#define __devinit __init -#define __devinitdata __initdata -#define __devexit __exit -#define __devexitdata __exitdata +#define __devinit __init +#define __devinitdata __initdata +#define __devinitbss __initbss +#define __devexit __exit +#define __devexitdata __exitdata +#define __devexitbss __exitbss #endif #ifdef CONFIG_HOTPLUG_CPU @@ -270,9 +274,11 @@ void __init parse_early_param(void); #define __cpuexitdata #else #define __cpuinit __init -#define __cpuinitdata __initdata -#define __cpuexit __exit +#define __cpuinitdata __initdata +#define __cpuinitbss __initbss +#define __cpuexit __exit #define __cpuexitdata __exitdata +#define __cpuexitbss __exitbss #endif #if defined(CONFIG_MEMORY_HOTPLUG) || defined(CONFIG_ACPI_HOTPLUG_MEMORY) \ @@ -283,9 +289,11 @@ void __init parse_early_param(void); #define __memexitdata #else #define __meminit __init -#define __meminitdata __initdata -#define __memexit __exit +#define __meminitdata __initdata +#define __meminitbss __meminitbss +#define __memexit __exit #define __memexitdata __exitdata +#define __memexitbss __exitbss #endif /* Functions marked as __devexit may be discarded at kernel link time, depending -- 1.5.3.3 From vagabon.xyz@gmail.com Thu Oct 11 10:58:58 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 11 Oct 2007 10:59:07 +0100 (BST) Received: from fk-out-0910.google.com ([209.85.128.190]:47125 "EHLO fk-out-0910.google.com") by ftp.linux-mips.org with ESMTP id S20021541AbXJKJ66 (ORCPT ); Thu, 11 Oct 2007 10:58:58 +0100 Received: by fk-out-0910.google.com with SMTP id f40so463275fka for ; Thu, 11 Oct 2007 02:58:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding; bh=bXdWnIVSZf5Wr9uM1h5+u09n28FDRK8YJGcNe5IEh9w=; b=dMHw1EfVEPHauulzL1caQbndf6UmtZWkSaah4opse7le7F+rcib03Jp4jHnWptv2EjXS7cRq79wGDlGBXwZtXvM/Rkx0iDeuBhqxz9n78uCcJQTBLpRE83NkkaTW2+HDg0XqjqR3CqTLoeaEbXpqFAfhkn8lbjcuHy2BxKJ534w= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding; b=Lyc06QKAUD4wuF/HijSYUBTUhjnJmcYw/gRK4bav+1olMsgeVNROE+G1o+FMG7pmujyvWnUcxX2XknrMofuh6m8WHgPUblvdVaF9tT5pIQoj73WEy08+Z1wl2qygu1i802V2thTS841RKX80Dvfk1gp83nt+CEF9UyJ51SDmiWg= Received: by 10.82.182.1 with SMTP id e1mr2733838buf.1192096721015; Thu, 11 Oct 2007 02:58:41 -0700 (PDT) Received: from ?192.168.0.1? ( [82.235.205.153]) by mx.google.com with ESMTPS id y6sm4065486mug.2007.10.11.02.58.40 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 11 Oct 2007 02:58:40 -0700 (PDT) Message-ID: <470DF3B8.6060804@gmail.com> Date: Thu, 11 Oct 2007 11:58:16 +0200 From: Franck Bui-Huu User-Agent: Thunderbird 2.0.0.5 (X11/20070719) MIME-Version: 1.0 To: Ralf Baechle , "Maciej W. Rozycki" , Geert Uytterhoeven CC: linux-mips Subject: [PATCH 2/2] Add .init.bss section for MIPS References: <470DF25E.60009@gmail.com> In-Reply-To: <470DF25E.60009@gmail.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 16957 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: vagabon.xyz@gmail.com Precedence: bulk X-list: linux-mips Signed-off-by: Franck Bui-Huu --- arch/mips/kernel/head.S | 5 +++++ arch/mips/kernel/vmlinux.lds.S | 7 ++++++- 2 files changed, 11 insertions(+), 1 deletions(-) diff --git a/arch/mips/kernel/head.S b/arch/mips/kernel/head.S index e46782b..e8245cd 100644 --- a/arch/mips/kernel/head.S +++ b/arch/mips/kernel/head.S @@ -183,6 +183,11 @@ NESTED(kernel_entry, 16, sp) # kernel entry point LONG_S zero, (t0) bne t0, t1, 1b + PTR_LA a0, _sinitbss + PTR_LA a1, _einitbss + PTR_SUBU a1, a0 + jal __bzero + LONG_S a0, fw_arg0 # firmware arguments LONG_S a1, fw_arg1 LONG_S a2, fw_arg2 diff --git a/arch/mips/kernel/vmlinux.lds.S b/arch/mips/kernel/vmlinux.lds.S index 84f9a4c..30e0d65 100644 --- a/arch/mips/kernel/vmlinux.lds.S +++ b/arch/mips/kernel/vmlinux.lds.S @@ -100,7 +100,7 @@ SECTIONS _edata = .; /* End of data section */ /* will be freed after init */ - . = ALIGN(_PAGE_SIZE); /* Init code and data */ + . = ALIGN(_PAGE_SIZE); /* Init code, data and bss */ __init_begin = .; .init.text : { _sinittext = .; @@ -110,6 +110,11 @@ SECTIONS .init.data : { *(.init.data) } + .init.bss (NOLOAD) : { + _sinitbss = .; + *(.init.bss) + _einitbss = .; + } . = ALIGN(16); .init.setup : { __setup_start = .; -- 1.5.3.3 From macro@linux-mips.org Thu Oct 11 13:01:34 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 11 Oct 2007 13:01:43 +0100 (BST) Received: from cerber.ds.pg.gda.pl ([153.19.208.18]:27623 "EHLO cerber.ds.pg.gda.pl") by ftp.linux-mips.org with ESMTP id S20030387AbXJKMBe (ORCPT ); Thu, 11 Oct 2007 13:01:34 +0100 Received: from localhost (unknown [127.0.0.17]) by cerber.ds.pg.gda.pl (Postfix) with ESMTP id E9A6C400A4; Thu, 11 Oct 2007 14:01:34 +0200 (CEST) X-Virus-Scanned: amavisd-new at cerber.ds.pg.gda.pl Received: from cerber.ds.pg.gda.pl ([153.19.208.18]) by localhost (cerber.ds.pg.gda.pl [153.19.208.18]) (amavisd-new, port 10024) with ESMTP id dR5QVdDMRK70; Thu, 11 Oct 2007 14:01:28 +0200 (CEST) Received: from piorun.ds.pg.gda.pl (piorun.ds.pg.gda.pl [153.19.208.8]) by cerber.ds.pg.gda.pl (Postfix) with ESMTP id 4DE4240095; Thu, 11 Oct 2007 14:01:28 +0200 (CEST) Received: from blysk.ds.pg.gda.pl (macro@blysk.ds.pg.gda.pl [153.19.208.6]) by piorun.ds.pg.gda.pl (8.13.8/8.13.8) with ESMTP id l9BC1U3l009966; Thu, 11 Oct 2007 14:01:31 +0200 Date: Thu, 11 Oct 2007 13:01:26 +0100 (BST) From: "Maciej W. Rozycki" To: Nigel Stephens cc: Franck Bui-Huu , Ralf Baechle , Thiemo Seufer , linux-mips@linux-mips.org Subject: Re: [SPAM?] Re: [PATCH] mm/pg-r4k.c: Dump the generated code In-Reply-To: <470CC0CE.9080303@mips.com> Message-ID: References: <20071002141125.GC16772@networkno.de> <20071002154918.GA11312@linux-mips.org> <47038874.9050704@gmail.com> <20071003131158.GL16772@networkno.de> <4703F155.4000301@gmail.com> <20071003201800.GP16772@networkno.de> <47049734.6050802@gmail.com> <20071004121557.GA28928@linux-mips.org> <4705004C.5000705@gmail.com> <4705EFE5.7090704@gmail.com> <470A4349.9090301@gmail.com> <470BE1F4.3070800@gmail.com> <470CC0CE.9080303@mips.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: ClamAV 0.91.2/4529/Thu Oct 11 08:54:06 2007 on piorun.ds.pg.gda.pl X-Virus-Status: Clean Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 16958 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: macro@linux-mips.org Precedence: bulk X-list: linux-mips On Wed, 10 Oct 2007, Nigel Stephens wrote: > Actually the -march=4ksd option will allow gcc to use of the SmartMIPS lwxs > (indexed load) instruction, which could save a few instructions here and > there. Good point, but if we decide the lone instruction is worth the hassle, then we should use "-msmartmips" on top of the base ISA selection. Likewise with "lwx" and "-mdsp". Though either way I am not sure these would have to be put in Kconfig or Makefile anywhere. A generic way should be enough for the insistent as the potentially useful options may proliferate; we have the CFLAGS_KERNEL and CFLAGS_MODULE Makefile variables that would suit for setting upon `make' invocation. Maciej From ralf@linux-mips.org Thu Oct 11 13:44:33 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 11 Oct 2007 13:44:35 +0100 (BST) Received: from localhost.localdomain ([127.0.0.1]:62387 "EHLO dl5rb.ham-radio-op.net") by ftp.linux-mips.org with ESMTP id S20030447AbXJKMod (ORCPT ); Thu, 11 Oct 2007 13:44:33 +0100 Received: from denk.linux-mips.net (denk.linux-mips.net [127.0.0.1]) by dl5rb.ham-radio-op.net (8.14.1/8.13.8) with ESMTP id l9BCiW2g024857; Thu, 11 Oct 2007 13:44:32 +0100 Received: (from ralf@localhost) by denk.linux-mips.net (8.14.1/8.14.1/Submit) id l9BCiAqo024843; Thu, 11 Oct 2007 13:44:10 +0100 Date: Thu, 11 Oct 2007 13:44:10 +0100 From: Ralf Baechle To: Franck Bui-Huu Cc: "Maciej W. Rozycki" , Geert Uytterhoeven , linux-mips Subject: Re: [RFC] Add __initbss section Message-ID: <20071011124410.GA17202@linux-mips.org> References: <470DF25E.60009@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <470DF25E.60009@gmail.com> User-Agent: Mutt/1.5.14 (2007-02-12) Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 16959 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: ralf@linux-mips.org Precedence: bulk X-list: linux-mips On Thu, Oct 11, 2007 at 11:52:30AM +0200, Franck Bui-Huu wrote: > Other question: I noticed that the exit.data section is not > discarded. Could anybody give me the reason why ? .exit.data and .exit.text may reference each other. __exit functions generally get compiled into .exit.text but some constructs such as jump tables for switch() constructs may be compiled into address tables which gcc unfortunately will put into .rodata, so .rodata will end up referencing function addresses in .exit.text which makes ld unhappy if .exit.text was discarded. So until this is fixed in gcc we can't discard exit code, unfortunately. It's actually an issue which doesn't strike very often, so users who are desparate for shrinking the kernel down could try to undo patchsets: 6f0b1e5d266fb1d0da019c07b56ccc02c3a4f53a ca7402fed2a76cd5a417ac4d375a5539dcb2b6de and see if they can get away with it. If the final kernel link succeeds, the build would be ok. I think gcc should probably put the jump table into a .subsection if a section was explicitly requested, at least for non-PIC code. Ralf From macro@linux-mips.org Thu Oct 11 14:19:09 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 11 Oct 2007 14:19:19 +0100 (BST) Received: from cerber.ds.pg.gda.pl ([153.19.208.18]:27543 "EHLO cerber.ds.pg.gda.pl") by ftp.linux-mips.org with ESMTP id S20030439AbXJKNTJ (ORCPT ); Thu, 11 Oct 2007 14:19:09 +0100 Received: from localhost (unknown [127.0.0.17]) by cerber.ds.pg.gda.pl (Postfix) with ESMTP id 2AA03400A4; Thu, 11 Oct 2007 15:19:10 +0200 (CEST) X-Virus-Scanned: amavisd-new at cerber.ds.pg.gda.pl Received: from cerber.ds.pg.gda.pl ([153.19.208.18]) by localhost (cerber.ds.pg.gda.pl [153.19.208.18]) (amavisd-new, port 10024) with ESMTP id qfCR-O5NWLGY; Thu, 11 Oct 2007 15:19:03 +0200 (CEST) Received: from piorun.ds.pg.gda.pl (piorun.ds.pg.gda.pl [153.19.208.8]) by cerber.ds.pg.gda.pl (Postfix) with ESMTP id D3C6C40095; Thu, 11 Oct 2007 15:19:03 +0200 (CEST) Received: from blysk.ds.pg.gda.pl (macro@blysk.ds.pg.gda.pl [153.19.208.6]) by piorun.ds.pg.gda.pl (8.13.8/8.13.8) with ESMTP id l9BDJ7eL024056; Thu, 11 Oct 2007 15:19:07 +0200 Date: Thu, 11 Oct 2007 14:19:02 +0100 (BST) From: "Maciej W. Rozycki" To: Franck Bui-Huu cc: Ralf Baechle , Geert Uytterhoeven , linux-mips Subject: Re: [RFC] Add __initbss section In-Reply-To: <470DF25E.60009@gmail.com> Message-ID: References: <470DF25E.60009@gmail.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: ClamAV 0.91.2/4529/Thu Oct 11 08:54:06 2007 on piorun.ds.pg.gda.pl X-Virus-Status: Clean Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 16960 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: macro@linux-mips.org Precedence: bulk X-list: linux-mips On Thu, 11 Oct 2007, Franck Bui-Huu wrote: > and the kernel image is bigger after the patch is applied ! > > $ ls -l vmlinux* > -rwxrwxr-x 1 fbuihuu fbuihuu 2503324 2007-10-11 11:41 vmlinux* > -rwxrwxr-x 1 fbuihuu fbuihuu 2503264 2007-10-11 11:41 vmlinux~old* > > Could anybody explain me why ? The time is missing and I probably > couldn't investigate into this until this weekend. I guess for a bss-type section you want to use something like: .section .init.bss,"aw",@nobits > Also not that with the current patchset applied, there are now 2 > segments that need to be loaded, hopefully it won't cause any issues > with any bootloaders out there that would assume that an image has > only one segment... Well, there should be no need for an extra segment -- just rearrange the order of the sections in the linker script appropriately. You should probably add __exitbss for consistency too. You can make all the three sections adjacent so that no separate initialisation is required. Another place for optimisation are inline string literals referred to from .init.text or .exit.text only, which is a bit more complicated to handle, but sounds interesting enough to me I shall give it a try in the next few days. I have an idea how to do it. Maciej From macro@linux-mips.org Thu Oct 11 14:35:56 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 11 Oct 2007 14:36:05 +0100 (BST) Received: from cerber.ds.pg.gda.pl ([153.19.208.18]:45979 "EHLO cerber.ds.pg.gda.pl") by ftp.linux-mips.org with ESMTP id S20021373AbXJKNf4 (ORCPT ); Thu, 11 Oct 2007 14:35:56 +0100 Received: from localhost (unknown [127.0.0.17]) by cerber.ds.pg.gda.pl (Postfix) with ESMTP id 21E9A400A4; Thu, 11 Oct 2007 15:35:27 +0200 (CEST) X-Virus-Scanned: amavisd-new at cerber.ds.pg.gda.pl Received: from cerber.ds.pg.gda.pl ([153.19.208.18]) by localhost (cerber.ds.pg.gda.pl [153.19.208.18]) (amavisd-new, port 10024) with ESMTP id Uuko7UlzZAk0; Thu, 11 Oct 2007 15:35:21 +0200 (CEST) Received: from piorun.ds.pg.gda.pl (piorun.ds.pg.gda.pl [153.19.208.8]) by cerber.ds.pg.gda.pl (Postfix) with ESMTP id 04F9340095; Thu, 11 Oct 2007 15:35:21 +0200 (CEST) Received: from blysk.ds.pg.gda.pl (macro@blysk.ds.pg.gda.pl [153.19.208.6]) by piorun.ds.pg.gda.pl (8.13.8/8.13.8) with ESMTP id l9BDZPQM027702; Thu, 11 Oct 2007 15:35:25 +0200 Date: Thu, 11 Oct 2007 14:35:20 +0100 (BST) From: "Maciej W. Rozycki" To: Ralf Baechle cc: Franck Bui-Huu , Geert Uytterhoeven , linux-mips Subject: Re: [RFC] Add __initbss section In-Reply-To: <20071011124410.GA17202@linux-mips.org> Message-ID: References: <470DF25E.60009@gmail.com> <20071011124410.GA17202@linux-mips.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: ClamAV 0.91.2/4529/Thu Oct 11 08:54:06 2007 on piorun.ds.pg.gda.pl X-Virus-Status: Clean Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 16961 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: macro@linux-mips.org Precedence: bulk X-list: linux-mips On Thu, 11 Oct 2007, Ralf Baechle wrote: > I think gcc should probably put the jump table into a .subsection if > a section was explicitly requested, at least for non-PIC code. Has anybody filed a bug report? The GCC maintainers may well not be aware of the problem and some arcane ways of use exercised by Linux. Maciej From yoichi_yuasa@tripeaks.co.jp Thu Oct 11 14:55:34 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 11 Oct 2007 14:55:42 +0100 (BST) Received: from mo30.po.2iij.net ([210.128.50.53]:25645 "EHLO mo30.po.2iij.net") by ftp.linux-mips.org with ESMTP id S20021571AbXJKNze (ORCPT ); Thu, 11 Oct 2007 14:55:34 +0100 Received: by mo.po.2iij.net (mo30) id l9BDsF0K015954; Thu, 11 Oct 2007 22:54:15 +0900 (JST) Received: from delta (221.25.30.125.dy.iij4u.or.jp [125.30.25.221]) by mbox.po.2iij.net (po-mbox302) id l9BDsEYi021931 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 11 Oct 2007 22:54:14 +0900 Date: Thu, 11 Oct 2007 22:54:13 +0900 From: Yoichi Yuasa To: Ralf Baechle Cc: yoichi_yuasa@tripeaks.co.jp, linux-mips Subject: [PATCH][MIPS] WRPPMC serial support move to platform device Message-Id: <20071011225413.e9bff979.yoichi_yuasa@tripeaks.co.jp> Organization: TriPeaks Corporation X-Mailer: Sylpheed 2.4.0 (GTK+ 2.10.11; i486-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 16962 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: yoichi_yuasa@tripeaks.co.jp Precedence: bulk X-list: linux-mips WRPPMC serial support move to platform device. Signed-off-by: Yoichi Yuasa diff -pruN -X mips/Documentation/dontdiff mips-orig/arch/mips/gt64120/wrppmc/Makefile mips/arch/mips/gt64120/wrppmc/Makefile --- mips-orig/arch/mips/gt64120/wrppmc/Makefile 2007-10-01 17:03:49.454725750 +0900 +++ mips/arch/mips/gt64120/wrppmc/Makefile 2007-10-01 18:24:04.947682250 +0900 @@ -9,6 +9,6 @@ # Makefile for the Wind River MIPS 4KC PPMC Eval Board # -obj-y += irq.o reset.o setup.o time.o pci.o +obj-y += irq.o pci.o reset.o serial.o setup.o time.o EXTRA_CFLAGS += -Werror diff -pruN -X mips/Documentation/dontdiff mips-orig/arch/mips/gt64120/wrppmc/serial.c mips/arch/mips/gt64120/wrppmc/serial.c --- mips-orig/arch/mips/gt64120/wrppmc/serial.c 1970-01-01 09:00:00.000000000 +0900 +++ mips/arch/mips/gt64120/wrppmc/serial.c 2007-10-01 18:24:04.967683500 +0900 @@ -0,0 +1,80 @@ +/* + * Registration of WRPPMC UART platform device. + * + * Copyright (C) 2007 Yoichi Yuasa + * + * 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., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA + */ +#include +#include +#include +#include +#include + +#include + +static struct resource wrppmc_uart_resource[] __initdata = { + { + .start = WRPPMC_UART16550_BASE, + .end = WRPPMC_UART16550_BASE + 7, + .flags = IORESOURCE_MEM, + }, + { + .start = WRPPMC_UART16550_IRQ, + .end = WRPPMC_UART16550_IRQ, + .flags = IORESOURCE_IRQ, + }, +}; + +static struct plat_serial8250_port wrppmc_serial8250_port[] = { + { + .irq = WRPPMC_UART16550_IRQ, + .uartclk = WRPPMC_UART16550_CLOCK, + .iotype = UPIO_MEM, + .flags = UPF_IOREMAP | UPF_SKIP_TEST, + .mapbase = WRPPMC_UART16550_BASE, + }, + {}, +}; + +static __init int wrppmc_uart_add(void) +{ + struct platform_device *pdev; + int retval; + + pdev = platform_device_alloc("serial8250", -1); + if (!pdev) + return -ENOMEM; + + pdev->id = PLAT8250_DEV_PLATFORM; + pdev->dev.platform_data = wrppmc_serial8250_port; + + retval = platform_device_add_resources(pdev, wrppmc_uart_resource, + ARRAY_SIZE(wrppmc_uart_resource)); + if (retval) + goto err_free_device; + + retval = platform_device_add(pdev); + if (retval) + goto err_free_device; + + return 0; + +err_free_device: + platform_device_put(pdev); + + return retval; +} +device_initcall(wrppmc_uart_add); diff -pruN -X mips/Documentation/dontdiff mips-orig/arch/mips/gt64120/wrppmc/setup.c mips/arch/mips/gt64120/wrppmc/setup.c --- mips-orig/arch/mips/gt64120/wrppmc/setup.c 2007-10-01 17:03:49.454725750 +0900 +++ mips/arch/mips/gt64120/wrppmc/setup.c 2007-10-01 18:24:04.967683500 +0900 @@ -11,10 +11,6 @@ #include #include #include -#include -#include -#include -#include #include #include @@ -98,32 +94,6 @@ void __init prom_free_prom_memory(void) { } -#ifdef CONFIG_SERIAL_8250 -static void wrppmc_setup_serial(void) -{ - struct uart_port up; - - memset(&up, 0x00, sizeof(struct uart_port)); - - /* - * A note about mapbase/membase - * -) mapbase is the physical address of the IO port. - * -) membase is an 'ioremapped' cookie. - */ - up.line = 0; - up.type = PORT_16550; - up.iotype = UPIO_MEM; - up.mapbase = WRPPMC_UART16550_BASE; - up.membase = ioremap(up.mapbase, 8); - up.irq = WRPPMC_UART16550_IRQ; - up.uartclk = WRPPMC_UART16550_CLOCK; - up.flags = UPF_SKIP_TEST/* | UPF_BOOT_AUTOCONF */; - up.regshift = 0; - - early_serial_setup(&up); -} -#endif - void __init plat_mem_setup(void) { extern void wrppmc_machine_restart(char *command); @@ -138,10 +108,6 @@ void __init plat_mem_setup(void)