From vagabon.xyz@gmail.com Fri Dec 1 09:40:53 2006 Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 01 Dec 2006 09:40:58 +0000 (GMT) Received: from ug-out-1314.google.com ([66.249.92.172]:52778 "EHLO ug-out-1314.google.com") by ftp.linux-mips.org with ESMTP id S20037860AbWLAJkx (ORCPT ); Fri, 1 Dec 2006 09:40:53 +0000 Received: by ug-out-1314.google.com with SMTP id 40so2560184uga for ; Fri, 01 Dec 2006 01:40:53 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:mime-version:content-type:content-transfer-encoding:content-disposition; b=htNn/jqLzg6aKMBFrh4x0Ek/xMhkjbreJbPmd+mc766S0wfNQBhoPYzhD824Z4c8+j3t2qoPCyX/7XhxGHgMvQeGobVovbduGXQqpbwL0q2APL1wuVoj4X6uQpYRQBkMyJ/4XUA3PTNzZ8D+zbxWTHtXzzix3VfMkQosUYu13lo= Received: by 10.78.83.13 with SMTP id g13mr4620878hub.1164966052368; Fri, 01 Dec 2006 01:40:52 -0800 (PST) Received: by 10.78.124.19 with HTTP; Fri, 1 Dec 2006 01:40:52 -0800 (PST) Message-ID: Date: Fri, 1 Dec 2006 10:40:52 +0100 From: "Franck Bui-Huu" To: "Atsushi Nemoto" Subject: Is _do_IRQ() not needed anymore ? Cc: linux-mips MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed 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: 13281 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 Atsushi, First thanks for your work on irq cleanup. Now it seems that __do_IRQ() is not needed anymore. I dunno if it's true for all platforms though. Does something like this make sense for example ? -- >8 -- diff --git a/arch/mips/Kconfig b/arch/mips/Kconfig index 5ff94e5..a4c5306 100644 --- a/arch/mips/Kconfig +++ b/arch/mips/Kconfig @@ -913,8 +913,13 @@ config SYS_SUPPORTS_BIG_ENDIAN config SYS_SUPPORTS_LITTLE_ENDIAN bool +config GENERIC_HARDIRQS_NO__DO_IRQ + bool + default n + config IRQ_CPU bool + select GENERIC_HARDIRQS_NO__DO_IRQ config IRQ_CPU_RM7K bool -- Franck From anemo@mba.ocn.ne.jp Fri Dec 1 09:57:48 2006 Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 01 Dec 2006 09:57:52 +0000 (GMT) Received: from topsns2.toshiba-tops.co.jp ([202.230.225.126]:11025 "EHLO topsns2.toshiba-tops.co.jp") by ftp.linux-mips.org with ESMTP id S20037861AbWLAJ5s (ORCPT ); Fri, 1 Dec 2006 09:57:48 +0000 Received: from topsms.toshiba-tops.co.jp by topsns2.toshiba-tops.co.jp via smtpd (for ftp.linux-mips.org [194.74.144.162]) with ESMTP; Fri, 1 Dec 2006 18:57:47 +0900 Received: from topsms.toshiba-tops.co.jp (localhost.localdomain [127.0.0.1]) by localhost.toshiba-tops.co.jp (Postfix) with ESMTP id 9CEFE25786; Fri, 1 Dec 2006 18:57:41 +0900 (JST) Received: from srd2sd.toshiba-tops.co.jp (srd2sd.toshiba-tops.co.jp [172.17.28.2]) by topsms.toshiba-tops.co.jp (Postfix) with ESMTP id 9122720474; Fri, 1 Dec 2006 18:57:41 +0900 (JST) Received: from localhost (fragile [172.17.28.65]) by srd2sd.toshiba-tops.co.jp (8.12.10/8.12.10) with ESMTP id kB19vfW0064617; Fri, 1 Dec 2006 18:57:41 +0900 (JST) (envelope-from anemo@mba.ocn.ne.jp) Date: Fri, 01 Dec 2006 18:57:40 +0900 (JST) Message-Id: <20061201.185740.03976990.nemoto@toshiba-tops.co.jp> To: vagabon.xyz@gmail.com Cc: linux-mips@linux-mips.org Subject: Re: Is _do_IRQ() not needed anymore ? From: Atsushi Nemoto In-Reply-To: References: 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 3.3 on Emacs 21.3 / 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: 13282 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 Fri, 1 Dec 2006 10:40:52 +0100, "Franck Bui-Huu" wrote: > Now it seems that __do_IRQ() is not needed anymore. I dunno if it's > true for all platforms though. Does something like this make sense for > example ? > > -- >8 -- > diff --git a/arch/mips/Kconfig b/arch/mips/Kconfig > index 5ff94e5..a4c5306 100644 > --- a/arch/mips/Kconfig > +++ b/arch/mips/Kconfig > @@ -913,8 +913,13 @@ config SYS_SUPPORTS_BIG_ENDIAN > config SYS_SUPPORTS_LITTLE_ENDIAN > bool > > +config GENERIC_HARDIRQS_NO__DO_IRQ > + bool > + default n > + No, there are irq chips still need __do_IRQ(). Please grep 'set_irq_chip('. If _all_ irq chip were converted to use flow handler, GENERIC_HARDIRQS_NO__DO_IRQ will be good. But we have i8259... --- Atsushi Nemoto From vagabon.xyz@gmail.com Fri Dec 1 10:06:46 2006 Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 01 Dec 2006 10:06:50 +0000 (GMT) Received: from ug-out-1314.google.com ([66.249.92.169]:47267 "EHLO ug-out-1314.google.com") by ftp.linux-mips.org with ESMTP id S20037863AbWLAKGq (ORCPT ); Fri, 1 Dec 2006 10:06:46 +0000 Received: by ug-out-1314.google.com with SMTP id 40so2566123uga for ; Fri, 01 Dec 2006 02:06:45 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=UTWwr7qVzA//Fkw7I98lElC4TW82CbAbgR7isMY75OB+w8ripAjP8NvxulQy0jgoAIgn8276FlTW/Vohsyb+ZbBMdoRYroXTapdOzXhg6vlnzbmTtf6E1WkDOzCfsPfep9TGjcqM34HjtNee/fgPI0BBaWnQtjqqT1cZBHBjDSQ= Received: by 10.78.201.2 with SMTP id y2mr4626608huf.1164967604951; Fri, 01 Dec 2006 02:06:44 -0800 (PST) Received: by 10.78.124.19 with HTTP; Fri, 1 Dec 2006 02:06:44 -0800 (PST) Message-ID: Date: Fri, 1 Dec 2006 11:06:44 +0100 From: "Franck Bui-Huu" To: "Atsushi Nemoto" Subject: Re: Is _do_IRQ() not needed anymore ? Cc: linux-mips@linux-mips.org In-Reply-To: <20061201.185740.03976990.nemoto@toshiba-tops.co.jp> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <20061201.185740.03976990.nemoto@toshiba-tops.co.jp> 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: 13283 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 On 12/1/06, Atsushi Nemoto wrote: > No, there are irq chips still need __do_IRQ(). Please grep > 'set_irq_chip('. > > If _all_ irq chip were converted to use flow handler, > GENERIC_HARDIRQS_NO__DO_IRQ will be good. But we have i8259... That's why in my example I made GENERIC_HARDIRQS_NO__DO_IRQ config default to 'n' and selected by a irq chip that doens't use __do_IRQ() anymore, well I think... -- Franck From anemo@mba.ocn.ne.jp Fri Dec 1 10:10:53 2006 Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 01 Dec 2006 10:10:57 +0000 (GMT) Received: from topsns2.toshiba-tops.co.jp ([202.230.225.126]:7215 "EHLO topsns2.toshiba-tops.co.jp") by ftp.linux-mips.org with ESMTP id S20037863AbWLAKKx (ORCPT ); Fri, 1 Dec 2006 10:10:53 +0000 Received: from topsms.toshiba-tops.co.jp by topsns2.toshiba-tops.co.jp via smtpd (for ftp.linux-mips.org [194.74.144.162]) with ESMTP; Fri, 1 Dec 2006 19:10:52 +0900 Received: from topsms.toshiba-tops.co.jp (localhost.localdomain [127.0.0.1]) by localhost.toshiba-tops.co.jp (Postfix) with ESMTP id 2A0D2417B2; Fri, 1 Dec 2006 19:10:50 +0900 (JST) Received: from srd2sd.toshiba-tops.co.jp (srd2sd.toshiba-tops.co.jp [172.17.28.2]) by topsms.toshiba-tops.co.jp (Postfix) with ESMTP id 1BEF61F537; Fri, 1 Dec 2006 19:10:50 +0900 (JST) Received: from localhost (fragile [172.17.28.65]) by srd2sd.toshiba-tops.co.jp (8.12.10/8.12.10) with ESMTP id kB1AAnW0064682; Fri, 1 Dec 2006 19:10:49 +0900 (JST) (envelope-from anemo@mba.ocn.ne.jp) Date: Fri, 01 Dec 2006 19:10:49 +0900 (JST) Message-Id: <20061201.191049.63741937.nemoto@toshiba-tops.co.jp> To: vagabon.xyz@gmail.com Cc: linux-mips@linux-mips.org Subject: Re: Is _do_IRQ() not needed anymore ? From: Atsushi Nemoto In-Reply-To: References: <20061201.185740.03976990.nemoto@toshiba-tops.co.jp> 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 3.3 on Emacs 21.3 / 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: 13284 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 Fri, 1 Dec 2006 11:06:44 +0100, "Franck Bui-Huu" wrote: > > If _all_ irq chip were converted to use flow handler, > > GENERIC_HARDIRQS_NO__DO_IRQ will be good. But we have i8259... > > That's why in my example I made GENERIC_HARDIRQS_NO__DO_IRQ config > default to 'n' and selected by a irq chip that doens't use __do_IRQ() > anymore, well I think... You can use both irq_cpu and i8259 same time. :) --- Atsushi Nemoto From vagabon.xyz@gmail.com Fri Dec 1 10:19:35 2006 Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 01 Dec 2006 10:19:40 +0000 (GMT) Received: from ug-out-1314.google.com ([66.249.92.174]:15324 "EHLO ug-out-1314.google.com") by ftp.linux-mips.org with ESMTP id S20037861AbWLAKTf (ORCPT ); Fri, 1 Dec 2006 10:19:35 +0000 Received: by ug-out-1314.google.com with SMTP id 40so2568997uga for ; Fri, 01 Dec 2006 02:19:35 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=b8XbmV27V8DNGeeoN4tB3lu2Z2RD53fzWn/cHEc2MkPN+RyJ/nEqFCO08tMR/TR+B7r/sjtH6JOfM/GKbBQ9pgnNETEWzvDPo4w2b4JXROcw70f6hPusY0IatcgulJT8Z0U6qhdC5bCRJ+fkW/ezyPJhn1DSp1EZHIsz/9KAibA= Received: by 10.78.204.20 with SMTP id b20mr4669601hug.1164968374207; Fri, 01 Dec 2006 02:19:34 -0800 (PST) Received: by 10.78.124.19 with HTTP; Fri, 1 Dec 2006 02:19:34 -0800 (PST) Message-ID: Date: Fri, 1 Dec 2006 11:19:34 +0100 From: "Franck Bui-Huu" To: "Atsushi Nemoto" Subject: Re: Is _do_IRQ() not needed anymore ? Cc: linux-mips@linux-mips.org In-Reply-To: <20061201.191049.63741937.nemoto@toshiba-tops.co.jp> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <20061201.185740.03976990.nemoto@toshiba-tops.co.jp> <20061201.191049.63741937.nemoto@toshiba-tops.co.jp> 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: 13285 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 On 12/1/06, Atsushi Nemoto wrote: > On Fri, 1 Dec 2006 11:06:44 +0100, "Franck Bui-Huu" wrote: > > > If _all_ irq chip were converted to use flow handler, > > > GENERIC_HARDIRQS_NO__DO_IRQ will be good. But we have i8259... > > > > That's why in my example I made GENERIC_HARDIRQS_NO__DO_IRQ config > > default to 'n' and selected by a irq chip that doens't use __do_IRQ() > > anymore, well I think... > > You can use both irq_cpu and i8259 same time. :) > ok bad example. Why not making the select thing part of the platform config like this ? diff --git a/arch/mips/Kconfig b/arch/mips/Kconfig index 5ff94e5..8565533 100644 --- a/arch/mips/Kconfig +++ b/arch/mips/Kconfig @@ -233,6 +233,7 @@ config LASAT select SYS_SUPPORTS_32BIT_KERNEL select SYS_SUPPORTS_64BIT_KERNEL if EXPERIMENTAL select SYS_SUPPORTS_LITTLE_ENDIAN + select GENERIC_HARDIRQS_NO__DO_IRQ config MIPS_ATLAS bool "MIPS Atlas board" @@ -913,6 +914,10 @@ config SYS_SUPPORTS_BIG_ENDIAN config SYS_SUPPORTS_LITTLE_ENDIAN bool +config GENERIC_HARDIRQS_NO__DO_IRQ + bool + default n + config IRQ_CPU bool -- Franck From anemo@mba.ocn.ne.jp Fri Dec 1 10:41:06 2006 Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 01 Dec 2006 10:41:10 +0000 (GMT) Received: from topsns2.toshiba-tops.co.jp ([202.230.225.126]:56417 "EHLO topsns2.toshiba-tops.co.jp") by ftp.linux-mips.org with ESMTP id S20037860AbWLAKlG (ORCPT ); Fri, 1 Dec 2006 10:41:06 +0000 Received: from topsms.toshiba-tops.co.jp by topsns2.toshiba-tops.co.jp via smtpd (for ftp.linux-mips.org [194.74.144.162]) with ESMTP; Fri, 1 Dec 2006 19:41:04 +0900 Received: from topsms.toshiba-tops.co.jp (localhost.localdomain [127.0.0.1]) by localhost.toshiba-tops.co.jp (Postfix) with ESMTP id DD2D53EEA7; Fri, 1 Dec 2006 19:41:02 +0900 (JST) Received: from srd2sd.toshiba-tops.co.jp (srd2sd.toshiba-tops.co.jp [172.17.28.2]) by topsms.toshiba-tops.co.jp (Postfix) with ESMTP id CAACA20403; Fri, 1 Dec 2006 19:41:02 +0900 (JST) Received: from localhost (fragile [172.17.28.65]) by srd2sd.toshiba-tops.co.jp (8.12.10/8.12.10) with ESMTP id kB1Af2W0064777; Fri, 1 Dec 2006 19:41:02 +0900 (JST) (envelope-from anemo@mba.ocn.ne.jp) Date: Fri, 01 Dec 2006 19:41:02 +0900 (JST) Message-Id: <20061201.194102.89066483.nemoto@toshiba-tops.co.jp> To: vagabon.xyz@gmail.com Cc: linux-mips@linux-mips.org Subject: Re: Is _do_IRQ() not needed anymore ? From: Atsushi Nemoto In-Reply-To: References: <20061201.191049.63741937.nemoto@toshiba-tops.co.jp> 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 3.3 on Emacs 21.3 / 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: 13286 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 Fri, 1 Dec 2006 11:19:34 +0100, "Franck Bui-Huu" wrote: > ok bad example. Why not making the select thing part of the platform > config like this ? > > diff --git a/arch/mips/Kconfig b/arch/mips/Kconfig > index 5ff94e5..8565533 100644 > --- a/arch/mips/Kconfig > +++ b/arch/mips/Kconfig > @@ -233,6 +233,7 @@ config LASAT > select SYS_SUPPORTS_32BIT_KERNEL > select SYS_SUPPORTS_64BIT_KERNEL if EXPERIMENTAL > select SYS_SUPPORTS_LITTLE_ENDIAN > + select GENERIC_HARDIRQS_NO__DO_IRQ > > config MIPS_ATLAS > bool "MIPS Atlas board" > @@ -913,6 +914,10 @@ config SYS_SUPPORTS_BIG_ENDIAN > config SYS_SUPPORTS_LITTLE_ENDIAN > bool > > +config GENERIC_HARDIRQS_NO__DO_IRQ > + bool > + default n > + > config IRQ_CPU > bool This looks good for me. Also, if you selected GENERIC_HARDIRQS_NO__DO_IRQ, you can remove .end handler. But adding "#ifdef GENERIC_HARDIRQS_NO__DO_IRQ" for each .end might be slightly ugly... --- Atsushi Nemoto From vagabon.xyz@gmail.com Fri Dec 1 11:03:55 2006 Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 01 Dec 2006 11:03:56 +0000 (GMT) Received: from ug-out-1314.google.com ([66.249.92.170]:14008 "EHLO ug-out-1314.google.com") by ftp.linux-mips.org with ESMTP id S20037868AbWLALDz (ORCPT ); Fri, 1 Dec 2006 11:03:55 +0000 Received: by ug-out-1314.google.com with SMTP id 40so2580110uga for ; Fri, 01 Dec 2006 03:03:54 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=r27rTY33VktGd72AYvDQ9VKenKKzqUtLuy5GgMyd0XjsdsqGyQDCZx2uP4SSojFr5O3w8vpSqX9p7lAFll8Fe7xMikyjO928EbL+Lbl+Hlc3kTkXsYoHxaAixtNbV0Ei09l2xB/4YubcVoSkz5AdkX/tTC5MgsZm4S399Q18Gdk= Received: by 10.78.185.7 with SMTP id i7mr4679654huf.1164971034538; Fri, 01 Dec 2006 03:03:54 -0800 (PST) Received: by 10.78.124.19 with HTTP; Fri, 1 Dec 2006 03:03:54 -0800 (PST) Message-ID: Date: Fri, 1 Dec 2006 12:03:54 +0100 From: "Franck Bui-Huu" To: "Atsushi Nemoto" Subject: Re: Is _do_IRQ() not needed anymore ? Cc: linux-mips@linux-mips.org In-Reply-To: <20061201.194102.89066483.nemoto@toshiba-tops.co.jp> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <20061201.191049.63741937.nemoto@toshiba-tops.co.jp> <20061201.194102.89066483.nemoto@toshiba-tops.co.jp> 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: 13287 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 On 12/1/06, Atsushi Nemoto wrote: > > Also, if you selected GENERIC_HARDIRQS_NO__DO_IRQ, you can remove .end > handler. But adding "#ifdef GENERIC_HARDIRQS_NO__DO_IRQ" for each > .end might be slightly ugly... > why not simply removing it since it won't be used anymore ? -- Franck From vagabon.xyz@gmail.com Fri Dec 1 11:12:23 2006 Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 01 Dec 2006 11:12:27 +0000 (GMT) Received: from ug-out-1314.google.com ([66.249.92.172]:61919 "EHLO ug-out-1314.google.com") by ftp.linux-mips.org with ESMTP id S20037868AbWLALMX (ORCPT ); Fri, 1 Dec 2006 11:12:23 +0000 Received: by ug-out-1314.google.com with SMTP id 40so2582156uga for ; Fri, 01 Dec 2006 03:12:22 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=hh4qMNW+Cgkh4514GIaQhWqSn4RiDrunrDMfsgNKSczjALBJdMznBie8RI6zdc6W1lBiq1mbw605ftM7uGcGbHgvqxh7OczSuDAvGaXkLD9mJBr8xmt0AMgc7KDDBMLS1N/lCoeRmeQj8yYHI3lLOCImvYhWmQgXb9E73cGfMGQ= Received: by 10.78.166.7 with SMTP id o7mr4716677hue.1164971542386; Fri, 01 Dec 2006 03:12:22 -0800 (PST) Received: by 10.78.124.19 with HTTP; Fri, 1 Dec 2006 03:12:22 -0800 (PST) Message-ID: Date: Fri, 1 Dec 2006 12:12:22 +0100 From: "Franck Bui-Huu" To: "Atsushi Nemoto" Subject: Re: Is _do_IRQ() not needed anymore ? Cc: linux-mips@linux-mips.org In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <20061201.191049.63741937.nemoto@toshiba-tops.co.jp> <20061201.194102.89066483.nemoto@toshiba-tops.co.jp> 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: 13288 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 On 12/1/06, Franck Bui-Huu wrote: > On 12/1/06, Atsushi Nemoto wrote: > > > > Also, if you selected GENERIC_HARDIRQS_NO__DO_IRQ, you can remove .end > > handler. But adding "#ifdef GENERIC_HARDIRQS_NO__DO_IRQ" for each > > .end might be slightly ugly... > > > > why not simply removing it since it won't be used anymore ? > oops sorry I take it back, I already forgot my first wrong assumption... -- Franck From anemo@mba.ocn.ne.jp Fri Dec 1 11:12:55 2006 Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 01 Dec 2006 11:12:59 +0000 (GMT) Received: from topsns2.toshiba-tops.co.jp ([202.230.225.126]:12182 "EHLO topsns2.toshiba-tops.co.jp") by ftp.linux-mips.org with ESMTP id S20037868AbWLALMz (ORCPT ); Fri, 1 Dec 2006 11:12:55 +0000 Received: from topsms.toshiba-tops.co.jp by topsns2.toshiba-tops.co.jp via smtpd (for ftp.linux-mips.org [194.74.144.162]) with ESMTP; Fri, 1 Dec 2006 20:12:54 +0900 Received: from topsms.toshiba-tops.co.jp (localhost.localdomain [127.0.0.1]) by localhost.toshiba-tops.co.jp (Postfix) with ESMTP id B026940022; Fri, 1 Dec 2006 20:12:52 +0900 (JST) Received: from srd2sd.toshiba-tops.co.jp (srd2sd.toshiba-tops.co.jp [172.17.28.2]) by topsms.toshiba-tops.co.jp (Postfix) with ESMTP id A5DC63EEA7; Fri, 1 Dec 2006 20:12:52 +0900 (JST) Received: from localhost (fragile [172.17.28.65]) by srd2sd.toshiba-tops.co.jp (8.12.10/8.12.10) with ESMTP id kB1BCqW0064892; Fri, 1 Dec 2006 20:12:52 +0900 (JST) (envelope-from anemo@mba.ocn.ne.jp) Date: Fri, 01 Dec 2006 20:12:52 +0900 (JST) Message-Id: <20061201.201252.18306502.nemoto@toshiba-tops.co.jp> To: vagabon.xyz@gmail.com Cc: linux-mips@linux-mips.org Subject: Re: Is _do_IRQ() not needed anymore ? From: Atsushi Nemoto In-Reply-To: References: <20061201.194102.89066483.nemoto@toshiba-tops.co.jp> 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 3.3 on Emacs 21.3 / 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: 13289 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 Fri, 1 Dec 2006 12:03:54 +0100, "Franck Bui-Huu" wrote: > > Also, if you selected GENERIC_HARDIRQS_NO__DO_IRQ, you can remove .end > > handler. But adding "#ifdef GENERIC_HARDIRQS_NO__DO_IRQ" for each > > .end might be slightly ugly... > > why not simply removing it since it won't be used anymore ? Indeed. If the irq chip was always used with flow handler we can remove it. --- Atsushi Nemoto From yoichi_yuasa@tripeaks.co.jp Fri Dec 1 13:21:07 2006 Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 01 Dec 2006 13:21:12 +0000 (GMT) Received: from mo31.po.2iij.net ([210.128.50.54]:18500 "EHLO mo31.po.2iij.net") by ftp.linux-mips.org with ESMTP id S28573702AbWLANVH (ORCPT ); Fri, 1 Dec 2006 13:21:07 +0000 Received: by mo.po.2iij.net (mo31) id kB1DL5YY030730; Fri, 1 Dec 2006 22:21:05 +0900 (JST) Received: from localhost.localdomain (133.25.30.125.dy.iij4u.or.jp [125.30.25.133]) by mbox.po.2iij.net (mbox32) id kB1DL2aR027760 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 1 Dec 2006 22:21:03 +0900 (JST) Date: Fri, 1 Dec 2006 22:17:46 +0900 From: Yoichi Yuasa To: Ralf Baechle Cc: yoichi_yuasa@tripeaks.co.jp, linux-mips Subject: [PATCH 3/5] MIPS: separate cobalt PCI codes from setup.c Message-Id: <20061201221746.1f45d98c.yoichi_yuasa@tripeaks.co.jp> In-Reply-To: <20061201221601.3aa34024.yoichi_yuasa@tripeaks.co.jp> References: <20061201221242.261f57b0.yoichi_yuasa@tripeaks.co.jp> <20061201221601.3aa34024.yoichi_yuasa@tripeaks.co.jp> Organization: TriPeaks Corporation X-Mailer: Sylpheed version 1.0.6 (GTK+ 1.2.10; 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: 13290 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 patch has separated cobalt PCI codes from setup.c . It's removed #ifdef CONFIG_PCI/#endif from cobalt setup.c . Yoichi 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 2006-10-12 10:19:25.000465500 +0900 +++ mips/arch/mips/cobalt/Makefile 2006-10-12 10:19:58.502559250 +0900 @@ -4,6 +4,7 @@ obj-y := irq.o reset.o setup.o +obj-$(CONFIG_PCI) += pci.o obj-$(CONFIG_EARLY_PRINTK) += console.o EXTRA_AFLAGS := $(CFLAGS) diff -pruN -X mips/Documentation/dontdiff mips-orig/arch/mips/cobalt/pci.c mips/arch/mips/cobalt/pci.c --- mips-orig/arch/mips/cobalt/pci.c 1970-01-01 09:00:00.000000000 +0900 +++ mips/arch/mips/cobalt/pci.c 2006-10-12 10:19:58.502559250 +0900 @@ -0,0 +1,47 @@ +/* + * Register PCI controller. + * + * 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) 1996, 1997, 2004, 05 by Ralf Baechle (ralf@linux-mips.org) + * Copyright (C) 2001, 2002, 2003 by Liam Davies (ldavies@agile.tv) + * + */ +#include +#include + +#include + +extern struct pci_ops gt64111_pci_ops; + +static struct resource cobalt_mem_resource = { + .start = GT_DEF_PCI0_MEM0_BASE, + .end = GT_DEF_PCI0_MEM0_BASE + GT_DEF_PCI0_MEM0_SIZE - 1, + .name = "PCI memory", + .flags = IORESOURCE_MEM, +}; + +static struct resource cobalt_io_resource = { + .start = 0x1000, + .end = 0xffff, + .name = "PCI I/O", + .flags = IORESOURCE_IO, +}; + +static struct pci_controller cobalt_pci_controller = { + .pci_ops = >64111_pci_ops, + .mem_resource = &cobalt_mem_resource, + .io_resource = &cobalt_io_resource, + .io_offset = 0 - GT_DEF_PCI0_IO_BASE, +}; + +static int __init cobalt_pci_init(void) +{ + register_pci_controller(&cobalt_pci_controller); + + return 0; +} + +arch_initcall(cobalt_pci_init); 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 2006-10-12 10:20:53.049968250 +0900 +++ mips/arch/mips/cobalt/setup.c 2006-10-12 10:22:31.464118750 +0900 @@ -63,22 +63,6 @@ void __init plat_timer_setup(struct irqa GT_WRITE(GT_INTRMASK_OFS, GT_INTR_T0EXP_MSK | GT_READ(GT_INTRMASK_OFS)); } -extern struct pci_ops gt64111_pci_ops; - -static struct resource cobalt_mem_resource = { - .start = GT_DEF_PCI0_MEM0_BASE, - .end = GT_DEF_PCI0_MEM0_BASE + GT_DEF_PCI0_MEM0_SIZE - 1, - .name = "PCI memory", - .flags = IORESOURCE_MEM -}; - -static struct resource cobalt_io_resource = { - .start = 0x1000, - .end = 0xffff, - .name = "PCI I/O", - .flags = IORESOURCE_IO -}; - /* * Cobalt doesn't have PS/2 keyboard/mouse interfaces, * keyboard conntroller is never used. @@ -92,14 +76,6 @@ static struct resource cobalt_reserved_r }, }; -static struct pci_controller cobalt_pci_controller = { - .pci_ops = >64111_pci_ops, - .mem_resource = &cobalt_mem_resource, - .mem_offset = 0, - .io_resource = &cobalt_io_resource, - .io_offset = 0 - GT_DEF_PCI0_IO_BASE, -}; - void __init plat_mem_setup(void) { static struct uart_port uart; @@ -126,10 +102,6 @@ void __init plat_mem_setup(void) printk("Cobalt board ID: %d\n", cobalt_board_id); -#ifdef CONFIG_PCI - register_pci_controller(&cobalt_pci_controller); -#endif - if (cobalt_board_id > COBALT_BRD_ID_RAQ1) { #ifdef CONFIG_EARLY_PRINTK cobalt_early_console(); From yoichi_yuasa@tripeaks.co.jp Fri Dec 1 13:21:36 2006 Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 01 Dec 2006 13:21:39 +0000 (GMT) Received: from mo32.po.2iij.net ([210.128.50.17]:41794 "EHLO mo32.po.2iij.net") by ftp.linux-mips.org with ESMTP id S28573729AbWLANVH (ORCPT ); Fri, 1 Dec 2006 13:21:07 +0000 Received: by mo.po.2iij.net (mo32) id kB1DL4YY000110; Fri, 1 Dec 2006 22:21:04 +0900 (JST) Received: from localhost.localdomain (133.25.30.125.dy.iij4u.or.jp [125.30.25.133]) by mbox.po.2iij.net (mbox32) id kB1DL03P027729 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 1 Dec 2006 22:21:00 +0900 (JST) Date: Fri, 1 Dec 2006 22:12:42 +0900 From: Yoichi Yuasa To: Ralf Baechle Cc: yoichi_yuasa@tripeaks.co.jp, linux-mips Subject: [PATCH 1/5] MIPS: fix cobalt I/O resource range Message-Id: <20061201221242.261f57b0.yoichi_yuasa@tripeaks.co.jp> Organization: TriPeaks Corporation X-Mailer: Sylpheed version 1.0.6 (GTK+ 1.2.10; 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: 13291 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 patch has fixed cobalt I/O reource range. The cobalt real I/O resource range from 0x0 to 0xffff. Yoichi Signed-off-by: Yoichi Yuasa 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 2006-10-12 01:03:18.055569000 +0900 +++ mips/arch/mips/cobalt/setup.c 2006-10-12 01:01:59.973744750 +0900 @@ -130,8 +130,7 @@ void __init plat_mem_setup(void) set_io_port_base(CKSEG1ADDR(GT_DEF_PCI0_IO_BASE)); - /* I/O port resource must include UART and LCD/buttons */ - ioport_resource.end = 0x0fffffff; + ioport_resource.end = 0xffff; /* request I/O space for devices used on all i[345]86 PCs */ for (i = 0; i < COBALT_IO_RESOURCES; i++) @@ -149,24 +148,24 @@ void __init plat_mem_setup(void) register_pci_controller(&cobalt_pci_controller); #endif -#ifdef CONFIG_SERIAL_8250 if (cobalt_board_id > COBALT_BRD_ID_RAQ1) { - #ifdef CONFIG_EARLY_PRINTK cobalt_early_console(); #endif +#ifdef CONFIG_SERIAL_8250 uart.line = 0; uart.type = PORT_UNKNOWN; uart.uartclk = 18432000; uart.irq = COBALT_SERIAL_IRQ; - uart.flags = UPF_BOOT_AUTOCONF | UPF_SKIP_TEST; - uart.iobase = 0xc800000; - uart.iotype = UPIO_PORT; + uart.flags = UPF_IOREMAP | UPF_BOOT_AUTOCONF | + UPF_SKIP_TEST; + uart.iotype = UPIO_MEM; + uart.mapbase = 0x1c800000; early_serial_setup(&uart); - } #endif + } } /* From yoichi_yuasa@tripeaks.co.jp Fri Dec 1 13:22:03 2006 Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 01 Dec 2006 13:22:08 +0000 (GMT) Received: from mo31.po.2iij.net ([210.128.50.54]:7468 "EHLO mo31.po.2iij.net") by ftp.linux-mips.org with ESMTP id S28573724AbWLANVH (ORCPT ); Fri, 1 Dec 2006 13:21:07 +0000 Received: by mo.po.2iij.net (mo31) id kB1DL46T030724; Fri, 1 Dec 2006 22:21:04 +0900 (JST) Received: from localhost.localdomain (133.25.30.125.dy.iij4u.or.jp [125.30.25.133]) by mbox.po.2iij.net (mbox32) id kB1DL16M027748 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 1 Dec 2006 22:21:01 +0900 (JST) Date: Fri, 1 Dec 2006 22:16:01 +0900 From: Yoichi Yuasa To: Ralf Baechle Cc: yoichi_yuasa@tripeaks.co.jp, linux-mips Subject: [PATCH 2/5] MIPS: remove unused resources for cobalt Message-Id: <20061201221601.3aa34024.yoichi_yuasa@tripeaks.co.jp> In-Reply-To: <20061201221242.261f57b0.yoichi_yuasa@tripeaks.co.jp> References: <20061201221242.261f57b0.yoichi_yuasa@tripeaks.co.jp> Organization: TriPeaks Corporation X-Mailer: Sylpheed version 1.0.6 (GTK+ 1.2.10; 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: 13292 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 patch has removed unused resources for cobalt. Yoichi Signed-off-by: Yoichi Yuasa 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 2006-10-12 01:03:59.401472250 +0900 +++ mips/arch/mips/cobalt/setup.c 2006-10-12 01:05:36.454992750 +0900 @@ -79,37 +79,19 @@ static struct resource cobalt_io_resourc .flags = IORESOURCE_IO }; -static struct resource cobalt_io_resources[] = { - { - .start = 0x00, - .end = 0x1f, - .name = "dma1", - .flags = IORESOURCE_BUSY - }, { - .start = 0x40, - .end = 0x5f, - .name = "timer", - .flags = IORESOURCE_BUSY - }, { +/* + * Cobalt doesn't have PS/2 keyboard/mouse interfaces, + * keyboard conntroller is never used. + */ +static struct resource cobalt_reserved_resources[] = { + { /* keyboard */ .start = 0x60, .end = 0x6f, - .name = "keyboard", - .flags = IORESOURCE_BUSY - }, { - .start = 0x80, - .end = 0x8f, - .name = "dma page reg", - .flags = IORESOURCE_BUSY - }, { - .start = 0xc0, - .end = 0xdf, - .name = "dma2", - .flags = IORESOURCE_BUSY + .name = "reserved", + .flags = IORESOURCE_BUSY, }, }; -#define COBALT_IO_RESOURCES (sizeof(cobalt_io_resources)/sizeof(struct resource)) - static struct pci_controller cobalt_pci_controller = { .pci_ops = >64111_pci_ops, .mem_resource = &cobalt_mem_resource, @@ -132,9 +114,9 @@ void __init plat_mem_setup(void) ioport_resource.end = 0xffff; - /* request I/O space for devices used on all i[345]86 PCs */ - for (i = 0; i < COBALT_IO_RESOURCES; i++) - request_resource(&ioport_resource, cobalt_io_resources + i); + /* These resources have been reserved by VIA SuperI/O chip. */ + for (i = 0; i < ARRAY_SIZE(cobalt_reserved_resources); i++) + request_resource(&ioport_resource, cobalt_reserved_resources + i); /* Read the cobalt id register out of the PCI config space */ PCI_CFG_SET(devfn, (VIA_COBALT_BRD_ID_REG & ~0x3)); From yoichi_yuasa@tripeaks.co.jp Fri Dec 1 13:22:31 2006 Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 01 Dec 2006 13:22:34 +0000 (GMT) Received: from mo31.po.2iij.net ([210.128.50.54]:11808 "EHLO mo31.po.2iij.net") by ftp.linux-mips.org with ESMTP id S28573732AbWLANVQ (ORCPT ); Fri, 1 Dec 2006 13:21:16 +0000 Received: by mo.po.2iij.net (mo31) id kB1DLEu9030758; Fri, 1 Dec 2006 22:21:14 +0900 (JST) Received: from localhost.localdomain (133.25.30.125.dy.iij4u.or.jp [125.30.25.133]) by mbox.po.2iij.net (mbox32) id kB1DL9pe027845 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 1 Dec 2006 22:21:09 +0900 (JST) Date: Fri, 1 Dec 2006 22:19:10 +0900 From: Yoichi Yuasa To: Ralf Baechle Cc: yoichi_yuasa@tripeaks.co.jp, linux-mips Subject: [PATCH 4/5] MIPS: update reset operations for cobalt Message-Id: <20061201221910.56cde68c.yoichi_yuasa@tripeaks.co.jp> In-Reply-To: <20061201221746.1f45d98c.yoichi_yuasa@tripeaks.co.jp> References: <20061201221242.261f57b0.yoichi_yuasa@tripeaks.co.jp> <20061201221601.3aa34024.yoichi_yuasa@tripeaks.co.jp> <20061201221746.1f45d98c.yoichi_yuasa@tripeaks.co.jp> Organization: TriPeaks Corporation X-Mailer: Sylpheed version 1.0.6 (GTK+ 1.2.10; 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: 13293 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 patch has updated reset operations for cobalt. Yoichi 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 2006-10-12 10:28:55.612126500 +0900 +++ mips/arch/mips/cobalt/reset.c 2006-10-12 10:32:39.698131000 +0900 @@ -8,17 +8,33 @@ * Copyright (C) 1995, 1996, 1997 by Ralf Baechle * Copyright (C) 2001 by Liam Davies (ldavies@agile.tv) */ -#include -#include -#include +#include +#include +#include + #include -#include #include -#include -#include -#include -void cobalt_machine_halt(void) +#define COBALT_LED_PORT (void __iomem *)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 \ + ((~readl((void __iomem *)CKSEG1ADDR(0x1d000000)) >> 24) & \ + COBALT_KEY_MASK) +# define COBALT_KEY_CLEAR (1 << 1) +# define COBALT_KEY_LEFT (1 << 2) +# define COBALT_KEY_UP (1 << 3) +# define COBALT_KEY_DOWN (1 << 4) +# define COBALT_KEY_RIGHT (1 << 5) +# define COBALT_KEY_ENTER (1 << 6) +# define COBALT_KEY_SELECT (1 << 7) +# define COBALT_KEY_MASK 0xfe + +static void cobalt_machine_halt(void) { int state, last, diff; unsigned long mark; @@ -34,22 +50,23 @@ void cobalt_machine_halt(void) for (state = 0;;) { state ^= COBALT_LED_POWER_OFF; - COBALT_LED_PORT = state; + writeb(state, COBALT_LED_PORT); diff = COBALT_KEY_PORT ^ last; last ^= diff; - if((diff & (COBALT_KEY_ENTER | COBALT_KEY_SELECT)) && !(~last & (COBALT_KEY_ENTER | COBALT_KEY_SELECT))) - COBALT_LED_PORT = COBALT_LED_RESET; + if((diff & (COBALT_KEY_ENTER | COBALT_KEY_SELECT)) && + !(~last & (COBALT_KEY_ENTER | COBALT_KEY_SELECT))) + writeb(COBALT_LED_RESET, COBALT_LED_PORT); for (mark = jiffies; jiffies - mark < HZ;) ; } } -void cobalt_machine_restart(char *command) +static void cobalt_machine_restart(char *command) { - COBALT_LED_PORT = COBALT_LED_RESET; + writeb(COBALT_LED_RESET, COBALT_LED_PORT); /* we should never get here */ cobalt_machine_halt(); @@ -58,8 +75,19 @@ void cobalt_machine_restart(char *comman /* * This triggers the luser mode device driver for the power switch ;-) */ -void cobalt_machine_power_off(void) +static void cobalt_machine_power_off(void) { printk("You can switch the machine off now.\n"); cobalt_machine_halt(); } + +static int __init cobalt_reset_init(void) +{ + _machine_restart = cobalt_machine_restart; + _machine_halt = cobalt_machine_halt; + pm_power_off = cobalt_machine_power_off; + + return 0; +} + +arch_initcall(cobalt_reset_init); 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 2006-10-12 10:32:51.726882750 +0900 +++ mips/arch/mips/cobalt/setup.c 2006-10-12 10:34:09.171722750 +0900 @@ -12,7 +12,6 @@ #include #include #include -#include #include #include @@ -21,14 +20,10 @@ #include #include #include -#include #include #include -extern void cobalt_machine_restart(char *command); -extern void cobalt_machine_halt(void); -extern void cobalt_machine_power_off(void); extern void cobalt_early_console(void); int cobalt_board_id; @@ -82,10 +77,6 @@ void __init plat_mem_setup(void) unsigned int devfn = PCI_DEVFN(COBALT_PCICONF_VIA, 0); int i; - _machine_restart = cobalt_machine_restart; - _machine_halt = cobalt_machine_halt; - pm_power_off = cobalt_machine_power_off; - set_io_port_base(CKSEG1ADDR(GT_DEF_PCI0_IO_BASE)); ioport_resource.end = 0xffff; 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 2006-10-12 10:32:50.006775250 +0900 +++ mips/include/asm-mips/mach-cobalt/cobalt.h 2006-10-12 10:32:39.698131000 +0900 @@ -71,23 +71,6 @@ GT_WRITE(GT_PCI0_CFGADDR_OFS, (0x80000000 | (PCI_SLOT (devfn) << 11) | \ (PCI_FUNC (devfn) << 8) | (where))) -#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) -# define COBALT_KEY_UP (1 << 3) -# define COBALT_KEY_DOWN (1 << 4) -# define COBALT_KEY_RIGHT (1 << 5) -# define COBALT_KEY_ENTER (1 << 6) -# define COBALT_KEY_SELECT (1 << 7) -# define COBALT_KEY_MASK 0xfe - #define COBALT_UART ((volatile unsigned char *) CKSEG1ADDR(0x1c800000)) #endif /* __ASM_COBALT_H */ From yoichi_yuasa@tripeaks.co.jp Fri Dec 1 13:22:58 2006 Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 01 Dec 2006 13:23:04 +0000 (GMT) Received: from mo31.po.2iij.net ([210.128.50.54]:279 "EHLO mo31.po.2iij.net") by ftp.linux-mips.org with ESMTP id S28573733AbWLANVQ (ORCPT ); Fri, 1 Dec 2006 13:21:16 +0000 Received: by mo.po.2iij.net (mo31) id kB1DLEuB030758; Fri, 1 Dec 2006 22:21:14 +0900 (JST) Received: from localhost.localdomain (133.25.30.125.dy.iij4u.or.jp [125.30.25.133]) by mbox.po.2iij.net (mbox32) id kB1DLA84027868 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 1 Dec 2006 22:21:10 +0900 (JST) Date: Fri, 1 Dec 2006 22:20:21 +0900 From: Yoichi Yuasa To: Ralf Baechle Cc: yoichi_yuasa@tripeaks.co.jp, linux-mips Subject: [PATCH 5/5] MIPS: clean up include files for cobalt Message-Id: <20061201222021.7be0fae6.yoichi_yuasa@tripeaks.co.jp> In-Reply-To: <20061201221910.56cde68c.yoichi_yuasa@tripeaks.co.jp> References: <20061201221242.261f57b0.yoichi_yuasa@tripeaks.co.jp> <20061201221601.3aa34024.yoichi_yuasa@tripeaks.co.jp> <20061201221746.1f45d98c.yoichi_yuasa@tripeaks.co.jp> <20061201221910.56cde68c.yoichi_yuasa@tripeaks.co.jp> Organization: TriPeaks Corporation X-Mailer: Sylpheed version 1.0.6 (GTK+ 1.2.10; 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: 13294 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 patch has cleaned up include files for cobalt. Yoichi 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 2006-10-12 11:44:59.727188000 +0900 +++ mips/arch/mips/cobalt/console.c 2006-10-12 11:53:43.203903250 +0900 @@ -7,7 +7,7 @@ #include #include #include -#include +#include static void putchar(int c) { diff -pruN -X mips/Documentation/dontdiff mips-orig/arch/mips/cobalt/irq.c mips/arch/mips/cobalt/irq.c --- mips-orig/arch/mips/cobalt/irq.c 2006-10-12 11:49:45.137025000 +0900 +++ mips/arch/mips/cobalt/irq.c 2006-10-12 11:53:26.330848750 +0900 @@ -17,7 +17,7 @@ #include #include -#include +#include /* * We have two types of interrupts that we handle, ones that come in through 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 2006-10-12 11:49:54.681621500 +0900 +++ mips/arch/mips/cobalt/setup.c 2006-10-12 11:56:31.510421750 +0900 @@ -18,11 +18,9 @@ #include #include #include -#include -#include #include -#include +#include extern void cobalt_early_console(void); From vagabon.xyz@gmail.com Fri Dec 1 14:56:52 2006 Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 01 Dec 2006 14:56:59 +0000 (GMT) Received: from nf-out-0910.google.com ([64.233.182.191]:43488 "EHLO nf-out-0910.google.com") by ftp.linux-mips.org with ESMTP id S20037960AbWLAO4w (ORCPT ); Fri, 1 Dec 2006 14:56:52 +0000 Received: by nf-out-0910.google.com with SMTP id l24so3447314nfc for ; Fri, 01 Dec 2006 06:56:51 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:reply-to:user-agent:mime-version:to:cc:subject:content-type:content-transfer-encoding:from; b=dpbPpppK9T26RtBnz/2xIIlfbGUGTCEB2jsnf2mXerwfkuclT+FyCkTYwQ2mCKRBNGrVuFbwperpmj72iZhhzczxmT0sEMqQrcBAePPB1MdZutElRXuP/1mG3kWffxmq9lE/nPN9dbsEfYPj7SDKPnKjlbylSDRdxYxUhv4FTvg= Received: by 10.48.202.19 with SMTP id z19mr9344267nff.1164985011258; Fri, 01 Dec 2006 06:56:51 -0800 (PST) Received: from ?192.168.0.24? ( [81.252.61.1]) by mx.google.com with ESMTP id d2sm37205612nfe.2006.12.01.06.56.49; Fri, 01 Dec 2006 06:56:50 -0800 (PST) Message-ID: <457042FF.2060908@innova-card.com> Date: Fri, 01 Dec 2006 15:58:07 +0100 Reply-To: Franck User-Agent: Thunderbird 1.5.0.4 (X11/20060614) MIME-Version: 1.0 To: Ralf Baechle CC: Atsushi Nemoto , linux-mips Subject: [PATCH] Compile __do_IRQ() when really needed Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit From: Franck Bui-Huu 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: 13295 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 From: Franck Bui-Huu __do_IRQ() is needed only by irq handlers that can't use default handler defined in kernel/irq/chip.c. For others platforms there's no need to compile this function since it won't be used. For those platforms this patch defines GENERIC_HARDIRQS_NO__DO_IRQ symbol which is used exactly for this purpose. Futhermore for platforms which do not use __do_IRQ(), end() method which is part of the 'irq_chip' structure is not used. This patch simply removes this method in this case. Signed-off-by: Franck Bui-Huu --- Eyeballs from people impacted by this patch are greatly appreciated. Thanks. arch/mips/Kconfig | 16 +++++++++++ arch/mips/dec/ioasic-irq.c | 15 ---------- arch/mips/dec/kn02-irq.c | 7 ----- arch/mips/emma2rh/common/irq_emma2rh.c | 7 ----- arch/mips/emma2rh/markeins/irq_markeins.c | 7 ----- arch/mips/jazz/irq.c | 7 ----- arch/mips/kernel/irq-mv6434x.c | 10 ------- arch/mips/kernel/irq-rm7000.c | 7 ----- arch/mips/kernel/irq-rm9000.c | 8 ----- arch/mips/kernel/irq_cpu.c | 7 ----- arch/mips/lasat/interrupt.c | 7 ----- arch/mips/momentum/ocelot_c/cpci-irq.c | 10 ------- arch/mips/momentum/ocelot_c/uart-irq.c | 10 ------- arch/mips/philips/pnx8550/common/int.c | 8 ----- arch/mips/sgi-ip22/ip22-int.c | 28 -------------------- arch/mips/sgi-ip27/ip27-irq.c | 8 ----- arch/mips/sgi-ip27/ip27-timer.c | 5 --- arch/mips/tx4927/common/tx4927_irq.c | 22 --------------- .../tx4927/toshiba_rbtx4927/toshiba_rbtx4927_irq.c | 19 ------------- arch/mips/tx4938/common/irq.c | 20 -------------- arch/mips/tx4938/toshiba_rbtx4938/irq.c | 10 ------- arch/mips/vr41xx/common/icu.c | 14 ---------- 22 files changed, 16 insertions(+), 236 deletions(-) diff --git a/arch/mips/Kconfig b/arch/mips/Kconfig index 5ff94e5..249660a 100644 --- a/arch/mips/Kconfig +++ b/arch/mips/Kconfig @@ -171,6 +171,7 @@ config MACH_DECSTATION select SYS_SUPPORTS_128HZ select SYS_SUPPORTS_256HZ select SYS_SUPPORTS_1024HZ + select GENERIC_HARDIRQS_NO__DO_IRQ help This enables support for DEC's MIPS based workstations. For details see the Linux/MIPS FAQ on and the @@ -216,6 +217,7 @@ config MACH_JAZZ select SYS_SUPPORTS_32BIT_KERNEL select SYS_SUPPORTS_64BIT_KERNEL if EXPERIMENTAL select SYS_SUPPORTS_100HZ + select GENERIC_HARDIRQS_NO__DO_IRQ help This a family of machines based on the MIPS R4030 chipset which was used by several vendors to build RISC/os and Windows NT workstations. @@ -233,6 +235,7 @@ config LASAT select SYS_SUPPORTS_32BIT_KERNEL select SYS_SUPPORTS_64BIT_KERNEL if EXPERIMENTAL select SYS_SUPPORTS_LITTLE_ENDIAN + select GENERIC_HARDIRQS_NO__DO_IRQ config MIPS_ATLAS bool "MIPS Atlas board" @@ -256,6 +259,7 @@ config MIPS_ATLAS select SYS_SUPPORTS_BIG_ENDIAN select SYS_SUPPORTS_LITTLE_ENDIAN select SYS_SUPPORTS_MULTITHREADING if EXPERIMENTAL + select GENERIC_HARDIRQS_NO__DO_IRQ help This enables support for the MIPS Technologies Atlas evaluation board. @@ -410,6 +414,7 @@ config MOMENCO_OCELOT_C select SYS_SUPPORTS_32BIT_KERNEL select SYS_SUPPORTS_64BIT_KERNEL select SYS_SUPPORTS_BIG_ENDIAN + select GENERIC_HARDIRQS_NO__DO_IRQ help The Ocelot is a MIPS-based Single Board Computer (SBC) made by Momentum Computer . @@ -468,6 +473,7 @@ config DDB5477 config MACH_VR41XX bool "NEC VR41XX-based machines" select SYS_HAS_CPU_VR41XX + select GENERIC_HARDIRQS_NO__DO_IRQ config PMC_YOSEMITE bool "PMC-Sierra Yosemite eval board" @@ -519,6 +525,7 @@ config MARKEINS select SYS_SUPPORTS_BIG_ENDIAN select SYS_SUPPORTS_LITTLE_ENDIAN select SYS_HAS_CPU_R5000 + select GENERIC_HARDIRQS_NO__DO_IRQ help This enables support for the R5432-based NEC Mark-eins boards with R5500 CPU. @@ -539,6 +546,7 @@ config SGI_IP22 select SYS_SUPPORTS_32BIT_KERNEL select SYS_SUPPORTS_64BIT_KERNEL select SYS_SUPPORTS_BIG_ENDIAN + select GENERIC_HARDIRQS_NO__DO_IRQ help This are the SGI Indy, Challenge S and Indigo2, as well as certain OEM variants like the Tandem CMN B006S. To compile a Linux kernel @@ -558,6 +566,7 @@ config SGI_IP27 select SYS_SUPPORTS_BIG_ENDIAN select SYS_SUPPORTS_NUMA select SYS_SUPPORTS_SMP + select GENERIC_HARDIRQS_NO__DO_IRQ help This are the SGI Origin 200, Origin 2000 and Onyx 2 Graphics workstations. To compile a Linux kernel that runs on these, say Y @@ -739,6 +748,7 @@ config TOSHIBA_RBTX4927 select SYS_SUPPORTS_64BIT_KERNEL select SYS_SUPPORTS_BIG_ENDIAN select TOSHIBA_BOARDS + select GENERIC_HARDIRQS_NO__DO_IRQ help This Toshiba board is based on the TX4927 processor. Say Y here to support this machine type @@ -758,6 +768,7 @@ config TOSHIBA_RBTX4938 select SYS_SUPPORTS_LITTLE_ENDIAN select SYS_SUPPORTS_BIG_ENDIAN select TOSHIBA_BOARDS + select GENERIC_HARDIRQS_NO__DO_IRQ help This Toshiba board is based on the TX4938 processor. Say Y here to support this machine type @@ -824,6 +835,10 @@ config SCHED_NO_NO_OMIT_FRAME_POINTER bool default y +config GENERIC_HARDIRQS_NO__DO_IRQ + bool + default n + # # Select some configuration options automatically based on user selections. # @@ -985,6 +1000,7 @@ config SOC_PNX8550 select HW_HAS_PCI select SYS_HAS_CPU_MIPS32_R1 select SYS_SUPPORTS_32BIT_KERNEL + select GENERIC_HARDIRQS_NO__DO_IRQ config SWAP_IO_SPACE bool diff --git a/arch/mips/dec/ioasic-irq.c b/arch/mips/dec/ioasic-irq.c index 269b22b..c5248a1 100644 --- a/arch/mips/dec/ioasic-irq.c +++ b/arch/mips/dec/ioasic-irq.c @@ -55,19 +55,12 @@ static inline void ack_ioasic_irq(unsign fast_iob(); } -static inline void end_ioasic_irq(unsigned int irq) -{ - if (!(irq_desc[irq].status & (IRQ_DISABLED | IRQ_INPROGRESS))) - unmask_ioasic_irq(irq); -} - static struct irq_chip ioasic_irq_type = { .typename = "IO-ASIC", .ack = ack_ioasic_irq, .mask = mask_ioasic_irq, .mask_ack = ack_ioasic_irq, .unmask = unmask_ioasic_irq, - .end = end_ioasic_irq, }; @@ -77,20 +70,12 @@ static struct irq_chip ioasic_irq_type = #define ack_ioasic_dma_irq ack_ioasic_irq -static inline void end_ioasic_dma_irq(unsigned int irq) -{ - clear_ioasic_irq(irq); - fast_iob(); - end_ioasic_irq(irq); -} - static struct irq_chip ioasic_dma_irq_type = { .typename = "IO-ASIC-DMA", .ack = ack_ioasic_dma_irq, .mask = mask_ioasic_dma_irq, .mask_ack = ack_ioasic_dma_irq, .unmask = unmask_ioasic_dma_irq, - .end = end_ioasic_dma_irq, }; diff --git a/arch/mips/dec/kn02-irq.c b/arch/mips/dec/kn02-irq.c index 5a9be4c..916e46b 100644 --- a/arch/mips/dec/kn02-irq.c +++ b/arch/mips/dec/kn02-irq.c @@ -57,19 +57,12 @@ static void ack_kn02_irq(unsigned int ir iob(); } -static void end_kn02_irq(unsigned int irq) -{ - if (!(irq_desc[irq].status & (IRQ_DISABLED | IRQ_INPROGRESS))) - unmask_kn02_irq(irq); -} - static struct irq_chip kn02_irq_type = { .typename = "KN02-CSR", .ack = ack_kn02_irq, .mask = mask_kn02_irq, .mask_ack = ack_kn02_irq, .unmask = unmask_kn02_irq, - .end = end_kn02_irq, }; diff --git a/arch/mips/emma2rh/common/irq_emma2rh.c b/arch/mips/emma2rh/common/irq_emma2rh.c index 59b9829..8d880f0 100644 --- a/arch/mips/emma2rh/common/irq_emma2rh.c +++ b/arch/mips/emma2rh/common/irq_emma2rh.c @@ -56,19 +56,12 @@ static void emma2rh_irq_disable(unsigned ll_emma2rh_irq_disable(irq - emma2rh_irq_base); } -static void emma2rh_irq_end(unsigned int irq) -{ - if (!(irq_desc[irq].status & (IRQ_DISABLED | IRQ_INPROGRESS))) - ll_emma2rh_irq_enable(irq - emma2rh_irq_base); -} - struct irq_chip emma2rh_irq_controller = { .typename = "emma2rh_irq", .ack = emma2rh_irq_disable, .mask = emma2rh_irq_disable, .mask_ack = emma2rh_irq_disable, .unmask = emma2rh_irq_enable, - .end = emma2rh_irq_end, }; void emma2rh_irq_init(u32 irq_base) diff --git a/arch/mips/emma2rh/markeins/irq_markeins.c b/arch/mips/emma2rh/markeins/irq_markeins.c index 3ac4e40..2116d9b 100644 --- a/arch/mips/emma2rh/markeins/irq_markeins.c +++ b/arch/mips/emma2rh/markeins/irq_markeins.c @@ -48,19 +48,12 @@ static void emma2rh_sw_irq_disable(unsig ll_emma2rh_sw_irq_disable(irq - emma2rh_sw_irq_base); } -static void emma2rh_sw_irq_end(unsigned int irq) -{ - if (!(irq_desc[irq].status & (IRQ_DISABLED | IRQ_INPROGRESS))) - ll_emma2rh_sw_irq_enable(irq - emma2rh_sw_irq_base); -} - struct irq_chip emma2rh_sw_irq_controller = { .typename = "emma2rh_sw_irq", .ack = emma2rh_sw_irq_disable, .mask = emma2rh_sw_irq_disable, .mask_ack = emma2rh_sw_irq_disable, .unmask = emma2rh_sw_irq_enable, - .end = emma2rh_sw_irq_end, }; void emma2rh_sw_irq_init(u32 irq_base) diff --git a/arch/mips/jazz/irq.c b/arch/mips/jazz/irq.c index 5c4f50c..f8d417b 100644 --- a/arch/mips/jazz/irq.c +++ b/arch/mips/jazz/irq.c @@ -39,19 +39,12 @@ void disable_r4030_irq(unsigned int irq) spin_unlock_irqrestore(&r4030_lock, flags); } -static void end_r4030_irq(unsigned int irq) -{ - if (!(irq_desc[irq].status & (IRQ_DISABLED|IRQ_INPROGRESS))) - enable_r4030_irq(irq); -} - static struct irq_chip r4030_irq_type = { .typename = "R4030", .ack = disable_r4030_irq, .mask = disable_r4030_irq, .mask_ack = disable_r4030_irq, .unmask = enable_r4030_irq, - .end = end_r4030_irq, }; void __init init_r4030_ints(void) diff --git a/arch/mips/kernel/irq-mv6434x.c b/arch/mips/kernel/irq-mv6434x.c index 6cfb31c..efbd219 100644 --- a/arch/mips/kernel/irq-mv6434x.c +++ b/arch/mips/kernel/irq-mv6434x.c @@ -67,15 +67,6 @@ static inline void unmask_mv64340_irq(un } /* - * End IRQ processing - */ -static void end_mv64340_irq(unsigned int irq) -{ - if (!(irq_desc[irq].status & (IRQ_DISABLED|IRQ_INPROGRESS))) - unmask_mv64340_irq(irq); -} - -/* * Interrupt handler for interrupts coming from the Marvell chip. * It could be built in ethernet ports etc... */ @@ -106,7 +97,6 @@ struct irq_chip mv64340_irq_type = { .mask = mask_mv64340_irq, .mask_ack = mask_mv64340_irq, .unmask = unmask_mv64340_irq, - .end = end_mv64340_irq, }; void __init mv64340_irq_init(unsigned int base) diff --git a/arch/mips/kernel/irq-rm7000.c b/arch/mips/kernel/irq-rm7000.c index ddcc2a5..123324b 100644 --- a/arch/mips/kernel/irq-rm7000.c +++ b/arch/mips/kernel/irq-rm7000.c @@ -29,19 +29,12 @@ static inline void mask_rm7k_irq(unsigne clear_c0_intcontrol(0x100 << (irq - irq_base)); } -static void rm7k_cpu_irq_end(unsigned int irq) -{ - if (!(irq_desc[irq].status & (IRQ_DISABLED | IRQ_INPROGRESS))) - unmask_rm7k_irq(irq); -} - static struct irq_chip rm7k_irq_controller = { .typename = "RM7000", .ack = mask_rm7k_irq, .mask = mask_rm7k_irq, .mask_ack = mask_rm7k_irq, .unmask = unmask_rm7k_irq, - .end = rm7k_cpu_irq_end, }; void __init rm7k_cpu_irq_init(int base) diff --git a/arch/mips/kernel/irq-rm9000.c b/arch/mips/kernel/irq-rm9000.c index ba6440c..0e6f4c5 100644 --- a/arch/mips/kernel/irq-rm9000.c +++ b/arch/mips/kernel/irq-rm9000.c @@ -80,19 +80,12 @@ static void rm9k_perfcounter_irq_shutdow on_each_cpu(local_rm9k_perfcounter_irq_shutdown, (void *) irq, 0, 1); } -static void rm9k_cpu_irq_end(unsigned int irq) -{ - if (!(irq_desc[irq].status & (IRQ_DISABLED | IRQ_INPROGRESS))) - unmask_rm9k_irq(irq); -} - static struct irq_chip rm9k_irq_controller = { .typename = "RM9000", .ack = mask_rm9k_irq, .mask = mask_rm9k_irq, .mask_ack = mask_rm9k_irq, .unmask = unmask_rm9k_irq, - .end = rm9k_cpu_irq_end, }; static struct irq_chip rm9k_perfcounter_irq = { @@ -103,7 +96,6 @@ static struct irq_chip rm9k_perfcounter_ .mask = mask_rm9k_irq, .mask_ack = mask_rm9k_irq, .unmask = unmask_rm9k_irq, - .end = rm9k_cpu_irq_end, }; unsigned int rm9000_perfcount_irq; diff --git a/arch/mips/kernel/irq_cpu.c b/arch/mips/kernel/irq_cpu.c index be5ac23..7634a66 100644 --- a/arch/mips/kernel/irq_cpu.c +++ b/arch/mips/kernel/irq_cpu.c @@ -50,12 +50,6 @@ static inline void mask_mips_irq(unsigne irq_disable_hazard(); } -static void mips_cpu_irq_end(unsigned int irq) -{ - if (!(irq_desc[irq].status & (IRQ_DISABLED | IRQ_INPROGRESS))) - unmask_mips_irq(irq); -} - static struct irq_chip mips_cpu_irq_controller = { .typename = "MIPS", .ack = mask_mips_irq, @@ -63,7 +57,6 @@ static struct irq_chip mips_cpu_irq_cont .mask_ack = mask_mips_irq, .unmask = unmask_mips_irq, .eoi = unmask_mips_irq, - .end = mips_cpu_irq_end, }; /* diff --git a/arch/mips/lasat/interrupt.c b/arch/mips/lasat/interrupt.c index 4a84a7b..2affa5f 100644 --- a/arch/mips/lasat/interrupt.c +++ b/arch/mips/lasat/interrupt.c @@ -44,19 +44,12 @@ void enable_lasat_irq(unsigned int irq_n *lasat_int_mask |= (1 << irq_nr) << lasat_int_mask_shift; } -static void end_lasat_irq(unsigned int irq) -{ - if (!(irq_desc[irq].status & (IRQ_DISABLED|IRQ_INPROGRESS))) - enable_lasat_irq(irq); -} - static struct irq_chip lasat_irq_type = { .typename = "Lasat", .ack = disable_lasat_irq, .mask = disable_lasat_irq, .mask_ack = disable_lasat_irq, .unmask = enable_lasat_irq, - .end = end_lasat_irq, }; static inline int ls1bit32(unsigned int x) diff --git a/arch/mips/momentum/ocelot_c/cpci-irq.c b/arch/mips/momentum/ocelot_c/cpci-irq.c index e5a4a0a..bb11fef 100644 --- a/arch/mips/momentum/ocelot_c/cpci-irq.c +++ b/arch/mips/momentum/ocelot_c/cpci-irq.c @@ -66,15 +66,6 @@ static inline void unmask_cpci_irq(unsig } /* - * End IRQ processing - */ -static void end_cpci_irq(unsigned int irq) -{ - if (!(irq_desc[irq].status & (IRQ_DISABLED|IRQ_INPROGRESS))) - unmask_cpci_irq(irq); -} - -/* * Interrupt handler for interrupts coming from the FPGA chip. * It could be built in ethernet ports etc... */ @@ -98,7 +89,6 @@ struct irq_chip cpci_irq_type = { .mask = mask_cpci_irq, .mask_ack = mask_cpci_irq, .unmask = unmask_cpci_irq, - .end = end_cpci_irq, }; void cpci_irq_init(void) diff --git a/arch/mips/momentum/ocelot_c/uart-irq.c b/arch/mips/momentum/ocelot_c/uart-irq.c index 0029f00..a7a80c0 100644 --- a/arch/mips/momentum/ocelot_c/uart-irq.c +++ b/arch/mips/momentum/ocelot_c/uart-irq.c @@ -60,15 +60,6 @@ static inline void unmask_uart_irq(unsig } /* - * End IRQ processing - */ -static void end_uart_irq(unsigned int irq) -{ - if (!(irq_desc[irq].status & (IRQ_DISABLED|IRQ_INPROGRESS))) - unmask_uart_irq(irq); -} - -/* * Interrupt handler for interrupts coming from the FPGA chip. */ void ll_uart_irq(void) @@ -91,7 +82,6 @@ struct irq_chip uart_irq_type = { .mask = mask_uart_irq, .mask_ack = mask_uart_irq, .unmask = unmask_uart_irq, - .end = end_uart_irq, }; void uart_irq_init(void) diff --git a/arch/mips/philips/pnx8550/common/int.c b/arch/mips/philips/pnx8550/common/int.c index 0dc2393..2c36c10 100644 --- a/arch/mips/philips/pnx8550/common/int.c +++ b/arch/mips/philips/pnx8550/common/int.c @@ -158,20 +158,12 @@ int pnx8550_set_gic_priority(int irq, in return prev_priority; } -static void end_irq(unsigned int irq) -{ - if (!(irq_desc[irq].status & (IRQ_DISABLED|IRQ_INPROGRESS))) { - unmask_irq(irq); - } -} - static struct irq_chip level_irq_type = { .typename = "PNX Level IRQ", .ack = mask_irq, .mask = mask_irq, .mask_ack = mask_irq, .unmask = unmask_irq, - .end = end_irq, }; static struct irqaction gic_action = { diff --git a/arch/mips/sgi-ip22/ip22-int.c b/arch/mips/sgi-ip22/ip22-int.c index c7b1380..c44f8be 100644 --- a/arch/mips/sgi-ip22/ip22-int.c +++ b/arch/mips/sgi-ip22/ip22-int.c @@ -51,19 +51,12 @@ static void disable_local0_irq(unsigned sgint->imask0 &= ~(1 << (irq - SGINT_LOCAL0)); } -static void end_local0_irq (unsigned int irq) -{ - if (!(irq_desc[irq].status & (IRQ_DISABLED|IRQ_INPROGRESS))) - enable_local0_irq(irq); -} - static struct irq_chip ip22_local0_irq_type = { .typename = "IP22 local 0", .ack = disable_local0_irq, .mask = disable_local0_irq, .mask_ack = disable_local0_irq, .unmask = enable_local0_irq, - .end = end_local0_irq, }; static void enable_local1_irq(unsigned int irq) @@ -79,19 +72,12 @@ void disable_local1_irq(unsigned int irq sgint->imask1 &= ~(1 << (irq - SGINT_LOCAL1)); } -static void end_local1_irq (unsigned int irq) -{ - if (!(irq_desc[irq].status & (IRQ_DISABLED|IRQ_INPROGRESS))) - enable_local1_irq(irq); -} - static struct irq_chip ip22_local1_irq_type = { .typename = "IP22 local 1", .ack = disable_local1_irq, .mask = disable_local1_irq, .mask_ack = disable_local1_irq, .unmask = enable_local1_irq, - .end = end_local1_irq, }; static void enable_local2_irq(unsigned int irq) @@ -107,19 +93,12 @@ void disable_local2_irq(unsigned int irq sgint->imask0 &= ~(1 << (SGI_MAP_0_IRQ - SGINT_LOCAL0)); } -static void end_local2_irq (unsigned int irq) -{ - if (!(irq_desc[irq].status & (IRQ_DISABLED|IRQ_INPROGRESS))) - enable_local2_irq(irq); -} - static struct irq_chip ip22_local2_irq_type = { .typename = "IP22 local 2", .ack = disable_local2_irq, .mask = disable_local2_irq, .mask_ack = disable_local2_irq, .unmask = enable_local2_irq, - .end = end_local2_irq, }; static void enable_local3_irq(unsigned int irq) @@ -135,19 +114,12 @@ void disable_local3_irq(unsigned int irq sgint->imask1 &= ~(1 << (SGI_MAP_1_IRQ - SGINT_LOCAL1)); } -static void end_local3_irq (unsigned int irq) -{ - if (!(irq_desc[irq].status & (IRQ_DISABLED|IRQ_INPROGRESS))) - enable_local3_irq(irq); -} - static struct irq_chip ip22_local3_irq_type = { .typename = "IP22 local 3", .ack = disable_local3_irq, .mask = disable_local3_irq, .mask_ack = disable_local3_irq, .unmask = enable_local3_irq, - .end = end_local3_irq, }; static void indy_local0_irqdispatch(void) diff --git a/arch/mips/sgi-ip27/ip27-irq.c b/arch/mips/sgi-ip27/ip27-irq.c index 5f8835b..319f880 100644 --- a/arch/mips/sgi-ip27/ip27-irq.c +++ b/arch/mips/sgi-ip27/ip27-irq.c @@ -332,13 +332,6 @@ static inline void disable_bridge_irq(un intr_disconnect_level(cpu, swlevel); } -static void end_bridge_irq(unsigned int irq) -{ - if (!(irq_desc[irq].status & (IRQ_DISABLED|IRQ_INPROGRESS)) && - irq_desc[irq].action) - enable_bridge_irq(irq); -} - static struct irq_chip bridge_irq_type = { .typename = "bridge", .startup = startup_bridge_irq, @@ -347,7 +340,6 @@ static struct irq_chip bridge_irq_type = .mask = disable_bridge_irq, .mask_ack = disable_bridge_irq, .unmask = enable_bridge_irq, - .end = end_bridge_irq, }; void __devinit register_bridge_irq(unsigned int irq) diff --git a/arch/mips/sgi-ip27/ip27-timer.c b/arch/mips/sgi-ip27/ip27-timer.c index 7d36172..c20e989 100644 --- a/arch/mips/sgi-ip27/ip27-timer.c +++ b/arch/mips/sgi-ip27/ip27-timer.c @@ -180,10 +180,6 @@ static void disable_rt_irq(unsigned int { } -static void end_rt_irq(unsigned int irq) -{ -} - static struct irq_chip rt_irq_type = { .typename = "SN HUB RT timer", .ack = disable_rt_irq, @@ -191,7 +187,6 @@ static struct irq_chip rt_irq_type = { .mask_ack = disable_rt_irq, .unmask = enable_rt_irq, .eoi = enable_rt_irq, - .end = end_rt_irq, }; static struct irqaction rt_irqaction = { diff --git a/arch/mips/tx4927/common/tx4927_irq.c b/arch/mips/tx4927/common/tx4927_irq.c index 21873de..bd64c16 100644 --- a/arch/mips/tx4927/common/tx4927_irq.c +++ b/arch/mips/tx4927/common/tx4927_irq.c @@ -114,11 +114,9 @@ static const u32 tx4927_irq_debug_flag = static void tx4927_irq_cp0_enable(unsigned int irq); static void tx4927_irq_cp0_disable(unsigned int irq); -static void tx4927_irq_cp0_end(unsigned int irq); static void tx4927_irq_pic_enable(unsigned int irq); static void tx4927_irq_pic_disable(unsigned int irq); -static void tx4927_irq_pic_end(unsigned int irq); /* * Kernel structs for all pic's @@ -131,7 +129,6 @@ static struct irq_chip tx4927_irq_cp0_ty .mask = tx4927_irq_cp0_disable, .mask_ack = tx4927_irq_cp0_disable, .unmask = tx4927_irq_cp0_enable, - .end = tx4927_irq_cp0_end, }; #define TX4927_PIC_NAME "TX4927-PIC" @@ -141,7 +138,6 @@ static struct irq_chip tx4927_irq_pic_ty .mask = tx4927_irq_pic_disable, .mask_ack = tx4927_irq_pic_disable, .unmask = tx4927_irq_pic_enable, - .end = tx4927_irq_pic_end, }; #define TX4927_PIC_ACTION(s) { no_action, 0, CPU_MASK_NONE, s, NULL, NULL } @@ -214,15 +210,6 @@ static void tx4927_irq_cp0_disable(unsig tx4927_irq_cp0_modify(CCP0_STATUS, tx4927_irq_cp0_mask(irq), 0); } -static void tx4927_irq_cp0_end(unsigned int irq) -{ - TX4927_IRQ_DPRINTK(TX4927_IRQ_CP0_ENDIRQ, "irq=%d \n", irq); - - if (!(irq_desc[irq].status & (IRQ_DISABLED | IRQ_INPROGRESS))) { - tx4927_irq_cp0_enable(irq); - } -} - /* * Functions for pic */ @@ -376,15 +363,6 @@ static void tx4927_irq_pic_disable(unsig tx4927_irq_pic_mask(irq), 0); } -static void tx4927_irq_pic_end(unsigned int irq) -{ - TX4927_IRQ_DPRINTK(TX4927_IRQ_PIC_ENDIRQ, "irq=%d\n", irq); - - if (!(irq_desc[irq].status & (IRQ_DISABLED | IRQ_INPROGRESS))) { - tx4927_irq_pic_enable(irq); - } -} - /* * Main init functions */ diff --git a/arch/mips/tx4927/toshiba_rbtx4927/toshiba_rbtx4927_irq.c b/arch/mips/tx4927/toshiba_rbtx4927/toshiba_rbtx4927_irq.c index 34cdb2a..ce4ef10 100644 --- a/arch/mips/tx4927/toshiba_rbtx4927/toshiba_rbtx4927_irq.c +++ b/arch/mips/tx4927/toshiba_rbtx4927/toshiba_rbtx4927_irq.c @@ -223,7 +223,6 @@ extern void mask_and_ack_8259A(unsigned static void toshiba_rbtx4927_irq_ioc_enable(unsigned int irq); static void toshiba_rbtx4927_irq_ioc_disable(unsigned int irq); -static void toshiba_rbtx4927_irq_ioc_end(unsigned int irq); #ifdef CONFIG_TOSHIBA_FPCIB0 static void toshiba_rbtx4927_irq_isa_enable(unsigned int irq); @@ -239,7 +238,6 @@ static struct irq_chip toshiba_rbtx4927_ .mask = toshiba_rbtx4927_irq_ioc_disable, .mask_ack = toshiba_rbtx4927_irq_ioc_disable, .unmask = toshiba_rbtx4927_irq_ioc_enable, - .end = toshiba_rbtx4927_irq_ioc_end, }; #define TOSHIBA_RBTX4927_IOC_INTR_ENAB 0xbc002000 #define TOSHIBA_RBTX4927_IOC_INTR_STAT 0xbc002006 @@ -388,23 +386,6 @@ static void toshiba_rbtx4927_irq_ioc_dis TOSHIBA_RBTX4927_WR08(TOSHIBA_RBTX4927_IOC_INTR_ENAB, v); } -static void toshiba_rbtx4927_irq_ioc_end(unsigned int irq) -{ - TOSHIBA_RBTX4927_IRQ_DPRINTK(TOSHIBA_RBTX4927_IRQ_IOC_ENDIRQ, - "irq=%d\n", irq); - - if (irq < TOSHIBA_RBTX4927_IRQ_IOC_BEG - || irq > TOSHIBA_RBTX4927_IRQ_IOC_END) { - TOSHIBA_RBTX4927_IRQ_DPRINTK(TOSHIBA_RBTX4927_IRQ_EROR, - "bad irq=%d\n", irq); - panic("\n"); - } - - if (!(irq_desc[irq].status & (IRQ_DISABLED | IRQ_INPROGRESS))) { - toshiba_rbtx4927_irq_ioc_enable(irq); - } -} - /**********************************************************************************/ /* Functions for isa */ diff --git a/arch/mips/tx4938/common/irq.c b/arch/mips/tx4938/common/irq.c index 42e1276..a347b42 100644 --- a/arch/mips/tx4938/common/irq.c +++ b/arch/mips/tx4938/common/irq.c @@ -39,11 +39,9 @@ static void tx4938_irq_cp0_enable(unsigned int irq); static void tx4938_irq_cp0_disable(unsigned int irq); -static void tx4938_irq_cp0_end(unsigned int irq); static void tx4938_irq_pic_enable(unsigned int irq); static void tx4938_irq_pic_disable(unsigned int irq); -static void tx4938_irq_pic_end(unsigned int irq); /**********************************************************************************/ /* Kernel structs for all pic's */ @@ -56,7 +54,6 @@ static struct irq_chip tx4938_irq_cp0_ty .mask = tx4938_irq_cp0_disable, .mask_ack = tx4938_irq_cp0_disable, .unmask = tx4938_irq_cp0_enable, - .end = tx4938_irq_cp0_end, }; #define TX4938_PIC_NAME "TX4938-PIC" @@ -66,7 +63,6 @@ static struct irq_chip tx4938_irq_pic_ty .mask = tx4938_irq_pic_disable, .mask_ack = tx4938_irq_pic_disable, .unmask = tx4938_irq_pic_enable, - .end = tx4938_irq_pic_end, }; static struct irqaction tx4938_irq_pic_action = { @@ -104,14 +100,6 @@ tx4938_irq_cp0_disable(unsigned int irq) clear_c0_status(tx4938_irq_cp0_mask(irq)); } -static void -tx4938_irq_cp0_end(unsigned int irq) -{ - if (!(irq_desc[irq].status & (IRQ_DISABLED | IRQ_INPROGRESS))) { - tx4938_irq_cp0_enable(irq); - } -} - /**********************************************************************************/ /* Functions for pic */ /**********************************************************************************/ @@ -269,14 +257,6 @@ tx4938_irq_pic_disable(unsigned int irq) tx4938_irq_pic_mask(irq), 0); } -static void -tx4938_irq_pic_end(unsigned int irq) -{ - if (!(irq_desc[irq].status & (IRQ_DISABLED | IRQ_INPROGRESS))) { - tx4938_irq_pic_enable(irq); - } -} - /**********************************************************************************/ /* Main init functions */ /**********************************************************************************/ diff --git a/arch/mips/tx4938/toshiba_rbtx4938/irq.c b/arch/mips/tx4938/toshiba_rbtx4938/irq.c index 8c87a35..b6f363d 100644 --- a/arch/mips/tx4938/toshiba_rbtx4938/irq.c +++ b/arch/mips/tx4938/toshiba_rbtx4938/irq.c @@ -89,7 +89,6 @@ IRQ Device static void toshiba_rbtx4938_irq_ioc_enable(unsigned int irq); static void toshiba_rbtx4938_irq_ioc_disable(unsigned int irq); -static void toshiba_rbtx4938_irq_ioc_end(unsigned int irq); #define TOSHIBA_RBTX4938_IOC_NAME "RBTX4938-IOC" static struct irq_chip toshiba_rbtx4938_irq_ioc_type = { @@ -98,7 +97,6 @@ static struct irq_chip toshiba_rbtx4938_ .mask = toshiba_rbtx4938_irq_ioc_disable, .mask_ack = toshiba_rbtx4938_irq_ioc_disable, .unmask = toshiba_rbtx4938_irq_ioc_enable, - .end = toshiba_rbtx4938_irq_ioc_end, }; #define TOSHIBA_RBTX4938_IOC_INTR_ENAB 0xb7f02000 @@ -167,14 +165,6 @@ toshiba_rbtx4938_irq_ioc_disable(unsigne TX4938_RD08(TOSHIBA_RBTX4938_IOC_INTR_ENAB); } -static void -toshiba_rbtx4938_irq_ioc_end(unsigned int irq) -{ - if (!(irq_desc[irq].status & (IRQ_DISABLED | IRQ_INPROGRESS))) { - toshiba_rbtx4938_irq_ioc_enable(irq); - } -} - extern void __init txx9_spi_irqinit(int irc_irq); void __init arch_init_irq(void) diff --git a/arch/mips/vr41xx/common/icu.c b/arch/mips/vr41xx/common/icu.c index 54b92a7..c075261 100644 --- a/arch/mips/vr41xx/common/icu.c +++ b/arch/mips/vr41xx/common/icu.c @@ -427,19 +427,12 @@ static void enable_sysint1_irq(unsigned icu1_set(MSYSINT1REG, 1 << SYSINT1_IRQ_TO_PIN(irq)); } -static void end_sysint1_irq(unsigned int irq) -{ - if (!(irq_desc[irq].status & (IRQ_DISABLED | IRQ_INPROGRESS))) - icu1_set(MSYSINT1REG, 1 << SYSINT1_IRQ_TO_PIN(irq)); -} - static struct irq_chip sysint1_irq_type = { .typename = "SYSINT1", .ack = disable_sysint1_irq, .mask = disable_sysint1_irq, .mask_ack = disable_sysint1_irq, .unmask = enable_sysint1_irq, - .end = end_sysint1_irq, }; static void disable_sysint2_irq(unsigned int irq) @@ -452,19 +445,12 @@ static void enable_sysint2_irq(unsigned icu2_set(MSYSINT2REG, 1 << SYSINT2_IRQ_TO_PIN(irq)); } -static void end_sysint2_irq(unsigned int irq) -{ - if (!(irq_desc[irq].status & (IRQ_DISABLED | IRQ_INPROGRESS))) - icu2_set(MSYSINT2REG, 1 << SYSINT2_IRQ_TO_PIN(irq)); -} - static struct irq_chip sysint2_irq_type = { .typename = "SYSINT2", .ack = disable_sysint2_irq, .mask = disable_sysint2_irq, .mask_ack = disable_sysint2_irq, .unmask = enable_sysint2_irq, - .end = end_sysint2_irq, }; static inline int set_sysint1_assign(unsigned int irq, unsigned char assign) -- 1.4.4.1 From sshtylyov@ru.mvista.com Fri Dec 1 15:07:07 2006 Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 01 Dec 2006 15:07:11 +0000 (GMT) Received: from h155.mvista.com ([63.81.120.155]:28640 "EHLO imap.sh.mvista.com") by ftp.linux-mips.org with ESMTP id S20037897AbWLAPHH (ORCPT ); Fri, 1 Dec 2006 15:07:07 +0000 Received: from [192.168.1.248] (unknown [10.150.0.9]) by imap.sh.mvista.com (Postfix) with ESMTP id 0510C3ECA; Fri, 1 Dec 2006 07:06:48 -0800 (PST) Message-ID: <45704569.8000807@ru.mvista.com> Date: Fri, 01 Dec 2006 18:08:25 +0300 From: Sergei Shtylyov Organization: MontaVista Software Inc. User-Agent: Mozilla/5.0 (X11; U; Linux i686; rv:1.7.2) Gecko/20040803 X-Accept-Language: ru, en-us, en-gb MIME-Version: 1.0 To: Atsushi Nemoto Cc: vagabon.xyz@gmail.com, linux-mips@linux-mips.org Subject: Re: Is _do_IRQ() not needed anymore ? References: <20061201.185740.03976990.nemoto@toshiba-tops.co.jp> <20061201.191049.63741937.nemoto@toshiba-tops.co.jp> In-Reply-To: <20061201.191049.63741937.nemoto@toshiba-tops.co.jp> Content-Type: text/plain; charset=us-ascii; 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: 13296 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: sshtylyov@ru.mvista.com Precedence: bulk X-list: linux-mips Hello. Atsushi Nemoto wrote: >>>If _all_ irq chip were converted to use flow handler, >>>GENERIC_HARDIRQS_NO__DO_IRQ will be good. But we have i8259... >>That's why in my example I made GENERIC_HARDIRQS_NO__DO_IRQ config >>default to 'n' and selected by a irq chip that doens't use __do_IRQ() >>anymore, well I think... > You can use both irq_cpu and i8259 same time. :) What's wrong with 8259 I wonder? It's happily converted to genirq by other arches... > --- > Atsushi Nemoto WBR, Sergei From anemo@mba.ocn.ne.jp Fri Dec 1 15:08:09 2006 Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 01 Dec 2006 15:08:15 +0000 (GMT) Received: from mba.ocn.ne.jp ([210.190.142.172]:47586 "HELO smtp.mba.ocn.ne.jp") by ftp.linux-mips.org with SMTP id S20038324AbWLAPIJ (ORCPT ); Fri, 1 Dec 2006 15:08:09 +0000 Received: from localhost (p7250-ipad213funabasi.chiba.ocn.ne.jp [124.85.72.250]) by smtp.mba.ocn.ne.jp (Postfix) with ESMTP id 4DC4AC15F; Sat, 2 Dec 2006 00:08:04 +0900 (JST) Date: Sat, 02 Dec 2006 00:08:03 +0900 (JST) Message-Id: <20061202.000803.05599975.anemo@mba.ocn.ne.jp> To: linux-mips@linux-mips.org Cc: ralf@linux-mips.org Subject: Re: [PATCH] use generic_handle_irq, handle_level_irq, handle_percpu_irq From: Atsushi Nemoto In-Reply-To: <20061114.011318.99611303.anemo@mba.ocn.ne.jp> References: <20061114.011318.99611303.anemo@mba.ocn.ne.jp> 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 3.3 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: 13297 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 Tue, 14 Nov 2006 01:13:18 +0900 (JST), Atsushi Nemoto wrote: > Further incorporation of generic irq framework. Replacing __do_IRQ() > by proper flow handler would make the irq handling path a bit simpler > and faster. > > * use generic_handle_irq() instead of __do_IRQ(). > * use handle_level_irq for obvious level-type irq chips. > * use handle_percpu_irq for irqs marked as IRQ_PER_CPU. > * setup .eoi routine for irq chips possibly used with handle_percpu_irq. > > Signed-off-by: Atsushi Nemoto > > arch/mips/dec/ioasic-irq.c | 6 ++++-- Does somebody tried this patch on decstation? I'm afraid this patch broke it. While ioasic_dma_irq_type's .end routine end_ioasic_dma_irq() is doing something special, it should not be handled correctly by handle_level_irq. Here is a patch revert that part. Subject: do not use handle_level_irq for ioasic_dma_irq_type. Signed-off-by: Atsushi Nemoto diff --git a/arch/mips/dec/ioasic-irq.c b/arch/mips/dec/ioasic-irq.c index 269b22b..e21476d 100644 --- a/arch/mips/dec/ioasic-irq.c +++ b/arch/mips/dec/ioasic-irq.c @@ -106,8 +106,7 @@ void __init init_ioasic_irqs(int base) set_irq_chip_and_handler(i, &ioasic_irq_type, handle_level_irq); for (; i < base + IO_IRQ_LINES; i++) - set_irq_chip_and_handler(i, &ioasic_dma_irq_type, - handle_level_irq); + set_irq_chip(i, &ioasic_dma_irq_type); ioasic_irq_base = base; } From anemo@mba.ocn.ne.jp Fri Dec 1 15:12:22 2006 Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 01 Dec 2006 15:12:27 +0000 (GMT) Received: from mba.ocn.ne.jp ([210.190.142.172]:59118 "HELO smtp.mba.ocn.ne.jp") by ftp.linux-mips.org with SMTP id S20037960AbWLAPMW (ORCPT ); Fri, 1 Dec 2006 15:12:22 +0000 Received: from localhost (p7250-ipad213funabasi.chiba.ocn.ne.jp [124.85.72.250]) by smtp.mba.ocn.ne.jp (Postfix) with ESMTP id CCEA1BFB3; Sat, 2 Dec 2006 00:12:17 +0900 (JST) Date: Sat, 02 Dec 2006 00:12:17 +0900 (JST) Message-Id: <20061202.001217.108120576.anemo@mba.ocn.ne.jp> To: vagabon.xyz@gmail.com Cc: ralf@linux-mips.org, linux-mips@linux-mips.org Subject: Re: [PATCH] Compile __do_IRQ() when really needed From: Atsushi Nemoto In-Reply-To: <457042FF.2060908@innova-card.com> References: <457042FF.2060908@innova-card.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 3.3 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: 13298 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 Fri, 01 Dec 2006 15:58:07 +0100, Franck Bui-Huu wrote: > __do_IRQ() is needed only by irq handlers that can't use > default handler defined in kernel/irq/chip.c. > > For others platforms there's no need to compile this function > since it won't be used. For those platforms this patch defines > GENERIC_HARDIRQS_NO__DO_IRQ symbol which is used exactly for > this purpose. > > Futhermore for platforms which do not use __do_IRQ(), end() > method which is part of the 'irq_chip' structure is not used. > This patch simply removes this method in this case. As I wrote in separate mail, I think I had fault on ioasic_dma_irq_type. So please drop some part from your patch. > @@ -171,6 +171,7 @@ config MACH_DECSTATION > select SYS_SUPPORTS_128HZ > select SYS_SUPPORTS_256HZ > select SYS_SUPPORTS_1024HZ > + select GENERIC_HARDIRQS_NO__DO_IRQ > help > This enables support for DEC's MIPS based workstations. For details > see the Linux/MIPS FAQ on and the and > @@ -77,20 +70,12 @@ static struct irq_chip ioasic_irq_type = > > #define ack_ioasic_dma_irq ack_ioasic_irq > > -static inline void end_ioasic_dma_irq(unsigned int irq) > -{ > - clear_ioasic_irq(irq); > - fast_iob(); > - end_ioasic_irq(irq); > -} > - > static struct irq_chip ioasic_dma_irq_type = { > .typename = "IO-ASIC-DMA", > .ack = ack_ioasic_dma_irq, > .mask = mask_ioasic_dma_irq, > .mask_ack = ack_ioasic_dma_irq, > .unmask = unmask_ioasic_dma_irq, > - .end = end_ioasic_dma_irq, > }; > > Sorry for confusion... --- Atsushi Nemoto From macro@linux-mips.org Fri Dec 1 15:14:13 2006 Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 01 Dec 2006 15:14:18 +0000 (GMT) Received: from pollux.ds.pg.gda.pl ([153.19.208.7]:9477 "EHLO pollux.ds.pg.gda.pl") by ftp.linux-mips.org with ESMTP id S20038324AbWLAPON (ORCPT ); Fri, 1 Dec 2006 15:14:13 +0000 Received: from localhost (localhost [127.0.0.1]) by pollux.ds.pg.gda.pl (Postfix) with ESMTP id 23E5EE1CAE; Fri, 1 Dec 2006 16:14:01 +0100 (CET) X-Virus-Scanned: by amavisd-new at pollux.ds.pg.gda.pl Received: from pollux.ds.pg.gda.pl ([127.0.0.1]) by localhost (pollux.ds.pg.gda.pl [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U0fJsd1e4NwV; Fri, 1 Dec 2006 16:14:00 +0100 (CET) Received: from piorun.ds.pg.gda.pl (piorun.ds.pg.gda.pl [153.19.208.8]) by pollux.ds.pg.gda.pl (Postfix) with ESMTP id C0A62E1CAC; Fri, 1 Dec 2006 16:14:00 +0100 (CET) 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 kB1FEB1L013274; Fri, 1 Dec 2006 16:14:11 +0100 Date: Fri, 1 Dec 2006 15:14:07 +0000 (GMT) From: "Maciej W. Rozycki" To: Franck Bui-Huu cc: Ralf Baechle , Atsushi Nemoto , linux-mips Subject: Re: [PATCH] Compile __do_IRQ() when really needed In-Reply-To: <457042FF.2060908@innova-card.com> Message-ID: References: <457042FF.2060908@innova-card.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: ClamAV 0.88.6/2267/Fri Dec 1 05:29:21 2006 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: 13299 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, 1 Dec 2006, Franck Bui-Huu wrote: > diff --git a/arch/mips/dec/ioasic-irq.c b/arch/mips/dec/ioasic-irq.c > index 269b22b..c5248a1 100644 > --- a/arch/mips/dec/ioasic-irq.c > +++ b/arch/mips/dec/ioasic-irq.c > @@ -55,19 +55,12 @@ static inline void ack_ioasic_irq(unsign > fast_iob(); > } > > -static inline void end_ioasic_irq(unsigned int irq) > -{ > - if (!(irq_desc[irq].status & (IRQ_DISABLED | IRQ_INPROGRESS))) > - unmask_ioasic_irq(irq); > -} > - > static struct irq_chip ioasic_irq_type = { > .typename = "IO-ASIC", > .ack = ack_ioasic_irq, > .mask = mask_ioasic_irq, > .mask_ack = ack_ioasic_irq, > .unmask = unmask_ioasic_irq, > - .end = end_ioasic_irq, > }; > > > @@ -77,20 +70,12 @@ static struct irq_chip ioasic_irq_type = > > #define ack_ioasic_dma_irq ack_ioasic_irq > > -static inline void end_ioasic_dma_irq(unsigned int irq) > -{ > - clear_ioasic_irq(irq); > - fast_iob(); > - end_ioasic_irq(irq); > -} > - > static struct irq_chip ioasic_dma_irq_type = { > .typename = "IO-ASIC-DMA", > .ack = ack_ioasic_dma_irq, > .mask = mask_ioasic_dma_irq, > .mask_ack = ack_ioasic_dma_irq, > .unmask = unmask_ioasic_dma_irq, > - .end = end_ioasic_dma_irq, > }; > > You have removed a call to clear_ioasic_irq() -- I/O ASIC DMA engines will cease to work as a result. Maciej From vagabon.xyz@gmail.com Fri Dec 1 15:18:17 2006 Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 01 Dec 2006 15:18:21 +0000 (GMT) Received: from ug-out-1314.google.com ([66.249.92.168]:4822 "EHLO ug-out-1314.google.com") by ftp.linux-mips.org with ESMTP id S20038405AbWLAPSR (ORCPT ); Fri, 1 Dec 2006 15:18:17 +0000 Received: by ug-out-1314.google.com with SMTP id 40so2648187uga for ; Fri, 01 Dec 2006 07:18:16 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=F9490MT6fG8tJ30xxewsn+EDtTrlZgsw2MEmkowPbkZMOgMnWn4NwlvHw8GvOzBV4Ul3Mb247fT3GV/oM7LOXf6I6EU420zLp4mdo+Yj0PeGgQ1Ta9c5F9296ZPFiSzzWHVeZ66t6O6cgiXi4VREOZ+/3/5gx1dVJ6gto6YKIU8= Received: by 10.78.138.6 with SMTP id l6mr4884934hud.1164986296194; Fri, 01 Dec 2006 07:18:16 -0800 (PST) Received: by 10.78.124.19 with HTTP; Fri, 1 Dec 2006 07:18:15 -0800 (PST) Message-ID: Date: Fri, 1 Dec 2006 16:18:15 +0100 From: "Franck Bui-Huu" To: "Atsushi Nemoto" Subject: Re: [PATCH] Compile __do_IRQ() when really needed Cc: ralf@linux-mips.org, linux-mips@linux-mips.org In-Reply-To: <20061202.001217.108120576.anemo@mba.ocn.ne.jp> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <457042FF.2060908@innova-card.com> <20061202.001217.108120576.anemo@mba.ocn.ne.jp> 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: 13300 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 On 12/1/06, Atsushi Nemoto wrote: > On Fri, 01 Dec 2006 15:58:07 +0100, Franck Bui-Huu wrote: > > __do_IRQ() is needed only by irq handlers that can't use > > default handler defined in kernel/irq/chip.c. > > > > For others platforms there's no need to compile this function > > since it won't be used. For those platforms this patch defines > > GENERIC_HARDIRQS_NO__DO_IRQ symbol which is used exactly for > > this purpose. > > > > Futhermore for platforms which do not use __do_IRQ(), end() > > method which is part of the 'irq_chip' structure is not used. > > This patch simply removes this method in this case. > > As I wrote in separate mail, I think I had fault on > ioasic_dma_irq_type. So please drop some part from your patch. > Yes, I just noticed your latest patch which makes this one obsolete and wrong. I'm going to drop DEC's part. thanks -- Franck From anemo@mba.ocn.ne.jp Fri Dec 1 15:22:18 2006 Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 01 Dec 2006 15:22:23 +0000 (GMT) Received: from mba.ocn.ne.jp ([210.190.142.172]:58589 "HELO smtp.mba.ocn.ne.jp") by ftp.linux-mips.org with SMTP id S20038329AbWLAPWS (ORCPT ); Fri, 1 Dec 2006 15:22:18 +0000 Received: from localhost (p7250-ipad213funabasi.chiba.ocn.ne.jp [124.85.72.250]) by smtp.mba.ocn.ne.jp (Postfix) with ESMTP id 4C9B6BFBB; Sat, 2 Dec 2006 00:22:14 +0900 (JST) Date: Sat, 02 Dec 2006 00:22:14 +0900 (JST) Message-Id: <20061202.002214.51866784.anemo@mba.ocn.ne.jp> To: sshtylyov@ru.mvista.com Cc: vagabon.xyz@gmail.com, linux-mips@linux-mips.org Subject: Re: Is _do_IRQ() not needed anymore ? From: Atsushi Nemoto In-Reply-To: <45704569.8000807@ru.mvista.com> References: <20061201.191049.63741937.nemoto@toshiba-tops.co.jp> <45704569.8000807@ru.mvista.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 3.3 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: 13301 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 Fri, 01 Dec 2006 18:08:25 +0300, Sergei Shtylyov wrote: > > You can use both irq_cpu and i8259 same time. :) > > What's wrong with 8259 I wonder? It's happily converted to genirq by other > arches... Indeed. I missed other arch's i8259.c had changed. Maybe we should update i8259.c entirely. --- Atsushi Nemoto From sshtylyov@ru.mvista.com Fri Dec 1 15:27:45 2006 Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 01 Dec 2006 15:27:49 +0000 (GMT) Received: from h155.mvista.com ([63.81.120.155]:46560 "EHLO imap.sh.mvista.com") by ftp.linux-mips.org with ESMTP id S20038324AbWLAP1p (ORCPT ); Fri, 1 Dec 2006 15:27:45 +0000 Received: from [192.168.1.248] (unknown [10.150.0.9]) by imap.sh.mvista.com (Postfix) with ESMTP id 7D5B33ECA; Fri, 1 Dec 2006 07:27:40 -0800 (PST) Message-ID: <45704A4D.9050303@ru.mvista.com> Date: Fri, 01 Dec 2006 18:29:17 +0300 From: Sergei Shtylyov Organization: MontaVista Software Inc. User-Agent: Mozilla/5.0 (X11; U; Linux i686; rv:1.7.2) Gecko/20040803 X-Accept-Language: ru, en-us, en-gb MIME-Version: 1.0 To: Atsushi Nemoto Cc: vagabon.xyz@gmail.com, linux-mips@linux-mips.org Subject: Re: Is _do_IRQ() not needed anymore ? References: <20061201.191049.63741937.nemoto@toshiba-tops.co.jp> <45704569.8000807@ru.mvista.com> <20061202.002214.51866784.anemo@mba.ocn.ne.jp> In-Reply-To: <20061202.002214.51866784.anemo@mba.ocn.ne.jp> Content-Type: text/plain; charset=us-ascii; 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: 13302 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: sshtylyov@ru.mvista.com Precedence: bulk X-list: linux-mips Hello. Atsushi Nemoto wrote: >>>You can use both irq_cpu and i8259 same time. :) >> What's wrong with 8259 I wonder? It's happily converted to genirq by other >>arches... > Indeed. I missed other arch's i8259.c had changed. Maybe we should > update i8259.c entirely. The question is what flow to use: level/edge ones used in x86 code and actually intended for simplistic controllers, not the likes of 8259 OR the "fasteoi" one used in PowerPC code and (as it turned out in my earlier discussion in linuxppc-dev) intended for the controllers that are smart enough to mask off the lower-priority IRQs when getting the top level one acknowledged and unmask them upon EOI command... > --- > Atsushi Nemoto WBR, Sergei From yoichi_yuasa@tripeaks.co.jp Fri Dec 1 15:29:52 2006 Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 01 Dec 2006 15:29:57 +0000 (GMT) Received: from mo32.po.2iij.net ([210.128.50.17]:46894 "EHLO mo32.po.2iij.net") by ftp.linux-mips.org with ESMTP id S20038324AbWLAP3w (ORCPT ); Fri, 1 Dec 2006 15:29:52 +0000 Received: by mo.po.2iij.net (mo32) id kB1FTkir023411; Sat, 2 Dec 2006 00:29:46 +0900 (JST) Received: from localhost.localdomain (133.25.30.125.dy.iij4u.or.jp [125.30.25.133]) by mbox.po.2iij.net (mbox32) id kB1FTbdF080366 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sat, 2 Dec 2006 00:29:38 +0900 (JST) Date: Sat, 2 Dec 2006 00:29:37 +0900 From: Yoichi Yuasa To: Franck Cc: yoichi_yuasa@tripeaks.co.jp, ralf@linux-mips.org, anemo@mba.ocn.ne.jp, linux-mips@linux-mips.org Subject: Re: [PATCH] Compile __do_IRQ() when really needed Message-Id: <20061202002937.7b4cb749.yoichi_yuasa@tripeaks.co.jp> In-Reply-To: <457042FF.2060908@innova-card.com> References: <457042FF.2060908@innova-card.com> Organization: TriPeaks Corporation X-Mailer: Sylpheed version 1.0.6 (GTK+ 1.2.10; 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: 13303 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, On Fri, 01 Dec 2006 15:58:07 +0100 Franck Bui-Huu wrote: > config MACH_VR41XX > bool "NEC VR41XX-based machines" > select SYS_HAS_CPU_VR41XX > + select GENERIC_HARDIRQS_NO__DO_IRQ NEC CMBVR4133 has i8259. The other vr41xx boards have no problem. Thanks, Yoichi From vagabon.xyz@gmail.com Fri Dec 1 15:31:40 2006 Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 01 Dec 2006 15:31:46 +0000 (GMT) Received: from nf-out-0910.google.com ([64.233.182.184]:18026 "EHLO nf-out-0910.google.com") by ftp.linux-mips.org with ESMTP id S20038416AbWLAPbk (ORCPT ); Fri, 1 Dec 2006 15:31:40 +0000 Received: by nf-out-0910.google.com with SMTP id l24so3455611nfc for ; Fri, 01 Dec 2006 07:31:39 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:reply-to:user-agent:mime-version:to:cc:subject:content-type:content-transfer-encoding:from; b=WbfsuoStQlV1M2JnWO96MwmhXnr/6neajbNFN6Eo882xw1kGwsK04Ac+9oCQsxh4X8ITILyB2+0DHQYSCFkapSwenRlUOYxQNGkzpdgqHJ1BdBZ8RW4q7xEoSRiEotwtbpSNKNG1fwfNFqJaXGA+/oYPhR8ngSjsbYFkGpQvcBY= Received: by 10.49.21.8 with SMTP id y8mr9385280nfi.1164987098127; Fri, 01 Dec 2006 07:31:38 -0800 (PST) Received: from ?192.168.0.24? ( [81.252.61.1]) by mx.google.com with ESMTP id x27sm16017566nfb.2006.12.01.07.31.37; Fri, 01 Dec 2006 07:31:37 -0800 (PST) Message-ID: <45704B26.9040202@innova-card.com> Date: Fri, 01 Dec 2006 16:32:54 +0100 Reply-To: Franck User-Agent: Thunderbird 1.5.0.4 (X11/20060614) MIME-Version: 1.0 To: Ralf Baechle CC: Atsushi Nemoto , macro@linux-mips.org, linux-mips Subject: [PATCH] Compile __do_IRQ() when really needed [take #2] Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit From: Franck Bui-Huu 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: 13304 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 From: Franck Bui-Huu __do_IRQ() is needed only by irq handlers that can't use default handler defined in kernel/irq/chip.c. For others platforms there's no need to compile this function since it won't be used. For those platforms this patch defines GENERIC_HARDIRQS_NO__DO_IRQ symbol which is used exactly for this purpose. Futhermore for platforms which do not use __do_IRQ(), end() method which is part of the 'irq_chip' structure is not used. This patch simply removes this method in this case. Signed-off-by: Franck Bui-Huu --- With DEC's part updated. arch/mips/Kconfig | 15 ++++++++++ arch/mips/dec/ioasic-irq.c | 7 ----- arch/mips/dec/kn02-irq.c | 7 ----- arch/mips/emma2rh/common/irq_emma2rh.c | 7 ----- arch/mips/emma2rh/markeins/irq_markeins.c | 7 ----- arch/mips/jazz/irq.c | 7 ----- arch/mips/kernel/irq-mv6434x.c | 10 ------- arch/mips/kernel/irq-rm7000.c | 7 ----- arch/mips/kernel/irq-rm9000.c | 8 ----- arch/mips/kernel/irq_cpu.c | 7 ----- arch/mips/lasat/interrupt.c | 7 ----- arch/mips/momentum/ocelot_c/cpci-irq.c | 10 ------- arch/mips/momentum/ocelot_c/uart-irq.c | 10 ------- arch/mips/philips/pnx8550/common/int.c | 8 ----- arch/mips/sgi-ip22/ip22-int.c | 28 -------------------- arch/mips/sgi-ip27/ip27-irq.c | 8 ----- arch/mips/sgi-ip27/ip27-timer.c | 5 --- arch/mips/tx4927/common/tx4927_irq.c | 22 --------------- .../tx4927/toshiba_rbtx4927/toshiba_rbtx4927_irq.c | 19 ------------- arch/mips/tx4938/common/irq.c | 20 -------------- arch/mips/tx4938/toshiba_rbtx4938/irq.c | 10 ------- arch/mips/vr41xx/common/icu.c | 14 ---------- 22 files changed, 15 insertions(+), 228 deletions(-) diff --git a/arch/mips/Kconfig b/arch/mips/Kconfig index 5ff94e5..08a64a8 100644 --- a/arch/mips/Kconfig +++ b/arch/mips/Kconfig @@ -216,6 +216,7 @@ config MACH_JAZZ select SYS_SUPPORTS_32BIT_KERNEL select SYS_SUPPORTS_64BIT_KERNEL if EXPERIMENTAL select SYS_SUPPORTS_100HZ + select GENERIC_HARDIRQS_NO__DO_IRQ help This a family of machines based on the MIPS R4030 chipset which was used by several vendors to build RISC/os and Windows NT workstations. @@ -233,6 +234,7 @@ config LASAT select SYS_SUPPORTS_32BIT_KERNEL select SYS_SUPPORTS_64BIT_KERNEL if EXPERIMENTAL select SYS_SUPPORTS_LITTLE_ENDIAN + select GENERIC_HARDIRQS_NO__DO_IRQ config MIPS_ATLAS bool "MIPS Atlas board" @@ -256,6 +258,7 @@ config MIPS_ATLAS select SYS_SUPPORTS_BIG_ENDIAN select SYS_SUPPORTS_LITTLE_ENDIAN select SYS_SUPPORTS_MULTITHREADING if EXPERIMENTAL + select GENERIC_HARDIRQS_NO__DO_IRQ help This enables support for the MIPS Technologies Atlas evaluation board. @@ -410,6 +413,7 @@ config MOMENCO_OCELOT_C select SYS_SUPPORTS_32BIT_KERNEL select SYS_SUPPORTS_64BIT_KERNEL select SYS_SUPPORTS_BIG_ENDIAN + select GENERIC_HARDIRQS_NO__DO_IRQ help The Ocelot is a MIPS-based Single Board Computer (SBC) made by Momentum Computer . @@ -468,6 +472,7 @@ config DDB5477 config MACH_VR41XX bool "NEC VR41XX-based machines" select SYS_HAS_CPU_VR41XX + select GENERIC_HARDIRQS_NO__DO_IRQ config PMC_YOSEMITE bool "PMC-Sierra Yosemite eval board" @@ -519,6 +524,7 @@ config MARKEINS select SYS_SUPPORTS_BIG_ENDIAN select SYS_SUPPORTS_LITTLE_ENDIAN select SYS_HAS_CPU_R5000 + select GENERIC_HARDIRQS_NO__DO_IRQ help This enables support for the R5432-based NEC Mark-eins boards with R5500 CPU. @@ -539,6 +545,7 @@ config SGI_IP22 select SYS_SUPPORTS_32BIT_KERNEL select SYS_SUPPORTS_64BIT_KERNEL select SYS_SUPPORTS_BIG_ENDIAN + select GENERIC_HARDIRQS_NO__DO_IRQ help This are the SGI Indy, Challenge S and Indigo2, as well as certain OEM variants like the Tandem CMN B006S. To compile a Linux kernel @@ -558,6 +565,7 @@ config SGI_IP27 select SYS_SUPPORTS_BIG_ENDIAN select SYS_SUPPORTS_NUMA select SYS_SUPPORTS_SMP + select GENERIC_HARDIRQS_NO__DO_IRQ help This are the SGI Origin 200, Origin 2000 and Onyx 2 Graphics workstations. To compile a Linux kernel that runs on these, say Y @@ -739,6 +747,7 @@ config TOSHIBA_RBTX4927 select SYS_SUPPORTS_64BIT_KERNEL select SYS_SUPPORTS_BIG_ENDIAN select TOSHIBA_BOARDS + select GENERIC_HARDIRQS_NO__DO_IRQ help This Toshiba board is based on the TX4927 processor. Say Y here to support this machine type @@ -758,6 +767,7 @@ config TOSHIBA_RBTX4938 select SYS_SUPPORTS_LITTLE_ENDIAN select SYS_SUPPORTS_BIG_ENDIAN select TOSHIBA_BOARDS + select GENERIC_HARDIRQS_NO__DO_IRQ help This Toshiba board is based on the TX4938 processor. Say Y here to support this machine type @@ -824,6 +834,10 @@ config SCHED_NO_NO_OMIT_FRAME_POINTER bool default y +config GENERIC_HARDIRQS_NO__DO_IRQ + bool + default n + # # Select some configuration options automatically based on user selections. # @@ -985,6 +999,7 @@ config SOC_PNX8550 select HW_HAS_PCI select SYS_HAS_CPU_MIPS32_R1 select SYS_SUPPORTS_32BIT_KERNEL + select GENERIC_HARDIRQS_NO__DO_IRQ config SWAP_IO_SPACE bool diff --git a/arch/mips/dec/ioasic-irq.c b/arch/mips/dec/ioasic-irq.c index 269b22b..880ef88 100644 --- a/arch/mips/dec/ioasic-irq.c +++ b/arch/mips/dec/ioasic-irq.c @@ -55,19 +55,12 @@ static inline void ack_ioasic_irq(unsign fast_iob(); } -static inline void end_ioasic_irq(unsigned int irq) -{ - if (!(irq_desc[irq].status & (IRQ_DISABLED | IRQ_INPROGRESS))) - unmask_ioasic_irq(irq); -} - static struct irq_chip ioasic_irq_type = { .typename = "IO-ASIC", .ack = ack_ioasic_irq, .mask = mask_ioasic_irq, .mask_ack = ack_ioasic_irq, .unmask = unmask_ioasic_irq, - .end = end_ioasic_irq, }; diff --git a/arch/mips/dec/kn02-irq.c b/arch/mips/dec/kn02-irq.c index 5a9be4c..916e46b 100644 --- a/arch/mips/dec/kn02-irq.c +++ b/arch/mips/dec/kn02-irq.c @@ -57,19 +57,12 @@ static void ack_kn02_irq(unsigned int ir iob(); } -static void end_kn02_irq(unsigned int irq) -{ - if (!(irq_desc[irq].status & (IRQ_DISABLED | IRQ_INPROGRESS))) - unmask_kn02_irq(irq); -} - static struct irq_chip kn02_irq_type = { .typename = "KN02-CSR", .ack = ack_kn02_irq, .mask = mask_kn02_irq, .mask_ack = ack_kn02_irq, .unmask = unmask_kn02_irq, - .end = end_kn02_irq, }; diff --git a/arch/mips/emma2rh/common/irq_emma2rh.c b/arch/mips/emma2rh/common/irq_emma2rh.c index 59b9829..8d880f0 100644 --- a/arch/mips/emma2rh/common/irq_emma2rh.c +++ b/arch/mips/emma2rh/common/irq_emma2rh.c @@ -56,19 +56,12 @@ static void emma2rh_irq_disable(unsigned ll_emma2rh_irq_disable(irq - emma2rh_irq_base); } -static void emma2rh_irq_end(unsigned int irq) -{ - if (!(irq_desc[irq].status & (IRQ_DISABLED | IRQ_INPROGRESS))) - ll_emma2rh_irq_enable(irq - emma2rh_irq_base); -} - struct irq_chip emma2rh_irq_controller = { .typename = "emma2rh_irq", .ack = emma2rh_irq_disable, .mask = emma2rh_irq_disable, .mask_ack = emma2rh_irq_disable, .unmask = emma2rh_irq_enable, - .end = emma2rh_irq_end, }; void emma2rh_irq_init(u32 irq_base) diff --git a/arch/mips/emma2rh/markeins/irq_markeins.c b/arch/mips/emma2rh/markeins/irq_markeins.c index 3ac4e40..2116d9b 100644 --- a/arch/mips/emma2rh/markeins/irq_markeins.c +++ b/arch/mips/emma2rh/markeins/irq_markeins.c @@ -48,19 +48,12 @@ static void emma2rh_sw_irq_disable(unsig ll_emma2rh_sw_irq_disable(irq - emma2rh_sw_irq_base); } -static void emma2rh_sw_irq_end(unsigned int irq) -{ - if (!(irq_desc[irq].status & (IRQ_DISABLED | IRQ_INPROGRESS))) - ll_emma2rh_sw_irq_enable(irq - emma2rh_sw_irq_base); -} - struct irq_chip emma2rh_sw_irq_controller = { .typename = "emma2rh_sw_irq", .ack = emma2rh_sw_irq_disable, .mask = emma2rh_sw_irq_disable, .mask_ack = emma2rh_sw_irq_disable, .unmask = emma2rh_sw_irq_enable, - .end = emma2rh_sw_irq_end, }; void emma2rh_sw_irq_init(u32 irq_base) diff --git a/arch/mips/jazz/irq.c b/arch/mips/jazz/irq.c index 5c4f50c..f8d417b 100644 --- a/arch/mips/jazz/irq.c +++ b/arch/mips/jazz/irq.c @@ -39,19 +39,12 @@ void disable_r4030_irq(unsigned int irq) spin_unlock_irqrestore(&r4030_lock, flags); } -static void end_r4030_irq(unsigned int irq) -{ - if (!(irq_desc[irq].status & (IRQ_DISABLED|IRQ_INPROGRESS))) - enable_r4030_irq(irq); -} - static struct irq_chip r4030_irq_type = { .typename = "R4030", .ack = disable_r4030_irq, .mask = disable_r4030_irq, .mask_ack = disable_r4030_irq, .unmask = enable_r4030_irq, - .end = end_r4030_irq, }; void __init init_r4030_ints(void) diff --git a/arch/mips/kernel/irq-mv6434x.c b/arch/mips/kernel/irq-mv6434x.c index 6cfb31c..efbd219 100644 --- a/arch/mips/kernel/irq-mv6434x.c +++ b/arch/mips/kernel/irq-mv6434x.c @@ -67,15 +67,6 @@ static inline void unmask_mv64340_irq(un } /* - * End IRQ processing - */ -static void end_mv64340_irq(unsigned int irq) -{ - if (!(irq_desc[irq].status & (IRQ_DISABLED|IRQ_INPROGRESS))) - unmask_mv64340_irq(irq); -} - -/* * Interrupt handler for interrupts coming from the Marvell chip. * It could be built in ethernet ports etc... */ @@ -106,7 +97,6 @@ struct irq_chip mv64340_irq_type = { .mask = mask_mv64340_irq, .mask_ack = mask_mv64340_irq, .unmask = unmask_mv64340_irq, - .end = end_mv64340_irq, }; void __init mv64340_irq_init(unsigned int base) diff --git a/arch/mips/kernel/irq-rm7000.c b/arch/mips/kernel/irq-rm7000.c index ddcc2a5..123324b 100644 --- a/arch/mips/kernel/irq-rm7000.c +++ b/arch/mips/kernel/irq-rm7000.c @@ -29,19 +29,12 @@ static inline void mask_rm7k_irq(unsigne clear_c0_intcontrol(0x100 << (irq - irq_base)); } -static void rm7k_cpu_irq_end(unsigned int irq) -{ - if (!(irq_desc[irq].status & (IRQ_DISABLED | IRQ_INPROGRESS))) - unmask_rm7k_irq(irq); -} - static struct irq_chip rm7k_irq_controller = { .typename = "RM7000", .ack = mask_rm7k_irq, .mask = mask_rm7k_irq, .mask_ack = mask_rm7k_irq, .unmask = unmask_rm7k_irq, - .end = rm7k_cpu_irq_end, }; void __init rm7k_cpu_irq_init(int base) diff --git a/arch/mips/kernel/irq-rm9000.c b/arch/mips/kernel/irq-rm9000.c index ba6440c..0e6f4c5 100644 --- a/arch/mips/kernel/irq-rm9000.c +++ b/arch/mips/kernel/irq-rm9000.c @@ -80,19 +80,12 @@ static void rm9k_perfcounter_irq_shutdow on_each_cpu(local_rm9k_perfcounter_irq_shutdown, (void *) irq, 0, 1); } -static void rm9k_cpu_irq_end(unsigned int irq) -{ - if (!(irq_desc[irq].status & (IRQ_DISABLED | IRQ_INPROGRESS))) - unmask_rm9k_irq(irq); -} - static struct irq_chip rm9k_irq_controller = { .typename = "RM9000", .ack = mask_rm9k_irq, .mask = mask_rm9k_irq, .mask_ack = mask_rm9k_irq, .unmask = unmask_rm9k_irq, - .end = rm9k_cpu_irq_end, }; static struct irq_chip rm9k_perfcounter_irq = { @@ -103,7 +96,6 @@ static struct irq_chip rm9k_perfcounter_ .mask = mask_rm9k_irq, .mask_ack = mask_rm9k_irq, .unmask = unmask_rm9k_irq, - .end = rm9k_cpu_irq_end, }; unsigned int rm9000_perfcount_irq; diff --git a/arch/mips/kernel/irq_cpu.c b/arch/mips/kernel/irq_cpu.c index be5ac23..7634a66 100644 --- a/arch/mips/kernel/irq_cpu.c +++ b/arch/mips/kernel/irq_cpu.c @@ -50,12 +50,6 @@ static inline void mask_mips_irq(unsigne irq_disable_hazard(); } -static void mips_cpu_irq_end(unsigned int irq) -{ - if (!(irq_desc[irq].status & (IRQ_DISABLED | IRQ_INPROGRESS))) - unmask_mips_irq(irq); -} - static struct irq_chip mips_cpu_irq_controller = { .typename = "MIPS", .ack = mask_mips_irq, @@ -63,7 +57,6 @@ static struct irq_chip mips_cpu_irq_cont .mask_ack = mask_mips_irq, .unmask = unmask_mips_irq, .eoi = unmask_mips_irq, - .end = mips_cpu_irq_end, }; /* diff --git a/arch/mips/lasat/interrupt.c b/arch/mips/lasat/interrupt.c index 4a84a7b..2affa5f 100644 --- a/arch/mips/lasat/interrupt.c +++ b/arch/mips/lasat/interrupt.c @@ -44,19 +44,12 @@ void enable_lasat_irq(unsigned int irq_n *lasat_int_mask |= (1 << irq_nr) << lasat_int_mask_shift; } -static void end_lasat_irq(unsigned int irq) -{ - if (!(irq_desc[irq].status & (IRQ_DISABLED|IRQ_INPROGRESS))) - enable_lasat_irq(irq); -} - static struct irq_chip lasat_irq_type = { .typename = "Lasat", .ack = disable_lasat_irq, .mask = disable_lasat_irq, .mask_ack = disable_lasat_irq, .unmask = enable_lasat_irq, - .end = end_lasat_irq, }; static inline int ls1bit32(unsigned int x) diff --git a/arch/mips/momentum/ocelot_c/cpci-irq.c b/arch/mips/momentum/ocelot_c/cpci-irq.c index e5a4a0a..bb11fef 100644 --- a/arch/mips/momentum/ocelot_c/cpci-irq.c +++ b/arch/mips/momentum/ocelot_c/cpci-irq.c @@ -66,15 +66,6 @@ static inline void unmask_cpci_irq(unsig } /* - * End IRQ processing - */ -static void end_cpci_irq(unsigned int irq) -{ - if (!(irq_desc[irq].status & (IRQ_DISABLED|IRQ_INPROGRESS))) - unmask_cpci_irq(irq); -} - -/* * Interrupt handler for interrupts coming from the FPGA chip. * It could be built in ethernet ports etc... */ @@ -98,7 +89,6 @@ struct irq_chip cpci_irq_type = { .mask = mask_cpci_irq, .mask_ack = mask_cpci_irq, .unmask = unmask_cpci_irq, - .end = end_cpci_irq, }; void cpci_irq_init(void) diff --git a/arch/mips/momentum/ocelot_c/uart-irq.c b/arch/mips/momentum/ocelot_c/uart-irq.c index 0029f00..a7a80c0 100644 --- a/arch/mips/momentum/ocelot_c/uart-irq.c +++ b/arch/mips/momentum/ocelot_c/uart-irq.c @@ -60,15 +60,6 @@ static inline void unmask_uart_irq(unsig } /* - * End IRQ processing - */ -static void end_uart_irq(unsigned int irq) -{ - if (!(irq_desc[irq].status & (IRQ_DISABLED|IRQ_INPROGRESS))) - unmask_uart_irq(irq); -} - -/* * Interrupt handler for interrupts coming from the FPGA chip. */ void ll_uart_irq(void) @@ -91,7 +82,6 @@ struct irq_chip uart_irq_type = { .mask = mask_uart_irq, .mask_ack = mask_uart_irq, .unmask = unmask_uart_irq, - .end = end_uart_irq, }; void uart_irq_init(void) diff --git a/arch/mips/philips/pnx8550/common/int.c b/arch/mips/philips/pnx8550/common/int.c index 0dc2393..2c36c10 100644 --- a/arch/mips/philips/pnx8550/common/int.c +++ b/arch/mips/philips/pnx8550/common/int.c @@ -158,20 +158,12 @@ int pnx8550_set_gic_priority(int irq, in return prev_priority; } -static void end_irq(unsigned int irq) -{ - if (!(irq_desc[irq].status & (IRQ_DISABLED|IRQ_INPROGRESS))) { - unmask_irq(irq); - } -} - static struct irq_chip level_irq_type = { .typename = "PNX Level IRQ", .ack = mask_irq, .mask = mask_irq, .mask_ack = mask_irq, .unmask = unmask_irq, - .end = end_irq, }; static struct irqaction gic_action = { diff --git a/arch/mips/sgi-ip22/ip22-int.c b/arch/mips/sgi-ip22/ip22-int.c index c7b1380..c44f8be 100644 --- a/arch/mips/sgi-ip22/ip22-int.c +++ b/arch/mips/sgi-ip22/ip22-int.c @@ -51,19 +51,12 @@ static void disable_local0_irq(unsigned sgint->imask0 &= ~(1 << (irq - SGINT_LOCAL0)); } -static void end_local0_irq (unsigned int irq) -{ - if (!(irq_desc[irq].status & (IRQ_DISABLED|IRQ_INPROGRESS))) - enable_local0_irq(irq); -} - static struct irq_chip ip22_local0_irq_type = { .typename = "IP22 local 0", .ack = disable_local0_irq, .mask = disable_local0_irq, .mask_ack = disable_local0_irq, .unmask = enable_local0_irq, - .end = end_local0_irq, }; static void enable_local1_irq(unsigned int irq) @@ -79,19 +72,12 @@ void disable_local1_irq(unsigned int irq sgint->imask1 &= ~(1 << (irq - SGINT_LOCAL1)); } -static void end_local1_irq (unsigned int irq) -{ - if (!(irq_desc[irq].status & (IRQ_DISABLED|IRQ_INPROGRESS))) - enable_local1_irq(irq); -} - static struct irq_chip ip22_local1_irq_type = { .typename = "IP22 local 1", .ack = disable_local1_irq, .mask = disable_local1_irq, .mask_ack = disable_local1_irq, .unmask = enable_local1_irq, - .end = end_local1_irq, }; static void enable_local2_irq(unsigned int irq) @@ -107,19 +93,12 @@ void disable_local2_irq(unsigned int irq sgint->imask0 &= ~(1 << (SGI_MAP_0_IRQ - SGINT_LOCAL0)); } -static void end_local2_irq (unsigned int irq) -{ - if (!(irq_desc[irq].status & (IRQ_DISABLED|IRQ_INPROGRESS))) - enable_local2_irq(irq); -} - static struct irq_chip ip22_local2_irq_type = { .typename = "IP22 local 2", .ack = disable_local2_irq, .mask = disable_local2_irq, .mask_ack = disable_local2_irq, .unmask = enable_local2_irq, - .end = end_local2_irq, }; static void enable_local3_irq(unsigned int irq) @@ -135,19 +114,12 @@ void disable_local3_irq(unsigned int irq sgint->imask1 &= ~(1 << (SGI_MAP_1_IRQ - SGINT_LOCAL1)); } -static void end_local3_irq (unsigned int irq) -{ - if (!(irq_desc[irq].status & (IRQ_DISABLED|IRQ_INPROGRESS))) - enable_local3_irq(irq); -} - static struct irq_chip ip22_local3_irq_type = { .typename = "IP22 local 3", .ack = disable_local3_irq, .mask = disable_local3_irq, .mask_ack = disable_local3_irq, .unmask = enable_local3_irq, - .end = end_local3_irq, }; static void indy_local0_irqdispatch(void) diff --git a/arch/mips/sgi-ip27/ip27-irq.c b/arch/mips/sgi-ip27/ip27-irq.c index 5f8835b..319f880 100644 --- a/arch/mips/sgi-ip27/ip27-irq.c +++ b/arch/mips/sgi-ip27/ip27-irq.c @@ -332,13 +332,6 @@ static inline void disable_bridge_irq(un intr_disconnect_level(cpu, swlevel); } -static void end_bridge_irq(unsigned int irq) -{ - if (!(irq_desc[irq].status & (IRQ_DISABLED|IRQ_INPROGRESS)) && - irq_desc[irq].action) - enable_bridge_irq(irq); -} - static struct irq_chip bridge_irq_type = { .typename = "bridge", .startup = startup_bridge_irq, @@ -347,7 +340,6 @@ static struct irq_chip bridge_irq_type = .mask = disable_bridge_irq, .mask_ack = disable_bridge_irq, .unmask = enable_bridge_irq, - .end = end_bridge_irq, }; void __devinit register_bridge_irq(unsigned int irq) diff --git a/arch/mips/sgi-ip27/ip27-timer.c b/arch/mips/sgi-ip27/ip27-timer.c index 7d36172..c20e989 100644 --- a/arch/mips/sgi-ip27/ip27-timer.c +++ b/arch/mips/sgi-ip27/ip27-timer.c @@ -180,10 +180,6 @@ static void disable_rt_irq(unsigned int { } -static void end_rt_irq(unsigned int irq) -{ -} - static struct irq_chip rt_irq_type = { .typename = "SN HUB RT timer", .ack = disable_rt_irq, @@ -191,7 +187,6 @@ static struct irq_chip rt_irq_type = { .mask_ack = disable_rt_irq, .unmask = enable_rt_irq, .eoi = enable_rt_irq, - .end = end_rt_irq, }; static struct irqaction rt_irqaction = { diff --git a/arch/mips/tx4927/common/tx4927_irq.c b/arch/mips/tx4927/common/tx4927_irq.c index 21873de..bd64c16 100644 --- a/arch/mips/tx4927/common/tx4927_irq.c +++ b/arch/mips/tx4927/common/tx4927_irq.c @@ -114,11 +114,9 @@ static const u32 tx4927_irq_debug_flag = static void tx4927_irq_cp0_enable(unsigned int irq); static void tx4927_irq_cp0_disable(unsigned int irq); -static void tx4927_irq_cp0_end(unsigned int irq); static void tx4927_irq_pic_enable(unsigned int irq); static void tx4927_irq_pic_disable(unsigned int irq); -static void tx4927_irq_pic_end(unsigned int irq); /* * Kernel structs for all pic's @@ -131,7 +129,6 @@ static struct irq_chip tx4927_irq_cp0_ty .mask = tx4927_irq_cp0_disable, .mask_ack = tx4927_irq_cp0_disable, .unmask = tx4927_irq_cp0_enable, - .end = tx4927_irq_cp0_end, }; #define TX4927_PIC_NAME "TX4927-PIC" @@ -141,7 +138,6 @@ static struct irq_chip tx4927_irq_pic_ty .mask = tx4927_irq_pic_disable, .mask_ack = tx4927_irq_pic_disable, .unmask = tx4927_irq_pic_enable, - .end = tx4927_irq_pic_end, }; #define TX4927_PIC_ACTION(s) { no_action, 0, CPU_MASK_NONE, s, NULL, NULL } @@ -214,15 +210,6 @@ static void tx4927_irq_cp0_disable(unsig tx4927_irq_cp0_modify(CCP0_STATUS, tx4927_irq_cp0_mask(irq), 0); } -static void tx4927_irq_cp0_end(unsigned int irq) -{ - TX4927_IRQ_DPRINTK(TX4927_IRQ_CP0_ENDIRQ, "irq=%d \n", irq); - - if (!(irq_desc[irq].status & (IRQ_DISABLED | IRQ_INPROGRESS))) { - tx4927_irq_cp0_enable(irq); - } -} - /* * Functions for pic */ @@ -376,15 +363,6 @@ static void tx4927_irq_pic_disable(unsig tx4927_irq_pic_mask(irq), 0); } -static void tx4927_irq_pic_end(unsigned int irq) -{ - TX4927_IRQ_DPRINTK(TX4927_IRQ_PIC_ENDIRQ, "irq=%d\n", irq); - - if (!(irq_desc[irq].status & (IRQ_DISABLED | IRQ_INPROGRESS))) { - tx4927_irq_pic_enable(irq); - } -} - /* * Main init functions */ diff --git a/arch/mips/tx4927/toshiba_rbtx4927/toshiba_rbtx4927_irq.c b/arch/mips/tx4927/toshiba_rbtx4927/toshiba_rbtx4927_irq.c index 34cdb2a..ce4ef10 100644 --- a/arch/mips/tx4927/toshiba_rbtx4927/toshiba_rbtx4927_irq.c +++ b/arch/mips/tx4927/toshiba_rbtx4927/toshiba_rbtx4927_irq.c @@ -223,7 +223,6 @@ extern void mask_and_ack_8259A(unsigned static void toshiba_rbtx4927_irq_ioc_enable(unsigned int irq); static void toshiba_rbtx4927_irq_ioc_disable(unsigned int irq); -static void toshiba_rbtx4927_irq_ioc_end(unsigned int irq); #ifdef CONFIG_TOSHIBA_FPCIB0 static void toshiba_rbtx4927_irq_isa_enable(unsigned int irq); @@ -239,7 +238,6 @@ static struct irq_chip toshiba_rbtx4927_ .mask = toshiba_rbtx4927_irq_ioc_disable, .mask_ack = toshiba_rbtx4927_irq_ioc_disable, .unmask = toshiba_rbtx4927_irq_ioc_enable, - .end = toshiba_rbtx4927_irq_ioc_end, }; #define TOSHIBA_RBTX4927_IOC_INTR_ENAB 0xbc002000 #define TOSHIBA_RBTX4927_IOC_INTR_STAT 0xbc002006 @@ -388,23 +386,6 @@ static void toshiba_rbtx4927_irq_ioc_dis TOSHIBA_RBTX4927_WR08(TOSHIBA_RBTX4927_IOC_INTR_ENAB, v); } -static void toshiba_rbtx4927_irq_ioc_end(unsigned int irq) -{ - TOSHIBA_RBTX4927_IRQ_DPRINTK(TOSHIBA_RBTX4927_IRQ_IOC_ENDIRQ, - "irq=%d\n", irq); - - if (irq < TOSHIBA_RBTX4927_IRQ_IOC_BEG - || irq > TOSHIBA_RBTX4927_IRQ_IOC_END) { - TOSHIBA_RBTX4927_IRQ_DPRINTK(TOSHIBA_RBTX4927_IRQ_EROR, - "bad irq=%d\n", irq); - panic("\n"); - } - - if (!(irq_desc[irq].status & (IRQ_DISABLED | IRQ_INPROGRESS))) { - toshiba_rbtx4927_irq_ioc_enable(irq); - } -} - /**********************************************************************************/ /* Functions for isa */ diff --git a/arch/mips/tx4938/common/irq.c b/arch/mips/tx4938/common/irq.c index 42e1276..a347b42 100644 --- a/arch/mips/tx4938/common/irq.c +++ b/arch/mips/tx4938/common/irq.c @@ -39,11 +39,9 @@ static void tx4938_irq_cp0_enable(unsigned int irq); static void tx4938_irq_cp0_disable(unsigned int irq); -static void tx4938_irq_cp0_end(unsigned int irq); static void tx4938_irq_pic_enable(unsigned int irq); static void tx4938_irq_pic_disable(unsigned int irq); -static void tx4938_irq_pic_end(unsigned int irq); /**********************************************************************************/ /* Kernel structs for all pic's */ @@ -56,7 +54,6 @@ static struct irq_chip tx4938_irq_cp0_ty .mask = tx4938_irq_cp0_disable, .mask_ack = tx4938_irq_cp0_disable, .unmask = tx4938_irq_cp0_enable, - .end = tx4938_irq_cp0_end, }; #define TX4938_PIC_NAME "TX4938-PIC" @@ -66,7 +63,6 @@ static struct irq_chip tx4938_irq_pic_ty .mask = tx4938_irq_pic_disable, .mask_ack = tx4938_irq_pic_disable, .unmask = tx4938_irq_pic_enable, - .end = tx4938_irq_pic_end, }; static struct irqaction tx4938_irq_pic_action = { @@ -104,14 +100,6 @@ tx4938_irq_cp0_disable(unsigned int irq) clear_c0_status(tx4938_irq_cp0_mask(irq)); } -static void -tx4938_irq_cp0_end(unsigned int irq) -{ - if (!(irq_desc[irq].status & (IRQ_DISABLED | IRQ_INPROGRESS))) { - tx4938_irq_cp0_enable(irq); - } -} - /**********************************************************************************/ /* Functions for pic */ /**********************************************************************************/ @@ -269,14 +257,6 @@ tx4938_irq_pic_disable(unsigned int irq) tx4938_irq_pic_mask(irq), 0); } -static void -tx4938_irq_pic_end(unsigned int irq) -{ - if (!(irq_desc[irq].status & (IRQ_DISABLED | IRQ_INPROGRESS))) { - tx4938_irq_pic_enable(irq); - } -} - /**********************************************************************************/ /* Main init functions */ /**********************************************************************************/ diff --git a/arch/mips/tx4938/toshiba_rbtx4938/irq.c b/arch/mips/tx4938/toshiba_rbtx4938/irq.c index 8c87a35..b6f363d 100644 --- a/arch/mips/tx4938/toshiba_rbtx4938/irq.c +++ b/arch/mips/tx4938/toshiba_rbtx4938/irq.c @@ -89,7 +89,6 @@ IRQ Device static void toshiba_rbtx4938_irq_ioc_enable(unsigned int irq); static void toshiba_rbtx4938_irq_ioc_disable(unsigned int irq); -static void toshiba_rbtx4938_irq_ioc_end(unsigned int irq); #define TOSHIBA_RBTX4938_IOC_NAME "RBTX4938-IOC" static struct irq_chip toshiba_rbtx4938_irq_ioc_type = { @@ -98,7 +97,6 @@ static struct irq_chip toshiba_rbtx4938_ .mask = toshiba_rbtx4938_irq_ioc_disable, .mask_ack = toshiba_rbtx4938_irq_ioc_disable, .unmask = toshiba_rbtx4938_irq_ioc_enable, - .end = toshiba_rbtx4938_irq_ioc_end, }; #define TOSHIBA_RBTX4938_IOC_INTR_ENAB 0xb7f02000 @@ -167,14 +165,6 @@ toshiba_rbtx4938_irq_ioc_disable(unsigne TX4938_RD08(TOSHIBA_RBTX4938_IOC_INTR_ENAB); } -static void -toshiba_rbtx4938_irq_ioc_end(unsigned int irq) -{ - if (!(irq_desc[irq].status & (IRQ_DISABLED | IRQ_INPROGRESS))) { - toshiba_rbtx4938_irq_ioc_enable(irq); - } -} - extern void __init txx9_spi_irqinit(int irc_irq); void __init arch_init_irq(void) diff --git a/arch/mips/vr41xx/common/icu.c b/arch/mips/vr41xx/common/icu.c index 54b92a7..c075261 100644 --- a/arch/mips/vr41xx/common/icu.c +++ b/arch/mips/vr41xx/common/icu.c @@ -427,19 +427,12 @@ static void enable_sysint1_irq(unsigned icu1_set(MSYSINT1REG, 1 << SYSINT1_IRQ_TO_PIN(irq)); } -static void end_sysint1_irq(unsigned int irq) -{ - if (!(irq_desc[irq].status & (IRQ_DISABLED | IRQ_INPROGRESS))) - icu1_set(MSYSINT1REG, 1 << SYSINT1_IRQ_TO_PIN(irq)); -} - static struct irq_chip sysint1_irq_type = { .typename = "SYSINT1", .ack = disable_sysint1_irq, .mask = disable_sysint1_irq, .mask_ack = disable_sysint1_irq, .unmask = enable_sysint1_irq, - .end = end_sysint1_irq, }; static void disable_sysint2_irq(unsigned int irq) @@ -452,19 +445,12 @@ static void enable_sysint2_irq(unsigned icu2_set(MSYSINT2REG, 1 << SYSINT2_IRQ_TO_PIN(irq)); } -static void end_sysint2_irq(unsigned int irq) -{ - if (!(irq_desc[irq].status & (IRQ_DISABLED | IRQ_INPROGRESS))) - icu2_set(MSYSINT2REG, 1 << SYSINT2_IRQ_TO_PIN(irq)); -} - static struct irq_chip sysint2_irq_type = { .typename = "SYSINT2", .ack = disable_sysint2_irq, .mask = disable_sysint2_irq, .mask_ack = disable_sysint2_irq, .unmask = enable_sysint2_irq, - .end = end_sysint2_irq, }; static inline int set_sysint1_assign(unsigned int irq, unsigned char assign) -- 1.4.4.1 From sshtylyov@ru.mvista.com Fri Dec 1 15:33:21 2006 Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 01 Dec 2006 15:33:25 +0000 (GMT) Received: from h155.mvista.com ([63.81.120.155]:57568 "EHLO imap.sh.mvista.com") by ftp.linux-mips.org with ESMTP id S20038419AbWLAPdV (ORCPT ); Fri, 1 Dec 2006 15:33:21 +0000 Received: from [192.168.1.248] (unknown [10.150.0.9]) by imap.sh.mvista.com (Postfix) with ESMTP id 9D8C43ECA; Fri, 1 Dec 2006 07:33:17 -0800 (PST) Message-ID: <45704B9D.5090805@ru.mvista.com> Date: Fri, 01 Dec 2006 18:34:53 +0300 From: Sergei Shtylyov Organization: MontaVista Software Inc. User-Agent: Mozilla/5.0 (X11; U; Linux i686; rv:1.7.2) Gecko/20040803 X-Accept-Language: ru, en-us, en-gb MIME-Version: 1.0 To: Atsushi Nemoto Cc: vagabon.xyz@gmail.com, linux-mips@linux-mips.org Subject: Re: Is _do_IRQ() not needed anymore ? References: <20061201.191049.63741937.nemoto@toshiba-tops.co.jp> <45704569.8000807@ru.mvista.com> <20061202.002214.51866784.anemo@mba.ocn.ne.jp> <45704A4D.9050303@ru.mvista.com> In-Reply-To: <45704A4D.9050303@ru.mvista.com> Content-Type: text/plain; charset=us-ascii; 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: 13305 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: sshtylyov@ru.mvista.com Precedence: bulk X-list: linux-mips Hello. Sergei Shtylyov wrote: >>>> You can use both irq_cpu and i8259 same time. :) >>> What's wrong with 8259 I wonder? It's happily converted to genirq >>> by other arches... >> Indeed. I missed other arch's i8259.c had changed. Maybe we should >> update i8259.c entirely. > The question is what flow to use: level/edge ones used in x86 code > and actually intended for simplistic controllers, not the likes of 8259 > OR the "fasteoi" one used in PowerPC code and (as it turned out in my Sorry for some confusion: in arch/powerpc/ level flow is always used for 8259 code (just because it fits both leve and edge cases)... > earlier discussion in linuxppc-dev) intended for the controllers that > are smart enough to mask off the lower-priority IRQs when getting the > top level one acknowledged and unmask them upon EOI command... However, Benjamin Herrenschmidt said that 8259 should have used fasteoi flow instead since it was intended for that exact type of controllers (he claimed to have proposed this flow initially). >> --- >> Atsushi Nemoto WBR, Sergei From macro@linux-mips.org Fri Dec 1 15:36:50 2006 Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 01 Dec 2006 15:36:55 +0000 (GMT) Received: from pollux.ds.pg.gda.pl ([153.19.208.7]:47374 "EHLO pollux.ds.pg.gda.pl") by ftp.linux-mips.org with ESMTP id S20038324AbWLAPgu (ORCPT ); Fri, 1 Dec 2006 15:36:50 +0000 Received: from localhost (localhost [127.0.0.1]) by pollux.ds.pg.gda.pl (Postfix) with ESMTP id 9D480E1D01; Fri, 1 Dec 2006 16:36:37 +0100 (CET) X-Virus-Scanned: by amavisd-new at pollux.ds.pg.gda.pl Received: from pollux.ds.pg.gda.pl ([127.0.0.1]) by localhost (pollux.ds.pg.gda.pl [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qWNuSMgh8ZuD; Fri, 1 Dec 2006 16:36:37 +0100 (CET) Received: from piorun.ds.pg.gda.pl (piorun.ds.pg.gda.pl [153.19.208.8]) by pollux.ds.pg.gda.pl (Postfix) with ESMTP id 3C29BE1CAE; Fri, 1 Dec 2006 16:36:37 +0100 (CET) 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 kB1FalGR021234; Fri, 1 Dec 2006 16:36:47 +0100 Date: Fri, 1 Dec 2006 15:36:44 +0000 (GMT) From: "Maciej W. Rozycki" To: Franck Bui-Huu cc: Ralf Baechle , Atsushi Nemoto , linux-mips Subject: Re: [PATCH] Compile __do_IRQ() when really needed [take #2] In-Reply-To: <45704B26.9040202@innova-card.com> Message-ID: References: <45704B26.9040202@innova-card.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: ClamAV 0.88.6/2267/Fri Dec 1 05:29:21 2006 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: 13306 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, 1 Dec 2006, Franck Bui-Huu wrote: > diff --git a/arch/mips/dec/ioasic-irq.c b/arch/mips/dec/ioasic-irq.c > index 269b22b..880ef88 100644 > --- a/arch/mips/dec/ioasic-irq.c > +++ b/arch/mips/dec/ioasic-irq.c > @@ -55,19 +55,12 @@ static inline void ack_ioasic_irq(unsign > fast_iob(); > } > > -static inline void end_ioasic_irq(unsigned int irq) > -{ > - if (!(irq_desc[irq].status & (IRQ_DISABLED | IRQ_INPROGRESS))) > - unmask_ioasic_irq(irq); > -} > - > static struct irq_chip ioasic_irq_type = { > .typename = "IO-ASIC", > .ack = ack_ioasic_irq, > .mask = mask_ioasic_irq, > .mask_ack = ack_ioasic_irq, > .unmask = unmask_ioasic_irq, > - .end = end_ioasic_irq, > }; > > Well, end_ioasic_irq() is called from end_ioasic_dma_irq(), sorry. ;-) Maciej From vagabon.xyz@gmail.com Fri Dec 1 15:40:39 2006 Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 01 Dec 2006 15:40:43 +0000 (GMT) Received: from wr-out-0506.google.com ([64.233.184.238]:51019 "EHLO wr-out-0506.google.com") by ftp.linux-mips.org with ESMTP id S20038423AbWLAPkj (ORCPT ); Fri, 1 Dec 2006 15:40:39 +0000 Received: by wr-out-0506.google.com with SMTP id i32so937481wra for ; Fri, 01 Dec 2006 07:40:38 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=K/iX8tITw9zCT6xfR5qGOoSUe/HjcAx2wQHeRJX8zbkK3YbZqgfCNxgAkzODi8OfOwNlMgymlYZTrgQFTecWHVhENiqU+dSmsbM2N3NQ3WLA1+Aq8C+f/AaHuTiyrVBe+oWqKknmCZ3Mwx2Cp84g7MBzGBrbLfIroB1XUIqNb9M= Received: by 10.78.149.15 with SMTP id w15mr4921584hud.1164987637295; Fri, 01 Dec 2006 07:40:37 -0800 (PST) Received: by 10.78.124.19 with HTTP; Fri, 1 Dec 2006 07:40:37 -0800 (PST) Message-ID: Date: Fri, 1 Dec 2006 16:40:37 +0100 From: "Franck Bui-Huu" To: "Maciej W. Rozycki" Subject: Re: [PATCH] Compile __do_IRQ() when really needed [take #2] Cc: "Ralf Baechle" , "Atsushi Nemoto" , linux-mips In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <45704B26.9040202@innova-card.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: 13307 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 On 12/1/06, Maciej W. Rozycki wrote: > > Well, end_ioasic_irq() is called from end_ioasic_dma_irq(), sorry. ;-) > no problem, I should had caught this by my own. Let's do it again... thanks -- Franck From anemo@mba.ocn.ne.jp Fri Dec 1 15:45:31 2006 Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 01 Dec 2006 15:45:36 +0000 (GMT) Received: from mba.ocn.ne.jp ([210.190.142.172]:29905 "HELO smtp.mba.ocn.ne.jp") by ftp.linux-mips.org with SMTP id S20037895AbWLAPpb (ORCPT ); Fri, 1 Dec 2006 15:45:31 +0000 Received: from localhost (p7250-ipad213funabasi.chiba.ocn.ne.jp [124.85.72.250]) by smtp.mba.ocn.ne.jp (Postfix) with ESMTP id 8109EBDA5; Sat, 2 Dec 2006 00:45:27 +0900 (JST) Date: Sat, 02 Dec 2006 00:45:27 +0900 (JST) Message-Id: <20061202.004527.52131670.anemo@mba.ocn.ne.jp> To: vagabon.xyz@gmail.com Cc: ralf@linux-mips.org, linux-mips@linux-mips.org Subject: Re: [PATCH] Compile __do_IRQ() when really needed From: Atsushi Nemoto In-Reply-To: <457042FF.2060908@innova-card.com> References: <457042FF.2060908@innova-card.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 3.3 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: 13308 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 Fri, 01 Dec 2006 15:58:07 +0100, Franck Bui-Huu wrote: > @@ -216,6 +217,7 @@ config MACH_JAZZ > select SYS_SUPPORTS_32BIT_KERNEL > select SYS_SUPPORTS_64BIT_KERNEL if EXPERIMENTAL > select SYS_SUPPORTS_100HZ > + select GENERIC_HARDIRQS_NO__DO_IRQ > help > This a family of machines based on the MIPS R4030 chipset which was > used by several vendors to build RISC/os and Windows NT workstations. JAZZ uses i8259 which is not converted to irq flow handler yet. > @@ -468,6 +473,7 @@ config DDB5477 > config MACH_VR41XX > bool "NEC VR41XX-based machines" > select SYS_HAS_CPU_VR41XX > + select GENERIC_HARDIRQS_NO__DO_IRQ > > config PMC_YOSEMITE > bool "PMC-Sierra Yosemite eval board" Same here. > @@ -519,6 +525,7 @@ config MARKEINS > select SYS_SUPPORTS_BIG_ENDIAN > select SYS_SUPPORTS_LITTLE_ENDIAN > select SYS_HAS_CPU_R5000 > + select GENERIC_HARDIRQS_NO__DO_IRQ > help > This enables support for the R5432-based NEC Mark-eins > boards with R5500 CPU. For now emma2rh_gpio_irq_controller still needs __do_IRQ(). > @@ -539,6 +546,7 @@ config SGI_IP22 > select SYS_SUPPORTS_32BIT_KERNEL > select SYS_SUPPORTS_64BIT_KERNEL > select SYS_SUPPORTS_BIG_ENDIAN > + select GENERIC_HARDIRQS_NO__DO_IRQ > help > This are the SGI Indy, Challenge S and Indigo2, as well as certain > OEM variants like the Tandem CMN B006S. To compile a Linux kernel For now ip22_eisa1_irq_type and ip22_eisa2_irq_type need __do_IRQ(). > @@ -739,6 +748,7 @@ config TOSHIBA_RBTX4927 > select SYS_SUPPORTS_64BIT_KERNEL > select SYS_SUPPORTS_BIG_ENDIAN > select TOSHIBA_BOARDS > + select GENERIC_HARDIRQS_NO__DO_IRQ > help > This Toshiba board is based on the TX4927 processor. Say Y here to > support this machine type For now toshiba_rbtx4927_irq_isa_type still needs __do_IRQ(). > @@ -758,6 +768,7 @@ config TOSHIBA_RBTX4938 > select SYS_SUPPORTS_LITTLE_ENDIAN > select SYS_SUPPORTS_BIG_ENDIAN > select TOSHIBA_BOARDS > + select GENERIC_HARDIRQS_NO__DO_IRQ > help > This Toshiba board is based on the TX4938 processor. Say Y here to > support this machine type RBTX4938(rbhma4500) uses i8259 which is not converted to irq flow handler yet. > @@ -214,15 +210,6 @@ static void tx4927_irq_cp0_disable(unsig > tx4927_irq_cp0_modify(CCP0_STATUS, tx4927_irq_cp0_mask(irq), 0); > } > > -static void tx4927_irq_cp0_end(unsigned int irq) > -{ > - TX4927_IRQ_DPRINTK(TX4927_IRQ_CP0_ENDIRQ, "irq=%d \n", irq); > - > - if (!(irq_desc[irq].status & (IRQ_DISABLED | IRQ_INPROGRESS))) { > - tx4927_irq_cp0_enable(irq); > - } > -} > - > /* > * Functions for pic > */ > @@ -376,15 +363,6 @@ static void tx4927_irq_pic_disable(unsig > tx4927_irq_pic_mask(irq), 0); > } > > -static void tx4927_irq_pic_end(unsigned int irq) > -{ > - TX4927_IRQ_DPRINTK(TX4927_IRQ_PIC_ENDIRQ, "irq=%d\n", irq); > - > - if (!(irq_desc[irq].status & (IRQ_DISABLED | IRQ_INPROGRESS))) { > - tx4927_irq_pic_enable(irq); > - } > -} > - > /* > * Main init functions > */ You can remove those lines too: #define TX4927_IRQ_CP0_ENDIRQ ( 1 << 16 ) #define TX4927_IRQ_PIC_ENDIRQ ( 1 << 26 ) > diff --git a/arch/mips/tx4927/toshiba_rbtx4927/toshiba_rbtx4927_irq.c b/arch/mips/tx4927/toshiba_rbtx4927/toshiba_rbtx4927_irq.c > index 34cdb2a..ce4ef10 100644 > --- a/arch/mips/tx4927/toshiba_rbtx4927/toshiba_rbtx4927_irq.c > +++ b/arch/mips/tx4927/toshiba_rbtx4927/toshiba_rbtx4927_irq.c > @@ -388,23 +386,6 @@ static void toshiba_rbtx4927_irq_ioc_dis > TOSHIBA_RBTX4927_WR08(TOSHIBA_RBTX4927_IOC_INTR_ENAB, v); > } > > -static void toshiba_rbtx4927_irq_ioc_end(unsigned int irq) > -{ > - TOSHIBA_RBTX4927_IRQ_DPRINTK(TOSHIBA_RBTX4927_IRQ_IOC_ENDIRQ, > - "irq=%d\n", irq); > - > - if (irq < TOSHIBA_RBTX4927_IRQ_IOC_BEG > - || irq > TOSHIBA_RBTX4927_IRQ_IOC_END) { > - TOSHIBA_RBTX4927_IRQ_DPRINTK(TOSHIBA_RBTX4927_IRQ_EROR, > - "bad irq=%d\n", irq); > - panic("\n"); > - } > - > - if (!(irq_desc[irq].status & (IRQ_DISABLED | IRQ_INPROGRESS))) { > - toshiba_rbtx4927_irq_ioc_enable(irq); > - } > -} > - > > /**********************************************************************************/ > /* Functions for isa */ You can remove this line too: #define TOSHIBA_RBTX4927_IRQ_IOC_ENDIRQ ( 1 << 16 ) From vagabon.xyz@gmail.com Fri Dec 1 15:47:55 2006 Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 01 Dec 2006 15:47:59 +0000 (GMT) Received: from py-out-1112.google.com ([64.233.166.178]:53315 "EHLO py-out-1112.google.com") by ftp.linux-mips.org with ESMTP id S20038415AbWLAPrz (ORCPT ); Fri, 1 Dec 2006 15:47:55 +0000 Received: by py-out-1112.google.com with SMTP id u52so1930106pyb for ; Fri, 01 Dec 2006 07:47:53 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=R7WdJGHKAWSp3qAl5lgSYBESzqkUrz80GXjL04++DQvz5vEFWdFHMdTWY16jw9X1vSFIOI6d4eVdZGQ23WiRqhscEjM/wy/tOwHGSk8LWY/L4vx/DcGwNWI7Ft8ydYBgrOPeX8Tanne9ocJPEXh8qWecXzcoJj7EN0uvLvBwosI= Received: by 10.78.139.1 with SMTP id m1mr4921709hud.1164988073016; Fri, 01 Dec 2006 07:47:53 -0800 (PST) Received: by 10.78.124.19 with HTTP; Fri, 1 Dec 2006 07:47:52 -0800 (PST) Message-ID: Date: Fri, 1 Dec 2006 16:47:52 +0100 From: "Franck Bui-Huu" To: "Yoichi Yuasa" Subject: Re: [PATCH] Compile __do_IRQ() when really needed Cc: ralf@linux-mips.org, anemo@mba.ocn.ne.jp, linux-mips@linux-mips.org In-Reply-To: <20061202002937.7b4cb749.yoichi_yuasa@tripeaks.co.jp> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <457042FF.2060908@innova-card.com> <20061202002937.7b4cb749.yoichi_yuasa@tripeaks.co.jp> 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: 13309 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, On 12/1/06, Yoichi Yuasa wrote: > Hi, > > On Fri, 01 Dec 2006 15:58:07 +0100 > Franck Bui-Huu wrote: > > > config MACH_VR41XX > > bool "NEC VR41XX-based machines" > > select SYS_HAS_CPU_VR41XX > > + select GENERIC_HARDIRQS_NO__DO_IRQ > > NEC CMBVR4133 has i8259. > The other vr41xx boards have no problem. > Thanks for testing. -- Franck From sshtylyov@ru.mvista.com Fri Dec 1 15:57:38 2006 Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 01 Dec 2006 15:57:42 +0000 (GMT) Received: from h155.mvista.com ([63.81.120.155]:8161 "EHLO imap.sh.mvista.com") by ftp.linux-mips.org with ESMTP id S20038426AbWLAP5i (ORCPT ); Fri, 1 Dec 2006 15:57:38 +0000 Received: from [192.168.1.248] (unknown [10.150.0.9]) by imap.sh.mvista.com (Postfix) with ESMTP id 04CA13ECA; Fri, 1 Dec 2006 07:57:33 -0800 (PST) Message-ID: <4570514F.8030905@ru.mvista.com> Date: Fri, 01 Dec 2006 18:59:11 +0300 From: Sergei Shtylyov Organization: MontaVista Software Inc. User-Agent: Mozilla/5.0 (X11; U; Linux i686; rv:1.7.2) Gecko/20040803 X-Accept-Language: ru, en-us, en-gb MIME-Version: 1.0 To: Atsushi Nemoto Cc: vagabon.xyz@gmail.com, ralf@linux-mips.org, linux-mips@linux-mips.org Subject: Re: [PATCH] Compile __do_IRQ() when really needed References: <457042FF.2060908@innova-card.com> <20061202.004527.52131670.anemo@mba.ocn.ne.jp> In-Reply-To: <20061202.004527.52131670.anemo@mba.ocn.ne.jp> Content-Type: text/plain; charset=us-ascii; 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: 13310 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: sshtylyov@ru.mvista.com Precedence: bulk X-list: linux-mips Hello. Atsushi Nemoto wrote: >>@@ -758,6 +768,7 @@ config TOSHIBA_RBTX4938 >> select SYS_SUPPORTS_LITTLE_ENDIAN >> select SYS_SUPPORTS_BIG_ENDIAN >> select TOSHIBA_BOARDS >>+ select GENERIC_HARDIRQS_NO__DO_IRQ >> help >> This Toshiba board is based on the TX4938 processor. Say Y here to >> support this machine type > RBTX4938(rbhma4500) uses i8259 which is not converted to irq flow > handler yet. I'm afraid there's some mistake in Kconfig -- RBTX4938 doesn't have 8259 compatible controller. And the backplane that has it isn't supported by the current code anyway. WBR, Sergei From vagabon.xyz@gmail.com Fri Dec 1 16:47:31 2006 Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 01 Dec 2006 16:47:36 +0000 (GMT) Received: from ug-out-1314.google.com ([66.249.92.170]:21748 "EHLO ug-out-1314.google.com") by ftp.linux-mips.org with ESMTP id S20038433AbWLAQrb (ORCPT ); Fri, 1 Dec 2006 16:47:31 +0000 Received: by ug-out-1314.google.com with SMTP id 40so2675671uga for ; Fri, 01 Dec 2006 08:47:31 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=NH1SF9V5GKquyDMv8ezQ7c0252CBQr4a8h7LSO6bh2vVR85NP0hR9fqFSVLsN4j/E6m0qeb008v/M4A1/J+lkvxJm0aVPx+Uxy2ikMr6QrFEsheTkRUcICf/ylAv3OQgRbJyfwB/hNZ6SD/pF01QeNEEerkLpdcBteiGvwPfa4Y= Received: by 10.78.17.1 with SMTP id 1mr4967232huq.1164991649926; Fri, 01 Dec 2006 08:47:29 -0800 (PST) Received: by 10.78.124.19 with HTTP; Fri, 1 Dec 2006 08:47:29 -0800 (PST) Message-ID: Date: Fri, 1 Dec 2006 17:47:29 +0100 From: "Franck Bui-Huu" To: "Atsushi Nemoto" Subject: Re: [PATCH] Compile __do_IRQ() when really needed Cc: ralf@linux-mips.org, linux-mips@linux-mips.org In-Reply-To: <20061202.004527.52131670.anemo@mba.ocn.ne.jp> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <457042FF.2060908@innova-card.com> <20061202.004527.52131670.anemo@mba.ocn.ne.jp> 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: 13311 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 On 12/1/06, Atsushi Nemoto wrote: > On Fri, 01 Dec 2006 15:58:07 +0100, Franck Bui-Huu wrote: > > @@ -216,6 +217,7 @@ config MACH_JAZZ > > select SYS_SUPPORTS_32BIT_KERNEL > > select SYS_SUPPORTS_64BIT_KERNEL if EXPERIMENTAL > > select SYS_SUPPORTS_100HZ > > + select GENERIC_HARDIRQS_NO__DO_IRQ > > help > > This a family of machines based on the MIPS R4030 chipset which was > > used by several vendors to build RISC/os and Windows NT workstations. > > JAZZ uses i8259 which is not converted to irq flow handler yet. > stupid me, I completely forgot this point ! I'm going to take a cool shower before updating that... > > @@ -468,6 +473,7 @@ config DDB5477 > > config MACH_VR41XX > > bool "NEC VR41XX-based machines" > > select SYS_HAS_CPU_VR41XX > > + select GENERIC_HARDIRQS_NO__DO_IRQ > > > > config PMC_YOSEMITE > > bool "PMC-Sierra Yosemite eval board" > > Same here. > are you sure ? I don't see any traces of i8259 selection. Moreover, Yoichi's vr41xx boards seem to have no problem I agree with all the rest. Thanks -- Franck From sshtylyov@ru.mvista.com Fri Dec 1 16:52:38 2006 Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 01 Dec 2006 16:52:43 +0000 (GMT) Received: from h155.mvista.com ([63.81.120.155]:19682 "EHLO imap.sh.mvista.com") by ftp.linux-mips.org with ESMTP id S20038442AbWLAQwi (ORCPT ); Fri, 1 Dec 2006 16:52:38 +0000 Received: from [192.168.1.248] (unknown [10.150.0.9]) by imap.sh.mvista.com (Postfix) with ESMTP id 380433ECA; Fri, 1 Dec 2006 08:52:33 -0800 (PST) Message-ID: <45705E34.2030704@ru.mvista.com> Date: Fri, 01 Dec 2006 19:54:12 +0300 From: Sergei Shtylyov Organization: MontaVista Software Inc. User-Agent: Mozilla/5.0 (X11; U; Linux i686; rv:1.7.2) Gecko/20040803 X-Accept-Language: ru, en-us, en-gb MIME-Version: 1.0 To: Franck Bui-Huu Cc: Atsushi Nemoto , ralf@linux-mips.org, linux-mips@linux-mips.org Subject: Re: [PATCH] Compile __do_IRQ() when really needed References: <457042FF.2060908@innova-card.com> <20061202.004527.52131670.anemo@mba.ocn.ne.jp> In-Reply-To: Content-Type: text/plain; charset=us-ascii; 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: 13312 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: sshtylyov@ru.mvista.com Precedence: bulk X-list: linux-mips Hello. Franck Bui-Huu wrote: >> > @@ -468,6 +473,7 @@ config DDB5477 >> > config MACH_VR41XX >> > bool "NEC VR41XX-based machines" >> > select SYS_HAS_CPU_VR41XX >> > + select GENERIC_HARDIRQS_NO__DO_IRQ >> > >> > config PMC_YOSEMITE >> > bool "PMC-Sierra Yosemite eval board" >> Same here. > are you sure ? I don't see any traces of i8259 selection. > Moreover, Yoichi's vr41xx boards seem to have no problem CMB-Vr4133 has the Rockhopper backplane with 8259 integrated into ALi chip -- and it is supported via CONFIG_ROCKHOPPER. > I agree with all the rest. > Thanks WBR, Sergei From anemo@mba.ocn.ne.jp Fri Dec 1 17:05:48 2006 Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 01 Dec 2006 17:05:54 +0000 (GMT) Received: from mba.ocn.ne.jp ([210.190.142.172]:58109 "HELO smtp.mba.ocn.ne.jp") by ftp.linux-mips.org with SMTP id S20038432AbWLARFs (ORCPT ); Fri, 1 Dec 2006 17:05:48 +0000 Received: from localhost (p7250-ipad213funabasi.chiba.ocn.ne.jp [124.85.72.250]) by smtp.mba.ocn.ne.jp (Postfix) with ESMTP id E7C6CC3E2; Sat, 2 Dec 2006 02:05:44 +0900 (JST) Date: Sat, 02 Dec 2006 02:05:44 +0900 (JST) Message-Id: <20061202.020544.89039198.anemo@mba.ocn.ne.jp> To: vagabon.xyz@gmail.com Cc: ralf@linux-mips.org, linux-mips@linux-mips.org Subject: Re: [PATCH] Compile __do_IRQ() when really needed From: Atsushi Nemoto In-Reply-To: References: <457042FF.2060908@innova-card.com> <20061202.004527.52131670.anemo@mba.ocn.ne.jp> 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 3.3 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: 13313 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 Fri, 1 Dec 2006 17:47:29 +0100, "Franck Bui-Huu" wrote: > > > @@ -468,6 +473,7 @@ config DDB5477 > > > config MACH_VR41XX > > > bool "NEC VR41XX-based machines" > > > select SYS_HAS_CPU_VR41XX > > > + select GENERIC_HARDIRQS_NO__DO_IRQ > > > > > > config PMC_YOSEMITE > > > bool "PMC-Sierra Yosemite eval board" > > > > Same here. > > > > are you sure ? I don't see any traces of i8259 selection. > Moreover, Yoichi's vr41xx boards seem to have no problem Oh I was wrong. I had misread VR41XX as DDB5477... --- Atsushi Nemoto From vagabon.xyz@gmail.com Fri Dec 1 17:11:04 2006 Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 01 Dec 2006 17:11:09 +0000 (GMT) Received: from ug-out-1314.google.com ([66.249.92.175]:50570 "EHLO ug-out-1314.google.com") by ftp.linux-mips.org with ESMTP id S20038451AbWLARLE (ORCPT ); Fri, 1 Dec 2006 17:11:04 +0000 Received: by ug-out-1314.google.com with SMTP id 40so2683354uga for ; Fri, 01 Dec 2006 09:11:04 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=PHuxR868zzzCIiEOyjtIm20XEywHICY3nOxBEqNGPOtHwnQSqS9AbHg/OxJjgXTA5IKFesHS5uxe3EtC31Oj6rzGO/NOnfI4zgU5ZQD3DJAo3ZP+51lIyx6bD451WekJ91Pk5T3tGyD7w/9htb7MHCSxBREk0B43pDzF3xhdnnY= Received: by 10.78.128.11 with SMTP id a11mr5042912hud.1164993063840; Fri, 01 Dec 2006 09:11:03 -0800 (PST) Received: by 10.78.124.19 with HTTP; Fri, 1 Dec 2006 09:11:03 -0800 (PST) Message-ID: Date: Fri, 1 Dec 2006 18:11:03 +0100 From: "Franck Bui-Huu" To: "Sergei Shtylyov" Subject: Re: [PATCH] Compile __do_IRQ() when really needed Cc: "Atsushi Nemoto" , ralf@linux-mips.org, linux-mips@linux-mips.org In-Reply-To: <45705E34.2030704@ru.mvista.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <457042FF.2060908@innova-card.com> <20061202.004527.52131670.anemo@mba.ocn.ne.jp> <45705E34.2030704@ru.mvista.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: 13314 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 On 12/1/06, Sergei Shtylyov wrote: > CMB-Vr4133 has the Rockhopper backplane with 8259 integrated into ALi chip > -- and it is supported via CONFIG_ROCKHOPPER. > thanks, I can see it now. -- Franck From vagabon.xyz@gmail.com Fri Dec 1 17:12:35 2006 Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 01 Dec 2006 17:12:40 +0000 (GMT) Received: from ug-out-1314.google.com ([66.249.92.175]:57235 "EHLO ug-out-1314.google.com") by ftp.linux-mips.org with ESMTP id S20038452AbWLARMf (ORCPT ); Fri, 1 Dec 2006 17:12:35 +0000 Received: by ug-out-1314.google.com with SMTP id 40so2683846uga for ; Fri, 01 Dec 2006 09:12:35 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=J9daMnbe9jMh9lNlj1ZDW+EGhPCaIKS1+z9HFE84ZEYD/mfzCDziEEKCvnfIEWFnlQQUHFwzpk4odsrreU8fCmDP7uUDAyXVlAyyjCV8K70P5Hw+Zc24dD1DxiP8kC1w1cuFp1vvDJqt/uI3fGEd6OoAkD44N5oPFprvX+vzBVg= Received: by 10.78.166.7 with SMTP id o7mr5005861hue.1164993154925; Fri, 01 Dec 2006 09:12:34 -0800 (PST) Received: by 10.78.124.19 with HTTP; Fri, 1 Dec 2006 09:12:34 -0800 (PST) Message-ID: Date: Fri, 1 Dec 2006 18:12:34 +0100 From: "Franck Bui-Huu" To: "Atsushi Nemoto" Subject: Re: [PATCH] Compile __do_IRQ() when really needed Cc: ralf@linux-mips.org, linux-mips@linux-mips.org In-Reply-To: <20061202.020544.89039198.anemo@mba.ocn.ne.jp> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <457042FF.2060908@innova-card.com> <20061202.004527.52131670.anemo@mba.ocn.ne.jp> <20061202.020544.89039198.anemo@mba.ocn.ne.jp> 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: 13315 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 On 12/1/06, Atsushi Nemoto wrote: > On Fri, 1 Dec 2006 17:47:29 +0100, "Franck Bui-Huu" wrote: > > > > @@ -468,6 +473,7 @@ config DDB5477 > > > > config MACH_VR41XX > > > > bool "NEC VR41XX-based machines" > > > > select SYS_HAS_CPU_VR41XX > > > > + select GENERIC_HARDIRQS_NO__DO_IRQ > > > > > > > > config PMC_YOSEMITE > > > > bool "PMC-Sierra Yosemite eval board" > > > > > > Same here. > > > > > > > are you sure ? I don't see any traces of i8259 selection. > > Moreover, Yoichi's vr41xx boards seem to have no problem > > Oh I was wrong. I had misread VR41XX as DDB5477... > No you were not ;) take a look to Sergei reply. -- Franck From vagabon.xyz@gmail.com Fri Dec 1 17:21:12 2006 Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 01 Dec 2006 17:21:17 +0000 (GMT) Received: from nf-out-0910.google.com ([64.233.182.190]:6427 "EHLO nf-out-0910.google.com") by ftp.linux-mips.org with ESMTP id S28573740AbWLARVM (ORCPT ); Fri, 1 Dec 2006 17:21:12 +0000 Received: by nf-out-0910.google.com with SMTP id l24so3480348nfc for ; Fri, 01 Dec 2006 09:21:11 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:reply-to:user-agent:mime-version:to:cc:subject:content-type:content-transfer-encoding:from; b=GezxrujMy1cscXqmDkF7d6MYQewOxmEZGNHgdaYvcFDDCZUeDZihCQeMTqmxoWGQwGt9xgJDCQEpMC+I5yvvfDx3BE+qwayY63e5pJM9k5zuMctixiW7eSXWxJbX4yM1CJMGD/LiSxwnZ3CfQdaQrRTt7qykbz0qz5qRndi3/sI= Received: by 10.48.220.12 with SMTP id s12mr9539660nfg.1164993671064; Fri, 01 Dec 2006 09:21:11 -0800 (PST) Received: from ?192.168.0.24? ( [81.252.61.1]) by mx.google.com with ESMTP id d2sm37682224nfe.2006.12.01.09.21.09; Fri, 01 Dec 2006 09:21:10 -0800 (PST) Message-ID: <457064D3.3030705@innova-card.com> Date: Fri, 01 Dec 2006 18:22:27 +0100 Reply-To: Franck User-Agent: Thunderbird 1.5.0.4 (X11/20060614) MIME-Version: 1.0 To: Ralf Baechle CC: Atsushi Nemoto , macro@linux-mips.org, sshtylyov@ru.mvista.com, linux-mips Subject: [PATCH] Compile __do_IRQ() when really needed [take #3] Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit From: Franck Bui-Huu 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: 13316 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 From: Franck Bui-Huu __do_IRQ() is needed only by irq handlers that can't use default handlers defined in kernel/irq/chip.c. For others platforms there's no need to compile this function since it won't be used. For those platforms this patch defines GENERIC_HARDIRQS_NO__DO_IRQ symbol which is used exactly for this purpose. Futhermore for platforms which do not use __do_IRQ(), end() method which is part of the 'irq_chip' structure is not used. This patch simply removes this method in this case. Signed-off-by: Franck Bui-Huu --- Thanks for your feedbacks and sorry for the crap I previously sent... arch/mips/Kconfig | 9 ++++++ arch/mips/dec/ioasic-irq.c | 1 - arch/mips/dec/kn02-irq.c | 7 ----- arch/mips/emma2rh/common/irq_emma2rh.c | 7 ----- arch/mips/emma2rh/markeins/irq_markeins.c | 7 ----- arch/mips/jazz/irq.c | 7 ----- arch/mips/kernel/irq-mv6434x.c | 10 ------- arch/mips/kernel/irq-rm7000.c | 7 ----- arch/mips/kernel/irq-rm9000.c | 8 ----- arch/mips/kernel/irq_cpu.c | 7 ----- arch/mips/lasat/interrupt.c | 7 ----- arch/mips/momentum/ocelot_c/cpci-irq.c | 10 ------- arch/mips/momentum/ocelot_c/uart-irq.c | 10 ------- arch/mips/philips/pnx8550/common/int.c | 8 ----- arch/mips/sgi-ip22/ip22-int.c | 28 -------------------- arch/mips/sgi-ip27/ip27-irq.c | 8 ----- arch/mips/sgi-ip27/ip27-timer.c | 5 --- arch/mips/tx4927/common/tx4927_irq.c | 26 ------------------ .../tx4927/toshiba_rbtx4927/toshiba_rbtx4927_irq.c | 21 --------------- arch/mips/tx4938/common/irq.c | 20 -------------- arch/mips/tx4938/toshiba_rbtx4938/irq.c | 10 ------- arch/mips/vr41xx/Kconfig | 5 +++ arch/mips/vr41xx/common/icu.c | 14 ---------- 23 files changed, 14 insertions(+), 228 deletions(-) diff --git a/arch/mips/Kconfig b/arch/mips/Kconfig index 5ff94e5..0dfa941 100644 --- a/arch/mips/Kconfig +++ b/arch/mips/Kconfig @@ -233,6 +233,7 @@ config LASAT select SYS_SUPPORTS_32BIT_KERNEL select SYS_SUPPORTS_64BIT_KERNEL if EXPERIMENTAL select SYS_SUPPORTS_LITTLE_ENDIAN + select GENERIC_HARDIRQS_NO__DO_IRQ config MIPS_ATLAS bool "MIPS Atlas board" @@ -256,6 +257,7 @@ config MIPS_ATLAS select SYS_SUPPORTS_BIG_ENDIAN select SYS_SUPPORTS_LITTLE_ENDIAN select SYS_SUPPORTS_MULTITHREADING if EXPERIMENTAL + select GENERIC_HARDIRQS_NO__DO_IRQ help This enables support for the MIPS Technologies Atlas evaluation board. @@ -410,6 +412,7 @@ config MOMENCO_OCELOT_C select SYS_SUPPORTS_32BIT_KERNEL select SYS_SUPPORTS_64BIT_KERNEL select SYS_SUPPORTS_BIG_ENDIAN + select GENERIC_HARDIRQS_NO__DO_IRQ help The Ocelot is a MIPS-based Single Board Computer (SBC) made by Momentum Computer . @@ -558,6 +561,7 @@ config SGI_IP27 select SYS_SUPPORTS_BIG_ENDIAN select SYS_SUPPORTS_NUMA select SYS_SUPPORTS_SMP + select GENERIC_HARDIRQS_NO__DO_IRQ help This are the SGI Origin 200, Origin 2000 and Onyx 2 Graphics workstations. To compile a Linux kernel that runs on these, say Y @@ -824,6 +828,10 @@ config SCHED_NO_NO_OMIT_FRAME_POINTER bool default y +config GENERIC_HARDIRQS_NO__DO_IRQ + bool + default n + # # Select some configuration options automatically based on user selections. # @@ -985,6 +993,7 @@ config SOC_PNX8550 select HW_HAS_PCI select SYS_HAS_CPU_MIPS32_R1 select SYS_SUPPORTS_32BIT_KERNEL + select GENERIC_HARDIRQS_NO__DO_IRQ config SWAP_IO_SPACE bool diff --git a/arch/mips/dec/ioasic-irq.c b/arch/mips/dec/ioasic-irq.c index 269b22b..c7391bb 100644 --- a/arch/mips/dec/ioasic-irq.c +++ b/arch/mips/dec/ioasic-irq.c @@ -67,7 +67,6 @@ static struct irq_chip ioasic_irq_type = .mask = mask_ioasic_irq, .mask_ack = ack_ioasic_irq, .unmask = unmask_ioasic_irq, - .end = end_ioasic_irq, }; diff --git a/arch/mips/dec/kn02-irq.c b/arch/mips/dec/kn02-irq.c index 5a9be4c..916e46b 100644 --- a/arch/mips/dec/kn02-irq.c +++ b/arch/mips/dec/kn02-irq.c @@ -57,19 +57,12 @@ static void ack_kn02_irq(unsigned int ir iob(); } -static void end_kn02_irq(unsigned int irq) -{ - if (!(irq_desc[irq].status & (IRQ_DISABLED | IRQ_INPROGRESS))) - unmask_kn02_irq(irq); -} - static struct irq_chip kn02_irq_type = { .typename = "KN02-CSR", .ack = ack_kn02_irq, .mask = mask_kn02_irq, .mask_ack = ack_kn02_irq, .unmask = unmask_kn02_irq, - .end = end_kn02_irq, }; diff --git a/arch/mips/emma2rh/common/irq_emma2rh.c b/arch/mips/emma2rh/common/irq_emma2rh.c index 59b9829..8d880f0 100644 --- a/arch/mips/emma2rh/common/irq_emma2rh.c +++ b/arch/mips/emma2rh/common/irq_emma2rh.c @@ -56,19 +56,12 @@ static void emma2rh_irq_disable(unsigned ll_emma2rh_irq_disable(irq - emma2rh_irq_base); } -static void emma2rh_irq_end(unsigned int irq) -{ - if (!(irq_desc[irq].status & (IRQ_DISABLED | IRQ_INPROGRESS))) - ll_emma2rh_irq_enable(irq - emma2rh_irq_base); -} - struct irq_chip emma2rh_irq_controller = { .typename = "emma2rh_irq", .ack = emma2rh_irq_disable, .mask = emma2rh_irq_disable, .mask_ack = emma2rh_irq_disable, .unmask = emma2rh_irq_enable, - .end = emma2rh_irq_end, }; void emma2rh_irq_init(u32 irq_base) diff --git a/arch/mips/emma2rh/markeins/irq_markeins.c b/arch/mips/emma2rh/markeins/irq_markeins.c index 3ac4e40..2116d9b 100644 --- a/arch/mips/emma2rh/markeins/irq_markeins.c +++ b/arch/mips/emma2rh/markeins/irq_markeins.c @@ -48,19 +48,12 @@ static void emma2rh_sw_irq_disable(unsig ll_emma2rh_sw_irq_disable(irq - emma2rh_sw_irq_base); } -static void emma2rh_sw_irq_end(unsigned int irq) -{ - if (!(irq_desc[irq].status & (IRQ_DISABLED | IRQ_INPROGRESS))) - ll_emma2rh_sw_irq_enable(irq - emma2rh_sw_irq_base); -} - struct irq_chip emma2rh_sw_irq_controller = { .typename = "emma2rh_sw_irq", .ack = emma2rh_sw_irq_disable, .mask = emma2rh_sw_irq_disable, .mask_ack = emma2rh_sw_irq_disable, .unmask = emma2rh_sw_irq_enable, - .end = emma2rh_sw_irq_end, }; void emma2rh_sw_irq_init(u32 irq_base) diff --git a/arch/mips/jazz/irq.c b/arch/mips/jazz/irq.c index 5c4f50c..f8d417b 100644 --- a/arch/mips/jazz/irq.c +++ b/arch/mips/jazz/irq.c @@ -39,19 +39,12 @@ void disable_r4030_irq(unsigned int irq) spin_unlock_irqrestore(&r4030_lock, flags); } -static void end_r4030_irq(unsigned int irq) -{ - if (!(irq_desc[irq].status & (IRQ_DISABLED|IRQ_INPROGRESS))) - enable_r4030_irq(irq); -} - static struct irq_chip r4030_irq_type = { .typename = "R4030", .ack = disable_r4030_irq, .mask = disable_r4030_irq, .mask_ack = disable_r4030_irq, .unmask = enable_r4030_irq, - .end = end_r4030_irq, }; void __init init_r4030_ints(void) diff --git a/arch/mips/kernel/irq-mv6434x.c b/arch/mips/kernel/irq-mv6434x.c index 6cfb31c..efbd219 100644 --- a/arch/mips/kernel/irq-mv6434x.c +++ b/arch/mips/kernel/irq-mv6434x.c @@ -67,15 +67,6 @@ static inline void unmask_mv64340_irq(un } /* - * End IRQ processing - */ -static void end_mv64340_irq(unsigned int irq) -{ - if (!(irq_desc[irq].status & (IRQ_DISABLED|IRQ_INPROGRESS))) - unmask_mv64340_irq(irq); -} - -/* * Interrupt handler for interrupts coming from the Marvell chip. * It could be built in ethernet ports etc... */ @@ -106,7 +97,6 @@ struct irq_chip mv64340_irq_type = { .mask = mask_mv64340_irq, .mask_ack = mask_mv64340_irq, .unmask = unmask_mv64340_irq, - .end = end_mv64340_irq, }; void __init mv64340_irq_init(unsigned int base) diff --git a/arch/mips/kernel/irq-rm7000.c b/arch/mips/kernel/irq-rm7000.c index ddcc2a5..123324b 100644 --- a/arch/mips/kernel/irq-rm7000.c +++ b/arch/mips/kernel/irq-rm7000.c @@ -29,19 +29,12 @@ static inline void mask_rm7k_irq(unsigne clear_c0_intcontrol(0x100 << (irq - irq_base)); } -static void rm7k_cpu_irq_end(unsigned int irq) -{ - if (!(irq_desc[irq].status & (IRQ_DISABLED | IRQ_INPROGRESS))) - unmask_rm7k_irq(irq); -} - static struct irq_chip rm7k_irq_controller = { .typename = "RM7000", .ack = mask_rm7k_irq, .mask = mask_rm7k_irq, .mask_ack = mask_rm7k_irq, .unmask = unmask_rm7k_irq, - .end = rm7k_cpu_irq_end, }; void __init rm7k_cpu_irq_init(int base) diff --git a/arch/mips/kernel/irq-rm9000.c b/arch/mips/kernel/irq-rm9000.c index ba6440c..0e6f4c5 100644 --- a/arch/mips/kernel/irq-rm9000.c +++ b/arch/mips/kernel/irq-rm9000.c @@ -80,19 +80,12 @@ static void rm9k_perfcounter_irq_shutdow on_each_cpu(local_rm9k_perfcounter_irq_shutdown, (void *) irq, 0, 1); } -static void rm9k_cpu_irq_end(unsigned int irq) -{ - if (!(irq_desc[irq].status & (IRQ_DISABLED | IRQ_INPROGRESS))) - unmask_rm9k_irq(irq); -} - static struct irq_chip rm9k_irq_controller = { .typename = "RM9000", .ack = mask_rm9k_irq, .mask = mask_rm9k_irq, .mask_ack = mask_rm9k_irq, .unmask = unmask_rm9k_irq, - .end = rm9k_cpu_irq_end, }; static struct irq_chip rm9k_perfcounter_irq = { @@ -103,7 +96,6 @@ static struct irq_chip rm9k_perfcounter_ .mask = mask_rm9k_irq, .mask_ack = mask_rm9k_irq, .unmask = unmask_rm9k_irq, - .end = rm9k_cpu_irq_end, }; unsigned int rm9000_perfcount_irq; diff --git a/arch/mips/kernel/irq_cpu.c b/arch/mips/kernel/irq_cpu.c index be5ac23..7634a66 100644 --- a/arch/mips/kernel/irq_cpu.c +++ b/arch/mips/kernel/irq_cpu.c @@ -50,12 +50,6 @@ static inline void mask_mips_irq(unsigne irq_disable_hazard(); } -static void mips_cpu_irq_end(unsigned int irq) -{ - if (!(irq_desc[irq].status & (IRQ_DISABLED | IRQ_INPROGRESS))) - unmask_mips_irq(irq); -} - static struct irq_chip mips_cpu_irq_controller = { .typename = "MIPS", .ack = mask_mips_irq, @@ -63,7 +57,6 @@ static struct irq_chip mips_cpu_irq_cont .mask_ack = mask_mips_irq, .unmask = unmask_mips_irq, .eoi = unmask_mips_irq, - .end = mips_cpu_irq_end, }; /* diff --git a/arch/mips/lasat/interrupt.c b/arch/mips/lasat/interrupt.c index 4a84a7b..2affa5f 100644 --- a/arch/mips/lasat/interrupt.c +++ b/arch/mips/lasat/interrupt.c @@ -44,19 +44,12 @@ void enable_lasat_irq(unsigned int irq_n *lasat_int_mask |= (1 << irq_nr) << lasat_int_mask_shift; } -static void end_lasat_irq(unsigned int irq) -{ - if (!(irq_desc[irq].status & (IRQ_DISABLED|IRQ_INPROGRESS))) - enable_lasat_irq(irq); -} - static struct irq_chip lasat_irq_type = { .typename = "Lasat", .ack = disable_lasat_irq, .mask = disable_lasat_irq, .mask_ack = disable_lasat_irq, .unmask = enable_lasat_irq, - .end = end_lasat_irq, }; static inline int ls1bit32(unsigned int x) diff --git a/arch/mips/momentum/ocelot_c/cpci-irq.c b/arch/mips/momentum/ocelot_c/cpci-irq.c index e5a4a0a..bb11fef 100644 --- a/arch/mips/momentum/ocelot_c/cpci-irq.c +++ b/arch/mips/momentum/ocelot_c/cpci-irq.c @@ -66,15 +66,6 @@ static inline void unmask_cpci_irq(unsig } /* - * End IRQ processing - */ -static void end_cpci_irq(unsigned int irq) -{ - if (!(irq_desc[irq].status & (IRQ_DISABLED|IRQ_INPROGRESS))) - unmask_cpci_irq(irq); -} - -/* * Interrupt handler for interrupts coming from the FPGA chip. * It could be built in ethernet ports etc... */ @@ -98,7 +89,6 @@ struct irq_chip cpci_irq_type = { .mask = mask_cpci_irq, .mask_ack = mask_cpci_irq, .unmask = unmask_cpci_irq, - .end = end_cpci_irq, }; void cpci_irq_init(void) diff --git a/arch/mips/momentum/ocelot_c/uart-irq.c b/arch/mips/momentum/ocelot_c/uart-irq.c index 0029f00..a7a80c0 100644 --- a/arch/mips/momentum/ocelot_c/uart-irq.c +++ b/arch/mips/momentum/ocelot_c/uart-irq.c @@ -60,15 +60,6 @@ static inline void unmask_uart_irq(unsig } /* - * End IRQ processing - */ -static void end_uart_irq(unsigned int irq) -{ - if (!(irq_desc[irq].status & (IRQ_DISABLED|IRQ_INPROGRESS))) - unmask_uart_irq(irq); -} - -/* * Interrupt handler for interrupts coming from the FPGA chip. */ void ll_uart_irq(void) @@ -91,7 +82,6 @@ struct irq_chip uart_irq_type = { .mask = mask_uart_irq, .mask_ack = mask_uart_irq, .unmask = unmask_uart_irq, - .end = end_uart_irq, }; void uart_irq_init(void) diff --git a/arch/mips/philips/pnx8550/common/int.c b/arch/mips/philips/pnx8550/common/int.c index 0dc2393..2c36c10 100644 --- a/arch/mips/philips/pnx8550/common/int.c +++ b/arch/mips/philips/pnx8550/common/int.c @@ -158,20 +158,12 @@ int pnx8550_set_gic_priority(int irq, in return prev_priority; } -static void end_irq(unsigned int irq) -{ - if (!(irq_desc[irq].status & (IRQ_DISABLED|IRQ_INPROGRESS))) { - unmask_irq(irq); - } -} - static struct irq_chip level_irq_type = { .typename = "PNX Level IRQ", .ack = mask_irq, .mask = mask_irq, .mask_ack = mask_irq, .unmask = unmask_irq, - .end = end_irq, }; static struct irqaction gic_action = { diff --git a/arch/mips/sgi-ip22/ip22-int.c b/arch/mips/sgi-ip22/ip22-int.c index c7b1380..c44f8be 100644 --- a/arch/mips/sgi-ip22/ip22-int.c +++ b/arch/mips/sgi-ip22/ip22-int.c @@ -51,19 +51,12 @@ static void disable_local0_irq(unsigned sgint->imask0 &= ~(1 << (irq - SGINT_LOCAL0)); } -static void end_local0_irq (unsigned int irq) -{ - if (!(irq_desc[irq].status & (IRQ_DISABLED|IRQ_INPROGRESS))) - enable_local0_irq(irq); -} - static struct irq_chip ip22_local0_irq_type = { .typename = "IP22 local 0", .ack = disable_local0_irq, .mask = disable_local0_irq, .mask_ack = disable_local0_irq, .unmask = enable_local0_irq, - .end = end_local0_irq, }; static void enable_local1_irq(unsigned int irq) @@ -79,19 +72,12 @@ void disable_local1_irq(unsigned int irq sgint->imask1 &= ~(1 << (irq - SGINT_LOCAL1)); } -static void end_local1_irq (unsigned int irq) -{ - if (!(irq_desc[irq].status & (IRQ_DISABLED|IRQ_INPROGRESS))) - enable_local1_irq(irq); -} - static struct irq_chip ip22_local1_irq_type = { .typename = "IP22 local 1", .ack = disable_local1_irq, .mask = disable_local1_irq, .mask_ack = disable_local1_irq, .unmask = enable_local1_irq, - .end = end_local1_irq, }; static void enable_local2_irq(unsigned int irq) @@ -107,19 +93,12 @@ void disable_local2_irq(unsigned int irq sgint->imask0 &= ~(1 << (SGI_MAP_0_IRQ - SGINT_LOCAL0)); } -static void end_local2_irq (unsigned int irq) -{ - if (!(irq_desc[irq].status & (IRQ_DISABLED|IRQ_INPROGRESS))) - enable_local2_irq(irq); -} - static struct irq_chip ip22_local2_irq_type = { .typename = "IP22 local 2", .ack = disable_local2_irq, .mask = disable_local2_irq, .mask_ack = disable_local2_irq, .unmask = enable_local2_irq, - .end = end_local2_irq, }; static void enable_local3_irq(unsigned int irq) @@ -135,19 +114,12 @@ void disable_local3_irq(unsigned int irq sgint->imask1 &= ~(1 << (SGI_MAP_1_IRQ - SGINT_LOCAL1)); } -static void end_local3_irq (unsigned int irq) -{ - if (!(irq_desc[irq].status & (IRQ_DISABLED|IRQ_INPROGRESS))) - enable_local3_irq(irq); -} - static struct irq_chip ip22_local3_irq_type = { .typename = "IP22 local 3", .ack = disable_local3_irq, .mask = disable_local3_irq, .mask_ack = disable_local3_irq, .unmask = enable_local3_irq, - .end = end_local3_irq, }; static void indy_local0_irqdispatch(void) diff --git a/arch/mips/sgi-ip27/ip27-irq.c b/arch/mips/sgi-ip27/ip27-irq.c index 5f8835b..319f880 100644 --- a/arch/mips/sgi-ip27/ip27-irq.c +++ b/arch/mips/sgi-ip27/ip27-irq.c @@ -332,13 +332,6 @@ static inline void disable_bridge_irq(un intr_disconnect_level(cpu, swlevel); } -static void end_bridge_irq(unsigned int irq) -{ - if (!(irq_desc[irq].status & (IRQ_DISABLED|IRQ_INPROGRESS)) && - irq_desc[irq].action) - enable_bridge_irq(irq); -} - static struct irq_chip bridge_irq_type = { .typename = "bridge", .startup = startup_bridge_irq, @@ -347,7 +340,6 @@ static struct irq_chip bridge_irq_type = .mask = disable_bridge_irq, .mask_ack = disable_bridge_irq, .unmask = enable_bridge_irq, - .end = end_bridge_irq, }; void __devinit register_bridge_irq(unsigned int irq) diff --git a/arch/mips/sgi-ip27/ip27-timer.c b/arch/mips/sgi-ip27/ip27-timer.c index 7d36172..c20e989 100644 --- a/arch/mips/sgi-ip27/ip27-timer.c +++ b/arch/mips/sgi-ip27/ip27-timer.c @@ -180,10 +180,6 @@ static void disable_rt_irq(unsigned int { } -static void end_rt_irq(unsigned int irq) -{ -} - static struct irq_chip rt_irq_type = { .typename = "SN HUB RT timer", .ack = disable_rt_irq, @@ -191,7 +187,6 @@ static struct irq_chip rt_irq_type = { .mask_ack = disable_rt_irq, .unmask = enable_rt_irq, .eoi = enable_rt_irq, - .end = end_rt_irq, }; static struct irqaction rt_irqaction = { diff --git a/arch/mips/tx4927/common/tx4927_irq.c b/arch/mips/tx4927/common/tx4927_irq.c index 21873de..ed4a19a 100644 --- a/arch/mips/tx4927/common/tx4927_irq.c +++ b/arch/mips/tx4927/common/tx4927_irq.c @@ -66,12 +66,10 @@ #define TX4927_IRQ_CP0_INIT ( 1 << 10 ) #define TX4927_IRQ_CP0_ENABLE ( 1 << 13 ) #define TX4927_IRQ_CP0_DISABLE ( 1 << 14 ) -#define TX4927_IRQ_CP0_ENDIRQ ( 1 << 16 ) #define TX4927_IRQ_PIC_INIT ( 1 << 20 ) #define TX4927_IRQ_PIC_ENABLE ( 1 << 23 ) #define TX4927_IRQ_PIC_DISABLE ( 1 << 24 ) -#define TX4927_IRQ_PIC_ENDIRQ ( 1 << 26 ) #define TX4927_IRQ_ALL 0xffffffff #endif @@ -82,12 +80,10 @@ static const u32 tx4927_irq_debug_flag = | TX4927_IRQ_WARN | TX4927_IRQ_EROR // | TX4927_IRQ_CP0_INIT // | TX4927_IRQ_CP0_ENABLE -// | TX4927_IRQ_CP0_DISABLE // | TX4927_IRQ_CP0_ENDIRQ // | TX4927_IRQ_PIC_INIT // | TX4927_IRQ_PIC_ENABLE // | TX4927_IRQ_PIC_DISABLE -// | TX4927_IRQ_PIC_ENDIRQ // | TX4927_IRQ_INIT // | TX4927_IRQ_NEST1 // | TX4927_IRQ_NEST2 @@ -114,11 +110,9 @@ static const u32 tx4927_irq_debug_flag = static void tx4927_irq_cp0_enable(unsigned int irq); static void tx4927_irq_cp0_disable(unsigned int irq); -static void tx4927_irq_cp0_end(unsigned int irq); static void tx4927_irq_pic_enable(unsigned int irq); static void tx4927_irq_pic_disable(unsigned int irq); -static void tx4927_irq_pic_end(unsigned int irq); /* * Kernel structs for all pic's @@ -131,7 +125,6 @@ static struct irq_chip tx4927_irq_cp0_ty .mask = tx4927_irq_cp0_disable, .mask_ack = tx4927_irq_cp0_disable, .unmask = tx4927_irq_cp0_enable, - .end = tx4927_irq_cp0_end, }; #define TX4927_PIC_NAME "TX4927-PIC" @@ -141,7 +134,6 @@ static struct irq_chip tx4927_irq_pic_ty .mask = tx4927_irq_pic_disable, .mask_ack = tx4927_irq_pic_disable, .unmask = tx4927_irq_pic_enable, - .end = tx4927_irq_pic_end, }; #define TX4927_PIC_ACTION(s) { no_action, 0, CPU_MASK_NONE, s, NULL, NULL } @@ -214,15 +206,6 @@ static void tx4927_irq_cp0_disable(unsig tx4927_irq_cp0_modify(CCP0_STATUS, tx4927_irq_cp0_mask(irq), 0); } -static void tx4927_irq_cp0_end(unsigned int irq) -{ - TX4927_IRQ_DPRINTK(TX4927_IRQ_CP0_ENDIRQ, "irq=%d \n", irq); - - if (!(irq_desc[irq].status & (IRQ_DISABLED | IRQ_INPROGRESS))) { - tx4927_irq_cp0_enable(irq); - } -} - /* * Functions for pic */ @@ -376,15 +359,6 @@ static void tx4927_irq_pic_disable(unsig tx4927_irq_pic_mask(irq), 0); } -static void tx4927_irq_pic_end(unsigned int irq) -{ - TX4927_IRQ_DPRINTK(TX4927_IRQ_PIC_ENDIRQ, "irq=%d\n", irq); - - if (!(irq_desc[irq].status & (IRQ_DISABLED | IRQ_INPROGRESS))) { - tx4927_irq_pic_enable(irq); - } -} - /* * Main init functions */ diff --git a/arch/mips/tx4927/toshiba_rbtx4927/toshiba_rbtx4927_irq.c b/arch/mips/tx4927/toshiba_rbtx4927/toshiba_rbtx4927_irq.c index 34cdb2a..5a5ea6c 100644 --- a/arch/mips/tx4927/toshiba_rbtx4927/toshiba_rbtx4927_irq.c +++ b/arch/mips/tx4927/toshiba_rbtx4927/toshiba_rbtx4927_irq.c @@ -153,7 +153,6 @@ JP7 is not bus master -- do NOT use -- o #define TOSHIBA_RBTX4927_IRQ_IOC_INIT ( 1 << 10 ) #define TOSHIBA_RBTX4927_IRQ_IOC_ENABLE ( 1 << 13 ) #define TOSHIBA_RBTX4927_IRQ_IOC_DISABLE ( 1 << 14 ) -#define TOSHIBA_RBTX4927_IRQ_IOC_ENDIRQ ( 1 << 16 ) #define TOSHIBA_RBTX4927_IRQ_ISA_INIT ( 1 << 20 ) #define TOSHIBA_RBTX4927_IRQ_ISA_ENABLE ( 1 << 23 ) @@ -172,7 +171,6 @@ static const u32 toshiba_rbtx4927_irq_de // | TOSHIBA_RBTX4927_IRQ_IOC_INIT // | TOSHIBA_RBTX4927_IRQ_IOC_ENABLE // | TOSHIBA_RBTX4927_IRQ_IOC_DISABLE -// | TOSHIBA_RBTX4927_IRQ_IOC_ENDIRQ // | TOSHIBA_RBTX4927_IRQ_ISA_INIT // | TOSHIBA_RBTX4927_IRQ_ISA_ENABLE // | TOSHIBA_RBTX4927_IRQ_ISA_DISABLE @@ -223,7 +221,6 @@ extern void mask_and_ack_8259A(unsigned static void toshiba_rbtx4927_irq_ioc_enable(unsigned int irq); static void toshiba_rbtx4927_irq_ioc_disable(unsigned int irq); -static void toshiba_rbtx4927_irq_ioc_end(unsigned int irq); #ifdef CONFIG_TOSHIBA_FPCIB0 static void toshiba_rbtx4927_irq_isa_enable(unsigned int irq); @@ -239,7 +236,6 @@ static struct irq_chip toshiba_rbtx4927_ .mask = toshiba_rbtx4927_irq_ioc_disable, .mask_ack = toshiba_rbtx4927_irq_ioc_disable, .unmask = toshiba_rbtx4927_irq_ioc_enable, - .end = toshiba_rbtx4927_irq_ioc_end, }; #define TOSHIBA_RBTX4927_IOC_INTR_ENAB 0xbc002000 #define TOSHIBA_RBTX4927_IOC_INTR_STAT 0xbc002006 @@ -388,23 +384,6 @@ static void toshiba_rbtx4927_irq_ioc_dis TOSHIBA_RBTX4927_WR08(TOSHIBA_RBTX4927_IOC_INTR_ENAB, v); } -static void toshiba_rbtx4927_irq_ioc_end(unsigned int irq) -{ - TOSHIBA_RBTX4927_IRQ_DPRINTK(TOSHIBA_RBTX4927_IRQ_IOC_ENDIRQ, - "irq=%d\n", irq); - - if (irq < TOSHIBA_RBTX4927_IRQ_IOC_BEG - || irq > TOSHIBA_RBTX4927_IRQ_IOC_END) { - TOSHIBA_RBTX4927_IRQ_DPRINTK(TOSHIBA_RBTX4927_IRQ_EROR, - "bad irq=%d\n", irq); - panic("\n"); - } - - if (!(irq_desc[irq].status & (IRQ_DISABLED | IRQ_INPROGRESS))) { - toshiba_rbtx4927_irq_ioc_enable(irq); - } -} - /**********************************************************************************/ /* Functions for isa */ diff --git a/arch/mips/tx4938/common/irq.c b/arch/mips/tx4938/common/irq.c index 42e1276..a347b42 100644 --- a/arch/mips/tx4938/common/irq.c +++ b/arch/mips/tx4938/common/irq.c @@ -39,11 +39,9 @@ static void tx4938_irq_cp0_enable(unsigned int irq); static void tx4938_irq_cp0_disable(unsigned int irq); -static void tx4938_irq_cp0_end(unsigned int irq); static void tx4938_irq_pic_enable(unsigned int irq); static void tx4938_irq_pic_disable(unsigned int irq); -static void tx4938_irq_pic_end(unsigned int irq); /**********************************************************************************/ /* Kernel structs for all pic's */ @@ -56,7 +54,6 @@ static struct irq_chip tx4938_irq_cp0_ty .mask = tx4938_irq_cp0_disable, .mask_ack = tx4938_irq_cp0_disable, .unmask = tx4938_irq_cp0_enable, - .end = tx4938_irq_cp0_end, }; #define TX4938_PIC_NAME "TX4938-PIC" @@ -66,7 +63,6 @@ static struct irq_chip tx4938_irq_pic_ty .mask = tx4938_irq_pic_disable, .mask_ack = tx4938_irq_pic_disable, .unmask = tx4938_irq_pic_enable, - .end = tx4938_irq_pic_end, }; static struct irqaction tx4938_irq_pic_action = { @@ -104,14 +100,6 @@ tx4938_irq_cp0_disable(unsigned int irq) clear_c0_status(tx4938_irq_cp0_mask(irq)); } -static void -tx4938_irq_cp0_end(unsigned int irq) -{ - if (!(irq_desc[irq].status & (IRQ_DISABLED | IRQ_INPROGRESS))) { - tx4938_irq_cp0_enable(irq); - } -} - /**********************************************************************************/ /* Functions for pic */ /**********************************************************************************/ @@ -269,14 +257,6 @@ tx4938_irq_pic_disable(unsigned int irq) tx4938_irq_pic_mask(irq), 0); } -static void -tx4938_irq_pic_end(unsigned int irq) -{ - if (!(irq_desc[irq].status & (IRQ_DISABLED | IRQ_INPROGRESS))) { - tx4938_irq_pic_enable(irq); - } -} - /**********************************************************************************/ /* Main init functions */ /**********************************************************************************/ diff --git a/arch/mips/tx4938/toshiba_rbtx4938/irq.c b/arch/mips/tx4938/toshiba_rbtx4938/irq.c index 8c87a35..b6f363d 100644 --- a/arch/mips/tx4938/toshiba_rbtx4938/irq.c +++ b/arch/mips/tx4938/toshiba_rbtx4938/irq.c @@ -89,7 +89,6 @@ IRQ Device static void toshiba_rbtx4938_irq_ioc_enable(unsigned int irq); static void toshiba_rbtx4938_irq_ioc_disable(unsigned int irq); -static void toshiba_rbtx4938_irq_ioc_end(unsigned int irq); #define TOSHIBA_RBTX4938_IOC_NAME "RBTX4938-IOC" static struct irq_chip toshiba_rbtx4938_irq_ioc_type = { @@ -98,7 +97,6 @@ static struct irq_chip toshiba_rbtx4938_ .mask = toshiba_rbtx4938_irq_ioc_disable, .mask_ack = toshiba_rbtx4938_irq_ioc_disable, .unmask = toshiba_rbtx4938_irq_ioc_enable, - .end = toshiba_rbtx4938_irq_ioc_end, }; #define TOSHIBA_RBTX4938_IOC_INTR_ENAB 0xb7f02000 @@ -167,14 +165,6 @@ toshiba_rbtx4938_irq_ioc_disable(unsigne TX4938_RD08(TOSHIBA_RBTX4938_IOC_INTR_ENAB); } -static void -toshiba_rbtx4938_irq_ioc_end(unsigned int irq) -{ - if (!(irq_desc[irq].status & (IRQ_DISABLED | IRQ_INPROGRESS))) { - toshiba_rbtx4938_irq_ioc_enable(irq); - } -} - extern void __init txx9_spi_irqinit(int irc_irq); void __init arch_init_irq(void) diff --git a/arch/mips/vr41xx/Kconfig b/arch/mips/vr41xx/Kconfig index 92f41f6..c8dfd80 100644 --- a/arch/mips/vr41xx/Kconfig +++ b/arch/mips/vr41xx/Kconfig @@ -6,6 +6,7 @@ config CASIO_E55 select ISA select SYS_SUPPORTS_32BIT_KERNEL select SYS_SUPPORTS_LITTLE_ENDIAN + select GENERIC_HARDIRQS_NO__DO_IRQ config IBM_WORKPAD bool "Support for IBM WorkPad z50" @@ -15,6 +16,7 @@ config IBM_WORKPAD select ISA select SYS_SUPPORTS_32BIT_KERNEL select SYS_SUPPORTS_LITTLE_ENDIAN + select GENERIC_HARDIRQS_NO__DO_IRQ config NEC_CMBVR4133 bool "Support for NEC CMB-VR4133" @@ -39,6 +41,7 @@ config TANBAC_TB022X select IRQ_CPU select SYS_SUPPORTS_32BIT_KERNEL select SYS_SUPPORTS_LITTLE_ENDIAN + select GENERIC_HARDIRQS_NO__DO_IRQ help The TANBAC VR4131 multichip module(TB0225) and the TANBAC VR4131DIMM(TB0229) are MIPS-based platforms @@ -71,6 +74,7 @@ config VICTOR_MPC30X select IRQ_CPU select SYS_SUPPORTS_32BIT_KERNEL select SYS_SUPPORTS_LITTLE_ENDIAN + select GENERIC_HARDIRQS_NO__DO_IRQ config ZAO_CAPCELLA bool "Support for ZAO Networks Capcella" @@ -80,6 +84,7 @@ config ZAO_CAPCELLA select IRQ_CPU select SYS_SUPPORTS_32BIT_KERNEL select SYS_SUPPORTS_LITTLE_ENDIAN + select GENERIC_HARDIRQS_NO__DO_IRQ config PCI_VR41XX bool "Add PCI control unit support of NEC VR4100 series" diff --git a/arch/mips/vr41xx/common/icu.c b/arch/mips/vr41xx/common/icu.c index 54b92a7..c075261 100644 --- a/arch/mips/vr41xx/common/icu.c +++ b/arch/mips/vr41xx/common/icu.c @@ -427,19 +427,12 @@ static void enable_sysint1_irq(unsigned icu1_set(MSYSINT1REG, 1 << SYSINT1_IRQ_TO_PIN(irq)); } -static void end_sysint1_irq(unsigned int irq) -{ - if (!(irq_desc[irq].status & (IRQ_DISABLED | IRQ_INPROGRESS))) - icu1_set(MSYSINT1REG, 1 << SYSINT1_IRQ_TO_PIN(irq)); -} - static struct irq_chip sysint1_irq_type = { .typename = "SYSINT1", .ack = disable_sysint1_irq, .mask = disable_sysint1_irq, .mask_ack = disable_sysint1_irq, .unmask = enable_sysint1_irq, - .end = end_sysint1_irq, }; static void disable_sysint2_irq(unsigned int irq) @@ -452,19 +445,12 @@ static void enable_sysint2_irq(unsigned icu2_set(MSYSINT2REG, 1 << SYSINT2_IRQ_TO_PIN(irq)); } -static void end_sysint2_irq(unsigned int irq) -{ - if (!(irq_desc[irq].status & (IRQ_DISABLED | IRQ_INPROGRESS))) - icu2_set(MSYSINT2REG, 1 << SYSINT2_IRQ_TO_PIN(irq)); -} - static struct irq_chip sysint2_irq_type = { .typename = "SYSINT2", .ack = disable_sysint2_irq, .mask = disable_sysint2_irq, .mask_ack = disable_sysint2_irq, .unmask = enable_sysint2_irq, - .end = end_sysint2_irq, }; static inline int set_sysint1_assign(unsigned int irq, unsigned char assign) -- 1.4.4.1 From hjl@lucon.org Fri Dec 1 18:23:31 2006 Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 01 Dec 2006 18:23:37 +0000 (GMT) Received: from smtp114.sbc.mail.mud.yahoo.com ([68.142.198.213]:33614 "HELO smtp114.sbc.mail.mud.yahoo.com") by ftp.linux-mips.org with SMTP id S28573745AbWLASXb (ORCPT ); Fri, 1 Dec 2006 18:23:31 +0000 Received: (qmail 73196 invoked from network); 1 Dec 2006 18:23:21 -0000 Received: from unknown (HELO lucon.org) (hjjean@sbcglobal.net@75.0.162.249 with login) by smtp114.sbc.mail.mud.yahoo.com with SMTP; 1 Dec 2006 18:23:20 -0000 X-YMail-OSG: OZy_TN0VM1kPfZyb1OfmXbfZLF5aTWIdeDth8yKeL0w4vHQpaFXWLqfpvPprsUGfy9ssMSXe6JqDqdfyel9GIZZvj53IByAczkpgbtncNJSZ8g4eVbEFPQ-- Received: by lucon.org (Postfix, from userid 500) id D851346EEED; Fri, 1 Dec 2006 10:23:18 -0800 (PST) Date: Fri, 1 Dec 2006 10:23:18 -0800 From: "H. J. Lu" To: linux-gcc@vger.kernel.org Cc: gcc@gcc.gnu.org, GNU C Library , Mat Hostetter , Warner Losh , linux-mips@linux-mips.org, Ralf Baechle , Linas Vepstas , linux-vax@pergamentum.com Subject: The Linux binutils 2.17.50.0.8 is released Message-ID: <20061201182318.GA7026@lucon.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.2i 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: 13317 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.17.50.0.8 for Linux, which is based on binutils 2006 1201 in CVS on sourceware.org plus various changes. It is purely for Linux. Starting from the 2.17.50.0.8 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.17.50.0.8 to hjl@lucon.org and http://www.sourceware.org/bugzilla/ If you don't use # rpmbuild -ta binutils-xx.xx.xx.xx.xx.tar.bz2 to compile the Linux binutils, please read patches/README in source tree to apply Linux patches if there are any. 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.17.50.0.8.tar.bz2. Source code. 2. binutils-2.17.50.0.7-2.17.50.0.8.diff.bz2. Patch against the previous beta source code. 3. binutils-2.17.50.0.8-1.i386.rpm. IA-32 binary RPM for RedHat EL 4. 4. binutils-2.17.50.0.8-1.ia64.rpm. IA-64 binary RPM for RedHat EL 4. 5. binutils-2.17.50.0.8-1.x86_64.rpm. X64_64 binary RPM for RedHat EL 4. There is no separate source rpm. You can do # rpmbuild -ta binutils-2.17.50.0.8.tar.bz2 to create both binary and source rpms. 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 12/01/2006 From kaz@zeugmasystems.com Fri Dec 1 23:22:29 2006 Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 01 Dec 2006 23:22:34 +0000 (GMT) Received: from mail.zeugmasystems.com ([192.139.122.66]:35150 "EHLO zeugmasystems.com") by ftp.linux-mips.org with ESMTP id S28573770AbWLAXW3 convert rfc822-to-8bit (ORCPT ); Fri, 1 Dec 2006 23:22:29 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 8BIT Subject: Trouble with System V IPC on n32. Date: Fri, 1 Dec 2006 15:22:19 -0800 Message-ID: <66910A579C9312469A7DF9ADB54A8B7D4B5F37@exchange.ZeugmaSystems.local> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Trouble with System V IPC on n32. Thread-Index: AccVn4woxnreGnt4Qeu5SryUvIlOVg== From: "Kaz Kylheku" To: 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: 13318 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: kaz@zeugmasystems.com Precedence: bulk X-list: linux-mips Hey everyone, I'm investigating why shmat() isn't working for me. I'm running glibc 2.5 with glibc-ports 2.5, n32 ABI, on a 2.6.17.7 kernel. What happens is that the underlying do_shmat() works, but then ultimately, the glibc function fails, and errno is EFAULT. I suspect that something is screwing up above do_shmat() related to 32 versus 64 bit issues. The thing is, that glibc uses the sys_ipc dispatcher system call to call shmat and other functions. On MIPS, this is only defined in the o32 system call table. The dispatch opcode for the shmat service uses a pointer-to-user-space-pointer argument, but it doesn't look like the implementation of sys_ipc has no corresponding compat_sys_ipc flavor which understands that. I don't even know where glibc is getting the __NR_ number for the sys_ipc call, since it should not be visible from the kernel header if the O32 ABI isn't being used, but it might just be defining it for itself. (Glibc tends to do stupid things like that: #ifndef __NR_some_syscall ... #define __NR_some_syscall ... #endif). So I have an unconfirmed suspicion that the n32 glibc might actually be landing into the o32 sys_ipc (a suspiction which I'm about to test right away). Would it be reasonable to write a compat_sys_ipc, and wire that into the n32 system call table, or am I barking up the wrong tree? Also wouldn't the o32 syscall table need such a compat_sys_ipc also? If o32 user space makes calls to a 64 bit sys_ipc, I don't see how some of those calls can work. I'd be in favor of just making a single do_ipc function which takes an extra parameter that indicates whether the client is 32 or 64. The sys_ipc and compat_sys_ipc can just be stub wrappers which call that one with the correct value of that parameter. Then those cases in sys_ipc which are sensitive to 32/64 issues can implement variation based on that flag, all at the cost of a few cycles. I don't feel like fixing glibc to avoid using the IPC dispatcher. Mainly because the glibc code is harder to work with, and I would want this to be right. I.e. adding the right files under the right sysdeps/* etc. From kaz@zeugmasystems.com Fri Dec 1 23:45:10 2006 Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 01 Dec 2006 23:45:14 +0000 (GMT) Received: from mail.zeugmasystems.com ([192.139.122.66]:19280 "EHLO zeugmasystems.com") by ftp.linux-mips.org with ESMTP id S28573767AbWLAXpK convert rfc822-to-8bit (ORCPT ); Fri, 1 Dec 2006 23:45:10 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 8BIT Subject: RE: Trouble with System V IPC on n32. Date: Fri, 1 Dec 2006 15:45:03 -0800 Message-ID: <66910A579C9312469A7DF9ADB54A8B7D4B5F42@exchange.ZeugmaSystems.local> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Trouble with System V IPC on n32. Thread-Index: AccVn4woxnreGnt4Qeu5SryUvIlOVgAAtm7g From: "Kaz Kylheku" To: 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: 13319 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: kaz@zeugmasystems.com Precedence: bulk X-list: linux-mips My guess was wrong. The call is going through sys32_shmat. Inside this function, the put_user call is returning -14/EFAULT. From kaz@zeugmasystems.com Sat Dec 2 00:33:23 2006 Received: with ECARTIS (v1.0.0; list linux-mips); Sat, 02 Dec 2006 00:33:27 +0000 (GMT) Received: from mail.zeugmasystems.com ([192.139.122.66]:41554 "EHLO zeugmasystems.com") by ftp.linux-mips.org with ESMTP id S20038423AbWLBAdX convert rfc822-to-8bit (ORCPT ); Sat, 2 Dec 2006 00:33:23 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 8BIT Subject: N32 shmat problem identified! Kernel fix needed. Date: Fri, 1 Dec 2006 16:33:16 -0800 Message-ID: <66910A579C9312469A7DF9ADB54A8B7D4B5F5F@exchange.ZeugmaSystems.local> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: N32 shmat problem identified! Kernel fix needed. Thread-Index: AccVn4woxnreGnt4Qeu5SryUvIlOVgAAtm7gAAGkLSA= From: "Kaz Kylheku" To: 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: 13320 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: kaz@zeugmasystems.com Precedence: bulk X-list: linux-mips The problem is simple. The function named sys32_shmat has no reason to exist, and is broken. It assumes that user space has passed a pointer to the location where the resulting pointer should be stored. But that is not the shmat API, and glibc will pass no such parameter. So a null dereference results, leading to EFAULT. The fix is to remove this function from the code base and quite simply to wire the normal sys_shmat into the n32 syscall table. Since there is in fact no pointer-to-pointer argument, this function doesn't have a 32 bit compatibility issues. From ashlesha@kenati.com Sat Dec 2 01:47:28 2006 Received: with ECARTIS (v1.0.0; list linux-mips); Sat, 02 Dec 2006 01:47:33 +0000 (GMT) Received: from [69.90.147.196] ([69.90.147.196]:5348 "EHLO mail.kenati.com") by ftp.linux-mips.org with ESMTP id S20038471AbWLBBr2 (ORCPT ); Sat, 2 Dec 2006 01:47:28 +0000 Received: from [192.168.1.169] (adsl-71-130-109-177.dsl.snfc21.pacbell.net [71.130.109.177]) by mail.kenati.com (Postfix) with ESMTP id 7306915D4006 for ; Fri, 1 Dec 2006 19:16:53 -0800 (PST) Subject: initramfs -- boot args? From: Ashlesha Shintre Reply-To: ashlesha@kenati.com To: linux-mips@linux-mips.org Content-Type: text/plain Date: Fri, 01 Dec 2006 17:59:51 -0800 Message-Id: <1165024791.6535.43.camel@sandbar.kenati.com> Mime-Version: 1.0 X-Mailer: Evolution 2.4.2.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: 13321 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: ashlesha@kenati.com Precedence: bulk X-list: linux-mips hi, i m working on porting the 2.6.14.6 linux kernel to the encore m3 board with the au1500 processor -- nfs is giving me errors (Kernel not syncing -- Attempted to kill init) so i m trying to build an initrd image -- according to this document: http://www.timesys.com/timesource/initramfs.htm I built my own initramfs_data.cpio.gz file that contains the object file for the hello world code below- printkf("Hello World\n"); sleep(99999999); return(0) As part of make menuconfig, I pointed the CONFIG_INITRAMFS_SOURCE to the loaction of this cpio.gz archive (which was abt 24MB) -- however, this resulted in a Huge kernel image (174MB! -- i only have 64MB available on this board) making it impossible to load the image onto the board. then, I copied this initramfs_data.cpio.gz file into the linux/usr/ directory and build the kernel, leaving the CONFIG_INITRAMFS_SOURCE path blank -- the size of the kernel build was back to normal what boot args should I now supply to the board? i tried giving root=/dev/ram0 rw ip=the usual and init=hello, but this does not work..(as expected) as i understand it, when the kernel is built with a non empty initramfs_data.cpio.gz archive, it extracts the filesystem (in this case init/hello) and mounts it as part of the rootfs... Also, I m not sure how to enable support for initrd into my kernel, cus there doesnt seem to be an option in the make menuconfig to that effect?! -- but i m guessing it must be configured as i see the CONFIG_INITRAMFS_SOURCE -- Could someone please point me to the right direction and also tell me if what I m thinking is on the right/wrong track? Thank you! Ashlesha. From ralf@linux-mips.org Sat Dec 2 02:51:17 2006 Received: with ECARTIS (v1.0.0; list linux-mips); Sat, 02 Dec 2006 02:51:18 +0000 (GMT) Received: from localhost.localdomain ([127.0.0.1]:33209 "EHLO dl5rb.ham-radio-op.net") by ftp.linux-mips.org with ESMTP id S20038482AbWLBCvR (ORCPT ); Sat, 2 Dec 2006 02:51:17 +0000 Received: from denk.linux-mips.net (denk.linux-mips.net [127.0.0.1]) by dl5rb.ham-radio-op.net (8.13.8/8.13.8) with ESMTP id kB22O6hD029741; Sat, 2 Dec 2006 02:24:06 GMT Received: (from ralf@localhost) by denk.linux-mips.net (8.13.8/8.13.8/Submit) id kB22O4su029740; Sat, 2 Dec 2006 02:24:04 GMT Date: Sat, 2 Dec 2006 02:24:04 +0000 From: Ralf Baechle To: Kaz Kylheku Cc: linux-mips@linux-mips.org Subject: Re: N32 shmat problem identified! Kernel fix needed. Message-ID: <20061202022404.GA28637@linux-mips.org> References: <66910A579C9312469A7DF9ADB54A8B7D4B5F5F@exchange.ZeugmaSystems.local> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <66910A579C9312469A7DF9ADB54A8B7D4B5F5F@exchange.ZeugmaSystems.local> User-Agent: Mutt/1.4.2.2i 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: 13322 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 Fri, Dec 01, 2006 at 04:33:16PM -0800, Kaz Kylheku wrote: > The function named sys32_shmat has no reason to exist, and is broken. It > assumes that user space has passed a pointer to the location where the > resulting pointer should be stored. But that is not the shmat API, and > glibc will pass no such parameter. So a null dereference results, > leading to EFAULT. > > The fix is to remove this function from the code base and quite simply > to wire the normal sys_shmat into the n32 syscall table. Since there is > in fact no pointer-to-pointer argument, this function doesn't have a 32 > bit compatibility issues. That's fixed since two months. Ralf From jgarzik@pobox.com Sat Dec 2 05:20:05 2006 Received: with ECARTIS (v1.0.0; list linux-mips); Sat, 02 Dec 2006 05:20:10 +0000 (GMT) Received: from srv5.dvmed.net ([207.36.208.214]:49326 "EHLO mail.dvmed.net") by ftp.linux-mips.org with ESMTP id S20037692AbWLBFUF (ORCPT ); Sat, 2 Dec 2006 05:20:05 +0000 Received: from cpe-065-190-194-075.nc.res.rr.com ([65.190.194.75] helo=[10.10.10.10]) by mail.dvmed.net with esmtpsa (Exim 4.63 #1 (Red Hat Linux)) id 1GqNI8-0007sD-3H; Sat, 02 Dec 2006 05:20:00 +0000 Message-ID: <45710CFE.5090007@pobox.com> Date: Sat, 02 Dec 2006 00:19:58 -0500 From: Jeff Garzik User-Agent: Thunderbird 1.5.0.8 (X11/20061107) MIME-Version: 1.0 To: "Maciej W. Rozycki" CC: Andrew Morton , netdev@vger.kernel.org, linux-mips@linux-mips.org Subject: Re: [PATCH 2.6.18] declance: Support the I/O ASIC LANCE w/o TURBOchannel References: In-Reply-To: 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: 13323 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: jgarzik@pobox.com Precedence: bulk X-list: linux-mips Maciej W. Rozycki wrote: > The onboard LANCE of I/O ASIC systems is not a TURBOchannel device, at > least from the software point of view. Therefore it does not rely on any > kernel TURBOchannel bus services and can be supported even if support for > TURBOchannel has not been enabled in the configuration. > > Signed-off-by: Maciej W. Rozycki can you (or Andrew) please resend your patches against 2.6.19? Jeff From cw@f00f.org Sat Dec 2 05:32:55 2006 Received: with ECARTIS (v1.0.0; list linux-mips); Sat, 02 Dec 2006 05:33:00 +0000 (GMT) Received: from smtp104.sbc.mail.re2.yahoo.com ([68.142.229.101]:9579 "HELO smtp104.sbc.mail.re2.yahoo.com") by ftp.linux-mips.org with SMTP id S20037692AbWLBFcz (ORCPT ); Sat, 2 Dec 2006 05:32:55 +0000 Received: (qmail 31870 invoked from network); 2 Dec 2006 05:32:48 -0000 Received: from unknown (HELO stupidest.org) (cwedgwood@sbcglobal.net@24.5.75.45 with login) by smtp104.sbc.mail.re2.yahoo.com with SMTP; 2 Dec 2006 05:32:48 -0000 X-YMail-OSG: X_e_DZ8VM1lU01lklG0gB46OlsdDAx8FcFU2PMfn3WmGw9OzKiVC_vjc7ssAGZftcLL59BijWmQ_CL2uk.vZ6f1p2_IoSpxHoQo3ePqGc9Jrcf.f31Lq Received: by tuatara.stupidest.org (Postfix, from userid 10000) id 5567E1827280; Fri, 1 Dec 2006 21:32:47 -0800 (PST) Date: Fri, 1 Dec 2006 21:32:47 -0800 From: Chris Wedgwood To: Ashlesha Shintre Cc: linux-mips@linux-mips.org Subject: Re: initramfs -- boot args? Message-ID: <20061202053247.GB12580@tuatara.stupidest.org> References: <1165024791.6535.43.camel@sandbar.kenati.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1165024791.6535.43.camel@sandbar.kenati.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: 13324 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: cw@f00f.org Precedence: bulk X-list: linux-mips On Fri, Dec 01, 2006 at 05:59:51PM -0800, Ashlesha Shintre wrote: > I built my own initramfs_data.cpio.gz file that contains the object file > for the hello world code below- > > printkf("Hello World\n"); > sleep(99999999); > return(0) as what filename? initramfs can be very picky. can you show me "cpio --list --verbose < initramfs.cpio" or similar please? From akpm@osdl.org Sat Dec 2 05:46:38 2006 Received: with ECARTIS (v1.0.0; list linux-mips); Sat, 02 Dec 2006 05:46:43 +0000 (GMT) Received: from smtp.osdl.org ([65.172.181.25]:14302 "EHLO smtp.osdl.org") by ftp.linux-mips.org with ESMTP id S20038453AbWLBFqi (ORCPT ); Sat, 2 Dec 2006 05:46:38 +0000 Received: from shell0.pdx.osdl.net (fw.osdl.org [65.172.181.6]) by smtp.osdl.org (8.12.8/8.12.8) with ESMTP id kB25kVjQ014700 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Fri, 1 Dec 2006 21:46:31 -0800 Received: from box (shell0.pdx.osdl.net [10.9.0.31]) by shell0.pdx.osdl.net (8.13.1/8.11.6) with SMTP id kB25kRlr009054; Fri, 1 Dec 2006 21:46:27 -0800 Date: Fri, 1 Dec 2006 21:46:26 -0800 From: Andrew Morton To: Jeff Garzik Cc: "Maciej W. Rozycki" , netdev@vger.kernel.org, linux-mips@linux-mips.org Subject: Re: [PATCH 2.6.18] declance: Support the I/O ASIC LANCE w/o TURBOchannel Message-Id: <20061201214626.1c50dd38.akpm@osdl.org> In-Reply-To: <45710CFE.5090007@pobox.com> References: <45710CFE.5090007@pobox.com> X-Mailer: Sylpheed version 2.2.7 (GTK+ 2.8.17; x86_64-unknown-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-MIMEDefang-Filter: osdl$Revision: 1.161 $ X-Scanned-By: MIMEDefang 2.36 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: 13325 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: akpm@osdl.org Precedence: bulk X-list: linux-mips On Sat, 02 Dec 2006 00:19:58 -0500 Jeff Garzik wrote: > Maciej W. Rozycki wrote: > > The onboard LANCE of I/O ASIC systems is not a TURBOchannel device, at > > least from the software point of view. Therefore it does not rely on any > > kernel TURBOchannel bus services and can be supported even if support for > > TURBOchannel has not been enabled in the configuration. > > > > Signed-off-by: Maciej W. Rozycki > > can you (or Andrew) please resend your patches against 2.6.19? > I have then all (I think) queued up. Will send once I've done a round of build-testing. From hewei.fu@siemens.com Sun Dec 3 09:15:21 2006 Received: with ECARTIS (v1.0.0; list linux-mips); Sun, 03 Dec 2006 09:15:27 +0000 (GMT) Received: from david.siemens.com.cn ([194.138.202.53]:3809 "EHLO david.siemens.com.cn") by ftp.linux-mips.org with ESMTP id S20038753AbWLCJPV convert rfc822-to-8bit (ORCPT ); Sun, 3 Dec 2006 09:15:21 +0000 Received: from ns.siemens.com.cn (ns.siemens.com.cn [194.138.237.52]) by david.siemens.com.cn (8.11.7/8.11.7) with ESMTP id kB39FCJ10774 for ; Sun, 3 Dec 2006 17:15:17 +0800 (CST) Received: from pekw905a.cn001.siemens.net (localhost [127.0.0.1]) by ns.siemens.com.cn (8.11.7/8.11.7) with ESMTP id kB39FA111959 for ; Sun, 3 Dec 2006 17:15:12 +0800 (CST) Received: from PEKW934A.cn001.siemens.net ([139.24.236.66]) by pekw905a.cn001.siemens.net with Microsoft SMTPSVC(6.0.3790.1830); Sun, 3 Dec 2006 17:15:09 +0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 8BIT Subject: The difference between mips*-gnu and mips*-linux when configure tool-chain Date: Sun, 3 Dec 2006 17:15:07 +0800 Message-ID: <96E7D5519FC3D741BEE27AB88C7387970162312C@PEKW934A.cn001.siemens.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: The difference between mips*-gnu and mips*-linux when configure tool-chain Thread-Index: AccWu4aqDG6I9o1bQbac0KZMM452qQ== From: "Fu, He Wei PSE NKG" To: X-OriginalArrivalTime: 03 Dec 2006 09:15:10.0124 (UTC) FILETIME=[8816CEC0:01C716BB] 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: 13326 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: hewei.fu@siemens.com Precedence: bulk X-list: linux-mips Hello everyone.At the time of building tool-chain for mips machine,we can choose mips*-gnu or mips*-linux, I want to know what's the difference between them? The original idea is that mips*-gnu for developing firmware which has not OS-surport, and mips*-linux for developing software on Linux, but it is not suitable for firmware such as bootloaders.But now I think I'm not right,it seems that configure with mips*-linux suit for both linux and bootloader, and configure with mips*-gnu means build for OS such as IRIX surport, I'm not very clearly,can anybody help me figour out the difference between them? Thanks From anemo@mba.ocn.ne.jp Sun Dec 3 13:42:20 2006 Received: with ECARTIS (v1.0.0; list linux-mips); Sun, 03 Dec 2006 13:42:25 +0000 (GMT) Received: from mba.ocn.ne.jp ([210.190.142.172]:59632 "HELO smtp.mba.ocn.ne.jp") by ftp.linux-mips.org with SMTP id S20038804AbWLCNmU (ORCPT ); Sun, 3 Dec 2006 13:42:20 +0000 Received: from localhost (p6165-ipad201funabasi.chiba.ocn.ne.jp [222.146.69.165]) by smtp.mba.ocn.ne.jp (Postfix) with ESMTP id 08537C1E9; Sun, 3 Dec 2006 22:42:15 +0900 (JST) Date: Sun, 03 Dec 2006 22:42:14 +0900 (JST) Message-Id: <20061203.224214.74752582.anemo@mba.ocn.ne.jp> To: ralf@linux-mips.org Cc: kaz@zeugmasystems.com, linux-mips@linux-mips.org Subject: Re: N32 shmat problem identified! Kernel fix needed. From: Atsushi Nemoto In-Reply-To: <20061202022404.GA28637@linux-mips.org> References: <66910A579C9312469A7DF9ADB54A8B7D4B5F5F@exchange.ZeugmaSystems.local> <20061202022404.GA28637@linux-mips.org> 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 3.3 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: 13327 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 Sat, 2 Dec 2006 02:24:04 +0000, Ralf Baechle wrote: > > The fix is to remove this function from the code base and quite simply > > to wire the normal sys_shmat into the n32 syscall table. Since there is > > in fact no pointer-to-pointer argument, this function doesn't have a 32 > > bit compatibility issues. > > That's fixed since two months. Minor correction: about a month, not two :) http://www.linux-mips.org/archives/linux-mips/2006-11/msg00030.html This fix is already merged to master and linux-2.6.1x-stable branches in linux-mips.org tree, though not merged to kernel.org's tree yet unfortunately. --- Atsushi Nemoto From anemo@mba.ocn.ne.jp Sun Dec 3 15:33:47 2006 Received: with ECARTIS (v1.0.0; list linux-mips); Sun, 03 Dec 2006 15:33:52 +0000 (GMT) Received: from mba.ocn.ne.jp ([210.190.142.172]:45257 "HELO smtp.mba.ocn.ne.jp") by ftp.linux-mips.org with SMTP id S20038817AbWLCPdr (ORCPT ); Sun, 3 Dec 2006 15:33:47 +0000 Received: from localhost (p6165-ipad201funabasi.chiba.ocn.ne.jp [222.146.69.165]) by smtp.mba.ocn.ne.jp (Postfix) with ESMTP id 7ED55C0D1; Mon, 4 Dec 2006 00:33:42 +0900 (JST) Date: Mon, 04 Dec 2006 00:33:42 +0900 (JST) Message-Id: <20061204.003342.75185311.anemo@mba.ocn.ne.jp> To: linux-mips@linux-mips.org Cc: ralf@linux-mips.org Subject: [PATCH] fix 64-bit build From: Atsushi Nemoto 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 3.3 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: 13328 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 commit d89d8e0637a5e4e0a12e90c4bc934d0d4c335239 break 64-bit build. Signed-off-by: Atsushi Nemoto diff --git a/include/asm-mips/atomic.h b/include/asm-mips/atomic.h index 7978d8e..3657670 100644 --- a/include/asm-mips/atomic.h +++ b/include/asm-mips/atomic.h @@ -375,7 +375,7 @@ #define atomic_add_negative(i,v) (atomic #ifdef CONFIG_64BIT -typedef struct { volatile __s64 counter; } atomic64_t; +typedef struct { volatile long counter; } atomic64_t; #define ATOMIC64_INIT(i) { (i) } From anemo@mba.ocn.ne.jp Sun Dec 3 15:43:04 2006 Received: with ECARTIS (v1.0.0; list linux-mips); Sun, 03 Dec 2006 15:43:10 +0000 (GMT) Received: from mba.ocn.ne.jp ([210.190.142.172]:36295 "HELO smtp.mba.ocn.ne.jp") by ftp.linux-mips.org with SMTP id S20038819AbWLCPnE (ORCPT ); Sun, 3 Dec 2006 15:43:04 +0000 Received: from localhost (p6165-ipad201funabasi.chiba.ocn.ne.jp [222.146.69.165]) by smtp.mba.ocn.ne.jp (Postfix) with ESMTP id 33FE7BC95; Mon, 4 Dec 2006 00:42:59 +0900 (JST) Date: Mon, 04 Dec 2006 00:42:59 +0900 (JST) Message-Id: <20061204.004259.63130921.anemo@mba.ocn.ne.jp> To: linux-mips@linux-mips.org Cc: ralf@linux-mips.org Subject: [PATCH] Unify csum_partial.S From: Atsushi Nemoto 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 3.3 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: 13329 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 The 32-bit version and 64-bit version are almost equal. Unify them. This makes further improvements (for example, copying with parallel, supporting PREFETCH, etc.) easier. Signed-off-by: Atsushi Nemoto --- arch/mips/lib-32/Makefile | 2 arch/mips/lib-32/csum_partial.S | 240 --------------------------- arch/mips/lib-64/Makefile | 2 arch/mips/lib-64/csum_partial.S | 242 ---------------------------- arch/mips/lib/Makefile | 4 arch/mips/lib/csum_partial.S | 258 ++++++++++++++++++++++++++++++ 6 files changed, 262 insertions(+), 486 deletions(-) diff --git a/arch/mips/lib-32/Makefile b/arch/mips/lib-32/Makefile index ad28578..dcd4d2e 100644 --- a/arch/mips/lib-32/Makefile +++ b/arch/mips/lib-32/Makefile @@ -2,7 +2,7 @@ # # Makefile for MIPS-specific library files.. # -lib-y += csum_partial.o memset.o watch.o +lib-y += memset.o watch.o obj-$(CONFIG_CPU_MIPS32) += dump_tlb.o obj-$(CONFIG_CPU_MIPS64) += dump_tlb.o diff --git a/arch/mips/lib-32/csum_partial.S b/arch/mips/lib-32/csum_partial.S deleted file mode 100644 index ea257db..0000000 --- a/arch/mips/lib-32/csum_partial.S +++ /dev/null @@ -1,240 +0,0 @@ -/* - * 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) 1998 Ralf Baechle - */ -#include -#include - -#define ADDC(sum,reg) \ - addu sum, reg; \ - sltu v1, sum, reg; \ - addu sum, v1 - -#define CSUM_BIGCHUNK(src, offset, sum, t0, t1, t2, t3) \ - lw t0, (offset + 0x00)(src); \ - lw t1, (offset + 0x04)(src); \ - lw t2, (offset + 0x08)(src); \ - lw t3, (offset + 0x0c)(src); \ - ADDC(sum, t0); \ - ADDC(sum, t1); \ - ADDC(sum, t2); \ - ADDC(sum, t3); \ - lw t0, (offset + 0x10)(src); \ - lw t1, (offset + 0x14)(src); \ - lw t2, (offset + 0x18)(src); \ - lw t3, (offset + 0x1c)(src); \ - ADDC(sum, t0); \ - ADDC(sum, t1); \ - ADDC(sum, t2); \ - ADDC(sum, t3); \ - -/* - * a0: source address - * a1: length of the area to checksum - * a2: partial checksum - */ - -#define src a0 -#define dest a1 -#define sum v0 - - .text - .set noreorder - -/* unknown src alignment and < 8 bytes to go */ -small_csumcpy: - move a1, t2 - - andi t0, a1, 4 - beqz t0, 1f - andi t0, a1, 2 - - /* Still a full word to go */ - ulw t1, (src) - addiu src, 4 - ADDC(sum, t1) - -1: move t1, zero - beqz t0, 1f - andi t0, a1, 1 - - /* Still a halfword to go */ - ulhu t1, (src) - addiu src, 2 - -1: beqz t0, 1f - sll t1, t1, 16 - - lbu t2, (src) - nop - -#ifdef __MIPSEB__ - sll t2, t2, 8 -#endif - or t1, t2 - -1: ADDC(sum, t1) - - /* fold checksum */ - sll v1, sum, 16 - addu sum, v1 - sltu v1, sum, v1 - srl sum, sum, 16 - addu sum, v1 - - /* odd buffer alignment? */ - beqz t7, 1f - nop - sll v1, sum, 8 - srl sum, sum, 8 - or sum, v1 - andi sum, 0xffff -1: - .set reorder - /* Add the passed partial csum. */ - ADDC(sum, a2) - jr ra - .set noreorder - -/* ------------------------------------------------------------------------- */ - - .align 5 -LEAF(csum_partial) - move sum, zero - move t7, zero - - sltiu t8, a1, 0x8 - bnez t8, small_csumcpy /* < 8 bytes to copy */ - move t2, a1 - - beqz a1, out - andi t7, src, 0x1 /* odd buffer? */ - -hword_align: - beqz t7, word_align - andi t8, src, 0x2 - - lbu t0, (src) - subu a1, a1, 0x1 -#ifdef __MIPSEL__ - sll t0, t0, 8 -#endif - ADDC(sum, t0) - addu src, src, 0x1 - andi t8, src, 0x2 - -word_align: - beqz t8, dword_align - sltiu t8, a1, 56 - - lhu t0, (src) - subu a1, a1, 0x2 - ADDC(sum, t0) - sltiu t8, a1, 56 - addu src, src, 0x2 - -dword_align: - bnez t8, do_end_words - move t8, a1 - - andi t8, src, 0x4 - beqz t8, qword_align - andi t8, src, 0x8 - - lw t0, 0x00(src) - subu a1, a1, 0x4 - ADDC(sum, t0) - addu src, src, 0x4 - andi t8, src, 0x8 - -qword_align: - beqz t8, oword_align - andi t8, src, 0x10 - - lw t0, 0x00(src) - lw t1, 0x04(src) - subu a1, a1, 0x8 - ADDC(sum, t0) - ADDC(sum, t1) - addu src, src, 0x8 - andi t8, src, 0x10 - -oword_align: - beqz t8, begin_movement - srl t8, a1, 0x7 - - lw t3, 0x08(src) - lw t4, 0x0c(src) - lw t0, 0x00(src) - lw t1, 0x04(src) - ADDC(sum, t3) - ADDC(sum, t4) - ADDC(sum, t0) - ADDC(sum, t1) - subu a1, a1, 0x10 - addu src, src, 0x10 - srl t8, a1, 0x7 - -begin_movement: - beqz t8, 1f - andi t2, a1, 0x40 - -move_128bytes: - CSUM_BIGCHUNK(src, 0x00, sum, t0, t1, t3, t4) - CSUM_BIGCHUNK(src, 0x20, sum, t0, t1, t3, t4) - CSUM_BIGCHUNK(src, 0x40, sum, t0, t1, t3, t4) - CSUM_BIGCHUNK(src, 0x60, sum, t0, t1, t3, t4) - subu t8, t8, 0x01 - bnez t8, move_128bytes - addu src, src, 0x80 - -1: - beqz t2, 1f - andi t2, a1, 0x20 - -move_64bytes: - CSUM_BIGCHUNK(src, 0x00, sum, t0, t1, t3, t4) - CSUM_BIGCHUNK(src, 0x20, sum, t0, t1, t3, t4) - addu src, src, 0x40 - -1: - beqz t2, do_end_words - andi t8, a1, 0x1c - -move_32bytes: - CSUM_BIGCHUNK(src, 0x00, sum, t0, t1, t3, t4) - andi t8, a1, 0x1c - addu src, src, 0x20 - -do_end_words: - beqz t8, maybe_end_cruft - srl t8, t8, 0x2 - -end_words: - lw t0, (src) - subu t8, t8, 0x1 - ADDC(sum, t0) - bnez t8, end_words - addu src, src, 0x4 - -maybe_end_cruft: - andi t2, a1, 0x3 - -small_memcpy: - j small_csumcpy; move a1, t2 - beqz t2, out - move a1, t2 - -end_bytes: - lb t0, (src) - subu a1, a1, 0x1 - bnez a2, end_bytes - addu src, src, 0x1 - -out: - jr ra - move v0, sum - END(csum_partial) diff --git a/arch/mips/lib-64/Makefile b/arch/mips/lib-64/Makefile index ad28578..dcd4d2e 100644 --- a/arch/mips/lib-64/Makefile +++ b/arch/mips/lib-64/Makefile @@ -2,7 +2,7 @@ # # Makefile for MIPS-specific library files.. # -lib-y += csum_partial.o memset.o watch.o +lib-y += memset.o watch.o obj-$(CONFIG_CPU_MIPS32) += dump_tlb.o obj-$(CONFIG_CPU_MIPS64) += dump_tlb.o diff --git a/arch/mips/lib-64/csum_partial.S b/arch/mips/lib-64/csum_partial.S deleted file mode 100644 index 25aba66..0000000 --- a/arch/mips/lib-64/csum_partial.S +++ /dev/null @@ -1,242 +0,0 @@ -/* - * 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. - * - * Quick'n'dirty IP checksum ... - * - * Copyright (C) 1998, 1999 Ralf Baechle - * Copyright (C) 1999 Silicon Graphics, Inc. - */ -#include -#include - -#define ADDC(sum,reg) \ - addu sum, reg; \ - sltu v1, sum, reg; \ - addu sum, v1 - -#define CSUM_BIGCHUNK(src, offset, sum, t0, t1, t2, t3) \ - lw t0, (offset + 0x00)(src); \ - lw t1, (offset + 0x04)(src); \ - lw t2, (offset + 0x08)(src); \ - lw t3, (offset + 0x0c)(src); \ - ADDC(sum, t0); \ - ADDC(sum, t1); \ - ADDC(sum, t2); \ - ADDC(sum, t3); \ - lw t0, (offset + 0x10)(src); \ - lw t1, (offset + 0x14)(src); \ - lw t2, (offset + 0x18)(src); \ - lw t3, (offset + 0x1c)(src); \ - ADDC(sum, t0); \ - ADDC(sum, t1); \ - ADDC(sum, t2); \ - ADDC(sum, t3); \ - -/* - * a0: source address - * a1: length of the area to checksum - * a2: partial checksum - */ - -#define src a0 -#define sum v0 - - .text - .set noreorder - -/* unknown src alignment and < 8 bytes to go */ -small_csumcpy: - move a1, ta2 - - andi ta0, a1, 4 - beqz ta0, 1f - andi ta0, a1, 2 - - /* Still a full word to go */ - ulw ta1, (src) - daddiu src, 4 - ADDC(sum, ta1) - -1: move ta1, zero - beqz ta0, 1f - andi ta0, a1, 1 - - /* Still a halfword to go */ - ulhu ta1, (src) - daddiu src, 2 - -1: beqz ta0, 1f - sll ta1, ta1, 16 - - lbu ta2, (src) - nop - -#ifdef __MIPSEB__ - sll ta2, ta2, 8 -#endif - or ta1, ta2 - -1: ADDC(sum, ta1) - - /* fold checksum */ - sll v1, sum, 16 - addu sum, v1 - sltu v1, sum, v1 - srl sum, sum, 16 - addu sum, v1 - - /* odd buffer alignment? */ - beqz t3, 1f - nop - sll v1, sum, 8 - srl sum, sum, 8 - or sum, v1 - andi sum, 0xffff -1: - .set reorder - /* Add the passed partial csum. */ - ADDC(sum, a2) - jr ra - .set noreorder - -/* ------------------------------------------------------------------------- */ - - .align 5 -LEAF(csum_partial) - move sum, zero - move t3, zero - - sltiu t8, a1, 0x8 - bnez t8, small_csumcpy /* < 8 bytes to copy */ - move ta2, a1 - - beqz a1, out - andi t3, src, 0x1 /* odd buffer? */ - -hword_align: - beqz t3, word_align - andi t8, src, 0x2 - - lbu ta0, (src) - dsubu a1, a1, 0x1 -#ifdef __MIPSEL__ - sll ta0, ta0, 8 -#endif - ADDC(sum, ta0) - daddu src, src, 0x1 - andi t8, src, 0x2 - -word_align: - beqz t8, dword_align - sltiu t8, a1, 56 - - lhu ta0, (src) - dsubu a1, a1, 0x2 - ADDC(sum, ta0) - sltiu t8, a1, 56 - daddu src, src, 0x2 - -dword_align: - bnez t8, do_end_words - move t8, a1 - - andi t8, src, 0x4 - beqz t8, qword_align - andi t8, src, 0x8 - - lw ta0, 0x00(src) - dsubu a1, a1, 0x4 - ADDC(sum, ta0) - daddu src, src, 0x4 - andi t8, src, 0x8 - -qword_align: - beqz t8, oword_align - andi t8, src, 0x10 - - lw ta0, 0x00(src) - lw ta1, 0x04(src) - dsubu a1, a1, 0x8 - ADDC(sum, ta0) - ADDC(sum, ta1) - daddu src, src, 0x8 - andi t8, src, 0x10 - -oword_align: - beqz t8, begin_movement - dsrl t8, a1, 0x7 - - lw ta3, 0x08(src) - lw t0, 0x0c(src) - lw ta0, 0x00(src) - lw ta1, 0x04(src) - ADDC(sum, ta3) - ADDC(sum, t0) - ADDC(sum, ta0) - ADDC(sum, ta1) - dsubu a1, a1, 0x10 - daddu src, src, 0x10 - dsrl t8, a1, 0x7 - -begin_movement: - beqz t8, 1f - andi ta2, a1, 0x40 - -move_128bytes: - CSUM_BIGCHUNK(src, 0x00, sum, ta0, ta1, ta3, t0) - CSUM_BIGCHUNK(src, 0x20, sum, ta0, ta1, ta3, t0) - CSUM_BIGCHUNK(src, 0x40, sum, ta0, ta1, ta3, t0) - CSUM_BIGCHUNK(src, 0x60, sum, ta0, ta1, ta3, t0) - dsubu t8, t8, 0x01 - bnez t8, move_128bytes - daddu src, src, 0x80 - -1: - beqz ta2, 1f - andi ta2, a1, 0x20 - -move_64bytes: - CSUM_BIGCHUNK(src, 0x00, sum, ta0, ta1, ta3, t0) - CSUM_BIGCHUNK(src, 0x20, sum, ta0, ta1, ta3, t0) - daddu src, src, 0x40 - -1: - beqz ta2, do_end_words - andi t8, a1, 0x1c - -move_32bytes: - CSUM_BIGCHUNK(src, 0x00, sum, ta0, ta1, ta3, t0) - andi t8, a1, 0x1c - daddu src, src, 0x20 - -do_end_words: - beqz t8, maybe_end_cruft - dsrl t8, t8, 0x2 - -end_words: - lw ta0, (src) - dsubu t8, t8, 0x1 - ADDC(sum, ta0) - bnez t8, end_words - daddu src, src, 0x4 - -maybe_end_cruft: - andi ta2, a1, 0x3 - -small_memcpy: - j small_csumcpy; move a1, ta2 /* XXX ??? */ - beqz t2, out - move a1, ta2 - -end_bytes: - lb ta0, (src) - dsubu a1, a1, 0x1 - bnez a2, end_bytes - daddu src, src, 0x1 - -out: - jr ra - move v0, sum - END(csum_partial) diff --git a/arch/mips/lib/Makefile b/arch/mips/lib/Makefile index 7e86f0c..42a2b24 100644 --- a/arch/mips/lib/Makefile +++ b/arch/mips/lib/Makefile @@ -2,8 +2,8 @@ # # Makefile for MIPS-specific library files.. # -lib-y += csum_partial_copy.o memcpy.o promlib.o strlen_user.o strncpy_user.o \ - strnlen_user.o uncached.o +lib-y += csum_partial.o csum_partial_copy.o memcpy.o promlib.o \ + strlen_user.o strncpy_user.o strnlen_user.o uncached.o # libgcc-style stuff needed in the kernel lib-y += ashldi3.o ashrdi3.o lshrdi3.o diff --git a/arch/mips/lib/csum_partial.S b/arch/mips/lib/csum_partial.S new file mode 100644 index 0000000..15611d9 --- /dev/null +++ b/arch/mips/lib/csum_partial.S @@ -0,0 +1,258 @@ +/* + * 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. + * + * Quick'n'dirty IP checksum ... + * + * Copyright (C) 1998, 1999 Ralf Baechle + * Copyright (C) 1999 Silicon Graphics, Inc. + */ +#include +#include + +#ifdef CONFIG_64BIT +#define T0 ta0 +#define T1 ta1 +#define T2 ta2 +#define T3 ta3 +#define T4 t0 +#define T7 t3 +#else +#define T0 t0 +#define T1 t1 +#define T2 t2 +#define T3 t3 +#define T4 t4 +#define T7 t7 +#endif + +#define ADDC(sum,reg) \ + addu sum, reg; \ + sltu v1, sum, reg; \ + addu sum, v1 + +#define CSUM_BIGCHUNK(src, offset, sum, _t0, _t1, _t2, _t3) \ + lw _t0, (offset + 0x00)(src); \ + lw _t1, (offset + 0x04)(src); \ + lw _t2, (offset + 0x08)(src); \ + lw _t3, (offset + 0x0c)(src); \ + ADDC(sum, _t0); \ + ADDC(sum, _t1); \ + ADDC(sum, _t2); \ + ADDC(sum, _t3); \ + lw _t0, (offset + 0x10)(src); \ + lw _t1, (offset + 0x14)(src); \ + lw _t2, (offset + 0x18)(src); \ + lw _t3, (offset + 0x1c)(src); \ + ADDC(sum, _t0); \ + ADDC(sum, _t1); \ + ADDC(sum, _t2); \ + ADDC(sum, _t3); \ + +/* + * a0: source address + * a1: length of the area to checksum + * a2: partial checksum + */ + +#define src a0 +#define sum v0 + + .text + .set noreorder + +/* unknown src alignment and < 8 bytes to go */ +small_csumcpy: + move a1, T2 + + andi T0, a1, 4 + beqz T0, 1f + andi T0, a1, 2 + + /* Still a full word to go */ + ulw T1, (src) + PTR_ADDIU src, 4 + ADDC(sum, T1) + +1: move T1, zero + beqz T0, 1f + andi T0, a1, 1 + + /* Still a halfword to go */ + ulhu T1, (src) + PTR_ADDIU src, 2 + +1: beqz T0, 1f + sll T1, T1, 16 + + lbu T2, (src) + nop + +#ifdef __MIPSEB__ + sll T2, T2, 8 +#endif + or T1, T2 + +1: ADDC(sum, T1) + + /* fold checksum */ + sll v1, sum, 16 + addu sum, v1 + sltu v1, sum, v1 + srl sum, sum, 16 + addu sum, v1 + + /* odd buffer alignment? */ + beqz T7, 1f + nop + sll v1, sum, 8 + srl sum, sum, 8 + or sum, v1 + andi sum, 0xffff +1: + .set reorder + /* Add the passed partial csum. */ + ADDC(sum, a2) + jr ra + .set noreorder + +/* ------------------------------------------------------------------------- */ + + .align 5 +LEAF(csum_partial) + move sum, zero + move T7, zero + + sltiu t8, a1, 0x8 + bnez t8, small_csumcpy /* < 8 bytes to copy */ + move T2, a1 + + beqz a1, out + andi T7, src, 0x1 /* odd buffer? */ + +hword_align: + beqz T7, word_align + andi t8, src, 0x2 + + lbu T0, (src) + LONG_SUBU a1, a1, 0x1 +#ifdef __MIPSEL__ + sll T0, T0, 8 +#endif + ADDC(sum, T0) + PTR_ADDU src, src, 0x1 + andi t8, src, 0x2 + +word_align: + beqz t8, dword_align + sltiu t8, a1, 56 + + lhu T0, (src) + LONG_SUBU a1, a1, 0x2 + ADDC(sum, T0) + sltiu t8, a1, 56 + PTR_ADDU src, src, 0x2 + +dword_align: + bnez t8, do_end_words + move t8, a1 + + andi t8, src, 0x4 + beqz t8, qword_align + andi t8, src, 0x8 + + lw T0, 0x00(src) + LONG_SUBU a1, a1, 0x4 + ADDC(sum, T0) + PTR_ADDU src, src, 0x4 + andi t8, src, 0x8 + +qword_align: + beqz t8, oword_align + andi t8, src, 0x10 + + lw T0, 0x00(src) + lw T1, 0x04(src) + LONG_SUBU a1, a1, 0x8 + ADDC(sum, T0) + ADDC(sum, T1) + PTR_ADDU src, src, 0x8 + andi t8, src, 0x10 + +oword_align: + beqz t8, begin_movement + LONG_SRL t8, a1, 0x7 + + lw T3, 0x08(src) + lw T4, 0x0c(src) + lw T0, 0x00(src) + lw T1, 0x04(src) + ADDC(sum, T3) + ADDC(sum, T4) + ADDC(sum, T0) + ADDC(sum, T1) + LONG_SUBU a1, a1, 0x10 + PTR_ADDU src, src, 0x10 + LONG_SRL t8, a1, 0x7 + +begin_movement: + beqz t8, 1f + andi T2, a1, 0x40 + +move_128bytes: + CSUM_BIGCHUNK(src, 0x00, sum, T0, T1, T3, T4) + CSUM_BIGCHUNK(src, 0x20, sum, T0, T1, T3, T4) + CSUM_BIGCHUNK(src, 0x40, sum, T0, T1, T3, T4) + CSUM_BIGCHUNK(src, 0x60, sum, T0, T1, T3, T4) + LONG_SUBU t8, t8, 0x01 + bnez t8, move_128bytes + PTR_ADDU src, src, 0x80 + +1: + beqz T2, 1f + andi T2, a1, 0x20 + +move_64bytes: + CSUM_BIGCHUNK(src, 0x00, sum, T0, T1, T3, T4) + CSUM_BIGCHUNK(src, 0x20, sum, T0, T1, T3, T4) + PTR_ADDU src, src, 0x40 + +1: + beqz T2, do_end_words + andi t8, a1, 0x1c + +move_32bytes: + CSUM_BIGCHUNK(src, 0x00, sum, T0, T1, T3, T4) + andi t8, a1, 0x1c + PTR_ADDU src, src, 0x20 + +do_end_words: + beqz t8, maybe_end_cruft + LONG_SRL t8, t8, 0x2 + +end_words: + lw T0, (src) + LONG_SUBU t8, t8, 0x1 + ADDC(sum, T0) + bnez t8, end_words + PTR_ADDU src, src, 0x4 + +maybe_end_cruft: + andi T2, a1, 0x3 + +small_memcpy: + j small_csumcpy; move a1, T2 /* XXX ??? */ + beqz t2, out + move a1, T2 + +end_bytes: + lb T0, (src) + LONG_SUBU a1, a1, 0x1 + bnez a2, end_bytes + PTR_ADDU src, src, 0x1 + +out: + jr ra + move v0, sum + END(csum_partial) From anemo@mba.ocn.ne.jp Sun Dec 3 16:53:31 2006 Received: with ECARTIS (v1.0.0; list linux-mips); Sun, 03 Dec 2006 16:53:36 +0000 (GMT) Received: from mba.ocn.ne.jp ([210.190.142.172]:39925 "HELO smtp.mba.ocn.ne.jp") by ftp.linux-mips.org with SMTP id S20037479AbWLCQxb (ORCPT ); Sun, 3 Dec 2006 16:53:31 +0000 Received: from localhost (p6165-ipad201funabasi.chiba.ocn.ne.jp [222.146.69.165]) by smtp.mba.ocn.ne.jp (Postfix) with ESMTP id CBF0CC0CE for ; Mon, 4 Dec 2006 01:53:27 +0900 (JST) Date: Mon, 04 Dec 2006 01:53:27 +0900 (JST) Message-Id: <20061204.015327.36921579.anemo@mba.ocn.ne.jp> To: linux-mips@linux-mips.org Subject: Re: [MIPS] Use conditional traps for BUG_ON on MIPS II and better. From: Atsushi Nemoto In-Reply-To: References: 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 3.3 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: 13330 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 Thu, 30 Nov 2006 01:23:17 +0000, linux-mips@linux-mips.org wrote: > Author: Ralf Baechle Mon Oct 16 01:38:50 2006 +0100 > Commit: 17243c78ae5f25c8901da05ca4eab0968dddb16f > Gitweb: http://www.linux-mips.org/g/linux/17243c78 > Branch: master > > This shaves of around 4kB and a few cycles for the average kernel that > has CONFIG_BUG enabled. > > Signed-off-by: Ralf Baechle It seems this commit break QEMU kernel ... or QEMU can not interpret the TNE instruction correctly? --- Atsushi Nemoto From drow@nevyn.them.org Sun Dec 3 17:05:20 2006 Received: with ECARTIS (v1.0.0; list linux-mips); Sun, 03 Dec 2006 17:05:24 +0000 (GMT) Received: from nevyn.them.org ([66.93.172.17]:49287 "EHLO nevyn.them.org") by ftp.linux-mips.org with ESMTP id S20037526AbWLCRFU (ORCPT ); Sun, 3 Dec 2006 17:05:20 +0000 Received: from drow by nevyn.them.org with local (Exim 4.63) (envelope-from ) id 1GqumB-0002w5-Rf; Sun, 03 Dec 2006 12:05:15 -0500 Date: Sun, 3 Dec 2006 12:05:15 -0500 From: Daniel Jacobowitz To: "Fu, He Wei PSE NKG" Cc: linux-mips@linux-mips.org Subject: Re: The difference between mips*-gnu and mips*-linux when configure tool-chain Message-ID: <20061203170514.GA11258@nevyn.them.org> References: <96E7D5519FC3D741BEE27AB88C7387970162312C@PEKW934A.cn001.siemens.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <96E7D5519FC3D741BEE27AB88C7387970162312C@PEKW934A.cn001.siemens.net> 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: 13331 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 Sun, Dec 03, 2006 at 05:15:07PM +0800, Fu, He Wei PSE NKG wrote: > Hello everyone.At the time of building tool-chain for mips machine,we > can choose mips*-gnu or mips*-linux, I want to know what's the > difference between them? The original idea is that mips*-gnu for > developing firmware which has not OS-surport, and mips*-linux for > developing software on Linux, but it is not suitable for firmware such > as bootloaders.But now I think I'm not right,it seems that configure > with mips*-linux suit for both linux and bootloader, and configure with > mips*-gnu means build for OS such as IRIX surport, I'm not very > clearly,can anybody help me figour out the difference between them? mips-gnu is the GNU system (the Hurd kernel). mips-linux is used for the kernel and userspace of a Linux system. mips-elf is used for bare metal targets without an OS. You should be able to build a Linux bootloader using a mips-linux compiler. -- Daniel Jacobowitz CodeSourcery From ralf@linux-mips.org Sun Dec 3 21:35:19 2006 Received: with ECARTIS (v1.0.0; list linux-mips); Sun, 03 Dec 2006 21:35:21 +0000 (GMT) Received: from localhost.localdomain ([127.0.0.1]:43744 "EHLO dl5rb.ham-radio-op.net") by ftp.linux-mips.org with ESMTP id S20037799AbWLCVfT (ORCPT ); Sun, 3 Dec 2006 21:35:19 +0000 Received: from denk.linux-mips.net (denk.linux-mips.net [127.0.0.1]) by dl5rb.ham-radio-op.net (8.13.8/8.13.8) with ESMTP id kB3LZJub024195; Sun, 3 Dec 2006 21:35:19 GMT Received: (from ralf@localhost) by denk.linux-mips.net (8.13.8/8.13.8/Submit) id kB3LZIwe024194; Sun, 3 Dec 2006 21:35:18 GMT Date: Sun, 3 Dec 2006 21:35:18 +0000 From: Ralf Baechle To: Atsushi Nemoto Cc: linux-mips@linux-mips.org Subject: Re: [MIPS] Use conditional traps for BUG_ON on MIPS II and better. Message-ID: <20061203213518.GA22225@linux-mips.org> References: <20061204.015327.36921579.anemo@mba.ocn.ne.jp> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20061204.015327.36921579.anemo@mba.ocn.ne.jp> User-Agent: Mutt/1.4.2.2i 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: 13332 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, Dec 04, 2006 at 01:53:27AM +0900, Atsushi Nemoto wrote: > > This shaves of around 4kB and a few cycles for the average kernel that > > has CONFIG_BUG enabled. > > > > Signed-off-by: Ralf Baechle > > It seems this commit break QEMU kernel ... or QEMU can not interpret > the TNE instruction correctly? Thiemo says that's indeed a possibility. Probably that feature has not been well tested in qemu. Ralf From m.kozlowski@tuxland.pl Mon Dec 4 09:36:45 2006 Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 04 Dec 2006 09:36:49 +0000 (GMT) Received: from xdsl-664.zgora.dialog.net.pl ([81.168.226.152]:37640 "EHLO tuxland.pl") by ftp.linux-mips.org with ESMTP id S20038708AbWLDJgp convert rfc822-to-8bit (ORCPT ); Mon, 4 Dec 2006 09:36:45 +0000 Received: from [192.168.1.3] (xdsl-664.zgora.dialog.net.pl [81.168.226.152]) by tuxland.pl (Postfix) with ESMTP id 70C4F6EF87; Mon, 4 Dec 2006 10:36:23 +0100 (CET) Received: from [192.168.1.3] ([192.168.1.3]) by tuxland.pl (AISK); Mon, 04 Dec 2006 10:36:22 +0100 (CET) From: Mariusz Kozlowski To: ralf@linux-mips.org Subject: [2.4 PATCH] mips/mips64 mv64340 parenthesis fixes Date: Mon, 4 Dec 2006 10:36:21 +0100 User-Agent: KMail/1.9.5 Cc: linux-mips@linux-mips.org, Willy Tarreau MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-2" Content-Transfer-Encoding: 8BIT Content-Disposition: inline Message-Id: <200612041036.21953.m.kozlowski@tuxland.pl> 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: 13333 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.kozlowski@tuxland.pl Precedence: bulk X-list: linux-mips Hello,         This patch fixes parenthesis mv64340 stuff in both mips and mips64 code. Signed-off-by: Mariusz Kozlowski  include/asm-mips/mv64340.h   |    2 +-  include/asm-mips64/mv64340.h |    2 +-  2 files changed, 2 insertions(+), 2 deletions(-) diff -upr linux-2.4.34-pre6-a/include/asm-mips/mv64340.h linux-2.4.34-pre6-b/include/asm-mips/mv64340.h --- linux-2.4.34-pre6-a/include/asm-mips/mv64340.h 2003-08-25 13:44:43.000000000 +0200 +++ linux-2.4.34-pre6-b/include/asm-mips/mv64340.h 2006-12-01 11:56:57.000000000 +0100 @@ -718,7 +718,7 @@ #define MV64340_ETH_RX_FIFO_URGENT_THRESHOLD_REG(port) (0x2470 + (port<<10)) #define MV64340_ETH_TX_FIFO_URGENT_THRESHOLD_REG(port) (0x2474 + (port<<10)) #define MV64340_ETH_RX_MINIMAL_FRAME_SIZE_REG(port) (0x247c + (port<<10)) -#define MV64340_ETH_RX_DISCARDED_FRAMES_COUNTER(port) (0x2484 + (port<<10) +#define MV64340_ETH_RX_DISCARDED_FRAMES_COUNTER(port) (0x2484 + (port<<10)) #define MV64340_ETH_PORT_DEBUG_0_REG(port) (0x248c + (port<<10)) #define MV64340_ETH_PORT_DEBUG_1_REG(port) (0x2490 + (port<<10)) #define MV64340_ETH_PORT_INTERNAL_ADDR_ERROR_REG(port) (0x2494 + (port<<10)) diff -upr linux-2.4.34-pre6-a/include/asm-mips64/mv64340.h linux-2.4.34-pre6-b/include/asm-mips64/mv64340.h --- linux-2.4.34-pre6-a/include/asm-mips64/mv64340.h 2003-08-25 13:44:44.000000000 +0200 +++ linux-2.4.34-pre6-b/include/asm-mips64/mv64340.h 2006-12-01 12:01:03.000000000 +0100 @@ -718,7 +718,7 @@ #define MV64340_ETH_RX_FIFO_URGENT_THRESHOLD_REG(port) (0x2470 + (port<<10)) #define MV64340_ETH_TX_FIFO_URGENT_THRESHOLD_REG(port) (0x2474 + (port<<10)) #define MV64340_ETH_RX_MINIMAL_FRAME_SIZE_REG(port) (0x247c + (port<<10)) -#define MV64340_ETH_RX_DISCARDED_FRAMES_COUNTER(port) (0x2484 + (port<<10) +#define MV64340_ETH_RX_DISCARDED_FRAMES_COUNTER(port) (0x2484 + (port<<10)) #define MV64340_ETH_PORT_DEBUG_0_REG(port) (0x248c + (port<<10)) #define MV64340_ETH_PORT_DEBUG_1_REG(port) (0x2490 + (port<<10)) #define MV64340_ETH_PORT_INTERNAL_ADDR_ERROR_REG(port) (0x2494 + (port<<10)) -- Regards, Mariusz Kozlowski From m.kozlowski@tuxland.pl Mon Dec 4 09:37:43 2006 Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 04 Dec 2006 09:37:47 +0000 (GMT) Received: from xdsl-664.zgora.dialog.net.pl ([81.168.226.152]:38152 "EHLO tuxland.pl") by ftp.linux-mips.org with ESMTP id S20038722AbWLDJhn convert rfc822-to-8bit (ORCPT ); Mon, 4 Dec 2006 09:37:43 +0000 Received: from [192.168.1.3] (xdsl-664.zgora.dialog.net.pl [81.168.226.152]) by tuxland.pl (Postfix) with ESMTP id 022B06EF87; Mon, 4 Dec 2006 10:37:22 +0100 (CET) Received: from [192.168.1.3] ([192.168.1.3]) by tuxland.pl (AISK); Mon, 04 Dec 2006 10:37:22 +0100 (CET) From: Mariusz Kozlowski To: ralf@linux-mips.org Subject: [2.4 PATCH] mips64 klconfig parenthesis fix Date: Mon, 4 Dec 2006 10:37:21 +0100 User-Agent: KMail/1.9.5 Cc: linux-mips@linux-mips.org, Willy Tarreau MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-2" Content-Transfer-Encoding: 8BIT Content-Disposition: inline Message-Id: <200612041037.21563.m.kozlowski@tuxland.pl> 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: 13334 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.kozlowski@tuxland.pl Precedence: bulk X-list: linux-mips Hello,         This patch fixes parenthesis stuff in PTR_CH_MALLOC_HDR() macro code. Signed-off-by: Mariusz Kozlowski  include/asm-mips64/sn/klconfig.h |    2 +-  1 file changed, 1 insertion(+), 1 deletion(-) --- linux-2.4.34-pre6-a/include/asm-mips64/sn/klconfig.h 2002-11-29 00:53:15.000000000 +0100 +++ linux-2.4.34-pre6-b/include/asm-mips64/sn/klconfig.h 2006-12-01 12:01:25.000000000 +0100 @@ -196,7 +196,7 @@ typedef struct kl_config_hdr { ((__psunsigned_t)_k + (_k->ch_malloc_hdr_off))) #else #define PTR_CH_MALLOC_HDR(_k) ((klc_malloc_hdr_t *)\ - (unsigned long)_k + (_k->ch_malloc_hdr_off))) + ((unsigned long)_k + (_k->ch_malloc_hdr_off))) #endif #define KL_CONFIG_CH_MALLOC_HDR(_n) PTR_CH_MALLOC_HDR(KL_CONFIG_HDR(_n)) -- Regards, Mariusz Kozlowski From macro@linux-mips.org Mon Dec 4 12:06:17 2006 Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 04 Dec 2006 12:06:21 +0000 (GMT) Received: from pollux.ds.pg.gda.pl ([153.19.208.7]:30220 "EHLO pollux.ds.pg.gda.pl") by ftp.linux-mips.org with ESMTP id S20038775AbWLDMGR (ORCPT ); Mon, 4 Dec 2006 12:06:17 +0000 Received: from localhost (localhost [127.0.0.1]) by pollux.ds.pg.gda.pl (Postfix) with ESMTP id 0C293E1CB0; Mon, 4 Dec 2006 13:06:05 +0100 (CET) X-Virus-Scanned: by amavisd-new at pollux.ds.pg.gda.pl Received: from pollux.ds.pg.gda.pl ([127.0.0.1]) by localhost (pollux.ds.pg.gda.pl [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U0g2UdVkmD+K; Mon, 4 Dec 2006 13:06:04 +0100 (CET) Received: from piorun.ds.pg.gda.pl (piorun.ds.pg.gda.pl [153.19.208.8]) by pollux.ds.pg.gda.pl (Postfix) with ESMTP id A37ACE1C93; Mon, 4 Dec 2006 13:06:04 +0100 (CET) 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 kB4C6CDC023918; Mon, 4 Dec 2006 13:06:12 +0100 Date: Mon, 4 Dec 2006 12:06:08 +0000 (GMT) From: "Maciej W. Rozycki" To: Andrew Morton cc: Jeff Garzik , netdev@vger.kernel.org, linux-mips@linux-mips.org Subject: Re: [PATCH 2.6.18] declance: Support the I/O ASIC LANCE w/o TURBOchannel In-Reply-To: <20061201214626.1c50dd38.akpm@osdl.org> Message-ID: References: <45710CFE.5090007@pobox.com> <20061201214626.1c50dd38.akpm@osdl.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: ClamAV 0.88.6/2276/Mon Dec 4 09:15:27 2006 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: 13335 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, 1 Dec 2006, Andrew Morton wrote: > > can you (or Andrew) please resend your patches against 2.6.19? > > > > I have then all (I think) queued up. Will send once I've done a round > of build-testing. Thanks a lot, Andrew. Maciej From ralf@linux-mips.org Mon Dec 4 13:31:07 2006 Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 04 Dec 2006 13:31:08 +0000 (GMT) Received: from localhost.localdomain ([127.0.0.1]:31648 "EHLO dl5rb.ham-radio-op.net") by ftp.linux-mips.org with ESMTP id S20038831AbWLDNbH (ORCPT ); Mon, 4 Dec 2006 13:31:07 +0000 Received: from denk.linux-mips.net (denk.linux-mips.net [127.0.0.1]) by dl5rb.ham-radio-op.net (8.13.8/8.13.8) with ESMTP id kB4DV6dp032556; Mon, 4 Dec 2006 13:31:06 GMT Received: (from ralf@localhost) by denk.linux-mips.net (8.13.8/8.13.8/Submit) id kB4DV5D9032548; Mon, 4 Dec 2006 13:31:05 GMT Date: Mon, 4 Dec 2006 13:31:05 +0000 From: Ralf Baechle To: Mariusz Kozlowski Cc: linux-mips@linux-mips.org, Willy Tarreau Subject: Re: [2.4 PATCH] mips/mips64 mv64340 parenthesis fixes Message-ID: <20061204133105.GA30410@linux-mips.org> References: <200612041036.21953.m.kozlowski@tuxland.pl> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <200612041036.21953.m.kozlowski@tuxland.pl> User-Agent: Mutt/1.4.2.2i 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: 13336 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, Dec 04, 2006 at 10:36:21AM +0100, Mariusz Kozlowski wrote: >         This patch fixes parenthesis mv64340 stuff in both mips and mips64 code. Applied. Not that anybody case much, the broken macros were unused ... Ralf From ralf@linux-mips.org Mon Dec 4 14:10:45 2006 Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 04 Dec 2006 14:10:47 +0000 (GMT) Received: from localhost.localdomain ([127.0.0.1]:41618 "EHLO dl5rb.ham-radio-op.net") by ftp.linux-mips.org with ESMTP id S20038841AbWLDOKp (ORCPT ); Mon, 4 Dec 2006 14:10:45 +0000 Received: from denk.linux-mips.net (denk.linux-mips.net [127.0.0.1]) by dl5rb.ham-radio-op.net (8.13.8/8.13.8) with ESMTP id kB4EAip5014085; Mon, 4 Dec 2006 14:10:44 GMT Received: (from ralf@localhost) by denk.linux-mips.net (8.13.8/8.13.8/Submit) id kB4EAgiV014054; Mon, 4 Dec 2006 14:10:42 GMT Date: Mon, 4 Dec 2006 14:10:42 +0000 From: Ralf Baechle To: Yoichi Yuasa Cc: linux-mips Subject: Re: [PATCH 1/5] MIPS: fix cobalt I/O resource range Message-ID: <20061204141042.GA7231@linux-mips.org> References: <20061201221242.261f57b0.yoichi_yuasa@tripeaks.co.jp> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20061201221242.261f57b0.yoichi_yuasa@tripeaks.co.jp> User-Agent: Mutt/1.4.2.2i 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: 13337 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 Fri, Dec 01, 2006 at 10:12:42PM +0900, Yoichi Yuasa wrote: > This patch has fixed cobalt I/O reource range. > The cobalt real I/O resource range from 0x0 to 0xffff. > > Yoichi > > Signed-off-by: Yoichi Yuasa > > 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 2006-10-12 01:03:18.055569000 +0900 > +++ mips/arch/mips/cobalt/setup.c 2006-10-12 01:01:59.973744750 +0900 > @@ -130,8 +130,7 @@ void __init plat_mem_setup(void) > > set_io_port_base(CKSEG1ADDR(GT_DEF_PCI0_IO_BASE)); > > - /* I/O port resource must include UART and LCD/buttons */ > - ioport_resource.end = 0x0fffffff; > + ioport_resource.end = 0xffff; This is actually the default, so the code can go and anyway then the code stops making sense, too. Ralf From ralf@linux-mips.org Mon Dec 4 14:12:58 2006 Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 04 Dec 2006 14:12:59 +0000 (GMT) Received: from localhost.localdomain ([127.0.0.1]:2452 "EHLO dl5rb.ham-radio-op.net") by ftp.linux-mips.org with ESMTP id S20038843AbWLDOM6 (ORCPT ); Mon, 4 Dec 2006 14:12:58 +0000 Received: from denk.linux-mips.net (denk.linux-mips.net [127.0.0.1]) by dl5rb.ham-radio-op.net (8.13.8/8.13.8) with ESMTP id kB4ECwIN015070; Mon, 4 Dec 2006 14:12:58 GMT Received: (from ralf@localhost) by denk.linux-mips.net (8.13.8/8.13.8/Submit) id kB4ECwIu015069; Mon, 4 Dec 2006 14:12:58 GMT Date: Mon, 4 Dec 2006 14:12:58 +0000 From: Ralf Baechle To: Yoichi Yuasa Cc: linux-mips Subject: Re: [PATCH 2/5] MIPS: remove unused resources for cobalt Message-ID: <20061204141258.GB7231@linux-mips.org> References: <20061201221242.261f57b0.yoichi_yuasa@tripeaks.co.jp> <20061201221601.3aa34024.yoichi_yuasa@tripeaks.co.jp> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20061201221601.3aa34024.yoichi_yuasa@tripeaks.co.jp> User-Agent: Mutt/1.4.2.2i 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: 13338 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 Fri, Dec 01, 2006 at 10:16:01PM +0900, Yoichi Yuasa wrote: > This patch has removed unused resources for cobalt. The VIA PCI-to-ISA bridge used in Cobalts contains the DMA controller, so these resources should be reserved even though nothing is actually using them. Ralf From ralf@linux-mips.org Mon Dec 4 14:13:22 2006 Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 04 Dec 2006 14:13:25 +0000 (GMT) Received: from localhost.localdomain ([127.0.0.1]:3732 "EHLO dl5rb.ham-radio-op.net") by ftp.linux-mips.org with ESMTP id S20038848AbWLDONV (ORCPT ); Mon, 4 Dec 2006 14:13:21 +0000 Received: from denk.linux-mips.net (denk.linux-mips.net [127.0.0.1]) by dl5rb.ham-radio-op.net (8.13.8/8.13.8) with ESMTP id kB4EDMGM015266; Mon, 4 Dec 2006 14:13:22 GMT Received: (from ralf@localhost) by denk.linux-mips.net (8.13.8/8.13.8/Submit) id kB4EDLnq015265; Mon, 4 Dec 2006 14:13:21 GMT Date: Mon, 4 Dec 2006 14:13:21 +0000 From: Ralf Baechle To: Yoichi Yuasa Cc: linux-mips Subject: Re: [PATCH 3/5] MIPS: separate cobalt PCI codes from setup.c Message-ID: <20061204141321.GC7231@linux-mips.org> References: <20061201221242.261f57b0.yoichi_yuasa@tripeaks.co.jp> <20061201221601.3aa34024.yoichi_yuasa@tripeaks.co.jp> <20061201221746.1f45d98c.yoichi_yuasa@tripeaks.co.jp> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20061201221746.1f45d98c.yoichi_yuasa@tripeaks.co.jp> User-Agent: Mutt/1.4.2.2i 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: 13339 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 Fri, Dec 01, 2006 at 10:17:46PM +0900, Yoichi Yuasa wrote: > This patch has separated cobalt PCI codes from setup.c . > It's removed #ifdef CONFIG_PCI/#endif from cobalt setup.c . Looks good. Ralf From afleming@freescale.com Mon Dec 4 19:55:01 2006 Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 04 Dec 2006 19:55:05 +0000 (GMT) Received: from az33egw01.freescale.net ([192.88.158.102]:39871 "EHLO az33egw01.freescale.net") by ftp.linux-mips.org with ESMTP id S20038907AbWLDTzB (ORCPT ); Mon, 4 Dec 2006 19:55:01 +0000 Received: from az33smr01.freescale.net (az33smr01.freescale.net [10.64.34.199]) by az33egw01.freescale.net (8.12.11/az33egw01) with ESMTP id kB4JspL1005635; Mon, 4 Dec 2006 12:54:51 -0700 (MST) Received: from [10.82.17.56] ([10.82.17.56]) by az33smr01.freescale.net (8.13.1/8.13.0) with ESMTP id kB4Jsnjp027934; Mon, 4 Dec 2006 13:54:49 -0600 (CST) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Cc: Andrew Morton , Jeff Garzik , Ralf Baechle , netdev@vger.kernel.org, linux-mips@linux-mips.org Content-Transfer-Encoding: 7bit From: Andy Fleming Subject: Re: [patch 3/6] 2.6.18: sb1250-mac: Phylib IRQ handling fixes Date: Mon, 4 Dec 2006 13:54:45 -0600 To: "Maciej W. Rozycki" X-Mailer: Apple Mail (2.752.2) 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: 13340 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: afleming@freescale.com Precedence: bulk X-list: linux-mips On Nov 30, 2006, at 12:07, Maciej W. Rozycki wrote: > On Mon, 23 Oct 2006, Maciej W. Rozycki wrote: > >>> I'm not too enthusiastic about requiring the ethernet drivers to >>> call >>> phy_disconnect in a separate thread after "close" is called. >>> Assuming there's >>> not some sort of "squash work queue" function that can be invoked >>> with >>> rtnl_lock held, I think phy_disconnect should schedule itself to >>> flush the >>> queue. This would also require that mdiobus_unregister hold off >>> on freeing >>> phydevs if any of the phys were still waiting for pending >>> flush_pending calls >>> to finish. Which would, in turn, require mdiobus_unregister to >>> schedule >>> cleaning up memory for some later time. >> >> This could work, indeed. >> >>> I'm not enthusiastic about that implementation, either, but it >>> maintains the >>> abstractions I consider important for this code. The ethernet >>> driver should >>> not need to know what structures the PHY lib uses to implement >>> its interrupt >>> handling, and how to work around their failings, IMHO. >> >> Agreed. > > So what's the plan? > > Here's a new version of the patch that addresses your other concerns. So I think the problem is we still don't understand the problem, and the solution to the problem, except that it's causing your driver to lock up. Most of the changes below are fine with me. The confusing one is still the check for current_is_keventd(). This is related in some way to why the driver code invokes phy_disconnect from a work_queue. I admit, though, I'm not familiar enough with the work queue infrastructure to understand the problem. But I'm very certain that creating a work queue for the sole purpose of disconnecting from the PHY is crufty. Can you try again to convey how this solves your problem, so we can try to figure out if there's a better way? Andy From hewei.fu@siemens.com Tue Dec 5 03:41:34 2006 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 05 Dec 2006 03:41:39 +0000 (GMT) Received: from david.siemens.com.cn ([194.138.202.53]:48004 "EHLO david.siemens.com.cn") by ftp.linux-mips.org with ESMTP id S20038965AbWLEDle convert rfc822-to-8bit (ORCPT ); Tue, 5 Dec 2006 03:41:34 +0000 Received: from ns.siemens.com.cn (ns.siemens.com.cn [194.138.237.52]) by david.siemens.com.cn (8.11.7/8.11.7) with ESMTP id kB53fGJ14244; Tue, 5 Dec 2006 11:41:20 +0800 (CST) Received: from pekw905a.cn001.siemens.net (localhost [127.0.0.1]) by ns.siemens.com.cn (8.11.7/8.11.7) with ESMTP id kB53fF115993; Tue, 5 Dec 2006 11:41:15 +0800 (CST) Received: from PEKW934A.cn001.siemens.net ([139.24.236.66]) by pekw905a.cn001.siemens.net with Microsoft SMTPSVC(6.0.3790.1830); Tue, 5 Dec 2006 11:41:14 +0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 8BIT Subject: RE: The difference between mips*-gnu and mips*-linux when configure tool-chain Date: Tue, 5 Dec 2006 11:41:12 +0800 Message-ID: <96E7D5519FC3D741BEE27AB88C7387970167840A@PEKW934A.cn001.siemens.net> In-Reply-To: <20061203170514.GA11258@nevyn.them.org> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: The difference between mips*-gnu and mips*-linux when configure tool-chain Thread-Index: AccW/Tvw9HWJ0gXfS7mWzjp4UM2UyABE0/pQ From: "Fu, He Wei PSE NKG" To: "Daniel Jacobowitz" Cc: X-OriginalArrivalTime: 05 Dec 2006 03:41:14.0170 (UTC) FILETIME=[368E59A0:01C7181F] 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: 13341 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: hewei.fu@siemens.com Precedence: bulk X-list: linux-mips Thanks, sorry for I missed the mips*-elf for mips*-gnu. I think that for ld,the difference between mips*-elf and mips*-linux produces only some minor impact on the default ld script, for the behavior of ld itself, it has not serious impact.Is it my understanding correct? But for bfd, does the difference of these two config-choice have impact on the behavior of two different bfd-target? . -----Original Message----- From: Daniel Jacobowitz [mailto:dan@debian.org] Sent: Monday, December 04, 2006 1:05 AM To: Fu, He Wei PSE NKG Cc: linux-mips@linux-mips.org Subject: Re: The difference between mips*-gnu and mips*-linux when configure tool-chain On Sun, Dec 03, 2006 at 05:15:07PM +0800, Fu, He Wei PSE NKG wrote: > Hello everyone.At the time of building tool-chain for mips machine,we > can choose mips*-gnu or mips*-linux, I want to know what's the > difference between them? The original idea is that mips*-gnu for > developing firmware which has not OS-surport, and mips*-linux for > developing software on Linux, but it is not suitable for firmware such > as bootloaders.But now I think I'm not right,it seems that configure > with mips*-linux suit for both linux and bootloader, and configure with > mips*-gnu means build for OS such as IRIX surport, I'm not very > clearly,can anybody help me figour out the difference between them? mips-gnu is the GNU system (the Hurd kernel). mips-linux is used for the kernel and userspace of a Linux system. mips-elf is used for bare metal targets without an OS. You should be able to build a Linux bootloader using a mips-linux compiler. -- Daniel Jacobowitz CodeSourcery From vagabon.xyz@gmail.com Tue Dec 5 09:38:41 2006 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 05 Dec 2006 09:38:46 +0000 (GMT) Received: from nf-out-0910.google.com ([64.233.182.190]:36120 "EHLO nf-out-0910.google.com") by ftp.linux-mips.org with ESMTP id S20038971AbWLEJil (ORCPT ); Tue, 5 Dec 2006 09:38:41 +0000 Received: by nf-out-0910.google.com with SMTP id l24so156791nfc for ; Tue, 05 Dec 2006 01:38:41 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:reply-to:user-agent:mime-version:to:cc:subject:content-type:content-transfer-encoding:from; b=kVRJ7whDkyr7ggJYQqNIeUWQ/s9L7o24yNLvHqwd0kshIuqBSKCSMQvQeZYQyDILLnpIN/AYj0uC2UaxMmo2fm4p+sIDELTl+ukqDFf5q16w5vhXTDHHnwBE3ZYVv6lWM9Kb4MV/PrFmxybkGMocDmJBjW2Sytc2tQS9ySFSeVI= Received: by 10.49.57.14 with SMTP id j14mr585706nfk.1165311520956; Tue, 05 Dec 2006 01:38:40 -0800 (PST) Received: from ?192.168.0.24? ( [81.252.61.1]) by mx.google.com with ESMTP id d2sm1948705nfe.2006.12.05.01.38.40; Tue, 05 Dec 2006 01:38:40 -0800 (PST) Message-ID: <45753E6C.1030702@innova-card.com> Date: Tue, 05 Dec 2006 10:39:56 +0100 Reply-To: Franck User-Agent: Thunderbird 1.5.0.4 (X11/20060614) MIME-Version: 1.0 To: Ralf Baechle CC: linux-mips Subject: [PATCH] pte_offset(dir,addr): parenthesis fix Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit From: Franck Bui-Huu 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: 13342 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 From: Franck Bui-Huu This patch adds missing parenthesis around 'dir' argument in pte_offset() macro definition. It also removes an extra space in the definition of pte_offset_kernel() macro. Signed-off-by: Franck Bui-Huu --- Hi Ralf, Could you apply this trivial patch ? include/asm-mips/pgtable-32.h | 6 +++--- include/asm-mips/pgtable-64.h | 4 ++-- 2 files changed, 5 insertions(+), 5 deletions(-) diff --git a/include/asm-mips/pgtable-32.h b/include/asm-mips/pgtable-32.h index d20f2e9..2fbd47e 100644 --- a/include/asm-mips/pgtable-32.h +++ b/include/asm-mips/pgtable-32.h @@ -156,9 +156,9 @@ pfn_pte(unsigned long pfn, pgprot_t prot #define __pte_offset(address) \ (((address) >> PAGE_SHIFT) & (PTRS_PER_PTE - 1)) #define pte_offset(dir, address) \ - ((pte_t *) (pmd_page_vaddr(*dir)) + __pte_offset(address)) -#define pte_offset_kernel(dir, address) \ - ((pte_t *) pmd_page_vaddr(*(dir)) + __pte_offset(address)) + ((pte_t *) pmd_page_vaddr(*(dir)) + __pte_offset(address)) +#define pte_offset_kernel(dir, address) \ + ((pte_t *) pmd_page_vaddr(*(dir)) + __pte_offset(address)) #define pte_offset_map(dir, address) \ ((pte_t *)page_address(pmd_page(*(dir))) + __pte_offset(address)) diff --git a/include/asm-mips/pgtable-64.h b/include/asm-mips/pgtable-64.h index b9b1e86..a5b1871 100644 --- a/include/asm-mips/pgtable-64.h +++ b/include/asm-mips/pgtable-64.h @@ -212,9 +212,9 @@ static inline pmd_t *pmd_offset(pud_t * #define __pte_offset(address) \ (((address) >> PAGE_SHIFT) & (PTRS_PER_PTE - 1)) #define pte_offset(dir, address) \ - ((pte_t *) (pmd_page_vaddr(*dir)) + __pte_offset(address)) + ((pte_t *) pmd_page_vaddr(*(dir)) + __pte_offset(address)) #define pte_offset_kernel(dir, address) \ - ((pte_t *) pmd_page_vaddr(*(dir)) + __pte_offset(address)) + ((pte_t *) pmd_page_vaddr(*(dir)) + __pte_offset(address)) #define pte_offset_map(dir, address) \ ((pte_t *)page_address(pmd_page(*(dir))) + __pte_offset(address)) #define pte_offset_map_nested(dir, address) \ -- 1.4.4.1 From ths@networkno.de Tue Dec 5 12:43:30 2006 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 05 Dec 2006 12:43:35 +0000 (GMT) Received: from phoenix.bawue.net ([193.7.176.60]:32943 "EHLO mail.bawue.net") by ftp.linux-mips.org with ESMTP id S20038987AbWLEMna (ORCPT ); Tue, 5 Dec 2006 12:43:30 +0000 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 C2AE1B908A; Tue, 5 Dec 2006 13:45:46 +0100 (CET) Received: from ths by lagash with local (Exim 4.63) (envelope-from ) id 1GrZeO-0001sx-1q; Tue, 05 Dec 2006 12:43:56 +0000 Date: Tue, 5 Dec 2006 12:43:56 +0000 To: "Fu, He Wei PSE NKG" Cc: Daniel Jacobowitz , linux-mips@linux-mips.org Subject: Re: The difference between mips*-gnu and mips*-linux when configure tool-chain Message-ID: <20061205124355.GB26046@networkno.de> References: <20061203170514.GA11258@nevyn.them.org> <96E7D5519FC3D741BEE27AB88C7387970167840A@PEKW934A.cn001.siemens.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <96E7D5519FC3D741BEE27AB88C7387970167840A@PEKW934A.cn001.siemens.net> User-Agent: Mutt/1.5.13 (2006-08-11) From: Thiemo Seufer 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: 13343 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 Fu, He Wei PSE NKG wrote: > Thanks, sorry for I missed the mips*-elf for mips*-gnu. > > I think that for ld,the difference between mips*-elf and mips*-linux > produces only some minor impact on the default ld script, for the > behavior of ld itself, it has not serious impact.Is it my understanding > correct? > > But for bfd, does the difference of these two config-choice have impact > on the behavior of two different bfd-target? . For both cases the resulting object file layout is different. mips*-elf uses SGI-style, mips*-linux uses "traditional" style. I expect the "traditional" format to get better long-term maintenance. For a stand-alone bootloader both do for now, but I would prefer mips*-linux since it eliminates the need for one extra compiler when building a Linux environment. Thiemo From anemo@mba.ocn.ne.jp Tue Dec 5 16:21:03 2006 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 05 Dec 2006 16:21:09 +0000 (GMT) Received: from mba.ocn.ne.jp ([210.190.142.172]:24526 "HELO smtp.mba.ocn.ne.jp") by ftp.linux-mips.org with SMTP id S20039016AbWLEQVD (ORCPT ); Tue, 5 Dec 2006 16:21:03 +0000 Received: from localhost (p2151-ipad26funabasi.chiba.ocn.ne.jp [220.104.88.151]) by smtp.mba.ocn.ne.jp (Postfix) with ESMTP id 075D2BB5B; Wed, 6 Dec 2006 01:20:58 +0900 (JST) Date: Wed, 06 Dec 2006 01:20:57 +0900 (JST) Message-Id: <20061206.012057.119272708.anemo@mba.ocn.ne.jp> To: linux-mips@linux-mips.org Cc: ralf@linux-mips.org Subject: [PATCH] genirq: use name instead of typename From: Atsushi Nemoto 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 3.3 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: 13344 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 The "typename" field was obsoleted by the "name" field. Signed-off-by: Atsushi Nemoto --- diff --git a/arch/mips/kernel/irq.c b/arch/mips/kernel/irq.c index b339798..2fe4c86 100644 --- a/arch/mips/kernel/irq.c +++ b/arch/mips/kernel/irq.c @@ -117,7 +117,7 @@ #else for_each_online_cpu(j) seq_printf(p, "%10u ", kstat_cpu(j).irqs[i]); #endif - seq_printf(p, " %14s", irq_desc[i].chip->typename); + seq_printf(p, " %14s", irq_desc[i].chip->name); seq_printf(p, " %s", action->name); for (action=action->next; action; action = action->next) From anemo@mba.ocn.ne.jp Tue Dec 5 16:23:16 2006 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 05 Dec 2006 16:23:21 +0000 (GMT) Received: from mba.ocn.ne.jp ([210.190.142.172]:56810 "HELO smtp.mba.ocn.ne.jp") by ftp.linux-mips.org with SMTP id S20039016AbWLEQXQ (ORCPT ); Tue, 5 Dec 2006 16:23:16 +0000 Received: from localhost (p2151-ipad26funabasi.chiba.ocn.ne.jp [220.104.88.151]) by smtp.mba.ocn.ne.jp (Postfix) with ESMTP id 0C36CBB25; Wed, 6 Dec 2006 01:23:12 +0900 (JST) Date: Wed, 06 Dec 2006 01:23:11 +0900 (JST) Message-Id: <20061206.012311.86891097.anemo@mba.ocn.ne.jp> To: linux-mips@linux-mips.org Cc: ralf@linux-mips.org Subject: [PATCH] Import updates from i386's i8259.c From: Atsushi Nemoto 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 3.3 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: 13345 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 Import many updates from i386's i8259.c, especially genirq transitions. Signed-off-by: Atsushi Nemoto --- arch/mips/kernel/i8259.c | 195 ++++++++++++++++++++++--------------- include/asm-mips/i8259.h | 33 ++++-- 2 files changed, 142 insertions(+), 86 deletions(-) diff --git a/arch/mips/kernel/i8259.c b/arch/mips/kernel/i8259.c index 2526c0c..1a1d754 100644 --- a/arch/mips/kernel/i8259.c +++ b/arch/mips/kernel/i8259.c @@ -19,9 +19,6 @@ #include #include #include -void enable_8259A_irq(unsigned int irq); -void disable_8259A_irq(unsigned int irq); - /* * This is the 'legacy' 8259A Programmable Interrupt Controller, * present in the majority of PC/AT boxes. @@ -31,23 +28,16 @@ void disable_8259A_irq(unsigned int irq) * moves to arch independent land */ +static int i8259A_auto_eoi; DEFINE_SPINLOCK(i8259A_lock); - -static void end_8259A_irq (unsigned int irq) -{ - if (!(irq_desc[irq].status & (IRQ_DISABLED|IRQ_INPROGRESS)) && - irq_desc[irq].action) - enable_8259A_irq(irq); -} - +/* some platforms call this... */ void mask_and_ack_8259A(unsigned int); -static struct irq_chip i8259A_irq_type = { - .typename = "XT-PIC", - .enable = enable_8259A_irq, - .disable = disable_8259A_irq, - .ack = mask_and_ack_8259A, - .end = end_8259A_irq, +static struct irq_chip i8259A_chip = { + .name = "XT-PIC", + .mask = disable_8259A_irq, + .unmask = enable_8259A_irq, + .mask_ack = mask_and_ack_8259A, }; /* @@ -59,8 +49,8 @@ static struct irq_chip i8259A_irq_type = */ static unsigned int cached_irq_mask = 0xffff; -#define cached_21 (cached_irq_mask) -#define cached_A1 (cached_irq_mask >> 8) +#define cached_master_mask (cached_irq_mask) +#define cached_slave_mask (cached_irq_mask >> 8) void disable_8259A_irq(unsigned int irq) { @@ -70,9 +60,9 @@ void disable_8259A_irq(unsigned int irq) spin_lock_irqsave(&i8259A_lock, flags); cached_irq_mask |= mask; if (irq & 8) - outb(cached_A1,0xA1); + outb(cached_slave_mask, PIC_SLAVE_IMR); else - outb(cached_21,0x21); + outb(cached_master_mask, PIC_MASTER_IMR); spin_unlock_irqrestore(&i8259A_lock, flags); } @@ -84,23 +74,23 @@ void enable_8259A_irq(unsigned int irq) spin_lock_irqsave(&i8259A_lock, flags); cached_irq_mask &= mask; if (irq & 8) - outb(cached_A1,0xA1); + outb(cached_slave_mask, PIC_SLAVE_IMR); else - outb(cached_21,0x21); + outb(cached_master_mask, PIC_MASTER_IMR); spin_unlock_irqrestore(&i8259A_lock, flags); } int i8259A_irq_pending(unsigned int irq) { - unsigned int mask = 1 << irq; + unsigned int mask = 1<> 8); + ret = inb(PIC_SLAVE_CMD) & (mask >> 8); spin_unlock_irqrestore(&i8259A_lock, flags); return ret; @@ -109,7 +99,8 @@ int i8259A_irq_pending(unsigned int irq) void make_8259A_irq(unsigned int irq) { disable_irq_nosync(irq); - set_irq_chip(irq, &i8259A_irq_type); + set_irq_chip_and_handler_name(irq, &i8259A_chip, handle_level_irq, + "XT"); enable_irq(irq); } @@ -122,17 +113,17 @@ void make_8259A_irq(unsigned int irq) static inline int i8259A_irq_real(unsigned int irq) { int value; - int irqmask = 1 << irq; + int irqmask = 1<> 8); - outb(0x0A,0xA0); /* back to the IRR register */ + outb(0x0B,PIC_SLAVE_CMD); /* ISR register */ + value = inb(PIC_SLAVE_CMD) & (irqmask >> 8); + outb(0x0A,PIC_SLAVE_CMD); /* back to the IRR register */ return value; } @@ -149,17 +140,19 @@ void mask_and_ack_8259A(unsigned int irq spin_lock_irqsave(&i8259A_lock, flags); /* - * Lightweight spurious IRQ detection. We do not want to overdo - * spurious IRQ handling - it's usually a sign of hardware problems, so - * we only do the checks we can do without slowing down good hardware - * nnecesserily. + * Lightweight spurious IRQ detection. We do not want + * to overdo spurious IRQ handling - it's usually a sign + * of hardware problems, so we only do the checks we can + * do without slowing down good hardware unnecessarily. * - * Note that IRQ7 and IRQ15 (the two spurious IRQs usually resulting - * rom the 8259A-1|2 PICs) occur even if the IRQ is masked in the 8259A. - * Thus we can check spurious 8259A IRQs without doing the quite slow - * i8259A_irq_real() call for every IRQ. This does not cover 100% of - * spurious interrupts, but should be enough to warn the user that - * there is something bad going on ... + * Note that IRQ7 and IRQ15 (the two spurious IRQs + * usually resulting from the 8259A-1|2 PICs) occur + * even if the IRQ is masked in the 8259A. Thus we + * can check spurious 8259A IRQs without doing the + * quite slow i8259A_irq_real() call for every IRQ. + * This does not cover 100% of spurious interrupts, + * but should be enough to warn the user that there + * is something bad going on ... */ if (cached_irq_mask & irqmask) goto spurious_8259A_irq; @@ -167,14 +160,14 @@ void mask_and_ack_8259A(unsigned int irq handle_real_irq: if (irq & 8) { - inb(0xA1); /* DUMMY - (do we need this?) */ - outb(cached_A1,0xA1); - outb(0x60+(irq&7),0xA0);/* 'Specific EOI' to slave */ - outb(0x62,0x20); /* 'Specific EOI' to master-IRQ2 */ + inb(PIC_SLAVE_IMR); /* DUMMY - (do we need this?) */ + outb(cached_slave_mask, PIC_SLAVE_IMR); + outb(0x60+(irq&7),PIC_SLAVE_CMD);/* 'Specific EOI' to slave */ + outb(0x60+PIC_CASCADE_IR,PIC_MASTER_CMD); /* 'Specific EOI' to master-IRQ2 */ } else { - inb(0x21); /* DUMMY - (do we need this?) */ - outb(cached_21,0x21); - outb(0x60+irq,0x20); /* 'Specific EOI' to master */ + inb(PIC_MASTER_IMR); /* DUMMY - (do we need this?) */ + outb(cached_master_mask, PIC_MASTER_IMR); + outb(0x60+irq,PIC_MASTER_CMD); /* 'Specific EOI to master */ } #ifdef CONFIG_MIPS_MT_SMTC if (irq_hwmask[irq] & ST0_IM) @@ -195,7 +188,7 @@ spurious_8259A_irq: goto handle_real_irq; { - static int spurious_irq_mask = 0; + static int spurious_irq_mask; /* * At this point we can be sure the IRQ is spurious, * lets ACK and report it. [once per IRQ] @@ -214,15 +207,52 @@ spurious_8259A_irq: } } +static char irq_trigger[2]; +/** + * ELCR registers (0x4d0, 0x4d1) control edge/level of IRQ + */ +static void restore_ELCR(char *trigger) +{ + outb(trigger[0], 0x4d0); + outb(trigger[1], 0x4d1); +} + +static void save_ELCR(char *trigger) +{ + /* IRQ 0,1,2,8,13 are marked as reserved */ + trigger[0] = inb(0x4d0) & 0xF8; + trigger[1] = inb(0x4d1) & 0xDE; +} + static int i8259A_resume(struct sys_device *dev) { - init_8259A(0); + init_8259A(i8259A_auto_eoi); + restore_ELCR(irq_trigger); + return 0; +} + +static int i8259A_suspend(struct sys_device *dev, pm_message_t state) +{ + save_ELCR(irq_trigger); + return 0; +} + +static int i8259A_shutdown(struct sys_device *dev) +{ + /* Put the i8259A into a quiescent state that + * the kernel initialization code can get it + * out of. + */ + outb(0xff, PIC_MASTER_IMR); /* mask all of 8259A-1 */ + outb(0xff, PIC_SLAVE_IMR); /* mask all of 8259A-1 */ return 0; } static struct sysdev_class i8259_sysdev_class = { set_kset_name("i8259"), + .suspend = i8259A_suspend, .resume = i8259A_resume, + .shutdown = i8259A_shutdown, }; static struct sys_device device_i8259A = { @@ -240,45 +270,45 @@ static int __init i8259A_init_sysfs(void device_initcall(i8259A_init_sysfs); -void __init init_8259A(int auto_eoi) +void init_8259A(int auto_eoi) { unsigned long flags; + i8259A_auto_eoi = auto_eoi; + spin_lock_irqsave(&i8259A_lock, flags); - outb(0xff, 0x21); /* mask all of 8259A-1 */ - outb(0xff, 0xA1); /* mask all of 8259A-2 */ + outb(0xff, PIC_MASTER_IMR); /* mask all of 8259A-1 */ + outb(0xff, PIC_SLAVE_IMR); /* mask all of 8259A-2 */ /* * outb_p - this has to work on a wide range of PC hardware. */ - outb_p(0x11, 0x20); /* ICW1: select 8259A-1 init */ - outb_p(0x00, 0x21); /* ICW2: 8259A-1 IR0-7 mapped to 0x00-0x07 */ - outb_p(0x04, 0x21); /* 8259A-1 (the master) has a slave on IR2 */ - if (auto_eoi) - outb_p(0x03, 0x21); /* master does Auto EOI */ - else - outb_p(0x01, 0x21); /* master expects normal EOI */ - - outb_p(0x11, 0xA0); /* ICW1: select 8259A-2 init */ - outb_p(0x08, 0xA1); /* ICW2: 8259A-2 IR0-7 mapped to 0x08-0x0f */ - outb_p(0x02, 0xA1); /* 8259A-2 is a slave on master's IR2 */ - outb_p(0x01, 0xA1); /* (slave's support for AEOI in flat mode - is to be investigated) */ - + outb_p(0x11, PIC_MASTER_CMD); /* ICW1: select 8259A-1 init */ + outb_p(0x20 + 0, PIC_MASTER_IMR); /* ICW2: 8259A-1 IR0-7 mapped to 0x20-0x27 */ + outb_p(1U << PIC_CASCADE_IR, PIC_MASTER_IMR); /* 8259A-1 (the master) has a slave on IR2 */ + if (auto_eoi) /* master does Auto EOI */ + outb_p(MASTER_ICW4_DEFAULT | PIC_ICW4_AEOI, PIC_MASTER_IMR); + else /* master expects normal EOI */ + outb_p(MASTER_ICW4_DEFAULT, PIC_MASTER_IMR); + + outb_p(0x11, PIC_SLAVE_CMD); /* ICW1: select 8259A-2 init */ + outb_p(0x20 + 8, PIC_SLAVE_IMR); /* ICW2: 8259A-2 IR0-7 mapped to 0x28-0x2f */ + outb_p(PIC_CASCADE_IR, PIC_SLAVE_IMR); /* 8259A-2 is a slave on master's IR2 */ + outb_p(SLAVE_ICW4_DEFAULT, PIC_SLAVE_IMR); /* (slave's support for AEOI in flat mode is to be investigated) */ if (auto_eoi) /* - * in AEOI mode we just have to mask the interrupt + * In AEOI mode we just have to mask the interrupt * when acking. */ - i8259A_irq_type.ack = disable_8259A_irq; + i8259A_chip.mask_ack = disable_8259A_irq; else - i8259A_irq_type.ack = mask_and_ack_8259A; + i8259A_chip.mask_ack = mask_and_ack_8259A; udelay(100); /* wait for 8259A to initialize */ - outb(cached_21, 0x21); /* restore master IRQ mask */ - outb(cached_A1, 0xA1); /* restore slave IRQ mask */ + outb(cached_master_mask, PIC_MASTER_IMR); /* restore master IRQ mask */ + outb(cached_slave_mask, PIC_SLAVE_IMR); /* restore slave IRQ mask */ spin_unlock_irqrestore(&i8259A_lock, flags); } @@ -291,11 +321,17 @@ static struct irqaction irq2 = { }; static struct resource pic1_io_resource = { - .name = "pic1", .start = 0x20, .end = 0x21, .flags = IORESOURCE_BUSY + .name = "pic1", + .start = PIC_MASTER_CMD, + .end = PIC_MASTER_IMR, + .flags = IORESOURCE_BUSY }; static struct resource pic2_io_resource = { - .name = "pic2", .start = 0xa0, .end = 0xa1, .flags = IORESOURCE_BUSY + .name = "pic2", + .start = PIC_SLAVE_CMD, + .end = PIC_SLAVE_IMR, + .flags = IORESOURCE_BUSY }; /* @@ -313,7 +349,8 @@ void __init init_i8259_irqs (void) init_8259A(0); for (i = 0; i < 16; i++) - set_irq_chip(i, &i8259A_irq_type); + set_irq_chip_and_handler_name(i, &i8259A_chip, + handle_level_irq, "XT"); - setup_irq(2, &irq2); + setup_irq(PIC_CASCADE_IR, &irq2); } diff --git a/include/asm-mips/i8259.h b/include/asm-mips/i8259.h index 0214abe..2a10383 100644 --- a/include/asm-mips/i8259.h +++ b/include/asm-mips/i8259.h @@ -19,8 +19,27 @@ #include #include +/* i8259A PIC registers */ +#define PIC_MASTER_CMD 0x20 +#define PIC_MASTER_IMR 0x21 +#define PIC_MASTER_ISR PIC_MASTER_CMD +#define PIC_MASTER_POLL PIC_MASTER_ISR +#define PIC_MASTER_OCW3 PIC_MASTER_ISR +#define PIC_SLAVE_CMD 0xa0 +#define PIC_SLAVE_IMR 0xa1 + +/* i8259A PIC related value */ +#define PIC_CASCADE_IR 2 +#define MASTER_ICW4_DEFAULT 0x01 +#define SLAVE_ICW4_DEFAULT 0x01 +#define PIC_ICW4_AEOI 2 + extern spinlock_t i8259A_lock; +extern void init_8259A(int auto_eoi); +extern void enable_8259A_irq(unsigned int irq); +extern void disable_8259A_irq(unsigned int irq); + extern void init_i8259_irqs(void); /* @@ -35,15 +54,15 @@ static inline int i8259_irq(void) spin_lock(&i8259A_lock); /* Perform an interrupt acknowledge cycle on controller 1. */ - outb(0x0C, 0x20); /* prepare for poll */ - irq = inb(0x20) & 7; - if (irq == 2) { + outb(0x0C, PIC_MASTER_CMD); /* prepare for poll */ + irq = inb(PIC_MASTER_CMD) & 7; + if (irq == PIC_CASCADE_IR) { /* * Interrupt is cascaded so perform interrupt * acknowledge on controller 2. */ - outb(0x0C, 0xA0); /* prepare for poll */ - irq = (inb(0xA0) & 7) + 8; + outb(0x0C, PIC_SLAVE_CMD); /* prepare for poll */ + irq = (inb(PIC_SLAVE_CMD) & 7) + 8; } if (unlikely(irq == 7)) { @@ -54,8 +73,8 @@ static inline int i8259_irq(void) * significant bit is not set then there is no valid * interrupt. */ - outb(0x0B, 0x20); /* ISR register */ - if(~inb(0x20) & 0x80) + outb(0x0B, PIC_MASTER_ISR); /* ISR register */ + if(~inb(PIC_MASTER_ISR) & 0x80) irq = -1; } From vagabon.xyz@gmail.com Tue Dec 5 16:49:25 2006 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 05 Dec 2006 16:49:30 +0000 (GMT) Received: from nf-out-0910.google.com ([64.233.182.186]:36568 "EHLO nf-out-0910.google.com") by ftp.linux-mips.org with ESMTP id S20039036AbWLEQtZ (ORCPT ); Tue, 5 Dec 2006 16:49:25 +0000 Received: by nf-out-0910.google.com with SMTP id l24so254514nfc for ; Tue, 05 Dec 2006 08:49:24 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:reply-to:user-agent:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding:from; b=MHjwOS5xmx0+2Q5BiLQJ4/3WyHCpCtblsgWp7kEQLXUVXthKenvQGr1iAPWI3h29FIeiI0QO9vpgEeonQ+pnukzWAsZECX5C7aaenSEyQP5VMWwvQPlJvt6DanTDE/ScPAdC77pdSLqqLhGvidnzoueU7t8M+V2x9yP4+VqD3OI= Received: by 10.49.92.18 with SMTP id u18mr1088153nfl.1165337364565; Tue, 05 Dec 2006 08:49:24 -0800 (PST) Received: from ?192.168.0.24? ( [81.252.61.1]) by mx.google.com with ESMTP id p43sm3280147nfa.2006.12.05.08.49.22; Tue, 05 Dec 2006 08:49:23 -0800 (PST) Message-ID: <4575A364.1010703@innova-card.com> Date: Tue, 05 Dec 2006 17:50:44 +0100 Reply-To: Franck User-Agent: Thunderbird 1.5.0.4 (X11/20060614) MIME-Version: 1.0 To: Atsushi Nemoto CC: linux-mips@linux-mips.org, ralf@linux-mips.org Subject: Re: [PATCH] Import updates from i386's i8259.c References: <20061206.012311.86891097.anemo@mba.ocn.ne.jp> In-Reply-To: <20061206.012311.86891097.anemo@mba.ocn.ne.jp> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit From: Franck Bui-Huu 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: 13346 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, Atsushi Nemoto wrote: > Import many updates from i386's i8259.c, especially genirq > transitions. > Does your patch make the following patch out of date (I sent it to the list 4 days ago) ? [PATCH] Compile __do_IRQ() when really needed [take #3] Franck From ralf@linux-mips.org Tue Dec 5 16:52:56 2006 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 05 Dec 2006 16:52:58 +0000 (GMT) Received: from localhost.localdomain ([127.0.0.1]:37092 "EHLO dl5rb.ham-radio-op.net") by ftp.linux-mips.org with ESMTP id S20039028AbWLEQw4 (ORCPT ); Tue, 5 Dec 2006 16:52:56 +0000 Received: from denk.linux-mips.net (denk.linux-mips.net [127.0.0.1]) by dl5rb.ham-radio-op.net (8.13.8/8.13.8) with ESMTP id kB5GqsXV017441; Tue, 5 Dec 2006 16:52:54 GMT Received: (from ralf@localhost) by denk.linux-mips.net (8.13.8/8.13.8/Submit) id kB5Gqrvf017440; Tue, 5 Dec 2006 16:52:53 GMT Date: Tue, 5 Dec 2006 16:52:53 +0000 From: Ralf Baechle To: Franck Bui-Huu Cc: Atsushi Nemoto , linux-mips@linux-mips.org Subject: Re: [PATCH] Import updates from i386's i8259.c Message-ID: <20061205165253.GA17390@linux-mips.org> References: <20061206.012311.86891097.anemo@mba.ocn.ne.jp> <4575A364.1010703@innova-card.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4575A364.1010703@innova-card.com> User-Agent: Mutt/1.4.2.2i 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: 13347 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, Dec 05, 2006 at 05:50:44PM +0100, Franck Bui-Huu wrote: > Atsushi Nemoto wrote: > > Import many updates from i386's i8259.c, especially genirq > > transitions. > > > > Does your patch make the following patch out of date (I sent > it to the list 4 days ago) ? > > [PATCH] Compile __do_IRQ() when really needed [take #3] I believe it will need an update. Ralf From vagabon.xyz@gmail.com Tue Dec 5 17:08:39 2006 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 05 Dec 2006 17:08:44 +0000 (GMT) Received: from nf-out-0910.google.com ([64.233.182.188]:7215 "EHLO nf-out-0910.google.com") by ftp.linux-mips.org with ESMTP id S20039028AbWLERIj (ORCPT ); Tue, 5 Dec 2006 17:08:39 +0000 Received: by nf-out-0910.google.com with SMTP id l24so259789nfc for ; Tue, 05 Dec 2006 09:08:38 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:reply-to:user-agent:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding:from; b=bIrcH7M5zfpZrD64S1bLRRxfh2cWOATx8nKg0fRaindy1NKCva/A2sBcnso+tQfdE1S6UksUw3lCvlIULgw26eMSVnyD1dowdlnC4tQGEwqX1zgQFYSjALW/D3cdC5J2rPJKtBf1A+0cddAkyB+O4ABchtby0KP7LIx6vlcEokE= Received: by 10.49.80.12 with SMTP id h12mr1096492nfl.1165338518341; Tue, 05 Dec 2006 09:08:38 -0800 (PST) Received: from ?192.168.0.24? ( [81.252.61.1]) by mx.google.com with ESMTP id v20sm3316440nfc.2006.12.05.09.08.37; Tue, 05 Dec 2006 09:08:37 -0800 (PST) Message-ID: <4575A7E8.60901@innova-card.com> Date: Tue, 05 Dec 2006 18:10:00 +0100 Reply-To: Franck User-Agent: Thunderbird 1.5.0.4 (X11/20060614) MIME-Version: 1.0 To: Ralf Baechle CC: Atsushi Nemoto , linux-mips@linux-mips.org Subject: Re: [PATCH] Import updates from i386's i8259.c References: <20061206.012311.86891097.anemo@mba.ocn.ne.jp> <4575A364.1010703@innova-card.com> <20061205165253.GA17390@linux-mips.org> In-Reply-To: <20061205165253.GA17390@linux-mips.org> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit From: Franck Bui-Huu 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: 13348 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, Ralf Baechle wrote: > > I believe it will need an update. > Ok, I'll do that tomorrow. Franck From sathesh_edara2003@yahoo.co.in Tue Dec 5 17:54:20 2006 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 05 Dec 2006 17:54:26 +0000 (GMT) Received: from web7907.mail.in.yahoo.com ([202.86.4.83]:8371 "HELO web7907.mail.in.yahoo.com") by ftp.linux-mips.org with SMTP id S20039045AbWLERyU (ORCPT ); Tue, 5 Dec 2006 17:54:20 +0000 Received: (qmail 20191 invoked by uid 60001); 5 Dec 2006 17:54:13 -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=hlRpZRKW0/lbGmPmQd29yDbCqZErKPFEP0ab456TAZ5QDAIBDjO/AsCZVUs0MSdTRRk44B9UzUbVExqsqmM4a661DA1SibjIG6hss7APs3A0H7H+/niC8EEw0yVHew19Ztb2j3awWW/Q9Qj0xmk02M2IIKwR03KFkEYM8pWvO9M=; X-YMail-OSG: 5lTBvnQVM1koWtYv0N6DiJxVjzrmtGVOb32onFeunmeCQTUFoWAPYHU3pHaW5oXr7saUK4_VPY8Q2Im5_1oL1JWK8KtJzBH0dMex2JVFaxiltzdGCZ62OeeF.gRTkfVj6mgUZx3fBMwtmPm6T39tdWlcHsygLb_l Received: from [206.40.46.114] by web7907.mail.in.yahoo.com via HTTP; Tue, 05 Dec 2006 17:54:12 GMT Date: Tue, 5 Dec 2006 17:54:12 +0000 (GMT) From: sathesh babu Subject: Toolchain for M IPS24KE To: linux-mips@linux-mips.org MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-34709160-1165341252=:20050" Content-Transfer-Encoding: 8bit Message-ID: <86084.20050.qm@web7907.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: 13349 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: sathesh_edara2003@yahoo.co.in Precedence: bulk X-list: linux-mips --0-34709160-1165341252=:20050 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Hi, Can some one give pointers on Toolchain for MIPS24KE ( Linux-2.6.x kernel). Could you please tell me where can i get the sources for this?. Regards, Sathesh --------------------------------- Find out what India is talking about on - Yahoo! Answers India Send FREE SMS to your friend's mobile from Yahoo! Messenger Version 8. Get it NOW --0-34709160-1165341252=:20050 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: 8bit
Hi,
  Can some one give pointers on Toolchain for MIPS24KE ( Linux-2.6.x kernel).
Could you please tell me where can i get the sources for this?.
 
Regards,
Sathesh

Find out what India is talking about on - Yahoo! Answers India
Send FREE SMS to your friend's mobile from Yahoo! Messenger Version 8. Get it NOW --0-34709160-1165341252=:20050-- From ashlesha@kenati.com Tue Dec 5 19:11:21 2006 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 05 Dec 2006 19:11:27 +0000 (GMT) Received: from [69.90.147.196] ([69.90.147.196]:21669 "EHLO mail.kenati.com") by ftp.linux-mips.org with ESMTP id S20038975AbWLETLV (ORCPT ); Tue, 5 Dec 2006 19:11:21 +0000 Received: from [192.168.1.169] (adsl-71-130-109-177.dsl.snfc21.pacbell.net [71.130.109.177]) by mail.kenati.com (Postfix) with ESMTP id 6D04B15D4004 for ; Tue, 5 Dec 2006 12:41:13 -0800 (PST) Subject: serial console: platform_device From: Ashlesha Shintre Reply-To: ashlesha@kenati.com To: linux-mips@linux-mips.org Content-Type: text/plain Date: Tue, 05 Dec 2006 11:23:59 -0800 Message-Id: <1165346639.6871.19.camel@sandbar.kenati.com> Mime-Version: 1.0 X-Mailer: Evolution 2.4.2.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: 13350 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: ashlesha@kenati.com Precedence: bulk X-list: linux-mips Hi, I m working on porting the 2.6.14.6 kernel to the Encore M3 (AU1500) board -- The kernel mounts the NFS root and executes the init=/bin/sh program -- however I dont see it on the console (standard 8250 UART) The reason is that there was no platform_device structure defined for the serial console in the platform.c file. I therefore added the following to the arch/mips/au1000/common/platform.c file, > > #ifdef CONFIG_MIPS_AMPRO_M3 > static struct plat_serial8250_port encm3_via_uart_data[] = { > { > .mapbase = 0x50000000 + 0x3f8, > .membase = (char *)(0x50000000 +0x3f8), > .irq = AU1000_GPIO_0, > .flags = UPF_SHARE_IRQ, > .iotype = UPIO_PORT, > .regshift = 1, > .uartclk = 1843200, > > }, > { }, > }; > > static struct resource encm3_via_uart_resource = { > .start = VIA_COM1_ADDR, // this is 0x3f8 > .end = VIA_COM1_ADDR + 0x7, > .flags = IORESOURCE_IO, > }; > > > static struct platform_device encm3_via_uart = { > .name = "serial8250", > .id = 1, > .dev = { > .platform_data = encm3_via_uart_data, > }, > .num_resources = 1, > .resource = &encm3_via_uart_resource, > }; > #endif > I have a these queries about the above entries: 1) The serial console is on a VIA 686B southbridge which is on the PCI bus -- however, because of the way the VIA is designed, any references from the processor to port 0x3f8 are routed to the console -- - the 0x50000000 is the mips_io_port_base address for the Southbridge so should the resource.flags be IORESOURCE_IO or IORESOURCE_MEM -- what does this signify exactly? I tried both and neither makes a difference to the output from the log buffer which I have pasted below. Does this have to do with whether the ports are i/o or memory mapped -- cus in that case it should be IORESOURCE_MEM as all io ports on MIPS processors are memory mapped -- right? 2) in the platform_device structure, does the name of the device have to be coherent with a name given to it elsewhere, if yes, where? 3) control goes into the serial8250_probe function and assigns values from the plat_serial8250_port encm3_via_uart_data to the port..so what is the basic difference between registration of "probe device" versus "platform bus" devices in the 2.6 kernel? When I build the kernel with this platform.c file and run it, I see an error in the pci_register_driver function executed to register the usb port which is on the AU1500 chip, which is the other platform device -- I did not get such an error before the above entries were added to the file! I have pasted the contents of the entire file below. Sorry about the length of this email and Thank you, Ashlesha. > /* > * Platform device support for Au1x00 SoCs. > * > * Copyright 2004, Matt Porter > * > * This file is licensed under the terms of the GNU General Public > * License version 2. This program is licensed "as is" without any > * warranty of any kind, whether express or implied. > */ > #include > #include > #include > #include > #include > #include > > #include > #include > > static struct resource au1xxx_usb_ohci_resources[] = { > [0] = { > .start = USB_OHCI_BASE, > .end = USB_OHCI_BASE + USB_OHCI_LEN, > .flags = IORESOURCE_MEM, > }, > [1] = { > .start = AU1000_USB_HOST_INT, > .end = AU1000_USB_HOST_INT, > .flags = IORESOURCE_IRQ, > }, > }; > > /* The dmamask must be set for OHCI to work */ > static u64 ohci_dmamask = ~(u32)0; > > static struct platform_device au1xxx_usb_ohci_device = { > .name = "au1xxx-ohci", > .id = 0, > .dev = { > .dma_mask = &ohci_dmamask, > .coherent_dma_mask = 0xffffffff, > }, > .num_resources = ARRAY_SIZE(au1xxx_usb_ohci_resources), > .resource = au1xxx_usb_ohci_resources, > 44,2-9 Top > > }; > > > > #ifdef CONFIG_MIPS_AMPRO_M3 > static struct plat_serial8250_port encm3_via_uart_data[] = { > { > // .mapbase = 0x50000000 + 0x3f8, //resource base > .membase = (char *)(0x50000000 + 0x3f8), // is a pointer - ioremap cookie or NULL > .irq = AU1000_GPIO_0, > .flags = UPF_SHARE_IRQ, //| UPF_IOREMAP, //UPF_BOOT_AUTOCONF | UPF_SKIP_TEST | > .iotype = UPIO_PORT, > .regshift = 1, > .uartclk = 1843200, > > }, > { }, > }; > > static struct resource encm3_via_uart_resource = { > .start = VIA_COM1_ADDR, > .end = VIA_COM1_ADDR + 0x7, > .flags = IORESOURCE_IO, > }; > > > static struct platform_device encm3_via_uart = { // coyote_uart arm/mach-ixp4xx/coyote-setup.c > .name = "serial8250", > .id = 1, > .dev = { > .platform_data = encm3_via_uart_data, > }, > .num_resources = 1, > .resource = &encm3_via_uart_resource, > }; > #endif > > static struct platform_device *au1xxx_platform_devices[] __initdata = { > &au1xxx_usb_ohci_device, > &encm3_via_uart, > }; > int au1xxx_platform_init(void) > { > printk("size of au1xxx platform devices is %d\n",ARRAY_SIZE(au1xxx_platform_devices)); > return platform_add_devices(au1xxx_platform_devices, ARRAY_SIZE(au1xxx_platform_devices)); > } > > arch_initcall(au1xxx_platform_init); > From sshtylyov@ru.mvista.com Tue Dec 5 19:41:31 2006 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 05 Dec 2006 19:41:36 +0000 (GMT) Received: from h155.mvista.com ([63.81.120.155]:62274 "EHLO imap.sh.mvista.com") by ftp.linux-mips.org with ESMTP id S20037733AbWLETlb (ORCPT ); Tue, 5 Dec 2006 19:41:31 +0000 Received: from [192.168.1.248] (unknown [10.150.0.9]) by imap.sh.mvista.com (Postfix) with ESMTP id 158E93EC9; Tue, 5 Dec 2006 11:41:09 -0800 (PST) Message-ID: <4575CBB6.8030804@ru.mvista.com> Date: Tue, 05 Dec 2006 22:42:46 +0300 From: Sergei Shtylyov Organization: MontaVista Software Inc. User-Agent: Mozilla/5.0 (X11; U; Linux i686; rv:1.7.2) Gecko/20040803 X-Accept-Language: ru, en-us, en-gb MIME-Version: 1.0 To: ashlesha@kenati.com Cc: linux-mips@linux-mips.org Subject: Re: serial console: platform_device References: <1165346639.6871.19.camel@sandbar.kenati.com> In-Reply-To: <1165346639.6871.19.camel@sandbar.kenati.com> Content-Type: text/plain; charset=us-ascii; 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: 13351 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: sshtylyov@ru.mvista.com Precedence: bulk X-list: linux-mips Hello. Ashlesha Shintre wrote: > I m working on porting the 2.6.14.6 kernel to the Encore M3 (AU1500) > board -- > The kernel mounts the NFS root and executes the init=/bin/sh program -- > however I dont see it on the console (standard 8250 UART) > The reason is that there was no platform_device structure defined for > the serial console in the platform.c file. > I therefore added the following to the > arch/mips/au1000/common/platform.c file, I doubt this is fitting place, since it only registers SoC devices. Move this to the *board* specific code instead. >>#ifdef CONFIG_MIPS_AMPRO_M3 >>static struct plat_serial8250_port encm3_via_uart_data[] = { >> { >> .mapbase = 0x50000000 + 0x3f8, I highly doubt this is correct -- the address 0x3f8 is in I/O space. And since 0x50000000 is mips_io_port_base, you do *not* need to add it here. >> .membase = (char *)(0x50000000 +0x3f8), This needs a kernel address, i.e. in KSEG1. As the UARTs are in the I/O space, you just don't need to set this. >>static struct resource encm3_via_uart_resource = { >> .start = VIA_COM1_ADDR, // this is 0x3f8 >> .end = VIA_COM1_ADDR + 0x7, >> .flags = IORESOURCE_IO, >>}; >> >> >>static struct platform_device encm3_via_uart = { >> .name = "serial8250", >> .id = 1, >> .dev = { >> .platform_data = encm3_via_uart_data, >> }, >> .num_resources = 1, Where the IRQ is declared? >> .resource = &encm3_via_uart_resource, >>}; >>#endif Well, I doubt that you need to also decalre the UART as platform_device in addition to registering it with 8250.x -- it'll do everything for you. > I have a these queries about the above entries: > 1) The serial console is on a VIA 686B southbridge which is on the PCI > bus -- however, because of the way the VIA is designed, any references > from the processor to port 0x3f8 are routed to the console -- > - the 0x50000000 is the mips_io_port_base address for the Southbridge > so should the resource.flags be IORESOURCE_IO or IORESOURCE_MEM -- what > does this signify exactly? On x86 the hardware on the busses is accessible via both memory and I/O address space (the 2nd method was historically preferred) -- so, all archs that want to reuse the standard x86 h/w have to adapt to its ways, implementing I/O address space accesses by some means, usually by dedicating the certain range of the physical addresses to it.... > I tried both and neither makes a difference > to the output from the log buffer which I have pasted below. Does this > have to do with whether the ports are i/o or memory mapped -- cus in This has to do with improper UART addresses you were passing. > that case it should be IORESOURCE_MEM as all io ports on MIPS processors > are memory mapped -- right? No, it should be IORESOURCE_IO. > 2) in the platform_device structure, does the name of the device have to > be coherent with a name given to it elsewhere, if yes, where? You just don't need it in this case. > 3) control goes into the serial8250_probe function and assigns values > from the plat_serial8250_port encm3_via_uart_data to the port..so what > is the basic difference between registration of "probe device" versus > "platform bus" devices in the 2.6 kernel? I'm not sure I follow you here. WBR, Sergei From ralf@linux-mips.org Tue Dec 5 19:49:09 2006 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 05 Dec 2006 19:49:10 +0000 (GMT) Received: from localhost.localdomain ([127.0.0.1]:6316 "EHLO dl5rb.ham-radio-op.net") by ftp.linux-mips.org with ESMTP id S20039061AbWLETtJ (ORCPT ); Tue, 5 Dec 2006 19:49:09 +0000 Received: from denk.linux-mips.net (denk.linux-mips.net [127.0.0.1]) by dl5rb.ham-radio-op.net (8.13.8/8.13.8) with ESMTP id kB5Jn8k4001185; Tue, 5 Dec 2006 19:49:08 GMT Received: (from ralf@localhost) by denk.linux-mips.net (8.13.8/8.13.8/Submit) id kB5Jn7Cj001184; Tue, 5 Dec 2006 19:49:07 GMT Date: Tue, 5 Dec 2006 19:49:07 +0000 From: Ralf Baechle To: Atsushi Nemoto Cc: linux-mips@linux-mips.org Subject: Re: [PATCH] Import updates from i386's i8259.c Message-ID: <20061205194907.GA1088@linux-mips.org> References: <20061206.012311.86891097.anemo@mba.ocn.ne.jp> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20061206.012311.86891097.anemo@mba.ocn.ne.jp> User-Agent: Mutt/1.4.2.2i 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: 13352 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, Dec 06, 2006 at 01:23:11AM +0900, Atsushi Nemoto wrote: > Import many updates from i386's i8259.c, especially genirq > transitions. With this patch applied Malta fails ... Ralf From ralf@linux-mips.org Tue Dec 5 19:57:04 2006 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 05 Dec 2006 19:57:05 +0000 (GMT) Received: from localhost.localdomain ([127.0.0.1]:37052 "EHLO dl5rb.ham-radio-op.net") by ftp.linux-mips.org with ESMTP id S20037733AbWLET5E (ORCPT ); Tue, 5 Dec 2006 19:57:04 +0000 Received: from denk.linux-mips.net (denk.linux-mips.net [127.0.0.1]) by dl5rb.ham-radio-op.net (8.13.8/8.13.8) with ESMTP id kB5Jv3Uo002129; Tue, 5 Dec 2006 19:57:03 GMT Received: (from ralf@localhost) by denk.linux-mips.net (8.13.8/8.13.8/Submit) id kB5Jv2n5002128; Tue, 5 Dec 2006 19:57:02 GMT Date: Tue, 5 Dec 2006 19:57:02 +0000 From: Ralf Baechle To: Atsushi Nemoto Cc: linux-mips@linux-mips.org Subject: Re: [PATCH] Import updates from i386's i8259.c Message-ID: <20061205195702.GA2097@linux-mips.org> References: <20061206.012311.86891097.anemo@mba.ocn.ne.jp> <20061205194907.GA1088@linux-mips.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20061205194907.GA1088@linux-mips.org> User-Agent: Mutt/1.4.2.2i 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: 13353 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, Dec 05, 2006 at 07:49:07PM +0000, Ralf Baechle wrote: > > Import many updates from i386's i8259.c, especially genirq > > transitions. > > With this patch applied Malta fails ... Which meant I removed this patch from my tree for now. Which means nothing is blocking Franck's patch anymore so I applied it with a trivial build fix to irq_cpu.c. Ralf From ashlesha@kenati.com Tue Dec 5 20:35:52 2006 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 05 Dec 2006 20:35:58 +0000 (GMT) Received: from [69.90.147.196] ([69.90.147.196]:29886 "EHLO mail.kenati.com") by ftp.linux-mips.org with ESMTP id S20039071AbWLEUfw (ORCPT ); Tue, 5 Dec 2006 20:35:52 +0000 Received: from [192.168.1.169] (adsl-71-130-109-177.dsl.snfc21.pacbell.net [71.130.109.177]) by mail.kenati.com (Postfix) with ESMTP id 3DBAF15D4004; Tue, 5 Dec 2006 14:05:44 -0800 (PST) Subject: Re: serial console: platform_device From: Ashlesha Shintre Reply-To: ashlesha@kenati.com To: Sergei Shtylyov Cc: linux-mips@linux-mips.org In-Reply-To: <4575CBB6.8030804@ru.mvista.com> References: <1165346639.6871.19.camel@sandbar.kenati.com> <4575CBB6.8030804@ru.mvista.com> Content-Type: text/plain Date: Tue, 05 Dec 2006 12:48:30 -0800 Message-Id: <1165351710.6871.34.camel@sandbar.kenati.com> Mime-Version: 1.0 X-Mailer: Evolution 2.4.2.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: 13354 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: ashlesha@kenati.com Precedence: bulk X-list: linux-mips Hi, Thank you for your prompt response -- I really appreciate it. On Tue, 2006-12-05 at 22:42 +0300, Sergei Shtylyov wrote: > > 3) control goes into the serial8250_probe function and assigns > values > > from the plat_serial8250_port encm3_via_uart_data to the port..so > what > > is the basic difference between registration of "probe device" > versus > > "platform bus" devices in the 2.6 kernel? > > I'm not sure I follow you here. What I meant was, what was the basis for the implementation of platform_device and platform_init functions in 2.6? By my understanding the way it worked in 2.4 was by the device probing functions that would allocate memory, io ports etc.. m working on making the changes you suggested -- without the addition of the platform_device and other structures, the serial console is never detected -- I never get a msg at boot time that reads serial8250: ttyS0 at I/O 0x3f8 (irq = whatever) is a 16550A so I think i might need these routines Also, the Southbridge interrupts are assigned interrupt number: AU1000_GPIO_0..and I have included this as below: > static struct plat_serial8250_port encm3_via_uart_data[] = { > { > .mapbase = 0x3f8, > .irq = AU1000_GPIO_0, > .flags = UPF_SHARE_IRQ, > .iotype = UPIO_PORT, > .regshift = 1, > .uartclk = 1843200, > > }, > { }, > }; Thanks again! Ashlesha. From sshtylyov@ru.mvista.com Tue Dec 5 20:45:21 2006 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 05 Dec 2006 20:45:26 +0000 (GMT) Received: from h155.mvista.com ([63.81.120.155]:23108 "EHLO imap.sh.mvista.com") by ftp.linux-mips.org with ESMTP id S20039071AbWLEUpV (ORCPT ); Tue, 5 Dec 2006 20:45:21 +0000 Received: from [192.168.1.248] (unknown [10.150.0.9]) by imap.sh.mvista.com (Postfix) with ESMTP id 8D2FC3EC9; Tue, 5 Dec 2006 12:45:18 -0800 (PST) Message-ID: <4575DABF.2000604@ru.mvista.com> Date: Tue, 05 Dec 2006 23:46:55 +0300 From: Sergei Shtylyov Organization: MontaVista Software Inc. User-Agent: Mozilla/5.0 (X11; U; Linux i686; rv:1.7.2) Gecko/20040803 X-Accept-Language: ru, en-us, en-gb MIME-Version: 1.0 To: ashlesha@kenati.com Cc: linux-mips@linux-mips.org Subject: Re: serial console: platform_device References: <1165346639.6871.19.camel@sandbar.kenati.com> <4575CBB6.8030804@ru.mvista.com> <1165351710.6871.34.camel@sandbar.kenati.com> In-Reply-To: <1165351710.6871.34.camel@sandbar.kenati.com> Content-Type: text/plain; charset=us-ascii; 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: 13355 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: sshtylyov@ru.mvista.com Precedence: bulk X-list: linux-mips Hello. Ashlesha Shintre wrote: >>>3) control goes into the serial8250_probe function and assigns values >>>from the plat_serial8250_port encm3_via_uart_data to the port..so what >>>is the basic difference between registration of "probe device" versus >>>"platform bus" devices in the 2.6 kernel? >> I'm not sure I follow you here. > What I meant was, what was the basis for the implementation of > platform_device and platform_init functions in 2.6? This is a convenient way to registers the various SoC and on-board devices residing on the busses that can't be scanned like ISA/LPC/whatever (and unlike PCI, for example). > By my understanding the way it worked in 2.4 was by the device probing > functions that would allocate memory, io ports etc.. Basically, you don't need to probe for device which you *know* is there, you just need to tell the driver where it is. > m working on making the changes you suggested -- > without the addition of the platform_device and other structures, the I meant that you *only* need struct plat_serial8250_port, and not platform_device. > serial console is never detected -- I never get a msg at boot time that > reads > serial8250: ttyS0 at I/O 0x3f8 (irq = whatever) is a 16550A > so I think i might need these routines > Also, the Southbridge interrupts are assigned interrupt number: > AU1000_GPIO_0..and I have included this as below: Ah, I forgot to mention that if your UART is a part of the south bridge, its IRQ number is _4_ on the integrated 8259 interrupt controller. I'm sure that AU1000_GPIO_0 is the cascaded interrupt request from 8259, not the UART's own IRQ... >>static struct plat_serial8250_port encm3_via_uart_data[] = { >> { >> .mapbase = 0x3f8, >> .irq = AU1000_GPIO_0, So, this is wrong. You need to specify to what platform IRQ 8259's IRQ4 gets routed here. > Thanks again! > Ashlesha. WBR, Sergei From ashlesha@kenati.com Wed Dec 6 00:18:21 2006 Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 06 Dec 2006 00:18:26 +0000 (GMT) Received: from [69.90.147.196] ([69.90.147.196]:62653 "EHLO mail.kenati.com") by ftp.linux-mips.org with ESMTP id S20039094AbWLFASV (ORCPT ); Wed, 6 Dec 2006 00:18:21 +0000 Received: from [192.168.1.169] (adsl-71-130-109-177.dsl.snfc21.pacbell.net [71.130.109.177]) by mail.kenati.com (Postfix) with ESMTP id 5027C15D4004; Tue, 5 Dec 2006 17:48:14 -0800 (PST) Subject: Re: serial console: platform_device From: Ashlesha Shintre Reply-To: ashlesha@kenati.com To: Sergei Shtylyov Cc: linux-mips@linux-mips.org In-Reply-To: <4575DABF.2000604@ru.mvista.com> References: <1165346639.6871.19.camel@sandbar.kenati.com> <4575CBB6.8030804@ru.mvista.com> <1165351710.6871.34.camel@sandbar.kenati.com> <4575DABF.2000604@ru.mvista.com> Content-Type: text/plain Date: Tue, 05 Dec 2006 16:30:58 -0800 Message-Id: <1165365058.6871.54.camel@sandbar.kenati.com> Mime-Version: 1.0 X-Mailer: Evolution 2.4.2.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: 13356 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: ashlesha@kenati.com Precedence: bulk X-list: linux-mips Hi Sergei, Another query: > Ah, I forgot to mention that if your UART is a part of the south bridge, > its IRQ number is _4_ on the integrated 8259 interrupt controller. I'm sure > that AU1000_GPIO_0 is the cascaded interrupt request from 8259, not the UART's > own IRQ... > > >>static struct plat_serial8250_port encm3_via_uart_data[] = { > >> { > >> .mapbase = 0x3f8, > >> .irq = AU1000_GPIO_0, > > So, this is wrong. You need to specify to what platform IRQ 8259's IRQ4 > gets routed here. I m not sure what you mean here -- the AU1000_GPIO_0 is the cascaded interrupt request from the 8259 on the VIA Southbridge -- Best Regards, Ashlesha. From yoichi_yuasa@tripeaks.co.jp Wed Dec 6 00:40:51 2006 Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 06 Dec 2006 00:40:56 +0000 (GMT) Received: from mo31.po.2iij.net ([210.128.50.54]:11281 "EHLO mo31.po.2iij.net") by ftp.linux-mips.org with ESMTP id S20039087AbWLFAkv (ORCPT ); Wed, 6 Dec 2006 00:40:51 +0000 Received: by mo.po.2iij.net (mo31) id kB60emZM068441; Wed, 6 Dec 2006 09:40:48 +0900 (JST) Received: from localhost.localdomain (65.126.232.202.bf.2iij.net [202.232.126.65]) by mbox.po.2iij.net (mbox32) id kB60ejPO055477 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 6 Dec 2006 09:40:45 +0900 (JST) Date: Wed, 6 Dec 2006 09:40:45 +0900 From: Yoichi Yuasa To: Ralf Baechle Cc: yoichi_yuasa@tripeaks.co.jp, linux-mips@linux-mips.org Subject: Re: [PATCH 1/5] MIPS: fix cobalt I/O resource range Message-Id: <20061206094045.785f57b9.yoichi_yuasa@tripeaks.co.jp> In-Reply-To: <20061204141042.GA7231@linux-mips.org> References: <20061201221242.261f57b0.yoichi_yuasa@tripeaks.co.jp> <20061204141042.GA7231@linux-mips.org> Organization: TriPeaks Corporation X-Mailer: Sylpheed version 1.0.4 (GTK+ 1.2.10; i386-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: 13357 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, Thank you for your comments. I'll update my patches. Yoichi On Mon, 4 Dec 2006 14:10:42 +0000 Ralf Baechle wrote: > On Fri, Dec 01, 2006 at 10:12:42PM +0900, Yoichi Yuasa wrote: > > > This patch has fixed cobalt I/O reource range. > > The cobalt real I/O resource range from 0x0 to 0xffff. > > > > Yoichi > > > > Signed-off-by: Yoichi Yuasa > > > > 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 2006-10-12 01:03:18.055569000 +0900 > > +++ mips/arch/mips/cobalt/setup.c 2006-10-12 01:01:59.973744750 +0900 > > @@ -130,8 +130,7 @@ void __init plat_mem_setup(void) > > > > set_io_port_base(CKSEG1ADDR(GT_DEF_PCI0_IO_BASE)); > > > > - /* I/O port resource must include UART and LCD/buttons */ > > - ioport_resource.end = 0x0fffffff; > > + ioport_resource.end = 0xffff; > > This is actually the default, so the code can go and anyway then the > code stops making sense, too. > > Ralf > From anemo@mba.ocn.ne.jp Wed Dec 6 01:28:43 2006 Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 06 Dec 2006 01:28:47 +0000 (GMT) Received: from topsns2.toshiba-tops.co.jp ([202.230.225.126]:42232 "EHLO topsns2.toshiba-tops.co.jp") by ftp.linux-mips.org with ESMTP id S20039115AbWLFB2n (ORCPT ); Wed, 6 Dec 2006 01:28:43 +0000 Received: from topsms.toshiba-tops.co.jp by topsns2.toshiba-tops.co.jp via smtpd (for ftp.linux-mips.org [194.74.144.162]) with ESMTP; Wed, 6 Dec 2006 10:28:42 +0900 Received: from topsms.toshiba-tops.co.jp (localhost.localdomain [127.0.0.1]) by localhost.toshiba-tops.co.jp (Postfix) with ESMTP id 2C21421F8B; Wed, 6 Dec 2006 10:28:35 +0900 (JST) Received: from srd2sd.toshiba-tops.co.jp (srd2sd.toshiba-tops.co.jp [172.17.28.2]) by topsms.toshiba-tops.co.jp (Postfix) with ESMTP id 176C72043A; Wed, 6 Dec 2006 10:28:35 +0900 (JST) Received: from localhost (fragile [172.17.28.65]) by srd2sd.toshiba-tops.co.jp (8.12.10/8.12.10) with ESMTP id kB61SYW0084533; Wed, 6 Dec 2006 10:28:34 +0900 (JST) (envelope-from anemo@mba.ocn.ne.jp) Date: Wed, 06 Dec 2006 10:28:33 +0900 (JST) Message-Id: <20061206.102833.126141309.nemoto@toshiba-tops.co.jp> To: vagabon.xyz@gmail.com Cc: linux-mips@linux-mips.org, ralf@linux-mips.org Subject: Re: [PATCH] Import updates from i386's i8259.c From: Atsushi Nemoto In-Reply-To: <4575A364.1010703@innova-card.com> References: <20061206.012311.86891097.anemo@mba.ocn.ne.jp> <4575A364.1010703@innova-card.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 3.3 on Emacs 21.3 / 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: 13358 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 Tue, 05 Dec 2006 17:50:44 +0100, Franck Bui-Huu wrote: > Does your patch make the following patch out of date (I sent > it to the list 4 days ago) ? > > [PATCH] Compile __do_IRQ() when really needed [take #3] Your patch should have no problem as is, but you might be able to add more "select GENERIC_HARDIRQS_NO__DO_IRQ" after my patch. --- Atsushi Nemoto From anemo@mba.ocn.ne.jp Wed Dec 6 01:39:26 2006 Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 06 Dec 2006 01:39:30 +0000 (GMT) Received: from topsns2.toshiba-tops.co.jp ([202.230.225.126]:45621 "EHLO topsns2.toshiba-tops.co.jp") by ftp.linux-mips.org with ESMTP id S20039130AbWLFBj0 (ORCPT ); Wed, 6 Dec 2006 01:39:26 +0000 Received: from topsms.toshiba-tops.co.jp by topsns2.toshiba-tops.co.jp via smtpd (for ftp.linux-mips.org [194.74.144.162]) with ESMTP; Wed, 6 Dec 2006 10:39:25 +0900 Received: from topsms.toshiba-tops.co.jp (localhost.localdomain [127.0.0.1]) by localhost.toshiba-tops.co.jp (Postfix) with ESMTP id C268E3EEB0; Wed, 6 Dec 2006 10:39:23 +0900 (JST) Received: from srd2sd.toshiba-tops.co.jp (srd2sd.toshiba-tops.co.jp [172.17.28.2]) by topsms.toshiba-tops.co.jp (Postfix) with ESMTP id B689F20485; Wed, 6 Dec 2006 10:39:23 +0900 (JST) Received: from localhost (fragile [172.17.28.65]) by srd2sd.toshiba-tops.co.jp (8.12.10/8.12.10) with ESMTP id kB61dNW0084581; Wed, 6 Dec 2006 10:39:23 +0900 (JST) (envelope-from anemo@mba.ocn.ne.jp) Date: Wed, 06 Dec 2006 10:39:23 +0900 (JST) Message-Id: <20061206.103923.71086192.nemoto@toshiba-tops.co.jp> To: ralf@linux-mips.org Cc: linux-mips@linux-mips.org Subject: Re: [PATCH] Import updates from i386's i8259.c From: Atsushi Nemoto In-Reply-To: <20061205195702.GA2097@linux-mips.org> References: <20061206.012311.86891097.anemo@mba.ocn.ne.jp> <20061205194907.GA1088@linux-mips.org> <20061205195702.GA2097@linux-mips.org> 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 3.3 on Emacs 21.3 / 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: 13359 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 Tue, 5 Dec 2006 19:57:02 +0000, Ralf Baechle wrote: > > > Import many updates from i386's i8259.c, especially genirq > > > transitions. > > > > With this patch applied Malta fails ... > > Which meant I removed this patch from my tree for now. Which means nothing > is blocking Franck's patch anymore so I applied it with a trivial build fix > to irq_cpu.c. Ah ... could you tell me how Malta failed? BTW, your additional irq_cpu.c might have another problem. The mips_mt_cpu_irq_controller have not used flow handler yet. I did not change it since I could not see which flow handler (handle_level_irq or handle_percpu_irq) are suitable at the time. --- Atsushi Nemoto From ralf@linux-mips.org Wed Dec 6 01:46:15 2006 Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 06 Dec 2006 01:46:16 +0000 (GMT) Received: from localhost.localdomain ([127.0.0.1]:21131 "EHLO dl5rb.ham-radio-op.net") by ftp.linux-mips.org with ESMTP id S20039115AbWLFBqP (ORCPT ); Wed, 6 Dec 2006 01:46:15 +0000 Received: from denk.linux-mips.net (denk.linux-mips.net [127.0.0.1]) by dl5rb.ham-radio-op.net (8.13.8/8.13.8) with ESMTP id kB61jqXD028041; Wed, 6 Dec 2006 01:45:52 GMT Received: (from ralf@localhost) by denk.linux-mips.net (8.13.8/8.13.8/Submit) id kB61jp38028040; Wed, 6 Dec 2006 01:45:51 GMT Date: Wed, 6 Dec 2006 01:45:51 +0000 From: Ralf Baechle To: Atsushi Nemoto Cc: vagabon.xyz@gmail.com, linux-mips@linux-mips.org Subject: Re: [PATCH] Import updates from i386's i8259.c Message-ID: <20061206014551.GA27985@linux-mips.org> References: <20061206.012311.86891097.anemo@mba.ocn.ne.jp> <4575A364.1010703@innova-card.com> <20061206.102833.126141309.nemoto@toshiba-tops.co.jp> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20061206.102833.126141309.nemoto@toshiba-tops.co.jp> User-Agent: Mutt/1.4.2.2i 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: 13360 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, Dec 06, 2006 at 10:28:33AM +0900, Atsushi Nemoto wrote: > > Does your patch make the following patch out of date (I sent > > it to the list 4 days ago) ? > > > > [PATCH] Compile __do_IRQ() when really needed [take #3] > > Your patch should have no problem as is, but you might be able to add > more "select GENERIC_HARDIRQS_NO__DO_IRQ" after my patch. Sure - but why checking in a patch when an updated version is already almost in flight ... Ralf From ralf@linux-mips.org Wed Dec 6 01:58:39 2006 Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 06 Dec 2006 01:58:41 +0000 (GMT) Received: from localhost.localdomain ([127.0.0.1]:26033 "EHLO dl5rb.ham-radio-op.net") by ftp.linux-mips.org with ESMTP id S20039130AbWLFB6j (ORCPT ); Wed, 6 Dec 2006 01:58:39 +0000 Received: from denk.linux-mips.net (denk.linux-mips.net [127.0.0.1]) by dl5rb.ham-radio-op.net (8.13.8/8.13.8) with ESMTP id kB61wId0028268; Wed, 6 Dec 2006 01:58:18 GMT Received: (from ralf@localhost) by denk.linux-mips.net (8.13.8/8.13.8/Submit) id kB61wIL0028267; Wed, 6 Dec 2006 01:58:18 GMT Date: Wed, 6 Dec 2006 01:58:18 +0000 From: Ralf Baechle To: Atsushi Nemoto Cc: linux-mips@linux-mips.org Subject: Re: [PATCH] Import updates from i386's i8259.c Message-ID: <20061206015818.GB27985@linux-mips.org> References: <20061206.012311.86891097.anemo@mba.ocn.ne.jp> <20061205194907.GA1088@linux-mips.org> <20061205195702.GA2097@linux-mips.org> <20061206.103923.71086192.nemoto@toshiba-tops.co.jp> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20061206.103923.71086192.nemoto@toshiba-tops.co.jp> User-Agent: Mutt/1.4.2.2i 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: 13361 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, Dec 06, 2006 at 10:39:23AM +0900, Atsushi Nemoto wrote: > Ah ... could you tell me how Malta failed? IDE DMA timeouts. There are some other issues with the legacy IDE on the Intel PIIX which likely affect other systems such as Alpha as well. I think I solved that so it's now time to tackle the IRQ stuff. Even without your i8259 stuff there are some strange things going on currently: [...] hda: Maxtor 31536H2, ATA DISK drive ide0 at 0x1f0-0x1f7,0x3f6 on irq 14 hda: max request size: 128KiB hda: 30015216 sectors (15367 MB) w/512KiB Cache, CHS=29777/16/63, UDMA(33) hda: cache flushes not supported hda: hda1 hda2 mice: PS/2 mouse device common for all mice TCP cubic registered NET: Registered protocol family 1 NET: Registered protocol family 17 NET: Registered protocol family 15 Time: MIPS clocksource has been installed. EXT3-fs: INFO: recovery required on readonly filesystem. EXT3-fs: write access will be enabled during recovery. kjournald starting. Commit interval 5 seconds EXT3-fs: recovery complete. EXT3-fs: mounted filesystem with ordered data mode. VFS: Mounted root (ext3 filesystem) readonly. Freeing prom memory: 956kb freed Freeing firmware memory: 978944k freed Freeing unused kernel memory: 160k freed irq 7, desc: 803db360, depth: 1, count: 0, unhandled: 0 ->handle_irq(): 8014ff28, handle_bad_irq+0x0/0x318 ->chip(): 803a3d4c, 0x803a3d4c ->action(): 00000000 IRQ_DISABLED set unexpected IRQ # 7 Algorithmics/MIPS FPU Emulator v1.5 irq 7, desc: 803db360, depth: 1, count: 0, unhandled: 0 ->handle_irq(): 8014ff28, handle_bad_irq+0x0/0x318 ->chip(): 803a3d4c, 0x803a3d4c ->action(): 00000000 IRQ_DISABLED set unexpected IRQ # 7 INIT: irq 7, desc: 803db360, depth: 1, count: 0, unhandled: 0 ->handle_irq(): 8014ff28, handle_bad_irq+0x0/0x318 ->chip(): 803a3d4c, 0x803a3d4c ->action(): 00000000 IRQ_DISABLED set unexpected IRQ # 7 version 2.84 bootingirq 7, desc: 803db360, depth: 1, count: 0, unhandled: 0 ->handle_irq(): 8014ff28, handle_bad_irq+0x0/0x318 ->chip(): 803a3d4c, 0x803a3d4c ->action(): 00000000 IRQ_DISABLED set unexpected IRQ # 7 irq 7, desc: 803db360, depth: 1, count: 0, unhandled: 0 ->handle_irq(): 8014ff28, handle_bad_irq+0x0/0x318 ->chip(): 803a3d4c, 0x803a3d4c ->action(): 00000000 IRQ_DISABLED set unexpected IRQ # 7 Welcome to Red Hat Linux Press 'I' to enter interactive startup. Mounting proc filesystem: [ OK ] Configuring kernel parameters: [ OK ] Setting clock (utc): Wed Dec 6 00:16:39 GMT 2006 [ OK ] Activating swap partitions: [ OK ] [...] > BTW, your additional irq_cpu.c might have another problem. The > mips_mt_cpu_irq_controller have not used flow handler yet. I did not > change it since I could not see which flow handler (handle_level_irq > or handle_percpu_irq) are suitable at the time. Ralf From anemo@mba.ocn.ne.jp Wed Dec 6 02:56:08 2006 Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 06 Dec 2006 02:56:12 +0000 (GMT) Received: from topsns2.toshiba-tops.co.jp ([202.230.225.126]:30909 "EHLO topsns2.toshiba-tops.co.jp") by ftp.linux-mips.org with ESMTP id S20039154AbWLFC4I (ORCPT ); Wed, 6 Dec 2006 02:56:08 +0000 Received: from topsms.toshiba-tops.co.jp by topsns2.toshiba-tops.co.jp via smtpd (for ftp.linux-mips.org [194.74.144.162]) with ESMTP; Wed, 6 Dec 2006 11:56:06 +0900 Received: from topsms.toshiba-tops.co.jp (localhost.localdomain [127.0.0.1]) by localhost.toshiba-tops.co.jp (Postfix) with ESMTP id 53846417CC; Wed, 6 Dec 2006 11:56:03 +0900 (JST) Received: from srd2sd.toshiba-tops.co.jp (srd2sd.toshiba-tops.co.jp [172.17.28.2]) by topsms.toshiba-tops.co.jp (Postfix) with ESMTP id 4026320302; Wed, 6 Dec 2006 11:56:03 +0900 (JST) Received: from localhost (fragile [172.17.28.65]) by srd2sd.toshiba-tops.co.jp (8.12.10/8.12.10) with ESMTP id kB62u2W0084873; Wed, 6 Dec 2006 11:56:03 +0900 (JST) (envelope-from anemo@mba.ocn.ne.jp) Date: Wed, 06 Dec 2006 11:56:02 +0900 (JST) Message-Id: <20061206.115602.63741871.nemoto@toshiba-tops.co.jp> To: ralf@linux-mips.org Cc: linux-mips@linux-mips.org Subject: Re: [PATCH] Import updates from i386's i8259.c From: Atsushi Nemoto In-Reply-To: <20061206015818.GB27985@linux-mips.org> References: <20061205195702.GA2097@linux-mips.org> <20061206.103923.71086192.nemoto@toshiba-tops.co.jp> <20061206015818.GB27985@linux-mips.org> 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 3.3 on Emacs 21.3 / 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: 13362 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 Wed, 6 Dec 2006 01:58:18 +0000, Ralf Baechle wrote: > There are some other issues with the legacy IDE on the Intel PIIX which > likely affect other systems such as Alpha as well. I think I solved that > so it's now time to tackle the IRQ stuff. Even without your i8259 stuff > there are some strange things going on currently: > > [...] > irq 7, desc: 803db360, depth: 1, count: 0, unhandled: 0 > ->handle_irq(): 8014ff28, handle_bad_irq+0x0/0x318 > ->chip(): 803a3d4c, 0x803a3d4c > ->action(): 00000000 > IRQ_DISABLED set > unexpected IRQ # 7 Hmm ... malta_int.c:get_int() returned 7? I have no idea, but it seems mips_irq_lock in malta_int.c can be replaced by i8259A_lock... --- Atsushi Nemoto From anemo@mba.sphere.ne.jp Wed Dec 6 04:38:41 2006 Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 06 Dec 2006 04:38:47 +0000 (GMT) Received: from topsns2.toshiba-tops.co.jp ([202.230.225.126]:9547 "EHLO topsns2.toshiba-tops.co.jp") by ftp.linux-mips.org with ESMTP id S20027544AbWLFEil (ORCPT ); Wed, 6 Dec 2006 04:38:41 +0000 Received: from topsms.toshiba-tops.co.jp by topsns2.toshiba-tops.co.jp via smtpd (for ftp.linux-mips.org [194.74.144.162]) with ESMTP; Wed, 6 Dec 2006 13:38:39 +0900 Received: from topsms.toshiba-tops.co.jp (localhost.localdomain [127.0.0.1]) by localhost.toshiba-tops.co.jp (Postfix) with ESMTP id BD54420741; Wed, 6 Dec 2006 13:38:37 +0900 (JST) Received: from srd2sd.toshiba-tops.co.jp (srd2sd.toshiba-tops.co.jp [172.17.28.2]) by topsms.toshiba-tops.co.jp (Postfix) with ESMTP id A941D20488; Wed, 6 Dec 2006 13:38:37 +0900 (JST) Received: from localhost (fragile [172.17.28.65]) by srd2sd.toshiba-tops.co.jp (8.12.10/8.12.10) with ESMTP id kB64caW0085181; Wed, 6 Dec 2006 13:38:37 +0900 (JST) (envelope-from anemo@mba.sphere.ne.jp) Date: Wed, 06 Dec 2006 13:38:36 +0900 (JST) Message-Id: <20061206.133836.89067271.nemoto@toshiba-tops.co.jp> To: ralf@linux-mips.org Cc: linux-mips@linux-mips.org Subject: Re: [PATCH] Import updates from i386's i8259.c From: anemo@mba.sphere.ne.jp In-Reply-To: <20061206.115602.63741871.nemoto@toshiba-tops.co.jp> References: <20061206.103923.71086192.nemoto@toshiba-tops.co.jp> <20061206015818.GB27985@linux-mips.org> <20061206.115602.63741871.nemoto@toshiba-tops.co.jp> 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 3.3 on Emacs 21.3 / 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: 13363 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.sphere.ne.jp Precedence: bulk X-list: linux-mips On Wed, 06 Dec 2006 11:56:02 +0900 (JST), Atsushi Nemoto wrote: > > unexpected IRQ # 7 > > Hmm ... malta_int.c:get_int() returned 7? I have no idea, but it > seems mips_irq_lock in malta_int.c can be replaced by i8259A_lock... Though I can not see why IRQ7 raised, I found a fault in my patch. - outb_p(0x00, 0x21); /* ICW2: 8259A-1 IR0-7 mapped to 0x00-0x07 */ ... - outb_p(0x08, 0xA1); /* ICW2: 8259A-2 IR0-7 mapped to 0x08-0x0f */ ... + outb_p(0x20 + 0, PIC_MASTER_IMR); /* ICW2: 8259A-1 IR0-7 mapped to 0x20-0x27 */ ... + outb_p(0x20 + 8, PIC_SLAVE_IMR); /* ICW2: 8259A-2 IR0-7 mapped to 0x28-0x2f */ MIPS was mapping i8259 irqs to 0-15 but i386 is mapping them to 0x20-0x2f. Here is a revised patch. Please try it. Subject: [PATCH] Import updates from i386's i8259.c (take 2) Import many updates from i386's i8259.c, especially genirq transitions. Signed-off-by: Atsushi Nemoto --- diff --git a/arch/mips/kernel/i8259.c b/arch/mips/kernel/i8259.c index 2526c0c..85ca2a9 100644 --- a/arch/mips/kernel/i8259.c +++ b/arch/mips/kernel/i8259.c @@ -19,9 +19,6 @@ #include #include #include -void enable_8259A_irq(unsigned int irq); -void disable_8259A_irq(unsigned int irq); - /* * This is the 'legacy' 8259A Programmable Interrupt Controller, * present in the majority of PC/AT boxes. @@ -31,23 +28,16 @@ void disable_8259A_irq(unsigned int irq) * moves to arch independent land */ +static int i8259A_auto_eoi; DEFINE_SPINLOCK(i8259A_lock); - -static void end_8259A_irq (unsigned int irq) -{ - if (!(irq_desc[irq].status & (IRQ_DISABLED|IRQ_INPROGRESS)) && - irq_desc[irq].action) - enable_8259A_irq(irq); -} - +/* some platforms call this... */ void mask_and_ack_8259A(unsigned int); -static struct irq_chip i8259A_irq_type = { - .typename = "XT-PIC", - .enable = enable_8259A_irq, - .disable = disable_8259A_irq, - .ack = mask_and_ack_8259A, - .end = end_8259A_irq, +static struct irq_chip i8259A_chip = { + .name = "XT-PIC", + .mask = disable_8259A_irq, + .unmask = enable_8259A_irq, + .mask_ack = mask_and_ack_8259A, }; /* @@ -59,8 +49,8 @@ static struct irq_chip i8259A_irq_type = */ static unsigned int cached_irq_mask = 0xffff; -#define cached_21 (cached_irq_mask) -#define cached_A1 (cached_irq_mask >> 8) +#define cached_master_mask (cached_irq_mask) +#define cached_slave_mask (cached_irq_mask >> 8) void disable_8259A_irq(unsigned int irq) { @@ -70,9 +60,9 @@ void disable_8259A_irq(unsigned int irq) spin_lock_irqsave(&i8259A_lock, flags); cached_irq_mask |= mask; if (irq & 8) - outb(cached_A1,0xA1); + outb(cached_slave_mask, PIC_SLAVE_IMR); else - outb(cached_21,0x21); + outb(cached_master_mask, PIC_MASTER_IMR); spin_unlock_irqrestore(&i8259A_lock, flags); } @@ -84,23 +74,23 @@ void enable_8259A_irq(unsigned int irq) spin_lock_irqsave(&i8259A_lock, flags); cached_irq_mask &= mask; if (irq & 8) - outb(cached_A1,0xA1); + outb(cached_slave_mask, PIC_SLAVE_IMR); else - outb(cached_21,0x21); + outb(cached_master_mask, PIC_MASTER_IMR); spin_unlock_irqrestore(&i8259A_lock, flags); } int i8259A_irq_pending(unsigned int irq) { - unsigned int mask = 1 << irq; + unsigned int mask = 1<> 8); + ret = inb(PIC_SLAVE_CMD) & (mask >> 8); spin_unlock_irqrestore(&i8259A_lock, flags); return ret; @@ -109,7 +99,8 @@ int i8259A_irq_pending(unsigned int irq) void make_8259A_irq(unsigned int irq) { disable_irq_nosync(irq); - set_irq_chip(irq, &i8259A_irq_type); + set_irq_chip_and_handler_name(irq, &i8259A_chip, handle_level_irq, + "XT"); enable_irq(irq); } @@ -122,17 +113,17 @@ void make_8259A_irq(unsigned int irq) static inline int i8259A_irq_real(unsigned int irq) { int value; - int irqmask = 1 << irq; + int irqmask = 1<> 8); - outb(0x0A,0xA0); /* back to the IRR register */ + outb(0x0B,PIC_SLAVE_CMD); /* ISR register */ + value = inb(PIC_SLAVE_CMD) & (irqmask >> 8); + outb(0x0A,PIC_SLAVE_CMD); /* back to the IRR register */ return value; } @@ -149,17 +140,19 @@ void mask_and_ack_8259A(unsigned int irq spin_lock_irqsave(&i8259A_lock, flags); /* - * Lightweight spurious IRQ detection. We do not want to overdo - * spurious IRQ handling - it's usually a sign of hardware problems, so - * we only do the checks we can do without slowing down good hardware - * nnecesserily. + * Lightweight spurious IRQ detection. We do not want + * to overdo spurious IRQ handling - it's usually a sign + * of hardware problems, so we only do the checks we can + * do without slowing down good hardware unnecessarily. * - * Note that IRQ7 and IRQ15 (the two spurious IRQs usually resulting - * rom the 8259A-1|2 PICs) occur even if the IRQ is masked in the 8259A. - * Thus we can check spurious 8259A IRQs without doing the quite slow - * i8259A_irq_real() call for every IRQ. This does not cover 100% of - * spurious interrupts, but should be enough to warn the user that - * there is something bad going on ... + * Note that IRQ7 and IRQ15 (the two spurious IRQs + * usually resulting from the 8259A-1|2 PICs) occur + * even if the IRQ is masked in the 8259A. Thus we + * can check spurious 8259A IRQs without doing the + * quite slow i8259A_irq_real() call for every IRQ. + * This does not cover 100% of spurious interrupts, + * but should be enough to warn the user that there + * is something bad going on ... */ if (cached_irq_mask & irqmask) goto spurious_8259A_irq; @@ -167,14 +160,14 @@ void mask_and_ack_8259A(unsigned int irq handle_real_irq: if (irq & 8) { - inb(0xA1); /* DUMMY - (do we need this?) */ - outb(cached_A1,0xA1); - outb(0x60+(irq&7),0xA0);/* 'Specific EOI' to slave */ - outb(0x62,0x20); /* 'Specific EOI' to master-IRQ2 */ + inb(PIC_SLAVE_IMR); /* DUMMY - (do we need this?) */ + outb(cached_slave_mask, PIC_SLAVE_IMR); + outb(0x60+(irq&7),PIC_SLAVE_CMD);/* 'Specific EOI' to slave */ + outb(0x60+PIC_CASCADE_IR,PIC_MASTER_CMD); /* 'Specific EOI' to master-IRQ2 */ } else { - inb(0x21); /* DUMMY - (do we need this?) */ - outb(cached_21,0x21); - outb(0x60+irq,0x20); /* 'Specific EOI' to master */ + inb(PIC_MASTER_IMR); /* DUMMY - (do we need this?) */ + outb(cached_master_mask, PIC_MASTER_IMR); + outb(0x60+irq,PIC_MASTER_CMD); /* 'Specific EOI to master */ } #ifdef CONFIG_MIPS_MT_SMTC if (irq_hwmask[irq] & ST0_IM) @@ -195,7 +188,7 @@ spurious_8259A_irq: goto handle_real_irq; { - static int spurious_irq_mask = 0; + static int spurious_irq_mask; /* * At this point we can be sure the IRQ is spurious, * lets ACK and report it. [once per IRQ] @@ -214,15 +207,52 @@ spurious_8259A_irq: } } +static char irq_trigger[2]; +/** + * ELCR registers (0x4d0, 0x4d1) control edge/level of IRQ + */ +static void restore_ELCR(char *trigger) +{ + outb(trigger[0], 0x4d0); + outb(trigger[1], 0x4d1); +} + +static void save_ELCR(char *trigger) +{ + /* IRQ 0,1,2,8,13 are marked as reserved */ + trigger[0] = inb(0x4d0) & 0xF8; + trigger[1] = inb(0x4d1) & 0xDE; +} + static int i8259A_resume(struct sys_device *dev) { - init_8259A(0); + init_8259A(i8259A_auto_eoi); + restore_ELCR(irq_trigger); + return 0; +} + +static int i8259A_suspend(struct sys_device *dev, pm_message_t state) +{ + save_ELCR(irq_trigger); + return 0; +} + +static int i8259A_shutdown(struct sys_device *dev) +{ + /* Put the i8259A into a quiescent state that + * the kernel initialization code can get it + * out of. + */ + outb(0xff, PIC_MASTER_IMR); /* mask all of 8259A-1 */ + outb(0xff, PIC_SLAVE_IMR); /* mask all of 8259A-1 */ return 0; } static struct sysdev_class i8259_sysdev_class = { set_kset_name("i8259"), + .suspend = i8259A_suspend, .resume = i8259A_resume, + .shutdown = i8259A_shutdown, }; static struct sys_device device_i8259A = { @@ -244,41 +274,41 @@ void __init init_8259A(int auto_eoi) { unsigned long flags; + i8259A_auto_eoi = auto_eoi; + spin_lock_irqsave(&i8259A_lock, flags); - outb(0xff, 0x21); /* mask all of 8259A-1 */ - outb(0xff, 0xA1); /* mask all of 8259A-2 */ + outb(0xff, PIC_MASTER_IMR); /* mask all of 8259A-1 */ + outb(0xff, PIC_SLAVE_IMR); /* mask all of 8259A-2 */ /* * outb_p - this has to work on a wide range of PC hardware. */ - outb_p(0x11, 0x20); /* ICW1: select 8259A-1 init */ - outb_p(0x00, 0x21); /* ICW2: 8259A-1 IR0-7 mapped to 0x00-0x07 */ - outb_p(0x04, 0x21); /* 8259A-1 (the master) has a slave on IR2 */ - if (auto_eoi) - outb_p(0x03, 0x21); /* master does Auto EOI */ - else - outb_p(0x01, 0x21); /* master expects normal EOI */ - - outb_p(0x11, 0xA0); /* ICW1: select 8259A-2 init */ - outb_p(0x08, 0xA1); /* ICW2: 8259A-2 IR0-7 mapped to 0x08-0x0f */ - outb_p(0x02, 0xA1); /* 8259A-2 is a slave on master's IR2 */ - outb_p(0x01, 0xA1); /* (slave's support for AEOI in flat mode - is to be investigated) */ - + outb_p(0x11, PIC_MASTER_CMD); /* ICW1: select 8259A-1 init */ + outb_p(I8259A_IRQ_BASE + 0, PIC_MASTER_IMR); /* ICW2: 8259A-1 IR0 mapped to I8259A_IRQ_BASE + 0x00 */ + outb_p(1U << PIC_CASCADE_IR, PIC_MASTER_IMR); /* 8259A-1 (the master) has a slave on IR2 */ + if (auto_eoi) /* master does Auto EOI */ + outb_p(MASTER_ICW4_DEFAULT | PIC_ICW4_AEOI, PIC_MASTER_IMR); + else /* master expects normal EOI */ + outb_p(MASTER_ICW4_DEFAULT, PIC_MASTER_IMR); + + outb_p(0x11, PIC_SLAVE_CMD); /* ICW1: select 8259A-2 init */ + outb_p(I8259A_IRQ_BASE + 8, PIC_SLAVE_IMR); /* ICW2: 8259A-2 IR0 mapped to I8259A_IRQ_BASE + 0x08 */ + outb_p(PIC_CASCADE_IR, PIC_SLAVE_IMR); /* 8259A-2 is a slave on master's IR2 */ + outb_p(SLAVE_ICW4_DEFAULT, PIC_SLAVE_IMR); /* (slave's support for AEOI in flat mode is to be investigated) */ if (auto_eoi) /* - * in AEOI mode we just have to mask the interrupt + * In AEOI mode we just have to mask the interrupt * when acking. */ - i8259A_irq_type.ack = disable_8259A_irq; + i8259A_chip.mask_ack = disable_8259A_irq; else - i8259A_irq_type.ack = mask_and_ack_8259A; + i8259A_chip.mask_ack = mask_and_ack_8259A; udelay(100); /* wait for 8259A to initialize */ - outb(cached_21, 0x21); /* restore master IRQ mask */ - outb(cached_A1, 0xA1); /* restore slave IRQ mask */ + outb(cached_master_mask, PIC_MASTER_IMR); /* restore master IRQ mask */ + outb(cached_slave_mask, PIC_SLAVE_IMR); /* restore slave IRQ mask */ spin_unlock_irqrestore(&i8259A_lock, flags); } @@ -291,11 +321,17 @@ static struct irqaction irq2 = { }; static struct resource pic1_io_resource = { - .name = "pic1", .start = 0x20, .end = 0x21, .flags = IORESOURCE_BUSY + .name = "pic1", + .start = PIC_MASTER_CMD, + .end = PIC_MASTER_IMR, + .flags = IORESOURCE_BUSY }; static struct resource pic2_io_resource = { - .name = "pic2", .start = 0xa0, .end = 0xa1, .flags = IORESOURCE_BUSY + .name = "pic2", + .start = PIC_SLAVE_CMD, + .end = PIC_SLAVE_IMR, + .flags = IORESOURCE_BUSY }; /* @@ -313,7 +349,8 @@ void __init init_i8259_irqs (void) init_8259A(0); for (i = 0; i < 16; i++) - set_irq_chip(i, &i8259A_irq_type); + set_irq_chip_and_handler_name(i, &i8259A_chip, + handle_level_irq, "XT"); - setup_irq(2, &irq2); + setup_irq(PIC_CASCADE_IR, &irq2); } diff --git a/include/asm-mips/i8259.h b/include/asm-mips/i8259.h index 0214abe..4df8d8b 100644 --- a/include/asm-mips/i8259.h +++ b/include/asm-mips/i8259.h @@ -19,10 +19,31 @@ #include #include +/* i8259A PIC registers */ +#define PIC_MASTER_CMD 0x20 +#define PIC_MASTER_IMR 0x21 +#define PIC_MASTER_ISR PIC_MASTER_CMD +#define PIC_MASTER_POLL PIC_MASTER_ISR +#define PIC_MASTER_OCW3 PIC_MASTER_ISR +#define PIC_SLAVE_CMD 0xa0 +#define PIC_SLAVE_IMR 0xa1 + +/* i8259A PIC related value */ +#define PIC_CASCADE_IR 2 +#define MASTER_ICW4_DEFAULT 0x01 +#define SLAVE_ICW4_DEFAULT 0x01 +#define PIC_ICW4_AEOI 2 + extern spinlock_t i8259A_lock; +extern void init_8259A(int auto_eoi); +extern void enable_8259A_irq(unsigned int irq); +extern void disable_8259A_irq(unsigned int irq); + extern void init_i8259_irqs(void); +#define I8259A_IRQ_BASE 0 + /* * Do the traditional i8259 interrupt polling thing. This is for the few * cases where no better interrupt acknowledge method is available and we @@ -35,15 +56,15 @@ static inline int i8259_irq(void) spin_lock(&i8259A_lock); /* Perform an interrupt acknowledge cycle on controller 1. */ - outb(0x0C, 0x20); /* prepare for poll */ - irq = inb(0x20) & 7; - if (irq == 2) { + outb(0x0C, PIC_MASTER_CMD); /* prepare for poll */ + irq = inb(PIC_MASTER_CMD) & 7; + if (irq == PIC_CASCADE_IR) { /* * Interrupt is cascaded so perform interrupt * acknowledge on controller 2. */ - outb(0x0C, 0xA0); /* prepare for poll */ - irq = (inb(0xA0) & 7) + 8; + outb(0x0C, PIC_SLAVE_CMD); /* prepare for poll */ + irq = (inb(PIC_SLAVE_CMD) & 7) + 8; } if (unlikely(irq == 7)) { @@ -54,14 +75,14 @@ static inline int i8259_irq(void) * significant bit is not set then there is no valid * interrupt. */ - outb(0x0B, 0x20); /* ISR register */ - if(~inb(0x20) & 0x80) + outb(0x0B, PIC_MASTER_ISR); /* ISR register */ + if(~inb(PIC_MASTER_ISR) & 0x80) irq = -1; } spin_unlock(&i8259A_lock); - return irq; + return likely(irq >= 0) ? irq + I8259A_IRQ_BASE : irq; } #endif /* _ASM_I8259_H */ From ydgoo9@gmail.com Wed Dec 6 08:05:02 2006 Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 06 Dec 2006 08:05:06 +0000 (GMT) Received: from ug-out-1314.google.com ([66.249.92.171]:54937 "EHLO ug-out-1314.google.com") by ftp.linux-mips.org with ESMTP id S20037666AbWLFIFC (ORCPT ); Wed, 6 Dec 2006 08:05:02 +0000 Received: by ug-out-1314.google.com with SMTP id 40so76168uga for ; Wed, 06 Dec 2006 00:05:02 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; b=I3F3rRbJUaaUm3/Vpgm42VKb93E28/tyMwssAtdEMlBtKohlrMo24XmlINDHHXIA4uat7LMiXHZ8Rj55QPIbW5G5AXf7yLn5qgfTlDGn07ZmONPHGxt+vnsi1urDAzYv0uoLXbT426DRxBlMvCHM/MbTSa0/c4vSAWKH4kcucQI= Received: by 10.78.17.1 with SMTP id 1mr324601huq.1165392301698; Wed, 06 Dec 2006 00:05:01 -0800 (PST) Received: by 10.78.199.6 with HTTP; Wed, 6 Dec 2006 00:05:01 -0800 (PST) Message-ID: <38dc7fce0612060005o6807e347re182171214c2501a@mail.gmail.com> Date: Wed, 6 Dec 2006 17:05:01 +0900 From: "Youngduk Goo" To: linux-mips@linux-mips.org Subject: USB 2.0 error MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed 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: 13364 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: ydgoo9@gmail.com Precedence: bulk X-list: linux-mips I have tested the USB 2.0 and 1.1 on my set based on the mips core. The kernel version is 2.6.15 (not the uclinux) with uClibc. The port 0 of USB is working fine as a EHCI(2.0) when I put the storage. But In case of port 1, it fails to identify the device. It can read the device information but cannot read partition table. I don't know how to debug it. ans where to start it. Please give me a advice. Thanks in advance. This is the error message. Vendor: I0MEGA Model: Mini128MB*IOM2B5 Rev: 2.00 Type: Direct-Access ANSI SCSI revision: 02 aSCSI device sda: 256000 512-byte hdwr sectors (131 MB) sda: Write Protect is off sda: Mode Sense: 03 00 00 00 sda: assuming drive cache: write through SCSI device sda: 256000 512-byte hdwr sectors (131 MB) sda: Write Protect is off sda: Mode Sense: 03 00 00 00 sda: assuming drive cache: write through usb 1-2: reset high speed USB device using hcd and address 2 sd 0:0:0:0: SCSI error: return code = 0x70000 end_request: I/O error, dev sda, sector 0 Buffer I/O error on device sda, logical block 0 usb 1-2: reset high speed USB device using hcd and address 2 sd 0:0:0:0: SCSI error: return code = 0x70000 end_request: I/O error, dev sda, sector 0 Buffer I/O error on device sda, logical block 0 unable to read partition table sd 0:0:0:0: Attached scsi removable disk sda sd 0:0:0:0: Attached scsi generic sg0 type 0 usb-storage: device scan complete From vagabon.xyz@gmail.com Wed Dec 6 08:40:51 2006 Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 06 Dec 2006 08:40:55 +0000 (GMT) Received: from ug-out-1314.google.com ([66.249.92.171]:17489 "EHLO ug-out-1314.google.com") by ftp.linux-mips.org with ESMTP id S20038322AbWLFIkv (ORCPT ); Wed, 6 Dec 2006 08:40:51 +0000 Received: by ug-out-1314.google.com with SMTP id 40so83838uga for ; Wed, 06 Dec 2006 00:40:51 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=BL1dD1A19paWMmd8HKOeGHSXepDDHyi5PWwq6cFUkgIRqRKLvst6lQ7i2RuYRl2YgBAncP+fdD9k/YeOjRwfK/6CA7NPjqox5FNM1KUIIxkEfMf3Is3UyK69zTZyby5rUKeRm4BJB70vW8jqtfofmqeW554dRZcsQqYnWH0vIyg= Received: by 10.78.128.15 with SMTP id a15mr403269hud.1165394450547; Wed, 06 Dec 2006 00:40:50 -0800 (PST) Received: by 10.78.123.2 with HTTP; Wed, 6 Dec 2006 00:40:50 -0800 (PST) Message-ID: Date: Wed, 6 Dec 2006 09:40:50 +0100 From: "Franck Bui-Huu" To: "Ralf Baechle" , "Atsushi Nemoto" Subject: Re: [PATCH] Import updates from i386's i8259.c Cc: linux-mips@linux-mips.org In-Reply-To: <20061205195702.GA2097@linux-mips.org> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <20061206.012311.86891097.anemo@mba.ocn.ne.jp> <20061205194907.GA1088@linux-mips.org> <20061205195702.GA2097@linux-mips.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: 13365 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 On 12/5/06, Ralf Baechle wrote: > On Tue, Dec 05, 2006 at 07:49:07PM +0000, Ralf Baechle wrote: > > > > Import many updates from i386's i8259.c, especially genirq > > > transitions. > > > > With this patch applied Malta fails ... > > Which meant I removed this patch from my tree for now. Which means nothing > is blocking Franck's patch anymore so I applied it with a trivial build fix > to irq_cpu.c. > Thanks ! Except the mips_mt_cpu_irq_controller have not used flow handler yet as Astushi already reported. Atsushi, could you take care of removing "select GENERIC_HARDIRQS_NO__DO_IRQ" in your patch where needed ? specially all boards based on NEC VR41XX cpu. thanks -- Franck From sshtylyov@ru.mvista.com Wed Dec 6 12:58:07 2006 Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 06 Dec 2006 12:58:12 +0000 (GMT) Received: from h155.mvista.com ([63.81.120.155]:47199 "EHLO imap.sh.mvista.com") by ftp.linux-mips.org with ESMTP id S20037869AbWLFM6H (ORCPT ); Wed, 6 Dec 2006 12:58:07 +0000 Received: from [192.168.1.248] (unknown [10.150.0.9]) by imap.sh.mvista.com (Postfix) with ESMTP id 8B0733EC9; Wed, 6 Dec 2006 04:58:01 -0800 (PST) Message-ID: <4576BEBA.6080702@ru.mvista.com> Date: Wed, 06 Dec 2006 15:59:38 +0300 From: Sergei Shtylyov Organization: MontaVista Software Inc. User-Agent: Mozilla/5.0 (X11; U; Linux i686; rv:1.7.2) Gecko/20040803 X-Accept-Language: ru, en-us, en-gb MIME-Version: 1.0 To: ashlesha@kenati.com Cc: linux-mips@linux-mips.org Subject: Re: serial console: platform_device References: <1165346639.6871.19.camel@sandbar.kenati.com> <4575CBB6.8030804@ru.mvista.com> <1165351710.6871.34.camel@sandbar.kenati.com> <4575DABF.2000604@ru.mvista.com> <1165365058.6871.54.camel@sandbar.kenati.com> In-Reply-To: <1165365058.6871.54.camel@sandbar.kenati.com> Content-Type: text/plain; charset=us-ascii; 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: 13366 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: sshtylyov@ru.mvista.com Precedence: bulk X-list: linux-mips Hello. Ashlesha Shintre wrote: >> Ah, I forgot to mention that if your UART is a part of the south bridge, >>its IRQ number is _4_ on the integrated 8259 interrupt controller. I'm sure >>that AU1000_GPIO_0 is the cascaded interrupt request from 8259, not the UART's >>own IRQ... >>>>static struct plat_serial8250_port encm3_via_uart_data[] = { >>>> { >>>> .mapbase = 0x3f8, >>>> .irq = AU1000_GPIO_0, >> So, this is wrong. You need to specify to what platform IRQ 8259's IRQ4 >>gets routed here. > I m not sure what you mean here -- the AU1000_GPIO_0 is the cascaded > interrupt request from the 8259 on the VIA Southbridge -- I meant that the UART interrupts from the south bridge *cannot* be delivered *directly* to the Alchemy's embedded interrupt controller), so AU1000_GPIO_0 must be used to deliver all the interrupts from 8259 (the interrupt controller integrated into the south bridge) to the embedded interrupt controller. So, you need to setup some kind of the cascading interrupt handler for AU1000_GPIO_0 to read the vector from 8259 I think... > Best Regards, > Ashlesha. WBR, Sergei From sshtylyov@ru.mvista.com Wed Dec 6 13:15:54 2006 Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 06 Dec 2006 13:15:58 +0000 (GMT) Received: from h155.mvista.com ([63.81.120.155]:62047 "EHLO imap.sh.mvista.com") by ftp.linux-mips.org with ESMTP id S20038409AbWLFNPy (ORCPT ); Wed, 6 Dec 2006 13:15:54 +0000 Received: from [192.168.1.248] (unknown [10.150.0.9]) by imap.sh.mvista.com (Postfix) with ESMTP id BD6FD3EC9; Wed, 6 Dec 2006 05:15:51 -0800 (PST) Message-ID: <4576C2E9.4060900@ru.mvista.com> Date: Wed, 06 Dec 2006 16:17:29 +0300 From: Sergei Shtylyov Organization: MontaVista Software Inc. User-Agent: Mozilla/5.0 (X11; U; Linux i686; rv:1.7.2) Gecko/20040803 X-Accept-Language: ru, en-us, en-gb MIME-Version: 1.0 To: anemo@mba.sphere.ne.jp Cc: ralf@linux-mips.org, linux-mips@linux-mips.org Subject: Re: [PATCH] Import updates from i386's i8259.c References: <20061206.103923.71086192.nemoto@toshiba-tops.co.jp> <20061206015818.GB27985@linux-mips.org> <20061206.115602.63741871.nemoto@toshiba-tops.co.jp> <20061206.133836.89067271.nemoto@toshiba-tops.co.jp> In-Reply-To: <20061206.133836.89067271.nemoto@toshiba-tops.co.jp> Content-Type: text/plain; charset=us-ascii; 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: 13367 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: sshtylyov@ru.mvista.com Precedence: bulk X-list: linux-mips Hello. anemo@mba.sphere.ne.jp wrote: > Import many updates from i386's i8259.c, especially genirq > transitions. > Signed-off-by: Atsushi Nemoto > --- > diff --git a/arch/mips/kernel/i8259.c b/arch/mips/kernel/i8259.c > index 2526c0c..85ca2a9 100644 > --- a/arch/mips/kernel/i8259.c > +++ b/arch/mips/kernel/i8259.c [...] > @@ -31,23 +28,16 @@ void disable_8259A_irq(unsigned int irq) > * moves to arch independent land > */ > > +static int i8259A_auto_eoi; > DEFINE_SPINLOCK(i8259A_lock); > - > -static void end_8259A_irq (unsigned int irq) > -{ > - if (!(irq_desc[irq].status & (IRQ_DISABLED|IRQ_INPROGRESS)) && > - irq_desc[irq].action) > - enable_8259A_irq(irq); > -} > - > +/* some platforms call this... */ > void mask_and_ack_8259A(unsigned int); > > -static struct irq_chip i8259A_irq_type = { > - .typename = "XT-PIC", > - .enable = enable_8259A_irq, > - .disable = disable_8259A_irq, > - .ack = mask_and_ack_8259A, > - .end = end_8259A_irq, > +static struct irq_chip i8259A_chip = { > + .name = "XT-PIC", > + .mask = disable_8259A_irq, > + .unmask = enable_8259A_irq, > + .mask_ack = mask_and_ack_8259A, > }; I wonder whose idea was to call this device XT-PIC. XT never had dual 8259A PICs and so was capable of handling only 8 IRQs. Dual 8259A was first used in the AT class machines... > @@ -84,23 +74,23 @@ void enable_8259A_irq(unsigned int irq) > spin_lock_irqsave(&i8259A_lock, flags); > cached_irq_mask &= mask; > if (irq & 8) > - outb(cached_A1,0xA1); > + outb(cached_slave_mask, PIC_SLAVE_IMR); > else > - outb(cached_21,0x21); > + outb(cached_master_mask, PIC_MASTER_IMR); > spin_unlock_irqrestore(&i8259A_lock, flags); > } > > int i8259A_irq_pending(unsigned int irq) > { > - unsigned int mask = 1 << irq; > + unsigned int mask = 1< @@ -109,7 +99,8 @@ int i8259A_irq_pending(unsigned int irq) > void make_8259A_irq(unsigned int irq) > { > disable_irq_nosync(irq); > - set_irq_chip(irq, &i8259A_irq_type); > + set_irq_chip_and_handler_name(irq, &i8259A_chip, handle_level_irq, > + "XT"); No! Do not evoke the memory of XT anymore, let it rest in peace at last! Call it 8259A, please. > @@ -122,17 +113,17 @@ void make_8259A_irq(unsigned int irq) > static inline int i8259A_irq_real(unsigned int irq) > { > int value; > - int irqmask = 1 << irq; > + int irqmask = 1< @@ -214,15 +207,52 @@ spurious_8259A_irq: > } > } > > +static char irq_trigger[2]; > +/** > + * ELCR registers (0x4d0, 0x4d1) control edge/level of IRQ > + */ > +static void restore_ELCR(char *trigger) > +{ > + outb(trigger[0], 0x4d0); > + outb(trigger[1], 0x4d1); > +} > + > +static void save_ELCR(char *trigger) > +{ > + /* IRQ 0,1,2,8,13 are marked as reserved */ > + trigger[0] = inb(0x4d0) & 0xF8; > + trigger[1] = inb(0x4d1) & 0xDE; Erm, the bits should be zero, why mask them out I wonder... WBR, Sergei From ralf@linux-mips.org Wed Dec 6 13:44:22 2006 Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 06 Dec 2006 13:44:24 +0000 (GMT) Received: from localhost.localdomain ([127.0.0.1]:26332 "EHLO dl5rb.ham-radio-op.net") by ftp.linux-mips.org with ESMTP id S20037869AbWLFNoW (ORCPT ); Wed, 6 Dec 2006 13:44:22 +0000 Received: from denk.linux-mips.net (denk.linux-mips.net [127.0.0.1]) by dl5rb.ham-radio-op.net (8.13.8/8.13.8) with ESMTP id kB6C7IgE013773; Wed, 6 Dec 2006 12:09:58 GMT Received: (from ralf@localhost) by denk.linux-mips.net (8.13.8/8.13.8/Submit) id kB6C7HiL013772; Wed, 6 Dec 2006 12:07:17 GMT Date: Wed, 6 Dec 2006 12:07:17 +0000 From: Ralf Baechle To: Atsushi Nemoto Cc: linux-mips@linux-mips.org Subject: Re: [PATCH] Import updates from i386's i8259.c Message-ID: <20061206120717.GA13744@linux-mips.org> References: <20061205195702.GA2097@linux-mips.org> <20061206.103923.71086192.nemoto@toshiba-tops.co.jp> <20061206015818.GB27985@linux-mips.org> <20061206.115602.63741871.nemoto@toshiba-tops.co.jp> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20061206.115602.63741871.nemoto@toshiba-tops.co.jp> User-Agent: Mutt/1.4.2.2i 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: 13368 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, Dec 06, 2006 at 11:56:02AM +0900, Atsushi Nemoto wrote: > Date: Wed, 06 Dec 2006 11:56:02 +0900 (JST) > To: ralf@linux-mips.org > Cc: linux-mips@linux-mips.org > Subject: Re: [PATCH] Import updates from i386's i8259.c > From: Atsushi Nemoto > Content-Type: Text/Plain; charset=us-ascii > > On Wed, 6 Dec 2006 01:58:18 +0000, Ralf Baechle wrote: > > There are some other issues with the legacy IDE on the Intel PIIX which > > likely affect other systems such as Alpha as well. I think I solved that > > so it's now time to tackle the IRQ stuff. Even without your i8259 stuff > > there are some strange things going on currently: > > > > [...] > > irq 7, desc: 803db360, depth: 1, count: 0, unhandled: 0 > > ->handle_irq(): 8014ff28, handle_bad_irq+0x0/0x318 > > ->chip(): 803a3d4c, 0x803a3d4c > > ->action(): 00000000 > > IRQ_DISABLED set > > unexpected IRQ # 7 > > Hmm ... malta_int.c:get_int() returned 7? I have no idea, but it > seems mips_irq_lock in malta_int.c can be replaced by i8259A_lock... Your new patch works and also resolves this issue. Ralf From macro@linux-mips.org Wed Dec 6 13:48:07 2006 Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 06 Dec 2006 13:48:13 +0000 (GMT) Received: from pollux.ds.pg.gda.pl ([153.19.208.7]:37392 "EHLO pollux.ds.pg.gda.pl") by ftp.linux-mips.org with ESMTP id S20038415AbWLFNsH (ORCPT ); Wed, 6 Dec 2006 13:48:07 +0000 Received: from localhost (localhost [127.0.0.1]) by pollux.ds.pg.gda.pl (Postfix) with ESMTP id 5DCA6F5943; Wed, 6 Dec 2006 14:47:56 +0100 (CET) X-Virus-Scanned: by amavisd-new at pollux.ds.pg.gda.pl Received: from pollux.ds.pg.gda.pl ([127.0.0.1]) by localhost (pollux.ds.pg.gda.pl [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xaEEcnmOqxhs; Wed, 6 Dec 2006 14:47:56 +0100 (CET) Received: from piorun.ds.pg.gda.pl (piorun.ds.pg.gda.pl [153.19.208.8]) by pollux.ds.pg.gda.pl (Postfix) with ESMTP id F02A7E1C88; Wed, 6 Dec 2006 14:47:55 +0100 (CET) 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 kB6Dm5rl014046; Wed, 6 Dec 2006 14:48:05 +0100 Date: Wed, 6 Dec 2006 13:48:02 +0000 (GMT) From: "Maciej W. Rozycki" To: Sergei Shtylyov cc: Ingo Molnar , anemo@mba.sphere.ne.jp, Ralf Baechle , linux-mips@linux-mips.org Subject: Re: [PATCH] Import updates from i386's i8259.c In-Reply-To: <4576C2E9.4060900@ru.mvista.com> Message-ID: References: <20061206.103923.71086192.nemoto@toshiba-tops.co.jp> <20061206015818.GB27985@linux-mips.org> <20061206.115602.63741871.nemoto@toshiba-tops.co.jp> <20061206.133836.89067271.nemoto@toshiba-tops.co.jp> <4576C2E9.4060900@ru.mvista.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: ClamAV 0.88.6/2292/Wed Dec 6 12:00:54 2006 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: 13369 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, 6 Dec 2006, Sergei Shtylyov wrote: > > +static struct irq_chip i8259A_chip = { > > + .name = "XT-PIC", > > + .mask = disable_8259A_irq, > > + .unmask = enable_8259A_irq, > > + .mask_ack = mask_and_ack_8259A, > > }; > > I wonder whose idea was to call this device XT-PIC. XT never had dual 8259A > PICs and so was capable of handling only 8 IRQs. Dual 8259A was first used in > the AT class machines... Ask Ingo, perhaps... ;-) I think he was perfectly right, though -- this is a pair of PC/XT-class PICs. And with the "IO-APIC-edge" and "IO-APIC-level" alternatives back when the concept of IRQ controllers was introduced, "XT-PIC" rather than "8259A" sounded quite right. Maciej From sshtylyov@ru.mvista.com Wed Dec 6 13:52:07 2006 Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 06 Dec 2006 13:52:11 +0000 (GMT) Received: from h155.mvista.com ([63.81.120.155]:30048 "EHLO imap.sh.mvista.com") by ftp.linux-mips.org with ESMTP id S20038486AbWLFNwH (ORCPT ); Wed, 6 Dec 2006 13:52:07 +0000 Received: from [192.168.1.248] (unknown [10.150.0.9]) by imap.sh.mvista.com (Postfix) with ESMTP id 3E28F3EC9; Wed, 6 Dec 2006 05:52:02 -0800 (PST) Message-ID: <4576CB64.2060705@ru.mvista.com> Date: Wed, 06 Dec 2006 16:53:40 +0300 From: Sergei Shtylyov Organization: MontaVista Software Inc. User-Agent: Mozilla/5.0 (X11; U; Linux i686; rv:1.7.2) Gecko/20040803 X-Accept-Language: ru, en-us, en-gb MIME-Version: 1.0 To: "Maciej W. Rozycki" Cc: Ingo Molnar , anemo@mba.sphere.ne.jp, Ralf Baechle , linux-mips@linux-mips.org Subject: Re: [PATCH] Import updates from i386's i8259.c References: <20061206.103923.71086192.nemoto@toshiba-tops.co.jp> <20061206015818.GB27985@linux-mips.org> <20061206.115602.63741871.nemoto@toshiba-tops.co.jp> <20061206.133836.89067271.nemoto@toshiba-tops.co.jp> <4576C2E9.4060900@ru.mvista.com> In-Reply-To: Content-Type: text/plain; charset=us-ascii; 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: 13370 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: sshtylyov@ru.mvista.com Precedence: bulk X-list: linux-mips Hello. Maciej W. Rozycki wrote: >>>+static struct irq_chip i8259A_chip = { >>>+ .name = "XT-PIC", >>>+ .mask = disable_8259A_irq, >>>+ .unmask = enable_8259A_irq, >>>+ .mask_ack = mask_and_ack_8259A, >>> }; >> I wonder whose idea was to call this device XT-PIC. XT never had dual 8259A >>PICs and so was capable of handling only 8 IRQs. Dual 8259A was first used in >>the AT class machines... > Ask Ingo, perhaps... ;-) Ask and be ignored. :-) > I think he was perfectly right, though -- this > is a pair of PC/XT-class PICs. Coupled as only in PC/AT-class machines. So, this XT qualification is actually meaningless. It's 8259A, that's all. > And with the "IO-APIC-edge" and > "IO-APIC-level" alternatives back when the concept of IRQ controllers was > introduced, "XT-PIC" rather than "8259A" sounded quite right. I don't follow you here. > Maciej WBR, Sergei From macro@linux-mips.org Wed Dec 6 14:41:54 2006 Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 06 Dec 2006 14:41:59 +0000 (GMT) Received: from pollux.ds.pg.gda.pl ([153.19.208.7]:63505 "EHLO pollux.ds.pg.gda.pl") by ftp.linux-mips.org with ESMTP id S20037666AbWLFOly (ORCPT ); Wed, 6 Dec 2006 14:41:54 +0000 Received: from localhost (localhost [127.0.0.1]) by pollux.ds.pg.gda.pl (Postfix) with ESMTP id 275A9E1CA2; Wed, 6 Dec 2006 15:41:40 +0100 (CET) X-Virus-Scanned: by amavisd-new at pollux.ds.pg.gda.pl Received: from pollux.ds.pg.gda.pl ([127.0.0.1]) by localhost (pollux.ds.pg.gda.pl [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eeFBNBYiwd8R; Wed, 6 Dec 2006 15:41:39 +0100 (CET) Received: from piorun.ds.pg.gda.pl (piorun.ds.pg.gda.pl [153.19.208.8]) by pollux.ds.pg.gda.pl (Postfix) with ESMTP id B0A6DE1C92; Wed, 6 Dec 2006 15:41:39 +0100 (CET) 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 kB6EfmwI000655; Wed, 6 Dec 2006 15:41:49 +0100 Date: Wed, 6 Dec 2006 14:41:45 +0000 (GMT) From: "Maciej W. Rozycki" To: Sergei Shtylyov cc: Ingo Molnar , anemo@mba.sphere.ne.jp, Ralf Baechle , linux-mips@linux-mips.org Subject: Re: [PATCH] Import updates from i386's i8259.c In-Reply-To: <4576CB64.2060705@ru.mvista.com> Message-ID: References: <20061206.103923.71086192.nemoto@toshiba-tops.co.jp> <20061206015818.GB27985@linux-mips.org> <20061206.115602.63741871.nemoto@toshiba-tops.co.jp> <20061206.133836.89067271.nemoto@toshiba-tops.co.jp> <4576C2E9.4060900@ru.mvista.com> <4576CB64.2060705@ru.mvista.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: ClamAV 0.88.6/2292/Wed Dec 6 12:00:54 2006 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: 13371 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, 6 Dec 2006, Sergei Shtylyov wrote: > > And with the "IO-APIC-edge" and "IO-APIC-level" alternatives back when the > > concept of IRQ controllers was introduced, "XT-PIC" rather than "8259A" > > sounded quite right. > > I don't follow you here. These were the three first names of interrupt controllers introduced back in 2.1 and the names chosen looked consistent. Maciej From sshtylyov@ru.mvista.com Wed Dec 6 15:11:09 2006 Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 06 Dec 2006 15:11:13 +0000 (GMT) Received: from h155.mvista.com ([63.81.120.155]:45409 "EHLO imap.sh.mvista.com") by ftp.linux-mips.org with ESMTP id S20038415AbWLFPLJ (ORCPT ); Wed, 6 Dec 2006 15:11:09 +0000 Received: from [192.168.1.248] (unknown [10.150.0.9]) by imap.sh.mvista.com (Postfix) with ESMTP id 4EE933EC9; Wed, 6 Dec 2006 07:11:06 -0800 (PST) Message-ID: <4576DDEC.1050105@ru.mvista.com> Date: Wed, 06 Dec 2006 18:12:44 +0300 From: Sergei Shtylyov Organization: MontaVista Software Inc. User-Agent: Mozilla/5.0 (X11; U; Linux i686; rv:1.7.2) Gecko/20040803 X-Accept-Language: ru, en-us, en-gb MIME-Version: 1.0 To: "Maciej W. Rozycki" Cc: Ingo Molnar , anemo@mba.sphere.ne.jp, Ralf Baechle , linux-mips@linux-mips.org Subject: Re: [PATCH] Import updates from i386's i8259.c References: <20061206.103923.71086192.nemoto@toshiba-tops.co.jp> <20061206015818.GB27985@linux-mips.org> <20061206.115602.63741871.nemoto@toshiba-tops.co.jp> <20061206.133836.89067271.nemoto@toshiba-tops.co.jp> <4576C2E9.4060900@ru.mvista.com> <4576CB64.2060705@ru.mvista.com> In-Reply-To: Content-Type: text/plain; charset=us-ascii; 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: 13372 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: sshtylyov@ru.mvista.com Precedence: bulk X-list: linux-mips Hello. Maciej W. Rozycki wrote: >>>And with the "IO-APIC-edge" and "IO-APIC-level" alternatives back when the >>>concept of IRQ controllers was introduced, "XT-PIC" rather than "8259A" >>>sounded quite right. >> I don't follow you here. > These were the three first names of interrupt controllers introduced back > in 2.1 and the names chosen looked consistent. I'd say they *only* looked consistent then. :-) In fact, i8259.c is driving two coupled together 8259 chips, so using the word "XT" in this context was absolutely wrong. As for the I/O APIC, I think i82903AA was "the reference design" for it... > Maciej WBR, Sergei From macro@linux-mips.org Wed Dec 6 15:43:21 2006 Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 06 Dec 2006 15:43:26 +0000 (GMT) Received: from pollux.ds.pg.gda.pl ([153.19.208.7]:38670 "EHLO pollux.ds.pg.gda.pl") by ftp.linux-mips.org with ESMTP id S20037960AbWLFPnV (ORCPT ); Wed, 6 Dec 2006 15:43:21 +0000 Received: from localhost (localhost [127.0.0.1]) by pollux.ds.pg.gda.pl (Postfix) with ESMTP id 3CADCF5965; Wed, 6 Dec 2006 16:43:06 +0100 (CET) X-Virus-Scanned: by amavisd-new at pollux.ds.pg.gda.pl Received: from pollux.ds.pg.gda.pl ([127.0.0.1]) by localhost (pollux.ds.pg.gda.pl [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8IRYCnkrxC8w; Wed, 6 Dec 2006 16:43:05 +0100 (CET) Received: from piorun.ds.pg.gda.pl (piorun.ds.pg.gda.pl [153.19.208.8]) by pollux.ds.pg.gda.pl (Postfix) with ESMTP id C3633F5964; Wed, 6 Dec 2006 16:43:05 +0100 (CET) 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 kB6FhGaN024482; Wed, 6 Dec 2006 16:43:17 +0100 Date: Wed, 6 Dec 2006 15:43:12 +0000 (GMT) From: "Maciej W. Rozycki" To: Sergei Shtylyov cc: Ingo Molnar , anemo@mba.sphere.ne.jp, Ralf Baechle , linux-mips@linux-mips.org Subject: Re: [PATCH] Import updates from i386's i8259.c In-Reply-To: <4576DDEC.1050105@ru.mvista.com> Message-ID: References: <20061206.103923.71086192.nemoto@toshiba-tops.co.jp> <20061206015818.GB27985@linux-mips.org> <20061206.115602.63741871.nemoto@toshiba-tops.co.jp> <20061206.133836.89067271.nemoto@toshiba-tops.co.jp> <4576C2E9.4060900@ru.mvista.com> <4576CB64.2060705@ru.mvista.com> <4576DDEC.1050105@ru.mvista.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: ClamAV 0.88.6/2293/Wed Dec 6 15:00:31 2006 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: 13373 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, 6 Dec 2006, Sergei Shtylyov wrote: > I'd say they *only* looked consistent then. :-) Some user tools may rely on certain strings seen in /proc/interrupts ("procinfo"?). > As for the I/O APIC, I think i82903AA was "the reference design" for it... Nope, it was the i82489DX -- the original "discrete" coupled Local & I/O APIC using a five-wire inter-APIC bus and a protocol different from later implementations. Then there were ones included in the i82379AB (SIO.A) and i82374EB/SB (ESC) chipset components. They used a three-wire bus and a new protocol. And only then came the i82093AA. Maciej From vagabon.xyz@gmail.com Wed Dec 6 15:47:07 2006 Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 06 Dec 2006 15:47:12 +0000 (GMT) Received: from nf-out-0910.google.com ([64.233.182.185]:15474 "EHLO nf-out-0910.google.com") by ftp.linux-mips.org with ESMTP id S20038252AbWLFPrH (ORCPT ); Wed, 6 Dec 2006 15:47:07 +0000 Received: by nf-out-0910.google.com with SMTP id l24so555907nfc for ; Wed, 06 Dec 2006 07:47:07 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:to:cc:subject:date:message-id:x-mailer:from; b=lA7ebdCXY8iZQIaryLRr8Nbkc7lE8Lo2beY2O48JPrPP1EUQRzjvYWQRNr6BcHq8bUkRTy+ygo7Ks4JgzQO7OUI9Wbo8sdy24wkzWd5iqtBjrPfJv8vyTmeCb+CqiRfjaMv2/DLQCz8gqnMitIaezluGtBu1IH/hYz/ppFhsAbM= Received: by 10.49.91.6 with SMTP id t6mr2378148nfl.1165420026786; Wed, 06 Dec 2006 07:47:06 -0800 (PST) Received: from spoutnik.innova-card.com ( [81.252.61.1]) by mx.google.com with ESMTP id m16sm2290260nfc.2006.12.06.07.47.06; Wed, 06 Dec 2006 07:47:06 -0800 (PST) Received: by spoutnik.innova-card.com (Postfix, from userid 500) id 7470E23F76E; Wed, 6 Dec 2006 16:48:30 +0100 (CET) To: ralf@linux-mips.org Cc: linux-mips@linux-mips.org Subject: [RFC] FLATMEM: allow memory to start at pfn != 0 Date: Wed, 6 Dec 2006 16:48:27 +0100 Message-Id: <1165420110699-git-send-email-fbuihuu@gmail.com> X-Mailer: git-send-email 1.4.4.1 From: Franck Bui-Huu 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: 13374 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 patchset relaxes this constraint. Basically you just need to define in your platform code (include/asm-mips/mach-foo/spaces.h probably) PHYS_OFFSET that corresponds to the start of your physical memory and you're done. The first patch is just a fix for HIGHMEM, I just found it while writing this patchset. I haven't done any tests though, I have no hardwares to play with. The second and third patchs are the real meat. There are 2 points that I'm not really sure: - PHYS_OFFSET is defined in page.h, I'm not sure if it's the right place though. - ARCH_PFN_OFFSET is always defined whatever the memory model. I don't think it will hurt since physical memory always has a starting point in all cases. Please consider. Franck --- arch/mips/kernel/setup.c | 30 ++++++++++++++++++++++-------- arch/mips/mm/init.c | 30 +++++++++++++----------------- include/asm-mips/dma.h | 1 + include/asm-mips/io.h | 4 ++-- include/asm-mips/page.h | 25 +++++++++++++++++++++---- 5 files changed, 59 insertions(+), 31 deletions(-) From vagabon.xyz@gmail.com Wed Dec 6 15:47:35 2006 Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 06 Dec 2006 15:47:38 +0000 (GMT) Received: from nf-out-0910.google.com ([64.233.182.188]:60785 "EHLO nf-out-0910.google.com") by ftp.linux-mips.org with ESMTP id S20038251AbWLFPrH (ORCPT ); Wed, 6 Dec 2006 15:47:07 +0000 Received: by nf-out-0910.google.com with SMTP id l24so555905nfc for ; Wed, 06 Dec 2006 07:47:07 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:to:cc:subject:date:message-id:x-mailer:in-reply-to:references:from; b=VfS5aX0aaQoGY/hpVIE3oOE9AtbfHp7yWeK4tQ+/wDaT99i+b/x4SBcP6kwd2tvQZ4v8na5VwD2qfCyn7TZ2QY8a7ohcYvDeCNjrd51o253jnzcHYo5TGcCzQ9ShYzqwUPiAP6YD1yiFvfm5L19xdfjy0BNJLUMnzUFvaZWwU3Y= Received: by 10.48.162.12 with SMTP id k12mr2382706nfe.1165420026965; Wed, 06 Dec 2006 07:47:06 -0800 (PST) Received: from spoutnik.innova-card.com ( [81.252.61.1]) by mx.google.com with ESMTP id c10sm2295679nfb.2006.12.06.07.47.06; Wed, 06 Dec 2006 07:47:06 -0800 (PST) Received: by spoutnik.innova-card.com (Postfix, from userid 500) id BE0A523F76A; Wed, 6 Dec 2006 16:48:30 +0100 (CET) To: ralf@linux-mips.org Cc: linux-mips@linux-mips.org, Franck Bui-Huu Subject: [PATCH 2/3] Setup min_low_pfn/max_low_pfn correctly Date: Wed, 6 Dec 2006 16:48:29 +0100 Message-Id: <11654201103291-git-send-email-fbuihuu@gmail.com> X-Mailer: git-send-email 1.4.4.1 In-Reply-To: <1165420110699-git-send-email-fbuihuu@gmail.com> References: <1165420110699-git-send-email-fbuihuu@gmail.com> From: Franck Bui-Huu 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: 13375 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 From: Franck Bui-Huu The old code was assuming that min_low_pfn was always 0. This means that we can't handle platforms with a big hole at start of memory since mem_map[] size would blew up. This patch does not relax this constraint but it's a first step to achieve that. Signed-off-by: Franck Bui-Huu --- arch/mips/kernel/setup.c | 27 +++++++++++++++++++-------- arch/mips/mm/init.c | 15 ++++++--------- include/asm-mips/dma.h | 1 + 3 files changed, 26 insertions(+), 17 deletions(-) diff --git a/arch/mips/kernel/setup.c b/arch/mips/kernel/setup.c index 89440a0..8e58d7f 100644 --- a/arch/mips/kernel/setup.c +++ b/arch/mips/kernel/setup.c @@ -271,7 +271,6 @@ static void __init bootmem_init(void) static void __init bootmem_init(void) { unsigned long reserved_end; - unsigned long highest = 0; unsigned long mapstart = -1UL; unsigned long bootmap_size; int i; @@ -284,6 +283,13 @@ static void __init bootmem_init(void) reserved_end = max(init_initrd(), PFN_UP(__pa_symbol(&_end))); /* + * max_low_pfn is not a number of pages. The number of pages + * of the system is given by 'max_low_pfn - min_low_pfn'. + */ + min_low_pfn = -1UL; + max_low_pfn = 0; + + /* * Find the highest page frame number we have available. */ for (i = 0; i < boot_mem_map.nr_map; i++) { @@ -296,8 +302,10 @@ static void __init bootmem_init(void) end = PFN_DOWN(boot_mem_map.map[i].addr + boot_mem_map.map[i].size); - if (end > highest) - highest = end; + if (end > max_low_pfn) + max_low_pfn = end; + if (start < min_low_pfn) + min_low_pfn = start; if (end <= reserved_end) continue; if (start >= mapstart) @@ -305,22 +313,25 @@ static void __init bootmem_init(void) mapstart = max(reserved_end, start); } + if (min_low_pfn >= max_low_pfn) + panic("Boggus memory mapping !!!"); + /* * Determine low and high memory ranges */ - if (highest > PFN_DOWN(HIGHMEM_START)) { + if (max_low_pfn > PFN_DOWN(HIGHMEM_START)) { #ifdef CONFIG_HIGHMEM highstart_pfn = PFN_DOWN(HIGHMEM_START); - highend_pfn = highest; + highend_pfn = max_low_pfn; #endif - highest = PFN_DOWN(HIGHMEM_START); + max_low_pfn = PFN_DOWN(HIGHMEM_START); } /* * Initialize the boot-time allocator with low memory only. */ - bootmap_size = init_bootmem(mapstart, highest); - + bootmap_size = init_bootmem_node(NODE_DATA(0), mapstart, + min_low_pfn, max_low_pfn); /* * Register fully available low RAM pages with the bootmem allocator. */ diff --git a/arch/mips/mm/init.c b/arch/mips/mm/init.c index 30245c0..e78a1b1 100644 --- a/arch/mips/mm/init.c +++ b/arch/mips/mm/init.c @@ -341,7 +341,6 @@ static int __init page_is_ram(unsigned l void __init paging_init(void) { unsigned long zones_size[MAX_NR_ZONES] = { 0, }; - unsigned long max_dma, low; #ifndef CONFIG_FLATMEM unsigned long zholes_size[MAX_NR_ZONES] = { 0, }; unsigned long i, j, pfn; @@ -354,18 +353,16 @@ void __init paging_init(void) #endif kmap_coherent_init(); - max_dma = virt_to_phys((char *)MAX_DMA_ADDRESS) >> PAGE_SHIFT; - low = max_low_pfn; - #ifdef CONFIG_ISA - if (low < max_dma) - zones_size[ZONE_DMA] = low; + if (max_low_pfn < MAX_DMA_PFN) + zones_size[ZONE_DMA] = max_low_pfn; else { - zones_size[ZONE_DMA] = max_dma; - zones_size[ZONE_NORMAL] = low - max_dma; + unsigned long start_normal_zone = max(min_low_pfn, MAX_DMA_PFN); + zones_size[ZONE_DMA] = MAX_DMA_PFN; + zones_size[ZONE_NORMAL] = max_low_pfn - start_normal_zone; } #else - zones_size[ZONE_DMA] = low; + zones_size[ZONE_DMA] = max_low_pfn - min_low_pfn; #endif #ifdef CONFIG_HIGHMEM zones_size[ZONE_HIGHMEM] = highend_pfn - highstart_pfn; diff --git a/include/asm-mips/dma.h b/include/asm-mips/dma.h index 23f789c..e06ef07 100644 --- a/include/asm-mips/dma.h +++ b/include/asm-mips/dma.h @@ -91,6 +91,7 @@ #else #define MAX_DMA_ADDRESS (PAGE_OFFSET + 0x01000000) #endif +#define MAX_DMA_PFN PFN_DOWN(virt_to_phys((void *)MAX_DMA_ADDRESS)) /* 8237 DMA controllers */ #define IO_DMA1_BASE 0x00 /* 8 bit slave DMA, channels 0..3 */ -- 1.4.4.1 From vagabon.xyz@gmail.com Wed Dec 6 15:48:02 2006 Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 06 Dec 2006 15:48:07 +0000 (GMT) Received: from nf-out-0910.google.com ([64.233.182.191]:41844 "EHLO nf-out-0910.google.com") by ftp.linux-mips.org with ESMTP id S20038329AbWLFPrH (ORCPT ); Wed, 6 Dec 2006 15:47:07 +0000 Received: by nf-out-0910.google.com with SMTP id l24so555911nfc for ; Wed, 06 Dec 2006 07:47:07 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:to:cc:subject:date:message-id:x-mailer:in-reply-to:references:from; b=eQODzc4tJ7rlK8H6lq30Yr0psYD/FuOcydmvFooco+tx+SXFGXrsJsTQFMoIxRLENWw120lBeRhr1/cz5Du6IB+RA0ek9Q5YxNm7Fyb4XcOIje/RnXXcgOKrMRFmJ7yEvqHTkxlDk85OIfPFOmWnz29GuQWyi7GmhJQg0saWIrM= Received: by 10.49.20.15 with SMTP id x15mr2390435nfi.1165420027035; Wed, 06 Dec 2006 07:47:07 -0800 (PST) Received: from spoutnik.innova-card.com ( [81.252.61.1]) by mx.google.com with ESMTP id m15sm2266129nfc.2006.12.06.07.47.06; Wed, 06 Dec 2006 07:47:06 -0800 (PST) Received: by spoutnik.innova-card.com (Postfix, from userid 500) id E135A23F76F; Wed, 6 Dec 2006 16:48:30 +0100 (CET) To: ralf@linux-mips.org Cc: linux-mips@linux-mips.org, Franck Bui-Huu Subject: [PATCH 3/3] FLATMEM: allow memory to start at pfn != 0 Date: Wed, 6 Dec 2006 16:48:30 +0100 Message-Id: <11654201101967-git-send-email-fbuihuu@gmail.com> X-Mailer: git-send-email 1.4.4.1 In-Reply-To: <1165420110699-git-send-email-fbuihuu@gmail.com> References: <1165420110699-git-send-email-fbuihuu@gmail.com> From: Franck Bui-Huu 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: 13376 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 From: Franck Bui-Huu This patch introduces PHYS_OFFSET define which is the start of the physical memory and uses it wherever needed. Specially when converting physical/virtual addresses into virtual/physical ones. Currently all platforms defines PHYS_OFFSET to 0. Signed-off-by: Franck Bui-Huu --- arch/mips/kernel/setup.c | 3 +++ include/asm-mips/io.h | 4 ++-- include/asm-mips/page.h | 25 +++++++++++++++++++++---- 3 files changed, 26 insertions(+), 6 deletions(-) diff --git a/arch/mips/kernel/setup.c b/arch/mips/kernel/setup.c index 8e58d7f..46312c2 100644 --- a/arch/mips/kernel/setup.c +++ b/arch/mips/kernel/setup.c @@ -315,6 +315,9 @@ static void __init bootmem_init(void) if (min_low_pfn >= max_low_pfn) panic("Boggus memory mapping !!!"); + if (min_low_pfn != ARCH_PFN_OFFSET) + panic("PHYS_OFFSET(%lx) and your mem start(%lx) don't match", + PHYS_OFFSET, PFN_PHYS(min_low_pfn)); /* * Determine low and high memory ranges diff --git a/include/asm-mips/io.h b/include/asm-mips/io.h index 38d1399..e1592af 100644 --- a/include/asm-mips/io.h +++ b/include/asm-mips/io.h @@ -115,7 +115,7 @@ static inline void set_io_port_base(unsi */ static inline unsigned long virt_to_phys(volatile const void *address) { - return (unsigned long)address - PAGE_OFFSET; + return (unsigned long)address - PAGE_OFFSET + PHYS_OFFSET; } /* @@ -132,7 +132,7 @@ static inline unsigned long virt_to_phys */ static inline void * phys_to_virt(unsigned long address) { - return (void *)(address + PAGE_OFFSET); + return (void *)(address + PAGE_OFFSET - PHYS_OFFSET); } /* diff --git a/include/asm-mips/page.h b/include/asm-mips/page.h index 5c4284b..6894dc2 100644 --- a/include/asm-mips/page.h +++ b/include/asm-mips/page.h @@ -34,6 +34,20 @@ #ifndef __ASSEMBLY__ +/* + * This gives the physical RAM offset. + */ +#ifndef PHYS_OFFSET +#define PHYS_OFFSET 0UL +#endif + +/* + * It's normally defined only for FLATMEM config but it's + * used in our early mem init code for all memory models. + * So always define it. + */ +#define ARCH_PFN_OFFSET PFN_UP(PHYS_OFFSET) + #include #include #include @@ -133,20 +147,23 @@ typedef struct { unsigned long pgprot; } /* to align the pointer to the (next) page boundary */ #define PAGE_ALIGN(addr) (((addr) + PAGE_SIZE - 1) & PAGE_MASK) +/* + * __pa()/__va() should be used only during mem init. + */ #if defined(CONFIG_64BIT) && !defined(CONFIG_BUILD_ELF64) #define __pa_page_offset(x) ((unsigned long)(x) < CKSEG0 ? PAGE_OFFSET : CKSEG0) #else #define __pa_page_offset(x) PAGE_OFFSET #endif -#define __pa(x) ((unsigned long)(x) - __pa_page_offset(x)) -#define __pa_symbol(x) __pa(RELOC_HIDE((unsigned long)(x),0)) -#define __va(x) ((void *)((unsigned long)(x) + PAGE_OFFSET)) +#define __pa(x) ((unsigned long)(x) - __pa_page_offset(x) + PHYS_OFFSET) +#define __va(x) ((void *)((unsigned long)(x) + PAGE_OFFSET - PHYS_OFFSET)) +#define __pa_symbol(x) __pa(RELOC_HIDE((unsigned long)(x),0)) #define pfn_to_kaddr(pfn) __va((pfn) << PAGE_SHIFT) #ifdef CONFIG_FLATMEM -#define pfn_valid(pfn) ((pfn) < max_mapnr) +#define pfn_valid(pfn) ((pfn) >= ARCH_PFN_OFFSET && (pfn) < max_mapnr) #elif defined(CONFIG_SPARSEMEM) -- 1.4.4.1 From vagabon.xyz@gmail.com Wed Dec 6 15:48:30 2006 Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 06 Dec 2006 15:48:35 +0000 (GMT) Received: from nf-out-0910.google.com ([64.233.182.185]:15474 "EHLO nf-out-0910.google.com") by ftp.linux-mips.org with ESMTP id S20038486AbWLFPrI (ORCPT ); Wed, 6 Dec 2006 15:47:08 +0000 Received: by nf-out-0910.google.com with SMTP id l24so555907nfc for ; Wed, 06 Dec 2006 07:47:08 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:to:cc:subject:date:message-id:x-mailer:in-reply-to:references:from; b=qe03BI23PZnFQMoZ63XLQRF0RIRDhVDgIyGcy3JGSH1yJMKeeutse5OL2+OTg26WEBi+mJ9Qm9AccgUuc38qVBqOBw2W56nXwBfnrgMpyIEhh88hZG234yRNf9Feh+zkjbP42QPbLvPAPiZ8IiaLl7oNteoIgphFvB1VRXZCGLI= Received: by 10.48.254.10 with SMTP id b10mr2414826nfi.1165420026878; Wed, 06 Dec 2006 07:47:06 -0800 (PST) Received: from spoutnik.innova-card.com ( [81.252.61.1]) by mx.google.com with ESMTP id m16sm2290262nfc.2006.12.06.07.47.06; Wed, 06 Dec 2006 07:47:06 -0800 (PST) Received: by spoutnik.innova-card.com (Postfix, from userid 500) id 9CCEA23F759; Wed, 6 Dec 2006 16:48:30 +0100 (CET) To: ralf@linux-mips.org Cc: linux-mips@linux-mips.org, Franck Bui-Huu Subject: [PATCH 1/3] paging_init(): use highend_pfn/highstart_pfn Date: Wed, 6 Dec 2006 16:48:28 +0100 Message-Id: <11654201101028-git-send-email-fbuihuu@gmail.com> X-Mailer: git-send-email 1.4.4.1 In-Reply-To: <1165420110699-git-send-email-fbuihuu@gmail.com> References: <1165420110699-git-send-email-fbuihuu@gmail.com> From: Franck Bui-Huu 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: 13377 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 From: Franck Bui-Huu This patch makes paging_init() use highend_pfn/highstart_pfn globals. It removes the need of 'high' local which was needed only by HIGHMEM config. More important perhaps, it fixes a bug when HIGHMEM is set but there's actually no physical highmem (highend_pfn = 0) Signed-off-by: Franck Bui-Huu --- arch/mips/mm/init.c | 17 ++++++++--------- 1 files changed, 8 insertions(+), 9 deletions(-) diff --git a/arch/mips/mm/init.c b/arch/mips/mm/init.c index 1db991d..30245c0 100644 --- a/arch/mips/mm/init.c +++ b/arch/mips/mm/init.c @@ -341,7 +341,7 @@ static int __init page_is_ram(unsigned l void __init paging_init(void) { unsigned long zones_size[MAX_NR_ZONES] = { 0, }; - unsigned long max_dma, high, low; + unsigned long max_dma, low; #ifndef CONFIG_FLATMEM unsigned long zholes_size[MAX_NR_ZONES] = { 0, }; unsigned long i, j, pfn; @@ -356,7 +356,6 @@ void __init paging_init(void) max_dma = virt_to_phys((char *)MAX_DMA_ADDRESS) >> PAGE_SHIFT; low = max_low_pfn; - high = highend_pfn; #ifdef CONFIG_ISA if (low < max_dma) @@ -369,13 +368,13 @@ void __init paging_init(void) zones_size[ZONE_DMA] = low; #endif #ifdef CONFIG_HIGHMEM - if (cpu_has_dc_aliases) { - printk(KERN_WARNING "This processor doesn't support highmem."); - if (high - low) - printk(" %ldk highmem ignored", high - low); - printk("\n"); - } else - zones_size[ZONE_HIGHMEM] = high - low; + zones_size[ZONE_HIGHMEM] = highend_pfn - highstart_pfn; + + if (cpu_has_dc_aliases && zones_size[ZONE_HIGHMEM]) { + printk(KERN_WARNING "This processor doesn't support highmem." + " %ldk highmem ignored\n", zones_size[ZONE_HIGHMEM]); + zones_size[ZONE_HIGHMEM] = 0; + } #endif #ifdef CONFIG_FLATMEM -- 1.4.4.1 From sshtylyov@ru.mvista.com Wed Dec 6 15:48:58 2006 Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 06 Dec 2006 15:49:02 +0000 (GMT) Received: from h155.mvista.com ([63.81.120.155]:25698 "EHLO imap.sh.mvista.com") by ftp.linux-mips.org with ESMTP id S20038310AbWLFPrW (ORCPT ); Wed, 6 Dec 2006 15:47:22 +0000 Received: from [192.168.1.248] (unknown [10.150.0.9]) by imap.sh.mvista.com (Postfix) with ESMTP id 8F8A83EC9; Wed, 6 Dec 2006 07:47:18 -0800 (PST) Message-ID: <4576E666.1010502@ru.mvista.com> Date: Wed, 06 Dec 2006 18:48:54 +0300 From: Sergei Shtylyov Organization: MontaVista Software Inc. User-Agent: Mozilla/5.0 (X11; U; Linux i686; rv:1.7.2) Gecko/20040803 X-Accept-Language: ru, en-us, en-gb MIME-Version: 1.0 To: "Maciej W. Rozycki" Cc: Ingo Molnar , anemo@mba.sphere.ne.jp, Ralf Baechle , linux-mips@linux-mips.org Subject: Re: [PATCH] Import updates from i386's i8259.c References: <20061206.103923.71086192.nemoto@toshiba-tops.co.jp> <20061206015818.GB27985@linux-mips.org> <20061206.115602.63741871.nemoto@toshiba-tops.co.jp> <20061206.133836.89067271.nemoto@toshiba-tops.co.jp> <4576C2E9.4060900@ru.mvista.com> <4576CB64.2060705@ru.mvista.com> <4576DDEC.1050105@ru.mvista.com> In-Reply-To: Content-Type: text/plain; charset=us-ascii; 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: 13378 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: sshtylyov@ru.mvista.com Precedence: bulk X-list: linux-mips Hello. Maciej W. Rozycki wrote: >> As for the I/O APIC, I think i82903AA was "the reference design" for it... > Nope, it was the i82489DX -- the original "discrete" coupled Local & I/O > APIC using a five-wire inter-APIC bus and a protocol different from later > implementations. Hm, that's news to me. I always thought that chip was external *local* APIC only... Well, there's no docs on it anyway. > Then there were ones included in the i82379AB (SIO.A) > and i82374EB/SB (ESC) chipset components. They used a three-wire bus and > a new protocol. And only then came the i82093AA. Aha, you're probably correct here. I forgot about those early chipssets. > Maciej WBR, Sergei From anemo@mba.ocn.ne.jp Wed Dec 6 17:03:57 2006 Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 06 Dec 2006 17:04:02 +0000 (GMT) Received: from mba.ocn.ne.jp ([210.190.142.172]:1488 "HELO smtp.mba.ocn.ne.jp") by ftp.linux-mips.org with SMTP id S20038416AbWLFRD5 (ORCPT ); Wed, 6 Dec 2006 17:03:57 +0000 Received: from localhost (p6066-ipad209funabasi.chiba.ocn.ne.jp [58.88.117.66]) by smtp.mba.ocn.ne.jp (Postfix) with ESMTP id CD718B9A8; Thu, 7 Dec 2006 02:03:48 +0900 (JST) Date: Thu, 07 Dec 2006 02:03:48 +0900 (JST) Message-Id: <20061207.020348.25910403.anemo@mba.ocn.ne.jp> To: sshtylyov@ru.mvista.com Cc: ralf@linux-mips.org, linux-mips@linux-mips.org Subject: Re: [PATCH] Import updates from i386's i8259.c From: Atsushi Nemoto In-Reply-To: <4576C2E9.4060900@ru.mvista.com> References: <20061206.115602.63741871.nemoto@toshiba-tops.co.jp> <20061206.133836.89067271.nemoto@toshiba-tops.co.jp> <4576C2E9.4060900@ru.mvista.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 3.3 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: 13379 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 Wed, 06 Dec 2006 16:17:29 +0300, Sergei Shtylyov wrote: > > +static struct irq_chip i8259A_chip = { > > + .name = "XT-PIC", > > + .mask = disable_8259A_irq, > > + .unmask = enable_8259A_irq, > > + .mask_ack = mask_and_ack_8259A, > > }; > > I wonder whose idea was to call this device XT-PIC. XT never had dual > 8259A PICs and so was capable of handling only 8 IRQs. Dual 8259A was first > used in the AT class machines... It has been called "XT-PIC" anyway so I'd like to keep unchanged. > > { > > - unsigned int mask = 1 << irq; > > + unsigned int mask = 1< > Unnecassary, to say the least. > > > @@ -109,7 +99,8 @@ int i8259A_irq_pending(unsigned int irq) > > void make_8259A_irq(unsigned int irq) > > { > > disable_irq_nosync(irq); > > - set_irq_chip(irq, &i8259A_irq_type); > > + set_irq_chip_and_handler_name(irq, &i8259A_chip, handle_level_irq, > > + "XT"); > > No! Do not evoke the memory of XT anymore, let it rest in peace at last! > Call it 8259A, please. > > > @@ -122,17 +113,17 @@ void make_8259A_irq(unsigned int irq) > > static inline int i8259A_irq_real(unsigned int irq) > > { > > int value; > > - int irqmask = 1 << irq; > > + int irqmask = 1< > Unnecessary too. Well, these changes are due to synchronization with i386's code. I'll drop them. > > @@ -214,15 +207,52 @@ spurious_8259A_irq: > > } > > } > > > > +static char irq_trigger[2]; > > +/** > > + * ELCR registers (0x4d0, 0x4d1) control edge/level of IRQ > > + */ > > +static void restore_ELCR(char *trigger) > > +{ > > + outb(trigger[0], 0x4d0); > > + outb(trigger[1], 0x4d1); > > +} > > + > > +static void save_ELCR(char *trigger) > > +{ > > + /* IRQ 0,1,2,8,13 are marked as reserved */ > > + trigger[0] = inb(0x4d0) & 0xF8; > > + trigger[1] = inb(0x4d1) & 0xDE; > > Erm, the bits should be zero, why mask them out I wonder... These codes are also come from i386 ... while they seems not used on MIPS now anyway I'll drop them. Thank you for review. I'll post updated patch soon. --- Atsushi Nemoto From anemo@mba.ocn.ne.jp Wed Dec 6 17:04:26 2006 Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 06 Dec 2006 17:04:29 +0000 (GMT) Received: from mba.ocn.ne.jp ([210.190.142.172]:34518 "HELO smtp.mba.ocn.ne.jp") by ftp.linux-mips.org with SMTP id S20038576AbWLFRE0 (ORCPT ); Wed, 6 Dec 2006 17:04:26 +0000 Received: from localhost (p6066-ipad209funabasi.chiba.ocn.ne.jp [58.88.117.66]) by smtp.mba.ocn.ne.jp (Postfix) with ESMTP id 3F921B9D5; Thu, 7 Dec 2006 02:04:18 +0900 (JST) Date: Thu, 07 Dec 2006 02:04:17 +0900 (JST) Message-Id: <20061207.020417.126141622.anemo@mba.ocn.ne.jp> To: linux-mips@linux-mips.org Cc: ralf@linux-mips.org Subject: [PATCH] Import updates from i386's i8259.c (take #3) From: Atsushi Nemoto 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 3.3 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: 13380 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 Import many updates from i386's i8259.c, especially genirq transitions. Signed-off-by: Atsushi Nemoto --- arch/mips/kernel/i8259.c | 162 +++++++++++++++++++++++---------------------- include/asm-mips/i8259.h | 37 ++++++++-- 2 files changed, 115 insertions(+), 84 deletions(-) diff --git a/arch/mips/kernel/i8259.c b/arch/mips/kernel/i8259.c index 2526c0c..b59a676 100644 --- a/arch/mips/kernel/i8259.c +++ b/arch/mips/kernel/i8259.c @@ -19,9 +19,6 @@ #include #include #include -void enable_8259A_irq(unsigned int irq); -void disable_8259A_irq(unsigned int irq); - /* * This is the 'legacy' 8259A Programmable Interrupt Controller, * present in the majority of PC/AT boxes. @@ -31,23 +28,16 @@ void disable_8259A_irq(unsigned int irq) * moves to arch independent land */ +static int i8259A_auto_eoi; DEFINE_SPINLOCK(i8259A_lock); - -static void end_8259A_irq (unsigned int irq) -{ - if (!(irq_desc[irq].status & (IRQ_DISABLED|IRQ_INPROGRESS)) && - irq_desc[irq].action) - enable_8259A_irq(irq); -} - +/* some platforms call this... */ void mask_and_ack_8259A(unsigned int); -static struct irq_chip i8259A_irq_type = { - .typename = "XT-PIC", - .enable = enable_8259A_irq, - .disable = disable_8259A_irq, - .ack = mask_and_ack_8259A, - .end = end_8259A_irq, +static struct irq_chip i8259A_chip = { + .name = "XT-PIC", + .mask = disable_8259A_irq, + .unmask = enable_8259A_irq, + .mask_ack = mask_and_ack_8259A, }; /* @@ -59,8 +49,8 @@ static struct irq_chip i8259A_irq_type = */ static unsigned int cached_irq_mask = 0xffff; -#define cached_21 (cached_irq_mask) -#define cached_A1 (cached_irq_mask >> 8) +#define cached_master_mask (cached_irq_mask) +#define cached_slave_mask (cached_irq_mask >> 8) void disable_8259A_irq(unsigned int irq) { @@ -70,9 +60,9 @@ void disable_8259A_irq(unsigned int irq) spin_lock_irqsave(&i8259A_lock, flags); cached_irq_mask |= mask; if (irq & 8) - outb(cached_A1,0xA1); + outb(cached_slave_mask, PIC_SLAVE_IMR); else - outb(cached_21,0x21); + outb(cached_master_mask, PIC_MASTER_IMR); spin_unlock_irqrestore(&i8259A_lock, flags); } @@ -84,9 +74,9 @@ void enable_8259A_irq(unsigned int irq) spin_lock_irqsave(&i8259A_lock, flags); cached_irq_mask &= mask; if (irq & 8) - outb(cached_A1,0xA1); + outb(cached_slave_mask, PIC_SLAVE_IMR); else - outb(cached_21,0x21); + outb(cached_master_mask, PIC_MASTER_IMR); spin_unlock_irqrestore(&i8259A_lock, flags); } @@ -98,9 +88,9 @@ int i8259A_irq_pending(unsigned int irq) spin_lock_irqsave(&i8259A_lock, flags); if (irq < 8) - ret = inb(0x20) & mask; + ret = inb(PIC_MASTER_CMD) & mask; else - ret = inb(0xA0) & (mask >> 8); + ret = inb(PIC_SLAVE_CMD) & (mask >> 8); spin_unlock_irqrestore(&i8259A_lock, flags); return ret; @@ -109,7 +99,7 @@ int i8259A_irq_pending(unsigned int irq) void make_8259A_irq(unsigned int irq) { disable_irq_nosync(irq); - set_irq_chip(irq, &i8259A_irq_type); + set_irq_chip_and_handler(irq, &i8259A_chip, handle_level_irq); enable_irq(irq); } @@ -125,14 +115,14 @@ static inline int i8259A_irq_real(unsign int irqmask = 1 << irq; if (irq < 8) { - outb(0x0B,0x20); /* ISR register */ - value = inb(0x20) & irqmask; - outb(0x0A,0x20); /* back to the IRR register */ + outb(0x0B,PIC_MASTER_CMD); /* ISR register */ + value = inb(PIC_MASTER_CMD) & irqmask; + outb(0x0A,PIC_MASTER_CMD); /* back to the IRR register */ return value; } - outb(0x0B,0xA0); /* ISR register */ - value = inb(0xA0) & (irqmask >> 8); - outb(0x0A,0xA0); /* back to the IRR register */ + outb(0x0B,PIC_SLAVE_CMD); /* ISR register */ + value = inb(PIC_SLAVE_CMD) & (irqmask >> 8); + outb(0x0A,PIC_SLAVE_CMD); /* back to the IRR register */ return value; } @@ -149,17 +139,19 @@ void mask_and_ack_8259A(unsigned int irq spin_lock_irqsave(&i8259A_lock, flags); /* - * Lightweight spurious IRQ detection. We do not want to overdo - * spurious IRQ handling - it's usually a sign of hardware problems, so - * we only do the checks we can do without slowing down good hardware - * nnecesserily. + * Lightweight spurious IRQ detection. We do not want + * to overdo spurious IRQ handling - it's usually a sign + * of hardware problems, so we only do the checks we can + * do without slowing down good hardware unnecessarily. * - * Note that IRQ7 and IRQ15 (the two spurious IRQs usually resulting - * rom the 8259A-1|2 PICs) occur even if the IRQ is masked in the 8259A. - * Thus we can check spurious 8259A IRQs without doing the quite slow - * i8259A_irq_real() call for every IRQ. This does not cover 100% of - * spurious interrupts, but should be enough to warn the user that - * there is something bad going on ... + * Note that IRQ7 and IRQ15 (the two spurious IRQs + * usually resulting from the 8259A-1|2 PICs) occur + * even if the IRQ is masked in the 8259A. Thus we + * can check spurious 8259A IRQs without doing the + * quite slow i8259A_irq_real() call for every IRQ. + * This does not cover 100% of spurious interrupts, + * but should be enough to warn the user that there + * is something bad going on ... */ if (cached_irq_mask & irqmask) goto spurious_8259A_irq; @@ -167,14 +159,14 @@ void mask_and_ack_8259A(unsigned int irq handle_real_irq: if (irq & 8) { - inb(0xA1); /* DUMMY - (do we need this?) */ - outb(cached_A1,0xA1); - outb(0x60+(irq&7),0xA0);/* 'Specific EOI' to slave */ - outb(0x62,0x20); /* 'Specific EOI' to master-IRQ2 */ + inb(PIC_SLAVE_IMR); /* DUMMY - (do we need this?) */ + outb(cached_slave_mask, PIC_SLAVE_IMR); + outb(0x60+(irq&7),PIC_SLAVE_CMD);/* 'Specific EOI' to slave */ + outb(0x60+PIC_CASCADE_IR,PIC_MASTER_CMD); /* 'Specific EOI' to master-IRQ2 */ } else { - inb(0x21); /* DUMMY - (do we need this?) */ - outb(cached_21,0x21); - outb(0x60+irq,0x20); /* 'Specific EOI' to master */ + inb(PIC_MASTER_IMR); /* DUMMY - (do we need this?) */ + outb(cached_master_mask, PIC_MASTER_IMR); + outb(0x60+irq,PIC_MASTER_CMD); /* 'Specific EOI to master */ } #ifdef CONFIG_MIPS_MT_SMTC if (irq_hwmask[irq] & ST0_IM) @@ -195,7 +187,7 @@ spurious_8259A_irq: goto handle_real_irq; { - static int spurious_irq_mask = 0; + static int spurious_irq_mask; /* * At this point we can be sure the IRQ is spurious, * lets ACK and report it. [once per IRQ] @@ -216,13 +208,25 @@ spurious_8259A_irq: static int i8259A_resume(struct sys_device *dev) { - init_8259A(0); + init_8259A(i8259A_auto_eoi); + return 0; +} + +static int i8259A_shutdown(struct sys_device *dev) +{ + /* Put the i8259A into a quiescent state that + * the kernel initialization code can get it + * out of. + */ + outb(0xff, PIC_MASTER_IMR); /* mask all of 8259A-1 */ + outb(0xff, PIC_SLAVE_IMR); /* mask all of 8259A-1 */ return 0; } static struct sysdev_class i8259_sysdev_class = { set_kset_name("i8259"), .resume = i8259A_resume, + .shutdown = i8259A_shutdown, }; static struct sys_device device_i8259A = { @@ -244,41 +248,41 @@ void __init init_8259A(int auto_eoi) { unsigned long flags; + i8259A_auto_eoi = auto_eoi; + spin_lock_irqsave(&i8259A_lock, flags); - outb(0xff, 0x21); /* mask all of 8259A-1 */ - outb(0xff, 0xA1); /* mask all of 8259A-2 */ + outb(0xff, PIC_MASTER_IMR); /* mask all of 8259A-1 */ + outb(0xff, PIC_SLAVE_IMR); /* mask all of 8259A-2 */ /* * outb_p - this has to work on a wide range of PC hardware. */ - outb_p(0x11, 0x20); /* ICW1: select 8259A-1 init */ - outb_p(0x00, 0x21); /* ICW2: 8259A-1 IR0-7 mapped to 0x00-0x07 */ - outb_p(0x04, 0x21); /* 8259A-1 (the master) has a slave on IR2 */ - if (auto_eoi) - outb_p(0x03, 0x21); /* master does Auto EOI */ - else - outb_p(0x01, 0x21); /* master expects normal EOI */ - - outb_p(0x11, 0xA0); /* ICW1: select 8259A-2 init */ - outb_p(0x08, 0xA1); /* ICW2: 8259A-2 IR0-7 mapped to 0x08-0x0f */ - outb_p(0x02, 0xA1); /* 8259A-2 is a slave on master's IR2 */ - outb_p(0x01, 0xA1); /* (slave's support for AEOI in flat mode - is to be investigated) */ - + outb_p(0x11, PIC_MASTER_CMD); /* ICW1: select 8259A-1 init */ + outb_p(I8259A_IRQ_BASE + 0, PIC_MASTER_IMR); /* ICW2: 8259A-1 IR0 mapped to I8259A_IRQ_BASE + 0x00 */ + outb_p(1U << PIC_CASCADE_IR, PIC_MASTER_IMR); /* 8259A-1 (the master) has a slave on IR2 */ + if (auto_eoi) /* master does Auto EOI */ + outb_p(MASTER_ICW4_DEFAULT | PIC_ICW4_AEOI, PIC_MASTER_IMR); + else /* master expects normal EOI */ + outb_p(MASTER_ICW4_DEFAULT, PIC_MASTER_IMR); + + outb_p(0x11, PIC_SLAVE_CMD); /* ICW1: select 8259A-2 init */ + outb_p(I8259A_IRQ_BASE + 8, PIC_SLAVE_IMR); /* ICW2: 8259A-2 IR0 mapped to I8259A_IRQ_BASE + 0x08 */ + outb_p(PIC_CASCADE_IR, PIC_SLAVE_IMR); /* 8259A-2 is a slave on master's IR2 */ + outb_p(SLAVE_ICW4_DEFAULT, PIC_SLAVE_IMR); /* (slave's support for AEOI in flat mode is to be investigated) */ if (auto_eoi) /* - * in AEOI mode we just have to mask the interrupt + * In AEOI mode we just have to mask the interrupt * when acking. */ - i8259A_irq_type.ack = disable_8259A_irq; + i8259A_chip.mask_ack = disable_8259A_irq; else - i8259A_irq_type.ack = mask_and_ack_8259A; + i8259A_chip.mask_ack = mask_and_ack_8259A; udelay(100); /* wait for 8259A to initialize */ - outb(cached_21, 0x21); /* restore master IRQ mask */ - outb(cached_A1, 0xA1); /* restore slave IRQ mask */ + outb(cached_master_mask, PIC_MASTER_IMR); /* restore master IRQ mask */ + outb(cached_slave_mask, PIC_SLAVE_IMR); /* restore slave IRQ mask */ spin_unlock_irqrestore(&i8259A_lock, flags); } @@ -291,11 +295,17 @@ static struct irqaction irq2 = { }; static struct resource pic1_io_resource = { - .name = "pic1", .start = 0x20, .end = 0x21, .flags = IORESOURCE_BUSY + .name = "pic1", + .start = PIC_MASTER_CMD, + .end = PIC_MASTER_IMR, + .flags = IORESOURCE_BUSY }; static struct resource pic2_io_resource = { - .name = "pic2", .start = 0xa0, .end = 0xa1, .flags = IORESOURCE_BUSY + .name = "pic2", + .start = PIC_SLAVE_CMD, + .end = PIC_SLAVE_IMR, + .flags = IORESOURCE_BUSY }; /* @@ -313,7 +323,7 @@ void __init init_i8259_irqs (void) init_8259A(0); for (i = 0; i < 16; i++) - set_irq_chip(i, &i8259A_irq_type); + set_irq_chip_and_handler(i, &i8259A_chip, handle_level_irq); - setup_irq(2, &irq2); + setup_irq(PIC_CASCADE_IR, &irq2); } diff --git a/include/asm-mips/i8259.h b/include/asm-mips/i8259.h index 0214abe..4df8d8b 100644 --- a/include/asm-mips/i8259.h +++ b/include/asm-mips/i8259.h @@ -19,10 +19,31 @@ #include #include +/* i8259A PIC registers */ +#define PIC_MASTER_CMD 0x20 +#define PIC_MASTER_IMR 0x21 +#define PIC_MASTER_ISR PIC_MASTER_CMD +#define PIC_MASTER_POLL PIC_MASTER_ISR +#define PIC_MASTER_OCW3 PIC_MASTER_ISR +#define PIC_SLAVE_CMD 0xa0 +#define PIC_SLAVE_IMR 0xa1 + +/* i8259A PIC related value */ +#define PIC_CASCADE_IR 2 +#define MASTER_ICW4_DEFAULT 0x01 +#define SLAVE_ICW4_DEFAULT 0x01 +#define PIC_ICW4_AEOI 2 + extern spinlock_t i8259A_lock; +extern void init_8259A(int auto_eoi); +extern void enable_8259A_irq(unsigned int irq); +extern void disable_8259A_irq(unsigned int irq); + extern void init_i8259_irqs(void); +#define I8259A_IRQ_BASE 0 + /* * Do the traditional i8259 interrupt polling thing. This is for the few * cases where no better interrupt acknowledge method is available and we @@ -35,15 +56,15 @@ static inline int i8259_irq(void) spin_lock(&i8259A_lock); /* Perform an interrupt acknowledge cycle on controller 1. */ - outb(0x0C, 0x20); /* prepare for poll */ - irq = inb(0x20) & 7; - if (irq == 2) { + outb(0x0C, PIC_MASTER_CMD); /* prepare for poll */ + irq = inb(PIC_MASTER_CMD) & 7; + if (irq == PIC_CASCADE_IR) { /* * Interrupt is cascaded so perform interrupt * acknowledge on controller 2. */ - outb(0x0C, 0xA0); /* prepare for poll */ - irq = (inb(0xA0) & 7) + 8; + outb(0x0C, PIC_SLAVE_CMD); /* prepare for poll */ + irq = (inb(PIC_SLAVE_CMD) & 7) + 8; } if (unlikely(irq == 7)) { @@ -54,14 +75,14 @@ static inline int i8259_irq(void) * significant bit is not set then there is no valid * interrupt. */ - outb(0x0B, 0x20); /* ISR register */ - if(~inb(0x20) & 0x80) + outb(0x0B, PIC_MASTER_ISR); /* ISR register */ + if(~inb(PIC_MASTER_ISR) & 0x80) irq = -1; } spin_unlock(&i8259A_lock); - return irq; + return likely(irq >= 0) ? irq + I8259A_IRQ_BASE : irq; } #endif /* _ASM_I8259_H */ From macro@linux-mips.org Wed Dec 6 19:00:31 2006 Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 06 Dec 2006 19:00:36 +0000 (GMT) Received: from pollux.ds.pg.gda.pl ([153.19.208.7]:26125 "EHLO pollux.ds.pg.gda.pl") by ftp.linux-mips.org with ESMTP id S20037960AbWLFTAb (ORCPT ); Wed, 6 Dec 2006 19:00:31 +0000 Received: from localhost (localhost [127.0.0.1]) by pollux.ds.pg.gda.pl (Postfix) with ESMTP id B69A9F5964; Wed, 6 Dec 2006 20:00:13 +0100 (CET) X-Virus-Scanned: by amavisd-new at pollux.ds.pg.gda.pl Received: from pollux.ds.pg.gda.pl ([127.0.0.1]) by localhost (pollux.ds.pg.gda.pl [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kdquFQP3WcsW; Wed, 6 Dec 2006 20:00:13 +0100 (CET) Received: from piorun.ds.pg.gda.pl (piorun.ds.pg.gda.pl [153.19.208.8]) by pollux.ds.pg.gda.pl (Postfix) with ESMTP id A5073F5949; Wed, 6 Dec 2006 20:00:12 +0100 (CET) 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 kB6J0Pho007503; Wed, 6 Dec 2006 20:00:26 +0100 Date: Wed, 6 Dec 2006 19:00:20 +0000 (GMT) From: "Maciej W. Rozycki" To: Sergei Shtylyov cc: Ingo Molnar , anemo@mba.sphere.ne.jp, Ralf Baechle , linux-mips@linux-mips.org Subject: Re: [PATCH] Import updates from i386's i8259.c In-Reply-To: <4576E666.1010502@ru.mvista.com> Message-ID: References: <20061206.103923.71086192.nemoto@toshiba-tops.co.jp> <20061206015818.GB27985@linux-mips.org> <20061206.115602.63741871.nemoto@toshiba-tops.co.jp> <20061206.133836.89067271.nemoto@toshiba-tops.co.jp> <4576C2E9.4060900@ru.mvista.com> <4576CB64.2060705@ru.mvista.com> <4576DDEC.1050105@ru.mvista.com> <4576E666.1010502@ru.mvista.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: ClamAV 0.88.6/2293/Wed Dec 6 15:00:31 2006 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: 13381 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, 6 Dec 2006, Sergei Shtylyov wrote: > > Nope, it was the i82489DX -- the original "discrete" coupled Local & I/O > > APIC using a five-wire inter-APIC bus and a protocol different from later > > implementations. > > Hm, that's news to me. I always thought that chip was external *local* APIC > only... Well, there's no docs on it anyway. The docs used to be available from Intel -- guess how we have got the chip supported. ;-) Maciej From ashlesha@kenati.com Wed Dec 6 19:36:57 2006 Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 06 Dec 2006 19:37:02 +0000 (GMT) Received: from [69.90.147.196] ([69.90.147.196]:10136 "EHLO mail.kenati.com") by ftp.linux-mips.org with ESMTP id S20038616AbWLFTg5 (ORCPT ); Wed, 6 Dec 2006 19:36:57 +0000 Received: from [192.168.1.169] (adsl-71-130-109-177.dsl.snfc21.pacbell.net [71.130.109.177]) by mail.kenati.com (Postfix) with ESMTP id 71DE415D4004; Wed, 6 Dec 2006 13:06:56 -0800 (PST) Subject: Re: serial console: platform_device From: Ashlesha Shintre Reply-To: ashlesha@kenati.com To: Sergei Shtylyov Cc: linux-mips@linux-mips.org In-Reply-To: <4576BEBA.6080702@ru.mvista.com> References: <1165346639.6871.19.camel@sandbar.kenati.com> <4575CBB6.8030804@ru.mvista.com> <1165351710.6871.34.camel@sandbar.kenati.com> <4575DABF.2000604@ru.mvista.com> <1165365058.6871.54.camel@sandbar.kenati.com> <4576BEBA.6080702@ru.mvista.com> Content-Type: text/plain Date: Wed, 06 Dec 2006 11:49:37 -0800 Message-Id: <1165434577.6516.8.camel@sandbar.kenati.com> Mime-Version: 1.0 X-Mailer: Evolution 2.4.2.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: 13382 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: ashlesha@kenati.com Precedence: bulk X-list: linux-mips hi, There is already an interrupt handler in place for the AU1000_GPIO_0 that takes care of the cascaded interrupts -- so I *can* say .irq= AU1000_GPIO_0 ----right? Also, how will I make sure my board specific encm3_platform_init is called during the arch init calls? I have put in an entry in the Makefile for the board specific encm3_platform.c file -- so it is built - but when control goes to the static int __devinit serial8250_probe(struct device *dev) function in the 8250.c it never executes the serial8250_register_port function. I know this cus I m using the JTAG port on the board to look inside and step through the code.. Here is my /arch/mips/au1000/encm3/encm3_platform.c file: Thanks and Regards, Ashlesha. > /* > * Platform device support for Au1x00 SoCs. > * > * Copyright 2004, Matt Porter > * > * This file is licensed under the terms of the GNU General Public > * License version 2. This program is licensed "as is" without any > * warranty of any kind, whether express or implied. > */ > #include > #include > #include > #include > #include > #include > > #include > #include > static struct plat_serial8250_port encm3_via_uart_data[] = { > { > .mapbase = > 0x3f8, //resource base > // .membase = (char *)(0x50000000 + > 0x3f8), // is a pointer - ioremap cookie or NULL > .irq = AU1000_GPIO_0, > .flags = UPF_SHARE_IRQ, //| > UPF_IOREMAP, //UPF_BOOT_AUTOCONF | UPF_SKIP_TEST | > .iotype = UPIO_PORT, > .regshift = 1, > .uartclk = 1843200, > > }, > { }, > }; > > static struct resource encm3_via_uart_resource = { > .start = VIA_COM1_ADDR, > .end = VIA_COM1_ADDR + 0x7, > .flags = IORESOURCE_IO, > }; > > > static struct platform_device encm3_via_uart = { > .name = "serial8250", > .id = 1, > .dev = { > .platform_data = encm3_via_uart_data, > }, > .num_resources = 1, > .resource = &encm3_via_uart_resource, > }; > > static struct platform_device *encm3_platform_devices[] __initdata = { > &encm3_via_uart, > }; > > int encm3_platform_init(void) > { > printk("size of encm3 platform devices is %d > \n",ARRAY_SIZE(encm3_platform_devices)); > return platform_add_devices(encm3_platform_devices, > ARRAY_SIZE(encm3_platform_devices)); > } > > arch_initcall(encm3_platform_init); On Wed, 2006-12-06 at 15:59 +0300, Sergei Shtylyov wrote: > Hello. > > Ashlesha Shintre wrote: > > >> Ah, I forgot to mention that if your UART is a part of the south bridge, > >>its IRQ number is _4_ on the integrated 8259 interrupt controller. I'm sure > >>that AU1000_GPIO_0 is the cascaded interrupt request from 8259, not the UART's > >>own IRQ... > > >>>>static struct plat_serial8250_port encm3_via_uart_data[] = { > >>>> { > >>>> .mapbase = 0x3f8, > >>>> .irq = AU1000_GPIO_0, > > >> So, this is wrong. You need to specify to what platform IRQ 8259's IRQ4 > >>gets routed here. > > > I m not sure what you mean here -- the AU1000_GPIO_0 is the cascaded > > interrupt request from the 8259 on the VIA Southbridge -- > > I meant that the UART interrupts from the south bridge *cannot* be > delivered *directly* to the Alchemy's embedded interrupt controller), so > AU1000_GPIO_0 must be used to deliver all the interrupts from 8259 (the > interrupt controller integrated into the south bridge) to the embedded > interrupt controller. So, you need to setup some kind of the cascading > interrupt handler for AU1000_GPIO_0 to read the vector from 8259 I think... > > > Best Regards, > > Ashlesha. > > WBR, Sergei From sshtylyov@ru.mvista.com Wed Dec 6 19:53:44 2006 Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 06 Dec 2006 19:53:48 +0000 (GMT) Received: from h155.mvista.com ([63.81.120.155]:56679 "EHLO imap.sh.mvista.com") by ftp.linux-mips.org with ESMTP id S20038616AbWLFTxo (ORCPT ); Wed, 6 Dec 2006 19:53:44 +0000 Received: from [192.168.1.248] (unknown [10.150.0.9]) by imap.sh.mvista.com (Postfix) with ESMTP id 07D343EC9; Wed, 6 Dec 2006 11:53:22 -0800 (PST) Message-ID: <45772013.70907@ru.mvista.com> Date: Wed, 06 Dec 2006 22:54:59 +0300 From: Sergei Shtylyov Organization: MontaVista Software Inc. User-Agent: Mozilla/5.0 (X11; U; Linux i686; rv:1.7.2) Gecko/20040803 X-Accept-Language: ru, en-us, en-gb MIME-Version: 1.0 To: ashlesha@kenati.com Cc: linux-mips@linux-mips.org Subject: Re: serial console: platform_device References: <1165346639.6871.19.camel@sandbar.kenati.com> <4575CBB6.8030804@ru.mvista.com> <1165351710.6871.34.camel@sandbar.kenati.com> <4575DABF.2000604@ru.mvista.com> <1165365058.6871.54.camel@sandbar.kenati.com> <4576BEBA.6080702@ru.mvista.com> <1165434577.6516.8.camel@sandbar.kenati.com> In-Reply-To: <1165434577.6516.8.camel@sandbar.kenati.com> Content-Type: text/plain; charset=us-ascii; 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: 13383 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: sshtylyov@ru.mvista.com Precedence: bulk X-list: linux-mips Hello. Ashlesha Shintre wrote: > There is already an interrupt handler in place for the AU1000_GPIO_0 > that takes care of the cascaded interrupts -- so I *can* say > .irq= AU1000_GPIO_0 ----right? No, you can't. You'll have to specify to what 8259's IRQ4 maps to on your platform. > Also, how will I make sure my board specific encm3_platform_init is > called during the arch init calls? Mentioning it in arch_initcall() arranges for that. :-/ > I have put in an entry in the Makefile for the board specific > encm3_platform.c file -- so it is built - but when control goes to the > static int __devinit serial8250_probe(struct device *dev) function in > the 8250.c it never executes the serial8250_register_port function. > I know this cus I m using the JTAG port on the board to look inside and > step through the code.. That's strange. Although the UART declaration has a grave defect.... > Here is my /arch/mips/au1000/encm3/encm3_platform.c file: >>/* >> * Platform device support for Au1x00 SoCs. >> * >> * Copyright 2004, Matt Porter >> * >> * This file is licensed under the terms of the GNU General Public >> * License version 2. This program is licensed "as is" without any >> * warranty of any kind, whether express or implied. >> */ That boilerplate is no longer applicable. :-) >>#include >>#include >>#include >>#include >>#include >>#include >> >>#include >>#include >>static struct plat_serial8250_port encm3_via_uart_data[] = { >> { >> .mapbase = >>0x3f8, //resource base Damn, I didn't notice: .mapbase should be changed to .iobase! >>// .membase = (char *)(0x50000000 + >>0x3f8), // is a pointer - ioremap cookie or NULL >> .irq = AU1000_GPIO_0, >> .flags = UPF_SHARE_IRQ, //| >>UPF_IOREMAP, //UPF_BOOT_AUTOCONF | UPF_SKIP_TEST | >> .iotype = UPIO_PORT, >> .regshift = 1, >> .uartclk = 1843200, >> >> }, >> { }, >>}; >>static struct resource encm3_via_uart_resource = { >> .start = VIA_COM1_ADDR, >> .end = VIA_COM1_ADDR + 0x7, >> .flags = IORESOURCE_IO, >>}; Still, you don't need to declare the resources for the 8250 devices -- the driver should handle requesting them for you -- as they're alredy specified by struct plat_serial8250_port. >>static struct platform_device encm3_via_uart = { >> .name = "serial8250", >> .id = 1, I guess it should be PLAT8250_DEV_LEGACY... >> .dev = { >> .platform_data = encm3_via_uart_data, >> }, So, you also don't need the following 2 lines: >> .num_resources = 1, >> .resource = &encm3_via_uart_resource, >>}; >>static struct platform_device *encm3_platform_devices[] __initdata = { >> &encm3_via_uart, >>}; >>int encm3_platform_init(void) >>{ >> printk("size of encm3 platform devices is %d >>\n",ARRAY_SIZE(encm3_platform_devices)); >> return platform_add_devices(encm3_platform_devices, >>ARRAY_SIZE(encm3_platform_devices)); I think it's better to call platform_device_register() for a single device... WBR, Sergei From ralf@linux-mips.org Wed Dec 6 20:33:10 2006 Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 06 Dec 2006 20:33:12 +0000 (GMT) Received: from localhost.localdomain ([127.0.0.1]:51133 "EHLO dl5rb.ham-radio-op.net") by ftp.linux-mips.org with ESMTP id S20037871AbWLFUdK (ORCPT ); Wed, 6 Dec 2006 20:33:10 +0000 Received: from denk.linux-mips.net (denk.linux-mips.net [127.0.0.1]) by dl5rb.ham-radio-op.net (8.13.8/8.13.8) with ESMTP id kB6KX884010522; Wed, 6 Dec 2006 20:33:08 GMT Received: (from ralf@localhost) by denk.linux-mips.net (8.13.8/8.13.8/Submit) id kB6KWxIG010521; Wed, 6 Dec 2006 20:32:59 GMT Date: Wed, 6 Dec 2006 20:32:59 +0000 From: Ralf Baechle To: Atsushi Nemoto Cc: sshtylyov@ru.mvista.com, linux-mips@linux-mips.org Subject: Re: [PATCH] Import updates from i386's i8259.c Message-ID: <20061206203259.GA10170@linux-mips.org> References: <20061206.115602.63741871.nemoto@toshiba-tops.co.jp> <20061206.133836.89067271.nemoto@toshiba-tops.co.jp> <4576C2E9.4060900@ru.mvista.com> <20061207.020348.25910403.anemo@mba.ocn.ne.jp> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20061207.020348.25910403.anemo@mba.ocn.ne.jp> User-Agent: Mutt/1.4.2.2i 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: 13384 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, Dec 07, 2006 at 02:03:48AM +0900, Atsushi Nemoto wrote: > > 8259A PICs and so was capable of handling only 8 IRQs. Dual 8259A was first > > used in the AT class machines... > > It has been called "XT-PIC" anyway so I'd like to keep unchanged. 90% of the i8259 code are identical between i386 and MIPS and several others; maybe it's time to share such code between architectures. Ralf From ashlesha@kenati.com Thu Dec 7 00:00:43 2006 Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 07 Dec 2006 00:00:48 +0000 (GMT) Received: from [69.90.147.196] ([69.90.147.196]:57018 "EHLO mail.kenati.com") by ftp.linux-mips.org with ESMTP id S20038989AbWLGAAn (ORCPT ); Thu, 7 Dec 2006 00:00:43 +0000 Received: from [192.168.1.169] (adsl-71-130-109-177.dsl.snfc21.pacbell.net [71.130.109.177]) by mail.kenati.com (Postfix) with ESMTP id 74A4C15D4004; Wed, 6 Dec 2006 17:30:43 -0800 (PST) Subject: Cant analyze prologue code From: Ashlesha Shintre Reply-To: ashlesha@kenati.com To: Sergei Shtylyov Cc: linux-mips@linux-mips.org In-Reply-To: <45772013.70907@ru.mvista.com> References: <1165346639.6871.19.camel@sandbar.kenati.com> <4575CBB6.8030804@ru.mvista.com> <1165351710.6871.34.camel@sandbar.kenati.com> <4575DABF.2000604@ru.mvista.com> <1165365058.6871.54.camel@sandbar.kenati.com> <4576BEBA.6080702@ru.mvista.com> <1165434577.6516.8.camel@sandbar.kenati.com> <45772013.70907@ru.mvista.com> Content-Type: text/plain Date: Wed, 06 Dec 2006 16:13:23 -0800 Message-Id: <1165450403.6516.28.camel@sandbar.kenati.com> Mime-Version: 1.0 X-Mailer: Evolution 2.4.2.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: 13385 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: ashlesha@kenati.com Precedence: bulk X-list: linux-mips Hi Sergei! So now encm3_platform_init function is linked to the kernel image -- and is part of the executable -- i added this line to the arch/mips/au1000/encm3/Makefile: obj-y +=encm3_platform.o However, I now get a "Cant analyze prologue code at 80294aec." error! Any remedies/suggestions for the same? Thank you! Best Regards, Ashlesha. On Wed, 2006-12-06 at 22:54 +0300, Sergei Shtylyov wrote: > Hello. > > Ashlesha Shintre wrote: > > > There is already an interrupt handler in place for the AU1000_GPIO_0 > > that takes care of the cascaded interrupts -- so I *can* say > > .irq= AU1000_GPIO_0 ----right? > > No, you can't. You'll have to specify to what 8259's IRQ4 maps to on your > platform. > > > Also, how will I make sure my board specific encm3_platform_init is > > called during the arch init calls? > > Mentioning it in arch_initcall() arranges for that. :-/ > > > I have put in an entry in the Makefile for the board specific > > encm3_platform.c file -- so it is built - but when control goes to the > > static int __devinit serial8250_probe(struct device *dev) function in > > the 8250.c it never executes the serial8250_register_port function. > > I know this cus I m using the JTAG port on the board to look inside and > > step through the code.. > > That's strange. Although the UART declaration has a grave defect.... > > > Here is my /arch/mips/au1000/encm3/encm3_platform.c file: > > >>/* > >> * Platform device support for Au1x00 SoCs. > >> * > >> * Copyright 2004, Matt Porter > >> * > >> * This file is licensed under the terms of the GNU General Public > >> * License version 2. This program is licensed "as is" without any > >> * warranty of any kind, whether express or implied. > >> */ > > That boilerplate is no longer applicable. :-) > > >>#include > >>#include > >>#include > >>#include > >>#include > >>#include > >> > >>#include > >>#include > >>static struct plat_serial8250_port encm3_via_uart_data[] = { > >> { > >> .mapbase = > >>0x3f8, //resource base > > Damn, I didn't notice: .mapbase should be changed to .iobase! > > >>// .membase = (char *)(0x50000000 + > >>0x3f8), // is a pointer - ioremap cookie or NULL > >> .irq = AU1000_GPIO_0, > >> .flags = UPF_SHARE_IRQ, //| > >>UPF_IOREMAP, //UPF_BOOT_AUTOCONF | UPF_SKIP_TEST | > >> .iotype = UPIO_PORT, > >> .regshift = 1, > >> .uartclk = 1843200, > >> > >> }, > >> { }, > >>}; > > >>static struct resource encm3_via_uart_resource = { > >> .start = VIA_COM1_ADDR, > >> .end = VIA_COM1_ADDR + 0x7, > >> .flags = IORESOURCE_IO, > >>}; > > Still, you don't need to declare the resources for the 8250 devices -- the > driver should handle requesting them for you -- as they're alredy specified by > struct plat_serial8250_port. > > >>static struct platform_device encm3_via_uart = { > >> .name = "serial8250", > >> .id = 1, > > I guess it should be PLAT8250_DEV_LEGACY... > > >> .dev = { > >> .platform_data = encm3_via_uart_data, > >> }, > > So, you also don't need the following 2 lines: > > >> .num_resources = 1, > >> .resource = &encm3_via_uart_resource, > >>}; > > >>static struct platform_device *encm3_platform_devices[] __initdata = { > >> &encm3_via_uart, > >>}; > > >>int encm3_platform_init(void) > >>{ > >> printk("size of encm3 platform devices is %d > >>\n",ARRAY_SIZE(encm3_platform_devices)); > >> return platform_add_devices(encm3_platform_devices, > >>ARRAY_SIZE(encm3_platform_devices)); > > I think it's better to call platform_device_register() for a single device... > > WBR, Sergei > From anemo@mba.ocn.ne.jp Thu Dec 7 01:37:20 2006 Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 07 Dec 2006 01:37:24 +0000 (GMT) Received: from topsns2.toshiba-tops.co.jp ([202.230.225.126]:22456 "EHLO topsns2.toshiba-tops.co.jp") by ftp.linux-mips.org with ESMTP id S20039024AbWLGBhU (ORCPT ); Thu, 7 Dec 2006 01:37:20 +0000 Received: from topsms.toshiba-tops.co.jp by topsns2.toshiba-tops.co.jp via smtpd (for ftp.linux-mips.org [194.74.144.162]) with ESMTP; Thu, 7 Dec 2006 10:37:19 +0900 Received: from topsms.toshiba-tops.co.jp (localhost.localdomain [127.0.0.1]) by localhost.toshiba-tops.co.jp (Postfix) with ESMTP id F172D41D16; Thu, 7 Dec 2006 10:37:15 +0900 (JST) Received: from srd2sd.toshiba-tops.co.jp (srd2sd.toshiba-tops.co.jp [172.17.28.2]) by topsms.toshiba-tops.co.jp (Postfix) with ESMTP id E6C6D20427; Thu, 7 Dec 2006 10:37:15 +0900 (JST) Received: from localhost (fragile [172.17.28.65]) by srd2sd.toshiba-tops.co.jp (8.12.10/8.12.10) with ESMTP id kB71bEW0089330; Thu, 7 Dec 2006 10:37:14 +0900 (JST) (envelope-from anemo@mba.ocn.ne.jp) Date: Thu, 07 Dec 2006 10:37:14 +0900 (JST) Message-Id: <20061207.103714.25910613.nemoto@toshiba-tops.co.jp> To: ashlesha@kenati.com Cc: sshtylyov@ru.mvista.com, linux-mips@linux-mips.org Subject: Re: Cant analyze prologue code From: Atsushi Nemoto In-Reply-To: <1165450403.6516.28.camel@sandbar.kenati.com> References: <1165434577.6516.8.camel@sandbar.kenati.com> <45772013.70907@ru.mvista.com> <1165450403.6516.28.camel@sandbar.kenati.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 3.3 on Emacs 21.3 / 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: 13386 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 Wed, 06 Dec 2006 16:13:23 -0800, Ashlesha Shintre wrote: > However, I now get a "Cant analyze prologue code at 80294aec." error! > > Any remedies/suggestions for the same? Please look at this thread: http://www.linux-mips.org/archives/linux-mips/2004-09/msg00123.html Final patch is: http://www.linux-mips.org/archives/linux-mips/2004-10/msg00312.html And actual commit is: http://www.linux-mips.org/git?p=linux.git;a=commitdiff;h=dc953df1ba5526814982676f47580c8e1bcdbfeb --- Atsushi Nemoto From anemo@mba.ocn.ne.jp Thu Dec 7 03:17:09 2006 Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 07 Dec 2006 03:17:13 +0000 (GMT) Received: from topsns2.toshiba-tops.co.jp ([202.230.225.126]:4729 "EHLO topsns2.toshiba-tops.co.jp") by ftp.linux-mips.org with ESMTP id S20039065AbWLGDRJ (ORCPT ); Thu, 7 Dec 2006 03:17:09 +0000 Received: from topsms.toshiba-tops.co.jp by topsns2.toshiba-tops.co.jp via smtpd (for ftp.linux-mips.org [194.74.144.162]) with ESMTP; Thu, 7 Dec 2006 12:17:08 +0900 Received: from topsms.toshiba-tops.co.jp (localhost.localdomain [127.0.0.1]) by localhost.toshiba-tops.co.jp (Postfix) with ESMTP id 700AD20752; Thu, 7 Dec 2006 12:17:05 +0900 (JST) Received: from srd2sd.toshiba-tops.co.jp (srd2sd.toshiba-tops.co.jp [172.17.28.2]) by topsms.toshiba-tops.co.jp (Postfix) with ESMTP id 63AF820488; Thu, 7 Dec 2006 12:17:05 +0900 (JST) Received: from localhost (fragile [172.17.28.65]) by srd2sd.toshiba-tops.co.jp (8.12.10/8.12.10) with ESMTP id kB73H2W0089697; Thu, 7 Dec 2006 12:17:04 +0900 (JST) (envelope-from anemo@mba.ocn.ne.jp) Date: Thu, 07 Dec 2006 12:17:02 +0900 (JST) Message-Id: <20061207.121702.108739943.nemoto@toshiba-tops.co.jp> To: vagabon.xyz@gmail.com Cc: ralf@linux-mips.org, anemo@mba.ocn.ne.jp, linux-mips@linux-mips.org Subject: Re: [PATCH] Import updates from i386's i8259.c From: Atsushi Nemoto In-Reply-To: References: <20061205194907.GA1088@linux-mips.org> <20061205195702.GA2097@linux-mips.org> 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 3.3 on Emacs 21.3 / 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: 13387 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 Wed, 6 Dec 2006 09:40:50 +0100, "Franck Bui-Huu" wrote: > Atsushi, could you take care of removing "select > GENERIC_HARDIRQS_NO__DO_IRQ" in your patch where needed ? specially > all boards based on NEC VR41XX cpu. You mean "adding" ? I think now we can select GENERIC_HARDIRQS_NO__DO_IRQ for all MACH_VR41XX boards. Also I think most codes in vr41xx/nec-cmbvr4133/irq.c can be removed if we made I8259A_IRQ_BASE customizable, but that would be another story... --- Atsushi Nemoto From ashlesha@kenati.com Thu Dec 7 03:26:33 2006 Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 07 Dec 2006 03:26:38 +0000 (GMT) Received: from [69.90.147.196] ([69.90.147.196]:51415 "EHLO mail.kenati.com") by ftp.linux-mips.org with ESMTP id S20039073AbWLGD0d (ORCPT ); Thu, 7 Dec 2006 03:26:33 +0000 Received: from [192.168.1.169] (adsl-71-130-109-177.dsl.snfc21.pacbell.net [71.130.109.177]) by mail.kenati.com (Postfix) with ESMTP id 08DDC15D4004; Wed, 6 Dec 2006 20:56:36 -0800 (PST) Subject: Re: Cant analyze prologue code From: Ashlesha Shintre Reply-To: ashlesha@kenati.com To: Atsushi Nemoto , sshtylyov@ru.mvista.com Cc: linux-mips@linux-mips.org In-Reply-To: <20061207.103714.25910613.nemoto@toshiba-tops.co.jp> References: <1165434577.6516.8.camel@sandbar.kenati.com> <45772013.70907@ru.mvista.com> <1165450403.6516.28.camel@sandbar.kenati.com> <20061207.103714.25910613.nemoto@toshiba-tops.co.jp> Content-Type: text/plain Date: Wed, 06 Dec 2006 19:39:14 -0800 Message-Id: <1165462754.6516.40.camel@sandbar.kenati.com> Mime-Version: 1.0 X-Mailer: Evolution 2.4.2.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: 13388 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: ashlesha@kenati.com Precedence: bulk X-list: linux-mips Hi, I cant build the kernel with this patch -- i m using the 2.6.14.6 kernel.. also, the kernel does not hang, but the output produced on the console is not complete: eg i.e. I get this: > 1000 i 1.5 P P > 0: A1 Er n 01500000, 28 > 0: Bd BCM5221 10/100 BT PHY e 0 > 0: U Bo BCM5221 10/100 BT PHY a > 1: A1 Ee 01510000, 29 > 1: Bm BCM5221 10/100 BT PHY e 0 > 1: U Bc BCM5221 10/100 BT PHY l > NET: Re c l 2 > IP t h l i: 1024 (: 0, 4096 s) > TCP l h i: 4096 (: 2, 16384 s) > TCP d h i: 4096 (: 2, 16384 s) > TCP: H s u (a 4096 4096) > TCP s > TCP s > NET: Rs o y 1 > NET: Rt o i 17 > IP-C: Gn s 255.255.255.0 instead of : > au1000eth version 1.5 Pete Popov > eth0: Au1x Ethernet found at 0xb1500000, irq 28 > eth0: Broadcom BCM5221 10/100 BaseT PHY at phy address 0 > eth0: Using Broadcom BCM5221 10/100 BaseT PHY as default > eth1: Au1x Ethernet found at 0xb1510000, irq 29 > eth1: Broadcom BCM5221 10/100 BaseT PHY at phy address 0 > eth1: Using Broadcom BCM5221 10/100 BaseT PHY as default > NET: Registered protocol family 2 > IP route cache hash table entries: 1024 (order: 0, 4096 bytes) > TCP established hash table entries: 4096 (order: 2, 16384 bytes) > TCP bind hash table entries: 4096 (order: 2, 16384 bytes) > TCP: Hash tables configured (established 4096 bind 4096) > TCP reno registered > TCP bic registered > NET: Registered protocol family 1 > NET: Registered protocol family 17 > IP-Config: Guessing netmask 255.255.255.0 > IP-Config: Complete: which makes me think there is some kind of a wrong initialisation of the UART -- but i ve checked all the parameters: iobase, IRQ, etc and nothing is obviously wrong -- I was wondering what the significance of the flags in the plat_serial8250_port is? > static struct plat_serial8250_port encm3_via_uart_data[] = { > { > > .flags = UPF_SHARE_IRQ, > Thanks and Regards, Ashlesha. On Thu, 2006-12-07 at 10:37 +0900, Atsushi Nemoto wrote: > On Wed, 06 Dec 2006 16:13:23 -0800, Ashlesha Shintre wrote: > > However, I now get a "Cant analyze prologue code at 80294aec." error! > > > > Any remedies/suggestions for the same? > > Please look at this thread: > > http://www.linux-mips.org/archives/linux-mips/2004-09/msg00123.html > > Final patch is: > > http://www.linux-mips.org/archives/linux-mips/2004-10/msg00312.html > > And actual commit is: > > http://www.linux-mips.org/git?p=linux.git;a=commitdiff;h=dc953df1ba5526814982676f47580c8e1bcdbfeb > > --- > Atsushi Nemoto From anemo@mba.ocn.ne.jp Thu Dec 7 04:13:11 2006 Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 07 Dec 2006 04:13:15 +0000 (GMT) Received: from topsns2.toshiba-tops.co.jp ([202.230.225.126]:16369 "EHLO topsns2.toshiba-tops.co.jp") by ftp.linux-mips.org with ESMTP id S20037675AbWLGENL (ORCPT ); Thu, 7 Dec 2006 04:13:11 +0000 Received: from topsms.toshiba-tops.co.jp by topsns2.toshiba-tops.co.jp via smtpd (for ftp.linux-mips.org [194.74.144.162]) with ESMTP; Thu, 7 Dec 2006 13:13:09 +0900 Received: from topsms.toshiba-tops.co.jp (localhost.localdomain [127.0.0.1]) by localhost.toshiba-tops.co.jp (Postfix) with ESMTP id EE81F41E11; Thu, 7 Dec 2006 13:13:06 +0900 (JST) Received: from srd2sd.toshiba-tops.co.jp (srd2sd.toshiba-tops.co.jp [172.17.28.2]) by topsms.toshiba-tops.co.jp (Postfix) with ESMTP id E392F41DBA; Thu, 7 Dec 2006 13:13:06 +0900 (JST) Received: from localhost (fragile [172.17.28.65]) by srd2sd.toshiba-tops.co.jp (8.12.10/8.12.10) with ESMTP id kB74D6W0089930; Thu, 7 Dec 2006 13:13:06 +0900 (JST) (envelope-from anemo@mba.ocn.ne.jp) Date: Thu, 07 Dec 2006 13:13:06 +0900 (JST) Message-Id: <20061207.131306.63741931.nemoto@toshiba-tops.co.jp> To: ashlesha@kenati.com Cc: sshtylyov@ru.mvista.com, linux-mips@linux-mips.org Subject: Re: Cant analyze prologue code From: Atsushi Nemoto In-Reply-To: <1165462754.6516.40.camel@sandbar.kenati.com> References: <1165450403.6516.28.camel@sandbar.kenati.com> <20061207.103714.25910613.nemoto@toshiba-tops.co.jp> <1165462754.6516.40.camel@sandbar.kenati.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 3.3 on Emacs 21.3 / 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: 13389 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 Wed, 06 Dec 2006 19:39:14 -0800, Ashlesha Shintre wrote: > I cant build the kernel with this patch -- i m using the 2.6.14.6 > kernel.. Then these patch might fit your needs: http://www.linux-mips.org/archives/linux-mips/2005-11/msg00088.html or http://www.linux-mips.org/archives/linux-mips/2006-02/msg00097.html (http://www.linux-mips.org/git?p=linux.git;a=commitdiff;h=63077519899721120b61d663a68adced068a459d) > also, the kernel does not hang, but the output produced on the console > is not complete: eg > i.e. I get this: Anyway, "Cant analyze prologue code" message should not irrelevant to your serial console problem. --- Atsushi Nemoto From vagabon.xyz@gmail.com Thu Dec 7 07:34:45 2006 Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 07 Dec 2006 07:34:50 +0000 (GMT) Received: from nf-out-0910.google.com ([64.233.182.189]:35516 "EHLO nf-out-0910.google.com") by ftp.linux-mips.org with ESMTP id S20038727AbWLGHep (ORCPT ); Thu, 7 Dec 2006 07:34:45 +0000 Received: by nf-out-0910.google.com with SMTP id l24so758955nfc for ; Wed, 06 Dec 2006 23:34:43 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=lCLsEwv1uZZn+JyEmE36G1pSNHTENzaE8SaKwiwtCkgGqv8AMmtbQvRAb/Q/J3m6CiHdyBPdEwNb4RV1BEL/AkEoQaJelNtud2dn2VNhwsCBhUfABiNMAv/utLUMqqanxrqSct65INKQHnCFwXIUpOJ5AsLEpJEo/YinM59zsdc= Received: by 10.49.7.10 with SMTP id k10mr3411715nfi.1165476883430; Wed, 06 Dec 2006 23:34:43 -0800 (PST) Received: by 10.78.123.2 with HTTP; Wed, 6 Dec 2006 23:34:43 -0800 (PST) Message-ID: Date: Thu, 7 Dec 2006 08:34:43 +0100 From: "Franck Bui-Huu" To: "Atsushi Nemoto" Subject: Re: [PATCH] Import updates from i386's i8259.c Cc: ralf@linux-mips.org, linux-mips@linux-mips.org In-Reply-To: <20061207.121702.108739943.nemoto@toshiba-tops.co.jp> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <20061205194907.GA1088@linux-mips.org> <20061205195702.GA2097@linux-mips.org> <20061207.121702.108739943.nemoto@toshiba-tops.co.jp> 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: 13390 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 On 12/7/06, Atsushi Nemoto wrote: > On Wed, 6 Dec 2006 09:40:50 +0100, "Franck Bui-Huu" wrote: > > Atsushi, could you take care of removing "select > > GENERIC_HARDIRQS_NO__DO_IRQ" in your patch where needed ? specially > > all boards based on NEC VR41XX cpu. > > You mean "adding" ? I think now we can select > GENERIC_HARDIRQS_NO__DO_IRQ for all MACH_VR41XX boards. > yes sorry. I was thinking of removing all of them in arch/mips/vr41xx/Kconfig, and add it to MACH_VR41XX config and all others configs that were using the i8259. -- Franck From hch@lst.de Thu Dec 7 09:46:47 2006 Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 07 Dec 2006 09:46:51 +0000 (GMT) Received: from verein.lst.de ([213.95.11.210]:932 "EHLO mail.lst.de") by ftp.linux-mips.org with ESMTP id S20038860AbWLGJqr (ORCPT ); Thu, 7 Dec 2006 09:46:47 +0000 Received: from verein.lst.de (localhost [127.0.0.1]) by mail.lst.de (8.12.3/8.12.3/Debian-7.1) with ESMTP id kB79kesi030447 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Thu, 7 Dec 2006 10:46:40 +0100 Received: (from hch@localhost) by verein.lst.de (8.12.3/8.12.3/Debian-6.6) id kB79kdbj030445; Thu, 7 Dec 2006 10:46:39 +0100 Date: Thu, 7 Dec 2006 10:46:39 +0100 From: Christoph Hellwig To: linux-mips@linux-mips.org, linux-kernel@vger.kernel.org, mingo@elte.hu Subject: Re: [MIPS] Import updates from i386's i8259.c Message-ID: <20061207094639.GA30260@lst.de> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.3.28i X-Scanned-By: MIMEDefang 2.39 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: 13391 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: hch@lst.de Precedence: bulk X-list: linux-mips On Wed, Dec 06, 2006 at 08:15:47PM +0000, linux-mips@linux-mips.org wrote: > Author: Atsushi Nemoto Thu Dec 7 02:04:17 2006 +0900 > Comitter: Ralf Baechle Wed Dec 6 20:10:54 2006 +0000 > Commit: bf8cfe1360932f191a3ea8d47c773c008ec32cd7 > Gitweb: http://www.linux-mips.org/g/linux/bf8cfe13 > Branch: master > > Import many updates from i386's i8259.c, especially genirq transitions. Shouldn't we try to share i8259.c over the various architectures that use this controller? With the generic hardirq framework that should be possible. From ralf@linux-mips.org Thu Dec 7 11:50:41 2006 Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 07 Dec 2006 11:50:55 +0000 (GMT) Received: from localhost.localdomain ([127.0.0.1]:29583 "EHLO dl5rb.ham-radio-op.net") by ftp.linux-mips.org with ESMTP id S20039152AbWLGLul (ORCPT ); Thu, 7 Dec 2006 11:50:41 +0000 Received: from denk.linux-mips.net (denk.linux-mips.net [127.0.0.1]) by dl5rb.ham-radio-op.net (8.13.8/8.13.8) with ESMTP id kB7BobPJ017271; Thu, 7 Dec 2006 11:50:38 GMT Received: (from ralf@localhost) by denk.linux-mips.net (8.13.8/8.13.8/Submit) id kB7BoZFd017270; Thu, 7 Dec 2006 11:50:35 GMT Date: Thu, 7 Dec 2006 11:50:35 +0000 From: Ralf Baechle To: Atsushi Nemoto Cc: vagabon.xyz@gmail.com, linux-mips@linux-mips.org Subject: Re: [PATCH] Import updates from i386's i8259.c Message-ID: <20061207115035.GA15386@linux-mips.org> References: <20061205194907.GA1088@linux-mips.org> <20061205195702.GA2097@linux-mips.org> <20061207.121702.108739943.nemoto@toshiba-tops.co.jp> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20061207.121702.108739943.nemoto@toshiba-tops.co.jp> User-Agent: Mutt/1.4.2.2i 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: 13392 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, Dec 07, 2006 at 12:17:02PM +0900, Atsushi Nemoto wrote: > You mean "adding" ? I think now we can select > GENERIC_HARDIRQS_NO__DO_IRQ for all MACH_VR41XX boards. > > Also I think most codes in vr41xx/nec-cmbvr4133/irq.c can be removed > if we made I8259A_IRQ_BASE customizable, but that would be another > story... This number is fixed to zero because that's what all the old ISA drivers expect, the ISA boards have printed on etc... Ralf From a.voropay@equant.ru Thu Dec 7 12:23:30 2006 Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 07 Dec 2006 12:23:35 +0000 (GMT) Received: from mx.globalone.ru ([194.84.254.251]:47017 "EHLO mx.globalone.ru") by ftp.linux-mips.org with ESMTP id S20039158AbWLGMXa (ORCPT ); Thu, 7 Dec 2006 12:23:30 +0000 Received: from mx.globalone.ru (localhost [127.0.0.1]) by mx.globalone.ru (8.13.1/8.13.1) with ESMTP id kB7CNNwF020577 for ; Thu, 7 Dec 2006 15:23:24 +0300 Received: from smtp.globalone.ru (smtp.globalone.ru [172.16.38.5]) by mx.globalone.ru (8.13.1/8.13.1) with ESMTP id kB7CN9nU020398 for ; Thu, 7 Dec 2006 15:23:09 +0300 Received: from voropaya ([172.16.38.7]) by smtp.globalone.ru (Netscape Messaging Server 4.15) with SMTP id J9WL2L00.5GX for ; Thu, 7 Dec 2006 15:23:09 +0300 Message-ID: <385101c719fa$80448100$e90d11ac@spb.in.rosprint.ru> From: "Alexander Voropay" To: References: <20061207094639.GA30260@lst.de> Subject: Re: [MIPS] Import updates from i386's i8259.c Date: Thu, 7 Dec 2006 15:21:55 +0300 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Scanned-By: MIMEDefang 2.56 on 172.16.38.2 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: 13393 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: a.voropay@orange-ftgroup.ru Precedence: bulk X-list: linux-mips "Christoph Hellwig" wrote: >> Import many updates from i386's i8259.c, especially genirq transitions. > > Shouldn't we try to share i8259.c over the various architectures that > use this controller? With the generic hardirq framework that should be > possible. The "i8259" should be under "ISA" or "EISA" Kconfig option. AFAIK, all known ISA chipsets contains dual i8259 controllers: LPC on the PCI-ISA bridge (Cobalt, Malta, ...), Intel 82430 EISA Mongoose chipset (Indigo2 IP22, Magnum/Jazz, SNI RM-200, ...) -- -=AV=- From ralf@linux-mips.org Thu Dec 7 12:33:24 2006 Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 07 Dec 2006 12:33:26 +0000 (GMT) Received: from localhost.localdomain ([127.0.0.1]:62124 "EHLO dl5rb.ham-radio-op.net") by ftp.linux-mips.org with ESMTP id S20039163AbWLGMdY (ORCPT ); Thu, 7 Dec 2006 12:33:24 +0000 Received: from denk.linux-mips.net (denk.linux-mips.net [127.0.0.1]) by dl5rb.ham-radio-op.net (8.13.8/8.13.8) with ESMTP id kB7CXMJv026021; Thu, 7 Dec 2006 12:33:22 GMT Received: (from ralf@localhost) by denk.linux-mips.net (8.13.8/8.13.8/Submit) id kB7CXLuO026020; Thu, 7 Dec 2006 12:33:21 GMT Date: Thu, 7 Dec 2006 12:33:21 +0000 From: Ralf Baechle To: Christoph Hellwig Cc: linux-mips@linux-mips.org, linux-kernel@vger.kernel.org, mingo@elte.hu Subject: Re: [MIPS] Import updates from i386's i8259.c Message-ID: <20061207123321.GB15386@linux-mips.org> References: <20061207094639.GA30260@lst.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20061207094639.GA30260@lst.de> User-Agent: Mutt/1.4.2.2i 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: 13394 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, Dec 07, 2006 at 10:46:39AM +0100, Christoph Hellwig wrote: > On Wed, Dec 06, 2006 at 08:15:47PM +0000, linux-mips@linux-mips.org wrote: > > Author: Atsushi Nemoto Thu Dec 7 02:04:17 2006 +0900 > > Comitter: Ralf Baechle Wed Dec 6 20:10:54 2006 +0000 > > Commit: bf8cfe1360932f191a3ea8d47c773c008ec32cd7 > > Gitweb: http://www.linux-mips.org/g/linux/bf8cfe13 > > Branch: master > > > > Import many updates from i386's i8259.c, especially genirq transitions. > > Shouldn't we try to share i8259.c over the various architectures that > use this controller? With the generic hardirq framework that should be > possible. See http://www.linux-mips.org/cgi-bin/mesg.cgi?a=linux-mips&i=20061206203259.GA10170%40linux-mips.org ;-) The MIPS version of i8259 is already sharable that is all the code that doesn't immediately deal with the i8259 PIC has been removed. A few small things will need still need attention. i386 uses this silly optimization in cached_master_mask / cached_slave_mask that depends on little endian byte order. i386 programs ICW2 with 0x20 while MIPS uses I8259A_IRQ_BASE. And the i386 version has various stuff such as the FPU interrupt handler which are not immediately i8259A-related in i8259.c. Ralf From macro@linux-mips.org Thu Dec 7 13:32:35 2006 Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 07 Dec 2006 13:32:42 +0000 (GMT) Received: from pollux.ds.pg.gda.pl ([153.19.208.7]:30471 "EHLO pollux.ds.pg.gda.pl") by ftp.linux-mips.org with ESMTP id S20039091AbWLGNcf (ORCPT ); Thu, 7 Dec 2006 13:32:35 +0000 Received: from localhost (localhost [127.0.0.1]) by pollux.ds.pg.gda.pl (Postfix) with ESMTP id 7141AFE271; Thu, 7 Dec 2006 14:32:20 +0100 (CET) X-Virus-Scanned: by amavisd-new at pollux.ds.pg.gda.pl Received: from pollux.ds.pg.gda.pl ([127.0.0.1]) by localhost (pollux.ds.pg.gda.pl [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z9fdumk-ROr1; Thu, 7 Dec 2006 14:32:20 +0100 (CET) Received: from piorun.ds.pg.gda.pl (piorun.ds.pg.gda.pl [153.19.208.8]) by pollux.ds.pg.gda.pl (Postfix) with ESMTP id EB90FFE255; Thu, 7 Dec 2006 14:32:19 +0100 (CET) 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 kB7DWTMv024230; Thu, 7 Dec 2006 14:32:29 +0100 Date: Thu, 7 Dec 2006 13:32:25 +0000 (GMT) From: "Maciej W. Rozycki" To: Ralf Baechle cc: Atsushi Nemoto , vagabon.xyz@gmail.com, linux-mips@linux-mips.org Subject: Re: [PATCH] Import updates from i386's i8259.c In-Reply-To: <20061207115035.GA15386@linux-mips.org> Message-ID: References: <20061205194907.GA1088@linux-mips.org> <20061205195702.GA2097@linux-mips.org> <20061207.121702.108739943.nemoto@toshiba-tops.co.jp> <20061207115035.GA15386@linux-mips.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: ClamAV 0.88.6/2299/Thu Dec 7 08:36:50 2006 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: 13395 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, 7 Dec 2006, Ralf Baechle wrote: > > Also I think most codes in vr41xx/nec-cmbvr4133/irq.c can be removed > > if we made I8259A_IRQ_BASE customizable, but that would be another > > story... > > This number is fixed to zero because that's what all the old ISA drivers > expect, the ISA boards have printed on etc... Well, it's probably that nobody has been brave enough to tackle it yet. ;-) Maciej From ralf@linux-mips.org Thu Dec 7 13:37:50 2006 Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 07 Dec 2006 13:37:52 +0000 (GMT) Received: from localhost.localdomain ([127.0.0.1]:6820 "EHLO dl5rb.ham-radio-op.net") by ftp.linux-mips.org with ESMTP id S20039159AbWLGNhu (ORCPT ); Thu, 7 Dec 2006 13:37:50 +0000 Received: from denk.linux-mips.net (denk.linux-mips.net [127.0.0.1]) by dl5rb.ham-radio-op.net (8.13.8/8.13.8) with ESMTP id kB7Dbjqu003401; Thu, 7 Dec 2006 13:37:46 GMT Received: (from ralf@localhost) by denk.linux-mips.net (8.13.8/8.13.8/Submit) id kB7Dbhbq003400; Thu, 7 Dec 2006 13:37:43 GMT Date: Thu, 7 Dec 2006 13:37:43 +0000 From: Ralf Baechle To: "Maciej W. Rozycki" Cc: Atsushi Nemoto , vagabon.xyz@gmail.com, linux-mips@linux-mips.org Subject: Re: [PATCH] Import updates from i386's i8259.c Message-ID: <20061207133743.GA3373@linux-mips.org> References: <20061205194907.GA1088@linux-mips.org> <20061205195702.GA2097@linux-mips.org> <20061207.121702.108739943.nemoto@toshiba-tops.co.jp> <20061207115035.GA15386@linux-mips.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.2i 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: 13396 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, Dec 07, 2006 at 01:32:25PM +0000, Maciej W. Rozycki wrote: > From: "Maciej W. Rozycki" > > > Also I think most codes in vr41xx/nec-cmbvr4133/irq.c can be removed > > > if we made I8259A_IRQ_BASE customizable, but that would be another > > > story... > > > > This number is fixed to zero because that's what all the old ISA drivers > > expect, the ISA boards have printed on etc... > > Well, it's probably that nobody has been brave enough to tackle it yet. > ;-) I just think this problem should better be unsolved ;-) Ralf From sshtylyov@ru.mvista.com Thu Dec 7 13:50:20 2006 Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 07 Dec 2006 13:50:25 +0000 (GMT) Received: from h155.mvista.com ([63.81.120.155]:14469 "EHLO imap.sh.mvista.com") by ftp.linux-mips.org with ESMTP id S20038561AbWLGNuU (ORCPT ); Thu, 7 Dec 2006 13:50:20 +0000 Received: from [192.168.1.248] (unknown [10.150.0.9]) by imap.sh.mvista.com (Postfix) with ESMTP id CAFAE3EC9; Thu, 7 Dec 2006 05:50:09 -0800 (PST) Message-ID: <45781C70.30405@ru.mvista.com> Date: Thu, 07 Dec 2006 16:51:44 +0300 From: Sergei Shtylyov Organization: MontaVista Software Inc. User-Agent: Mozilla/5.0 (X11; U; Linux i686; rv:1.7.2) Gecko/20040803 X-Accept-Language: ru, en-us, en-gb MIME-Version: 1.0 To: Ralf Baechle Cc: Atsushi Nemoto , vagabon.xyz@gmail.com, linux-mips@linux-mips.org Subject: Re: [PATCH] Import updates from i386's i8259.c References: <20061205194907.GA1088@linux-mips.org> <20061205195702.GA2097@linux-mips.org> <20061207.121702.108739943.nemoto@toshiba-tops.co.jp> <20061207115035.GA15386@linux-mips.org> In-Reply-To: <20061207115035.GA15386@linux-mips.org> Content-Type: text/plain; charset=us-ascii; 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: 13397 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: sshtylyov@ru.mvista.com Precedence: bulk X-list: linux-mips Hello. Ralf Baechle wrote: > On Thu, Dec 07, 2006 at 12:17:02PM +0900, Atsushi Nemoto wrote: >>You mean "adding" ? I think now we can select >>GENERIC_HARDIRQS_NO__DO_IRQ for all MACH_VR41XX boards. >>Also I think most codes in vr41xx/nec-cmbvr4133/irq.c can be removed >>if we made I8259A_IRQ_BASE customizable, but that would be another >>story... > This number is fixed to zero because that's what all the old ISA drivers > expect, the ISA boards have printed on etc... It's not really related as 8259 is programmed to generate vectors 0x20 to 0x2F for x86 but the the IRQs start from zero anyway... > Ralf WBR, Sergei From sshtylyov@ru.mvista.com Thu Dec 7 13:53:02 2006 Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 07 Dec 2006 13:53:06 +0000 (GMT) Received: from h155.mvista.com ([63.81.120.155]:20357 "EHLO imap.sh.mvista.com") by ftp.linux-mips.org with ESMTP id S20039152AbWLGNxC (ORCPT ); Thu, 7 Dec 2006 13:53:02 +0000 Received: from [192.168.1.248] (unknown [10.150.0.9]) by imap.sh.mvista.com (Postfix) with ESMTP id 663873EC9; Thu, 7 Dec 2006 05:52:59 -0800 (PST) Message-ID: <45781D1C.40805@ru.mvista.com> Date: Thu, 07 Dec 2006 16:54:36 +0300 From: Sergei Shtylyov Organization: MontaVista Software Inc. User-Agent: Mozilla/5.0 (X11; U; Linux i686; rv:1.7.2) Gecko/20040803 X-Accept-Language: ru, en-us, en-gb MIME-Version: 1.0 To: Alexander Voropay Cc: linux-mips@linux-mips.org Subject: Re: [MIPS] Import updates from i386's i8259.c References: <20061207094639.GA30260@lst.de> <385101c719fa$80448100$e90d11ac@spb.in.rosprint.ru> In-Reply-To: <385101c719fa$80448100$e90d11ac@spb.in.rosprint.ru> Content-Type: text/plain; charset=us-ascii; 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: 13398 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: sshtylyov@ru.mvista.com Precedence: bulk X-list: linux-mips Hello. Alexander Voropay wrote: >>> Import many updates from i386's i8259.c, especially genirq transitions. >> Shouldn't we try to share i8259.c over the various architectures that >> use this controller? With the generic hardirq framework that should be >> possible. > The "i8259" should be under "ISA" or "EISA" Kconfig option. It's not really bus specific actually. I'm sure MCA systems had it as well. > -- > -=AV=- WBR, Sergei From macro@linux-mips.org Thu Dec 7 15:03:56 2006 Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 07 Dec 2006 15:04:02 +0000 (GMT) Received: from pollux.ds.pg.gda.pl ([153.19.208.7]:8210 "EHLO pollux.ds.pg.gda.pl") by ftp.linux-mips.org with ESMTP id S20027577AbWLGPD4 (ORCPT ); Thu, 7 Dec 2006 15:03:56 +0000 Received: from localhost (localhost [127.0.0.1]) by pollux.ds.pg.gda.pl (Postfix) with ESMTP id A5F53FE276; Thu, 7 Dec 2006 16:03:42 +0100 (CET) X-Virus-Scanned: by amavisd-new at pollux.ds.pg.gda.pl Received: from pollux.ds.pg.gda.pl ([127.0.0.1]) by localhost (pollux.ds.pg.gda.pl [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6l463pDaGZMj; Thu, 7 Dec 2006 16:03:42 +0100 (CET) Received: from piorun.ds.pg.gda.pl (piorun.ds.pg.gda.pl [153.19.208.8]) by pollux.ds.pg.gda.pl (Postfix) with ESMTP id 42BBAFE272; Thu, 7 Dec 2006 16:03:42 +0100 (CET) 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 kB7F3qZ3026535; Thu, 7 Dec 2006 16:03:52 +0100 Date: Thu, 7 Dec 2006 15:03:48 +0000 (GMT) From: "Maciej W. Rozycki" To: Sergei Shtylyov cc: Ralf Baechle , Atsushi Nemoto , vagabon.xyz@gmail.com, linux-mips@linux-mips.org Subject: Re: [PATCH] Import updates from i386's i8259.c In-Reply-To: <45781C70.30405@ru.mvista.com> Message-ID: References: <20061205194907.GA1088@linux-mips.org> <20061205195702.GA2097@linux-mips.org> <20061207.121702.108739943.nemoto@toshiba-tops.co.jp> <20061207115035.GA15386@linux-mips.org> <45781C70.30405@ru.mvista.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: ClamAV 0.88.6/2299/Thu Dec 7 08:36:50 2006 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: 13399 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, 7 Dec 2006, Sergei Shtylyov wrote: > It's not really related as 8259 is programmed to generate vectors 0x20 to > 0x2F for x86 but the the IRQs start from zero anyway... In Linux most platforms define IRQ numbers in the sense of physical lines (or wires if you prefer) routed to inputs of interrupt controllers rather than vectors which may or may not be used by a given platform (and to complicate things further, the presence of which may be software-configurable). Of course if a message passing concept is used for interrupt delivery (be it a simple chain or a more complicated protocol), then a different numbering scheme may be required and exposing vectors may be a necessity. Even with the i8259A there is no need to use its vector at all if the processor being interrupted does not issue INTA cycles itself. Maciej From ralf@linux-mips.org Thu Dec 7 15:09:34 2006 Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 07 Dec 2006 15:09:36 +0000 (GMT) Received: from localhost.localdomain ([127.0.0.1]:63932 "EHLO dl5rb.ham-radio-op.net") by ftp.linux-mips.org with ESMTP id S20037433AbWLGPJe (ORCPT ); Thu, 7 Dec 2006 15:09:34 +0000 Received: from denk.linux-mips.net (denk.linux-mips.net [127.0.0.1]) by dl5rb.ham-radio-op.net (8.13.8/8.13.8) with ESMTP id kB7F9VPO008090; Thu, 7 Dec 2006 15:09:31 GMT Received: (from ralf@localhost) by denk.linux-mips.net (8.13.8/8.13.8/Submit) id kB7F9TUB008089; Thu, 7 Dec 2006 15:09:29 GMT Date: Thu, 7 Dec 2006 15:09:29 +0000 From: Ralf Baechle To: "Maciej W. Rozycki" Cc: Sergei Shtylyov , Atsushi Nemoto , vagabon.xyz@gmail.com, linux-mips@linux-mips.org Subject: Re: [PATCH] Import updates from i386's i8259.c Message-ID: <20061207150929.GA4156@linux-mips.org> References: <20061205194907.GA1088@linux-mips.org> <20061205195702.GA2097@linux-mips.org> <20061207.121702.108739943.nemoto@toshiba-tops.co.jp> <20061207115035.GA15386@linux-mips.org> <45781C70.30405@ru.mvista.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.2i 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: 13400 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, Dec 07, 2006 at 03:03:48PM +0000, Maciej W. Rozycki wrote: > > It's not really related as 8259 is programmed to generate vectors 0x20 to > > 0x2F for x86 but the the IRQs start from zero anyway... > > In Linux most platforms define IRQ numbers in the sense of physical lines > (or wires if you prefer) routed to inputs of interrupt controllers rather > than vectors which may or may not be used by a given platform (and to > complicate things further, the presence of which may be > software-configurable). Of course if a message passing concept is used > for interrupt delivery (be it a simple chain or a more complicated > protocol), then a different numbering scheme may be required and exposing > vectors may be a necessity. > > Even with the i8259A there is no need to use its vector at all if the > processor being interrupted does not issue INTA cycles itself. The Jazz family and the RM200 have registers to perform interrupt acknowledge cycles. Linux doesn't use it on the RM200 because of a funny PCI ASIC bug which may cause certain interrupts getting lost until the PIC is fully initialized. I never looked into the details since the SNI recommendation was to just avoid that feature. Ralf From vitalywool@gmail.com Thu Dec 7 15:22:42 2006 Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 07 Dec 2006 15:22:49 +0000 (GMT) Received: from rtsoft2.corbina.net ([85.21.88.2]:10433 "HELO mail.dev.rtsoft.ru") by ftp.linux-mips.org with SMTP id S20037524AbWLGPWm (ORCPT ); Thu, 7 Dec 2006 15:22:42 +0000 Received: (qmail 19980 invoked from network); 7 Dec 2006 15:23:14 -0000 Received: from laja.dev.rtsoft.ru.dev.rtsoft.ru (HELO laja) (192.168.1.205) by mail.dev.rtsoft.ru with SMTP; 7 Dec 2006 15:23:14 -0000 Date: Thu, 7 Dec 2006 18:22:34 +0300 From: Vitaly Wool To: ralf@linux-mips.org Cc: linux-mips@linux-mips.org Subject: [PATCH] add STB810 support (Philips PNX8550-based) Message-Id: <20061207182234.83212939.vitalywool@gmail.com> X-Mailer: Sylpheed version 2.2.4 (GTK+ 2.8.20; 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: 13401 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: vitalywool@gmail.com Precedence: bulk X-list: linux-mips Hello Ralf, please find the patch that adds support for STB810 below. arch/mips/Kconfig | 5 arch/mips/Makefile | 5 arch/mips/configs/pnx8550-stb810_defconfig | 1117 +++++++++++++++++++++++++ arch/mips/kernel/head.S | 2 arch/mips/philips/pnx8550/common/prom.c | 20 arch/mips/philips/pnx8550/stb810/Makefile | 4 arch/mips/philips/pnx8550/stb810/board_setup.c | 56 + arch/mips/philips/pnx8550/stb810/irqmap.c | 23 arch/mips/philips/pnx8550/stb810/prom_init.c | 49 + include/asm-mips/bootinfo.h | 1 10 files changed, 1267 insertions(+), 15 deletions(-) Signed-off-by: Vitaly Wool Index: linux-mips.git/arch/mips/philips/pnx8550/stb810/Makefile =================================================================== --- /dev/null 1970-01-01 00:00:00.000000000 +0000 +++ linux-mips.git/arch/mips/philips/pnx8550/stb810/Makefile 2006-12-07 18:21:04.000000000 +0300 @@ -0,0 +1,4 @@ + +# Makefile for the Philips STB810 Board. + +lib-y := prom_init.o board_setup.o irqmap.o Index: linux-mips.git/arch/mips/philips/pnx8550/stb810/board_setup.c =================================================================== --- /dev/null 1970-01-01 00:00:00.000000000 +0000 +++ linux-mips.git/arch/mips/philips/pnx8550/stb810/board_setup.c 2006-12-07 18:21:04.000000000 +0300 @@ -0,0 +1,56 @@ +/* + * STB810 specific board startup routines. + * + * Based on the arch/mips/philips/pnx8550/jbs/board_setup.c + * + * Author: MontaVista Software, Inc. + * source@mvista.com + * + * Copyright 2005 MontaVista Software Inc. + * + * 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. + */ + +#include +#include +#include +#include +#include +#include +#include + +#include +#include +#include +#include +#include +#include + +#include + +/* CP0 hazard avoidance. */ +#define BARRIER __asm__ __volatile__(".set noreorder\n\t" \ + "nop; nop; nop; nop; nop; nop;\n\t" \ + ".set reorder\n\t") + +void __init board_setup(void) +{ + unsigned long config0, configpr; + + config0 = read_c0_config(); + + /* clear all three cache coherency fields */ + config0 &= ~(0x7 | (7<<25) | (7<<28)); + config0 |= (CONF_CM_DEFAULT | (CONF_CM_DEFAULT<<25) | + (CONF_CM_DEFAULT<<28)); + write_c0_config(config0); + BARRIER; + + configpr = read_c0_config7(); + configpr |= (1<<19); /* enable tlb */ + write_c0_config7(configpr); + BARRIER; +} Index: linux-mips.git/arch/mips/philips/pnx8550/stb810/irqmap.c =================================================================== --- /dev/null 1970-01-01 00:00:00.000000000 +0000 +++ linux-mips.git/arch/mips/philips/pnx8550/stb810/irqmap.c 2006-12-07 18:21:04.000000000 +0300 @@ -0,0 +1,23 @@ +/* + * Philips STB810 board irqmap. + * + * Author: MontaVista Software, Inc. + * source@mvista.com + * + * Copyright 2005 MontaVista Software Inc. + * + * 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. + */ + +#include +#include + +char irq_tab_jbs[][5] __initdata = { + [8] = { -1, PNX8550_INT_PCI_INTA, 0xff, 0xff, 0xff}, + [9] = { -1, PNX8550_INT_PCI_INTA, 0xff, 0xff, 0xff}, + [10] = { -1, PNX8550_INT_PCI_INTA, 0xff, 0xff, 0xff}, +}; + Index: linux-mips.git/arch/mips/philips/pnx8550/stb810/prom_init.c =================================================================== --- /dev/null 1970-01-01 00:00:00.000000000 +0000 +++ linux-mips.git/arch/mips/philips/pnx8550/stb810/prom_init.c 2006-12-07 18:21:04.000000000 +0300 @@ -0,0 +1,49 @@ +/* + * STB810 specific prom routines + * + * Author: MontaVista Software, Inc. + * source@mvista.com + * + * Copyright 2005 MontaVista Software Inc. + * + * 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. + */ + +#include +#include +#include +#include +#include +#include +#include +#include + +int prom_argc; +char **prom_argv, **prom_envp; +extern void __init prom_init_cmdline(void); +extern char *prom_getenv(char *envname); + +const char *get_system_type(void) +{ + return "Philips PNX8550/STB810"; +} + +void __init prom_init(void) +{ + + unsigned long memsize; + prom_argc = (int) fw_arg0; + prom_argv = (char **) fw_arg1; + prom_envp = (char **) fw_arg2; + + prom_init_cmdline(); + + mips_machgroup = MACH_GROUP_PHILIPS; + mips_machtype = MACH_PHILIPS_STB810; + + memsize = 0x08000000; /* Trimedia uses memory above */ + add_memory_region(0, memsize, BOOT_MEM_RAM); +} Index: linux-mips.git/include/asm-mips/bootinfo.h =================================================================== --- linux-mips.git.orig/include/asm-mips/bootinfo.h 2006-12-07 18:20:47.000000000 +0300 +++ linux-mips.git/include/asm-mips/bootinfo.h 2006-12-07 18:21:04.000000000 +0300 @@ -131,6 +131,7 @@ #define MACH_PHILIPS_NINO 0 /* Nino */ #define MACH_PHILIPS_VELO 1 /* Velo */ #define MACH_PHILIPS_JBS 2 /* JBS */ +#define MACH_PHILIPS_STB810 3 /* STB810 */ /* * Valid machtype for group SIBYTE Index: linux-mips.git/arch/mips/philips/pnx8550/common/prom.c =================================================================== --- linux-mips.git.orig/arch/mips/philips/pnx8550/common/prom.c 2006-12-07 18:20:47.000000000 +0300 +++ linux-mips.git/arch/mips/philips/pnx8550/common/prom.c 2006-12-07 18:21:04.000000000 +0300 @@ -35,23 +35,15 @@ return &(arcs_cmdline[0]); } -void prom_init_cmdline(void) +void __init prom_init_cmdline(void) { - char *cp; - int actr; - - actr = 1; /* Always ignore argv[0] */ + int i; - cp = &(arcs_cmdline[0]); - while(actr < prom_argc) { - strcpy(cp, prom_argv[actr]); - cp += strlen(prom_argv[actr]); - *cp++ = ' '; - actr++; + arcs_cmdline[0] = '\0'; + for (i = 0; i < prom_argc; i++) { + strcat(arcs_cmdline, prom_argv[i]); + strcat(arcs_cmdline, " "); } - if (cp != &(arcs_cmdline[0])) /* get rid of trailing space */ - --cp; - *cp = '\0'; } char *prom_getenv(char *envname) Index: linux-mips.git/arch/mips/kernel/head.S =================================================================== --- linux-mips.git.orig/arch/mips/kernel/head.S 2006-12-07 18:20:47.000000000 +0300 +++ linux-mips.git/arch/mips/kernel/head.S 2006-12-07 18:21:04.000000000 +0300 @@ -138,7 +138,7 @@ EXPORT(stext) # used for profiling EXPORT(_stext) -#if defined(CONFIG_QEMU) || defined(CONFIG_MIPS_SIM) +#if defined(CONFIG_QEMU) || defined(CONFIG_MIPS_SIM) || defined(CONFIG_PNX8550_STB810) /* * Give us a fighting chance of running if execution beings at the * kernel load address. This is needed because this platform does Index: linux-mips.git/arch/mips/configs/pnx8550-stb810_defconfig =================================================================== --- /dev/null 1970-01-01 00:00:00.000000000 +0000 +++ linux-mips.git/arch/mips/configs/pnx8550-stb810_defconfig 2006-12-07 18:21:04.000000000 +0300 @@ -0,0 +1,1777 @@ +# +# Automatically generated make config: don't edit +# Linux kernel version: 2.6.19-rc5 +# Wed Nov 8 13:46:57 2006 +# +CONFIG_ARM=y +# CONFIG_GENERIC_TIME is not set +CONFIG_MMU=y +CONFIG_GENERIC_HARDIRQS=y +CONFIG_TRACE_IRQFLAGS_SUPPORT=y +CONFIG_HARDIRQS_SW_RESEND=y +CONFIG_GENERIC_IRQ_PROBE=y +CONFIG_RWSEM_GENERIC_SPINLOCK=y +CONFIG_GENERIC_HWEIGHT=y +CONFIG_GENERIC_CALIBRATE_DELAY=y +CONFIG_VECTORS_BASE=0xffff0000 +CONFIG_DEFCONFIG_LIST="/lib/modules/$UNAME_RELEASE/.config" + +# +# Code maturity level options +# +CONFIG_EXPERIMENTAL=y +CONFIG_BROKEN_ON_SMP=y +CONFIG_LOCK_KERNEL=y +CONFIG_INIT_ENV_ARG_LIMIT=32 + +# +# General setup +# +CONFIG_LOCALVERSION="" +CONFIG_LOCALVERSION_AUTO=y +CONFIG_SWAP=y +CONFIG_SYSVIPC=y +# CONFIG_IPC_NS is not set +CONFIG_POSIX_MQUEUE=y +CONFIG_BSD_PROCESS_ACCT=y +# CONFIG_BSD_PROCESS_ACCT_V3 is not set +# CONFIG_TASKSTATS is not set +# CONFIG_UTS_NS is not set +# CONFIG_AUDIT is not set +# CONFIG_IKCONFIG is not set +# CONFIG_RELAY is not set +CONFIG_INITRAMFS_SOURCE="" +CONFIG_CC_OPTIMIZE_FOR_SIZE=y +CONFIG_SYSCTL=y +CONFIG_EMBEDDED=y +CONFIG_UID16=y +# CONFIG_SYSCTL_SYSCALL is not set +CONFIG_KALLSYMS=y +# CONFIG_KALLSYMS_ALL is not set +# 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_EPOLL=y +CONFIG_SHMEM=y +CONFIG_SLAB=y +CONFIG_VM_EVENT_COUNTERS=y +CONFIG_RT_MUTEXES=y +# CONFIG_TINY_SHMEM is not set +CONFIG_BASE_SMALL=0 +# CONFIG_SLOB is not set + +# +# Loadable module support +# +CONFIG_MODULES=y +CONFIG_MODULE_UNLOAD=y +CONFIG_MODULE_FORCE_UNLOAD=y +CONFIG_MODVERSIONS=y +CONFIG_MODULE_SRCVERSION_ALL=y +CONFIG_KMOD=y + +# +# Block layer +# +CONFIG_BLOCK=y +# CONFIG_BLK_DEV_IO_TRACE is not set + +# +# IO Schedulers +# +CONFIG_IOSCHED_NOOP=y +CONFIG_IOSCHED_AS=y +CONFIG_IOSCHED_DEADLINE=y +CONFIG_IOSCHED_CFQ=y +CONFIG_DEFAULT_AS=y +# CONFIG_DEFAULT_DEADLINE is not set +# CONFIG_DEFAULT_CFQ is not set +# CONFIG_DEFAULT_NOOP is not set +CONFIG_DEFAULT_IOSCHED="anticipatory" + +# +# System Type +# +# CONFIG_ARCH_AAEC2000 is not set +# CONFIG_ARCH_INTEGRATOR is not set +# CONFIG_ARCH_REALVIEW is not set +# CONFIG_ARCH_VERSATILE is not set +# CONFIG_ARCH_AT91 is not set +# CONFIG_ARCH_CLPS7500 is not set +# CONFIG_ARCH_CLPS711X is not set +# CONFIG_ARCH_CO285 is not set +# CONFIG_ARCH_EBSA110 is not set +# CONFIG_ARCH_EP93XX is not set +# CONFIG_ARCH_FOOTBRIDGE is not set +# CONFIG_ARCH_NETX is not set +# CONFIG_ARCH_H720X is not set +# CONFIG_ARCH_IMX is not set +# CONFIG_ARCH_IOP32X is not set +# CONFIG_ARCH_IOP33X is not set +# CONFIG_ARCH_IXP4XX is not set +# CONFIG_ARCH_IXP2000 is not set +# CONFIG_ARCH_IXP23XX is not set +# CONFIG_ARCH_L7200 is not set +CONFIG_ARCH_PNX4008=y +# CONFIG_ARCH_PXA is not set +# CONFIG_ARCH_RPC is not set +# CONFIG_ARCH_SA1100 is not set +# CONFIG_ARCH_S3C2410 is not set +# CONFIG_ARCH_SHARK is not set +# CONFIG_ARCH_LH7A40X is not set +# CONFIG_ARCH_OMAP is not set + +# +# Processor Type +# +CONFIG_CPU_32=y +CONFIG_CPU_ARM926T=y +CONFIG_CPU_32v5=y +CONFIG_CPU_ABRT_EV5TJ=y +CONFIG_CPU_CACHE_VIVT=y +CONFIG_CPU_COPY_V4WB=y +CONFIG_CPU_TLB_V4WBI=y +CONFIG_CPU_CP15=y +CONFIG_CPU_CP15_MMU=y + +# +# Processor Features +# +CONFIG_ARM_THUMB=y +# CONFIG_CPU_ICACHE_DISABLE is not set +# CONFIG_CPU_DCACHE_DISABLE is not set +# CONFIG_CPU_DCACHE_WRITETHROUGH is not set +# CONFIG_CPU_CACHE_ROUND_ROBIN is not set + +# +# Bus support +# + +# +# PCCARD (PCMCIA/CardBus) support +# +# CONFIG_PCCARD is not set + +# +# Kernel Features +# +CONFIG_PREEMPT=y +# CONFIG_NO_IDLE_HZ is not set +CONFIG_HZ=100 +# CONFIG_AEABI is not set +# CONFIG_ARCH_DISCONTIGMEM_ENABLE is not set +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=4096 +# CONFIG_RESOURCES_64BIT is not set +CONFIG_ALIGNMENT_TRAP=y + +# +# Boot options +# +CONFIG_ZBOOT_ROM_TEXT=0x0 +CONFIG_ZBOOT_ROM_BSS=0x0 +CONFIG_CMDLINE="mem=64M console=ttyS0,115200 ip=dhcp" +# CONFIG_XIP_KERNEL is not set + +# +# Floating point emulation +# + +# +# At least one emulation must be selected +# +CONFIG_FPE_NWFPE=y +# CONFIG_FPE_NWFPE_XP is not set +# CONFIG_FPE_FASTFPE is not set +# CONFIG_VFP is not set + +# +# Userspace binary formats +# +CONFIG_BINFMT_ELF=y +CONFIG_BINFMT_AOUT=m +CONFIG_BINFMT_MISC=m +# CONFIG_ARTHUR is not set + +# +# Power management options +# +CONFIG_PM=y +CONFIG_PM_LEGACY=y +# CONFIG_PM_DEBUG is not set +# CONFIG_PM_SYSFS_DEPRECATED is not set +# CONFIG_APM is not set + +# +# Networking +# +CONFIG_NET=y + +# +# Networking options +# +# CONFIG_NETDEBUG is not set +CONFIG_PACKET=y +CONFIG_PACKET_MMAP=y +CONFIG_UNIX=y +CONFIG_XFRM=y +# CONFIG_XFRM_USER is not set +# CONFIG_XFRM_SUB_POLICY is not set +# CONFIG_NET_KEY 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_FWMARK=y +CONFIG_IP_ROUTE_MULTIPATH=y +# CONFIG_IP_ROUTE_MULTIPATH_CACHED is not set +CONFIG_IP_ROUTE_VERBOSE=y +CONFIG_IP_PNP=y +CONFIG_IP_PNP_DHCP=y +CONFIG_IP_PNP_BOOTP=y +# CONFIG_IP_PNP_RARP is not set +CONFIG_NET_IPIP=y +# CONFIG_NET_IPGRE is not set +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=y +CONFIG_INET_XFRM_MODE_TRANSPORT=y +CONFIG_INET_XFRM_MODE_TUNNEL=y +CONFIG_INET_XFRM_MODE_BEET=y +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" + +# +# IP: Virtual Server Configuration +# +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_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 is not set +CONFIG_IPV6_SIT=m +CONFIG_IPV6_TUNNEL=m +# CONFIG_IPV6_MULTIPLE_TABLES is not set +# CONFIG_NETLABEL is not set +# CONFIG_NETWORK_SECMARK is not set +CONFIG_NETFILTER=y +# CONFIG_NETFILTER_DEBUG is not set +CONFIG_BRIDGE_NETFILTER=y + +# +# Core Netfilter Configuration +# +# CONFIG_NETFILTER_NETLINK is not set +# CONFIG_NETFILTER_XTABLES is not set + +# +# IP: Netfilter Configuration +# +CONFIG_IP_NF_CONNTRACK=m +CONFIG_IP_NF_CT_ACCT=y +CONFIG_IP_NF_CONNTRACK_MARK=y +# CONFIG_IP_NF_CONNTRACK_EVENTS is not set +CONFIG_IP_NF_CT_PROTO_SCTP=m +CONFIG_IP_NF_FTP=m +CONFIG_IP_NF_IRC=m +# CONFIG_IP_NF_NETBIOS_NS is not set +CONFIG_IP_NF_TFTP=m +CONFIG_IP_NF_AMANDA=m +# CONFIG_IP_NF_PPTP is not set +# CONFIG_IP_NF_H323 is not set +# CONFIG_IP_NF_SIP is not set +CONFIG_IP_NF_QUEUE=m + +# +# IPv6: Netfilter Configuration (EXPERIMENTAL) +# +CONFIG_IP6_NF_QUEUE=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 is not set + +# +# DCCP Configuration (EXPERIMENTAL) +# +# CONFIG_IP_DCCP is not set + +# +# SCTP Configuration (EXPERIMENTAL) +# +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 + +# +# TIPC Configuration (EXPERIMENTAL) +# +# CONFIG_TIPC 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=m +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_CLK_JIFFIES=y +# CONFIG_NET_SCH_CLK_GETTIMEOFDAY is not set +# CONFIG_NET_SCH_CLK_CPU is not set + +# +# 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_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 is not set +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 is not set +CONFIG_NET_CLS_RSVP=m +CONFIG_NET_CLS_RSVP6=m +# CONFIG_NET_EMATCH is not set +# CONFIG_NET_CLS_ACT is not set +CONFIG_NET_CLS_POLICE=y +# CONFIG_NET_CLS_IND is not set +CONFIG_NET_ESTIMATOR=y + +# +# Network testing +# +CONFIG_NET_PKTGEN=m +# CONFIG_HAMRADIO is not set +# CONFIG_IRDA is not set +# CONFIG_BT is not set +CONFIG_IEEE80211=m +# CONFIG_IEEE80211_DEBUG is not set +# CONFIG_IEEE80211_CRYPT_WEP is not set +CONFIG_IEEE80211_CRYPT_CCMP=m +CONFIG_IEEE80211_CRYPT_TKIP=m +# CONFIG_IEEE80211_SOFTMAC is not set +CONFIG_WIRELESS_EXT=y +CONFIG_FIB_RULES=y + +# +# Device Drivers +# + +# +# Generic Driver Options +# +CONFIG_STANDALONE=y +CONFIG_PREVENT_FIRMWARE_BUILD=y +CONFIG_FW_LOADER=y +# CONFIG_DEBUG_DRIVER is not set +# CONFIG_SYS_HYPERVISOR is not set + +# +# Connector - unified userspace <-> kernelspace linker +# +# CONFIG_CONNECTOR is not set + +# +# Memory Technology Devices (MTD) +# +CONFIG_MTD=y +# CONFIG_MTD_DEBUG is not set +CONFIG_MTD_CONCAT=y +CONFIG_MTD_PARTITIONS=y +CONFIG_MTD_REDBOOT_PARTS=y +CONFIG_MTD_REDBOOT_DIRECTORY_BLOCK=-1 +# CONFIG_MTD_REDBOOT_PARTS_UNALLOCATED is not set +# CONFIG_MTD_REDBOOT_PARTS_READONLY is not set +# CONFIG_MTD_CMDLINE_PARTS is not set +# CONFIG_MTD_AFS_PARTS is not set + +# +# User Modules And Translation Layers +# +CONFIG_MTD_CHAR=y +CONFIG_MTD_BLOCK=y +# CONFIG_FTL is not set +# CONFIG_NFTL is not set +# CONFIG_INFTL is not set +# CONFIG_RFD_FTL is not set +# CONFIG_SSFDC is not set + +# +# RAM/ROM/Flash chip drivers +# +# CONFIG_MTD_CFI is not set +# CONFIG_MTD_JEDECPROBE 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_RAM is not set +# CONFIG_MTD_ROM is not set +# CONFIG_MTD_ABSENT is not set +# CONFIG_MTD_OBSOLETE_CHIPS is not set + +# +# Mapping drivers for chip access +# +# CONFIG_MTD_COMPLEX_MAPPINGS is not set +# CONFIG_MTD_PLATRAM is not set + +# +# Self-contained MTD device drivers +# +# CONFIG_MTD_DATAFLASH is not set +CONFIG_MTD_M25P80=y +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 is not set + +# +# 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 + +# +# NAND Flash Device Drivers +# +CONFIG_MTD_NAND=y +# CONFIG_MTD_NAND_VERIFY_WRITE is not set +# CONFIG_MTD_NAND_ECC_SMC is not set +CONFIG_MTD_NAND_IDS=y +# CONFIG_MTD_NAND_DISKONCHIP is not set +CONFIG_MTD_NAND_PNX4008=y +CONFIG_MTD_NAND_PNX4008_DMA=y +CONFIG_MTD_NAND_PNX4008_HWECC=y +CONFIG_MTD_NAND_NANDSIM=y + +# +# OneNAND Flash Device Drivers +# +# CONFIG_MTD_ONENAND is not set + +# +# Parallel port support +# +# CONFIG_PARPORT is not set + +# +# Plug and Play support +# + +# +# Block devices +# +# CONFIG_BLK_DEV_COW_COMMON is not set +CONFIG_BLK_DEV_LOOP=y +CONFIG_BLK_DEV_CRYPTOLOOP=y +CONFIG_BLK_DEV_NBD=y +# CONFIG_BLK_DEV_UB is not set +CONFIG_BLK_DEV_RAM=y +CONFIG_BLK_DEV_RAM_COUNT=16 +CONFIG_BLK_DEV_RAM_SIZE=8192 +CONFIG_BLK_DEV_RAM_BLOCKSIZE=1024 +CONFIG_BLK_DEV_INITRD=y +CONFIG_CDROM_PKTCDVD=m +CONFIG_CDROM_PKTCDVD_BUFFERS=8 +# CONFIG_CDROM_PKTCDVD_WCACHE is not set +# CONFIG_ATA_OVER_ETH is not set + +# +# SCSI device support +# +# CONFIG_RAID_ATTRS is not set +CONFIG_SCSI=m +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 + +# +# SCSI Transports +# +CONFIG_SCSI_SPI_ATTRS=m +CONFIG_SCSI_FC_ATTRS=m +# CONFIG_SCSI_ISCSI_ATTRS is not set +# CONFIG_SCSI_SAS_ATTRS is not set +# CONFIG_SCSI_SAS_LIBSAS is not set + +# +# SCSI low-level drivers +# +# CONFIG_ISCSI_TCP is not set +CONFIG_SCSI_DEBUG=m + +# +# Multi-device support (RAID and LVM) +# +# CONFIG_MD is not set + +# +# Fusion MPT device support +# +# CONFIG_FUSION is not set + +# +# IEEE 1394 (FireWire) support +# + +# +# I2O device support +# + +# +# Network device support +# +CONFIG_NETDEVICES=y +CONFIG_DUMMY=m +CONFIG_BONDING=m +CONFIG_EQUALIZER=m +CONFIG_TUN=m + +# +# PHY device support +# +# CONFIG_PHYLIB is not set + +# +# Ethernet (10 or 100Mbit) +# +CONFIG_NET_ETHERNET=y +CONFIG_MII=y +# CONFIG_SMC91X is not set +# CONFIG_DM9000 is not set + +# +# Ethernet (1000 Mbit) +# + +# +# Ethernet (10000 Mbit) +# + +# +# Token Ring devices +# + +# +# Wireless LAN (non-hamradio) +# +CONFIG_NET_RADIO=y +# CONFIG_NET_WIRELESS_RTNETLINK is not set + +# +# Obsolete Wireless cards support (pre-802.11) +# +CONFIG_STRIP=m +# CONFIG_USB_ZD1201 is not set +# CONFIG_HOSTAP is not set + +# +# Wan interfaces +# +CONFIG_WAN=y +CONFIG_HDLC=m +# CONFIG_HDLC_RAW is not set +# CONFIG_HDLC_RAW_ETH is not set +# CONFIG_HDLC_CISCO is not set +# CONFIG_HDLC_FR is not set +# CONFIG_HDLC_PPP is not set +# CONFIG_HDLC_X25 is not set +CONFIG_DLCI=m +CONFIG_DLCI_COUNT=24 +CONFIG_DLCI_MAX=8 +CONFIG_WAN_ROUTER_DRIVERS=y +CONFIG_LAPBETHER=m +CONFIG_X25_ASY=m + +# +# ATM drivers +# +# CONFIG_ATM_DUMMY is not set +CONFIG_ATM_TCP=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_SLIP=m +CONFIG_SLIP_COMPRESSED=y +CONFIG_SLHC=m +CONFIG_SLIP_SMART=y +CONFIG_SLIP_MODE_SLIP6=y +CONFIG_SHAPER=m +CONFIG_NETCONSOLE=m +CONFIG_NETPOLL=y +# CONFIG_NETPOLL_RX is not set +# CONFIG_NETPOLL_TRAP is not set +CONFIG_NET_POLL_CONTROLLER=y + +# +# ISDN subsystem +# +# CONFIG_ISDN is not set + +# +# Input device support +# +CONFIG_INPUT=y +# CONFIG_INPUT_FF_MEMLESS is not set + +# +# Userland interfaces +# +# CONFIG_INPUT_MOUSEDEV is not set +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 is not set +CONFIG_INPUT_MOUSE=y +CONFIG_MOUSE_PS2=m +CONFIG_MOUSE_SERIAL=m +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 is not set +CONFIG_JOYSTICK_JOYDUMP=m +CONFIG_INPUT_TOUCHSCREEN=y +# CONFIG_TOUCHSCREEN_ADS7846 is not set +CONFIG_TOUCHSCREEN_GUNZE=m +# CONFIG_TOUCHSCREEN_ELO is not set +# CONFIG_TOUCHSCREEN_MTOUCH is not set +# CONFIG_TOUCHSCREEN_MK712 is not set +# CONFIG_TOUCHSCREEN_PENMOUNT is not set +# CONFIG_TOUCHSCREEN_TOUCHRIGHT is not set +# CONFIG_TOUCHSCREEN_TOUCHWIN is not set +CONFIG_INPUT_MISC=y +CONFIG_INPUT_UINPUT=m + +# +# Hardware I/O ports +# +CONFIG_SERIO=y +CONFIG_SERIO_SERPORT=m +CONFIG_SERIO_LIBPS2=y +CONFIG_SERIO_RAW=m +CONFIG_GAMEPORT=m +CONFIG_GAMEPORT_NS558=m +CONFIG_GAMEPORT_L4=m + +# +# Character devices +# +CONFIG_VT=y +CONFIG_VT_CONSOLE=y +CONFIG_HW_CONSOLE=y +# CONFIG_VT_HW_CONSOLE_BINDING is not set +# CONFIG_SERIAL_NONSTANDARD is not set + +# +# Serial drivers +# +CONFIG_SERIAL_8250=y +CONFIG_SERIAL_8250_CONSOLE=y +CONFIG_SERIAL_8250_NR_UARTS=4 +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 + +# +# Non-8250 serial port support +# +CONFIG_SERIAL_CORE=y +CONFIG_SERIAL_CORE_CONSOLE=y +CONFIG_UNIX98_PTYS=y +CONFIG_LEGACY_PTYS=y +CONFIG_LEGACY_PTY_COUNT=256 + +# +# IPMI +# +# CONFIG_IPMI_HANDLER is not set + +# +# Watchdog Cards +# +CONFIG_WATCHDOG=y +# CONFIG_WATCHDOG_NOWAYOUT is not set + +# +# Watchdog Device Drivers +# +CONFIG_SOFT_WATCHDOG=m +CONFIG_PNX4008_WATCHDOG=y + +# +# USB-based Watchdog Cards +# +CONFIG_USBPCWATCHDOG=m +CONFIG_HW_RANDOM=y +# CONFIG_NVRAM is not set +# CONFIG_DTLK is not set +# CONFIG_R3964 is not set + +# +# Ftape, the floppy tape device driver +# +# CONFIG_RAW_DRIVER is not set + +# +# TPM devices +# +# CONFIG_TCG_TPM is not set + +# +# I2C support +# +CONFIG_I2C=y +CONFIG_I2C_CHARDEV=y + +# +# I2C Algorithms +# +CONFIG_I2C_ALGOBIT=m +CONFIG_I2C_ALGOPCF=m +CONFIG_I2C_ALGOPCA=m + +# +# I2C Hardware Bus support +# +# CONFIG_I2C_OCORES is not set +# CONFIG_I2C_PARPORT_LIGHT is not set +# CONFIG_I2C_STUB is not set +# CONFIG_I2C_PCA_ISA is not set +CONFIG_I2C_PNX=y +CONFIG_I2C_PNX_EARLY=y + +# +# Miscellaneous I2C Chip support +# +# CONFIG_SENSORS_DS1337 is not set +# CONFIG_SENSORS_DS1374 is not set +CONFIG_SENSORS_EEPROM=m +CONFIG_SENSORS_PCF8574=m +# CONFIG_SENSORS_PCA9539 is not set +CONFIG_SENSORS_PCF8591=m +# CONFIG_SENSORS_MAX6875 is not set +CONFIG_I2C_DEBUG_CORE=y +CONFIG_I2C_DEBUG_ALGO=y +CONFIG_I2C_DEBUG_BUS=y +CONFIG_I2C_DEBUG_CHIP=y + +# +# SPI support +# +CONFIG_SPI=y +# CONFIG_SPI_DEBUG is not set +CONFIG_SPI_MASTER=y + +# +# SPI Master Controller Drivers +# +CONFIG_SPI_BITBANG=y +CONFIG_SPI_PNX=y + +# +# SPI Protocol Masters +# +CONFIG_SPI_EEPROM=y + +# +# Dallas's 1-wire bus +# +# CONFIG_W1 is not set + +# +# Hardware Monitoring support +# +# CONFIG_HWMON is not set +# CONFIG_HWMON_VID is not set + +# +# Misc devices +# +# CONFIG_TIFM_CORE is not set + +# +# LED devices +# +# CONFIG_NEW_LEDS is not set + +# +# LED drivers +# + +# +# LED Triggers +# + +# +# Multimedia devices +# +# CONFIG_VIDEO_DEV is not set + +# +# Digital Video Broadcasting Devices +# +CONFIG_DVB=y +CONFIG_DVB_CORE=m +# CONFIG_DVB_CORE_ATTACH is not set + +# +# Supported USB Adapters +# +# CONFIG_DVB_USB 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 is not set + +# +# 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 is not set +CONFIG_DVB_TDA8083=m +CONFIG_DVB_MT312=m +CONFIG_DVB_VES1X93=m +# CONFIG_DVB_S5H1420 is not set +# CONFIG_DVB_TDA10086 is not set + +# +# 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 is not set +CONFIG_DVB_DIB3000MB=m +CONFIG_DVB_DIB3000MC=m + +# +# DVB-C (cable) frontends +# +CONFIG_DVB_VES1820=m +CONFIG_DVB_TDA10021=m +CONFIG_DVB_STV0297=m + +# +# ATSC (North American/Korean Terrestrial/Cable DTV) frontends +# +# CONFIG_DVB_NXT200X is not set +# CONFIG_DVB_OR51211 is not set +# CONFIG_DVB_OR51132 is not set +# CONFIG_DVB_BCM3510 is not set +# CONFIG_DVB_LGDT330X is not set + +# +# Tuners/PLL support +# +CONFIG_DVB_PLL=m +# CONFIG_DVB_TDA826X is not set +# CONFIG_DVB_TUNER_MT2060 is not set + +# +# Miscellaneous devices +# +CONFIG_DVB_LNBP21=m +# CONFIG_DVB_ISL6421 is not set +# CONFIG_DVB_TUA6100 is not set +# CONFIG_USB_DABUSB is not set + +# +# Graphics support +# +CONFIG_FIRMWARE_EDID=y +CONFIG_FB=y +# CONFIG_FB_DDC is not set +CONFIG_FB_CFB_FILLRECT=y +CONFIG_FB_CFB_COPYAREA=y +CONFIG_FB_CFB_IMAGEBLIT=y +# CONFIG_FB_MACMODES is not set +# CONFIG_FB_BACKLIGHT is not set +# CONFIG_FB_MODE_HELPERS is not set +# CONFIG_FB_TILEBLITTING is not set +# CONFIG_FB_S1D13XXX is not set +CONFIG_FB_PNX4008_DUM=y +CONFIG_FB_PNX4008_DUM_RGB=y +# CONFIG_FB_VIRTUAL is not set + +# +# Console display driver support +# +# CONFIG_VGA_CONSOLE is not set +CONFIG_DUMMY_CONSOLE=y +CONFIG_FRAMEBUFFER_CONSOLE=y +CONFIG_FRAMEBUFFER_CONSOLE_ROTATION=y +CONFIG_FONTS=y +CONFIG_FONT_8x8=y +# CONFIG_FONT_8x16 is not set +# CONFIG_FONT_6x11 is not set +# CONFIG_FONT_7x14 is not set +# CONFIG_FONT_PEARL_8x8 is not set +# CONFIG_FONT_ACORN_8x8 is not set +# CONFIG_FONT_MINI_4x6 is not set +# CONFIG_FONT_SUN8x16 is not set +# CONFIG_FONT_SUN12x22 is not set +# CONFIG_FONT_10x18 is not set + +# +# Logo configuration +# +# CONFIG_LOGO is not set +# CONFIG_BACKLIGHT_LCD_SUPPORT 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_DYNAMIC_MINORS is not set +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_DUMMY=m +CONFIG_SND_VIRMIDI=m +CONFIG_SND_MTPAV=m +CONFIG_SND_SERIAL_U16550=m +CONFIG_SND_MPU401=m + +# +# ALSA ARM devices +# + +# +# USB devices +# +CONFIG_SND_USB_AUDIO=m + +# +# Open Sound System +# +CONFIG_SOUND_PRIME=m +# CONFIG_OSS_OBSOLETE_DRIVER is not set +# CONFIG_SOUND_MSNDCLAS is not set +# CONFIG_SOUND_MSNDPIN is not set + +# +# USB support +# +CONFIG_USB_ARCH_HAS_HCD=y +CONFIG_USB_ARCH_HAS_OHCI=y +# CONFIG_USB_ARCH_HAS_EHCI is not set +CONFIG_USB=y +# CONFIG_USB_DEBUG is not set + +# +# Miscellaneous USB options +# +CONFIG_USB_DEVICEFS=y +CONFIG_USB_BANDWIDTH=y +# CONFIG_USB_DYNAMIC_MINORS is not set +# CONFIG_USB_SUSPEND is not set +# CONFIG_USB_OTG is not set + +# +# USB Host Controller Drivers +# +# CONFIG_USB_ISP116X_HCD is not set +CONFIG_USB_OHCI_HCD=y +# CONFIG_USB_OHCI_BIG_ENDIAN is not set +CONFIG_USB_OHCI_LITTLE_ENDIAN=y +CONFIG_USB_SL811_HCD=m + +# +# 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_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 is not set +# CONFIG_USB_STORAGE_KARMA is not set +# CONFIG_USB_LIBUSUAL is not set + +# +# USB Input Devices +# +CONFIG_USB_HID=m +CONFIG_USB_HIDINPUT=y +# CONFIG_USB_HIDINPUT_POWERBOOK is not set +# 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_AIPTEK=m +CONFIG_USB_WACOM=m +# CONFIG_USB_ACECAD is not set +CONFIG_USB_KBTAB=m +CONFIG_USB_POWERMATE=m +# CONFIG_USB_TOUCHSCREEN is not set +# CONFIG_USB_YEALINK is not set +CONFIG_USB_XPAD=m +CONFIG_USB_ATI_REMOTE=m +# CONFIG_USB_ATI_REMOTE2 is not set +# CONFIG_USB_KEYSPAN_REMOTE is not set +# CONFIG_USB_APPLETOUCH is not set + +# +# USB Imaging devices +# +CONFIG_USB_MDC800=m +CONFIG_USB_MICROTEK=m + +# +# USB Network Adapters +# +CONFIG_USB_CATC=y +CONFIG_USB_KAWETH=y +CONFIG_USB_PEGASUS=y +CONFIG_USB_RTL8150=y +CONFIG_USB_USBNET_MII=m +CONFIG_USB_USBNET=y +CONFIG_USB_NET_AX8817X=m +CONFIG_USB_NET_CDCETHER=m +# CONFIG_USB_NET_GL620A is not set +CONFIG_USB_NET_NET1080=m +# CONFIG_USB_NET_PLUSB is not set +# CONFIG_USB_NET_MCS7830 is not set +# CONFIG_USB_NET_RNDIS_HOST is not set +# CONFIG_USB_NET_CDC_SUBSET is not set +CONFIG_USB_NET_ZAURUS=m +CONFIG_USB_MON=y + +# +# USB port drivers +# + +# +# USB Serial Converter support +# +CONFIG_USB_SERIAL=m +CONFIG_USB_SERIAL_GENERIC=y +# CONFIG_USB_SERIAL_AIRCABLE is not set +# CONFIG_USB_SERIAL_AIRPRIME is not set +# CONFIG_USB_SERIAL_ARK3116 is not set +CONFIG_USB_SERIAL_BELKIN=m +CONFIG_USB_SERIAL_WHITEHEAT=m +CONFIG_USB_SERIAL_DIGI_ACCELEPORT=m +# CONFIG_USB_SERIAL_CP2101 is not set +CONFIG_USB_SERIAL_CYPRESS_M8=m +CONFIG_USB_SERIAL_EMPEG=m +CONFIG_USB_SERIAL_FTDI_SIO=m +# CONFIG_USB_SERIAL_FUNSOFT is not set +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 is not set +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 is not set +# CONFIG_USB_SERIAL_MOS7840 is not set +# CONFIG_USB_SERIAL_NAVMAN is not set +CONFIG_USB_SERIAL_PL2303=m +# CONFIG_USB_SERIAL_HP4X is not set +CONFIG_USB_SERIAL_SAFE=m +# CONFIG_USB_SERIAL_SAFE_PADDED is not set +# CONFIG_USB_SERIAL_SIERRAWIRELESS is not set +# CONFIG_USB_SERIAL_TI is not set +CONFIG_USB_SERIAL_CYBERJACK=m +CONFIG_USB_SERIAL_XIRCOM=m +# CONFIG_USB_SERIAL_OPTION is not set +CONFIG_USB_SERIAL_OMNINET=m +CONFIG_USB_EZUSB=y + +# +# USB Miscellaneous drivers +# +# CONFIG_USB_EMI62 is not set +# CONFIG_USB_EMI26 is not set +# CONFIG_USB_ADUTUX is not set +CONFIG_USB_AUERSWALD=m +CONFIG_USB_RIO500=m +CONFIG_USB_LEGOTOWER=m +CONFIG_USB_LCD=m +CONFIG_USB_LED=m +# CONFIG_USB_CYPRESS_CY7C63 is not set +CONFIG_USB_CYTHERM=m +# CONFIG_USB_PHIDGET is not set +# CONFIG_USB_IDMOUSE is not set +# CONFIG_USB_FTDI_ELAN is not set +# CONFIG_USB_APPLEDISPLAY is not set +# CONFIG_USB_LD is not set +# CONFIG_USB_TRANCEVIBRATOR is not set +CONFIG_USB_TEST=m + +# +# USB DSL modem support +# +CONFIG_USB_ATM=m +CONFIG_USB_SPEEDTOUCH=m +# CONFIG_USB_CXACRU is not set +# CONFIG_USB_UEAGLEATM is not set +# CONFIG_USB_XUSBATM is not set + +# +# USB Gadget Support +# +CONFIG_USB_GADGET=m +# CONFIG_USB_GADGET_DEBUG_FILES is not set +CONFIG_USB_GADGET_SELECTED=y +# CONFIG_USB_GADGET_NET2280 is not set +# CONFIG_USB_GADGET_PXA2XX 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_AT91 is not set +CONFIG_USB_GADGET_DUMMY_HCD=y +CONFIG_USB_DUMMY_HCD=m +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 is not set + +# +# MMC/SD Card support +# +CONFIG_MMC=m +# CONFIG_MMC_DEBUG is not set +CONFIG_MMC_BLOCK=m +# CONFIG_MMC_TIFM_SD is not set + +# +# Real Time Clock +# +CONFIG_RTC_LIB=y +# CONFIG_RTC_CLASS is not set + +# +# File systems +# +CONFIG_EXT2_FS=y +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=y +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 is not set +# 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 is not set + +# +# CD-ROM/DVD Filesystems +# +CONFIG_ISO9660_FS=m +CONFIG_JOLIET=y +CONFIG_ZISOFS=y +CONFIG_ZISOFS_FS=m +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_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 is not set + +# +# Miscellaneous filesystems +# +CONFIG_ADFS_FS=m +# CONFIG_ADFS_FS_RW is not set +CONFIG_AFFS_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_JFFS_FS=m +CONFIG_JFFS_FS_VERBOSE=0 +CONFIG_JFFS_PROC_FS=y +CONFIG_JFFS2_FS=y +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=y +# CONFIG_JFFS2_ZLIB is not set +# CONFIG_JFFS2_RTIME is not set +# CONFIG_JFFS2_RUBIN is not set +CONFIG_JFFS2_CMODE_NONE=y +# CONFIG_JFFS2_CMODE_PRIORITY is not set +# CONFIG_JFFS2_CMODE_SIZE is not set +# CONFIG_YAFFS_FS 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=y +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_ROOT_NFS=y +CONFIG_LOCKD=y +CONFIG_LOCKD_V4=y +CONFIG_EXPORTFS=m +CONFIG_NFS_COMMON=y +CONFIG_SUNRPC=y +CONFIG_SUNRPC_GSS=y +CONFIG_RPCSEC_GSS_KRB5=y +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_RXRPC=m +# CONFIG_9P_FS 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 is not set +# CONFIG_EFI_PARTITION is not set + +# +# Native Language Support +# +CONFIG_NLS=m +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 is not set + +# +# Profiling support +# +# CONFIG_PROFILING is not set + +# +# Kernel hacking +# +# CONFIG_PRINTK_TIME is not set +CONFIG_ENABLE_MUST_CHECK=y +CONFIG_MAGIC_SYSRQ=y +# CONFIG_UNUSED_SYMBOLS is not set +CONFIG_DEBUG_KERNEL=y +CONFIG_LOG_BUF_SHIFT=14 +CONFIG_DETECT_SOFTLOCKUP=y +# CONFIG_SCHEDSTATS is not set +# CONFIG_DEBUG_SLAB is not set +CONFIG_DEBUG_PREEMPT=y +# CONFIG_DEBUG_RT_MUTEXES is not set +# CONFIG_RT_MUTEX_TESTER is not set +# CONFIG_DEBUG_SPINLOCK is not set +# CONFIG_DEBUG_MUTEXES is not set +# CONFIG_DEBUG_RWSEMS is not set +# CONFIG_DEBUG_SPINLOCK_SLEEP is not set +# CONFIG_DEBUG_LOCKING_API_SELFTESTS is not set +# CONFIG_DEBUG_KOBJECT is not set +# CONFIG_DEBUG_BUGVERBOSE is not set +# CONFIG_DEBUG_INFO is not set +# CONFIG_DEBUG_FS is not set +# CONFIG_DEBUG_VM is not set +# CONFIG_DEBUG_LIST is not set +CONFIG_FRAME_POINTER=y +CONFIG_FORCED_INLINING=y +# CONFIG_HEADERS_CHECK is not set +# CONFIG_RCU_TORTURE_TEST is not set +# CONFIG_DEBUG_USER is not set +# CONFIG_DEBUG_WAITQ is not set +# CONFIG_DEBUG_ERRORS is not set +CONFIG_DEBUG_LL=y +# CONFIG_DEBUG_ICEDCC is not set + +# +# Security options +# +# CONFIG_KEYS is not set +CONFIG_SECURITY=y +# CONFIG_SECURITY_NETWORK is not set +CONFIG_SECURITY_CAPABILITIES=m +CONFIG_SECURITY_ROOTPLUG=m + +# +# Cryptographic options +# +CONFIG_CRYPTO=y +CONFIG_CRYPTO_ALGAPI=y +CONFIG_CRYPTO_BLKCIPHER=y +CONFIG_CRYPTO_HASH=y +CONFIG_CRYPTO_MANAGER=y +CONFIG_CRYPTO_HMAC=y +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 is not set +CONFIG_CRYPTO_ECB=m +CONFIG_CRYPTO_CBC=y +CONFIG_CRYPTO_DES=y +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_TEST=m + +# +# Hardware crypto devices +# + +# +# Library routines +# +CONFIG_CRC_CCITT=m +CONFIG_CRC16=m +CONFIG_CRC32=y +CONFIG_LIBCRC32C=m +CONFIG_ZLIB_INFLATE=y +CONFIG_ZLIB_DEFLATE=m +CONFIG_TEXTSEARCH=y +CONFIG_TEXTSEARCH_KMP=m +CONFIG_PLIST=y Index: linux-mips.git/arch/mips/Kconfig =================================================================== --- linux-mips.git.orig/arch/mips/Kconfig 2006-12-07 18:20:47.000000000 +0300 +++ linux-mips.git/arch/mips/Kconfig 2006-12-07 18:21:04.000000000 +0300 @@ -459,6 +459,11 @@ select PNX8550 select SYS_SUPPORTS_LITTLE_ENDIAN +config PNX8550_STB810 + bool "Support for Philips PNX8550 based STB810 board" + select PNX8550 + select SYS_SUPPORTS_LITTLE_ENDIAN + config DDB5477 bool "NEC DDB Vrc-5477" select DDB5XXX_COMMON Index: linux-mips.git/arch/mips/Makefile =================================================================== --- linux-mips.git.orig/arch/mips/Makefile 2006-12-07 18:20:47.000000000 +0300 +++ linux-mips.git/arch/mips/Makefile 2006-12-07 18:21:04.000000000 +0300 @@ -463,6 +463,11 @@ #cflags-$(CONFIG_PNX8550_JBS) += -Iinclude/asm-mips/mach-pnx8550 load-$(CONFIG_PNX8550_JBS) += 0xffffffff80060000 +# Philips PNX8550 STB810 board +# +libs-$(CONFIG_PNX8550_STB810) += arch/mips/philips/pnx8550/stb810/ +load-$(CONFIG_PNX8550_STB810) += 0xffffffff80060000 + # NEC EMMA2RH boards # core-$(CONFIG_EMMA2RH) += arch/mips/emma2rh/common/ From sshtylyov@ru.mvista.com Thu Dec 7 15:45:27 2006 Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 07 Dec 2006 15:45:34 +0000 (GMT) Received: from h155.mvista.com ([63.81.120.155]:9863 "EHLO imap.sh.mvista.com") by ftp.linux-mips.org with ESMTP id S20027579AbWLGPp1 (ORCPT ); Thu, 7 Dec 2006 15:45:27 +0000 Received: from [192.168.1.248] (unknown [10.150.0.9]) by imap.sh.mvista.com (Postfix) with ESMTP id 4E46E3EC9; Thu, 7 Dec 2006 07:45:22 -0800 (PST) Message-ID: <45783772.6030504@ru.mvista.com> Date: Thu, 07 Dec 2006 18:46:58 +0300 From: Sergei Shtylyov Organization: MontaVista Software Inc. User-Agent: Mozilla/5.0 (X11; U; Linux i686; rv:1.7.2) Gecko/20040803 X-Accept-Language: ru, en-us, en-gb MIME-Version: 1.0 To: Vitaly Wool Cc: ralf@linux-mips.org, linux-mips@linux-mips.org Subject: Re: [PATCH] add STB810 support (Philips PNX8550-based) References: <20061207182234.83212939.vitalywool@gmail.com> In-Reply-To: <20061207182234.83212939.vitalywool@gmail.com> Content-Type: text/plain; charset=us-ascii; 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: 13402 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: sshtylyov@ru.mvista.com Precedence: bulk X-list: linux-mips Hello. Vitaly Wool wrote: > please find the patch that adds support for STB810 below. [...] > Signed-off-by: Vitaly Wool > Index: linux-mips.git/arch/mips/philips/pnx8550/stb810/board_setup.c > =================================================================== > --- /dev/null 1970-01-01 00:00:00.000000000 +0000 > +++ linux-mips.git/arch/mips/philips/pnx8550/stb810/board_setup.c 2006-12-07 18:21:04.000000000 +0300 > @@ -0,0 +1,56 @@ [...] > +/* CP0 hazard avoidance. */ > +#define BARRIER __asm__ __volatile__(".set noreorder\n\t" \ > + "nop; nop; nop; nop; nop; nop;\n\t" \ > + ".set reorder\n\t") > + Erm, barrier code have been reworked, IIRC. Is there really a need for the 6-nop custom barrier here? > +void __init board_setup(void) > +{ > + unsigned long config0, configpr; > + > + config0 = read_c0_config(); > + > + /* clear all three cache coherency fields */ > + config0 &= ~(0x7 | (7<<25) | (7<<28)); > + config0 |= (CONF_CM_DEFAULT | (CONF_CM_DEFAULT<<25) | > + (CONF_CM_DEFAULT<<28)); > + write_c0_config(config0); > + BARRIER; > + > + configpr = read_c0_config7(); > + configpr |= (1<<19); /* enable tlb */ > + write_c0_config7(configpr); > + BARRIER; > +} > Index: linux-mips.git/arch/mips/philips/pnx8550/stb810/irqmap.c > =================================================================== > --- /dev/null 1970-01-01 00:00:00.000000000 +0000 > +++ linux-mips.git/arch/mips/philips/pnx8550/stb810/irqmap.c 2006-12-07 18:21:04.000000000 +0300 > @@ -0,0 +1,23 @@ [...] > +char irq_tab_jbs[][5] __initdata = { > + [8] = { -1, PNX8550_INT_PCI_INTA, 0xff, 0xff, 0xff}, > + [9] = { -1, PNX8550_INT_PCI_INTA, 0xff, 0xff, 0xff}, > + [10] = { -1, PNX8550_INT_PCI_INTA, 0xff, 0xff, 0xff}, > +}; This is somewhat unusual PCI interrupt rounting... > Index: linux-mips.git/arch/mips/kernel/head.S > Index: linux-mips.git/arch/mips/configs/pnx8550-stb810_defconfig > =================================================================== > --- /dev/null 1970-01-01 00:00:00.000000000 +0000 > +++ linux-mips.git/arch/mips/configs/pnx8550-stb810_defconfig 2006-12-07 18:21:04.000000000 +0300 > @@ -0,0 +1,1777 @@ > +# > +# Automatically generated make config: don't edit > +# Linux kernel version: 2.6.19-rc5 > +# Wed Nov 8 13:46:57 2006 > +# > +CONFIG_ARM=y ARM?! Are you sure it's a correct defconfig? ;-) WBR, Sergei From ralf@linux-mips.org Thu Dec 7 15:48:33 2006 Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 07 Dec 2006 15:48:35 +0000 (GMT) Received: from localhost.localdomain ([127.0.0.1]:2731 "EHLO dl5rb.ham-radio-op.net") by ftp.linux-mips.org with ESMTP id S20037585AbWLGPsd (ORCPT ); Thu, 7 Dec 2006 15:48:33 +0000 Received: from denk.linux-mips.net (denk.linux-mips.net [127.0.0.1]) by dl5rb.ham-radio-op.net (8.13.8/8.13.8) with ESMTP id kB7FmVVq009033; Thu, 7 Dec 2006 15:48:31 GMT Received: (from ralf@localhost) by denk.linux-mips.net (8.13.8/8.13.8/Submit) id kB7FmUYq009032; Thu, 7 Dec 2006 15:48:30 GMT Date: Thu, 7 Dec 2006 15:48:30 +0000 From: Ralf Baechle To: Vitaly Wool Cc: linux-mips@linux-mips.org Subject: Re: [PATCH] add STB810 support (Philips PNX8550-based) Message-ID: <20061207154830.GB4156@linux-mips.org> References: <20061207182234.83212939.vitalywool@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20061207182234.83212939.vitalywool@gmail.com> User-Agent: Mutt/1.4.2.2i 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: 13403 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, Dec 07, 2006 at 06:22:34PM +0300, Vitaly Wool wrote: > Index: linux-mips.git/arch/mips/philips/pnx8550/stb810/Makefile > =================================================================== > --- /dev/null 1970-01-01 00:00:00.000000000 +0000 > +++ linux-mips.git/arch/mips/philips/pnx8550/stb810/Makefile 2006-12-07 18:21:04.000000000 +0300 > @@ -0,0 +1,4 @@ > + > +# Makefile for the Philips STB810 Board. > + > +lib-y := prom_init.o board_setup.o irqmap.o > Index: linux-mips.git/arch/mips/philips/pnx8550/stb810/board_setup.c > =================================================================== > --- /dev/null 1970-01-01 00:00:00.000000000 +0000 > +++ linux-mips.git/arch/mips/philips/pnx8550/stb810/board_setup.c 2006-12-07 18:21:04.000000000 +0300 > @@ -0,0 +1,56 @@ > +/* > + * STB810 specific board startup routines. > + * > + * Based on the arch/mips/philips/pnx8550/jbs/board_setup.c > + * > + * Author: MontaVista Software, Inc. > + * source@mvista.com > + * > + * Copyright 2005 MontaVista Software Inc. > + * > + * 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. > + */ > + > +#include > +#include > +#include > +#include > +#include > +#include > +#include > + > +#include > +#include > +#include > +#include > +#include > +#include > + > +#include > + > +/* CP0 hazard avoidance. */ > +#define BARRIER __asm__ __volatile__(".set noreorder\n\t" \ > + "nop; nop; nop; nop; nop; nop;\n\t" \ > + ".set reorder\n\t") > + > +void __init board_setup(void) > +{ > + unsigned long config0, configpr; > + > + config0 = read_c0_config(); > + > + /* clear all three cache coherency fields */ > + config0 &= ~(0x7 | (7<<25) | (7<<28)); > + config0 |= (CONF_CM_DEFAULT | (CONF_CM_DEFAULT<<25) | > + (CONF_CM_DEFAULT<<28)); > + write_c0_config(config0); > + BARRIER; > + > + configpr = read_c0_config7(); > + configpr |= (1<<19); /* enable tlb */ > + write_c0_config7(configpr); > + BARRIER; > +} You really need that hazard barrier? Chances are you can get away without a hazard barrier I guess. > Index: linux-mips.git/arch/mips/philips/pnx8550/stb810/irqmap.c > =================================================================== > --- /dev/null 1970-01-01 00:00:00.000000000 +0000 > +++ linux-mips.git/arch/mips/philips/pnx8550/stb810/irqmap.c 2006-12-07 18:21:04.000000000 +0300 > +char irq_tab_jbs[][5] __initdata = { > + [8] = { -1, PNX8550_INT_PCI_INTA, 0xff, 0xff, 0xff}, > + [9] = { -1, PNX8550_INT_PCI_INTA, 0xff, 0xff, 0xff}, > + [10] = { -1, PNX8550_INT_PCI_INTA, 0xff, 0xff, 0xff}, Coding style, indent with tabs. > Index: linux-mips.git/arch/mips/kernel/head.S > =================================================================== > --- linux-mips.git.orig/arch/mips/kernel/head.S 2006-12-07 18:20:47.000000000 +0300 > +++ linux-mips.git/arch/mips/kernel/head.S 2006-12-07 18:21:04.000000000 +0300 > @@ -138,7 +138,7 @@ > EXPORT(stext) # used for profiling > EXPORT(_stext) > > -#if defined(CONFIG_QEMU) || defined(CONFIG_MIPS_SIM) > +#if defined(CONFIG_QEMU) || defined(CONFIG_MIPS_SIM) || defined(CONFIG_PNX8550_STB810) Your firmware is really so broken it needs this? > Index: linux-mips.git/arch/mips/configs/pnx8550-stb810_defconfig > =================================================================== > --- /dev/null 1970-01-01 00:00:00.000000000 +0000 > +++ linux-mips.git/arch/mips/configs/pnx8550-stb810_defconfig 2006-12-07 18:21:04.000000000 +0300 > @@ -0,0 +1,1777 @@ > +# > +# Automatically generated make config: don't edit > +# Linux kernel version: 2.6.19-rc5 > +# Wed Nov 8 13:46:57 2006 > +# > +CONFIG_ARM=y LOL. Doesn't look quite right. Let's see if you find out why ;-) Ralf From anemo@mba.ocn.ne.jp Thu Dec 7 16:04:36 2006 Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 07 Dec 2006 16:04:41 +0000 (GMT) Received: from mba.ocn.ne.jp ([210.190.142.172]:35293 "HELO smtp.mba.ocn.ne.jp") by ftp.linux-mips.org with SMTP id S20037600AbWLGQEg (ORCPT ); Thu, 7 Dec 2006 16:04:36 +0000 Received: from localhost (p8245-ipad29funabasi.chiba.ocn.ne.jp [221.184.75.245]) by smtp.mba.ocn.ne.jp (Postfix) with ESMTP id 903F8B89A; Fri, 8 Dec 2006 01:04:31 +0900 (JST) Date: Fri, 08 Dec 2006 01:04:31 +0900 (JST) Message-Id: <20061208.010431.05600019.anemo@mba.ocn.ne.jp> To: linux-mips@linux-mips.org Cc: ralf@linux-mips.org Subject: [PATCH 1/3] Make csum_partial more readable From: Atsushi Nemoto 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 3.3 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: 13404 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 Use standard o32 register name instead of T0, T1, etc, like memcpy.S. Signed-off-by: Atsushi Nemoto --- diff --git a/arch/mips/lib/csum_partial.S b/arch/mips/lib/csum_partial.S index 15611d9..3bffdbb 100644 --- a/arch/mips/lib/csum_partial.S +++ b/arch/mips/lib/csum_partial.S @@ -12,19 +12,23 @@ #include #include #ifdef CONFIG_64BIT -#define T0 ta0 -#define T1 ta1 -#define T2 ta2 -#define T3 ta3 -#define T4 t0 -#define T7 t3 -#else -#define T0 t0 -#define T1 t1 -#define T2 t2 -#define T3 t3 -#define T4 t4 -#define T7 t7 +/* + * As we are sharing code base with the mips32 tree (which use the o32 ABI + * register definitions). We need to redefine the register definitions from + * the n64 ABI register naming to the o32 ABI register naming. + */ +#undef t0 +#undef t1 +#undef t2 +#undef t3 +#define t0 $8 +#define t1 $9 +#define t2 $10 +#define t3 $11 +#define t4 $12 +#define t5 $13 +#define t6 $14 +#define t7 $15 #endif #define ADDC(sum,reg) \ @@ -64,37 +68,37 @@ #define sum v0 /* unknown src alignment and < 8 bytes to go */ small_csumcpy: - move a1, T2 + move a1, t2 - andi T0, a1, 4 - beqz T0, 1f - andi T0, a1, 2 + andi t0, a1, 4 + beqz t0, 1f + andi t0, a1, 2 /* Still a full word to go */ - ulw T1, (src) + ulw t1, (src) PTR_ADDIU src, 4 - ADDC(sum, T1) + ADDC(sum, t1) -1: move T1, zero - beqz T0, 1f - andi T0, a1, 1 +1: move t1, zero + beqz t0, 1f + andi t0, a1, 1 /* Still a halfword to go */ - ulhu T1, (src) + ulhu t1, (src) PTR_ADDIU src, 2 -1: beqz T0, 1f - sll T1, T1, 16 +1: beqz t0, 1f + sll t1, t1, 16 - lbu T2, (src) + lbu t2, (src) nop #ifdef __MIPSEB__ - sll T2, T2, 8 + sll t2, t2, 8 #endif - or T1, T2 + or t1, t2 -1: ADDC(sum, T1) +1: ADDC(sum, t1) /* fold checksum */ sll v1, sum, 16 @@ -104,7 +108,7 @@ #endif addu sum, v1 /* odd buffer alignment? */ - beqz T7, 1f + beqz t7, 1f nop sll v1, sum, 8 srl sum, sum, 8 @@ -122,25 +126,25 @@ #endif .align 5 LEAF(csum_partial) move sum, zero - move T7, zero + move t7, zero sltiu t8, a1, 0x8 bnez t8, small_csumcpy /* < 8 bytes to copy */ - move T2, a1 + move t2, a1 beqz a1, out - andi T7, src, 0x1 /* odd buffer? */ + andi t7, src, 0x1 /* odd buffer? */ hword_align: - beqz T7, word_align + beqz t7, word_align andi t8, src, 0x2 - lbu T0, (src) + lbu t0, (src) LONG_SUBU a1, a1, 0x1 #ifdef __MIPSEL__ - sll T0, T0, 8 + sll t0, t0, 8 #endif - ADDC(sum, T0) + ADDC(sum, t0) PTR_ADDU src, src, 0x1 andi t8, src, 0x2 @@ -148,9 +152,9 @@ word_align: beqz t8, dword_align sltiu t8, a1, 56 - lhu T0, (src) + lhu t0, (src) LONG_SUBU a1, a1, 0x2 - ADDC(sum, T0) + ADDC(sum, t0) sltiu t8, a1, 56 PTR_ADDU src, src, 0x2 @@ -162,9 +166,9 @@ dword_align: beqz t8, qword_align andi t8, src, 0x8 - lw T0, 0x00(src) + lw t0, 0x00(src) LONG_SUBU a1, a1, 0x4 - ADDC(sum, T0) + ADDC(sum, t0) PTR_ADDU src, src, 0x4 andi t8, src, 0x8 @@ -172,11 +176,11 @@ qword_align: beqz t8, oword_align andi t8, src, 0x10 - lw T0, 0x00(src) - lw T1, 0x04(src) + lw t0, 0x00(src) + lw t1, 0x04(src) LONG_SUBU a1, a1, 0x8 - ADDC(sum, T0) - ADDC(sum, T1) + ADDC(sum, t0) + ADDC(sum, t1) PTR_ADDU src, src, 0x8 andi t8, src, 0x10 @@ -184,46 +188,46 @@ oword_align: beqz t8, begin_movement LONG_SRL t8, a1, 0x7 - lw T3, 0x08(src) - lw T4, 0x0c(src) - lw T0, 0x00(src) - lw T1, 0x04(src) - ADDC(sum, T3) - ADDC(sum, T4) - ADDC(sum, T0) - ADDC(sum, T1) + lw t3, 0x08(src) + lw t4, 0x0c(src) + lw t0, 0x00(src) + lw t1, 0x04(src) + ADDC(sum, t3) + ADDC(sum, t4) + ADDC(sum, t0) + ADDC(sum, t1) LONG_SUBU a1, a1, 0x10 PTR_ADDU src, src, 0x10 LONG_SRL t8, a1, 0x7 begin_movement: beqz t8, 1f - andi T2, a1, 0x40 + andi t2, a1, 0x40 move_128bytes: - CSUM_BIGCHUNK(src, 0x00, sum, T0, T1, T3, T4) - CSUM_BIGCHUNK(src, 0x20, sum, T0, T1, T3, T4) - CSUM_BIGCHUNK(src, 0x40, sum, T0, T1, T3, T4) - CSUM_BIGCHUNK(src, 0x60, sum, T0, T1, T3, T4) + CSUM_BIGCHUNK(src, 0x00, sum, t0, t1, t3, t4) + CSUM_BIGCHUNK(src, 0x20, sum, t0, t1, t3, t4) + CSUM_BIGCHUNK(src, 0x40, sum, t0, t1, t3, t4) + CSUM_BIGCHUNK(src, 0x60, sum, t0, t1, t3, t4) LONG_SUBU t8, t8, 0x01 bnez t8, move_128bytes PTR_ADDU src, src, 0x80 1: - beqz T2, 1f - andi T2, a1, 0x20 + beqz t2, 1f + andi t2, a1, 0x20 move_64bytes: - CSUM_BIGCHUNK(src, 0x00, sum, T0, T1, T3, T4) - CSUM_BIGCHUNK(src, 0x20, sum, T0, T1, T3, T4) + CSUM_BIGCHUNK(src, 0x00, sum, t0, t1, t3, t4) + CSUM_BIGCHUNK(src, 0x20, sum, t0, t1, t3, t4) PTR_ADDU src, src, 0x40 1: - beqz T2, do_end_words + beqz t2, do_end_words andi t8, a1, 0x1c move_32bytes: - CSUM_BIGCHUNK(src, 0x00, sum, T0, T1, T3, T4) + CSUM_BIGCHUNK(src, 0x00, sum, t0, t1, t3, t4) andi t8, a1, 0x1c PTR_ADDU src, src, 0x20 @@ -232,22 +236,22 @@ do_end_words: LONG_SRL t8, t8, 0x2 end_words: - lw T0, (src) + lw t0, (src) LONG_SUBU t8, t8, 0x1 - ADDC(sum, T0) + ADDC(sum, t0) bnez t8, end_words PTR_ADDU src, src, 0x4 maybe_end_cruft: - andi T2, a1, 0x3 + andi t2, a1, 0x3 small_memcpy: - j small_csumcpy; move a1, T2 /* XXX ??? */ + j small_csumcpy; move a1, t2 /* XXX ??? */ beqz t2, out - move a1, T2 + move a1, t2 end_bytes: - lb T0, (src) + lb t0, (src) LONG_SUBU a1, a1, 0x1 bnez a2, end_bytes PTR_ADDU src, src, 0x1 From anemo@mba.ocn.ne.jp Thu Dec 7 16:05:04 2006 Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 07 Dec 2006 16:05:10 +0000 (GMT) Received: from mba.ocn.ne.jp ([210.190.142.172]:25570 "HELO smtp.mba.ocn.ne.jp") by ftp.linux-mips.org with SMTP id S20037652AbWLGQEt (ORCPT ); Thu, 7 Dec 2006 16:04:49 +0000 Received: from localhost (p8245-ipad29funabasi.chiba.ocn.ne.jp [221.184.75.245]) by smtp.mba.ocn.ne.jp (Postfix) with ESMTP id E40FFB64F; Fri, 8 Dec 2006 01:04:45 +0900 (JST) Date: Fri, 08 Dec 2006 01:04:45 +0900 (JST) Message-Id: <20061208.010445.07456436.anemo@mba.ocn.ne.jp> To: linux-mips@linux-mips.org Cc: ralf@linux-mips.org Subject: [PATCH 2/3] Optimize flow of csum_partial From: Atsushi Nemoto 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 3.3 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: 13405 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 Delete dead codes at end of the function and move small_csumcopy there. This makes some labels (maybe_end_cruft, small_memcpy, end_bytes, out) needless and eliminates some branches. Signed-off-by: Atsushi Nemoto --- diff --git a/arch/mips/lib/csum_partial.S b/arch/mips/lib/csum_partial.S index 3bffdbb..b04475d 100644 --- a/arch/mips/lib/csum_partial.S +++ b/arch/mips/lib/csum_partial.S @@ -65,64 +65,6 @@ #define sum v0 .text .set noreorder - -/* unknown src alignment and < 8 bytes to go */ -small_csumcpy: - move a1, t2 - - andi t0, a1, 4 - beqz t0, 1f - andi t0, a1, 2 - - /* Still a full word to go */ - ulw t1, (src) - PTR_ADDIU src, 4 - ADDC(sum, t1) - -1: move t1, zero - beqz t0, 1f - andi t0, a1, 1 - - /* Still a halfword to go */ - ulhu t1, (src) - PTR_ADDIU src, 2 - -1: beqz t0, 1f - sll t1, t1, 16 - - lbu t2, (src) - nop - -#ifdef __MIPSEB__ - sll t2, t2, 8 -#endif - or t1, t2 - -1: ADDC(sum, t1) - - /* fold checksum */ - sll v1, sum, 16 - addu sum, v1 - sltu v1, sum, v1 - srl sum, sum, 16 - addu sum, v1 - - /* odd buffer alignment? */ - beqz t7, 1f - nop - sll v1, sum, 8 - srl sum, sum, 8 - or sum, v1 - andi sum, 0xffff -1: - .set reorder - /* Add the passed partial csum. */ - ADDC(sum, a2) - jr ra - .set noreorder - -/* ------------------------------------------------------------------------- */ - .align 5 LEAF(csum_partial) move sum, zero @@ -132,8 +74,7 @@ LEAF(csum_partial) bnez t8, small_csumcpy /* < 8 bytes to copy */ move t2, a1 - beqz a1, out - andi t7, src, 0x1 /* odd buffer? */ + andi t7, src, 0x1 /* odd buffer? */ hword_align: beqz t7, word_align @@ -232,8 +173,9 @@ move_32bytes: PTR_ADDU src, src, 0x20 do_end_words: - beqz t8, maybe_end_cruft - LONG_SRL t8, t8, 0x2 + beqz t8, small_csumcpy + andi t2, a1, 0x3 + LONG_SRL t8, t8, 0x2 end_words: lw t0, (src) @@ -242,21 +184,58 @@ end_words: bnez t8, end_words PTR_ADDU src, src, 0x4 -maybe_end_cruft: - andi t2, a1, 0x3 +/* unknown src alignment and < 8 bytes to go */ +small_csumcpy: + move a1, t2 -small_memcpy: - j small_csumcpy; move a1, t2 /* XXX ??? */ - beqz t2, out - move a1, t2 + andi t0, a1, 4 + beqz t0, 1f + andi t0, a1, 2 -end_bytes: - lb t0, (src) - LONG_SUBU a1, a1, 0x1 - bnez a2, end_bytes - PTR_ADDU src, src, 0x1 + /* Still a full word to go */ + ulw t1, (src) + PTR_ADDIU src, 4 + ADDC(sum, t1) + +1: move t1, zero + beqz t0, 1f + andi t0, a1, 1 + + /* Still a halfword to go */ + ulhu t1, (src) + PTR_ADDIU src, 2 + +1: beqz t0, 1f + sll t1, t1, 16 + + lbu t2, (src) + nop + +#ifdef __MIPSEB__ + sll t2, t2, 8 +#endif + or t1, t2 + +1: ADDC(sum, t1) -out: + /* fold checksum */ + sll v1, sum, 16 + addu sum, v1 + sltu v1, sum, v1 + srl sum, sum, 16 + addu sum, v1 + + /* odd buffer alignment? */ + beqz t7, 1f + nop + sll v1, sum, 8 + srl sum, sum, 8 + or sum, v1 + andi sum, 0xffff +1: + .set reorder + /* Add the passed partial csum. */ + ADDC(sum, a2) jr ra - move v0, sum + .set noreorder END(csum_partial) From anemo@mba.ocn.ne.jp Thu Dec 7 16:05:33 2006 Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 07 Dec 2006 16:05:39 +0000 (GMT) Received: from mba.ocn.ne.jp ([210.190.142.172]:740 "HELO smtp.mba.ocn.ne.jp") by ftp.linux-mips.org with SMTP id S20037653AbWLGQE4 (ORCPT ); Thu, 7 Dec 2006 16:04:56 +0000 Received: from localhost (p8245-ipad29funabasi.chiba.ocn.ne.jp [221.184.75.245]) by smtp.mba.ocn.ne.jp (Postfix) with ESMTP id ACE8EB64F; Fri, 8 Dec 2006 01:04:51 +0900 (JST) Date: Fri, 08 Dec 2006 01:04:51 +0900 (JST) Message-Id: <20061208.010451.51865806.anemo@mba.ocn.ne.jp> To: linux-mips@linux-mips.org Cc: ralf@linux-mips.org Subject: [PATCH 3/3] Optimize csum_partial for 64bit kernel From: Atsushi Nemoto 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 3.3 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: 13406 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 Make csum_partial 64-bit powered. Signed-off-by: Atsushi Nemoto --- diff --git a/arch/mips/lib/csum_partial.S b/arch/mips/lib/csum_partial.S index b04475d..9db3572 100644 --- a/arch/mips/lib/csum_partial.S +++ b/arch/mips/lib/csum_partial.S @@ -29,30 +29,49 @@ #define t4 $12 #define t5 $13 #define t6 $14 #define t7 $15 + +#define USE_DOUBLE #endif +#ifdef USE_DOUBLE + +#define LOAD ld +#define ADD daddu +#define NBYTES 8 + +#else + +#define LOAD lw +#define ADD addu +#define NBYTES 4 + +#endif /* USE_DOUBLE */ + +#define UNIT(unit) ((unit)*NBYTES) + #define ADDC(sum,reg) \ - addu sum, reg; \ + ADD sum, reg; \ sltu v1, sum, reg; \ - addu sum, v1 + ADD sum, v1 -#define CSUM_BIGCHUNK(src, offset, sum, _t0, _t1, _t2, _t3) \ - lw _t0, (offset + 0x00)(src); \ - lw _t1, (offset + 0x04)(src); \ - lw _t2, (offset + 0x08)(src); \ - lw _t3, (offset + 0x0c)(src); \ - ADDC(sum, _t0); \ - ADDC(sum, _t1); \ - ADDC(sum, _t2); \ - ADDC(sum, _t3); \ - lw _t0, (offset + 0x10)(src); \ - lw _t1, (offset + 0x14)(src); \ - lw _t2, (offset + 0x18)(src); \ - lw _t3, (offset + 0x1c)(src); \ +#define CSUM_BIGCHUNK1(src, offset, sum, _t0, _t1, _t2, _t3) \ + LOAD _t0, (offset + UNIT(0))(src); \ + LOAD _t1, (offset + UNIT(1))(src); \ + LOAD _t2, (offset + UNIT(2))(src); \ + LOAD _t3, (offset + UNIT(3))(src); \ ADDC(sum, _t0); \ ADDC(sum, _t1); \ ADDC(sum, _t2); \ - ADDC(sum, _t3); \ + ADDC(sum, _t3) + +#ifdef USE_DOUBLE +#define CSUM_BIGCHUNK(src, offset, sum, _t0, _t1, _t2, _t3) \ + CSUM_BIGCHUNK1(src, offset, sum, _t0, _t1, _t2, _t3) +#else +#define CSUM_BIGCHUNK(src, offset, sum, _t0, _t1, _t2, _t3) \ + CSUM_BIGCHUNK1(src, offset, sum, _t0, _t1, _t2, _t3); \ + CSUM_BIGCHUNK1(src, offset + 0x10, sum, _t0, _t1, _t2, _t3) +#endif /* * a0: source address @@ -117,11 +136,17 @@ qword_align: beqz t8, oword_align andi t8, src, 0x10 +#ifdef USE_DOUBLE + ld t0, 0x00(src) + LONG_SUBU a1, a1, 0x8 + ADDC(sum, t0) +#else lw t0, 0x00(src) lw t1, 0x04(src) LONG_SUBU a1, a1, 0x8 ADDC(sum, t0) ADDC(sum, t1) +#endif PTR_ADDU src, src, 0x8 andi t8, src, 0x10 @@ -129,14 +154,14 @@ oword_align: beqz t8, begin_movement LONG_SRL t8, a1, 0x7 - lw t3, 0x08(src) - lw t4, 0x0c(src) - lw t0, 0x00(src) - lw t1, 0x04(src) - ADDC(sum, t3) - ADDC(sum, t4) +#ifdef USE_DOUBLE + ld t0, 0x00(src) + ld t1, 0x08(src) ADDC(sum, t0) ADDC(sum, t1) +#else + CSUM_BIGCHUNK1(src, 0x00, sum, t0, t1, t3, t4) +#endif LONG_SUBU a1, a1, 0x10 PTR_ADDU src, src, 0x10 LONG_SRL t8, a1, 0x7 @@ -219,6 +244,13 @@ #endif 1: ADDC(sum, t1) /* fold checksum */ +#ifdef USE_DOUBLE + dsll32 v1, sum, 0 + daddu sum, v1 + sltu v1, sum, v1 + dsra32 sum, sum, 0 + addu sum, v1 +#endif sll v1, sum, 16 addu sum, v1 sltu v1, sum, v1 From anemo@mba.ocn.ne.jp Thu Dec 7 16:55:12 2006 Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 07 Dec 2006 16:55:18 +0000 (GMT) Received: from mba.ocn.ne.jp ([210.190.142.172]:64991 "HELO smtp.mba.ocn.ne.jp") by ftp.linux-mips.org with SMTP id S20037690AbWLGQzM (ORCPT ); Thu, 7 Dec 2006 16:55:12 +0000 Received: from localhost (p8245-ipad29funabasi.chiba.ocn.ne.jp [221.184.75.245]) by smtp.mba.ocn.ne.jp (Postfix) with ESMTP id E8014B8B9; Fri, 8 Dec 2006 01:55:07 +0900 (JST) Date: Fri, 08 Dec 2006 01:55:07 +0900 (JST) Message-Id: <20061208.015507.82088245.anemo@mba.ocn.ne.jp> To: linux-mips@linux-mips.org Cc: ralf@linux-mips.org, vagabon.xyz@gmail.com Subject: [PATCH] add GENERIC_HARDIRQS_NO__DO_IRQ for i8259 users From: Atsushi Nemoto 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 3.3 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: 13407 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 Now i8259A_chip uses new irq flow handler. Select GENERIC_HARDIRQS_NO__DO_IRQ on some more platforms. Signed-off-by: Atsushi Nemoto --- arch/mips/Kconfig | 6 ++ arch/mips/tx4927/toshiba_rbtx4927/toshiba_rbtx4927_irq.c | 27 ------------- arch/mips/vr41xx/Kconfig | 5 -- arch/mips/vr41xx/nec-cmbvr4133/irq.c | 9 ---- 4 files changed, 9 insertions(+), 38 deletions(-) diff --git a/arch/mips/Kconfig b/arch/mips/Kconfig index 1afc890..78e70f2 100644 --- a/arch/mips/Kconfig +++ b/arch/mips/Kconfig @@ -165,6 +165,7 @@ config MIPS_COBALT select SYS_SUPPORTS_32BIT_KERNEL select SYS_SUPPORTS_64BIT_KERNEL if EXPERIMENTAL select SYS_SUPPORTS_LITTLE_ENDIAN + select GENERIC_HARDIRQS_NO__DO_IRQ config MACH_DECSTATION bool "DECstations" @@ -225,6 +226,7 @@ config MACH_JAZZ select SYS_SUPPORTS_32BIT_KERNEL select SYS_SUPPORTS_64BIT_KERNEL if EXPERIMENTAL select SYS_SUPPORTS_100HZ + select GENERIC_HARDIRQS_NO__DO_IRQ help This a family of machines based on the MIPS R4030 chipset which was used by several vendors to build RISC/os and Windows NT workstations. @@ -480,6 +482,7 @@ config DDB5477 config MACH_VR41XX bool "NEC VR41XX-based machines" select SYS_HAS_CPU_VR41XX + select GENERIC_HARDIRQS_NO__DO_IRQ config PMC_YOSEMITE bool "PMC-Sierra Yosemite eval board" @@ -513,6 +516,7 @@ config QEMU select SYS_SUPPORTS_BIG_ENDIAN select SYS_SUPPORTS_LITTLE_ENDIAN select ARCH_SPARSEMEM_ENABLE + select GENERIC_HARDIRQS_NO__DO_IRQ help Qemu is a software emulator which among other architectures also can simulate a MIPS32 4Kc system. This patch adds support for the @@ -752,6 +756,7 @@ config TOSHIBA_RBTX4927 select SYS_SUPPORTS_64BIT_KERNEL select SYS_SUPPORTS_BIG_ENDIAN select TOSHIBA_BOARDS + select GENERIC_HARDIRQS_NO__DO_IRQ help This Toshiba board is based on the TX4927 processor. Say Y here to support this machine type @@ -771,6 +776,7 @@ config TOSHIBA_RBTX4938 select SYS_SUPPORTS_LITTLE_ENDIAN select SYS_SUPPORTS_BIG_ENDIAN select TOSHIBA_BOARDS + select GENERIC_HARDIRQS_NO__DO_IRQ help This Toshiba board is based on the TX4938 processor. Say Y here to support this machine type diff --git a/arch/mips/tx4927/toshiba_rbtx4927/toshiba_rbtx4927_irq.c b/arch/mips/tx4927/toshiba_rbtx4927/toshiba_rbtx4927_irq.c index 5a5ea6c..b54b529 100644 --- a/arch/mips/tx4927/toshiba_rbtx4927/toshiba_rbtx4927_irq.c +++ b/arch/mips/tx4927/toshiba_rbtx4927/toshiba_rbtx4927_irq.c @@ -158,7 +158,6 @@ #define TOSHIBA_RBTX4927_IRQ_ISA_INIT #define TOSHIBA_RBTX4927_IRQ_ISA_ENABLE ( 1 << 23 ) #define TOSHIBA_RBTX4927_IRQ_ISA_DISABLE ( 1 << 24 ) #define TOSHIBA_RBTX4927_IRQ_ISA_MASK ( 1 << 25 ) -#define TOSHIBA_RBTX4927_IRQ_ISA_ENDIRQ ( 1 << 26 ) #define TOSHIBA_RBTX4927_SETUP_ALL 0xffffffff #endif @@ -175,7 +174,6 @@ static const u32 toshiba_rbtx4927_irq_de // | TOSHIBA_RBTX4927_IRQ_ISA_ENABLE // | TOSHIBA_RBTX4927_IRQ_ISA_DISABLE // | TOSHIBA_RBTX4927_IRQ_ISA_MASK -// | TOSHIBA_RBTX4927_IRQ_ISA_ENDIRQ ); #endif @@ -226,7 +224,6 @@ #ifdef CONFIG_TOSHIBA_FPCIB0 static void toshiba_rbtx4927_irq_isa_enable(unsigned int irq); static void toshiba_rbtx4927_irq_isa_disable(unsigned int irq); static void toshiba_rbtx4927_irq_isa_mask_and_ack(unsigned int irq); -static void toshiba_rbtx4927_irq_isa_end(unsigned int irq); #endif #define TOSHIBA_RBTX4927_IOC_NAME "RBTX4927-IOC" @@ -249,7 +246,6 @@ static struct irq_chip toshiba_rbtx4927_ .mask = toshiba_rbtx4927_irq_isa_disable, .mask_ack = toshiba_rbtx4927_irq_isa_mask_and_ack, .unmask = toshiba_rbtx4927_irq_isa_enable, - .end = toshiba_rbtx4927_irq_isa_end, }; #endif @@ -402,7 +398,8 @@ static void __init toshiba_rbtx4927_irq_ for (i = TOSHIBA_RBTX4927_IRQ_ISA_BEG; i <= TOSHIBA_RBTX4927_IRQ_ISA_END; i++) - set_irq_chip(i, &toshiba_rbtx4927_irq_isa_type); + set_irq_chip_and_handler(i, &toshiba_rbtx4927_irq_isa_type, + handle_level_irq); setup_irq(TOSHIBA_RBTX4927_IRQ_NEST_ISA_ON_IOC, &toshiba_rbtx4927_irq_isa_master); @@ -470,26 +467,6 @@ static void toshiba_rbtx4927_irq_isa_mas #endif -#ifdef CONFIG_TOSHIBA_FPCIB0 -static void toshiba_rbtx4927_irq_isa_end(unsigned int irq) -{ - TOSHIBA_RBTX4927_IRQ_DPRINTK(TOSHIBA_RBTX4927_IRQ_ISA_ENDIRQ, - "irq=%d\n", irq); - - if (irq < TOSHIBA_RBTX4927_IRQ_ISA_BEG - || irq > TOSHIBA_RBTX4927_IRQ_ISA_END) { - TOSHIBA_RBTX4927_IRQ_DPRINTK(TOSHIBA_RBTX4927_IRQ_EROR, - "bad irq=%d\n", irq); - panic("\n"); - } - - if (!(irq_desc[irq].status & (IRQ_DISABLED | IRQ_INPROGRESS))) { - toshiba_rbtx4927_irq_isa_enable(irq); - } -} -#endif - - void __init arch_init_irq(void) { extern void tx4927_irq_init(void); diff --git a/arch/mips/vr41xx/Kconfig b/arch/mips/vr41xx/Kconfig index c8dfd80..92f41f6 100644 --- a/arch/mips/vr41xx/Kconfig +++ b/arch/mips/vr41xx/Kconfig @@ -6,7 +6,6 @@ config CASIO_E55 select ISA select SYS_SUPPORTS_32BIT_KERNEL select SYS_SUPPORTS_LITTLE_ENDIAN - select GENERIC_HARDIRQS_NO__DO_IRQ config IBM_WORKPAD bool "Support for IBM WorkPad z50" @@ -16,7 +15,6 @@ config IBM_WORKPAD select ISA select SYS_SUPPORTS_32BIT_KERNEL select SYS_SUPPORTS_LITTLE_ENDIAN - select GENERIC_HARDIRQS_NO__DO_IRQ config NEC_CMBVR4133 bool "Support for NEC CMB-VR4133" @@ -41,7 +39,6 @@ config TANBAC_TB022X select IRQ_CPU select SYS_SUPPORTS_32BIT_KERNEL select SYS_SUPPORTS_LITTLE_ENDIAN - select GENERIC_HARDIRQS_NO__DO_IRQ help The TANBAC VR4131 multichip module(TB0225) and the TANBAC VR4131DIMM(TB0229) are MIPS-based platforms @@ -74,7 +71,6 @@ config VICTOR_MPC30X select IRQ_CPU select SYS_SUPPORTS_32BIT_KERNEL select SYS_SUPPORTS_LITTLE_ENDIAN - select GENERIC_HARDIRQS_NO__DO_IRQ config ZAO_CAPCELLA bool "Support for ZAO Networks Capcella" @@ -84,7 +80,6 @@ config ZAO_CAPCELLA select IRQ_CPU select SYS_SUPPORTS_32BIT_KERNEL select SYS_SUPPORTS_LITTLE_ENDIAN - select GENERIC_HARDIRQS_NO__DO_IRQ config PCI_VR41XX bool "Add PCI control unit support of NEC VR4100 series" diff --git a/arch/mips/vr41xx/nec-cmbvr4133/irq.c b/arch/mips/vr41xx/nec-cmbvr4133/irq.c index a039bb7..128ed8d 100644 --- a/arch/mips/vr41xx/nec-cmbvr4133/irq.c +++ b/arch/mips/vr41xx/nec-cmbvr4133/irq.c @@ -45,19 +45,12 @@ static void ack_i8259_irq(unsigned int i mask_and_ack_8259A(irq - I8259_IRQ_BASE); } -static void end_i8259_irq(unsigned int irq) -{ - if (!(irq_desc[irq].status & (IRQ_DISABLED|IRQ_INPROGRESS))) - enable_8259A_irq(irq - I8259_IRQ_BASE); -} - static struct irq_chip i8259_irq_type = { .typename = "XT-PIC", .ack = ack_i8259_irq, .mask = disable_i8259_irq, .mask_ack = ack_i8259_irq, .unmask = enable_i8259_irq, - .end = end_i8259_irq, }; static int i8259_get_irq_number(int irq) @@ -92,7 +85,7 @@ void __init rockhopper_init_irq(void) } for (i = I8259_IRQ_BASE; i <= I8259_IRQ_LAST; i++) - set_irq_chip(i, &i8259_irq_type); + set_irq_chip_and_handler(i, &i8259_irq_type, handle_level_irq); setup_irq(I8259_SLAVE_IRQ, &i8259_slave_cascade); From vagabon.xyz@gmail.com Thu Dec 7 17:16:04 2006 Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 07 Dec 2006 17:16:11 +0000 (GMT) Received: from an-out-0708.google.com ([209.85.132.241]:58413 "EHLO an-out-0708.google.com") by ftp.linux-mips.org with ESMTP id S20038436AbWLGRQE (ORCPT ); Thu, 7 Dec 2006 17:16:04 +0000 Received: by an-out-0708.google.com with SMTP id c8so69723ana for ; Thu, 07 Dec 2006 09:16:03 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=MTk3b8oPcPhaqfg5qL08abcsYAZpLfpAMVtfAjmSojC82IPmoR55cblCSXlNTYHgxKbBw5f8+OydwVj0RBbyBma4fHo8njMUBRaaukiB0B5ek/rvOHmHkq7DPBGMrplU/BooielzLPBMUnCyxJKikax0OXdkN+e/CeVFY2RXCqs= Received: by 10.78.183.15 with SMTP id g15mr1563236huf.1165511762418; Thu, 07 Dec 2006 09:16:02 -0800 (PST) Received: by 10.78.123.2 with HTTP; Thu, 7 Dec 2006 09:16:01 -0800 (PST) Message-ID: Date: Thu, 7 Dec 2006 18:16:01 +0100 From: "Franck Bui-Huu" To: "Atsushi Nemoto" Subject: Re: [PATCH] add GENERIC_HARDIRQS_NO__DO_IRQ for i8259 users Cc: linux-mips@linux-mips.org, ralf@linux-mips.org In-Reply-To: <20061208.015507.82088245.anemo@mba.ocn.ne.jp> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <20061208.015507.82088245.anemo@mba.ocn.ne.jp> 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: 13408 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 On 12/7/06, Atsushi Nemoto wrote: > Now i8259A_chip uses new irq flow handler. Select > GENERIC_HARDIRQS_NO__DO_IRQ on some more platforms. > Looks good to me. thanks -- Franck From vitalywool@gmail.com Thu Dec 7 20:43:24 2006 Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 07 Dec 2006 20:43:29 +0000 (GMT) Received: from ug-out-1314.google.com ([66.249.92.175]:22111 "EHLO ug-out-1314.google.com") by ftp.linux-mips.org with ESMTP id S20037774AbWLGUnY (ORCPT ); Thu, 7 Dec 2006 20:43:24 +0000 Received: by ug-out-1314.google.com with SMTP id 40so685971uga for ; Thu, 07 Dec 2006 12:43:17 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=WkflEvaQyj38ix7ZFZdMnO1856ViYR1hnAD+QbAu5nrqeL8W0enNxaS5B215sfrev1vsQPBKOC/afS45l9/fI0RVQ7lKsyf2pJE9Ky6NJIyd4b2vMHRmw6y9kUekOS8PLw8S6PTUq5vDaqceqCF9mb96P3q75ZxYFriXbQGrKWE= Received: by 10.82.118.2 with SMTP id q2mr51224buc.1165524183211; Thu, 07 Dec 2006 12:43:03 -0800 (PST) Received: by 10.82.108.6 with HTTP; Thu, 7 Dec 2006 12:43:03 -0800 (PST) Message-ID: Date: Thu, 7 Dec 2006 23:43:03 +0300 From: "Vitaly Wool" To: "Ralf Baechle" Subject: Re: [PATCH] add STB810 support (Philips PNX8550-based) Cc: linux-mips@linux-mips.org In-Reply-To: <20061207154830.GB4156@linux-mips.org> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_58093_30791097.1165524183120" References: <20061207182234.83212939.vitalywool@gmail.com> <20061207154830.GB4156@linux-mips.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: 13409 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: vitalywool@gmail.com Precedence: bulk X-list: linux-mips ------=_Part_58093_30791097.1165524183120 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline On 12/7/06, Ralf Baechle wrote: > > LOL. > > Doesn't look quite right. Let's see if you find out why ;-) > Shoot. Okay, that's really funny... copied the config from the other build... :( Vitaly ------=_Part_58093_30791097.1165524183120 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline On 12/7/06, Ralf Baechle <ralf@linux-mips.org> wrote:
LOL.

Doesn't look quite right.  Let's see if you find out why ;-)

Shoot. Okay, that's really funny... copied the config from the other build... :(

Vitaly
------=_Part_58093_30791097.1165524183120-- From ashlesha@kenati.com Fri Dec 8 01:49:01 2006 Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 08 Dec 2006 01:49:06 +0000 (GMT) Received: from [69.90.147.196] ([69.90.147.196]:42464 "EHLO mail.kenati.com") by ftp.linux-mips.org with ESMTP id S20037876AbWLHBtB (ORCPT ); Fri, 8 Dec 2006 01:49:01 +0000 Received: from [192.168.1.169] (adsl-71-130-109-177.dsl.snfc21.pacbell.net [71.130.109.177]) by mail.kenati.com (Postfix) with ESMTP id 1207615D4004; Thu, 7 Dec 2006 19:19:10 -0800 (PST) Subject: Serial 8250 driver registration: From: Ashlesha Shintre Reply-To: ashlesha@kenati.com To: Atsushi Nemoto , Sergei Shtylyov Cc: linux-mips@linux-mips.org In-Reply-To: <20061208.101112.108306293.nemoto@toshiba-tops.co.jp> References: <1165462754.6516.40.camel@sandbar.kenati.com> <20061207.131306.63741931.nemoto@toshiba-tops.co.jp> <1165534711.6512.10.camel@sandbar.kenati.com> <20061208.101112.108306293.nemoto@toshiba-tops.co.jp> Content-Type: text/plain Date: Thu, 07 Dec 2006 18:01:45 -0800 Message-Id: <1165543305.6512.17.camel@sandbar.kenati.com> Mime-Version: 1.0 X-Mailer: Evolution 2.4.2.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: 13410 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: ashlesha@kenati.com Precedence: bulk X-list: linux-mips Hi, Yeah, i thought you might have meant that :-) i m starting to think that the uartclk parameter that i pass to the platform_add_devices function might be wrong -- i m passing the standard value of 1843200 for a baudrate of 115200... now the output after the board specific encm3_platform_init function is called, is the kernel messages with mostly alternate characters missing, like so: > 1000 s 1.5 P P > 0: A1 Ee d 01500000, 28 > 0: Bd BCM5221 10/100 BT PHY e 0 > 0: U Bd BCM5221 10/100 BT PHY a > 1: A1 Er 01510000, 29 > 1: Bo BCM5221 10/100 BT PHY r 0 > 1: U Bo BCM5221 10/100 BT PHY a > NET: Rt c l 2 > IP h e r: 1024 (r: 0, 4096 ) > TCP a e r: 4096 (r: 2, 16384 e) > TCP e r: 4096 (r: 2, 16384 e) > TCP: H e i (b 4096 d 4096) > TCP o i > TCP t > NET: Re c l 1 > NET: Rs t y 17 > IP-Ci: Gs m 255.255.255.0 > IP-C:: Ce: > c=0, =192.168.1.147, =255.255.255.0, =255.255.255.255, > =192.168.1.147, ==, -n=(e)<6>0: n l x > , > s=255.255.255.255, s=192.168.1.8, p= > d c n > i n > Ln t RPC 100003/2 192.168.1.8 > Li RPC 100005/1 192.168.1.8 > VFS: Me ( y). > Fi e e y: 128 Could there be another cause for this? This is my platform_device structure: > static struct plat_serial8250_port encm3_via_uart_data[] = { > { > .iobase = 0x3f8, //iobase address > // .membase = (char *)(0x50000000 + 0x3f8), // is a pointer - ioremap cookie or NULL > .irq = INT_PIC_4, // interrupt 4 from the 8259 on the southbridge > // .flags = UPF_SHARE_IRQ, //| UPF_SKIP_TEST | > .flags = UPF_BOOT_AUTOCONF | UPF_SKIP_TEST | UPF_AUTO_IRQ, > .iotype = UPIO_PORT, > .regshift = 1, > .uartclk = 1843200, > > }, > { }, > }; Regards, Ashlesha. From vitalywool@gmail.com Fri Dec 8 08:40:40 2006 Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 08 Dec 2006 08:40:44 +0000 (GMT) Received: from rtsoft3.corbina.net ([85.21.88.6]:27198 "EHLO buildserver.ru.mvista.com") by ftp.linux-mips.org with ESMTP id S20027704AbWLHIkk (ORCPT ); Fri, 8 Dec 2006 08:40:40 +0000 Received: from barja (unknown [10.150.0.9]) by buildserver.ru.mvista.com (Postfix) with SMTP id D69C88810; Fri, 8 Dec 2006 12:40:34 +0400 (SAMT) Date: Fri, 8 Dec 2006 11:40:35 +0300 From: Vitaly Wool To: ralf@linux-mips.org Cc: linux-mips@linux-mips.org Subject: [PATCH][respin] add STB810 support (Philips PNX8550-based) Message-Id: <20061208114035.000049c4.vitalywool@gmail.com> Organization: MontaVista X-Mailer: Sylpheed version 0.7.5-20020429 (GTK+ 1.3.0; Win32) 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: 13411 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: vitalywool@gmail.com Precedence: bulk X-list: linux-mips Hello Ralf, please find the updated patch that adds support for STB810 below. arch/mips/Kconfig | 5 arch/mips/Makefile | 5 arch/mips/configs/pnx8550-stb810_defconfig | 1229 +++++++++++++++++++++++++ arch/mips/pci/fixup-pnx8550.c | 4 arch/mips/philips/pnx8550/common/prom.c | 20 arch/mips/philips/pnx8550/jbs/irqmap.c | 8 arch/mips/philips/pnx8550/stb810/Makefile | 4 arch/mips/philips/pnx8550/stb810/board_setup.c | 49 arch/mips/philips/pnx8550/stb810/irqmap.c | 23 arch/mips/philips/pnx8550/stb810/prom_init.c | 49 include/asm-mips/bootinfo.h | 1 11 files changed, 1377 insertions(+), 20 deletions(-) Signed-off-by: Vitaly Wool Index: linux-mips.git/arch/mips/Kconfig =================================================================== --- linux-mips.git.orig/arch/mips/Kconfig 2006-12-08 11:31:42.000000000 +0300 +++ linux-mips.git/arch/mips/Kconfig 2006-12-08 11:31:44.000000000 +0300 @@ -459,6 +459,11 @@ select PNX8550 select SYS_SUPPORTS_LITTLE_ENDIAN +config PNX8550_STB810 + bool "Support for Philips PNX8550 based STB810 board" + select PNX8550 + select SYS_SUPPORTS_LITTLE_ENDIAN + config DDB5477 bool "NEC DDB Vrc-5477" select DDB5XXX_COMMON Index: linux-mips.git/arch/mips/Makefile =================================================================== --- linux-mips.git.orig/arch/mips/Makefile 2006-12-08 11:31:42.000000000 +0300 +++ linux-mips.git/arch/mips/Makefile 2006-12-08 11:31:44.000000000 +0300 @@ -463,6 +463,11 @@ #cflags-$(CONFIG_PNX8550_JBS) += -Iinclude/asm-mips/mach-pnx8550 load-$(CONFIG_PNX8550_JBS) += 0xffffffff80060000 +# Philips PNX8550 STB810 board +# +libs-$(CONFIG_PNX8550_STB810) += arch/mips/philips/pnx8550/stb810/ +load-$(CONFIG_PNX8550_STB810) += 0xffffffff80060000 + # NEC EMMA2RH boards # core-$(CONFIG_EMMA2RH) += arch/mips/emma2rh/common/ Index: linux-mips.git/arch/mips/configs/pnx8550-stb810_defconfig =================================================================== --- /dev/null 1970-01-01 00:00:00.000000000 +0000 +++ linux-mips.git/arch/mips/configs/pnx8550-stb810_defconfig 2006-12-08 11:31:44.000000000 +0300 @@ -0,0 +1,1229 @@ +# +# Automatically generated make config: don't edit +# Linux kernel version: 2.6.19 +# Thu Dec 7 16:35:12 2006 +# +CONFIG_MIPS=y + +# +# Machine selection +# +# CONFIG_MIPS_MTX1 is not set +# CONFIG_MIPS_BOSPORUS is not set +# CONFIG_MIPS_PB1000 is not set +# CONFIG_MIPS_PB1100 is not set +# CONFIG_MIPS_PB1500 is not set +# CONFIG_MIPS_PB1550 is not set +# CONFIG_MIPS_PB1200 is not set +# CONFIG_MIPS_DB1000 is not set +# CONFIG_MIPS_DB1100 is not set +# CONFIG_MIPS_DB1500 is not set +# CONFIG_MIPS_DB1550 is not set +# CONFIG_MIPS_DB1200 is not set +# CONFIG_MIPS_MIRAGE is not set +# CONFIG_BASLER_EXCITE is not set +# CONFIG_MIPS_COBALT is not set +# CONFIG_MACH_DECSTATION is not set +# CONFIG_MIPS_EV64120 is not set +# CONFIG_MACH_JAZZ is not set +# CONFIG_LASAT is not set +# CONFIG_MIPS_ATLAS is not set +# CONFIG_MIPS_MALTA is not set +# CONFIG_MIPS_SEAD is not set +# CONFIG_WR_PPMC is not set +# CONFIG_MIPS_SIM is not set +# CONFIG_MOMENCO_JAGUAR_ATX is not set +# CONFIG_MOMENCO_OCELOT is not set +# CONFIG_MOMENCO_OCELOT_3 is not set +# CONFIG_MOMENCO_OCELOT_C is not set +# CONFIG_MOMENCO_OCELOT_G is not set +# CONFIG_MIPS_XXS1500 is not set +# CONFIG_PNX8550_V2PCI is not set +# CONFIG_PNX8550_JBS is not set +CONFIG_PNX8550_STB810=y +# CONFIG_DDB5477 is not set +# CONFIG_MACH_VR41XX is not set +# CONFIG_PMC_YOSEMITE is not set +# CONFIG_QEMU is not set +# CONFIG_MARKEINS is not set +# CONFIG_SGI_IP22 is not set +# CONFIG_SGI_IP27 is not set +# CONFIG_SGI_IP32 is not set +# CONFIG_SIBYTE_BIGSUR is not set +# CONFIG_SIBYTE_SWARM is not set +# CONFIG_SIBYTE_SENTOSA is not set +# CONFIG_SIBYTE_RHONE is not set +# CONFIG_SIBYTE_CARMEL is not set +# CONFIG_SIBYTE_PTSWARM is not set +# CONFIG_SIBYTE_LITTLESUR is not set +# CONFIG_SIBYTE_CRHINE is not set +# CONFIG_SIBYTE_CRHONE is not set +# CONFIG_SNI_RM200_PCI is not set +# CONFIG_TOSHIBA_JMR3927 is not set +# CONFIG_TOSHIBA_RBTX4927 is not set +# CONFIG_TOSHIBA_RBTX4938 is not set +# CONFIG_KEXEC is not set +CONFIG_RWSEM_GENERIC_SPINLOCK=y +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_DMA_NONCOHERENT=y +CONFIG_DMA_NEED_PCI_MAP_STATE=y +# CONFIG_CPU_BIG_ENDIAN is not set +CONFIG_CPU_LITTLE_ENDIAN=y +CONFIG_SYS_SUPPORTS_LITTLE_ENDIAN=y +CONFIG_PNX8550=y +CONFIG_SOC_PNX8550=y +CONFIG_MIPS_L1_CACHE_SHIFT=5 + +# +# CPU selection +# +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_MIPS_VPE_LOADER is not set +# CONFIG_64BIT_PHYS_ADDR is not set +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 is not set +# 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=y +# CONFIG_PREEMPT_VOLUNTARY is not set +# CONFIG_PREEMPT is not set +CONFIG_LOCKDEP_SUPPORT=y +CONFIG_STACKTRACE_SUPPORT=y +CONFIG_DEFCONFIG_LIST="/lib/modules/$UNAME_RELEASE/.config" + +# +# Code maturity level options +# +CONFIG_EXPERIMENTAL=y +CONFIG_BROKEN_ON_SMP=y +CONFIG_INIT_ENV_ARG_LIMIT=32 + +# +# General setup +# +CONFIG_LOCALVERSION="" +CONFIG_LOCALVERSION_AUTO=y +CONFIG_SWAP=y +CONFIG_SYSVIPC=y +# CONFIG_IPC_NS is not set +# CONFIG_POSIX_MQUEUE is not set +# CONFIG_BSD_PROCESS_ACCT is not set +# CONFIG_TASKSTATS is not set +# CONFIG_UTS_NS is not set +# CONFIG_AUDIT is not set +CONFIG_IKCONFIG=y +CONFIG_IKCONFIG_PROC=y +CONFIG_SYSFS_DEPRECATED=y +# CONFIG_RELAY is not set +CONFIG_INITRAMFS_SOURCE="" +# CONFIG_CC_OPTIMIZE_FOR_SIZE is not set +CONFIG_SYSCTL=y +CONFIG_EMBEDDED=y +# CONFIG_SYSCTL_SYSCALL is not set +CONFIG_KALLSYMS=y +# CONFIG_KALLSYMS_ALL is not set +# CONFIG_KALLSYMS_EXTRA_PASS is not set +# CONFIG_HOTPLUG is not set +CONFIG_PRINTK=y +CONFIG_BUG=y +CONFIG_ELF_CORE=y +CONFIG_BASE_FULL=y +CONFIG_FUTEX=y +CONFIG_EPOLL=y +CONFIG_SHMEM=y +CONFIG_SLAB=y +CONFIG_VM_EVENT_COUNTERS=y +CONFIG_RT_MUTEXES=y +# CONFIG_TINY_SHMEM is not set +CONFIG_BASE_SMALL=0 +# CONFIG_SLOB is not set + +# +# Loadable module support +# +CONFIG_MODULES=y +# CONFIG_MODULE_UNLOAD is not set +# CONFIG_MODVERSIONS is not set +# CONFIG_MODULE_SRCVERSION_ALL is not set +CONFIG_KMOD=y + +# +# Block layer +# +CONFIG_BLOCK=y +# CONFIG_LBD is not set +# CONFIG_BLK_DEV_IO_TRACE is not set +# CONFIG_LSF is not set + +# +# IO Schedulers +# +CONFIG_IOSCHED_NOOP=y +CONFIG_IOSCHED_AS=y +CONFIG_IOSCHED_DEADLINE=y +CONFIG_IOSCHED_CFQ=y +CONFIG_DEFAULT_AS=y +# CONFIG_DEFAULT_DEADLINE is not set +# CONFIG_DEFAULT_CFQ is not set +# CONFIG_DEFAULT_NOOP is not set +CONFIG_DEFAULT_IOSCHED="anticipatory" + +# +# Bus options (PCI, PCMCIA, EISA, ISA, TC) +# +CONFIG_HW_HAS_PCI=y +CONFIG_PCI=y +# CONFIG_PCI_MULTITHREAD_PROBE is not set +# CONFIG_PCI_DEBUG is not set +CONFIG_MMU=y + +# +# PCCARD (PCMCIA/CardBus) support +# + +# +# PCI Hotplug Support +# + +# +# Executable file formats +# +CONFIG_BINFMT_ELF=y +# CONFIG_BINFMT_MISC is not set +CONFIG_TRAD_SIGNALS=y + +# +# Networking +# +CONFIG_NET=y + +# +# Networking options +# +# CONFIG_NETDEBUG is not set +CONFIG_PACKET=y +# CONFIG_PACKET_MMAP is not set +CONFIG_UNIX=y +CONFIG_XFRM=y +# CONFIG_XFRM_USER is not set +# CONFIG_XFRM_SUB_POLICY is not set +# CONFIG_NET_KEY is not set +CONFIG_INET=y +# CONFIG_IP_MULTICAST is not set +# CONFIG_IP_ADVANCED_ROUTER is not set +CONFIG_IP_FIB_HASH=y +CONFIG_IP_PNP=y +CONFIG_IP_PNP_DHCP=y +CONFIG_IP_PNP_BOOTP=y +# CONFIG_IP_PNP_RARP is not set +# CONFIG_NET_IPIP is not set +# CONFIG_NET_IPGRE is not set +# CONFIG_ARPD is not set +# CONFIG_SYN_COOKIES is not set +# CONFIG_INET_AH is not set +# CONFIG_INET_ESP is not set +# CONFIG_INET_IPCOMP is not set +# CONFIG_INET_XFRM_TUNNEL is not set +# CONFIG_INET_TUNNEL is not set +CONFIG_INET_XFRM_MODE_TRANSPORT=y +CONFIG_INET_XFRM_MODE_TUNNEL=y +CONFIG_INET_XFRM_MODE_BEET=y +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_IPV6 is not set +# CONFIG_INET6_XFRM_TUNNEL is not set +# CONFIG_INET6_TUNNEL is not set +# CONFIG_NETWORK_SECMARK is not set +# CONFIG_NETFILTER is not set + +# +# DCCP Configuration (EXPERIMENTAL) +# +# CONFIG_IP_DCCP is not set + +# +# SCTP Configuration (EXPERIMENTAL) +# +# CONFIG_IP_SCTP is not set + +# +# TIPC Configuration (EXPERIMENTAL) +# +# CONFIG_TIPC is not set +# CONFIG_ATM is not set +# CONFIG_BRIDGE is not set +# CONFIG_VLAN_8021Q is not set +# CONFIG_DECNET is not set +# CONFIG_LLC2 is not set +# CONFIG_IPX is not set +# CONFIG_ATALK is not set +# CONFIG_X25 is not set +# CONFIG_LAPB is not set +# CONFIG_ECONET is not set +# CONFIG_WAN_ROUTER is not set + +# +# QoS and/or fair queueing +# +# CONFIG_NET_SCHED is not set + +# +# Network testing +# +# CONFIG_NET_PKTGEN is not set +# CONFIG_HAMRADIO is not set +# CONFIG_IRDA is not set +# CONFIG_BT is not set +# CONFIG_IEEE80211 is not set + +# +# Device Drivers +# + +# +# Generic Driver Options +# +CONFIG_STANDALONE=y +CONFIG_PREVENT_FIRMWARE_BUILD=y +# CONFIG_DEBUG_DRIVER is not set +# CONFIG_SYS_HYPERVISOR is not set + +# +# Connector - unified userspace <-> kernelspace linker +# +# CONFIG_CONNECTOR is not set + +# +# Memory Technology Devices (MTD) +# +# CONFIG_MTD is not set + +# +# Parallel port support +# +# CONFIG_PARPORT is not set + +# +# Plug and Play support +# + +# +# Block devices +# +# CONFIG_BLK_CPQ_DA is not set +# CONFIG_BLK_CPQ_CISS_DA is not set +# CONFIG_BLK_DEV_DAC960 is not set +# CONFIG_BLK_DEV_UMEM is not set +# CONFIG_BLK_DEV_COW_COMMON is not set +CONFIG_BLK_DEV_LOOP=y +# CONFIG_BLK_DEV_CRYPTOLOOP is not set +# CONFIG_BLK_DEV_NBD is not set +# CONFIG_BLK_DEV_SX8 is not set +# CONFIG_BLK_DEV_UB is not set +CONFIG_BLK_DEV_RAM=y +CONFIG_BLK_DEV_RAM_COUNT=16 +CONFIG_BLK_DEV_RAM_SIZE=8192 +CONFIG_BLK_DEV_RAM_BLOCKSIZE=1024 +CONFIG_BLK_DEV_INITRD=y +# CONFIG_CDROM_PKTCDVD is not set +# CONFIG_ATA_OVER_ETH is not set + +# +# Misc devices +# +# CONFIG_SGI_IOC4 is not set +# CONFIG_TIFM_CORE is not set + +# +# ATA/ATAPI/MFM/RLL support +# +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=y +# CONFIG_IDEDISK_MULTI_MODE is not set +CONFIG_BLK_DEV_IDECD=m +# CONFIG_BLK_DEV_IDETAPE is not set +# CONFIG_BLK_DEV_IDEFLOPPY is not set +CONFIG_BLK_DEV_IDESCSI=y +# CONFIG_IDE_TASK_IOCTL is not set + +# +# IDE chipset support/bugfixes +# +CONFIG_IDE_GENERIC=y +CONFIG_BLK_DEV_IDEPCI=y +CONFIG_IDEPCI_SHARE_IRQ=y +CONFIG_BLK_DEV_OFFBOARD=y +CONFIG_BLK_DEV_GENERIC=y +# CONFIG_BLK_DEV_OPTI621 is not set +CONFIG_BLK_DEV_IDEDMA_PCI=y +# CONFIG_BLK_DEV_IDEDMA_FORCED is not set +# CONFIG_IDEDMA_PCI_AUTO is not set +# CONFIG_BLK_DEV_AEC62XX is not set +# CONFIG_BLK_DEV_ALI15X3 is not set +# CONFIG_BLK_DEV_AMD74XX is not set +# CONFIG_BLK_DEV_CMD64X is not set +# CONFIG_BLK_DEV_TRIFLEX is not set +# CONFIG_BLK_DEV_CY82C693 is not set +# CONFIG_BLK_DEV_CS5520 is not set +# CONFIG_BLK_DEV_CS5530 is not set +# CONFIG_BLK_DEV_HPT34X is not set +CONFIG_BLK_DEV_HPT366=y +# CONFIG_BLK_DEV_JMICRON is not set +# CONFIG_BLK_DEV_SC1200 is not set +# CONFIG_BLK_DEV_PIIX is not set +# CONFIG_BLK_DEV_IT821X is not set +# CONFIG_BLK_DEV_NS87415 is not set +# CONFIG_BLK_DEV_PDC202XX_OLD is not set +# CONFIG_BLK_DEV_PDC202XX_NEW is not set +# CONFIG_BLK_DEV_SVWKS is not set +# CONFIG_BLK_DEV_SIIMAGE is not set +# CONFIG_BLK_DEV_SLC90E66 is not set +# CONFIG_BLK_DEV_TRM290 is not set +# CONFIG_BLK_DEV_VIA82CXXX is not set +# CONFIG_IDE_ARM is not set +CONFIG_BLK_DEV_IDEDMA=y +# CONFIG_IDEDMA_IVB is not set +# CONFIG_IDEDMA_AUTO is not set +# CONFIG_BLK_DEV_HD is not set + +# +# SCSI device support +# +# CONFIG_RAID_ATTRS is not set +CONFIG_SCSI=y +# CONFIG_SCSI_NETLINK is not set +CONFIG_SCSI_PROC_FS=y + +# +# SCSI support type (disk, tape, CD-ROM) +# +CONFIG_BLK_DEV_SD=y +# CONFIG_CHR_DEV_ST is not set +# CONFIG_CHR_DEV_OSST is not set +# CONFIG_BLK_DEV_SR is not set +# CONFIG_CHR_DEV_SG is not set +# CONFIG_CHR_DEV_SCH is not set + +# +# Some SCSI devices (e.g. CD jukebox) support multiple LUNs +# +# CONFIG_SCSI_MULTI_LUN is not set +CONFIG_SCSI_CONSTANTS=y +# CONFIG_SCSI_LOGGING is not set + +# +# SCSI Transports +# +# CONFIG_SCSI_SPI_ATTRS is not set +# CONFIG_SCSI_FC_ATTRS is not set +CONFIG_SCSI_ISCSI_ATTRS=m +# CONFIG_SCSI_SAS_ATTRS is not set +# CONFIG_SCSI_SAS_LIBSAS is not set + +# +# SCSI low-level drivers +# +CONFIG_ISCSI_TCP=m +# CONFIG_BLK_DEV_3W_XXXX_RAID is not set +# CONFIG_SCSI_3W_9XXX is not set +# CONFIG_SCSI_ACARD is not set +# CONFIG_SCSI_AACRAID is not set +# CONFIG_SCSI_AIC7XXX is not set +# CONFIG_SCSI_AIC7XXX_OLD is not set +# CONFIG_SCSI_AIC79XX is not set +# CONFIG_SCSI_AIC94XX is not set +# CONFIG_SCSI_DPT_I2O is not set +# CONFIG_SCSI_ARCMSR is not set +# CONFIG_MEGARAID_NEWGEN is not set +# CONFIG_MEGARAID_LEGACY is not set +# CONFIG_MEGARAID_SAS is not set +# CONFIG_SCSI_HPTIOP is not set +# CONFIG_SCSI_DMX3191D is not set +# CONFIG_SCSI_FUTURE_DOMAIN is not set +# CONFIG_SCSI_IPS is not set +# CONFIG_SCSI_INITIO is not set +# CONFIG_SCSI_INIA100 is not set +# CONFIG_SCSI_STEX is not set +# CONFIG_SCSI_SYM53C8XX_2 is not set +# CONFIG_SCSI_QLOGIC_1280 is not set +# CONFIG_SCSI_QLA_FC is not set +# CONFIG_SCSI_QLA_ISCSI is not set +# CONFIG_SCSI_LPFC is not set +# CONFIG_SCSI_DC395x is not set +# CONFIG_SCSI_DC390T is not set +# CONFIG_SCSI_NSP32 is not set +# CONFIG_SCSI_DEBUG is not set + +# +# Serial ATA (prod) and Parallel ATA (experimental) drivers +# +# CONFIG_ATA is not set + +# +# Multi-device support (RAID and LVM) +# +# CONFIG_MD is not set + +# +# Fusion MPT device support +# +# CONFIG_FUSION is not set +# CONFIG_FUSION_SPI is not set +# CONFIG_FUSION_FC is not set +# CONFIG_FUSION_SAS is not set + +# +# IEEE 1394 (FireWire) support +# +# CONFIG_IEEE1394 is not set + +# +# I2O device support +# +# CONFIG_I2O is not set + +# +# Network device support +# +CONFIG_NETDEVICES=y +# CONFIG_DUMMY is not set +# CONFIG_BONDING is not set +# CONFIG_EQUALIZER is not set +# CONFIG_TUN is not set + +# +# ARCnet devices +# +# CONFIG_ARCNET is not set + +# +# PHY device support +# +# CONFIG_PHYLIB is not set + +# +# Ethernet (10 or 100Mbit) +# +CONFIG_NET_ETHERNET=y +CONFIG_MII=y +# CONFIG_HAPPYMEAL is not set +# CONFIG_SUNGEM is not set +# CONFIG_CASSINI is not set +# CONFIG_NET_VENDOR_3COM is not set +# CONFIG_DM9000 is not set + +# +# Tulip family network device support +# +# CONFIG_NET_TULIP is not set +# CONFIG_HP100 is not set +CONFIG_NET_PCI=y +# CONFIG_PCNET32 is not set +# CONFIG_AMD8111_ETH is not set +# CONFIG_ADAPTEC_STARFIRE is not set +# CONFIG_B44 is not set +# CONFIG_FORCEDETH is not set +# CONFIG_DGRS is not set +# CONFIG_EEPRO100 is not set +# CONFIG_E100 is not set +# CONFIG_FEALNX is not set +CONFIG_NATSEMI=y +# CONFIG_NE2K_PCI is not set +# CONFIG_8139CP is not set +# CONFIG_8139TOO is not set +# CONFIG_SIS900 is not set +# CONFIG_EPIC100 is not set +# CONFIG_SUNDANCE is not set +# CONFIG_TLAN is not set +# CONFIG_VIA_RHINE is not set + +# +# Ethernet (1000 Mbit) +# +# CONFIG_ACENIC is not set +# CONFIG_DL2K is not set +# CONFIG_E1000 is not set +# CONFIG_NS83820 is not set +# CONFIG_HAMACHI is not set +# CONFIG_YELLOWFIN is not set +# CONFIG_R8169 is not set +# CONFIG_SIS190 is not set +# CONFIG_SKGE is not set +# CONFIG_SKY2 is not set +# CONFIG_SK98LIN is not set +# CONFIG_VIA_VELOCITY is not set +# CONFIG_TIGON3 is not set +# CONFIG_BNX2 is not set +# CONFIG_QLA3XXX is not set + +# +# Ethernet (10000 Mbit) +# +# CONFIG_CHELSIO_T1 is not set +# CONFIG_IXGB is not set +# CONFIG_S2IO is not set +# CONFIG_MYRI10GE is not set +# CONFIG_NETXEN_NIC is not set + +# +# Token Ring devices +# +# CONFIG_TR is not set + +# +# Wireless LAN (non-hamradio) +# +# CONFIG_NET_RADIO is not set + +# +# Wan interfaces +# +# CONFIG_WAN is not set +# CONFIG_FDDI is not set +# CONFIG_HIPPI is not set +# CONFIG_PPP is not set +# CONFIG_SLIP is not set +# CONFIG_NET_FC is not set +# CONFIG_SHAPER is not set +# CONFIG_NETCONSOLE is not set +# CONFIG_NETPOLL is not set +# CONFIG_NET_POLL_CONTROLLER is not set + +# +# ISDN subsystem +# +# CONFIG_ISDN is not set + +# +# Telephony Support +# +# CONFIG_PHONE is not set + +# +# Input device support +# +CONFIG_INPUT=y +# CONFIG_INPUT_FF_MEMLESS is not set + +# +# Userland interfaces +# +# CONFIG_INPUT_MOUSEDEV is not set +# CONFIG_INPUT_JOYDEV is not set +# CONFIG_INPUT_TSDEV is not set +# CONFIG_INPUT_EVDEV is not set +# CONFIG_INPUT_EVBUG is not set + +# +# Input Device Drivers +# +# CONFIG_INPUT_KEYBOARD is not set +# CONFIG_INPUT_MOUSE is not set +# CONFIG_INPUT_JOYSTICK is not set +# CONFIG_INPUT_TOUCHSCREEN is not set +# CONFIG_INPUT_MISC is not set + +# +# Hardware I/O ports +# +CONFIG_SERIO=y +# CONFIG_SERIO_I8042 is not set +# CONFIG_SERIO_SERPORT is not set +# CONFIG_SERIO_PCIPS2 is not set +CONFIG_SERIO_LIBPS2=y +# CONFIG_SERIO_RAW is not set +# CONFIG_GAMEPORT is not set + +# +# Character devices +# +CONFIG_VT=y +CONFIG_VT_CONSOLE=y +CONFIG_HW_CONSOLE=y +# CONFIG_VT_HW_CONSOLE_BINDING is not set +# CONFIG_SERIAL_NONSTANDARD is not set + +# +# Serial drivers +# +# CONFIG_SERIAL_8250 is not set + +# +# Non-8250 serial port support +# +# CONFIG_SERIAL_PNX8XXX is not set +# CONFIG_SERIAL_JSM is not set +CONFIG_UNIX98_PTYS=y +CONFIG_LEGACY_PTYS=y +CONFIG_LEGACY_PTY_COUNT=256 + +# +# IPMI +# +# CONFIG_IPMI_HANDLER is not set + +# +# Watchdog Cards +# +# CONFIG_WATCHDOG is not set +CONFIG_HW_RANDOM=y +# CONFIG_RTC is not set +# CONFIG_GEN_RTC is not set +# CONFIG_DTLK is not set +# CONFIG_R3964 is not set +# CONFIG_APPLICOM is not set +# CONFIG_DRM is not set +# CONFIG_RAW_DRIVER is not set + +# +# TPM devices +# +# CONFIG_TCG_TPM is not set + +# +# I2C support +# +# CONFIG_I2C is not set + +# +# SPI support +# +# CONFIG_SPI is not set +# CONFIG_SPI_MASTER is not set + +# +# Dallas's 1-wire bus +# +# CONFIG_W1 is not set + +# +# Hardware Monitoring support +# +CONFIG_HWMON=y +# CONFIG_HWMON_VID is not set +# CONFIG_SENSORS_ABITUGURU is not set +# CONFIG_SENSORS_F71805F is not set +# CONFIG_SENSORS_VT1211 is not set +# CONFIG_HWMON_DEBUG_CHIP is not set + +# +# Multimedia devices +# +# CONFIG_VIDEO_DEV is not set + +# +# Digital Video Broadcasting Devices +# +# CONFIG_DVB is not set +# CONFIG_USB_DABUSB is not set + +# +# Graphics support +# +CONFIG_FIRMWARE_EDID=y +# CONFIG_FB is not set + +# +# Console display driver support +# +# CONFIG_VGA_CONSOLE is not set +CONFIG_DUMMY_CONSOLE=y +# CONFIG_BACKLIGHT_LCD_SUPPORT is not set + +# +# Sound +# +# CONFIG_SOUND is not set + +# +# USB support +# +CONFIG_USB_ARCH_HAS_HCD=y +CONFIG_USB_ARCH_HAS_OHCI=y +CONFIG_USB_ARCH_HAS_EHCI=y +CONFIG_USB=y +# CONFIG_USB_DEBUG is not set + +# +# Miscellaneous USB options +# +# CONFIG_USB_DEVICEFS is not set +# CONFIG_USB_BANDWIDTH is not set +# CONFIG_USB_DYNAMIC_MINORS is not set +# CONFIG_USB_MULTITHREAD_PROBE is not set +# CONFIG_USB_OTG is not set + +# +# USB Host Controller Drivers +# +# CONFIG_USB_EHCI_HCD is not set +# CONFIG_USB_ISP116X_HCD is not set +CONFIG_USB_OHCI_HCD=y +# CONFIG_USB_OHCI_BIG_ENDIAN is not set +CONFIG_USB_OHCI_LITTLE_ENDIAN=y +# CONFIG_USB_UHCI_HCD is not set +# CONFIG_USB_SL811_HCD is not set + +# +# USB Device Class drivers +# +# CONFIG_USB_ACM is not set +# CONFIG_USB_PRINTER is not set + +# +# NOTE: USB_STORAGE enables SCSI, and 'SCSI disk support' +# + +# +# may also be needed; see USB_STORAGE Help for more information +# +CONFIG_USB_STORAGE=y +# 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 is not set +# CONFIG_USB_STORAGE_KARMA is not set +# CONFIG_USB_LIBUSUAL is not set + +# +# USB Input Devices +# +# CONFIG_USB_HID is not set + +# +# USB HID Boot Protocol drivers +# +# CONFIG_USB_KBD is not set +# CONFIG_USB_MOUSE is not set +# CONFIG_USB_AIPTEK is not set +# CONFIG_USB_WACOM is not set +# CONFIG_USB_ACECAD is not set +# CONFIG_USB_KBTAB is not set +# CONFIG_USB_POWERMATE is not set +# CONFIG_USB_TOUCHSCREEN is not set +# CONFIG_USB_YEALINK is not set +# CONFIG_USB_XPAD is not set +# CONFIG_USB_ATI_REMOTE is not set +# CONFIG_USB_ATI_REMOTE2 is not set +# CONFIG_USB_KEYSPAN_REMOTE is not set +# CONFIG_USB_APPLETOUCH is not set + +# +# USB Imaging devices +# +# CONFIG_USB_MDC800 is not set +# CONFIG_USB_MICROTEK is not set + +# +# USB Network Adapters +# +# CONFIG_USB_CATC is not set +# CONFIG_USB_KAWETH is not set +# CONFIG_USB_PEGASUS is not set +# CONFIG_USB_RTL8150 is not set +# CONFIG_USB_USBNET_MII is not set +# CONFIG_USB_USBNET is not set +CONFIG_USB_MON=y + +# +# USB port drivers +# + +# +# USB Serial Converter support +# +# CONFIG_USB_SERIAL is not set + +# +# USB Miscellaneous drivers +# +# CONFIG_USB_EMI62 is not set +# CONFIG_USB_EMI26 is not set +# CONFIG_USB_ADUTUX is not set +# CONFIG_USB_AUERSWALD is not set +# CONFIG_USB_RIO500 is not set +# CONFIG_USB_LEGOTOWER is not set +# CONFIG_USB_LCD is not set +# CONFIG_USB_LED is not set +# CONFIG_USB_CYPRESS_CY7C63 is not set +# CONFIG_USB_CYTHERM is not set +# CONFIG_USB_PHIDGET is not set +# CONFIG_USB_IDMOUSE is not set +# CONFIG_USB_FTDI_ELAN is not set +# CONFIG_USB_APPLEDISPLAY is not set +# CONFIG_USB_LD is not set +# CONFIG_USB_TRANCEVIBRATOR is not set + +# +# USB DSL modem support +# + +# +# USB Gadget Support +# +# CONFIG_USB_GADGET is not set + +# +# MMC/SD Card support +# +# CONFIG_MMC is not set + +# +# LED devices +# +# CONFIG_NEW_LEDS is not set + +# +# LED drivers +# + +# +# LED Triggers +# + +# +# InfiniBand support +# +# CONFIG_INFINIBAND is not set + +# +# EDAC - error detection and reporting (RAS) (EXPERIMENTAL) +# + +# +# Real Time Clock +# +# CONFIG_RTC_CLASS is not set + +# +# DMA Engine support +# +# CONFIG_DMA_ENGINE is not set + +# +# DMA Clients +# + +# +# DMA Devices +# + +# +# File systems +# +CONFIG_EXT2_FS=y +# CONFIG_EXT2_FS_XATTR is not set +# CONFIG_EXT2_FS_XIP is not set +# CONFIG_EXT3_FS is not set +# CONFIG_EXT4DEV_FS is not set +# CONFIG_REISERFS_FS is not set +# CONFIG_JFS_FS is not set +# CONFIG_FS_POSIX_ACL is not set +# CONFIG_XFS_FS is not set +# CONFIG_GFS2_FS is not set +# CONFIG_OCFS2_FS is not set +# CONFIG_MINIX_FS is not set +# CONFIG_ROMFS_FS is not set +CONFIG_INOTIFY=y +CONFIG_INOTIFY_USER=y +# CONFIG_QUOTA is not set +# CONFIG_DNOTIFY is not set +# CONFIG_AUTOFS_FS is not set +# CONFIG_AUTOFS4_FS is not set +# CONFIG_FUSE_FS is not set + +# +# CD-ROM/DVD Filesystems +# +# CONFIG_ISO9660_FS is not set +# CONFIG_UDF_FS is not set + +# +# DOS/FAT/NT Filesystems +# +CONFIG_FAT_FS=y +CONFIG_MSDOS_FS=y +CONFIG_VFAT_FS=y +CONFIG_FAT_DEFAULT_CODEPAGE=437 +CONFIG_FAT_DEFAULT_IOCHARSET="iso8859-1" +# CONFIG_NTFS_FS is not set + +# +# Pseudo filesystems +# +CONFIG_PROC_FS=y +# CONFIG_PROC_KCORE is not set +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 is not set + +# +# Miscellaneous filesystems +# +# CONFIG_ADFS_FS is not set +# CONFIG_AFFS_FS is not set +# CONFIG_HFS_FS is not set +# CONFIG_HFSPLUS_FS is not set +# CONFIG_BEFS_FS is not set +# CONFIG_BFS_FS is not set +# CONFIG_EFS_FS is not set +# CONFIG_CRAMFS is not set +# CONFIG_VXFS_FS is not set +# CONFIG_HPFS_FS is not set +# CONFIG_QNX4FS_FS is not set +# CONFIG_SYSV_FS is not set +# CONFIG_UFS_FS is not set + +# +# Network File Systems +# +CONFIG_NFS_FS=y +CONFIG_NFS_V3=y +# CONFIG_NFS_V3_ACL is not set +# CONFIG_NFS_V4 is not set +# CONFIG_NFS_DIRECTIO is not set +CONFIG_NFSD=m +# CONFIG_NFSD_V3 is not set +# CONFIG_NFSD_TCP is not set +CONFIG_ROOT_NFS=y +CONFIG_LOCKD=y +CONFIG_LOCKD_V4=y +CONFIG_EXPORTFS=m +CONFIG_NFS_COMMON=y +CONFIG_SUNRPC=y +# CONFIG_RPCSEC_GSS_KRB5 is not set +# CONFIG_RPCSEC_GSS_SPKM3 is not set +# CONFIG_SMB_FS is not set +# CONFIG_CIFS is not set +# CONFIG_NCP_FS is not set +# CONFIG_CODA_FS is not set +# CONFIG_AFS_FS is not set +# CONFIG_9P_FS is not set + +# +# Partition Types +# +# CONFIG_PARTITION_ADVANCED is not set +CONFIG_MSDOS_PARTITION=y + +# +# Native Language Support +# +CONFIG_NLS=y +CONFIG_NLS_DEFAULT="iso8859-1" +# CONFIG_NLS_CODEPAGE_437 is not set +# CONFIG_NLS_CODEPAGE_737 is not set +# CONFIG_NLS_CODEPAGE_775 is not set +# CONFIG_NLS_CODEPAGE_850 is not set +# CONFIG_NLS_CODEPAGE_852 is not set +# CONFIG_NLS_CODEPAGE_855 is not set +# CONFIG_NLS_CODEPAGE_857 is not set +# CONFIG_NLS_CODEPAGE_860 is not set +# CONFIG_NLS_CODEPAGE_861 is not set +# CONFIG_NLS_CODEPAGE_862 is not set +# CONFIG_NLS_CODEPAGE_863 is not set +# CONFIG_NLS_CODEPAGE_864 is not set +# CONFIG_NLS_CODEPAGE_865 is not set +# CONFIG_NLS_CODEPAGE_866 is not set +# CONFIG_NLS_CODEPAGE_869 is not set +# CONFIG_NLS_CODEPAGE_936 is not set +# CONFIG_NLS_CODEPAGE_950 is not set +# CONFIG_NLS_CODEPAGE_932 is not set +# CONFIG_NLS_CODEPAGE_949 is not set +# CONFIG_NLS_CODEPAGE_874 is not set +# CONFIG_NLS_ISO8859_8 is not set +# CONFIG_NLS_CODEPAGE_1250 is not set +# CONFIG_NLS_CODEPAGE_1251 is not set +# CONFIG_NLS_ASCII is not set +# CONFIG_NLS_ISO8859_1 is not set +# CONFIG_NLS_ISO8859_2 is not set +# CONFIG_NLS_ISO8859_3 is not set +# CONFIG_NLS_ISO8859_4 is not set +# CONFIG_NLS_ISO8859_5 is not set +# CONFIG_NLS_ISO8859_6 is not set +# CONFIG_NLS_ISO8859_7 is not set +# CONFIG_NLS_ISO8859_9 is not set +# CONFIG_NLS_ISO8859_13 is not set +# CONFIG_NLS_ISO8859_14 is not set +# CONFIG_NLS_ISO8859_15 is not set +# CONFIG_NLS_KOI8_R is not set +# CONFIG_NLS_KOI8_U is not set +# CONFIG_NLS_UTF8 is not set + +# +# Profiling support +# +# CONFIG_PROFILING is not set + +# +# Kernel hacking +# +CONFIG_TRACE_IRQFLAGS_SUPPORT=y +# CONFIG_PRINTK_TIME is not set +CONFIG_ENABLE_MUST_CHECK=y +CONFIG_MAGIC_SYSRQ=y +# CONFIG_UNUSED_SYMBOLS is not set +CONFIG_DEBUG_KERNEL=y +CONFIG_LOG_BUF_SHIFT=14 +CONFIG_DETECT_SOFTLOCKUP=y +# CONFIG_SCHEDSTATS is not set +CONFIG_DEBUG_SLAB=y +# CONFIG_DEBUG_SLAB_LEAK is not set +# CONFIG_DEBUG_RT_MUTEXES is not set +# CONFIG_RT_MUTEX_TESTER is not set +# CONFIG_DEBUG_SPINLOCK is not set +# CONFIG_DEBUG_MUTEXES is not set +# CONFIG_DEBUG_RWSEMS is not set +# CONFIG_DEBUG_LOCK_ALLOC is not set +# CONFIG_PROVE_LOCKING is not set +# CONFIG_DEBUG_SPINLOCK_SLEEP is not set +# CONFIG_DEBUG_LOCKING_API_SELFTESTS is not set +# CONFIG_DEBUG_KOBJECT is not set +# CONFIG_DEBUG_INFO is not set +# CONFIG_DEBUG_FS is not set +# CONFIG_DEBUG_VM is not set +# CONFIG_DEBUG_LIST is not set +CONFIG_FORCED_INLINING=y +CONFIG_HEADERS_CHECK=y +# CONFIG_RCU_TORTURE_TEST is not set +CONFIG_CROSSCOMPILE=y +CONFIG_CMDLINE="console=ttyS1,38400n8 kgdb=ttyS0 root=/dev/nfs ip=bootp" +# CONFIG_DEBUG_STACK_USAGE is not set +# CONFIG_KGDB is not set +# CONFIG_RUNTIME_DEBUG is not set +# CONFIG_MIPS_UNCACHED is not set + +# +# Security options +# +# CONFIG_KEYS is not set +# CONFIG_SECURITY is not set + +# +# Cryptographic options +# +CONFIG_CRYPTO=y +CONFIG_CRYPTO_ALGAPI=m +CONFIG_CRYPTO_BLKCIPHER=m +CONFIG_CRYPTO_MANAGER=m +# CONFIG_CRYPTO_HMAC is not set +# CONFIG_CRYPTO_NULL is not set +# CONFIG_CRYPTO_MD4 is not set +CONFIG_CRYPTO_MD5=m +# CONFIG_CRYPTO_SHA1 is not set +# CONFIG_CRYPTO_SHA256 is not set +# CONFIG_CRYPTO_SHA512 is not set +# CONFIG_CRYPTO_WP512 is not set +# CONFIG_CRYPTO_TGR192 is not set +CONFIG_CRYPTO_ECB=m +CONFIG_CRYPTO_CBC=m +# CONFIG_CRYPTO_DES is not set +# CONFIG_CRYPTO_BLOWFISH is not set +# CONFIG_CRYPTO_TWOFISH is not set +# CONFIG_CRYPTO_SERPENT is not set +# CONFIG_CRYPTO_AES is not set +# CONFIG_CRYPTO_CAST5 is not set +# CONFIG_CRYPTO_CAST6 is not set +# CONFIG_CRYPTO_TEA is not set +# CONFIG_CRYPTO_ARC4 is not set +# CONFIG_CRYPTO_KHAZAD is not set +# CONFIG_CRYPTO_ANUBIS is not set +# CONFIG_CRYPTO_DEFLATE is not set +# CONFIG_CRYPTO_MICHAEL_MIC is not set +CONFIG_CRYPTO_CRC32C=m +# CONFIG_CRYPTO_TEST is not set + +# +# Hardware crypto devices +# + +# +# Library routines +# +CONFIG_CRC_CCITT=m +# CONFIG_CRC16 is not set +CONFIG_CRC32=y +CONFIG_LIBCRC32C=m +CONFIG_PLIST=y Index: linux-mips.git/arch/mips/philips/pnx8550/common/prom.c =================================================================== --- linux-mips.git.orig/arch/mips/philips/pnx8550/common/prom.c 2006-12-08 11:31:42.000000000 +0300 +++ linux-mips.git/arch/mips/philips/pnx8550/common/prom.c 2006-12-08 11:31:44.000000000 +0300 @@ -35,23 +35,15 @@ return &(arcs_cmdline[0]); } -void prom_init_cmdline(void) +void __init prom_init_cmdline(void) { - char *cp; - int actr; - - actr = 1; /* Always ignore argv[0] */ + int i; - cp = &(arcs_cmdline[0]); - while(actr < prom_argc) { - strcpy(cp, prom_argv[actr]); - cp += strlen(prom_argv[actr]); - *cp++ = ' '; - actr++; + arcs_cmdline[0] = '\0'; + for (i = 0; i < prom_argc; i++) { + strcat(arcs_cmdline, prom_argv[i]); + strcat(arcs_cmdline, " "); } - if (cp != &(arcs_cmdline[0])) /* get rid of trailing space */ - --cp; - *cp = '\0'; } char *prom_getenv(char *envname) Index: linux-mips.git/arch/mips/philips/pnx8550/stb810/Makefile =================================================================== --- /dev/null 1970-01-01 00:00:00.000000000 +0000 +++ linux-mips.git/arch/mips/philips/pnx8550/stb810/Makefile 2006-12-08 11:31:44.000000000 +0300 @@ -0,0 +1,4 @@ + +# Makefile for the Philips STB810 Board. + +lib-y := prom_init.o board_setup.o irqmap.o Index: linux-mips.git/arch/mips/philips/pnx8550/stb810/board_setup.c =================================================================== --- /dev/null 1970-01-01 00:00:00.000000000 +0000 +++ linux-mips.git/arch/mips/philips/pnx8550/stb810/board_setup.c 2006-12-08 11:31:44.000000000 +0300 @@ -0,0 +1,49 @@ +/* + * STB810 specific board startup routines. + * + * Based on the arch/mips/philips/pnx8550/jbs/board_setup.c + * + * Author: MontaVista Software, Inc. + * source@mvista.com + * + * Copyright 2005 MontaVista Software Inc. + * + * 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. + */ + +#include +#include +#include +#include +#include +#include +#include + +#include +#include +#include +#include +#include +#include + +#include + +void __init board_setup(void) +{ + unsigned long config0, configpr; + + config0 = read_c0_config(); + + /* clear all three cache coherency fields */ + config0 &= ~(0x7 | (7<<25) | (7<<28)); + config0 |= (CONF_CM_DEFAULT | (CONF_CM_DEFAULT<<25) | + (CONF_CM_DEFAULT<<28)); + write_c0_config(config0); + + configpr = read_c0_config7(); + configpr |= (1<<19); /* enable tlb */ + write_c0_config7(configpr); +} Index: linux-mips.git/arch/mips/philips/pnx8550/stb810/irqmap.c =================================================================== --- /dev/null 1970-01-01 00:00:00.000000000 +0000 +++ linux-mips.git/arch/mips/philips/pnx8550/stb810/irqmap.c 2006-12-08 11:31:44.000000000 +0300 @@ -0,0 +1,23 @@ +/* + * Philips STB810 board irqmap. + * + * Author: MontaVista Software, Inc. + * source@mvista.com + * + * Copyright 2005 MontaVista Software Inc. + * + * 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. + */ + +#include +#include + +char pnx8550_irq_tab[][5] __initdata = { + [8] = { -1, PNX8550_INT_PCI_INTA, 0xff, 0xff, 0xff}, + [9] = { -1, PNX8550_INT_PCI_INTA, 0xff, 0xff, 0xff}, + [10] = { -1, PNX8550_INT_PCI_INTA, 0xff, 0xff, 0xff}, +}; + Index: linux-mips.git/arch/mips/philips/pnx8550/stb810/prom_init.c =================================================================== --- /dev/null 1970-01-01 00:00:00.000000000 +0000 +++ linux-mips.git/arch/mips/philips/pnx8550/stb810/prom_init.c 2006-12-08 11:31:44.000000000 +0300 @@ -0,0 +1,49 @@ +/* + * STB810 specific prom routines + * + * Author: MontaVista Software, Inc. + * source@mvista.com + * + * Copyright 2005 MontaVista Software Inc. + * + * 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. + */ + +#include +#include +#include +#include +#include +#include +#include +#include + +int prom_argc; +char **prom_argv, **prom_envp; +extern void __init prom_init_cmdline(void); +extern char *prom_getenv(char *envname); + +const char *get_system_type(void) +{ + return "Philips PNX8550/STB810"; +} + +void __init prom_init(void) +{ + + unsigned long memsize; + prom_argc = (int) fw_arg0; + prom_argv = (char **) fw_arg1; + prom_envp = (char **) fw_arg2; + + prom_init_cmdline(); + + mips_machgroup = MACH_GROUP_PHILIPS; + mips_machtype = MACH_PHILIPS_STB810; + + memsize = 0x08000000; /* Trimedia uses memory above */ + add_memory_region(0, memsize, BOOT_MEM_RAM); +} Index: linux-mips.git/include/asm-mips/bootinfo.h =================================================================== --- linux-mips.git.orig/include/asm-mips/bootinfo.h 2006-12-08 11:31:42.000000000 +0300 +++ linux-mips.git/include/asm-mips/bootinfo.h 2006-12-08 11:31:44.000000000 +0300 @@ -131,6 +131,7 @@ #define MACH_PHILIPS_NINO 0 /* Nino */ #define MACH_PHILIPS_VELO 1 /* Velo */ #define MACH_PHILIPS_JBS 2 /* JBS */ +#define MACH_PHILIPS_STB810 3 /* STB810 */ /* * Valid machtype for group SIBYTE Index: linux-mips.git/arch/mips/pci/fixup-pnx8550.c =================================================================== --- linux-mips.git.orig/arch/mips/pci/fixup-pnx8550.c 2006-12-07 18:11:13.000000000 +0300 +++ linux-mips.git/arch/mips/pci/fixup-pnx8550.c 2006-12-08 11:31:44.000000000 +0300 @@ -33,7 +33,7 @@ #define DBG(x...) #endif -extern char irq_tab_jbs[][5]; +extern char pnx8550_irq_tab[][5]; void __init pcibios_fixup_resources(struct pci_dev *dev) { @@ -47,7 +47,7 @@ int __init pcibios_map_irq(struct pci_dev *dev, u8 slot, u8 pin) { - return irq_tab_jbs[slot][pin]; + return pnx8550_irq_tab[slot][pin]; } /* Do platform specific device initialization at pci_enable_device() time */ Index: linux-mips.git/arch/mips/philips/pnx8550/jbs/irqmap.c =================================================================== --- linux-mips.git.orig/arch/mips/philips/pnx8550/jbs/irqmap.c 2006-12-07 18:11:14.000000000 +0300 +++ linux-mips.git/arch/mips/philips/pnx8550/jbs/irqmap.c 2006-12-08 11:31:44.000000000 +0300 @@ -28,9 +28,9 @@ #include #include -char irq_tab_jbs[][5] __initdata = { - [8] = { -1, PNX8550_INT_PCI_INTA, 0xff, 0xff, 0xff}, - [9] = { -1, PNX8550_INT_PCI_INTA, 0xff, 0xff, 0xff}, - [17] = { -1, PNX8550_INT_PCI_INTA, 0xff, 0xff, 0xff}, +char pnx8550_irq_tab[][5] __initdata = { + [8] = { -1, PNX8550_INT_PCI_INTA, 0xff, 0xff, 0xff}, + [9] = { -1, PNX8550_INT_PCI_INTA, 0xff, 0xff, 0xff}, + [17] = { -1, PNX8550_INT_PCI_INTA, 0xff, 0xff, 0xff}, }; From sshtylyov@ru.mvista.com Fri Dec 8 12:57:55 2006 Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 08 Dec 2006 12:57:59 +0000 (GMT) Received: from h155.mvista.com ([63.81.120.155]:62631 "EHLO imap.sh.mvista.com") by ftp.linux-mips.org with ESMTP id S20037578AbWLHM5z (ORCPT ); Fri, 8 Dec 2006 12:57:55 +0000 Received: from [192.168.1.248] (unknown [10.150.0.9]) by imap.sh.mvista.com (Postfix) with ESMTP id 28A4F3EC9; Fri, 8 Dec 2006 04:57:32 -0800 (PST) Message-ID: <4579619D.1080903@ru.mvista.com> Date: Fri, 08 Dec 2006 15:59:09 +0300 From: Sergei Shtylyov Organization: MontaVista Software Inc. User-Agent: Mozilla/5.0 (X11; U; Linux i686; rv:1.7.2) Gecko/20040803 X-Accept-Language: ru, en-us, en-gb MIME-Version: 1.0 To: ashlesha@kenati.com Cc: Atsushi Nemoto , linux-mips@linux-mips.org Subject: Re: Serial 8250 driver registration: References: <1165462754.6516.40.camel@sandbar.kenati.com> <20061207.131306.63741931.nemoto@toshiba-tops.co.jp> <1165534711.6512.10.camel@sandbar.kenati.com> <20061208.101112.108306293.nemoto@toshiba-tops.co.jp> <1165543305.6512.17.camel@sandbar.kenati.com> In-Reply-To: <1165543305.6512.17.camel@sandbar.kenati.com> Content-Type: text/plain; charset=us-ascii; 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: 13412 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: sshtylyov@ru.mvista.com Precedence: bulk X-list: linux-mips Hello. Ashlesha Shintre wrote: > Yeah, i thought you might have meant that :-) > i m starting to think that the uartclk parameter that i pass to the > platform_add_devices function might be wrong -- > i m passing the standard value of 1843200 for a baudrate of 115200... Since it's a standard x86 UART built into the x86 south bridge, it should be clocked by the standard 1.8432 MHz clock. WBR, Sergei From ralf@linux-mips.org Fri Dec 8 13:05:45 2006 Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 08 Dec 2006 13:05:46 +0000 (GMT) Received: from localhost.localdomain ([127.0.0.1]:2275 "EHLO dl5rb.ham-radio-op.net") by ftp.linux-mips.org with ESMTP id S20037591AbWLHNFp (ORCPT ); Fri, 8 Dec 2006 13:05:45 +0000 Received: from denk.linux-mips.net (denk.linux-mips.net [127.0.0.1]) by dl5rb.ham-radio-op.net (8.13.8/8.13.8) with ESMTP id kB8D5i0Y006929; Fri, 8 Dec 2006 13:05:44 GMT Received: (from ralf@localhost) by denk.linux-mips.net (8.13.8/8.13.8/Submit) id kB8D5htA006928; Fri, 8 Dec 2006 13:05:43 GMT Date: Fri, 8 Dec 2006 13:05:43 +0000 From: Ralf Baechle To: Vitaly Wool Cc: linux-mips@linux-mips.org Subject: Re: [PATCH][respin] add STB810 support (Philips PNX8550-based) Message-ID: <20061208130543.GB5797@linux-mips.org> References: <20061208114035.000049c4.vitalywool@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20061208114035.000049c4.vitalywool@gmail.com> User-Agent: Mutt/1.4.2.2i 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: 13413 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 Fri, Dec 08, 2006 at 11:40:35AM +0300, Vitaly Wool wrote: > please find the updated patch that adds support for STB810 below. Ok, I applied the unARMed version of the patch :-) Thanks Vitaly, Ralf From ralf@linux-mips.org Fri Dec 8 13:08:06 2006 Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 08 Dec 2006 13:08:08 +0000 (GMT) Received: from localhost.localdomain ([127.0.0.1]:2945 "EHLO dl5rb.ham-radio-op.net") by ftp.linux-mips.org with ESMTP id S20037768AbWLHNIG (ORCPT ); Fri, 8 Dec 2006 13:08:06 +0000 Received: from denk.linux-mips.net (denk.linux-mips.net [127.0.0.1]) by dl5rb.ham-radio-op.net (8.13.8/8.13.8) with ESMTP id kB8D86dl007582; Fri, 8 Dec 2006 13:08:06 GMT Received: (from ralf@localhost) by denk.linux-mips.net (8.13.8/8.13.8/Submit) id kB8D86Tu007581; Fri, 8 Dec 2006 13:08:06 GMT Date: Fri, 8 Dec 2006 13:08:06 +0000 From: Ralf Baechle To: Vitaly Wool Cc: linux-mips@linux-mips.org Subject: Re: [PATCH][respin] add STB810 support (Philips PNX8550-based) Message-ID: <20061208130806.GA7439@linux-mips.org> References: <20061208114035.000049c4.vitalywool@gmail.com> <20061208130543.GB5797@linux-mips.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20061208130543.GB5797@linux-mips.org> User-Agent: Mutt/1.4.2.2i 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: 13414 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 Fri, Dec 08, 2006 at 01:05:43PM +0000, Ralf Baechle wrote: Hmmm... CC arch/mips/philips/pnx8550/common/setup.o arch/mips/philips/pnx8550/common/setup.c:27:34: error: linux/serial_pnx8xxx.h: No such file or directory arch/mips/philips/pnx8550/common/setup.c: In function 'plat_mem_setup': arch/mips/philips/pnx8550/common/setup.c:147: error: 'PNX8XXX_UART_LCR_8BIT' undeclared (first use in this function) arch/mips/philips/pnx8550/common/setup.c:147: error: (Each undeclared identifier is reported only once arch/mips/philips/pnx8550/common/setup.c:147: error: for each function it appears in.) make[1]: *** [arch/mips/philips/pnx8550/common/setup.o] Error 1 make: *** [arch/mips/philips/pnx8550/common] Error 2 Ralf From sshtylyov@ru.mvista.com Fri Dec 8 13:17:56 2006 Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 08 Dec 2006 13:18:00 +0000 (GMT) Received: from h155.mvista.com ([63.81.120.155]:16552 "EHLO imap.sh.mvista.com") by ftp.linux-mips.org with ESMTP id S20037767AbWLHNR4 (ORCPT ); Fri, 8 Dec 2006 13:17:56 +0000 Received: from [192.168.1.248] (unknown [10.150.0.9]) by imap.sh.mvista.com (Postfix) with ESMTP id 8DF553EC9; Fri, 8 Dec 2006 05:17:52 -0800 (PST) Message-ID: <45796661.7070600@ru.mvista.com> Date: Fri, 08 Dec 2006 16:19:29 +0300 From: Sergei Shtylyov Organization: MontaVista Software Inc. User-Agent: Mozilla/5.0 (X11; U; Linux i686; rv:1.7.2) Gecko/20040803 X-Accept-Language: ru, en-us, en-gb MIME-Version: 1.0 To: Vitaly Wool Cc: ralf@linux-mips.org, linux-mips@linux-mips.org Subject: Re: [PATCH][respin] add STB810 support (Philips PNX8550-based) References: <20061208114035.000049c4.vitalywool@gmail.com> In-Reply-To: <20061208114035.000049c4.vitalywool@gmail.com> Content-Type: text/plain; charset=us-ascii; 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: 13415 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: sshtylyov@ru.mvista.com Precedence: bulk X-list: linux-mips Hello. Vitaly Wool wrote: > please find the updated patch that adds support for STB810 below. [...] > Signed-off-by: Vitaly Wool > Index: linux-mips.git/arch/mips/configs/pnx8550-stb810_defconfig > =================================================================== > --- /dev/null 1970-01-01 00:00:00.000000000 +0000 > +++ linux-mips.git/arch/mips/configs/pnx8550-stb810_defconfig 2006-12-08 11:31:44.000000000 +0300 > +CONFIG_BLK_DEV_HPT366=y Oh? Definitely not a good driver support choice for embedded targets... Does STB810 have is on board? > +# CONFIG_BLK_DEV_HD is not set > + > +# > +# SCSI device support > +# > +# CONFIG_RAID_ATTRS is not set > +CONFIG_SCSI=y > +# CONFIG_SCSI_NETLINK is not set > +CONFIG_SCSI_PROC_FS=y > + > +# > +# SCSI support type (disk, tape, CD-ROM) > +# > +CONFIG_BLK_DEV_SD=y Do we really need SCSI *disk* support? > +# > +# Some SCSI devices (e.g. CD jukebox) support multiple LUNs > +# > +# CONFIG_SCSI_MULTI_LUN is not set > +CONFIG_SCSI_CONSTANTS=y > +# CONFIG_SCSI_LOGGING is not set > + > +# > +# SCSI Transports > +# > +# CONFIG_SCSI_SPI_ATTRS is not set > +# CONFIG_SCSI_FC_ATTRS is not set > +CONFIG_SCSI_ISCSI_ATTRS=m > +# CONFIG_SCSI_SAS_ATTRS is not set > +# CONFIG_SCSI_SAS_LIBSAS is not set > + > +# > +# SCSI low-level drivers > +# > +CONFIG_ISCSI_TCP=m I doubt this kernel needs iSCSI crap even as modules... > +# > +# Watchdog Cards > +# > +# CONFIG_WATCHDOG is not set > +CONFIG_HW_RANDOM=y Oh? > +# > +# Hardware Monitoring support > +# > +CONFIG_HWMON=y Oh really? > +# may also be needed; see USB_STORAGE Help for more information > +# > +CONFIG_USB_STORAGE=y > +# 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 Hm, do we really need to support all these? > +CONFIG_EXT2_FS=y > +# CONFIG_EXT2_FS_XATTR is not set > +# CONFIG_EXT2_FS_XIP is not set > +# CONFIG_EXT3_FS is not set > +# CONFIG_EXT4DEV_FS is not set > +# CONFIG_REISERFS_FS is not set > +# CONFIG_JFS_FS is not set > +# CONFIG_FS_POSIX_ACL is not set > +# CONFIG_XFS_FS is not set > +# CONFIG_GFS2_FS is not set > +# CONFIG_OCFS2_FS is not set > +# CONFIG_MINIX_FS is not set > +# CONFIG_ROMFS_FS is not set > +CONFIG_INOTIFY=y > +CONFIG_INOTIFY_USER=y > +# CONFIG_QUOTA is not set > +# CONFIG_DNOTIFY is not set > +# CONFIG_AUTOFS_FS is not set > +# CONFIG_AUTOFS4_FS is not set > +# CONFIG_FUSE_FS is not set > + > +# > +# CD-ROM/DVD Filesystems > +# > +# CONFIG_ISO9660_FS is not set > +# CONFIG_UDF_FS is not set > + > +# > +# DOS/FAT/NT Filesystems > +# > +CONFIG_FAT_FS=y > +CONFIG_MSDOS_FS=y > +CONFIG_VFAT_FS=y > +CONFIG_FAT_DEFAULT_CODEPAGE=437 > +CONFIG_FAT_DEFAULT_IOCHARSET="iso8859-1" > +# CONFIG_NTFS_FS is not set > + > +# > +# Pseudo filesystems > +# > +CONFIG_PROC_FS=y > +# CONFIG_PROC_KCORE is not set > +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 is not set > + > +# > +# Miscellaneous filesystems > +# > +# CONFIG_ADFS_FS is not set > +# CONFIG_AFFS_FS is not set > +# CONFIG_HFS_FS is not set > +# CONFIG_HFSPLUS_FS is not set > +# CONFIG_BEFS_FS is not set > +# CONFIG_BFS_FS is not set > +# CONFIG_EFS_FS is not set > +# CONFIG_CRAMFS is not set > +# CONFIG_VXFS_FS is not set > +# CONFIG_HPFS_FS is not set > +# CONFIG_QNX4FS_FS is not set > +# CONFIG_SYSV_FS is not set > +# CONFIG_UFS_FS is not set > + > +# > +# Network File Systems > +# > +CONFIG_NFS_FS=y > +CONFIG_NFS_V3=y > +# CONFIG_NFS_V3_ACL is not set > +# CONFIG_NFS_V4 is not set > +# CONFIG_NFS_DIRECTIO is not set > +CONFIG_NFSD=m > +# CONFIG_NFSD_V3 is not set > +# CONFIG_NFSD_TCP is not set > +CONFIG_ROOT_NFS=y > +CONFIG_LOCKD=y > +CONFIG_LOCKD_V4=y > +CONFIG_EXPORTFS=m > +CONFIG_NFS_COMMON=y > +CONFIG_SUNRPC=y > +# CONFIG_RPCSEC_GSS_KRB5 is not set > +# CONFIG_RPCSEC_GSS_SPKM3 is not set > +# CONFIG_SMB_FS is not set > +# CONFIG_CIFS is not set > +# CONFIG_NCP_FS is not set > +# CONFIG_CODA_FS is not set > +# CONFIG_AFS_FS is not set > +# CONFIG_9P_FS is not set > + > +# > +# Partition Types > +# > +# CONFIG_PARTITION_ADVANCED is not set > +CONFIG_MSDOS_PARTITION=y I doubt this kernel needs iSCSI crap even as modules but well... WBR, Sergei From sshtylyov@ru.mvista.com Fri Dec 8 13:19:42 2006 Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 08 Dec 2006 13:19:47 +0000 (GMT) Received: from h155.mvista.com ([63.81.120.155]:19112 "EHLO imap.sh.mvista.com") by ftp.linux-mips.org with ESMTP id S20037767AbWLHNTm (ORCPT ); Fri, 8 Dec 2006 13:19:42 +0000 Received: from [192.168.1.248] (unknown [10.150.0.9]) by imap.sh.mvista.com (Postfix) with ESMTP id 80B243EC9; Fri, 8 Dec 2006 05:19:39 -0800 (PST) Message-ID: <457966C9.8000801@ru.mvista.com> Date: Fri, 08 Dec 2006 16:21:13 +0300 From: Sergei Shtylyov Organization: MontaVista Software Inc. User-Agent: Mozilla/5.0 (X11; U; Linux i686; rv:1.7.2) Gecko/20040803 X-Accept-Language: ru, en-us, en-gb MIME-Version: 1.0 To: Ralf Baechle Cc: Vitaly Wool , linux-mips@linux-mips.org Subject: Re: [PATCH][respin] add STB810 support (Philips PNX8550-based) References: <20061208114035.000049c4.vitalywool@gmail.com> <20061208130543.GB5797@linux-mips.org> <20061208130806.GA7439@linux-mips.org> In-Reply-To: <20061208130806.GA7439@linux-mips.org> Content-Type: text/plain; charset=us-ascii; 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: 13416 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: sshtylyov@ru.mvista.com Precedence: bulk X-list: linux-mips Hello. Ralf Baechle wrote: > On Fri, Dec 08, 2006 at 01:05:43PM +0000, Ralf Baechle wrote: > Hmmm... > CC arch/mips/philips/pnx8550/common/setup.o > arch/mips/philips/pnx8550/common/setup.c:27:34: error: linux/serial_pnx8xxx.h: No such file or directory > arch/mips/philips/pnx8550/common/setup.c: In function 'plat_mem_setup': > arch/mips/philips/pnx8550/common/setup.c:147: error: 'PNX8XXX_UART_LCR_8BIT' undeclared (first use in this function) > arch/mips/philips/pnx8550/common/setup.c:147: error: (Each undeclared identifier is reported only once > arch/mips/philips/pnx8550/common/setup.c:147: error: for each function it appears in.) > make[1]: *** [arch/mips/philips/pnx8550/common/setup.o] Error 1 > make: *** [arch/mips/philips/pnx8550/common] Error 2 PNX8xxx UART driver still not accepted it seems, thanks to RMK's step out from the serial core maintenance... WBR, Sergei From sshtylyov@ru.mvista.com Fri Dec 8 13:25:30 2006 Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 08 Dec 2006 13:25:35 +0000 (GMT) Received: from h155.mvista.com ([63.81.120.155]:27304 "EHLO imap.sh.mvista.com") by ftp.linux-mips.org with ESMTP id S20038415AbWLHNZa (ORCPT ); Fri, 8 Dec 2006 13:25:30 +0000 Received: from [192.168.1.248] (unknown [10.150.0.9]) by imap.sh.mvista.com (Postfix) with ESMTP id 615113EC9; Fri, 8 Dec 2006 05:25:26 -0800 (PST) Message-ID: <45796826.4060209@ru.mvista.com> Date: Fri, 08 Dec 2006 16:27:02 +0300 From: Sergei Shtylyov Organization: MontaVista Software Inc. User-Agent: Mozilla/5.0 (X11; U; Linux i686; rv:1.7.2) Gecko/20040803 X-Accept-Language: ru, en-us, en-gb MIME-Version: 1.0 To: Vitaly Wool Cc: ralf@linux-mips.org, linux-mips@linux-mips.org Subject: Re: [PATCH][respin] add STB810 support (Philips PNX8550-based) References: <20061208114035.000049c4.vitalywool@gmail.com> <45796661.7070600@ru.mvista.com> In-Reply-To: <45796661.7070600@ru.mvista.com> Content-Type: text/plain; charset=us-ascii; 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: 13417 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: sshtylyov@ru.mvista.com Precedence: bulk X-list: linux-mips Hello, I wrote: >> +# >> +# Partition Types >> +# >> +# CONFIG_PARTITION_ADVANCED is not set >> +CONFIG_MSDOS_PARTITION=y > I doubt this kernel needs iSCSI crap even as modules but well... Oh, sorry, cut-n-paste issue. I meant to also complain about [V]FAT support in-kernel... WBR, Sergei From vitalywool@gmail.com Fri Dec 8 13:49:05 2006 Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 08 Dec 2006 13:49:10 +0000 (GMT) Received: from nf-out-0910.google.com ([64.233.182.189]:27740 "EHLO nf-out-0910.google.com") by ftp.linux-mips.org with ESMTP id S20037767AbWLHNtF (ORCPT ); Fri, 8 Dec 2006 13:49:05 +0000 Received: by nf-out-0910.google.com with SMTP id l24so1083020nfc for ; Fri, 08 Dec 2006 05:49:05 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=EnF16Gvam6YiVWMN6rGcqgwUc0psRjKWoNit6H/5RE/0f+RRrLwsVxjXZW2NV0WKLEWzkABsipjcxJ9PN87tzsNH+dT3Ly6T3rNSbJKaSBl/4pBQi/HbYzaMxscEPIpLAfwn7O3MOMXCcFQztULeZZ444xnGV7suNVqU1quwkQA= Received: by 10.82.123.16 with SMTP id v16mr309544buc.1165585744753; Fri, 08 Dec 2006 05:49:04 -0800 (PST) Received: by 10.82.108.6 with HTTP; Fri, 8 Dec 2006 05:49:04 -0800 (PST) Message-ID: Date: Fri, 8 Dec 2006 16:49:04 +0300 From: "Vitaly Wool" To: "Ralf Baechle" Subject: Re: [PATCH][respin] add STB810 support (Philips PNX8550-based) Cc: linux-mips@linux-mips.org In-Reply-To: <20061208130806.GA7439@linux-mips.org> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <20061208114035.000049c4.vitalywool@gmail.com> <20061208130543.GB5797@linux-mips.org> <20061208130806.GA7439@linux-mips.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: 13418 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: vitalywool@gmail.com Precedence: bulk X-list: linux-mips On 12/8/06, Ralf Baechle wrote: > On Fri, Dec 08, 2006 at 01:05:43PM +0000, Ralf Baechle wrote: > > Hmmm... > > CC arch/mips/philips/pnx8550/common/setup.o > arch/mips/philips/pnx8550/common/setup.c:27:34: error: > linux/serial_pnx8xxx.h: No such file or directory > arch/mips/philips/pnx8550/common/setup.c: In function 'plat_mem_setup': > arch/mips/philips/pnx8550/common/setup.c:147: error: 'PNX8XXX_UART_LCR_8BIT' > undeclared (first use in this function) > arch/mips/philips/pnx8550/common/setup.c:147: error: (Each undeclared > identifier is reported only once > arch/mips/philips/pnx8550/common/setup.c:147: error: for each function it > appears in.) > make[1]: *** [arch/mips/philips/pnx8550/common/setup.o] Error 1 > make: *** [arch/mips/philips/pnx8550/common] Error 2 That's due to my serial rework for 8550 still being ignored, even though it has been accepted basically by rmk just before he quitted mainstaining serial stuff . The latest repost was yesterday: http://lkml.org/lkml/2006/12/7/147. I don't know what else to do to make it seen by anyone :( Vitaly From ashlesha@kenati.com Sat Dec 9 02:09:34 2006 Received: with ECARTIS (v1.0.0; list linux-mips); Sat, 09 Dec 2006 02:09:39 +0000 (GMT) Received: from [69.90.147.196] ([69.90.147.196]:59296 "EHLO mail.kenati.com") by ftp.linux-mips.org with ESMTP id S20038913AbWLICJe (ORCPT ); Sat, 9 Dec 2006 02:09:34 +0000 Received: from [192.168.1.169] (adsl-71-130-109-177.dsl.snfc21.pacbell.net [71.130.109.177]) by mail.kenati.com (Postfix) with ESMTP id E2FEE15D4005; Fri, 8 Dec 2006 19:39:49 -0800 (PST) Subject: console stuck From: Ashlesha Shintre Reply-To: ashlesha@kenati.com To: Sergei Shtylyov , Atsushi Nemoto , linux-mips@linux-mips.org Content-Type: text/plain Date: Fri, 08 Dec 2006 18:22:20 -0800 Message-Id: <1165630940.7860.7.camel@sandbar.kenati.com> Mime-Version: 1.0 X-Mailer: Evolution 2.4.2.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: 13419 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: ashlesha@kenati.com Precedence: bulk X-list: linux-mips Hi, I m very much confused as to why there is an infinite loop in the __request_resource function in the linux/kernel/resource.c file? The serial console is getting stuck at this point. > for (;;) { > tmp = *p; > if (!tmp || tmp->start > end) { > new->sibling = tmp; > *p = new; > new->parent = root; > return NULL; > } > p = &tmp->sibling; > if (tmp->end < start){ > printk("tmp->end = %d\n",tmp->end); > printk("tmp->start = %d\n",tmp->start); > printk("*********!!!!!!!*******sibling?!!\n"); > continue; > } > return tmp; Thanks and Regards, Ashlesha. From sshtylyov@ru.mvista.com Sat Dec 9 16:54:20 2006 Received: with ECARTIS (v1.0.0; list linux-mips); Sat, 09 Dec 2006 16:54:24 +0000 (GMT) Received: from h155.mvista.com ([63.81.120.155]:957 "EHLO imap.sh.mvista.com") by ftp.linux-mips.org with ESMTP id S20037789AbWLIQyU (ORCPT ); Sat, 9 Dec 2006 16:54:20 +0000 Received: from [192.168.1.248] (unknown [10.150.0.9]) by imap.sh.mvista.com (Postfix) with ESMTP id 7F7693ECA; Sat, 9 Dec 2006 08:54:03 -0800 (PST) Message-ID: <457AEA8B.9030605@ru.mvista.com> Date: Sat, 09 Dec 2006 19:55:39 +0300 From: Sergei Shtylyov Organization: MontaVista Software Inc. User-Agent: Mozilla/5.0 (X11; U; Linux i686; rv:1.7.2) Gecko/20040803 X-Accept-Language: ru, en-us, en-gb MIME-Version: 1.0 To: ashlesha@kenati.com Cc: Atsushi Nemoto , linux-mips@linux-mips.org Subject: Re: console stuck References: <1165630940.7860.7.camel@sandbar.kenati.com> In-Reply-To: <1165630940.7860.7.camel@sandbar.kenati.com> Content-Type: text/plain; charset=us-ascii; 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: 13420 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: sshtylyov@ru.mvista.com Precedence: bulk X-list: linux-mips Hello. Ashlesha Shintre wrote: > Hi, > I m very much confused as to why there is an infinite loop in the > __request_resource function in the linux/kernel/resource.c file? It has 2 exit points (return statements). > The serial console is getting stuck at this point. Then there's something very wrong with your resources... >>for (;;) { >> tmp = *p; >> if (!tmp || tmp->start > end) { >> new->sibling = tmp; >> *p = new; >> new->parent = root; >> return NULL; >> } >> p = &tmp->sibling; >> if (tmp->end < start){ >> printk("tmp->end = %d\n",tmp->end); >> printk("tmp->start = %d\n",tmp->start); >> printk("*********!!!!!!!*******sibling?!!\n"); >> continue; >> } >> return tmp; > > > Thanks and Regards, > Ashlesha. WBR, Sergei From ashlesha@kenati.com Sat Dec 9 23:56:49 2006 Received: with ECARTIS (v1.0.0; list linux-mips); Sat, 09 Dec 2006 23:56:55 +0000 (GMT) Received: from [69.90.147.196] ([69.90.147.196]:53176 "EHLO mail.kenati.com") by ftp.linux-mips.org with ESMTP id S20039157AbWLIX4t (ORCPT ); Sat, 9 Dec 2006 23:56:49 +0000 Received: from [192.168.1.169] (adsl-71-130-109-177.dsl.snfc21.pacbell.net [71.130.109.177]) by mail.kenati.com (Postfix) with ESMTP id E413EE404D; Sat, 9 Dec 2006 17:22:54 -0800 (PST) Subject: Re: console stuck From: Ashlesha Shintre Reply-To: ashlesha@kenati.com To: Sergei Shtylyov Cc: Atsushi Nemoto , linux-mips@linux-mips.org In-Reply-To: <457AEA8B.9030605@ru.mvista.com> References: <1165630940.7860.7.camel@sandbar.kenati.com> <457AEA8B.9030605@ru.mvista.com> Content-Type: text/plain Date: Sat, 09 Dec 2006 16:09:41 -0800 Message-Id: <1165709381.6518.13.camel@sandbar.kenati.com> Mime-Version: 1.0 X-Mailer: Evolution 2.4.2.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: 13421 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: ashlesha@kenati.com Precedence: bulk X-list: linux-mips Another basic query: I m pretty sure I cant see my user space messages on the console due to the fact that the ttyS0 device is not registered -- The board specific platform_init function that I wrote returns non-error values and executes fine! -- Also, I figured that the ttyS0 uart regsitration is a separate process that runs independently of the above arch_initcall -- It is spawned from the serial8250_register_ports function which is part of the __init routines -- The "name" of the uart driver in this case is "serial" and is the struct uart_driver serial8250_reg defined in the drivers/serial/8250.c file and not "serial8250" which is the name of the struct device_driver serial8250_isa_driver -- how are these two processes -- the arch_initcall encm3_platform_init function and the __init serial8250_register_ports function related? and how come they use separate drivers? Thank you, Ashlesha. On Sat, 2006-12-09 at 19:55 +0300, Sergei Shtylyov wrote: > Hello. > > Ashlesha Shintre wrote: > > Hi, > > > I m very much confused as to why there is an infinite loop in the > > __request_resource function in the linux/kernel/resource.c file? > > It has 2 exit points (return statements). > > > The serial console is getting stuck at this point. > > Then there's something very wrong with your resources... > > >>for (;;) { > >> tmp = *p; > >> if (!tmp || tmp->start > end) { > >> new->sibling = tmp; > >> *p = new; > >> new->parent = root; > >> return NULL; > >> } > >> p = &tmp->sibling; > >> if (tmp->end < start){ > >> printk("tmp->end = %d\n",tmp->end); > >> printk("tmp->start = %d\n",tmp->start); > >> printk("*********!!!!!!!*******sibling?!!\n"); > >> continue; > >> } > >> return tmp; > > > > > > Thanks and Regards, > > Ashlesha. > > WBR, Sergei > From anemo@mba.ocn.ne.jp Sun Dec 10 16:16:53 2006 Received: with ECARTIS (v1.0.0; list linux-mips); Sun, 10 Dec 2006 16:16:59 +0000 (GMT) Received: from mba.ocn.ne.jp ([210.190.142.172]:32482 "HELO smtp.mba.ocn.ne.jp") by ftp.linux-mips.org with SMTP id S20039260AbWLJQQx (ORCPT ); Sun, 10 Dec 2006 16:16:53 +0000 Received: from localhost (p1056-ipad26funabasi.chiba.ocn.ne.jp [220.104.87.56]) by smtp.mba.ocn.ne.jp (Postfix) with ESMTP id 6E218B62E; Mon, 11 Dec 2006 01:16:47 +0900 (JST) Date: Mon, 11 Dec 2006 01:16:47 +0900 (JST) Message-Id: <20061211.011647.41196525.anemo@mba.ocn.ne.jp> To: linux-mips@linux-mips.org Cc: ralf@linux-mips.org Subject: [PATCH] Fix negative buffer overflow in copy_from_user From: Atsushi Nemoto 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 3.3 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: 13422 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 If we passed an invalid _and_ unaligned source address to copy_from_user(), the fault handling code miscalculates a length of uncopied bytes and returns a value greater than original length. This also causes an negative buffer overflow and overwrites some bytes just before the destination kernel buffer. This can happen "src_unaligned" case in memcpy.S. If the first load from source buffer was a LDFIRST/LDREST (L[WD][RL]) instruction, it raise an exception and the THREAD_BUADDR will be an aligned address so it will _smaller_ than its real target address. For all case "src" register is smaller than its target load address (ie. the offset of load instruction is always greater then zero), and on the first load instruction "src" is always start of uncopied source buffer, so we can fix the faulted address using the "src" value. Signed-off-by: Atsushi Nemoto --- diff --git a/arch/mips/lib/memcpy.S b/arch/mips/lib/memcpy.S index a526c62..7b21bc9 100644 --- a/arch/mips/lib/memcpy.S +++ b/arch/mips/lib/memcpy.S @@ -434,6 +434,12 @@ l_exc: nop LOAD t0, THREAD_BUADDR(t0) # t0 is just past last good address nop + /* If src was unaligned, t0 might be _smaller_ then src. Fix it. */ + slt t1, t0, src + beqz t1, 1f + nop + move t0, src +1: SUB len, AT, t0 # len number of uncopied bytes /* * Here's where we rely on src and dst being incremented in tandem, From ralf@linux-mips.org Sun Dec 10 19:41:49 2006 Received: with ECARTIS (v1.0.0; list linux-mips); Sun, 10 Dec 2006 19:41:51 +0000 (GMT) Received: from localhost.localdomain ([127.0.0.1]:15267 "EHLO dl5rb.ham-radio-op.net") by ftp.linux-mips.org with ESMTP id S20039327AbWLJTlt (ORCPT ); Sun, 10 Dec 2006 19:41:49 +0000 Received: from denk.linux-mips.net (denk.linux-mips.net [127.0.0.1]) by dl5rb.ham-radio-op.net (8.13.8/8.13.8) with ESMTP id kBAJfkrW000535; Sun, 10 Dec 2006 19:41:47 GMT Received: (from ralf@localhost) by denk.linux-mips.net (8.13.8/8.13.8/Submit) id kBAJfiHj000534; Sun, 10 Dec 2006 19:41:44 GMT Date: Sun, 10 Dec 2006 19:41:44 +0000 From: Ralf Baechle To: Andrew Morton , linux-kernel@vger.kernel.org, linux-mips@linux-mips.org, mchehab@infradead.org, luca.risolia@studio.unibo.it Subject: [PATCH] Fix namespace conflict between w9968cf.c on MIPS Message-ID: <20061210194144.GA423@linux-mips.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.2i 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: 13423 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 Both use __SC. Since __* is sort of private namespace I've choosen to fix this in the driver. For consistency I decieded to also change __UNSC to UNSC. Signed-off-by: Ralf Baechle diff --git a/drivers/media/video/w9968cf.c b/drivers/media/video/w9968cf.c index ddce2fb..9f403af 100644 --- a/drivers/media/video/w9968cf.c +++ b/drivers/media/video/w9968cf.c @@ -1827,8 +1827,8 @@ w9968cf_set_window(struct w9968cf_device int err = 0; /* Work around to avoid FP arithmetics */ - #define __SC(x) ((x) << 10) - #define __UNSC(x) ((x) >> 10) + #define SC(x) ((x) << 10) + #define UNSC(x) ((x) >> 10) /* Make sure we are using a supported resolution */ if ((err = w9968cf_adjust_window_size(cam, (u16*)&win.width, @@ -1836,15 +1836,15 @@ w9968cf_set_window(struct w9968cf_device goto error; /* Scaling factors */ - fw = __SC(win.width) / cam->maxwidth; - fh = __SC(win.height) / cam->maxheight; + fw = SC(win.width) / cam->maxwidth; + fh = SC(win.height) / cam->maxheight; /* Set up the width and height values used by the chip */ if ((win.width > cam->maxwidth) || (win.height > cam->maxheight)) { cam->vpp_flag |= VPP_UPSCALE; /* Calculate largest w,h mantaining the same w/h ratio */ - w = (fw >= fh) ? cam->maxwidth : __SC(win.width)/fh; - h = (fw >= fh) ? __SC(win.height)/fw : cam->maxheight; + w = (fw >= fh) ? cam->maxwidth : SC(win.width)/fh; + h = (fw >= fh) ? SC(win.height)/fw : cam->maxheight; if (w < cam->minwidth) /* just in case */ w = cam->minwidth; if (h < cam->minheight) /* just in case */ @@ -1861,8 +1861,8 @@ w9968cf_set_window(struct w9968cf_device /* Calculate cropped area manteining the right w/h ratio */ if (cam->largeview && !(cam->vpp_flag & VPP_UPSCALE)) { - cw = (fw >= fh) ? cam->maxwidth : __SC(win.width)/fh; - ch = (fw >= fh) ? __SC(win.height)/fw : cam->maxheight; + cw = (fw >= fh) ? cam->maxwidth : SC(win.width)/fh; + ch = (fw >= fh) ? SC(win.height)/fw : cam->maxheight; } else { cw = w; ch = h; @@ -1901,8 +1901,8 @@ w9968cf_set_window(struct w9968cf_device /* We have to scale win.x and win.y offsets */ if ( (cam->largeview && !(cam->vpp_flag & VPP_UPSCALE)) || (cam->vpp_flag & VPP_UPSCALE) ) { - ax = __SC(win.x)/fw; - ay = __SC(win.y)/fh; + ax = SC(win.x)/fw; + ay = SC(win.y)/fh; } else { ax = win.x; ay = win.y; @@ -1917,8 +1917,8 @@ w9968cf_set_window(struct w9968cf_device /* Adjust win.x, win.y */ if ( (cam->largeview && !(cam->vpp_flag & VPP_UPSCALE)) || (cam->vpp_flag & VPP_UPSCALE) ) { - win.x = __UNSC(ax*fw); - win.y = __UNSC(ay*fh); + win.x = UNSC(ax*fw); + win.y = UNSC(ay*fh); } else { win.x = ax; win.y = ay; From zzh.hust@gmail.com Mon Dec 11 03:50:10 2006 Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 11 Dec 2006 03:50:14 +0000 (GMT) Received: from nf-out-0910.google.com ([64.233.182.185]:35426 "EHLO nf-out-0910.google.com") by ftp.linux-mips.org with ESMTP id S20039461AbWLKDuK (ORCPT ); Mon, 11 Dec 2006 03:50:10 +0000 Received: by nf-out-0910.google.com with SMTP id l24so1778693nfc for ; Sun, 10 Dec 2006 19:50:10 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; b=B9AVPPEbXg6pI/uvESmlf+6QaIbddbBlXS47A6Qsfatrs/G6VqWCdlXChxyhao/58DcdRPaljg4bufK9cwmUiOD8kWXp3e0z2bbiIIpcIgXmmGlb7DXZ3Xue6lTz87N1gR6MlJwHowD1ruL1eUHXuueYGkbmzgsLppaFfP8F4fo= Received: by 10.82.114.3 with SMTP id m3mr524478buc.1165809010040; Sun, 10 Dec 2006 19:50:10 -0800 (PST) Received: by 10.82.179.13 with HTTP; Sun, 10 Dec 2006 19:50:10 -0800 (PST) Message-ID: <50c9a2250612101950s20e3f71cs7c6726be43685b26@mail.gmail.com> Date: Mon, 11 Dec 2006 11:50:10 +0800 From: zhuzhenhua To: linux-mips Subject: hwo to improve a video decoder program's timeslice MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed 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: 13424 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: zzh.hust@gmail.com Precedence: bulk X-list: linux-mips i have a video decoder program run as aplication and i now have change the HZ from 1000 to 100, set the decoder program priority as 99. if i want to the video decoder program to get more time to run, is there any other way to improve it ? thanks for any hints Best Regards zhuzhenhua From anemo@mba.ocn.ne.jp Mon Dec 11 04:40:29 2006 Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 11 Dec 2006 04:40:33 +0000 (GMT) Received: from topsns2.toshiba-tops.co.jp ([202.230.225.126]:4696 "EHLO topsns2.toshiba-tops.co.jp") by ftp.linux-mips.org with ESMTP id S20038448AbWLKEk3 (ORCPT ); Mon, 11 Dec 2006 04:40:29 +0000 Received: from topsms.toshiba-tops.co.jp by topsns2.toshiba-tops.co.jp via smtpd (for ftp.linux-mips.org [194.74.144.162]) with ESMTP; Mon, 11 Dec 2006 13:40:28 +0900 Received: from topsms.toshiba-tops.co.jp (localhost.localdomain [127.0.0.1]) by localhost.toshiba-tops.co.jp (Postfix) with ESMTP id 9347641525; Mon, 11 Dec 2006 13:40:24 +0900 (JST) Received: from srd2sd.toshiba-tops.co.jp (srd2sd.toshiba-tops.co.jp [172.17.28.2]) by topsms.toshiba-tops.co.jp (Postfix) with ESMTP id 8659520327; Mon, 11 Dec 2006 13:40:24 +0900 (JST) Received: from localhost (fragile [172.17.28.65]) by srd2sd.toshiba-tops.co.jp (8.12.10/8.12.10) with ESMTP id kBB4eOW0007811; Mon, 11 Dec 2006 13:40:24 +0900 (JST) (envelope-from anemo@mba.ocn.ne.jp) Date: Mon, 11 Dec 2006 13:40:24 +0900 (JST) Message-Id: <20061211.134024.41628345.nemoto@toshiba-tops.co.jp> To: linux-mips@linux-mips.org Cc: ralf@linux-mips.org Subject: Re: [PATCH] Fix negative buffer overflow in copy_from_user From: Atsushi Nemoto In-Reply-To: <20061211.011647.41196525.anemo@mba.ocn.ne.jp> References: <20061211.011647.41196525.anemo@mba.ocn.ne.jp> 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 3.3 on Emacs 21.3 / 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: 13425 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, 11 Dec 2006 01:16:47 +0900 (JST), Atsushi Nemoto wrote: > If we passed an invalid _and_ unaligned source address to > copy_from_user(), the fault handling code miscalculates a length of > uncopied bytes and returns a value greater than original length. This > also causes an negative buffer overflow and overwrites some bytes just > before the destination kernel buffer. > > This can happen "src_unaligned" case in memcpy.S. If the first load > from source buffer was a LDFIRST/LDREST (L[WD][RL]) instruction, it > raise an exception and the THREAD_BUADDR will be an aligned address so > it will _smaller_ than its real target address. Sorry, this is wrong! Please ignore this patch. In this case THREAD_BUADDR should be an _unaligned_ address. On QEMU THREAD_BUADDR was an _aligned_ address so it might be a QEMU bug ... --- Atsushi Nemoto From ralf@linux-mips.org Mon Dec 11 15:53:51 2006 Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 11 Dec 2006 15:53:52 +0000 (GMT) Received: from localhost.localdomain ([127.0.0.1]:2178 "EHLO dl5rb.ham-radio-op.net") by ftp.linux-mips.org with ESMTP id S20039438AbWLKPxv (ORCPT ); Mon, 11 Dec 2006 15:53:51 +0000 Received: from denk.linux-mips.net (denk.linux-mips.net [127.0.0.1]) by dl5rb.ham-radio-op.net (8.13.8/8.13.8) with ESMTP id kBBFrgch003729 for ; Mon, 11 Dec 2006 15:53:42 GMT Received: (from ralf@localhost) by denk.linux-mips.net (8.13.8/8.13.8/Submit) id kBBFrfGL003728 for linux-mips@linux-mips.org; Mon, 11 Dec 2006 15:53:41 GMT Date: Mon, 11 Dec 2006 15:53:41 +0000 From: Ralf Baechle To: linux-mips@linux-mips.org Subject: Git stuff Message-ID: <20061211155341.GA3542@linux-mips.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.2i 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: 13426 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've been asked what that strange commit commit e81fbbbb9a0d8072460c223e935fb1aca4231dc0 Merge: 6f0b1e5... 9202f32... Author: Ralf Baechle Date: Mon Dec 11 12:25:29 2006 +0000 Merge branch 'master' of git://git.kernel.org/pub/scm/linux/kernel/git/torva nothing to commit from around noon today means - it's a merge commit where after resolution of the merge conflict there was nothing left to commit. Nothing to worry :) Also sorry for the flood of commit messages. I cherry pick any commit that is a fix to the -stable branches which ends multiplying the number of commits. If you only care about certain branches you can use i.e. procmail to filter away the uninterestin messages. The format of the mail messages was choosen to make that easy. Ralf From philippedeswert@scarlet.be Mon Dec 11 18:10:55 2006 Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 11 Dec 2006 18:11:00 +0000 (GMT) Received: from oola.is.scarlet.be ([193.74.71.23]:57732 "EHLO oola.is.scarlet.be") by ftp.linux-mips.org with ESMTP id S20039494AbWLKSKz convert rfc822-to-8bit (ORCPT ); Mon, 11 Dec 2006 18:10:55 +0000 Received: from (fuji.is.scarlet.be [193.74.71.41]) by oola.is.scarlet.be with ESMTP id kBBIAro04841; Mon, 11 Dec 2006 19:10:53 +0100 Date: Mon, 11 Dec 2006 19:10:53 +0100 Message-Id: Subject: Re:hwo to improve a video decoder program's timeslice MIME-Version: 1.0 X-Sensitivity: 3 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8BIT From: "Philippe De Swert" To: "zzh\.hust" Cc: "linux-mips" X-XaM3-API-Version: 4.1 (B54) X-type: 0 X-SenderIP: 192.100.124.218 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-Envid: i have a video decoder program run as aplication > and i now have change the HZ from 1000 to 100, set the decoder program > priority as 99. Seems you are mixing things here... The HZ change will just change the interval of the timer tick. For some more explanations about this, look here : http://kerneltrap.org/node/464 > if i want to the video decoder program to get more time to run, is > there any other way to improve it ? Maybe using nice? Try "man nice" in a terminal on your Linux box to get more explanations about this. Cheers, Philippe--- Scarlet ONE - Combine ADSL with unlimited fixed phone and save 400 euros http://www.scarlet.be From ralf@linux-mips.org Mon Dec 11 18:16:42 2006 Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 11 Dec 2006 18:16:44 +0000 (GMT) Received: from localhost.localdomain ([127.0.0.1]:47597 "EHLO dl5rb.ham-radio-op.net") by ftp.linux-mips.org with ESMTP id S20039491AbWLKSQm (ORCPT ); Mon, 11 Dec 2006 18:16:42 +0000 Received: from denk.linux-mips.net (denk.linux-mips.net [127.0.0.1]) by dl5rb.ham-radio-op.net (8.13.8/8.13.8) with ESMTP id kBBIGeNe028049; Mon, 11 Dec 2006 18:16:40 GMT Received: (from ralf@localhost) by denk.linux-mips.net (8.13.8/8.13.8/Submit) id kBBIGe2i028044; Mon, 11 Dec 2006 18:16:40 GMT Date: Mon, 11 Dec 2006 18:16:40 +0000 From: Ralf Baechle To: Franck Bui-Huu Cc: linux-mips@linux-mips.org, Franck Bui-Huu Subject: Re: [PATCH 2/3] Setup min_low_pfn/max_low_pfn correctly Message-ID: <20061211181640.GA25769@linux-mips.org> References: <1165420110699-git-send-email-fbuihuu@gmail.com> <11654201103291-git-send-email-fbuihuu@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <11654201103291-git-send-email-fbuihuu@gmail.com> User-Agent: Mutt/1.4.2.2i 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: 13428 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, Dec 06, 2006 at 04:48:29PM +0100, Franck Bui-Huu wrote: > The old code was assuming that min_low_pfn was always 0. This > means that we can't handle platforms with a big hole at start > of memory since mem_map[] size would blew up. It was - and IP22 was paying a high price for that. It's currently 1MB on 32-bit and 1.75MB on 64-bit kernels - but used to be much higher in the past. Btw, I think you're confusing the terms here; your patch description reads wrong while the patch looks fine. PFN is page frame number, not physical frame number. To avoid wasting dead mem_map[] entries idealy the pfn for the first allocatable page should be zero. So ignoring NUMA and discontig memory for a moment (those make everything more complicated ...) PFN 0 is the first entry in mem_map[] - which usually but not necessarily is physical address 0x0. > This patch does not relax this constraint but it's a first > step to achieve that. > diff --git a/arch/mips/kernel/setup.c b/arch/mips/kernel/setup.c > index 89440a0..8e58d7f 100644 > --- a/arch/mips/kernel/setup.c > +++ b/arch/mips/kernel/setup.c > @@ -271,7 +271,6 @@ static void __init bootmem_init(void) > static void __init bootmem_init(void) > { > unsigned long reserved_end; > - unsigned long highest = 0; > unsigned long mapstart = -1UL; Assigning a negative number to an unsigned long variable ... > unsigned long bootmap_size; > int i; > @@ -284,6 +283,13 @@ static void __init bootmem_init(void) > reserved_end = max(init_initrd(), PFN_UP(__pa_symbol(&_end))); > > /* > + * max_low_pfn is not a number of pages. The number of pages > + * of the system is given by 'max_low_pfn - min_low_pfn'. > + */ > + min_low_pfn = -1UL; Assigning a negative number to an unsigned long variable ... Ralf From ralf@linux-mips.org Mon Dec 11 18:46:40 2006 Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 11 Dec 2006 18:46:42 +0000 (GMT) Received: from localhost.localdomain ([127.0.0.1]:20898 "EHLO dl5rb.ham-radio-op.net") by ftp.linux-mips.org with ESMTP id S20039510AbWLKSqk (ORCPT ); Mon, 11 Dec 2006 18:46:40 +0000 Received: from denk.linux-mips.net (denk.linux-mips.net [127.0.0.1]) by dl5rb.ham-radio-op.net (8.13.8/8.13.8) with ESMTP id kBBIkemx015120; Mon, 11 Dec 2006 18:46:40 GMT Received: (from ralf@localhost) by denk.linux-mips.net (8.13.8/8.13.8/Submit) id kBBIkeAE015119; Mon, 11 Dec 2006 18:46:40 GMT Date: Mon, 11 Dec 2006 18:46:40 +0000 From: Ralf Baechle To: Franck Bui-Huu Cc: linux-mips@linux-mips.org Subject: Re: [RFC] FLATMEM: allow memory to start at pfn != 0 Message-ID: <20061211184640.GB1308@linux-mips.org> References: <1165420110699-git-send-email-fbuihuu@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1165420110699-git-send-email-fbuihuu@gmail.com> User-Agent: Mutt/1.4.2.2i 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: 13429 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, Dec 06, 2006 at 04:48:27PM +0100, Franck Bui-Huu wrote: I just tested this on a Malta. So patch 2/3 makes Malta die pretty spectacularly, so I'm going to remve patches 2/3 and 3/3 again from my tree. Btw, there's spelling mistake in 2/3: + panic("Boggus memory mapping !!!"); Ralf From luca.risolia@studio.unibo.it Mon Dec 11 20:01:57 2006 Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 11 Dec 2006 20:02:02 +0000 (GMT) Received: from as4.cineca.com ([130.186.84.213]:10419 "EHLO as4.cineca.com") by ftp.linux-mips.org with ESMTP id S20039517AbWLKUB5 (ORCPT ); Mon, 11 Dec 2006 20:01:57 +0000 Received: from localhost (localhost.localdomain [127.0.0.1]) by as4.cineca.com (Postfix) with ESMTP id 114B825DAED; Mon, 11 Dec 2006 21:01:39 +0100 (CET) Received: from unibo.mm.cineca.it (unibo.mm.cineca.it [130.186.10.202]) by as4.cineca.com (Postfix) with ESMTP id 799DD25DAC3; Mon, 11 Dec 2006 21:01:27 +0100 (CET) Received: from localhost (unibo.mm.cineca.it [130.186.10.202]) as user anonymous by unibo.mm.cineca.it (Postfix) with ESMTP id A8C37D74B6B; Mon, 11 Dec 2006 21:01:26 +0100 (MET) Received: from 151.46.154.186 ( [151.46.154.186]) as user luca.risolia@studio.unibo.it@posta.studio.unibo.it by posta.studio.unibo.it with HTTP; Mon, 11 Dec 2006 21:01:26 +0100 Message-ID: <1165867286.457db9169cf67@posta.studio.unibo.it> Date: Mon, 11 Dec 2006 21:01:26 +0100 From: "luca.risolia@studio.unibo.it" To: Ralf Baechle Cc: Andrew Morton , linux-kernel@vger.kernel.org, linux-mips@linux-mips.org, mchehab@infradead.org Subject: Re: [PATCH] Fix namespace conflict between w9968cf.c on MIPS References: <20061210194144.GA423@linux-mips.org> In-Reply-To: <20061210194144.GA423@linux-mips.org> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit User-Agent: Internet Messaging Program (IMP) 3.1 X-Originating-IP: 151.46.154.186 X-Virus-Scanned: Cineca AppOs 0.99 at as4.cineca.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: 13430 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: luca.risolia@studio.unibo.it Precedence: bulk X-list: linux-mips Okay, thanks. Best regards Luca Risolia Scrive Ralf Baechle : > Both use __SC. Since __* is sort of private namespace I've choosen to > fix this in the driver. For consistency I decieded to also change > __UNSC to UNSC. > > Signed-off-by: Ralf Baechle > > diff --git a/drivers/media/video/w9968cf.c b/drivers/media/video/w9968cf.c > index ddce2fb..9f403af 100644 > --- a/drivers/media/video/w9968cf.c > +++ b/drivers/media/video/w9968cf.c > @@ -1827,8 +1827,8 @@ w9968cf_set_window(struct w9968cf_device > int err = 0; > > /* Work around to avoid FP arithmetics */ > - #define __SC(x) ((x) << 10) > - #define __UNSC(x) ((x) >> 10) > + #define SC(x) ((x) << 10) > + #define UNSC(x) ((x) >> 10) > > /* Make sure we are using a supported resolution */ > if ((err = w9968cf_adjust_window_size(cam, (u16*)&win.width, > @@ -1836,15 +1836,15 @@ w9968cf_set_window(struct w9968cf_device > goto error; > > /* Scaling factors */ > - fw = __SC(win.width) / cam->maxwidth; > - fh = __SC(win.height) / cam->maxheight; > + fw = SC(win.width) / cam->maxwidth; > + fh = SC(win.height) / cam->maxheight; > > /* Set up the width and height values used by the chip */ > if ((win.width > cam->maxwidth) || (win.height > cam->maxheight)) { > cam->vpp_flag |= VPP_UPSCALE; > /* Calculate largest w,h mantaining the same w/h ratio */ > - w = (fw >= fh) ? cam->maxwidth : __SC(win.width)/fh; > - h = (fw >= fh) ? __SC(win.height)/fw : cam->maxheight; > + w = (fw >= fh) ? cam->maxwidth : SC(win.width)/fh; > + h = (fw >= fh) ? SC(win.height)/fw : cam->maxheight; > if (w < cam->minwidth) /* just in case */ > w = cam->minwidth; > if (h < cam->minheight) /* just in case */ > @@ -1861,8 +1861,8 @@ w9968cf_set_window(struct w9968cf_device > > /* Calculate cropped area manteining the right w/h ratio */ > if (cam->largeview && !(cam->vpp_flag & VPP_UPSCALE)) { > - cw = (fw >= fh) ? cam->maxwidth : __SC(win.width)/fh; > - ch = (fw >= fh) ? __SC(win.height)/fw : cam->maxheight; > + cw = (fw >= fh) ? cam->maxwidth : SC(win.width)/fh; > + ch = (fw >= fh) ? SC(win.height)/fw : cam->maxheight; > } else { > cw = w; > ch = h; > @@ -1901,8 +1901,8 @@ w9968cf_set_window(struct w9968cf_device > /* We have to scale win.x and win.y offsets */ > if ( (cam->largeview && !(cam->vpp_flag & VPP_UPSCALE)) > || (cam->vpp_flag & VPP_UPSCALE) ) { > - ax = __SC(win.x)/fw; > - ay = __SC(win.y)/fh; > + ax = SC(win.x)/fw; > + ay = SC(win.y)/fh; > } else { > ax = win.x; > ay = win.y; > @@ -1917,8 +1917,8 @@ w9968cf_set_window(struct w9968cf_device > /* Adjust win.x, win.y */ > if ( (cam->largeview && !(cam->vpp_flag & VPP_UPSCALE)) > || (cam->vpp_flag & VPP_UPSCALE) ) { > - win.x = __UNSC(ax*fw); > - win.y = __UNSC(ay*fh); > + win.x = UNSC(ax*fw); > + win.y = UNSC(ay*fh); > } else { > win.x = ax; > win.y = ay; > > From zzh.hust@gmail.com Tue Dec 12 00:58:15 2006 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 12 Dec 2006 00:58:19 +0000 (GMT) Received: from nf-out-0910.google.com ([64.233.182.191]:53426 "EHLO nf-out-0910.google.com") by ftp.linux-mips.org with ESMTP id S20039561AbWLLA6P (ORCPT ); Tue, 12 Dec 2006 00:58:15 +0000 Received: by nf-out-0910.google.com with SMTP id l24so73437nfc for ; Mon, 11 Dec 2006 16:58:07 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=dter0MhAnz5/Mec/jkvYNqFLPzEic06efpxzTHZCJ7BPzevc7r4V20A31/ja4/Q7C5DcZcJquYMtD1FQdC5C7FEIxbHGSJXkDADheDIM7cL3HOxGV+T1dlj+AJBYl7v84hByv7s8K9c0qN2q9dnBxrR7PeYPaw+FH8tiMaMBAVY= Received: by 10.82.105.13 with SMTP id d13mr1196885buc.1165885087427; Mon, 11 Dec 2006 16:58:07 -0800 (PST) Received: by 10.82.178.4 with HTTP; Mon, 11 Dec 2006 16:58:06 -0800 (PST) Message-ID: <50c9a2250612111658t50c5cdcdtd6831101d4316e2e@mail.gmail.com> Date: Tue, 12 Dec 2006 08:58:06 +0800 From: zhuzhenhua To: "Philippe De Swert" Subject: Re: hwo to improve a video decoder program's timeslice Cc: linux-mips In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline 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: 13431 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: zzh.hust@gmail.com Precedence: bulk X-list: linux-mips On 12/12/06, Philippe De Swert wrote: > Hi, > > > i have a video decoder program run as aplication > > and i now have change the HZ from 1000 to 100, set the decoder program > > priority as 99. > > Seems you are mixing things here... The HZ change will just change the > interval of the timer tick. For some more explanations about this, look here : > http://kerneltrap.org/node/464 > > > if i want to the video decoder program to get more time to run, is > > there any other way to improve it ? > > Maybe using nice? Try "man nice" in a terminal on your Linux box to get more > explanations about this. thanks, i have try nice already, there's not too much change. > > Cheers, > > Philippe--- > Scarlet ONE - Combine ADSL with unlimited fixed phone and save 400 euros > http://www.scarlet.be > > From vagabon.xyz@gmail.com Tue Dec 12 08:55:48 2006 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 12 Dec 2006 08:55:52 +0000 (GMT) Received: from ug-out-1314.google.com ([66.249.92.171]:49983 "EHLO ug-out-1314.google.com") by ftp.linux-mips.org with ESMTP id S20037892AbWLLIzs (ORCPT ); Tue, 12 Dec 2006 08:55:48 +0000 Received: by ug-out-1314.google.com with SMTP id 40so1953865uga for ; Tue, 12 Dec 2006 00:55:47 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=QNvPQYQ07bVRHGzDxpH+1lBweBiEJZvrIawXhaAv0QW7LE6j64Miw7D2WljzngMmfbmteWpzPiZkCzQbu1CpXKSkDEL/qZpOj08hXQYj9hACZ/YIFDQePYP/981ng9/rUs10xevUMlxMl+gLSYmalWPSJf1Mjvjsd4HgDSBg1I8= Received: by 10.78.21.7 with SMTP id 7mr156756huu.1165913746868; Tue, 12 Dec 2006 00:55:46 -0800 (PST) Received: by 10.78.123.2 with HTTP; Tue, 12 Dec 2006 00:55:41 -0800 (PST) Message-ID: Date: Tue, 12 Dec 2006 09:55:41 +0100 From: "Franck Bui-Huu" To: "Ralf Baechle" Subject: Re: [RFC] FLATMEM: allow memory to start at pfn != 0 Cc: linux-mips@linux-mips.org In-Reply-To: <20061211184640.GB1308@linux-mips.org> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <1165420110699-git-send-email-fbuihuu@gmail.com> <20061211184640.GB1308@linux-mips.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: 13432 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 Ralf, On 12/11/06, Ralf Baechle wrote: > On Wed, Dec 06, 2006 at 04:48:27PM +0100, Franck Bui-Huu wrote: > > I just tested this on a Malta. So patch 2/3 makes Malta die pretty > spectacularly, so I'm going to remve patches 2/3 and 3/3 again from my > tree. > Thanks for your review ! Could you give me some info about your config to help me to find out the issue ? For example what's your value of PHYS_OFFSET ? your memory mapping ? > Btw, there's spelling mistake in 2/3: > > + panic("Boggus memory mapping !!!"); I'll fix it by "Incorrect memory mapping !!!" thanks -- Franck From vagabon.xyz@gmail.com Tue Dec 12 09:14:55 2006 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 12 Dec 2006 09:15:00 +0000 (GMT) Received: from ug-out-1314.google.com ([66.249.92.171]:48802 "EHLO ug-out-1314.google.com") by ftp.linux-mips.org with ESMTP id S20037867AbWLLJOz (ORCPT ); Tue, 12 Dec 2006 09:14:55 +0000 Received: by ug-out-1314.google.com with SMTP id 40so1958510uga for ; Tue, 12 Dec 2006 01:14:54 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=nkL4IlS9AzDVvGE+2LHY2gI6vUh+kqc+TqPMB0QH6cckyOUaJOFNLp3UQcZOWM5a6ffvfYEKgKz/V1m/GoDZmdlE2EQ/ZX6nXK2lLTD9bVdNQ2duUZfpPHb3L+43vqQVyI2ryG/iayt96vQDV7RBa26FUrOg/qSyMF0fR6qeKdk= Received: by 10.78.193.19 with SMTP id q19mr869629huf.1165914893886; Tue, 12 Dec 2006 01:14:53 -0800 (PST) Received: by 10.78.123.2 with HTTP; Tue, 12 Dec 2006 01:14:53 -0800 (PST) Message-ID: Date: Tue, 12 Dec 2006 10:14:53 +0100 From: "Franck Bui-Huu" To: "Ralf Baechle" Subject: Re: [PATCH 2/3] Setup min_low_pfn/max_low_pfn correctly Cc: linux-mips@linux-mips.org, "Franck Bui-Huu" In-Reply-To: <20061211181640.GA25769@linux-mips.org> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <1165420110699-git-send-email-fbuihuu@gmail.com> <11654201103291-git-send-email-fbuihuu@gmail.com> <20061211181640.GA25769@linux-mips.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: 13433 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 On 12/11/06, Ralf Baechle wrote: > On Wed, Dec 06, 2006 at 04:48:29PM +0100, Franck Bui-Huu wrote: > > > The old code was assuming that min_low_pfn was always 0. This > > means that we can't handle platforms with a big hole at start > > of memory since mem_map[] size would blew up. > > It was - and IP22 was paying a high price for that. It's currently 1MB > on 32-bit and 1.75MB on 64-bit kernels - but used to be much higher in > the past. > > Btw, I think you're confusing the terms here; your patch description reads > wrong while the patch looks fine. PFN is page frame number, not physical > frame number. To avoid wasting dead mem_map[] entries idealy the pfn for > the first allocatable page should be zero. > So ignoring NUMA and discontig memory for a moment (those make everything > more complicated ...) PFN 0 is the first entry in mem_map[] - which usually > but not necessarily is physical address 0x0. > well if you look at the generic definition of pfn_to_page(), you find: #define __pfn_to_page(pfn) (mem_map + ((pfn) - ARCH_PFN_OFFSET)) With the current implementation, PFN 0 is something that does not exist. PFN ARCH_PFN_OFFSET is the first entry in mem_map[]... I think I'm missing your point.... > > This patch does not relax this constraint but it's a first > > step to achieve that. > > > diff --git a/arch/mips/kernel/setup.c b/arch/mips/kernel/setup.c > > index 89440a0..8e58d7f 100644 > > --- a/arch/mips/kernel/setup.c > > +++ b/arch/mips/kernel/setup.c > > @@ -271,7 +271,6 @@ static void __init bootmem_init(void) > > static void __init bootmem_init(void) > > { > > unsigned long reserved_end; > > - unsigned long highest = 0; > > unsigned long mapstart = -1UL; > > Assigning a negative number to an unsigned long variable ... > Well, it's a convenient way to set mapstart to 0xffffffff on both 32bits and 64bits kernels as you guessed. I think it's quite readable thanks to the 'UL' suffix. But I'll change the whole line with: unsigned long mapstart = ~(0UL); > > unsigned long bootmap_size; > > int i; > > @@ -284,6 +283,13 @@ static void __init bootmem_init(void) > > reserved_end = max(init_initrd(), PFN_UP(__pa_symbol(&_end))); > > > > /* > > + * max_low_pfn is not a number of pages. The number of pages > > + * of the system is given by 'max_low_pfn - min_low_pfn'. > > + */ > > + min_low_pfn = -1UL; > > Assigning a negative number to an unsigned long variable ... ditto thanks -- Franck From anemo@mba.ocn.ne.jp Tue Dec 12 16:23:01 2006 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 12 Dec 2006 16:23:08 +0000 (GMT) Received: from [210.190.142.172] ([210.190.142.172]:61928 "HELO smtp.mba.ocn.ne.jp") by ftp.linux-mips.org with SMTP id S20038801AbWLLQXB (ORCPT ); Tue, 12 Dec 2006 16:23:01 +0000 Received: from localhost (p4142-ipad01funabasi.chiba.ocn.ne.jp [61.207.78.142]) by smtp.mba.ocn.ne.jp (Postfix) with ESMTP id DF74BBBC0; Wed, 13 Dec 2006 01:22:06 +0900 (JST) Date: Wed, 13 Dec 2006 01:22:06 +0900 (JST) Message-Id: <20061213.012206.98747230.anemo@mba.ocn.ne.jp> To: linux-mips@linux-mips.org Cc: ralf@linux-mips.org Subject: [PATCH] csum_partial and copy in parallel From: Atsushi Nemoto 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 3.3 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: 13434 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 Implement optimized asm version of csum_partial_copy_nocheck, csum_partial_copy_from_user and csum_and_copy_to_user which can do calculate and copy in parallel, based on memcpy.S. Signed-off-by: Atsushi Nemoto --- arch/mips/lib/Makefile | 2 arch/mips/lib/csum_partial.S | 459 ++++++++++++++++++++++++++++++++++++ arch/mips/lib/csum_partial_copy.c | 52 ---- include/asm-mips/checksum.h | 31 +- 4 files changed, 479 insertions(+), 65 deletions(-) diff --git a/arch/mips/lib/Makefile b/arch/mips/lib/Makefile index 9bf005f..30a9b83 100644 --- a/arch/mips/lib/Makefile +++ b/arch/mips/lib/Makefile @@ -2,7 +2,7 @@ # # Makefile for MIPS-specific library files.. # -lib-y += csum_partial.o csum_partial_copy.o memcpy.o promlib.o \ +lib-y += csum_partial.o memcpy.o promlib.o \ strlen_user.o strncpy_user.o strnlen_user.o uncached.o # libgcc-style stuff needed in the kernel diff --git a/arch/mips/lib/csum_partial.S b/arch/mips/lib/csum_partial.S index 9db3572..ec0744d 100644 --- a/arch/mips/lib/csum_partial.S +++ b/arch/mips/lib/csum_partial.S @@ -8,7 +8,9 @@ * Copyright (C) 1998, 1999 Ralf Baechle * Copyright (C) 1999 Silicon Graphics, Inc. */ +#include #include +#include #include #ifdef CONFIG_64BIT @@ -271,3 +273,460 @@ #endif jr ra .set noreorder END(csum_partial) + + +/* + * checksum and copy routines based on memcpy.S + * + * csum_partial_copy_nocheck(src, dst, len, sum) + * __csum_partial_copy_from_user(src, dst, len, sum, errp) + * __csum_and_copy_to_user(src, dst, len, sum, errp) + * + * See "Spec" in memcpy.S for details. Unlike __copy_user, all + * function in this file use the standard calling convention. + */ + +#define src a0 +#define dst a1 +#define len a2 +#define psum a3 +#define sum v0 +#define odd t5 +#define errptr t6 + +/* + * The exception handler for loads requires that: + * 1- AT contain the address of the byte just past the end of the source + * of the copy, + * 2- src_entry <= src < AT, and + * 3- (dst - src) == (dst_entry - src_entry), + * The _entry suffix denotes values when __copy_user was called. + * + * (1) is set up up by __csum_partial_copy_from_user and maintained by + * not writing AT in __csum_partial_copy + * (2) is met by incrementing src by the number of bytes copied + * (3) is met by not doing loads between a pair of increments of dst and src + * + * The exception handlers for stores stores -EFAULT to errptr and return. + * These handlers do not need to overwrite any data. + */ + +#define EXC(inst_reg,addr,handler) \ +9: inst_reg, addr; \ + .section __ex_table,"a"; \ + PTR 9b, handler; \ + .previous + +#ifdef USE_DOUBLE + +#define LOAD ld +#define LOADL ldl +#define LOADR ldr +#define STOREL sdl +#define STORER sdr +#define STORE sd +#define ADD daddu +#define SUB dsubu +#define SRL dsrl +#define SLL dsll +#define SLLV dsllv +#define SRLV dsrlv +#define NBYTES 8 +#define LOG_NBYTES 3 + +#else + +#define LOAD lw +#define LOADL lwl +#define LOADR lwr +#define STOREL swl +#define STORER swr +#define STORE sw +#define ADD addu +#define SUB subu +#define SRL srl +#define SLL sll +#define SLLV sllv +#define SRLV srlv +#define NBYTES 4 +#define LOG_NBYTES 2 + +#endif /* USE_DOUBLE */ + +#ifdef CONFIG_CPU_LITTLE_ENDIAN +#define LDFIRST LOADR +#define LDREST LOADL +#define STFIRST STORER +#define STREST STOREL +#define SHIFT_DISCARD SLLV +#define SHIFT_DISCARD_REVERT SRLV +#else +#define LDFIRST LOADL +#define LDREST LOADR +#define STFIRST STOREL +#define STREST STORER +#define SHIFT_DISCARD SRLV +#define SHIFT_DISCARD_REVERT SLLV +#endif + +#define FIRST(unit) ((unit)*NBYTES) +#define REST(unit) (FIRST(unit)+NBYTES-1) + +#define ADDRMASK (NBYTES-1) + + .set noat + +LEAF(csum_partial_copy_nocheck) + move AT, zero + b __csum_partial_copy + move errptr, zero +FEXPORT(__csum_partial_copy_from_user) + b __csum_partial_copy_user + PTR_ADDU AT, src, len /* See (1) above. */ +FEXPORT(__csum_and_copy_to_user) + move AT, zero +__csum_partial_copy_user: +#ifdef CONFIG_64BIT + move errptr, a4 +#else + lw errptr, 16(sp) +#endif +__csum_partial_copy: + move sum, zero + move odd, zero + /* + * Note: dst & src may be unaligned, len may be 0 + * Temps + */ +#define rem t8 + + /* + * The "issue break"s below are very approximate. + * Issue delays for dcache fills will perturb the schedule, as will + * load queue full replay traps, etc. + * + * If len < NBYTES use byte operations. + */ + sltu t2, len, NBYTES + and t1, dst, ADDRMASK + bnez t2, copy_bytes_checklen + and t0, src, ADDRMASK + andi odd, dst, 0x1 /* odd buffer? */ + bnez t1, dst_unaligned + nop + bnez t0, src_unaligned_dst_aligned + /* + * use delay slot for fall-through + * src and dst are aligned; need to compute rem + */ +both_aligned: + SRL t0, len, LOG_NBYTES+3 # +3 for 8 units/iter + beqz t0, cleanup_both_aligned # len < 8*NBYTES + and rem, len, (8*NBYTES-1) # rem = len % (8*NBYTES) + /* + * We can not do this loop if LOAD might fail, otherwize + * l_exc_copy can not calclate sum correctly. + * AT==0 means LOAD should not fail. + */ + bnez AT, cleanup_both_aligned + nop + .align 4 +1: + LOAD t0, UNIT(0)(src) + LOAD t1, UNIT(1)(src) + LOAD t2, UNIT(2)(src) + LOAD t3, UNIT(3)(src) + SUB len, len, 8*NBYTES + LOAD t4, UNIT(4)(src) + LOAD t7, UNIT(5)(src) +EXC( STORE t0, UNIT(0)(dst), s_exc) + ADDC(sum, t0) +EXC( STORE t1, UNIT(1)(dst), s_exc) + ADDC(sum, t1) + LOAD t0, UNIT(6)(src) + LOAD t1, UNIT(7)(src) + ADD src, src, 8*NBYTES + ADD dst, dst, 8*NBYTES +EXC( STORE t2, UNIT(-6)(dst), s_exc) + ADDC(sum, t2) +EXC( STORE t3, UNIT(-5)(dst), s_exc) + ADDC(sum, t3) +EXC( STORE t4, UNIT(-4)(dst), s_exc) + ADDC(sum, t4) +EXC( STORE t7, UNIT(-3)(dst), s_exc) + ADDC(sum, t7) +EXC( STORE t0, UNIT(-2)(dst), s_exc) + ADDC(sum, t0) +EXC( STORE t1, UNIT(-1)(dst), s_exc) + .set reorder + ADDC(sum, t1) + bne len, rem, 1b + .set noreorder + + /* + * len == rem == the number of bytes left to copy < 8*NBYTES + */ +cleanup_both_aligned: + beqz len, done + sltu t0, len, 4*NBYTES + bnez t0, less_than_4units + and rem, len, (NBYTES-1) # rem = len % NBYTES + /* + * len >= 4*NBYTES + */ +EXC( LOAD t0, UNIT(0)(src), l_exc) +EXC( LOAD t1, UNIT(1)(src), l_exc_copy) +EXC( LOAD t2, UNIT(2)(src), l_exc_copy) +EXC( LOAD t3, UNIT(3)(src), l_exc_copy) + SUB len, len, 4*NBYTES + ADD src, src, 4*NBYTES +EXC( STORE t0, UNIT(0)(dst), s_exc) + ADDC(sum, t0) +EXC( STORE t1, UNIT(1)(dst), s_exc) + ADDC(sum, t1) +EXC( STORE t2, UNIT(2)(dst), s_exc) + ADDC(sum, t2) +EXC( STORE t3, UNIT(3)(dst), s_exc) + ADDC(sum, t3) + beqz len, done + ADD dst, dst, 4*NBYTES +less_than_4units: + /* + * rem = len % NBYTES + */ + beq rem, len, copy_bytes + nop +1: +EXC( LOAD t0, 0(src), l_exc) + ADD src, src, NBYTES + SUB len, len, NBYTES +EXC( STORE t0, 0(dst), s_exc) + ADDC(sum, t0) + bne rem, len, 1b + ADD dst, dst, NBYTES + + /* + * src and dst are aligned, need to copy rem bytes (rem < NBYTES) + * A loop would do only a byte at a time with possible branch + * mispredicts. Can't do an explicit LOAD dst,mask,or,STORE + * because can't assume read-access to dst. Instead, use + * STREST dst, which doesn't require read access to dst. + * + * This code should perform better than a simple loop on modern, + * wide-issue mips processors because the code has fewer branches and + * more instruction-level parallelism. + */ +#define bits t2 + beqz len, done + ADD t1, dst, len # t1 is just past last byte of dst + li bits, 8*NBYTES + SLL rem, len, 3 # rem = number of bits to keep +EXC( LOAD t0, 0(src), l_exc) + SUB bits, bits, rem # bits = number of bits to discard + SHIFT_DISCARD t0, t0, bits +EXC( STREST t0, -1(t1), s_exc) + SHIFT_DISCARD_REVERT t0, t0, bits + .set reorder + ADDC(sum, t0) + b done + .set noreorder +dst_unaligned: + /* + * dst is unaligned + * t0 = src & ADDRMASK + * t1 = dst & ADDRMASK; T1 > 0 + * len >= NBYTES + * + * Copy enough bytes to align dst + * Set match = (src and dst have same alignment) + */ +#define match rem +EXC( LDFIRST t3, FIRST(0)(src), l_exc) + ADD t2, zero, NBYTES +EXC( LDREST t3, REST(0)(src), l_exc_copy) + SUB t2, t2, t1 # t2 = number of bytes copied + xor match, t0, t1 +EXC( STFIRST t3, FIRST(0)(dst), s_exc) + SLL t4, t1, 3 # t4 = number of bits to discard + SHIFT_DISCARD t3, t3, t4 + /* no SHIFT_DISCARD_REVERT to handle odd buffer properly */ + ADDC(sum, t3) + beq len, t2, done + SUB len, len, t2 + ADD dst, dst, t2 + beqz match, both_aligned + ADD src, src, t2 + +src_unaligned_dst_aligned: + SRL t0, len, LOG_NBYTES+2 # +2 for 4 units/iter + beqz t0, cleanup_src_unaligned + and rem, len, (4*NBYTES-1) # rem = len % 4*NBYTES +1: +/* + * Avoid consecutive LD*'s to the same register since some mips + * implementations can't issue them in the same cycle. + * It's OK to load FIRST(N+1) before REST(N) because the two addresses + * are to the same unit (unless src is aligned, but it's not). + */ +EXC( LDFIRST t0, FIRST(0)(src), l_exc) +EXC( LDFIRST t1, FIRST(1)(src), l_exc_copy) + SUB len, len, 4*NBYTES +EXC( LDREST t0, REST(0)(src), l_exc_copy) +EXC( LDREST t1, REST(1)(src), l_exc_copy) +EXC( LDFIRST t2, FIRST(2)(src), l_exc_copy) +EXC( LDFIRST t3, FIRST(3)(src), l_exc_copy) +EXC( LDREST t2, REST(2)(src), l_exc_copy) +EXC( LDREST t3, REST(3)(src), l_exc_copy) + ADD src, src, 4*NBYTES +#ifdef CONFIG_CPU_SB1 + nop # improves slotting +#endif +EXC( STORE t0, UNIT(0)(dst), s_exc) + ADDC(sum, t0) +EXC( STORE t1, UNIT(1)(dst), s_exc) + ADDC(sum, t1) +EXC( STORE t2, UNIT(2)(dst), s_exc) + ADDC(sum, t2) +EXC( STORE t3, UNIT(3)(dst), s_exc) + ADDC(sum, t3) + bne len, rem, 1b + ADD dst, dst, 4*NBYTES + +cleanup_src_unaligned: + beqz len, done + and rem, len, NBYTES-1 # rem = len % NBYTES + beq rem, len, copy_bytes + nop +1: +EXC( LDFIRST t0, FIRST(0)(src), l_exc) +EXC( LDREST t0, REST(0)(src), l_exc_copy) + ADD src, src, NBYTES + SUB len, len, NBYTES +EXC( STORE t0, 0(dst), s_exc) + ADDC(sum, t0) + bne len, rem, 1b + ADD dst, dst, NBYTES + +copy_bytes_checklen: + beqz len, done + nop +copy_bytes: + /* 0 < len < NBYTES */ +#ifdef CONFIG_CPU_LITTLE_ENDIAN +#define SHIFT_START 0 +#define SHIFT_INC 8 +#else +#define SHIFT_START 8*(NBYTES-1) +#define SHIFT_INC -8 +#endif + move t2, zero # partial word + li t3, SHIFT_START # shift +/* use l_exc_copy here to return correct sum on fault */ +#define COPY_BYTE(N) \ +EXC( lbu t0, N(src), l_exc_copy); \ + SUB len, len, 1; \ +EXC( sb t0, N(dst), s_exc); \ + SLLV t0, t0, t3; \ + addu t3, SHIFT_INC; \ + beqz len, copy_bytes_done; \ + or t2, t0 + + COPY_BYTE(0) + COPY_BYTE(1) +#ifdef USE_DOUBLE + COPY_BYTE(2) + COPY_BYTE(3) + COPY_BYTE(4) + COPY_BYTE(5) +#endif +EXC( lbu t0, NBYTES-2(src), l_exc_copy) + SUB len, len, 1 +EXC( sb t0, NBYTES-2(dst), s_exc) + SLLV t0, t0, t3 + or t2, t0 +copy_bytes_done: + ADDC(sum, t2) +done: + /* fold checksum */ +#ifdef USE_DOUBLE + dsll32 v1, sum, 0 + daddu sum, v1 + sltu v1, sum, v1 + dsra32 sum, sum, 0 + addu sum, v1 +#endif + sll v1, sum, 16 + addu sum, v1 + sltu v1, sum, v1 + srl sum, sum, 16 + addu sum, v1 + + /* odd buffer alignment? */ + beqz odd, 1f + nop + sll v1, sum, 8 + srl sum, sum, 8 + or sum, v1 + andi sum, 0xffff +1: + .set reorder + ADDC(sum, psum) + jr ra + .set noreorder + +l_exc_copy: + /* + * Copy bytes from src until faulting load address (or until a + * lb faults) + * + * When reached by a faulting LDFIRST/LDREST, THREAD_BUADDR($28) + * may be more than a byte beyond the last address. + * Hence, the lb below may get an exception. + * + * Assumes src < THREAD_BUADDR($28) + */ + LOAD t0, TI_TASK($28) + li t2, SHIFT_START + LOAD t0, THREAD_BUADDR(t0) +1: +EXC( lbu t1, 0(src), l_exc) + ADD src, src, 1 + sb t1, 0(dst) # can't fault -- we're copy_from_user + SLLV t1, t1, t2 + addu t2, SHIFT_INC + ADDC(sum, t1) + bne src, t0, 1b + ADD dst, dst, 1 +l_exc: + LOAD t0, TI_TASK($28) + nop + LOAD t0, THREAD_BUADDR(t0) # t0 is just past last good address + nop + SUB len, AT, t0 # len number of uncopied bytes + /* + * Here's where we rely on src and dst being incremented in tandem, + * See (3) above. + * dst += (fault addr - src) to put dst at first byte to clear + */ + ADD dst, t0 # compute start address in a1 + SUB dst, src + /* + * Clear len bytes starting at dst. Can't call __bzero because it + * might modify len. An inefficient loop for these rare times... + */ + beqz len, done + SUB src, len, 1 +1: sb zero, 0(dst) + ADD dst, dst, 1 + bnez src, 1b + SUB src, src, 1 + li v1, -EFAULT + b done + sw v1, (errptr) + +s_exc: + li v0, -1 /* invalid checksum */ + li v1, -EFAULT + jr ra + sw v1, (errptr) + END(csum_partial_copy_nocheck) diff --git a/arch/mips/lib/csum_partial_copy.c b/arch/mips/lib/csum_partial_copy.c deleted file mode 100644 index 0677104..0000000 --- a/arch/mips/lib/csum_partial_copy.c +++ /dev/null @@ -1,52 +0,0 @@ -/* - * 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, 1995 Waldorf Electronics GmbH - * Copyright (C) 1998, 1999 Ralf Baechle - */ -#include -#include -#include -#include -#include -#include -#include - -/* - * copy while checksumming, otherwise like csum_partial - */ -__wsum csum_partial_copy_nocheck(const void *src, - void *dst, int len, __wsum sum) -{ - /* - * It's 2:30 am and I don't feel like doing it real ... - * This is lots slower than the real thing (tm) - */ - sum = csum_partial(src, len, sum); - memcpy(dst, src, len); - - return sum; -} - -EXPORT_SYMBOL(csum_partial_copy_nocheck); - -/* - * Copy from userspace and compute checksum. If we catch an exception - * then zero the rest of the buffer. - */ -__wsum csum_partial_copy_from_user (const void __user *src, - void *dst, int len, __wsum sum, int *err_ptr) -{ - int missing; - - might_sleep(); - missing = copy_from_user(dst, src, len); - if (missing) { - memset(dst + len - missing, 0, missing); - *err_ptr = -EFAULT; - } - - return csum_partial(dst, len, sum); -} diff --git a/include/asm-mips/checksum.h b/include/asm-mips/checksum.h index 9b768c3..6596fe6 100644 --- a/include/asm-mips/checksum.h +++ b/include/asm-mips/checksum.h @@ -29,31 +29,38 @@ #include */ __wsum csum_partial(const void *buff, int len, __wsum sum); +__wsum __csum_partial_copy_from_user(const void __user *src, void *dst, + int len, __wsum sum, int *err_ptr); +__wsum __csum_and_copy_to_user(const void *src, void __user *dst, + int len, __wsum sum, int *err_ptr); + /* * this is a new version of the above that records errors it finds in *errp, * but continues and zeros the rest of the buffer. */ -__wsum csum_partial_copy_from_user(const void __user *src, - void *dst, int len, - __wsum sum, int *errp); +static inline +__wsum csum_partial_copy_from_user(const void __user *src, void *dst, int len, + __wsum sum, int *err_ptr) +{ + might_sleep(); + return __csum_partial_copy_from_user(src, dst, len, sum, err_ptr); +} /* * Copy and checksum to user */ #define HAVE_CSUM_COPY_USER -static inline __wsum csum_and_copy_to_user (const void *src, void __user *dst, - int len, __wsum sum, - int *err_ptr) +static inline +__wsum csum_and_copy_to_user(const void *src, void __user *dst, int len, + __wsum sum, int *err_ptr) { might_sleep(); - sum = csum_partial(src, len, sum); - - if (copy_to_user(dst, src, len)) { + if (access_ok(VERIFY_WRITE, dst, len)) + return __csum_and_copy_to_user(src, dst, len, sum, err_ptr); + if (len) *err_ptr = -EFAULT; - return (__force __wsum)-1; - } - return sum; + return (__force __wsum)-1; /* invalid checksum */ } /* From ths@networkno.de Tue Dec 12 17:21:57 2006 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 12 Dec 2006 17:22:03 +0000 (GMT) Received: from phoenix.bawue.net ([193.7.176.60]:20192 "EHLO mail.bawue.net") by ftp.linux-mips.org with ESMTP id S20039585AbWLLRV5 (ORCPT ); Tue, 12 Dec 2006 17:21:57 +0000 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 A30DEB98CC; Tue, 12 Dec 2006 18:20:22 +0100 (CET) Received: from ths by lagash with local (Exim 4.63) (envelope-from ) id 1GuBGc-0006Qb-5u; Tue, 12 Dec 2006 17:18:10 +0000 Date: Tue, 12 Dec 2006 17:18:10 +0000 To: Atsushi Nemoto Cc: linux-mips@linux-mips.org, ralf@linux-mips.org Subject: Re: [PATCH] csum_partial and copy in parallel Message-ID: <20061212171809.GG21819@networkno.de> References: <20061213.012206.98747230.anemo@mba.ocn.ne.jp> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20061213.012206.98747230.anemo@mba.ocn.ne.jp> User-Agent: Mutt/1.5.13 (2006-08-11) From: Thiemo Seufer 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: 13435 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 Atsushi Nemoto wrote: [snip] > + * See "Spec" in memcpy.S for details. Unlike __copy_user, all > + * function in this file use the standard calling convention. > + */ > + > +#define src a0 > +#define dst a1 > +#define len a2 > +#define psum a3 > +#define sum v0 > +#define odd t5 > +#define errptr t6 Does this work for 64 bit? t5/t6/t7 look weird for that. Thiemo From ashlesha@kenati.com Tue Dec 12 19:55:59 2006 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 12 Dec 2006 19:56:05 +0000 (GMT) Received: from [69.90.147.196] ([69.90.147.196]:2972 "EHLO mail.kenati.com") by ftp.linux-mips.org with ESMTP id S20039625AbWLLTz7 (ORCPT ); Tue, 12 Dec 2006 19:55:59 +0000 Received: from [192.168.1.169] (adsl-71-130-109-177.dsl.snfc21.pacbell.net [71.130.109.177]) by mail.kenati.com (Postfix) with ESMTP id 981F1E404D for ; Tue, 12 Dec 2006 13:22:25 -0800 (PST) Subject: 8250 Flag definitions From: Ashlesha Shintre Reply-To: ashlesha@kenati.com To: linux-mips@linux-mips.org Content-Type: text/plain Date: Tue, 12 Dec 2006 12:09:02 -0800 Message-Id: <1165954142.6539.1.camel@sandbar.kenati.com> Mime-Version: 1.0 X-Mailer: Evolution 2.4.2.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: 13436 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: ashlesha@kenati.com Precedence: bulk X-list: linux-mips Hi, Is there a document that outlines the meaning of these flags in the 8250 serial driver? > #define UPF_FOURPORT (1 << 1) > 232 #define UPF_SAK (1 << 2) > 233 #define UPF_SPD_MASK (0x1030) > 234 #define UPF_SPD_HI (0x0010) > 235 #define UPF_SPD_VHI (0x0020) > 236 #define UPF_SPD_CUST (0x0030) > 237 #define UPF_SPD_SHI (0x1000) > 238 #define UPF_SPD_WARP (0x1010) > 239 #define UPF_SKIP_TEST (1 << 6) > 240 #define UPF_AUTO_IRQ (1 << 7) > 241 #define UPF_HARDPPS_CD (1 << 11) > 242 #define UPF_LOW_LATENCY (1 << 13) > 243 #define UPF_BUGGY_UART (1 << 14) > 244 #define UPF_AUTOPROBE (1 << 15) > 245 #define UPF_MAGIC_MULTIPLIER (1 << 16) > 246 #define UPF_BOOT_ONLYMCA (1 << 22) > 247 #define UPF_CONS_FLOW (1 << 23) > 248 #define UPF_SHARE_IRQ (1 << 24) > 249 #define UPF_BOOT_AUTOCONF (1 << 28) > 250 #define UPF_IOREMAP (1 << 31) Thanks, Ashlesha. From alan@lxorguk.ukuu.org.uk Tue Dec 12 23:07:38 2006 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 12 Dec 2006 23:07:42 +0000 (GMT) Received: from outpipe-village-512-1.bc.nu ([81.2.110.250]:47065 "EHLO lxorguk.ukuu.org.uk") by ftp.linux-mips.org with ESMTP id S20037830AbWLLXHh (ORCPT ); Tue, 12 Dec 2006 23:07:37 +0000 Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by lxorguk.ukuu.org.uk (8.13.8/8.13.4) with ESMTP id kBCNFeji021336; Tue, 12 Dec 2006 23:15:41 GMT Date: Tue, 12 Dec 2006 23:15:40 +0000 From: Alan To: ashlesha@kenati.com Cc: linux-mips@linux-mips.org Subject: Re: 8250 Flag definitions Message-ID: <20061212231540.4dad65e1@localhost.localdomain> In-Reply-To: <1165954142.6539.1.camel@sandbar.kenati.com> References: <1165954142.6539.1.camel@sandbar.kenati.com> X-Mailer: Sylpheed-Claws 2.6.0 (GTK+ 2.8.20; x86_64-redhat-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: 13437 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 On Tue, 12 Dec 2006 12:09:02 -0800 Ashlesha Shintre wrote: > Hi, > > Is there a document that outlines the meaning of these flags in the 8250 > serial driver? Try include/linux/serial.h - each ASYNC_ entry has a comment explaining what it does, and that covers your UP_ stuff fairly completely. From anemo@mba.ocn.ne.jp Wed Dec 13 00:52:22 2006 Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 13 Dec 2006 00:52:26 +0000 (GMT) Received: from topsns2.toshiba-tops.co.jp ([202.230.225.126]:49627 "EHLO topsns2.toshiba-tops.co.jp") by ftp.linux-mips.org with ESMTP id S20039656AbWLMAwW (ORCPT ); Wed, 13 Dec 2006 00:52:22 +0000 Received: from topsms.toshiba-tops.co.jp by topsns2.toshiba-tops.co.jp via smtpd (for ftp.linux-mips.org [194.74.144.162]) with ESMTP; Wed, 13 Dec 2006 09:52:20 +0900 Received: from topsms.toshiba-tops.co.jp (localhost.localdomain [127.0.0.1]) by localhost.toshiba-tops.co.jp (Postfix) with ESMTP id AF77C41DB9; Wed, 13 Dec 2006 09:52:17 +0900 (JST) Received: from srd2sd.toshiba-tops.co.jp (srd2sd.toshiba-tops.co.jp [172.17.28.2]) by topsms.toshiba-tops.co.jp (Postfix) with ESMTP id 9D46721F8F; Wed, 13 Dec 2006 09:52:17 +0900 (JST) Received: from localhost (fragile [172.17.28.65]) by srd2sd.toshiba-tops.co.jp (8.12.10/8.12.10) with ESMTP id kBD0qHW0016324; Wed, 13 Dec 2006 09:52:17 +0900 (JST) (envelope-from anemo@mba.ocn.ne.jp) Date: Wed, 13 Dec 2006 09:52:17 +0900 (JST) Message-Id: <20061213.095217.126574007.nemoto@toshiba-tops.co.jp> To: ths@networkno.de Cc: linux-mips@linux-mips.org, ralf@linux-mips.org Subject: Re: [PATCH] csum_partial and copy in parallel From: Atsushi Nemoto In-Reply-To: <20061212171809.GG21819@networkno.de> References: <20061213.012206.98747230.anemo@mba.ocn.ne.jp> <20061212171809.GG21819@networkno.de> 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 3.3 on Emacs 21.3 / 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: 13438 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 Tue, 12 Dec 2006 17:18:10 +0000, Thiemo Seufer wrote: > > +#define odd t5 > > +#define errptr t6 > > Does this work for 64 bit? t5/t6/t7 look weird for that. Yes. I tested on 32/64 bit, little/big endian. Excerpt from head of csum_partial.S (or memcpy.S): #ifdef CONFIG_64BIT /* * As we are sharing code base with the mips32 tree (which use the o32 ABI * register definitions). We need to redefine the register definitions from * the n64 ABI register naming to the o32 ABI register naming. */ #undef t0 #undef t1 #undef t2 #undef t3 #define t0 $8 #define t1 $9 #define t2 $10 #define t3 $11 #define t4 $12 #define t5 $13 #define t6 $14 #define t7 $15 --- Atsushi Nemoto From rongkai.zhan@windriver.com Wed Dec 13 02:23:30 2006 Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 13 Dec 2006 02:23:37 +0000 (GMT) Received: from mail.windriver.com ([147.11.1.11]:20443 "EHLO mail.wrs.com") by ftp.linux-mips.org with ESMTP id S20039672AbWLMCXa (ORCPT ); Wed, 13 Dec 2006 02:23:30 +0000 Received: from ALA-MAIL03.corp.ad.wrs.com (ala-mail03 [147.11.57.144]) by mail.wrs.com (8.13.6/8.13.3) with ESMTP id kBD2NL5N009351; Tue, 12 Dec 2006 18:23:22 -0800 (PST) Received: from ism-mail01.corp.ad.wrs.com ([128.224.200.18]) by ALA-MAIL03.corp.ad.wrs.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 12 Dec 2006 18:23:21 -0800 Received: from 147.11.233.37 ([147.11.233.37]) by ism-mail01.corp.ad.wrs.com ([128.224.200.18]) via Exchange Front-End Server webmail-na.wrs.com ([147.11.57.147]) with Microsoft Exchange Server HTTP-DAV ; Wed, 13 Dec 2006 02:23:17 +0000 Received: from mark.zhan by webmail-na.wrs.com; 12 Dec 2006 21:23:17 -0500 Subject: Re: Re:hwo to improve a video decoder program's timeslice From: "Mark.Zhan" To: Philippe De Swert Cc: "zzh.hust" , linux-mips In-Reply-To: References: Content-Type: text/plain Content-Transfer-Encoding: 7bit Date: Tue, 12 Dec 2006 21:23:17 -0500 Message-Id: <1165976597.5831.13.camel@localhost.wrs.com> Mime-Version: 1.0 X-Mailer: Evolution 2.6.1 X-OriginalArrivalTime: 13 Dec 2006 02:23:21.0391 (UTC) FILETIME=[A8AADBF0:01C71E5D] 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: 13439 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: rongkai.zhan@windriver.com Precedence: bulk X-list: linux-mips On Mon, 2006-12-11 at 19:10 +0100, Philippe De Swert wrote: > Hi, > > > i have a video decoder program run as aplication > > and i now have change the HZ from 1000 to 100, set the decoder program > > priority as 99. > > Seems you are mixing things here... The HZ change will just change the > interval of the timer tick. For some more explanations about this, look here : > http://kerneltrap.org/node/464 The decrement of the timer tick number definitely can increase the execution time of application. And Disable kernel preemption also has the same impact. > > > if i want to the video decoder program to get more time to run, is > > there any other way to improve it ? > > Maybe using nice? Try "man nice" in a terminal on your Linux box to get more > explanations about this. > > Cheers, > > Philippe--- > Scarlet ONE - Combine ADSL with unlimited fixed phone and save 400 euros > http://www.scarlet.be > > -- Best Regards Mark.Zhan Wind River Beijing Engineer Team From KokHow.Teh@infineon.com Wed Dec 13 10:36:30 2006 Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 13 Dec 2006 10:36:34 +0000 (GMT) Received: from smtp3.infineon.com ([203.126.106.229]:52030 "EHLO smtp3.infineon.com") by ftp.linux-mips.org with ESMTP id S20038807AbWLMKga convert rfc822-to-8bit (ORCPT ); Wed, 13 Dec 2006 10:36:30 +0000 Received: from unknown (HELO sinse301.ap.infineon.com) ([172.20.70.22]) by smtp3.infineon.com with ESMTP; 13 Dec 2006 18:36:11 +0800 X-SBRS: None X-MIMEOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 8BIT Subject: MIPS32v2 toolchain for MIPS32 24KE Core? Date: Wed, 13 Dec 2006 18:36:10 +0800 Message-ID: <5049F8BE55F36348A315EFBE6CF34386E5D89E@sinse301.ap.infineon.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: MIPS32v2 toolchain for MIPS32 24KE Core? Thread-index: AcceooFiwZT6t1TWRpmt/RCd9et/5g== From: To: , Cc: 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: 13440 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: KokHow.Teh@infineon.com Precedence: bulk X-list: linux-mips Hi; Which toolchain can I use to build linux kernel for 24KEc core in order to use MIPS32v2 ISA? "Programming the MIPS32 24KE Core Family" (Document Number MD00458 Revision 1.10 December 21,2005) from MIPS Technologies illustrates the details of programming this core using MIPS32v2 ISA to access into some hardware registers using some extended instructions. One typical critical example that I encounter now is the use of `rdhwr v0, CCRes` that tells you how fast the COUNT register is running. I assumed it to be running at pipeline frequency but in fact it is not. What I do now is to hard-code it to be running at half of the pipeline frequency according to hardware implementation document since the present toolchain that I am using is not supporting this ISA. Assembling `rdhwr v0,CCRes` will result in "opcode not supported at this ISA level (mips2) error. GCC(1) does not give any indication of MIPS32v2 ISA at all. Any advice and insight is appreciated. Regards, KH From ths@networkno.de Wed Dec 13 11:00:04 2006 Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 13 Dec 2006 11:00:09 +0000 (GMT) Received: from phoenix.bawue.net ([193.7.176.60]:19682 "EHLO mail.bawue.net") by ftp.linux-mips.org with ESMTP id S20038715AbWLMLAE (ORCPT ); Wed, 13 Dec 2006 11:00:04 +0000 Received: from lagash (88-106-179-150.dynamic.dsl.as9105.com [88.106.179.150]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by mail.bawue.net (Postfix) with ESMTP id 2EF89B8D49; Wed, 13 Dec 2006 12:02:50 +0100 (CET) Received: from ths by lagash with local (Exim 4.63) (envelope-from ) id 1GuRql-0006S8-Gg; Wed, 13 Dec 2006 11:00:35 +0000 Date: Wed, 13 Dec 2006 11:00:35 +0000 To: KokHow.Teh@infineon.com Cc: linux-mips@linux-mips.org, info@denx.de, Bing-Tao.Xu@infineon.com Subject: Re: MIPS32v2 toolchain for MIPS32 24KE Core? Message-ID: <20061213110035.GA4148@networkno.de> References: <5049F8BE55F36348A315EFBE6CF34386E5D89E@sinse301.ap.infineon.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5049F8BE55F36348A315EFBE6CF34386E5D89E@sinse301.ap.infineon.com> User-Agent: Mutt/1.5.13 (2006-08-11) From: Thiemo Seufer 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: 13441 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 KokHow.Teh@infineon.com wrote: > Hi; > Which toolchain can I use to build linux kernel for 24KEc core > in order to use MIPS32v2 ISA? MIPS32R2 support was added in gcc-3.4.6, as mentioned in the release notes at http://gcc.gnu.org/ Thiemo From dmitry.adamushko@gmail.com Wed Dec 13 11:07:42 2006 Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 13 Dec 2006 11:07:46 +0000 (GMT) Received: from wx-out-0506.google.com ([66.249.82.235]:971 "EHLO wx-out-0506.google.com") by ftp.linux-mips.org with ESMTP id S20038878AbWLMLHm (ORCPT ); Wed, 13 Dec 2006 11:07:42 +0000 Received: by wx-out-0506.google.com with SMTP id t14so136405wxc for ; Wed, 13 Dec 2006 03:07:40 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=E/DxvkccEbnZOcJzbxEt4biowBc+bPorGt5zGTGsasSERaZfvxHj+hjkOtb2PC1j2bljGEwz0WRE/7v+BALwVm6K+zFblsH7HbtN1WbHukQj0Wih4vrPIRgwJm6e6seRlrVxo3sWHViN+TiAyneKxl0bKiGscdxcHvysgwY32IE= Received: by 10.90.103.2 with SMTP id a2mr427497agc.1166008060590; Wed, 13 Dec 2006 03:07:40 -0800 (PST) Received: by 10.90.101.14 with HTTP; Wed, 13 Dec 2006 03:07:40 -0800 (PST) Message-ID: Date: Wed, 13 Dec 2006 12:07:40 +0100 From: "Dmitry Adamushko" To: linux-mips@linux-mips.org Subject: unwind_stack() and an exception at the last instruction (after the epilogue) Cc: "Ralf Baechle" , "Dmitry Adamushko" In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline 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: 13442 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: dmitry.adamushko@gmail.com Precedence: bulk X-list: linux-mips [ resend: probably, my previouse one had been rejected as it was not in plain-text :] Hello, unwind_stack() explicitly handles a case when an exception takes place at the first instruction, i.e. before the prologue. But what's about another corner case - when an exception is caused by an instruction placed after the epilogue. example: 00400e8c : 400e8c: 3c1c0fc0 lui gp,0xfc0 400e90: 279c71c4 addiu gp,gp,29124 400e94: 0399e021 addu gp,gp,t9 400e98: 27bdffe0 addiu sp,sp,-32 400e9c: afbf0018 sw ra,24(sp) 400ea0: afbc0010 sw gp,16(sp) 400ea4: 8f84801c lw a0,-32740(gp) 400ea8: 8f9980ac lw t9,-32596(gp) 400eac: 00000000 nop 400eb0: 0320f809 jalr t9 400eb4: 24841984 addiu a0,a0,6532 400eb8: 8fbc0010 lw gp,16(sp) 400ebc: 8fbf0018 lw ra,24(sp) 400ec0: 27bd0020 addiu sp,sp,32 400ec4: 03e00008 jr ra 400ec8: ac000000 sw zero,0(zero) <----------- will be here when an exception happens In this case, already points to the caller's stack frame so unwind_stack() will take a wrong assumption (as it looks at the epilogue of the callee). btw, the first and last instructions are just corner cases of an instruction being placed before the prologue and after the epilogue, right? so something like - if (unlikely(ofs == 0)) { + if (unlikely(offs == 0 || offs == size - sizeof_mips_instruction)) pc = *ra; *ra = 0; return pc; } won't be a generic solution. Did I miss something? Hm... is always guaranted to be right when the instruction is in the branch delay slot? p.s. yep, the example is a part of user-space code (optimization: -Os) or is there anything (compiler options etc.) preventing similar code from being generated for kernel-space code? Thanks in advance for any comments. -- Best regards, Dmitry Adamushko From ths@networkno.de Wed Dec 13 12:02:07 2006 Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 13 Dec 2006 12:02:12 +0000 (GMT) Received: from phoenix.bawue.net ([193.7.176.60]:36541 "EHLO mail.bawue.net") by ftp.linux-mips.org with ESMTP id S20037491AbWLMMCH (ORCPT ); Wed, 13 Dec 2006 12:02:07 +0000 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 5B004BAA6D; Wed, 13 Dec 2006 12:56:53 +0100 (CET) Received: from ths by lagash with local (Exim 4.63) (envelope-from ) id 1GuSh4-0006pO-U2; Wed, 13 Dec 2006 11:54:38 +0000 Date: Wed, 13 Dec 2006 11:54:38 +0000 To: Dmitry Adamushko Cc: linux-mips@linux-mips.org, Ralf Baechle Subject: Re: unwind_stack() and an exception at the last instruction (after the epilogue) Message-ID: <20061213115438.GA25904@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.13 (2006-08-11) From: Thiemo Seufer 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: 13443 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 Dmitry Adamushko wrote: > [ resend: probably, my previouse one had been rejected as it was not > in plain-text :] > > > Hello, > > unwind_stack() explicitly handles a case when an exception takes > place at the first instruction, i.e. before the prologue. > > But what's about another corner case - when an exception is caused by > an instruction placed after the epilogue. > > example: > > 00400e8c : > 400e8c: 3c1c0fc0 lui gp,0xfc0 > 400e90: 279c71c4 addiu gp,gp,29124 > 400e94: 0399e021 addu gp,gp,t9 > 400e98: 27bdffe0 addiu sp,sp,-32 > 400e9c: afbf0018 sw ra,24(sp) > 400ea0: afbc0010 sw gp,16(sp) > 400ea4: 8f84801c lw a0,-32740(gp) > 400ea8: 8f9980ac lw t9,-32596(gp) > 400eac: 00000000 nop > 400eb0: 0320f809 jalr t9 > 400eb4: 24841984 addiu a0,a0,6532 > 400eb8: 8fbc0010 lw gp,16(sp) > 400ebc: 8fbf0018 lw ra,24(sp) > 400ec0: 27bd0020 addiu sp,sp,32 > 400ec4: 03e00008 jr ra > 400ec8: ac000000 sw zero,0(zero) > <----------- will be here when an exception happens Was this example generated by a real world compiler? (Which one?) > In this case, already points to the caller's stack frame so > unwind_stack() will take a wrong assumption (as it looks at the > epilogue of the callee). > > btw, the first and last instructions are just corner cases of an > instruction being placed before the prologue and after the epilogue, > right? > > so something like > > - if (unlikely(ofs == 0)) { > + if (unlikely(offs == 0 || offs == size - sizeof_mips_instruction)) > pc = *ra; > *ra = 0; > return pc; > } > > won't be a generic solution. > > Did I miss something? Hm... is always guaranted to be right > when the instruction is in the branch delay slot? > > p.s. yep, the example is a part of user-space code (optimization: > -Os) or is there anything (compiler options etc.) preventing similar > code from being generated for kernel-space code? I'm inclined to claim the example is broken WRT ABI rules since it doesn't enclose the whole user code in the prologue/epilogue bracket. Thiemo From dmitry.adamushko@gmail.com Wed Dec 13 12:45:57 2006 Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 13 Dec 2006 12:46:01 +0000 (GMT) Received: from wr-out-0506.google.com ([64.233.184.232]:51789 "EHLO wr-out-0506.google.com") by ftp.linux-mips.org with ESMTP id S20038893AbWLMMp5 (ORCPT ); Wed, 13 Dec 2006 12:45:57 +0000 Received: by wr-out-0506.google.com with SMTP id i32so40858wra for ; Wed, 13 Dec 2006 04:45:56 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=IzYfJ0P6sZvo5oh/UtrERrjtKkZA2lhlntPj5W2Gw2XLhi4EQxMVDLwIrAbpO2/aEBWeRTy8yX/54eGUJB797pO7NCcpKcrdjn3O2hy5qrKhGqKCT9OU9fM0ItjhnDYpX1sWbEOn4jnxcRv4QkjrTPHtH0x4bIheC2tBEh/SkkY= Received: by 10.90.63.16 with SMTP id l16mr582397aga.1166013955840; Wed, 13 Dec 2006 04:45:55 -0800 (PST) Received: by 10.90.101.14 with HTTP; Wed, 13 Dec 2006 04:45:55 -0800 (PST) Message-ID: Date: Wed, 13 Dec 2006 13:45:55 +0100 From: "Dmitry Adamushko" To: "Thiemo Seufer" Subject: Re: unwind_stack() and an exception at the last instruction (after the epilogue) Cc: "Ralf Baechle" , linux-mips@linux-mips.org In-Reply-To: <20061213115438.GA25904@networkno.de> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <20061213115438.GA25904@networkno.de> 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: 13444 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: dmitry.adamushko@gmail.com Precedence: bulk X-list: linux-mips > Was this example generated by a real world compiler? (Which one?) [adamushkad@cplx219]/>mips-linux-uclibc-gcc -v Reading specs from /vobs/linux/tools/mips/gcc-3.4.2/bin/../lib/gcc/mips-linux-uclibc/3.4.2/specs Configured with: /vobs/linux/tools/buildroot/toolchain_build_mips/gcc-3.4.2/configure --prefix=/vobs/linux/tools/buildroot/build_mips/staging_dir --build=i386-pc-linux-gnu --host=i386-pc-linux-gnu --target=mips-linux-uclibc --enable-languages=c,c++ --enable-shared --disable-__cxa_atexit --enable-target-optspace -with-gnu-ld --disable-nls --enable-multilib Thread model: posix gcc version 3.4.2 > I'm inclined to claim the example is broken WRT ABI rules since it > doesn't enclose the whole user code in the prologue/epilogue bracket. > It's o32. So it explicitly requires that when the prologue and epilogue have been used in the function, all the user code must be place in between, right? In this light, the unlike(ofs == 0) in unwind_stack() aims at catching cases when is wrong (if addiu sp,sp,OFFSET is normally the very first instruction) ok, here is an example from kernel/sched.o (the same compiler). 00000098 : 98: 8c820018 lw v0,24(a0) <----- before the prologue 9c: 27bdfff8 addiu sp,sp,-8 a0: afbe0000 sw s8,0(sp) a4: 000210c0 sll v0,v0,0x3 a8: 00a21021 addu v0,a1,v0 ac: 24420018 addiu v0,v0,24 b0: 8c460004 lw a2,4(v0) b4: 24830020 addiu v1,a0,32 b8: ac430004 sw v1,4(v0) bc: ac820020 sw v0,32(a0) c0: ac660004 sw a2,4(v1) c4: acc30000 sw v1,0(a2) c8: 8c860018 lw a2,24(a0) cc: 24a70004 addiu a3,a1,4 d0: 03a0f021 move s8,sp d4: 00061142 srl v0,a2,0x5 d8: 00021080 sll v0,v0,0x2 dc: 00e23821 addu a3,a3,v0 e0: 8ce30000 lw v1,0(a3) e4: 30c6001f andi a2,a2,0x1f e8: 24020001 li v0,1 ec: 00c21004 sllv v0,v0,a2 f0: 00621825 or v1,v1,v0 f4: ace30000 sw v1,0(a3) f8: 8ca20000 lw v0,0(a1) fc: 03c0e821 move sp,s8 100: 8fbe0000 lw s8,0(sp) 104: 24420001 addiu v0,v0,1 108: 27bd0008 addiu sp,sp,8 10c: aca20000 sw v0,0(a1) 110: 03e00008 jr ra 114: ac850028 sw a1,40(a0) <------------ after the epilogue As I can see, normally this compiler places "addiu sp,sp,FRAME_SIZE" at the branch delay slot of "jr ra" but e.g. enqueue_task() (example above) and request_task() are exceptions. btw, the very first instruction is also placed before the epilogue. Are there any configure options that might have caused such a behaviour [hmmm... e.g. gcc was configured with --ignore-abi-rulles :] ? Although, I don't think this would be an option-dependent case. > Thiemo > -- Best regards, Dmitry Adamushko From ths@networkno.de Wed Dec 13 13:54:53 2006 Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 13 Dec 2006 13:54:58 +0000 (GMT) Received: from phoenix.bawue.net ([193.7.176.60]:33241 "EHLO mail.bawue.net") by ftp.linux-mips.org with ESMTP id S20038878AbWLMNyx (ORCPT ); Wed, 13 Dec 2006 13:54:53 +0000 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 77D45BB0C1; Wed, 13 Dec 2006 14:54:37 +0100 (CET) Received: from ths by lagash with local (Exim 4.63) (envelope-from ) id 1GuUX0-0007eI-8c; Wed, 13 Dec 2006 13:52:22 +0000 Date: Wed, 13 Dec 2006 13:52:22 +0000 From: Thiemo Seufer To: Dmitry Adamushko Cc: Ralf Baechle , linux-mips@linux-mips.org Subject: Re: unwind_stack() and an exception at the last instruction (after the epilogue) Message-ID: <20061213135222.GB25904@networkno.de> References: <20061213115438.GA25904@networkno.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: 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: 13445 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 Dmitry Adamushko wrote: > >Was this example generated by a real world compiler? (Which one?) > > [adamushkad@cplx219]/>mips-linux-uclibc-gcc -v > Reading specs from > /vobs/linux/tools/mips/gcc-3.4.2/bin/../lib/gcc/mips-linux-uclibc/3.4.2/specs > Configured with: > /vobs/linux/tools/buildroot/toolchain_build_mips/gcc-3.4.2/configure > --prefix=/vobs/linux/tools/buildroot/build_mips/staging_dir > --build=i386-pc-linux-gnu > --host=i386-pc-linux-gnu > --target=mips-linux-uclibc > --enable-languages=c,c++ > --enable-shared > --disable-__cxa_atexit > --enable-target-optspace > -with-gnu-ld > --disable-nls > --enable-multilib > Thread model: posix > > gcc version 3.4.2 I figure it doesn't create such an zero access as shown in the example. > >I'm inclined to claim the example is broken WRT ABI rules since it > >doesn't enclose the whole user code in the prologue/epilogue bracket. > > > > It's o32. So it explicitly requires that when the prologue and > epilogue have been used in the function, all the user code must be > place in between, right? That's basically the definition of "prologue" and "epilogue". > In this light, the unlike(ofs == 0) in unwind_stack() aims at catching > cases when is wrong (if addiu sp,sp,OFFSET is normally the very > first instruction) Technically it is probably ok, since the o32 ABI covers only PIC code, while the kernel is non-PIC. > ok, here is an example from kernel/sched.o (the same compiler). > > 00000098 : > 98: 8c820018 lw v0,24(a0) <----- before the > prologue > 9c: 27bdfff8 addiu sp,sp,-8 > a0: afbe0000 sw s8,0(sp) > a4: 000210c0 sll v0,v0,0x3 > a8: 00a21021 addu v0,a1,v0 > ac: 24420018 addiu v0,v0,24 > b0: 8c460004 lw a2,4(v0) > b4: 24830020 addiu v1,a0,32 > b8: ac430004 sw v1,4(v0) > bc: ac820020 sw v0,32(a0) > c0: ac660004 sw a2,4(v1) > c4: acc30000 sw v1,0(a2) > c8: 8c860018 lw a2,24(a0) > cc: 24a70004 addiu a3,a1,4 > d0: 03a0f021 move s8,sp > d4: 00061142 srl v0,a2,0x5 > d8: 00021080 sll v0,v0,0x2 > dc: 00e23821 addu a3,a3,v0 > e0: 8ce30000 lw v1,0(a3) > e4: 30c6001f andi a2,a2,0x1f > e8: 24020001 li v0,1 > ec: 00c21004 sllv v0,v0,a2 > f0: 00621825 or v1,v1,v0 > f4: ace30000 sw v1,0(a3) > f8: 8ca20000 lw v0,0(a1) > fc: 03c0e821 move sp,s8 > 100: 8fbe0000 lw s8,0(sp) > 104: 24420001 addiu v0,v0,1 > 108: 27bd0008 addiu sp,sp,8 > 10c: aca20000 sw v0,0(a1) > 110: 03e00008 jr ra > 114: ac850028 sw a1,40(a0) <------------ > after the epilogue It looks rather broken, given that the stack frame is only used to pointlessly push s8 around. The compiler should have optimized it away. > As I can see, normally this compiler places "addiu sp,sp,FRAME_SIZE" > at the branch delay slot of "jr ra" but e.g. enqueue_task() (example > above) and request_task() are exceptions. btw, the very first > instruction is also placed before the epilogue. > > Are there any configure options that might have caused such a > behaviour [hmmm... e.g. gcc was configured with --ignore-abi-rulles :] > ? Although, I don't think this would be an option-dependent case. Well, breakage happens from time to time in gcc. To cover such cases it would be nice to have a more robust stack unwinder, but that's easier said than done. Thiemo From dmitry.adamushko@gmail.com Wed Dec 13 14:40:25 2006 Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 13 Dec 2006 14:40:29 +0000 (GMT) Received: from wr-out-0506.google.com ([64.233.184.231]:63741 "EHLO wr-out-0506.google.com") by ftp.linux-mips.org with ESMTP id S20038940AbWLMOkZ (ORCPT ); Wed, 13 Dec 2006 14:40:25 +0000 Received: by wr-out-0506.google.com with SMTP id i32so62041wra for ; Wed, 13 Dec 2006 06:40:21 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=ZkXKIFYsC9RR13cjkt2snGqBSJh11khefZ954ceuDZI17ppGwffOrdCnpqCa7MQXgm6Hs4qFNq/tmnlCaB4ahFK/pAcqQtoJhz4zI4428/oqVPbvBG4e1JyXSdX3VxH+TW2BCyoVLBaLXk0bUC0N8/pN8ROCh/Fh+bmbFrf13TU= Received: by 10.90.52.2 with SMTP id z2mr781362agz.1166020821564; Wed, 13 Dec 2006 06:40:21 -0800 (PST) Received: by 10.90.101.14 with HTTP; Wed, 13 Dec 2006 06:40:21 -0800 (PST) Message-ID: Date: Wed, 13 Dec 2006 15:40:21 +0100 From: "Dmitry Adamushko" To: "Thiemo Seufer" Subject: Re: unwind_stack() and an exception at the last instruction (after the epilogue) Cc: "Ralf Baechle" , linux-mips@linux-mips.org In-Reply-To: <20061213135222.GB25904@networkno.de> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <20061213115438.GA25904@networkno.de> <20061213135222.GB25904@networkno.de> 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: 13446 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: dmitry.adamushko@gmail.com Precedence: bulk X-list: linux-mips > > gcc version 3.4.2 > > I figure it doesn't create such an zero access as shown in the example. the code in question intentionally dereferenced a NULL pointer. the funny thing is that when it's like this : void cause_oops(void) { unsigned long *addr = NULL; printf("Let's crash..."); // (1) *addr = 0; // (2) } the compiler (-g -Os) generates the code as I have sent before, iow with "sw zero, 0(zero)" in the delay slot [see, the compiler is kindof smart as it elimimates a need to store "addr" on stack :] But if I change the order of (1) and (2), the generated code is different 00401364 : 401364: 3c1c0fc0 lui gp,0xfc0 401368: 279c6cec addiu gp,gp,27884 40136c: 0399e021 addu gp,gp,t9 401370: 8f84801c lw a0,-32740(gp) 401374: 8f9980b0 lw t9,-32592(gp) 401378: ac000000 sw zero,0(zero) 40137c: 03200008 jr t9 401380: 24842010 addiu a0,a0,8208 So the "prologue" and "epilogue" are omitted, that's good. > > It looks rather broken, given that the stack frame is only used to > pointlessly push s8 around. The compiler should have optimized it away. Yes, all the "broken" functions (there are a few in sched.o) have at least one thing in common - they don't use stack at all, aside of storing the frame pointer (s8). > > Are there any configure options that might have caused such a > > behaviour [hmmm... e.g. gcc was configured with --ignore-abi-rulles :] > > ? Although, I don't think this would be an option-dependent case. > > Well, breakage happens from time to time in gcc. To cover such cases > it would be nice to have a more robust stack unwinder, but that's easier > said than done. Yep, but this would add additional complexity which is not that necessary for the common path. e.g. as we know the start and end address of the function (ksyms_lookup_size_off()), it's possible to find out a position of the "prologue" and "epilogue" (addiu sp,sp,SIZE - the same way it's done in get_frame_info()) so we would know: function_start (1), prologue_addr (2), epilogue_addr (3), function_end (4) and this would cover the (broken) cases when is in [1, 2] or [3, 4] as well as the cases when e.g. is broken in the prologue ? Anyway, thanks for the conversation. > > Thiemo > -- Best regards, Dmitry Adamushko From anemo@mba.ocn.ne.jp Wed Dec 13 16:16:56 2006 Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 13 Dec 2006 16:17:01 +0000 (GMT) Received: from mba.ocn.ne.jp ([210.190.142.172]:54518 "HELO smtp.mba.ocn.ne.jp") by ftp.linux-mips.org with SMTP id S20038926AbWLMQQ4 (ORCPT ); Wed, 13 Dec 2006 16:16:56 +0000 Received: from localhost (p2025-ipad210funabasi.chiba.ocn.ne.jp [58.88.121.25]) by smtp.mba.ocn.ne.jp (Postfix) with ESMTP id 399E5C0AA; Thu, 14 Dec 2006 01:16:52 +0900 (JST) Date: Thu, 14 Dec 2006 01:16:51 +0900 (JST) Message-Id: <20061214.011651.31638583.anemo@mba.ocn.ne.jp> To: dmitry.adamushko@gmail.com Cc: ths@networkno.de, ralf@linux-mips.org, linux-mips@linux-mips.org Subject: Re: unwind_stack() and an exception at the last instruction (after the epilogue) From: Atsushi Nemoto In-Reply-To: References: <20061213135222.GB25904@networkno.de> 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 3.3 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: 13447 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 Wed, 13 Dec 2006 15:40:21 +0100, "Dmitry Adamushko" wrote: > e.g. as we know the start and end address of the function > (ksyms_lookup_size_off()), it's possible to find out a position of the > "prologue" and "epilogue" (addiu sp,sp,SIZE - the same way it's done > in get_frame_info()) so we would know: > > function_start (1), prologue_addr (2), epilogue_addr (3), function_end (4) > > and this would cover the (broken) cases when is in [1, 2] or [3, 4] > as well as the cases when e.g. is broken in the prologue ? It would be hard because: * A function can have multiple epilogues. * gcc often moves "if" block codes to end of the function. While current unwind_stack() is not perfect, any attempt to make it robust is welcome. But you might have to analyze _all_ code if you wanted to save _all_ case. I think UNIX's "90% principle" is good enough here. BTW, enqueue_task() will not use stack anymore since SCHED_NO_NO_OMIT_FRAME_POINTER is defined. --- Atsushi Nemoto From bcasavan@sgi.com Wed Dec 13 22:06:27 2006 Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 13 Dec 2006 22:06:32 +0000 (GMT) Received: from omx2-ext.sgi.com ([192.48.171.19]:38618 "EHLO omx2.sgi.com") by ftp.linux-mips.org with ESMTP id S20038836AbWLMWG1 (ORCPT ); Wed, 13 Dec 2006 22:06:27 +0000 Received: from internal-mail-relay1.corp.sgi.com (internal-mail-relay1.corp.sgi.com [198.149.32.52]) by omx2.sgi.com (8.12.11/8.12.9/linux-outbound_gateway-1.1) with ESMTP id kBE0sak0004438; Wed, 13 Dec 2006 16:54:36 -0800 Received: from pkunk.americas.sgi.com (pkunk.americas.sgi.com [128.162.232.31]) by internal-mail-relay1.corp.sgi.com (8.12.9/8.12.10/SGI_generic_relay-1.2) with ESMTP id kBDM6Nbk64641162; Wed, 13 Dec 2006 14:06:23 -0800 (PST) Date: Wed, 13 Dec 2006 16:06:23 -0600 (CST) From: Brent Casavant Reply-To: Brent Casavant To: linux-kernel@vger.kernel.org cc: linux-mips@linux-mips.org, Pat Gefre , Stanislaw Skowronek Subject: [PATCH] IOC3/IOC4: PCI mem space resources Message-ID: <20061213155832.C56992@pkunk.americas.sgi.com> Organization: Silicon Graphics, Inc. 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: 13448 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: bcasavan@sgi.com Precedence: bulk X-list: linux-mips The SGI IOC3 and IOC4 PCI devices implement memory space apertures, not I/O space apertures. Use the appropriate region management functions. Signed-off-by: Brent Casavant --- I'd appreciate a review/ack by the MIPS folks, just in case I'm unaware of something special on those systems. misc/ioc4.c | 6 +++--- serial/ioc4_serial.c | 6 +++--- sn/ioc3.c | 6 +++--- 3 files changed, 9 insertions(+), 9 deletions(-) --- diff --git a/drivers/misc/ioc4.c b/drivers/misc/ioc4.c index b995a15..6a5a05d 100644 --- a/drivers/misc/ioc4.c +++ b/drivers/misc/ioc4.c @@ -309,7 +309,7 @@ ioc4_probe(struct pci_dev *pdev, const s ret = -ENODEV; goto out_pci; } - if (!request_region(idd->idd_bar0, sizeof(struct ioc4_misc_regs), + if (!request_mem_region(idd->idd_bar0, sizeof(struct ioc4_misc_regs), "ioc4_misc")) { printk(KERN_WARNING "%s: Unable to request IOC4 misc region " @@ -379,7 +379,7 @@ ioc4_probe(struct pci_dev *pdev, const s return 0; out_misc_region: - release_region(idd->idd_bar0, sizeof(struct ioc4_misc_regs)); + release_mem_region(idd->idd_bar0, sizeof(struct ioc4_misc_regs)); out_pci: kfree(idd); out_idd: @@ -418,7 +418,7 @@ ioc4_remove(struct pci_dev *pdev) "Device removal may be incomplete.\n", __FUNCTION__, pci_name(idd->idd_pdev)); } - release_region(idd->idd_bar0, sizeof(struct ioc4_misc_regs)); + release_mem_region(idd->idd_bar0, sizeof(struct ioc4_misc_regs)); /* Disable IOC4 and relinquish */ pci_disable_device(pdev); diff --git a/drivers/serial/ioc4_serial.c b/drivers/serial/ioc4_serial.c index c862f67..f540212 100644 --- a/drivers/serial/ioc4_serial.c +++ b/drivers/serial/ioc4_serial.c @@ -2685,7 +2685,7 @@ static int ioc4_serial_remove_one(struct free_irq(control->ic_irq, soft); if (soft->is_ioc4_serial_addr) { iounmap(soft->is_ioc4_serial_addr); - release_region((unsigned long) + release_mem_region((unsigned long) soft->is_ioc4_serial_addr, sizeof(struct ioc4_serial)); } @@ -2790,7 +2790,7 @@ ioc4_serial_attach_one(struct ioc4_drive /* request serial registers */ tmp_addr1 = idd->idd_bar0 + IOC4_SERIAL_OFFSET; - if (!request_region(tmp_addr1, sizeof(struct ioc4_serial), + if (!request_mem_region(tmp_addr1, sizeof(struct ioc4_serial), "sioc4_uart")) { printk(KERN_WARNING "ioc4 (%p): unable to get request region for " @@ -2889,7 +2889,7 @@ out3: out2: if (serial) iounmap(serial); - release_region(tmp_addr1, sizeof(struct ioc4_serial)); + release_mem_region(tmp_addr1, sizeof(struct ioc4_serial)); out1: return ret; diff --git a/drivers/sn/ioc3.c b/drivers/sn/ioc3.c index cd6b653..2dd6eed 100644 --- a/drivers/sn/ioc3.c +++ b/drivers/sn/ioc3.c @@ -654,7 +654,7 @@ #endif ret = -ENODEV; goto out_pci; } - if (!request_region(idd->pma, IOC3_PCI_SIZE, "ioc3")) { + if (!request_mem_region(idd->pma, IOC3_PCI_SIZE, "ioc3")) { printk(KERN_WARNING "%s: Unable to request IOC3 region " "for pci_dev %s.\n", @@ -744,7 +744,7 @@ #endif return 0; out_misc_region: - release_region(idd->pma, IOC3_PCI_SIZE); + release_mem_region(idd->pma, IOC3_PCI_SIZE); out_pci: kfree(idd); out_idd: @@ -785,7 +785,7 @@ static void ioc3_remove(struct pci_dev * if(idd->dual_irq) free_irq(idd->irq_eth, (void *)idd); iounmap(idd->vma); - release_region(idd->pma, IOC3_PCI_SIZE); + release_mem_region(idd->pma, IOC3_PCI_SIZE); /* Disable IOC3 and relinquish */ pci_disable_device(pdev); From ralf@linux-mips.org Thu Dec 14 02:05:43 2006 Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 14 Dec 2006 02:05:45 +0000 (GMT) Received: from localhost.localdomain ([127.0.0.1]:15784 "EHLO dl5rb.ham-radio-op.net") by ftp.linux-mips.org with ESMTP id S20039733AbWLNCFn (ORCPT ); Thu, 14 Dec 2006 02:05:43 +0000 Received: from denk.linux-mips.net (denk.linux-mips.net [127.0.0.1]) by dl5rb.ham-radio-op.net (8.13.8/8.13.8) with ESMTP id kBE1l6bj004659; Thu, 14 Dec 2006 01:47:06 GMT Received: (from ralf@localhost) by denk.linux-mips.net (8.13.8/8.13.8/Submit) id kBE1l4DH004657; Thu, 14 Dec 2006 02:47:04 +0100 Date: Thu, 14 Dec 2006 02:47:04 +0100 From: Ralf Baechle To: Atsushi Nemoto Cc: dmitry.adamushko@gmail.com, ths@networkno.de, linux-mips@linux-mips.org Subject: Re: unwind_stack() and an exception at the last instruction (after the epilogue) Message-ID: <20061214014704.GA984@linux-mips.org> References: <20061213135222.GB25904@networkno.de> <20061214.011651.31638583.anemo@mba.ocn.ne.jp> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20061214.011651.31638583.anemo@mba.ocn.ne.jp> User-Agent: Mutt/1.4.2.2i 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: 13449 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, Dec 14, 2006 at 01:16:51AM +0900, Atsushi Nemoto wrote: > While current unwind_stack() is not perfect, any attempt to make it > robust is welcome. But you might have to analyze _all_ code if you > wanted to save _all_ case. I think UNIX's "90% principle" is good > enough here. If the current unwinder should ever become a problem we have the option of the DWARF2-based unwinder as backup. Ralf From tux-master@web.de Thu Dec 14 20:40:13 2006 Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 14 Dec 2006 20:40:19 +0000 (GMT) Received: from fmmailgate03.web.de ([217.72.192.234]:23474 "EHLO fmmailgate03.web.de") by ftp.linux-mips.org with ESMTP id S20038981AbWLNUkN (ORCPT ); Thu, 14 Dec 2006 20:40:13 +0000 Received: from smtp05.web.de (fmsmtp05.dlan.cinetic.de [172.20.4.166]) by fmmailgate03.web.de (Postfix) with ESMTP id 853F2462813B; Thu, 14 Dec 2006 21:40:07 +0100 (CET) Received: from [84.180.143.59] (helo=pluto.sol) by smtp05.web.de with asmtp (TLSv1:AES256-SHA:256) (WEB.DE 4.107 #114) id 1GuxN7-0005AS-00; Thu, 14 Dec 2006 21:40:06 +0100 Received: from jens by pluto.sol with local (Exim 4.63) (envelope-from ) id 1GuxIl-0004pA-NB; Thu, 14 Dec 2006 21:35:35 +0100 Date: Thu, 14 Dec 2006 21:35:35 +0100 From: Jens Seidel To: linux-mips@linux-mips.org Subject: SGI Octane kernel patches fail Message-ID: <20061214203535.GA18511@pluto> Reply-To: linux-mips@linux-mips.org, Jens Seidel Mail-Followup-To: linux-mips@linux-mips.org, Jens Seidel MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.13 (2006-08-11) X-Sender: tux-master@web.de 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: 13450 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: jensseidel@users.sf.net Precedence: bulk X-list: linux-mips Hi, I have a SGI Octane IP30 and was able to boot Linux on it with the ip30-r10k+-20050128.img Gentoo kernel. Nevertheless I noticed that this kernel is very unstable. Once I was lucky and able to bootstrap Debian before the kernel paniced again (usually a "unaligned instruction access in arch/mips/kernel/unaligned.c::do_ade, line 544[#3]"). I tried to compile a newer 2.6.19-rc1 kernel and applied the two IOC3 and IP30 patches from ftp://ftp.linux-mips.org/pub/linux/mips/people/skylark/. First of all the patch fails slightly and needs manual adjustments. Compiling results in an error, do_IRQ() is called with only one parameter instead of two. So I wonder what kernels are compatible with linux-mips-2.6.19-rc1-ip30-r28.patch.bz2. Do I need other patches as well? Also the kernel config file skylark-approved-config-tm in skylark/ is out of date. It seems to match a 2.6.12 or similar version. PS: Please CC: me. Jens From geoman@gentoo.org Thu Dec 14 22:40:30 2006 Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 14 Dec 2006 22:40:35 +0000 (GMT) Received: from lennier.cc.vt.edu ([198.82.162.213]:17848 "EHLO lennier.cc.vt.edu") by ftp.linux-mips.org with ESMTP id S20039086AbWLNWka (ORCPT ); Thu, 14 Dec 2006 22:40:30 +0000 Received: from vivi.cc.vt.edu (IDENT:mirapoint@evil-vivi.cc.vt.edu [10.1.1.12]) by lennier.cc.vt.edu (8.12.11.20060308/8.12.11) with ESMTP id kBEMckk9029026; Thu, 14 Dec 2006 17:40:31 -0500 Received: from authsmtp1.cc.vt.edu (auth.smtp.vt.edu [198.82.161.56]) by vivi.cc.vt.edu (MOS 3.8.2-GA) with ESMTP id GQW41692; Thu, 14 Dec 2006 17:40:22 -0500 (EST) Received: from gs4073.geos.vt.edu (gs4073.geos.vt.edu [128.173.184.73]) (authenticated bits=0) by authsmtp1.cc.vt.edu (8.13.1/8.13.1) with ESMTP id kBEMeL2d025869; Thu, 14 Dec 2006 17:40:22 -0500 Date: Thu, 14 Dec 2006 17:39:35 -0500 From: "Stephen P. Becker" To: linux-mips@linux-mips.org Cc: Jens Seidel Subject: Re: SGI Octane kernel patches fail Message-ID: <20061214173935.485faba6@gs4073.geos.vt.edu> In-Reply-To: <20061214203535.GA18511@pluto> References: <20061214203535.GA18511@pluto> Organization: Gentoo Linux X-Mailer: Sylpheed-Claws 2.6.0 (GTK+ 2.10.6; i686-pc-linux-gnu) X-Face: SZkgO{p^G't0]8U]p8b=DtT,_0Hz?S)hKCI\sEHZRAdrYo?=`'CDw8uu-Mpo(x;@%XjW]VR euvbMM4Iixr>@Wxy?~f]4@1uGNlXGT0!AC[b{1R>:@]U~bPf8(Jcg8C&H}<7dM!Q2p/C\tw4vUb{he PZ&oWm&Pr#hRGa*=ReoPd,mbd_X/-yCj\-Ya{7j7Dkg)5bA&1!c,~8V/7lBGlF?6;fBJ):7sjgT0\= Jre""/n'zX=E==KMA{k&pBLm,c*Y0 Mime-Version: 1.0 Content-Type: multipart/signed; boundary=Sig_oiST9PxXCNTLbVGhB8ro.zw; protocol="application/pgp-signature"; micalg=PGP-SHA1 X-Junkmail-Status: score=10/50, host=vivi.cc.vt.edu X-Junkmail-SD-Raw: score=unknown, refid=str=0001.0A090207.4581D197.00A1:SCCEO16322,ss=1,fgs=0, ip=198.82.161.56, so=2006-09-22 03:48:54, dmn=5.2.121/2006-09-27 X-Mirapoint-RAPID-Raw: score=unknown(0), refid=str=0001.0A090207.4581D197.00A1:SCCEO16322,ss=1,fgs=0, ip=198.82.161.56, so=2006-09-22 03:48:54, dmn=5.2.121/2006-09-27 X-Mirapoint-Loop-Id: f8a8173ab3592955c342fb77a2fd2cd6 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: 13451 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: geoman@gentoo.org Precedence: bulk X-list: linux-mips --Sig_oiST9PxXCNTLbVGhB8ro.zw Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable On Thu, 14 Dec 2006 21:35:35 +0100 Jens Seidel wrote: > Hi, >=20 > I have a SGI Octane IP30 and was able to boot Linux on it with the > ip30-r10k+-20050128.img Gentoo kernel. Nevertheless I noticed that > this kernel is very unstable. Yes, that kernel is ancient and known to be totally broken. Try http://dev.gentoo.org/~kumba/mips/netboot/testing/ip30-r10k+-20060112.img.b= z2 instead. -Steve --Sig_oiST9PxXCNTLbVGhB8ro.zw Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFFgdKsHyvOE7OTyFYRAlidAJ4n0glAGH6xSd0yjQn3gF9UiBwA0wCghv5u 91tIqH1vVHpIZMrDk+VcjKU= =5tAM -----END PGP SIGNATURE----- --Sig_oiST9PxXCNTLbVGhB8ro.zw-- From elmar.gerdes@engel-kg.com Thu Dec 14 22:51:33 2006 Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 14 Dec 2006 22:51:37 +0000 (GMT) Received: from mail.engel-kg.com ([212.6.249.86]:33264 "EHLO centauri.engel-kg.com") by ftp.linux-mips.org with ESMTP id S20039828AbWLNWvd (ORCPT ); Thu, 14 Dec 2006 22:51:33 +0000 Received: from pogo.engel-kg.com (sirius.engel-kg.com [192.168.3.112]) by centauri.engel-kg.com (Postfix) with ESMTP id 22A8BB860; Thu, 14 Dec 2006 23:51:27 +0100 (CET) Date: Thu, 14 Dec 2006 23:47:10 +0100 (CET) From: elmar gerdes To: linux-usb-devel@lists.sourceforge.net cc: linux-mips@linux-mips.org Subject: Question on UDC driver for the Alchemy Au1550 Message-ID: <20061214234250.Q13369@pogo.engel-kg.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed 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: 13452 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: elmar.gerdes@engel-kg.com Precedence: bulk X-list: linux-mips Hi folks, to make this short: Is anybody working on a UDC driver for the Alchemy Au1550 (MIPS-based)? If you are interested in details, please read on: I'm working with an Au1550-based board and would like to run it as a USB device. There have been a few drivers around for Au1xxx-based boards, but none of them seems to be adequate for this processor (or else I missed something...): a) in the kernel tree: arch/mips/au1000/common/usbdev.c This one was for Au1000, Au1100, and Au1500 IIRC. But it didn't even compile for quite some kernel versions and now it has been removed from the tree. b1) drivers/usb/gadget/au1200udc.c This driver hasn't made it (yet) into the kernel tree. I grabbed it from some postings to linux-usb-devel, but it's for the Au1200 (and Geode LX companion chip). b2) drivers/usb/gadget/amd5536udc.c from RMI. This looks very similar to the au1200udc.c driver. I would consider it a predecessor. The first driver (usbdev.c) cannot work this way, but the access to registers and endpoints is like that for the Au1500 which should be correct for the Au1500, too. But the Au1550's DMA differs. The second driver (au1200udc.c / amd5536udc.c) has the same DMA, but the registers and endpoint stuff are different, and it supports USB 2.0 whereas the Au1550 only supports USB 1.1. It looks like the Au1550 needs a driver merged from the 2 (or 3) above drivers. Is anybody working on that? Can anybody point me to some projects, people or other source code that could help me? Regards, Elmar From tux-master@web.de Thu Dec 14 23:14:07 2006 Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 14 Dec 2006 23:14:12 +0000 (GMT) Received: from fmmailgate03.web.de ([217.72.192.234]:29415 "EHLO fmmailgate03.web.de") by ftp.linux-mips.org with ESMTP id S20039846AbWLNXOH (ORCPT ); Thu, 14 Dec 2006 23:14:07 +0000 Received: from smtp05.web.de (fmsmtp05.dlan.cinetic.de [172.20.4.166]) by fmmailgate03.web.de (Postfix) with ESMTP id 960D94634DEF; Fri, 15 Dec 2006 00:14:01 +0100 (CET) Received: from [84.180.164.166] (helo=pluto.sol) by smtp05.web.de with asmtp (TLSv1:AES256-SHA:256) (WEB.DE 4.107 #114) id 1Guzm5-0001D4-00; Fri, 15 Dec 2006 00:14:01 +0100 Received: from jens by pluto.sol with local (Exim 4.63) (envelope-from ) id 1Guzhi-0001DC-NA; Fri, 15 Dec 2006 00:09:30 +0100 Date: Fri, 15 Dec 2006 00:09:30 +0100 From: Jens Seidel To: linux-mips@linux-mips.org Cc: Jens Seidel Subject: Re: SGI Octane kernel patches fail Message-ID: <20061214230930.GB2229@pluto> References: <20061214203535.GA18511@pluto> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20061214203535.GA18511@pluto> User-Agent: Mutt/1.5.13 (2006-08-11) X-Sender: tux-master@web.de 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: 13453 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: jensseidel@users.sf.net Precedence: bulk X-list: linux-mips On Thu, Dec 14, 2006 at 09:35:35PM +0100, Jens Seidel wrote: > I tried to compile a newer 2.6.19-rc1 kernel and applied the two IOC3 > and IP30 patches from > ftp://ftp.linux-mips.org/pub/linux/mips/people/skylark/. First of all > the patch fails slightly and needs manual adjustments. Compiling results > in an error, do_IRQ() is called with only one parameter instead of two. > > So I wonder what kernels are compatible with > linux-mips-2.6.19-rc1-ip30-r28.patch.bz2. Do I need other patches as > well? Also the kernel config file skylark-approved-config-tm in skylark/ > is out of date. It seems to match a 2.6.12 or similar version. > > PS: Please CC: me. Ah, it works fine with linux-2.6.19 (it was trivial to crosscompile). So it seems the names of the patches are just wrong. I still fail to mount the root fs via NFS (tcpdump reports no network transfer after loading the kernel) and to have root on a local hard disk: [17179594.972000] XFS: file system using version 1 directory format [17179595.044000] XFS: SB validate failed [17179595.092000] VFS: Cannot open root device "sdb8" or unknown-block(8,24) [17179595.172000] Please append a correct "root=" boot option [17179595.240000] Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(8,24) I need to check this "SB validation". But I'm sure I'm able to embed an initrd into the kernel as this works already with the old Gentoo kernel. Jens From anemo@mba.ocn.ne.jp Fri Dec 15 16:26:51 2006 Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 15 Dec 2006 16:26:56 +0000 (GMT) Received: from mba.ocn.ne.jp ([210.190.142.172]:19961 "HELO smtp.mba.ocn.ne.jp") by ftp.linux-mips.org with SMTP id S20038640AbWLOQ0v (ORCPT ); Fri, 15 Dec 2006 16:26:51 +0000 Received: from localhost (p8174-ipad34funabasi.chiba.ocn.ne.jp [124.85.65.174]) by smtp.mba.ocn.ne.jp (Postfix) with ESMTP id 20441BD84; Sat, 16 Dec 2006 01:26:46 +0900 (JST) Date: Sat, 16 Dec 2006 01:26:45 +0900 (JST) Message-Id: <20061216.012645.07642903.anemo@mba.ocn.ne.jp> To: ralf@linux-mips.org Cc: linux-mips@linux-mips.org, qemu-devel@nongnu.org Subject: Re: [MIPS] Use conditional traps for BUG_ON on MIPS II and better. From: Atsushi Nemoto In-Reply-To: <20061203213518.GA22225@linux-mips.org> References: <20061204.015327.36921579.anemo@mba.ocn.ne.jp> <20061203213518.GA22225@linux-mips.org> 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 3.3 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: 13454 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, 3 Dec 2006 21:35:18 +0000, Ralf Baechle wrote: > > It seems this commit break QEMU kernel ... or QEMU can not interpret > > the TNE instruction correctly? > > Thiemo says that's indeed a possibility. Probably that feature has not > been well tested in qemu. I found the bug. "Trap If XXX" instructions are translated as it was "Trap If XXX Immediate". Index: target-mips/translate.c =================================================================== RCS file: /sources/qemu/qemu/target-mips/translate.c,v retrieving revision 1.27 diff -u -r1.27 translate.c --- target-mips/translate.c 10 Dec 2006 22:08:10 -0000 1.27 +++ target-mips/translate.c 15 Dec 2006 16:16:07 -0000 @@ -1276,6 +1276,7 @@ GEN_LOAD_REG_TN(T1, rt); cond = 1; } + break; case OPC_TEQI: case OPC_TGEI: case OPC_TGEIU: --- Atsushi Nemoto From sshtylyov@dev.rtsoft.ru Fri Dec 15 21:26:46 2006 Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 15 Dec 2006 21:26:50 +0000 (GMT) Received: from rtsoft3.corbina.net ([85.21.88.6]:42989 "EHLO buildserver.ru.mvista.com") by ftp.linux-mips.org with ESMTP id S20039933AbWLOV0q (ORCPT ); Fri, 15 Dec 2006 21:26:46 +0000 Received: from [192.168.1.248] (unknown [10.150.0.9]) by buildserver.ru.mvista.com (Postfix) with ESMTP id 642B48814; Sat, 16 Dec 2006 01:26:44 +0400 (SAMT) Message-ID: <45831375.4060303@dev.rtsoft.ru> Date: Sat, 16 Dec 2006 00:28:21 +0300 From: Sergei Shtylyov Organization: RTSoft, Inc. User-Agent: Mozilla/5.0 (X11; U; Linux i686; rv:1.7.2) Gecko/20040803 X-Accept-Language: ru, en-us, en-gb MIME-Version: 1.0 To: elmar gerdes Cc: linux-usb-devel@lists.sourceforge.net, linux-mips@linux-mips.org Subject: Re: Question on UDC driver for the Alchemy Au1550 References: <20061214234250.Q13369@pogo.engel-kg.com> In-Reply-To: <20061214234250.Q13369@pogo.engel-kg.com> Content-Type: text/plain; charset=us-ascii; 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: 13455 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: sshtylyov@dev.rtsoft.ru Precedence: bulk X-list: linux-mips Hello. elmar gerdes wrote: > to make this short: > Is anybody working on a UDC driver for the Alchemy Au1550 > (MIPS-based)? > If you are interested in details, please read on: > I'm working with an Au1550-based board and would like to run it as a USB > device. There have been a few drivers around for Au1xxx-based boards, > but none of them seems to be adequate for this processor (or else I > missed something...): > a) in the kernel tree: arch/mips/au1000/common/usbdev.c > > This one was for Au1000, Au1100, and Au1500 IIRC. But it didn't > even compile for quite some kernel versions and now it has been > removed from the tree. > The first driver (usbdev.c) cannot work this way, but the access to It was written by MontaVista in the ancient times when there was no USB gadget stack I think. It was never completeed because of the known USB device interrupt latency issues in the early revisions of Au1xx0 chips. > registers and endpoints is like that for the Au1500 which should be > correct for the Au1500, too. But the Au1550's DMA differs. > The second driver (au1200udc.c / amd5536udc.c) has the same DMA, but the > registers and endpoint stuff are different, and it supports USB 2.0 > whereas the Au1550 only supports USB 1.1. Au1200 has OTG controller, hasn't it? > It looks like the Au1550 needs a driver merged from the 2 (or 3) above > drivers. Probably. > Is anybody working on that? Can anybody point me to some projects, > people or other source code that could help me? I think Rodolfo Giometti was working on Au1100 (and hence Au1000/1500) USB device support. The topic of Alchemy USB device has been touched several times on linux-mips, I'd suggest to look thru the list archives. Getting the Au1550 spec. update would be a good idea too... although you're probably lucky with Au1550 -- I'm not seeing any USB device errata listed for there. > Regards, > Elmar WBR, Sergei From vagabon.xyz@gmail.com Sat Dec 16 11:17:24 2006 Received: with ECARTIS (v1.0.0; list linux-mips); Sat, 16 Dec 2006 11:17:28 +0000 (GMT) Received: from ug-out-1314.google.com ([66.249.92.170]:58513 "EHLO ug-out-1314.google.com") by ftp.linux-mips.org with ESMTP id S20038404AbWLPLRY (ORCPT ); Sat, 16 Dec 2006 11:17:24 +0000 Received: by ug-out-1314.google.com with SMTP id 40so1309093uga for ; Sat, 16 Dec 2006 03:17:24 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=X+XJs0KS7Cnke3rm8I5iC1sXWGfFTH1hvlCW8pz9vthEMHjKCJ2sF55Cde+/dWKicOqqAnNgK4zDE+DBxmVQecF4hDUWMZ5gDAneAMjLu64DGuzobx25LLTDjUuHsywfKIMrerWWd+CVsUU23QHrhyp5wf5ls5Zswk5L+uUXpdI= Received: by 10.78.193.19 with SMTP id q19mr956483huf.1166267843605; Sat, 16 Dec 2006 03:17:23 -0800 (PST) Received: by 10.78.124.19 with HTTP; Sat, 16 Dec 2006 03:17:23 -0800 (PST) Message-ID: Date: Sat, 16 Dec 2006 12:17:23 +0100 From: "Franck Bui-Huu" To: "Ralf Baechle" Subject: Re: [RFC] FLATMEM: allow memory to start at pfn != 0 Cc: linux-mips@linux-mips.org In-Reply-To: <20061211184640.GB1308@linux-mips.org> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <1165420110699-git-send-email-fbuihuu@gmail.com> <20061211184640.GB1308@linux-mips.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: 13456 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 On 12/11/06, Ralf Baechle wrote: > On Wed, Dec 06, 2006 at 04:48:27PM +0100, Franck Bui-Huu wrote: > > I just tested this on a Malta. So patch 2/3 makes Malta die pretty > spectacularly, so I'm going to remve patches 2/3 and 3/3 again from my > tree. > When you'll have time, could you test only patch 2/3. It's only a clean up patch, which eases integration of patch 3/3 ? This clean up should improve current code even if you don't merge patch 3/3. And more importantly, knowing that patch 2/3 woks should help me to find out what's wrong with your config. Thanks Franck From ths@networkno.de Sat Dec 16 17:19:12 2006 Received: with ECARTIS (v1.0.0; list linux-mips); Sat, 16 Dec 2006 17:19:17 +0000 (GMT) Received: from phoenix.bawue.net ([193.7.176.60]:40644 "EHLO mail.bawue.net") by ftp.linux-mips.org with ESMTP id S20039490AbWLPRTM (ORCPT ); Sat, 16 Dec 2006 17:19:12 +0000 Received: from lagash (p54A46E44.dip.t-dialin.net [84.164.110.68]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by mail.bawue.net (Postfix) with ESMTP id 6CDADBAD28; Sat, 16 Dec 2006 18:10:59 +0100 (CET) Received: from ths by lagash with local (Exim 4.63) (envelope-from ) id 1Gvd4Z-0008C1-5t; Sat, 16 Dec 2006 17:11:43 +0000 Date: Sat, 16 Dec 2006 17:11:43 +0000 To: Atsushi Nemoto Cc: ralf@linux-mips.org, linux-mips@linux-mips.org, qemu-devel@nongnu.org Subject: Re: [MIPS] Use conditional traps for BUG_ON on MIPS II and better. Message-ID: <20061216171142.GA21660@networkno.de> References: <20061204.015327.36921579.anemo@mba.ocn.ne.jp> <20061203213518.GA22225@linux-mips.org> <20061216.012645.07642903.anemo@mba.ocn.ne.jp> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20061216.012645.07642903.anemo@mba.ocn.ne.jp> User-Agent: Mutt/1.5.13 (2006-08-11) From: Thiemo Seufer 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: 13457 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 Atsushi Nemoto wrote: > On Sun, 3 Dec 2006 21:35:18 +0000, Ralf Baechle wrote: > > > It seems this commit break QEMU kernel ... or QEMU can not interpret > > > the TNE instruction correctly? > > > > Thiemo says that's indeed a possibility. Probably that feature has not > > been well tested in qemu. > > I found the bug. "Trap If XXX" instructions are translated as it was > "Trap If XXX Immediate". > > Index: target-mips/translate.c > =================================================================== > RCS file: /sources/qemu/qemu/target-mips/translate.c,v > retrieving revision 1.27 > diff -u -r1.27 translate.c > --- target-mips/translate.c 10 Dec 2006 22:08:10 -0000 1.27 > +++ target-mips/translate.c 15 Dec 2006 16:16:07 -0000 > @@ -1276,6 +1276,7 @@ > GEN_LOAD_REG_TN(T1, rt); > cond = 1; > } > + break; > case OPC_TEQI: > case OPC_TGEI: > case OPC_TGEIU: Thanks, committed. Thiemo From anemo@mba.ocn.ne.jp Sun Dec 17 15:07:46 2006 Received: with ECARTIS (v1.0.0; list linux-mips); Sun, 17 Dec 2006 15:07:52 +0000 (GMT) Received: from mba.ocn.ne.jp ([210.190.142.172]:60128 "HELO smtp.mba.ocn.ne.jp") by ftp.linux-mips.org with SMTP id S20042189AbWLQPHq (ORCPT ); Sun, 17 Dec 2006 15:07:46 +0000 Received: from localhost (p3079-ipad02funabasi.chiba.ocn.ne.jp [61.214.23.79]) by smtp.mba.ocn.ne.jp (Postfix) with ESMTP id 32A99BCBA; Mon, 18 Dec 2006 00:07:40 +0900 (JST) Date: Mon, 18 Dec 2006 00:07:40 +0900 (JST) Message-Id: <20061218.000740.08076708.anemo@mba.ocn.ne.jp> To: linux-mips@linux-mips.org Cc: ralf@linux-mips.org Subject: [PATCH] Unify memset.S From: Atsushi Nemoto 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 3.3 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: 13458 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 The 32-bit version and 64-bit version are almost equal. Unify them. This makes further improvements (for example, supporting CDEX, etc.) easier. Signed-off-by: Atsushi Nemoto --- arch/mips/lib-32/Makefile | 2 arch/mips/lib-32/memset.S | 145 -------------------------------------- arch/mips/lib-64/Makefile | 2 arch/mips/lib-64/memset.S | 142 ------------------------------------- arch/mips/lib/Makefile | 2 arch/mips/lib/memset.S | 166 ++++++++++++++++++++++++++++++++++++++++++++ 6 files changed, 169 insertions(+), 290 deletions(-) diff --git a/arch/mips/lib-32/Makefile b/arch/mips/lib-32/Makefile index dcd4d2e..2036cf5 100644 --- a/arch/mips/lib-32/Makefile +++ b/arch/mips/lib-32/Makefile @@ -2,7 +2,7 @@ # # Makefile for MIPS-specific library files.. # -lib-y += memset.o watch.o +lib-y += watch.o obj-$(CONFIG_CPU_MIPS32) += dump_tlb.o obj-$(CONFIG_CPU_MIPS64) += dump_tlb.o diff --git a/arch/mips/lib-32/memset.S b/arch/mips/lib-32/memset.S deleted file mode 100644 index 1981485..0000000 --- a/arch/mips/lib-32/memset.S +++ /dev/null @@ -1,145 +0,0 @@ -/* - * 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) 1998, 1999, 2000 by Ralf Baechle - * Copyright (C) 1999, 2000 Silicon Graphics, Inc. - */ -#include -#include -#include - -#define EX(insn,reg,addr,handler) \ -9: insn reg, addr; \ - .section __ex_table,"a"; \ - PTR 9b, handler; \ - .previous - - .macro f_fill64 dst, offset, val, fixup - EX(LONG_S, \val, (\offset + 0 * LONGSIZE)(\dst), \fixup) - EX(LONG_S, \val, (\offset + 1 * LONGSIZE)(\dst), \fixup) - EX(LONG_S, \val, (\offset + 2 * LONGSIZE)(\dst), \fixup) - EX(LONG_S, \val, (\offset + 3 * LONGSIZE)(\dst), \fixup) - EX(LONG_S, \val, (\offset + 4 * LONGSIZE)(\dst), \fixup) - EX(LONG_S, \val, (\offset + 5 * LONGSIZE)(\dst), \fixup) - EX(LONG_S, \val, (\offset + 6 * LONGSIZE)(\dst), \fixup) - EX(LONG_S, \val, (\offset + 7 * LONGSIZE)(\dst), \fixup) - EX(LONG_S, \val, (\offset + 8 * LONGSIZE)(\dst), \fixup) - EX(LONG_S, \val, (\offset + 9 * LONGSIZE)(\dst), \fixup) - EX(LONG_S, \val, (\offset + 10 * LONGSIZE)(\dst), \fixup) - EX(LONG_S, \val, (\offset + 11 * LONGSIZE)(\dst), \fixup) - EX(LONG_S, \val, (\offset + 12 * LONGSIZE)(\dst), \fixup) - EX(LONG_S, \val, (\offset + 13 * LONGSIZE)(\dst), \fixup) - EX(LONG_S, \val, (\offset + 14 * LONGSIZE)(\dst), \fixup) - EX(LONG_S, \val, (\offset + 15 * LONGSIZE)(\dst), \fixup) - .endm - -/* - * memset(void *s, int c, size_t n) - * - * a0: start of area to clear - * a1: char to fill with - * a2: size of area to clear - */ - .set noreorder - .align 5 -LEAF(memset) - beqz a1, 1f - move v0, a0 /* result */ - - andi a1, 0xff /* spread fillword */ - sll t1, a1, 8 - or a1, t1 - sll t1, a1, 16 - or a1, t1 -1: - -FEXPORT(__bzero) - sltiu t0, a2, LONGSIZE /* very small region? */ - bnez t0, small_memset - andi t0, a0, LONGMASK /* aligned? */ - - beqz t0, 1f - PTR_SUBU t0, LONGSIZE /* alignment in bytes */ - -#ifdef __MIPSEB__ - EX(swl, a1, (a0), first_fixup) /* make word aligned */ -#endif -#ifdef __MIPSEL__ - EX(swr, a1, (a0), first_fixup) /* make word aligned */ -#endif - PTR_SUBU a0, t0 /* long align ptr */ - PTR_ADDU a2, t0 /* correct size */ - -1: ori t1, a2, 0x3f /* # of full blocks */ - xori t1, 0x3f - beqz t1, memset_partial /* no block to fill */ - andi t0, a2, 0x3c - - PTR_ADDU t1, a0 /* end address */ - .set reorder -1: PTR_ADDIU a0, 64 - f_fill64 a0, -64, a1, fwd_fixup - bne t1, a0, 1b - .set noreorder - -memset_partial: - PTR_LA t1, 2f /* where to start */ - PTR_SUBU t1, t0 - jr t1 - PTR_ADDU a0, t0 /* dest ptr */ - - .set push - .set noreorder - .set nomacro - f_fill64 a0, -64, a1, partial_fixup /* ... but first do longs ... */ -2: .set pop - andi a2, LONGMASK /* At most one long to go */ - - beqz a2, 1f - PTR_ADDU a0, a2 /* What's left */ -#ifdef __MIPSEB__ - EX(swr, a1, -1(a0), last_fixup) -#endif -#ifdef __MIPSEL__ - EX(swl, a1, -1(a0), last_fixup) -#endif -1: jr ra - move a2, zero - -small_memset: - beqz a2, 2f - PTR_ADDU t1, a0, a2 - -1: PTR_ADDIU a0, 1 /* fill bytewise */ - bne t1, a0, 1b - sb a1, -1(a0) - -2: jr ra /* done */ - move a2, zero - END(memset) - -first_fixup: - jr ra - nop - -fwd_fixup: - PTR_L t0, TI_TASK($28) - LONG_L t0, THREAD_BUADDR(t0) - andi a2, 0x3f - LONG_ADDU a2, t1 - jr ra - LONG_SUBU a2, t0 - -partial_fixup: - PTR_L t0, TI_TASK($28) - LONG_L t0, THREAD_BUADDR(t0) - andi a2, LONGMASK - LONG_ADDU a2, t1 - jr ra - LONG_SUBU a2, t0 - -last_fixup: - jr ra - andi v1, a2, LONGMASK diff --git a/arch/mips/lib-64/Makefile b/arch/mips/lib-64/Makefile index dcd4d2e..2036cf5 100644 --- a/arch/mips/lib-64/Makefile +++ b/arch/mips/lib-64/Makefile @@ -2,7 +2,7 @@ # # Makefile for MIPS-specific library files.. # -lib-y += memset.o watch.o +lib-y += watch.o obj-$(CONFIG_CPU_MIPS32) += dump_tlb.o obj-$(CONFIG_CPU_MIPS64) += dump_tlb.o diff --git a/arch/mips/lib-64/memset.S b/arch/mips/lib-64/memset.S deleted file mode 100644 index e2c42c8..0000000 --- a/arch/mips/lib-64/memset.S +++ /dev/null @@ -1,142 +0,0 @@ -/* - * 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) 1998, 1999, 2000 by Ralf Baechle - * Copyright (C) 1999, 2000 Silicon Graphics, Inc. - */ -#include -#include -#include - -#define EX(insn,reg,addr,handler) \ -9: insn reg, addr; \ - .section __ex_table,"a"; \ - PTR 9b, handler; \ - .previous - - .macro f_fill64 dst, offset, val, fixup - EX(LONG_S, \val, (\offset + 0 * LONGSIZE)(\dst), \fixup) - EX(LONG_S, \val, (\offset + 1 * LONGSIZE)(\dst), \fixup) - EX(LONG_S, \val, (\offset + 2 * LONGSIZE)(\dst), \fixup) - EX(LONG_S, \val, (\offset + 3 * LONGSIZE)(\dst), \fixup) - EX(LONG_S, \val, (\offset + 4 * LONGSIZE)(\dst), \fixup) - EX(LONG_S, \val, (\offset + 5 * LONGSIZE)(\dst), \fixup) - EX(LONG_S, \val, (\offset + 6 * LONGSIZE)(\dst), \fixup) - EX(LONG_S, \val, (\offset + 7 * LONGSIZE)(\dst), \fixup) - .endm - -/* - * memset(void *s, int c, size_t n) - * - * a0: start of area to clear - * a1: char to fill with - * a2: size of area to clear - */ - .set noreorder - .align 5 -LEAF(memset) - beqz a1, 1f - move v0, a0 /* result */ - - andi a1, 0xff /* spread fillword */ - dsll t1, a1, 8 - or a1, t1 - dsll t1, a1, 16 - or a1, t1 - dsll t1, a1, 32 - or a1, t1 -1: - -FEXPORT(__bzero) - sltiu t0, a2, LONGSIZE /* very small region? */ - bnez t0, small_memset - andi t0, a0, LONGMASK /* aligned? */ - - beqz t0, 1f - PTR_SUBU t0, LONGSIZE /* alignment in bytes */ - -#ifdef __MIPSEB__ - EX(sdl, a1, (a0), first_fixup) /* make dword aligned */ -#endif -#ifdef __MIPSEL__ - EX(sdr, a1, (a0), first_fixup) /* make dword aligned */ -#endif - PTR_SUBU a0, t0 /* long align ptr */ - PTR_ADDU a2, t0 /* correct size */ - -1: ori t1, a2, 0x3f /* # of full blocks */ - xori t1, 0x3f - beqz t1, memset_partial /* no block to fill */ - andi t0, a2, 0x38 - - PTR_ADDU t1, a0 /* end address */ - .set reorder -1: PTR_ADDIU a0, 64 - f_fill64 a0, -64, a1, fwd_fixup - bne t1, a0, 1b - .set noreorder - -memset_partial: - PTR_LA t1, 2f /* where to start */ - .set noat - dsrl AT, t0, 1 - PTR_SUBU t1, AT - .set noat - jr t1 - PTR_ADDU a0, t0 /* dest ptr */ - - .set push - .set noreorder - .set nomacro - f_fill64 a0, -64, a1, partial_fixup /* ... but first do longs ... */ -2: .set pop - andi a2, LONGMASK /* At most one long to go */ - - beqz a2, 1f - PTR_ADDU a0, a2 /* What's left */ -#ifdef __MIPSEB__ - EX(sdr, a1, -1(a0), last_fixup) -#endif -#ifdef __MIPSEL__ - EX(sdl, a1, -1(a0), last_fixup) -#endif -1: jr ra - move a2, zero - -small_memset: - beqz a2, 2f - PTR_ADDU t1, a0, a2 - -1: PTR_ADDIU a0, 1 /* fill bytewise */ - bne t1, a0, 1b - sb a1, -1(a0) - -2: jr ra /* done */ - move a2, zero - END(memset) - -first_fixup: - jr ra - nop - -fwd_fixup: - PTR_L t0, TI_TASK($28) - LONG_L t0, THREAD_BUADDR(t0) - andi a2, 0x3f - LONG_ADDU a2, t1 - jr ra - LONG_SUBU a2, t0 - -partial_fixup: - PTR_L t0, TI_TASK($28) - LONG_L t0, THREAD_BUADDR(t0) - andi a2, LONGMASK - LONG_ADDU a2, t1 - jr ra - LONG_SUBU a2, t0 - -last_fixup: - jr ra - andi v1, a2, LONGMASK diff --git a/arch/mips/lib/Makefile b/arch/mips/lib/Makefile index 30a9b83..a9f6434 100644 --- a/arch/mips/lib/Makefile +++ b/arch/mips/lib/Makefile @@ -2,7 +2,7 @@ # # Makefile for MIPS-specific library files.. # -lib-y += csum_partial.o memcpy.o promlib.o \ +lib-y += csum_partial.o memcpy.o memset.o promlib.o \ strlen_user.o strncpy_user.o strnlen_user.o uncached.o # libgcc-style stuff needed in the kernel diff --git a/arch/mips/lib/memset.S b/arch/mips/lib/memset.S new file mode 100644 index 0000000..3f8b8b3 --- /dev/null +++ b/arch/mips/lib/memset.S @@ -0,0 +1,166 @@ +/* + * 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) 1998, 1999, 2000 by Ralf Baechle + * Copyright (C) 1999, 2000 Silicon Graphics, Inc. + */ +#include +#include +#include + +#if LONGSIZE == 4 +#define LONG_S_L swl +#define LONG_S_R swr +#else +#define LONG_S_L sdl +#define LONG_S_R sdr +#endif + +#define EX(insn,reg,addr,handler) \ +9: insn reg, addr; \ + .section __ex_table,"a"; \ + PTR 9b, handler; \ + .previous + + .macro f_fill64 dst, offset, val, fixup + EX(LONG_S, \val, (\offset + 0 * LONGSIZE)(\dst), \fixup) + EX(LONG_S, \val, (\offset + 1 * LONGSIZE)(\dst), \fixup) + EX(LONG_S, \val, (\offset + 2 * LONGSIZE)(\dst), \fixup) + EX(LONG_S, \val, (\offset + 3 * LONGSIZE)(\dst), \fixup) + EX(LONG_S, \val, (\offset + 4 * LONGSIZE)(\dst), \fixup) + EX(LONG_S, \val, (\offset + 5 * LONGSIZE)(\dst), \fixup) + EX(LONG_S, \val, (\offset + 6 * LONGSIZE)(\dst), \fixup) + EX(LONG_S, \val, (\offset + 7 * LONGSIZE)(\dst), \fixup) +#if LONGSIZE == 4 + EX(LONG_S, \val, (\offset + 8 * LONGSIZE)(\dst), \fixup) + EX(LONG_S, \val, (\offset + 9 * LONGSIZE)(\dst), \fixup) + EX(LONG_S, \val, (\offset + 10 * LONGSIZE)(\dst), \fixup) + EX(LONG_S, \val, (\offset + 11 * LONGSIZE)(\dst), \fixup) + EX(LONG_S, \val, (\offset + 12 * LONGSIZE)(\dst), \fixup) + EX(LONG_S, \val, (\offset + 13 * LONGSIZE)(\dst), \fixup) + EX(LONG_S, \val, (\offset + 14 * LONGSIZE)(\dst), \fixup) + EX(LONG_S, \val, (\offset + 15 * LONGSIZE)(\dst), \fixup) +#endif + .endm + +/* + * memset(void *s, int c, size_t n) + * + * a0: start of area to clear + * a1: char to fill with + * a2: size of area to clear + */ + .set noreorder + .align 5 +LEAF(memset) + beqz a1, 1f + move v0, a0 /* result */ + + andi a1, 0xff /* spread fillword */ + LONG_SLL t1, a1, 8 + or a1, t1 + LONG_SLL t1, a1, 16 +#if LONGSIZE == 8 + or a1, t1 + LONG_SLL t1, a1, 32 +#endif + or a1, t1 +1: + +FEXPORT(__bzero) + sltiu t0, a2, LONGSIZE /* very small region? */ + bnez t0, small_memset + andi t0, a0, LONGMASK /* aligned? */ + + beqz t0, 1f + PTR_SUBU t0, LONGSIZE /* alignment in bytes */ + +#ifdef __MIPSEB__ + EX(LONG_S_L, a1, (a0), first_fixup) /* make word/dword aligned */ +#endif +#ifdef __MIPSEL__ + EX(LONG_S_R, a1, (a0), first_fixup) /* make word/dword aligned */ +#endif + PTR_SUBU a0, t0 /* long align ptr */ + PTR_ADDU a2, t0 /* correct size */ + +1: ori t1, a2, 0x3f /* # of full blocks */ + xori t1, 0x3f + beqz t1, memset_partial /* no block to fill */ + andi t0, a2, 0x40-LONGSIZE + + PTR_ADDU t1, a0 /* end address */ + .set reorder +1: PTR_ADDIU a0, 64 + f_fill64 a0, -64, a1, fwd_fixup + bne t1, a0, 1b + .set noreorder + +memset_partial: + PTR_LA t1, 2f /* where to start */ +#if LONGSIZE == 4 + PTR_SUBU t1, t0 +#else + .set noat + LONG_SRL AT, t0, 1 + PTR_SUBU t1, AT + .set noat +#endif + jr t1 + PTR_ADDU a0, t0 /* dest ptr */ + + .set push + .set noreorder + .set nomacro + f_fill64 a0, -64, a1, partial_fixup /* ... but first do longs ... */ +2: .set pop + andi a2, LONGMASK /* At most one long to go */ + + beqz a2, 1f + PTR_ADDU a0, a2 /* What's left */ +#ifdef __MIPSEB__ + EX(LONG_S_R, a1, -1(a0), last_fixup) +#endif +#ifdef __MIPSEL__ + EX(LONG_S_L, a1, -1(a0), last_fixup) +#endif +1: jr ra + move a2, zero + +small_memset: + beqz a2, 2f + PTR_ADDU t1, a0, a2 + +1: PTR_ADDIU a0, 1 /* fill bytewise */ + bne t1, a0, 1b + sb a1, -1(a0) + +2: jr ra /* done */ + move a2, zero + END(memset) + +first_fixup: + jr ra + nop + +fwd_fixup: + PTR_L t0, TI_TASK($28) + LONG_L t0, THREAD_BUADDR(t0) + andi a2, 0x3f + LONG_ADDU a2, t1 + jr ra + LONG_SUBU a2, t0 + +partial_fixup: + PTR_L t0, TI_TASK($28) + LONG_L t0, THREAD_BUADDR(t0) + andi a2, LONGMASK + LONG_ADDU a2, t1 + jr ra + LONG_SUBU a2, t0 + +last_fixup: + jr ra + andi v1, a2, LONGMASK From anemo@mba.ocn.ne.jp Sun Dec 17 15:38:25 2006 Received: with ECARTIS (v1.0.0; list linux-mips); Sun, 17 Dec 2006 15:38:30 +0000 (GMT) Received: from mba.ocn.ne.jp ([210.190.142.172]:55551 "HELO smtp.mba.ocn.ne.jp") by ftp.linux-mips.org with SMTP id S20042560AbWLQPiZ (ORCPT ); Sun, 17 Dec 2006 15:38:25 +0000 Received: from localhost (p3079-ipad02funabasi.chiba.ocn.ne.jp [61.214.23.79]) by smtp.mba.ocn.ne.jp (Postfix) with ESMTP id 729D0BCD5; Mon, 18 Dec 2006 00:38:21 +0900 (JST) Date: Mon, 18 Dec 2006 00:38:21 +0900 (JST) Message-Id: <20061218.003821.96686517.anemo@mba.ocn.ne.jp> To: linux-mips@linux-mips.org Cc: ralf@linux-mips.org Subject: [PATCH] Fix build_store_reg() From: Atsushi Nemoto 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 3.3 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: 13459 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 The commit a923660d786a53e78834b19062f7af2535f7f8ad accidently prevents TX49 from using CDEX. Use build_dst_pref() only if prefetch for store was really available. Signed-off-by: Atsushi Nemoto --- diff --git a/arch/mips/mm/pg-r4k.c b/arch/mips/mm/pg-r4k.c index d41fc58..dc795be 100644 --- a/arch/mips/mm/pg-r4k.c +++ b/arch/mips/mm/pg-r4k.c @@ -243,11 +243,10 @@ static void __init __build_store_reg(int static inline void build_store_reg(int reg) { - if (cpu_has_prefetch) - if (reg) - build_dst_pref(pref_offset_copy); - else - build_dst_pref(pref_offset_clear); + int pref_off = cpu_has_prefetch ? + (reg ? pref_offset_copy : pref_offset_clear) : 0; + if (pref_off) + build_dst_pref(pref_off); else if (cpu_has_cache_cdex_s) build_cdex_s(); else if (cpu_has_cache_cdex_p) From lists@nabble.com Mon Dec 18 09:04:12 2006 Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 18 Dec 2006 09:04:18 +0000 (GMT) Received: from www.nabble.com ([72.21.53.35]:8938 "EHLO talk.nabble.com") by ftp.linux-mips.org with ESMTP id S20047876AbWLRJEM (ORCPT ); Mon, 18 Dec 2006 09:04:12 +0000 Received: from [72.21.53.38] (helo=jubjub.nabble.com) by talk.nabble.com with esmtp (Exim 4.50) id 1GwEPq-0006ch-4E for linux-mips@linux-mips.org; Mon, 18 Dec 2006 01:04:10 -0800 Message-ID: <7925460.post@talk.nabble.com> Date: Mon, 18 Dec 2006 01:04:10 -0800 (PST) From: Daniel Laird To: linux-mips@linux-mips.org Subject: PAGE_ALIGN + PAGE_SHIFT from userspace MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Nabble-From: danieljlaird@hotmail.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: 13460 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: danieljlaird@hotmail.com Precedence: bulk X-list: linux-mips Hi All, I was using linux 2.6.17.13 on my MIPS and it was all going well. I am just porting to 2.6.19 and am having a couple of issues. My first issue is that i used to mmap a buffer from user space. I used to use a PAGE_ALIGN macro when doing this: /** to align the pointer to the (next) page boundary */ #define PAGE_ALIGN(addr) (((addr) + PAGE_SIZE - 1) & PAGE_MASK) this worked as PAGE_SIZE and PAGE_MASK were available in page.h. This have now been moved inside the #ifdef KERNEL guard in the header file. Meaning these are no longer available. Are these available somewhere else? Should I be doing something different to mmap? Any help appreciated Daniel Laird -- View this message in context: http://www.nabble.com/PAGE_ALIGN-%2B-PAGE_SHIFT-from-userspace-tf2838680.html#a7925460 Sent from the linux-mips main mailing list archive at Nabble.com. From lists@nabble.com Mon Dec 18 09:15:02 2006 Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 18 Dec 2006 09:15:07 +0000 (GMT) Received: from www.nabble.com ([72.21.53.35]:46991 "EHLO talk.nabble.com") by ftp.linux-mips.org with ESMTP id S20047907AbWLRJPC (ORCPT ); Mon, 18 Dec 2006 09:15:02 +0000 Received: from [72.21.53.38] (helo=jubjub.nabble.com) by talk.nabble.com with esmtp (Exim 4.50) id 1GwEaL-0001sa-2O for linux-mips@linux-mips.org; Mon, 18 Dec 2006 01:15:01 -0800 Message-ID: <7925588.post@talk.nabble.com> Date: Mon, 18 Dec 2006 01:15:01 -0800 (PST) From: Daniel Laird To: linux-mips@linux-mips.org Subject: 2.6.19 timer API changes MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Nabble-From: danieljlaird@hotmail.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: 13461 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: danieljlaird@hotmail.com Precedence: bulk X-list: linux-mips Hi All, I am porting the Philips/PNX8550 kernel from 2.6.17.13 to 2.6.19. I am having some issues: One issue I am having is with the new Timer API that replaced the board specific API. I have made all of the important changes board_timer_setup -> plat_timer_setup When I run the kernel it hangs in the calibrate_delay function. Eventually the complete kernel does run but it runs very slow. This is usually an issue with the Timer Interuppt setup etc. But I have looked at the other MIPS ports and seem to have made the same changes. On the PNX8550 it does not use the CP0 timer but use a different timer (the Custom MIPS core has 3 extra timers) I replaced the arch/mips/kernel/time.c with a merge between 2.6.17.13 and 2.6.19 and I can get the kernel to boot at the correct speed straight through the calibrate_delay function and the entire system seems to be working correctly. I was wondering if anyone might have any ideas on how to debug this problem as I would like a clean port to 2.6.19. Maybe the new timer code will not work properly on the PNX8550 in which case maybe some patches are required. I am continuing to debug at my end and once I have a working system with the smallest set of changes to the time.c file I will post them in the hope that someone will point out a silly error I have made in the CPU/board setup. In the mean time any helpful ideas on debugging, tracing, even solving this issue would be really appreciated Daniel -- View this message in context: http://www.nabble.com/2.6.19-timer-API-changes-tf2838715.html#a7925588 Sent from the linux-mips main mailing list archive at Nabble.com. From ths@networkno.de Mon Dec 18 13:00:48 2006 Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 18 Dec 2006 13:00:54 +0000 (GMT) Received: from phoenix.bawue.net ([193.7.176.60]:41434 "EHLO mail.bawue.net") by ftp.linux-mips.org with ESMTP id S20048948AbWLRNAs (ORCPT ); Mon, 18 Dec 2006 13:00:48 +0000 Received: from lagash (p54A47C58.dip.t-dialin.net [84.164.124.88]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by mail.bawue.net (Postfix) with ESMTP id 131F5B84E1; Mon, 18 Dec 2006 13:46:17 +0100 (CET) Received: from ths by lagash with local (Exim 4.63) (envelope-from ) id 1GwHtU-000259-3y; Mon, 18 Dec 2006 12:47:00 +0000 Date: Mon, 18 Dec 2006 12:47:00 +0000 To: Daniel Laird Cc: linux-mips@linux-mips.org Subject: Re: PAGE_ALIGN + PAGE_SHIFT from userspace Message-ID: <20061218124659.GA17301@networkno.de> References: <7925460.post@talk.nabble.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <7925460.post@talk.nabble.com> User-Agent: Mutt/1.5.13 (2006-08-11) From: Thiemo Seufer 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: 13462 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 Daniel Laird wrote: > > Hi All, > > I was using linux 2.6.17.13 on my MIPS and it was all going well. I am just > porting to 2.6.19 and am having a couple of issues. > > My first issue is that i used to mmap a buffer from user space. I used to > use a PAGE_ALIGN macro when doing this: > /** to align the pointer to the (next) page boundary */ > #define PAGE_ALIGN(addr) (((addr) + PAGE_SIZE - 1) & PAGE_MASK) > > this worked as PAGE_SIZE and PAGE_MASK were available in page.h. It didn't work reliably since the pagesize is a kernel configuration option. > This have now been moved inside the #ifdef KERNEL guard in the header file. > Meaning these are no longer available. > > Are these available somewhere else? > Should I be doing something different to mmap? Use the libc's sysconf(_SC_PAGESIZE) function. Thiemo From anemo@mba.ocn.ne.jp Mon Dec 18 16:17:42 2006 Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 18 Dec 2006 16:17:47 +0000 (GMT) Received: from mba.ocn.ne.jp ([210.190.142.172]:52203 "HELO smtp.mba.ocn.ne.jp") by ftp.linux-mips.org with SMTP id S20050072AbWLRQRm (ORCPT ); Mon, 18 Dec 2006 16:17:42 +0000 Received: from localhost (p8230-ipad202funabasi.chiba.ocn.ne.jp [222.146.79.230]) by smtp.mba.ocn.ne.jp (Postfix) with ESMTP id A773FBC42; Tue, 19 Dec 2006 01:17:35 +0900 (JST) Date: Tue, 19 Dec 2006 01:17:35 +0900 (JST) Message-Id: <20061219.011735.35857841.anemo@mba.ocn.ne.jp> To: linux-mips@linux-mips.org Cc: ralf@linux-mips.org Subject: [PATCH] Fix csum_partial_copy_from_user From: Atsushi Nemoto 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 3.3 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: 13463 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 I found that asm version of csum_partial_copy_from_user() introduced in e9e016815f264227b6260f77ca84f1c43cf8b9bd was less effective. For csum_partial_copy_from_user() case, "both_aligned" 8-word copy/sum loop block is skipped to handle LOAD failure properly. So we should iterate 4-word copy/sum block for that case, otherwize we will loop at ineffective "less_than_4units" block. Signed-off-by: Atsushi Nemoto --- diff --git a/arch/mips/lib/csum_partial.S b/arch/mips/lib/csum_partial.S index ec0744d..0d6e9ae 100644 --- a/arch/mips/lib/csum_partial.S +++ b/arch/mips/lib/csum_partial.S @@ -488,8 +488,11 @@ EXC( STORE t2, UNIT(2)(dst), s_exc) ADDC(sum, t2) EXC( STORE t3, UNIT(3)(dst), s_exc) ADDC(sum, t3) - beqz len, done + /* If we skipped both_aligned 8-word loop, iterate here */ + bnez AT, cleanup_both_aligned ADD dst, dst, 4*NBYTES + beqz len, done + nop less_than_4units: /* * rem = len % NBYTES From lists@nabble.com Tue Dec 19 08:17:29 2006 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 19 Dec 2006 08:17:34 +0000 (GMT) Received: from www.nabble.com ([72.21.53.35]:8904 "EHLO talk.nabble.com") by ftp.linux-mips.org with ESMTP id S28574753AbWLSIR3 (ORCPT ); Tue, 19 Dec 2006 08:17:29 +0000 Received: from [72.21.53.38] (helo=jubjub.nabble.com) by talk.nabble.com with esmtp (Exim 4.50) id 1GwaA8-0000l8-Nl for linux-mips@linux-mips.org; Tue, 19 Dec 2006 00:17:24 -0800 Message-ID: <7943218.post@talk.nabble.com> Date: Tue, 19 Dec 2006 00:17:24 -0800 (PST) From: Daniel Laird To: linux-mips@linux-mips.org Subject: 2.6.19 timer API changes In-Reply-To: <7925588.post@talk.nabble.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Nabble-From: danieljlaird@hotmail.com References: <7925588.post@talk.nabble.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: 13464 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: danieljlaird@hotmail.com Precedence: bulk X-list: linux-mips Hi All, I am porting the Philips/PNX8550 kernel from 2.6.17.13 to 2.6.19. I am having some issues: One issue I am having is with the new Timer API that replaced the board specific API. I have made all of the important changes board_timer_setup -> plat_timer_setup When I run the kernel it hangs in the calibrate_delay function. Eventually the complete kernel does run but it runs very slow. This is usually an issue with the Timer Interuppt setup etc. But I have looked at the other MIPS ports and seem to have made the same changes. On the PNX8550 it does not use the CP0 timer but use a different timer (the Custom MIPS core has 3 extra timers) I replaced the arch/mips/kernel/time.c with a merge between 2.6.17.13 and 2.6.19 and I can get the kernel to boot at the correct speed straight through the calibrate_delay function and the entire system seems to be working correctly. I was wondering if anyone might have any ideas on how to debug this problem as I would like a clean port to 2.6.19. Maybe the new timer code will not work properly on the PNX8550 in which case maybe some patches are required. I am continuing to debug at my end and once I have a working system with the smallest set of changes to the time.c file I will post them in the hope that someone will point out a silly error I have made in the CPU/board setup. In the mean time any helpful ideas on debugging, tracing, even solving this issue would be really appreciated Daniel -- View this message in context: http://www.nabble.com/2.6.19-timer-API-changes-tf2838715.html#a7943218 Sent from the linux-mips main mailing list archive at Nabble.com. From lists@nabble.com Tue Dec 19 08:18:05 2006 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 19 Dec 2006 08:18:10 +0000 (GMT) Received: from www.nabble.com ([72.21.53.35]:14793 "EHLO talk.nabble.com") by ftp.linux-mips.org with ESMTP id S28574828AbWLSISF (ORCPT ); Tue, 19 Dec 2006 08:18:05 +0000 Received: from [72.21.53.38] (helo=jubjub.nabble.com) by talk.nabble.com with esmtp (Exim 4.50) id 1GwaAm-0000qu-GY for linux-mips@linux-mips.org; Tue, 19 Dec 2006 00:18:04 -0800 Message-ID: <7943224.post@talk.nabble.com> Date: Tue, 19 Dec 2006 00:18:04 -0800 (PST) From: Daniel Laird To: linux-mips@linux-mips.org Subject: Re: PAGE_ALIGN + PAGE_SHIFT from userspace In-Reply-To: <20061218124659.GA17301@networkno.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Nabble-From: danieljlaird@hotmail.com References: <7925460.post@talk.nabble.com> <20061218124659.GA17301@networkno.de> 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: 13465 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: danieljlaird@hotmail.com Precedence: bulk X-list: linux-mips Works a treat thankyou! -- View this message in context: http://www.nabble.com/PAGE_ALIGN-%2B-PAGE_SHIFT-from-userspace-tf2838680.html#a7943224 Sent from the linux-mips main mailing list archive at Nabble.com. From anemo@mba.ocn.ne.jp Tue Dec 19 14:34:16 2006 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 19 Dec 2006 14:34:21 +0000 (GMT) Received: from mba.ocn.ne.jp ([210.190.142.172]:60610 "HELO smtp.mba.ocn.ne.jp") by ftp.linux-mips.org with SMTP id S28576869AbWLSOeQ (ORCPT ); Tue, 19 Dec 2006 14:34:16 +0000 Received: from localhost (p7053-ipad211funabasi.chiba.ocn.ne.jp [58.91.163.53]) by smtp.mba.ocn.ne.jp (Postfix) with ESMTP id CB604BA43; Tue, 19 Dec 2006 23:34:10 +0900 (JST) Date: Tue, 19 Dec 2006 23:34:10 +0900 (JST) Message-Id: <20061219.233410.25911550.anemo@mba.ocn.ne.jp> To: danieljlaird@hotmail.com Cc: linux-mips@linux-mips.org Subject: Re: 2.6.19 timer API changes From: Atsushi Nemoto In-Reply-To: <7943218.post@talk.nabble.com> References: <7925588.post@talk.nabble.com> <7943218.post@talk.nabble.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 3.3 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: 13466 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 Tue, 19 Dec 2006 00:17:24 -0800 (PST), Daniel Laird wrote: > When I run the kernel it hangs in the calibrate_delay function. > Eventually the complete kernel does run but it runs very slow. > This is usually an issue with the Timer Interuppt setup etc. But I have > looked at the other MIPS ports and seem to have made the same changes. > > On the PNX8550 it does not use the CP0 timer but use a different timer (the > Custom MIPS core has 3 extra timers) Hmm, do the TIMER1 and CP0_COUNTER run at same speed? If no, the PNX8550 port should be broken (i.e. gettimeofday() did not work properly) even without the timer API changes. You should provide custom clocksource.mips_read (previously named mips_hpt_read) function which returns TIMER1 counter value. If the TIMER1 was not 32-bit free-run counter, some trick would be required. Refer sb1250 or jmr3927 for example. --- Atsushi Nemoto From lists@nabble.com Tue Dec 19 14:51:54 2006 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 19 Dec 2006 14:51:59 +0000 (GMT) Received: from www.nabble.com ([72.21.53.35]:47519 "EHLO talk.nabble.com") by ftp.linux-mips.org with ESMTP id S28576942AbWLSOvy (ORCPT ); Tue, 19 Dec 2006 14:51:54 +0000 Received: from [72.21.53.38] (helo=jubjub.nabble.com) by talk.nabble.com with esmtp (Exim 4.50) id 1GwgJo-0006wo-7E for linux-mips@linux-mips.org; Tue, 19 Dec 2006 06:51:48 -0800 Message-ID: <7948316.post@talk.nabble.com> Date: Tue, 19 Dec 2006 06:51:48 -0800 (PST) From: Daniel Laird To: linux-mips@linux-mips.org Subject: Re: 2.6.19 timer API changes In-Reply-To: <20061219.233410.25911550.anemo@mba.ocn.ne.jp> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Nabble-From: danieljlaird@hotmail.com References: <7925588.post@talk.nabble.com> <7943218.post@talk.nabble.com> <20061219.233410.25911550.anemo@mba.ocn.ne.jp> 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: 13467 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: danieljlaird@hotmail.com Precedence: bulk X-list: linux-mips Atsushi Nemoto wrote: > > Hmm, do the TIMER1 and CP0_COUNTER run at same speed? If no, the > PNX8550 port should be broken (i.e. gettimeofday() did not work > properly) even without the timer API changes. You should provide > custom clocksource.mips_read (previously named mips_hpt_read) function > which returns TIMER1 counter value. If the TIMER1 was not 32-bit > free-run counter, some trick would be required. Refer sb1250 or > jmr3927 for example. > > --- > Atsushi Nemoto > > > I am just starting to look into this (thankyou for your first comments). I have reduced the problem code, so if I change the following: /* For use both as a high precision timer and an interrupt source. */ static void __init c0_hpt_timer_init(void) { expirelo = read_c0_count() + cycles_per_jiffy; write_c0_compare(expirelo); } (the 2.6.19 version) to the following: /* For use both as a high precision timer and an interrupt source. */ static void __init c0_hpt_timer_init(void) { unsigned int count = read_c0_count() - mips_hpt_read(); expirelo = (count / cycles_per_jiffy + 1) * cycles_per_jiffy; write_c0_count(expirelo - cycles_per_jiffy); write_c0_compare(expirelo); write_c0_count(count); } Then i get the system to boot up and all seems well. I am new to this and am looking into why this change makes the system boot up. As always though any help is appreciated. Cheers Dan -- View this message in context: http://www.nabble.com/2.6.19-timer-API-changes-tf2838715.html#a7948316 Sent from the linux-mips main mailing list archive at Nabble.com. From anemo@mba.ocn.ne.jp Tue Dec 19 15:01:17 2006 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 19 Dec 2006 15:01:22 +0000 (GMT) Received: from mba.ocn.ne.jp ([210.190.142.172]:723 "HELO smtp.mba.ocn.ne.jp") by ftp.linux-mips.org with SMTP id S28576972AbWLSPBR (ORCPT ); Tue, 19 Dec 2006 15:01:17 +0000 Received: from localhost (p7053-ipad211funabasi.chiba.ocn.ne.jp [58.91.163.53]) by smtp.mba.ocn.ne.jp (Postfix) with ESMTP id 42782B864; Wed, 20 Dec 2006 00:01:14 +0900 (JST) Date: Wed, 20 Dec 2006 00:01:13 +0900 (JST) Message-Id: <20061220.000113.59033093.anemo@mba.ocn.ne.jp> To: danieljlaird@hotmail.com Cc: linux-mips@linux-mips.org Subject: Re: 2.6.19 timer API changes From: Atsushi Nemoto In-Reply-To: <20061219.233410.25911550.anemo@mba.ocn.ne.jp> References: <7925588.post@talk.nabble.com> <7943218.post@talk.nabble.com> <20061219.233410.25911550.anemo@mba.ocn.ne.jp> 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 3.3 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: 13468 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 Tue, 19 Dec 2006 00:17:24 -0800 (PST), Daniel Laird wrote: > On the PNX8550 it does not use the CP0 timer but use a different timer (the > Custom MIPS core has 3 extra timers) Do you know what this ifndef line mean? #ifndef CONFIG_SOC_PNX8550 /* pnx8550 resets to zero */ /* Ack this timer interrupt and set the next one. */ expirelo += cycles_per_jiffy; #endif If it means "On PNX8550, writing to COMPARE register resets COUNTER to zero", new time.c might be broken for PNX8550. Could you try this patch? diff --git a/arch/mips/kernel/time.c b/arch/mips/kernel/time.c index 11aab6d..4eb0741 100644 --- a/arch/mips/kernel/time.c +++ b/arch/mips/kernel/time.c @@ -119,7 +119,11 @@ static cycle_t c0_hpt_read(void) /* For use both as a high precision timer and an interrupt source. */ static void __init c0_hpt_timer_init(void) { +#ifdef CONFIG_SOC_PNX8550 /* pnx8550 resets to zero */ + expirelo = cycles_per_jiffy; +#else expirelo = read_c0_count() + cycles_per_jiffy; +#endif write_c0_compare(expirelo); } From lists@nabble.com Tue Dec 19 15:34:55 2006 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 19 Dec 2006 15:35:28 +0000 (GMT) Received: from www.nabble.com ([72.21.53.35]:31644 "EHLO talk.nabble.com") by ftp.linux-mips.org with ESMTP id S28577065AbWLSPez (ORCPT ); Tue, 19 Dec 2006 15:34:55 +0000 Received: from [72.21.53.38] (helo=jubjub.nabble.com) by talk.nabble.com with esmtp (Exim 4.50) id 1GwgzW-0006VH-6v for linux-mips@linux-mips.org; Tue, 19 Dec 2006 07:34:54 -0800 Message-ID: <7949125.post@talk.nabble.com> Date: Tue, 19 Dec 2006 07:34:54 -0800 (PST) From: Daniel Laird To: linux-mips@linux-mips.org Subject: Re: 2.6.19 timer API changes In-Reply-To: <20061220.000113.59033093.anemo@mba.ocn.ne.jp> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Nabble-From: danieljlaird@hotmail.com References: <7925588.post@talk.nabble.com> <7943218.post@talk.nabble.com> <20061219.233410.25911550.anemo@mba.ocn.ne.jp> <20061220.000113.59033093.anemo@mba.ocn.ne.jp> 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: 13469 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: danieljlaird@hotmail.com Precedence: bulk X-list: linux-mips Atsushi Nemoto wrote: > > On Tue, 19 Dec 2006 00:17:24 -0800 (PST), Daniel Laird > wrote: >> On the PNX8550 it does not use the CP0 timer but use a different timer >> (the >> Custom MIPS core has 3 extra timers) > > Do you know what this ifndef line mean? > > #ifndef CONFIG_SOC_PNX8550 /* pnx8550 resets to zero */ > /* Ack this timer interrupt and set the next one. */ > expirelo += cycles_per_jiffy; > #endif > > If it means "On PNX8550, writing to COMPARE register resets COUNTER to > zero", new time.c might be broken for PNX8550. Could you try this > patch? > > diff --git a/arch/mips/kernel/time.c b/arch/mips/kernel/time.c > index 11aab6d..4eb0741 100644 > --- a/arch/mips/kernel/time.c > +++ b/arch/mips/kernel/time.c > @@ -119,7 +119,11 @@ static cycle_t c0_hpt_read(void) > /* For use both as a high precision timer and an interrupt source. */ > static void __init c0_hpt_timer_init(void) > { > +#ifdef CONFIG_SOC_PNX8550 /* pnx8550 resets to zero */ > + expirelo = cycles_per_jiffy; > +#else > expirelo = read_c0_count() + cycles_per_jiffy; > +#endif > write_c0_compare(expirelo); > } > > > > I am just digging out the mips core user manual... However I have tried this change you suggested, it still takes a long time to get past the calibrate delay function (~10seconds). However after this it seems to run at full speed where as before it used to run very slow. So an improvement, I think this does mean the new time.c has broken 8550 support hopefully I can find otu what the core does so it can be fixed. -- View this message in context: http://www.nabble.com/2.6.19-timer-API-changes-tf2838715.html#a7949125 Sent from the linux-mips main mailing list archive at Nabble.com. From sshtylyov@ru.mvista.com Tue Dec 19 15:53:01 2006 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 19 Dec 2006 15:53:05 +0000 (GMT) Received: from h155.mvista.com ([63.81.120.155]:55008 "EHLO imap.sh.mvista.com") by ftp.linux-mips.org with ESMTP id S28577122AbWLSPxB (ORCPT ); Tue, 19 Dec 2006 15:53:01 +0000 Received: from [192.168.1.248] (unknown [10.150.0.9]) by imap.sh.mvista.com (Postfix) with ESMTP id 3893F3ECA; Tue, 19 Dec 2006 07:52:39 -0800 (PST) Message-ID: <45880AC4.5010403@ru.mvista.com> Date: Tue, 19 Dec 2006 18:52:36 +0300 From: Sergei Shtylyov Organization: MontaVista Software Inc. User-Agent: Mozilla/5.0 (X11; U; Linux i686; rv:1.7.2) Gecko/20040803 X-Accept-Language: ru, en-us, en-gb MIME-Version: 1.0 To: Atsushi Nemoto Cc: danieljlaird@hotmail.com, linux-mips@linux-mips.org, Vitaly Wool Subject: Re: 2.6.19 timer API changes References: <7925588.post@talk.nabble.com> <7943218.post@talk.nabble.com> <20061219.233410.25911550.anemo@mba.ocn.ne.jp> In-Reply-To: <20061219.233410.25911550.anemo@mba.ocn.ne.jp> Content-Type: text/plain; charset=us-ascii; 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: 13470 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: sshtylyov@ru.mvista.com Precedence: bulk X-list: linux-mips Hello. Atsushi Nemoto wrote: >>When I run the kernel it hangs in the calibrate_delay function. >>Eventually the complete kernel does run but it runs very slow. >>This is usually an issue with the Timer Interuppt setup etc. But I have >>looked at the other MIPS ports and seem to have made the same changes. >>On the PNX8550 it does not use the CP0 timer but use a different timer (the >>Custom MIPS core has 3 extra timers) > Hmm, do the TIMER1 and CP0_COUNTER run at same speed? If no, the > PNX8550 port should be broken (i.e. gettimeofday() did not work > properly) even without the timer API changes. You should provide > custom clocksource.mips_read (previously named mips_hpt_read) function > which returns TIMER1 counter value. If the TIMER1 was not 32-bit > free-run counter, some trick would be required. Refer sb1250 or > jmr3927 for example. I would like to discourage you from repeating those JMR3927 clocksource "tricks" when you have 3 spare count/compare regs. This will warrant troubles when clockevents support gets merged into mainline (in fact, it was not necessary even on JMR3927 which has 3 timers). Although, if the timer isn't auto-reloading (I assume it isn't), the trick shouldn't be needed. > --- > Atsushi Nemoto WBR, Sergei From sshtylyov@ru.mvista.com Tue Dec 19 16:24:07 2006 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 19 Dec 2006 16:24:11 +0000 (GMT) Received: from h155.mvista.com ([63.81.120.155]:31201 "EHLO imap.sh.mvista.com") by ftp.linux-mips.org with ESMTP id S28577296AbWLSQYH (ORCPT ); Tue, 19 Dec 2006 16:24:07 +0000 Received: from [192.168.1.248] (unknown [10.150.0.9]) by imap.sh.mvista.com (Postfix) with ESMTP id 08A603ECA; Tue, 19 Dec 2006 08:24:01 -0800 (PST) Message-ID: <4588121D.90505@ru.mvista.com> Date: Tue, 19 Dec 2006 19:23:57 +0300 From: Sergei Shtylyov Organization: MontaVista Software Inc. User-Agent: Mozilla/5.0 (X11; U; Linux i686; rv:1.7.2) Gecko/20040803 X-Accept-Language: ru, en-us, en-gb MIME-Version: 1.0 To: Daniel Laird Cc: linux-mips@linux-mips.org, Vitaly Wool Subject: Re: 2.6.19 timer API changes References: <7925588.post@talk.nabble.com> <7943218.post@talk.nabble.com> <20061219.233410.25911550.anemo@mba.ocn.ne.jp> <7948316.post@talk.nabble.com> In-Reply-To: <7948316.post@talk.nabble.com> Content-Type: text/plain; charset=us-ascii; 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: 13471 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: sshtylyov@ru.mvista.com Precedence: bulk X-list: linux-mips Daniel Laird wrote: > Atsushi Nemoto wrote: >>Hmm, do the TIMER1 and CP0_COUNTER run at same speed? If no, the >>PNX8550 port should be broken (i.e. gettimeofday() did not work >>properly) even without the timer API changes. You should provide >>custom clocksource.mips_read (previously named mips_hpt_read) function Meaning clocksource_mips.read... :-) >>which returns TIMER1 counter value. If the TIMER1 was not 32-bit >>free-run counter, some trick would be required. Refer sb1250 or >>jmr3927 for example. >>--- >>Atsushi Nemoto >> >> >> > > I am just starting to look into this (thankyou for your first comments). > I have reduced the problem code, so if I change the following: > /* For use both as a high precision timer and an interrupt source. */ > static void __init c0_hpt_timer_init(void) > { > expirelo = read_c0_count() + cycles_per_jiffy; > write_c0_compare(expirelo); > } (the 2.6.19 version) > to the following: > /* For use both as a high precision timer and an interrupt source. */ > static void __init c0_hpt_timer_init(void) > { > unsigned int count = read_c0_count() - mips_hpt_read(); Doesn't make sense to me... Should be 0 or near. > expirelo = (count / cycles_per_jiffy + 1) * cycles_per_jiffy; > write_c0_count(expirelo - cycles_per_jiffy); > write_c0_compare(expirelo); > write_c0_count(count); > } This code just shouldn't be executing at all, since the interrupts are coming from the other source than standard CP0 count/compare registers (so, I'd assume mips_timer_state should need to be set -- but it doesn't)... and at the same time the handler writes to them... well, PNX8550 must have really weird timers... > Then i get the system to boot up and all seems well. I am new to this and > am looking into why this change makes the system boot up. As always though > any help is appreciated. > Cheers > Dan WBR, Sergei From anemo@mba.ocn.ne.jp Tue Dec 19 16:29:20 2006 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 19 Dec 2006 16:29:25 +0000 (GMT) Received: from mba.ocn.ne.jp ([210.190.142.172]:7404 "HELO smtp.mba.ocn.ne.jp") by ftp.linux-mips.org with SMTP id S28577320AbWLSQ3U (ORCPT ); Tue, 19 Dec 2006 16:29:20 +0000 Received: from localhost (p7053-ipad211funabasi.chiba.ocn.ne.jp [58.91.163.53]) by smtp.mba.ocn.ne.jp (Postfix) with ESMTP id 220E1B836; Wed, 20 Dec 2006 01:29:17 +0900 (JST) Date: Wed, 20 Dec 2006 01:29:16 +0900 (JST) Message-Id: <20061220.012916.96686413.anemo@mba.ocn.ne.jp> To: sshtylyov@ru.mvista.com Cc: danieljlaird@hotmail.com, linux-mips@linux-mips.org, vwool@ru.mvista.com Subject: Re: 2.6.19 timer API changes From: Atsushi Nemoto In-Reply-To: <45880AC4.5010403@ru.mvista.com> References: <7943218.post@talk.nabble.com> <20061219.233410.25911550.anemo@mba.ocn.ne.jp> <45880AC4.5010403@ru.mvista.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 3.3 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: 13472 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 Tue, 19 Dec 2006 18:52:36 +0300, Sergei Shtylyov wrote: > I would like to discourage you from repeating those JMR3927 > clocksource "tricks" when you have 3 spare count/compare regs. This > will warrant troubles when clockevents support gets merged into > mainline (in fact, it was not necessary even on JMR3927 which has 3 > timers). Although, if the timer isn't auto-reloading (I assume it > isn't), the trick shouldn't be needed. Indeed. JMR3927 is not good for reference on writing new code. Though I do not know the PNX8550 timer details, if writing to the COMPARE reset the COUNTER or COUNTER wrapped to zero at a value in COMPARE, perhaps we can not use c0_hpt_read for clocksource. --- Atsushi Nemoto From anemo@mba.ocn.ne.jp Tue Dec 19 17:15:13 2006 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 19 Dec 2006 17:15:18 +0000 (GMT) Received: from mba.ocn.ne.jp ([210.190.142.172]:45506 "HELO smtp.mba.ocn.ne.jp") by ftp.linux-mips.org with SMTP id S28577424AbWLSRPN (ORCPT ); Tue, 19 Dec 2006 17:15:13 +0000 Received: from localhost (p7053-ipad211funabasi.chiba.ocn.ne.jp [58.91.163.53]) by smtp.mba.ocn.ne.jp (Postfix) with ESMTP id BCFCABA9E; Wed, 20 Dec 2006 02:15:08 +0900 (JST) Date: Wed, 20 Dec 2006 02:15:08 +0900 (JST) Message-Id: <20061220.021508.97296486.anemo@mba.ocn.ne.jp> To: danieljlaird@hotmail.com Cc: linux-mips@linux-mips.org, ralf@linux-mips.org Subject: Re: 2.6.19 timer API changes From: Atsushi Nemoto In-Reply-To: <7949125.post@talk.nabble.com> References: <20061219.233410.25911550.anemo@mba.ocn.ne.jp> <20061220.000113.59033093.anemo@mba.ocn.ne.jp> <7949125.post@talk.nabble.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 3.3 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: 13473 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 Tue, 19 Dec 2006 07:34:54 -0800 (PST), Daniel Laird wrote: > I am just digging out the mips core user manual... > However I have tried this change you suggested, it still takes a long time > to get past the calibrate delay function (~10seconds). > However after this it seems to run at full speed where as before it used to > run very slow. > So an improvement, I think this does mean the new time.c has broken 8550 > support hopefully I can find otu what the core does so it can be fixed. Hm, then it seems writing to COMPARE does not clear COUNT. How about this? You should still fix pnx8550_hpt_read() anyway, but I suppose gettimeofday() on PNX8550 was broken long time. Subject: [MIPS] Use custom timer_ack and clocksource_mips.read for PNX8550 Signed-off-by: Atsushi Nemoto --- diff --git a/arch/mips/kernel/time.c b/arch/mips/kernel/time.c index 11aab6d..8aa544f 100644 --- a/arch/mips/kernel/time.c +++ b/arch/mips/kernel/time.c @@ -94,10 +94,8 @@ static void c0_timer_ack(void) { unsigned int count; -#ifndef CONFIG_SOC_PNX8550 /* pnx8550 resets to zero */ /* Ack this timer interrupt and set the next one. */ expirelo += cycles_per_jiffy; -#endif write_c0_compare(expirelo); /* Check to see if we have missed any timer interrupts. */ diff --git a/arch/mips/philips/pnx8550/common/time.c b/arch/mips/philips/pnx8550/common/time.c index 65c440e..e86905a 100644 --- a/arch/mips/philips/pnx8550/common/time.c +++ b/arch/mips/philips/pnx8550/common/time.c @@ -33,7 +33,18 @@ #include #include #include -extern unsigned int mips_hpt_frequency; +static unsigned long cycles_per_jiffy __read_mostly; + +static void pnx8550_timer_ack(void) +{ + write_c0_compare(cycles_per_jiffy); +} + +static cycle_t pnx8550_hpt_read(void) +{ + /* FIXME: we should use timer2 or timer3 as freerun counter */ + return read_c0_count(); +} /* * pnx8550_time_init() - it does the following things: @@ -68,6 +79,11 @@ void pnx8550_time_init(void) * HZ timer interrupts per second. */ mips_hpt_frequency = 27UL * ((1000000UL * n)/(m * pow2p)); + cycles_per_jiffy = (mips_hpt_frequency + HZ / 2) / HZ; + clocksource_mips.read = pnx8550_hpt_read; + mips_timer_ack = pnx8550_timer_ack; + write_c0_count(0); + write_c0_compare(cycles_per_jiffy); } void __init plat_timer_setup(struct irqaction *irq) From ravikinikeri@gmail.com Wed Dec 20 07:21:11 2006 Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 20 Dec 2006 07:21:15 +0000 (GMT) Received: from py-out-1112.google.com ([64.233.166.177]:13828 "EHLO py-out-1112.google.com") by ftp.linux-mips.org with ESMTP id S28581482AbWLTHVL (ORCPT ); Wed, 20 Dec 2006 07:21:11 +0000 Received: by py-out-1112.google.com with SMTP id u52so1252763pyb for ; Tue, 19 Dec 2006 23:21:10 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; b=DjFatI0aCResKPMIpXY9DXZPnUPe1H5cCXoN9fG91NwY9Bv9YU3V3vV7Z4ZtqtMN8AZpAUiAvAOBz31OtMoxuyKU/xPbcFnJEUtsuKePraGk4uedusqhcQcLk9lNDy+5rVVmUEtGT4H3riR/HYONYTF7rs7oUvBY0Ek3ls5jUtE= Received: by 10.35.81.1 with SMTP id i1mr12034603pyl.1166599270476; Tue, 19 Dec 2006 23:21:10 -0800 (PST) Received: by 10.35.102.11 with HTTP; Tue, 19 Dec 2006 23:21:10 -0800 (PST) Message-ID: <8cd2fe3d0612192321i67f612d4n7d0a113104871b4a@mail.gmail.com> Date: Wed, 20 Dec 2006 12:51:10 +0530 From: "ravindra kumar" To: linux-mips@linux-mips.org Subject: regarding bluetooth MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed 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: 13474 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: ravikinikeri@gmail.com Precedence: bulk X-list: linux-mips hello all This is ravindra currently doing my MS in real time embedded systems in bangalore (india)...right now i m doin my project work. title is "To develop bluetooth communication on OMAP1510 Innovator development kit with the external bluetooth enabled device using linux ( porting linux on OMAP1510)" here i have ported linux on OMAP 1510 kit..as we know that OMAP1510 kit supports bluetooth features..so i have to built bluetooth stack and port on to the OMAP1510 kit..so that the OMAP kit should enable[detect] the other external bluetooth device.. so i m struggling to build the bluetooth stack in linux platform.. please help me regarding this.. thank u.. Ravindra From lists@nabble.com Wed Dec 20 09:38:04 2006 Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 20 Dec 2006 09:38:09 +0000 (GMT) Received: from www.nabble.com ([72.21.53.35]:59047 "EHLO talk.nabble.com") by ftp.linux-mips.org with ESMTP id S28581953AbWLTJiE (ORCPT ); Wed, 20 Dec 2006 09:38:04 +0000 Received: from [72.21.53.38] (helo=jubjub.nabble.com) by talk.nabble.com with esmtp (Exim 4.50) id 1Gwxsz-00006h-21 for linux-mips@linux-mips.org; Wed, 20 Dec 2006 01:37:17 -0800 Message-ID: <7987092.post@talk.nabble.com> Date: Wed, 20 Dec 2006 01:37:17 -0800 (PST) From: Daniel Laird To: linux-mips@linux-mips.org Subject: Re: 2.6.19 timer API changes In-Reply-To: <20061220.021508.97296486.anemo@mba.ocn.ne.jp> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Nabble-From: danieljlaird@hotmail.com References: <7925588.post@talk.nabble.com> <7943218.post@talk.nabble.com> <20061219.233410.25911550.anemo@mba.ocn.ne.jp> <20061220.000113.59033093.anemo@mba.ocn.ne.jp> <7949125.post@talk.nabble.com> <20061220.021508.97296486.anemo@mba.ocn.ne.jp> 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: 13475 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: danieljlaird@hotmail.com Precedence: bulk X-list: linux-mips Atsushi Nemoto wrote: > > > Hm, then it seems writing to COMPARE does not clear COUNT. > > How about this? You should still fix pnx8550_hpt_read() anyway, but I > suppose gettimeofday() on PNX8550 was broken long time. > > > Subject: [MIPS] Use custom timer_ack and clocksource_mips.read for PNX8550 > I have not tried the suggested change yet, but I have fiund the mips manual and here is what it says: The 32-bit register is both readable and writable through the MTC0 and MFC0 instructions as CP0 register 9. Upon reset, the Count register is set to 0. Count and Compare together make up Timer_1 in the PR4450 (see Section 3.12). The timer is active by default. When active, Count register contains a free running counter; on each processor clock-tick, the value in the register increments by one. However, when bit ST1 bit[3] in the CP0 Configuration register is enabled, the timer is stopped. When the ST1 bit is disabled, the timer returns to its default state. Timer_1 is active when the PR4450 is in Sleep mode, but is switched off when the PR4450 is in Coma mode. When active, the register can be reset with the assertion of the Terminal Count (TC_1) signal, which is asserted when the values in the Count and Compare registers match. After the Count register is reset, it restarts its count on the next processor clock-tick. In the PR4450, the TC_1 signal is fed to the external hardware interrupt signal to invoke an interrupt handler e.g., the timer interrupt. The TC_1 signal can only be reset to 0 when the interrupt handler performs a write to the Compare register. Consecutive writes to Count will result in undefined contents. At least one instruction must be inserted between consecutive writes to Count. This seems to suggest that writing to the compare register does in fact clear count. If I do the following: static void __init c0_hpt_timer_init(void) { #ifdef CONFIG_SOC_PNX8550 /* pnx8550 resets to zero */ expirelo = cycles_per_jiffy; #else expirelo = read_c0_count() + cycles_per_jiffy; #endif write_c0_compare(expirelo); write_c0_count(cycles_per_jiffy); //Added DJL } Then I get a normal startup. i.e it boots fast (no 10second hang). If I remove the write_c0_count then I get the 10 second hang. I have no idea if gettimeofday is broken. ANy ideas on testing this? Is there a test package / application that will do this? Before I write my own Thanks for the suggestions keep them coming! Cheers Dan -- View this message in context: http://www.nabble.com/2.6.19-timer-API-changes-tf2838715.html#a7987092 Sent from the linux-mips main mailing list archive at Nabble.com. From macro@linux-mips.org Wed Dec 20 12:01:34 2006 Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 20 Dec 2006 12:01:41 +0000 (GMT) Received: from pollux.ds.pg.gda.pl ([153.19.208.7]:58640 "EHLO pollux.ds.pg.gda.pl") by ftp.linux-mips.org with ESMTP id S28582458AbWLTMBe (ORCPT ); Wed, 20 Dec 2006 12:01:34 +0000 Received: from localhost (localhost [127.0.0.1]) by pollux.ds.pg.gda.pl (Postfix) with ESMTP id 158B6FE2B9; Wed, 20 Dec 2006 13:01:19 +0100 (CET) X-Virus-Scanned: by amavisd-new at pollux.ds.pg.gda.pl Received: from pollux.ds.pg.gda.pl ([127.0.0.1]) by localhost (pollux.ds.pg.gda.pl [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AseC5nLWdLAQ; Wed, 20 Dec 2006 13:01:18 +0100 (CET) Received: from piorun.ds.pg.gda.pl (piorun.ds.pg.gda.pl [153.19.208.8]) by pollux.ds.pg.gda.pl (Postfix) with ESMTP id 9ADE9FE2B5; Wed, 20 Dec 2006 13:01:18 +0100 (CET) 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 kBKC1MsL010498; Wed, 20 Dec 2006 13:01:23 +0100 Date: Wed, 20 Dec 2006 12:01:19 +0000 (GMT) From: "Maciej W. Rozycki" To: Andrew Morton , Ralf Baechle , Jeff Garzik , Antonino Daplas , James.Bottomley@SteelEye.com cc: linux-mips@linux-mips.org, linux-kernel@vger.kernel.org, netdev@vger.kernel.org, linux-fbdev-devel@lists.sourceforge.net, linux-scsi@vger.kernel.org Subject: [PATCH 2.6.20-rc1 00/10] TURBOchannel update to the driver model Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: ClamAV 0.88.7/2360/Wed Dec 20 07:24:09 2006 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: 13476 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 Hello, It has been much longer than expected, but finally it is here! This series of patches converts support for the TURBOchannel bus to the driver model. As a nice side effect, the generic part of the code is now really generic, that is no more dependencies on MIPS specifics under drivers/tc/ and platform specific code for MIPS got moved where it belongs. As to whether other relevant platforms will add TURBOchannel support or not I cannot tell right now. ;-) All the changes have been successfully tested with a DECstation 5000/133 and the necessary bits of additional hardware as appropriate. Where drivers supporting different bus attachments were concerned, they were built for configurations enabling all the other buses supported and run-time checked if possible. And last but not least, thanks to James Simmons for beginning this work a while ago as his code was great to start with. Maciej From macro@linux-mips.org Wed Dec 20 12:02:04 2006 Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 20 Dec 2006 12:02:08 +0000 (GMT) Received: from pollux.ds.pg.gda.pl ([153.19.208.7]:59664 "EHLO pollux.ds.pg.gda.pl") by ftp.linux-mips.org with ESMTP id S28582459AbWLTMBk (ORCPT ); Wed, 20 Dec 2006 12:01:40 +0000 Received: from localhost (localhost [127.0.0.1]) by pollux.ds.pg.gda.pl (Postfix) with ESMTP id B1E36FE2BA; Wed, 20 Dec 2006 13:01:26 +0100 (CET) X-Virus-Scanned: by amavisd-new at pollux.ds.pg.gda.pl Received: from pollux.ds.pg.gda.pl ([127.0.0.1]) by localhost (pollux.ds.pg.gda.pl [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cf1mPAuMhUQv; Wed, 20 Dec 2006 13:01:26 +0100 (CET) Received: from piorun.ds.pg.gda.pl (piorun.ds.pg.gda.pl [153.19.208.8]) by pollux.ds.pg.gda.pl (Postfix) with ESMTP id E2DE4FE2B5; Wed, 20 Dec 2006 13:01:25 +0100 (CET) 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 kBKC1XlV010519; Wed, 20 Dec 2006 13:01:33 +0100 Date: Wed, 20 Dec 2006 12:01:30 +0000 (GMT) From: "Maciej W. Rozycki" To: Andrew Morton , Ralf Baechle , Jeff Garzik , Antonino Daplas , James.Bottomley@SteelEye.com cc: linux-mips@linux-mips.org, linux-kernel@vger.kernel.org, netdev@vger.kernel.org, linux-fbdev-devel@lists.sourceforge.net, linux-scsi@vger.kernel.org Subject: [PATCH 2.6.20-rc1 01/10] TURBOchannel update to the driver model Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: ClamAV 0.88.7/2360/Wed Dec 20 07:24:09 2006 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: 13477 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 This is a set of changes to convert support for the TURBOchannel bus to the driver model. It implements the usual set of calls similar to what other bus drivers have: tc_register_driver(), tc_unregister_driver(), etc. All the platform-specific bits have been removed and headers from asm-mips/dec/ have been merged into linux/tc.h, which should be included by drivers. Signed-off-by: Maciej W. Rozycki --- Please apply. Maciej patch-mips-2.6.18-20060920-tc-sysfs-78 diff -up --recursive --new-file linux-mips-2.6.18-20060920.macro/MAINTAINERS linux-mips-2.6.18-20060920/MAINTAINERS --- linux-mips-2.6.18-20060920.macro/MAINTAINERS 2006-09-20 04:56:08.000000000 +0000 +++ linux-mips-2.6.18-20060920/MAINTAINERS 2006-11-30 01:54:54.000000000 +0000 @@ -2910,6 +2910,11 @@ L: vtun@office.satix.net W: http://vtun.sourceforge.net/tun S: Maintained +TURBOCHANNEL SUBSYSTEM +P: Maciej W. Rozycki +M: macro@linux-mips.org +S: Maintained + U14-34F SCSI DRIVER P: Dario Ballabio M: ballabio_dario@emc.com diff -up --recursive --new-file linux-mips-2.6.18-20060920.macro/drivers/tc/Makefile linux-mips-2.6.18-20060920/drivers/tc/Makefile --- linux-mips-2.6.18-20060920.macro/drivers/tc/Makefile 2003-06-05 04:03:00.000000000 +0000 +++ linux-mips-2.6.18-20060920/drivers/tc/Makefile 2006-10-03 21:01:58.000000000 +0000 @@ -4,7 +4,7 @@ # Object file lists. -obj-$(CONFIG_TC) += tc.o +obj-$(CONFIG_TC) += tc.o tc-driver.o obj-$(CONFIG_ZS) += zs.o obj-$(CONFIG_VT) += lk201.o lk201-map.o lk201-remap.o diff -up --recursive --new-file linux-mips-2.6.18-20060920.macro/drivers/tc/tc-driver.c linux-mips-2.6.18-20060920/drivers/tc/tc-driver.c --- linux-mips-2.6.18-20060920.macro/drivers/tc/tc-driver.c 1970-01-01 00:00:00.000000000 +0000 +++ linux-mips-2.6.18-20060920/drivers/tc/tc-driver.c 2006-12-19 22:29:49.000000000 +0000 @@ -0,0 +1,110 @@ +/* + * TURBOchannel driver services. + * + * Copyright (c) 2005 James Simmons + * Copyright (c) 2006 Maciej W. Rozycki + * + * Loosely based on drivers/dio/dio-driver.c and + * drivers/pci/pci-driver.c. + * + * 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. + */ + +#include +#include +#include + +/** + * tc_register_driver - register a new TC driver + * @drv: the driver structure to register + * + * Adds the driver structure to the list of registered drivers + * Returns a negative value on error, otherwise 0. + * If no error occurred, the driver remains registered even if + * no device was claimed during registration. + */ +int tc_register_driver(struct tc_driver *tdrv) +{ + return driver_register(&tdrv->driver); +} +EXPORT_SYMBOL(tc_register_driver); + +/** + * tc_unregister_driver - unregister a TC driver + * @drv: the driver structure to unregister + * + * Deletes the driver structure from the list of registered TC drivers, + * gives it a chance to clean up by calling its remove() function for + * each device it was responsible for, and marks those devices as + * driverless. + */ +void tc_unregister_driver(struct tc_driver *tdrv) +{ + driver_unregister(&tdrv->driver); +} +EXPORT_SYMBOL(tc_unregister_driver); + +/** + * tc_match_device - tell if a TC device structure has a matching + * TC device ID structure + * @tdrv: the TC driver to earch for matching TC device ID strings + * @tdev: the TC device structure to match against + * + * Used by a driver to check whether a TC device present in the + * system is in its list of supported devices. Returns the matching + * tc_device_id structure or %NULL if there is no match. + */ +const struct tc_device_id *tc_match_device(struct tc_driver *tdrv, + struct tc_dev *tdev) +{ + const struct tc_device_id *id = tdrv->id_table; + + if (id) { + while (id->name[0] || id->vendor[0]) { + if (strcmp(tdev->name, id->name) == 0 && + strcmp(tdev->vendor, id->vendor) == 0) + return id; + id++; + } + } + return NULL; +} +EXPORT_SYMBOL(tc_match_device); + +/** + * tc_bus_match - Tell if a device structure has a matching + * TC device ID structure + * @dev: the device structure to match against + * @drv: the device driver to search for matching TC device ID strings + * + * Used by a driver to check whether a TC device present in the + * system is in its list of supported devices. Returns 1 if there + * is a match or 0 otherwise. + */ +static int tc_bus_match(struct device *dev, struct device_driver *drv) +{ + struct tc_dev *tdev = to_tc_dev(dev); + struct tc_driver *tdrv = to_tc_driver(drv); + const struct tc_device_id *id; + + id = tc_match_device(tdrv, tdev); + if (id) + return 1; + + return 0; +} + +struct bus_type tc_bus_type = { + .name = "tc", + .match = tc_bus_match, +}; +EXPORT_SYMBOL(tc_bus_type); + +static int __init tc_driver_init(void) +{ + return bus_register(&tc_bus_type); +} + +postcore_initcall(tc_driver_init); diff -up --recursive --new-file linux-mips-2.6.18-20060920.macro/drivers/tc/tc.c linux-mips-2.6.18-20060920/drivers/tc/tc.c --- linux-mips-2.6.18-20060920.macro/drivers/tc/tc.c 2006-05-30 17:03:11.000000000 +0000 +++ linux-mips-2.6.18-20060920/drivers/tc/tc.c 2006-12-19 23:03:11.000000000 +0000 @@ -1,254 +1,193 @@ /* - * tc-init: We assume the TURBOchannel to be up and running so - * just probe for Modules and fill in the global data structure - * tc_bus. + * TURBOchannel bus services. * - * 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) Harald Koerfgen, 1998 + * Copyright (c) 2001, 2003, 2005, 2006 Maciej W. Rozycki + * Copyright (c) 2005 James Simmons * - * Copyright (c) Harald Koerfgen, 1998 - * Copyright (c) 2001, 2003, 2005 Maciej W. Rozycki + * 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. */ +#include +#include #include +#include #include +#include #include #include +#include #include -#include -#include #include -#include -#include -#include -#include -#include -#include - -MODULE_LICENSE("GPL"); -slot_info tc_bus[MAX_SLOT]; -static int num_tcslots; -static tcinfo *info; +static struct tc_bus tc_bus = { + .name = "TURBOchannel", +}; /* - * Interface to the world. Read comment in include/asm-mips/tc.h. + * Probing for TURBOchannel modules. */ - -int search_tc_card(const char *name) -{ - int slot; - slot_info *sip; - - for (slot = 0; slot < num_tcslots; slot++) { - sip = &tc_bus[slot]; - if ((sip->flags & FREE) && - (strncmp(sip->name, name, strlen(name)) == 0)) { - return slot; - } - } - - return -ENODEV; -} - -void claim_tc_card(int slot) -{ - if (tc_bus[slot].flags & IN_USE) { - printk("claim_tc_card: attempting to claim a card already in use\n"); - return; - } - tc_bus[slot].flags &= ~FREE; - tc_bus[slot].flags |= IN_USE; -} - -void release_tc_card(int slot) +static void __init tc_bus_add_devices(struct tc_bus *tbus) { - if (tc_bus[slot].flags & FREE) { - printk("release_tc_card: " - "attempting to release a card already free\n"); - return; - } - tc_bus[slot].flags &= ~IN_USE; - tc_bus[slot].flags |= FREE; -} - -unsigned long get_tc_base_addr(int slot) -{ - return tc_bus[slot].base_addr; -} - -unsigned long get_tc_irq_nr(int slot) -{ - return tc_bus[slot].interrupt; -} - -unsigned long get_tc_speed(void) -{ - return 100000 * (10000 / (unsigned long)info->clk_period); -} - -/* - * Probing for TURBOchannel modules - */ -static void __init tc_probe(unsigned long startaddr, unsigned long size, - int slots) -{ - unsigned long slotaddr; + resource_size_t slotsize = tbus->info.slot_size << 20; + resource_size_t extslotsize = tbus->ext_slot_size; + resource_size_t slotaddr; + resource_size_t extslotaddr; + resource_size_t devsize; + void __iomem *module; + struct tc_dev *tdev; int i, slot, err; - long offset; u8 pattern[4]; - volatile u8 *module; + long offset; - for (slot = 0; slot < slots; slot++) { - slotaddr = startaddr + slot * size; - module = ioremap_nocache(slotaddr, size); + for (slot = 0; slot < tbus->num_tcslots; slot++) { + slotaddr = tbus->slot_base + slot * slotsize; + extslotaddr = tbus->ext_slot_base + slot * extslotsize; + module = ioremap_nocache(slotaddr, slotsize); BUG_ON(!module); - offset = OLDCARD; + offset = TC_OLDCARD; err = 0; - err |= get_dbe(pattern[0], module + OLDCARD + TC_PATTERN0); - err |= get_dbe(pattern[1], module + OLDCARD + TC_PATTERN1); - err |= get_dbe(pattern[2], module + OLDCARD + TC_PATTERN2); - err |= get_dbe(pattern[3], module + OLDCARD + TC_PATTERN3); - if (err) { - iounmap(module); - continue; - } + err |= tc_preadb(pattern + 0, module + offset + TC_PATTERN0); + err |= tc_preadb(pattern + 1, module + offset + TC_PATTERN1); + err |= tc_preadb(pattern + 2, module + offset + TC_PATTERN2); + err |= tc_preadb(pattern + 3, module + offset + TC_PATTERN3); + if (err) + goto out_err; if (pattern[0] != 0x55 || pattern[1] != 0x00 || pattern[2] != 0xaa || pattern[3] != 0xff) { - offset = NEWCARD; + offset = TC_NEWCARD; err = 0; - err |= get_dbe(pattern[0], module + TC_PATTERN0); - err |= get_dbe(pattern[1], module + TC_PATTERN1); - err |= get_dbe(pattern[2], module + TC_PATTERN2); - err |= get_dbe(pattern[3], module + TC_PATTERN3); - if (err) { - iounmap(module); - continue; - } + err |= tc_preadb(pattern + 0, + module + offset + TC_PATTERN0); + err |= tc_preadb(pattern + 1, + module + offset + TC_PATTERN1); + err |= tc_preadb(pattern + 2, + module + offset + TC_PATTERN2); + err |= tc_preadb(pattern + 3, + module + offset + TC_PATTERN3); + if (err) + goto out_err; } if (pattern[0] != 0x55 || pattern[1] != 0x00 || - pattern[2] != 0xaa || pattern[3] != 0xff) { - iounmap(module); - continue; - } + pattern[2] != 0xaa || pattern[3] != 0xff) + goto out_err; + + /* Found a board, allocate it an entry in the list */ + tdev = kzalloc(sizeof(*tdev), GFP_KERNEL); + if (!tdev) { + printk(KERN_ERR "tc%x: unable to allocate tc_dev\n", + slot); + goto out_err; + } + sprintf(tdev->dev.bus_id, "tc%x", slot); + tdev->bus = tbus; + tdev->dev.parent = &tbus->dev; + tdev->dev.bus = &tc_bus_type; + tdev->slot = slot; - tc_bus[slot].base_addr = slotaddr; for (i = 0; i < 8; i++) { - tc_bus[slot].firmware[i] = - module[TC_FIRM_VER + offset + 4 * i]; - tc_bus[slot].vendor[i] = - module[TC_VENDOR + offset + 4 * i]; - tc_bus[slot].name[i] = - module[TC_MODULE + offset + 4 * i]; - } - tc_bus[slot].firmware[8] = 0; - tc_bus[slot].vendor[8] = 0; - tc_bus[slot].name[8] = 0; - /* - * Looks unneccesary, but we may change - * TC? in the future - */ - switch (slot) { - case 0: - tc_bus[slot].interrupt = dec_interrupt[DEC_IRQ_TC0]; - break; - case 1: - tc_bus[slot].interrupt = dec_interrupt[DEC_IRQ_TC1]; - break; - case 2: - tc_bus[slot].interrupt = dec_interrupt[DEC_IRQ_TC2]; - break; - /* - * Yuck! DS5000/200 onboard devices - */ - case 5: - tc_bus[slot].interrupt = dec_interrupt[DEC_IRQ_TC5]; - break; - case 6: - tc_bus[slot].interrupt = dec_interrupt[DEC_IRQ_TC6]; - break; - default: - tc_bus[slot].interrupt = -1; - break; - } + tdev->firmware[i] = + readb(module + offset + TC_FIRM_VER + 4 * i); + tdev->vendor[i] = + readb(module + offset + TC_VENDOR + 4 * i); + tdev->name[i] = + readb(module + offset + TC_MODULE + 4 * i); + } + tdev->firmware[8] = 0; + tdev->vendor[8] = 0; + tdev->name[8] = 0; + + pr_info("%s: %s %s %s\n", tdev->dev.bus_id, tdev->vendor, + tdev->name, tdev->firmware); + + devsize = readb(module + offset + TC_SLOT_SIZE); + devsize <<= 22; + if (devsize <= slotsize) { + tdev->resource.start = slotaddr; + tdev->resource.end = slotaddr + devsize - 1; + } else if (devsize <= extslotsize) { + tdev->resource.start = extslotaddr; + tdev->resource.end = extslotaddr + devsize - 1; + } else { + printk(KERN_ERR "%s: Cannot provide slot space " + "(%dMiB required, up to %dMiB supported)\n", + tdev->dev.bus_id, devsize >> 20, + max(slotsize, extslotsize) >> 20); + kfree(tdev); + goto out_err; + } + tdev->resource.name = tdev->name; + tdev->resource.flags = IORESOURCE_MEM; + + tc_device_get_irq(tdev); + device_register(&tdev->dev); + list_add_tail(&tdev->node, &tbus->devices); + +out_err: iounmap(module); } } /* - * the main entry + * The main entry. */ static int __init tc_init(void) { - int tc_clock; - int i; - unsigned long slot0addr; - unsigned long slot_size; - - if (!TURBOCHANNEL) + /* Initialize the TURBOchannel bus */ + if (tc_bus_get_info(&tc_bus)) return 0; - for (i = 0; i < MAX_SLOT; i++) { - tc_bus[i].base_addr = 0; - tc_bus[i].name[0] = 0; - tc_bus[i].vendor[0] = 0; - tc_bus[i].firmware[0] = 0; - tc_bus[i].interrupt = -1; - tc_bus[i].flags = FREE; - } - - info = rex_gettcinfo(); - slot0addr = CPHYSADDR((long)rex_slot_address(0)); - - switch (mips_machtype) { - case MACH_DS5000_200: - num_tcslots = 7; - break; - case MACH_DS5000_1XX: - case MACH_DS5000_2X0: - case MACH_DS5900: - num_tcslots = 3; - break; - case MACH_DS5000_XX: - default: - num_tcslots = 2; - break; - } - - tc_clock = 10000 / info->clk_period; - - if (info->slot_size && slot0addr) { - pr_info("TURBOchannel rev. %d at %d.%d MHz (with%s parity)\n", - info->revision, tc_clock / 10, tc_clock % 10, - info->parity ? "" : "out"); - - slot_size = info->slot_size << 20; - - tc_probe(slot0addr, slot_size, num_tcslots); - - for (i = 0; i < num_tcslots; i++) { - if (!tc_bus[i].base_addr) - continue; - pr_info(" slot %d: %s %s %s\n", i, tc_bus[i].vendor, - tc_bus[i].name, tc_bus[i].firmware); + INIT_LIST_HEAD(&tc_bus.devices); + strcpy(tc_bus.dev.bus_id, "tc"); + device_register(&tc_bus.dev); + + if (tc_bus.info.slot_size) { + unsigned int tc_clock = tc_get_speed(&tc_bus) / 100000; + + pr_info("tc: TURBOchannel rev. %d at %d.%d MHz " + "(with%s parity)\n", tc_bus.info.revision, + tc_clock / 10, tc_clock % 10, + tc_bus.info.parity ? "" : "out"); + + tc_bus.resource[0].start = tc_bus.slot_base; + tc_bus.resource[0].end = tc_bus.slot_base + + (tc_bus.info.slot_size << 20) * + tc_bus.num_tcslots; + tc_bus.resource[0].name = tc_bus.name; + tc_bus.resource[0].flags = IORESOURCE_MEM; + if (request_resource(&iomem_resource, + &tc_bus.resource[0]) < 0) { + printk(KERN_ERR "tc: Cannot reserve resource\n"); + return 0; + } + if (tc_bus.ext_slot_size) { + tc_bus.resource[1].start = tc_bus.ext_slot_base; + tc_bus.resource[1].end = tc_bus.ext_slot_base + + tc_bus.ext_slot_size * + tc_bus.num_tcslots; + tc_bus.resource[1].name = tc_bus.name; + tc_bus.resource[1].flags = IORESOURCE_MEM; + if (request_resource(&iomem_resource, + &tc_bus.resource[1]) < 0) { + printk(KERN_ERR + "tc: Cannot reserve resource\n"); + release_resource(&tc_bus.resource[0]); + return 0; + } } + + tc_bus_add_devices(&tc_bus); } return 0; } subsys_initcall(tc_init); - -EXPORT_SYMBOL(search_tc_card); -EXPORT_SYMBOL(claim_tc_card); -EXPORT_SYMBOL(release_tc_card); -EXPORT_SYMBOL(get_tc_base_addr); -EXPORT_SYMBOL(get_tc_irq_nr); -EXPORT_SYMBOL(get_tc_speed); diff -up --recursive --new-file linux-mips-2.6.18-20060920.macro/include/asm-mips/dec/tc.h linux-mips-2.6.18-20060920/include/asm-mips/dec/tc.h --- linux-mips-2.6.18-20060920.macro/include/asm-mips/dec/tc.h 2005-07-20 05:00:28.000000000 +0000 +++ linux-mips-2.6.18-20060920/include/asm-mips/dec/tc.h 1970-01-01 00:00:00.000000000 +0000 @@ -1,41 +0,0 @@ -/* - * Interface to the TURBOchannel related routines - * - * 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) 1998 Harald Koerfgen - */ -#ifndef __ASM_DEC_TC_H -#define __ASM_DEC_TC_H - -/* - * Search for a TURBOchannel Option Module - * with a certain name. Returns slot number - * of the first card not in use or -ENODEV - * if none found. - */ -extern int search_tc_card(const char *); -/* - * Marks the card in slot as used - */ -extern void claim_tc_card(int); -/* - * Marks the card in slot as free - */ -extern void release_tc_card(int); -/* - * Return base address of card in slot - */ -extern unsigned long get_tc_base_addr(int); -/* - * Return interrupt number of slot - */ -extern unsigned long get_tc_irq_nr(int); -/* - * Return TURBOchannel clock frequency in Hz - */ -extern unsigned long get_tc_speed(void); - -#endif /* __ASM_DEC_TC_H */ diff -up --recursive --new-file linux-mips-2.6.18-20060920.macro/include/asm-mips/dec/tcinfo.h linux-mips-2.6.18-20060920/include/asm-mips/dec/tcinfo.h --- linux-mips-2.6.18-20060920.macro/include/asm-mips/dec/tcinfo.h 2002-08-06 03:57:30.000000000 +0000 +++ linux-mips-2.6.18-20060920/include/asm-mips/dec/tcinfo.h 1970-01-01 00:00:00.000000000 +0000 @@ -1,47 +0,0 @@ -/* - * Various TURBOchannel related stuff - * - * 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. - * - * Information obtained through the get_tcinfo prom call - * created from: - * - * TURBOchannel Firmware Specification - * - * EK-TCAAD-FS-004 - * from Digital Equipment Corporation - * - * Copyright (c) 1998 Harald Koerfgen - */ - -typedef struct { - int revision; - int clk_period; - int slot_size; - int io_timeout; - int dma_range; - int max_dma_burst; - int parity; - int reserved[4]; -} tcinfo; - -#define MAX_SLOT 7 - -typedef struct { - unsigned long base_addr; - unsigned char name[9]; - unsigned char vendor[9]; - unsigned char firmware[9]; - int interrupt; - int flags; -} slot_info; - -/* - * Values for flags - */ -#define FREE 1<<0 -#define IN_USE 1<<1 - - diff -up --recursive --new-file linux-mips-2.6.18-20060920.macro/include/asm-mips/dec/tcmodule.h linux-mips-2.6.18-20060920/include/asm-mips/dec/tcmodule.h --- linux-mips-2.6.18-20060920.macro/include/asm-mips/dec/tcmodule.h 2002-08-06 03:57:30.000000000 +0000 +++ linux-mips-2.6.18-20060920/include/asm-mips/dec/tcmodule.h 1970-01-01 00:00:00.000000000 +0000 @@ -1,39 +0,0 @@ -/* - * 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. - * - * Offsets for the ROM header locations for - * TURBOchannel cards - * - * created from: - * - * TURBOchannel Firmware Specification - * - * EK-TCAAD-FS-004 - * from Digital Equipment Corporation - * - * Jan.1998 Harald Koerfgen - */ -#ifndef __ASM_DEC_TCMODULE_H -#define __ASM_DEC_TCMODULE_H - -#define OLDCARD 0x3c0000 -#define NEWCARD 0x000000 - -#define TC_ROM_WIDTH 0x3e0 -#define TC_ROM_STRIDE 0x3e4 -#define TC_ROM_SIZE 0x3e8 -#define TC_SLOT_SIZE 0x3ec -#define TC_PATTERN0 0x3f0 -#define TC_PATTERN1 0x3f4 -#define TC_PATTERN2 0x3f8 -#define TC_PATTERN3 0x3fc -#define TC_FIRM_VER 0x400 -#define TC_VENDOR 0x420 -#define TC_MODULE 0x440 -#define TC_FIRM_TYPE 0x460 -#define TC_FLAGS 0x470 -#define TC_ROM_OBJECTS 0x480 - -#endif /* __ASM_DEC_TCMODULE_H */ diff -up --recursive --new-file linux-mips-2.6.18-20060920.macro/include/linux/tc.h linux-mips-2.6.18-20060920/include/linux/tc.h --- linux-mips-2.6.18-20060920.macro/include/linux/tc.h 1970-01-01 00:00:00.000000000 +0000 +++ linux-mips-2.6.18-20060920/include/linux/tc.h 2006-12-19 22:33:29.000000000 +0000 @@ -0,0 +1,141 @@ +/* + * Interface to the TURBOchannel related routines. + * + * Copyright (c) 1998 Harald Koerfgen + * Copyright (c) 2005 James Simmons + * Copyright (c) 2006 Maciej W. Rozycki + * + * Based on: + * + * "TURBOchannel Firmware Specification", EK-TCAAD-FS-004 + * + * from Digital Equipment Corporation. + * + * 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. + */ +#ifndef _LINUX_TC_H +#define _LINUX_TC_H + +#include +#include +#include +#include + +/* + * Offsets for the ROM header locations for TURBOchannel cards. + */ +#define TC_OLDCARD 0x3c0000 +#define TC_NEWCARD 0x000000 + +#define TC_ROM_WIDTH 0x3e0 +#define TC_ROM_STRIDE 0x3e4 +#define TC_ROM_SIZE 0x3e8 +#define TC_SLOT_SIZE 0x3ec +#define TC_PATTERN0 0x3f0 +#define TC_PATTERN1 0x3f4 +#define TC_PATTERN2 0x3f8 +#define TC_PATTERN3 0x3fc +#define TC_FIRM_VER 0x400 +#define TC_VENDOR 0x420 +#define TC_MODULE 0x440 +#define TC_FIRM_TYPE 0x460 +#define TC_FLAGS 0x470 +#define TC_ROM_OBJECTS 0x480 + +/* + * Information obtained through the get_tcinfo() PROM call. + */ +struct tcinfo { + s32 revision; /* Hardware revision level. */ + s32 clk_period; /* Clock period in nanoseconds. */ + s32 slot_size; /* Slot size in megabytes. */ + s32 io_timeout; /* I/O timeout in cycles. */ + s32 dma_range; /* DMA address range in megabytes. */ + s32 max_dma_burst; /* Maximum DMA burst length. */ + s32 parity; /* System module supports TC parity. */ + s32 reserved[4]; +}; + +/* + * TURBOchannel bus. + */ +struct tc_bus { + struct list_head devices; /* List of devices on this bus. */ + struct resource resource[2]; /* Address space routed to this bus. */ + + struct device dev; + char name[13]; + resource_size_t slot_base; + resource_size_t ext_slot_base; + resource_size_t ext_slot_size; + int num_tcslots; + struct tcinfo info; +}; + +/* + * TURBOchannel device. + */ +struct tc_dev { + struct list_head node; /* Node in list of all TC devices. */ + struct tc_bus *bus; /* Bus this device is on. */ + struct tc_driver *driver; /* Which driver has allocated this + device. */ + struct device dev; /* Generic device interface. */ + struct resource resource; /* Address space of this device. */ + char vendor[9]; + char name[9]; + char firmware[9]; + int interrupt; + int slot; +}; + +#define to_tc_dev(n) container_of(n, struct tc_dev, dev) + +struct tc_device_id { + char vendor[9]; + char name[9]; +}; + +/* + * TURBOchannel driver. + */ +struct tc_driver { + struct list_head node; + const struct tc_device_id *id_table; + struct device_driver driver; +}; + +#define to_tc_driver(drv) container_of(drv, struct tc_driver, driver) + +/* + * Return TURBOchannel clock frequency in Hz. + */ +static inline unsigned long tc_get_speed(struct tc_bus *tbus) +{ + return 100000 * (10000 / (unsigned long)tbus->info.clk_period); +} + +#ifdef CONFIG_TC + +extern struct bus_type tc_bus_type; + +extern int tc_register_driver(struct tc_driver *tdrv); +extern void tc_unregister_driver(struct tc_driver *tdrv); + +#else /* !CONFIG_TC */ + +static inline int tc_register_driver(struct tc_driver *tdrv) { return 0; } +static inline void tc_unregister_driver(struct tc_driver *tdrv) { } + +#endif /* CONFIG_TC */ + +/* + * These have to be provided by the architecture. + */ +extern int tc_preadb(u8 *valp, void __iomem *addr); +extern int tc_bus_get_info(struct tc_bus *tbus); +extern void tc_device_get_irq(struct tc_dev *tdev); + +#endif /* _LINUX_TC_H */ From macro@linux-mips.org Wed Dec 20 12:02:31 2006 Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 20 Dec 2006 12:02:36 +0000 (GMT) Received: from pollux.ds.pg.gda.pl ([153.19.208.7]:62224 "EHLO pollux.ds.pg.gda.pl") by ftp.linux-mips.org with ESMTP id S28582461AbWLTMBp (ORCPT ); Wed, 20 Dec 2006 12:01:45 +0000 Received: from localhost (localhost [127.0.0.1]) by pollux.ds.pg.gda.pl (Postfix) with ESMTP id 03FE8FE2BB; Wed, 20 Dec 2006 13:01:31 +0100 (CET) X-Virus-Scanned: by amavisd-new at pollux.ds.pg.gda.pl Received: from pollux.ds.pg.gda.pl ([127.0.0.1]) by localhost (pollux.ds.pg.gda.pl [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NmSCEIJqsiSo; Wed, 20 Dec 2006 13:01:31 +0100 (CET) Received: from piorun.ds.pg.gda.pl (piorun.ds.pg.gda.pl [153.19.208.8]) by pollux.ds.pg.gda.pl (Postfix) with ESMTP id 7164DFE2B5; Wed, 20 Dec 2006 13:01:31 +0100 (CET) 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 kBKC1dHh010533; Wed, 20 Dec 2006 13:01:39 +0100 Date: Wed, 20 Dec 2006 12:01:36 +0000 (GMT) From: "Maciej W. Rozycki" To: Andrew Morton , Ralf Baechle cc: linux-mips@linux-mips.org, linux-kernel@vger.kernel.org Subject: [PATCH 2.6.20-rc1 02/10] TURBOchannel support for the DECstation Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: ClamAV 0.88.7/2360/Wed Dec 20 07:24:09 2006 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: 13478 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 This is the platform-specific part of TURBOchannel bus support for the DECstation. It implements determining whether the bus is actually there, getting bus parameters, IRQ assignments for devices and protected accesses to possibly unoccupied slots that may trigger bus error exceptions. Signed-off-by: Maciej W. Rozycki --- Please apply. Maciej patch-mips-2.6.18-20060920-tc-dec-1 diff -up --recursive --new-file linux-mips-2.6.18-20060920.macro/arch/mips/dec/Makefile linux-mips-2.6.18-20060920/arch/mips/dec/Makefile --- linux-mips-2.6.18-20060920.macro/arch/mips/dec/Makefile 2005-07-20 04:56:55.000000000 +0000 +++ linux-mips-2.6.18-20060920/arch/mips/dec/Makefile 2006-12-01 01:50:37.000000000 +0000 @@ -6,6 +6,7 @@ obj-y := ecc-berr.o int-handler.o ioasi kn02-irq.o kn02xa-berr.o reset.o setup.o time.o obj-$(CONFIG_PROM_CONSOLE) += promcon.o +obj-$(CONFIG_TC) += tc.o obj-$(CONFIG_CPU_HAS_WB) += wbflush.o EXTRA_AFLAGS := $(CFLAGS) diff -up --recursive --new-file linux-mips-2.6.18-20060920.macro/arch/mips/dec/prom/identify.c linux-mips-2.6.18-20060920/arch/mips/dec/prom/identify.c --- linux-mips-2.6.18-20060920.macro/arch/mips/dec/prom/identify.c 2005-07-20 04:56:55.000000000 +0000 +++ linux-mips-2.6.18-20060920/arch/mips/dec/prom/identify.c 2006-12-19 22:06:13.000000000 +0000 @@ -88,6 +88,7 @@ static inline void prom_init_kn02(void) { dec_kn_slot_base = KN02_SLOT_BASE; dec_kn_slot_size = KN02_SLOT_SIZE; + dec_tc_bus = 1; dec_rtc_base = (void *)CKSEG1ADDR(dec_kn_slot_base + KN02_RTC); } @@ -96,6 +97,7 @@ static inline void prom_init_kn02xa(void { dec_kn_slot_base = KN02XA_SLOT_BASE; dec_kn_slot_size = IOASIC_SLOT_SIZE; + dec_tc_bus = 1; ioasic_base = (void *)CKSEG1ADDR(dec_kn_slot_base + IOASIC_IOCTL); dec_rtc_base = (void *)CKSEG1ADDR(dec_kn_slot_base + IOASIC_TOY); @@ -105,6 +107,7 @@ static inline void prom_init_kn03(void) { dec_kn_slot_base = KN03_SLOT_BASE; dec_kn_slot_size = IOASIC_SLOT_SIZE; + dec_tc_bus = 1; ioasic_base = (void *)CKSEG1ADDR(dec_kn_slot_base + IOASIC_IOCTL); dec_rtc_base = (void *)CKSEG1ADDR(dec_kn_slot_base + IOASIC_TOY); diff -up --recursive --new-file linux-mips-2.6.18-20060920.macro/arch/mips/dec/setup.c linux-mips-2.6.18-20060920/arch/mips/dec/setup.c --- linux-mips-2.6.18-20060920.macro/arch/mips/dec/setup.c 2006-07-10 04:59:17.000000000 +0000 +++ linux-mips-2.6.18-20060920/arch/mips/dec/setup.c 2006-12-19 22:01:33.000000000 +0000 @@ -53,6 +53,8 @@ unsigned long dec_kn_slot_base, dec_kn_s EXPORT_SYMBOL(dec_kn_slot_base); EXPORT_SYMBOL(dec_kn_slot_size); +int dec_tc_bus; + spinlock_t ioasic_ssr_lock; volatile u32 *ioasic_base; diff -up --recursive --new-file linux-mips-2.6.18-20060920.macro/arch/mips/dec/tc.c linux-mips-2.6.18-20060920/arch/mips/dec/tc.c --- linux-mips-2.6.18-20060920.macro/arch/mips/dec/tc.c 1970-01-01 00:00:00.000000000 +0000 +++ linux-mips-2.6.18-20060920/arch/mips/dec/tc.c 2006-12-19 22:10:23.000000000 +0000 @@ -0,0 +1,95 @@ +/* + * TURBOchannel architecture calls. + * + * Copyright (c) Harald Koerfgen, 1998 + * Copyright (c) 2001, 2003, 2005, 2006 Maciej W. Rozycki + * Copyright (c) 2005 James Simmons + * + * 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. + */ +#include +#include +#include +#include +#include +#include + +#include +#include +#include + +#include +#include +#include + +/* + * Protected read byte from TURBOchannel slot space. + */ +int tc_preadb(u8 *valp, void __iomem *addr) +{ + return get_dbe(*valp, (u8 *)addr); +} + +/* + * Get TURBOchannel bus information as specified by the spec, plus + * the slot space base address and the number of slots. + */ +int __init tc_bus_get_info(struct tc_bus *tbus) +{ + if (!dec_tc_bus) + return -ENXIO; + + memcpy(&tbus->info, rex_gettcinfo(), sizeof(tbus->info)); + tbus->slot_base = CPHYSADDR((long)rex_slot_address(0)); + + switch (mips_machtype) { + case MACH_DS5000_200: + tbus->num_tcslots = 7; + break; + case MACH_DS5000_2X0: + case MACH_DS5900: + tbus->ext_slot_base = 0x20000000; + tbus->ext_slot_size = 0x20000000; + /* fall through */ + case MACH_DS5000_1XX: + tbus->num_tcslots = 3; + break; + case MACH_DS5000_XX: + tbus->num_tcslots = 2; + default: + break; + } + return 0; +} + +/* + * Get the IRQ for the specified slot. + */ +void __init tc_device_get_irq(struct tc_dev *tdev) +{ + switch (tdev->slot) { + case 0: + tdev->interrupt = dec_interrupt[DEC_IRQ_TC0]; + break; + case 1: + tdev->interrupt = dec_interrupt[DEC_IRQ_TC1]; + break; + case 2: + tdev->interrupt = dec_interrupt[DEC_IRQ_TC2]; + break; + /* + * Yuck! DS5000/200 onboard devices + */ + case 5: + tdev->interrupt = dec_interrupt[DEC_IRQ_TC5]; + break; + case 6: + tdev->interrupt = dec_interrupt[DEC_IRQ_TC6]; + break; + default: + tdev->interrupt = -1; + break; + } +} diff -up --recursive --new-file linux-mips-2.6.18-20060920.macro/include/asm-mips/dec/system.h linux-mips-2.6.18-20060920/include/asm-mips/dec/system.h --- linux-mips-2.6.18-20060920.macro/include/asm-mips/dec/system.h 2005-09-13 04:56:38.000000000 +0000 +++ linux-mips-2.6.18-20060920/include/asm-mips/dec/system.h 2006-12-19 22:01:13.000000000 +0000 @@ -3,7 +3,7 @@ * * Generic DECstation/DECsystem bits. * - * Copyright (C) 2005 Maciej W. Rozycki + * Copyright (C) 2005, 2006 Maciej W. Rozycki * * This program is free software; you can redistribute it and/or * modify it under the terms of the GNU General Public License @@ -14,5 +14,6 @@ #define __ASM_DEC_SYSTEM_H extern unsigned long dec_kn_slot_base, dec_kn_slot_size; +extern int dec_tc_bus; #endif /* __ASM_DEC_SYSTEM_H */ From macro@linux-mips.org Wed Dec 20 12:02:59 2006 Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 20 Dec 2006 12:03:06 +0000 (GMT) Received: from pollux.ds.pg.gda.pl ([153.19.208.7]:64272 "EHLO pollux.ds.pg.gda.pl") by ftp.linux-mips.org with ESMTP id S28582462AbWLTMBu (ORCPT ); Wed, 20 Dec 2006 12:01:50 +0000 Received: from localhost (localhost [127.0.0.1]) by pollux.ds.pg.gda.pl (Postfix) with ESMTP id 51D71FE2BC; Wed, 20 Dec 2006 13:01:38 +0100 (CET) X-Virus-Scanned: by amavisd-new at pollux.ds.pg.gda.pl Received: from pollux.ds.pg.gda.pl ([127.0.0.1]) by localhost (pollux.ds.pg.gda.pl [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xmpgtWYvLTF6; Wed, 20 Dec 2006 13:01:37 +0100 (CET) Received: from piorun.ds.pg.gda.pl (piorun.ds.pg.gda.pl [153.19.208.8]) by pollux.ds.pg.gda.pl (Postfix) with ESMTP id 80EBFFE2B5; Wed, 20 Dec 2006 13:01:37 +0100 (CET) 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 kBKC1jx4010545; Wed, 20 Dec 2006 13:01:45 +0100 Date: Wed, 20 Dec 2006 12:01:42 +0000 (GMT) From: "Maciej W. Rozycki" To: Andrew Morton , Jeff Garzik cc: linux-mips@linux-mips.org, linux-kernel@vger.kernel.org, netdev@vger.kernel.org Subject: [PATCH 2.6.20-rc1 03/10] defxx: TURBOchannel support Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: ClamAV 0.88.7/2360/Wed Dec 20 07:24:09 2006 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: 13479 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 This is a set of changes to add TURBOchannel support to the defxx driver. As at this point the EISA support in the driver has become the only not having been converted to the driver model, I took the opportunity to convert it as well. Plus support for MMIO in addition to PIO operation as TURBOchannel requires it anyway. Signed-off-by: Maciej W. Rozycki --- These changes have been tested at the run time with TC and PCI variations of the board. EISA support has only been verified to build correctly. I do believe I got it mostly right, but if there is somebody interested in keeping the DEFEA supported, then please send me results of testing or, for long-term testing, I would not mind accepting such a board either. ;-) Please apply. Maciej patch-mips-2.6.18-20060920-defta-69 diff -up --recursive --new-file linux-mips-2.6.18-20060920.macro/drivers/net/Kconfig linux-mips-2.6.18-20060920/drivers/net/Kconfig --- linux-mips-2.6.18-20060920.macro/drivers/net/Kconfig 2006-09-10 04:55:24.000000000 +0000 +++ linux-mips-2.6.18-20060920/drivers/net/Kconfig 2006-12-15 22:45:17.000000000 +0000 @@ -2443,7 +2443,7 @@ config RIONET_RX_SIZE config FDDI bool "FDDI driver support" - depends on (PCI || EISA) + depends on (PCI || EISA || TC) help Fiber Distributed Data Interface is a high speed local area network design; essentially a replacement for high speed Ethernet. FDDI can @@ -2453,11 +2453,31 @@ config FDDI will say N. config DEFXX - tristate "Digital DEFEA and DEFPA adapter support" - depends on FDDI && (PCI || EISA) - help - This is support for the DIGITAL series of EISA (DEFEA) and PCI - (DEFPA) controllers which can connect you to a local FDDI network. + tristate "Digital DEFTA/DEFEA/DEFPA adapter support" + depends on FDDI && (PCI || EISA || TC) + ---help--- + This is support for the DIGITAL series of TURBOchannel (DEFTA), + EISA (DEFEA) and PCI (DEFPA) controllers which can connect you + to a local FDDI network. + + To compile this driver as a module, choose M here: the module + will be called defxx. If unsure, say N. + +config DEFXX_MMIO + bool + prompt "Use MMIO instead of PIO" if PCI || EISA + depends on DEFXX + default n if PCI || EISA + default y + ---help--- + This instructs the driver to use EISA or PCI memory-mapped I/O + (MMIO) as appropriate instead of programmed I/O ports (PIO). + Enabling this gives an improvement in processing time in parts + of the driver, but it may cause problems with EISA (DEFEA) + adapters. TURBOchannel does not have the concept of I/O ports, + so MMIO is always used for these (DEFTA) adapters. + + If unsure, say N. config SKFP tristate "SysKonnect FDDI PCI support" diff -up --recursive --new-file linux-mips-2.6.18-20060920.macro/drivers/net/defxx.c linux-mips-2.6.18-20060920/drivers/net/defxx.c --- linux-mips-2.6.18-20060920.macro/drivers/net/defxx.c 2006-10-23 22:58:19.000000000 +0000 +++ linux-mips-2.6.18-20060920/drivers/net/defxx.c 2006-12-20 00:22:01.000000000 +0000 @@ -10,10 +10,12 @@ * * Abstract: * A Linux device driver supporting the Digital Equipment Corporation - * FDDI EISA and PCI controller families. Supported adapters include: + * FDDI TURBOchannel, EISA and PCI controller families. Supported + * adapters include: * - * DEC FDDIcontroller/EISA (DEFEA) - * DEC FDDIcontroller/PCI (DEFPA) + * DEC FDDIcontroller/TURBOchannel (DEFTA) + * DEC FDDIcontroller/EISA (DEFEA) + * DEC FDDIcontroller/PCI (DEFPA) * * The original author: * LVS Lawrence V. Stefani @@ -193,24 +195,27 @@ * 14 Aug 2004 macro Fix device names reported. * 14 Jun 2005 macro Use irqreturn_t. * 23 Oct 2006 macro Big-endian host support. + * 14 Dec 2006 macro TURBOchannel support. */ /* Include files */ - -#include -#include -#include -#include -#include -#include -#include -#include +#include #include +#include +#include +#include +#include #include +#include +#include +#include +#include #include -#include +#include #include -#include +#include +#include +#include #include #include @@ -219,8 +224,8 @@ /* Version information string should be updated prior to each new release! */ #define DRV_NAME "defxx" -#define DRV_VERSION "v1.09" -#define DRV_RELDATE "2006/10/23" +#define DRV_VERSION "v1.10" +#define DRV_RELDATE "2006/12/14" static char version[] __devinitdata = DRV_NAME ": " DRV_VERSION " " DRV_RELDATE @@ -235,12 +240,41 @@ static char version[] __devinitdata = */ #define NEW_SKB_SIZE (PI_RCV_DATA_K_SIZE_MAX+128) +#define __unused __attribute__ ((unused)) + +#ifdef CONFIG_PCI +#define DFX_BUS_PCI(dev) (dev->bus == &pci_bus_type) +#else +#define DFX_BUS_PCI(dev) 0 +#endif + +#ifdef CONFIG_EISA +#define DFX_BUS_EISA(dev) (dev->bus == &eisa_bus_type) +#else +#define DFX_BUS_EISA(dev) 0 +#endif + +#ifdef CONFIG_TC +#define DFX_BUS_TC(dev) (dev->bus == &tc_bus_type) +#else +#define DFX_BUS_TC(dev) 0 +#endif + +#ifdef CONFIG_DEFXX_MMIO +#define DFX_MMIO 1 +#else +#define DFX_MMIO 0 +#endif + /* Define module-wide (static) routines */ static void dfx_bus_init(struct net_device *dev); +static void dfx_bus_uninit(struct net_device *dev); static void dfx_bus_config_check(DFX_board_t *bp); -static int dfx_driver_init(struct net_device *dev, const char *print_name); +static int dfx_driver_init(struct net_device *dev, + const char *print_name, + resource_size_t bar_start); static int dfx_adap_init(DFX_board_t *bp, int get_buffers); static int dfx_open(struct net_device *dev); @@ -274,13 +308,13 @@ static void dfx_xmt_flush(DFX_board_t * /* Define module-wide (static) variables */ -static struct net_device *root_dfx_eisa_dev; +static struct pci_driver dfx_pci_driver; +static struct eisa_driver dfx_eisa_driver; +static struct tc_driver dfx_tc_driver; /* * ======================= - * = dfx_port_write_byte = - * = dfx_port_read_byte = * = dfx_port_write_long = * = dfx_port_read_long = * ======================= @@ -292,12 +326,11 @@ static struct net_device *root_dfx_eisa_ * None * * Arguments: - * bp - pointer to board information - * offset - register offset from base I/O address - * data - for dfx_port_write_byte and dfx_port_write_long, this - * is a value to write. - * for dfx_port_read_byte and dfx_port_read_byte, this - * is a pointer to store the read value. + * bp - pointer to board information + * offset - register offset from base I/O address + * data - for dfx_port_write_long, this is a value to write; + * for dfx_port_read_long, this is a pointer to store + * the read value * * Functional Description: * These routines perform the correct operation to read or write @@ -311,7 +344,7 @@ static struct net_device *root_dfx_eisa_ * registers using the register offsets defined in DEFXX.H. * * PCI port block base addresses are assigned by the PCI BIOS or system - * firmware. There is one 128 byte port block which can be accessed. It + * firmware. There is one 128 byte port block which can be accessed. It * allows for I/O mapping of both PDQ and PFI registers using the register * offsets defined in DEFXX.H. * @@ -319,7 +352,7 @@ static struct net_device *root_dfx_eisa_ * None * * Assumptions: - * bp->base_addr is a valid base I/O address for this adapter. + * bp->base is a valid base I/O address for this adapter. * offset is a valid register offset for this adapter. * * Side Effects: @@ -330,69 +363,135 @@ static struct net_device *root_dfx_eisa_ * advantage of strict data type checking. */ -static inline void dfx_port_write_byte( - DFX_board_t *bp, - int offset, - u8 data - ) - - { - u16 port = bp->base_addr + offset; - - outb(data, port); - } +static inline void dfx_writel(DFX_board_t *bp, int offset, u32 data) +{ + writel(data, bp->base.mem + offset); + mb(); +} -static inline void dfx_port_read_byte( - DFX_board_t *bp, - int offset, - u8 *data - ) +static inline void dfx_outl(DFX_board_t *bp, int offset, u32 data) +{ + outl(data, bp->base.port + offset); +} - { - u16 port = bp->base_addr + offset; +static void dfx_port_write_long(DFX_board_t *bp, int offset, u32 data) +{ + struct device __unused *bdev = bp->bus_dev; + int dfx_bus_tc = DFX_BUS_TC(bdev); + int dfx_use_mmio = DFX_MMIO || dfx_bus_tc; - *data = inb(port); - } + if (dfx_use_mmio) + dfx_writel(bp, offset, data); + else + dfx_outl(bp, offset, data); +} -static inline void dfx_port_write_long( - DFX_board_t *bp, - int offset, - u32 data - ) - { - u16 port = bp->base_addr + offset; +static inline void dfx_readl(DFX_board_t *bp, int offset, u32 *data) +{ + mb(); + *data = readl(bp->base.mem + offset); +} - outl(data, port); - } +static inline void dfx_inl(DFX_board_t *bp, int offset, u32 *data) +{ + *data = inl(bp->base.port + offset); +} -static inline void dfx_port_read_long( - DFX_board_t *bp, - int offset, - u32 *data - ) +static void dfx_port_read_long(DFX_board_t *bp, int offset, u32 *data) +{ + struct device __unused *bdev = bp->bus_dev; + int dfx_bus_tc = DFX_BUS_TC(bdev); + int dfx_use_mmio = DFX_MMIO || dfx_bus_tc; - { - u16 port = bp->base_addr + offset; + if (dfx_use_mmio) + dfx_readl(bp, offset, data); + else + dfx_inl(bp, offset, data); +} - *data = inl(port); + +/* + * ================ + * = dfx_get_bars = + * ================ + * + * Overview: + * Retrieves the address range used to access control and status + * registers. + * + * Returns: + * None + * + * Arguments: + * bdev - pointer to device information + * bar_start - pointer to store the start address + * bar_len - pointer to store the length of the area + * + * Assumptions: + * I am sure there are some. + * + * Side Effects: + * None + */ +static void dfx_get_bars(struct device *bdev, + resource_size_t *bar_start, resource_size_t *bar_len) +{ + int dfx_bus_pci = DFX_BUS_PCI(bdev); + int dfx_bus_eisa = DFX_BUS_EISA(bdev); + int dfx_bus_tc = DFX_BUS_TC(bdev); + int dfx_use_mmio = DFX_MMIO || dfx_bus_tc; + + if (dfx_bus_pci) { + int num = dfx_use_mmio ? 0 : 1; + + *bar_start = pci_resource_start(to_pci_dev(bdev), num); + *bar_len = pci_resource_len(to_pci_dev(bdev), num); + } + if (dfx_bus_eisa) { + unsigned long base_addr = to_eisa_device(bdev)->base_addr; + resource_size_t bar; + + if (dfx_use_mmio) { + bar = inb(base_addr + PI_ESIC_K_MEM_ADD_CMP_2); + bar <<= 8; + bar |= inb(base_addr + PI_ESIC_K_MEM_ADD_CMP_1); + bar <<= 8; + bar |= inb(base_addr + PI_ESIC_K_MEM_ADD_CMP_0); + bar <<= 16; + *bar_start = bar; + bar = inb(base_addr + PI_ESIC_K_MEM_ADD_MASK_2); + bar <<= 8; + bar |= inb(base_addr + PI_ESIC_K_MEM_ADD_MASK_1); + bar <<= 8; + bar |= inb(base_addr + PI_ESIC_K_MEM_ADD_MASK_0); + bar <<= 16; + *bar_len = (bar | PI_MEM_ADD_MASK_M) + 1; + } else { + *bar_start = base_addr; + *bar_len = PI_ESIC_K_CSR_IO_LEN; + } + } + if (dfx_bus_tc) { + *bar_start = to_tc_dev(bdev)->resource.start + + PI_TC_K_CSR_OFFSET; + *bar_len = PI_TC_K_CSR_LEN; } +} - /* - * ============= - * = dfx_init_one_pci_or_eisa = - * ============= + * ================ + * = dfx_register = + * ================ * * Overview: - * Initializes a supported FDDI EISA or PCI controller + * Initializes a supported FDDI controller * * Returns: * Condition code * * Arguments: - * pdev - pointer to pci device information (NULL for EISA) - * ioaddr - pointer to port (NULL for PCI) + * bdev - pointer to device information * * Functional Description: * @@ -408,56 +507,74 @@ static inline void dfx_port_read_long( * initialized and the board resources are read and stored in * the device structure. */ -static int __devinit dfx_init_one_pci_or_eisa(struct pci_dev *pdev, long ioaddr) +static int __devinit dfx_register(struct device *bdev) { static int version_disp; - char *print_name = DRV_NAME; + int dfx_bus_pci = DFX_BUS_PCI(bdev); + int dfx_bus_tc = DFX_BUS_TC(bdev); + int dfx_use_mmio = DFX_MMIO || dfx_bus_tc; + char *print_name = bdev->bus_id; struct net_device *dev; DFX_board_t *bp; /* board pointer */ + resource_size_t bar_start = 0; /* pointer to port */ + resource_size_t bar_len = 0; /* resource length */ int alloc_size; /* total buffer size used */ - int err; + struct resource *region; + int err = 0; if (!version_disp) { /* display version info if adapter is found */ version_disp = 1; /* set display flag to TRUE so that */ printk(version); /* we only display this string ONCE */ } - if (pdev != NULL) - print_name = pci_name(pdev); - dev = alloc_fddidev(sizeof(*bp)); if (!dev) { - printk(KERN_ERR "%s: unable to allocate fddidev, aborting\n", + printk(KERN_ERR "%s: Unable to allocate fddidev, aborting\n", print_name); return -ENOMEM; } /* Enable PCI device. */ - if (pdev != NULL) { - err = pci_enable_device (pdev); - if (err) goto err_out; - ioaddr = pci_resource_start (pdev, 1); + if (dfx_bus_pci && pci_enable_device(to_pci_dev(bdev))) { + printk(KERN_ERR "%s: Cannot enable PCI device, aborting\n", + print_name); + goto err_out; } SET_MODULE_OWNER(dev); - if (pdev != NULL) - SET_NETDEV_DEV(dev, &pdev->dev); + SET_NETDEV_DEV(dev, bdev); + + bp = netdev_priv(dev); + bp->bus_dev = bdev; + dev_set_drvdata(bdev, dev); - bp = dev->priv; + dfx_get_bars(bdev, &bar_start, &bar_len); - if (!request_region(ioaddr, - pdev ? PFI_K_CSR_IO_LEN : PI_ESIC_K_CSR_IO_LEN, - print_name)) { + if (dfx_use_mmio) + region = request_mem_region(bar_start, bar_len, print_name); + else + region = request_region(bar_start, bar_len, print_name); + if (!region) { printk(KERN_ERR "%s: Cannot reserve I/O resource " - "0x%x @ 0x%lx, aborting\n", print_name, - pdev ? PFI_K_CSR_IO_LEN : PI_ESIC_K_CSR_IO_LEN, ioaddr); + "0x%lx @ 0x%lx, aborting\n", + print_name, (long)bar_len, (long)bar_start); err = -EBUSY; - goto err_out; + goto err_out_disable; } - /* Initialize new device structure */ + /* Set up I/O base address. */ + if (dfx_use_mmio) { + bp->base.mem = ioremap_nocache(bar_start, bar_len); + if (!bp->base.mem) { + printk(KERN_ERR "%s: Cannot map MMIO\n", print_name); + goto err_out_region; + } + } else { + bp->base.port = bar_start; + dev->base_addr = bar_start; + } - dev->base_addr = ioaddr; /* save port (I/O) base address */ + /* Initialize new device structure */ dev->get_stats = dfx_ctl_get_stats; dev->open = dfx_open; @@ -466,22 +583,12 @@ static int __devinit dfx_init_one_pci_or dev->set_multicast_list = dfx_ctl_set_multicast_list; dev->set_mac_address = dfx_ctl_set_mac_address; - if (pdev == NULL) { - /* EISA board */ - bp->bus_type = DFX_BUS_TYPE_EISA; - bp->next = root_dfx_eisa_dev; - root_dfx_eisa_dev = dev; - } else { - /* PCI board */ - bp->bus_type = DFX_BUS_TYPE_PCI; - bp->pci_dev = pdev; - pci_set_drvdata (pdev, dev); - pci_set_master (pdev); - } + if (dfx_bus_pci) + pci_set_master(to_pci_dev(bdev)); - if (dfx_driver_init(dev, print_name) != DFX_K_SUCCESS) { + if (dfx_driver_init(dev, print_name, bar_start) != DFX_K_SUCCESS) { err = -ENODEV; - goto err_out_region; + goto err_out_unmap; } err = register_netdev(dev); @@ -500,44 +607,28 @@ err_out_kfree: sizeof(PI_CONSUMER_BLOCK) + (PI_ALIGN_K_DESC_BLK - 1); if (bp->kmalloced) - pci_free_consistent(pdev, alloc_size, - bp->kmalloced, bp->kmalloced_dma); + dma_free_coherent(bdev, alloc_size, + bp->kmalloced, bp->kmalloced_dma); + +err_out_unmap: + if (dfx_use_mmio) + iounmap(bp->base.mem); + err_out_region: - release_region(ioaddr, pdev ? PFI_K_CSR_IO_LEN : PI_ESIC_K_CSR_IO_LEN); + if (dfx_use_mmio) + release_mem_region(bar_start, bar_len); + else + release_region(bar_start, bar_len); + +err_out_disable: + if (dfx_bus_pci) + pci_disable_device(to_pci_dev(bdev)); + err_out: free_netdev(dev); return err; } -static int __devinit dfx_init_one(struct pci_dev *pdev, const struct pci_device_id *ent) -{ - return dfx_init_one_pci_or_eisa(pdev, 0); -} - -static int __init dfx_eisa_init(void) -{ - int rc = -ENODEV; - int i; /* used in for loops */ - u16 port; /* temporary I/O (port) address */ - u32 slot_id; /* EISA hardware (slot) ID read from adapter */ - - DBG_printk("In dfx_eisa_init...\n"); - - /* Scan for FDDI EISA controllers */ - - for (i=0; i < DFX_MAX_EISA_SLOTS; i++) /* only scan for up to 16 EISA slots */ - { - port = (i << 12) + PI_ESIC_K_SLOT_ID; /* port = I/O address for reading slot ID */ - slot_id = inl(port); /* read EISA HW (slot) ID */ - if ((slot_id & 0xF0FFFFFF) == DEFEA_PRODUCT_ID) - { - port = (i << 12); /* recalc base addr */ - - if (dfx_init_one_pci_or_eisa(NULL, port) == 0) rc = 0; - } - } - return rc; -} /* * ================ @@ -545,7 +636,7 @@ static int __init dfx_eisa_init(void) * ================ * * Overview: - * Initializes EISA and PCI controller bus-specific logic. + * Initializes the bus-specific controller logic. * * Returns: * None @@ -561,7 +652,7 @@ static int __init dfx_eisa_init(void) * None * * Assumptions: - * dev->base_addr has already been set with the proper + * bp->base has already been set with the proper * base I/O address for this device. * * Side Effects: @@ -572,87 +663,103 @@ static int __init dfx_eisa_init(void) static void __devinit dfx_bus_init(struct net_device *dev) { - DFX_board_t *bp = dev->priv; - u8 val; /* used for I/O read/writes */ + DFX_board_t *bp = netdev_priv(dev); + struct device *bdev = bp->bus_dev; + int dfx_bus_pci = DFX_BUS_PCI(bdev); + int dfx_bus_eisa = DFX_BUS_EISA(bdev); + int dfx_bus_tc = DFX_BUS_TC(bdev); + int dfx_use_mmio = DFX_MMIO || dfx_bus_tc; + u8 val; DBG_printk("In dfx_bus_init...\n"); - /* - * Initialize base I/O address field in bp structure - * - * Note: bp->base_addr is the same as dev->base_addr. - * It's useful because often we'll need to read - * or write registers where we already have the - * bp pointer instead of the dev pointer. Having - * the base address in the bp structure will - * save a pointer dereference. - * - * IMPORTANT!! This field must be defined before - * any of the dfx_port_* inline functions are - * called. - */ - - bp->base_addr = dev->base_addr; - - /* And a pointer back to the net_device struct */ + /* Initialize a pointer back to the net_device struct */ bp->dev = dev; /* Initialize adapter based on bus type */ - if (bp->bus_type == DFX_BUS_TYPE_EISA) - { - /* Get the interrupt level from the ESIC chip */ - - dfx_port_read_byte(bp, PI_ESIC_K_IO_CONFIG_STAT_0, &val); - switch ((val & PI_CONFIG_STAT_0_M_IRQ) >> PI_CONFIG_STAT_0_V_IRQ) - { - case PI_CONFIG_STAT_0_IRQ_K_9: - dev->irq = 9; - break; - - case PI_CONFIG_STAT_0_IRQ_K_10: - dev->irq = 10; - break; - - case PI_CONFIG_STAT_0_IRQ_K_11: - dev->irq = 11; - break; - - case PI_CONFIG_STAT_0_IRQ_K_15: - dev->irq = 15; - break; - } - - /* Enable access to I/O on the board by writing 0x03 to Function Control Register */ + if (dfx_bus_tc) + dev->irq = to_tc_dev(bdev)->interrupt; + if (dfx_bus_eisa) { + unsigned long base_addr = to_eisa_device(bdev)->base_addr; + + /* Get the interrupt level from the ESIC chip. */ + val = inb(base_addr + PI_ESIC_K_IO_CONFIG_STAT_0); + val &= PI_CONFIG_STAT_0_M_IRQ; + val >>= PI_CONFIG_STAT_0_V_IRQ; + + switch (val) { + case PI_CONFIG_STAT_0_IRQ_K_9: + dev->irq = 9; + break; - dfx_port_write_byte(bp, PI_ESIC_K_FUNCTION_CNTRL, PI_ESIC_K_FUNCTION_CNTRL_IO_ENB); + case PI_CONFIG_STAT_0_IRQ_K_10: + dev->irq = 10; + break; - /* Set the I/O decode range of the board */ + case PI_CONFIG_STAT_0_IRQ_K_11: + dev->irq = 11; + break; - val = ((dev->base_addr >> 12) << PI_IO_CMP_V_SLOT); - dfx_port_write_byte(bp, PI_ESIC_K_IO_CMP_0_1, val); - dfx_port_write_byte(bp, PI_ESIC_K_IO_CMP_1_1, val); + case PI_CONFIG_STAT_0_IRQ_K_15: + dev->irq = 15; + break; + } - /* Enable access to rest of module (including PDQ and packet memory) */ + /* + * Enable memory decoding (MEMCS0) and/or port decoding + * (IOCS1/IOCS0) as appropriate in Function Control + * Register. One of the port chip selects seems to be + * used for the Burst Holdoff register, but this bit of + * documentation is missing and as yet it has not been + * determined which of the two. This is also the reason + * the size of the decoded port range is twice as large + * as one required by the PDQ. + */ - dfx_port_write_byte(bp, PI_ESIC_K_SLOT_CNTRL, PI_SLOT_CNTRL_M_ENB); + /* Set the decode range of the board. */ + val = ((bp->base.port >> 12) << PI_IO_CMP_V_SLOT); + outb(base_addr + PI_ESIC_K_IO_ADD_CMP_0_1, val); + outb(base_addr + PI_ESIC_K_IO_ADD_CMP_0_0, 0); + outb(base_addr + PI_ESIC_K_IO_ADD_CMP_1_1, val); + outb(base_addr + PI_ESIC_K_IO_ADD_CMP_1_0, 0); + val = PI_ESIC_K_CSR_IO_LEN - 1; + outb(base_addr + PI_ESIC_K_IO_ADD_MASK_0_1, (val >> 8) & 0xff); + outb(base_addr + PI_ESIC_K_IO_ADD_MASK_0_0, val & 0xff); + outb(base_addr + PI_ESIC_K_IO_ADD_MASK_1_1, (val >> 8) & 0xff); + outb(base_addr + PI_ESIC_K_IO_ADD_MASK_1_0, val & 0xff); + + /* Enable the decoders. */ + val = PI_FUNCTION_CNTRL_M_IOCS1 | PI_FUNCTION_CNTRL_M_IOCS0; + if (dfx_use_mmio) + val |= PI_FUNCTION_CNTRL_M_MEMCS0; + outb(base_addr + PI_ESIC_K_FUNCTION_CNTRL, val); /* - * Map PDQ registers into I/O space. This is done by clearing a bit - * in Burst Holdoff register. + * Enable access to the rest of the module + * (including PDQ and packet memory). */ + val = PI_SLOT_CNTRL_M_ENB; + outb(base_addr + PI_ESIC_K_SLOT_CNTRL, val); - dfx_port_read_byte(bp, PI_ESIC_K_BURST_HOLDOFF, &val); - dfx_port_write_byte(bp, PI_ESIC_K_BURST_HOLDOFF, (val & ~PI_BURST_HOLDOFF_M_MEM_MAP)); + /* + * Map PDQ registers into memory or port space. This is + * done with a bit in the Burst Holdoff register. + */ + val = inb(base_addr + PI_DEFEA_K_BURST_HOLDOFF); + if (dfx_use_mmio) + val |= PI_BURST_HOLDOFF_V_MEM_MAP; + else + val &= ~PI_BURST_HOLDOFF_V_MEM_MAP; + outb(base_addr + PI_DEFEA_K_BURST_HOLDOFF, val); /* Enable interrupts at EISA bus interface chip (ESIC) */ - - dfx_port_read_byte(bp, PI_ESIC_K_IO_CONFIG_STAT_0, &val); - dfx_port_write_byte(bp, PI_ESIC_K_IO_CONFIG_STAT_0, (val | PI_CONFIG_STAT_0_M_INT_ENB)); - } - else - { - struct pci_dev *pdev = bp->pci_dev; + val = inb(base_addr + PI_ESIC_K_IO_CONFIG_STAT_0); + val |= PI_CONFIG_STAT_0_M_INT_ENB; + outb(base_addr + PI_ESIC_K_IO_CONFIG_STAT_0, val); + } + if (dfx_bus_pci) { + struct pci_dev *pdev = to_pci_dev(bdev); /* Get the interrupt level from the PCI Configuration Table */ @@ -661,17 +768,70 @@ static void __devinit dfx_bus_init(struc /* Check Latency Timer and set if less than minimal */ pci_read_config_byte(pdev, PCI_LATENCY_TIMER, &val); - if (val < PFI_K_LAT_TIMER_MIN) /* if less than min, override with default */ - { + if (val < PFI_K_LAT_TIMER_MIN) { val = PFI_K_LAT_TIMER_DEF; pci_write_config_byte(pdev, PCI_LATENCY_TIMER, val); - } + } /* Enable interrupts at PCI bus interface chip (PFI) */ + val = PFI_MODE_M_PDQ_INT_ENB | PFI_MODE_M_DMA_ENB; + dfx_port_write_long(bp, PFI_K_REG_MODE_CTRL, val); + } +} - dfx_port_write_long(bp, PFI_K_REG_MODE_CTRL, (PFI_MODE_M_PDQ_INT_ENB | PFI_MODE_M_DMA_ENB)); - } +/* + * ================== + * = dfx_bus_uninit = + * ================== + * + * Overview: + * Uninitializes the bus-specific controller logic. + * + * Returns: + * None + * + * Arguments: + * dev - pointer to device information + * + * Functional Description: + * Perform bus-specific logic uninitialization. + * + * Return Codes: + * None + * + * Assumptions: + * bp->base has already been set with the proper + * base I/O address for this device. + * + * Side Effects: + * Interrupts are disabled at the adapter bus-specific logic. + */ + +static void __devinit dfx_bus_uninit(struct net_device *dev) +{ + DFX_board_t *bp = netdev_priv(dev); + struct device *bdev = bp->bus_dev; + int dfx_bus_pci = DFX_BUS_PCI(bdev); + int dfx_bus_eisa = DFX_BUS_EISA(bdev); + u8 val; + + DBG_printk("In dfx_bus_uninit...\n"); + + /* Uninitialize adapter based on bus type */ + + if (dfx_bus_eisa) { + unsigned long base_addr = to_eisa_device(bdev)->base_addr; + + /* Disable interrupts at EISA bus interface chip (ESIC) */ + val = inb(base_addr + PI_ESIC_K_IO_CONFIG_STAT_0); + val &= ~PI_CONFIG_STAT_0_M_INT_ENB; + outb(base_addr + PI_ESIC_K_IO_CONFIG_STAT_0, val); + } + if (dfx_bus_pci) { + /* Disable interrupts at PCI bus interface chip (PFI) */ + dfx_port_write_long(bp, PFI_K_REG_MODE_CTRL, 0); } +} /* @@ -706,18 +866,16 @@ static void __devinit dfx_bus_init(struc static void __devinit dfx_bus_config_check(DFX_board_t *bp) { + struct device __unused *bdev = bp->bus_dev; + int dfx_bus_eisa = DFX_BUS_EISA(bdev); int status; /* return code from adapter port control call */ - u32 slot_id; /* EISA-bus hardware id (DEC3001, DEC3002,...) */ u32 host_data; /* LW data returned from port control call */ DBG_printk("In dfx_bus_config_check...\n"); /* Configuration check only valid for EISA adapter */ - if (bp->bus_type == DFX_BUS_TYPE_EISA) - { - dfx_port_read_long(bp, PI_ESIC_K_SLOT_ID, &slot_id); - + if (dfx_bus_eisa) { /* * First check if revision 2 EISA controller. Rev. 1 cards used * PDQ revision B, so no workaround needed in this case. Rev. 3 @@ -725,14 +883,11 @@ static void __devinit dfx_bus_config_che * case, either. Only Rev. 2 cards used either Rev. D or E * chips, so we must verify the chip revision on Rev. 2 cards. */ - - if (slot_id == DEFEA_PROD_ID_2) - { + if (to_eisa_device(bdev)->id.driver_data == DEFEA_PROD_ID_2) { /* - * Revision 2 FDDI EISA controller found, so let's check PDQ - * revision of adapter. + * Revision 2 FDDI EISA controller found, + * so let's check PDQ revision of adapter. */ - status = dfx_hw_port_ctrl_req(bp, PI_PCTRL_M_SUB_CMD, PI_SUB_CMD_K_PDQ_REV_GET, @@ -806,13 +961,20 @@ static void __devinit dfx_bus_config_che */ static int __devinit dfx_driver_init(struct net_device *dev, - const char *print_name) + const char *print_name, + resource_size_t bar_start) { - DFX_board_t *bp = dev->priv; + DFX_board_t *bp = netdev_priv(dev); + struct device *bdev = bp->bus_dev; + int dfx_bus_pci = DFX_BUS_PCI(bdev); + int dfx_bus_eisa = DFX_BUS_EISA(bdev); + int dfx_bus_tc = DFX_BUS_TC(bdev); + int dfx_use_mmio = DFX_MMIO || dfx_bus_tc; int alloc_size; /* total buffer size needed */ char *top_v, *curr_v; /* virtual addrs into memory block */ dma_addr_t top_p, curr_p; /* physical addrs into memory block */ u32 data, le32; /* host data register value */ + char *board_name = NULL; DBG_printk("In dfx_driver_init...\n"); @@ -881,20 +1043,18 @@ static int __devinit dfx_driver_init(str */ memcpy(dev->dev_addr, bp->factory_mac_addr, FDDI_K_ALEN); - if (bp->bus_type == DFX_BUS_TYPE_EISA) - printk("%s: DEFEA at I/O addr = 0x%lX, IRQ = %d, " - "Hardware addr = %02X-%02X-%02X-%02X-%02X-%02X\n", - print_name, dev->base_addr, dev->irq, - dev->dev_addr[0], dev->dev_addr[1], - dev->dev_addr[2], dev->dev_addr[3], - dev->dev_addr[4], dev->dev_addr[5]); - else - printk("%s: DEFPA at I/O addr = 0x%lX, IRQ = %d, " - "Hardware addr = %02X-%02X-%02X-%02X-%02X-%02X\n", - print_name, dev->base_addr, dev->irq, - dev->dev_addr[0], dev->dev_addr[1], - dev->dev_addr[2], dev->dev_addr[3], - dev->dev_addr[4], dev->dev_addr[5]); + if (dfx_bus_tc) + board_name = "DEFTA"; + if (dfx_bus_eisa) + board_name = "DEFEA"; + if (dfx_bus_pci) + board_name = "DEFPA"; + pr_info("%s: %s at %saddr = 0x%llx, IRQ = %d, " + "Hardware addr = %02X-%02X-%02X-%02X-%02X-%02X\n", + print_name, board_name, dfx_use_mmio ? "" : "I/O ", + (long long)bar_start, dev->irq, + dev->dev_addr[0], dev->dev_addr[1], dev->dev_addr[2], + dev->dev_addr[3], dev->dev_addr[4], dev->dev_addr[5]); /* * Get memory for descriptor block, consumer block, and other buffers @@ -909,8 +1069,9 @@ static int __devinit dfx_driver_init(str #endif sizeof(PI_CONSUMER_BLOCK) + (PI_ALIGN_K_DESC_BLK - 1); - bp->kmalloced = top_v = pci_alloc_consistent(bp->pci_dev, alloc_size, - &bp->kmalloced_dma); + bp->kmalloced = top_v = dma_alloc_coherent(bp->bus_dev, alloc_size, + &bp->kmalloced_dma, + GFP_ATOMIC); if (top_v == NULL) { printk("%s: Could not allocate memory for host buffers " "and structures!\n", print_name); @@ -1220,14 +1381,15 @@ static int dfx_adap_init(DFX_board_t *bp static int dfx_open(struct net_device *dev) { + DFX_board_t *bp = netdev_priv(dev); int ret; - DFX_board_t *bp = dev->priv; DBG_printk("In dfx_open...\n"); /* Register IRQ - support shared interrupts by passing device ptr */ - ret = request_irq(dev->irq, dfx_interrupt, IRQF_SHARED, dev->name, dev); + ret = request_irq(dev->irq, dfx_interrupt, IRQF_SHARED, dev->name, + dev); if (ret) { printk(KERN_ERR "%s: Requested IRQ %d is busy\n", dev->name, dev->irq); return ret; @@ -1310,7 +1472,7 @@ static int dfx_open(struct net_device *d static int dfx_close(struct net_device *dev) { - DFX_board_t *bp = dev->priv; + DFX_board_t *bp = netdev_priv(dev); DBG_printk("In dfx_close...\n"); @@ -1646,7 +1808,7 @@ static void dfx_int_type_0_process(DFX_b static void dfx_int_common(struct net_device *dev) { - DFX_board_t *bp = dev->priv; + DFX_board_t *bp = netdev_priv(dev); PI_UINT32 port_status; /* Port Status register */ /* Process xmt interrupts - frequent case, so always call this routine */ @@ -1717,18 +1879,16 @@ static void dfx_int_common(struct net_de static irqreturn_t dfx_interrupt(int irq, void *dev_id, struct pt_regs *regs) { - struct net_device *dev = dev_id; - DFX_board_t *bp; /* private board structure pointer */ - - /* Get board pointer only if device structure is valid */ - - bp = dev->priv; - - /* See if we're already servicing an interrupt */ + struct net_device *dev = dev_id; + DFX_board_t *bp = netdev_priv(dev); + struct device *bdev = bp->bus_dev; + int dfx_bus_pci = DFX_BUS_PCI(bdev); + int dfx_bus_eisa = DFX_BUS_EISA(bdev); + int dfx_bus_tc = DFX_BUS_TC(bdev); /* Service adapter interrupts */ - if (bp->bus_type == DFX_BUS_TYPE_PCI) { + if (dfx_bus_pci) { u32 status; dfx_port_read_long(bp, PFI_K_REG_STATUS, &status); @@ -1752,10 +1912,12 @@ static irqreturn_t dfx_interrupt(int irq PFI_MODE_M_DMA_ENB)); spin_unlock(&bp->lock); - } else { + } + if (dfx_bus_eisa) { + unsigned long base_addr = to_eisa_device(bdev)->base_addr; u8 status; - dfx_port_read_byte(bp, PI_ESIC_K_IO_CONFIG_STAT_0, &status); + status = inb(base_addr + PI_ESIC_K_IO_CONFIG_STAT_0); if (!(status & PI_CONFIG_STAT_0_M_PEND)) return IRQ_NONE; @@ -1763,15 +1925,35 @@ static irqreturn_t dfx_interrupt(int irq /* Disable interrupts at the ESIC */ status &= ~PI_CONFIG_STAT_0_M_INT_ENB; - dfx_port_write_byte(bp, PI_ESIC_K_IO_CONFIG_STAT_0, status); + outb(base_addr + PI_ESIC_K_IO_CONFIG_STAT_0, status); /* Call interrupt service routine for this adapter */ dfx_int_common(dev); /* Reenable interrupts at the ESIC */ - dfx_port_read_byte(bp, PI_ESIC_K_IO_CONFIG_STAT_0, &status); + status = inb(base_addr + PI_ESIC_K_IO_CONFIG_STAT_0); status |= PI_CONFIG_STAT_0_M_INT_ENB; - dfx_port_write_byte(bp, PI_ESIC_K_IO_CONFIG_STAT_0, status); + outb(base_addr + PI_ESIC_K_IO_CONFIG_STAT_0, status); + + spin_unlock(&bp->lock); + } + if (dfx_bus_tc) { + u32 status; + + dfx_port_read_long(bp, PI_PDQ_K_REG_PORT_STATUS, &status); + if (!(status & (PI_PSTATUS_M_RCV_DATA_PENDING | + PI_PSTATUS_M_XMT_DATA_PENDING | + PI_PSTATUS_M_SMT_HOST_PENDING | + PI_PSTATUS_M_UNSOL_PENDING | + PI_PSTATUS_M_CMD_RSP_PENDING | + PI_PSTATUS_M_CMD_REQ_PENDING | + PI_PSTATUS_M_TYPE_0_PENDING))) + return IRQ_NONE; + + spin_lock(&bp->lock); + + /* Call interrupt service routine for this adapter */ + dfx_int_common(dev); spin_unlock(&bp->lock); } @@ -1825,7 +2007,7 @@ static irqreturn_t dfx_interrupt(int irq static struct net_device_stats *dfx_ctl_get_stats(struct net_device *dev) { - DFX_board_t *bp = dev->priv; + DFX_board_t *bp = netdev_priv(dev); /* Fill the bp->stats structure with driver-maintained counters */ @@ -2011,8 +2193,8 @@ static struct net_device_stats *dfx_ctl_ */ static void dfx_ctl_set_multicast_list(struct net_device *dev) - { - DFX_board_t *bp = dev->priv; +{ + DFX_board_t *bp = netdev_priv(dev); int i; /* used as index in for loop */ struct dev_mc_list *dmi; /* ptr to multicast addr entry */ @@ -2126,8 +2308,8 @@ static void dfx_ctl_set_multicast_list(s static int dfx_ctl_set_mac_address(struct net_device *dev, void *addr) { - DFX_board_t *bp = dev->priv; struct sockaddr *p_sockaddr = (struct sockaddr *)addr; + DFX_board_t *bp = netdev_priv(dev); /* Copy unicast address to driver-maintained structs and update count */ @@ -2766,9 +2948,9 @@ static int dfx_rcv_init(DFX_board_t *bp, my_skb_align(newskb, 128); bp->descr_block_virt->rcv_data[i + j].long_1 = - (u32)pci_map_single(bp->pci_dev, newskb->data, + (u32)dma_map_single(bp->bus_dev, newskb->data, NEW_SKB_SIZE, - PCI_DMA_FROMDEVICE); + DMA_FROM_DEVICE); /* * p_rcv_buff_va is only used inside the * kernel so we put the skb pointer here. @@ -2882,17 +3064,17 @@ static void dfx_rcv_queue_process( my_skb_align(newskb, 128); skb = (struct sk_buff *)bp->p_rcv_buff_va[entry]; - pci_unmap_single(bp->pci_dev, + dma_unmap_single(bp->bus_dev, bp->descr_block_virt->rcv_data[entry].long_1, NEW_SKB_SIZE, - PCI_DMA_FROMDEVICE); + DMA_FROM_DEVICE); skb_reserve(skb, RCV_BUFF_K_PADDING); bp->p_rcv_buff_va[entry] = (char *)newskb; bp->descr_block_virt->rcv_data[entry].long_1 = - (u32)pci_map_single(bp->pci_dev, + (u32)dma_map_single(bp->bus_dev, newskb->data, NEW_SKB_SIZE, - PCI_DMA_FROMDEVICE); + DMA_FROM_DEVICE); } else skb = NULL; } else @@ -3012,7 +3194,7 @@ static int dfx_xmt_queue_pkt( ) { - DFX_board_t *bp = dev->priv; + DFX_board_t *bp = netdev_priv(dev); u8 prod; /* local transmit producer index */ PI_XMT_DESCR *p_xmt_descr; /* ptr to transmit descriptor block entry */ XMT_DRIVER_DESCR *p_xmt_drv_descr; /* ptr to transmit driver descriptor */ @@ -3118,8 +3300,8 @@ static int dfx_xmt_queue_pkt( */ p_xmt_descr->long_0 = (u32) (PI_XMT_DESCR_M_SOP | PI_XMT_DESCR_M_EOP | ((skb->len) << PI_XMT_DESCR_V_SEG_LEN)); - p_xmt_descr->long_1 = (u32)pci_map_single(bp->pci_dev, skb->data, - skb->len, PCI_DMA_TODEVICE); + p_xmt_descr->long_1 = (u32)dma_map_single(bp->bus_dev, skb->data, + skb->len, DMA_TO_DEVICE); /* * Verify that descriptor is actually available @@ -3222,10 +3404,10 @@ static int dfx_xmt_done(DFX_board_t *bp) /* Return skb to operating system */ comp = bp->rcv_xmt_reg.index.xmt_comp; - pci_unmap_single(bp->pci_dev, + dma_unmap_single(bp->bus_dev, bp->descr_block_virt->xmt_data[comp].long_1, p_xmt_drv_descr->p_skb->len, - PCI_DMA_TODEVICE); + DMA_TO_DEVICE); dev_kfree_skb_irq(p_xmt_drv_descr->p_skb); /* @@ -3346,10 +3528,10 @@ static void dfx_xmt_flush( DFX_board_t * /* Return skb to operating system */ comp = bp->rcv_xmt_reg.index.xmt_comp; - pci_unmap_single(bp->pci_dev, + dma_unmap_single(bp->bus_dev, bp->descr_block_virt->xmt_data[comp].long_1, p_xmt_drv_descr->p_skb->len, - PCI_DMA_TODEVICE); + DMA_TO_DEVICE); dev_kfree_skb(p_xmt_drv_descr->p_skb); /* Increment transmit error counter */ @@ -3377,13 +3559,44 @@ static void dfx_xmt_flush( DFX_board_t * bp->cons_block_virt->xmt_rcv_data = prod_cons; } -static void __devexit dfx_remove_one_pci_or_eisa(struct pci_dev *pdev, struct net_device *dev) +/* + * ================== + * = dfx_unregister = + * ================== + * + * Overview: + * Shuts down an FDDI controller + * + * Returns: + * Condition code + * + * Arguments: + * bdev - pointer to device information + * + * Functional Description: + * + * Return Codes: + * None + * + * Assumptions: + * It compiles so it should work :-( (PCI cards do :-) + * + * Side Effects: + * Device structures for FDDI adapters (fddi0, fddi1, etc) are + * freed. + */ +static void __devexit dfx_unregister(struct device *bdev) { - DFX_board_t *bp = dev->priv; + struct net_device *dev = dev_get_drvdata(bdev); + DFX_board_t *bp = netdev_priv(dev); + int dfx_bus_pci = DFX_BUS_PCI(bdev); + int dfx_bus_tc = DFX_BUS_TC(bdev); + int dfx_use_mmio = DFX_MMIO || dfx_bus_tc; + resource_size_t bar_start = 0; /* pointer to port */ + resource_size_t bar_len = 0; /* resource length */ int alloc_size; /* total buffer size used */ unregister_netdev(dev); - release_region(dev->base_addr, pdev ? PFI_K_CSR_IO_LEN : PI_ESIC_K_CSR_IO_LEN ); alloc_size = sizeof(PI_DESCR_BLOCK) + PI_CMD_REQ_K_SIZE_MAX + PI_CMD_RSP_K_SIZE_MAX + @@ -3393,78 +3606,141 @@ static void __devexit dfx_remove_one_pci sizeof(PI_CONSUMER_BLOCK) + (PI_ALIGN_K_DESC_BLK - 1); if (bp->kmalloced) - pci_free_consistent(pdev, alloc_size, bp->kmalloced, - bp->kmalloced_dma); + dma_free_coherent(bdev, alloc_size, + bp->kmalloced, bp->kmalloced_dma); + + dfx_bus_uninit(dev); + + dfx_get_bars(bdev, &bar_start, &bar_len); + if (dfx_use_mmio) { + iounmap(bp->base.mem); + release_mem_region(bar_start, bar_len); + } else + release_region(bar_start, bar_len); + + if (dfx_bus_pci) + pci_disable_device(to_pci_dev(bdev)); + free_netdev(dev); } -static void __devexit dfx_remove_one (struct pci_dev *pdev) + +static int __devinit __unused dfx_dev_register(struct device *); +static int __devexit __unused dfx_dev_unregister(struct device *); + +#ifdef CONFIG_PCI +static int __devinit dfx_pci_register(struct pci_dev *, + const struct pci_device_id *); +static void __devexit dfx_pci_unregister(struct pci_dev *); + +static struct pci_device_id dfx_pci_table[] = { + { PCI_DEVICE(PCI_VENDOR_ID_DEC, PCI_DEVICE_ID_DEC_FDDI) }, + { } +}; +MODULE_DEVICE_TABLE(pci, dfx_pci_table); + +static struct pci_driver dfx_pci_driver = { + .name = "defxx", + .id_table = dfx_pci_table, + .probe = dfx_pci_register, + .remove = __devexit_p(dfx_pci_unregister), +}; + +static __devinit int dfx_pci_register(struct pci_dev *pdev, + const struct pci_device_id *ent) { - struct net_device *dev = pci_get_drvdata(pdev); + return dfx_register(&pdev->dev); +} - dfx_remove_one_pci_or_eisa(pdev, dev); - pci_set_drvdata(pdev, NULL); +static void __devexit dfx_pci_unregister(struct pci_dev *pdev) +{ + dfx_unregister(&pdev->dev); } +#endif /* CONFIG_PCI */ -static struct pci_device_id dfx_pci_tbl[] = { - { PCI_VENDOR_ID_DEC, PCI_DEVICE_ID_DEC_FDDI, PCI_ANY_ID, PCI_ANY_ID, }, - { 0, } +#ifdef CONFIG_EISA +static struct eisa_device_id dfx_eisa_table[] = { + { "DEC3001", DEFEA_PROD_ID_1 }, + { "DEC3002", DEFEA_PROD_ID_2 }, + { "DEC3003", DEFEA_PROD_ID_3 }, + { "DEC3004", DEFEA_PROD_ID_4 }, + { } }; -MODULE_DEVICE_TABLE(pci, dfx_pci_tbl); +MODULE_DEVICE_TABLE(eisa, dfx_eisa_table); -static struct pci_driver dfx_driver = { - .name = "defxx", - .probe = dfx_init_one, - .remove = __devexit_p(dfx_remove_one), - .id_table = dfx_pci_tbl, +static struct eisa_driver dfx_eisa_driver = { + .id_table = dfx_eisa_table, + .driver = { + .name = "defxx", + .bus = &eisa_bus_type, + .probe = dfx_dev_register, + .remove = __devexit_p(dfx_dev_unregister), + }, }; +#endif /* CONFIG_EISA */ -static int dfx_have_pci; -static int dfx_have_eisa; +#ifdef CONFIG_TC +static struct tc_device_id const dfx_tc_table[] = { + { "DEC ", "PMAF-FA " }, + { "DEC ", "PMAF-FD " }, + { "DEC ", "PMAF-FS " }, + { "DEC ", "PMAF-FU " }, + { } +}; +MODULE_DEVICE_TABLE(tc, dfx_tc_table); +static struct tc_driver dfx_tc_driver = { + .id_table = dfx_tc_table, + .driver = { + .name = "defxx", + .bus = &tc_bus_type, + .probe = dfx_dev_register, + .remove = __devexit_p(dfx_dev_unregister), + }, +}; +#endif /* CONFIG_TC */ -static void __exit dfx_eisa_cleanup(void) +static int __devinit __unused dfx_dev_register(struct device *dev) { - struct net_device *dev = root_dfx_eisa_dev; + int status; - while (dev) - { - struct net_device *tmp; - DFX_board_t *bp; - - bp = (DFX_board_t*)dev->priv; - tmp = bp->next; - dfx_remove_one_pci_or_eisa(NULL, dev); - dev = tmp; - } + status = dfx_register(dev); + if (!status) + get_device(dev); + return status; } -static int __init dfx_init(void) +static int __devexit __unused dfx_dev_unregister(struct device *dev) { - int rc_pci, rc_eisa; + put_device(dev); + dfx_unregister(dev); + return 0; +} - rc_pci = pci_module_init(&dfx_driver); - if (rc_pci >= 0) dfx_have_pci = 1; - - rc_eisa = dfx_eisa_init(); - if (rc_eisa >= 0) dfx_have_eisa = 1; - return ((rc_eisa < 0) ? 0 : rc_eisa) + ((rc_pci < 0) ? 0 : rc_pci); +static int __devinit dfx_init(void) +{ + int status; + + status = pci_register_driver(&dfx_pci_driver); + if (!status) + status = eisa_driver_register(&dfx_eisa_driver); + if (!status) + status = tc_register_driver(&dfx_tc_driver); + return status; } -static void __exit dfx_cleanup(void) +static void __devexit dfx_cleanup(void) { - if (dfx_have_pci) - pci_unregister_driver(&dfx_driver); - if (dfx_have_eisa) - dfx_eisa_cleanup(); - + tc_unregister_driver(&dfx_tc_driver); + eisa_driver_unregister(&dfx_eisa_driver); + pci_unregister_driver(&dfx_pci_driver); } module_init(dfx_init); module_exit(dfx_cleanup); MODULE_AUTHOR("Lawrence V. Stefani"); -MODULE_DESCRIPTION("DEC FDDIcontroller EISA/PCI (DEFEA/DEFPA) driver " +MODULE_DESCRIPTION("DEC FDDIcontroller TC/EISA/PCI (DEFTA/DEFEA/DEFPA) driver " DRV_VERSION " " DRV_RELDATE); MODULE_LICENSE("GPL"); diff -up --recursive --new-file linux-mips-2.6.18-20060920.macro/drivers/net/defxx.h linux-mips-2.6.18-20060920/drivers/net/defxx.h --- linux-mips-2.6.18-20060920.macro/drivers/net/defxx.h 2006-10-23 00:27:28.000000000 +0000 +++ linux-mips-2.6.18-20060920/drivers/net/defxx.h 2006-12-16 04:02:34.000000000 +0000 @@ -26,6 +26,7 @@ * 12-Sep-96 LVS Removed packet request header pointers. * 04 Aug 2003 macro Converted to the DMA API. * 23 Oct 2006 macro Big-endian host support. + * 14 Dec 2006 macro TURBOchannel support. */ #ifndef _DEFXX_H_ @@ -1471,9 +1472,17 @@ typedef union #endif /* __BIG_ENDIAN */ +/* Define TC PDQ CSR offset and length */ + +#define PI_TC_K_CSR_OFFSET 0x100000 +#define PI_TC_K_CSR_LEN 0x40 /* 64 bytes */ + /* Define EISA controller register offsets */ -#define PI_ESIC_K_BURST_HOLDOFF 0x040 +#define PI_ESIC_K_CSR_IO_LEN 0x80 /* 128 bytes */ + +#define PI_DEFEA_K_BURST_HOLDOFF 0x040 + #define PI_ESIC_K_SLOT_ID 0xC80 #define PI_ESIC_K_SLOT_CNTRL 0xC84 #define PI_ESIC_K_MEM_ADD_CMP_0 0xC85 @@ -1488,14 +1497,14 @@ typedef union #define PI_ESIC_K_MEM_ADD_LO_CMP_0 0xC8E #define PI_ESIC_K_MEM_ADD_LO_CMP_1 0xC8F #define PI_ESIC_K_MEM_ADD_LO_CMP_2 0xC90 -#define PI_ESIC_K_IO_CMP_0_0 0xC91 -#define PI_ESIC_K_IO_CMP_0_1 0xC92 -#define PI_ESIC_K_IO_CMP_1_0 0xC93 -#define PI_ESIC_K_IO_CMP_1_1 0xC94 -#define PI_ESIC_K_IO_CMP_2_0 0xC95 -#define PI_ESIC_K_IO_CMP_2_1 0xC96 -#define PI_ESIC_K_IO_CMP_3_0 0xC97 -#define PI_ESIC_K_IO_CMP_3_1 0xC98 +#define PI_ESIC_K_IO_ADD_CMP_0_0 0xC91 +#define PI_ESIC_K_IO_ADD_CMP_0_1 0xC92 +#define PI_ESIC_K_IO_ADD_CMP_1_0 0xC93 +#define PI_ESIC_K_IO_ADD_CMP_1_1 0xC94 +#define PI_ESIC_K_IO_ADD_CMP_2_0 0xC95 +#define PI_ESIC_K_IO_ADD_CMP_2_1 0xC96 +#define PI_ESIC_K_IO_ADD_CMP_3_0 0xC97 +#define PI_ESIC_K_IO_ADD_CMP_3_1 0xC98 #define PI_ESIC_K_IO_ADD_MASK_0_0 0xC99 #define PI_ESIC_K_IO_ADD_MASK_0_1 0xC9A #define PI_ESIC_K_IO_ADD_MASK_1_0 0xC9B @@ -1518,11 +1527,16 @@ typedef union #define PI_ESIC_K_INPUT_PORT 0xCAC #define PI_ESIC_K_OUTPUT_PORT 0xCAD #define PI_ESIC_K_FUNCTION_CNTRL 0xCAE -#define PI_ESIC_K_CSR_IO_LEN PI_ESIC_K_FUNCTION_CNTRL+1 /* always last reg + 1 */ -/* Define the value all drivers must write to the function control register. */ +/* Define the bits in the function control register. */ -#define PI_ESIC_K_FUNCTION_CNTRL_IO_ENB 0x03 +#define PI_FUNCTION_CNTRL_M_IOCS0 0x01 +#define PI_FUNCTION_CNTRL_M_IOCS1 0x02 +#define PI_FUNCTION_CNTRL_M_IOCS2 0x04 +#define PI_FUNCTION_CNTRL_M_IOCS3 0x08 +#define PI_FUNCTION_CNTRL_M_MEMCS0 0x10 +#define PI_FUNCTION_CNTRL_M_MEMCS1 0x20 +#define PI_FUNCTION_CNTRL_M_DMA 0x80 /* Define the bits in the slot control register. */ @@ -1540,6 +1554,10 @@ typedef union #define PI_BURST_HOLDOFF_V_RESERVED 1 #define PI_BURST_HOLDOFF_V_MEM_MAP 0 +/* Define the implicit mask of the Memory Address Mask Register. */ + +#define PI_MEM_ADD_MASK_M 0x3ff + /* * Define the fields in the IO Compare registers. * The driver must initialize the slot field with the slot ID shifted by the @@ -1577,6 +1595,7 @@ typedef union #define DEFEA_PROD_ID_1 0x0130A310 /* DEC product 300, rev 1 */ #define DEFEA_PROD_ID_2 0x0230A310 /* DEC product 300, rev 2 */ #define DEFEA_PROD_ID_3 0x0330A310 /* DEC product 300, rev 3 */ +#define DEFEA_PROD_ID_4 0x0430A310 /* DEC product 300, rev 4 */ /**********************************************/ /* Digital PFI Specification v1.0 Definitions */ @@ -1633,12 +1652,6 @@ typedef union #define PFI_STATUS_V_FIFO_EMPTY 1 #define PFI_STATUS_V_DMA_IN_PROGRESS 0 -#define DFX_MAX_EISA_SLOTS 16 /* maximum number of EISA slots to scan */ -#define DFX_MAX_NUM_BOARDS 8 /* maximum number of adapters supported */ - -#define DFX_BUS_TYPE_PCI 0 /* type code for DEC FDDIcontroller/PCI */ -#define DFX_BUS_TYPE_EISA 1 /* type code for DEC FDDIcontroller/EISA */ - #define DFX_FC_PRH2_PRH1_PRH0 0x54003820 /* Packet Request Header bytes + FC */ #define DFX_PRH0_BYTE 0x20 /* Packet Request Header byte 0 */ #define DFX_PRH1_BYTE 0x38 /* Packet Request Header byte 1 */ @@ -1756,10 +1769,11 @@ typedef struct DFX_board_tag /* Store device, bus-specific, and parameter information for this adapter */ struct net_device *dev; /* pointer to device structure */ - struct net_device *next; - u32 bus_type; /* bus type (0 == PCI, 1 == EISA) */ - u16 base_addr; /* base I/O address (same as dev->base_addr) */ - struct pci_dev * pci_dev; + union { + void __iomem *mem; + int port; + } base; /* base address */ + struct device *bus_dev; u32 full_duplex_enb; /* FDDI Full Duplex enable (1 == on, 2 == off) */ u32 req_ttrt; /* requested TTRT value (in 80ns units) */ u32 burst_size; /* adapter burst size (enumerated) */ From macro@linux-mips.org Wed Dec 20 12:03:29 2006 Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 20 Dec 2006 12:03:33 +0000 (GMT) Received: from pollux.ds.pg.gda.pl ([153.19.208.7]:1553 "EHLO pollux.ds.pg.gda.pl") by ftp.linux-mips.org with ESMTP id S28582464AbWLTMBz (ORCPT ); Wed, 20 Dec 2006 12:01:55 +0000 Received: from localhost (localhost [127.0.0.1]) by pollux.ds.pg.gda.pl (Postfix) with ESMTP id E2405FE2BD; Wed, 20 Dec 2006 13:01:44 +0100 (CET) X-Virus-Scanned: by amavisd-new at pollux.ds.pg.gda.pl Received: from pollux.ds.pg.gda.pl ([127.0.0.1]) by localhost (pollux.ds.pg.gda.pl [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ds8YdQ3dCWpa; Wed, 20 Dec 2006 13:01:44 +0100 (CET) Received: from piorun.ds.pg.gda.pl (piorun.ds.pg.gda.pl [153.19.208.8]) by pollux.ds.pg.gda.pl (Postfix) with ESMTP id 3BBC0FE2B5; Wed, 20 Dec 2006 13:01:44 +0100 (CET) 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 kBKC1qP0010560; Wed, 20 Dec 2006 13:01:52 +0100 Date: Wed, 20 Dec 2006 12:01:49 +0000 (GMT) From: "Maciej W. Rozycki" To: Andrew Morton , Jeff Garzik cc: linux-mips@linux-mips.org, linux-kernel@vger.kernel.org, netdev@vger.kernel.org Subject: [PATCH 2.6.20-rc1 04/10] EISA registration with !CONFIG_EISA Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: ClamAV 0.88.7/2360/Wed Dec 20 07:24:09 2006 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: 13480 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 This is a change for the EISA bus support to permit drivers to call un/registration functions even if EISA support has not been enabled. This is similar to what PCI (and now TC) does and reduces the need for #ifdef clutter. Signed-off-by: Maciej W. Rozycki --- This is required by the updated defxx driver. Please apply. Maciej patch-mips-2.6.18-20060920-eisa-register-0 diff -up --recursive --new-file linux-mips-2.6.18-20060920.macro/include/linux/eisa.h linux-mips-2.6.18-20060920/include/linux/eisa.h --- linux-mips-2.6.18-20060920.macro/include/linux/eisa.h 2003-10-10 04:00:31.000000000 +0000 +++ linux-mips-2.6.18-20060920/include/linux/eisa.h 2006-12-14 22:43:31.000000000 +0000 @@ -67,10 +67,20 @@ struct eisa_driver { #define to_eisa_driver(drv) container_of(drv,struct eisa_driver, driver) +/* These external functions are only available when EISA support is enabled. */ +#ifdef CONFIG_EISA + extern struct bus_type eisa_bus_type; int eisa_driver_register (struct eisa_driver *edrv); void eisa_driver_unregister (struct eisa_driver *edrv); +#else /* !CONFIG_EISA */ + +static inline int eisa_driver_register (struct eisa_driver *edrv) { return 0; } +static inline void eisa_driver_unregister (struct eisa_driver *edrv) { } + +#endif /* !CONFIG_EISA */ + /* Mimics pci.h... */ static inline void *eisa_get_drvdata (struct eisa_device *edev) { From macro@linux-mips.org Wed Dec 20 12:03:56 2006 Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 20 Dec 2006 12:04:02 +0000 (GMT) Received: from pollux.ds.pg.gda.pl ([153.19.208.7]:4113 "EHLO pollux.ds.pg.gda.pl") by ftp.linux-mips.org with ESMTP id S28582465AbWLTMCA (ORCPT ); Wed, 20 Dec 2006 12:02:00 +0000 Received: from localhost (localhost [127.0.0.1]) by pollux.ds.pg.gda.pl (Postfix) with ESMTP id 85CB4FE2C0; Wed, 20 Dec 2006 13:01:50 +0100 (CET) X-Virus-Scanned: by amavisd-new at pollux.ds.pg.gda.pl Received: from pollux.ds.pg.gda.pl ([127.0.0.1]) by localhost (pollux.ds.pg.gda.pl [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ibb28xyd8BhJ; Wed, 20 Dec 2006 13:01:49 +0100 (CET) Received: from piorun.ds.pg.gda.pl (piorun.ds.pg.gda.pl [153.19.208.8]) by pollux.ds.pg.gda.pl (Postfix) with ESMTP id BC100FE2B5; Wed, 20 Dec 2006 13:01:49 +0100 (CET) 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 kBKC1w7K010567; Wed, 20 Dec 2006 13:01:58 +0100 Date: Wed, 20 Dec 2006 12:01:55 +0000 (GMT) From: "Maciej W. Rozycki" To: Andrew Morton , Jeff Garzik cc: linux-mips@linux-mips.org, linux-kernel@vger.kernel.org, netdev@vger.kernel.org Subject: [PATCH 2.6.20-rc1 05/10] if_fddi.h: Add a missing inclusion Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: ClamAV 0.88.7/2360/Wed Dec 20 07:24:09 2006 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: 13481 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 This is a change to include in which is needed for "struct fddi_statistics". Signed-off-by: Maciej W. Rozycki --- Please apply. Maciej patch-mips-2.6.18-20060920-if_fddi-netdev-0 diff -up --recursive --new-file linux-mips-2.6.18-20060920.macro/include/linux/if_fddi.h linux-mips-2.6.18-20060920/include/linux/if_fddi.h --- linux-mips-2.6.18-20060920.macro/include/linux/if_fddi.h 2006-09-20 20:51:20.000000000 +0000 +++ linux-mips-2.6.18-20060920/include/linux/if_fddi.h 2006-12-14 04:36:58.000000000 +0000 @@ -103,6 +103,8 @@ struct fddihdr } __attribute__ ((packed)); #ifdef __KERNEL__ +#include + /* Define FDDI statistics structure */ struct fddi_statistics { From macro@linux-mips.org Wed Dec 20 12:04:25 2006 Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 20 Dec 2006 12:04:32 +0000 (GMT) Received: from pollux.ds.pg.gda.pl ([153.19.208.7]:9489 "EHLO pollux.ds.pg.gda.pl") by ftp.linux-mips.org with ESMTP id S28582470AbWLTMCJ (ORCPT ); Wed, 20 Dec 2006 12:02:09 +0000 Received: from localhost (localhost [127.0.0.1]) by pollux.ds.pg.gda.pl (Postfix) with ESMTP id C2D1FFE2BE; Wed, 20 Dec 2006 13:01:56 +0100 (CET) X-Virus-Scanned: by amavisd-new at pollux.ds.pg.gda.pl Received: from pollux.ds.pg.gda.pl ([127.0.0.1]) by localhost (pollux.ds.pg.gda.pl [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8nnZGGSh9vNG; Wed, 20 Dec 2006 13:01:56 +0100 (CET) Received: from piorun.ds.pg.gda.pl (piorun.ds.pg.gda.pl [153.19.208.8]) by pollux.ds.pg.gda.pl (Postfix) with ESMTP id 4D6E9FE2B5; Wed, 20 Dec 2006 13:01:56 +0100 (CET) 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 kBKC23ZG010594; Wed, 20 Dec 2006 13:02:04 +0100 Date: Wed, 20 Dec 2006 12:02:00 +0000 (GMT) From: "Maciej W. Rozycki" To: Andrew Morton , Antonino Daplas cc: linux-mips@linux-mips.org, linux-kernel@vger.kernel.org, linux-fbdev-devel@lists.sourceforge.net Subject: [PATCH 2.6.20-rc1 06/10] tgafb: TURBOchannel support Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: ClamAV 0.88.7/2360/Wed Dec 20 07:24:09 2006 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: 13482 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 This is support for the TC variations of the TGA boards (properly known as SFB+ or Smart Frame Buffer Plus boards). The 8-plane SFB+ board uses the Bt459 RAMDAC (unlike its PCI counterpart, which uses the Bt485), so bits have been added to support this chip as well. Signed-off-by: Maciej W. Rozycki --- These changes have been tested at the run time with an 8-plane and a 24-plane TC board (ZLX-E1 and ZLX-E3). As I have no PCI TGA hardware, I could not test these at the run time (it built with no problems for the Alpha), but I took care not to break support for these and I do hope I succeeded. ;-) Please apply. Maciej patch-mips-2.6.18-20060920-hx+-70 diff -up --recursive --new-file linux-mips-2.6.18-20060920.macro/drivers/video/Kconfig linux-mips-2.6.18-20060920/drivers/video/Kconfig --- linux-mips-2.6.18-20060920.macro/drivers/video/Kconfig 2006-08-21 04:55:25.000000000 +0000 +++ linux-mips-2.6.18-20060920/drivers/video/Kconfig 2006-12-12 14:39:01.000000000 +0000 @@ -531,14 +531,24 @@ config FB_HP300 default y config FB_TGA - tristate "TGA framebuffer support" - depends on FB && ALPHA + tristate "TGA/SFB+ framebuffer support" + depends on FB && (ALPHA || TC) select FB_CFB_FILLRECT select FB_CFB_COPYAREA select FB_CFB_IMAGEBLIT help - This is the frame buffer device driver for generic TGA graphic - cards. Say Y if you have one of those. + This is the frame buffer device driver for generic TGA and SFB+ + graphic cards. These include DEC ZLXp-E1, E2 and E3 PCI cards, + also known as PBXGA-A, B and C, and DEC ZLX-E1, E2 and E3 + TURBOchannel cards, also known as PMAGD-A, B and C. + + Due to hardware limitations ZLX-E2 and E3 cards are not supported + for DECstation 5000/200 systems. Additionally due to firmware + limitations these cards may cause troubles with booting DECstation + 5000/240 and /260 systems, but are fully supported under Linux if + you manage to get it going. + + Say Y if you have one of those. config FB_VESA bool "VESA VGA graphics support" diff -up --recursive --new-file linux-mips-2.6.18-20060920.macro/drivers/video/tgafb.c linux-mips-2.6.18-20060920/drivers/video/tgafb.c --- linux-mips-2.6.18-20060920.macro/drivers/video/tgafb.c 2006-12-14 01:00:00.000000000 +0000 +++ linux-mips-2.6.18-20060920/drivers/video/tgafb.c 2006-12-16 14:38:34.000000000 +0000 @@ -5,27 +5,45 @@ * Copyright (C) 1997 Geert Uytterhoeven * Copyright (C) 1999,2000 Martin Lucina, Tom Zerucha * Copyright (C) 2002 Richard Henderson + * Copyright (C) 2006 Maciej W. Rozycki * * 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. */ -#include -#include -#include -#include -#include -#include -#include #include -#include +#include +#include #include +#include +#include +#include +#include +#include #include +#include #include +#include +#include +#include + #include + #include