* Re: [UPDATED PATCH] SGIWD93: use cached memory access to make driver work on IP28
From: Ralf Baechle @ 2007-12-08 16:04 UTC (permalink / raw)
To: Thomas Bogendoerfer; +Cc: linux-scsi, linux-mips, James.Bottomley
In-Reply-To: <20071202103309.6A926C2EB4@solo.franken.de>
On Sun, Dec 02, 2007 at 11:33:09AM +0100, Thomas Bogendoerfer wrote:
> SGI IP28 machines would need special treatment (enable adding addtional
> wait states) when accessing memory uncached. To avoid this pain I
> changed the driver to use only cached access to memory.
>
> Signed-off-by: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
Acked-by: Ralf Baechle <ralf@linux-mips.org>
The machine really is as insane as Thomas makes it sound. Actually even
more so.
Ralf
^ permalink raw reply
* Re: [PATCH] SNI_RM: EISA support for A20R/RM200
From: Ralf Baechle @ 2007-12-08 16:05 UTC (permalink / raw)
To: Thomas Bogendoerfer; +Cc: linux-mips
In-Reply-To: <20071130214749.7E597C2EAB@solo.franken.de>
On Fri, Nov 30, 2007 at 10:47:49PM +0100, Thomas Bogendoerfer wrote:
> This patch adds EISA support for non PCI RMs (RM200 and RM400-xxx). The
> major part is the splitting of the EISA and onboard ISA of the RM200,
> which makes the EISA bus on the RM200 look like on other RMs.
>
> Signed-off-by: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
Queued for 2.6.25.
Thanks,
Ralf
^ permalink raw reply
* Re: [UPDATED PATCH] IP28 support
From: Richard Sandiford @ 2007-12-08 17:52 UTC (permalink / raw)
To: Thomas Bogendoerfer; +Cc: Kumba, Ralf Baechle, linux-mips
In-Reply-To: <20071205093938.GA6848@alpha.franken.de>
tsbogend@alpha.franken.de (Thomas Bogendoerfer) writes:
> On Wed, Dec 05, 2007 at 01:16:13AM -0500, Kumba wrote:
>> I've been out of it lately -- did the gcc side of things ever make it in,
>> or do we need to go push on that some more?
>
> We need push on that. Looking at
>
> http://gcc.gnu.org/ml/gcc-patches/2006-04/msg00291.html
>
> there seems to be a missing understanding, why the cache
> barriers are needed.
Heh. Quite probably. Which bit of my message don't you agree with?
FWIW, I was going off the original message as posted here:
http://gcc.gnu.org/ml/gcc-patches/2006-03/msg00090.html
The explanation of the chosen workaround seemed to be left to this bit
of http://mail-index.netbsd.org/port-sgimips/2000/06/29/0006.html:
All is well with coherent IO systems. On non coherent
systems like Indigo2 and O2 this creates a race
condition with DMA reads (IO->mem) where a stale
cached data can be written back over the DMAed data.
R10K Indigo2:
This issue was figured out late the the R10K I2
design cycle. The problem was fixed by modifying
the compiler and assembler to issue a cache barrier
instruction to address 0(sp) as the first instruction
in basic blocks that contain stores to registers
other than $0 and $sp.
and from a compiler point of view, it would be nice to know
_why_ that was a reasonable workaround. What I was really
looking for was: (a) a short description of the problem,
(b) a list of assumptions that the compiler is going to
make when working around the problem and (c) a description
of what said workarounds are.
My understanding of (a) is that, if a store is speculatively executed,
the target of the store might be fetched into cache and marked dirty.
We therefore want to avoid the speculative execution of stores if:
(1) the addressed memory might be the target of a later DMA operation.
If the DMA completes before the "dirty" cache line is flushed,
the cached data might overwrite the DMAed data.
(2) the addressed memory might be to IO-mapped cached memory
(usually through the address being garbage). The cached
data will be written back to the IO region when flushed.
We also want to avoid speculative execution of loads if:
(3) the addressed memory might be to load-sensitive IO-mapped cached
memory (usually through the address being garbage). The hardware
would "see" loads that aren't actually executed.
Is that vaguely accurate?
I tried to piece together (b) by asking questions in the reviews,
but it would be great to have a single explanation.
The idea behind (c) is simple, of course: we insert a cache barrier
before the potentially-problematic stores (and, for certain
configurations, loads, although the original gcc patch had the
associated macro hard-wired to false). The key is explaining how,
from a compiler internals viewpoint, we decide what is "potentially-
problematic". This ties in with the assumptions for (b).
I'm sure my attempt at (a) above can be improved upon even if it's
vaguely right. But...
> I guess the patch could be improved
> by pointing directly to the errata section of the R10k
> user manual.
...I think an integrated explanation of (a), (b) and (c) above
would be better than quoting large parts of the processor manual.
The processor manual is aimed at a much broader audience and has
a lot of superfluous info. It also doesn't explain what _our_
assumptions are and what our chosen workaround is.
Richard
^ permalink raw reply
* Re: [UPDATED PATCH] IP28 support
From: Richard Sandiford @ 2007-12-08 17:52 UTC (permalink / raw)
To: Thomas Bogendoerfer; +Cc: Kumba, Ralf Baechle, linux-mips
In-Reply-To: <20071205093938.GA6848@alpha.franken.de>
tsbogend@alpha.franken.de (Thomas Bogendoerfer) writes:
> On Wed, Dec 05, 2007 at 01:16:13AM -0500, Kumba wrote:
>> I've been out of it lately -- did the gcc side of things ever make it in,
>> or do we need to go push on that some more?
>
> We need push on that. Looking at
>
> http://gcc.gnu.org/ml/gcc-patches/2006-04/msg00291.html
>
> there seems to be a missing understanding, why the cache
> barriers are needed.
Heh. Quite probably. Which bit of my message don't you agree with?
FWIW, I was going off the original message as posted here:
http://gcc.gnu.org/ml/gcc-patches/2006-03/msg00090.html
The explanation of the chosen workaround seemed to be left to this bit
of http://mail-index.netbsd.org/port-sgimips/2000/06/29/0006.html:
All is well with coherent IO systems. On non coherent
systems like Indigo2 and O2 this creates a race
condition with DMA reads (IO->mem) where a stale
cached data can be written back over the DMAed data.
R10K Indigo2:
This issue was figured out late the the R10K I2
design cycle. The problem was fixed by modifying
the compiler and assembler to issue a cache barrier
instruction to address 0(sp) as the first instruction
in basic blocks that contain stores to registers
other than $0 and $sp.
and from a compiler point of view, it would be nice to know
_why_ that was a reasonable workaround. What I was really
looking for was: (a) a short description of the problem,
(b) a list of assumptions that the compiler is going to
make when working around the problem and (c) a description
of what said workarounds are.
My understanding of (a) is that, if a store is speculatively executed,
the target of the store might be fetched into cache and marked dirty.
We therefore want to avoid the speculative execution of stores if:
(1) the addressed memory might be the target of a later DMA operation.
If the DMA completes before the "dirty" cache line is flushed,
the cached data might overwrite the DMAed data.
(2) the addressed memory might be to IO-mapped cached memory
(usually through the address being garbage). The cached
data will be written back to the IO region when flushed.
We also want to avoid speculative execution of loads if:
(3) the addressed memory might be to load-sensitive IO-mapped cached
memory (usually through the address being garbage). The hardware
would "see" loads that aren't actually executed.
Is that vaguely accurate?
I tried to piece together (b) by asking questions in the reviews,
but it would be great to have a single explanation.
The idea behind (c) is simple, of course: we insert a cache barrier
before the potentially-problematic stores (and, for certain
configurations, loads, although the original gcc patch had the
associated macro hard-wired to false). The key is explaining how,
from a compiler internals viewpoint, we decide what is "potentially-
problematic". This ties in with the assumptions for (b).
I'm sure my attempt at (a) above can be improved upon even if it's
vaguely right. But...
> I guess the patch could be improved
> by pointing directly to the errata section of the R10k
> user manual.
...I think an integrated explanation of (a), (b) and (c) above
would be better than quoting large parts of the processor manual.
The processor manual is aimed at a much broader audience and has
a lot of superfluous info. It also doesn't explain what _our_
assumptions are and what our chosen workaround is.
Richard
^ permalink raw reply
* RE: SiByte 1480 & Branch Likely instructions?
From: Kaz Kylheku @ 2007-12-07 23:39 UTC (permalink / raw)
To: linux-mips
In-Reply-To: <DDFD17CC94A9BD49A82147DDF7D545C5590CF0@exchange.ZeugmaSystems.local>
Kaz wrote:
> Hi All,
>
> Not really a kernel-related question. I've discovered that GCC 4.1.1
> (which I'm not using for kernel compiling, but user space) generates
> branch likely instructions by default, even though the documentation
> says that their use is off by default for MIPS32 and MIPS64, because
That's because the compiler is not configured correctly. The default CPU
string "from-abi" ends up being used, and so the target ISA is MIPS III.
> In parallel with writing some tests, I thought I would ask whether
> anyone happens know whether or not these instructions are known to
> actually work correctly on the SB1480 silicon (and perhaps any
> additional details, like what revisions, etc)?
A basic sanity test does find bnezl working.
#include <stdio.h>
#include <stdlib.h>
static int branch_likely_works(void)
{
int one = 1;
int result;
__asm__ __volatile__
(" .set push\n"
" .set noreorder\n"
"1: move %0, $0\n"
" bnezl %0, 1b\n"
" lw %0, %1\n"
" .set pop\n"
: "=r" (result)
: "m" (one));
return result == 0;
}
int main(void)
{
if (branch_likely_works()) {
puts("branch-likely instruction bnezl correctly annuls delay
slot");
return 0;
}
puts("branch-likely instruction bnezl fails to annul delay slot");
return EXIT_FAILURE;
}
^ permalink raw reply
* RE: SiByte 1480 & Branch Likely instructions?
From: Kaz Kylheku @ 2007-12-07 23:39 UTC (permalink / raw)
To: linux-mips
In-Reply-To: <DDFD17CC94A9BD49A82147DDF7D545C5590CF0@exchange.ZeugmaSystems.local>
Kaz wrote:
> Hi All,
>
> Not really a kernel-related question. I've discovered that GCC 4.1.1
> (which I'm not using for kernel compiling, but user space) generates
> branch likely instructions by default, even though the documentation
> says that their use is off by default for MIPS32 and MIPS64, because
That's because the compiler is not configured correctly. The default CPU
string "from-abi" ends up being used, and so the target ISA is MIPS III.
> In parallel with writing some tests, I thought I would ask whether
> anyone happens know whether or not these instructions are known to
> actually work correctly on the SB1480 silicon (and perhaps any
> additional details, like what revisions, etc)?
A basic sanity test does find bnezl working.
#include <stdio.h>
#include <stdlib.h>
static int branch_likely_works(void)
{
int one = 1;
int result;
__asm__ __volatile__
(" .set push\n"
" .set noreorder\n"
"1: move %0, $0\n"
" bnezl %0, 1b\n"
" lw %0, %1\n"
" .set pop\n"
: "=r" (result)
: "m" (one));
return result == 0;
}
int main(void)
{
if (branch_likely_works()) {
puts("branch-likely instruction bnezl correctly annuls delay
slot");
return 0;
}
puts("branch-likely instruction bnezl fails to annul delay slot");
return EXIT_FAILURE;
}
^ permalink raw reply
* SiByte 1480 & Branch Likely instructions?
From: Kaz Kylheku @ 2007-12-07 21:54 UTC (permalink / raw)
To: linux-mips
Hi All,
Not really a kernel-related question. I've discovered that GCC 4.1.1
(which I'm not using for kernel compiling, but user space) generates
branch likely instructions by default, even though the documentation
says that their use is off by default for MIPS32 and MIPS64, because
they are considered deprecated. They are documented as obsolete for the
Broadcom chips I am working with.
I'm investigating a software anomaly which looks like might be caused by
failure to annul the delay slot of a branch-likely in the fall-through
case.
In parallel with writing some tests, I thought I would ask whether
anyone happens know whether or not these instructions are known to
actually work correctly on the SB1480 silicon (and perhaps any
additional details, like what revisions, etc)?
Thanks
^ permalink raw reply
* SiByte 1480 & Branch Likely instructions?
From: Kaz Kylheku @ 2007-12-07 21:54 UTC (permalink / raw)
To: linux-mips
Hi All,
Not really a kernel-related question. I've discovered that GCC 4.1.1
(which I'm not using for kernel compiling, but user space) generates
branch likely instructions by default, even though the documentation
says that their use is off by default for MIPS32 and MIPS64, because
they are considered deprecated. They are documented as obsolete for the
Broadcom chips I am working with.
I'm investigating a software anomaly which looks like might be caused by
failure to annul the delay slot of a branch-likely in the fall-through
case.
In parallel with writing some tests, I thought I would ask whether
anyone happens know whether or not these instructions are known to
actually work correctly on the SB1480 silicon (and perhaps any
additional details, like what revisions, etc)?
Thanks
^ permalink raw reply
* Unhandled kernel unaligned access in do_ade+0x2b8/0x430
From: Giuseppe Sacco @ 2007-12-07 15:03 UTC (permalink / raw)
To: linux-mips
Does anyone already happenend to see this problem?
Unhandled kernel unaligned access[#1]
Cpu 0
[...]
Status: 9401fce3 KX SX UK KERNEL EXL IE
Cause : 00000010
BadVA : bfffff000fe8fa2a
PrId : 00002321
[...]
Process swapper (pid: 0, threadinfo=ffffffff8037c000,
task=ffffffff803802f0)
[...]
Call Trace:
[<ffffffff8000e1f8>] do_ade+0x2b8/0x430
[<ffffffff8000746c>] handle_adel_int+0x34/0x48
Code: 00431024 5440ffae de0201000 <89230000> 99230003 24020000 1440ffe7
00051402 08003854
^ permalink raw reply
* Re: [RFC PATCH] Alchemy: Au1210/Au1250 CPU support
From: Ralf Baechle @ 2007-12-07 11:56 UTC (permalink / raw)
To: Manuel Lauss; +Cc: linux-mips
In-Reply-To: <20071206080755.GA20485@roarinelk.homelinux.net>
On Thu, Dec 06, 2007 at 09:07:55AM +0100, Manuel Lauss wrote:
> This patch adds IDs fornew Au1200 variants: Au1210 and Au1250.
> They are essentially identical to the Au1200 except for the Au1210
> which has a different SoC-ID in the PRId register [bits 31:24].
> The Au1250 is a "Au1200 V0.2".
>
> Signed-off-by: Manuel Lauss <mano@roarinelk.homelinux.net>
Looks ok, queued for 2.6.25.
Ralf
^ permalink raw reply
* Re: [PATCH] Alchemy: Fix Au1x SD controller IRQ
From: Ralf Baechle @ 2007-12-07 1:55 UTC (permalink / raw)
To: Manuel Lauss; +Cc: linux-mips
In-Reply-To: <20071206071156.GA20211@roarinelk.homelinux.net>
On Thu, Dec 06, 2007 at 08:11:56AM +0100, Manuel Lauss wrote:
> With the introduction of MIPS_CPU_IRQ_BASE, the hardcoded IRQ number
> of the au1100/au1200 SD controller(s) is no longer valid.
>
> Signed-off-by: Manuel Lauss <mano@roarinelk.homelinux.net>
Thanks, applied.
Ralf
^ permalink raw reply
* Re: Bug in Au1x00 UART or USB drivers for 2.6 kernels?
From: Nathan Eggan @ 2007-12-07 0:00 UTC (permalink / raw)
To: linux-mips mailing list
A'ight... I just finished pulling down a copy of the Linux-mips kernel 2.6.23.9 and building it for my DBAu1500. I was hoping this would fix the issue I'm experiencing with the serial ports and the USB bus. (For those that didn't catch the previous emails, I'm suffering byte substitution in a very regular pattern on the Au1500's UARTs when I put activity on the USB bus.)
Unfortunately, the new kernel appears to have no effect. :( It performs the same as the previous.
For the record, my tested setup was:
- Linux 2.6.23 with the MIPS patches
- Busybox 1.7.3 (doubt this is relevant)
- compiled with uClibc-0.9.28 & gcc-3.4.5 (this probably isn't relevant either)
All the tests I've discussed to date were down with the test code previously included in this thread, and the serial port was set for 115,200bps 8-N-1. (I've heard the 115k number can be taboo for some unknown reason, but we really need the speed on the UART. :( (It's already slow enough!) So, I'm not sure too many folks would be happy if I halve it 56k to try to make it work.
A few other notes:
- As previously stated, a 2.4.26 kernel I tried worked fine; so this looks to be a 2.6 kernel issue. (I've now tried 2.6.17, 2.6.21, and 2.6.23.9 and all have the same issue.)
- I also tried using an FTDI USB-to-serial dongle and experienced NO errors. So, this is clearly an interplay issue between the UART and the USB bus.
Any other others?
Thanks again!
Nate
_________________________________________________________________
Put your friends on the big screen with Windows Vista® + Windows Live™.
http://www.microsoft.com/windows/shop/specialoffers.mspx?ocid=TXT_TAGLM_CPC_MediaCtr_bigscreen_102007
From ralf@linux-mips.org Fri Dec 7 11:37:58 2007
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 07 Dec 2007 11:38:01 +0000 (GMT)
Received: from localhost.localdomain ([127.0.0.1]:19932 "EHLO
dl5rb.ham-radio-op.net") by ftp.linux-mips.org with ESMTP
id S20031765AbXLGLh6 (ORCPT <rfc822;linux-mips@linux-mips.org>);
Fri, 7 Dec 2007 11:37:58 +0000
Received: from denk.linux-mips.net (denk.linux-mips.net [127.0.0.1])
by dl5rb.ham-radio-op.net (8.14.1/8.13.8) with ESMTP id lB7BbMin007612;
Fri, 7 Dec 2007 11:37:22 GMT
Received: (from ralf@localhost)
by denk.linux-mips.net (8.14.1/8.14.1/Submit) id lB71tKbv001304;
Fri, 7 Dec 2007 01:55:20 GMT
Date: Fri, 7 Dec 2007 01:55:20 +0000
From: Ralf Baechle <ralf@linux-mips.org>
To: Manuel Lauss <mano@roarinelk.homelinux.net>
Cc: linux-mips@linux-mips.org
Subject: Re: [PATCH] Alchemy: Fix Au1x SD controller IRQ
Message-ID: <20071207015519.GA1231@linux-mips.org>
References: <20071206071156.GA20211@roarinelk.homelinux.net>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20071206071156.GA20211@roarinelk.homelinux.net>
User-Agent: Mutt/1.5.17 (2007-11-01)
Return-Path: <ralf@linux-mips.org>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 17726
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: ralf@linux-mips.org
Precedence: bulk
X-list: linux-mips
On Thu, Dec 06, 2007 at 08:11:56AM +0100, Manuel Lauss wrote:
> With the introduction of MIPS_CPU_IRQ_BASE, the hardcoded IRQ number
> of the au1100/au1200 SD controller(s) is no longer valid.
>
> Signed-off-by: Manuel Lauss <mano@roarinelk.homelinux.net>
Thanks, applied.
Ralf
^ permalink raw reply
* Re: Bug in Au1x00 UART or USB drivers for 2.6 kernels?
From: Nathan Eggan @ 2007-12-07 0:00 UTC (permalink / raw)
To: linux-mips mailing list
A'ight... I just finished pulling down a copy of the Linux-mips kernel 2.6.23.9 and building it for my DBAu1500. I was hoping this would fix the issue I'm experiencing with the serial ports and the USB bus. (For those that didn't catch the previous emails, I'm suffering byte substitution in a very regular pattern on the Au1500's UARTs when I put activity on the USB bus.)
Unfortunately, the new kernel appears to have no effect. :( It performs the same as the previous.
For the record, my tested setup was:
- Linux 2.6.23 with the MIPS patches
- Busybox 1.7.3 (doubt this is relevant)
- compiled with uClibc-0.9.28 & gcc-3.4.5 (this probably isn't relevant either)
All the tests I've discussed to date were down with the test code previously included in this thread, and the serial port was set for 115,200bps 8-N-1. (I've heard the 115k number can be taboo for some unknown reason, but we really need the speed on the UART. :( (It's already slow enough!) So, I'm not sure too many folks would be happy if I halve it 56k to try to make it work.
A few other notes:
- As previously stated, a 2.4.26 kernel I tried worked fine; so this looks to be a 2.6 kernel issue. (I've now tried 2.6.17, 2.6.21, and 2.6.23.9 and all have the same issue.)
- I also tried using an FTDI USB-to-serial dongle and experienced NO errors. So, this is clearly an interplay issue between the UART and the USB bus.
Any other others?
Thanks again!
Nate
_________________________________________________________________
Put your friends on the big screen with Windows Vista® + Windows Live™.
http://www.microsoft.com/windows/shop/specialoffers.mspx?ocid=TXT_TAGLM_CPC_MediaCtr_bigscreen_102007
^ permalink raw reply
* Re: [PATCH] Alchemy: fix PCI resource conflict
From: Sergei Shtylyov @ 2007-12-06 18:33 UTC (permalink / raw)
To: Ralf Baechle; +Cc: linux-mips
In-Reply-To: <20071206182639.GB24263@linux-mips.org>
Hello.
Ralf Baechle wrote:
>>From: Sergei Shtylyov <sshtylyov@ru.mvista.com>
>>Date: Thu, 6 Dec 2007 20:56:06 +0300
>>To: ralf@linux-mips.org
>>Cc: linux-mips@linux-mips.org
>>Subject: [PATCH] Alchemy: fix PCI resource conflict
>>Content-Type: text/plain;
>> charset="us-ascii"
>>... by getting the PCI resources back into the 32-bit range -- there's no need
>>therefore for CONFIG_RESOURCES_64BIT either. This makes Alchemy PCI work again
>>while currently the kernel skips the bus scan.
> So now you're using the numeric overflow to get things to "work"?
Kinda. :-) Note that it was used in non-PCI case anyway.
> Ralf
WBR, Sergei
^ permalink raw reply
* Re: [PATCH] Alchemy: fix PCI resource conflict
From: Ralf Baechle @ 2007-12-06 18:26 UTC (permalink / raw)
To: Sergei Shtylyov; +Cc: linux-mips
In-Reply-To: <200712062056.06326.sshtylyov@ru.mvista.com>
On Thu, Dec 06, 2007 at 08:56:06PM +0300, Sergei Shtylyov wrote:
> From: Sergei Shtylyov <sshtylyov@ru.mvista.com>
> Date: Thu, 6 Dec 2007 20:56:06 +0300
> To: ralf@linux-mips.org
> Cc: linux-mips@linux-mips.org
> Subject: [PATCH] Alchemy: fix PCI resource conflict
> Content-Type: text/plain;
> charset="us-ascii"
>
> ... by getting the PCI resources back into the 32-bit range -- there's no need
> therefore for CONFIG_RESOURCES_64BIT either. This makes Alchemy PCI work again
> while currently the kernel skips the bus scan.
So now you're using the numeric overflow to get things to "work"?
Ralf
^ permalink raw reply
* [PATCH] Alchemy: fix PCI resource conflict
From: Sergei Shtylyov @ 2007-12-06 17:56 UTC (permalink / raw)
To: ralf; +Cc: linux-mips
... by getting the PCI resources back into the 32-bit range -- there's no need
therefore for CONFIG_RESOURCES_64BIT either. This makes Alchemy PCI work again
while currently the kernel skips the bus scan.
Signed-off-by: Sergei Shtylyov <sshtylyov@ru.mvista.com>
arch/mips/au1000/Kconfig | 9 ---------
arch/mips/au1000/common/pci.c | 8 ++++----
include/asm-mips/mach-au1x00/au1000.h | 9 +++++----
3 files changed, 9 insertions(+), 17 deletions(-)
Index: linux-2.6/arch/mips/au1000/Kconfig
===================================================================
--- linux-2.6.orig/arch/mips/au1000/Kconfig
+++ linux-2.6/arch/mips/au1000/Kconfig
@@ -7,7 +7,6 @@ config MIPS_MTX1
bool "4G Systems MTX-1 board"
select DMA_NONCOHERENT
select HW_HAS_PCI
- select RESOURCES_64BIT if PCI
select SOC_AU1500
select SYS_SUPPORTS_LITTLE_ENDIAN
@@ -22,7 +21,6 @@ config MIPS_DB1000
select SOC_AU1000
select DMA_NONCOHERENT
select HW_HAS_PCI
- select RESOURCES_64BIT if PCI
select SYS_SUPPORTS_LITTLE_ENDIAN
config MIPS_DB1100
@@ -44,7 +42,6 @@ config MIPS_DB1500
select DMA_NONCOHERENT
select HW_HAS_PCI
select MIPS_DISABLE_OBSOLETE_IDE
- select RESOURCES_64BIT if PCI
select SYS_SUPPORTS_BIG_ENDIAN
select SYS_SUPPORTS_LITTLE_ENDIAN
@@ -54,7 +51,6 @@ config MIPS_DB1550
select HW_HAS_PCI
select DMA_NONCOHERENT
select MIPS_DISABLE_OBSOLETE_IDE
- select RESOURCES_64BIT if PCI
select SYS_SUPPORTS_LITTLE_ENDIAN
config MIPS_MIRAGE
@@ -68,7 +64,6 @@ config MIPS_PB1000
select SOC_AU1000
select DMA_NONCOHERENT
select HW_HAS_PCI
- select RESOURCES_64BIT if PCI
select SWAP_IO_SPACE
select SYS_SUPPORTS_LITTLE_ENDIAN
@@ -77,7 +72,6 @@ config MIPS_PB1100
select SOC_AU1100
select DMA_NONCOHERENT
select HW_HAS_PCI
- select RESOURCES_64BIT if PCI
select SWAP_IO_SPACE
select SYS_SUPPORTS_LITTLE_ENDIAN
@@ -86,7 +80,6 @@ config MIPS_PB1200
select SOC_AU1200
select DMA_NONCOHERENT
select MIPS_DISABLE_OBSOLETE_IDE
- select RESOURCES_64BIT if PCI
select SYS_SUPPORTS_LITTLE_ENDIAN
config MIPS_PB1500
@@ -94,7 +87,6 @@ config MIPS_PB1500
select SOC_AU1500
select DMA_NONCOHERENT
select HW_HAS_PCI
- select RESOURCES_64BIT if PCI
select SYS_SUPPORTS_LITTLE_ENDIAN
config MIPS_PB1550
@@ -103,7 +95,6 @@ config MIPS_PB1550
select DMA_NONCOHERENT
select HW_HAS_PCI
select MIPS_DISABLE_OBSOLETE_IDE
- select RESOURCES_64BIT if PCI
select SYS_SUPPORTS_LITTLE_ENDIAN
config MIPS_XXS1500
Index: linux-2.6/arch/mips/au1000/common/pci.c
===================================================================
--- linux-2.6.orig/arch/mips/au1000/common/pci.c
+++ linux-2.6/arch/mips/au1000/common/pci.c
@@ -39,15 +39,15 @@
/* TBD */
static struct resource pci_io_resource = {
- .start = (resource_size_t)PCI_IO_START,
- .end = (resource_size_t)PCI_IO_END,
+ .start = PCI_IO_START,
+ .end = PCI_IO_END,
.name = "PCI IO space",
.flags = IORESOURCE_IO
};
static struct resource pci_mem_resource = {
- .start = (resource_size_t)PCI_MEM_START,
- .end = (resource_size_t)PCI_MEM_END,
+ .start = PCI_MEM_START,
+ .end = PCI_MEM_END,
.name = "PCI memory space",
.flags = IORESOURCE_MEM
};
Index: linux-2.6/include/asm-mips/mach-au1x00/au1000.h
===================================================================
--- linux-2.6.orig/include/asm-mips/mach-au1x00/au1000.h
+++ linux-2.6/include/asm-mips/mach-au1x00/au1000.h
@@ -1680,10 +1680,11 @@ enum soc_au1200_ints {
#define Au1500_PCI_MEM_START 0x440000000ULL
#define Au1500_PCI_MEM_END 0x44FFFFFFFULL
-#define PCI_IO_START (Au1500_PCI_IO_START + 0x1000)
-#define PCI_IO_END (Au1500_PCI_IO_END)
-#define PCI_MEM_START (Au1500_PCI_MEM_START)
-#define PCI_MEM_END (Au1500_PCI_MEM_END)
+#define PCI_IO_START (u32)(Au1500_PCI_IO_START + 0x1000)
+#define PCI_IO_END (u32) Au1500_PCI_IO_END
+#define PCI_MEM_START (u32) Au1500_PCI_MEM_START
+#define PCI_MEM_END (u32) Au1500_PCI_MEM_END
+
#define PCI_FIRST_DEVFN (0<<3)
#define PCI_LAST_DEVFN (19<<3)
^ permalink raw reply
* Re: Bug in Au1x00 UART or USB drivers for 2.6 kernels?
From: Nathan Eggan @ 2007-12-06 17:11 UTC (permalink / raw)
To: linux-mips mailing list
In-Reply-To: <20071206165100.GP2391@dusktilldawn.nl>
>
> ----------------------------------------
> > Date: Thu, 6 Dec 2007 17:51:00 +0100
> > From: freddy@dusktilldawn.nl
> > To: nathan_eggan@live.com
> > CC: linux-mips@linux-mips.org
> > Subject: Re: Bug in Au1x00 UART or USB drivers for 2.6 kernels?
> >
> > Hi Nathan,
> >
> > On Thu, Dec 06, 2007 at 04:41:23PM +0000, Nathan Eggan wrote:
> > > Can anyone see this?
> >
> > Yes, your message came through clearly.
> >
> > And to reply a little bit more on topic. I had also some strange
> > serial trouble with 2.6.16, but it dissapeared when I used
> > 2.6.23.9. The trouble I had was using 115200bps and for some strange
> > reason bytes would be missing on one of the interfaces. I had no
> > trouble on ttyS2, but ttyS0 would. Strange, but using 2.6.23.9 I
> > did not experience the same problems. I did not investigate the
> > real cause, but just wanted to let you know.
> >
> >
> > --
> > $ cat ~/.signature
> > Freddy Spierenburg <freddy@dusktilldawn.nl> http://freddy.snarl.nl/
> > GnuPG: 0x7941D1E1=C948 5851 26D2 FA5C 39F1 E588 6F17 FD5D 7941 D1E1
> > $ # Please read http://www.ietf.org/rfc/rfc2015.txt before complain!
>
>
> Thanks Freddy! It's good to hear you folks can see this. (I hope you can see this response. M$'s crappy reply has converted all the original text to HTML escaped charactes. :( )
>
> I was reading up on the latest kernel changes you folks are implementing, and I noticed that new IRQ handlers are being coded into 2.6.23 and 2.6.24. So, perhaps that's the resolution that's required. I've been in the process of pulling down the latest kernel source and getting it up and running; so perhaps that'll fix everything for me.
>
> Thanks again.
> Nate
> _________________________________________________________________
> Connect and share in new ways with Windows Live.
> http://www.windowslive.com/connect.html?ocid=TXT_TAGLM_Wave2_newways_112007
_________________________________________________________________
You keep typing, we keep giving. Download Messenger and join the i’m Initiative now.
http://im.live.com/messenger/im/home/?source=TAGLM
From sshtylyov@ru.mvista.com Thu Dec 6 17:56:19 2007
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 06 Dec 2007 17:56:28 +0000 (GMT)
Received: from rtsoft3.corbina.net ([85.21.88.6]:1318 "EHLO
buildserver.ru.mvista.com") by ftp.linux-mips.org with ESMTP
id S20027331AbXLFR4T (ORCPT <rfc822;linux-mips@linux-mips.org>);
Thu, 6 Dec 2007 17:56:19 +0000
Received: from wasted.dev.rtsoft.ru (unknown [10.150.0.9])
by buildserver.ru.mvista.com (Postfix) with ESMTP
id B50508810; Thu, 6 Dec 2007 22:55:47 +0400 (SAMT)
From: Sergei Shtylyov <sshtylyov@ru.mvista.com>
Organization: MontaVista Software Inc.
To: ralf@linux-mips.org
Subject: [PATCH] Alchemy: fix PCI resource conflict
Date: Thu, 6 Dec 2007 20:56:06 +0300
User-Agent: KMail/1.5
Cc: linux-mips@linux-mips.org
MIME-Version: 1.0
Content-Type: text/plain;
charset="us-ascii"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Message-Id: <200712062056.06326.sshtylyov@ru.mvista.com>
Return-Path: <sshtylyov@ru.mvista.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 17722
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: sshtylyov@ru.mvista.com
Precedence: bulk
X-list: linux-mips
... by getting the PCI resources back into the 32-bit range -- there's no need
therefore for CONFIG_RESOURCES_64BIT either. This makes Alchemy PCI work again
while currently the kernel skips the bus scan.
Signed-off-by: Sergei Shtylyov <sshtylyov@ru.mvista.com>
arch/mips/au1000/Kconfig | 9 ---------
arch/mips/au1000/common/pci.c | 8 ++++----
include/asm-mips/mach-au1x00/au1000.h | 9 +++++----
3 files changed, 9 insertions(+), 17 deletions(-)
Index: linux-2.6/arch/mips/au1000/Kconfig
===================================================================
--- linux-2.6.orig/arch/mips/au1000/Kconfig
+++ linux-2.6/arch/mips/au1000/Kconfig
@@ -7,7 +7,6 @@ config MIPS_MTX1
bool "4G Systems MTX-1 board"
select DMA_NONCOHERENT
select HW_HAS_PCI
- select RESOURCES_64BIT if PCI
select SOC_AU1500
select SYS_SUPPORTS_LITTLE_ENDIAN
@@ -22,7 +21,6 @@ config MIPS_DB1000
select SOC_AU1000
select DMA_NONCOHERENT
select HW_HAS_PCI
- select RESOURCES_64BIT if PCI
select SYS_SUPPORTS_LITTLE_ENDIAN
config MIPS_DB1100
@@ -44,7 +42,6 @@ config MIPS_DB1500
select DMA_NONCOHERENT
select HW_HAS_PCI
select MIPS_DISABLE_OBSOLETE_IDE
- select RESOURCES_64BIT if PCI
select SYS_SUPPORTS_BIG_ENDIAN
select SYS_SUPPORTS_LITTLE_ENDIAN
@@ -54,7 +51,6 @@ config MIPS_DB1550
select HW_HAS_PCI
select DMA_NONCOHERENT
select MIPS_DISABLE_OBSOLETE_IDE
- select RESOURCES_64BIT if PCI
select SYS_SUPPORTS_LITTLE_ENDIAN
config MIPS_MIRAGE
@@ -68,7 +64,6 @@ config MIPS_PB1000
select SOC_AU1000
select DMA_NONCOHERENT
select HW_HAS_PCI
- select RESOURCES_64BIT if PCI
select SWAP_IO_SPACE
select SYS_SUPPORTS_LITTLE_ENDIAN
@@ -77,7 +72,6 @@ config MIPS_PB1100
select SOC_AU1100
select DMA_NONCOHERENT
select HW_HAS_PCI
- select RESOURCES_64BIT if PCI
select SWAP_IO_SPACE
select SYS_SUPPORTS_LITTLE_ENDIAN
@@ -86,7 +80,6 @@ config MIPS_PB1200
select SOC_AU1200
select DMA_NONCOHERENT
select MIPS_DISABLE_OBSOLETE_IDE
- select RESOURCES_64BIT if PCI
select SYS_SUPPORTS_LITTLE_ENDIAN
config MIPS_PB1500
@@ -94,7 +87,6 @@ config MIPS_PB1500
select SOC_AU1500
select DMA_NONCOHERENT
select HW_HAS_PCI
- select RESOURCES_64BIT if PCI
select SYS_SUPPORTS_LITTLE_ENDIAN
config MIPS_PB1550
@@ -103,7 +95,6 @@ config MIPS_PB1550
select DMA_NONCOHERENT
select HW_HAS_PCI
select MIPS_DISABLE_OBSOLETE_IDE
- select RESOURCES_64BIT if PCI
select SYS_SUPPORTS_LITTLE_ENDIAN
config MIPS_XXS1500
Index: linux-2.6/arch/mips/au1000/common/pci.c
===================================================================
--- linux-2.6.orig/arch/mips/au1000/common/pci.c
+++ linux-2.6/arch/mips/au1000/common/pci.c
@@ -39,15 +39,15 @@
/* TBD */
static struct resource pci_io_resource = {
- .start = (resource_size_t)PCI_IO_START,
- .end = (resource_size_t)PCI_IO_END,
+ .start = PCI_IO_START,
+ .end = PCI_IO_END,
.name = "PCI IO space",
.flags = IORESOURCE_IO
};
static struct resource pci_mem_resource = {
- .start = (resource_size_t)PCI_MEM_START,
- .end = (resource_size_t)PCI_MEM_END,
+ .start = PCI_MEM_START,
+ .end = PCI_MEM_END,
.name = "PCI memory space",
.flags = IORESOURCE_MEM
};
Index: linux-2.6/include/asm-mips/mach-au1x00/au1000.h
===================================================================
--- linux-2.6.orig/include/asm-mips/mach-au1x00/au1000.h
+++ linux-2.6/include/asm-mips/mach-au1x00/au1000.h
@@ -1680,10 +1680,11 @@ enum soc_au1200_ints {
#define Au1500_PCI_MEM_START 0x440000000ULL
#define Au1500_PCI_MEM_END 0x44FFFFFFFULL
-#define PCI_IO_START (Au1500_PCI_IO_START + 0x1000)
-#define PCI_IO_END (Au1500_PCI_IO_END)
-#define PCI_MEM_START (Au1500_PCI_MEM_START)
-#define PCI_MEM_END (Au1500_PCI_MEM_END)
+#define PCI_IO_START (u32)(Au1500_PCI_IO_START + 0x1000)
+#define PCI_IO_END (u32) Au1500_PCI_IO_END
+#define PCI_MEM_START (u32) Au1500_PCI_MEM_START
+#define PCI_MEM_END (u32) Au1500_PCI_MEM_END
+
#define PCI_FIRST_DEVFN (0<<3)
#define PCI_LAST_DEVFN (19<<3)
^ permalink raw reply
* Re: Bug in Au1x00 UART or USB drivers for 2.6 kernels?
From: Nathan Eggan @ 2007-12-06 17:11 UTC (permalink / raw)
To: linux-mips mailing list
In-Reply-To: <20071206165100.GP2391@dusktilldawn.nl>
>
> ----------------------------------------
> > Date: Thu, 6 Dec 2007 17:51:00 +0100
> > From: freddy@dusktilldawn.nl
> > To: nathan_eggan@live.com
> > CC: linux-mips@linux-mips.org
> > Subject: Re: Bug in Au1x00 UART or USB drivers for 2.6 kernels?
> >
> > Hi Nathan,
> >
> > On Thu, Dec 06, 2007 at 04:41:23PM +0000, Nathan Eggan wrote:
> > > Can anyone see this?
> >
> > Yes, your message came through clearly.
> >
> > And to reply a little bit more on topic. I had also some strange
> > serial trouble with 2.6.16, but it dissapeared when I used
> > 2.6.23.9. The trouble I had was using 115200bps and for some strange
> > reason bytes would be missing on one of the interfaces. I had no
> > trouble on ttyS2, but ttyS0 would. Strange, but using 2.6.23.9 I
> > did not experience the same problems. I did not investigate the
> > real cause, but just wanted to let you know.
> >
> >
> > --
> > $ cat ~/.signature
> > Freddy Spierenburg <freddy@dusktilldawn.nl> http://freddy.snarl.nl/
> > GnuPG: 0x7941D1E1=C948 5851 26D2 FA5C 39F1 E588 6F17 FD5D 7941 D1E1
> > $ # Please read http://www.ietf.org/rfc/rfc2015.txt before complain!
>
>
> Thanks Freddy! It's good to hear you folks can see this. (I hope you can see this response. M$'s crappy reply has converted all the original text to HTML escaped charactes. :( )
>
> I was reading up on the latest kernel changes you folks are implementing, and I noticed that new IRQ handlers are being coded into 2.6.23 and 2.6.24. So, perhaps that's the resolution that's required. I've been in the process of pulling down the latest kernel source and getting it up and running; so perhaps that'll fix everything for me.
>
> Thanks again.
> Nate
> _________________________________________________________________
> Connect and share in new ways with Windows Live.
> http://www.windowslive.com/connect.html?ocid=TXT_TAGLM_Wave2_newways_112007
_________________________________________________________________
You keep typing, we keep giving. Download Messenger and join the i’m Initiative now.
http://im.live.com/messenger/im/home/?source=TAGLM
^ permalink raw reply
* [PATCH] Fix oprofile configuration breakage
From: Ralf Baechle @ 2007-12-06 16:53 UTC (permalink / raw)
To: Linus Torvalds, Andrew Morton, linux-kernel, linux-mips
The cleanup 09cadedbdc01f1a4bea1f427d4fb4642eaa19da9 broke the oprofile
configuration for MIPS by allowing oprofile support to be built for
kernel models where oprofile doesn't have a chance in hell to work.
Just a dependecy list on a number of architectures is - surprise - broken
and should as per past discussions probably in most considered to be
broken in most cases. So I introduce a dependency for the oprofile
configuration on ARCH_SUPPORTS_OPROFILE.
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
---
Since we're already in -rc4 I try to keep things minimally intrusive and
use ARCH_SUPPORTS_OPROFILE only for MIPS for now instead of touching a
dozen architectures.
arch/mips/Kconfig | 4 ++++
kernel/Kconfig.instrumentation | 2 +-
2 files changed, 5 insertions(+), 1 deletion(-)
diff --git a/arch/mips/Kconfig b/arch/mips/Kconfig
index 455bd1f..c6fc405 100644
--- a/arch/mips/Kconfig
+++ b/arch/mips/Kconfig
@@ -714,6 +714,10 @@ config ARCH_HAS_ILOG2_U64
bool
default n
+config ARCH_SUPPORTS_OPROFILE
+ bool
+ default y if !MIPS_MT_SMTC
+
config GENERIC_FIND_NEXT_BIT
bool
default y
diff --git a/kernel/Kconfig.instrumentation b/kernel/Kconfig.instrumentation
index 2ea1e34..12a9f74 100644
--- a/kernel/Kconfig.instrumentation
+++ b/kernel/Kconfig.instrumentation
@@ -21,7 +21,7 @@ config PROFILING
config OPROFILE
tristate "OProfile system profiling (EXPERIMENTAL)"
depends on PROFILING
- depends on (ALPHA || ARM || BLACKFIN || X86_32 || IA64 || M32R || MIPS || PARISC || PPC || S390 || SUPERH || SPARC || X86_64) && !UML
+ depends on (ARCH_SUPPORTS_OPROFILE || ALPHA || ARM || BLACKFIN || X86_32 || IA64 || M32R || PARISC || PPC || S390 || SUPERH || SPARC || X86_64) && !UML
help
OProfile is a profiling system capable of profiling the
whole system, include the kernel, kernel modules, libraries,
^ permalink raw reply related
* Re: Bug in Au1x00 UART or USB drivers for 2.6 kernels?
From: Freddy Spierenburg @ 2007-12-06 16:51 UTC (permalink / raw)
To: Nathan Eggan; +Cc: linux-mips mailing list
In-Reply-To: <BLU127-W10543A7CB1FFFC1CCC77918A6F0@phx.gbl>
[-- Attachment #1: Type: text/plain, Size: 824 bytes --]
Hi Nathan,
On Thu, Dec 06, 2007 at 04:41:23PM +0000, Nathan Eggan wrote:
> Can anyone see this?
Yes, your message came through clearly.
And to reply a little bit more on topic. I had also some strange
serial trouble with 2.6.16, but it dissapeared when I used
2.6.23.9. The trouble I had was using 115200bps and for some strange
reason bytes would be missing on one of the interfaces. I had no
trouble on ttyS2, but ttyS0 would. Strange, but using 2.6.23.9 I
did not experience the same problems. I did not investigate the
real cause, but just wanted to let you know.
--
$ cat ~/.signature
Freddy Spierenburg <freddy@dusktilldawn.nl> http://freddy.snarl.nl/
GnuPG: 0x7941D1E1=C948 5851 26D2 FA5C 39F1 E588 6F17 FD5D 7941 D1E1
$ # Please read http://www.ietf.org/rfc/rfc2015.txt before complain!
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: Bug in Au1x00 UART or USB drivers for 2.6 kernels?
From: Nathan Eggan @ 2007-12-06 16:41 UTC (permalink / raw)
To: linux-mips mailing list
Can anyone see this? I'm new to Ecartis, so I'm not sure whether any of my messages are getting through.
Plus, my crappy Microsoft Windows Live Hotmail client could be screwing me up. I'm not sure I can force it to just send purely plain text email.
Thanks,
Nate
_________________________________________________________________
You keep typing, we keep giving. Download Messenger and join the i’m Initiative now.
http://im.live.com/messenger/im/home/?source=TAGLM
From freddy@dusktilldawn.nl Thu Dec 6 16:51:06 2007
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 06 Dec 2007 16:51:14 +0000 (GMT)
Received: from tool.snarl.nl ([82.95.241.19]:29706 "EHLO tool.snarl.nl")
by ftp.linux-mips.org with ESMTP id S20026868AbXLFQvG (ORCPT
<rfc822;linux-mips@linux-mips.org>); Thu, 6 Dec 2007 16:51:06 +0000
Received: from localhost (tool.local.snarl.nl [127.0.0.1])
by tool.snarl.nl (Postfix) with ESMTP id E60795DF94;
Thu, 6 Dec 2007 17:51:00 +0100 (CET)
Received: from tool.snarl.nl ([127.0.0.1])
by localhost (tool.local.snarl.nl [127.0.0.1]) (amavisd-new, port 10024)
with LMTP id W8VuGNwoEV1s; Thu, 6 Dec 2007 17:51:00 +0100 (CET)
Received: by tool.snarl.nl (Postfix, from userid 1000)
id 587F35DF6F; Thu, 6 Dec 2007 17:51:00 +0100 (CET)
Date: Thu, 6 Dec 2007 17:51:00 +0100
From: Freddy Spierenburg <freddy@dusktilldawn.nl>
To: Nathan Eggan <nathan_eggan@live.com>
Cc: linux-mips mailing list <linux-mips@linux-mips.org>
Subject: Re: Bug in Au1x00 UART or USB drivers for 2.6 kernels?
Message-ID: <20071206165100.GP2391@dusktilldawn.nl>
References: <BLU127-W10543A7CB1FFFC1CCC77918A6F0@phx.gbl>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha1;
protocol="application/pgp-signature"; boundary="iSEM+tA/SPO43KHM"
Content-Disposition: inline
In-Reply-To: <BLU127-W10543A7CB1FFFC1CCC77918A6F0@phx.gbl>
X-User-Agent-Feature: All mail clients suck. This one just sucks less.
X-GPG-Key: http://snarl.nl/~freddy/keys/freddyPublicKey.gpg
User-Agent: Mutt/1.5.16 (2007-06-11)
Return-Path: <freddy@dusktilldawn.nl>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 17719
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: freddy@dusktilldawn.nl
Precedence: bulk
X-list: linux-mips
--iSEM+tA/SPO43KHM
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
Hi Nathan,
On Thu, Dec 06, 2007 at 04:41:23PM +0000, Nathan Eggan wrote:
> Can anyone see this?
Yes, your message came through clearly.
And to reply a little bit more on topic. I had also some strange
serial trouble with 2.6.16, but it dissapeared when I used
2.6.23.9. The trouble I had was using 115200bps and for some strange
reason bytes would be missing on one of the interfaces. I had no
trouble on ttyS2, but ttyS0 would. Strange, but using 2.6.23.9 I
did not experience the same problems. I did not investigate the
real cause, but just wanted to let you know.
--=20
$ cat ~/.signature
Freddy Spierenburg <freddy@dusktilldawn.nl> http://freddy.snarl.nl/
GnuPG: 0x7941D1E1=3DC948 5851 26D2 FA5C 39F1 E588 6F17 FD5D 7941 D1E1
$ # Please read http://www.ietf.org/rfc/rfc2015.txt before complain!
--iSEM+tA/SPO43KHM
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature
Content-Disposition: inline
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
iD8DBQFHWChzbxf9XXlB0eERAmXpAJwPAy0TD8UbO0O9W3q3dJpYem6btgCfT7Of
dMdSa+9/guIra+nPJKBu7as=
=ris/
-----END PGP SIGNATURE-----
--iSEM+tA/SPO43KHM--
^ permalink raw reply
* Re: Bug in Au1x00 UART or USB drivers for 2.6 kernels?
From: Nathan Eggan @ 2007-12-06 16:41 UTC (permalink / raw)
To: linux-mips mailing list
Can anyone see this? I'm new to Ecartis, so I'm not sure whether any of my messages are getting through.
Plus, my crappy Microsoft Windows Live Hotmail client could be screwing me up. I'm not sure I can force it to just send purely plain text email.
Thanks,
Nate
_________________________________________________________________
You keep typing, we keep giving. Download Messenger and join the i’m Initiative now.
http://im.live.com/messenger/im/home/?source=TAGLM
^ permalink raw reply
* Re: [UPDATED PATCH] IP28 support
From: Ralf Baechle @ 2007-12-06 11:44 UTC (permalink / raw)
To: David Daney; +Cc: peter fuerst, Thomas Bogendoerfer, Kumba, linux-mips
In-Reply-To: <47570C27.9050901@avtrex.com>
On Wed, Dec 05, 2007 at 12:37:59PM -0800, David Daney wrote:
>> There was no answer to .../2006-05/msg01446.html. Perhaps i should just
>> put together an updated patch,
>
> That would be helpful. It would have to be against GCC's svn trunk.
> Currently 4.3 is in regression fix only mode. The earliest the patch could
> appear in an official GCC release would probably be version 4.4
Many distributions have the policy of applying only patches that are
upstream, even if they're upstream only for a newer version. As such
getting them into the FSF 4.4 tree would also be tremendously useful as
an icebreaker.
Ralf
^ permalink raw reply
* Re: [UPDATED PATCH] IP28 support
From: Ralf Baechle @ 2007-12-06 11:41 UTC (permalink / raw)
To: peter fuerst; +Cc: Thomas Bogendoerfer, Kumba, linux-mips
In-Reply-To: <Pine.LNX.4.21.0712051841520.1354@Opal.Peter>
On Wed, Dec 05, 2007 at 08:49:53PM +0100, peter fuerst wrote:
> > there seems to be a missing understanding, why the cache
> > barriers are needed. I guess the patch could be improved
> > by pointing directly to the errata section of the R10k
> > user manual. Or even better copy the text out of the user
> > manual. That should make clear why this patch is needed.
>
> Better copy, i guess. (Assuming copying whole paragraphs is still proper
> citation ;-) Along with the initial patch (.../2006-03.msg00090.html) as
> well as in the last letter so far (.../2006-05/msg01446.html) i pointed
> to the corresponding chapter in the R10k User's Manual and to the entry
> in the NetBSD eMail archive. In the last letter i tried to augment these
> by a summarizing explanation, but it seems i'm not very good at that...
I'm not sure how far "fair use" of the R10000 manual text can be stretched.
But afair Bill Earl (wje@sgi.com) posted a reasonable explanation which
also for the purposes of the gcc manual is much easier to understand.
Ralf
^ permalink raw reply
* [RFC PATCH] Alchemy: Au1210/Au1250 CPU support
From: Manuel Lauss @ 2007-12-06 8:07 UTC (permalink / raw)
To: linux-mips
This patch adds IDs fornew Au1200 variants: Au1210 and Au1250.
They are essentially identical to the Au1200 except for the Au1210
which has a different SoC-ID in the PRId register [bits 31:24].
The Au1250 is a "Au1200 V0.2".
Signed-off-by: Manuel Lauss <mano@roarinelk.homelinux.net>
--- linux-2.6.24-rc4/include/asm-mips/cpu.h 2007-12-04 08:33:33.143002000 +0100
+++ linux-2.6.24-rc4-work/include/asm-mips/cpu.h 2007-12-06 16:28:48.000000000 +0100
@@ -195,8 +195,8 @@ enum cpu_type_enum {
* MIPS32 class processors
*/
CPU_4KC, CPU_4KEC, CPU_4KSC, CPU_24K, CPU_34K, CPU_74K, CPU_AU1000,
- CPU_AU1100, CPU_AU1200, CPU_AU1500, CPU_AU1550, CPU_PR4450,
- CPU_BCM3302, CPU_BCM4710,
+ CPU_AU1100, CPU_AU1200, CPU_AU1210, CPU_AU1250, CPU_AU1500, CPU_AU1550,
+ CPU_PR4450, CPU_BCM3302, CPU_BCM4710,
/*
* MIPS64 class processors
--- linux-2.6.24-rc4/arch/mips/kernel/cpu-probe.c 2007-12-04 08:33:00.793002000 +0100
+++ linux-2.6.24-rc4-work/arch/mips/kernel/cpu-probe.c 2007-12-06 16:27:06.000000000 +0100
@@ -188,6 +188,8 @@ static inline void check_wait(void)
case CPU_AU1500:
case CPU_AU1550:
case CPU_AU1200:
+ case CPU_AU1210:
+ case CPU_AU1250:
if (allow_au1k_wait)
cpu_wait = au1k_wait;
break;
@@ -733,6 +735,11 @@ static inline void cpu_probe_alchemy(str
break;
case 4:
c->cputype = CPU_AU1200;
+ if (2 == (c->processor_id & 0xff))
+ c->cputype = CPU_AU1250;
+ break;
+ case 5:
+ c->cputype = CPU_AU1210;
break;
default:
panic("Unknown Au Core!");
@@ -858,6 +865,8 @@ static __init const char *cpu_to_name(st
case CPU_AU1100: name = "Au1100"; break;
case CPU_AU1550: name = "Au1550"; break;
case CPU_AU1200: name = "Au1200"; break;
+ case CPU_AU1210: name = "Au1210"; break;
+ case CPU_AU1250: name = "Au1250"; break;
case CPU_4KEC: name = "MIPS 4KEc"; break;
case CPU_4KSC: name = "MIPS 4KSc"; break;
case CPU_VR41XX: name = "NEC Vr41xx"; break;
--- linux-2.6.24-rc4/arch/mips/mm/c-r4k.c 2007-12-04 08:33:00.963002000 +0100
+++ linux-2.6.24-rc4-work/arch/mips/mm/c-r4k.c 2007-12-06 16:44:07.000000000 +0100
@@ -989,6 +989,8 @@ static void __init probe_pcache(void)
case CPU_AU1100:
case CPU_AU1550:
case CPU_AU1200:
+ case CPU_AU1210:
+ case CPU_AU1250:
c->icache.flags |= MIPS_CACHE_IC_F_DC;
break;
}
--- linux-2.6.24-rc4/arch/mips/mm/tlbex.c 2007-12-04 08:33:00.983002000 +0100
+++ linux-2.6.24-rc4-work/arch/mips/mm/tlbex.c 2007-12-06 16:44:30.000000000 +0100
@@ -894,6 +894,8 @@ static __init void build_tlb_write_entry
case CPU_AU1500:
case CPU_AU1550:
case CPU_AU1200:
+ case CPU_AU1210:
+ case CPU_AU1250:
case CPU_PR4450:
i_nop(p);
tlbw(p);
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox