* Re: [PATCH] prom_free_prom_memory for QEMU
From: Thiemo Seufer @ 2008-01-14 14:27 UTC (permalink / raw)
To: Dmitri Vorobiev; +Cc: Atsushi Nemoto, ralf, linux-mips
In-Reply-To: <478B6BBD.90005@gmail.com>
Dmitri Vorobiev wrote:
> Atsushi Nemoto wrote:
> > On Mon, 14 Jan 2008 13:37:01 +0000, Ralf Baechle <ralf@linux-mips.org> wrote:
> >> I was actually planning to remove the Qemu platform for 2.6.25. The
> >> Malta emulation has become so good that there is no more point in having
> >> the underfeatured synthetic platform that CONFIG_QEMU is.
> >>
> >> Objections?
> >
> > The Qemu platform is one of officially supported platforms by Debian.
> > If Debian did not support the Malta yet, I hope qemu alive.
>
> Would you like me to try following the instructions given at
>
> http://www.aurel32.net/info/debian_mips_qemu.php
>
> with QEMU emulating a Malta board? I haven't tried this yet, but I
> feel that the possibility exists that this would work out of the box.
Combining a self-compiled Malta kernel with the Qemu initrd from Debian
works with some minor glitches (like unusable kernel modules in the
installed image). Adding proper support in the Debian installer is
currently ongoing.
Thiemo
^ permalink raw reply
* Re: [PATCH] IP28 fixes
From: Sergei Shtylyov @ 2008-01-14 14:24 UTC (permalink / raw)
To: Ralf Baechle; +Cc: Thomas Bogendoerfer, linux-mips
In-Reply-To: <20080114001014.GC20115@linux-mips.org>
Ralf Baechle wrote:
>>- ISA DMA is broken on IP28
>>- bus error handler improved to not issue bus errors for
>> speculative accesses to CPU and GIO addresses. We now
>> treat CSTAT_ADDR and GSTAT_TIME errors as non fatal, when
>> they are issues via MC error interrupt. For real (non
>> speculative) bus errors a DBE will be issued, which is
>> lethal as before. Handling the issue this way gets rid
>> of decoding instructions
>>Signed-off-by: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
> Folded into the "[MIPS] IP28 support" patch for 2.6.28.
Poor IP32 will have to wait couple of years? ;-)
> Thanks,
> Ralf
WBR, Sergei
^ permalink raw reply
* Re: [PATCH] prom_free_prom_memory for QEMU
From: Ralf Baechle @ 2008-01-14 14:14 UTC (permalink / raw)
To: Dmitri Vorobiev; +Cc: Atsushi Nemoto, linux-mips
In-Reply-To: <478B6AA3.2070402@gmail.com>
On Mon, Jan 14, 2008 at 04:58:59PM +0300, Dmitri Vorobiev wrote:
> > I was actually planning to remove the Qemu platform for 2.6.25. The
> > Malta emulation has become so good that there is no more point in having
> > the underfeatured synthetic platform that CONFIG_QEMU is.
>
> I wholeheartedly agree with that. It is a godsend to me that I can use
> identical configs to build the kernels for QEMU and for a physical Malta.
> Emulation is more convenient to me because QEMU boots and runs faster
> than the board I'm working with. Many thanks for that to QEMU developers.
>
> Off the topic, how about the plans to remove Atlas support?
Maciej is promising to fix it up since a few years ;-) Aside of that it's
safe to say the Atlas is dead like a coffin nail.
The main problem with the Atlas is the SAA9730 SOC which is broken in an
infinite number of totally pervert ways, I'm told. I know of no systems
other than the Atlas using it.
Ralf
^ permalink raw reply
* Re: [PATCH] prom_free_prom_memory for QEMU
From: Dmitri Vorobiev @ 2008-01-14 14:03 UTC (permalink / raw)
To: Atsushi Nemoto; +Cc: ralf, linux-mips
In-Reply-To: <20080114.225318.63132741.anemo@mba.ocn.ne.jp>
Atsushi Nemoto wrote:
> On Mon, 14 Jan 2008 13:37:01 +0000, Ralf Baechle <ralf@linux-mips.org> wrote:
>> I was actually planning to remove the Qemu platform for 2.6.25. The
>> Malta emulation has become so good that there is no more point in having
>> the underfeatured synthetic platform that CONFIG_QEMU is.
>>
>> Objections?
>
> The Qemu platform is one of officially supported platforms by Debian.
> If Debian did not support the Malta yet, I hope qemu alive.
Would you like me to try following the instructions given at
http://www.aurel32.net/info/debian_mips_qemu.php
with QEMU emulating a Malta board? I haven't tried this yet, but I
feel that the possibility exists that this would work out of the box.
Dmitri
>
> ---
> Atsushi Nemoto
>
>
^ permalink raw reply
* Re: [PATCH] prom_free_prom_memory for QEMU
From: Ralf Baechle @ 2008-01-14 13:59 UTC (permalink / raw)
To: Atsushi Nemoto; +Cc: linux-mips
In-Reply-To: <20080114.225318.63132741.anemo@mba.ocn.ne.jp>
On Mon, Jan 14, 2008 at 10:53:18PM +0900, Atsushi Nemoto wrote:
> On Mon, 14 Jan 2008 13:37:01 +0000, Ralf Baechle <ralf@linux-mips.org> wrote:
> > I was actually planning to remove the Qemu platform for 2.6.25. The
> > Malta emulation has become so good that there is no more point in having
> > the underfeatured synthetic platform that CONFIG_QEMU is.
> >
> > Objections?
>
> The Qemu platform is one of officially supported platforms by Debian.
> If Debian did not support the Malta yet, I hope qemu alive.
A few days ago Thiemo told me Debian dropped the Qemu kernel image. Malta
otoh is alive and well.
Ralf
^ permalink raw reply
* Re: [PATCH] prom_free_prom_memory for QEMU
From: Dmitri Vorobiev @ 2008-01-14 13:58 UTC (permalink / raw)
To: Ralf Baechle; +Cc: Atsushi Nemoto, linux-mips
In-Reply-To: <20080114133701.GA16555@linux-mips.org>
Ralf Baechle wrote:
> On Mon, Jan 14, 2008 at 09:22:53PM +0900, Atsushi Nemoto wrote:
>
>> You can get 60kb more memory by this patch. Note that this patch
>> might cause segfault on some intermediate version of qemu 0.9.0 and
>> 0.9.1 (For example Debian qemu-0.9.0+20070816-1).
>
> I was actually planning to remove the Qemu platform for 2.6.25. The
> Malta emulation has become so good that there is no more point in having
> the underfeatured synthetic platform that CONFIG_QEMU is.
I wholeheartedly agree with that. It is a godsend to me that I can use
identical configs to build the kernels for QEMU and for a physical Malta.
Emulation is more convenient to me because QEMU boots and runs faster
than the board I'm working with. Many thanks for that to QEMU developers.
Off the topic, how about the plans to remove Atlas support?
Dmitri
>
> Objections?
>
> Ralf
>
>
^ permalink raw reply
* Re: [PATCH] prom_free_prom_memory for QEMU
From: Atsushi Nemoto @ 2008-01-14 13:53 UTC (permalink / raw)
To: ralf; +Cc: linux-mips
In-Reply-To: <20080114133701.GA16555@linux-mips.org>
On Mon, 14 Jan 2008 13:37:01 +0000, Ralf Baechle <ralf@linux-mips.org> wrote:
> I was actually planning to remove the Qemu platform for 2.6.25. The
> Malta emulation has become so good that there is no more point in having
> the underfeatured synthetic platform that CONFIG_QEMU is.
>
> Objections?
The Qemu platform is one of officially supported platforms by Debian.
If Debian did not support the Malta yet, I hope qemu alive.
---
Atsushi Nemoto
^ permalink raw reply
* Re: [PATCH] prom_free_prom_memory for QEMU
From: Ralf Baechle @ 2008-01-14 13:37 UTC (permalink / raw)
To: Atsushi Nemoto; +Cc: linux-mips
In-Reply-To: <20080114.212253.126142719.anemo@mba.ocn.ne.jp>
On Mon, Jan 14, 2008 at 09:22:53PM +0900, Atsushi Nemoto wrote:
> You can get 60kb more memory by this patch. Note that this patch
> might cause segfault on some intermediate version of qemu 0.9.0 and
> 0.9.1 (For example Debian qemu-0.9.0+20070816-1).
I was actually planning to remove the Qemu platform for 2.6.25. The
Malta emulation has become so good that there is no more point in having
the underfeatured synthetic platform that CONFIG_QEMU is.
Objections?
Ralf
^ permalink raw reply
* [PATCH] prom_free_prom_memory for QEMU
From: Atsushi Nemoto @ 2008-01-14 12:22 UTC (permalink / raw)
To: linux-mips; +Cc: ralf
You can get 60kb more memory by this patch. Note that this patch
might cause segfault on some intermediate version of qemu 0.9.0 and
0.9.1 (For example Debian qemu-0.9.0+20070816-1).
Signed-off-by: Atsushi Nemoto <anemo@mba.ocn.ne.jp>
---
diff --git a/arch/mips/qemu/q-mem.c b/arch/mips/qemu/q-mem.c
index dae39b5..84cbee2 100644
--- a/arch/mips/qemu/q-mem.c
+++ b/arch/mips/qemu/q-mem.c
@@ -1,5 +1,9 @@
#include <linux/init.h>
+#include <asm/bootinfo.h>
+#include <asm/sections.h>
+#include <asm/page.h>
void __init prom_free_prom_memory(void)
{
+ free_init_pages("prom memory", PAGE_SIZE, __pa_symbol(&_text));
}
^ permalink raw reply related
* Re: (Try #3) [Patch 2/8] MIPS: Remove 'TOPDIR' from Makefiles
From: WANG Cong @ 2008-01-14 6:26 UTC (permalink / raw)
To: Sam Ravnborg
Cc: Ralf Baechle, WANG Cong, Andreas Schwab, LKML, linux-kbuild,
Andrew Morton, linux-mips
In-Reply-To: <20080111170204.GA28299@uranus.ravnborg.org>
On Fri, Jan 11, 2008 at 06:02:04PM +0100, Sam Ravnborg wrote:
>On Fri, Jan 11, 2008 at 02:17:54PM +0000, Ralf Baechle wrote:
>> On Wed, Jan 02, 2008 at 02:21:36PM +0800, WANG Cong wrote:
>>
>> > >> Shouldn't that use $(LINUXINCLUDE), or $(KBUILD_CPPFLAGS)?
>> > >It would be better to use $(LINUXINCLUDE) as we then pull in all config
>> > >symbols too and do not have to hardcode kbuild internal names (include2).
>> >
>> > OK. Refine this patch.
>>
>> LDSCRIPT also needed fixing to get builds in a separate object directory
>> working again.
>>
>> I've applied below fix.
>
>Great - I will drop it from my tree.
>
>See small comment below.
>
> Sam
>
>
>> Ralf
>>
>> From 8babf06e1265214116fb8ffc634c04df85597c52 Mon Sep 17 00:00:00 2001
>> From: WANG Cong <xiyou.wangcong@gmail.com>
>> Date: Wed, 2 Jan 2008 14:21:36 +0800
>> Subject: [PATCH] [MIPS] Lasat: Fix built in separate object directory.
>>
>> Signed-off-by: WANG Cong <xiyou.wangcong@gmail.com>
>>
>> [Ralf: The LDSCRIPT script needed fixing, too]
>>
>> Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
>>
>> diff --git a/arch/mips/lasat/image/Makefile b/arch/mips/lasat/image/Makefile
>> index 5332449..7ccd40d 100644
>> --- a/arch/mips/lasat/image/Makefile
>> +++ b/arch/mips/lasat/image/Makefile
>> @@ -12,11 +12,11 @@ endif
>>
>> MKLASATIMG = mklasatimg
>> MKLASATIMG_ARCH = mq2,mqpro,sp100,sp200
>> -KERNEL_IMAGE = $(TOPDIR)/vmlinux
>> +KERNEL_IMAGE = vmlinux
>> KERNEL_START = $(shell $(NM) $(KERNEL_IMAGE) | grep " _text" | cut -f1 -d\ )
>> KERNEL_ENTRY = $(shell $(NM) $(KERNEL_IMAGE) | grep kernel_entry | cut -f1 -d\ )
>>
>> -LDSCRIPT= -L$(obj) -Tromscript.normal
>> +LDSCRIPT= -L$(srctree)/$(obj) -Tromscript.normal
>
>This needs to read:
>> +LDSCRIPT= -L$(srctree)/$(src) -Tromscript.normal
>
>
>(There is no difference between src and obj in normal cases but to be consistent
>it shuld be like above).
Agreed. Thank you!
^ permalink raw reply
* Re: [SPAM] flush_cache_page
From: Jorgen Lundman @ 2008-01-14 4:19 UTC (permalink / raw)
To: linux-mips
In-Reply-To: <DF375560-30CA-44EF-A571-437BB4B08D31@27m.se>
Markus Gothe wrote:
> Man, 2.6.15 is like 2-3 years old....
Thank you, that is very useful. And if you can let me know how I do the
signature, and which AES keys I need to encrypt the kernel with to be
able to boot it on the SMP8634 I could upgrade.
But for now, I can not change what the device runs, only try to work
around its limitations.
Lund
>
> On 13 Jan 2008, at 05:55, Jorgen Lundman wrote:
>
>>
>> Due to cache coherence bugs, Fuse has an extra call to work around it;
>>
>> flush_cache_page(vma, cs->addr, page_to_pfn(cs->pg));
>>
>>
>> But my kernel (2.6.15 for mips 4KEc Tangox board) does not have a
>> flush_cache_page().
>>
>> If I use kangox_flush_all() Fuse works rather well, but the
>> performance is abysmal. Can I simulate this call using one of the
>> calls I do have;
>>
>> __flush_dcache_page
>> flush_data_cache_page
>> tangox_flush_cache_all
>> cache_flush
>> kc_flush_cache
>>
>> Or alternatively, does anyone have the source for flush_cache_page()
>> for said CPU?
>>
>>
>>
>> --
>> Jorgen Lundman | <lundman@lundman.net <mailto:lundman@lundman.net>>
>> Unix Administrator | +81 (0)3 -5456-2687 ext 1017 (work)
>> Shibuya-ku, Tokyo | +81 (0)90-5578-8500 (cell)
>> Japan | +81 (0)3 -3375-1767 (home)
>>
>
> _______________________________________
>
> Mr Markus Gothe
> Software Engineer
>
> Phone: +46 (0)13 21 81 20 (ext. 1046)
> Fax: +46 (0)13 21 21 15
> Mobile: +46 (0)73 718 72 80
> Diskettgatan 11, SE-583 35 Linköping, Sweden
> www.27m.com <http://www.27m.com>
>
>
--
Jorgen Lundman | <lundman@lundman.net>
Unix Administrator | +81 (0)3 -5456-2687 ext 1017 (work)
Shibuya-ku, Tokyo | +81 (0)90-5578-8500 (cell)
Japan | +81 (0)3 -3375-1767 (home)
^ permalink raw reply
* Re: [patch] pnx8xxx clocksource cleanups
From: Ralf Baechle @ 2008-01-14 0:18 UTC (permalink / raw)
To: Vitaly Wool; +Cc: sshtylyov, linux-mips
In-Reply-To: <4788BAAC.3020908@gmail.com>
On Sat, Jan 12, 2008 at 04:03:40PM +0300, Vitaly Wool wrote:
> This patch does some PNX8XXX clocksource cleanups.
Queued for 2.6.25.
Ralf
^ permalink raw reply
* Re: [PATCH] IP28 fixes
From: Ralf Baechle @ 2008-01-14 0:10 UTC (permalink / raw)
To: Thomas Bogendoerfer; +Cc: linux-mips
In-Reply-To: <20080112230051.AE10EC2F34@solo.franken.de>
On Sun, Jan 13, 2008 at 12:00:51AM +0100, Thomas Bogendoerfer wrote:
> - ISA DMA is broken on IP28
> - bus error handler improved to not issue bus errors for
> speculative accesses to CPU and GIO addresses. We now
> treat CSTAT_ADDR and GSTAT_TIME errors as non fatal, when
> they are issues via MC error interrupt. For real (non
> speculative) bus errors a DBE will be issued, which is
> lethal as before. Handling the issue this way gets rid
> of decoding instructions
>
> Signed-off-by: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
Folded into the "[MIPS] IP28 support" patch for 2.6.28.
Thanks,
Ralf
^ permalink raw reply
* Re: [PATCH] Cobalt Qube1 has no serial port so don't use it
From: Ralf Baechle @ 2008-01-14 0:04 UTC (permalink / raw)
To: Thomas Bogendoerfer; +Cc: linux-mips
In-Reply-To: <20080111232517.C7B9FC2F2B@solo.franken.de>
On Sat, Jan 12, 2008 at 12:25:17AM +0100, Thomas Bogendoerfer wrote:
> Because Qube1 doesn't have a serial chip waiting for transmit fifo empty
> takes forever, which isn't a good idea. No prom_putchar/early console
> for Qube1 fixes this.
Applied, too.
Ralf
^ permalink raw reply
* Re: [PATCH] Fix ethernet interrupts for Cobalt RaQ1
From: Ralf Baechle @ 2008-01-14 0:01 UTC (permalink / raw)
To: Thomas Bogendoerfer; +Cc: linux-mips
In-Reply-To: <20080111232514.64772C2F2A@solo.franken.de>
On Sat, Jan 12, 2008 at 12:25:14AM +0100, Thomas Bogendoerfer wrote:
> RAQ1 uses the same interrupt routing as qube2.
>
> Signed-off-by: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
Applied with comment fix from Martin.
Thanks,
Ralf
^ permalink raw reply
* [RFC] cleanup of board-specific code?
From: Dmitri Vorobiev @ 2008-01-13 21:04 UTC (permalink / raw)
To: linux-mips
I stumbled upon a bug in the board initialization code for Malta. While
researching this bug, I noticed that the files in arch/mips/mips-boards
contain multiple coding style violations, sloppily written constructs and
many other things, which seem to be in obvious need of cleaning up.
I think I can prepare and post a series of patches with a massive code
cleanup for the places mentioned above. The question is: would the MIPS
maintainers be interested in applying such changes? If yes, I could do
that in nearest future; if not, I will post a patch, which merely fixes
the Malta board initialization bug.
Thanks,
Dmitri
^ permalink raw reply
* Re: [SPAM] flush_cache_page
From: Markus Gothe @ 2008-01-13 15:21 UTC (permalink / raw)
To: Jorgen Lundman; +Cc: linux-mips
In-Reply-To: <478999C4.3040708@lundman.net>
[-- Attachment #1.1: Type: text/plain, Size: 1191 bytes --]
Man, 2.6.15 is like 2-3 years old....
On 13 Jan 2008, at 05:55, Jorgen Lundman wrote:
>
> Due to cache coherence bugs, Fuse has an extra call to work around it;
>
> flush_cache_page(vma, cs->addr, page_to_pfn(cs->pg));
>
>
> But my kernel (2.6.15 for mips 4KEc Tangox board) does not have a
> flush_cache_page().
>
> If I use kangox_flush_all() Fuse works rather well, but the
> performance is abysmal. Can I simulate this call using one of the
> calls I do have;
>
> __flush_dcache_page
> flush_data_cache_page
> tangox_flush_cache_all
> cache_flush
> kc_flush_cache
>
> Or alternatively, does anyone have the source for flush_cache_page()
> for said CPU?
>
>
>
> --
> Jorgen Lundman | <lundman@lundman.net>
> Unix Administrator | +81 (0)3 -5456-2687 ext 1017 (work)
> Shibuya-ku, Tokyo | +81 (0)90-5578-8500 (cell)
> Japan | +81 (0)3 -3375-1767 (home)
>
_______________________________________
Mr Markus Gothe
Software Engineer
Phone: +46 (0)13 21 81 20 (ext. 1046)
Fax: +46 (0)13 21 21 15
Mobile: +46 (0)73 718 72 80
Diskettgatan 11, SE-583 35 Linköping, Sweden
www.27m.com
[-- Attachment #1.2: Type: text/html, Size: 3364 bytes --]
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 194 bytes --]
^ permalink raw reply
* Re: [PATCH][MIPS]: AR7 GPIO
From: Atsushi Nemoto @ 2008-01-13 12:32 UTC (permalink / raw)
To: technoboy85; +Cc: linux-mips, florian, nbd, ejka, nico, ralf, akpm
In-Reply-To: <200801121818.02550.technoboy85@gmail.com>
On Sat, 12 Jan 2008 18:18:02 +0100, Matteo Croce <technoboy85@gmail.com> wrote:
> +static inline void gpio_set_value(unsigned gpio, int value)
> +{
> + static void __iomem *gpio_out;
> + unsigned tmp;
> +
> + if (!gpio_out)
> + gpio_out = (void __iomem *)
> + KSEG1ADDR(AR7_REGS_GPIO + AR7_GPIO_OUTPUT);
> +
> + tmp = readl(gpio_out) & ~(1 << gpio);
> + if (value)
> + tmp |= 1 << gpio;
> + writel(tmp, gpio_out);
> +}
It seems the compiler can calculate gpio_out value at compile time.
So I think caching it just make the function slower.
---
Atsushi Nemoto
^ permalink raw reply
* Re: [PATCH][MIPS]: AR7 GPIO
From: Atsushi Nemoto @ 2008-01-13 12:21 UTC (permalink / raw)
To: technoboy85; +Cc: linux-mips, florian, nbd, ejka, nico, ralf, akpm
In-Reply-To: <200801121818.02550.technoboy85@gmail.com>
On Sat, 12 Jan 2008 18:18:02 +0100, Matteo Croce <technoboy85@gmail.com> wrote:
> This new patch caches addresses as suggested by Atsushi Nemoto
Well, I cannot remember any suggestion about caches. I just said you
should kill all volatiles.
> +static inline int gpio_get_value(unsigned gpio)
> +{
> + static unsigned addr;
> +
> + if (!addr) {
> + void __iomem *gpio_in = (void __iomem *)
> + KSEG1ADDR(AR7_REGS_GPIO + AR7_GPIO_INPUT);
> + addr = readl(gpio_in);
> + }
> +
> + return addr & (1 << gpio);
> +}
Anyway, this is absolutely broken. You are caching the GPIO value,
not the address.
---
Atsushi Nemoto
^ permalink raw reply
* flush_cache_page
From: Jorgen Lundman @ 2008-01-13 4:55 UTC (permalink / raw)
To: linux-mips
Due to cache coherence bugs, Fuse has an extra call to work around it;
flush_cache_page(vma, cs->addr, page_to_pfn(cs->pg));
But my kernel (2.6.15 for mips 4KEc Tangox board) does not have a
flush_cache_page().
If I use kangox_flush_all() Fuse works rather well, but the performance
is abysmal. Can I simulate this call using one of the calls I do have;
__flush_dcache_page
flush_data_cache_page
tangox_flush_cache_all
cache_flush
kc_flush_cache
Or alternatively, does anyone have the source for flush_cache_page() for
said CPU?
--
Jorgen Lundman | <lundman@lundman.net>
Unix Administrator | +81 (0)3 -5456-2687 ext 1017 (work)
Shibuya-ku, Tokyo | +81 (0)90-5578-8500 (cell)
Japan | +81 (0)3 -3375-1767 (home)
^ permalink raw reply
* [PATCH] I8042: SNI RM support
From: Thomas Bogendoerfer @ 2008-01-12 23:39 UTC (permalink / raw)
To: linux-input, linux-mips; +Cc: dmitry.torokhov
SNI RM200 don't have the i8042 controller connected to the EISA bus, but
have a second address range for onboard devices. This patch handles
the two possible address ranges for the i8042 on SNI RMs
Signed-off-by: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
---
Please apply for 2.6.25.
drivers/input/serio/i8042-snirm.h | 75 +++++++++++++++++++++++++++++++++++++
drivers/input/serio/i8042.h | 2 +
2 files changed, 77 insertions(+), 0 deletions(-)
diff --git a/drivers/input/serio/i8042-snirm.h b/drivers/input/serio/i8042-snirm.h
new file mode 100644
index 0000000..57a66a3
--- /dev/null
+++ b/drivers/input/serio/i8042-snirm.h
@@ -0,0 +1,75 @@
+#ifndef _I8042_SNIRM_H
+#define _I8042_SNIRM_H
+
+#include <asm/sni.h>
+
+/*
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License version 2 as published by
+ * the Free Software Foundation.
+ */
+
+/*
+ * Names.
+ */
+
+#define I8042_KBD_PHYS_DESC "onboard/serio0"
+#define I8042_AUX_PHYS_DESC "onboard/serio1"
+#define I8042_MUX_PHYS_DESC "onboard/serio%d"
+
+/*
+ * IRQs.
+ */
+static int i8042_kbd_irq = -1;
+static int i8042_aux_irq = -1;
+#define I8042_KBD_IRQ i8042_kbd_irq
+#define I8042_AUX_IRQ i8042_aux_irq
+
+static void __iomem *kbd_iobase;
+
+#define I8042_COMMAND_REG (kbd_iobase + 0x64UL)
+#define I8042_DATA_REG (kbd_iobase + 0x60UL)
+
+static inline int i8042_read_data(void)
+{
+ return readb(kbd_iobase + 0x60UL);
+}
+
+static inline int i8042_read_status(void)
+{
+ return readb(kbd_iobase + 0x64UL);
+}
+
+static inline void i8042_write_data(int val)
+{
+ writeb(val, kbd_iobase + 0x60UL);
+}
+
+static inline void i8042_write_command(int val)
+{
+ writeb(val, kbd_iobase + 0x64UL);
+}
+static inline int i8042_platform_init(void)
+{
+ /* RM200 is strange ... */
+ if (sni_brd_type == SNI_BRD_RM200) {
+ kbd_iobase = ioremap(0x16000000, 4);
+ i8042_kbd_irq = 33;
+ i8042_aux_irq = 44;
+ } else {
+ kbd_iobase = ioremap(0x14000000, 4);
+ i8042_kbd_irq = 1;
+ i8042_aux_irq = 12;
+ }
+ if (!kbd_iobase)
+ return -ENOMEM;
+
+ return 0;
+}
+
+static inline void i8042_platform_exit(void)
+{
+
+}
+
+#endif /* _I8042_SNIRM_H */
diff --git a/drivers/input/serio/i8042.h b/drivers/input/serio/i8042.h
index dd22d91..b5e9917 100644
--- a/drivers/input/serio/i8042.h
+++ b/drivers/input/serio/i8042.h
@@ -18,6 +18,8 @@
#include "i8042-jazzio.h"
#elif defined(CONFIG_SGI_IP22)
#include "i8042-ip22io.h"
+#elif defined(CONFIG_SNI_RM)
+#include "i8042-snirm.h"
#elif defined(CONFIG_PPC)
#include "i8042-ppcio.h"
#elif defined(CONFIG_SPARC)
^ permalink raw reply related
* [PATCH] SGISEEQ: fix oops when doing ifconfig down; ifconfig up
From: Thomas Bogendoerfer @ 2008-01-12 23:08 UTC (permalink / raw)
To: netdev, linux-mips; +Cc: ralf, jgarzik
When doing init_ring checking whether a new skb needs to be allocated
was wrong.
Signed-off-by: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
---
This is a bug fix for the 2.6.25 driver.
drivers/net/sgiseeq.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/net/sgiseeq.c b/drivers/net/sgiseeq.c
index c69bb8b..78994ed 100644
--- a/drivers/net/sgiseeq.c
+++ b/drivers/net/sgiseeq.c
@@ -193,7 +193,7 @@ static int seeq_init_ring(struct net_device *dev)
/* And now the rx ring. */
for (i = 0; i < SEEQ_RX_BUFFERS; i++) {
- if (!sp->rx_desc[i].rdma.pbuf) {
+ if (!sp->rx_desc[i].skb) {
dma_addr_t dma_addr;
struct sk_buff *skb = netdev_alloc_skb(dev, PKT_BUF_SZ);
^ permalink raw reply related
* [PATCH] IP28 fixes
From: Thomas Bogendoerfer @ 2008-01-12 23:00 UTC (permalink / raw)
To: linux-mips; +Cc: ralf
- ISA DMA is broken on IP28
- bus error handler improved to not issue bus errors for
speculative accesses to CPU and GIO addresses. We now
treat CSTAT_ADDR and GSTAT_TIME errors as non fatal, when
they are issues via MC error interrupt. For real (non
speculative) bus errors a DBE will be issued, which is
lethal as before. Handling the issue this way gets rid
of decoding instructions
Signed-off-by: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
---
arch/mips/Kconfig | 1 +
arch/mips/sgi-ip22/ip28-berr.c | 203 +---------------------------------------
2 files changed, 4 insertions(+), 200 deletions(-)
diff --git a/arch/mips/Kconfig b/arch/mips/Kconfig
index 3541402..2996b9f 100644
--- a/arch/mips/Kconfig
+++ b/arch/mips/Kconfig
@@ -457,6 +457,7 @@ config SGI_IP28
select CSRC_R4K
select DEFAULT_SGI_PARTITION
select DMA_NONCOHERENT
+ select GENERIC_ISA_DMA_SUPPORT_BROKEN
select IRQ_CPU
select HW_HAS_EISA
select I8253
diff --git a/arch/mips/sgi-ip22/ip28-berr.c b/arch/mips/sgi-ip22/ip28-berr.c
index 0ee5be8..b09d7d5 100644
--- a/arch/mips/sgi-ip22/ip28-berr.c
+++ b/arch/mips/sgi-ip22/ip28-berr.c
@@ -299,198 +299,6 @@ static void print_buserr(const struct pt_regs *regs)
}
/*
- * Try to find out, whether the bus error is caused by the instruction
- * at EPC, otherwise we have an asynchronous error.
- *
- * Doc1: "MIPS IV Instruction Set", Rev 3.2 (SGI 007-2597-001)
- * Doc2: "MIPS R10000 Microporcessor User's Manual", Ver 2.0 (SGI 007-2490-001)
- * Doc3: "MIPS R4000 Microporcessor User's Manual", 2nd Ed. (SGI 007-2489-001)
- */
-
-#define JMP_INDEX26_OP 1
-#define JMP_REGISTER_OP 2
-#define JMP_PCREL16_OP 3
-#define BASE_OFFSET_OP 4
-#define BASE_IDXREG_OP 5
-
-/* Match virtual address in an insn with physical error address */
-
-static int match_addr(unsigned paddr, unsigned long vaddr)
-{
- unsigned long uaddr;
-
- if ((vaddr & 0xffffffff80000000L) == 0xffffffff80000000L)
- uaddr = (unsigned) CPHYSADDR(vaddr);
- else if ((vaddr >> 62) == 2)
- uaddr = (unsigned) XPHYSADDR(vaddr);
- else {
- unsigned long eh = vaddr & ~0x1fffL;
-
- eh |= read_c0_entryhi() & 0xff;
- write_c0_entryhi(eh);
- tlb_probe();
- if (read_c0_index() & 0x80000000)
- return 0;
- tlb_read();
- if (vaddr & (1L << PAGE_SHIFT))
- uaddr = (unsigned) read_c0_entrylo1();
- else
- uaddr = (unsigned) read_c0_entrylo0();
- uaddr <<= 6;
- uaddr &= ~PAGE_MASK;
- uaddr |= vaddr & PAGE_MASK;
- }
- return ((uaddr & ~0x7f) == (paddr & ~0x7f));
-}
-
-/* Check, which kind of memory reference is triggered by `insn' */
-
-static int check_special(unsigned insn)
-{
- /* See Doc1, page A-180 */
- unsigned func = insn & 0x3f;
-
- if (8 == func || 8+1 == func) /* JR, JALR */
- return JMP_REGISTER_OP;
-
- return 0;
-}
-
-static int check_regimm(unsigned insn)
-{
- /* See Doc1, page A-180 */
- unsigned rt = (insn >> 19) & 3; /* bits 20..19[..16] */
-
- /* BLTZ, BGEZ, BLTZL, BBGEZL || BLTZAL, BGEZAL, BLTZALL, BBGEZALL */
- if (!rt || 2 == rt)
- return JMP_PCREL16_OP;
-
- return 0;
-}
-
-static int check_cop0(unsigned insn)
-{
- /* See Doc2, pages 287 ff., 187 ff. */
- if ((insn >> 26) == 5*8+7) /* CACHE */
- switch ((insn >> 16) & 0x1f) {
- case Index_Writeback_Inv_D:
- case Hit_Writeback_Inv_D:
- case Index_Writeback_Inv_S:
- case Hit_Writeback_Inv_S:
- return BASE_OFFSET_OP;
- }
- return 0;
-}
-
-static int check_cop1(unsigned insn)
-{
- /* See Doc1, pages B-108 ff. */
- unsigned fmt = (insn >> 21) & 0x1f; /* bits 25..21 */
-
- if (8 == fmt) /* BC1* */
- return JMP_PCREL16_OP;
-
- return 0;
-}
-
-static int check_cop1x(unsigned insn)
-{
- /* See Doc1, pages B-108 ff. */
- switch (insn & 0x3f) {
- case 0: /* LWXC1 */
- case 1: /* LDXC1 */
- case 8: /* SWXC1 */
- case 8+1: /* SDXC1 */
- return BASE_IDXREG_OP;
- }
- return 0;
-}
-
-static int check_plain(unsigned insn)
-{
- /* See Doc1, page A-180 */
- unsigned opcode = insn >> 26;
-
- if (2 == opcode || 3 == opcode) /* J, JAL */
- return JMP_INDEX26_OP;
-
- if ((4 <= opcode && opcode <= 7) || /* BEQ, BNE, BLEZ, BGTZ */
- (4+2*8 <= opcode && opcode <= 7+2*8)) /* BEQL, BNEL, BLEZL, BGTZL */
- return JMP_PCREL16_OP;
-
- if (6*8+3 == opcode) /* PREF */
- return 0;
-
- if (3*8+2 == opcode || 3*8+3 == opcode || /* LDL, LDR */
- 4*8 <= opcode) /* misc. LOAD, STORE */
- return BASE_OFFSET_OP;
-
- return 0;
-}
-
-/* Check, whether the insn at EPC causes a memory access at `paddr' */
-
-static int check_addr_in_insn(unsigned paddr, const struct pt_regs *regs)
-{
- unsigned long epc;
- unsigned insn;
- unsigned long a;
- int typ;
-
- epc = regs->cp0_cause & CAUSEF_BD ? regs->cp0_epc:regs->cp0_epc+4;
-
- /* show_code() from kernel/traps.c */
- if (__get_user(insn, (u32 *)epc))
- return 1;
-
- /* See Doc1, pages A-180, B-108 ff. */
- switch (insn >> 26) {
- case 0:
- typ = check_special(insn);
- break;
- case 1:
- typ = check_regimm(insn);
- break;
- case 2*8: /* COP0 */
- case 5*8+7: /* CACHE */
- typ = check_cop0(insn);
- break;
- case 2*8+1:
- typ = check_cop1(insn);
- break;
- case 2*8+3:
- typ = check_cop1x(insn);
- break;
- default:
- typ = check_plain(insn);
- break;
- }
- switch (typ) {
- case JMP_INDEX26_OP:
- a = (regs->cp0_epc + 4) & ~0xfffffff;
- a |= (insn & 0x3ffffff) << 2;
- return match_addr(paddr, a);
- case JMP_REGISTER_OP:
- a = regs->regs[(insn >> 21) & 0x1f];
- return match_addr(paddr, a);
- case JMP_PCREL16_OP:
- a = regs->cp0_epc + 4 + ((insn & 0xffff) << 2);
- return match_addr(paddr, a);
- case BASE_OFFSET_OP:
- a = regs->regs[(insn >> 21) & 0x1f] + (insn & 0xffff);
- return match_addr(paddr, a);
- case BASE_IDXREG_OP:
- a = regs->regs[(insn >> 21) & 0x1f];
- a += regs->regs[(insn >> 16) & 0x1f];
- return match_addr(paddr, a);
- case 0:
- return 0;
- }
- /* Assume it would be too dangerous to continue ... */
- return 1;
-}
-
-/*
* Check, whether MC's (virtual) DMA address caused the bus error.
* See "Virtual DMA Specification", Draft 1.5, Feb 13 1992, SGI
*/
@@ -594,16 +402,11 @@ static int ip28_be_interrupt(const struct pt_regs *regs)
/* Any state other than "Memory bus error" is fatal. */
if (cpu_err_stat & CPU_ERRMASK & ~SGIMC_CSTAT_ADDR)
- goto mips_be_fatal;
-
- /* GIO errors are fatal */
- if (gio_err_stat & GIO_ERRMASK)
goto mips_be_fatal;
- /* Finding `cpu_err_addr' in the insn at EPC is fatal. */
- if ((cpu_err_stat & CPU_ERRMASK) &&
- check_addr_in_insn(cpu_err_addr, regs))
- goto mips_be_fatal;
+ /* GIO errors other than timeouts are fatal */
+ if (gio_err_stat & GIO_ERRMASK & ~SGIMC_GSTAT_TIME)
+ goto mips_be_fatal;
/*
* Now we have an asynchronous bus error, speculatively or DMA caused.
^ permalink raw reply related
* Re: [UPDATED PATCH] SGISEEQ: use cached memory access to make driver work on IP28
From: Jeff Garzik @ 2008-01-12 22:23 UTC (permalink / raw)
To: Thomas Bogendoerfer; +Cc: netdev, linux-mips, ralf
In-Reply-To: <20071219124235.GA7550@alpha.franken.de>
Thomas Bogendoerfer wrote:
> - Use inline functions for dma_sync_* instead of macros
> - added Kconfig change to make selection for similair SGI boxes easier
>
> Signed-off-by: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
> ---
>
> drivers/net/Kconfig | 2 +-
> drivers/net/sgiseeq.c | 64 ++++++++++++++++++++++++++-----------------------
> 2 files changed, 35 insertions(+), 31 deletions(-)
applied
^ permalink raw reply
* Re: [patch] pnx8xxx clocksource cleanups
From: Vitaly Wool @ 2008-01-12 20:40 UTC (permalink / raw)
To: Sergei Shtylyov; +Cc: ralf, linux-mips
In-Reply-To: <4788F6FE.6000803@ru.mvista.com>
> > +static inline void timer_ack(void)
> > +{
> > + write_c0_compare(cpj);
> > +}
>
> I still don't understand why you need this function at all, and the 'cpj'
> variable as well -- clockevents core will set the comparator to a needed
> value. Also, I don't see much value in moving that function...
Well, it's explicitly made inline and it has been moved closer to the
calling function.
Vitaly
^ 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