On Fri, 2009-02-13 at 10:00 -0500, Steven Rostedt wrote:
plain text document attachment
(0002-powerpc-ftrace-use-create_branch-lib-function.patch)
From: Steven Rostedt srost...@redhat.com
Impact: clean up, remove duplicate code
When ftrace was first ported to PowerPC, there existed a
On Fri, 2009-02-13 at 14:45 -0600, Dave Kleikamp wrote:
When identify_cpu() is called a second time with a logical PVR, it only
copies a subset of the cpu_spec structure to avoid overwriting the
performance monitor fields that were initialized based on the real PVR.
If the real PVR is not
On Sun, 15 Feb 2009, Michael Ellerman wrote:
/* if (link) set op to 'bl' else 'b' */
- op = 0x4800 | (link ? 1 : 0);
- op |= (ftrace_calc_offset(ip, addr) 0x03fc);
+ op = create_branch((unsigned int *)ip, addr, link ? 1 : 0);
If I was feeling nit-picky I'd say
Hi All,
I've been rather busy lately and have unfortunately gotten behind on
updating the 4xx tree. I spent some time this weekend looking over
the patches queued up, and fortunately there were not too many. I'm
doing some build testing of these 4 today:
commit
On Wed, Feb 04, 2009 at 10:26:12PM +0100, Ingo Molnar wrote:
* Anton Vorontsov avoront...@ru.mvista.com wrote:
This patch gives arches more freedom on overwriting CFLAGS, specifically
on PowerPC we want to remove -fno-omit-frame-pointer flag.
Signed-off-by: Anton Vorontsov
On Wed, Feb 11, 2009 at 02:51:34PM +1100, Benjamin Herrenschmidt wrote:
On Wed, 2009-02-04 at 22:26 +0100, Ingo Molnar wrote:
+include $(srctree)/arch/$(SRCARCH)/Makefile
+
# arch Makefile may override CC so keep this after arch Makefile is
included
NOSTDINC_FLAGS += -nostdinc
* Sam Ravnborg s...@ravnborg.org wrote:
On Wed, Feb 04, 2009 at 10:26:12PM +0100, Ingo Molnar wrote:
* Anton Vorontsov avoront...@ru.mvista.com wrote:
This patch gives arches more freedom on overwriting CFLAGS, specifically
on PowerPC we want to remove -fno-omit-frame-pointer
On Sat, 2009-02-14 at 23:03 +0100, Ingo Molnar wrote:
So the question is: even with FRAME_POINTERS disabled on PPC, is
__builtin_return_address(1)/(2) reliable, and is save_stack_trace() fast?
(i.e.
can it walk down the stack frame efficiently, or does it have to scan the full
kernel
Hi,
I'm programming a board with an MPC8555E on which an external chip can
raise low priority interrupts through the port C of the CPM2. Under
nominal conditions it generates few interrupts, but they take a
relatively long time to be processed.
I also use some CPM2 controllers in such a way that