* [PATCH] powerpc: Call find_legacy_serial_ports() if we enable CONFIG_SERIAL_8250
From: Kumar Gala @ 2005-12-21 2:45 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev, linuxppc64-dev
In setup_arch and setup_system call find_legacy_serial_ports() if we
build in support for 8250 serial ports instead of basing it on PPC_MULTIPLATFORM.
Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
---
commit 399e10aa1c6a3ca64e8e8e8cea7289e9908cc62c
tree 3e5320b8a97a37c4d010186aabf8a95e5be264b4
parent 7b69a37a4e811e72e82896ab38e6ae04542455f5
author Kumar Gala <galak@kernel.crashing.org> Tue, 20 Dec 2005 20:48:36 -0600
committer Kumar Gala <galak@kernel.crashing.org> Tue, 20 Dec 2005 20:48:36 -0600
arch/powerpc/kernel/setup_32.c | 2 +-
arch/powerpc/kernel/setup_64.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/kernel/setup_32.c b/arch/powerpc/kernel/setup_32.c
index 79d434f..e5d285a 100644
--- a/arch/powerpc/kernel/setup_32.c
+++ b/arch/powerpc/kernel/setup_32.c
@@ -299,7 +299,7 @@ void __init setup_arch(char **cmdline_p)
if (ppc_md.init_early)
ppc_md.init_early();
-#ifdef CONFIG_PPC_MULTIPLATFORM
+#ifdef CONFIG_SERIAL_8250
find_legacy_serial_ports();
#endif
finish_device_tree();
diff --git a/arch/powerpc/kernel/setup_64.c b/arch/powerpc/kernel/setup_64.c
index 419e0b9..98e9f05 100644
--- a/arch/powerpc/kernel/setup_64.c
+++ b/arch/powerpc/kernel/setup_64.c
@@ -472,7 +472,7 @@ void __init setup_system(void)
* hash table management for us, thus ioremap works. We do that early
* so that further code can be debugged
*/
-#ifdef CONFIG_PPC_MULTIPLATFORM
+#ifdef CONFIG_SERIAL_8250
find_legacy_serial_ports();
#endif
^ permalink raw reply related
* [PATCH] powerpc: added a udbg_progress
From: Kumar Gala @ 2005-12-20 22:37 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev, linuxppc64-dev
Added a common udbg_progress for use by ppc_md.progress()
Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
---
commit 7b69a37a4e811e72e82896ab38e6ae04542455f5
tree 923809875e727ab5d0dd0579e45da9201dd86653
parent adb69b3e888de037f4e58cc505443e624d498596
author Kumar Gala <galak@kernel.crashing.org> Tue, 20 Dec 2005 16:40:09 -0600
committer Kumar Gala <galak@kernel.crashing.org> Tue, 20 Dec 2005 16:40:09 -0600
arch/powerpc/kernel/udbg.c | 6 ++++++
arch/powerpc/platforms/powermac/setup.c | 8 +-------
include/asm-powerpc/udbg.h | 1 +
3 files changed, 8 insertions(+), 7 deletions(-)
diff --git a/arch/powerpc/kernel/udbg.c b/arch/powerpc/kernel/udbg.c
index 9567d94..558c1ce 100644
--- a/arch/powerpc/kernel/udbg.c
+++ b/arch/powerpc/kernel/udbg.c
@@ -90,6 +90,12 @@ void udbg_printf(const char *fmt, ...)
va_end(args);
}
+void __init udbg_progress(char *s, unsigned short hex)
+{
+ udbg_puts(s);
+ udbg_puts("\n");
+}
+
/*
* Early boot console based on udbg
*/
diff --git a/arch/powerpc/platforms/powermac/setup.c b/arch/powerpc/platforms/powermac/setup.c
index 1daa5a0..e5a5bdb 100644
--- a/arch/powerpc/platforms/powermac/setup.c
+++ b/arch/powerpc/platforms/powermac/setup.c
@@ -639,12 +639,6 @@ static void __init pmac_init_early(void)
#endif
}
-static void __init pmac_progress(char *s, unsigned short hex)
-{
- udbg_puts(s);
- udbg_puts("\n");
-}
-
/*
* pmac has no legacy IO, anything calling this function has to
* fail or bad things will happen
@@ -763,7 +757,7 @@ struct machdep_calls __initdata pmac_md
.calibrate_decr = pmac_calibrate_decr,
.feature_call = pmac_do_feature_call,
.check_legacy_ioport = pmac_check_legacy_ioport,
- .progress = pmac_progress,
+ .progress = udbg_progress,
#ifdef CONFIG_PPC64
.pci_probe_mode = pmac_pci_probe_mode,
.idle_loop = native_idle,
diff --git a/include/asm-powerpc/udbg.h b/include/asm-powerpc/udbg.h
index 58cdc88..a3390b0 100644
--- a/include/asm-powerpc/udbg.h
+++ b/include/asm-powerpc/udbg.h
@@ -23,6 +23,7 @@ extern int udbg_read(char *buf, int bufl
extern void register_early_udbg_console(void);
extern void udbg_printf(const char *fmt, ...);
+extern void udbg_progress(char *s, unsigned short hex);
extern void udbg_init_uart(void __iomem *comport, unsigned int speed,
unsigned int clock);
^ permalink raw reply related
* [PATCH] powerpc: Add the ability to handle SOC ports in legacy_serial
From: Kumar Gala @ 2005-12-20 22:16 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc64-dev, linuxppc-dev
Add the ability to configure and initialize legacy 8250 serials
ports on an SOC bus. Also, fixed an issue that we would not
configure any serial ports if "linux,stdout-path" was not found.
Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
---
commit adb69b3e888de037f4e58cc505443e624d498596
tree 7be9bb626b8d2c773dd88a1d3e17a5f56995075f
parent 8bec94b3bb35c0273fbab5a6aa477ec71a4d1fab
author Kumar Gala <galak@kernel.crashing.org> Tue, 20 Dec 2005 16:20:09 -0600
committer Kumar Gala <galak@kernel.crashing.org> Tue, 20 Dec 2005 16:20:09 -0600
arch/powerpc/kernel/legacy_serial.c | 62 +++++++++++++++++++++++++++++------
1 files changed, 52 insertions(+), 10 deletions(-)
diff --git a/arch/powerpc/kernel/legacy_serial.c b/arch/powerpc/kernel/legacy_serial.c
index d179ec5..59164ba 100644
--- a/arch/powerpc/kernel/legacy_serial.c
+++ b/arch/powerpc/kernel/legacy_serial.c
@@ -36,7 +36,8 @@ static int legacy_serial_console = -1;
static int __init add_legacy_port(struct device_node *np, int want_index,
int iotype, phys_addr_t base,
- phys_addr_t taddr, unsigned long irq)
+ phys_addr_t taddr, unsigned long irq,
+ unsigned int flags)
{
u32 *clk, *spd, clock = BASE_BAUD * 16;
int index;
@@ -90,7 +91,7 @@ static int __init add_legacy_port(struct
legacy_serial_ports[index].iotype = iotype;
legacy_serial_ports[index].uartclk = clock;
legacy_serial_ports[index].irq = irq;
- legacy_serial_ports[index].flags = ASYNC_BOOT_AUTOCONF;
+ legacy_serial_ports[index].flags = flags;
legacy_serial_infos[index].taddr = taddr;
legacy_serial_infos[index].np = of_node_get(np);
legacy_serial_infos[index].clock = clock;
@@ -107,6 +108,32 @@ static int __init add_legacy_port(struct
return index;
}
+static int __init add_legacy_soc_port(struct device_node *np,
+ struct device_node *soc_dev)
+{
+ phys_addr_t addr;
+ u32 *addrp;
+ unsigned int flags = UPF_BOOT_AUTOCONF | UPF_SKIP_TEST | UPF_SHARE_IRQ;
+
+ /* We only support ports that have a clock frequency properly
+ * encoded in the device-tree.
+ */
+ if (get_property(np, "clock-frequency", NULL) == NULL)
+ return -1;
+
+ /* Get the address */
+ addrp = of_get_address(soc_dev, 0, NULL, NULL);
+ if (addrp == NULL)
+ return -1;
+
+ addr = of_translate_address(soc_dev, addrp);
+
+ /* Add port, irq will be dealt with later. We passed a translated
+ * IO port value. It will be fixed up later along with the irq
+ */
+ return add_legacy_port(np, -1, UPIO_MEM, addr, addr, NO_IRQ, flags);
+}
+
static int __init add_legacy_isa_port(struct device_node *np,
struct device_node *isa_bridge)
{
@@ -137,7 +164,7 @@ static int __init add_legacy_isa_port(st
taddr = of_translate_address(np, reg);
/* Add port, irq will be dealt with later */
- return add_legacy_port(np, index, UPIO_PORT, reg[1], taddr, NO_IRQ);
+ return add_legacy_port(np, index, UPIO_PORT, reg[1], taddr, NO_IRQ, UPF_BOOT_AUTOCONF);
}
@@ -204,7 +231,7 @@ static int __init add_legacy_pci_port(st
/* Add port, irq will be dealt with later. We passed a translated
* IO port value. It will be fixed up later along with the irq
*/
- return add_legacy_port(np, index, iotype, base, addr, NO_IRQ);
+ return add_legacy_port(np, index, iotype, base, addr, NO_IRQ, UPF_BOOT_AUTOCONF);
}
/*
@@ -218,7 +245,7 @@ static int __init add_legacy_pci_port(st
*/
void __init find_legacy_serial_ports(void)
{
- struct device_node *np, *stdout;
+ struct device_node *np, *stdout = NULL;
char *path;
int index;
@@ -226,13 +253,23 @@ void __init find_legacy_serial_ports(voi
/* Now find out if one of these is out firmware console */
path = (char *)get_property(of_chosen, "linux,stdout-path", NULL);
- if (path == NULL) {
+ if (path != NULL) {
+ stdout = of_find_node_by_path(path);
+ if (stdout)
+ DBG("stdout is %s\n", stdout->full_name);
+ } else {
DBG(" no linux,stdout-path !\n");
- return;
}
- stdout = of_find_node_by_path(path);
- if (stdout) {
- DBG("stdout is %s\n", stdout->full_name);
+
+ /* First fill our array with SOC ports */
+ for (np = NULL; (np = of_find_compatible_node(np, "serial", "ns16550")) != NULL;) {
+ struct device_node *soc = of_get_parent(np);
+ if (soc && !strcmp(soc->type, "soc")) {
+ index = add_legacy_soc_port(np, np);
+ if (index >= 0 && np == stdout)
+ legacy_serial_console = index;
+ }
+ of_node_put(soc);
}
/* First fill our array with ISA ports */
@@ -437,6 +474,11 @@ static int __init check_legacy_serial_co
DBG(" of_chosen is NULL !\n");
return -ENODEV;
}
+
+ if (legacy_serial_console < 0) {
+ DBG(" legacy_serial_console not found !\n");
+ return -ENODEV;
+ }
/* We are getting a weird phandle from OF ... */
/* ... So use the full path instead */
name = (char *)get_property(of_chosen, "linux,stdout-path", NULL);
^ permalink raw reply related
* [PATCH] powerpc: Loosen udbg_probe_uart_speed sanity checking
From: Kumar Gala @ 2005-12-20 22:16 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc64-dev, linuxppc-dev
The checking of the baudrate in udbg_probe_uart_speed was
too tight and would cause reporting back of the default
baud rate in cases where the computed speed was valid.
Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
---
commit 8bec94b3bb35c0273fbab5a6aa477ec71a4d1fab
tree c2dde72aa75a3d807a918556e97b21723c10267b
parent a86f866f7b31e01c729ee7498228c547a51d8514
author Kumar Gala <galak@kernel.crashing.org> Tue, 20 Dec 2005 16:17:13 -0600
committer Kumar Gala <galak@kernel.crashing.org> Tue, 20 Dec 2005 16:17:13 -0600
arch/powerpc/kernel/udbg_16550.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch/powerpc/kernel/udbg_16550.c b/arch/powerpc/kernel/udbg_16550.c
index e58c048..7541bf4 100644
--- a/arch/powerpc/kernel/udbg_16550.c
+++ b/arch/powerpc/kernel/udbg_16550.c
@@ -137,7 +137,7 @@ unsigned int udbg_probe_uart_speed(void
speed = (clock / prescaler) / (divisor * 16);
/* sanity check */
- if (speed < 9600 || speed > 115200)
+ if (speed < 0 || speed > (clock / 16))
speed = 9600;
return speed;
^ permalink raw reply related
* Re: [PATCH 0/9] Some Freescale MPC52xx related updates
From: Sylvain Munaut @ 2005-12-20 21:36 UTC (permalink / raw)
To: Kumar Gala; +Cc: Andrew Morton, Tom Rini, Linux PPC Embedded
In-Reply-To: <Pine.LNX.4.44.0512201452570.26351-100000@gate.crashing.org>
Kumar Gala wrote:
>>Hello Andrew & all,
>>
>>
>>This set of patches contains misc updates that are in my local
>>tree since sometimes now and I think they're good to go upstream.
>>
>>They've been posted separatly on the ppc mailing list at some point
>>and tested by several people. So far I received no negative feedback.
>>Most are trivial compile fix, small improvements, ...
>>
>>
>>Thanks,
>>
>> Sylvain Munaut
>
>
> Sylvain, its been a while.
Yes, indeed ... I'm trying to catch up.
> We have started to a powerpc.git tree that
> Paul is maintaining rather than forwarding patches to Andrew.
>
> So you may want to let Paul know about these 52xx patches for him to queue
> them up in the powerpc.git tree.
I knew it ... I can't seem to get it right the first time each time I
miss something when pushing patches ...
I'll send the patch series to Paul right now.
Sylvain
^ permalink raw reply
* Re: POSIX High Resolution Timers in LinuxPPC 2.4
From: Geoff Levand @ 2005-12-19 22:56 UTC (permalink / raw)
To: David Jander; +Cc: Martin, Tim, linuxppc-embedded
In-Reply-To: <200512191039.58149.david.jander@protonic.nl>
David Jander wrote:
> Hi Tim,
>
> On Friday 16 December 2005 23:34, Martin, Tim wrote:
>
>>Could someone give me a brief history lesson on POSIX high resolution
>>timers (e.g. timer_create() function) implemented in the Linux kernel on
>>the PowerPC 405 architecture? Specifically:
>>
>>Confirm they are in the mainline 2.6 kernel now (e.g. kernel.org)?
>>
>>Were they ever a part of the "mainline" 2.4 linuxppc kernel (e.g
>>ppc.bkbits.net)?
>>
>>If no, were they ever available as a patch? The stuff at
>>sourceforge.net/projects/high-res-timers stops at 2.4.20 and looks like it
>>was only ever working for i386, not ppc.
>
>
> I asked a related question a while back, and got no answer (yet).
> I did find this though, which you might have overlooked:
> http://prdownloads.sourceforge.net/high-res-timers/ppc-hrt-2.6.10.patch?download
>
> I am equally puzzled about whether this has made it into mainstream, is about
> to, or never will. I don't even know if it actually works.
>
You would do better to inquire on the HRT mailing list:
http://lists.sourceforge.net/lists/listinfo/high-res-timers-discourse
HRT support (from http://sourceforge.net/projects/high-res-timers/) was
never accepted to mainline. It works on Ebony (PPC440), but I guess it
is OK on others since it uses the PPC time base. I recommend you get
the latest from CVS, which is against 2.6.12. Older versions have
CVS tags.
-Geoff
^ permalink raw reply
* [RFC] RTC subsystem
From: Alessandro Zummo @ 2005-12-20 21:00 UTC (permalink / raw)
Cc: linuxppc-dev, nslu2-developers, linuxppc-embedded,
linux-arm-kernel, lm-sensors
Hello,
I've posted a proposal for a new RTC subsystem
on lkml ( http://lkml.org/lkml/2005/12/20/220 ) .
I'd appreciate having feedback from anyone that could
be interested in this matter.
Thanks in advance.
--
Best regards,
Alessandro Zummo,
Tower Technologies - Turin, Italy
http://www.towertech.it
^ permalink raw reply
* Re: [PATCH 0/9] Some Freescale MPC52xx related updates
From: Kumar Gala @ 2005-12-20 20:54 UTC (permalink / raw)
To: Sylvain Munaut; +Cc: Andrew Morton, Tom Rini, Linux PPC Embedded
In-Reply-To: <0.20051220_213752_1ebc_tnt@patchsend.246tNt.com>
> Hello Andrew & all,
>
>
> This set of patches contains misc updates that are in my local
> tree since sometimes now and I think they're good to go upstream.
>
> They've been posted separatly on the ppc mailing list at some point
> and tested by several people. So far I received no negative feedback.
> Most are trivial compile fix, small improvements, ...
>
>
> Thanks,
>
> Sylvain Munaut
Sylvain, its been a while. We have started to a powerpc.git tree that
Paul is maintaining rather than forwarding patches to Andrew.
So you may want to let Paul know about these 52xx patches for him to queue
them up in the powerpc.git tree.
- kumar
^ permalink raw reply
* console on POWER4 not working with 2.6.15
From: Olaf Hering @ 2005-12-20 20:45 UTC (permalink / raw)
To: linux-kernel, linuxppc-dev
The connection of ttyS0 to /dev/console doesnt seem to work anymore mit
2.6.15-rc5+6 on a POWER4 p630 in fullsystempartition mode, no HMC
connected. It works with 2.6.14.4.
I tested 2.6.15-rc6 arch/powerpc/configs/ppc64_defconfig.
Our SLES9 /init script in initramfs doesnt print anything with 2.6.15
after 'Freeing unused kernel memory: 360k freed'. But it does print its
banner with 2.6.14.4. Other system with hvc console appear to work,
like JS20 or some POWER5 boxes.
So this regression seems to be local to ttyS0. The bootlog shows that
the firmware stdout device is properly detected at "COM1".
I will try older rc kernels now, but I may lose remote control of the
system.
The system appears to boot a bit into the init scripts, as the (unknown)
TIOCGDEV ioctl indicates. sysrq is not recognized. Forcing the system
into xmon shows all cpus are idle. Triggering a sysrq t via PS/2
keyboard shows this:
boot S 000000000fe3637c 9680 2288 2287 2301 (NOTLB)
Call Trace:
[C00000003FE7F950] [C00000000061D850] nfs_v2_clientops+0x90/0x118 (unreliable)
[C00000003FE7FB20] [C0000000000242C0] .__switch_to+0x140/0x164
[C00000003FE7FBB0] [C00000000049C3C4] .schedule+0x664/0x7ac
[C00000003FE7FC80] [C00000000005C284] .do_wait+0xecc/0x10a0
[C00000003FE7FDC0] [C000000000012468] .compat_sys_waitpid+0x18/0x2c
[C00000003FE7FE30] [C000000000008600] syscall_exit+0x0/0x18
stty S 000000000ff6f520 12512 2301 2288 (NOTLB)
Call Trace:
[C0000001FEF0B480] [C0000000000242C0] .__switch_to+0x140/0x164
[C0000001FEF0B510] [C00000000049C3C4] .schedule+0x664/0x7ac
[C0000001FEF0B5E0] [C00000000049CC14] .schedule_timeout+0x40/0xec
[C0000001FEF0B6B0] [C000000000264D00] .tty_wait_until_sent+0x114/0x198
[C0000001FEF0B7A0] [C000000000264FF4] .set_termios+0x270/0x2b8
[C0000001FEF0B860] [C0000000002657F8] .n_tty_ioctl+0x7bc/0xc88
[C0000001FEF0B940] [C000000000261460] .tty_ioctl+0x11b8/0x1214
[C0000001FEF0BB70] [C0000000000CCC84] .do_ioctl+0xd4/0x108
[C0000001FEF0BC00] [C0000000000CD134] .vfs_ioctl+0x47c/0x4b0
[C0000001FEF0BCB0] [C0000000000CD1BC] .sys_ioctl+0x54/0x94
[C0000001FEF0BD60] [C0000000000EE10C] .compat_sys_ioctl+0x338/0x3bc
[C0000001FEF0BE30] [C000000000008600] syscall_exit+0x0/0x18
....
Elapsed time since release of system processors: 1 mins 37 secs
Config file read, 384 bytes
Welcome to yaboot version 1.3.11.SuSE
Enter "help" to get some basic usage information
boot: sysrq
Please wait, loading kernel...
Elf64 kernel loaded...
Loading ramdisk...
ramdisk loaded at 04400000, size: 1228 Kbytes
OF stdout device is: /pci@400000000110/isa@3/serial@i3f8
command line: root=/dev/sda4 xmon=on debug
memory layout at init:
memory_limit : 0000000000000000 (16 MB aligned)
alloc_bottom : 0000000004533000
alloc_top : 0000000030000000
alloc_top_hi : 0000000200000000
rmo_top : 0000000030000000
ram_top : 0000000200000000
Looking for displays
found display : /pci@400000000112/pci@2,6/pci@1/display@0, opening ... done
opening PHB /pci@400000000110... done
opening PHB /pci@400000000112... done
instantiating rtas at 0x000000002fd0d000 ... done
0000000000000000 : boot cpu 0000000000000000
0000000000000001 : starting cpu hw idx 0000000000000001... done
0000000000000002 : starting cpu hw idx 0000000000000002... done
0000000000000003 : starting cpu hw idx 0000000000000003... done
copying OF device tree ...
Building dt strings...
Building dt structure...
Device tree strings 0x0000000004834000 -> 0x00000000048353ac
Device tree struct 0x0000000004836000 -> 0x0000000004841000
Calling quiesce ...
returning from prom_init
Page orders: linear mapping = 24, others = 12
Found initrd at 0xc000000004400000:0xc000000004533000
trying to initialize btext ...
boot stdout isn't a display !
trying /pci@400000000112/pci@2,6/pci@1/display@0 ...
result: 0
Starting Linux PPC64 #3 SMP Tue Dec 20 13:32:44 CET 2005
-----------------------------------------------------
ppc64_pft_size = 0x0
ppc64_interrupt_controller = 0x2
platform = 0x100
physicalMemorySize = 0x200000000
ppc64_caches.dcache_line_size = 0x80
ppc64_caches.icache_line_size = 0x80
htab_address = 0xc0000001f0000000
htab_hash_mask = 0xfffff
-----------------------------------------------------
[boot]0100 MM Init
[boot]0100 MM Init Done
Linux version 2.6.15-rc6 (olaf@sweetie) (gcc version 3.3.3 (SuSE Linux)) #3 SMP Tue Dec 20 13:32:44 CET 2005
[boot]0012 Setup Arch
EEH: PCI Enhanced I/O Error Handling Enabled
PPC64 nvram contains 81920 bytes
Using default idle loop
Top of RAM: 0x200000000, Total RAM: 0x200000000
Memory hole size: 0MB
[boot]0015 Setup Done
Built 1 zonelists
Kernel command line: root=/dev/sda4 xmon=on debug
[boot]0020 XICS Init
[boot]0021 XICS Done
PID hash table entries: 4096 (order: 12, 131072 bytes)
time_init: decrementer frequency = 181.701671 MHz
time_init: processor frequency = 1453.000000 MHz
Page orders: linear mapping = 24, others = 12
Found initrd at 0xc000000004400000:0xc000000004533000
trying to initialize btext ...
boot stdout isn't a display !
trying /pci@400000000112/pci@2,6/pci@1/display@0 ...
result: 0
Starting Linux PPC64 #3 SMP Tue Dec 20 13:32:44 CET 2005
-----------------------------------------------------
ppc64_pft_size = 0x0
ppc64_interrupt_controller = 0x2
platform = 0x100
physicalMemorySize = 0x200000000
ppc64_caches.dcache_line_size = 0x80
ppc64_caches.icache_line_size = 0x80
htab_address = 0xc0000001f0000000
htab_hash_mask = 0xfffff
-----------------------------------------------------
[boot]0100 MM Init
[boot]0100 MM Init Done
Linux version 2.6.15-rc6 (olaf@sweetie) (gcc version 3.3.3 (SuSE Linux)) #3 SMP Tue Dec 20 13:32:44 CET 2005
[boot]0012 Setup Arch
EEH: PCI Enhanced I/O Error Handling Enabled
PPC64 nvram contains 81920 bytes
Using default idle loop
Top of RAM: 0x200000000, Total RAM: 0x200000000
Memory hole size: 0MB
On node 0 totalpages: 2097152
DMA zone: 2097152 pages, LIFO batch:31
DMA32 zone: 0 pages, LIFO batch:0
Normal zone: 0 pages, LIFO batch:0
HighMem zone: 0 pages, LIFO batch:0
[boot]0015 Setup Done
Built 1 zonelists
Kernel command line: root=/dev/sda4 xmon=on debug
[boot]0020 XICS Init
[boot]0021 XICS Done
PID hash table entries: 4096 (order: 12, 131072 bytes)
time_init: decrementer frequency = 181.701671 MHz
time_init: processor frequency = 1453.000000 MHz
Console: colour dummy device 80x25
Dentry cache hash table entries: 2097152 (order: 12, 16777216 bytes)
Inode-cache hash table entries: 1048576 (order: 11, 8388608 bytes)
Memory: 8087032k/8388608k available (5824k kernel code, 300928k reserved, 2028k data, 499k bss, 360k init)
Calibrating delay loop... 362.49 BogoMIPS (lpj=724992)
Mount-cache hash table entries: 256
Processor 1 found.
Processor 2 found.
Processor 3 found.
Brought up 4 CPUs
checking if image is initramfs... it is
Freeing initrd memory: 1228k freed
NET: Registered protocol family 16
PCI: Probing PCI hardware
Failed to request PCI IO region on PCI domain 0000
Using INTC for W82c105 IDE controller.
IOMMU table initialized, virtual merging enabled
ISA bridge at 0000:00:03.0
mapping IO 3fd30000000 -> d000080000000000, size: 100000
mapping IO 3fd50000000 -> d000080000100000, size: 100000
PCI: Probing PCI hardware done
Registering pmac pic with sysfs...
SCSI subsystem initialized
usbcore: registered new driver usbfs
usbcore: registered new driver hub
RTAS daemon started
RTAS: event: 99, Type: Internal Device Failure, Severity: 2
Total HugeTLB memory allocated, 0
JFS: nTxBlock = 8192, nTxLock = 65536
Initializing Cryptographic API
io scheduler noop registered
io scheduler anticipatory registered
io scheduler deadline registered
io scheduler cfq registered
matroxfb: Matrox G450 detected
PInS data found at offset 31168
PInS memtype = 4
matroxfb: 640x480x8bpp (virtual: 640x26214)
matroxfb: framebuffer at 0x3FDEC000000, mapped to 0xd000080080054000, size 16777216
Console: switching to colour frame buffer device 80x30
fb0: MATROX frame buffer device
matroxfb_crtc2: secondary head of fb0 was registered as fb1
vio_register_driver: driver hvc_console registering
HVSI: registered 0 devices
serio: i8042 AUX port at 0x60,0x64 irq 12
serio: i8042 KBD port at 0x60,0x64 irq 1
Serial: 8250/16550 driver $Revision: 1.90 $ 4 ports, IRQ sharing disabled
serial8250.0: ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A
serial8250.0: ttyS1 at I/O 0x2f8 (irq = 3) is a 16550A
serial8250.0: ttyS2 at I/O 0x898 (irq = 10) is a 16550A
Floppy drive(s): fd0 is 2.88M
FDC 0 is a National Semiconductor PC87306
RAMDISK driver initialized: 16 RAM disks of 65536K size 1024 blocksize
loop: loaded (max 8 devices)
Intel(R) PRO/1000 Network Driver - version 6.1.16-k2
Copyright (c) 1999-2005 Intel Corporation.
pcnet32.c:v1.31c 01.Nov.2005 tsbogend@alpha.franken.de
e100: Intel(R) PRO/100 Network Driver, 3.4.14-k4-NAPI
e100: Copyright(c) 1999-2005 Intel Corporation
PCI: Enabling device: (0000:21:01.0), cmd 143
e100: eth0: e100_probe: addr 0x3fd88030000, irq 101, MAC addr 00:02:55:4F:05:C7
PCI: Enabling device: (0001:21:01.0), cmd 143
e100: eth1: e100_probe: addr 0x3fde8030000, irq 133, MAC addr 00:02:55:4F:05:D7
acenic.c: v0.92 08/05/2002 Jes Sorensen, linux-acenic@SunSITE.dk
http://home.cern.ch/~jes/gige/acenic.html
PCI: Enabling device: (0000:01:01.0), cmd 142
0000:01:01.0: Alteon AceNIC Gigabit Ethernet at 0x3fd80000000, irq 99
Tigon II (Rev. 6), Firmware: 12.4.11, MAC: 00:04:ac:7c:84:ad
PCI bus width: 64 bits, speed: 66MHz, latency: 72 clks
0000:01:01.0: Firmware up and running
PCI: Enabling device: (0000:61:01.0), cmd 142
0000:61:01.0: Alteon AceNIC Gigabit Ethernet at 0x3fd90000000, irq 105
Tigon II (Rev. 6), Firmware: 12.4.11, MAC: 00:06:29:6b:17:1d
PCI bus width: 64 bits, speed: 66MHz, latency: 72 clks
0000:61:01.0: Firmware up and running
netconsole: not configured, aborting
Uniform Multi-Platform E-IDE driver Revision: 7.00alpha2
ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx
PCI: Enabling device: (0000:41:01.0), cmd 143
sym0: <1010-66> rev 0x1 at pci 0000:41:01.0 irq 103
sym0: No NVRAM, ID 7, Fast-80, LVD, parity checking
sym0: SCSI BUS has been reset.
scsi0 : sym-2.2.1
Vendor: IBM Model: IC35L036UCD210-0 Rev: S5BS
Type: Direct-Access ANSI SCSI revision: 03
target0:0:8: tagged command queuing enabled, command queue depth 16.
target0:0:8: Beginning Domain Validation
target0:0:8: asynchronous.
target0:0:8: wide asynchronous.
target0:0:8: FAST-80 WIDE SCSI 160.0 MB/s DT (12.5 ns, offset 31)
target0:0:8: FAST-80 WIDE SCSI 160.0 MB/s DT (12.5 ns, offset 31)
target0:0:8: Ending Domain Validation
Vendor: IBM Model: IC35L036UCD210-0 Rev: S5BS
Type: Direct-Access ANSI SCSI revision: 03
target0:0:9: tagged command queuing enabled, command queue depth 16.
target0:0:9: Beginning Domain Validation
target0:0:9: asynchronous.
target0:0:9: wide asynchronous.
target0:0:9: FAST-80 WIDE SCSI 160.0 MB/s DT (12.5 ns, offset 31)
target0:0:9: FAST-80 WIDE SCSI 160.0 MB/s DT (12.5 ns, offset 31)
target0:0:9: Ending Domain Validation
Vendor: IBM Model: HSBPD4E PU3SCSI Rev: 0011
Type: Enclosure ANSI SCSI revision: 02
target0:0:15: Beginning Domain Validation
0:0:15:0: phase change 6-7 6@400503a8 resid=4.
target0:0:15: asynchronous.
target0:0:15: Ending Domain Validation
PCI: Enabling device: (0000:41:01.1), cmd 143
sym1: <1010-66> rev 0x1 at pci 0000:41:01.1 irq 104
sym1: No NVRAM, ID 7, Fast-80, SE, parity checking
sym1: SCSI BUS has been reset.
scsi1 : sym-2.2.1
target1:0:0: FAST-20 WIDE SCSI 40.0 MB/s ST (50 ns, offset 31)
Vendor: HP Model: IBM-C568303030!D Rev: C209
Type: Sequential-Access ANSI SCSI revision: 02
target1:0:0: Beginning Domain Validation
target1:0:0: FAST-20 SCSI 20.0 MB/s ST (50 ns, offset 31)
target1:0:0: FAST-20 WIDE SCSI 40.0 MB/s ST (50 ns, offset 31)
1:0:0:0: ABORT operation started.
1:0:0:0: ABORT operation timed-out.
1:0:0:0: DEVICE RESET operation started.
1:0:0:0: DEVICE RESET operation complete.
target1:0:0: control msgout: c.
sym1: TARGET 0 has been reset.
1:0:0:0: ABORT operation started.
1:0:0:0: ABORT operation complete.
1:0:0:0: BUS RESET operation started.
1:0:0:0: BUS RESET operation complete.
sym1: SCSI BUS reset detected.
sym1: SCSI BUS has been reset.
target1:0:0: FAST-20 WIDE SCSI 40.0 MB/s ST (50 ns, offset 31)
target1:0:0: Wide Transfers Fail
target1:0:0: FAST-20 SCSI 20.0 MB/s ST (50 ns, offset 31)
target1:0:0: Domain Validation skipping write tests
target1:0:0: Ending Domain Validation
ipr: IBM Power RAID SCSI Device Driver version: 2.1.0 (October 31, 2005)
vio_register_driver: driver ibmvscsi registering
libata version 1.20 loaded.
st: Version 20050830, fixed bufsize 32768, s/g segs 256
st 1:0:0:0: Attached scsi tape st0<4>st0: try direct i/o: yes (alignment 512 B), max page reachable by HBA 2097152
SCSI device sda: 71096640 512-byte hdwr sectors (36401 MB)
SCSI device sda: drive cache: write through
SCSI device sda: 71096640 512-byte hdwr sectors (36401 MB)
SCSI device sda: drive cache: write through
sda: sda2 sda3 sda4
sd 0:0:8:0: Attached scsi disk sda
SCSI device sdb: 71096640 512-byte hdwr sectors (36401 MB)
SCSI device sdb: drive cache: write through
SCSI device sdb: 71096640 512-byte hdwr sectors (36401 MB)
SCSI device sdb: drive cache: write through
sdb: sdb1 sdb2
sd 0:0:9:0: Attached scsi disk sdb
sd 0:0:8:0: Attached scsi generic sg0 type 0
sd 0:0:9:0: Attached scsi generic sg1 type 0
0:0:15:0: Attached scsi generic sg2 type 13
st 1:0:0:0: Attached scsi generic sg3 type 1
ieee1394: Initialized config rom entry `ip1394'
ieee1394: raw1394: /dev/raw1394 device initialized
ohci_hcd: 2005 April 22 USB 1.1 'Open' Host Controller (OHCI) Driver (PCI)
ohci_hcd 0001:01:01.0: OHCI Host Controller
ohci_hcd 0001:01:01.0: new USB bus registered, assigned bus number 1
ohci_hcd 0001:01:01.0: irq 131, io mem 0x3fde0003000
hub 1-0:1.0: USB hub found
hub 1-0:1.0: 1 port detected
ohci_hcd 0001:01:01.1: OHCI Host Controller
ohci_hcd 0001:01:01.1: new USB bus registered, assigned bus number 2
ohci_hcd 0001:01:01.1: irq 132, io mem 0x3fde0002000
hub 2-0:1.0: USB hub found
hub 2-0:1.0: 1 port detected
ohci_hcd 0001:01:01.2: OHCI Host Controller
ohci_hcd 0001:01:01.2: new USB bus registered, assigned bus number 3
ohci_hcd 0001:01:01.2: irq 131, io mem 0x3fde0001000
hub 3-0:1.0: USB hub found
hub 3-0:1.0: 1 port detected
ohci_hcd 0001:01:01.3: OHCI Host Controller
ohci_hcd 0001:01:01.3: new USB bus registered, assigned bus number 4
ohci_hcd 0001:01:01.3: irq 132, io mem 0x3fde0000000
hub 4-0:1.0: USB hub found
hub 4-0:1.0: 1 port detected
usbcore: registered new driver hiddev
usbcore: registered new driver usbhid
/home/olaf/kernel/bugs/96313/linux-2.6.15-rc6-olh/drivers/usb/input/hid-core.c: v2.6:USB HID core driver
mice: PS/2 mouse device common for all mice
i2c /dev entries driver
md: linear personality registered as nr 1
md: raid0 personality registered as nr 2
atkbd.c: keyboard reset failed on isa0060/serio1
md: raid1 personality registered as nr 3
md: raid10 personality registered as nr 9
md: raid5 personality registered as nr 4
raid5: measuring checksumming speed
8regs : 3777.000 MB/sec
8regs_prefetch: 3726.000 MB/sec
32regs : 4717.000 MB/sec
32regs_prefetch: 3839.000 MB/sec
raid5: using function: 32regs (4717.000 MB/sec)
md: md driver 0.90.3 MAX_MD_DEVS=256, MD_SB_DISKS=27
md: bitmap version 4.39
device-mapper: 4.4.0-ioctl (2005-01-12) initialised: dm-devel@redhat.com
oprofile: using ppc64/power4 performance monitoring.
Netfilter messages via NETLINK v0.30.
NET: Registered protocol family 2
IP route cache hash table entries: 524288 (order: 10, 4194304 bytes)
TCP established hash table entries: 1048576 (order: 12, 16777216 bytes)
TCP bind hash table entries: 65536 (order: 8, 1048576 bytes)
TCP: Hash tables configured (established 1048576 bind 65536)
TCP reno registered
IPv4 over IPv4 tunneling driver
TCP bic registered
NET: Registered protocol family 1
NET: Registered protocol family 17
input: AT Raw Set 2 keyboard as /class/input/input0
Freeing unused kernel memory: 360k freed
st0: Block limits 1 - 16777215 bytes.
ReiserFS: sda4: found reiserfs format "3.6" with standard journal
ReiserFS: sda4: using ordered data mode
ReiserFS: sda4: journal params: device sda4, size 8192, journal first block 18, max trans len 1024, max batch 900, max commit age 30, max trans age 30
ReiserFS: sda4: checking transaction log (sda4)
ReiserFS: sda4: Using r5 hash to sort names
ioctl32(showconsole:2292): Unknown cmd fd(0) cmd(40045432){00} arg(ffe05a88) on /dev/console
--
short story of a lazy sysadmin:
alias appserv=wotan
^ permalink raw reply
* [PATCH 9/9] ppc32: Allows compilation of a MPC52xx kernel without PCI
From: Sylvain Munaut @ 2005-12-20 20:44 UTC (permalink / raw)
To: Andrew Morton; +Cc: Tom Rini, Sylvain Munaut, Linux PPC Embedded
In-Reply-To: <0.20051220_213752_1ebc_tnt@patchsend.246tNt.com>
ppc32: Allows compilation of a MPC52xx kernel without PCI
Some custom cards might not need PCI, without this patch,
compilation fails.
Signed-off-by: Roger Blofeld <blofeldus@yahoo.com>
Signed-off-by: Sylvain Munaut <tnt@246tNt.com>
---
commit 181a39c878aab09ba95bfd9396e8c7d7004f4c4e
tree 42106141a8a50c521a8d169bb6b364d78401e15d
parent ebf0598ce7564d4c1db16d995e609923bbb2eba8
author Sylvain Munaut <tnt@246tNt.com> Sun, 18 Dec 2005 21:27:54 +0100
committer Sylvain Munaut <tnt@246tNt.com> Sun, 18 Dec 2005 21:27:54 +0100
arch/ppc/platforms/lite5200.c | 2 ++
include/asm-ppc/io.h | 2 ++
include/asm-ppc/mpc52xx.h | 11 +++++++++++
3 files changed, 15 insertions(+), 0 deletions(-)
diff --git a/arch/ppc/platforms/lite5200.c b/arch/ppc/platforms/lite5200.c
index d44cc99..7ed52dc 100644
--- a/arch/ppc/platforms/lite5200.c
+++ b/arch/ppc/platforms/lite5200.c
@@ -196,8 +196,10 @@ platform_init(unsigned long r3, unsigned
mpc52xx_set_bat();
/* No ISA bus by default */
+#ifdef CONFIG_PCI
isa_io_base = 0;
isa_mem_base = 0;
+#endif
/* Powersave */
/* This is provided as an example on how to do it. But you
diff --git a/include/asm-ppc/io.h b/include/asm-ppc/io.h
index 84ac6e2..df9cf6e 100644
--- a/include/asm-ppc/io.h
+++ b/include/asm-ppc/io.h
@@ -27,6 +27,8 @@
#if defined(CONFIG_4xx)
#include <asm/ibm4xx.h>
+#elif defined(CONFIG_PPC_MPC52xx)
+#include <asm/mpc52xx.h>
#elif defined(CONFIG_8xx)
#include <asm/mpc8xx.h>
#elif defined(CONFIG_8260)
diff --git a/include/asm-ppc/mpc52xx.h b/include/asm-ppc/mpc52xx.h
index 04d5630..a055e07 100644
--- a/include/asm-ppc/mpc52xx.h
+++ b/include/asm-ppc/mpc52xx.h
@@ -29,6 +29,17 @@ struct pt_regs;
#endif /* __ASSEMBLY__ */
+#ifdef CONFIG_PCI
+#define _IO_BASE isa_io_base
+#define _ISA_MEM_BASE isa_mem_base
+#define PCI_DRAM_OFFSET pci_dram_offset
+#else
+#define _IO_BASE 0
+#define _ISA_MEM_BASE 0
+#define PCI_DRAM_OFFSET 0
+#endif
+
+
/* ======================================================================== */
/* PPC Sys devices definition */
/* ======================================================================== */
^ permalink raw reply related
* [PATCH 8/9] ppc32: Fix MPC52xx PCI init in cas the bootloader didn't do it
From: Sylvain Munaut @ 2005-12-20 20:44 UTC (permalink / raw)
To: Andrew Morton; +Cc: Tom Rini, Sylvain Munaut, Linux PPC Embedded
In-Reply-To: <0.20051220_213752_1ebc_tnt@patchsend.246tNt.com>
ppc32: Fix MPC52xx PCI init in cas the bootloader didn't do it
We were counting on the bootloader to init some stuff, like get
the bus out of reset and enable accesses.
Signed-off-by: Sylvain Munaut <tnt@246tNt.com>
---
commit ebf0598ce7564d4c1db16d995e609923bbb2eba8
tree 3ba738b8bf64ebe609c5f8301f87b55d25c2d9fd
parent 20734ce8dc6fafd40c421bd275712d7bb6124d20
author Sylvain Munaut <tnt@246tNt.com> Sun, 18 Dec 2005 20:09:13 +0100
committer Sylvain Munaut <tnt@246tNt.com> Sun, 18 Dec 2005 20:09:13 +0100
arch/ppc/syslib/mpc52xx_pci.c | 10 ++++++----
1 files changed, 6 insertions(+), 4 deletions(-)
diff --git a/arch/ppc/syslib/mpc52xx_pci.c b/arch/ppc/syslib/mpc52xx_pci.c
index 2c5e6dd..313c96e 100644
--- a/arch/ppc/syslib/mpc52xx_pci.c
+++ b/arch/ppc/syslib/mpc52xx_pci.c
@@ -154,9 +154,12 @@ static struct pci_ops mpc52xx_pci_ops =
static void __init
mpc52xx_pci_setup(struct mpc52xx_pci __iomem *pci_regs)
{
+ u32 tmp;
/* Setup control regs */
- /* Nothing to do afaik */
+ tmp = in_be32(&pci_regs->scr);
+ tmp |= PCI_COMMAND_MASTER | PCI_COMMAND_MEMORY;
+ out_be32(&pci_regs->scr, tmp);
/* Setup windows */
out_be32(&pci_regs->iw0btar, MPC52xx_PCI_IWBTAR_TRANSLATION(
@@ -197,13 +200,12 @@ mpc52xx_pci_setup(struct mpc52xx_pci __i
/* Not necessary and can be a bad thing if for example the bootloader
is displaying a splash screen or ... Just left here for
documentation purpose if anyone need it */
-#if 0
- u32 tmp;
tmp = in_be32(&pci_regs->gscr);
+#if 0
out_be32(&pci_regs->gscr, tmp | MPC52xx_PCI_GSCR_PR);
udelay(50);
- out_be32(&pci_regs->gscr, tmp);
#endif
+ out_be32(&pci_regs->gscr, tmp & ~MPC52xx_PCI_GSCR_PR);
}
static void
^ permalink raw reply related
* [PATCH 7/9] ppc32: Fix MPC52xx configuration space access
From: Sylvain Munaut @ 2005-12-20 20:43 UTC (permalink / raw)
To: Andrew Morton; +Cc: Tom Rini, Sylvain Munaut, Linux PPC Embedded
In-Reply-To: <0.20051220_213752_1ebc_tnt@patchsend.246tNt.com>
ppc32: Fix MPC52xx configuration space access
This patch takes care of an errata of the MPC5200 by avoiding 32 bits
access in type 1 configuration accesses. All others accesses are still
32 bits wide. It also adds some mb() since the simple out_be(...) are
not sufficient in this case.
Signed-off-by: Sylvain Munaut <tnt@246tNt.com>
---
commit 20734ce8dc6fafd40c421bd275712d7bb6124d20
tree e53eeedbe423ecf718313dd2173031d456b4f3e8
parent 7834134483a1ae663b805714fcd741c1caf41171
author Sylvain Munaut <tnt@246tNt.com> Sun, 18 Dec 2005 14:52:51 +0100
committer Sylvain Munaut <tnt@246tNt.com> Sun, 18 Dec 2005 14:52:51 +0100
arch/ppc/syslib/mpc52xx_pci.c | 81 ++++++++++++++++++++++++++++++++++-------
1 files changed, 68 insertions(+), 13 deletions(-)
diff --git a/arch/ppc/syslib/mpc52xx_pci.c b/arch/ppc/syslib/mpc52xx_pci.c
index e6cb3e2..2c5e6dd 100644
--- a/arch/ppc/syslib/mpc52xx_pci.c
+++ b/arch/ppc/syslib/mpc52xx_pci.c
@@ -24,6 +24,12 @@
#include <asm/machdep.h>
+/* This macro is defined to activate the workaround for the bug
+ 435 of the MPC5200 (L25R). With it activated, we don't do any
+ 32 bits configuration access during type-1 cycles */
+#define MPC5200_BUG_435_WORKAROUND
+
+
static int
mpc52xx_pci_read_config(struct pci_bus *bus, unsigned int devfn,
int offset, int len, u32 *val)
@@ -40,17 +46,39 @@ mpc52xx_pci_read_config(struct pci_bus *
((bus->number - hose->bus_offset) << 16) |
(devfn << 8) |
(offset & 0xfc));
+ mb();
- value = in_le32(hose->cfg_data);
+#ifdef MPC5200_BUG_435_WORKAROUND
+ if (bus->number != hose->bus_offset) {
+ switch (len) {
+ case 1:
+ value = in_8(((u8 __iomem *)hose->cfg_data) + (offset & 3));
+ break;
+ case 2:
+ value = in_le16(((u16 __iomem *)hose->cfg_data) + ((offset>>1) & 1));
+ break;
+
+ default:
+ value = in_le16((u16 __iomem *)hose->cfg_data) |
+ (in_le16(((u16 __iomem *)hose->cfg_data) + 1) << 16);
+ break;
+ }
+ }
+ else
+#endif
+ {
+ value = in_le32(hose->cfg_data);
- if (len != 4) {
- value >>= ((offset & 0x3) << 3);
- value &= 0xffffffff >> (32 - (len << 3));
+ if (len != 4) {
+ value >>= ((offset & 0x3) << 3);
+ value &= 0xffffffff >> (32 - (len << 3));
+ }
}
*val = value;
out_be32(hose->cfg_addr, 0);
+ mb();
return PCIBIOS_SUCCESSFUL;
}
@@ -71,21 +99,48 @@ mpc52xx_pci_write_config(struct pci_bus
((bus->number - hose->bus_offset) << 16) |
(devfn << 8) |
(offset & 0xfc));
+ mb();
- if (len != 4) {
- value = in_le32(hose->cfg_data);
+#ifdef MPC5200_BUG_435_WORKAROUND
+ if (bus->number != hose->bus_offset) {
+ switch (len) {
+ case 1:
+ out_8(((u8 __iomem *)hose->cfg_data) +
+ (offset & 3), val);
+ break;
+ case 2:
+ out_le16(((u16 __iomem *)hose->cfg_data) +
+ ((offset>>1) & 1), val);
+ break;
+
+ default:
+ out_le16((u16 __iomem *)hose->cfg_data,
+ (u16)val);
+ out_le16(((u16 __iomem *)hose->cfg_data) + 1,
+ (u16)(val>>16));
+ break;
+ }
+ }
+ else
+#endif
+ {
+ if (len != 4) {
+ value = in_le32(hose->cfg_data);
+
+ offset = (offset & 0x3) << 3;
+ mask = (0xffffffff >> (32 - (len << 3)));
+ mask <<= offset;
- offset = (offset & 0x3) << 3;
- mask = (0xffffffff >> (32 - (len << 3)));
- mask <<= offset;
+ value &= ~mask;
+ val = value | ((val << offset) & mask);
+ }
- value &= ~mask;
- val = value | ((val << offset) & mask);
+ out_le32(hose->cfg_data, val);
}
-
- out_le32(hose->cfg_data, val);
+ mb();
out_be32(hose->cfg_addr, 0);
+ mb();
return PCIBIOS_SUCCESSFUL;
}
^ permalink raw reply related
* [PATCH 6/9] ppc32: Remove __init qualifier from mpc52xx pci resources fixups
From: Sylvain Munaut @ 2005-12-20 20:43 UTC (permalink / raw)
To: Andrew Morton; +Cc: Tom Rini, Sylvain Munaut, Linux PPC Embedded
In-Reply-To: <0.20051220_213752_1ebc_tnt@patchsend.246tNt.com>
ppc32: Remove __init qualifier from mpc52xx pci resources fixups
The mpc52xx_pci_fixup_resources is not only called at init but also
when there is a pci hotplug like when a cardbus card is plugged in.
So that function is needed after init too.
Thanks to Asier Llano Palacios for reporting this.
Signed-off-by: Sylvain Munaut <tnt@246tNt.com>
---
commit 7834134483a1ae663b805714fcd741c1caf41171
tree 56da4218fa2a0bd1541b7743e79415fc48715ba1
parent 0311bddd40fe347ea69a5659f02e1beb8fe96ea8
author Sylvain Munaut <tnt@246tNt.com> Sun, 18 Dec 2005 11:48:56 +0100
committer Sylvain Munaut <tnt@246tNt.com> Sun, 18 Dec 2005 11:48:56 +0100
arch/ppc/syslib/mpc52xx_pci.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch/ppc/syslib/mpc52xx_pci.c b/arch/ppc/syslib/mpc52xx_pci.c
index 4ac1908..e6cb3e2 100644
--- a/arch/ppc/syslib/mpc52xx_pci.c
+++ b/arch/ppc/syslib/mpc52xx_pci.c
@@ -151,7 +151,7 @@ mpc52xx_pci_setup(struct mpc52xx_pci __i
#endif
}
-static void __init
+static void
mpc52xx_pci_fixup_resources(struct pci_dev *dev)
{
int i;
^ permalink raw reply related
* [PATCH 5/9] ppc32: Modify Freescale MPC52xx IRQ mapping to _not_ use irq 0
From: Sylvain Munaut @ 2005-12-20 20:42 UTC (permalink / raw)
To: Andrew Morton; +Cc: Tom Rini, Sylvain Munaut, Linux PPC Embedded
In-Reply-To: <0.20051220_213752_1ebc_tnt@patchsend.246tNt.com>
ppc32: Modify Freescale MPC52xx IRQ mapping to _not_ use irq 0
AFAIK IRQ number 0 is a perfectly valid IRQ number. But it seems there
are numerous places where it's considered to be invalid or "no irq" value.
Since that value is problematic, the IRQ mapping is changed to not
use it.
Signed-off-by: Sylvain Munaut <tnt@246tNt.com>
---
commit 0311bddd40fe347ea69a5659f02e1beb8fe96ea8
tree 16003ab98c67face9c25bdb247e241d88dd596f5
parent ae62fed2708efa333d41f7b36893e5fdbd0f6730
author Sylvain Munaut <tnt@246tNt.com> Sun, 18 Dec 2005 11:20:17 +0100
committer Sylvain Munaut <tnt@246tNt.com> Sun, 18 Dec 2005 11:20:17 +0100
include/asm-ppc/mpc52xx.h | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/include/asm-ppc/mpc52xx.h b/include/asm-ppc/mpc52xx.h
index e5f80c2..04d5630 100644
--- a/include/asm-ppc/mpc52xx.h
+++ b/include/asm-ppc/mpc52xx.h
@@ -107,7 +107,7 @@ enum ppc_sys_devices {
#define MPC52xx_SDMA_IRQ_NUM 17
#define MPC52xx_PERP_IRQ_NUM 23
-#define MPC52xx_CRIT_IRQ_BASE 0
+#define MPC52xx_CRIT_IRQ_BASE 1
#define MPC52xx_MAIN_IRQ_BASE (MPC52xx_CRIT_IRQ_BASE + MPC52xx_CRIT_IRQ_NUM)
#define MPC52xx_SDMA_IRQ_BASE (MPC52xx_MAIN_IRQ_BASE + MPC52xx_MAIN_IRQ_NUM)
#define MPC52xx_PERP_IRQ_BASE (MPC52xx_SDMA_IRQ_BASE + MPC52xx_SDMA_IRQ_NUM)
^ permalink raw reply related
* [PATCH 4/9] ppc32: Fix static IO mapping for Freescale MPC52xx
From: Sylvain Munaut @ 2005-12-20 20:42 UTC (permalink / raw)
To: Andrew Morton; +Cc: Tom Rini, Sylvain Munaut, Linux PPC Embedded
In-Reply-To: <0.20051220_213752_1ebc_tnt@patchsend.246tNt.com>
ppc32: Fix static IO mapping for Freescale MPC52xx
The current iomapping used MBAR_SIZE for the size argument
of io_block_mapping, resulting in a call to setbat with a
size argument of 64k which is invalid.
This patch correct this and maps the whole 0xf0000000->0xffffffff
range so that devices on the local bus are also included in
the BAT mapping.
Thanks to Bernhard Kuhn from Metrowerks for pointing this out.
Signed-off-by: Sylvain Munaut <tnt@246tNt.com>
---
commit ae62fed2708efa333d41f7b36893e5fdbd0f6730
tree a1a4da53edb2f235be6658558eeb606a0b2580e9
parent 1661f915e8bd58e52fe3326e038efe74068702e0
author Sylvain Munaut <tnt@246tNt.com> Sun, 18 Dec 2005 11:13:15 +0100
committer Sylvain Munaut <tnt@246tNt.com> Sun, 18 Dec 2005 11:13:15 +0100
arch/ppc/syslib/mpc52xx_setup.c | 6 ++++--
1 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/arch/ppc/syslib/mpc52xx_setup.c b/arch/ppc/syslib/mpc52xx_setup.c
index bb23745..a4a4b02 100644
--- a/arch/ppc/syslib/mpc52xx_setup.c
+++ b/arch/ppc/syslib/mpc52xx_setup.c
@@ -84,9 +84,11 @@ mpc52xx_set_bat(void)
void __init
mpc52xx_map_io(void)
{
- /* Here we only map the MBAR */
+ /* Here we map the MBAR and the whole upper zone. MBAR is only
+ 64k but we can't map only 64k with BATs. Map the whole
+ 0xf0000000 range is ok and helps eventual lpb devices placed there */
io_block_mapping(
- MPC52xx_MBAR_VIRT, MPC52xx_MBAR, MPC52xx_MBAR_SIZE, _PAGE_IO);
+ MPC52xx_MBAR_VIRT, MPC52xx_MBAR, 0x10000000, _PAGE_IO);
}
^ permalink raw reply related
* [PATCH 3/9] ppc32/serial: Change mpc52xx_uart.c to use the Low Density Serial port major
From: Sylvain Munaut @ 2005-12-20 20:41 UTC (permalink / raw)
To: Andrew Morton; +Cc: Tom Rini, Sylvain Munaut, Linux PPC Embedded
In-Reply-To: <0.20051220_213752_1ebc_tnt@patchsend.246tNt.com>
ppc32/serial: Change mpc52xx_uart.c to use the Low Density Serial port major
Before this patch we were just using the "classic" /dev/ttySx devices.
However when another on the system is loaded that uses those (like drivers
for serial PCMCIA), that creates a conflict for the minors. Therefore, we
now use /dev/ttyPSC[0:5] (note the 0-based numbering !) with some minors
we've been assigned in the "Low Density Serial port major"
Signed-off-by: Sylvain Munaut <tnt@246tNt.com>
---
commit 1661f915e8bd58e52fe3326e038efe74068702e0
tree 04215b96380f2d7d218a223d837b9eabe2f120f4
parent c83b03a94291bdd952c6b1b20ab15981456e8625
author Sylvain Munaut <tnt@246tNt.com> Sat, 17 Dec 2005 23:21:16 +0100
committer Sylvain Munaut <tnt@246tNt.com> Sat, 17 Dec 2005 23:21:16 +0100
drivers/serial/mpc52xx_uart.c | 26 +++++++++++++++-----------
1 files changed, 15 insertions(+), 11 deletions(-)
diff --git a/drivers/serial/mpc52xx_uart.c b/drivers/serial/mpc52xx_uart.c
index 4dcf031..1288d62 100644
--- a/drivers/serial/mpc52xx_uart.c
+++ b/drivers/serial/mpc52xx_uart.c
@@ -37,11 +37,11 @@
* by the bootloader or in the platform init code.
*
* The idx field must be equal to the PSC index ( e.g. 0 for PSC1, 1 for PSC2,
- * and so on). So the PSC1 is mapped to /dev/ttyS0, PSC2 to /dev/ttyS1 and so
- * on. But be warned, it's an ABSOLUTE REQUIREMENT ! This is needed mainly for
- * the console code : without this 1:1 mapping, at early boot time, when we are
- * parsing the kernel args console=ttyS?, we wouldn't know wich PSC it will be
- * mapped to.
+ * and so on). So the PSC1 is mapped to /dev/ttyPSC0, PSC2 to /dev/ttyPSC1 and
+ * so on. But be warned, it's an ABSOLUTE REQUIREMENT ! This is needed mainly
+ * fpr the console code : without this 1:1 mapping, at early boot time, when we
+ * are parsing the kernel args console=ttyPSC?, we wouldn't know wich PSC it
+ * will be mapped to.
*/
#include <linux/config.h>
@@ -65,6 +65,10 @@
#include <linux/serial_core.h>
+/* We've been assigned a range on the "Low-density serial ports" major */
+#define SERIAL_PSC_MAJOR 204
+#define SERIAL_PSC_MINOR 148
+
#define ISR_PASS_LIMIT 256 /* Max number of iteration in the interrupt */
@@ -671,12 +675,12 @@ mpc52xx_console_setup(struct console *co
static struct uart_driver mpc52xx_uart_driver;
static struct console mpc52xx_console = {
- .name = "ttyS",
+ .name = "ttyPSC",
.write = mpc52xx_console_write,
.device = uart_console_device,
.setup = mpc52xx_console_setup,
.flags = CON_PRINTBUFFER,
- .index = -1, /* Specified on the cmdline (e.g. console=ttyS0 ) */
+ .index = -1, /* Specified on the cmdline (e.g. console=ttyPSC0 ) */
.data = &mpc52xx_uart_driver,
};
@@ -703,10 +707,10 @@ console_initcall(mpc52xx_console_init);
static struct uart_driver mpc52xx_uart_driver = {
.owner = THIS_MODULE,
.driver_name = "mpc52xx_psc_uart",
- .dev_name = "ttyS",
- .devfs_name = "ttyS",
- .major = TTY_MAJOR,
- .minor = 64,
+ .dev_name = "ttyPSC",
+ .devfs_name = "ttyPSC",
+ .major = SERIAL_PSC_MAJOR,
+ .minor = SERIAL_PSC_MINOR,
.nr = MPC52xx_PSC_MAXNUM,
.cons = MPC52xx_PSC_CONSOLE,
};
^ permalink raw reply related
* [PATCH 2/9] ppc32/serial: Fix compiler errors with GCC 4.x in mpc52xx_uart.c
From: Sylvain Munaut @ 2005-12-20 20:41 UTC (permalink / raw)
To: Andrew Morton; +Cc: Tom Rini, Sylvain Munaut, Linux PPC Embedded
In-Reply-To: <0.20051220_213752_1ebc_tnt@patchsend.246tNt.com>
ppc32/serial: Fix compiler errors with GCC 4.x in mpc52xx_uart.c
Signed-off-by: Wolfgang Denk <wd@denx.de>
Signed-off-by: Sylvain Munaut <tnt@246tNt.com>
---
commit c83b03a94291bdd952c6b1b20ab15981456e8625
tree 81e1121a440a4624a4cd7f112fe44fca438ee140
parent 144f9d12ec7d04b38f83a131c4e544f78d2d47b2
author Sylvain Munaut <tnt@246tNt.com> Sat, 17 Dec 2005 23:12:39 +0100
committer Sylvain Munaut <tnt@246tNt.com> Sat, 17 Dec 2005 23:12:39 +0100
drivers/serial/mpc52xx_uart.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/serial/mpc52xx_uart.c b/drivers/serial/mpc52xx_uart.c
index b8727d9..4dcf031 100644
--- a/drivers/serial/mpc52xx_uart.c
+++ b/drivers/serial/mpc52xx_uart.c
@@ -668,7 +668,7 @@ mpc52xx_console_setup(struct console *co
}
-extern struct uart_driver mpc52xx_uart_driver;
+static struct uart_driver mpc52xx_uart_driver;
static struct console mpc52xx_console = {
.name = "ttyS",
^ permalink raw reply related
* [PATCH 1/9] ppc32: Remove useless file arch/ppc/platforms/mpc5200.c
From: Sylvain Munaut @ 2005-12-20 20:40 UTC (permalink / raw)
To: Andrew Morton; +Cc: Tom Rini, Sylvain Munaut, Linux PPC Embedded
In-Reply-To: <0.20051220_213752_1ebc_tnt@patchsend.246tNt.com>
ppc32: Remove useless file arch/ppc/platforms/mpc5200.c
That file is a left-over of the 'old' OCP model that
should have been erased during the change to platform
model but I forgot it ...
Signed-off-by: Sylvain Munaut <tnt@246tNt.com>
---
commit 144f9d12ec7d04b38f83a131c4e544f78d2d47b2
tree 629ebc02993d06ff02b87e2d0effb257ef842328
parent 48ea753075aa15699bd5fac26faa08431aaa697b
author Sylvain Munaut <tnt@246tNt.com> Sat, 17 Dec 2005 23:03:25 +0100
committer Sylvain Munaut <tnt@246tNt.com> Sat, 17 Dec 2005 23:03:25 +0100
arch/ppc/platforms/mpc5200.c | 53 ------------------------------------------
1 files changed, 0 insertions(+), 53 deletions(-)
diff --git a/arch/ppc/platforms/mpc5200.c b/arch/ppc/platforms/mpc5200.c
deleted file mode 100644
index a58db43..0000000
--- a/arch/ppc/platforms/mpc5200.c
+++ /dev/null
@@ -1,53 +0,0 @@
-/*
- * arch/ppc/platforms/mpc5200.c
- *
- * OCP Definitions for the boards based on MPC5200 processor. Contains
- * definitions for every common peripherals. (Mostly all but PSCs)
- *
- * Maintainer : Sylvain Munaut <tnt@246tNt.com>
- *
- * Copyright 2004 Sylvain Munaut <tnt@246tNt.com>
- *
- * This file is licensed under the terms of the GNU General Public License
- * version 2. This program is licensed "as is" without any warranty of any
- * kind, whether express or implied.
- */
-
-#include <asm/ocp.h>
-#include <asm/mpc52xx.h>
-
-
-static struct ocp_fs_i2c_data mpc5200_i2c_def = {
- .flags = FS_I2C_CLOCK_5200,
-};
-
-
-/* Here is the core_ocp struct.
- * With all the devices common to all board. Even if port multiplexing is
- * not setup for them (if the user don't want them, just don't select the
- * config option). The potentially conflicting devices (like PSCs) goes in
- * board specific file.
- */
-struct ocp_def core_ocp[] = {
- {
- .vendor = OCP_VENDOR_FREESCALE,
- .function = OCP_FUNC_IIC,
- .index = 0,
- .paddr = MPC52xx_I2C1,
- .irq = OCP_IRQ_NA, /* MPC52xx_IRQ_I2C1 - Buggy */
- .pm = OCP_CPM_NA,
- .additions = &mpc5200_i2c_def,
- },
- {
- .vendor = OCP_VENDOR_FREESCALE,
- .function = OCP_FUNC_IIC,
- .index = 1,
- .paddr = MPC52xx_I2C2,
- .irq = OCP_IRQ_NA, /* MPC52xx_IRQ_I2C2 - Buggy */
- .pm = OCP_CPM_NA,
- .additions = &mpc5200_i2c_def,
- },
- { /* Terminating entry */
- .vendor = OCP_VENDOR_INVALID
- }
-};
^ permalink raw reply related
* [PATCH 0/9] Some Freescale MPC52xx related updates
From: Sylvain Munaut @ 2005-12-20 20:40 UTC (permalink / raw)
To: Andrew Morton; +Cc: Tom Rini, Sylvain Munaut, Linux PPC Embedded
Hello Andrew & all,
This set of patches contains misc updates that are in my local
tree since sometimes now and I think they're good to go upstream.
They've been posted separatly on the ppc mailing list at some point
and tested by several people. So far I received no negative feedback.
Most are trivial compile fix, small improvements, ...
Thanks,
Sylvain Munaut
^ permalink raw reply
* Re: TLB preloading on 8xx
From: Dan Malek @ 2005-12-20 19:45 UTC (permalink / raw)
To: Marcelo Tosatti; +Cc: linux-ppc-embedded
In-Reply-To: <20051220173730.GB6404@dmt.cnet>
On Dec 20, 2005, at 12:37 PM, Marcelo Tosatti wrote:
> Sum up the costs of disabling interrupts and disabling translation,
> and you
> end up with a slow dog. Damn, the TLB exceptions are indeed efficient.
Like I've always said, make the TLB miss exception path very
short and efficient. You have to consider the total system impact
of running this code, which includes replacing lots of cache
lines that will affect the performance of the application.
Don't be looking for "tricks" in the exception path, look for
ways outside of that we can better structure the page tables
so we can _remove_ code from the exception handler, not
add to it. What you are doing here is an attempt to do
that, but you are executing lots more code to do this
preload than the TLB miss exception would do.
Keep trying, though, this was a good idea to test :-)
Thanks.
-- Dan
^ permalink raw reply
* Re: RFC: Rev 0.5 Booting the Linux/ppc kernel without Open Firmware
From: Arnd Bergmann @ 2005-12-20 18:58 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc64-dev, linuxppc-dev
In-Reply-To: <Pine.LNX.4.44.0512201106280.22417-100000@gate.crashing.org>
On Dinsdag 20 Dezember 2005 18:26, Kumar Gala wrote:
>
> > AFAICS, that requires at least two things:
> > - The device needs to be created when the bus is probed, i.e.
> > of_device_register can not be called from inside the driver
> > module_init() function.
> >
>
> This is already handled by the platform device in the kernel.
Ok, i was a bit misinformed about how platform devices currently work,
for some reason I thought that there was only a single entry point
for register_device and register_driver, which is untrue.
Sorry for the confusion here.
> I still dont see what a new bus type get us. I'm going to have to have
> specific code to parse and build and register my devices. If that could
> ends up registering a platform device or a newflatOF device I dont see any
> real difference.
After looking into it a bit more, I found that we already have
two different types of platform devices here: the standard struct
platform_device and the of_platform_device that is currently used
only on powermac and (maybe surprisingly) is not based on a
platform_device at all but on of_device.
Using the basic platform_device has the big advantage that you
can't access the device_node information (unless we implement the
device::firmware_data infrastructure for powerpc, which looks
increasingly appealing).
> > The alternative would be to represent all of the device tree
> > in /sys/devices, but IMHO that should better be part of
> > /sys/firmware with symlinks to the linux internal device tree
> > representation.
>
> Today I have:
> /sys/devices/platform/
> fsl-gianfar.1
> fsl-i2c.1
> fsl-i2c.2
> fsl-sec2.1
> fsl-usb2-dr.1
> fsl-usb2-mph.1
> serial8250
> serial8250.0
The problem I see with these is that currently they are all created
by platform specific code or driver specific code that knows exactly
that these devices exist on the hardware.
When moving to the device tree, you need some criteria to decide
which devices to add and which not. One way to do this would be
to only add devices that are a direct child of an SOC bus. If you
would simply add every single device_node as a platform_device,
you end up with a huge number of entries in /sys/devices/platform/
that are either unused completely or already represented elsewhere
like /sys/devices/pci*/*.
One idea I just had (forgive me if that is bullshit, it's getting late
here) is to really do the /sys/firmware stuff by embedding a kobject
in every device_node. The existing bus types that already know about
device_node (pci, vio, macio, of_platform, ...) get converted to
use that (e.g. pci stores the device_node in pci_dev:dev:firmware_data
instead of pci_dev:sysdata) and create the appropriate symlink in sysfs.
When an of_platform_driver registers, we can still give it all devices
because we can create the of_platform_device on the fly by doing the
match on the device_node first.
Arnd <><
^ permalink raw reply
* TLB preloading on 8xx
From: Marcelo Tosatti @ 2005-12-20 17:37 UTC (permalink / raw)
To: linux-ppc-embedded
Hi,
Been playing with TLB preloading on 8xx for the past weeks, and I must
say that results are frustrating.
Most of the TLB setup work involves writing to special purpose
registers, using "mtspr", which is a serializing instruction (it blocks
all execution units).
Sum up the costs of disabling interrupts and disabling translation, and you
end up with a slow dog. Damn, the TLB exceptions are indeed efficient.
The test used to measure pagefault latency is LMbench's "lat_pagefault".
vanilla:
[root@CAS /]# ./lat_pagefault -N10 out.prof
Pagefaults on out.prof: 36.3728 microseconds
d-tlb-preload:
[root@CAS /]# ./lat_pagefault -N10 out.prof
Pagefaults on out.prof: 43.7793 microseconds
diff -Nur --exclude-from=linux-2.6-git-dec01/Documentation/dontdiff linux-2.6-git-dec01.orig/arch/ppc/kernel/head_8xx.S linux-2.6-git-dec01/arch/ppc/kernel/head_8xx.S
--- linux-2.6-git-dec01.orig/arch/ppc/kernel/head_8xx.S 2005-12-05 09:47:27.000000000 -0600
+++ linux-2.6-git-dec01/arch/ppc/kernel/head_8xx.S 2005-12-15 12:37:07.449818656 -0600
@@ -804,7 +828,156 @@
SYNC
blr
+
+_GLOBAL(__tlb_data_load)
+ rlwinm r8, r4, 0, 0, 19 /* extract page address */
+ ori r8, r8, MD_EVALID /* set valid bit */
+ slw r3, r3, 28
+ rlwimi r8, r3, 0, 28, 31 /* load ASID from r3 */
+#ifdef CONFIG_8xx_CPU6
+ li r9, 0x3780;
+ stw r9, 4(r7);
+ lwz r9, 4(r7);
+#endif
+ mtspr SPRN_MD_EPN, r8
+
+ mfspr r10, SPRN_M_TWB /* Get level 1 table entry address */
+ lwz r11, 0(r10) /* Get the level 1 entry */
+ ori r11,r11,1 /* Set valid bit */
+
+ /* Insert the Guarded flag into the TWC from the Linux PTE.
+ * It is bit 27 of both the Linux PTE and the TWC (at least
+ * I got that right :-). It will be better when we can put
+ * this into the Linux pgd/pmd and load it in the operation
+ * above.
+ */
+ mr r12, r5
+ rlwimi r11, r12, 0, 27, 27
+
+ /*
+ * Some fields of MD_TWC are cleared by the CPU on a DTLB miss.
+ * Must do it manually for TLB preload.
+ * clear 23-26 (access protection group)
+ * clear 28-29 (page size) and 30 (write-through)
+ */
+ li r12, 0
+ rlwimi r11, r12, 0, 23, 26
+ rlwimi r11, r12, 0, 28, 30
+#ifdef CONFIG_8xx_CPU6
+ li r9, 0x3b80;
+ stw r9, 4(r7);
+ lwz r9, 4(r7);
+#endif
+ mtspr SPRN_MD_TWC, r11 /* Set segment attributes */
+
+ mr r8, r5
+ mr r11, r8
+ rlwinm r8, r8, 0, 0, 20
+ ori r8, r8, 1 /* set valid bit */
+ /* Update 'changed', among others.
+ */
+ andi. r11, r11, _PAGE_RW
+ li r11, 0x00f0
+ beq 1f
+ ori r8, r8, _PAGE_DIRTY|_PAGE_ACCESSED|_PAGE_HWWRITE
+// stw r8, 0(r5) /* and update pte in table */
+ ori r11, r11, _PAGE_HWWRITE
+ /* The Linux PTE won't go exactly into the MMU TLB.
+ * Software indicator bits 21, 22 and 28 must be clear.
+ * Software indicator bits 24, 25, 26, and 27 must be
+ * set. All other Linux PTE bits control the behavior
+ * of the MMU.
+ */
+1:
+ rlwimi r8, r11, 0, 23, 28 /* Set 24-27, clear 28 */
+ /* 23 is set if page is _PAGE_RW */
+#ifdef CONFIG_8xx_CPU6
+ li r9, 0x3d80;
+ stw r9, 4(r7);
+ lwz r9, 4(r7);
+#endif
+ mtspr SPRN_MD_RPN, r8 /* Update TLB entry */
+
+ mfmsr r11
+ lwz r6, 0(r7) /* restore Link Register */
+ mtlr r6
+ li r6, 0x7fff
+ rlwimi r11, r6, 0, 27, 27 /* set DR */
+ mtmsr r11
+ tovirt(r7, r7)
+ blr
+
+/*
+ * Load a D-TLB entry.
+ * r3: context number
+ * r4: effective address
+ * r5: PTE pointer
+ * r6: PMD (level-1 entry)
+ * r7: temp location
+ */
+_GLOBAL(tlb_data_load)
+ lwz r5, 0(r5)
+ mflr r6
+ stw r6, 0(r7) /* save Link Register */
+ mfmsr r11
+ li r6, 0
+ rlwimi r11, r6, 0, 27, 27 /* clear DR (data translat.)*/
+ mtmsr r11
+ lis r6, __tlb_data_load@h
+ ori r6, r6, __tlb_data_load@l
+ tophys(r7, r7)
+ mtlr r6
+ blr
+
+/*
+ * Load a I-TLB entry.
+ * r3: context number
+ * r4: effective address
+ * r5: PTE pointer
+ * r6: PMD (level-1 entry)
+ * r7: temp location
+ */
+_GLOBAL(tlb_instr_load)
+ rlwinm r8, r4, 0, 0, 19 /* extract page address */
+ ori r8, r8, MI_EVALID /* set valid bit */
+ slw r3, r3, 28
+ rlwimi r8, r3, 0, 28, 31 /* load ASID from r3 */
#ifdef CONFIG_8xx_CPU6
+ li r9, 0x2780;
+ stw r9, 0(r7);
+ lwz r9, 0(r7);
+#endif
+
+ mfspr r10, SPRN_M_TWB /* Get level 1 table entry address */
+ tovirt(r10, r10)
+ lwz r11, 0(r10) /* Get the level 1 entry */
+ ori r11,r11,1 /* Set valid bit */
+#ifdef CONFIG_8xx_CPU6
+ li r9, 0x2b80;
+ stw r9, 0(r7);
+ lwz r9, 0(r7);
+#endif
+ mtspr SPRN_MI_TWC, r11 /* Set segment attributes */
+
+ lwz r8, 0(r5)
+ rlwinm r8, r8, 0, 0, 19
+ ori r8, r8, 1 /* set valid bit */
+ /* The Linux PTE won't go exactly into the MMU TLB.
+ * Software indicator bits 21, 22 and 28 must be clear.
+ * Software indicator bits 24, 25, 26, and 27 must be
+ * set. All other Linux PTE bits control the behavior
+ * of the MMU.
+ */
+ li r11, 0x00f0
+ rlwimi r8, r11, 0, 24, 28 /* Set 24-27, clear 28 */
+#ifdef CONFIG_8xx_CPU6
+ li r9, 0x2d80;
+ stw r9, 0(r7);
+ lwz r9, 0(r7);
+#endif
+ mtspr SPRN_MI_RPN, r8 /* Update TLB entry */
+ blr
+
/* It's here because it is unique to the 8xx.
* It is important we get called with interrupts disabled. I used to
* do that, but it appears that all code that calls this already had
@@ -820,7 +993,6 @@
mtspr 22, r3 /* Update Decrementer */
SYNC
blr
-#endif
/*
* We put a few things here that have to be page-aligned.
diff -Nur --exclude-from=linux-2.6-git-dec01/Documentation/dontdiff linux-2.6-git-dec01.orig/arch/ppc/mm/init.c linux-2.6-git-dec01/arch/ppc/mm/init.c
--- linux-2.6-git-dec01.orig/arch/ppc/mm/init.c 2005-12-05 09:47:28.000000000 -0600
+++ linux-2.6-git-dec01/arch/ppc/mm/init.c 2005-12-15 13:16:42.787712408 -0600
@@ -583,6 +583,54 @@
kunmap(page);
}
+extern void tlb_data_load(unsigned long id, unsigned long address, pte_t *pte,
+ unsigned long pmdval, unsigned long *tmpval);
+
+extern void tlb_instr_load(unsigned long id, unsigned long address, pte_t *pte,
+ unsigned long pmdval, unsigned long *tmpval);
+
+void tlb_preload(struct vm_area_struct *vma, unsigned long address,
+ pte_t pte)
+{
+ struct mm_struct *mm;
+ pmd_t *pmd;
+ pte_t *ptep;
+ int mapping_executable = 0;
+ unsigned long flags, tmpval;
+ unsigned long tmp[4];
+
+ if ((vma->vm_flags & VM_EXEC) == VM_EXEC)
+ mapping_executable = 1;
+
+ local_irq_save(flags);
+
+ mm = vma->vm_mm;
+ pmd = pmd_offset(pgd_offset(mm, address), address);
+ if (!pmd_none(*pmd)) {
+ if (mfspr(SPRN_M_CASID) != (mm->context)) {
+ printk(KERN_ERR "CASID:%lx mm->context:%lx\n",
+ mfspr(SPRN_M_CASID), (mm->context));
+ BUG();
+ }
+ ptep = pte_offset_map(pmd, address);
+ if (!pte_present(pte) || !ptep)
+ goto out;
+ if (!mapping_executable)
+ tlb_data_load(mm->context, address, ptep,
+ pmd_val(*pmd), &tmp);
+#ifdef NOTYET
+ else
+ tlb_instr_load(mm->context, address, ptep,
+ pmd_val(*pmd), &tmp);
+#endif
+out:
+ pte_unmap(ptep);
+ }
+ local_irq_restore(flags);
+}
+
+extern void tlbie_efficient(unsigned long address, struct vm_area_struct *vma);
+
/*
* This is called at the end of handling a user page fault, when the
* fault has been handled by updating a PTE in the linux page tables.
@@ -614,6 +662,7 @@
flush_dcache_icache_page(page);
set_bit(PG_arch_1, &page->flags);
}
+ tlb_preload(vma, address, pte);
}
#ifdef CONFIG_PPC_STD_MMU
^ permalink raw reply
* Re: linux DMA capabilities in MV64460
From: Mark A. Greer @ 2005-12-20 17:54 UTC (permalink / raw)
To: Brian Waite; +Cc: linuxppc-embedded
In-Reply-To: <200512200927.35976.bwaite@irobot.com>
On Tue, Dec 20, 2005 at 09:27:35AM -0500, Brian Waite wrote:
> On Monday 19 December 2005 8:01 pm, Mark A. Greer wrote:
> > >
> > > up the mv64460. One source told me:
> > > > In order to do PCI bursts, you'll need to use a DMA engine. The
> > > > MV64460 does contain a DMA engine, but you'd need to write a driver
> > > > to access it.
> >
> > That is not correct (assuming the quote is not out of context).
> > The bridge supports bursting on the PCI bus as long as the bridge is
> > configured correctly and the PCI device is making an appropriate request.
> > Note, however, that there are many errata for the Marvell parts including
> > some with cache coherency.
> There are many many errata regarding cache coherency. Also, the PCI bandwidth
> the bridge is capable of with coherency enabled is very small. You will most
> likely need to use sw coherency for any real speed.
I've managed to get reasonable speed with coherency on but you have to
jack the burst sizes to the max (see my comment below). The speed was
hugely affected by the burst size; coherency enabled had only a minor impact.
The problem for me, however, was the board(s) I have do not have the
necessary hw coherency errata workarounds implemented so the bridge
eventually hangs with coherency enabled.
Unfortunately, I think I deleted the file with my performance
results in one of my cleanup binges. IIRC, though, I got ~750 Mbps
with coherency off and ~725 Mbps with it on using an e1000 & a 750fx
or gx clocked around 800 MHz.
> > If your system is running with coherency on,
> > you may have to limit your bursts to 32 bytes (i.e., the size of one
> > cache line).
> You will have to limit your self to 32 byte bursts with coherency. This is a
> requirement not an errata.
That is only true for the 64360. The 64460 does not have that
restriction AFAICT.
<snip>
Mark
^ permalink raw reply
* Re: RFC: Rev 0.5 Booting the Linux/ppc kernel without Open Firmware
From: Kumar Gala @ 2005-12-20 17:26 UTC (permalink / raw)
To: Arnd Bergmann; +Cc: linuxppc64-dev, linuxppc-dev
In-Reply-To: <200512201118.05404.arnd@arndb.de>
On Tue, 20 Dec 2005, Arnd Bergmann wrote:
> On Maandag 19 Dezember 2005 21:49, Kumar Gala wrote:
> > I'm still in favor of just leaving these devices as straight platform
> > devices. Unless there is something that is bus specific that each device
> > on the bus conforms to I dont see any reason to create a new bus type.
>
> How do platform devices work with module autoloading? What I'm interested
> in is to have stuff like the Fedora installer or kernels with modular
> drivers 'just work' because they can use the same way to load their
> modules that is already used for PCI devices.
>
> AFAICS, that requires at least two things:
> - The device needs to be created when the bus is probed, i.e.
> of_device_register can not be called from inside the driver
> module_init() function.
>
This is already handled by the platform device in the kernel.
> - The bus type needs to create a modalias file so user space can
> do the matching with the of device table in the modules.
Seems like a simple thing to add to platform device.
> Both of these should be a lot easier to implement with a special
> bus type that creates entries in sysfs for a subset of the OF
> device tree.
I still dont see what a new bus type get us. I'm going to have to have
specific code to parse and build and register my devices. If that could
ends up registering a platform device or a newflatOF device I dont see any
real difference.
> The alternative would be to represent all of the device tree
> in /sys/devices, but IMHO that should better be part of
> /sys/firmware with symlinks to the linux internal device tree
> representation.
Today I have:
/sys/devices/platform/
fsl-gianfar.1
fsl-i2c.1
fsl-i2c.2
fsl-sec2.1
fsl-usb2-dr.1
fsl-usb2-mph.1
serial8250
serial8250.0
- kumar
^ permalink raw reply
* yaboot mailing lists - new home
From: Paul Nasrat @ 2005-12-20 16:08 UTC (permalink / raw)
To: Ethan Benson, linuxppc-dev; +Cc: linuxppc64-dev
Following the hardware failure on penguinppc.org I've managed to arrange
hosting thanks to the kind administrators at ozlabs
https://ozlabs.org/mailman/listinfo/yaboot-devel
https://ozlabs.org/mailman/listinfo/yaboot-users
I haven't pushed any content there yet, but I think we were aiming at a
test release shortly so having the lists back will help.
Paul
^ 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