Re: [PATCH] mpc5xxx_get_bus_frequency(): use common code on MPC512x and MPC52xx
On Wed, Jun 17, 2009 at 12:14 AM, Grant Likelygrant.lik...@secretlab.ca wrote: On Thu, Jun 11, 2009 at 2:19 PM, Wolfgang Denkw...@denx.de wrote: So far, MPC512x used mpc512x_find_ips_freq() to get the bus frequency, while MPC52xx used mpc52xx_find_ipb_freq(). Despite the different clock names (IPS vs. IPB) the code was identical. Use common code for both processor families. Signed-off-by: Wolfgang Denk w...@denx.de Cc: Grant Likely grant.lik...@secretlab.ca Cc: Kumar Gala ga...@kernel.crashing.org You probably already know this, but this patch doesn't apply against mainline, so I won't merge for 2.6.31. Never mind; I'm smoking something. The patch applies fine. g. -- Grant Likely, B.Sc., P.Eng. Secret Lab Technologies Ltd. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [ewg] Re: [PATCH 2.6.31] ehca: Tolerate dynamic memory operations and huge pages
On Tue, 16 Jun 2009 09:10:39 -0700 Roland Dreier rdre...@cisco.com wrote: Yeah, the notifier code remains untouched as we still do not allow dynamic memory operations _while_ our module is loaded. The patch allows the driver to cope with DMEM operations that happened before the module was loaded, which might result in a non-contiguous memory layout. When the driver registers its global memory region in the system, the memory layout must be considered. We chose the term toleration instead of support to illustrate this. I see. So things just silently broke in some cases when the driver was loaded after operations you didn't tolerate? Anyway, thanks for the explanation. Well, things did not break silently. The registration of the MR failed with an error code which was reported to userspace. Will you push the patch for .31 or .32? Thanks, Alex ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: PowerPC PCI DMA issues (prefetch/coherency?)
You could enable CONFIG_NOT_COHERENT_CACHE. I've just tried this (I had to edit Kconfig in power/platforms to make the build system accept it), and interestingly it's making no difference. I'm using streaming mappings, and are using the pci_map_sg functions to ensure the memory is mapped/flushed correctly. I've also explicitly put in a pci_dma_sync_sg_for_device, however that's also not made any difference. Turning the cpu cache snoop off has the same affect as it did without CONFIG_NOT_COHERENT_CACHE; it gets much worse. Any other ideas? Will back off the low latency patches next, and give 2.6.30 a try - see if that makes any difference. -- __ Chris Pringle Software Engineer Miranda Technologies Ltd. Hithercroft Road Wallingford Oxfordshire OX10 9DG UK Tel. +44 1491 820206 Fax. +44 1491 820001 www.miranda.com Miranda Technologies Limited Registered in England and Wales CN 02017053 Registered Office: James House, Mere Park, Dedmere Road, Marlow, Bucks, SL7 1FJ ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: MPC83xx watchdog reset board dead lock
Hi Leon, I doubt if there are working designs for this. In u-boot the watchdog (if enabled with CONFIG_WATCHDOG) is normally strobed in the decrementer interrupt routine (timer_interrupt). So I guess there's not a big chance it triggers a reset. It is possible to configure the WD to issue a machine check interrupt (i.s.o. HRESET). Maybe it's possible (or even done already) to put the flash into READ-mode from the isr ? --- N. van Bolhuis. Leon Woestenberg wrote: Hello, this is a hardware, even board issue, but I hope to find the right target audience here. In our MPC83xx design I would like to prevent dead lock in case where a field upgrade is performed, i.e. NOR Flash is erased or written, and the MPC83xx built-in hardware watchdog triggers. In u-boot the scenario can be easily reproduced by running this command (WARNING, erases some sectors!) on an MPC8313E-RDB: erase_wdg=mw.l 0xe204 0x1007 1;mw.w 0xe20e 0x556c 1;mw.w 0xe20e 0xaa39 1;erase 1:10-30 This sets up the watchdog to reset soonish, then starts erasing NOR sectors. Watchdog triggers and resets - Dead lock. Most MPC8xxx board designs I have seen suffer from this possible dead lock: - NOR Flash is put in erase mode or write mode - Hardware watchdog triggers - HRESET# is asserted by the processor, during which the configuration words are read from NOR Flash. Either HRESET# is not attached to NOR, NOR stays in erase/write mode and invalid words will be read - dead lock or either: HRESET# is attached to NOR reset, NOR is reset, but stays in reset as HRESET# stays asserted. We have been looking at several solutions hardware wise that reset the NOR flash on HRESET# going low, but the processors are stubborn, read the config words only once, than dead lock. I wonder if there are known-working designs for this. Regards, ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH] powerpc: Add irqtrace support for 32-bit powerpc
Based on initial work from: Dale Farnsworth d...@farnsworth.org Add the low level irq tracing hooks for 32-bit powerpc needed to enable full lockdep functionality. The approach taken to deal with the code in entry_32.S is that we don't trace all the transitions of MSR:EE when we just turn it off to peek at TI_FLAGS without races. Only when we are calling into C code or returning from exceptions with a state that have changed from what lockdep thinks. There's a little bugger though: If we take an exception that keeps interrupts enabled (such as an alignment exception) while interrupts are enabled, we will call trace_hardirqs_on() on the way back spurriously. Not a big deal, but to get rid of it would require remembering in pt_regs that the exception was one of the type that kept interrupts enabled which we don't know at this stage. (Well, we could test all cases for regs-trap but that sucks too much). Signed-off-by: Benjamin Herrenschmidt b...@kernel.crashing.org --- Not very well tested ... got issues with my u-boot on the 440 board and I didn't have much time to test elsewhere. FSL welcome to test on funky configs. It's likely to still be subtely broken :-) arch/powerpc/Kconfig |1 arch/powerpc/include/asm/hw_irq.h | 20 +++--- arch/powerpc/kernel/entry_32.S| 126 -- arch/powerpc/kernel/setup_32.c|2 arch/powerpc/kernel/udbg.c|1 5 files changed, 135 insertions(+), 15 deletions(-) --- linux-work.orig/arch/powerpc/Kconfig2009-06-17 16:45:15.0 +1000 +++ linux-work/arch/powerpc/Kconfig 2009-06-17 16:45:36.0 +1000 @@ -62,7 +62,6 @@ config HAVE_LATENCYTOP_SUPPORT config TRACE_IRQFLAGS_SUPPORT bool - depends on PPC64 default y config LOCKDEP_SUPPORT Index: linux-work/arch/powerpc/kernel/entry_32.S === --- linux-work.orig/arch/powerpc/kernel/entry_32.S 2009-06-17 16:45:15.0 +1000 +++ linux-work/arch/powerpc/kernel/entry_32.S 2009-06-17 18:29:23.0 +1000 @@ -191,11 +191,49 @@ transfer_to_handler_cont: mflrr9 lwz r11,0(r9) /* virtual address of handler */ lwz r9,4(r9)/* where to go when done */ +#ifdef CONFIG_TRACE_IRQFLAGS + lis r12,reenable_...@h + ori r12,r12,reenable_...@l + mtspr SPRN_SRR0,r12 + mtspr SPRN_SRR1,r10 + SYNC + RFI +reenable_mmu: /* re-enable mmu so we can */ + mfmsr r10 + lwz r12,_MSR(r1) + xor r10,r10,r12 + andi. r10,r10,MSR_EE /* Did EE change? */ + beq 1f + + /* Save handler and return address into the 2 unused words +* of the STACK_FRAME_OVERHEAD (sneak sneak sneak). Everything +* else can be recovered from the pt_regs except r3 which for +* normal interrupts has been set to pt_regs and for syscalls +* is an argument, so we temporarily use ORIG_GPR3 to save it +*/ + stw r9,8(r1) + stw r11,12(r1) + stw r3,ORIG_GPR3(r1) + bl trace_hardirqs_off + lwz r0,GPR0(r1) + lwz r3,ORIG_GPR3(r1) + lwz r4,GPR4(r1) + lwz r5,GPR5(r1) + lwz r6,GPR6(r1) + lwz r7,GPR7(r1) + lwz r8,GPR8(r1) + lwz r9,8(r1) + lwz r11,12(r1) +1: mtctr r11 + mtlrr9 + bctr/* jump to handler */ +#else /* CONFIG_TRACE_IRQFLAGS */ mtspr SPRN_SRR0,r11 mtspr SPRN_SRR1,r10 mtlrr9 SYNC RFI /* jump to handler, enable MMU */ +#endif /* CONFIG_TRACE_IRQFLAGS */ #if defined (CONFIG_6xx) || defined(CONFIG_E500) 4: rlwinm r12,r12,0,~_TLF_NAPPING @@ -251,6 +289,31 @@ _GLOBAL(DoSyscall) #ifdef SHOW_SYSCALLS bl do_show_syscall #endif /* SHOW_SYSCALLS */ +#ifdef CONFIG_TRACE_IRQFLAGS + /* Return from syscalls can (and generally will) hard enable +* interrupts. You aren't supposed to call a syscall with +* interrupts disabled in the first place. However, to ensure +* that we get it right vs. lockdep if it happens, we force +* that hard enable here with appropriate tracing if we see +* that we have been called with interrupts off +*/ + mfmsr r11 + andi. r12,r11,MSR_EE + bne+1f + /* We came in with interrupts disabled, we enable them now */ + bl trace_hardirqs_on + mfmsr r11 + lwz r0,GPR0(r1) + lwz r3,GPR3(r1) + lwz r4,GPR4(r1) + ori r11,r11,MSR_EE + lwz r5,GPR5(r1) + lwz r6,GPR6(r1) + lwz r7,GPR7(r1) + lwz r8,GPR8(r1) + mtmsr r11 +1: +#endif /* CONFIG_TRACE_IRQFLAGS */ rlwinm r10,r1,0,0,(31-THREAD_SHIFT)/*
Re: [PATCH] powerpc/mm: Fix potential access to freed pages when using hugetlbfs
Benjamin Herrenschmidt wrote: When using 64k page sizes, our PTE pages are split in two halves, the second half containing the extension used to keep track of individual 4k pages when not using HW 64k pages. However, our page tables used for hugetlb have a slightly different format and don't carry that second half. Our code that batched PTEs to be invalidated unconditionally reads the second half (to put it into the batch), which means that when called to invalidate hugetlb PTEs, it will access unrelated memory. It breaks when CONFIG_DEBUG_PAGEALLOC is enabled. This fixes it by only accessing the second half when the _PAGE_COMBO bit is set in the first half, which indicates that we are dealing with a combo page which represents 16x4k subpages. Anything else shouldn't have this bit set and thus not require loading from the second half. Signed-off-by: Benjamin Herrenschmidt b...@kernel.crashing.org Thanks for the patch. The machine survived after two days of testing with hugetlbfs tests. Regards -Sachin -- - Sachin Sant IBM Linux Technology Center India Systems and Technology Labs Bangalore, India - ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: MPC83xx watchdog reset board dead lock
Hello all, On Wed, Jun 17, 2009 at 10:35 AM, Norbert van Bolhuisnvbolh...@aimvalley.nl wrote: Hi Leon, I doubt if there are working designs for this. ... In u-boot the watchdog (if enabled with CONFIG_WATCHDOG) is normally strobed in the decrementer interrupt routine (timer_interrupt). So I guess there's not a big chance it triggers a reset. ... Most designs do not care about the watchdog, or only pet in their non-critical paths... That's not what the watchdog is for. Also, I don't care about u-boot. I care about a design where the Flash NOR could be in write mode at any time when the watchdog triggers, when the hardware is running critical software. No lifes in danger when it happens, only jobs, so no biggy :-) David has been helpful in thinking this through, but we followed-up offline, and we independently came up with the following design, so this must therefore work (disclaimer applies). Note, it DOES require a NOR flash that has a RY/BUSY# pin. Quoting David Hawkins, who gave a very clear explanation: --- How about using the RDY/BUSY# pin on the Flash in conjunction with PORESET#. If the flash is busy, then the processor gets PORESET#, otherwise, the HRESET# just does its normal thing. That way PORESET# only ever asserts when you have the combo of the Flash being busy and HRESET# asserting. ... If you have the Flash BUSY# signal, then this scheme works great, since using HRESET# low and BUSY# low to create a PORESET# source is only active until the Flash RESET# is asserted long enough for it to get out of the BUSY# state and back into read-array mode. --- Kudos to David. I'll be testing the design tomorrow on the reference board, I'll report results in this thread. Regards / Groeten, -- Leon ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: sym scsi driver problem with 2.6.26 or newer debian kernel on p610 (fwd)
Hello! I'm sorry about the annoyances, but I'd welcome all ideas, suggestions to see what needs to be done or should be tested for the solution. Thank you very much! Guennadi Liakhovetski wrote: Ok, first attempt to forward this to scsi was wrong, as pointed out by Matthew Wilcox this does indeed look like an interrupt problem - no interrupts drom SCSI, IDE, keyboar. Might be a known problem, I guess. In any case, I think, the OP would be grateful for any hints. Thanks Guennadi --- Guennadi Liakhovetski, Ph.D. Freelance Open-Source Software Developer http://www.open-technology.de/ -- Forwarded message -- Date: Sat, 13 Jun 2009 16:22:07 +0200 From: Laszlo Fekete blackl...@ktk.bme.hu To: debian-powe...@lists.debian.org Subject: sym scsi driver problem with 2.6.26 or newer debian kernel on p610 Resent-Date: Sat, 13 Jun 2009 14:29:55 + (UTC) Resent-From: debian-powe...@lists.debian.org This is a multi-part message in MIME format. Hello! Pls help me with sym scsi driver problem. I have Ibm P610 (and tested it on P630 and P640 too), installed debian etch and upgraded to lenny. But with 2.6.26 or newer kernel it's not booting, it's hang on sym scsi bus scan. Whats the problem with it, or how can I fix this? I attach the output from minicom with 2.6.29, 2.6.26, and the working 2.6.24 kernel booting. Thank you very much! ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
8xx: 2.4.25, fec.c, consistent_alloc and eth_copy_and_sum
Looking into arch/ppc/8xx_io/fec.c in the linuxppc_2_4_devel git tree I wonder if it is necessary to copy every received frame from memory allocated by consistent_alloc into a socket buffer? Couldn't we let the FEC DMA directly into the socket buffer to improve the performance? BTW, has someone tried to implement NAPI in this driver? Regards, Joerg -- GMX FreeDSL Komplettanschluss mit DSL 6.000 Flatrate und Telefonanschluss für nur 17,95 Euro/mtl.!* http://portal.gmx.net/de/go/dsl02 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] powerpc/mm: Fix potential access to freed pages when using hugetlbfs
Thanks for the patch. The machine survived after two days of testing with hugetlbfs tests. Excellent, thanks for testing, I'll merge it with my next batch. Cheers, Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[BUG] lib/kernel_lock.c:126 with cgroups regression ltp tests
While executing cgroups regression tests from LTP May 2009
release on a Power6 box came across the following bug.
This is with 2.6.30-git10 (300df7dc89cc276377fc020704e34875d5c473b6)
[ cut here ]
kernel BUG at lib/kernel_lock.c:126!
Oops: Exception in kernel mode, sig: 5 [#1]
SMP NR_CPUS=1024 NUMA pSeries
Modules linked in: ipv6 fuse loop dm_mod sr_mod ehea cdrom sg ibmveth sd_mod
crc_t10dif ibmvscsic scsi_transport_srp scsi_tgt scsi_mod
NIP: c05c6dac LR: c01965ac CTR: 0006
REGS: c0002a5d3910 TRAP: 0700 Not tainted (2.6.30-git10)
MSR: 80029032 EE,ME,CE,IR,DR CR: 82042442 XER:
TASK = c000407cbc20[9581] 'mount' THREAD: c0002a5d CPU: 3
6GPR00: 0001 c0002a5d3b90 c0ef31f0 fff0
6GPR04: c00f0098 c0799813 0001
6GPR08: c0e36aa0 c000407cbc20 0002 c000407cbc20
6GPR12: 24042424 c0ff2a00 0fffed50f6fd 0fffed506e08
6GPR16: 0fffed506db8 1002b638
6GPR20: 100329a0 0fffed506e0c c0003e14b870
6GPR24: c0002a03
6GPR28: c0003e14b800 fff0 c0e7aa40 c0002a5d3b90
NIP [c05c6dac] .unlock_kernel+0x20/0x78
LR [c01965ac] .do_remount_sb+0x190/0x204
Call Trace:
[c0002a5d3bd0] [c019659c] .do_remount_sb+0x180/0x204
[c0002a5d3c70] [c01b8210] .do_mount+0x38c/0x9fc
[c0002a5d3d60] [c01b8940] .SyS_mount+0xc0/0x12c
[c0002a5d3e30] [c0008534] syscall_exit+0x0/0x40
Instruction dump:
383f0040 ebc1fff0 ebe1fff8 4e800020 fbc1fff0 fbe1fff8 f821ffc1 7c3f0b78
ebc2c0b8 e92d01b0 e809001e 78000fe0 0b00 e96d01b0 812b001c 3929
---[ end trace 3bf0012ad33d52b2 ]---
Corresponding c code is :
void __lockfunc unlock_kernel(void)
{
BUG_ON(current-lock_depth 0); ==
if (likely(--current-lock_depth 0))
__unlock_kernel();
Have attached the cgroups regression test run log.
Thanks
-Sachin
--
-
Sachin Sant
IBM Linux Technology Center
India Systems and Technology Labs
Bangalore, India
-
cgroup_regression_test1 PASS : no kernel bug was found
/ltp-full-20090531/testcases/bin/cgroup_regression_test.sh: line 102: 7036 Terminated ./fork_processes
cgroup_regression_test2 PASS : notify_on_release is inherited
cgroup_regression_test3 PASS : no kernel bug was found
cgroup_regression_test4 CONF : CONFIG_LOCKDEP is not enabled
cgroup_regression_test5 PASS : no kernel bug was found
/ltp-full-20090531/testcases/bin/cgroup_regression_test.sh: line 253: 8781 Terminated sleep 100
/ltp-full-20090531/testcases/bin/cgroup_regression_test.sh: line 325: 8800 Terminated ./test_6_2
cgroup_regression_test6 PASS : no kernel bug was found
[ cut here ]
Oops: Exception in kernel mode, sig: 5 [#1]
SMP NR_CPUS=1024 NUMA pSeries
Modules linked in: ipv6 fuse loop dm_mod sr_mod ehea cdrom sg ibmveth sd_mod crc_t10dif ibmvscsic scsi_transport_srp scsi_tgt scsi_mod
NIP: c05c6dac LR: c01965ac CTR: 0006
REGS: c0002a5d3910 TRAP: 0700 Not tainted (2.6.30-git10)
MSR: 80029032 EE,ME,CE,IR,DR CR: 82042442 XER:
TASK = c000407cbc20[9581] 'mount' THREAD: c0002a5d CPU: 3
6GPR00: 0001 c0002a5d3b90 c0ef31f0 fff0
6GPR04: c00f0098 c0799813 0001
6GPR08: c0e36aa0 c000407cbc20 0002 c000407cbc20
6GPR12: 24042424 c0ff2a00 0fffed50f6fd 0fffed506e08
6GPR16: 0fffed506db8 1002b638
6GPR20: 100329a0 0fffed506e0c c0003e14b870
6GPR24: c0002a03
6GPR28: c0003e14b800 fff0 c0e7aa40 c0002a5d3b90
NIP [c05c6dac] .unlock_kernel+0x20/0x78
LR [c01965ac] .do_remount_sb+0x190/0x204
Call Trace:
[c0002a5d3bd0] [c019659c] .do_remount_sb+0x180/0x204
[c0002a5d3c70] [c01b8210] .do_mount+0x38c/0x9fc
[c0002a5d3d60] [c01b8940] .SyS_mount+0xc0/0x12c
[c0002a5d3e30] [c0008534] syscall_exit+0x0/0x40
Instruction dump:
383f0040 ebc1fff0 ebe1fff8 4e800020 fbc1fff0 fbe1fff8 f821ffc1 7c3f0b78
ebc2c0b8 e92d01b0 e809001e 78000fe0 0b00 e96d01b0 812b001c 3929
---[ end trace 3bf0012ad33d52b2 ]---
/ltp-full-20090531/testcases/bin/cgroup_regression_test.sh: line 347: 9581 Trace/breakpoint trap mount -t cgroup -o remount xxx cgroup/ 2 /dev/null
/ltp-full-20090531/testcases/bin/cgroup_regression_test.sh: line 363: 9579 Terminated sleep 100
Re: MPC83xx watchdog reset board dead lock
Hello, On Wed, Jun 17, 2009 at 12:09 PM, Leon Woestenbergleon.woestenb...@gmail.com wrote: Quoting David Hawkins, who gave a very clear explanation: ... If you have the Flash BUSY# signal, then this scheme works great, since using HRESET# low and BUSY# low to create a PORESET# source is only active until the Flash RESET# is asserted long enough for it to get out of the BUSY# state and back into read-array mode. I just found out from a Spansion datasheet that the RY/BUSY# of a typical Flash NOR is enabled by CE#, and tri-state otherwise. CE# in turn is driven by the LCS# from the PowerPC. So basically, the first configuration access cycle while the NOR is in write mode, will pull CE# low, which results in RY/BUSY# being driven. I have measured this pulse is ~1.9 us. So the reset circuitry needs a maximum minimum pulse duration of 1.9 us. Our reset controller (DS1818) fulfills this requirement, with a T,PB of 1 us. A reset controller will extend the reset pulse. This is needed because: for Flash NOR: I have seen a mininum of 35 us reset pulse. (for the PowerPC: PORESET# should be asserted externally for at least 32 input clock cycles) Regards, -- Leon ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [BUG] lib/kernel_lock.c:126 with cgroups regression ltp tests
On Wed, 2009-06-17 at 16:21 +0530, Sachin Sant wrote:
While executing cgroups regression tests from LTP May 2009
release on a Power6 box came across the following bug.
This is with 2.6.30-git10 (300df7dc89cc276377fc020704e34875d5c473b6)
Looks like 337eb00a2 missed some return paths in do_remount_sb()?
$ git log -p -U13 337eb00a2c3a421999c39c94ce7e33545ee8baa7 fs/super.c
commit 337eb00a2c3a421999c39c94ce7e33545ee8baa7
Author: Alessio Igor Bogani abog...@texware.it
Date: Tue May 12 15:10:54 2009 +0200
Push BKL down into -remount_fs()
[xfs, btrfs, capifs, shmem don't need BKL, exempt]
Signed-off-by: Alessio Igor Bogani abog...@texware.it
Signed-off-by: Al Viro v...@zeniv.linux.org.uk
diff --git a/fs/super.c b/fs/super.c
index 1905f4a..83b4741 100644
--- a/fs/super.c
+++ b/fs/super.c
@@ -530,53 +530,51 @@ int do_remount_sb(struct super_block *sb, int flags, void
{
int retval;
int remount_rw;
#ifdef CONFIG_BLOCK
if (!(flags MS_RDONLY) bdev_read_only(sb-s_bdev))
return -EACCES;
#endif
if (flags MS_RDONLY)
acct_auto_close(sb);
shrink_dcache_sb(sb);
sync_filesystem(sb);
- lock_kernel();
/* If we are remounting RDONLY and current sb is read/write,
make sure there are no rw files opened */
if ((flags MS_RDONLY) !(sb-s_flags MS_RDONLY)) {
if (force)
mark_files_ro(sb);
else if (!fs_may_remount_ro(sb)) {
unlock_kernel();
return -EBUSY;
}
retval = vfs_dq_off(sb, 1);
if (retval 0 retval != -ENOSYS) {
unlock_kernel();
return -EBUSY;
}
}
remount_rw = !(flags MS_RDONLY) (sb-s_flags MS_RDONLY);
if (sb-s_op-remount_fs) {
retval = sb-s_op-remount_fs(sb, flags, data);
if (retval) {
unlock_kernel();
return retval;
}
}
sb-s_flags = (sb-s_flags ~MS_RMT_MASK) | (flags MS_RMT_MASK);
- unlock_kernel();
cheers
[ cut here ]
kernel BUG at lib/kernel_lock.c:126!
Oops: Exception in kernel mode, sig: 5 [#1]
SMP NR_CPUS=1024 NUMA pSeries
Modules linked in: ipv6 fuse loop dm_mod sr_mod ehea cdrom sg ibmveth sd_mod
crc_t10dif ibmvscsic scsi_transport_srp scsi_tgt scsi_mod
NIP: c05c6dac LR: c01965ac CTR: 0006
REGS: c0002a5d3910 TRAP: 0700 Not tainted (2.6.30-git10)
MSR: 80029032 EE,ME,CE,IR,DR CR: 82042442 XER:
TASK = c000407cbc20[9581] 'mount' THREAD: c0002a5d CPU: 3
6GPR00: 0001 c0002a5d3b90 c0ef31f0 fff0
6GPR04: c00f0098 c0799813 0001
6GPR08: c0e36aa0 c000407cbc20 0002 c000407cbc20
6GPR12: 24042424 c0ff2a00 0fffed50f6fd 0fffed506e08
6GPR16: 0fffed506db8 1002b638
6GPR20: 100329a0 0fffed506e0c c0003e14b870
6GPR24: c0002a03
6GPR28: c0003e14b800 fff0 c0e7aa40 c0002a5d3b90
NIP [c05c6dac] .unlock_kernel+0x20/0x78
LR [c01965ac] .do_remount_sb+0x190/0x204
Call Trace:
[c0002a5d3bd0] [c019659c] .do_remount_sb+0x180/0x204
[c0002a5d3c70] [c01b8210] .do_mount+0x38c/0x9fc
[c0002a5d3d60] [c01b8940] .SyS_mount+0xc0/0x12c
[c0002a5d3e30] [c0008534] syscall_exit+0x0/0x40
Instruction dump:
383f0040 ebc1fff0 ebe1fff8 4e800020 fbc1fff0 fbe1fff8 f821ffc1 7c3f0b78
ebc2c0b8 e92d01b0 e809001e 78000fe0 0b00 e96d01b0 812b001c 3929
---[ end trace 3bf0012ad33d52b2 ]---
Corresponding c code is :
void __lockfunc unlock_kernel(void)
{
BUG_ON(current-lock_depth 0); ==
if (likely(--current-lock_depth 0))
__unlock_kernel();
Have attached the cgroups regression test run log.
Thanks
-Sachin
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
signature.asc
Description: This is a digitally signed message part
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH] Do not inline putprops function
Do not inline putprops function
With the recent kexec-tools git tree, both kexec and kdump kernels hang (i.e
kexec -l and kexec -p respectively). This happened after the patch ppc64:
cleanups commit b43a84a31a4be6ed025c1bdef3bb1c3c12e01b16. I tried
reverting each hunk and then found out that retaining following lines in
fs2dt.c makes kexec/kdump work.
-static unsigned *dt_len; /* changed len of modified cmdline
- in flat device-tree */
[]
- dt_len = dt;
I don't have any clue why removing a unused variable would cause the kexec
kernel to hang. After further investigation, I observed that if the putprops
function is not inlined, kexec/kdump kernel would work even after removing
the above lines.
This patch directs gcc to not inline the putprops function. Now we could
invoke kexec and kdump kernels.
---
kexec/arch/ppc64/fs2dt.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/kexec/arch/ppc64/fs2dt.c b/kexec/arch/ppc64/fs2dt.c
index 1f551fd..1e01f74 100644
--- a/kexec/arch/ppc64/fs2dt.c
+++ b/kexec/arch/ppc64/fs2dt.c
@@ -259,7 +259,7 @@ static void add_usable_mem_property(int fd, int len)
}
/* put all properties (files) in the property structure */
-static void putprops(char *fn, struct dirent **nlist, int numlist)
+__attribute__ ((noinline)) static void putprops(char *fn, struct dirent
**nlist, int numlist)
{
struct dirent *dp;
int i = 0, fd, len;
--
1.6.0.6
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH 1/6] perf_counter: powerpc: Enable use of software counters on 32-bit powerpc
This enables the perf_counter subsystem on 32-bit powerpc. Since we
don't have any support for hardware counters on 32-bit powerpc yet,
only software counters can be used.
Besides selecting HAVE_PERF_COUNTERS for 32-bit powerpc as well as
64-bit, the main thing this does is add an implementation of
set_perf_counter_pending(). This needs to arrange for
perf_counter_do_pending() to be called when interrupts are enabled.
Rather than add code to local_irq_restore as 64-bit does, the 32-bit
set_perf_counter_pending() generates an interrupt by setting the
decrementer to 1 so that a decrementer interrupt will become pending
in 1 or 2 timebase ticks (if a decrementer interrupt isn't already
pending). When interrupts are enabled, timer_interrupt() will be
called, and some new code in there calls perf_counter_do_pending().
We use a per-cpu array of flags to indicate whether we need to call
perf_counter_do_pending() or not.
This introduces a couple of new Kconfig symbols: PPC_HAVE_PMU_SUPPORT,
which is selected by processor families for which we have hardware PMU
support (currently only PPC64), and PPC_PERF_CTRS, which enables the
powerpc-specific perf_counter back-end.
Signed-off-by: Paul Mackerras pau...@samba.org
---
This depends on the generic atomic64_t patches, which are now in
Linus' tree. Ingo, if you're putting these in, please pull Linus'
tree in first.
arch/powerpc/Kconfig|1 +
arch/powerpc/include/asm/hw_irq.h |5 -
arch/powerpc/include/asm/perf_counter.h | 10 --
arch/powerpc/kernel/Makefile|6 +++---
arch/powerpc/kernel/time.c | 25 +
arch/powerpc/platforms/Kconfig.cputype | 11 ++-
6 files changed, 51 insertions(+), 7 deletions(-)
diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
index 9fb344d..bf6cedf 100644
--- a/arch/powerpc/Kconfig
+++ b/arch/powerpc/Kconfig
@@ -126,6 +126,7 @@ config PPC
select HAVE_OPROFILE
select HAVE_SYSCALL_WRAPPERS if PPC64
select GENERIC_ATOMIC64 if PPC32
+ select HAVE_PERF_COUNTERS
config EARLY_PRINTK
bool
diff --git a/arch/powerpc/include/asm/hw_irq.h
b/arch/powerpc/include/asm/hw_irq.h
index 10a642d..867ab8e 100644
--- a/arch/powerpc/include/asm/hw_irq.h
+++ b/arch/powerpc/include/asm/hw_irq.h
@@ -131,6 +131,8 @@ static inline int irqs_disabled_flags(unsigned long flags)
struct irq_chip;
#ifdef CONFIG_PERF_COUNTERS
+
+#ifdef CONFIG_PPC64
static inline unsigned long test_perf_counter_pending(void)
{
unsigned long x;
@@ -154,8 +156,9 @@ static inline void clear_perf_counter_pending(void)
r (0),
i (offsetof(struct paca_struct, perf_counter_pending)));
}
+#endif /* CONFIG_PPC64 */
-#else
+#else /* CONFIG_PERF_COUNTERS */
static inline unsigned long test_perf_counter_pending(void)
{
diff --git a/arch/powerpc/include/asm/perf_counter.h
b/arch/powerpc/include/asm/perf_counter.h
index b398a84..2c2d9f6 100644
--- a/arch/powerpc/include/asm/perf_counter.h
+++ b/arch/powerpc/include/asm/perf_counter.h
@@ -57,11 +57,17 @@ extern struct power_pmu *ppmu;
struct pt_regs;
extern unsigned long perf_misc_flags(struct pt_regs *regs);
-#define perf_misc_flags(regs) perf_misc_flags(regs)
-
extern unsigned long perf_instruction_pointer(struct pt_regs *regs);
/*
+ * Only override the default definitions in include/linux/perf_counter.h
+ * if we have hardware PMU support.
+ */
+#ifdef CONFIG_PPC_PERF_CTRS
+#define perf_misc_flags(regs) perf_misc_flags(regs)
+#endif
+
+/*
* The power_pmu.get_constraint function returns a 64-bit value and
* a 64-bit mask that express the constraints between this event and
* other events.
diff --git a/arch/powerpc/kernel/Makefile b/arch/powerpc/kernel/Makefile
index 612b0c4..c5f93f0 100644
--- a/arch/powerpc/kernel/Makefile
+++ b/arch/powerpc/kernel/Makefile
@@ -95,9 +95,9 @@ obj64-$(CONFIG_AUDIT) += compat_audit.o
obj-$(CONFIG_DYNAMIC_FTRACE) += ftrace.o
obj-$(CONFIG_FUNCTION_GRAPH_TRACER)+= ftrace.o
-obj-$(CONFIG_PERF_COUNTERS)+= perf_counter.o power4-pmu.o ppc970-pmu.o \
- power5-pmu.o power5+-pmu.o power6-pmu.o \
- power7-pmu.o
+obj-$(CONFIG_PPC_PERF_CTRS)+= perf_counter.o
+obj64-$(CONFIG_PPC_PERF_CTRS) += power4-pmu.o ppc970-pmu.o power5-pmu.o \
+ power5+-pmu.o power6-pmu.o power7-pmu.o
obj-$(CONFIG_8XX_MINIMAL_FPEMU) += softemu8xx.o
diff --git a/arch/powerpc/kernel/time.c b/arch/powerpc/kernel/time.c
index 15391c2..eae4511 100644
--- a/arch/powerpc/kernel/time.c
+++ b/arch/powerpc/kernel/time.c
@@ -53,6 +53,7 @@
#include linux/posix-timers.h
#include linux/irq.h
#include linux/delay.h
+#include linux/perf_counter.h
#include asm/io.h
#include asm/processor.h
@@ -525,6 +526,26 @@ void __init iSeries_time_init_early(void)
}
#endif /* CONFIG_PPC_ISERIES */
+#if
[PATCH 5/6] perf_counter: powerpc: Add processor back-end for MPC7450 family
This adds support for the performance monitor hardware on the
MPC7450 family of processors (7450, 7451, 7455, 7447/7457, 7447A,
7448), used in the later Apple G4 powermacs/powerbooks and other
machines. These machines have 6 hardware counters with a unique
set of events which can be counted on each counter, with some
events being available on multiple counters.
Raw event codes for these processors are (PMC 8) + PMCSEL.
If PMC is non-zero then the event is that selected by the given
PMCSEL value for that PMC (hardware counter). If PMC is zero
then the event selected is one of the low-numbered ones that are
common to several PMCs. In this case PMCSEL must be = 22 and
the event is what that PMCSEL value would select on PMC1 (but
it may be placed any other PMC that has the same event for that
PMCSEL value).
For events that count cycles or occurrences that exceed a threshold,
the threshold requested can be specified in the 0x3f000 bits of the
raw event codes. If the event uses the threshold multiplier bit
and that bit should be set, that is indicated with the 0x4 bit
of the raw event code.
This fills in some of the generic cache events. Unfortunately there
are quite a few blank spaces in the table, partly because these
processors tend to count cache hits rather than cache accesses.
Signed-off-by: Paul Mackerras pau...@samba.org
---
arch/powerpc/kernel/Makefile |2 +
arch/powerpc/kernel/mpc7450-pmu.c | 417
arch/powerpc/platforms/Kconfig.cputype |1 +
3 files changed, 420 insertions(+), 0 deletions(-)
create mode 100644 arch/powerpc/kernel/mpc7450-pmu.c
diff --git a/arch/powerpc/kernel/Makefile b/arch/powerpc/kernel/Makefile
index c5f93f0..a9f8829 100644
--- a/arch/powerpc/kernel/Makefile
+++ b/arch/powerpc/kernel/Makefile
@@ -98,6 +98,7 @@ obj-$(CONFIG_FUNCTION_GRAPH_TRACER) += ftrace.o
obj-$(CONFIG_PPC_PERF_CTRS)+= perf_counter.o
obj64-$(CONFIG_PPC_PERF_CTRS) += power4-pmu.o ppc970-pmu.o power5-pmu.o \
power5+-pmu.o power6-pmu.o power7-pmu.o
+obj32-$(CONFIG_PPC_PERF_CTRS) += mpc7450-pmu.o
obj-$(CONFIG_8XX_MINIMAL_FPEMU) += softemu8xx.o
@@ -106,6 +107,7 @@ obj-y += iomap.o
endif
obj-$(CONFIG_PPC64)+= $(obj64-y)
+obj-$(CONFIG_PPC32)+= $(obj32-y)
ifneq ($(CONFIG_XMON)$(CONFIG_KEXEC),)
obj-y += ppc_save_regs.o
diff --git a/arch/powerpc/kernel/mpc7450-pmu.c
b/arch/powerpc/kernel/mpc7450-pmu.c
new file mode 100644
index 000..75ff47f
--- /dev/null
+++ b/arch/powerpc/kernel/mpc7450-pmu.c
@@ -0,0 +1,417 @@
+/*
+ * Performance counter support for MPC7450-family processors.
+ *
+ * Copyright 2008-2009 Paul Mackerras, IBM Corporation.
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * as published by the Free Software Foundation; either version
+ * 2 of the License, or (at your option) any later version.
+ */
+#include linux/string.h
+#include linux/perf_counter.h
+#include linux/string.h
+#include asm/reg.h
+#include asm/cputable.h
+
+#define N_COUNTER 6 /* Number of hardware counters */
+#define MAX_ALT3 /* Maximum number of event alternative
codes */
+
+/*
+ * Bits in event code for MPC7450 family
+ */
+#define PM_THRMULT_MSKS0x4
+#define PM_THRESH_SH 12
+#define PM_THRESH_MSK 0x3f
+#define PM_PMC_SH 8
+#define PM_PMC_MSK 7
+#define PM_PMCSEL_MSK 0x7f
+
+/*
+ * Classify events according to how specific their PMC requirements are.
+ * Result is:
+ * 0: can go on any PMC
+ * 1: can go on PMCs 1-4
+ * 2: can go on PMCs 1,2,4
+ * 3: can go on PMCs 1 or 2
+ * 4: can only go on one PMC
+ * -1: event code is invalid
+ */
+#define N_CLASSES 5
+
+static int mpc7450_classify_event(u32 event)
+{
+ int pmc;
+
+ pmc = (event PM_PMC_SH) PM_PMC_MSK;
+ if (pmc) {
+ if (pmc N_COUNTER)
+ return -1;
+ return 4;
+ }
+ event = PM_PMCSEL_MSK;
+ if (event = 1)
+ return 0;
+ if (event = 7)
+ return 1;
+ if (event = 13)
+ return 2;
+ if (event = 22)
+ return 3;
+ return -1;
+}
+
+/*
+ * Events using threshold and possible threshold scale:
+ * codescale? name
+ * 11e N PM_INSTQ_EXCEED_CYC
+ * 11f N PM_ALTV_IQ_EXCEED_CYC
+ * 128 Y PM_DTLB_SEARCH_EXCEED_CYC
+ * 12b Y PM_LD_MISS_EXCEED_L1_CYC
+ * 220 N PM_CQ_EXCEED_CYC
+ * 30c N PM_GPR_RB_EXCEED_CYC
+ * 30d ? PM_FPR_IQ_EXCEED_CYC ?
+ * 311 Y PM_ITLB_SEARCH_EXCEED
+ * 410 N PM_GPR_IQ_EXCEED_CYC
+ */
+
+/*
+ * Return use of threshold and threshold scale bits:
+ * 0 = uses neither, 1 = uses threshold, 2 = uses both
+
Re: [PATCH 1/6] perf_counter: powerpc: Enable use of software counters on 32-bit powerpc
* Paul Mackerras pau...@samba.org wrote: This depends on the generic atomic64_t patches, which are now in Linus' tree. Ingo, if you're putting these in, please pull Linus' tree in first. yes, i already did that earlier today - so all should be fine with the lib/atomic64.c dependency. Ingo ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] Do not inline putprops function
On Wed, Jun 17, 2009 at 05:04:56PM +0530, M. Mohan Kumar wrote:
Do not inline putprops function
With the recent kexec-tools git tree, both kexec and kdump kernels hang (i.e
kexec -l and kexec -p respectively). This happened after the patch ppc64:
cleanups commit b43a84a31a4be6ed025c1bdef3bb1c3c12e01b16. I tried
reverting each hunk and then found out that retaining following lines in
fs2dt.c makes kexec/kdump work.
-static unsigned *dt_len; /* changed len of modified cmdline
- in flat device-tree */
[]
- dt_len = dt;
I don't have any clue why removing a unused variable would cause the kexec
kernel to hang. After further investigation, I observed that if the putprops
function is not inlined, kexec/kdump kernel would work even after removing
the above lines.
This patch directs gcc to not inline the putprops function. Now we could
invoke kexec and kdump kernels.
I'm happy to apply this if you provide a sign-off,
but do you know why not inlining makes a difference here?
---
kexec/arch/ppc64/fs2dt.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/kexec/arch/ppc64/fs2dt.c b/kexec/arch/ppc64/fs2dt.c
index 1f551fd..1e01f74 100644
--- a/kexec/arch/ppc64/fs2dt.c
+++ b/kexec/arch/ppc64/fs2dt.c
@@ -259,7 +259,7 @@ static void add_usable_mem_property(int fd, int len)
}
/* put all properties (files) in the property structure */
-static void putprops(char *fn, struct dirent **nlist, int numlist)
+__attribute__ ((noinline)) static void putprops(char *fn, struct dirent
**nlist, int numlist)
{
struct dirent *dp;
int i = 0, fd, len;
--
1.6.0.6
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: MPC83xx watchdog reset board dead lock
Hi Leon, ... Most designs do not care about the watchdog, or only pet in their non-critical paths... That's not what the watchdog is for. Also, I don't care about u-boot. I care about a design where the Flash NOR could be in write mode at any time when the watchdog triggers, when the hardware is running critical software. No lifes in danger when it happens, only jobs, so no biggy :-) true, I was just looking from SW/u-boot perspective. Ideally the dead-lock is prevented on board/HW level. David has been helpful in thinking this through, but we followed-up offline, and we independently came up with the following design, so this must therefore work (disclaimer applies). Note, it DOES require a NOR flash that has a RY/BUSY# pin. Quoting David Hawkins, who gave a very clear explanation: --- How about using the RDY/BUSY# pin on the Flash in conjunction with PORESET#. If the flash is busy, then the processor gets PORESET#, otherwise, the HRESET# just does its normal thing. That way PORESET# only ever asserts when you have the combo of the Flash being busy and HRESET# asserting. ... If you have the Flash BUSY# signal, then this scheme works great, since using HRESET# low and BUSY# low to create a PORESET# source is only active until the Flash RESET# is asserted long enough for it to get out of the BUSY# state and back into read-array mode. --- Kudos to David. I'll be testing the design tomorrow on the reference board, I'll report results in this thread. Interesting. Looking forward to the results. --- N. van Bolhuis. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [BUG] lib/kernel_lock.c:126 with cgroups regression ltp tests
Michael Ellerman wrote: On Wed, 2009-06-17 at 16:21 +0530, Sachin Sant wrote: While executing cgroups regression tests from LTP May 2009 release on a Power6 box came across the following bug. This is with 2.6.30-git10 (300df7dc89cc276377fc020704e34875d5c473b6) Looks like 337eb00a2 missed some return paths in do_remount_sb()? $ git log -p -U13 337eb00a2c3a421999c39c94ce7e33545ee8baa7 fs/super.c commit 337eb00a2c3a421999c39c94ce7e33545ee8baa7 Author: Alessio Igor Bogani abog...@texware.it Thanks Michael. The following submitted patch from Chris fixes this issue. http://patchwork.kernel.org/patch/30675/ Thanks -Sachin -- - Sachin Sant IBM Linux Technology Center India Systems and Technology Labs Bangalore, India - ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] Do not inline putprops function
On Wed, 2009-06-17 at 17:29 +0530, M. Mohan Kumar wrote: Do not inline putprops function With the recent kexec-tools git tree, both kexec and kdump kernels hang (i.e kexec -l and kexec -p respectively). This happened after the patch ppc64: cleanups commit b43a84a31a4be6ed025c1bdef3bb1c3c12e01b16. I tried reverting each hunk and then found out that retaining following lines in fs2dt.c makes kexec/kdump work. -static unsigned *dt_len; /* changed len of modified cmdline - in flat device-tree */ [] - dt_len = dt; I don't have any clue why removing a unused variable would cause the kexec kernel to hang. After further investigation, I observed that if the putprops function is not inlined, kexec/kdump kernel would work even after removing the above lines. This patch directs gcc to not inline the putprops function. Now we could invoke kexec and kdump kernels. What compiler version are you using? Does the behaviour change if you use a newer/older compiler? It sounds to me like there's some deeper bug and your patch is just papering over it. cheers signature.asc Description: This is a digitally signed message part ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 6/6] perf_counter: tools: Makefile tweaks for 64-bit powerpc
Ingo Molnar writes: ah, it does this: /* * This is here because we used to use l64 for 64bit powerpc * and we don't want to impact user mode with our change to ll64 * in the kernel. */ #if defined(__powerpc64__) !defined(__KERNEL__) # include asm-generic/int-l64.h #else # include asm-generic/int-ll64.h #endif That's crappy really. We were concerned that changing the userland-visible type of __u64 from unsigned long to unsigned long long, etc., would be breaking the ABI, even if only in a small way - I thought it could possibly change C++ mangled function names, for instance, and it would cause fresh compile warnings on existing user code that prints __u64 with %lx, which has always been the correct thing to do on ppc64. A counter-argument would be, I guess, that __u64 et al. are purely for use in describing the kernel/user interface, so we have a little more latitude than with the type of e.g. u_int64_t. I dunno. I don't recall getting much of an answer from the glibc guys about what they thought of the idea of changing it. Anyway, of the 64-bit architectures, alpha, ia64, and mips64 also have __u64 as unsigned long in userspace, so this issue will still crop up even if we change it on powerpc. Paul. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Trouble porting a USB gadget serial UDC driver from 2.6.14 to 2.6.27
Hi, I'm having trouble porting our in-house UDC driver to 2.6.27. It originally worked on 2.6.14 as an CDC-ACM driver. The hardware platform is a mpc8272-based board. I notice a lot of changes since 2.6.14. For starters, instead of the single serial.c file, there is now f_serial.c, u_serial.c and f_acm.c. Currently, the UDC driver in 2.6.27 seems to work if I simply plug the USB cable in between our gadget serial Linux device and a Windows PC. However, if I unplug, then replug the cable, the 'Out' Endpoint seems fine, but the 'In' Endpoint doesn't seem to come up properly. In other words, data only seems to be getting through in the direction from the PC to the gadget serial Linux device, but not vice versa. Is there some sort of architecture document to show how the f_serial.c, u_serial.c and f_acm.c files all fit together? I've searched in the Documentation directory and I've read the usb-gadget-serial docbook document but it doesn't really tell me this. Also, it seems that for some reason composite.c is being compiled and used, but my CDC-ACM gadget serial driver is *not* a composite driver. Is it possible to prevent linking with this composite driver? Cheers, Daniel ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH][Resend 2][BUILD FAILURE 04/04] Next June 04:PPC64 randconfig [drivers/net/ucc_geth.o]
On Mon, 2009-06-15 at 12:22 +0530, Subrata Modak wrote:
Hi Li/Nathan,
On Thu, 2009-06-11 at 09:07 +0530, Subrata Modak wrote:
Hi Nathan,
On Wed, 2009-06-10 at 21:28 -0500, Nathan Lynch wrote:
Subrata Modak subr...@linux.vnet.ibm.com writes:
On Thu, 2009-06-11 at 11:05 +1000, Stephen Rothwell wrote:
Hi Subrata,
On Wed, 10 Jun 2009 23:13:23 +0530 Subrata Modak
subr...@linux.vnet.ibm.com wrote:
/* Find the TBI PHY. If it's not there, we don't support SGMII
*/
-ph = of_get_property(np, tbi-handle, NULL);
+ph = (phandle *)of_get_property(np, tbi-handle, NULL);
You don't need this cast because of_get_property() returns void *.
Stephen,
True. But without this gcc complains:
CC [M] drivers/net/ucc_geth.o
drivers/net/ucc_geth.c: In function bucc_geth_probeb:
drivers/net/ucc_geth.c:3824: warning: assignment discards qualifiers
from pointer target type
ph should be declared const phandle *. Look at other uses of
of_get_property.
Ok fine. Here is a revised patch again.
Subject: [PATCH][Resend 2][BUILD FAILURE 04/04] Next June 04:PPC64
randconfig [drivers/net/ucc_geth.o]
Reference(s):
http://lkml.org/lkml/2009/6/4/241,
http://lkml.org/lkml/2009/6/10/338,
Fix the following build error:
drivers/net/ucc_geth.c: In function bucc_geth_probeb:
drivers/net/ucc_geth.c:3822: error: 'ph' undeclared (first use in this
function)
drivers/net/ucc_geth.c:3822: error: (Each undeclared identifier is reported
only once
drivers/net/ucc_geth.c:3822: error: for each function it appears in.)
drivers/net/ucc_geth.c:3832: error: 'mdio' undeclared (first use in this
function)
make[2]: *** [drivers/net/ucc_geth.o] Error 1
Signed-off-by: Subrata Modak subr...@linux.vnet.ibm.com
---
Is there anything else to be done in this patch. If this is OK, can this
be applied. I am not sure, but, i find Li Yang as the maintainer for
this in linux*/MAINTAINERS file. Kindly let me know if this patch needs
to be revisited for some other issue(s).
Li,
Any thoughts on this patch ?
Regards--
Subrata
Regards--
Subrata
--- linux-2.6.30-rc8/drivers/net/ucc_geth.c.orig2009-06-10
11:58:39.0 -0500
+++ linux-2.6.30-rc8/drivers/net/ucc_geth.c 2009-06-10 22:28:13.0
-0500
@@ -3595,6 +3595,8 @@ static const struct net_device_ops ucc_g
static int ucc_geth_probe(struct of_device* ofdev, const struct
of_device_id *match)
{
+ struct device_node *mdio;
+ const phandle *ph;
struct device *device = ofdev-dev;
struct device_node *np = ofdev-node;
struct net_device *dev = NULL;
---
Regards--
Subrata
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[BUILD FAILURE 02/04] Next June 04:PPC64 randconfig [drivers/usb/host/ohci-hcd.o]
On Mon, 2009-06-15 at 12:21 +0530, Subrata Modak wrote: On Fri, 2009-06-12 at 15:05 +0530, Subrata Modak wrote: On Tue, 2009-06-09 at 17:38 -0700, David Brownell wrote: On Friday 05 June 2009, Subrata Modak wrote: Correct, it fixes the issue. However, since few changes might have gone to the Kconfig, the patch does not apply cleanly. Below is the patch, just a retake of the earlier one, but on the latest code. And it got mangled a bit along the way. Plus, the original one goofed up Kconfig dependency displays ... both issues fixed in this version, against current mainline GIT. If someone can verify all four PPC/OF/OHCI configs build on on PPC64, I'm OK with it. - Dave Dave, Sorry for being late. The patch fixes the issue on the latest git for PPC64. Infact, the whole drivers/usb/host/ builds just fine: linux-2.6 # make drivers/usb/host/ CHK include/linux/version.h CHK include/linux/utsrelease.h SYMLINK include/asm - include/asm-powerpc CALLscripts/checksyscalls.sh CC drivers/usb/host/ohci-hcd.o CC drivers/usb/host/pci-quirks.o CC drivers/usb/host/uhci-hcd.o LD drivers/usb/host/built-in.o CC [M] drivers/usb/host/isp116x-hcd.o CC [M] drivers/usb/host/u132-hcd.o You can check in the patch now. Dave, Have you checked in this patch ? Or, does it require some more modification/updates from somebody´s side ? Dave, Would you consider checking in this patch ? Regards-- Subrata Regards-- Subrata Regards-- Subrata == CUT HERE From: Arnd Bergmann a...@arndb.de Subject: fix build failure for PPC64 randconfig [usb/ohci] We could just make the USB_OHCI_HCD_PPC_OF option implicit and selected only if at least one of USB_OHCI_HCD_PPC_OF_BE and USB_OHCI_HCD_PPC_OF_LE are set. [ dbrown...@users.sourceforge.net: fix patch manglation and dependencies ] Signed-off-by: Arnd Bergmann a...@arndb.de Resent-by: Subrata Modak subr...@linux.vnet.ibm.com Signed-off-by: David Brownell dbrown...@users.sourceforge.net --- drivers/usb/host/Kconfig | 29 +++-- 1 file changed, 15 insertions(+), 14 deletions(-) --- a/drivers/usb/host/Kconfig +++ b/drivers/usb/host/Kconfig @@ -180,26 +180,27 @@ config USB_OHCI_HCD_PPC_SOC Enables support for the USB controller on the MPC52xx or STB03xxx processor chip. If unsure, say Y. -config USB_OHCI_HCD_PPC_OF - bool OHCI support for PPC USB controller on OF platform bus - depends on USB_OHCI_HCD PPC_OF - default y - ---help--- - Enables support for the USB controller PowerPC present on the - OpenFirmware platform bus. - config USB_OHCI_HCD_PPC_OF_BE - bool Support big endian HC - depends on USB_OHCI_HCD_PPC_OF - default y + bool OHCI support for OF platform bus (big endian) + depends on USB_OHCI_HCD PPC_OF select USB_OHCI_BIG_ENDIAN_DESC select USB_OHCI_BIG_ENDIAN_MMIO + ---help--- + Enables support for big-endian USB controllers present on the + OpenFirmware platform bus. config USB_OHCI_HCD_PPC_OF_LE - bool Support little endian HC - depends on USB_OHCI_HCD_PPC_OF - default n + bool OHCI support for OF platform bus (little endian) + depends on USB_OHCI_HCD PPC_OF select USB_OHCI_LITTLE_ENDIAN + ---help--- + Enables support for little-endian USB controllers present on the + OpenFirmware platform bus. + +config USB_OHCI_HCD_PPC_OF + bool + depends on USB_OHCI_HCD PPC_OF + default USB_OHCI_HCD_PPC_OF_BE || USB_OHCI_HCD_PPC_OF_LE config USB_OHCI_HCD_PCI bool OHCI support for PCI-bus USB controllers ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH][Resend 2][BUILD FAILURE 04/04] Next June 04:PPC64 randconfig [drivers/net/ucc_geth.o]
On Jun 17, 2009, at 7:51 AM, Subrata Modak wrote:
On Mon, 2009-06-15 at 12:22 +0530, Subrata Modak wrote:
Hi Li/Nathan,
On Thu, 2009-06-11 at 09:07 +0530, Subrata Modak wrote:
Hi Nathan,
On Wed, 2009-06-10 at 21:28 -0500, Nathan Lynch wrote:
Subrata Modak subr...@linux.vnet.ibm.com writes:
On Thu, 2009-06-11 at 11:05 +1000, Stephen Rothwell wrote:
Hi Subrata,
On Wed, 10 Jun 2009 23:13:23 +0530 Subrata Modak subr...@linux.vnet.ibm.com
wrote:
/* Find the TBI PHY. If it's not there, we don't support
SGMII */
- ph = of_get_property(np, tbi-handle, NULL);
+ ph = (phandle *)of_get_property(np, tbi-handle, NULL);
You don't need this cast because of_get_property() returns
void *.
Stephen,
True. But without this gcc complains:
CC [M] drivers/net/ucc_geth.o
drivers/net/ucc_geth.c: In function bucc_geth_probeb:
drivers/net/ucc_geth.c:3824: warning: assignment discards
qualifiers
from pointer target type
ph should be declared const phandle *. Look at other uses of
of_get_property.
Ok fine. Here is a revised patch again.
Subject: [PATCH][Resend 2][BUILD FAILURE 04/04] Next June 04:PPC64
randconfig [drivers/net/ucc_geth.o]
Reference(s):
http://lkml.org/lkml/2009/6/4/241,
http://lkml.org/lkml/2009/6/10/338,
Fix the following build error:
drivers/net/ucc_geth.c: In function bucc_geth_probeb:
drivers/net/ucc_geth.c:3822: error: 'ph' undeclared (first use in
this function)
drivers/net/ucc_geth.c:3822: error: (Each undeclared identifier is
reported only once
drivers/net/ucc_geth.c:3822: error: for each function it appears
in.)
drivers/net/ucc_geth.c:3832: error: 'mdio' undeclared (first use
in this function)
make[2]: *** [drivers/net/ucc_geth.o] Error 1
Signed-off-by: Subrata Modak subr...@linux.vnet.ibm.com
---
Is there anything else to be done in this patch. If this is OK, can
this
be applied. I am not sure, but, i find Li Yang as the maintainer for
this in linux*/MAINTAINERS file. Kindly let me know if this patch
needs
to be revisited for some other issue(s).
Li,
Any thoughts on this patch ?
Regards--
Subrata
Regards--
Subrata
--- linux-2.6.30-rc8/drivers/net/ucc_geth.c.orig 2009-06-10
11:58:39.0 -0500
+++ linux-2.6.30-rc8/drivers/net/ucc_geth.c 2009-06-10
22:28:13.0 -0500
@@ -3595,6 +3595,8 @@ static const struct net_device_ops ucc_g
static int ucc_geth_probe(struct of_device* ofdev, const struct
of_device_id *match)
{
+ struct device_node *mdio;
+ const phandle *ph;
struct device *device = ofdev-dev;
struct device_node *np = ofdev-node;
struct net_device *dev = NULL;
---
Regards--
Subrata
I'm confused by the proposed fix as we already have *mdio *ph
defined in this function:
static int ucc_geth_probe(struct of_device* ofdev, const struct
of_device_id *match)
{
struct device *device = ofdev-dev;
struct device_node *np = ofdev-node;
struct device_node *mdio;
struct net_device *dev = NULL;
struct ucc_geth_private *ugeth = NULL;
struct ucc_geth_info *ug_info;
struct resource res;
struct device_node *phy;
int err, ucc_num, max_speed = 0;
const phandle *ph;
const u32 *fixed_link;
const unsigned int *prop;
const char *sprop;
const void *mac_addr;
...
- k
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] Do not inline putprops function
On Wed, Jun 17, 2009 at 10:26:35PM +1000, Michael Ellerman wrote: On Wed, 2009-06-17 at 17:29 +0530, M. Mohan Kumar wrote: Do not inline putprops function With the recent kexec-tools git tree, both kexec and kdump kernels hang (i.e kexec -l and kexec -p respectively). This happened after the patch ppc64: cleanups commit b43a84a31a4be6ed025c1bdef3bb1c3c12e01b16. I tried reverting each hunk and then found out that retaining following lines in fs2dt.c makes kexec/kdump work. -static unsigned *dt_len; /* changed len of modified cmdline - in flat device-tree */ [] - dt_len = dt; I don't have any clue why removing a unused variable would cause the kexec kernel to hang. After further investigation, I observed that if the putprops function is not inlined, kexec/kdump kernel would work even after removing the above lines. This patch directs gcc to not inline the putprops function. Now we could invoke kexec and kdump kernels. What compiler version are you using? Does the behaviour change if you use a newer/older compiler? It sounds to me like there's some deeper bug and your patch is just papering over it. Agreed, this doesn't make any sense. Try changing the compiler version to see if the problem goes away or stops. It might also be worthwhile to dump the contents of the device tree at the start and end of the kexec process. If the changing of how a function is inlined is causing a hang, its likely changing how the putprops function is writing information to the device tree. Understanding what that change is will likely provide clues to how the code has changed. Neil cheers ___ kexec mailing list ke...@lists.infradead.org http://lists.infradead.org/mailman/listinfo/kexec ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: PowerPC PCI DMA issues (prefetch/coherency?)
Chris Pringle wrote: You could enable CONFIG_NOT_COHERENT_CACHE. I've just tried this (I had to edit Kconfig in power/platforms to make the build system accept it), and interestingly it's making no difference. I'm using streaming mappings, and are using the pci_map_sg functions to ensure the memory is mapped/flushed correctly. I've also explicitly put in a pci_dma_sync_sg_for_device, however that's also not made any difference. Turning the cpu cache snoop off has the same affect as it did without CONFIG_NOT_COHERENT_CACHE; it gets much worse. Any other ideas? Will back off the low latency patches next, and give 2.6.30 a try - see if that makes any difference. Low latency patches made no difference. Tried it with 2.6.30 and it now works. There are a couple of commits contributing to the fix, including one introduced between 2.6.29-rc8 and 2.6.29 proper in powerpc/kernel/head_32.S (couple of commits with the name Fix Respect _PAGE_COHERENT on classic ppc32 SW TLB load machines). I've tried backporting this to 2.6.29-rc8 and it then worked. Backporting to 2.6.26 made no difference however, so I suspect there are other things fixed which are also contributing. I'm going to move to 2.6.29/2.6.30 which should resolve our issue. Thanks to all who have contributed to this thread. Chris -- __ Chris Pringle Software Engineer Miranda Technologies Ltd. Hithercroft Road Wallingford Oxfordshire OX10 9DG UK Tel. +44 1491 820206 Fax. +44 1491 820001 www.miranda.com Miranda Technologies Limited Registered in England and Wales CN 02017053 Registered Office: James House, Mere Park, Dedmere Road, Marlow, Bucks, SL7 1FJ ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH][Resend 2][BUILD FAILURE 04/04] Next June 04:PPC64 randconfig [drivers/net/ucc_geth.o]
Hi Kumar, On Wed, 17 Jun 2009 08:07:47 -0500 Kumar Gala ga...@kernel.crashing.org wrote: I'm confused by the proposed fix as we already have *mdio *ph defined in this function: Which tree are you looking at? Linus' tree, and linux-next, do not have those local variables ... -- Cheers, Stephen Rothwells...@canb.auug.org.au http://www.canb.auug.org.au/~sfr/ pgpoCIoOrAduS.pgp Description: PGP signature ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 6/6] perf_counter: tools: Makefile tweaks for 64-bit powerpc
* Paul Mackerras pau...@samba.org wrote: Ingo Molnar writes: ah, it does this: /* * This is here because we used to use l64 for 64bit powerpc * and we don't want to impact user mode with our change to ll64 * in the kernel. */ #if defined(__powerpc64__) !defined(__KERNEL__) # include asm-generic/int-l64.h #else # include asm-generic/int-ll64.h #endif That's crappy really. We were concerned that changing the userland-visible type of __u64 from unsigned long to unsigned long long, etc., would be breaking the ABI, even if only in a small way - I thought it could possibly change C++ mangled function names, for instance, and it would cause fresh compile warnings on existing user code that prints __u64 with %lx, which has always been the correct thing to do on ppc64. A counter-argument would be, I guess, that __u64 et al. are purely for use in describing the kernel/user interface, so we have a little more latitude than with the type of e.g. u_int64_t. I dunno. I don't recall getting much of an answer from the glibc guys about what they thought of the idea of changing it. Anyway, of the 64-bit architectures, alpha, ia64, and mips64 also have __u64 as unsigned long in userspace, so this issue will still crop up even if we change it on powerpc. Having crap elsewhere is no reason to spread it further really. We need consistent types. Can we define __KERNEL__ perhaps to get to the real types? Ingo ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] Do not inline putprops function
On Wed, Jun 17, 2009 at 09:04:13AM -0400, Neil Horman wrote: On Wed, Jun 17, 2009 at 10:26:35PM +1000, Michael Ellerman wrote: What compiler version are you using? Does the behaviour change if you use a newer/older compiler? It sounds to me like there's some deeper bug and your patch is just papering over it. I tried with gcc 4.3.2. Let me try with a recent version and update. Agreed, this doesn't make any sense. Try changing the compiler version to see if the problem goes away or stops. It might also be worthwhile to dump the contents of the device tree at the start and end of the kexec process. If the changing of how a function is inlined is causing a hang, its likely changing how the putprops function is writing information to the device tree. Understanding what that change is will likely provide clues to how the code has changed. Neil, there was no code change in fs2dt.c Regards, M. Mohan Kumar ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH][Resend 2][BUILD FAILURE 04/04] Next June 04:PPC64 randconfig [drivers/net/ucc_geth.o]
On Wed, 17 Jun 2009 23:23:41 +1000 Stephen Rothwell s...@canb.auug.org.au
wrote:
Hi Kumar,
On Wed, 17 Jun 2009 08:07:47 -0500 Kumar Gala ga...@kernel.crashing.org
wrote:
I'm confused by the proposed fix as we already have *mdio *ph
defined in this function:
Which tree are you looking at? Linus' tree, and linux-next, do not have
those local variables ...
Hmmm, commit 0b9da337dca972e7a4144e298ec3adb8f244d4a4 (net: Rework
ucc_geth driver to use of_mdio infrastructure) removed the locals along
with their usages, then commit 047584ce94108012288554a5f84585d792cc7f8f
(net/ucc_geth: Add SGMII support for UEC GETH driver) added more uses
without adding the variables back.
Here is the patch again:
From: Subrata Modak subr...@linux.vnet.ibm.com
Subject: [PATCH] Fix build error in ucc_geth.c
Fix the following build error:
drivers/net/ucc_geth.c: In function bucc_geth_probeb:
drivers/net/ucc_geth.c:3822: error: 'ph' undeclared (first use in this function)
drivers/net/ucc_geth.c:3822: error: (Each undeclared identifier is reported
only once
drivers/net/ucc_geth.c:3822: error: for each function it appears in.)
drivers/net/ucc_geth.c:3832: error: 'mdio' undeclared (first use in this
function)
make[2]: *** [drivers/net/ucc_geth.o] Error 1
Signed-off-by: Subrata Modak subr...@linux.vnet.ibm.com
--- linux-2.6.30-rc8/drivers/net/ucc_geth.c.orig2009-06-10
11:58:39.0 -0500
+++ linux-2.6.30-rc8/drivers/net/ucc_geth.c 2009-06-10 22:28:13.0
-0500
@@ -3595,6 +3595,8 @@ static const struct net_device_ops ucc_g
static int ucc_geth_probe(struct of_device* ofdev, const struct of_device_id
*match)
{
+ struct device_node *mdio;
+ const phandle *ph;
struct device *device = ofdev-dev;
struct device_node *np = ofdev-node;
struct net_device *dev = NULL;
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: linux-next: kvm/powerpc tree build failure
On 06/17/2009 08:04 AM, Stephen Rothwell wrote: From: Stephen Rothwells...@canb.auug.org.au Date: Wed, 17 Jun 2009 14:57:29 +1000 Subject: [PATCH] kvm/powerpc: make 32 bit constant unsigned long KVM_PAGES_PER_HPAGE needs to be unsigned long since its value is 2^31. Eliminates this compiler warning: Thanks, applied. For some reason my own build testing didn't fail on this. -- Do not meddle in the internals of kernels, for they are subtle and quick to panic. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH][Resend 2][BUILD FAILURE 04/04] Next June 04:PPC64 randconfig [drivers/net/ucc_geth.o]
On Jun 17, 2009, at 8:34 AM, Stephen Rothwell wrote:
On Wed, 17 Jun 2009 23:23:41 +1000 Stephen Rothwell s...@canb.auug.org.au
wrote:
Hi Kumar,
On Wed, 17 Jun 2009 08:07:47 -0500 Kumar Gala ga...@kernel.crashing.org
wrote:
I'm confused by the proposed fix as we already have *mdio *ph
defined in this function:
Which tree are you looking at? Linus' tree, and linux-next, do not
have
those local variables ...
Hmmm, commit 0b9da337dca972e7a4144e298ec3adb8f244d4a4 (net: Rework
ucc_geth driver to use of_mdio infrastructure) removed the locals
along
with their usages, then commit
047584ce94108012288554a5f84585d792cc7f8f
(net/ucc_geth: Add SGMII support for UEC GETH driver) added more
uses
without adding the variables back.
Here is the patch again:
From: Subrata Modak subr...@linux.vnet.ibm.com
Subject: [PATCH] Fix build error in ucc_geth.c
Fix the following build error:
drivers/net/ucc_geth.c: In function bucc_geth_probeb:
drivers/net/ucc_geth.c:3822: error: 'ph' undeclared (first use in
this function)
drivers/net/ucc_geth.c:3822: error: (Each undeclared identifier is
reported only once
drivers/net/ucc_geth.c:3822: error: for each function it appears in.)
drivers/net/ucc_geth.c:3832: error: 'mdio' undeclared (first use in
this function)
make[2]: *** [drivers/net/ucc_geth.o] Error 1
Signed-off-by: Subrata Modak subr...@linux.vnet.ibm.com
--- linux-2.6.30-rc8/drivers/net/ucc_geth.c.orig 2009-06-10
11:58:39.0 -0500
+++ linux-2.6.30-rc8/drivers/net/ucc_geth.c 2009-06-10
22:28:13.0 -0500
@@ -3595,6 +3595,8 @@ static const struct net_device_ops ucc_g
static int ucc_geth_probe(struct of_device* ofdev, const struct
of_device_id *match)
{
+ struct device_node *mdio;
+ const phandle *ph;
struct device *device = ofdev-dev;
struct device_node *np = ofdev-node;
struct net_device *dev = NULL;
ah... was looking at powerpc next which hasn't pulled in linus's
latest tree w/netdev updates.
- k
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: linux-next: kvm/powerpc tree build failure
Hi Avi, On Wed, 17 Jun 2009 16:49:51 +0300 Avi Kivity a...@redhat.com wrote: Thanks, applied. For some reason my own build testing didn't fail on this. Thanks. It could be a different compiler version doesn't complain (I am currently using 4.4.0) and the powerpc tree has a patch to build parts of arch/powerpc with -Werror which makes it stand out a bit :-) -- Cheers, Stephen Rothwells...@canb.auug.org.au http://www.canb.auug.org.au/~sfr/ pgprmskd76CoZ.pgp Description: PGP signature ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH] net/ucc_geth: Fix compile errors
From: Subrata Modak subr...@linux.vnet.ibm.com
drivers/net/ucc_geth.c: In function 'ucc_geth_probe':
drivers/net/ucc_geth.c:3822: error: 'ph' undeclared (first use in this function)
drivers/net/ucc_geth.c:3822: error: (Each undeclared identifier is reported
only once
drivers/net/ucc_geth.c:3822: error: for each function it appears in.)
drivers/net/ucc_geth.c:3832: error: 'mdio' undeclared (first use in this
function)
Signed-off-by: Subrata Modak subr...@linux.vnet.ibm.com
Signed-off-by: Kumar Gala ga...@kernel.crashing.org
---
drivers/net/ucc_geth.c |2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/drivers/net/ucc_geth.c b/drivers/net/ucc_geth.c
index e2f2e91..31da996 100644
--- a/drivers/net/ucc_geth.c
+++ b/drivers/net/ucc_geth.c
@@ -3595,6 +3595,8 @@ static const struct net_device_ops ucc_geth_netdev_ops = {
static int ucc_geth_probe(struct of_device* ofdev, const struct of_device_id
*match)
{
+ struct device_node *mdio;
+ const phandle *ph;
struct device *device = ofdev-dev;
struct device_node *np = ofdev-node;
struct net_device *dev = NULL;
--
1.6.0.6
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: linux-next: kvm/powerpc tree build failure
On 06/17/2009 04:55 PM, Stephen Rothwell wrote: Hi Avi, On Wed, 17 Jun 2009 16:49:51 +0300 Avi Kivitya...@redhat.com wrote: Thanks, applied. For some reason my own build testing didn't fail on this. Thanks. It could be a different compiler version doesn't complain (I am currently using 4.4.0) and the powerpc tree has a patch to build parts of arch/powerpc with -Werror which makes it stand out a bit :-) Ah yes, you did mention it was a warning. -- Do not meddle in the internals of kernels, for they are subtle and quick to panic. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] Do not inline putprops function
On Wed, Jun 17, 2009 at 07:04:35PM +0530, M. Mohan Kumar wrote: On Wed, Jun 17, 2009 at 09:04:13AM -0400, Neil Horman wrote: On Wed, Jun 17, 2009 at 10:26:35PM +1000, Michael Ellerman wrote: What compiler version are you using? Does the behaviour change if you use a newer/older compiler? It sounds to me like there's some deeper bug and your patch is just papering over it. I tried with gcc 4.3.2. Let me try with a recent version and update. Agreed, this doesn't make any sense. Try changing the compiler version to see if the problem goes away or stops. It might also be worthwhile to dump the contents of the device tree at the start and end of the kexec process. If the changing of how a function is inlined is causing a hang, its likely changing how the putprops function is writing information to the device tree. Understanding what that change is will likely provide clues to how the code has changed. Neil, there was no code change in fs2dt.c Sure there was, by modifying the code to tell it to not inline the putprops function, you changed how the complier optimizes that code block. There may not be any source level code change, but the assembly is certainly different, and it must be so in a way thats causing a hang. The putpops function changes the contents of the ppc64 device-tree, so if this is a compiler bug, and its causing a hang, I imagine we'll see some manifestation in a change in the device tree contents. Neil Regards, M. Mohan Kumar ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 1/6] perf_counter: powerpc: Enable use of software counters on 32-bit powerpc
On Jun 17, 2009, at 6:50 AM, Paul Mackerras wrote: diff --git a/arch/powerpc/platforms/Kconfig.cputype b/arch/powerpc/ platforms/Kconfig.cputype index cca6b4f..dd9f3ec 100644 --- a/arch/powerpc/platforms/Kconfig.cputype +++ b/arch/powerpc/platforms/Kconfig.cputype @@ -1,7 +1,7 @@ config PPC64 bool 64-bit kernel default n - select HAVE_PERF_COUNTERS + select PPC_HAVE_PMU_SUPPORT help This option selects whether a 32-bit or a 64-bit kernel will be built. @@ -243,6 +243,15 @@ config VIRT_CPU_ACCOUNTING If in doubt, say Y here. +config PPC_HAVE_PMU_SUPPORT + bool what does this mean? + +config PPC_PERF_CTRS + def_bool y + depends on PERF_COUNTERS PPC_HAVE_PMU_SUPPORT + help + This enables the powerpc-specific perf_counter back-end. Can we distinguish between the two different architected perf counters programming models to start with. Maybe something like: PPC_BOOK3S_PERF_CTRS and PPC_BOOK3E_PERF_CTRS (or PPC_SERVER_PERF_CTRS / PPC_EMB_PERF_CTRS) + config SMP depends on PPC_STD_MMU || FSL_BOOKE bool Symmetric multi-processing support -- 1.6.0.4 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 5/6] perf_counter: powerpc: Add processor back-end for MPC7450 family
On Jun 17, 2009, at 6:53 AM, Paul Mackerras wrote: This adds support for the performance monitor hardware on the MPC7450 family of processors (7450, 7451, 7455, 7447/7457, 7447A, 7448), used in the later Apple G4 powermacs/powerbooks and other machines. These machines have 6 hardware counters with a unique set of events which can be counted on each counter, with some events being available on multiple counters. Raw event codes for these processors are (PMC 8) + PMCSEL. If PMC is non-zero then the event is that selected by the given PMCSEL value for that PMC (hardware counter). If PMC is zero then the event selected is one of the low-numbered ones that are common to several PMCs. In this case PMCSEL must be = 22 and the event is what that PMCSEL value would select on PMC1 (but it may be placed any other PMC that has the same event for that PMCSEL value). For events that count cycles or occurrences that exceed a threshold, the threshold requested can be specified in the 0x3f000 bits of the raw event codes. If the event uses the threshold multiplier bit and that bit should be set, that is indicated with the 0x4 bit of the raw event code. This fills in some of the generic cache events. Unfortunately there are quite a few blank spaces in the table, partly because these processors tend to count cache hits rather than cache accesses. Signed-off-by: Paul Mackerras pau...@samba.org --- arch/powerpc/kernel/Makefile |2 + arch/powerpc/kernel/mpc7450-pmu.c | 417 +++ + arch/powerpc/platforms/Kconfig.cputype |1 + 3 files changed, 420 insertions(+), 0 deletions(-) create mode 100644 arch/powerpc/kernel/mpc7450-pmu.c diff --git a/arch/powerpc/kernel/Makefile b/arch/powerpc/kernel/ Makefile index c5f93f0..a9f8829 100644 --- a/arch/powerpc/kernel/Makefile +++ b/arch/powerpc/kernel/Makefile @@ -98,6 +98,7 @@ obj-$(CONFIG_FUNCTION_GRAPH_TRACER) += ftrace.o obj-$(CONFIG_PPC_PERF_CTRS) += perf_counter.o obj64-$(CONFIG_PPC_PERF_CTRS) += power4-pmu.o ppc970-pmu.o power5- pmu.o \ power5+-pmu.o power6-pmu.o power7-pmu.o This should be something like: obj64-$(CONFIG_PPC_PERF_CTRS)-$(PPC_BOOK3S_64) +obj32-$(CONFIG_PPC_PERF_CTRS) += mpc7450-pmu.o obj32-$(CONFIG_PPC_PERF_CTRS)-$(PPC_BOOK3S_32) Or use new Kconfig types as I suggested on patch 1/6 obj-$(CONFIG_8XX_MINIMAL_FPEMU) += softemu8xx.o @@ -106,6 +107,7 @@ obj-y += iomap.o endif obj-$(CONFIG_PPC64) += $(obj64-y) +obj-$(CONFIG_PPC32)+= $(obj32-y) ifneq ($(CONFIG_XMON)$(CONFIG_KEXEC),) obj-y += ppc_save_regs.o diff --git a/arch/powerpc/kernel/mpc7450-pmu.c b/arch/pow ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 1/6] perf_counter: powerpc: Enable use of software counters on 32-bit powerpc
* Paul Mackerras pau...@samba.org wrote: This depends on the generic atomic64_t patches, which are now in Linus' tree. Ingo, if you're putting these in, please pull Linus' tree in first. Note, i've created a new branch, tip:perfcounters/powerpc, so we can keep these things separate and Ben can pull them too. I see there was some review feedback - do you want to send a v2 version perhaps? Ingo ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 1/6] perf_counter: powerpc: Enable use of software counters on 32-bit powerpc
On Jun 17, 2009, at 9:21 AM, Ingo Molnar wrote: * Paul Mackerras pau...@samba.org wrote: This depends on the generic atomic64_t patches, which are now in Linus' tree. Ingo, if you're putting these in, please pull Linus' tree in first. Note, i've created a new branch, tip:perfcounters/powerpc, so we can keep these things separate and Ben can pull them too. I see there was some review feedback - do you want to send a v2 version perhaps? Out of interest, is the intent to try and get these changes into .31? I ask because I want to know if I should try to find time to add support for the FSL embedded perfmon ASAP or not. - k ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] Do not inline putprops function
On Wed, Jun 17, 2009 at 10:05:14AM -0400, Neil Horman wrote: On Wed, Jun 17, 2009 at 07:04:35PM +0530, M. Mohan Kumar wrote: On Wed, Jun 17, 2009 at 09:04:13AM -0400, Neil Horman wrote: On Wed, Jun 17, 2009 at 10:26:35PM +1000, Michael Ellerman wrote: What compiler version are you using? Does the behaviour change if you use a newer/older compiler? It sounds to me like there's some deeper bug and your patch is just papering over it. I tried with gcc 4.3.2. Let me try with a recent version and update. Agreed, this doesn't make any sense. Try changing the compiler version to see if the problem goes away or stops. It might also be worthwhile to dump the contents of the device tree at the start and end of the kexec process. If the changing of how a function is inlined is causing a hang, its likely changing how the putprops function is writing information to the device tree. Understanding what that change is will likely provide clues to how the code has changed. Neil, there was no code change in fs2dt.c Sure there was, by modifying the code to tell it to not inline the putprops function, you changed how the complier optimizes that code block. There may not be any source level code change, but the assembly is certainly different, and it must be so in a way thats causing a hang. The putpops function changes the contents of the ppc64 device-tree, so if this is a compiler bug, and its causing a hang, I imagine we'll see some manifestation in a change in the device tree contents. As I mentioned in the patch description, when I retained the variable dt_len and dt_len = dt assignment, kexec/kdump kernel would work. But even if I comment the dt_len = dt assignment kernel would hang. If you need I can send objdump of fs2dt.o with and without this assignment. Regards, M. Mohan Kumar. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 1/6] perf_counter: powerpc: Enable use of software counters on 32-bit powerpc
* Kumar Gala ga...@kernel.crashing.org wrote: On Jun 17, 2009, at 9:21 AM, Ingo Molnar wrote: * Paul Mackerras pau...@samba.org wrote: This depends on the generic atomic64_t patches, which are now in Linus' tree. Ingo, if you're putting these in, please pull Linus' tree in first. Note, i've created a new branch, tip:perfcounters/powerpc, so we can keep these things separate and Ben can pull them too. I see there was some review feedback - do you want to send a v2 version perhaps? Out of interest, is the intent to try and get these changes into .31? I ask because I want to know if I should try to find time to add support for the FSL embedded perfmon ASAP or not. I think it would be nice to have more platform support in .31. Perfcounters is a brand-new feature so there's no risk of regression. In the end it will depend on Linus to pull of course, and BenH can veto it too if he'd like no more PowerPC changes in this cycle. Worst-case it's all .32 material. Ingo ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] Do not inline putprops function
On Wed, Jun 17, 2009 at 07:56:52PM +0530, M. Mohan Kumar wrote: On Wed, Jun 17, 2009 at 10:05:14AM -0400, Neil Horman wrote: On Wed, Jun 17, 2009 at 07:04:35PM +0530, M. Mohan Kumar wrote: On Wed, Jun 17, 2009 at 09:04:13AM -0400, Neil Horman wrote: On Wed, Jun 17, 2009 at 10:26:35PM +1000, Michael Ellerman wrote: What compiler version are you using? Does the behaviour change if you use a newer/older compiler? It sounds to me like there's some deeper bug and your patch is just papering over it. I tried with gcc 4.3.2. Let me try with a recent version and update. Agreed, this doesn't make any sense. Try changing the compiler version to see if the problem goes away or stops. It might also be worthwhile to dump the contents of the device tree at the start and end of the kexec process. If the changing of how a function is inlined is causing a hang, its likely changing how the putprops function is writing information to the device tree. Understanding what that change is will likely provide clues to how the code has changed. Neil, there was no code change in fs2dt.c Sure there was, by modifying the code to tell it to not inline the putprops function, you changed how the complier optimizes that code block. There may not be any source level code change, but the assembly is certainly different, and it must be so in a way thats causing a hang. The putpops function changes the contents of the ppc64 device-tree, so if this is a compiler bug, and its causing a hang, I imagine we'll see some manifestation in a change in the device tree contents. As I mentioned in the patch description, when I retained the variable dt_len and dt_len = dt assignment, kexec/kdump kernel would work. But even if I comment the dt_len = dt assignment kernel would hang. If you need I can Yes, and as Michael has noted, that is likey an indication of a compiler bug. You shouldn't get differing behavior in a kdump kernel by removing an unused variable in kexec. Which is why I'm unconvinced this patch is really fixing anything, but rather just avoiding the real problem. send objdump of fs2dt.o with and without this assignment. That would be a fine thing to do, and I'd be happy to compare them. My though regarding the comparison of the device tree on a good and bad run was meant to expidite what change in the assembly we'd be looking for. If its the kdump kernel boot thats hanging, Its likely hanging on something in the device tree, as thats whats being manipulated by this code. So I figure that understanding whats changed there will point us toward what change in the assembly might be responsible for the hang. The assmebly's going to be signficantly different (lots of optimization might be lost from no longer inlining a function), so anything that helps us narrow down whats changed will be good Neil Regards, M. Mohan Kumar. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
ethernet packet drop
Hello everyone, I am working on a project for router development. The basic specifications of the router are as follows: · Supports MPC8248 - 32-bit PowerQUICC II Communication Processor running at 400 MHz (Max) core frequency, 200 MHz (Max) CPM, and 100MHz (Max) external bus frequency. · 64-bit wide 256-MByte synchronous DRAM (soldered on-board), consisting of 4 no. devices of 8M x 16 x 4, residing on 60X bus (PBI mode), controlled by SDRAM machine. · 256 MB NAND Flash, organized as 256M x 8, buffered from 60X bus, controlled by UPM machine. · Upto 8MB NOR Flash, Boot sector (bottom) type, organized as 8M x 8, buffered from 60X bus, controlled by GPCM machine. · Linux Kernel version: linux-2.6.16.40 While testing my router with the spirent test equipment, the 2 ethernet ports of the router are connected to the testing equipment. I send data from the testing equipment through the ethernet port , the router forwards the packet to the other ethernet port again connected to the testing equipment. When I increase the throughput to 70 mbps the testing equipment starts showing packet losses which should not happen as its a 10/100 mbps link. I am not able to understand where would the problem lie. Pls if someone can list the different issues due to which this problem is occurring, it will be really helpful Regards, Mehul ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: 2.6.30-rc6: Problem with an SSD disk on Freescale PowerPC mpc8315e-rdb, works fine on x86
Hello Kumar, all, On Mon, Jun 8, 2009 at 4:59 PM, Leon Woestenbergleon.woestenb...@gmail.com wrote: using 2.6.30-rc6, I get the following problems when I read from a SSD disk, connected to the 3.0 Gb SATA controller of the MPC8315E SoC rev 1.0 running Linux 2.6.30-rc6. Result on a first batch of bisects. I decided to go with the kernel releases rather than git-bisect (still too scary for me). All kernel releases 2.6.25 through -30 kernel gave the same error. 2.6.25 crashed on it, whereas 2.6.26+ recovered after each dd run. The BSP 2.6.24.3-rt3 kernel did not give the error. So on my todo is diff between 2.6.25 and .2.6.24.3-rt3 from the BSP. Regards, -- Leon ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [RFC PATCH] fsldma: Add DMA_SLAVE support
Ira Snyder wrote: Using EXPORT_SYMBOL would defeat the purpose of conforming to the dmaengine api which should allow other subsystems to generically discover an fsldma resource. Any driver would still use dma_request_channel(), etc. to get access to a DMA channel. AFAICT, DMA_SLAVE is intended for doing something completely hardware-specific with the DMA controller. Yes. Specifically DMA_SLAVE operations imply a pre-established context with a 3rd device (the other 2 devices being system memory and the dma channel), as compared to plain memcpy. The assumption is that a dma device with this capability may not be shared with other requesters until the context is torn down. [..] What I've implemented is this: (sorry about the poor drawing) scatterlist fsl_dma_hw_addr +++---+ | DATA | | DEST1 | | DATA | + +---+ | DATA | | | DATA | | +---+ | DATA | +--- | DEST2 | | DATA |+---+ ++ . . . Of course, the reverse works as well. You can copy from a list of hardware address/length pairs to a scatterlist. So, using my implementation of the DMA_SLAVE feature, you can take a big chunk of data (which is organized into a scatterlist) and DMA it directly to a set of hardware addresses, all in a single, unbroken transaction. Could the same effect be achieved by calling -prep_slave_sg multiple times? Once you need to add dma-driver specific helper routines you are effectively extending the dmaengine interface in an fsldma specific fashion. Can we reduce this to just the existing primitives? If it turns out that this is untenable can we extend dmaengine to make this a generic capability? My preference is the former. I've inlined the driver for the FPGA programmer below. I don't think it is appropriate to push into mainline, since it will only work for our board, and nothing else. If we find that we need to extend the dmaengine interface we will need an in-tree user. In my opinion, as long as it passes the Voyager test [1] then I do not see why it should be barred from upstream. [..] He also used platform data to get the register addresses. I'm unaware of a way to put arbitrary platform data into the OF tree used on PowerPC. Anybody else on ppc-dev know if this is possible?? I didn't want to force other users to implement the allocation routines for the struct fsl_dma_hw_addr themselves, so I provided routines to do so. It depends on how many users of this feature there ends up being, pushing this into each driver that needs it would not be too horrible especially if it just the three straightforward routines (fsl_dma_slave_append, fsl_dma_slave_free, and fsl_dma_slave_alloc). So, the three options in order of preference are: 1/ arrange to call -prep multiple times to handle each dma address 2/ push the functionality down into the individual drivers that need it 3/ up level the functionality into dmaengine to make it generically available Thanks, Dan [1]: The Voyager test refers to James Bottomley's maintenance of the Voyager x86-sub-architecture. If at least one person cares about a feature, is willing to maintain the code, and it does not impose a maintenance burden on other parts of the tree then it can go upstream. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH][Resend 2][BUILD FAILURE 04/04] Next June 04:PPC64 randconfig [drivers/net/ucc_geth.o]
On Wed, Jun 17, 2009 at 7:34 AM, Stephen Rothwells...@canb.auug.org.au wrote:
On Wed, 17 Jun 2009 23:23:41 +1000 Stephen Rothwell s...@canb.auug.org.au
wrote:
Hi Kumar,
On Wed, 17 Jun 2009 08:07:47 -0500 Kumar Gala ga...@kernel.crashing.org
wrote:
I'm confused by the proposed fix as we already have *mdio *ph
defined in this function:
Which tree are you looking at? Linus' tree, and linux-next, do not have
those local variables ...
Hmmm, commit 0b9da337dca972e7a4144e298ec3adb8f244d4a4 (net: Rework
ucc_geth driver to use of_mdio infrastructure) removed the locals along
with their usages, then commit 047584ce94108012288554a5f84585d792cc7f8f
(net/ucc_geth: Add SGMII support for UEC GETH driver) added more uses
without adding the variables back.
Here is the patch again:
From: Subrata Modak subr...@linux.vnet.ibm.com
Subject: [PATCH] Fix build error in ucc_geth.c
Fix the following build error:
drivers/net/ucc_geth.c: In function bucc_geth_probeb:
drivers/net/ucc_geth.c:3822: error: 'ph' undeclared (first use in this
function)
drivers/net/ucc_geth.c:3822: error: (Each undeclared identifier is reported
only once
drivers/net/ucc_geth.c:3822: error: for each function it appears in.)
drivers/net/ucc_geth.c:3832: error: 'mdio' undeclared (first use in this
function)
make[2]: *** [drivers/net/ucc_geth.o] Error 1
Signed-off-by: Subrata Modak subr...@linux.vnet.ibm.com
--- linux-2.6.30-rc8/drivers/net/ucc_geth.c.orig 2009-06-10
11:58:39.0 -0500
+++ linux-2.6.30-rc8/drivers/net/ucc_geth.c 2009-06-10 22:28:13.0
-0500
@@ -3595,6 +3595,8 @@ static const struct net_device_ops ucc_g
static int ucc_geth_probe(struct of_device* ofdev, const struct of_device_id
*match)
{
+ struct device_node *mdio;
+ const phandle *ph;
struct device *device = ofdev-dev;
struct device_node *np = ofdev-node;
struct net_device *dev = NULL;
Ah, this might not be the right fix then. I'll look.
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: 2.6.30-rc6: Problem with an SSD disk on Freescale PowerPC mpc8315e-rdb, works fine on x86
On Jun 17, 2009, at 11:07 AM, Leon Woestenberg wrote: Hello Kumar, all, On Mon, Jun 8, 2009 at 4:59 PM, Leon Woestenbergleon.woestenb...@gmail.com wrote: using 2.6.30-rc6, I get the following problems when I read from a SSD disk, connected to the 3.0 Gb SATA controller of the MPC8315E SoC rev 1.0 running Linux 2.6.30-rc6. Result on a first batch of bisects. I decided to go with the kernel releases rather than git-bisect (still too scary for me). All kernel releases 2.6.25 through -30 kernel gave the same error. 2.6.25 crashed on it, whereas 2.6.26+ recovered after each dd run. The BSP 2.6.24.3-rt3 kernel did not give the error. So on my todo is diff between 2.6.25 and .2.6.24.3-rt3 from the BSP. Does kernel.org 2.6.24 work ok? - k ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [BUILD FAILURE 02/04] Next June 04:PPC64 randconfig [drivers/usb/host/ohci-hcd.o]
On Wed, Jun 17, 2009 at 6:53 AM, Subrata Modaksubr...@linux.vnet.ibm.com wrote: On Mon, 2009-06-15 at 12:21 +0530, Subrata Modak wrote: On Fri, 2009-06-12 at 15:05 +0530, Subrata Modak wrote: On Tue, 2009-06-09 at 17:38 -0700, David Brownell wrote: On Friday 05 June 2009, Subrata Modak wrote: Correct, it fixes the issue. However, since few changes might have gone to the Kconfig, the patch does not apply cleanly. Below is the patch, just a retake of the earlier one, but on the latest code. And it got mangled a bit along the way. Plus, the original one goofed up Kconfig dependency displays ... both issues fixed in this version, against current mainline GIT. If someone can verify all four PPC/OF/OHCI configs build on on PPC64, I'm OK with it. - Dave Dave, Sorry for being late. The patch fixes the issue on the latest git for PPC64. Infact, the whole drivers/usb/host/ builds just fine: linux-2.6 # make drivers/usb/host/ CHK include/linux/version.h CHK include/linux/utsrelease.h SYMLINK include/asm - include/asm-powerpc CALL scripts/checksyscalls.sh CC drivers/usb/host/ohci-hcd.o CC drivers/usb/host/pci-quirks.o CC drivers/usb/host/uhci-hcd.o LD drivers/usb/host/built-in.o CC [M] drivers/usb/host/isp116x-hcd.o CC [M] drivers/usb/host/u132-hcd.o You can check in the patch now. Dave, Have you checked in this patch ? Or, does it require some more modification/updates from somebody´s side ? Dave, Would you consider checking in this patch ? Hold off please; give me a couple of hours to investigate. g. -- Grant Likely, B.Sc., P.Eng. Secret Lab Technologies Ltd. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [RFC PATCH] fsldma: Add DMA_SLAVE support
On Wed, Jun 17, 2009 at 10:17:54AM -0700, Dan Williams wrote:
Ira Snyder wrote:
Using EXPORT_SYMBOL would defeat the purpose of conforming to the
dmaengine api which should allow other subsystems to generically
discover an fsldma resource.
Any driver would still use dma_request_channel(), etc. to get access to
a DMA channel. AFAICT, DMA_SLAVE is intended for doing something
completely hardware-specific with the DMA controller.
Yes. Specifically DMA_SLAVE operations imply a pre-established context
with a 3rd device (the other 2 devices being system memory and the dma
channel), as compared to plain memcpy. The assumption is that a dma
device with this capability may not be shared with other requesters
until the context is torn down.
[..]
What I've implemented is this: (sorry about the poor drawing)
scatterlist fsl_dma_hw_addr
+++---+
| DATA | | DEST1 |
| DATA | + +---+
| DATA | |
| DATA | | +---+
| DATA | +--- | DEST2 |
| DATA |+---+
++
.
.
.
Of course, the reverse works as well. You can copy from a list of
hardware address/length pairs to a scatterlist.
So, using my implementation of the DMA_SLAVE feature, you can take a big
chunk of data (which is organized into a scatterlist) and DMA it
directly to a set of hardware addresses, all in a single, unbroken
transaction.
Could the same effect be achieved by calling -prep_slave_sg multiple
times? Once you need to add dma-driver specific helper routines you are
effectively extending the dmaengine interface in an fsldma specific
fashion. Can we reduce this to just the existing primitives? If it
turns out that this is untenable can we extend dmaengine to make this a
generic capability? My preference is the former.
I can do something similar by calling device_prep_dma_memcpy() lots of
times. Once for each page in the scatterlist.
This has the advantage of not changing the DMAEngine API.
This has the disadvantage of not being a single transaction. The DMA
controller will get an interrupt after each memcpy() transaction, clean
up descriptors, etc.
It also has the disadvantage of not being able to change the
controller-specific features I'm using: external start. This feature
lets the 3rd device control the DMA controller. It looks like the
atmel-mci driver has a similar feature. The DMAEngine API has no way to
expose this type of feature except through DMA_SLAVE.
If it is just the 3 helper routines that are the issue with this patch,
I have no problem dropping them and letting each user re-create them
themselves.
I've inlined the driver for the FPGA programmer below. I don't think it
is appropriate to push into mainline, since it will only work for our
board, and nothing else.
If we find that we need to extend the dmaengine interface we will need
an in-tree user. In my opinion, as long as it passes the Voyager test
[1] then I do not see why it should be barred from upstream.
Yep, I understand the Voyager test. I just didn't think it would be
useful to anyone to try and push it upstream, especially since the
hardware is in-house only.
The virtio-over-pci patches I've posted a while back may benefit from
this as well. They look more likely to go upstream. I've been really
busy and haven't had time to work on them recently, but Grant Likely is
working on them at the moment.
[..]
He also used platform data to get the register addresses. I'm unaware of
a way to put arbitrary platform data into the OF tree used on PowerPC.
Anybody else on ppc-dev know if this is possible??
I didn't want to force other users to implement the allocation routines
for the struct fsl_dma_hw_addr themselves, so I provided routines to do
so.
It depends on how many users of this feature there ends up being,
pushing this into each driver that needs it would not be too horrible
especially if it just the three straightforward routines
(fsl_dma_slave_append, fsl_dma_slave_free, and fsl_dma_slave_alloc).
Right, the routines are very simple. I wouldn't have any problem leaving
it up to users.
So, the three options in order of preference are:
1/ arrange to call -prep multiple times to handle each dma address
This doesn't seem quite right. I'd end up doing something like:
struct fsl_dma_slave slave;
slave.external_start = true;
slave.address = 0xf0003000;
slave.length = 4096;
chan-private = slave;
for_each_sg(sgl, sg, sg_len, i) {
device_prep_slave_sg(chan, sg, 1, DMA_TO_DEVICE, 0);
}
That pretty much defeats the purpose of the scatterlist argument,
doesn't it? Also, it is no better than just calling
device_prep_dma_memcpy() lots of times. You don't get a single DMA
transaction.
It is trivial to implement a dma_addr_t to dma_addr_t memcpy function.
Here is a version I've used in the
Re: [BUILD FAILURE 02/04] Next June 04:PPC64 randconfig [drivers/usb/host/ohci-hcd.o]
On Wed, Jun 17, 2009 at 12:15 PM, Grant Likelygrant.lik...@secretlab.ca wrote: On Wed, Jun 17, 2009 at 6:53 AM, Subrata Modaksubr...@linux.vnet.ibm.com wrote: On Mon, 2009-06-15 at 12:21 +0530, Subrata Modak wrote: On Fri, 2009-06-12 at 15:05 +0530, Subrata Modak wrote: On Tue, 2009-06-09 at 17:38 -0700, David Brownell wrote: On Friday 05 June 2009, Subrata Modak wrote: Correct, it fixes the issue. However, since few changes might have gone to the Kconfig, the patch does not apply cleanly. Below is the patch, just a retake of the earlier one, but on the latest code. And it got mangled a bit along the way. Plus, the original one goofed up Kconfig dependency displays ... both issues fixed in this version, against current mainline GIT. If someone can verify all four PPC/OF/OHCI configs build on on PPC64, I'm OK with it. - Dave Dave, Sorry for being late. The patch fixes the issue on the latest git for PPC64. Infact, the whole drivers/usb/host/ builds just fine: linux-2.6 # make drivers/usb/host/ CHK include/linux/version.h CHK include/linux/utsrelease.h SYMLINK include/asm - include/asm-powerpc CALL scripts/checksyscalls.sh CC drivers/usb/host/ohci-hcd.o CC drivers/usb/host/pci-quirks.o CC drivers/usb/host/uhci-hcd.o LD drivers/usb/host/built-in.o CC [M] drivers/usb/host/isp116x-hcd.o CC [M] drivers/usb/host/u132-hcd.o You can check in the patch now. Dave, Have you checked in this patch ? Or, does it require some more modification/updates from somebody´s side ? Dave, Would you consider checking in this patch ? Hold off please; give me a couple of hours to investigate. Never mind; I replied to the wrong email. Please ignore my comments. g. -- Grant Likely, B.Sc., P.Eng. Secret Lab Technologies Ltd. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] sdhci: Add support for hosts that are only capable of 1-bit transfers
On Sat, Jun 13, 2009 at 09:40:02AM -0600, Grant Likely wrote: On Thu, Jun 11, 2009 at 2:15 PM, Anton Vorontsovavoront...@ru.mvista.com wrote: Some hosts (hardware configurations, or particular SD/MMC slots) may not support 4-bit bus. For example, on MPC8569E-MDS boards we can switch between serial (1-bit only) and nibble (4-bit) modes, thought we have to disable more peripherals to work in 4-bit mode. Along with some small core changes, this patch modifies sdhci-of driver, so that now it looks for mode property in the device-tree. Signed-off-by: Anton Vorontsov avoront...@ru.mvista.com --- Pierre, I'm not sure if a quirk would be appropriate here. If so, I can redo the patch with FORCE_1_BIT_DATA quirk. Thanks, Documentation/powerpc/dts-bindings/fsl/esdhc.txt | 2 ++ drivers/mmc/host/sdhci-of.c | 7 +++ drivers/mmc/host/sdhci-pci.c | 1 + drivers/mmc/host/sdhci.c | 2 +- 4 files changed, 11 insertions(+), 1 deletions(-) diff --git a/Documentation/powerpc/dts-bindings/fsl/esdhc.txt b/Documentation/powerpc/dts-bindings/fsl/esdhc.txt index 5093ddf..298b865 100644 --- a/Documentation/powerpc/dts-bindings/fsl/esdhc.txt +++ b/Documentation/powerpc/dts-bindings/fsl/esdhc.txt @@ -10,6 +10,8 @@ Required properties: - interrupts : should contain eSDHC interrupt. - interrupt-parent : interrupt source phandle. - clock-frequency : specifies eSDHC base clock frequency. + - mode : specifies eSDHC mode, valid values are: 1-bit and 4-bit. + If mode is unspecified, then 4-bit mode is assumed. In light of Pierre's comment that 4-bit is mandatory and this is a deviation, perhaps it would be better to define an empty property to indicate that only 1-bit transfers work. Maybe something along the lines of sdhc-1-bit-only? Yeah, since it turned up to be a quirk, we'd better use a named property. (I think that by convention we should use commas for controller-specific properties, i.e. sdhci,property.) Thanks! -- Anton Vorontsov email: cbouatmai...@gmail.com irc://irc.freenode.net/bd2 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH v2] sdhci: Add support for hosts that are only capable of 1-bit transfers
Some hosts (hardware configurations, or particular SD/MMC slots) may
not support 4-bit bus. For example, on MPC8569E-MDS boards we can
switch between serial (1-bit only) and nibble (4-bit) modes, thought
we have to disable more peripherals to work in 4-bit mode.
Along with some small core changes, this patch modifies sdhci-of
driver, so that now it looks for sdhci,1-bit-only property in the
device-tree, and if specified we enable a proper quirk.
Signed-off-by: Anton Vorontsov avoront...@ru.mvista.com
---
Pierre,
As promised, here is a version with a quirk.
Also incorporated suggestions by Grant Likely.
Thanks,
Documentation/powerpc/dts-bindings/fsl/esdhc.txt |2 ++
drivers/mmc/host/sdhci-of.c |3 +++
drivers/mmc/host/sdhci.c |5 -
drivers/mmc/host/sdhci.h |2 ++
4 files changed, 11 insertions(+), 1 deletions(-)
diff --git a/Documentation/powerpc/dts-bindings/fsl/esdhc.txt
b/Documentation/powerpc/dts-bindings/fsl/esdhc.txt
index 5093ddf..3ed3797 100644
--- a/Documentation/powerpc/dts-bindings/fsl/esdhc.txt
+++ b/Documentation/powerpc/dts-bindings/fsl/esdhc.txt
@@ -10,6 +10,8 @@ Required properties:
- interrupts : should contain eSDHC interrupt.
- interrupt-parent : interrupt source phandle.
- clock-frequency : specifies eSDHC base clock frequency.
+ - sdhci,1-bit-only : (optional) specifies that a controller can
+only handle 1-bit data transfers.
Example:
diff --git a/drivers/mmc/host/sdhci-of.c b/drivers/mmc/host/sdhci-of.c
index 09cc597..dd65f84 100644
--- a/drivers/mmc/host/sdhci-of.c
+++ b/drivers/mmc/host/sdhci-of.c
@@ -244,6 +244,9 @@ static int __devinit sdhci_of_probe(struct of_device *ofdev,
host-ops = sdhci_of_data-ops;
}
+ if (of_get_property(np, sdhci,1-bit-only, NULL))
+ host-quirks |= SDHCI_QUIRK_FORCE_1_BIT_DATA;
+
clk = of_get_property(np, clock-frequency, size);
if (clk size == sizeof(*clk) *clk)
of_host-clock = *clk;
diff --git a/drivers/mmc/host/sdhci.c b/drivers/mmc/host/sdhci.c
index 9234be2..f28f94a 100644
--- a/drivers/mmc/host/sdhci.c
+++ b/drivers/mmc/host/sdhci.c
@@ -1721,7 +1721,10 @@ int sdhci_add_host(struct sdhci_host *host)
mmc-ops = sdhci_ops;
mmc-f_min = host-max_clk / 256;
mmc-f_max = host-max_clk;
- mmc-caps = MMC_CAP_4_BIT_DATA | MMC_CAP_SDIO_IRQ;
+ mmc-caps = MMC_CAP_SDIO_IRQ;
+
+ if (!(host-quirks SDHCI_QUIRK_FORCE_1_BIT_DATA))
+ mmc-caps |= MMC_CAP_4_BIT_DATA;
if (caps SDHCI_CAN_DO_HISPD)
mmc-caps |= MMC_CAP_SD_HIGHSPEED;
diff --git a/drivers/mmc/host/sdhci.h b/drivers/mmc/host/sdhci.h
index 65c6f99..834f877 100644
--- a/drivers/mmc/host/sdhci.h
+++ b/drivers/mmc/host/sdhci.h
@@ -226,6 +226,8 @@ struct sdhci_host {
#define SDHCI_QUIRK_RESTORE_IRQS_AFTER_RESET (119)
/* Controller has to be forced to use block size of 2048 bytes */
#define SDHCI_QUIRK_FORCE_BLK_SZ_2048 (120)
+/* Controller can only handle 1-bit data transfers */
+#define SDHCI_QUIRK_FORCE_1_BIT_DATA (121)
int irq;/* Device IRQ */
void __iomem * ioaddr; /* Mapped address */
--
1.6.3.1
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH][Resend 2][BUILD FAILURE 04/04] Next June 04:PPC64 randconfig [drivers/net/ucc_geth.o]
On Wed, Jun 17, 2009 at 11:29 AM, Grant Likelygrant.lik...@secretlab.ca wrote:
On Wed, Jun 17, 2009 at 7:34 AM, Stephen Rothwells...@canb.auug.org.au
wrote:
On Wed, 17 Jun 2009 23:23:41 +1000 Stephen Rothwell s...@canb.auug.org.au
wrote:
Hi Kumar,
On Wed, 17 Jun 2009 08:07:47 -0500 Kumar Gala ga...@kernel.crashing.org
wrote:
I'm confused by the proposed fix as we already have *mdio *ph
defined in this function:
Which tree are you looking at? Linus' tree, and linux-next, do not have
those local variables ...
Hmmm, commit 0b9da337dca972e7a4144e298ec3adb8f244d4a4 (net: Rework
ucc_geth driver to use of_mdio infrastructure) removed the locals along
with their usages, then commit 047584ce94108012288554a5f84585d792cc7f8f
(net/ucc_geth: Add SGMII support for UEC GETH driver) added more uses
without adding the variables back.
Here is the patch again:
From: Subrata Modak subr...@linux.vnet.ibm.com
Subject: [PATCH] Fix build error in ucc_geth.c
Fix the following build error:
drivers/net/ucc_geth.c: In function bucc_geth_probeb:
drivers/net/ucc_geth.c:3822: error: 'ph' undeclared (first use in this
function)
drivers/net/ucc_geth.c:3822: error: (Each undeclared identifier is reported
only once
drivers/net/ucc_geth.c:3822: error: for each function it appears in.)
drivers/net/ucc_geth.c:3832: error: 'mdio' undeclared (first use in this
function)
make[2]: *** [drivers/net/ucc_geth.o] Error 1
Signed-off-by: Subrata Modak subr...@linux.vnet.ibm.com
--- linux-2.6.30-rc8/drivers/net/ucc_geth.c.orig 2009-06-10
11:58:39.0 -0500
+++ linux-2.6.30-rc8/drivers/net/ucc_geth.c 2009-06-10
22:28:13.0 -0500
@@ -3595,6 +3595,8 @@ static const struct net_device_ops ucc_g
static int ucc_geth_probe(struct of_device* ofdev, const struct
of_device_id *match)
{
+ struct device_node *mdio;
+ const phandle *ph;
struct device *device = ofdev-dev;
struct device_node *np = ofdev-node;
struct net_device *dev = NULL;
Ah, this might not be the right fix then. I'll look.
Yeah, this is not the right fix. The SGMII change doesn't mesh well
with the of_mdio changes and needed some rewriting. I'm about to post
a patch (compile tested only) which should make things happy.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v2] sdhci: Add support for hosts that are only capable of 1-bit transfers
On Wed, Jun 17, 2009 at 2:14 PM, Anton
Vorontsovavoront...@ru.mvista.com wrote:
Some hosts (hardware configurations, or particular SD/MMC slots) may
not support 4-bit bus. For example, on MPC8569E-MDS boards we can
switch between serial (1-bit only) and nibble (4-bit) modes, thought
we have to disable more peripherals to work in 4-bit mode.
Along with some small core changes, this patch modifies sdhci-of
driver, so that now it looks for sdhci,1-bit-only property in the
device-tree, and if specified we enable a proper quirk.
Signed-off-by: Anton Vorontsov avoront...@ru.mvista.com
Looks good to me.
Acked-by: Grant Likely grant.lik...@secretlab.ca
g.
---
Pierre,
As promised, here is a version with a quirk.
Also incorporated suggestions by Grant Likely.
Thanks,
Documentation/powerpc/dts-bindings/fsl/esdhc.txt | 2 ++
drivers/mmc/host/sdhci-of.c | 3 +++
drivers/mmc/host/sdhci.c | 5 -
drivers/mmc/host/sdhci.h | 2 ++
4 files changed, 11 insertions(+), 1 deletions(-)
diff --git a/Documentation/powerpc/dts-bindings/fsl/esdhc.txt
b/Documentation/powerpc/dts-bindings/fsl/esdhc.txt
index 5093ddf..3ed3797 100644
--- a/Documentation/powerpc/dts-bindings/fsl/esdhc.txt
+++ b/Documentation/powerpc/dts-bindings/fsl/esdhc.txt
@@ -10,6 +10,8 @@ Required properties:
- interrupts : should contain eSDHC interrupt.
- interrupt-parent : interrupt source phandle.
- clock-frequency : specifies eSDHC base clock frequency.
+ - sdhci,1-bit-only : (optional) specifies that a controller can
+ only handle 1-bit data transfers.
Example:
diff --git a/drivers/mmc/host/sdhci-of.c b/drivers/mmc/host/sdhci-of.c
index 09cc597..dd65f84 100644
--- a/drivers/mmc/host/sdhci-of.c
+++ b/drivers/mmc/host/sdhci-of.c
@@ -244,6 +244,9 @@ static int __devinit sdhci_of_probe(struct of_device
*ofdev,
host-ops = sdhci_of_data-ops;
}
+ if (of_get_property(np, sdhci,1-bit-only, NULL))
+ host-quirks |= SDHCI_QUIRK_FORCE_1_BIT_DATA;
+
clk = of_get_property(np, clock-frequency, size);
if (clk size == sizeof(*clk) *clk)
of_host-clock = *clk;
diff --git a/drivers/mmc/host/sdhci.c b/drivers/mmc/host/sdhci.c
index 9234be2..f28f94a 100644
--- a/drivers/mmc/host/sdhci.c
+++ b/drivers/mmc/host/sdhci.c
@@ -1721,7 +1721,10 @@ int sdhci_add_host(struct sdhci_host *host)
mmc-ops = sdhci_ops;
mmc-f_min = host-max_clk / 256;
mmc-f_max = host-max_clk;
- mmc-caps = MMC_CAP_4_BIT_DATA | MMC_CAP_SDIO_IRQ;
+ mmc-caps = MMC_CAP_SDIO_IRQ;
+
+ if (!(host-quirks SDHCI_QUIRK_FORCE_1_BIT_DATA))
+ mmc-caps |= MMC_CAP_4_BIT_DATA;
if (caps SDHCI_CAN_DO_HISPD)
mmc-caps |= MMC_CAP_SD_HIGHSPEED;
diff --git a/drivers/mmc/host/sdhci.h b/drivers/mmc/host/sdhci.h
index 65c6f99..834f877 100644
--- a/drivers/mmc/host/sdhci.h
+++ b/drivers/mmc/host/sdhci.h
@@ -226,6 +226,8 @@ struct sdhci_host {
#define SDHCI_QUIRK_RESTORE_IRQS_AFTER_RESET (119)
/* Controller has to be forced to use block size of 2048 bytes */
#define SDHCI_QUIRK_FORCE_BLK_SZ_2048 (120)
+/* Controller can only handle 1-bit data transfers */
+#define SDHCI_QUIRK_FORCE_1_BIT_DATA (121)
int irq; /* Device IRQ */
void __iomem * ioaddr; /* Mapped address */
--
1.6.3.1
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH 1/2] Revert net/ucc_geth: Add SGMII support for UEC GETH driver
From: Grant Likely grant.lik...@secretlab.ca
This reverts commit 047584ce94108012288554a5f84585d792cc7f8f.
This patch meshes badly with net: Rework ucc_geth driver to use
of_mdio infrastructure (0b9da337dca972e7a4144e298ec3adb8f244d4a4).
Since most of the patch needs to be reworked, it is clearer to revert
the patch and then apply the corrected version
Signed-off-by: Grant Likely grant.lik...@secretlab.ca
---
arch/powerpc/include/asm/qe.h |2 -
drivers/net/ucc_geth.c| 79 +
drivers/net/ucc_geth.h| 28 +--
3 files changed, 2 insertions(+), 107 deletions(-)
diff --git a/arch/powerpc/include/asm/qe.h b/arch/powerpc/include/asm/qe.h
index 157c5ca..e0faf33 100644
--- a/arch/powerpc/include/asm/qe.h
+++ b/arch/powerpc/include/asm/qe.h
@@ -675,8 +675,6 @@ struct ucc_slow_pram {
#define UCC_GETH_UPSMR_RMM 0x1000
#define UCC_GETH_UPSMR_CAM 0x0400
#define UCC_GETH_UPSMR_BRO 0x0200
-#define UCC_GETH_UPSMR_SMM 0x0080
-#define UCC_GETH_UPSMR_SGMM0x0020
/* UCC Transmit On Demand Register (UTODR) */
#define UCC_SLOW_TOD 0x8000
diff --git a/drivers/net/ucc_geth.c b/drivers/net/ucc_geth.c
index e2f2e91..5118993 100644
--- a/drivers/net/ucc_geth.c
+++ b/drivers/net/ucc_geth.c
@@ -1,5 +1,5 @@
/*
- * Copyright (C) 2006-2009 Freescale Semicondutor, Inc. All rights reserved.
+ * Copyright (C) 2006-2007 Freescale Semicondutor, Inc. All rights reserved.
*
* Author: Shlomi Gridish grid...@freescale.com
*Li Yang le...@freescale.com
@@ -65,8 +65,6 @@
static DEFINE_SPINLOCK(ugeth_lock);
-static void uec_configure_serdes(struct net_device *dev);
-
static struct {
u32 msg_enable;
} debug = { -1 };
@@ -1412,9 +1410,6 @@ static int adjust_enet_interface(struct ucc_geth_private
*ugeth)
(ugeth-phy_interface == PHY_INTERFACE_MODE_RTBI)) {
upsmr |= UCC_GETH_UPSMR_TBIM;
}
- if ((ugeth-phy_interface == PHY_INTERFACE_MODE_SGMII))
- upsmr |= UCC_GETH_UPSMR_SGMM;
-
out_be32(uf_regs-upsmr, upsmr);
/* Disable autonegotiation in tbi mode, because by default it
@@ -1559,9 +1554,6 @@ static int init_phy(struct net_device *dev)
return -ENODEV;
}
- if (priv-phy_interface == PHY_INTERFACE_MODE_SGMII)
- uec_configure_serdes(dev);
-
phydev-supported = (ADVERTISED_10baseT_Half |
ADVERTISED_10baseT_Full |
ADVERTISED_100baseT_Half |
@@ -1577,41 +1569,7 @@ static int init_phy(struct net_device *dev)
return 0;
}
-/* Initialize TBI PHY interface for communicating with the
- * SERDES lynx PHY on the chip. We communicate with this PHY
- * through the MDIO bus on each controller, treating it as a
- * normal PHY at the address found in the UTBIPA register. We assume
- * that the UTBIPA register is valid. Either the MDIO bus code will set
- * it to a value that doesn't conflict with other PHYs on the bus, or the
- * value doesn't matter, as there are no other PHYs on the bus.
- */
-static void uec_configure_serdes(struct net_device *dev)
-{
- struct ucc_geth_private *ugeth = netdev_priv(dev);
-
- if (!ugeth-tbiphy) {
- printk(KERN_WARNING SGMII mode requires that the device
- tree specify a tbi-handle\n);
- return;
- }
-
- /*
-* If the link is already up, we must already be ok, and don't need to
-* configure and reset the TBI-SerDes link. Maybe U-Boot configured
-* everything for us? Resetting it takes the link down and requires
-* several seconds for it to come back.
-*/
- if (phy_read(ugeth-tbiphy, ENET_TBI_MII_SR) TBISR_LSTATUS)
- return;
-
- /* Single clk mode, mii mode off(for serdes communication) */
- phy_write(ugeth-tbiphy, ENET_TBI_MII_ANA, TBIANA_SETTINGS);
- phy_write(ugeth-tbiphy, ENET_TBI_MII_TBICON, TBICON_CLK_SELECT);
-
- phy_write(ugeth-tbiphy, ENET_TBI_MII_CR, TBICR_SETTINGS);
-
-}
static int ugeth_graceful_stop_tx(struct ucc_geth_private *ugeth)
{
@@ -3573,8 +3531,6 @@ static phy_interface_t to_phy_interface(const char
*phy_connection_type)
return PHY_INTERFACE_MODE_RGMII_RXID;
if (strcasecmp(phy_connection_type, rtbi) == 0)
return PHY_INTERFACE_MODE_RTBI;
- if (strcasecmp(phy_connection_type, sgmii) == 0)
- return PHY_INTERFACE_MODE_SGMII;
return PHY_INTERFACE_MODE_MII;
}
@@ -3619,7 +3575,6 @@ static int ucc_geth_probe(struct of_device* ofdev, const
struct of_device_id *ma
PHY_INTERFACE_MODE_RMII, PHY_INTERFACE_MODE_RGMII,
PHY_INTERFACE_MODE_GMII, PHY_INTERFACE_MODE_RGMII,
PHY_INTERFACE_MODE_TBI, PHY_INTERFACE_MODE_RTBI,
- PHY_INTERFACE_MODE_SGMII,
};
ugeth_vdbg(%s: IN,
[PATCH 0/2] Revert and reimplement Add SGMII support to UCC GETH
Here is a fix for the build failure discovered during the 2.6.31 merge window on ucc_geth.c. I decided to revert and reapply a fixed version of the patch to make the new version easier to review and bisect if I got the fixup wrong. I've compile tested both patches, but I do not have hardware to run test. Haiying, please confirm that I haven't horribly trashed your hard work with my changes. For anyone interested, I've also pushed these patches out to the -next-net branch of my git tree: The following changes since commit 65795efbd380a832ae508b04dba8f8e53f0b84d9: Linus Torvalds (1): Merge branch 'next-i2c' of git://aeryn.fluff.org.uk/bjdooks/linux are available in the git repository at: git://git.secretlab.ca/git/linux-2.6 next-net Grant Likely (1): Revert net/ucc_geth: Add SGMII support for UEC GETH driver Haiying Wang (1): net/ucc_geth: Add SGMII support for UCC GETH driver drivers/net/ucc_geth.c | 113 +++ drivers/net/ucc_geth.h |2 +- 2 files changed, 47 insertions(+), 68 deletions(-) -- Grant Likely, B.Sc. P.Eng. Secret Lab Technologies Ltd. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH 1/2] Revert net/ucc_geth: Add SGMII support for UEC GETH driver
From: Grant Likely grant.lik...@secretlab.ca
This reverts commit 047584ce94108012288554a5f84585d792cc7f8f.
This patch meshes badly with net: Rework ucc_geth driver to use
of_mdio infrastructure (0b9da337dca972e7a4144e298ec3adb8f244d4a4).
Since most of the patch needs to be reworked, it is clearer to revert
the patch and then apply the corrected version
Signed-off-by: Grant Likely grant.lik...@secretlab.ca
---
arch/powerpc/include/asm/qe.h |2 -
drivers/net/ucc_geth.c| 79 +
drivers/net/ucc_geth.h| 28 +--
3 files changed, 2 insertions(+), 107 deletions(-)
diff --git a/arch/powerpc/include/asm/qe.h b/arch/powerpc/include/asm/qe.h
index 157c5ca..e0faf33 100644
--- a/arch/powerpc/include/asm/qe.h
+++ b/arch/powerpc/include/asm/qe.h
@@ -675,8 +675,6 @@ struct ucc_slow_pram {
#define UCC_GETH_UPSMR_RMM 0x1000
#define UCC_GETH_UPSMR_CAM 0x0400
#define UCC_GETH_UPSMR_BRO 0x0200
-#define UCC_GETH_UPSMR_SMM 0x0080
-#define UCC_GETH_UPSMR_SGMM0x0020
/* UCC Transmit On Demand Register (UTODR) */
#define UCC_SLOW_TOD 0x8000
diff --git a/drivers/net/ucc_geth.c b/drivers/net/ucc_geth.c
index e2f2e91..5118993 100644
--- a/drivers/net/ucc_geth.c
+++ b/drivers/net/ucc_geth.c
@@ -1,5 +1,5 @@
/*
- * Copyright (C) 2006-2009 Freescale Semicondutor, Inc. All rights reserved.
+ * Copyright (C) 2006-2007 Freescale Semicondutor, Inc. All rights reserved.
*
* Author: Shlomi Gridish grid...@freescale.com
*Li Yang le...@freescale.com
@@ -65,8 +65,6 @@
static DEFINE_SPINLOCK(ugeth_lock);
-static void uec_configure_serdes(struct net_device *dev);
-
static struct {
u32 msg_enable;
} debug = { -1 };
@@ -1412,9 +1410,6 @@ static int adjust_enet_interface(struct ucc_geth_private
*ugeth)
(ugeth-phy_interface == PHY_INTERFACE_MODE_RTBI)) {
upsmr |= UCC_GETH_UPSMR_TBIM;
}
- if ((ugeth-phy_interface == PHY_INTERFACE_MODE_SGMII))
- upsmr |= UCC_GETH_UPSMR_SGMM;
-
out_be32(uf_regs-upsmr, upsmr);
/* Disable autonegotiation in tbi mode, because by default it
@@ -1559,9 +1554,6 @@ static int init_phy(struct net_device *dev)
return -ENODEV;
}
- if (priv-phy_interface == PHY_INTERFACE_MODE_SGMII)
- uec_configure_serdes(dev);
-
phydev-supported = (ADVERTISED_10baseT_Half |
ADVERTISED_10baseT_Full |
ADVERTISED_100baseT_Half |
@@ -1577,41 +1569,7 @@ static int init_phy(struct net_device *dev)
return 0;
}
-/* Initialize TBI PHY interface for communicating with the
- * SERDES lynx PHY on the chip. We communicate with this PHY
- * through the MDIO bus on each controller, treating it as a
- * normal PHY at the address found in the UTBIPA register. We assume
- * that the UTBIPA register is valid. Either the MDIO bus code will set
- * it to a value that doesn't conflict with other PHYs on the bus, or the
- * value doesn't matter, as there are no other PHYs on the bus.
- */
-static void uec_configure_serdes(struct net_device *dev)
-{
- struct ucc_geth_private *ugeth = netdev_priv(dev);
-
- if (!ugeth-tbiphy) {
- printk(KERN_WARNING SGMII mode requires that the device
- tree specify a tbi-handle\n);
- return;
- }
-
- /*
-* If the link is already up, we must already be ok, and don't need to
-* configure and reset the TBI-SerDes link. Maybe U-Boot configured
-* everything for us? Resetting it takes the link down and requires
-* several seconds for it to come back.
-*/
- if (phy_read(ugeth-tbiphy, ENET_TBI_MII_SR) TBISR_LSTATUS)
- return;
-
- /* Single clk mode, mii mode off(for serdes communication) */
- phy_write(ugeth-tbiphy, ENET_TBI_MII_ANA, TBIANA_SETTINGS);
- phy_write(ugeth-tbiphy, ENET_TBI_MII_TBICON, TBICON_CLK_SELECT);
-
- phy_write(ugeth-tbiphy, ENET_TBI_MII_CR, TBICR_SETTINGS);
-
-}
static int ugeth_graceful_stop_tx(struct ucc_geth_private *ugeth)
{
@@ -3573,8 +3531,6 @@ static phy_interface_t to_phy_interface(const char
*phy_connection_type)
return PHY_INTERFACE_MODE_RGMII_RXID;
if (strcasecmp(phy_connection_type, rtbi) == 0)
return PHY_INTERFACE_MODE_RTBI;
- if (strcasecmp(phy_connection_type, sgmii) == 0)
- return PHY_INTERFACE_MODE_SGMII;
return PHY_INTERFACE_MODE_MII;
}
@@ -3619,7 +3575,6 @@ static int ucc_geth_probe(struct of_device* ofdev, const
struct of_device_id *ma
PHY_INTERFACE_MODE_RMII, PHY_INTERFACE_MODE_RGMII,
PHY_INTERFACE_MODE_GMII, PHY_INTERFACE_MODE_RGMII,
PHY_INTERFACE_MODE_TBI, PHY_INTERFACE_MODE_RTBI,
- PHY_INTERFACE_MODE_SGMII,
};
ugeth_vdbg(%s: IN,
[PATCH 2/2] net/ucc_geth: Add SGMII support for UCC GETH driver
From: Haiying Wang haiying.w...@freescale.com
-- derived from reverted commit 047584ce94108012288554a5f84585d792cc7f8f
-- reworked by Grant Likely to play nice with commit:
net: Rework ucc_geth driver to use of_mdio infrastructure
(0b9da337dca972e7a4144e298ec3adb8f244d4a4)
Signed-off-by: Haiying Wang haiying.w...@freescale.com
Signed-off-by: David S. Miller da...@davemloft.net
Signed-off-by: Grant Likely grant.lik...@secretlab.ca
---
arch/powerpc/include/asm/qe.h |2 +
drivers/net/ucc_geth.c| 58 -
drivers/net/ucc_geth.h| 28 +++-
3 files changed, 86 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/include/asm/qe.h b/arch/powerpc/include/asm/qe.h
index e0faf33..157c5ca 100644
--- a/arch/powerpc/include/asm/qe.h
+++ b/arch/powerpc/include/asm/qe.h
@@ -675,6 +675,8 @@ struct ucc_slow_pram {
#define UCC_GETH_UPSMR_RMM 0x1000
#define UCC_GETH_UPSMR_CAM 0x0400
#define UCC_GETH_UPSMR_BRO 0x0200
+#define UCC_GETH_UPSMR_SMM 0x0080
+#define UCC_GETH_UPSMR_SGMM0x0020
/* UCC Transmit On Demand Register (UTODR) */
#define UCC_SLOW_TOD 0x8000
diff --git a/drivers/net/ucc_geth.c b/drivers/net/ucc_geth.c
index 5118993..40c6eba 100644
--- a/drivers/net/ucc_geth.c
+++ b/drivers/net/ucc_geth.c
@@ -1,5 +1,5 @@
/*
- * Copyright (C) 2006-2007 Freescale Semicondutor, Inc. All rights reserved.
+ * Copyright (C) 2006-2009 Freescale Semicondutor, Inc. All rights reserved.
*
* Author: Shlomi Gridish grid...@freescale.com
*Li Yang le...@freescale.com
@@ -1410,6 +1410,9 @@ static int adjust_enet_interface(struct ucc_geth_private
*ugeth)
(ugeth-phy_interface == PHY_INTERFACE_MODE_RTBI)) {
upsmr |= UCC_GETH_UPSMR_TBIM;
}
+ if ((ugeth-phy_interface == PHY_INTERFACE_MODE_SGMII))
+ upsmr |= UCC_GETH_UPSMR_SGMM;
+
out_be32(uf_regs-upsmr, upsmr);
/* Disable autonegotiation in tbi mode, because by default it
@@ -1531,6 +1534,49 @@ static void adjust_link(struct net_device *dev)
spin_unlock_irqrestore(ugeth-lock, flags);
}
+/* Initialize TBI PHY interface for communicating with the
+ * SERDES lynx PHY on the chip. We communicate with this PHY
+ * through the MDIO bus on each controller, treating it as a
+ * normal PHY at the address found in the UTBIPA register. We assume
+ * that the UTBIPA register is valid. Either the MDIO bus code will set
+ * it to a value that doesn't conflict with other PHYs on the bus, or the
+ * value doesn't matter, as there are no other PHYs on the bus.
+ */
+static void uec_configure_serdes(struct net_device *dev)
+{
+ struct ucc_geth_private *ugeth = netdev_priv(dev);
+ struct ucc_geth_info *ug_info = ugeth-ug_info;
+ struct phy_device *tbiphy;
+
+ if (!ug_info-tbi_node) {
+ dev_warn(dev-dev, SGMII mode requires that the device
+ tree specify a tbi-handle\n);
+ return;
+ }
+
+ tbiphy = of_phy_find_device(ug_info-tbi_node);
+ if (!tbiphy) {
+ dev_err(dev-dev, error: Could not get TBI device\n);
+ return;
+ }
+
+ /*
+* If the link is already up, we must already be ok, and don't need to
+* configure and reset the TBI-SerDes link. Maybe U-Boot configured
+* everything for us? Resetting it takes the link down and requires
+* several seconds for it to come back.
+*/
+ if (phy_read(tbiphy, ENET_TBI_MII_SR) TBISR_LSTATUS)
+ return;
+
+ /* Single clk mode, mii mode off(for serdes communication) */
+ phy_write(tbiphy, ENET_TBI_MII_ANA, TBIANA_SETTINGS);
+
+ phy_write(tbiphy, ENET_TBI_MII_TBICON, TBICON_CLK_SELECT);
+
+ phy_write(tbiphy, ENET_TBI_MII_CR, TBICR_SETTINGS);
+}
+
/* Configure the PHY for dev.
* returns 0 if success. -1 if failure
*/
@@ -1554,6 +1600,9 @@ static int init_phy(struct net_device *dev)
return -ENODEV;
}
+ if (priv-phy_interface == PHY_INTERFACE_MODE_SGMII)
+ uec_configure_serdes(dev);
+
phydev-supported = (ADVERTISED_10baseT_Half |
ADVERTISED_10baseT_Full |
ADVERTISED_100baseT_Half |
@@ -3531,6 +3580,8 @@ static phy_interface_t to_phy_interface(const char
*phy_connection_type)
return PHY_INTERFACE_MODE_RGMII_RXID;
if (strcasecmp(phy_connection_type, rtbi) == 0)
return PHY_INTERFACE_MODE_RTBI;
+ if (strcasecmp(phy_connection_type, sgmii) == 0)
+ return PHY_INTERFACE_MODE_SGMII;
return PHY_INTERFACE_MODE_MII;
}
@@ -3575,6 +3626,7 @@ static int ucc_geth_probe(struct of_device* ofdev, const
struct of_device_id *ma
PHY_INTERFACE_MODE_RMII, PHY_INTERFACE_MODE_RGMII,
PHY_INTERFACE_MODE_GMII,
[PATCH 0/2] Revert and reimplement Add SGMII support to UCC GETH
(REPOST; I messed up an email address first time around and apparently my posting got rejected. If you've already received this message, then I apologize for the noise) Here is a fix for the build failure discovered during the 2.6.31 merge window on ucc_geth.c. I decided to revert and reapply a fixed version of the patch to make the new version easier to review and bisect if I got the fixup wrong. I've compile tested both patches, but I do not have hardware to run test. Haiying, please confirm that I haven't horribly trashed your hard work with my changes. For anyone interested, I've also pushed these patches out to the -next-net branch of my git tree: The following changes since commit 65795efbd380a832ae508b04dba8f8e53f0b84d9: Linus Torvalds (1): Merge branch 'next-i2c' of git://aeryn.fluff.org.uk/bjdooks/linux are available in the git repository at: git://git.secretlab.ca/git/linux-2.6 next-net Grant Likely (1): Revert net/ucc_geth: Add SGMII support for UEC GETH driver Haiying Wang (1): net/ucc_geth: Add SGMII support for UCC GETH driver drivers/net/ucc_geth.c | 113 +++ drivers/net/ucc_geth.h |2 +- 2 files changed, 47 insertions(+), 68 deletions(-) -- Grant Likely, B.Sc. P.Eng. Secret Lab Technologies Ltd. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH 1/2] Revert net/ucc_geth: Add SGMII support for UEC GETH driver
From: Grant Likely grant.lik...@secretlab.ca
This reverts commit 047584ce94108012288554a5f84585d792cc7f8f.
This patch meshes badly with net: Rework ucc_geth driver to use
of_mdio infrastructure (0b9da337dca972e7a4144e298ec3adb8f244d4a4).
Since most of the patch needs to be reworked, it is clearer to revert
the patch and then apply the corrected version
Signed-off-by: Grant Likely grant.lik...@secretlab.ca
---
arch/powerpc/include/asm/qe.h |2 -
drivers/net/ucc_geth.c| 79 +
drivers/net/ucc_geth.h| 28 +--
3 files changed, 2 insertions(+), 107 deletions(-)
diff --git a/arch/powerpc/include/asm/qe.h b/arch/powerpc/include/asm/qe.h
index 157c5ca..e0faf33 100644
--- a/arch/powerpc/include/asm/qe.h
+++ b/arch/powerpc/include/asm/qe.h
@@ -675,8 +675,6 @@ struct ucc_slow_pram {
#define UCC_GETH_UPSMR_RMM 0x1000
#define UCC_GETH_UPSMR_CAM 0x0400
#define UCC_GETH_UPSMR_BRO 0x0200
-#define UCC_GETH_UPSMR_SMM 0x0080
-#define UCC_GETH_UPSMR_SGMM0x0020
/* UCC Transmit On Demand Register (UTODR) */
#define UCC_SLOW_TOD 0x8000
diff --git a/drivers/net/ucc_geth.c b/drivers/net/ucc_geth.c
index e2f2e91..5118993 100644
--- a/drivers/net/ucc_geth.c
+++ b/drivers/net/ucc_geth.c
@@ -1,5 +1,5 @@
/*
- * Copyright (C) 2006-2009 Freescale Semicondutor, Inc. All rights reserved.
+ * Copyright (C) 2006-2007 Freescale Semicondutor, Inc. All rights reserved.
*
* Author: Shlomi Gridish grid...@freescale.com
*Li Yang le...@freescale.com
@@ -65,8 +65,6 @@
static DEFINE_SPINLOCK(ugeth_lock);
-static void uec_configure_serdes(struct net_device *dev);
-
static struct {
u32 msg_enable;
} debug = { -1 };
@@ -1412,9 +1410,6 @@ static int adjust_enet_interface(struct ucc_geth_private
*ugeth)
(ugeth-phy_interface == PHY_INTERFACE_MODE_RTBI)) {
upsmr |= UCC_GETH_UPSMR_TBIM;
}
- if ((ugeth-phy_interface == PHY_INTERFACE_MODE_SGMII))
- upsmr |= UCC_GETH_UPSMR_SGMM;
-
out_be32(uf_regs-upsmr, upsmr);
/* Disable autonegotiation in tbi mode, because by default it
@@ -1559,9 +1554,6 @@ static int init_phy(struct net_device *dev)
return -ENODEV;
}
- if (priv-phy_interface == PHY_INTERFACE_MODE_SGMII)
- uec_configure_serdes(dev);
-
phydev-supported = (ADVERTISED_10baseT_Half |
ADVERTISED_10baseT_Full |
ADVERTISED_100baseT_Half |
@@ -1577,41 +1569,7 @@ static int init_phy(struct net_device *dev)
return 0;
}
-/* Initialize TBI PHY interface for communicating with the
- * SERDES lynx PHY on the chip. We communicate with this PHY
- * through the MDIO bus on each controller, treating it as a
- * normal PHY at the address found in the UTBIPA register. We assume
- * that the UTBIPA register is valid. Either the MDIO bus code will set
- * it to a value that doesn't conflict with other PHYs on the bus, or the
- * value doesn't matter, as there are no other PHYs on the bus.
- */
-static void uec_configure_serdes(struct net_device *dev)
-{
- struct ucc_geth_private *ugeth = netdev_priv(dev);
-
- if (!ugeth-tbiphy) {
- printk(KERN_WARNING SGMII mode requires that the device
- tree specify a tbi-handle\n);
- return;
- }
-
- /*
-* If the link is already up, we must already be ok, and don't need to
-* configure and reset the TBI-SerDes link. Maybe U-Boot configured
-* everything for us? Resetting it takes the link down and requires
-* several seconds for it to come back.
-*/
- if (phy_read(ugeth-tbiphy, ENET_TBI_MII_SR) TBISR_LSTATUS)
- return;
-
- /* Single clk mode, mii mode off(for serdes communication) */
- phy_write(ugeth-tbiphy, ENET_TBI_MII_ANA, TBIANA_SETTINGS);
- phy_write(ugeth-tbiphy, ENET_TBI_MII_TBICON, TBICON_CLK_SELECT);
-
- phy_write(ugeth-tbiphy, ENET_TBI_MII_CR, TBICR_SETTINGS);
-
-}
static int ugeth_graceful_stop_tx(struct ucc_geth_private *ugeth)
{
@@ -3573,8 +3531,6 @@ static phy_interface_t to_phy_interface(const char
*phy_connection_type)
return PHY_INTERFACE_MODE_RGMII_RXID;
if (strcasecmp(phy_connection_type, rtbi) == 0)
return PHY_INTERFACE_MODE_RTBI;
- if (strcasecmp(phy_connection_type, sgmii) == 0)
- return PHY_INTERFACE_MODE_SGMII;
return PHY_INTERFACE_MODE_MII;
}
@@ -3619,7 +3575,6 @@ static int ucc_geth_probe(struct of_device* ofdev, const
struct of_device_id *ma
PHY_INTERFACE_MODE_RMII, PHY_INTERFACE_MODE_RGMII,
PHY_INTERFACE_MODE_GMII, PHY_INTERFACE_MODE_RGMII,
PHY_INTERFACE_MODE_TBI, PHY_INTERFACE_MODE_RTBI,
- PHY_INTERFACE_MODE_SGMII,
};
ugeth_vdbg(%s: IN,
[PATCH 2/2] net/ucc_geth: Add SGMII support for UCC GETH driver
From: Haiying Wang haiying.w...@freescale.com
-- derived from reverted commit 047584ce94108012288554a5f84585d792cc7f8f
-- reworked by Grant Likely to play nice with commit:
net: Rework ucc_geth driver to use of_mdio infrastructure
(0b9da337dca972e7a4144e298ec3adb8f244d4a4)
Signed-off-by: Haiying Wang haiying.w...@freescale.com
Signed-off-by: David S. Miller da...@davemloft.net
Signed-off-by: Grant Likely grant.lik...@secretlab.ca
---
arch/powerpc/include/asm/qe.h |2 +
drivers/net/ucc_geth.c| 58 -
drivers/net/ucc_geth.h| 28 +++-
3 files changed, 86 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/include/asm/qe.h b/arch/powerpc/include/asm/qe.h
index e0faf33..157c5ca 100644
--- a/arch/powerpc/include/asm/qe.h
+++ b/arch/powerpc/include/asm/qe.h
@@ -675,6 +675,8 @@ struct ucc_slow_pram {
#define UCC_GETH_UPSMR_RMM 0x1000
#define UCC_GETH_UPSMR_CAM 0x0400
#define UCC_GETH_UPSMR_BRO 0x0200
+#define UCC_GETH_UPSMR_SMM 0x0080
+#define UCC_GETH_UPSMR_SGMM0x0020
/* UCC Transmit On Demand Register (UTODR) */
#define UCC_SLOW_TOD 0x8000
diff --git a/drivers/net/ucc_geth.c b/drivers/net/ucc_geth.c
index 5118993..40c6eba 100644
--- a/drivers/net/ucc_geth.c
+++ b/drivers/net/ucc_geth.c
@@ -1,5 +1,5 @@
/*
- * Copyright (C) 2006-2007 Freescale Semicondutor, Inc. All rights reserved.
+ * Copyright (C) 2006-2009 Freescale Semicondutor, Inc. All rights reserved.
*
* Author: Shlomi Gridish grid...@freescale.com
*Li Yang le...@freescale.com
@@ -1410,6 +1410,9 @@ static int adjust_enet_interface(struct ucc_geth_private
*ugeth)
(ugeth-phy_interface == PHY_INTERFACE_MODE_RTBI)) {
upsmr |= UCC_GETH_UPSMR_TBIM;
}
+ if ((ugeth-phy_interface == PHY_INTERFACE_MODE_SGMII))
+ upsmr |= UCC_GETH_UPSMR_SGMM;
+
out_be32(uf_regs-upsmr, upsmr);
/* Disable autonegotiation in tbi mode, because by default it
@@ -1531,6 +1534,49 @@ static void adjust_link(struct net_device *dev)
spin_unlock_irqrestore(ugeth-lock, flags);
}
+/* Initialize TBI PHY interface for communicating with the
+ * SERDES lynx PHY on the chip. We communicate with this PHY
+ * through the MDIO bus on each controller, treating it as a
+ * normal PHY at the address found in the UTBIPA register. We assume
+ * that the UTBIPA register is valid. Either the MDIO bus code will set
+ * it to a value that doesn't conflict with other PHYs on the bus, or the
+ * value doesn't matter, as there are no other PHYs on the bus.
+ */
+static void uec_configure_serdes(struct net_device *dev)
+{
+ struct ucc_geth_private *ugeth = netdev_priv(dev);
+ struct ucc_geth_info *ug_info = ugeth-ug_info;
+ struct phy_device *tbiphy;
+
+ if (!ug_info-tbi_node) {
+ dev_warn(dev-dev, SGMII mode requires that the device
+ tree specify a tbi-handle\n);
+ return;
+ }
+
+ tbiphy = of_phy_find_device(ug_info-tbi_node);
+ if (!tbiphy) {
+ dev_err(dev-dev, error: Could not get TBI device\n);
+ return;
+ }
+
+ /*
+* If the link is already up, we must already be ok, and don't need to
+* configure and reset the TBI-SerDes link. Maybe U-Boot configured
+* everything for us? Resetting it takes the link down and requires
+* several seconds for it to come back.
+*/
+ if (phy_read(tbiphy, ENET_TBI_MII_SR) TBISR_LSTATUS)
+ return;
+
+ /* Single clk mode, mii mode off(for serdes communication) */
+ phy_write(tbiphy, ENET_TBI_MII_ANA, TBIANA_SETTINGS);
+
+ phy_write(tbiphy, ENET_TBI_MII_TBICON, TBICON_CLK_SELECT);
+
+ phy_write(tbiphy, ENET_TBI_MII_CR, TBICR_SETTINGS);
+}
+
/* Configure the PHY for dev.
* returns 0 if success. -1 if failure
*/
@@ -1554,6 +1600,9 @@ static int init_phy(struct net_device *dev)
return -ENODEV;
}
+ if (priv-phy_interface == PHY_INTERFACE_MODE_SGMII)
+ uec_configure_serdes(dev);
+
phydev-supported = (ADVERTISED_10baseT_Half |
ADVERTISED_10baseT_Full |
ADVERTISED_100baseT_Half |
@@ -3531,6 +3580,8 @@ static phy_interface_t to_phy_interface(const char
*phy_connection_type)
return PHY_INTERFACE_MODE_RGMII_RXID;
if (strcasecmp(phy_connection_type, rtbi) == 0)
return PHY_INTERFACE_MODE_RTBI;
+ if (strcasecmp(phy_connection_type, sgmii) == 0)
+ return PHY_INTERFACE_MODE_SGMII;
return PHY_INTERFACE_MODE_MII;
}
@@ -3575,6 +3626,7 @@ static int ucc_geth_probe(struct of_device* ofdev, const
struct of_device_id *ma
PHY_INTERFACE_MODE_RMII, PHY_INTERFACE_MODE_RGMII,
PHY_INTERFACE_MODE_GMII,
Re: [PATCH 1/6] perf_counter: powerpc: Enable use of software counters on 32-bit powerpc
Kumar Gala writes: On Jun 17, 2009, at 6:50 AM, Paul Mackerras wrote: +config PPC_HAVE_PMU_SUPPORT + bool what does this mean? At the moment it means that arch/powerpc/kernel/perf_counters.c works for at least some processors in the selected processor family. + +config PPC_PERF_CTRS + def_bool y + depends on PERF_COUNTERS PPC_HAVE_PMU_SUPPORT + help + This enables the powerpc-specific perf_counter back-end. Can we distinguish between the two different architected perf counters programming models to start with. Maybe something like: PPC_BOOK3S_PERF_CTRS and PPC_BOOK3E_PERF_CTRS (or PPC_SERVER_PERF_CTRS / PPC_EMB_PERF_CTRS) We can do that once we have code to support the Freescale embedded PMU and we know how much of arch/powerpc/kernel/perf_counters.c is or isn't useful there. We don't have to get to the final state in one patch. I'd rather put this patch in as-is and then see a patch series that adds the Freescale embedded PMU support and makes whatever Kconfig changes are necessary later. Paul. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 5/6] perf_counter: powerpc: Add processor back-end for MPC7450 family
Kumar Gala writes: This should be something like: obj64-$(CONFIG_PPC_PERF_CTRS)-$(PPC_BOOK3S_64) +obj32-$(CONFIG_PPC_PERF_CTRS) += mpc7450-pmu.o obj32-$(CONFIG_PPC_PERF_CTRS)-$(PPC_BOOK3S_32) Or use new Kconfig types as I suggested on patch 1/6 Feel free to send a patch making those changes along with adding the code to support the Freescale embedded PMU. :) Paul. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 1/6] perf_counter: powerpc: Enable use of software counters on 32-bit powerpc
Ingo Molnar writes: Note, i've created a new branch, tip:perfcounters/powerpc, so we can keep these things separate and Ben can pull them too. I see there was some review feedback - do you want to send a v2 version perhaps? Kumar's comments seemed to me to be wanting changes to accommodate code that doesn't exist yet, so I think those changes should be done later when that code exists and we know exactly what is needed. So the current patches are fine as-is IMO. Paul. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: ethernet packet drop
Couple of points to debug, 1. Do you see any pause frames getting generated by Router device and not honoured by Spirent test equipment? 2. Checkout the MPC8248' load if you have console connected to it, using #top command. Parav --- On Wed, 6/17/09, Mehul Chadha mehul...@gmail.com wrote: From: Mehul Chadha mehul...@gmail.com Subject: ethernet packet drop To: linuxppc-dev@lists.ozlabs.org Date: Wednesday, June 17, 2009, 8:23 PM Hello everyone, I am working on a project for router development. The basic specifications of the router are as follows: · Supports MPC8248 - 32-bit PowerQUICC II Communication Processor running at 400 MHz (Max) core frequency, 200 MHz (Max) CPM, and 100MHz (Max) external bus frequency. · 64-bit wide 256-MByte synchronous DRAM (soldered on-board), consisting of 4 no. devices of 8M x 16 x 4, residing on 60X bus (PBI mode), controlled by SDRAM machine. · 256 MB NAND Flash, organized as 256M x 8, buffered from 60X bus, controlled by UPM machine. · Upto 8MB NOR Flash, Boot sector (bottom) type, organized as 8M x 8, buffered from 60X bus, controlled by GPCM machine. · Linux Kernel version: linux-2.6.16.40 While testing my router with the spirent test equipment, the 2 ethernet ports of the router are connected to the testing equipment. I send data from the testing equipment through the ethernet port , the router forwards the packet to the other ethernet port again connected to the testing equipment. When I increase the throughput to 70 mbps the testing equipment starts showing packet losses which should not happen as its a 10/100 mbps link. I am not able to understand where would the problem lie. Pls if someone can list the different issues due to which this problem is occurring, it will be really helpful Regards,Mehul -Inline Attachment Follows- ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 0/2] Revert and reimplement Add SGMII support to UCC GETH
From: Grant Likely grant.lik...@secretlab.ca Date: Wed, 17 Jun 2009 17:15:58 -0600 (REPOST; I messed up an email address first time around and apparently my posting got rejected. If you've already received this message, then I apologize for the noise) Here is a fix for the build failure discovered during the 2.6.31 merge window on ucc_geth.c. I decided to revert and reapply a fixed version of the patch to make the new version easier to review and bisect if I got the fixup wrong. I've compile tested both patches, but I do not have hardware to run test. Haiying, please confirm that I haven't horribly trashed your hard work with my changes. I've applied these to net-next-2.6, thanks! ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH v3] powerpc/5200: add general purpose timer API for the MPC5200
From: Grant Likely grant.lik...@secretlab.ca
This patch adds an interface for controlling the timer function of the
MPC5200 GPT devices.
Signed-off-by: Grant Likely grant.lik...@secretlab.ca
---
arch/powerpc/include/asm/mpc52xx.h|7 ++
arch/powerpc/platforms/52xx/mpc52xx_gpt.c | 133 +++--
2 files changed, 130 insertions(+), 10 deletions(-)
diff --git a/arch/powerpc/include/asm/mpc52xx.h
b/arch/powerpc/include/asm/mpc52xx.h
index 1b4f697..6716850 100644
--- a/arch/powerpc/include/asm/mpc52xx.h
+++ b/arch/powerpc/include/asm/mpc52xx.h
@@ -276,6 +276,13 @@ extern int mpc52xx_set_psc_clkdiv(int psc_id, int clkdiv);
extern unsigned int mpc52xx_get_xtal_freq(struct device_node *node);
extern void mpc52xx_restart(char *cmd);
+/* mpc52xx_gpt.c */
+struct mpc52xx_gpt_priv;
+extern struct mpc52xx_gpt_priv *mpc52xx_gpt_from_irq(int irq);
+extern int mpc52xx_gpt_start_timer(struct mpc52xx_gpt_priv *gpt, int period,
+int continuous);
+extern void mpc52xx_gpt_stop_timer(struct mpc52xx_gpt_priv *gpt);
+
/* mpc52xx_pic.c */
extern void mpc52xx_init_irq(void);
extern unsigned int mpc52xx_get_irq(void);
diff --git a/arch/powerpc/platforms/52xx/mpc52xx_gpt.c
b/arch/powerpc/platforms/52xx/mpc52xx_gpt.c
index bfbcd41..2c3fa13 100644
--- a/arch/powerpc/platforms/52xx/mpc52xx_gpt.c
+++ b/arch/powerpc/platforms/52xx/mpc52xx_gpt.c
@@ -46,13 +46,17 @@
* the output mode. This driver does not change the output mode setting.
*/
+#include linux/device.h
#include linux/irq.h
#include linux/interrupt.h
#include linux/io.h
+#include linux/list.h
+#include linux/mutex.h
#include linux/of.h
#include linux/of_platform.h
#include linux/of_gpio.h
#include linux/kernel.h
+#include asm/div64.h
#include asm/mpc52xx.h
MODULE_DESCRIPTION(Freescale MPC52xx gpt driver);
@@ -68,16 +72,21 @@ MODULE_LICENSE(GPL);
* @irqhost: Pointer to irq_host instance; used when IRQ mode is supported
*/
struct mpc52xx_gpt_priv {
+ struct list_head list; /* List of all GPT devices */
struct device *dev;
struct mpc52xx_gpt __iomem *regs;
spinlock_t lock;
struct irq_host *irqhost;
+ u32 ipb_freq;
#if defined(CONFIG_GPIOLIB)
struct of_gpio_chip of_gc;
#endif
};
+LIST_HEAD(mpc52xx_gpt_list);
+DEFINE_MUTEX(mpc52xx_gpt_list_mutex);
+
#define MPC52xx_GPT_MODE_MS_MASK (0x07)
#define MPC52xx_GPT_MODE_MS_IC (0x01)
#define MPC52xx_GPT_MODE_MS_OC (0x02)
@@ -88,6 +97,9 @@ struct mpc52xx_gpt_priv {
#define MPC52xx_GPT_MODE_GPIO_OUT_LOW (0x20)
#define MPC52xx_GPT_MODE_GPIO_OUT_HIGH (0x30)
+#define MPC52xx_GPT_MODE_COUNTER_ENABLE(0x1000)
+#define MPC52xx_GPT_MODE_CONTINUOUS(0x0400)
+#define MPC52xx_GPT_MODE_OPEN_DRAIN(0x0200)
#define MPC52xx_GPT_MODE_IRQ_EN(0x0100)
#define MPC52xx_GPT_MODE_ICT_MASK (0x03)
@@ -190,7 +202,7 @@ static int mpc52xx_gpt_irq_xlate(struct irq_host *h, struct
device_node *ct,
dev_dbg(gpt-dev, %s: flags=%i\n, __func__, intspec[0]);
- if ((intsize 1) || (intspec[0] 1) || (intspec[0] 3)) {
+ if ((intsize 1) || (intspec[0] 3)) {
dev_err(gpt-dev, bad irq specifier in %s\n, ct-full_name);
return -EINVAL;
}
@@ -211,13 +223,11 @@ mpc52xx_gpt_irq_setup(struct mpc52xx_gpt_priv *gpt,
struct device_node *node)
{
int cascade_virq;
unsigned long flags;
-
- /* Only setup cascaded IRQ if device tree claims the GPT is
-* an interrupt controller */
- if (!of_find_property(node, interrupt-controller, NULL))
- return;
+ u32 mode;
cascade_virq = irq_of_parse_and_map(node, 0);
+ if (!cascade_virq)
+ return;
gpt-irqhost = irq_alloc_host(node, IRQ_HOST_MAP_LINEAR, 1,
mpc52xx_gpt_irq_ops, -1);
@@ -227,14 +237,16 @@ mpc52xx_gpt_irq_setup(struct mpc52xx_gpt_priv *gpt,
struct device_node *node)
}
gpt-irqhost-host_data = gpt;
-
set_irq_data(cascade_virq, gpt);
set_irq_chained_handler(cascade_virq, mpc52xx_gpt_irq_cascade);
- /* Set to Input Capture mode */
+ /* If the GPT is currently disabled, then change it to be in Input
+* Capture mode. If the mode is non-zero, then the pin could be
+* already in use for something. */
spin_lock_irqsave(gpt-lock, flags);
- clrsetbits_be32(gpt-regs-mode, MPC52xx_GPT_MODE_MS_MASK,
- MPC52xx_GPT_MODE_MS_IC);
+ mode = in_be32(gpt-regs-mode);
+ if ((mode MPC52xx_GPT_MODE_MS_MASK) == 0)
+ out_be32(gpt-regs-mode, mode | MPC52xx_GPT_MODE_MS_IC);
spin_unlock_irqrestore(gpt-lock, flags);
dev_dbg(gpt-dev, %s() complete. virq=%i\n, __func__, cascade_virq);
@@ -335,6 +347,102 @@ static void
mpc52xx_gpt_gpio_setup(struct mpc52xx_gpt_priv *p, struct device_node *np) { }
[PATCH v3] powerpc/5200: add LocalPlus bus FIFO device driver
From: Grant Likely grant.lik...@secretlab.ca
This is a driver for the LocalPlus bus FIFO device
Signed-off-by: Grant Likely grant.lik...@secretlab.ca
---
arch/powerpc/include/asm/mpc52xx.h| 36 ++
arch/powerpc/platforms/52xx/Kconfig |4
arch/powerpc/platforms/52xx/Makefile |1
arch/powerpc/platforms/52xx/mpc52xx_lpbfifo.c | 458 +
4 files changed, 499 insertions(+), 0 deletions(-)
create mode 100644 arch/powerpc/platforms/52xx/mpc52xx_lpbfifo.c
diff --git a/arch/powerpc/include/asm/mpc52xx.h
b/arch/powerpc/include/asm/mpc52xx.h
index 6716850..974fc8f 100644
--- a/arch/powerpc/include/asm/mpc52xx.h
+++ b/arch/powerpc/include/asm/mpc52xx.h
@@ -283,6 +283,42 @@ extern int mpc52xx_gpt_start_timer(struct mpc52xx_gpt_priv
*gpt, int period,
int continuous);
extern void mpc52xx_gpt_stop_timer(struct mpc52xx_gpt_priv *gpt);
+/* mpc52xx_lpbfifo.c */
+#define MPC52XX_LPBFIFO_FLAG_READ (0)
+#define MPC52XX_LPBFIFO_FLAG_WRITE (10)
+#define MPC52XX_LPBFIFO_FLAG_NO_INCREMENT (11)
+#define MPC52XX_LPBFIFO_FLAG_NO_DMA(12)
+#define MPC52XX_LPBFIFO_FLAG_POLL_DMA (13)
+
+struct mpc52xx_lpbfifo_request {
+ struct list_head list;
+
+ /* localplus bus address */
+ unsigned int cs;
+ size_t offset;
+
+ /* Memory address */
+ void *data;
+ phys_addr_t data_phys;
+
+ /* Details of transfer */
+ size_t size;
+ size_t pos; /* current position of transfer */
+ int flags;
+
+ /* What to do when finished */
+ void (*callback)(struct mpc52xx_lpbfifo_request *);
+
+ void *priv; /* Driver private data */
+
+ /* statistics */
+ int irq_count;
+ int irq_ticks;
+};
+
+extern int mpc52xx_lpbfifo_submit(struct mpc52xx_lpbfifo_request *req);
+extern void mpc52xx_lpbfifo_abort(struct mpc52xx_lpbfifo_request *req);
+
/* mpc52xx_pic.c */
extern void mpc52xx_init_irq(void);
extern unsigned int mpc52xx_get_irq(void);
diff --git a/arch/powerpc/platforms/52xx/Kconfig
b/arch/powerpc/platforms/52xx/Kconfig
index 8b8e956..d64783e 100644
--- a/arch/powerpc/platforms/52xx/Kconfig
+++ b/arch/powerpc/platforms/52xx/Kconfig
@@ -62,3 +62,7 @@ config PPC_MPC5200_GPIO
select GENERIC_GPIO
help
Enable gpiolib support for mpc5200 based boards
+
+config PPC_MPC5200_LPBFIFO
+ tristate MPC5200 LocalPlus bus FIFO driver
+ depends on PPC_MPC52xx
diff --git a/arch/powerpc/platforms/52xx/Makefile
b/arch/powerpc/platforms/52xx/Makefile
index bfd4f52..2bc8cd0 100644
--- a/arch/powerpc/platforms/52xx/Makefile
+++ b/arch/powerpc/platforms/52xx/Makefile
@@ -15,3 +15,4 @@ ifeq ($(CONFIG_PPC_LITE5200),y)
endif
obj-$(CONFIG_PPC_MPC5200_GPIO) += mpc52xx_gpio.o
+obj-$(CONFIG_PPC_MPC5200_LPBFIFO) += mpc52xx_lpbfifo.o
diff --git a/arch/powerpc/platforms/52xx/mpc52xx_lpbfifo.c
b/arch/powerpc/platforms/52xx/mpc52xx_lpbfifo.c
new file mode 100644
index 000..fe32ae5
--- /dev/null
+++ b/arch/powerpc/platforms/52xx/mpc52xx_lpbfifo.c
@@ -0,0 +1,458 @@
+/*
+ * LocalPlus Bus FIFO driver for the Freescale MPC52xx.
+ *
+ * Copyright (C) 2009 Secret Lab Technologies Ltd.
+ *
+ * This file is released under the GPLv2
+ *
+ * Todo:
+ * - Add support for multiple requests to be queued.
+ */
+
+#include linux/interrupt.h
+#include linux/kernel.h
+#include linux/of.h
+#include linux/of_platform.h
+#include linux/spinlock.h
+#include asm/io.h
+#include asm/prom.h
+#include asm/mpc52xx.h
+#include asm/time.h
+
+#include sysdev/bestcomm/bestcomm.h
+#include sysdev/bestcomm/bestcomm_priv.h
+#include sysdev/bestcomm/gen_bd.h
+
+MODULE_AUTHOR(Grant Likely grant.lik...@secretlab.ca);
+MODULE_DESCRIPTION(MPC5200 LocalPlus FIFO device driver);
+MODULE_LICENSE(GPL);
+
+#define LPBFIFO_REG_PACKET_SIZE(0x00)
+#define LPBFIFO_REG_START_ADDRESS (0x04)
+#define LPBFIFO_REG_CONTROL(0x08)
+#define LPBFIFO_REG_ENABLE (0x0C)
+#define LPBFIFO_REG_BYTES_DONE_STATUS (0x14)
+#define LPBFIFO_REG_FIFO_DATA (0x40)
+#define LPBFIFO_REG_FIFO_STATUS(0x44)
+#define LPBFIFO_REG_FIFO_CONTROL (0x48)
+#define LPBFIFO_REG_FIFO_ALARM (0x4C)
+
+struct mpc52xx_lpbfifo {
+ struct device *dev;
+ phys_addr_t regs_phys;
+ void __iomem *regs;
+ int irq;
+ spinlock_t lock;
+
+ struct bcom_task *bcom_tx_task;
+ struct bcom_task *bcom_rx_task;
+ struct bcom_task *bcom_cur_task;
+
+ /* Current state data */
+ struct mpc52xx_lpbfifo_request *req;
+};
+
+/* The MPC5200 has only one fifo, so only need one instance structure */
+static struct mpc52xx_lpbfifo lpbfifo;
+
+/**
+ * mpc52xx_lpbfifo_kick - Trigger the next block of data to be transfered
+ */
+static void mpc52xx_lpbfifo_kick(struct mpc52xx_lpbfifo_request *req)
+{
+ size_t transfer_size = req-size - req-pos;
+
[PATCH v4] powerpc/5200: Add mpc5200-spi (non-PSC) device driver
From: Grant Likely grant.lik...@secretlab.ca
Adds support for the dedicated SPI device on the Freescale MPC5200(b)
SoC.
Signed-off-by: Grant Likely grant.lik...@secretlab.ca
---
Hi David,
It's been a while since I've posted this, but I believe I've addressed
all the outstanding comments against v3, and people are asking me for it.
The pre-message stuff is all gone and the error handling should be
better now.
BTW, the premessage stuff was to handle a platform I had where some of
the CS lines were controlled with a separate SPI transaction to the
same SPI controller. It almost looks like an SPI bridge. It requires
more thought before I try again.
Being a new driver, it would be nice to get it into 2.6.31, but
definitely not critical.
g.
drivers/spi/Kconfig |8 +
drivers/spi/Makefile|1
drivers/spi/mpc52xx_spi.c | 520 +++
include/linux/spi/mpc52xx_spi.h | 10 +
4 files changed, 539 insertions(+), 0 deletions(-)
create mode 100644 drivers/spi/mpc52xx_spi.c
create mode 100644 include/linux/spi/mpc52xx_spi.h
diff --git a/drivers/spi/Kconfig b/drivers/spi/Kconfig
index 83a185d..1994bcd 100644
--- a/drivers/spi/Kconfig
+++ b/drivers/spi/Kconfig
@@ -132,6 +132,14 @@ config SPI_LM70_LLP
which interfaces to an LM70 temperature sensor using
a parallel port.
+config SPI_MPC52xx
+ tristate Freescale MPC52xx SPI (non-PSC) controller support
+ depends on PPC_MPC52xx SPI
+ select SPI_MASTER_OF
+ help
+ This drivers supports the MPC52xx SPI controller in master SPI
+ mode.
+
config SPI_MPC52xx_PSC
tristate Freescale MPC52xx PSC SPI controller
depends on PPC_MPC52xx EXPERIMENTAL
diff --git a/drivers/spi/Makefile b/drivers/spi/Makefile
index 5d04519..8de32c7 100644
--- a/drivers/spi/Makefile
+++ b/drivers/spi/Makefile
@@ -24,6 +24,7 @@ obj-$(CONFIG_SPI_OMAP_UWIRE) += omap_uwire.o
obj-$(CONFIG_SPI_OMAP24XX) += omap2_mcspi.o
obj-$(CONFIG_SPI_ORION)+= orion_spi.o
obj-$(CONFIG_SPI_MPC52xx_PSC) += mpc52xx_psc_spi.o
+obj-$(CONFIG_SPI_MPC52xx) += mpc52xx_spi.o
obj-$(CONFIG_SPI_MPC83xx) += spi_mpc83xx.o
obj-$(CONFIG_SPI_S3C24XX_GPIO) += spi_s3c24xx_gpio.o
obj-$(CONFIG_SPI_S3C24XX) += spi_s3c24xx.o
diff --git a/drivers/spi/mpc52xx_spi.c b/drivers/spi/mpc52xx_spi.c
new file mode 100644
index 000..ef8379b
--- /dev/null
+++ b/drivers/spi/mpc52xx_spi.c
@@ -0,0 +1,520 @@
+/*
+ * MPC52xx SPI bus driver.
+ *
+ * Copyright (C) 2008 Secret Lab Technologies Ltd.
+ *
+ * This file is released under the GPLv2
+ *
+ * This is the driver for the MPC5200's dedicated SPI controller.
+ *
+ * Note: this driver does not support the MPC5200 PSC in SPI mode. For
+ * that driver see drivers/spi/mpc52xx_psc_spi.c
+ */
+
+#include linux/module.h
+#include linux/init.h
+#include linux/errno.h
+#include linux/of_platform.h
+#include linux/interrupt.h
+#include linux/delay.h
+#include linux/spi/spi.h
+#include linux/spi/mpc52xx_spi.h
+#include linux/of_spi.h
+#include linux/io.h
+#include asm/time.h
+#include asm/mpc52xx.h
+
+MODULE_AUTHOR(Grant Likely grant.lik...@secretlab.ca);
+MODULE_DESCRIPTION(MPC52xx SPI (non-PSC) Driver);
+MODULE_LICENSE(GPL);
+
+/* Register offsets */
+#define SPI_CTRL1 0x00
+#define SPI_CTRL1_SPIE (1 7)
+#define SPI_CTRL1_SPE (1 6)
+#define SPI_CTRL1_MSTR (1 4)
+#define SPI_CTRL1_CPOL (1 3)
+#define SPI_CTRL1_CPHA (1 2)
+#define SPI_CTRL1_SSOE (1 1)
+#define SPI_CTRL1_LSBFE(1 0)
+
+#define SPI_CTRL2 0x01
+#define SPI_BRR0x04
+
+#define SPI_STATUS 0x05
+#define SPI_STATUS_SPIF(1 7)
+#define SPI_STATUS_WCOL(1 6)
+#define SPI_STATUS_MODF(1 4)
+
+#define SPI_DATA 0x09
+#define SPI_PORTDATA 0x0d
+#define SPI_DATADIR0x10
+
+/* FSM state return values */
+#define FSM_STOP 0 /* Nothing more for the state machine to */
+ /* do. If something interesting happens */
+ /* then and IRQ will be received */
+#define FSM_POLL 1 /* need to poll for completion, an IRQ is */
+ /* not expected */
+#define FSM_CONTINUE 2 /* Keep iterating the state machine */
+
+/* Driver internal data */
+struct mpc52xx_spi {
+ struct spi_master *master;
+ u32 sysclk;
+ void __iomem *regs;
+ int irq0; /* MODF irq */
+ int irq1; /* SPIF irq */
+ int ipb_freq;
+
+ /* Statistics */
+ int msg_count;
+ int wcol_count;
+ int wcol_ticks;
+ u32 wcol_tx_timestamp;
+ int modf_count;
+ int byte_count;
+
+ struct list_head queue; /* queue of pending messages */
+ spinlock_t lock;
+ struct work_struct
[PATCH] powerpc/mm: Make k(un)map_atomic out of line
Those functions are way too big to be inline, besides, kmap_atomic()
wants to call debug_kmap_atomic() which isn't exported for modules
and causes module link failures.
Signed-off-by: Benjamin Herrenschmidt b...@kernel.crashing.org
---
arch/powerpc/include/asm/highmem.h | 55 +--
arch/powerpc/mm/Makefile |1
arch/powerpc/mm/highmem.c | 75 +
3 files changed, 80 insertions(+), 51 deletions(-)
--- linux-work.orig/arch/powerpc/include/asm/highmem.h 2009-06-18
11:34:42.0 +1000
+++ linux-work/arch/powerpc/include/asm/highmem.h 2009-06-18
11:34:45.0 +1000
@@ -62,6 +62,9 @@ extern pte_t *pkmap_page_table;
extern void *kmap_high(struct page *page);
extern void kunmap_high(struct page *page);
+extern void *kmap_atomic_prot(struct page *page, enum km_type type,
+ pgprot_t prot);
+extern void kunmap_atomic(void *kvaddr, enum km_type type);
static inline void *kmap(struct page *page)
{
@@ -79,62 +82,11 @@ static inline void kunmap(struct page *p
kunmap_high(page);
}
-/*
- * The use of kmap_atomic/kunmap_atomic is discouraged - kmap/kunmap
- * gives a more generic (and caching) interface. But kmap_atomic can
- * be used in IRQ contexts, so in some (very limited) cases we need
- * it.
- */
-static inline void *kmap_atomic_prot(struct page *page, enum km_type type,
pgprot_t prot)
-{
- unsigned int idx;
- unsigned long vaddr;
-
- /* even !CONFIG_PREEMPT needs this, for in_atomic in do_page_fault */
- pagefault_disable();
- if (!PageHighMem(page))
- return page_address(page);
-
- debug_kmap_atomic(type);
- idx = type + KM_TYPE_NR*smp_processor_id();
- vaddr = __fix_to_virt(FIX_KMAP_BEGIN + idx);
-#ifdef CONFIG_DEBUG_HIGHMEM
- BUG_ON(!pte_none(*(kmap_pte-idx)));
-#endif
- __set_pte_at(init_mm, vaddr, kmap_pte-idx, mk_pte(page, prot), 1);
- local_flush_tlb_page(NULL, vaddr);
-
- return (void*) vaddr;
-}
-
static inline void *kmap_atomic(struct page *page, enum km_type type)
{
return kmap_atomic_prot(page, type, kmap_prot);
}
-static inline void kunmap_atomic(void *kvaddr, enum km_type type)
-{
-#ifdef CONFIG_DEBUG_HIGHMEM
- unsigned long vaddr = (unsigned long) kvaddr PAGE_MASK;
- enum fixed_addresses idx = type + KM_TYPE_NR*smp_processor_id();
-
- if (vaddr __fix_to_virt(FIX_KMAP_END)) {
- pagefault_enable();
- return;
- }
-
- BUG_ON(vaddr != __fix_to_virt(FIX_KMAP_BEGIN + idx));
-
- /*
-* force other mappings to Oops if they'll try to access
-* this pte without first remap it
-*/
- pte_clear(init_mm, vaddr, kmap_pte-idx);
- local_flush_tlb_page(NULL, vaddr);
-#endif
- pagefault_enable();
-}
-
static inline struct page *kmap_atomic_to_page(void *ptr)
{
unsigned long idx, vaddr = (unsigned long) ptr;
@@ -148,6 +100,7 @@ static inline struct page *kmap_atomic_t
return pte_page(*pte);
}
+
#define flush_cache_kmaps()flush_cache_all()
#endif /* __KERNEL__ */
Index: linux-work/arch/powerpc/mm/Makefile
===
--- linux-work.orig/arch/powerpc/mm/Makefile2009-06-18 11:34:42.0
+1000
+++ linux-work/arch/powerpc/mm/Makefile 2009-06-18 11:34:45.0 +1000
@@ -30,3 +30,4 @@ obj-$(CONFIG_PPC_MM_SLICES) += slice.o
obj-$(CONFIG_HUGETLB_PAGE) += hugetlbpage.o
obj-$(CONFIG_PPC_SUBPAGE_PROT) += subpage-prot.o
obj-$(CONFIG_NOT_COHERENT_CACHE) += dma-noncoherent.o
+obj-$(CONFIG_HIGHMEM) += highmem.o
Index: linux-work/arch/powerpc/mm/highmem.c
===
--- /dev/null 1970-01-01 00:00:00.0 +
+++ linux-work/arch/powerpc/mm/highmem.c2009-06-18 11:35:51.0
+1000
@@ -0,0 +1,75 @@
+/*
+ * highmem.c: virtual kernel memory mappings for high memory
+ *
+ * PowerPC version, stolen from the i386 version.
+ *
+ * Used in CONFIG_HIGHMEM systems for memory pages which
+ * are not addressable by direct kernel virtual addresses.
+ *
+ * Copyright (C) 1999 Gerhard Wichert, Siemens AG
+ * gerhard.wich...@pdb.siemens.de
+ *
+ *
+ * Redesigned the x86 32-bit VM architecture to deal with
+ * up to 16 Terrabyte physical memory. With current x86 CPUs
+ * we now support up to 64 Gigabytes physical RAM.
+ *
+ * Copyright (C) 1999 Ingo Molnar mi...@redhat.com
+ *
+ * Reworked for PowerPC by various contributors. Moved from
+ * highmem.h by Benjamin Herrenschmidt (c) 2009 IBM Corp.
+ */
+
+
+/*
+ * The use of kmap_atomic/kunmap_atomic is discouraged - kmap/kunmap
+ * gives a more generic (and caching) interface. But kmap_atomic can
+ * be used in IRQ contexts, so in some (very limited) cases we need
+ * it.
+ */
+void *kmap_atomic_prot(struct page *page, enum km_type type,
[PATCH] powerpc: Add irqtrace support for 32-bit powerpc (v2)
Based on initial work from: Dale Farnsworth d...@farnsworth.org Add the low level irq tracing hooks for 32-bit powerpc needed to enable full lockdep functionality. The approach taken to deal with the code in entry_32.S is that we don't trace all the transitions of MSR:EE when we just turn it off to peek at TI_FLAGS without races. Only when we are calling into C code or returning from exceptions with a state that have changed from what lockdep thinks. There's a little bugger though: If we take an exception that keeps interrupts enabled (such as an alignment exception) while interrupts are enabled, we will call trace_hardirqs_on() on the way back spurriously. Not a big deal, but to get rid of it would require remembering in pt_regs that the exception was one of the type that kept interrupts enabled which we don't know at this stage. (Well, we could test all cases for regs-trap but that sucks too much). Signed-off-by: Benjamin Herrenschmidt b...@kernel.crashing.org --- This one fixes a bug, trace_hardirqs_on was too late in the restore: code path and would clobber things. This boots fine now on a PowerBook. arch/powerpc/Kconfig |1 arch/powerpc/include/asm/hw_irq.h | 20 ++--- arch/powerpc/kernel/entry_32.S| 127 -- arch/powerpc/kernel/setup_32.c|2 arch/powerpc/kernel/udbg.c|1 5 files changed, 136 insertions(+), 15 deletions(-) --- linux-work.orig/arch/powerpc/Kconfig2009-06-18 13:21:29.0 +1000 +++ linux-work/arch/powerpc/Kconfig 2009-06-18 13:21:39.0 +1000 @@ -62,7 +62,6 @@ config HAVE_LATENCYTOP_SUPPORT config TRACE_IRQFLAGS_SUPPORT bool - depends on PPC64 default y config LOCKDEP_SUPPORT Index: linux-work/arch/powerpc/kernel/entry_32.S === --- linux-work.orig/arch/powerpc/kernel/entry_32.S 2009-06-18 13:21:29.0 +1000 +++ linux-work/arch/powerpc/kernel/entry_32.S 2009-06-18 13:36:41.0 +1000 @@ -191,11 +191,49 @@ transfer_to_handler_cont: mflrr9 lwz r11,0(r9) /* virtual address of handler */ lwz r9,4(r9)/* where to go when done */ +#ifdef CONFIG_TRACE_IRQFLAGS + lis r12,reenable_...@h + ori r12,r12,reenable_...@l + mtspr SPRN_SRR0,r12 + mtspr SPRN_SRR1,r10 + SYNC + RFI +reenable_mmu: /* re-enable mmu so we can */ + mfmsr r10 + lwz r12,_MSR(r1) + xor r10,r10,r12 + andi. r10,r10,MSR_EE /* Did EE change? */ + beq 1f + + /* Save handler and return address into the 2 unused words +* of the STACK_FRAME_OVERHEAD (sneak sneak sneak). Everything +* else can be recovered from the pt_regs except r3 which for +* normal interrupts has been set to pt_regs and for syscalls +* is an argument, so we temporarily use ORIG_GPR3 to save it +*/ + stw r9,8(r1) + stw r11,12(r1) + stw r3,ORIG_GPR3(r1) + bl trace_hardirqs_off + lwz r0,GPR0(r1) + lwz r3,ORIG_GPR3(r1) + lwz r4,GPR4(r1) + lwz r5,GPR5(r1) + lwz r6,GPR6(r1) + lwz r7,GPR7(r1) + lwz r8,GPR8(r1) + lwz r9,8(r1) + lwz r11,12(r1) +1: mtctr r11 + mtlrr9 + bctr/* jump to handler */ +#else /* CONFIG_TRACE_IRQFLAGS */ mtspr SPRN_SRR0,r11 mtspr SPRN_SRR1,r10 mtlrr9 SYNC RFI /* jump to handler, enable MMU */ +#endif /* CONFIG_TRACE_IRQFLAGS */ #if defined (CONFIG_6xx) || defined(CONFIG_E500) 4: rlwinm r12,r12,0,~_TLF_NAPPING @@ -251,6 +289,31 @@ _GLOBAL(DoSyscall) #ifdef SHOW_SYSCALLS bl do_show_syscall #endif /* SHOW_SYSCALLS */ +#ifdef CONFIG_TRACE_IRQFLAGS + /* Return from syscalls can (and generally will) hard enable +* interrupts. You aren't supposed to call a syscall with +* interrupts disabled in the first place. However, to ensure +* that we get it right vs. lockdep if it happens, we force +* that hard enable here with appropriate tracing if we see +* that we have been called with interrupts off +*/ + mfmsr r11 + andi. r12,r11,MSR_EE + bne+1f + /* We came in with interrupts disabled, we enable them now */ + bl trace_hardirqs_on + mfmsr r11 + lwz r0,GPR0(r1) + lwz r3,GPR3(r1) + lwz r4,GPR4(r1) + ori r11,r11,MSR_EE + lwz r5,GPR5(r1) + lwz r6,GPR6(r1) + lwz r7,GPR7(r1) + lwz r8,GPR8(r1) + mtmsr r11 +1: +#endif /* CONFIG_TRACE_IRQFLAGS */ rlwinm r10,r1,0,0,(31-THREAD_SHIFT)/* current_thread_info() */ lwz
[PATCH 1/7] powerpc/pseries: Use pr_devel() in pseries LPAR HPTE routines
pr_debug() can now result in code being generated even when DEBUG
is not defined. That's not really desirable in some places.
In particular, pSeries_lpar_hpte_insert() goes from 185 instructions
to 77 instructions as a result of this patch. Luckily that code
isn't called very often ...
With CONFIG_DYNAMIC_DEBUG=y:
size before:
textdata bss dec hex filename
72841552 296913223ac platforms/pseries/lpar.o
size after:
textdata bss dec hex filename
58061096 29671981c1e platforms/pseries/lpar.o
Signed-off-by: Michael Ellerman mich...@ellerman.id.au
---
arch/powerpc/platforms/pseries/lpar.c | 18 +-
1 files changed, 9 insertions(+), 9 deletions(-)
diff --git a/arch/powerpc/platforms/pseries/lpar.c
b/arch/powerpc/platforms/pseries/lpar.c
index e3139fa..903eb9e 100644
--- a/arch/powerpc/platforms/pseries/lpar.c
+++ b/arch/powerpc/platforms/pseries/lpar.c
@@ -286,7 +286,7 @@ static long pSeries_lpar_hpte_insert(unsigned long
hpte_group,
unsigned long hpte_v, hpte_r;
if (!(vflags HPTE_V_BOLTED))
- pr_debug(hpte_insert(group=%lx, va=%016lx, pa=%016lx,
+ pr_devel(hpte_insert(group=%lx, va=%016lx, pa=%016lx,
rflags=%lx, vflags=%lx, psize=%d)\n,
hpte_group, va, pa, rflags, vflags, psize);
@@ -294,7 +294,7 @@ static long pSeries_lpar_hpte_insert(unsigned long
hpte_group,
hpte_r = hpte_encode_r(pa, psize) | rflags;
if (!(vflags HPTE_V_BOLTED))
- pr_debug( hpte_v=%016lx, hpte_r=%016lx\n, hpte_v, hpte_r);
+ pr_devel( hpte_v=%016lx, hpte_r=%016lx\n, hpte_v, hpte_r);
/* Now fill in the actual HPTE */
/* Set CEC cookie to 0 */
@@ -311,7 +311,7 @@ static long pSeries_lpar_hpte_insert(unsigned long
hpte_group,
lpar_rc = plpar_pte_enter(flags, hpte_group, hpte_v, hpte_r, slot);
if (unlikely(lpar_rc == H_PTEG_FULL)) {
if (!(vflags HPTE_V_BOLTED))
- pr_debug( full\n);
+ pr_devel( full\n);
return -1;
}
@@ -322,11 +322,11 @@ static long pSeries_lpar_hpte_insert(unsigned long
hpte_group,
*/
if (unlikely(lpar_rc != H_SUCCESS)) {
if (!(vflags HPTE_V_BOLTED))
- pr_debug( lpar err %lu\n, lpar_rc);
+ pr_devel( lpar err %lu\n, lpar_rc);
return -2;
}
if (!(vflags HPTE_V_BOLTED))
- pr_debug( - slot: %lu\n, slot 7);
+ pr_devel( - slot: %lu\n, slot 7);
/* Because of iSeries, we have to pass down the secondary
* bucket bit here as well
@@ -418,17 +418,17 @@ static long pSeries_lpar_hpte_updatepp(unsigned long slot,
want_v = hpte_encode_avpn(va, psize, ssize);
- pr_debug(update: avpnv=%016lx, hash=%016lx, f=%lx, psize: %d ...,
+ pr_devel(update: avpnv=%016lx, hash=%016lx, f=%lx, psize: %d ...,
want_v, slot, flags, psize);
lpar_rc = plpar_pte_protect(flags, slot, want_v);
if (lpar_rc == H_NOT_FOUND) {
- pr_debug(not found !\n);
+ pr_devel(not found !\n);
return -1;
}
- pr_debug(ok\n);
+ pr_devel(ok\n);
BUG_ON(lpar_rc != H_SUCCESS);
@@ -503,7 +503,7 @@ static void pSeries_lpar_hpte_invalidate(unsigned long
slot, unsigned long va,
unsigned long lpar_rc;
unsigned long dummy1, dummy2;
- pr_debug(inval : slot=%lx, va=%016lx, psize: %d, local: %d\n,
+ pr_devel(inval : slot=%lx, va=%016lx, psize: %d, local: %d\n,
slot, va, psize, local);
want_v = hpte_encode_avpn(va, psize, ssize);
--
1.6.2.1
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH 2/7] powerpc: Use pr_devel() in arch/powerpc/mm/gup.c
pr_debug() can now result in code being generated even when DEBUG
is not defined. That's not really desirable in some places.
With CONFIG_DYNAMIC_DEBUG=y:
size before:
textdata bss dec hex filename
3252 384 03636 e34 arch/powerpc/mm/gup.o
size after:
textdata bss dec hex filename
2576 96 02672 a70 arch/powerpc/mm/gup.o
Signed-off-by: Michael Ellerman mich...@ellerman.id.au
---
arch/powerpc/mm/gup.c | 10 +-
1 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/arch/powerpc/mm/gup.c b/arch/powerpc/mm/gup.c
index bc400c7..bc122a1 100644
--- a/arch/powerpc/mm/gup.c
+++ b/arch/powerpc/mm/gup.c
@@ -159,7 +159,7 @@ int get_user_pages_fast(unsigned long start, int nr_pages,
int write,
int psize;
#endif
- pr_debug(%s(%lx,%x,%s)\n, __func__, start, nr_pages, write ? write
: read);
+ pr_devel(%s(%lx,%x,%s)\n, __func__, start, nr_pages, write ? write
: read);
start = PAGE_MASK;
addr = start;
@@ -170,7 +170,7 @@ int get_user_pages_fast(unsigned long start, int nr_pages,
int write,
start, len)))
goto slow_irqon;
- pr_debug( aligned: %lx .. %lx\n, start, end);
+ pr_devel( aligned: %lx .. %lx\n, start, end);
#ifdef CONFIG_HUGETLB_PAGE
/* We bail out on slice boundary crossing when hugetlb is
@@ -234,7 +234,7 @@ int get_user_pages_fast(unsigned long start, int nr_pages,
int write,
do {
VM_BUG_ON(shift != mmu_psize_defs[get_slice_psize(mm,
a)].shift);
ptep = huge_pte_offset(mm, a);
- pr_debug( %016lx: huge ptep %p\n, a, ptep);
+ pr_devel( %016lx: huge ptep %p\n, a, ptep);
if (!ptep || !gup_huge_pte(ptep, hstate, a, end,
write, pages,
nr))
goto slow;
@@ -249,7 +249,7 @@ int get_user_pages_fast(unsigned long start, int nr_pages,
int write,
#ifdef CONFIG_PPC64
VM_BUG_ON(shift != mmu_psize_defs[get_slice_psize(mm,
addr)].shift);
#endif
- pr_debug( %016lx: normal pgd %p\n, addr,
+ pr_devel( %016lx: normal pgd %p\n, addr,
(void *)pgd_val(pgd));
next = pgd_addr_end(addr, end);
if (pgd_none(pgd))
@@ -269,7 +269,7 @@ int get_user_pages_fast(unsigned long start, int nr_pages,
int write,
slow:
local_irq_enable();
slow_irqon:
- pr_debug( slow path ! nr = %d\n, nr);
+ pr_devel( slow path ! nr = %d\n, nr);
/* Try to get the remaining pages with get_user_pages */
start += nr PAGE_SHIFT;
--
1.6.2.1
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH 3/7] powerpc: Cleanup use pr_devel() in arch/powerpc/mm/slb.c
pr_debug() can now result in code being generated even when DEBUG is not defined. That's not really desirable in some places. With CONFIG_DYNAMIC_DEBUG=y: size before: textdata bss dec hex filename 3261 416 43681 e61 arch/powerpc/mm/slb.o size after: textdata bss dec hex filename 2861 248 43113 c29 arch/powerpc/mm/slb.o Signed-off-by: Michael Ellerman mich...@ellerman.id.au --- arch/powerpc/mm/slb.c | 13 +++-- 1 files changed, 3 insertions(+), 10 deletions(-) diff --git a/arch/powerpc/mm/slb.c b/arch/powerpc/mm/slb.c index 3b52c80..5b7038f 100644 --- a/arch/powerpc/mm/slb.c +++ b/arch/powerpc/mm/slb.c @@ -14,8 +14,6 @@ * 2 of the License, or (at your option) any later version. */ -#undef DEBUG - #include asm/pgtable.h #include asm/mmu.h #include asm/mmu_context.h @@ -27,11 +25,6 @@ #include linux/compiler.h #include asm/udbg.h -#ifdef DEBUG -#define DBG(fmt...) printk(fmt) -#else -#define DBG pr_debug -#endif extern void slb_allocate_realmode(unsigned long ea); extern void slb_allocate_user(unsigned long ea); @@ -285,13 +278,13 @@ void slb_initialize(void) patch_slb_encoding(slb_compare_rr_to_size, mmu_slb_size); - DBG(SLB: linear LLP = %04lx\n, linear_llp); - DBG(SLB: io LLP = %04lx\n, io_llp); + pr_devel(SLB: linear LLP = %04lx\n, linear_llp); + pr_devel(SLB: io LLP = %04lx\n, io_llp); #ifdef CONFIG_SPARSEMEM_VMEMMAP patch_slb_encoding(slb_miss_kernel_load_vmemmap, SLB_VSID_KERNEL | vmemmap_llp); - DBG(SLB: vmemmap LLP = %04lx\n, vmemmap_llp); + pr_devel(SLB: vmemmap LLP = %04lx\n, vmemmap_llp); #endif } -- 1.6.2.1 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH 4/7] powerpc: Use pr_devel() in do_dcache_icache_coherency()
pr_debug() can now result in code being generated even when DEBUG
is not defined. That's not really desirable in some places.
With CONFIG_DYNAMIC_DEBUG=y:
size before:
textdata bss dec hex filename
2036 368 82412 96c arch/powerpc/mm/pgtable.o
size after:
textdata bss dec hex filename
1677 248 81933 78d arch/powerpc/mm/pgtable.o
Signed-off-by: Michael Ellerman mich...@ellerman.id.au
---
arch/powerpc/mm/pgtable.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/mm/pgtable.c b/arch/powerpc/mm/pgtable.c
index ae1d67c..627767d 100644
--- a/arch/powerpc/mm/pgtable.c
+++ b/arch/powerpc/mm/pgtable.c
@@ -129,12 +129,12 @@ static pte_t do_dcache_icache_coherency(pte_t pte)
page = pfn_to_page(pfn);
if (!PageReserved(page) !test_bit(PG_arch_1, page-flags)) {
- pr_debug(do_dcache_icache_coherency... flushing\n);
+ pr_devel(do_dcache_icache_coherency... flushing\n);
flush_dcache_icache_page(page);
set_bit(PG_arch_1, page-flags);
}
else
- pr_debug(do_dcache_icache_coherency... already clean\n);
+ pr_devel(do_dcache_icache_coherency... already clean\n);
return __pte(pte_val(pte) | _PAGE_HWEXEC);
}
--
1.6.2.1
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH 5/7] powerpc/cell: Use pr_devel() in axon_msi.c
pr_debug() can now result in code being generated even when DEBUG
is not defined. That's not really desirable in some places.
With CONFIG_DYNAMIC_DEBUG=y:
size before:
textdata bss dec hex filename
70831616 0869921fb arch/powerpc/../axon_msi.o
size after:
textdata bss dec hex filename
57721208 069801b44 arch/powerpc/../axon_msi.o
Signed-off-by: Michael Ellerman mich...@ellerman.id.au
---
arch/powerpc/platforms/cell/axon_msi.c | 22 +++---
1 files changed, 11 insertions(+), 11 deletions(-)
diff --git a/arch/powerpc/platforms/cell/axon_msi.c
b/arch/powerpc/platforms/cell/axon_msi.c
index c71498d..aca5741 100644
--- a/arch/powerpc/platforms/cell/axon_msi.c
+++ b/arch/powerpc/platforms/cell/axon_msi.c
@@ -85,7 +85,7 @@ static inline void axon_msi_debug_setup(struct device_node
*dn,
static void msic_dcr_write(struct axon_msic *msic, unsigned int dcr_n, u32 val)
{
- pr_debug(axon_msi: dcr_write(0x%x, 0x%x)\n, val, dcr_n);
+ pr_devel(axon_msi: dcr_write(0x%x, 0x%x)\n, val, dcr_n);
dcr_write(msic-dcr_host, dcr_n, val);
}
@@ -98,7 +98,7 @@ static void axon_msi_cascade(unsigned int irq, struct
irq_desc *desc)
int retry = 0;
write_offset = dcr_read(msic-dcr_host, MSIC_WRITE_OFFSET_REG);
- pr_debug(axon_msi: original write_offset 0x%x\n, write_offset);
+ pr_devel(axon_msi: original write_offset 0x%x\n, write_offset);
/* write_offset doesn't wrap properly, so we have to mask it */
write_offset = MSIC_FIFO_SIZE_MASK;
@@ -108,7 +108,7 @@ static void axon_msi_cascade(unsigned int irq, struct
irq_desc *desc)
msi = le32_to_cpu(msic-fifo_virt[idx]);
msi = 0x;
- pr_debug(axon_msi: woff %x roff %x msi %x\n,
+ pr_devel(axon_msi: woff %x roff %x msi %x\n,
write_offset, msic-read_offset, msi);
if (msi NR_IRQS irq_map[msi].host == msic-irq_host) {
@@ -123,12 +123,12 @@ static void axon_msi_cascade(unsigned int irq, struct
irq_desc *desc)
*/
udelay(1);
retry++;
- pr_debug(axon_msi: invalid irq 0x%x!\n, msi);
+ pr_devel(axon_msi: invalid irq 0x%x!\n, msi);
continue;
}
if (retry) {
- pr_debug(axon_msi: late irq 0x%x, retry %d\n,
+ pr_devel(axon_msi: late irq 0x%x, retry %d\n,
msi, retry);
retry = 0;
}
@@ -332,7 +332,7 @@ static int axon_msi_shutdown(struct of_device *device)
struct axon_msic *msic = dev_get_drvdata(device-dev);
u32 tmp;
- pr_debug(axon_msi: disabling %s\n,
+ pr_devel(axon_msi: disabling %s\n,
msic-irq_host-of_node-full_name);
tmp = dcr_read(msic-dcr_host, MSIC_CTRL_REG);
tmp = ~MSIC_CTRL_ENABLE ~MSIC_CTRL_IRQ_ENABLE;
@@ -349,7 +349,7 @@ static int axon_msi_probe(struct of_device *device,
unsigned int virq;
int dcr_base, dcr_len;
- pr_debug(axon_msi: setting up dn %s\n, dn-full_name);
+ pr_devel(axon_msi: setting up dn %s\n, dn-full_name);
msic = kzalloc(sizeof(struct axon_msic), GFP_KERNEL);
if (!msic) {
@@ -403,7 +403,7 @@ static int axon_msi_probe(struct of_device *device,
set_irq_data(virq, msic);
set_irq_chained_handler(virq, axon_msi_cascade);
- pr_debug(axon_msi: irq 0x%x setup for axon_msi\n, virq);
+ pr_devel(axon_msi: irq 0x%x setup for axon_msi\n, virq);
/* Enable the MSIC hardware */
msic_dcr_write(msic, MSIC_BASE_ADDR_HI_REG, msic-fifo_phys 32);
@@ -484,13 +484,13 @@ void axon_msi_debug_setup(struct device_node *dn, struct
axon_msic *msic)
addr = of_translate_address(dn, of_get_property(dn, reg, NULL));
if (addr == OF_BAD_ADDR) {
- pr_debug(axon_msi: couldn't translate reg property\n);
+ pr_devel(axon_msi: couldn't translate reg property\n);
return;
}
msic-trigger = ioremap(addr, 0x4);
if (!msic-trigger) {
- pr_debug(axon_msi: ioremap failed\n);
+ pr_devel(axon_msi: ioremap failed\n);
return;
}
@@ -498,7 +498,7 @@ void axon_msi_debug_setup(struct device_node *dn, struct
axon_msic *msic)
if (!debugfs_create_file(name, 0600, powerpc_debugfs_root,
msic, fops_msic)) {
- pr_debug(axon_msi: debugfs_create_file failed!\n);
+ pr_devel(axon_msi: debugfs_create_file failed!\n);
return;
}
}
--
1.6.2.1
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
[PATCH 6/7] powerpc/pseries: Use pr_devel() in xics.c
pr_debug() can now result in code being generated even when DEBUG
is not defined. That's not really desirable in some places.
With CONFIG_DYNAMIC_DEBUG=y:
size before:
textdata bss dec hex filename
77205488 296 1350434c0 platforms/pseries/xics.o
size after:
textdata bss dec hex filename
75355456 296 1328733e7 platforms/pseries/xics.o
Signed-off-by: Michael Ellerman mich...@ellerman.id.au
---
arch/powerpc/platforms/pseries/xics.c |8
1 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/arch/powerpc/platforms/pseries/xics.c
b/arch/powerpc/platforms/pseries/xics.c
index be3581a..419f8a6 100644
--- a/arch/powerpc/platforms/pseries/xics.c
+++ b/arch/powerpc/platforms/pseries/xics.c
@@ -190,10 +190,10 @@ static void xics_unmask_irq(unsigned int virq)
int call_status;
int server;
- pr_debug(xics: unmask virq %d\n, virq);
+ pr_devel(xics: unmask virq %d\n, virq);
irq = (unsigned int)irq_map[virq].hwirq;
- pr_debug( - map to hwirq 0x%x\n, irq);
+ pr_devel( - map to hwirq 0x%x\n, irq);
if (irq == XICS_IPI || irq == XICS_IRQ_SPURIOUS)
return;
@@ -252,7 +252,7 @@ static void xics_mask_irq(unsigned int virq)
{
unsigned int irq;
- pr_debug(xics: mask virq %d\n, virq);
+ pr_devel(xics: mask virq %d\n, virq);
irq = (unsigned int)irq_map[virq].hwirq;
if (irq == XICS_IPI || irq == XICS_IRQ_SPURIOUS)
@@ -414,7 +414,7 @@ static int xics_host_match(struct irq_host *h, struct
device_node *node)
static int xics_host_map(struct irq_host *h, unsigned int virq,
irq_hw_number_t hw)
{
- pr_debug(xics: map virq %d, hwirq 0x%lx\n, virq, hw);
+ pr_devel(xics: map virq %d, hwirq 0x%lx\n, virq, hw);
/* Insert the interrupt mapping into the radix tree for fast lookup */
irq_radix_revmap_insert(xics_host, virq, hw);
--
1.6.2.1
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH 7/7] powerpc: Use pr_devel() in arch/powerpc/mm/mmu_context_nohash.c
pr_debug() can now result in code being generated even when DEBUG
is not defined. That's not really desirable in some places.
With CONFIG_DYNAMIC_DEBUG=y:
size before:
textdata bss dec hex filename
1508 48 281584 630 powerpc/mm/mmu_context_nohash.o
size after:
textdata bss dec hex filename
1088 0 281116 45c powerpc/mm/mmu_context_nohash.o
Signed-off-by: Michael Ellerman mich...@ellerman.id.au
---
arch/powerpc/mm/mmu_context_nohash.c | 16
1 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/arch/powerpc/mm/mmu_context_nohash.c
b/arch/powerpc/mm/mmu_context_nohash.c
index 8343986..92a1971 100644
--- a/arch/powerpc/mm/mmu_context_nohash.c
+++ b/arch/powerpc/mm/mmu_context_nohash.c
@@ -89,7 +89,7 @@ static unsigned int steal_context_smp(unsigned int id)
id = first_context;
continue;
}
- pr_debug([%d] steal context %d from mm @%p\n,
+ pr_devel([%d] steal context %d from mm @%p\n,
smp_processor_id(), id, mm);
/* Mark this mm has having no context anymore */
@@ -126,7 +126,7 @@ static unsigned int steal_context_up(unsigned int id)
/* Pick up the victim mm */
mm = context_mm[id];
- pr_debug([%d] steal context %d from mm @%p\n, cpu, id, mm);
+ pr_devel([%d] steal context %d from mm @%p\n, cpu, id, mm);
/* Flush the TLB for that context */
local_flush_tlb_mm(mm);
@@ -180,7 +180,7 @@ void switch_mmu_context(struct mm_struct *prev, struct
mm_struct *next)
spin_lock(context_lock);
#ifndef DEBUG_STEAL_ONLY
- pr_debug([%d] activating context for mm @%p, active=%d, id=%d\n,
+ pr_devel([%d] activating context for mm @%p, active=%d, id=%d\n,
cpu, next, next-context.active, next-context.id);
#endif
@@ -189,7 +189,7 @@ void switch_mmu_context(struct mm_struct *prev, struct
mm_struct *next)
next-context.active++;
if (prev) {
#ifndef DEBUG_STEAL_ONLY
- pr_debug( old context %p active was: %d\n,
+ pr_devel( old context %p active was: %d\n,
prev, prev-context.active);
#endif
WARN_ON(prev-context.active 1);
@@ -236,7 +236,7 @@ void switch_mmu_context(struct mm_struct *prev, struct
mm_struct *next)
next-context.id = id;
#ifndef DEBUG_STEAL_ONLY
- pr_debug([%d] picked up new id %d, nrf is now %d\n,
+ pr_devel([%d] picked up new id %d, nrf is now %d\n,
cpu, id, nr_free_contexts);
#endif
@@ -247,7 +247,7 @@ void switch_mmu_context(struct mm_struct *prev, struct
mm_struct *next)
* local TLB for it and unmark it before we use it
*/
if (test_bit(id, stale_map[cpu])) {
- pr_debug([%d] flushing stale context %d for mm @%p !\n,
+ pr_devel([%d] flushing stale context %d for mm @%p !\n,
cpu, id, next);
local_flush_tlb_mm(next);
@@ -314,13 +314,13 @@ static int __cpuinit mmu_context_cpu_notify(struct
notifier_block *self,
switch (action) {
case CPU_ONLINE:
case CPU_ONLINE_FROZEN:
- pr_debug(MMU: Allocating stale context map for CPU %d\n, cpu);
+ pr_devel(MMU: Allocating stale context map for CPU %d\n, cpu);
stale_map[cpu] = kzalloc(CTX_MAP_SIZE, GFP_KERNEL);
break;
#ifdef CONFIG_HOTPLUG_CPU
case CPU_DEAD:
case CPU_DEAD_FROZEN:
- pr_debug(MMU: Freeing stale context map for CPU %d\n, cpu);
+ pr_devel(MMU: Freeing stale context map for CPU %d\n, cpu);
kfree(stale_map[cpu]);
stale_map[cpu] = NULL;
break;
--
1.6.2.1
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
