Re: [BUG] hvc_console WARN() on current upstream
Am Donnerstag, 8. Januar 2009 schrieb Benjamin Herrenschmidt: [ cut here ] Badness at /home/benh/kernels/linux-powerpc/kernel/mutex.c:135 NIP: c04fe0dc LR: c04fe0c0 CTR: c02c4304 REGS: cfffb660 TRAP: 0700 Not tainted (2.6.28-test) MSR: 80021032 ME,CE,IR,DR CR: 2882 XER: 2003 TASK = c07bd340[0] 'swapper' THREAD: c0874000 CPU: 0 GPR00: cfffb8e0 c0877438 0001 GPR04: c000225f0928 0003 0801 GPR08: cf3cf3cf3cf3cf3d c0e6edc0 c0787634 c08d45ac GPR12: 2882 c08b7300 c0002254db20 0001 GPR16: 0003 c0002254d940 c0002254da70 c000225f0828 GPR20: c000225f0929 c0002254dee8 GPR24: c02c2604 0003 c07bd340 GPR28: c0002254dee8 c0002254d800 c07ef2b8 c0002254dee8 NIP [c04fe0dc] .mutex_lock_nested+0x90/0x408 LR [c04fe0c0] .mutex_lock_nested+0x74/0x408 Call Trace: [cfffb9e0] [c02c2604] .echo_set_canon_col+0x28/0x68 [cfffba70] [c02c4db4] .n_tty_receive_buf+0xcbc/0xfe0 [cfffbc10] [c02c80f8] .flush_to_ldisc+0x18c/0x24c [cfffbcd0] [c02dd02c] .hvc_poll+0x2d0/0x328 [cfffbde0] [c02dd2e4] .hvc_handle_interrupt+0x14/0x3c [cfffbe50] [c00999a4] .handle_IRQ_event+0x50/0xc0 [cfffbef0] [c009bdec] .handle_fasteoi_irq+0xf8/0x194 [cfffbf90] [c0025950] .call_handle_irq+0x1c/0x2c [c0877a30] [c000cd18] .do_IRQ+0x104/0x1dc [c0877ae0] [c0004800] hardware_interrupt_entry+0x18/0x98 --- Exception: 501 at .cpu_idle+0x104/0x190 LR = .cpu_idle+0x104/0x190 [c0877dd0] [c0011e58] .cpu_idle+0xf8/0x190 (unreliable) [c0877e60] [c0500b24] .rest_init+0x7c/0x94 [c0877ee0] [c0715aec] .start_kernel+0x3f4/0x414 [c0877f90] [c0008368] .start_here_common+0x1c/0x34 Instruction dump: 78290464 80090014 5409012f 41820028 4bd5ead5 6000 2fa3 419e0018 e93e8008 8009 2f80 409e0008 0fe0 3800 8b8d01da 980d01da The machine still boots, so it's not a show stopper. Hmmm, Seems that we are in interrupt, doing hvc_poll, which does tty_flip_buffer_push which calls flush_to_ldisc doing a n_tty_receive_buf and we will finally take a mutex in echo_set_canon_col my first guess is that the following patch triggered the Badness: git show a88a69c9 commit a88a69c91256418c5907c2f1f8a0ec0a36f9e6cc Author: Joe Peterson j...@skyrush.com Date: Fri Jan 2 13:40:53 2009 + n_tty: Fix loss of echoed characters and remove bkl from n_tty I have no idea how to fix this. Joe Peterson CCed. Christian ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [BUG] hvc_console WARN() on current upstream
Also including Alan, he's the current tty guru On Thu, 2009-01-08 at 08:57 +0100, Christian Borntraeger wrote: Am Donnerstag, 8. Januar 2009 schrieb Benjamin Herrenschmidt: [ cut here ] Badness at /home/benh/kernels/linux-powerpc/kernel/mutex.c:135 NIP: c04fe0dc LR: c04fe0c0 CTR: c02c4304 REGS: cfffb660 TRAP: 0700 Not tainted (2.6.28-test) MSR: 80021032 ME,CE,IR,DR CR: 2882 XER: 2003 TASK = c07bd340[0] 'swapper' THREAD: c0874000 CPU: 0 GPR00: cfffb8e0 c0877438 0001 GPR04: c000225f0928 0003 0801 GPR08: cf3cf3cf3cf3cf3d c0e6edc0 c0787634 c08d45ac GPR12: 2882 c08b7300 c0002254db20 0001 GPR16: 0003 c0002254d940 c0002254da70 c000225f0828 GPR20: c000225f0929 c0002254dee8 GPR24: c02c2604 0003 c07bd340 GPR28: c0002254dee8 c0002254d800 c07ef2b8 c0002254dee8 NIP [c04fe0dc] .mutex_lock_nested+0x90/0x408 LR [c04fe0c0] .mutex_lock_nested+0x74/0x408 Call Trace: [cfffb9e0] [c02c2604] .echo_set_canon_col+0x28/0x68 [cfffba70] [c02c4db4] .n_tty_receive_buf+0xcbc/0xfe0 [cfffbc10] [c02c80f8] .flush_to_ldisc+0x18c/0x24c [cfffbcd0] [c02dd02c] .hvc_poll+0x2d0/0x328 [cfffbde0] [c02dd2e4] .hvc_handle_interrupt+0x14/0x3c [cfffbe50] [c00999a4] .handle_IRQ_event+0x50/0xc0 [cfffbef0] [c009bdec] .handle_fasteoi_irq+0xf8/0x194 [cfffbf90] [c0025950] .call_handle_irq+0x1c/0x2c [c0877a30] [c000cd18] .do_IRQ+0x104/0x1dc [c0877ae0] [c0004800] hardware_interrupt_entry+0x18/0x98 --- Exception: 501 at .cpu_idle+0x104/0x190 LR = .cpu_idle+0x104/0x190 [c0877dd0] [c0011e58] .cpu_idle+0xf8/0x190 (unreliable) [c0877e60] [c0500b24] .rest_init+0x7c/0x94 [c0877ee0] [c0715aec] .start_kernel+0x3f4/0x414 [c0877f90] [c0008368] .start_here_common+0x1c/0x34 Instruction dump: 78290464 80090014 5409012f 41820028 4bd5ead5 6000 2fa3 419e0018 e93e8008 8009 2f80 409e0008 0fe0 3800 8b8d01da 980d01da The machine still boots, so it's not a show stopper. Hmmm, Seems that we are in interrupt, doing hvc_poll, which does tty_flip_buffer_push which calls flush_to_ldisc doing a n_tty_receive_buf and we will finally take a mutex in echo_set_canon_col my first guess is that the following patch triggered the Badness: git show a88a69c9 commit a88a69c91256418c5907c2f1f8a0ec0a36f9e6cc Author: Joe Peterson j...@skyrush.com Date: Fri Jan 2 13:40:53 2009 + n_tty: Fix loss of echoed characters and remove bkl from n_tty I have no idea how to fix this. Joe Peterson CCed. Christian ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: 2.6.28-rc9 panics with crashkernel=256M while booting
On Wednesday 07 January 2009 22:55:25 Dave Hansen wrote:
I'm just suggesting making your fix in the ppc code instead of in
mm/bootmem.c.
Here are the changes that helped to boot the kernel. Please review it.
Thanks,
Signed-off-by: Chandru S chan...@linux.vnet.ibm.com
Cc: Dave Hansen d...@linux.vnet.ibm.com
---
arch/powerpc/mm/numa.c | 11 ++-
1 file changed, 10 insertions(+), 1 deletion(-)
--- linux-2.6.28/arch/powerpc/mm/numa.c.orig2009-01-08 03:20:41.0
-0600
+++ linux-2.6.28/arch/powerpc/mm/numa.c 2009-01-08 03:50:41.0 -0600
@@ -16,6 +16,7 @@
#include linux/module.h
#include linux/nodemask.h
#include linux/cpu.h
+#include linux/pfn.h
#include linux/notifier.h
#include linux/lmb.h
#include linux/of.h
@@ -898,9 +899,17 @@ static void mark_reserved_regions_for_ni
* if reserved region extends past active region
* then trim size to active region
*/
- if (end_pfn node_ar.end_pfn)
+ if (end_pfn node_ar.end_pfn) {
reserve_size = (node_ar.end_pfn PAGE_SHIFT)
- (start_pfn PAGE_SHIFT);
+ /*
+* resize it further if the reservation could
+* cross the last page in this node
+*/
+ if (PFN_UP(physbase+reserve_size)
+node_end_pfn)
+ reserve_size -= PAGE_SIZE;
+ }
/*
* Only worry about *this* node, others may not
* yet have valid NODE_DATA().
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [patch 0/6] ps3vram driver patches
On Wed, 7 Jan 2009, Arnd Bergmann wrote: On Wednesday 07 January 2009, Geoff Levand wrote: Geert and I were discussing actually removing the direct write to the XDR memory, and so the need for that ioremap, as the mapping is just used in ps3vram_erase(), which seems could be removed. ps3vram_erase() writes all ones to the memory, as that's what done when erasing real FLASH. I do not know if the MTD layer can handle it if we don't erase it to ones. David? Ah, I see. I also forgot to mention that the ioremap_flags change should only be done for actual memory regions, but *not* for memory mapped I/O registers. This is DDR memory for the RSX. I want to get it converted to a block device, and I will work towards that, but it will take some time. �As it is, it is very useful for typical systems that are running full desktops like gmome or KDE and do a lot of swapping. �Many of the distros now use it, and users want it. Yes, fine by me. One disadvantage of this approach is that it makes life more difficult for distro maintainers: their userland has to support both the MTD and the block version. With kind regards, Geert Uytterhoeven Software Architect Sony Techsoft Centre Europe The Corporate Village · Da Vincilaan 7-D1 · B-1935 Zaventem · Belgium Phone:+32 (0)2 700 8453 Fax: +32 (0)2 700 8622 E-mail: geert.uytterhoe...@sonycom.com Internet: http://www.sony-europe.com/ A division of Sony Europe (Belgium) N.V. VAT BE 0413.825.160 · RPR Brussels Fortis · BIC GEBABEBB · IBAN BE41293037680010 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH v6] spi: Add PPC4xx SPI driver
This adds a SPI driver for the SPI controller found in the IBM/AMCC
4xx PowerPC's.
Signed-off-by: Stefan Roese s...@denx.de
Signed-off-by: Wolfgang Ocker w...@reccoware.de
Acked-by: Josh Boyer jwbo...@linux.vnet.ibm.com
---
Changes in v6:
- Moved comment about high interrupt load to top of file and extended it
by explaining that the 4xx SPI controller has no FIFOs.
- Added parameter checking to setup() routine.
- Removed comment about LSB
- Used of_gpio_count() instead creating own static implementation as
suggested by Anton.
Changes in v5:
- Don't call setupxfer() from setup() so that the baudrate etc
won't get changed while another transfer is active, as suggested
by David Brownell.
- module_{init,exit} moved directly to the functions to which they
apply.
- Use __func__ instead of __FUNCTION__.
Changes in v4:
- Added fixes suggested by Josh Boyer
- Changed compatible property from ibm,spi to ibm,ppc4xx-spi
Changes in v3:
- When the device is removed the GPIOs are released. The memory
for the GPIO array is freed.
Changes in v2:
- Now the gpios property is correctly decoded and the
resulting gpio numbers are used as the devices chip
selects.
drivers/spi/Kconfig |7 +
drivers/spi/Makefile |1 +
drivers/spi/spi_ppc4xx.c | 594 ++
3 files changed, 602 insertions(+), 0 deletions(-)
create mode 100644 drivers/spi/spi_ppc4xx.c
diff --git a/drivers/spi/Kconfig b/drivers/spi/Kconfig
index b9d0efb..69d5fee 100644
--- a/drivers/spi/Kconfig
+++ b/drivers/spi/Kconfig
@@ -155,6 +155,13 @@ config SPI_ORION
help
This enables using the SPI master controller on the Orion chips.
+config SPI_PPC4xx
+ tristate PPC4xx SPI Controller
+ depends on 4xx SPI_MASTER
+ select SPI_BITBANG
+ help
+ This selects a driver for the PPC4xx SPI Controller.
+
config SPI_PXA2XX
tristate PXA2xx SSP SPI master
depends on ARCH_PXA EXPERIMENTAL
diff --git a/drivers/spi/Makefile b/drivers/spi/Makefile
index ccf18de..a2e5816 100644
--- a/drivers/spi/Makefile
+++ b/drivers/spi/Makefile
@@ -24,6 +24,7 @@ obj-$(CONFIG_SPI_OMAP24XX)+= omap2_mcspi.o
obj-$(CONFIG_SPI_ORION)+= orion_spi.o
obj-$(CONFIG_SPI_MPC52xx_PSC) += mpc52xx_psc_spi.o
obj-$(CONFIG_SPI_MPC83xx) += spi_mpc83xx.o
+obj-$(CONFIG_SPI_PPC4xx) += spi_ppc4xx.o
obj-$(CONFIG_SPI_S3C24XX_GPIO) += spi_s3c24xx_gpio.o
obj-$(CONFIG_SPI_S3C24XX) += spi_s3c24xx.o
obj-$(CONFIG_SPI_TXX9) += spi_txx9.o
diff --git a/drivers/spi/spi_ppc4xx.c b/drivers/spi/spi_ppc4xx.c
new file mode 100644
index 000..15d433a
--- /dev/null
+++ b/drivers/spi/spi_ppc4xx.c
@@ -0,0 +1,594 @@
+/*
+ * SPI_PPC4XX SPI controller driver.
+ *
+ * Copyright (C) 2007 Gary Jennejohn ga...@denx.de
+ * Copyright 2008 Stefan Roese s...@denx.de, DENX Software Engineering
+ *
+ * Based in part on drivers/spi/spi_s3c24xx.c
+ *
+ * Copyright (c) 2006 Ben Dooks
+ * Copyright (c) 2006 Simtec Electronics
+ * Ben Dooks b...@simtec.co.uk
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License version 2 as published
+ * by the Free Software Foundation.
+ */
+
+/*
+ * The PPC4xx SPI controller has no FIFO so each sent/received byte will
+ * generate an interrupt to the CPU. This can cause high CPU utilization.
+ * This driver allows platforms to reduce the interrupt load on the CPU
+ * during SPI transfers by setting max_speed_hz via the device tree.
+ */
+
+#include linux/module.h
+#include linux/init.h
+#include linux/sched.h
+#include linux/errno.h
+#include linux/wait.h
+#include linux/of_platform.h
+#include linux/of_spi.h
+#include linux/of_gpio.h
+#include linux/interrupt.h
+#include linux/delay.h
+
+#include linux/gpio.h
+#include linux/spi/spi.h
+#include linux/spi/spi_bitbang.h
+
+#include asm/io.h
+#include asm/dcr.h
+#include asm/dcr-regs.h
+
+/* bits in mode register - bit 0 ist MSb */
+/* data latched on leading edge of clock, else trailing edge */
+#define SPI_PPC4XX_MODE_SCP(0x80 3)
+/* port enabled */
+#define SPI_PPC4XX_MODE_SPE(0x80 4)
+/* MSB first, else LSB first */
+#define SPI_PPC4XX_MODE_RD (0x80 5)
+/* clock invert - idle clock = 1, active clock = 0; else reversed */
+#define SPI_PPC4XX_MODE_CI (0x80 6)
+/* loopback enable */
+#define SPI_PPC4XX_MODE_IL (0x80 7)
+/* bits in control register */
+/* starts a transfer when set */
+#define SPI_PPC4XX_CR_STR (0x80 7)
+/* bits in status register */
+/* port is busy with a transfer */
+#define SPI_PPC4XX_SR_BSY (0x80 6)
+/* RxD ready */
+#define SPI_PPC4XX_SR_RBR (0x80 7)
+
+/* the spi-mode bits understood by this driver: */
+#define MODEBITS (SPI_CPHA | SPI_CPOL | SPI_CS_HIGH | SPI_LSB_FIRST)
+
+/* clock settings (SCP and CI) for various SPI modes */
+#define SPI_CLK_MODE0
Re: [PATCH 1/3] radeonfb: Fix 64 bits resources on 32 bits archs
Hello.
Benjamin Herrenschmidt wrote:
This fixes radeonfb to not truncate 64 bits resources on 32 bits
platforms. Unfortunately, there are still issues with addresses
returned to userspace via struct fb_fix_screeninfo. This will
have to be dealt with separately.
Signed-off-by: Benjamin Herrenschmidt b...@kernel.crashing.org
I'm seeing that these 3 patch series (dating back to April) still
unapplied. Have everybody forgotten about them? I'd like to see them
finally applied.
--- linux-work.orig/drivers/video/aty/radeon_base.c 2008-04-22
11:04:19.0 +1000
+++ linux-work/drivers/video/aty/radeon_base.c 2008-04-22 11:05:00.0
+1000
@@ -1886,7 +1886,7 @@ static int __devinit radeon_set_fbinfo (
info-screen_size = rinfo-mapped_vram;
/* Fill fix common fields */
strlcpy(info-fix.id, rinfo-name, sizeof(info-fix.id));
-info-fix.smem_start = rinfo-fb_base_phys;
+info-fix.smem_start = (unsigned long)rinfo-fb_base_phys;
info-fix.smem_len = rinfo-video_ram;
info-fix.type = FB_TYPE_PACKED_PIXELS;
info-fix.visual = FB_VISUAL_PSEUDOCOLOR;
@@ -1894,7 +1894,7 @@ static int __devinit radeon_set_fbinfo (
info-fix.ypanstep = 1;
info-fix.ywrapstep = 0;
info-fix.type_aux = 0;
-info-fix.mmio_start = rinfo-mmio_base_phys;
+info-fix.mmio_start = (unsigned long)rinfo-mmio_base_phys;
info-fix.mmio_len = RADEON_REGSIZE;
info-fix.accel = FB_ACCEL_ATI_RADEON;
Index: linux-work/drivers/video/aty/radeonfb.h
===
--- linux-work.orig/drivers/video/aty/radeonfb.h2008-04-22
11:03:17.0 +1000
+++ linux-work/drivers/video/aty/radeonfb.h 2008-04-22 11:03:27.0
+1000
@@ -287,8 +287,8 @@ struct radeonfb_info {
char name[DEVICE_NAME_SIZE];
- unsigned long mmio_base_phys;
- unsigned long fb_base_phys;
+ resource_size_t mmio_base_phys;
+ resource_size_t fb_base_phys;
void __iomem *mmio_base;
void __iomem*fb_base;
WBR, Sergei
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 1/3] radeonfb: Fix 64 bits resources on 32 bits archs
Hello.
Benjamin Herrenschmidt wrote:
This fixes radeonfb to not truncate 64 bits resources on 32 bits
platforms. Unfortunately, there are still issues with addresses
returned to userspace via struct fb_fix_screeninfo. This will
have to be dealt with separately.
Signed-off-by: Benjamin Herrenschmidt b...@kernel.crashing.org
I'm seeing that this 3 patch series (dating back to April) still
unapplied. Have everybody forgotten about them? I'd like to see them
finally applied.
--- linux-work.orig/drivers/video/aty/radeon_base.c 2008-04-22
11:04:19.0 +1000
+++ linux-work/drivers/video/aty/radeon_base.c 2008-04-22 11:05:00.0
+1000
@@ -1886,7 +1886,7 @@ static int __devinit radeon_set_fbinfo (
info-screen_size = rinfo-mapped_vram;
/* Fill fix common fields */
strlcpy(info-fix.id, rinfo-name, sizeof(info-fix.id));
-info-fix.smem_start = rinfo-fb_base_phys;
+info-fix.smem_start = (unsigned long)rinfo-fb_base_phys;
info-fix.smem_len = rinfo-video_ram;
info-fix.type = FB_TYPE_PACKED_PIXELS;
info-fix.visual = FB_VISUAL_PSEUDOCOLOR;
@@ -1894,7 +1894,7 @@ static int __devinit radeon_set_fbinfo (
info-fix.ypanstep = 1;
info-fix.ywrapstep = 0;
info-fix.type_aux = 0;
-info-fix.mmio_start = rinfo-mmio_base_phys;
+info-fix.mmio_start = (unsigned long)rinfo-mmio_base_phys;
info-fix.mmio_len = RADEON_REGSIZE;
info-fix.accel = FB_ACCEL_ATI_RADEON;
Index: linux-work/drivers/video/aty/radeonfb.h
===
--- linux-work.orig/drivers/video/aty/radeonfb.h2008-04-22
11:03:17.0 +1000
+++ linux-work/drivers/video/aty/radeonfb.h 2008-04-22 11:03:27.0
+1000
@@ -287,8 +287,8 @@ struct radeonfb_info {
char name[DEVICE_NAME_SIZE];
- unsigned long mmio_base_phys;
- unsigned long fb_base_phys;
+ resource_size_t mmio_base_phys;
+ resource_size_t fb_base_phys;
void __iomem *mmio_base;
void __iomem*fb_base;
WBR, Sergei
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 1/2] watchdog: Basic support for GE Fanuc's FPGA based watchdog timer
Wim Van Sebroeck wrote: Hi All, Any status of acceptance of this? I changed the ioctl to an unlocked ioctl and removed the temperature ioctl call. It's now in my linux-2.6-watchdog-next tree. Can someone verify that it still works? (http://git.kernel.org/?p=linux/kernel/git/wim/linux-2.6-watchdog-next.git;a=summary) Hi Wim, Thank you for reviewing these patches. I have made the changes you have on my dev tree and, whilst I don't have an SBC610 to hand, I have checked the driver on a similar board which also uses the same watchdog and it's still working as expected. Martyn -- Martyn Welch MEng MPhil MIET (Principal Software Engineer) T:+44(0)1327322748 GE Fanuc Intelligent Platforms Ltd,|Registered in England and Wales Tove Valley Business Park, Towcester, |(3828642) at 100 Barbirolli Square, Northants, NN12 6PF, UK T:+44(0)1327359444 |Manchester,M2 3AB VAT:GB 729849476 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [BUG] hvc_console WARN() on current upstream
Seems that we are in interrupt, doing hvc_poll, which does tty_flip_buffer_push Which means that someone has tty-low_latency set and is calling tty_flip_buffer_push in an IRQ. That has never been allowed or safe, and now it hurts ;) /** * tty_flip_buffer_push- terminal * @tty: tty to push * * Queue a push of the terminal flip buffers to the line discipline. This * function must not be called from IRQ context if tty-low_latency is set * * In the event of the queue being busy for flipping the work will be * held off and retried later. * * Locking: tty buffer lock. Driver locks in low latency mode. */ That comment has been there for some years in varying formats ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Kernel completely crashes after accessing an unmapped area.
Hello Benjamin
Thank you very much for your help. You are completely right, once I
have fixed the cputable everything worked like a charm. I have
reviewed the last git version and it seems solved there, so I wont
publish the patch in git format ( to avoid confusions)
Best regards
--- a/arch/powerpc/kernel/cputable.c
+++ b/arch/powerpc/kernel/cputable.c
@@ -1487,6 +1487,8 @@ static struct cpu_spec __initdata cpu_specs[] = {
.cpu_user_features = COMMON_USER_BOOKE,
.icache_bsize = 32,
.dcache_bsize = 32,
+ .cpu_setup = __setup_cpu_440spe,
+ .machine_check = machine_check_440A,
.platform = ppc440,
},
{ /* 460EX */
r...@q5:~# md.l 0x8000
[ 191.806370] Machine check in kernel mode.
[ 191.809078] Data Read PLB Error
[ 191.812194] Oops: Machine check, sig: 7 [#2]
[ 191.816419] PREEMPT Xilinx Virtex440
[ 191.819962] Modules linked in: reg_user
[ 191.823767] NIP: d106f16c LR: d106f128 CTR: c000f90c
[ 191.828699] REGS: cfff9f10 TRAP: 0214 Tainted: G D(2.6.27)
[ 191.835082] MSR: 00029000 EE,ME CR: 84000422 XER:
[ 191.840875] TASK = cf83d000[2969] 'md.l' THREAD: ce8a8000
[ 191.846055] GPR00: a5a5a5a5 ce8a9e50 cf83d000 d1072000 d1072000
8000 051b
[ 191.854350] GPR08: 8000
10018d78 fffda400
[ 191.862644] GPR16: ffbbfffc 0004 003f 01ff
1008d23c 1008d254
[ 191.870938] GPR24: 4800e454 bf820e00 0002 40087100 40087100
c02e6bf0 40087100 bf820b70
[ 191.879421] NIP [d106f16c] reg_user_ioctl+0x16c/0x1c8 [reg_user]
[ 191.885375] LR [d106f128] reg_user_ioctl+0x128/0x1c8 [reg_user]
[ 191.891242] Call Trace:
[ 191.893670] [ce8a9e50] [d106f128] reg_user_ioctl+0x128/0x1c8
[reg_user] (unreliable)
[ 191.901364] [ce8a9e80] [c00956dc] vfs_ioctl+0x9c/0xa8
[ 191.906369] [ce8a9ea0] [c009576c] do_vfs_ioctl+0x84/0x68c
[ 191.911725] [ce8a9f10] [c0095db4] sys_ioctl+0x40/0x74
[ 191.916744] [ce8a9f40] [c000d3c4] ret_from_syscall+0x0/0x3c
[ 191.922260] Instruction dump:
[ 191.925200] 6fc04008 2f807100 419e0020 48000101 3860 4bfffee8
3c60d107 3863f314
[ 191.932887] 48bd 4bb8 7c0004ac 8003 0c00 4c00012c
9001000c 80020214
[ 191.940754] ---[ end trace af45d29b317f9126 ]---
Bus error
r...@q5:~# ls
On Fri, Nov 21, 2008 at 10:17, Benjamin Herrenschmidt
b...@kernel.crashing.org wrote:
On Wed, 2008-11-19 at 13:59 +0100, Ricardo wrote:
Hello All:
I am using the paulus tree popwerpc linux kernel for a ppc440 cpu
located in a Virtex5 FPGA.
While developing some drivers (a simple gpio device) I have notice
that if I try to access an unmapped area (an address without any
register/device attached), the system completely crashes... I remember
that doing the same with a ppc400 cpu the system showed a
Instruction/Data bus error and continue working.
My question: The ppc440 cannot recover from this types of errors or
is a kernel missing feature/bug?
You may want to look at the patch I posted recently:
powerpc: Fix 460EX/460GT machine check handling
From the look of your log, we aren't using the right type of machine
check handler for your core and it may need a similar treatement as the
above processors.
There are two kind of 440 cores vs. machine checks. On the old kind,
machine checks used to be critical interrupts (and thus used CSRR0 and
CSRR1 to save the context) while on the new kind, machine checks are
their own type of exception with a dedicated pair of context save
registers MCSRR0 and MCSRR1.
It -looks- like the problem might be that the kernel isn't using the
right set for your core. It uses by default the old style unless
you change the machine check IVOR to point to MachineCheckA
which is done by calling __fixup_440A_mcheck() in your CPU init routine
for example, as we do for other 440 cores.
So you would have to hook up a setup_cpu routine in cputable for
those guys (I can see the virtex cores seem to not have any at
this stage) and also change their machine check pointer to
use machine_check_440A instead of machine_check_4xx so the machine
check details are properly decoded.
Of course check your Virtex user manual to make sure that's indeed
what is happening :-)
Cheers,
Ben.
--
Ricardo Ribalda
http://www.eps.uam.es/~rribalda/
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH 0/5] hvc_console updates was Re: [BUG] hvc_console WARN() on current upstream
Alan Cox wrote: Benjamin Herrenschmidt wrote: Seems that we are in interrupt, doing hvc_poll, which does tty_flip_buffer_push Which means that someone has tty-low_latency set and is calling tty_flip_buffer_push in an IRQ. That has never been allowed or safe, and now it hurts ;) /** * tty_flip_buffer_push- terminal * @tty: tty to push * * Queue a push of the terminal flip buffers to the line discipline. This * function must not be called from IRQ context if tty-low_latency is set * * In the event of the queue being busy for flipping the work will be * held off and retried later. * * Locking: tty buffer lock. Driver locks in low latency mode. */ That comment has been there for some years in varying formats I actually was preparing a patch for this problem after I had encountered the a deadlock due to this. That is in the first patch. I then found and made a few more cleanups, although I might have reordered the rest. The history for setting low_latency is in the changelog of the first patch.. milton ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH 3/4] hvc_console: free_irq only if request_irq was successful
Only call free_irq if we marked the request_irq has having succeeded
instead of whenever the the sub-driver identified the interrupt to use.
Signed-off-by: Milton Miller milt...@bga.com
---
Appears to be a bugfix but might use a bit of time in -next.
This code was created in 2.6.28 to allow s390 to build without adding ifdefs.
Many hvc-console sub-drivers have a single channel and are not modules.
Index: work.git/drivers/char/hvc_irq.c
===
--- work.git.orig/drivers/char/hvc_irq.c2009-01-08 04:07:28.0
-0600
+++ work.git/drivers/char/hvc_irq.c 2009-01-08 04:07:47.0 -0600
@@ -37,7 +37,7 @@ int notifier_add_irq(struct hvc_struct *
void notifier_del_irq(struct hvc_struct *hp, int irq)
{
- if (!irq)
+ if (!hp-irq_requested)
return;
free_irq(irq, hp);
hp-irq_requested = 0;
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH 2/4] hvc_console: use kzalloc
Replace kmalloc + memset with kzalloc. Signed-off-by: Milton Miller milt...@bga.com Index: work.git/drivers/char/hvc_console.c === --- work.git.orig/drivers/char/hvc_console.c2009-01-08 04:24:10.0 -0600 +++ work.git/drivers/char/hvc_console.c 2009-01-08 04:24:35.0 -0600 @@ -765,13 +765,11 @@ struct hvc_struct __devinit *hvc_alloc(u return ERR_PTR(err); } - hp = kmalloc(ALIGN(sizeof(*hp), sizeof(long)) + outbuf_size, + hp = kzalloc(ALIGN(sizeof(*hp), sizeof(long)) + outbuf_size, GFP_KERNEL); if (!hp) return ERR_PTR(-ENOMEM); - memset(hp, 0x00, sizeof(*hp)); - hp-vtermno = vtermno; hp-data = data; hp-ops = ops; ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH 4/4] hvc_console: comment mb and make it an smp_ one
I remember some history on this barrier. There was a race between open via /dev/console and the tty being fully setup. Its also why there is a temporary variable and the global is assigned at the end of the function. Signed-off-by: Milton Miller milt...@bga.com Index: work.git/drivers/char/hvc_console.c === --- work.git.orig/drivers/char/hvc_console.c2009-01-08 04:33:39.0 -0600 +++ work.git/drivers/char/hvc_console.c 2009-01-08 04:35:09.0 -0600 @@ -875,8 +875,11 @@ static int hvc_init(void) goto stop_thread; } - /* FIXME: This mb() seems completely random. Remove it. */ - mb(); + /* +* Make sure tty is fully registered before allowing it to be +* found by hvc_console_device. +*/ + smp_mb(); hvc_driver = drv; return 0; ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH 1/4] hvc_console: do not set low_latency
hvc_console is setting low_latency unconditionally, but some clients are interrupt driven and will call hvc_poll from irq context. This will cause tty_flip_buffer_push to be called from irq context, and it very clearly states it must not be called from IRQ when low_latency is specified. Looking back through history: v2.6.16-rc1 via 33f0f88f1c51ae5c2d593d26960c760ea154c2e2 [PATCH] TTY layer buffering revamp added this new api. v2.6.16-rc3 via 8977d929e49021d9a6e031310aab01fa72f849c2 [PATCH] tty buffering stall fix claims to fix a stall discovered with hvc_console v2.6.16-rc5 via fb5c594c2acc441f0d2d8f457484a0e0e9285db3 [PATCH] Fix race condition in hvc console. said set this flag to avoid a stall problem, and was merged through the powerpc arch tree. Without searching for email discussions, it would appear to be an overlapping fix, but one that did not consider all users. --- This version continues to set low_latency if irqs are not flagged to be in use, as requested by paulus. Do all hvc drivers identify the interrupt this way? (A quick look at hvc_iucv says they lock to bh and are not irq driven, the rest would have used the irq before that patch). Having the flag set for purely polled drivers will save delaying the work when receiving input for 1 jiffie. Index: work.git/drivers/char/hvc_console.c === --- work.git.orig/drivers/char/hvc_console.c2009-01-08 03:01:24.0 -0600 +++ work.git/drivers/char/hvc_console.c 2009-01-08 03:01:51.0 -0600 @@ -318,7 +318,8 @@ static int hvc_open(struct tty_struct *t } /* else count == 0 */ tty-driver_data = hp; - tty-low_latency = 1; /* Makes flushes to ldisc synchronous. */ + if (!hp-irq_requested) + tty-low_latency = 1; /* Makes flushes to ldisc synchronous. */ hp-tty = tty; ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH 4/4] powerpc: numa: avoid possible reference beyond property length in find_min_common_depth
find_min_common_depth was checking the property length incorrectly.
The value is in bytes not cells, and it is using the second entry.
Signed-off-By: Milton Miller milt...@bga.com
---
I'm not aware of any trees that are broken in this way, so backport
not likely needed but easy to apply.
Index: work.git/arch/powerpc/mm/numa.c
===
--- work.git.orig/arch/powerpc/mm/numa.c2009-01-05 05:08:10.0
-0600
+++ work.git/arch/powerpc/mm/numa.c 2009-01-05 05:10:25.0 -0600
@@ -260,7 +260,7 @@ static int __init find_min_common_depth(
ref_points = of_get_property(rtas_root,
ibm,associativity-reference-points, len);
- if ((len = 1) ref_points) {
+ if ((len = 2 * sizeof(unsigned int)) ref_points) {
depth = ref_points[1];
} else {
dbg(NUMA: ibm,associativity-reference-points not found.\n);
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH 3/4] powerpc: remove redundant find_cpu_node
use of_get_cpu_node, which is a superset of numa.c's find_cpu_node in
a less restrictive section (text vs cpuinit).
Signed-off-by: Milton Miller milt...@bga.com
Index: work.git/arch/powerpc/mm/numa.c
===
--- work.git.orig/arch/powerpc/mm/numa.c2008-12-18 15:31:35.0
-0600
+++ work.git/arch/powerpc/mm/numa.c 2009-01-05 05:10:29.0 -0600
@@ -157,35 +157,6 @@ static void unmap_cpu_from_node(unsigned
}
#endif /* CONFIG_HOTPLUG_CPU */
-static struct device_node * __cpuinit find_cpu_node(unsigned int cpu)
-{
- unsigned int hw_cpuid = get_hard_smp_processor_id(cpu);
- struct device_node *cpu_node = NULL;
- const unsigned int *interrupt_server, *reg;
- int len;
-
- while ((cpu_node = of_find_node_by_type(cpu_node, cpu)) != NULL) {
- /* Try interrupt server first */
- interrupt_server = of_get_property(cpu_node,
- ibm,ppc-interrupt-server#s, len);
-
- len = len / sizeof(u32);
-
- if (interrupt_server (len 0)) {
- while (len--) {
- if (interrupt_server[len] == hw_cpuid)
- return cpu_node;
- }
- } else {
- reg = of_get_property(cpu_node, reg, len);
- if (reg (len 0) (reg[0] == hw_cpuid))
- return cpu_node;
- }
- }
-
- return NULL;
-}
-
/* must hold reference to node during call */
static const int *of_get_associativity(struct device_node *dev)
{
@@ -469,7 +440,7 @@ static int of_drconf_to_nid_single(struc
static int __cpuinit numa_setup_cpu(unsigned long lcpu)
{
int nid = 0;
- struct device_node *cpu = find_cpu_node(lcpu);
+ struct device_node *cpu = of_get_cpu_node(lcpu, NULL);
if (!cpu) {
WARN_ON(1);
@@ -651,7 +622,7 @@ static int __init parse_numa_properties(
for_each_present_cpu(i) {
int nid;
- cpu = find_cpu_node(i);
+ cpu = of_get_cpu_node(i, NULL);
BUG_ON(!cpu);
nid = of_node_to_nid_single(cpu);
of_node_put(cpu);
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH 1/4] powerpc: move hose_list and pci_address_to_pio to pci-common
move the definition of hose_list next to its hotplug spinlock.
create pcibios_io_size to encapsulate ifdef in existing pci-common
function pcibios_vaddr_is_ioport
move pci_address_to_pio to pci-common, using new pcibios_io_size, and
protect this GPL exported function against concurrent hotplug removal
Signed-off-by: Milton Miller milt...@bga.com
---
I was looking at uses of hose_list when I ran across this almost common
function. I haven't looked where the exported function might be used.
Index: work.git/arch/powerpc/kernel/pci-common.c
===
--- work.git.orig/arch/powerpc/kernel/pci-common.c 2009-01-08
03:23:42.0 -0600
+++ work.git/arch/powerpc/kernel/pci-common.c 2009-01-08 03:24:36.0
-0600
@@ -40,6 +40,7 @@
#include asm/eeh.h
static DEFINE_SPINLOCK(hose_spinlock);
+LIST_HEAD(hose_list);
/* XXX kill that some day ... */
static int global_phb_number; /* Global phb counter */
@@ -115,19 +116,24 @@ void pcibios_free_controller(struct pci_
kfree(phb);
}
+static resource_size_t pcibios_io_size(const struct pci_controller *hose)
+{
+#ifdef CONFIG_PPC64
+ return hose-pci_io_size;
+#else
+ return hose-io_resource.end - hose-io_resource.start + 1;
+#endif
+}
+
int pcibios_vaddr_is_ioport(void __iomem *address)
{
int ret = 0;
struct pci_controller *hose;
- unsigned long size;
+ resource_size_t size;
spin_lock(hose_spinlock);
list_for_each_entry(hose, hose_list, list_node) {
-#ifdef CONFIG_PPC64
- size = hose-pci_io_size;
-#else
- size = hose-io_resource.end - hose-io_resource.start + 1;
-#endif
+ size = pcibios_io_size(hose);
if (address = hose-io_base_virt
address (hose-io_base_virt + size)) {
ret = 1;
@@ -138,6 +144,29 @@ int pcibios_vaddr_is_ioport(void __iomem
return ret;
}
+unsigned long pci_address_to_pio(phys_addr_t address)
+{
+ struct pci_controller *hose;
+ resource_size_t size;
+ unsigned long ret = ~0;
+
+ spin_lock(hose_spinlock);
+ list_for_each_entry(hose, hose_list, list_node) {
+ size = pcibios_io_size(hose);
+ if (address = hose-io_base_phys
+ address (hose-io_base_phys + size)) {
+ unsigned long base =
+ (unsigned long)hose-io_base_virt - _IO_BASE;
+ ret = base + (address - hose-io_base_phys);
+ break;
+ }
+ }
+ spin_unlock(hose_spinlock);
+
+ return ret;
+}
+EXPORT_SYMBOL_GPL(pci_address_to_pio);
+
/*
* Return the domain number for this bus.
*/
Index: work.git/arch/powerpc/kernel/pci_32.c
===
--- work.git.orig/arch/powerpc/kernel/pci_32.c 2009-01-08 03:23:42.0
-0600
+++ work.git/arch/powerpc/kernel/pci_32.c 2009-01-08 03:23:46.0
-0600
@@ -20,6 +20,7 @@
#include asm/prom.h
#include asm/sections.h
#include asm/pci-bridge.h
+#include asm/ppc-pci.h
#include asm/byteorder.h
#include asm/uaccess.h
#include asm/machdep.h
@@ -43,8 +44,6 @@ static u8* pci_to_OF_bus_map;
*/
static int pci_assign_all_buses;
-LIST_HEAD(hose_list);
-
static int pci_bus_count;
/* This will remain NULL for now, until isa-bridge.c is made common
@@ -491,24 +490,6 @@ long sys_pciconfig_iobase(long which, un
return result;
}
-unsigned long pci_address_to_pio(phys_addr_t address)
-{
- struct pci_controller *hose, *tmp;
-
- list_for_each_entry_safe(hose, tmp, hose_list, list_node) {
- unsigned int size = hose-io_resource.end -
- hose-io_resource.start + 1;
- if (address = hose-io_base_phys
- address (hose-io_base_phys + size)) {
- unsigned long base =
- (unsigned long)hose-io_base_virt - _IO_BASE;
- return base + (address - hose-io_base_phys);
- }
- }
- return (unsigned int)-1;
-}
-EXPORT_SYMBOL(pci_address_to_pio);
-
/*
* Null PCI config access functions, for the case when we can't
* find a hose.
Index: work.git/arch/powerpc/kernel/pci_64.c
===
--- work.git.orig/arch/powerpc/kernel/pci_64.c 2009-01-08 03:23:42.0
-0600
+++ work.git/arch/powerpc/kernel/pci_64.c 2009-01-08 03:23:46.0
-0600
@@ -43,8 +43,6 @@ unsigned long pci_probe_only = 1;
unsigned long pci_io_base = ISA_IO_BASE;
EXPORT_SYMBOL(pci_io_base);
-LIST_HEAD(hose_list);
-
static void fixup_broken_pcnet32(struct pci_dev* dev)
{
if ((dev-class8 == PCI_CLASS_NETWORK_ETHERNET)) {
@@ -524,23 +522,6 @@ int __devinit pcibios_map_io_space(struc
}
[PATCH 2/4] powerpc: remove write only variable
Since we never hotplug add an isa bus, we never need to set primary.
Delete this write-only variable.
Signed-off-by: Milton Miller milt...@bga.com
---
The reference to primary was removed in during a code move
92eb4602 (v2.6.16) when dlpar for p5ioc was tested.
Index: work.git/arch/powerpc/platforms/pseries/pci_dlpar.c
===
--- work.git.orig/arch/powerpc/platforms/pseries/pci_dlpar.c2009-01-05
04:38:15.0 -0600
+++ work.git/arch/powerpc/platforms/pseries/pci_dlpar.c 2009-01-05
04:38:48.0 -0600
@@ -137,11 +137,9 @@ EXPORT_SYMBOL_GPL(pcibios_add_pci_device
struct pci_controller * __devinit init_phb_dynamic(struct device_node *dn)
{
struct pci_controller *phb;
- int primary;
pr_debug(PCI: Initializing new hotplug PHB %s\n, dn-full_name);
- primary = list_empty(hose_list);
phb = pcibios_alloc_controller(dn);
if (!phb)
return NULL;
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH kexec-tools v2] ppc64: always check number of ranges when adding them
make the idom always call realloc_memory_ranges when filling a range entry
kexec was core dumping after using 5 exclude_range pairs when only 3
were allocated.
also delcare realloc_memory_ranges to take void.
Signed-off-by: Milton Miller milt...@bga.com
---
v2: compare variable j not i in a spot noticed by Michael Ellerman
Index: kexec-tools/kexec/arch/ppc64/kexec-ppc64.c
===
--- kexec-tools.orig/kexec/arch/ppc64/kexec-ppc64.c 2009-01-08
01:21:43.0 -0600
+++ kexec-tools/kexec/arch/ppc64/kexec-ppc64.c 2009-01-08 01:22:33.0
-0600
@@ -96,7 +96,7 @@ err1:
}
-static int realloc_memory_ranges()
+static int realloc_memory_ranges(void)
{
size_t memory_range_len;
@@ -469,6 +469,8 @@ static int get_devtree_details(unsigned
exclude_range[i].start = initrd_start;
exclude_range[i].end = initrd_end;
i++;
+ if (i = max_memory_ranges)
+ realloc_memory_ranges();
}
} /* chosen */
@@ -581,6 +583,8 @@ static int get_devtree_details(unsigned
exclude_range[i].start = tce_base;
exclude_range[i].end = tce_base + tce_size;
i++;
+ if (i = max_memory_ranges)
+ realloc_memory_ranges();
if (kexec_flags KEXEC_ON_CRASH)
add_usable_mem_rgns(tce_base, tce_size);
closedir(cdir);
@@ -634,6 +638,8 @@ int setup_memory_ranges(unsigned long ke
memory_range[j].end = exclude_range[i].start -
1;
memory_range[j].type = RANGE_RAM;
j++;
+ if (j = max_memory_ranges)
+ realloc_memory_ranges();
}
} /* i == 0 */
/* If the last exclude range does not end at memory_max, include
@@ -646,6 +652,8 @@ int setup_memory_ranges(unsigned long ke
memory_range[j].end = memory_max;
memory_range[j].type = RANGE_RAM;
j++;
+ if (j = max_memory_ranges)
+ realloc_memory_ranges();
/* Limit the end to rmo_top */
if (memory_range[j-1].start = rmo_top) {
j--;
@@ -666,6 +674,8 @@ int setup_memory_ranges(unsigned long ke
memory_range[j].end = exclude_range[i+1].start - 1;
memory_range[j].type = RANGE_RAM;
j++;
+ if (j = max_memory_ranges)
+ realloc_memory_ranges();
/* Limit range to rmo_top */
if (memory_range[j-1].start = rmo_top) {
j--;
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH] powerpc/e500mc: Minor tweaks to init/exception code for e500mc
* PID1/PID2 don't exist on e500mc so we should write them * Doorbell exceptions need to be taken w/EE still disabled since we use them for things like IPIs Signed-off-by: Kumar Gala ga...@kernel.crashing.org --- arch/powerpc/kernel/head_fsl_booke.S |6 +++--- 1 files changed, 3 insertions(+), 3 deletions(-) diff --git a/arch/powerpc/kernel/head_fsl_booke.S b/arch/powerpc/kernel/head_fsl_booke.S index 2f32720..6319973 100644 --- a/arch/powerpc/kernel/head_fsl_booke.S +++ b/arch/powerpc/kernel/head_fsl_booke.S @@ -103,7 +103,7 @@ invstr: mflrr6 /* Make it accessible */ or r7,r7,r4 mtspr SPRN_MAS6,r7 tlbsx 0,r6/* search MSR[IS], SPID=PID0 */ -#ifndef CONFIG_E200 +#if !defined(CONFIG_E200) !defined(CONFIG_PPC_E500MC) mfspr r7,SPRN_MAS1 andis. r7,r7,mas1_va...@h bne match_TLB @@ -216,7 +216,7 @@ skpinv: addir6,r6,1 /* Increment */ /* 4. Clear out PIDs Search info */ li r6,0 mtspr SPRN_PID0,r6 -#ifndef CONFIG_E200 +#if !defined(CONFIG_E200) !defined(CONFIG_PPC_E500MC) mtspr SPRN_PID1,r6 mtspr SPRN_PID2,r6 #endif @@ -707,7 +707,7 @@ interrupt_base: EXCEPTION(0x2060, PerformanceMonitor, performance_monitor_exception, EXC_XFER_STD) #ifdef CONFIG_PPC_E500MC - EXCEPTION(0x2070, Doorbell, unknown_exception, EXC_XFER_EE) + EXCEPTION(0x2070, Doorbell, unknown_exception, EXC_XFER_STD) #endif /* Debug Interrupt */ -- 1.5.6.5 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] powerpc/mpc52xx: Properly update irq_desc when set_type() is called.
Grant Likely wrote: On Wed, Jan 7, 2009 at 8:51 PM, Matt Sealey m...@genesi-usa.com wrote: Grant Likely wrote: From: Grant Likely grant.lik...@secretlab.ca The MPC5200 PIC driver doesn't correctly update the .status field of the irq_desc structure when the set_type hook is called. This patch adds the required code. Also cleans up the external IRQ typename field to be something easier to read (very minor). Signed-off-by: Grant Likely grant.lik...@secretlab.ca Hi Grant, What does this affect? cat /proc/interrupts Ah so, completely cosmetic in the end. I was worried I'd have to build a new kernel for a second.. :D -- Matt ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [Patch 0/3] Overview, OProfile SPU event profiling support for IBM Cell processor
On 01.12.08 16:18:26, Carl Love wrote: This is a rework of the previously posted set of patches. Patch 1 is the user level patch to add the SPU events to the user OProfile tool. Patch 2 is a kernel patch to do code clean up and restructuring to make it easier to add the new SPU event profiling support. This patch makes no functional changes. Patch 3 is a kernel patch to add the SPU event profiling support. I applied patch 2 3 to: git://git.kernel.org/pub/scm/linux/kernel/git/rric/oprofile.git cell The patches did not apply cleanly. I had to change the path to arch/powerpc/include/asm/, fix cell/pr_util.h and did some whitespace cleanups. Please run your tests on the cell branch. Thanks, -Robert -- Advanced Micro Devices, Inc. Operating System Research Center email: robert.rich...@amd.com ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 3/4] hvc_console: free_irq only if request_irq was successful
Am Donnerstag, 8. Januar 2009 schrieb Milton Miller:
Only call free_irq if we marked the request_irq has having succeeded
instead of whenever the the sub-driver identified the interrupt to use.
Signed-off-by: Milton Miller milt...@bga.com
---
Appears to be a bugfix but might use a bit of time in -next.
This code was created in 2.6.28 to allow s390 to build without adding
ifdefs.
Many hvc-console sub-drivers have a single channel and are not modules.
Index: work.git/drivers/char/hvc_irq.c
===
--- work.git.orig/drivers/char/hvc_irq.c 2009-01-08 04:07:28.0
-0600
+++ work.git/drivers/char/hvc_irq.c 2009-01-08 04:07:47.0 -0600
@@ -37,7 +37,7 @@ int notifier_add_irq(struct hvc_struct *
void notifier_del_irq(struct hvc_struct *hp, int irq)
{
- if (!irq)
+ if (!hp-irq_requested)
return;
free_irq(irq, hp);
hp-irq_requested = 0;
Looks sane.
Acked-by: Christian Borntraeger borntrae...@de.ibm.com
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] gianfar: Fixup use of BUS_ID_SIZE
From: Kumar Gala ga...@kernel.crashing.org Date: Wed, 7 Jan 2009 09:52:01 -0600 Commit b31a1d8b41513b96e9c7ec2f68c5734cef0b26a4 went back to using BUS_ID_SIZE instead of sizeof() as per the larger patch series that will remove char bus_id[20] from struct device. Signed-off-by: Kumar Gala ga...@kernel.crashing.org Applied, thanks Kumar. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 1/2] powerpc/fsl_pci: Add MPC83xx PCI-E controller RC mode support
On Thu, Jan 08, 2009 at 12:50:22AM -0600, Kumar Gala wrote:
+struct mpc83xx_pcie_priv {
+void __iomem *cfg_map;
+u32 dev_base;
+};
So was thinking about this and was wondering about doing the following:
hose-cfg_addr /* use instead of dev_base to cache pci bus/dev/fn */
hose-cfg_data /* should be the outbound window used for pci cfg cycles
*/
hose-dn-data /* for IMMR regs to tweak window */
thoughts?
I don't quite like the casts that we'll need to do this.
Doing this means we should be able to get rid of struct
mpc83xx_pcie_priv
Not sure what benefits this would bring? Saving few bytes of code and
data at the cost of losing clean, cast-less, self documented code?..
I was actually thinking of getting rid of hose-cfg_data usage, and
replacing it with mpc83xx_pci_priv-cfg_type0 (and rename
mpc83xx_pci_priv-cfg_map to cfg_type1).
OTOH, I can surely do that what you described, but to me it doesn't
look like a great idea (i.e. using irrelevant struct members for
hooking our data)...
--
Anton Vorontsov
email: cbouatmai...@gmail.com
irc://irc.freenode.net/bd2
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH RFC v5] net: add PCINet driver
From: Ira Snyder i...@ovro.caltech.edu Date: Wed, 7 Jan 2009 11:50:52 -0800 This adds support to Linux for a virtual ethernet interface which uses the PCI bus as its transport mechanism. It creates a simple, familiar, and fast method of communication for two devices connected by a PCI interface. Well, it looks like much more than that to me. What is this UART thing in here for? I can only assume it's meant to be used as a console port between the x86 host and the powerpc nodes. You haven't even mentioned this UART aspect even indirectly in the commit message. This just looks like yet another set of virtualization drivers to me. You could have just have easily built this using your own PCI backplane framework, and using the virtio stuff on top. And the virtio stuff has all kinds of snazzy optimizations that will likely improve your throughput, it has console drivers that distributions already probe for and attach appropriately, etc. In short I really don't like this conceptually, it can be done so much better using facilities we already have that are heavily optimized and userland understands already. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] ucc_geth: use correct UCCE macros
From: Timur Tabi ti...@freescale.com Date: Wed, 7 Jan 2009 14:17:04 -0600 On Wed, Jan 7, 2009 at 2:12 PM, Timur Tabi ti...@freescale.com wrote: This patch will break ucc_geth.c if my other patch, powerpc: add Ethernet UPSMR definitions to QE library isn't also applied. That patch is currently in Kumar's 'next' branch, so it will make 2.6.29-rc0. Therefore, it should be safe to apply this patch to 'net-next' today, with the understanding that everything will be peachy once Linus pulls everyone's 2.6.29 branches. David, as I mentioned here, Kumar already has the pre-req patch in his 'next' branch (for 2.6.29), so if you apply this patch to your 'next', ucc_geth.c will break until Linus pulls from Kumar and you pull from Linus. I think that's OK. I think I'll wait for Kumar's stuff to hit Linus's tree, then apply this patch. The patch is safely stored in my inbox and patchwork so there is no need to fear it getting lost :-) ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] ucc_geth: use correct UCCE macros
David Miller wrote: I think I'll wait for Kumar's stuff to hit Linus's tree, then apply this patch. The patch is safely stored in my inbox and patchwork so there is no need to fear it getting lost :-) That's good enough for me. Thanks! -- Timur Tabi Linux kernel developer at Freescale ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 1/2] powerpc/fsl_pci: Add MPC83xx PCI-E controller RC mode support
On Jan 8, 2009, at 1:10 PM, Anton Vorontsov wrote:
On Thu, Jan 08, 2009 at 12:50:22AM -0600, Kumar Gala wrote:
+struct mpc83xx_pcie_priv {
+ void __iomem *cfg_map;
+ u32 dev_base;
+};
So was thinking about this and was wondering about doing the
following:
hose-cfg_addr /* use instead of dev_base to cache pci bus/dev/fn */
hose-cfg_data /* should be the outbound window used for pci cfg
cycles
*/
hose-dn-data /* for IMMR regs to tweak window */
thoughts?
I don't quite like the casts that we'll need to do this.
Doing this means we should be able to get rid of struct
mpc83xx_pcie_priv
Not sure what benefits this would bring? Saving few bytes of code and
data at the cost of losing clean, cast-less, self documented code?..
I was actually thinking of getting rid of hose-cfg_data usage, and
replacing it with mpc83xx_pci_priv-cfg_type0 (and rename
mpc83xx_pci_priv-cfg_map to cfg_type1).
OTOH, I can surely do that what you described, but to me it doesn't
look like a great idea (i.e. using irrelevant struct members for
hooking our data)...
I'm ok if you get rid of cfg_data usage.. than we aren't overloading
the indirect variables for 83xx pci cfg cycles
- k
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH RFC v5] net: add PCINet driver
On Thu, Jan 08, 2009 at 11:16:10AM -0800, David Miller wrote: From: Ira Snyder i...@ovro.caltech.edu Date: Wed, 7 Jan 2009 11:50:52 -0800 This adds support to Linux for a virtual ethernet interface which uses the PCI bus as its transport mechanism. It creates a simple, familiar, and fast method of communication for two devices connected by a PCI interface. Well, it looks like much more than that to me. What is this UART thing in here for? I can only assume it's meant to be used as a console port between the x86 host and the powerpc nodes. Exactly right. I needed it to tell the U-Boot bootloader to tftp the kernel and boot the board. These boards don't keep their PCI settings (assigned by the BIOS at boot) over a soft or hard reset. I couldn't think of a better way to get them started. You haven't even mentioned this UART aspect even indirectly in the commit message. Sorry, I'll add something about it. This just looks like yet another set of virtualization drivers to me. You could have just have easily built this using your own PCI backplane framework, and using the virtio stuff on top. And the virtio stuff has all kinds of snazzy optimizations that will likely improve your throughput, it has console drivers that distributions already probe for and attach appropriately, etc. In short I really don't like this conceptually, it can be done so much better using facilities we already have that are heavily optimized and userland understands already. I've had a really hard time understanding the virtio code. I haven't been able to find much in the way of documentation for it. Can you point me to some code that does anything vaguely similar to what you are suggesting? Arnd Bergmann said that there is a similar driver (for different hardware) that uses virtio, but it is very slow, because it doesn't use the DMA controller to transfer data. I need at very minimum 40MB/sec of client - host data transfer. Thanks for the comments, Ira -- To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: 2.6.28-rc9 panics with crashkernel=256M while booting
On Thu, 2009-01-08 at 15:59 +0530, Chandru wrote:
@@ -898,9 +899,17 @@ static void mark_reserved_regions_for_ni
* if reserved region extends past active region
* then trim size to active region
*/
- if (end_pfn node_ar.end_pfn)
+ if (end_pfn node_ar.end_pfn) {
reserve_size = (node_ar.end_pfn PAGE_SHIFT)
- (start_pfn PAGE_SHIFT);
+ /*
+* resize it further if the reservation could
+* cross the last page in this node
+*/
+ if (PFN_UP(physbase+reserve_size)
+node_end_pfn)
+ reserve_size -= PAGE_SIZE;
+ }
/*
Now I'm even more confused. Could you please send a fully changelogged
patch that describes the problem, and how this fixes it? This just
seems like an off-by-one error, which isn't what I thought we had before
at all.
I'm also horribly confused why PFN_UP is needed here. Is 'physbase' not
page aligned? reserve_size looks like it *has* to be. 'end_pfn' is
always (as far as I have ever seen in the kernel) the pfn of the page
after the area we are interested in and we treat it as such in that
function. In the case of an unaligned physbase, that wouldn't be true.
Think of the case where we have a 1-byte reservation. start_pfn will
equal end_pfn and we won't go into that while loop at *all* and won't
reserve anything.
Does 'end_pfn' need fixing?
-- Dave
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [BUG] hvc_console WARN() on current upstream
On Thu, 2009-01-08 at 11:11 +, Alan Cox wrote: Seems that we are in interrupt, doing hvc_poll, which does tty_flip_buffer_push Which means that someone has tty-low_latency set and is calling tty_flip_buffer_push in an IRQ. That has never been allowed or safe, and now it hurts ;) Heh, allright :-) I'll see where that flag is set and clear it when using IRQs. That comment has been there for some years in varying formats Possibly, I didn't write that code, thanks for pointing me to the problem. Cheers, Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 1/2] powerpc/fsl_pci: Add MPC83xx PCI-E controller RC modesupport
On Thu, Jan 08, 2009 at 03:27:10PM +0800, Liu Dave wrote: +static void __iomem *mpc83xx_pcie_remap_cfg(struct pci_bus *bus, + unsigned int devfn, [snip] + if (pcie-dev_base == dev_base) + goto mapped; + + out_le32(hose-cfg_data + PEX_OUTWIN0_TAL, dev_base); + + pcie-dev_base = dev_base; Do we need local_irq_save/local_irq_restore between them? No, I don't think we need it. drivers/pci/access.c hold an irqsave spinlock for -read and -write callbacks. out_le32(PEX_OUTWIN0_TAL,...) and pcie-dev_base = dev_base; +mapped: + return pcie-cfg_map + offset; +} Thanks, -- Anton Vorontsov email: cbouatmai...@gmail.com irc://irc.freenode.net/bd2 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH RFC v5] net: add PCINet driver
On Thu, Jan 08, 2009 at 11:27:16AM -0800, Ira Snyder wrote: On Thu, Jan 08, 2009 at 11:16:10AM -0800, David Miller wrote: From: Ira Snyder i...@ovro.caltech.edu Date: Wed, 7 Jan 2009 11:50:52 -0800 This adds support to Linux for a virtual ethernet interface which uses the PCI bus as its transport mechanism. It creates a simple, familiar, and fast method of communication for two devices connected by a PCI interface. Well, it looks like much more than that to me. What is this UART thing in here for? I can only assume it's meant to be used as a console port between the x86 host and the powerpc nodes. Exactly right. I needed it to tell the U-Boot bootloader to tftp the kernel and boot the board. These boards don't keep their PCI settings (assigned by the BIOS at boot) over a soft or hard reset. I couldn't think of a better way to get them started. You haven't even mentioned this UART aspect even indirectly in the commit message. Sorry, I'll add something about it. This just looks like yet another set of virtualization drivers to me. You could have just have easily built this using your own PCI backplane framework, and using the virtio stuff on top. And the virtio stuff has all kinds of snazzy optimizations that will likely improve your throughput, it has console drivers that distributions already probe for and attach appropriately, etc. In short I really don't like this conceptually, it can be done so much better using facilities we already have that are heavily optimized and userland understands already. I've had a really hard time understanding the virtio code. I haven't been able to find much in the way of documentation for it. Can you point me to some code that does anything vaguely similar to what you are suggesting? Arnd Bergmann said that there is a similar driver (for different hardware) that uses virtio, but it is very slow, because it doesn't use the DMA controller to transfer data. I need at very minimum 40MB/sec of client - host data transfer. Rusty, since you wrote the virtio code, can you point me at the things I would need to implement to use virtio over the PCI bus. The guests (PowerPC computers running Linux) are PCI cards in the host system (an Intel Pentium3-M system). The guest computers can access all of the host's memory. The guests provide a 1MB (movable) window into their memory. The PowerPC computers also have a DMA controller, which I've used to get better throughput from my driver. I have a way to create interrupts to both the host and guest systems. I've read your paper titled: virtio: Towards a De-Facto Standard For Virtual I/O Devices If I read that correctly, then I should implement all of the functions in struct virtqueue_ops appropriately, and the existing virtio drivers should just work. The only concern I have there is how to make guest - host transfer use the DMA controller. I've done all programming of it from the guest kernel, using the Linux DMAEngine API. Are there any other implementations other than virtio_ring? I appreciate any input you can give. If I should be CCing someone else, just let me know and I'll drop you from the CC list. Thanks, Ira ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH v6 1/2] powerpc/fsl_pci: Add MPC83xx PCI-E controller RC mode support
This patch adds support for PCI-Express controllers as found on the
newer MPC83xx chips.
The work is loosely based on the Tony Li's patch[1], but unlike the
original patch, this patch implements sliding window for the Type 1
transactions using outbound window translations, so we don't have to
ioremap the whole PCI-E configuration space.
[1] http://ozlabs.org/pipermail/linuxppc-dev/2008-January/049028.html
Signed-off-by: Tony Li tony...@freescale.com
Signed-off-by: Anton Vorontsov avoront...@ru.mvista.com
---
On Thu, Jan 08, 2009 at 01:24:27PM -0600, Kumar Gala wrote:
[...]
I'm ok if you get rid of cfg_data usage.. than we aren't overloading the
indirect variables for 83xx pci cfg cycles
Here it is.
Thanks,
arch/powerpc/sysdev/fsl_pci.c | 244 +
include/linux/pci_ids.h |8 ++
2 files changed, 228 insertions(+), 24 deletions(-)
diff --git a/arch/powerpc/sysdev/fsl_pci.c b/arch/powerpc/sysdev/fsl_pci.c
index 9817f63..78021d8 100644
--- a/arch/powerpc/sysdev/fsl_pci.c
+++ b/arch/powerpc/sysdev/fsl_pci.c
@@ -1,12 +1,16 @@
/*
* MPC83xx/85xx/86xx PCI/PCIE support routing.
*
- * Copyright 2007,2008 Freescale Semiconductor, Inc
+ * Copyright 2007-2009 Freescale Semiconductor, Inc.
+ * Copyright 2008-2009 MontaVista Software, Inc.
*
* Initial author: Xianghua Xiao x.x...@freescale.com
* Recode: ZHANG WEI wei.zh...@freescale.com
* Rewrite the routing for Frescale PCI and PCI Express
* Roy Zang tie-fei.z...@freescale.com
+ * MPC83xx PCI-Express support:
+ * Tony Li tony...@freescale.com
+ * Anton Vorontsov avoront...@ru.mvista.com
*
* 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
@@ -27,6 +31,29 @@
#include sysdev/fsl_soc.h
#include sysdev/fsl_pci.h
+static int fsl_pcie_bus_fixup;
+
+static void __init quirk_fsl_pcie_header(struct pci_dev *dev)
+{
+ /* if we aren't a PCIe don't bother */
+ if (!pci_find_capability(dev, PCI_CAP_ID_EXP))
+ return;
+
+ dev-class = PCI_CLASS_BRIDGE_PCI 8;
+ fsl_pcie_bus_fixup = 1;
+ return;
+}
+
+static int __init fsl_pcie_check_link(struct pci_controller *hose)
+{
+ u32 val;
+
+ early_read_config_dword(hose, 0, 0, PCIE_LTSSM, val);
+ if (val PCIE_LTSSM_L0)
+ return 1;
+ return 0;
+}
+
#if defined(CONFIG_PPC_85xx) || defined(CONFIG_PPC_86xx)
static int __init setup_one_atmu(struct ccsr_pci __iomem *pci,
unsigned int index, const struct resource *res,
@@ -159,28 +186,6 @@ static void __init setup_pci_pcsrbar(struct pci_controller
*hose)
#endif
}
-static int fsl_pcie_bus_fixup;
-
-static void __init quirk_fsl_pcie_header(struct pci_dev *dev)
-{
- /* if we aren't a PCIe don't bother */
- if (!pci_find_capability(dev, PCI_CAP_ID_EXP))
- return ;
-
- dev-class = PCI_CLASS_BRIDGE_PCI 8;
- fsl_pcie_bus_fixup = 1;
- return ;
-}
-
-static int __init fsl_pcie_check_link(struct pci_controller *hose)
-{
- u32 val;
- early_read_config_dword(hose, 0, 0, PCIE_LTSSM, val);
- if (val PCIE_LTSSM_L0)
- return 1;
- return 0;
-}
-
void fsl_pcibios_fixup_bus(struct pci_bus *bus)
{
struct pci_controller *hose = (struct pci_controller *) bus-sysdata;
@@ -294,8 +299,184 @@ DECLARE_PCI_FIXUP_HEADER(0x1957, PCI_DEVICE_ID_MPC8610,
quirk_fsl_pcie_header);
#endif /* CONFIG_PPC_85xx || CONFIG_PPC_86xx */
#if defined(CONFIG_PPC_83xx) || defined(CONFIG_PPC_MPC512x)
+DECLARE_PCI_FIXUP_HEADER(0x1957, PCI_DEVICE_ID_MPC8314E,
quirk_fsl_pcie_header);
+DECLARE_PCI_FIXUP_HEADER(0x1957, PCI_DEVICE_ID_MPC8314, quirk_fsl_pcie_header);
+DECLARE_PCI_FIXUP_HEADER(0x1957, PCI_DEVICE_ID_MPC8315E,
quirk_fsl_pcie_header);
+DECLARE_PCI_FIXUP_HEADER(0x1957, PCI_DEVICE_ID_MPC8315, quirk_fsl_pcie_header);
+DECLARE_PCI_FIXUP_HEADER(0x1957, PCI_DEVICE_ID_MPC8377E,
quirk_fsl_pcie_header);
+DECLARE_PCI_FIXUP_HEADER(0x1957, PCI_DEVICE_ID_MPC8377, quirk_fsl_pcie_header);
+DECLARE_PCI_FIXUP_HEADER(0x1957, PCI_DEVICE_ID_MPC8378E,
quirk_fsl_pcie_header);
+DECLARE_PCI_FIXUP_HEADER(0x1957, PCI_DEVICE_ID_MPC8378, quirk_fsl_pcie_header);
+
+struct mpc83xx_pcie_priv {
+ void __iomem *cfg_type0;
+ void __iomem *cfg_type1;
+ u32 dev_base;
+};
+
+/*
+ * With the convention of u-boot, the PCIE outbound window 0 serves
+ * as configuration transactions outbound.
+ */
+#define PEX_OUTWIN0_BAR0xCA4
+#define PEX_OUTWIN0_TAL0xCA8
+#define PEX_OUTWIN0_TAH0xCAC
+
+static int mpc83xx_pcie_exclude_device(struct pci_bus *bus, unsigned int devfn)
+{
+ struct pci_controller *hose = bus-sysdata;
+
+ if (hose-indirect_type PPC_INDIRECT_TYPE_NO_PCIE_LINK)
+ return PCIBIOS_DEVICE_NOT_FOUND;
+ /*
+* Workaround for the HW bug: for Type 0 configure transactions the
+*
[PATCH 1/2] powerpc/fsl-booke: Cleanup init/exception setup to be runtime
We currently have a few variants of fsl-booke processors (e500v1, e500v2,
e500mc, and e200). They all have minor differences that we had previously
been handling via ifdefs.
To move towards having this support the following changes have been made:
* PID1, PID2 only exist on e500v1 e500v2 and should not be accessed on
e500mc or e200. We use MMUCFG[NPIDS] to determine which case we are
since we only touch PID1/2 in extremely early init code.
* Not all IVORs exist on all the processors so introduce cpu_setup
functions for each variant to setup the proper IVORs that are either
unique or exist but have some variations between the processors
Signed-off-by: Kumar Gala ga...@kernel.crashing.org
---
arch/powerpc/include/asm/reg_booke.h |1 +
arch/powerpc/kernel/Makefile |1 +
arch/powerpc/kernel/cpu_setup_fsl_booke.S | 31 +++
arch/powerpc/kernel/cputable.c|8 +++
arch/powerpc/kernel/head_booke.h |6 +-
arch/powerpc/kernel/head_fsl_booke.S | 83 +++--
6 files changed, 99 insertions(+), 31 deletions(-)
create mode 100644 arch/powerpc/kernel/cpu_setup_fsl_booke.S
diff --git a/arch/powerpc/include/asm/reg_booke.h
b/arch/powerpc/include/asm/reg_booke.h
index 6745376..597debe 100644
--- a/arch/powerpc/include/asm/reg_booke.h
+++ b/arch/powerpc/include/asm/reg_booke.h
@@ -110,6 +110,7 @@
#define SPRN_L1CSR00x3F2 /* L1 Cache Control and Status Register 0 */
#define SPRN_L1CSR10x3F3 /* L1 Cache Control and Status Register 1 */
#define SPRN_MMUCSR0 0x3F4 /* MMU Control and Status Register 0 */
+#define SPRN_MMUCFG0x3F7 /* MMU Configuration Register */
#define SPRN_PIT 0x3DB /* Programmable Interval Timer */
#define SPRN_BUCSR 0x3F5 /* Branch Unit Control and Status */
#define SPRN_L2CSR00x3F9 /* L2 Data Cache Control and Status Register 0
*/
diff --git a/arch/powerpc/kernel/Makefile b/arch/powerpc/kernel/Makefile
index 8d1a419..d159921 100644
--- a/arch/powerpc/kernel/Makefile
+++ b/arch/powerpc/kernel/Makefile
@@ -61,6 +61,7 @@ obj-$(CONFIG_HIBERNATION) += swsusp.o suspend.o \
obj64-$(CONFIG_HIBERNATION)+= swsusp_asm64.o
obj-$(CONFIG_MODULES) += module.o module_$(CONFIG_WORD_SIZE).o
obj-$(CONFIG_44x) += cpu_setup_44x.o
+obj-$(CONFIG_FSL_BOOKE)+= cpu_setup_fsl_booke.o
extra-$(CONFIG_PPC_STD_MMU):= head_32.o
extra-$(CONFIG_PPC64) := head_64.o
diff --git a/arch/powerpc/kernel/cpu_setup_fsl_booke.S
b/arch/powerpc/kernel/cpu_setup_fsl_booke.S
new file mode 100644
index 000..eb4b9ad
--- /dev/null
+++ b/arch/powerpc/kernel/cpu_setup_fsl_booke.S
@@ -0,0 +1,31 @@
+/*
+ * This file contains low level CPU setup functions.
+ * Kumar Gala ga...@kernel.crashing.org
+ * Copyright 2009 Freescale Semiconductor, Inc.
+ *
+ * Based on cpu_setup_6xx code by
+ * Benjamin Herrenschmidt b...@kernel.crashing.org
+ *
+ * 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 asm/processor.h
+#include asm/cputable.h
+#include asm/ppc_asm.h
+
+_GLOBAL(__setup_cpu_e200)
+ /* enable dedicated debug exception handling resources (Debug APU) */
+ mfspr r3,SPRN_HID0
+ ori r3,r3,hid0_dap...@l
+ mtspr SPRN_HID0,r3
+ b __setup_e200_ivors
+_GLOBAL(__setup_cpu_e500v1)
+_GLOBAL(__setup_cpu_e500v2)
+ b __setup_e500_ivors
+_GLOBAL(__setup_cpu_e500mc)
+ b __setup_e500mc_ivors
+
diff --git a/arch/powerpc/kernel/cputable.c b/arch/powerpc/kernel/cputable.c
index 923f87a..9fdf1b8 100644
--- a/arch/powerpc/kernel/cputable.c
+++ b/arch/powerpc/kernel/cputable.c
@@ -35,6 +35,10 @@ const char *powerpc_base_platform;
* and ppc64
*/
#ifdef CONFIG_PPC32
+extern void __setup_cpu_e200(unsigned long offset, struct cpu_spec* spec);
+extern void __setup_cpu_e500v1(unsigned long offset, struct cpu_spec* spec);
+extern void __setup_cpu_e500v2(unsigned long offset, struct cpu_spec* spec);
+extern void __setup_cpu_e500mc(unsigned long offset, struct cpu_spec* spec);
extern void __setup_cpu_440ep(unsigned long offset, struct cpu_spec* spec);
extern void __setup_cpu_440epx(unsigned long offset, struct cpu_spec* spec);
extern void __setup_cpu_440gx(unsigned long offset, struct cpu_spec* spec);
@@ -1687,6 +1691,7 @@ static struct cpu_spec __initdata cpu_specs[] = {
PPC_FEATURE_UNIFIED_CACHE,
.mmu_features = MMU_FTR_TYPE_FSL_E,
.dcache_bsize = 32,
+ .cpu_setup = __setup_cpu_e200,
.machine_check = machine_check_e200,
.platform = ppc5554,
}
@@ -1706,6 +1711,7 @@ static struct cpu_spec __initdata cpu_specs[]
[PATCH 2/2] powerpc/e500mc: Doorbells need to be taken w/exceptions disabled
We use Doorbell interrupts for IPIs and thus we need to make sure we aren't interrupted in the process of processing the IPI. Signed-off-by: Kumar Gala ga...@kernel.crashing.org --- arch/powerpc/kernel/head_fsl_booke.S |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/arch/powerpc/kernel/head_fsl_booke.S b/arch/powerpc/kernel/head_fsl_booke.S index 6062669..475c937 100644 --- a/arch/powerpc/kernel/head_fsl_booke.S +++ b/arch/powerpc/kernel/head_fsl_booke.S @@ -698,7 +698,7 @@ interrupt_base: /* Performance Monitor */ EXCEPTION(0x2060, PerformanceMonitor, performance_monitor_exception, EXC_XFER_STD) - EXCEPTION(0x2070, Doorbell, unknown_exception, EXC_XFER_EE) + EXCEPTION(0x2070, Doorbell, unknown_exception, EXC_XFER_STD) /* Debug Interrupt */ DEBUG_DEBUG_EXCEPTION -- 1.5.6.5 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] powerpc/e500mc: Minor tweaks to init/exception code for e500mc
On Jan 8, 2009, at 8:33 AM, Kumar Gala wrote: * PID1/PID2 don't exist on e500mc so we should write them * Doorbell exceptions need to be taken w/EE still disabled since we use them for things like IPIs Signed-off-by: Kumar Gala ga...@kernel.crashing.org --- arch/powerpc/kernel/head_fsl_booke.S |6 +++--- 1 files changed, 3 insertions(+), 3 deletions(-) superseded by larger cleanup. - k ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH v6 1/2] powerpc/fsl_pci: Add MPC83xx PCI-E controller RC mode support
On Jan 8, 2009, at 3:55 PM, Anton Vorontsov wrote: This patch adds support for PCI-Express controllers as found on the newer MPC83xx chips. The work is loosely based on the Tony Li's patch[1], but unlike the original patch, this patch implements sliding window for the Type 1 transactions using outbound window translations, so we don't have to ioremap the whole PCI-E configuration space. [1] http://ozlabs.org/pipermail/linuxppc-dev/2008-January/049028.html Signed-off-by: Tony Li tony...@freescale.com Signed-off-by: Anton Vorontsov avoront...@ru.mvista.com --- On Thu, Jan 08, 2009 at 01:24:27PM -0600, Kumar Gala wrote: [...] I'm ok if you get rid of cfg_data usage.. than we aren't overloading the indirect variables for 83xx pci cfg cycles Here it is. Thanks, arch/powerpc/sysdev/fsl_pci.c | 244 + include/linux/pci_ids.h |8 ++ 2 files changed, 228 insertions(+), 24 deletions(-) applied - k ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 2/2] powerpc/83xx: Add PCI-E support for all MPC83xx boards with PCI-E
On Jan 7, 2009, at 7:31 PM, Anton Vorontsov wrote: This patch adds pcie nodes to the appropriate dts files, plus adds some probing code for the boards. Also, remove of_device_is_avaliable() check from the mpc837x_mds.c board file, as mpc83xx_add_bridge() has the same check now. Signed-off-by: Anton Vorontsov avoront...@ru.mvista.com --- arch/powerpc/boot/dts/mpc8315erdb.dts | 64 + arch/powerpc/boot/dts/mpc8377_mds.dts | 64 + arch/powerpc/boot/dts/mpc8377_rdb.dts | 64 + arch/powerpc/boot/dts/mpc8378_mds.dts | 64 + arch/powerpc/boot/dts/mpc8378_rdb.dts | 64 + arch/powerpc/platforms/83xx/mpc831x_rdb.c |2 + arch/powerpc/platforms/83xx/mpc837x_mds.c | 10 +--- arch/powerpc/platforms/83xx/mpc837x_rdb.c |2 + 8 files changed, 327 insertions(+), 7 deletions(-) applied - k ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [Patch 0/3] Overview, OProfile SPU event profiling support for IBM Cell processor
On Thu, 2009-01-08 at 16:48 +0100, Robert Richter wrote: On 01.12.08 16:18:26, Carl Love wrote: This is a rework of the previously posted set of patches. Patch 1 is the user level patch to add the SPU events to the user OProfile tool. Patch 2 is a kernel patch to do code clean up and restructuring to make it easier to add the new SPU event profiling support. This patch makes no functional changes. Patch 3 is a kernel patch to add the SPU event profiling support. I applied patch 2 3 to: git://git.kernel.org/pub/scm/linux/kernel/git/rric/oprofile.git cell The patches did not apply cleanly. I had to change the path to arch/powerpc/include/asm/, fix cell/pr_util.h and did some whitespace cleanups. Please run your tests on the cell branch. Thanks, -Robert I pulled down the git tree, compiled and installed it. I tested it against the OProfile testsuite, which includes SPU event profiling tests. Everything passed. The patch I submitted was against a 2.6.26 tree. You are now on a 2.6.28 tree so perhaps that is why the patch did not apply cleanly. The patch has been out there for some time. Carl Love ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
linux-next: manual merge of the rr tree
Hi Rusty, Today's linux-next merge of the rr tree got a conflict in arch/powerpc/kernel/sysfs.c between commit 93197a36a9c16a85fb24cf5a8639f7bf9af838a3 (powerpc: Rewrite sysfs processor cache info code) from Linus' tree and commit 013ab448cec493262080ecc47b13e0adbcfaeccd (cpualloc:rename-per_cpu-vars) from the rr tree. The former moved the code modified by the latter into another file and rewrote it. This is part of the code churn that should not be happening in linux-next during the merge window. :-( I have dropped the rr tree for today, sorry. -- Cheers, Stephen Rothwells...@canb.auug.org.au http://www.canb.auug.org.au/~sfr/ pgpRgCW9iUEes.pgp Description: PGP signature ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
RE: [PATCH 2/2] powerpc/e500mc: Doorbells need to be taken w/exceptionsdisabled
Acked-by: Dave Liu dave...@freescale.com -Original Message- From: linuxppc-dev-bounces+daveliu=freescale@ozlabs.org [mailto:linuxppc-dev-bounces+daveliu=freescale@ozlabs.org] On Behalf Of Kumar Gala Sent: 2009?1?9? 8:15 AM To: linuxppc-dev@ozlabs.org Subject: [PATCH 2/2] powerpc/e500mc: Doorbells need to be taken w/exceptionsdisabled We use Doorbell interrupts for IPIs and thus we need to make sure we aren't interrupted in the process of processing the IPI. Signed-off-by: Kumar Gala ga...@kernel.crashing.org --- arch/powerpc/kernel/head_fsl_booke.S |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/arch/powerpc/kernel/head_fsl_booke.S b/arch/powerpc/kernel/head_fsl_booke.S index 6062669..475c937 100644 --- a/arch/powerpc/kernel/head_fsl_booke.S +++ b/arch/powerpc/kernel/head_fsl_booke.S @@ -698,7 +698,7 @@ interrupt_base: /* Performance Monitor */ EXCEPTION(0x2060, PerformanceMonitor, performance_monitor_exception, EXC_XFER_STD) - EXCEPTION(0x2070, Doorbell, unknown_exception, EXC_XFER_EE) + EXCEPTION(0x2070, Doorbell, unknown_exception, EXC_XFER_STD) /* Debug Interrupt */ DEBUG_DEBUG_EXCEPTION -- 1.5.6.5 ___ 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
