[RFC] MPIC Bindings and Bindings for AMP Systems
Hi All,
I am currently doing some work on Linux PPC AMP systems (with Hollis,
CC'd). We are using device trees to partition resources between the
different OSes. To help with this effort, we would like to introduce
some new bindings to the MPIC.
Currently, there are no bindings for the MPIC under
'.../Documentation/powerpc/dts-bindings/'. I think most folks are
following the IEEE 1275 bindings for Open PIC.
It would be nice to check-in a binding for the MPIC that is a superset
of the 1275 bindings as a place to document extensions. The already in
use property 'protected-sources', for example, could be placed there.
I have included a draft proposal of what this would like. It includes
some properties ('no-reset') and a node (for message registers) that we
are currently using for our AMP implementation and we would really
like to push upstream. If the general idea seems sound, then I will
clean up the proposal and submit a patch for the bindings.
Thoughts?
* MPIC Binding
This binding specifies what properties and child nodes must be available
on the device tree representation of the MPIC interrupt
controller. This binding is a superset of the binding defined for Open
PIC in [1].
** Required properties:
- All of the required properties mentioned in [1].
** Optional properties:
- no-reset : the presence of this property indicates that the
interrupt controller should not be reset during OS
initialization.
- protected-sources : a list of interrupt sources that are not
available for use.
** Example:
mpic: p...@4 {
interrupt-controller;
#address-cells = 0;
#interrupt-cells = 2;
reg = 0x4 0x4;
compatible = chrp,open-pic;
device_type = open-pic;
protected-sources = 0xb1 0xb2;
no-reset;
};
* MPIC Message Registers
This binding specifies how the MPIC message registers implemented on
some Freescale platforms for interprocessor communication should be
represented.
** Required parent:
- Message register nodes should always been nested under a MPIC
node.
** Required properties:
- compatible : compatible list, contains 2 entries, first is
fsl,CHIP-msgr, where CHIP is the processor
(p2020, mpc8572, etc ...) and the second is
fsl,mpic-msgr.
- reg: should contain the address and the length of the
message register block.
- cell-index : the index of the message register block.
- interrupts : each one of the interrupts here represents the
interrupt line for one message register. These
interrupts are routed internally to the MPIC.
NOTE: The 'interrupt-parent' is implicit since message register nodes
are always children of interrupt controller nodes.
** Example:
mpic: p...@4 {
interrupt-controller;
#address-cells = 0;
#interrupt-cells = 2;
reg = 0x4 0x4;
compatible = chrp,open-pic;
device_type = open-pic;
protected-sources = 0xb1;
m...@1400 {
compatible = fsl,p2020-msgr, fsl,mpic-msgr;
reg = 0x1400 0x200;
cell-index = 0;
interrupts = 0xb0 0x2 0xb1 0x2
0xb2 0x2 0xb3 0x2;
};
m...@2400 {
compatible = fsl,p2020-msgr, fsl,mpic-msgr;
reg = 0x2400 0x200;
cell-index = 1;
interrupts = 0xb4 0x2 0xb5 0x2
0xb6 0x2 0xb7 0x2;
};
};
* References
[1] PowerPC Microprocessor Common Hardware Reference Platform (CHRP)
Binding, Version 1.8, 1998. Published by the Open Firmware Working
Group. (http://playground.sun.com/1275/bindings/chrp/chrp1_8a.ps)
--
Meador Inge | meador_inge AT mentor.com
Mentor Embedded | http://www.mentor.com/embedded-software
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[RFC] MPIC Bindings and Bindings for AMP Systems
Hi All,
I am currently doing some work on Linux PPC AMP systems (with Hollis,
CC'd). We are using device trees to partition resources between the
different OSes. To help with this effort, we would like to introduce
some new bindings to the MPIC.
Currently, there are no bindings for the MPIC under
'.../Documentation/powerpc/dts-bindings/'. I think most folks are
following the IEEE 1275 bindings for Open PIC.
It would be nice to check-in a binding for the MPIC that is a superset
of the 1275 bindings as a place to document extensions. The already in
use property 'protected-sources', for example, could be placed there.
I have included a draft proposal of what this would like. It includes
some properties ('no-reset') and a node (for message registers) that we
are currently using for our AMP implementation and we would really
like to push upstream. If the general idea seems sound, then I will
clean up the proposal and submit a patch for the bindings.
Thoughts?
===
* MPIC Binding
This binding specifies what properties and child nodes must be available
on the device tree representation of the MPIC interrupt
controller. This binding is a superset of the binding defined for Open
PIC in [1].
** Required properties:
- All of the required properties mentioned in [1].
** Optional properties:
- no-reset : the presence of this property indicates that the
interrupt controller should not be reset during OS
initialization.
- protected-sources : a list of interrupt sources that are not
available for use.
** Example:
mpic: p...@4 {
interrupt-controller;
#address-cells = 0;
#interrupt-cells = 2;
reg = 0x4 0x4;
compatible = chrp,open-pic;
device_type = open-pic;
protected-sources = 0xb1 0xb2;
no-reset;
};
* MPIC Message Registers
This binding specifies how the MPIC message registers implemented on
some Freescale platforms for interprocessor communication should be
represented.
** Required parent:
- Message register nodes should always been nested under a MPIC
node.
** Required properties:
- compatible : compatible list, contains 2 entries, first is
fsl,CHIP-msgr, where CHIP is the processor
(p2020, mpc8572, etc ...) and the second is
fsl,mpic-msgr.
- reg: should contain the address and the length of the
message register block.
- cell-index : the index of the message register block.
- interrupts : each one of the interrupts here represents the
interrupt line for one message register. These
interrupts are routed internally to the MPIC.
NOTE: The 'interrupt-parent' is implicit since message register nodes
are always children of interrupt controller nodes.
** Example:
mpic: p...@4 {
interrupt-controller;
#address-cells = 0;
#interrupt-cells = 2;
reg = 0x4 0x4;
compatible = chrp,open-pic;
device_type = open-pic;
protected-sources = 0xb1;
m...@1400 {
compatible = fsl,p2020-msgr, fsl,mpic-msgr;
reg = 0x1400 0x200;
cell-index = 0;
interrupts = 0xb0 0x2 0xb1 0x2
0xb2 0x2 0xb3 0x2;
};
m...@2400 {
compatible = fsl,p2020-msgr, fsl,mpic-msgr;
reg = 0x2400 0x200;
cell-index = 1;
interrupts = 0xb4 0x2 0xb5 0x2
0xb6 0x2 0xb7 0x2;
};
};
* References
[1] PowerPC Microprocessor Common Hardware Reference Platform (CHRP)
Binding, Version 1.8, 1998. Published by the Open Firmware Working
Group. (http://playground.sun.com/1275/bindings/chrp/chrp1_8a.ps)
--
Meador Inge | meador_inge AT mentor.com
Mentor Embedded | http://www.mentor.com/embedded-software
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [Cbe-oss-dev] [RFC 0/3] powerpc: memory copy routines tweaked for Cell
Sorry, I was send wrong files.
I send my three files again.
#include stdlib.h
#include stdio.h
#include ppu_intrinsics.h
extern void *memcpy(void *, const void *, size_t);
int main() {
unsigned char *s, *d;
register unsigned long long start, finish, i;
if(posix_memalign((void *)s, 128, 16384)) {
printf(failed\n);
goto end;
}
for(i = 128, j = 0; i 0; i--, j += 128) { /* clear s from
cache */
__dcbf(s+j);
}
if(posix_memalign((void *)d, 128, 16384)) {
printf(failed\n);
goto end;
}
for(i = 128, j = 0; i 0; i--, j += 128) { /* clear d from
cache */
__dcbf(s+j);
}
__dcbt(memcpy); /* prefetch memcpy */
__dcbt(memcpy+128);
__dcbt(memcpy+256);
__dcbt(memcpy+384);
__dcbt(memcpy+512);
__dcbt(memcpy+640);
__dcbt(memcpy+768);
__dcbt(memcpy+896);
__dcbt(memcpy+1024);
__dcbt(memcpy+1152);
__dcbt(memcpy+1280);
__dcbt(memcpy+1408);
__dcbt(memcpy+1536);
__dcbt(memcpy+1664);
__dcbt(memcpy+1792);
__dcbt(memcpy+1920);
__dcbt(memcpy+2048);
__dcbt(memcpy+2176);
__dcbt(memcpy+2304);
__dcbt(memcpy+2432);
__sync();
start = __mftb();
memcpy(d, s, 4096);
finish = __mftb();
printf(%lld\n, finish - start);
free(s);
free(d);
end:
return 0;
}
#include stdlib.h
#include stdio.h
#include ppu_intrinsics.h
extern void *memcpy(void *, const void *, size_t);
int main() {
unsigned char *s, *d;
register unsigned long long start, finish, i;
if(posix_memalign((void *)s, 128, 4096)) {
printf(failed\n);
goto end;
}
for(i = 32, j = 0; i 0; i--, j += 128) { /* clear s from
cache */
__dcbf(s+j);
}
if(posix_memalign((void *)d, 128, 4096)) {
printf(failed\n);
goto end;
}
for(i = 32, j = 0; i 0; i--, j += 128) { /* clear d from
cache */
__dcbf(s+j);
}
__dcbt(cpymem); /* prefetch memcpy */
__dcbt(cpymem+128);
__dcbt(cpymem+256);
__dcbt(cpymem+384);
__dcbt(cpymem+512);
__dcbt(cpymem+640);
__dcbt(cpymem+768);
__dcbt(cpymem+896);
__dcbt(cpymem+1024);
__dcbt(cpymem+1152);
__dcbt(cpymem+1280);
__dcbt(cpymem+1408);
__dcbt(cpymem+1536);
__dcbt(cpymem+1664);
__dcbt(cpymem+1792);
__dcbt(cpymem+1920);
__dcbt(cpymem+2048);
__dcbt(cpymem+2176);
__dcbt(cpymem+2304);
__dcbt(cpymem+2432);
__sync();
start = __mftb();
memcpy(d, s, 4096);
finish = __mftb();
printf(%lld\n, finish - start);
free(s);
free(d);
end:
return 0;
}
Copy Memory-to-Memory, results are in ticks.
16KB4KB 2KB1KB512B 256B 128B64B
32B 16B
---
main1.C 2063~2466669~879 60~6333~36 22~2419~21
17~21 17~19 15~17 15~16
main2.C110~114 60~6233~36 21~24 19~21
17~18 17~18 15~16 15~16___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [Cbe-oss-dev] [RFC 0/3] powerpc: memory copy routines tweaked for Cell
Hi everyone,
I'm a new Cell BE user, and my debug platform is YDL6.2 run on PS3.
I wrote two simple test programs that tests Mark Nelson's memcpy routines under
a number of conditions, and the test arrays are aligned on 128-byte boundaries.
Following explains my three files.
1. The main1.C is my first test program, it assigns two 16KB arrays.
2. The main2.C is my second test program, it assigns two 4KB arrays.
3. The test_result.TXT is my test result.
Therefore, I have three questions.
1. How to calculate the bandwidth (MB/s)?
2. Is my result or test way correct?
3. Why is the 4KB result different between main1.C and main2.C?
PS: Please use UltraEdit open my three flies.
#include stdlib.h
#include stdio.h
#include ppu_intrinsics.h
extern void *memcpy(void *, const void *, size_t);
int main() {
unsigned char *s, *d;
register unsigned long long start, finish, i;
if(posix_memalign((void *)s, 128, 4096)) {
printf(failed\n);
goto end;
}
for(i = 32, j = 0; i 0; i--, j += 128) { /* clear s from
cache */
__dcbf(s+j);
}
if(posix_memalign((void *)d, 128, 4096)) {
printf(failed\n);
goto end;
}
for(i = 32, j = 0; i 0; i--, j += 128) { /* clear d from
cache */
__dcbf(s+j);
}
__dcbt(cpymem); /* prefetch memcpy */
__dcbt(cpymem+128);
__dcbt(cpymem+256);
__dcbt(cpymem+384);
__dcbt(cpymem+512);
__dcbt(cpymem+640);
__dcbt(cpymem+768);
__dcbt(cpymem+896);
__dcbt(cpymem+1024);
__dcbt(cpymem+1152);
__dcbt(cpymem+1280);
__dcbt(cpymem+1408);
__dcbt(cpymem+1536);
__dcbt(cpymem+1664);
__dcbt(cpymem+1792);
__dcbt(cpymem+1920);
__dcbt(cpymem+2048);
__dcbt(cpymem+2176);
__dcbt(cpymem+2304);
__dcbt(cpymem+2432);
__sync();
start = __mftb();
memcpy(d, s, 4096);
finish = __mftb();
printf(%lld\n, finish - start);
free(s);
free(d);
end:
return 0;
}
Copy Memory-to-Memory, results are in ticks.
16KB4KB 2KB1KB512B 256B 128B64B
32B 16B
---
main1.C 2063~2466 669~879 60~6333~36 22~2419~21
17~21 17~19 15~17 15~16
main2.C110~114 60~62
33~36 21~24 19~21 17~18 17~18 15~16
15~16Copy Memory-to-Memory, results are in ticks.
16KB4KB 2KB1KB512B 256B 128B64B
32B 16B
---
main1.C 2063~2466 669~879 60~6333~36 22~2419~21
17~21 17~19 15~17 15~16
main2.C110~114 60~62
33~36 21~24 19~21 17~18 17~18 15~16
15~16___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [RFC] MPIC Bindings and Bindings for AMP Systems
On Thu, Dec 23, 2010 at 12:51:29AM -0600, Meador Inge wrote:
Hi All,
I am currently doing some work on Linux PPC AMP systems (with Hollis,
CC'd). We are using device trees to partition resources between the
different OSes. To help with this effort, we would like to introduce
some new bindings to the MPIC.
Currently, there are no bindings for the MPIC under
'.../Documentation/powerpc/dts-bindings/'. I think most folks are
following the IEEE 1275 bindings for Open PIC.
It would be nice to check-in a binding for the MPIC that is a superset
of the 1275 bindings as a place to document extensions. The already in
use property 'protected-sources', for example, could be placed there.
I have included a draft proposal of what this would like. It includes
some properties ('no-reset') and a node (for message registers) that we
are currently using for our AMP implementation and we would really
like to push upstream. If the general idea seems sound, then I will
clean up the proposal and submit a patch for the bindings.
Thoughts?
Hi Meador. Comments below.
g.
===
* MPIC Binding
This binding specifies what properties and child nodes must be
available on the device tree representation of the MPIC interrupt
controller. This binding is a superset of the binding defined for
Open PIC in [1].
** Required properties:
- All of the required properties mentioned in [1].
You should probably list them here anyway to aid the reader.
** Optional properties:
- no-reset : the presence of this property indicates that the
interrupt controller should not be reset during OS
initialization.
- protected-sources : a list of interrupt sources that are not
available for use.
What is the use case for the protected-sources property? Wouldn't the
irqs simply not be referenced by any device nodes? Documenting the
reason for this property would be useful here.
** Example:
mpic: p...@4 {
interrupt-controller;
#address-cells = 0;
#interrupt-cells = 2;
reg = 0x4 0x4;
compatible = chrp,open-pic;
device_type = open-pic;
protected-sources = 0xb1 0xb2;
no-reset;
};
* MPIC Message Registers
This binding specifies how the MPIC message registers implemented on
some Freescale platforms for interprocessor communication should be
represented.
** Required parent:
- Message register nodes should always been nested under a MPIC
node.
** Required properties:
- compatible : compatible list, contains 2 entries, first is
fsl,CHIP-msgr, where CHIP is the processor
(p2020, mpc8572, etc ...) and the second is
fsl,mpic-msgr.
I'd rather see the 'generic' value of mpic-msgr omitted and instead
allow new parts to claim compatibility with an older chip. Generic
or wildcard compatible values can be troublesome because the meaning
has a tendency to change over time.
- reg: should contain the address and the length of the
message register block.
- cell-index : the index of the message register block.
? This needs some more explanation. cell-index often gets abused as
a way to enumerate devices. Typically, the address of the device
itself is sufficient to identify the device.
- interrupts : each one of the interrupts here represents the
interrupt line for one message register. These
interrupts are routed internally to the MPIC.
NOTE: The 'interrupt-parent' is implicit since message register nodes
are always children of interrupt controller nodes.
** Example:
mpic: p...@4 {
interrupt-controller;
#address-cells = 0;
#interrupt-cells = 2;
reg = 0x4 0x4;
compatible = chrp,open-pic;
device_type = open-pic;
protected-sources = 0xb1;
m...@1400 {
compatible = fsl,p2020-msgr, fsl,mpic-msgr;
reg = 0x1400 0x200;
Are these registers memory mapped? If so, then the parent node
needs to have a 'ranges' property.
cell-index = 0;
interrupts = 0xb0 0x2 0xb1 0x2
0xb2 0x2 0xb3 0x2;
};
m...@2400 {
compatible = fsl,p2020-msgr, fsl,mpic-msgr;
reg = 0x2400 0x200;
cell-index = 1;
interrupts = 0xb4 0x2 0xb5 0x2
0xb6 0x2 0xb7 0x2;
};
};
* References
[1] PowerPC Microprocessor Common Hardware Reference Platform (CHRP)
Binding, Version 1.8,
Re: [PATCH RESEND 2] mpc52xx: gpt: include fs.h
On Wed, Dec 22, 2010 at 04:42:55PM +0100, Wolfram Sang wrote: Fix build errors like these (from a randconfig and my defconfig for a custom board): src/arch/powerpc/platforms/52xx/mpc52xx_gpt.c:549: error: dereferencing pointer to incomplete type: 1 errors in 1 logs src/arch/powerpc/platforms/52xx/mpc52xx_gpt.c:636: error: implicit declaration of function 'nonseekable_open': 1 errors in 1 logs src/arch/powerpc/platforms/52xx/mpc52xx_gpt.c:657: error: variable 'mpc52xx_wdt_fops' has initializer but incomplete type: 1 errors in 1 logs src/arch/powerpc/platforms/52xx/mpc52xx_gpt.c:658: error: excess elements in struct initializer: 1 errors in 1 logs src/arch/powerpc/platforms/52xx/mpc52xx_gpt.c:658: error: unknown field 'owner' specified in initializer: 1 errors in 1 logs ... Reported-by: Geert Uytterhoeven ge...@linux-m68k.org Signed-off-by: Wolfram Sang w.s...@pengutronix.de Cc: Grant Likely grant.lik...@secretlab.ca Cc: Benjamin Herrenschmidt b...@kernel.crashing.org Cc: Andrew Morton a...@linux-foundation.org Applied, thanks. Sorry for the delay. I got severely snowed under this fall and have only come up for air now. g. --- rc7 is out and we still have this build-failure. Please apply. arch/powerpc/platforms/52xx/mpc52xx_gpt.c |1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/arch/powerpc/platforms/52xx/mpc52xx_gpt.c b/arch/powerpc/platforms/52xx/mpc52xx_gpt.c index fea833e..e0d703c 100644 --- a/arch/powerpc/platforms/52xx/mpc52xx_gpt.c +++ b/arch/powerpc/platforms/52xx/mpc52xx_gpt.c @@ -63,6 +63,7 @@ #include linux/of_gpio.h #include linux/kernel.h #include linux/slab.h +#include linux/fs.h #include linux/watchdog.h #include linux/miscdevice.h #include linux/uaccess.h -- 1.7.2.3 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 1/4] of: Add support for linking device tree blobs into vmlinux
On Wed, Dec 22, 2010 at 11:57:26AM -0800, dirk.brande...@gmail.com wrote: From: Dirk Brandewie dirk.brande...@gmail.com This patch adds support for linking device tree blob(s) into vmlinux. Modifies asm-generic/vmlinux.lds.h to add linking .dtb sections into vmlinux. To maintain compatiblity with the of/fdt driver code platforms MUST copy the blob to a non-init memory location before the kernel frees the .init.* sections in the image. Modifies scripts/Makefile.lib to add a kbuild command to compile DTS files to device tree blobs and a rule to create objects to wrap the blobs for linking. STRUCT_ALIGNMENT is defined in vmlinux.lds.h for use in the rule to create wrapper objects for the dtb in Makefile.lib. The STRUCT_ALIGN() macro in vmlinux.lds.h is modified to use the STRUCT_ALIGNMENT definition. The DTB's are placed on 32 byte boundries to allow parsing the blob with driver/of/fdt.c during early boot without having to copy the blob to get the structure alignment GCC expects. A DTB is linked in by adding the DTB object to the list of objects to be linked into vmlinux in the archtecture specific Makefile using obj-y += foo.dtb.o Signed-off-by: Dirk Brandewie dirk.brande...@gmail.com merged, thanks. g. --- Documentation/kbuild/makefiles.txt | 15 +++ include/asm-generic/vmlinux.lds.h | 13 +++-- scripts/Makefile.lib | 23 +++ 3 files changed, 49 insertions(+), 2 deletions(-) diff --git a/Documentation/kbuild/makefiles.txt b/Documentation/kbuild/makefiles.txt index 0ef00bd..86e3cd0 100644 --- a/Documentation/kbuild/makefiles.txt +++ b/Documentation/kbuild/makefiles.txt @@ -1136,6 +1136,21 @@ When kbuild executes, the following steps are followed (roughly): resulting in the target file being recompiled for no obvious reason. +dtc + Create flattend device tree blob object suitable for linking + into vmlinux. Device tree blobs linked into vmlinux are placed + in an init section in the image. Platform code *must* copy the + blob to non-init memory prior to calling unflatten_device_tree(). + + Example: + #arch/x86/platform/ce4100/Makefile + clean-files := *dtb.S + + DTC_FLAGS := -p 1024 + obj-y += foo.dtb.o + + $(obj)/%.dtb: $(src)/%.dts + $(call cmd,dtc) --- 6.7 Custom kbuild commands diff --git a/include/asm-generic/vmlinux.lds.h b/include/asm-generic/vmlinux.lds.h index bd69d79..05cbad0 100644 --- a/include/asm-generic/vmlinux.lds.h +++ b/include/asm-generic/vmlinux.lds.h @@ -67,7 +67,8 @@ * Align to a 32 byte boundary equal to the * alignment gcc 4.5 uses for a struct */ -#define STRUCT_ALIGN() . = ALIGN(32) +#define STRUCT_ALIGNMENT 32 +#define STRUCT_ALIGN() . = ALIGN(STRUCT_ALIGNMENT) /* The actual configuration determine if the init/exit sections * are handled as text/data or they can be discarded (which @@ -146,6 +147,13 @@ #define TRACE_SYSCALLS() #endif + +#define KERNEL_DTB() \ + STRUCT_ALIGN(); \ + VMLINUX_SYMBOL(__dtb_start) = .;\ + *(.dtb.init.rodata) \ + VMLINUX_SYMBOL(__dtb_end) = .; + /* .data section */ #define DATA_DATA\ *(.data)\ @@ -468,7 +476,8 @@ MCOUNT_REC()\ DEV_DISCARD(init.rodata)\ CPU_DISCARD(init.rodata)\ - MEM_DISCARD(init.rodata) + MEM_DISCARD(init.rodata)\ + KERNEL_DTB() #define INIT_TEXT\ *(.init.text) \ diff --git a/scripts/Makefile.lib b/scripts/Makefile.lib index 4c72c11..7df8eb5 100644 --- a/scripts/Makefile.lib +++ b/scripts/Makefile.lib @@ -200,6 +200,29 @@ quiet_cmd_gzip = GZIP$@ cmd_gzip = (cat $(filter-out FORCE,$^) | gzip -f -9 $@) || \ (rm -f $@ ; false) +# DTC +# --- + +# Generate an assembly file to wrap the output of the device tree compiler +quiet_cmd_dt_S_dtb= DTB$@ +cmd_dt_S_dtb=\ +(\ + echo '\#include asm-generic/vmlinux.lds.h'; \ + echo '.section .dtb.init.rodata,a'; \ + echo '.balign STRUCT_ALIGNMENT';\ + echo '.global __dtb_$(*F)_begin'; \ + echo
Re: [PATCH 1/4] of: Add support for linking device tree blobs into vmlinux
On Thu, Dec 23, 2010 at 07:14:20AM +0100, Geert Uytterhoeven wrote:
2010/12/22 Michal Marek mma...@suse.cz:
On 22.12.2010 20:57, dirk.brande...@gmail.com wrote:
From: Dirk Brandewiedirk.brande...@gmail.com
This patch adds support for linking device tree blob(s) into
vmlinux. Modifies asm-generic/vmlinux.lds.h to add linking
.dtb sections into vmlinux. To maintain compatiblity with the of/fdt
driver code platforms MUST copy the blob to a non-init memory location
before the kernel frees the .init.* sections in the image.
Modifies scripts/Makefile.lib to add a kbuild command to
compile DTS files to device tree blobs and a rule to create objects to
wrap the blobs for linking.
STRUCT_ALIGNMENT is defined in vmlinux.lds.h for use in the rule to
create wrapper objects for the dtb in Makefile.lib. The
STRUCT_ALIGN() macro in vmlinux.lds.h is modified to use the
STRUCT_ALIGNMENT definition.
The DTB's are placed on 32 byte boundries to allow parsing the blob
with driver/of/fdt.c during early boot without having to copy the blob
to get the structure alignment GCC expects.
A DTB is linked in by adding the DTB object to the list of objects to
be linked into vmlinux in the archtecture specific Makefile using
obj-y += foo.dtb.o
Signed-off-by: Dirk Brandewiedirk.brande...@gmail.com
Hi,
you can add
Acked-by: Michal Marek mma...@suse.cz
but I thing this series should go through the tip tree, as your primary
target seems to be x86 and patch 2/4 depends on the ce4100 code that is only
in tip.
If the two lines
+# device tree blob
+obj-$(CONFIG_X86_INTEL_CE) += ce4100.dtb.o
are removed, patch 2/4 no longer depends on the ce4100 code.
The summary and description for that patch don't mention anything
about ce4100 anyway.
I'd like to take this through the dt tree. I'll drop the ce4100 hunk
when I merge it.
g.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 --
ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say programmer or something like
that.
-- Linus Torvalds
___
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: [RFC] MPIC Bindings and Bindings for AMP Systems
On 12/23/2010 12:56 PM, Grant Likely wrote:
Hi Meador. Comments below.
g.
Thanks a lot for the feedback Grant.
You should probably list them here anyway to aid the reader.
Will do.
What is the use case for the protected-sources property? Wouldn't the
irqs simply not be referenced by any device nodes? Documenting the
reason for this property would be useful here.
One use case is the original [1]:
Some HW platforms, such as the new cell blades, requires some
MPIC sources to be left alone by the operating system. This
implements support for a protected-sources property in the
mpic controller node containing a list of source numbers to be
protected against operating system interference.
Our use case is to reserve certain IRQs for certain OSes in an AMP
system. As an example, consider that OS 1 has (simplified for discussion):
mpic: p...@4 {
...
protected-sources = 0xb1;
m...@41400 {
interrupts = 0xb0 2 0xb1 2 0xb2 2 0xb3 2;
};
};
and OS 2 has:
mpic: p...@4 {
...
protected-sources = 0xb0;
m...@41400 {
interrupts = 0xb0 2 0xb1 2 0xb2 2 0xb3 2;
};
};
where OS 1 is sent messages through the message register tied to 0xb0
and OS 2 is sent messages through the message register tied to 0xb1.
We can't just remove the IRQ of the _other_ OS from the 'interrupts'
property in the message node because we need to know the IRQ in order to
talk to the other OS. So, we use protected sources to tell the OS that
an IRQ is not available for its own use, while at the same time keeping
complete information on all the IRQ mappings for the message registers.
I will update the documentation.
I'd rather see the 'generic' value of mpic-msgr omitted and instead
allow new parts to claim compatibility with an older chip. Generic
or wildcard compatible values can be troublesome because the meaning
has a tendency to change over time.
I don't completely see the issue here. Do you have a specific example
of how generic values like this cause problems? How do you see this
working in terms of processing the data? It seems like we are going to
have to be aware of N values instead of 1, which seems worse.
? This needs some more explanation. cell-index often gets abused as
a way to enumerate devices. Typically, the address of the device
itself is sufficient to identify the device.
The message registers typically come in blocks of four memory mapped
registers and may not be in contiguous memory (example [3]). The intent
of 'cell-index' is to put an ordering on the blocks (so, yes,
enumeration). We could order them by address as well I suppose. One
less property to worry about :)
Are these registers memory mapped? If so, then the parent node
needs to have a 'ranges' property.
Yes, they are. I will look into adding that.
[1] commit 7fd7218610600b16f6f0af3f9d9353ba0265c09f,
http://git.kernel.org/?p=linux/kernel/git/stable/linux-2.6.36.y.git;a=commit;h=7fd7218610600b16f6f0af3f9d9353ba0265c09f
[2] Documentation/powerpc/dts-bindings/fsl/msi-pic.txt
[3]
http://cache.freescale.com/files/32bit/doc/ref_manual/MPC8572ERM.pdf?fr=g
--
Meador Inge | meador_inge AT mentor.com
Mentor Embedded | http://www.mentor.com/embedded-software
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 2/4] x86/of: Add building device tree blob(s) into image.
On Wed, Dec 22, 2010 at 11:57:27AM -0800, dirk.brande...@gmail.com wrote: From: Dirk Brandewie dirk.brande...@gmail.com This patch adds linking device tree blob into vmlinux. DTB's are added by adding the blob object name to list of objects to be linked into the image. Signed-off-by: Dirk Brandewie dirk.brande...@gmail.com --- arch/x86/platform/ce4100/Makefile | 10 ++ 1 files changed, 10 insertions(+), 0 deletions(-) diff --git a/arch/x86/platform/ce4100/Makefile b/arch/x86/platform/ce4100/Makefile index 91fc929..e5f3b7b 100644 --- a/arch/x86/platform/ce4100/Makefile +++ b/arch/x86/platform/ce4100/Makefile @@ -1 +1,11 @@ obj-$(CONFIG_X86_INTEL_CE) += ce4100.o +clean-files := *dtb.S + +ifdef CONFIG_X86_OF +### +# device tree blob +obj-$(CONFIG_X86_INTEL_CE) += ce4100.dtb.o + +$(obj)/%.dtb: $(src)/%.dts + $(call cmd,dtc) +endif Skipped for now; will pick up after ce4100 is in mainline since this is a pretty low-risk change. g. -- 1.7.2.3 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 4/4] microblaze/of: Use generic rule to build dtb's
On Wed, Dec 22, 2010 at 11:57:29AM -0800, dirk.brande...@gmail.com wrote: From: Dirk Brandewie dirk.brande...@gmail.com Modify arch/powerpc/boot/Makefile to use dtc command in scripts/Makefile.lib Signed-off-by: Dirk Brandewie dirk.brande...@gmail.com applied, thanks g. --- arch/microblaze/boot/Makefile | 12 +++- 1 files changed, 3 insertions(+), 9 deletions(-) diff --git a/arch/microblaze/boot/Makefile b/arch/microblaze/boot/Makefile index be01d78..4c4e58e 100644 --- a/arch/microblaze/boot/Makefile +++ b/arch/microblaze/boot/Makefile @@ -10,9 +10,6 @@ targets := linux.bin linux.bin.gz simpleImage.% OBJCOPYFLAGS := -O binary -# Where the DTS files live -dtstree := $(srctree)/$(src)/dts - # Ensure system.dtb exists $(obj)/linked_dtb.o: $(obj)/system.dtb @@ -51,14 +48,11 @@ $(obj)/simpleImage.%: vmlinux FORCE $(call if_changed,strip) @echo 'Kernel: $@ is ready' ' (#'`cat .version`')' -# Rule to build device tree blobs -DTC = $(objtree)/scripts/dtc/dtc # Rule to build device tree blobs -quiet_cmd_dtc = DTC $@ - cmd_dtc = $(DTC) -O dtb -o $(obj)/$*.dtb -b 0 -p 1024 $(dtstree)/$*.dts +DTC_FLAGS := -p 1024 -$(obj)/%.dtb: $(dtstree)/%.dts FORCE - $(call if_changed,dtc) +$(obj)/%.dtb: $(src)/dts/%.dts FORCE + $(call cmd,dtc) clean-files += *.dtb simpleImage.*.unstrip linux.bin.ub -- 1.7.2.3 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 3/4] of/powerpc: Use generic rule to build dtb's
On Wed, Dec 22, 2010 at 11:57:28AM -0800, dirk.brande...@gmail.com wrote: From: Dirk Brandewie dirk.brande...@gmail.com Modify arch/powerpc/boot/Makefile to use dtc command in scripts/Makefile.lib Signed-off-by: Dirk Brandewie dirk.brande...@gmail.com applied, thanks g. --- arch/powerpc/boot/Makefile |8 +++- 1 files changed, 3 insertions(+), 5 deletions(-) diff --git a/arch/powerpc/boot/Makefile b/arch/powerpc/boot/Makefile index fae8192..96deec6 100644 --- a/arch/powerpc/boot/Makefile +++ b/arch/powerpc/boot/Makefile @@ -35,7 +35,7 @@ endif BOOTCFLAGS += -I$(obj) -I$(srctree)/$(obj) -DTS_FLAGS?= -p 1024 +DTC_FLAGS?= -p 1024 $(obj)/4xx.o: BOOTCFLAGS += -mcpu=405 $(obj)/ebony.o: BOOTCFLAGS += -mcpu=405 @@ -332,10 +332,8 @@ $(obj)/treeImage.%: vmlinux $(obj)/%.dtb $(wrapperbits) $(call if_changed,wrap,treeboot-$*,,$(obj)/$*.dtb) # Rule to build device tree blobs -DTC = $(objtree)/scripts/dtc/dtc - -$(obj)/%.dtb: $(dtstree)/%.dts - $(DTC) -O dtb -o $(obj)/$*.dtb -b 0 $(DTS_FLAGS) $(dtstree)/$*.dts +$(obj)/%.dtb: $(src)/dts/%.dts + $(call cmd,dtc) # If there isn't a platform selected then just strip the vmlinux. ifeq (,$(image-y)) -- 1.7.2.3 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [RFC] MPIC Bindings and Bindings for AMP Systems
On Thu, Dec 23, 2010 at 03:49:54PM -0600, Meador Inge wrote:
On 12/23/2010 12:56 PM, Grant Likely wrote:
Hi Meador. Comments below.
g.
Thanks a lot for the feedback Grant.
You should probably list them here anyway to aid the reader.
Will do.
What is the use case for the protected-sources property? Wouldn't the
irqs simply not be referenced by any device nodes? Documenting the
reason for this property would be useful here.
One use case is the original [1]:
Some HW platforms, such as the new cell blades, requires some
MPIC sources to be left alone by the operating system. This
implements support for a protected-sources property in the
mpic controller node containing a list of source numbers to be
protected against operating system interference.
Our use case is to reserve certain IRQs for certain OSes in an AMP
system. As an example, consider that OS 1 has (simplified for
discussion):
mpic: p...@4 {
...
protected-sources = 0xb1;
m...@41400 {
interrupts = 0xb0 2 0xb1 2 0xb2 2 0xb3 2;
};
};
and OS 2 has:
mpic: p...@4 {
...
protected-sources = 0xb0;
m...@41400 {
interrupts = 0xb0 2 0xb1 2 0xb2 2 0xb3 2;
};
};
where OS 1 is sent messages through the message register tied to
0xb0 and OS 2 is sent messages through the message register tied to
0xb1.
We can't just remove the IRQ of the _other_ OS from the 'interrupts'
property in the message node because we need to know the IRQ in
order to talk to the other OS. So, we use protected sources to tell
the OS that an IRQ is not available for its own use, while at the
same time keeping complete information on all the IRQ mappings for
the message registers.
If the OS cannot use the IRQ, then it better not be encoded into an
'interrupts' property. Instead, they should be encoded into a
different property (which could use exactly the same encoding as
'interrupts') that tells the driver that it is the target processor's
irq. Something like 'target-interrupts-cpu0 = 0xb1 2' for OS#1 in
the example.
I will update the documentation.
I'd rather see the 'generic' value of mpic-msgr omitted and instead
allow new parts to claim compatibility with an older chip. Generic
or wildcard compatible values can be troublesome because the meaning
has a tendency to change over time.
I don't completely see the issue here. Do you have a specific
example of how generic values like this cause problems?
For example, both the mpc83xx family and the mpc5xxx family of
processors implement the same i2c core (historically using compatible
fsl,i2c), but the behaviour of the two parts is subtly and
incompatibly different. The actual implementation name has to be
matched to figure out how to drive the core correctly. So, in that
case which implementation does fsl,i2c really describe?
How do you
see this working in terms of processing the data? It seems like we
are going to have to be aware of N values instead of 1, which seems
worse.
This argument has been rehashed many times, but it basically comes
down to compatible values should ideally be anchored to a real
implemented device, not to a family of devices, or to an unversioned
specification.
In practise, the implementation doesn't actually look any different
except that the 'reference' version specifies a specific
implementation instead of a generic name. To use a concrete example,
if there are two parts using this MPIC, like the freescale p2040 and
p4080, and say for argument that the p2040 was implemented first, then
the compatible values would look like:
for the p2040: compatible = fsl,p2040-msgr;
for the p4080: compatible = fsl,p4080-msgr, fsl,p2040-msgr;
and the driver could simply bind on fsl,p2040-msgr to work with both
chips. So, instead of an arbitrary fsl,mpic-msgr string,
fsl,p2040-msgr is used as the baseline value and there is no
ambiguity about which part it describes.
If the p4080 is actually subtly different from the p2040, then
it would not claim compatibility with the former and the driver can
match against either string; adapting its behaviour as necessary.
? This needs some more explanation. cell-index often gets abused as
a way to enumerate devices. Typically, the address of the device
itself is sufficient to identify the device.
The message registers typically come in blocks of four memory mapped
registers and may not be in contiguous memory (example [3]). The
intent of 'cell-index' is to put an ordering on the blocks (so, yes,
enumeration). We could order them by address as well I suppose.
One less property to worry about :)
:-) I'd prefer to see a binding that doesn't need to enumerate nodes.
If the nodes *really* need to be enumerated, then I recommend looking
at using properties in the aliases node to assign globally enumerated
names, or at explicitly
Re: [PATCH] of/address: use propper endianess in get_flags
On Thu, Dec 02, 2010 at 10:15:12AM +1100, Benjamin Herrenschmidt wrote:
On Wed, 2010-12-01 at 10:54 +0100, Sebastian Andrzej Siewior wrote:
This patch changes u32 to __be32 for all ranges, prop and addr and
such. Those variables are pointing to the device tree which containts
intergers in big endian format.
Most functions are doing it right because of_read_number() is doing the
right thing for them. of_bus_isa_get_flags(), of_bus_pci_get_flags() and
of_bus_isa_map() were accessing the data directly and were doing it wrong.
Signed-off-by: Sebastian Andrzej Siewior bige...@linutronix.de
Acked-by: Benjamin Herrenschmidt b...@kernel.crashing.org
Applied for -next, thanks.
g.
---
---
arch/powerpc/include/asm/prom.h |2 +-
drivers/of/address.c| 54
--
include/linux/of_address.h |6 ++--
3 files changed, 32 insertions(+), 30 deletions(-)
diff --git a/arch/powerpc/include/asm/prom.h
b/arch/powerpc/include/asm/prom.h
index ae26f2e..ab34f60 100644
--- a/arch/powerpc/include/asm/prom.h
+++ b/arch/powerpc/include/asm/prom.h
@@ -42,7 +42,7 @@ extern void pci_create_OF_bus_map(void);
/* Translate a DMA address from device space to CPU space */
extern u64 of_translate_dma_address(struct device_node *dev,
- const u32 *in_addr);
+ const __be32 *in_addr);
#ifdef CONFIG_PCI
extern unsigned long pci_address_to_pio(phys_addr_t address);
diff --git a/drivers/of/address.c b/drivers/of/address.c
index 3a1c7e7..b4559c5 100644
--- a/drivers/of/address.c
+++ b/drivers/of/address.c
@@ -12,13 +12,13 @@
(ns) 0)
static struct of_bus *of_match_bus(struct device_node *np);
-static int __of_address_to_resource(struct device_node *dev, const u32
*addrp,
- u64 size, unsigned int flags,
+static int __of_address_to_resource(struct device_node *dev,
+ const __be32 *addrp, u64 size, unsigned int flags,
struct resource *r);
/* Debug utility */
#ifdef DEBUG
-static void of_dump_addr(const char *s, const u32 *addr, int na)
+static void of_dump_addr(const char *s, const __be32 *addr, int na)
{
printk(KERN_DEBUG %s, s);
while (na--)
@@ -26,7 +26,7 @@ static void of_dump_addr(const char *s, const u32 *addr,
int na)
printk(\n);
}
#else
-static void of_dump_addr(const char *s, const u32 *addr, int na) { }
+static void of_dump_addr(const char *s, const __be32 *addr, int na) { }
#endif
/* Callbacks for bus specific translators */
@@ -36,10 +36,10 @@ struct of_bus {
int (*match)(struct device_node *parent);
void(*count_cells)(struct device_node *child,
int *addrc, int *sizec);
- u64 (*map)(u32 *addr, const u32 *range,
+ u64 (*map)(u32 *addr, const __be32 *range,
int na, int ns, int pna);
int (*translate)(u32 *addr, u64 offset, int na);
- unsigned int(*get_flags)(const u32 *addr);
+ unsigned int(*get_flags)(const __be32 *addr);
};
/*
@@ -55,7 +55,7 @@ static void of_bus_default_count_cells(struct device_node
*dev,
*sizec = of_n_size_cells(dev);
}
-static u64 of_bus_default_map(u32 *addr, const u32 *range,
+static u64 of_bus_default_map(u32 *addr, const __be32 *range,
int na, int ns, int pna)
{
u64 cp, s, da;
@@ -85,7 +85,7 @@ static int of_bus_default_translate(u32 *addr, u64
offset, int na)
return 0;
}
-static unsigned int of_bus_default_get_flags(const u32 *addr)
+static unsigned int of_bus_default_get_flags(const __be32 *addr)
{
return IORESOURCE_MEM;
}
@@ -110,10 +110,10 @@ static void of_bus_pci_count_cells(struct device_node
*np,
*sizec = 2;
}
-static unsigned int of_bus_pci_get_flags(const u32 *addr)
+static unsigned int of_bus_pci_get_flags(const __be32 *addr)
{
unsigned int flags = 0;
- u32 w = addr[0];
+ u32 w = be32_to_cpup(addr);
switch((w 24) 0x03) {
case 0x01:
@@ -129,7 +129,8 @@ static unsigned int of_bus_pci_get_flags(const u32
*addr)
return flags;
}
-static u64 of_bus_pci_map(u32 *addr, const u32 *range, int na, int ns, int
pna)
+static u64 of_bus_pci_map(u32 *addr, const __be32 *range, int na, int ns,
+ int pna)
{
u64 cp, s, da;
unsigned int af, rf;
@@ -160,7 +161,7 @@ static int of_bus_pci_translate(u32 *addr, u64 offset,
int na)
return of_bus_default_translate(addr + 1, offset, na - 1);
}
-const u32 *of_get_pci_address(struct device_node *dev, int bar_no, u64
*size,
+const __be32 *of_get_pci_address(struct device_node *dev, int bar_no, u64
*size,
[PATCH][GIT PULL] powerpc64/tracing: Add frame buffer to calls of trace_hardirqs_on/off
Ben, Joerg reported a crash with the irqsoff tracer with PPC32. Unfortunately, I don't have a ppc32 that I can work with (my kids took it from me). I posted a test patch on the BZ that was opened for it: https://bugzilla.kernel.org/show_bug.cgi?id=16573 Anyway, I was also able to reproduce the crash on PPC64. This patch handles that case. The following patch is in: git://git.kernel.org/pub/scm/linux/kernel/git/rostedt/linux-2.6-trace.git branch: ppc/ftrace Steven Rostedt (1): powerpc64/tracing: Add frame buffer to calls of trace_hardirqs_on/off arch/powerpc/include/asm/irqflags.h | 40 ++ 1 files changed, 30 insertions(+), 10 deletions(-) --- commit 5025019505da6731f8be13940bb978617599c935 Author: Steven Rostedt srost...@redhat.com Date: Thu Dec 23 21:07:39 2010 -0800 powerpc64/tracing: Add frame buffer to calls of trace_hardirqs_on/off When an interrupt occurs in userspace, we can call trace_hardirqs_on/off() With one level stack. But if we have irqsoff tracing enabled, it checks both CALLER_ADDR0 and CALLER_ADDR1. The second call goes two stack frames up. If this is from user space, then there may not exist a second stack. Add a second stack when calling trace_hardirqs_on/off() otherwise the following oops might occur: Oops: Kernel access of bad area, sig: 11 [#1] PREEMPT SMP NR_CPUS=2 PA Semi PWRficient last sysfs file: /sys/block/sda/size Modules linked in: ohci_hcd ehci_hcd usbcore NIP: c00e1c00 LR: c00034d4 CTR: 00011012c440 REGS: c0003e2f3af0 TRAP: 0300 Not tainted (2.6.37-rc6+) MSR: 90001032 ME,IR,DR CR: 4804 XER: 2000 DAR: 0001ffb9db50, DSISR: 4000 TASK = c0003e1a00a0[2088] 'emacs' THREAD: c0003e2f CPU: 1 GPR00: 0001 c0003e2f3d70 c084e0d0 c08816e8 GPR04: 1034c678 1032e8f9 10336540 4002 GPR08: 4002 0001ffb9db40 c0003e2f3e30 6000 GPR12: 1000f032 cfff0280 1032e8c9 0008 GPR16: 105be9c0 105be950 105be9b0 105be950 GPR20: ffb9dc50 ffb9dbf0 102f 102f GPR24: 102e 102f 10336540 c09ded38 GPR28: 102e c00034d4 c07ccb10 c0003e2f3d70 NIP [c00e1c00] .trace_hardirqs_off+0xb0/0x1d0 LR [c00034d4] decrementer_common+0xd4/0x100 Call Trace: [c0003e2f3d70] [c0003e2f3e30] 0xc0003e2f3e30 (unreliable) [c0003e2f3e30] [c00034d4] decrementer_common+0xd4/0x100 Instruction dump: 8169 7f8b 419e0018 f84a0028 6000 6000 6000 e95f 8003 e92a eb6301f8 2f80 eb890010 41fe00dc a06d000a eb1e8050 ---[ end trace 4ec7fd2be9240928 ]--- Reported-by: Joerg Sommer jo...@alea.gnuu.de Signed-off-by: Steven Rostedt rost...@goodmis.org diff --git a/arch/powerpc/include/asm/irqflags.h b/arch/powerpc/include/asm/irqflags.h index b85d8dd..b0b06d8 100644 --- a/arch/powerpc/include/asm/irqflags.h +++ b/arch/powerpc/include/asm/irqflags.h @@ -12,24 +12,44 @@ #else #ifdef CONFIG_TRACE_IRQFLAGS +#ifdef CONFIG_IRQSOFF_TRACER +/* + * Since the ftrace irqsoff latency trace checks CALLER_ADDR1, + * which is the stack frame here, we need to force a stack frame + * in case we came from user space. + */ +#define TRACE_WITH_FRAME_BUFFER(func) \ + mflrr0; \ + stdur1, -32(r1);\ + std r0, 16(r1); \ + stdur1, -32(r1);\ + bl func;\ + ld r1, 0(r1); \ + ld r1, 0(r1); +#else +#define TRACE_WITH_FRAME_BUFFER(func) \ + bl func; +#endif + /* * Most of the CPU's IRQ-state tracing is done from assembly code; we * have to call a C function so call a wrapper that saves all the * C-clobbered registers. */ -#define TRACE_ENABLE_INTS bl .trace_hardirqs_on -#define TRACE_DISABLE_INTS bl .trace_hardirqs_off -#define TRACE_AND_RESTORE_IRQ_PARTIAL(en,skip) \ - cmpdi en,0; \ - bne 95f;\ - stb en,PACASOFTIRQEN(r13); \ - bl .trace_hardirqs_off;\ - b skip; \ -95:bl .trace_hardirqs_on; \ +#define TRACE_ENABLE_INTS TRACE_WITH_FRAME_BUFFER(.trace_hardirqs_on) +#define TRACE_DISABLE_INTS TRACE_WITH_FRAME_BUFFER(.trace_hardirqs_off) + +#define TRACE_AND_RESTORE_IRQ_PARTIAL(en,skip) \ + cmpdi en,0; \ + bne 95f;
