* [PATCH v3 2/3] powerpc/fsl: 85xx: document cache-sram
From: Vivek Mahajan @ 2009-10-21 12:50 UTC (permalink / raw)
To: linuxppc-dev; +Cc: kumar.gala, Vivek Mahajan
In-Reply-To: <1256129459-10685-1-git-send-email-vivek.mahajan@freescale.com>
Adds documentation for Freescale's QorIQ based cache-sram as under:-
* How to enable it from a low level driver
* How to set its size
Signed-off-by: Vivek Mahajan <vivek.mahajan@freescale.com>
---
v2, v3: No change over v1
Documentation/powerpc/fsl_85xx_cache_sram.txt | 31 +++++++++++++++++++++++++
1 files changed, 31 insertions(+), 0 deletions(-)
create mode 100644 Documentation/powerpc/fsl_85xx_cache_sram.txt
diff --git a/Documentation/powerpc/fsl_85xx_cache_sram.txt b/Documentation/powerpc/fsl_85xx_cache_sram.txt
new file mode 100644
index 0000000..7f43e2a
--- /dev/null
+++ b/Documentation/powerpc/fsl_85xx_cache_sram.txt
@@ -0,0 +1,31 @@
+* Freescale QorIQ based Cache SRAM
+
+Freescale's QorIQ platforms provide an option of configuring
+a part of (or full) cache memory as SRAM. Any low level
+driver can use its APIs via selecting FSL_85XX_CACHE_SRAM as
+under for the case of gianfar ethernet driver:-
+
+In drivers/net/Kconfig:-
+
+config GIANFAR
+ ....
+ select FSL_85XX_CACHE_SRAM if MPC85xx
+ ....
+
+FSL_85XX_CACHE_SRAM and its base address are defined in
+arch/powerpc/platforms/85xx/Kconfig as under:-
+
+config FSL_85XX_CACHE_SRAM
+ bool
+ select PPC_LIB_RHEAP
+
+config FSL_85XX_CACHE_SRAM_BASE
+ hex
+ depends on FSL_85XX_CACHE_SRAM
+ default "0xfff00000"
+
+The size of the above cache SRAM memory window is passed via the
+kernel command line as <cache-sram-size=....>
+
+Absence of the above parameter in the kernel command line is
+treated as no cache SRAM.
--
1.5.6.5
^ permalink raw reply related
* [PATCH v3 1/3] powerpc/fsl: 85xx: document cache-sram size as a kernel parametric option
From: Vivek Mahajan @ 2009-10-21 12:50 UTC (permalink / raw)
To: linuxppc-dev; +Cc: kumar.gala, Vivek Mahajan
Adds documentation for the size parameter of Freescale's QorIQ
based cache-sram
Signed-off-by: Vivek Mahajan <vivek.mahajan@freescale.com>
---
v2, v3: No change over v1
Documentation/kernel-parameters.txt | 3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/Documentation/kernel-parameters.txt b/Documentation/kernel-parameters.txt
index 6fa7292..8767f36 100644
--- a/Documentation/kernel-parameters.txt
+++ b/Documentation/kernel-parameters.txt
@@ -412,6 +412,9 @@ and is between 256 and 4096 characters. It is defined in the file
c101= [NET] Moxa C101 synchronous serial card
+ cache-sram-size= [PPC] Size of Freescale's QorIQ Cache SRAM
+ See Documentation/powerpc/fsl_85xx_cache_sram.txt.
+
cachesize= [BUGS=X86-32] Override level 2 CPU cache size detection.
Sometimes CPU hardware bugs make them report the cache
size incorrectly. The kernel will attempt work arounds
--
1.5.6.5
^ permalink raw reply related
* [PATCH] powerpc: Move ehea hcall definitions into hvcall.h
From: Anton Blanchard @ 2009-10-21 6:06 UTC (permalink / raw)
To: benh; +Cc: tklein, raisch, linuxppc-dev, themann
Move ehea hcall definitions into hvcall.h.
Signed-off-by: Anton Blanchard <anton@samba.org>
---
Index: linux.trees.git/arch/powerpc/include/asm/hvcall.h
===================================================================
--- linux.trees.git.orig/arch/powerpc/include/asm/hvcall.h 2009-10-19 17:59:42.000000000 +1100
+++ linux.trees.git/arch/powerpc/include/asm/hvcall.h 2009-10-19 18:03:18.000000000 +1100
@@ -212,6 +212,19 @@
#define H_QUERY_INT_STATE 0x1E4
#define H_POLL_PENDING 0x1D8
#define H_ILLAN_ATTRIBUTES 0x244
+#define H_MODIFY_HEA_QP 0x250
+#define H_QUERY_HEA_QP 0x254
+#define H_QUERY_HEA 0x258
+#define H_QUERY_HEA_PORT 0x25C
+#define H_MODIFY_HEA_PORT 0x260
+#define H_REG_BCMC 0x264
+#define H_DEREG_BCMC 0x268
+#define H_REGISTER_HEA_RPAGES 0x26C
+#define H_DISABLE_AND_GET_HEA 0x270
+#define H_GET_HEA_INFO 0x274
+#define H_ALLOC_HEA_RESOURCE 0x278
+#define H_ADD_CONN 0x284
+#define H_DEL_CONN 0x288
#define H_JOIN 0x298
#define H_VASI_STATE 0x2A4
#define H_ENABLE_CRQ 0x2B0
Index: linux.trees.git/drivers/net/ehea/ehea_phyp.h
===================================================================
--- linux.trees.git.orig/drivers/net/ehea/ehea_phyp.h 2009-10-19 18:03:48.000000000 +1100
+++ linux.trees.git/drivers/net/ehea/ehea_phyp.h 2009-10-19 18:03:56.000000000 +1100
@@ -33,7 +33,6 @@
#include <asm/hvcall.h>
#include "ehea.h"
#include "ehea_hw.h"
-#include "ehea_hcall.h"
/* Some abbreviations used here:
*
Index: linux.trees.git/drivers/net/ehea/ehea_hcall.h
===================================================================
--- linux.trees.git.orig/drivers/net/ehea/ehea_hcall.h 2009-10-19 17:59:31.000000000 +1100
+++ /dev/null 1970-01-01 00:00:00.000000000 +0000
@@ -1,51 +0,0 @@
-/*
- * linux/drivers/net/ehea/ehea_hcall.h
- *
- * eHEA ethernet device driver for IBM eServer System p
- *
- * (C) Copyright IBM Corp. 2006
- *
- * Authors:
- * Christoph Raisch <raisch@de.ibm.com>
- * Jan-Bernd Themann <themann@de.ibm.com>
- * Thomas Klein <tklein@de.ibm.com>
- *
- *
- * 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, or (at your option)
- * any later version.
- *
- * This program is distributed in the hope that it will be useful,
- * but WITHOUT ANY WARRANTY; without even the implied warranty of
- * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
- * GNU General Public License for more details.
- *
- * You should have received a copy of the GNU General Public License
- * along with this program; if not, write to the Free Software
- * Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
- */
-
-#ifndef __EHEA_HCALL_H__
-#define __EHEA_HCALL_H__
-
-/**
- * This file contains HCALL defines that are to be included in the appropriate
- * kernel files later
- */
-
-#define H_ALLOC_HEA_RESOURCE 0x278
-#define H_MODIFY_HEA_QP 0x250
-#define H_QUERY_HEA_QP 0x254
-#define H_QUERY_HEA 0x258
-#define H_QUERY_HEA_PORT 0x25C
-#define H_MODIFY_HEA_PORT 0x260
-#define H_REG_BCMC 0x264
-#define H_DEREG_BCMC 0x268
-#define H_REGISTER_HEA_RPAGES 0x26C
-#define H_DISABLE_AND_GET_HEA 0x270
-#define H_GET_HEA_INFO 0x274
-#define H_ADD_CONN 0x284
-#define H_DEL_CONN 0x288
-
-#endif /* __EHEA_HCALL_H__ */
^ permalink raw reply
* Re: Device Tree Corrupted after unflatten_device_tree()
From: Michael Ellerman @ 2009-10-20 23:01 UTC (permalink / raw)
To: Lixin Yao; +Cc: linuxppc-dev
In-Reply-To: <03D77CA4AC7F4D48A6AB5DA3F1001B3FB5BB88@exchtxus2.HSTX.global.vpn>
[-- Attachment #1: Type: text/plain, Size: 986 bytes --]
On Tue, 2009-10-20 at 09:10 -0700, Lixin Yao wrote:
> I use a board with MPC866T and 2.6.28 Linux Kernel. Occasionally, the
> unflattened device is corrupted after “unflatten_device_tree()” which
> causes crash of kernel when device tree is traversed later on.
>
> I looked at the fixes in lib/lmb.c, arch/powerpc/mm,
> arch/powerpc/kernel etc since 2.6.28 to 2.6.32-r4 (the most recent
> version) and could not fix my problem.
>
> I have had a hard time trying to determine the cause.
>
> arch/powerpc/kernel/setup_32.c
>
> void __init setup_arch(char **cmdline_p)
>
> {
>
> *cmdline_p = cmd_line;
>
> /* so udelay does something sensible, assume <= 1000 bogomips
> */
>
> loops_per_jiffy = 500000000 / HZ;
>
> unflatten_device_tree();
>
> /* UNFLATTENED DEVICE TREE IS CORRUPTED SOMETIMES HERE */
_In what way_ is it corrupted? Bad tree structure? Bogus node/property
values, names etc.
cheers
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Linux for MPC5554 or MPC5534 (core e200z6)?
From: Németh Márton @ 2009-10-20 22:21 UTC (permalink / raw)
To: Grant Likely, linuxppc-dev
Hi Grant,
Hello List,
is there anybody who was successfully run Linux kernel on Freescale MPC5554
[1], [2] or on Freescale MPC5534 [3], [4]? Both of these embedded PowerPC
controllers have the e200z6 core.
Is there anybody who is working with these controllers or with the e200z6 core?
References:
[1] Freescale MPC5554
http://www.freescale.com/webapp/sps/site/prod_summary.jsp?code=MPC5554
[2] MPC5553/MPC5554 Microcontroller Reference Manual
http://www.freescale.com/files/32bit/doc/ref_manual/MPC5553_MPC5554_RM.pdf
[3] Freescale MPC5534
http://www.freescale.com/webapp/sps/site/prod_summary.jsp?code=MPC5534
[4] MPC5534 Microcontroller Reference Manual
http://www.freescale.com/files/32bit/doc/ref_manual/MPC5534RM.pdf
Regards,
Márton Németh
^ permalink raw reply
* Device Tree Corrupted after unflatten_device_tree()
From: Lixin Yao @ 2009-10-20 16:10 UTC (permalink / raw)
To: linuxppc-dev
[-- Attachment #1: Type: text/plain, Size: 848 bytes --]
I use a board with MPC866T and 2.6.28 Linux Kernel. Occasionally, the
unflattened device is corrupted after "unflatten_device_tree()" which
causes crash of kernel when device tree is traversed later on.
I looked at the fixes in lib/lmb.c, arch/powerpc/mm, arch/powerpc/kernel
etc since 2.6.28 to 2.6.32-r4 (the most recent version) and could not
fix my problem.
I have had a hard time trying to determine the cause.
arch/powerpc/kernel/setup_32.c
void __init setup_arch(char **cmdline_p)
{
*cmdline_p = cmd_line;
/* so udelay does something sensible, assume <= 1000 bogomips */
loops_per_jiffy = 500000000 / HZ;
unflatten_device_tree();
/* UNFLATTENED DEVICE TREE IS CORRUPTED SOMETIMES HERE */
check_for_initrd();
......
}
Any ideas?
Thanks.
Lixin Yao
Harris Startex Networks Inc.
RTP, NC, USA
[-- Attachment #2: Type: text/html, Size: 4135 bytes --]
^ permalink raw reply
* Re: [PATCH] * mpc8313erdb.dts: Fixed eTSEC interrupt assignment.
From: Scott Wood @ 2009-10-20 15:56 UTC (permalink / raw)
To: Richard Cochran; +Cc: 'linuxppc-dev@lists.ozlabs.org'
In-Reply-To: <95DC1AA8EC908B48939B72CF375AA5E30E2AECFD@alice.at.omicron.at>
On Tue, Oct 20, 2009 at 12:01:19PM +0200, Richard Cochran wrote:
> > -----Original Message-----
> > From: Scott Wood [mailto:scottwood@freescale.com]
> >
> > What problems have you been having with upstream kernels on mpc8313erdb,
> > other than this IRQ issue? It should work, though the BSP may have extra
> > features that haven't been pushed upstream.
>
> I have been working from kernel 2.6.30 (although the very latest
> kernel is just the same WRT these problems, AFAICT). I had to patch in
> order to sovle the following three problems:
>
> 1. The flash layout in the DTS does not match the default partitioning
> from Freescale. In the current dts, the NAND partitioning is wrong,
> and there is no partitioning for the NOR flash given.
OK, I wasn't aware of that -- that kind of thing is an artifact of the BSP
development process being fairly separate from upstream development. The
"open source team" works on upstream Linux and upstream U-Boot. We don't
run the BSP u-boot (since we're developing the newer u-boot), and it's easy
to miss when things like this diverge.
In this case, I'd be surprised if the NAND partitioning that is upstream
came from anywhere but an early BSP's Linux tree. There's not much we (the
upstream-focused developers) can do if different BSPs have different layouts
(other than not specify a layout at all)... What is the layout you see in
your BSP?
> 2. The eTSEC interrupt issue that started this thread.
Well, yes. :-)
> 3. The PTP IO signals are not configured in a vanilla linux. For this,
> you need parts of a Freescale patch. [1] Their PTP implementation
> gianfar driver is horrible, but still, the IO configuration in
> these two files in the patch is necessary to get any external
> signals from the PTP clock:
>
> arch/powerpc/platforms/83xx/mpc8313_rdb.c
> arch/powerpc/platforms/83xx/mpc83xx.h
Yes, this is one of those features that is currently BSP-only (partly due to
it needing work, as you note above). That's different than the board simply
not being supported upstream, but if you need it, you need it. I'll raise
the issue in my team, but I suggest also letting Freescale support (or other
official feedback channels) know what you'd like to see in terms of
improvements in that code and getting it upstream.
-Scott
^ permalink raw reply
* Re: UBIFS problem on MPC8536DS
From: Felix Radensky @ 2009-10-20 15:30 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc-dev@ozlabs.org, linux-mtd@lists.infradead.org
In-Reply-To: <4ADCC247.6080107@freescale.com>
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.
>
OK, I have NOR and NAND synchronized properly now.
Thanks a lot for your help.
Felix.
^ permalink raw reply
* Re: [PATCH] BUILD_BUG_ON: make it handle more cases
From: Alan Jenkins @ 2009-10-20 14:43 UTC (permalink / raw)
To: Américo Wang
Cc: sfr, Hollis Blanchard, Rusty Russell, linux-kernel, Jan Beulich,
linux-next, kvm-ppc, akpm, linuxppc-dev
In-Reply-To: <20091020135835.GB2462@hack>
On 10/20/09, Am=E9rico Wang <xiyou.wangcong@gmail.com> wrote:
> On Tue, Oct 20, 2009 at 02:15:33PM +1030, Rusty Russell wrote:
>>BUILD_BUG_ON used to use the optimizer to do code elimination or fail
>>at link time; it was changed to first the size of a negative array (a
>>nicer compile time error), then (in
>>8c87df457cb58fe75b9b893007917cf8095660a0) to a bitfield.
>>
>>bitfields: needs a literal constant at parse time, and can't be put under
>> "if (__builtin_constant_p(x))" for example.
>>negative array: can handle anything, but if the compiler can't tell it's
>> a constant, silently has no effect.
>>link time: breaks link if the compiler can't determine the value, but the
>> linker output is not usually as informative as a compiler error.
>>
>>If we use the negative-array-size method *and* the link time trick,
>>we get the ability to use BUILD_BUG_ON() under __builtin_constant_p()
>>branches, and maximal ability for the compiler to detect errors at
>>build time.
>>
>>Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
>>
>>diff --git a/include/linux/kernel.h b/include/linux/kernel.h
>>--- a/include/linux/kernel.h
>>+++ b/include/linux/kernel.h
>>@@ -683,12 +683,6 @@ 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
>>@@ -696,6 +690,33 @@ struct sysinfo {
>> #define BUILD_BUG_ON_ZERO(e) (sizeof(struct { int:-!!(e); }))
>> #define BUILD_BUG_ON_NULL(e) ((void *)sizeof(struct { int:-!!(e); }))
>>
>>+/**
>>+ * 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 t=
o
>>+ * 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 message can be harder to track
>> down
>>+ * though, hence the two different methods.
>>+ */
>>+#ifndef __OPTIMIZE__
>>+#define BUILD_BUG_ON(condition) ((void)sizeof(char[1 - 2*!!(condition)])=
)
>>+#else
>>+extern int __build_bug_on_failed;
>
> Hmm, what exactly is __build_bug_on_failed?
Well, we haven't added a definition for it in this patch. I'm sure
grep will tell you it wasn't defined before hand either. So any
reference to it is an error - which will be reported at link time.
>>+#define BUILD_BUG_ON(condition) \
>>+ do { \
>>+ ((void)sizeof(char[1 - 2*!!(condition)])); \
>>+ if (condition) __build_bug_on_failed =3D 1; \
If "condition" is known false at compile time, gcc -O will eliminate
the code which refers to __build_bug_on_failed. If it's not proved to
be false - it will break the build, which is exactly what we want
BUILD_BUG_ON to do.
>>+ } while(0)
>>+#endif
>>+#define MAYBE_BUILD_BUG_ON(condition) BUILD_BUG_ON(condition)
>>+
>> /* Trap pasters of __FUNCTION__ at compile-time */
>> #define __FUNCTION__ (__func__)
>>
^ permalink raw reply
* bus error exception handler not working
From: Norbert van Bolhuis @ 2009-10-20 14:20 UTC (permalink / raw)
To: linuxppc-dev@ozlabs.org >> "linuxppc-dev@ozlabs.org"
reading a bogus address in u-boot gives:
=> md 0x88000000
88000000:Machine check in kernel mode.
Caused by (from msr): regs 0ff0ec28 Unknown values in msr
NIP: 0000111C XER: 2000005F LR: 0FFDB104 REGS: 0ff0ec28 TRAP: 0200 DAR: 00000000
MSR: 00001000 EE: 0 PR: 0 FP: 0 ME: 1 IR/DR: 00
GPR00: 0FFDB104 0FF0ED18 0FF0EF48 0FFE9DAC 00000002 00000010 FFFFFFFF 00000030
GPR08: 00000001 00000020 00000000 00000009 0FF0E828 1001910C 0FFF9000 0FFE9E10
GPR16: 0FFE9DAC 0FFEADF8 0FFEADF0 0FFEDCE4 48024028 8800002B 88000000 88000000
GPR24: 0FF0ED20 00000040 00000000 00000004 0FF0ED20 00000004 0FFFA650 88000000
Call backtrace:
0FFDB104 0FFC67B4 0FFCF668 0FFCED70 0FFCEEE0 0FFD1AA8 0FFB5FF4
0FFB2644
machine check
Resetting the board.
U-Boot 2008.10 (Oct 16 2009 - 14:57:46) MPC83XX, version=0x00910161
Reset Status: Software Hard, External/Internal Soft, External/Internal Hard
doing the same in linux kernel gives an immediate reboot (checkstop):
# readmm 32 88000000 1
U-Boot 2008.10 (Oct 16 2009 - 14:57:46) MPC83XX, version=0x00910161
Reset Status: Check Stop, External/Internal Soft, External/Internal Hard
We're using an MPC8313E on a custom board (similar to MPC8313E-RDB) with
U-Boot v2008.10 and linux 2.6.28.
The problem is that the linux kernel exception handler (arch/powerpc/kernel/head_32.S)
doesn't work. It looks like this:
. = 0x200
0x200 mtspr SPRN_SPRG0,r10
mtspr SPRN_SPRG1,r11
mfcr r10
#define EXCEPTION_PROLOG_1 \
0x20c mfspr r11,SPRN_SRR1; /* check whether user or kernel */ \
andi. r11,r11,MSR_PR; \
tophys(r11,r1); /* use tophys(r1) if kernel */ \
beq 1f; \
mfspr r11,SPRN_SPRG3; \
lwz r11,THREAD_INFO-THREAD(r11); \
addi r11,r11,THREAD_SIZE; \
tophys(r11,r11); \
1: subi r11,r11,INT_FRAME_SIZE /* alloc exc. frame */
#define EXCEPTION_PROLOG_2 \
CLR_TOP32(r11); \
0x230 stw r10,_CCR(r11); /* save registers */ \
stw r12,GPR12(r11); \
stw r9,GPR9(r11); \
mfspr r10,SPRN_SPRG0; \
stw r10,GPR10(r11); \
mfspr r12,SPRN_SPRG1; \
stw r12,GPR11(r11); \
mflr r10; \
stw r10,_LINK(r11); \
mfspr r12,SPRN_SRR0; \
mfspr r9,SPRN_SRR1; \
stw r1,GPR1(r11); \
stw r1,0(r11); \
tovirt(r1,r11); /* set new kernel sp */ \
li r10,MSR_KERNEL & ~(MSR_IR|MSR_DR); /* can take exceptions */ \
MTMSRD(r10); /* (except for mach check in rtas) */ \
stw r0,GPR0(r11); \
lis r10,STACK_FRAME_REGS_MARKER@ha; /* exception frame marker */ \
0x278 addi r10,r10,STACK_FRAME_REGS_MARKER@l; \
stw r10,8(r11); \
SAVE_4GPRS(3, r11); \
SAVE_2GPRS(7, r11)
0x298 addi r3,r1,STACK_FRAME_OVERHEAD
EXC_XFER_STD(0x200, machine_check_exception)
0x29c li r10,trap
...
bl machine_check_exception
somehow machine_check_exception isn't reached. can anyone tell me why ?
is there something wrong with EXCEPTION_PROLOG_1/EXCEPTION_PROLOG_2 ?
^ permalink raw reply
* Re: [PATCH] BUILD_BUG_ON: make it handle more cases
From: Américo Wang @ 2009-10-20 13:58 UTC (permalink / raw)
To: Rusty Russell
Cc: sfr, Hollis Blanchard, linux-kernel, kvm-ppc, linux-next,
Jan Beulich, akpm, linuxppc-dev
In-Reply-To: <200910201415.34361.rusty@rustcorp.com.au>
On Tue, Oct 20, 2009 at 02:15:33PM +1030, Rusty Russell wrote:
>BUILD_BUG_ON used to use the optimizer to do code elimination or fail
>at link time; it was changed to first the size of a negative array (a
>nicer compile time error), then (in
>8c87df457cb58fe75b9b893007917cf8095660a0) to a bitfield.
>
>bitfields: needs a literal constant at parse time, and can't be put under
> "if (__builtin_constant_p(x))" for example.
>negative array: can handle anything, but if the compiler can't tell it's
> a constant, silently has no effect.
>link time: breaks link if the compiler can't determine the value, but the
> linker output is not usually as informative as a compiler error.
>
>If we use the negative-array-size method *and* the link time trick,
>we get the ability to use BUILD_BUG_ON() under __builtin_constant_p()
>branches, and maximal ability for the compiler to detect errors at
>build time.
>
>Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
>
>diff --git a/include/linux/kernel.h b/include/linux/kernel.h
>--- a/include/linux/kernel.h
>+++ b/include/linux/kernel.h
>@@ -683,12 +683,6 @@ 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
>@@ -696,6 +690,33 @@ struct sysinfo {
> #define BUILD_BUG_ON_ZERO(e) (sizeof(struct { int:-!!(e); }))
> #define BUILD_BUG_ON_NULL(e) ((void *)sizeof(struct { int:-!!(e); }))
>
>+/**
>+ * 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 message can be harder to track down
>+ * though, hence the two different methods.
>+ */
>+#ifndef __OPTIMIZE__
>+#define BUILD_BUG_ON(condition) ((void)sizeof(char[1 - 2*!!(condition)]))
>+#else
>+extern int __build_bug_on_failed;
Hmm, what exactly is __build_bug_on_failed?
>+#define BUILD_BUG_ON(condition) \
>+ do { \
>+ ((void)sizeof(char[1 - 2*!!(condition)])); \
>+ if (condition) __build_bug_on_failed = 1; \
>+ } while(0)
>+#endif
>+#define MAYBE_BUILD_BUG_ON(condition) BUILD_BUG_ON(condition)
>+
> /* Trap pasters of __FUNCTION__ at compile-time */
> #define __FUNCTION__ (__func__)
>
>--
>To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
>the body of a message to majordomo@vger.kernel.org
>More majordomo info at http://vger.kernel.org/majordomo-info.html
>Please read the FAQ at http://www.tux.org/lkml/
--
Live like a child, think like the god.
^ permalink raw reply
* RE: [PATCH v0 1/2] DMA: fsldma: Disable DMA_INTERRUPT when Async_tx enabled
From: Suresh Vishnu-B05022 @ 2009-10-20 13:09 UTC (permalink / raw)
To: Ira W. Snyder, Dan Williams
Cc: herbert, linux-kernel, linux-raid, linuxppc-dev, linux-crypto,
Tabi Timur-B04825
In-Reply-To: <20091016153334.GA27401@ovro.caltech.edu>
> -----Original Message-----
> From: Ira W. Snyder [mailto:iws@ovro.caltech.edu]=20
> Sent: Friday, October 16, 2009 9:04 PM
> To: Dan Williams
> Cc: Suresh Vishnu-B05022; herbert@gondor.apana.org.au;=20
> linux-kernel@vger.kernel.org; linux-raid@vger.kernel.org;=20
> linuxppc-dev@ozlabs.org; linux-crypto@vger.kernel.org; Tabi=20
> Timur-B04825
> Subject: Re: [PATCH v0 1/2] DMA: fsldma: Disable=20
> DMA_INTERRUPT when Async_tx enabled
>=20
> On Thu, Oct 15, 2009 at 06:25:14PM -0700, Dan Williams wrote:
> > [ added Leo and Timur to the Cc ]
> >=20
> > On Wed, Oct 14, 2009 at 11:41 PM, Vishnu Suresh=20
> <Vishnu@freescale.com> wrote:
> > > This patch disables the use of DMA_INTERRUPT capability with=20
> > > Async_tx
> > >
> > > The fsldma produces a null transfer with DMA_INTERRUPT capability=20
> > > when used with Async_tx. When RAID devices queue a=20
> transaction via=20
> > > Async_tx, this =A0results in a hang.
> > >
> > > Signed-off-by: Vishnu Suresh <Vishnu@freescale.com>
> > > ---
> > > =A0drivers/dma/fsldma.c | =A0 =A06 ++++++
> > > =A01 files changed, 6 insertions(+), 0 deletions(-)
> > >
> > > diff --git a/drivers/dma/fsldma.c b/drivers/dma/fsldma.c index=20
> > > 296f9e7..66d9b39 100644
> > > --- a/drivers/dma/fsldma.c
> > > +++ b/drivers/dma/fsldma.c
> > > @@ -1200,7 +1200,13 @@ static int __devinit=20
> of_fsl_dma_probe(struct=20
> > > of_device *dev,
> > > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0-=20
> fdev->reg.start +=20
> > > 1);
> > >
> > > =A0 =A0 =A0 =A0dma_cap_set(DMA_MEMCPY, fdev->common.cap_mask);
> > > +#ifndef CONFIG_ASYNC_CORE
> > > + =A0 =A0 =A0 /*
> > > + =A0 =A0 =A0 =A0* The DMA_INTERRUPT async_tx is a NULL transfer,=20
> which will
> > > + =A0 =A0 =A0 =A0* triger a PE interrupt.
> > > + =A0 =A0 =A0 =A0*/
> > > =A0 =A0 =A0 =A0dma_cap_set(DMA_INTERRUPT, fdev->common.cap_mask);
> > > +#endif
> > > =A0 =A0 =A0 =A0dma_cap_set(DMA_SLAVE, fdev->common.cap_mask);
> > > =A0 =A0 =A0 =A0fdev->common.device_alloc_chan_resources =3D=20
> > > fsl_dma_alloc_chan_resources;
> > > =A0 =A0 =A0 =A0fdev->common.device_free_chan_resources =3D=20
> > > fsl_dma_free_chan_resources;
> >=20
> > You are basically saying that fsl_dma_prep_interrupt() is=20
> buggy. Can=20
> > that routine be fixed rather than this piecemeal solution? If it=20
> > cannot be fixed (i.e. hardware issue) then fsl_dma_prep_interrupt()=20
> > should just be disabled/deleted altogether.
We are working to fix this issue.
> >=20
>=20
> For what it's worth, I've used the following code in the=20
> recent past, without any issues. This was on an 83xx, within=20
> the last few kernel releases. I haven't tried it on the latest -rc.
This works fine as long as only DMA_MEMCPY is being used.
The async_tx_channel_switch does not occur and the=20
device_prep_dma_interrupt is not called.=20
However, when a DMA_XOR capable device is exposed,=20
which is differnet from the DMA_MEMCPY/INTERRUPT device, this path is =
hit.
Is it proper to schedule a dma_interrupt from the channel switch call,=20
even when the depend_tx and tx channels correspond to different devices?
>=20
> Using device_prep_dma_memcpy() can trigger a callback as=20
> well, so the interrupt feature isn't strictly needed. Just=20
> attach the callback to the last memcpy operation.
>=20
> static dma_cookie_t dma_async_interrupt(struct dma_chan *chan,
> dma_async_tx_callback=20
> callback,
> void *data) {
> struct dma_device *dev =3D chan->device;
> struct dma_async_tx_descriptor *tx;=20
>=20
> /* Set up the DMA */
> tx =3D dev->device_prep_dma_interrupt(chan, =
DMA_PREP_INTERRUPT);
> if (!tx)
> return -ENOMEM;
>=20
> tx->callback =3D callback;
> tx->callback_param =3D data;
>=20
> return tx->tx_submit(tx);
> }
>=20
> Ira
>=20
>=20
^ permalink raw reply
* RE: [PATCH] * mpc8313erdb.dts: Fixed eTSEC interrupt assignment.
From: Richard Cochran @ 2009-10-20 10:01 UTC (permalink / raw)
To: 'Scott Wood'; +Cc: 'linuxppc-dev@lists.ozlabs.org'
In-Reply-To: <20091016160125.GC11838@loki.buserror.net>
> -----Original Message-----
> From: Scott Wood [mailto:scottwood@freescale.com]
>
> What problems have you been having with upstream kernels on mpc8313erdb,
> other than this IRQ issue? It should work, though the BSP may have extra
> features that haven't been pushed upstream.
I have been working from kernel 2.6.30 (although the very latest
kernel is just the same WRT these problems, AFAICT). I had to patch in
order to sovle the following three problems:
1. The flash layout in the DTS does not match the default partitioning
from Freescale. In the current dts, the NAND partitioning is wrong,
and there is no partitioning for the NOR flash given.
2. The eTSEC interrupt issue that started this thread.
3. The PTP IO signals are not configured in a vanilla linux. For this,
you need parts of a Freescale patch. [1] Their PTP implementation
gianfar driver is horrible, but still, the IO configuration in
these two files in the patch is necessary to get any external
signals from the PTP clock:
arch/powerpc/platforms/83xx/mpc8313_rdb.c
arch/powerpc/platforms/83xx/mpc83xx.h
It may be that point 1 is not so important, since the flash layout is
perhaps a very personal thing, but I would still expect the default
dts to match the default partitioning from Freescale.
Point 2 is obviously essential, and if you buy the mpc8313 for its PTP
capabilities, as I did, then point 3 is a show stopper, as well.
> I just booted 2.6.32-rc4 straight from Linus on an mpc8572ds yesterday.
> I've booted various upstream kernels on mpc8313erdb (typically an older r=
ev,
> though).
Okay, you are right, the mpc8572ds does seem to work pretty well.
Perhaps we can fix up the above three issues?
Richard
[1] http://www.bitshrine.org/gpp_info/linux-fsl-2.6.23-MPC8313ERDB-IEEE-158=
8.patch.html
^ permalink raw reply
* Re: [PATCH 3/3] powerpc: perf_event: Hide iseries_check_pending_irqs
From: Benjamin Herrenschmidt @ 2009-10-20 4:12 UTC (permalink / raw)
To: Anton Blanchard; +Cc: linuxppc-dev, Ingo Molnar, paulus, a.p.zijlstra
In-Reply-To: <20091020035058.GU4808@kryten>
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.
^ permalink raw reply
* Re: [PATCH 3/3] powerpc: perf_event: Hide iseries_check_pending_irqs
From: Anton Blanchard @ 2009-10-20 3:50 UTC (permalink / raw)
To: Ingo Molnar; +Cc: paulus, a.p.zijlstra, linuxppc-dev
In-Reply-To: <20091019072334.GA17960@elte.hu>
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
^ permalink raw reply
* [PATCH] BUILD_BUG_ON: make it handle more cases
From: Rusty Russell @ 2009-10-20 3:45 UTC (permalink / raw)
To: Hollis Blanchard
Cc: sfr, linux-kernel, kvm-ppc, linux-next, Jan Beulich, akpm,
linuxppc-dev
In-Reply-To: <1256002193.6546.2.camel@slab>
BUILD_BUG_ON used to use the optimizer to do code elimination or fail
at link time; it was changed to first the size of a negative array (a
nicer compile time error), then (in
8c87df457cb58fe75b9b893007917cf8095660a0) to a bitfield.
bitfields: needs a literal constant at parse time, and can't be put under
"if (__builtin_constant_p(x))" for example.
negative array: can handle anything, but if the compiler can't tell it's
a constant, silently has no effect.
link time: breaks link if the compiler can't determine the value, but the
linker output is not usually as informative as a compiler error.
If we use the negative-array-size method *and* the link time trick,
we get the ability to use BUILD_BUG_ON() under __builtin_constant_p()
branches, and maximal ability for the compiler to detect errors at
build time.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
diff --git a/include/linux/kernel.h b/include/linux/kernel.h
--- a/include/linux/kernel.h
+++ b/include/linux/kernel.h
@@ -683,12 +683,6 @@ 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
@@ -696,6 +690,33 @@ struct sysinfo {
#define BUILD_BUG_ON_ZERO(e) (sizeof(struct { int:-!!(e); }))
#define BUILD_BUG_ON_NULL(e) ((void *)sizeof(struct { int:-!!(e); }))
+/**
+ * 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 message can be harder to track down
+ * though, hence the two different methods.
+ */
+#ifndef __OPTIMIZE__
+#define BUILD_BUG_ON(condition) ((void)sizeof(char[1 - 2*!!(condition)]))
+#else
+extern int __build_bug_on_failed;
+#define BUILD_BUG_ON(condition) \
+ do { \
+ ((void)sizeof(char[1 - 2*!!(condition)])); \
+ if (condition) __build_bug_on_failed = 1; \
+ } while(0)
+#endif
+#define MAYBE_BUILD_BUG_ON(condition) BUILD_BUG_ON(condition)
+
/* Trap pasters of __FUNCTION__ at compile-time */
#define __FUNCTION__ (__func__)
^ permalink raw reply
* Re: linux-next: tree build failure
From: Hollis Blanchard @ 2009-10-20 1:29 UTC (permalink / raw)
To: Rusty Russell
Cc: sfr, linux-kernel, kvm-ppc, linux-next, Jan Beulich, akpm,
linuxppc-dev
In-Reply-To: <200910201142.34006.rusty@rustcorp.com.au>
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
^ permalink raw reply
* Re: linux-next: tree build failure
From: Rusty Russell @ 2009-10-20 1:12 UTC (permalink / raw)
To: Hollis Blanchard
Cc: sfr, linux-kernel, kvm-ppc, linux-next, Jan Beulich, akpm,
linuxppc-dev
In-Reply-To: <1255976369.13995.98.camel@slab.beaverton.ibm.com>
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.
*/
Thanks!
Rusty.
^ permalink raw reply
* Re: UBIFS problem on MPC8536DS
From: Felix Radensky @ 2009-10-19 20:19 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc-dev@ozlabs.org, linux-mtd@lists.infradead.org
In-Reply-To: <4ADCC247.6080107@freescale.com>
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.
^ permalink raw reply
* Re: UBIFS problem on MPC8536DS
From: Scott Wood @ 2009-10-19 19:47 UTC (permalink / raw)
To: Felix Radensky; +Cc: linuxppc-dev@ozlabs.org, linux-mtd@lists.infradead.org
In-Reply-To: <4ADCC08D.5080207@embedded-sol.com>
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
^ permalink raw reply
* Re: UBIFS problem on MPC8536DS
From: Felix Radensky @ 2009-10-19 19:39 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc-dev@ozlabs.org, linux-mtd@lists.infradead.org
In-Reply-To: <20091019154002.GC19074@loki.buserror.net>
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.
^ permalink raw reply
* [PATCH] [RFC] PowerPC64: Use preempt_schedule_irq instead of preempt_schedule when returning from exceptions
From: Valentine Barshak @ 2009-10-19 18:28 UTC (permalink / raw)
To: linuxppc-dev; +Cc: olof, paulus
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 <vbarshak@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.000000000 +0400
+++ linux-2.6.new/arch/powerpc/kernel/entry_64.S 2009-10-19 17:35:16.000000000 +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
^ permalink raw reply
* Re: linux-next: tree build failure
From: Hollis Blanchard @ 2009-10-19 18:19 UTC (permalink / raw)
To: Jan Beulich
Cc: sfr, Rusty Russell, linux-kernel, kvm-ppc, linux-next, akpm,
linuxppc-dev
In-Reply-To: <4AD6EB17020000780001A050@vpn.id2.novell.com>
On Thu, 2009-10-15 at 08:27 +0100, Jan Beulich wrote:
> >>> Hollis Blanchard <hollisb@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
^ permalink raw reply
* Re: [PATCH] powerpc: tracing: Add powerpc tracepoints for interrupt entry and exit
From: Steven Rostedt @ 2009-10-19 17:00 UTC (permalink / raw)
To: Anton Blanchard; +Cc: Ingo Molnar, linuxppc-dev, Frederic Weisbecker
In-Reply-To: <20091018110109.GJ4808@kryten>
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=c0000000ce31fb10
> <idle>-0 [006] 3243.949850520: irq_exit: pt_regs=c0000000ce31fb10
>
> <idle>-0 [007] 3243.950218208: irq_entry: pt_regs=c0000000ce323b10
> <idle>-0 [007] 3243.950224080: irq_exit: pt_regs=c0000000ce323b10
>
> <idle>-0 [000] 3244.021879320: irq_entry: pt_regs=c000000000a63aa0
> <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=c000000000a63aa0
>
> 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 <anton@samba.org>
> --
I'm fine with the name "powerpc".
Acked-by: Steven Rostedt <rostedt@goodmis.org>
^ permalink raw reply
* [PATCH 1/1] powerpc: Add kdump support to Collaborative Memory Manager
From: Brian King @ 2009-10-19 15:51 UTC (permalink / raw)
To: benh; +Cc: brking, linuxppc-dev
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 <brking@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.000000000 -0500
+++ linux-2.6-bjking1/arch/powerpc/platforms/pseries/cmm.c 2009-09-25 10:24:19.000000000 -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.000000000 -0500
+++ linux-2.6-bjking1/arch/powerpc/platforms/pseries/Kconfig 2009-09-24 16:35:00.000000000 -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
_
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox