From tiansm@lemote.com Wed Aug 1 01:48:02 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 01 Aug 2007 01:48:04 +0100 (BST) Received: from [222.92.8.141] ([222.92.8.141]:57232 "HELO lemote.com") by ftp.linux-mips.org with SMTP id S20021428AbXHAAsC (ORCPT ); Wed, 1 Aug 2007 01:48:02 +0100 Received: (qmail 26100 invoked by uid 511); 1 Aug 2007 00:53:01 -0000 Received: from unknown (HELO ?192.168.2.233?) (192.168.2.233) by lemote.com with SMTP; 1 Aug 2007 00:53:01 -0000 Message-ID: <46AFD82D.9070304@lemote.com> Date: Wed, 01 Aug 2007 08:47:41 +0800 From: Songmao Tian User-Agent: Icedove 1.5.0.8 (X11/20061116) MIME-Version: 1.0 To: Ralf Baechle CC: Dajie Tan , linux-mips Subject: Re: [PATCH] 16K page size in 32 bit kernel References: <20070731130950.GA5540@sw-linux.com> <20070731100027.GA3983@linux-mips.org> <46AF3DEE.2080603@lemote.com> <20070731204532.GA22036@linux-mips.org> In-Reply-To: <20070731204532.GA22036@linux-mips.org> 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: 15969 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: tiansm@lemote.com Precedence: bulk X-list: linux-mips Ralf Baechle wrote: > On Tue, Jul 31, 2007 at 09:49:34PM +0800, Songmao Tian wrote: > > >> I think the following is more complete? >> >> #ifdef CONFIG_64BIT_PHYS_ADDR >> -#define PGDIR_SHIFT 21 >> +#define PGDIR_SHIFT (PAGE_SHIFT + (PAGE_SHIFT + PTE_ORDER - 3)) >> #else >> -#define PGDIR_SHIFT 22 >> +#define PGDIR_SHIFT (PAGE_SHIFT + (PAGE_SHIFT + PTE_ORDER - 2)) >> #endif >> > > Better suggestion :-) > > Ralf > > Signed-off-by: Ralf Baechle > > diff --git a/include/asm-mips/pgtable-32.h b/include/asm-mips/pgtable-32.h > index 2fbd47e..ff29485 100644 > --- a/include/asm-mips/pgtable-32.h > +++ b/include/asm-mips/pgtable-32.h > @@ -43,11 +43,7 @@ extern int add_temporary_entry(unsigned long entrylo0, unsigned long entrylo1, > */ > > /* PGDIR_SHIFT determines what a third-level page table entry can map */ > -#ifdef CONFIG_64BIT_PHYS_ADDR > -#define PGDIR_SHIFT 21 > -#else > -#define PGDIR_SHIFT 22 > -#endif > +#define PGDIR_SHIFT (2 * PAGE_SHIFT + PTE_ORDER - PTE_T_LOG2) > #define PGDIR_SIZE (1UL << PGDIR_SHIFT) > #define PGDIR_MASK (~(PGDIR_SIZE-1)) > > > > Sure:) Tian From domen.puncer@telargo.com Wed Aug 1 08:28:16 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 01 Aug 2007 08:28:18 +0100 (BST) Received: from out002.atlarge.net ([129.41.63.60]:14822 "EHLO out002.atlarge.net") by ftp.linux-mips.org with ESMTP id S20021689AbXHAH2Q (ORCPT ); Wed, 1 Aug 2007 08:28:16 +0100 Received: from hpmailfe-01.atlarge.net ([10.100.60.156]) by out002.atlarge.net with Microsoft SMTPSVC(6.0.3790.1830); Wed, 1 Aug 2007 02:27:18 -0500 Received: from localhost ([213.250.36.225]) by hpmailfe-01.atlarge.net with Microsoft SMTPSVC(6.0.3790.1830); Wed, 1 Aug 2007 02:27:17 -0500 Date: Wed, 1 Aug 2007 09:28:07 +0200 From: Domen Puncer To: Domen Puncer Cc: Russell King , David Brownell , linuxppc-dev@ozlabs.org, Christoph Hellwig , linux-mips@linux-mips.org Subject: Generic clk.h wrappers? [Was: Re: [PATCH 1/3] powerpc clk.h interface for platforms] Message-ID: <20070801072807.GL4529@moe.telargo.com> References: <20070711093113.GE4375@moe.telargo.com> <200707110856.58463.david-b@pacbell.net> <20070711161633.GA4846@lst.de> <200707111002.55119.david-b@pacbell.net> <20070711203454.GC2301@flint.arm.linux.org.uk> <20070713091203.GE11476@nd47.coderock.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20070713091203.GE11476@nd47.coderock.org> User-Agent: Mutt/1.5.12-2006-07-14 X-OriginalArrivalTime: 01 Aug 2007 07:27:17.0947 (UTC) FILETIME=[63ECB8B0:01C7D40D] Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 15970 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: domen.puncer@telargo.com Precedence: bulk X-list: linux-mips On 13/07/07 11:12 +0200, Domen Puncer wrote: > On 11/07/07 21:34 +0100, Russell King wrote: > > On Wed, Jul 11, 2007 at 10:02:54AM -0700, David Brownell wrote: > > > On Wednesday 11 July 2007, Christoph Hellwig wrote: > > > > On Wed, Jul 11, 2007 at 08:56:58AM -0700, David Brownell wrote: > > > > > > Umm, this is about the fifth almost identical implementation of > > > > > > the clk_ functions. Please, please put it into common code. > > > > > > > > > > > > And talk to the mips folks which just got a similar comment from me. > > > > > > > > > > You mean like a lib/clock.c core, rather than an opsvector? > > > > > > > > I mean an ops vector and surrounding wrappers. Every architecture > > > > is reimplementing their own dispatch table which is rather annoying. > > > > > > ARM doesn't. :) > > > > > > But then, nobody expects one kernel to support more than one > > > vendor's ARM chips; or usually, more than one generation of > > > that vendor's chips. So any dispatch table is specific to > > > a given platform, and tuned to its quirks. Not much to share > > > between OMAP and AT91, for example, except in some cases maybe > > > an arm926ejs block. > > > > And also the information stored within a 'struct clk' is very platform > > dependent. In the most basic situation, 'struct clk' may not actually > > be a structure, but the clock rate. All functions with the exception of > > clk_get() and clk_get_rate() could well be no-ops, clk_get() just returns > > the 'struct clk' representing the rate and 'clk_get_rate' returns that > > as an integer. > > > > More complex setups might want 'struct clk' to contain the address of a > > clock enable register, the bit position to enable that clock source, the > > clock rate, a refcount, and so on, all of which would be utterly useless > > for a platform which had fixed rate clocks. > > The patch that triggered this discussion is at the end. > It doesn't make any assumption on struct clk, it's just a > wrapper around functions from clk.h. > Point of this patch was to abstract exported functions, since > arch/powerpc/ can support multiple platfroms in one binary. So... the thread just ended without any consensus, ACK or whatever. Choices I see: - have EXPORT_SYMBOL for clk.h functions in ie. lib/clock.c and have every implemenation fill some global struct. - leave this patch as it is, abstraction only for arch/powerpc/. - or I can just forget about this, and leave it for the next sucker who will want nicer clock handling in some driver. Domen From tiansm@lemote.com Wed Aug 1 08:57:04 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 01 Aug 2007 08:57:12 +0100 (BST) Received: from [222.92.8.141] ([222.92.8.141]:21681 "HELO lemote.com") by ftp.linux-mips.org with SMTP id S20021676AbXHAH5E (ORCPT ); Wed, 1 Aug 2007 08:57:04 +0100 Received: (qmail 31801 invoked by uid 511); 1 Aug 2007 08:02:12 -0000 Received: from unknown (HELO ?192.168.2.233?) (192.168.2.233) by lemote.com with SMTP; 1 Aug 2007 08:02:12 -0000 Message-ID: <46B03CC0.3090000@lemote.com> Date: Wed, 01 Aug 2007 15:56:48 +0800 From: Songmao Tian User-Agent: Icedove 1.5.0.8 (X11/20061116) MIME-Version: 1.0 To: alsa-devel@alsa-project.org, linux-mips@linux-mips.org Subject: ALSA on MIPS platform 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: 15971 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: tiansm@lemote.com Precedence: bulk X-list: linux-mips Hi, In http://www.linux-mips.org/archives/linux-mips/2007-04/msg00114.html, Atsushi Nemoto pointed out the problem is discussed before, the thread can be found at http://lkml.org/lkml/2006/1/25/117. Thanks Atsushi Nemoto:) The problem is clear: 1. dma_alloc_noncoherent() return a non-cached address, and virt_to_page() need a cached logical addr (Have I named it right?) 2. mmaped dam buffer should be non-cached. We have a ugly patch, but we want to solve the problem cleanly, so can anyone show me the way? Regards, Tian diff --git a/sound/core/pcm_native.c b/sound/core/pcm_native.c index 59b29cd..fd0aa66 100644 --- a/sound/core/pcm_native.c +++ b/sound/core/pcm_native.c @@ -3138,7 +3138,11 @@ static struct page *snd_pcm_mmap_data_nopage(struct vm_area_struct *area, return NOPAGE_OOM; /* XXX: is this really due to OOM? */ } else { vaddr = runtime->dma_area + offset; +#if defined(__mips__) && defined(CONFIG_DMA_NONCOHERENT) + page = virt_to_page(CAC_ADDR(vaddr)); +#else page = virt_to_page(vaddr); +#endif } get_page(page); if (type) @@ -3254,6 +3258,11 @@ static int snd_pcm_mmap(struct file *file, struct vm_area_struct *area) substream = pcm_file->substream; snd_assert(substream != NULL, return -ENXIO); +#if defined(__mips__) && defined(CONFIG_DMA_NONCOHERENT) + /* all mmap using uncached mode */ + area->vm_page_prot = pgprot_noncached(area->vm_page_prot); +#endif + offset = area->vm_pgoff << PAGE_SHIFT; switch (offset) { case SNDRV_PCM_MMAP_OFFSET_STATUS: diff --git a/sound/core/sgbuf.c b/sound/core/sgbuf.c index cefd228..2251e70 100644 --- a/sound/core/sgbuf.c +++ b/sound/core/sgbuf.c @@ -91,12 +91,21 @@ void *snd_malloc_sgbuf_pages(struct device *device, } sgbuf->table[i].buf = tmpb.area; sgbuf->table[i].addr = tmpb.addr; +#if defined(__mips__) && defined(CONFIG_DMA_NONCOHERENT) + sgbuf->page_table[i] = virt_to_page(CAC_ADDR(tmpb.area)); +#else sgbuf->page_table[i] = virt_to_page(tmpb.area); +#endif sgbuf->pages++; } sgbuf->size = size; +#if defined(__mips__) && defined(CONFIG_DMA_NONCOHERENT) + /* maybe we should use uncached accelerated mode */ + dmab->area = vmap(sgbuf->page_table, sgbuf->pages, VM_MAP, pgprot_noncached(PAGE_KERNEL)); +#else dmab->area = vmap(sgbuf->page_table, sgbuf->pages, VM_MAP, PAGE_KERNEL); +#endif if (! dmab->area) goto _failed; return dmab->area; From jiankemeng@gmail.com Wed Aug 1 10:01:37 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 01 Aug 2007 10:01:42 +0100 (BST) Received: from wa-out-1112.google.com ([209.85.146.181]:62474 "EHLO wa-out-1112.google.com") by ftp.linux-mips.org with ESMTP id S20021708AbXHAJBh (ORCPT ); Wed, 1 Aug 2007 10:01:37 +0100 Received: by wa-out-1112.google.com with SMTP id m16so139163waf for ; Wed, 01 Aug 2007 02:01:18 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:received:date:from:to:cc:subject:message-id:mime-version:content-type:content-disposition:user-agent; b=galvjmnljIffu3acc7ZiJOqnSdj2K4cyoB3bi/jgAMxog2TceL2faHs1STze2XHm6qN5v7pEBfz0Uzt1FaCOrlRcKRteRfOY8OOfCPGohADRiRiB2qmwdoXv/aLEJqa9BEsaKToy3NTqCcHPj0cTM4UehdoQOVHNQk0MUoXOrkc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:date:from:to:cc:subject:message-id:mime-version:content-type:content-disposition:user-agent; b=RZpciKJ31JyQI8RNYUE2FCNcZO2BZX7ThINJQy+Hoii8+E96+U/YVgSoq7GIC8HQ+d37He0SsvHRRT69mFJi5tJXyTCVkdApwE4xmK/QR5dqpDriYO40zeZ/aWZ7LXpxuZW1uY2fr+Uk1BRQEurVh6H2e4UfxTzQgs/X/8Vqhjo= Received: by 10.115.107.1 with SMTP id j1mr509496wam.1185958877896; Wed, 01 Aug 2007 02:01:17 -0700 (PDT) Received: from dajietan.caozhai.com ( [58.213.112.151]) by mx.google.com with ESMTPS id v39sm557866wah.2007.08.01.02.01.16 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 01 Aug 2007 02:01:17 -0700 (PDT) Received: from comcat by dajietan.caozhai.com with local (Exim 4.54) id 1IGDp8-0001Lz-0w; Wed, 01 Aug 2007 17:01:10 +0400 Date: Wed, 1 Aug 2007 17:01:09 +0400 From: Dajie Tan To: Ralf Baechle Cc: linux-mips , oprofile-list@lists.sourceforge.net Subject: [PATCH][resend] add support for profiling loongson2e Message-ID: <20070801130109.GA5170@sw-linux.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.9i Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 15972 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: jiankemeng@gmail.com Precedence: bulk X-list: linux-mips Using mutt resend it. Wish it would be sended ok. Tan. Signed-off-by: Dajie Tan --- arch/mips/lemote/lm2e/irq.c | 2 + arch/mips/oprofile/Makefile | 1 + arch/mips/oprofile/common.c | 6 + arch/mips/oprofile/op_model_loongson2e.c | 170 ++++++++++++++++++++++++++++++ drivers/oprofile/cpu_buffer.c | 4 + include/asm-mips/mipsregs.h | 60 +++++++++++ 6 files changed, 243 insertions(+), 0 deletions(-) diff --git a/arch/mips/lemote/lm2e/irq.c b/arch/mips/lemote/lm2e/irq.c index 3e0b7be..62f6822 100644 --- a/arch/mips/lemote/lm2e/irq.c +++ b/arch/mips/lemote/lm2e/irq.c @@ -81,6 +81,8 @@ asmlinkage void plat_irq_dispatch(void) if (pending & CAUSEF_IP7) { do_IRQ(MIPS_CPU_IRQ_BASE + 7); + } else if (pending & CAUSEF_IP6) { /* performance counter overflowe at IP6 */ + do_IRQ(MIPS_CPU_IRQ_BASE + 6); } else if (pending & CAUSEF_IP5) { i8259_irqdispatch(); } else if (pending & CAUSEF_IP2) { diff --git a/arch/mips/oprofile/Makefile b/arch/mips/oprofile/Makefile index bf3be6f..9148850 100644 --- a/arch/mips/oprofile/Makefile +++ b/arch/mips/oprofile/Makefile @@ -15,3 +15,4 @@ 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_RM9000) += op_model_rm9000.o +oprofile-$(CONFIG_CPU_LOONGSON2) += op_model_loongson2e.o diff --git a/arch/mips/oprofile/common.c b/arch/mips/oprofile/common.c index 4e0a90b..50a0531 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_loongson2e_ops __attribute__((weak)); static struct op_mips_model *model; @@ -92,6 +93,11 @@ int __init oprofile_arch_init(struct oprofile_operations *ops) case CPU_RM9000: lmodel = &op_model_rm9000_ops; break; + + case CPU_LOONGSON2: + lmodel = &op_model_loongson2e_ops; + break; + }; if (!lmodel) diff --git a/arch/mips/oprofile/op_model_loongson2e.c b/arch/mips/oprofile/op_model_loongson2e.c new file mode 100644 index 0000000..f7c2a84 --- /dev/null +++ b/arch/mips/oprofile/op_model_loongson2e.c @@ -0,0 +1,170 @@ +/* + * 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) 2007 by Dajie Tan + */ + +#include +#include +#include +#include + +#include "op_impl.h" + +#define GODSON2E_PERFCTL_EXL (1UL << 0) +#define GODSON2E_PERFCTL_KERNEL (1UL << 1) +#define GODSON2E_PERFCTL_SUPERVISOR (1UL << 2) +#define GODSON2E_PERFCTL_USER (1UL << 3) +#define GODSON2E_PERFCTL_INTERRUPT_ENABLE (1UL << 4) +#define GODSON2E_PERFCTL_OVERFLOW (1ULL << 31) + +#define GODSON2E_COUNTER1_EVENT(event) ((event) << 5) +#define GODSON2E_COUNTER2_EVENT(event) ((event) << 9) + + +/* IP6 --- performance counter overflow */ +static int loongson2e_pmc_irq = MIPS_CPU_IRQ_BASE + 6; + + +static struct loongson2e_register_config { + unsigned int control; + unsigned int reset_counter1; + unsigned int reset_counter2; + int c1_enabled; + int c2_enabled; +} reg; + +/* Compute all of the registers in preparation for enabling profiling. */ + +static void loongson2e_reg_setup(struct op_counter_config *ctr) +{ + unsigned int control = 0; + + /* Compute the performance counter control word. */ + /* For now count kernel and user mode */ + if (ctr[0].enabled) + control |= GODSON2E_COUNTER1_EVENT(ctr[0].event) | + GODSON2E_PERFCTL_INTERRUPT_ENABLE; + else + control |= GODSON2E_COUNTER1_EVENT(0xe); + + if (ctr[1].enabled) + control |= GODSON2E_COUNTER2_EVENT(ctr[1].event) | + GODSON2E_PERFCTL_INTERRUPT_ENABLE; + else + control |= GODSON2E_COUNTER2_EVENT(0x3); + + if (ctr[0].kernel || ctr[1].kernel) + control |= GODSON2E_PERFCTL_KERNEL; + else + control &= ~GODSON2E_PERFCTL_KERNEL; + + if (ctr[0].user || ctr[1].user) + control |= GODSON2E_PERFCTL_USER; + else + control &= ~GODSON2E_PERFCTL_USER; + + if (ctr[0].exl || ctr[1].exl) + control |= GODSON2E_PERFCTL_EXL; + else + control &= ~GODSON2E_PERFCTL_EXL; + + reg.control = control; + + reg.c1_enabled = ctr[0].enabled; + reg.c2_enabled = ctr[1].enabled; + reg.reset_counter1 = ctr[0].count ? 0x80000000 - ctr[0].count : 0; + reg.reset_counter2 = ctr[1].count ? 0x80000000 - ctr[1].count : 0; +} + +static void loongson2e_cpu_setup (void *args) +{ + uint64_t perfcount; + perfcount = ((uint64_t) reg.reset_counter2 << 32) | reg.reset_counter1; + write_c0_pmc_count(perfcount); +} + +static void loongson2e_cpu_start(void *args) +{ + /* Start all counters */ + write_c0_pmc_control(reg.control); +} + +static void loongson2e_cpu_stop(void *args) +{ + /* Stop all counters */ + write_c0_pmc_control(0); +} + + +static irqreturn_t loongson2e_pmc_handler(int irq, void * dev_id) +{ + uint32_t counter1, counter2; + uint64_t counters; + uint64_t tmp = 0x0; + struct pt_regs *regs = get_irq_regs(); + + /* + * Godson2e combines two 32-bit performance counters into a single + * 64-bit coprocessor zero register. To avoid a race updating the + * registers we need to stop the counters while we're messing with + * them ... + */ + + write_c0_pmc_control(tmp); + + counters = read_c0_pmc_count(); + counter1 = counters; + counter2 = counters >> 32; + + if (reg.c2_enabled && counter2 & GODSON2E_PERFCTL_OVERFLOW) { + oprofile_add_sample(regs, 1); + counter2 = reg.reset_counter2; + } + + if (reg.c1_enabled && counter1 & GODSON2E_PERFCTL_OVERFLOW) { + oprofile_add_sample(regs, 0); + counter1 = reg.reset_counter1; + } + + counters = ((uint64_t)counter2 << 32) | counter1; + + write_c0_pmc_count(counters); + write_c0_pmc_control(reg.control); + + return IRQ_HANDLED; +} + +static int __init loongson2e_init(void) +{ + uint64_t tmp = 0; + write_c0_pmc_control(0); + write_c0_pmc_count(tmp); + + return request_irq(loongson2e_pmc_irq, loongson2e_pmc_handler, + IRQF_DISABLED, "Perfcounter", NULL); +} + +static void loongson2e_exit(void) +{ + uint64_t tmp = 0; + write_c0_pmc_control(0); + write_c0_pmc_count(tmp); + + free_irq(loongson2e_pmc_irq, NULL); +} + +struct op_mips_model op_model_loongson2e_ops = { + .reg_setup = loongson2e_reg_setup, + .cpu_setup = loongson2e_cpu_setup, + .init = loongson2e_init, + .exit = loongson2e_exit, + .cpu_start = loongson2e_cpu_start, + .cpu_stop = loongson2e_cpu_stop, + .cpu_type = "mips/loongson2e", + .num_counters = 2 +}; + + diff --git a/drivers/oprofile/cpu_buffer.c b/drivers/oprofile/cpu_buffer.c index a83c3db..fde9819 100644 --- a/drivers/oprofile/cpu_buffer.c +++ b/drivers/oprofile/cpu_buffer.c @@ -148,6 +148,10 @@ add_sample(struct oprofile_cpu_buffer * cpu_buf, unsigned long pc, unsigned long event) { struct op_sample * entry = &cpu_buf->buffer[cpu_buf->head_pos]; + + if(!entry) + return; + entry->eip = pc; entry->event = event; increment_head(cpu_buf); diff --git a/include/asm-mips/mipsregs.h b/include/asm-mips/mipsregs.h index 18f47f1..8a00c20 100644 --- a/include/asm-mips/mipsregs.h +++ b/include/asm-mips/mipsregs.h @@ -600,6 +600,58 @@ do { \ } while (0) + +/* + * Macros to access the loongson2e system control coprocessor + */ +#define __read_64bit_c0_pmc_split(source, sel) \ +({ \ + unsigned long long val; \ + unsigned long flags; \ + \ + local_irq_save(flags); \ + if (sel == 0) \ + __asm__ __volatile__( \ + ".set\tmips64\n\t" \ + "dmfc0\t%M0, " #source "\n\t" \ + "dsll\t%L0, %M0, 32\n\t" \ + "dsra\t%M0, %M0, 32\n\t" \ + "dsra\t%L0, %L0, 32\n\t" \ + ".set\tmips0" \ + : "=r" (val)); \ + else \ + __asm__ __volatile__( \ + ".set\tmips64\n\t" \ + "dmfc0\t%M0, " #source ", " #sel "\n\t" \ + "dsll\t%L0, %M0, 32\n\t" \ + "dsra\t%M0, %M0, 32\n\t" \ + "dsra\t%L0, %L0, 32\n\t" \ + ".set\tmips0" \ + : "=r" (val)); \ + local_irq_restore(flags); \ + \ + val; \ +}) + +#define __read_64bit_c0_pmc(source, sel) \ +({ unsigned long long __res; \ + if (sizeof(unsigned long) == 4) \ + __res = __read_64bit_c0_pmc_split(source, sel); \ + else if (sel == 0) \ + __asm__ __volatile__( \ + ".set\tmips3\n\t" \ + "dmfc0\t%0, " #source "\n\t" \ + ".set\tmips0" \ + : "=r" (__res)); \ + else \ + __asm__ __volatile__( \ + ".set\tmips64\n\t" \ + "dmfc0\t%0, " #source ", " #sel "\n\t" \ + ".set\tmips0" \ + : "=r" (__res)); \ + __res; \ +}) + /* * Macros to access the system control coprocessor */ @@ -905,6 +957,14 @@ do { \ #define read_c0_framemask() __read_32bit_c0_register($21, 0) #define write_c0_framemask(val) __write_32bit_c0_register($21, 0, val) +/* Loongson2e PMC control register */ +#define read_c0_pmc_control() __read_32bit_c0_register($24, 0) +#define write_c0_pmc_control(val) __write_32bit_c0_register($24, 0, val) + +/* Loongson2e PMC counter register */ +#define read_c0_pmc_count() __read_64bit_c0_pmc($25, 0) +#define write_c0_pmc_count(val) __write_64bit_c0_register($25, 0, val) + /* RM9000 PerfControl performance counter control register */ #define read_c0_perfcontrol() __read_32bit_c0_register($22, 0) #define write_c0_perfcontrol(val) __write_32bit_c0_register($22, 0, val) From naren_lin@yahoo.co.in Wed Aug 1 12:26:31 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 01 Aug 2007 12:26:33 +0100 (BST) Received: from web94312.mail.in2.yahoo.com ([203.104.16.222]:57445 "HELO web94312.mail.in2.yahoo.com") by ftp.linux-mips.org with SMTP id S20021767AbXHAL0b (ORCPT ); Wed, 1 Aug 2007 12:26:31 +0100 Received: (qmail 52714 invoked by uid 60001); 1 Aug 2007 11:26:21 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.co.in; h=X-YMail-OSG:Received:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding:Message-ID; b=nHAxgI4IMuw6iWyx5ugsIExOUavHotAeuZTOlUWwj9xs+zlWnzb86HUGGHcmgxEO8ak/jaElrWWRJtFk3rBm7pF12KYhyetnfFGelxQZerxrQAAb6/lSX6cuzypMC7Ih5Pm8QrrV/uBKEf0lQZLZGQReppFnjLibtr7Mx3c7vDE=; X-YMail-OSG: QIY7uvwVM1m_i1ZxT1jDNiTk8kQ6lTR2VJV4xMqTUIaATxXMygDCu5ZRKhWe5DwOEVSEcCkpZzwRf5Ov4ST.kYmnCg-- Received: from [121.100.32.51] by web94312.mail.in2.yahoo.com via HTTP; Wed, 01 Aug 2007 12:26:21 BST Date: Wed, 1 Aug 2007 12:26:21 +0100 (BST) From: Naren chandru Subject: Re: tx4927 patch for linux-2.6.22.1 To: Atsushi Nemoto Cc: linux-mips@linux-mips.org In-Reply-To: <20070725.001433.118975997.anemo@mba.ocn.ne.jp> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Message-ID: <900995.51898.qm@web94312.mail.in2.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: 15973 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: naren_lin@yahoo.co.in Precedence: bulk X-list: linux-mips --- Atsushi Nemoto wrote: > On Mon, 23 Jul 2007 22:23:23 -0700 (PDT), naren_lin >> Any patches is available for 2.6.22.1 > > kernel for tx4927 mips? > > I could build 2.6.22.1 successfully with > rbhma4200_defconfig at least. > Exact error log? > I could build it for tx4927 Thanks, Naren Once upon a time there was 1 GB storage in your inbox. To know the happy ending go to http://help.yahoo.com/l/in/yahoo/mail/yahoomail/tools/tools-08.html From ralf@linux-mips.org Wed Aug 1 12:52:32 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 01 Aug 2007 12:52:34 +0100 (BST) Received: from localhost.localdomain ([127.0.0.1]:32980 "EHLO dl5rb.ham-radio-op.net") by ftp.linux-mips.org with ESMTP id S20021794AbXHALwc (ORCPT ); Wed, 1 Aug 2007 12:52:32 +0100 Received: from denk.linux-mips.net (denk.linux-mips.net [127.0.0.1]) by dl5rb.ham-radio-op.net (8.14.1/8.13.8) with ESMTP id l71BqWMf020439 for ; Wed, 1 Aug 2007 12:52:32 +0100 Received: (from ralf@localhost) by denk.linux-mips.net (8.14.1/8.14.1/Submit) id l71BqVBG020438 for linux-mips@linux-mips.org; Wed, 1 Aug 2007 12:52:31 +0100 Date: Wed, 1 Aug 2007 12:52:31 +0100 From: Ralf Baechle To: linux-mips@linux-mips.org Subject: Modpost warning on Alchemy Message-ID: <20070801115231.GA20323@linux-mips.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.14 (2007-02-12) Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 15974 X-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 Somebody with a clue on the Alchemy stuff may want to look into this mostpost warning: MODPOST vmlinux.o WARNING: vmlinux.o(.text+0x1e32dc): Section mismatch: reference to .init.text:add_wired_entry (between 'config_access' and 'config_write') LD vmlinux All the PCI config space accessors on Alchemy will call arch/mips/pci/ops-au1000.c:config_access which in turn calls add_wired_entry add_wired_entry in turn is an __init function so it's only a matter of luck if the PCI code doesn't explode on Alchemy. So could somebody Alchemist try to rewrite this to use ioremap() instead? Thanks, Ralf From sshtylyov@ru.mvista.com Wed Aug 1 13:21:51 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 01 Aug 2007 13:21:53 +0100 (BST) Received: from h155.mvista.com ([63.81.120.155]:17755 "EHLO imap.sh.mvista.com") by ftp.linux-mips.org with ESMTP id S20021798AbXHAMVv (ORCPT ); Wed, 1 Aug 2007 13:21:51 +0100 Received: from [192.168.1.248] (unknown [10.150.0.9]) by imap.sh.mvista.com (Postfix) with ESMTP id 85A443EC9; Wed, 1 Aug 2007 05:21:18 -0700 (PDT) Message-ID: <46B07B36.1000501@ru.mvista.com> Date: Wed, 01 Aug 2007 16:23:18 +0400 From: Sergei Shtylyov Organization: MontaVista Software Inc. User-Agent: Mozilla/5.0 (X11; U; Linux i686; rv:1.7.2) Gecko/20040803 X-Accept-Language: ru, en-us, en-gb MIME-Version: 1.0 To: Ralf Baechle Cc: linux-mips@linux-mips.org Subject: Re: Modpost warning on Alchemy References: <20070801115231.GA20323@linux-mips.org> In-Reply-To: <20070801115231.GA20323@linux-mips.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 15975 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: sshtylyov@ru.mvista.com Precedence: bulk X-list: linux-mips Ralf Baechle wrote: > Somebody with a clue on the Alchemy stuff may want to look into this > mostpost warning: > MODPOST vmlinux.o > WARNING: vmlinux.o(.text+0x1e32dc): Section mismatch: reference to .init.text:add_wired_entry (between 'config_access' and 'config_write') > LD vmlinux > All the PCI config space accessors on Alchemy will call > arch/mips/pci/ops-au1000.c:config_access which in turn calls add_wired_entry > add_wired_entry in turn is an __init function so it's only a matter of > luck if the PCI code doesn't explode on Alchemy. > So could somebody Alchemist try to rewrite this to use ioremap() instead? Will ioremap() work for 4 GB range? I guess not. What actually needs to be done is move this code under if (first_cfg) into __init function... > Thanks, > Ralf MBR, Sergei From movement@totally.trollied.org.uk Wed Aug 1 13:42:03 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 01 Aug 2007 13:42:05 +0100 (BST) Received: from 87-237-56-54.northerncolo.co.uk ([87.237.56.54]:21917 "EHLO totally.trollied.org.uk") by ftp.linux-mips.org with ESMTP id S20021761AbXHAMmD (ORCPT ); Wed, 1 Aug 2007 13:42:03 +0100 Received: from localhost ([127.0.0.1] helo=totally.trollied.org.uk) by totally.trollied.org.uk with esmtps (TLSv1:AES256-SHA:256) (Exim 4.62) (envelope-from ) id 1IGDTN-0007sU-N1; Wed, 01 Aug 2007 13:38:41 +0100 Received: (from movement@localhost) by totally.trollied.org.uk (8.13.7/8.13.7/Submit) id l71CcekF030283; Wed, 1 Aug 2007 13:38:40 +0100 Date: Wed, 1 Aug 2007 13:38:40 +0100 From: John Levon To: Dajie Tan Cc: Ralf Baechle , linux-mips , oprofile-list@lists.sourceforge.net Subject: Re: [PATCH][resend] add support for profiling loongson2e Message-ID: <20070801123840.GA29950@totally.trollied.org.uk> References: <20070801130109.GA5170@sw-linux.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20070801130109.GA5170@sw-linux.com> X-Url: http://www.movementarian.org/ User-Agent: Mutt/1.5.9i Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 15976 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: levon@movementarian.org Precedence: bulk X-list: linux-mips On Wed, Aug 01, 2007 at 05:01:09PM +0400, Dajie Tan wrote: > diff --git a/drivers/oprofile/cpu_buffer.c b/drivers/oprofile/cpu_buffer.c > index a83c3db..fde9819 100644 > --- a/drivers/oprofile/cpu_buffer.c > +++ b/drivers/oprofile/cpu_buffer.c > @@ -148,6 +148,10 @@ add_sample(struct oprofile_cpu_buffer * cpu_buf, > unsigned long pc, unsigned long event) > { > struct op_sample * entry = &cpu_buf->buffer[cpu_buf->head_pos]; > + > + if(!entry) > + return; > + Perhaps I wasn't clear. This change is unacceptable and must not be merged. john From macro@linux-mips.org Wed Aug 1 13:54:30 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 01 Aug 2007 13:54:32 +0100 (BST) Received: from pollux.ds.pg.gda.pl ([153.19.208.7]:57093 "EHLO pollux.ds.pg.gda.pl") by ftp.linux-mips.org with ESMTP id S20021817AbXHAMya (ORCPT ); Wed, 1 Aug 2007 13:54:30 +0100 Received: from localhost (localhost [127.0.0.1]) by pollux.ds.pg.gda.pl (Postfix) with ESMTP id D154DE1C78; Wed, 1 Aug 2007 14:53:56 +0200 (CEST) X-Virus-Scanned: by amavisd-new at pollux.ds.pg.gda.pl Received: from pollux.ds.pg.gda.pl ([127.0.0.1]) by localhost (pollux.ds.pg.gda.pl [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xZ5wY530dPtM; Wed, 1 Aug 2007 14:53:56 +0200 (CEST) Received: from piorun.ds.pg.gda.pl (piorun.ds.pg.gda.pl [153.19.208.8]) by pollux.ds.pg.gda.pl (Postfix) with ESMTP id 806D2E1C63; Wed, 1 Aug 2007 14:53:56 +0200 (CEST) Received: from blysk.ds.pg.gda.pl (macro@blysk.ds.pg.gda.pl [153.19.208.6]) by piorun.ds.pg.gda.pl (8.13.8/8.13.8) with ESMTP id l71Cs36d007343; Wed, 1 Aug 2007 14:54:04 +0200 Date: Wed, 1 Aug 2007 13:53:59 +0100 (BST) From: "Maciej W. Rozycki" To: Sergei Shtylyov cc: Ralf Baechle , linux-mips@linux-mips.org Subject: Re: Modpost warning on Alchemy In-Reply-To: <46B07B36.1000501@ru.mvista.com> Message-ID: References: <20070801115231.GA20323@linux-mips.org> <46B07B36.1000501@ru.mvista.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: ClamAV 0.91.1/3846/Wed Aug 1 09:27:07 2007 on piorun.ds.pg.gda.pl X-Virus-Status: Clean Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 15977 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: macro@linux-mips.org Precedence: bulk X-list: linux-mips On Wed, 1 Aug 2007, Sergei Shtylyov wrote: > > So could somebody Alchemist try to rewrite this to use ioremap() instead? > > Will ioremap() work for 4 GB range? I guess not. Of course it will. It shall work with whatever physical address space is supported by your MMU. As long as the MMU is handled correctly that is, but I guess I may have omitted this clarification as obvious. Maciej From hch@lst.de Wed Aug 1 13:58:04 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 01 Aug 2007 13:58:06 +0100 (BST) Received: from verein.lst.de ([213.95.11.210]:54660 "EHLO mail.lst.de") by ftp.linux-mips.org with ESMTP id S20021823AbXHAM6E (ORCPT ); Wed, 1 Aug 2007 13:58:04 +0100 Received: from verein.lst.de (localhost [127.0.0.1]) by mail.lst.de (8.12.3/8.12.3/Debian-7.1) with ESMTP id l71CvrA5027401 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Wed, 1 Aug 2007 14:57:53 +0200 Received: (from hch@localhost) by verein.lst.de (8.12.3/8.12.3/Debian-6.6) id l71CvrL2027399; Wed, 1 Aug 2007 14:57:53 +0200 Date: Wed, 1 Aug 2007 14:57:53 +0200 From: Christoph Hellwig To: Domen Puncer Cc: Russell King , David Brownell , linuxppc-dev@ozlabs.org, Christoph Hellwig , linux-mips@linux-mips.org Subject: Re: Generic clk.h wrappers? [Was: Re: [PATCH 1/3] powerpc clk.h interface for platforms] Message-ID: <20070801125753.GB27199@lst.de> References: <20070711093113.GE4375@moe.telargo.com> <200707110856.58463.david-b@pacbell.net> <20070711161633.GA4846@lst.de> <200707111002.55119.david-b@pacbell.net> <20070711203454.GC2301@flint.arm.linux.org.uk> <20070713091203.GE11476@nd47.coderock.org> <20070801072807.GL4529@moe.telargo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20070801072807.GL4529@moe.telargo.com> User-Agent: Mutt/1.3.28i X-Scanned-By: MIMEDefang 2.39 Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 15978 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: hch@lst.de Precedence: bulk X-list: linux-mips On Wed, Aug 01, 2007 at 09:28:07AM +0200, Domen Puncer wrote: > > It doesn't make any assumption on struct clk, it's just a > > wrapper around functions from clk.h. > > Point of this patch was to abstract exported functions, since > > arch/powerpc/ can support multiple platfroms in one binary. > > So... the thread just ended without any consensus, ACK or whatever. > > Choices I see: > - have EXPORT_SYMBOL for clk.h functions in ie. lib/clock.c and have > every implemenation fill some global struct. > - leave this patch as it is, abstraction only for arch/powerpc/. > - or I can just forget about this, and leave it for the next sucker > who will want nicer clock handling in some driver It seems like arm really wants this optimized to the last cycle and no abstraction inbetween so we're probably stuck with the status quo. I'm pretty sure this will get too messy sooner and later and people will clean the mess up, but due to the political issues I don't think it's fair to put that burden on you just for submitting the powerpc implementation. So, please leave the patch as-is. From sshtylyov@ru.mvista.com Wed Aug 1 14:11:17 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 01 Aug 2007 14:11:19 +0100 (BST) Received: from h155.mvista.com ([63.81.120.155]:41820 "EHLO imap.sh.mvista.com") by ftp.linux-mips.org with ESMTP id S20021814AbXHANLR (ORCPT ); Wed, 1 Aug 2007 14:11:17 +0100 Received: from [192.168.1.248] (unknown [10.150.0.9]) by imap.sh.mvista.com (Postfix) with ESMTP id 228BA3EC9; Wed, 1 Aug 2007 06:11:15 -0700 (PDT) Message-ID: <46B086EB.2030101@ru.mvista.com> Date: Wed, 01 Aug 2007 17:13:15 +0400 From: Sergei Shtylyov Organization: MontaVista Software Inc. User-Agent: Mozilla/5.0 (X11; U; Linux i686; rv:1.7.2) Gecko/20040803 X-Accept-Language: ru, en-us, en-gb MIME-Version: 1.0 To: "Maciej W. Rozycki" Cc: Ralf Baechle , linux-mips@linux-mips.org Subject: Re: Modpost warning on Alchemy References: <20070801115231.GA20323@linux-mips.org> <46B07B36.1000501@ru.mvista.com> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 15979 X-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 Maciej W. Rozycki wrote: >>>So could somebody Alchemist try to rewrite this to use ioremap() instead? >> Will ioremap() work for 4 GB range? I guess not. > Of course it will. It shall work with whatever physical address space is > supported by your MMU. As long as the MMU is handled correctly that is, > but I guess I may have omitted this clarification as obvious. Even on a CPU with 36-bit physical address? ;-) > Maciej WBR, Sergei From sshtylyov@ru.mvista.com Wed Aug 1 14:16:35 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 01 Aug 2007 14:16:38 +0100 (BST) Received: from h155.mvista.com ([63.81.120.155]:58204 "EHLO imap.sh.mvista.com") by ftp.linux-mips.org with ESMTP id S20021839AbXHANQf (ORCPT ); Wed, 1 Aug 2007 14:16:35 +0100 Received: from [192.168.1.248] (unknown [10.150.0.9]) by imap.sh.mvista.com (Postfix) with ESMTP id 7C9923EC9; Wed, 1 Aug 2007 06:16:03 -0700 (PDT) Message-ID: <46B0880B.2000009@ru.mvista.com> Date: Wed, 01 Aug 2007 17:18:03 +0400 From: Sergei Shtylyov Organization: MontaVista Software Inc. User-Agent: Mozilla/5.0 (X11; U; Linux i686; rv:1.7.2) Gecko/20040803 X-Accept-Language: ru, en-us, en-gb MIME-Version: 1.0 To: Sergei Shtylyov Cc: "Maciej W. Rozycki" , Ralf Baechle , linux-mips@linux-mips.org Subject: Re: Modpost warning on Alchemy References: <20070801115231.GA20323@linux-mips.org> <46B07B36.1000501@ru.mvista.com> <46B086EB.2030101@ru.mvista.com> In-Reply-To: <46B086EB.2030101@ru.mvista.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 15980 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: sshtylyov@ru.mvista.com Precedence: bulk X-list: linux-mips Hello, I wrote: >>>> So could somebody Alchemist try to rewrite this to use ioremap() >>>> instead? >>> Will ioremap() work for 4 GB range? I guess not. >> Of course it will. It shall work with whatever physical address >> space is supported by your MMU. As long as the MMU is handled >> correctly that is, but I guess I may have omitted this clarification >> as obvious. > Even on a CPU with 36-bit physical address? ;-) WTF... I know I've typed "32-bit CPU"! :-/ >> Maciej WBR, Sergei From bamakhrama@gmail.com Wed Aug 1 14:18:18 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 01 Aug 2007 14:18:20 +0100 (BST) Received: from fk-out-0910.google.com ([209.85.128.185]:53585 "EHLO fk-out-0910.google.com") by ftp.linux-mips.org with ESMTP id S20021813AbXHANSS (ORCPT ); Wed, 1 Aug 2007 14:18:18 +0100 Received: by fk-out-0910.google.com with SMTP id f40so177685fka for ; Wed, 01 Aug 2007 06:18:00 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:reply-to:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; b=m7CBtT8kFGWqITHI+bIl2iHodSNw11OuffZwqDT52gK16cQPoMwOTc91vzNcHN9n/lKKUa+SZEHskZ6jfDIKY7OYblca/j/asG+R72ZS3LggpFohK1zH0ZAzzdMEf74/xqj48Qdg1sLiWZFu/uhBTh5I5id7A+ObMt/5bFWmojo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:reply-to:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; b=eJQdT5tQX7iT+NNj0fU8nc+hfF7mhBOkQGYJKHSdJ/0Xu/PtLiSpCqxjsOC7haeGajAoC9gzwOn/aWiCGP2HoGGiIQw9NSnMJIfa5GZ6wWEiCIKTR2kmizQ9HuZQcU3DXCk1sjhz8gvQIZzocxTemDR/jtaJwvVtz5xfjO2x4/Y= Received: by 10.82.182.1 with SMTP id e1mr741944buf.1185974280091; Wed, 01 Aug 2007 06:18:00 -0700 (PDT) Received: by 10.82.148.14 with HTTP; Wed, 1 Aug 2007 06:18:00 -0700 (PDT) Message-ID: <40378e40708010618r7a93e58br206e7c47e685a05e@mail.gmail.com> Date: Wed, 1 Aug 2007 15:18:00 +0200 From: "Mohamed Bamakhrama" Reply-To: bamakhrama@gmail.com To: linux-mips@linux-mips.org Subject: cacheops.h & r4kcache.h MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 15981 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: bamakhrama@gmail.com Precedence: bulk X-list: linux-mips Hi *, In those two header files, flush & invalidate operations were implemented. Nevertheless, the MIPS32 core supports cache locking as well. Is there any implementations for Fetch&Lock instructions within the kernel? Best regards, -- Mohamed A. Bamakhrama Web: http://home.cs.tum.edu/~bamakhra/ From ralf@linux-mips.org Wed Aug 1 15:01:17 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 01 Aug 2007 15:01:19 +0100 (BST) Received: from localhost.localdomain ([127.0.0.1]:64909 "EHLO dl5rb.ham-radio-op.net") by ftp.linux-mips.org with ESMTP id S20021839AbXHAOBQ (ORCPT ); Wed, 1 Aug 2007 15:01:16 +0100 Received: from denk.linux-mips.net (denk.linux-mips.net [127.0.0.1]) by dl5rb.ham-radio-op.net (8.14.1/8.13.8) with ESMTP id l71E1FLf024209; Wed, 1 Aug 2007 15:01:15 +0100 Received: (from ralf@localhost) by denk.linux-mips.net (8.14.1/8.14.1/Submit) id l71E1EEX024208; Wed, 1 Aug 2007 15:01:14 +0100 Date: Wed, 1 Aug 2007 15:01:14 +0100 From: Ralf Baechle To: Mohamed Bamakhrama Cc: linux-mips@linux-mips.org Subject: Re: cacheops.h & r4kcache.h Message-ID: <20070801140114.GA23858@linux-mips.org> References: <40378e40708010618r7a93e58br206e7c47e685a05e@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <40378e40708010618r7a93e58br206e7c47e685a05e@mail.gmail.com> User-Agent: Mutt/1.5.14 (2007-02-12) Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 15982 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: ralf@linux-mips.org Precedence: bulk X-list: linux-mips On Wed, Aug 01, 2007 at 03:18:00PM +0200, Mohamed Bamakhrama wrote: > In those two header files, flush & invalidate operations were > implemented. Nevertheless, the MIPS32 core supports cache locking as > well. Is there any implementations for Fetch&Lock instructions within > the kernel? No. The primary use for cache locking seems to be the rather extreme realtime requirements, a league where Linux isn't playing quite yet. For a more general purpose OS locking has a good chance of doing more harm than help. Ralf From bamakhrama@gmail.com Wed Aug 1 15:13:24 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 01 Aug 2007 15:13:26 +0100 (BST) Received: from fk-out-0910.google.com ([209.85.128.184]:7655 "EHLO fk-out-0910.google.com") by ftp.linux-mips.org with ESMTP id S20021828AbXHAONY (ORCPT ); Wed, 1 Aug 2007 15:13:24 +0100 Received: by fk-out-0910.google.com with SMTP id f40so188567fka for ; Wed, 01 Aug 2007 07:13:05 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=pqng43wNFsEnd7MqbjrTdRIw8ueJGdyKf0sJZqTIb1NbNPK6o4Cghp/rQRu376r7tX/LUNDV6N8lpVv+f/r1oMPaEfAXpbR/PNwUbCL3/gmfq7tsWVDPVaUuCBiU0RptFfE82yBVwF2iHQgC39hSreQN3lz1RJ7HIwKJ0xICJ+o= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=qa+dESB4D6xdM40wkd9K+AwGADQI7f14+iLRxgEaIAOOkHSSH6q8pgDhH61baQjggIIKlKLUqyINTnAjwsJWBVTFjdQnToCQrMSowG8/stvn3JbttCv6REW1iFnYBmDOB5EKPKo2xsTVmM8x/AKPBGce5ztUz2hNaliNcTs8w8Y= Received: by 10.82.134.12 with SMTP id h12mr877106bud.1185977585159; Wed, 01 Aug 2007 07:13:05 -0700 (PDT) Received: by 10.82.148.14 with HTTP; Wed, 1 Aug 2007 07:13:05 -0700 (PDT) Message-ID: <40378e40708010713p3d866a9dva7d69132e61497d6@mail.gmail.com> Date: Wed, 1 Aug 2007 16:13:05 +0200 From: "Mohamed Bamakhrama" Reply-To: bamakhrama@gmail.com To: "Ralf Baechle" Subject: Re: cacheops.h & r4kcache.h Cc: linux-mips@linux-mips.org In-Reply-To: <20070801140114.GA23858@linux-mips.org> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <40378e40708010618r7a93e58br206e7c47e685a05e@mail.gmail.com> <20070801140114.GA23858@linux-mips.org> Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 15983 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: bamakhrama@gmail.com Precedence: bulk X-list: linux-mips On 8/1/07, Ralf Baechle wrote: > On Wed, Aug 01, 2007 at 03:18:00PM +0200, Mohamed Bamakhrama wrote: > > > In those two header files, flush & invalidate operations were > > implemented. Nevertheless, the MIPS32 core supports cache locking as > > well. Is there any implementations for Fetch&Lock instructions within > > the kernel? > > No. The primary use for cache locking seems to be the rather extreme > realtime requirements, a league where Linux isn't playing quite yet. > For a more general purpose OS locking has a good chance of doing more > harm than help. > > Ralf > I agree with you that it fits more to real-time systems. My point was that such a functionality can be added to the list of available macros (i.e. Fetch, invalidate) so that when the developer (of an embedded system for example) needs it, he/she can use it directly. Is it possible to submit a patch which adds this functionality? Regards, -- Mohamed From ralf@linux-mips.org Wed Aug 1 15:40:02 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 01 Aug 2007 15:40:04 +0100 (BST) Received: from localhost.localdomain ([127.0.0.1]:59062 "EHLO dl5rb.ham-radio-op.net") by ftp.linux-mips.org with ESMTP id S20021864AbXHAOkC (ORCPT ); Wed, 1 Aug 2007 15:40:02 +0100 Received: from denk.linux-mips.net (denk.linux-mips.net [127.0.0.1]) by dl5rb.ham-radio-op.net (8.14.1/8.13.8) with ESMTP id l71Ee1Xt012923; Wed, 1 Aug 2007 15:40:01 +0100 Received: (from ralf@localhost) by denk.linux-mips.net (8.14.1/8.14.1/Submit) id l71Ee1WE012918; Wed, 1 Aug 2007 15:40:01 +0100 Date: Wed, 1 Aug 2007 15:40:01 +0100 From: Ralf Baechle To: Mohamed Bamakhrama Cc: linux-mips@linux-mips.org Subject: Re: cacheops.h & r4kcache.h Message-ID: <20070801144001.GA12840@linux-mips.org> References: <40378e40708010618r7a93e58br206e7c47e685a05e@mail.gmail.com> <20070801140114.GA23858@linux-mips.org> <40378e40708010713p3d866a9dva7d69132e61497d6@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <40378e40708010713p3d866a9dva7d69132e61497d6@mail.gmail.com> User-Agent: Mutt/1.5.14 (2007-02-12) Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 15984 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: ralf@linux-mips.org Precedence: bulk X-list: linux-mips On Wed, Aug 01, 2007 at 04:13:05PM +0200, Mohamed Bamakhrama wrote: > I agree with you that it fits more to real-time systems. My point was > that such a functionality can be added to the list of available macros > (i.e. Fetch, invalidate) so that when the developer (of an embedded > system for example) needs it, he/she can use it directly. > > Is it possible to submit a patch which adds this functionality? It takes more than a small patch to add a few cacheop definitions. Linux generiously uses Index cacheops and so would also blow away wired cache lines and that would need to be prevented. But to answer your question, with these notes, yes. Ralf From alan@lxorguk.ukuu.org.uk Wed Aug 1 16:32:12 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 01 Aug 2007 16:32:17 +0100 (BST) Received: from outpipe-village-512-1.bc.nu ([81.2.110.250]:39556 "EHLO the-village.bc.nu") by ftp.linux-mips.org with ESMTP id S20021883AbXHAPcM (ORCPT ); Wed, 1 Aug 2007 16:32:12 +0100 Received: from the-village.bc.nu (localhost.localdomain [127.0.0.1]) by the-village.bc.nu (8.13.8/8.13.8) with ESMTP id l71FdQX4015584; Wed, 1 Aug 2007 16:39:27 +0100 Date: Wed, 1 Aug 2007 16:39:26 +0100 From: Alan Cox To: Sergei Shtylyov Cc: "Maciej W. Rozycki" , Ralf Baechle , linux-mips@linux-mips.org Subject: Re: Modpost warning on Alchemy Message-ID: <20070801163926.038c48db@the-village.bc.nu> In-Reply-To: <46B086EB.2030101@ru.mvista.com> References: <20070801115231.GA20323@linux-mips.org> <46B07B36.1000501@ru.mvista.com> <46B086EB.2030101@ru.mvista.com> X-Mailer: Claws Mail 2.9.1 (GTK+ 2.10.13; i386-redhat-linux-gnu) Organization: Red Hat UK Cyf., Amberley Place, 107-111 Peascod Street, Windsor, Berkshire, SL4 1TE, Y Deyrnas Gyfunol. Cofrestrwyd yng Nghymru a Lloegr o'r rhif cofrestru 3798903 Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 15985 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: alan@lxorguk.ukuu.org.uk Precedence: bulk X-list: linux-mips On Wed, 01 Aug 2007 17:13:15 +0400 Sergei Shtylyov wrote: > Maciej W. Rozycki wrote: > > >>>So could somebody Alchemist try to rewrite this to use ioremap() instead? > > >> Will ioremap() work for 4 GB range? I guess not. > > > Of course it will. It shall work with whatever physical address space is > > supported by your MMU. As long as the MMU is handled correctly that is, > > but I guess I may have omitted this clarification as obvious. > > Even on a CPU with 36-bit physical address? ;-) Nope. This is one problem for example with ioremap on a Pentium Pro. From macro@linux-mips.org Wed Aug 1 16:38:35 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 01 Aug 2007 16:38:40 +0100 (BST) Received: from pollux.ds.pg.gda.pl ([153.19.208.7]:40977 "EHLO pollux.ds.pg.gda.pl") by ftp.linux-mips.org with ESMTP id S20021903AbXHAPif (ORCPT ); Wed, 1 Aug 2007 16:38:35 +0100 Received: from localhost (localhost [127.0.0.1]) by pollux.ds.pg.gda.pl (Postfix) with ESMTP id C9D22E1C78; Wed, 1 Aug 2007 17:38:30 +0200 (CEST) X-Virus-Scanned: by amavisd-new at pollux.ds.pg.gda.pl Received: from pollux.ds.pg.gda.pl ([127.0.0.1]) by localhost (pollux.ds.pg.gda.pl [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bS4Opvxnhpuy; Wed, 1 Aug 2007 17:38:30 +0200 (CEST) Received: from piorun.ds.pg.gda.pl (piorun.ds.pg.gda.pl [153.19.208.8]) by pollux.ds.pg.gda.pl (Postfix) with ESMTP id 7FF12E1C6D; Wed, 1 Aug 2007 17:38:30 +0200 (CEST) Received: from blysk.ds.pg.gda.pl (macro@blysk.ds.pg.gda.pl [153.19.208.6]) by piorun.ds.pg.gda.pl (8.13.8/8.13.8) with ESMTP id l71Fcelj026147; Wed, 1 Aug 2007 17:38:40 +0200 Date: Wed, 1 Aug 2007 16:38:34 +0100 (BST) From: "Maciej W. Rozycki" To: Sergei Shtylyov cc: Ralf Baechle , linux-mips@linux-mips.org Subject: Re: Modpost warning on Alchemy In-Reply-To: <46B0880B.2000009@ru.mvista.com> Message-ID: References: <20070801115231.GA20323@linux-mips.org> <46B07B36.1000501@ru.mvista.com> <46B086EB.2030101@ru.mvista.com> <46B0880B.2000009@ru.mvista.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: ClamAV 0.91.1/3846/Wed Aug 1 09:27:07 2007 on piorun.ds.pg.gda.pl X-Virus-Status: Clean Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 15986 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: macro@linux-mips.org Precedence: bulk X-list: linux-mips On Wed, 1 Aug 2007, Sergei Shtylyov wrote: > > > Of course it will. It shall work with whatever physical address space is > > > supported by your MMU. As long as the MMU is handled correctly that is, > > > but I guess I may have omitted this clarification as obvious. > > > Even on a CPU with 36-bit physical address? ;-) > > WTF... I know I've typed "32-bit CPU"! :-/ It does not matter. The physical address of an I/O resource can be treated as a cookie that is converted, typically though an MMU, to another cookie that can be used with {read,write}{b,w,l}(). Of course you may have troubles ioremap()ping say 4GB of I/O space on a processor with a 32-bit virtual address space, but that is a corner case and typically your I/O space will be sparsely occupied. On a MIPS32 processor you have 512MB of KSEG0/1 unmapped virtual address space available for I/O devices located within the first 512MB of the physical address space plus 1GB of KSEG2 mapped virtual address space available for I/O devices located anywhere in the physical address space. That gives you from 1GB to 1.5GB of virtual address space for I/O which is enough for all the usual cases. Maciej From sshtylyov@ru.mvista.com Wed Aug 1 16:42:55 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 01 Aug 2007 16:42:59 +0100 (BST) Received: from h155.mvista.com ([63.81.120.155]:13664 "EHLO imap.sh.mvista.com") by ftp.linux-mips.org with ESMTP id S20021857AbXHAPmz (ORCPT ); Wed, 1 Aug 2007 16:42:55 +0100 Received: from [192.168.1.248] (unknown [10.150.0.9]) by imap.sh.mvista.com (Postfix) with ESMTP id 9419C3EC9; Wed, 1 Aug 2007 08:42:52 -0700 (PDT) Message-ID: <46B0AA74.7040100@ru.mvista.com> Date: Wed, 01 Aug 2007 19:44:52 +0400 From: Sergei Shtylyov Organization: MontaVista Software Inc. User-Agent: Mozilla/5.0 (X11; U; Linux i686; rv:1.7.2) Gecko/20040803 X-Accept-Language: ru, en-us, en-gb MIME-Version: 1.0 To: "Maciej W. Rozycki" Cc: Ralf Baechle , linux-mips@linux-mips.org Subject: Re: Modpost warning on Alchemy References: <20070801115231.GA20323@linux-mips.org> <46B07B36.1000501@ru.mvista.com> <46B086EB.2030101@ru.mvista.com> <46B0880B.2000009@ru.mvista.com> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 15987 X-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 Maciej W. Rozycki wrote: >>>>Of course it will. It shall work with whatever physical address space is >>>>supported by your MMU. As long as the MMU is handled correctly that is, >>>>but I guess I may have omitted this clarification as obvious. >>> Even on a CPU with 36-bit physical address? ;-) >> WTF... I know I've typed "32-bit CPU"! :-/ > It does not matter. The physical address of an I/O resource can be Believe me, it does in *this* case. :-) > treated as a cookie that is converted, typically though an MMU, to another > cookie that can be used with {read,write}{b,w,l}(). Of course you may > have troubles ioremap()ping say 4GB of I/O space on a processor with a > 32-bit virtual address space, but that is a corner case and typically your > I/O space will be sparsely occupied. It is exactly this case. > On a MIPS32 processor you have 512MB of KSEG0/1 unmapped virtual address > space available for I/O devices located within the first 512MB of the PCI config. space is mapped at 0x600000000, well beyond KGSEG0/1. > physical address space plus 1GB of KSEG2 mapped virtual address space > available for I/O devices located anywhere in the physical address space. > That gives you from 1GB to 1.5GB of virtual address space for I/O which is > enough for all the usual cases. This case is not usual. :-) > Maciej Thanks for wasting time on my education about MIPS. ;-) WBR, Sergei From hjl@lucon.org Wed Aug 1 16:44:08 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 01 Aug 2007 16:44:14 +0100 (BST) Received: from rwcrmhc15.comcast.net ([216.148.227.155]:44459 "EHLO rwcrmhc15.comcast.net") by ftp.linux-mips.org with ESMTP id S20021878AbXHAPoI (ORCPT ); Wed, 1 Aug 2007 16:44:08 +0100 Received: from lucon.org ([24.6.230.138]) by comcast.net (rwcrmhc15) with ESMTP id <20070801154356m1500a2lkce>; Wed, 1 Aug 2007 15:44:00 +0000 Received: by lucon.org (Postfix, from userid 500) id 40D98F7F56; Wed, 1 Aug 2007 08:43:56 -0700 (PDT) Date: Wed, 1 Aug 2007 08:43:56 -0700 From: "H.J. Lu" To: linux-gcc@vger.kernel.org, gcc@gcc.gnu.org, GNU C Library Cc: Mat Hostetter , Warner Losh , linux-mips@linux-mips.org, Ralf Baechle , linux-vax@pergamentum.com Subject: The Linux binutils 2.17.50.0.18 is released Message-ID: <20070801154356.GA3216@lucon.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.14 (2007-02-12) Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 15988 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: hjl@lucon.org Precedence: bulk X-list: linux-mips This is the beta release of binutils 2.17.50.0.18 for Linux, which is based on binutils 2007 0731 in CVS on sourceware.org plus various changes. It is purely for Linux. All relevant patches in patches have been applied to the source tree. You can take a look at patches/README to see what have been applied and in what order they have been applied. Starting from the 2.17.50.0.4 release, the default output section LMA (load memory address) has changed for allocatable sections from being equal to VMA (virtual memory address), to keeping the difference between LMA and VMA the same as the previous output section in the same region. For .data.init_task : { *(.data.init_task) } LMA of .data.init_task section is equal to its VMA with the old linker. With the new linker, it depends on the previous output section. You can use .data.init_task : AT (ADDR(.data.init_task)) { *(.data.init_task) } to ensure that LMA of .data.init_task section is always equal to its VMA. The linker script in the older 2.6 x86-64 kernel depends on the old behavior. You can add AT (ADDR(section)) to force LMA of .data.init_task section equal to its VMA. It will work with both old and new linkers. The x86-64 kernel linker script in kernel 2.6.13 and above is OK. The new x86_64 assembler no longer accepts monitor %eax,%ecx,%edx You should use monitor %rax,%ecx,%edx or monitor which works with both old and new x86_64 assemblers. They should generate the same opcode. The new i386/x86_64 assemblers no longer accept instructions for moving between a segment register and a 32bit memory location, i.e., movl (%eax),%ds movl %ds,(%eax) To generate instructions for moving between a segment register and a 16bit memory location without the 16bit operand size prefix, 0x66, mov (%eax),%ds mov %ds,(%eax) should be used. It will work with both new and old assemblers. The assembler starting from 2.16.90.0.1 will also support movw (%eax),%ds movw %ds,(%eax) without the 0x66 prefix. Patches for 2.4 and 2.6 Linux kernels are available at http://www.kernel.org/pub/linux/devel/binutils/linux-2.4-seg-4.patch http://www.kernel.org/pub/linux/devel/binutils/linux-2.6-seg-5.patch The ia64 assembler is now defaulted to tune for Itanium 2 processors. To build a kernel for Itanium 1 processors, you will need to add ifeq ($(CONFIG_ITANIUM),y) CFLAGS += -Wa,-mtune=itanium1 AFLAGS += -Wa,-mtune=itanium1 endif to arch/ia64/Makefile in your kernel source tree. Please report any bugs related to binutils 2.17.50.0.18 to hjl@lucon.org and http://www.sourceware.org/bugzilla/ Changes from binutils 2.17.50.0.17: 1. Update from binutils 2007 0731. 2. Switching from GPLv2 to GPLv3. 3. Add a new ELF linker option, --build-id, to generate a unique per-binary identifier embedded in a note section. 4. Remove COFF/x86-64 from PE-COFF/x86-64. 5. Fix a "nm -l" crash on DWARF info. PR 4797. 6. Match symbol type when creating symbol aliase in ELF shared library. 7. Fix addr2line on relocatable linux kernel. PR 4756. 8. Change disassembler to print addend as signed. 9. Support section alignment from 128 to 8192 bytes for PE-COFF. 10. Add attribute section to ELF linker. 11. Fix ELF linker to meet gABI alignment requirement. PR 4701. 12. Add support for reading in debug information via a .gnu_debuglink section. 13. Fix string merge for ia64 linker. PR 4590. 14. Add --common to size to display total size for *COM* syms. 15. Fix "strip --strip-unneeded" on relocatable files. PR 4716. 16. Fix "objcopy/strip --only-keep-debug" for SHT_NOTE sections. 17. Fix objdump -S with unit-at-a-time. 18. Properly handle "-shared -pie" in linker. PR 4409. 19. Fix x86 disassembler in Intel mode for various SIMD instruction. PRs 4667/4834. 20. Update x86-64 assembler to long nop sequence by default. 21. Fix --32 for x86-64 mingw assembler. 22. Fix a memory corruption in assembler. PR 4722. 22. Properly support 64bit PE-COFF on hosts where long isn't 64bit. 23. Add #line in generated linker source files. 24. Fix linker crash on SIZEOF. PR 4782. 27. Add CR16 support. 28. Add windmc tool for Windows. 29. Generate x86 instruction/register definitions from ascii tables. 30. Fix strip for Solaris. PR 4712. 31. Fix various mips bugs. 32. Fix various ppc bugs. 33. Fix various spu bugs. 34. Fix various xtensa bugs. Changes from binutils 2.17.50.0.16: 1. Update from binutils 2007 0615. 2. Preserve section alignment for copy relocation. PR 4504. 3. Properly fix regression with objcopy --only-keep-debug. PR 4479. 4. Fix ELF eh frame handling. PR 4497. 5. Fix ia64 string merge. PR 4590. 5. Don't use PE target on EFI files nor EFI target on PE files. 6. Speed up linker with many input files. 7. Support cross compiling windres. PR 2737. 8. Fix various windres bugs. 9. Fix various arms bugs. 10. Fix various m68k bugs. 11. Fix various mips bugs. 12. Fix various ppc bugs. 13. Fix various sparc bugs. 14. Fix various spu bugs. 15. Fix various xtensa bugs. Changes from binutils 2.17.50.0.15: 1. Update from binutils 2007 0511. 2. Fix objcopy --only-keep-debug and linker multiple BSS sections handling. PR 4479. 3. Fix "readelf -s -D" for gnu hash. PR 4476. 4. Fix ia64 linker crash with --unresolved-symbols=ignore-all. PR 4409. 5. Improve crc32 support in x86 assembler/dissassembler. 6. Improve displacement handling in x86 dissassembler. PR 4430. 7. Correct PC relative displacement handling in x86-64 dissassembler for Intel mode. PR 4429. 8. Fix various PPC bugs. 9. Fix various SPU bugs. 10. Fix various ARM bugs. 11. Fix various m68k bugs. 12. Fix various xtensa bugs. Changes from binutils 2.17.50.0.14: 1. Update from binutils 2007 0418. 2. Support Intel SSE4 instructions. 3. Fix linker --fatal-warnings for --warn-shared-textrel. PR 4304. 4. Improve linker error message to identify linker script error location. PR 4090. 5. Fix objcopy to allow removing all sections. PR 4348. 6. Don't print addresses of 32-bit targets as 64-bit values on 64bit host. PR 4292. 7. Improve checking for corrupted input files. PR 4110. 8. Improve alpha linker performance. 9. Add a new linker option, -l:foo. 10. Fix a PPC linker bug. PR 4267. 11. Misc vxworks bug fixes. 12. Misc SH bug fixes. 13. Misc SPU bug fixes. 14. Misc ARM bug fixes. 15. Misc MIPS bug fixes. 16. Misc xtensa bug fixes. Changes from binutils 2.17.50.0.13: 1. Update from binutils 2007 0322. 2. Fix >16byte nop padding regression in x86 assembler. 3. Fix x86-64 disassembler for xchg. PR 4218. 4. Optimize opcode for x86-64 xchg. 5. Allow register operand with x86 nop. 6. Properly handle holes between sections for PE-COFF. PR 4210. 7. Print more PE-COFF info for objdump -p. 8. Report missing matching LO16 relocation for HI16 relocation in mips linker. 9. Use PC-relative relocation for Win64. 10. Fix strip for Solaris. PR 3535. 11. Fix a C++ demangler crash. 12. Some m32c update. 13. Fix misc ARM bugs. Changes from binutils 2.17.50.0.12: 1. Update from binutils 2007 0315. 2. Add EFI/x86-64 support. 3. Fix ELF linker for relocation against STN_UNDEF. PR 3958. 4. Fix ELF linker for SHT_NOBITS section whose VMA > page size. PR 4144. 5. Make assembler and disassembler consistent for "test %eax,%ebx". PR 4027. 6. Fix i386 32bit address wraparound. PR 3966. 7. Allow Linux/i386 linker to read FreeBSD/i386 object files. 8. Fix ELF linker crash upon use of .gnu.warning. sections. PR 3953. 9. Fix ELF linker to issue an error on bad section in segment. PR 4007. 10. Support enabling both x86_64-mingw32 and i386-mingw32. PR 3945. 11. Fix assembler to stabilize .gcc_except_table relaxation. PR 4029. 12. Fix a MIPS linker crash. PR 3852. 13. Fix readelf for h8300-elf. PR 3800. 14. Fix strip for Solaris. PR 3535. 15. Misc xtensa bug fixes. 16. Misc PPC bug fixes. 17. Misc SPU bug fixes. 18. Add support for Toshiba MeP. Changes from binutils 2.17.50.0.11: 1. Update from binutils 2007 0128. 2. Remove duplicate code in x86 assembler. 3. Fix 32bit and 64bit HPPA/ELF. Changes from binutils 2.17.50.0.10: 1. Update from binutils 2007 0125. 2. Support environment variables, LD_SYMBOLIC for -Bsymbolic and LD_SYMBOLIC_FUNCTIONS for -Bsymbolic-functions. 3. Build binutils rpm with LD_SYMBOLIC_FUNCTIONS=1 and reduce PLT relocations in libfd.so by 84%. 4. Enable sharable sections only for ia32, x86-64 and ia64. 5. Properly handle PT_GNU_RELRO segment for objcopy. Changes from binutils 2.17.50.0.9: 1. Update from binutils 2007 0122. 2. Implement sharable section proposal for ia32, x86-64 and ia64: http://groups-beta.google.com/group/generic-abi 3. Implement linker enhancement, -Bsymbolic-functions, --dynamic-list-cpp-new and --dynamic-list-data. PR 3831. 4. Implement new linker switch, --default-script=FILE/-dT FILE. 5. Check EI_OSABI when reading ELF files. PR 3826. 6. Fix x86 assembler error message. PR 3830. 7. Fix a bug in ld testsuite. PR 1283. 8. Don't include archive64.o for 32bit target. PR 3631. 9. Support -z max-page-size and -z common-page-size in user provided linker script. 10. Fix 32bit library support for GNU/kFreeBSD/x86-64. PR 3843. 11. Fix some bugs in Score assembler. PR 3871. 12. Fix various bugs in ARM assembler. PR 3707 and more. 13. Add Fido support. Changes from binutils 2.17.50.0.8: 1. Update from binutils 2007 0103. 2. Fix --wrap linker bug. 3. Improve handling ELF binaries generated by foreign ELF linkers. 4. Various ELF M68K bug fixes. 5. Score bug fixes. 6. Don't read past end of archive elements. PR 3704. 7. Improve .eh_frame_hdr section handling. 8. Fix symbol visibility with comdat/linkonce sections in ELF linker. PR 3666. 9. Fix 4 operand instruction handling in x86 assembler. 10. Properly check the 4th operand in x86 assembler. PR 3712. 11. Fix .cfi_endproc handling in assembler. PR 3607. 12. Various ARM bug fixes. 13. Various PE linker fixes. 14. Improve x86 dissassembler for cmpxchg16b. Changes from binutils 2.17.50.0.7: 1. Update from binutils 2006 1201. 2. Fix "objcopy --only-keep-debug" crash. PR 3609. 3. Fix various ARM ELF bugs. 4. Fix various xtensa bugs. 5. Update x86 disassembler. Changes from binutils 2.17.50.0.6: 1. Update from binutils 2006 1127. 2. Properly set ELF output segment address when the first section in input segment is removed. 3. Better merging of CIEs in linker .eh_frame optimizations. 4. Support .cfi_personality and .cfi_lsda assembler directives. 5. Fix an ARM linker crash. PR 3532. 6. Fix various PPC64 ELF bugs. 7. Mark discarded debug info more thoroughly in linker output. 8. Fix various MIPS ELF bugs. 9. Fix readelf to display program interpreter path > 64 chars. PR 3384. 10. Add support for PowerPC SPU. 11. Properly handle cloned symbols used in relocations in assembler. PR 3469. 12. Update opcode for POPCNT in amdfam10 architecture. Changes from binutils 2.17.50.0.5: 1. Update from binutils 2006 1020. 2. Don't make debug symbol dynamic. PR 3290. 3. Don't page align empty SHF_ALLOC sections, which leads to very large executables. PR 3314. 4. Use a different section index for section relative symbols against removed empty sections. 5. Fix a few ELF EH frame handling bugs. 6. Don't ignore relocation overflow on branches to undefweaks for x86-64. PR 3283. 7. Rename MNI to SSSE3. 8. Properly append symbol list for --dynamic-list. lists. 9. Various ARM ELF fixes. 10. Correct 64bit library search path for Linux/x86 linker with 64bit support. 11. Fix ELF linker to copy OS/PROC specific flags from input section to output section. 12. Fix DW_FORM_ref_addr handling in linker dwarf reader. PR 3191. 13. Fix ELF indirect symbol handling. PR 3351. 14. Fix PT_GNU_RELRO segment handling for SHF_TLS sections. Don't add PT_GNU_RELRO segment when there are no relro sections. PR 3281. 15. Various MIPS ELF fixes. 16. Various Sparc ELF fixes. 17. Various Xtensa ELF fixes. Changes from binutils 2.17.50.0.4: 1. Update from binutils 2006 0927. 2. Fix linker regressions of section address and section relative symbol with empty output section. PR 3223/3267. 3. Fix "strings -T". PR 3257. 4. Fix "objcopy --only-keep-debug". PR 3262. 5. Add Intell iwmmxt2 support. 6. Fix an x86 disassembler bug. PR 3100. Changes from binutils 2.17.50.0.3: 1. Update from binutils 2006 0924. 2. Speed up linker on .o files with debug info on linkonce sections. PR 3111. 3. Added x86-64 PE support. 4. Fix objcopy/strip on .o files with section groups. PR 3181. 5. Fix "ld --hash-style=gnu" crash with gcc 3.4.6. PR 3197. 6. Fix "strip --strip-debug" on .o files generated with "gcc -feliminate-dwarf2-dups". PR 3186. 7. Fix "ld -r" on .o files generated with "gcc -feliminate-dwarf2-dups". PR 3249. 8. Add --dynamic-list to linker to make global symbols dynamic. 9. Fix magic number for EFI ia64. PR 3171. 10. Remove PT_NULL segment for "ld -z relro". PR 3015. 11. Make objcopy to perserve the file formats in archive elements. PR 3110. 12. Optimize x86-64 assembler and fix disassembler for "add32 mov xx,$eax". PR 3235. 13. Improve linker diagnostics. PR 3107. 14. Fix "ld --sort-section name". PR 3009. 15. Updated an x86 disassembler bug. PR 3000. 16. Various updates for PPC, ARM, MIPS, SH, Xtensa. 17. Added Score support. Changes from binutils 2.17.50.0.2: 1. Update from binutils 2006 0715. 2. Add --hash-style to ELF linker with DT_GNU_HASH and SHT_GNU_HASH. 3. Fix a visibility bug in ELF linker (PR 2884). 4. Properly fix the i386 TLS linker bug (PR 2513). 5. Add assembler and dissassembler support for Pentium Pro nops. 6. Optimize x86 nops for Pentium Pro and above. 7. Add -march=/-mtune= to x86 assembler. 8. Fix an ELF linker with TLS common symbols. 9. Improve program header allocation in ELF linker. 10. Improve MIPS, M68K and ARM support. 11. Fix an ELF linker crash when reporting alignment change (PR 2735). 12. Remove unused ELF section symbols (PR 2723). 13. Add --localize-hidden to objcopy. 14. Add AMD SSE4a and ABM new instruction support. 15. Properly handle illegal x86 instructions in group 11 (PR 2829). 16. Add "-z max-page-size=" and "-z common-page-size=" to ELF linker. 17. Fix objcopy for .tbss sections. Changes from binutils 2.17.50.0.1: 1. Update from binutils 2006 0526. 2. Change the x86-64 maximum page size to 2MB. 3. Support --enable-targets=all for 64bit target and host (PR 1485). 4. Properly update CIE/FDE length and align section for .eh_frame section (PR 2655/2657). 5. Properly handle removed ELF section symbols. 6. Fix an ELF linker regression introduced on 2006-04-21. 7. Fix an segfault in PPC ELF linker (PR 2658). 8. Speed up the ELF linker by caching the result of kept section check. 9. Properly create stabs section for ELF. 10. Preserve ELF program header when copying ELF files. 11. Properly handle ELF SHN_LOPROC/SHN_HIOS when checking section index (PR 2607). 12. Misc mips updates. 13. Misc arm updates. 14. Misc xtensa updates. 15. Fix an alpha assembler warning (PR 2598). 16. Fix assembler buffer overflow. 17. Properly disassemble sgdt/sidt for x86-64. Changes from binutils 2.16.91.0.7: 1. Update from binutils 2006 0427. 2. Fix an objcopy regression (PR 2593). 3. Reduce ar memory usage (PR 2467). 4. Allow application specific ELF sections (PR 2537). 5. Fix an i386 TLS linker bug (PR 2513). 6. Speed up ia64 linker by 1300X in some cases (PR 2442). 7. Check illegal immediate register operand in i386 assembler (PR 2533). 8. Fix a strings bug (PR 2584). 9. Better handle corrupted ELF files (PR 2257). 10. Fix a MIPS linker bug (PR 2267). Changes from binutils 2.16.91.0.6: 1. Update from binutils 2006 0317. 2. Support Intel Merom New Instructions in assembler/disassembler. 3. Support Intel new instructions in Montecito. 4. Fix linker "--as-needed" (PR 2434). 5. Fix linker "-s" regression (PR 2462). 6. Fix REP prefix for string instructions in x86 disassembler (PR 2428). 7. Fix the weak undefined symbols in PIE (PR 2218). 8. Fix 2 DWARF reader bugs (PRs 2443, 2338). 9. Improve ELF linker error message (PR 2322). 10. Avoid abort with dynamic symbols in >64K sections (PR 2411). 11. Handle mismatched symbol types for executables (PR 2404). 12. Avoid a linker linkonce regression (PR 2342). Changes from binutils 2.16.91.0.5: 1. Update from binutils 2006 0212. 2. Correct Linux linker search order for DT_NEEDED entries (PR 2290). 3. Fix the x86-64 disassembler for control/debug register moves. 4. Properly handle ELF strip/objcopy with unmodified program header (PR 2258). 5. Improve ELF linker error handling when there are not enough room for program headers (PR 2322). 6. Properly handle weak undefined symbols in PIE (PR 2218). 7. Support new i386/x86-64 TLS relocations. 8. Fix addr2line for linux kernel (PR 2096). 9. Fix an assembler memory leak with --statistics. 10. Avoid an ia64 assembler regression (PR 2117). Changes from binutils 2.16.91.0.4: 1. Update from binutils 2005 1219. 2. Fix a MIPS linker regression (PR 1932). 3. Fix an objcopy bug for ia64 (PR 1991). 4. Fix a linker crash on bad input (PR 2008). 5. Fix 64bit monitor and mwait (PR 1874). Changes from binutils 2.16.91.0.3: 1. Update from binutils 2005 1111. 2. Fix ELF orphan section handling (PR 1467) 3. Fix ELF section attribute handleing (PR 1487). 4. Fix IA64 unwind info dump for relocatable files. (PR 1436). 5. Add DWARF info dump to objdump. 6. Fix SHF_LINK_ORDER handling (PR 1321). 7. Don't allow "ld --just-symbols" on DSO (PR 1263). 8. Fix a "ld -u" crash on TLS symbol (PR 1301). 9. Fix an IA64 linker crash (PR 1247). 10. Fix a MIPS linker bug (PR 1150). 11. Fix a M68K linker bug (PR 1775). 12. Fix an ELF symbol versioning linker bug (PR 1540). 13. Improve linker error handling (PR 1208). 14. Add new SPARC processors to SunOS for objcopy (PR 1472). 15. Add "@file" to read options from a file. 16. Add assembler weakref support. Changes from binutils 2.16.91.0.2: 1. Update from binutils 2005 0821. 2. Support x86-64 medium model. 3. Fix "objdump -S --adjust-vma=xxx" (PR 1179). 4. Reduce R_IA64_NONE relocations from R_IA64_LDXMOV relaxation. 5. Fix x86 linker regression for dosemu. 6. Add "readelf -t/--section-details" to display section details. 7. Fix "as -al=file" regression (PR 1118). Changes from binutils 2.16.91.0.1: 1. Update from binutils 2005 0720. 2. Add Intel VMX support. 3. Add AMD SVME support. 4. Add x86-64 new relocations for medium model. 5. Fix a PIE regression (PR 975). 6. Fix an x86_64 signed 32bit displacement regression. 7. Fix PPC PLT (PR 1004). 8. Improve empty section removal. Changes from binutils 2.16.90.0.3: 1. Update from binutils 2005 0622. 2. Fix a linker versioning bug exposed by gcc 4 (PR 1022/1023/1025). 3. Optimize ia64 br->brl relaxation (PR 834). 4. Improve linker empty section removal. 5. Fix DWARF 2 line number reporting (PR 990). 6. Fix DWARF 2 line number reporting regression on assembly file (PR 1000). Changes from binutils 2.16.90.0.2: 1. Update from binutils 2005 0510. 2. Update ia64 assembler to support comdat group section generated by gcc 4 (PR 940). 3. Fix a linker crash on bad input (PR 939). 4. Fix a sh64 assembler regression (PR 936). 5. Support linker script on executable (PR 882). 6. Fix the linker -pie regression (PR 878). 7. Fix an x86_64 disassembler bug (PR 843). 8. Fix a PPC linker regression. 9. Misc speed up. Changes from binutils 2.16.90.0.1: 1. Update from binutils 2005 0429. 2. Fix an ELF linker regression (PR 815). 3. Fix an empty section removal related bug. 4. Fix an ia64 linker regression (PR 855). 5. Don't allow local symbol to be equated common/undefined symbols (PR 857). 6. Fix the ia64 linker to handle local dynamic symbol error reporting. 7. Make non-debugging reference to discarded section an error (PR 858). 8. Support Sparc/TLS. 9. Support rpm build with newer rpm. 10. Fix an alpha linker regression. 11. Fix the non-gcc build regression. Changes from binutils 2.15.94.0.2.2: 1. Update from binutils 2005 0408. 2. The i386/x86_64 assemblers no longer accept instructions for moving between a segment register and a 32bit memory location. 3. The x86_64 assembler now allows movq between a segment register and a 64bit general purpose register. 4. 20x Speed up linker for input files with >64K sections. 5. Properly report ia64 linker relaxation failures. 6. Support tuning ia64 assembler for Itanium 2 processors. 7. Linker will remove empty unused output sections. 8. Add -N to readelf to display full section names. 9. Fix the ia64 linker to support linkonce text sections without unwind sections. 10. More unwind directive checkings in the ia64 assembler. 11. Speed up linker with wildcard handling. 12. Fix readelf to properly dump .debug_ranges and .debug_loc sections. Changes from binutils 2.15.94.0.2: 1. Fix greater than 64K section support in linker. 2. Properly handle i386 and x86_64 protected symbols in linker. 3. Fix readelf for LEB128 on 64bit hosts. 4. Speed up readelf for section group process. 5. Include ia64 texinfo pages. 6. Change ia64 assembler to check hint.b for Montecito. 7. Improve relaxation failure report in ia64 linker. 8. Fix ia64 linker to allow relax backward branch in the same section. Changes from binutils 2.15.94.0.1: 1. Update from binutils 2004 1220. 2. Fix strip for TLS symbol references. Changes from binutils 2.15.92.0.2: 1. Update from binutils 2004 1121. 2. Put ia64 .ctors/.dtors sections next to small data section for Intel ia64 compiler. 3. Fix -Bdynamic/-Bstatic handling for linker script. 4. Provide more information on relocation overflow. 5. Add --sort-section to linker. 6. Support icc 8.1 unwind info in readelf. 7. Fix the infinite loop bug on bad input in the ia64 assembler. 8. Fix ia64 SECREL relocation in linker. 9. Fix a section group memory leak in readelf. Changes from binutils 2.15.91.0.2: 1. Update from binutils 2004 0927. 2. Work around a section header bug in Intel ia64 compiler. 3. Fix an unwind directive bug in the ia64 assembler. 4. Fix various PPC bugs. 5. Update ARM support. 6. Fix an x86-64 linker warning while building Linux kernel. Changes from binutils 2.15.91.0.1: 1. Update from binutils 2004 0727. 2. Fix the x86_64 linker to prevent non-PIC code in shared library. 3. Fix the ia64 linker to warn the relotable files which can't be relaxed. 4. Fix the comdat group support. Allow mix single-member comdat group with linkonce section. 5. Added --add-needed/--no-add-needed options to linker. 6. Fix the SHF_LINK_ORDER support. 7. Fix the ia64 assembler for multiple sections with the same name and SHT_IA_64_UNWIND sections. 8. Fix the ia64 assembler for merge section and relaxation. Changes from binutils 2.15.90.0.3: 1. Update from binutils 2004 0527. 2. Fix -x auto option in the ia64 assembler. 3. Add the AR check in the ia64 assembler. 4. Fix the section group support. 5. Add a new -z relro linker option. 6. Fix an exception section placement bug in linker. 7. Add .serialize.data and .serialize.instruction to the ia64 assembler. Changes from binutils 2.15.90.0.2: 1. Update from binutils 2004 0415. 2. Fix the linker for weak undefined symbol handling. 3. Fix the ELF/Sparc and ELF/Sparc64 linker for statically linking PIC code. Changes from binutils 2.15.90.0.1.1: 1. Update from binutils 2004 0412. 2. Add --as-needed/--no-as-needed to linker. 3. Fix -z defs in linker. 4. Always reserve the memory for ia64 dynamic linker. 5. Fix a race condition in ia64 lazy binding. Changes from binutils 2.15.90.0.1: 1. Fixed an ia64 assembler bug. 2. Install the assembler man page. Changes from binutils 2.14.90.0.8: 1. Update from binutils 2004 0303. 2. Fixed linker for undefined symbols with non-default visibility. 3. Sped up linker weakdef symbol handling. 4. Fixed mixing ELF32 and ELF64 object files in archive. 5. Added ia64 linker brl optimization. 6. Fixed ia64 linker to disallow invalid dynamic relocations. 7. Fixed DT_TEXTREL handling in ia64 linker. 8. Fixed alignment handling in ia64 assembler. 9. Improved ia64 assembler unwind table handling. Changes from binutils 2.14.90.0.7: 1. Update from binutils 2004 0114. 2. Fixed an ia64 assembler unwind table bug. 3. Better handle IPF linker relaxation overflow. 4. Fixed misc PPC bugs. Changes from binutils 2.14.90.0.6: 1. Update from binutils 2003 1029. 2. Allow type changes for undefined symbols. 3. Fix EH frame optimization. 4. Fix the check for undefined versioned symbol with wildcard. 5. Support generating code for Itanium. 6. Detect and warn bad symbol index. 7. Update IPF assemebler DV check. Changes from binutils 2.14.90.0.5: 1. Update from binutils 2003 0820. 2. No longer use section names for ELF section types nor flags. 3. Fix some ELF/IA64 linker bugs. 4. Fix some ELF/ppc bugs. 5. Add archive support to readelf. Changes from binutils 2.14.90.0.4.1: 1. Update from binutils 2003 0722. 2. Fix an ELF/mips linker bug. 3. Fix an ELF/hpppa linker bug. 4. Fix an ELF/ia64 assembler bug. 5. Fix a linkonce support with C++ debug. 6. A new working C++ demangler. 7. Various alpha, mips, ia64, ... bug fixes. 8. Support for the current gcc and glibc. Changes from binutils 2.14.90.0.4: 1. Fix an ia64 assembler hint@pause bug. 2. Support Intel Prescott New Instructions. Changes from binutils 2.14.90.0.3: 1. Work around the brain dead libtool. Changes from binutils 2.14.90.0.2: 1. Update from binutils 2003 0523. 2. Fix 2 ELF visibility bugs. 3. Fix ELF/ppc linker bugs. Changes from binutils 2.14.90.0.1: 1. Update from binutils 2003 0515. 2. Fix various ELF visibility bugs. 3. Fix some ia64 linker bugs. 4. Add more IAS compatibilities to ia64 assembler. Changes from binutils 2.13.90.0.20: 1. Update from binutils 2003 0505. 2. Fix various ELF visibility bugs. 3. Fix some ia64 linker bugs. 4. Fix some ia64 assembler bugs. 5. Add some IAS compatibilities to ia64 assembler. 6. Fix ELF common symbol alignment. 7. Fix ELF weak symbol handling. Changes from binutils 2.13.90.0.18: 1. Update from binutils 2003 0319. 2. Fix an ia64 linker brl relaxation bug. 3. Fix some ELF/ppc linker bugs. Changes from binutils 2.13.90.0.16: 1. Update from binutils 2003 0121. 2. Fix an ia64 gas bug. 3. Fix some TLS bugs. 4. Fix some ELF/ppc bugs. 5. Fix an ELF/m68k bug. 2. Include /usr/bin/c++filt. Changes from binutils 2.13.90.0.14: 1. Update from binutils 2002 1126. 2. Include /usr/bin/c++filt. 3. Fix "ld -r" with execption handling. Changes from binutils 2.13.90.0.10: 1. Update from binutils 2002 1114. 2. Fix ELF/alpha bugs. 3. Fix an ELF/i386 assembler bug. Changes from binutils 2.13.90.0.4: 1. Update from binutils 2002 1010. 2. More ELF/PPC linker bug fixes. 3. Fix an ELF/alpha linker bug. 4. Fix an ELF/sparc linker bug to support Solaris. 5. More TLS updates. Changes from binutils 2.13.90.0.3: 1. Update from binutils 2002 0814. 2. Fix symbol versioning bugs for gcc 3.2. 3. Fix mips gas. Changes from binutils 2.13.90.0.2: 1. Update from binutils 2002 0809. 2. Fix a mips gas compatibility bug. 3. Fix an x86 TLS bfd bug. 4. Fix an x86 PIC gas bug. 5. Improve symbol versioning support. The file list: 1. binutils-2.17.50.0.18.tar.bz2. Source code. 2. binutils-2.17.50.0.17-2.17.50.0.18.diff.bz2. Patch against the previous beta source code. 3. binutils-2.17.50.0.18.i686.tar.bz2. IA-32 binary tar ball for RedHat EL 4. 4. binutils-2.17.50.0.18.ia64.tar.bz2. IA-64 binary tar ball for RedHat EL 4. 5. binutils-2.17.50.0.18.x86_64.tar.bz2. X64_64 binary tar ball for RedHat EL 4. The primary sites for the beta Linux binutils are: 1. http://www.kernel.org/pub/linux/devel/binutils/ Thanks. H.J. Lu hjl@lucon.org 07/31/2007 From macro@linux-mips.org Wed Aug 1 16:49:14 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 01 Aug 2007 16:49:21 +0100 (BST) Received: from pollux.ds.pg.gda.pl ([153.19.208.7]:17417 "EHLO pollux.ds.pg.gda.pl") by ftp.linux-mips.org with ESMTP id S20021902AbXHAPtO (ORCPT ); Wed, 1 Aug 2007 16:49:14 +0100 Received: from localhost (localhost [127.0.0.1]) by pollux.ds.pg.gda.pl (Postfix) with ESMTP id 8319BE1C7C; Wed, 1 Aug 2007 17:49:10 +0200 (CEST) X-Virus-Scanned: by amavisd-new at pollux.ds.pg.gda.pl Received: from pollux.ds.pg.gda.pl ([127.0.0.1]) by localhost (pollux.ds.pg.gda.pl [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 213EH-QuC+vw; Wed, 1 Aug 2007 17:49:10 +0200 (CEST) Received: from piorun.ds.pg.gda.pl (piorun.ds.pg.gda.pl [153.19.208.8]) by pollux.ds.pg.gda.pl (Postfix) with ESMTP id 1EC10E1C79; Wed, 1 Aug 2007 17:49:10 +0200 (CEST) Received: from blysk.ds.pg.gda.pl (macro@blysk.ds.pg.gda.pl [153.19.208.6]) by piorun.ds.pg.gda.pl (8.13.8/8.13.8) with ESMTP id l71FnJqr027546; Wed, 1 Aug 2007 17:49:19 +0200 Date: Wed, 1 Aug 2007 16:49:14 +0100 (BST) From: "Maciej W. Rozycki" To: Alan Cox cc: Sergei Shtylyov , Ralf Baechle , linux-mips@linux-mips.org Subject: Re: Modpost warning on Alchemy In-Reply-To: <20070801163926.038c48db@the-village.bc.nu> Message-ID: References: <20070801115231.GA20323@linux-mips.org> <46B07B36.1000501@ru.mvista.com> <46B086EB.2030101@ru.mvista.com> <20070801163926.038c48db@the-village.bc.nu> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: ClamAV 0.91.1/3846/Wed Aug 1 09:27:07 2007 on piorun.ds.pg.gda.pl X-Virus-Status: Clean Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 15989 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: macro@linux-mips.org Precedence: bulk X-list: linux-mips On Wed, 1 Aug 2007, Alan Cox wrote: > > > Of course it will. It shall work with whatever physical address space is > > > supported by your MMU. As long as the MMU is handled correctly that is, > > > but I guess I may have omitted this clarification as obvious. > > > > Even on a CPU with 36-bit physical address? ;-) > > Nope. This is one problem for example with ioremap on a Pentium Pro. Well, but we only consider MIPS processors here which do not have such odd restrictions resulting from bad design decisions in the past. ;-) The 32-bit TLB entry format allows for up to 36 bits of the physical address space (34 bits if support for the page size of 1kB has been enabled). For anything beyond that you need a 64-bit MIPS processor using the 64-bit TLB entry format. Maciej From alan@lxorguk.ukuu.org.uk Wed Aug 1 16:52:57 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 01 Aug 2007 16:53:02 +0100 (BST) Received: from outpipe-village-512-1.bc.nu ([81.2.110.250]:52371 "EHLO the-village.bc.nu") by ftp.linux-mips.org with ESMTP id S20021917AbXHAPw5 (ORCPT ); Wed, 1 Aug 2007 16:52:57 +0100 Received: from the-village.bc.nu (localhost.localdomain [127.0.0.1]) by the-village.bc.nu (8.13.8/8.13.8) with ESMTP id l71FwCec015653; Wed, 1 Aug 2007 16:58:12 +0100 Date: Wed, 1 Aug 2007 16:58:12 +0100 From: Alan Cox To: "Maciej W. Rozycki" Cc: Sergei Shtylyov , Ralf Baechle , linux-mips@linux-mips.org Subject: Re: Modpost warning on Alchemy Message-ID: <20070801165812.3bdb269f@the-village.bc.nu> In-Reply-To: References: <20070801115231.GA20323@linux-mips.org> <46B07B36.1000501@ru.mvista.com> <46B086EB.2030101@ru.mvista.com> <20070801163926.038c48db@the-village.bc.nu> X-Mailer: Claws Mail 2.9.1 (GTK+ 2.10.13; i386-redhat-linux-gnu) Organization: Red Hat UK Cyf., Amberley Place, 107-111 Peascod Street, Windsor, Berkshire, SL4 1TE, Y Deyrnas Gyfunol. Cofrestrwyd yng Nghymru a Lloegr o'r rhif cofrestru 3798903 Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 15990 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: alan@lxorguk.ukuu.org.uk Precedence: bulk X-list: linux-mips > > > Even on a CPU with 36-bit physical address? ;-) > > > > Nope. This is one problem for example with ioremap on a Pentium Pro. > > Well, but we only consider MIPS processors here which do not have such > odd restrictions resulting from bad design decisions in the past. ;-) > The 32-bit TLB entry format allows for up to 36 bits of the physical > address space (34 bits if support for the page size of 1kB has been So does the Pentium Pro. We can map 36bit physical addresses. > enabled). For anything beyond that you need a 64-bit MIPS processor using > the 64-bit TLB entry format. Your problem is a little higher up the stack. ioremap takes an unsigned long, which on a 32bit system usually means you can't give it a 36bit bus address to remap. Alan From sshtylyov@ru.mvista.com Wed Aug 1 17:00:13 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 01 Aug 2007 17:00:17 +0100 (BST) Received: from h155.mvista.com ([63.81.120.155]:48480 "EHLO imap.sh.mvista.com") by ftp.linux-mips.org with ESMTP id S20021918AbXHAQAN (ORCPT ); Wed, 1 Aug 2007 17:00:13 +0100 Received: from [192.168.1.248] (unknown [10.150.0.9]) by imap.sh.mvista.com (Postfix) with ESMTP id 9BBE53EC9; Wed, 1 Aug 2007 08:59:40 -0700 (PDT) Message-ID: <46B0AE64.7060004@ru.mvista.com> Date: Wed, 01 Aug 2007 20:01:40 +0400 From: Sergei Shtylyov Organization: MontaVista Software Inc. User-Agent: Mozilla/5.0 (X11; U; Linux i686; rv:1.7.2) Gecko/20040803 X-Accept-Language: ru, en-us, en-gb MIME-Version: 1.0 To: Alan Cox Cc: "Maciej W. Rozycki" , Ralf Baechle , linux-mips@linux-mips.org Subject: Re: Modpost warning on Alchemy References: <20070801115231.GA20323@linux-mips.org> <46B07B36.1000501@ru.mvista.com> <46B086EB.2030101@ru.mvista.com> <20070801163926.038c48db@the-village.bc.nu> <20070801165812.3bdb269f@the-village.bc.nu> In-Reply-To: <20070801165812.3bdb269f@the-village.bc.nu> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 15991 X-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 Alan Cox wrote: >>>> Even on a CPU with 36-bit physical address? ;-) >>>Nope. This is one problem for example with ioremap on a Pentium Pro. >> Well, but we only consider MIPS processors here which do not have such >>odd restrictions resulting from bad design decisions in the past. ;-) >>The 32-bit TLB entry format allows for up to 36 bits of the physical >>address space (34 bits if support for the page size of 1kB has been > So does the Pentium Pro. We can map 36bit physical addresses. >>enabled). For anything beyond that you need a 64-bit MIPS processor using >>the 64-bit TLB entry format. > Your problem is a little higher up the stack. ioremap takes an unsigned > long, which on a 32bit system usually means you can't give it a 36bit bus > address to remap. It takes phys_t, which is 'unsigned long long' for this platform that has CONFIG_64BUIT_PHYS_ADDR=y. The reall issue is the size. > Alan WBR, Sergei From macro@linux-mips.org Wed Aug 1 17:00:51 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 01 Aug 2007 17:00:58 +0100 (BST) Received: from pollux.ds.pg.gda.pl ([153.19.208.7]:26128 "EHLO pollux.ds.pg.gda.pl") by ftp.linux-mips.org with ESMTP id S20021932AbXHAQAv (ORCPT ); Wed, 1 Aug 2007 17:00:51 +0100 Received: from localhost (localhost [127.0.0.1]) by pollux.ds.pg.gda.pl (Postfix) with ESMTP id 8B93EE1C78; Wed, 1 Aug 2007 18:00:17 +0200 (CEST) X-Virus-Scanned: by amavisd-new at pollux.ds.pg.gda.pl Received: from pollux.ds.pg.gda.pl ([127.0.0.1]) by localhost (pollux.ds.pg.gda.pl [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id udPkY26Tr4ip; Wed, 1 Aug 2007 18:00:17 +0200 (CEST) Received: from piorun.ds.pg.gda.pl (piorun.ds.pg.gda.pl [153.19.208.8]) by pollux.ds.pg.gda.pl (Postfix) with ESMTP id 354B6E1C63; Wed, 1 Aug 2007 18:00:17 +0200 (CEST) Received: from blysk.ds.pg.gda.pl (macro@blysk.ds.pg.gda.pl [153.19.208.6]) by piorun.ds.pg.gda.pl (8.13.8/8.13.8) with ESMTP id l71G0RpQ028918; Wed, 1 Aug 2007 18:00:27 +0200 Date: Wed, 1 Aug 2007 17:00:21 +0100 (BST) From: "Maciej W. Rozycki" To: Alan Cox cc: Sergei Shtylyov , Ralf Baechle , linux-mips@linux-mips.org Subject: Re: Modpost warning on Alchemy In-Reply-To: <20070801165812.3bdb269f@the-village.bc.nu> Message-ID: References: <20070801115231.GA20323@linux-mips.org> <46B07B36.1000501@ru.mvista.com> <46B086EB.2030101@ru.mvista.com> <20070801163926.038c48db@the-village.bc.nu> <20070801165812.3bdb269f@the-village.bc.nu> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: ClamAV 0.91.1/3846/Wed Aug 1 09:27:07 2007 on piorun.ds.pg.gda.pl X-Virus-Status: Clean Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 15992 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: macro@linux-mips.org Precedence: bulk X-list: linux-mips On Wed, 1 Aug 2007, Alan Cox wrote: > > enabled). For anything beyond that you need a 64-bit MIPS processor using > > the 64-bit TLB entry format. > > Your problem is a little higher up the stack. ioremap takes an unsigned > long, which on a 32bit system usually means you can't give it a 36bit bus > address to remap. Well, phys_t is what it takes for MIPS and for MIPS: #ifdef CONFIG_64BIT_PHYS_ADDR typedef unsigned long long phys_t; #else typedef unsigned long phys_t; #endif so no problem here as long as you enable CONFIG_64BIT_PHYS_ADDR which is implied in such a case. Maciej From ralf@linux-mips.org Wed Aug 1 17:21:12 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 01 Aug 2007 17:21:14 +0100 (BST) Received: from localhost.localdomain ([127.0.0.1]:21962 "EHLO dl5rb.ham-radio-op.net") by ftp.linux-mips.org with ESMTP id S20021444AbXHAQVM (ORCPT ); Wed, 1 Aug 2007 17:21:12 +0100 Received: from denk.linux-mips.net (denk.linux-mips.net [127.0.0.1]) by dl5rb.ham-radio-op.net (8.14.1/8.13.8) with ESMTP id l71GLB71015914; Wed, 1 Aug 2007 17:21:12 +0100 Received: (from ralf@localhost) by denk.linux-mips.net (8.14.1/8.14.1/Submit) id l71GLBLm015913; Wed, 1 Aug 2007 17:21:11 +0100 Date: Wed, 1 Aug 2007 17:21:11 +0100 From: Ralf Baechle To: "Maciej W. Rozycki" Cc: Alan Cox , Sergei Shtylyov , linux-mips@linux-mips.org Subject: Re: Modpost warning on Alchemy Message-ID: <20070801162110.GB14756@linux-mips.org> References: <20070801115231.GA20323@linux-mips.org> <46B07B36.1000501@ru.mvista.com> <46B086EB.2030101@ru.mvista.com> <20070801163926.038c48db@the-village.bc.nu> <20070801165812.3bdb269f@the-village.bc.nu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.14 (2007-02-12) Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 15993 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: ralf@linux-mips.org Precedence: bulk X-list: linux-mips On Wed, Aug 01, 2007 at 05:00:21PM +0100, Maciej W. Rozycki wrote: > #ifdef CONFIG_64BIT_PHYS_ADDR > typedef unsigned long long phys_t; > #else > typedef unsigned long phys_t; > #endif > > so no problem here as long as you enable CONFIG_64BIT_PHYS_ADDR which is > implied in such a case. Which happens to be the solution that is Linus-incompatible so I may eventually have to change it ;-) Ralf From macro@linux-mips.org Wed Aug 1 17:26:46 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 01 Aug 2007 17:26:52 +0100 (BST) Received: from pollux.ds.pg.gda.pl ([153.19.208.7]:9736 "EHLO pollux.ds.pg.gda.pl") by ftp.linux-mips.org with ESMTP id S20021969AbXHAQ0q (ORCPT ); Wed, 1 Aug 2007 17:26:46 +0100 Received: from localhost (localhost [127.0.0.1]) by pollux.ds.pg.gda.pl (Postfix) with ESMTP id 16AC9E1C78; Wed, 1 Aug 2007 18:26:42 +0200 (CEST) X-Virus-Scanned: by amavisd-new at pollux.ds.pg.gda.pl Received: from pollux.ds.pg.gda.pl ([127.0.0.1]) by localhost (pollux.ds.pg.gda.pl [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nwM8QihGGCDy; Wed, 1 Aug 2007 18:26:41 +0200 (CEST) Received: from piorun.ds.pg.gda.pl (piorun.ds.pg.gda.pl [153.19.208.8]) by pollux.ds.pg.gda.pl (Postfix) with ESMTP id AF540E1C63; Wed, 1 Aug 2007 18:26:41 +0200 (CEST) Received: from blysk.ds.pg.gda.pl (macro@blysk.ds.pg.gda.pl [153.19.208.6]) by piorun.ds.pg.gda.pl (8.13.8/8.13.8) with ESMTP id l71GQpbE032143; Wed, 1 Aug 2007 18:26:51 +0200 Date: Wed, 1 Aug 2007 17:26:46 +0100 (BST) From: "Maciej W. Rozycki" To: Sergei Shtylyov cc: Ralf Baechle , linux-mips@linux-mips.org Subject: Re: Modpost warning on Alchemy In-Reply-To: <46B0AA74.7040100@ru.mvista.com> Message-ID: References: <20070801115231.GA20323@linux-mips.org> <46B07B36.1000501@ru.mvista.com> <46B086EB.2030101@ru.mvista.com> <46B0880B.2000009@ru.mvista.com> <46B0AA74.7040100@ru.mvista.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: ClamAV 0.91.1/3846/Wed Aug 1 09:27:07 2007 on piorun.ds.pg.gda.pl X-Virus-Status: Clean Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 15994 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: macro@linux-mips.org Precedence: bulk X-list: linux-mips On Wed, 1 Aug 2007, Sergei Shtylyov wrote: > PCI config. space is mapped at 0x600000000, well beyond KGSEG0/1. It is still just fine with ioremap() -- it will simply use KSEG2 in this case. You cannot bypass the TLB here with a 32-bit processor no matter what. And regarding what you have written above and the size issue you mentioned in another e-mail (do you map the whole PCI config space linearly in the physical address space of the CPU or suchlike?) -- PCI config space accesses are rare (by design rather than chance), so performance is a non-issue and it should be absolutely fine for you to call ioremap() and iounmap() in code specific for your PCI host bridge for the required fragment upon every access. There is no need for a permanent map here. You probably waste more performance by taking away a TLB entry to wire it anyway. > Thanks for wasting time on my education about MIPS. ;-) Well, more about Linux perhaps than MIPS in general. :-) Maciej From macro@linux-mips.org Wed Aug 1 17:33:56 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 01 Aug 2007 17:34:01 +0100 (BST) Received: from pollux.ds.pg.gda.pl ([153.19.208.7]:20742 "EHLO pollux.ds.pg.gda.pl") by ftp.linux-mips.org with ESMTP id S20021437AbXHAQd4 (ORCPT ); Wed, 1 Aug 2007 17:33:56 +0100 Received: from localhost (localhost [127.0.0.1]) by pollux.ds.pg.gda.pl (Postfix) with ESMTP id 8E084E1C78; Wed, 1 Aug 2007 18:33:21 +0200 (CEST) X-Virus-Scanned: by amavisd-new at pollux.ds.pg.gda.pl Received: from pollux.ds.pg.gda.pl ([127.0.0.1]) by localhost (pollux.ds.pg.gda.pl [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QIQYUdjnEp5Q; Wed, 1 Aug 2007 18:33:21 +0200 (CEST) Received: from piorun.ds.pg.gda.pl (piorun.ds.pg.gda.pl [153.19.208.8]) by pollux.ds.pg.gda.pl (Postfix) with ESMTP id 2F900E1C63; Wed, 1 Aug 2007 18:33:21 +0200 (CEST) Received: from blysk.ds.pg.gda.pl (macro@blysk.ds.pg.gda.pl [153.19.208.6]) by piorun.ds.pg.gda.pl (8.13.8/8.13.8) with ESMTP id l71GXV9U000484; Wed, 1 Aug 2007 18:33:31 +0200 Date: Wed, 1 Aug 2007 17:33:25 +0100 (BST) From: "Maciej W. Rozycki" To: Ralf Baechle cc: Alan Cox , Sergei Shtylyov , linux-mips@linux-mips.org Subject: Re: Modpost warning on Alchemy In-Reply-To: <20070801162110.GB14756@linux-mips.org> Message-ID: References: <20070801115231.GA20323@linux-mips.org> <46B07B36.1000501@ru.mvista.com> <46B086EB.2030101@ru.mvista.com> <20070801163926.038c48db@the-village.bc.nu> <20070801165812.3bdb269f@the-village.bc.nu> <20070801162110.GB14756@linux-mips.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: ClamAV 0.91.1/3846/Wed Aug 1 09:27:07 2007 on piorun.ds.pg.gda.pl X-Virus-Status: Clean Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 15995 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: macro@linux-mips.org Precedence: bulk X-list: linux-mips On Wed, 1 Aug 2007, Ralf Baechle wrote: > > so no problem here as long as you enable CONFIG_64BIT_PHYS_ADDR which is > > implied in such a case. > > Which happens to be the solution that is Linus-incompatible so I may > eventually have to change it ;-) Well, however we do it, the width of the physical address cookie used with ioremap() should not be forced to be related to the width of the virtual address space in any way. I see no reason for us to be crippled by limitations of some other architectures or, worse yet, by ones of some code specific to some other platform. Maciej From sshtylyov@ru.mvista.com Wed Aug 1 17:35:11 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 01 Aug 2007 17:35:15 +0100 (BST) Received: from h155.mvista.com ([63.81.120.155]:40545 "EHLO imap.sh.mvista.com") by ftp.linux-mips.org with ESMTP id S20021961AbXHAQfL (ORCPT ); Wed, 1 Aug 2007 17:35:11 +0100 Received: from [192.168.1.248] (unknown [10.150.0.9]) by imap.sh.mvista.com (Postfix) with ESMTP id 8DB2B3EC9; Wed, 1 Aug 2007 09:35:08 -0700 (PDT) Message-ID: <46B0B6B4.5090103@ru.mvista.com> Date: Wed, 01 Aug 2007 20:37:08 +0400 From: Sergei Shtylyov Organization: MontaVista Software Inc. User-Agent: Mozilla/5.0 (X11; U; Linux i686; rv:1.7.2) Gecko/20040803 X-Accept-Language: ru, en-us, en-gb MIME-Version: 1.0 To: "Maciej W. Rozycki" Cc: Ralf Baechle , linux-mips@linux-mips.org Subject: Re: Modpost warning on Alchemy References: <20070801115231.GA20323@linux-mips.org> <46B07B36.1000501@ru.mvista.com> <46B086EB.2030101@ru.mvista.com> <46B0880B.2000009@ru.mvista.com> <46B0AA74.7040100@ru.mvista.com> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 15996 X-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 Maciej W. Rozycki wrote: >> PCI config. space is mapped at 0x600000000, well beyond KGSEG0/1. > It is still just fine with ioremap() -- it will simply use KSEG2 in this > case. You cannot bypass the TLB here with a 32-bit processor no matter > what. > And regarding what you have written above and the size issue you > mentioned in another e-mail (do you map the whole PCI config space > linearly in the physical address space of the CPU or suchlike?) -- PCI No, I don't. But that was why the original code preferred the wired entry approach over ioremap() -- not to map a whole range... > config space accesses are rare (by design rather than chance), so That depends on the drivers used (some IDE drivers access it really often). > performance is a non-issue and it should be absolutely fine for you to > call ioremap() and iounmap() in code specific for your PCI host bridge for > the required fragment upon every access. There is no need for a permanent That's an idea -- however, as the currecnt code uses a cached mapping, this part would certainly need to be saved in the new implementaion -- if someone will go and fix it eventually. :-) > map here. You probably waste more performance by taking away a TLB entry > to wire it anyway. No, I didn't write that code. :-) >> Thanks for wasting time on my education about MIPS. ;-) > Well, more about Linux perhaps than MIPS in general. :-) Let's say that was about Linux/MIPS. But the key word was "wasting". ;-) > Maciej WBR, Sergei From macro@linux-mips.org Wed Aug 1 17:55:07 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 01 Aug 2007 17:55:14 +0100 (BST) Received: from pollux.ds.pg.gda.pl ([153.19.208.7]:25354 "EHLO pollux.ds.pg.gda.pl") by ftp.linux-mips.org with ESMTP id S20021437AbXHAQzH (ORCPT ); Wed, 1 Aug 2007 17:55:07 +0100 Received: from localhost (localhost [127.0.0.1]) by pollux.ds.pg.gda.pl (Postfix) with ESMTP id 0BD38E1C7B; Wed, 1 Aug 2007 18:54:33 +0200 (CEST) X-Virus-Scanned: by amavisd-new at pollux.ds.pg.gda.pl Received: from pollux.ds.pg.gda.pl ([127.0.0.1]) by localhost (pollux.ds.pg.gda.pl [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Dpz2Pa28hqHp; Wed, 1 Aug 2007 18:54:32 +0200 (CEST) Received: from piorun.ds.pg.gda.pl (piorun.ds.pg.gda.pl [153.19.208.8]) by pollux.ds.pg.gda.pl (Postfix) with ESMTP id B8CC4E1C66; Wed, 1 Aug 2007 18:54:32 +0200 (CEST) Received: from blysk.ds.pg.gda.pl (macro@blysk.ds.pg.gda.pl [153.19.208.6]) by piorun.ds.pg.gda.pl (8.13.8/8.13.8) with ESMTP id l71Gsh9P003488; Wed, 1 Aug 2007 18:54:43 +0200 Date: Wed, 1 Aug 2007 17:54:37 +0100 (BST) From: "Maciej W. Rozycki" To: Sergei Shtylyov cc: Ralf Baechle , linux-mips@linux-mips.org Subject: Re: Modpost warning on Alchemy In-Reply-To: <46B0B6B4.5090103@ru.mvista.com> Message-ID: References: <20070801115231.GA20323@linux-mips.org> <46B07B36.1000501@ru.mvista.com> <46B086EB.2030101@ru.mvista.com> <46B0880B.2000009@ru.mvista.com> <46B0AA74.7040100@ru.mvista.com> <46B0B6B4.5090103@ru.mvista.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: ClamAV 0.91.1/3846/Wed Aug 1 09:27:07 2007 on piorun.ds.pg.gda.pl X-Virus-Status: Clean Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 15997 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: macro@linux-mips.org Precedence: bulk X-list: linux-mips On Wed, 1 Aug 2007, Sergei Shtylyov wrote: > > And regarding what you have written above and the size issue you mentioned > > in another e-mail (do you map the whole PCI config space linearly in the > > physical address space of the CPU or suchlike?) -- PCI > > No, I don't. But that was why the original code preferred the wired entry > approach over ioremap() -- not to map a whole range... So what is the issue with the size then? How big is the area? > > config space accesses are rare (by design rather than chance), so > > That depends on the drivers used (some IDE drivers access it really often). It is their problem I would say -- there is a design problem either in these drivers or the hardware handled. The PCI spec is very explicit that the config space is meant to be seldom accessed only. Device initialization/shutdown and bus error recovery are the normal places. > > performance is a non-issue and it should be absolutely fine for you to call > > ioremap() and iounmap() in code specific for your PCI host bridge for the > > required fragment upon every access. There is no need for a permanent > > That's an idea -- however, as the currecnt code uses a cached mapping, this > part would certainly need to be saved in the new implementaion -- if someone > will go and fix it eventually. :-) Well, cached mapping does not seem particularly wise with PCI configuration registers, but you have got the ioremap_cachable() call if you insist. ;-) > > Well, more about Linux perhaps than MIPS in general. :-) > > Let's say that was about Linux/MIPS. But the key word was "wasting". ;-) I reckon the key is how you look at it. ;-) Maciej From alan@lxorguk.ukuu.org.uk Wed Aug 1 18:03:16 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 01 Aug 2007 18:03:21 +0100 (BST) Received: from [81.2.110.250] ([81.2.110.250]:31156 "EHLO the-village.bc.nu") by ftp.linux-mips.org with ESMTP id S20021981AbXHARDQ (ORCPT ); Wed, 1 Aug 2007 18:03:16 +0100 Received: from the-village.bc.nu (localhost.localdomain [127.0.0.1]) by the-village.bc.nu (8.13.8/8.13.8) with ESMTP id l71HAV8L015836; Wed, 1 Aug 2007 18:10:31 +0100 Date: Wed, 1 Aug 2007 18:10:31 +0100 From: Alan Cox To: "Maciej W. Rozycki" Cc: Sergei Shtylyov , Ralf Baechle , linux-mips@linux-mips.org Subject: Re: Modpost warning on Alchemy Message-ID: <20070801181031.390d4f3a@the-village.bc.nu> In-Reply-To: References: <20070801115231.GA20323@linux-mips.org> <46B07B36.1000501@ru.mvista.com> <46B086EB.2030101@ru.mvista.com> <46B0880B.2000009@ru.mvista.com> <46B0AA74.7040100@ru.mvista.com> <46B0B6B4.5090103@ru.mvista.com> X-Mailer: Claws Mail 2.9.1 (GTK+ 2.10.13; i386-redhat-linux-gnu) Organization: Red Hat UK Cyf., Amberley Place, 107-111 Peascod Street, Windsor, Berkshire, SL4 1TE, Y Deyrnas Gyfunol. Cofrestrwyd yng Nghymru a Lloegr o'r rhif cofrestru 3798903 Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 15998 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: alan@lxorguk.ukuu.org.uk Precedence: bulk X-list: linux-mips > > That depends on the drivers used (some IDE drivers access it really often). > > It is their problem I would say -- there is a design problem either in > these drivers or the hardware handled. The PCI spec is very explicit that > the config space is meant to be seldom accessed only. Device > initialization/shutdown and bus error recovery are the normal places. An awful lot of vendors get it horribly wrong and many end up needing configuration space access even in IRQ handlers. Dishonourable mentions to ATI for example ;) From sshtylyov@ru.mvista.com Wed Aug 1 18:04:35 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 01 Aug 2007 18:04:39 +0100 (BST) Received: from h155.mvista.com ([63.81.120.155]:37986 "EHLO imap.sh.mvista.com") by ftp.linux-mips.org with ESMTP id S20021961AbXHAREf (ORCPT ); Wed, 1 Aug 2007 18:04:35 +0100 Received: from [192.168.1.248] (unknown [10.150.0.9]) by imap.sh.mvista.com (Postfix) with ESMTP id CD2683EC9; Wed, 1 Aug 2007 10:04:32 -0700 (PDT) Message-ID: <46B0BD99.6070901@ru.mvista.com> Date: Wed, 01 Aug 2007 21:06:33 +0400 From: Sergei Shtylyov Organization: MontaVista Software Inc. User-Agent: Mozilla/5.0 (X11; U; Linux i686; rv:1.7.2) Gecko/20040803 X-Accept-Language: ru, en-us, en-gb MIME-Version: 1.0 To: "Maciej W. Rozycki" Cc: Ralf Baechle , linux-mips@linux-mips.org Subject: Re: Modpost warning on Alchemy References: <20070801115231.GA20323@linux-mips.org> <46B07B36.1000501@ru.mvista.com> <46B086EB.2030101@ru.mvista.com> <46B0880B.2000009@ru.mvista.com> <46B0AA74.7040100@ru.mvista.com> <46B0B6B4.5090103@ru.mvista.com> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 15999 X-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 Maciej W. Rozycki wrote: >>>And regarding what you have written above and the size issue you mentioned >>>in another e-mail (do you map the whole PCI config space linearly in the >>>physical address space of the CPU or suchlike?) -- PCI >> No, I don't. But that was why the original code preferred the wired entry >>approach over ioremap() -- not to map a whole range... > So what is the issue with the size then? How big is the area? I've already said: 4 gigs! At least in theory, actually it's 2 gigs due to a device # being limited to 0 thru 19 (address bits 11 thru 30 are used as IDSELx). >>>performance is a non-issue and it should be absolutely fine for you to call >>>ioremap() and iounmap() in code specific for your PCI host bridge for the >>>required fragment upon every access. There is no need for a permanent >> That's an idea -- however, as the currecnt code uses a cached mapping, this >>part would certainly need to be saved in the new implementaion -- if someone >>will go and fix it eventually. :-) > Well, cached mapping does not seem particularly wise with PCI > configuration registers, but you have got the ioremap_cachable() call if > you insist. ;-) I meant that the implementation "caches" the 8 KiB mapping used for the last config. access. >>>Well, more about Linux perhaps than MIPS in general. :-) >> Let's say that was about Linux/MIPS. But the key word was "wasting". ;-) > I reckon the key is how you look at it. ;-) There was no need to tell me about how KSEG0/1/2 work -- that's why I cosidered it wasting time. :-) > Maciej WBR, Sergei From sshtylyov@ru.mvista.com Wed Aug 1 18:07:40 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 01 Aug 2007 18:07:46 +0100 (BST) Received: from h155.mvista.com ([63.81.120.155]:40546 "EHLO imap.sh.mvista.com") by ftp.linux-mips.org with ESMTP id S20021981AbXHARHk (ORCPT ); Wed, 1 Aug 2007 18:07:40 +0100 Received: from [192.168.1.248] (unknown [10.150.0.9]) by imap.sh.mvista.com (Postfix) with ESMTP id BA2973EC9; Wed, 1 Aug 2007 10:07:38 -0700 (PDT) Message-ID: <46B0BE52.4000302@ru.mvista.com> Date: Wed, 01 Aug 2007 21:09:38 +0400 From: Sergei Shtylyov Organization: MontaVista Software Inc. User-Agent: Mozilla/5.0 (X11; U; Linux i686; rv:1.7.2) Gecko/20040803 X-Accept-Language: ru, en-us, en-gb MIME-Version: 1.0 To: "Maciej W. Rozycki" Cc: Ralf Baechle , linux-mips@linux-mips.org Subject: Re: Modpost warning on Alchemy References: <20070801115231.GA20323@linux-mips.org> <46B07B36.1000501@ru.mvista.com> <46B086EB.2030101@ru.mvista.com> <46B0880B.2000009@ru.mvista.com> <46B0AA74.7040100@ru.mvista.com> <46B0B6B4.5090103@ru.mvista.com> In-Reply-To: <46B0B6B4.5090103@ru.mvista.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 16000 X-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 Sergei Shtylyov wrote: >> It is still just fine with ioremap() -- it will simply use KSEG2 in >> this case. You cannot bypass the TLB here with a 32-bit processor no >> matter what. >> And regarding what you have written above and the size issue you >> mentioned in another e-mail (do you map the whole PCI config space >> linearly in the physical address space of the CPU or suchlike?) -- PCI > No, I don't. But that was why the original code preferred the wired > entry approach over ioremap() -- not to map a whole range... Not the only one: dynamic ioremap() seems to be impossible in interrupt context. >> config space accesses are rare (by design rather than chance), so > That depends on the drivers used (some IDE drivers access it really > often). >> performance is a non-issue and it should be absolutely fine for you to >> call ioremap() and iounmap() in code specific for your PCI host bridge >> for the required fragment upon every access. There is no need for a >> permanent > That's an idea -- however, as the currecnt code uses a cached No, it seems this actually is not an option. So, the path of least resistence should be taken. WBR, Sergei From yoichi_yuasa@tripeaks.co.jp Thu Aug 2 04:44:50 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 02 Aug 2007 04:44:54 +0100 (BST) Received: from mo31.po.2iij.net ([210.128.50.54]:13132 "EHLO mo31.po.2iij.net") by ftp.linux-mips.org with ESMTP id S20021437AbXHBDou (ORCPT ); Thu, 2 Aug 2007 04:44:50 +0100 Received: by mo.po.2iij.net (mo31) id l723ik1s014689; Thu, 2 Aug 2007 12:44:46 +0900 (JST) Received: from localhost.localdomain (65.126.232.202.bf.2iij.net [202.232.126.65]) by mbox.po.2iij.net (po-mbox302) id l723iiOt002957 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 2 Aug 2007 12:44:45 +0900 Date: Thu, 2 Aug 2007 12:44:44 +0900 From: Yoichi Yuasa To: Ralf Baechle Cc: yoichi_yuasa@tripeaks.co.jp, linux-mips Subject: [PATCH][MIPS] remove unused pnx8550 Kconfig Message-Id: <20070802124444.5dda6060.yoichi_yuasa@tripeaks.co.jp> Organization: TriPeaks Corporation X-Mailer: Sylpheed version 1.0.4 (GTK+ 1.2.10; i386-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 16001 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: yoichi_yuasa@tripeaks.co.jp Precedence: bulk X-list: linux-mips Remove unused pnx8550 Kconfig Signed-off-by: Yoichi Yuasa diff -pruN -X mips/Documentation/dontdiff mips-orig/arch/mips/Kconfig mips/arch/mips/Kconfig --- mips-orig/arch/mips/Kconfig 2007-08-01 11:25:02.551361500 +0900 +++ mips/arch/mips/Kconfig 2007-08-01 11:46:19.307153750 +0900 @@ -604,7 +604,6 @@ source "arch/mips/sibyte/Kconfig" source "arch/mips/tx492