Re: [BUG] 2.6.24-rc3-git2 softlockup detected
Andrew Morton wrote: On Wed, 28 Nov 2007 11:59:00 +0530 Kamalesh Babulal [EMAIL PROTECTED] wrote: Hi, (cc linux-scsi, for sym53c8xx) Soft lockup is detected while bootup with 2.6.24-rc3-git2 on powerbox I assume this is a post-2.6.23 regression? BUG: soft lockup - CPU#1 stuck for 11s! [insmod:375] NIP: c002f02c LR: d01414fc CTR: c002f018 REGS: c0077cbef0b0 TRAP: 0901 Not tainted (2.6.24-rc3-git2-autotest) MSR: 80009032 EE,ME,IR,DR CR: 24022088 XER: TASK = c0077cbd8000[375] 'insmod' THREAD: c0077cbec000 CPU: 1 GPR00: d01414fc c0077cbef330 c052b930 d80080002014 GPR04: d8008000202c c0077ca1cb00 d014ce54 GPR08: c0077ca1c63c 002a c002f018 GPR12: d0143610 c0473d00 NIP [c002f02c] .ioread8+0x14/0x60 LR [d01414fc] .sym_hcb_attach+0x1188/0x1378 [sym53c8xx] Call Trace: [c0077cbef330] [c0077cbef3c0] 0xc0077cbef3c0 (unreliable) [c0077cbef3a0] [d01414fc] .sym_hcb_attach+0x1188/0x1378 [sym53c8xx] [c0077cbef470] [d01395f8] .sym2_probe+0x700/0x99c [sym53c8xx] [c0077cbef710] [c01bc118] .pci_device_probe+0x124/0x1b0 [c0077cbef7b0] [c0221138] .driver_probe_device+0x144/0x20c [c0077cbef850] [c0221450] .__driver_attach+0xcc/0x154 [c0077cbef8e0] [c021ff94] .bus_for_each_dev+0x7c/0xd4 [c0077cbef9a0] [c0220e9c] .driver_attach+0x28/0x40 [c0077cbefa20] [c02204d8] .bus_add_driver+0x90/0x228 [c0077cbefac0] [c0221858] .driver_register+0x94/0xb0 [c0077cbefb40] [c01bc430] .__pci_register_driver+0x6c/0xcc [c0077cbefbe0] [d0143428] .sym2_init+0x108/0x15b0 [sym53c8xx] [c0077cbefc80] [c008ce80] .sys_init_module+0x17c4/0x1958 [c0077cbefe30] [c000872c] syscall_exit+0x0/0x40 Instruction dump: 6000 786b0420 38210070 7d635b78 e8010010 7c0803a6 4e800020 7c0802a6 f8010010 f821ff91 7c0004ac 8923 0c09 4c00012c 79290620 2f8900ff I see no obvious lockup sites near the end of sym_hcb_attach(). Maybe it's being called lots of times from a higher level.. Do the traces all look the same? Hi Andrew, I see this call trace twice and both looks similar and on another reboot the following trace is seen twice in different cpu BUG: soft lockup detected on CPU#3! Call Trace: [C0003FEDEDA0] [C0010220] .show_stack+0x68/0x1b0 (unreliable) [C0003FEDEE40] [C00A061C] .softlockup_tick+0xf0/0x13c [C0003FEDEEF0] [C0072E2C] .run_local_timers+0x1c/0x30 [C0003FEDEF70] [C0022FA0] .timer_interrupt+0xa8/0x488 [C0003FEDF050] [C00034EC] decrementer_common+0xec/0x100 --- Exception: 901 at .ioread8+0x14/0x60 LR = .sym_hcb_attach+0x1194/0x1384 [sym53c8xx] [C0003FEDF340] [D02B3BC0] 0xd02b3bc0 (unreliable) [C0003FEDF3B0] [D029A3C0] .sym_hcb_attach+0x1194/0x1384 [sym53c8xx] [C0003FEDF480] [D0291D30] .sym2_probe+0x75c/0x9f8 [sym53c8xx] [C0003FEDF710] [C01B65A4] .pci_device_probe+0x13c/0x1dc [C0003FEDF7D0] [C0219A0C] .driver_probe_device+0xa0/0x15c [C0003FEDF870] [C0219C64] .__driver_attach+0xb4/0x138 [C0003FEDF900] [C021913C] .bus_for_each_dev+0x7c/0xd4 [C0003FEDF9C0] [C02198B0] .driver_attach+0x28/0x40 [C0003FEDFA40] [C0218BA4] .bus_add_driver+0x98/0x18c [C0003FEDFAE0] [C021A064] .driver_register+0xa8/0xc4 [C0003FEDFB60] [C01B68AC] .__pci_register_driver+0x5c/0xa4 [C0003FEDFBF0] [D029C204] .sym2_init+0x104/0x1550 [sym53c8xx] [C0003FEDFC90] [C008D1F4] .sys_init_module+0x1764/0x1998 [C0003FEDFE30] [C000869C] syscall_exit+0x0/0x40 -- Thanks Regards, Kamalesh Babulal, Linux Technology Center, IBM, ISTL. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 1/2] powerpc: add hugepagesz boot-time parameter
On Wednesday 28 November 2007, Jon Tollefson wrote: This patch adds the hugepagesz boot-time parameter for ppc64 that lets you pick the size for your huge pages. The choices available are 64K and 16M. It defaults to 16M (previously the only choice) if nothing or an invalid choice is specified. Tested 64K huge pages with the libhugetlbfs 1.2 release with its 'make func' and 'make stress' test invocations. How hard would it be to add the 1MB page size that some CPUs support as well? On systems with small physical memory like the PS3, that sounds very useful to me. Arnd ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [BUG] 2.6.24-rc3-git2 softlockup detected
On Wed, 28 Nov 2007 12:47:19 +0530 Kamalesh Babulal [EMAIL PROTECTED] wrote: Andrew Morton wrote: On Wed, 28 Nov 2007 11:59:00 +0530 Kamalesh Babulal [EMAIL PROTECTED] wrote: Hi, (cc linux-scsi, for sym53c8xx) Soft lockup is detected while bootup with 2.6.24-rc3-git2 on powerbox I assume this is a post-2.6.23 regression? BUG: soft lockup - CPU#1 stuck for 11s! [insmod:375] NIP: c002f02c LR: d01414fc CTR: c002f018 REGS: c0077cbef0b0 TRAP: 0901 Not tainted (2.6.24-rc3-git2-autotest) MSR: 80009032 EE,ME,IR,DR CR: 24022088 XER: TASK = c0077cbd8000[375] 'insmod' THREAD: c0077cbec000 CPU: 1 GPR00: d01414fc c0077cbef330 c052b930 d80080002014 GPR04: d8008000202c c0077ca1cb00 d014ce54 GPR08: c0077ca1c63c 002a c002f018 GPR12: d0143610 c0473d00 NIP [c002f02c] .ioread8+0x14/0x60 LR [d01414fc] .sym_hcb_attach+0x1188/0x1378 [sym53c8xx] Call Trace: [c0077cbef330] [c0077cbef3c0] 0xc0077cbef3c0 (unreliable) [c0077cbef3a0] [d01414fc] .sym_hcb_attach+0x1188/0x1378 [sym53c8xx] [c0077cbef470] [d01395f8] .sym2_probe+0x700/0x99c [sym53c8xx] [c0077cbef710] [c01bc118] .pci_device_probe+0x124/0x1b0 [c0077cbef7b0] [c0221138] .driver_probe_device+0x144/0x20c [c0077cbef850] [c0221450] .__driver_attach+0xcc/0x154 [c0077cbef8e0] [c021ff94] .bus_for_each_dev+0x7c/0xd4 [c0077cbef9a0] [c0220e9c] .driver_attach+0x28/0x40 [c0077cbefa20] [c02204d8] .bus_add_driver+0x90/0x228 [c0077cbefac0] [c0221858] .driver_register+0x94/0xb0 [c0077cbefb40] [c01bc430] .__pci_register_driver+0x6c/0xcc [c0077cbefbe0] [d0143428] .sym2_init+0x108/0x15b0 [sym53c8xx] [c0077cbefc80] [c008ce80] .sys_init_module+0x17c4/0x1958 [c0077cbefe30] [c000872c] syscall_exit+0x0/0x40 Instruction dump: 6000 786b0420 38210070 7d635b78 e8010010 7c0803a6 4e800020 7c0802a6 f8010010 f821ff91 7c0004ac 8923 0c09 4c00012c 79290620 2f8900ff I see no obvious lockup sites near the end of sym_hcb_attach(). Maybe it's being called lots of times from a higher level.. Do the traces all look the same? Hi Andrew, I see this call trace twice and both looks similar and on another reboot the following trace is seen twice in different cpu BUG: soft lockup detected on CPU#3! Call Trace: [C0003FEDEDA0] [C0010220] .show_stack+0x68/0x1b0 (unreliable) [C0003FEDEE40] [C00A061C] .softlockup_tick+0xf0/0x13c [C0003FEDEEF0] [C0072E2C] .run_local_timers+0x1c/0x30 [C0003FEDEF70] [C0022FA0] .timer_interrupt+0xa8/0x488 [C0003FEDF050] [C00034EC] decrementer_common+0xec/0x100 --- Exception: 901 at .ioread8+0x14/0x60 LR = .sym_hcb_attach+0x1194/0x1384 [sym53c8xx] [C0003FEDF340] [D02B3BC0] 0xd02b3bc0 (unreliable) [C0003FEDF3B0] [D029A3C0] .sym_hcb_attach+0x1194/0x1384 [sym53c8xx] [C0003FEDF480] [D0291D30] .sym2_probe+0x75c/0x9f8 [sym53c8xx] [C0003FEDF710] [C01B65A4] .pci_device_probe+0x13c/0x1dc [C0003FEDF7D0] [C0219A0C] .driver_probe_device+0xa0/0x15c [C0003FEDF870] [C0219C64] .__driver_attach+0xb4/0x138 [C0003FEDF900] [C021913C] .bus_for_each_dev+0x7c/0xd4 [C0003FEDF9C0] [C02198B0] .driver_attach+0x28/0x40 [C0003FEDFA40] [C0218BA4] .bus_add_driver+0x98/0x18c [C0003FEDFAE0] [C021A064] .driver_register+0xa8/0xc4 [C0003FEDFB60] [C01B68AC] .__pci_register_driver+0x5c/0xa4 [C0003FEDFBF0] [D029C204] .sym2_init+0x104/0x1550 [sym53c8xx] [C0003FEDFC90] [C008D1F4] .sys_init_module+0x1764/0x1998 [C0003FEDFE30] [C000869C] syscall_exit+0x0/0x40 hm, odd. Can you look up sym_hcb_attach+0x1194/0x1384 in gdb? Something like - Enable CONFIG_DEBUG_INFO - gdb sym53c8xx.o (gdb) p sym_hcb_attach prints 0xsomething (gdb) p/x 0xsomething + 0x1194 prints 0xsomethingelse (gdb) l *0xsomethingelse ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: of_compat_cmp on various platforms
On Tue, 27 Nov 2007 22:46:16 -0500 Jon Smirl [EMAIL PROTECTED] wrote: Is this right or should it be the same everywhere? asm-powerpc/prom.h:#define of_compat_cmp(s1, s2, l) strcasecmp((s1), (s2)) asm-sparc/prom.h:#define of_compat_cmp(s1, s2, l) strncmp((s1), (s2), (l)) asm-sparc64/prom.h:#define of_compat_cmp(s1, s2, l) strncmp((s1), (s2), (l)) The only reason these exist is because the sparc and powerpc versions needed to be different when I was consolidating the of routines. One of the things we have to work on is finding the platforms/drivers where this matters and fix them. So, for now, these need to be there. -- Cheers, Stephen Rothwell[EMAIL PROTECTED] http://www.canb.auug.org.au/~sfr/ pgpZd97RhCygL.pgp Description: PGP signature ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: PPC upstream kernel ignored DABR bug
On Wednesday 28 November 2007, Jan Kratochvil wrote: Please be aware DABR works fine if the same code runs just 1 (always) or 2 (sometimes) threads. It starts failing with too many threads running: $ ./dabr-lost TID 32725: DABR 0x1001279f NIP 0xfecf41c TID 32726: DABR 0x1001279f NIP 0xfecf41c TID 32725: hitting the variable variable found = -1, caught TID = 32725 TID 32726: hitting the variable variable found = -1, caught TID = 32726 The kernel bug did not get reproduced - increase THREADS. As I did not find any code in that kernel touching DABRX its value should not be dependent on the number of threads running. Right, this is a different problem from the one reported by Uli. From what I can tell, your problem is that you set the DABR only in one thread, so the other threads don't see it. DABR is saved in the thread_struct, so setting it in one thread doesn't have an impact on any other thread. Arnd ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: 2.6.24-rc3-mm2 - Build Failure on powerpc timerfd() undeclared
Hi Andrew, Kernel build fails, with build error CC arch/powerpc/platforms/cell/spu_callbacks.o In file included from arch/powerpc/platforms/cell/spu_callbacks.c:49: include/asm/systbl.h:312: error: ‘sys_timerfd’ undeclared here (not in a function) make[2]: *** [arch/powerpc/platforms/cell/spu_callbacks.o] Error 1 make[1]: *** [arch/powerpc/platforms/cell] Error 2 make: *** [arch/powerpc/platforms] Error 2 -- Thanks Regards, Kamalesh Babulal, Linux Technology Center, IBM, ISTL. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: PPC upstream kernel ignored DABR bug
On Wed, 28 Nov 2007 13:28:48 +0100, Arnd Bergmann wrote:
On Wednesday 28 November 2007, Jan Kratochvil wrote:
Please be aware DABR works fine if the same code runs just 1 (always) or
2 (sometimes) threads. It starts failing with too many threads running:
$ ./dabr-lost
TID 32725: DABR 0x1001279f NIP 0xfecf41c
TID 32726: DABR 0x1001279f NIP 0xfecf41c
TID 32725: hitting the variable
variable found = -1, caught TID = 32725
TID 32726: hitting the variable
variable found = -1, caught TID = 32726
The kernel bug did not get reproduced - increase THREADS.
As I did not find any code in that kernel touching DABRX its value should
not
be dependent on the number of threads running.
Right, this is a different problem from the one reported by Uli.
From what I can tell, your problem is that you set the DABR only
in one thread, so the other threads don't see it. DABR is saved
in the thread_struct, so setting it in one thread doesn't have
an impact on any other thread.
It even prints out above:
TID 32725: DABR 0x1001279f NIP 0xfecf41c
TID 32726: DABR 0x1001279f NIP 0xfecf41c
that it wrote DABR in both the threads and it has also successfully read it
back from each thread specifically (according to its thread-specific TID).
for (threadi = 0; threadi THREADS; threadi++)
{
pid_t tid = thread[threadi];
setup (tid);
...
}
static void setup (pid_t tid)
{
...
l = ptrace (PTRACE_SET_DEBUGREG, tid, NULL, (void *) dabr);
...
}
Also if I would not set DABR specifically for each thread it would not work in
90% of cases for `THREADS == 2'. And it would not work for `THREADS == 4' if
they are busylooping (therefore not in a syscall).
TID 596: DABR 0x100127a7 NIP 0x1dbc
TID 597: DABR 0x100127a7 NIP 0x1db0
TID 598: DABR 0x100127a7 NIP 0x1dac
TID 599: DABR 0x100127a7 NIP 0x1dbc
TID 596: hitting the variable
variable found = -1, caught TID = 596
TID 599: hitting the variable
variable found = -1, caught TID = 599
TID 597: hitting the variable
variable found = -1, caught TID = 597
TID 598: hitting the variable
variable found = -1, caught TID = 598
The kernel bug got workarounded by WORKAROUND_SET_DABR_IN_SYSCALL.
(I found out now WORKAROUND_SET_DABR_IN_SYSCALL only reduces the probability of
the failure, it is not a 100% workaround of the problem in the testcase.)
There is some tricky kernel code around it but I did not try to debug it:
struct task_struct *__switch_to(struct task_struct *prev,
struct task_struct *new)
{
...
if (unlikely(__get_cpu_var(current_dabr) != new-thread.dabr)) {
set_dabr(new-thread.dabr);
__get_cpu_var(current_dabr) = new-thread.dabr;
}
...
}
Regards,
Jan
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 2/2] [PPC 44x] enable L2-cache for ALPR, Katmai, Ocotea, and Taishan
On Tue, Nov 27, 2007 at 10:41:46AM +1100, Benjamin Herrenschmidt wrote: BTW... Do you know why we can't just enable HW snoop ? The 440SPe documentation seems to indicate that this is supported by the L2 cache via snooping on the PLB. Unless something has been changed significantly in the 44x port, but L2 cache code I wrote for 440GX did exactly this - we never needed any manual L2 cache management at all. -- Eugene ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH] Stop phy code from returning success to unknown ioctls.
This kind of sucks, and prevents the Fedora installer from using the device for network installs... [EMAIL PROTECTED] phy]# iwconfig eth0 Warning: Driver for device eth0 has been compiled with an ancient version of Wireless Extension, while this program support version 11 and later. Some things may be broken... eth0ESSID:off/any Nickname: NWID:0 Channel:0 Access Point: 00:00:BF:81:14:E0 Bit Rate:-1.08206e+06 kb/s Sensitivity=0/0 RTS thr:off Fragment thr:off Encryption key:too big Power Management:off Signed-off-by: David Woodhouse [EMAIL PROTECTED] diff --git a/drivers/net/phy/phy.c b/drivers/net/phy/phy.c index 9bc1177..7c9e6e3 100644 --- a/drivers/net/phy/phy.c +++ b/drivers/net/phy/phy.c @@ -406,6 +406,9 @@ int phy_mii_ioctl(struct phy_device *phydev, phydev-drv-config_init) phydev-drv-config_init(phydev); break; + + default: + return -ENOTTY; } return 0; -- dwmw2 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 2/2] [PPC 44x] enable L2-cache for ALPR, Katmai, Ocotea, and Taishan
On Wed, 2007-11-28 at 11:47 -0800, Eugene Surovegin wrote: On Tue, Nov 27, 2007 at 10:41:46AM +1100, Benjamin Herrenschmidt wrote: BTW... Do you know why we can't just enable HW snoop ? The 440SPe documentation seems to indicate that this is supported by the L2 cache via snooping on the PLB. Unless something has been changed significantly in the 44x port, but L2 cache code I wrote for 440GX did exactly this - we never needed any manual L2 cache management at all. Ah good. So we should port that code over instead. Thanks ! Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] powerpc: fix os-term usage on kernel panic
On Tue, Nov 27, 2007 at 06:15:59PM -0600, Will Schmidt wrote: (resending with the proper from addr this time). I'm seeing some funky behavior on power5/power6 partitions with this patch.A /sbin/reboot is now behaving much more like a /sbin/halt. Anybody else seeing this, or is it time for me to call an exorcist for my boxes? I beleive the patch http://www.nabble.com/-PATCH--powerpc-pseries:-tell-phyp-to-auto-restart-t4847604.html will cure this problem. From that patch: +/** + * pSeries_auto_restart - tell hypervisor that boot succeeded. + * + * The pseries hypervisor attempts to detect and prevent an + * infinite loop of kernel crashes and auto-reboots. It does + * so by refusing to auto-reboot unless we indicate that the + * current boot was sucessful. So, indicate success late in + * the boot sequence. + */ FYI, I am leaving IBM in just a few days now, and won't really have much of a chance to debug this, if there are other problems. This pair of patches was required to make hypervisor-assisted dump work, viz, we need to tell the hypervisor about when we crashed, or didn't crash, so that if we crashed, the dump can be taken appropriately. It occurs to me that, as I write this, that maybe xmon 'zr' command should be modified to call pSeries_auto_restart just in case, so that it actually reboots. There might be another funky code path that I can't think of right now. --linas ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: MPC5200 I2C and 2.6 kernel
In message [EMAIL PROTECTED] you wrote: Regardless what I'm doing in the 2.6 kernel configuration I can't get this RTC running (I activated RTC support and the driver for the M41T00 in the configuration). hwclock --debug tells me: hwclock: Open of /dev/rtc failed, errno=19: No such device. Well... did you check how your /dev/rtc is set up? It used to be a misc device with MAJ=10 MIN=135 in old kernel versions, but now it's MAJ=254 MIN=4, i. e. it should look like this: crw-r--r-- 1 root root 254, 0 Jun 22 18:30 /dev/rtc Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: [EMAIL PROTECTED] For every complex problem, there is a solution that is simple, neat, and wrong. -- H. L. Mencken ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] powerpc: fix os-term usage on kernel panic
On Wed, Nov 28, 2007 at 12:00:37PM +0100, Olaf Hering wrote: On Tue, Nov 27, Will Schmidt wrote: -void rtas_os_term(char *str) +void rtas_panic_msg(char *str) - if (panic_timeout) - return; This change is wrong. Booting with panic=123 really means the system has to reboot in 123 seconds after a panic. And it does. But, maybe this panic_timeout check was moved elsewhere. It was *always* somewhere else; the check here was always wrong. This change makes the os-term call happen after the the panic timeout amount of time has elapsed. --linas ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: 2.6.24-rc3-mm2 - Build Failure on powerpc timerfd() undeclared
On Wed, 28 Nov 2007, Andrew Morton wrote: On Wed, 28 Nov 2007 14:32:07 +0100 Arnd Bergmann [EMAIL PROTECTED] wrote: On Wednesday 28 November 2007, Kamalesh Babulal wrote: Kernel build fails, with build error CC arch/powerpc/platforms/cell/spu_callbacks.o In file included from arch/powerpc/platforms/cell/spu_callbacks.c:49: include/asm/systbl.h:312: error: ‘sys_timerfd’ undeclared here (not in a function) make[2]: *** [arch/powerpc/platforms/cell/spu_callbacks.o] Error 1 make[1]: *** [arch/powerpc/platforms/cell] Error 2 make: *** [arch/powerpc/platforms] Error 2 I guess all architectures except x86 are currently broken because they reference the old sys_timerfd function. None of them were broken in my testing and I'm unsure why powerpc broke here. This patch should add the missing bits to powerpc. Because the patches in -mm left the stubs in place in sys_ni.c and powerpc _should_ have (incorrectly) picked those up. My fault. I forgot to update sys_ni.c with the new functions (and with the sys_timerfd-sys_timerfd_create name change). Do you want a patch Andrew? - Davide ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
RE: [PATCH] e1000: Fix for 32 bits platforms with 64 bits resources
Benjamin Herrenschmidt wrote: The e1000 driver stores the content of the PCI resources into unsigned long's before ioremapping. This breaks on 32 bits platforms that support 64 bits MMIO resources such as ppc 44x. This fixes it by removing those temporary variables and passing directly the result of pci_resource_start/len to ioremap. the patch is mostly fine, but looking through the tree, doesn't every driver that has 64 bit capable resources have this problem? in fact, skeleton module has this problem, if I'm not mistaken. e1000 isn't the only one. :-) The side effect is that I removed the assignments to the netdev fields mem_start, mem_end and base_addr, which are totally useless for PCI devices. also, concerning this, ifconfig shows the output of these variables, I don't think we want to blatantly remove them, as it is actually removing information that is, if not used, at least displayed to user space. eth6 Link encap:Ethernet HWaddr 00:0E:01:0C:02:03 inet addr:134.134.3.121 Bcast:134.134.3.255 Mask:255.255.255.0 inet6 addr: fe80::20e:1ff:fe0c:203/64 Scope:Link UP BROADCAST NOTRAILERS RUNNING MULTICAST MTU:1500 Metric:1 RX packets:9022519 errors:0 dropped:0 overruns:0 frame:0 TX packets:1303701 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:4044613454 (3857.2 Mb) TX bytes:118365109 (112.8 Mb) Base address:0xf000 Memory:feac-feae ^ ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 1/2] powerpc: add hugepagesz boot-time parameter
Arnd Bergmann wrote: On Wednesday 28 November 2007, Mel Gorman wrote: On (28/11/07 08:26), Arnd Bergmann didst pronounce: On Wednesday 28 November 2007, Jon Tollefson wrote: This patch adds the hugepagesz boot-time parameter for ppc64 that lets you pick the size for your huge pages. The choices available are 64K and 16M. It defaults to 16M (previously the only choice) if nothing or an invalid choice is specified. Tested 64K huge pages with the libhugetlbfs 1.2 release with its 'make func' and 'make stress' test invocations. How hard would it be to add the 1MB page size that some CPUs support as well? On systems with small physical memory like the PS3, that sounds very useful to me. Does the PS3 support 1M pages in hardware? When I last looked, the magic ibm,segment-page-sizes file that described the supported pagesizes was missing from the device tree. In this situation, the default sizes become 4K and 16M because no other ones are advertised. I think you can select the page size using a hypercall on the PS3. The CPU supports any two of (64k, 1M, 16M) simultaneously. The PS3's hypervisor allows you to create the lpar's virtual address space with two page sizes. I currently have this hard coded to 64K and 16M. Within the address space you create memory regions. I have the hot-plug memory mapped in as a single region that is hard coded as 16M pages. The current HV implementation only allows you to create an htab of at maximum 1M, so that influences how you can configure page sizes. Just as a note, since the amount of memory available to the Linux lpar is not a multiple of 16M, some of the available hot-plug memory is not mapped into the address space. For firmware 1.90, 8M is unused. I was thinking to create another region for that memory and put things like the storage bounce buffers in there. Maybe I'll use 1M pages for that memory. -Geoff ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [RFC/PATCH 5/14] powerpc: Fix 440/440A machine check handling
On Thu, Nov 22, 2007 at 07:05:25AM +1100, Benjamin Herrenschmidt wrote: On Wed, 2007-11-21 at 13:51 -0600, Josh Boyer wrote: Hrm... it's per processor, not per board. I didn't feel like digging which board uses which processor and go fixup all the ppc_md's Sounds like something a generic function could probe for from the DTS. I'll look at doing something here when I start making 44x multiplatform (soon). Well... we already probe the CPU type from cputable. So if there was a place to put that, it would be the cputable. It could make sense to have _both_ platform (ppc_md) and cputable functions, since some info is likely to be core-specific, other might be board/chipset/SoC-specific. -Olof ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Why are CONFIG_LOCKDEP_SUPPORT, CONFIG_TRACE_IRQFLAGS_SUPPORT, and CONFIG_STACKTRACE_SUPPORT not defined for PowerPC?
On Nov 28, 2007 11:56 AM, Timur Tabi [EMAIL PROTECTED] wrote: These three Kconfig options: CONFIG_LOCKDEP_SUPPORT CONFIG_TRACE_IRQFLAGS_SUPPORT CONFIG_STACKTRACE_SUPPORT Are not defined for ppc or powerpc, but they are defined for several other architectures. I'm trying to debug some semaphore locks in ALSA, and these defines are necessary to enable some other Kconfig features. These work for me, but I don't think they're finalised yet so your mileage may vary: http://patchwork.ozlabs.org/linuxppc/patch?id=14171 http://patchwork.ozlabs.org/linuxppc/patch?id=14172 Tim ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Why are CONFIG_LOCKDEP_SUPPORT, CONFIG_TRACE_IRQFLAGS_SUPPORT, and CONFIG_STACKTRACE_SUPPORT not defined for PowerPC?
These work for me, but I don't think they're finalised yet so your mileage may vary: http://patchwork.ozlabs.org/linuxppc/patch?id=14171 http://patchwork.ozlabs.org/linuxppc/patch?id=14172 FWIW, the second one doesn't work on my quad G5 but I have a version that works... Haven't figured out yet what's wrong with this one. johannes signature.asc Description: This is a digitally signed message part ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [RFC/PATCH 5/14] powerpc: Fix 440/440A machine check handling
On Wed, 2007-11-28 at 15:34 -0600, Olof Johansson wrote: On Thu, Nov 22, 2007 at 07:05:25AM +1100, Benjamin Herrenschmidt wrote: On Wed, 2007-11-21 at 13:51 -0600, Josh Boyer wrote: Hrm... it's per processor, not per board. I didn't feel like digging which board uses which processor and go fixup all the ppc_md's Sounds like something a generic function could probe for from the DTS. I'll look at doing something here when I start making 44x multiplatform (soon). Well... we already probe the CPU type from cputable. So if there was a place to put that, it would be the cputable. It could make sense to have _both_ platform (ppc_md) and cputable functions, since some info is likely to be core-specific, other might be board/chipset/SoC-specific. Yup. I need to look into it. We would call ppc_md. first and define 3 result codes: one for faulting, one for returning (fixed up) and one for passing along (to the per-cpu code). In fact, in theory we would need to also handle L1 parity errors on 970 now that I think of it... Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH] MTD: pasemi_nand driver
Plumbing for NAND connected via localbus on PA Semi PWRficient-based
boards.
From: Egor Martovetsky [EMAIL PROTECTED]
Signed-off-by: Olof Johansson [EMAIL PROTECTED]
Index: 2.6.24/drivers/mtd/nand/Kconfig
===
--- 2.6.24.orig/drivers/mtd/nand/Kconfig
+++ 2.6.24/drivers/mtd/nand/Kconfig
@@ -283,6 +283,12 @@ config MTD_NAND_CM_X270
tristate Support for NAND Flash on CM-X270 modules
depends on MTD_NAND MACH_ARMCORE
+config MTD_NAND_PASEMI
+ tristate NAND support for PA Semi PWRficient
+ depends on MTD_NAND PPC_PASEMI
+ help
+ Enables support for NAND Flash interface on PA Semi PWRficient
+ based boards
config MTD_NAND_NANDSIM
tristate Support for NAND Flash Simulator
Index: 2.6.24/drivers/mtd/nand/Makefile
===
--- 2.6.24.orig/drivers/mtd/nand/Makefile
+++ 2.6.24/drivers/mtd/nand/Makefile
@@ -29,5 +29,6 @@ obj-$(CONFIG_MTD_NAND_CM_X270)+= cmx27
obj-$(CONFIG_MTD_NAND_BASLER_EXCITE) += excite_nandflash.o
obj-$(CONFIG_MTD_NAND_PLATFORM)+= plat_nand.o
obj-$(CONFIG_MTD_ALAUDA) += alauda.o
+obj-$(CONFIG_MTD_NAND_PASEMI) += pasemi_nand.o
nand-objs := nand_base.o nand_bbt.o
Index: 2.6.24/drivers/mtd/nand/pasemi_nand.c
===
--- /dev/null
+++ 2.6.24/drivers/mtd/nand/pasemi_nand.c
@@ -0,0 +1,241 @@
+/*
+ * Copyright (C) 2006-2007 PA Semi, Inc
+ *
+ * Author: Egor Martovetsky [EMAIL PROTECTED]
+ * Maintained by: Olof Johansson [EMAIL PROTECTED]
+ *
+ * Driver for the PWRficient onchip NAND flash interface
+ *
+ * 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.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
+ */
+
+#undef DEBUG
+
+#include linux/slab.h
+#include linux/init.h
+#include linux/module.h
+#include linux/mtd/mtd.h
+#include linux/mtd/nand.h
+#include linux/mtd/nand_ecc.h
+#include linux/platform_device.h
+#include linux/pci.h
+#include asm/of_platform.h
+
+#include asm/io.h
+
+#define LBICTRL_LPCCTL_NR 0x4000
+#define CLE_PIN_CTL15
+#define ALE_PIN_CTL14
+
+static unsigned int lpcctl;
+static struct mtd_info *pasemi_nand_mtd;
+static const char driver_name[] = pasemi-nand;
+
+static void pasemi_read_buf(struct mtd_info *mtd, u_char *buf, int len)
+{
+ struct nand_chip *chip = mtd-priv;
+
+ while (len 0x800) {
+ memcpy_fromio(buf, chip-IO_ADDR_R, 0x800);
+ buf += 0x800;
+ len -= 0x800;
+ }
+ memcpy_fromio(buf, chip-IO_ADDR_R, len);
+}
+
+static void pasemi_write_buf(struct mtd_info *mtd, const u_char *buf, int len)
+{
+ struct nand_chip *chip = mtd-priv;
+
+ while (len 0x800) {
+ memcpy_toio(chip-IO_ADDR_R, buf, 0x800);
+ buf += 0x800;
+ len -= 0x800;
+ }
+ memcpy_toio(chip-IO_ADDR_R, buf, len);
+}
+
+static void pasemi_hwcontrol(struct mtd_info *mtd, int cmd,
+unsigned int ctrl)
+{
+ struct nand_chip *chip = mtd-priv;
+
+ if (cmd == NAND_CMD_NONE)
+ return;
+
+ if (ctrl NAND_CLE)
+ out_8(chip-IO_ADDR_W + (1 CLE_PIN_CTL), cmd);
+ else
+ out_8(chip-IO_ADDR_W + (1 ALE_PIN_CTL), cmd);
+
+ /* Push out posted writes */
+ eieio();
+ inl(lpcctl);
+}
+
+int pasemi_device_ready(struct mtd_info *mtd)
+{
+ return !!(inl(lpcctl) LBICTRL_LPCCTL_NR);
+}
+
+static int __devinit pasemi_nand_probe(struct of_device *ofdev,
+ const struct of_device_id *match)
+{
+ struct pci_dev *pdev;
+ struct device_node *np = ofdev-node;
+ struct resource res;
+ struct nand_chip *chip;
+ int err = 0;
+
+ err = of_address_to_resource(np, 0, res);
+
+ if (err)
+ return -EINVAL;
+
+ /* We only support one device at the moment */
+ if (pasemi_nand_mtd)
+ return -ENODEV;
+
+ pr_debug(pasemi_nand at %lx-%lx\n, res.start, res.end);
+
+ /* Allocate memory for MTD device structure and private data */
+ pasemi_nand_mtd = kzalloc(sizeof(struct mtd_info) +
+ sizeof(struct nand_chip), GFP_KERNEL);
+ if
Re: [patch 2/7] ps3: Add ps3_repository_find_device_by_id()
ps3: Add ps3_repository_find_device_by_id() Signed-off-by: Geert Uytterhoeven [EMAIL PROTECTED] --- arch/powerpc/platforms/ps3/platform.h |2 arch/powerpc/platforms/ps3/repository.c | 77 2 files changed, 79 insertions(+) Looks good. Acked-by: Geoff Levand [EMAIL PROTECTED] ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [patch 4/7] ps3: Add repository polling loop to work around hypervisor bug
Geert Uytterhoeven wrote: ps3: Add repository polling loop to work around hypervisor bug On some firmware versions (e.g. 1.90), the storage device may not show up in the repository immediately after receiving the notification message. Add a small polling loop to make sure we don't miss it. Signed-off-by: Geert Uytterhoeven [EMAIL PROTECTED] --- arch/powerpc/platforms/ps3/device-init.c | 47 ++- 1 files changed, 34 insertions(+), 13 deletions(-) Acked-by: Geoff Levand [EMAIL PROTECTED] ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] MTD: pasemi_nand driver
On Wed, 2007-11-28 at 16:14 -0600, Olof Johansson wrote: Plumbing for NAND connected via localbus on PA Semi PWRficient-based boards. Any reason it lacks MODULE_DEVICE_TABLE() ? I note electra-ide lacks it too. So no autoload of either. -- dwmw2 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [patch 5/7] ps3: Kill unused ps3_repository_bump_device()
Geert Uytterhoeven wrote: ps3: Kill unused ps3_repository_bump_device() Signed-off-by: Geert Uytterhoeven [EMAIL PROTECTED] --- arch/powerpc/platforms/ps3/platform.h |6 -- 1 files changed, 6 deletions(-) Acked-by: Geoff Levand [EMAIL PROTECTED] ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Problems booting a 64k page kernel
Hello all. I am new to building 64k page kernels and can't seem to get one to boot correctly. Everything looks okay until init gets a signal 11 while booting. Attached is my boot log and the kernel config I used. To generate this config I merely enabled the 64k page option in make menuconfig to alter a previously working config. Any help you can provide would be greatly appreciated. -- Adam Litke - (agl at us.ibm.com) IBM Linux Technology Center # # Automatically generated make config: don't edit # Linux kernel version: 2.6.24-rc3 # Wed Nov 28 12:34:20 2007 # CONFIG_PPC64=y # # Processor support # # CONFIG_POWER4_ONLY is not set CONFIG_POWER3=y CONFIG_POWER4=y # CONFIG_TUNE_CELL is not set CONFIG_PPC_FPU=y CONFIG_ALTIVEC=y CONFIG_PPC_STD_MMU=y CONFIG_PPC_MM_SLICES=y CONFIG_VIRT_CPU_ACCOUNTING=y CONFIG_SMP=y CONFIG_NR_CPUS=32 CONFIG_64BIT=y CONFIG_WORD_SIZE=64 CONFIG_PPC_MERGE=y CONFIG_MMU=y CONFIG_GENERIC_CMOS_UPDATE=y CONFIG_GENERIC_TIME=y CONFIG_GENERIC_TIME_VSYSCALL=y CONFIG_GENERIC_CLOCKEVENTS=y CONFIG_GENERIC_HARDIRQS=y CONFIG_IRQ_PER_CPU=y CONFIG_RWSEM_XCHGADD_ALGORITHM=y CONFIG_ARCH_HAS_ILOG2_U32=y CONFIG_ARCH_HAS_ILOG2_U64=y CONFIG_GENERIC_HWEIGHT=y CONFIG_GENERIC_CALIBRATE_DELAY=y CONFIG_GENERIC_FIND_NEXT_BIT=y CONFIG_ARCH_NO_VIRT_TO_BUS=y CONFIG_PPC=y CONFIG_EARLY_PRINTK=y CONFIG_COMPAT=y CONFIG_SYSVIPC_COMPAT=y CONFIG_SCHED_NO_NO_OMIT_FRAME_POINTER=y CONFIG_ARCH_MAY_HAVE_PC_FDC=y CONFIG_PPC_OF=y CONFIG_OF=y CONFIG_PPC_UDBG_16550=y CONFIG_GENERIC_TBSYNC=y CONFIG_AUDIT_ARCH=y CONFIG_GENERIC_BUG=y # CONFIG_DEFAULT_UIMAGE is not set CONFIG_PPC64_SWSUSP=y # CONFIG_PPC_DCR_NATIVE is not set # CONFIG_PPC_DCR_MMIO is not set # CONFIG_PPC_OF_PLATFORM_PCI is not set CONFIG_DEFCONFIG_LIST=/lib/modules/$UNAME_RELEASE/.config # # General setup # CONFIG_EXPERIMENTAL=y CONFIG_LOCK_KERNEL=y CONFIG_INIT_ENV_ARG_LIMIT=32 CONFIG_LOCALVERSION= CONFIG_LOCALVERSION_AUTO=y CONFIG_SWAP=y CONFIG_SYSVIPC=y CONFIG_SYSVIPC_SYSCTL=y # CONFIG_POSIX_MQUEUE is not set # CONFIG_BSD_PROCESS_ACCT is not set # CONFIG_TASKSTATS is not set # CONFIG_USER_NS is not set # CONFIG_PID_NS is not set # CONFIG_AUDIT is not set # CONFIG_IKCONFIG is not set CONFIG_LOG_BUF_SHIFT=15 # CONFIG_CGROUPS is not set CONFIG_FAIR_GROUP_SCHED=y CONFIG_FAIR_USER_SCHED=y # CONFIG_FAIR_CGROUP_SCHED is not set CONFIG_SYSFS_DEPRECATED=y # CONFIG_RELAY is not set CONFIG_BLK_DEV_INITRD=y CONFIG_INITRAMFS_SOURCE= CONFIG_CC_OPTIMIZE_FOR_SIZE=y CONFIG_SYSCTL=y # CONFIG_EMBEDDED is not set CONFIG_SYSCTL_SYSCALL=y CONFIG_KALLSYMS=y # CONFIG_KALLSYMS_ALL is not set # CONFIG_KALLSYMS_EXTRA_PASS is not set CONFIG_HOTPLUG=y CONFIG_PRINTK=y CONFIG_BUG=y CONFIG_ELF_CORE=y CONFIG_BASE_FULL=y CONFIG_FUTEX=y CONFIG_ANON_INODES=y CONFIG_EPOLL=y CONFIG_SIGNALFD=y CONFIG_EVENTFD=y CONFIG_SHMEM=y CONFIG_VM_EVENT_COUNTERS=y CONFIG_SLUB_DEBUG=y # CONFIG_SLAB is not set CONFIG_SLUB=y # CONFIG_SLOB is not set CONFIG_RT_MUTEXES=y # CONFIG_TINY_SHMEM is not set CONFIG_BASE_SMALL=0 CONFIG_MODULES=y CONFIG_MODULE_UNLOAD=y # CONFIG_MODULE_FORCE_UNLOAD is not set # CONFIG_MODVERSIONS is not set # CONFIG_MODULE_SRCVERSION_ALL is not set # CONFIG_KMOD is not set CONFIG_STOP_MACHINE=y CONFIG_BLOCK=y # CONFIG_BLK_DEV_IO_TRACE is not set # CONFIG_BLK_DEV_BSG is not set CONFIG_BLOCK_COMPAT=y # # IO Schedulers # CONFIG_IOSCHED_NOOP=y CONFIG_IOSCHED_AS=y CONFIG_IOSCHED_DEADLINE=y CONFIG_IOSCHED_CFQ=y # CONFIG_DEFAULT_AS is not set # CONFIG_DEFAULT_DEADLINE is not set CONFIG_DEFAULT_CFQ=y # CONFIG_DEFAULT_NOOP is not set CONFIG_DEFAULT_IOSCHED=cfq # # Platform support # CONFIG_PPC_MULTIPLATFORM=y # CONFIG_PPC_82xx is not set # CONFIG_PPC_83xx is not set # CONFIG_PPC_86xx is not set CONFIG_PPC_PSERIES=y # CONFIG_PPC_SPLPAR is not set CONFIG_EEH=y CONFIG_SCANLOG=y # CONFIG_LPARCFG is not set # CONFIG_PPC_ISERIES is not set # CONFIG_PPC_MPC52xx is not set # CONFIG_PPC_MPC5200 is not set CONFIG_PPC_PMAC=y CONFIG_PPC_PMAC64=y # CONFIG_PPC_MAPLE is not set # CONFIG_PPC_PASEMI is not set # CONFIG_PPC_CELLEB is not set # CONFIG_PPC_PS3 is not set # CONFIG_PPC_CELL is not set # CONFIG_PPC_CELL_NATIVE is not set # CONFIG_PPC_IBM_CELL_BLADE is not set # CONFIG_PQ2ADS is not set CONFIG_PPC_NATIVE=y # CONFIG_UDBG_RTAS_CONSOLE is not set CONFIG_XICS=y CONFIG_MPIC=y # CONFIG_MPIC_WEIRD is not set CONFIG_PPC_I8259=y CONFIG_U3_DART=y CONFIG_PPC_RTAS=y CONFIG_RTAS_ERROR_LOGGING=y CONFIG_RTAS_PROC=y # CONFIG_RTAS_FLASH is not set # CONFIG_MMIO_NVRAM is not set CONFIG_MPIC_U3_HT_IRQS=y CONFIG_IBMVIO=y # CONFIG_IBMEBUS is not set # CONFIG_PPC_MPC106 is not set CONFIG_PPC_970_NAP=y # CONFIG_PPC_INDIRECT_IO is not set # CONFIG_GENERIC_IOMAP is not set # CONFIG_CPU_FREQ is not set # CONFIG_CPM2 is not set # CONFIG_FSL_ULI1575 is not set # # Kernel options # # CONFIG_TICK_ONESHOT is not set # CONFIG_NO_HZ is not set # CONFIG_HIGH_RES_TIMERS is not set CONFIG_GENERIC_CLOCKEVENTS_BUILD=y # CONFIG_HZ_100 is not set CONFIG_HZ_250=y # CONFIG_HZ_300 is not set # CONFIG_HZ_1000 is not set CONFIG_HZ=250
Re: PPC upstream kernel ignored DABR bug
Arnd Bergmann wrote: On Monday 26 November 2007, Jan Kratochvil wrote: Hi, this testcase: http://people.redhat.com/jkratoch/dabr-lost.c reproduces a PPC DABR kernel bug. The variable `variable' should not get modified as the thread modifying it should be caught by its DABR: $ ./dabr-lost TID 30914: DABR 0x10012a77 NIP 0x80f6ebb318 TID 30915: DABR 0x10012a77 NIP 0x80f6ebb318 TID 30916: DABR 0x10012a77 NIP 0x80f6ebb318 TID 30914: hitting the variable TID 30915: hitting the variable TID 30916: hitting the variable variable found = 30916, caught TID = 30914 TID 30916: DABR 0x10012a77 Variable got modified by a thread which has DABR still set! This sounds like a bug recently reported by Uli Weigand. BenH said he'd take a look, but it probably fell under the table. The problem found by Uli is that on certain processors (Cell/B.E. in his case), the DABRX register needs to be set in order for the DABR to take effect. Just as a note, the PS3's lv1_set_dabr(), which we used for ppc_md.set_dabr sets up both the DABRX and DABR registers. -Geoff ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [patch 7/7] ps3: denoise arch/powerpc/platforms/ps3/repository.c
Geert Uytterhoeven wrote: arch/powerpc/platforms/ps3/repository.c: sparse and checkpatch denoising Signed-off-by: Geert Uytterhoeven [EMAIL PROTECTED] Acked-by: Geoff Levand [EMAIL PROTECTED] ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 1/2] powerpc: add hugepagesz boot-time parameter
On Tue, 27 Nov 2007 23:03:10 -0600 Jon Tollefson wrote: This patch adds the hugepagesz boot-time parameter for ppc64 that lets you pick the size for your huge pages. The choices available are 64K and 16M. It defaults to 16M (previously the only choice) if nothing or an invalid choice is specified. Tested 64K huge pages with the libhugetlbfs 1.2 release with its 'make func' and 'make stress' test invocations. This patch requires the patch posted by Mel Gorman that adds HUGETLB_PAGE_SIZE_VARIABLE; [PATCH] Fix boot problem with iSeries lacking hugepage support on 2007-11-15. Signed-off-by: Jon Tollefson [EMAIL PROTECTED] --- Documentation/kernel-parameters.txt |1 arch/powerpc/mm/hash_utils_64.c | 11 + arch/powerpc/mm/hugetlbpage.c | 41 include/asm-powerpc/mmu-hash64.h|1 mm/hugetlb.c|1 5 files changed, 46 insertions(+), 9 deletions(-) diff --git a/Documentation/kernel-parameters.txt b/Documentation/kernel-parameters.txt index 33121d6..2fc1fb8 100644 --- a/Documentation/kernel-parameters.txt +++ b/Documentation/kernel-parameters.txt @@ -685,6 +685,7 @@ and is between 256 and 4096 characters. It is defined in the file See Documentation/isdn/README.HiSax. hugepages= [HW,X86-32,IA-64] Maximal number of HugeTLB pages. + hugepagesz= [HW,IA-64,PPC] The size of the HugeTLB pages. Any chance of spelling it as hugepagesize so that it's a little less cryptic and more difficult to typo as hugepages? (i.e., less confusion between them) i8042.direct[HW] Put keyboard port into non-translated mode i8042.dumbkbd [HW] Pretend that controller can only read data from Thanks. --- ~Randy ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Problems booting a 64k page kernel
On Wed, 2007-11-28 at 16:50 -0600, aglitke wrote: Hello all. I am new to building 64k page kernels and can't seem to get one to boot correctly. Everything looks okay until init gets a signal 11 while booting. Attached is my boot log and the kernel config I used. To generate this config I merely enabled the 64k page option in make menuconfig to alter a previously working config. Any help you can provide would be greatly appreciated. I've seen that happen with an init linked with uClibc, its dynamic loader was doing mmap with MAP_FIXED on non-64K aligned addresses. What user space are you using? cheers -- Michael Ellerman OzLabs, IBM Australia Development Lab wwweb: http://michael.ellerman.id.au phone: +61 2 6212 1183 (tie line 70 21183) We do not inherit the earth from our ancestors, we borrow it from our children. - S.M.A.R.T Person signature.asc Description: This is a digitally signed message part ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Timers on mpc8248 etc...
I've got a routine that needs to delay for X microseconds, this is a must. The command after schedule_timeout must has to wait for the HW to complete a task that takes X microseconds. I would think that one way to do this is with a simple schedule_timeout. But in the example below, the time that passes from run1() to dontrun() is far less than 3.2 msecs. Infact, sometimes its ~ 800 micros according the a analyzer looking at points triggered in run1() and donrun(). Could this be a configuration problem with the timer/interrupt that generates the jiffies? run1(); delaytime = 3280; set_current_state(TASK_UNINTERRUPTIBLE) ; schedule_timeout(usecs_to_jiffies(delaytime)); //1HZ = 1 second 1/1000 second = 1 milli dontrun(); ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Timers on mpc8248 etc...
Alan Bennett wrote: I've got a routine that needs to delay for X microseconds, this is a must. The command after schedule_timeout must has to wait for the HW to complete a task that takes X microseconds. I would think that one way to do this is with a simple schedule_timeout. But in the example below, the time that passes from run1() to dontrun() is far less than 3.2 msecs. Infact, sometimes its ~ 800 micros according the a analyzer looking at points triggered in run1() and donrun(). Could this be a configuration problem with the timer/interrupt that generates the jiffies? Are you sure the timebase frequency is set correctly in the device tree? -Scott ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: PPC upstream kernel ignored DABR bug
On Wednesday 28 November 2007 23:59:36 Geoff Levand wrote: This sounds like a bug recently reported by Uli Weigand. BenH said he'd take a look, but it probably fell under the table. The problem found by Uli is that on certain processors (Cell/B.E. in his case), the DABRX register needs to be set in order for the DABR to take effect. Just as a note, the PS3's lv1_set_dabr(), which we used for ppc_md.set_dabr sets up both the DABRX and DABR registers. Yes, I know. I tried it on the PS3 first and couldn't reproduce the bug he saw on the blade. Arnd ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] MTD: pasemi_nand driver
On Wed, Nov 28, 2007 at 10:40:32PM +, David Woodhouse wrote: On Wed, 2007-11-28 at 16:14 -0600, Olof Johansson wrote: Plumbing for NAND connected via localbus on PA Semi PWRficient-based boards. Any reason it lacks MODULE_DEVICE_TABLE() ? I note electra-ide lacks it too. So no autoload of either. Nope, no good reason. I'll add one. Josh pointed out stdfeedback.h, d.v.s of_platform.h as well so I have to repost with that too. -Olof ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH v2] MTD: pasemi_nand driver
Plumbing for NAND connected via localbus on PA Semi PWRficient-based
boards.
From: Egor Martovetsky [EMAIL PROTECTED]
Signed-off-by: Olof Johansson [EMAIL PROTECTED]
---
Changes from original post:
* asm/of_platform.h - linux/of_platform.h
* MODULE_DEVICE_TABLE()
drivers/mtd/nand/Kconfig |6
drivers/mtd/nand/Makefile |1
drivers/mtd/nand/pasemi_nand.c | 243 +
3 files changed, 250 insertions(+)
Index: 2.6.24/drivers/mtd/nand/Kconfig
===
--- 2.6.24.orig/drivers/mtd/nand/Kconfig
+++ 2.6.24/drivers/mtd/nand/Kconfig
@@ -283,6 +283,12 @@ config MTD_NAND_CM_X270
tristate Support for NAND Flash on CM-X270 modules
depends on MTD_NAND MACH_ARMCORE
+config MTD_NAND_PASEMI
+ tristate NAND support for PA Semi PWRficient
+ depends on MTD_NAND PPC_PASEMI
+ help
+ Enables support for NAND Flash interface on PA Semi PWRficient
+ based boards
config MTD_NAND_NANDSIM
tristate Support for NAND Flash Simulator
Index: 2.6.24/drivers/mtd/nand/Makefile
===
--- 2.6.24.orig/drivers/mtd/nand/Makefile
+++ 2.6.24/drivers/mtd/nand/Makefile
@@ -29,5 +29,6 @@ obj-$(CONFIG_MTD_NAND_CM_X270)+= cmx27
obj-$(CONFIG_MTD_NAND_BASLER_EXCITE) += excite_nandflash.o
obj-$(CONFIG_MTD_NAND_PLATFORM)+= plat_nand.o
obj-$(CONFIG_MTD_ALAUDA) += alauda.o
+obj-$(CONFIG_MTD_NAND_PASEMI) += pasemi_nand.o
nand-objs := nand_base.o nand_bbt.o
Index: 2.6.24/drivers/mtd/nand/pasemi_nand.c
===
--- /dev/null
+++ 2.6.24/drivers/mtd/nand/pasemi_nand.c
@@ -0,0 +1,243 @@
+/*
+ * Copyright (C) 2006-2007 PA Semi, Inc
+ *
+ * Author: Egor Martovetsky [EMAIL PROTECTED]
+ * Maintained by: Olof Johansson [EMAIL PROTECTED]
+ *
+ * Driver for the PWRficient onchip NAND flash interface
+ *
+ * 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.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
+ */
+
+#undef DEBUG
+
+#include linux/slab.h
+#include linux/init.h
+#include linux/module.h
+#include linux/mtd/mtd.h
+#include linux/mtd/nand.h
+#include linux/mtd/nand_ecc.h
+#include linux/of_platform.h
+#include linux/platform_device.h
+#include linux/pci.h
+
+#include asm/io.h
+
+#define LBICTRL_LPCCTL_NR 0x4000
+#define CLE_PIN_CTL15
+#define ALE_PIN_CTL14
+
+static unsigned int lpcctl;
+static struct mtd_info *pasemi_nand_mtd;
+static const char driver_name[] = pasemi-nand;
+
+static void pasemi_read_buf(struct mtd_info *mtd, u_char *buf, int len)
+{
+ struct nand_chip *chip = mtd-priv;
+
+ while (len 0x800) {
+ memcpy_fromio(buf, chip-IO_ADDR_R, 0x800);
+ buf += 0x800;
+ len -= 0x800;
+ }
+ memcpy_fromio(buf, chip-IO_ADDR_R, len);
+}
+
+static void pasemi_write_buf(struct mtd_info *mtd, const u_char *buf, int len)
+{
+ struct nand_chip *chip = mtd-priv;
+
+ while (len 0x800) {
+ memcpy_toio(chip-IO_ADDR_R, buf, 0x800);
+ buf += 0x800;
+ len -= 0x800;
+ }
+ memcpy_toio(chip-IO_ADDR_R, buf, len);
+}
+
+static void pasemi_hwcontrol(struct mtd_info *mtd, int cmd,
+unsigned int ctrl)
+{
+ struct nand_chip *chip = mtd-priv;
+
+ if (cmd == NAND_CMD_NONE)
+ return;
+
+ if (ctrl NAND_CLE)
+ out_8(chip-IO_ADDR_W + (1 CLE_PIN_CTL), cmd);
+ else
+ out_8(chip-IO_ADDR_W + (1 ALE_PIN_CTL), cmd);
+
+ /* Push out posted writes */
+ eieio();
+ inl(lpcctl);
+}
+
+int pasemi_device_ready(struct mtd_info *mtd)
+{
+ return !!(inl(lpcctl) LBICTRL_LPCCTL_NR);
+}
+
+static int __devinit pasemi_nand_probe(struct of_device *ofdev,
+ const struct of_device_id *match)
+{
+ struct pci_dev *pdev;
+ struct device_node *np = ofdev-node;
+ struct resource res;
+ struct nand_chip *chip;
+ int err = 0;
+
+ err = of_address_to_resource(np, 0, res);
+
+ if (err)
+ return -EINVAL;
+
+ /* We only support one device at the moment */
+ if (pasemi_nand_mtd)
+ return -ENODEV;
+
+
Re: 2.6.24-rc3-mm2 - Build Failure on powerpc timerfd() undeclared
On Wednesday 28 November 2007 19:43:45 Andrew Morton wrote:
I guess all architectures except x86 are currently broken because they
reference the old sys_timerfd function.
None of them were broken in my testing and I'm unsure why powerpc broke
here.
PowerPC is unique in that it actually relies on the declarations
in include/{linux,asm}/syscalls.h to be present, because the
spu_syscall_table is generated from C code, not from assembly.
One reason why I did this was to be sure to find this exact
type of problem at compile-time, not at link time.
Arnd
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 1/2] powerpc: add hugepagesz boot-time parameter
On 11/28/07, Randy Dunlap [EMAIL PROTECTED] wrote: On Tue, 27 Nov 2007 23:03:10 -0600 Jon Tollefson wrote: This patch adds the hugepagesz boot-time parameter for ppc64 that lets you pick the size for your huge pages. The choices available are 64K and 16M. It defaults to 16M (previously the only choice) if nothing or an invalid choice is specified. Tested 64K huge pages with the libhugetlbfs 1.2 release with its 'make func' and 'make stress' test invocations. This patch requires the patch posted by Mel Gorman that adds HUGETLB_PAGE_SIZE_VARIABLE; [PATCH] Fix boot problem with iSeries lacking hugepage support on 2007-11-15. Signed-off-by: Jon Tollefson [EMAIL PROTECTED] --- Documentation/kernel-parameters.txt |1 arch/powerpc/mm/hash_utils_64.c | 11 + arch/powerpc/mm/hugetlbpage.c | 41 include/asm-powerpc/mmu-hash64.h|1 mm/hugetlb.c|1 5 files changed, 46 insertions(+), 9 deletions(-) diff --git a/Documentation/kernel-parameters.txt b/Documentation/kernel-parameters.txt index 33121d6..2fc1fb8 100644 --- a/Documentation/kernel-parameters.txt +++ b/Documentation/kernel-parameters.txt @@ -685,6 +685,7 @@ and is between 256 and 4096 characters. It is defined in the file See Documentation/isdn/README.HiSax. hugepages= [HW,X86-32,IA-64] Maximal number of HugeTLB pages. + hugepagesz= [HW,IA-64,PPC] The size of the HugeTLB pages. Any chance of spelling it as hugepagesize so that it's a little less cryptic and more difficult to typo as hugepages? (i.e., less confusion between them) It already exists as hugepagesz= for IA64. Changing it to hugepagesize would either make ppc be different than IA64, or require keeping both so as to make IA64 setups continue working as before? Thanks, Nish ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 2/3] [libata] pata_of_platform: OF-Platform PATA device driver
On Wed, Nov 28, 2007 at 07:11:19PM +0300, Sergei Shtylyov wrote:
Anton Vorontsov wrote:
This driver nicely wraps around pata_platform library functions,
and provides OF platform bus bindings to the PATA devices.
+static struct of_device_id pata_of_platform_match[] = {
+ { .compatible = pata-platform, },
+};
pata-platform really means nothing outside of linux. A more
generic label would be useful.
Agreed.
Now you're quick to agree. :-)
I'm quick to change my mind either. ;-)
*BOOM*, I changed my mind.
Maybe the name of the standards it supports? Could be
ata-4, ata-5 and the like, or the exact transfer mode, like
pata-udma-5, pata-pio-3, sata-150, etc.
You're quite optimistic about pata_platform capabilities. ;-)
Indeed. :-)
As far as I know it is [obviously] supports PIO modes only. And so
far I was able to get max 5.28 MB/s read transfers. Which looks like
ideal case for PIO1 (CF I'm testing on is 3.0, max. PIO4).
Believe me, it's a great speed even for PIO4. Most systems only show 3+
MiB/s in this mode according to hdparm.
I've modified pio_mask appropriately, plus I've tried to comment
out .set_mode = pata_platform_set_mode, and now it says:
ata5: PATA max PIO4 mmio cmd 0xf000 ctl 0xf20c irq 24
ata5.00: CFA: TOSHIBA THNCF512MQG, 3.00, max PIO4
ata5.00: configured for PIO4
ata5.00: configured for PIO4
That looks good, but speed is the same. Oh well, it's another
matter.
Back to dts, I think pata-pio-X is good scheme. That way we can
pass pio_mask via device tree. Sounds reasonable?
Grumble. Can't we pass this via some property other than compatible?
I'm
opposed to ata-5 and the like in there as well cause it's not clear what
information this would provide. Why people so love to make things complex WRT
the compatible property -- instead of making the task of selecting a proper
driver more simple, they tend to make it mode complex by trying to specify
values that have quite little to do with the device's programming interface
itself...
Ok, now I'm agree here. dts already specifying fsl,mpc8349emitx-pata,
second compatible entry is okay to mean nothing outside Linux itself,
there are plenty of examples for such kind.
Remaining question: any preferred name for that property? pio-mode okay?
It's assuming that PIO6 capable bus supports PIO0 as well, thus no mask.
--
Anton Vorontsov
email: [EMAIL PROTECTED]
backup email: [EMAIL PROTECTED]
irc://irc.freenode.net/bd2
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH] [9/12] pasemi_mac: SKB unmap optimization
pasemi_mac: SKB unmap optimization
Avoid touching skb_shinfo() in the unmap path, since it turns out to
normally cause cache misses and delays. instead, save number of fragments
in the TX_RING_INFO structures since that's all that's needed anyway.
Signed-off-by: Olof Johansson [EMAIL PROTECTED]
---
drivers/net/pasemi_mac.c | 39 +--
1 file changed, 25 insertions(+), 14 deletions(-)
Index: k.org/drivers/net/pasemi_mac.c
===
--- k.org.orig/drivers/net/pasemi_mac.c
+++ k.org/drivers/net/pasemi_mac.c
@@ -253,11 +253,11 @@ static int get_skb_hdr(struct sk_buff *s
}
static int pasemi_mac_unmap_tx_skb(struct pasemi_mac *mac,
+ const int nfrags,
struct sk_buff *skb,
const dma_addr_t *dmas)
{
int f;
- int nfrags = skb_shinfo(skb)-nr_frags;
struct pci_dev *pdev = mac-dma_pdev;
pci_unmap_single(pdev, dmas[0], skb_headlen(skb), PCI_DMA_TODEVICE);
@@ -425,7 +425,7 @@ static void pasemi_mac_free_tx_resources
unsigned int i, j;
struct pasemi_mac_buffer *info;
dma_addr_t dmas[MAX_SKB_FRAGS+1];
- int freed;
+ int freed, nfrags;
int start, limit;
start = txring-next_to_clean;
@@ -438,10 +438,12 @@ static void pasemi_mac_free_tx_resources
for (i = start; i limit; i += freed) {
info = txring-ring_info[(i+1) (TX_RING_SIZE-1)];
if (info-dma info-skb) {
- for (j = 0; j = skb_shinfo(info-skb)-nr_frags; j++)
+ nfrags = skb_shinfo(info-skb)-nr_frags;
+ for (j = 0; j = nfrags; j++)
dmas[j] = txring-ring_info[(i+1+j)
(TX_RING_SIZE-1)].dma;
- freed = pasemi_mac_unmap_tx_skb(mac, info-skb, dmas);
+ freed = pasemi_mac_unmap_tx_skb(mac, nfrags,
+ info-skb, dmas);
} else
freed = 2;
}
@@ -749,6 +751,8 @@ static int pasemi_mac_clean_tx(struct pa
unsigned long flags;
struct sk_buff *skbs[TX_CLEAN_BATCHSIZE];
dma_addr_t dmas[TX_CLEAN_BATCHSIZE][MAX_SKB_FRAGS+1];
+ int nf[TX_CLEAN_BATCHSIZE];
+ int nr_frags;
total_count = 0;
batch_limit = TX_CLEAN_BATCHSIZE;
@@ -758,6 +762,8 @@ restart:
start = txring-next_to_clean;
ring_limit = txring-next_to_fill;
+ prefetch(TX_DESC_INFO(txring, start+1).skb);
+
/* Compensate for when fill has wrapped but clean has not */
if (start ring_limit)
ring_limit += TX_RING_SIZE;
@@ -771,6 +777,9 @@ restart:
u64 mactx = TX_DESC(txring, i);
struct sk_buff *skb;
+ skb = TX_DESC_INFO(txring, i+1).skb;
+ nr_frags = TX_DESC_INFO(txring, i).dma;
+
if ((mactx XCT_MACTX_E) ||
(*chan-status PAS_STATUS_ERROR))
pasemi_mac_tx_error(mac, mactx);
@@ -779,21 +788,22 @@ restart:
/* Not yet transmitted */
break;
- skb = TX_DESC_INFO(txring, i+1).skb;
- skbs[descr_count] = skb;
+ buf_count = 2 + nr_frags;
+ /* Since we always fill with an even number of entries, make
+* sure we skip any unused one at the end as well.
+*/
+ if (buf_count 1)
+ buf_count++;
- buf_count = 2 + skb_shinfo(skb)-nr_frags;
- for (j = 0; j = skb_shinfo(skb)-nr_frags; j++)
+ for (j = 0; j = nr_frags; j++)
dmas[descr_count][j] = TX_DESC_INFO(txring, i+1+j).dma;
+ skbs[descr_count] = skb;
+ nf[descr_count] = nr_frags;
+
TX_DESC(txring, i) = 0;
TX_DESC(txring, i+1) = 0;
- /* Since we always fill with an even number of entries, make
-* sure we skip any unused one at the end as well.
-*/
- if (buf_count 1)
- buf_count++;
descr_count++;
}
txring-next_to_clean = i (TX_RING_SIZE-1);
@@ -802,7 +812,7 @@ restart:
netif_wake_queue(mac-netdev);
for (i = 0; i descr_count; i++)
- pasemi_mac_unmap_tx_skb(mac, skbs[i], dmas[i]);
+ pasemi_mac_unmap_tx_skb(mac, nf[i], skbs[i], dmas[i]);
total_count += descr_count;
@@ -1299,6 +1309,7 @@ static int pasemi_mac_start_tx(struct sk
}
TX_DESC(txring, fill) = mactx;
+ TX_DESC_INFO(txring, fill).dma = nfrags;
fill++;
TX_DESC_INFO(txring, fill).skb = skb;
for
[PATCH] [7/12] pasemi_mac: Improve RX interrupt mitigation
pasemi_mac: Improve RX interrupt mitigation
Currently the receive side interrupts will go off on the reception of
a packet, NAPI will poll the ring and keep polling as long as there's
a decent amount of packets to receive.
This is less than optimal, especially for LRO where it's better if we
have a more substantial amount of packets to process at once, to get
the real LRO benefits.
So, set the count threshold to a higher value and use the timeout feature
that will give us an interrupt even if not enough packets have come in
to set off the count threshold.
FIXME: It'd be real nice to have ethtool support for users to tune this
at runtime.
Signed-off-by: Olof Johansson [EMAIL PROTECTED]
---
drivers/net/pasemi_mac.c | 18 ++
1 file changed, 10 insertions(+), 8 deletions(-)
Index: k.org/drivers/net/pasemi_mac.c
===
--- k.org.orig/drivers/net/pasemi_mac.c
+++ k.org/drivers/net/pasemi_mac.c
@@ -504,15 +504,19 @@ static void pasemi_mac_replenish_rx_ring
static void pasemi_mac_restart_rx_intr(const struct pasemi_mac *mac)
{
+ struct pasemi_mac_rxring *rx = rx_ring(mac);
unsigned int reg, pcnt;
/* Re-enable packet count interrupts: finally
* ack the packet count interrupt we got in rx_intr.
*/
- pcnt = *rx_ring(mac)-chan.status PAS_STATUS_PCNT_M;
+ pcnt = *rx-chan.status PAS_STATUS_PCNT_M;
reg = PAS_IOB_DMA_RXCH_RESET_PCNT(pcnt) | PAS_IOB_DMA_RXCH_RESET_PINTC;
+ if (*rx-chan.status PAS_STATUS_TIMER)
+ reg |= PAS_IOB_DMA_RXCH_RESET_TINTC;
+
write_iob_reg(PAS_IOB_DMA_RXCH_RESET(mac-rx-chan.chno), reg);
}
@@ -795,8 +799,6 @@ static irqreturn_t pasemi_mac_rx_intr(in
reg |= PAS_IOB_DMA_RXCH_RESET_SINTC;
if (*chan-status PAS_STATUS_ERROR)
reg |= PAS_IOB_DMA_RXCH_RESET_DINTC;
- if (*chan-status PAS_STATUS_TIMER)
- reg |= PAS_IOB_DMA_RXCH_RESET_TINTC;
netif_rx_schedule(dev, mac-napi);
@@ -972,10 +974,6 @@ static int pasemi_mac_open(struct net_de
write_mac_reg(mac, PAS_MAC_CFG_TXP, flags);
- /* 0xff is max value, about 16ms */
- write_iob_reg(PAS_IOB_DMA_COM_TIMEOUTCFG,
- PAS_IOB_DMA_COM_TIMEOUTCFG_TCNT(0xff));
-
ret = pasemi_mac_setup_rx_resources(dev);
if (ret)
goto out_rx_resources;
@@ -985,8 +983,12 @@ static int pasemi_mac_open(struct net_de
if (!mac-tx)
goto out_tx_ring;
+ /* 0x3ff with 33MHz clock is about 31us */
+ write_iob_reg(PAS_IOB_DMA_COM_TIMEOUTCFG,
+ PAS_IOB_DMA_COM_TIMEOUTCFG_TCNT(0x3ff));
+
write_iob_reg(PAS_IOB_DMA_RXCH_CFG(mac-rx-chan.chno),
- PAS_IOB_DMA_RXCH_CFG_CNTTH(0));
+ PAS_IOB_DMA_RXCH_CFG_CNTTH(128));
write_iob_reg(PAS_IOB_DMA_TXCH_CFG(mac-tx-chan.chno),
PAS_IOB_DMA_TXCH_CFG_CNTTH(32));
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH] [3/12] pasemi: DMA engine management library
pasemi: DMA engine management library
Introduce a DMA management library to manage the various DMA resources
on the PA Semi SoCs. Since several drivers need to allocate these shared
resources, provide some abstractions as well as allocation/free functions
for channels, etc.
Signed-off-by: Olof Johansson [EMAIL PROTECTED]
---
arch/powerpc/platforms/pasemi/Makefile |2
arch/powerpc/platforms/pasemi/dma_lib.c | 487
arch/powerpc/platforms/pasemi/pasemi.h |1
include/asm-powerpc/pasemi_dma.h| 76
4 files changed, 565 insertions(+), 1 deletion(-)
Index: k.org/arch/powerpc/platforms/pasemi/Makefile
===
--- k.org.orig/arch/powerpc/platforms/pasemi/Makefile
+++ k.org/arch/powerpc/platforms/pasemi/Makefile
@@ -1,4 +1,4 @@
-obj-y += setup.o pci.o time.o idle.o powersave.o iommu.o
+obj-y += setup.o pci.o time.o idle.o powersave.o iommu.o dma_lib.o
obj-$(CONFIG_PPC_PASEMI_MDIO) += gpio_mdio.o
obj-$(CONFIG_ELECTRA_IDE) += electra_ide.o
obj-$(CONFIG_PPC_PASEMI_CPUFREQ) += cpufreq.o
Index: k.org/arch/powerpc/platforms/pasemi/dma_lib.c
===
--- /dev/null
+++ k.org/arch/powerpc/platforms/pasemi/dma_lib.c
@@ -0,0 +1,487 @@
+/*
+ * Copyright (C) 2006-2007 PA Semi, Inc
+ *
+ * Common functions for DMA access on PA Semi PWRficient
+ *
+ * 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.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
+ */
+
+#include linux/init.h
+#include linux/module.h
+#include linux/pci.h
+#include linux/of.h
+
+#include asm/pasemi_dma.h
+
+#define MAX_TXCH 64
+#define MAX_RXCH 64
+
+static struct pasdma_status *dma_status;
+
+static void __iomem *iob_regs;
+static void __iomem *mac_regs[6];
+static void __iomem *dma_regs;
+
+static int base_hw_irq;
+
+static int num_txch, num_rxch;
+
+static struct pci_dev *dma_pdev;
+
+/* Bitmaps to handle allocation of channels */
+
+static DECLARE_BITMAP(txch_free, MAX_TXCH);
+static DECLARE_BITMAP(rxch_free, MAX_RXCH);
+
+/* pasemi_read_iob_reg - read IOB register
+ * @reg: Register to read (offset into PCI CFG space)
+ */
+unsigned int pasemi_read_iob_reg(unsigned int reg)
+{
+ return in_le32(iob_regs+reg);
+}
+EXPORT_SYMBOL(pasemi_read_iob_reg);
+
+/* pasemi_write_iob_reg - write IOB register
+ * @reg: Register to write to (offset into PCI CFG space)
+ * @val: Value to write
+ */
+void pasemi_write_iob_reg(unsigned int reg, unsigned int val)
+{
+ out_le32(iob_regs+reg, val);
+}
+EXPORT_SYMBOL(pasemi_write_iob_reg);
+
+/* pasemi_read_mac_reg - read MAC register
+ * @intf: MAC interface
+ * @reg: Register to read (offset into PCI CFG space)
+ */
+unsigned int pasemi_read_mac_reg(int intf, unsigned int reg)
+{
+ return in_le32(mac_regs[intf]+reg);
+}
+EXPORT_SYMBOL(pasemi_read_mac_reg);
+
+/* pasemi_write_mac_reg - write MAC register
+ * @intf: MAC interface
+ * @reg: Register to write to (offset into PCI CFG space)
+ * @val: Value to write
+ */
+void pasemi_write_mac_reg(int intf, unsigned int reg, unsigned int val)
+{
+ out_le32(mac_regs[intf]+reg, val);
+}
+EXPORT_SYMBOL(pasemi_write_mac_reg);
+
+/* pasemi_read_dma_reg - read DMA register
+ * @reg: Register to read (offset into PCI CFG space)
+ */
+unsigned int pasemi_read_dma_reg(unsigned int reg)
+{
+ return in_le32(dma_regs+reg);
+}
+EXPORT_SYMBOL(pasemi_read_dma_reg);
+
+/* pasemi_write_dma_reg - write DMA register
+ * @reg: Register to write to (offset into PCI CFG space)
+ * @val: Value to write
+ */
+void pasemi_write_dma_reg(unsigned int reg, unsigned int val)
+{
+ out_le32(dma_regs+reg, val);
+}
+EXPORT_SYMBOL(pasemi_write_dma_reg);
+
+static int pasemi_alloc_tx_chan(enum pasemi_dmachan_type type)
+{
+ int bit;
+ int start, limit;
+
+ switch (type (TXCHAN_EVT0|TXCHAN_EVT1)) {
+ case TXCHAN_EVT0:
+ start = 0;
+ limit = 10;
+ break;
+ case TXCHAN_EVT1:
+ start = 10;
+ limit = MAX_TXCH;
+ break;
+ default:
+ start = 0;
+ limit = MAX_TXCH;
+ break;
+ }
+retry:
+ bit = find_next_bit(txch_free, MAX_TXCH, start);
+ if (bit = limit)
+ return -ENOSPC;
+ if (!test_and_clear_bit(bit, txch_free))
+ goto retry;
+
+ return
[PATCH] [2/12] pasemi_mac: Move register definitions to include/asm-powerpc
pasemi_mac: Move register definitions to include/asm-powerpc
Move the common register formats and descriptor layouts from
drivers/net/pasemi_mac.h to include/asm-poewrpc/pasemi_dma.h
Previously only the ethernet driver was using them, but other drivers
are coming up that will also use them, so it makes sense to share the
constants.
Signed-off-by: Olof Johansson [EMAIL PROTECTED]
---
drivers/net/pasemi_mac.c |1
drivers/net/pasemi_mac.h | 336 -
include/asm-powerpc/pasemi_dma.h | 391 +++
3 files changed, 394 insertions(+), 334 deletions(-)
Index: k.org/include/asm-powerpc/pasemi_dma.h
===
--- /dev/null
+++ k.org/include/asm-powerpc/pasemi_dma.h
@@ -0,0 +1,391 @@
+/*
+ * Copyright (C) 2006 PA Semi, Inc
+ *
+ * Hardware register layout and descriptor formats for the on-board
+ * DMA engine on PA Semi PWRficient. Used by ethernet, function and security
+ * drivers.
+ *
+ * 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.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
+ */
+
+#ifndef ASM_PASEMI_DMA_H
+#define ASM_PASEMI_DMA_H
+
+/* status register layout in IOB region, at 0xfb80 */
+struct pasdma_status {
+ u64 rx_sta[64]; /* RX channel status */
+ u64 tx_sta[20]; /* TX channel status */
+};
+
+
+/* All these registers live in the PCI configuration space for the DMA PCI
+ * device. Use the normal PCI config access functions for them.
+ */
+enum {
+ PAS_DMA_COM_TXCMD = 0x100, /* Transmit Command Register */
+ PAS_DMA_COM_TXSTA = 0x104, /* Transmit Status Register */
+ PAS_DMA_COM_RXCMD = 0x108, /* Receive Command Register */
+ PAS_DMA_COM_RXSTA = 0x10c, /* Receive Status Register*/
+};
+#define PAS_DMA_COM_TXCMD_EN 0x0001 /* enable */
+#define PAS_DMA_COM_TXSTA_ACT 0x0001 /* active */
+#define PAS_DMA_COM_RXCMD_EN 0x0001 /* enable */
+#define PAS_DMA_COM_RXSTA_ACT 0x0001 /* active */
+
+
+/* Per-interface and per-channel registers */
+#define _PAS_DMA_RXINT_STRIDE 0x20
+#define PAS_DMA_RXINT_RCMDSTA(i) (0x200+(i)*_PAS_DMA_RXINT_STRIDE)
+#definePAS_DMA_RXINT_RCMDSTA_EN0x0001
+#definePAS_DMA_RXINT_RCMDSTA_ST0x0002
+#definePAS_DMA_RXINT_RCMDSTA_MBT 0x0008
+#definePAS_DMA_RXINT_RCMDSTA_MDR 0x0010
+#definePAS_DMA_RXINT_RCMDSTA_MOO 0x0020
+#definePAS_DMA_RXINT_RCMDSTA_MBP 0x0040
+#definePAS_DMA_RXINT_RCMDSTA_BT0x0800
+#definePAS_DMA_RXINT_RCMDSTA_DR0x1000
+#definePAS_DMA_RXINT_RCMDSTA_OO0x2000
+#definePAS_DMA_RXINT_RCMDSTA_BP0x4000
+#definePAS_DMA_RXINT_RCMDSTA_TB0x8000
+#definePAS_DMA_RXINT_RCMDSTA_ACT 0x0001
+#definePAS_DMA_RXINT_RCMDSTA_DROPS_M 0xfffe
+#definePAS_DMA_RXINT_RCMDSTA_DROPS_S 17
+#define PAS_DMA_RXINT_CFG(i) (0x204+(i)*_PAS_DMA_RXINT_STRIDE)
+#definePAS_DMA_RXINT_CFG_RBP 0x8000
+#definePAS_DMA_RXINT_CFG_ITRR 0x4000
+#definePAS_DMA_RXINT_CFG_DHL_M 0x0700
+#definePAS_DMA_RXINT_CFG_DHL_S 24
+#definePAS_DMA_RXINT_CFG_DHL(x)(((x) PAS_DMA_RXINT_CFG_DHL_S) \
+PAS_DMA_RXINT_CFG_DHL_M)
+#definePAS_DMA_RXINT_CFG_ITR 0x0040
+#definePAS_DMA_RXINT_CFG_LW0x0020
+#definePAS_DMA_RXINT_CFG_L20x0010
+#definePAS_DMA_RXINT_CFG_HEN 0x0008
+#definePAS_DMA_RXINT_CFG_WIF 0x0002
+#definePAS_DMA_RXINT_CFG_WIL 0x0001
+
+#define PAS_DMA_RXINT_INCR(i) (0x210+(i)*_PAS_DMA_RXINT_STRIDE)
+#definePAS_DMA_RXINT_INCR_INCR_M 0x
+#definePAS_DMA_RXINT_INCR_INCR_S 0
+#definePAS_DMA_RXINT_INCR_INCR(x) ((x) 0x)
+#define PAS_DMA_RXINT_BASEL(i) (0x218+(i)*_PAS_DMA_RXINT_STRIDE)
+#definePAS_DMA_RXINT_BASEL_BRBL(x) ((x) ~0x3f)
+#define PAS_DMA_RXINT_BASEU(i) (0x21c+(i)*_PAS_DMA_RXINT_STRIDE)
+#definePAS_DMA_RXINT_BASEU_BRBH(x) ((x) 0xfff)
+#definePAS_DMA_RXINT_BASEU_SIZ_M 0x3fff /* # of cache lines
worth of buffer ring */
+#definePAS_DMA_RXINT_BASEU_SIZ_S 16 /* 0 = 16K */
+#definePAS_DMA_RXINT_BASEU_SIZ(x) (((x) PAS_DMA_RXINT_BASEU_SIZ_S) \
+
[PATCH] [11/12] pasemi_mac: Print warning when not attaching to a PHY
pasemi_mac: Print warning when not attaching to a PHY
Print a warning on the console when not connecting to a phy for an interface.
It turns out to be a pretty common problem when someone gets the MDIO info
wrong in their device tree, resulting in the macs running at a fixed 1Gbit FD.
Signed-off-by: Olof Johansson [EMAIL PROTECTED]
---
drivers/net/pasemi_mac.c |9 +
1 file changed, 5 insertions(+), 4 deletions(-)
Index: k.org/drivers/net/pasemi_mac.c
===
--- k.org.orig/drivers/net/pasemi_mac.c
+++ k.org/drivers/net/pasemi_mac.c
@@ -1064,11 +1064,12 @@ static int pasemi_mac_open(struct net_de
write_mac_reg(mac, PAS_MAC_CFG_PCFG, flags);
ret = pasemi_mac_phy_init(dev);
- /* Some configs don't have PHYs (XAUI etc), so don't complain about
-* failed init due to -ENODEV.
+ /* Warn for missing PHY on SGMII (1Gig) ports.
*/
- if (ret ret != -ENODEV)
- dev_warn(mac-pdev-dev, phy init failed: %d\n, ret);
+ if (ret mac-type == MAC_TYPE_GMAC) {
+ dev_warn(mac-pdev-dev, PHY init failed: %d.\n, ret);
+ dev_warn(mac-pdev-dev, Defaulting to 1Gbit full duplex\n);
+ }
netif_start_queue(dev);
napi_enable(mac-napi);
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH] [1/12] pasemi_mac: RX/TX ring management cleanup
pasemi_mac: RX/TX ring management cleanup
Prepare a bit for supporting multiple TX queues by cleaning up some
of the ring management and shuffle things around a bit.
Signed-off-by: Olof Johansson [EMAIL PROTECTED]
---
drivers/net/pasemi_mac.c | 277 ---
drivers/net/pasemi_mac.h | 19 +--
2 files changed, 157 insertions(+), 139 deletions(-)
Index: k.org/drivers/net/pasemi_mac.c
===
--- k.org.orig/drivers/net/pasemi_mac.c
+++ k.org/drivers/net/pasemi_mac.c
@@ -68,11 +68,11 @@
NETIF_MSG_RX_ERR | \
NETIF_MSG_TX_ERR)
-#define TX_RING(mac, num) ((mac)-tx-ring[(num) (TX_RING_SIZE-1)])
-#define TX_RING_INFO(mac, num) ((mac)-tx-ring_info[(num) (TX_RING_SIZE-1)])
-#define RX_RING(mac, num) ((mac)-rx-ring[(num) (RX_RING_SIZE-1)])
-#define RX_RING_INFO(mac, num) ((mac)-rx-ring_info[(num) (RX_RING_SIZE-1)])
-#define RX_BUFF(mac, num) ((mac)-rx-buffers[(num) (RX_RING_SIZE-1)])
+#define TX_DESC(tx, num) ((tx)-ring[(num) (TX_RING_SIZE-1)])
+#define TX_DESC_INFO(tx, num) ((tx)-ring_info[(num) (TX_RING_SIZE-1)])
+#define RX_DESC(rx, num) ((rx)-ring[(num) (RX_RING_SIZE-1)])
+#define RX_DESC_INFO(rx, num) ((rx)-ring_info[(num) (RX_RING_SIZE-1)])
+#define RX_BUFF(rx, num) ((rx)-buffers[(num) (RX_RING_SIZE-1)])
#define RING_USED(ring)(((ring)-next_to_fill -
(ring)-next_to_clean) \
((ring)-size - 1))
@@ -127,6 +127,16 @@ static void write_dma_reg(struct pasemi_
out_le32(mac-dma_regs+reg, val);
}
+static struct pasemi_mac_rxring *rx_ring(struct pasemi_mac *mac)
+{
+ return mac-rx;
+}
+
+static struct pasemi_mac_txring *tx_ring(struct pasemi_mac *mac)
+{
+ return mac-tx;
+}
+
static int pasemi_get_mac_addr(struct pasemi_mac *mac)
{
struct pci_dev *pdev = mac-pdev;
@@ -269,8 +279,8 @@ static int pasemi_mac_setup_rx_resources
ring-next_to_fill = 0;
ring-next_to_clean = 0;
- snprintf(ring-irq_name, sizeof(ring-irq_name),
-%s rx, dev-name);
+ ring-status = dma_status-rx_sta[mac-dma_rxch];
+ ring-mac = mac;
mac-rx = ring;
return 0;
@@ -278,7 +288,7 @@ static int pasemi_mac_setup_rx_resources
out_buffers:
dma_free_coherent(mac-dma_pdev-dev,
RX_RING_SIZE * sizeof(u64),
- mac-rx-ring, mac-rx-dma);
+ rx_ring(mac)-ring, rx_ring(mac)-dma);
out_ring_desc:
kfree(ring-ring_info);
out_ring_info:
@@ -287,12 +297,11 @@ out_ring:
return -ENOMEM;
}
-
-static int pasemi_mac_setup_tx_resources(struct net_device *dev)
+static struct pasemi_mac_txring *
+pasemi_mac_setup_tx_resources(struct net_device *dev, int txch)
{
struct pasemi_mac *mac = netdev_priv(dev);
u32 val;
- int chan_id = mac-dma_txch;
struct pasemi_mac_txring *ring;
unsigned int cfg;
@@ -317,12 +326,12 @@ static int pasemi_mac_setup_tx_resources
memset(ring-ring, 0, TX_RING_SIZE * sizeof(u64));
- write_dma_reg(mac, PAS_DMA_TXCHAN_BASEL(chan_id),
+ write_dma_reg(mac, PAS_DMA_TXCHAN_BASEL(txch),
PAS_DMA_TXCHAN_BASEL_BRBL(ring-dma));
val = PAS_DMA_TXCHAN_BASEU_BRBH(ring-dma 32);
val |= PAS_DMA_TXCHAN_BASEU_SIZ(TX_RING_SIZE 3);
- write_dma_reg(mac, PAS_DMA_TXCHAN_BASEU(chan_id), val);
+ write_dma_reg(mac, PAS_DMA_TXCHAN_BASEU(txch), val);
cfg = PAS_DMA_TXCHAN_CFG_TY_IFACE |
PAS_DMA_TXCHAN_CFG_TATTR(mac-dma_if) |
@@ -332,71 +341,70 @@ static int pasemi_mac_setup_tx_resources
if (translation_enabled())
cfg |= PAS_DMA_TXCHAN_CFG_TRD | PAS_DMA_TXCHAN_CFG_TRR;
- write_dma_reg(mac, PAS_DMA_TXCHAN_CFG(chan_id), cfg);
+ write_dma_reg(mac, PAS_DMA_TXCHAN_CFG(txch), cfg);
ring-next_to_fill = 0;
ring-next_to_clean = 0;
+ ring-status = dma_status-tx_sta[txch];
+ ring-chan = txch;
+ ring-mac = mac;
- snprintf(ring-irq_name, sizeof(ring-irq_name),
-%s tx, dev-name);
- mac-tx = ring;
-
- return 0;
+ return ring;
out_ring_desc:
kfree(ring-ring_info);
out_ring_info:
kfree(ring);
out_ring:
- return -ENOMEM;
+ return NULL;
}
-static void pasemi_mac_free_tx_resources(struct net_device *dev)
+static void pasemi_mac_free_tx_resources(struct pasemi_mac *mac)
{
- struct pasemi_mac *mac = netdev_priv(dev);
+ struct pasemi_mac_txring *txring = tx_ring(mac);
unsigned int i, j;
struct pasemi_mac_buffer *info;
dma_addr_t dmas[MAX_SKB_FRAGS+1];
int freed;
int start, limit;
- start = mac-tx-next_to_clean;
- limit = mac-tx-next_to_fill;
+ start = txring-next_to_clean;
+ limit = txring-next_to_fill;
/*
[PATCH] [0/12] pasemi_mac updates for 2.6.25 + DMA channel management library
Hi, The following series contains driver updates for 2.6.25, together with a couple of patches that introduces a library for abstracting DMA channel allocation and access. While the DMA stuff (patches 5 and 6) isn't really netdev material, the driver updates depend on them, and it'd just be easier to merge them up the netdev path. The patches are: 1/12: pasemi_mac: RX/TX ring management cleanup 2/12: pasemi_mac: Remove SKB copy/recycle logic 3/12: pasemi_mac: Print warning when not attaching to a PHY 4/12: pasemi_mac: Don't enable RX/TX without a link (if possible) 5/12: pasemi_mac: Move register definitions to include/asm-powerpc 6/12: pasemi: DMA engine management library 7/12: pasemi_mac: Convert to new dma library 8/12: pasemi_mac: performance tweaks 9/12: pasemi_mac: Fix TX cleaning 10/12: pasemi_mac: Improve RX interrupt mitigation l1/12: pasemi_mac: Software-based LRO support 12/12: pasemi_mac: SKB unmap optimization -Olof ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH] [5/12] pasemi_mac: performance tweaks
pasemi_mac: performance tweaks
* Seems like we do better with a smaller RX ring, probably because chances of
still having the SKB cached are better
* Const-ify variables to get better code generation and fewer reloads
* Move prefetching around a little, and try to prefetch the whole SKB
* Set NETIF_F_HIGHDMA
* Misc other minor tweaks
Signed-off-by: Olof Johansson [EMAIL PROTECTED]
---
drivers/net/pasemi_mac.c | 114 ---
1 file changed, 68 insertions(+), 46 deletions(-)
Index: k.org/drivers/net/pasemi_mac.c
===
--- k.org.orig/drivers/net/pasemi_mac.c
+++ k.org/drivers/net/pasemi_mac.c
@@ -56,7 +56,7 @@
/* Must be a power of two */
-#define RX_RING_SIZE 4096
+#define RX_RING_SIZE 1024
#define TX_RING_SIZE 4096
#define DEFAULT_MSG_ENABLE \
@@ -103,12 +103,12 @@ static void write_iob_reg(unsigned int r
pasemi_write_iob_reg(reg, val);
}
-static unsigned int read_mac_reg(struct pasemi_mac *mac, unsigned int reg)
+static unsigned int read_mac_reg(const struct pasemi_mac *mac, unsigned int
reg)
{
return pasemi_read_mac_reg(mac-dma_if, reg);
}
-static void write_mac_reg(struct pasemi_mac *mac, unsigned int reg,
+static void write_mac_reg(const struct pasemi_mac *mac, unsigned int reg,
unsigned int val)
{
pasemi_write_mac_reg(mac-dma_if, reg, val);
@@ -124,16 +124,26 @@ static void write_dma_reg(unsigned int r
pasemi_write_dma_reg(reg, val);
}
-static struct pasemi_mac_rxring *rx_ring(struct pasemi_mac *mac)
+static struct pasemi_mac_rxring *rx_ring(const struct pasemi_mac *mac)
{
return mac-rx;
}
-static struct pasemi_mac_txring *tx_ring(struct pasemi_mac *mac)
+static struct pasemi_mac_txring *tx_ring(const struct pasemi_mac *mac)
{
return mac-tx;
}
+static inline void prefetch_skb(const struct sk_buff *skb)
+{
+ const void *d = skb;
+
+ prefetch(d);
+ prefetch(d+64);
+ prefetch(d+128);
+ prefetch(d+192);
+}
+
static int mac_to_intf(struct pasemi_mac *mac)
{
struct pci_dev *pdev = mac-pdev;
@@ -211,19 +221,18 @@ static int pasemi_get_mac_addr(struct pa
static int pasemi_mac_unmap_tx_skb(struct pasemi_mac *mac,
struct sk_buff *skb,
- dma_addr_t *dmas)
+ const dma_addr_t *dmas)
{
int f;
int nfrags = skb_shinfo(skb)-nr_frags;
+ struct pci_dev *pdev = mac-dma_pdev;
- pci_unmap_single(mac-dma_pdev, dmas[0], skb_headlen(skb),
-PCI_DMA_TODEVICE);
+ pci_unmap_single(pdev, dmas[0], skb_headlen(skb), PCI_DMA_TODEVICE);
for (f = 0; f nfrags; f++) {
skb_frag_t *frag = skb_shinfo(skb)-frags[f];
- pci_unmap_page(mac-dma_pdev, dmas[f+1], frag-size,
- PCI_DMA_TODEVICE);
+ pci_unmap_page(pdev, dmas[f+1], frag-size, PCI_DMA_TODEVICE);
}
dev_kfree_skb_irq(skb);
@@ -233,7 +242,7 @@ static int pasemi_mac_unmap_tx_skb(struc
return (nfrags + 3) ~1;
}
-static int pasemi_mac_setup_rx_resources(struct net_device *dev)
+static int pasemi_mac_setup_rx_resources(const struct net_device *dev)
{
struct pasemi_mac_rxring *ring;
struct pasemi_mac *mac = netdev_priv(dev);
@@ -277,7 +286,7 @@ static int pasemi_mac_setup_rx_resources
PAS_DMA_RXCHAN_BASEU_BRBH(ring-chan.ring_dma 32) |
PAS_DMA_RXCHAN_BASEU_SIZ(RX_RING_SIZE 3));
- cfg = PAS_DMA_RXCHAN_CFG_HBU(1);
+ cfg = PAS_DMA_RXCHAN_CFG_HBU(2);
if (translation_enabled())
cfg |= PAS_DMA_RXCHAN_CFG_CTR;
@@ -291,7 +300,7 @@ static int pasemi_mac_setup_rx_resources
PAS_DMA_RXINT_BASEU_BRBH(ring-buf_dma 32) |
PAS_DMA_RXINT_BASEU_SIZ(RX_RING_SIZE 3));
- cfg = PAS_DMA_RXINT_CFG_DHL(1) | PAS_DMA_RXINT_CFG_L2 |
+ cfg = PAS_DMA_RXINT_CFG_DHL(2) | PAS_DMA_RXINT_CFG_L2 |
PAS_DMA_RXINT_CFG_LW | PAS_DMA_RXINT_CFG_RBP |
PAS_DMA_RXINT_CFG_HEN;
@@ -316,7 +325,7 @@ out_chan:
}
static struct pasemi_mac_txring *
-pasemi_mac_setup_tx_resources(struct net_device *dev)
+pasemi_mac_setup_tx_resources(const struct net_device *dev)
{
struct pasemi_mac *mac = netdev_priv(dev);
u32 val;
@@ -439,9 +448,10 @@ static void pasemi_mac_free_rx_resources
mac-rx = NULL;
}
-static void pasemi_mac_replenish_rx_ring(struct net_device *dev, int limit)
+static void pasemi_mac_replenish_rx_ring(const struct net_device *dev,
+const int limit)
{
- struct pasemi_mac *mac = netdev_priv(dev);
+ const struct pasemi_mac *mac = netdev_priv(dev);
struct pasemi_mac_rxring *rx = rx_ring(mac);
int fill, count;
@@ -492,7
[PATCH] [8/12] pasemi_mac: Software-based LRO support
pasemi_mac: Software-based LRO support
Implement LRO for pasemi_mac. Pretty straightforward.
Signed-off-by: Olof Johansson [EMAIL PROTECTED]
---
drivers/net/Kconfig |1
drivers/net/pasemi_mac.c | 53 +++
drivers/net/pasemi_mac.h |5
3 files changed, 55 insertions(+), 4 deletions(-)
Index: k.org/drivers/net/pasemi_mac.c
===
--- k.org.orig/drivers/net/pasemi_mac.c
+++ k.org/drivers/net/pasemi_mac.c
@@ -32,6 +32,7 @@
#include linux/ip.h
#include linux/tcp.h
#include net/checksum.h
+#include linux/inet_lro.h
#include asm/irq.h
#include asm/firmware.h
@@ -56,9 +57,11 @@
/* Must be a power of two */
-#define RX_RING_SIZE 1024
+#define RX_RING_SIZE 2048
#define TX_RING_SIZE 4096
+#define LRO_MAX_AGGR 64
+
#define DEFAULT_MSG_ENABLE \
(NETIF_MSG_DRV | \
NETIF_MSG_PROBE| \
@@ -206,7 +209,6 @@ static int pasemi_get_mac_addr(struct pa
return -ENOENT;
}
-
if (sscanf(maddr, %hhx:%hhx:%hhx:%hhx:%hhx:%hhx, addr[0],
addr[1], addr[2], addr[3], addr[4], addr[5]) != 6) {
dev_warn(pdev-dev,
@@ -219,6 +221,37 @@ static int pasemi_get_mac_addr(struct pa
return 0;
}
+static int get_skb_hdr(struct sk_buff *skb, void **iphdr,
+ void **tcph, u64 *hdr_flags, void *data)
+{
+ u64 macrx = (u64) data;
+ unsigned int ip_len;
+ struct iphdr *iph;
+
+ /* IPv4 header checksum failed */
+ if ((macrx XCT_MACRX_HTY_M) != XCT_MACRX_HTY_IPV4_OK)
+ return -1;
+
+ /* non tcp packet */
+ skb_reset_network_header(skb);
+ iph = ip_hdr(skb);
+ if (iph-protocol != IPPROTO_TCP)
+ return -1;
+
+ ip_len = ip_hdrlen(skb);
+ skb_set_transport_header(skb, ip_len);
+ *tcph = tcp_hdr(skb);
+
+ /* check if ip header and tcp header are complete */
+ if (iph-tot_len ip_len + tcp_hdrlen(skb))
+ return -1;
+
+ *hdr_flags = LRO_IPV4 | LRO_TCP;
+ *iphdr = iph;
+
+ return 0;
+}
+
static int pasemi_mac_unmap_tx_skb(struct pasemi_mac *mac,
struct sk_buff *skb,
const dma_addr_t *dmas)
@@ -662,7 +695,7 @@ static int pasemi_mac_clean_rx(struct pa
skb_put(skb, len-4);
skb-protocol = eth_type_trans(skb, mac-netdev);
- netif_receive_skb(skb);
+ lro_receive_skb(mac-lro_mgr, skb, (void *)macrx);
next:
RX_DESC(rx, n) = 0;
@@ -684,6 +717,8 @@ next:
rx_ring(mac)-next_to_clean = n;
+ lro_flush_all(mac-lro_mgr);
+
/* Increase is in number of 16-byte entries, and since each descriptor
* with an 8BRES takes up 3x8 bytes (padded to 4x8), increase with
* count*2.
@@ -988,7 +1023,7 @@ static int pasemi_mac_open(struct net_de
PAS_IOB_DMA_COM_TIMEOUTCFG_TCNT(0x3ff));
write_iob_reg(PAS_IOB_DMA_RXCH_CFG(mac-rx-chan.chno),
- PAS_IOB_DMA_RXCH_CFG_CNTTH(128));
+ PAS_IOB_DMA_RXCH_CFG_CNTTH(256));
write_iob_reg(PAS_IOB_DMA_TXCH_CFG(mac-tx-chan.chno),
PAS_IOB_DMA_TXCH_CFG_CNTTH(32));
@@ -1368,6 +1403,16 @@ pasemi_mac_probe(struct pci_dev *pdev, c
dev-features = NETIF_F_HW_CSUM | NETIF_F_LLTX | NETIF_F_SG |
NETIF_F_HIGHDMA;
+ mac-lro_mgr.max_aggr = LRO_MAX_AGGR;
+ mac-lro_mgr.max_desc = MAX_LRO_DESCRIPTORS;
+ mac-lro_mgr.lro_arr = mac-lro_desc;
+ mac-lro_mgr.get_skb_header = get_skb_hdr;
+ mac-lro_mgr.features = LRO_F_NAPI | LRO_F_EXTRACT_VLAN_ID;
+ mac-lro_mgr.dev = mac-netdev;
+ mac-lro_mgr.ip_summed = CHECKSUM_UNNECESSARY;
+ mac-lro_mgr.ip_summed_aggr = CHECKSUM_UNNECESSARY;
+
+
mac-dma_pdev = pci_get_device(PCI_VENDOR_ID_PASEMI, 0xa007, NULL);
if (!mac-dma_pdev) {
dev_err(mac-pdev-dev, Can't find DMA Controller\n);
Index: k.org/drivers/net/pasemi_mac.h
===
--- k.org.orig/drivers/net/pasemi_mac.h
+++ k.org/drivers/net/pasemi_mac.h
@@ -26,6 +26,8 @@
#include linux/spinlock.h
#include linux/phy.h
+#define MAX_LRO_DESCRIPTORS 8
+
struct pasemi_mac_txring {
struct pasemi_dmachan chan; /* Must be first */
spinlock_t lock;
@@ -64,7 +66,10 @@ struct pasemi_mac {
u8 mac_addr[6];
+ struct net_lro_mgr lro_mgr;
+ struct net_lro_desc lro_desc[MAX_LRO_DESCRIPTORS];
struct timer_list rxtimer;
+ unsigned intlro_max_aggr;
struct pasemi_mac_txring *tx;
struct pasemi_mac_rxring *rx;
Index: k.org/drivers/net/Kconfig
===
---
Re: [PATCH 1/2] powerpc: add hugepagesz boot-time parameter
Nish Aravamudan wrote: On 11/28/07, Randy Dunlap [EMAIL PROTECTED] wrote: On Tue, 27 Nov 2007 23:03:10 -0600 Jon Tollefson wrote: This patch adds the hugepagesz boot-time parameter for ppc64 that lets you pick the size for your huge pages. The choices available are 64K and 16M. It defaults to 16M (previously the only choice) if nothing or an invalid choice is specified. Tested 64K huge pages with the libhugetlbfs 1.2 release with its 'make func' and 'make stress' test invocations. This patch requires the patch posted by Mel Gorman that adds HUGETLB_PAGE_SIZE_VARIABLE; [PATCH] Fix boot problem with iSeries lacking hugepage support on 2007-11-15. Signed-off-by: Jon Tollefson [EMAIL PROTECTED] --- Documentation/kernel-parameters.txt |1 arch/powerpc/mm/hash_utils_64.c | 11 + arch/powerpc/mm/hugetlbpage.c | 41 include/asm-powerpc/mmu-hash64.h|1 mm/hugetlb.c|1 5 files changed, 46 insertions(+), 9 deletions(-) diff --git a/Documentation/kernel-parameters.txt b/Documentation/kernel-parameters.txt index 33121d6..2fc1fb8 100644 --- a/Documentation/kernel-parameters.txt +++ b/Documentation/kernel-parameters.txt @@ -685,6 +685,7 @@ and is between 256 and 4096 characters. It is defined in the file See Documentation/isdn/README.HiSax. hugepages= [HW,X86-32,IA-64] Maximal number of HugeTLB pages. + hugepagesz= [HW,IA-64,PPC] The size of the HugeTLB pages. Any chance of spelling it as hugepagesize so that it's a little less cryptic and more difficult to typo as hugepages? (i.e., less confusion between them) It already exists as hugepagesz= for IA64. Changing it to hugepagesize would either make ppc be different than IA64, or require keeping both so as to make IA64 setups continue working as before? Oh, but it wasn't in Doc/kernel-parameters.txt ? :( OK, just leave it as is, I think. Thanks, -- ~Randy ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH] [12/12] pasemi_mac: Don't enable RX/TX without a link (if possible)
pasemi_mac: Don't enable RX/TX without a link (if possible)
Don't enable RX/TX of packets until we have a link, since there's a chance
we'll just get RX frame errors, etc.
The case where we don't have a PHY we can't do much about: Just enable
it and deal with errors as they come in.
Signed-off-by: Olof Johansson [EMAIL PROTECTED]
---
drivers/net/pasemi_mac.c | 41 +
1 file changed, 33 insertions(+), 8 deletions(-)
Index: k.org/drivers/net/pasemi_mac.c
===
--- k.org.orig/drivers/net/pasemi_mac.c
+++ k.org/drivers/net/pasemi_mac.c
@@ -874,6 +874,24 @@ static irqreturn_t pasemi_mac_tx_intr(in
return IRQ_HANDLED;
}
+static void pasemi_mac_intf_disable(struct pasemi_mac *mac)
+{
+ unsigned int flags;
+
+ flags = read_mac_reg(mac, PAS_MAC_CFG_PCFG);
+ flags = ~PAS_MAC_CFG_PCFG_PE;
+ write_mac_reg(mac, PAS_MAC_CFG_PCFG, flags);
+}
+
+static void pasemi_mac_intf_enable(struct pasemi_mac *mac)
+{
+ unsigned int flags;
+
+ flags = read_mac_reg(mac, PAS_MAC_CFG_PCFG);
+ flags |= PAS_MAC_CFG_PCFG_PE;
+ write_mac_reg(mac, PAS_MAC_CFG_PCFG, flags);
+}
+
static void pasemi_adjust_link(struct net_device *dev)
{
struct pasemi_mac *mac = netdev_priv(dev);
@@ -889,11 +907,14 @@ static void pasemi_adjust_link(struct ne
printk(KERN_INFO %s: Link is down.\n, dev-name);
netif_carrier_off(dev);
+ pasemi_mac_intf_disable(mac);
mac-link = 0;
return;
- } else
+ } else {
+ pasemi_mac_intf_enable(mac);
netif_carrier_on(dev);
+ }
flags = read_mac_reg(mac, PAS_MAC_CFG_PCFG);
new_flags = flags ~(PAS_MAC_CFG_PCFG_HD | PAS_MAC_CFG_PCFG_SPD_M |
@@ -1052,8 +1073,7 @@ static int pasemi_mac_open(struct net_de
pasemi_mac_restart_rx_intr(mac);
pasemi_mac_restart_tx_intr(mac);
- flags = PAS_MAC_CFG_PCFG_S1 | PAS_MAC_CFG_PCFG_PE |
- PAS_MAC_CFG_PCFG_PR | PAS_MAC_CFG_PCFG_CE;
+ flags = PAS_MAC_CFG_PCFG_S1 | PAS_MAC_CFG_PCFG_PR | PAS_MAC_CFG_PCFG_CE;
if (mac-type == MAC_TYPE_GMAC)
flags |= PAS_MAC_CFG_PCFG_TSR_1G | PAS_MAC_CFG_PCFG_SPD_1G;
@@ -1064,11 +1084,16 @@ static int pasemi_mac_open(struct net_de
write_mac_reg(mac, PAS_MAC_CFG_PCFG, flags);
ret = pasemi_mac_phy_init(dev);
- /* Warn for missing PHY on SGMII (1Gig) ports.
-*/
- if (ret mac-type == MAC_TYPE_GMAC) {
- dev_warn(mac-pdev-dev, PHY init failed: %d.\n, ret);
- dev_warn(mac-pdev-dev, Defaulting to 1Gbit full duplex\n);
+ if (ret) {
+ /* Since we won't get link notification, just enable RX */
+ pasemi_mac_intf_enable(mac);
+ if (mac-type == MAC_TYPE_GMAC) {
+ /* Warn for missing PHY on SGMII (1Gig) ports */
+ dev_warn(mac-pdev-dev,
+PHY init failed: %d.\n, ret);
+ dev_warn(mac-pdev-dev,
+Defaulting to 1Gbit full duplex\n);
+ }
}
netif_start_queue(dev);
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] [0/12] pasemi_mac updates for 2.6.25 + DMA channel management library
On Wed, Nov 28, 2007 at 08:54:10PM -0600, Olof Johansson wrote: The patches are: [...] I got the order wrong above, the actual one is: 1/12 pasemi_mac: RX/TX ring management cleanup 2/12 pasemi_mac: Move register definitions to include/asm-powerpc 3/12 pasemi: DMA engine management library 4/12 pasemi_mac: Convert to new dma library 5/12 pasemi_mac: performance tweaks 6/12 pasemi_mac: Fix TX cleaning 7/12 pasemi_mac: Improve RX interrupt mitigation 8/12 pasemi_mac: Software-based LRO support 9/12 pasemi_mac: SKB unmap optimization 10/12 pasemi_mac: Remove SKB copy/recycle logic 11/12 pasemi_mac: Print warning when not attaching to a PHY 12/12 pasemi_mac: Don't enable RX/TX without a link (if possible) ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 1/2] powerpc: add hugepagesz boot-time parameter
On 11/28/07, Randy Dunlap [EMAIL PROTECTED] wrote: Nish Aravamudan wrote: On 11/28/07, Randy Dunlap [EMAIL PROTECTED] wrote: On Tue, 27 Nov 2007 23:03:10 -0600 Jon Tollefson wrote: This patch adds the hugepagesz boot-time parameter for ppc64 that lets you pick the size for your huge pages. The choices available are 64K and 16M. It defaults to 16M (previously the only choice) if nothing or an invalid choice is specified. Tested 64K huge pages with the libhugetlbfs 1.2 release with its 'make func' and 'make stress' test invocations. This patch requires the patch posted by Mel Gorman that adds HUGETLB_PAGE_SIZE_VARIABLE; [PATCH] Fix boot problem with iSeries lacking hugepage support on 2007-11-15. Signed-off-by: Jon Tollefson [EMAIL PROTECTED] --- Documentation/kernel-parameters.txt |1 arch/powerpc/mm/hash_utils_64.c | 11 + arch/powerpc/mm/hugetlbpage.c | 41 include/asm-powerpc/mmu-hash64.h|1 mm/hugetlb.c|1 5 files changed, 46 insertions(+), 9 deletions(-) diff --git a/Documentation/kernel-parameters.txt b/Documentation/kernel-parameters.txt index 33121d6..2fc1fb8 100644 --- a/Documentation/kernel-parameters.txt +++ b/Documentation/kernel-parameters.txt @@ -685,6 +685,7 @@ and is between 256 and 4096 characters. It is defined in the file See Documentation/isdn/README.HiSax. hugepages= [HW,X86-32,IA-64] Maximal number of HugeTLB pages. + hugepagesz= [HW,IA-64,PPC] The size of the HugeTLB pages. Any chance of spelling it as hugepagesize so that it's a little less cryptic and more difficult to typo as hugepages? (i.e., less confusion between them) It already exists as hugepagesz= for IA64. Changing it to hugepagesize would either make ppc be different than IA64, or require keeping both so as to make IA64 setups continue working as before? Oh, but it wasn't in Doc/kernel-parameters.txt ? :( Nope :( I wonder how many other kernel parameters are in the same boat? Where's an RPJDay-script when you need it? OK, just leave it as is, I think. Yeah, I guess that's probably easiest...unfortunately. -Nish ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] PPC: CELLEB - fix potential NULL pointer dereference
Cyrill Gorcunov [EMAIL PROTECTED] wrote:
On 11/28/07, Cyrill Gorcunov [EMAIL PROTECTED] wrote:
On 11/28/07, Michael Ellerman [EMAIL PROTECTED] wrote:
On Mon, 2007-11-26 at 10:46 +0300, Cyrill Gorcunov wrote:
This patch adds checking for NULL value returned to prevent possible
NULL pointer dereference.
Also two unneeded 'return' are removed.
Signed-off-by: Cyrill Gorcunov [EMAIL PROTECTED]
---
Any comments are welcome.
I guess it's good to be paranoid, but this is a little verbose:
wi0 = of_get_property(node, device-id, NULL);
+ if (unlikely((!wi0))) {
+ printk(KERN_ERR PCI: device-id not found.\n);
+ goto error;
+ }
wi1 = of_get_property(node, vendor-id, NULL);
+ if (unlikely((!wi1))) {
+ printk(KERN_ERR PCI: vendor-id not found.\n);
+ goto error;
+ }
wi2 = of_get_property(node, class-code, NULL);
+ if (unlikely((!wi2))) {
+ printk(KERN_ERR PCI: class-code not found.\n);
+ goto error;
+ }
wi3 = of_get_property(node, revision-id, NULL);
+ if (unlikely((!wi3))) {
+ printk(KERN_ERR PCI: revision-id not found.\n);
+ goto error;
+ }
Perhaps instead:
wi0 = of_get_property(node, device-id, NULL);
wi1 = of_get_property(node, vendor-id, NULL);
wi2 = of_get_property(node, class-code, NULL);
wi3 = of_get_property(node, revision-id, NULL);
if (!wi0 || !wi1 || !wi2 || !wi3) {
printk(KERN_ERR PCI: Missing device tree properties.\n);
goto error;
}
Hi Michael, yes that is much better (actually I was doubt about what form of
which the checking style to use - your form is much compact but mine does
show where *exactly* the problem appeared). So 'case that is the fake driver
your form is preferred ;) Ishizaki, could you use Michael's part then?
cheers
--
Michael Ellerman
OzLabs, IBM Australia Development Lab
wwweb: http://michael.ellerman.id.au
phone: +61 2 6212 1183 (tie line 70 21183)
We do not inherit the earth from our ancestors,
we borrow it from our children. - S.M.A.R.T Person
Cyrill
Ishizaki I can update the patch if you needed. Should I?
Cyrill
There is no problem to use Michael's part, and I also prefer simple
one like this.
Cyrill, would you please update your patch?
Best regards,
Kou Ishizaki
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] IB/ehca: Fix static rate if path faster than link
thanks, applied ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Timers on mpc8248 etc...
It comes from uboot. Can you point me in the right direction to make
sure its right?
PowerPC,[EMAIL PROTECTED] {
device_type = cpu;
reg = 0;
d-cache-line-size = d#32;
i-cache-line-size = d#32;
d-cache-size = d#16384;
i-cache-size = d#16384;
timebase-frequency = 0;
clock-frequency = 0;
};
On 11/28/07, Scott Wood [EMAIL PROTECTED] wrote:
Alan Bennett wrote:
I've got a routine that needs to delay for X microseconds, this is a
must. The command after schedule_timeout must has to wait for the HW
to complete a task that takes X microseconds.
I would think that one way to do this is with a simple
schedule_timeout. But in the example below, the time that passes from
run1() to dontrun() is far less than 3.2 msecs. Infact, sometimes its
~ 800 micros according the a analyzer looking at points triggered in
run1() and donrun(). Could this be a configuration problem with the
timer/interrupt that generates the jiffies?
Are you sure the timebase frequency is set correctly in the device tree?
-Scott
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH] Increase the upper bound on NR_CPUS.
Signed-off-by: Tony Breeds [EMAIL PROTECTED] --- why not? arch/powerpc/platforms/Kconfig.cputype |4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/arch/powerpc/platforms/Kconfig.cputype b/arch/powerpc/platforms/Kconfig.cputype index 99684ea..5d70862 100644 --- a/arch/powerpc/platforms/Kconfig.cputype +++ b/arch/powerpc/platforms/Kconfig.cputype @@ -220,8 +220,8 @@ config SMP If you don't know what to do here, say N. config NR_CPUS - int Maximum number of CPUs (2-128) - range 2 128 + int Maximum number of CPUs (2-1024) + range 2 1024 depends on SMP default 32 if PPC64 default 4 Yours Tony linux.conf.auhttp://linux.conf.au/ || http://lca2008.linux.org.au/ Jan 28 - Feb 02 2008 The Australian Linux Technical Conference! ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] Increase the upper bound on NR_CPUS.
On Thu, 2007-11-29 at 15:16 +1100, Tony Breeds wrote: Signed-off-by: Tony Breeds [EMAIL PROTECTED] --- why not? How big is say a pseries_defconfig with NR_CPUS = 1024 ? cheers -- Michael Ellerman OzLabs, IBM Australia Development Lab wwweb: http://michael.ellerman.id.au phone: +61 2 6212 1183 (tie line 70 21183) We do not inherit the earth from our ancestors, we borrow it from our children. - S.M.A.R.T Person signature.asc Description: This is a digitally signed message part ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] Increase the upper bound on NR_CPUS.
On Thu, Nov 29, 2007 at 03:17:16PM +1100, Michael Ellerman wrote:
On Thu, 2007-11-29 at 15:16 +1100, Tony Breeds wrote:
Signed-off-by: Tony Breeds [EMAIL PROTECTED]
---
why not?
How big is say a pseries_defconfig with NR_CPUS = 1024 ?
This is a ppc64_defconfig, with a couple of extra patches, and
NR_CPUS=1024
[EMAIL PROTECTED]:~/scratch/working$ size
../working_out/arch/powerpc/boot/zImage.{pmac,pseries,iseries}
../working_out/vmlinux
textdata bss dec hex filename
36970925356 48232 3750680 393b18
../working_out/arch/powerpc/boot/zImage.pmac
36970925356 48232 3750680 393b18
../working_out/arch/powerpc/boot/zImage.pseries
8101340 4994176 815544 13911060 d44414
../working_out/arch/powerpc/boot/zImage.iseries
8101340 4994176 815544 13911060 d44414 ../working_out/vmlinux
Yours Tony
linux.conf.auhttp://linux.conf.au/ || http://lca2008.linux.org.au/
Jan 28 - Feb 02 2008 The Australian Linux Technical Conference!
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] Increase the upper bound on NR_CPUS.
On Thu, 2007-11-29 at 15:23 +1100, Tony Breeds wrote:
On Thu, Nov 29, 2007 at 03:17:16PM +1100, Michael Ellerman wrote:
On Thu, 2007-11-29 at 15:16 +1100, Tony Breeds wrote:
Signed-off-by: Tony Breeds [EMAIL PROTECTED]
---
why not?
How big is say a pseries_defconfig with NR_CPUS = 1024 ?
This is a ppc64_defconfig, with a couple of extra patches, and
NR_CPUS=1024
[EMAIL PROTECTED]:~/scratch/working$ size
../working_out/arch/powerpc/boot/zImage.{pmac,pseries,iseries}
../working_out/vmlinux
textdata bss dec hex filename
36970925356 48232 3750680 393b18
../working_out/arch/powerpc/boot/zImage.pmac
36970925356 48232 3750680 393b18
../working_out/arch/powerpc/boot/zImage.pseries
8101340 4994176 815544 13911060 d44414
../working_out/arch/powerpc/boot/zImage.iseries
8101340 4994176 815544 13911060 d44414 ../working_out/vmlinux
OK, not too bad for the zImage, but the vmlinux has grown a bit, we
obviously have lots of foo[NR_CPUS].
NR_CPUS = 32 vs 1024
textdata bss dec hex filename
7889287 1786256 529248 10204791 9bb677 vmlinux
7901531 4946864 814432 13662827 d07a6b vmlinux
cheers
--
Michael Ellerman
OzLabs, IBM Australia Development Lab
wwweb: http://michael.ellerman.id.au
phone: +61 2 6212 1183 (tie line 70 21183)
We do not inherit the earth from our ancestors,
we borrow it from our children. - S.M.A.R.T Person
signature.asc
Description: This is a digitally signed message part
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] PPC: CELLEB - fix potential NULL pointer dereference
On 11/29/07, Ishizaki Kou [EMAIL PROTECTED] wrote:
[...snip...]
There is no problem to use Michael's part, and I also prefer simple
one like this.
Cyrill, would you please update your patch?
Best regards,
Kou Ishizaki
Please see updated patch enveloped. (Can't do it inline becase I'm on
my work now where I have no Linux machine)
Cyrill
---
From: Cyrill Gorcunov [EMAIL PROTECTED]
Subject: [PATCH] PPC: CELLEB - fix possible NULL pointer dereference
This patch adds checking for NULL returned value to
prevent possible NULL pointer dereference.
Signed-off-by: Cyrill Gorcunov [EMAIL PROTECTED]
---
arch/powerpc/platforms/celleb/pci.c | 11 ---
1 files changed, 8 insertions(+), 3 deletions(-)
diff --git a/arch/powerpc/platforms/celleb/pci.c
b/arch/powerpc/platforms/celleb/pci.c
index 6bc32fd..13ec4a6 100644
--- a/arch/powerpc/platforms/celleb/pci.c
+++ b/arch/powerpc/platforms/celleb/pci.c
@@ -138,8 +138,6 @@ static void celleb_config_read_fake(unsigned char *config,
int where,
*val = celleb_fake_config_readl(p);
break;
}
-
- return;
}
static void celleb_config_write_fake(unsigned char *config, int where,
@@ -158,7 +156,6 @@ static void celleb_config_write_fake(unsigned char *config,
int where,
celleb_fake_config_writel(val, p);
break;
}
- return;
}
static int celleb_fake_pci_read_config(struct pci_bus *bus,
@@ -351,6 +348,10 @@ static int __init celleb_setup_fake_pci_device(struct
device_node *node,
wi1 = of_get_property(node, vendor-id, NULL);
wi2 = of_get_property(node, class-code, NULL);
wi3 = of_get_property(node, revision-id, NULL);
+ if (!wi0 || !wi1 || !wi2 || !wi3) {
+ printk(KERN_ERR PCI: Missing device tree properties.\n);
+ goto error;
+ }
celleb_config_write_fake(*config, PCI_DEVICE_ID, 2, wi0[0] 0x);
celleb_config_write_fake(*config, PCI_VENDOR_ID, 2, wi1[0] 0x);
@@ -372,6 +373,10 @@ static int __init celleb_setup_fake_pci_device(struct
device_node *node,
celleb_setup_pci_base_addrs(hose, devno, fn, num_base_addr);
li = of_get_property(node, interrupts, rlen);
+ if (!li) {
+ printk(KERN_ERR PCI: interrupts not found.\n);
+ goto error;
+ }
val = li[0];
celleb_config_write_fake(*config, PCI_INTERRUPT_PIN, 1, 1);
celleb_config_write_fake(*config, PCI_INTERRUPT_LINE, 1, val);
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] Increase the upper bound on NR_CPUS.
Hi Tony, :-) On Thu, 29 Nov 2007 15:16:03 +1100 [EMAIL PROTECTED] (Tony Breeds) wrote: Signed-off-by: Tony Breeds [EMAIL PROTECTED] NAK ... you need to change the static initialisation of the paca structures to match ... -- Cheers, Stephen Rothwell[EMAIL PROTECTED] http://www.canb.auug.org.au/~sfr/ pgpxM0ALYmOtB.pgp Description: PGP signature ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH] PPC: CELLEB - fix possible NULL pointer dereference
From: Cyrill Gorcunov [EMAIL PROTECTED]
This patch adds checking for NULL returned value to
prevent possible NULL pointer dereference.
Signed-off-by: Cyrill Gorcunov [EMAIL PROTECTED]
---
Paul,
This is a resend of a patch from Cyrill. I changed it to inline style.
Cyrill,
This works good on Celleb. Thanks.
Best regards,
Kou Ishizaki
arch/powerpc/platforms/celleb/pci.c | 11 ---
1 files changed, 8 insertions(+), 3 deletions(-)
diff --git a/arch/powerpc/platforms/celleb/pci.c
b/arch/powerpc/platforms/celleb/pci.c
index 6bc32fd..13ec4a6 100644
--- a/arch/powerpc/platforms/celleb/pci.c
+++ b/arch/powerpc/platforms/celleb/pci.c
@@ -138,8 +138,6 @@ static void celleb_config_read_fake(unsigned char *config,
int where,
*val = celleb_fake_config_readl(p);
break;
}
-
- return;
}
static void celleb_config_write_fake(unsigned char *config, int where,
@@ -158,7 +156,6 @@ static void celleb_config_write_fake(unsigned char *config,
int where,
celleb_fake_config_writel(val, p);
break;
}
- return;
}
static int celleb_fake_pci_read_config(struct pci_bus *bus,
@@ -351,6 +348,10 @@ static int __init celleb_setup_fake_pci_device(struct
device_node *node,
wi1 = of_get_property(node, vendor-id, NULL);
wi2 = of_get_property(node, class-code, NULL);
wi3 = of_get_property(node, revision-id, NULL);
+ if (!wi0 || !wi1 || !wi2 || !wi3) {
+ printk(KERN_ERR PCI: Missing device tree properties.\n);
+ goto error;
+ }
celleb_config_write_fake(*config, PCI_DEVICE_ID, 2, wi0[0] 0x);
celleb_config_write_fake(*config, PCI_VENDOR_ID, 2, wi1[0] 0x);
@@ -372,6 +373,10 @@ static int __init celleb_setup_fake_pci_device(struct
device_node *node,
celleb_setup_pci_base_addrs(hose, devno, fn, num_base_addr);
li = of_get_property(node, interrupts, rlen);
+ if (!li) {
+ printk(KERN_ERR PCI: interrupts not found.\n);
+ goto error;
+ }
val = li[0];
celleb_config_write_fake(*config, PCI_INTERRUPT_PIN, 1, 1);
celleb_config_write_fake(*config, PCI_INTERRUPT_LINE, 1, val);
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
