From fbuihuu@gmail.com Sat Dec 1 21:13:30 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Sat, 01 Dec 2007 21:13:38 +0000 (GMT) Received: from nf-out-0910.google.com ([64.233.182.191]:46018 "EHLO nf-out-0910.google.com") by ftp.linux-mips.org with ESMTP id S20025949AbXLAVNa (ORCPT ); Sat, 1 Dec 2007 21:13:30 +0000 Received: by nf-out-0910.google.com with SMTP id c10so2240681nfd for ; Sat, 01 Dec 2007 13:13:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:from:to:cc:subject:date:message-id:x-mailer; bh=gM3lwe+Nj1yr/1VlODck0P6qaeKvLRMgCeqtuEi5tBc=; b=fsdiol9sKTTx5RNXDGhh3vfEDc6Tev9mfq9WCIUUwdAAMMPMcoMYZ58ApkTWPribRHJpa3eytgS7xvd/3uu+02F360+CuQo8sSBbfRi9rsKALo+LvhFqETi3cOmL5v56nESnA93Gm7QbiHeKnw0ULZlWpiAxY+8BHUEwldbMgxA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=received:from:to:cc:subject:date:message-id:x-mailer; b=OfUmBMrXh5dDVlDpVWAd7p3WcN9Nljrg2y01yKqYhTJvWtOy4qN0/GGyKeH1uNEKuiSfngsMyNrISy7tH3w+9+UBCr2RzAVAdRlukyo3GZWzDtivaytbM8jXRAmHphCBkGFrsHIs4KQ4irDZU+VJGqL0qWx2QOl9jQTZbk4AND8= Received: by 10.78.131.8 with SMTP id e8mr4514560hud.1196543609381; Sat, 01 Dec 2007 13:13:29 -0800 (PST) Received: from localhost ( [82.235.205.153]) by mx.google.com with ESMTPS id y2sm20915525mug.2007.12.01.13.13.27 (version=TLSv1/SSLv3 cipher=OTHER); Sat, 01 Dec 2007 13:13:28 -0800 (PST) From: Franck Bui-Huu To: linux-arch@vger.kernel.org Cc: macro@linux-mips.org, linux-mips@linux-mips.org Subject: [RFC] Yet another __init annotation: __initbss Date: Sat, 1 Dec 2007 22:13:04 +0100 Message-Id: <1196543586-6698-1-git-send-email-fbuihuu@gmail.com> X-Mailer: git-send-email 1.5.3.5 Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 17652 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: fbuihuu@gmail.com Precedence: bulk X-list: linux-mips Hi, Currently, there's no way to make a data part of both the init section and the bss section. Therefore uninitialized init data consume useless space in the vmlinux image. Most of these data can be listed by: $ git grep -E "__initdata([^=]*| ?= ?0);" -- *.c This short patchset is an attempt to make these init data part of the bss section (done by patch #1) and therefore decreases the size of the vmlinux image. For now, only MIPS architecture handles this new section, this is done by patch #2. It's only a start and should be enough for discussion. Please consider, Franck From fbuihuu@gmail.com Sat Dec 1 21:13:59 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Sat, 01 Dec 2007 21:14:07 +0000 (GMT) Received: from mu-out-0910.google.com ([209.85.134.185]:1449 "EHLO mu-out-0910.google.com") by ftp.linux-mips.org with ESMTP id S20025982AbXLAVNe (ORCPT ); Sat, 1 Dec 2007 21:13:34 +0000 Received: by mu-out-0910.google.com with SMTP id g7so1556288muf for ; Sat, 01 Dec 2007 13:13:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:from:to:cc:subject:date:message-id:x-mailer:in-reply-to:references; bh=xlZi7R9X35y9cLmby02SPm62fCqBFY/yrZaPe67uqzY=; b=uOpK7vHSaZ+FPEUTbYoIeBmOybPxl++rocEB99go1qB8rnjHnmpODY+lNzRrM5Y/lqvX9DVPstgWxwVieArlNaRM9hLEBVZ84NpxZXta0/Ijy6jEASQdEfRlNpSvP1c+jpsOpcoedq3C118j4yo8eNTYPb37EfIerAYAHQjDn8M= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=received:from:to:cc:subject:date:message-id:x-mailer:in-reply-to:references; b=kpVHqkRiin6wU27V1Bd/cuEqVc/RxQecahTki6sGxyjNlhu+UmnGKb95+thovVp92jwW3RhLOg1+yyD4htKdHSQ8GKY6bZIAhHAybLmUKFm9tz4NplN7kH6gWBz+t3CI4HcXt5ztPNQsVm/9ierOEylR8GaHPvBjM2xVcVLRgho= Received: by 10.86.100.7 with SMTP id x7mr8724082fgb.1196543612441; Sat, 01 Dec 2007 13:13:32 -0800 (PST) Received: from localhost ( [82.235.205.153]) by mx.google.com with ESMTPS id p9sm11677479fkb.2007.12.01.13.13.30 (version=TLSv1/SSLv3 cipher=OTHER); Sat, 01 Dec 2007 13:13:31 -0800 (PST) From: Franck Bui-Huu To: linux-arch@vger.kernel.org Cc: macro@linux-mips.org, linux-mips@linux-mips.org Subject: [PATCH 1/2] Yet another __initxxx annotations: __initbss/__exitbss Date: Sat, 1 Dec 2007 22:13:05 +0100 Message-Id: <1196543586-6698-2-git-send-email-fbuihuu@gmail.com> X-Mailer: git-send-email 1.5.3.5 In-Reply-To: <1196543586-6698-1-git-send-email-fbuihuu@gmail.com> References: <1196543586-6698-1-git-send-email-fbuihuu@gmail.com> Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 17653 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: fbuihuu@gmail.com Precedence: bulk X-list: linux-mips Currently we can mark an initialized data to belong to the init.data section, this data being discarded after the boot process and the memory space used is taken back by the kernel. For _uninitialized_ data, we must use the same mechanism. The main drawback of this is that these data take space in the kernel image whereas this space is not really used. It's actually the reason why we prefer to not initialize a normal data when its initial value is 0. This patch creates two new init sections called '.bss.init' and '.bss.exit'. These sections are similar to the .{init,exit}.data ones but doesn't consume any space in the vmlinux image because they're part of the bss section except that they're freed once the kernel has booted. To select the BSS attribute for a peculiar section, the name of the section must start with 'bss.' pattern. This is at least how GCC 3.2/4.1.2 works and it's the reason why the 2 new sections haven't been called '.{init,exit}.bss'. To mark a data part of one of these 2 sections, we use the 2 new annotations: __initbss/__exitbss. All data marked as part of this section must not be initialized, of course. Signed-off-by: Franck Bui-Huu --- include/linux/init.h | 25 +++++++++++++++++-------- 1 files changed, 17 insertions(+), 8 deletions(-) diff --git a/include/linux/init.h b/include/linux/init.h index 5141381..19e04b2 100644 --- a/include/linux/init.h +++ b/include/linux/init.h @@ -43,6 +43,8 @@ #define __init __attribute__ ((__section__ (".init.text"))) __cold #define __initdata __attribute__ ((__section__ (".init.data"))) #define __exitdata __attribute__ ((__section__(".exit.data"))) +#define __initbss __attribute__ ((__section__ (".bss.init"))) +#define __exitbss __attribute__ ((__section__ (".bss.exit"))) #define __exit_call __attribute_used__ __attribute__ ((__section__ (".exitcall.exit"))) /* modpost check for section mismatches during the kernel build. @@ -71,6 +73,7 @@ #define __FINIT .previous #define __INITDATA .section ".init.data","aw" #define __INITDATA_REFOK .section ".data.init.refok","aw" +#define __INITBSS .section ".bss.init","aw",@nobits #ifndef __ASSEMBLY__ /* @@ -260,10 +263,12 @@ void __init parse_early_param(void); #define __devexit #define __devexitdata #else -#define __devinit __init -#define __devinitdata __initdata -#define __devexit __exit -#define __devexitdata __exitdata +#define __devinit __init +#define __devinitdata __initdata +#define __devinitbss __initbss +#define __devexit __exit +#define __devexitdata __exitdata +#define __devexitbss __exitbss #endif #ifdef CONFIG_HOTPLUG_CPU @@ -273,9 +278,11 @@ void __init parse_early_param(void); #define __cpuexitdata #else #define __cpuinit __init -#define __cpuinitdata __initdata -#define __cpuexit __exit +#define __cpuinitdata __initdata +#define __cpuinitbss __initbss +#define __cpuexit __exit #define __cpuexitdata __exitdata +#define __cpuexitbss __exitbss #endif #if defined(CONFIG_MEMORY_HOTPLUG) || defined(CONFIG_ACPI_HOTPLUG_MEMORY) \ @@ -286,9 +293,11 @@ void __init parse_early_param(void); #define __memexitdata #else #define __meminit __init -#define __meminitdata __initdata -#define __memexit __exit +#define __meminitdata __initdata +#define __meminitbss __meminitbss +#define __memexit __exit #define __memexitdata __exitdata +#define __memexitbss __exitbss #endif /* Functions marked as __devexit may be discarded at kernel link time, depending -- 1.5.3.5 From fbuihuu@gmail.com Sat Dec 1 21:14:27 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Sat, 01 Dec 2007 21:14:37 +0000 (GMT) Received: from mu-out-0910.google.com ([209.85.134.184]:42665 "EHLO mu-out-0910.google.com") by ftp.linux-mips.org with ESMTP id S20025999AbXLAVNh (ORCPT ); Sat, 1 Dec 2007 21:13:37 +0000 Received: by mu-out-0910.google.com with SMTP id g7so1556351muf for ; Sat, 01 Dec 2007 13:13:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:from:to:cc:subject:date:message-id:x-mailer:in-reply-to:references; bh=VoR5l8cqb6l44ze3jC00m6EsJ+7Hr4kjBiio300nvdA=; b=t3Y5tu+Mco9zBdrGwSLMhldk5nDZFoznR8numhYl8Ip35dGE8PIWXRg+95FMgxs2npsyQp3JLINi1xMVMt4+XrdCIWWwA9Y8QoFBBSNIvnNFPav+309gs9FjazhJCT0SklR6SFpsJSBeW8DK37shuyYY5ISpGsCY6sLcQEEwDCs= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=received:from:to:cc:subject:date:message-id:x-mailer:in-reply-to:references; b=dyieupMvVkLEIzG7X/PmfWslcTqjqcfdTZyecPW9OkCMbzlwZtv9GZTWlHq5ZydxWfXNxRGgkEZyJtjQ6Q725SndQ3AFJq7Hjnw+lIMNvJRapKAq4b3G9Q6V+QnMr+rWTvnYvgR1fEh7hUoU2SHZDuveGlARG0oIRtRLg8maPZo= Received: by 10.86.1.1 with SMTP id 1mr8773799fga.1196543615833; Sat, 01 Dec 2007 13:13:35 -0800 (PST) Received: from localhost ( [82.235.205.153]) by mx.google.com with ESMTPS id l12sm5003187fgb.2007.12.01.13.13.34 (version=TLSv1/SSLv3 cipher=OTHER); Sat, 01 Dec 2007 13:13:34 -0800 (PST) From: Franck Bui-Huu To: linux-arch@vger.kernel.org Cc: macro@linux-mips.org, linux-mips@linux-mips.org Subject: [PATCH 2/2] MIPS: vmlinux.lds.S: handle .{init,exit}.bss sections Date: Sat, 1 Dec 2007 22:13:06 +0100 Message-Id: <1196543586-6698-3-git-send-email-fbuihuu@gmail.com> X-Mailer: git-send-email 1.5.3.5 In-Reply-To: <1196543586-6698-1-git-send-email-fbuihuu@gmail.com> References: <1196543586-6698-1-git-send-email-fbuihuu@gmail.com> Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 17654 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: fbuihuu@gmail.com Precedence: bulk X-list: linux-mips Signed-off-by: Franck Bui-Huu --- arch/mips/kernel/vmlinux.lds.S | 21 ++++++++++++++++----- 1 files changed, 16 insertions(+), 5 deletions(-) diff --git a/arch/mips/kernel/vmlinux.lds.S b/arch/mips/kernel/vmlinux.lds.S index 5fc2398..8508d3c 100644 --- a/arch/mips/kernel/vmlinux.lds.S +++ b/arch/mips/kernel/vmlinux.lds.S @@ -110,7 +110,7 @@ SECTIONS _edata = .; /* End of data section */ /* will be freed after init */ - . = ALIGN(_PAGE_SIZE); /* Init code and data */ + . = ALIGN(_PAGE_SIZE); /* Init code, data and bss */ __init_begin = .; .init.text : { _sinittext = .; @@ -158,12 +158,23 @@ SECTIONS } #endif PERCPU(_PAGE_SIZE) - . = ALIGN(_PAGE_SIZE); - __init_end = .; - /* freed after init ends here */ + /* + * We keep init/exit bss sections here to have only one + * segment to load. Note that .bss.exit is also discarded + * at runtime for the same reason as above. + */ + .exit.bss : { + *(.bss.exit) + } __bss_start = .; /* BSS */ - .sbss : { + .init.bss : { + *(.bss.init) + } + . = ALIGN(_PAGE_SIZE); + __init_end = .; /* freed after init ends here */ + + .sbss : { *(.sbss) *(.scommon) } -- 1.5.3.5 From jgarzik@pobox.com Sat Dec 1 21:57:28 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Sat, 01 Dec 2007 21:57:37 +0000 (GMT) Received: from srv5.dvmed.net ([207.36.208.214]:22407 "EHLO mail.dvmed.net") by ftp.linux-mips.org with ESMTP id S20026116AbXLAV5V (ORCPT ); Sat, 1 Dec 2007 21:57:21 +0000 Received: from cpe-069-134-071-233.nc.res.rr.com ([69.134.71.233] helo=core.yyz.us) by mail.dvmed.net with esmtpsa (Exim 4.63 #1 (Red Hat Linux)) id 1IyaKm-0001AY-Q8; Sat, 01 Dec 2007 21:57:13 +0000 Message-ID: <4751D8B7.1060508@pobox.com> Date: Sat, 01 Dec 2007 16:57:11 -0500 From: Jeff Garzik User-Agent: Thunderbird 2.0.0.9 (X11/20071115) MIME-Version: 1.0 To: Thomas Bogendoerfer CC: netdev@vger.kernel.org, linux-mips@linux-mips.org, ralf@linux-mips.org Subject: Re: [PATCH] SGISEEQ: use cached memory access to make driver work on IP28 References: <20071126223934.84BE7C2B26@solo.franken.de> In-Reply-To: <20071126223934.84BE7C2B26@solo.franken.de> 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: 17655 X-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 Thomas Bogendoerfer wrote: > Following patch is clearly 2.6.25 material and is needed to get SGI IP28 > machines supported. > > Thomas. > > SGI IP28 machines would need special treatment (enable adding addtional > wait states) when accessing memory uncached. To avoid this pain I changed > the driver to use only cached access to memory. > > Signed-off-by: Thomas Bogendoerfer applied. As I have noted to you previously, /please/ put extraneous comments /after/ a "---" separator, so that they are not copied by git-am (Linus's email patch import tool) into the permanent kernel changelog. The above should look like: SGI IP28 machines would need special treatment (enable adding addtional wait states) when accessing memory uncached. To avoid this pain I changed the driver to use only cached access to memory. Signed-off-by: Thomas Bogendoerfer --- Following patch is clearly 2.6.25 material and is needed to get SGI IP28 machines supported. Thomas. drivers/net/sgiseeq.c | 239 ++++++++++++++++++++++++++++++++++--------------- 1 files changed, 166 insertions(+), 73 deletions(-) See Documentation/SubmittingPatches for more details, in particular "14) The canonical patch format" or http://linux.yyz.us/patch-format.html Jeff From rmk+linux-mips=linux-mips.org@arm.linux.org.uk Sat Dec 1 23:22:14 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Sat, 01 Dec 2007 23:22:23 +0000 (GMT) Received: from caramon.arm.linux.org.uk ([78.32.30.218]:50665 "EHLO caramon.arm.linux.org.uk") by ftp.linux-mips.org with ESMTP id S20026751AbXLAXWO (ORCPT ); Sat, 1 Dec 2007 23:22:14 +0000 Received: from flint.arm.linux.org.uk ([2002:4e20:1eda:1:201:2ff:fe14:8fad]) by caramon.arm.linux.org.uk with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.62) (envelope-from ) id 1IybbN-0002ly-SD; Sat, 01 Dec 2007 23:18:26 +0000 Received: from rmk by flint.arm.linux.org.uk with local (Exim 4.62) (envelope-from ) id 1IybbL-0004Qn-QZ; Sat, 01 Dec 2007 23:18:23 +0000 Date: Sat, 1 Dec 2007 23:18:23 +0000 From: Russell King To: Franck Bui-Huu Cc: linux-arch@vger.kernel.org, macro@linux-mips.org, linux-mips@linux-mips.org Subject: Re: [PATCH 1/2] Yet another __initxxx annotations: __initbss/__exitbss Message-ID: <20071201231823.GB5411@flint.arm.linux.org.uk> Mail-Followup-To: Franck Bui-Huu , linux-arch@vger.kernel.org, macro@linux-mips.org, linux-mips@linux-mips.org References: <1196543586-6698-1-git-send-email-fbuihuu@gmail.com> <1196543586-6698-2-git-send-email-fbuihuu@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1196543586-6698-2-git-send-email-fbuihuu@gmail.com> User-Agent: Mutt/1.4.2.1i Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 17656 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: rmk@arm.linux.org.uk Precedence: bulk X-list: linux-mips On Sat, Dec 01, 2007 at 10:13:05PM +0100, Franck Bui-Huu wrote: > To select the BSS attribute for a peculiar section, the name of the > section must start with 'bss.' pattern. This is at least how GCC > 3.2/4.1.2 works and it's the reason why the 2 new sections haven't > been called '.{init,exit}.bss'. > > To mark a data part of one of these 2 sections, we use the 2 new > annotations: __initbss/__exitbss. > > All data marked as part of this section must not be initialized, > of course. Are you sure about this? The gcc manual for 4.1.1 says: Use the `section' attribute with an _initialized_ definition of a _global_ variable, as shown in the example. GCC issues a warning and otherwise ignores the `section' attribute in uninitialized variable declarations. which has had that paragraph since at least 3.4.0. Either the GCC documentation is wrong or the compiler is misbehaving if what you say works. Either way, I'd be nervous about relying on this given that GCC developers like to change the compiler behaviour. Suggest getting the GCC developers nailed down to ensure we know what the intended compiler behaviour is (and getting the docs to reflect that) before relying on the existing behaviour. -- Russell King Linux kernel 2.6 ARM Linux - http://www.arm.linux.org.uk/ maintainer of: From tsbogend@alpha.franken.de Sun Dec 2 11:13:39 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Sun, 02 Dec 2007 11:13:47 +0000 (GMT) Received: from elvis.franken.de ([193.175.24.41]:6113 "EHLO elvis.franken.de") by ftp.linux-mips.org with ESMTP id S20022282AbXLBLNj (ORCPT ); Sun, 2 Dec 2007 11:13:39 +0000 Received: from uucp (helo=solo.franken.de) by elvis.franken.de with local-bsmtp (Exim 3.36 #1) id 1IymiQ-0000XZ-00; Sun, 02 Dec 2007 12:10:26 +0100 Received: by solo.franken.de (Postfix, from userid 1000) id 6A926C2EB4; Sun, 2 Dec 2007 11:33:09 +0100 (CET) From: Thomas Bogendoerfer To: linux-scsi@vger.kernel.org, linux-mips@linux-mips.org cc: ralf@linux-mips.org, James.Bottomley@HansenPartnership.com Subject: [UPDATED PATCH] SGIWD93: use cached memory access to make driver work on IP28 Message-Id: <20071202103309.6A926C2EB4@solo.franken.de> Date: Sun, 2 Dec 2007 11:33:09 +0100 (CET) Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 17657 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: tsbogend@alpha.franken.de Precedence: bulk X-list: linux-mips SGI IP28 machines would need special treatment (enable adding addtional wait states) when accessing memory uncached. To avoid this pain I changed the driver to use only cached access to memory. Signed-off-by: Thomas Bogendoerfer --- Changes to last version: - added Kconfig change to make selection for similair SGI boxes easier drivers/scsi/Kconfig | 2 +- drivers/scsi/sgiwd93.c | 64 +++++++++++++++++++++++++++++------------------ 2 files changed, 40 insertions(+), 26 deletions(-) diff --git a/drivers/scsi/Kconfig b/drivers/scsi/Kconfig index a6676be..2a071b0 100644 --- a/drivers/scsi/Kconfig +++ b/drivers/scsi/Kconfig @@ -345,7 +345,7 @@ config ISCSI_TCP config SGIWD93_SCSI tristate "SGI WD93C93 SCSI Driver" - depends on SGI_IP22 && SCSI + depends on SGI_HAS_WD93 && SCSI help If you have a Western Digital WD93 SCSI controller on an SGI MIPS system, say Y. Otherwise, say N. diff --git a/drivers/scsi/sgiwd93.c b/drivers/scsi/sgiwd93.c index eef8275..e64ddee 100644 --- a/drivers/scsi/sgiwd93.c +++ b/drivers/scsi/sgiwd93.c @@ -33,10 +33,9 @@ struct ip22_hostdata { struct WD33C93_hostdata wh; - struct hpc_data { - dma_addr_t dma; - void *cpu; - } hd; + dma_addr_t dma; + void *cpu; + void *dev; }; #define host_to_hostdata(host) ((struct ip22_hostdata *)((host)->hostdata)) @@ -46,6 +45,11 @@ struct hpc_chunk { u32 _padding; /* align to quadword boundary */ }; +/* space for hpc dma descriptors */ +#define HPC_DMA_SIZE PAGE_SIZE + +#define DMA_DIR(d) ((d == DATA_OUT_DIR) ? DMA_TO_DEVICE : DMA_FROM_DEVICE) + static irqreturn_t sgiwd93_intr(int irq, void *dev_id) { struct Scsi_Host * host = dev_id; @@ -59,15 +63,17 @@ static irqreturn_t sgiwd93_intr(int irq, void *dev_id) } static inline -void fill_hpc_entries(struct hpc_chunk *hcp, struct scsi_cmnd *cmd, int datainp) +void fill_hpc_entries(struct ip22_hostdata *hd, struct scsi_cmnd *cmd, int din) { unsigned long len = cmd->SCp.this_residual; void *addr = cmd->SCp.ptr; dma_addr_t physaddr; unsigned long count; + struct hpc_chunk *hcp; - physaddr = dma_map_single(NULL, addr, len, cmd->sc_data_direction); + physaddr = dma_map_single(hd->dev, addr, len, DMA_DIR(din)); cmd->SCp.dma_handle = physaddr; + hcp = hd->cpu; while (len) { /* @@ -89,6 +95,9 @@ void fill_hpc_entries(struct hpc_chunk *hcp, struct scsi_cmnd *cmd, int datainp) */ hcp->desc.pbuf = 0; hcp->desc.cntinfo = HPCDMA_EOX; + dma_cache_sync(hd->dev, hd->cpu, + (unsigned long)(hcp + 1) - (unsigned long)hd->cpu, + DMA_TO_DEVICE); } static int dma_setup(struct scsi_cmnd *cmd, int datainp) @@ -96,9 +105,8 @@ static int dma_setup(struct scsi_cmnd *cmd, int datainp) struct ip22_hostdata *hdata = host_to_hostdata(cmd->device->host); struct hpc3_scsiregs *hregs = (struct hpc3_scsiregs *) cmd->device->host->base; - struct hpc_chunk *hcp = (struct hpc_chunk *) hdata->hd.cpu; - pr_debug("dma_setup: datainp<%d> hcp<%p> ", datainp, hcp); + pr_debug("dma_setup: datainp<%d> hcp<%p> ", datainp, hdata->cpu); hdata->wh.dma_dir = datainp; @@ -111,12 +119,12 @@ static int dma_setup(struct scsi_cmnd *cmd, int datainp) if (cmd->SCp.ptr == NULL || cmd->SCp.this_residual == 0) return 1; - fill_hpc_entries(hcp, cmd, datainp); + fill_hpc_entries(hdata, cmd, datainp); pr_debug(" HPCGO\n"); /* Start up the HPC. */ - hregs->ndptr = hdata->hd.dma; + hregs->ndptr = hdata->dma; if (datainp) hregs->ctrl = HPC3_SCTRL_ACTIVE; else @@ -134,6 +142,9 @@ static void dma_stop(struct Scsi_Host *instance, struct scsi_cmnd *SCpnt, if (!SCpnt) return; + if (SCpnt->SCp.ptr == NULL || SCpnt->SCp.this_residual == 0) + return; + hregs = (struct hpc3_scsiregs *) SCpnt->device->host->base; pr_debug("dma_stop: status<%d> ", status); @@ -145,8 +156,9 @@ static void dma_stop(struct Scsi_Host *instance, struct scsi_cmnd *SCpnt, barrier(); } hregs->ctrl = 0; - dma_unmap_single(NULL, SCpnt->SCp.dma_handle, SCpnt->SCp.this_residual, - SCpnt->sc_data_direction); + dma_unmap_single(hdata->dev, SCpnt->SCp.dma_handle, + SCpnt->SCp.this_residual, + DMA_DIR(hdata->wh.dma_dir)); pr_debug("\n"); } @@ -160,22 +172,23 @@ void sgiwd93_reset(unsigned long base) hregs->ctrl = 0; } -static inline void init_hpc_chain(struct hpc_data *hd) +static inline void init_hpc_chain(void *dev, struct ip22_hostdata *hdata) { - struct hpc_chunk *hcp = (struct hpc_chunk *) hd->cpu; - struct hpc_chunk *dma = (struct hpc_chunk *) hd->dma; + struct hpc_chunk *hcp = (struct hpc_chunk *)hdata->cpu; + dma_addr_t dma = hdata->dma; unsigned long start, end; start = (unsigned long) hcp; - end = start + PAGE_SIZE; + end = start + HPC_DMA_SIZE; while (start < end) { - hcp->desc.pnext = (u32) (dma + 1); + hcp->desc.pnext = (u32) (dma + sizeof(struct hpc_chunk)); hcp->desc.cntinfo = HPCDMA_EOX; - hcp++; dma++; + hcp++; + dma += sizeof(struct hpc_chunk); start += sizeof(struct hpc_chunk); }; hcp--; - hcp->desc.pnext = hd->dma; + hcp->desc.pnext = hdata->dma; } static int sgiwd93_bus_reset(struct scsi_cmnd *cmd) @@ -234,16 +247,17 @@ static int __init sgiwd93_probe(struct platform_device *pdev) host->irq = irq; hdata = host_to_hostdata(host); - hdata->hd.cpu = dma_alloc_coherent(&pdev->dev, PAGE_SIZE, - &hdata->hd.dma, GFP_KERNEL); - if (!hdata->hd.cpu) { + hdata->dev = &pdev->dev; + hdata->cpu = dma_alloc_noncoherent(&pdev->dev, HPC_DMA_SIZE, + &hdata->dma, GFP_KERNEL); + if (!hdata->cpu) { printk(KERN_WARNING "sgiwd93: Could not allocate memory for " "host %d buffer.\n", unit); err = -ENOMEM; goto out_put; } - init_hpc_chain(&hdata->hd); + init_hpc_chain(&pdev->dev, hdata); regs.SASR = wdregs + 3; regs.SCMD = wdregs + 7; @@ -273,7 +287,7 @@ static int __init sgiwd93_probe(struct platform_device *pdev) out_irq: free_irq(irq, host); out_free: - dma_free_coherent(NULL, PAGE_SIZE, hdata->hd.cpu, hdata->hd.dma); + dma_free_noncoherent(NULL, HPC_DMA_SIZE, hdata->cpu, hdata->dma); out_put: scsi_host_put(host); out: @@ -289,7 +303,7 @@ static void __exit sgiwd93_remove(struct platform_device *pdev) scsi_remove_host(host); free_irq(pd->irq, host); - dma_free_coherent(&pdev->dev, PAGE_SIZE, hdata->hd.cpu, hdata->hd.dma); + dma_free_noncoherent(&pdev->dev, HPC_DMA_SIZE, hdata->cpu, hdata->dma); scsi_host_put(host); } From tsbogend@alpha.franken.de Sun Dec 2 11:14:08 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Sun, 02 Dec 2007 11:14:12 +0000 (GMT) Received: from elvis.franken.de ([193.175.24.41]:7137 "EHLO elvis.franken.de") by ftp.linux-mips.org with ESMTP id S20022363AbXLBLNn (ORCPT ); Sun, 2 Dec 2007 11:13:43 +0000 Received: from uucp (helo=solo.franken.de) by elvis.franken.de with local-bsmtp (Exim 3.36 #1) id 1IymiQ-0000XZ-01; Sun, 02 Dec 2007 12:10:26 +0100 Received: by solo.franken.de (Postfix, from userid 1000) id 75E51C2EB5; Sun, 2 Dec 2007 11:33:12 +0100 (CET) From: Thomas Bogendoerfer To: netdev@vger.kernel.org, linux-mips@linux-mips.org cc: ralf@linux-mips.org, jgarzik@pobox.com Subject: [UPDATED PATCH] SGISEEQ: use cached memory access to make driver work on IP28 Message-Id: <20071202103312.75E51C2EB5@solo.franken.de> Date: Sun, 2 Dec 2007 11:33:12 +0100 (CET) Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 17658 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: tsbogend@alpha.franken.de Precedence: bulk X-list: linux-mips SGI IP28 machines would need special treatment (enable adding addtional wait states) when accessing memory uncached. To avoid this pain I changed the driver to use only cached access to memory. Signed-off-by: Thomas Bogendoerfer --- Changes to last version: - Use inline functions for dma_sync_* instead of macros (suggested by Ralf) - added Kconfig change to make selection for similair SGI boxes easier drivers/net/Kconfig | 2 +- drivers/net/sgiseeq.c | 243 ++++++++++++++++++++++++++++++++++--------------- 2 files changed, 171 insertions(+), 74 deletions(-) diff --git a/drivers/net/Kconfig b/drivers/net/Kconfig index 7a55bc1..9cbd5de 100644 --- a/drivers/net/Kconfig +++ b/drivers/net/Kconfig @@ -1795,7 +1795,7 @@ config DE620 config SGISEEQ tristate "SGI Seeq ethernet controller support" - depends on SGI_IP22 + depends on SGI_HAS_SEEQ help Say Y here if you have an Seeq based Ethernet network card. This is used in many Silicon Graphics machines. diff --git a/drivers/net/sgiseeq.c b/drivers/net/sgiseeq.c index ff40563..c69bb8b 100644 --- a/drivers/net/sgiseeq.c +++ b/drivers/net/sgiseeq.c @@ -12,7 +12,6 @@ #include #include #include -#include #include #include #include @@ -53,14 +52,27 @@ static char *sgiseeqstr = "SGI Seeq8003"; sp->tx_old + (SEEQ_TX_BUFFERS - 1) - sp->tx_new : \ sp->tx_old - sp->tx_new - 1) +#define VIRT_TO_DMA(sp, v) ((sp)->srings_dma + \ + (dma_addr_t)((unsigned long)(v) - \ + (unsigned long)((sp)->rx_desc))) + +/* Copy frames shorter than rx_copybreak, otherwise pass on up in + * a full sized sk_buff. Value of 100 stolen from tulip.c (!alpha). + */ +static int rx_copybreak = 100; + +#define PAD_SIZE (128 - sizeof(struct hpc_dma_desc) - sizeof(void *)) + struct sgiseeq_rx_desc { volatile struct hpc_dma_desc rdma; - volatile signed int buf_vaddr; + u8 padding[PAD_SIZE]; + struct sk_buff *skb; }; struct sgiseeq_tx_desc { volatile struct hpc_dma_desc tdma; - volatile signed int buf_vaddr; + u8 padding[PAD_SIZE]; + struct sk_buff *skb; }; /* @@ -96,6 +108,18 @@ struct sgiseeq_private { spinlock_t tx_lock; }; +static inline void dma_sync_desc_cpu(struct net_device *dev, void *addr) +{ + dma_cache_sync(dev->dev.parent, addr, sizeof(struct sgiseeq_rx_desc), + DMA_FROM_DEVICE); +} + +static inline void dma_sync_desc_dev(struct net_device *dev, void *addr) +{ + dma_cache_sync(dev->dev.parent, addr, sizeof(struct sgiseeq_rx_desc), + DMA_TO_DEVICE); +} + static inline void hpc3_eth_reset(struct hpc3_ethregs *hregs) { hregs->reset = HPC3_ERST_CRESET | HPC3_ERST_CLRIRQ; @@ -163,35 +187,55 @@ static int seeq_init_ring(struct net_device *dev) /* Setup tx ring. */ for(i = 0; i < SEEQ_TX_BUFFERS; i++) { - if (!sp->tx_desc[i].tdma.pbuf) { - unsigned long buffer; - - buffer = (unsigned long) kmalloc(PKT_BUF_SZ, GFP_KERNEL); - if (!buffer) - return -ENOMEM; - sp->tx_desc[i].buf_vaddr = CKSEG1ADDR(buffer); - sp->tx_desc[i].tdma.pbuf = CPHYSADDR(buffer); - } sp->tx_desc[i].tdma.cntinfo = TCNTINFO_INIT; + dma_sync_desc_dev(dev, &sp->tx_desc[i]); } /* And now the rx ring. */ for (i = 0; i < SEEQ_RX_BUFFERS; i++) { if (!sp->rx_desc[i].rdma.pbuf) { - unsigned long buffer; + dma_addr_t dma_addr; + struct sk_buff *skb = netdev_alloc_skb(dev, PKT_BUF_SZ); - buffer = (unsigned long) kmalloc(PKT_BUF_SZ, GFP_KERNEL); - if (!buffer) + if (skb == NULL) return -ENOMEM; - sp->rx_desc[i].buf_vaddr = CKSEG1ADDR(buffer); - sp->rx_desc[i].rdma.pbuf = CPHYSADDR(buffer); + skb_reserve(skb, 2); + dma_addr = dma_map_single(dev->dev.parent, + skb->data - 2, + PKT_BUF_SZ, DMA_FROM_DEVICE); + sp->rx_desc[i].skb = skb; + sp->rx_desc[i].rdma.pbuf = dma_addr; } sp->rx_desc[i].rdma.cntinfo = RCNTINFO_INIT; + dma_sync_desc_dev(dev, &sp->rx_desc[i]); } sp->rx_desc[i - 1].rdma.cntinfo |= HPCDMA_EOR; + dma_sync_desc_dev(dev, &sp->rx_desc[i - 1]); return 0; } +static void seeq_purge_ring(struct net_device *dev) +{ + struct sgiseeq_private *sp = netdev_priv(dev); + int i; + + /* clear tx ring. */ + for (i = 0; i < SEEQ_TX_BUFFERS; i++) { + if (sp->tx_desc[i].skb) { + dev_kfree_skb(sp->tx_desc[i].skb); + sp->tx_desc[i].skb = NULL; + } + } + + /* And now the rx ring. */ + for (i = 0; i < SEEQ_RX_BUFFERS; i++) { + if (sp->rx_desc[i].skb) { + dev_kfree_skb(sp->rx_desc[i].skb); + sp->rx_desc[i].skb = NULL; + } + } +} + #ifdef DEBUG static struct sgiseeq_private *gpriv; static struct net_device *gdev; @@ -258,8 +302,8 @@ static int init_seeq(struct net_device *dev, struct sgiseeq_private *sp, sregs->tstat = TSTAT_INIT_SEEQ; } - hregs->rx_ndptr = CPHYSADDR(sp->rx_desc); - hregs->tx_ndptr = CPHYSADDR(sp->tx_desc); + hregs->rx_ndptr = VIRT_TO_DMA(sp, sp->rx_desc); + hregs->tx_ndptr = VIRT_TO_DMA(sp, sp->tx_desc); seeq_go(sp, hregs, sregs); return 0; @@ -283,69 +327,90 @@ static inline void rx_maybe_restart(struct sgiseeq_private *sp, struct sgiseeq_regs *sregs) { if (!(hregs->rx_ctrl & HPC3_ERXCTRL_ACTIVE)) { - hregs->rx_ndptr = CPHYSADDR(sp->rx_desc + sp->rx_new); + hregs->rx_ndptr = VIRT_TO_DMA(sp, sp->rx_desc + sp->rx_new); seeq_go(sp, hregs, sregs); } } -#define for_each_rx(rd, sp) for((rd) = &(sp)->rx_desc[(sp)->rx_new]; \ - !((rd)->rdma.cntinfo & HPCDMA_OWN); \ - (rd) = &(sp)->rx_desc[(sp)->rx_new]) - static inline void sgiseeq_rx(struct net_device *dev, struct sgiseeq_private *sp, struct hpc3_ethregs *hregs, struct sgiseeq_regs *sregs) { struct sgiseeq_rx_desc *rd; struct sk_buff *skb = NULL; + struct sk_buff *newskb; unsigned char pkt_status; - unsigned char *pkt_pointer = NULL; int len = 0; unsigned int orig_end = PREV_RX(sp->rx_new); /* Service every received packet. */ - for_each_rx(rd, sp) { + rd = &sp->rx_desc[sp->rx_new]; + dma_sync_desc_cpu(dev, rd); + while (!(rd->rdma.cntinfo & HPCDMA_OWN)) { len = PKT_BUF_SZ - (rd->rdma.cntinfo & HPCDMA_BCNT) - 3; - pkt_pointer = (unsigned char *)(long)rd->buf_vaddr; - pkt_status = pkt_pointer[len + 2]; - + dma_unmap_single(dev->dev.parent, rd->rdma.pbuf, + PKT_BUF_SZ, DMA_FROM_DEVICE); + pkt_status = rd->skb->data[len]; if (pkt_status & SEEQ_RSTAT_FIG) { /* Packet is OK. */ - skb = dev_alloc_skb(len + 2); - - if (skb) { - skb_reserve(skb, 2); - skb_put(skb, len); - - /* Copy out of kseg1 to avoid silly cache flush. */ - skb_copy_to_linear_data(skb, pkt_pointer + 2, len); - skb->protocol = eth_type_trans(skb, dev); - - /* We don't want to receive our own packets */ - if (memcmp(eth_hdr(skb)->h_source, dev->dev_addr, ETH_ALEN)) { + /* We don't want to receive our own packets */ + if (memcmp(rd->skb->data + 6, dev->dev_addr, ETH_ALEN)) { + if (len > rx_copybreak) { + skb = rd->skb; + newskb = netdev_alloc_skb(dev, PKT_BUF_SZ); + if (!newskb) { + newskb = skb; + skb = NULL; + goto memory_squeeze; + } + skb_reserve(newskb, 2); + } else { + skb = netdev_alloc_skb(dev, len + 2); + if (skb) { + skb_reserve(skb, 2); + skb_copy_to_linear_data(skb, rd->skb->data, len); + } + newskb = rd->skb; + } +memory_squeeze: + if (skb) { + skb_put(skb, len); + skb->protocol = eth_type_trans(skb, dev); netif_rx(skb); dev->last_rx = jiffies; dev->stats.rx_packets++; dev->stats.rx_bytes += len; } else { - /* Silently drop my own packets */ - dev_kfree_skb_irq(skb); + printk(KERN_NOTICE "%s: Memory squeeze, deferring packet.\n", + dev->name); + dev->stats.rx_dropped++; } } else { - printk (KERN_NOTICE "%s: Memory squeeze, deferring packet.\n", - dev->name); - dev->stats.rx_dropped++; + /* Silently drop my own packets */ + newskb = rd->skb; } } else { record_rx_errors(dev, pkt_status); + newskb = rd->skb; } + rd->skb = newskb; + rd->rdma.pbuf = dma_map_single(dev->dev.parent, + newskb->data - 2, + PKT_BUF_SZ, DMA_FROM_DEVICE); /* Return the entry to the ring pool. */ rd->rdma.cntinfo = RCNTINFO_INIT; sp->rx_new = NEXT_RX(sp->rx_new); + dma_sync_desc_dev(dev, rd); + rd = &sp->rx_desc[sp->rx_new]; + dma_sync_desc_cpu(dev, rd); } + dma_sync_desc_cpu(dev, &sp->rx_desc[orig_end]); sp->rx_desc[orig_end].rdma.cntinfo &= ~(HPCDMA_EOR); + dma_sync_desc_dev(dev, &sp->rx_desc[orig_end]); + dma_sync_desc_cpu(dev, &sp->rx_desc[PREV_RX(sp->rx_new)]); sp->rx_desc[PREV_RX(sp->rx_new)].rdma.cntinfo |= HPCDMA_EOR; + dma_sync_desc_dev(dev, &sp->rx_desc[PREV_RX(sp->rx_new)]); rx_maybe_restart(sp, hregs, sregs); } @@ -358,20 +423,29 @@ static inline void tx_maybe_reset_collisions(struct sgiseeq_private *sp, } } -static inline void kick_tx(struct sgiseeq_tx_desc *td, +static inline void kick_tx(struct net_device *dev, + struct sgiseeq_private *sp, struct hpc3_ethregs *hregs) { + struct sgiseeq_tx_desc *td; + int i = sp->tx_old; + /* If the HPC aint doin nothin, and there are more packets * with ETXD cleared and XIU set we must make very certain * that we restart the HPC else we risk locking up the * adapter. The following code is only safe iff the HPCDMA * is not active! */ + td = &sp->tx_desc[i]; + dma_sync_desc_cpu(dev, td); while ((td->tdma.cntinfo & (HPCDMA_XIU | HPCDMA_ETXD)) == - (HPCDMA_XIU | HPCDMA_ETXD)) - td = (struct sgiseeq_tx_desc *)(long) CKSEG1ADDR(td->tdma.pnext); + (HPCDMA_XIU | HPCDMA_ETXD)) { + i = NEXT_TX(i); + td = &sp->tx_desc[i]; + dma_sync_desc_cpu(dev, td); + } if (td->tdma.cntinfo & HPCDMA_XIU) { - hregs->tx_ndptr = CPHYSADDR(td); + hregs->tx_ndptr = VIRT_TO_DMA(sp, td); hregs->tx_ctrl = HPC3_ETXCTRL_ACTIVE; } } @@ -400,11 +474,12 @@ static inline void sgiseeq_tx(struct net_device *dev, struct sgiseeq_private *sp for (j = sp->tx_old; j != sp->tx_new; j = NEXT_TX(j)) { td = &sp->tx_desc[j]; + dma_sync_desc_cpu(dev, td); if (!(td->tdma.cntinfo & (HPCDMA_XIU))) break; if (!(td->tdma.cntinfo & (HPCDMA_ETXD))) { if (!(status & HPC3_ETXCTRL_ACTIVE)) { - hregs->tx_ndptr = CPHYSADDR(td); + hregs->tx_ndptr = VIRT_TO_DMA(sp, td); hregs->tx_ctrl = HPC3_ETXCTRL_ACTIVE; } break; @@ -413,6 +488,11 @@ static inline void sgiseeq_tx(struct net_device *dev, struct sgiseeq_private *sp sp->tx_old = NEXT_TX(sp->tx_old); td->tdma.cntinfo &= ~(HPCDMA_XIU | HPCDMA_XIE); td->tdma.cntinfo |= HPCDMA_EOX; + if (td->skb) { + dev_kfree_skb_any(td->skb); + td->skb = NULL; + } + dma_sync_desc_dev(dev, td); } } @@ -480,6 +560,7 @@ static int sgiseeq_close(struct net_device *dev) /* Shutdown the Seeq. */ reset_hpc3_and_seeq(sp->hregs, sregs); free_irq(irq, dev); + seeq_purge_ring(dev); return 0; } @@ -506,16 +587,22 @@ static int sgiseeq_start_xmit(struct sk_buff *skb, struct net_device *dev) struct hpc3_ethregs *hregs = sp->hregs; unsigned long flags; struct sgiseeq_tx_desc *td; - int skblen, len, entry; + int len, entry; spin_lock_irqsave(&sp->tx_lock, flags); /* Setup... */ - skblen = skb->len; - len = (skblen <= ETH_ZLEN) ? ETH_ZLEN : skblen; + len = skb->len; + if (len < ETH_ZLEN) { + if (skb_padto(skb, ETH_ZLEN)) + return 0; + len = ETH_ZLEN; + } + dev->stats.tx_bytes += len; entry = sp->tx_new; td = &sp->tx_desc[entry]; + dma_sync_desc_cpu(dev, td); /* Create entry. There are so many races with adding a new * descriptor to the chain: @@ -530,25 +617,27 @@ static int sgiseeq_start_xmit(struct sk_buff *skb, struct net_device *dev) * entry and the HPC got to the end of the chain before we * added this new entry and restarted it. */ - skb_copy_from_linear_data(skb, (char *)(long)td->buf_vaddr, skblen); - if (len != skblen) - memset((char *)(long)td->buf_vaddr + skb->len, 0, len-skblen); + td->skb = skb; + td->tdma.pbuf = dma_map_single(dev->dev.parent, skb->data, + len, DMA_TO_DEVICE); td->tdma.cntinfo = (len & HPCDMA_BCNT) | HPCDMA_XIU | HPCDMA_EOXP | HPCDMA_XIE | HPCDMA_EOX; + dma_sync_desc_dev(dev, td); if (sp->tx_old != sp->tx_new) { struct sgiseeq_tx_desc *backend; backend = &sp->tx_desc[PREV_TX(sp->tx_new)]; + dma_sync_desc_cpu(dev, backend); backend->tdma.cntinfo &= ~HPCDMA_EOX; + dma_sync_desc_dev(dev, backend); } sp->tx_new = NEXT_TX(sp->tx_new); /* Advance. */ /* Maybe kick the HPC back into motion. */ if (!(hregs->tx_ctrl & HPC3_ETXCTRL_ACTIVE)) - kick_tx(&sp->tx_desc[sp->tx_old], hregs); + kick_tx(dev, sp, hregs); dev->trans_start = jiffies; - dev_kfree_skb(skb); if (!TX_BUFFS_AVAIL(sp)) netif_stop_queue(dev); @@ -586,33 +675,41 @@ static void sgiseeq_set_multicast(struct net_device *dev) sgiseeq_reset(dev); } -static inline void setup_tx_ring(struct sgiseeq_tx_desc *buf, int nbufs) +static inline void setup_tx_ring(struct net_device *dev, + struct sgiseeq_tx_desc *buf, + int nbufs) { + struct sgiseeq_private *sp = netdev_priv(dev); int i = 0; while (i < (nbufs - 1)) { - buf[i].tdma.pnext = CPHYSADDR(buf + i + 1); + buf[i].tdma.pnext = VIRT_TO_DMA(sp, buf + i + 1); buf[i].tdma.pbuf = 0; + dma_sync_desc_dev(dev, &buf[i]); i++; } - buf[i].tdma.pnext = CPHYSADDR(buf); + buf[i].tdma.pnext = VIRT_TO_DMA(sp, buf); + dma_sync_desc_dev(dev, &buf[i]); } -static inline void setup_rx_ring(struct sgiseeq_rx_desc *buf, int nbufs) +static inline void setup_rx_ring(struct net_device *dev, + struct sgiseeq_rx_desc *buf, + int nbufs) { + struct sgiseeq_private *sp = netdev_priv(dev); int i = 0; while (i < (nbufs - 1)) { - buf[i].rdma.pnext = CPHYSADDR(buf + i + 1); + buf[i].rdma.pnext = VIRT_TO_DMA(sp, buf + i + 1); buf[i].rdma.pbuf = 0; + dma_sync_desc_dev(dev, &buf[i]); i++; } buf[i].rdma.pbuf = 0; - buf[i].rdma.pnext = CPHYSADDR(buf); + buf[i].rdma.pnext = VIRT_TO_DMA(sp, buf); + dma_sync_desc_dev(dev, &buf[i]); } -#define ALIGNED(x) ((((unsigned long)(x)) + 0xf) & ~(0xf)) - static int __init sgiseeq_probe(struct platform_device *pdev) { struct sgiseeq_platform_data *pd = pdev->dev.platform_data; @@ -621,7 +718,7 @@ static int __init sgiseeq_probe(struct platform_device *pdev) unsigned int irq = pd->irq; struct sgiseeq_private *sp; struct net_device *dev; - int err, i; + int err; DECLARE_MAC_BUF(mac); dev = alloc_etherdev(sizeof (struct sgiseeq_private)); @@ -635,7 +732,7 @@ static int __init sgiseeq_probe(struct platform_device *pdev) sp = netdev_priv(dev); /* Make private data page aligned */ - sr = dma_alloc_coherent(&pdev->dev, sizeof(*sp->srings), + sr = dma_alloc_noncoherent(&pdev->dev, sizeof(*sp->srings), &sp->srings_dma, GFP_KERNEL); if (!sr) { printk(KERN_ERR "Sgiseeq: Page alloc failed, aborting.\n"); @@ -647,8 +744,8 @@ static int __init sgiseeq_probe(struct platform_device *pdev) sp->tx_desc = sp->srings->txvector; /* A couple calculations now, saves many cycles later. */ - setup_rx_ring(sp->rx_desc, SEEQ_RX_BUFFERS); - setup_tx_ring(sp->tx_desc, SEEQ_TX_BUFFERS); + setup_rx_ring(dev, sp->rx_desc, SEEQ_RX_BUFFERS); + setup_tx_ring(dev, sp->tx_desc, SEEQ_TX_BUFFERS); memcpy(dev->dev_addr, pd->mac, ETH_ALEN); @@ -716,8 +813,8 @@ static int __exit sgiseeq_remove(struct platform_device *pdev) struct sgiseeq_private *sp = netdev_priv(dev); unregister_netdev(dev); - dma_free_coherent(&pdev->dev, sizeof(*sp->srings), sp->srings, - sp->srings_dma); + dma_free_noncoherent(&pdev->dev, sizeof(*sp->srings), sp->srings, + sp->srings_dma); free_netdev(dev); platform_set_drvdata(pdev, NULL); From tsbogend@alpha.franken.de Sun Dec 2 12:00:59 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Sun, 02 Dec 2007 12:01:07 +0000 (GMT) Received: from elvis.franken.de ([193.175.24.41]:18661 "EHLO elvis.franken.de") by ftp.linux-mips.org with ESMTP id S20023160AbXLBMA7 (ORCPT ); Sun, 2 Dec 2007 12:00:59 +0000 Received: from uucp (helo=solo.franken.de) by elvis.franken.de with local-bsmtp (Exim 3.36 #1) id 1IynVI-0001dY-00; Sun, 02 Dec 2007 13:00:56 +0100 Received: by solo.franken.de (Postfix, from userid 1000) id E7844C2EB5; Sun, 2 Dec 2007 12:54:42 +0100 (CET) From: Thomas Bogendoerfer To: linux-kernel@vger.kernel.org, linux-mips@linux-mips.org cc: wim@iguana.be Subject: [PATCH] WATCHDOG: Use SGI_HAS_INDYDOG for INDYDOG depends Message-Id: <20071202115442.E7844C2EB5@solo.franken.de> Date: Sun, 2 Dec 2007 12:54:42 +0100 (CET) Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 17659 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: tsbogend@alpha.franken.de Precedence: bulk X-list: linux-mips Use SGI_HAS_INDYDOG for INDYDOG depends. Signed-off-by: Thomas Bogendoerfer --- Please apply for 2.6.25. drivers/watchdog/Kconfig | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/drivers/watchdog/Kconfig b/drivers/watchdog/Kconfig index 2792bc1..1ba30cb 100644 --- a/drivers/watchdog/Kconfig +++ b/drivers/watchdog/Kconfig @@ -586,7 +586,7 @@ config SBC_EPX_C3_WATCHDOG config INDYDOG tristate "Indy/I2 Hardware Watchdog" - depends on SGI_IP22 + depends on SGI_HAS_INDYDOG help Hardware driver for the Indy's/I2's watchdog. This is a watchdog timer that will reboot the machine after a 60 second From tsbogend@alpha.franken.de Sun Dec 2 12:01:27 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Sun, 02 Dec 2007 12:01:31 +0000 (GMT) Received: from elvis.franken.de ([193.175.24.41]:18917 "EHLO elvis.franken.de") by ftp.linux-mips.org with ESMTP id S20023297AbXLBMA7 (ORCPT ); Sun, 2 Dec 2007 12:00:59 +0000 Received: from uucp (helo=solo.franken.de) by elvis.franken.de with local-bsmtp (Exim 3.36 #1) id 1IynVI-0001dY-01; Sun, 02 Dec 2007 13:00:56 +0100 Received: by solo.franken.de (Postfix, from userid 1000) id BDBEFC2EB6; Sun, 2 Dec 2007 12:54:56 +0100 (CET) From: Thomas Bogendoerfer To: linux-kernel@vger.kernel.org, linux-mips@linux-mips.org cc: wim@iguana.be Subject: [PATCH] PARTITION: Use DEFAULT_SGI_PARTITION for SGI_PARTION default Message-Id: <20071202115456.BDBEFC2EB6@solo.franken.de> Date: Sun, 2 Dec 2007 12:54:56 +0100 (CET) Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 17660 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: tsbogend@alpha.franken.de Precedence: bulk X-list: linux-mips Use DEFAULT_SGI_PARTITION for SGI_PARTION default Signed-off-by: Thomas Bogendoerfer --- Please apply for 2.6.25. fs/partitions/Kconfig | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/fs/partitions/Kconfig b/fs/partitions/Kconfig index a99acd8..cb5f0a3 100644 --- a/fs/partitions/Kconfig +++ b/fs/partitions/Kconfig @@ -198,7 +198,7 @@ config LDM_DEBUG config SGI_PARTITION bool "SGI partition support" if PARTITION_ADVANCED - default y if (SGI_IP22 || SGI_IP27 || ((MACH_JAZZ || SNI_RM) && !CPU_LITTLE_ENDIAN)) + default y if DEFAULT_SGI_PARTITION help Say Y here if you would like to be able to read the hard disk partition table format used by SGI machines. From tsbogend@alpha.franken.de Sun Dec 2 12:01:52 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Sun, 02 Dec 2007 12:02:01 +0000 (GMT) Received: from elvis.franken.de ([193.175.24.41]:19941 "EHLO elvis.franken.de") by ftp.linux-mips.org with ESMTP id S20023370AbXLBMBB (ORCPT ); Sun, 2 Dec 2007 12:01:01 +0000 Received: from uucp (helo=solo.franken.de) by elvis.franken.de with local-bsmtp (Exim 3.36 #1) id 1IynVI-0001dY-02; Sun, 02 Dec 2007 13:00:56 +0100 Received: by solo.franken.de (Postfix, from userid 1000) id 85F91C2EB6; Sun, 2 Dec 2007 12:55:19 +0100 (CET) From: Thomas Bogendoerfer To: linux-input@vger.kernel.org, linux-mips@linux-mips.org cc: dmitry.torokhov@gmail.com Subject: [PATCH] I8042: Use SGI_HAS_I8042 to select SGI i8042 handlinig Message-Id: <20071202115519.85F91C2EB6@solo.franken.de> Date: Sun, 2 Dec 2007 12:55:19 +0100 (CET) Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 17661 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: tsbogend@alpha.franken.de Precedence: bulk X-list: linux-mips Use SGI_HAS_I8042 to select SGI i8042 handling Signed-off-by: Thomas Bogendoerfer --- Please apply for 2.6.25. drivers/input/serio/i8042.h | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/drivers/input/serio/i8042.h b/drivers/input/serio/i8042.h index dd22d91..c972e5d 100644 --- a/drivers/input/serio/i8042.h +++ b/drivers/input/serio/i8042.h @@ -16,7 +16,7 @@ #if defined(CONFIG_MACH_JAZZ) #include "i8042-jazzio.h" -#elif defined(CONFIG_SGI_IP22) +#elif defined(CONFIG_SGI_HAS_I8042) #include "i8042-ip22io.h" #elif defined(CONFIG_PPC) #include "i8042-ppcio.h" From tsbogend@alpha.franken.de Sun Dec 2 12:02:21 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Sun, 02 Dec 2007 12:02:31 +0000 (GMT) Received: from elvis.franken.de ([193.175.24.41]:20453 "EHLO elvis.franken.de") by ftp.linux-mips.org with ESMTP id S20023380AbXLBMBB (ORCPT ); Sun, 2 Dec 2007 12:01:01 +0000 Received: from uucp (helo=solo.franken.de) by elvis.franken.de with local-bsmtp (Exim 3.36 #1) id 1IynVJ-0001dY-01; Sun, 02 Dec 2007 13:00:57 +0100 Received: by solo.franken.de (Postfix, from userid 1000) id 2A477C2EB6; Sun, 2 Dec 2007 13:00:32 +0100 (CET) From: Thomas Bogendoerfer Subject: [UPDATED PATCH] IP28 support To: linux-mips@linux-mips.org cc: ralf@linux-mips.org Message-Id: <20071202120032.2A477C2EB6@solo.franken.de> Date: Sun, 2 Dec 2007 13:00:32 +0100 (CET) Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 17662 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: tsbogend@alpha.franken.de Precedence: bulk X-list: linux-mips Add support for SGI IP28 machines (Indigo 2 with R10k CPUs) This work is mainly based on Peter Fuersts work. Signed-off-by: Thomas Bogendoerfer --- Changes to last version: - restructered Kconfig to make device/feature selection easier arch/mips/Kconfig | 66 ++- arch/mips/Makefile | 14 + arch/mips/sgi-ip22/Makefile | 8 +- arch/mips/sgi-ip22/ip22-mc.c | 4 + arch/mips/sgi-ip22/ip28-berr.c | 700 ++++++++++++++++++++ include/asm-mips/dma.h | 7 +- include/asm-mips/mach-ip28/cpu-feature-overrides.h | 50 ++ include/asm-mips/mach-ip28/ds1286.h | 4 + include/asm-mips/mach-ip28/spaces.h | 22 + include/asm-mips/mach-ip28/war.h | 25 + 10 files changed, 890 insertions(+), 10 deletions(-) diff --git a/arch/mips/Kconfig b/arch/mips/Kconfig index 455bd1f..aae317d 100644 --- a/arch/mips/Kconfig +++ b/arch/mips/Kconfig @@ -122,6 +122,7 @@ config MACH_JAZZ select ARCH_MAY_HAVE_PC_FDC select CEVT_R4K select CSRC_R4K + select DEFAULT_SGI_PARTITION if CPU_BIG_ENDIAN select GENERIC_ISA_DMA select IRQ_CPU select I8253 @@ -398,6 +399,7 @@ config SGI_IP22 select BOOT_ELF32 select CEVT_R4K select CSRC_R4K + select DEFAULT_SGI_PARTITION select DMA_NONCOHERENT select HW_HAS_EISA select I8253 @@ -405,6 +407,12 @@ config SGI_IP22 select IP22_CPU_SCACHE select IRQ_CPU select GENERIC_ISA_DMA_SUPPORT_BROKEN + select SGI_HAS_DS1286 + select SGI_HAS_I8042 + select SGI_HAS_INDYDOG + select SGI_HAS_SEEQ + select SGI_HAS_WD93 + select SGI_HAS_ZILOG select SWAP_IO_SPACE select SYS_HAS_CPU_R4X00 select SYS_HAS_CPU_R5000 @@ -422,6 +430,7 @@ config SGI_IP27 select ARC select ARC64 select BOOT_ELF64 + select DEFAULT_SGI_PARTITION select DMA_IP27 select SYS_HAS_EARLY_PRINTK select HW_HAS_PCI @@ -438,6 +447,35 @@ config SGI_IP27 workstations. To compile a Linux kernel that runs on these, say Y here. +config SGI_IP28 + bool "SGI IP28 (Indigo2 R10k) (EXPERIMENTAL)" + depends on EXPERIMENTAL + select ARC + select ARC64 + select BOOT_ELF64 + select CEVT_R4K + select CSRC_R4K + select DEFAULT_SGI_PARTITION + select DMA_NONCOHERENT + select IRQ_CPU + select HW_HAS_EISA + select I8253 + select I8259 + select SGI_HAS_DS1286 + select SGI_HAS_I8042 + select SGI_HAS_INDYDOG + select SGI_HAS_SEEQ + select SGI_HAS_WD93 + select SGI_HAS_ZILOG + select SWAP_IO_SPACE + select SYS_HAS_CPU_R10000 + select SYS_HAS_EARLY_PRINTK + select SYS_SUPPORTS_64BIT_KERNEL + select SYS_SUPPORTS_BIG_ENDIAN + help + This is the SGI Indigo2 with R10000 processor. To compile a Linux + kernel that runs on these, say Y here. + config SGI_IP32 bool "SGI IP32 (O2)" select ARC @@ -577,6 +615,7 @@ config SNI_RM select BOOT_ELF32 select CEVT_R4K select CSRC_R4K + select DEFAULT_SGI_PARTITION if CPU_BIG_ENDIAN select DMA_NONCOHERENT select GENERIC_ISA_DMA select HW_HAS_EISA @@ -950,6 +989,27 @@ config EMMA2RH config SERIAL_RM9000 bool +config SGI_HAS_DS1286 + bool + +config SGI_HAS_INDYDOG + bool + +config SGI_HAS_SEEQ + bool + +config SGI_HAS_WD93 + bool + +config SGI_HAS_ZILOG + bool + +config SGI_HAS_I8042 + bool + +config DEFAULT_SGI_PARTITION + bool + config ARC32 bool @@ -959,7 +1019,7 @@ config BOOT_ELF32 config MIPS_L1_CACHE_SHIFT int default "4" if MACH_DECSTATION - default "7" if SGI_IP27 || SNI_RM + default "7" if SGI_IP27 || SGI_IP28 || SNI_RM default "4" if PMC_MSP4200_EVAL default "5" @@ -968,7 +1028,7 @@ config HAVE_STD_PC_SERIAL_PORT config ARC_CONSOLE bool "ARC console support" - depends on SGI_IP22 || (SNI_RM && CPU_LITTLE_ENDIAN) + depends on SGI_IP22 || SGI_IP28 || (SNI_RM && CPU_LITTLE_ENDIAN) config ARC_MEMORY bool @@ -977,7 +1037,7 @@ config ARC_MEMORY config ARC_PROMLIB bool - depends on MACH_JAZZ || SNI_RM || SGI_IP22 || SGI_IP32 + depends on MACH_JAZZ || SNI_RM || SGI_IP22 || SGI_IP28 || SGI_IP32 default y config ARC64 diff --git a/arch/mips/Makefile b/arch/mips/Makefile index a1f8d8b..d91fbca 100644 --- a/arch/mips/Makefile +++ b/arch/mips/Makefile @@ -475,6 +475,20 @@ endif endif # +# SGI IP28 (Indigo2 R10k) +# +# Set the load address to >= 0xa800000020080000 if you want to leave space for +# symmon, 0xa800000020004000 for production kernels ? Note that the value must +# be 16kb aligned or the handling of the current variable will break. +# Simplified: what IP22 does at 128MB+ in ksegN, IP28 does at 512MB+ in xkphys +# +#core-$(CONFIG_SGI_IP28) += arch/mips/sgi-ip22/ arch/mips/arc/arc_con.o +core-$(CONFIG_SGI_IP28) += arch/mips/sgi-ip22/ +cflags-$(CONFIG_SGI_IP28) += -mr10k-cache-barrier=1 -Iinclude/asm-mips/mach-ip28 +#cflags-$(CONFIG_SGI_IP28) += -Iinclude/asm-mips/mach-ip28 +load-$(CONFIG_SGI_IP28) += 0xa800000020004000 + +# # SGI-IP32 (O2) # # Set the load address to >= 80069000 if you want to leave space for symmon, diff --git a/arch/mips/sgi-ip22/Makefile b/arch/mips/sgi-ip22/Makefile index e3acb51..ef1564e 100644 --- a/arch/mips/sgi-ip22/Makefile +++ b/arch/mips/sgi-ip22/Makefile @@ -3,9 +3,11 @@ # under Linux. # -obj-y += ip22-mc.o ip22-hpc.o ip22-int.o ip22-berr.o \ - ip22-time.o ip22-nvram.o ip22-platform.o ip22-reset.o ip22-setup.o +obj-y += ip22-mc.o ip22-hpc.o ip22-int.o ip22-time.o ip22-nvram.o \ + ip22-platform.o ip22-reset.o ip22-setup.o +obj-$(CONFIG_SGI_IP22) += ip22-berr.o +obj-$(CONFIG_SGI_IP28) += ip28-berr.o obj-$(CONFIG_EISA) += ip22-eisa.o -EXTRA_CFLAGS += -Werror +# EXTRA_CFLAGS += -Werror diff --git a/arch/mips/sgi-ip22/ip22-mc.c b/arch/mips/sgi-ip22/ip22-mc.c index 01a805d..3f35d63 100644 --- a/arch/mips/sgi-ip22/ip22-mc.c +++ b/arch/mips/sgi-ip22/ip22-mc.c @@ -4,6 +4,7 @@ * Copyright (C) 1996 David S. Miller (dm@engr.sgi.com) * Copyright (C) 1999 Andrew R. Baker (andrewb@uab.edu) - Indigo2 changes * Copyright (C) 2003 Ladislav Michl (ladis@linux-mips.org) + * Copyright (C) 2004 Peter Fuerst (pf@net.alphadv.de) - IP28 */ #include @@ -137,9 +138,12 @@ void __init sgimc_init(void) /* Step 2: Enable all parity checking in cpu control register * zero. */ + /* don't touch parity settings for IP28 */ +#ifndef CONFIG_SGI_IP28 tmp = sgimc->cpuctrl0; tmp |= (SGIMC_CCTRL0_EPERRGIO | SGIMC_CCTRL0_EPERRMEM | SGIMC_CCTRL0_R4KNOCHKPARR); +#endif sgimc->cpuctrl0 = tmp; /* Step 3: Setup the MC write buffer depth, this is controlled diff --git a/arch/mips/sgi-ip22/ip28-berr.c b/arch/mips/sgi-ip22/ip28-berr.c new file mode 100644 index 0000000..0ee5be8 --- /dev/null +++ b/arch/mips/sgi-ip22/ip28-berr.c @@ -0,0 +1,700 @@ +/* + * ip28-berr.c: Bus error handling. + * + * Copyright (C) 2002, 2003 Ladislav Michl (ladis@linux-mips.org) + * Copyright (C) 2005 Peter Fuerst (pf@net.alphadv.de) - IP28 + */ + +#include +#include +#include +#include + +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include + +static unsigned int count_be_is_fixup; +static unsigned int count_be_handler; +static unsigned int count_be_interrupt; +static int debug_be_interrupt; + +static unsigned int cpu_err_stat; /* Status reg for CPU */ +static unsigned int gio_err_stat; /* Status reg for GIO */ +static unsigned int cpu_err_addr; /* Error address reg for CPU */ +static unsigned int gio_err_addr; /* Error address reg for GIO */ +static unsigned int extio_stat; +static unsigned int hpc3_berr_stat; /* Bus error interrupt status */ + +struct hpc3_stat { + unsigned long addr; + unsigned int ctrl; + unsigned int cbp; + unsigned int ndptr; +}; + +static struct { + struct hpc3_stat pbdma[8]; + struct hpc3_stat scsi[2]; + struct hpc3_stat ethrx, ethtx; +} hpc3; + +static struct { + unsigned long err_addr; + struct { + u32 lo; + u32 hi; + } tags[1][2], tagd[4][2], tagi[4][2]; /* Way 0/1 */ +} cache_tags; + +static inline void save_cache_tags(unsigned busaddr) +{ + unsigned long addr = CAC_BASE | busaddr; + int i; + cache_tags.err_addr = addr; + + /* + * Starting with a bus-address, save secondary cache (indexed by + * PA[23..18:7..6]) tags first. + */ + addr &= ~1L; +#define tag cache_tags.tags[0] + cache_op(Index_Load_Tag_S, addr); + tag[0].lo = read_c0_taglo(); /* PA[35:18], VA[13:12] */ + tag[0].hi = read_c0_taghi(); /* PA[39:36] */ + cache_op(Index_Load_Tag_S, addr | 1L); + tag[1].lo = read_c0_taglo(); /* PA[35:18], VA[13:12] */ + tag[1].hi = read_c0_taghi(); /* PA[39:36] */ +#undef tag + + /* + * Save all primary data cache (indexed by VA[13:5]) tags which + * might fit to this bus-address, knowing that VA[11:0] == PA[11:0]. + * Saving all tags and evaluating them later is easier and safer + * than relying on VA[13:12] from the secondary cache tags to pick + * matching primary tags here already. + */ + addr &= (0xffL << 56) | ((1 << 12) - 1); +#define tag cache_tags.tagd[i] + for (i = 0; i < 4; ++i, addr += (1 << 12)) { + cache_op(Index_Load_Tag_D, addr); + tag[0].lo = read_c0_taglo(); /* PA[35:12] */ + tag[0].hi = read_c0_taghi(); /* PA[39:36] */ + cache_op(Index_Load_Tag_D, addr | 1L); + tag[1].lo = read_c0_taglo(); /* PA[35:12] */ + tag[1].hi = read_c0_taghi(); /* PA[39:36] */ + } +#undef tag + + /* + * Save primary instruction cache (indexed by VA[13:6]) tags + * the same way. + */ + addr &= (0xffL << 56) | ((1 << 12) - 1); +#define tag cache_tags.tagi[i] + for (i = 0; i < 4; ++i, addr += (1 << 12)) { + cache_op(Index_Load_Tag_I, addr); + tag[0].lo = read_c0_taglo(); /* PA[35:12] */ + tag[0].hi = read_c0_taghi(); /* PA[39:36] */ + cache_op(Index_Load_Tag_I, addr | 1L); + tag[1].lo = read_c0_taglo(); /* PA[35:12] */ + tag[1].hi = read_c0_taghi(); /* PA[39:36] */ + } +#undef tag +} + +#define GIO_ERRMASK 0xff00 +#define CPU_ERRMASK 0x3f00 + +static void save_and_clear_buserr(void) +{ + int i; + + /* save status registers */ + cpu_err_addr = sgimc->cerr; + cpu_err_stat = sgimc->cstat; + gio_err_addr = sgimc->gerr; + gio_err_stat = sgimc->gstat; + extio_stat = sgioc->extio; + hpc3_berr_stat = hpc3c0->bestat; + + hpc3.scsi[0].addr = (unsigned long)&hpc3c0->scsi_chan0; + hpc3.scsi[0].ctrl = hpc3c0->scsi_chan0.ctrl; /* HPC3_SCTRL_ACTIVE ? */ + hpc3.scsi[0].cbp = hpc3c0->scsi_chan0.cbptr; + hpc3.scsi[0].ndptr = hpc3c0->scsi_chan0.ndptr; + + hpc3.scsi[1].addr = (unsigned long)&hpc3c0->scsi_chan1; + hpc3.scsi[1].ctrl = hpc3c0->scsi_chan1.ctrl; /* HPC3_SCTRL_ACTIVE ? */ + hpc3.scsi[1].cbp = hpc3c0->scsi_chan1.cbptr; + hpc3.scsi[1].ndptr = hpc3c0->scsi_chan1.ndptr; + + hpc3.ethrx.addr = (unsigned long)&hpc3c0->ethregs.rx_cbptr; + hpc3.ethrx.ctrl = hpc3c0->ethregs.rx_ctrl; /* HPC3_ERXCTRL_ACTIVE ? */ + hpc3.ethrx.cbp = hpc3c0->ethregs.rx_cbptr; + hpc3.ethrx.ndptr = hpc3c0->ethregs.rx_ndptr; + + hpc3.ethtx.addr = (unsigned long)&hpc3c0->ethregs.tx_cbptr; + hpc3.ethtx.ctrl = hpc3c0->ethregs.tx_ctrl; /* HPC3_ETXCTRL_ACTIVE ? */ + hpc3.ethtx.cbp = hpc3c0->ethregs.tx_cbptr; + hpc3.ethtx.ndptr = hpc3c0->ethregs.tx_ndptr; + + for (i = 0; i < 8; ++i) { + /* HPC3_PDMACTRL_ISACT ? */ + hpc3.pbdma[i].addr = (unsigned long)&hpc3c0->pbdma[i]; + hpc3.pbdma[i].ctrl = hpc3c0->pbdma[i].pbdma_ctrl; + hpc3.pbdma[i].cbp = hpc3c0->pbdma[i].pbdma_bptr; + hpc3.pbdma[i].ndptr = hpc3c0->pbdma[i].pbdma_dptr; + } + i = 0; + if (gio_err_stat & CPU_ERRMASK) + i = gio_err_addr; + if (cpu_err_stat & CPU_ERRMASK) + i = cpu_err_addr; + save_cache_tags(i); + + sgimc->cstat = sgimc->gstat = 0; +} + +static void print_cache_tags(void) +{ + u32 scb, scw; + int i; + + printk(KERN_ERR "Cache tags @ %08x:\n", (unsigned)cache_tags.err_addr); + + /* PA[31:12] shifted to PTag0 (PA[35:12]) format */ + scw = (cache_tags.err_addr >> 4) & 0x0fffff00; + + scb = cache_tags.err_addr & ((1 << 12) - 1) & ~((1 << 5) - 1); + for (i = 0; i < 4; ++i) { /* for each possible VA[13:12] value */ + if ((cache_tags.tagd[i][0].lo & 0x0fffff00) != scw && + (cache_tags.tagd[i][1].lo & 0x0fffff00) != scw) + continue; + printk(KERN_ERR + "D: 0: %08x %08x, 1: %08x %08x (VA[13:5] %04x)\n", + cache_tags.tagd[i][0].hi, cache_tags.tagd[i][0].lo, + cache_tags.tagd[i][1].hi, cache_tags.tagd[i][1].lo, + scb | (1 << 12)*i); + } + scb = cache_tags.err_addr & ((1 << 12) - 1) & ~((1 << 6) - 1); + for (i = 0; i < 4; ++i) { /* for each possible VA[13:12] value */ + if ((cache_tags.tagi[i][0].lo & 0x0fffff00) != scw && + (cache_tags.tagi[i][1].lo & 0x0fffff00) != scw) + continue; + printk(KERN_ERR + "I: 0: %08x %08x, 1: %08x %08x (VA[13:6] %04x)\n", + cache_tags.tagi[i][0].hi, cache_tags.tagi[i][0].lo, + cache_tags.tagi[i][1].hi, cache_tags.tagi[i][1].lo, + scb | (1 << 12)*i); + } + i = read_c0_config(); + scb = i & (1 << 13) ? 7:6; /* scblksize = 2^[7..6] */ + scw = ((i >> 16) & 7) + 19 - 1; /* scwaysize = 2^[24..19] / 2 */ + + i = ((1 << scw) - 1) & ~((1 << scb) - 1); + printk(KERN_ERR "S: 0: %08x %08x, 1: %08x %08x (PA[%u:%u] %05x)\n", + cache_tags.tags[0][0].hi, cache_tags.tags[0][0].lo, + cache_tags.tags[0][1].hi, cache_tags.tags[0][1].lo, + scw-1, scb, i & (unsigned)cache_tags.err_addr); +} + +static inline const char *cause_excode_text(int cause) +{ + static const char *txt[32] = + { "Interrupt", + "TLB modification", + "TLB (load or instruction fetch)", + "TLB (store)", + "Address error (load or instruction fetch)", + "Address error (store)", + "Bus error (instruction fetch)", + "Bus error (data: load or store)", + "Syscall", + "Breakpoint", + "Reserved instruction", + "Coprocessor unusable", + "Arithmetic Overflow", + "Trap", + "14", + "Floating-Point", + "16", "17", "18", "19", "20", "21", "22", + "Watch Hi/Lo", + "24", "25", "26", "27", "28", "29", "30", "31", + }; + return txt[(cause & 0x7c) >> 2]; +} + +static void print_buserr(const struct pt_regs *regs) +{ + const int field = 2 * sizeof(unsigned long); + int error = 0; + + if (extio_stat & EXTIO_MC_BUSERR) { + printk(KERN_ERR "MC Bus Error\n"); + error |= 1; + } + if (extio_stat & EXTIO_HPC3_BUSERR) { + printk(KERN_ERR "HPC3 Bus Error 0x%x:\n", + hpc3_berr_stat, + (hpc3_berr_stat & HPC3_BESTAT_PIDMASK) >> + HPC3_BESTAT_PIDSHIFT, + (hpc3_berr_stat & HPC3_BESTAT_CTYPE) ? "PIO" : "DMA", + hpc3_berr_stat & HPC3_BESTAT_BLMASK); + error |= 2; + } + if (extio_stat & EXTIO_EISA_BUSERR) { + printk(KERN_ERR "EISA Bus Error\n"); + error |= 4; + } + if (cpu_err_stat & CPU_ERRMASK) { + printk(KERN_ERR "CPU error 0x%x<%s%s%s%s%s%s> @ 0x%08x\n", + cpu_err_stat, + cpu_err_stat & SGIMC_CSTAT_RD ? "RD " : "", + cpu_err_stat & SGIMC_CSTAT_PAR ? "PAR " : "", + cpu_err_stat & SGIMC_CSTAT_ADDR ? "ADDR " : "", + cpu_err_stat & SGIMC_CSTAT_SYSAD_PAR ? "SYSAD " : "", + cpu_err_stat & SGIMC_CSTAT_SYSCMD_PAR ? "SYSCMD " : "", + cpu_err_stat & SGIMC_CSTAT_BAD_DATA ? "BAD_DATA " : "", + cpu_err_addr); + error |= 8; + } + if (gio_err_stat & GIO_ERRMASK) { + printk(KERN_ERR "GIO error 0x%x:<%s%s%s%s%s%s%s%s> @ 0x%08x\n", + gio_err_stat, + gio_err_stat & SGIMC_GSTAT_RD ? "RD " : "", + gio_err_stat & SGIMC_GSTAT_WR ? "WR " : "", + gio_err_stat & SGIMC_GSTAT_TIME ? "TIME " : "", + gio_err_stat & SGIMC_GSTAT_PROM ? "PROM " : "", + gio_err_stat & SGIMC_GSTAT_ADDR ? "ADDR " : "", + gio_err_stat & SGIMC_GSTAT_BC ? "BC " : "", + gio_err_stat & SGIMC_GSTAT_PIO_RD ? "PIO_RD " : "", + gio_err_stat & SGIMC_GSTAT_PIO_WR ? "PIO_WR " : "", + gio_err_addr); + error |= 16; + } + if (!error) + printk(KERN_ERR "MC: Hmm, didn't find any error condition.\n"); + else { + printk(KERN_ERR "CP0: config %08x, " + "MC: cpuctrl0/1: %08x/%05x, giopar: %04x\n" + "MC: cpu/gio_memacc: %08x/%05x, memcfg0/1: %08x/%08x\n", + read_c0_config(), + sgimc->cpuctrl0, sgimc->cpuctrl0, sgimc->giopar, + sgimc->cmacc, sgimc->gmacc, + sgimc->mconfig0, sgimc->mconfig1); + print_cache_tags(); + } + printk(KERN_ALERT "%s, epc == %0*lx, ra == %0*lx\n", + cause_excode_text(regs->cp0_cause), + field, regs->cp0_epc, field, regs->regs[31]); +} + +/* + * Try to find out, whether the bus error is caused by the instruction + * at EPC, otherwise we have an asynchronous error. + * + * Doc1: "MIPS IV Instruction Set", Rev 3.2 (SGI 007-2597-001) + * Doc2: "MIPS R10000 Microporcessor User's Manual", Ver 2.0 (SGI 007-2490-001) + * Doc3: "MIPS R4000 Microporcessor User's Manual", 2nd Ed. (SGI 007-2489-001) + */ + +#define JMP_INDEX26_OP 1 +#define JMP_REGISTER_OP 2 +#define JMP_PCREL16_OP 3 +#define BASE_OFFSET_OP 4 +#define BASE_IDXREG_OP 5 + +/* Match virtual address in an insn with physical error address */ + +static int match_addr(unsigned paddr, unsigned long vaddr) +{ + unsigned long uaddr; + + if ((vaddr & 0xffffffff80000000L) == 0xffffffff80000000L) + uaddr = (unsigned) CPHYSADDR(vaddr); + else if ((vaddr >> 62) == 2) + uaddr = (unsigned) XPHYSADDR(vaddr); + else { + unsigned long eh = vaddr & ~0x1fffL; + + eh |= read_c0_entryhi() & 0xff; + write_c0_entryhi(eh); + tlb_probe(); + if (read_c0_index() & 0x80000000) + return 0; + tlb_read(); + if (vaddr & (1L << PAGE_SHIFT)) + uaddr = (unsigned) read_c0_entrylo1(); + else + uaddr = (unsigned) read_c0_entrylo0(); + uaddr <<= 6; + uaddr &= ~PAGE_MASK; + uaddr |= vaddr & PAGE_MASK; + } + return ((uaddr & ~0x7f) == (paddr & ~0x7f)); +} + +/* Check, which kind of memory reference is triggered by `insn' */ + +static int check_special(unsigned insn) +{ + /* See Doc1, page A-180 */ + unsigned func = insn & 0x3f; + + if (8 == func || 8+1 == func) /* JR, JALR */ + return JMP_REGISTER_OP; + + return 0; +} + +static int check_regimm(unsigned insn) +{ + /* See Doc1, page A-180 */ + unsigned rt = (insn >> 19) & 3; /* bits 20..19[..16] */ + + /* BLTZ, BGEZ, BLTZL, BBGEZL || BLTZAL, BGEZAL, BLTZALL, BBGEZALL */ + if (!rt || 2 == rt) + return JMP_PCREL16_OP; + + return 0; +} + +static int check_cop0(unsigned insn) +{ + /* See Doc2, pages 287 ff., 187 ff. */ + if ((insn >> 26) == 5*8+7) /* CACHE */ + switch ((insn >> 16) & 0x1f) { + case Index_Writeback_Inv_D: + case Hit_Writeback_Inv_D: + case Index_Writeback_Inv_S: + case Hit_Writeback_Inv_S: + return BASE_OFFSET_OP; + } + return 0; +} + +static int check_cop1(unsigned insn) +{ + /* See Doc1, pages B-108 ff. */ + unsigned fmt = (insn >> 21) & 0x1f; /* bits 25..21 */ + + if (8 == fmt) /* BC1* */ + return JMP_PCREL16_OP; + + return 0; +} + +static int check_cop1x(unsigned insn) +{ + /* See Doc1, pages B-108 ff. */ + switch (insn & 0x3f) { + case 0: /* LWXC1 */ + case 1: /* LDXC1 */ + case 8: /* SWXC1 */ + case 8+1: /* SDXC1 */ + return BASE_IDXREG_OP; + } + return 0; +} + +static int check_plain(unsigned insn) +{ + /* See Doc1, page A-180 */ + unsigned opcode = insn >> 26; + + if (2 == opcode || 3 == opcode) /* J, JAL */ + return JMP_INDEX26_OP; + + if ((4 <= opcode && opcode <= 7) || /* BEQ, BNE, BLEZ, BGTZ */ + (4+2*8 <= opcode && opcode <= 7+2*8)) /* BEQL, BNEL, BLEZL, BGTZL */ + return JMP_PCREL16_OP; + + if (6*8+3 == opcode) /* PREF */ + return 0; + + if (3*8+2 == opcode || 3*8+3 == opcode || /* LDL, LDR */ + 4*8 <= opcode) /* misc. LOAD, STORE */ + return BASE_OFFSET_OP; + + return 0; +} + +/* Check, whether the insn at EPC causes a memory access at `paddr' */ + +static int check_addr_in_insn(unsigned paddr, const struct pt_regs *regs) +{ + unsigned long epc; + unsigned insn; + unsigned long a; + int typ; + + epc = regs->cp0_cause & CAUSEF_BD ? regs->cp0_epc:regs->cp0_epc+4; + + /* show_code() from kernel/traps.c */ + if (__get_user(insn, (u32 *)epc)) + return 1; + + /* See Doc1, pages A-180, B-108 ff. */ + switch (insn >> 26) { + case 0: + typ = check_special(insn); + break; + case 1: + typ = check_regimm(insn); + break; + case 2*8: /* COP0 */ + case 5*8+7: /* CACHE */ + typ = check_cop0(insn); + break; + case 2*8+1: + typ = check_cop1(insn); + break; + case 2*8+3: + typ = check_cop1x(insn); + break; + default: + typ = check_plain(insn); + break; + } + switch (typ) { + case JMP_INDEX26_OP: + a = (regs->cp0_epc + 4) & ~0xfffffff; + a |= (insn & 0x3ffffff) << 2; + return match_addr(paddr, a); + case JMP_REGISTER_OP: + a = regs->regs[(insn >> 21) & 0x1f]; + return match_addr(paddr, a); + case JMP_PCREL16_OP: + a = regs->cp0_epc + 4 + ((insn & 0xffff) << 2); + return match_addr(paddr, a); + case BASE_OFFSET_OP: + a = regs->regs[(insn >> 21) & 0x1f] + (insn & 0xffff); + return match_addr(paddr, a); + case BASE_IDXREG_OP: + a = regs->regs[(insn >> 21) & 0x1f]; + a += regs->regs[(insn >> 16) & 0x1f]; + return match_addr(paddr, a); + case 0: + return 0; + } + /* Assume it would be too dangerous to continue ... */ + return 1; +} + +/* + * Check, whether MC's (virtual) DMA address caused the bus error. + * See "Virtual DMA Specification", Draft 1.5, Feb 13 1992, SGI + */ + +static int addr_is_ram(unsigned long addr, unsigned sz) +{ + int i; + + for (i = 0; i < boot_mem_map.nr_map; i++) { + unsigned long a = boot_mem_map.map[i].addr; + if (a <= addr && addr+sz <= a+boot_mem_map.map[i].size) + return 1; + } + return 0; +} + +static int check_microtlb(u32 hi, u32 lo, unsigned long vaddr) +{ + /* This is likely rather similar to correct code ;-) */ + + vaddr &= 0x7fffffff; /* Doc. states that top bit is ignored */ + + /* If tlb-entry is valid and VPN-high (bits [30:21] ?) matches... */ + if ((lo & 2) && (vaddr >> 21) == ((hi<<1) >> 22)) { + u32 ctl = sgimc->dma_ctrl; + if (ctl & 1) { + unsigned int pgsz = (ctl & 2) ? 14:12; /* 16k:4k */ + /* PTEIndex is VPN-low (bits [22:14]/[20:12] ?) */ + unsigned long pte = (lo >> 6) << 12; /* PTEBase */ + pte += 8*((vaddr >> pgsz) & 0x1ff); + if (addr_is_ram(pte, 8)) { + /* + * Note: Since DMA hardware does look up + * translation on its own, this PTE *must* + * match the TLB/EntryLo-register format ! + */ + unsigned long a = *(unsigned long *) + PHYS_TO_XKSEG_UNCACHED(pte); + a = (a & 0x3f) << 6; /* PFN */ + a += vaddr & ((1 << pgsz) - 1); + return (cpu_err_addr == a); + } + } + } + return 0; +} + +static int check_vdma_memaddr(void) +{ + if (cpu_err_stat & CPU_ERRMASK) { + u32 a = sgimc->maddronly; + + if (!(sgimc->dma_ctrl & 0x100)) /* Xlate-bit clear ? */ + return (cpu_err_addr == a); + + if (check_microtlb(sgimc->dtlb_hi0, sgimc->dtlb_lo0, a) || + check_microtlb(sgimc->dtlb_hi1, sgimc->dtlb_lo1, a) || + check_microtlb(sgimc->dtlb_hi2, sgimc->dtlb_lo2, a) || + check_microtlb(sgimc->dtlb_hi3, sgimc->dtlb_lo3, a)) + return 1; + } + return 0; +} + +static int check_vdma_gioaddr(void) +{ + if (gio_err_stat & GIO_ERRMASK) { + u32 a = sgimc->gio_dma_trans; + a = (sgimc->gmaddronly & ~a) | (sgimc->gio_dma_sbits & a); + return (gio_err_addr == a); + } + return 0; +} + +/* + * MC sends an interrupt whenever bus or parity errors occur. In addition, + * if the error happened during a CPU read, it also asserts the bus error + * pin on the R4K. Code in bus error handler save the MC bus error registers + * and then clear the interrupt when this happens. + */ + +static int ip28_be_interrupt(const struct pt_regs *regs) +{ + int i; + + save_and_clear_buserr(); + /* + * Try to find out, whether we got here by a mispredicted speculative + * load/store operation. If so, it's not fatal, we can go on. + */ + /* Any cause other than "Interrupt" (ExcCode 0) is fatal. */ + if (regs->cp0_cause & CAUSEF_EXCCODE) + goto mips_be_fatal; + + /* Any cause other than "Bus error interrupt" (IP6) is weird. */ + if ((regs->cp0_cause & CAUSEF_IP6) != CAUSEF_IP6) + goto mips_be_fatal; + + if (extio_stat & (EXTIO_HPC3_BUSERR | EXTIO_EISA_BUSERR)) + goto mips_be_fatal; + + /* Any state other than "Memory bus error" is fatal. */ + if (cpu_err_stat & CPU_ERRMASK & ~SGIMC_CSTAT_ADDR) + goto mips_be_fatal; + + /* GIO errors are fatal */ + if (gio_err_stat & GIO_ERRMASK) + goto mips_be_fatal; + + /* Finding `cpu_err_addr' in the insn at EPC is fatal. */ + if ((cpu_err_stat & CPU_ERRMASK) && + check_addr_in_insn(cpu_err_addr, regs)) + goto mips_be_fatal; + + /* + * Now we have an asynchronous bus error, speculatively or DMA caused. + * Need to search all DMA descriptors for the error address. + */ + for (i = 0; i < sizeof(hpc3)/sizeof(struct hpc3_stat); ++i) { + struct hpc3_stat *hp = (struct hpc3_stat *)&hpc3 + i; + if ((cpu_err_stat & CPU_ERRMASK) && + (cpu_err_addr == hp->ndptr || cpu_err_addr == hp->cbp)) + break; + if ((gio_err_stat & GIO_ERRMASK) && + (gio_err_addr == hp->ndptr || gio_err_addr == hp->cbp)) + break; + } + if (i < sizeof(hpc3)/sizeof(struct hpc3_stat)) { + struct hpc3_stat *hp = (struct hpc3_stat *)&hpc3 + i; + printk(KERN_ERR "at DMA addresses: HPC3 @ %08lx:" + " ctl %08x, ndp %08x, cbp %08x\n", + CPHYSADDR(hp->addr), hp->ctrl, hp->ndptr, hp->cbp); + goto mips_be_fatal; + } + /* Check MC's virtual DMA stuff. */ + if (check_vdma_memaddr()) { + printk(KERN_ERR "at GIO DMA: mem address 0x%08x.\n", + sgimc->maddronly); + goto mips_be_fatal; + } + if (check_vdma_gioaddr()) { + printk(KERN_ERR "at GIO DMA: gio address 0x%08x.\n", + sgimc->gmaddronly); + goto mips_be_fatal; + } + /* A speculative bus error... */ + if (debug_be_interrupt) { + print_buserr(regs); + printk(KERN_ERR "discarded!\n"); + } + return MIPS_BE_DISCARD; + +mips_be_fatal: + print_buserr(regs); + return MIPS_BE_FATAL; +} + +void ip22_be_interrupt(int irq) +{ + const struct pt_regs *regs = get_irq_regs(); + + count_be_interrupt++; + + if (ip28_be_interrupt(regs) != MIPS_BE_DISCARD) { + /* Assume it would be too dangerous to continue ... */ + die_if_kernel("Oops", regs); + force_sig(SIGBUS, current); + } else if (debug_be_interrupt) + show_regs((struct pt_regs *)regs); +} + +static int ip28_be_handler(struct pt_regs *regs, int is_fixup) +{ + /* + * We arrive here only in the unusual case of do_be() invocation, + * i.e. by a bus error exception without a bus error interrupt. + */ + if (is_fixup) { + count_be_is_fixup++; + save_and_clear_buserr(); + return MIPS_BE_FIXUP; + } + count_be_handler++; + return ip28_be_interrupt(regs); +} + +void __init ip22_be_init(void) +{ + board_be_handler = ip28_be_handler; +} + +int ip28_show_be_info(struct seq_file *m) +{ + seq_printf(m, "IP28 be fixups\t\t: %u\n", count_be_is_fixup); + seq_printf(m, "IP28 be interrupts\t: %u\n", count_be_interrupt); + seq_printf(m, "IP28 be handler\t\t: %u\n", count_be_handler); + + return 0; +} + +static int __init debug_be_setup(char *str) +{ + debug_be_interrupt++; + return 1; +} +__setup("ip28_debug_be", debug_be_setup); + diff --git a/include/asm-mips/dma.h b/include/asm-mips/dma.h index d6a6c21..1353c81 100644 --- a/include/asm-mips/dma.h +++ b/include/asm-mips/dma.h @@ -84,10 +84,9 @@ * Deskstations or Acer PICA but not the much more versatile DMA logic used * for the local devices on Acer PICA or Magnums. */ -#ifdef CONFIG_SGI_IP22 -/* Horrible hack to have a correct DMA window on IP22 */ -#include -#define MAX_DMA_ADDRESS (PAGE_OFFSET + SGIMC_SEG0_BADDR + 0x01000000) +#if defined(CONFIG_SGI_IP22) || defined(CONFIG_SGI_IP28) +/* don't care; ISA bus master won't work, ISA slave DMA supports 32bit addr */ +#define MAX_DMA_ADDRESS PAGE_OFFSET #else #define MAX_DMA_ADDRESS (PAGE_OFFSET + 0x01000000) #endif diff --git a/include/asm-mips/mach-ip28/cpu-feature-overrides.h b/include/asm-mips/mach-ip28/cpu-feature-overrides.h new file mode 100644 index 0000000..9a53b32 --- /dev/null +++ b/include/asm-mips/mach-ip28/cpu-feature-overrides.h @@ -0,0 +1,50 @@ +/* + * This file is subject to the terms and conditions of the GNU General Public + * License. See the file "COPYING" in the main directory of this archive + * for more details. + * + * Copyright (C) 2003 Ralf Baechle + * 6/2004 pf + */ +#ifndef __ASM_MACH_IP28_CPU_FEATURE_OVERRIDES_H +#define __ASM_MACH_IP28_CPU_FEATURE_OVERRIDES_H + +/* + * IP28 only comes with R10000 family processors all using the same config + */ +#define cpu_has_watch 1 +#define cpu_has_mips16 0 +#define cpu_has_divec 0 +#define cpu_has_vce 0 +#define cpu_has_cache_cdex_p 0 +#define cpu_has_cache_cdex_s 0 +#define cpu_has_prefetch 1 +#define cpu_has_mcheck 0 +#define cpu_has_ejtag 0 + +#define cpu_has_llsc 1 +#define cpu_has_vtag_icache 0 +#define cpu_has_dc_aliases 0 /* see probe_pcache() */ +#define cpu_has_ic_fills_f_dc 0 +#define cpu_has_dsp 0 +#define cpu_icache_snoops_remote_store 1 +#define cpu_has_mipsmt 0 +#define cpu_has_userlocal 0 + +#define cpu_has_nofpuex 0 +#define cpu_has_64bits 1 + +#define cpu_has_4kex 1 +#define cpu_has_4k_cache 1 + +#define cpu_has_inclusive_pcaches 1 + +#define cpu_dcache_line_size() 32 +#define cpu_icache_line_size() 64 + +#define cpu_has_mips32r1 0 +#define cpu_has_mips32r2 0 +#define cpu_has_mips64r1 0 +#define cpu_has_mips64r2 0 + +#endif /* __ASM_MACH_IP28_CPU_FEATURE_OVERRIDES_H */ diff --git a/include/asm-mips/mach-ip28/ds1286.h b/include/asm-mips/mach-ip28/ds1286.h new file mode 100644 index 0000000..471bb9a --- /dev/null +++ b/include/asm-mips/mach-ip28/ds1286.h @@ -0,0 +1,4 @@ +#ifndef __ASM_MACH_IP28_DS1286_H +#define __ASM_MACH_IP28_DS1286_H +#include +#endif /* __ASM_MACH_IP28_DS1286_H */ diff --git a/include/asm-mips/mach-ip28/spaces.h b/include/asm-mips/mach-ip28/spaces.h new file mode 100644 index 0000000..05aabb2 --- /dev/null +++ b/include/asm-mips/mach-ip28/spaces.h @@ -0,0 +1,22 @@ +/* + * This file is subject to the terms and conditions of the GNU General Public + * License. See the file "COPYING" in the main directory of this archive + * for more details. + * + * Copyright (C) 1994 - 1999, 2000, 03, 04 Ralf Baechle + * Copyright (C) 2000, 2002 Maciej W. Rozycki + * Copyright (C) 1990, 1999, 2000 Silicon Graphics, Inc. + * 2004 pf + */ +#ifndef _ASM_MACH_IP28_SPACES_H +#define _ASM_MACH_IP28_SPACES_H + +#define CAC_BASE 0xa800000000000000 + +#define HIGHMEM_START (~0UL) + +#define PHYS_OFFSET _AC(0x20000000, UL) + +#include + +#endif /* _ASM_MACH_IP28_SPACES_H */ diff --git a/include/asm-mips/mach-ip28/war.h b/include/asm-mips/mach-ip28/war.h new file mode 100644 index 0000000..a1baafa --- /dev/null +++ b/include/asm-mips/mach-ip28/war.h @@ -0,0 +1,25 @@ +/* + * 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) 2002, 2004, 2007 by Ralf Baechle + */ +#ifndef __ASM_MIPS_MACH_IP28_WAR_H +#define __ASM_MIPS_MACH_IP28_WAR_H + +#define R4600_V1_INDEX_ICACHEOP_WAR 0 +#define R4600_V1_HIT_CACHEOP_WAR 0 +#define R4600_V2_HIT_CACHEOP_WAR 0 +#define R5432_CP0_INTERRUPT_WAR 0 +#define BCM1250_M3_WAR 0 +#define SIBYTE_1956_WAR 0 +#define MIPS4K_ICACHE_REFILL_WAR 0 +#define MIPS_CACHE_SYNC_WAR 0 +#define TX49XX_ICACHE_INDEX_INV_WAR 0 +#define RM9000_CDEX_SMP_WAR 0 +#define ICACHE_REFILLS_WORKAROUND_WAR 0 +#define R10000_LLSC_WAR 1 +#define MIPS34K_MISSED_ITLB_WAR 0 + +#endif /* __ASM_MIPS_MACH_IP28_WAR_H */ From tsbogend@alpha.franken.de Sun Dec 2 12:02:51 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Sun, 02 Dec 2007 12:03:01 +0000 (GMT) Received: from elvis.franken.de ([193.175.24.41]:21221 "EHLO elvis.franken.de") by ftp.linux-mips.org with ESMTP id S20023460AbXLBMBD (ORCPT ); Sun, 2 Dec 2007 12:01:03 +0000 Received: from uucp (helo=solo.franken.de) by elvis.franken.de with local-bsmtp (Exim 3.36 #1) id 1IynVI-0001dY-03; Sun, 02 Dec 2007 13:00:56 +0100 Received: by solo.franken.de (Postfix, from userid 1000) id 9A8C8C2EB6; Sun, 2 Dec 2007 12:55:33 +0100 (CET) From: Thomas Bogendoerfer To: linux-kernel@vger.kernel.org, linux-mips@linux-mips.org cc: akpm@linux-foundation.org Subject: [PATCH] SERIAL: Use SGI_HAS_ZILOG for IP22_ZILOG depends Message-Id: <20071202115533.9A8C8C2EB6@solo.franken.de> Date: Sun, 2 Dec 2007 12:55:33 +0100 (CET) Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 17663 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: tsbogend@alpha.franken.de Precedence: bulk X-list: linux-mips - Use SGI_HAS_ZILOG for IP22_ZILOG depends - remove IP22 from description, because the driver works on more than IP22 SGI machines Signed-off-by: Thomas Bogendoerfer --- Please apply for 2.6.25. drivers/serial/Kconfig | 8 ++++---- 1 files changed, 4 insertions(+), 4 deletions(-) diff --git a/drivers/serial/Kconfig b/drivers/serial/Kconfig index d7e1996..90eb9ce 100644 --- a/drivers/serial/Kconfig +++ b/drivers/serial/Kconfig @@ -877,15 +877,15 @@ config SERIAL_SUNHV systems. Say Y if you want to be able to use this device. config SERIAL_IP22_ZILOG - tristate "IP22 Zilog8530 serial support" - depends on SGI_IP22 + tristate "SGI Zilog8530 serial support" + depends on SGI_HAS_ZILOG select SERIAL_CORE help - This driver supports the Zilog8530 serial ports found on SGI IP22 + This driver supports the Zilog8530 serial ports found on SGI systems. Say Y or M if you want to be able to these serial ports. config SERIAL_IP22_ZILOG_CONSOLE - bool "Console on IP22 Zilog8530 serial port" + bool "Console on SGI Zilog8530 serial port" depends on SERIAL_IP22_ZILOG=y select SERIAL_CORE_CONSOLE From tsbogend@alpha.franken.de Sun Dec 2 12:03:21 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Sun, 02 Dec 2007 12:03:24 +0000 (GMT) Received: from elvis.franken.de ([193.175.24.41]:21477 "EHLO elvis.franken.de") by ftp.linux-mips.org with ESMTP id S20023451AbXLBMBD (ORCPT ); Sun, 2 Dec 2007 12:01:03 +0000 Received: from uucp (helo=solo.franken.de) by elvis.franken.de with local-bsmtp (Exim 3.36 #1) id 1IynVJ-0001dY-00; Sun, 02 Dec 2007 13:00:57 +0100 Received: by solo.franken.de (Postfix, from userid 1000) id 56627C2EB6; Sun, 2 Dec 2007 12:55:36 +0100 (CET) From: Thomas Bogendoerfer To: linux-kernel@vger.kernel.org, linux-mips@linux-mips.org cc: akpm@linux-foundation.org Subject: [PATCH] CHAR: Use SGI_HAS_DS1286 for SGI_DS1286 depends Message-Id: <20071202115536.56627C2EB6@solo.franken.de> Date: Sun, 2 Dec 2007 12:55:36 +0100 (CET) Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 17664 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: tsbogend@alpha.franken.de Precedence: bulk X-list: linux-mips Use SGI_HAS_DS1286 for SGI_DS1286 depends Signed-off-by: Thomas Bogendoerfer --- Please apply for 2.6.25. drivers/char/Kconfig | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/drivers/char/Kconfig b/drivers/char/Kconfig index a509b8d..06271e8 100644 --- a/drivers/char/Kconfig +++ b/drivers/char/Kconfig @@ -777,7 +777,7 @@ config JS_RTC config SGI_DS1286 tristate "SGI DS1286 RTC support" - depends on SGI_IP22 + depends on SGI_HAS_DS1286 help If you say Y here and create a character special file /dev/rtc with major number 10 and minor number 135 using mknod ("man mknod"), you From vagabon.xyz@gmail.com Sun Dec 2 21:37:01 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Sun, 02 Dec 2007 21:37:09 +0000 (GMT) Received: from nf-out-0910.google.com ([64.233.182.185]:46289 "EHLO nf-out-0910.google.com") by ftp.linux-mips.org with ESMTP id S20029466AbXLBVhB (ORCPT ); Sun, 2 Dec 2007 21:37:01 +0000 Received: by nf-out-0910.google.com with SMTP id c10so2349760nfd for ; Sun, 02 Dec 2007 13:37:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding; bh=UAZtJ3kEYqMZ+aXyXI1j+O2cHDEjVbOGZDCAPwqu7n0=; b=QorbrMCunR6s+Dt7kBm7+wX3O3HTWNHhM3sz6yHnayTCb8SqaPN9XmcxU3dACIDfeNtJppCCvCkKYqjMQ186N61RPY/IMB6OcOc9JEkx8YBwqyIfOOavTjYLaVQxf/4DM2zQFVOq5S40bdav7OcuaO0GSuHL7RC7Q0f+ARJ1t9s= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=received:message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding; b=vEi+tkwE2AbK8750dhpD8JOLotLYZp1tRI33SShQu6uLfbgrqGRJs/sXmjaWc7B//kFUaxQ3R3D/Q5nfyWdnFgck8qayxogOw49Be84MVnYh7Wu/wC9xUd6nU6nBOEysJgjWFzlGjyF5WEvqLGOsLBTXGNz+M8JbxT0ryq1R85c= Received: by 10.86.100.7 with SMTP id x7mr9883680fgb.1196631420724; Sun, 02 Dec 2007 13:37:00 -0800 (PST) Received: from ?192.168.0.1? ( [82.235.205.153]) by mx.google.com with ESMTPS id l19sm11132985fgb.2007.12.02.13.36.59 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sun, 02 Dec 2007 13:36:59 -0800 (PST) Message-ID: <47532577.804@gmail.com> Date: Sun, 02 Dec 2007 22:36:55 +0100 From: Franck Bui-Huu User-Agent: Thunderbird 2.0.0.5 (X11/20070719) MIME-Version: 1.0 To: rmk@arm.linux.org.uk CC: linux-arch@vger.kernel.org, macro@linux-mips.org, linux-mips@linux-mips.org Subject: Re: [PATCH 1/2] Yet another __initxxx annotations: __initbss/__exitbss References: <1196543586-6698-1-git-send-email-fbuihuu@gmail.com> <1196543586-6698-2-git-send-email-fbuihuu@gmail.com> <20071201231823.GB5411@flint.arm.linux.org.uk> In-Reply-To: <20071201231823.GB5411@flint.arm.linux.org.uk> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 17665 X-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 Russell King wrote: > On Sat, Dec 01, 2007 at 10:13:05PM +0100, Franck Bui-Huu wrote: >> To select the BSS attribute for a peculiar section, the name of the >> section must start with 'bss.' pattern. This is at least how GCC >> 3.2/4.1.2 works and it's the reason why the 2 new sections haven't >> been called '.{init,exit}.bss'. >> >> To mark a data part of one of these 2 sections, we use the 2 new >> annotations: __initbss/__exitbss. >> >> All data marked as part of this section must not be initialized, >> of course. > > Are you sure about this? The gcc manual for 4.1.1 says: > > Use the `section' attribute with an _initialized_ definition of a > _global_ variable, as shown in the example. GCC issues a warning > and otherwise ignores the `section' attribute in uninitialized > variable declarations. > > which has had that paragraph since at least 3.4.0. Either the GCC > documentation is wrong or the compiler is misbehaving if what you say > works. Either way, I'd be nervous about relying on this given that > GCC developers like to change the compiler behaviour. > Thanks for pointing this out. We already have (incorrectly) uninitialized data which are part of the init.data section and the section attribute isn't ignored at all, at least on x86 and mips. On ARM, you could take a look at where 'command_line' array, declared in in arch/arm/kernel/setup.c, is placed. So, it seems that we already rely on the compiler behaviour. > Suggest getting the GCC developers nailed down to ensure we know what > the intended compiler behaviour is (and getting the docs to reflect that) > before relying on the existing behaviour. > Yes I agree. Do you have someone in mind to suggest or should I ask to the GCC mailing list ? Franck From tsbogend@alpha.franken.de Mon Dec 3 07:20:35 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 03 Dec 2007 07:20:43 +0000 (GMT) Received: from elvis.franken.de ([193.175.24.41]:44165 "EHLO elvis.franken.de") by ftp.linux-mips.org with ESMTP id S20022769AbXLCHUf (ORCPT ); Mon, 3 Dec 2007 07:20:35 +0000 Received: from uucp (helo=solo.franken.de) by elvis.franken.de with local-bsmtp (Exim 3.36 #1) id 1Iz5YT-0000ox-00; Mon, 03 Dec 2007 08:17:25 +0100 Received: by solo.franken.de (Postfix, from userid 1000) id 36E3FDE4C4; Sun, 2 Dec 2007 20:43:46 +0100 (CET) From: Thomas Bogendoerfer To: linux-kernel@vger.kernel.org, linux-mips@linux-mips.org cc: akpm@linux-foundation.org Subject: [PATCH] SC26XX: New serial driver for SC2681 uarts Message-Id: <20071202194346.36E3FDE4C4@solo.franken.de> Date: Sun, 2 Dec 2007 20:43:46 +0100 (CET) Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 17666 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: tsbogend@alpha.franken.de Precedence: bulk X-list: linux-mips New serial driver for SC2681/SC2691 uarts. Older SNI RM400 machines are using these chips for onboard serial ports. Signed-off-by: Thomas Bogendoerfer --- Please apply for 2.6.25. drivers/serial/Kconfig | 15 + drivers/serial/Makefile | 1 + drivers/serial/sc26xx.c | 757 +++++++++++++++++++++++++++++++++++++++++++++++ 3 files changed, 773 insertions(+), 0 deletions(-) diff --git a/drivers/serial/Kconfig b/drivers/serial/Kconfig index d7e1996..2ea55d0 100644 --- a/drivers/serial/Kconfig +++ b/drivers/serial/Kconfig @@ -1284,4 +1284,19 @@ config SERIAL_OF_PLATFORM Currently, only 8250 compatible ports are supported, but others can easily be added. +config SERIAL_SC26XX + tristate "SC2681/SC2692 serial port support" + depends on SNI_RM + select SERIAL_CORE + help + This is a driver for the onboard serial ports of + older RM400 machines. + +config SERIAL_SC26XX_CONSOLE + bool "Console on SC2681/SC2692 serial port" + depends on SERIAL_SC26XX + select SERIAL_CORE_CONSOLE + help + Support for Console on SC2681/SC2692 serial ports. + endmenu diff --git a/drivers/serial/Makefile b/drivers/serial/Makefile index af6377d..87d09b6 100644 --- a/drivers/serial/Makefile +++ b/drivers/serial/Makefile @@ -64,3 +64,4 @@ obj-$(CONFIG_SERIAL_UARTLITE) += uartlite.o obj-$(CONFIG_SERIAL_NETX) += netx-serial.o obj-$(CONFIG_SERIAL_OF_PLATFORM) += of_serial.o obj-$(CONFIG_SERIAL_KS8695) += serial_ks8695.o +obj-$(CONFIG_SERIAL_SC26XX) += sc26xx.o diff --git a/drivers/serial/sc26xx.c b/drivers/serial/sc26xx.c new file mode 100644 index 0000000..be563ad --- /dev/null +++ b/drivers/serial/sc26xx.c @@ -0,0 +1,757 @@ +/* + * SC268xx.c: Serial driver for Philiphs SC2681/SC2692 devices. + * + * Copyright (C) 2006,2007 Thomas Bogendörfer (tsbogend@alpha.franken.de) + */ + +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include + +#if defined(CONFIG_MAGIC_SYSRQ) +#define SUPPORT_SYSRQ +#endif + +#include + +#define SC26XX_MAJOR 204 +#define SC26XX_MINOR_START 205 +#define SC26XX_NR 2 + +struct uart_sc26xx_port { + struct uart_port port[2]; + u8 dsr_mask[2]; + u8 cts_mask[2]; + u8 dcd_mask[2]; + u8 ri_mask[2]; + u8 dtr_mask[2]; + u8 rts_mask[2]; + u8 imr; +}; + +/* register common to both ports */ +#define RD_ISR 0x14 +#define RD_IPR 0x34 + +#define WR_ACR 0x10 +#define WR_IMR 0x14 +#define WR_OPCR 0x34 +#define WR_OPR_SET 0x38 +#define WR_OPR_CLR 0x3C + +/* access common register */ +#define READ_SC(p, r) readb ((p)->membase + RD_##r) +#define WRITE_SC(p, r, v) writeb ((v), (p)->membase + WR_##r) + +/* register per port */ +#define RD_PORT_MRx 0x00 +#define RD_PORT_SR 0x04 +#define RD_PORT_RHR 0x0c + +#define WR_PORT_MRx 0x00 +#define WR_PORT_CSR 0x04 +#define WR_PORT_CR 0x08 +#define WR_PORT_THR 0x0c + +/* access port register */ +#define READ_SC_PORT(p, r) \ + readb((p)->membase + (p)->line * 0x20 + RD_PORT_##r) +#define WRITE_SC_PORT(p, r, v) \ + writeb((v), (p)->membase + (p)->line * 0x20 + WR_PORT_##r) + +/* SR bits */ +#define SR_BREAK (1 << 7) +#define SR_FRAME (1 << 6) +#define SR_PARITY (1 << 5) +#define SR_OVERRUN (1 << 4) +#define SR_TXRDY (1 << 2) +#define SR_RXRDY (1 << 0) + +#define CR_RES_MR (1 << 4) +#define CR_RES_RX (2 << 4) +#define CR_RES_TX (3 << 4) +#define CR_STRT_BRK (6 << 4) +#define CR_STOP_BRK (7 << 4) +#define CR_DIS_TX (1 << 3) +#define CR_ENA_TX (1 << 2) +#define CR_DIS_RX (1 << 1) +#define CR_ENA_RX (1 << 0) + +/* ISR bits */ +#define ISR_RXRDYB (1 << 5) +#define ISR_TXRDYB (1 << 4) +#define ISR_RXRDYA (1 << 1) +#define ISR_TXRDYA (1 << 0) + +/* IMR bits */ +#define IMR_RXRDY (1 << 1) +#define IMR_TXRDY (1 << 0) + +static void sc26xx_enable_irq(struct uart_port *port, int mask) +{ + struct uart_sc26xx_port *up; + int line = port->line; + + port -= line; + up = (struct uart_sc26xx_port *)port; + + up->imr |= mask << (line * 4); + WRITE_SC(port, IMR, up->imr); +} + +static void sc26xx_disable_irq(struct uart_port *port, int mask) +{ + struct uart_sc26xx_port *up; + int line = port->line; + + port -= line; + up = (struct uart_sc26xx_port *)port; + + up->imr &= ~(mask << (line * 4)); + WRITE_SC(port, IMR, up->imr); +} + +static struct tty_struct *receive_chars(struct uart_port *port) +{ + struct tty_struct *tty = NULL; + int limit = 10000; + unsigned char ch; + char flag; + u8 status; + + if (port->info != NULL) /* Unopened serial console */ + tty = port->info->tty; + + while (limit-- > 0) { + status = READ_SC_PORT(port, SR); + if (!(status & SR_RXRDY)) + break; + ch = READ_SC_PORT(port, RHR); + + flag = TTY_NORMAL; + port->icount.rx++; + + if (unlikely(status & (SR_BREAK | SR_FRAME | + SR_PARITY | SR_OVERRUN))) { + if (status & SR_BREAK) { + status &= ~(SR_PARITY | SR_FRAME); + port->icount.brk++; + if (uart_handle_break(port)) + continue; + } else if (status & SR_PARITY) + port->icount.parity++; + else if (status & SR_FRAME) + port->icount.frame++; + if (status & SR_OVERRUN) + port->icount.overrun++; + + status &= port->read_status_mask; + if (status & SR_BREAK) + flag = TTY_BREAK; + else if (status & SR_PARITY) + flag = TTY_PARITY; + else if (status & SR_FRAME) + flag = TTY_FRAME; + } + + if (uart_handle_sysrq_char(port, ch)) + continue; + + if (status & port->ignore_status_mask) + continue; + + tty_insert_flip_char(tty, ch, flag); + } + return tty; +} + +static void transmit_chars(struct uart_port *port) +{ + struct circ_buf *xmit; + + if (!port->info) + return; + + xmit = &port->info->xmit; + if (uart_circ_empty(xmit) || uart_tx_stopped(port)) { + sc26xx_disable_irq(port, IMR_TXRDY); + return; + } + while (!uart_circ_empty(xmit)) { + if (!(READ_SC_PORT(port, SR) & SR_TXRDY)) + break; + + WRITE_SC_PORT(port, THR, xmit->buf[xmit->tail]); + xmit->tail = (xmit->tail + 1) & (UART_XMIT_SIZE - 1); + port->icount.tx++; + } + if (uart_circ_chars_pending(xmit) < WAKEUP_CHARS) + uart_write_wakeup(port); +} + +static irqreturn_t sc26xx_interrupt(int irq, void *dev_id) +{ + struct uart_sc26xx_port *up = dev_id; + struct tty_struct *tty; + unsigned long flags; + u8 isr; + + spin_lock_irqsave(&up->port[0].lock, flags); + + tty = NULL; + isr = READ_SC(&up->port[0], ISR); + if (isr & ISR_TXRDYA) + transmit_chars(&up->port[0]); + if (isr & ISR_RXRDYA) + tty = receive_chars(&up->port[0]); + + spin_unlock(&up->port[0].lock); + + if (tty) + tty_flip_buffer_push(tty); + + spin_lock(&up->port[1].lock); + + tty = NULL; + if (isr & ISR_TXRDYB) + transmit_chars(&up->port[1]); + if (isr & ISR_RXRDYB) + tty = receive_chars(&up->port[1]); + + spin_unlock_irqrestore(&up->port[1].lock, flags); + + if (tty) + tty_flip_buffer_push(tty); + + return IRQ_HANDLED; +} + +/* port->lock is not held. */ +static unsigned int sc26xx_tx_empty(struct uart_port *port) +{ + unsigned long flags; + unsigned int ret; + + spin_lock_irqsave(&port->lock, flags); + ret = (READ_SC_PORT(port, SR) & SR_TXRDY) ? TIOCSER_TEMT : 0; + spin_unlock_irqrestore(&port->lock, flags); + return ret; +} + +/* port->lock held by caller. */ +static void sc26xx_set_mctrl(struct uart_port *port, unsigned int mctrl) +{ + struct uart_sc26xx_port *up; + int line = port->line; + + port -= line; + up = (struct uart_sc26xx_port *)port; + + if (up->dtr_mask[line]) { + if (mctrl & TIOCM_DTR) + WRITE_SC(port, OPR_SET, up->dtr_mask[line]); + else + WRITE_SC(port, OPR_CLR, up->dtr_mask[line]); + } + if (up->rts_mask[line]) { + if (mctrl & TIOCM_RTS) + WRITE_SC(port, OPR_SET, up->rts_mask[line]); + else + WRITE_SC(port, OPR_CLR, up->rts_mask[line]); + } +} + +/* port->lock is held by caller and interrupts are disabled. */ +static unsigned int sc26xx_get_mctrl(struct uart_port *port) +{ + struct uart_sc26xx_port *up; + int line = port->line; + unsigned int mctrl = TIOCM_DSR | TIOCM_CTS | TIOCM_CAR; + u8 ipr; + + port -= line; + up = (struct uart_sc26xx_port *)port; + ipr = READ_SC(port, IPR) ^ 0xff; + + if (up->dsr_mask[line]) { + mctrl &= ~TIOCM_DSR; + mctrl |= ipr & up->dsr_mask[line] ? TIOCM_DSR : 0; + } + if (up->cts_mask[line]) { + mctrl &= ~TIOCM_CTS; + mctrl |= ipr & up->cts_mask[line] ? TIOCM_CTS : 0; + } + if (up->dcd_mask[line]) { + mctrl &= ~TIOCM_CAR; + mctrl |= ipr & up->dcd_mask[line] ? TIOCM_CAR : 0; + } + if (up->ri_mask[line]) { + mctrl &= ~TIOCM_RNG; + mctrl |= ipr & up->ri_mask[line] ? TIOCM_RNG : 0; + } + return mctrl; +} + +/* port->lock held by caller. */ +static void sc26xx_stop_tx(struct uart_port *port) +{ + return; +} + +/* port->lock held by caller. */ +static void sc26xx_start_tx(struct uart_port *port) +{ + struct circ_buf *xmit = &port->info->xmit; + + while (!uart_circ_empty(xmit)) { + if (!(READ_SC_PORT(port, SR) & SR_TXRDY)) { + sc26xx_enable_irq(port, IMR_TXRDY); + break; + } + WRITE_SC_PORT(port, THR, xmit->buf[xmit->tail]); + xmit->tail = (xmit->tail + 1) & (UART_XMIT_SIZE - 1); + port->icount.tx++; + } +} + +/* port->lock held by caller. */ +static void sc26xx_stop_rx(struct uart_port *port) +{ +} + +/* port->lock held by caller. */ +static void sc26xx_enable_ms(struct uart_port *port) +{ +} + +/* port->lock is not held. */ +static void sc26xx_break_ctl(struct uart_port *port, int break_state) +{ + unsigned long flags; + + spin_lock_irqsave(&port->lock, flags); + if (break_state == -1) + WRITE_SC_PORT(port, CR, CR_STRT_BRK); + else + WRITE_SC_PORT(port, CR, CR_STOP_BRK); + spin_unlock_irqrestore(&port->lock, flags); +} + +/* port->lock is not held. */ +static int sc26xx_startup(struct uart_port *port) +{ + sc26xx_disable_irq(port, IMR_TXRDY | IMR_RXRDY); + WRITE_SC(port, OPCR, 0); + + /* reset tx and rx */ + WRITE_SC_PORT(port, CR, CR_RES_RX); + WRITE_SC_PORT(port, CR, CR_RES_TX); + + /* start rx/tx */ + WRITE_SC_PORT(port, CR, CR_ENA_TX | CR_ENA_RX); + + /* enable irqs */ + sc26xx_enable_irq(port, IMR_RXRDY); + return 0; +} + +/* port->lock is not held. */ +static void sc26xx_shutdown(struct uart_port *port) +{ + /* disable interrupst */ + sc26xx_disable_irq(port, IMR_TXRDY | IMR_RXRDY); + + /* stop tx/rx */ + WRITE_SC_PORT(port, CR, CR_DIS_TX | CR_DIS_RX); +} + +/* port->lock is not held. */ +static void sc26xx_set_termios(struct uart_port *port, struct ktermios *termios, + struct ktermios *old) +{ + unsigned int baud = uart_get_baud_rate(port, termios, old, 0, 4000000); + unsigned int quot = uart_get_divisor(port, baud); + unsigned int iflag, cflag; + unsigned long flags; + u8 mr1, mr2, csr; + + spin_lock_irqsave(&port->lock, flags); + + while ((READ_SC_PORT(port, SR) & ((1 << 3) | (1 << 2))) != 0xc) + udelay(2); + + WRITE_SC_PORT(port, CR, CR_DIS_TX | CR_DIS_RX); + + iflag = termios->c_iflag; + cflag = termios->c_cflag; + + port->read_status_mask = SR_OVERRUN; + if (iflag & INPCK) + port->read_status_mask |= SR_PARITY | SR_FRAME; + if (iflag & (BRKINT | PARMRK)) + port->read_status_mask |= SR_BREAK; + + port->ignore_status_mask = 0; + if (iflag & IGNBRK) + port->ignore_status_mask |= SR_BREAK; + if ((cflag & CREAD) == 0) + port->ignore_status_mask |= SR_BREAK | SR_FRAME | + SR_PARITY | SR_OVERRUN; + + switch (cflag & CSIZE) { + case CS5: + mr1 = 0x00; + break; + case CS6: + mr1 = 0x01; + break; + case CS7: + mr1 = 0x02; + break; + default: + case CS8: + mr1 = 0x03; + break; + } + mr2 = 0x07; + if (cflag & CSTOPB) + mr2 = 0x0f; + if (cflag & PARENB) { + if (cflag & PARODD) + mr1 |= (1 << 2); + } else + mr1 |= (2 << 3); + + switch (baud) { + case 50: + csr = 0x00; + break; + case 110: + csr = 0x11; + break; + case 134: + csr = 0x22; + break; + case 200: + csr = 0x33; + break; + case 300: + csr = 0x44; + break; + case 600: + csr = 0x55; + break; + case 1200: + csr = 0x66; + break; + case 2400: + csr = 0x88; + break; + case 4800: + csr = 0x99; + break; + default: + case 9600: + csr = 0xbb; + break; + case 19200: + csr = 0xcc; + break; + } + + WRITE_SC_PORT(port, CR, CR_RES_MR); + WRITE_SC_PORT(port, MRx, mr1); + WRITE_SC_PORT(port, MRx, mr2); + + WRITE_SC(port, ACR, 0x80); + WRITE_SC_PORT(port, CSR, csr); + + /* reset tx and rx */ + WRITE_SC_PORT(port, CR, CR_RES_RX); + WRITE_SC_PORT(port, CR, CR_RES_TX); + + WRITE_SC_PORT(port, CR, CR_ENA_TX | CR_ENA_RX); + while ((READ_SC_PORT(port, SR) & ((1 << 3) | (1 << 2))) != 0xc) + udelay(2); + + /* XXX */ + uart_update_timeout(port, cflag, + (port->uartclk / (16 * quot))); + + spin_unlock_irqrestore(&port->lock, flags); +} + +static const char *sc26xx_type(struct uart_port *port) +{ + return "SC26XX"; +} + +static void sc26xx_release_port(struct uart_port *port) +{ +} + +static int sc26xx_request_port(struct uart_port *port) +{ + return 0; +} + +static void sc26xx_config_port(struct uart_port *port, int flags) +{ +} + +static int sc26xx_verify_port(struct uart_port *port, struct serial_struct *ser) +{ + return -EINVAL; +} + +static struct uart_ops sc26xx_ops = { + .tx_empty = sc26xx_tx_empty, + .set_mctrl = sc26xx_set_mctrl, + .get_mctrl = sc26xx_get_mctrl, + .stop_tx = sc26xx_stop_tx, + .start_tx = sc26xx_start_tx, + .stop_rx = sc26xx_stop_rx, + .enable_ms = sc26xx_enable_ms, + .break_ctl = sc26xx_break_ctl, + .startup = sc26xx_startup, + .shutdown = sc26xx_shutdown, + .set_termios = sc26xx_set_termios, + .type = sc26xx_type, + .release_port = sc26xx_release_port, + .request_port = sc26xx_request_port, + .config_port = sc26xx_config_port, + .verify_port = sc26xx_verify_port, +}; + +static struct uart_port *sc26xx_port; + +#ifdef CONFIG_SERIAL_SC26XX_CONSOLE +static inline void sc26xx_console_putchar(struct uart_port *port, char c) +{ + unsigned long flags; + int limit = 1000000; + + spin_lock_irqsave(&port->lock, flags); + + while (limit-- > 0) { + if (READ_SC_PORT(port, SR) & SR_TXRDY) { + WRITE_SC_PORT(port, THR, c); + break; + } + udelay(2); + } + + spin_unlock_irqrestore(&port->lock, flags); +} + +static void sc26xx_console_write(struct console *con, const char *s, unsigned n) +{ + struct uart_port *port = sc26xx_port; + int i; + + for (i = 0; i < n; i++) { + if (*s == '\n') + sc26xx_console_putchar(port, '\r'); + sc26xx_console_putchar(port, *s++); + } +} + +static int __init sc26xx_console_setup(struct console *con, char *options) +{ + struct uart_port *port = sc26xx_port; + int baud = 9600; + int bits = 8; + int parity = 'n'; + int flow = 'n'; + + if (port->type != PORT_SC26XX) + return -1; + + printk(KERN_INFO "Console: ttySC%d (SC26XX)\n", con->index); + if (options) + uart_parse_options(options, &baud, &parity, &bits, &flow); + + return uart_set_options(port, con, baud, parity, bits, flow); +} + +static struct uart_driver sc26xx_reg; +static struct console sc26xx_console = { + .name = "ttySC", + .write = sc26xx_console_write, + .device = uart_console_device, + .setup = sc26xx_console_setup, + .flags = CON_PRINTBUFFER, + .index = -1, + .data = &sc26xx_reg, +}; +#define SC26XX_CONSOLE &sc26xx_console +#else +#define SC26XX_CONSOLE NULL +#endif + +static struct uart_driver sc26xx_reg = { + .owner = THIS_MODULE, + .driver_name = "SC26xx", + .dev_name = "ttySC", + .major = SC26XX_MAJOR, + .minor = SC26XX_MINOR_START, + .nr = SC26XX_NR, + .cons = SC26XX_CONSOLE, +}; + +static inline u8 sc26xx_flags2mask(unsigned int flags, unsigned int bitpos) +{ + unsigned int bit = (flags >> bitpos) & 15; + + return bit ? (1 << (bit - 1)) : 0; +} + +static void __devinit sc26xx_init_masks(struct uart_sc26xx_port *up, + int line, unsigned int data) +{ + up->dtr_mask[line] = sc26xx_flags2mask(data, 0); + up->rts_mask[line] = sc26xx_flags2mask(data, 4); + up->dsr_mask[line] = sc26xx_flags2mask(data, 8); + up->cts_mask[line] = sc26xx_flags2mask(data, 12); + up->dcd_mask[line] = sc26xx_flags2mask(data, 16); + up->ri_mask[line] = sc26xx_flags2mask(data, 20); +} + +static int __devinit sc26xx_probe(struct platform_device *dev) +{ + struct resource *res; + struct uart_sc26xx_port *up; + unsigned int *sc26xx_data = dev->dev.platform_data; + int err; + + res = platform_get_resource(dev, IORESOURCE_MEM, 0); + if (!res) + return -ENODEV; + + up = kzalloc(sizeof *up, GFP_KERNEL); + if (unlikely(!up)) + return -ENOMEM; + + up->port[0].line = 0; + up->port[0].ops = &sc26xx_ops; + up->port[0].type = PORT_SC26XX; + up->port[0].uartclk = (29491200 / 16); /* arbitrary */ + + up->port[0].mapbase = res->start; + up->port[0].membase = ioremap_nocache(up->port[0].mapbase, 0x40); + up->port[0].iotype = UPIO_MEM; + up->port[0].irq = platform_get_irq(dev, 0); + + up->port[0].dev = &dev->dev; + + sc26xx_init_masks(up, 0, sc26xx_data[0]); + + sc26xx_port = &up->port[0]; + + up->port[1].line = 1; + up->port[1].ops = &sc26xx_ops; + up->port[1].type = PORT_SC26XX; + up->port[1].uartclk = (29491200 / 16); /* arbitrary */ + + up->port[1].mapbase = up->port[0].mapbase; + up->port[1].membase = up->port[0].membase; + up->port[1].iotype = UPIO_MEM; + up->port[1].irq = up->port[0].irq; + + up->port[1].dev = &dev->dev; + + sc26xx_init_masks(up, 1, sc26xx_data[1]); + + err = uart_register_driver(&sc26xx_reg); + if (err) + goto out_free_port; + + sc26xx_reg.tty_driver->name_base = sc26xx_reg.minor; + + err = uart_add_one_port(&sc26xx_reg, &up->port[0]); + if (err) + goto out_unregister_driver; + + err = uart_add_one_port(&sc26xx_reg, &up->port[1]); + if (err) + goto out_remove_port0; + + err = request_irq(up->port[0].irq, sc26xx_interrupt, 0, "sc26xx", up); + if (err) + goto out_remove_ports; + + dev_set_drvdata(&dev->dev, up); + return 0; + +out_remove_ports: + uart_remove_one_port(&sc26xx_reg, &up->port[1]); +out_remove_port0: + uart_remove_one_port(&sc26xx_reg, &up->port[0]); + +out_unregister_driver: + uart_unregister_driver(&sc26xx_reg); + +out_free_port: + kfree(up); + sc26xx_port = NULL; + return err; +} + + +static int __exit sc26xx_driver_remove(struct platform_device *dev) +{ + struct uart_sc26xx_port *up = dev_get_drvdata(&dev->dev); + + free_irq(up->port[0].irq, up); + + uart_remove_one_port(&sc26xx_reg, &up->port[0]); + uart_remove_one_port(&sc26xx_reg, &up->port[1]); + + uart_unregister_driver(&sc26xx_reg); + + kfree(up); + sc26xx_port = NULL; + + dev_set_drvdata(&dev->dev, NULL); + return 0; +} + +static struct platform_driver sc26xx_driver = { + .probe = sc26xx_probe, + .remove = __devexit_p(sc26xx_driver_remove), + .driver = { + .name = "SC26xx", + }, +}; + +static int __init sc26xx_init(void) +{ + return platform_driver_register(&sc26xx_driver); +} + +static void __exit sc26xx_exit(void) +{ + platform_driver_unregister(&sc26xx_driver); +} + +module_init(sc26xx_init); +module_exit(sc26xx_exit); + + +MODULE_AUTHOR("Thomas Bogendörfer"); +MODULE_DESCRIPTION("SC681/SC2692 serial driver"); +MODULE_VERSION("1.0"); +MODULE_LICENSE("GPL"); From ralf@linux-mips.org Mon Dec 3 13:06:44 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 03 Dec 2007 13:06:46 +0000 (GMT) Received: from localhost.localdomain ([127.0.0.1]:8111 "EHLO dl5rb.ham-radio-op.net") by ftp.linux-mips.org with ESMTP id S20022380AbXLCNGo (ORCPT ); Mon, 3 Dec 2007 13:06:44 +0000 Received: from denk.linux-mips.net (denk.linux-mips.net [127.0.0.1]) by dl5rb.ham-radio-op.net (8.14.1/8.13.8) with ESMTP id lB3D5DtN006431; Mon, 3 Dec 2007 13:05:38 GMT Received: (from ralf@localhost) by denk.linux-mips.net (8.14.1/8.14.1/Submit) id lB3D5DC5006430; Mon, 3 Dec 2007 13:05:13 GMT Date: Mon, 3 Dec 2007 13:05:13 +0000 From: Ralf Baechle To: linux-mips@linux-mips.org, linux-serial@linux-mips.org Subject: Rename Sibyte duart devices? Message-ID: <20071203130512.GA6320@linux-mips.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.17 (2007-11-01) Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 17667 X-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 Devices created by udev have been named duart? instead of the common ttyS?. This is a nuisance because it requires changes to all sorts of config files such as /etc/inittab, /etc/securetty etc. to work. I suggest to kill the problem by the root by something like the below patch. Comments? Ralf Signed-off-by: Ralf Baechle drivers/serial/sb1250-duart.c | 4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/serial/sb1250-duart.c b/drivers/serial/sb1250-duart.c index 2d6c08b..0defbd6 100644 --- a/drivers/serial/sb1250-duart.c +++ b/drivers/serial/sb1250-duart.c @@ -897,7 +897,7 @@ static int __init sbd_console_setup(struct console *co, char *options) static struct uart_driver sbd_reg; static struct console sbd_console = { - .name = "duart", + .name = "ttyS", .write = sbd_console_write, .device = uart_console_device, .setup = sbd_console_setup, @@ -925,7 +925,7 @@ console_initcall(sbd_serial_console_init); static struct uart_driver sbd_reg = { .owner = THIS_MODULE, .driver_name = "serial", - .dev_name = "duart", + .dev_name = "ttyS", .major = TTY_MAJOR, .minor = SB1250_DUART_MINOR_BASE, .nr = DUART_MAX_CHIP * DUART_MAX_SIDE, From ralf@linux-mips.org Mon Dec 3 13:10:04 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 03 Dec 2007 13:10:06 +0000 (GMT) Received: from localhost.localdomain ([127.0.0.1]:39047 "EHLO dl5rb.ham-radio-op.net") by ftp.linux-mips.org with ESMTP id S20023380AbXLCNKE (ORCPT ); Mon, 3 Dec 2007 13:10:04 +0000 Received: from denk.linux-mips.net (denk.linux-mips.net [127.0.0.1]) by dl5rb.ham-radio-op.net (8.14.1/8.13.8) with ESMTP id lB3D8Ik2006474; Mon, 3 Dec 2007 13:08:38 GMT Received: (from ralf@localhost) by denk.linux-mips.net (8.14.1/8.14.1/Submit) id lB3D8IXo006473; Mon, 3 Dec 2007 13:08:18 GMT Date: Mon, 3 Dec 2007 13:08:18 +0000 From: Ralf Baechle To: linux-mips@linux-mips.org, linux-serial@vger.kernel.org Subject: Rename Sibyte duart devices? Message-ID: <20071203130818.GA6466@linux-mips.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.17 (2007-11-01) Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 17668 X-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 Devices created by udev have been named duart? instead of the common ttyS?. This is a nuisance because it requires changes to all sorts of config files such as /etc/inittab, /etc/securetty etc. to work. I suggest to kill the problem by the root by something like the below patch. Comments? Ralf Signed-off-by: Ralf Baechle drivers/serial/sb1250-duart.c | 4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/serial/sb1250-duart.c b/drivers/serial/sb1250-duart.c index 2d6c08b..0defbd6 100644 --- a/drivers/serial/sb1250-duart.c +++ b/drivers/serial/sb1250-duart.c @@ -897,7 +897,7 @@ static int __init sbd_console_setup(struct console *co, char *options) static struct uart_driver sbd_reg; static struct console sbd_console = { - .name = "duart", + .name = "ttyS", .write = sbd_console_write, .device = uart_console_device, .setup = sbd_console_setup, @@ -925,7 +925,7 @@ console_initcall(sbd_serial_console_init); static struct uart_driver sbd_reg = { .owner = THIS_MODULE, .driver_name = "serial", - .dev_name = "duart", + .dev_name = "ttyS", .major = TTY_MAJOR, .minor = SB1250_DUART_MINOR_BASE, .nr = DUART_MAX_CHIP * DUART_MAX_SIDE, From yoichi_yuasa@tripeaks.co.jp Mon Dec 3 13:35:50 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 03 Dec 2007 13:35:58 +0000 (GMT) Received: from mo31.po.2iij.NET ([210.128.50.54]:33099 "EHLO mo31.po.2iij.net") by ftp.linux-mips.org with ESMTP id S20024469AbXLCNfu (ORCPT ); Mon, 3 Dec 2007 13:35:50 +0000 Received: by mo.po.2iij.net (mo31) id lB3DYLFh055260; Mon, 3 Dec 2007 22:34:21 +0900 (JST) Received: from delta (95.26.30.125.dy.iij4u.or.jp [125.30.26.95]) by mbox.po.2iij.net (po-mbox303) id lB3DYJCt013684 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 3 Dec 2007 22:34:19 +0900 Date: Mon, 3 Dec 2007 22:34:18 +0900 From: Yoichi Yuasa To: Martin Michlmayr Cc: yoichi_yuasa@tripeaks.co.jp, linux-mips@linux-mips.org, Richard Purdie Subject: Re: CONFIG_LEDS_COBALT_RAQ not as module Message-Id: <20071203223418.2fec44a9.yoichi_yuasa@tripeaks.co.jp> In-Reply-To: <20071130163258.GA10006@deprecation.cyrius.com> References: <20071130163258.GA10006@deprecation.cyrius.com> Organization: TriPeaks Corporation X-Mailer: Sylpheed 2.4.5 (GTK+ 2.12.0; 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: 17669 X-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, 30 Nov 2007 17:32:58 +0100 Martin Michlmayr wrote: > Hi Yoichi, > > Is there are good reason why LEDS_COBALT_QUBE is a tristate while > LEDS_COBALT_RAQ is a bool? I don't see why the RAQ LED driver > couldn't be modular. RAQ LED driver support power off trigger. Power off trigger is generated at the end of all. This is the reason why RAQ LED driver doesn't have module_exit function. Moreover, this is the reason why it is bool. Yoichi From ths@networkno.de Mon Dec 3 14:14:34 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 03 Dec 2007 14:14:42 +0000 (GMT) Received: from relay01.mx.bawue.net ([193.7.176.67]:7043 "EHLO relay01.mx.bawue.net") by ftp.linux-mips.org with ESMTP id S20023388AbXLCOOe (ORCPT ); Mon, 3 Dec 2007 14:14:34 +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 relay01.mx.bawue.net (Postfix) with ESMTP id 3931F48BE4; Mon, 3 Dec 2007 15:14:28 +0100 (CET) Received: from ths by lagash with local (Exim 4.68) (envelope-from ) id 1IzC42-0005OA-Uq; Mon, 03 Dec 2007 14:14:26 +0000 Date: Mon, 3 Dec 2007 14:14:26 +0000 From: Thiemo Seufer To: Ralf Baechle Cc: linux-mips@linux-mips.org, linux-serial@vger.kernel.org Subject: Re: Rename Sibyte duart devices? Message-ID: <20071203141426.GI617@networkno.de> References: <20071203130818.GA6466@linux-mips.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20071203130818.GA6466@linux-mips.org> User-Agent: Mutt/1.5.17 (2007-11-01) Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 17670 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: ths@networkno.de Precedence: bulk X-list: linux-mips Ralf Baechle wrote: > Devices created by udev have been named duart? instead of the common > ttyS?. This is a nuisance because it requires changes to all sorts of > config files such as /etc/inittab, /etc/securetty etc. to work. I > suggest to kill the problem by the root by something like the below > patch. Comments? Debian uses such a patch since forever to avoid all the trouble. Thiemo From macro@linux-mips.org Mon Dec 3 14:19:16 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 03 Dec 2007 14:19:24 +0000 (GMT) Received: from cerber.ds.pg.gda.pl ([153.19.208.18]:17080 "EHLO cerber.ds.pg.gda.pl") by ftp.linux-mips.org with ESMTP id S20023388AbXLCOTQ (ORCPT ); Mon, 3 Dec 2007 14:19:16 +0000 Received: from localhost (unknown [127.0.0.17]) by cerber.ds.pg.gda.pl (Postfix) with ESMTP id D7BB340095; Mon, 3 Dec 2007 15:18:46 +0100 (CET) X-Virus-Scanned: amavisd-new at cerber.ds.pg.gda.pl Received: from cerber.ds.pg.gda.pl ([153.19.208.18]) by localhost (cerber.ds.pg.gda.pl [153.19.208.18]) (amavisd-new, port 10024) with ESMTP id g9SYV-I9mriz; Mon, 3 Dec 2007 15:18:41 +0100 (CET) Received: from piorun.ds.pg.gda.pl (piorun.ds.pg.gda.pl [153.19.208.8]) by cerber.ds.pg.gda.pl (Postfix) with ESMTP id 4EDB640003; Mon, 3 Dec 2007 15:18:41 +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 lB3EIidB009318; Mon, 3 Dec 2007 15:18:45 +0100 Date: Mon, 3 Dec 2007 14:18:35 +0000 (GMT) From: "Maciej W. Rozycki" To: Ralf Baechle cc: linux-mips@linux-mips.org, linux-serial@linux-mips.org Subject: Re: Rename Sibyte duart devices? In-Reply-To: <20071203130512.GA6320@linux-mips.org> Message-ID: References: <20071203130512.GA6320@linux-mips.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: ClamAV 0.91.2/4980/Mon Dec 3 03:28:55 2007 on piorun.ds.pg.gda.pl X-Virus-Status: Clean Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 17671 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: macro@linux-mips.org Precedence: bulk X-list: linux-mips On Mon, 3 Dec 2007, Ralf Baechle wrote: > Devices created by udev have been named duart? instead of the common > ttyS?. This is a nuisance because it requires changes to all sorts of > config files such as /etc/inittab, /etc/securetty etc. to work. I > suggest to kill the problem by the root by something like the below > patch. Comments? Well, there is no problem with naming your device nodes in the filesystem however you like and the only place that only cares is the "console=" command line option. I think the root is ttyS devices should really be only used for 8250-based devices and if you plug a standard PC serial option card into one of the PCI slots, then all the hell will break loose. I might be wrong though and the issue I am referring to may have gone now. Maciej From macro@linux-mips.org Mon Dec 3 14:30:58 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 03 Dec 2007 14:31:07 +0000 (GMT) Received: from cerber.ds.pg.gda.pl ([153.19.208.18]:20438 "EHLO cerber.ds.pg.gda.pl") by ftp.linux-mips.org with ESMTP id S20024652AbXLCOa6 (ORCPT ); Mon, 3 Dec 2007 14:30:58 +0000 Received: from localhost (unknown [127.0.0.17]) by cerber.ds.pg.gda.pl (Postfix) with ESMTP id 3003340095; Mon, 3 Dec 2007 15:30:59 +0100 (CET) X-Virus-Scanned: amavisd-new at cerber.ds.pg.gda.pl Received: from cerber.ds.pg.gda.pl ([153.19.208.18]) by localhost (cerber.ds.pg.gda.pl [153.19.208.18]) (amavisd-new, port 10024) with ESMTP id fzxSSMXOw8hG; Mon, 3 Dec 2007 15:30:53 +0100 (CET) Received: from piorun.ds.pg.gda.pl (piorun.ds.pg.gda.pl [153.19.208.8]) by cerber.ds.pg.gda.pl (Postfix) with ESMTP id AFE1240003; Mon, 3 Dec 2007 15:30:53 +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 lB3EUv0Z011443; Mon, 3 Dec 2007 15:30:57 +0100 Date: Mon, 3 Dec 2007 14:30:47 +0000 (GMT) From: "Maciej W. Rozycki" To: Ralf Baechle cc: linux-mips@linux-mips.org, linux-serial@vger.kernel.org Subject: Re: Rename Sibyte duart devices? In-Reply-To: <20071203130818.GA6466@linux-mips.org> Message-ID: References: <20071203130818.GA6466@linux-mips.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: ClamAV 0.91.2/4980/Mon Dec 3 03:28:55 2007 on piorun.ds.pg.gda.pl X-Virus-Status: Clean Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 17672 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: macro@linux-mips.org Precedence: bulk X-list: linux-mips On Mon, 3 Dec 2007, Ralf Baechle wrote: > Devices created by udev have been named duart? instead of the common > ttyS?. This is a nuisance because it requires changes to all sorts of > config files such as /etc/inittab, /etc/securetty etc. to work. I > suggest to kill the problem by the root by something like the below > patch. Comments? Well, there is no problem with naming your device nodes in the filesystem however you like and the only place that only cares is the "console=" command line option. I think the root is ttyS devices should really be only used for 8250-based devices and if you plug a standard PC serial option card into one of the PCI slots, then all the hell will break loose. I might be wrong though and the issue I am referring to may have gone now. [Sent twice to reach linux-serial.] Maciej From tony.luck@intel.com Mon Dec 3 17:01:05 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 03 Dec 2007 17:01:13 +0000 (GMT) Received: from mga02.intel.com ([134.134.136.20]:35318 "EHLO mga02.intel.com") by ftp.linux-mips.org with ESMTP id S20026145AbXLCRBF convert rfc822-to-8bit (ORCPT ); Mon, 3 Dec 2007 17:01:05 +0000 Received: from orsmga001.jf.intel.com ([10.7.209.18]) by orsmga101.jf.intel.com with ESMTP; 03 Dec 2007 09:00:57 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="4.23,244,1194249600"; d="scan'208";a="286035360" Received: from fmsmsx334.amr.corp.intel.com ([132.233.42.1]) by orsmga001.jf.intel.com with ESMTP; 03 Dec 2007 09:00:57 -0800 Received: from scsmsx411.amr.corp.intel.com ([10.3.90.30]) by fmsmsx334.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 3 Dec 2007 09:00:50 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8BIT Subject: RE: [PATCH 2/2] MIPS: vmlinux.lds.S: handle .{init,exit}.bss sections Date: Mon, 3 Dec 2007 09:00:49 -0800 Message-ID: <617E1C2C70743745A92448908E030B2A030FE4C2@scsmsx411.amr.corp.intel.com> In-Reply-To: <1196543586-6698-3-git-send-email-fbuihuu@gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PATCH 2/2] MIPS: vmlinux.lds.S: handle .{init,exit}.bss sections Thread-Index: Acg0Xwu30WWAvFsLTfOiwZEntWZUcQBblNdw References: <1196543586-6698-1-git-send-email-fbuihuu@gmail.com> <1196543586-6698-3-git-send-email-fbuihuu@gmail.com> From: "Luck, Tony" To: "Franck Bui-Huu" , Cc: , X-OriginalArrivalTime: 03 Dec 2007 17:00:50.0677 (UTC) FILETIME=[0EBB9A50:01C835CE] Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 17673 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: tony.luck@intel.com Precedence: bulk X-list: linux-mips + /* + * We keep init/exit bss sections here to have only one + * segment to load. Note that .bss.exit is also discarded + * at runtime for the same reason as above. + */ + .exit.bss : { + *(.bss.exit) + } This change would also require an audit of the bootloader or early kernel initialization code (whichever handles zeroing of .bss space) to make sure that it understands that the kernel will now have an extra block of memory that needs to be cleared. Perhaps nothing needs to be done if the code already handled the general case of loading an ELF binary with some sections that have an in-memory size bigger than the on-disk size. But worth looking at in case the code makes an assumption about what needs to be zeroed. -Tony From andy.sharp@onstor.com Mon Dec 3 17:59:26 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 03 Dec 2007 17:59:36 +0000 (GMT) Received: from [66.201.51.66] ([66.201.51.66]:24486 "EHLO ripper.onstor.net") by ftp.linux-mips.org with ESMTP id S20024727AbXLCR70 (ORCPT ); Mon, 3 Dec 2007 17:59:26 +0000 Received: from andys by ripper.onstor.net with local (Exim 4.63) (envelope-from ) id 1IzFWd-0006uL-CQ; Mon, 03 Dec 2007 09:56:11 -0800 Date: Mon, 3 Dec 2007 09:56:11 -0800 From: Andrew Sharp To: linux-mips@linux-mips.org Cc: Ralf Baechle Subject: [PATCH] Add code to determine the L2 cache size on Sibyte 1250/112x processors. Message-ID: <20071203175601.GA26533@onstor.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.13 (2006-08-11) Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 17674 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: andy.sharp@onstor.com Precedence: bulk X-list: linux-mips Resend with an actual from header in the email. Stupid git-send-email...grmbl Add code to determine the L2 cache size on Sibyte 1250/112x processors. Signed-off-by: Andrew Sharp --- arch/mips/mm/c-sb1.c | 70 ++++++++++++++++++++++++++++++++++ include/asm-mips/sibyte/sb1250_l2c.h | 4 ++ 2 files changed, 74 insertions(+), 0 deletions(-) diff --git a/arch/mips/mm/c-sb1.c b/arch/mips/mm/c-sb1.c index ca8547e..cbc39f7 100644 --- a/arch/mips/mm/c-sb1.c +++ b/arch/mips/mm/c-sb1.c @@ -28,6 +28,9 @@ #include #include #include +#include +#include +#include extern void sb1_dma_init(void); @@ -423,6 +426,68 @@ static unsigned int decode_cache_line_size(unsigned int config_field) } /* + * each bit in the 4-bit way-enable field indicates an enabled way + */ + + static int +decode_l2_ways(u64 l2_misc) +{ + int ways; + int size; + + ways = G_L2C_MISC_NO_WAY(l2_misc) ^ 0xf; + if (ways) { + int i; + + size = L2C_NUM_WAYS; + for (i = 0; i < 4; i++) { + if (ways & 1) { + size -= 1; + } + ways = ways >> 1; + } + ways = size; + } else { + ways = L2C_NUM_WAYS; + } + + return ways; +} + +/* + * 0 = full size: 512KiB on 1250, 256 on 112x + * 1 || 2 = 256KiB + * 5, 6, 9, a = 128 KiB + */ + static int +decode_l2_size(u64 l2_misc) +{ + int size = 0; + int ways; + + ways = decode_l2_ways(l2_misc); + + switch _SB_GETVALUE(l2_misc, 4, _SB_MAKEMASK(4, 4)) { + case 0: + /* line size is 32 bytes on l2 cache */ + size = (L2C_ENTRIES_PER_WAY * ways * 32) / 1024; + break; + case 1: + case 2: + size = 256; + break; + case 5: + case 6: + case 9: + case 0xa: + size = 128; + break; + } + + return size; +} + +/* * Relevant bits of the config1 register format (from the MIPS32/MIPS64 specs) * * 24:22 Icache sets per way @@ -441,6 +506,7 @@ static char *way_string[] = { static __init void probe_cache_sizes(void) { u32 config1; + u64 l2_misc; config1 = read_c0_config1(); icache_line_size = decode_cache_line_size((config1 >> 19) & 0x7); @@ -469,6 +535,10 @@ static __init void probe_cache_sizes(void) printk("Primary data cache %ldkB, %s, linesize %d bytes.\n", dcache_size >> 10, way_string[dcache_assoc - 1], dcache_line_size); + + l2_misc = __raw_readq(IOADDR(A_L2_READ_MISC)); + printk("Secondary cache %dkB, %s, linesize %d bytes.\n", + decode_l2_size(l2_misc), way_string[decode_l2_ways(l2_misc) - 1], 32); } /* diff --git a/include/asm-mips/sibyte/sb1250_l2c.h b/include/asm-mips/sibyte/sb1250_l2c.h index 842f205..6aa19ad 100644 --- a/include/asm-mips/sibyte/sb1250_l2c.h +++ b/include/asm-mips/sibyte/sb1250_l2c.h @@ -102,7 +102,11 @@ #define A_L2C_MGMT_TAG_BASE 0x00D0000000 +#ifndef CONFIG_SIBYTE_BCM112X #define L2C_ENTRIES_PER_WAY 4096 +#else +#define L2C_ENTRIES_PER_WAY 2048 +#endif #define L2C_NUM_WAYS 4 -- 1.4.4.4 From andy.sharp@onstor.com Mon Dec 3 18:17:12 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 03 Dec 2007 18:17:20 +0000 (GMT) Received: from [66.201.51.66] ([66.201.51.66]:22460 "EHLO ripper.onstor.net") by ftp.linux-mips.org with ESMTP id S20026619AbXLCSRM (ORCPT ); Mon, 3 Dec 2007 18:17:12 +0000 Received: from andys by ripper.onstor.net with local (Exim 4.63) (envelope-from ) id 1IzFqq-0006wF-VP; Mon, 03 Dec 2007 10:17:04 -0800 Date: Mon, 3 Dec 2007 10:17:04 -0800 From: Andrew Sharp To: linux-mips@linux-mips.org Cc: Ralf Baechle , akpm@linux-foundation.org, wim@iguana.be Subject: [PATCH] Add support for SB1 hardware watchdog. Message-ID: <20071203181658.GA26631@onstor.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.13 (2006-08-11) Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 17675 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: andy.sharp@onstor.com Precedence: bulk X-list: linux-mips This patch is for watchdog timers built into SiByte MIPS SoCs. Signed-off-by: Andy Sharp --- drivers/watchdog/Kconfig | 13 ++ drivers/watchdog/sb_wdog.c | 369 ++++++++++++++++++++++++++++++++++++++++++++ 2 files changed, 382 insertions(+), 0 deletions(-) diff --git a/drivers/watchdog/Kconfig b/drivers/watchdog/Kconfig index 2792bc1..9057362 100644 --- a/drivers/watchdog/Kconfig +++ b/drivers/watchdog/Kconfig @@ -616,6 +616,19 @@ config AR7_WDT help Hardware driver for the TI AR7 Watchdog Timer. +config SIBYTE_WDOG + tristate "Sibyte SoC hardware watchdog" + depends on CPU_SB1 + help + Watchdog driver for the built in watchdog hardware in Sibyte + SoC processors. There are apparently two watchdog timers + on such processors; this driver supports only the first one, + because currently Linux only supports exporting one watchdog + to userspace. + + To compile this driver as a loadable module, choose M here. + The module will be called sb_wdog. + # PARISC Architecture # POWERPC Architecture diff --git a/drivers/watchdog/sb_wdog.c b/drivers/watchdog/sb_wdog.c new file mode 100644 index 0000000..1e80803 --- /dev/null +++ b/drivers/watchdog/sb_wdog.c @@ -0,0 +1,369 @@ +/* + * Watchdog driver for SiByte SB1 SoCs + * + * Copyright (C) 2007 OnStor, Inc. * Andrew Sharp + * + * This driver is intended to make the second of two hardware watchdogs + * on the Sibyte 12XX and 11XX SoCs available to the user. There are two + * such devices available on the SoC, but it seems that there isn't an + * enumeration class for watchdogs in Linux like there is for RTCs. + * The second is used rather than the first because it uses IRQ 1, + * thereby avoiding all that IRQ 0 problematic nonsense. + * + * I have not tried this driver on a 1480 processor; it might work + * just well enough to really screw things up. + * + * It is a simple timer, and there is an interrupt that is raised the + * first time the timer expires. The second time it expires, the chip + * is reset and there is no way to redirect that NMI. Which could + * be problematic in some cases where this chip is sitting on the HT + * bus and has just taken responsibility for providing a cache block. + * Since the reset can't be redirected to the external reset pin, it is + * possible that other HT connected processors might hang and not reset. + * For Linux, a soft reset would probably be even worse than a hard reset. + * There you have it. + * + * The timer takes 23 bits of a 64 bit register (?) as a count value, + * and decrements the count every microsecond, for a max value of + * 0x7fffff usec or about 8.3ish seconds. + * + * This watchdog borrows some user semantics from the softdog driver, + * in that if you close the fd, it leaves the watchdog running, unless + * you previously wrote a 'V' to the fd, in which case it disables + * the watchdog when you close the fd like some other drivers. + * + * Based on various other watchdog drivers, which are probably all + * loosely based on something Alan Cox wrote years ago. + * + * (c) Copyright 1996 Alan Cox , All Rights Reserved. + * http://www.redhat.com + * + * This program is free software; you can redistribute it and/or + * modify it under the terms of the GNU General Public License + * version 1 or 2 as published by the Free Software Foundation. + * + */ +#include +#include +#include +#include +#include +#include +#include +#include + +#include +#include +#include +#include + + +/* + * set the initial count value of a timer + * + * wdog is the iomem address of the cfg register + */ + void +sbwdog_set(char __iomem *wdog, unsigned long t) +{ + __raw_writeb(0, wdog - 0x10); + __raw_writeq(t & 0x7fffffUL, wdog); +} + +/* + * cause the timer to [re]load it's initial count and start counting + * all over again + * + * wdog is the iomem address of the cfg register + */ + void +sbwdog_pet(char __iomem *wdog) +{ + __raw_writeb(__raw_readb(wdog) | 1, wdog); +} + +static unsigned long sbwdog_gate; /* keeps it to one thread only */ +static char __iomem *kern_dog = (char __iomem *)(IO_BASE + (A_SCD_WDOG_CFG_0)); +static char __iomem *user_dog = (char __iomem *)(IO_BASE + (A_SCD_WDOG_CFG_1)); +static unsigned long timeout = 0x7fffffUL; /* useconds: 8.3ish secs. */ +static int expect_close; + +static struct watchdog_info ident = { + .options = WDIOF_CARDRESET | WDIOF_SETTIMEOUT | WDIOF_KEEPALIVEPING, + .identity = "SiByte Watchdog", +}; + +/* + * Allow only a single thread to walk the dog + */ + static int +sbwdog_open(struct inode *inode, struct file *file) +{ + nonseekable_open(inode, file); + if (test_and_set_bit(0, &sbwdog_gate)) { + return -EBUSY; + } + + /* + * Activate the timer + */ + sbwdog_set(user_dog, timeout); + __raw_writeb(1, user_dog); + + return 0; +} + +/* + * Put the dog back in the kennel. + */ + static int +sbwdog_release(struct inode *inode, struct file *file) +{ + if (expect_close == 42) { + __raw_writeb(0, user_dog); + module_put(THIS_MODULE); + } else { + /* + * ONSTOR change - chassisd does not keep the fd open and we don't want + * this message everytime the fd is closed. + */ +#if !defined(CONFIG_ONSTOR_BOBCAT) && !defined(CONFIG_ONSTOR_COUGAR) + printk(KERN_CRIT "%s: Unexpected close, not stopping watchdog!\n", + ident.identity); +#endif + sbwdog_pet(user_dog); + } + clear_bit(0, &sbwdog_gate); + expect_close = 0; + + return 0; +} + +/* + * 42 - the answer + */ + static ssize_t +sbwdog_write(struct file *file, const char __user *data, size_t len, + loff_t *ppos) +{ + int i; + + if (len) { + /* + * restart the timer + */ + expect_close = 0; + + for (i = 0; i != len; i++) { + char c; + + if (get_user(c, data + i)) { + return -EFAULT; + } + if (c == 'V') { + expect_close = 42; + } + } + sbwdog_pet(user_dog); + } + + return len; +} + + static int +sbwdog_ioctl(struct inode *inode, struct file *file, unsigned int cmd, + unsigned long arg) +{ + int ret = -ENOTTY; + unsigned long time; + void __user *argp = (void __user *)arg; + int __user *p = argp; + + switch (cmd) { + case WDIOC_GETSUPPORT: + ret = copy_to_user(argp, &ident, sizeof(ident)) ? -EFAULT : 0; + break; + + case WDIOC_GETSTATUS: + /* + * return the bits from the config register + */ + ret = put_user(__raw_readb(user_dog), p); + break; + + case WDIOC_SETTIMEOUT: + ret = get_user(time, p); + if (ret) { + break; + } + + time *= 1000000; + if (time > 0x7fffffUL) { + ret = -EINVAL; + break; + } + timeout = time; + sbwdog_set(user_dog, timeout); + sbwdog_pet(user_dog); + + case WDIOC_GETTIMEOUT: + /* + * get the remaining count from the ... count register + * which is 1*8 before the config register + */ + ret = put_user(__raw_readq(user_dog - 8) / 1000000, p); + break; + + case WDIOC_KEEPALIVE: + sbwdog_pet(user_dog); + ret = 0; + break; + } + return ret; +} + +/* + * Notifier for system down + */ + static int +sbwdog_notify_sys(struct notifier_block *this, unsigned long code, void *erf) +{ + if (code == SYS_DOWN || code == SYS_HALT) { + /* + * sit and sit + */ + __raw_writeb(0, user_dog); + __raw_writeb(0, kern_dog); + } + + return NOTIFY_DONE; +} + +static const struct file_operations sbwdog_fops = +{ + .owner = THIS_MODULE, + .llseek = no_llseek, + .write = sbwdog_write, + .ioctl = sbwdog_ioctl, + .open = sbwdog_open, + .release = sbwdog_release, +}; + +static struct miscdevice sbwdog_miscdev = +{ + .minor = WATCHDOG_MINOR, + .name = "watchdog", + .fops = &sbwdog_fops, +}; + +static struct notifier_block sbwdog_notifier = { + .notifier_call = sbwdog_notify_sys, +}; + +/* + * interrupt handler + * + * doesn't do a whole lot for user, but oh so cleverly written so kernel + * code can use it to re-up the watchdog, thereby saving the kernel from + * having to create and maintain a timer, just to tickle another timer, + * which is just so wrong. + */ + irqreturn_t +sbwdog_interrupt(int irq, void *addr) +{ + unsigned long wd_init; + char *wd_cfg_reg = (char *)addr; + u8 cfg; + + cfg = __raw_readb(wd_cfg_reg); + wd_init = __raw_readq(wd_cfg_reg - 8) & 0x7fffff; + + /* + * if it's the second watchdog timer, it's for those users + */ + if (wd_cfg_reg == user_dog) { + printk(KERN_CRIT + "%s in danger of initiating system reset in %ld.%01ld seconds\n", + ident.identity, wd_init / 1000000, (wd_init / 100000) % 10); + } else { + cfg |= 1; + } + + __raw_writeb(cfg, wd_cfg_reg); + + return IRQ_HANDLED; +} + + static int __init +sbwdog_init(void) +{ + int ret; + + /* + * register a reboot notifier + */ + ret = register_reboot_notifier(&sbwdog_notifier); + if (ret) { + printk (KERN_ERR "%s: cannot register reboot notifier (err=%d)\n", + ident.identity, ret); + return ret; + } + + /* + * get the resources + */ + ret = misc_register(&sbwdog_miscdev); + if (ret == 0) { + printk(KERN_INFO "%s: timeout is %ld.%ld secs\n", ident.identity, + timeout / 1000000, (timeout / 100000) % 10); + } + + ret = request_irq(1, sbwdog_interrupt, IRQF_DISABLED | IRQF_SHARED, + ident.identity, (void *)user_dog); + if (ret) { + printk(KERN_ERR "%s: failed to request irq 1 - %d\n", ident.identity, + ret); + misc_deregister(&sbwdog_miscdev); + } + + return ret; +} + + static void __exit +sbwdog_exit(void) +{ + misc_deregister(&sbwdog_miscdev); +} + +module_init(sbwdog_init); +module_exit(sbwdog_exit); + +MODULE_AUTHOR("Andrew Sharp "); +MODULE_DESCRIPTION("SiByte Watchdog"); + +module_param(timeout, ulong, 0); +MODULE_PARM_DESC(timeout, + "Watchdog timeout in microseconds (max/default 8388607 or 8.3ish secs)"); + +MODULE_LICENSE("GPL"); +MODULE_ALIAS_MISCDEV(WATCHDOG_MINOR); + +/* + * example code that can be put in a platform code area to utilize the + * first watchdog timer for the kernels own purpose. + + void +platform_wd_setup(void) +{ + int ret; + + ret = request_irq(0, sbwdog_interrupt, IRQF_DISABLED | IRQF_SHARED, + "Kernel Watchdog", IOADDR(A_SCD_WDOG_CFG_0)); + if (ret) { + printk(KERN_CRIT "Watchdog IRQ zero(0) failed to be requested - %d\n", + ret); + } +} + + + */ -- 1.4.4.4 From alan@lxorguk.ukuu.org.uk Mon Dec 3 18:38:43 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 03 Dec 2007 18:38:51 +0000 (GMT) Received: from outpipe-village-512-1.bc.nu ([81.2.110.250]:55976 "EHLO the-village.bc.nu") by ftp.linux-mips.org with ESMTP id S20026719AbXLCSin (ORCPT ); Mon, 3 Dec 2007 18:38:43 +0000 Received: from the-village.bc.nu (localhost.localdomain [127.0.0.1]) by the-village.bc.nu (8.14.1/8.13.8) with ESMTP id lB3IYJGI030243; Mon, 3 Dec 2007 18:34:19 GMT Date: Mon, 3 Dec 2007 18:34:19 +0000 From: Alan Cox To: Andrew Sharp Cc: linux-mips@linux-mips.org, Ralf Baechle , akpm@linux-foundation.org, wim@iguana.be Subject: Re: [PATCH] Add support for SB1 hardware watchdog. Message-ID: <20071203183419.3213d551@the-village.bc.nu> In-Reply-To: <20071203181658.GA26631@onstor.com> References: <20071203181658.GA26631@onstor.com> X-Mailer: Claws Mail 2.10.0 (GTK+ 2.10.14; i386-redhat-linux-gnu) Organization: Red Hat UK Cyf., Amberley Place, 107-111 Peascod Street, Windsor, Berkshire, SL4 1TE, Y Deyrnas Gyfunol. Cofrestrwyd yng Nghymru a Lloegr o'r rhif cofrestru 3798903 Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 17676 X-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 such processors; this driver supports only the first one, > + because currently Linux only supports exporting one watchdog > + to userspace. Yep. Perhaps that should change. > + * wdog is the iomem address of the cfg register > + */ > + void > +sbwdog_set(char __iomem *wdog, unsigned long t) > +{ > + __raw_writeb(0, wdog - 0x10); > + __raw_writeq(t & 0x7fffffUL, wdog); > +} What guarantees you don't get a pair of these calls at once or interleaving ? > + * return the bits from the config register > + */ > + ret = put_user(__raw_readb(user_dog), p); Should return the translated status bits ? Alan From ralf@linux-mips.org Mon Dec 3 19:21:21 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 03 Dec 2007 19:21:23 +0000 (GMT) Received: from localhost.localdomain ([127.0.0.1]:15809 "EHLO dl5rb.ham-radio-op.net") by ftp.linux-mips.org with ESMTP id S20030070AbXLCTVV (ORCPT ); Mon, 3 Dec 2007 19:21:21 +0000 Received: from denk.linux-mips.net (denk.linux-mips.net [127.0.0.1]) by dl5rb.ham-radio-op.net (8.14.1/8.13.8) with ESMTP id lB3JKEZD015088; Mon, 3 Dec 2007 19:20:39 GMT Received: (from ralf@localhost) by denk.linux-mips.net (8.14.1/8.14.1/Submit) id lB3JKAdu015087; Mon, 3 Dec 2007 19:20:10 GMT Date: Mon, 3 Dec 2007 19:20:10 +0000 From: Ralf Baechle To: Andrew Sharp Cc: linux-mips@linux-mips.org Subject: Re: [PATCH] Add code to determine the L2 cache size on Sibyte 1250/112x processors. Message-ID: <20071203192010.GA14818@linux-mips.org> References: <20071203175601.GA26533@onstor.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20071203175601.GA26533@onstor.com> User-Agent: Mutt/1.5.17 (2007-11-01) Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 17677 X-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 03, 2007 at 09:56:11AM -0800, Andrew Sharp wrote: > arch/mips/mm/c-sb1.c | 70 ++++++++++++++++++++++++++++++++++ c-sb1.c does no longer exist. The functionality was folded into c-r4k.c and at the same time alot of insanity aka pass 1 workarounds dropped. Ralf From andy.sharp@onstor.com Mon Dec 3 19:24:47 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 03 Dec 2007 19:24:56 +0000 (GMT) Received: from mail.onstor.com ([66.201.51.107]:23200 "EHLO mail.onstor.com") by ftp.linux-mips.org with ESMTP id S20030164AbXLCTYr (ORCPT ); Mon, 3 Dec 2007 19:24:47 +0000 Received: from onstor-exch02.onstor.net ([66.201.51.106]) by mail.onstor.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 3 Dec 2007 11:24:19 -0800 Received: from ripper.onstor.net ([10.0.0.42]) by onstor-exch02.onstor.net with Microsoft SMTPSVC(6.0.3790.1830); Mon, 3 Dec 2007 11:24:19 -0800 Date: Mon, 3 Dec 2007 11:24:18 -0800 From: Andrew Sharp To: Alan Cox Cc: linux-mips@linux-mips.org, Ralf Baechle , akpm@linux-foundation.org, wim@iguana.be Subject: Re: [PATCH] Add support for SB1 hardware watchdog. Message-ID: <20071203112418.26b94838@ripper.onstor.net> In-Reply-To: <20071203183419.3213d551@the-village.bc.nu> References: <20071203181658.GA26631@onstor.com> <20071203183419.3213d551@the-village.bc.nu> Organization: Onstor X-Mailer: Sylpheed-Claws 2.6.0 (GTK+ 2.8.20; x86_64-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 03 Dec 2007 19:24:19.0003 (UTC) FILETIME=[19B1E8B0:01C835E2] Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 17678 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: andy.sharp@onstor.com Precedence: bulk X-list: linux-mips On Mon, 3 Dec 2007 18:34:19 +0000 Alan Cox wrote: > > + on such processors; this driver supports only the first > > one, > > + because currently Linux only supports exporting one > > watchdog > > + to userspace. > > Yep. Perhaps that should change. I thought about that just a little; I'm just not sure what it would mean to have multiple watchdog devices. > > + * wdog is the iomem address of the cfg register > > + */ > > + void > > +sbwdog_set(char __iomem *wdog, unsigned long t) > > +{ > > + __raw_writeb(0, wdog - 0x10); > > + __raw_writeq(t & 0x7fffffUL, wdog); > > +} > > What guarantees you don't get a pair of these calls at once or > interleaving ? Not much, I suppose, except that opening the device file is exclusive. A thread could fork (or dup) after that and get crazy in a theoretical scenario ... are you suggesting this be serialized? > > > > + * return the bits from the config register > > + */ > > + ret = put_user(__raw_readb(user_dog), p); > > Should return the translated status bits ? Don't need this really. I see a few more things that need cleaning up so I will do that and submit another patch. And with changing of the directory up a level, I also forgot the makefile change. > > > Alan From andy.sharp@onstor.com Mon Dec 3 19:36:26 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 03 Dec 2007 19:36:34 +0000 (GMT) Received: from mail.onstor.com ([66.201.51.107]:42411 "EHLO mail.onstor.com") by ftp.linux-mips.org with ESMTP id S20030212AbXLCTg0 (ORCPT ); Mon, 3 Dec 2007 19:36:26 +0000 Received: from onstor-exch02.onstor.net ([66.201.51.106]) by mail.onstor.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 3 Dec 2007 11:36:19 -0800 Received: from ripper.onstor.net ([10.0.0.42]) by onstor-exch02.onstor.net with Microsoft SMTPSVC(6.0.3790.1830); Mon, 3 Dec 2007 11:36:18 -0800 Date: Mon, 3 Dec 2007 11:36:18 -0800 From: Andrew Sharp To: Ralf Baechle Cc: linux-mips@linux-mips.org Subject: Re: [PATCH] Add code to determine the L2 cache size on Sibyte 1250/112x processors. Message-ID: <20071203113618.0a37c718@ripper.onstor.net> In-Reply-To: <20071203192010.GA14818@linux-mips.org> References: <20071203175601.GA26533@onstor.com> <20071203192010.GA14818@linux-mips.org> Organization: Onstor X-Mailer: Sylpheed-Claws 2.6.0 (GTK+ 2.8.20; x86_64-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 03 Dec 2007 19:36:18.0371 (UTC) FILETIME=[C678C130:01C835E3] Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 17679 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: andy.sharp@onstor.com Precedence: bulk X-list: linux-mips On Mon, 3 Dec 2007 19:20:10 +0000 Ralf Baechle wrote: > On Mon, Dec 03, 2007 at 09:56:11AM -0800, Andrew Sharp wrote: > > > arch/mips/mm/c-sb1.c | 70 > > ++++++++++++++++++++++++++++++++++ > > c-sb1.c does no longer exist. The functionality was folded into > c-r4k.c and at the same time alot of insanity aka pass 1 workarounds > dropped. Doh. I knew that, too. Mindlessly trying to clear my patch backlog... From kaz@zeugmasystems.com Mon Dec 3 21:41:38 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 03 Dec 2007 21:41:46 +0000 (GMT) Received: from mail.zeugmasystems.com ([192.139.122.66]:42882 "EHLO zeugmasystems.com") by ftp.linux-mips.org with ESMTP id S20030354AbXLCVli convert rfc822-to-8bit (ORCPT ); Mon, 3 Dec 2007 21:41:38 +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: Rename Sibyte duart devices? Date: Mon, 3 Dec 2007 13:41:09 -0800 Message-ID: In-Reply-To: <20071203130818.GA6466@linux-mips.org> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Rename Sibyte duart devices? Thread-Index: Acg1rekoVcCpg0Q4Spm0frpoBYZIpAAMtdwA From: "Kaz Kylheku" To: "Ralf Baechle" , , Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 17680 X-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 Ralf Baechle wrote: > Devices created by udev have been named duart? instead of the common > ttyS?. This is a nuisance because it requires changes to all sorts of > config files such as /etc/inittab, /etc/securetty etc. to work. > suggest to kill the problem by the root by something like the below > patch. Comments? I can see this kind of a change being somewhat sneaky; some Linux users on SiByte systems have already worked around for the duart naming not by patching the kernel but by modifying their text configurations to use the duart naming. After they figure out why, after upgrading to a new kernel, their system doesn't work any more, they will still have the problem that the newer and older kernel require different text configuration in the file system with respect to the tty devices. It's nice to be able to pull out an older kernel and boot with it, without having to remember a list of things to tweak. To be forward and backward compatible, the kernel should perhaps offer the device under both aliases: /etc/TTYSx and /etc/duartx. Kaz "Kompatibility Kurmudgeon" Kylheku From vagabon.xyz@gmail.com Mon Dec 3 21:46:35 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 03 Dec 2007 21:46:43 +0000 (GMT) Received: from mu-out-0910.google.com ([209.85.134.189]:60218 "EHLO mu-out-0910.google.com") by ftp.linux-mips.org with ESMTP id S20022417AbXLCVqf (ORCPT ); Mon, 3 Dec 2007 21:46:35 +0000 Received: by mu-out-0910.google.com with SMTP id g7so9619muf for ; Mon, 03 Dec 2007 13:46:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding; bh=GCNBWdof0iUVH/lrTlVLb6vunE0XhVT9ja2HGx3LYws=; b=fG1XodbWuT2sELPxwuxEUzysnG29L3Ms1Q2KOWG0uJblMt+y2jQAJ8BZIkDEIGryqVY5Ijh/E9lWraemLk5IRRXSfTSbEEyJZ7Tn5I66t1tGAVSdaYNETFDoXtJ8kRSRKjNpTy9vp4+Seof9CK9xMTa/SHS4dQ7MHccIo/ImtZ8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=received:message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding; b=M3q+dqvHWhdI3F7YWDweNND2G87weB69lm8jduMMSWWvaUVi94uOdtBVnPr6GK7EENAYY9n0wWdYPY4hT2up5CMHHmujYPwIGOZPzbAajTQZhhMesRnp0Kb7DkRxslLwQtNgP1GGq/+SpAubdU4C7KFvrsvy/59Qa7oEaVrTsFo= Received: by 10.86.73.17 with SMTP id v17mr5088022fga.1196718382718; Mon, 03 Dec 2007 13:46:22 -0800 (PST) Received: from ?192.168.0.1? ( [82.235.205.153]) by mx.google.com with ESMTPS id 4sm6478517fge.2007.12.03.13.46.21 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 03 Dec 2007 13:46:22 -0800 (PST) Message-ID: <47547926.5060806@gmail.com> Date: Mon, 03 Dec 2007 22:46:14 +0100 From: Franck Bui-Huu User-Agent: Thunderbird 2.0.0.5 (X11/20070719) MIME-Version: 1.0 To: "Luck, Tony" CC: linux-arch@vger.kernel.org, macro@linux-mips.org, linux-mips@linux-mips.org Subject: Re: [PATCH 2/2] MIPS: vmlinux.lds.S: handle .{init,exit}.bss sections References: <1196543586-6698-1-git-send-email-fbuihuu@gmail.com> <1196543586-6698-3-git-send-email-fbuihuu@gmail.com> <617E1C2C70743745A92448908E030B2A030FE4C2@scsmsx411.amr.corp.intel.com> In-Reply-To: <617E1C2C70743745A92448908E030B2A030FE4C2@scsmsx411.amr.corp.intel.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 17681 X-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 Luck, Tony wrote: > + /* > + * We keep init/exit bss sections here to have only one > + * segment to load. Note that .bss.exit is also discarded > + * at runtime for the same reason as above. > + */ > + .exit.bss : { > + *(.bss.exit) > + } > > This change would also require an audit of the bootloader or early > kernel initialization code (whichever handles zeroing of .bss space) I think the kernel doesn't rely on the bootloader for clearing bss. > to make sure that it understands that the kernel will now have an > extra block of memory that needs to be cleared. Perhaps nothing > needs to be done if the code already handled the general case of > loading an ELF binary with some sections that have an in-memory > size bigger than the on-disk size. But worth looking at in case > the code makes an assumption about what needs to be zeroed. > For MIPS case, there is normally no extra block of memory to clear. [__bss_start, __bss_stop] range still includes the whole memory block to clear. So there's no need to modify any other code. Franck From ralf@linux-mips.org Mon Dec 3 23:10:39 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 03 Dec 2007 23:10:41 +0000 (GMT) Received: from localhost.localdomain ([127.0.0.1]:16567 "EHLO dl5rb.ham-radio-op.net") by ftp.linux-mips.org with ESMTP id S20030483AbXLCXKj (ORCPT ); Mon, 3 Dec 2007 23:10:39 +0000 Received: from denk.linux-mips.net (denk.linux-mips.net [127.0.0.1]) by dl5rb.ham-radio-op.net (8.14.1/8.13.8) with ESMTP id lB3N8U7u018763; Mon, 3 Dec 2007 23:08:55 GMT Received: (from ralf@localhost) by denk.linux-mips.net (8.14.1/8.14.1/Submit) id lB3N8S20018762; Mon, 3 Dec 2007 23:08:28 GMT Date: Mon, 3 Dec 2007 23:08:28 +0000 From: Ralf Baechle To: Andrew Sharp Cc: linux-mips@linux-mips.org, akpm@linux-foundation.org, wim@iguana.be Subject: Re: [PATCH] Add support for SB1 hardware watchdog. Message-ID: <20071203230828.GA17960@linux-mips.org> References: <20071203181658.GA26631@onstor.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20071203181658.GA26631@onstor.com> User-Agent: Mutt/1.5.17 (2007-11-01) Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 17682 X-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 03, 2007 at 10:17:04AM -0800, Andrew Sharp wrote: > + Watchdog driver for the built in watchdog hardware in Sibyte > + SoC processors. There are apparently two watchdog timers > + on such processors; this driver supports only the first one, > + because currently Linux only supports exporting one watchdog > + to userspace. And even four watchdogs in the BCM1480. You'd think they'd trust their hardware more than that ;-) > + * This driver is intended to make the second of two hardware watchdogs > + * on the Sibyte 12XX and 11XX SoCs available to the user. There are two > + * such devices available on the SoC, but it seems that there isn't an > + * enumeration class for watchdogs in Linux like there is for RTCs. > + * The second is used rather than the first because it uses IRQ 1, > + * thereby avoiding all that IRQ 0 problematic nonsense. > + * > + * I have not tried this driver on a 1480 processor; it might work > + * just well enough to really screw things up. Four rather similar watchdogs using four interrupts also. > + * It is a simple timer, and there is an interrupt that is raised the > + * first time the timer expires. The second time it expires, the chip > + * is reset and there is no way to redirect that NMI. Which could > + * be problematic in some cases where this chip is sitting on the HT > + * bus and has just taken responsibility for providing a cache block. > + * Since the reset can't be redirected to the external reset pin, it is > + * possible that other HT connected processors might hang and not reset. > + * For Linux, a soft reset would probably be even worse than a hard reset. > + * There you have it. If read requests are never returned eventually the ZB bus HT host bridge will run out of buffers after the 16th request. The CPU has four more buffers so the 21st read will stall the CPU's execution. About a milisecond later the machine check exception will make the CPU resume execution. But at this stage some registers are marked busy in the register scoreboard and any reference to those CPU registers will cause the CPU to hang again ... until the next machine check. Game over, press button to continue. > + * The timer takes 23 bits of a 64 bit register (?) as a count value, > + * and decrements the count every microsecond, for a max value of > + * 0x7fffff usec or about 8.3ish seconds. One off - the maximum time is 0x800000µs. Ralf From akpm@linux-foundation.org Mon Dec 3 23:54:02 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 03 Dec 2007 23:54:11 +0000 (GMT) Received: from smtp2.linux-foundation.org ([207.189.120.14]:33196 "EHLO smtp2.linux-foundation.org") by ftp.linux-mips.org with ESMTP id S20030539AbXLCXyC (ORCPT ); Mon, 3 Dec 2007 23:54:02 +0000 Received: from imap1.linux-foundation.org (imap1.linux-foundation.org [207.189.120.55]) by smtp2.linux-foundation.org (8.13.5.20060308/8.13.5/Debian-3ubuntu1.1) with ESMTP id lB3NrHme030241 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 3 Dec 2007 15:53:18 -0800 Received: from akpm.corp.google.com (localhost [127.0.0.1]) by imap1.linux-foundation.org (8.13.5.20060308/8.13.5/Debian-3ubuntu1.1) with SMTP id lB3NrHoE023861; Mon, 3 Dec 2007 15:53:17 -0800 Date: Mon, 3 Dec 2007 15:53:17 -0800 From: Andrew Morton To: Thomas Bogendoerfer Cc: linux-kernel@vger.kernel.org, linux-mips@linux-mips.org, Andy Whitcroft , Alan Cox Subject: Re: [PATCH] SC26XX: New serial driver for SC2681 uarts Message-Id: <20071203155317.772231f9.akpm@linux-foundation.org> In-Reply-To: <20071202194346.36E3FDE4C4@solo.franken.de> References: <20071202194346.36E3FDE4C4@solo.franken.de> 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 X-MIMEDefang-Filter: lf$Revision: 1.188 $ X-Scanned-By: MIMEDefang 2.53 on 207.189.120.14 Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 17683 X-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@linux-foundation.org Precedence: bulk X-list: linux-mips On Sun, 2 Dec 2007 20:43:46 +0100 (CET) Thomas Bogendoerfer wrote: > New serial driver for SC2681/SC2691 uarts. Older SNI RM400 machines are > using these chips for onboard serial ports. > Little things... > --- /dev/null > +++ b/drivers/serial/sc26xx.c > @@ -0,0 +1,757 @@ > +/* > + * SC268xx.c: Serial driver for Philiphs SC2681/SC2692 devices. > + * > + * Copyright (C) 2006,2007 Thomas Bogend__rfer (tsbogend@alpha.franken.de) > + */ > + > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > + > +#if defined(CONFIG_MAGIC_SYSRQ) > +#define SUPPORT_SYSRQ > +#endif > + > +#include > + > +#define SC26XX_MAJOR 204 > +#define SC26XX_MINOR_START 205 > +#define SC26XX_NR 2 > + > +struct uart_sc26xx_port { > + struct uart_port port[2]; > + u8 dsr_mask[2]; > + u8 cts_mask[2]; > + u8 dcd_mask[2]; > + u8 ri_mask[2]; > + u8 dtr_mask[2]; > + u8 rts_mask[2]; > + u8 imr; > +}; > + > +/* register common to both ports */ > +#define RD_ISR 0x14 > +#define RD_IPR 0x34 > + > +#define WR_ACR 0x10 > +#define WR_IMR 0x14 > +#define WR_OPCR 0x34 > +#define WR_OPR_SET 0x38 > +#define WR_OPR_CLR 0x3C > + > +/* access common register */ > +#define READ_SC(p, r) readb ((p)->membase + RD_##r) > +#define WRITE_SC(p, r, v) writeb ((v), (p)->membase + WR_##r) No space before the (. checkpatch misses this. > +/* register per port */ > +#define RD_PORT_MRx 0x00 > +#define RD_PORT_SR 0x04 > +#define RD_PORT_RHR 0x0c > + > +#define WR_PORT_MRx 0x00 > +#define WR_PORT_CSR 0x04 > +#define WR_PORT_CR 0x08 > +#define WR_PORT_THR 0x0c > + > +/* access port register */ > +#define READ_SC_PORT(p, r) \ > + readb((p)->membase + (p)->line * 0x20 + RD_PORT_##r) > +#define WRITE_SC_PORT(p, r, v) \ > + writeb((v), (p)->membase + (p)->line * 0x20 + WR_PORT_##r) eww, ugly. Why not have a nice C function which is passed RD_PORT_SR, RD_PORT_RHR, etc? That has the (minor) advantage that it won't malfunction if someone does WRITE_SC_PORT(foo++, r, v); (the macro references an arg more than once) > +/* SR bits */ > +#define SR_BREAK (1 << 7) > +#define SR_FRAME (1 << 6) > +#define SR_PARITY (1 << 5) > +#define SR_OVERRUN (1 << 4) > +#define SR_TXRDY (1 << 2) > +#define SR_RXRDY (1 << 0) > + > +#define CR_RES_MR (1 << 4) > +#define CR_RES_RX (2 << 4) > +#define CR_RES_TX (3 << 4) > +#define CR_STRT_BRK (6 << 4) > +#define CR_STOP_BRK (7 << 4) > +#define CR_DIS_TX (1 << 3) > +#define CR_ENA_TX (1 << 2) > +#define CR_DIS_RX (1 << 1) > +#define CR_ENA_RX (1 << 0) > + > +/* ISR bits */ > +#define ISR_RXRDYB (1 << 5) > +#define ISR_TXRDYB (1 << 4) > +#define ISR_RXRDYA (1 << 1) > +#define ISR_TXRDYA (1 << 0) > + > +/* IMR bits */ > +#define IMR_RXRDY (1 << 1) > +#define IMR_TXRDY (1 << 0) > + > +static void sc26xx_enable_irq(struct uart_port *port, int mask) > +{ > + struct uart_sc26xx_port *up; > + int line = port->line; > + > + port -= line; > + up = (struct uart_sc26xx_port *)port; Yeah, lots of serial drivers do this and it's old-fashioned. It would be clearer to use container_of() rather than the open-coded typecast. That way, the uart_port doesn't need to be the first member of uart_sc26xx_port, too. > + up->imr |= mask << (line * 4); > + WRITE_SC(port, IMR, up->imr); > +} > > ... > > + > +/* port->lock is not held. */ > +static unsigned int sc26xx_tx_empty(struct uart_port *port) > +{ > + unsigned long flags; > + unsigned int ret; > + > + spin_lock_irqsave(&port->lock, flags); > + ret = (READ_SC_PORT(port, SR) & SR_TXRDY) ? TIOCSER_TEMT : 0; > + spin_unlock_irqrestore(&port->lock, flags); > + return ret; > +} I suspect the locking here doesn't actually do anything? > +/* port->lock is not held. */ > +static void sc26xx_set_termios(struct uart_port *port, struct ktermios *termios, > + struct ktermios *old) hm, termios stuff. I'll cc Alan on the commit... > +static struct uart_port *sc26xx_port; > + > +#ifdef CONFIG_SERIAL_SC26XX_CONSOLE > +static inline void sc26xx_console_putchar(struct uart_port *port, char c) > +{ > + unsigned long flags; > + int limit = 1000000; > + > + spin_lock_irqsave(&port->lock, flags); > + > + while (limit-- > 0) { > + if (READ_SC_PORT(port, SR) & SR_TXRDY) { > + WRITE_SC_PORT(port, THR, c); > + break; > + } > + udelay(2); > + } > + > + spin_unlock_irqrestore(&port->lock, flags); > +} This is far too large to be inlined. > +static void sc26xx_console_write(struct console *con, const char *s, unsigned n) > +{ > + struct uart_port *port = sc26xx_port; > + int i; > + > + for (i = 0; i < n; i++) { > + if (*s == '\n') > + sc26xx_console_putchar(port, '\r'); > + sc26xx_console_putchar(port, *s++); > + } > +} > + > +static int __init sc26xx_console_setup(struct console *con, char *options) > +{ > + struct uart_port *port = sc26xx_port; > + int baud = 9600; > + int bits = 8; > + int parity = 'n'; > + int flow = 'n'; > + > + if (port->type != PORT_SC26XX) > + return -1; > + > + printk(KERN_INFO "Console: ttySC%d (SC26XX)\n", con->index); > + if (options) > + uart_parse_options(options, &baud, &parity, &bits, &flow); > + > + return uart_set_options(port, con, baud, parity, bits, flow); > +} > + > +static struct uart_driver sc26xx_reg; > +static struct console sc26xx_console = { > + .name = "ttySC", > + .write = sc26xx_console_write, > + .device = uart_console_device, > + .setup = sc26xx_console_setup, > + .flags = CON_PRINTBUFFER, > + .index = -1, > + .data = &sc26xx_reg, > +}; > +#define SC26XX_CONSOLE &sc26xx_console > +#else > +#define SC26XX_CONSOLE NULL > +#endif > + > +static struct uart_driver sc26xx_reg = { > + .owner = THIS_MODULE, > + .driver_name = "SC26xx", > + .dev_name = "ttySC", > + .major = SC26XX_MAJOR, > + .minor = SC26XX_MINOR_START, > + .nr = SC26XX_NR, > + .cons = SC26XX_CONSOLE, > +}; > + > +static inline u8 sc26xx_flags2mask(unsigned int flags, unsigned int bitpos) > +{ > + unsigned int bit = (flags >> bitpos) & 15; > + > + return bit ? (1 << (bit - 1)) : 0; > +} This might be too big as well. It's less of an issue for __devinit text though. From SRS0+dd00f2f123ee515c5e23+1562+infradead.org+arjan@pentafluge.srs.infradead.org Tue Dec 4 00:02:46 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 04 Dec 2007 00:02:56 +0000 (GMT) Received: from pentafluge.infradead.org ([213.146.154.40]:59333 "EHLO pentafluge.infradead.org") by ftp.linux-mips.org with ESMTP id S20030551AbXLDACq (ORCPT ); Tue, 4 Dec 2007 00:02:46 +0000 Received: from [192.102.209.1] (helo=laptopd505.fenrus.org) by pentafluge.infradead.org with esmtpsa (Exim 4.68 #1 (Red Hat Linux)) id 1IzLCD-0002Sy-Ot; Mon, 03 Dec 2007 23:59:30 +0000 Date: Mon, 3 Dec 2007 15:57:46 -0800 From: Arjan van de Ven To: Andrew Morton Cc: Thomas Bogendoerfer , linux-kernel@vger.kernel.org, linux-mips@linux-mips.org, Andy Whitcroft , Alan Cox Subject: Re: [PATCH] SC26XX: New serial driver for SC2681 uarts Message-ID: <20071203155746.2dc4506d@laptopd505.fenrus.org> In-Reply-To: <20071203155317.772231f9.akpm@linux-foundation.org> References: <20071202194346.36E3FDE4C4@solo.franken.de> <20071203155317.772231f9.akpm@linux-foundation.org> Organization: Intel X-Mailer: Claws Mail 3.0.2 (GTK+ 2.12.1; i386-redhat-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-SRS-Rewrite: SMTP reverse-path rewritten from by pentafluge.infradead.org See http://www.infradead.org/rpr.html Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 17684 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: arjan@infradead.org Precedence: bulk X-list: linux-mips On Mon, 3 Dec 2007 15:53:17 -0800 Andrew Morton wrote: > On Sun, 2 Dec 2007 20:43:46 +0100 (CET) > Thomas Bogendoerfer wrote: > > > New serial driver for SC2681/SC2691 uarts. Older SNI RM400 machines > > are using these chips for onboard serial ports. > > > > Little things... > > > --- /dev/null > > +++ b/drivers/serial/sc26xx.c > > @@ -0,0 +1,757 @@ > > +/* > > + * SC268xx.c: Serial driver for Philiphs SC2681/SC2692 devices. > > + * > > + * Copyright (C) 2006,2007 Thomas Bogend__rfer > > (tsbogend@alpha.franken.de) > > + */ > > + > > +#include > > +#include > > +#include > > +#include > > +#include > > +#include > > +#include > > +#include > > +#include > > +#include > > +#include > > +#include > > +#include > > +#include > > +#include > > +#include > > + > > +#if defined(CONFIG_MAGIC_SYSRQ) > > +#define SUPPORT_SYSRQ > > +#endif > > + > > +#include > > + > > +#define SC26XX_MAJOR 204 > > +#define SC26XX_MINOR_START 205 > > +#define SC26XX_NR 2 did lanana assign these numbers officially? From david.kuk@entone.com Tue Dec 4 02:22:49 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 04 Dec 2007 02:22:57 +0000 (GMT) Received: from wa-out-1112.google.com ([209.85.146.180]:63517 "EHLO wa-out-1112.google.com") by ftp.linux-mips.org with ESMTP id S20030690AbXLDCWt (ORCPT ); Tue, 4 Dec 2007 02:22:49 +0000 Received: by wa-out-1112.google.com with SMTP id m16so5567078waf for ; Mon, 03 Dec 2007 18:22:36 -0800 (PST) Received: by 10.142.72.21 with SMTP id u21mr10479wfa.1196734956458; Mon, 03 Dec 2007 18:22:36 -0800 (PST) Received: by 10.142.169.11 with HTTP; Mon, 3 Dec 2007 18:22:35 -0800 (PST) Message-ID: Date: Tue, 4 Dec 2007 10:22:35 +0800 From: "David Kuk" To: "YH Lin" Subject: Re: smp8634 add memory at dram1 Cc: linux-mips@linux-mips.org In-Reply-To: <5DF100B598199744B111FCEA5222E78A01CB9F5F@sigma-exch1.sdesigns.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_14758_19589160.1196734956430" References: <5DF100B598199744B111FCEA5222E78A01CB9F5F@sigma-exch1.sdesigns.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: 17685 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: david.kuk@entone.com Precedence: bulk X-list: linux-mips ------=_Part_14758_19589160.1196734956430 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Dear YH I am sorry i have been disturbed by other issues, the memory problem seems little bit difficult to me. In our case, i saw that in prom.c under mips/tango2, the function prom_init , it shows that : memcfg_t *m=(memcfg_t*)KSEG1ADDR(MEM_BASE_dram_controller_0+FM_MEMCFG); it's seems the kernel has hard coded to point the starting memory to DRAM controller 0's starting address, if now, i have remap 64mb memory at DRAM controller 1 at remap register 4, The problem is come, the kernel will ignore any memory before dram controller 0's starting address. Even i have add 0x0c000000--0x10000000 as boot memory, it still think it's first usable pfn is at 0x10000000. my solution is 3 steps 1, modify the compiler, let the linux start address moved to 0x0c000000, 2. modify the YAMON, and map the DRAM 1 controller to remap register4 in YAMON stage 3, modify the linux, to set the two piece of memory to the kernel as boot memory . it's this possible, or it have other better solution ? thx a lot for your kindly help ! best wishes David ------=_Part_14758_19589160.1196734956430 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Dear YH

I am sorry i have been disturbed by other issues, the memory problem seems little bit difficult to me. In our case, i saw that in prom.c under mips/tango2, the function prom_init , it shows that :
memcfg_t *m=(memcfg_t*)KSEG1ADDR(MEM_BASE_dram_controller_0+FM_MEMCFG);

it's seems the kernel has hard coded to point the starting memory to DRAM controller 0's starting address, if now, i have remap 64mb memory at DRAM controller 1 at remap register 4, The problem is come, the kernel will ignore any memory before dram controller 0's starting address. Even i have add 0x0c000000--0x10000000 as boot memory, it still think it's first usable pfn is at 0x10000000.

my solution is 3 steps

1, modify the compiler, let the linux start address moved to 0x0c000000,
2. modify the YAMON, and map the DRAM 1 controller to remap register4 in YAMON stage
3, modify the linux, to set the two piece of memory to the kernel as boot memory .

it's this possible, or it have other better solution ?

thx a lot for your kindly help !


best wishes
David


------=_Part_14758_19589160.1196734956430-- From tsbogend@alpha.franken.de Tue Dec 4 08:35:25 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 04 Dec 2007 08:35:35 +0000 (GMT) Received: from elvis.franken.de ([193.175.24.41]:24465 "EHLO elvis.franken.de") by ftp.linux-mips.org with ESMTP id S20025308AbXLDIfZ (ORCPT ); Tue, 4 Dec 2007 08:35:25 +0000 Received: from uucp (helo=solo.franken.de) by elvis.franken.de with local-bsmtp (Exim 3.36 #1) id 1IzTFQ-0004S7-00; Tue, 04 Dec 2007 09:35:20 +0100 Received: by solo.franken.de (Postfix, from userid 1000) id 4A812DE4C4; Tue, 4 Dec 2007 09:25:35 +0100 (CET) Date: Tue, 4 Dec 2007 09:25:35 +0100 To: Arjan van de Ven Cc: Andrew Morton , linux-kernel@vger.kernel.org, linux-mips@linux-mips.org, Andy Whitcroft , Alan Cox Subject: Re: [PATCH] SC26XX: New serial driver for SC2681 uarts Message-ID: <20071204082534.GA5938@alpha.franken.de> References: <20071202194346.36E3FDE4C4@solo.franken.de> <20071203155317.772231f9.akpm@linux-foundation.org> <20071203155746.2dc4506d@laptopd505.fenrus.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20071203155746.2dc4506d@laptopd505.fenrus.org> User-Agent: Mutt/1.5.13 (2006-08-11) From: tsbogend@alpha.franken.de (Thomas Bogendoerfer) Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 17686 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: tsbogend@alpha.franken.de Precedence: bulk X-list: linux-mips On Mon, Dec 03, 2007 at 03:57:46PM -0800, Arjan van de Ven wrote: > > > +#define SC26XX_MAJOR 204 > > > +#define SC26XX_MINOR_START 205 > > > +#define SC26XX_NR 2 > > did lanana assign these numbers officially? I tried to numbers several months ago and didn't get any response :-( Thomas. -- Crap can work. Given enough thrust pigs will fly, but it's not necessary a good idea. [ RFC1925, 2.3 ] From geert@linux-m68k.org Tue Dec 4 11:01:38 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 04 Dec 2007 11:01:46 +0000 (GMT) Received: from hoboe1bl1.telenet-ops.be ([195.130.137.72]:4774 "EHLO hoboe1bl1.telenet-ops.be") by ftp.linux-mips.org with ESMTP id S20031501AbXLDLBd (ORCPT ); Tue, 4 Dec 2007 11:01:33 +0000 Received: from localhost (localhost.localdomain [127.0.0.1]) by hoboe1bl1.telenet-ops.be (Postfix) with SMTP id 81DAED4051; Tue, 4 Dec 2007 12:01:22 +0100 (CET) Received: from anakin.of.borg (d54C15D55.access.telenet.be [84.193.93.85]) by hoboe1bl1.telenet-ops.be (Postfix) with ESMTP id F13AED4036; Tue, 4 Dec 2007 12:01:21 +0100 (CET) Received: from anakin.of.borg (localhost [127.0.0.1]) by anakin.of.borg (8.14.1/8.14.1/Debian-9) with ESMTP id lB4B1LCE024122 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 4 Dec 2007 12:01:21 +0100 Received: from localhost (geert@localhost) by anakin.of.borg (8.14.1/8.14.1/Submit) with ESMTP id lB4B1KD5024119; Tue, 4 Dec 2007 12:01:20 +0100 X-Authentication-Warning: anakin.of.borg: geert owned process doing -bs Date: Tue, 4 Dec 2007 12:01:20 +0100 (CET) From: Geert Uytterhoeven To: Thomas Bogendoerfer Cc: Arjan van de Ven , Andrew Morton , linux-kernel@vger.kernel.org, linux-mips@linux-mips.org, Andy Whitcroft , Alan Cox Subject: Re: [PATCH] SC26XX: New serial driver for SC2681 uarts In-Reply-To: <20071204082534.GA5938@alpha.franken.de> Message-ID: References: <20071202194346.36E3FDE4C4@solo.franken.de> <20071203155317.772231f9.akpm@linux-foundation.org> <20071203155746.2dc4506d@laptopd505.fenrus.org> <20071204082534.GA5938@alpha.franken.de> 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: 17687 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: geert@linux-m68k.org Precedence: bulk X-list: linux-mips On Tue, 4 Dec 2007, Thomas Bogendoerfer wrote: > On Mon, Dec 03, 2007 at 03:57:46PM -0800, Arjan van de Ven wrote: > > > > +#define SC26XX_MAJOR 204 > > > > +#define SC26XX_MINOR_START 205 > > > > +#define SC26XX_NR 2 > > > > did lanana assign these numbers officially? > > I tried to numbers several months ago and didn't get any response :-( What about a dynamic number? Gr{oetje,eeting}s, Geert -- Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say "programmer" or something like that. -- Linus Torvalds From alan@lxorguk.ukuu.org.uk Tue Dec 4 12:51:59 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 04 Dec 2007 12:52:08 +0000 (GMT) Received: from [81.2.110.250] ([81.2.110.250]:10159 "EHLO the-village.bc.nu") by ftp.linux-mips.org with ESMTP id S20032322AbXLDMv7 (ORCPT ); Tue, 4 Dec 2007 12:51:59 +0000 Received: from the-village.bc.nu (localhost.localdomain [127.0.0.1]) by the-village.bc.nu (8.14.1/8.13.8) with ESMTP id lB4CjGVq000757; Tue, 4 Dec 2007 12:45:16 GMT Date: Tue, 4 Dec 2007 12:45:16 +0000 From: Alan Cox To: tsbogend@alpha.franken.de (Thomas Bogendoerfer) Cc: Arjan van de Ven , Andrew Morton , linux-kernel@vger.kernel.org, linux-mips@linux-mips.org, Andy Whitcroft Subject: Re: [PATCH] SC26XX: New serial driver for SC2681 uarts Message-ID: <20071204124516.0120266a@the-village.bc.nu> In-Reply-To: <20071204082534.GA5938@alpha.franken.de> References: <20071202194346.36E3FDE4C4@solo.franken.de> <20071203155317.772231f9.akpm@linux-foundation.org> <20071203155746.2dc4506d@laptopd505.fenrus.org> <20071204082534.GA5938@alpha.franken.de> X-Mailer: Claws Mail 2.10.0 (GTK+ 2.10.14; i386-redhat-linux-gnu) Organization: Red Hat UK Cyf., Amberley Place, 107-111 Peascod Street, Windsor, Berkshire, SL4 1TE, Y Deyrnas Gyfunol. Cofrestrwyd yng Nghymru a Lloegr o'r rhif cofrestru 3798903 Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 17688 X-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, 4 Dec 2007 09:25:35 +0100 tsbogend@alpha.franken.de (Thomas Bogendoerfer) wrote: > On Mon, Dec 03, 2007 at 03:57:46PM -0800, Arjan van de Ven wrote: > > > > +#define SC26XX_MAJOR 204 > > > > +#define SC26XX_MINOR_START 205 > > > > +#define SC26XX_NR 2 > > > > did lanana assign these numbers officially? > > I tried to numbers several months ago and didn't get any response Please raise it with the relevant people. If our LANANA administrator is not doing their job then the Linuxfoundation need to find a replacement, or hand control of it over to someone outside. From andy.sharp@onstor.com Tue Dec 4 19:03:14 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 04 Dec 2007 19:03:23 +0000 (GMT) Received: from [66.201.51.66] ([66.201.51.66]:22335 "EHLO ripper.onstor.net") by ftp.linux-mips.org with ESMTP id S20032920AbXLDTDO (ORCPT ); Tue, 4 Dec 2007 19:03:14 +0000 Received: from andys by ripper.onstor.net with local (Exim 4.63) (envelope-from ) id 1Izd2v-0003ji-Qd; Tue, 04 Dec 2007 11:03:05 -0800 Date: Tue, 4 Dec 2007 11:03:05 -0800 From: Andrew Sharp To: linux-mips@linux-mips.org Cc: Ralf Baechle , akpm@linux-foundation.org, wim@iguana.be Subject: [PATCH] Add support for SB1 hardware watchdog, try#2 Message-ID: <20071204190259.GA14326@onstor.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.13 (2006-08-11) Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 17689 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: andy.sharp@onstor.com Precedence: bulk X-list: linux-mips This patch is for watchdog timers built into SiByte MIPS SoCs. Resend with changes from comments. Signed-off-by: Andy Sharp --- drivers/watchdog/Kconfig | 13 ++ drivers/watchdog/Makefile | 1 + drivers/watchdog/sb_wdog.c | 362 ++++++++++++++++++++++++++++++++++++++++++++ 3 files changed, 376 insertions(+), 0 deletions(-) diff --git a/drivers/watchdog/Kconfig b/drivers/watchdog/Kconfig index 2792bc1..9057362 100644 --- a/drivers/watchdog/Kconfig +++ b/drivers/watchdog/Kconfig @@ -616,6 +616,19 @@ config AR7_WDT help Hardware driver for the TI AR7 Watchdog Timer. +config SIBYTE_WDOG + tristate "Sibyte SoC hardware watchdog" + depends on CPU_SB1 + help + Watchdog driver for the built in watchdog hardware in Sibyte + SoC processors. There are apparently two watchdog timers + on such processors; this driver supports only the first one, + because currently Linux only supports exporting one watchdog + to userspace. + + To compile this driver as a loadable module, choose M here. + The module will be called sb_wdog. + # PARISC Architecture # POWERPC Architecture diff --git a/drivers/watchdog/Makefile b/drivers/watchdog/Makefile index 7d9e573..eb3822b 100644 --- a/drivers/watchdog/Makefile +++ b/drivers/watchdog/Makefile @@ -91,6 +91,7 @@ obj-$(CONFIG_INDYDOG) += indydog.o obj-$(CONFIG_WDT_MTX1) += mtx-1_wdt.o obj-$(CONFIG_WDT_RM9K_GPI) += rm9k_wdt.o obj-$(CONFIG_AR7_WDT) += ar7_wdt.o +obj-$(CONFIG_SIBYTE_WDOG) += sb_wdog.o # PARISC Architecture diff --git a/drivers/watchdog/sb_wdog.c b/drivers/watchdog/sb_wdog.c new file mode 100644 index 0000000..d2a0886 --- /dev/null +++ b/drivers/watchdog/sb_wdog.c @@ -0,0 +1,362 @@ +/* + * Watchdog driver for SiByte SB1 SoCs + * + * Copyright (C) 2007 OnStor, Inc. * Andrew Sharp + * + * This driver is intended to make the second of two hardware watchdogs + * on the Sibyte 12XX and 11XX SoCs available to the user. There are two + * such devices available on the SoC, but it seems that there isn't an + * enumeration class for watchdogs in Linux like there is for RTCs. + * The second is used rather than the first because it uses IRQ 1, + * thereby avoiding all that IRQ 0 problematic nonsense. + * + * I have not tried this driver on a 1480 processor; it might work + * just well enough to really screw things up. + * + * It is a simple timer, and there is an interrupt that is raised the + * first time the timer expires. The second time it expires, the chip + * is reset and there is no way to redirect that NMI. Which could + * be problematic in some cases where this chip is sitting on the HT + * bus and has just taken responsibility for providing a cache block. + * Since the reset can't be redirected to the external reset pin, it is + * possible that other HT connected processors might hang and not reset. + * For Linux, a soft reset would probably be even worse than a hard reset. + * There you have it. + * + * The timer takes 23 bits of a 64 bit register (?) as a count value, + * and decrements the count every microsecond, for a max value of + * 0x7fffff usec or about 8.3ish seconds. + * + * This watchdog borrows some user semantics from the softdog driver, + * in that if you close the fd, it leaves the watchdog running, unless + * you previously wrote a 'V' to the fd, in which case it disables + * the watchdog when you close the fd like some other drivers. + * + * Based on various other watchdog drivers, which are probably all + * loosely based on something Alan Cox wrote years ago. + * + * (c) Copyright 1996 Alan Cox , All Rights Reserved. + * http://www.redhat.com + * + * This program is free software; you can redistribute it and/or + * modify it under the terms of the GNU General Public License + * version 1 or 2 as published by the Free Software Foundation. + * + */ +#include +#include +#include +#include +#include +#include +#include +#include + +#include +#include +#include +#include + + +/* + * set the initial count value of a timer + * + * wdog is the iomem address of the cfg register + */ + void +sbwdog_set(char __iomem *wdog, unsigned long t) +{ + __raw_writeb(0, wdog - 0x10); + __raw_writeq(t & 0x7fffffUL, wdog); +} + +/* + * cause the timer to [re]load it's initial count and start counting + * all over again + * + * wdog is the iomem address of the cfg register + */ + void +sbwdog_pet(char __iomem *wdog) +{ + __raw_writeb(__raw_readb(wdog) | 1, wdog); +} + +static unsigned long sbwdog_gate; /* keeps it to one thread only */ +static char __iomem *kern_dog = (char __iomem *)(IO_BASE + (A_SCD_WDOG_CFG_0)); +static char __iomem *user_dog = (char __iomem *)(IO_BASE + (A_SCD_WDOG_CFG_1)); +static unsigned long timeout = 0x7fffffUL; /* useconds: 8.3ish secs. */ +static int expect_close; + +static struct watchdog_info ident = { + .options = WDIOF_CARDRESET | WDIOF_SETTIMEOUT | WDIOF_KEEPALIVEPING, + .identity = "SiByte Watchdog", +}; + +/* + * Allow only a single thread to walk the dog + */ + static int +sbwdog_open(struct inode *inode, struct file *file) +{ + nonseekable_open(inode, file); + if (test_and_set_bit(0, &sbwdog_gate)) { + return -EBUSY; + } + __module_get(THIS_MODULE); + + /* + * Activate the timer + */ + sbwdog_set(user_dog, timeout); + __raw_writeb(1, user_dog); + + return 0; +} + +/* + * Put the dog back in the kennel. + */ + static int +sbwdog_release(struct inode *inode, struct file *file) +{ + if (expect_close == 42) { + __raw_writeb(0, user_dog); + module_put(THIS_MODULE); + } else { + printk(KERN_CRIT "%s: Unexpected close, not stopping watchdog!\n", + ident.identity); + sbwdog_pet(user_dog); + } + clear_bit(0, &sbwdog_gate); + expect_close = 0; + + return 0; +} + +/* + * 42 - the answer + */ + static ssize_t +sbwdog_write(struct file *file, const char __user *data, size_t len, + loff_t *ppos) +{ + int i; + + if (len) { + /* + * restart the timer + */ + expect_close = 0; + + for (i = 0; i != len; i++) { + char c; + + if (get_user(c, data + i)) { + return -EFAULT; + } + if (c == 'V') { + expect_close = 42; + } + } + sbwdog_pet(user_dog); + } + + return len; +} + + static int +sbwdog_ioctl(struct inode *inode, struct file *file, unsigned int cmd, + unsigned long arg) +{ + int ret = -ENOTTY; + unsigned long time; + void __user *argp = (void __user *)arg; + int __user *p = argp; + + switch (cmd) { + case WDIOC_GETSUPPORT: + ret = copy_to_user(argp, &ident, sizeof(ident)) ? -EFAULT : 0; + break; + + case WDIOC_GETSTATUS: + case WDIOC_GETBOOTSTATUS: + ret = put_user(0, p); + break; + + case WDIOC_SETTIMEOUT: + ret = get_user(time, p); + if (ret) { + break; + } + + time *= 1000000; + if (time > 0x7fffffUL) { + ret = -EINVAL; + break; + } + timeout = time; + sbwdog_set(user_dog, timeout); + sbwdog_pet(user_dog); + + case WDIOC_GETTIMEOUT: + /* + * get the remaining count from the ... count register + * which is 1*8 before the config register + */ + ret = put_user(__raw_readq(user_dog - 8) / 1000000, p); + break; + + case WDIOC_KEEPALIVE: + sbwdog_pet(user_dog); + ret = 0; + break; + } + return ret; +} + +/* + * Notifier for system down + */ + static int +sbwdog_notify_sys(struct notifier_block *this, unsigned long code, void *erf) +{ + if (code == SYS_DOWN || code == SYS_HALT) { + /* + * sit and sit + */ + __raw_writeb(0, user_dog); + __raw_writeb(0, kern_dog); + } + + return NOTIFY_DONE; +} + +static const struct file_operations sbwdog_fops = +{ + .owner = THIS_MODULE, + .llseek = no_llseek, + .write = sbwdog_write, + .ioctl = sbwdog_ioctl, + .open = sbwdog_open, + .release = sbwdog_release, +}; + +static struct miscdevice sbwdog_miscdev = +{ + .minor = WATCHDOG_MINOR, + .name = "watchdog", + .fops = &sbwdog_fops, +}; + +static struct notifier_block sbwdog_notifier = { + .notifier_call = sbwdog_notify_sys, +}; + +/* + * interrupt handler + * + * doesn't do a whole lot for user, but oh so cleverly written so kernel + * code can use it to re-up the watchdog, thereby saving the kernel from + * having to create and maintain a timer, just to tickle another timer, + * which is just so wrong. + */ + irqreturn_t +sbwdog_interrupt(int irq, void *addr) +{ + unsigned long wd_init; + char *wd_cfg_reg = (char *)addr; + u8 cfg; + + cfg = __raw_readb(wd_cfg_reg); + wd_init = __raw_readq(wd_cfg_reg - 8) & 0x7fffff; + + /* + * if it's the second watchdog timer, it's for those users + */ + if (wd_cfg_reg == user_dog) { + printk(KERN_CRIT + "%s in danger of initiating system reset in %ld.%01ld seconds\n", + ident.identity, wd_init / 1000000, (wd_init / 100000) % 10); + } else { + cfg |= 1; + } + + __raw_writeb(cfg, wd_cfg_reg); + + return IRQ_HANDLED; +} + + static int __init +sbwdog_init(void) +{ + int ret; + + /* + * register a reboot notifier + */ + ret = register_reboot_notifier(&sbwdog_notifier); + if (ret) { + printk (KERN_ERR "%s: cannot register reboot notifier (err=%d)\n", + ident.identity, ret); + return ret; + } + + /* + * get the resources + */ + ret = misc_register(&sbwdog_miscdev); + if (ret == 0) { + printk(KERN_INFO "%s: timeout is %ld.%ld secs\n", ident.identity, + timeout / 1000000, (timeout / 100000) % 10); + } + + ret = request_irq(1, sbwdog_interrupt, IRQF_DISABLED | IRQF_SHARED, + ident.identity, (void *)user_dog); + if (ret) { + printk(KERN_ERR "%s: failed to request irq 1 - %d\n", ident.identity, + ret); + misc_deregister(&sbwdog_miscdev); + } + + return ret; +} + + static void __exit +sbwdog_exit(void) +{ + misc_deregister(&sbwdog_miscdev); +} + +module_init(sbwdog_init); +module_exit(sbwdog_exit); + +MODULE_AUTHOR("Andrew Sharp "); +MODULE_DESCRIPTION("SiByte Watchdog"); + +module_param(timeout, ulong, 0); +MODULE_PARM_DESC(timeout, + "Watchdog timeout in microseconds (max/default 8388607 or 8.3ish secs)"); + +MODULE_LICENSE("GPL"); +MODULE_ALIAS_MISCDEV(WATCHDOG_MINOR); + +/* + * example code that can be put in a platform code area to utilize the + * first watchdog timer for the kernels own purpose. + + void +platform_wd_setup(void) +{ + int ret; + + ret = request_irq(0, sbwdog_interrupt, IRQF_DISABLED | IRQF_SHARED, + "Kernel Watchdog", IOADDR(A_SCD_WDOG_CFG_0)); + if (ret) { + printk(KERN_CRIT "Watchdog IRQ zero(0) failed to be requested - %d\n", + ret); + } +} + + + */ From jgarzik@pobox.com Tue Dec 4 20:18:09 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 04 Dec 2007 20:18:17 +0000 (GMT) Received: from srv5.dvmed.net ([207.36.208.214]:10720 "EHLO mail.dvmed.net") by ftp.linux-mips.org with ESMTP id S20032961AbXLDUSB (ORCPT ); Tue, 4 Dec 2007 20:18:01 +0000 Received: from cpe-069-134-071-233.nc.res.rr.com ([69.134.71.233] helo=core.yyz.us) by mail.dvmed.net with esmtpsa (Exim 4.63 #1 (Red Hat Linux)) id 1IzeAJ-0004lD-SE; Tue, 04 Dec 2007 20:14:48 +0000 Message-ID: <4755B536.8070003@pobox.com> Date: Tue, 04 Dec 2007 15:14:46 -0500 From: Jeff Garzik User-Agent: Thunderbird 2.0.0.9 (X11/20071115) MIME-Version: 1.0 To: Thomas Bogendoerfer CC: netdev@vger.kernel.org, linux-mips@linux-mips.org, ralf@linux-mips.org Subject: Re: [UPDATED PATCH] SGISEEQ: use cached memory access to make driver work on IP28 References: <20071202103312.75E51C2EB5@solo.franken.de> In-Reply-To: <20071202103312.75E51C2EB5@solo.franken.de> 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: 17690 X-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 Thomas Bogendoerfer wrote: > SGI IP28 machines would need special treatment (enable adding addtional > wait states) when accessing memory uncached. To avoid this pain I changed > the driver to use only cached access to memory. > > Signed-off-by: Thomas Bogendoerfer > --- > > Changes to last version: > - Use inline functions for dma_sync_* instead of macros (suggested by Ralf) > - added Kconfig change to make selection for similair SGI boxes easier Has Ralf ACK'd this updated version? This is for 2.6.25 (i.e. not a bug fix for 2.6.24-rc) I presume? From ralf@linux-mips.org Tue Dec 4 21:07:35 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 04 Dec 2007 21:07:37 +0000 (GMT) Received: from localhost.localdomain ([127.0.0.1]:60325 "EHLO dl5rb.ham-radio-op.net") by ftp.linux-mips.org with ESMTP id S20033005AbXLDVHf (ORCPT ); Tue, 4 Dec 2007 21:07:35 +0000 Received: from denk.linux-mips.net (denk.linux-mips.net [127.0.0.1]) by dl5rb.ham-radio-op.net (8.14.1/8.13.8) with ESMTP id lB4L5W2i000992; Tue, 4 Dec 2007 21:05:57 GMT Received: (from ralf@localhost) by denk.linux-mips.net (8.14.1/8.14.1/Submit) id lB4L5VNx000991; Tue, 4 Dec 2007 21:05:31 GMT Date: Tue, 4 Dec 2007 21:05:31 +0000 From: Ralf Baechle To: Jeff Garzik Cc: Thomas Bogendoerfer , netdev@vger.kernel.org, linux-mips@linux-mips.org Subject: Re: [UPDATED PATCH] SGISEEQ: use cached memory access to make driver work on IP28 Message-ID: <20071204210531.GB775@linux-mips.org> References: <20071202103312.75E51C2EB5@solo.franken.de> <4755B536.8070003@pobox.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4755B536.8070003@pobox.com> User-Agent: Mutt/1.5.17 (2007-11-01) Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 17691 X-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 04, 2007 at 03:14:46PM -0500, Jeff Garzik wrote: >> Changes to last version: >> - Use inline functions for dma_sync_* instead of macros (suggested by Ralf) >> - added Kconfig change to make selection for similair SGI boxes easier > > Has Ralf ACK'd this updated version? Acked-by: Ralf Baechle > This is for 2.6.25 (i.e. not a bug fix for 2.6.24-rc) I presume? Yes. IP28 support it scheduled to be merged for 2.6.25. Ralf From tsbogend@alpha.franken.de Tue Dec 4 23:44:33 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 04 Dec 2007 23:44:42 +0000 (GMT) Received: from elvis.franken.de ([193.175.24.41]:54747 "EHLO elvis.franken.de") by ftp.linux-mips.org with ESMTP id S20033436AbXLDXod (ORCPT ); Tue, 4 Dec 2007 23:44:33 +0000 Received: from uucp (helo=solo.franken.de) by elvis.franken.de with local-bsmtp (Exim 3.36 #1) id 1IzhOC-000195-00; Wed, 05 Dec 2007 00:41:20 +0100 Received: by solo.franken.de (Postfix, from userid 1000) id 89572DE4C4; Wed, 5 Dec 2007 00:41:12 +0100 (CET) Date: Wed, 5 Dec 2007 00:41:12 +0100 To: Andrew Morton Cc: linux-kernel@vger.kernel.org, linux-mips@linux-mips.org, Andy Whitcroft , Alan Cox Subject: Re: [PATCH] SC26XX: New serial driver for SC2681 uarts Message-ID: <20071204234112.GA12352@alpha.franken.de> References: <20071202194346.36E3FDE4C4@solo.franken.de> <20071203155317.772231f9.akpm@linux-foundation.org> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20071203155317.772231f9.akpm@linux-foundation.org> User-Agent: Mutt/1.5.13 (2006-08-11) From: tsbogend@alpha.franken.de (Thomas Bogendoerfer) Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 17692 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: tsbogend@alpha.franken.de Precedence: bulk X-list: linux-mips On Mon, Dec 03, 2007 at 03:53:17PM -0800, Andrew Morton wrote: > On Sun, 2 Dec 2007 20:43:46 +0100 (CET) > Thomas Bogendoerfer wrote: > > > New serial driver for SC2681/SC2691 uarts. Older SNI RM400 machines are > > using these chips for onboard serial ports. > > > > Little things... here is an updated version. Changes: - use container_of - remove not needed locking - remove inlines - fix macros with double argument reference Thomas. -- New serial driver for SC2681/SC2691 uarts. Older SNI RM400 machines are using these chips for onboard serial ports. Signed-off-by: Thomas Bogendoerfer --- drivers/serial/Kconfig | 15 + drivers/serial/Makefile | 1 + drivers/serial/sc26xx.c | 755 +++++++++++++++++++++++++++++++++++++++++++++++ 3 files changed, 771 insertions(+), 0 deletions(-) diff --git a/drivers/serial/Kconfig b/drivers/serial/Kconfig index d7e1996..2ea55d0 100644 --- a/drivers/serial/Kconfig +++ b/drivers/serial/Kconfig @@ -1284,4 +1284,19 @@ config SERIAL_OF_PLATFORM Currently, only 8250 compatible ports are supported, but others can easily be added. +config SERIAL_SC26XX + tristate "SC2681/SC2692 serial port support" + depends on SNI_RM + select SERIAL_CORE + help + This is a driver for the onboard serial ports of + older RM400 machines. + +config SERIAL_SC26XX_CONSOLE + bool "Console on SC2681/SC2692 serial port" + depends on SERIAL_SC26XX + select SERIAL_CORE_CONSOLE + help + Support for Console on SC2681/SC2692 serial ports. + endmenu diff --git a/drivers/serial/Makefile b/drivers/serial/Makefile index af6377d..87d09b6 100644 --- a/drivers/serial/Makefile +++ b/drivers/serial/Makefile @@ -64,3 +64,4 @@ obj-$(CONFIG_SERIAL_UARTLITE) += uartlite.o obj-$(CONFIG_SERIAL_NETX) += netx-serial.o obj-$(CONFIG_SERIAL_OF_PLATFORM) += of_serial.o obj-$(CONFIG_SERIAL_KS8695) += serial_ks8695.o +obj-$(CONFIG_SERIAL_SC26XX) += sc26xx.o diff --git a/drivers/serial/sc26xx.c b/drivers/serial/sc26xx.c new file mode 100644 index 0000000..a350b6d --- /dev/null +++ b/drivers/serial/sc26xx.c @@ -0,0 +1,755 @@ +/* + * SC268xx.c: Serial driver for Philiphs SC2681/SC2692 devices. + * + * Copyright (C) 2006,2007 Thomas Bogendörfer (tsbogend@alpha.franken.de) + */ + +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include + +#if defined(CONFIG_MAGIC_SYSRQ) +#define SUPPORT_SYSRQ +#endif + +#include + +#define SC26XX_MAJOR 204 +#define SC26XX_MINOR_START 205 +#define SC26XX_NR 2 + +struct uart_sc26xx_port { + struct uart_port port[2]; + u8 dsr_mask[2]; + u8 cts_mask[2]; + u8 dcd_mask[2]; + u8 ri_mask[2]; + u8 dtr_mask[2]; + u8 rts_mask[2]; + u8 imr; +}; + +/* register common to both ports */ +#define RD_ISR 0x14 +#define RD_IPR 0x34 + +#define WR_ACR 0x10 +#define WR_IMR 0x14 +#define WR_OPCR 0x34 +#define WR_OPR_SET 0x38 +#define WR_OPR_CLR 0x3C + +/* access common register */ +#define READ_SC(p, r) readb((p)->membase + RD_##r) +#define WRITE_SC(p, r, v) writeb((v), (p)->membase + WR_##r) + +/* register per port */ +#define RD_PORT_MRx 0x00 +#define RD_PORT_SR 0x04 +#define RD_PORT_RHR 0x0c + +#define WR_PORT_MRx 0x00 +#define WR_PORT_CSR 0x04 +#define WR_PORT_CR 0x08 +#define WR_PORT_THR 0x0c + +/* SR bits */ +#define SR_BREAK (1 << 7) +#define SR_FRAME (1 << 6) +#define SR_PARITY (1 << 5) +#define SR_OVERRUN (1 << 4) +#define SR_TXRDY (1 << 2) +#define SR_RXRDY (1 << 0) + +#define CR_RES_MR (1 << 4) +#define CR_RES_RX (2 << 4) +#define CR_RES_TX (3 << 4) +#define CR_STRT_BRK (6 << 4) +#define CR_STOP_BRK (7 << 4) +#define CR_DIS_TX (1 << 3) +#define CR_ENA_TX (1 << 2) +#define CR_DIS_RX (1 << 1) +#define CR_ENA_RX (1 << 0) + +/* ISR bits */ +#define ISR_RXRDYB (1 << 5) +#define ISR_TXRDYB (1 << 4) +#define ISR_RXRDYA (1 << 1) +#define ISR_TXRDYA (1 << 0) + +/* IMR bits */ +#define IMR_RXRDY (1 << 1) +#define IMR_TXRDY (1 << 0) + +/* access port register */ +static inline u8 read_sc_port(struct uart_port *p, u8 reg) +{ + return readb(p->membase + p->line * 0x20 + reg); +} + +static inline void write_sc_port(struct uart_port *p, u8 reg, u8 val) +{ + writeb(val, p->membase + p->line * 0x20 + reg); +} + +#define READ_SC_PORT(p, r) read_sc_port(p, RD_PORT_##r) +#define WRITE_SC_PORT(p, r, v) write_sc_port(p, WR_PORT_##r, v) + +static void sc26xx_enable_irq(struct uart_port *port, int mask) +{ + struct uart_sc26xx_port *up; + int line = port->line; + + port -= line; + up = container_of(port, struct uart_sc26xx_port, port[0]); + + up->imr |= mask << (line * 4); + WRITE_SC(port, IMR, up->imr); +} + +static void sc26xx_disable_irq(struct uart_port *port, int mask) +{ + struct uart_sc26xx_port *up; + int line = port->line; + + port -= line; + up = container_of(port, struct uart_sc26xx_port, port[0]); + + up->imr &= ~(mask << (line * 4)); + WRITE_SC(port, IMR, up->imr); +} + +static struct tty_struct *receive_chars(struct uart_port *port) +{ + struct tty_struct *tty = NULL; + int limit = 10000; + unsigned char ch; + char flag; + u8 status; + + if (port->info != NULL) /* Unopened serial console */ + tty = port->info->tty; + + while (limit-- > 0) { + status = READ_SC_PORT(port, SR); + if (!(status & SR_RXRDY)) + break; + ch = READ_SC_PORT(port, RHR); + + flag = TTY_NORMAL; + port->icount.rx++; + + if (unlikely(status & (SR_BREAK | SR_FRAME | + SR_PARITY | SR_OVERRUN))) { + if (status & SR_BREAK) { + status &= ~(SR_PARITY | SR_FRAME); + port->icount.brk++; + if (uart_handle_break(port)) + continue; + } else if (status & SR_PARITY) + port->icount.parity++; + else if (status & SR_FRAME) + port->icount.frame++; + if (status & SR_OVERRUN) + port->icount.overrun++; + + status &= port->read_status_mask; + if (status & SR_BREAK) + flag = TTY_BREAK; + else if (status & SR_PARITY) + flag = TTY_PARITY; + else if (status & SR_FRAME) + flag = TTY_FRAME; + } + + if (uart_handle_sysrq_char(port, ch)) + continue; + + if (status & port->ignore_status_mask) + continue; + + tty_insert_flip_char(tty, ch, flag); + } + return tty; +} + +static void transmit_chars(struct uart_port *port) +{ + struct circ_buf *xmit; + + if (!port->info) + return; + + xmit = &port->info->xmit; + if (uart_circ_empty(xmit) || uart_tx_stopped(port)) { + sc26xx_disable_irq(port, IMR_TXRDY); + return; + } + while (!uart_circ_empty(xmit)) { + if (!(READ_SC_PORT(port, SR) & SR_TXRDY)) + break; + + WRITE_SC_PORT(port, THR, xmit->buf[xmit->tail]); + xmit->tail = (xmit->tail + 1) & (UART_XMIT_SIZE - 1); + port->icount.tx++; + } + if (uart_circ_chars_pending(xmit) < WAKEUP_CHARS) + uart_write_wakeup(port); +} + +static irqreturn_t sc26xx_interrupt(int irq, void *dev_id) +{ + struct uart_sc26xx_port *up = dev_id; + struct tty_struct *tty; + unsigned long flags; + u8 isr; + + spin_lock_irqsave(&up->port[0].lock, flags); + + tty = NULL; + isr = READ_SC(&up->port[0], ISR); + if (isr & ISR_TXRDYA) + transmit_chars(&up->port[0]); + if (isr & ISR_RXRDYA) + tty = receive_chars(&up->port[0]); + + spin_unlock(&up->port[0].lock); + + if (tty) + tty_flip_buffer_push(tty); + + spin_lock(&up->port[1].lock); + + tty = NULL; + if (isr & ISR_TXRDYB) + transmit_chars(&up->port[1]); + if (isr & ISR_RXRDYB) + tty = receive_chars(&up->port[1]); + + spin_unlock_irqrestore(&up->port[1].lock, flags); + + if (tty) + tty_flip_buffer_push(tty); + + return IRQ_HANDLED; +} + +/* port->lock is not held. */ +static unsigned int sc26xx_tx_empty(struct uart_port *port) +{ + return (READ_SC_PORT(port, SR) & SR_TXRDY) ? TIOCSER_TEMT : 0; +} + +/* port->lock held by caller. */ +static void sc26xx_set_mctrl(struct uart_port *port, unsigned int mctrl) +{ + struct uart_sc26xx_port *up; + int line = port->line; + + port -= line; + up = container_of(port, struct uart_sc26xx_port, port[0]); + + if (up->dtr_mask[line]) { + if (mctrl & TIOCM_DTR) + WRITE_SC(port, OPR_SET, up->dtr_mask[line]); + else + WRITE_SC(port, OPR_CLR, up->dtr_mask[line]); + } + if (up->rts_mask[line]) { + if (mctrl & TIOCM_RTS) + WRITE_SC(port, OPR_SET, up->rts_mask[line]); + else + WRITE_SC(port, OPR_CLR, up->rts_mask[line]); + } +} + +/* port->lock is held by caller and interrupts are disabled. */ +static unsigned int sc26xx_get_mctrl(struct uart_port *port) +{ + struct uart_sc26xx_port *up; + int line = port->line; + unsigned int mctrl = TIOCM_DSR | TIOCM_CTS | TIOCM_CAR; + u8 ipr; + + port -= line; + up = container_of(port, struct uart_sc26xx_port, port[0]); + ipr = READ_SC(port, IPR) ^ 0xff; + + if (up->dsr_mask[line]) { + mctrl &= ~TIOCM_DSR; + mctrl |= ipr & up->dsr_mask[line] ? TIOCM_DSR : 0; + } + if (up->cts_mask[line]) { + mctrl &= ~TIOCM_CTS; + mctrl |= ipr & up->cts_mask[line] ? TIOCM_CTS : 0; + } + if (up->dcd_mask[line]) { + mctrl &= ~TIOCM_CAR; + mctrl |= ipr & up->dcd_mask[line] ? TIOCM_CAR : 0; + } + if (up->ri_mask[line]) { + mctrl &= ~TIOCM_RNG; + mctrl |= ipr & up->ri_mask[line] ? TIOCM_RNG : 0; + } + return mctrl; +} + +/* port->lock held by caller. */ +static void sc26xx_stop_tx(struct uart_port *port) +{ + return; +} + +/* port->lock held by caller. */ +static void sc26xx_start_tx(struct uart_port *port) +{ + struct circ_buf *xmit = &port->info->xmit; + + while (!uart_circ_empty(xmit)) { + if (!(READ_SC_PORT(port, SR) & SR_TXRDY)) { + sc26xx_enable_irq(port, IMR_TXRDY); + break; + } + WRITE_SC_PORT(port, THR, xmit->buf[xmit->tail]); + xmit->tail = (xmit->tail + 1) & (UART_XMIT_SIZE - 1); + port->icount.tx++; + } +} + +/* port->lock held by caller. */ +static void sc26xx_stop_rx(struct uart_port *port) +{ +} + +/* port->lock held by caller. */ +static void sc26xx_enable_ms(struct uart_port *port) +{ +} + +/* port->lock is not held. */ +static void sc26xx_break_ctl(struct uart_port *port, int break_state) +{ + if (break_state == -1) + WRITE_SC_PORT(port, CR, CR_STRT_BRK); + else + WRITE_SC_PORT(port, CR, CR_STOP_BRK); +} + +/* port->lock is not held. */ +static int sc26xx_startup(struct uart_port *port) +{ + sc26xx_disable_irq(port, IMR_TXRDY | IMR_RXRDY); + WRITE_SC(port, OPCR, 0); + + /* reset tx and rx */ + WRITE_SC_PORT(port, CR, CR_RES_RX); + WRITE_SC_PORT(port, CR, CR_RES_TX); + + /* start rx/tx */ + WRITE_SC_PORT(port, CR, CR_ENA_TX | CR_ENA_RX); + + /* enable irqs */ + sc26xx_enable_irq(port, IMR_RXRDY); + return 0; +} + +/* port->lock is not held. */ +static void sc26xx_shutdown(struct uart_port *port) +{ + /* disable interrupst */ + sc26xx_disable_irq(port, IMR_TXRDY | IMR_RXRDY); + + /* stop tx/rx */ + WRITE_SC_PORT(port, CR, CR_DIS_TX | CR_DIS_RX); +} + +/* port->lock is not held. */ +static void sc26xx_set_termios(struct uart_port *port, struct ktermios *termios, + struct ktermios *old) +{ + unsigned int baud = uart_get_baud_rate(port, termios, old, 0, 4000000); + unsigned int quot = uart_get_divisor(port, baud); + unsigned int iflag, cflag; + unsigned long flags; + u8 mr1, mr2, csr; + + spin_lock_irqsave(&port->lock, flags); + + while ((READ_SC_PORT(port, SR) & ((1 << 3) | (1 << 2))) != 0xc) + udelay(2); + + WRITE_SC_PORT(port, CR, CR_DIS_TX | CR_DIS_RX); + + iflag = termios->c_iflag; + cflag = termios->c_cflag; + + port->read_status_mask = SR_OVERRUN; + if (iflag & INPCK) + port->read_status_mask |= SR_PARITY | SR_FRAME; + if (iflag & (BRKINT | PARMRK)) + port->read_status_mask |= SR_BREAK; + + port->ignore_status_mask = 0; + if (iflag & IGNBRK) + port->ignore_status_mask |= SR_BREAK; + if ((cflag & CREAD) == 0) + port->ignore_status_mask |= SR_BREAK | SR_FRAME | + SR_PARITY | SR_OVERRUN; + + switch (cflag & CSIZE) { + case CS5: + mr1 = 0x00; + break; + case CS6: + mr1 = 0x01; + break; + case CS7: + mr1 = 0x02; + break; + default: + case CS8: + mr1 = 0x03; + break; + } + mr2 = 0x07; + if (cflag & CSTOPB) + mr2 = 0x0f; + if (cflag & PARENB) { + if (cflag & PARODD) + mr1 |= (1 << 2); + } else + mr1 |= (2 << 3); + + switch (baud) { + case 50: + csr = 0x00; + break; + case 110: + csr = 0x11; + break; + case 134: + csr = 0x22; + break; + case 200: + csr = 0x33; + break; + case 300: + csr = 0x44; + break; + case 600: + csr = 0x55; + break; + case 1200: + csr = 0x66; + break; + case 2400: + csr = 0x88; + break; + case 4800: + csr = 0x99; + break; + default: + case 9600: + csr = 0xbb; + break; + case 19200: + csr = 0xcc; + break; + } + + WRITE_SC_PORT(port, CR, CR_RES_MR); + WRITE_SC_PORT(port, MRx, mr1); + WRITE_SC_PORT(port, MRx, mr2); + + WRITE_SC(port, ACR, 0x80); + WRITE_SC_PORT(port, CSR, csr); + + /* reset tx and rx */ + WRITE_SC_PORT(port, CR, CR_RES_RX); + WRITE_SC_PORT(port, CR, CR_RES_TX); + + WRITE_SC_PORT(port, CR, CR_ENA_TX | CR_ENA_RX); + while ((READ_SC_PORT(port, SR) & ((1 << 3) | (1 << 2))) != 0xc) + udelay(2); + + /* XXX */ + uart_update_timeout(port, cflag, + (port->uartclk / (16 * quot))); + + spin_unlock_irqrestore(&port->lock, flags); +} + +static const char *sc26xx_type(struct uart_port *port) +{ + return "SC26XX"; +} + +static void sc26xx_release_port(struct uart_port *port) +{ +} + +static int sc26xx_request_port(struct uart_port *port) +{ + return 0; +} + +static void sc26xx_config_port(struct uart_port *port, int flags) +{ +} + +static int sc26xx_verify_port(struct uart_port *port, struct serial_struct *ser) +{ + return -EINVAL; +} + +static struct uart_ops sc26xx_ops = { + .tx_empty = sc26xx_tx_empty, + .set_mctrl = sc26xx_set_mctrl, + .get_mctrl = sc26xx_get_mctrl, + .stop_tx = sc26xx_stop_tx, + .start_tx = sc26xx_start_tx, + .stop_rx = sc26xx_stop_rx, + .enable_ms = sc26xx_enable_ms, + .break_ctl = sc26xx_break_ctl, + .startup = sc26xx_startup, + .shutdown = sc26xx_shutdown, + .set_termios = sc26xx_set_termios, + .type = sc26xx_type, + .release_port = sc26xx_release_port, + .request_port = sc26xx_request_port, + .config_port = sc26xx_config_port, + .verify_port = sc26xx_verify_port, +}; + +static struct uart_port *sc26xx_port; + +#ifdef CONFIG_SERIAL_SC26XX_CONSOLE +static void sc26xx_console_putchar(struct uart_port *port, char c) +{ + unsigned long flags; + int limit = 1000000; + + spin_lock_irqsave(&port->lock, flags); + + while (limit-- > 0) { + if (READ_SC_PORT(port, SR) & SR_TXRDY) { + WRITE_SC_PORT(port, THR, c); + break; + } + udelay(2); + } + + spin_unlock_irqrestore(&port->lock, flags); +} + +static void sc26xx_console_write(struct console *con, const char *s, unsigned n) +{ + struct uart_port *port = sc26xx_port; + int i; + + for (i = 0; i < n; i++) { + if (*s == '\n') + sc26xx_console_putchar(port, '\r'); + sc26xx_console_putchar(port, *s++); + } +} + +static int __init sc26xx_console_setup(struct console *con, char *options) +{ + struct uart_port *port = sc26xx_port; + int baud = 9600; + int bits = 8; + int parity = 'n'; + int flow = 'n'; + + if (port->type != PORT_SC26XX) + return -1; + + printk(KERN_INFO "Console: ttySC%d (SC26XX)\n", con->index); + if (options) + uart_parse_options(options, &baud, &parity, &bits, &flow); + + return uart_set_options(port, con, baud, parity, bits, flow); +} + +static struct uart_driver sc26xx_reg; +static struct console sc26xx_console = { + .name = "ttySC", + .write = sc26xx_console_write, + .device = uart_console_device, + .setup = sc26xx_console_setup, + .flags = CON_PRINTBUFFER, + .index = -1, + .data = &sc26xx_reg, +}; +#define SC26XX_CONSOLE &sc26xx_console +#else +#define SC26XX_CONSOLE NULL +#endif + +static struct uart_driver sc26xx_reg = { + .owner = THIS_MODULE, + .driver_name = "SC26xx", + .dev_name = "ttySC", + .major = SC26XX_MAJOR, + .minor = SC26XX_MINOR_START, + .nr = SC26XX_NR, + .cons = SC26XX_CONSOLE, +}; + +static u8 sc26xx_flags2mask(unsigned int flags, unsigned int bitpos) +{ + unsigned int bit = (flags >> bitpos) & 15; + + return bit ? (1 << (bit - 1)) : 0; +} + +static void __devinit sc26xx_init_masks(struct uart_sc26xx_port *up, + int line, unsigned int data) +{ + up->dtr_mask[line] = sc26xx_flags2mask(data, 0); + up->rts_mask[line] = sc26xx_flags2mask(data, 4); + up->dsr_mask[line] = sc26xx_flags2mask(data, 8); + up->cts_mask[line] = sc26xx_flags2mask(data, 12); + up->dcd_mask[line] = sc26xx_flags2mask(data, 16); + up->ri_mask[line] = sc26xx_flags2mask(data, 20); +} + +static int __devinit sc26xx_probe(struct platform_device *dev) +{ + struct resource *res; + struct uart_sc26xx_port *up; + unsigned int *sc26xx_data = dev->dev.platform_data; + int err; + + res = platform_get_resource(dev, IORESOURCE_MEM, 0); + if (!res) + return -ENODEV; + + up = kzalloc(sizeof *up, GFP_KERNEL); + if (unlikely(!up)) + return -ENOMEM; + + up->port[0].line = 0; + up->port[0].ops = &sc26xx_ops; + up->port[0].type = PORT_SC26XX; + up->port[0].uartclk = (29491200 / 16); /* arbitrary */ + + up->port[0].mapbase = res->start; + up->port[0].membase = ioremap_nocache(up->port[0].mapbase, 0x40); + up->port[0].iotype = UPIO_MEM; + up->port[0].irq = platform_get_irq(dev, 0); + + up->port[0].dev = &dev->dev; + + sc26xx_init_masks(up, 0, sc26xx_data[0]); + + sc26xx_port = &up->port[0]; + + up->port[1].line = 1; + up->port[1].ops = &sc26xx_ops; + up->port[1].type = PORT_SC26XX; + up->port[1].uartclk = (29491200 / 16); /* arbitrary */ + + up->port[1].mapbase = up->port[0].mapbase; + up->port[1].membase = up->port[0].membase; + up->port[1].iotype = UPIO_MEM; + up->port[1].irq = up->port[0].irq; + + up->port[1].dev = &dev->dev; + + sc26xx_init_masks(up, 1, sc26xx_data[1]); + + err = uart_register_driver(&sc26xx_reg); + if (err) + goto out_free_port; + + sc26xx_reg.tty_driver->name_base = sc26xx_reg.minor; + + err = uart_add_one_port(&sc26xx_reg, &up->port[0]); + if (err) + goto out_unregister_driver; + + err = uart_add_one_port(&sc26xx_reg, &up->port[1]); + if (err) + goto out_remove_port0; + + err = request_irq(up->port[0].irq, sc26xx_interrupt, 0, "sc26xx", up); + if (err) + goto out_remove_ports; + + dev_set_drvdata(&dev->dev, up); + return 0; + +out_remove_ports: + uart_remove_one_port(&sc26xx_reg, &up->port[1]); +out_remove_port0: + uart_remove_one_port(&sc26xx_reg, &up->port[0]); + +out_unregister_driver: + uart_unregister_driver(&sc26xx_reg); + +out_free_port: + kfree(up); + sc26xx_port = NULL; + return err; +} + + +static int __exit sc26xx_driver_remove(struct platform_device *dev) +{ + struct uart_sc26xx_port *up = dev_get_drvdata(&dev->dev); + + free_irq(up->port[0].irq, up); + + uart_remove_one_port(&sc26xx_reg, &up->port[0]); + uart_remove_one_port(&sc26xx_reg, &up->port[1]); + + uart_unregister_driver(&sc26xx_reg); + + kfree(up); + sc26xx_port = NULL; + + dev_set_drvdata(&dev->dev, NULL); + return 0; +} + +static struct platform_driver sc26xx_driver = { + .probe = sc26xx_probe, + .remove = __devexit_p(sc26xx_driver_remove), + .driver = { + .name = "SC26xx", + }, +}; + +static int __init sc26xx_init(void) +{ + return platform_driver_register(&sc26xx_driver); +} + +static void __exit sc26xx_exit(void) +{ + platform_driver_unregister(&sc26xx_driver); +} + +module_init(sc26xx_init); +module_exit(sc26xx_exit); + + +MODULE_AUTHOR("Thomas Bogendörfer"); +MODULE_DESCRIPTION("SC681/SC2692 serial driver"); +MODULE_VERSION("1.0"); +MODULE_LICENSE("GPL"); From tsbogend@alpha.franken.de Tue Dec 4 23:58:00 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 04 Dec 2007 23:58:09 +0000 (GMT) Received: from elvis.franken.de ([193.175.24.41]:477 "EHLO elvis.franken.de") by ftp.linux-mips.org with ESMTP id S20033479AbXLDX6A (ORCPT ); Tue, 4 Dec 2007 23:58:00 +0000 Received: from uucp (helo=solo.franken.de) by elvis.franken.de with local-bsmtp (Exim 3.36 #1) id 1IzheI-0004IG-01; Wed, 05 Dec 2007 00:57:58 +0100 Received: by solo.franken.de (Postfix, from userid 1000) id F0716DE4C4; Wed, 5 Dec 2007 00:57:56 +0100 (CET) Date: Wed, 5 Dec 2007 00:57:56 +0100 To: Alan Cox Cc: Arjan van de Ven , Andrew Morton , linux-kernel@vger.kernel.org, linux-mips@linux-mips.org, Andy Whitcroft Subject: Re: [PATCH] SC26XX: New serial driver for SC2681 uarts Message-ID: <20071204235756.GB17760@alpha.franken.de> References: <20071202194346.36E3FDE4C4@solo.franken.de> <20071203155317.772231f9.akpm@linux-foundation.org> <20071203155746.2dc4506d@laptopd505.fenrus.org> <20071204082534.GA5938@alpha.franken.de> <20071204124516.0120266a@the-village.bc.nu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20071204124516.0120266a@the-village.bc.nu> User-Agent: Mutt/1.5.13 (2006-08-11) From: tsbogend@alpha.franken.de (Thomas Bogendoerfer) Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 17693 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: tsbogend@alpha.franken.de Precedence: bulk X-list: linux-mips On Tue, Dec 04, 2007 at 12:45:16PM +0000, Alan Cox wrote: > > I tried to numbers several months ago and didn't get any response > > Please raise it with the relevant people. If our LANANA administrator is > not doing their job then the Linuxfoundation need to find a replacement, > or hand control of it over to someone outside. I just sent another request for registration. I'll keep you updated. Thomas. -- Crap can work. Given enough thrust pigs will fly, but it's not necessary a good idea. [ RFC1925, 2.3 ] From akpm@linux-foundation.org Wed Dec 5 03:27:59 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 05 Dec 2007 03:28:07 +0000 (GMT) Received: from smtp2.linux-foundation.org ([207.189.120.14]:22980 "EHLO smtp2.linux-foundation.org") by ftp.linux-mips.org with ESMTP id S20033745AbXLED17 (ORCPT ); Wed, 5 Dec 2007 03:27:59 +0000 Received: from imap1.linux-foundation.org (imap1.linux-foundation.org [207.189.120.55]) by smtp2.linux-foundation.org (8.13.5.20060308/8.13.5/Debian-3ubuntu1.1) with ESMTP id lB53Rd8I017240 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 4 Dec 2007 19:27:40 -0800 Received: from box (localhost [127.0.0.1]) by imap1.linux-foundation.org (8.13.5.20060308/8.13.5/Debian-3ubuntu1.1) with SMTP id lB53Rcuv018999; Tue, 4 Dec 2007 19:27:38 -0800 Date: Tue, 4 Dec 2007 19:27:38 -0800 From: Andrew Morton To: tsbogend@alpha.franken.de (Thomas Bogendoerfer) Cc: linux-kernel@vger.kernel.org, linux-mips@linux-mips.org, Andy Whitcroft , Alan Cox Subject: Re: [PATCH] SC26XX: New serial driver for SC2681 uarts Message-Id: <20071204192738.54e79a97.akpm@linux-foundation.org> In-Reply-To: <20071204234112.GA12352@alpha.franken.de> References: <20071202194346.36E3FDE4C4@solo.franken.de> <20071203155317.772231f9.akpm@linux-foundation.org> <20071204234112.GA12352@alpha.franken.de> X-Mailer: Sylpheed 2.4.1 (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: lf$Revision: 1.188 $ X-Scanned-By: MIMEDefang 2.53 on 207.189.120.14 Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 17694 X-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@linux-foundation.org Precedence: bulk X-list: linux-mips On Wed, 5 Dec 2007 00:41:12 +0100 tsbogend@alpha.franken.de (Thomas Bogendoerfer) wrote: > On Mon, Dec 03, 2007 at 03:53:17PM -0800, Andrew Morton wrote: > > On Sun, 2 Dec 2007 20:43:46 +0100 (CET) > > Thomas Bogendoerfer wrote: > > > > > New serial driver for SC2681/SC2691 uarts. Older SNI RM400 machines are > > > using these chips for onboard serial ports. > > > > > > > Little things... > > here is an updated version. > > Changes: > - use container_of > - remove not needed locking > - remove inlines > - fix macros with double argument reference > > Thomas. > -- > > New serial driver for SC2681/SC2691 uarts. Older SNI RM400 machines are > using these chips for onboard serial ports. > grumble. These: > +#define READ_SC(p, r) readb((p)->membase + RD_##r) > +#define WRITE_SC(p, r, v) writeb((v), (p)->membase + WR_##r) and these: > +#define READ_SC_PORT(p, r) read_sc_port(p, RD_PORT_##r) > +#define WRITE_SC_PORT(p, r, v) write_sc_port(p, WR_PORT_##r, v) really don't need to exist. All they do is make the code harder to read. Think of the poor reader who sees this: status = READ_SC_PORT(port, SR); and then goes madly searching for "SR". After a while, our confused reader might think to go look at the definition of READ_SC_PORT, after which our reader will emulate a C preprocessor in wetware and will eventually construct then hunt down RD_PORT_SR and will then hopefully remember what the heck he was trying to do in the first place. This sucks. Code is written once and is read a thousand times. Please optimise for reading. From kaz@zeugmasystems.com Wed Dec 5 03:50:49 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 05 Dec 2007 03:50:57 +0000 (GMT) Received: from mail.zeugmasystems.com ([70.79.96.174]:6708 "EHLO zeugmasystems.com") by ftp.linux-mips.org with ESMTP id S20032592AbXLEDut (ORCPT ); Wed, 5 Dec 2007 03:50:49 +0000 Received: from rocktron ([10.18.28.223]) by zeugmasystems.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 4 Dec 2007 19:50:42 -0800 Message-ID: <802BA59F5D0A495BAB9A037527BB76BB@rocktron> From: "Kaz Kylheku" To: References: <20071203181658.GA26631@onstor.com> <20071203230828.GA17960@linux-mips.org> In-Reply-To: <20071203230828.GA17960@linux-mips.org> Subject: Re: [PATCH] Add support for SB1 hardware watchdog. Date: Tue, 4 Dec 2007 19:41:08 -0800 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 Windows Mail 6.0.6000.16480 X-MimeOLE: Produced By Microsoft MimeOLE V6.0.6000.16545 X-OriginalArrivalTime: 05 Dec 2007 03:50:42.0559 (UTC) FILETIME=[021E60F0:01C836F2] Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 17695 X-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 On Mon, Dec 03, 2007, Ralf Baechle wrote: > On Mon, Dec 03, 2007 at 10:17:04AM -0800, Andrew Sharp wrote: > >> + Watchdog driver for the built in watchdog hardware in Sibyte >> + SoC processors. There are apparently two watchdog timers >> + on such processors; this driver supports only the first one, >> + because currently Linux only supports exporting one watchdog >> + to userspace. > > And even four watchdogs in the BCM1480. > > You'd think they'd trust their hardware more than that ;-) Maybe the dogs can be daisy-chained together. After all, who watches the watcher? And who watches him? Did I ever tell you how lucky you are? http://www.drseussart.com/beewatcher.html http://www.webpages.ttu.edu/sbaugues/fin4323/dr.seuss.pdf From kaz@zeugmasystems.com Wed Dec 5 03:51:17 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 05 Dec 2007 03:51:21 +0000 (GMT) Received: from mail.zeugmasystems.com ([70.79.96.174]:6708 "EHLO zeugmasystems.com") by ftp.linux-mips.org with ESMTP id S20033763AbXLEDuu (ORCPT ); Wed, 5 Dec 2007 03:50:50 +0000 Received: from rocktron ([10.18.28.223]) by zeugmasystems.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 4 Dec 2007 19:50:42 -0800 Message-ID: <34AF8F83DE89424F94243BB80944B175@rocktron> From: "Kaz Kylheku" To: References: <20071203181658.GA26631@onstor.com> <20071203230828.GA17960@linux-mips.org> In-Reply-To: <20071203230828.GA17960@linux-mips.org> Subject: Re: [PATCH] Add support for SB1 hardware watchdog. Date: Tue, 4 Dec 2007 19:50:42 -0800 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 Windows Mail 6.0.6000.16480 X-MimeOLE: Produced By Microsoft MimeOLE V6.0.6000.16545 X-OriginalArrivalTime: 05 Dec 2007 03:50:42.0950 (UTC) FILETIME=[025A0A60:01C836F2] Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 17696 X-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 On Mon, Dec 03, 2007, Ralf Baechle wrote: > On Mon, Dec 03, 2007 at 10:17:04AM -0800, Andrew Sharp wrote: > >> + Watchdog driver for the built in watchdog hardware in Sibyte >> + SoC processors. There are apparently two watchdog timers >> + on such processors; this driver supports only the first one, >> + because currently Linux only supports exporting one watchdog >> + to userspace. > > And even four watchdogs in the BCM1480. > > You'd think they'd trust their hardware more than that ;-) Maybe the dogs can be daisy-chained together. After all, who watches the watcher? And who watches him? Did I ever tell you how lucky you are? http://www.drseussart.com/beewatcher.html http://www.webpages.ttu.edu/sbaugues/fin4323/dr.seuss.pdf From kumba@gentoo.org Wed Dec 5 06:16:28 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 05 Dec 2007 06:16:36 +0000 (GMT) Received: from qmta07.emeryville.ca.mail.comcast.net ([76.96.30.64]:31155 "EHLO QMTA07.emeryville.ca.mail.comcast.net") by ftp.linux-mips.org with ESMTP id S20022337AbXLEGQ2 (ORCPT ); Wed, 5 Dec 2007 06:16:28 +0000 Received: from OMTA01.emeryville.ca.mail.comcast.net ([76.96.30.11]) by QMTA07.emeryville.ca.mail.comcast.net with comcast id LsFa1Y00B0EPcho0A09Z00; Wed, 05 Dec 2007 06:16:20 +0000 Received: from [192.168.1.4] ([69.140.18.238]) by OMTA01.emeryville.ca.mail.comcast.net with comcast id LuGJ1Y00258Be2l0800000; Wed, 05 Dec 2007 06:16:19 +0000 X-Authority-Analysis: v=1.0 c=1 a=iutXgmbQ7ULgJeHD0VAA:9 a=VsqEP6V0iwlQwqG2ykgORS65Xd8A:4 a=QJAqVYndk0IA:10 Message-ID: <4756422D.6070305@gentoo.org> Date: Wed, 05 Dec 2007 01:16:13 -0500 From: Kumba User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: Ralf Baechle CC: Thomas Bogendoerfer , linux-mips@linux-mips.org Subject: Re: [UPDATED PATCH] IP28 support References: <20071129095442.C6679C2B39@solo.franken.de> <20071129130130.GA14655@linux-mips.org> In-Reply-To: <20071129130130.GA14655@linux-mips.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 17697 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: kumba@gentoo.org Precedence: bulk X-list: linux-mips Ralf Baechle wrote: > On Thu, Nov 29, 2007 at 10:54:42AM +0100, Thomas Bogendoerfer wrote: > >> Add support for SGI IP28 machines (Indigo 2 with R10k CPUs) >> This work is mainly based on Peter Fuersts work. > > Queued for 2.6.25. There clearly is work remaining to be done but the > code is now in an acceptable shape and the best way to push it forward > is integrating it. Thanks for all the work and especially to Peter > Fürst for the initial heavyweight lifting! > > Ralf Seconded. Peter is made of Win. I've been out of it lately -- did the gcc side of things ever make it in, or do we need to go push on that some more? --Kumba -- Gentoo/MIPS Team Lead "Such is oft the course of deeds that move the wheels of the world: small hands do them because they must, while the eyes of the great are elsewhere." --Elrond From tsbogend@alpha.franken.de Wed Dec 5 09:31:57 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 05 Dec 2007 09:32:05 +0000 (GMT) Received: from elvis.franken.de ([193.175.24.41]:65175 "EHLO elvis.franken.de") by ftp.linux-mips.org with ESMTP id S20022638AbXLEJb5 (ORCPT ); Wed, 5 Dec 2007 09:31:57 +0000 Received: from uucp (helo=solo.franken.de) by elvis.franken.de with local-bsmtp (Exim 3.36 #1) id 1Izqbh-0004k7-00; Wed, 05 Dec 2007 10:31:53 +0100 Received: by solo.franken.de (Postfix, from userid 1000) id 65573C2EB0; Wed, 5 Dec 2007 10:25:06 +0100 (CET) Date: Wed, 5 Dec 2007 10:25:06 +0100 To: Andrew Morton Cc: linux-kernel@vger.kernel.org, linux-mips@linux-mips.org, Andy Whitcroft , Alan Cox Subject: Re: [PATCH] SC26XX: New serial driver for SC2681 uarts Message-ID: <20071205092506.GA6691@alpha.franken.de> References: <20071202194346.36E3FDE4C4@solo.franken.de> <20071203155317.772231f9.akpm@linux-foundation.org> <20071204234112.GA12352@alpha.franken.de> <20071204192738.54e79a97.akpm@linux-foundation.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20071204192738.54e79a97.akpm@linux-foundation.org> User-Agent: Mutt/1.5.13 (2006-08-11) From: tsbogend@alpha.franken.de (Thomas Bogendoerfer) Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 17698 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: tsbogend@alpha.franken.de Precedence: bulk X-list: linux-mips On Tue, Dec 04, 2007 at 07:27:38PM -0800, Andrew Morton wrote: > grumble. > > These: > > > +#define READ_SC(p, r) readb((p)->membase + RD_##r) > > +#define WRITE_SC(p, r, v) writeb((v), (p)->membase + WR_##r) > > and these: > > > +#define READ_SC_PORT(p, r) read_sc_port(p, RD_PORT_##r) > > +#define WRITE_SC_PORT(p, r, v) write_sc_port(p, WR_PORT_##r, v) > > really don't need to exist. All they do is make the code harder to read. but they make the code safer. The chip has common register and port registers, which are randomly splattered over the address range. And some of them are read only, some write only. Read only and Write only register live at the same register offset and their function usually doesn't have anything in common. By using these macros I'll get compile errors when doing a READ_SC from a write only register and vice versa. I will also get compile errors, if I try to access a common register via READ_SC_PORT/WRITE_SC_PORT. If there is a better way to get more readable code for you and the safety I'd like, just tell me. > Think of the poor reader who sees this: > > status = READ_SC_PORT(port, SR); > > and then goes madly searching for "SR". which he then finds by this name in the data sheet. All the register names are named as close to the datasheet as possible. And I consider consulting datasheets when looking at drivers a pretty good idea. > Code is written once and is read a thousand times. Please optimise for > reading. it's no big deal to change that, but is getting bitten by stupid chips worth it ? I'd prefer to get a compile error than debugging a runtime error. Thomas. -- Crap can work. Given enough thrust pigs will fly, but it's not necessary a good idea. [ RFC1925, 2.3 ] From tsbogend@alpha.franken.de Wed Dec 5 09:42:59 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 05 Dec 2007 09:43:08 +0000 (GMT) Received: from elvis.franken.de ([193.175.24.41]:43672 "EHLO elvis.franken.de") by ftp.linux-mips.org with ESMTP id S20022728AbXLEJm7 (ORCPT ); Wed, 5 Dec 2007 09:42:59 +0000 Received: from uucp (helo=solo.franken.de) by elvis.franken.de with local-bsmtp (Exim 3.36 #1) id 1IzqjN-0006Gx-00; Wed, 05 Dec 2007 10:39:49 +0100 Received: by solo.franken.de (Postfix, from userid 1000) id 7EEC9C2EB1; Wed, 5 Dec 2007 10:39:38 +0100 (CET) Date: Wed, 5 Dec 2007 10:39:38 +0100 To: Kumba Cc: Ralf Baechle , linux-mips@linux-mips.org Subject: Re: [UPDATED PATCH] IP28 support Message-ID: <20071205093938.GA6848@alpha.franken.de> References: <20071129095442.C6679C2B39@solo.franken.de> <20071129130130.GA14655@linux-mips.org> <4756422D.6070305@gentoo.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4756422D.6070305@gentoo.org> User-Agent: Mutt/1.5.13 (2006-08-11) From: tsbogend@alpha.franken.de (Thomas Bogendoerfer) Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 17699 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: tsbogend@alpha.franken.de Precedence: bulk X-list: linux-mips On Wed, Dec 05, 2007 at 01:16:13AM -0500, Kumba wrote: > I've been out of it lately -- did the gcc side of things ever make it in, > or do we need to go push on that some more? We need push on that. Looking at http://gcc.gnu.org/ml/gcc-patches/2006-04/msg00291.html there seems to be a missing understanding, why the cache barriers are needed. I guess the patch could be improved by pointing directly to the errata section of the R10k user manual. Or even better copy the text out of the user manual. That should make clear why this patch is needed. Peter did you do the copyright assigment ? That's probably the second part, which needs to be done. Thomas. -- Crap can work. Given enough thrust pigs will fly, but it's not necessary a good idea. [ RFC1925, 2.3 ] From sshtylyov@ru.mvista.com Wed Dec 5 16:08:01 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 05 Dec 2007 16:08:11 +0000 (GMT) Received: from rtsoft3.corbina.net ([85.21.88.6]:6428 "EHLO buildserver.ru.mvista.com") by ftp.linux-mips.org with ESMTP id S20025455AbXLEQIB (ORCPT ); Wed, 5 Dec 2007 16:08:01 +0000 Received: from wasted.dev.rtsoft.ru (unknown [10.150.0.9]) by buildserver.ru.mvista.com (Postfix) with ESMTP id D383F8816; Wed, 5 Dec 2007 21:07:59 +0400 (SAMT) From: Sergei Shtylyov Organization: MontaVista Software Inc. To: ralf@linux-mips.org Subject: [PATCH 0/2] Alchemy: fix interrupt routing Date: Wed, 5 Dec 2007 19:08:18 +0300 User-Agent: KMail/1.5 Cc: linux-mips@linux-mips.org MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Message-Id: <200712051908.18780.sshtylyov@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: 17700 X-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. The two following patches together fix the interrupt routing currently broken and causing boot failure with such messages: unexpected IRQ # 8 irq 8, desc: 80406dd0, depth: 1, count: 0, unhandled: 0 ->handle_irq(): 80157d70, handle_bad_irq+0x0/0x38c ->chip(): 804016d0, 0x804016d0 ->action(): 00000000 IRQ_DISABLED set The patches are against the Linus' tree... WBR, Sergei From sshtylyov@ru.mvista.com Wed Dec 5 16:08:31 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 05 Dec 2007 16:08:40 +0000 (GMT) Received: from rtsoft3.corbina.net ([85.21.88.6]:6684 "EHLO buildserver.ru.mvista.com") by ftp.linux-mips.org with ESMTP id S20025677AbXLEQIF (ORCPT ); Wed, 5 Dec 2007 16:08:05 +0000 Received: from wasted.dev.rtsoft.ru (unknown [10.150.0.9]) by buildserver.ru.mvista.com (Postfix) with ESMTP id CCCDB8816; Wed, 5 Dec 2007 21:08:04 +0400 (SAMT) From: Sergei Shtylyov Organization: MontaVista Software Inc. To: ralf@linux-mips.org Subject: [PATCH 1/2] Alchemy: replace ffs() with __ffs() Date: Wed, 5 Dec 2007 19:08:24 +0300 User-Agent: KMail/1.5 Cc: linux-mips@linux-mips.org MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Message-Id: <200712051908.24027.sshtylyov@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: 17701 X-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 Fix havoc wrought by commit 56f621c7f6f735311eed3f36858b402013023c18 -- au_ffs() and ffs() are equivalent, that patch should have just replaced one with another. Now replace ffs() with __ffs() which returns an unbiased bit number. arch/mips/au1000/common/dbdma.c | 2 +- arch/mips/au1000/common/irq.c | 8 ++++---- arch/mips/au1000/pb1200/irqmap.c | 2 +- 3 files changed, 6 insertions(+), 6 deletions(-) Index: linux-2.6/arch/mips/au1000/common/dbdma.c =================================================================== --- linux-2.6.orig/arch/mips/au1000/common/dbdma.c +++ linux-2.6/arch/mips/au1000/common/dbdma.c @@ -859,7 +859,7 @@ dbdma_interrupt(int irq, void *dev_id) intstat = dbdma_gptr->ddma_intstat; au_sync(); - chan_index = ffs(intstat); + chan_index = __ffs(intstat); ctp = chan_tab_ptr[chan_index]; cp = ctp->chan_ptr; Index: linux-2.6/arch/mips/au1000/common/irq.c =================================================================== --- linux-2.6.orig/arch/mips/au1000/common/irq.c +++ linux-2.6/arch/mips/au1000/common/irq.c @@ -462,7 +462,7 @@ static void intc0_req0_irqdispatch(void) return; } #endif - bit = ffs(intc0_req0); + bit = __ffs(intc0_req0); intc0_req0 &= ~(1 << bit); do_IRQ(MIPS_CPU_IRQ_BASE + bit); } @@ -478,7 +478,7 @@ static void intc0_req1_irqdispatch(void) if (!intc0_req1) return; - bit = ffs(intc0_req1); + bit = __ffs(intc0_req1); intc0_req1 &= ~(1 << bit); do_IRQ(bit); } @@ -498,7 +498,7 @@ static void intc1_req0_irqdispatch(void) if (!intc1_req0) return; - bit = ffs(intc1_req0); + bit = __ffs(intc1_req0); intc1_req0 &= ~(1 << bit); do_IRQ(MIPS_CPU_IRQ_BASE + 32 + bit); } @@ -514,7 +514,7 @@ static void intc1_req1_irqdispatch(void) if (!intc1_req1) return; - bit = ffs(intc1_req1); + bit = __ffs(intc1_req1); intc1_req1 &= ~(1 << bit); do_IRQ(MIPS_CPU_IRQ_BASE + 32 + bit); } Index: linux-2.6/arch/mips/au1000/pb1200/irqmap.c =================================================================== --- linux-2.6.orig/arch/mips/au1000/pb1200/irqmap.c +++ linux-2.6/arch/mips/au1000/pb1200/irqmap.c @@ -74,7 +74,7 @@ irqreturn_t pb1200_cascade_handler( int bcsr->int_status = bisr; for( ; bisr; bisr &= (bisr-1) ) { - extirq_nr = PB1200_INT_BEGIN + ffs(bisr); + extirq_nr = PB1200_INT_BEGIN + __ffs(bisr); /* Ack and dispatch IRQ */ do_IRQ(extirq_nr); } From sshtylyov@ru.mvista.com Wed Dec 5 16:09:01 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 05 Dec 2007 16:09:04 +0000 (GMT) Received: from rtsoft3.corbina.net ([85.21.88.6]:7196 "EHLO buildserver.ru.mvista.com") by ftp.linux-mips.org with ESMTP id S20025684AbXLEQIi (ORCPT ); Wed, 5 Dec 2007 16:08:38 +0000 Received: from wasted.dev.rtsoft.ru (unknown [10.150.0.9]) by buildserver.ru.mvista.com (Postfix) with ESMTP id 7AA968816; Wed, 5 Dec 2007 21:08:07 +0400 (SAMT) From: Sergei Shtylyov Organization: MontaVista Software Inc. To: ralf@linux-mips.org Subject: [PATCH 2/2] Alchemy: fix IRQ bases Date: Wed, 5 Dec 2007 19:08:26 +0300 User-Agent: KMail/1.5 Cc: linux-mips@linux-mips.org MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Message-Id: <200712051908.26703.sshtylyov@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: 17702 X-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 Do what the commits commits f3e8d1da389fe2e514e31f6e93c690c8e1243849 and 9d360ab4a7568a8d177280f651a8a772ae52b9b9 failed to achieve -- actually convert the Alchemy code to irq_cpu. arch/mips/au1000/common/irq.c | 8 ++++---- include/asm-mips/mach-au1x00/au1000.h | 21 +++++++++++---------- 2 files changed, 15 insertions(+), 14 deletions(-) Index: linux-2.6/arch/mips/au1000/common/irq.c =================================================================== --- linux-2.6.orig/arch/mips/au1000/common/irq.c +++ linux-2.6/arch/mips/au1000/common/irq.c @@ -464,7 +464,7 @@ static void intc0_req0_irqdispatch(void) #endif bit = __ffs(intc0_req0); intc0_req0 &= ~(1 << bit); - do_IRQ(MIPS_CPU_IRQ_BASE + bit); + do_IRQ(AU1000_INTC0_INT_BASE + bit); } @@ -480,7 +480,7 @@ static void intc0_req1_irqdispatch(void) bit = __ffs(intc0_req1); intc0_req1 &= ~(1 << bit); - do_IRQ(bit); + do_IRQ(AU1000_INTC0_INT_BASE + bit); } @@ -500,7 +500,7 @@ static void intc1_req0_irqdispatch(void) bit = __ffs(intc1_req0); intc1_req0 &= ~(1 << bit); - do_IRQ(MIPS_CPU_IRQ_BASE + 32 + bit); + do_IRQ(AU1000_INTC1_INT_BASE + bit); } @@ -516,7 +516,7 @@ static void intc1_req1_irqdispatch(void) bit = __ffs(intc1_req1); intc1_req1 &= ~(1 << bit); - do_IRQ(MIPS_CPU_IRQ_BASE + 32 + bit); + do_IRQ(AU1000_INTC1_INT_BASE + bit); } asmlinkage void plat_irq_dispatch(void) Index: linux-2.6/include/asm-mips/mach-au1x00/au1000.h =================================================================== --- linux-2.6.orig/include/asm-mips/mach-au1x00/au1000.h +++ linux-2.6/include/asm-mips/mach-au1x00/au1000.h @@ -526,7 +526,7 @@ extern struct au1xxx_irqmap au1xxx_irq_m /* Au1000 */ #ifdef CONFIG_SOC_AU1000 enum soc_au1000_ints { - AU1000_FIRST_INT = MIPS_CPU_IRQ_BASE, + AU1000_FIRST_INT = MIPS_CPU_IRQ_BASE + 8, AU1000_UART0_INT = AU1000_FIRST_INT, AU1000_UART1_INT, /* au1000 */ AU1000_UART2_INT, /* au1000 */ @@ -605,7 +605,7 @@ enum soc_au1000_ints { /* Au1500 */ #ifdef CONFIG_SOC_AU1500 enum soc_au1500_ints { - AU1500_FIRST_INT = MIPS_CPU_IRQ_BASE, + AU1500_FIRST_INT = MIPS_CPU_IRQ_BASE + 8, AU1500_UART0_INT = AU1500_FIRST_INT, AU1000_PCI_INTA, /* au1500 */ AU1000_PCI_INTB, /* au1500 */ @@ -686,7 +686,7 @@ enum soc_au1500_ints { /* Au1100 */ #ifdef CONFIG_SOC_AU1100 enum soc_au1100_ints { - AU1100_FIRST_INT = MIPS_CPU_IRQ_BASE, + AU1100_FIRST_INT = MIPS_CPU_IRQ_BASE + 8, AU1100_UART0_INT, AU1100_UART1_INT, AU1100_SD_INT, @@ -761,7 +761,7 @@ enum soc_au1100_ints { #ifdef CONFIG_SOC_AU1550 enum soc_au1550_ints { - AU1550_FIRST_INT = MIPS_CPU_IRQ_BASE, + AU1550_FIRST_INT = MIPS_CPU_IRQ_BASE + 8, AU1550_UART0_INT = AU1550_FIRST_INT, AU1550_PCI_INTA, AU1550_PCI_INTB, @@ -851,7 +851,7 @@ enum soc_au1550_ints { #ifdef CONFIG_SOC_AU1200 enum soc_au1200_ints { - AU1200_FIRST_INT = MIPS_CPU_IRQ_BASE, + AU1200_FIRST_INT = MIPS_CPU_IRQ_BASE + 8, AU1200_UART0_INT = AU1200_FIRST_INT, AU1200_SWT_INT, AU1200_SD_INT, @@ -948,11 +948,12 @@ enum soc_au1200_ints { #endif /* CONFIG_SOC_AU1200 */ -#define AU1000_INTC0_INT_BASE (MIPS_CPU_IRQ_BASE + 0) -#define AU1000_INTC0_INT_LAST (MIPS_CPU_IRQ_BASE + 31) -#define AU1000_INTC1_INT_BASE (MIPS_CPU_IRQ_BASE + 32) -#define AU1000_INTC1_INT_LAST (MIPS_CPU_IRQ_BASE + 63) -#define AU1000_MAX_INTR (MIPS_CPU_IRQ_BASE + 63) +#define AU1000_INTC0_INT_BASE (MIPS_CPU_IRQ_BASE + 8) +#define AU1000_INTC0_INT_LAST (AU1000_INTC0_INT_BASE + 31) +#define AU1000_INTC1_INT_BASE (AU1000_INTC0_INT_BASE + 32) +#define AU1000_INTC1_INT_LAST (AU1000_INTC1_INT_BASE + 31) + +#define AU1000_MAX_INTR AU1000_INTC1_INT_LAST #define INTX 0xFF /* not valid */ /* Programmable Counters 0 and 1 */ From hse00027@fh-hagenberg.at Wed Dec 5 16:40:34 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 05 Dec 2007 16:40:44 +0000 (GMT) Received: from postman.fh-hagenberg.at ([193.170.124.96]:6409 "EHLO mail.fh-hagenberg.at") by ftp.linux-mips.org with ESMTP id S20025883AbXLEQke (ORCPT ); Wed, 5 Dec 2007 16:40:34 +0000 Received: from [192.168.1.164] ([84.150.240.17]) by mail.fh-hagenberg.at over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Wed, 5 Dec 2007 17:40:52 +0100 Message-ID: <4756D42E.9040609@fh-hagenberg.at> Date: Wed, 05 Dec 2007 17:39:10 +0100 From: Manuel Lauss User-Agent: Thunderbird/1.0 Mnenhy/0.7 MIME-Version: 1.0 To: Sergei Shtylyov CC: ralf@linux-mips.org, linux-mips@linux-mips.org Subject: Re: [PATCH 0/2] Alchemy: fix interrupt routing References: <200712051908.18780.sshtylyov@ru.mvista.com> In-Reply-To: <200712051908.18780.sshtylyov@ru.mvista.com> X-Face: ?%%W`v1k(]AEyz!>:Wx5B3%Q{:HAn7x3R7EpLwqQWHc2>e&B2[\87@^|&dnyPvU,Gvzzxg.-(oGbT?5:{e!;wuTp2T,mKccN-6N(MdgITqZUM?``s0vhYdFzpIvC:rShQMj;!?uPt/A@;p.SR[q@.&La)e,a|z@U.[ZAtdBK8pVN|?V,F7yXUoaXsna[0nauK{'i|.eTRjYb@E9%}g+HB"\1XeU6K*o+KObFtnB[\_N&w5O#i#*q/]%D6ib)7Ld<1[xQQr0Ya"g!+vxBIh(W@G>qiblEcRLXR9( Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 05 Dec 2007 16:40:52.0635 (UTC) FILETIME=[997866B0:01C8375D] Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 17703 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: manuel.lauss@fh-hagenberg.at Precedence: bulk X-list: linux-mips Sergei, Sergei Shtylyov schrieb: > Hello. > > The two following patches together fix the interrupt routing currently broken > and causing boot failure with such messages: > > unexpected IRQ # 8 > irq 8, desc: 80406dd0, depth: 1, count: 0, unhandled: 0 > ->handle_irq(): 80157d70, handle_bad_irq+0x0/0x38c > ->chip(): 804016d0, 0x804016d0 > ->action(): 00000000 > IRQ_DISABLED set > > The patches are against the Linus' tree... > > WBR, Sergei Thanks a billion! Finally I can boot linux-2.6.24-rc on my Au1200 again! -- Manuel Lauss HSSE / FH Hagenberg From ralf@linux-mips.org Wed Dec 5 18:07:39 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 05 Dec 2007 18:07:41 +0000 (GMT) Received: from localhost.localdomain ([127.0.0.1]:910 "EHLO dl5rb.ham-radio-op.net") by ftp.linux-mips.org with ESMTP id S20030702AbXLESHj (ORCPT ); Wed, 5 Dec 2007 18:07:39 +0000 Received: from denk.linux-mips.net (denk.linux-mips.net [127.0.0.1]) by dl5rb.ham-radio-op.net (8.14.1/8.13.8) with ESMTP id lB5I6EHq010705; Wed, 5 Dec 2007 18:06:39 GMT Received: (from ralf@localhost) by denk.linux-mips.net (8.14.1/8.14.1/Submit) id lB5I6Dkp010704; Wed, 5 Dec 2007 18:06:13 GMT Date: Wed, 5 Dec 2007 18:06:13 +0000 From: Ralf Baechle To: Sergei Shtylyov Cc: linux-mips@linux-mips.org Subject: Re: [PATCH 1/2] Alchemy: replace ffs() with __ffs() Message-ID: <20071205180613.GA10697@linux-mips.org> References: <200712051908.24027.sshtylyov@ru.mvista.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200712051908.24027.sshtylyov@ru.mvista.com> User-Agent: Mutt/1.5.17 (2007-11-01) Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 17704 X-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 05, 2007 at 07:08:24PM +0300, Sergei Shtylyov wrote: > Fix havoc wrought by commit 56f621c7f6f735311eed3f36858b402013023c18 -- > au_ffs() and ffs() are equivalent, that patch should have just replaced > one with another. Now replace ffs() with __ffs() which returns an > unbiased bit number. Thanks, applied. Ralf From nathan_eggan@live.com Wed Dec 5 18:20:21 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 05 Dec 2007 18:20:31 +0000 (GMT) Received: from bay0-omc3-s37.bay0.hotmail.com ([65.54.246.237]:18670 "EHLO bay0-omc3-s37.bay0.hotmail.com") by ftp.linux-mips.org with ESMTP id S20030698AbXLESUV convert rfc822-to-8bit (ORCPT ); Wed, 5 Dec 2007 18:20:21 +0000 Received: from BAY125-W45 ([65.55.130.80]) by bay0-omc3-s37.bay0.hotmail.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 5 Dec 2007 10:20:14 -0800 Message-ID: X-Originating-IP: [157.185.36.161] From: Nathan Eggan To: Subject: Bug in Au1x00 UART or USB drivers for 2.6 kernels? Date: Wed, 5 Dec 2007 18:20:14 +0000 Importance: Normal Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 8BIT MIME-Version: 1.0 X-OriginalArrivalTime: 05 Dec 2007 18:20:14.0229 (UTC) FILETIME=[7ADB7450:01C8376B] Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 17705 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: nathan_eggan@live.com Precedence: bulk X-list: linux-mips All, After some thorough testing and exploration, I believe I have uncovered a bug in the Au1x00 driver code of either the UART or the USB host in the Linux 2.6 kernels. In short, this bug causes corruption of the data being returned from the UART whenever both it and the USB are in use. The issue I’m seeing is pretty simple to describe. When I have a data stream running over a UART, and I introduce traffic on the USB, the data returning from my UART is corrupted. (I will describe what the corruption looks like shortly.) Even simple events such as hotplugging a device can and will create the corruption in the UART’s serial stream. As expected, the amount of corruption seems dependent upon the amount of traffic on the USB. I discovered this issue while working with a DBAu1500 running a buildroot package that contains a Linux 2.6.21 kernel (patched for the MIPS from the linux-mips.org site) and Busybox 1.7.3. To keep YAMON from bombing during builds, I’m still using a trusty gcc 3.4.5 compiler to build it all. To determine if the issue was particular to just that board or that kernel source, I ran the same tests on two other DBAu1500s I have lying around here. I tested two 2.6 kernels (a 2.6.17 and the 2.6.21) and one 2.4 kernel I used several years ago. Both 2.6 kernels displayed the same issue. The 2.4.26 kernel, on the other hand, worked flawlessly. This does not really surprise me, as I’m presently tempted to believe that the issue somehow has to do with the interplay between the USB and the Au1x00 UART support that is now integrated into the standard 8250 driver. To really monitor the byte sequences returning, I wrote a simple, multi-threaded test app designed to test the loopback of the UART. It works by generating a 4k packet containing a repeating alphabet sequence [ABCDEF…XYZAB…], sending it over the UART, and then reading it back again. (The loopback is achieved by tying the TX and RX leads of the UART together.) On the receive side, the receive buffer is initialized with (0x20) characters, so I know whether bytes were skipped or misread. Once an entire 4k packet has been sent and received, the TX and RX threads exit and the main application compares their results byte-for-byte. Any discrepancies are reported, and then the process repeats. (To aid in testing, I’ve included the code from this test app, as well as instructions for its use, at the conclusion of this email.) Now, the corruption I’m seeing looks like this: (All of this data was taken by running my test code on ttyS1(tts/1) and simply plugging and unplugging a USB 802.11 wireless device and connecting it to a WAP.) <<<<<<<<<<< start: code output>>>>>>>>>>>>> Iteration: 197...done, cross-checking...done, MATCHED! - RX ERROR: '' found in read return. Byte 81 of the 113 bytes read does not fit between 'A' & 'Z'! done, cross-checking... Index: TX: RX: 3568 'G'[47] ''[00] 3569 'H'[48] 'G'[47] 3570 'I'[49] 'H'[48] 3571 'J'[4a] 'I'[49] 3572 'K'[4b] 'J'[4a] 3573 'L'[4c] 'K'[4b] 3574 'M'[4d] 'L'[4c] 3575 'N'[4e] 'M'[4d] 3576 'O'[4f] 'N'[4e] 3577 'P'[50] 'O'[4f] 3578 'Q'[51] 'P'[50] 3579 'R'[52] 'Q'[51] 3580 'S'[53] 'R'[52] 3581 'T'[54] 'S'[53] 3582 'U'[55] 'T'[54] 3583 'V'[56] 'U'[55] *** 16 Errors detected @ iteration 197! *** Iteration: 200...done, cross-checking...done, MATCHED! - RX ERROR: '' found in read return. Byte 57 of the 105 bytes read does not fit between 'A' & 'Z'! done, cross-checking... Index: TX: RX: 2176 'S'[53] ''[00] 2177 'T'[54] 'S'[53] 2178 'U'[55] 'T'[54] 2179 'V'[56] 'U'[55] 2180 'W'[57] 'V'[56] 2181 'X'[58] 'W'[57] 2182 'Y'[59] 'X'[58] 2183 'Z'[5a] 'Y'[59] 2184 'A'[41] 'Z'[5a] 2185 'B'[42] 'A'[41] 2186 'C'[43] 'B'[42] 2187 'D'[44] 'C'[43] 2188 'E'[45] 'D'[44] 2189 'F'[46] 'E'[45] 2190 'G'[47] 'F'[46] 2191 'H'[48] 'G'[47] *** 16 Errors detected @ iteration 200! *** Iteration: 203...done, cross-checking...done, MATCHED! - RX ERROR: '' found in read return. Byte 81 of the 129 bytes read does not fit between 'A' & 'Z'! - RX ERROR: '' found in read return. Byte 113 of the 129 bytes read does not fit between 'A' & 'Z'! done, cross-checking... Index: TX: RX: 0832 'A'[41] ''[00] 0833 'B'[42] 'A'[41] 0834 'C'[43] 'B'[42] 0835 'D'[44] 'C'[43] 0836 'E'[45] 'D'[44] 0837 'F'[46] 'E'[45] 0838 'G'[47] 'F'[46] 0839 'H'[48] 'G'[47] 0840 'I'[49] 'H'[48] 0841 'J'[4a] 'I'[49] 0842 'K'[4b] 'J'[4a] 0843 'L'[4c] 'K'[4b] 0844 'M'[4d] 'L'[4c] 0845 'N'[4e] 'M'[4d] 0846 'O'[4f] 'N'[4e] 0847 'P'[50] 'O'[4f] 0864 'G'[47] ''[00] 0865 'H'[48] 'G'[47] 0866 'I'[49] 'H'[48] 0867 'J'[4a] 'I'[49] 0868 'K'[4b] 'J'[4a] 0869 'L'[4c] 'K'[4b] 0870 'M'[4d] 'L'[4c] 0871 'N'[4e] 'M'[4d] 0872 'O'[4f] 'N'[4e] 0873 'P'[50] 'O'[4f] 0874 'Q'[51] 'P'[50] 0875 'R'[52] 'Q'[51] 0876 'S'[53] 'R'[52] 0877 'T'[54] 'S'[53] 0878 'U'[55] 'T'[54] 0879 'V'[56] 'U'[55] *** 32 Errors detected @ iteration 203! *** Iteration: 204... <<<<<<<<<<< end: code output>>>>>>>>>>>>> As you can see, when the error occurs it effects an entire 16-byte block, and only that 16-byte block. If you look at the byte index numbers above, you will notice that the stream always resyncs after taking a hit. So, the error is not just a dropped or inserted byte. If either of those events occurred, I would expect the entire subsequent serial stream to be off by the number of characters dropped or added. That does not seem to be happening here. Moreover, as you can see, there is a definite pattern to the corruption within the block. It is not random. In a corrupted block, the first byte is cleared to “0” (a value my test code is not permitted to use.) All subsequent bytes are then shifted 1 location to the right with the last byte being lost. This is where my current work has brought me. I am beginning to dive into the kernel source to see if I can track down the issue, but before doing so I figured I would pass this around to the gurus here to see what you thought. By providing a solid description of the issue, as well as instructions for easily reproducing it, I’m hopeful that a resolution to it can be found soon. Thanks for your help! Nathan Eggan PS - Here is the test code I’ve been using. Please review it, and feel free to comment on it. To compile it, I’ve been issuing “mipsel-linux-g++ -static –lpthread”. (I ran -static against it to make it library independent when I was switching between 2.4 and 2.6 kernels.) Test Code: <<<<<<<<<<< start: test code>>>>>>>>>>>>> // standard includes #include #include #include #include #include #include #include #include #include #include #include #include // custom includes ///////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////// enum PARITY_TYPE { NO_PARITY, PARITY }; /****************************************************************************** * * Name: OpenSerialPort * * Purpose: This function opens a standard serial port * *****************************************************************************/ int OpenSerialPort ( char *dev_name, int baud_rate, int num_bytes, PARITY_TYPE parity ) { struct termios options; int ret_val = 0, fd = -1; // open the proper port char full_dev_name[256]; ret_val = sprintf(full_dev_name, "/dev/%s", dev_name); if ( (ret_val <= 0) || (full_dev_name == NULL) ) { printf("OpenSerialPort(): Failed to open serial port: '%s': errno = '%s'\n", full_dev_name, strerror(errno)); // will return fd = -1 } else { fd = open(full_dev_name, O_RDWR | O_NOCTTY| O_NDELAY); // error checking if (fd < 0) { printf ("OpenSerialPort(): Failed to open serial port: '%s': errno = '%s'\n", full_dev_name, strerror(errno)); } else // success, now configure the port { // set the port to block on read fcntl(fd, F_SETFL, 0); // get the port's current attribute set tcgetattr(fd, &options); // set up the baud rate - lock at 115200 for now int desired_baud_rate = 0; switch (baud_rate) { // put the most likely first case 57600: desired_baud_rate = B57600; break; case 115200: desired_baud_rate = B115200; break; case 230400: desired_baud_rate = B230400; break; #if !defined(HOST) case 460800: desired_baud_rate = B460800; break; case 500000: desired_baud_rate = B500000; break; case 576000: desired_baud_rate = B576000; break; case 921600: desired_baud_rate = B921600; break; case 1000000: desired_baud_rate = B1000000; break; case 1152000: desired_baud_rate = B1152000; break; case 1500000: desired_baud_rate = B1500000; break; case 2000000: desired_baud_rate = B2000000; break; case 2500000: desired_baud_rate = B2500000; break; case 3000000: desired_baud_rate = B3000000; break; case 3500000: desired_baud_rate = B3500000; break; case 4000000: desired_baud_rate = B4000000; break; #endif case 50: desired_baud_rate = B50; break; case 75: desired_baud_rate = B75; break; case 110: desired_baud_rate = B110; break; case 134: desired_baud_rate = B134; break; case 150: desired_baud_rate = B150; break; case 200: desired_baud_rate = B200; break; case 300: desired_baud_rate = B300; break; case 600: desired_baud_rate = B600; break; case 1200: desired_baud_rate = B1200; break; case 1800: desired_baud_rate = B1800; break; case 2400: desired_baud_rate = B2400; break; case 4800: desired_baud_rate = B4800; break; case 9600: desired_baud_rate = B9600; break; case 19200: desired_baud_rate = B19200; break; case 38400: desired_baud_rate = B38400; break; } if (desired_baud_rate) { cfsetispeed(&options, desired_baud_rate); cfsetospeed(&options, desired_baud_rate); } else { /* set baud to something that is defined */ cfsetispeed(&options, B115200); cfsetospeed(&options, B115200); } // enable the receiver and set local mode options.c_cflag |= (CLOCAL | CREAD); // NEVER set this directly, use "|=" // set the 8N1 options.c_cflag &= ~(PARENB); // disable parity checking [N] options.c_cflag &= ~(CSTOPB); // disable 2 stop bits (means 1 stop bit) [1] options.c_cflag &= ~(CSIZE); // mask the character bits options.c_cflag |= num_bytes; // select 8 data bits [8] // output options -- post process output and map new lines to // carriage return-new lines options.c_oflag |= OPOST | ONLCR; // lock in the options tcsetattr(fd, TCSANOW, &options); } } return(fd); } /****************************************************************************** * * Name: OpenRawSerialPort * * Purpose: This function opens a raw serial port * *****************************************************************************/ int OpenRawSerialPort ( char *dev_name, int baud_rate, int num_bytes, PARITY_TYPE parity, unsigned char vmin, unsigned char vtime ) { #define ALT_SERIAL_SETUP (1) int fd = OpenSerialPort (dev_name, baud_rate, num_bytes, parity); if (fd>= 0) { struct termios options; // get the port's current attribute set tcgetattr(fd, &options); #if ALT_SERIAL_SETUP options.c_lflag = 0; // ignore framing and parity errors options.c_iflag = IGNPAR; // disable output post-processing options.c_oflag = 0; #else // disable H/W flow control options.c_cflag &= ~(CRTSCTS); // use RAW input - i.e. do NOT process the stream, simply pump the bytes in/out options.c_lflag &= ~(ICANON | ECHO | ECHOE | ISIG); // disable input parity check options.c_iflag &= ~(INPCK); // disable S/W flow control options.c_iflag &= ~(IXON | IXOFF | IXANY); // disable a bunch of stuff options.c_iflag &= ~(IGNBRK | BRKINT | INLCR | IGNCR | ICRNL | IUCLC | IMAXBEL); // disable output post-processing options.c_oflag &= ~(OPOST); #endif // set the return rules for read() options.c_cc[VMIN] = vmin; // defaults to MAX_INPUT; at least MAX_INPUT bytes must be read; options.c_cc[VTIME] = vtime; // defaults to 1 => inter-byte delay = 1/10 sec // flush read or written data tcflush(fd, TCIFLUSH); // lock in the options tcsetattr(fd, TCSANOW, &options); } return (fd); } ///////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////// //#define DEBUG #define STRING_SIZE (4096) #define MAX_TIMEOUTS (10) #ifdef DEBUG #define DEBUG_PRINT (printf) #else #define DEBUG_PRINT(...) #endif // globals int fd; pthread_t tx_thread, rx_thread; unsigned char *send_string = NULL; unsigned char *recv_string = NULL; /****************************************************************************** * * Name: catchControlC * * Purpose: Catches the control-c and triggers a shutdown event so the * application shuts down gracefully. * *****************************************************************************/ void catchControlC(int) { printf("\n- killing tx_thread...\n");fflush(stdout); pthread_kill(tx_thread, 0); printf("\n- killing rx_thread...\n");fflush(stdout); pthread_kill(rx_thread, 0); printf("\n- closing fd...\n");fflush(stdout); close(fd); if (send_string) { delete (send_string); } if (recv_string) { delete (recv_string); } exit(1); } void *tx(void *params) { DEBUG_PRINT("TX thread\n"); // unsigned char *send_string = (char *)params; if (send_string == NULL) { printf("ERROR: send_string = NULL\n"); pthread_exit(NULL); } // scan for non-alphabet characters in received string for (int x=0; x < STRING_SIZE; x++) { if ( (send_string[x] < 'A') || (send_string[x]> 'Z') ) { printf("\n- TX ERROR: '%c' found in read return!\n", send_string[x]); } } int num_bytes_written = 0, num_timeouts = 0; while ( (num_bytes_written < STRING_SIZE) && (num_timeouts < MAX_TIMEOUTS) ) { int z = write(fd, &send_string[num_bytes_written], (STRING_SIZE - num_bytes_written)); if (z == 0) // timed out { num_timeouts++; printf("- TX: %d of %d sent, timeouts: %d\n", num_bytes_written, STRING_SIZE, num_timeouts);fflush(stdout); } else if ( num_bytes_written < 0 ) { printf("*** ERROR: Failed to send!\n");fflush(stdout); pthread_exit(NULL); } num_bytes_written += z; DEBUG_PRINT("- TX: %d of %d sent, timeouts: %d\n", num_bytes_written, STRING_SIZE, num_timeouts);fflush(stdout); } if (num_timeouts> MAX_TIMEOUTS) { printf("-- TX: Exceeded timeout allotment (%d)\n", MAX_TIMEOUTS); } pthread_exit(NULL); } void *rx(void *params) { DEBUG_PRINT("RX thread\n"); // unsigned char *recv_string = (char *)params; if (recv_string == NULL) { printf("ERROR: recv_string = NULL\n"); pthread_exit(NULL); } int num_bytes_read = 0, num_timeouts = 0; while ( (num_bytes_read < STRING_SIZE) && (num_timeouts < MAX_TIMEOUTS) ) { int y = read(fd, &recv_string[num_bytes_read], (STRING_SIZE - num_bytes_read)); if (y == 0) // timed out { num_timeouts++; printf("- RX: %d of %d received, timeouts: %d\n", num_bytes_read, STRING_SIZE, num_timeouts);fflush(stdout); } else if ( y < 0 ) // error { printf("*** ERROR: Read Error!\n");fflush(stdout); pthread_exit(NULL); } // scan for non-alphabet characters in received string for (int x=0; x < y; x++) { if ( (recv_string[num_bytes_read + x] < 'A') || (recv_string[num_bytes_read + x]> 'Z') ) { printf("\n- RX ERROR: '%c' found in read return. Byte %d of the %d bytes read does not fit between 'A' & 'Z'!\n", recv_string[num_bytes_read + x], x, y); } } num_bytes_read += y; DEBUG_PRINT("- RX: %d of %d received, timeouts: %d\n", num_bytes_read, STRING_SIZE, num_timeouts);fflush(stdout); } if (num_timeouts> MAX_TIMEOUTS) { printf("-- TX: Exceeded timeout allotment (%d)\n", MAX_TIMEOUTS); } pthread_exit(NULL); } int main (int argc, char *argv[]) { int ret_val = -1; unsigned char c; send_string = (unsigned char*) new unsigned char[STRING_SIZE]; recv_string = (unsigned char*) new unsigned char[STRING_SIZE]; // random seed srand(time(NULL)); // -- set up signal controls -- if(signal(SIGINT, SIG_IGN) != SIG_IGN) { signal(SIGINT, catchControlC); } if (argc == 2) // app name + serial port { int num_loops = 0; DEBUG_PRINT("starting...\n");fflush(stdout); fd = OpenRawSerialPort(argv[1], 115200, CS8, NO_PARITY, 0, 10); if (fd < 0) { printf("*** ERROR: Failed to open serial port: '%s',(%d)\n", strerror(errno), fd);fflush(stdout); exit(-1); } while(1) { printf("Iteration: %d...", num_loops);fflush(stdout); /* setup send string */ // cap alphabet c = 'A'; for (int x = 0; x < STRING_SIZE; x++) { send_string[x] = c++; if (c == '[') // 1 step past 'Z' { c = 'A'; } } /* clear recv string */ // fill with characters memset(recv_string, ' ', STRING_SIZE); /* create both threads - receiver first since its the consumer */ if ( pthread_create(&rx_thread, NULL, rx, (void *)recv_string) != 0 ) { exit(-1); } if ( pthread_create(&tx_thread, NULL, tx, (void *)send_string) != 0 ) { exit(-1); } /* wait for threads to complete */ pthread_join(tx_thread, NULL); pthread_join(rx_thread, NULL); printf("done, cross-checking...");fflush(stdout); int num_errors = 0, offset = 0; for (unsigned int x = 0; x < STRING_SIZE; x++) { if ( send_string[x] != recv_string[x] ) { if (num_errors == 0) { printf("\n\nIndex:\tTX:\tRX:\n");fflush(stdout); } printf("%04d\t'%c'[%02x]\t'%c'[%02x]\n", x, send_string[x], send_string[x], recv_string[x], recv_string[x]);fflush(stdout); num_errors++; } } if (num_errors == 0) { printf("done, MATCHED!"); } else { printf("\n\t*** %d Errors detected @ iteration %d! ***\n", num_errors, num_loops); } printf("\r"); usleep(10); num_loops++; } } else // show usage { printf("Error: Usage: '%s ttySx'\n", argv[0]); } return(ret_val); } <<<<<<<<<<< end: test code>>>>>>>>>>>>> _________________________________________________________________ Your smile counts. The more smiles you share, the more we donate.  Join in. www.windowslive.com/smile?ocid=TXT_TAGLM_Wave2_oprsmilewlhmtagline From ralf@linux-mips.org Wed Dec 5 18:22:32 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 05 Dec 2007 18:22:34 +0000 (GMT) Received: from localhost.localdomain ([127.0.0.1]:21412 "EHLO dl5rb.ham-radio-op.net") by ftp.linux-mips.org with ESMTP id S20030716AbXLESWc (ORCPT ); Wed, 5 Dec 2007 18:22:32 +0000 Received: from denk.linux-mips.net (denk.linux-mips.net [127.0.0.1]) by dl5rb.ham-radio-op.net (8.14.1/8.13.8) with ESMTP id lB5IL7pD011316; Wed, 5 Dec 2007 18:21:32 GMT Received: (from ralf@localhost) by denk.linux-mips.net (8.14.1/8.14.1/Submit) id lB5IL6hH011315; Wed, 5 Dec 2007 18:21:06 GMT Date: Wed, 5 Dec 2007 18:21:06 +0000 From: Ralf Baechle To: Sergei Shtylyov Cc: linux-mips@linux-mips.org Subject: Re: [PATCH 2/2] Alchemy: fix IRQ bases Message-ID: <20071205182106.GB10697@linux-mips.org> References: <200712051908.26703.sshtylyov@ru.mvista.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200712051908.26703.sshtylyov@ru.mvista.com> User-Agent: Mutt/1.5.17 (2007-11-01) Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 17706 X-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 05, 2007 at 07:08:26PM +0300, Sergei Shtylyov wrote: > Do what the commits commits f3e8d1da389fe2e514e31f6e93c690c8e1243849 and > 9d360ab4a7568a8d177280f651a8a772ae52b9b9 failed to achieve -- actually > convert the Alchemy code to irq_cpu. Applied, thanks. Ralf From ralf@linux-mips.org Wed Dec 5 18:25:54 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 05 Dec 2007 18:25:56 +0000 (GMT) Received: from localhost.localdomain ([127.0.0.1]:61592 "EHLO dl5rb.ham-radio-op.net") by ftp.linux-mips.org with ESMTP id S20030786AbXLESZy (ORCPT ); Wed, 5 Dec 2007 18:25:54 +0000 Received: from denk.linux-mips.net (denk.linux-mips.net [127.0.0.1]) by dl5rb.ham-radio-op.net (8.14.1/8.13.8) with ESMTP id lB5INrp1011352; Wed, 5 Dec 2007 18:24:18 GMT Received: (from ralf@localhost) by denk.linux-mips.net (8.14.1/8.14.1/Submit) id lB5INrp5011351; Wed, 5 Dec 2007 18:23:53 GMT Date: Wed, 5 Dec 2007 18:23:53 +0000 From: Ralf Baechle To: Manuel Lauss Cc: Sergei Shtylyov , linux-mips@linux-mips.org Subject: Re: [PATCH 0/2] Alchemy: fix interrupt routing Message-ID: <20071205182353.GC10697@linux-mips.org> References: <200712051908.18780.sshtylyov@ru.mvista.com> <4756D42E.9040609@fh-hagenberg.at> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4756D42E.9040609@fh-hagenberg.at> User-Agent: Mutt/1.5.17 (2007-11-01) Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 17707 X-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 05, 2007 at 05:39:10PM +0100, Manuel Lauss wrote: > Thanks a billion! > Finally I can boot linux-2.6.24-rc on my Au1200 again! And with a bit of luck Alchemy will now support tickless, too. Ralf From sshtylyov@ru.mvista.com Wed Dec 5 18:29:23 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 05 Dec 2007 18:29:32 +0000 (GMT) Received: from h155.mvista.com ([63.81.120.155]:44812 "EHLO imap.sh.mvista.com") by ftp.linux-mips.org with ESMTP id S20030733AbXLES3X (ORCPT ); Wed, 5 Dec 2007 18:29:23 +0000 Received: from [192.168.1.234] (unknown [10.150.0.9]) by imap.sh.mvista.com (Postfix) with ESMTP id 1EB3B3EC9; Wed, 5 Dec 2007 10:29:20 -0800 (PST) Message-ID: <4756EE12.8000605@ru.mvista.com> Date: Wed, 05 Dec 2007 21:29: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: Ralf Baechle Cc: Manuel Lauss , linux-mips@linux-mips.org Subject: Re: [PATCH 0/2] Alchemy: fix interrupt routing References: <200712051908.18780.sshtylyov@ru.mvista.com> <4756D42E.9040609@fh-hagenberg.at> <20071205182353.GC10697@linux-mips.org> In-Reply-To: <20071205182353.GC10697@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: 17708 X-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 Ralf Baechle wrote: >>Thanks a billion! >>Finally I can boot linux-2.6.24-rc on my Au1200 again! > And with a bit of luck Alchemy will now support tickless, too. Sigh. If only it had working PCI... :-( > Ralf WBR, Sergei From sshtylyov@ru.mvista.com Wed Dec 5 18:57:08 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 05 Dec 2007 18:57:16 +0000 (GMT) Received: from h155.mvista.com ([63.81.120.155]:25869 "EHLO imap.sh.mvista.com") by ftp.linux-mips.org with ESMTP id S20031549AbXLES5I (ORCPT ); Wed, 5 Dec 2007 18:57:08 +0000 Received: from [192.168.1.234] (unknown [10.150.0.9]) by imap.sh.mvista.com (Postfix) with ESMTP id A02813ECB; Wed, 5 Dec 2007 10:57:05 -0800 (PST) Message-ID: <4756F494.8090207@ru.mvista.com> Date: Wed, 05 Dec 2007 21:57:24 +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: Manuel Lauss , linux-mips@linux-mips.org Subject: Re: [PATCH 0/2] Alchemy: fix interrupt routing References: <200712051908.18780.sshtylyov@ru.mvista.com> <4756D42E.9040609@fh-hagenberg.at> <20071205182353.GC10697@linux-mips.org> In-Reply-To: <20071205182353.GC10697@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: 17709 X-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 Ralf Baechle wrote: >>Thanks a billion! >>Finally I can boot linux-2.6.24-rc on my Au1200 again! > And with a bit of luck Alchemy will now support tickless, too. It works: Timer Stats Version: v0.2 Sample period: 8.024 s 8, 1 swapper __netdev_watchdog_up (dev_watchdog) 8, 1 swapper phy_connect (phy_timer) 8, 1 swapper phy_connect (phy_timer) 7, 0 swapper receive_chars (delayed_work_timer_fn) 1, 1 swapper cache_register (delayed_work_timer_fn) 1, 1 swapper neigh_table_init_no_netlink (neigh_periodic_timer) 4, 1 swapper queue_delayed_work_on (delayed_work_timer_fn) 2, 866 mvltd schedule_timeout (process_timeout) 1, 0 swapper page_writeback_init (wb_timer_fn) 1, 1 init schedule_timeout (process_timeout) 41 total events, 5.109 events/sec > Ralf WBR, Sergei From ralf@linux-mips.org Wed Dec 5 19:14:11 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 05 Dec 2007 19:14:13 +0000 (GMT) Received: from localhost.localdomain ([127.0.0.1]:36331 "EHLO dl5rb.ham-radio-op.net") by ftp.linux-mips.org with ESMTP id S20031581AbXLETOL (ORCPT ); Wed, 5 Dec 2007 19:14:11 +0000 Received: from denk.linux-mips.net (denk.linux-mips.net [127.0.0.1]) by dl5rb.ham-radio-op.net (8.14.1/8.13.8) with ESMTP id lB5JCAcV012671; Wed, 5 Dec 2007 19:12:35 GMT Received: (from ralf@localhost) by denk.linux-mips.net (8.14.1/8.14.1/Submit) id lB5JC8fR012670; Wed, 5 Dec 2007 19:12:08 GMT Date: Wed, 5 Dec 2007 19:12:08 +0000 From: Ralf Baechle To: Sergei Shtylyov Cc: Manuel Lauss , linux-mips@linux-mips.org Subject: Re: [PATCH 0/2] Alchemy: fix interrupt routing Message-ID: <20071205191208.GA12547@linux-mips.org> References: <200712051908.18780.sshtylyov@ru.mvista.com> <4756D42E.9040609@fh-hagenberg.at> <20071205182353.GC10697@linux-mips.org> <4756F494.8090207@ru.mvista.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4756F494.8090207@ru.mvista.com> User-Agent: Mutt/1.5.17 (2007-11-01) Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 17710 X-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 05, 2007 at 09:57:24PM +0300, Sergei Shtylyov wrote: > It works: > 41 total events, 5.109 events/sec That's the expected behaviour, good. One of the remaining problems on some platforms with tickless kernels is that not all clocksource / clockevent driver combinations are playing nicely with each other. You can switch the clocksource driver manually at runtime. First let's see what clocksource we have: # cd /sys/devices/system/clocksource/clocksource0/ # cat available_clocksource MIPS pit jiffies # cat current_clocksource MIPS MIPS is the CP0 count register. pit is the i8259 and jiffies simply counts interrupts like in the old days so has problems with lost timer interrupts and generally not such a great idea for tickless. You should be able to switch between all these drivers by something like: # echo jiffies > current_clocksource Time: jiffies clocksource has been installed. # Try switching between all the available clocksources a few times to see if that's working right also. Ralf From sshtylyov@ru.mvista.com Wed Dec 5 19:22:04 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 05 Dec 2007 19:22:12 +0000 (GMT) Received: from h155.mvista.com ([63.81.120.155]:54029 "EHLO imap.sh.mvista.com") by ftp.linux-mips.org with ESMTP id S20032114AbXLETWE (ORCPT ); Wed, 5 Dec 2007 19:22:04 +0000 Received: from [192.168.1.234] (unknown [10.150.0.9]) by imap.sh.mvista.com (Postfix) with ESMTP id CAC463ECC; Wed, 5 Dec 2007 11:22:01 -0800 (PST) Message-ID: <4756FA6C.6040807@ru.mvista.com> Date: Wed, 05 Dec 2007 22:22:20 +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: Manuel Lauss , linux-mips@linux-mips.org Subject: Re: [PATCH 0/2] Alchemy: fix interrupt routing References: <200712051908.18780.sshtylyov@ru.mvista.com> <4756D42E.9040609@fh-hagenberg.at> <20071205182353.GC10697@linux-mips.org> <4756F494.8090207@ru.mvista.com> <20071205191208.GA12547@linux-mips.org> In-Reply-To: <20071205191208.GA12547@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: 17711 X-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 Ralf Baechle wrote: >> It works: >>41 total events, 5.109 events/sec > That's the expected behaviour, good. > One of the remaining problems on some platforms with tickless kernels is > that not all clocksource / clockevent driver combinations are playing > nicely with each other. You can switch the clocksource driver manually > at runtime. First let's see what clocksource we have: > > # cd /sys/devices/system/clocksource/clocksource0/ > # cat available_clocksource > MIPS pit jiffies I only have MIPS and jiffies of course. :-) > # cat current_clocksource > MIPS > MIPS is the CP0 count register. pit is the i8259 and jiffies simply counts > interrupts like in the old days so has problems with lost timer interrupts > and generally not such a great idea for tickless. You should be able to > switch between all these drivers by something like: > # echo jiffies > current_clocksource > Time: jiffies clocksource has been installed. > # > Try switching between all the available clocksources a few times to see if > that's working right also. It died after I selected jiffies. > Ralf WBR, Sergei From pf@pfrst.de Wed Dec 5 19:56:27 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 05 Dec 2007 19:56:37 +0000 (GMT) Received: from mail1.pearl-online.net ([62.159.194.147]:28207 "EHLO mail1.pearl-online.net") by ftp.linux-mips.org with ESMTP id S20032469AbXLET41 (ORCPT ); Wed, 5 Dec 2007 19:56:27 +0000 Received: from SNaIlmail.Peter (unknown [77.47.48.214]) by mail1.pearl-online.net (Postfix) with ESMTP id 64867AF82; Wed, 5 Dec 2007 20:56:55 +0100 (CET) Received: from Indigo2.Peter (Indigo2.Peter [192.168.1.28]) by SNaIlmail.Peter (8.12.6/8.12.6/Sendmail/Linux 2.0.32) with ESMTP id lB5JuDmP000707; Wed, 5 Dec 2007 20:56:14 +0100 Received: from Indigo2.Peter (localhost [127.0.0.1]) by Indigo2.Peter (8.12.6/8.12.6/Sendmail/Linux 2.6.20-ip28) with ESMTP id lB5Jnri5000386; Wed, 5 Dec 2007 20:49:53 +0100 Received: from localhost (pf@localhost) by Indigo2.Peter (8.12.6/8.12.6/Submit) with ESMTP id lB5JnrS0000383; Wed, 5 Dec 2007 20:49:53 +0100 Date: Wed, 5 Dec 2007 20:49:53 +0100 (CET) From: peter fuerst To: Thomas Bogendoerfer Cc: Kumba , Ralf Baechle , linux-mips@linux-mips.org Subject: Re: [UPDATED PATCH] IP28 support In-Reply-To: <20071205093938.GA6848@alpha.franken.de> Message-ID: 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: 17712 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: pf@pfrst.de Precedence: bulk X-list: linux-mips On Wed, 5 Dec 2007, Thomas Bogendoerfer wrote: > Date: Wed, 5 Dec 2007 10:39:38 +0100 > From: Thomas Bogendoerfer > To: Kumba > Cc: Ralf Baechle , linux-mips@linux-mips.org > Subject: Re: [UPDATED PATCH] IP28 support > > On Wed, Dec 05, 2007 at 01:16:13AM -0500, Kumba wrote: > > I've been out of it lately -- did the gcc side of things ever make it in, > > or do we need to go push on that some more? > > We need push on that. ... There was no answer to .../2006-05/msg01446.html. Perhaps i should just put together an updated patch, that incorporates the changes proposed in msg01446.html, and submit it (with the longer "Cc:" line and a hint to the increasing demand for it ;-) to revive at least the discussion at gcc-patches. What could be changed beyond the proposed changes without either omitting necessary cache-barriers or crippling the R10k, i can't see yet. > We need push on that. Looking at > > http://gcc.gnu.org/ml/gcc-patches/2006-04/msg00291.html > > there seems to be a missing understanding, why the cache > barriers are needed. I guess the patch could be improved > by pointing directly to the errata section of the R10k > user manual. Or even better copy the text out of the user > manual. That should make clear why this patch is needed. Better copy, i guess. (Assuming copying whole paragraphs is still proper citation ;-) Along with the initial patch (.../2006-03.msg00090.html) as well as in the last letter so far (.../2006-05/msg01446.html) i pointed to the corresponding chapter in the R10k User's Manual and to the entry in the NetBSD eMail archive. In the last letter i tried to augment these by a summarizing explanation, but it seems i'm not very good at that... > > Peter did you do the copyright assigment ? That's probably > the second part, which needs to be done. Yes, the assignment process became complete on May 22 2006 (though apparently i missed to notify Richard Sandiford about it) > > Thomas. > > -- > Crap can work. Given enough thrust pigs will fly, but it's not necessary a > good idea. [ RFC1925, 2.3 ] > > > kind regards peter From ddaney@avtrex.com Wed Dec 5 20:38:10 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 05 Dec 2007 20:38:19 +0000 (GMT) Received: from smtp1.dnsmadeeasy.com ([205.234.170.144]:35305 "EHLO smtp1.dnsmadeeasy.com") by ftp.linux-mips.org with ESMTP id S20032661AbXLEUiK (ORCPT ); Wed, 5 Dec 2007 20:38:10 +0000 Received: from smtp1.dnsmadeeasy.com (localhost [127.0.0.1]) by smtp1.dnsmadeeasy.com (Postfix) with ESMTP id CCEFC310C7D; Wed, 5 Dec 2007 20:38:16 +0000 (UTC) X-Authenticated-Name: js.dnsmadeeasy X-Transit-System: In case of SPAM please contact abuse@dnsmadeeasy.com Received: from avtrex.com (unknown [67.116.42.147]) by smtp1.dnsmadeeasy.com (Postfix) with ESMTP; Wed, 5 Dec 2007 20:38:16 +0000 (UTC) Received: from [192.168.7.26] ([192.168.7.26]) by avtrex.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 5 Dec 2007 12:38:00 -0800 Message-ID: <47570C27.9050901@avtrex.com> Date: Wed, 05 Dec 2007 12:37:59 -0800 From: David Daney User-Agent: Thunderbird 1.5.0.12 (X11/20071019) MIME-Version: 1.0 To: peter fuerst Cc: Thomas Bogendoerfer , Kumba , Ralf Baechle , linux-mips@linux-mips.org Subject: Re: [UPDATED PATCH] IP28 support References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 05 Dec 2007 20:38:00.0368 (UTC) FILETIME=[B9DC2B00:01C8377E] Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 17713 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: ddaney@avtrex.com Precedence: bulk X-list: linux-mips peter fuerst wrote: > > On Wed, 5 Dec 2007, Thomas Bogendoerfer wrote: > >> Date: Wed, 5 Dec 2007 10:39:38 +0100 >> From: Thomas Bogendoerfer >> To: Kumba >> Cc: Ralf Baechle , linux-mips@linux-mips.org >> Subject: Re: [UPDATED PATCH] IP28 support >> >> On Wed, Dec 05, 2007 at 01:16:13AM -0500, Kumba wrote: >>> I've been out of it lately -- did the gcc side of things ever make it in, >>> or do we need to go push on that some more? >> We need push on that. ... > > There was no answer to .../2006-05/msg01446.html. Perhaps i should just > put together an updated patch, That would be helpful. It would have to be against GCC's svn trunk. Currently 4.3 is in regression fix only mode. The earliest the patch could appear in an official GCC release would probably be version 4.4 > that incorporates the changes proposed in > msg01446.html, and submit it (with the longer "Cc:" line and a hint to > the increasing demand for it ;-) to revive at least the discussion at > gcc-patches. Just sent it to gcc-patches@ I think it will be noticed. > What could be changed beyond the proposed changes without either omitting > necessary cache-barriers or crippling the R10k, i can't see yet. > >> We need push on that. Looking at >> >> http://gcc.gnu.org/ml/gcc-patches/2006-04/msg00291.html >> >> there seems to be a missing understanding, why the cache >> barriers are needed. I guess the patch could be improved >> by pointing directly to the errata section of the R10k >> user manual. Or even better copy the text out of the user >> manual. That should make clear why this patch is needed. > > Better copy, i guess. (Assuming copying whole paragraphs is still proper > citation ;-) Along with the initial patch (.../2006-03.msg00090.html) as > well as in the last letter so far (.../2006-05/msg01446.html) i pointed > to the corresponding chapter in the R10k User's Manual and to the entry > in the NetBSD eMail archive. In the last letter i tried to augment these > by a summarizing explanation, but it seems i'm not very good at that... > >> Peter did you do the copyright assigment ? That's probably >> the second part, which needs to be done. > > Yes, the assignment process became complete on May 22 2006 > (though apparently i missed to notify Richard Sandiford about it) > Good. Richard is generally quite responsive to patches. Perhaps CC him on your patch. David Daney From mano@roarinelk.homelinux.net Thu Dec 6 07:12:58 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 06 Dec 2007 07:13:08 +0000 (GMT) Received: from fnoeppeil48.netpark.at ([217.175.205.176]:18952 "EHLO roarinelk.homelinux.net") by ftp.linux-mips.org with ESMTP id S20022157AbXLFHM6 (ORCPT ); Thu, 6 Dec 2007 07:12:58 +0000 Received: (qmail 20223 invoked by uid 1000); 6 Dec 2007 08:11:56 +0100 Date: Thu, 6 Dec 2007 08:11:56 +0100 From: Manuel Lauss To: linux-mips@linux-mips.org Subject: [PATCH] Alchemy: Fix Au1x SD controller IRQ Message-ID: <20071206071156.GA20211@roarinelk.homelinux.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.16 (2007-06-09) Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 17714 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: mano@roarinelk.homelinux.net Precedence: bulk X-list: linux-mips With the introduction of MIPS_CPU_IRQ_BASE, the hardcoded IRQ number of the au1100/au1200 SD controller(s) is no longer valid. Signed-off-by: Manuel Lauss --- linux-2.6.24-rc4/include/asm-mips/mach-au1x00/au1100_mmc.h 2007-12-04 08:31:24.613002000 +0100 +++ linux-2.6.24-rc4-work/include/asm-mips/mach-au1x00/au1100_mmc.h 2007-12-06 15:33:35.000000000 +0100 @@ -41,8 +41,11 @@ #define NUM_AU1100_MMC_CONTROLLERS 2 - -#define AU1100_SD_IRQ 2 +#if defined(CONFIG_SOC_AU1100) +#define AU1100_SD_IRQ AU1100_SD_INT +#elif defined(CONFIG_SOC_AU1200) +#define AU1100_SD_IRQ AU1200_SD_INT +#endif #define SD0_BASE 0xB0600000 From mano@roarinelk.homelinux.net Thu Dec 6 08:08:56 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 06 Dec 2007 08:09:06 +0000 (GMT) Received: from fnoeppeil48.netpark.at ([217.175.205.176]:44298 "EHLO roarinelk.homelinux.net") by ftp.linux-mips.org with ESMTP id S20022323AbXLFII4 (ORCPT ); Thu, 6 Dec 2007 08:08:56 +0000 Received: (qmail 20550 invoked by uid 1000); 6 Dec 2007 09:07:55 +0100 Date: Thu, 6 Dec 2007 09:07:55 +0100 From: Manuel Lauss To: linux-mips@linux-mips.org Subject: [RFC PATCH] Alchemy: Au1210/Au1250 CPU support Message-ID: <20071206080755.GA20485@roarinelk.homelinux.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.16 (2007-06-09) Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 17715 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: mano@roarinelk.homelinux.net Precedence: bulk X-list: linux-mips This patch adds IDs fornew Au1200 variants: Au1210 and Au1250. They are essentially identical to the Au1200 except for the Au1210 which has a different SoC-ID in the PRId register [bits 31:24]. The Au1250 is a "Au1200 V0.2". Signed-off-by: Manuel Lauss --- linux-2.6.24-rc4/include/asm-mips/cpu.h 2007-12-04 08:33:33.143002000 +0100 +++ linux-2.6.24-rc4-work/include/asm-mips/cpu.h 2007-12-06 16:28:48.000000000 +0100 @@ -195,8 +195,8 @@ enum cpu_type_enum { * MIPS32 class processors */ CPU_4KC, CPU_4KEC, CPU_4KSC, CPU_24K, CPU_34K, CPU_74K, CPU_AU1000, - CPU_AU1100, CPU_AU1200, CPU_AU1500, CPU_AU1550, CPU_PR4450, - CPU_BCM3302, CPU_BCM4710, + CPU_AU1100, CPU_AU1200, CPU_AU1210, CPU_AU1250, CPU_AU1500, CPU_AU1550, + CPU_PR4450, CPU_BCM3302, CPU_BCM4710, /* * MIPS64 class processors --- linux-2.6.24-rc4/arch/mips/kernel/cpu-probe.c 2007-12-04 08:33:00.793002000 +0100 +++ linux-2.6.24-rc4-work/arch/mips/kernel/cpu-probe.c 2007-12-06 16:27:06.000000000 +0100 @@ -188,6 +188,8 @@ static inline void check_wait(void) case CPU_AU1500: case CPU_AU1550: case CPU_AU1200: + case CPU_AU1210: + case CPU_AU1250: if (allow_au1k_wait) cpu_wait = au1k_wait; break; @@ -733,6 +735,11 @@ static inline void cpu_probe_alchemy(str break; case 4: c->cputype = CPU_AU1200; + if (2 == (c->processor_id & 0xff)) + c->cputype = CPU_AU1250; + break; + case 5: + c->cputype = CPU_AU1210; break; default: panic("Unknown Au Core!"); @@ -858,6 +865,8 @@ static __init const char *cpu_to_name(st case CPU_AU1100: name = "Au1100"; break; case CPU_AU1550: name = "Au1550"; break; case CPU_AU1200: name = "Au1200"; break; + case CPU_AU1210: name = "Au1210"; break; + case CPU_AU1250: name = "Au1250"; break; case CPU_4KEC: name = "MIPS 4KEc"; break; case CPU_4KSC: name = "MIPS 4KSc"; break; case CPU_VR41XX: name = "NEC Vr41xx"; break; --- linux-2.6.24-rc4/arch/mips/mm/c-r4k.c 2007-12-04 08:33:00.963002000 +0100 +++ linux-2.6.24-rc4-work/arch/mips/mm/c-r4k.c 2007-12-06 16:44:07.000000000 +0100 @@ -989,6 +989,8 @@ static void __init probe_pcache(void) case CPU_AU1100: case CPU_AU1550: case CPU_AU1200: + case CPU_AU1210: + case CPU_AU1250: c->icache.flags |= MIPS_CACHE_IC_F_DC; break; } --- linux-2.6.24-rc4/arch/mips/mm/tlbex.c 2007-12-04 08:33:00.983002000 +0100 +++ linux-2.6.24-rc4-work/arch/mips/mm/tlbex.c 2007-12-06 16:44:30.000000000 +0100 @@ -894,6 +894,8 @@ static __init void build_tlb_write_entry case CPU_AU1500: case CPU_AU1550: case CPU_AU1200: + case CPU_AU1210: + case CPU_AU1250: case CPU_PR4450: i_nop(p); tlbw(p); From ralf@linux-mips.org Thu Dec 6 11:41:34 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 06 Dec 2007 11:41:36 +0000 (GMT) Received: from localhost.localdomain ([127.0.0.1]:64650 "EHLO dl5rb.ham-radio-op.net") by ftp.linux-mips.org with ESMTP id S20022989AbXLFLle (ORCPT ); Thu, 6 Dec 2007 11:41:34 +0000 Received: from denk.linux-mips.net (denk.linux-mips.net [127.0.0.1]) by dl5rb.ham-radio-op.net (8.14.1/8.13.8) with ESMTP id lB6Bf4GE006748; Thu, 6 Dec 2007 11:41:05 GMT Received: (from ralf@localhost) by denk.linux-mips.net (8.14.1/8.14.1/Submit) id lB6Bf3FU006747; Thu, 6 Dec 2007 11:41:03 GMT Date: Thu, 6 Dec 2007 11:41:03 +0000 From: Ralf Baechle To: peter fuerst Cc: Thomas Bogendoerfer , Kumba , linux-mips@linux-mips.org Subject: Re: [UPDATED PATCH] IP28 support Message-ID: <20071206114103.GA6498@linux-mips.org> References: <20071205093938.GA6848@alpha.franken.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.17 (2007-11-01) Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 17716 X-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 05, 2007 at 08:49:53PM +0100, peter fuerst wrote: > > there seems to be a missing understanding, why the cache > > barriers are needed. I guess the patch could be improved > > by pointing directly to the errata section of the R10k > > user manual. Or even better copy the text out of the user > > manual. That should make clear why this patch is needed. > > Better copy, i guess. (Assuming copying whole paragraphs is still proper > citation ;-) Along with the initial patch (.../2006-03.msg00090.html) as > well as in the last letter so far (.../2006-05/msg01446.html) i pointed > to the corresponding chapter in the R10k User's Manual and to the entry > in the NetBSD eMail archive. In the last letter i tried to augment these > by a summarizing explanation, but it seems i'm not very good at that... I'm not sure how far "fair use" of the R10000 manual text can be stretched. But afair Bill Earl (wje@sgi.com) posted a reasonable explanation which also for the purposes of the gcc manual is much easier to understand. Ralf From ralf@linux-mips.org Thu Dec 6 11:45:15 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 06 Dec 2007 11:45:18 +0000 (GMT) Received: from localhost.localdomain ([127.0.0.1]:44765 "EHLO dl5rb.ham-radio-op.net") by ftp.linux-mips.org with ESMTP id S20022993AbXLFLpO (ORCPT ); Thu, 6 Dec 2007 11:45:14 +0000 Received: from denk.linux-mips.net (denk.linux-mips.net [127.0.0.1]) by dl5rb.ham-radio-op.net (8.14.1/8.13.8) with ESMTP id lB6BilI9006837; Thu, 6 Dec 2007 11:44:47 GMT Received: (from ralf@localhost) by denk.linux-mips.net (8.14.1/8.14.1/Submit) id lB6Bikq7006836; Thu, 6 Dec 2007 11:44:46 GMT Date: Thu, 6 Dec 2007 11:44:46 +0000 From: Ralf Baechle To: David Daney Cc: peter fuerst , Thomas Bogendoerfer , Kumba , linux-mips@linux-mips.org Subject: Re: [UPDATED PATCH] IP28 support Message-ID: <20071206114446.GC6498@linux-mips.org> References: <47570C27.9050901@avtrex.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <47570C27.9050901@avtrex.com> User-Agent: Mutt/1.5.17 (2007-11-01) Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 17717 X-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 05, 2007 at 12:37:59PM -0800, David Daney wrote: >> There was no answer to .../2006-05/msg01446.html. Perhaps i should just >> put together an updated patch, > > That would be helpful. It would have to be against GCC's svn trunk. > Currently 4.3 is in regression fix only mode. The earliest the patch could > appear in an official GCC release would probably be version 4.4 Many distributions have the policy of applying only patches that are upstream, even if they're upstream only for a newer version. As such getting them into the FSF 4.4 tree would also be tremendously useful as an icebreaker. Ralf From nathan_eggan@live.com Thu Dec 6 16:41:51 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 06 Dec 2007 16:42:00 +0000 (GMT) Received: from blu0-omc1-s6.blu0.hotmail.com ([65.55.162.149]:62569 "EHLO blu0-omc1-s6.blu0.hotmail.com") by ftp.linux-mips.org with ESMTP id S20026788AbXLFQlv convert rfc822-to-8bit (ORCPT ); Thu, 6 Dec 2007 16:41:51 +0000 Received: from BLU127-W10 ([65.55.162.182]) by blu0-omc1-s6.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 6 Dec 2007 08:41:23 -0800 Message-ID: X-Originating-IP: [157.185.36.161] From: Nathan Eggan To: linux-mips mailing list Subject: Re: Bug in Au1x00 UART or USB drivers for 2.6 kernels? Date: Thu, 6 Dec 2007 16:41:23 +0000 Importance: Normal Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 8BIT MIME-Version: 1.0 X-OriginalArrivalTime: 06 Dec 2007 16:41:23.0595 (UTC) FILETIME=[D65645B0:01C83826] Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 17718 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: nathan_eggan@live.com Precedence: bulk X-list: linux-mips Can anyone see this? I'm new to Ecartis, so I'm not sure whether any of my messages are getting through. Plus, my crappy Microsoft Windows Live Hotmail client could be screwing me up. I'm not sure I can force it to just send purely plain text email. Thanks, Nate _________________________________________________________________ You keep typing, we keep giving. Download Messenger and join the i’m Initiative now. http://im.live.com/messenger/im/home/?source=TAGLM From freddy@dusktilldawn.nl Thu Dec 6 16:51:06 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 06 Dec 2007 16:51:14 +0000 (GMT) Received: from tool.snarl.nl ([82.95.241.19]:29706 "EHLO tool.snarl.nl") by ftp.linux-mips.org with ESMTP id S20026868AbXLFQvG (ORCPT ); Thu, 6 Dec 2007 16:51:06 +0000 Received: from localhost (tool.local.snarl.nl [127.0.0.1]) by tool.snarl.nl (Postfix) with ESMTP id E60795DF94; Thu, 6 Dec 2007 17:51:00 +0100 (CET) Received: from tool.snarl.nl ([127.0.0.1]) by localhost (tool.local.snarl.nl [127.0.0.1]) (amavisd-new, port 10024) with LMTP id W8VuGNwoEV1s; Thu, 6 Dec 2007 17:51:00 +0100 (CET) Received: by tool.snarl.nl (Postfix, from userid 1000) id 587F35DF6F; Thu, 6 Dec 2007 17:51:00 +0100 (CET) Date: Thu, 6 Dec 2007 17:51:00 +0100 From: Freddy Spierenburg To: Nathan Eggan Cc: linux-mips mailing list Subject: Re: Bug in Au1x00 UART or USB drivers for 2.6 kernels? Message-ID: <20071206165100.GP2391@dusktilldawn.nl> References: MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="iSEM+tA/SPO43KHM" Content-Disposition: inline In-Reply-To: X-User-Agent-Feature: All mail clients suck. This one just sucks less. X-GPG-Key: http://snarl.nl/~freddy/keys/freddyPublicKey.gpg User-Agent: Mutt/1.5.16 (2007-06-11) Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 17719 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: freddy@dusktilldawn.nl Precedence: bulk X-list: linux-mips --iSEM+tA/SPO43KHM Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi Nathan, On Thu, Dec 06, 2007 at 04:41:23PM +0000, Nathan Eggan wrote: > Can anyone see this? Yes, your message came through clearly. And to reply a little bit more on topic. I had also some strange serial trouble with 2.6.16, but it dissapeared when I used 2.6.23.9. The trouble I had was using 115200bps and for some strange reason bytes would be missing on one of the interfaces. I had no trouble on ttyS2, but ttyS0 would. Strange, but using 2.6.23.9 I did not experience the same problems. I did not investigate the real cause, but just wanted to let you know. --=20 $ cat ~/.signature Freddy Spierenburg http://freddy.snarl.nl/ GnuPG: 0x7941D1E1=3DC948 5851 26D2 FA5C 39F1 E588 6F17 FD5D 7941 D1E1 $ # Please read http://www.ietf.org/rfc/rfc2015.txt before complain! --iSEM+tA/SPO43KHM Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFHWChzbxf9XXlB0eERAmXpAJwPAy0TD8UbO0O9W3q3dJpYem6btgCfT7Of dMdSa+9/guIra+nPJKBu7as= =ris/ -----END PGP SIGNATURE----- --iSEM+tA/SPO43KHM-- From ralf@linux-mips.org Thu Dec 6 16:53:52 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 06 Dec 2007 16:53:55 +0000 (GMT) Received: from localhost.localdomain ([127.0.0.1]:45781 "EHLO dl5rb.ham-radio-op.net") by ftp.linux-mips.org with ESMTP id S20026918AbXLFQxw (ORCPT ); Thu, 6 Dec 2007 16:53:52 +0000 Received: from denk.linux-mips.net (denk.linux-mips.net [127.0.0.1]) by dl5rb.ham-radio-op.net (8.14.1/8.13.8) with ESMTP id lB6GrKCn021697; Thu, 6 Dec 2007 16:53:21 GMT Received: (from ralf@localhost) by denk.linux-mips.net (8.14.1/8.14.1/Submit) id lB6GrJP3021696; Thu, 6 Dec 2007 16:53:19 GMT Date: Thu, 6 Dec 2007 16:53:19 +0000 From: Ralf Baechle To: Linus Torvalds , Andrew Morton , linux-kernel@vger.kernel.org, linux-mips@linux-mips.org Subject: [PATCH] Fix oprofile configuration breakage Message-ID: <20071206165319.GA21553@linux-mips.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.17 (2007-11-01) Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 17720 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: ralf@linux-mips.org Precedence: bulk X-list: linux-mips The cleanup 09cadedbdc01f1a4bea1f427d4fb4642eaa19da9 broke the oprofile configuration for MIPS by allowing oprofile support to be built for kernel models where oprofile doesn't have a chance in hell to work. Just a dependecy list on a number of architectures is - surprise - broken and should as per past discussions probably in most considered to be broken in most cases. So I introduce a dependency for the oprofile configuration on ARCH_SUPPORTS_OPROFILE. Signed-off-by: Ralf Baechle --- Since we're already in -rc4 I try to keep things minimally intrusive and use ARCH_SUPPORTS_OPROFILE only for MIPS for now instead of touching a dozen architectures. arch/mips/Kconfig | 4 ++++ kernel/Kconfig.instrumentation | 2 +- 2 files changed, 5 insertions(+), 1 deletion(-) diff --git a/arch/mips/Kconfig b/arch/mips/Kconfig index 455bd1f..c6fc405 100644 --- a/arch/mips/Kconfig +++ b/arch/mips/Kconfig @@ -714,6 +714,10 @@ config ARCH_HAS_ILOG2_U64 bool default n +config ARCH_SUPPORTS_OPROFILE + bool + default y if !MIPS_MT_SMTC + config GENERIC_FIND_NEXT_BIT bool default y diff --git a/kernel/Kconfig.instrumentation b/kernel/Kconfig.instrumentation index 2ea1e34..12a9f74 100644 --- a/kernel/Kconfig.instrumentation +++ b/kernel/Kconfig.instrumentation @@ -21,7 +21,7 @@ config PROFILING config OPROFILE tristate "OProfile system profiling (EXPERIMENTAL)" depends on PROFILING - depends on (ALPHA || ARM || BLACKFIN || X86_32 || IA64 || M32R || MIPS || PARISC || PPC || S390 || SUPERH || SPARC || X86_64) && !UML + depends on (ARCH_SUPPORTS_OPROFILE || ALPHA || ARM || BLACKFIN || X86_32 || IA64 || M32R || PARISC || PPC || S390 || SUPERH || SPARC || X86_64) && !UML help OProfile is a profiling system capable of profiling the whole system, include the kernel, kernel modules, libraries, From nathan_eggan@live.com Thu Dec 6 17:11:54 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 06 Dec 2007 17:12:03 +0000 (GMT) Received: from blu139-omc1-s5.blu139.hotmail.com ([65.55.175.145]:43675 "EHLO blu139-omc1-s5.blu139.hotmail.com") by ftp.linux-mips.org with ESMTP id S20027146AbXLFRLy convert rfc822-to-8bit (ORCPT ); Thu, 6 Dec 2007 17:11:54 +0000 Received: from BLU127-W21 ([65.55.162.181]) by blu139-omc1-s5.blu139.hotmail.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 6 Dec 2007 09:11:26 -0800 Message-ID: X-Originating-IP: [157.185.36.161] From: Nathan Eggan To: linux-mips mailing list Subject: Re: Bug in Au1x00 UART or USB drivers for 2.6 kernels? Date: Thu, 6 Dec 2007 17:11:26 +0000 Importance: Normal In-Reply-To: <20071206165100.GP2391@dusktilldawn.nl> References: <20071206165100.GP2391@dusktilldawn.nl> Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 8BIT MIME-Version: 1.0 X-OriginalArrivalTime: 06 Dec 2007 17:11:26.0659 (UTC) FILETIME=[090C0130:01C8382B] Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 17721 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: nathan_eggan@live.com Precedence: bulk X-list: linux-mips > > ---------------------------------------- > > Date: Thu, 6 Dec 2007 17:51:00 +0100 > > From: freddy@dusktilldawn.nl > > To: nathan_eggan@live.com > > CC: linux-mips@linux-mips.org > > Subject: Re: Bug in Au1x00 UART or USB drivers for 2.6 kernels? > > > > Hi Nathan, > > > > On Thu, Dec 06, 2007 at 04:41:23PM +0000, Nathan Eggan wrote: > > > Can anyone see this? > > > > Yes, your message came through clearly. > > > > And to reply a little bit more on topic. I had also some strange > > serial trouble with 2.6.16, but it dissapeared when I used > > 2.6.23.9. The trouble I had was using 115200bps and for some strange > > reason bytes would be missing on one of the interfaces. I had no > > trouble on ttyS2, but ttyS0 would. Strange, but using 2.6.23.9 I > > did not experience the same problems. I did not investigate the > > real cause, but just wanted to let you know. > > > > > > -- > > $ cat ~/.signature > > Freddy Spierenburg http://freddy.snarl.nl/ > > GnuPG: 0x7941D1E1=C948 5851 26D2 FA5C 39F1 E588 6F17 FD5D 7941 D1E1 > > $ # Please read http://www.ietf.org/rfc/rfc2015.txt before complain! > > > Thanks Freddy! It's good to hear you folks can see this. (I hope you can see this response. M$'s crappy reply has converted all the original text to HTML escaped charactes. :( ) > > I was reading up on the latest kernel changes you folks are implementing, and I noticed that new IRQ handlers are being coded into 2.6.23 and 2.6.24. So, perhaps that's the resolution that's required. I've been in the process of pulling down the latest kernel source and getting it up and running; so perhaps that'll fix everything for me. > > Thanks again. > Nate > _________________________________________________________________ > Connect and share in new ways with Windows Live. > http://www.windowslive.com/connect.html?ocid=TXT_TAGLM_Wave2_newways_112007 _________________________________________________________________ You keep typing, we keep giving. Download Messenger and join the i’m Initiative now. http://im.live.com/messenger/im/home/?source=TAGLM From sshtylyov@ru.mvista.com Thu Dec 6 17:56:19 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 06 Dec 2007 17:56:28 +0000 (GMT) Received: from rtsoft3.corbina.net ([85.21.88.6]:1318 "EHLO buildserver.ru.mvista.com") by ftp.linux-mips.org with ESMTP id S20027331AbXLFR4T (ORCPT ); Thu, 6 Dec 2007 17:56:19 +0000 Received: from wasted.dev.rtsoft.ru (unknown [10.150.0.9]) by buildserver.ru.mvista.com (Postfix) with ESMTP id B50508810; Thu, 6 Dec 2007 22:55:47 +0400 (SAMT) From: Sergei Shtylyov Organization: MontaVista Software Inc. To: ralf@linux-mips.org Subject: [PATCH] Alchemy: fix PCI resource conflict Date: Thu, 6 Dec 2007 20:56:06 +0300 User-Agent: KMail/1.5 Cc: linux-mips@linux-mips.org MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200712062056.06326.sshtylyov@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: 17722 X-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 ... by getting the PCI resources back into the 32-bit range -- there's no need therefore for CONFIG_RESOURCES_64BIT either. This makes Alchemy PCI work again while currently the kernel skips the bus scan. Signed-off-by: Sergei Shtylyov arch/mips/au1000/Kconfig | 9 --------- arch/mips/au1000/common/pci.c | 8 ++++---- include/asm-mips/mach-au1x00/au1000.h | 9 +++++---- 3 files changed, 9 insertions(+), 17 deletions(-) Index: linux-2.6/arch/mips/au1000/Kconfig =================================================================== --- linux-2.6.orig/arch/mips/au1000/Kconfig +++ linux-2.6/arch/mips/au1000/Kconfig @@ -7,7 +7,6 @@ config MIPS_MTX1 bool "4G Systems MTX-1 board" select DMA_NONCOHERENT select HW_HAS_PCI - select RESOURCES_64BIT if PCI select SOC_AU1500 select SYS_SUPPORTS_LITTLE_ENDIAN @@ -22,7 +21,6 @@ config MIPS_DB1000 select SOC_AU1000 select DMA_NONCOHERENT select HW_HAS_PCI - select RESOURCES_64BIT if PCI select SYS_SUPPORTS_LITTLE_ENDIAN config MIPS_DB1100 @@ -44,7 +42,6 @@ config MIPS_DB1500 select DMA_NONCOHERENT select HW_HAS_PCI select MIPS_DISABLE_OBSOLETE_IDE - select RESOURCES_64BIT if PCI select SYS_SUPPORTS_BIG_ENDIAN select SYS_SUPPORTS_LITTLE_ENDIAN @@ -54,7 +51,6 @@ config MIPS_DB1550 select HW_HAS_PCI select DMA_NONCOHERENT select MIPS_DISABLE_OBSOLETE_IDE - select RESOURCES_64BIT if PCI select SYS_SUPPORTS_LITTLE_ENDIAN config MIPS_MIRAGE @@ -68,7 +64,6 @@ config MIPS_PB1000 select SOC_AU1000 select DMA_NONCOHERENT select HW_HAS_PCI - select RESOURCES_64BIT if PCI select SWAP_IO_SPACE select SYS_SUPPORTS_LITTLE_ENDIAN @@ -77,7 +72,6 @@ config MIPS_PB1100 select SOC_AU1100 select DMA_NONCOHERENT select HW_HAS_PCI - select RESOURCES_64BIT if PCI select SWAP_IO_SPACE select SYS_SUPPORTS_LITTLE_ENDIAN @@ -86,7 +80,6 @@ config MIPS_PB1200 select SOC_AU1200 select DMA_NONCOHERENT select MIPS_DISABLE_OBSOLETE_IDE - select RESOURCES_64BIT if PCI select SYS_SUPPORTS_LITTLE_ENDIAN config MIPS_PB1500 @@ -94,7 +87,6 @@ config MIPS_PB1500 select SOC_AU1500 select DMA_NONCOHERENT select HW_HAS_PCI - select RESOURCES_64BIT if PCI select SYS_SUPPORTS_LITTLE_ENDIAN config MIPS_PB1550 @@ -103,7 +95,6 @@ config MIPS_PB1550 select DMA_NONCOHERENT select HW_HAS_PCI select MIPS_DISABLE_OBSOLETE_IDE - select RESOURCES_64BIT if PCI select SYS_SUPPORTS_LITTLE_ENDIAN config MIPS_XXS1500 Index: linux-2.6/arch/mips/au1000/common/pci.c =================================================================== --- linux-2.6.orig/arch/mips/au1000/common/pci.c +++ linux-2.6/arch/mips/au1000/common/pci.c @@ -39,15 +39,15 @@ /* TBD */ static struct resource pci_io_resource = { - .start = (resource_size_t)PCI_IO_START, - .end = (resource_size_t)PCI_IO_END, + .start = PCI_IO_START, + .end = PCI_IO_END, .name = "PCI IO space", .flags = IORESOURCE_IO }; static struct resource pci_mem_resource = { - .start = (resource_size_t)PCI_MEM_START, - .end = (resource_size_t)PCI_MEM_END, + .start = PCI_MEM_START, + .end = PCI_MEM_END, .name = "PCI memory space", .flags = IORESOURCE_MEM }; Index: linux-2.6/include/asm-mips/mach-au1x00/au1000.h =================================================================== --- linux-2.6.orig/include/asm-mips/mach-au1x00/au1000.h +++ linux-2.6/include/asm-mips/mach-au1x00/au1000.h @@ -1680,10 +1680,11 @@ enum soc_au1200_ints { #define Au1500_PCI_MEM_START 0x440000000ULL #define Au1500_PCI_MEM_END 0x44FFFFFFFULL -#define PCI_IO_START (Au1500_PCI_IO_START + 0x1000) -#define PCI_IO_END (Au1500_PCI_IO_END) -#define PCI_MEM_START (Au1500_PCI_MEM_START) -#define PCI_MEM_END (Au1500_PCI_MEM_END) +#define PCI_IO_START (u32)(Au1500_PCI_IO_START + 0x1000) +#define PCI_IO_END (u32) Au1500_PCI_IO_END +#define PCI_MEM_START (u32) Au1500_PCI_MEM_START +#define PCI_MEM_END (u32) Au1500_PCI_MEM_END + #define PCI_FIRST_DEVFN (0<<3) #define PCI_LAST_DEVFN (19<<3) From ralf@linux-mips.org Thu Dec 6 18:27:12 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 06 Dec 2007 18:27:14 +0000 (GMT) Received: from localhost.localdomain ([127.0.0.1]:27071 "EHLO dl5rb.ham-radio-op.net") by ftp.linux-mips.org with ESMTP id S20026788AbXLFS1M (ORCPT ); Thu, 6 Dec 2007 18:27:12 +0000 Received: from denk.linux-mips.net (denk.linux-mips.net [127.0.0.1]) by dl5rb.ham-radio-op.net (8.14.1/8.13.8) with ESMTP id lB6IQehZ026729; Thu, 6 Dec 2007 18:26:40 GMT Received: (from ralf@localhost) by denk.linux-mips.net (8.14.1/8.14.1/Submit) id lB6IQdNx026728; Thu, 6 Dec 2007 18:26:39 GMT Date: Thu, 6 Dec 2007 18:26:39 +0000 From: Ralf Baechle To: Sergei Shtylyov Cc: linux-mips@linux-mips.org Subject: Re: [PATCH] Alchemy: fix PCI resource conflict Message-ID: <20071206182639.GB24263@linux-mips.org> References: <200712062056.06326.sshtylyov@ru.mvista.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200712062056.06326.sshtylyov@ru.mvista.com> User-Agent: Mutt/1.5.17 (2007-11-01) Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 17723 X-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 06, 2007 at 08:56:06PM +0300, Sergei Shtylyov wrote: > From: Sergei Shtylyov > Date: Thu, 6 Dec 2007 20:56:06 +0300 > To: ralf@linux-mips.org > Cc: linux-mips@linux-mips.org > Subject: [PATCH] Alchemy: fix PCI resource conflict > Content-Type: text/plain; > charset="us-ascii" > > ... by getting the PCI resources back into the 32-bit range -- there's no need > therefore for CONFIG_RESOURCES_64BIT either. This makes Alchemy PCI work again > while currently the kernel skips the bus scan. So now you're using the numeric overflow to get things to "work"? Ralf From sshtylyov@ru.mvista.com Thu Dec 6 18:33:36 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 06 Dec 2007 18:33:45 +0000 (GMT) Received: from h155.mvista.com ([63.81.120.155]:7223 "EHLO imap.sh.mvista.com") by ftp.linux-mips.org with ESMTP id S20027623AbXLFSdg (ORCPT ); Thu, 6 Dec 2007 18:33:36 +0000 Received: from [192.168.1.234] (unknown [10.150.0.9]) by imap.sh.mvista.com (Postfix) with ESMTP id EE6243ECD; Thu, 6 Dec 2007 10:33:33 -0800 (PST) Message-ID: <4758408F.6040603@ru.mvista.com> Date: Thu, 06 Dec 2007 21:33:51 +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: linux-mips@linux-mips.org Subject: Re: [PATCH] Alchemy: fix PCI resource conflict References: <200712062056.06326.sshtylyov@ru.mvista.com> <20071206182639.GB24263@linux-mips.org> In-Reply-To: <20071206182639.GB24263@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: 17724 X-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: >>From: Sergei Shtylyov >>Date: Thu, 6 Dec 2007 20:56:06 +0300 >>To: ralf@linux-mips.org >>Cc: linux-mips@linux-mips.org >>Subject: [PATCH] Alchemy: fix PCI resource conflict >>Content-Type: text/plain; >> charset="us-ascii" >>... by getting the PCI resources back into the 32-bit range -- there's no need >>therefore for CONFIG_RESOURCES_64BIT either. This makes Alchemy PCI work again >>while currently the kernel skips the bus scan. > So now you're using the numeric overflow to get things to "work"? Kinda. :-) Note that it was used in non-PCI case anyway. > Ralf WBR, Sergei From nathan_eggan@live.com Fri Dec 7 00:01:12 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 07 Dec 2007 00:01:20 +0000 (GMT) Received: from blu139-omc1-s10.blu139.hotmail.com ([65.55.175.150]:38923 "EHLO blu139-omc1-s10.blu139.hotmail.com") by ftp.linux-mips.org with ESMTP id S20030868AbXLGABM convert rfc822-to-8bit (ORCPT ); Fri, 7 Dec 2007 00:01:12 +0000 Received: from BLU127-W9 ([65.55.162.182]) by blu139-omc1-s10.blu139.hotmail.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 6 Dec 2007 16:00:44 -0800 Message-ID: X-Originating-IP: [157.185.36.161] From: Nathan Eggan To: linux-mips mailing list Subject: Re: Bug in Au1x00 UART or USB drivers for 2.6 kernels? Date: Fri, 7 Dec 2007 00:00:44 +0000 Importance: Normal Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 8BIT MIME-Version: 1.0 X-OriginalArrivalTime: 07 Dec 2007 00:00:44.0561 (UTC) FILETIME=[36B27810:01C83864] Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 17725 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: nathan_eggan@live.com Precedence: bulk X-list: linux-mips A'ight... I just finished pulling down a copy of the Linux-mips kernel 2.6.23.9 and building it for my DBAu1500. I was hoping this would fix the issue I'm experiencing with the serial ports and the USB bus. (For those that didn't catch the previous emails, I'm suffering byte substitution in a very regular pattern on the Au1500's UARTs when I put activity on the USB bus.) Unfortunately, the new kernel appears to have no effect. :( It performs the same as the previous. For the record, my tested setup was: - Linux 2.6.23 with the MIPS patches - Busybox 1.7.3 (doubt this is relevant) - compiled with uClibc-0.9.28 & gcc-3.4.5 (this probably isn't relevant either) All the tests I've discussed to date were down with the test code previously included in this thread, and the serial port was set for 115,200bps 8-N-1. (I've heard the 115k number can be taboo for some unknown reason, but we really need the speed on the UART. :( (It's already slow enough!) So, I'm not sure too many folks would be happy if I halve it 56k to try to make it work. A few other notes: - As previously stated, a 2.4.26 kernel I tried worked fine; so this looks to be a 2.6 kernel issue. (I've now tried 2.6.17, 2.6.21, and 2.6.23.9 and all have the same issue.) - I also tried using an FTDI USB-to-serial dongle and experienced NO errors. So, this is clearly an interplay issue between the UART and the USB bus. Any other others? Thanks again! Nate _________________________________________________________________ Put your friends on the big screen with Windows Vista® + Windows Live™. http://www.microsoft.com/windows/shop/specialoffers.mspx?ocid=TXT_TAGLM_CPC_MediaCtr_bigscreen_102007 From ralf@linux-mips.org Fri Dec 7 11:37:58 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 07 Dec 2007 11:38:01 +0000 (GMT) Received: from localhost.localdomain ([127.0.0.1]:19932 "EHLO dl5rb.ham-radio-op.net") by ftp.linux-mips.org with ESMTP id S20031765AbXLGLh6 (ORCPT ); Fri, 7 Dec 2007 11:37:58 +0000 Received: from denk.linux-mips.net (denk.linux-mips.net [127.0.0.1]) by dl5rb.ham-radio-op.net (8.14.1/8.13.8) with ESMTP id lB7BbMin007612; Fri, 7 Dec 2007 11:37:22 GMT Received: (from ralf@localhost) by denk.linux-mips.net (8.14.1/8.14.1/Submit) id lB71tKbv001304; Fri, 7 Dec 2007 01:55:20 GMT Date: Fri, 7 Dec 2007 01:55:20 +0000 From: Ralf Baechle To: Manuel Lauss Cc: linux-mips@linux-mips.org Subject: Re: [PATCH] Alchemy: Fix Au1x SD controller IRQ Message-ID: <20071207015519.GA1231@linux-mips.org> References: <20071206071156.GA20211@roarinelk.homelinux.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20071206071156.GA20211@roarinelk.homelinux.net> User-Agent: Mutt/1.5.17 (2007-11-01) Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 17726 X-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 06, 2007 at 08:11:56AM +0100, Manuel Lauss wrote: > With the introduction of MIPS_CPU_IRQ_BASE, the hardcoded IRQ number > of the au1100/au1200 SD controller(s) is no longer valid. > > Signed-off-by: Manuel Lauss Thanks, applied. Ralf From ralf@linux-mips.org Fri Dec 7 11:57:33 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 07 Dec 2007 11:57:35 +0000 (GMT) Received: from localhost.localdomain ([127.0.0.1]:55175 "EHLO dl5rb.ham-radio-op.net") by ftp.linux-mips.org with ESMTP id S20031803AbXLGL5d (ORCPT ); Fri, 7 Dec 2007 11:57:33 +0000 Received: from denk.linux-mips.net (denk.linux-mips.net [127.0.0.1]) by dl5rb.ham-radio-op.net (8.14.1/8.13.8) with ESMTP id lB7BupF2011305; Fri, 7 Dec 2007 11:56:51 GMT Received: (from ralf@localhost) by denk.linux-mips.net (8.14.1/8.14.1/Submit) id lB7BuppY011304; Fri, 7 Dec 2007 11:56:51 GMT Date: Fri, 7 Dec 2007 11:56:51 +0000 From: Ralf Baechle To: Manuel Lauss Cc: linux-mips@linux-mips.org Subject: Re: [RFC PATCH] Alchemy: Au1210/Au1250 CPU support Message-ID: <20071207115650.GB7680@linux-mips.org> References: <20071206080755.GA20485@roarinelk.homelinux.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20071206080755.GA20485@roarinelk.homelinux.net> User-Agent: Mutt/1.5.17 (2007-11-01) Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 17727 X-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 06, 2007 at 09:07:55AM +0100, Manuel Lauss wrote: > This patch adds IDs fornew Au1200 variants: Au1210 and Au1250. > They are essentially identical to the Au1200 except for the Au1210 > which has a different SoC-ID in the PRId register [bits 31:24]. > The Au1250 is a "Au1200 V0.2". > > Signed-off-by: Manuel Lauss Looks ok, queued for 2.6.25. Ralf From giuseppe@eppesuigoccas.homedns.org Fri Dec 7 15:03:15 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 07 Dec 2007 15:03:24 +0000 (GMT) Received: from host93-214-dynamic.20-79-r.retail.telecomitalia.it ([79.20.214.93]:59534 "EHLO eppesuigoccas.homedns.org") by ftp.linux-mips.org with ESMTP id S20032419AbXLGPDP (ORCPT ); Fri, 7 Dec 2007 15:03:15 +0000 Received: from eppesuig3 ([192.168.2.50]) by eppesuigoccas.homedns.org with esmtpsa (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from ) id 1J0ejO-00040T-4o for linux-mips@linux-mips.org; Fri, 07 Dec 2007 16:03:11 +0100 Subject: Unhandled kernel unaligned access in do_ade+0x2b8/0x430 From: Giuseppe Sacco To: linux-mips@linux-mips.org Content-Type: text/plain Date: Fri, 07 Dec 2007 16:03:37 +0100 Message-Id: <1197039817.5979.5.camel@scarafaggio> Mime-Version: 1.0 X-Mailer: Evolution 2.10.3 Content-Transfer-Encoding: 7bit Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 17728 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: giuseppe@eppesuigoccas.homedns.org Precedence: bulk X-list: linux-mips Does anyone already happenend to see this problem? Unhandled kernel unaligned access[#1] Cpu 0 [...] Status: 9401fce3 KX SX UK KERNEL EXL IE Cause : 00000010 BadVA : bfffff000fe8fa2a PrId : 00002321 [...] Process swapper (pid: 0, threadinfo=ffffffff8037c000, task=ffffffff803802f0) [...] Call Trace: [] do_ade+0x2b8/0x430 [] handle_adel_int+0x34/0x48 Code: 00431024 5440ffae de0201000 <89230000> 99230003 24020000 1440ffe7 00051402 08003854 From kaz@zeugmasystems.com Fri Dec 7 21:57:26 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 07 Dec 2007 21:57:34 +0000 (GMT) Received: from mail.zeugmasystems.com ([70.79.96.174]:52343 "EHLO zeugmasystems.com") by ftp.linux-mips.org with ESMTP id S20022438AbXLGV50 convert rfc822-to-8bit (ORCPT ); Fri, 7 Dec 2007 21:57:26 +0000 Content-class: urn:content-classes:message Subject: SiByte 1480 & Branch Likely instructions? MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 8BIT Date: Fri, 7 Dec 2007 13:54:30 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: SiByte 1480 & Branch Likely instructions? Thread-Index: Acg5G75nLX9OzGDLQf6iiyb7ttVemw== 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: 17729 X-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 Hi All, Not really a kernel-related question. I've discovered that GCC 4.1.1 (which I'm not using for kernel compiling, but user space) generates branch likely instructions by default, even though the documentation says that their use is off by default for MIPS32 and MIPS64, because they are considered deprecated. They are documented as obsolete for the Broadcom chips I am working with. I'm investigating a software anomaly which looks like might be caused by failure to annul the delay slot of a branch-likely in the fall-through case. In parallel with writing some tests, I thought I would ask whether anyone happens know whether or not these instructions are known to actually work correctly on the SB1480 silicon (and perhaps any additional details, like what revisions, etc)? Thanks From kaz@zeugmasystems.com Fri Dec 7 23:40:05 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 07 Dec 2007 23:40:13 +0000 (GMT) Received: from mail.zeugmasystems.com ([192.139.122.66]:17454 "EHLO zeugmasystems.com") by ftp.linux-mips.org with ESMTP id S20024047AbXLGXkF convert rfc822-to-8bit (ORCPT ); Fri, 7 Dec 2007 23:40:05 +0000 Content-class: urn:content-classes:message Subject: RE: SiByte 1480 & Branch Likely instructions? MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 8BIT Date: Fri, 7 Dec 2007 15:39:57 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: SiByte 1480 & Branch Likely instructions? Thread-Index: Acg5G75nLX9OzGDLQf6iiyb7ttVemwADrN7Q 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: 17730 X-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 Kaz wrote: > Hi All, > > Not really a kernel-related question. I've discovered that GCC 4.1.1 > (which I'm not using for kernel compiling, but user space) generates > branch likely instructions by default, even though the documentation > says that their use is off by default for MIPS32 and MIPS64, because That's because the compiler is not configured correctly. The default CPU string "from-abi" ends up being used, and so the target ISA is MIPS III. > In parallel with writing some tests, I thought I would ask whether > anyone happens know whether or not these instructions are known to > actually work correctly on the SB1480 silicon (and perhaps any > additional details, like what revisions, etc)? A basic sanity test does find bnezl working. #include #include static int branch_likely_works(void) { int one = 1; int result; __asm__ __volatile__ (" .set push\n" " .set noreorder\n" "1: move %0, $0\n" " bnezl %0, 1b\n" " lw %0, %1\n" " .set pop\n" : "=r" (result) : "m" (one)); return result == 0; } int main(void) { if (branch_likely_works()) { puts("branch-likely instruction bnezl correctly annuls delay slot"); return 0; } puts("branch-likely instruction bnezl fails to annul delay slot"); return EXIT_FAILURE; } From rsandifo@nildram.co.uk Sat Dec 8 17:52:08 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Sat, 08 Dec 2007 17:52:19 +0000 (GMT) Received: from smtp.nildram.co.uk ([195.112.4.54]:24338 "EHLO smtp.nildram.co.uk") by ftp.linux-mips.org with ESMTP id S20026287AbXLHRwI (ORCPT ); Sat, 8 Dec 2007 17:52:08 +0000 Received: from firetop.home (85-211-134-127.dyn.gotadsl.co.uk [85.211.134.127]) by smtp.nildram.co.uk (Postfix) with ESMTP id 5B63B2B5F05; Sat, 8 Dec 2007 17:52:04 +0000 (GMT) Received: from richard by firetop.home with local (Exim 4.63) (envelope-from ) id 1J13qR-0006pZ-0X; Sat, 08 Dec 2007 17:52:07 +0000 From: Richard Sandiford To: tsbogend@alpha.franken.de (Thomas Bogendoerfer) Mail-Followup-To: tsbogend@alpha.franken.de (Thomas Bogendoerfer),Kumba , Ralf Baechle , linux-mips@linux-mips.org, rsandifo@nildram.co.uk Cc: Kumba , Ralf Baechle , linux-mips@linux-mips.org Subject: Re: [UPDATED PATCH] IP28 support References: <20071129095442.C6679C2B39@solo.franken.de> <20071129130130.GA14655@linux-mips.org> <4756422D.6070305@gentoo.org> <20071205093938.GA6848@alpha.franken.de> Date: Sat, 08 Dec 2007 17:52:06 +0000 In-Reply-To: <20071205093938.GA6848@alpha.franken.de> (Thomas Bogendoerfer's message of "Wed\, 5 Dec 2007 10\:39\:38 +0100") Message-ID: <87ejdx6pmh.fsf@firetop.home> User-Agent: Gnus/5.110006 (No Gnus v0.6) Emacs/21.4 (gnu/linux) 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: 17731 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: rsandifo@nildram.co.uk Precedence: bulk X-list: linux-mips tsbogend@alpha.franken.de (Thomas Bogendoerfer) writes: > On Wed, Dec 05, 2007 at 01:16:13AM -0500, Kumba wrote: >> I've been out of it lately -- did the gcc side of things ever make it in, >> or do we need to go push on that some more? > > We need push on that. Looking at > > http://gcc.gnu.org/ml/gcc-patches/2006-04/msg00291.html > > there seems to be a missing understanding, why the cache > barriers are needed. Heh. Quite probably. Which bit of my message don't you agree with? FWIW, I was going off the original message as posted here: http://gcc.gnu.org/ml/gcc-patches/2006-03/msg00090.html The explanation of the chosen workaround seemed to be left to this bit of http://mail-index.netbsd.org/port-sgimips/2000/06/29/0006.html: All is well with coherent IO systems. On non coherent systems like Indigo2 and O2 this creates a race condition with DMA reads (IO->mem) where a stale cached data can be written back over the DMAed data. R10K Indigo2: This issue was figured out late the the R10K I2 design cycle. The problem was fixed by modifying the compiler and assembler to issue a cache barrier instruction to address 0(sp) as the first instruction in basic blocks that contain stores to registers other than $0 and $sp. and from a compiler point of view, it would be nice to know _why_ that was a reasonable workaround. What I was really looking for was: (a) a short description of the problem, (b) a list of assumptions that the compiler is going to make when working around the problem and (c) a description of what said workarounds are. My understanding of (a) is that, if a store is speculatively executed, the target of the store might be fetched into cache and marked dirty. We therefore want to avoid the speculative execution of stores if: (1) the addressed memory might be the target of a later DMA operation. If the DMA completes before the "dirty" cache line is flushed, the cached data might overwrite the DMAed data. (2) the addressed memory might be to IO-mapped cached memory (usually through the address being garbage). The cached data will be written back to the IO region when flushed. We also want to avoid speculative execution of loads if: (3) the addressed memory might be to load-sensitive IO-mapped cached memory (usually through the address being garbage). The hardware would "see" loads that aren't actually executed. Is that vaguely accurate? I tried to piece together (b) by asking questions in the reviews, but it would be great to have a single explanation. The idea behind (c) is simple, of course: we insert a cache barrier before the potentially-problematic stores (and, for certain configurations, loads, although the original gcc patch had the associated macro hard-wired to false). The key is explaining how, from a compiler internals viewpoint, we decide what is "potentially- problematic". This ties in with the assumptions for (b). I'm sure my attempt at (a) above can be improved upon even if it's vaguely right. But... > I guess the patch could be improved > by pointing directly to the errata section of the R10k > user manual. ...I think an integrated explanation of (a), (b) and (c) above would be better than quoting large parts of the processor manual. The processor manual is aimed at a much broader audience and has a lot of superfluous info. It also doesn't explain what _our_ assumptions are and what our chosen workaround is. Richard From ralf@linux-mips.org Sat Dec 8 18:31:24 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Sat, 08 Dec 2007 18:31:26 +0000 (GMT) Received: from localhost.localdomain ([127.0.0.1]:46229 "EHLO dl5rb.ham-radio-op.net") by ftp.linux-mips.org with ESMTP id S20026990AbXLHSbY (ORCPT ); Sat, 8 Dec 2007 18:31:24 +0000 Received: from denk.linux-mips.net (denk.linux-mips.net [127.0.0.1]) by dl5rb.ham-radio-op.net (8.14.1/8.13.8) with ESMTP id lB8IVM5G029453; Sat, 8 Dec 2007 18:31:22 GMT Received: (from ralf@localhost) by denk.linux-mips.net (8.14.1/8.14.1/Submit) id lB8G5xED016287; Sat, 8 Dec 2007 16:05:59 GMT Date: Sat, 8 Dec 2007 16:05:59 +0000 From: Ralf Baechle To: Thomas Bogendoerfer Cc: linux-mips@linux-mips.org Subject: Re: [PATCH] SNI_RM: EISA support for A20R/RM200 Message-ID: <20071208160559.GB3361@linux-mips.org> References: <20071130214749.7E597C2EAB@solo.franken.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20071130214749.7E597C2EAB@solo.franken.de> User-Agent: Mutt/1.5.17 (2007-11-01) Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 17732 X-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, Nov 30, 2007 at 10:47:49PM +0100, Thomas Bogendoerfer wrote: > This patch adds EISA support for non PCI RMs (RM200 and RM400-xxx). The > major part is the splitting of the EISA and onboard ISA of the RM200, > which makes the EISA bus on the RM200 look like on other RMs. > > Signed-off-by: Thomas Bogendoerfer Queued for 2.6.25. Thanks, Ralf From ralf@linux-mips.org Sat Dec 8 18:31:46 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Sat, 08 Dec 2007 18:31:49 +0000 (GMT) Received: from localhost.localdomain ([127.0.0.1]:46997 "EHLO dl5rb.ham-radio-op.net") by ftp.linux-mips.org with ESMTP id S20026985AbXLHSb0 (ORCPT ); Sat, 8 Dec 2007 18:31:26 +0000 Received: from denk.linux-mips.net (denk.linux-mips.net [127.0.0.1]) by dl5rb.ham-radio-op.net (8.14.1/8.13.8) with ESMTP id lB8IVM5I029453; Sat, 8 Dec 2007 18:31:23 GMT Received: (from ralf@localhost) by denk.linux-mips.net (8.14.1/8.14.1/Submit) id lB8G4od7015182; Sat, 8 Dec 2007 16:04:50 GMT Date: Sat, 8 Dec 2007 16:04:49 +0000 From: Ralf Baechle To: Thomas Bogendoerfer Cc: linux-scsi@vger.kernel.org, linux-mips@linux-mips.org, James.Bottomley@HansenPartnership.com Subject: Re: [UPDATED PATCH] SGIWD93: use cached memory access to make driver work on IP28 Message-ID: <20071208160449.GA3361@linux-mips.org> References: <20071202103309.6A926C2EB4@solo.franken.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20071202103309.6A926C2EB4@solo.franken.de> User-Agent: Mutt/1.5.17 (2007-11-01) Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 17733 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: ralf@linux-mips.org Precedence: bulk X-list: linux-mips On Sun, Dec 02, 2007 at 11:33:09AM +0100, Thomas Bogendoerfer wrote: > SGI IP28 machines would need special treatment (enable adding addtional > wait states) when accessing memory uncached. To avoid this pain I > changed the driver to use only cached access to memory. > > Signed-off-by: Thomas Bogendoerfer Acked-by: Ralf Baechle The machine really is as insane as Thomas makes it sound. Actually even more so. Ralf From ralf@linux-mips.org Sat Dec 8 19:24:10 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Sat, 08 Dec 2007 19:24:13 +0000 (GMT) Received: from localhost.localdomain ([127.0.0.1]:52933 "EHLO dl5rb.ham-radio-op.net") by ftp.linux-mips.org with ESMTP id S20027576AbXLHTYK (ORCPT ); Sat, 8 Dec 2007 19:24:10 +0000 Received: from denk.linux-mips.net (denk.linux-mips.net [127.0.0.1]) by dl5rb.ham-radio-op.net (8.14.1/8.13.8) with ESMTP id lB8JO7e8029894; Sat, 8 Dec 2007 19:24:07 GMT Received: (from ralf@localhost) by denk.linux-mips.net (8.14.1/8.14.1/Submit) id lB8JO6uD029893; Sat, 8 Dec 2007 19:24:06 GMT Date: Sat, 8 Dec 2007 19:24:05 +0000 From: Ralf Baechle To: Thomas Bogendoerfer , Kumba , linux-mips@linux-mips.org, rsandifo@nildram.co.uk Subject: Re: [UPDATED PATCH] IP28 support Message-ID: <20071208192405.GA29208@linux-mips.org> References: <20071129095442.C6679C2B39@solo.franken.de> <20071129130130.GA14655@linux-mips.org> <4756422D.6070305@gentoo.org> <20071205093938.GA6848@alpha.franken.de> <87ejdx6pmh.fsf@firetop.home> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <87ejdx6pmh.fsf@firetop.home> User-Agent: Mutt/1.5.17 (2007-11-01) Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 17734 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: ralf@linux-mips.org Precedence: bulk X-list: linux-mips On Sat, Dec 08, 2007 at 05:52:06PM +0000, Richard Sandiford wrote: > tsbogend@alpha.franken.de (Thomas Bogendoerfer) writes: > > On Wed, Dec 05, 2007 at 01:16:13AM -0500, Kumba wrote: > >> I've been out of it lately -- did the gcc side of things ever make it in, > >> or do we need to go push on that some more? > > > > We need push on that. Looking at > > > > http://gcc.gnu.org/ml/gcc-patches/2006-04/msg00291.html > > > > there seems to be a missing understanding, why the cache > > barriers are needed. > > Heh. Quite probably. Which bit of my message don't you agree with? > > FWIW, I was going off the original message as posted here: > > http://gcc.gnu.org/ml/gcc-patches/2006-03/msg00090.html > > The explanation of the chosen workaround seemed to be left to this bit > of http://mail-index.netbsd.org/port-sgimips/2000/06/29/0006.html: > > All is well with coherent IO systems. On non coherent > systems like Indigo2 and O2 this creates a race > condition with DMA reads (IO->mem) where a stale > cached data can be written back over the DMAed data. It's not a race condition. > R10K Indigo2: > > This issue was figured out late the the R10K I2 > design cycle. The problem was fixed by modifying > the compiler and assembler to issue a cache barrier > instruction to address 0(sp) as the first instruction > in basic blocks that contain stores to registers > other than $0 and $sp. > > and from a compiler point of view, it would be nice to know > _why_ that was a reasonable workaround. What I was really > looking for was: (a) a short description of the problem, > (b) a list of assumptions that the compiler is going to > make when working around the problem and (c) a description > of what said workarounds are. > > My understanding of (a) is that, if a store is speculatively executed, > the target of the store might be fetched into cache and marked dirty. > We therefore want to avoid the speculative execution of stores if: > > (1) the addressed memory might be the target of a later DMA operation. > If the DMA completes before the "dirty" cache line is flushed, > the cached data might overwrite the DMAed data. > > (2) the addressed memory might be to IO-mapped cached memory > (usually through the address being garbage). The cached > data will be written back to the IO region when flushed. > > We also want to avoid speculative execution of loads if: > > (3) the addressed memory might be to load-sensitive IO-mapped cached > memory (usually through the address being garbage). The hardware > would "see" loads that aren't actually executed. > > Is that vaguely accurate? Yes. > I tried to piece together (b) by asking questions in the reviews, > but it would be great to have a single explanation. > > The idea behind (c) is simple, of course: we insert a cache barrier > before the potentially-problematic stores (and, for certain > configurations, loads, although the original gcc patch had the > associated macro hard-wired to false). The key is explaining how, > from a compiler internals viewpoint, we decide what is "potentially- > problematic". This ties in with the assumptions for (b). The principle for the compiler is a store is problematic unless proven otherwise. A speculative store relative to the stack pointer, frame pointer or global pointer for example is harmless. > I'm sure my attempt at (a) above can be improved upon even if it's > vaguely right. But... > > > I guess the patch could be improved > > by pointing directly to the errata section of the R10k > > user manual. > > ...I think an integrated explanation of (a), (b) and (c) above > would be better than quoting large parts of the processor manual. > The processor manual is aimed at a much broader audience and has > a lot of superfluous info. It also doesn't explain what _our_ > assumptions are and what our chosen workaround is. There are two R10000 manuals, one from SGI and one from NEC and they're differing quite a bit on the workaround. The SGI one gives a large number of suggestions on how to work around the behaviour some of which even require hardware asistance by on the system board. A long time ago Bill Earl, one of the engineers at SGI responsible for the workaround emailed me this explanation which I believe is quite reasonable: [...] The R10000 "bug" is, in a sense, a feature, in that it improves performance, and is harmless on machines with cache-coherent I/O. Specifically, on a speculative store miss (a cache miss due to a speculatively executed store instruction), the R10000 fetches the line dirty-exclusive and marks it modified, in anticipation of the store. If, however, the speculatively executed store never graduates (is never committed), the line is left dirty, even though it has not been modified. If the line happens to be part of a buffer into which data is being DMAed, a subsequent victim writeback of the dirty cache line might overwrite good data from the DMA with the obsolete data in the cache line. This means that, one way or the other, a system with non-cache-coherent I/O and an R10000 must avoid allowing the processor to perform a speculative store miss with respect to memory into which a DMA is taking place. Note that the Indigo2 and O2 have somewhat different workarounds. The Indigo2 deals with the kernel side using a special compilation mode, and the O2 deals with the kernel side using a special hardware feature plus a generalization of the solution for the user mode part of the problem. Both deal with the user mode by invalidating TLB entries for pages into which data is being transferred via DMA, so that the processor cannot resolve the virtual address, and hence cannot speculatively fetch a cache line at that address, while the DMA is in progress. The kernel side is harder, since the TLB is not used for K0SEG and XKPHYS address spaces, which is where things get complicated. [...] I should mention that the hardware assissted solution for the O2 which is implemented using an CPLD codenamed "juice" is not currently used by Linux that is it relies on the same software-only workaround as the Indigo 2 R10000. Ralf From rsandifo@nildram.co.uk Sat Dec 8 20:09:47 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Sat, 08 Dec 2007 20:09:55 +0000 (GMT) Received: from smtp.nildram.co.uk ([195.112.4.54]:36104 "EHLO smtp.nildram.co.uk") by ftp.linux-mips.org with ESMTP id S20029019AbXLHUJr (ORCPT ); Sat, 8 Dec 2007 20:09:47 +0000 Received: from firetop.home (85-211-134-127.dyn.gotadsl.co.uk [85.211.134.127]) by smtp.nildram.co.uk (Postfix) with ESMTP id 77C1E2B7355; Sat, 8 Dec 2007 20:09:28 +0000 (GMT) Received: from richard by firetop.home with local (Exim 4.63) (envelope-from ) id 1J15zP-0008DO-Gp; Sat, 08 Dec 2007 20:09:31 +0000 From: Richard Sandiford To: Ralf Baechle Mail-Followup-To: Ralf Baechle ,Thomas Bogendoerfer , Kumba , linux-mips@linux-mips.org, rsandifo@nildram.co.uk Cc: Thomas Bogendoerfer , Kumba , linux-mips@linux-mips.org Subject: Re: [UPDATED PATCH] IP28 support References: <20071129095442.C6679C2B39@solo.franken.de> <20071129130130.GA14655@linux-mips.org> <4756422D.6070305@gentoo.org> <20071205093938.GA6848@alpha.franken.de> <87ejdx6pmh.fsf@firetop.home> <20071208192405.GA29208@linux-mips.org> Date: Sat, 08 Dec 2007 20:09:31 +0000 In-Reply-To: <20071208192405.GA29208@linux-mips.org> (Ralf Baechle's message of "Sat\, 8 Dec 2007 19\:24\:05 +0000") Message-ID: <871w9x6j9g.fsf@firetop.home> User-Agent: Gnus/5.110006 (No Gnus v0.6) Emacs/21.4 (gnu/linux) 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: 17735 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: rsandifo@nildram.co.uk Precedence: bulk X-list: linux-mips Ralf Baechle writes: > On Sat, Dec 08, 2007 at 05:52:06PM +0000, Richard Sandiford wrote: >> I tried to piece together (b) by asking questions in the reviews, >> but it would be great to have a single explanation. >> >> The idea behind (c) is simple, of course: we insert a cache barrier >> before the potentially-problematic stores (and, for certain >> configurations, loads, although the original gcc patch had the >> associated macro hard-wired to false). The key is explaining how, >> from a compiler internals viewpoint, we decide what is "potentially- >> problematic". This ties in with the assumptions for (b). > > The principle for the compiler is a store is problematic unless proven > otherwise. A speculative store relative to the stack pointer, frame > pointer or global pointer for example is harmless. Right. But just so we're on the same page (and I think we probably are), my point was that those rules aren't intrinsically obvious. They're based on assumptions about how the code is written. For example, it assumes there's no DMAing into stack variables. Maybe obvious, but I think it needs to be stated explicitly. Then there's the language-lawyerly code I gave to Peter on gcc-patches@: void foo (int x) { int array[1]; if (x) bar (array[0x1fff]); } This function is valid if x is never true, so we cannot assume that all accesses off the stack and frame pointers are actually in-frame. You're assuming either (i) the kernel doesn't use code like that or (ii) that "garbage" addresses in the range [$sp - 0x8000, $sp + 0x7fff] will not trigger the problem. I imagine both are reasonable assumptions, and I'm perfectly happy for us to make them. But they're the kind of assumption we need to state explicitly. Peter's patch also treated accesses to constant integer and symbolic addresses as safe. Again, this involves making assumptions about how constant integer and symbolic addresses are used, and this is a much less obvious assumption than the stack one. Again, I understand that it's a reasonable assumption to make in the linux context, but it's one we need to pin down. E.g. there must be no run-time guarding of target-specific constant integer IO-mapped addresses in cases where those addresses might trigger the problem on other systems that the same kernel image supports. Despite appearances, I'm not trying to be awkward here ;) I just think the assumptions are too loosely-defined at the moment (or at least too scattered around). It would be nice to have some self-contained description, targetted specifically at gcc and linux, that contains anything a gcc hacker or user needs to know about the gcc patch. Richard From post@pfrst.de Sat Dec 8 21:39:47 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Sat, 08 Dec 2007 21:39:56 +0000 (GMT) Received: from mail1.pearl-online.net ([62.159.194.147]:49702 "EHLO mail1.pearl-online.net") by ftp.linux-mips.org with ESMTP id S20021622AbXLHVjr (ORCPT ); Sat, 8 Dec 2007 21:39:47 +0000 Received: from SNaIlmail.Peter (unknown [77.47.48.214]) by mail1.pearl-online.net (Postfix) with ESMTP id E43FBBC74; Sat, 8 Dec 2007 22:40:15 +0100 (CET) Received: from Indigo2.Peter (Indigo2.Peter [192.168.1.28]) by SNaIlmail.Peter (8.12.6/8.12.6/Sendmail/Linux 2.0.32) with ESMTP id lB8LT2Hd001249; Sat, 8 Dec 2007 22:29:02 +0100 Received: from Indigo2.Peter (localhost [127.0.0.1]) by Indigo2.Peter (8.12.6/8.12.6/Sendmail/Linux 2.6.20-ip28) with ESMTP id lB8LP1Q1014982; Sat, 8 Dec 2007 22:25:01 +0100 Received: from localhost (pf@localhost) by Indigo2.Peter (8.12.6/8.12.6/Submit) with ESMTP id lB8LP1wo014979; Sat, 8 Dec 2007 22:25:01 +0100 X-Authentication-Warning: Indigo2.Peter: pf owned process doing -bs Date: Sat, 8 Dec 2007 22:25:01 +0100 (CET) From: peter fuerst X-X-Sender: pf@Indigo2.Peter Reply-To: post@pfrst.de To: Richard Sandiford Cc: Ralf Baechle , Thomas Bogendoerfer , Kumba , linux-mips@linux-mips.org Subject: Re: [UPDATED PATCH] IP28 support In-Reply-To: <871w9x6j9g.fsf@firetop.home> Message-ID: References: <20071129095442.C6679C2B39@solo.franken.de> <20071129130130.GA14655@linux-mips.org> <4756422D.6070305@gentoo.org> <20071205093938.GA6848@alpha.franken.de> <87ejdx6pmh.fsf@firetop.home> <20071208192405.GA29208@linux-mips.org> <871w9x6j9g.fsf@firetop.home> 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: 17736 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: post@pfrst.de Precedence: bulk X-list: linux-mips Hi! could text like this help to pin the assumptions down (from "http://gcc.gnu.org/ml/gcc-patches/2006-05/msg01446.html") ? "... What cases of $N can be exempted from this measure? - Stack-addresses and constant (static) addresses ("sd $M,symbol+n") will not be used for DMA, since DMA-buffers are allocated at runtime. - Uncached accesses will not be done speculatively, but they fall under the "constant"-case already or will not be recognized at compile-time. Besides the DMA-problem, depending on the mis-speculation path (up to four branches deep), one of the frequently reused multi-purpose registers $N will contain some "random" value, which may be a legal but invalid kernel- address (say a800000061234567), reaching the memory-controller... However, there are cases where a register $N's content is well defined, no matter what (mis-)speculation path took us to this instruction: - The stack-pointer points to the stack from kernel-initializtion on. - Constant addresses ("symbol+n") are well defined "per se". (Luckily, legal-but-invalid doesn't occur in user mode, where no cache- barriers can be used. There we get either an address-error or a TLB-miss, leaving memory/bus untouched.) ..." kind regards peter On Sat, 8 Dec 2007, Richard Sandiford wrote: > Date: Sat, 08 Dec 2007 20:09:31 +0000 > From: Richard Sandiford > To: Ralf Baechle > Cc: Thomas Bogendoerfer , Kumba , > linux-mips@linux-mips.org > Subject: Re: [UPDATED PATCH] IP28 support > > Ralf Baechle writes: > > On Sat, Dec 08, 2007 at 05:52:06PM +0000, Richard Sandiford wrote: > >> I tried to piece together (b) by asking questions in the reviews, > >> but it would be great to have a single explanation. > >> > >> The idea behind (c) is simple, of course: we insert a cache barrier > >> before the potentially-problematic stores (and, for certain > >> configurations, loads, although the original gcc patch had the > >> associated macro hard-wired to false). The key is explaining how, > >> from a compiler internals viewpoint, we decide what is "potentially- > >> problematic". This ties in with the assumptions for (b). > > > > The principle for the compiler is a store is problematic unless proven > > otherwise. A speculative store relative to the stack pointer, frame > > pointer or global pointer for example is harmless. > > Right. But just so we're on the same page (and I think we probably are), > my point was that those rules aren't intrinsically obvious. They're > based on assumptions about how the code is written. For example, > it assumes there's no DMAing into stack variables. Maybe obvious, > but I think it needs to be stated explicitly. Then there's the > language-lawyerly code I gave to Peter on gcc-patches@: > > void foo (int x) > { > int array[1]; > if (x) > bar (array[0x1fff]); > } > > This function is valid if x is never true, so we cannot assume that all > accesses off the stack and frame pointers are actually in-frame. You're > assuming either (i) the kernel doesn't use code like that or (ii) that > "garbage" addresses in the range [$sp - 0x8000, $sp + 0x7fff] will not > trigger the problem. I imagine both are reasonable assumptions, and I'm > perfectly happy for us to make them. But they're the kind of assumption > we need to state explicitly. > > Peter's patch also treated accesses to constant integer and symbolic > addresses as safe. Again, this involves making assumptions about how > constant integer and symbolic addresses are used, and this is a much > less obvious assumption than the stack one. Again, I understand that > it's a reasonable assumption to make in the linux context, but it's one > we need to pin down. E.g. there must be no run-time guarding of > target-specific constant integer IO-mapped addresses in cases where > those addresses might trigger the problem on other systems that the > same kernel image supports. > > Despite appearances, I'm not trying to be awkward here ;) I just think > the assumptions are too loosely-defined at the moment (or at least too > scattered around). It would be nice to have some self-contained > description, targetted specifically at gcc and linux, that contains > anything a gcc hacker or user needs to know about the gcc patch. > > Richard > > > From rsandifo@nildram.co.uk Sat Dec 8 23:33:06 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Sat, 08 Dec 2007 23:33:15 +0000 (GMT) Received: from smtp.nildram.co.uk ([195.112.4.54]:55559 "EHLO smtp.nildram.co.uk") by ftp.linux-mips.org with ESMTP id S20022522AbXLHXdG (ORCPT ); Sat, 8 Dec 2007 23:33:06 +0000 Received: from firetop.home (85-211-134-127.dyn.gotadsl.co.uk [85.211.134.127]) by smtp.nildram.co.uk (Postfix) with ESMTP id 35A502C9E98; Sat, 8 Dec 2007 23:24:00 +0000 (GMT) Received: from richard by firetop.home with local (Exim 4.63) (envelope-from ) id 1J191f-00010V-NA; Sat, 08 Dec 2007 23:24:03 +0000 From: Richard Sandiford To: post@pfrst.de Mail-Followup-To: post@pfrst.de,Ralf Baechle , Thomas Bogendoerfer , Kumba , linux-mips@linux-mips.org, rsandifo@nildram.co.uk Cc: Ralf Baechle , Thomas Bogendoerfer , Kumba , linux-mips@linux-mips.org Subject: Re: [UPDATED PATCH] IP28 support References: <20071129095442.C6679C2B39@solo.franken.de> <20071129130130.GA14655@linux-mips.org> <4756422D.6070305@gentoo.org> <20071205093938.GA6848@alpha.franken.de> <87ejdx6pmh.fsf@firetop.home> <20071208192405.GA29208@linux-mips.org> <871w9x6j9g.fsf@firetop.home> Date: Sat, 08 Dec 2007 23:24:03 +0000 In-Reply-To: (peter fuerst's message of "Sat\, 8 Dec 2007 22\:25\:01 +0100 \(CET\)") Message-ID: <87wsro6a98.fsf@firetop.home> User-Agent: Gnus/5.110006 (No Gnus v0.6) Emacs/21.4 (gnu/linux) 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: 17737 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: rsandifo@nildram.co.uk Precedence: bulk X-list: linux-mips peter fuerst writes: > could text like this help to pin the assumptions down (from > "http://gcc.gnu.org/ml/gcc-patches/2006-05/msg01446.html") ? > > "... > What cases of $N can be exempted from this measure? > - Stack-addresses and constant (static) addresses ("sd $M,symbol+n") will not > be used for DMA, since DMA-buffers are allocated at runtime. > - Uncached accesses will not be done speculatively, but they fall under the > "constant"-case already or will not be recognized at compile-time. > > Besides the DMA-problem, depending on the mis-speculation path (up to four > branches deep), one of the frequently reused multi-purpose registers $N > will contain some "random" value, which may be a legal but invalid kernel- > address (say a800000061234567), reaching the memory-controller... > However, there are cases where a register $N's content is well defined, no > matter what (mis-)speculation path took us to this instruction: > - The stack-pointer points to the stack from kernel-initializtion on. > - Constant addresses ("symbol+n") are well defined "per se". > (Luckily, legal-but-invalid doesn't occur in user mode, where no cache- > barriers can be used. There we get either an address-error or a TLB-miss, > leaving memory/bus untouched.) > ..." Well, the explanation of the exceptions doesn't really address the corner cases I was trying to draw attention to in the message you replied to. What about top of the stack + X? Do we guarantee that the code will never cause the compiler to generate a store to such an address, even with an always-false guard? Or do we guarantee that stores and loads to [top-of-stack, top-of-stack + 0x7fff] can be speculated safely? Do we guarantee that every store and load to a cached constant address in the kernel image will not result in a harmful IO access on any target that the image supports? Perhaps we should just turn this around slightly and instead say: what must the compiler do, and when must it do it? The reasons why aren't that important from the compiler's perspective. So if we can just phrase it as: -mr10k-cache-barrier=load-store Insert a cache barrier at the beginning of any sequentially-executed series of instructions that contains a load or store. For the purposes of this option, GCC can ignore loads and stores that it can prove: (a) access a region in the range [-0x8000 + bottom of stack frame, 0x7fff + top of stack frame]; or (b) access a link-time-constant address. Here, a ``sequentially-executed series'' is one in which calls, jumps and branches occur only as the last instruction. -mr10k-cache-barrier=store Like -mr10k-cache-barrier=load-store, but ignore all loads. -mr10k-cache-barrier=none ... And if you guys are willing to make sure that's safe, and change the kernel whenever you find instances that it isn't safe, then that should be enough. (Bear in mind that there's ongoing work to do link-time optimisation in gcc, so translation-unit separation is no real guarantee.) Richard From ralf@linux-mips.org Sun Dec 9 04:38:42 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Sun, 09 Dec 2007 04:38:44 +0000 (GMT) Received: from localhost.localdomain ([127.0.0.1]:37297 "EHLO dl5rb.ham-radio-op.net") by ftp.linux-mips.org with ESMTP id S20021932AbXLIEim (ORCPT ); Sun, 9 Dec 2007 04:38:42 +0000 Received: from denk.linux-mips.net (denk.linux-mips.net [127.0.0.1]) by dl5rb.ham-radio-op.net (8.14.1/8.13.8) with ESMTP id lB94cMt7017247; Sun, 9 Dec 2007 04:38:27 GMT Received: (from ralf@localhost) by denk.linux-mips.net (8.14.1/8.14.1/Submit) id lB94cLWp017246; Sun, 9 Dec 2007 04:38:21 GMT Date: Sun, 9 Dec 2007 04:38:21 +0000 From: Ralf Baechle To: Thomas Bogendoerfer , Kumba , linux-mips@linux-mips.org, rsandifo@nildram.co.uk Subject: Re: [UPDATED PATCH] IP28 support Message-ID: <20071209043821.GB13729@linux-mips.org> References: <20071129095442.C6679C2B39@solo.franken.de> <20071129130130.GA14655@linux-mips.org> <4756422D.6070305@gentoo.org> <20071205093938.GA6848@alpha.franken.de> <87ejdx6pmh.fsf@firetop.home> <20071208192405.GA29208@linux-mips.org> <871w9x6j9g.fsf@firetop.home> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <871w9x6j9g.fsf@firetop.home> User-Agent: Mutt/1.5.17 (2007-11-01) Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 17738 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: ralf@linux-mips.org Precedence: bulk X-list: linux-mips On Sat, Dec 08, 2007 at 08:09:31PM +0000, Richard Sandiford wrote: > Ralf Baechle writes: > > On Sat, Dec 08, 2007 at 05:52:06PM +0000, Richard Sandiford wrote: > >> I tried to piece together (b) by asking questions in the reviews, > >> but it would be great to have a single explanation. > >> > >> The idea behind (c) is simple, of course: we insert a cache barrier > >> before the potentially-problematic stores (and, for certain > >> configurations, loads, although the original gcc patch had the > >> associated macro hard-wired to false). The key is explaining how, > >> from a compiler internals viewpoint, we decide what is "potentially- > >> problematic". This ties in with the assumptions for (b). > > > > The principle for the compiler is a store is problematic unless proven > > otherwise. A speculative store relative to the stack pointer, frame > > pointer or global pointer for example is harmless. > > Right. But just so we're on the same page (and I think we probably are), > my point was that those rules aren't intrinsically obvious. They're > based on assumptions about how the code is written. For example, > it assumes there's no DMAing into stack variables. Maybe obvious, > but I think it needs to be stated explicitly. Can't harm to be explicit. Linux forbids DMA to the stack. In that past DMA to the stack has caused alot of grief for Linux ports on some architectures. > Then there's the language-lawyerly code I gave to Peter on gcc-patches@: > > void foo (int x) > { > int array[1]; > if (x) > bar (array[0x1fff]); > } > > This function is valid if x is never true, so we cannot assume that all > accesses off the stack and frame pointers are actually in-frame. You're > assuming either (i) the kernel doesn't use code like that or (ii) that > "garbage" addresses in the range [$sp - 0x8000, $sp + 0x7fff] will not > trigger the problem. I imagine both are reasonable assumptions, and I'm > perfectly happy for us to make them. But they're the kind of assumption > we need to state explicitly. Interesting test case. I've been thinking about it myself but in the end decieded to believe Peter's analysis since he's banged the head for longer to the wall about this problem that I have ;-) I'm quite but not absolutely certain that this case cannot happen for realworld code, so I'd rather err on the side of caution. Peter & Thomas - we could make the stack thing bullet proof by vmallocing stacks and ensuring a sufficient virtual address gap exists around the stack such that the stack is the only addressable thing in the range of $sp +0x7fff / -0x8000? A -mr10k-cache-barrier=sp-is-safe option? > Peter's patch also treated accesses to constant integer and symbolic > addresses as safe. Again, this involves making assumptions about how > constant integer and symbolic addresses are used, and this is a much > less obvious assumption than the stack one. The latter assumption is also needed for -msym32 kernels, so it's well proven to be valid. The former hold, too. > Again, I understand that > it's a reasonable assumption to make in the linux context, but it's one > we need to pin down. E.g. there must be no run-time guarding of > target-specific constant integer IO-mapped addresses in cases where > those addresses might trigger the problem on other systems that the > same kernel image supports. In case of a hypothetic multi-platform kernel of which at least one needs the R10000 workarounds, all code would be uniformly compiled with the magic -mr10k-cache-barrier option and all source level workaround would be enabled. > Despite appearances, I'm not trying to be awkward here ;) I just think > the assumptions are too loosely-defined at the moment (or at least too > scattered around). It would be nice to have some self-contained > description, targetted specifically at gcc and linux, that contains > anything a gcc hacker or user needs to know about the gcc patch. Your help is certainly appreciated and trying to find the potencial holes here will only help. Ralf From ralf@linux-mips.org Sun Dec 9 05:15:00 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Sun, 09 Dec 2007 05:15:02 +0000 (GMT) Received: from localhost.localdomain ([127.0.0.1]:5586 "EHLO dl5rb.ham-radio-op.net") by ftp.linux-mips.org with ESMTP id S20022104AbXLIFPA (ORCPT ); Sun, 9 Dec 2007 05:15:00 +0000 Received: from denk.linux-mips.net (denk.linux-mips.net [127.0.0.1]) by dl5rb.ham-radio-op.net (8.14.1/8.13.8) with ESMTP id lB95EpPi027048; Sun, 9 Dec 2007 05:14:52 GMT Received: (from ralf@localhost) by denk.linux-mips.net (8.14.1/8.14.1/Submit) id lB95EoBt027047; Sun, 9 Dec 2007 05:14:51 GMT Date: Sun, 9 Dec 2007 05:14:50 +0000 From: Ralf Baechle To: Kaz Kylheku Cc: linux-mips@linux-mips.org Subject: Re: SiByte 1480 & Branch Likely instructions? Message-ID: <20071209051450.GA18181@linux-mips.org> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.17 (2007-11-01) Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 17739 X-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 07, 2007 at 01:54:30PM -0800, Kaz Kylheku wrote: > Not really a kernel-related question. I've discovered that GCC 4.1.1 > (which I'm not using for kernel compiling, but user space) generates > branch likely instructions by default, even though the documentation > says that their use is off by default for MIPS32 and MIPS64, because > they are considered deprecated. They are documented as obsolete for the > Broadcom chips I am working with. Microarchitecture guys love to hate branch likely. But the deprecation is a dream. Binary compatibility will always require those instructions to continue to exist so the genie is out of the bottle and so I feel very certain to predict that a future MIPS 3 specification will contain branch likely. Afair the SB1 core has a full blown implementation of branch likely - unlike the R10000 for example where implementors were lazy that is the branch predictor predicts branch likely instructions as always taken. So on the R10000 branch likely is only good as loop closure instruction while on SB1 it should actually do a decent job wherever it can be scheduled apropriately. > I'm investigating a software anomaly which looks like might be caused by > failure to annul the delay slot of a branch-likely in the fall-through > case. > > In parallel with writing some tests, I thought I would ask whether > anyone happens know whether or not these instructions are known to > actually work correctly on the SB1480 silicon (and perhaps any > additional details, like what revisions, etc)? I have no indications of the contrary. Ralf From ralf@linux-mips.org Sun Dec 9 05:26:32 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Sun, 09 Dec 2007 05:26:34 +0000 (GMT) Received: from localhost.localdomain ([127.0.0.1]:11398 "EHLO dl5rb.ham-radio-op.net") by ftp.linux-mips.org with ESMTP id S20022153AbXLIF0c (ORCPT ); Sun, 9 Dec 2007 05:26:32 +0000 Received: from denk.linux-mips.net (denk.linux-mips.net [127.0.0.1]) by dl5rb.ham-radio-op.net (8.14.1/8.13.8) with ESMTP id lB95QN88027144; Sun, 9 Dec 2007 05:26:24 GMT Received: (from ralf@localhost) by denk.linux-mips.net (8.14.1/8.14.1/Submit) id lB95QNOU027143; Sun, 9 Dec 2007 05:26:23 GMT Date: Sun, 9 Dec 2007 05:26:23 +0000 From: Ralf Baechle To: Kaz Kylheku Cc: linux-mips@linux-mips.org Subject: Re: SiByte 1480 & Branch Likely instructions? Message-ID: <20071209052623.GC18181@linux-mips.org> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.17 (2007-11-01) Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 17740 X-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 07, 2007 at 03:39:57PM -0800, Kaz Kylheku wrote: > > Not really a kernel-related question. I've discovered that GCC 4.1.1 > > (which I'm not using for kernel compiling, but user space) generates > > branch likely instructions by default, even though the documentation > > says that their use is off by default for MIPS32 and MIPS64, because > > That's because the compiler is not configured correctly. The default CPU > string "from-abi" ends up being used, and so the target ISA is MIPS III. > > > In parallel with writing some tests, I thought I would ask whether > > anyone happens know whether or not these instructions are known to > > actually work correctly on the SB1480 silicon (and perhaps any > > additional details, like what revisions, etc)? > > A basic sanity test does find bnezl working. > > #include > #include > > static int branch_likely_works(void) > { > int one = 1; > int result; > > __asm__ __volatile__ > (" .set push\n" > " .set noreorder\n" > "1: move %0, $0\n" > " bnezl %0, 1b\n" > " lw %0, %1\n" > " .set pop\n" > : "=r" (result) > : "m" (one)); > > return result == 0; > } > > int main(void) > { > if (branch_likely_works()) { > puts("branch-likely instruction bnezl correctly annuls delay > slot"); > return 0; > } > puts("branch-likely instruction bnezl fails to annul delay slot"); > return EXIT_FAILURE; > } That's a very basic test and it'd be very unlikely for the CPU to fail such a simple test. But think of scenarios like a load in the delay slot of a branch likely where the load instruction is on a different page than the branch and a tlb exception is getting caused. There are many other special cases which might be improperly implemented. But honestly - branch likely instructions were introduced into the MIPS architecture by the MIPS II R6000 in '89. And the SB1 core is 2000 vintage so I'd assume by now have figured out how to get it right. And branch likely is used in existing binaries. So I'd be surprised if it was broken. Ralf From yoichi_yuasa@tripeaks.co.jp Sun Dec 9 12:21:00 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Sun, 09 Dec 2007 12:21:08 +0000 (GMT) Received: from mo31.po.2iij.net ([210.128.50.54]:12295 "EHLO mo31.po.2iij.net") by ftp.linux-mips.org with ESMTP id S20026275AbXLIMVA (ORCPT ); Sun, 9 Dec 2007 12:21:00 +0000 Received: by mo.po.2iij.net (mo31) id lB9CJdG4059733; Sun, 9 Dec 2007 21:19:39 +0900 (JST) Received: from delta (224.24.30.125.dy.iij4u.or.jp [125.30.24.224]) by mbox.po.2iij.net (po-mbox301) id lB9CJbKS031840 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sun, 9 Dec 2007 21:19:37 +0900 Date: Sun, 9 Dec 2007 21:19:36 +0900 From: Yoichi Yuasa To: Ralf Baechle Cc: yoichi_yuasa@tripeaks.co.jp, linux-mips Subject: [PATCH][MIPS] remove mips_timer_state() Message-Id: <20071209211936.05b97163.yoichi_yuasa@tripeaks.co.jp> Organization: TriPeaks Corporation X-Mailer: Sylpheed 2.4.5 (GTK+ 2.12.0; 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: 17741 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: yoichi_yuasa@tripeaks.co.jp Precedence: bulk X-list: linux-mips Remove mips_timer_state(). It is not used at all. Signed-off-by: Yoichi Yuasa diff -pruN -X mips/Documentation/dontdiff mips-orig/arch/mips/dec/time.c mips/arch/mips/dec/time.c --- mips-orig/arch/mips/dec/time.c 2007-12-06 18:27:03.461092000 +0900 +++ mips/arch/mips/dec/time.c 2007-12-09 20:55:08.231255000 +0900 @@ -161,7 +161,6 @@ static cycle_t dec_ioasic_hpt_read(void) void __init plat_time_init(void) { - mips_timer_state = dec_timer_state; mips_timer_ack = dec_timer_ack; if (!cpu_has_counter && IOASIC) diff -pruN -X mips/Documentation/dontdiff mips-orig/arch/mips/kernel/time.c mips/arch/mips/kernel/time.c --- mips-orig/arch/mips/kernel/time.c 2007-12-06 18:27:04.629165000 +0900 +++ mips/arch/mips/kernel/time.c 2007-12-09 20:52:04.111748250 +0900 @@ -50,8 +50,6 @@ int update_persistent_clock(struct times return rtc_mips_set_mmss(now.tv_sec); } -int (*mips_timer_state)(void); - int null_perf_irq(void) { return 0; diff -pruN -X mips/Documentation/dontdiff mips-orig/include/asm-mips/time.h mips/include/asm-mips/time.h --- mips-orig/include/asm-mips/time.h 2007-12-06 18:30:02.548284250 +0900 +++ mips/include/asm-mips/time.h 2007-12-09 20:54:28.116748000 +0900 @@ -31,20 +31,13 @@ extern int rtc_mips_set_time(unsigned lo extern int rtc_mips_set_mmss(unsigned long); /* - * Timer interrupt functions. - * mips_timer_state is needed for high precision timer calibration. - */ -extern int (*mips_timer_state)(void); - -/* * board specific routines required by time_init(). */ extern void plat_time_init(void); /* * mips_hpt_frequency - must be set if you intend to use an R4k-compatible - * counter as a timer interrupt source; otherwise it can be set up - * automagically with an aid of mips_timer_state. + * counter as a timer interrupt source. */ extern unsigned int mips_hpt_frequency; From yoichi_yuasa@tripeaks.co.jp Sun Dec 9 12:22:12 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Sun, 09 Dec 2007 12:22:21 +0000 (GMT) Received: from mo32.po.2iij.NET ([210.128.50.17]:57929 "EHLO mo32.po.2iij.net") by ftp.linux-mips.org with ESMTP id S20026275AbXLIMWM (ORCPT ); Sun, 9 Dec 2007 12:22:12 +0000 Received: by mo.po.2iij.net (mo32) id lB9CMAxM079061; Sun, 9 Dec 2007 21:22:10 +0900 (JST) Received: from delta (224.24.30.125.dy.iij4u.or.jp [125.30.24.224]) by mbox.po.2iij.net (po-mbox303) id lB9CM5vg003794 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sun, 9 Dec 2007 21:22:05 +0900 Date: Sun, 9 Dec 2007 21:22:04 +0900 From: Yoichi Yuasa To: Ralf Baechle Cc: yoichi_yuasa@tripeaks.co.jp, linux-mips Subject: [PATCH][MIPS] set up Cobalt's mips_hpt_frequency Message-Id: <20071209212204.5e50a697.yoichi_yuasa@tripeaks.co.jp> Organization: TriPeaks Corporation X-Mailer: Sylpheed 2.4.5 (GTK+ 2.12.0; 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: 17742 X-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 Set up Cobalt's mips_hpt_frequency. Signed-off-by: Yoichi Yuasa diff -pruN -X mips/Documentation/dontdiff mips-orig/arch/mips/cobalt/time.c mips/arch/mips/cobalt/time.c --- mips-orig/arch/mips/cobalt/time.c 2007-12-06 18:27:02.689043750 +0900 +++ mips/arch/mips/cobalt/time.c 2007-12-09 17:13:37.916769000 +0900 @@ -27,9 +27,28 @@ void __init plat_time_init(void) { + u32 start, end; + int i = HZ / 10; + setup_pit_timer(); gt641xx_set_base_clock(GT641XX_BASE_CLOCK); - mips_timer_state = gt641xx_timer0_state; + /* + * MIPS counter frequency is measured between 100msec + * using GT64111 timer0. + */ + while (!gt641xx_timer0_state()) + ; + + start = read_c0_count(); + + while (i--) + while (!gt641xx_timer0_state()) + ; + + end = read_c0_count(); + + mips_hpt_frequency = (end - start) * 10; + printk(KERN_INFO "MIPS counter frequency %dHz\n", mips_hpt_frequency); } From tbm@cyrius.com Sun Dec 9 16:45:25 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Sun, 09 Dec 2007 16:45:32 +0000 (GMT) Received: from sorrow.cyrius.com ([65.19.161.204]:46096 "EHLO sorrow.cyrius.com") by ftp.linux-mips.org with ESMTP id S28573708AbXLIQpY (ORCPT ); Sun, 9 Dec 2007 16:45:24 +0000 Received: by sorrow.cyrius.com (Postfix, from userid 10) id 9C3A2D8DE; Sun, 9 Dec 2007 16:45:15 +0000 (UTC) Received: by deprecation.cyrius.com (Postfix, from userid 1000) id 8B179540A3; Sun, 9 Dec 2007 17:45:02 +0100 (CET) Date: Sun, 9 Dec 2007 09:45:02 -0700 From: Martin Michlmayr To: Markus Gothe Cc: linux-mips@linux-mips.org Subject: Re: [SPAM] Re: Donation of an Indigo 2 R4K@250 Message-ID: <20071209164502.GA13877@deprecation.cyrius.com> References: <20071105141248.GQ6244@deprecation.cyrius.com> <20071111110752.GA21220@deprecation.cyrius.com> <47385B75.2010700@27m.se> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <47385B75.2010700@27m.se> User-Agent: Mutt/1.5.16 (2007-06-11) Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 17743 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: tbm@cyrius.com Precedence: bulk X-list: linux-mips * Markus Gothe [2007-11-12 14:56]: > Which graphics option? A 'hinv -v' would be appreciated. hinv: CPU: MIPS R4400 Processor Chip Revision: 6.0 FPU: MIPS R4000 Floating Point Coprocessor Revision: 0.0 1 250 MHZ IP22 Processor Main memory size: 128 Mbytes Secondary unified instruction/data cache size: 2 Mbytes on Processor 0 Instruction cache size: 16 Kbytes Data cache size: 16 Kbytes Integral SCSI controller 0: Version WD33C93B, revision D Disk drive: unit 1 on SCSI controller 0 Integral SCSI controller 1: Version WD33C93B, revision D On-board serial ports: 2 On-board bi-directional parallel port Graphics board: GU1-Extreme Integral Ethernet: ec0, version 1 Iris Audio Processor: version A2 revision 1.1.0 EISA bus: adapter 0 gfxinfo: -- Graphics board 0 is "GR2" graphics. Managed (":0.0") 1280x1024 8 GEs, 2 REs, 24 bitplanes, 4 auxplanes, 4 cidplanes, Z-buffer GR2 revision 6, VB2.0 HQ2.1 rev A, GE7 rev B, RE3.1 rev A, VC1 rev B, MC rev C unknown, assuming 19" monitor -- Martin Michlmayr http://www.cyrius.com/ From ralf@linux-mips.org Sun Dec 9 19:10:43 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Sun, 09 Dec 2007 19:10:45 +0000 (GMT) Received: from localhost.localdomain ([127.0.0.1]:25258 "EHLO dl5rb.ham-radio-op.net") by ftp.linux-mips.org with ESMTP id S28573796AbXLITKn (ORCPT ); Sun, 9 Dec 2007 19:10:43 +0000 Received: from denk.linux-mips.net (denk.linux-mips.net [127.0.0.1]) by dl5rb.ham-radio-op.net (8.14.1/8.13.8) with ESMTP id lB9JAIA9032743; Sun, 9 Dec 2007 19:10:19 GMT Received: (from ralf@localhost) by denk.linux-mips.net (8.14.1/8.14.1/Submit) id lB9JAF5O032742; Sun, 9 Dec 2007 19:10:15 GMT Date: Sun, 9 Dec 2007 19:10:15 +0000 From: Ralf Baechle To: Yoichi Yuasa Cc: linux-mips Subject: Re: [PATCH][MIPS] remove mips_timer_state() Message-ID: <20071209191015.GA32724@linux-mips.org> References: <20071209211936.05b97163.yoichi_yuasa@tripeaks.co.jp> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20071209211936.05b97163.yoichi_yuasa@tripeaks.co.jp> User-Agent: Mutt/1.5.17 (2007-11-01) Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 17744 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: ralf@linux-mips.org Precedence: bulk X-list: linux-mips On Sun, Dec 09, 2007 at 09:19:36PM +0900, Yoichi Yuasa wrote: > Remove mips_timer_state(). > It is not used at all. > > Signed-off-by: Yoichi Yuasa Queued for 2.6.25. Thanks, Ralf From ralf@linux-mips.org Sun Dec 9 19:11:05 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Sun, 09 Dec 2007 19:11:09 +0000 (GMT) Received: from localhost.localdomain ([127.0.0.1]:27818 "EHLO dl5rb.ham-radio-op.net") by ftp.linux-mips.org with ESMTP id S28573810AbXLITKy (ORCPT ); Sun, 9 Dec 2007 19:10:54 +0000 Received: from denk.linux-mips.net (denk.linux-mips.net [127.0.0.1]) by dl5rb.ham-radio-op.net (8.14.1/8.13.8) with ESMTP id lB9JAgoY032752; Sun, 9 Dec 2007 19:10:42 GMT Received: (from ralf@localhost) by denk.linux-mips.net (8.14.1/8.14.1/Submit) id lB9JAdVs032751; Sun, 9 Dec 2007 19:10:39 GMT Date: Sun, 9 Dec 2007 19:10:39 +0000 From: Ralf Baechle To: Yoichi Yuasa Cc: linux-mips Subject: Re: [PATCH][MIPS] set up Cobalt's mips_hpt_frequency Message-ID: <20071209191039.GB32724@linux-mips.org> References: <20071209212204.5e50a697.yoichi_yuasa@tripeaks.co.jp> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20071209212204.5e50a697.yoichi_yuasa@tripeaks.co.jp> User-Agent: Mutt/1.5.17 (2007-11-01) Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 17745 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: ralf@linux-mips.org Precedence: bulk X-list: linux-mips On Sun, Dec 09, 2007 at 09:22:04PM +0900, Yoichi Yuasa wrote: > Set up Cobalt's mips_hpt_frequency. Queue for 2.6.25. Thanks, Ralf From yoichi_yuasa@tripeaks.co.jp Mon Dec 10 00:37:49 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 10 Dec 2007 00:37:58 +0000 (GMT) Received: from mo30.po.2iij.NET ([210.128.50.53]:59212 "EHLO mo30.po.2iij.net") by ftp.linux-mips.org with ESMTP id S28573947AbXLJAht (ORCPT ); Mon, 10 Dec 2007 00:37:49 +0000 Received: by mo.po.2iij.net (mo30) id lBA0aTto015256; Mon, 10 Dec 2007 09:36:29 +0900 (JST) Received: from localhost (65.126.232.202.bf.2iij.net [202.232.126.65]) by mbox.po.2iij.net (po-mbox303) id lBA0aRWD016476 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 10 Dec 2007 09:36:27 +0900 Message-Id: <200712100036.lBA0aRWD016476@po-mbox303.hop.2iij.net> Date: Mon, 10 Dec 2007 09:36:27 +0900 From: Yoichi Yuasa To: Ralf Baechle Cc: yoichi_yuasa@tripeaks.co.jp, linux-mips Subject: Re: [PATCH][MIPS] set up Cobalt's mips_hpt_frequency In-Reply-To: <20071209191039.GB32724@linux-mips.org> References: <20071209212204.5e50a697.yoichi_yuasa@tripeaks.co.jp> <20071209191039.GB32724@linux-mips.org> Organization: TriPeaks Corporation X-Mailer: Sylpheed version 2.3.0beta5 (GTK+ 2.8.20; x86_64-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 17746 X-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 On Sun, 9 Dec 2007 19:10:39 +0000 Ralf Baechle wrote: > On Sun, Dec 09, 2007 at 09:22:04PM +0900, Yoichi Yuasa wrote: > > > Set up Cobalt's mips_hpt_frequency. > > Queue for 2.6.25. Thanks, Cobalt cannot boot as this patch doesn't exist. Please apply 2.6.24-rc too. Thanks, Yoichi From zzh.hust@gmail.com Mon Dec 10 01:18:48 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 10 Dec 2007 01:18:57 +0000 (GMT) Received: from wa-out-1112.google.com ([209.85.146.179]:1330 "EHLO wa-out-1112.google.com") by ftp.linux-mips.org with ESMTP id S28573961AbXLJBSs (ORCPT ); Mon, 10 Dec 2007 01:18:48 +0000 Received: by wa-out-1112.google.com with SMTP id m16so2811366waf for ; Sun, 09 Dec 2007 17:18:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:mime-version:content-type; bh=ebO27moLBa1oNB1gSNylEf+MWlRlgnCHDFVPUzVeSko=; b=G8YKt6IqT0St6fOqb8oIGISiYFjTBHlN3YnxNftJYhpkE/JDY2StoTXyxMo4turrxV0J3E9HX5ZFZoyn/uzHeghzrwhmKeCTl1tWf+K+vLUT3rgbjIWH81w6umOh9E9kA7w7mNS6njgbZLQi/+rYi5ewfn8bW4lFOI9Ffz0HdP4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:mime-version:content-type; b=uehru+YnxPTZQU5J0CjF7ttd/LUpe+4JVIGP3aD/y4NFdF/Hkx/imCTsKhjB9qXfIoiC4oDeisV6Aaur5/1xqGcOQVAoimdUXfD2bWNNcRpvtE9i0DFM6EIb64bKpo8+aZR2C511jhEyOv+Q6ku7pzp/mSxx+K8ndASv0aN50ME= Received: by 10.115.78.1 with SMTP id f1mr6226353wal.1197249515952; Sun, 09 Dec 2007 17:18:35 -0800 (PST) Received: by 10.114.168.15 with HTTP; Sun, 9 Dec 2007 17:18:35 -0800 (PST) Message-ID: <50c9a2250712091718l75455353v1b86851a011eb4fe@mail.gmail.com> Date: Mon, 10 Dec 2007 09:18:35 +0800 From: zhuzhenhua To: linux-mips Subject: is there a standard high res timer patch for mips? MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_22432_8761073.1197249515950" Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 17747 X-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 ------=_Part_22432_8761073.1197249515950 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline hello, all i want to add the high res timer support for my kernel(version 2.6.14),and i found there are some patches: high-res-timers at sourceforge.net/projects/high-res-timers/high-res-timers Jun Sun's patch at http://linux.junsun.net/patches/oss.sgi.com/experimental/ Thomas Gleixner's patch at http://www.tglx.de/projects/hrtimers/ is there a standard high res timer patch for mips now? thanks for any hints Best Regards zzh ------=_Part_22432_8761073.1197249515950 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline hello, all
           i want to add the high res timer support for my kernel(version 2.6.14),and i found there are some patches:
 high-res-timers at sourceforge.net/projects/high-res-timers/high-res-timers
Jun Sun's patch at http://linux.junsun.net/patches/oss.sgi.com/experimental/
Thomas Gleixner's patch at http://www.tglx.de/projects/hrtimers/
     is there a standard high res timer patch for mips now?
     thanks for any hints


Best Regards

zzh


------=_Part_22432_8761073.1197249515950-- From sbrown@cortland.com Mon Dec 10 01:55:36 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 10 Dec 2007 01:55:46 +0000 (GMT) Received: from rv-out-0910.google.com ([209.85.198.191]:28527 "EHLO rv-out-0910.google.com") by ftp.linux-mips.org with ESMTP id S28573982AbXLJBzg (ORCPT ); Mon, 10 Dec 2007 01:55:36 +0000 Received: by rv-out-0910.google.com with SMTP id l15so1277696rvb for ; Sun, 09 Dec 2007 17:55:23 -0800 (PST) Received: by 10.141.167.5 with SMTP id u5mr3928560rvo.1197251723015; Sun, 09 Dec 2007 17:55:23 -0800 (PST) Received: from mythtv.cortland.com ( [209.162.137.90]) by mx.google.com with ESMTPS id f13sm4662373rvb.2007.12.09.17.55.22 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sun, 09 Dec 2007 17:55:22 -0800 (PST) Message-ID: <475C9C80.4030708@cortland.com> Date: Sun, 09 Dec 2007 17:55:12 -0800 From: Steve Brown User-Agent: Thunderbird 2.0.0.9 (X11/20071115) MIME-Version: 1.0 To: linux-mips Subject: SSB Bus: Need advice representing 2 devices in a core (BCM5354 USB2.0 core) 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: 17748 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: sbrown@cortland.com Precedence: bulk X-list: linux-mips I'm posting to this list because I think this is basically a ssb bus issue. If it doesn't belong here, where should I go? The USB 2.0 core in the BCM5354 is both a OHCI & EHCI device. I now have a OHCI & EHCI driver. The former is essentially the current ohci-ssb.c w/ a dma mask fix and the latter I derived from ohci-ssb and ehci-pci. Either one, but not both, will attach to the USB 2.0 core and mostly work. 1. Multiple devices per core The ssb bus code seems to expect only one device per core. I modified drivers/ssb/scan.c to add an additional identical device in the case of the USB 2.0 core. However, once a driver binds to one device, the other seems to no longer be available either. When the second driver loads, ssb_bus_match never sees the second device. I haven't figured out what's happening yet. I also considered modifying drivers/ssb/scan.c to add a phony additional core/device for SSB_DEV_USB20_HOST and then add that phony core to the OHCI device list. But, this seems really ugly. 2. Avoiding multiple core initializations I also need a way to determine if the core is already enabled, as I can't initialize it more than once. The initialization gets done in the probe code in ohci-ssb and ehci-ssb. The first one loaded does that and the second driver needs to skip the initialization. Does the following look like a safe test for a reset core? (ssb_read32(dev, SSB_TMSLOW) & SSB_TMSLOW_RESET) As ssb_enable always first resets the core, maybe this test isn't always reliable. If it isn't, should I just add a flag to the ssb_device structure that follows ssb_enable/ssb_disable? Any suggestions are appreciated. As I'm probably less than qualified to be doing this, I'll accept that as advice as well. Steve From aurel32@hall.aurel32.net Mon Dec 10 10:25:46 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 10 Dec 2007 10:25:54 +0000 (GMT) Received: from hall.aurel32.net ([88.191.38.19]:7089 "EHLO hall.aurel32.net") by ftp.linux-mips.org with ESMTP id S20024102AbXLJKZq (ORCPT ); Mon, 10 Dec 2007 10:25:46 +0000 Received: from aurel32 by hall.aurel32.net with local (Exim 4.63) (envelope-from ) id 1J1fmS-0002e3-5f; Mon, 10 Dec 2007 11:22:32 +0100 Date: Mon, 10 Dec 2007 11:22:32 +0100 From: Aurelien Jarno To: Ralf Baechle Cc: linux-mips@linux-mips.org Subject: [PATCH][MIPS] Enable SSB_DRIVER_EXTIF on BCM47XX platform Message-ID: <20071210102232.GA10145@hall.aurel32.net> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-15 Content-Disposition: inline X-Mailer: Mutt 1.5.13 (2006-08-11) User-Agent: Mutt/1.5.13 (2006-08-11) Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 17749 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: aurelien@aurel32.net Precedence: bulk X-list: linux-mips Hi, arch/mips/bcm47xx/gpio.c uses ssb_extif_* functions. The patch below makes sure those functions are available on the BCM47XX platform. Aurelien Signed-off-by: Aurelien Jarno diff --git a/arch/mips/Kconfig b/arch/mips/Kconfig index c6fc405..e46b076 100644 --- a/arch/mips/Kconfig +++ b/arch/mips/Kconfig @@ -59,6 +59,7 @@ config BCM47XX select SYS_SUPPORTS_LITTLE_ENDIAN select SSB select SSB_DRIVER_MIPS + select SSB_DRIVER_EXTIF select GENERIC_GPIO select SYS_HAS_EARLY_PRINTK select CFE -- .''`. Aurelien Jarno | GPG: 1024D/F1BCDB73 : :' : Debian developer | Electrical Engineer `. `' aurel32@debian.org | aurelien@aurel32.net `- people.debian.org/~aurel32 | www.aurel32.net From rsandifo@nildram.co.uk Mon Dec 10 11:01:10 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 10 Dec 2007 11:01:19 +0000 (GMT) Received: from smtp.nildram.co.uk ([195.112.4.54]:42763 "EHLO smtp.nildram.co.uk") by ftp.linux-mips.org with ESMTP id S20024131AbXLJLBK (ORCPT ); Mon, 10 Dec 2007 11:01:10 +0000 Received: from firetop.home (85-211-134-127.dyn.gotadsl.co.uk [85.211.134.127]) by smtp.nildram.co.uk (Postfix) with ESMTP id 3931C2B7945; Mon, 10 Dec 2007 11:00:53 +0000 (GMT) Received: from richard by firetop.home with local (Exim 4.63) (envelope-from ) id 1J1gNa-0004Lz-IN; Mon, 10 Dec 2007 11:00:54 +0000 From: Richard Sandiford To: Ralf Baechle Mail-Followup-To: Ralf Baechle ,Thomas Bogendoerfer , Kumba , linux-mips@linux-mips.org, rsandifo@nildram.co.uk Cc: Thomas Bogendoerfer , Kumba , linux-mips@linux-mips.org Subject: Re: [UPDATED PATCH] IP28 support References: <20071129095442.C6679C2B39@solo.franken.de> <20071129130130.GA14655@linux-mips.org> <4756422D.6070305@gentoo.org> <20071205093938.GA6848@alpha.franken.de> <87ejdx6pmh.fsf@firetop.home> <20071208192405.GA29208@linux-mips.org> <871w9x6j9g.fsf@firetop.home> <20071209043821.GB13729@linux-mips.org> Date: Mon, 10 Dec 2007 11:00:54 +0000 In-Reply-To: <20071209043821.GB13729@linux-mips.org> (Ralf Baechle's message of "Sun\, 9 Dec 2007 04\:38\:21 +0000") Message-ID: <871w9u24rd.fsf@firetop.home> User-Agent: Gnus/5.110006 (No Gnus v0.6) Emacs/21.4 (gnu/linux) 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: 17750 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: rsandifo@nildram.co.uk Precedence: bulk X-list: linux-mips Ralf Baechle writes: >> Then there's the language-lawyerly code I gave to Peter on gcc-patches@: >> >> void foo (int x) >> { >> int array[1]; >> if (x) >> bar (array[0x1fff]); >> } >> >> This function is valid if x is never true, so we cannot assume that all >> accesses off the stack and frame pointers are actually in-frame. You're >> assuming either (i) the kernel doesn't use code like that or (ii) that >> "garbage" addresses in the range [$sp - 0x8000, $sp + 0x7fff] will not >> trigger the problem. I imagine both are reasonable assumptions, and I'm >> perfectly happy for us to make them. But they're the kind of assumption >> we need to state explicitly. > > Interesting test case. I've been thinking about it myself but in the end > decieded to believe Peter's analysis since he's banged the head for longer > to the wall about this problem that I have ;-) I'm quite but not absolutely > certain that this case cannot happen for realworld code, so I'd rather > err on the side of caution. > > Peter & Thomas - we could make the stack thing bullet proof by vmallocing > stacks and ensuring a sufficient virtual address gap exists around the stack > such that the stack is the only addressable thing in the range of > $sp +0x7fff / -0x8000? FWIW, my first cut at the option restrictions were based on what the patch exempts (and doesn't exempt). We could instead get gcc to only exempt accesses that it can prove are either to the current function's stack frame or to its stack arguments. I.e. rather than consider every $sp-based access to be safe, we'd instead do some bounds checking on the value. (We could also use MEM_ATTRS to pick up cases where a stack variable is acceesed via something other than the stack or frame pointers, as happens for large frames.) >> Peter's patch also treated accesses to constant integer and symbolic >> addresses as safe. Again, this involves making assumptions about how >> constant integer and symbolic addresses are used, and this is a much >> less obvious assumption than the stack one. > > The latter assumption is also needed for -msym32 kernels, so it's well > proven to be valid. The former hold, too. > >> Again, I understand that >> it's a reasonable assumption to make in the linux context, but it's one >> we need to pin down. E.g. there must be no run-time guarding of >> target-specific constant integer IO-mapped addresses in cases where >> those addresses might trigger the problem on other systems that the >> same kernel image supports. > > In case of a hypothetic multi-platform kernel of which at least one needs > the R10000 workarounds, all code would be uniformly compiled with the > magic -mr10k-cache-barrier option and all source level workaround would > be enabled. Hmm. This probably shows I am misunderstanding the problem, but I was thinking about the IO-mapped case. I thought one of the problems was that if you had a cached speculative load or store to an access-sensitive IO-mapped address, the IO-mapped device might "see" that access even if it doesn't take place. Could you not have a situation where a KSEG0 or XKSEG0 access is access-sensitive on one machine and not another? The patch won't insert countermeasures before symbolic and constant addresses, because it believes all such addresses to be safe. I'm also a little worried that the compiler is free to make up accesses that didn't exist in the original program, provided that those accesses are never actually performed in cases where they'd be wrong. So how about: -mr10k-cache-barrier=load-store Insert a cache barrier at the beginning of any sequentially-executed series of instructions that contains a load or store. For the purposes of this option, GCC can ignore loads and stores that it can prove are an in-range access to: (a) the current function's stack frame; (b) an incoming stack argument; (b) an object with a link-time-constant address; or (c) a block of uncached memory It can also ignore sequences that are always immediately preceded by an untaken branch-likely instruction. Here, a ``sequentially-executed series'' is one in which calls, jumps and branches occur only as the last instruction. -mr10k-cache-barrier=store Like -mr10k-cache-barrier=load-store, but ignore all loads. -mr10k-cache-barrier=none ... Richard From giuseppe@eppesuigoccas.homedns.org Mon Dec 10 11:58:17 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 10 Dec 2007 11:58:26 +0000 (GMT) Received: from host188-210-dynamic.20-79-r.retail.telecomitalia.it ([79.20.210.188]:51899 "EHLO eppesuigoccas.homedns.org") by ftp.linux-mips.org with ESMTP id S20024298AbXLJL6R (ORCPT ); Mon, 10 Dec 2007 11:58:17 +0000 Received: from eppesuig3 ([192.168.2.50]) by eppesuigoccas.homedns.org with esmtpsa (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from ) id 1J1hH2-00014H-ET for linux-mips@linux-mips.org; Mon, 10 Dec 2007 12:58:14 +0100 Subject: Re: 2.6.24-rc1 does not boot on SGI From: Giuseppe Sacco To: linux-mips@linux-mips.org In-Reply-To: <1194281699.4192.3.camel@casa> References: <1193468825.7474.6.camel@scarafaggio> <20071029.000713.59464443.anemo@mba.ocn.ne.jp> <1193599031.14874.1.camel@scarafaggio> <20071029150625.GB4165@linux-mips.org> <1194268551.4842.3.camel@scarafaggio> <1194281699.4192.3.camel@casa> Content-Type: text/plain Date: Mon, 10 Dec 2007 12:58:49 +0100 Message-Id: <1197287929.17265.6.camel@scarafaggio> Mime-Version: 1.0 X-Mailer: Evolution 2.10.3 Content-Transfer-Encoding: 7bit Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 17751 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: giuseppe@eppesuigoccas.homedns.org Precedence: bulk X-list: linux-mips I reply to my own message, providing more details, hoping that anyone here could give a hint or the solution. During bootup on ip32, since 2.4.24-rc1, the system loop printing a message about unexpected interrupt #13. (see transcript below.) I enabled more debug in the kernel, and studied the code. What I understood is that interrupt #13 from CRIME means that the system should check on MACEISA for the real interrupt. The interrupt start appearing just after executing the code psmouse_init() that enable ps2 drivers for keyboard and mouse. Keyboard interrupt #49 is enabled first and mouse interrupt #51 is enabled later. When initialising the keyboard interrupt (it is a MACEISA interrupt), the interrupt start appearing, so I am pretty sure that interrupt #13 is related to the keyboard interrupt. When the system receive interrupt #13, it correctly detect it is a MACEISA interrupt, and check for mace->perif.ctrl.istat value. The problem seems to be that this value is zero instead of having bit #9 on (that would mean, interrupt #49, keyboard). So, either the interrupt #49 is not correctly enabled, or maceisa interrupt aren't correctly checked. Does this description ring a bell to anyone? Bye, Giuseppe Calling initcall 0xffffffff80496ca0: serport_init+0x0/0x48() initcall 0xffffffff80496ca0: serport_init+0x0/0x48() returned 0. initcall 0xffffffff80496ca0 ran for 0 msecs: serport_init+0x0/0x48() Calling initcall 0xffffffff80496ce8: maceps2_init+0x0/0xe0() initcall 0xffffffff80496ce8: maceps2_init+0x0/0xe0() returned 0. initcall 0xffffffff80496ce8 ran for 1 msecs: maceps2_init+0x0/0xe0() Calling initcall 0xffffffff80496dc8: serio_raw_init+0x0/0x18() initcall 0xffffffff80496dc8: serio_raw_init+0x0/0x18() returned 0. initcall 0xffffffff80496dc8 ran for 1 msecs: serio_raw_init+0x0/0x18() Calling initcall 0xffffffff80496f40: mousedev_init+0x0/0xd0() mice: PS/2 mouse device common for all mice initcall 0xffffffff80496f40: mousedev_init+0x0/0xd0() returned 0. initcall 0xffffffff80496f40 ran for 16 msecs: mousedev_init+0x0/0xd0() Calling initcall 0xffffffff80497010: atkbd_init+0x0/0x18() initcall 0xffffffff80497010: atkbd_init+0x0/0x18() returned 0. initcall 0xffffffff80497010 ran for 0 msecs: atkbd_init+0x0/0x18() Calling initcall 0xffffffff80497028: psmouse_init+0x0/0x90() maceisa enable: 49 crime_int 00000020 enabled *irq 13, crime_int=00002000, crime_mask=003003a0, mace_int=00000000* irq 13, desc: ffffffff80448390, depth: 1, count: 0, unhandled: 0 ->handle_irq(): ffffffff80065eb0, handle_bad_irq+0x0/0x2c0 ->chip(): ffffffff8043e320, 0xffffffff8043e320 ->action(): 0000000000000000 IRQ_DISABLED set From sshtylyov@ru.mvista.com Mon Dec 10 12:03:57 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 10 Dec 2007 12:04:06 +0000 (GMT) Received: from h155.mvista.com ([63.81.120.155]:54714 "EHLO imap.sh.mvista.com") by ftp.linux-mips.org with ESMTP id S20024304AbXLJMD5 (ORCPT ); Mon, 10 Dec 2007 12:03:57 +0000 Received: from [192.168.1.234] (unknown [10.150.0.9]) by imap.sh.mvista.com (Postfix) with ESMTP id 5F45B3ECD; Mon, 10 Dec 2007 04:03:24 -0800 (PST) Message-ID: <475D2B21.7050206@ru.mvista.com> Date: Mon, 10 Dec 2007 15:03:45 +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: Yoichi Yuasa Cc: Ralf Baechle , linux-mips Subject: Re: [PATCH][MIPS] set up Cobalt's mips_hpt_frequency References: <20071209212204.5e50a697.yoichi_yuasa@tripeaks.co.jp> In-Reply-To: <20071209212204.5e50a697.yoichi_yuasa@tripeaks.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: 17752 X-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. Yoichi Yuasa wrote: > Set up Cobalt's mips_hpt_frequency. > Signed-off-by: Yoichi Yuasa > diff -pruN -X mips/Documentation/dontdiff mips-orig/arch/mips/cobalt/time.c mips/arch/mips/cobalt/time.c > --- mips-orig/arch/mips/cobalt/time.c 2007-12-06 18:27:02.689043750 +0900 > +++ mips/arch/mips/cobalt/time.c 2007-12-09 17:13:37.916769000 +0900 > @@ -27,9 +27,28 @@ > > void __init plat_time_init(void) > { > + u32 start, end; > + int i = HZ / 10; > + > setup_pit_timer(); > > gt641xx_set_base_clock(GT641XX_BASE_CLOCK); > > - mips_timer_state = gt641xx_timer0_state; > + /* > + * MIPS counter frequency is measured between 100msec s/between/during/ WBR, Sergei From sshtylyov@ru.mvista.com Mon Dec 10 12:05:06 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 10 Dec 2007 12:05:15 +0000 (GMT) Received: from h155.mvista.com ([63.81.120.155]:56762 "EHLO imap.sh.mvista.com") by ftp.linux-mips.org with ESMTP id S20024304AbXLJMFG (ORCPT ); Mon, 10 Dec 2007 12:05:06 +0000 Received: from [192.168.1.234] (unknown [10.150.0.9]) by imap.sh.mvista.com (Postfix) with ESMTP id E34113ECD; Mon, 10 Dec 2007 04:05:04 -0800 (PST) Message-ID: <475D2B86.603@ru.mvista.com> Date: Mon, 10 Dec 2007 15:05:26 +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: zhuzhenhua Cc: linux-mips Subject: Re: is there a standard high res timer patch for mips? References: <50c9a2250712091718l75455353v1b86851a011eb4fe@mail.gmail.com> In-Reply-To: <50c9a2250712091718l75455353v1b86851a011eb4fe@mail.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: 17753 X-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. zhuzhenhua wrote: > i want to add the high res timer support for my kernel(version > 2.6.14),and i found there are some patches: > high-res-timers at sourceforge.net/projects/high-res-timers/high-res-timers > Jun Sun's patch at > http://linux.junsun.net/patches/oss.sgi.com/experimental/ > Thomas Gleixner's patch at http://www.tglx.de/projects/hrtimers/ > is there a standard high res timer patch for mips now? > thanks for any hints Yes, Tohmas' patch is now included into the kernel. > Best Regards > > zzh WBR, Sergei From ralf@linux-mips.org Mon Dec 10 13:15:20 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 10 Dec 2007 13:15:22 +0000 (GMT) Received: from localhost.localdomain ([127.0.0.1]:14283 "EHLO dl5rb.ham-radio-op.net") by ftp.linux-mips.org with ESMTP id S20024481AbXLJNPU (ORCPT ); Mon, 10 Dec 2007 13:15:20 +0000 Received: from denk.linux-mips.net (denk.linux-mips.net [127.0.0.1]) by dl5rb.ham-radio-op.net (8.14.1/8.13.8) with ESMTP id lBADF4Tf012145; Mon, 10 Dec 2007 13:15:04 GMT Received: (from ralf@localhost) by denk.linux-mips.net (8.14.1/8.14.1/Submit) id lBADF2eT012137; Mon, 10 Dec 2007 13:15:02 GMT Date: Mon, 10 Dec 2007 13:15:02 +0000 From: Ralf Baechle To: Yoichi Yuasa Cc: linux-mips Subject: Re: [PATCH][MIPS] set up Cobalt's mips_hpt_frequency Message-ID: <20071210131502.GA11886@linux-mips.org> References: <20071209212204.5e50a697.yoichi_yuasa@tripeaks.co.jp> <20071209191039.GB32724@linux-mips.org> <200712100036.lBA0aRWD016476@po-mbox303.hop.2iij.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200712100036.lBA0aRWD016476@po-mbox303.hop.2iij.net> User-Agent: Mutt/1.5.17 (2007-11-01) Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 17754 X-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 10, 2007 at 09:36:27AM +0900, Yoichi Yuasa wrote: > > On Sun, Dec 09, 2007 at 09:22:04PM +0900, Yoichi Yuasa wrote: > > > > > Set up Cobalt's mips_hpt_frequency. > > > > Queue for 2.6.25. Thanks, > > Cobalt cannot boot as this patch doesn't exist. > Please apply 2.6.24-rc too. Ah, sorry. Applied. Ralf From ralf@linux-mips.org Mon Dec 10 13:22:36 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 10 Dec 2007 13:22:38 +0000 (GMT) Received: from localhost.localdomain ([127.0.0.1]:21901 "EHLO dl5rb.ham-radio-op.net") by ftp.linux-mips.org with ESMTP id S20024464AbXLJNWg (ORCPT ); Mon, 10 Dec 2007 13:22:36 +0000 Received: from denk.linux-mips.net (denk.linux-mips.net [127.0.0.1]) by dl5rb.ham-radio-op.net (8.14.1/8.13.8) with ESMTP id lBADMJXp012909; Mon, 10 Dec 2007 13:22:20 GMT Received: (from ralf@localhost) by denk.linux-mips.net (8.14.1/8.14.1/Submit) id lBADMHBg012908; Mon, 10 Dec 2007 13:22:17 GMT Date: Mon, 10 Dec 2007 13:22:17 +0000 From: Ralf Baechle To: Sergei Shtylyov Cc: Yoichi Yuasa , linux-mips Subject: Re: [PATCH][MIPS] set up Cobalt's mips_hpt_frequency Message-ID: <20071210132217.GB11886@linux-mips.org> References: <20071209212204.5e50a697.yoichi_yuasa@tripeaks.co.jp> <475D2B21.7050206@ru.mvista.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <475D2B21.7050206@ru.mvista.com> User-Agent: Mutt/1.5.17 (2007-11-01) Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 17755 X-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 10, 2007 at 03:03:45PM +0300, Sergei Shtylyov wrote: >> diff -pruN -X mips/Documentation/dontdiff mips-orig/arch/mips/cobalt/time.c mips/arch/mips/cobalt/time.c >> --- mips-orig/arch/mips/cobalt/time.c 2007-12-06 18:27:02.689043750 +0900 >> +++ mips/arch/mips/cobalt/time.c 2007-12-09 17:13:37.916769000 +0900 >> @@ -27,9 +27,28 @@ >> void __init plat_time_init(void) >> { >> + u32 start, end; >> + int i = HZ / 10; >> + >> setup_pit_timer(); >> gt641xx_set_base_clock(GT641XX_BASE_CLOCK); >> - mips_timer_state = gt641xx_timer0_state; >> + /* >> + * MIPS counter frequency is measured between 100msec > > s/between/during/ Fixed. The patch which will go to Linus will have the typo fix comment folded into the actual mips_hpt_frequency patch. Ralf From ralf@linux-mips.org Mon Dec 10 15:14:28 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 10 Dec 2007 15:14:30 +0000 (GMT) Received: from localhost.localdomain ([127.0.0.1]:30643 "EHLO dl5rb.ham-radio-op.net") by ftp.linux-mips.org with ESMTP id S20024606AbXLJPO2 (ORCPT ); Mon, 10 Dec 2007 15:14:28 +0000 Received: from denk.linux-mips.net (denk.linux-mips.net [127.0.0.1]) by dl5rb.ham-radio-op.net (8.14.1/8.13.8) with ESMTP id lBAFE5dt019185; Mon, 10 Dec 2007 15:14:05 GMT Received: (from ralf@localhost) by denk.linux-mips.net (8.14.1/8.14.1/Submit) id lBAFE4XD019184; Mon, 10 Dec 2007 15:14:04 GMT Date: Mon, 10 Dec 2007 15:14:04 +0000 From: Ralf Baechle To: Sergei Shtylyov Cc: zhuzhenhua , linux-mips Subject: Re: is there a standard high res timer patch for mips? Message-ID: <20071210151404.GA8595@linux-mips.org> References: <50c9a2250712091718l75455353v1b86851a011eb4fe@mail.gmail.com> <475D2B86.603@ru.mvista.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <475D2B86.603@ru.mvista.com> User-Agent: Mutt/1.5.17 (2007-11-01) Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 17756 X-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 10, 2007 at 03:05:26PM +0300, Sergei Shtylyov wrote: >> i want to add the high res timer support for my kernel(version >> 2.6.14),and i found there are some patches: >> high-res-timers at sourceforge.net/projects/high-res-timers/high-res-timers >> Jun Sun's patch at >> http://linux.junsun.net/patches/oss.sgi.com/experimental/ >> Thomas Gleixner's patch at http://www.tglx.de/projects/hrtimers/ >> is there a standard high res timer patch for mips now? >> thanks for any hints > > Yes, Tohmas' patch is now included into the kernel. And the upcoming 2.6.24 kernel will be the first to support it. Ralf From macro@linux-mips.org Mon Dec 10 15:29:33 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 10 Dec 2007 15:29:41 +0000 (GMT) Received: from cerber.ds.pg.gda.pl ([153.19.208.18]:30140 "EHLO cerber.ds.pg.gda.pl") by ftp.linux-mips.org with ESMTP id S20024543AbXLJP3d (ORCPT ); Mon, 10 Dec 2007 15:29:33 +0000 Received: from localhost (unknown [127.0.0.17]) by cerber.ds.pg.gda.pl (Postfix) with ESMTP id 7FDDA400AB; Mon, 10 Dec 2007 16:29:03 +0100 (CET) X-Virus-Scanned: amavisd-new at cerber.ds.pg.gda.pl Received: from cerber.ds.pg.gda.pl ([153.19.208.18]) by localhost (cerber.ds.pg.gda.pl [153.19.208.18]) (amavisd-new, port 10024) with ESMTP id rT9zpoWVi3QP; Mon, 10 Dec 2007 16:28:58 +0100 (CET) Received: from piorun.ds.pg.gda.pl (piorun.ds.pg.gda.pl [153.19.208.8]) by cerber.ds.pg.gda.pl (Postfix) with ESMTP id 0E8CC4008C; Mon, 10 Dec 2007 16:28:58 +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 lBAFT2en028211; Mon, 10 Dec 2007 16:29:02 +0100 Date: Mon, 10 Dec 2007 15:28:52 +0000 (GMT) From: "Maciej W. Rozycki" To: Ralf Baechle cc: Kaz Kylheku , linux-mips@linux-mips.org Subject: Re: SiByte 1480 & Branch Likely instructions? In-Reply-To: <20071209051450.GA18181@linux-mips.org> Message-ID: References: <20071209051450.GA18181@linux-mips.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: ClamAV 0.91.2/5077/Mon Dec 10 14:59:40 2007 on piorun.ds.pg.gda.pl X-Virus-Status: Clean Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 17757 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: macro@linux-mips.org Precedence: bulk X-list: linux-mips On Sun, 9 Dec 2007, Ralf Baechle wrote: > > Not really a kernel-related question. I've discovered that GCC 4.1.1 > > (which I'm not using for kernel compiling, but user space) generates > > branch likely instructions by default, even though the documentation > > says that their use is off by default for MIPS32 and MIPS64, because > > they are considered deprecated. They are documented as obsolete for the > > Broadcom chips I am working with. > > Microarchitecture guys love to hate branch likely. But the deprecation is > a dream. Binary compatibility will always require those instructions to > continue to exist so the genie is out of the bottle and so I feel very > certain to predict that a future MIPS 3 specification will contain branch > likely. We have been there before -- binary compatibility does not preclude emulation. And I do not mean keeping the MIPS I toys (as they might be seen these days) running, but serious products deployed commercially, like newer VAX implementations that kept full binary compatibility with their predecessors in the area of the some of the more arcane instructions only by means of emulating them in the OS. Maciej From ralf@linux-mips.org Mon Dec 10 15:35:41 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 10 Dec 2007 15:35:43 +0000 (GMT) Received: from localhost.localdomain ([127.0.0.1]:18831 "EHLO dl5rb.ham-radio-op.net") by ftp.linux-mips.org with ESMTP id S20024672AbXLJPfl (ORCPT ); Mon, 10 Dec 2007 15:35:41 +0000 Received: from denk.linux-mips.net (denk.linux-mips.net [127.0.0.1]) by dl5rb.ham-radio-op.net (8.14.1/8.13.8) with ESMTP id lBAFZNpI019476; Mon, 10 Dec 2007 15:35:24 GMT Received: (from ralf@localhost) by denk.linux-mips.net (8.14.1/8.14.1/Submit) id lBAFZNm5019475; Mon, 10 Dec 2007 15:35:23 GMT Date: Mon, 10 Dec 2007 15:35:23 +0000 From: Ralf Baechle To: "Maciej W. Rozycki" Cc: Kaz Kylheku , linux-mips@linux-mips.org Subject: Re: SiByte 1480 & Branch Likely instructions? Message-ID: <20071210153523.GA19384@linux-mips.org> References: <20071209051450.GA18181@linux-mips.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.17 (2007-11-01) Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 17758 X-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 10, 2007 at 03:28:52PM +0000, Maciej W. Rozycki wrote: > > > Not really a kernel-related question. I've discovered that GCC 4.1.1 > > > (which I'm not using for kernel compiling, but user space) generates > > > branch likely instructions by default, even though the documentation > > > says that their use is off by default for MIPS32 and MIPS64, because > > > they are considered deprecated. They are documented as obsolete for the > > > Broadcom chips I am working with. > > > > Microarchitecture guys love to hate branch likely. But the deprecation is > > a dream. Binary compatibility will always require those instructions to > > continue to exist so the genie is out of the bottle and so I feel very > > certain to predict that a future MIPS 3 specification will contain branch > > likely. > > We have been there before -- binary compatibility does not preclude > emulation. And I do not mean keeping the MIPS I toys (as they might be > seen these days) running, but serious products deployed commercially, like > newer VAX implementations that kept full binary compatibility with their > predecessors in the area of the some of the more arcane instructions only > by means of emulating them in the OS. It would devastate the performance of some binaries. As an intellectual challenge, how far can you strip down a MIPS implementation and emulate removed instructions in the kernel ;-) Ralf From macro@linux-mips.org Mon Dec 10 16:20:41 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 10 Dec 2007 16:20:49 +0000 (GMT) Received: from cerber.ds.pg.gda.pl ([153.19.208.18]:5566 "EHLO cerber.ds.pg.gda.pl") by ftp.linux-mips.org with ESMTP id S20024841AbXLJQUl (ORCPT ); Mon, 10 Dec 2007 16:20:41 +0000 Received: from localhost (unknown [127.0.0.17]) by cerber.ds.pg.gda.pl (Postfix) with ESMTP id A7085400CE; Mon, 10 Dec 2007 17:20:41 +0100 (CET) X-Virus-Scanned: amavisd-new at cerber.ds.pg.gda.pl Received: from cerber.ds.pg.gda.pl ([153.19.208.18]) by localhost (cerber.ds.pg.gda.pl [153.19.208.18]) (amavisd-new, port 10024) with ESMTP id b97+h1i+5GXe; Mon, 10 Dec 2007 17:20:34 +0100 (CET) Received: from piorun.ds.pg.gda.pl (piorun.ds.pg.gda.pl [153.19.208.8]) by cerber.ds.pg.gda.pl (Postfix) with ESMTP id 177DA4008C; Mon, 10 Dec 2007 17:20:34 +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 lBAGKc3m006957; Mon, 10 Dec 2007 17:20:38 +0100 Date: Mon, 10 Dec 2007 16:20:27 +0000 (GMT) From: "Maciej W. Rozycki" To: Ralf Baechle cc: Kaz Kylheku , linux-mips@linux-mips.org Subject: Re: SiByte 1480 & Branch Likely instructions? In-Reply-To: <20071210153523.GA19384@linux-mips.org> Message-ID: References: <20071209051450.GA18181@linux-mips.org> <20071210153523.GA19384@linux-mips.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: ClamAV 0.91.2/5077/Mon Dec 10 14:59:40 2007 on piorun.ds.pg.gda.pl X-Virus-Status: Clean Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 17759 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: macro@linux-mips.org Precedence: bulk X-list: linux-mips On Mon, 10 Dec 2007, Ralf Baechle wrote: > It would devastate the performance of some binaries. I think this is what the deprecation is about. ;-) > As an intellectual challenge, how far can you strip down a MIPS > implementation and emulate removed instructions in the kernel ;-) Well, going back to MIPS I is certainly achievable (OK, we could keep ll/sc for the sake of sanity) and then perhaps a little bit further. After all, all of the ALU ops can be done with the NOR op only. ;-) Maciej From sshtylyov@ru.mvista.com Mon Dec 10 17:28:31 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 10 Dec 2007 17:28:39 +0000 (GMT) Received: from rtsoft3.corbina.net ([85.21.88.6]:63823 "EHLO buildserver.ru.mvista.com") by ftp.linux-mips.org with ESMTP id S20024935AbXLJR2b (ORCPT ); Mon, 10 Dec 2007 17:28:31 +0000 Received: from wasted.dev.rtsoft.ru (unknown [10.150.0.9]) by buildserver.ru.mvista.com (Postfix) with ESMTP id D2B408816; Mon, 10 Dec 2007 22:28:29 +0400 (SAMT) From: Sergei Shtylyov Organization: MontaVista Software Inc. To: ralf@linux-mips.org Subject: [PATCH] Alchemy: fix PCI resource conflict (take 2) Date: Mon, 10 Dec 2007 20:28:51 +0300 User-Agent: KMail/1.5 Cc: linux-mips@linux-mips.org MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200712102028.51448.sshtylyov@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: 17760 X-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 ... by getting the PCI resources back into the 32-bit range -- there's no need therefore for CONFIG_RESOURCES_64BIT either. This makes Alchemy PCI work again while currently the kernel skips the bus scan. Signed-off-by: Sergei Shtylyov --- arch/mips/au1000/Kconfig | 9 --------- arch/mips/au1000/common/pci.c | 8 ++++---- include/asm-mips/mach-au1x00/au1000.h | 9 +++++---- 3 files changed, 9 insertions(+), 17 deletions(-) Index: linux-2.6/arch/mips/au1000/Kconfig =================================================================== --- linux-2.6.orig/arch/mips/au1000/Kconfig +++ linux-2.6/arch/mips/au1000/Kconfig @@ -7,7 +7,6 @@ config MIPS_MTX1 bool "4G Systems MTX-1 board" select DMA_NONCOHERENT select HW_HAS_PCI - select RESOURCES_64BIT if PCI select SOC_AU1500 select SYS_SUPPORTS_LITTLE_ENDIAN @@ -22,7 +21,6 @@ config MIPS_DB1000 select SOC_AU1000 select DMA_NONCOHERENT select HW_HAS_PCI - select RESOURCES_64BIT if PCI select SYS_SUPPORTS_LITTLE_ENDIAN config MIPS_DB1100 @@ -44,7 +42,6 @@ config MIPS_DB1500 select DMA_NONCOHERENT select HW_HAS_PCI select MIPS_DISABLE_OBSOLETE_IDE - select RESOURCES_64BIT if PCI select SYS_SUPPORTS_BIG_ENDIAN select SYS_SUPPORTS_LITTLE_ENDIAN @@ -54,7 +51,6 @@ config MIPS_DB1550 select HW_HAS_PCI select DMA_NONCOHERENT select MIPS_DISABLE_OBSOLETE_IDE - select RESOURCES_64BIT if PCI select SYS_SUPPORTS_LITTLE_ENDIAN config MIPS_MIRAGE @@ -68,7 +64,6 @@ config MIPS_PB1000 select SOC_AU1000 select DMA_NONCOHERENT select HW_HAS_PCI - select RESOURCES_64BIT if PCI select SWAP_IO_SPACE select SYS_SUPPORTS_LITTLE_ENDIAN @@ -77,7 +72,6 @@ config MIPS_PB1100 select SOC_AU1100 select DMA_NONCOHERENT select HW_HAS_PCI - select RESOURCES_64BIT if PCI select SWAP_IO_SPACE select SYS_SUPPORTS_LITTLE_ENDIAN @@ -86,7 +80,6 @@ config MIPS_PB1200 select SOC_AU1200 select DMA_NONCOHERENT select MIPS_DISABLE_OBSOLETE_IDE - select RESOURCES_64BIT if PCI select SYS_SUPPORTS_LITTLE_ENDIAN config MIPS_PB1500 @@ -94,7 +87,6 @@ config MIPS_PB1500 select SOC_AU1500 select DMA_NONCOHERENT select HW_HAS_PCI - select RESOURCES_64BIT if PCI select SYS_SUPPORTS_LITTLE_ENDIAN config MIPS_PB1550 @@ -103,7 +95,6 @@ config MIPS_PB1550 select DMA_NONCOHERENT select HW_HAS_PCI select MIPS_DISABLE_OBSOLETE_IDE - select RESOURCES_64BIT if PCI select SYS_SUPPORTS_LITTLE_ENDIAN config MIPS_XXS1500 Index: linux-2.6/arch/mips/au1000/common/pci.c =================================================================== --- linux-2.6.orig/arch/mips/au1000/common/pci.c +++ linux-2.6/arch/mips/au1000/common/pci.c @@ -39,15 +39,15 @@ /* TBD */ static struct resource pci_io_resource = { - .start = (resource_size_t)PCI_IO_START, - .end = (resource_size_t)PCI_IO_END, + .start = PCI_IO_START, + .end = PCI_IO_END, .name = "PCI IO space", .flags = IORESOURCE_IO }; static struct resource pci_mem_resource = { - .start = (resource_size_t)PCI_MEM_START, - .end = (resource_size_t)PCI_MEM_END, + .start = PCI_MEM_START, + .end = PCI_MEM_END, .name = "PCI memory space", .flags = IORESOURCE_MEM }; Index: linux-2.6/include/asm-mips/mach-au1x00/au1000.h =================================================================== --- linux-2.6.orig/include/asm-mips/mach-au1x00/au1000.h +++ linux-2.6/include/asm-mips/mach-au1x00/au1000.h @@ -1680,10 +1680,11 @@ enum soc_au1200_ints { #define Au1500_PCI_MEM_START 0x440000000ULL #define Au1500_PCI_MEM_END 0x44FFFFFFFULL -#define PCI_IO_START (Au1500_PCI_IO_START + 0x1000) -#define PCI_IO_END (Au1500_PCI_IO_END) -#define PCI_MEM_START (Au1500_PCI_MEM_START) -#define PCI_MEM_END (Au1500_PCI_MEM_END) +#define PCI_IO_START 0x00001000 +#define PCI_IO_END 0x000FFFFF +#define PCI_MEM_START 0x40000000 +#define PCI_MEM_END 0x4FFFFFFF + #define PCI_FIRST_DEVFN (0<<3) #define PCI_LAST_DEVFN (19<<3) From sshtylyov@ru.mvista.com Mon Dec 10 17:36:29 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 10 Dec 2007 17:36:38 +0000 (GMT) Received: from rtsoft3.corbina.net ([85.21.88.6]:1360 "EHLO buildserver.ru.mvista.com") by ftp.linux-mips.org with ESMTP id S20025032AbXLJRg3 (ORCPT ); Mon, 10 Dec 2007 17:36:29 +0000 Received: from wasted.dev.rtsoft.ru (unknown [10.150.0.9]) by buildserver.ru.mvista.com (Postfix) with ESMTP id E09B48816; Mon, 10 Dec 2007 22:36:28 +0400 (SAMT) From: Sergei Shtylyov Organization: MontaVista Software Inc. To: ralf@linux-mips.org Subject: [PATCH] Alchemy: fix off by two error in __fixup_bigphys_addr() Date: Mon, 10 Dec 2007 20:36:50 +0300 User-Agent: KMail/1.5 Cc: linux-mips@linux-mips.org MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Message-Id: <200712102036.50247.sshtylyov@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: 17761 X-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 he PCI specific code in this function doesn't check for the address range being under the upper bound of the PCI memory window correctly -- fix this, somewhat beautifying the code around the check, while at it... Signed-off-by: Sergei Shtylyov --- arch/mips/au1000/common/setup.c | 9 ++++----- 1 files changed, 4 insertions(+), 5 deletions(-) Index: linux-2.6/arch/mips/au1000/common/setup.c =================================================================== --- linux-2.6.orig/arch/mips/au1000/common/setup.c +++ linux-2.6/arch/mips/au1000/common/setup.c @@ -137,12 +137,11 @@ phys_t __fixup_bigphys_addr(phys_t phys_ #ifdef CONFIG_PCI { - u32 start, end; + u32 start = (u32)Au1500_PCI_MEM_START; + u32 end = (u32)Au1500_PCI_MEM_END; - start = (u32)Au1500_PCI_MEM_START; - end = (u32)Au1500_PCI_MEM_END; - /* check for pci memory window */ - if ((phys_addr >= start) && ((phys_addr + size) < end)) + /* Check for PCI memory window */ + if (phys_addr >= start && (phys_addr + size - 1) <= end) return (phys_t) ((phys_addr - start) + Au1500_PCI_MEM_START); } From nathan_eggan@live.com Mon Dec 10 17:43:37 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 10 Dec 2007 17:43:46 +0000 (GMT) Received: from blu139-omc1-s2.blu139.hotmail.com ([65.55.175.142]:39560 "EHLO blu139-omc1-s2.blu139.hotmail.com") by ftp.linux-mips.org with ESMTP id S20025054AbXLJRnh convert rfc822-to-8bit (ORCPT ); Mon, 10 Dec 2007 17:43:37 +0000 Received: from BLU127-W16 ([65.55.162.181]) by blu139-omc1-s2.blu139.hotmail.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 10 Dec 2007 09:43:09 -0800 Message-ID: X-Originating-IP: [157.185.36.161] From: Nathan Eggan To: linux-mips mailing list Subject: RE: [PATCH] Alchemy: fix PCI resource conflict (take 2) Date: Mon, 10 Dec 2007 17:43:09 +0000 Importance: Normal In-Reply-To: <200712102028.51448.sshtylyov@ru.mvista.com> References: <200712102028.51448.sshtylyov@ru.mvista.com> Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8BIT MIME-Version: 1.0 X-OriginalArrivalTime: 10 Dec 2007 17:43:09.0186 (UTC) FILETIME=[20B19620:01C83B54] Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 17762 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: nathan_eggan@live.com Precedence: bulk X-list: linux-mips Any chance this will help fix my Au1x00 serial + USB issues? I know the old PCI bus code used to not work with the USB - at least the two could not run together. It's been a while since I looked at those issues, so that may have been resolved long ago. Just curious, Thanks! Nate ---------------------------------------- > From: sshtylyov@ru.mvista.com > To: ralf@linux-mips.org > Subject: [PATCH] Alchemy: fix PCI resource conflict (take 2) > Date: Mon, 10 Dec 2007 20:28:51 +0300 > CC: linux-mips@linux-mips.org > > ... by getting the PCI resources back into the 32-bit range -- there's no need > therefore for CONFIG_RESOURCES_64BIT either. This makes Alchemy PCI work again > while currently the kernel skips the bus scan. > > Signed-off-by: Sergei Shtylyov > > --- > arch/mips/au1000/Kconfig | 9 --------- > arch/mips/au1000/common/pci.c | 8 ++++---- > include/asm-mips/mach-au1x00/au1000.h | 9 +++++---- > 3 files changed, 9 insertions(+), 17 deletions(-) > > Index: linux-2.6/arch/mips/au1000/Kconfig > =================================================================== > --- linux-2.6.orig/arch/mips/au1000/Kconfig > +++ linux-2.6/arch/mips/au1000/Kconfig > @@ -7,7 +7,6 @@ config MIPS_MTX1 > bool "4G Systems MTX-1 board" > select DMA_NONCOHERENT > select HW_HAS_PCI > - select RESOURCES_64BIT if PCI > select SOC_AU1500 > select SYS_SUPPORTS_LITTLE_ENDIAN > > @@ -22,7 +21,6 @@ config MIPS_DB1000 > select SOC_AU1000 > select DMA_NONCOHERENT > select HW_HAS_PCI > - select RESOURCES_64BIT if PCI > select SYS_SUPPORTS_LITTLE_ENDIAN > > config MIPS_DB1100 > @@ -44,7 +42,6 @@ config MIPS_DB1500 > select DMA_NONCOHERENT > select HW_HAS_PCI > select MIPS_DISABLE_OBSOLETE_IDE > - select RESOURCES_64BIT if PCI > select SYS_SUPPORTS_BIG_ENDIAN > select SYS_SUPPORTS_LITTLE_ENDIAN > > @@ -54,7 +51,6 @@ config MIPS_DB1550 > select HW_HAS_PCI > select DMA_NONCOHERENT > select MIPS_DISABLE_OBSOLETE_IDE > - select RESOURCES_64BIT if PCI > select SYS_SUPPORTS_LITTLE_ENDIAN > > config MIPS_MIRAGE > @@ -68,7 +64,6 @@ config MIPS_PB1000 > select SOC_AU1000 > select DMA_NONCOHERENT > select HW_HAS_PCI > - select RESOURCES_64BIT if PCI > select SWAP_IO_SPACE > select SYS_SUPPORTS_LITTLE_ENDIAN > > @@ -77,7 +72,6 @@ config MIPS_PB1100 > select SOC_AU1100 > select DMA_NONCOHERENT > select HW_HAS_PCI > - select RESOURCES_64BIT if PCI > select SWAP_IO_SPACE > select SYS_SUPPORTS_LITTLE_ENDIAN > > @@ -86,7 +80,6 @@ config MIPS_PB1200 > select SOC_AU1200 > select DMA_NONCOHERENT > select MIPS_DISABLE_OBSOLETE_IDE > - select RESOURCES_64BIT if PCI > select SYS_SUPPORTS_LITTLE_ENDIAN > > config MIPS_PB1500 > @@ -94,7 +87,6 @@ config MIPS_PB1500 > select SOC_AU1500 > select DMA_NONCOHERENT > select HW_HAS_PCI > - select RESOURCES_64BIT if PCI > select SYS_SUPPORTS_LITTLE_ENDIAN > > config MIPS_PB1550 > @@ -103,7 +95,6 @@ config MIPS_PB1550 > select DMA_NONCOHERENT > select HW_HAS_PCI > select MIPS_DISABLE_OBSOLETE_IDE > - select RESOURCES_64BIT if PCI > select SYS_SUPPORTS_LITTLE_ENDIAN > > config MIPS_XXS1500 > Index: linux-2.6/arch/mips/au1000/common/pci.c > =================================================================== > --- linux-2.6.orig/arch/mips/au1000/common/pci.c > +++ linux-2.6/arch/mips/au1000/common/pci.c > @@ -39,15 +39,15 @@ > > /* TBD */ > static struct resource pci_io_resource = { > - .start = (resource_size_t)PCI_IO_START, > - .end = (resource_size_t)PCI_IO_END, > + .start = PCI_IO_START, > + .end = PCI_IO_END, > .name = "PCI IO space", > .flags = IORESOURCE_IO > }; > > static struct resource pci_mem_resource = { > - .start = (resource_size_t)PCI_MEM_START, > - .end = (resource_size_t)PCI_MEM_END, > + .start = PCI_MEM_START, > + .end = PCI_MEM_END, > .name = "PCI memory space", > .flags = IORESOURCE_MEM > }; > Index: linux-2.6/include/asm-mips/mach-au1x00/au1000.h > =================================================================== > --- linux-2.6.orig/include/asm-mips/mach-au1x00/au1000.h > +++ linux-2.6/include/asm-mips/mach-au1x00/au1000.h > @@ -1680,10 +1680,11 @@ enum soc_au1200_ints { > #define Au1500_PCI_MEM_START 0x440000000ULL > #define Au1500_PCI_MEM_END 0x44FFFFFFFULL > > -#define PCI_IO_START (Au1500_PCI_IO_START + 0x1000) > -#define PCI_IO_END (Au1500_PCI_IO_END) > -#define PCI_MEM_START (Au1500_PCI_MEM_START) > -#define PCI_MEM_END (Au1500_PCI_MEM_END) > +#define PCI_IO_START 0x00001000 > +#define PCI_IO_END 0x000FFFFF > +#define PCI_MEM_START 0x40000000 > +#define PCI_MEM_END 0x4FFFFFFF > + > #define PCI_FIRST_DEVFN (0<<3) > #define PCI_LAST_DEVFN (19<<3) > > > _________________________________________________________________ Connect and share in new ways with Windows Live. http://www.windowslive.com/connect.html?ocid=TXT_TAGLM_Wave2_newways_112007 From sshtylyov@ru.mvista.com Mon Dec 10 17:47:46 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 10 Dec 2007 17:47:55 +0000 (GMT) Received: from h155.mvista.com ([63.81.120.155]:61635 "EHLO imap.sh.mvista.com") by ftp.linux-mips.org with ESMTP id S20025092AbXLJRrq (ORCPT ); Mon, 10 Dec 2007 17:47:46 +0000 Received: from [192.168.1.234] (unknown [10.150.0.9]) by imap.sh.mvista.com (Postfix) with ESMTP id 7C24D3ECD; Mon, 10 Dec 2007 09:47:43 -0800 (PST) Message-ID: <475D7BD4.1050505@ru.mvista.com> Date: Mon, 10 Dec 2007 20:48:04 +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: Nathan Eggan Cc: linux-mips mailing list Subject: Re: [PATCH] Alchemy: fix PCI resource conflict (take 2) References: <200712102028.51448.sshtylyov@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: 17763 X-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 Nathan Eggan wrote: > Any chance this will help fix my Au1x00 serial + USB issues? I don't think so. > I know the old PCI bus code used to not work with the USB - at least the two could not run together. There are some chip errata connected with USB and PCI... WBR, Sergei From ricmm@kanux.com Mon Dec 10 21:55:32 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 10 Dec 2007 21:55:40 +0000 (GMT) Received: from rs26s12.datacenter.cha.cantv.net ([200.44.33.42]:20163 "EHLO rs26s12.datacenter.cha.cantv.net") by ftp.linux-mips.org with ESMTP id S20022240AbXLJVzc (ORCPT ); Mon, 10 Dec 2007 21:55:32 +0000 Received: from [192.168.0.2] (dC9D088C0.dslam-04-10-6-02-1-01.apr.dsl.cantv.net [201.208.136.192]) by rs26s12.datacenter.cha.cantv.net (8.13.8/8.13.0/3.0) with ESMTP id lBALtCLh007514; Mon, 10 Dec 2007 17:25:14 -0430 X-Matched-Lists: [] Message-ID: <475D7FE2.7080703@kanux.com> Date: Mon, 10 Dec 2007 14:05:22 -0400 From: Ricardo Mendoza User-Agent: Thunderbird 2.0.0.0 (X11/20070601) MIME-Version: 1.0 To: Giuseppe Sacco CC: linux-mips@linux-mips.org Subject: Re: 2.6.24-rc1 does not boot on SGI References: <1193468825.7474.6.camel@scarafaggio> <20071029.000713.59464443.anemo@mba.ocn.ne.jp> <1193599031.14874.1.camel@scarafaggio> <20071029150625.GB4165@linux-mips.org> <1194268551.4842.3.camel@scarafaggio> <1194281699.4192.3.camel@casa> <1197287929.17265.6.camel@scarafaggio> In-Reply-To: <1197287929.17265.6.camel@scarafaggio> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV version 0.91.2, clamav-milter version 0.91.2 on 10.128.1.89 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: 17764 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: ricmm@kanux.com Precedence: bulk X-list: linux-mips Giuseppe Sacco wrote: > I reply to my own message, providing more details, hoping that anyone > here could give a hint or the solution. > > During bootup on ip32, since 2.4.24-rc1, the system loop printing a > message about unexpected interrupt #13. (see transcript below.) > > I enabled more debug in the kernel, and studied the code. What I > understood is that interrupt #13 from CRIME means that the system should > check on MACEISA for the real interrupt. > > The interrupt start appearing just after executing the code > psmouse_init() that enable ps2 drivers for keyboard and mouse. Keyboard > interrupt #49 is enabled first and mouse interrupt #51 is enabled later. > > When initialising the keyboard interrupt (it is a MACEISA interrupt), > the interrupt start appearing, so I am pretty sure that interrupt #13 is > related to the keyboard interrupt. > > When the system receive interrupt #13, it correctly detect it is a > MACEISA interrupt, and check for mace->perif.ctrl.istat value. The > problem seems to be that this value is zero instead of having bit #9 on > (that would mean, interrupt #49, keyboard). > > So, either the interrupt #49 is not correctly enabled, or maceisa > interrupt aren't correctly checked. > > Does this description ring a bell to anyone? > > Bye, > Giuseppe > > Calling initcall 0xffffffff80496ca0: serport_init+0x0/0x48() > initcall 0xffffffff80496ca0: serport_init+0x0/0x48() returned 0. > initcall 0xffffffff80496ca0 ran for 0 msecs: serport_init+0x0/0x48() > Calling initcall 0xffffffff80496ce8: maceps2_init+0x0/0xe0() > initcall 0xffffffff80496ce8: maceps2_init+0x0/0xe0() returned 0. > initcall 0xffffffff80496ce8 ran for 1 msecs: maceps2_init+0x0/0xe0() > Calling initcall 0xffffffff80496dc8: serio_raw_init+0x0/0x18() > initcall 0xffffffff80496dc8: serio_raw_init+0x0/0x18() returned 0. > initcall 0xffffffff80496dc8 ran for 1 msecs: serio_raw_init+0x0/0x18() > Calling initcall 0xffffffff80496f40: mousedev_init+0x0/0xd0() > mice: PS/2 mouse device common for all mice > initcall 0xffffffff80496f40: mousedev_init+0x0/0xd0() returned 0. > initcall 0xffffffff80496f40 ran for 16 msecs: mousedev_init+0x0/0xd0() > Calling initcall 0xffffffff80497010: atkbd_init+0x0/0x18() > initcall 0xffffffff80497010: atkbd_init+0x0/0x18() returned 0. > initcall 0xffffffff80497010 ran for 0 msecs: atkbd_init+0x0/0x18() > Calling initcall 0xffffffff80497028: psmouse_init+0x0/0x90() > maceisa enable: 49 > crime_int 00000020 enabled > *irq 13, crime_int=00002000, crime_mask=003003a0, mace_int=00000000* > irq 13, desc: ffffffff80448390, depth: 1, count: 0, unhandled: 0 > ->handle_irq(): ffffffff80065eb0, handle_bad_irq+0x0/0x2c0 > ->chip(): ffffffff8043e320, 0xffffffff8043e320 > ->action(): 0000000000000000 > IRQ_DISABLED set I recommend you pull latest git. Looks like some issue that Ralf and I fixed a few weeks ago. Ricardo From giuseppe@eppesuigoccas.homedns.org Tue Dec 11 05:38:39 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 11 Dec 2007 05:38:47 +0000 (GMT) Received: from host188-210-dynamic.20-79-r.retail.telecomitalia.it ([79.20.210.188]:23270 "EHLO eppesuigoccas.homedns.org") by ftp.linux-mips.org with ESMTP id S20022392AbXLKFij (ORCPT ); Tue, 11 Dec 2007 05:38:39 +0000 Received: from eppesuig3 ([192.168.2.50]) by eppesuigoccas.homedns.org with esmtpsa (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from ) id 1J1xm5-0005o8-Kf; Tue, 11 Dec 2007 06:35:23 +0100 Subject: Re: 2.6.24-rc1 does not boot on SGI From: Giuseppe Sacco To: Ricardo Mendoza Cc: linux-mips@linux-mips.org In-Reply-To: <475D7FE2.7080703@kanux.com> References: <1193468825.7474.6.camel@scarafaggio> <20071029.000713.59464443.anemo@mba.ocn.ne.jp> <1193599031.14874.1.camel@scarafaggio> <20071029150625.GB4165@linux-mips.org> <1194268551.4842.3.camel@scarafaggio> <1194281699.4192.3.camel@casa> <1197287929.17265.6.camel@scarafaggio> <475D7FE2.7080703@kanux.com> Content-Type: text/plain Date: Tue, 11 Dec 2007 06:35:59 +0100 Message-Id: <1197351359.7889.3.camel@scarafaggio> Mime-Version: 1.0 X-Mailer: Evolution 2.10.3 Content-Transfer-Encoding: 7bit Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 17765 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: giuseppe@eppesuigoccas.homedns.org Precedence: bulk X-list: linux-mips Hi Ricardo, Il giorno lun, 10/12/2007 alle 14.05 -0400, Ricardo Mendoza ha scritto: [...] > > maceisa enable: 49 > > crime_int 00000020 enabled > > *irq 13, crime_int=00002000, crime_mask=003003a0, mace_int=00000000* > > irq 13, desc: ffffffff80448390, depth: 1, count: 0, unhandled: 0 > > ->handle_irq(): ffffffff80065eb0, handle_bad_irq+0x0/0x2c0 > > ->chip(): ffffffff8043e320, 0xffffffff8043e320 > > ->action(): 0000000000000000 > > IRQ_DISABLED set > > I recommend you pull latest git. Looks like some issue that Ralf and I > fixed a few weeks ago. I am using git (from linux-mips.org) of two or three days ago, but I will try if anything is changed in the meantime. Thanks, Giuseppe From aurel32@hall.aurel32.net Tue Dec 11 10:33:48 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 11 Dec 2007 10:33:57 +0000 (GMT) Received: from hall.aurel32.net ([88.191.38.19]:59616 "EHLO hall.aurel32.net") by ftp.linux-mips.org with ESMTP id S20022730AbXLKKds (ORCPT ); Tue, 11 Dec 2007 10:33:48 +0000 Received: from aurel32 by hall.aurel32.net with local (Exim 4.63) (envelope-from ) id 1J22Nm-0003DB-Eq; Tue, 11 Dec 2007 11:30:34 +0100 Date: Tue, 11 Dec 2007 11:30:34 +0100 From: Aurelien Jarno To: Ralf Baechle Cc: linux-mips@linux-mips.org Subject: [PATCH][MIPS] Kconfig fixes for BCM47XX platform Message-ID: <20071211103034.GA11972@hall.aurel32.net> References: <20071210102232.GA10145@hall.aurel32.net> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-15 Content-Disposition: inline In-Reply-To: <20071210102232.GA10145@hall.aurel32.net> X-Mailer: Mutt 1.5.13 (2006-08-11) User-Agent: Mutt/1.5.13 (2006-08-11) Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 17766 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: aurelien@aurel32.net Precedence: bulk X-list: linux-mips Hi, The patch below fixes two problems for Kconfig on the BCM47xx platform: - arch/mips/bcm47xx/gpio.c uses ssb_extif_* functions. Selecting SSB_DRIVER_EXTIF makes sure those functions are available. - arch/mips/pci/pci.c needs, when enabled, platform specific functions, which are defined when SSB_PCICORE_HOSTMODE is enabled. This patch replaces the one called "Enable SSB_DRIVER_EXTIF on BCM47XX platform" posted yesterday. Aurelien Signed-off-by: Aurelien Jarno diff --git a/arch/mips/Kconfig b/arch/mips/Kconfig index c6fc405..b4ffcae 100644 --- a/arch/mips/Kconfig +++ b/arch/mips/Kconfig @@ -59,6 +59,8 @@ config BCM47XX select SYS_SUPPORTS_LITTLE_ENDIAN select SSB select SSB_DRIVER_MIPS + select SSB_DRIVER_EXTIF + select SSB_PCICORE_HOSTMODE if PCI select GENERIC_GPIO select SYS_HAS_EARLY_PRINTK select CFE -- .''`. Aurelien Jarno | GPG: 1024D/F1BCDB73 : :' : Debian developer | Electrical Engineer `. `' aurel32@debian.org | aurelien@aurel32.net `- people.debian.org/~aurel32 | www.aurel32.net From giuseppe@eppesuigoccas.homedns.org Tue Dec 11 11:07:27 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 11 Dec 2007 11:07:36 +0000 (GMT) Received: from host188-210-dynamic.20-79-r.retail.telecomitalia.it ([79.20.210.188]:13988 "EHLO eppesuigoccas.homedns.org") by ftp.linux-mips.org with ESMTP id S20026909AbXLKLH1 (ORCPT ); Tue, 11 Dec 2007 11:07:27 +0000 Received: from eppesuig3 ([192.168.2.50]) by eppesuigoccas.homedns.org with esmtpsa (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from ) id 1J22uK-0005wd-2h for linux-mips@linux-mips.org; Tue, 11 Dec 2007 12:04:14 +0100 Subject: Still no 2.6.24 on ip32 [was: Re: 2.6.24-rc1 does not boot on SGI] From: Giuseppe Sacco To: linux-mips@linux-mips.org In-Reply-To: <475D7FE2.7080703@kanux.com> References: <1193468825.7474.6.camel@scarafaggio> <20071029.000713.59464443.anemo@mba.ocn.ne.jp> <1193599031.14874.1.camel@scarafaggio> <20071029150625.GB4165@linux-mips.org> <1194268551.4842.3.camel@scarafaggio> <1194281699.4192.3.camel@casa> <1197287929.17265.6.camel@scarafaggio> <475D7FE2.7080703@kanux.com> Content-Type: text/plain Date: Tue, 11 Dec 2007 12:04:55 +0100 Message-Id: <1197371095.7889.24.camel@scarafaggio> Mime-Version: 1.0 X-Mailer: Evolution 2.10.3 Content-Transfer-Encoding: 7bit Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 17767 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: giuseppe@eppesuigoccas.homedns.org Precedence: bulk X-list: linux-mips Il giorno lun, 10/12/2007 alle 14.05 -0400, Ricardo Mendoza ha scritto: [...] > > Calling initcall 0xffffffff80497028: psmouse_init+0x0/0x90() > > maceisa enable: 49 > > crime_int 00000020 enabled > > *irq 13, crime_int=00002000, crime_mask=003003a0, mace_int=00000000* > > irq 13, desc: ffffffff80448390, depth: 1, count: 0, unhandled: 0 > > ->handle_irq(): ffffffff80065eb0, handle_bad_irq+0x0/0x2c0 > > ->chip(): ffffffff8043e320, 0xffffffff8043e320 > > ->action(): 0000000000000000 > > IRQ_DISABLED set > > I recommend you pull latest git. Looks like some issue that Ralf and I > fixed a few weeks ago. I just checked that my repository is up to date, so my problem is still there (thus I don't know if it is the same problem you fixed). BTW, what was the problem you fixed? I would like to have a look to it, to better understand what's going on there. Thanks, Giuseppe From ralf@linux-mips.org Tue Dec 11 12:12:51 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 11 Dec 2007 12:12:54 +0000 (GMT) Received: from localhost.localdomain ([127.0.0.1]:22410 "EHLO dl5rb.ham-radio-op.net") by ftp.linux-mips.org with ESMTP id S20026954AbXLKMMv (ORCPT ); Tue, 11 Dec 2007 12:12:51 +0000 Received: from denk.linux-mips.net (denk.linux-mips.net [127.0.0.1]) by dl5rb.ham-radio-op.net (8.14.1/8.13.8) with ESMTP id lBBCCLVo010998; Tue, 11 Dec 2007 12:12:22 GMT Received: (from ralf@localhost) by denk.linux-mips.net (8.14.1/8.14.1/Submit) id lBBCCKSm010997; Tue, 11 Dec 2007 12:12:20 GMT Date: Tue, 11 Dec 2007 12:12:20 +0000 From: Ralf Baechle To: linux-mips@linux-mips.org, Yoichi Yuasa Subject: Cobalt fixes Message-ID: <20071211121220.GA10870@linux-mips.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.17 (2007-11-01) Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 17768 X-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 Some may have been following the beginning of this thread on linux-kernel, see for example http://www.opensubscriber.com/message/linux-kernel@vger.kernel.org/8161812.html for non-subscribers. Linus has reverted the offending patch fd6e732186ab522c812ab19c2c5e5befb8ec8115 in question so now the PCI and I/O port code needs to be fixed up to be able to handle such a setup. A test report of this patch which is meant to be applied on top of today's lmo git kernel on a Cobalt would be appreciated. Ralf [MIPS] Cobalt: Sort out legacy I/O port addressing. Thanks to the brainfucked GT-64111 which passes CPU addresses in the PCI I/O window to the PCI bus without any translation a Cobalt cannot generate a low I/O port address that is below < 0x10000000 in the GT-64111 default configuration. Fortunately the VIA VT82C586 southbridge used in Cobalts only decodes the low 16 bits of the I/O port address for its legacy devices. This can be exploited to generate equivalent addresses but need to use an address different from mips_io_port_base as the base to work. In addition PCI fixups need to be prevented from tinkering with legacy addresses. Signed-off-by: Ralf Baechle diff --git a/arch/mips/cobalt/pci.c b/arch/mips/cobalt/pci.c index cfce7af..b1fc6bd 100644 --- a/arch/mips/cobalt/pci.c +++ b/arch/mips/cobalt/pci.c @@ -24,8 +24,8 @@ static struct resource cobalt_mem_resource = { }; static struct resource cobalt_io_resource = { - .start = 0x1000, - .end = GT_DEF_PCI0_IO_SIZE - 1, + .start = GT_DEF_PCI0_IO_BASE + 0x1000, + .end = GT_DEF_PCI0_IO_BASE + GT_DEF_PCI0_IO_SIZE - 1, .name = "PCI I/O", .flags = IORESOURCE_IO, }; @@ -34,7 +34,7 @@ static struct pci_controller cobalt_pci_controller = { .pci_ops = >64xxx_pci0_ops, .mem_resource = &cobalt_mem_resource, .io_resource = &cobalt_io_resource, - .io_offset = 0 - GT_DEF_PCI0_IO_BASE, + .io_offset = 0, .io_map_base = CKSEG1ADDR(GT_DEF_PCI0_IO_BASE), }; diff --git a/arch/mips/cobalt/setup.c b/arch/mips/cobalt/setup.c index dd23beb..f99eaa9 100644 --- a/arch/mips/cobalt/setup.c +++ b/arch/mips/cobalt/setup.c @@ -79,10 +79,11 @@ void __init plat_mem_setup(void) _machine_halt = cobalt_machine_halt; pm_power_off = cobalt_machine_halt; - set_io_port_base(CKSEG1ADDR(GT_DEF_PCI0_IO_BASE)); + set_io_port_base(IO_BASE); + set_legacy_io_port_base(CKSEG1ADDR(GT_DEF_PCI0_IO_BASE)); /* I/O port resource must include LCD/buttons */ - ioport_resource.end = 0x0fffffff; + ioport_resource.end = GT_DEF_PCI0_IO_BASE + GT_DEF_PCI0_IO_SIZE - 1; /* These resources have been reserved by VIA SuperI/O chip. */ for (i = 0; i < ARRAY_SIZE(cobalt_reserved_resources); i++) diff --git a/arch/mips/kernel/setup.c b/arch/mips/kernel/setup.c index 7f6ddcb..f8b3f5a 100644 --- a/arch/mips/kernel/setup.c +++ b/arch/mips/kernel/setup.c @@ -60,11 +60,14 @@ static char command_line[CL_SIZE]; char arcs_cmdline[CL_SIZE]=CONFIG_CMDLINE; /* - * mips_io_port_base is the begin of the address space to which x86 style - * I/O ports are mapped. + * mips_io_port_base is the base of the address range into which the I/O ports + * are mapped. mips_legacy_io_port_base is the same but used only for legacy + * addresses below legacy_io_port_top. */ const unsigned long mips_io_port_base __read_mostly = -1; EXPORT_SYMBOL(mips_io_port_base); +const unsigned long mips_legacy_io_port_base __read_mostly = -1; +EXPORT_SYMBOL(mips_legacy_io_port_base); /* * isa_slot_offset is the address where E(ISA) busaddress 0 is mapped diff --git a/arch/mips/pci/fixup-cobalt.c b/arch/mips/pci/fixup-cobalt.c index f7df114..7da133b 100644 --- a/arch/mips/pci/fixup-cobalt.c +++ b/arch/mips/pci/fixup-cobalt.c @@ -51,6 +51,18 @@ static void qube_raq_galileo_early_fixup(struct pci_dev *dev) DECLARE_PCI_FIXUP_EARLY(PCI_VENDOR_ID_MARVELL, PCI_DEVICE_ID_MARVELL_GT64111, qube_raq_galileo_early_fixup); +static void __devinit cobalt_via_ide_native_mode_fixup(struct pci_dev *dev) +{ + unsigned char pif; + + pci_read_config_byte(dev, PCI_CLASS_PROG, &pif); + pif |= 4; + pci_write_config_byte(dev, PCI_CLASS_PROG, pif); +} + +DECLARE_PCI_FIXUP_EARLY(PCI_VENDOR_ID_VIA, PCI_DEVICE_ID_VIA_82C586_1, + cobalt_via_ide_native_mode_fixup); + static void qube_raq_via_bmIDE_fixup(struct pci_dev *dev) { unsigned short cfgword; diff --git a/arch/mips/pci/pci.c b/arch/mips/pci/pci.c index 589b745..6e6981f 100644 --- a/arch/mips/pci/pci.c +++ b/arch/mips/pci/pci.c @@ -242,6 +242,8 @@ static void pcibios_fixup_device_resources(struct pci_dev *dev, for (i = 0; i < PCI_NUM_RESOURCES; i++) { if (!dev->resource[i].start) continue; + if (dev->resource[i].flags & IORESOURCE_PCI_FIXED) + continue; if (dev->resource[i].flags & IORESOURCE_IO) offset = hose->io_offset; else if (dev->resource[i].flags & IORESOURCE_MEM) diff --git a/include/asm-mips/io.h b/include/asm-mips/io.h index e62058b..953be3b 100644 --- a/include/asm-mips/io.h +++ b/include/asm-mips/io.h @@ -53,11 +53,16 @@ /* * On MIPS I/O ports are memory mapped, so we access them using normal * load/store instructions. mips_io_port_base is the virtual address to - * which all ports are being mapped. For sake of efficiency some code - * assumes that this is an address that can be loaded with a single lui - * instruction, so the lower 16 bits must be zero. Should be true on - * on any sane architecture; generic code does not use this assumption. + * which all ports are being mapped. mips_legacy_io_port_base the same + * but used for ports below legacy_io_port_top. This special treatment + * of legacy addresses is used for example on Cobalt systems where the + * GT-64111 system controller doesn't allow access to low ports but aliasing + * can be exploited to access them anyway. So on a GT-64111 system + * mips_legacy_io_port_base would point to the base of the address range + * to which I/O ports are aliased. Having the legacy_io_port_top default of + * zero leaves this special treatment disabled by default. */ +extern const unsigned long mips_legacy_io_port_base; extern const unsigned long mips_io_port_base; /* @@ -75,6 +80,12 @@ static inline void set_io_port_base(unsigned long base) barrier(); } +static inline void set_legacy_io_port_base(unsigned long base) +{ + * (unsigned long *) &mips_legacy_io_port_base = base; + barrier(); +} + /* * Thanks to James van Artsdalen for a better timing-fix than * the two short jumps: using outb's to a nonexistent port seems @@ -375,9 +386,14 @@ static inline type pfx##read##bwlq(const volatile void __iomem *mem) \ static inline void pfx##out##bwlq##p(type val, unsigned long port) \ { \ volatile type *__addr; \ + unsigned long __vaddr; \ type __val; \ \ - __addr = (void *)__swizzle_addr_##bwlq(mips_io_port_base + port); \ + if (port < legacy_io_port_top) \ + __vaddr = mips_legacy_io_port_base + port; \ + else \ + __vaddr = mips_io_port_base + port; \ + __addr = (void *)__swizzle_addr_##bwlq(__vaddr); \ \ __val = pfx##ioswab##bwlq(__addr, val); \ \ @@ -391,9 +407,14 @@ static inline void pfx##out##bwlq##p(type val, unsigned long port) \ static inline type pfx##in##bwlq##p(unsigned long port) \ { \ volatile type *__addr; \ + unsigned long __vaddr; \ type __val; \ \ - __addr = (void *)__swizzle_addr_##bwlq(mips_io_port_base + port); \ + if (port < legacy_io_port_top) \ + __vaddr = mips_legacy_io_port_base + port; \ + else \ + __vaddr = mips_io_port_base + port; \ + __addr = (void *)__swizzle_addr_##bwlq(__vaddr); \ \ BUILD_BUG_ON(sizeof(type) > sizeof(unsigned long)); \ \ diff --git a/include/asm-mips/mach-cobalt/mangle-port.h b/include/asm-mips/mach-cobalt/mangle-port.h new file mode 100644 index 0000000..bdf5450 --- /dev/null +++ b/include/asm-mips/mach-cobalt/mangle-port.h @@ -0,0 +1,27 @@ +/* + * This file is subject to the terms and conditions of the GNU General Public + * License. See the file "COPYING" in the main directory of this archive + * for more details. + * + * Copyright (C) 2003, 2004, 2007 Ralf Baechle (ralf@linux-mips.org) + */ +#ifndef __ASM_MACH_COBALT_MANGLE_PORT_H +#define __ASM_MACH_COBALT_MANGLE_PORT_H + +#define __swizzle_addr_b(port) (port) +#define __swizzle_addr_w(port) (port) +#define __swizzle_addr_l(port) (port) +#define __swizzle_addr_q(port) (port) + +# define ioswabb(a, x) (x) +# define __mem_ioswabb(a, x) (x) +# define ioswabw(a, x) (x) +# define __mem_ioswabw(a, x) cpu_to_le16(x) +# define ioswabl(a, x) (x) +# define __mem_ioswabl(a, x) cpu_to_le32(x) +# define ioswabq(a, x) (x) +# define __mem_ioswabq(a, x) cpu_to_le32(x) + +#define legacy_io_port_top 0 + +#endif /* __ASM_MACH_COBALT_MANGLE_PORT_H */ diff --git a/include/asm-mips/mach-generic/mangle-port.h b/include/asm-mips/mach-generic/mangle-port.h index f49dc99..7f59bff 100644 --- a/include/asm-mips/mach-generic/mangle-port.h +++ b/include/asm-mips/mach-generic/mangle-port.h @@ -49,4 +49,6 @@ #endif +#define legacy_io_port_top 0 + #endif /* __ASM_MACH_GENERIC_MANGLE_PORT_H */ From ralf@linux-mips.org Tue Dec 11 12:20:02 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 11 Dec 2007 12:20:04 +0000 (GMT) Received: from localhost.localdomain ([127.0.0.1]:29925 "EHLO dl5rb.ham-radio-op.net") by ftp.linux-mips.org with ESMTP id S20026959AbXLKMUC (ORCPT ); Tue, 11 Dec 2007 12:20:02 +0000 Received: from denk.linux-mips.net (denk.linux-mips.net [127.0.0.1]) by dl5rb.ham-radio-op.net (8.14.1/8.13.8) with ESMTP id lBBCJWRi011357; Tue, 11 Dec 2007 12:19:33 GMT Received: (from ralf@localhost) by denk.linux-mips.net (8.14.1/8.14.1/Submit) id lBBCJV5t011356; Tue, 11 Dec 2007 12:19:31 GMT Date: Tue, 11 Dec 2007 12:19:31 +0000 From: Ralf Baechle To: Sergei Shtylyov Cc: linux-mips@linux-mips.org Subject: Re: [PATCH] Alchemy: fix PCI resource conflict (take 2) Message-ID: <20071211121931.GA11039@linux-mips.org> References: <200712102028.51448.sshtylyov@ru.mvista.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200712102028.51448.sshtylyov@ru.mvista.com> User-Agent: Mutt/1.5.17 (2007-11-01) Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 17769 X-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 10, 2007 at 08:28:51PM +0300, Sergei Shtylyov wrote: > ... by getting the PCI resources back into the 32-bit range -- there's no need > therefore for CONFIG_RESOURCES_64BIT either. This makes Alchemy PCI work again > while currently the kernel skips the bus scan. > > Signed-off-by: Sergei Shtylyov Thanks, applied. Which -stable branches do these two fixes need to be applied to? Ralf From ralf@linux-mips.org Tue Dec 11 12:20:25 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 11 Dec 2007 12:20:28 +0000 (GMT) Received: from localhost.localdomain ([127.0.0.1]:32741 "EHLO dl5rb.ham-radio-op.net") by ftp.linux-mips.org with ESMTP id S20026963AbXLKMUV (ORCPT ); Tue, 11 Dec 2007 12:20:21 +0000 Received: from denk.linux-mips.net (denk.linux-mips.net [127.0.0.1]) by dl5rb.ham-radio-op.net (8.14.1/8.13.8) with ESMTP id lBBCJpYV011364; Tue, 11 Dec 2007 12:19:51 GMT Received: (from ralf@localhost) by denk.linux-mips.net (8.14.1/8.14.1/Submit) id lBBCJor6011363; Tue, 11 Dec 2007 12:19:50 GMT Date: Tue, 11 Dec 2007 12:19:50 +0000 From: Ralf Baechle To: Sergei Shtylyov Cc: linux-mips@linux-mips.org Subject: Re: [PATCH] Alchemy: fix off by two error in __fixup_bigphys_addr() Message-ID: <20071211121950.GB11039@linux-mips.org> References: <200712102036.50247.sshtylyov@ru.mvista.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200712102036.50247.sshtylyov@ru.mvista.com> User-Agent: Mutt/1.5.17 (2007-11-01) Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 17770 X-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 10, 2007 at 08:36:50PM +0300, Sergei Shtylyov wrote: > he PCI specific code in this function doesn't check for the address range being > under the upper bound of the PCI memory window correctly -- fix this, somewhat > beautifying the code around the check, while at it... > > Signed-off-by: Sergei Shtylyov Applied, too. Thanks, Ralf From yoichi_yuasa@tripeaks.co.jp Tue Dec 11 14:41:47 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 11 Dec 2007 14:41:57 +0000 (GMT) Received: from mo30.po.2iij.NET ([210.128.50.53]:19009 "EHLO mo30.po.2iij.net") by ftp.linux-mips.org with ESMTP id S20027092AbXLKOlr (ORCPT ); Tue, 11 Dec 2007 14:41:47 +0000 Received: by mo.po.2iij.net (mo30) id lBBEeSYL091296; Tue, 11 Dec 2007 23:40:28 +0900 (JST) Received: from delta (224.24.30.125.dy.iij4u.or.jp [125.30.24.224]) by mbox.po.2iij.net (po-mbox301) id lBBEeQXH005253 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 11 Dec 2007 23:40:27 +0900 Date: Tue, 11 Dec 2007 23:40:26 +0900 From: Yoichi Yuasa To: Ralf Baechle Cc: yoichi_yuasa@tripeaks.co.jp, linux-mips@linux-mips.org Subject: Re: Cobalt fixes Message-Id: <20071211234026.f3de7e7f.yoichi_yuasa@tripeaks.co.jp> In-Reply-To: <20071211121220.GA10870@linux-mips.org> References: <20071211121220.GA10870@linux-mips.org> Organization: TriPeaks Corporation X-Mailer: Sylpheed 2.4.5 (GTK+ 2.12.0; 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: 17771 X-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 On Tue, 11 Dec 2007 12:12:20 +0000 Ralf Baechle wrote: > Some may have been following the beginning of this thread on linux-kernel, > see for example > > http://www.opensubscriber.com/message/linux-kernel@vger.kernel.org/8161812.html > > for non-subscribers. Linus has reverted the offending patch > fd6e732186ab522c812ab19c2c5e5befb8ec8115 in question so now the PCI and > I/O port code needs to be fixed up to be able to handle such a setup. > > A test report of this patch which is meant to be applied on top of > today's lmo git kernel on a Cobalt would be appreciated. It breaks all I/O port device(LCD, tulip, VIA ata) drivers. Yoichi From ralf@linux-mips.org Tue Dec 11 14:44:02 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 11 Dec 2007 14:44:04 +0000 (GMT) Received: from localhost.localdomain ([127.0.0.1]:57995 "EHLO dl5rb.ham-radio-op.net") by ftp.linux-mips.org with ESMTP id S20029143AbXLKOoC (ORCPT ); Tue, 11 Dec 2007 14:44:02 +0000 Received: from denk.linux-mips.net (denk.linux-mips.net [127.0.0.1]) by dl5rb.ham-radio-op.net (8.14.1/8.13.8) with ESMTP id lBBEhUBF015851; Tue, 11 Dec 2007 14:43:31 GMT Received: (from ralf@localhost) by denk.linux-mips.net (8.14.1/8.14.1/Submit) id lBBEhT8M015850; Tue, 11 Dec 2007 14:43:29 GMT Date: Tue, 11 Dec 2007 14:43:29 +0000 From: Ralf Baechle To: Yoichi Yuasa Cc: linux-mips@linux-mips.org Subject: Re: Cobalt fixes Message-ID: <20071211144329.GA15843@linux-mips.org> References: <20071211121220.GA10870@linux-mips.org> <20071211234026.f3de7e7f.yoichi_yuasa@tripeaks.co.jp> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20071211234026.f3de7e7f.yoichi_yuasa@tripeaks.co.jp> User-Agent: Mutt/1.5.17 (2007-11-01) Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 17772 X-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 11, 2007 at 11:40:26PM +0900, Yoichi Yuasa wrote: > > Some may have been following the beginning of this thread on linux-kernel, > > see for example > > > > http://www.opensubscriber.com/message/linux-kernel@vger.kernel.org/8161812.html > > > > for non-subscribers. Linus has reverted the offending patch > > fd6e732186ab522c812ab19c2c5e5befb8ec8115 in question so now the PCI and > > I/O port code needs to be fixed up to be able to handle such a setup. > > > > A test report of this patch which is meant to be applied on top of > > today's lmo git kernel on a Cobalt would be appreciated. > > It breaks all I/O port device(LCD, tulip, VIA ata) drivers. Thanks, I'll try to sort this out tonight when I'm hopefully going to have access to an actual machine. The bootup messages of the failing kernel might be interesting, if you have them at hand. Ralf From yoichi_yuasa@tripeaks.co.jp Tue Dec 11 14:50:06 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 11 Dec 2007 14:50:14 +0000 (GMT) Received: from mo32.po.2iij.net ([210.128.50.17]:38938 "EHLO mo32.po.2iij.net") by ftp.linux-mips.org with ESMTP id S20029252AbXLKOuG (ORCPT ); Tue, 11 Dec 2007 14:50:06 +0000 Received: by mo.po.2iij.net (mo32) id lBBEo3eZ018373; Tue, 11 Dec 2007 23:50:03 +0900 (JST) Received: from delta (224.24.30.125.dy.iij4u.or.jp [125.30.24.224]) by mbox.po.2iij.net (po-mbox304) id lBBEo1eY012889 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 11 Dec 2007 23:50:01 +0900 Date: Tue, 11 Dec 2007 23:50:01 +0900 From: Yoichi Yuasa To: Ralf Baechle Cc: yoichi_yuasa@tripeaks.co.jp, linux-mips@linux-mips.org Subject: Re: Cobalt fixes Message-Id: <20071211235001.8621bdb9.yoichi_yuasa@tripeaks.co.jp> In-Reply-To: <20071211121220.GA10870@linux-mips.org> References: <20071211121220.GA10870@linux-mips.org> Organization: TriPeaks Corporation X-Mailer: Sylpheed 2.4.5 (GTK+ 2.12.0; 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: 17773 X-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 On Tue, 11 Dec 2007 12:12:20 +0000 Ralf Baechle wrote: > Some may have been following the beginning of this thread on linux-kernel, > see for example > > http://www.opensubscriber.com/message/linux-kernel@vger.kernel.org/8161812.html > > for non-subscribers. Linus has reverted the offending patch > fd6e732186ab522c812ab19c2c5e5befb8ec8115 in question so now the PCI and > I/O port code needs to be fixed up to be able to handle such a setup. It can be fixed my fix PCI resource patch. http://www.linux-mips.org/archives/linux-mips/2007-01/msg00049.html Yoichi From ralf@linux-mips.org Tue Dec 11 15:35:55 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 11 Dec 2007 15:35:57 +0000 (GMT) Received: from localhost.localdomain ([127.0.0.1]:47591 "EHLO dl5rb.ham-radio-op.net") by ftp.linux-mips.org with ESMTP id S20029383AbXLKPfz (ORCPT ); Tue, 11 Dec 2007 15:35:55 +0000 Received: from denk.linux-mips.net (denk.linux-mips.net [127.0.0.1]) by dl5rb.ham-radio-op.net (8.14.1/8.13.8) with ESMTP id lBBFZNhs001859; Tue, 11 Dec 2007 15:35:23 GMT Received: (from ralf@localhost) by denk.linux-mips.net (8.14.1/8.14.1/Submit) id lBBFZMml001828; Tue, 11 Dec 2007 15:35:22 GMT Date: Tue, 11 Dec 2007 15:35:22 +0000 From: Ralf Baechle To: Yoichi Yuasa Cc: linux-mips@linux-mips.org Subject: Re: Cobalt fixes Message-ID: <20071211153522.GB15843@linux-mips.org> References: <20071211121220.GA10870@linux-mips.org> <20071211235001.8621bdb9.yoichi_yuasa@tripeaks.co.jp> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20071211235001.8621bdb9.yoichi_yuasa@tripeaks.co.jp> User-Agent: Mutt/1.5.17 (2007-11-01) Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 17774 X-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 11, 2007 at 11:50:01PM +0900, Yoichi Yuasa wrote: > > for non-subscribers. Linus has reverted the offending patch > > fd6e732186ab522c812ab19c2c5e5befb8ec8115 in question so now the PCI and > > I/O port code needs to be fixed up to be able to handle such a setup. > > It can be fixed my fix PCI resource patch. > > http://www.linux-mips.org/archives/linux-mips/2007-01/msg00049.html Modulo a codying style issue that one is the same as the pci.c segment of the patch I've just posted. Ralf From ricmm@kanux.com Tue Dec 11 17:16:46 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 11 Dec 2007 17:16:54 +0000 (GMT) Received: from rs25s9.datacenter.cha.cantv.net ([200.44.33.40]:49838 "EHLO rs25s9.datacenter.cha.cantv.net") by ftp.linux-mips.org with ESMTP id S20030205AbXLKRQq (ORCPT ); Tue, 11 Dec 2007 17:16:46 +0000 Received: from [192.168.0.2] (dC9D088C0.dslam-04-10-6-02-1-01.apr.dsl.cantv.net [201.208.136.192]) by rs25s9.datacenter.cha.cantv.net (8.13.8/8.13.0/3.0) with ESMTP id lBBHGK5t013393; Tue, 11 Dec 2007 12:46:20 -0430 X-Matched-Lists: [] Message-ID: <475E9012.1010504@kanux.com> Date: Tue, 11 Dec 2007 09:26:42 -0400 From: Ricardo Mendoza User-Agent: Thunderbird 2.0.0.0 (X11/20070601) MIME-Version: 1.0 To: Giuseppe Sacco CC: linux-mips@linux-mips.org Subject: Re: Still no 2.6.24 on ip32 [was: Re: 2.6.24-rc1 does not boot on SGI] References: <1193468825.7474.6.camel@scarafaggio> <20071029.000713.59464443.anemo@mba.ocn.ne.jp> <1193599031.14874.1.camel@scarafaggio> <20071029150625.GB4165@linux-mips.org> <1194268551.4842.3.camel@scarafaggio> <1194281699.4192.3.camel@casa> <1197287929.17265.6.camel@scarafaggio> <475D7FE2.7080703@kanux.com> <1197371095.7889.24.camel@scarafaggio> In-Reply-To: <1197371095.7889.24.camel@scarafaggio> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV version 0.91.2, clamav-milter version 0.91.2 on 10.128.1.89 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: 17775 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: ricmm@kanux.com Precedence: bulk X-list: linux-mips Giuseppe Sacco wrote: > I just checked that my repository is up to date, so my problem is still > there (thus I don't know if it is the same problem you fixed). > > BTW, what was the problem you fixed? I would like to have a look to it, > to better understand what's going on there. Well I just updated to see if anything had broken in the past few days, but I don't seem to be hitting that error of yours. Could you send your config to see if I can reproduce it? Ricardo From Frank_Rowand@sonyusa.com Tue Dec 11 18:14:31 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 11 Dec 2007 18:14:40 +0000 (GMT) Received: from outbound-blu.frontbridge.com ([65.55.251.16]:12393 "EHLO outbound9-blu-R.bigfish.com") by ftp.linux-mips.org with ESMTP id S20030427AbXLKSOb (ORCPT ); Tue, 11 Dec 2007 18:14:31 +0000 Received: from outbound9-blu.bigfish.com (localhost.localdomain [127.0.0.1]) by outbound9-blu-R.bigfish.com (Postfix) with ESMTP id 99EAAD0BA42; Tue, 11 Dec 2007 18:13:24 +0000 (UTC) Received: from mail19-blu-R.bigfish.com (unknown [10.1.252.3]) by outbound9-blu.bigfish.com (Postfix) with ESMTP id 867D417E005A; Tue, 11 Dec 2007 18:13:24 +0000 (UTC) Received: from mail19-blu (localhost.localdomain [127.0.0.1]) by mail19-blu-R.bigfish.com (Postfix) with ESMTP id E5C36178812E; Tue, 11 Dec 2007 18:13:23 +0000 (UTC) X-BigFish: V X-MS-Exchange-Organization-Antispam-Report: OrigIP: 160.33.66.75;Service: EHS Received: by mail19-blu (MessageSwitch) id 1197396802965085_1845; Tue, 11 Dec 2007 18:13:22 +0000 (UCT) Received: from mail8.fw-sd.sony.com (mail8.fw-sd.sony.com [160.33.66.75]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail19-blu.bigfish.com (Postfix) with ESMTP id 610361F009A; Tue, 11 Dec 2007 18:13:21 +0000 (UTC) Received: from mail3.sjc.in.sel.sony.com (mail3.sjc.in.sel.sony.com [43.134.1.211]) by mail8.fw-sd.sony.com (8.12.11/8.12.11) with ESMTP id lBBIDJ2F020817; Tue, 11 Dec 2007 18:13:19 GMT Received: from USSDIXIM02.am.sony.com (ussdixim02.am.sony.com [43.130.140.34]) by mail3.sjc.in.sel.sony.com (8.12.11/8.12.11) with ESMTP id lBBIDJ9E001405; Tue, 11 Dec 2007 18:13:19 GMT Received: from ussdixms03.am.sony.com ([43.130.140.23]) by USSDIXIM02.am.sony.com with Microsoft SMTPSVC(5.0.2195.6713); Tue, 11 Dec 2007 10:13:19 -0800 Received: from [43.135.148.200] ([43.135.148.200]) by ussdixms03.am.sony.com with Microsoft SMTPSVC(5.0.2195.6713); Tue, 11 Dec 2007 10:13:18 -0800 Subject: [PATCH] RBTX4927: linux-2.6.24-rc4 hang on boot From: Frank Rowand Reply-To: frank.rowand@am.sony.com To: linux-mips@linux-mips.org Cc: frank.rowand@am.sony.com Content-Type: text/plain Date: Tue, 11 Dec 2007 10:16:27 -0500 Message-Id: <1197386187.5610.18.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.12.1 (2.12.1-3.fc8) Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 11 Dec 2007 18:13:18.0948 (UTC) FILETIME=[81CF1A40:01C83C21] Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 17776 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: frank.rowand@am.sony.com Precedence: bulk X-list: linux-mips In linux-2.6.24-rc4 the Toshiba RBTX4927 hangs on boot. The cause is that plat_time_init() from arch/mips/tx4927/common/tx4927_setup.c does not override the __weak plat_time_init() from arch/mips/kernel/time.c. This is due to a compiler bug in gcc 4.1.1. The bug is reported to not exist in earlier versions of gcc, and to be fixed in 4.1.2. The problem is that the __weak plat_time_init() is empty and thus gets optimized out of existence (thus the linker is never given the option to replace the __weak function). For more info on the gcc bug see http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27781 The attached patch is one workaround. Another possible workaround would be to change the __weak plat_time_init() to be a non-empty function. Signed-off-by: Frank Rowand --- arch/mips/kernel/Makefile | 4 4 + 0 - 0 ! 1 files changed, 4 insertions(+) Index: linux-2.6.24-rc4/arch/mips/kernel/Makefile =================================================================== --- linux-2.6.24-rc4.orig/arch/mips/kernel/Makefile +++ linux-2.6.24-rc4/arch/mips/kernel/Makefile @@ -83,6 +83,10 @@ obj-$(CONFIG_EARLY_PRINTK) += early_prin CFLAGS_cpu-bugs64.o = $(shell if $(CC) $(KBUILD_CFLAGS) -Wa,-mdaddi -c -o /dev/null -xc /dev/null >/dev/null 2>&1; then echo "-DHAVE_AS_SET_DADDI"; fi) +# workaround for http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27781, +# which impacts plat_time_init() for tx4927, gcc 4.1.1 +CFLAGS_time.o += -fno-unit-at-a-time + obj-$(CONFIG_HAVE_STD_PC_SERIAL_PORT) += 8250-platform.o EXTRA_CFLAGS += -Werror From philippedeswert@scarlet.be Tue Dec 11 18:41:13 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 11 Dec 2007 18:41:22 +0000 (GMT) Received: from emh05.mail.saunalahti.fi ([62.142.5.111]:2955 "EHLO emh05.mail.saunalahti.fi") by ftp.linux-mips.org with ESMTP id S20022146AbXLKSlN (ORCPT ); Tue, 11 Dec 2007 18:41:13 +0000 Received: from saunalahti-vams (vs3-11.mail.saunalahti.fi [62.142.5.95]) by emh05-2.mail.saunalahti.fi (Postfix) with SMTP id 847498CD47; Tue, 11 Dec 2007 20:41:12 +0200 (EET) Received: from emh01.mail.saunalahti.fi ([62.142.5.107]) by vs3-11.mail.saunalahti.fi ([62.142.5.95]) with SMTP (gateway) id A029327FA7D; Tue, 11 Dec 2007 20:41:12 +0200 Received: from [192.168.0.102] (a91-153-17-113.elisa-laajakaista.fi [91.153.17.113]) by emh01.mail.saunalahti.fi (Postfix) with ESMTP id 0FEC84C0DE; Tue, 11 Dec 2007 20:41:06 +0200 (EET) Subject: CFP for embedded room at FOSDEM From: Philippe De Swert To: philippedeswert@gmail.com Content-Type: text/plain Date: Tue, 11 Dec 2007 20:40:15 +0200 Message-Id: <1197398415.2341.22.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.6.3 Content-Transfer-Encoding: 7bit X-Antivirus: VAMS Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 17777 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: philippedeswert@scarlet.be Precedence: bulk X-list: linux-mips Hi, This might be of interest to developers in the Free Software/Open Source world. FOSDEM is looking for speakers for the embedded track again. Anyone who thinks he/she has somebody interesting to share with other embedded developers please take a look at the call for papers. Cheers, Philippe CALL FOR PAPERS for the 6th EMBEDDED track at FOSDEM 2008 ========================================================= sat 23 - sun 24 February 2008, Brussels Call for papers ---------------- The 2008 edition of FOSDEM (Free and Open Source Developers' European Meeting; http://www.fosdem.org) will take place in Brussels, Belgium on 23 and 24 February 2008. For the sixth time, a track on Embedded Systems and Operating Systems will be organized. The fourth edition was quite succesful and attracted up to 150 attendants for certain topics. For last year's program see: http://archive.fosdem.org/2007/schedule/tracks/embedded The use of Free Software in the infrastructure of Embedded Systems is booming, e.g. by the use of Linux, uClinux, eCos, RedBoot, RTEMS and many other Free Software components. More companies are supporting Embedded Free Software every day because of the reliability and cheap licensing. This can be confirmed from looking at some high profile releases of embedded GNU/Linux systems. Some examples are the Nokia 770 & N800,some models of Motorola's smartphones and Archos media players. Not to forget the popular TomTom navigation system, the numerous SOHO routers and NAS devices based on linux. Operating System development has always been a very important topic in Free Software. As embedded and real-time systems typically have special OS requirements, we organise this Free Embedded and OS development track at FOSDEM to give people the opportunity to present their (or their teams) achievements. This track at FOSDEM provides a remarkable opportunity to present and discuss the ongoing work in these areas, and we invite developers to present their current projects. Technical topics of the conference include but are not limited to : * OS Development : kernel architecture and implementation, libraries, power management, TIPC, boot time and memory usage optimizations (e.g. Linux, BSD, uClinux, uClibc, newlib, slob allocator,...) * Practical experiences in implementing Free Software in embedded systems (e.g. reverse engineering, porting to (and adapting of) commercial devices like the Ipaq, linksys WRT54G, nlsu2 .... ) * Toolchain, performance testing and build environment (e.g. crosstool, emdebian, openembedded, PTX dist, packaging, scratchbox, Eclipse, Valgrind,...) * GUIs for embedded systems (Gtk, Qt-(embedded), GPE, Qtopia, UI design with touchscreen, Hildon GUI extensions, OpenMoko, OpenGL ES, ...) * Multimedia applications for embedded systems (e.g. integer only decoders, Opieplayer, gstreamer... ) * Real-time extensions, nanokernels and hardware virtualization software (e.g. RTAI, Adeos, KURT, L4, Qemu, User Mode Linux, VirtualLogix, high resolution timers, ...) * Hard real-time OS's (eCos, RTEMS, Real Time Linux,...) * Open hardware, DSP, softcores and general hardware management (e.g opencores.org, OpenRISC, leonSparc, FPGA's, specific design restrictions for free systems, DSP, Power management...) * Safety and security certifications applied to Free software (e.g. security measures in Embedded systems, TPM, SELinux for embedded, TrustZone, ...) * Tools and techniques for programming multicore systems * Free software licenses and embedded systems Authors that wish to present a topic are requested to submit their abstracts online to embedded@fosdem.org before 23/01/2008. Notification of receipt will be sent within 48 hours. Authors wishing to submit a full paper (between 6 and 12 A4 pages), can do so in PS or PDF format. The Program Committee will evaluate the abstracts and consists of: * Geert Uytterhoeven, Sony NSCE, Belgium * Peter De Schrijver (p2), Nokia (OSSO), Finland * Philippe De Swert, Nokia (OSSO), Finland * Klaas van Gend, MontaVista Software, The Netherlands * Michael Opdenacker, Free Electrons, France From giuseppe@eppesuigoccas.homedns.org Tue Dec 11 20:47:53 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 11 Dec 2007 20:48:01 +0000 (GMT) Received: from host188-210-dynamic.20-79-r.retail.telecomitalia.it ([79.20.210.188]:674 "EHLO eppesuigoccas.homedns.org") by ftp.linux-mips.org with ESMTP id S20021484AbXLKUrx (ORCPT ); Tue, 11 Dec 2007 20:47:53 +0000 Received: from giuseppe by eppesuigoccas.homedns.org with local (Exim 4.63) (envelope-from ) id 1J2By2-0003qK-4F; Tue, 11 Dec 2007 21:44:38 +0100 Date: Tue, 11 Dec 2007 21:44:37 +0100 From: Giuseppe Sacco To: Ricardo Mendoza Cc: linux-mips@linux-mips.org Subject: Re: Still no 2.6.24 on ip32 [was: Re: 2.6.24-rc1 does not boot on SGI] Message-ID: <20071211204437.GA14243@eppesuigoccas.homedns.org> References: <1193468825.7474.6.camel@scarafaggio> <20071029.000713.59464443.anemo@mba.ocn.ne.jp> <1193599031.14874.1.camel@scarafaggio> <20071029150625.GB4165@linux-mips.org> <1194268551.4842.3.camel@scarafaggio> <1194281699.4192.3.camel@casa> <1197287929.17265.6.camel@scarafaggio> <475D7FE2.7080703@kanux.com> <1197371095.7889.24.camel@scarafaggio> <475E9012.1010504@kanux.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <475E9012.1010504@kanux.com> User-Agent: Mutt/1.5.13 (2006-08-11) Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 17778 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: giuseppe@eppesuigoccas.homedns.org Precedence: bulk X-list: linux-mips On Tue, Dec 11, 2007 at 09:26:42AM -0400, Ricardo Mendoza wrote: > Giuseppe Sacco wrote: > > > I just checked that my repository is up to date, so my problem is still > > there (thus I don't know if it is the same problem you fixed). > > > > BTW, what was the problem you fixed? I would like to have a look to it, > > to better understand what's going on there. > > Well I just updated to see if anything had broken in the past few days, > but I don't seem to be hitting that error of yours. Could you send your > config to see if I can reproduce it? Yes, sure: http://eppesuigoccas.homedns.org/~giuseppe/debian/config-2.6.24-rc4-ip32.bz2 but please note that the problem is present in every kernel since 2.6.24-rc1 my boot stanza in arcboot is: label=test image=/boot/vmlinux-2.6.24-rc4-gs1 append="root=/dev/sda1 ro video=gbefb:1024x768-16@60 debug initcall_debug console=tty0 console=ttyS1,115200" bye, Giuseppe From ricmm@kanux.com Tue Dec 11 21:08:55 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 11 Dec 2007 21:09:05 +0000 (GMT) Received: from rs25s3.datacenter.cha.cantv.net ([200.44.33.4]:2215 "EHLO rs25s3.datacenter.cha.cantv.net") by ftp.linux-mips.org with ESMTP id S20021565AbXLKVIz (ORCPT ); Tue, 11 Dec 2007 21:08:55 +0000 Received: from [192.168.0.2] (dC9D088C0.dslam-04-10-6-02-1-01.apr.dsl.cantv.net [201.208.136.192]) by rs25s3.datacenter.cha.cantv.net (8.13.8/8.13.0/3.0) with ESMTP id lBBL7ZBT024341; Tue, 11 Dec 2007 16:37:37 -0430 X-Matched-Lists: [] Message-ID: <475EC648.8030906@kanux.com> Date: Tue, 11 Dec 2007 13:18:00 -0400 From: Ricardo Mendoza User-Agent: Thunderbird 2.0.0.0 (X11/20070601) MIME-Version: 1.0 To: Giuseppe Sacco CC: linux-mips@linux-mips.org Subject: Re: Still no 2.6.24 on ip32 [was: Re: 2.6.24-rc1 does not boot on SGI] References: <1193468825.7474.6.camel@scarafaggio> <20071029.000713.59464443.anemo@mba.ocn.ne.jp> <1193599031.14874.1.camel@scarafaggio> <20071029150625.GB4165@linux-mips.org> <1194268551.4842.3.camel@scarafaggio> <1194281699.4192.3.camel@casa> <1197287929.17265.6.camel@scarafaggio> <475D7FE2.7080703@kanux.com> <1197371095.7889.24.camel@scarafaggio> <475E9012.1010504@kanux.com> <20071211204437.GA14243@eppesuigoccas.homedns.org> In-Reply-To: <20071211204437.GA14243@eppesuigoccas.homedns.org> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV version 0.91.2, clamav-milter version 0.91.2 on 10.128.1.89 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: 17779 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: ricmm@kanux.com Precedence: bulk X-list: linux-mips Giuseppe Sacco wrote: > On Tue, Dec 11, 2007 at 09:26:42AM -0400, Ricardo Mendoza wrote: >> Giuseppe Sacco wrote: >> >>> I just checked that my repository is up to date, so my problem is still >>> there (thus I don't know if it is the same problem you fixed). >>> >>> BTW, what was the problem you fixed? I would like to have a look to it, >>> to better understand what's going on there. >> Well I just updated to see if anything had broken in the past few days, >> but I don't seem to be hitting that error of yours. Could you send your >> config to see if I can reproduce it? > > Yes, sure: http://eppesuigoccas.homedns.org/~giuseppe/debian/config-2.6.24-rc4-ip32.bz2 > but please note that the problem is present in every kernel since 2.6.24-rc1 > > my boot stanza in arcboot is: > > label=test > image=/boot/vmlinux-2.6.24-rc4-gs1 > append="root=/dev/sda1 ro video=gbefb:1024x768-16@60 debug initcall_debug console=tty0 console=ttyS1,115200" Ran it without problems, can't get into much detail right now but I the problem you are seeing is more than likely caused by your other patch to serial_core.c. Ricardo From flo@rfc822.org Tue Dec 11 22:13:29 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 11 Dec 2007 22:13:38 +0000 (GMT) Received: from hydra.gt.owl.de ([195.71.99.218]:62181 "EHLO hydra.gt.owl.de") by ftp.linux-mips.org with ESMTP id S20022230AbXLKWN3 (ORCPT ); Tue, 11 Dec 2007 22:13:29 +0000 Received: by hydra.gt.owl.de (Postfix, from userid 1000) id 6404B93703; Tue, 11 Dec 2007 23:13:27 +0100 (CET) Date: Tue, 11 Dec 2007 23:13:27 +0100 From: Florian Lohoff To: linux-mips@linux-mips.org Subject: 2.6.24-rc2 crash in kmap_coherent Message-ID: <20071211221327.GB2150@paradigm.rfc822.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="v9Ux+11Zm5mwPlX6" Content-Disposition: inline Organization: rfc822 - pure communication X-SpiderMe: mh-200712112238@listme.rfc822.org 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: 17780 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: flo@rfc822.org Precedence: bulk X-list: linux-mips --v9Ux+11Zm5mwPlX6 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi, i just discovered that my native gcc build on one of my Indys stopped. I found this in the dmesg ;) Its a 2.6.24-rc2 on an R5k Indy 64M: Kernel bug detected[#1]: Cpu 0 $ 0 : 0000000000000000 ffffffff9000cce0 0000000000000001 ffffffff80000000 $ 4 : ffffffff8921f910 000000007fda0f05 000000007fda0f05 ffffffff8b8ea000 $ 8 : ffffffff89b4ef05 000000000000000e ffffffff8921f910 0000000000000f05 $12 : 0000000000000000 ffffffff80000008 ffffffff88090010 00000000004038b4 $16 : ffffffff8921f910 000000007fda0f05 ffffffff8b8ea000 000000000000000e $20 : ffffffff8bdfb920 0000000000000000 ffffffff8bd88cc0 ffffffff8893fd58 $24 : 0000000000000006 ffffffff8801df00 = =20 $28 : ffffffff8893c000 ffffffff8893fd20 ffffffff88430000 ffffffff8801c010 Hi : 000000000001d1ea Lo : 0000000000009b4e epc : ffffffff8801bcf0 kmap_coherent+0x10/0x130 Not tainted ra : ffffffff8801c010 copy_from_user_page+0x40/0xb0 Status: 9000cce3 KX SX UX KERNEL EXL IE=20 Cause : 00000034 PrId : 00002321 (R5000) Modules linked in: dm_snapshot dm_mirror dm_mod ipv6 Process cat (pid: 14553, threadinfo=3Dffffffff8893c000, task=3Dffffffff88a5= 2660) Stack : 000000000000000e 000000007fda0f05 ffffffff8b8ea000 0000000000000000 ffffffff88079d10 ffffffff88079cc4 ffffffff8bfbd528 ffffffff8921f910 ffffffff8bdfb980 ffffffff8b8ea000 ffffffff8bdfb920 0000000000000000 ffffffff8b8ea000 000000000000000e ffffffff8bd88cc0 ffffffff8893fe78 0000000000447000 000000000052c7d8 0000000000000000 ffffffff880d9014 ffffffff8bd88cc0 ffffffff8b8ea000 fffffffffffffff4 ffffffff8b863248 0000000000000400 ffffffff8893fe78 0000000000447000 ffffffff880db188 ffffffff8be6f6e0 0000000000000400 0000000000447000 ffffffff8893fe78 0000000000447000 0000000000000003 0000000000000016 ffffffff8808fbdc ffffffff8be6f6e0 0000000000000400 0000000000447000 fffffffffffffff7 ... Call Trace: [] kmap_coherent+0x10/0x130 [] copy_from_user_page+0x40/0xb0 [] access_process_vm+0x168/0x1d8 [] proc_pid_cmdline+0xac/0x140 [] proc_info_read+0x108/0x150 [] vfs_read+0xec/0x178 [] sys_read+0x50/0x98 [] handle_sys+0x118/0x134 Code: 0002127a 00021000 30420001 <00028036> 8f820024 3c038843 24420001 = af820024 dc62f390=20 Flo --=20 Florian Lohoff flo@rfc822.org +49-171-2280134 Those who would give up a little freedom to get a little=20 security shall soon have neither - Benjamin Franklin --v9Ux+11Zm5mwPlX6 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFHXwuHUaz2rXW+gJcRAr+bAJ4r9/1gtvh0RWnEE07Jyjmai60dngCdGGt/ PRqproX6zCL6OdY0ROAz/no= =AQco -----END PGP SIGNATURE----- --v9Ux+11Zm5mwPlX6-- From ddaney@avtrex.com Tue Dec 11 22:49:49 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 11 Dec 2007 22:49:57 +0000 (GMT) Received: from smtp1.dnsmadeeasy.com ([205.234.170.144]:31898 "EHLO smtp1.dnsmadeeasy.com") by ftp.linux-mips.org with ESMTP id S20024076AbXLKWtt (ORCPT ); Tue, 11 Dec 2007 22:49:49 +0000 Received: from smtp1.dnsmadeeasy.com (localhost [127.0.0.1]) by smtp1.dnsmadeeasy.com (Postfix) with ESMTP id 4999D3112C8; Tue, 11 Dec 2007 22:49:52 +0000 (UTC) X-Authenticated-Name: js.dnsmadeeasy X-Transit-System: In case of SPAM please contact abuse@dnsmadeeasy.com Received: from avtrex.com (unknown [67.116.42.147]) by smtp1.dnsmadeeasy.com (Postfix) with ESMTP; Tue, 11 Dec 2007 22:49:50 +0000 (UTC) Received: from [192.168.7.26] ([192.168.7.26]) by avtrex.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 11 Dec 2007 14:49:22 -0800 Message-ID: <475F13F1.2050109@avtrex.com> Date: Tue, 11 Dec 2007 14:49:21 -0800 From: David Daney User-Agent: Thunderbird 1.5.0.12 (X11/20071019) MIME-Version: 1.0 To: Florian Lohoff Cc: linux-mips@linux-mips.org Subject: Re: 2.6.24-rc2 crash in kmap_coherent References: <20071211221327.GB2150@paradigm.rfc822.org> In-Reply-To: <20071211221327.GB2150@paradigm.rfc822.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 11 Dec 2007 22:49:22.0097 (UTC) FILETIME=[12371210:01C83C48] Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 17781 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: ddaney@avtrex.com Precedence: bulk X-list: linux-mips Florian Lohoff wrote: > Hi, > i just discovered that my native gcc build on one of my Indys stopped. I > found this in the dmesg ;) > > Its a 2.6.24-rc2 on an R5k Indy 64M: > > Kernel bug detected[#1]: > Cpu 0 > $ 0 : 0000000000000000 ffffffff9000cce0 0000000000000001 ffffffff80000000 > $ 4 : ffffffff8921f910 000000007fda0f05 000000007fda0f05 ffffffff8b8ea000 > $ 8 : ffffffff89b4ef05 000000000000000e ffffffff8921f910 0000000000000f05 > $12 : 0000000000000000 ffffffff80000008 ffffffff88090010 00000000004038b4 > $16 : ffffffff8921f910 000000007fda0f05 ffffffff8b8ea000 000000000000000e > $20 : ffffffff8bdfb920 0000000000000000 ffffffff8bd88cc0 ffffffff8893fd58 > $24 : 0000000000000006 ffffffff8801df00 > $28 : ffffffff8893c000 ffffffff8893fd20 ffffffff88430000 ffffffff8801c010 > Hi : 000000000001d1ea > Lo : 0000000000009b4e > epc : ffffffff8801bcf0 kmap_coherent+0x10/0x130 Not tainted > ra : ffffffff8801c010 copy_from_user_page+0x40/0xb0 > Status: 9000cce3 KX SX UX KERNEL EXL IE > Cause : 00000034 > PrId : 00002321 (R5000) > Modules linked in: dm_snapshot dm_mirror dm_mod ipv6 > Process cat (pid: 14553, threadinfo=ffffffff8893c000, task=ffffffff88a52660) > Stack : 000000000000000e 000000007fda0f05 ffffffff8b8ea000 0000000000000000 > ffffffff88079d10 ffffffff88079cc4 ffffffff8bfbd528 ffffffff8921f910 > ffffffff8bdfb980 ffffffff8b8ea000 ffffffff8bdfb920 0000000000000000 > ffffffff8b8ea000 000000000000000e ffffffff8bd88cc0 ffffffff8893fe78 > 0000000000447000 000000000052c7d8 0000000000000000 ffffffff880d9014 > ffffffff8bd88cc0 ffffffff8b8ea000 fffffffffffffff4 ffffffff8b863248 > 0000000000000400 ffffffff8893fe78 0000000000447000 ffffffff880db188 > ffffffff8be6f6e0 0000000000000400 0000000000447000 ffffffff8893fe78 > 0000000000447000 0000000000000003 0000000000000016 ffffffff8808fbdc > ffffffff8be6f6e0 0000000000000400 0000000000447000 fffffffffffffff7 > ... > Call Trace: > [] kmap_coherent+0x10/0x130 > [] copy_from_user_page+0x40/0xb0 > [] access_process_vm+0x168/0x1d8 > [] proc_pid_cmdline+0xac/0x140 > [] proc_info_read+0x108/0x150 > [] vfs_read+0xec/0x178 > [] sys_read+0x50/0x98 > [] handle_sys+0x118/0x134 > > > Code: 0002127a 00021000 30420001 <00028036> 8f820024 3c038843 24420001 af820024 dc62f390 > FWIW I get something very similar reading /proc/1/cmdline on 2.6.23-1/ip32 w/ R5000 and there have been other similar postings here recently. Maybe one day I will look into it, but it probably will not be real soon... David Daney From yoichi_yuasa@tripeaks.co.jp Tue Dec 11 22:54:33 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 11 Dec 2007 22:54:42 +0000 (GMT) Received: from mo31.po.2iij.NET ([210.128.50.54]:19498 "EHLO mo31.po.2iij.net") by ftp.linux-mips.org with ESMTP id S20024123AbXLKWyd (ORCPT ); Tue, 11 Dec 2007 22:54:33 +0000 Received: by mo.po.2iij.net (mo31) id lBBMrESc006631; Wed, 12 Dec 2007 07:53:14 +0900 (JST) Received: from delta (224.24.30.125.dy.iij4u.or.jp [125.30.24.224]) by mbox.po.2iij.net (po-mbox304) id lBBMrAsx022513 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 12 Dec 2007 07:53:10 +0900 Date: Wed, 12 Dec 2007 07:53:09 +0900 From: Yoichi Yuasa To: Ralf Baechle Cc: yoichi_yuasa@tripeaks.co.jp, linux-mips@linux-mips.org Subject: Re: Cobalt fixes Message-Id: <20071212075309.5172da92.yoichi_yuasa@tripeaks.co.jp> In-Reply-To: <20071211153522.GB15843@linux-mips.org> References: <20071211121220.GA10870@linux-mips.org> <20071211235001.8621bdb9.yoichi_yuasa@tripeaks.co.jp> <20071211153522.GB15843@linux-mips.org> Organization: TriPeaks Corporation X-Mailer: Sylpheed 2.4.5 (GTK+ 2.12.0; 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: 17782 X-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 On Tue, 11 Dec 2007 15:35:22 +0000 Ralf Baechle wrote: > On Tue, Dec 11, 2007 at 11:50:01PM +0900, Yoichi Yuasa wrote: > > > > for non-subscribers. Linus has reverted the offending patch > > > fd6e732186ab522c812ab19c2c5e5befb8ec8115 in question so now the PCI and > > > I/O port code needs to be fixed up to be able to handle such a setup. > > > > It can be fixed my fix PCI resource patch. > > > > http://www.linux-mips.org/archives/linux-mips/2007-01/msg00049.html > > Modulo a codying style issue that one is the same as the pci.c segment of > the patch I've just posted. This is a fix proposed before fd6e732186ab522c812ab19c2c5e5befb8ec8115. This patch is still effective. Fixed line offset and coding style. Signed-off-by: Yoichi Yuasa diff -pruN -X mips/Documentation/dontdiff mips-orig/arch/mips/pci/pci.c mips/arch/mips/pci/pci.c --- mips-orig/arch/mips/pci/pci.c 2007-12-12 06:48:44.282421000 +0900 +++ mips/arch/mips/pci/pci.c 2007-12-12 06:54:51.041342000 +0900 @@ -242,6 +242,8 @@ static void pcibios_fixup_device_resourc for (i = 0; i < PCI_NUM_RESOURCES; i++) { if (!dev->resource[i].start) continue; + if (dev->resource[i].flags & IORESOURCE_PCI_FIXED) + continue; if (dev->resource[i].flags & IORESOURCE_IO) offset = hose->io_offset; else if (dev->resource[i].flags & IORESOURCE_MEM) From ddaney@avtrex.com Wed Dec 12 06:41:08 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 12 Dec 2007 06:41:17 +0000 (GMT) Received: from smtp1.dnsmadeeasy.com ([205.234.170.144]:45013 "EHLO smtp1.dnsmadeeasy.com") by ftp.linux-mips.org with ESMTP id S20030236AbXLLGlI (ORCPT ); Wed, 12 Dec 2007 06:41:08 +0000 Received: from smtp1.dnsmadeeasy.com (localhost [127.0.0.1]) by smtp1.dnsmadeeasy.com (Postfix) with ESMTP id 43AD23110FA; Wed, 12 Dec 2007 06:40:57 +0000 (UTC) X-Authenticated-Name: js.dnsmadeeasy X-Transit-System: In case of SPAM please contact abuse@dnsmadeeasy.com Received: from avtrex.com (unknown [67.116.42.147]) by smtp1.dnsmadeeasy.com (Postfix) with ESMTP; Wed, 12 Dec 2007 06:40:56 +0000 (UTC) Received: from [192.168.7.224] ([192.168.7.224]) by avtrex.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 11 Dec 2007 22:40:50 -0800 Message-ID: <475F8272.6040702@avtrex.com> Date: Tue, 11 Dec 2007 22:40:50 -0800 From: David Daney User-Agent: Thunderbird 1.5.0.12 (X11/20071019) MIME-Version: 1.0 To: linux-mips@linux-mips.org Cc: Florian Lohoff Subject: Re: 2.6.24-rc2 crash in kmap_coherent References: <20071211221327.GB2150@paradigm.rfc822.org> <475F13F1.2050109@avtrex.com> In-Reply-To: <475F13F1.2050109@avtrex.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 12 Dec 2007 06:40:51.0046 (UTC) FILETIME=[EFBE2060:01C83C89] Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 17783 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: ddaney@avtrex.com Precedence: bulk X-list: linux-mips David Daney wrote: > Florian Lohoff wrote: >> Hi, >> i just discovered that my native gcc build on one of my Indys stopped. I >> found this in the dmesg ;) >> >> Its a 2.6.24-rc2 on an R5k Indy 64M: >> >> Kernel bug detected[#1]: >> Cpu 0 >> $ 0 : 0000000000000000 ffffffff9000cce0 0000000000000001 >> ffffffff80000000 >> $ 4 : ffffffff8921f910 000000007fda0f05 000000007fda0f05 >> ffffffff8b8ea000 >> $ 8 : ffffffff89b4ef05 000000000000000e ffffffff8921f910 >> 0000000000000f05 >> $12 : 0000000000000000 ffffffff80000008 ffffffff88090010 >> 00000000004038b4 >> $16 : ffffffff8921f910 000000007fda0f05 ffffffff8b8ea000 >> 000000000000000e >> $20 : ffffffff8bdfb920 0000000000000000 ffffffff8bd88cc0 >> ffffffff8893fd58 >> $24 : 0000000000000006 >> ffffffff8801df00 $28 : >> ffffffff8893c000 ffffffff8893fd20 ffffffff88430000 ffffffff8801c010 >> Hi : 000000000001d1ea >> Lo : 0000000000009b4e >> epc : ffffffff8801bcf0 kmap_coherent+0x10/0x130 Not tainted >> ra : ffffffff8801c010 copy_from_user_page+0x40/0xb0 >> Status: 9000cce3 KX SX UX KERNEL EXL IE Cause : 00000034 >> PrId : 00002321 (R5000) >> Modules linked in: dm_snapshot dm_mirror dm_mod ipv6 >> Process cat (pid: 14553, threadinfo=ffffffff8893c000, >> task=ffffffff88a52660) >> Stack : 000000000000000e 000000007fda0f05 ffffffff8b8ea000 >> 0000000000000000 >> ffffffff88079d10 ffffffff88079cc4 ffffffff8bfbd528 >> ffffffff8921f910 >> ffffffff8bdfb980 ffffffff8b8ea000 ffffffff8bdfb920 >> 0000000000000000 >> ffffffff8b8ea000 000000000000000e ffffffff8bd88cc0 >> ffffffff8893fe78 >> 0000000000447000 000000000052c7d8 0000000000000000 >> ffffffff880d9014 >> ffffffff8bd88cc0 ffffffff8b8ea000 fffffffffffffff4 >> ffffffff8b863248 >> 0000000000000400 ffffffff8893fe78 0000000000447000 >> ffffffff880db188 >> ffffffff8be6f6e0 0000000000000400 0000000000447000 >> ffffffff8893fe78 >> 0000000000447000 0000000000000003 0000000000000016 >> ffffffff8808fbdc >> ffffffff8be6f6e0 0000000000000400 0000000000447000 >> fffffffffffffff7 >> ... >> Call Trace: >> [] kmap_coherent+0x10/0x130 >> [] copy_from_user_page+0x40/0xb0 >> [] access_process_vm+0x168/0x1d8 >> [] proc_pid_cmdline+0xac/0x140 >> [] proc_info_read+0x108/0x150 >> [] vfs_read+0xec/0x178 >> [] sys_read+0x50/0x98 >> [] handle_sys+0x118/0x134 >> >> >> Code: 0002127a 00021000 30420001 <00028036> 8f820024 3c038843 >> 24420001 af820024 dc62f390 > > FWIW I get something very similar reading /proc/1/cmdline on > 2.6.23-1/ip32 w/ R5000 and there have been other similar postings here > recently. > > Maybe one day I will look into it, but it probably will not be real > soon... > Here is some further data: # cat /proc/version Linux version 2.6.23.1-DD_Patched (daney@silver64.hq2.avtrex.com) (gcc version 4.2.3 20071029 (prerelease)) #7 Sun Oct 28 23:40:58 PDT 2007 # cat /proc/cpuinfo system type : SGI O2 processor : 0 cpu model : R5000 V2.1 FPU V1.0 BogoMIPS : 199.68 wait instruction : yes microsecond timers : yes tlb_entries : 48 extra interrupt vector : no hardware watchpoint : no ASEs implemented : VCED exceptions : not available VCEI exceptions : not available Kernel bug detected[#3]: Cpu 0 $ 0 : 0000000000000000 ffffffff80450000 0000000000000001 0000000000002ee4 $ 4 : 980000000116f2f8 000000007ffc3ee4 00000000068e9603 0000000000100177 $ 8 : 000000007ffc3ee4 000000000000000e 0000000000000000 9800000005e7bd60 $12 : 0000000000000000 ffffffff80000008 ffffffff800a4958 00000000004038b4 $16 : 980000000116f2f8 000000000000000e 980000000d9a02a8 000000007ffc3ee4 $20 : 980000000bba2ce8 980000000b402cc0 9800000005e7bd60 9800000005e7bd68 $24 : 0000000000000006 000000002ab9d1f4 $28 : 9800000005e78000 9800000005e7bcc0 0000000000000000 ffffffff8001db68 Hi : 0000000000013abb Lo : 00000000000068e9 epc : ffffffff8001f370 kmap_coherent+0x10/0x128 Tainted: G D ra : ffffffff8001db68 __flush_anon_page+0x90/0xc0 Status: b001fce3 KX SX UX KERNEL EXL IE Cause : 00000034 PrId : 00002321 Modules linked in: ipv6 dm_snapshot dm_mirror dm_mod sg evdev Process cat (pid: 2851, threadinfo=9800000005e78000, task=980000000bd08cc8) Stack : ffffffff8008a4a0 ffffffff8008a0c0 0000000000000001 0000000000000000 9800000005e7bd68 9800000005e7bd60 0000000000000010 0000000000000006 000000000000000e 0000000000000044 980000000b402cc0 980000000978d000 0000000000000012 000000007ffc3ee4 980000000978d000 0000000000000012 980000000b402cc0 0000000000000000 980000000bba2ce8 ffffffff8008a650 0000000000000000 980000000116f2f8 980000000b402d20 980000000978d000 980000000b402cc0 980000000978d000 0000000000000012 0000000000000000 980000000bba2ce8 0000000000448000 0000000000001000 0000000000530328 0000000000000000 ffffffff800f8c20 980000000978d000 980000000bba2ce8 9800000009a49920 0000000000000400 9800000005e7be88 0000000000448000 ... Call Trace: [] kmap_coherent+0x10/0x128 [] __flush_anon_page+0x90/0xc0 [] get_user_pages+0x478/0x4f8 [] access_process_vm+0x130/0x230 [] proc_pid_cmdline+0xa8/0x170 [] proc_info_read+0x120/0x190 [] vfs_read+0xc0/0x160 [] sys_read+0x48/0xb0 [] handle_sys+0x134/0x150 Code: 0002127a 00021000 30420001 <00028036> 8f820024 00052b3a 24420001 af820024 3c0236db This is the result of doing: cat /proc/2818/cmdline 2818 is sshd, but I think that does not really matter. Before any pages had been swapped out I was able to get the command line. Then I did some work (run gdb on a very large program) that caused some pages to be swapped out. After that the cat fails with a SIGSEGV in sys_read and the above trace is produced. My theory is that if the page containing the command line is present, all is OK, but if it has been swapped out this happens. However if I turn off the swap device after the first occurrence of the problem, it does not seem to correct itself, so I don't really know what is causing it. The fault is caused by a 'tne' instruction in the first statement of kmap_coherent in arch/mips/mm/init.c: BUG_ON(Page_dcache_dirty(page)); There seems to be a bit of a logic error here: void __flush_anon_page(struct page *page, unsigned long vmaddr) { if (pages_do_alias((unsigned long)page_address(page), vmaddr)) { void *kaddr; kaddr = kmap_coherent(page, vmaddr); flush_data_cache_page((unsigned long)kaddr); kunmap_coherent(); } } We are calling kmap_coherent so that we can flush the cache for the page, but the first thing kmap_coherent does is BUG_ON if the cache is dirty... From ralf@linux-mips.org Wed Dec 12 11:24:23 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 12 Dec 2007 11:24:25 +0000 (GMT) Received: from localhost.localdomain ([127.0.0.1]:2454 "EHLO dl5rb.ham-radio-op.net") by ftp.linux-mips.org with ESMTP id S28574355AbXLLLYX (ORCPT ); Wed, 12 Dec 2007 11:24:23 +0000 Received: from denk.linux-mips.net (denk.linux-mips.net [127.0.0.1]) by dl5rb.ham-radio-op.net (8.14.1/8.13.8) with ESMTP id lBCBNj62029796; Wed, 12 Dec 2007 11:23:45 GMT Received: (from ralf@localhost) by denk.linux-mips.net (8.14.1/8.14.1/Submit) id lBCBNhOi029795; Wed, 12 Dec 2007 11:23:43 GMT Date: Wed, 12 Dec 2007 11:23:43 +0000 From: Ralf Baechle To: Yoichi Yuasa Cc: linux-mips@linux-mips.org Subject: Re: Cobalt fixes Message-ID: <20071212112343.GA28868@linux-mips.org> References: <20071211121220.GA10870@linux-mips.org> <20071211235001.8621bdb9.yoichi_yuasa@tripeaks.co.jp> <20071211153522.GB15843@linux-mips.org> <20071212075309.5172da92.yoichi_yuasa@tripeaks.co.jp> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20071212075309.5172da92.yoichi_yuasa@tripeaks.co.jp> User-Agent: Mutt/1.5.17 (2007-11-01) Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 17784 X-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 12, 2007 at 07:53:09AM +0900, Yoichi Yuasa wrote: > > > > for non-subscribers. Linus has reverted the offending patch > > > > fd6e732186ab522c812ab19c2c5e5befb8ec8115 in question so now the PCI and > > > > I/O port code needs to be fixed up to be able to handle such a setup. > > > > > > It can be fixed my fix PCI resource patch. > > > > > > http://www.linux-mips.org/archives/linux-mips/2007-01/msg00049.html > > > > Modulo a codying style issue that one is the same as the pci.c segment of > > the patch I've just posted. > > This is a fix proposed before fd6e732186ab522c812ab19c2c5e5befb8ec8115. > This patch is still effective. Ah, I had already applied the identical patch yesterday. Thanks anyway! But it should be considered temporary. For some configurations there is no chance for this to work and the patch will probably get in my way for the planned rewrite of the resource allocation. Ralf From ralf@linux-mips.org Wed Dec 12 12:06:50 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 12 Dec 2007 12:06:52 +0000 (GMT) Received: from localhost.localdomain ([127.0.0.1]:50656 "EHLO dl5rb.ham-radio-op.net") by ftp.linux-mips.org with ESMTP id S28574378AbXLLMGu (ORCPT ); Wed, 12 Dec 2007 12:06:50 +0000 Received: from denk.linux-mips.net (denk.linux-mips.net [127.0.0.1]) by dl5rb.ham-radio-op.net (8.14.1/8.13.8) with ESMTP id lBCC6Bo1030264; Wed, 12 Dec 2007 12:06:11 GMT Received: (from ralf@localhost) by denk.linux-mips.net (8.14.1/8.14.1/Submit) id lBCC6AFH030263; Wed, 12 Dec 2007 12:06:10 GMT Date: Wed, 12 Dec 2007 12:06:10 +0000 From: Ralf Baechle To: Florian Lohoff Cc: linux-mips@linux-mips.org, David Daney Subject: Re: 2.6.24-rc2 crash in kmap_coherent Message-ID: <20071212120610.GB28868@linux-mips.org> References: <20071211221327.GB2150@paradigm.rfc822.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20071211221327.GB2150@paradigm.rfc822.org> User-Agent: Mutt/1.5.17 (2007-11-01) Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 17785 X-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 11, 2007 at 11:13:27PM +0100, Florian Lohoff wrote: > Call Trace: > [] kmap_coherent+0x10/0x130 > [] copy_from_user_page+0x40/0xb0 > [] access_process_vm+0x168/0x1d8 > [] proc_pid_cmdline+0xac/0x140 > [] proc_info_read+0x108/0x150 > [] vfs_read+0xec/0x178 > [] sys_read+0x50/0x98 > [] handle_sys+0x118/0x134 > > > Code: 0002127a 00021000 30420001 <00028036> 8f820024 3c038843 24420001 af820024 dc62f390 Hmm... This suggests that 283abbaef425c1bf817ecbb456c413cab08b1434 is not quite right. It is making the assumption that a mapped page never has PG_dcache_dirty set. Ralf From yoichi_yuasa@tripeaks.co.jp Wed Dec 12 13:11:19 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 12 Dec 2007 13:11:28 +0000 (GMT) Received: from mo31.po.2iij.NET ([210.128.50.54]:44322 "EHLO mo31.po.2iij.net") by ftp.linux-mips.org with ESMTP id S20032245AbXLLNLS (ORCPT ); Wed, 12 Dec 2007 13:11:18 +0000 Received: by mo.po.2iij.net (mo31) id lBCDBFri074494; Wed, 12 Dec 2007 22:11:15 +0900 (JST) Received: from delta (224.24.30.125.dy.iij4u.or.jp [125.30.24.224]) by mbox.po.2iij.net (po-mbox304) id lBCDBAjD027592 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 12 Dec 2007 22:11:10 +0900 Date: Wed, 12 Dec 2007 22:11:09 +0900 From: Yoichi Yuasa To: Ralf Baechle Cc: yoichi_yuasa@tripeaks.co.jp, linux-mips Subject: [PATCH][MIPS] move vr41xx_calculate_clock_frequency() to plat_time_init() Message-Id: <20071212221109.e0448c18.yoichi_yuasa@tripeaks.co.jp> Organization: TriPeaks Corporation X-Mailer: Sylpheed 2.4.5 (GTK+ 2.12.0; 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: 17786 X-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 Moved vr41xx_calculate_clock_frequency() to plat_time_init(). This function relates to the timer function. Signed-off-by: Yoichi Yuasa diff -pruN -X mips/Documentation/dontdiff mips-orig/arch/mips/vr41xx/common/init.c mips/arch/mips/vr41xx/common/init.c --- mips-orig/arch/mips/vr41xx/common/init.c 2007-10-25 07:34:48.001908250 +0900 +++ mips/arch/mips/vr41xx/common/init.c 2007-10-25 07:49:57.538750750 +0900 @@ -40,6 +40,8 @@ void __init plat_time_init(void) { unsigned long tclock; + vr41xx_calculate_clock_frequency(); + tclock = vr41xx_get_tclock_frequency(); if (current_cpu_data.processor_id == PRID_VR4131_REV2_0 || current_cpu_data.processor_id == PRID_VR4131_REV2_1) @@ -50,8 +52,6 @@ void __init plat_time_init(void) void __init plat_mem_setup(void) { - vr41xx_calculate_clock_frequency(); - iomem_resource_init(); } From yoichi_yuasa@tripeaks.co.jp Wed Dec 12 13:23:45 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 12 Dec 2007 13:23:54 +0000 (GMT) Received: from mo32.po.2iij.net ([210.128.50.17]:17946 "EHLO mo32.po.2iij.net") by ftp.linux-mips.org with ESMTP id S20032300AbXLLNXp (ORCPT ); Wed, 12 Dec 2007 13:23:45 +0000 Received: by mo.po.2iij.net (mo32) id lBCDNgdR006691; Wed, 12 Dec 2007 22:23:42 +0900 (JST) Received: from delta (224.24.30.125.dy.iij4u.or.jp [125.30.24.224]) by mbox.po.2iij.net (po-mbox300) id lBCDNefa006383 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 12 Dec 2007 22:23:40 +0900 Date: Wed, 12 Dec 2007 22:20:19 +0900 From: Yoichi Yuasa To: Ralf Baechle Cc: yoichi_yuasa@tripeaks.co.jp, linux-mips Subject: [PATCH][1/2][MIPS] remove unneeded button check for reset Message-Id: <20071212222019.9ab7b2ed.yoichi_yuasa@tripeaks.co.jp> Organization: TriPeaks Corporation X-Mailer: Sylpheed 2.4.5 (GTK+ 2.12.0; 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: 17787 X-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 Removed unneeded button check for reset. Because, the Cobalt has power switch. Signed-off-by: Yoichi Yuasa diff -pruN -X mips/Documentation/dontdiff mips-orig/arch/mips/cobalt/reset.c mips/arch/mips/cobalt/reset.c --- mips-orig/arch/mips/cobalt/reset.c 2007-10-22 08:37:03.176567500 +0900 +++ mips/arch/mips/cobalt/reset.c 2007-10-22 09:28:23.004538000 +0900 @@ -10,7 +10,6 @@ */ #include #include -#include #include #include @@ -29,29 +28,14 @@ device_initcall(ledtrig_power_off_init); void cobalt_machine_halt(void) { - int state, last, diff; - unsigned long mark; - /* * turn on power off LED on RaQ - * - * restart if ENTER and SELECT are pressed */ - - last = COBALT_KEY_PORT; - led_trigger_event(power_off_led_trigger, LED_FULL); - for (state = 0;;) { - diff = COBALT_KEY_PORT ^ last; - last ^= diff; - - if((diff & (COBALT_KEY_ENTER | COBALT_KEY_SELECT)) && !(~last & (COBALT_KEY_ENTER | COBALT_KEY_SELECT))) - writeb(RESET, RESET_PORT); - - for (mark = jiffies; jiffies - mark < HZ;) - ; - } + local_irq_disable(); + printk(KERN_INFO "You can switch the machine off now.\n"); + while (1) ; } void cobalt_machine_restart(char *command) diff -pruN -X mips/Documentation/dontdiff mips-orig/include/asm-mips/mach-cobalt/cobalt.h mips/include/asm-mips/mach-cobalt/cobalt.h --- mips-orig/include/asm-mips/mach-cobalt/cobalt.h 2007-10-22 08:40:46.866547250 +0900 +++ mips/include/asm-mips/mach-cobalt/cobalt.h 2007-10-22 09:27:42.101981750 +0900 @@ -1,5 +1,5 @@ /* - * Lowlevel hardware stuff for the MIPS based Cobalt microservers. + * The Cobalt board ID information. * * 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 @@ -12,9 +12,6 @@ #ifndef __ASM_COBALT_H #define __ASM_COBALT_H -/* - * The Cobalt board ID information. - */ extern int cobalt_board_id; #define COBALT_BRD_ID_QUBE1 0x3 @@ -22,14 +19,4 @@ extern int cobalt_board_id; #define COBALT_BRD_ID_QUBE2 0x5 #define COBALT_BRD_ID_RAQ2 0x6 -#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 - #endif /* __ASM_COBALT_H */ From yoichi_yuasa@tripeaks.co.jp Wed Dec 12 13:25:02 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 12 Dec 2007 13:25:10 +0000 (GMT) Received: from mo31.po.2iij.NET ([210.128.50.54]:2343 "EHLO mo31.po.2iij.net") by ftp.linux-mips.org with ESMTP id S20032315AbXLLNZC (ORCPT ); Wed, 12 Dec 2007 13:25:02 +0000 Received: by mo.po.2iij.net (mo31) id lBCDNiUf081457; Wed, 12 Dec 2007 22:23:44 +0900 (JST) Received: from delta (224.24.30.125.dy.iij4u.or.jp [125.30.24.224]) by mbox.po.2iij.net (po-mbox303) id lBCDNfmQ028025 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 12 Dec 2007 22:23:41 +0900 Date: Wed, 12 Dec 2007 22:23:13 +0900 From: Yoichi Yuasa To: Ralf Baechle Cc: yoichi_yuasa@tripeaks.co.jp, linux-mips Subject: [PATCH][2/2][MIPS] add cpu_wait() to machine_halt() Message-Id: <20071212222313.92e69c16.yoichi_yuasa@tripeaks.co.jp> In-Reply-To: <20071212222019.9ab7b2ed.yoichi_yuasa@tripeaks.co.jp> References: <20071212222019.9ab7b2ed.yoichi_yuasa@tripeaks.co.jp> Organization: TriPeaks Corporation X-Mailer: Sylpheed 2.4.5 (GTK+ 2.12.0; 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: 17788 X-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 Added cpu_wait() to machine_halt(). For the power reduction in halt. Signed-off-by: Yoichi Yuasa diff -pruN -X mips/Documentation/dontdiff mips-orig/arch/mips/cobalt/reset.c mips/arch/mips/cobalt/reset.c --- mips-orig/arch/mips/cobalt/reset.c 2007-10-22 09:32:10.074729000 +0900 +++ mips/arch/mips/cobalt/reset.c 2007-10-22 09:59:23.092786250 +0900 @@ -12,6 +12,8 @@ #include #include +#include + #include #define RESET_PORT ((void __iomem *)CKSEG1ADDR(0x1c000000)) @@ -35,7 +37,10 @@ void cobalt_machine_halt(void) local_irq_disable(); printk(KERN_INFO "You can switch the machine off now.\n"); - while (1) ; + while (1) { + if (cpu_wait) + cpu_wait(); + } } void cobalt_machine_restart(char *command) From yoichi_yuasa@tripeaks.co.jp Wed Dec 12 13:41:16 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 12 Dec 2007 13:41:24 +0000 (GMT) Received: from mo30.po.2iij.NET ([210.128.50.53]:45592 "EHLO mo30.po.2iij.net") by ftp.linux-mips.org with ESMTP id S20032328AbXLLNlQ (ORCPT ); Wed, 12 Dec 2007 13:41:16 +0000 Received: by mo.po.2iij.net (mo30) id lBCDdwmx000543; Wed, 12 Dec 2007 22:39:58 +0900 (JST) Received: from delta (224.24.30.125.dy.iij4u.or.jp [125.30.24.224]) by mbox.po.2iij.net (po-mbox304) id lBCDdsNh016166 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 12 Dec 2007 22:39:55 +0900 Date: Wed, 12 Dec 2007 22:39:54 +0900 From: Yoichi Yuasa To: Ralf Baechle Cc: yoichi_yuasa@tripeaks.co.jp, linux-mips Subject: [PATCH][MIPS] move the eXcite local config to excitedirectory Message-Id: <20071212223954.44e12672.yoichi_yuasa@tripeaks.co.jp> Organization: TriPeaks Corporation X-Mailer: Sylpheed 2.4.5 (GTK+ 2.12.0; 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: 17789 X-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 Moved the eXcite local config to excite directory. Signed-off-by: Yoichi Yuasa diff -pruN -X mips/Documentation/dontdiff mips-orig/arch/mips/Kconfig mips/arch/mips/Kconfig --- mips-orig/arch/mips/Kconfig 2007-12-12 00:06:19.245069500 +0900 +++ mips/arch/mips/Kconfig 2007-12-12 00:09:53.974489250 +0900 @@ -37,16 +37,6 @@ config BASLER_EXCITE The eXcite is a smart camera platform manufactured by Basler Vision Technologies AG. -config BASLER_EXCITE_PROTOTYPE - bool "Support for pre-release units" - depends on BASLER_EXCITE - default n - help - Pre-series (prototype) units are different from later ones in - some ways. Select this option if you have one of these. Please - note that a kernel built with this option selected will not be - able to run on normal units. - config BCM47XX bool "BCM47XX based boards" select CEVT_R4K @@ -688,6 +678,7 @@ config WR_PPMC endchoice source "arch/mips/au1000/Kconfig" +source "arch/mips/basler/excite/Kconfig" source "arch/mips/jazz/Kconfig" source "arch/mips/lasat/Kconfig" source "arch/mips/pmc-sierra/Kconfig" diff -pruN -X mips/Documentation/dontdiff mips-orig/arch/mips/basler/excite/Kconfig mips/arch/mips/basler/excite/Kconfig --- mips-orig/arch/mips/basler/excite/Kconfig 1970-01-01 09:00:00.000000000 +0900 +++ mips/arch/mips/basler/excite/Kconfig 2007-12-12 00:09:53.974489250 +0900 @@ -0,0 +1,9 @@ +config BASLER_EXCITE_PROTOTYPE + bool "Support for pre-release units" + depends on BASLER_EXCITE + default n + help + Pre-series (prototype) units are different from later ones in + some ways. Select this option if you have one of these. Please + note that a kernel built with this option selected will not be + able to run on normal units. From pf@pfrst.de Wed Dec 12 15:26:59 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 12 Dec 2007 15:27:08 +0000 (GMT) Received: from mail1.pearl-online.net ([62.159.194.147]:41288 "EHLO mail1.pearl-online.net") by ftp.linux-mips.org with ESMTP id S20032396AbXLLP07 (ORCPT ); Wed, 12 Dec 2007 15:26:59 +0000 Received: from SNaIlmail.Peter (77.47.4.157.static.cablesurf.de [77.47.4.157]) by mail1.pearl-online.net (Postfix) with ESMTP id 978ADB14C; Wed, 12 Dec 2007 16:27:28 +0100 (CET) Received: from Indigo2.Peter (Indigo2.Peter [192.168.1.28]) by SNaIlmail.Peter (8.12.6/8.12.6/Sendmail/Linux 2.0.32) with ESMTP id lBCFQZ9U000788; Wed, 12 Dec 2007 16:26:36 +0100 Received: from Indigo2.Peter (localhost [127.0.0.1]) by Indigo2.Peter (8.12.6/8.12.6/Sendmail/Linux 2.6.14-rc2-ip28) with ESMTP id lBCFQVmq000535; Wed, 12 Dec 2007 16:26:31 +0100 Received: from localhost (pf@localhost) by Indigo2.Peter (8.12.6/8.12.6/Submit) with ESMTP id lBCFQVfF000532; Wed, 12 Dec 2007 16:26:31 +0100 Date: Wed, 12 Dec 2007 16:26:31 +0100 (CET) From: peter fuerst To: Richard Sandiford Cc: Ralf Baechle , Thomas Bogendoerfer , Kumba , linux-mips@linux-mips.org Subject: Re: [UPDATED PATCH] IP28 support In-Reply-To: <871w9u24rd.fsf@firetop.home> Message-ID: 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: 17790 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: pf@pfrst.de Precedence: bulk X-list: linux-mips On Mon, 10 Dec 2007, Richard Sandiford wrote: > Ralf Baechle writes: > >> Then there's the language-lawyerly code I gave to Peter on gcc-patches@: > >> > >> void foo (int x) > >> { > >> int array[1]; > >> if (x) > >> bar (array[0x1fff]); > >> } > >> A strange method to pass data... Of course, cooking up such an "ABI", where local variables are accessed with a const offset that is not known at compile-time to be valid, would subvert the test for $sp-based accesses... > >> This function is valid if x is never true, so we cannot assume that all > >> accesses off the stack and frame pointers are actually in-frame. You're > >> assuming either (i) the kernel doesn't use code like that or (ii) that > >> "garbage" addresses in the range [$sp - 0x8000, $sp + 0x7fff] will not > >> trigger the problem. I imagine both are reasonable assumptions, and I'm > >> perfectly happy for us to make them. But they're the kind of assumption > >> we need to state explicitly. > > > > Interesting test case. I've been thinking about it myself but in the end > > decieded to believe Peter's analysis since he's banged the head for longer > > to the wall about this problem that I have ;-) I'm quite but not absolutely > > certain that this case cannot happen for realworld code, so I'd rather > > err on the side of caution. > > > > Peter & Thomas - we could make the stack thing bullet proof by vmallocing > > stacks and ensuring a sufficient virtual address gap exists around the stack > > such that the stack is the only addressable thing in the range of > > $sp +0x7fff / -0x8000? ...but having an address-gap, virtual or by unused memory, should make it save even with such code. Typical "realworld" examples for speculative access to stack-variables are void foo (int x) void foo () { { int array[N]; int array[N], i; if (x < N) for (i = 0; i < N; i++) bar (array[x]); array[i] = 0; } } i.e. accesses with non-const offsets, i.e. no longer $sp-based, which always will trigger a CB. > > FWIW, my first cut at the option restrictions were based on what > the patch exempts (and doesn't exempt). We could instead get gcc > to only exempt accesses that it can prove are either to the current > function's stack frame or to its stack arguments. I.e. rather than > consider every $sp-based access to be safe, we'd instead do some "every $sp-based access" (set(mem(plus(sp)(const_int)))) is restricted to local variables too, with the constant offset being either - compiler-generated or - deliberately put in the source (however including the above example) > bounds checking on the value. Fine, if that is possible. > (We could also use MEM_ATTRS to > pick up cases where a stack variable is acceesed via something > other than the stack or frame pointers, as happens for large frames.) Aren't these always accesses with non-constant offset, where a CB can't be avoided, even if they are recognized as being actually relative to $sp ? > > >> Peter's patch also treated accesses to constant integer and symbolic > >> addresses as safe. Again, this involves making assumptions about how > >> constant integer and symbolic addresses are used, and this is a much > >> less obvious assumption than the stack one. > > > > The latter assumption is also needed for -msym32 kernels, so it's well > > proven to be valid. The former hold, too. > > > >> Again, I understand that > >> it's a reasonable assumption to make in the linux context, but it's one > >> we need to pin down. E.g. there must be no run-time guarding of > >> target-specific constant integer IO-mapped addresses in cases where > >> those addresses might trigger the problem on other systems that the > >> same kernel image supports. > > > > In case of a hypothetic multi-platform kernel of which at least one needs > > the R10000 workarounds, all code would be uniformly compiled with the > > magic -mr10k-cache-barrier option and all source level workaround would > > be enabled. > > Hmm. This probably shows I am misunderstanding the problem, but I was > thinking about the IO-mapped case. I thought one of the problems was > that if you had a cached speculative load or store to an access-sensitive > IO-mapped address, the IO-mapped device might "see" that access even if it > doesn't take place. Could you not have a situation where a KSEG0 or > XKSEG0 access is access-sensitive on one machine and not another? > The patch won't insert countermeasures before symbolic and constant > addresses, because it believes all such addresses to be safe. > The threat to IO-addresses comes from the addressing register in the speculated mem-instruction (set(mem(plus(reg)...), containing one of the addresses as "garbage". Symbolic addresses are well defined from link-time on, no matter what history before the access. They either point (set(mem(plus(symbol_ref)...) to - some variable in the cached area, what is harmless (unless DMA-related), or to - IO-devices, accessed uncached, i.e. non-speculative, unless there is a programming-error ;) The same holds for const_int used as address. If used for DMA and also directly accessed, symbolic addresses could be problematic though: extern char big_fat_dma_buffer[N]; if (!dma_running) *big_fat_dma_buffer = 0; else ... (However, as soon as accessed with non-constant offset - e.g. in a loop,... - the symbol_ref disappears from the mem-instruction which will trigger a CB) Btw. with 4.x symbolic addresses are practically (without backtrace analysis) not exempted from CBs, since they no longer show up in the mem-instruction and (set(mem(lo_sum(reg)... is seen instead. > I'm also a little worried that the compiler is free to make up accesses > that didn't exist in the original program, provided that those accesses The cache-barrier itself ? > are never actually performed in cases where they'd be wrong. So how about: > > -mr10k-cache-barrier=load-store > Insert a cache barrier at the beginning of any sequentially-executed > series of instructions that contains a load or store. For the purposes > of this option, GCC can ignore loads and stores that it can prove > are an in-range access to: > > (a) the current function's stack frame; > (b) an incoming stack argument; > (b) an object with a link-time-constant address; or > (c) a block of uncached memory Can we recognize uncached memory in the instruction ? > > It can also ignore sequences that are always immediately preceded by > an untaken branch-likely instruction. Fine! > > Here, a ``sequentially-executed series'' is one in which calls, > jumps and branches occur only as the last instruction. > > -mr10k-cache-barrier=store > Like -mr10k-cache-barrier=load-store, but ignore all loads. > > -mr10k-cache-barrier=none > ... > > Richard > > > kind regards peter From ralf@linux-mips.org Wed Dec 12 15:33:00 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 12 Dec 2007 15:33:02 +0000 (GMT) Received: from localhost.localdomain ([127.0.0.1]:44491 "EHLO dl5rb.ham-radio-op.net") by ftp.linux-mips.org with ESMTP id S20032611AbXLLPdA (ORCPT ); Wed, 12 Dec 2007 15:33:00 +0000 Received: from denk.linux-mips.net (denk.linux-mips.net [127.0.0.1]) by dl5rb.ham-radio-op.net (8.14.1/8.13.8) with ESMTP id lBCFWIj5024565; Wed, 12 Dec 2007 15:32:19 GMT Received: (from ralf@localhost) by denk.linux-mips.net (8.14.1/8.14.1/Submit) id lBCFWII6024564; Wed, 12 Dec 2007 15:32:18 GMT Date: Wed, 12 Dec 2007 15:32:18 +0000 From: Ralf Baechle To: Florian Lohoff Cc: linux-mips@linux-mips.org, David Daney Subject: Re: 2.6.24-rc2 crash in kmap_coherent Message-ID: <20071212153218.GA30291@linux-mips.org> References: <20071211221327.GB2150@paradigm.rfc822.org> <20071212120610.GB28868@linux-mips.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20071212120610.GB28868@linux-mips.org> User-Agent: Mutt/1.5.17 (2007-11-01) Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 17791 X-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 12, 2007 at 12:06:10PM +0000, Ralf Baechle wrote: > > Call Trace: > > [] kmap_coherent+0x10/0x130 > > [] copy_from_user_page+0x40/0xb0 > > [] access_process_vm+0x168/0x1d8 > > [] proc_pid_cmdline+0xac/0x140 > > [] proc_info_read+0x108/0x150 > > [] vfs_read+0xec/0x178 > > [] sys_read+0x50/0x98 > > [] handle_sys+0x118/0x134 > > > > > > Code: 0002127a 00021000 30420001 <00028036> 8f820024 3c038843 24420001 af820024 dc62f390 > > Hmm... This suggests that 283abbaef425c1bf817ecbb456c413cab08b1434 is > not quite right. It is making the assumption that a mapped page never has > PG_dcache_dirty set. Totally untested because I have other stuff to do but something along the lines of below patch, I think. Ralf diff --git a/arch/mips/mm/init.c b/arch/mips/mm/init.c index 480dec0..db5d608 100644 --- a/arch/mips/mm/init.c +++ b/arch/mips/mm/init.c @@ -211,7 +211,8 @@ void copy_user_highpage(struct page *to, struct page *from, void *vfrom, *vto; vto = kmap_atomic(to, KM_USER1); - if (cpu_has_dc_aliases && page_mapped(from)) { + if (cpu_has_dc_aliases && + page_mapped(from) && !Page_dcache_dirty(from)) { vfrom = kmap_coherent(from, vaddr); copy_page(vto, vfrom); kunmap_coherent(); @@ -234,7 +235,8 @@ void copy_to_user_page(struct vm_area_struct *vma, struct page *page, unsigned long vaddr, void *dst, const void *src, unsigned long len) { - if (cpu_has_dc_aliases && page_mapped(page)) { + if (cpu_has_dc_aliases && + page_mapped(page) && !Page_dcache_dirty(from)) { void *vto = kmap_coherent(page, vaddr) + (vaddr & ~PAGE_MASK); memcpy(vto, src, len); kunmap_coherent(); @@ -253,7 +255,8 @@ void copy_from_user_page(struct vm_area_struct *vma, struct page *page, unsigned long vaddr, void *dst, const void *src, unsigned long len) { - if (cpu_has_dc_aliases && page_mapped(page)) { + if (cpu_has_dc_aliases && + page_mapped(page) && !Page_dcache_dirty(page)) { void *vfrom = kmap_coherent(page, vaddr) + (vaddr & ~PAGE_MASK); memcpy(dst, vfrom, len); kunmap_coherent(); From giuseppe@eppesuigoccas.homedns.org Wed Dec 12 17:10:35 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 12 Dec 2007 17:10:44 +0000 (GMT) Received: from host188-210-dynamic.20-79-r.retail.telecomitalia.it ([79.20.210.188]:18579 "EHLO eppesuigoccas.homedns.org") by ftp.linux-mips.org with ESMTP id S20034423AbXLLRKf (ORCPT ); Wed, 12 Dec 2007 17:10:35 +0000 Received: from 89-96-243-184.ip14.fastwebnet.it ([89.96.243.184] helo=[192.168.215.30]) by eppesuigoccas.homedns.org with esmtpsa (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from ) id 1J2V6C-00062n-GP; Wed, 12 Dec 2007 18:10:22 +0100 Subject: Re: 2.6.24-rc2 crash in kmap_coherent From: Giuseppe Sacco To: Ralf Baechle Cc: Florian Lohoff , linux-mips@linux-mips.org, David Daney In-Reply-To: <20071212153218.GA30291@linux-mips.org> References: <20071211221327.GB2150@paradigm.rfc822.org> <20071212120610.GB28868@linux-mips.org> <20071212153218.GA30291@linux-mips.org> Content-Type: text/plain Date: Wed, 12 Dec 2007 18:11:11 +0100 Message-Id: <1197479471.25499.48.camel@scarafaggio> Mime-Version: 1.0 X-Mailer: Evolution 2.10.3 Content-Transfer-Encoding: 7bit Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 17792 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: giuseppe@eppesuigoccas.homedns.org Precedence: bulk X-list: linux-mips Hi Ralf, the change you proposed here give an error since "page" is onlt available on function copy_user_highpage() while there is not such variable (nor parameter) in function copy_to_user_page(). I am actually recompiling everything using only the first part of your patch, but I think it will not be enough. Bye, Giuseppe Il giorno mer, 12/12/2007 alle 15.32 +0000, Ralf Baechle ha scritto: [...] > Totally untested because I have other stuff to do but something along the > lines of below patch, I think. > > Ralf > > diff --git a/arch/mips/mm/init.c b/arch/mips/mm/init.c > index 480dec0..db5d608 100644 > --- a/arch/mips/mm/init.c > +++ b/arch/mips/mm/init.c > @@ -211,7 +211,8 @@ void copy_user_highpage(struct page *to, struct page *from, > void *vfrom, *vto; > > vto = kmap_atomic(to, KM_USER1); > - if (cpu_has_dc_aliases && page_mapped(from)) { > + if (cpu_has_dc_aliases && > + page_mapped(from) && !Page_dcache_dirty(from)) { > vfrom = kmap_coherent(from, vaddr); > copy_page(vto, vfrom); > kunmap_coherent(); > @@ -234,7 +235,8 @@ void copy_to_user_page(struct vm_area_struct *vma, > struct page *page, unsigned long vaddr, void *dst, const void *src, > unsigned long len) > { > - if (cpu_has_dc_aliases && page_mapped(page)) { > + if (cpu_has_dc_aliases && > + page_mapped(page) && !Page_dcache_dirty(from)) { > void *vto = kmap_coherent(page, vaddr) + (vaddr & ~PAGE_MASK); > memcpy(vto, src, len); > kunmap_coherent(); > @@ -253,7 +255,8 @@ void copy_from_user_page(struct vm_area_struct *vma, > struct page *page, unsigned long vaddr, void *dst, const void *src, > unsigned long len) > { > - if (cpu_has_dc_aliases && page_mapped(page)) { > + if (cpu_has_dc_aliases && > + page_mapped(page) && !Page_dcache_dirty(page)) { > void *vfrom = kmap_coherent(page, vaddr) + (vaddr & ~PAGE_MASK); > memcpy(dst, vfrom, len); > kunmap_coherent(); > > From giuseppe@eppesuigoccas.homedns.org Wed Dec 12 17:28:01 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 12 Dec 2007 17:28:11 +0000 (GMT) Received: from host188-210-dynamic.20-79-r.retail.telecomitalia.it ([79.20.210.188]:40683 "EHLO eppesuigoccas.homedns.org") by ftp.linux-mips.org with ESMTP id S20034556AbXLLR2B (ORCPT ); Wed, 12 Dec 2007 17:28:01 +0000 Received: from 89-96-243-184.ip14.fastwebnet.it ([89.96.243.184] helo=[192.168.215.30]) by eppesuigoccas.homedns.org with esmtpsa (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from ) id 1J2VK2-0006eo-CP; Wed, 12 Dec 2007 18:24:40 +0100 Subject: Re: 2.6.24-rc2 crash in kmap_coherent From: Giuseppe Sacco To: Ralf Baechle Cc: Florian Lohoff , linux-mips@linux-mips.org, David Daney In-Reply-To: <1197479471.25499.48.camel@scarafaggio> References: <20071211221327.GB2150@paradigm.rfc822.org> <20071212120610.GB28868@linux-mips.org> <20071212153218.GA30291@linux-mips.org> <1197479471.25499.48.camel@scarafaggio> Content-Type: text/plain Date: Wed, 12 Dec 2007 18:25:32 +0100 Message-Id: <1197480332.25499.50.camel@scarafaggio> Mime-Version: 1.0 X-Mailer: Evolution 2.10.3 Content-Transfer-Encoding: 7bit Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 17793 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: giuseppe@eppesuigoccas.homedns.org Precedence: bulk X-list: linux-mips Il giorno mer, 12/12/2007 alle 18.11 +0100, Giuseppe Sacco ha scritto: > Hi Ralf, > the change you proposed here give an error since "page" is onlt > available on function copy_user_highpage() while there is not such > variable (nor parameter) in function copy_to_user_page(). [...] Sorry, I meant the variable "from", not "page". From CFRIESEN@nortel.com Wed Dec 12 17:51:58 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 12 Dec 2007 17:52:06 +0000 (GMT) Received: from zrtps0kp.nortel.com ([47.140.192.56]:57269 "EHLO zrtps0kp.nortel.com") by ftp.linux-mips.org with ESMTP id S20034613AbXLLRv6 (ORCPT ); Wed, 12 Dec 2007 17:51:58 +0000 Received: from zcarhxs1.corp.nortel.com (zcarhxs1.corp.nortel.com [47.129.230.89]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id lBCHiKf28874; Wed, 12 Dec 2007 17:44:20 GMT Received: from [47.9.29.61] ([47.9.29.61] RDNS failed) by zcarhxs1.corp.nortel.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 12 Dec 2007 12:44:18 -0500 Message-ID: <47601DEE.4090200@nortel.com> Date: Wed, 12 Dec 2007 11:44:14 -0600 From: "Chris Friesen" User-Agent: Mozilla Thunderbird 1.0.2-6 (X11/20050513) X-Accept-Language: en-us, en MIME-Version: 1.0 To: linux-mips@linux-mips.org, ralf@linux-mips.org Subject: questions on struct sigcontext Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 12 Dec 2007 17:44:18.0301 (UTC) FILETIME=[9EB732D0:01C83CE6] Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 17794 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: cfriesen@nortel.com Precedence: bulk X-list: linux-mips Hi all, First, I'm not subscribed to the list so I'd appreciate being cc'd on any replies. We have a project getting started with MIPS, and one of the things that we're trying to bring in is some exception-handling code that logs various information about the ways that apps fail. In particular, the guys working on this have asked for the STATUS, CAUSE, BADVADDR, and FPC_EIR registers to be made available as part of struct sigcontext so that they can determine exactly why the app is failing. Looking at include/asm-mips/sigcontext.h I can see that these registers appear to be in the struct, but are either marked as "unused" or now have different names. Am I correct that these registers are not currently exported to userspace on a fault? If this is the case, why not? Does anyone have a patch to enable this export? It seems odd that mips app designers wouldn't want this information to be made available. Any information you can provide would be useful. Chris From rsandifo@nildram.co.uk Wed Dec 12 18:09:37 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 12 Dec 2007 18:09:46 +0000 (GMT) Received: from smtp.nildram.co.uk ([195.149.33.74]:38275 "EHLO smtp.nildram.co.uk") by ftp.linux-mips.org with ESMTP id S20034738AbXLLSJh (ORCPT ); Wed, 12 Dec 2007 18:09:37 +0000 Received: from firetop.home (85-211-134-127.dyn.gotadsl.co.uk [85.211.134.127]) by smtp.nildram.co.uk (Postfix) with ESMTP id 593762DFFD5; Wed, 12 Dec 2007 18:09:29 +0000 (GMT) Received: from richard by firetop.home with local (Exim 4.63) (envelope-from ) id 1J2W1T-0001wj-Ls; Wed, 12 Dec 2007 18:09:31 +0000 From: Richard Sandiford To: peter fuerst Mail-Followup-To: peter fuerst ,Ralf Baechle , Thomas Bogendoerfer , Kumba , linux-mips@linux-mips.org, rsandifo@nildram.co.uk Cc: Ralf Baechle , Thomas Bogendoerfer , Kumba , linux-mips@linux-mips.org Subject: Re: [UPDATED PATCH] IP28 support References: Date: Wed, 12 Dec 2007 18:09:31 +0000 In-Reply-To: (peter fuerst's message of "Wed\, 12 Dec 2007 16\:26\:31 +0100 \(CET\)") Message-ID: <87hcinlr8k.fsf@firetop.home> User-Agent: Gnus/5.110006 (No Gnus v0.6) Emacs/21.4 (gnu/linux) 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: 17795 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: rsandifo@nildram.co.uk Precedence: bulk X-list: linux-mips peter fuerst writes: >> Ralf Baechle writes: >> >> Then there's the language-lawyerly code I gave to Peter on gcc-patches@: >> >> >> >> void foo (int x) >> >> { >> >> int array[1]; >> >> if (x) >> >> bar (array[0x1fff]); >> >> } >> >> > > A strange method to pass data... Of course, cooking up such an "ABI", > where local variables are accessed with a const offset that is not known at > compile-time to be valid, would subvert the test for $sp-based accesses... Well, as I said when I gave that example originally, it's unlikely that the example would be written in that form. But hide the constants and checks in configurable macros, and the general idea becomes a little more feasible. >> FWIW, my first cut at the option restrictions were based on what >> the patch exempts (and doesn't exempt). We could instead get gcc >> to only exempt accesses that it can prove are either to the current >> function's stack frame or to its stack arguments. I.e. rather than >> consider every $sp-based access to be safe, we'd instead do some > > "every $sp-based access" (set(mem(plus(sp)(const_int)))) is restricted > to local variables too, with the constant offset being either > - compiler-generated or > - deliberately put in the source (however including the above example) That's not literally true. SP+INT addresses can be used to access stack arguments too, and 4.x can optimise some varargs accesses to compile-time base+offset addresses. And as I said, the compiler is free to make up accesses that aren't in fact valid for cases where the access isn't made. E.g. if you had a loop with a stride of 128, the compiler could unroll the loop as many times as it likes. Some of the unrolled iterations might access areas outside the stack frame. (You would hope that the compiler would be intelligent enough to crop the iteration count in such cases, because the extra iterations should never be used in valid code. But that isn't the point. The compiler doesn't _need_ to crop the iteration count for correctness, and we're talking about something we _do_ need for correctness.) >> bounds checking on the value. > Fine, if that is possible. FWIW, the frame info is available in cfun->machine->frame at the time your code runs. >> (We could also use MEM_ATTRS to >> pick up cases where a stack variable is acceesed via something >> other than the stack or frame pointers, as happens for large frames.) > > Aren't these always accesses with non-constant offset, where a CB can't be > avoided, even if they are recognized as being actually relative to $sp ? The MEM_ATTRS I meant were MEM_EXPR + MEM_OFFSET, which only apply where there is a known constant offset. >> > In case of a hypothetic multi-platform kernel of which at least one needs >> > the R10000 workarounds, all code would be uniformly compiled with the >> > magic -mr10k-cache-barrier option and all source level workaround would >> > be enabled. >> >> Hmm. This probably shows I am misunderstanding the problem, but I was >> thinking about the IO-mapped case. I thought one of the problems was >> that if you had a cached speculative load or store to an access-sensitive >> IO-mapped address, the IO-mapped device might "see" that access even if it >> doesn't take place. Could you not have a situation where a KSEG0 or >> XKSEG0 access is access-sensitive on one machine and not another? >> The patch won't insert countermeasures before symbolic and constant >> addresses, because it believes all such addresses to be safe. >> > > The threat to IO-addresses comes from the addressing register in the speculated > mem-instruction (set(mem(plus(reg)...), containing one of the addresses as > "garbage". > > Symbolic addresses are well defined from link-time on, no matter what history > before the access. They either point (set(mem(plus(symbol_ref)...) to > - some variable in the cached area, what is harmless (unless DMA-related), > or to > - IO-devices, accessed uncached, i.e. non-speculative, > unless there is a programming-error ;) > The same holds for const_int used as address. I think you're missing my point. If you access an I/O-mapped device through KSEG2 or an uncached XKPHYS address, is it not also physically possible (though clearly unwise) to access it through KSEG0 or a cached XKPHYS address too? So can you guarantee that every const_int cached address in a multi-platform kernel is not I/O-mapped on any of the r10k platforms? Or can you guarantee that the compiler will not manufacture such an address from an otherwise harmless address? Again, the key thing is to think about what the compiler can validly do on non-r10k platforms, however silly it might seem, and then make sure the workarounds cope with it. >> I'm also a little worried that the compiler is free to make up accesses >> that didn't exist in the original program, provided that those accesses > The cache-barrier itself ? No, in general. Optimisers (particularly loop optimisers) can invent accesses that didn't exist in the original source code. Normally they would only be executed in correct circumstances, but with this speculative execution, that might not be true. >> are never actually performed in cases where they'd be wrong. So how about: >> >> -mr10k-cache-barrier=load-store >> Insert a cache barrier at the beginning of any sequentially-executed >> series of instructions that contains a load or store. For the purposes >> of this option, GCC can ignore loads and stores that it can prove >> are an in-range access to: >> >> (a) the current function's stack frame; >> (b) an incoming stack argument; >> (b) an object with a link-time-constant address; or >> (c) a block of uncached memory > Can we recognize uncached memory in the instruction ? Well, I was just thinking about teaching the compiler about KSEG2, the always-uncached XKPHYS addresses, etc. (Sorry for messing up the bullet letters there!) The idea is that we have a correlation between symbolic constants and C objects, so we can check whether an offset in a symbolic constant is within the object. We already have code to do this in other situations. But there is no correlation between const_int addresses and C objects, and we cannot be sure that a given const_int address existed in the original source code, so I think the only safe thing is to check its uncached properties instead. I know all this must be frustrating. I'm sure your patches work great as they are with current and past kernels, and current and past compilers. The problem is that, if it becomes a mainline gcc feature, it needs to be defined from first principles. And we need to do that without assuming that the accesses we're looking at existed in the original source code. FWIW, I'm happy to help update the patch once we've agreed on an option spec. Richard From ddaney@avtrex.com Wed Dec 12 18:12:18 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 12 Dec 2007 18:12:26 +0000 (GMT) Received: from smtp1.dnsmadeeasy.com ([205.234.170.144]:18410 "EHLO smtp1.dnsmadeeasy.com") by ftp.linux-mips.org with ESMTP id S20034738AbXLLSMS (ORCPT ); Wed, 12 Dec 2007 18:12:18 +0000 Received: from smtp1.dnsmadeeasy.com (localhost [127.0.0.1]) by smtp1.dnsmadeeasy.com (Postfix) with ESMTP id 0690E3112A0; Wed, 12 Dec 2007 18:12:18 +0000 (UTC) X-Authenticated-Name: js.dnsmadeeasy X-Transit-System: In case of SPAM please contact abuse@dnsmadeeasy.com Received: from avtrex.com (unknown [67.116.42.147]) by smtp1.dnsmadeeasy.com (Postfix) with ESMTP; Wed, 12 Dec 2007 18:12:17 +0000 (UTC) Received: from [192.168.7.26] ([192.168.7.26]) by avtrex.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 12 Dec 2007 10:12:02 -0800 Message-ID: <47602471.9080706@avtrex.com> Date: Wed, 12 Dec 2007 10:12:01 -0800 From: David Daney User-Agent: Thunderbird 1.5.0.12 (X11/20071019) MIME-Version: 1.0 To: Chris Friesen Cc: linux-mips@linux-mips.org Subject: Re: questions on struct sigcontext References: <47601DEE.4090200@nortel.com> In-Reply-To: <47601DEE.4090200@nortel.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 12 Dec 2007 18:12:02.0396 (UTC) FILETIME=[7E97F1C0:01C83CEA] Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 17796 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: ddaney@avtrex.com Precedence: bulk X-list: linux-mips Chris Friesen wrote: > > Hi all, > > First, I'm not subscribed to the list so I'd appreciate being cc'd on > any replies. > > We have a project getting started with MIPS, and one of the things that > we're trying to bring in is some exception-handling code that logs > various information about the ways that apps fail. > > In particular, the guys working on this have asked for the STATUS, > CAUSE, BADVADDR, and FPC_EIR registers to be made available as part of > struct sigcontext so that they can determine exactly why the app is > failing. > > Looking at include/asm-mips/sigcontext.h I can see that these registers > appear to be in the struct, but are either marked as "unused" or now > have different names. > > Am I correct that these registers are not currently exported to > userspace on a fault? No. Most of the information is available. The si_addr and si_code of the sigcontext are populated as well as the ucontext at the fault. Given all this and the code at $pc when the fault occurred, it is a simple matter to determine what happened. I have seen some kernels patched so that an OOPS type dump was created in the trap handler, but this doesn't really add anything to the information that is already available in user space. David Daney From rsandifo@nildram.co.uk Wed Dec 12 18:22:25 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 12 Dec 2007 18:22:34 +0000 (GMT) Received: from smtp.nildram.co.uk ([195.112.4.54]:35334 "EHLO smtp.nildram.co.uk") by ftp.linux-mips.org with ESMTP id S20034756AbXLLSWZ (ORCPT ); Wed, 12 Dec 2007 18:22:25 +0000 Received: from firetop.home (85-211-134-127.dyn.gotadsl.co.uk [85.211.134.127]) by smtp.nildram.co.uk (Postfix) with ESMTP id 760A52B7BE8; Wed, 12 Dec 2007 18:22:22 +0000 (GMT) Received: from richard by firetop.home with local (Exim 4.63) (envelope-from ) id 1J2WDx-00021s-79; Wed, 12 Dec 2007 18:22:25 +0000 From: Richard Sandiford To: peter fuerst Mail-Followup-To: peter fuerst ,Ralf Baechle , Thomas Bogendoerfer , Kumba , linux-mips@linux-mips.org, rsandifo@nildram.co.uk Cc: Ralf Baechle , Thomas Bogendoerfer , Kumba , linux-mips@linux-mips.org Subject: Re: [UPDATED PATCH] IP28 support References: <87hcinlr8k.fsf@firetop.home> Date: Wed, 12 Dec 2007 18:22:25 +0000 In-Reply-To: <87hcinlr8k.fsf@firetop.home> (Richard Sandiford's message of "Wed\, 12 Dec 2007 18\:09\:31 +0000") Message-ID: <878x3zlqn2.fsf@firetop.home> User-Agent: Gnus/5.110006 (No Gnus v0.6) Emacs/21.4 (gnu/linux) 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: 17797 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: rsandifo@nildram.co.uk Precedence: bulk X-list: linux-mips Richard Sandiford writes: > through KSEG2 or an uncached XKPHYS address, is it not also physically er, I meant KSEG1 of course. Same mistake later. Richard From CFRIESEN@nortel.com Wed Dec 12 18:42:11 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 12 Dec 2007 18:42:19 +0000 (GMT) Received: from zrtps0kn.nortel.com ([47.140.192.55]:51342 "EHLO zrtps0kn.nortel.com") by ftp.linux-mips.org with ESMTP id S20034876AbXLLSmL (ORCPT ); Wed, 12 Dec 2007 18:42:11 +0000 Received: from zcarhxs1.corp.nortel.com (zcarhxs1.corp.nortel.com [47.129.230.89]) by zrtps0kn.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id lBCIYXA28791; Wed, 12 Dec 2007 18:34:33 GMT Received: from [47.9.29.61] ([47.9.29.61] RDNS failed) by zcarhxs1.corp.nortel.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 12 Dec 2007 13:34:22 -0500 Message-ID: <476029AB.80702@nortel.com> Date: Wed, 12 Dec 2007 12:34:19 -0600 From: "Chris Friesen" User-Agent: Mozilla Thunderbird 1.0.2-6 (X11/20050513) X-Accept-Language: en-us, en MIME-Version: 1.0 To: David Daney CC: linux-mips@linux-mips.org Subject: Re: questions on struct sigcontext References: <47601DEE.4090200@nortel.com> <47602471.9080706@avtrex.com> In-Reply-To: <47602471.9080706@avtrex.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 12 Dec 2007 18:34:22.0171 (UTC) FILETIME=[9D2962B0:01C83CED] Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 17798 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: cfriesen@nortel.com Precedence: bulk X-list: linux-mips David Daney wrote: > Most of the information is available. The si_addr and si_code of the > sigcontext are populated as well as the ucontext at the fault. I assume this should be siginfo rather than sigcontext? > Given all this and the code at $pc when the fault occurred, it is a > simple matter to determine what happened. Okay. I'll pass that information on and see if it's sufficient. Thanks, Chris From ddaney@avtrex.com Wed Dec 12 18:45:00 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 12 Dec 2007 18:45:08 +0000 (GMT) Received: from smtp1.dnsmadeeasy.com ([205.234.170.144]:9651 "EHLO smtp1.dnsmadeeasy.com") by ftp.linux-mips.org with ESMTP id S20034942AbXLLSpA (ORCPT ); Wed, 12 Dec 2007 18:45:00 +0000 Received: from smtp1.dnsmadeeasy.com (localhost [127.0.0.1]) by smtp1.dnsmadeeasy.com (Postfix) with ESMTP id 6D2B6310FA8; Wed, 12 Dec 2007 18:44:29 +0000 (UTC) X-Authenticated-Name: js.dnsmadeeasy X-Transit-System: In case of SPAM please contact abuse@dnsmadeeasy.com Received: from avtrex.com (unknown [67.116.42.147]) by smtp1.dnsmadeeasy.com (Postfix) with ESMTP; Wed, 12 Dec 2007 18:44:29 +0000 (UTC) Received: from [192.168.7.26] ([192.168.7.26]) by avtrex.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 12 Dec 2007 10:44:14 -0800 Message-ID: <47602BFE.4050606@avtrex.com> Date: Wed, 12 Dec 2007 10:44:14 -0800 From: David Daney User-Agent: Thunderbird 1.5.0.12 (X11/20071019) MIME-Version: 1.0 To: Chris Friesen Cc: linux-mips@linux-mips.org Subject: Re: questions on struct sigcontext References: <47601DEE.4090200@nortel.com> <47602471.9080706@avtrex.com> <476029AB.80702@nortel.com> In-Reply-To: <476029AB.80702@nortel.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 12 Dec 2007 18:44:14.0594 (UTC) FILETIME=[FE45F620:01C83CEE] Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 17799 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: ddaney@avtrex.com Precedence: bulk X-list: linux-mips Chris Friesen wrote: > David Daney wrote: > >> Most of the information is available. The si_addr and si_code of the >> sigcontext are populated as well as the ucontext at the fault. > > I assume this should be siginfo rather than sigcontext? Yes. In the three parameter form of the signal handler the second and third parameters are pointers to the siginfo and ucontext. > >> Given all this and the code at $pc when the fault occurred, it is a >> simple matter to determine what happened. > > Okay. I'll pass that information on and see if it's sufficient. > > Thanks, > > Chris From ralf@linux-mips.org Wed Dec 12 18:58:10 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 12 Dec 2007 18:58:12 +0000 (GMT) Received: from localhost.localdomain ([127.0.0.1]:8895 "EHLO dl5rb.ham-radio-op.net") by ftp.linux-mips.org with ESMTP id S20034920AbXLLS6K (ORCPT ); Wed, 12 Dec 2007 18:58:10 +0000 Received: from denk.linux-mips.net (denk.linux-mips.net [127.0.0.1]) by dl5rb.ham-radio-op.net (8.14.1/8.13.8) with ESMTP id lBCIvRTA026507; Wed, 12 Dec 2007 18:57:27 GMT Received: (from ralf@localhost) by denk.linux-mips.net (8.14.1/8.14.1/Submit) id lBCIvQmX026506; Wed, 12 Dec 2007 18:57:26 GMT Date: Wed, 12 Dec 2007 18:57:26 +0000 From: Ralf Baechle To: Chris Friesen Cc: linux-mips@linux-mips.org Subject: Re: questions on struct sigcontext Message-ID: <20071212185726.GA26190@linux-mips.org> References: <47601DEE.4090200@nortel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <47601DEE.4090200@nortel.com> User-Agent: Mutt/1.5.17 (2007-11-01) Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 17800 X-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 12, 2007 at 11:44:14AM -0600, Chris Friesen wrote: > First, I'm not subscribed to the list so I'd appreciate being cc'd on any > replies. > > We have a project getting started with MIPS, and one of the things that > we're trying to bring in is some exception-handling code that logs various > information about the ways that apps fail. > > In particular, the guys working on this have asked for the STATUS, CAUSE, > BADVADDR, and FPC_EIR registers to be made available as part of struct > sigcontext so that they can determine exactly why the app is failing. The status register doesn't provide useful information about application problems since it almost exclusivly affects kernel level operation. So its not exported to userspace. Cause I agree could occasionally be interesting. Historically the Linux/MIPS stackframe is derived from the IRIX stackframe. But Linux/MIPS did never populate the sc_cause field - no debugger or anything was using it. So eventually the field got recycled for the DSP ASE. The hard part here is finding place in the stackframe without breaking compatibility - and there are other users competing ... C0_badvaddr is available in the si_addr field of struct siginfo. The FIR register is the "FP Implementation and Revision register" which is read-only so the same for all processes. A debugger can access it at any time and there is no need to waste space in the stack frame on it. > Looking at include/asm-mips/sigcontext.h I can see that these registers > appear to be in the struct, but are either marked as "unused" or now have > different names. > > Am I correct that these registers are not currently exported to userspace > on a fault? If this is the case, why not? Does anyone have a patch to > enable this export? Be very, very, very careful if you're changing struct siginfo. Applications know about it. Iow if you change it the wrong way you break binary or even source compatibility and usually that's in very subtle ways. (Honestly, I hate our stackframe, especially the 32-bit one which is hell of overbloated. I *wish* I could just scrap it but its one of those holy cows - and I don't feel carnivorous enough yet to butcher it ;-) Ralf From drow@false.org Wed Dec 12 19:01:05 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 12 Dec 2007 19:01:13 +0000 (GMT) Received: from NaN.false.org ([208.75.86.248]:35204 "EHLO nan.false.org") by ftp.linux-mips.org with ESMTP id S20035012AbXLLTBF (ORCPT ); Wed, 12 Dec 2007 19:01:05 +0000 Received: from nan.false.org (localhost [127.0.0.1]) by nan.false.org (Postfix) with ESMTP id 5D65998021; Wed, 12 Dec 2007 19:00:33 +0000 (GMT) Received: from caradoc.them.org (22.svnf5.xdsl.nauticom.net [209.195.183.55]) by nan.false.org (Postfix) with ESMTP id 4609198020; Wed, 12 Dec 2007 19:00:33 +0000 (GMT) Received: from drow by caradoc.them.org with local (Exim 4.68) (envelope-from ) id 1J2Woq-00085Z-5E; Wed, 12 Dec 2007 14:00:32 -0500 Date: Wed, 12 Dec 2007 14:00:32 -0500 From: Daniel Jacobowitz To: Chris Friesen Cc: linux-mips@linux-mips.org, ralf@linux-mips.org Subject: Re: questions on struct sigcontext Message-ID: <20071212190032.GA30506@caradoc.them.org> References: <47601DEE.4090200@nortel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <47601DEE.4090200@nortel.com> User-Agent: Mutt/1.5.17 (2007-12-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: 17801 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: dan@debian.org Precedence: bulk X-list: linux-mips On Wed, Dec 12, 2007 at 11:44:14AM -0600, Chris Friesen wrote: > > Hi all, > > First, I'm not subscribed to the list so I'd appreciate being cc'd on any > replies. > > We have a project getting started with MIPS, and one of the things that > we're trying to bring in is some exception-handling code that logs > various information about the ways that apps fail. > > In particular, the guys working on this have asked for the STATUS, CAUSE, > BADVADDR, and FPC_EIR registers to be made available as part of struct > sigcontext so that they can determine exactly why the app is failing. > > Looking at include/asm-mips/sigcontext.h I can see that these registers > appear to be in the struct, but are either marked as "unused" or now have > different names. > > Am I correct that these registers are not currently exported to userspace > on a fault? If this is the case, why not? Does anyone have a patch to > enable this export? There used to be slots for badvaddr and cause. You'll have to ask Ralf why he decided to clobber them for DSP state, I don't remember :-) I suspect they may never have held useful information for you; we don't context switch them for userspace, so an intervening fault in kernel space or in another thread could change them. FPC_EIR is, unless I misremember, constant and read only. You can just read it. -- Daniel Jacobowitz CodeSourcery From ralf@linux-mips.org Wed Dec 12 19:05:46 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 12 Dec 2007 19:05:48 +0000 (GMT) Received: from localhost.localdomain ([127.0.0.1]:50591 "EHLO dl5rb.ham-radio-op.net") by ftp.linux-mips.org with ESMTP id S20033600AbXLLTFq (ORCPT ); Wed, 12 Dec 2007 19:05:46 +0000 Received: from denk.linux-mips.net (denk.linux-mips.net [127.0.0.1]) by dl5rb.ham-radio-op.net (8.14.1/8.13.8) with ESMTP id lBCJ4ubF026639; Wed, 12 Dec 2007 19:04:57 GMT Received: (from ralf@localhost) by denk.linux-mips.net (8.14.1/8.14.1/Submit) id lBCJ4tpd026638; Wed, 12 Dec 2007 19:04:55 GMT Date: Wed, 12 Dec 2007 19:04:55 +0000 From: Ralf Baechle To: Daniel Jacobowitz Cc: Chris Friesen , linux-mips@linux-mips.org Subject: Re: questions on struct sigcontext Message-ID: <20071212190455.GB26190@linux-mips.org> References: <47601DEE.4090200@nortel.com> <20071212190032.GA30506@caradoc.them.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20071212190032.GA30506@caradoc.them.org> User-Agent: Mutt/1.5.17 (2007-11-01) Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 17802 X-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 12, 2007 at 02:00:32PM -0500, Daniel Jacobowitz wrote: > There used to be slots for badvaddr and cause. You'll have to ask > Ralf why he decided to clobber them for DSP state, I don't remember > :-) I suspect they may never have held useful information for you; > we don't context switch them for userspace, so an intervening fault > in kernel space or in another thread could change them. Correct, we never filled badvaddr and cause, so it was easy to recycle those fields. Ralf From CFRIESEN@nortel.com Wed Dec 12 23:48:04 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 12 Dec 2007 23:48:13 +0000 (GMT) Received: from zcars04f.nortel.com ([47.129.242.57]:34274 "EHLO zcars04f.nortel.com") by ftp.linux-mips.org with ESMTP id S20035406AbXLLXsE (ORCPT ); Wed, 12 Dec 2007 23:48:04 +0000 Received: from zcarhxs1.corp.nortel.com (zcarhxs1.corp.nortel.com [47.129.230.89]) by zcars04f.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id lBCNluY21944; Wed, 12 Dec 2007 23:47:56 GMT Received: from [47.130.25.105] ([47.130.25.105] RDNS failed) by zcarhxs1.corp.nortel.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 12 Dec 2007 18:47:55 -0500 Message-ID: <47607327.5090709@nortel.com> Date: Wed, 12 Dec 2007 17:47:51 -0600 From: "Chris Friesen" User-Agent: Mozilla Thunderbird 1.0.2-6 (X11/20050513) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Daniel Jacobowitz CC: linux-mips@linux-mips.org, ralf@linux-mips.org Subject: Re: questions on struct sigcontext References: <47601DEE.4090200@nortel.com> <20071212190032.GA30506@caradoc.them.org> In-Reply-To: <20071212190032.GA30506@caradoc.them.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 12 Dec 2007 23:47:55.0847 (UTC) FILETIME=[6AFC8570:01C83D19] Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 17803 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: cfriesen@nortel.com Precedence: bulk X-list: linux-mips Daniel Jacobowitz wrote: > There used to be slots for badvaddr and cause. You'll have to ask > Ralf why he decided to clobber them for DSP state, I don't remember > :-) I suspect they may never have held useful information for you; > we don't context switch them for userspace, so an intervening fault > in kernel space or in another thread could change them. I'm a bit confused as to how they would never have held useful information--did you mean the registers themselves, or the entries in struct sigcontext? If the cause/badvaddr entries in struct sigcontext were filled in by the exception handler in the kernel, wouldn't the values in that struct be completely valid even if the registers themselves were changed before userspace could handle the signal? If this is not the case then it seems like si_addr/si_code wouldn't be trustworthy either. Chris From ddaney@avtrex.com Thu Dec 13 00:07:03 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 13 Dec 2007 00:07:11 +0000 (GMT) Received: from smtp1.dnsmadeeasy.com ([205.234.170.144]:5544 "EHLO smtp1.dnsmadeeasy.com") by ftp.linux-mips.org with ESMTP id S20035415AbXLMAHD (ORCPT ); Thu, 13 Dec 2007 00:07:03 +0000 Received: from smtp1.dnsmadeeasy.com (localhost [127.0.0.1]) by smtp1.dnsmadeeasy.com (Postfix) with ESMTP id CC6193111CE; Thu, 13 Dec 2007 00:06:37 +0000 (UTC) X-Authenticated-Name: js.dnsmadeeasy X-Transit-System: In case of SPAM please contact abuse@dnsmadeeasy.com Received: from avtrex.com (unknown [67.116.42.147]) by smtp1.dnsmadeeasy.com (Postfix) with ESMTP; Thu, 13 Dec 2007 00:06:37 +0000 (UTC) Received: from [192.168.7.26] ([192.168.7.26]) by avtrex.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 12 Dec 2007 16:06:14 -0800 Message-ID: <47607775.4020907@avtrex.com> Date: Wed, 12 Dec 2007 16:06:13 -0800 From: David Daney User-Agent: Thunderbird 1.5.0.12 (X11/20071019) MIME-Version: 1.0 To: Chris Friesen Cc: Daniel Jacobowitz , linux-mips@linux-mips.org, ralf@linux-mips.org Subject: Re: questions on struct sigcontext References: <47601DEE.4090200@nortel.com> <20071212190032.GA30506@caradoc.them.org> <47607327.5090709@nortel.com> In-Reply-To: <47607327.5090709@nortel.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 13 Dec 2007 00:06:14.0296 (UTC) FILETIME=[F9B68980:01C83D1B] Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 17804 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: ddaney@avtrex.com Precedence: bulk X-list: linux-mips Chris Friesen wrote: > Daniel Jacobowitz wrote: > >> There used to be slots for badvaddr and cause. You'll have to ask >> Ralf why he decided to clobber them for DSP state, I don't remember >> :-) I suspect they may never have held useful information for you; >> we don't context switch them for userspace, so an intervening fault >> in kernel space or in another thread could change them. > > I'm a bit confused as to how they would never have held useful > information--did you mean the registers themselves, or the entries in > struct sigcontext? The entries in the sigcontext. As Ralf said, they never held valid values. > > If the cause/badvaddr entries in struct sigcontext were filled in by the > exception handler in the kernel, It would appear that they are not. > wouldn't the values in that struct be > completely valid even if the registers themselves were changed before > userspace could handle the signal? > > If this is not the case then it seems like si_addr/si_code wouldn't be > trustworthy either. This I am not sure about :(, However knowing the values of all registers (and perhaps /proc/self/maps) and $pc you can easily derive what happened. David Daney From Nilanjan.Roychowdhury@gnss.com Thu Dec 13 03:37:53 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 13 Dec 2007 03:38:02 +0000 (GMT) Received: from mail.gnss.com ([209.47.22.10]:38916 "EHLO tormf01.gmi.domain") by ftp.linux-mips.org with ESMTP id S20035727AbXLMDhx (ORCPT ); Thu, 13 Dec 2007 03:37:53 +0000 Received: from tormf01.gmi.domain (127.0.0.1) by tormf01.gmi.domain (MlfMTA v3.2r9) id hc2kh20171s3 for ; Wed, 12 Dec 2007 22:37:22 -0500 (envelope-from ) Received: from INDEXCH2003.gmi.domain ([10.41.1.181]) by tormf01.gmi.domain (SonicWALL 6.0.1.9157) with ESMTP; Wed, 12 Dec 2007 22:37:22 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C83D39.7724DEF1" Subject: Inter processor synchronization Date: Thu, 13 Dec 2007 09:07:20 +0530 Message-ID: <9D98C51005D80D43A19A3DF329A61D690106A282@INDEXCH2003.gmi.domain> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Inter processor synchronization Thread-Index: Acg9OXc4eZ2or01CQpavhNXQtClAVQ== From: "Nilanjan Roychowdhury" To: X-Mlf-Version: 6.0.1.9157 X-Mlf-UniqueId: o200712130337200048605 Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 17805 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: Nilanjan.Roychowdhury@gnss.com Precedence: bulk X-list: linux-mips This is a multi-part message in MIME format. ------_=_NextPart_001_01C83D39.7724DEF1 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Hi, I have a scenario where two images of the same Linux kernel are running on two MIPS cores. One is 24K and another is 4KEC. What is the best way to achieve inter processor synchronization between them? I guess the locks for LL/SC are local to a particular core and can not be extended across a multi core system.=20 =20 Will it be easier for me if both of them becomes same core ( like both 24k) and I run the SMP version of Linux. Please throw some light. =20 Thanks, Nilanjan =20 =20 ------_=_NextPart_001_01C83D39.7724DEF1 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable

Hi,

I have a scenario where two images of the same Linux = kernel are running on two MIPS cores. One is 24K and another is 4KEC. What is = the best way to achieve inter processor synchronization between = them?

I guess the locks for LL/SC are local to a particular = core and can not be extended across a multi core system. =

 

Will it be easier for me if both of them becomes same = core ( like both 24k) and I run the SMP version of = Linux.

Please throw some light.

 

Thanks,

Nilanjan

 

 

------_=_NextPart_001_01C83D39.7724DEF1-- From ralf@linux-mips.org Thu Dec 13 12:58:49 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 13 Dec 2007 12:58:52 +0000 (GMT) Received: from localhost.localdomain ([127.0.0.1]:61149 "EHLO dl5rb.ham-radio-op.net") by ftp.linux-mips.org with ESMTP id S28575685AbXLMM6t (ORCPT ); Thu, 13 Dec 2007 12:58:49 +0000 Received: from denk.linux-mips.net (denk.linux-mips.net [127.0.0.1]) by dl5rb.ham-radio-op.net (8.14.1/8.13.8) with ESMTP id lBDCwm14001441; Thu, 13 Dec 2007 12:58:49 GMT Received: (from ralf@localhost) by denk.linux-mips.net (8.14.1/8.14.1/Submit) id lBDCwlx5001440; Thu, 13 Dec 2007 12:58:47 GMT Date: Thu, 13 Dec 2007 12:58:47 +0000 From: Ralf Baechle To: Nilanjan Roychowdhury Cc: linux-mips@linux-mips.org Subject: Re: Inter processor synchronization Message-ID: <20071213125847.GA1352@linux-mips.org> References: <9D98C51005D80D43A19A3DF329A61D690106A282@INDEXCH2003.gmi.domain> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <9D98C51005D80D43A19A3DF329A61D690106A282@INDEXCH2003.gmi.domain> User-Agent: Mutt/1.5.17 (2007-11-01) Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 17806 X-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 13, 2007 at 09:07:20AM +0530, Nilanjan Roychowdhury wrote: > I have a scenario where two images of the same Linux kernel are running > on two MIPS cores. One is 24K and another is 4KEC. What is the best way > to achieve inter processor synchronization between them? > > I guess the locks for LL/SC are local to a particular core and can not > be extended across a multi core system. 4K and 24K cores don't support cache coherency. So SMP is out of question. This is a _total_ showstopper for SMP, don't waste your time thinking on possible workarounds. The you could do is some sort of clusting, running two OS images, one on the 4K and one on the 24K which would communicate through a carefully cache managed or even uncached shared memory region. > Will it be easier for me if both of them becomes same core ( like both > 24k) and I run the SMP version of Linux. Within limits Linux supports mixing different CPU types such as R4000MC / R4400MC and R10000 / R12000 / R14000 mixes because those processors are similar enough Ralf From drow@false.org Thu Dec 13 19:45:27 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 13 Dec 2007 19:45:36 +0000 (GMT) Received: from NaN.false.org ([208.75.86.248]:48021 "EHLO nan.false.org") by ftp.linux-mips.org with ESMTP id S20033224AbXLMTp1 (ORCPT ); Thu, 13 Dec 2007 19:45:27 +0000 Received: from nan.false.org (localhost [127.0.0.1]) by nan.false.org (Postfix) with ESMTP id 9C33D98052; Thu, 13 Dec 2007 15:36:22 +0000 (GMT) Received: from caradoc.them.org (22.svnf5.xdsl.nauticom.net [209.195.183.55]) by nan.false.org (Postfix) with ESMTP id 7F3C998021; Thu, 13 Dec 2007 15:36:22 +0000 (GMT) Received: from drow by caradoc.them.org with local (Exim 4.68) (envelope-from ) id 1J2q6n-0008U8-Ls; Thu, 13 Dec 2007 10:36:21 -0500 Date: Thu, 13 Dec 2007 10:36:21 -0500 From: Daniel Jacobowitz To: Chris Friesen Cc: linux-mips@linux-mips.org, ralf@linux-mips.org Subject: Re: questions on struct sigcontext Message-ID: <20071213153621.GA32600@caradoc.them.org> References: <47601DEE.4090200@nortel.com> <20071212190032.GA30506@caradoc.them.org> <47607327.5090709@nortel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <47607327.5090709@nortel.com> User-Agent: Mutt/1.5.17 (2007-12-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: 17807 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: dan@debian.org Precedence: bulk X-list: linux-mips On Wed, Dec 12, 2007 at 05:47:51PM -0600, Chris Friesen wrote: > If the cause/badvaddr entries in struct sigcontext were filled in by the > exception handler in the kernel, wouldn't the values in that struct be > completely valid even if the registers themselves were changed before > userspace could handle the signal? Yeah, my reply didn't make much sense. Trust Ralf's instead. -- Daniel Jacobowitz CodeSourcery From Frank_Rowand@sonyusa.com Fri Dec 14 01:56:03 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 14 Dec 2007 01:56:13 +0000 (GMT) Received: from outbound-va3.frontbridge.com ([216.32.180.16]:52797 "EHLO outbound5-va3-R.bigfish.com") by ftp.linux-mips.org with ESMTP id S28576040AbXLNB4D (ORCPT ); Fri, 14 Dec 2007 01:56:03 +0000 Received: from outbound5-va3.bigfish.com (localhost.localdomain [127.0.0.1]) by outbound5-va3-R.bigfish.com (Postfix) with ESMTP id D7AB4B0C4F7; Fri, 14 Dec 2007 01:54:56 +0000 (UTC) Received: from mail140-va3-R.bigfish.com (si1-va3 [10.7.14.5]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by outbound5-va3.bigfish.com (Postfix) with ESMTP id D678F199006E; Fri, 14 Dec 2007 01:54:56 +0000 (UTC) Received: from mail140-va3 (localhost.localdomain [127.0.0.1]) by mail140-va3-R.bigfish.com (Postfix) with ESMTP id 88FEB19500B5; Fri, 14 Dec 2007 01:54:56 +0000 (UTC) X-BigFish: V X-MS-Exchange-Organization-Antispam-Report: OrigIP: 160.33.66.75;Service: EHS Received: by mail140-va3 (MessageSwitch) id 1197597296545852_2446; Fri, 14 Dec 2007 01:54:56 +0000 (UCT) Received: from mail8.fw-sd.sony.com (mail8.fw-sd.sony.com [160.33.66.75]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail140-va3.bigfish.com (Postfix) with ESMTP id 3209B7E8078; Fri, 14 Dec 2007 01:54:56 +0000 (UTC) Received: from mail3.sjc.in.sel.sony.com (mail3.sjc.in.sel.sony.com [43.134.1.211]) by mail8.fw-sd.sony.com (8.12.11/8.12.11) with ESMTP id lBE1stMI016051; Fri, 14 Dec 2007 01:54:55 GMT Received: from USSDIXIM02.am.sony.com (ussdixim02.am.sony.com [43.130.140.34]) by mail3.sjc.in.sel.sony.com (8.12.11/8.12.11) with ESMTP id lBE1ss4S029579; Fri, 14 Dec 2007 01:54:54 GMT Received: from ussdixms03.am.sony.com ([43.130.140.23]) by USSDIXIM02.am.sony.com with Microsoft SMTPSVC(5.0.2195.6713); Thu, 13 Dec 2007 17:54:54 -0800 Received: from [43.135.148.200] ([43.135.148.200]) by ussdixms03.am.sony.com with Microsoft SMTPSVC(5.0.2195.6713); Thu, 13 Dec 2007 17:54:53 -0800 Subject: [PATCH][MIPS] kernel build fails if CONFIG_KGDB=y and CONFIG_SMP=n From: Frank Rowand Reply-To: frank.rowand@am.sony.com To: linux-mips@linux-mips.org Content-Type: text/plain Date: Thu, 13 Dec 2007 17:57:57 -0500 Message-Id: <1197586677.4660.4.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.12.1 (2.12.1-3.fc8) Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 14 Dec 2007 01:54:53.0994 (UTC) FILETIME=[522B40A0:01C83DF4] Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 17808 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: frank.rowand@am.sony.com Precedence: bulk X-list: linux-mips The kernel build fails if CONFIG_KGDB=y and CONFIG_SMP=n. kgdb_wait() is defined but unused, resulting in a warning. The warning is converted to an error by the "EXTRA_CFLAGS += -Werror" in arch/mips/kernel/Makefile. Signed-off-by: Frank Rowand --- arch/mips/kernel/gdb-stub.c | 2 2 + 0 - 0 ! 1 files changed, 2 insertions(+) Index: linux-2.6.24-rc4/arch/mips/kernel/gdb-stub.c =================================================================== --- linux-2.6.24-rc4.orig/arch/mips/kernel/gdb-stub.c +++ linux-2.6.24-rc4/arch/mips/kernel/gdb-stub.c @@ -656,6 +656,7 @@ void set_async_breakpoint(unsigned long *epc = (unsigned long)async_breakpoint; } +#ifdef CONFIG_SMP static void kgdb_wait(void *arg) { unsigned flags; @@ -668,6 +669,7 @@ static void kgdb_wait(void *arg) local_irq_restore(flags); } +#endif /* * GDB stub needs to call kgdb_wait on all processor with interrupts From kaz@zeugmasystems.com Fri Dec 14 03:05:52 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 14 Dec 2007 03:06:00 +0000 (GMT) Received: from mail.zeugmasystems.com ([70.79.96.174]:59435 "EHLO zeugmasystems.com") by ftp.linux-mips.org with ESMTP id S28576108AbXLNDFw (ORCPT ); Fri, 14 Dec 2007 03:05:52 +0000 Received: from rocktron ([10.18.28.237]) by zeugmasystems.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 13 Dec 2007 19:05:23 -0800 Message-ID: <559073B2DA784D4BABF7618D6D8CA89C@rocktron> From: "Kaz Kylheku" To: References: In-Reply-To: Subject: GCC bug affecting MIPS (was Re: SiByte 1480 & Branch Likely instructions?) Date: Thu, 13 Dec 2007 19:05:20 -0800 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 Windows Mail 6.0.6000.16480 X-MimeOLE: Produced By Microsoft MimeOLE V6.0.6000.16545 X-OriginalArrivalTime: 14 Dec 2007 03:05:23.0768 (UTC) FILETIME=[2B4F8B80:01C83DFE] Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 17809 X-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 "Kaz Kylheku" wrote on December 07, 2007: > Kaz wrote: >> Hi All, >> >> Not really a kernel-related question. I've discovered that GCC 4.1.1 >> (which I'm not using for kernel compiling, but user space) generates >> branch likely instructions by default, even though the documentation >> says that their use is off by default for MIPS32 and MIPS64, because > > That's because the compiler is not configured correctly. The default CPU > string "from-abi" ends up being used, and so the target ISA is MIPS III. I managed to root-cause the original problem, and moments ago filed this bug report: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34456 GCC can screw up when doing branch delay slot filling, because in computing register liveness, it makes an incorrectly computed assumption about what registers are clobbered by a CALL_INSN. By unfortunate coincidence, it's possible for an instruction which restores the caller's GP to be wrongly moved into a non-annulled delay slot, wreaking havoc on the fall-through path where GP is in fact used. Jumps and data accesses are then attempted using what is possibly the wrong global offset table. From Nilanjan.Roychowdhury@gnss.com Fri Dec 14 04:21:41 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 14 Dec 2007 04:21:51 +0000 (GMT) Received: from mail.gnss.com ([209.47.22.10]:10256 "EHLO tormf01.gmi.domain") by ftp.linux-mips.org with ESMTP id S20021610AbXLNEVl convert rfc822-to-8bit (ORCPT ); Fri, 14 Dec 2007 04:21:41 +0000 Received: from tormf01.gmi.domain (127.0.0.1) by tormf01.gmi.domain (MlfMTA v3.2r9) id hc82da0171sb; Thu, 13 Dec 2007 23:21:27 -0500 (envelope-from ) Received: from INDEXCH2003.gmi.domain ([10.41.1.181]) by tormf01.gmi.domain (SonicWALL 6.0.1.9157) with ESMTP; Thu, 13 Dec 2007 23:21:26 -0500 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: Inter processor synchronization Date: Fri, 14 Dec 2007 09:51:23 +0530 Message-ID: <9D98C51005D80D43A19A3DF329A61D690106A297@INDEXCH2003.gmi.domain> In-Reply-To: <20071213125847.GA1352@linux-mips.org> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Inter processor synchronization Thread-Index: Acg9h+v6X6nQlzAoSFKIiGz9oKlz7AAgHufA References: <9D98C51005D80D43A19A3DF329A61D690106A282@INDEXCH2003.gmi.domain> <20071213125847.GA1352@linux-mips.org> From: "Nilanjan Roychowdhury" To: "Ralf Baechle" Cc: X-Mlf-Version: 6.0.1.9157 X-Mlf-UniqueId: o200712140421240079106 Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 17810 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: Nilanjan.Roychowdhury@gnss.com Precedence: bulk X-list: linux-mips on Thursday, December 13, 2007 6:29 PM:, Ralf Baechle wrote: > On Thu, Dec 13, 2007 at 09:07:20AM +0530, Nilanjan Roychowdhury wrote: > >> I have a scenario where two images of the same Linux kernel are >> running on two MIPS cores. One is 24K and another is 4KEC. What is >> the best way to achieve inter processor synchronization between them? >> >> I guess the locks for LL/SC are local to a particular core and can >> not be extended across a multi core system. > 4K and 24K cores don't support cache coherency. So SMP is out of > question. > This is a _total_ showstopper for SMP, don't waste your time thinking > on possible workarounds. > > The you could do is some sort of clusting, running two OS images, one > on the 4K and one on the 24K which would communicate through a > carefully cache managed or even uncached shared memory region. I guess I am left with only this option. Can you please throw some more lights On the IPC you are mentioning? >> Will it be easier for me if both of them becomes same core ( like >> both 24k) and I run the SMP version of Linux. > > > Within limits Linux supports mixing different CPU types such as > R4000MC / R4400MC and R10000 / R12000 / R14000 mixes because those > processors are similar enough > > Ralf Thanks, Nilanjan From kevink@mips.com Fri Dec 14 09:34:32 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 14 Dec 2007 09:34:41 +0000 (GMT) Received: from dns0.mips.com ([63.167.95.198]:46579 "EHLO dns0.mips.com") by ftp.linux-mips.org with ESMTP id S20023038AbXLNJec (ORCPT ); Fri, 14 Dec 2007 09:34:32 +0000 Received: from mercury.mips.com (mercury [192.168.64.101]) by dns0.mips.com (8.12.11/8.12.11) with ESMTP id lBE9QLMf005921; Fri, 14 Dec 2007 01:26:21 -0800 (PST) Received: from grendel (grendel [192.168.236.16]) by mercury.mips.com (8.13.5/8.13.5) with SMTP id lBE9QqPJ003446; Fri, 14 Dec 2007 01:26:53 -0800 (PST) Message-ID: <00c801c83e33$75572a00$10eca8c0@grendel> From: "Kevin D. Kissell" To: "Nilanjan Roychowdhury" , "Ralf Baechle" Cc: References: <9D98C51005D80D43A19A3DF329A61D690106A282@INDEXCH2003.gmi.domain> <20071213125847.GA1352@linux-mips.org> <9D98C51005D80D43A19A3DF329A61D690106A297@INDEXCH2003.gmi.domain> Subject: Re: Inter processor synchronization Date: Fri, 14 Dec 2007 10:26:49 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1914 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1914 Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 17811 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: kevink@mips.com Precedence: bulk X-list: linux-mips > >> I have a scenario where two images of the same Linux kernel are > >> running on two MIPS cores. One is 24K and another is 4KEC. What is > >> the best way to achieve inter processor synchronization between them? > >> > >> I guess the locks for LL/SC are local to a particular core and can > >> not be extended across a multi core system. Just to be clear, LL/SC are indeed local to a particular core *but*, in a cache coherent multiprocessor system, they provide multiprocessor synchronization - the fact that another core has referenced the coherent location will clear the link bit so that the SC will fail locally. > > 4K and 24K cores don't support cache coherency. So SMP is out of > > question. > > This is a _total_ showstopper for SMP, don't waste your time thinking > > on possible workarounds. > > > > The you could do is some sort of clusting, running two OS images, one > > on the 4K and one on the 24K which would communicate through a > > carefully cache managed or even uncached shared memory region. > > I guess I am left with only this option. Can you please throw some more > lights On the IPC you are mentioning? Unless one has special-purpose hardware that implements atomic operations (e.g. a hardware semaphore device), one must use algorithms that do not require atomic read-modify-write. Most classically, one uses mailboxes where each memory location has a single reader and a single writer. There are other, more general but less efficient algorithms (e.g. Decker's algorithm) out there as well. If one is doing this in cacheable memory, one needs to take care that (a) an explicit forced cache writeback operation is done to complete each update to the shared memory array, and (b) the "ownership" is at a granularity of a cache line, and not a memory word. If the memory is mapped uncached, and one has a message queue "next" pointer that is written by CPU A and a "last-read" pointer that is written by B, those two pointers can be in consecutive memory locations. But if the memory is cached, they must be in separate cache lines to avoid the writebacks of one CPU destroying the writebacks of another. Regards, Kevin K. From mikael.starvik@axis.com Fri Dec 14 09:49:57 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 14 Dec 2007 09:50:05 +0000 (GMT) Received: from miranda.se.axis.com ([193.13.178.8]:31121 "EHLO miranda.se.axis.com") by ftp.linux-mips.org with ESMTP id S20021618AbXLNJt5 convert rfc822-to-8bit (ORCPT ); Fri, 14 Dec 2007 09:49:57 +0000 Received: from exgate.se.axis.com (exgate.se.axis.com [10.0.5.55]) by miranda.se.axis.com (8.13.4/8.13.4/Debian-3sarge3) with SMTP id lBE9nfdo022182 for ; Fri, 14 Dec 2007 10:49:41 +0100 Received: from exmail1.se.axis.com ([10.0.5.70]) by exgate.se.axis.com with Microsoft SMTPSVC(5.0.2195.6713); Fri, 14 Dec 2007 10:49:40 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 8BIT Subject: GCC 3.4.5 and mftc0 Date: Fri, 14 Dec 2007 10:49:40 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: GCC 3.4.5 and mftc0 Thread-Index: Acg+NqUmOqkfWFBVTzaV/6B9jRu56Q== From: "Mikael Starvik" To: X-OriginalArrivalTime: 14 Dec 2007 09:49:40.0822 (UTC) FILETIME=[A5A43F60:01C83E36] Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 17812 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: mikael.starvik@axis.com Precedence: bulk X-list: linux-mips mftc0() is implemented as .word ... move %0, $1 With at least gcc 3.4.5 the move is implemented as an addu %0, $1, $0. But in the MIPS sumulator this fails and %0 gets the value 0xffffffff. Implementing this as a or %0, $1, $0 instead gives the expected result. Any suggestions where the problem is and what the correct solution is? After fixing this my next problem is that IPIs doesn't reach all TCs correctly (it seams like the code doesn't detect IXMT status correctly, but I am still investigating). It is likely that it is caused by something similar to the problem above. Regards /Mikael From ralf@linux-mips.org Fri Dec 14 12:53:42 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 14 Dec 2007 12:53:45 +0000 (GMT) Received: from localhost.localdomain ([127.0.0.1]:37860 "EHLO dl5rb.ham-radio-op.net") by ftp.linux-mips.org with ESMTP id S20026548AbXLNMxm (ORCPT ); Fri, 14 Dec 2007 12:53:42 +0000 Received: from denk.linux-mips.net (denk.linux-mips.net [127.0.0.1]) by dl5rb.ham-radio-op.net (8.14.1/8.13.8) with ESMTP id lBECrX3m029660; Fri, 14 Dec 2007 12:53:33 GMT Received: (from ralf@localhost) by denk.linux-mips.net (8.14.1/8.14.1/Submit) id lBE9dkpe027196; Fri, 14 Dec 2007 09:39:46 GMT Date: Fri, 14 Dec 2007 09:39:46 +0000 From: Ralf Baechle To: Jon Dufresne Cc: linux-kernel@vger.kernel.org, linux-mips@linux-mips.org Subject: Re: PCI resource unavailable on mips Message-ID: <20071214093945.GA25186@linux-mips.org> References: <1197557806.3370.7.camel@microwave.infinitevideocorporation.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1197557806.3370.7.camel@microwave.infinitevideocorporation.com> User-Agent: Mutt/1.5.17 (2007-11-01) Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 17813 X-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 13, 2007 at 09:56:46AM -0500, Jon Dufresne wrote: > I've done a bit of linux driver development on x86 in the past. > Currently I am working on my first ever linux driver for a mips box. I > started by testing the device in an x86 box and got it reasonable stable > and am now testing it in the mips box. There appears to be a major > problem, one unlike I have ever seen before. > > My PCI device has three BARS. This can be confirmed by the Technical > documentation and the x86 code. When the pci device is first probed, I > run a loop to printk out the bar information, this is just as a sanity > check. Here is the output on the x86: > > Bar0:PHYS=e0000000 LEN=04000000 > Bar1:PHYS=efa00000 LEN=00200000 > Bar2:PHYS=e8000000 LEN=04000000 > > but here is the output on the mips: > Bar0:PHYS=20000000 LEN=04000000 > Bar1:PHYS=24000000 LEN=00200000 > Bar2:PHYS=00000000 LEN=00000000 > > notice, BAR2 has no valid information on the mips. I tried to run > "pci_enable_device" before printing this information, as suggested by > LDD but it did not help. Resources are assigned on bootup by MIPS, not yet by pci_enable_device, so that was expected. > Has anyone seen a problem like this before and any idea how I can get > BAR2 a proper address? > > If I examine the config space directly there is an address in BAR2's > register, however it isn't in the 0x20000000 range like the other two, > instead it is 0x1c000000. Also if I do a ``cat /proc/iomem'' I correctly > see BAR0 and BAR1 in the output, but not BAR2. Odd. I knew the resource allocation stuff has it's issues for some non-trivial configuration but that one is a new one. Which makes me wonder if your platform runs the PCI code in probe-only mode where it will not actually assign resources but only inherit the whole PCI setup except interrupt routing from the firmware. What MIPS platform do you use? I'd like to take a look at its PCI setup code. Ralf From ralf@linux-mips.org Fri Dec 14 12:54:05 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 14 Dec 2007 12:54:08 +0000 (GMT) Received: from localhost.localdomain ([127.0.0.1]:38884 "EHLO dl5rb.ham-radio-op.net") by ftp.linux-mips.org with ESMTP id S20026603AbXLNMxn (ORCPT ); Fri, 14 Dec 2007 12:53:43 +0000 Received: from denk.linux-mips.net (denk.linux-mips.net [127.0.0.1]) by dl5rb.ham-radio-op.net (8.14.1/8.13.8) with ESMTP id lBECrX3o029660; Fri, 14 Dec 2007 12:53:35 GMT Received: (from ralf@localhost) by denk.linux-mips.net (8.14.1/8.14.1/Submit) id lBE17FqI024616; Fri, 14 Dec 2007 01:07:15 GMT Date: Fri, 14 Dec 2007 01:07:15 +0000 From: Ralf Baechle To: Yoichi Yuasa Cc: linux-mips Subject: Re: [PATCH][2/2][MIPS] add cpu_wait() to machine_halt() Message-ID: <20071214010715.GC20999@linux-mips.org> References: <20071212222019.9ab7b2ed.yoichi_yuasa@tripeaks.co.jp> <20071212222313.92e69c16.yoichi_yuasa@tripeaks.co.jp> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20071212222313.92e69c16.yoichi_yuasa@tripeaks.co.jp> User-Agent: Mutt/1.5.17 (2007-11-01) Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 17814 X-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 12, 2007 at 10:23:13PM +0900, Yoichi Yuasa wrote: > > Added cpu_wait() to machine_halt(). > For the power reduction in halt. Queued for 2.6.25. Thanks, Ralf. From ralf@linux-mips.org Fri Dec 14 12:54:29 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 14 Dec 2007 12:54:32 +0000 (GMT) Received: from localhost.localdomain ([127.0.0.1]:39140 "EHLO dl5rb.ham-radio-op.net") by ftp.linux-mips.org with ESMTP id S20026618AbXLNMxn (ORCPT ); Fri, 14 Dec 2007 12:53:43 +0000 Received: from denk.linux-mips.net (denk.linux-mips.net [127.0.0.1]) by dl5rb.ham-radio-op.net (8.14.1/8.13.8) with ESMTP id lBECrX3q029660; Fri, 14 Dec 2007 12:53:35 GMT Received: (from ralf@localhost) by denk.linux-mips.net (8.14.1/8.14.1/Submit) id lBE17wnM024619; Fri, 14 Dec 2007 01:07:58 GMT Date: Fri, 14 Dec 2007 01:07:58 +0000 From: Ralf Baechle To: Yoichi Yuasa Cc: linux-mips Subject: Re: [PATCH][MIPS] move the eXcite local config to excitedirectory Message-ID: <20071214010758.GD20999@linux-mips.org> References: <20071212223954.44e12672.yoichi_yuasa@tripeaks.co.jp> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20071212223954.44e12672.yoichi_yuasa@tripeaks.co.jp> User-Agent: Mutt/1.5.17 (2007-11-01) Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 17815 X-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 12, 2007 at 10:39:54PM +0900, Yoichi Yuasa wrote: > Moved the eXcite local config to excite directory. Queued for 2.6.25 - though a file for a single statement doesn't make verribly much sense. Thanks, Ralf. From ralf@linux-mips.org Fri Dec 14 12:54:52 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 14 Dec 2007 12:54:56 +0000 (GMT) Received: from localhost.localdomain ([127.0.0.1]:39652 "EHLO dl5rb.ham-radio-op.net") by ftp.linux-mips.org with ESMTP id S20026627AbXLNMxo (ORCPT ); Fri, 14 Dec 2007 12:53:44 +0000 Received: from denk.linux-mips.net (denk.linux-mips.net [127.0.0.1]) by dl5rb.ham-radio-op.net (8.14.1/8.13.8) with ESMTP id lBECrX3s029660; Fri, 14 Dec 2007 12:53:35 GMT Received: (from ralf@localhost) by denk.linux-mips.net (8.14.1/8.14.1/Submit) id lBE1728D024600; Fri, 14 Dec 2007 01:07:02 GMT Date: Fri, 14 Dec 2007 01:07:02 +0000 From: Ralf Baechle To: Yoichi Yuasa Cc: linux-mips Subject: Re: [PATCH][1/2][MIPS] remove unneeded button check for reset Message-ID: <20071214010702.GB20999@linux-mips.org> References: <20071212222019.9ab7b2ed.yoichi_yuasa@tripeaks.co.jp> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20071212222019.9ab7b2ed.yoichi_yuasa@tripeaks.co.jp> User-Agent: Mutt/1.5.17 (2007-11-01) Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 17816 X-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 12, 2007 at 10:20:19PM +0900, Yoichi Yuasa wrote: > Removed unneeded button check for reset. > Because, the Cobalt has power switch. Queued for 2.6.25 with the printk removed. If anywhere such notifications should go to userspace. Thanks, Ralf. From ralf@linux-mips.org Fri Dec 14 12:55:16 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 14 Dec 2007 12:55:20 +0000 (GMT) Received: from localhost.localdomain ([127.0.0.1]:39908 "EHLO dl5rb.ham-radio-op.net") by ftp.linux-mips.org with ESMTP id S20026633AbXLNMxo (ORCPT ); Fri, 14 Dec 2007 12:53:44 +0000 Received: from denk.linux-mips.net (denk.linux-mips.net [127.0.0.1]) by dl5rb.ham-radio-op.net (8.14.1/8.13.8) with ESMTP id lBECrX3u029660; Fri, 14 Dec 2007 12:53:35 GMT Received: (from ralf@localhost) by denk.linux-mips.net (8.14.1/8.14.1/Submit) id lBE162pm024580; Fri, 14 Dec 2007 01:06:02 GMT Date: Fri, 14 Dec 2007 01:06:02 +0000 From: Ralf Baechle To: Yoichi Yuasa Cc: linux-mips Subject: Re: [PATCH][MIPS] move vr41xx_calculate_clock_frequency() to plat_time_init() Message-ID: <20071214010602.GA20999@linux-mips.org> References: <20071212221109.e0448c18.yoichi_yuasa@tripeaks.co.jp> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20071212221109.e0448c18.yoichi_yuasa@tripeaks.co.jp> User-Agent: Mutt/1.5.17 (2007-11-01) Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 17817 X-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 12, 2007 at 10:11:09PM +0900, Yoichi Yuasa wrote: > Moved vr41xx_calculate_clock_frequency() to plat_time_init(). > This function relates to the timer function. > > Signed-off-by: Yoichi Yuasa Queued for 2.6.25. Thanks, Ralf. From ralf@linux-mips.org Fri Dec 14 12:55:40 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 14 Dec 2007 12:55:44 +0000 (GMT) Received: from localhost.localdomain ([127.0.0.1]:42980 "EHLO dl5rb.ham-radio-op.net") by ftp.linux-mips.org with ESMTP id S20026671AbXLNMxt (ORCPT ); Fri, 14 Dec 2007 12:53:49 +0000 Received: from denk.linux-mips.net (denk.linux-mips.net [127.0.0.1]) by dl5rb.ham-radio-op.net (8.14.1/8.13.8) with ESMTP id lBECrX3w029660; Fri, 14 Dec 2007 12:53:40 GMT Received: (from ralf@localhost) by denk.linux-mips.net (8.14.1/8.14.1/Submit) id lBE03mWZ019698; Fri, 14 Dec 2007 00:03:48 GMT Date: Fri, 14 Dec 2007 00:03:48 +0000 From: Ralf Baechle To: Frank Rowand Cc: linux-mips@linux-mips.org Subject: Re: [PATCH] RBTX4927: linux-2.6.24-rc4 hang on boot Message-ID: <20071214000348.GA12983@linux-mips.org> References: <1197386187.5610.18.camel@localhost.localdomain> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1197386187.5610.18.camel@localhost.localdomain> User-Agent: Mutt/1.5.17 (2007-11-01) Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 17818 X-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 11, 2007 at 10:16:27AM -0500, Frank Rowand wrote: > In linux-2.6.24-rc4 the Toshiba RBTX4927 hangs on boot. > > The cause is that plat_time_init() from arch/mips/tx4927/common/tx4927_setup.c > does not override the __weak plat_time_init() from arch/mips/kernel/time.c. > This is due to a compiler bug in gcc 4.1.1. The bug is reported to not exist > in earlier versions of gcc, and to be fixed in 4.1.2. The problem is that > the __weak plat_time_init() is empty and thus gets optimized out of > existence (thus the linker is never given the option to replace the > __weak function). You meant the call to plat_time_init() from time_init() gets optimized away. > For more info on the gcc bug see > > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27781 > > The attached patch is one workaround. Another possible workaround > would be to change the __weak plat_time_init() to be a non-empty > function. The __weak definition of plat_time_init was only ever meant to be a migration helper to keep platforms that don't have a plat_time_init compiling. A few greps says that all platforms now supply their own plat_time_init() so the weak definition is no longer needed. So I instead delete it. Ralf From ralf@linux-mips.org Fri Dec 14 16:26:41 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 14 Dec 2007 16:26:43 +0000 (GMT) Received: from localhost.localdomain ([127.0.0.1]:41880 "EHLO dl5rb.ham-radio-op.net") by ftp.linux-mips.org with ESMTP id S20030442AbXLNQ0l (ORCPT ); Fri, 14 Dec 2007 16:26:41 +0000 Received: from denk.linux-mips.net (denk.linux-mips.net [127.0.0.1]) by dl5rb.ham-radio-op.net (8.14.1/8.13.8) with ESMTP id lBEGQT9a006511; Fri, 14 Dec 2007 16:26:29 GMT Received: (from ralf@localhost) by denk.linux-mips.net (8.14.1/8.14.1/Submit) id lBEGQTvT006510; Fri, 14 Dec 2007 16:26:29 GMT Date: Fri, 14 Dec 2007 16:26:29 +0000 From: Ralf Baechle To: Mikael Starvik Cc: linux-mips@linux-mips.org Subject: Re: GCC 3.4.5 and mftc0 Message-ID: <20071214162629.GC30137@linux-mips.org> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.17 (2007-11-01) Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 17819 X-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 14, 2007 at 10:49:40AM +0100, Mikael Starvik wrote: > mftc0() is implemented as > > .word ... > move %0, $1 > > With at least gcc 3.4.5 the move is implemented as an addu %0, $1, $0. > But in the MIPS sumulator this fails and %0 gets the value 0xffffffff. > Implementing this as a or %0, $1, $0 instead gives the expected result. I wonder what "sumulator" you're using ... Addu is a perfectly fine implementation of move for 32-bit code. It's not for 64-bit code but that's beside the point here. The or method is also correct but historically the add instruction has been prefered, also because some processor - the R4300 afair - processes arithmetic instructions (add, sub that is not mul / div) faster than logic operations. > Any suggestions where the problem is and what the correct solution is? Fix the sumulator. > After fixing this my next problem is that IPIs doesn't reach all TCs > correctly (it seams like the code doesn't detect IXMT status correctly, > but I am still investigating). It is likely that it is caused by > something similar to the problem above. The code certainly works on real silicon, so the cause must be something local to your environment. Cheers, Ralf From jon.dufresne@infinitevideocorporation.com Fri Dec 14 18:32:47 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 14 Dec 2007 18:32:56 +0000 (GMT) Received: from host.infinivid.com ([64.119.179.76]:46266 "EHLO host.infinivid.com") by ftp.linux-mips.org with ESMTP id S20032875AbXLNScr (ORCPT ); Fri, 14 Dec 2007 18:32:47 +0000 Received: (qmail 9983 invoked from network); 14 Dec 2007 18:32:42 -0000 Received: from adsl-232-70-239.asm.bellsouth.net (HELO ?10.41.13.3?) (74.232.70.239) by host.infinivid.com with (RC4-MD5 encrypted) SMTP; 14 Dec 2007 11:32:41 -0700 Subject: Re: PCI resource unavailable on mips From: Jon Dufresne To: Ralf Baechle Cc: linux-kernel@vger.kernel.org, linux-mips@linux-mips.org In-Reply-To: <20071214093945.GA25186@linux-mips.org> References: <1197557806.3370.7.camel@microwave.infinitevideocorporation.com> <20071214093945.GA25186@linux-mips.org> Content-Type: text/plain Date: Fri, 14 Dec 2007 13:32:40 -0500 Message-Id: <1197657160.3420.11.camel@microwave.infinitevideocorporation.com> Mime-Version: 1.0 X-Mailer: Evolution 2.8.3 (2.8.3-2.fc6) 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: 17820 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: jon.dufresne@infinitevideocorporation.com Precedence: bulk X-list: linux-mips > > Odd. I knew the resource allocation stuff has it's issues for some > non-trivial configuration but that one is a new one. Which makes me > wonder if your platform runs the PCI code in probe-only mode where it > will not actually assign resources but only inherit the whole PCI setup > except interrupt routing from the firmware. > > What MIPS platform do you use? I'd like to take a look at its PCI setup > code. > I am using the MDS 810 STB as provided by MDS (http://www.mds.com/products/product.asp?prod=MDS-810). The kernel and entire environment (except my driver) was set up by MDS. uname output is as follows. # uname -a Linux 10.41.13.87 2.6.19PNX8550 #1 Wed Nov 21 14:55:52 EST 2007 mips unknown If I can provide additional information for you I'd be happy to help. Thanks, Jon From mratin@cisco.com Fri Dec 14 20:24:48 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 14 Dec 2007 20:24:57 +0000 (GMT) Received: from sj-iport-3-in.cisco.com ([171.71.176.72]:29036 "EHLO sj-iport-3.cisco.com") by ftp.linux-mips.org with ESMTP id S28576271AbXLNUYs convert rfc822-to-8bit (ORCPT ); Fri, 14 Dec 2007 20:24:48 +0000 Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-3.cisco.com with ESMTP; 14 Dec 2007 12:23:36 -0800 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id lBEKNaAa000615 for ; Fri, 14 Dec 2007 12:23:36 -0800 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id lBEKNJ1A000136 for ; Fri, 14 Dec 2007 20:23:36 GMT Received: from xmb-rtp-204.amer.cisco.com ([64.102.31.25]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 14 Dec 2007 15:23:28 -0500 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: Slow transfer for loopback Date: Fri, 14 Dec 2007 15:23:26 -0500 Message-ID: <0590495B8B6352449CE2CE5E8AAE67F15B4588@xmb-rtp-204.amer.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Slow transfer for loopback Thread-Index: Aceu+3eRgrIDbp9+SUKDz1eiP2iVCCPjFmwg References: From: "Ratin Rahman (mratin)" To: X-OriginalArrivalTime: 14 Dec 2007 20:23:28.0610 (UTC) FILETIME=[2FF83420:01C83E8F] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=432; t=1197663816; x=1198527816; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=mratin@cisco.com; z=From:=20=22Ratin=20Rahman=20(mratin)=22=20 |Subject:=20Slow=20transfer=20for=20loopback |Sender:=20; bh=lF8M6nJTXWCnUGAsGmNVO7+hjY6HFUd0rpiYtZT2iJg=; b=BLKvntRLvkroHDK8oVQUmzXpJaBFhQMpvZFqFbgeRlXFljSYUbArqHPR0e 6EHTNlG/LcOWXFayAM6rQSeXxQWkX9w5ThCNwYbSL4H12+G9vy2I5KSu3B8G TVaEVQ9iQ+; Authentication-Results: sj-dkim-2; header.From=mratin@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 17821 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: mratin@cisco.com Precedence: bulk X-list: linux-mips Hello All, I am using Mipsel linux 2.6.10 kernel on IDT 79RC32H434 chip which has integrated Ethernet MAC (100mbps). I am transfering UDP/RTP data (30 kbyte for an I frame, 2/3 kb for a p frame, splitted into 1480 bytes of RTP packets) over the loopback address from one application to another application. I am seeing accumulated delay in receiving the data. Anybody else experienced similar problem? Ratin From jon.dufresne@infinitevideocorporation.com Fri Dec 14 21:13:18 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 14 Dec 2007 21:13:27 +0000 (GMT) Received: from host.infinivid.com ([64.119.179.76]:50560 "EHLO host.infinivid.com") by ftp.linux-mips.org with ESMTP id S28576429AbXLNVNS (ORCPT ); Fri, 14 Dec 2007 21:13:18 +0000 Received: (qmail 15912 invoked from network); 14 Dec 2007 21:12:16 -0000 Received: from adsl-232-70-239.asm.bellsouth.net (HELO ?10.41.13.3?) (74.232.70.239) by host.infinivid.com with (RC4-MD5 encrypted) SMTP; 14 Dec 2007 14:12:16 -0700 Subject: Re: PCI resource unavailable on mips From: Jon Dufresne To: Ralf Baechle Cc: linux-kernel@vger.kernel.org, linux-mips@linux-mips.org In-Reply-To: <20071214093945.GA25186@linux-mips.org> References: <1197557806.3370.7.camel@microwave.infinitevideocorporation.com> <20071214093945.GA25186@linux-mips.org> Content-Type: text/plain Date: Fri, 14 Dec 2007 16:12:15 -0500 Message-Id: <1197666735.3800.1.camel@microwave.infinitevideocorporation.com> Mime-Version: 1.0 X-Mailer: Evolution 2.8.3 (2.8.3-2.fc6) 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: 17822 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: jon.dufresne@infinitevideocorporation.com Precedence: bulk X-list: linux-mips > Odd. I knew the resource allocation stuff has it's issues for some > non-trivial configuration but that one is a new one. Which makes me > wonder if your platform runs the PCI code in probe-only mode where it > will not actually assign resources but only inherit the whole PCI setup > except interrupt routing from the firmware. Hmm, I found more strange behavior with the bars that may or may not be related. I wrote a function that does another sanity check. It does an ioremap on one of the working bars, then reads one address for correctness. This is just to confirm that iomem is working. This is what the function looks like: > void dump_mmio(struct pci_dev *dev) > { > unsigned long phys, size; > struct resource *mem_region; > void __iomem *mmio; > u32 dword; > > phys = pci_resource_start(dev, 1); > size = pci_resource_len(dev, 1); > > mem_region = request_mem_region(phys, size, MODULENAME); > BUG_ON(!mem_region); > mmio = ioremap_nocache(phys, size); > BUG_ON(!mmio); > > printk("******************MMIO*************************************\n"); > printk("mmio=0x%p phys=0x%08lx size=0x%08lx\n", mmio, phys, size); > dword = ioread32(mmio + PCI_MMIO_BASE + 0x40); > printk("dword=%x\n", dword); > printk("***********************************************************\n"); > > iounmap(mmio); > release_mem_region(phys, size); > } on x86 this prints out what I would expect with the correct value which is: > ******************MMIO************************************* > mmio=0xf8e80000 phys=0xefa00000 size=0x00200000 > dword=54061131 > *********************************************************** on mips however this crashes the kernel with a "Data bus error" the exact output is below: > ******************MMIO************************************* > mmio=0xc0300000 phys=0x24000000 size=0x00200000 > Data bus error, epc == c0279a00, ra == c02799f4 > Oops[#1]: > Cpu 0 > $ 0 : 00000000 10008400 c0340040 802e031c > $ 4 : 802e031c 802e0000 00000001 8019f924 > $ 8 : 802e0000 0000020b 80320000 80320000 > $12 : 80320000 00000001 83031be6 8031c960 > $16 : 80086994 c0300000 24000000 00200000 > $20 : 802e0000 802e1ae4 c025a000 8008cde4 > $24 : 00000006 00000000 > $28 : 83030000 83031d20 c0288aec c02799f4 > Hi : 00000051 > Lo : eb851f00 > epc : c0279a00 Tainted: P > ra : c02799f4 Status: 10008403 KERNEL EXL IE > Cause : 1080001c > PrId : 00061200 > Modules linked in: tmman1700(P) mousedev usbhid usb_storage phStbFB(P) phStbFBRead(P) phStbVideoRenderer(P) phStbVe > Process insmod (pid: 785, threadinfo=83030000, task=8109f8e8) > Stack : c0288b28 c0300000 24000000 00200000 810b9c54 00000003 c0290000 810b9c00 > c0288b28 c0279ae4 83031d48 00000002 00000000 00000000 810b9c00 c0288510 > 00000000 80373480 80177520 801774e4 810b9d1c c0288544 80177574 829f6066 > 810b9d1c 810b9c48 c0288544 801a3d40 810b9d1c 801a4538 81091c00 8011fc70 > 810b9d1c 810b9c48 c0288544 c0288544 801a475c 801a475c 801a2810 80168e08 > ... > Call Trace:[][<80177520>][<801774e4>][<80177574>][<801a3d40>][<801a4538>][<8011fc70>][<801a475c>][<801a4] > > Code: 3c020004 34420040 02221021 <8c450000> 3c04c028 0200f809 24845164 3c04c028 0200f809 > Segmentation fault The data bus error occurs whenever I do a ioreadX on the ioremapped area. Any idea why this doesn't work on the mips? Thanks, Jon From giuseppe@eppesuigoccas.homedns.org Sat Dec 15 20:11:06 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Sat, 15 Dec 2007 20:11:15 +0000 (GMT) Received: from host140-217-dynamic.16-79-r.retail.telecomitalia.it ([79.16.217.140]:40358 "EHLO eppesuigoccas.homedns.org") by ftp.linux-mips.org with ESMTP id S20026001AbXLOULG (ORCPT ); Sat, 15 Dec 2007 20:11:06 +0000 Received: from giuseppe by eppesuigoccas.homedns.org with local (Exim 4.63) (envelope-from ) id 1J3dIY-00012b-JI; Sat, 15 Dec 2007 21:07:46 +0100 Date: Sat, 15 Dec 2007 21:07:46 +0100 From: Giuseppe Sacco To: Ricardo Mendoza , linux-mips@linux-mips.org Subject: Re: Still no 2.6.24 on ip32 Message-ID: <20071215200746.GA3989@eppesuigoccas.homedns.org> References: <1193599031.14874.1.camel@scarafaggio> <20071029150625.GB4165@linux-mips.org> <1194268551.4842.3.camel@scarafaggio> <1194281699.4192.3.camel@casa> <1197287929.17265.6.camel@scarafaggio> <475D7FE2.7080703@kanux.com> <1197371095.7889.24.camel@scarafaggio> <475E9012.1010504@kanux.com> <20071211204437.GA14243@eppesuigoccas.homedns.org> <475EC648.8030906@kanux.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <475EC648.8030906@kanux.com> User-Agent: Mutt/1.5.13 (2006-08-11) Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 17823 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: giuseppe@eppesuigoccas.homedns.org Precedence: bulk X-list: linux-mips Hi Ricardo, On Tue, Dec 11, 2007 at 01:18:00PM -0400, Ricardo Mendoza wrote: > Giuseppe Sacco wrote: > > On Tue, Dec 11, 2007 at 09:26:42AM -0400, Ricardo Mendoza wrote: > >> Giuseppe Sacco wrote: > >> > >>> I just checked that my repository is up to date, so my problem is still > >>> there (thus I don't know if it is the same problem you fixed). > >>> > >>> BTW, what was the problem you fixed? I would like to have a look to it, > >>> to better understand what's going on there. > >> Well I just updated to see if anything had broken in the past few days, > >> but I don't seem to be hitting that error of yours. Could you send your > >> config to see if I can reproduce it? > > > > Yes, sure: http://eppesuigoccas.homedns.org/~giuseppe/debian/config-2.6.24-rc4-ip32.bz2 > > but please note that the problem is present in every kernel since 2.6.24-rc1 > > > > my boot stanza in arcboot is: > > > > label=test > > image=/boot/vmlinux-2.6.24-rc4-gs1 > > append="root=/dev/sda1 ro video=gbefb:1024x768-16@60 debug initcall_debug console=tty0 console=ttyS1,115200" > > Ran it without problems, can't get into much detail right now but I the > problem you are seeing is more than likely caused by your other patch to > serial_core.c. I made a few run, recompiled everything from scratch, without my patch, but I always had the system loop on IRQ #13 while booting. Do you test on ip32? SGI O2 R5000@200? I would like to know any difference between our test environments. Thanks, Gisueppe From yoichi_yuasa@tripeaks.co.jp Sun Dec 16 13:57:17 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Sun, 16 Dec 2007 13:57:26 +0000 (GMT) Received: from mo31.po.2iij.NET ([210.128.50.54]:57098 "EHLO mo31.po.2iij.net") by ftp.linux-mips.org with ESMTP id S20025210AbXLPN5R (ORCPT ); Sun, 16 Dec 2007 13:57:17 +0000 Received: by mo.po.2iij.net (mo31) id lBGDtxWo047056; Sun, 16 Dec 2007 22:55:59 +0900 (JST) Received: from delta (224.24.30.125.dy.iij4u.or.jp [125.30.24.224]) by mbox.po.2iij.net (po-mbox303) id lBGDtuv8018839 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sun, 16 Dec 2007 22:55:56 +0900 Date: Sun, 16 Dec 2007 22:54:26 +0900 From: Yoichi Yuasa To: Ralf Baechle Cc: yoichi_yuasa@tripeaks.co.jp, linux-mips Subject: [PATCH][2/2][MIPS] remove unused lasat definitions Message-Id: <20071216225426.e2d1052c.yoichi_yuasa@tripeaks.co.jp> In-Reply-To: <20071216225300.6069fe55.yoichi_yuasa@tripeaks.co.jp> References: <20071216225300.6069fe55.yoichi_yuasa@tripeaks.co.jp> Organization: TriPeaks Corporation X-Mailer: Sylpheed 2.4.5 (GTK+ 2.12.0; 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: 17824 X-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 Removed unused lasat definitions. Signed-off-by: Yoichi Yuasa diff -pruN -X mips/Documentation/dontdiff mips-orig/include/asm-mips/lasat/lasat.h mips/include/asm-mips/lasat/lasat.h --- mips-orig/include/asm-mips/lasat/lasat.h 2007-12-11 23:12:53.674363750 +0900 +++ mips/include/asm-mips/lasat/lasat.h 2007-12-12 00:14:56.073369250 +0900 @@ -245,9 +245,6 @@ static inline void lasat_ndelay(unsigned #define LASAT_SERVICEMODE_MAGIC_1 0xdeadbeef #define LASAT_SERVICEMODE_MAGIC_2 0xfedeabba -/* Lasat 100 boards */ -#define LASAT_GT_BASE (KSEG1ADDR(0x14000000)) - /* Lasat 200 boards */ #define Vrc5074_PHYS_BASE 0x1fa00000 #define Vrc5074_BASE (KSEG1ADDR(Vrc5074_PHYS_BASE)) diff -pruN -X mips/Documentation/dontdiff mips-orig/include/asm-mips/mach-lasat/mach-gt64120.h mips/include/asm-mips/mach-lasat/mach-gt64120.h --- mips-orig/include/asm-mips/mach-lasat/mach-gt64120.h 2007-12-11 23:12:54.162394250 +0900 +++ mips/include/asm-mips/mach-lasat/mach-gt64120.h 2007-12-12 00:13:39.216566000 +0900 @@ -11,17 +11,6 @@ /* * GT64120 config space base address on Lasat 100 */ -#define GT64120_BASE (KSEG1ADDR(0x14000000)) - -/* - * PCI Bus allocation - * - * (Guessing ...) - */ -#define GT_PCI_MEM_BASE 0x12000000UL -#define GT_PCI_MEM_SIZE 0x02000000UL -#define GT_PCI_IO_BASE 0x10000000UL -#define GT_PCI_IO_SIZE 0x02000000UL -#define GT_ISA_IO_BASE PCI_IO_BASE +#define GT64120_BASE KSEG1ADDR(GT_DEF_BASE) #endif /* _ASM_GT64120_LASAT_GT64120_DEP_H */ From yoichi_yuasa@tripeaks.co.jp Sun Dec 16 13:57:47 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Sun, 16 Dec 2007 13:57:56 +0000 (GMT) Received: from mo31.po.2iij.NET ([210.128.50.54]:35890 "EHLO mo31.po.2iij.net") by ftp.linux-mips.org with ESMTP id S20025214AbXLPN5R (ORCPT ); Sun, 16 Dec 2007 13:57:17 +0000 Received: by mo.po.2iij.net (mo31) id lBGDtvPu047041; Sun, 16 Dec 2007 22:55:57 +0900 (JST) Received: from delta (224.24.30.125.dy.iij4u.or.jp [125.30.24.224]) by mbox.po.2iij.net (po-mbox302) id lBGDtttv023716 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sun, 16 Dec 2007 22:55:55 +0900 Date: Sun, 16 Dec 2007 22:53:00 +0900 From: Yoichi Yuasa To: Ralf Baechle Cc: yoichi_yuasa@tripeaks.co.jp, linux-mips Subject: [PATCH][1/2][MIPS] remove unused struct bootloader_header Message-Id: <20071216225300.6069fe55.yoichi_yuasa@tripeaks.co.jp> Organization: TriPeaks Corporation X-Mailer: Sylpheed 2.4.5 (GTK+ 2.12.0; 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: 17825 X-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 Removed unused struct bootloader_header. Signed-off-by: Yoichi Yuasa diff -pruN -X mips/Documentation/dontdiff mips-orig/arch/mips/lasat/image/head.S mips/arch/mips/lasat/image/head.S --- mips-orig/arch/mips/lasat/image/head.S 2007-11-05 08:41:37.923119250 +0900 +++ mips/arch/mips/lasat/image/head.S 2007-11-05 08:31:39.865743000 +0900 @@ -1,4 +1,5 @@ -#include +#define LASAT_K_MAGIC0_VAL 0xfedeabba +#define LASAT_K_MAGIC1_VAL 0xbedead .text .section .text.start, "ax" @@ -21,7 +22,6 @@ .word _kernel_entry /* Here we have room for future flags */ - .org 0x40 reldate: .word TIMESTAMP diff -pruN -X mips/Documentation/dontdiff mips-orig/include/asm-mips/lasat/head.h mips/include/asm-mips/lasat/head.h --- mips-orig/include/asm-mips/lasat/head.h 2007-11-05 08:41:37.991123500 +0900 +++ mips/include/asm-mips/lasat/head.h 1970-01-01 09:00:00.000000000 +0900 @@ -1,22 +0,0 @@ -/* - * Image header stuff - */ -#ifndef _HEAD_H -#define _HEAD_H - -#define LASAT_K_MAGIC0_VAL 0xfedeabba -#define LASAT_K_MAGIC1_VAL 0x00bedead - -#ifndef _LANGUAGE_ASSEMBLY -#include -struct bootloader_header { - u32 magic[2]; - u32 version; - u32 image_start; - u32 image_size; - u32 kernel_start; - u32 kernel_entry; -}; -#endif - -#endif /* _HEAD_H */ From ralf@linux-mips.org Sun Dec 16 22:49:39 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Sun, 16 Dec 2007 22:49:41 +0000 (GMT) Received: from localhost.localdomain ([127.0.0.1]:5076 "EHLO dl5rb.ham-radio-op.net") by ftp.linux-mips.org with ESMTP id S20032415AbXLPWtj (ORCPT ); Sun, 16 Dec 2007 22:49:39 +0000 Received: from denk.linux-mips.net (denk.linux-mips.net [127.0.0.1]) by dl5rb.ham-radio-op.net (8.14.1/8.13.8) with ESMTP id lBGMkI04019948; Sun, 16 Dec 2007 22:46:18 GMT Received: (from ralf@localhost) by denk.linux-mips.net (8.14.1/8.14.1/Submit) id lBGMkH2Y019947; Sun, 16 Dec 2007 22:46:17 GMT Date: Sun, 16 Dec 2007 22:46:17 +0000 From: Ralf Baechle To: Jon Dufresne Cc: linux-kernel@vger.kernel.org, linux-mips@linux-mips.org Subject: Re: PCI resource unavailable on mips Message-ID: <20071216224617.GA18613@linux-mips.org> References: <1197557806.3370.7.camel@microwave.infinitevideocorporation.com> <20071214093945.GA25186@linux-mips.org> <1197666735.3800.1.camel@microwave.infinitevideocorporation.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1197666735.3800.1.camel@microwave.infinitevideocorporation.com> User-Agent: Mutt/1.5.17 (2007-11-01) Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 17826 X-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 14, 2007 at 04:12:15PM -0500, Jon Dufresne wrote: > Hmm, I found more strange behavior with the bars that may or may not be > related. I wrote a function that does another sanity check. It does an > ioremap on one of the working bars, then reads one address for > correctness. This is just to confirm that iomem is working. This is what > the function looks like: > > > void dump_mmio(struct pci_dev *dev) > > { > > unsigned long phys, size; > > struct resource *mem_region; > > void __iomem *mmio; > > u32 dword; > > > > phys = pci_resource_start(dev, 1); > > size = pci_resource_len(dev, 1); > > > > mem_region = request_mem_region(phys, size, MODULENAME); > > BUG_ON(!mem_region); > > mmio = ioremap_nocache(phys, size); > > BUG_ON(!mmio); > > > > printk("******************MMIO*************************************\n"); > > printk("mmio=0x%p phys=0x%08lx size=0x%08lx\n", mmio, phys, size); > > dword = ioread32(mmio + PCI_MMIO_BASE + 0x40); > > printk("dword=%x\n", dword); > > printk("***********************************************************\n"); > > > > iounmap(mmio); > > release_mem_region(phys, size); > > } > > on x86 this prints out what I would expect with the correct value which > is: > > > ******************MMIO************************************* > > mmio=0xf8e80000 phys=0xefa00000 size=0x00200000 > > dword=54061131 > > *********************************************************** > > on mips however this crashes the kernel with a "Data bus error" the > exact output is below: > > > ******************MMIO************************************* > > mmio=0xc0300000 phys=0x24000000 size=0x00200000 The virtual address 0xc0300000 looks sensible and the physical address 0x24000000 is consistent with what you found in the BAR registers. So that all looks reasonable but that only means not obviously wrong. So next I wonder what the value of PCI_MMIO_BASE is ... > > Cpu 0 > > $ 0 : 00000000 10008400 c0340040 802e031c > > $ 4 : 802e031c 802e0000 00000001 8019f924 > > $ 8 : 802e0000 0000020b 80320000 80320000 > > $12 : 80320000 00000001 83031be6 8031c960 > > $16 : 80086994 c0300000 24000000 00200000 > > $20 : 802e0000 802e1ae4 c025a000 8008cde4 > > $24 : 00000006 00000000 > > $28 : 83030000 83031d20 c0288aec c02799f4 > > Hi : 00000051 > > Lo : eb851f00 > > epc : c0279a00 Tainted: P > > ra : c02799f4 Status: 10008403 KERNEL EXL IE > > Cause : 1080001c > > PrId : 00061200 > > Modules linked in: tmman1700(P) mousedev usbhid usb_storage phStbFB(P) phStbFBRead(P) phStbVideoRenderer(P) phStbVe > > Process insmod (pid: 785, threadinfo=83030000, task=8109f8e8) > > Stack : c0288b28 c0300000 24000000 00200000 810b9c54 00000003 c0290000 810b9c00 > > c0288b28 c0279ae4 83031d48 00000002 00000000 00000000 810b9c00 c0288510 > > 00000000 80373480 80177520 801774e4 810b9d1c c0288544 80177574 829f6066 > > 810b9d1c 810b9c48 c0288544 801a3d40 810b9d1c 801a4538 81091c00 8011fc70 > > 810b9d1c 810b9c48 c0288544 c0288544 801a475c 801a475c 801a2810 80168e08 > > ... > > Call Trace:[][<80177520>][<801774e4>][<80177574>][<801a3d40>][<801a4538>][<8011fc70>][<801a475c>][<801a4] > > > > Code: 3c020004 34420040 02221021 <8c450000> 3c04c028 0200f809 24845164 3c04c028 0200f809 > > Segmentation fault > > The data bus error occurs whenever I do a ioreadX on the ioremapped area. Any idea why this doesn't work on the mips? A bus error is an exception which is signalled by agent external (often called system controller) to the CPU core to signal a fatal error during a read or write bus transaction, for example after a bus timeout or if the address of the read/write isn't assigned to any device. PCI master abort also is often mapped to a bus error exception. Ralf From mikael.starvik@axis.com Mon Dec 17 06:45:38 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 17 Dec 2007 06:45:46 +0000 (GMT) Received: from miranda.se.axis.com ([193.13.178.8]:59032 "EHLO miranda.se.axis.com") by ftp.linux-mips.org with ESMTP id S20021826AbXLQGpi convert rfc822-to-8bit (ORCPT ); Mon, 17 Dec 2007 06:45:38 +0000 Received: from PCSTARVIK (dh10-84-127-75.se.axis.com [10.84.127.75]) by miranda.se.axis.com (8.13.4/8.13.4/Debian-3sarge3) with ESMTP id lBH6jRDL002226; Mon, 17 Dec 2007 07:45:27 +0100 From: "Mikael Starvik" To: "'Ralf Baechle'" , "Mikael Starvik" Cc: Subject: RE: GCC 3.4.5 and mftc0 Date: Mon, 17 Dec 2007 07:45:27 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 8BIT X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.6626 In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Importance: Normal Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 17827 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: mikael.starvik@axis.com Precedence: bulk X-list: linux-mips Thanks! and sorry for the spelling of simulator. /Mikael -----Original Message----- From: Ralf Baechle [mailto:ralf@linux-mips.org] Sent: Friday, December 14, 2007 5:26 PM To: Mikael Starvik Cc: linux-mips@linux-mips.org Subject: Re: GCC 3.4.5 and mftc0 On Fri, Dec 14, 2007 at 10:49:40AM +0100, Mikael Starvik wrote: > mftc0() is implemented as > > .word ... > move %0, $1 > > With at least gcc 3.4.5 the move is implemented as an addu %0, $1, $0. > But in the MIPS sumulator this fails and %0 gets the value 0xffffffff. > Implementing this as a or %0, $1, $0 instead gives the expected result. I wonder what "sumulator" you're using ... Addu is a perfectly fine implementation of move for 32-bit code. It's not for 64-bit code but that's beside the point here. The or method is also correct but historically the add instruction has been prefered, also because some processor - the R4300 afair - processes arithmetic instructions (add, sub that is not mul / div) faster than logic operations. > Any suggestions where the problem is and what the correct solution is? Fix the sumulator. > After fixing this my next problem is that IPIs doesn't reach all TCs > correctly (it seams like the code doesn't detect IXMT status correctly, > but I am still investigating). It is likely that it is caused by > something similar to the problem above. The code certainly works on real silicon, so the cause must be something local to your environment. Cheers, Ralf From share.kt@gmail.com Mon Dec 17 08:31:17 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 17 Dec 2007 08:31:25 +0000 (GMT) Received: from wa-out-1112.google.com ([209.85.146.179]:58263 "EHLO wa-out-1112.google.com") by ftp.linux-mips.org with ESMTP id S20023353AbXLQIbR (ORCPT ); Mon, 17 Dec 2007 08:31:17 +0000 Received: by wa-out-1112.google.com with SMTP id m16so3066282waf.20 for ; Mon, 17 Dec 2007 00:31:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:mime-version:content-type; bh=7VRmMX7iKjii4EkYWS3w18NfmrZAQgrMcgDs6rdXJVQ=; b=cUEh1H38RsObAmfkwUzyCwRvKt7rfu1uHChemRAhIb25V77TPdadL0UngwrFH1UBwNdapD5PsqMksQtupkeGzpQcboxdSmo0HnFVwr1Zyw8VsqTuAOi0UbyzG1V5IQQlejdc2hcmYPE7ILsX4mbKpXInDrCV1X7CRdOZZsAQrXU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:mime-version:content-type; b=QSFaIBDpYlFea09dK4la6hsoo63ga3WFSJ9nIx/l+W7EAYMwUjsBaVRIyKkFUR7QO/OEw9GRj+N57LMoRc4y2Vmyl+IIhr4KjtcZsrxIsmhy0QsXZNDnj7xnEeYCbzRYfyEPtu8LV5siwMoQFFb6pbJruJDHpCoQWY1p5X0Rdjs= Received: by 10.114.67.2 with SMTP id p2mr2125175waa.1.1197880265213; Mon, 17 Dec 2007 00:31:05 -0800 (PST) Received: by 10.114.135.8 with HTTP; Mon, 17 Dec 2007 00:31:05 -0800 (PST) Message-ID: Date: Mon, 17 Dec 2007 14:01:05 +0530 From: kaka To: linux-mips@linux-mips.org, uclinux-dev@uclinux.org, celinux-dev@tree.celinuxforum.org, linux-fbdev-users@lists.sourceforge.net, directfb-users@directfb.org, directfb-dev@directfb.org Subject: Error in running gtk example on cross compiled GTK with DirectFB on MIPS board MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_5204_15501233.1197880265204" Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 17828 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: share.kt@gmail.com Precedence: bulk X-list: linux-mips ------=_Part_5204_15501233.1197880265204 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline HI ALL, We have successfully cross compiled GTK and DIRECTFB with all its dependencies for MIPS board. On running the basic test example of GTK, it is getting struck in the thread loop infinitely. We had put the "debug printf" statement in the gtkmain.c and debugged the test example. It is getting struck in the * g_main_loop_run (loop);* given below is the code(code snippet from gtkmain.c) void gtk_main (void) { GList *tmp_list; GList *functions; GtkInitFunction *init; GMainLoop *loop; printf("\n%s :: %d\n",__FILE__,__LINE__); gtk_main_loop_level++; loop = g_main_loop_new (NULL, TRUE); main_loops = g_slist_prepend (main_loops, loop); printf("\n%s :: %d\n",__FILE__,__LINE__); tmp_list = functions = init_functions; init_functions = NULL; while (tmp_list) { init = tmp_list->data; tmp_list = tmp_list->next; (* init->function) (init->data); g_free (init); } g_list_free (functions); printf("\n%s :: %d\n",__FILE__,__LINE__); if (g_main_loop_is_running (main_loops->data)) { * printf("\n%s :: %d\n",__FILE__,__LINE__); GDK_THREADS_LEAVE (); g_main_loop_run (loop); GDK_THREADS_ENTER (); * printf("\n%s :: %d\n",__FILE__,__LINE__); gdk_flush (); } printf("\n%s :: %d\n",__FILE__,__LINE__); if (quit_functions) { GList *reinvoke_list = NULL; GtkQuitFunction *quitf; Given below is the src code for test example of GTK: #include int main( int argc, char *argv[] ) { GtkWidget *window; GtkWidget *pMainWidget; GdkPixbuf *image; gboolean ret = 0; gtk_init (&argc, &argv); printf("\n\n\ngtk_init (&argc, &argv);\n\n\n"); window = gtk_window_new (GTK_WINDOW_TOPLEVEL); //gtk_container_set_border_width (GTK_CONTAINER (window), 10); image = gdk_pixbuf_new_from_file ("test.gif", NULL); if (!image) return FALSE; pMainWidget = gtk_image_new_from_pixbuf(image); printf("\n\n\npMainWidget = gtk_image_new_from_pixbuf(image);\n\n\n"); gtk_widget_show (pMainWidget); gtk_container_add (GTK_CONTAINER (window), pMainWidget); printf("\n\n\ngtk_container_add (GTK_CONTAINER (window), pMainWidget);\n\n\n") ; gtk_widget_show (window); printf("\n\n\nABHISHEK START OF gtk_main\n\n\n"); gtk_main (); printf("\n\n\nABHISHEK END OF gtk_main\n\n\n"); return 0; } Can anybody Plz throw some light on it? Thanks in advcance -- Thanks & Regards, kaka ------=_Part_5204_15501233.1197880265204 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline
HI ALL,
 
We have successfully cross compiled GTK and DIRECTFB with all its dependencies for MIPS board.
On running the basic test example of GTK, it is getting struck in the thread loop infinitely.
We had put the  "debug printf"  statement in the gtkmain.c and debugged the test example.
It is getting struck in the  g_main_loop_run (loop); given below is the  code(code snippet from gtkmain.c)
 
void
gtk_main (void)
{
  GList *tmp_list;
  GList *functions;
  GtkInitFunction *init;
  GMainLoop *loop;
printf("\n%s :: %d\n",__FILE__,__LINE__);
  gtk_main_loop_level++;
 
  loop = g_main_loop_new (NULL, TRUE);
  main_loops = g_slist_prepend (main_loops, loop);
printf("\n%s :: %d\n",__FILE__,__LINE__);
  tmp_list = functions = init_functions;
  init_functions = NULL;
 
  while (tmp_list)
    {
      init = tmp_list->data;
      tmp_list = tmp_list->next;
     
      (* init->function) (init->data);
      g_free (init);
    }
  g_list_free (functions);
printf("\n%s :: %d\n",__FILE__,__LINE__);
  if (g_main_loop_is_running (main_loops->data))
    {
    printf("\n%s :: %d\n",__FILE__,__LINE__);
      GDK_THREADS_LEAVE ();
      g_main_loop_run (loop);
      GDK_THREADS_ENTER ();
      printf("\n%s :: %d\n",__FILE__,__LINE__);
      gdk_flush ();
    }
printf("\n%s :: %d\n",__FILE__,__LINE__);
  if (quit_functions)
    {
      GList *reinvoke_list = NULL;
      GtkQuitFunction *quitf;

 

Given below is the src code for test example of GTK:
 
#include <gtk/gtk.h>

int main( int   argc, char *argv[] )
{
	GtkWidget *window;
	GtkWidget *pMainWidget;
	GdkPixbuf *image;
	gboolean ret = 0;
	gtk_init (&argc, &argv);
printf("\n\n\ngtk_init (&argc, &argv);\n\n\n");		
	window = gtk_window_new (GTK_WINDOW_TOPLEVEL);
	
	//gtk_container_set_border_width (GTK_CONTAINER (window), 10);
	
	image  = gdk_pixbuf_new_from_file ("test.gif", NULL);
   	if (!image)
		return FALSE;
   	pMainWidget = gtk_image_new_from_pixbuf(image);
printf("\n\n\npMainWidget = gtk_image_new_from_pixbuf(image);\n\n\n");	
	gtk_widget_show (pMainWidget);
	
	gtk_container_add (GTK_CONTAINER (window), pMainWidget);
 printf("\n\n\ngtk_container_add (GTK_CONTAINER (window), pMainWidget);\n\n\n") ; 
	gtk_widget_show (window);
printf("\n\n\nABHISHEK START OF gtk_main\n\n\n");	
	gtk_main ();
printf("\n\n\nABHISHEK END OF gtk_main\n\n\n");
	return 0;
}
Can anybody Plz throw some light on it?
Thanks in advcance
--
Thanks & Regards,
kaka
------=_Part_5204_15501233.1197880265204-- From thomas@koeller.dyndns.org Mon Dec 17 10:35:16 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 17 Dec 2007 10:35:24 +0000 (GMT) Received: from mx02.hansenet.de ([213.191.73.26]:38802 "EHLO webmail.hansenet.de") by ftp.linux-mips.org with ESMTP id S20024204AbXLQKfQ (ORCPT ); Mon, 17 Dec 2007 10:35:16 +0000 Received: from [213.39.184.147] (213.39.184.147) by webmail.hansenet.de (7.3.118.12) (authenticated as mbx20228207@koeller-hh.org) id 47612DF0009945EB for linux-mips@linux-mips.org; Mon, 17 Dec 2007 11:34:57 +0100 Received: from localhost.koeller.dyndns.org (localhost.koeller.dyndns.org [127.0.0.1]) by mail.koeller.dyndns.org (Postfix) with ESMTP id 42B7547C0C for ; Mon, 17 Dec 2007 11:35:31 +0100 (CET) From: Thomas Koeller To: linux-mips@linux-mips.org Subject: timer irq setup Date: Mon, 17 Dec 2007 11:35:22 +0100 User-Agent: KMail/1.9.7 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200712171135.24569.thomas@koeller.dyndns.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: 17829 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: thomas@koeller.dyndns.org Precedence: bulk X-list: linux-mips In arch/mips/kernel/traps.c, per_cpu_trap_init() contains code to set up the global cp0_compare_irq variable. Does this make sense? I'd say that either the irq setup should be moved to trap_init(), or cp0_compare_irq should be changed to a per-cpu variable, depending on what the original intention was. tk -- Thomas Koeller thomas at koeller dot dyndns dot org From vksavl@gmail.com Mon Dec 17 13:18:03 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 17 Dec 2007 13:18:11 +0000 (GMT) Received: from nz-out-0506.google.com ([64.233.162.238]:54919 "EHLO nz-out-0506.google.com") by ftp.linux-mips.org with ESMTP id S20026800AbXLQNSD (ORCPT ); Mon, 17 Dec 2007 13:18:03 +0000 Received: by nz-out-0506.google.com with SMTP id n1so805480nzf.24 for ; Mon, 17 Dec 2007 05:17:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:mime-version:content-type:content-transfer-encoding:content-disposition; bh=YeW/VmpMHXbDLWNTjGYJidpIolxjDKcJRZJhK0L8yXM=; b=Vacn1WW2qjErAje1O0a3J/U2hnZm5juGde/bhMEk6Zb/ma040Rj1xsuceSC3QYlXBz8iDxEplIfcOOxHCp5VNj9Ci3CGPkU+2EZI9UIfjffgoZLkf1wP12qhjeXxCwAVhxNLym9WKKX9/kENXN54alYsSRsNAX3Zsw7eDyDklYE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:mime-version:content-type:content-transfer-encoding:content-disposition; b=BmJ2VV/2fF3MiglboTJRlhH3D4w+27tROQX8goCCPQ/56FPVMt3Ocpcg/Ke9soL9NU8ZrwDOzUVuNlv7g9rkZ4XbK/C8TYSHaAB/7R+O3uFTvHn8OKHIzy7gtaXzUBOS6sVdO8M6gJxg5eONEJ0jx+5LGZx/rzerZVLu30UkYoI= Received: by 10.142.229.4 with SMTP id b4mr509758wfh.118.1197897468747; Mon, 17 Dec 2007 05:17:48 -0800 (PST) Received: by 10.142.214.9 with HTTP; Mon, 17 Dec 2007 05:17:48 -0800 (PST) Message-ID: <73cd086a0712170517i146a452exea775f3942c1d5da@mail.gmail.com> Date: Mon, 17 Dec 2007 16:17:48 +0300 From: "Pavel Kiryukhin" To: linux-mips@linux-mips.org Subject: [PATCH][MIPS] fix user_cpus_allowed assignment Cc: vksavl@gmail.com MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 17830 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: vksavl@gmail.com Precedence: bulk X-list: linux-mips Hi, there seems to be a bug in affinity handling for CONFIG_MIPS_MT_FPAFF=y. It can be easily reproduced - for two-cpus system set new mask to 4. Call fails, but next sched_getaffinity() call returns 0 as current mask. Simple fix is below. Signed-off-by: Pavel Kiryukhin diff --git a/arch/mips/kernel/mips-mt-fpaff.c b/arch/mips/kernel/mips-mt-fpaff.cindex 892665b..774f91e 100644 --- a/arch/mips/kernel/mips-mt-fpaff.c +++ b/arch/mips/kernel/mips-mt-fpaff.c @@ -87,9 +87,6 @@ asmlinkage long mipsmt_sys_sched_setaffinity(pid_t pid, unsigned int len, if (retval) goto out_unlock; - /* Record new user-specified CPU set for future reference */ - p->thread.user_cpus_allowed = new_mask; - /* Unlock the task list */ read_unlock(&tasklist_lock); @@ -104,6 +101,10 @@ asmlinkage long mipsmt_sys_sched_setaffinity(pid_t pid, unsigned int len, retval = set_cpus_allowed(p, new_mask); } + /* Record new user-specified CPU set for future reference */ + if (!retval) + p->thread.user_cpus_allowed = new_mask; + out_unlock: put_task_struct(p); unlock_cpu_hotplug(); From jon.dufresne@infinitevideocorporation.com Mon Dec 17 15:16:35 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 17 Dec 2007 15:16:44 +0000 (GMT) Received: from host.infinivid.com ([64.119.179.76]:61591 "EHLO host.infinivid.com") by ftp.linux-mips.org with ESMTP id S20027487AbXLQPQf (ORCPT ); Mon, 17 Dec 2007 15:16:35 +0000 Received: (qmail 14086 invoked from network); 17 Dec 2007 15:16:33 -0000 Received: from adsl-232-70-239.asm.bellsouth.net (HELO ?10.41.13.3?) (74.232.70.239) by host.infinivid.com with (RC4-MD5 encrypted) SMTP; 17 Dec 2007 08:16:32 -0700 Subject: Re: PCI resource unavailable on mips From: Jon Dufresne To: Ralf Baechle Cc: linux-kernel@vger.kernel.org, linux-mips@linux-mips.org In-Reply-To: <20071216224617.GA18613@linux-mips.org> References: <1197557806.3370.7.camel@microwave.infinitevideocorporation.com> <20071214093945.GA25186@linux-mips.org> <1197666735.3800.1.camel@microwave.infinitevideocorporation.com> <20071216224617.GA18613@linux-mips.org> Content-Type: text/plain Date: Mon, 17 Dec 2007 10:16:31 -0500 Message-Id: <1197904591.3351.5.camel@microwave.infinitevideocorporation.com> Mime-Version: 1.0 X-Mailer: Evolution 2.8.3 (2.8.3-2.fc6) 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: 17831 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: jon.dufresne@infinitevideocorporation.com Precedence: bulk X-list: linux-mips I did a bit more work and investigation on this and it turns out I could not read the mmio in kernel space because I had not done a pci_enable_device_bars() on the device. I had never done this on x86 so I didn't realize it was necessary. > The virtual address 0xc0300000 looks sensible and the physical address > 0x24000000 is consistent with what you found in the BAR registers. So that > all looks reasonable but that only means not obviously wrong. So next I > wonder what the value of PCI_MMIO_BASE is ... The PCI_MMIO_BASE is a defined as: > #define PCI_MMIO_BASE (0x00040000) This is define in the technical documentation as the offset to access pci config space from the mmio. I am using this because I know what the values should be so it provides a nice sanity check. > A bus error is an exception which is signalled by agent external (often > called system controller) to the CPU core to signal a fatal error during a > read or write bus transaction, for example after a bus timeout or if the > address of the read/write isn't assigned to any device. PCI master abort > also is often mapped to a bus error exception. So after doing pci_enable_bars() I can now access this mmio region in kernel space. However, if I try to mmap this into user space I still receive the bus error. I am mapping this into user space using the example for LDD which says to use the remap_pfn_range() function. I've tested this on the x86 and it works as expected, however every time I access the mmio from user space using the mips, I continue to get the bus error I previously received in kernel space. Any idea what I might be doing wrong? How can I access this from user space? Thanks, Jon From sshtylyov@ru.mvista.com Mon Dec 17 15:47:15 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 17 Dec 2007 15:47:24 +0000 (GMT) Received: from h155.mvista.com ([63.81.120.155]:26596 "EHLO imap.sh.mvista.com") by ftp.linux-mips.org with ESMTP id S20028092AbXLQPrP (ORCPT ); Mon, 17 Dec 2007 15:47:15 +0000 Received: from [192.168.1.234] (unknown [10.150.0.9]) by imap.sh.mvista.com (Postfix) with ESMTP id 3777B3EC9; Mon, 17 Dec 2007 07:46:42 -0800 (PST) Message-ID: <476699FA.5050606@ru.mvista.com> Date: Mon, 17 Dec 2007 18:47:06 +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: Jon Dufresne Cc: Ralf Baechle , linux-kernel@vger.kernel.org, linux-mips@linux-mips.org Subject: Re: PCI resource unavailable on mips References: <1197557806.3370.7.camel@microwave.infinitevideocorporation.com> <20071214093945.GA25186@linux-mips.org> <1197666735.3800.1.camel@microwave.infinitevideocorporation.com> <20071216224617.GA18613@linux-mips.org> <1197904591.3351.5.camel@microwave.infinitevideocorporation.com> In-Reply-To: <1197904591.3351.5.camel@microwave.infinitevideocorporation.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: 17832 X-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. Jon Dufresne wrote: > I did a bit more work and investigation on this and it turns out I could > not read the mmio in kernel space because I had not done a > pci_enable_device_bars() on the device. I had never done this on x86 so > I didn't realize it was necessary. >>The virtual address 0xc0300000 looks sensible and the physical address >>0x24000000 is consistent with what you found in the BAR registers. So that >>all looks reasonable but that only means not obviously wrong. So next I >>wonder what the value of PCI_MMIO_BASE is ... > The PCI_MMIO_BASE is a defined as: >>#define PCI_MMIO_BASE (0x00040000) > This is define in the technical documentation as the offset to access > pci config space from the mmio. From what mmio? If it's for accessing a config. space why then you're using it as an offset from BAR? > I am using this because I know what the > values should be so it provides a nice sanity check. > Any idea what I might be doing wrong? How can I access this from user > space? Your example doesn't make sense to me so far. > Thanks, > Jon WBR, Sergei From kevink@mips.com Mon Dec 17 16:47:46 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 17 Dec 2007 16:47:54 +0000 (GMT) Received: from mx.mips.com ([63.167.95.198]:37826 "EHLO dns0.mips.com") by ftp.linux-mips.org with ESMTP id S20029072AbXLQQrq (ORCPT ); Mon, 17 Dec 2007 16:47:46 +0000 Received: from mercury.mips.com (mercury [192.168.64.101]) by dns0.mips.com (8.12.11/8.12.11) with ESMTP id lBHGdXA4013152; Mon, 17 Dec 2007 08:39:34 -0800 (PST) Received: from grendel (grendel [192.168.236.16]) by mercury.mips.com (8.13.5/8.13.5) with SMTP id lBHGe5ZK029893; Mon, 17 Dec 2007 08:40:06 -0800 (PST) Message-ID: <017c01c840cb$7a5049c0$10eca8c0@grendel> From: "Kevin D. Kissell" To: "Pavel Kiryukhin" , Cc: References: <73cd086a0712170517i146a452exea775f3942c1d5da@mail.gmail.com> Subject: Re: [PATCH][MIPS] fix user_cpus_allowed assignment Date: Mon, 17 Dec 2007 17:40:03 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1914 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1914 Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 17833 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: kevink@mips.com Precedence: bulk X-list: linux-mips This looks to be a correct fix. Long term, we really do need to convince the scheduler maintainer to provide hooks that will allow hardware-driven affinity to be integrated with application-driven affinity in a sensible way, without requiring replication (and replicated maintenence) of the system call code in private copies like this. I asked for such hooks in sched.c when it first became apparent that dynamic FPU affinity was desirable, but was blown off at that time, so, with regret, I perpetrated the local copy hack. But it's silly, and MIPS can't possibly be the only architecture where Linux is used in systems with assymmetric resources where adaptive affinity is useful. Regards, Kevin K. ----- Original Message ----- From: "Pavel Kiryukhin" To: Cc: Sent: Monday, December 17, 2007 2:17 PM Subject: [PATCH][MIPS] fix user_cpus_allowed assignment > Hi, > there seems to be a bug in affinity handling for CONFIG_MIPS_MT_FPAFF=y. > It can be easily reproduced - for two-cpus system set new mask to 4. > Call fails, but next sched_getaffinity() call returns 0 as current > mask. > Simple fix is below. > > Signed-off-by: Pavel Kiryukhin > > diff --git a/arch/mips/kernel/mips-mt-fpaff.c > b/arch/mips/kernel/mips-mt-fpaff.cindex 892665b..774f91e 100644 > --- a/arch/mips/kernel/mips-mt-fpaff.c > +++ b/arch/mips/kernel/mips-mt-fpaff.c > @@ -87,9 +87,6 @@ asmlinkage long mipsmt_sys_sched_setaffinity(pid_t > pid, unsigned int len, > if (retval) > goto out_unlock; > > - /* Record new user-specified CPU set for future reference */ > - p->thread.user_cpus_allowed = new_mask; > - > /* Unlock the task list */ > read_unlock(&tasklist_lock); > > @@ -104,6 +101,10 @@ asmlinkage long > mipsmt_sys_sched_setaffinity(pid_t pid, unsigned int len, > retval = set_cpus_allowed(p, new_mask); > } > > + /* Record new user-specified CPU set for future reference */ > + if (!retval) > + p->thread.user_cpus_allowed = new_mask; > + > out_unlock: > put_task_struct(p); > unlock_cpu_hotplug(); > > From dok@directfb.org Mon Dec 17 17:26:46 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 17 Dec 2007 17:26:54 +0000 (GMT) Received: from directfb.org ([212.227.87.76]:9458 "EHLO www.directfb.org") by ftp.linux-mips.org with ESMTP id S20030505AbXLQR0q (ORCPT ); Mon, 17 Dec 2007 17:26:46 +0000 Received: from shizo ([10.1.1.6]) by www.directfb.org with esmtpsa (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from ) id 1J4Jjf-0005vp-Km; Mon, 17 Dec 2007 18:26:35 +0100 Message-ID: <4766B149.5050109@directfb.org> Date: Mon, 17 Dec 2007 18:26:33 +0100 From: Denis Oliver Kropp User-Agent: Thunderbird 2.0.0.6 (X11/20070803) MIME-Version: 1.0 To: kaka CC: linux-mips@linux-mips.org, uclinux-dev@uclinux.org, celinux-dev@tree.celinuxforum.org, linux-fbdev-users@lists.sourceforge.net, directfb-users@directfb.org, directfb-dev@directfb.org Subject: Re: [directfb-dev] Error in running gtk example on cross compiled GTK with DirectFB on MIPS board References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 17834 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: dok@directfb.org Precedence: bulk X-list: linux-mips kaka wrote: > HI ALL, > > We have successfully cross compiled GTK and DIRECTFB with all its > dependencies for MIPS board. > On running the basic test example of GTK, it is getting struck in the thread > loop infinitely. > We had put the "debug printf" statement in the gtkmain.c and debugged the > test example. > It is getting struck in the * g_main_loop_run (loop);* given below is > the code(code > snippet from gtkmain.c) > > void > gtk_main (void) > { > GList *tmp_list; > GList *functions; > GtkInitFunction *init; > GMainLoop *loop; > printf("\n%s :: %d\n",__FILE__,__LINE__); > gtk_main_loop_level++; > > loop = g_main_loop_new (NULL, TRUE); > main_loops = g_slist_prepend (main_loops, loop); > printf("\n%s :: %d\n",__FILE__,__LINE__); > tmp_list = functions = init_functions; > init_functions = NULL; > > while (tmp_list) > { > init = tmp_list->data; > tmp_list = tmp_list->next; > > (* init->function) (init->data); > g_free (init); > } > g_list_free (functions); > printf("\n%s :: %d\n",__FILE__,__LINE__); > if (g_main_loop_is_running (main_loops->data)) > { > * printf("\n%s :: %d\n",__FILE__,__LINE__); > GDK_THREADS_LEAVE (); > g_main_loop_run (loop); > GDK_THREADS_ENTER (); > * printf("\n%s :: %d\n",__FILE__,__LINE__); That's normal. If you want runtime you have to create a timer or register idle or timeout functions. > gtk_container_add (GTK_CONTAINER (window), pMainWidget); > printf("\n\n\ngtk_container_add (GTK_CONTAINER (window), > pMainWidget);\n\n\n") ; > gtk_widget_show (window); > printf("\n\n\nABHISHEK START OF gtk_main\n\n\n"); > gtk_main (); > printf("\n\n\nABHISHEK END OF gtk_main\n\n\n"); > return 0; Simply/weakly put: it should not return before the application is quit. -- Best regards, Denis Oliver Kropp .------------------------------------------. | DirectFB - Hardware accelerated graphics | | http://www.directfb.org/ | "------------------------------------------" From share.kt@gmail.com Mon Dec 17 18:40:12 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 17 Dec 2007 18:40:21 +0000 (GMT) Received: from wa-out-1112.google.com ([209.85.146.179]:61136 "EHLO wa-out-1112.google.com") by ftp.linux-mips.org with ESMTP id S20031811AbXLQSkM (ORCPT ); Mon, 17 Dec 2007 18:40:12 +0000 Received: by wa-out-1112.google.com with SMTP id m16so3345194waf.20 for ; Mon, 17 Dec 2007 10:40:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; bh=Q0aNLBuxfgiX7g/CjPAS9TEtOi5pA6oHDUxDhydDeGs=; b=xKxHYQ9Eugxl8qEH0wFZJIbrFBhuIPwuaXC5nGODyVykGfN3qWol3QxQegORF7eQSt8XMTg2JFV22qGDzoeTKLDsb6AZv9rHFCdLrWhcG05b2A3hkjEveF+G0dwb9WhVkECplwJZkimI64tSNfEzCPk4MF7Eaq6U339x/et6SGA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=STgQVr5NUxZrUHEAt2/jKZXWB1HQc4Q6wpYen3j3iy7S+xszWKB1Mqhui+xIYcLBa+r12Enj3h9uqA1ruukDsUoMi3W2eZOXOCH0qru/ttTM92qJlPa/8H1u2i95njg11sYewfQHSqxXfLUJpqHk8hsUwl1JmywESMpwdZp353g= Received: by 10.114.181.1 with SMTP id d1mr3505880waf.10.1197916800597; Mon, 17 Dec 2007 10:40:00 -0800 (PST) Received: by 10.114.135.8 with HTTP; Mon, 17 Dec 2007 10:40:00 -0800 (PST) Message-ID: Date: Tue, 18 Dec 2007 00:10:00 +0530 From: kaka To: "Denis Oliver Kropp" Subject: Re: [directfb-dev] Error in running gtk example on cross compiled GTK with DirectFB on MIPS board Cc: linux-mips@linux-mips.org, uclinux-dev@uclinux.org, celinux-dev@tree.celinuxforum.org, linux-fbdev-users@lists.sourceforge.net, directfb-users@directfb.org, directfb-dev@directfb.org In-Reply-To: <4766B149.5050109@directfb.org> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_7619_17142918.1197916800588" References: <4766B149.5050109@directfb.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: 17835 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: share.kt@gmail.com Precedence: bulk X-list: linux-mips ------=_Part_7619_17142918.1197916800588 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Hi Denis, Thanks for the reply. I am running same example on X86 and it is running successfully and displaying image. On the other hand when i am running the same example on MIPS(GTK over DirecTFB) image is not being displayed. Could u plz provide some clue on it. Thanks. Kaka On 12/17/07, Denis Oliver Kropp wrote: > > kaka wrote: > > HI ALL, > > > > We have successfully cross compiled GTK and DIRECTFB with all its > > dependencies for MIPS board. > > On running the basic test example of GTK, it is getting struck in the > thread > > loop infinitely. > > We had put the "debug printf" statement in the gtkmain.c and debugged > the > > test example. > > It is getting struck in the * g_main_loop_run (loop);* given below is > > the code(code > > snippet from gtkmain.c) > > > > void > > gtk_main (void) > > { > > GList *tmp_list; > > GList *functions; > > GtkInitFunction *init; > > GMainLoop *loop; > > printf("\n%s :: %d\n",__FILE__,__LINE__); > > gtk_main_loop_level++; > > > > loop = g_main_loop_new (NULL, TRUE); > > main_loops = g_slist_prepend (main_loops, loop); > > printf("\n%s :: %d\n",__FILE__,__LINE__); > > tmp_list = functions = init_functions; > > init_functions = NULL; > > > > while (tmp_list) > > { > > init = tmp_list->data; > > tmp_list = tmp_list->next; > > > > (* init->function) (init->data); > > g_free (init); > > } > > g_list_free (functions); > > printf("\n%s :: %d\n",__FILE__,__LINE__); > > if (g_main_loop_is_running (main_loops->data)) > > { > > * printf("\n%s :: %d\n",__FILE__,__LINE__); > > GDK_THREADS_LEAVE (); > > g_main_loop_run (loop); > > GDK_THREADS_ENTER (); > > * printf("\n%s :: %d\n",__FILE__,__LINE__); > > That's normal. If you want runtime you have to create a timer or register > idle or timeout functions. > > > gtk_container_add (GTK_CONTAINER (window), pMainWidget); > > printf("\n\n\ngtk_container_add (GTK_CONTAINER (window), > > pMainWidget);\n\n\n") ; > > gtk_widget_show (window); > > printf("\n\n\nABHISHEK START OF gtk_main\n\n\n"); > > gtk_main (); > > printf("\n\n\nABHISHEK END OF gtk_main\n\n\n"); > > return 0; > > Simply/weakly put: it should not return before the application is quit. > > -- > Best regards, > Denis Oliver Kropp > > .------------------------------------------. > | DirectFB - Hardware accelerated graphics | > | http://www.directfb.org/ | > "------------------------------------------" > -- Thanks & Regards, kaka ------=_Part_7619_17142918.1197916800588 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline
Hi Denis,
 
Thanks for the reply.
I am running same example on X86 and it is running successfully and displaying image.
On the other hand when i am running the same example on MIPS(GTK over DirecTFB)
image is not being displayed.
 
Could u plz provide some clue on it.
Thanks.
 
Kaka

 
On 12/17/07, Denis Oliver Kropp <dok@directfb.org> wrote:
kaka wrote:
> HI ALL,
>
> We have successfully cross compiled GTK and DIRECTFB with all its
> dependencies for MIPS board.
> On running the basic test example of GTK, it is getting struck in the thread
> loop infinitely.
> We had put the  "debug printf"  statement in the gtkmain.c and debugged the
> test example.
> It is getting struck in the * g_main_loop_run (loop);* given below is
> the  code(code
> snippet from gtkmain.c)
>
> void
> gtk_main (void)
> {
>   GList *tmp_list;
>   GList *functions;
>   GtkInitFunction *init;
>   GMainLoop *loop;
> printf("\n%s :: %d\n",__FILE__,__LINE__);
>   gtk_main_loop_level++;
>
>   loop = g_main_loop_new (NULL, TRUE);
>   main_loops = g_slist_prepend (main_loops, loop);
> printf("\n%s :: %d\n",__FILE__,__LINE__);
>   tmp_list = functions = init_functions;
>   init_functions = NULL;
>
>   while (tmp_list)
>     {
>       init = tmp_list->data;
>       tmp_list = tmp_list->next;
>
>       (* init->function) (init->data);
>       g_free (init);
>     }
>   g_list_free (functions);
> printf("\n%s :: %d\n",__FILE__,__LINE__);
>   if (g_main_loop_is_running (main_loops->data))
>     {
>    * printf("\n%s :: %d\n",__FILE__,__LINE__);
>       GDK_THREADS_LEAVE ();
>       g_main_loop_run (loop);
>       GDK_THREADS_ENTER ();
> *      printf("\n%s :: %d\n",__FILE__,__LINE__);

That's normal. If you want runtime you have to create a timer or register idle or timeout functions.

>       gtk_container_add (GTK_CONTAINER (window), pMainWidget);
>  printf("\n\n\ngtk_container_add (GTK_CONTAINER (window),
> pMainWidget);\n\n\n") ;
>       gtk_widget_show (window);
> printf("\n\n\nABHISHEK START OF gtk_main\n\n\n");
>       gtk_main ();
> printf("\n\n\nABHISHEK END OF gtk_main\n\n\n");
>       return 0;

Simply/weakly put: it should not return before the application is quit.

--
Best regards,
Denis Oliver Kropp

.------------------------------------------.
| DirectFB - Hardware accelerated graphics |
| http://www.directfb.org/                 |
"------------------------------------------"



--
Thanks & Regards,
kaka ------=_Part_7619_17142918.1197916800588-- From joe@perches.com Mon Dec 17 19:32:27 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 17 Dec 2007 19:32:35 +0000 (GMT) Received: from DSL022.labridge.com ([206.117.136.22]:5900 "EHLO perches.com") by ftp.linux-mips.org with ESMTP id S20026548AbXLQTc1 (ORCPT ); Mon, 17 Dec 2007 19:32:27 +0000 Received: from localhost.localdomain (192-168-1-128.LABridge.com [192.168.1.128] (may be forged)) by perches.com (8.9.3/8.9.3) with ESMTP id KAA32725; Mon, 17 Dec 2007 10:43:12 -0800 From: Joe Perches To: linux-kernel@vger.kernel.org Cc: Andrew Morton , Ralf Baechle , linux-mips@linux-mips.org Subject: [PATCH] arch/mips/: Spelling fixes Date: Mon, 17 Dec 2007 11:30:08 -0800 Message-Id: <1197919875-5288-9-git-send-email-joe@perches.com> X-Mailer: git-send-email 1.5.3.7.949.g2221a6 Message-Id: <5703e57f925f31fc0eb38873bd7f10fc44f99cb4.1197918889.git.joe@perches.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: 17836 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: joe@perches.com Precedence: bulk X-list: linux-mips Signed-off-by: Joe Perches --- arch/mips/au1000/mtx-1/board_setup.c | 2 +- arch/mips/kernel/binfmt_elfn32.c | 2 +- arch/mips/kernel/binfmt_elfo32.c | 2 +- arch/mips/kernel/kspd.c | 2 +- arch/mips/kernel/setup.c | 4 ++-- arch/mips/kernel/smtc.c | 6 +++--- arch/mips/mm/c-r4k.c | 2 +- arch/mips/sgi-ip27/ip27-hubio.c | 2 +- 8 files changed, 11 insertions(+), 11 deletions(-) diff --git a/arch/mips/au1000/mtx-1/board_setup.c b/arch/mips/au1000/mtx-1/board_setup.c index abfc4bc..310d5df 100644 --- a/arch/mips/au1000/mtx-1/board_setup.c +++ b/arch/mips/au1000/mtx-1/board_setup.c @@ -99,7 +99,7 @@ mtx1_pci_idsel(unsigned int devsel, int assert) #endif if (assert && devsel != 0) { - // supress signal to cardbus + // suppress signal to cardbus au_writel( 0x00000002, SYS_OUTPUTCLR ); // set EXT_IO3 OFF } else { diff --git a/arch/mips/kernel/binfmt_elfn32.c b/arch/mips/kernel/binfmt_elfn32.c index 9b34238..77db347 100644 --- a/arch/mips/kernel/binfmt_elfn32.c +++ b/arch/mips/kernel/binfmt_elfn32.c @@ -98,7 +98,7 @@ static __inline__ void jiffies_to_compat_timeval(unsigned long jiffies, struct compat_timeval *value) { /* - * Convert jiffies to nanoseconds and seperate with + * Convert jiffies to nanoseconds and separate with * one divide. */ u64 nsec = (u64)jiffies * TICK_NSEC; diff --git a/arch/mips/kernel/binfmt_elfo32.c b/arch/mips/kernel/binfmt_elfo32.c index da41eac..08f4cd7 100644 --- a/arch/mips/kernel/binfmt_elfo32.c +++ b/arch/mips/kernel/binfmt_elfo32.c @@ -100,7 +100,7 @@ static inline void jiffies_to_compat_timeval(unsigned long jiffies, struct compat_timeval *value) { /* - * Convert jiffies to nanoseconds and seperate with + * Convert jiffies to nanoseconds and separate with * one divide. */ u64 nsec = (u64)jiffies * TICK_NSEC; diff --git a/arch/mips/kernel/kspd.c b/arch/mips/kernel/kspd.c index d2c2e00..1630784 100644 --- a/arch/mips/kernel/kspd.c +++ b/arch/mips/kernel/kspd.c @@ -222,7 +222,7 @@ void sp_work_handle_request(void) } } - /* Run the syscall at the priviledge of the user who loaded the + /* Run the syscall at the privilege of the user who loaded the SP program */ if (vpe_getuid(tclimit)) diff --git a/arch/mips/kernel/setup.c b/arch/mips/kernel/setup.c index 7f6ddcb..ddc2d6d 100644 --- a/arch/mips/kernel/setup.c +++ b/arch/mips/kernel/setup.c @@ -423,13 +423,13 @@ static void __init bootmem_init(void) #endif /* CONFIG_SGI_IP27 */ /* - * arch_mem_init - initialize memory managment subsystem + * arch_mem_init - initialize memory management subsystem * * o plat_mem_setup() detects the memory configuration and will record detected * memory areas using add_memory_region. * * At this stage the memory configuration of the system is known to the - * kernel but generic memory managment system is still entirely uninitialized. + * kernel but generic memory management system is still entirely uninitialized. * * o bootmem_init() * o sparse_init() diff --git a/arch/mips/kernel/smtc.c b/arch/mips/kernel/smtc.c index 9c92d42..37ee189 100644 --- a/arch/mips/kernel/smtc.c +++ b/arch/mips/kernel/smtc.c @@ -66,7 +66,7 @@ asiduse smtc_live_asid[MAX_SMTC_TLBS][MAX_SMTC_ASIDS]; static atomic_t ipi_timer_latch[NR_CPUS]; /* - * Number of InterProcessor Interupt (IPI) message buffers to allocate + * Number of InterProcessor Interrupt (IPI) message buffers to allocate */ #define IPIBUF_PER_CPU 4 @@ -781,7 +781,7 @@ void smtc_send_ipi(int cpu, int type, unsigned int action) if (cpu_data[cpu].vpe_id != cpu_data[smp_processor_id()].vpe_id) { if (type == SMTC_CLOCK_TICK) atomic_inc(&ipi_timer_latch[cpu]); - /* If not on same VPE, enqueue and send cross-VPE interupt */ + /* If not on same VPE, enqueue and send cross-VPE interrupt */ smtc_ipi_nq(&IPIQ[cpu], pipi); LOCK_CORE_PRA(); settc(cpu_data[cpu].tc_id); @@ -1064,7 +1064,7 @@ static void setup_cross_vpe_interrupts(unsigned int nvpe) return; if (!cpu_has_vint) - panic("SMTC Kernel requires Vectored Interupt support"); + panic("SMTC Kernel requires Vectored Interrupt support"); set_vi_handler(MIPS_CPU_IPI_IRQ, ipi_irq_dispatch); diff --git a/arch/mips/mm/c-r4k.c b/arch/mips/mm/c-r4k.c index 9355f1c..049ba7f 100644 --- a/arch/mips/mm/c-r4k.c +++ b/arch/mips/mm/c-r4k.c @@ -1108,7 +1108,7 @@ static void __init setup_scache(void) /* * Do the probing thing on R4000SC and R4400SC processors. Other * processors don't have a S-cache that would be relevant to the - * Linux memory managment. + * Linux memory management. */ switch (c->cputype) { case CPU_R4000SC: diff --git a/arch/mips/sgi-ip27/ip27-hubio.c b/arch/mips/sgi-ip27/ip27-hubio.c index 524b371..a1fa4ab 100644 --- a/arch/mips/sgi-ip27/ip27-hubio.c +++ b/arch/mips/sgi-ip27/ip27-hubio.c @@ -168,7 +168,7 @@ static void hub_set_piomode(nasid_t nasid) } /* - * hub_pio_init - PIO-related hub initalization + * hub_pio_init - PIO-related hub initialization * * @hub: hubinfo structure for our hub */ -- 1.5.3.7.949.g2221a6 From joe@perches.com Mon Dec 17 19:45:24 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 17 Dec 2007 19:45:33 +0000 (GMT) Received: from DSL022.labridge.com ([206.117.136.22]:7181 "EHLO perches.com") by ftp.linux-mips.org with ESMTP id S20027486AbXLQTpY (ORCPT ); Mon, 17 Dec 2007 19:45:24 +0000 Received: from localhost.localdomain (192-168-1-128.LABridge.com [192.168.1.128] (may be forged)) by perches.com (8.9.3/8.9.3) with ESMTP id KAA32728; Mon, 17 Dec 2007 10:43:13 -0800 From: Joe Perches To: linux-kernel@vger.kernel.org Cc: Andrew Morton , Ralf Baechle , linux-mips@linux-mips.org Subject: [PATCH] include/asm-mips/: Spelling fixes Date: Mon, 17 Dec 2007 11:30:09 -0800 Message-Id: <1197919875-5288-10-git-send-email-joe@perches.com> X-Mailer: git-send-email 1.5.3.7.949.g2221a6 Message-Id: <5703e57f925f31fc0eb38873bd7f10fc44f99cb4.1197918890.git.joe@perches.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: 17837 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: joe@perches.com Precedence: bulk X-list: linux-mips Signed-off-by: Joe Perches --- include/asm-mips/mach-excite/excite_fpga.h | 2 +- include/asm-mips/mach-wrppmc/mach-gt64120.h | 2 +- include/asm-mips/sgi/ip22.h | 2 +- include/asm-mips/sn/sn0/hubio.h | 2 +- 4 files changed, 4 insertions(+), 4 deletions(-) diff --git a/include/asm-mips/mach-excite/excite_fpga.h b/include/asm-mips/mach-excite/excite_fpga.h index 38fcda7..0a1ef69 100644 --- a/include/asm-mips/mach-excite/excite_fpga.h +++ b/include/asm-mips/mach-excite/excite_fpga.h @@ -3,7 +3,7 @@ /** - * Adress alignment of the individual FPGA bytes. + * Address alignment of the individual FPGA bytes. * The address arrangement of the individual bytes of the FPGA is two * byte aligned at the embedded MK2 platform. */ diff --git a/include/asm-mips/mach-wrppmc/mach-gt64120.h b/include/asm-mips/mach-wrppmc/mach-gt64120.h index 00d8bf6..465234a 100644 --- a/include/asm-mips/mach-wrppmc/mach-gt64120.h +++ b/include/asm-mips/mach-wrppmc/mach-gt64120.h @@ -45,7 +45,7 @@ #define GT_PCI_IO_SIZE 0x02000000UL /* - * PCI interrupts will come in on either the INTA or INTD interrups lines, + * PCI interrupts will come in on either the INTA or INTD interrupts lines, * which are mapped to the #2 and #5 interrupt pins of the MIPS. On our * boards, they all either come in on IntD or they all come in on IntA, they * aren't mixed. There can be numerous PCI interrupts, so we keep a list of the diff --git a/include/asm-mips/sgi/ip22.h b/include/asm-mips/sgi/ip22.h index f4981c4..c0501f9 100644 --- a/include/asm-mips/sgi/ip22.h +++ b/include/asm-mips/sgi/ip22.h @@ -15,7 +15,7 @@ /* * These are the virtual IRQ numbers, we divide all IRQ's into * 'spaces', the 'space' determines where and how to enable/disable - * that particular IRQ on an SGI machine. HPC DMA and MC DMA interrups + * that particular IRQ on an SGI machine. HPC DMA and MC DMA interrupts * are not supported this way. Driver is supposed to allocate HPC/MC * interrupt as shareable and then look to proper status bit (see * HAL2 driver). This will prevent many complications, trust me ;-) diff --git a/include/asm-mips/sn/sn0/hubio.h b/include/asm-mips/sn/sn0/hubio.h index ef91b33..0187895 100644 --- a/include/asm-mips/sn/sn0/hubio.h +++ b/include/asm-mips/sn/sn0/hubio.h @@ -338,7 +338,7 @@ typedef union io_perf_cnt { #define IIO_IFDR 0x400398 /* IOQ FIFO Depth */ #define IIO_IIAP 0x4003a0 /* IIQ Arbitration Parameters */ #define IIO_IMMR IIO_IIAP -#define IIO_ICMR 0x4003a8 /* CRB Managment Register */ +#define IIO_ICMR 0x4003a8 /* CRB Management Register */ #define IIO_ICCR 0x4003b0 /* CRB Control Register */ #define IIO_ICTO 0x4003b8 /* CRB Time Out Register */ #define IIO_ICTP 0x4003c0 /* CRB Time Out Prescalar */ -- 1.5.3.7.949.g2221a6 From sshtylyov@ru.mvista.com Mon Dec 17 19:53:43 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 17 Dec 2007 19:53:52 +0000 (GMT) Received: from h155.mvista.com ([63.81.120.155]:18154 "EHLO imap.sh.mvista.com") by ftp.linux-mips.org with ESMTP id S20022366AbXLQTxn (ORCPT ); Mon, 17 Dec 2007 19:53:43 +0000 Received: from [192.168.1.234] (unknown [10.150.0.9]) by imap.sh.mvista.com (Postfix) with ESMTP id 145153EC9; Mon, 17 Dec 2007 11:53:11 -0800 (PST) Message-ID: <4766D3BE.7070509@ru.mvista.com> Date: Mon, 17 Dec 2007 22:53:34 +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: Joe Perches Cc: linux-kernel@vger.kernel.org, Andrew Morton , Ralf Baechle , linux-mips@linux-mips.org Subject: Re: [PATCH] include/asm-mips/: Spelling fixes References: <1197919875-5288-10-git-send-email-joe@perches.com> In-Reply-To: <1197919875-5288-10-git-send-email-joe@perches.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: 17838 X-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. Joe Perches wrote: > Signed-off-by: Joe Perches > diff --git a/include/asm-mips/mach-wrppmc/mach-gt64120.h b/include/asm-mips/mach-wrppmc/mach-gt64120.h > index 00d8bf6..465234a 100644 > --- a/include/asm-mips/mach-wrppmc/mach-gt64120.h > +++ b/include/asm-mips/mach-wrppmc/mach-gt64120.h > @@ -45,7 +45,7 @@ > #define GT_PCI_IO_SIZE 0x02000000UL > > /* > - * PCI interrupts will come in on either the INTA or INTD interrups lines, > + * PCI interrupts will come in on either the INTA or INTD interrupts lines, "interrupt" here. WBR, Sergei From joe@perches.com Mon Dec 17 20:02:36 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 17 Dec 2007 20:02:43 +0000 (GMT) Received: from DSL022.labridge.com ([206.117.136.22]:19469 "EHLO perches.com") by ftp.linux-mips.org with ESMTP id S20029065AbXLQUCg (ORCPT ); Mon, 17 Dec 2007 20:02:36 +0000 Received: from [192.168.1.128] (192-168-1-128.LABridge.com [192.168.1.128] (may be forged)) by perches.com (8.9.3/8.9.3) with ESMTP id LAA00757; Mon, 17 Dec 2007 11:13:56 -0800 Subject: Re: [PATCH] include/asm-mips/: Spelling fixes From: Joe Perches To: Sergei Shtylyov Cc: linux-kernel@vger.kernel.org, Andrew Morton , Ralf Baechle , linux-mips@linux-mips.org In-Reply-To: <4766D3BE.7070509@ru.mvista.com> References: <1197919875-5288-10-git-send-email-joe@perches.com> <4766D3BE.7070509@ru.mvista.com> Content-Type: text/plain Date: Mon, 17 Dec 2007 12:02:09 -0800 Message-Id: <1197921729.27386.13.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.12.0-2mdv2008.0 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: 17839 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: joe@perches.com Precedence: bulk X-list: linux-mips On Mon, 2007-12-17 at 22:53 +0300, Sergei Shtylyov wrote: > > - * PCI interrupts will come in on either the INTA or INTD interrups lines, > > + * PCI interrupts will come in on either the INTA or INTD interrupts lines, > "interrupt" here. Quite right. I did them by script and inspected, but didn't notice that one. cheers, Joe Signed-off-by: Joe Perches --- diff --git a/include/asm-mips/mach-wrppmc/mach-gt64120.h b/include/asm-mips/mach-wrppmc/mach-gt64120.h index 00d8bf6..465234a 100644 --- a/include/asm-mips/mach-wrppmc/mach-gt64120.h +++ b/include/asm-mips/mach-wrppmc/mach-gt64120.h @@ -45,7 +45,7 @@ #define GT_PCI_IO_SIZE 0x02000000UL /* - * PCI interrupts will come in on either the INTA or INTD interrups lines, + * PCI interrupts will come in on either the INTA or INTD interrupt lines, * which are mapped to the #2 and #5 interrupt pins of the MIPS. On our * boards, they all either come in on IntD or they all come in on IntA, they * aren't mixed. There can be numerous PCI interrupts, so we keep a list of the From rpjday@crashcourse.ca Mon Dec 17 21:12:07 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 17 Dec 2007 21:12:15 +0000 (GMT) Received: from astoria.ccjclearline.com ([64.235.106.9]:31673 "EHLO astoria.ccjclearline.com") by ftp.linux-mips.org with ESMTP id S20033659AbXLQVMH (ORCPT ); Mon, 17 Dec 2007 21:12:07 +0000 Received: from [142.161.33.250] (helo=crashcourse.ca) by astoria.ccjclearline.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.68) (envelope-from ) id 1J4NCq-0000An-1A for linux-mips@linux-mips.org; Mon, 17 Dec 2007 16:08:56 -0500 Date: Mon, 17 Dec 2007 16:08:49 -0500 (EST) From: "Robert P. J. Day" X-X-Sender: rpjday@localhost.localdomain To: linux-mips@linux-mips.org Subject: [OT?] is there something strange about __builtin_ffs these days? Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - astoria.ccjclearline.com X-AntiAbuse: Original Domain - linux-mips.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - crashcourse.ca X-Source: X-Source-Args: X-Source-Dir: Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 17840 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: rpjday@crashcourse.ca Precedence: bulk X-list: linux-mips i'm hoping i'm not abusing this list overly by asking for some help with debugging an OpenWRT issue. the trac ticket is here: https://dev.openwrt.org/ticket/2735 and involves cross-compiling an image for the MIPS-based linksys WRT54GL router. i've verified that this error still exists in the latest svn update of openwrt and, in a nutshell, it involves the claim that "__builtin_ffs" is undefined: ... CC [M] /home/openwrt/builds/trunk_brcm47xx/build_dir/linux-brcm47xx/spca5xx-le/spca_core.o /home/openwrt/builds/trunk_brcm47xx/build_dir/linux-brcm47xx/spca5xx-le/spca_core.c:538:5: warning: "__builtin_ffs" is not defined /home/openwrt/builds/trunk_brcm47xx/build_dir/linux-brcm47xx/spca5xx-le/spca_core.c:538:5: error: missing binary operator before token "(" ... that line in the source file is simply: #if PUD_SHIFT i have no idea what the problem is here and, as you can see from the trac ticket, this seems to have started because of the kernel version upgrade from 2.6.22 to 2.6.23. but what about that would affect the usage of __builtin_ffs? does anyone have an idea why something this basic might be going wrong now? any suggestions appreciated. thanks. rday -- ======================================================================== Robert P. J. Day Linux Consulting, Training and Annoying Kernel Pedantry Waterloo, Ontario, CANADA http://crashcourse.ca ======================================================================== From ths@networkno.de Mon Dec 17 21:45:10 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 17 Dec 2007 21:45:20 +0000 (GMT) Received: from relay01.mx.bawue.net ([193.7.176.67]:194 "EHLO relay01.mx.bawue.net") by ftp.linux-mips.org with ESMTP id S20034152AbXLQVpK (ORCPT ); Mon, 17 Dec 2007 21:45:10 +0000 Received: from lagash (88-106-143-223.dynamic.dsl.as9105.com [88.106.143.223]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by relay01.mx.bawue.net (Postfix) with ESMTP id 1B380481E5; Mon, 17 Dec 2007 22:45:04 +0100 (CET) Received: from ths by lagash with local (Exim 4.68) (envelope-from ) id 1J4Nln-00081z-C4; Mon, 17 Dec 2007 21:45:03 +0000 Date: Mon, 17 Dec 2007 21:45:03 +0000 From: Thiemo Seufer To: "Robert P. J. Day" Cc: linux-mips@linux-mips.org Subject: Re: [OT?] is there something strange about __builtin_ffs these days? Message-ID: <20071217214503.GB17397@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.17 (2007-11-01) Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 17841 X-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 Robert P. J. Day wrote: > > i'm hoping i'm not abusing this list overly by asking for some help > with debugging an OpenWRT issue. the trac ticket is here: > > https://dev.openwrt.org/ticket/2735 > > and involves cross-compiling an image for the MIPS-based linksys > WRT54GL router. i've verified that this error still exists in the > latest svn update of openwrt and, in a nutshell, it involves the claim > that "__builtin_ffs" is undefined: > > ... > CC [M] /home/openwrt/builds/trunk_brcm47xx/build_dir/linux-brcm47xx/spca5xx-le/spca_core.o > /home/openwrt/builds/trunk_brcm47xx/build_dir/linux-brcm47xx/spca5xx-le/spca_core.c:538:5: > warning: "__builtin_ffs" is not defined > /home/openwrt/builds/trunk_brcm47xx/build_dir/linux-brcm47xx/spca5xx-le/spca_core.c:538:5: > error: missing binary operator before token "(" > ... > > that line in the source file is simply: > > #if PUD_SHIFT > > i have no idea what the problem is here and, as you can see from the > trac ticket, this seems to have started because of the kernel version > upgrade from 2.6.22 to 2.6.23. but what about that would affect the > usage of __builtin_ffs? > > does anyone have an idea why something this basic might be going > wrong now? any suggestions appreciated. thanks. The compiler should never attempt to use __builtin_ffs by itself, because the kernel makefile adds -ffreestanding to CFLAGS. So either your compiler is broken, or the makefile of your kernel tree is incorrect, or somewhere in your kernel tree there's a explicit call to __builtin_ffs (which is also incorrect, as the compiler may invoke library functions to implement it.) Thiemo From thomas.koeller@baslerweb.com Tue Dec 18 00:32:07 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 18 Dec 2007 00:32:16 +0000 (GMT) Received: from mx01.hansenet.de ([213.191.73.25]:35001 "EHLO webmail.hansenet.de") by ftp.linux-mips.org with ESMTP id S28577066AbXLRAcH convert rfc822-to-8bit (ORCPT ); Tue, 18 Dec 2007 00:32:07 +0000 Received: from [213.39.184.147] (213.39.184.147) by webmail.hansenet.de (7.3.118.12) (authenticated as mbx20228207@koeller-hh.org) id 4761398E00AECD15; Tue, 18 Dec 2007 01:31:47 +0100 Received: from localhost.koeller.dyndns.org (localhost.koeller.dyndns.org [127.0.0.1]) by mail.koeller.dyndns.org (Postfix) with ESMTP id D9ADE47C10; Tue, 18 Dec 2007 01:31:40 +0100 (CET) From: Thomas Koeller Organization: Basler AG To: linux-mips@linux-mips.org Subject: excite patches Date: Tue, 18 Dec 2007 01:31:21 +0100 User-Agent: KMail/1.9.7 MIME-Version: 1.0 Content-Disposition: inline Cc: ralf@linux-mips.org Content-Type: text/plain; charset="iso-8859-15" Content-Transfer-Encoding: 8BIT Message-Id: <200712180131.22459.thomas.koeller@baslerweb.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: 17842 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: thomas.koeller@baslerweb.com Precedence: bulk X-list: linux-mips Here is a series of patches to bring the excite platform up to date. In order to achieve this, I had to apply a couple of changes to some non-platform code as well: Patch 1/4: This one introduces a new configuration parameter named GPI_RM9000, used to enable devices that depend on RM9000-style GPI hardware. This is a re-submit, I submitted this patch before, but it has not been applied yet. Patch 2/4: The RM9000 hazards in include/asm-mips/hazards.h were apparently wrong; I could not get c0_compare_int_usable() in arch/mips/kernel/cevt-r4k.c to work. The RM9122 manual says, "When a CP0 register is changed by an MTC0 or CTC0 instruction, the contents of the changed register must not be used for 4 cycles after the MTC0 or CTC0 is issued. Specifically, if a CP0 register is loaded, its contents must not be read back or otherwise used until 4 cycles later." I guess this also covers the case of observing the result of writing to a CP0 register by reading the contents of another CP0 register, as in this case. Patch 3/4: Since the excite platform uses the RM9000's alternate timer interrupt, I had to rework the compare interrupt setup. I changed the existing get_c0_compare_int() hook to be called earlier than before, so that cp0_compare_irq contains the correct value right from the start, and functions like c0_compare_int_pending() and c0_compare_int_usable() continue to function without any need for modifications. Then I added a get_c0_perfcounter_int() hook to complement it. I also did some minor modifications, like adding 'const' in some places, and outputting an error message if the compare interrupt is found to be non-functional, a condition that certainly deserves such a message. Since the get_c0_compare_int() hook is used in arch/mips/mips-boards/generic/time.c, users of this file might theoretically be affected by this change. I do not have access to these boards, so I could not check, however, I believe the change does not cause any breakage here. Patch 4/4: Finally, the excite platform has to supply the alternate compare irq, which this patch is for. tk -- _______________________________ Thomas Köller, Software Developer Basler Vision Technologies An der Strusbek 60-62 22926 Ahrensburg Germany Tel. +49 (0) 4102 - 463 390 Fax +49 (0) 4102 - 463 390 mailto:thomas.koeller@baslerweb.com http://www.baslerweb.com Vorstand: Dr.-Ing. Dietmar Ley (Vorsitzender) · John P. Jennings · Peter Krumhoff · Aufsichtsratsvorsitzender: Norbert Basler Basler AG · Amtsgericht Ahrensburg HRB 4090 · Ust-IdNr.: DE 135 098 121 · Steuer-Nr.: 30 292 04497 _______________________________ From thomas.koeller@baslerweb.com Tue Dec 18 00:32:37 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 18 Dec 2007 00:32:46 +0000 (GMT) Received: from mx01.hansenet.de ([213.191.73.25]:34745 "EHLO webmail.hansenet.de") by ftp.linux-mips.org with ESMTP id S28577067AbXLRAcH (ORCPT ); Tue, 18 Dec 2007 00:32:07 +0000 Received: from [213.39.184.147] (213.39.184.147) by webmail.hansenet.de (7.3.118.12) (authenticated as mbx20228207@koeller-hh.org) id 4761398E00AECD12; Tue, 18 Dec 2007 01:31:47 +0100 Received: from localhost.koeller.dyndns.org (localhost.koeller.dyndns.org [127.0.0.1]) by mail.koeller.dyndns.org (Postfix) with ESMTP id 9FAE247C0D; Tue, 18 Dec 2007 01:31:40 +0100 (CET) From: Thomas Koeller Date: Tue, 18 Dec 2007 01:26:37 +0100 Subject: [PATCH 2/4] [MIPS] Fix interrupt enable/disable hazards for RM9000 X-Length: 805 X-UID: 19 MIME-Version: 1.0 Content-Disposition: inline To: linux-mips@linux-mips.org Cc: ralf@linux-mips.org Content-Transfer-Encoding: 7bit Message-Id: <20071218003140.9FAE247C0D@mail.koeller.dyndns.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: 17843 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: thomas.koeller@baslerweb.com Precedence: bulk X-list: linux-mips The no-op hazards present before this caused c0_compare_int_usable() in arch/mips/kernel/cevt-r4k.c to fail. Signed-off-by: Thomas Koeller diff --git a/include/asm-mips/hazards.h b/include/asm-mips/hazards.h index 2de638f..6454d66 100644 --- a/include/asm-mips/hazards.h +++ b/include/asm-mips/hazards.h @@ -176,8 +176,10 @@ ASMMACRO(tlb_probe_hazard, _ssnop; _ssnop; _ssnop; _ssnop ) ASMMACRO(irq_enable_hazard, + _ssnop; _ssnop; _ssnop; _ssnop ) ASMMACRO(irq_disable_hazard, + _ssnop; _ssnop; _ssnop; _ssnop ) ASMMACRO(back_to_back_c0_hazard, ) -- 1.5.3.6 From thomas.koeller@baslerweb.com Tue Dec 18 00:33:07 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 18 Dec 2007 00:33:15 +0000 (GMT) Received: from mx02.hansenet.de ([213.191.73.26]:6854 "EHLO webmail.hansenet.de") by ftp.linux-mips.org with ESMTP id S28577074AbXLRAc1 (ORCPT ); Tue, 18 Dec 2007 00:32:27 +0000 Received: from [213.39.184.147] (213.39.184.147) by webmail.hansenet.de (7.3.118.12) (authenticated as mbx20228207@koeller-hh.org) id 4766ADD8000AB815; Tue, 18 Dec 2007 01:31:46 +0100 Received: from localhost.koeller.dyndns.org (localhost.koeller.dyndns.org [127.0.0.1]) by mail.koeller.dyndns.org (Postfix) with ESMTP id C3C8D47C0E; Tue, 18 Dec 2007 01:31:40 +0100 (CET) From: Thomas Koeller Date: Tue, 18 Dec 2007 01:26:50 +0100 Subject: [PATCH 3/4] [MIPS] Allow platform to override default timer and performance counter interrupts X-Length: 4845 X-UID: 20 To: linux-mips@linux-mips.org Cc: ralf@linux-mips.org MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <20071218003140.C3C8D47C0E@mail.koeller.dyndns.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: 17844 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: thomas.koeller@baslerweb.com Precedence: bulk X-list: linux-mips While there was a platform hook for setting the compare timer interrupt before, it was implemented in a somewhat arkward way, and no such hook existed for the performance counter interrupt. This change aims at a cleaner solution, by using the platform-supplied values right from the beginning instead of setting up the standard irq first, and then ignoring it. Signed-off-by: Thomas Koeller diff --git a/arch/mips/kernel/cevt-r4k.c b/arch/mips/kernel/cevt-r4k.c index 24a2d90..3b1407e 100644 --- a/arch/mips/kernel/cevt-r4k.c +++ b/arch/mips/kernel/cevt-r4k.c @@ -9,6 +9,7 @@ #include #include #include +#include #include #include @@ -76,8 +77,8 @@ static irqreturn_t c0_compare_interrupt(int irq, void *dev_id) { const int r2 = cpu_has_mips_r2; struct clock_event_device *cd; - int cpu = smp_processor_id(); - + const int cpu = smp_processor_id(); + /* * Suckage alert: * Before R2 of the architecture there was no way to see if a @@ -169,9 +170,6 @@ static void mips_event_handler(struct clock_event_device *dev) { } -/* - * FIXME: This doesn't hold for the relocated E9000 compare interrupt. - */ static int c0_compare_int_pending(void) { return (read_c0_cause() >> cp0_compare_irq) & 0x100; @@ -183,7 +181,8 @@ static int c0_compare_int_usable(void) unsigned int cnt; /* - * IP7 already pending? Try to clear it by acking the timer. + * Compare interrupt already pending? + * Try to clear it by acking the timer. */ if (c0_compare_int_pending()) { write_c0_compare(read_c0_count()); @@ -221,8 +220,8 @@ static int c0_compare_int_usable(void) int __cpuinit mips_clockevent_init(void) { - uint64_t mips_freq = mips_hpt_frequency; - unsigned int cpu = smp_processor_id(); + const uint64_t mips_freq = mips_hpt_frequency; + const unsigned int cpu = smp_processor_id(); struct clock_event_device *cd; unsigned int irq; @@ -240,17 +239,12 @@ int __cpuinit mips_clockevent_init(void) return 0; #endif - if (!c0_compare_int_usable()) + if (!c0_compare_int_usable()) { + pr_crit("MIPS compare interrupt not working - no timer clock\n"); return -ENXIO; + } - /* - * With vectored interrupts things are getting platform specific. - * get_c0_compare_int is a hook to allow a platform to return the - * interrupt number of it's liking. - */ irq = MIPS_CPU_IRQ_BASE + cp0_compare_irq; - if (get_c0_compare_int) - irq = get_c0_compare_int(); cd = &per_cpu(mips_clockevent_device, cpu); diff --git a/arch/mips/kernel/traps.c b/arch/mips/kernel/traps.c index fcae667..268247d 100644 --- a/arch/mips/kernel/traps.c +++ b/arch/mips/kernel/traps.c @@ -1281,6 +1281,20 @@ extern void flush_tlb_handlers(void); */ int cp0_compare_irq; +unsigned int __init __weak +get_c0_compare_int(void) +{ + return cpu_has_mips_r2 ? + (read_c0_intctl() >> 29) & 7 : CP0_LEGACY_COMPARE_IRQ; +} + +unsigned int __init __weak +get_c0_perfcount_int(void) +{ + return cpu_has_mips_r2 ? + (read_c0_intctl() >> 26) & 7 : -1; +} + /* * Performance counter IRQ or -1 if shared with timer */ @@ -1352,21 +1366,11 @@ void __init per_cpu_trap_init(void) set_c0_cause(CAUSEF_IV); } - /* - * Before R2 both interrupt numbers were fixed to 7, so on R2 only: - * - * o read IntCtl.IPTI to determine the timer interrupt - * o read IntCtl.IPPCI to determine the performance counter interrupt - */ - if (cpu_has_mips_r2) { - cp0_compare_irq = (read_c0_intctl() >> 29) & 7; - cp0_perfcount_irq = (read_c0_intctl() >> 26) & 7; - if (cp0_perfcount_irq == cp0_compare_irq) - cp0_perfcount_irq = -1; - } else { - cp0_compare_irq = CP0_LEGACY_COMPARE_IRQ; + /* Set up timer & performance counter interrupts */ + cp0_compare_irq = get_c0_compare_int(); + cp0_perfcount_irq = get_c0_perfcount_int(); + if (cp0_perfcount_irq == cp0_compare_irq) cp0_perfcount_irq = -1; - } #ifdef CONFIG_MIPS_MT_SMTC } diff --git a/include/asm-mips/time.h b/include/asm-mips/time.h index 7717934..be0d157 100644 --- a/include/asm-mips/time.h +++ b/include/asm-mips/time.h @@ -59,7 +59,8 @@ extern int (*perf_irq)(void); */ #ifdef CONFIG_CEVT_R4K extern int mips_clockevent_init(void); -extern unsigned int __weak get_c0_compare_int(void); +extern unsigned int get_c0_compare_int(void); +extern unsigned int get_c0_perfcount_int(void); #else static inline int mips_clockevent_init(void) { -- 1.5.3.6 From thomas.koeller@baslerweb.com Tue Dec 18 00:33:35 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 18 Dec 2007 00:33:44 +0000 (GMT) Received: from mx02.hansenet.de ([213.191.73.26]:6598 "EHLO webmail.hansenet.de") by ftp.linux-mips.org with ESMTP id S28577075AbXLRAc1 (ORCPT ); Tue, 18 Dec 2007 00:32:27 +0000 Received: from [213.39.184.147] (213.39.184.147) by webmail.hansenet.de (7.3.118.12) (authenticated as mbx20228207@koeller-hh.org) id 4766ADD8000AB811; Tue, 18 Dec 2007 01:31:46 +0100 Received: from localhost.koeller.dyndns.org (localhost.koeller.dyndns.org [127.0.0.1]) by mail.koeller.dyndns.org (Postfix) with ESMTP id D487347C0F; Tue, 18 Dec 2007 01:31:40 +0100 (CET) From: Thomas Koeller Date: Tue, 18 Dec 2007 01:27:07 +0100 Subject: [PATCH 4/4] excite: Supply platform-specific compare and performance timer interrupts X-Length: 1010 X-UID: 21 To: linux-mips@linux-mips.org Cc: ralf@linux-mips.org MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <20071218003140.D487347C0F@mail.koeller.dyndns.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: 17845 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: thomas.koeller@baslerweb.com Precedence: bulk X-list: linux-mips As the eXcite platform uses the alternate RM9000 compare interrupt, it must supply a platform-specific irq value. The performance counter is currently unused. Signed-off-by: Thomas Koeller diff --git a/arch/mips/basler/excite/excite_setup.c b/arch/mips/basler/excite/excite_setup.c index 6dd8f0d..a91309f 100644 --- a/arch/mips/basler/excite/excite_setup.c +++ b/arch/mips/basler/excite/excite_setup.c @@ -85,6 +85,18 @@ void __init plat_time_init(void) mips_hpt_frequency = EXCITE_CPU_EXT_CLOCK * mult / div / 2; } +unsigned int __init +get_c0_compare_int(void) +{ + return 12; +} + +unsigned int __init +get_c0_perfcounter_int(void) +{ + return -1; +} + static int __init excite_init_console(void) { #if defined(CONFIG_SERIAL_8250) -- 1.5.3.6 From thomas.koeller@baslerweb.com Tue Dec 18 00:35:16 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 18 Dec 2007 00:35:25 +0000 (GMT) Received: from mx01.hansenet.de ([213.191.73.25]:21634 "EHLO webmail.hansenet.de") by ftp.linux-mips.org with ESMTP id S28577085AbXLRAfQ (ORCPT ); Tue, 18 Dec 2007 00:35:16 +0000 Received: from [213.39.184.147] (213.39.184.147) by webmail.hansenet.de (7.3.118.12) (authenticated as mbx20228207@koeller-hh.org) id 4761398E00AECD10; Tue, 18 Dec 2007 01:31:47 +0100 Received: from localhost.koeller.dyndns.org (localhost.koeller.dyndns.org [127.0.0.1]) by mail.koeller.dyndns.org (Postfix) with ESMTP id 4415847A63; Tue, 18 Dec 2007 01:31:40 +0100 (CET) From: Thomas Koeller Date: Tue, 18 Dec 2007 01:26:19 +0100 Subject: [PATCH 1/4] Introduced GPI_RM9000 configuration parameter X-Length: 809 X-UID: 18 To: linux-mips@linux-mips.org Cc: ralf@linux-mips.org MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <20071218003140.4415847A63@mail.koeller.dyndns.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: 17846 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: thomas.koeller@baslerweb.com Precedence: bulk X-list: linux-mips Signed-off-by: Thomas Koeller diff --git a/arch/mips/Kconfig b/arch/mips/Kconfig index c6fc405..62bc553 100644 --- a/arch/mips/Kconfig +++ b/arch/mips/Kconfig @@ -856,6 +856,9 @@ config GENERIC_ISA_DMA_SUPPORT_BROKEN config GENERIC_GPIO bool +config GPI_RM9000 + bool + # # Endianess selection. Sufficiently obscure so many users don't know what to # answer,so we try hard to limit the available choices. Also the use of a @@ -927,6 +930,7 @@ config MIPS_TX3927 config MIPS_RM9122 bool select SERIAL_RM9000 + select GPI_RM9000 config PNX8550 bool -- 1.5.3.6 From jgarzik@pobox.com Tue Dec 18 01:18:44 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 18 Dec 2007 01:18:52 +0000 (GMT) Received: from srv5.dvmed.net ([207.36.208.214]:4571 "EHLO mail.dvmed.net") by ftp.linux-mips.org with ESMTP id S20036299AbXLRBSo (ORCPT ); Tue, 18 Dec 2007 01:18:44 +0000 Received: from cpe-069-134-071-233.nc.res.rr.com ([69.134.71.233] helo=core.yyz.us) by mail.dvmed.net with esmtpsa (Exim 4.63 #1 (Red Hat Linux)) id 1J4R6W-0003rx-4a; Tue, 18 Dec 2007 01:18:40 +0000 Message-ID: <47671FEE.90103@pobox.com> Date: Mon, 17 Dec 2007 20:18:38 -0500 From: Jeff Garzik User-Agent: Thunderbird 2.0.0.9 (X11/20071115) MIME-Version: 1.0 To: Thomas Bogendoerfer CC: netdev@vger.kernel.org, linux-mips@linux-mips.org, ralf@linux-mips.org Subject: Re: [UPDATED PATCH] SGISEEQ: use cached memory access to make driver work on IP28 References: <20071202103312.75E51C2EB5@solo.franken.de> In-Reply-To: <20071202103312.75E51C2EB5@solo.franken.de> 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: 17847 X-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 Thomas Bogendoerfer wrote: > SGI IP28 machines would need special treatment (enable adding addtional > wait states) when accessing memory uncached. To avoid this pain I changed > the driver to use only cached access to memory. > > Signed-off-by: Thomas Bogendoerfer > --- > > Changes to last version: > - Use inline functions for dma_sync_* instead of macros (suggested by Ralf) > - added Kconfig change to make selection for similair SGI boxes easier hrm, could you rediff? it doesn't seem to apply From tsbogend@alpha.franken.de Tue Dec 18 10:30:18 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 18 Dec 2007 10:30:27 +0000 (GMT) Received: from elvis.franken.de ([193.175.24.41]:14740 "EHLO elvis.franken.de") by ftp.linux-mips.org with ESMTP id S28578256AbXLRKaS (ORCPT ); Tue, 18 Dec 2007 10:30:18 +0000 Received: from uucp (helo=solo.franken.de) by elvis.franken.de with local-bsmtp (Exim 3.36 #1) id 1J4ZiI-00075G-00; Tue, 18 Dec 2007 11:30:14 +0100 Received: by solo.franken.de (Postfix, from userid 1000) id E9764E3030; Tue, 18 Dec 2007 11:30:06 +0100 (CET) Date: Tue, 18 Dec 2007 11:30:06 +0100 To: Jeff Garzik Cc: netdev@vger.kernel.org, linux-mips@linux-mips.org, ralf@linux-mips.org Subject: Re: [UPDATED PATCH] SGISEEQ: use cached memory access to make driver work on IP28 Message-ID: <20071218103006.GA18598@alpha.franken.de> References: <20071202103312.75E51C2EB5@solo.franken.de> <47671FEE.90103@pobox.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <47671FEE.90103@pobox.com> User-Agent: Mutt/1.5.13 (2006-08-11) From: tsbogend@alpha.franken.de (Thomas Bogendoerfer) Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 17848 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: tsbogend@alpha.franken.de Precedence: bulk X-list: linux-mips On Mon, Dec 17, 2007 at 08:18:38PM -0500, Jeff Garzik wrote: > >Changes to last version: > >- Use inline functions for dma_sync_* instead of macros (suggested by Ralf) > >- added Kconfig change to make selection for similair SGI boxes easier > > hrm, could you rediff? it doesn't seem to apply sure, against which tree ? I tried netdev-2.6 and it applies without fuzz... Thomas. -- Crap can work. Given enough thrust pigs will fly, but it's not necessary a good idea. [ RFC1925, 2.3 ] From ralf@linux-mips.org Tue Dec 18 10:54:08 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 18 Dec 2007 10:54:10 +0000 (GMT) Received: from localhost.localdomain ([127.0.0.1]:25995 "EHLO dl5rb.ham-radio-op.net") by ftp.linux-mips.org with ESMTP id S28578333AbXLRKyI (ORCPT ); Tue, 18 Dec 2007 10:54:08 +0000 Received: from denk.linux-mips.net (denk.linux-mips.net [127.0.0.1]) by dl5rb.ham-radio-op.net (8.14.1/8.13.8) with ESMTP id lBIAmxgN019554; Tue, 18 Dec 2007 10:49:24 GMT Received: (from ralf@localhost) by denk.linux-mips.net (8.14.1/8.14.1/Submit) id lBIAmYqq019552; Tue, 18 Dec 2007 11:48:34 +0100 Date: Tue, 18 Dec 2007 11:48:34 +0100 From: Ralf Baechle To: Thomas Koeller Cc: linux-mips@linux-mips.org Subject: Re: timer irq setup Message-ID: <20071218104834.GA19316@linux-mips.org> References: <200712171135.24569.thomas@koeller.dyndns.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200712171135.24569.thomas@koeller.dyndns.org> User-Agent: Mutt/1.5.17 (2007-11-01) Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 17849 X-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 17, 2007 at 11:35:22AM +0100, Thomas Koeller wrote: > In arch/mips/kernel/traps.c, per_cpu_trap_init() contains > code to set up the global cp0_compare_irq variable. Does > this make sense? I'd say that either the irq setup should > be moved to trap_init(), or cp0_compare_irq should be > changed to a per-cpu variable, depending on what the original > intention was. Technically it would be legal to route the timer interrupt to a different interrupt for each of possibly multiple processors, that's why it's done in per_cpu_trap_init(). Obviously the rest of the code isn't quite there and also to best of my knowledge all actual implementations use the same interrupt across all cores. So something like a global variable and a paranoia check in per_cpu_trap_init() to ensure all CPUs really use the same interrupt would seem reasonable. Ralf From ralf@linux-mips.org Tue Dec 18 10:58:13 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 18 Dec 2007 10:58:16 +0000 (GMT) Received: from localhost.localdomain ([127.0.0.1]:42372 "EHLO dl5rb.ham-radio-op.net") by ftp.linux-mips.org with ESMTP id S28578333AbXLRK6N (ORCPT ); Tue, 18 Dec 2007 10:58:13 +0000 Received: from denk.linux-mips.net (denk.linux-mips.net [127.0.0.1]) by dl5rb.ham-radio-op.net (8.14.1/8.13.8) with ESMTP id lBIArJ6q019666; Tue, 18 Dec 2007 10:53:50 GMT Received: (from ralf@localhost) by denk.linux-mips.net (8.14.1/8.14.1/Submit) id lBIAqs5g019664; Tue, 18 Dec 2007 11:52:54 +0100 Date: Tue, 18 Dec 2007 11:52:54 +0100 From: Ralf Baechle To: Thomas Koeller Cc: linux-mips@linux-mips.org Subject: Re: [PATCH 1/4] Introduced GPI_RM9000 configuration parameter Message-ID: <20071218105254.GA13344@linux-mips.org> References: <20071218003140.4415847A63@mail.koeller.dyndns.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20071218003140.4415847A63@mail.koeller.dyndns.org> User-Agent: Mutt/1.5.17 (2007-11-01) Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 17850 X-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 18, 2007 at 01:26:19AM +0100, Thomas Koeller wrote: > diff --git a/arch/mips/Kconfig b/arch/mips/Kconfig > index c6fc405..62bc553 100644 > --- a/arch/mips/Kconfig > +++ b/arch/mips/Kconfig > @@ -856,6 +856,9 @@ config GENERIC_ISA_DMA_SUPPORT_BROKEN > config GENERIC_GPIO > bool > > +config GPI_RM9000 > + bool > + > # > # Endianess selection. Sufficiently obscure so many users don't know what to > # answer,so we try hard to limit the available choices. Also the use of a > @@ -927,6 +930,7 @@ config MIPS_TX3927 > config MIPS_RM9122 > bool > select SERIAL_RM9000 > + select GPI_RM9000 See my earlier reply to http://www.linux-mips.org/cgi-bin/mesg.cgi?a=linux-mips&i=20070911122005.GC24679%40linux-mips.org Technically the patch is ok but please only introduce new config symbols only together with an actual user. Ralf From jon.dufresne@infinitevideocorporation.com Tue Dec 18 18:12:44 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 18 Dec 2007 18:12:52 +0000 (GMT) Received: from host.infinivid.com ([64.119.179.76]:38635 "EHLO host.infinivid.com") by ftp.linux-mips.org with ESMTP id S28579654AbXLRSMo (ORCPT ); Tue, 18 Dec 2007 18:12:44 +0000 Received: (qmail 11549 invoked from network); 18 Dec 2007 18:11:41 -0000 Received: from c-76-17-127-170.hsd1.ga.comcast.net (HELO ?10.41.13.3?) (76.17.127.170) by host.infinivid.com with (RC4-MD5 encrypted) SMTP; 18 Dec 2007 11:11:41 -0700 Subject: Re: PCI resource unavailable on mips From: Jon Dufresne To: Sergei Shtylyov Cc: Ralf Baechle , linux-kernel@vger.kernel.org, linux-mips@linux-mips.org In-Reply-To: <476699FA.5050606@ru.mvista.com> References: <1197557806.3370.7.camel@microwave.infinitevideocorporation.com> <20071214093945.GA25186@linux-mips.org> <1197666735.3800.1.camel@microwave.infinitevideocorporation.com> <20071216224617.GA18613@linux-mips.org> <1197904591.3351.5.camel@microwave.infinitevideocorporation.com> <476699FA.5050606@ru.mvista.com> Content-Type: text/plain Date: Tue, 18 Dec 2007 13:11:10 -0500 Message-Id: <1198001470.3382.8.camel@microwave.infinitevideocorporation.com> Mime-Version: 1.0 X-Mailer: Evolution 2.8.3 (2.8.3-2.fc6) 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: 17851 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: jon.dufresne@infinitevideocorporation.com Precedence: bulk X-list: linux-mips > Your example doesn't make sense to me so far. Ok, I simplified my driver down to one small C file that does exactly what I want, and that is it. Below is my driver under "driver.c" and the user space program I am using to access it under "user-test.c". When I insmod this driver under mips, it correctly prints out the PCI config space by accessing it through the chip's mmio (which is provided by BAR1), using the offset 0x00040000 as described in the technical manual. This works correctly. This is the block of memory you see printed out in the dmesg below. When I run the user space program, however, I try to print out the same data through the mmap. This causes a Bus Error which I put the output of below. I am very confused by this. I can read the memory in kernel space, but not user space. This driver works as expected under x86, which only confuses me further. Any ideas what I am doing wrong? I've been starring at this for quite some time. Please feel free to give me any and all critiques on my code, it will only help towards solving this problem. Thanks for the help! ------driver.c---------- #include #include #include #include #define MODULE_NAME "tmexp" #define PCI_DEVICE_ID_PHILIPS_PNX1700 0x5406 #define MMIO_PCI_BASE 0x00040000 static int pnx1700_mmap(struct file *filp, struct vm_area_struct *vma); static int pnx1700_probe(struct pci_dev *dev, const struct pci_device_id *id); static void pnx1700_remove(struct pci_dev *dev); struct pnx1700 { dev_t devno; struct cdev cdev; struct pci_dev *pci_dev; void __iomem *mmio; }; struct pnx1700 tmexp; static struct pci_device_id pnx1700_ids[] = { { PCI_DEVICE(PCI_VENDOR_ID_PHILIPS, PCI_DEVICE_ID_PHILIPS_PNX1700) }, { 0, } }; static struct pci_driver pnx1700_pci_driver = { .name = MODULE_NAME, .id_table = pnx1700_ids, .probe = pnx1700_probe, .remove = pnx1700_remove, }; static struct file_operations pnx1700_fops = { .owner = THIS_MODULE, .mmap = pnx1700_mmap, }; static int pnx1700_mmap(struct file *filp, struct vm_area_struct *vma) { unsigned long off = vma->vm_pgoff << PAGE_SHIFT; unsigned long physical = pci_resource_start(tmexp.pci_dev, 1) + off; unsigned long vsize = vma->vm_end - vma->vm_start; unsigned long psize = pci_resource_len(tmexp.pci_dev, 1) - off; BUG_ON(vsize > psize); return io_remap_pfn_range(vma, vma->vm_start, physical >> PAGE_SHIFT, vsize, vma->vm_page_prot); } static void dump_pci_mmio(void __iomem *mmio) { int i; u8 mem[16]; for(i = 0; i < 0x100; i += 0x10) { memcpy_fromio(mem, mmio + MMIO_PCI_BASE + 0x40 + i, 16); printk("%02x: %02x %02x %02x %02x %02x %02x %02x %02x %02x %02x %02x % 02x %02x %02x %02x %02x\n", i, mem[0], mem[1], mem[2], mem[3], mem[4], mem[5], mem[6], mem[7], mem[8], mem[9], mem[10], mem[11], mem[12], mem[13], mem[14], mem[15]); } } static int pnx1700_probe(struct pci_dev *dev, const struct pci_device_id *id) { int err; struct resource *resource; unsigned long start = pci_resource_start(dev, 1); unsigned long len = pci_resource_len(dev, 1); tmexp.pci_dev = dev; err = pci_enable_device(dev); BUG_ON(err); err = pci_enable_device_bars(dev, 0x7); BUG_ON(err); resource = request_mem_region(start, len, MODULE_NAME); BUG_ON(!resource); tmexp.mmio = ioremap(start, len); BUG_ON(!tmexp.mmio); dump_pci_mmio(tmexp.mmio); return 0; } static void pnx1700_remove(struct pci_dev *dev) { unsigned long start = pci_resource_start(dev, 1); unsigned long len = pci_resource_len(dev, 1); iounmap(tmexp.mmio); release_mem_region(start, len); } static int __init tmexp_init(void) { int err; memset(&tmexp, 0, sizeof(struct pnx1700)); err = pci_register_driver(&pnx1700_pci_driver); BUG_ON(err); alloc_chrdev_region(&tmexp.devno, 0, 1, MODULE_NAME); cdev_init(&tmexp.cdev, &pnx1700_fops); tmexp.cdev.owner = THIS_MODULE; err = cdev_add(&tmexp.cdev, tmexp.devno, 1); BUG_ON(err); return 0; } static void __exit tmexp_exit(void) { cdev_del(&tmexp.cdev); unregister_chrdev_region(tmexp.devno, 1); pci_unregister_driver(&pnx1700_pci_driver); } module_init(tmexp_init); module_exit(tmexp_exit); ---------------- -------user-test.c---------- #include #include #include #include #include #include #define PCI_MMIO_BASE (0x00040000) static void dump_mem(void const *src, int offset, int size); static void sanity_check(void const *mmio); int main(int argc, char *argv[]) { int fd; void *mmio; fd = open("/dev/pnx1700", O_RDWR); mmio = mmap(0, 0x00200000, PROT_READ | PROT_WRITE, MAP_SHARED, fd, 0); printf("stuff mapped ready to test\n"); sanity_check(mmio); dump_mem(mmio, PCI_MMIO_BASE + 0x40, 0x100); munmap(mmio, 0x00200000); close(fd); return 0; } static void dump_mem(void const *src, int offset, int size) { int i; unsigned char mem[16]; for(i = 0; i < size; i += 0x10) { memcpy(mem, src + offset + i, 16); printf("%02x: %02x %02x %02x %02x %02x %02x %02x %02x %02x %02x %02x % 02x %02x %02x %02x %02x\n", i, mem[0], mem[1], mem[2], mem[3], mem[4], mem[5], mem[6], mem[7], mem[8], mem[9], mem[10], mem[11], mem[12], mem[13], mem[14], mem[15]); } } static void sanity_check(void const *mmio) { uint32_t dword; dword = *((uint32_t *)(mmio + PCI_MMIO_BASE + 0x40)); printf("dword=0x%x\n", dword); } ------------- -----output----- # ./load_driver PCI: Enabling device 0000:00:0c.0 (0000 -> 0002) 00: 31 11 06 54 02 00 90 82 00 00 80 04 00 00 00 00 10: 08 00 00 20 00 00 00 24 00 00 00 1c 00 00 00 00 20: 00 00 00 00 00 00 00 00 00 00 00 00 36 11 17 00 30: 00 00 00 00 40 00 00 00 00 00 00 00 00 01 09 18 40: 01 00 02 00 00 00 00 00 00 00 00 00 03 02 07 00 50: 06 18 00 00 00 00 00 00 00 00 00 00 00 00 00 00 60: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 70: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 90: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 10.41.1.162 # ./user-test stuff mapped reaData bus error, epc == 00400a24, ra == 004007f4 dy to test Bus error 10.41.1.162 # dmesg <4>PCI: Enabling device 0000:00:0c.0 (0000 -> 0002) <4>00: 31 11 06 54 02 00 90 82 00 00 80 04 00 00 00 00 <4>10: 08 00 00 20 00 00 00 24 00 00 00 1c 00 00 00 00 <4>20: 00 00 00 00 00 00 00 00 00 00 00 00 36 11 17 00 <4>30: 00 00 00 00 40 00 00 00 00 00 00 00 00 01 09 18 <4>40: 01 00 02 00 00 00 00 00 00 00 00 00 03 02 07 00 <4>50: 06 18 00 00 00 00 00 00 00 00 00 00 00 00 00 00 <4>60: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 <4>70: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 <4>80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 <4>90: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 <4>a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 <4>b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 <4>c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 <4>d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 <4>e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 <4>f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 <1>Data bus error, epc == 00400a24, ra == 004007f4 ----------- From jon.dufresne@infinitevideocorporation.com Tue Dec 18 18:41:16 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 18 Dec 2007 18:41:25 +0000 (GMT) Received: from host.infinivid.com ([64.119.179.76]:21383 "EHLO host.infinivid.com") by ftp.linux-mips.org with ESMTP id S28579772AbXLRSlQ (ORCPT ); Tue, 18 Dec 2007 18:41:16 +0000 Received: (qmail 25667 invoked from network); 18 Dec 2007 18:41:15 -0000 Received: from c-76-17-127-170.hsd1.ga.comcast.net (HELO ?10.41.13.3?) (76.17.127.170) by host.infinivid.com with (RC4-MD5 encrypted) SMTP; 18 Dec 2007 11:41:14 -0700 Subject: Re: PCI resource unavailable on mips From: Jon Dufresne To: Robert Hancock Cc: linux-kernel@vger.kernel.org, linux-mips In-Reply-To: <4761C26C.3010708@shaw.ca> References: <4761C26C.3010708@shaw.ca> Content-Type: text/plain Date: Tue, 18 Dec 2007 13:40:43 -0500 Message-Id: <1198003243.3382.11.camel@microwave.infinitevideocorporation.com> Mime-Version: 1.0 X-Mailer: Evolution 2.8.3 (2.8.3-2.fc6) 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: 17852 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: jon.dufresne@infinitevideocorporation.com Precedence: bulk X-list: linux-mips > > Bar0:PHYS=e0000000 LEN=04000000 > > Bar1:PHYS=efa00000 LEN=00200000 > > Bar2:PHYS=e8000000 LEN=04000000 > > So, two 64MB BARs and a 2MB one? That is right. > Any PCI resource allocation errors in dmesg during the boot process? > Could be the kernel wasn't able to find a place to map all of the BARs. > I went back and looked at the boot up messages and I found this: PCI: Failed to allocate mem resource #2:4000000@24000000 for 0000:00:0c.0 That is my device. So it does appear that there is an allocation issue. Any idea how to get around this? Thanks, Jon From alon.barlev@gmail.com Tue Dec 18 20:08:22 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 18 Dec 2007 20:08:31 +0000 (GMT) Received: from ug-out-1314.google.com ([66.249.92.171]:12449 "EHLO ug-out-1314.google.com") by ftp.linux-mips.org with ESMTP id S28580084AbXLRUIW (ORCPT ); Tue, 18 Dec 2007 20:08:22 +0000 Received: by ug-out-1314.google.com with SMTP id k3so185413ugf.38 for ; Tue, 18 Dec 2007 12:08:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; bh=3jyUfH+bAthU59RUNytI0o9Lyld5Eoq7wbaXHZqYonM=; b=xrhw4BfK8JT+IVK9bY2tyFPABFSpnVEZC9pNwm7uWDO4ZK8w70jd0ZXzi8GQIk11wT/Zniyf/zSrTi4/9KFM8tPKf/aVkqUzNEyfBYtzRwGUsKXk3us9+MhrFP4+VoYWQEGgl6Xjipmn0oHM927MsBtxsbf+a85Lu6J0pGyDcR4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; b=DKcVFpoirmGLyqtO90p3XFuWXDXzwuxGN53Q42WLqzRzJ7++Tv5Gt9f1flH59dV7cqqCU2sBFCbKzwu8/ocVTml1t0uE/Jz0TVU5HXxhWXtVgkX2nRrS2CX3ENjGKesE3znMHrM/8AQ4UUVKRoQMeLfUR1151ZgPAfflS8EoJPc= Received: by 10.67.22.2 with SMTP id z2mr1293517ugi.1.1198008492559; Tue, 18 Dec 2007 12:08:12 -0800 (PST) Received: by 10.67.117.17 with HTTP; Tue, 18 Dec 2007 12:08:12 -0800 (PST) Message-ID: <9e0cf0bf0712181208m7f16b9acpf3dba67f3556a613@mail.gmail.com> Date: Tue, 18 Dec 2007 22:08:12 +0200 From: "Alon Bar-Lev" To: linux-mips@ftp.linux-mips.org, LKML Subject: [MIPS] Build an embedded initramfs into mips kernel MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 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@ftp.linux-mips.org Original-Recipient: rfc822;linux-mips@ftp.linux-mips.org X-archive-position: 17853 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: alon.barlev@gmail.com Precedence: bulk X-list: linux-mips Hello, I am trying to build a basic initramfs image into the kernel, using the CONFIG_INITRAMFS_SOURCE. The required result is a single image loaded into a target containing usermode application (busybox). I use cross compile mipsel-unknown-linux-uclibc in order to build the kernel and the initramfs's usermode. The cpio image is created using cpio -o -H newc command. The same configuration works with i586-pc-linux-uclibc cross compile. printk at init/main.c::run_init_process() shows that the kernel_execve() returns -2 (ENOENT) for /init and -14 (EFAULT) for /*/init. Looking at the initramfs /init is available and executable. Any reason why I get ENOENT? Any special procedure should be performed for mips arch? Best Regards, Alon Bar-Lev. From hpa@zytor.com Tue Dec 18 21:33:33 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 18 Dec 2007 21:33:41 +0000 (GMT) Received: from terminus.zytor.com ([198.137.202.10]:20121 "EHLO terminus.zytor.com") by ftp.linux-mips.org with ESMTP id S28580302AbXLRVdd (ORCPT ); Tue, 18 Dec 2007 21:33:33 +0000 Received: from mail.hos.anvin.org (c-67-169-144-158.hsd1.ca.comcast.net [67.169.144.158]) (authenticated bits=0) by terminus.zytor.com (8.14.1/8.13.8) with ESMTP id lBILRBar008837 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 18 Dec 2007 13:27:12 -0800 Received: from tazenda.hos.anvin.org (tazenda.hos.anvin.org [172.27.0.16]) by mail.hos.anvin.org (8.13.8/8.13.8) with ESMTP id lBILRBSI007055; Tue, 18 Dec 2007 13:27:11 -0800 Received: from tazenda.hos.anvin.org (localhost.localdomain [127.0.0.1]) by tazenda.hos.anvin.org (8.14.1/8.13.6) with ESMTP id lBILRAQq032006; Tue, 18 Dec 2007 13:27:10 -0800 Message-ID: <47683B2D.9030608@zytor.com> Date: Tue, 18 Dec 2007 13:27:09 -0800 From: "H. Peter Anvin" User-Agent: Thunderbird 2.0.0.9 (X11/20071115) MIME-Version: 1.0 To: Alon Bar-Lev CC: linux-mips@ftp.linux-mips.org, LKML Subject: Re: [MIPS] Build an embedded initramfs into mips kernel References: <9e0cf0bf0712181208m7f16b9acpf3dba67f3556a613@mail.gmail.com> In-Reply-To: <9e0cf0bf0712181208m7f16b9acpf3dba67f3556a613@mail.gmail.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.91.2/5174/Tue Dec 18 11:07:58 2007 on terminus.zytor.com X-Virus-Status: Clean Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@ftp.linux-mips.org Original-Recipient: rfc822;linux-mips@ftp.linux-mips.org X-archive-position: 17854 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: hpa@zytor.com Precedence: bulk X-list: linux-mips Alon Bar-Lev wrote: > Hello, > > I am trying to build a basic initramfs image into the kernel, using > the CONFIG_INITRAMFS_SOURCE. The required result is a single image > loaded into a target containing usermode application (busybox). > > I use cross compile mipsel-unknown-linux-uclibc in order to build the > kernel and the initramfs's usermode. > > The cpio image is created using cpio -o -H newc command. > > The same configuration works with i586-pc-linux-uclibc cross compile. > > printk at init/main.c::run_init_process() shows that the > kernel_execve() returns -2 (ENOENT) for /init and -14 (EFAULT) for > /*/init. > > Looking at the initramfs /init is available and executable. > > Any reason why I get ENOENT? > Any special procedure should be performed for mips arch? > Make sure your /init doesn't depend on an interpreter or library which isn't available. -hpa From alon.barlev@gmail.com Tue Dec 18 22:09:56 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 18 Dec 2007 22:10:05 +0000 (GMT) Received: from ug-out-1314.google.com ([66.249.92.172]:5146 "EHLO ug-out-1314.google.com") by ftp.linux-mips.org with ESMTP id S28580325AbXLRWJ4 (ORCPT ); Tue, 18 Dec 2007 22:09:56 +0000 Received: by ug-out-1314.google.com with SMTP id k3so202142ugf.38 for ; Tue, 18 Dec 2007 14:09:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=JSpWUxCL5Ip8VogZEgs1d4hb2dNiymmevDkgDqIVeio=; b=pnlgLm9VCGJUnDUTPodmic0D9VVECQok/VMtzHzQdWiTOZ2Xj7g4P8GRdqTw2gYk4uuJ3rE/xFOyF/zb0uYTRFeA1nIzk9EEqK4okbNRWMjYgXMWjs4Un6jmJGmebWnQvQMHSVGovF5GJCvsFL/i3HdulANGpt9yR0UTiB+Acnw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=kYZd/ISYIHXtam1u+5m984P6DJNMdJauDMyOTxifeajVzbOeYeIivEnqccS590lo0Omyv+vLvjBl7KLWqsqa4L4RvMHlCRBuivjC85dY0z46ilau5721cRtlYK2kVzQ2pr4X1PIppO8Yoa6H8K0zlvXLxVa/8KfO8PHs6388Zo0= Received: by 10.66.255.7 with SMTP id c7mr919600ugi.43.1198015786337; Tue, 18 Dec 2007 14:09:46 -0800 (PST) Received: by 10.67.117.17 with HTTP; Tue, 18 Dec 2007 14:09:46 -0800 (PST) Message-ID: <9e0cf0bf0712181409p2475e1fdk779fdee4fa274722@mail.gmail.com> Date: Wed, 19 Dec 2007 00:09:46 +0200 From: "Alon Bar-Lev" To: "H. Peter Anvin" Subject: Re: [MIPS] Build an embedded initramfs into mips kernel Cc: linux-mips@ftp.linux-mips.org, LKML In-Reply-To: <47683B2D.9030608@zytor.com> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <9e0cf0bf0712181208m7f16b9acpf3dba67f3556a613@mail.gmail.com> <47683B2D.9030608@zytor.com> Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@ftp.linux-mips.org Original-Recipient: rfc822;linux-mips@ftp.linux-mips.org X-archive-position: 17855 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: alon.barlev@gmail.com Precedence: bulk X-list: linux-mips On 12/18/07, H. Peter Anvin wrote: > Make sure your /init doesn't depend on an interpreter or library which > isn't available. Thank you for your answer. I already checked. /init is hardlink to busybox, it depends on libc.so.0 which is available at /lib But shouldn't I get a different error code if this is the case? Best Regards, Alon Bar-Lev. From hpa@zytor.com Tue Dec 18 22:17:59 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 18 Dec 2007 22:18:08 +0000 (GMT) Received: from terminus.zytor.com ([198.137.202.10]:32139 "EHLO terminus.zytor.com") by ftp.linux-mips.org with ESMTP id S28580313AbXLRWR7 (ORCPT ); Tue, 18 Dec 2007 22:17:59 +0000 Received: from mail.hos.anvin.org (c-67-169-144-158.hsd1.ca.comcast.net [67.169.144.158]) (authenticated bits=0) by terminus.zytor.com (8.14.1/8.13.8) with ESMTP id lBIMBdXJ017120 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 18 Dec 2007 14:11:39 -0800 Received: from tazenda.hos.anvin.org (tazenda.hos.anvin.org [172.27.0.16]) by mail.hos.anvin.org (8.13.8/8.13.8) with ESMTP id lBIMBdeo007385; Tue, 18 Dec 2007 14:11:39 -0800 Received: from tazenda.hos.anvin.org (localhost.localdomain [127.0.0.1]) by tazenda.hos.anvin.org (8.14.1/8.13.6) with ESMTP id lBIMBcf1001679; Tue, 18 Dec 2007 14:11:38 -0800 Message-ID: <4768459A.3000003@zytor.com> Date: Tue, 18 Dec 2007 14:11:38 -0800 From: "H. Peter Anvin" User-Agent: Thunderbird 2.0.0.9 (X11/20071115) MIME-Version: 1.0 To: Alon Bar-Lev CC: linux-mips@ftp.linux-mips.org, LKML Subject: Re: [MIPS] Build an embedded initramfs into mips kernel References: <9e0cf0bf0712181208m7f16b9acpf3dba67f3556a613@mail.gmail.com> <47683B2D.9030608@zytor.com> <9e0cf0bf0712181409p2475e1fdk779fdee4fa274722@mail.gmail.com> In-Reply-To: <9e0cf0bf0712181409p2475e1fdk779fdee4fa274722@mail.gmail.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.91.2/5174/Tue Dec 18 11:07:58 2007 on terminus.zytor.com X-Virus-Status: Clean Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@ftp.linux-mips.org Original-Recipient: rfc822;linux-mips@ftp.linux-mips.org X-archive-position: 17856 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: hpa@zytor.com Precedence: bulk X-list: linux-mips Alon Bar-Lev wrote: > On 12/18/07, H. Peter Anvin wrote: >> Make sure your /init doesn't depend on an interpreter or library which >> isn't available. > > Thank you for your answer. > > I already checked. > > /init is hardlink to busybox, it depends on libc.so.0 which is available at /lib > > But shouldn't I get a different error code if this is the case? Don't think so. -hpa From w@1wt.eu Tue Dec 18 22:50:15 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 18 Dec 2007 22:50:22 +0000 (GMT) Received: from 1wt.eu ([62.212.114.60]:55050 "EHLO 1wt.eu") by ftp.linux-mips.org with ESMTP id S28580378AbXLRWuP (ORCPT ); Tue, 18 Dec 2007 22:50:15 +0000 Date: Tue, 18 Dec 2007 23:47:03 +0100 From: Willy Tarreau To: Alon Bar-Lev Cc: "H. Peter Anvin" , linux-mips@ftp.linux-mips.org, LKML Subject: Re: [MIPS] Build an embedded initramfs into mips kernel Message-ID: <20071218224702.GI15227@1wt.eu> References: <9e0cf0bf0712181208m7f16b9acpf3dba67f3556a613@mail.gmail.com> <47683B2D.9030608@zytor.com> <9e0cf0bf0712181409p2475e1fdk779fdee4fa274722@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <9e0cf0bf0712181409p2475e1fdk779fdee4fa274722@mail.gmail.com> User-Agent: Mutt/1.5.11 Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@ftp.linux-mips.org Original-Recipient: rfc822;linux-mips@ftp.linux-mips.org X-archive-position: 17857 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: w@1wt.eu Precedence: bulk X-list: linux-mips On Wed, Dec 19, 2007 at 12:09:46AM +0200, Alon Bar-Lev wrote: > On 12/18/07, H. Peter Anvin wrote: > > Make sure your /init doesn't depend on an interpreter or library which > > isn't available. > > Thank you for your answer. > > I already checked. > > /init is hardlink to busybox, it depends on libc.so.0 which is available at /lib Are you sure that libc.so.0 is enough and that you don't need any ld.so ? > But shouldn't I get a different error code if this is the case? If it does not find part of the dynamic linker or libraries, this error makes sense to me. You should try to build a static init with any stupid thing such as a hello world to ensure that the problem really comes from the init and nothing else. Regards, Willy From jgarzik@pobox.com Wed Dec 19 00:38:22 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 19 Dec 2007 00:38:30 +0000 (GMT) Received: from srv5.dvmed.net ([207.36.208.214]:55949 "EHLO mail.dvmed.net") by ftp.linux-mips.org with ESMTP id S28575968AbXLSAiW (ORCPT ); Wed, 19 Dec 2007 00:38:22 +0000 Received: from cpe-069-134-071-233.nc.res.rr.com ([69.134.71.233] helo=core.yyz.us) by mail.dvmed.net with esmtpsa (Exim 4.63 #1 (Red Hat Linux)) id 1J4mwz-0007uV-S3; Wed, 19 Dec 2007 00:38:18 +0000 Message-ID: <476867F5.3070006@pobox.com> Date: Tue, 18 Dec 2007 19:38:13 -0500 From: Jeff Garzik User-Agent: Thunderbird 2.0.0.9 (X11/20071115) MIME-Version: 1.0 To: Thomas Bogendoerfer CC: netdev@vger.kernel.org, linux-mips@linux-mips.org, ralf@linux-mips.org Subject: Re: [UPDATED PATCH] SGISEEQ: use cached memory access to make driver work on IP28 References: <20071202103312.75E51C2EB5@solo.franken.de> <47671FEE.90103@pobox.com> <20071218103006.GA18598@alpha.franken.de> In-Reply-To: <20071218103006.GA18598@alpha.franken.de> 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: 17858 X-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 Thomas Bogendoerfer wrote: > On Mon, Dec 17, 2007 at 08:18:38PM -0500, Jeff Garzik wrote: >>> Changes to last version: >>> - Use inline functions for dma_sync_* instead of macros (suggested by Ralf) >>> - added Kconfig change to make selection for similair SGI boxes easier >> hrm, could you rediff? it doesn't seem to apply > > sure, against which tree ? I tried netdev-2.6 and it applies without fuzz... It needs to be the 'upstream' branch of netdev-2.6. The default netdev-2.6.git branch, master, is a 100% vanilla duplicate of Linus's git repository. (this permits a common practice of presenting logs and diffs using git's branch..branch notation) Jeff From tsbogend@alpha.franken.de Wed Dec 19 12:46:05 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 19 Dec 2007 12:46:14 +0000 (GMT) Received: from elvis.franken.de ([193.175.24.41]:23222 "EHLO elvis.franken.de") by ftp.linux-mips.org with ESMTP id S20024609AbXLSMqF (ORCPT ); Wed, 19 Dec 2007 12:46:05 +0000 Received: from uucp (helo=solo.franken.de) by elvis.franken.de with local-bsmtp (Exim 3.36 #1) id 1J4yGA-0005o9-00; Wed, 19 Dec 2007 13:42:50 +0100 Received: by solo.franken.de (Postfix, from userid 1000) id 2F7A0C2EE1; Wed, 19 Dec 2007 13:42:36 +0100 (CET) Date: Wed, 19 Dec 2007 13:42:36 +0100 To: Jeff Garzik Cc: netdev@vger.kernel.org, linux-mips@linux-mips.org, ralf@linux-mips.org Subject: Re: [UPDATED PATCH] SGISEEQ: use cached memory access to make driver work on IP28 Message-ID: <20071219124235.GA7550@alpha.franken.de> References: <20071202103312.75E51C2EB5@solo.franken.de> <47671FEE.90103@pobox.com> <20071218103006.GA18598@alpha.franken.de> <476867F5.3070006@pobox.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <476867F5.3070006@pobox.com> User-Agent: Mutt/1.5.13 (2006-08-11) From: tsbogend@alpha.franken.de (Thomas Bogendoerfer) Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 17859 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: tsbogend@alpha.franken.de Precedence: bulk X-list: linux-mips - Use inline functions for dma_sync_* instead of macros - added Kconfig change to make selection for similair SGI boxes easier Signed-off-by: Thomas Bogendoerfer --- drivers/net/Kconfig | 2 +- drivers/net/sgiseeq.c | 64 ++++++++++++++++++++++++++----------------------- 2 files changed, 35 insertions(+), 31 deletions(-) diff --git a/drivers/net/Kconfig b/drivers/net/Kconfig index 84df799..f816798 100644 --- a/drivers/net/Kconfig +++ b/drivers/net/Kconfig @@ -1807,7 +1807,7 @@ config DE620 config SGISEEQ tristate "SGI Seeq ethernet controller support" - depends on SGI_IP22 + depends on SGI_HAS_SEEQ help Say Y here if you have an Seeq based Ethernet network card. This is used in many Silicon Graphics machines. diff --git a/drivers/net/sgiseeq.c b/drivers/net/sgiseeq.c index 3145ca1..c69bb8b 100644 --- a/drivers/net/sgiseeq.c +++ b/drivers/net/sgiseeq.c @@ -56,14 +56,6 @@ static char *sgiseeqstr = "SGI Seeq8003"; (dma_addr_t)((unsigned long)(v) - \ (unsigned long)((sp)->rx_desc))) -#define DMA_SYNC_DESC_CPU(dev, addr) \ - do { dma_cache_sync((dev)->dev.parent, (void *)addr, \ - sizeof(struct sgiseeq_rx_desc), DMA_FROM_DEVICE); } while (0) - -#define DMA_SYNC_DESC_DEV(dev, addr) \ - do { dma_cache_sync((dev)->dev.parent, (void *)addr, \ - sizeof(struct sgiseeq_rx_desc), DMA_TO_DEVICE); } while (0) - /* Copy frames shorter than rx_copybreak, otherwise pass on up in * a full sized sk_buff. Value of 100 stolen from tulip.c (!alpha). */ @@ -116,6 +108,18 @@ struct sgiseeq_private { spinlock_t tx_lock; }; +static inline void dma_sync_desc_cpu(struct net_device *dev, void *addr) +{ + dma_cache_sync(dev->dev.parent, addr, sizeof(struct sgiseeq_rx_desc), + DMA_FROM_DEVICE); +} + +static inline void dma_sync_desc_dev(struct net_device *dev, void *addr) +{ + dma_cache_sync(dev->dev.parent, addr, sizeof(struct sgiseeq_rx_desc), + DMA_TO_DEVICE); +} + static inline void hpc3_eth_reset(struct hpc3_ethregs *hregs) { hregs->reset = HPC3_ERST_CRESET | HPC3_ERST_CLRIRQ; @@ -184,7 +188,7 @@ static int seeq_init_ring(struct net_device *dev) /* Setup tx ring. */ for(i = 0; i < SEEQ_TX_BUFFERS; i++) { sp->tx_desc[i].tdma.cntinfo = TCNTINFO_INIT; - DMA_SYNC_DESC_DEV(dev, &sp->tx_desc[i]); + dma_sync_desc_dev(dev, &sp->tx_desc[i]); } /* And now the rx ring. */ @@ -203,10 +207,10 @@ static int seeq_init_ring(struct net_device *dev) sp->rx_desc[i].rdma.pbuf = dma_addr; } sp->rx_desc[i].rdma.cntinfo = RCNTINFO_INIT; - DMA_SYNC_DESC_DEV(dev, &sp->rx_desc[i]); + dma_sync_desc_dev(dev, &sp->rx_desc[i]); } sp->rx_desc[i - 1].rdma.cntinfo |= HPCDMA_EOR; - DMA_SYNC_DESC_DEV(dev, &sp->rx_desc[i - 1]); + dma_sync_desc_dev(dev, &sp->rx_desc[i - 1]); return 0; } @@ -341,7 +345,7 @@ static inline void sgiseeq_rx(struct net_device *dev, struct sgiseeq_private *sp /* Service every received packet. */ rd = &sp->rx_desc[sp->rx_new]; - DMA_SYNC_DESC_CPU(dev, rd); + dma_sync_desc_cpu(dev, rd); while (!(rd->rdma.cntinfo & HPCDMA_OWN)) { len = PKT_BUF_SZ - (rd->rdma.cntinfo & HPCDMA_BCNT) - 3; dma_unmap_single(dev->dev.parent, rd->rdma.pbuf, @@ -397,16 +401,16 @@ memory_squeeze: /* Return the entry to the ring pool. */ rd->rdma.cntinfo = RCNTINFO_INIT; sp->rx_new = NEXT_RX(sp->rx_new); - DMA_SYNC_DESC_DEV(dev, rd); + dma_sync_desc_dev(dev, rd); rd = &sp->rx_desc[sp->rx_new]; - DMA_SYNC_DESC_CPU(dev, rd); + dma_sync_desc_cpu(dev, rd); } - DMA_SYNC_DESC_CPU(dev, &sp->rx_desc[orig_end]); + dma_sync_desc_cpu(dev, &sp->rx_desc[orig_end]); sp->rx_desc[orig_end].rdma.cntinfo &= ~(HPCDMA_EOR); - DMA_SYNC_DESC_DEV(dev, &sp->rx_desc[orig_end]); - DMA_SYNC_DESC_CPU(dev, &sp->rx_desc[PREV_RX(sp->rx_new)]); + dma_sync_desc_dev(dev, &sp->rx_desc[orig_end]); + dma_sync_desc_cpu(dev, &sp->rx_desc[PREV_RX(sp->rx_new)]); sp->rx_desc[PREV_RX(sp->rx_new)].rdma.cntinfo |= HPCDMA_EOR; - DMA_SYNC_DESC_DEV(dev, &sp->rx_desc[PREV_RX(sp->rx_new)]); + dma_sync_desc_dev(dev, &sp->rx_desc[PREV_RX(sp->rx_new)]); rx_maybe_restart(sp, hregs, sregs); } @@ -433,12 +437,12 @@ static inline void kick_tx(struct net_device *dev, * is not active! */ td = &sp->tx_desc[i]; - DMA_SYNC_DESC_CPU(dev, td); + dma_sync_desc_cpu(dev, td); while ((td->tdma.cntinfo & (HPCDMA_XIU | HPCDMA_ETXD)) == (HPCDMA_XIU | HPCDMA_ETXD)) { i = NEXT_TX(i); td = &sp->tx_desc[i]; - DMA_SYNC_DESC_CPU(dev, td); + dma_sync_desc_cpu(dev, td); } if (td->tdma.cntinfo & HPCDMA_XIU) { hregs->tx_ndptr = VIRT_TO_DMA(sp, td); @@ -470,7 +474,7 @@ static inline void sgiseeq_tx(struct net_device *dev, struct sgiseeq_private *sp for (j = sp->tx_old; j != sp->tx_new; j = NEXT_TX(j)) { td = &sp->tx_desc[j]; - DMA_SYNC_DESC_CPU(dev, td); + dma_sync_desc_cpu(dev, td); if (!(td->tdma.cntinfo & (HPCDMA_XIU))) break; if (!(td->tdma.cntinfo & (HPCDMA_ETXD))) { @@ -488,7 +492,7 @@ static inline void sgiseeq_tx(struct net_device *dev, struct sgiseeq_private *sp dev_kfree_skb_any(td->skb); td->skb = NULL; } - DMA_SYNC_DESC_DEV(dev, td); + dma_sync_desc_dev(dev, td); } } @@ -598,7 +602,7 @@ static int sgiseeq_start_xmit(struct sk_buff *skb, struct net_device *dev) dev->stats.tx_bytes += len; entry = sp->tx_new; td = &sp->tx_desc[entry]; - DMA_SYNC_DESC_CPU(dev, td); + dma_sync_desc_cpu(dev, td); /* Create entry. There are so many races with adding a new * descriptor to the chain: @@ -618,14 +622,14 @@ static int sgiseeq_start_xmit(struct sk_buff *skb, struct net_device *dev) len, DMA_TO_DEVICE); td->tdma.cntinfo = (len & HPCDMA_BCNT) | HPCDMA_XIU | HPCDMA_EOXP | HPCDMA_XIE | HPCDMA_EOX; - DMA_SYNC_DESC_DEV(dev, td); + dma_sync_desc_dev(dev, td); if (sp->tx_old != sp->tx_new) { struct sgiseeq_tx_desc *backend; backend = &sp->tx_desc[PREV_TX(sp->tx_new)]; - DMA_SYNC_DESC_CPU(dev, backend); + dma_sync_desc_cpu(dev, backend); backend->tdma.cntinfo &= ~HPCDMA_EOX; - DMA_SYNC_DESC_DEV(dev, backend); + dma_sync_desc_dev(dev, backend); } sp->tx_new = NEXT_TX(sp->tx_new); /* Advance. */ @@ -681,11 +685,11 @@ static inline void setup_tx_ring(struct net_device *dev, while (i < (nbufs - 1)) { buf[i].tdma.pnext = VIRT_TO_DMA(sp, buf + i + 1); buf[i].tdma.pbuf = 0; - DMA_SYNC_DESC_DEV(dev, &buf[i]); + dma_sync_desc_dev(dev, &buf[i]); i++; } buf[i].tdma.pnext = VIRT_TO_DMA(sp, buf); - DMA_SYNC_DESC_DEV(dev, &buf[i]); + dma_sync_desc_dev(dev, &buf[i]); } static inline void setup_rx_ring(struct net_device *dev, @@ -698,12 +702,12 @@ static inline void setup_rx_ring(struct net_device *dev, while (i < (nbufs - 1)) { buf[i].rdma.pnext = VIRT_TO_DMA(sp, buf + i + 1); buf[i].rdma.pbuf = 0; - DMA_SYNC_DESC_DEV(dev, &buf[i]); + dma_sync_desc_dev(dev, &buf[i]); i++; } buf[i].rdma.pbuf = 0; buf[i].rdma.pnext = VIRT_TO_DMA(sp, buf); - DMA_SYNC_DESC_DEV(dev, &buf[i]); + dma_sync_desc_dev(dev, &buf[i]); } static int __init sgiseeq_probe(struct platform_device *pdev) -- Crap can work. Given enough thrust pigs will fly, but it's not necessary a good idea. [ RFC1925, 2.3 ] From langabe@gmail.com Wed Dec 19 15:00:34 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 19 Dec 2007 15:00:44 +0000 (GMT) Received: from rn-out-0910.google.com ([64.233.170.189]:23900 "EHLO rn-out-0102.google.com") by ftp.linux-mips.org with ESMTP id S20025044AbXLSOys (ORCPT ); Wed, 19 Dec 2007 14:54:48 +0000 Received: by rn-out-0102.google.com with SMTP id i19so834236rng.2 for ; Wed, 19 Dec 2007 06:53:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:sender:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; bh=jPs5rW1WFs0vdW38MGlxY1JcBw3C7UB1uctW/K1fuII=; b=Qm8BozsdFV40s4eY+wYKeOHgJKbpR02usmG+cIDj+9Fv2KyBu15CxbswIhns+fjbrRJAkwLrOqWAmNmOLF6uy1VzjaczK8PNLHx52pMTXNErRvc2rRYcyLypH/bL7eM9WA39Cel8uafDang0wJcHhpnFQ57wnFtVqOrkZZ+42+4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:sender:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; b=sbl4sZQ4PLKVTedQODrgyFEPjYz/aZJwnFL0gxMapJLtutYu94Uqs+FWSwp+CjgqdWnA6I4RPlaYj/8nMaO3v37fSY+kx0VkZSBOOxm7OltunPqtcRpUvyKOcuJ3TtzEA3YrPzOEViVMvwpsIzyT4MhVo4E0ueJre3zn/VyoDkM= Received: by 10.150.195.21 with SMTP id s21mr1181191ybf.9.1198076025287; Wed, 19 Dec 2007 06:53:45 -0800 (PST) Received: by 10.150.96.3 with HTTP; Wed, 19 Dec 2007 06:53:45 -0800 (PST) Message-ID: Date: Wed, 19 Dec 2007 14:53:45 +0000 From: "Alex Gonzalez" To: linux-mips@ftp.linux-mips.org Subject: Re: [MIPS] Build an embedded initramfs into mips kernel In-Reply-To: <20071218224702.GI15227@1wt.eu> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <9e0cf0bf0712181208m7f16b9acpf3dba67f3556a613@mail.gmail.com> <47683B2D.9030608@zytor.com> <9e0cf0bf0712181409p2475e1fdk779fdee4fa274722@mail.gmail.com> <20071218224702.GI15227@1wt.eu> X-Google-Sender-Auth: 2209a145c5657f04 Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@ftp.linux-mips.org Original-Recipient: rfc822;linux-mips@ftp.linux-mips.org X-archive-position: 17860 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: alex@langabe.org Precedence: bulk X-list: linux-mips Hi, I have a detailed description of the process I went through at my blog http://www.langabe.org/2007/10/adding-initramfs-support-to-linux.html It might help you to compare notes. Alex On Dec 18, 2007 10:47 PM, Willy Tarreau wrote: > On Wed, Dec 19, 2007 at 12:09:46AM +0200, Alon Bar-Lev wrote: > > On 12/18/07, H. Peter Anvin wrote: > > > Make sure your /init doesn't depend on an interpreter or library which > > > isn't available. > > > > Thank you for your answer. > > > > I already checked. > > > > /init is hardlink to busybox, it depends on libc.so.0 which is available at /lib > > Are you sure that libc.so.0 is enough and that you don't need any ld.so ? > > > But shouldn't I get a different error code if this is the case? > > If it does not find part of the dynamic linker or libraries, this error > makes sense to me. > > You should try to build a static init with any stupid thing such as a > hello world to ensure that the problem really comes from the init and > nothing else. > > Regards, > Willy > > > From ralf@linux-mips.org Wed Dec 19 17:34:35 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 19 Dec 2007 17:34:37 +0000 (GMT) Received: from localhost.localdomain ([127.0.0.1]:24448 "EHLO dl5rb.ham-radio-op.net") by ftp.linux-mips.org with ESMTP id S20026895AbXLSRef (ORCPT ); Wed, 19 Dec 2007 17:34:35 +0000 Received: from denk.linux-mips.net (denk.linux-mips.net [127.0.0.1]) by dl5rb.ham-radio-op.net (8.14.1/8.13.8) with ESMTP id lBJHSdEb009747; Wed, 19 Dec 2007 18:29:04 +0100 Received: (from ralf@localhost) by denk.linux-mips.net (8.14.1/8.14.1/Submit) id lBJHRo4U009745; Wed, 19 Dec 2007 18:27:50 +0100 Date: Wed, 19 Dec 2007 18:27:50 +0100 From: Ralf Baechle To: Thomas Bogendoerfer Cc: Jeff Garzik , netdev@vger.kernel.org, linux-mips@linux-mips.org Subject: Re: [UPDATED PATCH] SGISEEQ: use cached memory access to make driver work on IP28 Message-ID: <20071219172750.GA9717@linux-mips.org> References: <20071202103312.75E51C2EB5@solo.franken.de> <47671FEE.90103@pobox.com> <20071218103006.GA18598@alpha.franken.de> <476867F5.3070006@pobox.com> <20071219124235.GA7550@alpha.franken.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20071219124235.GA7550@alpha.franken.de> User-Agent: Mutt/1.5.17 (2007-11-01) Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 17861 X-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 19, 2007 at 01:42:36PM +0100, Thomas Bogendoerfer wrote: > - Use inline functions for dma_sync_* instead of macros > - added Kconfig change to make selection for similair SGI boxes easier > > Signed-off-by: Thomas Bogendoerfer Acked-by: Ralf Baechle Ralf From alon.barlev@gmail.com Wed Dec 19 18:46:57 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 19 Dec 2007 18:47:04 +0000 (GMT) Received: from ug-out-1314.google.com ([66.249.92.172]:43727 "EHLO ug-out-1314.google.com") by ftp.linux-mips.org with ESMTP id S28581735AbXLSSq5 (ORCPT ); Wed, 19 Dec 2007 18:46:57 +0000 Received: by ug-out-1314.google.com with SMTP id k3so336189ugf.38 for ; Wed, 19 Dec 2007 10:46:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=SLMmRrTckla286sGvvaUhAbsjLQ4JakEImd3agdLa00=; b=Xvqpw/kA/E5F9jfDGaJyCujLYjoodnGmnHWob0m1uvoPEDXf0t7G9JjvndWDxJOt5cheNNAn5se2hDH/MULrGD9tCync67D0LpPGB9jTJwPFdTCDYRJ/faPStjl2dBGOw7MTa4fM2jJKD+9+tKvyVh+dW5vbRm00BNlGDCgkTSQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=W+6XGkLPXx4O3VCNPZaU+JgVNj16fdkTs5gU8yH/Iszf/1O1Spnu6eFzNQq9oCRnbjY5G9PAy+UyFSbrSkq+9C5C36x3yk0JxbsZtI8hwMMxm7K7BeQCjYSlNEz6Atyq7fCQDZGS7Gatv0FVCC7/xmYEytFZo/RqTAwxCVyO/G4= Received: by 10.66.254.15 with SMTP id b15mr1658711ugi.76.1198090006807; Wed, 19 Dec 2007 10:46:46 -0800 (PST) Received: by 10.67.117.17 with HTTP; Wed, 19 Dec 2007 10:46:46 -0800 (PST) Message-ID: <9e0cf0bf0712191046q702eefb0vdd0526360eceddc1@mail.gmail.com> Date: Wed, 19 Dec 2007 20:46:46 +0200 From: "Alon Bar-Lev" To: "Willy Tarreau" Subject: Re: [MIPS] Build an embedded initramfs into mips kernel Cc: "H. Peter Anvin" , linux-mips@ftp.linux-mips.org, LKML In-Reply-To: <20071218224702.GI15227@1wt.eu> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <9e0cf0bf0712181208m7f16b9acpf3dba67f3556a613@mail.gmail.com> <47683B2D.9030608@zytor.com> <9e0cf0bf0712181409p2475e1fdk779fdee4fa274722@mail.gmail.com> <20071218224702.GI15227@1wt.eu> Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@ftp.linux-mips.org Original-Recipient: rfc822;linux-mips@ftp.linux-mips.org X-archive-position: 17862 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: alon.barlev@gmail.com Precedence: bulk X-list: linux-mips Thank you for your help. Indeed the dynamic loader of uclibc is the cause. I upgraded to latest uclibc-0.9.29, and finally the files was linked against uclibc's ld. But it did not work... Tried to run a dynamic linked executable via static shell, and got floating point exception. Tried to compile toolchain and uclibc with softfloat, but still did not work. So I moved to glibc and all works correctly. Thank you for quick response! I will continue the discussion at uclibc lists. Best Regards, Alon Bar-Lev. On 12/19/07, Willy Tarreau wrote: > On Wed, Dec 19, 2007 at 12:09:46AM +0200, Alon Bar-Lev wrote: > > On 12/18/07, H. Peter Anvin wrote: > > > Make sure your /init doesn't depend on an interpreter or library which > > > isn't available. > > > > Thank you for your answer. > > > > I already checked. > > > > /init is hardlink to busybox, it depends on libc.so.0 which is available at /lib > > Are you sure that libc.so.0 is enough and that you don't need any ld.so ? > > > But shouldn't I get a different error code if this is the case? > > If it does not find part of the dynamic linker or libraries, this error > makes sense to me. > > You should try to build a static init with any stupid thing such as a > hello world to ensure that the problem really comes from the init and > nothing else. > > Regards, > Willy > > From share.kt@gmail.com Thu Dec 20 18:09:07 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 20 Dec 2007 18:09:16 +0000 (GMT) Received: from nz-out-0506.google.com ([64.233.162.227]:39087 "EHLO nz-out-0506.google.com") by ftp.linux-mips.org with ESMTP id S28583882AbXLTSJH (ORCPT ); Thu, 20 Dec 2007 18:09:07 +0000 Received: by nz-out-0506.google.com with SMTP id n1so1711871nzf.24 for ; Thu, 20 Dec 2007 10:08:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; bh=+g6WenyiBCk9D0+heMpoopfxEp9mpC2ZpRYJHftUdII=; b=KCVVKrmO8pslTmnPfDu408Ksu0/qgAi7NN/xU4tlZoAllUEvXAzmgVbx5P9dcsTCautlfm8/h761Fw12DTiBKKdyoFw6biUt8gcv2VW4/2AvYSwFb3dEnQg11OLW8iP51MAgVm0tOPZjLJgIwklB+U2rND0zJ/tyVaN6iRaL7Q0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=TPk+iKLiAIB2w1lhPb6LNc3y3Tx18irkZEWQMie5r4ThueKqXtYobeUwKBUwl/PV1oumPf+Os7KYHKqFIPCtAqPmipKYOalCBxAHbcaUJBxV0RfO/I+P6kP9nUxKA4gqku65ZJyxvVc4KyeLYd+swmQpUSQfbHsnyNZ2VCrgodg= Received: by 10.115.55.1 with SMTP id h1mr288171wak.69.1198174134057; Thu, 20 Dec 2007 10:08:54 -0800 (PST) Received: by 10.114.135.8 with HTTP; Thu, 20 Dec 2007 10:08:54 -0800 (PST) Message-ID: Date: Thu, 20 Dec 2007 23:38:54 +0530 From: kaka To: "Denis Oliver Kropp" Subject: Re: [directfb-dev] Error in running gtk example on cross compiled GTK with DirectFB on MIPS board Cc: linux-mips@linux-mips.org, uclinux-dev@uclinux.org, celinux-dev@tree.celinuxforum.org, linux-fbdev-users@lists.sourceforge.net, directfb-users@directfb.org, directfb-dev@directfb.org In-Reply-To: <4766B149.5050109@directfb.org> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_18098_26786107.1198174134052" References: <4766B149.5050109@directfb.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: 17863 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: share.kt@gmail.com Precedence: bulk X-list: linux-mips ------=_Part_18098_26786107.1198174134052 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Hi Denis, I am writing gfx driver for DirectFB on BroadCom chip. Right now i am using FBdev system to display graphics on BCM chip(MIPS platform) which should use software fallbacks from DirectFB.Later on i 'll add hardware accelerartion also. My framebuffer driver for BCM chip is working fine. I have checked it by running a small example. Also the gfxdriver for directFB is working fine for Video and Image. The problem which i am facing right now is that i am running the fill rectangle example. IT is not filling any color in the rectangle. I am always getting the black screen. Could you plz provide some clue on it ? Also could you plz specify the file name and function in which directFB library is writing into the framebuffer memory the color pixel information? Thanks in Advance. kaka On 12/17/07, Denis Oliver Kropp wrote: > > kaka wrote: > > HI ALL, > > > > We have successfully cross compiled GTK and DIRECTFB with all its > > dependencies for MIPS board. > > On running the basic test example of GTK, it is getting struck in the > thread > > loop infinitely. > > We had put the "debug printf" statement in the gtkmain.c and debugged > the > > test example. > > It is getting struck in the * g_main_loop_run (loop);* given below is > > the code(code > > snippet from gtkmain.c) > > > > void > > gtk_main (void) > > { > > GList *tmp_list; > > GList *functions; > > GtkInitFunction *init; > > GMainLoop *loop; > > printf("\n%s :: %d\n",__FILE__,__LINE__); > > gtk_main_loop_level++; > > > > loop = g_main_loop_new (NULL, TRUE); > > main_loops = g_slist_prepend (main_loops, loop); > > printf("\n%s :: %d\n",__FILE__,__LINE__); > > tmp_list = functions = init_functions; > > init_functions = NULL; > > > > while (tmp_list) > > { > > init = tmp_list->data; > > tmp_list = tmp_list->next; > > > > (* init->function) (init->data); > > g_free (init); > > } > > g_list_free (functions); > > printf("\n%s :: %d\n",__FILE__,__LINE__); > > if (g_main_loop_is_running (main_loops->data)) > > { > > * printf("\n%s :: %d\n",__FILE__,__LINE__); > > GDK_THREADS_LEAVE (); > > g_main_loop_run (loop); > > GDK_THREADS_ENTER (); > > * printf("\n%s :: %d\n",__FILE__,__LINE__); > > That's normal. If you want runtime you have to create a timer or register > idle or timeout functions. > > > gtk_container_add (GTK_CONTAINER (window), pMainWidget); > > printf("\n\n\ngtk_container_add (GTK_CONTAINER (window), > > pMainWidget);\n\n\n") ; > > gtk_widget_show (window); > > printf("\n\n\nABHISHEK START OF gtk_main\n\n\n"); > > gtk_main (); > > printf("\n\n\nABHISHEK END OF gtk_main\n\n\n"); > > return 0; > > Simply/weakly put: it should not return before the application is quit. > > -- > Best regards, > Denis Oliver Kropp > > .------------------------------------------. > | DirectFB - Hardware accelerated graphics | > | http://www.directfb.org/ | > "------------------------------------------" > -- Thanks & Regards, kaka ------=_Part_18098_26786107.1198174134052 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline
Hi Denis,
 
I am writing gfx driver for DirectFB on BroadCom chip.
Right now i am using FBdev system to display graphics on BCM chip(MIPS platform)  which should use software fallbacks from DirectFB.Later on i 'll add hardware accelerartion also. 
My framebuffer driver for BCM chip is working fine. I have checked it by running a small example. Also the gfxdriver for directFB is working fine for Video and Image.
The problem which i am facing right now is that i am running the fill rectangle example.
IT is not filling any color in the rectangle. I am always getting the black screen.
 
Could you plz provide some clue on it ?
Also could you plz specify the file name and function in which directFB library is writing into the framebuffer memory the color pixel information?
 
Thanks in Advance.
kaka


 
On 12/17/07, Denis Oliver Kropp <dok@directfb.org> wrote:
kaka wrote:
> HI ALL,
>
> We have successfully cross compiled GTK and DIRECTFB with all its
> dependencies for MIPS board.
> On running the basic test example of GTK, it is getting struck in the thread
> loop infinitely.
> We had put the  "debug printf"  statement in the gtkmain.c and debugged the
> test example.
> It is getting struck in the * g_main_loop_run (loop);* given below is
> the  code(code
> snippet from gtkmain.c)
>
> void
> gtk_main (void)
> {
>   GList *tmp_list;
>   GList *functions;
>   GtkInitFunction *init;
>   GMainLoop *loop;
> printf("\n%s :: %d\n",__FILE__,__LINE__);
>   gtk_main_loop_level++;
>
>   loop = g_main_loop_new (NULL, TRUE);
>   main_loops = g_slist_prepend (main_loops, loop);
> printf("\n%s :: %d\n",__FILE__,__LINE__);
>   tmp_list = functions = init_functions;
>   init_functions = NULL;
>
>   while (tmp_list)
>     {
>       init = tmp_list->data;
>       tmp_list = tmp_list->next;
>
>       (* init->function) (init->data);
>       g_free (init);
>     }
>   g_list_free (functions);
> printf("\n%s :: %d\n",__FILE__,__LINE__);
>   if (g_main_loop_is_running (main_loops->data))
>     {
>    * printf("\n%s :: %d\n",__FILE__,__LINE__);
>       GDK_THREADS_LEAVE ();
>       g_main_loop_run (loop);
>       GDK_THREADS_ENTER ();
> *      printf("\n%s :: %d\n",__FILE__,__LINE__);

That's normal. If you want runtime you have to create a timer or register idle or timeout functions.

>       gtk_container_add (GTK_CONTAINER (window), pMainWidget);
>  printf("\n\n\ngtk_container_add (GTK_CONTAINER (window),
> pMainWidget);\n\n\n") ;
>       gtk_widget_show (window);
> printf("\n\n\nABHISHEK START OF gtk_main\n\n\n");
>       gtk_main ();
> printf("\n\n\nABHISHEK END OF gtk_main\n\n\n");
>       return 0;

Simply/weakly put: it should not return before the application is quit.

--
Best regards,
Denis Oliver Kropp

.------------------------------------------.
| DirectFB - Hardware accelerated graphics |
| http://www.directfb.org/                 |
"------------------------------------------"



--
Thanks & Regards,
kaka ------=_Part_18098_26786107.1198174134052-- From share.kt@gmail.com Thu Dec 20 18:11:56 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 20 Dec 2007 18:12:05 +0000 (GMT) Received: from wa-out-1112.google.com ([209.85.146.180]:8436 "EHLO wa-out-1112.google.com") by ftp.linux-mips.org with ESMTP id S28583883AbXLTSL4 (ORCPT ); Thu, 20 Dec 2007 18:11:56 +0000 Received: by wa-out-1112.google.com with SMTP id m16so5130320waf.20 for ; Thu, 20 Dec 2007 10:11:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:mime-version:content-type; bh=ghiP9soSKfz1tubGUZ2Jm7ut7dsPE80pP55E4mU0Xuw=; b=cUZG+RjN4YivA9/rzxjSOXz0eHzWxWQNiACkcStrWGcXlExJcueMV8acxwuRDm0FysoQEGtKMvgwIY4ZMUV1HEl+jgJIHuZGfoF5Ne9GvB5CRqQDKhZreFTrb4rg5Po+0EUjaULOfrMDCa2SSJzU7Ac9VjweR9Et+riO7yEmEFQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:mime-version:content-type; b=V/iuEzN2Yt2+l9QrYehM6XkpQPrdrapx/lUnrgKo2XroJq+cpr75lEcdmMc8UQ0t8iDHvkgXiAHcOl3LKjWH97GQ37kdGKXuYypr/D5Ybh42qfJ3v7WCuMZVYfqyv2BCeNH1IEer4lEqva1qIBIT9fMPQR9w2zwuIqRlhlwe4lw= Received: by 10.114.209.1 with SMTP id h1mr279701wag.130.1198174302355; Thu, 20 Dec 2007 10:11:42 -0800 (PST) Received: by 10.114.135.8 with HTTP; Thu, 20 Dec 2007 10:11:42 -0800 (PST) Message-ID: Date: Thu, 20 Dec 2007 23:41:42 +0530 From: kaka To: "Denis Oliver Kropp" Subject: Fill rectangle is not filling the screen with the COLOR(ALways filling the screen with Black color) Cc: linux-mips@linux-mips.org, uclinux-dev@uclinux.org, celinux-dev@tree.celinuxforum.org, linux-fbdev-users@lists.sourceforge.net, directfb-users@directfb.org, directfb-dev@directfb.org MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_18102_17029842.1198174302348" Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 17864 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: share.kt@gmail.com Precedence: bulk X-list: linux-mips ------=_Part_18102_17029842.1198174302348 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline > > Hi Denis, > > I am writing gfx driver for DirectFB on BroadCom chip. > Right now i am using FBdev system to display graphics on BCM chip(MIPS > platform) which should use software fallbacks from DirectFB.Later on i > 'll add hardware accelerartion also. > My framebuffer driver for BCM chip is working fine. I have checked it by > running a small example. Also the gfxdriver for directFB is working fine for > Video and Image. > The problem which i am facing right now is that i am running the fill > rectangle example. > IT is not filling any color in the rectangle. I am always getting the > black screen. > > Could you plz provide some clue on it ? > Also could you plz specify the file name and function in which directFB > library is writing into the framebuffer memory the color pixel information? > > Thanks in Advance. > kaka > > > > On 12/17/07, Denis Oliver Kropp wrote: > > > > kaka wrote: > > > HI ALL, > > > > > > We have successfully cross compiled GTK and DIRECTFB with all its > > > dependencies for MIPS board. > > > On running the basic test example of GTK, it is getting struck in the > > thread > > > loop infinitely. > > > We had put the "debug printf" statement in the gtkmain.c and > > debugged the > > > test example. > > > It is getting struck in the * g_main_loop_run (loop);* given below is > > > the code(code > > > snippet from gtkmain.c) > > > > > > void > > > gtk_main (void) > > > { > > > GList *tmp_list; > > > GList *functions; > > > GtkInitFunction *init; > > > GMainLoop *loop; > > > printf("\n%s :: %d\n",__FILE__,__LINE__); > > > gtk_main_loop_level++; > > > > > > loop = g_main_loop_new (NULL, TRUE); > > > main_loops = g_slist_prepend (main_loops, loop); > > > printf("\n%s :: %d\n",__FILE__,__LINE__); > > > tmp_list = functions = init_functions; > > > init_functions = NULL; > > > > > > while (tmp_list) > > > { > > > init = tmp_list->data; > > > tmp_list = tmp_list->next; > > > > > > (* init->function) (init->data); > > > g_free (init); > > > } > > > g_list_free (functions); > > > printf("\n%s :: %d\n",__FILE__,__LINE__); > > > if (g_main_loop_is_running (main_loops->data)) > > > { > > > * printf("\n%s :: %d\n",__FILE__,__LINE__); > > > GDK_THREADS_LEAVE (); > > > g_main_loop_run (loop); > > > GDK_THREADS_ENTER (); > > > * printf("\n%s :: %d\n",__FILE__,__LINE__); > > > > That's normal. If you want runtime you have to create a timer or > > register idle or timeout functions. > > > > > gtk_container_add (GTK_CONTAINER (window), pMainWidget); > > > printf("\n\n\ngtk_container_add (GTK_CONTAINER (window), > > > pMainWidget);\n\n\n") ; > > > gtk_widget_show (window); > > > printf("\n\n\nABHISHEK START OF gtk_main\n\n\n"); > > > gtk_main (); > > > printf("\n\n\nABHISHEK END OF gtk_main\n\n\n"); > > > return 0; > > > > Simply/weakly put: it should not return before the application is quit. > > > > -- > > Best regards, > > Denis Oliver Kropp > > > > .------------------------------------------. > > | DirectFB - Hardware accelerated graphics | > > | http://www.directfb.org/ | > > "------------------------------------------" > > > > > > -- > Thanks & Regards, > kaka -- Thanks & Regards, kaka ------=_Part_18102_17029842.1198174302348 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline
Hi Denis,
 
I am writing gfx driver for DirectFB on BroadCom chip.
Right now i am using FBdev system to display graphics on BCM chip(MIPS platform)  which should use software fallbacks from DirectFB.Later on i 'll add hardware accelerartion also. 
My framebuffer driver for BCM chip is working fine. I have checked it by running a small example. Also the gfxdriver for directFB is working fine for Video and Image.
The problem which i am facing right now is that i am running the fill rectangle example.
IT is not filling any color in the rectangle. I am always getting the black screen.
 
Could you plz provide some clue on it ?
Also could you plz specify the file name and function in which directFB library is writing into the framebuffer memory the color pixel information?
 
Thanks in Advance.
kaka


 
On 12/17/07, Denis Oliver Kropp < dok@directfb.org> wrote:
kaka wrote:
> HI ALL,
>
> We have successfully cross compiled GTK and DIRECTFB with all its
> dependencies for MIPS board.
> On running the basic test example of GTK, it is getting struck in the thread
> loop infinitely.
> We had put the  "debug printf"  statement in the gtkmain.c and debugged the
> test example.
> It is getting struck in the * g_main_loop_run (loop);* given below is
> the  code(code
> snippet from gtkmain.c)
>
> void
> gtk_main (void)
> {
>   GList *tmp_list;
>   GList *functions;
>   GtkInitFunction *init;
>   GMainLoop *loop;
> printf("\n%s :: %d\n",__FILE__,__LINE__);
>   gtk_main_loop_level++;
>
>   loop = g_main_loop_new (NULL, TRUE);
>   main_loops = g_slist_prepend (main_loops, loop);
> printf("\n%s :: %d\n",__FILE__,__LINE__);
>   tmp_list = functions = init_functions;
>   init_functions = NULL;
>
>   while (tmp_list)
>     {
>       init = tmp_list->data;
>       tmp_list = tmp_list->next;
>
>       (* init->function) (init->data);
>       g_free (init);
>     }
>   g_list_free (functions);
> printf("\n%s :: %d\n",__FILE__,__LINE__);
>   if (g_main_loop_is_running (main_loops->data))
>     {
>    * printf("\n%s :: %d\n",__FILE__,__LINE__);
>       GDK_THREADS_LEAVE ();
>       g_main_loop_run (loop);
>       GDK_THREADS_ENTER ();
> *      printf("\n%s :: %d\n",__FILE__,__LINE__);

That's normal. If you want runtime you have to create a timer or register idle or timeout functions.

>       gtk_container_add (GTK_CONTAINER (window), pMainWidget);
>  printf("\n\n\ngtk_container_add (GTK_CONTAINER (window),
> pMainWidget);\n\n\n") ;
>       gtk_widget_show (window);
> printf("\n\n\nABHISHEK START OF gtk_main\n\n\n");
>       gtk_main ();
> printf("\n\n\nABHISHEK END OF gtk_main\n\n\n");
>       return 0;

Simply/weakly put: it should not return before the application is quit.

--
Best regards,
Denis Oliver Kropp

.------------------------------------------.
| DirectFB - Hardware accelerated graphics |
| http://www.directfb.org/                 |
"------------------------------------------"



--
Thanks & Regards,
kaka



--
Thanks & Regards,
kaka ------=_Part_18102_17029842.1198174302348-- From mike.emmel@gmail.com Thu Dec 20 19:10:56 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 20 Dec 2007 19:11:05 +0000 (GMT) Received: from wr-out-0506.google.com ([64.233.184.226]:28483 "EHLO wr-out-0506.google.com") by ftp.linux-mips.org with ESMTP id S28583905AbXLTTK4 (ORCPT ); Thu, 20 Dec 2007 19:10:56 +0000 Received: by wr-out-0506.google.com with SMTP id 67so2717149wri.6 for ; Thu, 20 Dec 2007 11:09:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=e/6DaMWAhwrgYqbRjZci70QLFPWAzjW3mZF1fcNOfOQ=; b=EGtxFUjQTu7L1h/rB3OpHFm8/qaLikdKpZfz0plmDQ0+gttxNLPjlhW5cVYMHv3RYCjbusuJN+qFPr7hKAxgZxoecm1Dav+uyQnvaJhlDPOLmb1EOEgTRgICBbr1u6ZpCrhfuvC7C3nKqpA/6kJjMLUW7K3qmkCWXgqlFJUaAi8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=Mi2FHL9mbOU0bO5R46gTX8sI0OGcIEny43/uLe48xZfqm312x8R0ZIR2PJE/T0pslaK5u3ZRmZdfZaQLkd+DI3p27XF7gsE0rw3fovJqzia+JU+Qgxe3kEbk57t/mS7gObT4fJqQPTn5yR4adqvT4lPVRvsfgRzHYzyek0oqN/0= Received: by 10.142.212.19 with SMTP id k19mr281805wfg.66.1198177794249; Thu, 20 Dec 2007 11:09:54 -0800 (PST) Received: by 10.142.213.18 with HTTP; Thu, 20 Dec 2007 11:09:54 -0800 (PST) Message-ID: <3e9035250712201109n341b972cl80256a0c8523b653@mail.gmail.com> Date: Thu, 20 Dec 2007 11:09:54 -0800 From: "Mike Emmel" To: kaka Subject: Re: [directfb-dev] Error in running gtk example on cross compiled GTK with DirectFB on MIPS board Cc: "Denis Oliver Kropp" , linux-mips@linux-mips.org, uclinux-dev@uclinux.org, linux-fbdev-users@lists.sourceforge.net, directfb-dev@directfb.org, celinux-dev@tree.celinuxforum.org, directfb-users@directfb.org In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <4766B149.5050109@directfb.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: 17865 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: mike.emmel@gmail.com Precedence: bulk X-list: linux-mips I suspect this is related to the creation of a top level ARGB surface when gtk is initialized. You probably should dig around a bit but it looks to me like its a issue with surface formats. Since your doing the driver you should try and make sure that you get a accelerated surface working for Gtk/Cairo this would need to be either RGB/ARGB because of limited pixel format support in Cairo. gdk_display_open in gdkdisplay-directfb.c See how it finally initializes and I suspect that if you do the same in a simple DirectFB app you get the black screen and can debug. On Dec 20, 2007 10:08 AM, kaka wrote: > Hi Denis, > > I am writing gfx driver for DirectFB on BroadCom chip. > Right now i am using FBdev system to display graphics on BCM chip(MIPS > platform) which should use software fallbacks from DirectFB.Later on i 'll > add hardware accelerartion also. > My framebuffer driver for BCM chip is working fine. I have checked it by > running a small example. Also the gfxdriver for directFB is working fine for > Video and Image. > The problem which i am facing right now is that i am running the fill > rectangle example. > IT is not filling any color in the rectangle. I am always getting the black > screen. > > Could you plz provide some clue on it ? > Also could you plz specify the file name and function in which directFB > library is writing into the framebuffer memory the color pixel information? > > Thanks in Advance. > kaka > > > > On 12/17/07, Denis Oliver Kropp wrote: > > > kaka wrote: > > > HI ALL, > > > > > > We have successfully cross compiled GTK and DIRECTFB with all its > > > dependencies for MIPS board. > > > On running the basic test example of GTK, it is getting struck in the > thread > > > loop infinitely. > > > We had put the "debug printf" statement in the gtkmain.c and debugged > the > > > test example. > > > It is getting struck in the * g_main_loop_run (loop);* given below is > > > the code(code > > > snippet from gtkmain.c) > > > > > > void > > > gtk_main (void) > > > { > > > GList *tmp_list; > > > GList *functions; > > > GtkInitFunction *init; > > > GMainLoop *loop; > > > printf("\n%s :: %d\n",__FILE__,__LINE__); > > > gtk_main_loop_level++; > > > > > > loop = g_main_loop_new (NULL, TRUE); > > > main_loops = g_slist_prepend (main_loops, loop); > > > printf("\n%s :: %d\n",__FILE__,__LINE__); > > > tmp_list = functions = init_functions; > > > init_functions = NULL; > > > > > > while (tmp_list) > > > { > > > init = tmp_list->data; > > > tmp_list = tmp_list->next; > > > > > > (* init->function) (init->data); > > > g_free (init); > > > } > > > g_list_free (functions); > > > printf("\n%s :: %d\n",__FILE__,__LINE__); > > > if (g_main_loop_is_running (main_loops->data)) > > > { > > > * printf("\n%s :: %d\n",__FILE__,__LINE__); > > > GDK_THREADS_LEAVE (); > > > g_main_loop_run (loop); > > > GDK_THREADS_ENTER (); > > > * printf("\n%s :: %d\n",__FILE__,__LINE__); > > > > That's normal. If you want runtime you have to create a timer or register > idle or timeout functions. > > > > > gtk_container_add (GTK_CONTAINER (window), pMainWidget); > > > printf("\n\n\ngtk_container_add (GTK_CONTAINER (window), > > > pMainWidget);\n\n\n") ; > > > gtk_widget_show (window); > > > printf("\n\n\nABHISHEK START OF gtk_main\n\n\n"); > > > gtk_main (); > > > printf("\n\n\nABHISHEK END OF gtk_main\n\n\n"); > > > return 0; > > > > Simply/weakly put: it should not return before the application is quit. > > > > -- > > Best regards, > > Denis Oliver Kropp > > > > .------------------------------------------. > > | DirectFB - Hardware accelerated graphics | > > | http://www.directfb.org/ | > > "------------------------------------------" > > > > > > -- > Thanks & Regards, > kaka > _______________________________________________ > directfb-dev mailing list > directfb-dev@directfb.org > http://mail.directfb.org/cgi-bin/mailman/listinfo/directfb-dev > > From ralf@linux-mips.org Fri Dec 21 01:24:37 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 21 Dec 2007 01:24:39 +0000 (GMT) Received: from localhost.localdomain ([127.0.0.1]:24968 "EHLO dl5rb.ham-radio-op.net") by ftp.linux-mips.org with ESMTP id S28584306AbXLUBYh (ORCPT ); Fri, 21 Dec 2007 01:24:37 +0000 Received: from denk.linux-mips.net (denk.linux-mips.net [127.0.0.1]) by dl5rb.ham-radio-op.net (8.14.1/8.13.8) with ESMTP id lBL1BOlt015515; Fri, 21 Dec 2007 02:11:49 +0100 Received: (from ralf@localhost) by denk.linux-mips.net (8.14.1/8.14.1/Submit) id lBL1BMuf015514; Fri, 21 Dec 2007 02:11:22 +0100 Date: Fri, 21 Dec 2007 02:11:22 +0100 From: Ralf Baechle To: "Kevin D. Kissell" Cc: Pavel Kiryukhin , linux-mips@linux-mips.org Subject: Re: [PATCH][MIPS] fix user_cpus_allowed assignment Message-ID: <20071221011122.GB14926@linux-mips.org> References: <73cd086a0712170517i146a452exea775f3942c1d5da@mail.gmail.com> <017c01c840cb$7a5049c0$10eca8c0@grendel> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <017c01c840cb$7a5049c0$10eca8c0@grendel> User-Agent: Mutt/1.5.17 (2007-11-01) Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 17866 X-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 17, 2007 at 05:40:03PM +0100, Kevin D. Kissell wrote: > This looks to be a correct fix. Long term, we really do need to convince > the scheduler maintainer to provide hooks that will allow hardware-driven > affinity to be integrated with application-driven affinity in a sensible way, > without requiring replication (and replicated maintenence) of the system > call code in private copies like this. I asked for such hooks in sched.c > when it first became apparent that dynamic FPU affinity was desirable, > but was blown off at that time, so, with regret, I perpetrated the local copy > hack. But it's silly, and MIPS can't possibly be the only architecture where > Linux is used in systems with assymmetric resources where adaptive affinity > is useful. I dare to speculate that the new job of a certain Mike Uhler may increase the need for such a scheduler feature :-) Ralf From apw@shadowen.org Fri Dec 21 17:39:23 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 21 Dec 2007 17:39:32 +0000 (GMT) Received: from hellhawk.shadowen.org ([80.68.90.175]:2057 "EHLO hellhawk.shadowen.org") by ftp.linux-mips.org with ESMTP id S20029906AbXLURjW (ORCPT ); Fri, 21 Dec 2007 17:39:22 +0000 Received: from localhost ([127.0.0.1] helo=pinky) by hellhawk.shadowen.org with esmtp (Exim 4.63) (envelope-from ) id 1J5ln4-0005eb-Gs; Fri, 21 Dec 2007 17:36:06 +0000 Date: Fri, 21 Dec 2007 17:36:01 +0000 From: Andy Whitcroft To: Andrew Morton Cc: Thomas Bogendoerfer , linux-kernel@vger.kernel.org, linux-mips@linux-mips.org, Alan Cox Subject: Re: [PATCH] SC26XX: New serial driver for SC2681 uarts Message-ID: <20071221173601.GR13186@shadowen.org> References: <20071202194346.36E3FDE4C4@solo.franken.de> <20071203155317.772231f9.akpm@linux-foundation.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20071203155317.772231f9.akpm@linux-foundation.org> 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: 17867 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: apw@shadowen.org Precedence: bulk X-list: linux-mips On Mon, Dec 03, 2007 at 03:53:17PM -0800, Andrew Morton wrote: > > +#define READ_SC(p, r) readb ((p)->membase + RD_##r) > > +#define WRITE_SC(p, r, v) writeb ((v), (p)->membase + WR_##r) > > No space before the (. checkpatch misses this. Yep, over careful in the special case for the parameters for #define macros, which have different spacing rules. This will be fixed in 0.13: WARNING: no space between function name and open parenthesis '(' #1: FILE: Z45.c:1: +#define WRITE_SC(p, r, v) writeb ((v), (p)->membase + WR_##r) -apw From penberg@gmail.com Sat Dec 22 09:47:26 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Sat, 22 Dec 2007 09:47:34 +0000 (GMT) Received: from rv-out-0910.google.com ([209.85.198.186]:22233 "EHLO rv-out-0910.google.com") by ftp.linux-mips.org with ESMTP id S20029658AbXLVJr0 (ORCPT ); Sat, 22 Dec 2007 09:47:26 +0000 Received: by rv-out-0910.google.com with SMTP id l15so492987rvb.24 for ; Sat, 22 Dec 2007 01:47:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; bh=p0hXdTv+AR7thQfNVv68jsu4bx06cR7Ik1mAQ4LiT0M=; b=CQyPW0XqMt38d7ojRT60mRtwa0qg6ys/piEQMD/uGre4u8+BmxlmSxu4+AgqklASMZwUPUWqfxiA/7PyR08XiXoWKBv3F3Ygwu3J5/ghKpAyqwdJ7oyJVjq5aOC+WuqEl12kx5uVxMQYAt8HZEvXSzQvcVZfm+7+KNnNLf7Yp+Y= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; b=hKWRhs5yKCPQqaE6ps1/bkV3cTWfC4Du8VFMRG1sme0oYWEBuRX/L5JgMxO5YCqbN1ViOYWX23BZWn3V8rpOrg88x3V5ETULkBhYf3sDLuzKnsHqlrj9k26G8OmXHTnta3UZcQqgSApCG7rXFceSfgfl+MIvt0tzrVnzZp+/5OM= Received: by 10.141.44.13 with SMTP id w13mr1260119rvj.181.1198316834135; Sat, 22 Dec 2007 01:47:14 -0800 (PST) Received: by 10.140.203.15 with HTTP; Sat, 22 Dec 2007 01:47:14 -0800 (PST) Message-ID: <84144f020712220147q2e291fa1t4ee03e4d64be95b@mail.gmail.com> Date: Sat, 22 Dec 2007 11:47:14 +0200 From: "Pekka Enberg" To: "Thomas Bogendoerfer" Subject: Re: [PATCH] SC26XX: New serial driver for SC2681 uarts Cc: "Andrew Morton" , linux-kernel@vger.kernel.org, linux-mips@linux-mips.org, "Andy Whitcroft" , "Alan Cox" In-Reply-To: <20071205092506.GA6691@alpha.franken.de> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <20071202194346.36E3FDE4C4@solo.franken.de> <20071203155317.772231f9.akpm@linux-foundation.org> <20071204234112.GA12352@alpha.franken.de> <20071204192738.54e79a97.akpm@linux-foundation.org> <20071205092506.GA6691@alpha.franken.de> X-Google-Sender-Auth: 2a0b04f06c6c25f0 Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 17868 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: penberg@cs.helsinki.fi Precedence: bulk X-list: linux-mips Hi Thomas, On Dec 5, 2007 11:25 AM, Thomas Bogendoerfer wrote: > > These: > > > > > +#define READ_SC(p, r) readb((p)->membase + RD_##r) > > > +#define WRITE_SC(p, r, v) writeb((v), (p)->membase + WR_##r) > > > > and these: > > > > > +#define READ_SC_PORT(p, r) read_sc_port(p, RD_PORT_##r) > > > +#define WRITE_SC_PORT(p, r, v) write_sc_port(p, WR_PORT_##r, v) > > > > really don't need to exist. All they do is make the code harder to read. > > but they make the code safer. The chip has common register and port > registers, which are randomly splattered over the address range. And > some of them are read only, some write only. Read only and Write > only register live at the same register offset and their function > usually doesn't have anything in common. By using these macros I'll > get compile errors when doing a READ_SC from a write only register > and vice versa. I will also get compile errors, if I try to access a > common register via READ_SC_PORT/WRITE_SC_PORT. You can use grep to make sure there are no reads to a write-only register. What you have there is not safety but macro obfuscation at its best. It makes the code harder to read for anyone not intimately familiar with the driver. From post@pfrst.de Sun Dec 23 01:46:18 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Sun, 23 Dec 2007 01:46:27 +0000 (GMT) Received: from mail1.pearl-online.net ([62.159.194.147]:63826 "EHLO mail1.pearl-online.net") by ftp.linux-mips.org with ESMTP id S28575343AbXLWBqS (ORCPT ); Sun, 23 Dec 2007 01:46:18 +0000 Received: from SNaIlmail.Peter (unknown [77.47.54.105]) by mail1.pearl-online.net (Postfix) with ESMTP id E6462B27F; Sun, 23 Dec 2007 02:45:30 +0100 (CET) Received: from Indigo2.Peter (Indigo2.Peter [192.168.1.28]) by SNaIlmail.Peter (8.12.6/8.12.6/Sendmail/Linux 2.0.32) with ESMTP id lBN1jA74000860; Sun, 23 Dec 2007 02:45:11 +0100 Received: from Indigo2.Peter (localhost [127.0.0.1]) by Indigo2.Peter (8.12.6/8.12.6/Sendmail/Linux 2.6.14-rc2-ip28) with ESMTP id lBN1i2F5000219; Sun, 23 Dec 2007 02:44:02 +0100 Received: from localhost (pf@localhost) by Indigo2.Peter (8.12.6/8.12.6/Submit) with ESMTP id lBN1i1od000216; Sun, 23 Dec 2007 02:44:01 +0100 X-Authentication-Warning: Indigo2.Peter: pf owned process doing -bs Date: Sun, 23 Dec 2007 02:44:01 +0100 (CET) From: peter fuerst X-X-Sender: pf@Indigo2.Peter To: Richard Sandiford Cc: Ralf Baechle , Thomas Bogendoerfer , Kumba , linux-mips@linux-mips.org Subject: Re: [UPDATED PATCH] IP28 support Message-ID: 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: 17869 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: post@pfrst.de Precedence: bulk X-list: linux-mips On Wed, 12 Dec 2007, Richard Sandiford wrote: > Date: Wed, 12 Dec 2007 18:09:31 +0000 > From: Richard Sandiford > To: peter fuerst > Cc: Ralf Baechle , > Thomas Bogendoerfer , > Kumba , linux-mips@linux-mips.org > Subject: Re: [UPDATED PATCH] IP28 support > > peter fuerst writes: > >> Ralf Baechle writes: > >> >> Then there's the language-lawyerly code I gave to Peter on gcc-patches@: > >> >> > >> >> void foo (int x) > >> >> { > >> >> int array[1]; > >> >> if (x) > >> >> bar (array[0x1fff]); > >> >> } > >> >> > > > > A strange method to pass data... Of course, cooking up such an "ABI", > > where local variables are accessed with a const offset that is not known at > > compile-time to be valid, would subvert the test for $sp-based accesses... > > Well, as I said when I gave that example originally, it's unlikely that > the example would be written in that form. But hide the constants and > checks in configurable macros, and the general idea becomes a little > more feasible. > > >> FWIW, my first cut at the option restrictions were based on what > >> the patch exempts (and doesn't exempt). We could instead get gcc > >> to only exempt accesses that it can prove are either to the current > >> function's stack frame or to its stack arguments. I.e. rather than > >> consider every $sp-based access to be safe, we'd instead do some > > > > "every $sp-based access" (set(mem(plus(sp)(const_int)))) is restricted > > to local variables too, with the constant offset being either > > - compiler-generated or > > - deliberately put in the source (however including the above example) > > That's not literally true. SP+INT addresses can be used to access > stack arguments too, and 4.x can optimise some varargs accesses to "local variables" was meant to include (var-)argument-slots too, which are allright, so far. > compile-time base+offset addresses. And as I said, the compiler is > free to make up accesses that aren't in fact valid for cases where > the access isn't made. E.g. if you had a loop with a stride of 128, > the compiler could unroll the loop as many times as it likes. Some > of the unrolled iterations might access areas outside the stack frame. You mean, the compiler would generate $sp+const_int accesses here, whose validity is not known at compile-time - similar to foo() above ? > (You would hope that the compiler would be intelligent enough to crop > the iteration count in such cases, because the extra iterations should > never be used in valid code. But that isn't the point. The compiler > doesn't _need_ to crop the iteration count for correctness, and we're > talking about something we _do_ need for correctness.) > > >> bounds checking on the value. > > Fine, if that is possible. > > FWIW, the frame info is available in cfun->machine->frame at the time > your code runs. > > >> (We could also use MEM_ATTRS to > >> pick up cases where a stack variable is acceesed via something > >> other than the stack or frame pointers, as happens for large frames.) > > > > Aren't these always accesses with non-constant offset, where a CB can't be > > avoided, even if they are recognized as being actually relative to $sp ? > > The MEM_ATTRS I meant were MEM_EXPR + MEM_OFFSET, which only apply where > there is a known constant offset. > > >> > In case of a hypothetic multi-platform kernel of which at least one needs > >> > the R10000 workarounds, all code would be uniformly compiled with the > >> > magic -mr10k-cache-barrier option and all source level workaround would > >> > be enabled. > >> > >> Hmm. This probably shows I am misunderstanding the problem, but I was > >> thinking about the IO-mapped case. I thought one of the problems was > >> that if you had a cached speculative load or store to an access-sensitive > >> IO-mapped address, the IO-mapped device might "see" that access even if it > >> doesn't take place. Could you not have a situation where a KSEG0 or > >> XKSEG0 access is access-sensitive on one machine and not another? > >> The patch won't insert countermeasures before symbolic and constant > >> addresses, because it believes all such addresses to be safe. > >> > > > > The threat to IO-addresses comes from the addressing register in the speculated > > mem-instruction (set(mem(plus(reg)...), containing one of the addresses as > > "garbage". > > > > Symbolic addresses are well defined from link-time on, no matter what history > > before the access. They either point (set(mem(plus(symbol_ref)...) to > > - some variable in the cached area, what is harmless (unless DMA-related), > > or to > > - IO-devices, accessed uncached, i.e. non-speculative, > > unless there is a programming-error ;) > > The same holds for const_int used as address. > > I think you're missing my point. If you access an I/O-mapped device > through KSEG2 or an uncached XKPHYS address, is it not also physically > possible (though clearly unwise) to access it through KSEG0 or a cached > XKPHYS address too? So can you guarantee that every const_int cached > address in a multi-platform kernel is not I/O-mapped on any of the r10k > platforms? Or can you guarantee that the compiler will not manufacture > such an address from an otherwise harmless address? Hmm, it's not quite clear, how it could be manufactured. > Again, the key thing > is to think about what the compiler can validly do on non-r10k platforms, > however silly it might seem, and then make sure the workarounds cope > with it. Do you think of accesses that essentially look like this ? if (machine_x) *uncached(const_addr) = val; else *cached(const_addr) = val; Fortunately (at least? even?) on IP28 cached access (hence a block read request) to an I/O-device address is a non-issue. In this respect the hardware design seems to follow the recommendations from the R10000 manual (NACK from external agent?): - if such an access graduates (i.e. a "real" access), a bus-error will occur. - if not (i.e. mis-speculated), nothing happens. However, i don't yet know, how O2 behaves, or, if there exists any other R10k-machine, which would need the software-workaround. > > >> I'm also a little worried that the compiler is free to make up accesses > >> that didn't exist in the original program, provided that those accesses > > The cache-barrier itself ? > > No, in general. Optimisers (particularly loop optimisers) can invent > accesses that didn't exist in the original source code. Normally they > would only be executed in correct circumstances, but with this > speculative execution, that might not be true. > > >> are never actually performed in cases where they'd be wrong. So how about: > >> > >> -mr10k-cache-barrier=load-store > >> Insert a cache barrier at the beginning of any sequentially-executed > >> series of instructions that contains a load or store. For the purposes > >> of this option, GCC can ignore loads and stores that it can prove > >> are an in-range access to: > >> > >> (a) the current function's stack frame; > >> (b) an incoming stack argument; > >> (b) an object with a link-time-constant address; or > >> (c) a block of uncached memory > > Can we recognize uncached memory in the instruction ? > > Well, I was just thinking about teaching the compiler about KSEG2, > the always-uncached XKPHYS addresses, etc. (Sorry for messing up > the bullet letters there!) The idea is that we have a correlation > between symbolic constants and C objects, so we can check whether > an offset in a symbolic constant is within the object. We already No doubt, this would be very helpfull. > have code to do this in other situations. But there is no correlation > between const_int addresses and C objects, and we cannot be sure that > a given const_int address existed in the original source code, so > I think the only safe thing is to check its uncached properties instead. > > I know all this must be frustrating. I'm sure your patches work great > as they are with current and past kernels, and current and past compilers. > The problem is that, if it becomes a mainline gcc feature, it needs to be > defined from first principles. Agreed, the design of any feature advantageously should be based on a clear (more or less formal) specification of what the compiler can do. > And we need to do that without assuming > that the accesses we're looking at existed in the original source code. > > FWIW, I'm happy to help update the patch once we've agreed on an This would be appreciated (of course :) Many thanks in advance! > option spec. Well, the option spec could be as listed above. With "store" as default for an empty option-string ("none" as default if the option isn't given at all). > > Richard > > kind regards peter PS: apologies for delaying the answer, i just couldn't concentrate on this topic recently. From rsandifo@nildram.co.uk Sun Dec 23 09:40:34 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Sun, 23 Dec 2007 09:40:44 +0000 (GMT) Received: from mk-outboundfilter-4.mail.uk.tiscali.com ([212.74.114.32]:45336 "EHLO mk-outboundfilter-4.mail.uk.tiscali.com") by ftp.linux-mips.org with ESMTP id S20025429AbXLWJke (ORCPT ); Sun, 23 Dec 2007 09:40:34 +0000 X-Trace: 3224809/mk-outboundfilter-2.mail.uk.tiscali.com/F2S/$MX-ACCEPTED/nildram-infrastructure/195.149.33.74 X-SBRS: None X-RemoteIP: 195.149.33.74 X-IP-MAIL-FROM: rsandifo@nildram.co.uk X-IP-BHB: Once X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ah4FAAq7bUfDlSFK/2dsb2JhbACBV5AFl1I Received: from smtp.nildram.co.uk ([195.149.33.74]) by smtp.f2s.tiscali.co.uk with ESMTP; 23 Dec 2007 09:39:28 +0000 Received: from firetop.home (85-211-134-127.dyn.gotadsl.co.uk [85.211.134.127]) by smtp.nildram.co.uk (Postfix) with ESMTP id 331922DC03B; Sun, 23 Dec 2007 09:39:27 +0000 (GMT) Received: from richard by firetop.home with local (Exim 4.63) (envelope-from ) id 1J6NIu-00018o-7I; Sun, 23 Dec 2007 09:39:28 +0000 From: Richard Sandiford To: peter fuerst Mail-Followup-To: peter fuerst ,Ralf Baechle , Thomas Bogendoerfer , Kumba , linux-mips@linux-mips.org, rsandifo@nildram.co.uk Cc: Ralf Baechle , Thomas Bogendoerfer , Kumba , linux-mips@linux-mips.org Subject: Re: [UPDATED PATCH] IP28 support References: Date: Sun, 23 Dec 2007 09:39:28 +0000 In-Reply-To: (peter fuerst's message of "Sun\, 23 Dec 2007 02\:44\:01 +0100 \(CET\)") Message-ID: <871w9d7nsf.fsf@firetop.home> User-Agent: Gnus/5.110006 (No Gnus v0.6) Emacs/21.4 (gnu/linux) 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: 17870 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: rsandifo@nildram.co.uk Precedence: bulk X-list: linux-mips peter fuerst writes: >> compile-time base+offset addresses. And as I said, the compiler is >> free to make up accesses that aren't in fact valid for cases where >> the access isn't made. E.g. if you had a loop with a stride of 128, >> the compiler could unroll the loop as many times as it likes. Some >> of the unrolled iterations might access areas outside the stack frame. > > You mean, the compiler would generate $sp+const_int accesses here, whose > validity is not known at compile-time - similar to foo() above ? Right. >> I think you're missing my point. If you access an I/O-mapped device >> through KSEG2 or an uncached XKPHYS address, is it not also physically >> possible (though clearly unwise) to access it through KSEG0 or a cached >> XKPHYS address too? So can you guarantee that every const_int cached >> address in a multi-platform kernel is not I/O-mapped on any of the r10k >> platforms? Or can you guarantee that the compiler will not manufacture >> such an address from an otherwise harmless address? > Hmm, it's not quite clear, how it could be manufactured. Similar to the above really, for combinations of suitably bizarre input code and compiler behaviour. Again, the problem isn't that such a thing is _likely_ to happen, just that it wouldn't be wrong for it to happen in non-r10k situations (and thus not likely to be treated as a "wrong-code" bug by gcc developers). >> Again, the key thing >> is to think about what the compiler can validly do on non-r10k platforms, >> however silly it might seem, and then make sure the workarounds cope >> with it. > > Do you think of accesses that essentially look like this ? > > if (machine_x) > *uncached(const_addr) = val; > else > *cached(const_addr) = val; Well, more generally, I was thinking of something like: if (machine_x) *cached(const_addr1) = ...; else ...blah... where const_addr1 might be harmful if !machine_x. > Fortunately (at least? even?) on IP28 cached access (hence a block read > request) to an I/O-device address is a non-issue. In this respect the > hardware design seems to follow the recommendations from the R10000 manual > (NACK from external agent?): > - if such an access graduates (i.e. a "real" access), a bus-error will occur. > - if not (i.e. mis-speculated), nothing happens. Ah, OK. That's what I was missing, thanks. (I suspect you and Ralf have explained that to me before, but it hadn't sunk in. Sorry!) > However, i don't yet know, how O2 behaves, or, if there exists any other > R10k-machine, which would need the software-workaround. OK. In that case, for the IP28 at least, I think the only issue with excluding cachable const_int addresses is that the compiler might somehow conspire to create an address that turns out to be, for some runs at least, an address in a DMA buffer. > Well, the option spec could be as listed above. With "store" as default > for an empty option-string ("none" as default if the option isn't given > at all). Sounds good. Thanks, it seems we have a plan ;) Richard From alon.barlev@gmail.com Sun Dec 23 15:34:08 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Sun, 23 Dec 2007 15:34:18 +0000 (GMT) Received: from ug-out-1314.google.com ([66.249.92.174]:62763 "EHLO ug-out-1314.google.com") by ftp.linux-mips.org with ESMTP id S20032395AbXLWPeI (ORCPT ); Sun, 23 Dec 2007 15:34:08 +0000 Received: by ug-out-1314.google.com with SMTP id k3so959198ugf.38 for ; Sun, 23 Dec 2007 07:33:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; bh=X9rNmo/KJE+WXaUbO8kAiZ0SpM045qO0BEym7UezwcA=; b=F4QiUT3CczpjUShjQ6hyWtXUnvjdqRDVGGisQIIS/cuD1f/on0LPn4qM8dgagOOEFCrHlXDkD0jfGM7/Dp2L9F0kZNfYmK2LGeS+GrBppf531pLBGrOuGJzyRWhVE8EpGv8ZImsgIfHWOzmA3XJzyoSN+ltW7FIkQwNMLs5WS7U= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; b=iyWso7E2Zd91rHU5FEqHyqRTTmNbo37IUbqKKuNkAB7DYrE6itIOhqEQXXCuhcvU5LHKhmhmNEXDFzdVukwTO72fTRahp+HrqNrsdem9pmErqHVvOvpRTNqXYzL2Mg7Fl78tU1suwfIykcdE8wev/S65By+KQ2MLJnw3eBllFbY= Received: by 10.66.220.17 with SMTP id s17mr2198295ugg.20.1198424038068; Sun, 23 Dec 2007 07:33:58 -0800 (PST) Received: by 10.67.117.17 with HTTP; Sun, 23 Dec 2007 07:33:58 -0800 (PST) Message-ID: <9e0cf0bf0712230733o3dfd54fcp4962ebf3f84cdff@mail.gmail.com> Date: Sun, 23 Dec 2007 17:33:58 +0200 From: "Alon Bar-Lev" To: linux-mips@ftp.linux-mips.org, LKML Subject: [MIPS] MEM_SDREFCFG is not defined for Alchemy DB1550 (compile fail) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 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@ftp.linux-mips.org Original-Recipient: rfc822;linux-mips@ftp.linux-mips.org X-archive-position: 17871 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: alon.barlev@gmail.com Precedence: bulk X-list: linux-mips Hello, When I have: CONFIG_MIPS_DB1550 CONFIG_SOC_AU1550 CONFIG_SOC_AU1X00 CONFIG_PM MEM_SDREFCFG is used at: arch/mips/au1000/common/power.c::pm_do_freq() While the MEM_SDREFCFG constant is declare only for CONFIG_SOC_AU1000, CONFIG_SOC_AU1500, CONFIG_SOC_AU1100 at: include/asm-mips/mach-au1x00/au1000.h Maybe MEM_SDREFCFG should be defined for CONFIG_SOC_AU1X00? Or there should be #ifdef for its usage in power.c? Best Regards, Alon Bar-Lev. From alon.barlev@gmail.com Sun Dec 23 18:22:23 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Sun, 23 Dec 2007 18:22:32 +0000 (GMT) Received: from ug-out-1314.google.com ([66.249.92.168]:5893 "EHLO ug-out-1314.google.com") by ftp.linux-mips.org with ESMTP id S20032895AbXLWSWX (ORCPT ); Sun, 23 Dec 2007 18:22:23 +0000 Received: by ug-out-1314.google.com with SMTP id k3so976678ugf.38 for ; Sun, 23 Dec 2007 10:22:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=FUHfUCzrO0wUM4wc5uS21wJjp2RnX8jYLCNSmVeDzCU=; b=XI2H8UWj6N4OUVt9adMY6IirJDJjiSAapTF1O0GdXx/4iCoYH4tlM3Am0udESGgPRzVBRYWBMc9FoZw7QhSJ+Mckv2OgF44jlgS9guRde91L1ytYynUyVvUHtspkLwtHDf+ndhrbaA8Zt2m9Dw305bBJkMaqvTJEpZQP4uzUupQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=CLo4Ki64M1JomDp8m4J4hUji2rmcGAXyDJtzk/FK/wlsqHbuwMTdcykhaSLTKGKWKE3pLUNa0+DmvFe+wagYlTjVCCh0CThbY9YreGd/TSUpCtRsIO7wF96YE8OOXPwb1vlLblD3Z+PsfY1/YcRyvIYCYoephekDdGYCc8GVylQ= Received: by 10.67.116.2 with SMTP id t2mr2085074ugm.62.1198434133079; Sun, 23 Dec 2007 10:22:13 -0800 (PST) Received: by 10.67.117.17 with HTTP; Sun, 23 Dec 2007 10:22:13 -0800 (PST) Message-ID: <9e0cf0bf0712231022o4a282e70i8cecd70ecc452505@mail.gmail.com> Date: Sun, 23 Dec 2007 20:22:13 +0200 From: "Alon Bar-Lev" To: linux-mips@ftp.linux-mips.org, LKML , ppopov@mvista.com Subject: Re: [MIPS] MEM_SDREFCFG is not defined for Alchemy DB1550 (compile fail) In-Reply-To: <9e0cf0bf0712230733o3dfd54fcp4962ebf3f84cdff@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <9e0cf0bf0712230733o3dfd54fcp4962ebf3f84cdff@mail.gmail.com> Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@ftp.linux-mips.org Original-Recipient: rfc822;linux-mips@ftp.linux-mips.org X-archive-position: 17872 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: alon.barlev@gmail.com Precedence: bulk X-list: linux-mips Hello, Forgot to write that I checked mips & linus gits, and the problem still exists. Best Regards, Alon Bar-Lev. On 12/23/07, Alon Bar-Lev wrote: > Hello, > > When I have: > CONFIG_MIPS_DB1550 > CONFIG_SOC_AU1550 > CONFIG_SOC_AU1X00 > CONFIG_PM > > MEM_SDREFCFG is used at: > arch/mips/au1000/common/power.c::pm_do_freq() > > While the MEM_SDREFCFG constant is declare only for CONFIG_SOC_AU1000, > CONFIG_SOC_AU1500, CONFIG_SOC_AU1100 at: > include/asm-mips/mach-au1x00/au1000.h > > Maybe MEM_SDREFCFG should be defined for CONFIG_SOC_AU1X00? > Or there should be #ifdef for its usage in power.c? > > Best Regards, > Alon Bar-Lev. > From flo@rfc822.org Sun Dec 23 19:55:14 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Sun, 23 Dec 2007 19:55:22 +0000 (GMT) Received: from hydra.gt.owl.de ([195.71.99.218]:7577 "EHLO hydra.gt.owl.de") by ftp.linux-mips.org with ESMTP id S20033703AbXLWTzO (ORCPT ); Sun, 23 Dec 2007 19:55:14 +0000 Received: by hydra.gt.owl.de (Postfix, from userid 1000) id 93E1793701; Sun, 23 Dec 2007 20:54:42 +0100 (CET) Date: Sun, 23 Dec 2007 20:54:42 +0100 From: Florian Lohoff To: linux-mips@linux-mips.org Subject: IP28 Installation Success report Was: [UPDATED PATCH] IP28 support Message-ID: <20071223195442.GA17311@paradigm.rfc822.org> References: <20071202120032.2A477C2EB6@solo.franken.de> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="6TrnltStXW4iwmi0" Content-Disposition: inline In-Reply-To: <20071202120032.2A477C2EB6@solo.franken.de> Organization: rfc822 - pure communication X-SpiderMe: mh-200712232045@listme.rfc822.org 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: 17873 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: flo@rfc822.org Precedence: bulk X-list: linux-mips --6TrnltStXW4iwmi0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Dec 02, 2007 at 01:00:32PM +0100, Thomas Bogendoerfer wrote: > Add support for SGI IP28 machines (Indigo 2 with R10k CPUs) > This work is mainly based on Peter Fuersts work. I thought an installation success report is sometimes nice to have: flo@ip28:~$ cat /proc/cpuinfo=20 system type : SGI Indigo2 processor : 0 cpu model : R10000 V2.5 FPU V0.0 BogoMIPS : 194.04 wait instruction : no microsecond timers : yes tlb_entries : 64 extra interrupt vector : no hardware watchpoint : yes ASEs implemented : shadow register sets : 1 VCED exceptions : not available VCEI exceptions : not available flo@ip28:~$ uptime 19:49:15 up 4 days, 9:09, 2 users, load average: 0.00, 0.00, 0.00 flo@ip28:~$ uname -a Linux ip28 2.6.24-rc5-g8b3ba06b-dirty #21 Tue Dec 18 12:48:29 CET 2007 mips= 64 GNU/Linux flo@ip28:~$ cat /proc/interrupts=20 CPU0 =20 0: 1 XT-PIC timer 2: 0 XT-PIC cascade 18: 0 MIPS local0 cascade 19: 0 MIPS local1 cascade 22: 1 MIPS Bus Error 23: 94680570 MIPS timer 25: 3863916 IP22 local 0 SGI WD93 26: 7 IP22 local 0 SGI WD93 27: 677582 IP22 local 0 SGI Seeq8003 31: 0 IP22 local 0 mapable0 cascade 33: 0 IP22 local 1 Front Panel 43: 1 IP22 local 2 EISA 44: 5 IP22 local 2 i8042, i8042 45: 6462546 IP22 local 2 IP22-Zilog ERR: 0 The maschine successfully compiled multiple gcc version and had no hickups so far ... Peter and Thomas did great work .... Flo --=20 Florian Lohoff flo@rfc822.org +49-171-2280134 security shall soon have neither - Benjamin Franklin --6TrnltStXW4iwmi0 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFHbr0CUaz2rXW+gJcRAop2AKCuNMfz+1N8CeFPui/169qNTg5ZdgCfVyoo xCwssQKevt24/Oj3ehEK1ic= =Or13 -----END PGP SIGNATURE----- --6TrnltStXW4iwmi0-- From post@pfrst.de Tue Dec 25 00:47:18 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 25 Dec 2007 00:47:26 +0000 (GMT) Received: from [84.159.79.95] ([84.159.79.95]:11947 "EHLO p549F4F5F.dip.t-dialin.net") by ftp.linux-mips.org with ESMTP id S20024732AbXLYArS (ORCPT ); Tue, 25 Dec 2007 00:47:18 +0000 Received: from mail1.pearl-online.net ([62.159.194.147]:58659 "EHLO mail1.pearl-online.net") by lappi.linux-mips.net with ESMTP id S1096297AbXLXAkS (ORCPT ); Mon, 24 Dec 2007 01:40:18 +0100 Received: from SNaIlmail.Peter (unknown [77.47.54.40]) by mail1.pearl-online.net (Postfix) with ESMTP id 6B55FC863; Mon, 24 Dec 2007 01:39:32 +0100 (CET) Received: from Opal.Peter (Opal.Peter [192.168.1.1]) by SNaIlmail.Peter (8.12.6/8.12.6/Sendmail/Linux 2.0.32) with ESMTP id lBO0dLOA000772; Mon, 24 Dec 2007 01:39:22 +0100 Received: from Opal.Peter (localhost [127.0.0.1]) by Opal.Peter (8.12.11.Beta0/8.12.11.Beta0/Sendmail/Linux 2.4.24-1-386) with ESMTP id lBO0dA2Y001993; Mon, 24 Dec 2007 01:39:11 +0100 Received: from localhost (pf@localhost) by Opal.Peter (8.12.11.Beta0/8.12.11.Beta0/Debian-1) with ESMTP id lBO0dAlS001989; Mon, 24 Dec 2007 01:39:10 +0100 X-Authentication-Warning: Opal.Peter: pf owned process doing -bs Date: Mon, 24 Dec 2007 01:39:10 +0100 (CET) From: post@pfrst.de X-Sender: pf@Opal.Peter To: Richard Sandiford Cc: Ralf Baechle , Thomas Bogendoerfer , Kumba , linux-mips@linux-mips.org Subject: Re: [UPDATED PATCH] IP28 support In-Reply-To: <871w9d7nsf.fsf@firetop.home> Message-ID: 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: 17874 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: post@pfrst.de Precedence: bulk X-list: linux-mips On Sun, 23 Dec 2007, Richard Sandiford wrote: > Date: Sun, 23 Dec 2007 09:39:28 +0000 > From: Richard Sandiford > To: peter fuerst > Cc: Ralf Baechle , > Thomas Bogendoerfer , > Kumba , linux-mips@linux-mips.org > Subject: Re: [UPDATED PATCH] IP28 support > > ... > Ah, OK. That's what I was missing, thanks. (I suspect you and Ralf > have explained that to me before, but it hadn't sunk in. Sorry!) Missed to explain that in time... Sorry! > ... kind regards peter From sshtylyov@ru.mvista.com Tue Dec 25 10:41:24 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 25 Dec 2007 10:41:32 +0000 (GMT) Received: from h155.mvista.com ([63.81.120.155]:41420 "EHLO imap.sh.mvista.com") by ftp.linux-mips.org with ESMTP id S20023087AbXLYKlY (ORCPT ); Tue, 25 Dec 2007 10:41:24 +0000 Received: from [192.168.1.234] (unknown [10.150.0.9]) by imap.sh.mvista.com (Postfix) with ESMTP id B35F03EC9; Tue, 25 Dec 2007 02:40:50 -0800 (PST) Message-ID: <4770DE51.5000205@ru.mvista.com> Date: Tue, 25 Dec 2007 13:41:21 +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: Alon Bar-Lev Cc: linux-mips@ftp.linux-mips.org, LKML Subject: Re: [MIPS] MEM_SDREFCFG is not defined for Alchemy DB1550 (compile fail) References: <9e0cf0bf0712230733o3dfd54fcp4962ebf3f84cdff@mail.gmail.com> In-Reply-To: <9e0cf0bf0712230733o3dfd54fcp4962ebf3f84cdff@mail.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@ftp.linux-mips.org Original-Recipient: rfc822;linux-mips@ftp.linux-mips.org X-archive-position: 17875 X-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. Alon Bar-Lev wrote: > When I have: > CONFIG_MIPS_DB1550 > CONFIG_SOC_AU1550 > CONFIG_SOC_AU1X00 > CONFIG_PM > MEM_SDREFCFG is used at: > arch/mips/au1000/common/power.c::pm_do_freq() PM code is generally broken and unmaintained, so no wonder. I don't remember if anyone has fixed CPU context restoration code (it uses a "skewed" stack frame). > While the MEM_SDREFCFG constant is declare only for CONFIG_SOC_AU1000, > CONFIG_SOC_AU1500, CONFIG_SOC_AU1100 at: > include/asm-mips/mach-au1x00/au1000.h > Maybe MEM_SDREFCFG should be defined for CONFIG_SOC_AU1X00? I've just looked into the Au1550 datasheet and indeed it doesn't have such register; its SDDRAM controller is not compatible with older SoCs. > Or there should be #ifdef for its usage in power.c? Looks like you'll have to invent something... ;-) > Best Regards, > Alon Bar-Lev. WBR, Sergei From ralf@linux-mips.org Tue Dec 25 14:33:14 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 25 Dec 2007 14:33:17 +0000 (GMT) Received: from localhost.localdomain ([127.0.0.1]:38885 "EHLO dl5rb.ham-radio-op.net") by ftp.linux-mips.org with ESMTP id S28576160AbXLYOdO (ORCPT ); Tue, 25 Dec 2007 14:33:14 +0000 Received: from denk.linux-mips.net (denk.linux-mips.net [127.0.0.1]) by dl5rb.ham-radio-op.net (8.14.1/8.13.8) with ESMTP id lBPEWiJG000605; Tue, 25 Dec 2007 15:32:44 +0100 Received: (from ralf@localhost) by denk.linux-mips.net (8.14.1/8.14.1/Submit) id lBPEWf3Y000604; Tue, 25 Dec 2007 15:32:41 +0100 Date: Tue, 25 Dec 2007 15:32:41 +0100 From: Ralf Baechle To: Sergei Shtylyov Cc: Alon Bar-Lev , linux-mips@ftp.linux-mips.org, LKML Subject: Re: [MIPS] MEM_SDREFCFG is not defined for Alchemy DB1550 (compile fail) Message-ID: <20071225143240.GA29231@linux-mips.org> References: <9e0cf0bf0712230733o3dfd54fcp4962ebf3f84cdff@mail.gmail.com> <4770DE51.5000205@ru.mvista.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4770DE51.5000205@ru.mvista.com> User-Agent: Mutt/1.5.17 (2007-11-01) Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@ftp.linux-mips.org Original-Recipient: rfc822;linux-mips@ftp.linux-mips.org X-archive-position: 17876 X-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 25, 2007 at 01:41:21PM +0300, Sergei Shtylyov wrote: >> When I have: >> CONFIG_MIPS_DB1550 >> CONFIG_SOC_AU1550 >> CONFIG_SOC_AU1X00 >> CONFIG_PM > >> MEM_SDREFCFG is used at: >> arch/mips/au1000/common/power.c::pm_do_freq() > > PM code is generally broken and unmaintained, so no wonder. I don't > remember if anyone has fixed CPU context restoration code (it uses a > "skewed" stack frame). > >> While the MEM_SDREFCFG constant is declare only for CONFIG_SOC_AU1000, >> CONFIG_SOC_AU1500, CONFIG_SOC_AU1100 at: >> include/asm-mips/mach-au1x00/au1000.h > >> Maybe MEM_SDREFCFG should be defined for CONFIG_SOC_AU1X00? > > I've just looked into the Au1550 datasheet and indeed it doesn't have > such register; its SDDRAM controller is not compatible with older SoCs. > >> Or there should be #ifdef for its usage in power.c? > > Looks like you'll have to invent something... ;-) > >> Best Regards, >> Alon Bar-Lev. So I guess it's time to mark the whole PM stuff as BROKEN? Ralf From alon.barlev@gmail.com Tue Dec 25 17:04:25 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 25 Dec 2007 17:04:34 +0000 (GMT) Received: from ug-out-1314.google.com ([66.249.92.169]:2290 "EHLO ug-out-1314.google.com") by ftp.linux-mips.org with ESMTP id S28576521AbXLYREZ (ORCPT ); Tue, 25 Dec 2007 17:04:25 +0000 Received: by ug-out-1314.google.com with SMTP id k3so1306217ugf.38 for ; Tue, 25 Dec 2007 09:04:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=Ixh6lv2cB14se4hLyU3fB1oJyY/anfBTFv0bMmHDQwQ=; b=fbYoZW2UT1QP7yo3TzVUNOwc2bgxXBrWabUoIrZdQ/DF86Rvr8W7z0jcH2rkMTvjDfvwazkuOqJhqC8IvaV6uhfy3huZZ53UGY6cTvPUnVidjwwJ02BEwZjxc/7iCrjDz+4oZSa397zCkAfhbkw7GXWNnWXPAo6LIORi1mDl7Qo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=HNG+6OslokDP9P41l0iHfbGQqUkqaf0ePKiH1fmn1xnnluiXc0LxiRv0K7CHSQxyv9OrkhVs2CJ4TEeYW2r1Rkr67A0UzGOX1qOCX7JvAZ5FruPfbapv77Fy4rOFp/hEmGoHOA2T2QE1OTSAzKW8jGmANHyz5gfbbi3QU6d/4kM= Received: by 10.67.116.9 with SMTP id t9mr4765344ugm.77.1198602254626; Tue, 25 Dec 2007 09:04:14 -0800 (PST) Received: by 10.67.117.17 with HTTP; Tue, 25 Dec 2007 09:04:14 -0800 (PST) Message-ID: <9e0cf0bf0712250904t213d623bp977db54b6be5e3e@mail.gmail.com> Date: Tue, 25 Dec 2007 19:04:14 +0200 From: "Alon Bar-Lev" To: "Sergei Shtylyov" Subject: Re: [MIPS] MEM_SDREFCFG is not defined for Alchemy DB1550 (compile fail) Cc: linux-mips@ftp.linux-mips.org, LKML , "Ralf Baechle" In-Reply-To: <4770DE51.5000205@ru.mvista.com> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <9e0cf0bf0712230733o3dfd54fcp4962ebf3f84cdff@mail.gmail.com> <4770DE51.5000205@ru.mvista.com> Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@ftp.linux-mips.org Original-Recipient: rfc822;linux-mips@ftp.linux-mips.org X-archive-position: 17877 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: alon.barlev@gmail.com Precedence: bulk X-list: linux-mips Thank you for your reply! On 12/25/07, Sergei Shtylyov wrote: > PM code is generally broken and unmaintained, so no wonder. I don't > remember if anyone has fixed CPU context restoration code (it uses a "skewed" > stack frame). So suspend modes on these boards are not supported? Only "Always On" configuration is supported? Or there is another method to preserve power? Best Regards, Alon Bar-Lev. From sshtylyov@ru.mvista.com Tue Dec 25 17:18:52 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 25 Dec 2007 17:18:54 +0000 (GMT) Received: from h155.mvista.com ([63.81.120.155]:58065 "EHLO imap.sh.mvista.com") by ftp.linux-mips.org with ESMTP id S28576532AbXLYRSw (ORCPT ); Tue, 25 Dec 2007 17:18:52 +0000 Received: from [192.168.1.234] (unknown [10.150.0.9]) by imap.sh.mvista.com (Postfix) with ESMTP id ADDAB3EC9; Tue, 25 Dec 2007 09:18:19 -0800 (PST) Message-ID: <47713B7A.9050102@ru.mvista.com> Date: Tue, 25 Dec 2007 20:18:50 +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: Alon Bar-Lev Cc: linux-mips@ftp.linux-mips.org, LKML , Ralf Baechle Subject: Re: [MIPS] MEM_SDREFCFG is not defined for Alchemy DB1550 (compile fail) References: <9e0cf0bf0712230733o3dfd54fcp4962ebf3f84cdff@mail.gmail.com> <4770DE51.5000205@ru.mvista.com> <9e0cf0bf0712250904t213d623bp977db54b6be5e3e@mail.gmail.com> In-Reply-To: <9e0cf0bf0712250904t213d623bp977db54b6be5e3e@mail.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@ftp.linux-mips.org Original-Recipient: rfc822;linux-mips@ftp.linux-mips.org X-archive-position: 17878 X-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 Alon Bar-Lev wrote: >> PM code is generally broken and unmaintained, so no wonder. I don't >>remember if anyone has fixed CPU context restoration code (it uses a "skewed" >>stack frame). > So suspend modes on these boards are not supported? > Only "Always On" configuration is supported? Sleep mode is supported according to the code. But as I've said PM bits haven't been maintained -- probably since the submission. > Best Regards, > Alon Bar-Lev. WBR, Sergei From alon.barlev@gmail.com Tue Dec 25 17:35:49 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 25 Dec 2007 17:35:57 +0000 (GMT) Received: from ug-out-1314.google.com ([66.249.92.173]:9869 "EHLO ug-out-1314.google.com") by ftp.linux-mips.org with ESMTP id S28576562AbXLYRft (ORCPT ); Tue, 25 Dec 2007 17:35:49 +0000 Received: by ug-out-1314.google.com with SMTP id k3so1310093ugf.38 for ; Tue, 25 Dec 2007 09:35:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=RiVsQZ51Yr5B96HvHMyDueMOvn/xPBis6n+3saIs06c=; b=l4gY1CPMYYCJ0J8tI5p29peEivRXUeIXSPPtb8KRolPhpeKhEI4MuYoGiDPZOIGjtA5SA3Cb76VWSZl0liobnSZkxlSrEOnvU9oFDSn24r6KK5Ncch6sMZRbfy0My99OXHoQwgYZ0HVk7cnfc0mzR53eW4T/omMNmuCN+wIv9Is= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=uRR2/EQVgbpQJCrDi2JR8lCSGgXKJGbIJNhKLkj9tfG5iR6sGk59S2Ml3NMqRjs4iAWsB2SIvS1xJtI2yuzAKyfvnQNelKJQSTs0gxjrh7Vnu12r+JC1zPoYJB85fWcdf8pIh0mw29H96RHIM+AIX96hgOcY8tg3w4VXjbOcOrI= Received: by 10.67.116.7 with SMTP id t7mr4941512ugm.38.1198604138745; Tue, 25 Dec 2007 09:35:38 -0800 (PST) Received: by 10.67.117.17 with HTTP; Tue, 25 Dec 2007 09:35:38 -0800 (PST) Message-ID: <9e0cf0bf0712250935m57b36328h91bdcd45eee5987e@mail.gmail.com> Date: Tue, 25 Dec 2007 19:35:38 +0200 From: "Alon Bar-Lev" To: "Sergei Shtylyov" Subject: Re: [MIPS] MEM_SDREFCFG is not defined for Alchemy DB1550 (compile fail) Cc: linux-mips@ftp.linux-mips.org, LKML , "Ralf Baechle" In-Reply-To: <47713B7A.9050102@ru.mvista.com> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <9e0cf0bf0712230733o3dfd54fcp4962ebf3f84cdff@mail.gmail.com> <4770DE51.5000205@ru.mvista.com> <9e0cf0bf0712250904t213d623bp977db54b6be5e3e@mail.gmail.com> <47713B7A.9050102@ru.mvista.com> Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@ftp.linux-mips.org Original-Recipient: rfc822;linux-mips@ftp.linux-mips.org X-archive-position: 17879 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: alon.barlev@gmail.com Precedence: bulk X-list: linux-mips On 12/25/07, Sergei Shtylyov wrote: > > So suspend modes on these boards are not supported? > > Only "Always On" configuration is supported? > > Sleep mode is supported according to the code. But as I've said PM bits > haven't been maintained -- probably since the submission. Thanks! Will it be maintained? Are there any plans? Is there, a missing features list (TODO)? Or this is completely unsupported board? Best Regards, Alon Bar-Lev. From sshtylyov@ru.mvista.com Tue Dec 25 18:00:17 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 25 Dec 2007 18:00:26 +0000 (GMT) Received: from rtsoft3.corbina.net ([85.21.88.6]:26200 "EHLO buildserver.ru.mvista.com") by ftp.linux-mips.org with ESMTP id S28576632AbXLYSAR (ORCPT ); Tue, 25 Dec 2007 18:00:17 +0000 Received: from wasted.dev.rtsoft.ru (unknown [10.150.0.9]) by buildserver.ru.mvista.com (Postfix) with ESMTP id 3BD5A8816; Tue, 25 Dec 2007 23:00:16 +0400 (SAMT) From: Sergei Shtylyov Organization: MontaVista Software Inc. To: ralf@linux-mips.org Subject: [PATCH] Alchemy: fix modpost warning Date: Tue, 25 Dec 2007 21:00:45 +0300 User-Agent: KMail/1.5 Cc: linux-mips@linux-mips.org MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200712252100.47365.sshtylyov@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: 17880 X-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 WARNING: vmlinux.o(.text+0x1ca608): Section mismatch: reference to .init.text: add_wired_entry (between 'config_access' and 'config_read') by refactoring the code calling add_wired_entry() from config_access() to a separate function which is called from aau1x_pci_setup(). While at it: - make some unnecassarily global variables 'static'; - fix the letter case, whitespace, etc. in the comments... Signed-off-by: Sergei Shtylyov arch/mips/au1000/common/pci.c | 8 ++++-- arch/mips/pci/ops-au1000.c | 53 ++++++++++++++++++++---------------------- 2 files changed, 32 insertions(+), 29 deletions(-) Index: linux-2.6/arch/mips/au1000/common/pci.c =================================================================== --- linux-2.6.orig/arch/mips/au1000/common/pci.c +++ linux-2.6/arch/mips/au1000/common/pci.c @@ -1,8 +1,8 @@ /* * BRIEF MODULE DESCRIPTION - * Alchemy/AMD Au1x00 pci support. + * Alchemy/AMD Au1x00 PCI support. * - * Copyright 2001,2002,2003 MontaVista Software Inc. + * Copyright 2001-2003, 2007 MontaVista Software Inc. * Author: MontaVista Software, Inc. * ppopov@mvista.com or source@mvista.com * @@ -66,6 +66,8 @@ static unsigned long virt_io_addr; static int __init au1x_pci_setup(void) { + extern void au1x_pci_cfg_init(void); + #if defined(CONFIG_SOC_AU1500) || defined(CONFIG_SOC_AU1550) virt_io_addr = (unsigned long)ioremap(Au1500_PCI_IO_START, Au1500_PCI_IO_END - Au1500_PCI_IO_START + 1); @@ -94,6 +96,8 @@ static int __init au1x_pci_setup(void) set_io_port_base(virt_io_addr); #endif + au1x_pci_cfg_init(); + register_pci_controller(&au1x_controller); return 0; } Index: linux-2.6/arch/mips/pci/ops-au1000.c =================================================================== --- linux-2.6.orig/arch/mips/pci/ops-au1000.c +++ linux-2.6/arch/mips/pci/ops-au1000.c @@ -1,8 +1,8 @@ /* * BRIEF MODULE DESCRIPTION - * Alchemy/AMD Au1x00 pci support. + * Alchemy/AMD Au1x00 PCI support. * - * Copyright 2001,2002,2003 MontaVista Software Inc. + * Copyright 2001-2003, 2007 MontaVista Software Inc. * Author: MontaVista Software, Inc. * ppopov@mvista.com or source@mvista.com * @@ -69,10 +69,27 @@ void mod_wired_entry(int entry, unsigned write_c0_pagemask(old_pagemask); } -struct vm_struct *pci_cfg_vm; +static struct vm_struct *pci_cfg_vm; static int pci_cfg_wired_entry; -static int first_cfg = 1; -unsigned long last_entryLo0, last_entryLo1; +static unsigned long last_entryLo0, last_entryLo1; + +/* + * We can't ioremap the entire pci config space because it's too large. + * Nor can we call ioremap dynamically because some device drivers use + * the PCI config routines from within interrupt handlers and that + * becomes a problem in get_vm_area(). We use one wired TLB to handle + * all config accesses for all busses. + */ +void __init au1x_pci_cfg_init(void) +{ + /* Reserve a wired entry for PCI config accesses */ + pci_cfg_vm = get_vm_area(0x2000, VM_IOREMAP); + if (!pci_cfg_vm) + panic(KERN_ERR "PCI unable to get vm area\n"); + pci_cfg_wired_entry = read_c0_wired(); + add_wired_entry(0, 0, (unsigned long)pci_cfg_vm->addr, PM_4K); + last_entryLo0 = last_entryLo1 = 0xffffffff; +} static int config_access(unsigned char access_type, struct pci_bus *bus, unsigned int dev_fn, unsigned char where, @@ -97,27 +114,6 @@ static int config_access(unsigned char a Au1500_PCI_STATCMD); au_sync_udelay(1); - /* - * We can't ioremap the entire pci config space because it's - * too large. Nor can we call ioremap dynamically because some - * device drivers use the pci config routines from within - * interrupt handlers and that becomes a problem in get_vm_area(). - * We use one wired tlb to handle all config accesses for all - * busses. To improve performance, if the current device - * is the same as the last device accessed, we don't touch the - * tlb. - */ - if (first_cfg) { - /* reserve a wired entry for pci config accesses */ - first_cfg = 0; - pci_cfg_vm = get_vm_area(0x2000, VM_IOREMAP); - if (!pci_cfg_vm) - panic(KERN_ERR "PCI unable to get vm area\n"); - pci_cfg_wired_entry = read_c0_wired(); - add_wired_entry(0, 0, (unsigned long)pci_cfg_vm->addr, PM_4K); - last_entryLo0 = last_entryLo1 = 0xffffffff; - } - /* Allow board vendors to implement their own off-chip idsel. * If it doesn't succeed, may as well bail out at this point. */ @@ -144,9 +140,12 @@ static int config_access(unsigned char a /* page boundary */ cfg_base = cfg_base & PAGE_MASK; + /* + * To improve performance, if the current device is the same as + * the last device accessed, we don't touch the TLB. + */ entryLo0 = (6 << 26) | (cfg_base >> 6) | (2 << 3) | 7; entryLo1 = (6 << 26) | (cfg_base >> 6) | (0x1000 >> 6) | (2 << 3) | 7; - if ((entryLo0 != last_entryLo0) || (entryLo1 != last_entryLo1)) { mod_wired_entry(pci_cfg_wired_entry, entryLo0, entryLo1, (unsigned long)pci_cfg_vm->addr, PM_4K); From zyj001et@gmail.com Wed Dec 26 06:38:26 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 26 Dec 2007 06:38:34 +0000 (GMT) Received: from hs-out-0708.google.com ([64.233.178.243]:1322 "EHLO hs-out-2122.google.com") by ftp.linux-mips.org with ESMTP id S20025627AbXLZGi0 (ORCPT ); Wed, 26 Dec 2007 06:38:26 +0000 Received: by hs-out-2122.google.com with SMTP id l65so1671460hsc.0 for ; Tue, 25 Dec 2007 22:38:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:mime-version:content-type; bh=i1QMaUx7s5Jrdzp4N3BGtRjr7ocTU5iOoJmbJjxZ26I=; b=WmJqEtDU6q2c6k3nz5RUjnrbfEDY+ds6xquoBKq3VTR+FLUGTSlL2hGHSJsYipaA7smWejJx+Isp1YQdc0NrVavYF5a9x4/fLzoXkK2vK9p+Q7f6caqCX860C7+KN9pD9j9qTgkxCEBom4+7BU6KCJAvZsINLEtevKtrfsNSTII= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:mime-version:content-type; b=f3R5g/uHWUWUqJPwU0J//uthDoWGNPG5ZMgul3Ngt2p/75IzD686A9ZPmTu8pLlHsBqFRXsv7FGeHutsOfPJBHfH9YLsOaMcU6AaIUjV1gjYouzhBBDvL0zw0cw8+KZMrlUhpSuVtL12+r1NDtjyzB/DnnaiHzvhlQRZjtEKivA= Received: by 10.150.157.11 with SMTP id f11mr1602162ybe.108.1198651104817; Tue, 25 Dec 2007 22:38:24 -0800 (PST) Received: by 10.150.51.3 with HTTP; Tue, 25 Dec 2007 22:38:24 -0800 (PST) Message-ID: <47f174260712252238x80b76arafa15a0153d3f40d@mail.gmail.com> Date: Wed, 26 Dec 2007 14:38:24 +0800 From: "Zhou YaJin" To: linux-mips@linux-mips.org Subject: admulator: a simulator of adm5120 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_2875_25263922.1198651104811" Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 17881 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: zyj001et@gmail.com Precedence: bulk X-list: linux-mips ------=_Part_2875_25263922.1198651104811 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Hi everyone, I am glad to release admulator-a simulator of adm5120. Currently it can run linux 2.6 kernel and openwrt. website: http://admulator.sf.net If you have any question about admulator, please contact me. Thanks :) Admulator is a full system simulator of adm5120 soc. It simulates a mips32 cpu core and other devices. Currently it can run linux 2.6 kernel and openwrt for adm5120. The entire source code of admulator is distributed under GPL. Some of the features include: - full system simulation. the ability to run unmodified linux kernel and openwrt. - mips32 cpu core without fpu support - 4Mbytes flash simulation(including CFI Interface) - duart simulation - gdb interface Missing features : - no switch core simulation in current release - no binary translation ------=_Part_2875_25263922.1198651104811 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Hi everyone, I am glad to release admulator-a simulator of adm5120. Currently it can run linux 2.6 kernel and openwrt.
website:
http://admulator.sf.net
If you have any question about admulator, please contact me. Thanks :)

Admulator is a full system simulator of adm5120 soc. It simulates a mips32 cpu core and other devices. Currently it can run linux 2.6 kernel and openwrt for adm5120. The entire source code of admulator is distributed under GPL.

Some of the features include:

  • full system simulation. the ability to run unmodified linux kernel and openwrt.
  • mips32 cpu core without fpu support
  • 4Mbytes flash simulation(including CFI Interface)
  • duart simulation
  • gdb interface

Missing features :

  • no switch core simulation in current release
  • no binary translation




------=_Part_2875_25263922.1198651104811-- From ASinha@zeugmasystems.com Thu Dec 27 02:29:10 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 27 Dec 2007 02:29:18 +0000 (GMT) Received: from mail.zeugmasystems.com ([192.139.122.66]:40796 "EHLO zeugmasystems.com") by ftp.linux-mips.org with ESMTP id S20034523AbXL0C3J (ORCPT ); Thu, 27 Dec 2007 02:29:09 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C84830.3F0C6997" Subject: question about oprofile support Date: Wed, 26 Dec 2007 18:28:58 -0800 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: question about oprofile support Thread-Index: AchIMDwwQspU45gHS3mmRD2rNDCO/Q== From: "Anirban Sinha" 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: 17882 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: ASinha@zeugmasystems.com Precedence: bulk X-list: linux-mips This is a multi-part message in MIME format. ------_=_NextPart_001_01C84830.3F0C6997 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi: =20 Linux-mips.org states: (http://www.linux-mips.org/wiki/Oprofile)=20 =20 "Oprofile support is available at the time of this writing only in the Sourceforge Oprofile CVS repository; released versions are either lacking support for MIPS or are unusable due to bugs" =20 I am wondering if this is still true. If we want to have oprofile support on mips hardware, do we have to checkout the HEAD revision from oprofile cvs repository or is it already available from the standard 0.9.3 release?=20 =20 Thanks in advance to anyone who can throw any lights on this. =20 Cheers, =20 Ani =20 ------_=_NextPart_001_01C84830.3F0C6997 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi:

 

Linux-mips.org states: (http://www.linux-mips.or= g/wiki/Oprofile)

 

“Oprofile support is available at the time of = this writing only in the Sourceforge Oprofile CVS repository; released = versions are either lacking support for MIPS or are unusable due to = bugs”

 

I am wondering if this is still true. If we want to = have oprofile support on mips hardware, do we have to checkout the HEAD = revision from oprofile cvs repository or is it already available from the standard = 0.9.3 release?

 

Thanks in advance to anyone who can throw any = lights on this.

 

Cheers,

 

Ani

 

------_=_NextPart_001_01C84830.3F0C6997-- From ASinha@zeugmasystems.com Thu Dec 27 05:45:09 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 27 Dec 2007 05:45:17 +0000 (GMT) Received: from mail.zeugmasystems.com ([192.139.122.66]:12135 "EHLO zeugmasystems.com") by ftp.linux-mips.org with ESMTP id S20023067AbXL0FpJ convert rfc822-to-8bit (ORCPT ); Thu, 27 Dec 2007 05:45:09 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8BIT Subject: RE: question about oprofile support Date: Wed, 26 Dec 2007 21:44:41 -0800 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: question about oprofile support Thread-Index: AchIMDwwQspU45gHS3mmRD2rNDCO/QAGrc6A References: From: "Anirban Sinha" 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: 17883 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: ASinha@zeugmasystems.com Precedence: bulk X-list: linux-mips If I am not too wrong, I think this is what the picture is like as far as the mips support for oprfile goes: Oprofile 0.9.2 release version supports mips architecture partially. Their release notes says: "Support for MIPS 5K, 20K, 25K, and 34K added." However, support for R10000, R12000, R12000, RM7000, RM9000, SB1 / SB1A, VR5432, VR5500 processors are only available through the CVS checkout: "The R10000, R12000, R12000, RM7000, RM9000, SB1 / SB1A, VR5432, VR5500 processors are supported by the CVS version of the userspace tools; support for further is in the queue." If I am wrong in understanding this, please correct me. Cheers, Ani From: linux-mips-bounce@linux-mips.org [mailto:linux-mips-bounce@linux-mips.org] On Behalf Of Anirban Sinha Sent: Wednesday, December 26, 2007 6:29 PM To: linux-mips@linux-mips.org Subject: question about oprofile support Hi: Linux-mips.org states: (http://www.linux-mips.org/wiki/Oprofile) "Oprofile support is available at the time of this writing only in the Sourceforge Oprofile CVS repository; released versions are either lacking support for MIPS or are unusable due to bugs" I am wondering if this is still true. If we want to have oprofile support on mips hardware, do we have to checkout the HEAD revision from oprofile cvs repository or is it already available from the standard 0.9.3 release? Thanks in advance to anyone who can throw any lights on this. Cheers, Ani   From flo@rfc822.org Thu Dec 27 09:04:02 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 27 Dec 2007 09:04:11 +0000 (GMT) Received: from hydra.gt.owl.de ([195.71.99.218]:2983 "EHLO hydra.gt.owl.de") by ftp.linux-mips.org with ESMTP id S20027298AbXL0JEC (ORCPT ); Thu, 27 Dec 2007 09:04:02 +0000 Received: by hydra.gt.owl.de (Postfix, from userid 1000) id DD73993701; Thu, 27 Dec 2007 10:04:01 +0100 (CET) Date: Thu, 27 Dec 2007 10:04:01 +0100 From: Florian Lohoff To: linux-mips@linux-mips.org Subject: MC Bus Error / tcp_ack_saw_tstamp Was: IP28 Installation Success report Message-ID: <20071227090401.GA3393@paradigm.rfc822.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="gKMricLos+KVdGMg" Content-Disposition: inline Organization: rfc822 - pure communication X-SpiderMe: mh-200712270957@listme.rfc822.org 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: 17884 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: flo@rfc822.org Precedence: bulk X-list: linux-mips --gKMricLos+KVdGMg Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Dec 23, 2007 at 08:54:42PM +0100, Florian Lohoff wrote: > I thought an installation success report is sometimes nice to have: Linux ip28 2.6.24-rc5-g8b3ba06b-dirty #21 Tue Dec 18 12:48:29 CET 2007 mips= 64 GNU/Linux After ~10 days uptime and multiple gcc builds. Logging in via ssh=20 and issueing an "ls" in the build directory: MC Bus Error GIO error 0x401: