Re: [RFC PATCH v5 1/9] fadump: Add documentation for firmware-assisted dump.
On 11/25/2011 04:04 AM, Paul Mackerras wrote: > On Tue, Nov 15, 2011 at 08:43:34PM +0530, Mahesh J Salgaonkar wrote: >> From: Mahesh Salgaonkar >> >> Documentation for firmware-assisted dump. This document is based on the >> original documentation written for phyp assisted dump by Linas Vepstas >> and Manish Ahuja, with few changes to reflect the current implementation. >> >> Change in v3: >> - Modified the documentation to reflect introdunction of fadump_registered >> sysfs file and few minor changes. >> >> Change in v2: >> - Modified the documentation to reflect the change of fadump_region >> file under debugfs filesystem. > > In general we don't want the changes between successive versions in > the patch description; this information should go below the "---" > line. The patch description should describe how the patch is now and > give any information that will be useful to someone looking at the > resulting git commit later on, but it doesn't need to tell us about > previous versions of the patch that will never appear in the git > history. Sure will do that. > >> +-- Once the dump is copied out, the memory that held the dump >> + is immediately available to the running kernel. A further >> + reboot isn't required. > > I have a general worry about the system making allocations that are > intended to be node-local while it is running with restricted memory > (i.e. after the crash and reboot and before the dump has been written > out and the dump memory freed). Those allocations will probably all > come from one node and thus won't necessarily be on the desired node. > So, for very large systems with significant NUMA characteristics, it > may be desirable (though not required) to reboot after taking the > dump. I have been working on trying to integrate FADUMP with the kdump infrastructure on distros, which will modify the existing kernel initrd to capture the vmcore and release the memory at the very early stage before the switch_root. However, by default FADUMP will also reboot after capturing vmcore unless user specifies 'noreboot' option through kdump configuration file. > > What happens about the NUMA information in the kernel -- all the > memory sections, etc.? Do they get set up as normal even though the > second kernel is booting with only a small amount of memory initially? > In FADUMP case, the booting of second kernel after crash is equivalent to normal kernel bootup and it boots with the knowledge of entire system RAM with NUMA information. The memblock structure does contain map for entire system RAM. We just reserve the memory above the bootmem at the very early stage in the second kernel, so that it remains untouched. Thanks, -Mahesh. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] powerpc/40x: Add APM8018X SOC support
Hello Arnd,
Thanks for the comments. Please see inline replies.
Regards,
Tanmay
On Wed, Nov 23, 2011 at 7:45 PM, Arnd Bergmann wrote:
> On Wednesday 23 November 2011, Tanmay Inamdar wrote:
> > The AppliedMicro APM8018X embedded processor targets embedded
> applications that
> > require low power and a small footprint. It features a PowerPC 405
> processor
> > core built in a 65nm low-power CMOS process with a five-stage pipeline
> executing
> > up to one instruction per cycle. The family has 128-kbytes of on-chip
> memory,
> > a 128-bit local bus and on-chip DDR2 SDRAM controller with 16-bit
> interface.
>
> Hi Tanmay,
>
> > +#if defined(CONFIG_APM8018X)
> > +#define DCRN_CPR0_ADDR 0xa
> > +#define DCRN_CPR0_DATA 0xb
> > +#else
> > /* 440EP Clock/Power-on Reset regs */
> > #define DCRN_CPR0_ADDR 0xc
> > #define DCRN_CPR0_DATA 0xd
> > +#endif /* CONFIG_APM8018X */
>
> This prevents you from building one kernel that runs on both APM8018X and
> others. Better define a new constant name for the new registers and select
> the right one at run-time.
>
> > diff --git a/arch/powerpc/boot/dts/klondike.dts
> b/arch/powerpc/boot/dts/klondike.dts
> > new file mode 100644
> > index 000..9372a52
> > --- /dev/null
> > +++ b/arch/powerpc/boot/dts/klondike.dts
> > @@ -0,0 +1,668 @@
> > +/*
> > + * Device Tree Source for AMCC Klondike (405)
> > + *
>
> The device tree file for the most part describes the chip, but partly also
> the board. Have you considered splitting the soc parts into a .dtsi file
> and moving all the configuration into a separate file?
>
Thanks for suggesting this. I will consider using .dtsi now.
>
>
> > diff --git a/arch/powerpc/configs/40x/klondike_defconfig
> b/arch/powerpc/configs/40x/klondike_defconfig
> > new file mode 100644
> > index 000..840f438
> > --- /dev/null
> > +++ b/arch/powerpc/configs/40x/klondike_defconfig
> > @@ -0,0 +1,1353 @@
> > +#
> > +# Automatically generated file; DO NOT EDIT.
> > +# Linux/powerpc 3.2.0-rc2 Kernel Configuration
> > +#
> > +# CONFIG_PPC64 is not set
> > +
>
> Please use 'make savedefconfig' to create a minimal defconfig file instead
> of listing
> the full configuration here.
>
Yes.
>
> > diff --git a/arch/powerpc/include/asm/dcr-regs.h
> b/arch/powerpc/include/asm/dcr-regs.h
> > index 380274d..c900cfd 100644
> > --- a/arch/powerpc/include/asm/dcr-regs.h
> > +++ b/arch/powerpc/include/asm/dcr-regs.h
> > @@ -24,9 +24,18 @@
> > * of the driver main register set
> > */
> >
> > +#if defined(CONFIG_APM8018X)
> > +/* CPR */
> > +#define DCRN_CPR0_CONFIG_ADDR0xa
> > +#define DCRN_CPR1_CONFIG_DATA0xb
> > +/* AHB */
> > +#define DCRN_SDR1_CONFIG_ADDR0xc
> > +#define DCRN_SDR1_CONFIG_DATA0xd
> > +#else
> > /* CPRs (440GX and 440SP/440SPe) */
> > #define DCRN_CPR0_CONFIG_ADDR0xc
> > #define DCRN_CPR0_CONFIG_DATA0xd
> > +#endif /* CONFIG_APM8018X */
>
> same comment as above.
>
Some existing drivers use these macros. If I change the names, I will have
to update the
driver code.
>
> > diff --git a/arch/powerpc/kernel/cputable.c
> b/arch/powerpc/kernel/cputable.c
> > index edae5bb..e5c51a6 100644
> > --- a/arch/powerpc/kernel/cputable.c
> > +++ b/arch/powerpc/kernel/cputable.c
> > @@ -1505,6 +1505,58 @@ static struct cpu_spec __initdata cpu_specs[] = {
> > .machine_check = machine_check_4xx,
> > .platform = "ppc405",
> > },
> > + { /* APM80186-SK */
> > + .pvr_mask = 0x,
> > + .pvr_value = 0x7ff11432,
>
> If you mask out the lower bits, you only need a single entry instead of
> four identical ones.
>
You are right. But each PVR represent different version of SOC. If I create
single
entry, then I will have to give generic cpu_name which I don't want.
>
> > --- a/arch/powerpc/kernel/udbg_16550.c
> > +++ b/arch/powerpc/kernel/udbg_16550.c
> > @@ -18,6 +18,19 @@ extern void real_writeb(u8 data, volatile u8 __iomem
> *addr);
> > extern u8 real_205_readb(volatile u8 __iomem *addr);
> > extern void real_205_writeb(u8 data, volatile u8 __iomem *addr);
> >
> > +#ifdef CONFIG_UART_16550_WORD_ADDRESSABLE
> > +struct NS16550 {
> > + /* this struct must be packed */
> > + unsigned char rbr; /* 0 */ u8 s0[3];
> > + unsigned char ier; /* 1 */ u8 s1[3];
> > + unsigned char fcr; /* 2 */ u8 s2[3];
> > + unsigned char lcr; /* 3 */ u8 s3[3];
> > + unsigned char mcr; /* 4 */ u8 s4[3];
> > + unsigned char lsr; /* 5 */ u8 s5[3];
> > + unsigned char msr; /* 6 */ u8 s6[3];
> > + unsigned char scr; /* 7 */ u8 s7[3];
> > +};
> > +#else
> > struct NS16550 {
> > /* this struct must be packed */
> > unsigned char rbr; /* 0 */
> > @@ -29,6 +42,7 @@ struct NS16550 {
> > unsigned char msr; /* 6 */
> > unsigned char scr; /* 7 */
> > };
> > +#endif /* CONFIG_UART_16550_WORD_ADDRESSABLE */
> >
>
> Same things a
Re: [PATCH] powerpc/40x: Add APM8018X SOC support
On Friday 25 November 2011, Tanmay Inamdar wrote:
> > >
> > > +#if defined(CONFIG_APM8018X)
> > > +/* CPR */
> > > +#define DCRN_CPR0_CONFIG_ADDR0xa
> > > +#define DCRN_CPR1_CONFIG_DATA0xb
> > > +/* AHB */
> > > +#define DCRN_SDR1_CONFIG_ADDR0xc
> > > +#define DCRN_SDR1_CONFIG_DATA0xd
> > > +#else
> > > /* CPRs (440GX and 440SP/440SPe) */
> > > #define DCRN_CPR0_CONFIG_ADDR0xc
> > > #define DCRN_CPR0_CONFIG_DATA0xd
> > > +#endif /* CONFIG_APM8018X */
> >
> > same comment as above.
> >
>
> Some existing drivers use these macros. If I change the names, I will have
> to update the
> driver code.
Not so many apparently:
$ git grep DCRN_CPR._CONFIG
arch/powerpc/include/asm/dcr-regs.h:#define DCRN_CPR0_CONFIG_ADDR 0xc
arch/powerpc/include/asm/dcr-regs.h:#define DCRN_CPR0_CONFIG_DATA 0xd
arch/powerpc/kvm/44x_emulate.c: case DCRN_CPR0_CONFIG_ADDR:
arch/powerpc/kvm/44x_emulate.c: case DCRN_CPR0_CONFIG_DATA:
arch/powerpc/kvm/44x_emulate.c:
mtdcr(DCRN_CPR0_CONFIG_ADDR,
arch/powerpc/kvm/44x_emulate.c:
mfdcr(DCRN_CPR0_CONFIG_DATA));
arch/powerpc/kvm/44x_emulate.c: case DCRN_CPR0_CONFIG_ADDR:
Don't worry about out of tree drivers. If you want to be nice to the authors,
rename the macros so that the drivers break in an obvious way rather than
silently.
Note that any drivers relying on these as a constant are already broken
as soon as you try to build a kernel with both APM8018X and 440 enabled,
so you absolutely have to change the device drivers to work with those
kernels.
> > > diff --git a/arch/powerpc/kernel/cputable.c
> > b/arch/powerpc/kernel/cputable.c
> > > index edae5bb..e5c51a6 100644
> > > --- a/arch/powerpc/kernel/cputable.c
> > > +++ b/arch/powerpc/kernel/cputable.c
> > > @@ -1505,6 +1505,58 @@ static struct cpu_spec __initdata cpu_specs[] = {
> > > .machine_check = machine_check_4xx,
> > > .platform = "ppc405",
> > > },
> > > + { /* APM80186-SK */
> > > + .pvr_mask = 0x,
> > > + .pvr_value = 0x7ff11432,
> >
> > If you mask out the lower bits, you only need a single entry instead of
> > four identical ones.
> >
>
> You are right. But each PVR represent different version of SOC. If I create
> single
> entry, then I will have to give generic cpu_name which I don't want.
Isn't the common name for these always "APM80186"? If you don't need to tell
the difference between them for the purposes of cpu_spec, then don't do
it here.
Arnd
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] powerpc/40x: Add APM8018X SOC support
Hello, Please see inline comment. Regards, Tanmay On Wed, Nov 23, 2011 at 9:46 PM, Kumar Gala wrote: > > On Nov 23, 2011, at 3:44 AM, Tanmay Inamdar wrote: > > > arch/powerpc/kernel/udbg_16550.c | 22 + > > Would be probably good to split this change into its own patch. Sure. I will do it. > > - k CONFIDENTIALITY NOTICE: This e-mail message, including any attachments, is for the sole use of the intended recipient(s) and contains information that is confidential and proprietary to AppliedMicro Corporation or its subsidiaries. It is to be used solely for the purpose of furthering the parties' business relationship. All unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH net-next v2 4/4] powerpc: tqm8548/tqm8xx: add and update CAN device nodes
This patch enables or updates support for the CC770 and AN82527
CAN controller on the TQM8548 and TQM8xx boards.
CC: devicetree-disc...@lists.ozlabs.org
CC: linuxppc-...@ozlabs.org
CC: Kumar Gala
Signed-off-by: Wolfgang Grandegger
---
arch/powerpc/boot/dts/tqm8548-bigflash.dts | 19 ++-
arch/powerpc/boot/dts/tqm8548.dts | 19 ++-
arch/powerpc/boot/dts/tqm8xx.dts | 25 +
3 files changed, 53 insertions(+), 10 deletions(-)
diff --git a/arch/powerpc/boot/dts/tqm8548-bigflash.dts
b/arch/powerpc/boot/dts/tqm8548-bigflash.dts
index 9452c3c..d918752 100644
--- a/arch/powerpc/boot/dts/tqm8548-bigflash.dts
+++ b/arch/powerpc/boot/dts/tqm8548-bigflash.dts
@@ -352,7 +352,7 @@
ranges = <
0 0x0 0xfc00 0x0400 // NOR FLASH bank 1
1 0x0 0xf800 0x0800 // NOR FLASH bank 0
- 2 0x0 0xa300 0x8000 // CAN (2 x i82527)
+ 2 0x0 0xa300 0x8000 // CAN (2 x CC770)
3 0x0 0xa301 0x8000 // NAND FLASH
>;
@@ -393,18 +393,27 @@
};
/* Note: CAN support needs be enabled in U-Boot */
- can0@2,0 {
- compatible = "intel,82527"; // Bosch CC770
+ can@2,0 {
+ compatible = "bosch,cc770"; // Bosch CC770
reg = <2 0x0 0x100>;
interrupts = <4 1>;
interrupt-parent = <&mpic>;
+ bosch,external-clock-frequency = <1600>;
+ bosch,disconnect-rx1-input;
+ bosch,disconnect-tx1-output;
+ bosch,iso-low-speed-mux;
+ bosch,clock-out-frequency = <1600>;
};
- can1@2,100 {
- compatible = "intel,82527"; // Bosch CC770
+ can@2,100 {
+ compatible = "bosch,cc770"; // Bosch CC770
reg = <2 0x100 0x100>;
interrupts = <4 1>;
interrupt-parent = <&mpic>;
+ bosch,external-clock-frequency = <1600>;
+ bosch,disconnect-rx1-input;
+ bosch,disconnect-tx1-output;
+ bosch,iso-low-speed-mux;
};
/* Note: NAND support needs to be enabled in U-Boot */
diff --git a/arch/powerpc/boot/dts/tqm8548.dts
b/arch/powerpc/boot/dts/tqm8548.dts
index 619776f..988d887 100644
--- a/arch/powerpc/boot/dts/tqm8548.dts
+++ b/arch/powerpc/boot/dts/tqm8548.dts
@@ -352,7 +352,7 @@
ranges = <
0 0x0 0xfc00 0x0400 // NOR FLASH bank 1
1 0x0 0xf800 0x0800 // NOR FLASH bank 0
- 2 0x0 0xe300 0x8000 // CAN (2 x i82527)
+ 2 0x0 0xe300 0x8000 // CAN (2 x CC770)
3 0x0 0xe301 0x8000 // NAND FLASH
>;
@@ -393,18 +393,27 @@
};
/* Note: CAN support needs be enabled in U-Boot */
- can0@2,0 {
- compatible = "intel,82527"; // Bosch CC770
+ can@2,0 {
+ compatible = "bosch,cc770"; // Bosch CC770
reg = <2 0x0 0x100>;
interrupts = <4 1>;
interrupt-parent = <&mpic>;
+ bosch,external-clock-frequency = <1600>;
+ bosch,disconnect-rx1-input;
+ bosch,disconnect-tx1-output;
+ bosch,iso-low-speed-mux;
+ bosch,clock-out-frequency = <1600>;
};
- can1@2,100 {
- compatible = "intel,82527"; // Bosch CC770
+ can@2,100 {
+ compatible = "bosch,cc770"; // Bosch CC770
reg = <2 0x100 0x100>;
interrupts = <4 1>;
interrupt-parent = <&mpic>;
+ bosch,external-clock-frequency = <1600>;
+ bosch,disconnect-rx1-input;
+ bosch,disconnect-tx1-output;
+ bosch,iso-low-speed-mux;
};
/* Note: NAND support needs to be enabled in U-Boot */
diff --git a/arch/powerpc/boot/dts/tqm8xx.dts b/arch/powerpc/boot/dts/tqm8xx.dts
index f6da7ec..c3dba25 100644
--- a/arch/powerpc/boot/dts/tqm8xx.dts
+++ b/arch/powerpc/boot/dts/tqm8xx.dts
@@ -57,6 +57,7 @@
ranges = <
0x0 0x0 0x4000 0x80
+ 0x3 0x0 0xc000 0x200
>;
flash@0,0 {
@@ -67,
[PATCH net-next v2 3/4] can: cc770: add platform bus driver for the CC770 and AN82527
This driver works with both, static platform data and device tree
bindings. It has been tested on a TQM855L board with two AN82527
CAN controllers on the local bus.
CC: devicetree-disc...@lists.ozlabs.org
CC: linuxppc-...@ozlabs.org
CC: Kumar Gala
Signed-off-by: Wolfgang Grandegger
---
.../devicetree/bindings/net/can/cc770.txt | 56
drivers/net/can/cc770/Kconfig |7 +
drivers/net/can/cc770/Makefile |1 +
drivers/net/can/cc770/cc770_platform.c | 289
4 files changed, 353 insertions(+), 0 deletions(-)
create mode 100644 Documentation/devicetree/bindings/net/can/cc770.txt
create mode 100644 drivers/net/can/cc770/cc770_platform.c
diff --git a/Documentation/devicetree/bindings/net/can/cc770.txt
b/Documentation/devicetree/bindings/net/can/cc770.txt
new file mode 100644
index 000..01e282d
--- /dev/null
+++ b/Documentation/devicetree/bindings/net/can/cc770.txt
@@ -0,0 +1,56 @@
+Memory mapped Bosch CC770 and Intel AN82527 CAN controller
+
+Note: The CC770 is a CAN controller from Bosch, which is 100%
+compatible with the old AN82527 from Intel, but with "bugs" being fixed.
+
+Required properties:
+
+- compatible : should be "bosch,cc770" for the CC770 and "intc,82527"
+ for the AN82527.
+
+- reg : should specify the chip select, address offset and size required
+ to map the registers of the controller. The size is usually 0x80.
+
+- interrupts : property with a value describing the interrupt source
+ (number and sensitivity) required for the controller.
+
+Optional properties:
+
+- bosch,external-clock-frequency : frequency of the external oscillator
+ clock in Hz. Note that the internal clock frequency used by the
+ controller is half of that value. If not specified, a default
+ value of 1600 (16 MHz) is used.
+
+- bosch,clock-out-frequency : slock frequency in Hz on the CLKOUT pin.
+ If not specified or if the specified value is 0, the CLKOUT pin
+ will be disabled.
+
+- bosch,slew-rate : slew rate of the CLKOUT signal. If not specified,
+ a resonable value will be calculated.
+
+- bosch,disconnect-rx0-input : see data sheet.
+
+- bosch,disconnect-rx1-input : see data sheet.
+
+- bosch,disconnect-tx1-output : see data sheet.
+
+- bosch,polarity-dominant : see data sheet.
+
+- bosch,divide-memory-clock : see data sheet.
+
+- bosch,iso-low-speed-mux : see data sheet.
+
+For further information, please have a look to the CC770 or AN82527.
+
+Examples:
+
+can@3,100 {
+ compatible = "bosch,cc770";
+ reg = <3 0x100 0x80>;
+ interrupts = <2 0>;
+ interrupt-parent = <&mpic>;
+ bosch,external-clock-frequency = <1600>;
+};
+
+
+
diff --git a/drivers/net/can/cc770/Kconfig b/drivers/net/can/cc770/Kconfig
index 28e4d48..22c07a8 100644
--- a/drivers/net/can/cc770/Kconfig
+++ b/drivers/net/can/cc770/Kconfig
@@ -11,4 +11,11 @@ config CAN_CC770_ISA
connected to the ISA bus using I/O port, memory mapped or
indirect access.
+config CAN_CC770_PLATFORM
+ tristate "Generic Platform Bus based CC770 driver"
+ ---help---
+ This driver adds support for the CC770 and AN82527 chips
+ connected to the "platform bus" (Linux abstraction for directly
+ to the processor attached devices).
+
endif
diff --git a/drivers/net/can/cc770/Makefile b/drivers/net/can/cc770/Makefile
index 872ecff..9fb8321 100644
--- a/drivers/net/can/cc770/Makefile
+++ b/drivers/net/can/cc770/Makefile
@@ -4,5 +4,6 @@
obj-$(CONFIG_CAN_CC770) += cc770.o
obj-$(CONFIG_CAN_CC770_ISA) += cc770_isa.o
+obj-$(CONFIG_CAN_CC770_PLATFORM) += cc770_platform.o
ccflags-$(CONFIG_CAN_DEBUG_DEVICES) := -DDEBUG
diff --git a/drivers/net/can/cc770/cc770_platform.c
b/drivers/net/can/cc770/cc770_platform.c
new file mode 100644
index 000..a33f91d
--- /dev/null
+++ b/drivers/net/can/cc770/cc770_platform.c
@@ -0,0 +1,289 @@
+/*
+ * Driver for CC770 and AN82527 CAN controllers on the platform bus
+ *
+ * Copyright (C) 2009, 2011 Wolfgang Grandegger
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the version 2 of the GNU General Public License
+ * as published by the Free Software Foundation
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software Foundation,
+ * Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA.
+ */
+
+/*
+ * If platform data are used you should have similar definitions
+ * in your board-specific code:
+ *
+ * static struct cc770_platform_data myboard_cc770_pdata = {
+ * .osc_freq = 1600,
+ *
Re: [PATCH-RFC 01/10] lib: move GENERIC_IOMAP to lib/Kconfig
On Thu, Nov 24, 2011 at 09:15:42PM +0100, Michael S. Tsirkin wrote: > define GENERIC_IOMAP in a central location > instead of all architectures. This will be helpful > for the follow-up patch which makes it select > other configs. Code is also a bit shorter this way. > > Signed-off-by: Michael S. Tsirkin For the CRIS part: Acked-by: Jesper Nilsson /^JN - Jesper Nilsson -- Jesper Nilsson -- jesper.nils...@axis.com signature.asc Description: Digital signature ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: Enabling MBX in MPC5121 - OGLES kernel modules
Hi Wanted to repeat my previous email about enabling MBX in MPC5121. Anybody out there who can assist me ? regards Einar From: Einar Már Björgvinsson Sent: Tuesday, November 22, 2011 7:15 PM To: linuxppc-dev@lists.ozlabs.org Subject: Enabling MBX in MPC5121 - OGLES kernel modules Hi I've been working on enabling the PowerVR GPU core in MPC5121 chip. I've been following the documentation from here: http://www.datasheetarchive.com/indexdl/Datasheet-076/DSAE0026055.pdf This documentation was released in a bundle with MBX libraries and MBX kernel patches. Also have I downloaded the OGLES SDK from Imgtech where I've successfully built some demos for MPC5121. The last piece of the puzzle is to have the right kernel modules. There are some kernel modules provided in the documentation bundle but they are build against older kernel version (2.6.24) but I'm am using kernel version 2.6.33 with RT 29. What I'm hoping is that somebody have the source code for the following kernel modules: - pvr.ko - clcdc.ko - swcamera.ko - dgbdrv.ko Hope somebody out there can assist Regards Einar M. Bjorgvinsson Embedded Software Engineer Marel ehf Iceland ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: oprofile callgraph support missing for common cpus
On 11/25/2011 01:24 PM, Benjamin Herrenschmidt wrote: > On Fri, 2011-11-18 at 09:22 +0100, Joakim Tjernlund wrote: > >> I forgot to ask, oprofile mentions setting -no-omit-framepointer to get >> correct backtrace but I cannot turn on frame pointers for the ppc kernel. >> Isn't frame pointers needed for pcc? what about user space? > PowerPC always has frame pointers, ignore that :-) Recently I have met a similar problem on frame pointer but at arm_v7 variant in back tracing support for Oprofile, could you help me see it? thanks in advance: in my case, I have enabled Oprofile support in my arm_v7 thumb2 target, in the created binary image including kernel image and rootfs, seems that frame pointer is not enabled for arm thumb2, So I have met the following problems in back trace: I can get the right stack traces for kernel stack, but for user stack, the stack length is always one depth, why? Is this a known deficiency in supporting arm thumb2 for Oprofile stack trace? Thanks. B.R. --David > Cheers, > Ben. > > > > -- > All the data continuously generated in your IT infrastructure > contains a definitive record of customers, application performance, > security threats, fraudulent activity, and more. Splunk takes this > data and makes sense of it. IT sense. And common sense. > http://p.sf.net/sfu/splunk-novd2d > ___ > oprofile-list mailing list > oprofile-l...@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/oprofile-list ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
