* Re: SiByte 1480 & Branch Likely instructions?
From: Maciej W. Rozycki @ 2007-12-10 15:28 UTC (permalink / raw)
To: Ralf Baechle; +Cc: Kaz Kylheku, linux-mips
In-Reply-To: <20071209051450.GA18181@linux-mips.org>
On Sun, 9 Dec 2007, Ralf Baechle wrote:
> > Not really a kernel-related question. I've discovered that GCC 4.1.1
> > (which I'm not using for kernel compiling, but user space) generates
> > branch likely instructions by default, even though the documentation
> > says that their use is off by default for MIPS32 and MIPS64, because
> > they are considered deprecated. They are documented as obsolete for the
> > Broadcom chips I am working with.
>
> Microarchitecture guys love to hate branch likely. But the deprecation is
> a dream. Binary compatibility will always require those instructions to
> continue to exist so the genie is out of the bottle and so I feel very
> certain to predict that a future MIPS 3 specification will contain branch
> likely.
We have been there before -- binary compatibility does not preclude
emulation. And I do not mean keeping the MIPS I toys (as they might be
seen these days) running, but serious products deployed commercially, like
newer VAX implementations that kept full binary compatibility with their
predecessors in the area of the some of the more arcane instructions only
by means of emulating them in the OS.
Maciej
^ permalink raw reply
* Re: is there a standard high res timer patch for mips?
From: Ralf Baechle @ 2007-12-10 15:14 UTC (permalink / raw)
To: Sergei Shtylyov; +Cc: zhuzhenhua, linux-mips
In-Reply-To: <475D2B86.603@ru.mvista.com>
On Mon, Dec 10, 2007 at 03:05:26PM +0300, Sergei Shtylyov wrote:
>> i want to add the high res timer support for my kernel(version
>> 2.6.14),and i found there are some patches:
>> high-res-timers at sourceforge.net/projects/high-res-timers/high-res-timers
>> Jun Sun's patch at
>> http://linux.junsun.net/patches/oss.sgi.com/experimental/<http://linux.junsun.net/patches/oss.sgi.com/experimental/040419.a-cpu-timer.patch>
>> Thomas Gleixner's patch at http://www.tglx.de/projects/hrtimers/
>> is there a standard high res timer patch for mips now?
>> thanks for any hints
>
> Yes, Tohmas' patch is now included into the kernel.
And the upcoming 2.6.24 kernel will be the first to support it.
Ralf
^ permalink raw reply
* Re: [PATCH][MIPS] set up Cobalt's mips_hpt_frequency
From: Ralf Baechle @ 2007-12-10 13:22 UTC (permalink / raw)
To: Sergei Shtylyov; +Cc: Yoichi Yuasa, linux-mips
In-Reply-To: <475D2B21.7050206@ru.mvista.com>
On Mon, Dec 10, 2007 at 03:03:45PM +0300, Sergei Shtylyov wrote:
>> diff -pruN -X mips/Documentation/dontdiff mips-orig/arch/mips/cobalt/time.c mips/arch/mips/cobalt/time.c
>> --- mips-orig/arch/mips/cobalt/time.c 2007-12-06 18:27:02.689043750 +0900
>> +++ mips/arch/mips/cobalt/time.c 2007-12-09 17:13:37.916769000 +0900
>> @@ -27,9 +27,28 @@
>> void __init plat_time_init(void)
>> {
>> + u32 start, end;
>> + int i = HZ / 10;
>> +
>> setup_pit_timer();
>> gt641xx_set_base_clock(GT641XX_BASE_CLOCK);
>> - mips_timer_state = gt641xx_timer0_state;
>> + /*
>> + * MIPS counter frequency is measured between 100msec
>
> s/between/during/
Fixed. The patch which will go to Linus will have the typo fix comment
folded into the actual mips_hpt_frequency patch.
Ralf
^ permalink raw reply
* Re: [PATCH][MIPS] set up Cobalt's mips_hpt_frequency
From: Ralf Baechle @ 2007-12-10 13:15 UTC (permalink / raw)
To: Yoichi Yuasa; +Cc: linux-mips
In-Reply-To: <200712100036.lBA0aRWD016476@po-mbox303.hop.2iij.net>
On Mon, Dec 10, 2007 at 09:36:27AM +0900, Yoichi Yuasa wrote:
> > On Sun, Dec 09, 2007 at 09:22:04PM +0900, Yoichi Yuasa wrote:
> >
> > > Set up Cobalt's mips_hpt_frequency.
> >
> > Queue for 2.6.25. Thanks,
>
> Cobalt cannot boot as this patch doesn't exist.
> Please apply 2.6.24-rc too.
Ah, sorry. Applied.
Ralf
^ permalink raw reply
* Re: is there a standard high res timer patch for mips?
From: Sergei Shtylyov @ 2007-12-10 12:05 UTC (permalink / raw)
To: zhuzhenhua; +Cc: linux-mips
In-Reply-To: <50c9a2250712091718l75455353v1b86851a011eb4fe@mail.gmail.com>
Hello.
zhuzhenhua wrote:
> i want to add the high res timer support for my kernel(version
> 2.6.14),and i found there are some patches:
> high-res-timers at sourceforge.net/projects/high-res-timers/high-res-timers
> Jun Sun's patch at
> http://linux.junsun.net/patches/oss.sgi.com/experimental/<http://linux.junsun.net/patches/oss.sgi.com/experimental/040419.a-cpu-timer.patch>
> Thomas Gleixner's patch at http://www.tglx.de/projects/hrtimers/
> is there a standard high res timer patch for mips now?
> thanks for any hints
Yes, Tohmas' patch is now included into the kernel.
> Best Regards
>
> zzh
WBR, Sergei
^ permalink raw reply
* Re: [PATCH][MIPS] set up Cobalt's mips_hpt_frequency
From: Sergei Shtylyov @ 2007-12-10 12:03 UTC (permalink / raw)
To: Yoichi Yuasa; +Cc: Ralf Baechle, linux-mips
In-Reply-To: <20071209212204.5e50a697.yoichi_yuasa@tripeaks.co.jp>
Hello.
Yoichi Yuasa wrote:
> Set up Cobalt's mips_hpt_frequency.
> Signed-off-by: Yoichi Yuasa <yoichi_yuasa@tripeaks.co.jp>
> diff -pruN -X mips/Documentation/dontdiff mips-orig/arch/mips/cobalt/time.c mips/arch/mips/cobalt/time.c
> --- mips-orig/arch/mips/cobalt/time.c 2007-12-06 18:27:02.689043750 +0900
> +++ mips/arch/mips/cobalt/time.c 2007-12-09 17:13:37.916769000 +0900
> @@ -27,9 +27,28 @@
>
> void __init plat_time_init(void)
> {
> + u32 start, end;
> + int i = HZ / 10;
> +
> setup_pit_timer();
>
> gt641xx_set_base_clock(GT641XX_BASE_CLOCK);
>
> - mips_timer_state = gt641xx_timer0_state;
> + /*
> + * MIPS counter frequency is measured between 100msec
s/between/during/
WBR, Sergei
^ permalink raw reply
* Re: 2.6.24-rc1 does not boot on SGI
From: Giuseppe Sacco @ 2007-12-10 11:58 UTC (permalink / raw)
To: linux-mips
In-Reply-To: <1194281699.4192.3.camel@casa>
I reply to my own message, providing more details, hoping that anyone
here could give a hint or the solution.
During bootup on ip32, since 2.4.24-rc1, the system loop printing a
message about unexpected interrupt #13. (see transcript below.)
I enabled more debug in the kernel, and studied the code. What I
understood is that interrupt #13 from CRIME means that the system should
check on MACEISA for the real interrupt.
The interrupt start appearing just after executing the code
psmouse_init() that enable ps2 drivers for keyboard and mouse. Keyboard
interrupt #49 is enabled first and mouse interrupt #51 is enabled later.
When initialising the keyboard interrupt (it is a MACEISA interrupt),
the interrupt start appearing, so I am pretty sure that interrupt #13 is
related to the keyboard interrupt.
When the system receive interrupt #13, it correctly detect it is a
MACEISA interrupt, and check for mace->perif.ctrl.istat value. The
problem seems to be that this value is zero instead of having bit #9 on
(that would mean, interrupt #49, keyboard).
So, either the interrupt #49 is not correctly enabled, or maceisa
interrupt aren't correctly checked.
Does this description ring a bell to anyone?
Bye,
Giuseppe
Calling initcall 0xffffffff80496ca0: serport_init+0x0/0x48()
initcall 0xffffffff80496ca0: serport_init+0x0/0x48() returned 0.
initcall 0xffffffff80496ca0 ran for 0 msecs: serport_init+0x0/0x48()
Calling initcall 0xffffffff80496ce8: maceps2_init+0x0/0xe0()
initcall 0xffffffff80496ce8: maceps2_init+0x0/0xe0() returned 0.
initcall 0xffffffff80496ce8 ran for 1 msecs: maceps2_init+0x0/0xe0()
Calling initcall 0xffffffff80496dc8: serio_raw_init+0x0/0x18()
initcall 0xffffffff80496dc8: serio_raw_init+0x0/0x18() returned 0.
initcall 0xffffffff80496dc8 ran for 1 msecs: serio_raw_init+0x0/0x18()
Calling initcall 0xffffffff80496f40: mousedev_init+0x0/0xd0()
mice: PS/2 mouse device common for all mice
initcall 0xffffffff80496f40: mousedev_init+0x0/0xd0() returned 0.
initcall 0xffffffff80496f40 ran for 16 msecs: mousedev_init+0x0/0xd0()
Calling initcall 0xffffffff80497010: atkbd_init+0x0/0x18()
initcall 0xffffffff80497010: atkbd_init+0x0/0x18() returned 0.
initcall 0xffffffff80497010 ran for 0 msecs: atkbd_init+0x0/0x18()
Calling initcall 0xffffffff80497028: psmouse_init+0x0/0x90()
maceisa enable: 49
crime_int 00000020 enabled
*irq 13, crime_int=00002000, crime_mask=003003a0, mace_int=00000000*
irq 13, desc: ffffffff80448390, depth: 1, count: 0, unhandled: 0
->handle_irq(): ffffffff80065eb0, handle_bad_irq+0x0/0x2c0
->chip(): ffffffff8043e320, 0xffffffff8043e320
->action(): 0000000000000000
IRQ_DISABLED set
^ permalink raw reply
* Re: [UPDATED PATCH] IP28 support
From: Richard Sandiford @ 2007-12-10 11:00 UTC (permalink / raw)
To: Ralf Baechle; +Cc: Thomas Bogendoerfer, Kumba, linux-mips
In-Reply-To: <20071209043821.GB13729@linux-mips.org>
Ralf Baechle <ralf@linux-mips.org> writes:
>> Then there's the language-lawyerly code I gave to Peter on gcc-patches@:
>>
>> void foo (int x)
>> {
>> int array[1];
>> if (x)
>> bar (array[0x1fff]);
>> }
>>
>> This function is valid if x is never true, so we cannot assume that all
>> accesses off the stack and frame pointers are actually in-frame. You're
>> assuming either (i) the kernel doesn't use code like that or (ii) that
>> "garbage" addresses in the range [$sp - 0x8000, $sp + 0x7fff] will not
>> trigger the problem. I imagine both are reasonable assumptions, and I'm
>> perfectly happy for us to make them. But they're the kind of assumption
>> we need to state explicitly.
>
> Interesting test case. I've been thinking about it myself but in the end
> decieded to believe Peter's analysis since he's banged the head for longer
> to the wall about this problem that I have ;-) I'm quite but not absolutely
> certain that this case cannot happen for realworld code, so I'd rather
> err on the side of caution.
>
> Peter & Thomas - we could make the stack thing bullet proof by vmallocing
> stacks and ensuring a sufficient virtual address gap exists around the stack
> such that the stack is the only addressable thing in the range of
> $sp +0x7fff / -0x8000?
FWIW, my first cut at the option restrictions were based on what
the patch exempts (and doesn't exempt). We could instead get gcc
to only exempt accesses that it can prove are either to the current
function's stack frame or to its stack arguments. I.e. rather than
consider every $sp-based access to be safe, we'd instead do some
bounds checking on the value. (We could also use MEM_ATTRS to
pick up cases where a stack variable is acceesed via something
other than the stack or frame pointers, as happens for large frames.)
>> Peter's patch also treated accesses to constant integer and symbolic
>> addresses as safe. Again, this involves making assumptions about how
>> constant integer and symbolic addresses are used, and this is a much
>> less obvious assumption than the stack one.
>
> The latter assumption is also needed for -msym32 kernels, so it's well
> proven to be valid. The former hold, too.
>
>> Again, I understand that
>> it's a reasonable assumption to make in the linux context, but it's one
>> we need to pin down. E.g. there must be no run-time guarding of
>> target-specific constant integer IO-mapped addresses in cases where
>> those addresses might trigger the problem on other systems that the
>> same kernel image supports.
>
> In case of a hypothetic multi-platform kernel of which at least one needs
> the R10000 workarounds, all code would be uniformly compiled with the
> magic -mr10k-cache-barrier option and all source level workaround would
> be enabled.
Hmm. This probably shows I am misunderstanding the problem, but I was
thinking about the IO-mapped case. I thought one of the problems was
that if you had a cached speculative load or store to an access-sensitive
IO-mapped address, the IO-mapped device might "see" that access even if it
doesn't take place. Could you not have a situation where a KSEG0 or
XKSEG0 access is access-sensitive on one machine and not another?
The patch won't insert countermeasures before symbolic and constant
addresses, because it believes all such addresses to be safe.
I'm also a little worried that the compiler is free to make up accesses
that didn't exist in the original program, provided that those accesses
are never actually performed in cases where they'd be wrong. So how about:
-mr10k-cache-barrier=load-store
Insert a cache barrier at the beginning of any sequentially-executed
series of instructions that contains a load or store. For the purposes
of this option, GCC can ignore loads and stores that it can prove
are an in-range access to:
(a) the current function's stack frame;
(b) an incoming stack argument;
(b) an object with a link-time-constant address; or
(c) a block of uncached memory
It can also ignore sequences that are always immediately preceded by
an untaken branch-likely instruction.
Here, a ``sequentially-executed series'' is one in which calls,
jumps and branches occur only as the last instruction.
-mr10k-cache-barrier=store
Like -mr10k-cache-barrier=load-store, but ignore all loads.
-mr10k-cache-barrier=none
...
Richard
^ permalink raw reply
* [PATCH][MIPS] Enable SSB_DRIVER_EXTIF on BCM47XX platform
From: Aurelien Jarno @ 2007-12-10 10:22 UTC (permalink / raw)
To: Ralf Baechle; +Cc: linux-mips
Hi,
arch/mips/bcm47xx/gpio.c uses ssb_extif_* functions. The patch below
makes sure those functions are available on the BCM47XX platform.
Aurelien
Signed-off-by: Aurelien Jarno <aurelien@aurel32.net>
diff --git a/arch/mips/Kconfig b/arch/mips/Kconfig
index c6fc405..e46b076 100644
--- a/arch/mips/Kconfig
+++ b/arch/mips/Kconfig
@@ -59,6 +59,7 @@ config BCM47XX
select SYS_SUPPORTS_LITTLE_ENDIAN
select SSB
select SSB_DRIVER_MIPS
+ select SSB_DRIVER_EXTIF
select GENERIC_GPIO
select SYS_HAS_EARLY_PRINTK
select CFE
--
.''`. Aurelien Jarno | GPG: 1024D/F1BCDB73
: :' : Debian developer | Electrical Engineer
`. `' aurel32@debian.org | aurelien@aurel32.net
`- people.debian.org/~aurel32 | www.aurel32.net
^ permalink raw reply related
* SSB Bus: Need advice representing 2 devices in a core (BCM5354 USB2.0 core)
From: Steve Brown @ 2007-12-10 1:55 UTC (permalink / raw)
To: linux-mips
I'm posting to this list because I think this is basically a ssb bus
issue. If it doesn't belong here, where should I go?
The USB 2.0 core in the BCM5354 is both a OHCI & EHCI device. I now have
a OHCI & EHCI driver. The former is essentially the current ohci-ssb.c
w/ a dma mask fix and the latter I derived from ohci-ssb and ehci-pci.
Either one, but not both, will attach to the USB 2.0 core and mostly work.
1. Multiple devices per core
The ssb bus code seems to expect only one device per core. I modified
drivers/ssb/scan.c to add an additional identical device in the case of
the USB 2.0 core. However, once a driver binds to one device, the other
seems to no longer be available either. When the second driver loads,
ssb_bus_match never sees the second device. I haven't figured out what's
happening yet.
I also considered modifying drivers/ssb/scan.c to add a phony additional
core/device for SSB_DEV_USB20_HOST and then add that phony core to the
OHCI device list. But, this seems really ugly.
2. Avoiding multiple core initializations
I also need a way to determine if the core is already enabled, as I
can't initialize it more than once. The initialization gets done in the
probe code in ohci-ssb and ehci-ssb. The first one loaded does that and
the second driver needs to skip the initialization. Does the following
look like a safe test for a reset core?
(ssb_read32(dev, SSB_TMSLOW) & SSB_TMSLOW_RESET)
As ssb_enable always first resets the core, maybe this test isn't always
reliable. If it isn't, should I just add a flag to the ssb_device
structure that follows ssb_enable/ssb_disable?
Any suggestions are appreciated. As I'm probably less than qualified to
be doing this, I'll accept that as advice as well.
Steve
^ permalink raw reply
* is there a standard high res timer patch for mips?
From: zhuzhenhua @ 2007-12-10 1:18 UTC (permalink / raw)
To: linux-mips
[-- Attachment #1: Type: text/plain, Size: 537 bytes --]
hello, all
i want to add the high res timer support for my kernel(version
2.6.14),and i found there are some patches:
high-res-timers at sourceforge.net/projects/high-res-timers/high-res-timers
Jun Sun's patch at
http://linux.junsun.net/patches/oss.sgi.com/experimental/<http://linux.junsun.net/patches/oss.sgi.com/experimental/040419.a-cpu-timer.patch>
Thomas Gleixner's patch at http://www.tglx.de/projects/hrtimers/
is there a standard high res timer patch for mips now?
thanks for any hints
Best Regards
zzh
[-- Attachment #2: Type: text/html, Size: 930 bytes --]
^ permalink raw reply
* Re: [PATCH][MIPS] set up Cobalt's mips_hpt_frequency
From: Yoichi Yuasa @ 2007-12-10 0:36 UTC (permalink / raw)
To: Ralf Baechle; +Cc: yoichi_yuasa, linux-mips
In-Reply-To: <20071209191039.GB32724@linux-mips.org>
On Sun, 9 Dec 2007 19:10:39 +0000
Ralf Baechle <ralf@linux-mips.org> wrote:
> On Sun, Dec 09, 2007 at 09:22:04PM +0900, Yoichi Yuasa wrote:
>
> > Set up Cobalt's mips_hpt_frequency.
>
> Queue for 2.6.25. Thanks,
Cobalt cannot boot as this patch doesn't exist.
Please apply 2.6.24-rc too.
Thanks,
Yoichi
^ permalink raw reply
* Re: [PATCH][MIPS] set up Cobalt's mips_hpt_frequency
From: Ralf Baechle @ 2007-12-09 19:10 UTC (permalink / raw)
To: Yoichi Yuasa; +Cc: linux-mips
In-Reply-To: <20071209212204.5e50a697.yoichi_yuasa@tripeaks.co.jp>
On Sun, Dec 09, 2007 at 09:22:04PM +0900, Yoichi Yuasa wrote:
> Set up Cobalt's mips_hpt_frequency.
Queue for 2.6.25. Thanks,
Ralf
^ permalink raw reply
* Re: [PATCH][MIPS] remove mips_timer_state()
From: Ralf Baechle @ 2007-12-09 19:10 UTC (permalink / raw)
To: Yoichi Yuasa; +Cc: linux-mips
In-Reply-To: <20071209211936.05b97163.yoichi_yuasa@tripeaks.co.jp>
On Sun, Dec 09, 2007 at 09:19:36PM +0900, Yoichi Yuasa wrote:
> Remove mips_timer_state().
> It is not used at all.
>
> Signed-off-by: Yoichi Yuasa <yoichi_yuasa@tripeaks.co.jp>
Queued for 2.6.25.
Thanks,
Ralf
^ permalink raw reply
* Re: [SPAM] Re: Donation of an Indigo 2 R4K@250
From: Martin Michlmayr @ 2007-12-09 16:45 UTC (permalink / raw)
To: Markus Gothe; +Cc: linux-mips
In-Reply-To: <47385B75.2010700@27m.se>
* Markus Gothe <markus.gothe@27m.se> [2007-11-12 14:56]:
> Which graphics option? A 'hinv -v' would be appreciated.
hinv:
CPU: MIPS R4400 Processor Chip Revision: 6.0
FPU: MIPS R4000 Floating Point Coprocessor Revision: 0.0
1 250 MHZ IP22 Processor
Main memory size: 128 Mbytes
Secondary unified instruction/data cache size: 2 Mbytes on Processor 0
Instruction cache size: 16 Kbytes
Data cache size: 16 Kbytes
Integral SCSI controller 0: Version WD33C93B, revision D
Disk drive: unit 1 on SCSI controller 0
Integral SCSI controller 1: Version WD33C93B, revision D
On-board serial ports: 2
On-board bi-directional parallel port
Graphics board: GU1-Extreme
Integral Ethernet: ec0, version 1
Iris Audio Processor: version A2 revision 1.1.0
EISA bus: adapter 0
gfxinfo:
--
Graphics board 0 is "GR2" graphics.
Managed (":0.0") 1280x1024
8 GEs, 2 REs, 24 bitplanes, 4 auxplanes, 4 cidplanes, Z-buffer
GR2 revision 6, VB2.0
HQ2.1 rev A, GE7 rev B, RE3.1 rev A, VC1 rev B, MC rev C
unknown, assuming 19" monitor
--
Martin Michlmayr
http://www.cyrius.com/
^ permalink raw reply
* [PATCH][MIPS] set up Cobalt's mips_hpt_frequency
From: Yoichi Yuasa @ 2007-12-09 12:22 UTC (permalink / raw)
To: Ralf Baechle; +Cc: yoichi_yuasa, linux-mips
Set up Cobalt's mips_hpt_frequency.
Signed-off-by: Yoichi Yuasa <yoichi_yuasa@tripeaks.co.jp>
diff -pruN -X mips/Documentation/dontdiff mips-orig/arch/mips/cobalt/time.c mips/arch/mips/cobalt/time.c
--- mips-orig/arch/mips/cobalt/time.c 2007-12-06 18:27:02.689043750 +0900
+++ mips/arch/mips/cobalt/time.c 2007-12-09 17:13:37.916769000 +0900
@@ -27,9 +27,28 @@
void __init plat_time_init(void)
{
+ u32 start, end;
+ int i = HZ / 10;
+
setup_pit_timer();
gt641xx_set_base_clock(GT641XX_BASE_CLOCK);
- mips_timer_state = gt641xx_timer0_state;
+ /*
+ * MIPS counter frequency is measured between 100msec
+ * using GT64111 timer0.
+ */
+ while (!gt641xx_timer0_state())
+ ;
+
+ start = read_c0_count();
+
+ while (i--)
+ while (!gt641xx_timer0_state())
+ ;
+
+ end = read_c0_count();
+
+ mips_hpt_frequency = (end - start) * 10;
+ printk(KERN_INFO "MIPS counter frequency %dHz\n", mips_hpt_frequency);
}
^ permalink raw reply
* [PATCH][MIPS] remove mips_timer_state()
From: Yoichi Yuasa @ 2007-12-09 12:19 UTC (permalink / raw)
To: Ralf Baechle; +Cc: yoichi_yuasa, linux-mips
Remove mips_timer_state().
It is not used at all.
Signed-off-by: Yoichi Yuasa <yoichi_yuasa@tripeaks.co.jp>
diff -pruN -X mips/Documentation/dontdiff mips-orig/arch/mips/dec/time.c mips/arch/mips/dec/time.c
--- mips-orig/arch/mips/dec/time.c 2007-12-06 18:27:03.461092000 +0900
+++ mips/arch/mips/dec/time.c 2007-12-09 20:55:08.231255000 +0900
@@ -161,7 +161,6 @@ static cycle_t dec_ioasic_hpt_read(void)
void __init plat_time_init(void)
{
- mips_timer_state = dec_timer_state;
mips_timer_ack = dec_timer_ack;
if (!cpu_has_counter && IOASIC)
diff -pruN -X mips/Documentation/dontdiff mips-orig/arch/mips/kernel/time.c mips/arch/mips/kernel/time.c
--- mips-orig/arch/mips/kernel/time.c 2007-12-06 18:27:04.629165000 +0900
+++ mips/arch/mips/kernel/time.c 2007-12-09 20:52:04.111748250 +0900
@@ -50,8 +50,6 @@ int update_persistent_clock(struct times
return rtc_mips_set_mmss(now.tv_sec);
}
-int (*mips_timer_state)(void);
-
int null_perf_irq(void)
{
return 0;
diff -pruN -X mips/Documentation/dontdiff mips-orig/include/asm-mips/time.h mips/include/asm-mips/time.h
--- mips-orig/include/asm-mips/time.h 2007-12-06 18:30:02.548284250 +0900
+++ mips/include/asm-mips/time.h 2007-12-09 20:54:28.116748000 +0900
@@ -31,20 +31,13 @@ extern int rtc_mips_set_time(unsigned lo
extern int rtc_mips_set_mmss(unsigned long);
/*
- * Timer interrupt functions.
- * mips_timer_state is needed for high precision timer calibration.
- */
-extern int (*mips_timer_state)(void);
-
-/*
* board specific routines required by time_init().
*/
extern void plat_time_init(void);
/*
* mips_hpt_frequency - must be set if you intend to use an R4k-compatible
- * counter as a timer interrupt source; otherwise it can be set up
- * automagically with an aid of mips_timer_state.
+ * counter as a timer interrupt source.
*/
extern unsigned int mips_hpt_frequency;
^ permalink raw reply
* Re: SiByte 1480 & Branch Likely instructions?
From: Ralf Baechle @ 2007-12-09 5:26 UTC (permalink / raw)
To: Kaz Kylheku; +Cc: linux-mips
In-Reply-To: <DDFD17CC94A9BD49A82147DDF7D545C5590D6B@exchange.ZeugmaSystems.local>
On Fri, Dec 07, 2007 at 03:39:57PM -0800, Kaz Kylheku wrote:
> > Not really a kernel-related question. I've discovered that GCC 4.1.1
> > (which I'm not using for kernel compiling, but user space) generates
> > branch likely instructions by default, even though the documentation
> > says that their use is off by default for MIPS32 and MIPS64, because
>
> That's because the compiler is not configured correctly. The default CPU
> string "from-abi" ends up being used, and so the target ISA is MIPS III.
>
> > In parallel with writing some tests, I thought I would ask whether
> > anyone happens know whether or not these instructions are known to
> > actually work correctly on the SB1480 silicon (and perhaps any
> > additional details, like what revisions, etc)?
>
> A basic sanity test does find bnezl working.
>
> #include <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;
> }
That's a very basic test and it'd be very unlikely for the CPU to fail
such a simple test.
But think of scenarios like a load in the delay slot of a branch likely
where the load instruction is on a different page than the branch and a
tlb exception is getting caused. There are many other special cases
which might be improperly implemented.
But honestly - branch likely instructions were introduced into the MIPS
architecture by the MIPS II R6000 in '89. And the SB1 core is 2000
vintage so I'd assume by now have figured out how to get it right. And
branch likely is used in existing binaries. So I'd be surprised if it
was broken.
Ralf
^ permalink raw reply
* Re: SiByte 1480 & Branch Likely instructions?
From: Ralf Baechle @ 2007-12-09 5:14 UTC (permalink / raw)
To: Kaz Kylheku; +Cc: linux-mips
In-Reply-To: <DDFD17CC94A9BD49A82147DDF7D545C5590CF0@exchange.ZeugmaSystems.local>
On Fri, Dec 07, 2007 at 01:54:30PM -0800, Kaz Kylheku wrote:
> Not really a kernel-related question. I've discovered that GCC 4.1.1
> (which I'm not using for kernel compiling, but user space) generates
> branch likely instructions by default, even though the documentation
> says that their use is off by default for MIPS32 and MIPS64, because
> they are considered deprecated. They are documented as obsolete for the
> Broadcom chips I am working with.
Microarchitecture guys love to hate branch likely. But the deprecation is
a dream. Binary compatibility will always require those instructions to
continue to exist so the genie is out of the bottle and so I feel very
certain to predict that a future MIPS 3 specification will contain branch
likely.
Afair the SB1 core has a full blown implementation of branch likely -
unlike the R10000 for example where implementors were lazy that is the
branch predictor predicts branch likely instructions as always taken.
So on the R10000 branch likely is only good as loop closure instruction
while on SB1 it should actually do a decent job wherever it can be
scheduled apropriately.
> I'm investigating a software anomaly which looks like might be caused by
> failure to annul the delay slot of a branch-likely in the fall-through
> case.
>
> In parallel with writing some tests, I thought I would ask whether
> anyone happens know whether or not these instructions are known to
> actually work correctly on the SB1480 silicon (and perhaps any
> additional details, like what revisions, etc)?
I have no indications of the contrary.
Ralf
^ permalink raw reply
* Re: [UPDATED PATCH] IP28 support
From: Ralf Baechle @ 2007-12-09 4:38 UTC (permalink / raw)
To: Thomas Bogendoerfer, Kumba, linux-mips, rsandifo
In-Reply-To: <871w9x6j9g.fsf@firetop.home>
On Sat, Dec 08, 2007 at 08:09:31PM +0000, Richard Sandiford wrote:
> Ralf Baechle <ralf@linux-mips.org> writes:
> > On Sat, Dec 08, 2007 at 05:52:06PM +0000, Richard Sandiford wrote:
> >> I tried to piece together (b) by asking questions in the reviews,
> >> but it would be great to have a single explanation.
> >>
> >> The idea behind (c) is simple, of course: we insert a cache barrier
> >> before the potentially-problematic stores (and, for certain
> >> configurations, loads, although the original gcc patch had the
> >> associated macro hard-wired to false). The key is explaining how,
> >> from a compiler internals viewpoint, we decide what is "potentially-
> >> problematic". This ties in with the assumptions for (b).
> >
> > The principle for the compiler is a store is problematic unless proven
> > otherwise. A speculative store relative to the stack pointer, frame
> > pointer or global pointer for example is harmless.
>
> Right. But just so we're on the same page (and I think we probably are),
> my point was that those rules aren't intrinsically obvious. They're
> based on assumptions about how the code is written. For example,
> it assumes there's no DMAing into stack variables. Maybe obvious,
> but I think it needs to be stated explicitly.
Can't harm to be explicit. Linux forbids DMA to the stack. In that past
DMA to the stack has caused alot of grief for Linux ports on some
architectures.
> Then there's the language-lawyerly code I gave to Peter on gcc-patches@:
>
> void foo (int x)
> {
> int array[1];
> if (x)
> bar (array[0x1fff]);
> }
>
> This function is valid if x is never true, so we cannot assume that all
> accesses off the stack and frame pointers are actually in-frame. You're
> assuming either (i) the kernel doesn't use code like that or (ii) that
> "garbage" addresses in the range [$sp - 0x8000, $sp + 0x7fff] will not
> trigger the problem. I imagine both are reasonable assumptions, and I'm
> perfectly happy for us to make them. But they're the kind of assumption
> we need to state explicitly.
Interesting test case. I've been thinking about it myself but in the end
decieded to believe Peter's analysis since he's banged the head for longer
to the wall about this problem that I have ;-) I'm quite but not absolutely
certain that this case cannot happen for realworld code, so I'd rather
err on the side of caution.
Peter & Thomas - we could make the stack thing bullet proof by vmallocing
stacks and ensuring a sufficient virtual address gap exists around the stack
such that the stack is the only addressable thing in the range of
$sp +0x7fff / -0x8000?
A -mr10k-cache-barrier=sp-is-safe option?
> Peter's patch also treated accesses to constant integer and symbolic
> addresses as safe. Again, this involves making assumptions about how
> constant integer and symbolic addresses are used, and this is a much
> less obvious assumption than the stack one.
The latter assumption is also needed for -msym32 kernels, so it's well
proven to be valid. The former hold, too.
> Again, I understand that
> it's a reasonable assumption to make in the linux context, but it's one
> we need to pin down. E.g. there must be no run-time guarding of
> target-specific constant integer IO-mapped addresses in cases where
> those addresses might trigger the problem on other systems that the
> same kernel image supports.
In case of a hypothetic multi-platform kernel of which at least one needs
the R10000 workarounds, all code would be uniformly compiled with the
magic -mr10k-cache-barrier option and all source level workaround would
be enabled.
> Despite appearances, I'm not trying to be awkward here ;) I just think
> the assumptions are too loosely-defined at the moment (or at least too
> scattered around). It would be nice to have some self-contained
> description, targetted specifically at gcc and linux, that contains
> anything a gcc hacker or user needs to know about the gcc patch.
Your help is certainly appreciated and trying to find the potencial holes
here will only help.
Ralf
^ permalink raw reply
* Re: [UPDATED PATCH] IP28 support
From: Richard Sandiford @ 2007-12-08 23:24 UTC (permalink / raw)
To: post; +Cc: Ralf Baechle, Thomas Bogendoerfer, Kumba, linux-mips
In-Reply-To: <Pine.LNX.4.58.0712082217370.14975@Indigo2.Peter>
peter fuerst <post@pfrst.de> writes:
> could text like this help to pin the assumptions down (from
> "http://gcc.gnu.org/ml/gcc-patches/2006-05/msg01446.html") ?
>
> "...
> What cases of $N can be exempted from this measure?
> - Stack-addresses and constant (static) addresses ("sd $M,symbol+n") will not
> be used for DMA, since DMA-buffers are allocated at runtime.
> - Uncached accesses will not be done speculatively, but they fall under the
> "constant"-case already or will not be recognized at compile-time.
>
> Besides the DMA-problem, depending on the mis-speculation path (up to four
> branches deep), one of the frequently reused multi-purpose registers $N
> will contain some "random" value, which may be a legal but invalid kernel-
> address (say a800000061234567), reaching the memory-controller...
> However, there are cases where a register $N's content is well defined, no
> matter what (mis-)speculation path took us to this instruction:
> - The stack-pointer points to the stack from kernel-initializtion on.
> - Constant addresses ("symbol+n") are well defined "per se".
> (Luckily, legal-but-invalid doesn't occur in user mode, where no cache-
> barriers can be used. There we get either an address-error or a TLB-miss,
> leaving memory/bus untouched.)
> ..."
Well, the explanation of the exceptions doesn't really address the
corner cases I was trying to draw attention to in the message you
replied to. What about top of the stack + X? Do we guarantee that
the code will never cause the compiler to generate a store to such
an address, even with an always-false guard? Or do we guarantee
that stores and loads to [top-of-stack, top-of-stack + 0x7fff] can
be speculated safely? Do we guarantee that every store and load to
a cached constant address in the kernel image will not result in
a harmful IO access on any target that the image supports?
Perhaps we should just turn this around slightly and instead say:
what must the compiler do, and when must it do it? The reasons why
aren't that important from the compiler's perspective. So if we can
just phrase it as:
-mr10k-cache-barrier=load-store
Insert a cache barrier at the beginning of any sequentially-executed
series of instructions that contains a load or store. For the purposes
of this option, GCC can ignore loads and stores that it can prove:
(a) access a region in the range [-0x8000 + bottom of stack frame,
0x7fff + top of stack frame]; or
(b) access a link-time-constant address.
Here, a ``sequentially-executed series'' is one in which calls,
jumps and branches occur only as the last instruction.
-mr10k-cache-barrier=store
Like -mr10k-cache-barrier=load-store, but ignore all loads.
-mr10k-cache-barrier=none
...
And if you guys are willing to make sure that's safe, and change
the kernel whenever you find instances that it isn't safe, then
that should be enough. (Bear in mind that there's ongoing work
to do link-time optimisation in gcc, so translation-unit separation
is no real guarantee.)
Richard
^ permalink raw reply
* Re: [UPDATED PATCH] IP28 support
From: peter fuerst @ 2007-12-08 21:25 UTC (permalink / raw)
To: Richard Sandiford; +Cc: Ralf Baechle, Thomas Bogendoerfer, Kumba, linux-mips
In-Reply-To: <871w9x6j9g.fsf@firetop.home>
Hi!
could text like this help to pin the assumptions down (from
"http://gcc.gnu.org/ml/gcc-patches/2006-05/msg01446.html") ?
"...
What cases of $N can be exempted from this measure?
- Stack-addresses and constant (static) addresses ("sd $M,symbol+n") will not
be used for DMA, since DMA-buffers are allocated at runtime.
- Uncached accesses will not be done speculatively, but they fall under the
"constant"-case already or will not be recognized at compile-time.
Besides the DMA-problem, depending on the mis-speculation path (up to four
branches deep), one of the frequently reused multi-purpose registers $N
will contain some "random" value, which may be a legal but invalid kernel-
address (say a800000061234567), reaching the memory-controller...
However, there are cases where a register $N's content is well defined, no
matter what (mis-)speculation path took us to this instruction:
- The stack-pointer points to the stack from kernel-initializtion on.
- Constant addresses ("symbol+n") are well defined "per se".
(Luckily, legal-but-invalid doesn't occur in user mode, where no cache-
barriers can be used. There we get either an address-error or a TLB-miss,
leaving memory/bus untouched.)
..."
kind regards
peter
On Sat, 8 Dec 2007, Richard Sandiford wrote:
> Date: Sat, 08 Dec 2007 20:09:31 +0000
> From: Richard Sandiford <rsandifo@nildram.co.uk>
> To: Ralf Baechle <ralf@linux-mips.org>
> Cc: Thomas Bogendoerfer <tsbogend@alpha.franken.de>, Kumba <kumba@gentoo.org>,
> linux-mips@linux-mips.org
> Subject: Re: [UPDATED PATCH] IP28 support
>
> Ralf Baechle <ralf@linux-mips.org> writes:
> > On Sat, Dec 08, 2007 at 05:52:06PM +0000, Richard Sandiford wrote:
> >> I tried to piece together (b) by asking questions in the reviews,
> >> but it would be great to have a single explanation.
> >>
> >> The idea behind (c) is simple, of course: we insert a cache barrier
> >> before the potentially-problematic stores (and, for certain
> >> configurations, loads, although the original gcc patch had the
> >> associated macro hard-wired to false). The key is explaining how,
> >> from a compiler internals viewpoint, we decide what is "potentially-
> >> problematic". This ties in with the assumptions for (b).
> >
> > The principle for the compiler is a store is problematic unless proven
> > otherwise. A speculative store relative to the stack pointer, frame
> > pointer or global pointer for example is harmless.
>
> Right. But just so we're on the same page (and I think we probably are),
> my point was that those rules aren't intrinsically obvious. They're
> based on assumptions about how the code is written. For example,
> it assumes there's no DMAing into stack variables. Maybe obvious,
> but I think it needs to be stated explicitly. Then there's the
> language-lawyerly code I gave to Peter on gcc-patches@:
>
> void foo (int x)
> {
> int array[1];
> if (x)
> bar (array[0x1fff]);
> }
>
> This function is valid if x is never true, so we cannot assume that all
> accesses off the stack and frame pointers are actually in-frame. You're
> assuming either (i) the kernel doesn't use code like that or (ii) that
> "garbage" addresses in the range [$sp - 0x8000, $sp + 0x7fff] will not
> trigger the problem. I imagine both are reasonable assumptions, and I'm
> perfectly happy for us to make them. But they're the kind of assumption
> we need to state explicitly.
>
> Peter's patch also treated accesses to constant integer and symbolic
> addresses as safe. Again, this involves making assumptions about how
> constant integer and symbolic addresses are used, and this is a much
> less obvious assumption than the stack one. Again, I understand that
> it's a reasonable assumption to make in the linux context, but it's one
> we need to pin down. E.g. there must be no run-time guarding of
> target-specific constant integer IO-mapped addresses in cases where
> those addresses might trigger the problem on other systems that the
> same kernel image supports.
>
> Despite appearances, I'm not trying to be awkward here ;) I just think
> the assumptions are too loosely-defined at the moment (or at least too
> scattered around). It would be nice to have some self-contained
> description, targetted specifically at gcc and linux, that contains
> anything a gcc hacker or user needs to know about the gcc patch.
>
> Richard
>
>
>
^ permalink raw reply
* Re: [UPDATED PATCH] IP28 support
From: Richard Sandiford @ 2007-12-08 20:09 UTC (permalink / raw)
To: Ralf Baechle; +Cc: Thomas Bogendoerfer, Kumba, linux-mips
In-Reply-To: <20071208192405.GA29208@linux-mips.org>
Ralf Baechle <ralf@linux-mips.org> writes:
> On Sat, Dec 08, 2007 at 05:52:06PM +0000, Richard Sandiford wrote:
>> I tried to piece together (b) by asking questions in the reviews,
>> but it would be great to have a single explanation.
>>
>> The idea behind (c) is simple, of course: we insert a cache barrier
>> before the potentially-problematic stores (and, for certain
>> configurations, loads, although the original gcc patch had the
>> associated macro hard-wired to false). The key is explaining how,
>> from a compiler internals viewpoint, we decide what is "potentially-
>> problematic". This ties in with the assumptions for (b).
>
> The principle for the compiler is a store is problematic unless proven
> otherwise. A speculative store relative to the stack pointer, frame
> pointer or global pointer for example is harmless.
Right. But just so we're on the same page (and I think we probably are),
my point was that those rules aren't intrinsically obvious. They're
based on assumptions about how the code is written. For example,
it assumes there's no DMAing into stack variables. Maybe obvious,
but I think it needs to be stated explicitly. Then there's the
language-lawyerly code I gave to Peter on gcc-patches@:
void foo (int x)
{
int array[1];
if (x)
bar (array[0x1fff]);
}
This function is valid if x is never true, so we cannot assume that all
accesses off the stack and frame pointers are actually in-frame. You're
assuming either (i) the kernel doesn't use code like that or (ii) that
"garbage" addresses in the range [$sp - 0x8000, $sp + 0x7fff] will not
trigger the problem. I imagine both are reasonable assumptions, and I'm
perfectly happy for us to make them. But they're the kind of assumption
we need to state explicitly.
Peter's patch also treated accesses to constant integer and symbolic
addresses as safe. Again, this involves making assumptions about how
constant integer and symbolic addresses are used, and this is a much
less obvious assumption than the stack one. Again, I understand that
it's a reasonable assumption to make in the linux context, but it's one
we need to pin down. E.g. there must be no run-time guarding of
target-specific constant integer IO-mapped addresses in cases where
those addresses might trigger the problem on other systems that the
same kernel image supports.
Despite appearances, I'm not trying to be awkward here ;) I just think
the assumptions are too loosely-defined at the moment (or at least too
scattered around). It would be nice to have some self-contained
description, targetted specifically at gcc and linux, that contains
anything a gcc hacker or user needs to know about the gcc patch.
Richard
^ permalink raw reply
* Re: [UPDATED PATCH] IP28 support
From: Ralf Baechle @ 2007-12-08 19:24 UTC (permalink / raw)
To: Thomas Bogendoerfer, Kumba, linux-mips, rsandifo
In-Reply-To: <87ejdx6pmh.fsf@firetop.home>
On Sat, Dec 08, 2007 at 05:52:06PM +0000, Richard Sandiford wrote:
> tsbogend@alpha.franken.de (Thomas Bogendoerfer) writes:
> > On Wed, Dec 05, 2007 at 01:16:13AM -0500, Kumba wrote:
> >> I've been out of it lately -- did the gcc side of things ever make it in,
> >> or do we need to go push on that some more?
> >
> > We need push on that. Looking at
> >
> > http://gcc.gnu.org/ml/gcc-patches/2006-04/msg00291.html
> >
> > there seems to be a missing understanding, why the cache
> > barriers are needed.
>
> Heh. Quite probably. Which bit of my message don't you agree with?
>
> FWIW, I was going off the original message as posted here:
>
> http://gcc.gnu.org/ml/gcc-patches/2006-03/msg00090.html
>
> The explanation of the chosen workaround seemed to be left to this bit
> of http://mail-index.netbsd.org/port-sgimips/2000/06/29/0006.html:
>
> All is well with coherent IO systems. On non coherent
> systems like Indigo2 and O2 this creates a race
> condition with DMA reads (IO->mem) where a stale
> cached data can be written back over the DMAed data.
It's not a race condition.
> R10K Indigo2:
>
> This issue was figured out late the the R10K I2
> design cycle. The problem was fixed by modifying
> the compiler and assembler to issue a cache barrier
> instruction to address 0(sp) as the first instruction
> in basic blocks that contain stores to registers
> other than $0 and $sp.
>
> and from a compiler point of view, it would be nice to know
> _why_ that was a reasonable workaround. What I was really
> looking for was: (a) a short description of the problem,
> (b) a list of assumptions that the compiler is going to
> make when working around the problem and (c) a description
> of what said workarounds are.
>
> My understanding of (a) is that, if a store is speculatively executed,
> the target of the store might be fetched into cache and marked dirty.
> We therefore want to avoid the speculative execution of stores if:
>
> (1) the addressed memory might be the target of a later DMA operation.
> If the DMA completes before the "dirty" cache line is flushed,
> the cached data might overwrite the DMAed data.
>
> (2) the addressed memory might be to IO-mapped cached memory
> (usually through the address being garbage). The cached
> data will be written back to the IO region when flushed.
>
> We also want to avoid speculative execution of loads if:
>
> (3) the addressed memory might be to load-sensitive IO-mapped cached
> memory (usually through the address being garbage). The hardware
> would "see" loads that aren't actually executed.
>
> Is that vaguely accurate?
Yes.
> I tried to piece together (b) by asking questions in the reviews,
> but it would be great to have a single explanation.
>
> The idea behind (c) is simple, of course: we insert a cache barrier
> before the potentially-problematic stores (and, for certain
> configurations, loads, although the original gcc patch had the
> associated macro hard-wired to false). The key is explaining how,
> from a compiler internals viewpoint, we decide what is "potentially-
> problematic". This ties in with the assumptions for (b).
The principle for the compiler is a store is problematic unless proven
otherwise. A speculative store relative to the stack pointer, frame
pointer or global pointer for example is harmless.
> I'm sure my attempt at (a) above can be improved upon even if it's
> vaguely right. But...
>
> > I guess the patch could be improved
> > by pointing directly to the errata section of the R10k
> > user manual.
>
> ...I think an integrated explanation of (a), (b) and (c) above
> would be better than quoting large parts of the processor manual.
> The processor manual is aimed at a much broader audience and has
> a lot of superfluous info. It also doesn't explain what _our_
> assumptions are and what our chosen workaround is.
There are two R10000 manuals, one from SGI and one from NEC and they're
differing quite a bit on the workaround. The SGI one gives a large number
of suggestions on how to work around the behaviour some of which even
require hardware asistance by on the system board. A long time ago
Bill Earl, one of the engineers at SGI responsible for the workaround
emailed me this explanation which I believe is quite reasonable:
[...]
The R10000 "bug" is, in a sense, a feature, in that it improves
performance, and is harmless on machines with cache-coherent I/O.
Specifically, on a speculative store miss (a cache miss due to a
speculatively executed store instruction), the R10000 fetches the line
dirty-exclusive and marks it modified, in anticipation of the store.
If, however, the speculatively executed store never graduates (is
never committed), the line is left dirty, even though it has not been
modified. If the line happens to be part of a buffer into which data
is being DMAed, a subsequent victim writeback of the dirty cache line
might overwrite good data from the DMA with the obsolete data in the
cache line. This means that, one way or the other, a system with
non-cache-coherent I/O and an R10000 must avoid allowing the
processor to perform a speculative store miss with respect to memory
into which a DMA is taking place.
Note that the Indigo2 and O2 have somewhat different workarounds.
The Indigo2 deals with the kernel side using a special compilation mode,
and the O2 deals with the kernel side using a special hardware feature
plus a generalization of the solution for the user mode part of the problem.
Both deal with the user mode by invalidating TLB entries for pages into
which data is being transferred via DMA, so that the processor cannot
resolve the virtual address, and hence cannot speculatively fetch
a cache line at that address, while the DMA is in progress. The kernel
side is harder, since the TLB is not used for K0SEG and XKPHYS address
spaces, which is where things get complicated.
[...]
I should mention that the hardware assissted solution for the O2 which is
implemented using an CPLD codenamed "juice" is not currently used by
Linux that is it relies on the same software-only workaround as the
Indigo 2 R10000.
Ralf
^ permalink raw reply
* 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
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