Re: [PATCH 0/9] powerpc: port of dynamic ftrace
* Steven Rostedt [EMAIL PROTECTED] wrote: arch/powerpc/Kconfig |2 + arch/powerpc/include/asm/ftrace.h | 14 +- arch/powerpc/include/asm/module.h | 16 ++- arch/powerpc/kernel/ftrace.c | 473 +--- arch/powerpc/kernel/idle.c|5 + arch/powerpc/kernel/module_32.c | 10 + arch/powerpc/kernel/module_64.c | 13 + arch/x86/include/asm/ftrace.h |9 +- arch/x86/kernel/ftrace.c | 168 +- include/linux/ftrace.h| 51 - kernel/module.c |2 +- kernel/trace/ftrace.c | 137 ++-- scripts/recordmcount.pl | 20 ++- 13 files changed, 790 insertions(+), 130 deletions(-) Hm, something like this shouldnt be pulled into the powerpc tree: it touches the core kernel, x86 code and ftrace code as well. Please do the suggestion i outlined and which Paul agreed with: prepare a branch that touches _only_ powerpc files and gets these changes there, without actually breaking the build on powerpc. And please do not name the branch as hack - we dont want Paul to pull such a branch name - it will show up in the upstream git logs. Those changes should only touch powerpc files. Do not try to shoe-horn already applied ftrace commits into a separate branch with different sha1's. Yes, ftrace wont be enable-able on powerpc when that is pulled, but it will only be for a brief period shortly before the merge window. (and it will all just work fine when integrated together) Once this branch is done, and once Paul agrees that it looks OK-ish to him, we can put it into ftrace-next straight away [but still keep it in a separate topic tree in tip/tracing/powerpc - so it can all be reconsidered reversibly if it causes too much merge trouble]. Paul will then be able to pull it in a few weeks, in the runup to the v2.6.29 merge window. The other option is to go the slow route of 2-3 kernel releases to pull this all off. ok? Ingo ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH] powerpc: Add use of Epson RTX-8581 RTC to GE Fanuc SBC610 dts
Adding use of newly added Epson RTX-8581 real-time clock driver to GE
Fanuc SBC610's dts file and adding driver to default config.
Signed-off-by: Martyn Welch [EMAIL PROTECTED]
---
arch/powerpc/boot/dts/gef_sbc610.dts |5 +
arch/powerpc/configs/86xx/gef_sbc610_defconfig |8 ++--
2 files changed, 11 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/boot/dts/gef_sbc610.dts
b/arch/powerpc/boot/dts/gef_sbc610.dts
index c046190..ed230bf 100644
--- a/arch/powerpc/boot/dts/gef_sbc610.dts
+++ b/arch/powerpc/boot/dts/gef_sbc610.dts
@@ -146,6 +146,11 @@
interrupt-parent = mpic;
dfsrr;
+ [EMAIL PROTECTED] {
+ compatible = epson,rx8581;
+ reg = 0x0051;
+ };
+
[EMAIL PROTECTED] {
compatible = dallas,ds1682;
reg = 0x6b;
diff --git a/arch/powerpc/configs/86xx/gef_sbc610_defconfig
b/arch/powerpc/configs/86xx/gef_sbc610_defconfig
index 771b671..2e78ff4 100644
--- a/arch/powerpc/configs/86xx/gef_sbc610_defconfig
+++ b/arch/powerpc/configs/86xx/gef_sbc610_defconfig
@@ -1398,8 +1398,11 @@ CONFIG_USB_STORAGE=y
# CONFIG_ACCESSIBILITY is not set
# CONFIG_INFINIBAND is not set
# CONFIG_EDAC is not set
-CONFIG_RTC_LIB=m
-CONFIG_RTC_CLASS=m
+CONFIG_RTC_LIB=y
+CONFIG_RTC_CLASS=y
+CONFIG_RTC_HCTOSYS=y
+CONFIG_RTC_HCTOSYS_DEVICE=rtc0
+# CONFIG_RTC_DEBUG is not set
#
# RTC interfaces
@@ -1425,6 +1428,7 @@ CONFIG_RTC_INTF_DEV=y
# CONFIG_RTC_DRV_M41T80 is not set
# CONFIG_RTC_DRV_S35390A is not set
# CONFIG_RTC_DRV_FM3130 is not set
+CONFIG_RTC_DRV_RX8581=y
#
# SPI RTC drivers
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 0/9] powerpc: port of dynamic ftrace
On Thu, 20 Nov 2008, Ingo Molnar wrote: Hm, something like this shouldnt be pulled into the powerpc tree: it touches the core kernel, x86 code and ftrace code as well. Please do the suggestion i outlined and which Paul agreed with: prepare a branch that touches _only_ powerpc files and gets these changes there, without actually breaking the build on powerpc. And please do not name the branch as hack - we dont want Paul to pull such a branch name - it will show up in the upstream git logs. Those changes should only touch powerpc files. Do not try to shoe-horn already applied ftrace commits into a separate branch with different sha1's. Yes, ftrace wont be enable-able on powerpc when that is pulled, but it will only be for a brief period shortly before the merge window. (and it will all just work fine when integrated together) As stated in the original post, I also had a separate branch called ppc/ftrace-disable. Here's the generate posting if I were to send it: The following patches are in: git://git.kernel.org/pub/scm/linux/kernel/git/rostedt/linux-2.6-trace.git branch: ppc/ftrace-disable Matt Fleming (1): ftrace: align __mcount_loc sections Steven Rostedt (8): ftrace: disable dynamic ftrace from PowerPC powerpc: ftrace, do not latency trace idle powerpc: ftrace, convert to new dynamic ftrace arch API powerpc/ppc64: ftrace, mcount record powerpc port powerpc: ftrace, use probe_kernel API to modify code powerpc/ppc64: ftrace, handle module trampolines for dyn ftrace powerpc/ppc32: ftrace, enabled dynamic ftrace powerpc/ppc32: ftrace, dynamic ftrace to handle modules arch/powerpc/Kconfig |2 + arch/powerpc/include/asm/ftrace.h | 14 +- arch/powerpc/include/asm/module.h | 16 ++- arch/powerpc/kernel/ftrace.c | 473 +--- arch/powerpc/kernel/idle.c|5 + arch/powerpc/kernel/module_32.c | 10 + arch/powerpc/kernel/module_64.c | 13 + kernel/trace/Kconfig |1 + scripts/recordmcount.pl | 20 ++- 9 files changed, 511 insertions(+), 43 deletions(-) There is a dependency on Matt's commit for one of the PPC commits to apply. I could hack that commit to work without Matt's patch, but then that just postpones conflicts later on. Matt's change is this: scripts/recordmcount.pl | 20 ++- The commit to disable PPC is this: diff --git a/kernel/trace/Kconfig b/kernel/trace/Kconfig index 33dbefd..d9127f4 100644 --- a/kernel/trace/Kconfig +++ b/kernel/trace/Kconfig @@ -162,6 +162,7 @@ config DYNAMIC_FTRACE depends on FUNCTION_TRACER depends on HAVE_DYNAMIC_FTRACE depends on DEBUG_KERNEL + depends on !PPC default y help This option will modify all the calls to ftrace dynamically This does touch generic code, but this is to handle the chicken and the egg problem. I would like the disabling of PowerPC code in a separate commit (one easy to revert). But I can not disable the PowerPC code before the code is there. If I disable it after the code is there, then there exists a time that PowerPC will not compile due to this not being disabled. Once this branch is done, and once Paul agrees that it looks OK-ish to him, we can put it into ftrace-next straight away [but still keep it in a separate topic tree in tip/tracing/powerpc - so it can all be reconsidered reversibly if it causes too much merge trouble]. Paul will then be able to pull it in a few weeks, in the runup to the v2.6.29 merge window. I guess the question comes down to, do I work around Matt's patch? The other option is to go the slow route of 2-3 kernel releases to pull this all off. 2 or 3 kernel releases seems a bit extreme. But this is Paul's call. Paul, any suggestions? -- Steve ok? Ingo ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH] cpm2: Round the baud-rate clock divider to the nearest integer.
Instead of rounding the divider down, improve the baud-rate generators accuracy by rounding to the nearest integer. Signed-off-by: Laurent Pinchart [EMAIL PROTECTED] --- arch/powerpc/sysdev/cpm2.c |3 ++- 1 files changed, 2 insertions(+), 1 deletions(-) diff --git a/arch/powerpc/sysdev/cpm2.c b/arch/powerpc/sysdev/cpm2.c index f1c3395..474d176 100644 --- a/arch/powerpc/sysdev/cpm2.c +++ b/arch/powerpc/sysdev/cpm2.c @@ -129,7 +129,8 @@ void __cpm2_setbrg(uint brg, uint rate, uint clk, int div16, int src) brg -= 4; } bp += brg; - val = (((clk / rate) - 1) 1) | CPM_BRG_EN | src; + /* Round the clock divider to the nearest integer. */ + val = (((clk * 2 / rate) - 1) ~1) | CPM_BRG_EN | src; if (div16) val |= CPM_BRG_DIV16; -- 1.5.6.3 -- Laurent Pinchart CSE Semaphore Belgium Chaussee de Bruxelles, 732A B-1410 Waterloo Belgium T +32 (2) 387 42 59 F +32 (2) 387 42 75 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH] Add support for the nwp serial device
From: Benjamin Krill [EMAIL PROTECTED]
This patch adds support for the nwp serial device which is connected to
a DCR bus. It uses the of_serial device driver to determine necessary
properties from the device tree. The supported device is added as serial
port number 84.
Signed-off-by: Benjamin Krill [EMAIL PROTECTED]
Signed-off-by: Arnd Bergmann [EMAIL PROTECTED]
---
Since the serial drivers are still orphaned, should we merge this through
the powerpc tree?
---
drivers/serial/Kconfig | 11 +-
drivers/serial/Makefile |1 +
drivers/serial/nwpserial.c | 443 +++
drivers/serial/of_serial.c | 18 ++
include/linux/nwpserial.h | 18 ++
include/linux/serial_core.h |3 +
6 files changed, 493 insertions(+), 1 deletions(-)
create mode 100644 drivers/serial/nwpserial.c
create mode 100644 include/linux/nwpserial.h
diff --git a/drivers/serial/Kconfig b/drivers/serial/Kconfig
index 579d63a..45dcc8d 100644
--- a/drivers/serial/Kconfig
+++ b/drivers/serial/Kconfig
@@ -1297,13 +1297,22 @@ config SERIAL_NETX_CONSOLE
config SERIAL_OF_PLATFORM
tristate Serial port on Open Firmware platform bus
depends on PPC_OF
- depends on SERIAL_8250
+ depends on SERIAL_8250 || SERIAL_OF_PLATFORM_NWPSERIAL
help
If you have a PowerPC based system that has serial ports
on a platform specific bus, you should enable this option.
Currently, only 8250 compatible ports are supported, but
others can easily be added.
+config SERIAL_OF_PLATFORM_NWPSERIAL
+ tristate NWP serial port driver
+ depends on PPC_OF PPC_DCR
+ select SERIAL_OF_PLATFORM
+ select SERIAL_CORE_CONSOLE
+ select SERIAL_CORE
+ help
+ This driver supports the nwp serial port.
+
config SERIAL_QE
tristate Freescale QUICC Engine serial port support
depends on QUICC_ENGINE
diff --git a/drivers/serial/Makefile b/drivers/serial/Makefile
index 0c17c8d..05da19d 100644
--- a/drivers/serial/Makefile
+++ b/drivers/serial/Makefile
@@ -70,6 +70,7 @@ obj-$(CONFIG_SERIAL_ATMEL) += atmel_serial.o
obj-$(CONFIG_SERIAL_UARTLITE) += uartlite.o
obj-$(CONFIG_SERIAL_NETX) += netx-serial.o
obj-$(CONFIG_SERIAL_OF_PLATFORM) += of_serial.o
+obj-$(CONFIG_SERIAL_OF_PLATFORM_NWPSERIAL) += nwpserial.o
obj-$(CONFIG_SERIAL_KS8695) += serial_ks8695.o
obj-$(CONFIG_KGDB_SERIAL_CONSOLE) += kgdboc.o
obj-$(CONFIG_SERIAL_QE) += ucc_uart.o
diff --git a/drivers/serial/nwpserial.c b/drivers/serial/nwpserial.c
new file mode 100644
index 000..5f2ecab
--- /dev/null
+++ b/drivers/serial/nwpserial.c
@@ -0,0 +1,443 @@
+/*
+ * Serial Port driver for a NWP uart device
+ *
+ *Copyright (C) 2008 IBM Corp., Benjamin Krill [EMAIL PROTECTED]
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * as published by the Free Software Foundation; either version
+ * 2 of the License, or (at your option) any later version.
+ *
+ */
+#include linux/console.h
+#include linux/serial.h
+#include linux/serial_reg.h
+#include linux/serial_core.h
+#include linux/tty.h
+#include linux/irqreturn.h
+#include linux/mutex.h
+#include linux/of_platform.h
+#include linux/of_device.h
+#include linux/nwpserial.h
+#include asm/prom.h
+#include asm/dcr.h
+
+#define NWPSERIAL_NR 2
+
+#define NWPSERIAL_STATUS_RXVALID 0x1
+#define NWPSERIAL_STATUS_TXFULL 0x2
+
+struct nwpserial_port {
+ struct uart_port port;
+ dcr_host_t dcr_host;
+ unsigned int ier;
+ unsigned int mcr;
+};
+
+static DEFINE_MUTEX(nwpserial_mutex);
+static struct nwpserial_port nwpserial_ports[NWPSERIAL_NR];
+
+static void nwpserial_console_putchar(struct uart_port *port, int c)
+{
+ struct nwpserial_port *up = container_of(port, struct nwpserial_port,
port);
+ /* check if tx buffer is full */
+ while ((dcr_read(up-dcr_host, UART_LSR) UART_LSR_THRE) == 0)
+ cpu_relax();
+ dcr_write(up-dcr_host, UART_TX, c);
+ up-port.icount.tx++;
+}
+
+static void
+nwpserial_console_write(struct console *co, const char *s, unsigned int count)
+{
+ struct nwpserial_port *up = nwpserial_ports[co-index];
+ unsigned long flags;
+ int locked = 1;
+
+ if (oops_in_progress)
+ locked = spin_trylock_irqsave(up-port.lock, flags);
+ else
+ spin_lock_irqsave(up-port.lock, flags);
+
+ /* save and disable interrupt */
+ up-ier = dcr_read(up-dcr_host, UART_IER);
+ dcr_write(up-dcr_host, UART_IER, up-ier ~UART_IER_RDI);
+
+ uart_console_write(up-port, s, count, nwpserial_console_putchar);
+
+ /* wait for transmitter to become emtpy */
+ while ((dcr_read(up-dcr_host, UART_LSR) UART_LSR_THRE) == 0)
+ cpu_relax();
+
+ /* restore interrupt state */
+ dcr_write(up-dcr_host, UART_IER, up-ier);
+
+ if (locked)
+
Re: [PATCH] Add support for the nwp serial device
On Thu, Nov 20, 2008 at 03:01:23PM +0100, Arnd Bergmann wrote: From: Benjamin Krill [EMAIL PROTECTED] This patch adds support for the nwp serial device which is connected to a DCR bus. It uses the of_serial device driver to determine necessary properties from the device tree. The supported device is added as serial port number 84. What does 'NWP' stand for, and how is it different from a regular serial port? Also, what platforms can this device be found on currently? Some of that should be included in the changelog, but I'm curious as well too. josh ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
USB on lite5200 does not work.
Hi folks I've got a little problem with USB using a board based on lite5200. Some infos: -uBoot 1.2.0 -Linux version 2.6.21.7-hrt1-WR2.0bl_standard -time_init: processor frequency = 396.00 MHz We are using a minimal rootfs in order to jump on the real rootfs. We reach the shell using the rootfs minimal but when we plug-in an USB (hosting the real rootfs) the system frozen until the USB is unplugged. From uBoot, USB works well. Here following snap of boot, cat of /proc/interrupts and some Trace messages. We appreciate any help. We have already take a look to posts like: http://www.mail-archive.com/linuxppc-dev@ozlabs.org/msg24295.html or http://www.nabble.com/USB-support-on-mpc5200-broken-td19658810.html Error: hub 1-0:1.0: port_wait_reset: err = -22 is due to a USB mouse plugged in at boot time. === [EMAIL PROTECTED]: /proc #cat /proc/interrupts CPU0 80: 0 MPC52xx Main Edge mpc52xx-hwtimer 134: 10 MPC52xx Peripherals Edge ohci_hcd:usb1 139: 45882 MPC52xx Peripherals Edge mpc52xx_psc_uart 143: 0 MPC52xx Peripherals Edge i2c-mpc 144: 0 MPC52xx Peripherals Edge i2c-mpc 145: 0 MPC52xx Peripherals Edge can-mpc52xx 146: 0 MPC52xx Peripherals Edge can-mpc52xx BAD: 0 === usb 1-2: new full speed USB device using ppc-of-ohci and addr2 BUG: soft lockup detected on CPU#0! Call Trace: [C7E07A50] [C0007F40] show_stack+0x3c/0x194 (unreliable) [C7E07A80] [C004A2E0] softlockup_tick+0xa4/0xd4 [C7E07AA0] [C002B8F8] run_local_timers+0x18/0x28 [C7E07AB0] [C002B938] update_process_times+0x30/0x7c [C7E07AC0] [C003FE9C] tick_sched_timer+0xb0/0x280 [C7E07B20] [C003C498] hrtimer_interrupt+0x214/0x26c [C7E07B80] [C000E6A4] timer_interrupt+0x88/0x354 [C7E07BF0] [C0011B64] ret_from_except+0x0/0x14 --- Exception: 901 at handle_IRQ_event+0x7c/0x1e8 LR = handle_level_irq+0x90/0x13c [C7E07CB0] [C7E21C00] 0xc7e21c00 (unreliable) [C7E07CD0] [C004C240] handle_level_irq+0x90/0x13c [C7E07CE0] [C000626C] do_IRQ+0x98/0xbc [C7E07CF0] [C0011B64] ret_from_except+0x0/0x14 --- Exception: 501 at schedule+0xac/0x64c LR = schedule+0x78/0x64c [C7E07E00] [C02A7C84] schedule_timeout+0x68/0xe4 [C7E07E40] [C02A7658] wait_for_completion_timeout+0x8c/0x138 [C7E07E80] [C019D954] usb_start_wait_urb+0x68/0xcc [C7E07EB0] [C019DBB4] usb_control_msg+0xc4/0xf0 [C7E07EF0] [C0198AB4] hub_port_init+0x3fc/0x5b0 [C7E07F40] [C019A6F4] hub_thread+0x344/0xbe4 [C7E07FC0] [C0037DC0] kthread+0xc0/0xfc [C7E07FF0] [C0012358] original_kernel_thread+0x44/0x60 ppc-of-ohci f0001000.usb: OHCI Unrecoverable Error, disabled ppc-of-ohci f0001000.usb: HC died; cleaning up irq 134: nobody cared (try booting with the irqpoll option) Call Trace: [C7E29DF0] [C0007F40] show_stack+0x3c/0x194 (unreliable) [C7E29E20] [C004B2B8] __report_bad_irq+0x34/0xac [C7E29E40] [C004B40C] note_interrupt+0xdc/0x288 [C7E29E70] [C004C2A4] handle_level_irq+0xf4/0x13c [C7E29E80] [C000626C] do_IRQ+0x98/0xbc [C7E29E90] [C0011B64] ret_from_except+0x0/0x14 --- Exception: 501 at schedule+0x304/0x64c LR = schedule+0x2d8/0x64c [C7E29FA0] [C004A214] watchdog+0x4c/0x74 [C7E29FC0] [C0037DC0] kthread+0xc0/0xfc [C7E29FF0] [C0012358] original_kernel_thread+0x44/0x60 handlers: [c019c078] (usb_hcd_irq+0x0/0x9c) Disabling IRQ #134 hub
Re :Re: 8360E MDS - linux 2.6.20
Hi Kim,I did the following steps, but Iam unable to generate the rootfs.ext2.gz.uboot - Executed the ./install command from the 8360CD. As a result of it generated the ltib directory- In the ltib directory ./ltib --configureIn the configure menu, I specified the following, before saving the configs- Tool chain as (gcc-3.4.3/glibc-2.3.3)- uboot 1.1.3- Kernel (local linux directory build) which refers to the local directory where linux-2.6.20.6 is placed- Kernel config filespecified as mpc8360emds_defconfig, which is the file copied from /home/nanda/linux2.6.20.6/arch/powerpc/configs/mpc8360emds_defconfig to the ltib/config/platform/mpc8360epb directory) - Linux Target Architecture as powerpcAfter the above process by saving the configuration (it started building kernel and generated uImage) and failed in the below place (Refer also the attached build.txt file)Processing: skell === Testing ppp_url connectivity: FAIL, disabli ng Testing gpp_url connectivity: FAIL, disabling No network download connection availableStarted: Thu Nov 20 14:44:45 2008 Ended: Thu Nov 20 14:57:32 2008 Elapsed: 767 seconds Build Failed=I have attached the below files for boot and build logs with this mail, 1) defconfig.dev - default config generated for ./ltib configurenbsp;from config/platform/mpc8360epbnbsp;2) build.txt - Error build during ./ltib configure output3) mpc8360emds_defconfig - Default config file from /home/nanda/linux2.6.20.6/arch/powerpc/configs/ The end result was I could only see the uImage generated without rootfs.ext2.gz.uboot. nbsp;Please clarify on the same Thanks in advance,Regards,NandaOn Wed, 19 Nov 2008 11:47:51 -0600 Kim Phillips wroteOn 19 Nov 2008 09:08:10 -nanda wrote:gt; I could successfully build the uImage for linux 2.6.20.6 on the mpc8360E MDS. But I also need the rootfs.ext2.gz.uboot(RAMDisk Image) required for bringing up the board. Ca n also get the steps for the building the rootfs?gt; gt; Since the reference board mpc8360E MDS which I got from freescale had default (uImage and rootfs.ext2.gz.uboot) only for linux 2.6.11. Iam finding difficulty in bringing for linux 2.6.20.6 kernel.What problems are you seeing running the 2.6.20 based kernel image andthe rootfs you built with ltib?Kim___Linuxppc-dev mailing [EMAIL PROTECTED]://ozlabs.org/mailman/listinfo/linuxppc-dev# # Automatically generated make config: don't edit # LTIB version: 6.2.1 # CONFIG_CONFIG_TITLE=LTIB: Freescale MPC8360E PB PowerPC board CONFIG_CPU=MPC8360EPB CONFIG_PLATFORM_COMMENT=Freescale MPC8360E PB PowerPC board CONFIG_VENDOR=Freescale CONFIG_PLATFORM=mpc8360epb CONFIG_GNUTARCH=powerpc CONFIG_CFGHOST=powerpc-linux # # Choose the platform revision # # CONFIG_PLATFORM_REV1 is not set CONFIG_PLATFORM_REV2=y CONFIG_ENDIAN=big # # Choose the target C library type # CONFIG_GLIBC=y # CONFIG_UCLIBC is not set # # Choose your toolchain # CONFIG_TOOLCHAIN1=y # CONFIG_TOOLCHAIN2 is not set # CONFIG_TOOLCHAIN3 is not set # CONFIG_TOOLCHAIN_CUSTOM is not set CONFIG_TOOLCHAIN=mtwk-lnx-powerpc-gcc-3.4.3-glibc-2.3.3-0.28-1.i686.rpm CONFIG_TOOLCHAIN_PATH=/opt/mtwk/usr/local/powerpc-linux/gcc-3.4.3-glibc-2.3.3 CONFIG_TOOLCHAIN_PREFIX=powerpc-linux- CONFIG_TOOLCHAIN_CFLAGS= # # Choose bootloader # CONFIG_BOOTLOADER1=y # CONFIG_BOOTLOADER2 is not set # CONFIG_BOOTLOADER_NONE is not set CONFIG_PKG_U_BOOT=u-boot-1.1.3-mpc8360epb-rev2 CONFIG_PKG_U_BOOT_GENERAL=y # CONFIG_PKG_U_BOOT_PCI33M is not set # CONFIG_PKG_U_BOOT_PCI66M is not set # CONFIG_PKG_U_BOOT_PCIAGENT is not set CONFIG_PKG_U_BOOT_CONFIG_TYPE=MPC8360EPB_config CONFIG_PKG_U_BOOT_BUILD_ARGS=OPTFLAGS=-Os # # Choose your Kernel # # CONFIG_KERNEL1 is not set # CONFIG_KERNEL2 is not set CONFIG_KERNEL_DIR_BUILD=y # CONFIG_KERNEL_NONE is not set CONFIG_PKG_KERNEL=kernel26-dir-build # # Choose the Linux Target Architecture # # CONFIG_LINTARCH_PPC is not set CONFIG_LINTARCH_POWERPC=y CONFIG_LINTARCH=powerpc CONFIG_PKG_KERNEL_PATH_PRECONFIG=/home/nanda/linux-2.6.20.6/ CONFIG_PKG_KERNEL_KBUILD_PRECONFIG=$PKG_KERNEL_PATH_PRECONFIG/../kbuild/$PLATFORM CONFIG_KERNEL_CONFIG1=y # CONFIG_KERNEL_CONFIG2 is not set # CONFIG_KERNEL_CONFIG3 is not set # CONFIG_KERNEL_CONFIG4 is not set # CONFIG_KERNEL_CONFIG5 is not set # CONFIG_KERNEL_CONFIG6 is not set # CONFIG_KERNEL_CONFIG7 is not set # CONFIG_KERNEL_CONFIG8 is not set # CONFIG_KERNEL_CONFIG9 is not set # CONFIG_KERNEL_CONFIG_CUSTOM is not set CONFIG_PKG_KERNEL_PRECONFIG=mpc8360emds_defconfig.config # CONFIG_PKG_KERNEL_WANT_HEADERS is not set # CONFIG_PKG_KERNEL_WANT_CF is not set # CONFIG_PKG_KERNEL_LEAVESRC is not set CONFIG_DISTRO=dist/lfs-5.1 # # Package selection # # # Package list # CONFIG_PKG_APPTRK_PPCBIN=y # CONFIG_PKG_AUTOCONF is not set # CONFIG_PKG_AUTOMAKE is not set CONFIG_LIBC_WANTED=y CONFIG_PKG_LIBC=base_libs # CONFIG_PKG_LIBC_WANT_LOCALES is not set #
Re: [PATCH 0/9] powerpc: port of dynamic ftrace
* Steven Rostedt [EMAIL PROTECTED] wrote: branch: ppc/ftrace-disable Matt Fleming (1): ftrace: align __mcount_loc sections Steven Rostedt (8): ftrace: disable dynamic ftrace from PowerPC powerpc: ftrace, do not latency trace idle powerpc: ftrace, convert to new dynamic ftrace arch API powerpc/ppc64: ftrace, mcount record powerpc port powerpc: ftrace, use probe_kernel API to modify code powerpc/ppc64: ftrace, handle module trampolines for dyn ftrace powerpc/ppc32: ftrace, enabled dynamic ftrace powerpc/ppc32: ftrace, dynamic ftrace to handle modules arch/powerpc/Kconfig |2 + arch/powerpc/include/asm/ftrace.h | 14 +- arch/powerpc/include/asm/module.h | 16 ++- arch/powerpc/kernel/ftrace.c | 473 +--- arch/powerpc/kernel/idle.c|5 + arch/powerpc/kernel/module_32.c | 10 + arch/powerpc/kernel/module_64.c | 13 + kernel/trace/Kconfig |1 + scripts/recordmcount.pl | 20 ++- 9 files changed, 511 insertions(+), 43 deletions(-) There is a dependency on Matt's commit for one of the PPC commits to apply. I could hack that commit to work without Matt's patch, but then that just postpones conflicts later on. Matt's change is this: scripts/recordmcount.pl | 20 ++- looks much better and the (minimal) generic impact is OK i think - as long as Paul Acks the powerpc changes we could freeze that branch (so that Paul can pull it in a few weeks) and base your ftrace-powerpc work on that. ( The branch should still be named something constructive like powerpc-ftrace-v29 or so - not ppc/ftrace-disable - but that's a detail. ) Ingo ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: USB on lite5200 does not work.
On Thu, Nov 20, 2008 at 7:09 AM, [EMAIL PROTECTED] wrote: Hi folks I've got a little problem with USB using a board based on lite5200. Some infos: -uBoot 1.2.0 -Linux version 2.6.21.7-hrt1-WR2.0bl_standard -time_init: processor frequency = 396.00 MHz There have been a lot of changes to MPC5200 support in the last 6 kernel releases. Can you try with a more recent kernel? Thanks, g. -- Grant Likely, B.Sc., P.Eng. Secret Lab Technologies Ltd. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Please pull 'merge' branch of powerpc-4xx git tree
On Thu, 13 Nov 2008 10:36:23 -0500 Josh Boyer [EMAIL PROTECTED] wrote: Hi Paul, Please pull the merge branch of the powerpc-4xx git tree. It contains two small fixes that should go into .28. Ping? josh The following changes since commit cb8fdc69a2a80e81e1280ec58afd2c3217ac8a7f: Paul Mackerras (1): powerpc: Update desktop/server defconfigs are available in the git repository at: ssh://master.kernel.org/pub/scm/linux/kernel/git/jwboyer/powerpc-4xx.git merge Benjamin Herrenschmidt (1): powerpc/44x: Fix 460EX/460GT machine check handling Grant Erickson (1): powerpc/40x: Limit allocable DRAM during early mapping arch/powerpc/kernel/cpu_setup_44x.S |7 ++- arch/powerpc/mm/40x_mmu.c | 16 ++-- 2 files changed, 20 insertions(+), 3 deletions(-) ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
times(2) sys call bug?
Why does the below program end up reporting -1
multiple seconds when times() wrap:
#include sys/times.h
#include stdio.h
main()
{
unsigned long t1;
clock_t t2;
while(1){
t1 = times(NULL);
t2 = times(NULL);
sleep(1);
printf(unsigned t1:%u, clock_t t2:%d\n, t1, t2);
if (t2 1000)
break;
}
}
and got:
unsigned t1:4294966339, clock_t t2:-957
unsigned t1:4294966439, clock_t t2:-857
unsigned t1:4294966539, clock_t t2:-757
unsigned t1:4294966639, clock_t t2:-657
unsigned t1:4294966739, clock_t t2:-557
unsigned t1:4294967295, clock_t t2:-1
unsigned t1:4294967295, clock_t t2:-1
unsigned t1:4294967295, clock_t t2:-1
unsigned t1:4294967295, clock_t t2:-1
unsigned t1:4294967295, clock_t t2:-1
unsigned t1:43, clock_t t2:43
unsigned t1:143, clock_t t2:143
unsigned t1:243, clock_t t2:243
unsigned t1:343, clock_t t2:343
unsigned t1:443, clock_t t2:443
unsigned t1:543, clock_t t2:543
unsigned t1:643, clock_t t2:643
unsigned t1:743, clock_t t2:743
unsigned t1:843, clock_t t2:843
unsigned t1:943, clock_t t2:943
unsigned t1:1043, clock_t t2:1043
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] powerpc: Add MSR[CE, DE] to the MSR bits we print on show_regs()
On Nov 19, 2008, at 10:46 PM, Benjamin Herrenschmidt wrote:
On Wed, 2008-11-19 at 08:39 -0600, Kumar Gala wrote:
Signed-off-by: Kumar Gala [EMAIL PROTECTED]
---
Shouldn't this be protected by some ifdef ?
Ben.
arch/powerpc/kernel/process.c |2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/arch/powerpc/kernel/process.c b/arch/powerpc/kernel/
process.c
index 957bded..b038323 100644
--- a/arch/powerpc/kernel/process.c
+++ b/arch/powerpc/kernel/process.c
@@ -467,6 +467,8 @@ static struct regbit {
{MSR_VEC, VEC},
{MSR_VSX, VSX},
{MSR_ME,ME},
+ {MSR_CE,CE},
+ {MSR_DE,DE},
{MSR_IR,IR},
{MSR_DR,DR},
{0, NULL}
Why? The bits are always defined and don't seem to be reused (and we
don't ifdef VEC, VSX, etc..) so why bother?
- k
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] cpm2: Round the baud-rate clock divider to the nearest integer.
On Nov 20, 2008, at 6:32 AM, Laurent Pinchart wrote: Instead of rounding the divider down, improve the baud-rate generators accuracy by rounding to the nearest integer. Signed-off-by: Laurent Pinchart [EMAIL PROTECTED] --- arch/powerpc/sysdev/cpm2.c |3 ++- 1 files changed, 2 insertions(+), 1 deletions(-) is this fixing a bug or just making things better? - k ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: times(2) sys call bug?
On Thu, 20 Nov 2008 16:09:16 +0100 Joakim Tjernlund [EMAIL PROTECTED] wrote: Why does the below program end up reporting -1 multiple seconds when times() wrap: http://sources.redhat.com/bugzilla/show_bug.cgi?id=5209 josh ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] Add support for the nwp serial device
On Thu, 20 Nov 2008 16:20:54 +0100 Benjamin Krill [EMAIL PROTECTED] wrote: Hi Josh, What does 'NWP' stand for, and how is it different from a regular serial port? Also, what platforms can this device be found on currently? Some of that should be included in the changelog, but I'm curious as well too. NWP stands for network processor and it is part of the QPACE - Quantum Chromodynamics Parallel Computing on the Cell Broadband Engine project [1]. The implementation is a lightweight uart implementation with the focus to consume as little resources as possible and it is connected to a DCR bus. Neat. Thanks. We should include that in the changelog. josh ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: R: USB on lite5200 does not work.
On Thu, Nov 20, 2008 at 8:33 AM, [EMAIL PROTECTED] wrote: I Grant I would but I cannot move up to an other kernel, project constraints. Complement of INFO: using a lite5200EVB USB works. using our board (kernel modified for our board), USB does not work. Have you got some ideas? I can send you what file have been modified (a couple). Check your settings in the port config register. Also, please remember to CC: the mailing list when replying to questions. g. -- Grant Likely, B.Sc., P.Eng. Secret Lab Technologies Ltd. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] cpm2: Round the baud-rate clock divider to the nearest integer.
On Nov 20, 2008, at 9:57 AM, Laurent Pinchart wrote: Hi Kumar, On Thursday 20 November 2008 16:32:21 Kumar Gala wrote: On Nov 20, 2008, at 6:32 AM, Laurent Pinchart wrote: Instead of rounding the divider down, improve the baud-rate generators accuracy by rounding to the nearest integer. Signed-off-by: Laurent Pinchart [EMAIL PROTECTED] --- arch/powerpc/sysdev/cpm2.c |3 ++- 1 files changed, 2 insertions(+), 1 deletions(-) is this fixing a bug or just making things better? I guess it depends on your definition of bug :-) The problem has always been present in the kernel sources, and people seem to have coped with it until today. It is still a bug in my opinion, but I suppose the patch can wait until 2.6.29 especially if we want to get it tested (it slightly changes baud rates after all). Ok. I'll put this in the .29 queue. Can you provide a bit more detail on the issue this is resolving. - k ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: times(2) sys call bug?
On Thu, 2008-11-20 at 10:37 -0500, Josh Boyer wrote: On Thu, 20 Nov 2008 16:09:16 +0100 Joakim Tjernlund [EMAIL PROTECTED] wrote: Why does the below program end up reporting -1 multiple seconds when times() wrap: http://sources.redhat.com/bugzilla/show_bug.cgi?id=5209 josh I see, but this is a new ppc kernel bug I think. This little hack changes the kernel sys call handling in an crude way and then it works. Apperently the kernel thinks is an error if the syscall returns a value between -_LAST_ERRNO and -1. Perhaps a known bug? diff --git a/arch/powerpc/kernel/entry_32.S b/arch/powerpc/kernel/entry_32.S index 1cbbf70..72effde 100644 --- a/arch/powerpc/kernel/entry_32.S +++ b/arch/powerpc/kernel/entry_32.S @@ -278,7 +278,8 @@ ret_from_syscall: SYNC MTMSRD(r10) lwz r9,TI_FLAGS(r12) - li r8,-_LAST_ERRNO + //lir8,-_LAST_ERRNO + li r8,-2 andi. r0,r9,(_TIF_SYSCALL_T_OR_A|_TIF_SINGLESTEP|_TIF_USER_WORK_MASK|_TIF_PERSYSCALL_MASK) bne-syscall_exit_work cmplw 0,r3,r8 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH V2] powerpc: Add sync_*_for_* to dma_ops
We need to swap these out once we start using swiotlb, so add
them to dma_ops. Create CONFIG_PPC_NEED_DMA_SYNC_OPS Kconfig
option; this is currently enabled automatically if we're
CONFIG_NOT_COHERENT_CACHE. In the future, this will also
be enabled for builds that need swiotlb. If PPC_NEED_DMA_SYNC_OPS
is not defined, the dma_sync_*_for_* ops compile to nothing.
Otherwise, they access the dma_ops pointers for the sync ops.
This patch also changes dma_sync_single_range_* to actually
sync the range - previously it was using a generous
dma_sync_single. dma_sync_single_* is now implemented
as a dma_sync_single_range with an offset of 0.
Signed-off-by: Becky Bruce [EMAIL PROTECTED]
---
arch/powerpc/Kconfig |4 ++
arch/powerpc/include/asm/dma-mapping.h | 93 +---
arch/powerpc/kernel/dma.c | 26 +
3 files changed, 92 insertions(+), 31 deletions(-)
diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
index 525c13a..be4f99b 100644
--- a/arch/powerpc/Kconfig
+++ b/arch/powerpc/Kconfig
@@ -285,6 +285,10 @@ config IOMMU_VMERGE
config IOMMU_HELPER
def_bool PPC64
+config PPC_NEED_DMA_SYNC_OPS
+ def_bool y
+ depends on NOT_COHERENT_CACHE
+
config HOTPLUG_CPU
bool Support for enabling/disabling CPUs
depends on SMP HOTPLUG EXPERIMENTAL (PPC_PSERIES || PPC_PMAC)
diff --git a/arch/powerpc/include/asm/dma-mapping.h
b/arch/powerpc/include/asm/dma-mapping.h
index 3c4a2c2..9063184 100644
--- a/arch/powerpc/include/asm/dma-mapping.h
+++ b/arch/powerpc/include/asm/dma-mapping.h
@@ -76,6 +76,22 @@ struct dma_mapping_ops {
dma_addr_t dma_address, size_t size,
enum dma_data_direction direction,
struct dma_attrs *attrs);
+#ifdef CONFIG_PPC_NEED_DMA_SYNC_OPS
+ void(*sync_single_range_for_cpu)(struct device *hwdev,
+ dma_addr_t dma_handle, unsigned long offset,
+ size_t size,
+ enum dma_data_direction direction);
+ void(*sync_single_range_for_device)(struct device *hwdev,
+ dma_addr_t dma_handle, unsigned long offset,
+ size_t size,
+ enum dma_data_direction direction);
+ void(*sync_sg_for_cpu)(struct device *hwdev,
+ struct scatterlist *sg, int nelems,
+ enum dma_data_direction direction);
+ void(*sync_sg_for_device)(struct device *hwdev,
+ struct scatterlist *sg, int nelems,
+ enum dma_data_direction direction);
+#endif
};
/*
@@ -282,47 +298,78 @@ static inline void dma_unmap_sg(struct device *dev,
struct scatterlist *sg,
dma_unmap_sg_attrs(dev, sg, nhwentries, direction, NULL);
}
+#ifdef CONFIG_PPC_NEED_DMA_SYNC_OPS
static inline void dma_sync_single_for_cpu(struct device *dev,
dma_addr_t dma_handle, size_t size,
enum dma_data_direction direction)
{
- BUG_ON(direction == DMA_NONE);
- __dma_sync(bus_to_virt(dma_handle), size, direction);
+ struct dma_mapping_ops *dma_ops = get_dma_ops(dev);
+
+ BUG_ON(!dma_ops);
+ dma_ops-sync_single_range_for_cpu(dev, dma_handle, 0,
+ size, direction);
}
static inline void dma_sync_single_for_device(struct device *dev,
dma_addr_t dma_handle, size_t size,
enum dma_data_direction direction)
{
- BUG_ON(direction == DMA_NONE);
- __dma_sync(bus_to_virt(dma_handle), size, direction);
+ struct dma_mapping_ops *dma_ops = get_dma_ops(dev);
+
+ BUG_ON(!dma_ops);
+ dma_ops-sync_single_range_for_device(dev, dma_handle,
+ 0, size, direction);
}
static inline void dma_sync_sg_for_cpu(struct device *dev,
struct scatterlist *sgl, int nents,
enum dma_data_direction direction)
{
- struct scatterlist *sg;
- int i;
-
- BUG_ON(direction == DMA_NONE);
+ struct dma_mapping_ops *dma_ops = get_dma_ops(dev);
- for_each_sg(sgl, sg, nents, i)
- __dma_sync_page(sg_page(sg), sg-offset, sg-length, direction);
+ BUG_ON(!dma_ops);
+ dma_ops-sync_sg_for_cpu(dev, sgl, nents, direction);
}
static inline void dma_sync_sg_for_device(struct device *dev,
struct scatterlist *sgl, int nents,
enum dma_data_direction direction)
{
- struct scatterlist *sg;
- int i;
+ struct dma_mapping_ops *dma_ops = get_dma_ops(dev);
- BUG_ON(direction == DMA_NONE);
+ BUG_ON(!dma_ops);
+ dma_ops-sync_sg_for_device(dev, sgl, nents, direction);
+}
+
+static inline void
Re: [PATCH v2] powerpc: allow configuring max stack dump depth
On Thu, 2008-11-20 at 09:10 +1100, Paul Mackerras wrote: Johannes Berg writes: On my screen, when something crashes, I only have space for maybe 16 functions of the stack trace before the information above it scrolls off the screen. It's easy to hack the kernel to print out only that much, but it's harder to remember to do it. This patch introduces a config option for it so that I can keep the setting in my config. Signed-off-by: Johannes Berg [EMAIL PROTECTED] --- Sure, here's an updated version. I used DEBUG_KERNEL since the ADVANCED_CONFIGURATION help text implies it's for MM and can cause the kernel to not boot, not something this config is related to. Um, with this I get a compile error when DEBUG_KERNEL=n: CC arch/powerpc/kernel/process.o /home/paulus/kernel/powerpc/arch/powerpc/kernel/process.c:1001: error: 'CONFIG_PRINT_STACK_DEPTH' undeclared here (not in a function) make[2]: *** [arch/powerpc/kernel/process.o] Error 1 Ouch, clearly I haven't been paying attention, my mistake. Sorry about that. I think it needs to look like this: +config PRINT_STACK_DEPTH + int Stack depth to print if DEBUG_KERNEL Yes, that's better, thanks. johannes signature.asc Description: This is a digitally signed message part ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH v3] powerpc: allow configuring max stack dump depth
On my screen, when something crashes, I only have space for maybe
16 functions of the stack trace before the information above it
scrolls off the screen. It's easy to hack the kernel to print out
only that much, but it's harder to remember to do it. This patch
introduces a config option for it so that I can keep the setting
in my config.
Signed-off-by: Johannes Berg [EMAIL PROTECTED]
---
v3 corrects the stupid Kconfig dependency mistake
arch/powerpc/Kconfig.debug|9 +
arch/powerpc/kernel/process.c |2 +-
2 files changed, 10 insertions(+), 1 deletion(-)
--- everything.orig/arch/powerpc/Kconfig.debug 2008-11-19 01:13:16.0
+0100
+++ everything/arch/powerpc/Kconfig.debug 2008-11-20 14:21:46.0
+0100
@@ -2,6 +2,15 @@ menu Kernel hacking
source lib/Kconfig.debug
+config PRINT_STACK_DEPTH
+ int Stack depth to print if DEBUG_KERNEL
+ default 64
+ help
+ This option allows you to set the stack depth that the kernel
+ prints in stack traces. This can be useful if your display is
+ too small and stack traces cause important information to
+ scroll off the screen.
+
config DEBUG_STACKOVERFLOW
bool Check for stack overflows
depends on DEBUG_KERNEL
--- everything.orig/arch/powerpc/kernel/process.c 2008-11-19
01:13:16.0 +0100
+++ everything/arch/powerpc/kernel/process.c2008-11-19 12:45:28.0
+0100
@@ -998,7 +998,7 @@ unsigned long get_wchan(struct task_stru
return 0;
}
-static int kstack_depth_to_print = 64;
+static int kstack_depth_to_print = CONFIG_PRINT_STACK_DEPTH;
void show_stack(struct task_struct *tsk, unsigned long *stack)
{
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
ltib error -linux2.6.20.6 with MPC8360E MDS
Hi All,nbsp;nbsp; Iam forwarding the mail which I have posted to powerpc
linux listnbsp;[EMAIL PROTECTED]nbsp; Iam getting the below error during the
generation of rootfs.ext2.gz.uboot (Power PC Linux RAM Disk Image) and uImage
(Power PC Linux Kernel Image) for linux-2.6.20.6 kernel on the power PC MPC
8360E MDS using ltib tool.Testing ppp_url connectivity: FAIL, disabling
Testing gpp_url connectivity: FAIL, disabling No network download connection
availableI did the following steps, but Iam unable to generate the
rootfs.ext2.gz.uboot - In the ltib directory ./ltib --configureIn the configure
menu, I specified the following, before saving the configs- Tool chain as
(gcc-3.4.3/glibc-2.3.3)- uboot 1.1.3- Kernel (local linux directory build)
which refers to the local directory where linux-2.6.20.6 is placed- Kernel
config filespecified as mpc8360emds_defconfig, which is the file copied from
/home/nanda/linux2.6.2
0.6/arch/powerpc/configs/mpc8360emds_defconfig to the
ltib/config/platform/mpc8360epb directory) - Linux Target Architecture as
powerpcAfter the above process by saving the configuration (it started
building kernel and generated uImage) and failed in the below place (Refer also
the attached build.txt file)Processing: skell
=== Testing ppp_url connectivity: FAIL, disabling Testing
gpp_url connectivity: FAIL, disabling No network download connection
availableStarted: Thu Nov 20 14:44:45 2008 Ended: Thu Nov 20 14:57:32 2008
Elapsed: 767 seconds Build Failed=I have
attached the below files for boot and build logs with this mail, 1)
defconfig.dev - default config generated for ./ltib configure from
config/platform/mpc8360epb 2) build.txt - Error build during ./ltib configure
output3) mpc8360emds_defconfig - Default config file from
/home/nanda/linux2.6.20.6/arch/powerpc/configs/ The end resu
lt was I could only see the uImage generated without rootfs.ext2.gz.uboot.
Please clarify on the same Thanks in advance,Regards,Nanda LD init/built-in.o
LD vmlinux
SYSMAP System.map
MODPOST vmlinux
WRAParch/powerpc/boot/uImage
Image Name: Linux-2.6.20.6
Created: Thu Nov 20 14:54:04 2008
Image Type: PowerPC Linux Kernel Image (gzip compressed)
Data Size:1205859 Bytes = 1177.60 kB = 1.15 MB
Load Address: 0x
Entry Point: 0x
+ grep -q '^CONFIG_MODULES='
/home/nanda/linux-2.6.20.6//../kbuild/mpc8360epb/.config
+ make ARCH=powerpc CROSS_COMPILE= 'HOSTCC=/usr/bin/gcc -B/usr/bin//' modules
Using /home/nanda/linux-2.6.20.6 as source for kernel
GEN /home/nanda/kbuild/mpc8360epb/Makefile
CHK include/linux/version.h
CHK include/linux/utsrelease.h
CC [M] crypto/ecb.o
Building modules, stage 2.
MODPOST 1 modules
CC crypto/ecb.mod.o
LD [M] crypto/ecb.ko
+ '[' powerpc = powerpc -a -d '/home/nanda/linux-2.6.20.6//%{dtc_path}' ']'
+ exit 0
Executing(%install): /bin/sh -e
/home/nanda/BoardBringUp/ltib-mpc8360epb-20061208/tmp/rpm-tmp.94803
+ umask 022
+ cd /home/nanda/BoardBringUp/ltib-mpc8360epb-20061208/rpm/BUILD
+ KSRC_DIR=/home/nanda/linux-2.6.20.6/
+ cd /home/nanda/linux-2.6.20.6/
++ pwd
+ KSRC_DIR=/home/nanda/linux-2.6.20.6
++ eval echo '$PKG_KERNEL_PATH_PRECONFIG/../kbuild/$PLATFORM'
+++ echo /home/nanda/linux-2.6.20.6//../kbuild/mpc8360epb
+ KBOUT=/home/nanda/linux-2.6.20.6//../kbuild/mpc8360epb
+ KBOUT=/home/nanda/linux-2.6.20.6//../kbuild/mpc8360epb
+ '[' /home/nanda/linux-2.6.20.6//../kbuild/mpc8360epb '!=' . ']'
+ export KBUILD_OUTPUT=/home/nanda/linux-2.6.20.6//../kbuild/mpc8360epb
+ KBUILD_OUTPUT=/home/nanda/linux-2.6.20.6//../kbuild/mpc8360epb
+ grep -q CONFIG_PPC_MERGE=y
/home/nanda/linux-2.6.20.6//../kbuild/mpc8360epb/.config
+ LINTARCH=powerpc
+ case $LINTARCH in
+ BOOT_KERNEL=arch/powerpc/boot/uImage
+ grep -q CONFIG_PPCMERGE=y
/home/nanda/linux-2.6.20.6//../kbuild/mpc8360epb/.config
+ rm -rf /home/nanda/BoardBringUp/ltib-mpc8360epb-20061208/tmp/kernel
+ mkdir -p
/home/nanda/BoardBringUp/ltib-mpc8360epb-20061208/tmp/kernel//opt/freescale/rootfs/powerpc/boot
+ cd /home/nanda/linux-2.6.20.6//../kbuild/mpc8360epb
+ SYSCFG_BOOT_KERNEL=arch/powerpc/boot/uImage
+ '[' -n '' ']'
+ for i in vmlinux System.map '$SYSCFG_BOOT_KERNEL'
+ cp vmlinux
/home/nanda/BoardBringUp/ltib-mpc8360epb-20061208/tmp/kernel//opt/freescale/rootfs/powerpc/boot/
+ for i in vmlinux System.map '$SYSCFG_BOOT_KERNEL'
+ cp System.map
/home/nanda/BoardBringUp/ltib-mpc8360epb-20061208/tmp/kernel//opt/freescale/rootfs/powerpc/boot/
+ for i in vmlinux System.map '$SYSCFG_BOOT_KERNEL'
+ cp arch/powerpc/boot/uImage
/home/nanda/BoardBringUp/ltib-mpc8360epb-20061208/tmp/kernel//opt/freescale/rootfs/powerpc/boot/
++ basename arch/powerpc/boot/uImage
+ ln -s uImage
/home/nanda/BoardBringUp/ltib-mpc8360epb-20061208/tmp/kernel//opt/freescale/rootfs/powerpc/boot/bootable_kernel
+ cp .config
Re: USB on lite5200 does not work.
Dear [EMAIL PROTECTED], In message [EMAIL PROTECTED] you wrote: I've got a little problem with USB using a board based on lite5200. Some infos: -uBoot 1.2.0 -Linux version 2.6.21.7-hrt1-WR2.0bl_standard 2.6.21 is a pretty old kernel. In mainline, it didn't include real stable support for the MPC5200 yet, and I have no idea what WRS did in this area (but I doubt they did much fixing there). Please be aware that you are using a highly proprietary, heavily modified kernel. You either want to ask Wind River support for help, or try a recent mainline kernel. 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: [EMAIL PROTECTED] The software required `Windows 95 or better', so I installed Linux. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: powerpc: udbg based backend for hvc_console
[I'm going to reply to several points in this thread in one reply. I have restored context that was trimmed in later replys when I wanted to speak to.] David Gibson wrote at 2008-11-18 00:28:28: On Mon, Nov 17, 2008 at 01:41:24PM -0600, Timur Tabi wrote: On Thu, Oct 23, 2008 at 9:54 PM, David Gibson [EMAIL PROTECTED] wrote: This patch adds a new backend for the hvc console based on the low-level udbg callbacks. This effectively implements a working runtime console in terms of the simple udbg primitives. This is kind of a hack - since udbg isn't something you really want to be using routinely - but it's really useful during bringup. Why is udbg hvc something you want to not use routinely? Stated differently, if your routine (1) fundamently works one character at a time and (2) is not interrupt driven, and (3) only supports one channel, what avantage is there to an explicit hvc driver? This can be used to quickly implement a userspace usable console while you're working on a proper driver for whatever console I/O device the hardware has. Or, it can be used to avoid writing a full blown tty/console driver entirely for quick-and-dirty I/O hardware that will later be replaced by something else. Actually it looks remarkably similar to a cleaned up version of a patch i've been using since hvc_console was split to be a hookable shell. Or was it the motivation for adding the hooks? The code is different in how it structures the error checks and that it is implemented in drivers/char where it belongs (hence the cleaned up comment) but the fact that David recreated what I did does speak to its general utility. David, I have a stupid question. I already have an HVC console driver that works. Do I need to do anything, other than enable HVC_UDBG, to get my hvc console drive to use udbg? As was pointed out elsewhere, this is hvc calling udbg not udbg hooks calling hvc_cosole methods, which might need a different context. But I wanted to comment on David's reply: Um.. well.. if you have both activated, I think you can select which HVC console backend will be used by using console=/dev/hvcNN on the commandline, where values of NN correspond to different backends, in order depending on link order in some complex fashion. It doesn't just work that way because of the way the hvc_console shell implements the console hooks. If the drivers request different hvc channel numbers, then yes, you can select which hvc backend is used by choosing console=hvcNN. If all request 0, then which ever one registers with hvc_console first wins the slot, and the others get a busy error return. They can still register their tty later, at which point they get a dynamically determined /dev/hvcN slot, above all registered console slots. There are multiple reasons for this design. The original user, pseries vterm, wants to assign the channel number based on what the hypervisor tells it the channel should be. There are two loops though the device tree, searching for different protocols (and consequently different backends), so they need to be able to specify the number and not just use the order they are found. The platform describes not only the protocol, but which instance that is, and the backend currently registers with that number. Another reason is its a bad idea to have console=/dev/hvc0 depend on link order instead of knowing which driver is selected. If a user is specifing what the console is, it should not depend on other linked drivers. Until this point, all mainline drivers have been exclusive in that only one will actually register with hvc_console midlayer on any given platform. This is the first backend that is not exclusive, and therefore its coexistence needs special attention. In my internal tree, I register (my version of) this not as hvc0 but as hvc4. hvc0 is rtas, hvc1-3 are an internal backend, and this one is hvc4. The order I chose is arbitrary, but the main point is it does't compete with hvc_rtas for slot 0. (All of these drivers coexist, and I can choose which one I want to use based on my needs for that boot.) We could make it configurable via Kconfig, or just choose a slot. (I think vterm can have 2 channels on some boxes where they drive real serial ports on the box.) But if you already have a working HVC console driver, I don't see why you'd want to use HVC_UDBG - it's essentially a bringup hack. As I said, why should we need a fancier hvc_console backend if you are polling and gain no efficency processing multiple characters at once. The udbg drivers know if they are sharing the interface with a hvc_console some other driver. If we trigger the registration of this backend on the udbg hook saying its useful (eg by setting a flag word in the function where we assign the udbg putc and getc pointers) then this driver will not need to be compiled out for production
[PATCH 3/5] powerpc: ftrace, use probe_kernel API to modify code
From: Steven Rostedt [EMAIL PROTECTED]
Impact: use cleaner probe_kernel API over assembly
Using probe_kernel_read/write interface is a much cleaner approach
than the current assembly version.
Signed-off-by: Steven Rostedt [EMAIL PROTECTED]
---
arch/powerpc/kernel/ftrace.c | 53 -
1 files changed, 21 insertions(+), 32 deletions(-)
diff --git a/arch/powerpc/kernel/ftrace.c b/arch/powerpc/kernel/ftrace.c
index 24c023a..1adfbb2 100644
--- a/arch/powerpc/kernel/ftrace.c
+++ b/arch/powerpc/kernel/ftrace.c
@@ -9,6 +9,7 @@
#include linux/spinlock.h
#include linux/hardirq.h
+#include linux/uaccess.h
#include linux/ftrace.h
#include linux/percpu.h
#include linux/init.h
@@ -72,45 +73,33 @@ static int
ftrace_modify_code(unsigned long ip, unsigned char *old_code,
unsigned char *new_code)
{
- unsigned replaced;
- unsigned old = *(unsigned *)old_code;
- unsigned new = *(unsigned *)new_code;
- int faulted = 0;
+ unsigned char replaced[MCOUNT_INSN_SIZE];
/*
* Note: Due to modules and __init, code can
* disappear and change, we need to protect against faulting
-* as well as code changing.
+* as well as code changing. We do this by using the
+* probe_kernel_* functions.
*
* No real locking needed, this code is run through
-* kstop_machine.
+* kstop_machine, or before SMP starts.
*/
- asm volatile (
- 1: lwz %1, 0(%2)\n
- cmpw%1, %5\n
- bne 2f\n
- stwu%3, 0(%2)\n
- 2:\n
- .section .fixup, \ax\\n
- 3: li %0, 1\n
- b 2b\n
- .previous\n
- .section __ex_table,\a\\n
- _ASM_ALIGN \n
- _ASM_PTR 1b, 3b\n
- .previous
- : =r(faulted), =r(replaced)
- : r(ip), r(new),
- 0(faulted), r(old)
- : memory);
-
- if (replaced != old replaced != new)
- faulted = 2;
-
- if (!faulted)
- flush_icache_range(ip, ip + 8);
-
- return faulted;
+
+ /* read the text we want to modify */
+ if (probe_kernel_read(replaced, (void *)ip, MCOUNT_INSN_SIZE))
+ return -EFAULT;
+
+ /* Make sure it is what we expect it to be */
+ if (memcmp(replaced, old_code, MCOUNT_INSN_SIZE) != 0)
+ return -EINVAL;
+
+ /* replace the text with the new text */
+ if (probe_kernel_write((void *)ip, new_code, MCOUNT_INSN_SIZE))
+ return -EPERM;
+
+ flush_icache_range(ip, ip + 8);
+
+ return 0;
}
static int test_24bit_addr(unsigned long ip, unsigned long addr)
--
1.5.6.5
--
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH 5/5] powerpc/ppc32: ftrace, dynamic ftrace to handle modules
From: Steven Rostedt [EMAIL PROTECTED]
Impact: add ability to trace modules on 32 bit PowerPC
This patch performs the necessary trampoline calls to handle
modules with dynamic ftrace on 32 bit PowerPC.
Signed-off-by: Steven Rostedt [EMAIL PROTECTED]
---
arch/powerpc/include/asm/module.h |5 ++-
arch/powerpc/kernel/ftrace.c | 101 ++--
arch/powerpc/kernel/module_32.c | 10
3 files changed, 109 insertions(+), 7 deletions(-)
diff --git a/arch/powerpc/include/asm/module.h
b/arch/powerpc/include/asm/module.h
index 340bc69..0845488 100644
--- a/arch/powerpc/include/asm/module.h
+++ b/arch/powerpc/include/asm/module.h
@@ -39,11 +39,14 @@ struct mod_arch_specific {
unsigned long tramp;
#endif
-#else
+#else /* powerpc64 */
/* Indices of PLT sections within module. */
unsigned int core_plt_section;
unsigned int init_plt_section;
+#ifdef CONFIG_DYNAMIC_FTRACE
+ unsigned long tramp;
#endif
+#endif /* powerpc64 */
/* List of BUG addresses, source line numbers and filenames */
struct list_head bug_list;
diff --git a/arch/powerpc/kernel/ftrace.c b/arch/powerpc/kernel/ftrace.c
index 1aec559..3271cd6 100644
--- a/arch/powerpc/kernel/ftrace.c
+++ b/arch/powerpc/kernel/ftrace.c
@@ -274,7 +274,63 @@ static int
__ftrace_make_nop(struct module *mod,
struct dyn_ftrace *rec, unsigned long addr)
{
- /* Ignore modules for PPC32 (for now) */
+ unsigned char replaced[MCOUNT_INSN_SIZE];
+ unsigned int *op = (unsigned *)replaced;
+ unsigned char jmp[8];
+ unsigned int *ptr = (unsigned int *)jmp;
+ unsigned long ip = rec-ip;
+ unsigned long tramp;
+ int offset;
+
+ if (probe_kernel_read(replaced, (void *)ip, MCOUNT_INSN_SIZE))
+ return -EFAULT;
+
+ /* Make sure that that this is still a 24bit jump */
+ if (!is_bl_op(*op)) {
+ printk(KERN_ERR Not expected bl: opcode is %x\n, *op);
+ return -EINVAL;
+ }
+
+ /* lets find where the pointer goes */
+ tramp = find_bl_target(ip, *op);
+
+ /*
+* On PPC32 the trampoline looks like:
+* lis r11,[EMAIL PROTECTED]
+* addi r11,r11,[EMAIL PROTECTED]
+* mtctr r11
+* bctr
+*/
+
+ DEBUGP(ip:%lx jumps to %lx, ip, tramp);
+
+ /* Find where the trampoline jumps to */
+ if (probe_kernel_read(jmp, (void *)tramp, 8)) {
+ printk(KERN_ERR Failed to read %lx\n, tramp);
+ return -EFAULT;
+ }
+
+ DEBUGP( %08x %08x , ptr[0], ptr[1]);
+
+ tramp = (ptr[1] 0x) |
+ ((ptr[0] 0x) 16);
+ if (tramp 0x8000)
+ tramp -= 0x1;
+
+ DEBUGP( %x , tramp);
+
+ if (tramp != addr) {
+ printk(KERN_ERR
+ Trampoline location %08lx does not match addr\n,
+ tramp);
+ return -EINVAL;
+ }
+
+ op[0] = PPC_NOP_INSTR;
+
+ if (probe_kernel_write((void *)ip, replaced, MCOUNT_INSN_SIZE))
+ return -EPERM;
+
return 0;
}
#endif /* PPC64 */
@@ -297,7 +353,6 @@ int ftrace_make_nop(struct module *mod,
return ftrace_modify_code(ip, old, new);
}
-#ifdef CONFIG_PPC64
/*
* Out of range jumps are called from modules.
* We should either already have a pointer to the module
@@ -320,7 +375,6 @@ int ftrace_make_nop(struct module *mod,
/* nothing to do if mod == rec-arch.mod */
} else
mod = rec-arch.mod;
-#endif /* CONFIG_PPC64 */
return __ftrace_make_nop(mod, rec, addr);
@@ -380,7 +434,44 @@ __ftrace_make_call(struct dyn_ftrace *rec, unsigned long
addr)
static int
__ftrace_make_call(struct dyn_ftrace *rec, unsigned long addr)
{
- /* PPC32 ignores modules for now */
+ unsigned char replaced[MCOUNT_INSN_SIZE];
+ unsigned int *op = (unsigned *)replaced;
+ unsigned long ip = rec-ip;
+ unsigned long offset;
+
+ /* read where this goes */
+ if (probe_kernel_read(replaced, (void *)ip, MCOUNT_INSN_SIZE))
+ return -EFAULT;
+
+ /* It should be pointing to a nop */
+ if (op[0] != PPC_NOP_INSTR) {
+ printk(KERN_ERR Expected NOP but have %x\n, op[0]);
+ return -EINVAL;
+ }
+
+ /* If we never set up a trampoline to ftrace_caller, then bail */
+ if (!rec-arch.mod-arch.tramp) {
+ printk(KERN_ERR No ftrace trampoline\n);
+ return -EINVAL;
+ }
+
+ /* now calculate a jump to the ftrace caller trampoline */
+ offset = rec-arch.mod-arch.tramp - ip;
+
+ if (test_offset(offset)) {
+ printk(KERN_ERR REL24 %li out of range!\n,
+ (long int)offset);
+ return -EINVAL;
+ }
+
+ /* Set to bl addr */
+ op[0] =
Re: [PATCH 0/5] powerpc: dynamic ftrace port
* Steven Rostedt [EMAIL PROTECTED] wrote: Paul and Ingo, The following are the changes to get dynamic ftrace working on PowerPC. I modified these a little from the last postings. 1) I removed the changes to recordmcount.pl. This is not a PowerPC change, although PowerPC needs it for dynamic ftrace. But the changes here can go via linux-tip. 2) I removed the adding of HAVE_DYNAMIC_FTRACE and HAVE_FTRACE_MCOUNT_RECORD. Without these config options, this code will not be compiled. I have a separate patch that adds them in when the time is right. Paul, these patches should not harm anything if you decide to pull them in. As I stated above, without the above config options, they are not enabled. There is one exception and that is for the first patch. The first patch is actually a fix for the irqsoff latency tracer which is already in mainline for PowerPC. These patches only touch PowerPC code. The following patches are in: git://git.kernel.org/pub/scm/linux/kernel/git/rostedt/linux-2.6-trace.git branch: ppc/ftrace Steven Rostedt (5): powerpc: ftrace, do not latency trace idle powerpc: ftrace, convert to new dynamic ftrace arch API powerpc: ftrace, use probe_kernel API to modify code powerpc/ppc64: ftrace, handle module trampolines for dyn ftrace powerpc/ppc32: ftrace, dynamic ftrace to handle modules arch/powerpc/include/asm/ftrace.h | 14 +- arch/powerpc/include/asm/module.h | 16 ++- arch/powerpc/kernel/ftrace.c | 473 +--- arch/powerpc/kernel/idle.c|5 + arch/powerpc/kernel/module_32.c | 10 + arch/powerpc/kernel/module_64.c | 13 + 6 files changed, 489 insertions(+), 42 deletions(-) looks perfect to me! Thanks Steve for going through this - this was really a logistical worst-case-scenario. Now lets hope it looks good to Paul too and we can get his Acked-by :-) Ingo ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] Fix BSR to allow mmap of small BSR on 64k kernel
On Thu, Nov 20, 2008 at 09:54:21AM +1100, Paul Mackerras wrote: Sonny Rao writes: On Wed, Nov 19, 2008 at 03:07:04PM +1100, Paul Mackerras wrote: I think we should be checking that dev-bsr_len == 4096 here. Paul. Well, dev-bsr_len could be 4096 or 8192 Isn't the dev-bsr_len == 8192 case the one where we'll only map 4096 bytes and therefore not do what the user expected? Sounds to me like we want to return an error for that case. Well, the problem is that we can't tell if the user asked for 4k or 8k (since we only know the size of the VMA). If we fail whenever dev-bsr_len is 8k then the user could never map that device on a 64k page kernel. Is that what we want? -- Sonny Rao, LTC OzLabs, BML team ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH 3/3] ftrace: create default variables for archs in recordmcount.pl
From: Steven Rostedt [EMAIL PROTECTED]
Impact: cleanup of recordmcount.pl
Now that more architectures are being ported to the MCOUNT_RECORD
method, there is no reason to have each declare their own arch
specific variable if most of them share the same value. This patch
creates a set of default values for the arch specific variables
based off of i386.
Signed-off-by: Steven Rostedt [EMAIL PROTECTED]
---
scripts/recordmcount.pl | 27 +++
1 files changed, 11 insertions(+), 16 deletions(-)
diff --git a/scripts/recordmcount.pl b/scripts/recordmcount.pl
index 7ec032e..c5c58ac 100755
--- a/scripts/recordmcount.pl
+++ b/scripts/recordmcount.pl
@@ -145,10 +145,17 @@ if ($arch eq x86) {
}
}
+#
+# We base the defaults off of i386, the other archs may
+# feel free to change them in the below if statements.
+#
+$nm_regex = ^[0-9a-fA-F]+\\s+t\\s+(\\S+);
+$section_regex = Disassembly of section\\s+(\\S+):;
+$function_regex = ^([0-9a-fA-F]+)\\s+(.*?):;
+$mcount_regex = ^\\s*([0-9a-fA-F]+):.*\\smcount\$;
+$type = .long;
+
if ($arch eq x86_64) {
-$nm_regex = ^[0-9a-fA-F]+\\s+t\\s+(\\S+);
-$section_regex = Disassembly of section\\s+(\\S+):;
-$function_regex = ^([0-9a-fA-F]+)\\s+(.*?):;
$mcount_regex = ^\\s*([0-9a-fA-F]+):.*\\smcount([+-]0x[0-9a-zA-Z]+)?\$;
$type = .quad;
$alignment = 8;
@@ -160,11 +167,6 @@ if ($arch eq x86_64) {
$cc .= -m64;
} elsif ($arch eq i386) {
-$nm_regex = ^[0-9a-fA-F]+\\s+t\\s+(\\S+);
-$section_regex = Disassembly of section\\s+(\\S+):;
-$function_regex = ^([0-9a-fA-F]+)\\s+(.*?):;
-$mcount_regex = ^\\s*([0-9a-fA-F]+):.*\\smcount\$;
-$type = .long;
$alignment = 4;
# force flags for this arch
@@ -174,11 +176,6 @@ if ($arch eq x86_64) {
$cc .= -m32;
} elsif ($arch eq sh) {
-$nm_regex = ^[0-9a-fA-F]+\\s+t\\s+(\\S+);
-$section_regex = Disassembly of section\\s+(\\S+):;
-$function_regex = ^([0-9a-fA-F]+)\\s+(.*?):;
-$mcount_regex = ^\\s*([0-9a-fA-F]+):.*\\smcount\$;
-$type = .long;
# force flags for this arch
$ld .= -m shlelf_linux;
@@ -187,13 +184,11 @@ if ($arch eq x86_64) {
} elsif ($arch eq powerpc) {
$nm_regex = ^[0-9a-fA-F]+\\s+t\\s+(\\.?\\S+);
-$section_regex = Disassembly of section\\s+(\\S+):;
$function_regex = ^([0-9a-fA-F]+)\\s+(\\.?.*?):;
$mcount_regex = ^\\s*([0-9a-fA-F]+):.*\\s\\.?_mcount\$;
+
if ($bits == 64) {
$type = .quad;
-} else {
- $type = .long;
}
} else {
--
1.5.6.5
--
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH 0/1] powerpc: make mcount a stub for dynamic ftrace
Paul, I have one more patch. I added it to the end of the ppc/ftrace branch. The new way of handling the finding of mcounts means we do not need to do anything in the mcount call itself. It should just be a stub and when ftrace is enabled, it will change the caller sites to call something other than mcount. The following patches are in: git://git.kernel.org/pub/scm/linux/kernel/git/rostedt/linux-2.6-trace.git branch: ppc/ftrace Steven Rostedt (1): powerpc: ftrace, do nothing in mcount call for dyn ftrace arch/powerpc/kernel/entry_32.S | 35 +-- arch/powerpc/kernel/entry_64.S | 12 2 files changed, 1 insertions(+), 46 deletions(-) ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH 1/1] powerpc: ftrace, do nothing in mcount call for dyn ftrace
From: Steven Rostedt [EMAIL PROTECTED] Impact: quicken mcount calls that are not replaced by dyn ftrace Dynamic ftrace no longer does on the fly recording of mcount locations. The mcount locations are now found at compile time. The mcount function no longer needs to store registers and call a stub function. It can now just simply return. Since there are some functions that do not get converted to a nop (.init sections and other code that may disappear), this patch should help speed up that code. Signed-off-by: Steven Rostedt [EMAIL PROTECTED] --- arch/powerpc/kernel/entry_32.S | 35 +-- arch/powerpc/kernel/entry_64.S | 12 2 files changed, 1 insertions(+), 46 deletions(-) diff --git a/arch/powerpc/kernel/entry_32.S b/arch/powerpc/kernel/entry_32.S index 7ecc0d1..d2c4035 100644 --- a/arch/powerpc/kernel/entry_32.S +++ b/arch/powerpc/kernel/entry_32.S @@ -1162,40 +1162,7 @@ machine_check_in_rtas: #ifdef CONFIG_DYNAMIC_FTRACE _GLOBAL(mcount) _GLOBAL(_mcount) - stwur1,-48(r1) - stw r3, 12(r1) - stw r4, 16(r1) - stw r5, 20(r1) - stw r6, 24(r1) - mflrr3 - stw r7, 28(r1) - mfcrr5 - stw r8, 32(r1) - stw r9, 36(r1) - stw r10,40(r1) - stw r3, 44(r1) - stw r5, 8(r1) - subir3, r3, MCOUNT_INSN_SIZE - .globl mcount_call -mcount_call: - bl ftrace_stub - nop - lwz r6, 8(r1) - lwz r0, 44(r1) - lwz r3, 12(r1) - mtctr r0 - lwz r4, 16(r1) - mtcrr6 - lwz r5, 20(r1) - lwz r6, 24(r1) - lwz r0, 52(r1) - lwz r7, 28(r1) - lwz r8, 32(r1) - mtlrr0 - lwz r9, 36(r1) - lwz r10,40(r1) - addir1, r1, 48 - bctr + blr _GLOBAL(ftrace_caller) /* Based off of objdump optput from glibc */ diff --git a/arch/powerpc/kernel/entry_64.S b/arch/powerpc/kernel/entry_64.S index e6d5284..b00982e 100644 --- a/arch/powerpc/kernel/entry_64.S +++ b/arch/powerpc/kernel/entry_64.S @@ -888,18 +888,6 @@ _GLOBAL(enter_prom) #ifdef CONFIG_DYNAMIC_FTRACE _GLOBAL(mcount) _GLOBAL(_mcount) - /* Taken from output of objdump from lib64/glibc */ - mflrr3 - stdur1, -112(r1) - std r3, 128(r1) - subir3, r3, MCOUNT_INSN_SIZE - .globl mcount_call -mcount_call: - bl ftrace_stub - nop - ld r0, 128(r1) - mtlrr0 - addir1, r1, 112 blr _GLOBAL(ftrace_caller) -- 1.5.6.5 -- ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[GIT PULL] Please pull spufs.git merge branch
Hi Paul, Please do a: git pull \ git://git.kernel.org/pub/scm/linux/kernel/git/jk/spufs.git merge For a spufs bugfix Cheers, Jeremy --- diffstat: arch/powerpc/platforms/cell/spufs/file.c |3 +++ 1 file changed, 3 insertions(+) 1 commits: powerpc/spufs: Fix spinning in spufs_ps_fault on signal Jeremy Kerr [EMAIL PROTECTED] ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [Ltib] ltib error -linux2.6.20.6 with MPC8360E MDS
Hi Nanda, This is happening because you don't have access to http://www.bitshrine.org/gpp for some reason. If LTIB needs to download sources to build a package, it will get them from bitshrine.org. Can you check that you are able to access this URL from the command line with wget. Regards, Stuart On Thu, 2008-11-20 at 18:30 +, nanda wrote: Hi All, Iam forwarding the mail which I have posted to powerpc linux list Linuxppc-dev@ozlabs.org === Iam getting the below error during the generation of rootfs.ext2.gz.uboot (Power PC Linux RAM Disk Image) and uImage (Power PC Linux Kernel Image) for linux-2.6.20.6 kernel on the power PC MPC 8360E MDS using ltib tool. Testing ppp_url connectivity: FAIL, disabling Testing gpp_url connectivity: FAIL, disabling No network download connection available I did the following steps, but Iam unable to generate the rootfs.ext2.gz.uboot - In the ltib directory ./ltib --configure In the configure menu, I specified the following, before saving the configs - Tool chain as (gcc-3.4.3/glibc-2.3.3) - uboot 1.1.3 - Kernel (local linux directory build) which refers to the local directory where linux-2.6.20.6 is placed - Kernel config filespecified as mpc8360emds_defconfig, which is the file copied from /home/nanda/linux2.6.20.6/arch/powerpc/configs/mpc8360emds_defconfig to the ltib/config/platform/mpc8360epb directory) - Linux Target Architecture as powerpc After the above process by saving the configuration (it started building kernel and generated uImage) and failed in the below place (Refer also the attached build.txt file) Processing: skell === Testing ppp_url connectivity: FAIL, disabling Testing gpp_url connectivity: FAIL, disabling No network download connection available Started: Thu Nov 20 14:44:45 2008 Ended: Thu Nov 20 14:57:32 2008 Elapsed: 767 seconds Build Failed = I have attached the below files for boot and build logs with this mail, 1) defconfig.dev - default config generated for ./ltib configure from config/platform/mpc8360epb 2) build.txt - Error build during ./ltib configure output 3) mpc8360emds_defconfig - Default config file from /home/nanda/linux2.6.20.6/arch/powerpc/configs/ The end result was I could only see the uImage generated without rootfs.ext2.gz.uboot. Please clarify on the same Thanks in advance, Regards, Nanda ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] ftrace: mcountrecord.pl for arm
Ingo and Steven,
Here's an updated version of the arch/arm changes for dynamic ftrace
based on top of your latest tip/master.
-Jim
---
From: Jim Radford [EMAIL PROTECTED]
Subject: ftrace: enable dynamic ftrace for arm
Update to the latest api, syncing functions with the x86 versions.
Index: linux-2.6/arch/arm/Kconfig
===
--- linux-2.6.orig/arch/arm/Kconfig
+++ linux-2.6/arch/arm/Kconfig
@@ -16,7 +16,9 @@ config ARM
select HAVE_ARCH_KGDB
select HAVE_KPROBES if (!XIP_KERNEL)
select HAVE_KRETPROBES if (HAVE_KPROBES)
- select HAVE_FUNCTION_TRACER if (!XIP_KERNEL)
+ select HAVE_FTRACE_MCOUNT_RECORD
+ select HAVE_DYNAMIC_FTRACE if (!XIP_KERNEL)
+ select HAVE_FUNCTION_TRACER
select HAVE_GENERIC_DMA_COHERENT
help
The ARM series is a line of low-power-consumption RISC chip designs
Index: linux-2.6/arch/arm/include/asm/ftrace.h
===
--- linux-2.6.orig/arch/arm/include/asm/ftrace.h
+++ linux-2.6/arch/arm/include/asm/ftrace.h
@@ -7,6 +7,19 @@
#ifndef __ASSEMBLY__
extern void mcount(void);
+
+static inline unsigned long ftrace_call_adjust(unsigned long addr)
+{
+ return addr;
+}
+
+#ifdef CONFIG_DYNAMIC_FTRACE
+
+struct dyn_arch_ftrace {
+ /* No extra data needed for x86 */
+};
+
+#endif /* CONFIG_DYNAMIC_FTRACE */
#endif
#endif
Index: linux-2.6/arch/arm/kernel/entry-common.S
===
--- linux-2.6.orig/arch/arm/kernel/entry-common.S
+++ linux-2.6/arch/arm/kernel/entry-common.S
@@ -104,14 +104,7 @@ ENDPROC(ret_from_fork)
#ifdef CONFIG_FUNCTION_TRACER
#ifdef CONFIG_DYNAMIC_FTRACE
ENTRY(mcount)
- stmdb sp!, {r0-r3, lr}
- mov r0, lr
- sub r0, r0, #MCOUNT_INSN_SIZE
-
- .globl mcount_call
-mcount_call:
- bl ftrace_stub
- ldmia sp!, {r0-r3, pc}
+ mov pc, lr
ENTRY(ftrace_caller)
stmdb sp!, {r0-r3, lr}
Index: linux-2.6/arch/arm/kernel/ftrace.c
===
--- linux-2.6.orig/arch/arm/kernel/ftrace.c
+++ linux-2.6/arch/arm/kernel/ftrace.c
@@ -23,13 +23,13 @@
static unsigned long bl_insn;
static const unsigned long NOP = 0xe1a0; /* mov r0, r0 */
-unsigned char *ftrace_nop_replace(void)
+static unsigned char *ftrace_nop_replace(void)
{
return (char *)NOP;
}
/* construct a branch (BL) instruction to addr */
-unsigned char *ftrace_call_replace(unsigned long pc, unsigned long addr)
+static unsigned char *ftrace_call_replace(unsigned long pc, unsigned long addr)
{
long offset;
@@ -46,7 +46,7 @@ unsigned char *ftrace_call_replace(unsig
return (unsigned char *)bl_insn;
}
-int ftrace_modify_code(unsigned long pc, unsigned char *old_code,
+static int ftrace_modify_code(unsigned long pc, unsigned char *old_code,
unsigned char *new_code)
{
unsigned long err = 0, replaced = 0, old, new;
@@ -82,22 +82,46 @@ int ftrace_modify_code(unsigned long pc,
return err;
}
+int ftrace_make_nop(struct module *mod,
+ struct dyn_ftrace *rec, unsigned long addr)
+{
+ unsigned char *new, *old;
+ unsigned long ip = rec-ip;
+
+ old = ftrace_call_replace(ip, addr);
+ new = ftrace_nop_replace();
+
+ return ftrace_modify_code(rec-ip, old, new);
+}
+
+int ftrace_make_call(struct dyn_ftrace *rec, unsigned long addr)
+{
+ unsigned char *new, *old;
+ unsigned long ip = rec-ip;
+
+ old = ftrace_nop_replace();
+ new = ftrace_call_replace(ip, addr);
+
+ return ftrace_modify_code(rec-ip, old, new);
+}
+
int ftrace_update_ftrace_func(ftrace_func_t func)
{
+ unsigned long ip = (unsigned long)(ftrace_call);
+ unsigned char old[MCOUNT_INSN_SIZE], *new;
int ret;
- unsigned long pc, old;
- unsigned char *new;
- pc = (unsigned long)ftrace_call;
- memcpy(old, ftrace_call, MCOUNT_INSN_SIZE);
- new = ftrace_call_replace(pc, (unsigned long)func);
- ret = ftrace_modify_code(pc, (unsigned char *)old, new);
+ memcpy(old, ftrace_call, sizeof(old));
+ new = ftrace_call_replace(ip, (unsigned long)func);
+ ret = ftrace_modify_code(ip, (unsigned char *)old, new);
+
return ret;
}
/* run from kstop_machine */
int __init ftrace_dyn_arch_init(void *data)
{
- ftrace_mcount_set(data);
+ /* The return code is retured via data */
+ *(unsigned long *)data = 0;
return 0;
}
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: powerpc: udbg based backend for hvc_console
On Thu, Nov 20, 2008 at 01:16:27PM -0600, Timur Tabi wrote: Milton Miller wrote: Stated differently, if your routine (1) fundamently works one character at a time and (2) is not interrupt driven, and (3) only supports one channel, what avantage is there to an explicit hvc driver? I think it's because HVC has the ability to use HVC client drivers for console and TTY, but udbg does not. So if you have a udbg-only driver, it will cease to function when the kernel switches to the normal console. Perhaps it would make more sense to have the kernel continue to use udbg if there is no normal console driver, instead of relying on David's driver. This doesn't work - the udbg console can't support a full tty driver which is needed by userspace. Originally, I was going to extend the udbg console so that it supported a tty backended onto the udbg methods. Then I realised that the code I'd need to do this would be essentially identical to hvconsole, so why duplicate it. -- David Gibson| I'll have my music baroque, and my code david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_ | _way_ _around_! http://www.ozlabs.org/~dgibson ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: powerpc: udbg based backend for hvc_console
On Thu, Nov 20, 2008 at 01:07:11PM -0600, Milton Miller wrote: [I'm going to reply to several points in this thread in one reply. I have restored context that was trimmed in later replys when I wanted to speak to.] David Gibson wrote at 2008-11-18 00:28:28: On Mon, Nov 17, 2008 at 01:41:24PM -0600, Timur Tabi wrote: On Thu, Oct 23, 2008 at 9:54 PM, David Gibson [EMAIL PROTECTED] wrote: This patch adds a new backend for the hvc console based on the low-level udbg callbacks. This effectively implements a working runtime console in terms of the simple udbg primitives. This is kind of a hack - since udbg isn't something you really want to be using routinely - but it's really useful during bringup. Why is udbg hvc something you want to not use routinely? Well.. because the udbg methods themselves are not sometimes (not always, but reasonably often), something you don't really want to use except during bringup. A number of them use various hacks that lets them work very early, and very reliably even when much of the kernel is borked, but aren't the sort of thing you want to do except during bringup. e.g. being mapped by special bolted TLB entries established very early, rather than using ioremap(); polled access for interrupt capable devices; hard-coded device addresses, meaning the kernel will only work on one precise type of system. Stated differently, if your routine (1) fundamently works one character at a time and (2) is not interrupt driven, and (3) only supports one channel, what avantage is there to an explicit hvc driver? Using standard kernel interfaces, instead of random early debug hacks. This can be used to quickly implement a userspace usable console while you're working on a proper driver for whatever console I/O device the hardware has. Or, it can be used to avoid writing a full blown tty/console driver entirely for quick-and-dirty I/O hardware that will later be replaced by something else. Actually it looks remarkably similar to a cleaned up version of a patch i've been using since hvc_console was split to be a hookable shell. Or was it the motivation for adding the hooks? The code is different in how it structures the error checks and that it is implemented in drivers/char where it belongs (hence the cleaned up comment) but the fact that David recreated what I did does speak to its general utility. Heh, ok. David, I have a stupid question. I already have an HVC console driver that works. Do I need to do anything, other than enable HVC_UDBG, to get my hvc console drive to use udbg? As was pointed out elsewhere, this is hvc calling udbg not udbg hooks calling hvc_cosole methods, which might need a different context. But I wanted to comment on David's reply: Um.. well.. if you have both activated, I think you can select which HVC console backend will be used by using console=/dev/hvcNN on the commandline, where values of NN correspond to different backends, in order depending on link order in some complex fashion. It doesn't just work that way because of the way the hvc_console shell implements the console hooks. If the drivers request different hvc channel numbers, then yes, you can select which hvc backend is used by choosing console=hvcNN. If all request 0, then which ever one registers with hvc_console first wins the slot, and the others get a busy error return. They can still register their tty later, at which point they get a dynamically determined /dev/hvcN slot, above all registered console slots. Ah, ok, my mistake. There are multiple reasons for this design. The original user, pseries vterm, wants to assign the channel number based on what the hypervisor tells it the channel should be. There are two loops though the device tree, searching for different protocols (and consequently different backends), so they need to be able to specify the number and not just use the order they are found. The platform describes not only the protocol, but which instance that is, and the backend currently registers with that number. Another reason is its a bad idea to have console=/dev/hvc0 depend on link order instead of knowing which driver is selected. If a user is specifing what the console is, it should not depend on other linked drivers. Until this point, all mainline drivers have been exclusive in that only one will actually register with hvc_console midlayer on any given platform. This is the first backend that is not exclusive, and therefore its coexistence needs special attention. In my internal tree, I register (my version of) this not as hvc0 but as hvc4. hvc0 is rtas, hvc1-3 are an internal backend, and this one is hvc4. The order I chose is arbitrary, but the main point is it does't compete with hvc_rtas for slot 0. (All of these drivers coexist, and I can choose which one I want to use based on my needs for that
Re: [PATCH] Add support for the nwp serial device
On Thu, Nov 20, 2008 at 03:01:23PM +0100, Arnd Bergmann wrote: From: Benjamin Krill [EMAIL PROTECTED] This patch adds support for the nwp serial device which is connected to a DCR bus. It uses the of_serial device driver to determine necessary properties from the device tree. The supported device is added as serial port number 84. Uh.. registers as port number 84?? What's this random number about? -- David Gibson| I'll have my music baroque, and my code david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_ | _way_ _around_! http://www.ozlabs.org/~dgibson ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] powerpc/cell/axon-msi: retry on missing interrupt
On Mon, 2008-11-17 at 17:10 +0100, Arnd Bergmann wrote:
The MSI capture logic for the axon bridge can sometimes
lose interrupts in case of high DMA and interrupt load,
when it signals an MSI interrupt to the MPIC interrupt
controller while we are already handling another MSI.
8 8 8
Index: linux-2.6/arch/powerpc/platforms/cell/axon_msi.c
===
--- linux-2.6.orig/arch/powerpc/platforms/cell/axon_msi.c 2008-11-17
10:29:05.0 -0500
+++ linux-2.6/arch/powerpc/platforms/cell/axon_msi.c 2008-11-17
10:29:08.0 -0500
@@ -95,6 +95,7 @@
struct axon_msic *msic = get_irq_data(irq);
u32 write_offset, msi;
int idx;
+ int retry = 0;
write_offset = dcr_read(msic-dcr_host, MSIC_WRITE_OFFSET_REG);
pr_debug(axon_msi: original write_offset 0x%x\n, write_offset);
@@ -102,7 +103,7 @@
/* write_offset doesn't wrap properly, so we have to mask it */
write_offset = MSIC_FIFO_SIZE_MASK;
- while (msic-read_offset != write_offset) {
+ while (msic-read_offset != write_offset retry 100) {
idx = msic-read_offset / sizeof(__le32);
msi = le32_to_cpu(msic-fifo_virt[idx]);
msi = 0x;
@@ -110,13 +111,37 @@
pr_debug(axon_msi: woff %x roff %x msi %x\n,
write_offset, msic-read_offset, msi);
+ if (msi NR_IRQS irq_map[msi].host == msic-irq_host) {
+ generic_handle_irq(msi);
+ msic-fifo_virt[idx] = cpu_to_le32(0x);
+ } else {
+ /*
+ * Reading the MSIC_WRITE_OFFSET_REG does not
+ * reliably flush the outstanding DMA to the
+ * FIFO buffer. Here we were reading stale
+ * data, so we need to retry.
+ */
+ udelay(1);
+ retry++;
+ pr_debug(axon_msi: invalid irq 0x%x!\n, msi);
+ continue;
+ }
+
+ if (retry) {
+ pr_debug(axon_msi: late irq 0x%x, retry %d\n,
+ msi, retry);
+ retry = 0;
+ }
+
msic-read_offset += MSIC_FIFO_ENTRY_SIZE;
msic-read_offset = MSIC_FIFO_SIZE_MASK;
+ }
- if (msi NR_IRQS irq_map[msi].host == msic-irq_host)
- generic_handle_irq(msi);
- else
- pr_debug(axon_msi: invalid irq 0x%x!\n, msi);
+ if (retry) {
+ printk(KERN_WARNING axon_msi: irq timed out\n);
+
+ msic-read_offset += MSIC_FIFO_ENTRY_SIZE;
+ msic-read_offset = MSIC_FIFO_SIZE_MASK;
}
By incrementing the offset we're dropping the irq. Would it be better to
just return, and hope that the next time we come in the MSI will have
landed in the fifo and then we can deliver it? It might be late, really
late I guess, but that might be better then dropping it altogether.
We'd still need an ultimate fallback case, where we drop it altogether.
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
signature.asc
Description: This is a digitally signed message part
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 4/4] leds: Let GPIO LEDs keep their current state
On Mon, 17 Nov 2008, Richard Purdie wrote:
On Fri, 2008-10-24 at 16:09 -0700, Trent Piepho wrote:
+if (template-keep_state)
+state = !!gpio_get_value(led_dat-gpio) ^ led_dat-active_low;
+else
+state = template-default_state;
state = of_get_property(child, default-state, NULL);
led.default_state = state !strcmp(state, on);
+led.keep_state = state !strcmp(state, keep);
+++ b/include/linux/leds.h
@@ -138,7 +138,8 @@ struct gpio_led {
const char *default_trigger;
unsignedgpio;
u8 active_low;
-u8 default_state;
+u8 default_state; /* 0 = off, 1 = on */
+u8 keep_state; /* overrides default_state */
};
How about something simpler here, just make default state have three
different values - keep, on and off? I'm not keen on having two
different state variables like this.
I thought of that, but it ends up being more complex. Instead of just
using:
static const struct gpio_led myled = {
.name = something,
.keep_state = 1,
}
You'd do something like this:
.default_state = LEDS_GPIO_DEFSTATE_KEEP,
Is that better? The constants for on/off/keep are one more thing you have
to look-up and remember when defining leds. The code in the leds-gpio
driver ends up getting more complex to deal with one tristate vs two
booleans.
This is a patch to change to a tristate. I don't think it's an
improvement. More symbols defined, more code, extra stuff to remember
when defining leds, and removing the field from struct gpio_led doesn't
make it smaller due to padding.
diff --git a/drivers/leds/leds-gpio.c b/drivers/leds/leds-gpio.c
index bb2a234..8a7303c 100644
--- a/drivers/leds/leds-gpio.c
+++ b/drivers/leds/leds-gpio.c
@@ -92,10 +92,10 @@ static int __devinit create_gpio_led(const struct gpio_led
*template,
led_dat-cdev.blink_set = gpio_blink_set;
}
led_dat-cdev.brightness_set = gpio_led_set;
- if (template-keep_state)
+ if (template-default_state == LEDS_GPIO_DEFSTATE_KEEP)
state = !!gpio_get_value(led_dat-gpio) ^ led_dat-active_low;
else
- state = template-default_state;
+ state = (template-default_state == LEDS_GPIO_DEFSTATE_ON);
led_dat-cdev.brightness = state ? LED_FULL : LED_OFF;
gpio_direction_output(led_dat-gpio, led_dat-active_low ^ state);
@@ -268,8 +268,15 @@ static int __devinit of_gpio_leds_probe(struct of_device
*ofdev,
led.default_trigger =
of_get_property(child, linux,default-trigger, NULL);
state = of_get_property(child, default-state, NULL);
- led.default_state = state !strcmp(state, on);
- led.keep_state = state !strcmp(state, keep);
+ if (state) {
+ if (!strcmp(state, keep)) {
+ led.default_state = LEDS_GPIO_DEFSTATE_KEEP;
+ } else if(!strcmp(state, on)) {
+ led.default_state = LEDS_GPIO_DEFSTATE_ON;
+ } else {
+ led.default_state = LEDS_GPIO_DEFSTATE_OFF;
+ }
+ }
ret = create_gpio_led(led, pdata-led_data[pdata-num_leds++],
ofdev-dev, NULL);
diff --git a/include/linux/leds.h b/include/linux/leds.h
index c51b625..f4a125c 100644
--- a/include/linux/leds.h
+++ b/include/linux/leds.h
@@ -138,9 +138,12 @@ struct gpio_led {
const char *default_trigger;
unsignedgpio;
u8 active_low;
- u8 default_state; /* 0 = off, 1 = on */
- u8 keep_state; /* overrides default_state */
+ u8 default_state;
+ /* default_state should be one of LEDS_GPIO_DEFSTATE_(ON|OFF|KEEP) */
};
+#define LEDS_GPIO_DEFSTATE_OFF 0
+#define LEDS_GPIO_DEFSTATE_ON 1
+#define LEDS_GPIO_DEFSTATE_KEEP2
struct gpio_led_platform_data {
int num_leds;
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] powerpc/mpic: don't reset affinity for secondary MPIC on boot
On Thu, 2008-11-20 at 18:23 +0100, Arnd Bergmann wrote:
Kexec/kdump currently fails on the IBM QS2x blades when the kexec happens
on a CPU other than the initial boot CPU. It turns out that this is the
result of mpic_init trying to set affinity of each interrupt vector to the
current boot CPU.
As far as I can tell, the same problem is likely to exist on any
secondary MPIC, because they have to deliver interrupts to the first
output all the time. There are two potential solutions for this: either
not set up affinity at all for secondary MPICs, or assume that a single
CPU output is connected to the upstream interrupt controller and hardcode
affinity to that per architecture.
This patch implements the second approach, defaulting to the first output.
An architecture that has a secondary MPIC connected upstream using a
different output needs to set the mpic default_dest to the correct
value before calling mpic_init.
Signed-off-by: Arnd Bergmann [EMAIL PROTECTED]
---
include/asm/mpic.h |3 +++
sysdev/mpic.c |9 +++--
2 files changed, 10 insertions(+), 2 deletions(-)
On Thursday 20 November 2008, Benjamin Herrenschmidt wrote:
I would rather, for non primary, set it to a cpu provided as
either a new argument or an mpic struct member initially set to 1 with
an accessor to change it if necessary.
How about this one?
Or should we define a flag to have it read it at init time from the chip ?
I don't understand. This is init time, where we write it to the chip,
what do you mean with reading from it? If I understand you correctly,
we can't trust that value to start with.
Oh just that for powermac for example, I know I'm resetting the thing,
so can't rely on init values, and on some BML embedded boxes too, while
on things like cell I don't off hand know what the right CPU number is
to hit the right C3PO interrupt, so I'm better off reading what SLOF
did :-)
But if you think on Cell we can just hard wire in the platform code,
then I'm ok.
Cheers,
Ben.
Arnd
diff --git a/arch/powerpc/include/asm/mpic.h b/arch/powerpc/include/asm/mpic.h
index fe566a3..543d51c 100644
--- a/arch/powerpc/include/asm/mpic.h
+++ b/arch/powerpc/include/asm/mpic.h
@@ -295,6 +295,9 @@ struct mpic
/* Protected sources */
unsigned long *protected;
+ /* destination for non-primary MPICs */
+ int default_dest;
+
#ifdef CONFIG_MPIC_WEIRD
/* Pointer to HW info array */
u32 *hw_set;
diff --git a/arch/powerpc/sysdev/mpic.c b/arch/powerpc/sysdev/mpic.c
index 8e3478c..cf154c9 100644
--- a/arch/powerpc/sysdev/mpic.c
+++ b/arch/powerpc/sysdev/mpic.c
@@ -1220,6 +1220,7 @@ void __init mpic_set_default_senses(struct mpic *mpic,
u8 *senses, int count)
void __init mpic_init(struct mpic *mpic)
{
int i;
+ int cpu;
BUG_ON(mpic-num_sources == 0);
@@ -1262,6 +1263,11 @@ void __init mpic_init(struct mpic *mpic)
mpic_pasemi_msi_init(mpic);
+ if (mpic-flags MPIC_PRIMARY)
+ cpu = hard_smp_processor_id();
+ else
+ cpu = mpic-default_dest;
+
for (i = 0; i mpic-num_sources; i++) {
/* start with vector = source number, and masked */
u32 vecpri = MPIC_VECPRI_MASK | i |
@@ -1272,8 +1278,7 @@ void __init mpic_init(struct mpic *mpic)
continue;
/* init hw */
mpic_irq_write(i, MPIC_INFO(IRQ_VECTOR_PRI), vecpri);
- mpic_irq_write(i, MPIC_INFO(IRQ_DESTINATION),
-1 hard_smp_processor_id());
+ mpic_irq_write(i, MPIC_INFO(IRQ_DESTINATION), 1 cpu);
}
/* Init spurious vector */
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [spi-devel-general] [PATCH v3] spi: Add PPC4xx SPI driver
On Thursday 30 October 2008, Jason Hanna wrote: Also, any pointers to sample/test code incorporating a spi protocol driver would be incredibly helpful. Look at Documentation/spi/*.c ... for user mode code hooking up through spidev. I'm very new to device driver programming and don't really know what I'm doing yet. I seem to be getting the spi_ppc4xx and spi_bitbang modules loaded, but am unsure how to verify proper initialization and what next steps I need to follow in order to develop and associate a protocol driver. Documentation/spi/spi-summary should help. And sticking a 'scope on the outputs (as you said you plan) is a decent place to start, if you don't have something to talk to yet. - dave ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [spi-devel-general] [PATCH v4] spi: Add PPC4xx SPI driver
On Friday 31 October 2008, Stefan Roese wrote: + dev_dbg(spi-dev, %s: mode %d, %u bpw, %d hz\n, + __FUNCTION__, spi-mode, spi-bits_per_word, + spi-max_speed_hz); Oh, and checkpatch.pl would warn about __FUNCTION__ vs __func__ ... ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] Add support for the nwp serial device
On Fri, Nov 21, 2008 at 08:21:02AM +0100, Benjamin Krill wrote: * David Gibson | 2008-11-21 11:35:45 [+1100]: Uh.. registers as port number 84?? What's this random number about? It's just the next free number in serial_core.h. Ah, right, sorry, those are type codes. Thought you meant it was registering as /dev/ttyS84 or something similarly strange. -- David Gibson| I'll have my music baroque, and my code david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_ | _way_ _around_! http://www.ozlabs.org/~dgibson ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
