* Re: request_irq return errno 38
From: Vijay Nikam @ 2009-02-12 10:51 UTC (permalink / raw)
To: Brad Boyer, scottwood, linuxppc-dev
In-Reply-To: <20090211223546.GA20129@cynthia.pants.nu>
Thanks for your replies ...
I checked the irq.c and irq.h and found the prototype of
irq_of_parse_and_map() and found from the comment that it is a wrapper
function contains a chain of irq_map_one() and irq_create_mapping()
...
It means that I can use irq_create_mapping() to know the virq also the
same suggessted by michael ... what is the difference between these
two i.e. irq_create_mapping() and irq_of_parse_and_map() ... I mean in
usage what could be the difference ? ? ?
If used the irq_of_parse_and_map() then the paraments I need to pass
are device_node *dev and index irq_of_parse_and_map(struct device_node
*dev, int index) ... then how I can pass the required information i.e.
dev and index ? ? ?
Also how I can read the device tree binary file ? ? ?
Kindly please acknowledge ... thank you ...
Kind Regards,
Vijay Nikam
On 2/12/09, Brad Boyer <flar@allandria.com> wrote:
> On Wed, Feb 11, 2009 at 03:43:26PM +0530, Vijay Nikam wrote:
> > I read in LDD book, they give directly irq no. they have given
> > parallel port example, here they have set or said irq no. defaults to
> > 7 and they have not done any irq_mapping so what is the difference ? ?
> > ? I mean how I should know when to use irq_mapping and when not ? ? ?
> >
> > Also is it some difference between writng drivers on embedded Linux
> > level and Linux PC (i386) ? ? ?
>
> The basic request_irq() function is generic, but the value of the
> arguments (especially the number for the IRQ line) is architecture
> specific in many ways. This is one difference between the i386 code
> and the powerpc code inside Linux. Most i386 hardware is standard
> PC hardware with very clearly defined interrupt sources. Because of
> this, the mapping from the numeric IRQ value to a real hardware
> interrupt source is defined pretty clearly. The powerpc architecture
> code has to support almost arbitrarily complex hardware, and the
> embedded world is the source of most of the complexity. Because of
> this, the powerpc code has to dynamically allocate those numeric
> IRQ sources and tie them to a specific hardware interrupt. There
> is functionality to take the information from your device tree and
> convert it to a virtual IRQ. That happens automatically for some types
> of devices like PCI cards, but your driver may have to do that mapping
> itself in other cases. I believe the appropriate API for this is the
> function irq_of_parse_and_map(). It takes a device node and index into
> the interrupt list for that device and gives a virtual IRQ number.
>
> Brad Boyer
> flar@allandria.com
>
>
^ permalink raw reply
* PowerPC 7447A Paging table Search
From: sumedh tirodkar @ 2009-02-12 9:59 UTC (permalink / raw)
To: linuxppc-dev
How will i confirm if PowerPC 7447A processor has or does not have a
dedicated hardware for page table search algorithm?
If it does not have, then which interrupt handler is written for page
address translation mechanism?
-Sumedh
^ permalink raw reply
* [MPC8272ADS]Problem adding flash partitions inside the device tree
From: Jean-Michel Hautbois @ 2009-02-12 9:23 UTC (permalink / raw)
To: linuxppc-dev
[-- Attachment #1: Type: text/plain, Size: 2422 bytes --]
Hi everybody !
I am currently trying to add the support of partitions for the Flash chip on
my MPC8272ADS board (the chips are Sharp LH28F016SCT-L90).
I have added this part:
flash@0,0 {
compatible = "jedec-flash";
reg = <0x0 0x0 0x2000000>;
bank-width = <4>;
device-width = <1>;
partition@ff800000 {
label = "kernel";
reg = <0xff800000 0x00400000>;
read-only;
};
partition@ffc00000 {
label = "user";
reg = <0xffc00000 0x00300000>;
};
partition@fff00000 {
label = "u-boot";
reg = <0xfff00000 0x00100000>;
read-only;
};
};
But when I am compiling, I have these warnings:
Warning (reg_format): "reg" property in /localbus@f0010100/flash@0
,0/partition@ff800000 has invalid length (8 bytes) (#address-cells == 2,
#size-cells == 1)
Warning (reg_format): "reg" property in /localbus@f0010100/flash@0
,0/partition@ffc00000 has invalid length (8 bytes) (#address-cells == 2,
#size-cells == 1)
Warning (reg_format): "reg" property in /localbus@f0010100/flash@0
,0/partition@fff00000 has invalid length (8 bytes) (#address-cells == 2,
#size-cells == 1)
Warning (avoid_default_addr_size): Relying on default #address-cells value
for /localbus@f0010100/flash@0,0/partition@ff800000
Warning (avoid_default_addr_size): Relying on default #size-cells value for
/localbus@f0010100/flash@0,0/partition@ff800000
Warning (avoid_default_addr_size): Relying on default #address-cells value
for /localbus@f0010100/flash@0,0/partition@ffc00000
Warning (avoid_default_addr_size): Relying on default #size-cells value for
/localbus@f0010100/flash@0,0/partition@ffc00000
Warning (avoid_default_addr_size): Relying on default #address-cells value
for /localbus@f0010100/flash@0,0/partition@fff00000
Warning (avoid_default_addr_size): Relying on default #size-cells value for
/localbus@f0010100/flash@0,0/partition@fff00000
Can anyone help me ?
I can't understand what the "address-cells" is.
Thanks in advance !
Best Regards.
JM
[-- Attachment #2: Type: text/html, Size: 5159 bytes --]
^ permalink raw reply
* Re: AMCC ppc440spe 2.6.23.10 kernel boot help
From: Wolfgang Denk @ 2009-02-12 8:07 UTC (permalink / raw)
To: Shubhada Pugaonkar; +Cc: linuxppc-dev
In-Reply-To: <8A71B368A89016469F72CD08050AD33402D57545@maui.asicdesigners.com>
Dear Shubhada,
In message <8A71B368A89016469F72CD08050AD33402D57545@maui.asicdesigners.com> you wrote:
>
> I am kind of helpless regarding the kernel version, as our customer is
> using it and I need to replicate their environment. I just tried 2.6.28
> with katmai_defconfig file and still face the same problem.
You probably did not load (and use) the device tree blob which is
needed with recent (arch/powerpc based) kernel versions.
> The config file that I sent before is provided by the customer. It is a
> working configuration for them.
>
> The exact board that I have is Katmai.
It looks broken to me for a Katmai board. Are you sure your customer
is also using Katmai?
> my printenv output is as follows.
This is obviously an old setup for old (arch/ppc only) kernel
versions, and heavily crippl^H^H^H^H^H modified from the default
environment. You might consider to restart from the default
environment settings (probably even with a recent version of U-Boot -
your's is too old and does not include full device tree support).
On the other hand, I don;t see a reason why the old (arch/ppc based)
kernel should not boot - except that it might be misconfigured for
that board.
Did you try any of the released (and well tested) kernel images on
our FTP server? See ftp://ftp.denx.de/pub/linux/images/amcc/katmai/
Best regards,
Wolfgang Denk
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de
"Just think of a computer as hardware you can program."
- Nigel de la Tierre
^ permalink raw reply
* Re: Badness at kernel/time/timekeeping.c:98 in pmud (timekeeping_suspended)
From: Benjamin Herrenschmidt @ 2009-02-12 6:05 UTC (permalink / raw)
To: Thomas Gleixner
Cc: Rafael J. Wysocki, linuxppc-dev, Ingo Molnar, Paul Collins,
linux-kernel
In-Reply-To: <alpine.LFD.2.00.0902091302310.415@localhost.localdomain>
> The commit fixed the problem with sched_clock, but it does not fix
> problems where other parts of the kernel call timekeeping functions
> _AFTER_ timekeeping has been suspended.
Maybe we should use the PMU sysdev which is used for suspending
backlight stuff etc... to also suspend emitting of the input events.
Cheers,
Ben.
^ permalink raw reply
* Re: request_irq return errno 38
From: Benjamin Herrenschmidt @ 2009-02-12 6:01 UTC (permalink / raw)
To: Brad Boyer; +Cc: Vijay Nikam, linuxppc-dev
In-Reply-To: <20090211223546.GA20129@cynthia.pants.nu>
On Wed, 2009-02-11 at 14:35 -0800, Brad Boyer wrote:
> On Wed, Feb 11, 2009 at 03:43:26PM +0530, Vijay Nikam wrote:
> > I read in LDD book, they give directly irq no. they have given
> > parallel port example, here they have set or said irq no. defaults to
> > 7 and they have not done any irq_mapping so what is the difference ? ?
> > ? I mean how I should know when to use irq_mapping and when not ? ? ?
> >
> > Also is it some difference between writng drivers on embedded Linux
> > level and Linux PC (i386) ? ? ?
>
> The basic request_irq() function is generic, but the value of the
> arguments (especially the number for the IRQ line) is architecture
> specific in many ways. This is one difference between the i386 code
> and the powerpc code inside Linux. Most i386 hardware is standard
> PC hardware with very clearly defined interrupt sources.
In fact, not even clearly anymore :-) IE, there are still some legacy
interrupts at fixed numbers but most things are remapped on x86 too
nowadays when using IO_APICs, the kernel obtains numbers from ACPI,
remaps them etc...
What saves x86 is that anything other than legacy ISA uses PCI nowadays
and thus that remapping is invisible to PCI drivers (as it is on
powerpc). The problem only bites with other bus types more common on
embedded hardware, as you mention further down.
> Because of
> this, the mapping from the numeric IRQ value to a real hardware
> interrupt source is defined pretty clearly. The powerpc architecture
> code has to support almost arbitrarily complex hardware, and the
> embedded world is the source of most of the complexity. Because of
> this, the powerpc code has to dynamically allocate those numeric
> IRQ sources and tie them to a specific hardware interrupt. There
> is functionality to take the information from your device tree and
> convert it to a virtual IRQ. That happens automatically for some types
> of devices like PCI cards, but your driver may have to do that mapping
> itself in other cases. I believe the appropriate API for this is the
> function irq_of_parse_and_map(). It takes a device node and index into
> the interrupt list for that device and gives a virtual IRQ number.
Cheers,
Ben.
> Brad Boyer
> flar@allandria.com
>
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-dev
^ permalink raw reply
* RE: [PATCH] powerpc/83xx: Revive Marvell PHY option on MPC8313E-RDB rev. C boards
From: Li Yang-R58472 @ 2009-02-12 5:40 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev list
In-Reply-To: <60C07231-C830-440E-8425-D3069AB3620B@kernel.crashing.org>
> -----Original Message-----
> From: Kumar Gala [mailto:galak@kernel.crashing.org]=20
> Sent: Thursday, February 12, 2009 1:25 PM
> To: Li Yang-R58472
> Cc: linuxppc-dev list; Anton Vorontsov
> Subject: Re: [PATCH] powerpc/83xx: Revive Marvell PHY option=20
> on MPC8313E-RDB rev. C boards
>=20
>=20
> On Feb 10, 2009, at 9:10 AM, Anton Vorontsov wrote:
>=20
> >
> > Li, thanks for heads-up!
> >
> > One thing though: documentation says that Marvell PHY=20
> address is 0x3,=20
> > while old device tree and this patch:
> >
> >=20
> http://www.bitshrine.org/gpp/linux-fsl-2.6.23-MPC8313ERDB-add-default-
> > dts.patch
> >
> > says "0x1"... I don't have any rev. C boards, so it would=20
> be great if=20
> > somebody could confirm that 0x1 is the actual address.
The correct address is 0x3. The previous patch in revB BSP used a guess
value before the revC documentation is available. The latest BSP has
been updated to use the correct address.
- Leo
^ permalink raw reply
* Re: [PATCH] powerpc/83xx: Revive Marvell PHY option on MPC8313E-RDB rev. C boards
From: Kumar Gala @ 2009-02-12 5:25 UTC (permalink / raw)
To: Li Yang-R58472; +Cc: linuxppc-dev
In-Reply-To: <3A45394FD742FA419B760BB8D398F9ED1D2D22@zch01exm26.fsl.freescale.net>
>> On Feb 10, 2009, at 9:10 AM, Anton Vorontsov wrote:
>>
>>> commit e85477f516c2de7ed515fcf94ceab5282eba7fa4 ("powerpc/83xx: Fix
>>> TSEC0 workability on MPC8313E-RDB boards") fixed TSEC0
>> workability for
>>> rev. A and rev. B boards by using fixed-link property for VSC 7385
>>> 5-port switch. But rev. C boards have an option where TSEC0
>> connected
>>> to a Marvell PHY, which is a normal PHY on MDIO bus.
>>>
>>> So far U-Boot does not fix up TSEC0 nodes for MPC8313E-RDB
>> boards, so
>>> we'd better include two device-tree files: one that specify Vitesse
>>> PHY and another for boards with Marvell PHY option.
>>>
>>> Reported-by: Li Yang <leoli@freescale.com>
>>> Signed-off-by: Anton Vorontsov <avorontsov@ru.mvista.com>
>>> ---
>>>
>>> Li, thanks for heads-up!
>>>
>>> One thing though: documentation says that Marvell PHY
>> address is 0x3,
>>> while old device tree and this patch:
>>>
>>>
>> http://www.bitshrine.org/gpp/linux-fsl-2.6.23-MPC8313ERDB-add-
>> default-
>>> dts.patch
>>>
>>> says "0x1"... I don't have any rev. C boards, so it would
>> be great if
>>> somebody could confirm that 0x1 is the actual address.
>>>
>>> arch/powerpc/boot/dts/mpc8313erdb_marvell_phy.dts | 401
>> ++++++++++++
>>> +++++++++
>>> arch/powerpc/configs/83xx/mpc8313_rdb_defconfig | 2 +-
>>> 2 files changed, 402 insertions(+), 1 deletions(-) create
>> mode 100644
>>> arch/powerpc/boot/dts/mpc8313erdb_marvell_phy.dts
>>
>> did we decide that we don't have any bcsr or something that
>> convey board rev or this setting?
>
> Nope for now. The board do have two revision bits readable to the
> core,
> one bit set by resisters and the other set by a switch. We don't
> currently have a convention for using these two bits. And apperently
> they can't cover the information of both the board revision and setup.
>
> - Leo
ok. I'll take the patch pending the other question Anton raised about
the phy id.
- k
^ permalink raw reply
* Re: [PATCH] powerpc/83xx: Revive Marvell PHY option on MPC8313E-RDB rev. C boards
From: Kumar Gala @ 2009-02-12 5:24 UTC (permalink / raw)
To: Li Yang; +Cc: linuxppc-dev list
In-Reply-To: <20090210151047.GA25086@oksana.dev.rtsoft.ru>
On Feb 10, 2009, at 9:10 AM, Anton Vorontsov wrote:
>
> Li, thanks for heads-up!
>
> One thing though: documentation says that Marvell PHY address is
> 0x3, while old device tree and this patch:
>
> http://www.bitshrine.org/gpp/linux-fsl-2.6.23-MPC8313ERDB-add-default-dts.patch
>
> says "0x1"... I don't have any rev. C boards, so it would
> be great if somebody could confirm that 0x1 is the actual address.
Leo, on comments on this?
- k
^ permalink raw reply
* [PATCH] powerpc: Fix warnings from make headers_check
From: Kumar Gala @ 2009-02-12 5:09 UTC (permalink / raw)
Cc: linuxppc-dev
include/asm/bootx.h:12: include of <linux/types.h> is preferred over <asm/types.h>
include/asm/bootx.h:57: found __[us]{8,16,32,64} type without #include <linux/types.h>
include/asm/elf.h:5: include of <linux/types.h> is preferred over <asm/types.h>
include/asm/kvm.h:23: include of <linux/types.h> is preferred over <asm/types.h>
include/asm/kvm.h:26: found __[us]{8,16,32,64} type without #include <linux/types.h>
include/asm/ps3fb.h:33: found __[us]{8,16,32,64} type without #include <linux/types.h>
include/asm/spu_info.h:27: found __[us]{8,16,32,64} type without #include <linux/types.h>
include/asm/swab.h:11: include of <linux/types.h> is preferred over <asm/types.h>
Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
---
arch/powerpc/include/asm/bootx.h | 2 +-
arch/powerpc/include/asm/elf.h | 3 ++-
arch/powerpc/include/asm/kvm.h | 2 +-
arch/powerpc/include/asm/ps3fb.h | 1 +
arch/powerpc/include/asm/spu_info.h | 3 ++-
arch/powerpc/include/asm/swab.h | 2 +-
6 files changed, 8 insertions(+), 5 deletions(-)
diff --git a/arch/powerpc/include/asm/bootx.h b/arch/powerpc/include/asm/bootx.h
index 57b82e3..60a3c9e 100644
--- a/arch/powerpc/include/asm/bootx.h
+++ b/arch/powerpc/include/asm/bootx.h
@@ -9,7 +9,7 @@
#ifndef __ASM_BOOTX_H__
#define __ASM_BOOTX_H__
-#include <asm/types.h>
+#include <linux/types.h>
#ifdef macintosh
#include <Types.h>
diff --git a/arch/powerpc/include/asm/elf.h b/arch/powerpc/include/asm/elf.h
index cd46f02..c125da7 100644
--- a/arch/powerpc/include/asm/elf.h
+++ b/arch/powerpc/include/asm/elf.h
@@ -7,7 +7,8 @@
#include <asm/string.h>
#endif
-#include <asm/types.h>
+#include <linux/types.h>
+
#include <asm/ptrace.h>
#include <asm/cputable.h>
#include <asm/auxvec.h>
diff --git a/arch/powerpc/include/asm/kvm.h b/arch/powerpc/include/asm/kvm.h
index f993e41..4e0cf65 100644
--- a/arch/powerpc/include/asm/kvm.h
+++ b/arch/powerpc/include/asm/kvm.h
@@ -20,7 +20,7 @@
#ifndef __LINUX_KVM_POWERPC_H
#define __LINUX_KVM_POWERPC_H
-#include <asm/types.h>
+#include <linux/types.h>
struct kvm_regs {
__u64 pc;
diff --git a/arch/powerpc/include/asm/ps3fb.h b/arch/powerpc/include/asm/ps3fb.h
index 3f121fe..1a91daf 100644
--- a/arch/powerpc/include/asm/ps3fb.h
+++ b/arch/powerpc/include/asm/ps3fb.h
@@ -20,6 +20,7 @@
#define _ASM_POWERPC_PS3FB_H_
#include <linux/ioctl.h>
+#include <linux/types.h>
/* ioctl */
#define PS3FB_IOCTL_SETMODE _IOW('r', 1, int) /* set video mode */
diff --git a/arch/powerpc/include/asm/spu_info.h b/arch/powerpc/include/asm/spu_info.h
index 3545efb..1286c82 100644
--- a/arch/powerpc/include/asm/spu_info.h
+++ b/arch/powerpc/include/asm/spu_info.h
@@ -23,9 +23,10 @@
#ifndef _SPU_INFO_H
#define _SPU_INFO_H
+#include <linux/types.h>
+
#ifdef __KERNEL__
#include <asm/spu.h>
-#include <linux/types.h>
#else
struct mfc_cq_sr {
__u64 mfc_cq_data0_RW;
diff --git a/arch/powerpc/include/asm/swab.h b/arch/powerpc/include/asm/swab.h
index ef824ae..c581e3e 100644
--- a/arch/powerpc/include/asm/swab.h
+++ b/arch/powerpc/include/asm/swab.h
@@ -8,7 +8,7 @@
* 2 of the License, or (at your option) any later version.
*/
-#include <asm/types.h>
+#include <linux/types.h>
#include <linux/compiler.h>
#ifdef __GNUC__
--
1.5.6.6
^ permalink raw reply related
* WARNING Cannot determine dependencies of kernel module 'uhci-hcd'.?
From: Anil B G @ 2009-02-12 5:09 UTC (permalink / raw)
To: linuxppc-dev
[-- Attachment #1: Type: text/plain, Size: 1056 bytes --]
Hi,
1. I was trying to build the linux 2.6.28.4 kernel on a ppc system
While building there was an issue in the mkinitrd as below
-------------------------------------------------------------------------------------------------------------------
Kernel image: /boot/vmlinux-2.6.27.5-2-ppc64
Initrd image: /boot/abc
Root device: /dev/disk/by-id/scsi-35000cca005281f3c-part3 (/dev/sda3)
(mounted on / as ext3)
WARNING Cannot determine dependencies of kernel module 'uhci-hcd'.
Does it exist? If it does, try depmod -a. Continuing without uhci-hcd.
Features: block usb resume.userspace resume.kernel
depmod -a works fine.
-------------------------------------------------------------------------------------------------------------------
I tried enabling OHCI inplace of UHCI in the .config and got similar
results. I then tried disabling USB in the menuconfig, but still got the
same result.
I then tried with a different kernel (2.6.27.5) and got pretty much the same
result.
Any suggestions on how to get around this problem?
Regards,
Anil
[-- Attachment #2: Type: text/html, Size: 1996 bytes --]
^ permalink raw reply
* Re: [RFC patch] powerpc: Add topology_ready to machdep calls
From: Benjamin Herrenschmidt @ 2009-02-12 4:21 UTC (permalink / raw)
To: Geoff Levand; +Cc: Linuxppc-dev
In-Reply-To: <49935F81.7060203@am.sony.com>
On Wed, 2009-02-11 at 15:30 -0800, Geoff Levand wrote:
> Add a new member topology_ready to the powerpc machdep_calls
> structure.
>
> The NUMA hot plug memory routines require the NUMA node to have
> been registered via register_one_node() prior to adding memory
> to the node. The powerpc arch registers NUMA nodes during
> startup in its topology_init() routine.
Just a question.. what's wrong with just using some later kind of
initcall ? You want to get the memory added as early as possible ?
Cheers,
Ben.
^ permalink raw reply
* Re: [RFC patch] powerpc: Add topology_ready to machdep calls
From: Benjamin Herrenschmidt @ 2009-02-12 4:21 UTC (permalink / raw)
To: Geoff Levand; +Cc: Linuxppc-dev
In-Reply-To: <49935F81.7060203@am.sony.com>
On Wed, 2009-02-11 at 15:30 -0800, Geoff Levand wrote:
> Add a new member topology_ready to the powerpc machdep_calls
> structure.
>
> The NUMA hot plug memory routines require the NUMA node to have
> been registered via register_one_node() prior to adding memory
> to the node. The powerpc arch registers NUMA nodes during
> startup in its topology_init() routine.
>
> Currently, there is no mechanism for the platform code to know
> when the nodes have been registered, and hence, when it is safe
> to add hot plug memory.
No objection other than the confusion with the /* Optional may be NULL
*/ comment above the line you added that becomes weirdly placed since
it applies, I think, to show_cpuinfo.
Cheers,
Ben.
> Signed-off-by: Geoff Levand <geoffrey.levand@am.sony.com>
> ---
> arch/powerpc/include/asm/machdep.h | 1 +
> arch/powerpc/kernel/sysfs.c | 3 +++
> 2 files changed, 4 insertions(+)
>
> --- a/arch/powerpc/include/asm/machdep.h
> +++ b/arch/powerpc/include/asm/machdep.h
> @@ -106,6 +106,7 @@ struct machdep_calls {
> void (*setup_arch)(void); /* Optional, may be NULL */
> void (*init_early)(void);
> /* Optional, may be NULL. */
> + void (*topology_ready)(void); /* Optional, may be NULL */
> void (*show_cpuinfo)(struct seq_file *m);
> void (*show_percpuinfo)(struct seq_file *m, int i);
>
> --- a/arch/powerpc/kernel/sysfs.c
> +++ b/arch/powerpc/kernel/sysfs.c
> @@ -647,6 +647,9 @@ static int __init topology_init(void)
> register_cpu_online(cpu);
> }
>
> + if (ppc_md.topology_ready)
> + ppc_md.topology_ready();
> +
> return 0;
> }
> subsys_initcall(topology_init);
>
^ permalink raw reply
* Re: [PATCH 0/7][RFC] function graph tracer port to PowerPC
From: Frederic Weisbecker @ 2009-02-12 4:08 UTC (permalink / raw)
To: Steven Rostedt
Cc: linux-kernel, linuxppc-dev, Paul Mackerras, Ingo Molnar,
Andrew Morton
In-Reply-To: <alpine.DEB.1.10.0902112116340.13595@gandalf.stny.rr.com>
On Wed, Feb 11, 2009 at 09:16:57PM -0500, Steven Rostedt wrote:
>
> On Thu, 12 Feb 2009, Frederic Weisbecker wrote:
>
> > On Wed, Feb 11, 2009 at 08:10:51PM -0500, Steven Rostedt wrote:
> > >
> > > The following set of patches are RFC and not for inclusion
> > > (unless everyone is fine with them as is).
> > >
> > > This is the port to PowerPC of the function graph tracer that was written
> > > by Frederic Weisbecker for the x86 architecture. It is broken up
> > > into a series of logical steps.
> > >
> > > 1) get generic code ready for other archs
> > > 2) get PowerPC 64-bit working with just static function tracing
> > > 3) get PowerPC 64-bit working with dynamic function tracing
> > > 4) get PowerPC 32-bit working with just static function tracing
> > > 5) get PowerPC 32-bit working with dynamic function tracing
> > >
> > > (with some clean ups in between)
> > >
> >
> >
> > Thanks a lot Steven!
> > I'm sad to not having a Power Pc to test it...
>
> If you had a PowerPC, I doubt I would have been the one to port it ;-)
Especially since you already implemented ftrace on PowerPc :)
I will acquire an Arm board soon to adapt function graph on Arm...
> -- Steve
>
^ permalink raw reply
* Re: [PATCH 0/7][RFC] function graph tracer port to PowerPC
From: Steven Rostedt @ 2009-02-12 2:37 UTC (permalink / raw)
To: Michael Ellerman
Cc: Frederic Weisbecker, linux-kernel, linuxppc-dev, Paul Mackerras,
Ingo Molnar, Andrew Morton
In-Reply-To: <1234405406.8142.4.camel@localhost>
On Thu, 12 Feb 2009, Michael Ellerman wrote:
> >
> >
> > The function graph tracer not only traces the start of a function
> > (uses the function tracer part for that) but also uses the kprobes
> > trick to replace the return address with a hook to trace the exit
> > of the function.
>
> You use the "kprobes trick", but none of the kprobes code (AFAICS).
> Couldn't there be some common code between the two?
I'm not 100% sure how kprobes work, but I believe they use traps. And then
they set the return address to take another trap, to fix it. I could be
totally off here, on how kprobes does this.
But ftrace is about executing the code directly. The return code jumps to
a another function in asm that will set up the call to do the tracing, and
then fix the return pointer back. The only thing that is similar between
the two approaches that I can tell, is that we both modify the return
address of the function. I took a quick peek at the kprobes code and I
see no easy way to share it.
-- Steve
^ permalink raw reply
* RE: [PATCH] powerpc/83xx: Revive Marvell PHY option on MPC8313E-RDB rev. C boards
From: Li Yang-R58472 @ 2009-02-12 2:36 UTC (permalink / raw)
To: Kumar Gala, avorontsov; +Cc: linuxppc-dev
In-Reply-To: <6413661A-2719-46F5-AC06-C83C088DCCA1@kernel.crashing.org>
> -----Original Message-----
> From: Kumar Gala [mailto:galak@kernel.crashing.org]=20
> Sent: Tuesday, February 10, 2009 11:31 PM
> To: avorontsov@ru.mvista.com
> Cc: Li Yang-R58472; linuxppc-dev@ozlabs.org
> Subject: Re: [PATCH] powerpc/83xx: Revive Marvell PHY option=20
> on MPC8313E-RDB rev. C boards
>=20
>=20
> On Feb 10, 2009, at 9:10 AM, Anton Vorontsov wrote:
>=20
> > commit e85477f516c2de7ed515fcf94ceab5282eba7fa4 ("powerpc/83xx: Fix=20
> > TSEC0 workability on MPC8313E-RDB boards") fixed TSEC0=20
> workability for=20
> > rev. A and rev. B boards by using fixed-link property for VSC 7385=20
> > 5-port switch. But rev. C boards have an option where TSEC0=20
> connected=20
> > to a Marvell PHY, which is a normal PHY on MDIO bus.
> >
> > So far U-Boot does not fix up TSEC0 nodes for MPC8313E-RDB=20
> boards, so=20
> > we'd better include two device-tree files: one that specify Vitesse=20
> > PHY and another for boards with Marvell PHY option.
> >
> > Reported-by: Li Yang <leoli@freescale.com>
> > Signed-off-by: Anton Vorontsov <avorontsov@ru.mvista.com>
> > ---
> >
> > Li, thanks for heads-up!
> >
> > One thing though: documentation says that Marvell PHY=20
> address is 0x3,=20
> > while old device tree and this patch:
> >
> >=20
> http://www.bitshrine.org/gpp/linux-fsl-2.6.23-MPC8313ERDB-add-default-
> > dts.patch
> >
> > says "0x1"... I don't have any rev. C boards, so it would=20
> be great if=20
> > somebody could confirm that 0x1 is the actual address.
> >
> > arch/powerpc/boot/dts/mpc8313erdb_marvell_phy.dts | 401=20
> ++++++++++++
> > +++++++++
> > arch/powerpc/configs/83xx/mpc8313_rdb_defconfig | 2 +-
> > 2 files changed, 402 insertions(+), 1 deletions(-) create=20
> mode 100644=20
> > arch/powerpc/boot/dts/mpc8313erdb_marvell_phy.dts
>=20
> did we decide that we don't have any bcsr or something that=20
> convey board rev or this setting?
Nope for now. The board do have two revision bits readable to the core,
one bit set by resisters and the other set by a switch. We don't
currently have a convention for using these two bits. And apperently
they can't cover the information of both the board revision and setup.
- Leo
^ permalink raw reply
* Re: [PATCH 0/7][RFC] function graph tracer port to PowerPC
From: Michael Ellerman @ 2009-02-12 2:23 UTC (permalink / raw)
To: Steven Rostedt
Cc: Frederic Weisbecker, linux-kernel, linuxppc-dev, Paul Mackerras,
Ingo Molnar, Andrew Morton
In-Reply-To: <20090212011051.265346435@goodmis.org>
[-- Attachment #1: Type: text/plain, Size: 1321 bytes --]
On Wed, 2009-02-11 at 20:10 -0500, Steven Rostedt wrote:
> The following set of patches are RFC and not for inclusion
> (unless everyone is fine with them as is).
>
> This is the port to PowerPC of the function graph tracer that was written
> by Frederic Weisbecker for the x86 architecture. It is broken up
> into a series of logical steps.
>
> 1) get generic code ready for other archs
> 2) get PowerPC 64-bit working with just static function tracing
> 3) get PowerPC 64-bit working with dynamic function tracing
> 4) get PowerPC 32-bit working with just static function tracing
> 5) get PowerPC 32-bit working with dynamic function tracing
>
> (with some clean ups in between)
>
>
> The function graph tracer not only traces the start of a function
> (uses the function tracer part for that) but also uses the kprobes
> trick to replace the return address with a hook to trace the exit
> of the function.
You use the "kprobes trick", but none of the kprobes code (AFAICS).
Couldn't there be some common code between the two?
cheers
--
Michael Ellerman
OzLabs, IBM Australia Development Lab
wwweb: http://michael.ellerman.id.au
phone: +61 2 6212 1183 (tie line 70 21183)
We do not inherit the earth from our ancestors,
we borrow it from our children. - S.M.A.R.T Person
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: [PATCH 0/7][RFC] function graph tracer port to PowerPC
From: Steven Rostedt @ 2009-02-12 2:16 UTC (permalink / raw)
To: Frederic Weisbecker
Cc: linux-kernel, linuxppc-dev, Paul Mackerras, Ingo Molnar,
Andrew Morton
In-Reply-To: <20090212015503.GA4697@nowhere>
On Thu, 12 Feb 2009, Frederic Weisbecker wrote:
> On Wed, Feb 11, 2009 at 08:10:51PM -0500, Steven Rostedt wrote:
> >
> > The following set of patches are RFC and not for inclusion
> > (unless everyone is fine with them as is).
> >
> > This is the port to PowerPC of the function graph tracer that was written
> > by Frederic Weisbecker for the x86 architecture. It is broken up
> > into a series of logical steps.
> >
> > 1) get generic code ready for other archs
> > 2) get PowerPC 64-bit working with just static function tracing
> > 3) get PowerPC 64-bit working with dynamic function tracing
> > 4) get PowerPC 32-bit working with just static function tracing
> > 5) get PowerPC 32-bit working with dynamic function tracing
> >
> > (with some clean ups in between)
> >
>
>
> Thanks a lot Steven!
> I'm sad to not having a Power Pc to test it...
If you had a PowerPC, I doubt I would have been the one to port it ;-)
-- Steve
^ permalink raw reply
* Re: [PATCH 0/7][RFC] function graph tracer port to PowerPC
From: Frederic Weisbecker @ 2009-02-12 1:55 UTC (permalink / raw)
To: Steven Rostedt
Cc: linux-kernel, linuxppc-dev, Paul Mackerras, Ingo Molnar,
Andrew Morton
In-Reply-To: <20090212011051.265346435@goodmis.org>
On Wed, Feb 11, 2009 at 08:10:51PM -0500, Steven Rostedt wrote:
>
> The following set of patches are RFC and not for inclusion
> (unless everyone is fine with them as is).
>
> This is the port to PowerPC of the function graph tracer that was written
> by Frederic Weisbecker for the x86 architecture. It is broken up
> into a series of logical steps.
>
> 1) get generic code ready for other archs
> 2) get PowerPC 64-bit working with just static function tracing
> 3) get PowerPC 64-bit working with dynamic function tracing
> 4) get PowerPC 32-bit working with just static function tracing
> 5) get PowerPC 32-bit working with dynamic function tracing
>
> (with some clean ups in between)
>
Thanks a lot Steven!
I'm sad to not having a Power Pc to test it...
> The function graph tracer not only traces the start of a function
> (uses the function tracer part for that) but also uses the kprobes
> trick to replace the return address with a hook to trace the exit
> of the function. These hooks are generic in that other tracers
> can also use them. But the function graph tracer itself is very
> powerful. Simply doing the following:
>
> # echo function_graph > /debug/tracing/current_tracer
> # cat /debug/tracing/trace
>
> # tracer: function_graph
> #
> # CPU OVERHEAD/DURATION FUNCTION CALLS
> # | | | | | | |
> ------------------------------------------
> 0) less-2228 => cat-2229
> ------------------------------------------
>
> 0) | .__do_fault() {
> 0) | .filemap_fault() {
> 0) | .find_lock_page() {
> 0) | .find_get_page() {
> 0) 3.168 us | .__rcu_read_lock();
> 0) 2.704 us | .__rcu_read_unlock();
> 0) + 14.640 us | }
> 0) + 20.112 us | }
> 0) + 26.464 us | }
> 0) 2.912 us | ._spin_lock();
> 0) 2.656 us | .page_add_file_rmap();
> 0) | .update_mmu_cache() {
> 0) | .hash_preload() {
> 0) 2.368 us | .get_slice_psize();
> 0) 2.752 us | .hash_page_do_lazy_icache();
> 0) 3.568 us | .native_hpte_insert();
> 0) + 19.680 us | }
> 0) + 24.960 us | }
> 0) 2.336 us | ._spin_unlock();
> 0) | .unlock_page() {
> 0) 2.688 us | .page_waitqueue();
> 0) 2.608 us | .__wake_up_bit();
> 0) + 12.912 us | }
> 0) ! 351.776 us | }
> 0) ! 357.392 us | }
> 0) 3.040 us | .up_read();
> 0) | .compat_sys_ioctl() {
> 0) 3.024 us | .fget_light();
> 0) | .tty_compat_ioctl() {
> 0) 2.704 us | .tty_paranoia_check();
> 0) | .tty_ldisc_ref_wait() {
> 0) | .tty_ldisc_try() {
> 0) 2.880 us | ._spin_lock_irqsave();
> 0) 2.928 us | ._spin_unlock_irqrestore();
> 0) + 13.776 us | }
> 0) + 19.424 us | }
>
> [...]
>
> As you can see, it gives a nice call trace of the functions being called
> at run time, as well as a time stamp of how much time the function
> took to execute.
>
> Adding dynamic tracing to the mix, we can trace a single function:
>
> # echo .do_fork > /debug/tracing/set_graph_function
> # echo function_graph > /debug/tracing/current_tracer
> # cat /debug/tracing/trace
>
> # tracer: function_graph
> #
> # CPU OVERHEAD/DURATION FUNCTION CALLS
> # | | | | | | |
> 1) | .do_fork() {
> 1) | .copy_process() {
> 1) | .prepare_to_copy() {
> 1) 2.944 us | .flush_fp_to_thread();
> 1) 2.800 us | .flush_altivec_to_thread();
> 1) 2.608 us | .flush_vsx_to_thread();
> 1) + 19.184 us | }
> 1) | .kmem_cache_alloc() {
> 1) 2.464 us | .slab_should_failslab();
> 1) 8.304 us | }
> 1) | .alloc_thread_info() {
> 1) | .kmem_cache_alloc() {
> 1) 2.512 us | .slab_should_failslab();
> 1) 8.224 us | }
> 1) + 13.344 us | }
> 1) 7.584 us | .arch_dup_task_struct();
> 1) | .copy_creds() {
> 1) 2.736 us | .__mutex_init();
> 1) | .prepare_creds() {
> 1) | .kmem_cache_alloc() {
> 1) 2.640 us | .slab_should_failslab();
> 1) 8.368 us | }
>
> [...]
>
>
> Note, the '.' in the '.do_fork' is a PowerPC64 thing. PowerPC32 and
> other archs just need to do 'do_fork', without the dot.
>
>
> The following patches are in:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/rostedt/linux-2.6-trace.git
>
> branch: rfc/ppc/ftrace
>
>
> Steven Rostedt (7):
> tracing/function-graph-tracer: make arch generic push pop functions
> powerpc64: port of the function graph tracer
> powerpc64, tracing: add function graph tracer with dynamic tracing
> powerpc64, ftrace: save toc only on modules for function graph
> powerpc32, ftrace: save and restore mcount regs with macro
> powerpc32, ftrace: port function graph tracer to ppc32, static only
> powerpc32, ftrace: dynamic function graph tracer
>
> ----
> arch/powerpc/Kconfig | 1 +
> arch/powerpc/include/asm/ftrace.h | 39 ++++++++++-
> arch/powerpc/kernel/Makefile | 9 +-
> arch/powerpc/kernel/entry_32.S | 115 ++++++++++++++---------------
> arch/powerpc/kernel/entry_64.S | 89 +++++++++++++++++++++-
> arch/powerpc/kernel/ftrace.c | 135 ++++++++++++++++++++++++++++++++--
> arch/powerpc/kernel/process.c | 16 ++++
> arch/powerpc/kernel/vmlinux.lds.S | 1 +
> arch/x86/include/asm/ftrace.h | 25 ------
> arch/x86/kernel/ftrace.c | 75 +------------------
> include/linux/ftrace.h | 24 ++++++
> kernel/trace/trace_functions_graph.c | 75 +++++++++++++++++++
> 12 files changed, 428 insertions(+), 176 deletions(-)
> --
^ permalink raw reply
* Re: next Feb 10: mm/slqb build break
From: David Miller @ 2009-02-12 1:47 UTC (permalink / raw)
To: npiggin; +Cc: sfr, linux-kernel, linuxppc-dev, penberg, linux-next
In-Reply-To: <20090212014503.GD30043@wotan.suse.de>
From: Nick Piggin <npiggin@suse.de>
Date: Thu, 12 Feb 2009 02:45:03 +0100
> On Tue, Feb 10, 2009 at 01:53:51PM +0200, Pekka Enberg wrote:
> > Actually, that's not the root cause here. You seem to have CONFIG_SMP
> > disabled but CONFIG_NUMA enabled. That's not possible on x86 which
> > makes me think it's a ppc kconfig bug. Hmm?
>
> If it is really a valid config, then we should be able to make
> slqb build with it...
FWIW I only allow NUMA with SMP on sparc64, just like x86.
Although it seems IA64, like powerpc, does not have this restriction.
Hmmm...
^ permalink raw reply
* Re: next Feb 10: mm/slqb build break
From: Nick Piggin @ 2009-02-12 1:45 UTC (permalink / raw)
To: Pekka Enberg; +Cc: Stephen Rothwell, linux-next, LKML, linuxppc-dev
In-Reply-To: <84144f020902100353x4074f342ne4d61483074a06b7@mail.gmail.com>
On Tue, Feb 10, 2009 at 01:53:51PM +0200, Pekka Enberg wrote:
> On Tue, Feb 10, 2009 at 11:54 AM, Sachin P. Sant <sachinp@in.ibm.com> wrote:
> > Sachin P. Sant wrote:
> >>
> >> Hi Stephen,
> >>
> >> Todays next randconfig build on powerpc fails with
> >>
> >> CC mm/slqb.o
> >> mm/slqb.c: In function __slab_free:
> >> mm/slqb.c:1648: error: implicit declaration of function
> >> slab_free_to_remote
> >> mm/slqb.c: In function kmem_cache_open:
> >> mm/slqb.c:2174: error: implicit declaration of function
> >> kmem_cache_dyn_array_free
> >> mm/slqb.c:2175: warning: label error_cpu_array defined but not used
> >> mm/slqb.c: In function kmem_cache_destroy:
> >> mm/slqb.c:2294: error: implicit declaration of function
> >> claim_remote_free_list
> >> mm/slqb.c: In function kmem_cache_reap_percpu:
> >> mm/slqb.c:2547: error: implicit declaration of function
> >> flush_remote_free_cache
> >> mm/slqb.c: In function kmem_cache_init:
> >> mm/slqb.c:2783: error: per_cpu__kmem_cpu_nodes undeclared (first use in
> >> this function)
> >> mm/slqb.c:2783: error: (Each undeclared identifier is reported only once
> >> mm/slqb.c:2783: error: for each function it appears in.)
> >> mm/slqb.c:2784: error: kmem_cpu_cache undeclared (first use in this
> >> function)
> >> make[1]: *** [mm/slqb.o] Error 1
> >> make: *** [mm] Error 2
> >
> > CONFIG_SMP is not set hence the failure.
>
> Actually, that's not the root cause here. You seem to have CONFIG_SMP
> disabled but CONFIG_NUMA enabled. That's not possible on x86 which
> makes me think it's a ppc kconfig bug. Hmm?
If it is really a valid config, then we should be able to make
slqb build with it...
^ permalink raw reply
* RE: AMCC ppc440spe 2.6.23.10 kernel boot help
From: Shubhada Pugaonkar @ 2009-02-12 1:36 UTC (permalink / raw)
To: Wolfgang Denk; +Cc: linuxppc-dev
Hi Wolfgang=20
Thanks for quick response.=20
I am kind of helpless regarding the kernel version, as our customer is
using it and I need to replicate their environment. I just tried 2.6.28
with katmai_defconfig file and still face the same problem.=20
The config file that I sent before is provided by the customer. It is a
working configuration for them.=20
The exact board that I have is Katmai.
I verified that I am using serial port 0. I tried to set bootargs to
just console=3DttyS0,115200 and I don't see the kernel booting. =
Everything
in env variables seems ok to me unless something trivial is missing my
eyes.=20
My sequence for boot is=20
=3D>tftp 0x1000000 uImage-ppc
=3D> run flash_nfs (I have done this manually also)=20
my printenv output is as follows.
Thanks for your help
Shubhada
-----------------------------------------------------------------
bootdelay=3D5
baudrate=3D115200
loads_echo=3D1
netdev=3Deth0
addtty=3Dsetenv bootargs ${bootargs} console=3DttyS0,${baudrate}
net_nfs=3Dtftp 200000 ${bootfile};run nfsargs addip addtty;bootm
initrd_high=3D30000000
load=3Dtftp 200000 katmai/u-boot.bin
update=3Dprotect off fffc0000 ffffffff;era fffc0000 ffffffff;cp.b
${fileaddr} fffc0000 ${filesize};setenv filesize;saveenv
upd=3Drun load;run update
kozio=3Dbootm ffc60000
loadkernel=3Dfatload ace 0 0x1000000 /mnt-xsa/kernel.img
loadramdisk=3Dfatload ace 0 0x3000000 /mnt-xsa/ramdisk.img
ramargs=3Dsetenv bootargs ramdisk=3D65536 root=3D/dev/ram rw
ramdisk_addr=3D0x3000000
preboot=3Decho;echo Type "run flash_nfs" to mount root filesystem over
NFS;echo
bootcmd=3Drun loadkernel;run loadramdisk;run flash_self
ethact=3Dppc_4xx_eth0
fixedip=3Decho Using IP address ${ipaddr}
addip=3D${fixedip}
setip=3Dsetenv bootargs ${bootargs}
ip=3D${ipaddr}:${severip}:${gatewayip}:${netmask}:${hostname}:${netdev}:o=
f
f panic=3D1
flash_self=3Drun ramargs addip setip addtty;bootm ${kernel_addr}
${ramdisk_addr}
dynip=3Dsetenv autoload n;dhcp
flash_nfs=3Drun nfsargs addip setip addtty;bootm ${kernel_addr}
ethaddr=3D00:01:73:77:56:64
hostname=3Dppcb1
gw=3D10.192.160.1
net_nfs=3Dtftp 200000 ppc-2.6.23.10
severip=3D10.192.165.106
kerel_addr=3D0x100000
kernel_addr=3D0x1000000
filesize=3D1136BB
fileaddr=3D1000000
gatewayip=3D10.192.160.1
netmask=3D255.255.240.0
ipaddr=3D10.192.164.166
serverip=3D10.192.165.106
rootpath=3D/opt/eldk4.1/ppc_4xx
nfsargs=3Dsetenv bootargs root=3D/dev/nfs rw
nfsroot=3D10.192.165.106:/opt/eldk4.1/ppc_4xx
bootfile=3DuImage-ppc
stdin=3Dserial
stdout=3Dserial
stderr=3Dserial
ver=3DU-Boot 1.3.1-gc1d16334 (Jan 9 2008 - 11:26:13)
bootargs=3Droot=3D/dev/nfs rw =
nfsroot=3D10.192.165.106:/opt/eldk4.1/ppc_4xx
ip=3D10.192.164.166:10.192.165.106:10.192.160.1:255.255.240.0:ppcb1:eth0:=
o
ff console=3DttyS0,115200
Environment size: 1770/16379 bytes
------------------------------------------------------------------------
--
-----Original Message-----
From: Wolfgang Denk [mailto:wd@denx.de]=20
Sent: Wednesday, February 11, 2009 3:56 PM
To: Shubhada Pugaonkar
Cc: linuxppc-dev@ozlabs.org
Subject: Re: AMCC ppc440spe 2.6.23.10 kernel boot help
Dear "Shubhada Pugaonkar",
In message
<8A71B368A89016469F72CD08050AD33402D57544@maui.asicdesigners.com> you
wrote:
>=20
> I am trying to bringup AMCC ppc440sPE board with 2.6.23.10 kernel
from
2.6.23.10 is very old. Please use current code. 2.6.23 was long before
the switch to arch/powerpc, so all the efforts you are spnding now on
this old stuff are really wasted.
Use at least 2.6.28 or later.
> kernel.org. My .config file is attached. I used ARCH=3Dppc and
Why don't you start with a good, known to work kernel config file
like 44x/katmai_defconfig ?
For example, you mention a 440SPe processor above, but your config
file seems to be derived from a Luan board, which is 440SP (not SPe)
so there is not much surprise if it doesn't work.
> CROSS_COMPILE=3Dppc-linux- (also tried ppc_4xx-) and did 'make =
uImage',
> but unable to boot into the kernel. My nfs and uboot settings seem to
be
> correct. The kernel gets stuck as shown below. Any help appreciated.
> Please let me know if any more information is required.
In the first place, please use current code.
Second - which exact board is this? Katmai?
> =3D> run flash_nfs
What exactly are your environment settings? Which exact value of
"bootargs" do you pass to Linux? Does it include a valid console=3D
argument?
Best regards,
Wolfgang Denk
--=20
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de
"If you'll excuse me a minute, I'm going to have a cup of coffee."
- broadcast from Apollo 11's LEM, "Eagle", to Johnson Space Center,
Houston July 20, 1969, 7:27 P.M.
^ permalink raw reply
* [PATCH 7/7][RFC] powerpc32, ftrace: dynamic function graph tracer
From: Steven Rostedt @ 2009-02-12 1:10 UTC (permalink / raw)
To: linux-kernel
Cc: linuxppc-dev, Paul Mackerras, Frederic Weisbecker, Ingo Molnar,
Andrew Morton
In-Reply-To: <20090212011051.265346435@goodmis.org>
From: Steven Rostedt <rostedt@gollum.(none)>
This patch gets function graph tracing working with dynamic function
tracer on PowerPC32.
Signed-off-by: Steven Rostedt <rostedt@gollum.(none)>
---
arch/powerpc/Kconfig | 2 +-
arch/powerpc/kernel/entry_32.S | 8 ++++++--
2 files changed, 7 insertions(+), 3 deletions(-)
diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
index 9e4bd20..40b7981 100644
--- a/arch/powerpc/Kconfig
+++ b/arch/powerpc/Kconfig
@@ -111,7 +111,7 @@ config PPC
select HAVE_FTRACE_MCOUNT_RECORD
select HAVE_DYNAMIC_FTRACE
select HAVE_FUNCTION_TRACER
- select HAVE_FUNCTION_GRAPH_TRACER if PPC64 || !DYNAMIC_FTRACE
+ select HAVE_FUNCTION_GRAPH_TRACER
select ARCH_WANT_OPTIONAL_GPIOLIB
select HAVE_IDE
select HAVE_IOREMAP_PROT
diff --git a/arch/powerpc/kernel/entry_32.S b/arch/powerpc/kernel/entry_32.S
index 9cf7083..529bfbb 100644
--- a/arch/powerpc/kernel/entry_32.S
+++ b/arch/powerpc/kernel/entry_32.S
@@ -1183,7 +1183,12 @@ _GLOBAL(ftrace_caller)
ftrace_call:
bl ftrace_stub
nop
-
+#ifdef CONFIG_FUNCTION_GRAPH_TRACER
+.globl ftrace_graph_call
+ftrace_graph_call:
+ b ftrace_graph_stub
+_GLOBAL(ftrace_graph_stub)
+#endif
MCOUNT_RESTORE_FRAME
/* old link register ends up in ctr reg */
bctr
@@ -1205,7 +1210,6 @@ _GLOBAL(_mcount)
b ftrace_graph_caller
#endif
MCOUNT_RESTORE_FRAME
-
bctr
#endif
--
1.5.6.5
--
^ permalink raw reply related
* [PATCH 5/7][RFC] powerpc32, ftrace: save and restore mcount regs with macro
From: Steven Rostedt @ 2009-02-12 1:10 UTC (permalink / raw)
To: linux-kernel
Cc: linuxppc-dev, Paul Mackerras, Frederic Weisbecker, Ingo Molnar,
Andrew Morton
In-Reply-To: <20090212011051.265346435@goodmis.org>
From: Steven Rostedt <rostedt@gollum.(none)>
Impact: clean up
Use a macro to save and restore the registers for PowerPC32,
since that code is duplicated.
This is similar to the work done by Cyrill Gorcunov for the
mcount code in x86_64.
Signed-off-by: Steven Rostedt <rostedt@gollum.(none)>
---
arch/powerpc/include/asm/ftrace.h | 39 ++++++++++++++++++++-
arch/powerpc/kernel/entry_32.S | 68 +++++--------------------------------
2 files changed, 47 insertions(+), 60 deletions(-)
diff --git a/arch/powerpc/include/asm/ftrace.h b/arch/powerpc/include/asm/ftrace.h
index e5f2ae8..dde1296 100644
--- a/arch/powerpc/include/asm/ftrace.h
+++ b/arch/powerpc/include/asm/ftrace.h
@@ -5,7 +5,44 @@
#define MCOUNT_ADDR ((long)(_mcount))
#define MCOUNT_INSN_SIZE 4 /* sizeof mcount call */
-#ifndef __ASSEMBLY__
+#ifdef __ASSEMBLY__
+
+/* Based off of objdump optput from glibc */
+
+#define MCOUNT_SAVE_FRAME \
+ stwu r1,-48(r1); \
+ stw r3, 12(r1); \
+ stw r4, 16(r1); \
+ stw r5, 20(r1); \
+ stw r6, 24(r1); \
+ mflr r3; \
+ lwz r4, 52(r1); \
+ mfcr r5; \
+ stw r7, 28(r1); \
+ stw r8, 32(r1); \
+ stw r9, 36(r1); \
+ stw r10,40(r1); \
+ stw r3, 44(r1); \
+ stw r5, 8(r1)
+
+#define MCOUNT_RESTORE_FRAME \
+ lwz r6, 8(r1); \
+ lwz r0, 44(r1); \
+ lwz r3, 12(r1); \
+ mtctr r0; \
+ lwz r4, 16(r1); \
+ mtcr r6; \
+ lwz r5, 20(r1); \
+ lwz r6, 24(r1); \
+ lwz r0, 52(r1); \
+ lwz r7, 28(r1); \
+ lwz r8, 32(r1); \
+ mtlr r0; \
+ lwz r9, 36(r1); \
+ lwz r10,40(r1); \
+ addi r1, r1, 48
+
+#else /* !__ASSEMBLY__ */
extern void _mcount(void);
#ifdef CONFIG_DYNAMIC_FTRACE
diff --git a/arch/powerpc/kernel/entry_32.S b/arch/powerpc/kernel/entry_32.S
index 6f7eb7e..eb0c13e 100644
--- a/arch/powerpc/kernel/entry_32.S
+++ b/arch/powerpc/kernel/entry_32.S
@@ -1176,59 +1176,22 @@ _GLOBAL(_mcount)
bctr
_GLOBAL(ftrace_caller)
- /* Based off of objdump optput from glibc */
- stwu r1,-48(r1)
- stw r3, 12(r1)
- stw r4, 16(r1)
- stw r5, 20(r1)
- stw r6, 24(r1)
- mflr r3
- lwz r4, 52(r1)
- mfcr r5
- stw r7, 28(r1)
- stw r8, 32(r1)
- stw r9, 36(r1)
- stw r10,40(r1)
- stw r3, 44(r1)
- stw r5, 8(r1)
+ MCOUNT_SAVE_FRAME
+ /* r3 ends up with link register */
subi r3, r3, MCOUNT_INSN_SIZE
.globl ftrace_call
ftrace_call:
bl ftrace_stub
nop
- lwz r6, 8(r1)
- lwz r0, 44(r1)
- lwz r3, 12(r1)
- mtctr r0
- lwz r4, 16(r1)
- mtcr r6
- lwz r5, 20(r1)
- lwz r6, 24(r1)
- lwz r0, 52(r1)
- lwz r7, 28(r1)
- lwz r8, 32(r1)
- mtlr r0
- lwz r9, 36(r1)
- lwz r10,40(r1)
- addi r1, r1, 48
+
+ MCOUNT_RESTORE_FRAME
+ /* old link register ends up in ctr reg */
bctr
#else
_GLOBAL(mcount)
_GLOBAL(_mcount)
- stwu r1,-48(r1)
- stw r3, 12(r1)
- stw r4, 16(r1)
- stw r5, 20(r1)
- stw r6, 24(r1)
- mflr r3
- lwz r4, 52(r1)
- mfcr r5
- stw r7, 28(r1)
- stw r8, 32(r1)
- stw r9, 36(r1)
- stw r10,40(r1)
- stw r3, 44(r1)
- stw r5, 8(r1)
+
+ MCOUNT_SAVE_FRAME
subi r3, r3, MCOUNT_INSN_SIZE
LOAD_REG_ADDR(r5, ftrace_trace_function)
@@ -1239,21 +1202,8 @@ _GLOBAL(_mcount)
nop
- lwz r6, 8(r1)
- lwz r0, 44(r1)
- lwz r3, 12(r1)
- mtctr r0
- lwz r4, 16(r1)
- mtcr r6
- lwz r5, 20(r1)
- lwz r6, 24(r1)
- lwz r0, 52(r1)
- lwz r7, 28(r1)
- lwz r8, 32(r1)
- mtlr r0
- lwz r9, 36(r1)
- lwz r10,40(r1)
- addi r1, r1, 48
+ MCOUNT_RESTORE_FRAME
+
bctr
#endif
--
1.5.6.5
--
^ permalink raw reply related
* [PATCH 6/7][RFC] powerpc32, ftrace: port function graph tracer to ppc32, static only
From: Steven Rostedt @ 2009-02-12 1:10 UTC (permalink / raw)
To: linux-kernel
Cc: linuxppc-dev, Paul Mackerras, Frederic Weisbecker, Ingo Molnar,
Andrew Morton
In-Reply-To: <20090212011051.265346435@goodmis.org>
From: Steven Rostedt <rostedt@goodmis.org>
This patch ports the function graph tracer for PowerPC, but only
for static function tracing.
Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
---
arch/powerpc/Kconfig | 2 +-
arch/powerpc/kernel/entry_32.S | 43 +++++++++++++++++++++++++++++++++++++++-
arch/powerpc/kernel/ftrace.c | 2 +-
3 files changed, 44 insertions(+), 3 deletions(-)
diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
index 6e1ee1b..9e4bd20 100644
--- a/arch/powerpc/Kconfig
+++ b/arch/powerpc/Kconfig
@@ -111,7 +111,7 @@ config PPC
select HAVE_FTRACE_MCOUNT_RECORD
select HAVE_DYNAMIC_FTRACE
select HAVE_FUNCTION_TRACER
- select HAVE_FUNCTION_GRAPH_TRACER if PPC64
+ select HAVE_FUNCTION_GRAPH_TRACER if PPC64 || !DYNAMIC_FTRACE
select ARCH_WANT_OPTIONAL_GPIOLIB
select HAVE_IDE
select HAVE_IOREMAP_PROT
diff --git a/arch/powerpc/kernel/entry_32.S b/arch/powerpc/kernel/entry_32.S
index eb0c13e..9cf7083 100644
--- a/arch/powerpc/kernel/entry_32.S
+++ b/arch/powerpc/kernel/entry_32.S
@@ -1199,9 +1199,11 @@ _GLOBAL(_mcount)
mtctr r5
bctrl
-
nop
+#ifdef CONFIG_FUNCTION_GRAPH_TRACER
+ b ftrace_graph_caller
+#endif
MCOUNT_RESTORE_FRAME
bctr
@@ -1210,4 +1212,43 @@ _GLOBAL(_mcount)
_GLOBAL(ftrace_stub)
blr
+#ifdef CONFIG_FUNCTION_GRAPH_TRACER
+_GLOBAL(ftrace_graph_caller)
+ /* load r4 with local address */
+ lwz r4, 44(r1)
+ subi r4, r4, MCOUNT_INSN_SIZE
+
+ /* get the parent address */
+ addi r3, r1, 52
+
+ bl prepare_ftrace_return
+ nop
+
+ MCOUNT_RESTORE_FRAME
+ /* old link register ends up in ctr reg */
+ bctr
+
+_GLOBAL(return_to_handler)
+ /* need to save return values */
+ stwu r1, -32(r1)
+ stw r3, 20(r1)
+ stw r4, 16(r1)
+ stw r31, 12(r1)
+ mr r31, r1
+
+ bl ftrace_return_to_handler
+ nop
+
+ /* return value has real return address */
+ mtlr r3
+
+ lwz r3, 20(r1)
+ lwz r4, 16(r1)
+ lwz r31,12(r1)
+ lwz r1, 0(r1)
+
+ /* Jump back to real return address */
+ blr
+#endif /* CONFIG_FUNCTION_GRAPH_TRACER */
+
#endif /* CONFIG_MCOUNT */
diff --git a/arch/powerpc/kernel/ftrace.c b/arch/powerpc/kernel/ftrace.c
index 5c6dfa9..dddd99b 100644
--- a/arch/powerpc/kernel/ftrace.c
+++ b/arch/powerpc/kernel/ftrace.c
@@ -603,7 +603,7 @@ void prepare_ftrace_return(unsigned long *parent, unsigned long self_addr)
"1: " PPC_LL "%[old], 0(%[parent])\n"
"2: " PPC_STL "%[return_hooker], 0(%[parent])\n"
" li %[faulted], 0\n"
- "3:"
+ "3:\n"
".section .fixup, \"ax\"\n"
"4: li %[faulted], 1\n"
--
1.5.6.5
--
^ permalink raw reply related
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