Re: MPC5121 CAN and USB
On Friday 16 October 2009 01:10:05 am Wolfgang Denk wrote: Dear Paul, In message 26b052040910151603y8fc9b00g678d6a873083f...@mail.gmail.com you wrote: The ltib-mpc5121ads-20090602 branch reflects the exact state of the kernel contained in the LTIB with this name (dated July 2009, despite the name; based at 2.6.24.6, i. e. 7+ kernel versions behind). I have diff'ed this and it is very similar to the ltib in the BSP. The MBX patches may be missing though. These patches can be obtained via the Freescale SDK for the OpenGL on the MPC5121e webpage. Who cares. This code is about 8 (!) kernel releases behind. Scrap it. I would love to, but as it stands, this is still the best we can get for the MPC5121e :-( I took that branch, merged the MBX patch in from the LTIB and ported the new NFC driver from the 'mpc512x' branch back to this one, since the original driver is buggy. The latest OpenGL-ES libraries and MBX drivers released are closed-source, buggy, but stable and seem to work well if your program doesn't do the kinds of things that make it crash. If you know the limitations of this and can live with it, it might be bearable... I don't have any other option :-( Best regards, -- David Jander Protonic Holland. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 3/3] powerpc: perf_event: Hide iseries_check_pending_irqs
* Anton Blanchard an...@samba.org wrote: If CONFIG_PPC_ISERIES isn't defined we end up with iseries_check_pending_irqs and do_work at the same address. perf ends up picking iseries_check_pending_irqs which creates confusing backtraces. Hide it. Signed-off-by: Anton Blanchard an...@samba.org Just to confirm - these 3 symbol fixes are for the PowerPC tree, not for the perf events tree, right? There's nothing perf specific about the fixes - kgdb, systemtap and other debugging/instrumentation frameworks will benefit from more precise symbol generation too. Ingo ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 3/3] powerpc perf_event: Add alignment-faults and emulation-faults software events
* Anton Blanchard an...@samba.org wrote: Hook up the alignment-faults and emulation-faults events for powerpc. Signed-off-by: Anton Blanchard an...@samba.org nice. The first patch is for perf events - it would be nice if we could do the two PowerPC changes via the perf events tree - that would speed up the upstream availability of this new feature. Ben, what do you think? Ingo ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Acceleration for map_copy_from on powerpc 512x
Hi, I'm working on a powerpc (PPC512x) embedded Linux product, and while I was trying to improve boot time, I found I could exploit the hw in order to speed up reading from NOR flashes. The Linux/mtd version we're using is 2.6.24.6+Freescale patches. Basically, I needed to hack the map_copy_from, which for my arch and uncached areas translates to a memcpy, in order to use the SCLPC FIFO, with a performance benefit of 2x on aligned multiple of 32Bytes transfers. I didn't find a cleaner way than just #ifdef'ing the map_copy_from call and substitute with my call on relevant cases. I wonder if there is a cleaner way. And yes, as soon as I've cleaned up the code a little bit, I will definitely post a patch about it. Moreover: a huge benefit would come from exploiting DMA on these transfers, but I found I'm in_atomic while doing map_copy_from... is there an alternative way of locking than just disabling preemption? I know maybe a newer kernel has already fixed it, but we're kind of stuck with the old one since we don't have time to port all of our device drivers to 2.6.3x Thanks, Matteo ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: UBIFS problem on MPC8536DS
On Sun, Oct 18, 2009 at 11:38:13AM +0200, Felix Radensky wrote: Hi, Scott Scott Wood wrote: On Fri, Oct 16, 2009 at 07:01:43AM +0200, Felix Radensky wrote: Thanks for confirmation. So the real problem is eLBC ? What happens if I access other devices on eLBC (e.g. FPGA) simultaneously with NAND or NOR ? AFAICT, the problem is NAND being accessed simultaneously with anything else on the eLBC (at least GPCM -- not sure about UPM). Instead of delaying the memory-like transaction until the NAND special operation has completed, it seems to just abort the NAND operation. eLBC can't really tell the difference whether you've got NOR or FPGA hooked up to a GPCM chip select, so the problem should still apply. Can you please provide some code example of synchronizing GPCM and NAND ? I don't have any. It's something that would have to be written. -Scott ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH 1/1] powerpc: Add kdump support to Collaborative Memory Manager
When running Active Memory Sharing, the Collaborative Memory Manager (CMM)
may mark some pages as loaned with the hypervisor. Periodically, the
CMM will query the hypervisor for a loan request, which is a single signed
value. When kexec'ing into a kdump kernel, the CMM driver in the kdump
kernel is not aware of the pages the previous kernel had marked as loaned,
so the hypervisor and the CMM driver are out of sync. Fix the CMM driver
to handle this scenario by ignoring requests to decrease the number of loaned
pages if we don't think we have any pages loaned. Pages that are marked as
loaned which are not in the balloon will automatically get switched to
active
the next time we touch the page. This also fixes the case where totalram_pages
is smaller than min_mem_mb, which can occur during kdump.
Signed-off-by: Brian King brk...@linux.vnet.ibm.com
---
arch/powerpc/platforms/pseries/Kconfig |2 +-
arch/powerpc/platforms/pseries/cmm.c | 29 +++--
2 files changed, 20 insertions(+), 11 deletions(-)
diff -puN arch/powerpc/platforms/pseries/cmm.c~powerpc_cmm_fix_kdump
arch/powerpc/platforms/pseries/cmm.c
--- linux-2.6/arch/powerpc/platforms/pseries/cmm.c~powerpc_cmm_fix_kdump
2009-09-24 16:35:00.0 -0500
+++ linux-2.6-bjking1/arch/powerpc/platforms/pseries/cmm.c 2009-09-25
10:24:19.0 -0500
@@ -229,8 +229,9 @@ static void cmm_get_mpp(void)
{
int rc;
struct hvcall_mpp_data mpp_data;
- unsigned long active_pages_target;
- signed long page_loan_request;
+ signed long active_pages_target, page_loan_request, target;
+ signed long total_pages = totalram_pages + loaned_pages;
+ signed long min_mem_pages = (min_mem_mb * 1024 * 1024) / PAGE_SIZE;
rc = h_get_mpp(mpp_data);
@@ -238,17 +239,25 @@ static void cmm_get_mpp(void)
return;
page_loan_request = div_s64((s64)mpp_data.loan_request, PAGE_SIZE);
- loaned_pages_target = page_loan_request + loaned_pages;
- if (loaned_pages_target oom_freed_pages)
- loaned_pages_target -= oom_freed_pages;
+ target = page_loan_request + (signed long)loaned_pages;
+
+ if (target 0 || total_pages min_mem_pages)
+ target = 0;
+
+ if (target oom_freed_pages)
+ target -= oom_freed_pages;
else
- loaned_pages_target = 0;
+ target = 0;
+
+ active_pages_target = total_pages - target;
+
+ if (min_mem_pages active_pages_target)
+ target = total_pages - min_mem_pages;
- active_pages_target = totalram_pages + loaned_pages -
loaned_pages_target;
+ if (target 0)
+ target = 0;
- if ((min_mem_mb * 1024 * 1024) (active_pages_target * PAGE_SIZE))
- loaned_pages_target = totalram_pages + loaned_pages -
- ((min_mem_mb * 1024 * 1024) / PAGE_SIZE);
+ loaned_pages_target = target;
cmm_dbg(delta = %ld, loaned = %lu, target = %lu, oom = %lu, totalram =
%lu\n,
page_loan_request, loaned_pages, loaned_pages_target,
diff -puN arch/powerpc/platforms/pseries/Kconfig~powerpc_cmm_fix_kdump
arch/powerpc/platforms/pseries/Kconfig
--- linux-2.6/arch/powerpc/platforms/pseries/Kconfig~powerpc_cmm_fix_kdump
2009-09-24 16:35:00.0 -0500
+++ linux-2.6-bjking1/arch/powerpc/platforms/pseries/Kconfig2009-09-24
16:35:00.0 -0500
@@ -59,7 +59,7 @@ config PPC_SMLPAR
config CMM
tristate Collaborative memory management
- depends on PPC_SMLPAR !CRASH_DUMP
+ depends on PPC_SMLPAR
default y
help
Select this option, if you want to enable the kernel interface
_
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] powerpc: tracing: Add powerpc tracepoints for interrupt entry and exit
On Sun, 2009-10-18 at 22:01 +1100, Anton Blanchard wrote: Hi Ben, Breaks 6xx_defconfig: Yuck. Since the CREATE_TRACE_POINTS stuff appears to need a non trivial number of includes it might be best just to fold it into one of the tracepoint call sites like this. -- This patch adds powerpc specific tracepoints for interrupt entry and exit. While we already have generic irq_handler_entry and irq_handler_exit tracepoints there are cases on our virtualised powerpc machines where an interrupt is presented to the OS, but subsequently handled by the hypervisor. This means no OS interrupt handler is invoked. Here is an example on a POWER6 machine with the patch below applied: idle-0 [006] 3243.949840744: irq_entry: pt_regs=c000ce31fb10 idle-0 [006] 3243.949850520: irq_exit: pt_regs=c000ce31fb10 idle-0 [007] 3243.950218208: irq_entry: pt_regs=c000ce323b10 idle-0 [007] 3243.950224080: irq_exit: pt_regs=c000ce323b10 idle-0 [000] 3244.021879320: irq_entry: pt_regs=c0a63aa0 idle-0 [000] 3244.021883616: irq_handler_entry: irq=87 handler=eth0 idle-0 [000] 3244.021887328: irq_handler_exit: irq=87 return=handled idle-0 [000] 3244.021897408: irq_exit: pt_regs=c0a63aa0 Here we see two phantom interrupts (no handler was invoked), followed by a real interrupt for eth0. Without the tracepoints in this patch we would have missed the phantom interrupts. Since these would be the first arch specific tracepoints, I'd like to make sure we agree on naming. The tracepoints live in events/powerpc/*, but I'm wondering if the tracepoint name should also contain the arch name, eg powerpc_irq_entry/powerpc_irq_exit. Thoughts? Signed-off-by: Anton Blanchard an...@samba.org -- I'm fine with the name powerpc. Acked-by: Steven Rostedt rost...@goodmis.org ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: linux-next: tree build failure
On Thu, 2009-10-15 at 08:27 +0100, Jan Beulich wrote:
Hollis Blanchard holl...@us.ibm.com 15.10.09 00:57
On Fri, 2009-10-09 at 12:14 -0700, Hollis Blanchard wrote:
Rusty's version of BUILD_BUG_ON() does indeed fix the build break, and
also exposes the bug in kvmppc_account_exit_stat(). So to recap:
original: built but didn't work
Jan's: doesn't build
Rusty's: builds and works
Where do you want to go from here?
Jan, what are your thoughts? Your BUILD_BUG_ON patch has broken the
build, and we still need to fix it.
My perspective is that it just uncovered already existing brokenness. And
honestly, I won't be able to get to look into this within the next days. (And
btw., when I run into issues with other people's code changes, quite
frequently I'm told to propose a patch, so I'm also having some
philosophical problem understanding why I can't simply expect the same
when people run into issues with changes I made, especially in cases like
this where it wasn't me introducing the broken code.) So, if this can wait
for a couple of days, I can try to find time to look into this. Otherwise, I'd
rely on someone running into the actual issue to implement a solution.
Sorry, I thought it was clear, but to be more explicit: I propose the
following patch, which replaces the current BUILD_BUG_ON implementation
with Rusty's version.
diff --git a/include/linux/kernel.h b/include/linux/kernel.h
--- a/include/linux/kernel.h
+++ b/include/linux/kernel.h
@@ -677,18 +677,19 @@ struct sysinfo {
char _f[20-2*sizeof(long)-sizeof(int)]; /* Padding: libc5 uses this.. */
};
-/* Force a compilation error if condition is true */
-#define BUILD_BUG_ON(condition) ((void)BUILD_BUG_ON_ZERO(condition))
-
-/* Force a compilation error if condition is constant and true */
-#define MAYBE_BUILD_BUG_ON(cond) ((void)sizeof(char[1 - 2 * !!(cond)]))
-
-/* Force a compilation error if condition is true, but also produce a
- result (of value 0 and type size_t), so the expression can be used
- e.g. in a structure initializer (or where-ever else comma expressions
- aren't permitted). */
-#define BUILD_BUG_ON_ZERO(e) (sizeof(struct { int:-!!(e); }))
-#define BUILD_BUG_ON_NULL(e) ((void *)sizeof(struct { int:-!!(e); }))
+#ifndef __OPTIMIZE__
+#define BUILD_BUG_ON(condition) ((void)sizeof(char[1 - 2*!!(condition)]))
+#else
+/* If it's a constant, catch it at compile time, otherwise at link time. */
+extern int __build_bug_on_failed;
+#define BUILD_BUG_ON_ZERO(e) (sizeof(char[1 - 2 * !!(e)]) - 1)
+#define BUILD_BUG_ON(condition) \
+ do {
\
+ ((void)sizeof(char[1 - 2*!!(condition)]));
\
+ if (condition) __build_bug_on_failed = 1;
\
+ } while(0)
+#define MAYBE_BUILD_BUG_ON(condition) BUILD_BUG_ON(condition)
+#endif
/* Trap pasters of __FUNCTION__ at compile-time */
#define __FUNCTION__ (__func__)
--
Hollis Blanchard
IBM Linux Technology Center
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH] [RFC] PowerPC64: Use preempt_schedule_irq instead of preempt_schedule when returning from exceptions
Use preempt_schedule_irq to prevent infinite irq-entry and eventual stack overflow problems with fast-paced IRQ sources. This kind of problems has been observed on the PASemi Electra IDE controller. We have to make sure we are soft-disabled before calling preempt_schedule_irq and hard disable interrupts after that to avoid unrecoverable exceptions. This patch also moves the clrrdi r9,r1,THREAD_SHIFT out of the #ifdef CONFIG_PPC_BOOK3E scope, since r9 is clobbered and has to be restored in both cases. Signed-off-by: Valentine Barshak vbars...@ru.mvista.com --- arch/powerpc/kernel/entry_64.S | 25 ++--- 1 file changed, 6 insertions(+), 19 deletions(-) diff -pruN linux-2.6.orig/arch/powerpc/kernel/entry_64.S linux-2.6.new/arch/powerpc/kernel/entry_64.S --- linux-2.6.orig/arch/powerpc/kernel/entry_64.S 2009-10-17 03:46:26.0 +0400 +++ linux-2.6.new/arch/powerpc/kernel/entry_64.S2009-10-19 17:35:16.0 +0400 @@ -660,33 +660,20 @@ do_work: bne restore /* here we are preempting the current task */ 1: -#ifdef CONFIG_TRACE_IRQFLAGS - bl .trace_hardirqs_on - /* Note: we just clobbered r10 which used to contain the previous -* MSR before the hard-disabling done by the caller of do_work. -* We don't have that value anymore, but it doesn't matter as -* we will hard-enable unconditionally, we can just reload the -* current MSR into r10 -*/ - mfmsr r10 -#endif /* CONFIG_TRACE_IRQFLAGS */ - li r0,1 + /* ensure we are soft-disabled */ + li r0,0 stb r0,PACASOFTIRQEN(r13) - stb r0,PACAHARDIRQEN(r13) + bl .preempt_schedule_irq + /* hard-disable interrupts */ #ifdef CONFIG_PPC_BOOK3E - wrteei 1 - bl .preempt_schedule wrteei 0 #else - ori r10,r10,MSR_EE - mtmsrd r10,1 /* reenable interrupts */ - bl .preempt_schedule mfmsr r10 - clrrdi r9,r1,THREAD_SHIFT - rldicl r10,r10,48,1/* disable interrupts again */ + rldicl r10,r10,48,1 rotldi r10,r10,16 mtmsrd r10,1 #endif /* CONFIG_PPC_BOOK3E */ + clrrdi r9,r1,THREAD_SHIFT ld r4,TI_FLAGS(r9) andi. r0,r4,_TIF_NEED_RESCHED bne 1b ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: UBIFS problem on MPC8536DS
Scott Wood wrote: On Sun, Oct 18, 2009 at 11:38:13AM +0200, Felix Radensky wrote: Hi, Scott Scott Wood wrote: On Fri, Oct 16, 2009 at 07:01:43AM +0200, Felix Radensky wrote: Thanks for confirmation. So the real problem is eLBC ? What happens if I access other devices on eLBC (e.g. FPGA) simultaneously with NAND or NOR ? AFAICT, the problem is NAND being accessed simultaneously with anything else on the eLBC (at least GPCM -- not sure about UPM). Instead of delaying the memory-like transaction until the NAND special operation has completed, it seems to just abort the NAND operation. eLBC can't really tell the difference whether you've got NOR or FPGA hooked up to a GPCM chip select, so the problem should still apply. Can you please provide some code example of synchronizing GPCM and NAND ? I don't have any. It's something that would have to be written. OK, no problem. I just wanted to get an idea of what should be done. Should the NOR code poll some eLBC register to wait for completion of NAND special operation ? Can you tell what register is relevant ? Thanks. Felix. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: UBIFS problem on MPC8536DS
Felix Radensky wrote: OK, no problem. I just wanted to get an idea of what should be done. Should the NOR code poll some eLBC register to wait for completion of NAND special operation ? Can you tell what register is relevant ? I was thinking you'd just share a mutex with the NAND code. -Scott ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: UBIFS problem on MPC8536DS
Scott Wood wrote: Felix Radensky wrote: OK, no problem. I just wanted to get an idea of what should be done. Should the NOR code poll some eLBC register to wait for completion of NAND special operation ? Can you tell what register is relevant ? I was thinking you'd just share a mutex with the NAND code. Thanks. Do I understand correctly that in fsl_ebc_nand.c this mutex should protect the execution of special operation and wait for completion in fsl_elbc_run_command() routine ? Felix. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: linux-next: tree build failure
On Tue, 2009-10-20 at 11:42 +1030, Rusty Russell wrote: On Tue, 20 Oct 2009 04:49:29 am Hollis Blanchard wrote: On Thu, 2009-10-15 at 08:27 +0100, Jan Beulich wrote: My perspective is that it just uncovered already existing brokenness. Sorry, I thought it was clear, but to be more explicit: I propose the following patch, which replaces the current BUILD_BUG_ON implementation with Rusty's version. OK, I switched my brain back on. Yeah, I agree: we may still want BUILD_OR_RUNTIME_BUG_ON one day, but I like this. It's just missing the giant comment that it needs :) /** * BUILD_BUG_ON - break compile if a condition is true. * @cond: the condition which the compiler should know is false. * * If you have some code which relies on certain constants being equal, or * other compile-time-evaluated condition, you should use BUILD_BUG_ON to * detect if someone changes it. * * The implementation uses gcc's reluctance to create a negative array, but * gcc (as of 4.4) only emits that error for obvious cases (eg. not arguments * to inline functions). So as a fallback we use the optimizer; if it can't * prove the condition is false, it will cause a link error on the undefined * __build_bug_on_failed. This error is less neat, and can be harder to * track down. */ Do you want to put together a signed-off patch Rusty? It's your code, so I don't feel comfortable doing that. Once we have that, can we remove the mysterious MAYBE_BUILD_BUG_ON statements introduced in previous patches? (Does it BUG or doesn't it??) -- Hollis Blanchard IBM Linux Technology Center ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 3/3] powerpc: perf_event: Hide iseries_check_pending_irqs
Hi Ingo, Just to confirm - these 3 symbol fixes are for the PowerPC tree, not for the perf events tree, right? There's nothing perf specific about the fixes - kgdb, systemtap and other debugging/instrumentation frameworks will benefit from more precise symbol generation too. Yeah, while they were written to fix perf backtrace issues they are definitely not perf specific. Hopefully Ben will queue them up in his tree for the next merge window :) Anton ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 3/3] powerpc: perf_event: Hide iseries_check_pending_irqs
On Tue, 2009-10-20 at 14:50 +1100, Anton Blanchard wrote: Hi Ingo, Just to confirm - these 3 symbol fixes are for the PowerPC tree, not for the perf events tree, right? There's nothing perf specific about the fixes - kgdb, systemtap and other debugging/instrumentation frameworks will benefit from more precise symbol generation too. Yeah, while they were written to fix perf backtrace issues they are definitely not perf specific. Hopefully Ben will queue them up in his tree for the next merge window :) Right, I'm overdue for a powerpc-next but with some family issues last couple of week and KS/JLS this week, it' a bit hard :-) Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
