Re: x86/non-x86: percpu, node ids, apic ids x86.git fixup
* Luck, Tony <[EMAIL PROTECTED]> wrote:
> > I'll start digging on why this doesn't boot ... but you might as well
> > send the fixes so far upstream to Linus so that the SMP fix is available
>
> Well a pure 2.6.24 version compiled with CONFIG_SMP=n booted just
> fine, so the breakage is recent ... and more than likely related to
> this change.
>
> I've only had a casual dig at the failing case ... kernel dies in
> memset() as called from kmem_cache_alloc() with the address being
> written as 0x40117b48 (which is off in the virtual address
> space range used by users ... not a kernel address).
hm, as far as i could check, on ia64 UP the .percpu section link
difference was the only ia64 difference i could find out of those
changes. Could you try to copy a 2.6.24 include/asm-generic/percpu.h,
include/asm-ia64.h and include/linux/percpu.h into your current tree,
and see whether that boots? If yes, then it's the percpu changes. The
patch below does this ontop of very latest -git - and it builds fine
with your UP config with a crosscompiler.
> I'll dig some more tomorrow.
thanks.
Ingo
---
include/asm-generic/percpu.h | 99 ---
include/asm-ia64/percpu.h| 57 +++-
include/linux/percpu.h | 20
3 files changed, 82 insertions(+), 94 deletions(-)
Index: linux-x86.q/include/asm-generic/percpu.h
===
--- linux-x86.q.orig/include/asm-generic/percpu.h
+++ linux-x86.q/include/asm-generic/percpu.h
@@ -3,79 +3,54 @@
#include
#include
-/*
- * Determine the real variable name from the name visible in the
- * kernel sources.
- */
-#define per_cpu_var(var) per_cpu__##var
-
+#define __GENERIC_PER_CPU
#ifdef CONFIG_SMP
-/*
- * per_cpu_offset() is the offset that has to be added to a
- * percpu variable to get to the instance for a certain processor.
- *
- * Most arches use the __per_cpu_offset array for those offsets but
- * some arches have their own ways of determining the offset (x86_64, s390).
- */
-#ifndef __per_cpu_offset
extern unsigned long __per_cpu_offset[NR_CPUS];
#define per_cpu_offset(x) (__per_cpu_offset[x])
-#endif
-
-/*
- * Determine the offset for the currently active processor.
- * An arch may define __my_cpu_offset to provide a more effective
- * means of obtaining the offset to the per cpu variables of the
- * current processor.
- */
-#ifndef __my_cpu_offset
-#define __my_cpu_offset per_cpu_offset(raw_smp_processor_id())
-#define my_cpu_offset per_cpu_offset(smp_processor_id())
-#else
-#define my_cpu_offset __my_cpu_offset
-#endif
-
-/*
- * Add a offset to a pointer but keep the pointer as is.
- *
- * Only S390 provides its own means of moving the pointer.
- */
-#ifndef SHIFT_PERCPU_PTR
-#define SHIFT_PERCPU_PTR(__p, __offset)RELOC_HIDE((__p), (__offset))
-#endif
-
-/*
- * A percpu variable may point to a discarded regions. The following are
- * established ways to produce a usable pointer from the percpu variable
- * offset.
- */
-#define per_cpu(var, cpu) \
- (*SHIFT_PERCPU_PTR(&per_cpu_var(var), per_cpu_offset(cpu)))
-#define __get_cpu_var(var) \
- (*SHIFT_PERCPU_PTR(&per_cpu_var(var), my_cpu_offset))
-#define __raw_get_cpu_var(var) \
- (*SHIFT_PERCPU_PTR(&per_cpu_var(var), __my_cpu_offset))
-
-
-#ifdef CONFIG_HAVE_SETUP_PER_CPU_AREA
-extern void setup_per_cpu_areas(void);
-#endif
+/* Separate out the type, so (int[3], foo) works. */
+#define DEFINE_PER_CPU(type, name) \
+__attribute__((__section__(".data.percpu"))) __typeof__(type)
per_cpu__##name
+
+#define DEFINE_PER_CPU_SHARED_ALIGNED(type, name) \
+__attribute__((__section__(".data.percpu.shared_aligned"))) \
+__typeof__(type) per_cpu__##name \
+cacheline_aligned_in_smp
+
+/* var is in discarded region: offset to particular copy we want */
+#define per_cpu(var, cpu) (*({ \
+ extern int simple_identifier_##var(void); \
+ RELOC_HIDE(&per_cpu__##var, __per_cpu_offset[cpu]); }))
+#define __get_cpu_var(var) per_cpu(var, smp_processor_id())
+#define __raw_get_cpu_var(var) per_cpu(var, raw_smp_processor_id())
+
+/* A macro to avoid #include hell... */
+#define percpu_modcopy(pcpudst, src, size) \
+do { \
+ unsigned int __i; \
+ for_each_possible_cpu(__i) \
+ memcpy((pcpudst)+__per_cpu_offset[__i], \
+ (src), (size)); \
+} while (0)
#else /* ! SMP */
-#define per_cpu(var, cpu) (*((void)(cpu),
&per_cpu_var(var)))
-#define __get_cpu_var(var) per_cpu_var(var)
-#define __raw_get_cpu_var(var) per_cpu_var(var)
+#define DEFINE_PER_CPU(type, name) \
+__typeof__(
Re: [RFC] [POWERPC] bootwrapper: build multiple cuImages
Hi Grant, > Currently, the kernel uses CONFIG_DEVICE_TREE to wrap a kernel image > with a fdt blob which means for any given configuration only one dts > file can be selected and so support for only one board can be built > > This patch moves the selection of the default .dts file out of the kernel > config and into the bootwrapper makefile. The makefile chooses which > images to build based on the kernel config and the dts source file > name is taken directly from the image name. For example "cuImage.ebony" > will use "ebony.dts" as the device tree source file. Cool stuff. This should be the last step to enable multiplatform builds on 8xx etc. as Arndt asked a few days ago ;) Thanks, Jochen ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: x86/non-x86: percpu, node ids, apic ids x86.git fixup
On Wed, Jan 30, 2008 at 11:33:29AM -0800, Luck, Tony wrote: > > I'm having trouble replicating this error. With the latest linux-2.6.git > > plus the patch I just sent, I get the following errors: > > > > drivers/input/mouse/psmouse-base.c:45: error: __param_proto causes a > > section type conflict > > drivers/md/md.c:5881: error: __param_start_ro causes a section type conflict > > Weird. psmouse-base.c builds ok for me. Perhaps there is a compiler > version difference? I'm running a rather old 3.4.6 that came with > my RHEL 4.5 release. >... It depends on the compiler version. And you were in the Cc of Ivan's patch that fixes it... [1] > -Tony cu Adrian [1] http://lkml.org/lkml/2007/12/27/29 -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH/RFC] [POWERPC] Add i2c pins to dts and board setup
Add CPM i2c support for mpc8272, mpc866 and mpc885 boards.
Signed-off-by: Jochen Friedrich <[EMAIL PROTECTED]>
---
arch/powerpc/boot/dts/mpc8272ads.dts | 10 ++
arch/powerpc/boot/dts/mpc866ads.dts | 10 ++
arch/powerpc/boot/dts/mpc885ads.dts | 10 ++
arch/powerpc/platforms/82xx/mpc8272_ads.c|5 +
arch/powerpc/platforms/8xx/mpc86xads_setup.c |4
arch/powerpc/platforms/8xx/mpc885ads_setup.c |3 +++
6 files changed, 42 insertions(+), 0 deletions(-)
diff --git a/arch/powerpc/boot/dts/mpc8272ads.dts
b/arch/powerpc/boot/dts/mpc8272ads.dts
index 7285ca1..7273996 100644
--- a/arch/powerpc/boot/dts/mpc8272ads.dts
+++ b/arch/powerpc/boot/dts/mpc8272ads.dts
@@ -215,6 +215,16 @@
linux,network-index = <1>;
fsl,cpm-command = <16200300>;
};
+
+ [EMAIL PROTECTED] {
+ compatible = "fsl,mpc8248-i2c",
+"fsl,cpm2-i2c",
+"fsl,cpm-i2c";
+ reg = <11860 20 8afc 2>;
+ interrupts = <1 8>;
+ interrupt-parent = <&PIC>;
+ fsl,cpm-command = <2960>;
+ };
};
PIC: [EMAIL PROTECTED] {
diff --git a/arch/powerpc/boot/dts/mpc866ads.dts
b/arch/powerpc/boot/dts/mpc866ads.dts
index daf9433..d669049 100644
--- a/arch/powerpc/boot/dts/mpc866ads.dts
+++ b/arch/powerpc/boot/dts/mpc866ads.dts
@@ -169,6 +169,16 @@
fsl,cpm-command = <>;
linux,network-index = <1>;
};
+
+ [EMAIL PROTECTED] {
+ compatible = "fsl,mpc866-i2c",
+"fsl,cpm1-i2c",
+"fsl,cpm-i2c";
+ reg = <860 20 3c80 30>;
+ interrupts = <10>;
+ interrupt-parent = <&CPM_PIC>;
+ fsl,cpm-command = <0010>;
+ };
};
};
diff --git a/arch/powerpc/boot/dts/mpc885ads.dts
b/arch/powerpc/boot/dts/mpc885ads.dts
index 8848e63..fd9c9d7 100644
--- a/arch/powerpc/boot/dts/mpc885ads.dts
+++ b/arch/powerpc/boot/dts/mpc885ads.dts
@@ -213,6 +213,16 @@
fsl,cpm-command = <0080>;
linux,network-index = <2>;
};
+
+ [EMAIL PROTECTED] {
+ compatible = "fsl,mpc885-i2c",
+"fsl,cpm1-i2c",
+"fsl,cpm-i2c";
+ reg = <860 20 3c80 30>;
+ interrupts = <10>;
+ interrupt-parent = <&CPM_PIC>;
+ fsl,cpm-command = <0010>;
+ };
};
};
diff --git a/arch/powerpc/platforms/82xx/mpc8272_ads.c
b/arch/powerpc/platforms/82xx/mpc8272_ads.c
index 3fce6b3..8f1862a 100644
--- a/arch/powerpc/platforms/82xx/mpc8272_ads.c
+++ b/arch/powerpc/platforms/82xx/mpc8272_ads.c
@@ -96,6 +96,11 @@ static struct cpm_pin mpc8272_ads_pins[] = {
{1, 31, CPM_PIN_OUTPUT | CPM_PIN_PRIMARY},
{2, 16, CPM_PIN_INPUT | CPM_PIN_PRIMARY},
{2, 17, CPM_PIN_INPUT | CPM_PIN_PRIMARY},
+
+ /* I2C */
+ {3, 26, CPM_PIN_INPUT | CPM_PIN_SECONDARY | CPM_PIN_OPENDRAIN},
+ {3, 27, CPM_PIN_INPUT | CPM_PIN_SECONDARY | CPM_PIN_OPENDRAIN},
+
};
static void __init init_ioports(void)
diff --git a/arch/powerpc/platforms/8xx/mpc86xads_setup.c
b/arch/powerpc/platforms/8xx/mpc86xads_setup.c
index c028a5b..caaec29 100644
--- a/arch/powerpc/platforms/8xx/mpc86xads_setup.c
+++ b/arch/powerpc/platforms/8xx/mpc86xads_setup.c
@@ -65,6 +65,10 @@ static struct cpm_pin mpc866ads_pins[] = {
{CPM_PORTD, 13, CPM_PIN_OUTPUT},
{CPM_PORTD, 14, CPM_PIN_OUTPUT},
{CPM_PORTD, 15, CPM_PIN_OUTPUT},
+
+ /* I2C */
+ {CPM_PORTB, 26, CPM_PIN_INPUT | CPM_PIN_OPENDRAIN},
+ {CPM_PORTB, 27, CPM_PIN_INPUT | CPM_PIN_OPENDRAIN},
};
static void __init init_ioports(void)
diff --git a/arch/powerpc/platforms/8xx/mpc885ads_setup.c
b/arch/powerpc/platforms/8xx/mpc885ads_setup.c
index 6e7ded0..45ed6cd 100644
--- a/arch/powerpc/platforms/8xx/mpc885ads_setup.c
+++ b/arch/powerpc/platforms/8xx/mpc885ads_setup.c
@@ -158,6 +158,9 @@ static struct cpm_pin mpc885ads_pins[] = {
{CPM_PORTE, 28, CPM_PIN_OUTPUT},
{CPM_PORTE, 29, CPM_PIN_OUTPUT},
#endif
+ /* I2C */
+ {CPM_PORTB, 26, CPM_PIN_INPUT | CPM_PIN_OPENDRAIN},
+ {CPM_PORTB, 27, CPM_PIN_INPUT | CPM
[PATCHv4 2.6.25] i2c: adds support for i2c bus on Freescale CPM1/CPM2 controllers
Using the port of 2.4 code from Vitaly Bordug <[EMAIL PROTECTED]>
and the actual algorithm used by the i2c driver of the DBox code on
cvs.tuxboc.org from Tmbinc, Gillem ([EMAIL PROTECTED]). Renamed i2c-rpx.c and
i2c-algo-8xx.c to i2c-cpm.c and converted the driver to an
of_platform_driver.
Signed-off-by: Jochen Friedrich <[EMAIL PROTECTED]>
---
drivers/i2c/busses/Kconfig | 10 +
drivers/i2c/busses/Makefile |1 +
drivers/i2c/busses/i2c-cpm.c | 759 ++
3 files changed, 770 insertions(+), 0 deletions(-)
create mode 100644 drivers/i2c/busses/i2c-cpm.c
diff --git a/drivers/i2c/busses/Kconfig b/drivers/i2c/busses/Kconfig
index b61f56b..1d18db7 100644
--- a/drivers/i2c/busses/Kconfig
+++ b/drivers/i2c/busses/Kconfig
@@ -114,6 +114,16 @@ config I2C_BLACKFIN_TWI_CLK_KHZ
help
The unit of the TWI clock is kHz.
+config I2C_CPM
+ tristate "Freescale CPM1 or CPM2 (MPC8xx/826x)"
+ depends on (CPM1 || CPM2) && I2C && PPC_OF
+ help
+ This supports the use of the I2C interface on Freescale
+ processors with CPM1 or CPM2.
+
+ This driver can also be built as a module. If so, the module
+ will be called i2c-cpm.
+
config I2C_DAVINCI
tristate "DaVinci I2C driver"
depends on ARCH_DAVINCI
diff --git a/drivers/i2c/busses/Makefile b/drivers/i2c/busses/Makefile
index ea7068f..1291e2b 100644
--- a/drivers/i2c/busses/Makefile
+++ b/drivers/i2c/busses/Makefile
@@ -11,6 +11,7 @@ obj-$(CONFIG_I2C_AMD8111) += i2c-amd8111.o
obj-$(CONFIG_I2C_AT91) += i2c-at91.o
obj-$(CONFIG_I2C_AU1550) += i2c-au1550.o
obj-$(CONFIG_I2C_BLACKFIN_TWI) += i2c-bfin-twi.o
+obj-$(CONFIG_I2C_CPM) += i2c-cpm.o
obj-$(CONFIG_I2C_DAVINCI) += i2c-davinci.o
obj-$(CONFIG_I2C_ELEKTOR) += i2c-elektor.o
obj-$(CONFIG_I2C_GPIO) += i2c-gpio.o
diff --git a/drivers/i2c/busses/i2c-cpm.c b/drivers/i2c/busses/i2c-cpm.c
new file mode 100644
index 000..7191427
--- /dev/null
+++ b/drivers/i2c/busses/i2c-cpm.c
@@ -0,0 +1,759 @@
+/*
+ * Freescale CPM1/CPM2 I2C interface.
+ * Copyright (c) 1999 Dan Malek ([EMAIL PROTECTED]).
+ *
+ * moved into proper i2c interface;
+ * Brad Parker ([EMAIL PROTECTED])
+ *
+ * (C) 2007 Montavista Software, Inc.
+ * Vitaly Bordug <[EMAIL PROTECTED]>
+ *
+ * RPX lite specific parts of the i2c interface
+ * Update: There actually isn't anything RPXLite-specific about this module.
+ * This should work for most any CPM board. The console messages have been
+ * changed to eliminate RPXLite references.
+ *
+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.
+
+This program is distributed in the hope that it will be useful,
+but WITHOUT ANY WARRANTY; without even the implied warranty of
+MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+GNU General Public License for more details.
+
+You should have received a copy of the GNU General Public License
+along with this program; if not, write to the Free Software
+Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
+ *
+ * moved into proper i2c interface; separated out platform specific
+ * parts into i2c-8xx.c
+ * Brad Parker ([EMAIL PROTECTED])
+ *
+ * Parts from dbox2_i2c.c (cvs.tuxbox.org)
+ * (C) 2000-2001 Tmbinc, Gillem ([EMAIL PROTECTED])
+ *
+ * (C) 2007 Montavista Software, Inc.
+ * Vitaly Bordug <[EMAIL PROTECTED]>
+ *
+ * Converted to of_platform_device. Renamed to i2c-cpm.c.
+ * (C) 2007 Jochen Friedrich <[EMAIL PROTECTED]>
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+/*
+ * Wait for patch from Jon Smirl
+ * #include "powerpc-common.h"
+ */
+
+/* Try to define this if you have an older CPU (earlier than rev D4) */
+/* However, better use a GPIO based bitbang driver in this case :/ */
+#undef I2C_CHIP_ERRATA
+
+#define CPM_MAX_READ513
+#define CPM_MAXBD 4
+
+#define CPM_CR_INIT_TRX(0x00)
+#define CPM_CR_CLOSE_RXBD (0x07)
+
+#define I2C_EB (0x10) /* Big endian mode */
+
+/* I2C parameter RAM. */
+struct i2c_ram {
+ ushort rbase; /* Rx Buffer descriptor base address */
+ ushort tbase; /* Tx Buffer descriptor base address */
+ u_char rfcr; /* Rx function code */
+ u_char tfcr; /* Tx function code */
+ ushort mrblr; /* Max receive buffer length */
+ uintrstate; /* Internal */
+ uintrdp;/* Internal */
+ ushort rbptr; /* Rx Buffer descriptor pointer */
+ ushort rbc;/* Internal */
+ uintrxtmp; /* Int
Re: [PATCH] [POWERPC] Set dma_data correctly for direct_ops on pasemi
On Thu, 2008-01-31 at 00:41 -0600, Olof Johansson wrote: > More late-caught fallout from the mainline merge. The patch: > > [POWERPC] Use archdata.dma_data in dma_direct_ops and add the offset > > "Now that all platforms using dma_direct_offset setup the > archdata.dma_data correctly, ..." > > Nope -- the pasemi iommu setup code that disables translation on the > DMA pci device didn't set dma_data correctly. > > The below patch is needed, please merge as soon as practical. Thanks! Sorry about that. I'm confused though, didn't your device come from alloc_pci_dev() which kzalloc()s the pci_dev which contains the archdata which contains the dma_data, ie. dma_data will already be 0? 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
[PATCH v7] [POWERPC] Add LED driver for Promess Motion-PRO board.
Add support for two Motion-PRO board custom LEDs:
- motionpro-statusled
- motionpro-readyled
Signed-off-by: Jan Wrobel <[EMAIL PROTECTED]>
Signed-off-by: Marian Balakowicz <[EMAIL PROTECTED]>
---
Update since v6:
- fix error handling for null label proper
drivers/leds/Kconfig |7 +
drivers/leds/Makefile |3
drivers/leds/leds-motionpro.c | 250 +
include/asm-powerpc/mpc52xx.h |5 +
4 files changed, 264 insertions(+), 1 deletions(-)
create mode 100644 drivers/leds/leds-motionpro.c
diff --git a/drivers/leds/Kconfig b/drivers/leds/Kconfig
index ec568fa..1567ed6 100644
--- a/drivers/leds/Kconfig
+++ b/drivers/leds/Kconfig
@@ -55,6 +55,13 @@ config LEDS_TOSA
This option enables support for the LEDs on Sharp Zaurus
SL-6000 series.
+config LEDS_MOTIONPRO
+ tristate "Motion-PRO LEDs Support"
+ depends on LEDS_CLASS && PPC_MPC5200
+ help
+ This option enables support for status and ready LEDs connected
+ to GPIO lines on Motion-PRO board.
+
config LEDS_S3C24XX
tristate "LED Support for Samsung S3C24XX GPIO LEDs"
depends on LEDS_CLASS && ARCH_S3C2410
diff --git a/drivers/leds/Makefile b/drivers/leds/Makefile
index a60de1b..a56d399 100644
--- a/drivers/leds/Makefile
+++ b/drivers/leds/Makefile
@@ -18,7 +18,8 @@ obj-$(CONFIG_LEDS_H1940) += leds-h1940.o
obj-$(CONFIG_LEDS_COBALT_QUBE) += leds-cobalt-qube.o
obj-$(CONFIG_LEDS_COBALT_RAQ) += leds-cobalt-raq.o
obj-$(CONFIG_LEDS_GPIO)+= leds-gpio.o
-obj-$(CONFIG_LEDS_CM_X270) += leds-cm-x270.o
+obj-$(CONFIG_LEDS_CM_X270) += leds-cm-x270.o
+obj-$(CONFIG_LEDS_MOTIONPRO) += leds-motionpro.o
# LED Triggers
obj-$(CONFIG_LEDS_TRIGGER_TIMER) += ledtrig-timer.o
diff --git a/drivers/leds/leds-motionpro.c b/drivers/leds/leds-motionpro.c
new file mode 100644
index 000..b8dfa8a
--- /dev/null
+++ b/drivers/leds/leds-motionpro.c
@@ -0,0 +1,250 @@
+/*
+ * LEDs driver for the Motion-PRO board.
+ *
+ * Copyright (C) 2007 Semihalf
+ * Jan Wrobel <[EMAIL PROTECTED]>
+ * Marian Balakowicz <[EMAIL PROTECTED]>
+ *
+ * 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.
+ *
+ * This program is distributed in the hope that it will be useful, but WITHOUT
+ * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for
+ * more details.
+ *
+ * You should have received a copy of the GNU General Public License along
+ * with this program; if not, write to the Free Software Foundation, Inc., 51
+ * Franklin St, Fifth Floor, Boston, MA 02110-1301 USA
+ *
+ *
+ * Decription:
+ * This driver enables control over Motion-PRO status and ready LEDs through
+ * sysfs. LEDs can be controlled by writing to sysfs files:
+ * class/leds//(brightness|delay_off|delay_on).
+ * See Documentation/leds-class.txt for more details.
+ * is the set to the value of 'label' property of the
+ * corresponding GPT node.
+ *
+ * Before user issues first control command via sysfs, LED blinking is
+ * controlled by the kernel ('blink-delay' property of the GPT node
+ * in the device tree blob).
+ *
+ */
+
+#define DEBUG
+
+#include
+#include
+#include
+#include
+
+/* LED control bits */
+#define LED_ON MPC52xx_GPT_OUTPUT_1
+
+/* LED mode */
+#define LED_MODE_KERNEL1
+#define LED_MODE_USER 2
+
+struct motionpro_led {
+ spinlock_t led_lock;/* Protects the LED data */
+ struct mpc52xx_gpt __iomem *gpt;/* LED registers */
+ struct timer_list blink_timer; /* Used if blink_delay is nonzero */
+ unsigned int blink_delay; /* [ms], if set to 0 blinking is off */
+ unsigned int mode; /* kernel/user */
+ struct led_classdev mpled_cdev; /* LED class */
+};
+
+/*
+ * Timer event - blinks LED before user takes control over it
+ * with the first access via sysfs.
+ */
+static void mpled_timer_toggle(unsigned long data)
+{
+ struct motionpro_led *mpled = (struct motionpro_led *)data;
+
+ spin_lock_bh(&mpled->led_lock);
+ if (mpled->mode == LED_MODE_KERNEL) {
+ u32 val = in_be32(&mpled->gpt->mode);
+ val ^= LED_ON;
+ out_be32(&mpled->gpt->mode, val);
+
+ mod_timer(&mpled->blink_timer,
+ jiffies + msecs_to_jiffies(mpled->blink_delay));
+ }
+ spin_unlock_bh(&mpled->led_lock);
+}
+
+/*
+ * Turn on/off led according to user settings in sysfs.
+ * First call to this function disables kernel blinking.
+ */
+static void mpled_set(struct led_classdev *led_cdev,
+ enum led_brightness brightness)
+{
+ struct motionpro_led *mpled;
+ int old_mode;
+ u3
Kernel oops while duming user core.
Hi I get the following kernel core while a user program I have is dumping core. Any DIeas at what to look for? (this is runnign 2.6.24, arch/powerpc on a 8280) When runnign the program on 2.6.18 arch/ppc, the program gets a sig 11 and dumps core. On 2.6.24, I ghet the kernel oops, and then the program hangs sround forever and is unkillable. Unable to handle kernel paging request for data at address 0x48024000 Faulting instruction address: 0xc000ef88 Oops: Kernel access of bad area, sig: 11 [#1] PREEMPT Innovative Systems ApMax Modules linked in: drv_wd(P) drv_scc devcom drv_pcir tipc drv_ss7 drv_auxcpu drv_leds(P) drv_ethsw proc_sysinfo(P) i2c_8266(P) NIP: c000ef88 LR: c0012180 CTR: 0080 REGS: eebc9b70 TRAP: 0300 Tainted: P (2.6.24) MSR: 9032 CR: 24004442 XER: DAR: 48024000, DSISR: 2000 TASK = eebac3c0[3131] 'armd' THREAD: eebc8000 GPR00: ee9b7d00 eebc9c20 eebac3c0 48024000 0080 399a4181 48024000 GPR08: 399a4181 ee9b7d00 c200 44004422 10100f38 ee82fc00 bfff GPR16: ef377060 0030 ee9b7d00 eebc9cdc 0011 eebc9cd8 eeb96480 GPR24: ee9b7d00 399a4181 48024000 eeb9a370 eeb9a370 399a4181 48024000 c2733480 NIP [c000ef88] __flush_dcache_icache+0x14/0x40 LR [c0012180] update_mmu_cache+0x74/0x114 Call Trace: [eebc9c20] [eebc8000] 0xeebc8000 (unreliable) [eebc9c40] [c005d060] handle_mm_fault+0x630/0xbc0 [eebc9c80] [c005d9e4] get_user_pages+0x3f4/0x4fc [eebc9cd0] [c00aa7c4] elf_core_dump+0x9a4/0xc5c [eebc9d60] [c00779e4] do_coredump+0x6e0/0x748 [eebc9e50] [c002a5b0] get_signal_to_deliver+0x40c/0x45c [eebc9e80] [c0008ce8] do_signal+0x50/0x294 [eebc9f40] [c000fb98] do_user_signal+0x74/0xc4 --- Exception: 300 at 0x10044efc LR = 0x10044ec0 Instruction dump: 4d820020 7c8903a6 7c001bac 38630020 4200fff8 7c0004ac 4e800020 6000 54630026 38800080 7c8903a6 7c661b78 <7c00186c> 38630020 4200fff8 7c0004ac ---[ end trace 97db37eaf213da3c ]--- note: armd[3131] exited with preempt_count 2 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
build fails for adder875 for new pulls of powerpc.git
The latest commits to powerpc.git removes commproc.h files used by arch/powerpc/platforms/8xx/adder875.c The kernel fails to build for the adder configs. Regards, Dag Rognlien <>___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [RFC] [POWERPC] bootwrapper: build multiple cuImages
On Wed, Jan 30, 2008 at 07:40:28PM -0700, Grant Likely wrote: > mpc866ads, mpc885ads and ep88xc are oddities in that they build > zImages with embedded device tree blobs. What about ep8248e? And the mpc8xxads boards use cuImage, not zImage. > One option would be to add two new targets: zImage.dtb.% and > zImage.initrd.dtb.%, but I'm not sure if it is a good idea. I'd much prefer that over having several lines per board in the makefile. -Scott ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
RE: Kernel oops while duming user core.
Nathan Lynch wrote: > Hmm, this is the second report of 2.6.24 crashing in > __flush_dcache_icache during a core dump; see: > http://ozlabs.org/pipermail/linuxppc-dev/2007-December/048662.html > > Is this easily recreatable? Yes. I have a binary that will do this every time it is started (on this particular system), only takes about 10 seconds before it dumps. I was going to test HEAD of powerpc.git to see if it is still there. I cannot test any earlier versions as our board port was done on 2.6.24. Our older kernel port is 2.6.18 on arch/ppc, and it works just fine. One potential clue: > Unable to handle kernel paging request for data at address 0x48024000 this adddress is beyond our physical memory. We have 1GB of mem (CONFIG_HIGH_MEM enabled) so 0x3fff_ is the last valid address. 0x4000_ to 0x7fff_ are unused, 0x8000_ to 0x9fff_ is used by PCI. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH v2] [POWERPC] Set dma_data correctly for direct_ops on pasemi
More fallout from the merge:
[POWERPC] Use archdata.dma_data in dma_direct_ops and add the offset
"Now that all platforms using dma_direct_offset setup the
archdata.dma_data correctly, ..."
Nope -- the pasemi iommu setup code that disables translation on the DMA
pci device still set dma_data to point at the table. The below patch is
needed, please merge asap.
Signed-off-by: Olof Johansson <[EMAIL PROTECTED]>
diff --git a/arch/powerpc/platforms/pasemi/iommu.c
b/arch/powerpc/platforms/pasemi/iommu.c
index 9916a0f..5803f11 100644
--- a/arch/powerpc/platforms/pasemi/iommu.c
+++ b/arch/powerpc/platforms/pasemi/iommu.c
@@ -182,8 +182,10 @@ static void pci_dma_dev_setup_pasemi(struct pci_dev *dev)
* CONFIG_PPC_PASEMI_IOMMU_DMA_FORCE at build time.
*/
if (dev->vendor == 0x1959 && dev->device == 0xa007 &&
- !firmware_has_feature(FW_FEATURE_LPAR))
+ !firmware_has_feature(FW_FEATURE_LPAR)) {
dev->dev.archdata.dma_ops = &dma_direct_ops;
+ return;
+ }
#endif
dev->dev.archdata.dma_data = &iommu_table_iobmap;
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] [POWERPC] Set dma_data correctly for direct_ops on pasemi
On Thu, Jan 31, 2008 at 11:38:16PM +1100, Michael Ellerman wrote: > On Thu, 2008-01-31 at 00:41 -0600, Olof Johansson wrote: > > More late-caught fallout from the mainline merge. The patch: > > > > [POWERPC] Use archdata.dma_data in dma_direct_ops and add the offset > > > > "Now that all platforms using dma_direct_offset setup the > > archdata.dma_data correctly, ..." > > > > Nope -- the pasemi iommu setup code that disables translation on the > > DMA pci device didn't set dma_data correctly. > > > > The below patch is needed, please merge as soon as practical. Thanks! > > Sorry about that. > > I'm confused though, didn't your device come from alloc_pci_dev() which > kzalloc()s the pci_dev which contains the archdata which contains the > dma_data, ie. dma_data will already be 0? Yeah, I don't see how my patch could work (but it did), since the code falls through and overwrites dma_data with the pointer to the table, just as before. Weird, I did test it last night. See new patch. -Olof ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
RE: Kernel oops while duming user core.
Rune Torgersen wrote:
> I was going to test HEAD of powerpc.git to see if it is still there.
Still there. Also used GDB on the vmlinux image to get source and
dissasembly of the ooops:
Unable to handle kernel paging request for data at address 0x48024000
Faulting instruction address: 0xc000f0a0
Oops: Kernel access of bad area, sig: 11 [#1]
PREEMPT Innovative Systems ApMax
Modules linked in: drv_wd(P) drv_scc devcom drv_pcir tipc drv_ss7
drv_auxcpu drv_leds(P) drv_ethsw proc_sysinfo(P) i2c_8266(P)
NIP: c000f0a0 LR: c0011fec CTR: 0080
REGS: eebe9b70 TRAP: 0300 Tainted: P (2.6.24-test)
MSR: 9032 CR: 24004442 XER:
DAR: 48024000, DSISR: 2000
TASK = eeba9780[2554] 'armd_crash' THREAD: eebe8000
GPR00: eea44d00 eebe9c20 eeba9780 48024000 0080 37a56181 48024000
GPR08: 37a56181 eea44d00 c200 44004422 10100f38 ef336600
bfff
GPR16: eeff0300 0030 eea44d00 eebe9cdc 0011 eebe9cd8
eebca480
GPR24: eea44d00 37a56181 48024000 eebad580 eebad580 37a56181 48024000
c26f4ac0
NIP [c000f0a0] __flush_dcache_icache+0x14/0x40
LR [c0011fec] update_mmu_cache+0x74/0x114
Call Trace:
[eebe9c20] [eebe8000] 0xeebe8000 (unreliable)
[eebe9c40] [c005cfd0] handle_mm_fault+0x630/0xbc0
[eebe9c80] [c005d954] get_user_pages+0x3f4/0x4fc
[eebe9cd0] [c00aa730] elf_core_dump+0x9a4/0xc5c
[eebe9d60] [c0077954] do_coredump+0x6e0/0x748
[eebe9e50] [c002a520] get_signal_to_deliver+0x40c/0x45c
[eebe9e80] [c0008cec] do_signal+0x50/0x294
[eebe9f40] [c000fc9c] do_user_signal+0x74/0xc4
--- Exception: 300 at 0x10044efc
LR = 0x10044ec0
Instruction dump:
4d820020 7c8903a6 7c001bac 38630020 4200fff8 7c0004ac 4e800020 6000
54630026 38800080 7c8903a6 7c661b78 <7c00186c> 38630020 4200fff8
7c0004ac
---[ end trace 37755b0fb9e79677 ]---
note: armd_crash[2554] exited with preempt_count 2
backtrace using gdb on vmlinux image:
0xc00aa730 is in elf_core_dump (fs/binfmt_elf.c:1762).
1757
1758for (addr = vma->vm_start; addr < end; addr +=
PAGE_SIZE) {
1759struct page *page;
1760struct vm_area_struct *vma;
1761
1762if (get_user_pages(current, current->mm,
addr, 1, 0, 1,
1763&page, &vma) <=
0) {
1764DUMP_SEEK(PAGE_SIZE);
1765} else {
1766if (page == ZERO_PAGE(0)) {
(gdb) list *0xc005d954
0xc005d954 is in get_user_pages (mm/memory.c:1072).
1067cond_resched();
1068while (!(page = follow_page(vma, start,
foll_flags))) {
1069int ret;
1070ret = handle_mm_fault(mm, vma,
start,
1071foll_flags &
FOLL_WRITE);
1072if (ret & VM_FAULT_ERROR) {
1073if (ret & VM_FAULT_OOM)
1074return i ? i :
-ENOMEM;
1075else if (ret &
VM_FAULT_SIGBUS)
1076return i ? i :
-EFAULT;
(gdb) list *0xc005cfd0
0xc005cfd0 is in handle_mm_fault (include/asm/thread_info.h:99).
94 {
95 register unsigned long sp asm("r1");
96
97 /* gcc4, at least, is smart enough to turn this into a
single
98 * rlwinm for ppc32 and clrrdi for ppc64 */
99 return (struct thread_info *)(sp & ~(THREAD_SIZE-1));
100 }
101
102 #endif /* __ASSEMBLY__ */
103
(gdb)
(gdb) list *0xc0011fec
0xc0011fec is in update_mmu_cache (arch/powerpc/mm/mem.c:489).
484 _tlbie(address, 0 /* 8xx doesn't care about PID
*/);
485 #endif
486 if (!PageReserved(page)
487 && !test_bit(PG_arch_1, &page->flags)) {
488 if (vma->vm_mm == current->active_mm) {
489 __flush_dcache_icache((void *)
address);
490 } else
491 flush_dcache_icache_page(page);
492 set_bit(PG_arch_1, &page->flags);
493 }
(gdb) list *0xc000f0a0
No source file for address 0xc000f0a0.
(gdb) disassemble 0xc000f0a0
Dump of assembler code for function __flush_dcache_icache:
0xc000f08c <__flush_dcache_icache+0>: dec%esi
0xc000f08d <__flush_dcache_icache+1>: addb $0x20,(%eax)
0xc000f090 <__flush_dcache_icache+4>: push %esp
0xc000f091 <__flush_dcache_icache+5>: arpl %ax,(%eax)
0xc000f093 <__flush_dcache_icache+7>: cmp%al,%es:0x897c8000(%eax)
0xc000f09a <__flush_dcache_icache+14>: add0x781b667c(%esi),%esp
0xc000f0a0 <__flush_dcache_icache+20>: jl 0xc000f0a2
<__flush_dcache_icache+22>
0xc000f0a2 <__flush_dcache_icache+2
Re: [PATCH 1/2] Add RapidIO node into MPC8641HPCN dts file
Zhang Wei wrote:
> Signed-off-by: Zhang Wei <[EMAIL PROTECTED]>
> ---
> arch/powerpc/boot/dts/mpc8641_hpcn.dts | 13 +
> 1 files changed, 13 insertions(+), 0 deletions(-)
>
> diff --git a/arch/powerpc/boot/dts/mpc8641_hpcn.dts
> b/arch/powerpc/boot/dts/mpc8641_hpcn.dts
> index 556a9ca..1a0fce5 100644
> --- a/arch/powerpc/boot/dts/mpc8641_hpcn.dts
> +++ b/arch/powerpc/boot/dts/mpc8641_hpcn.dts
> @@ -499,4 +500,16 @@
> 0 0010>;
> };
> };
> +
> + rapidio0: [EMAIL PROTECTED] {
> + #address-cells = <2>;
> + #size-cells = <2>;
> + compatible = "fsl,rapidio-delta";
> + reg = ;
> + ranges = <0 0 c000 0 2000>;
> + interrupt-parent = <&mpic>;
> + /* err_irq bell_outb_irq bell_inb_irq
> + msg1_tx_irq msg1_rx_irq msg2_tx_irq msg2_rx_irq */
> + interrupts = <30 2 31 2 32 2 35 2 36 2 37 2 38 2>;
> + };
> };
Have updates to the booting-without-of.txt file for
been made or proposed for the RapidIO node definition?
jdl
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH] adder875, ep88xc: fix to match recent 8xx cleanups.
asm/commproc.h was renamed to asm/cpm1.h
sysdev/commproc.h was renamed to platforms/8xx/mpc8xx.h
m8xx_pic_init was renamed to mpc8xx_pics_init
Signed-off-by: Scott Wood <[EMAIL PROTECTED]>
---
arch/powerpc/platforms/8xx/adder875.c |6 +++---
arch/powerpc/platforms/8xx/ep88xc.c |1 -
2 files changed, 3 insertions(+), 4 deletions(-)
diff --git a/arch/powerpc/platforms/8xx/adder875.c
b/arch/powerpc/platforms/8xx/adder875.c
index c6bc078..82363e9 100644
--- a/arch/powerpc/platforms/8xx/adder875.c
+++ b/arch/powerpc/platforms/8xx/adder875.c
@@ -15,12 +15,12 @@
#include
#include
-#include
+#include
#include
#include
#include
-#include
+#include "mpc8xx.h"
struct cpm_pin {
int port, pin, flags;
@@ -108,7 +108,7 @@ define_machine(adder875) {
.name = "Adder MPC875",
.probe = adder875_probe,
.setup_arch = adder875_setup,
- .init_IRQ = m8xx_pic_init,
+ .init_IRQ = mpc8xx_pics_init,
.get_irq = mpc8xx_get_irq,
.restart = mpc8xx_restart,
.calibrate_decr = generic_calibrate_decr,
diff --git a/arch/powerpc/platforms/8xx/ep88xc.c
b/arch/powerpc/platforms/8xx/ep88xc.c
index a8dffa0..7d9ac60 100644
--- a/arch/powerpc/platforms/8xx/ep88xc.c
+++ b/arch/powerpc/platforms/8xx/ep88xc.c
@@ -15,7 +15,6 @@
#include
#include
#include
-#include
#include
#include "mpc8xx.h"
--
1.5.3.8
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH] powerpc: correct 2nd pci controller interrupt value in mpc834x_mds dts
according to the 8349EA ref man, pci2 IRQ is 67. Thanks to Peter Van Ackeren for finding this. Signed-off-by: Kim Phillips <[EMAIL PROTECTED]> --- arch/powerpc/boot/dts/mpc834x_mds.dts |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/arch/powerpc/boot/dts/mpc834x_mds.dts b/arch/powerpc/boot/dts/mpc834x_mds.dts index 7480eda..0199c5c 100644 --- a/arch/powerpc/boot/dts/mpc834x_mds.dts +++ b/arch/powerpc/boot/dts/mpc834x_mds.dts @@ -332,7 +332,7 @@ 0xc000 0x0 0x0 0x3 &ipic 23 0x8 0xc000 0x0 0x0 0x4 &ipic 20 0x8>; interrupt-parent = <&ipic>; - interrupts = <66 0x8>; + interrupts = <67 0x8>; bus-range = <0 0>; ranges = <0x0200 0x0 0xb000 0xb000 0x0 0x1000 0x4200 0x0 0xa000 0xa000 0x0 0x1000 -- 1.5.2.2 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
RE: x86/non-x86: percpu, node ids, apic ids x86.git fixup
> hm, as far as i could check, on ia64 UP the .percpu section link > difference was the only ia64 difference i could find out of those > changes. Could you try to copy a 2.6.24 include/asm-generic/percpu.h, > include/asm-ia64.h and include/linux/percpu.h into your current tree, > and see whether that boots? If yes, then it's the percpu changes. The > patch below does this ontop of very latest -git - and it builds fine > with your UP config with a crosscompiler. Applied that patch and UP kernel built ok, and then crashed in the same place with the memset() to a user-looking address from kmem_cache_alloc() So the percpu changes are innocent ... something else since 2.6.24 is to blame. Only 5749 commits :-) I'll start bisecting. -Tony ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
RE: [PATCH 4/6] Add multi mport support.
On Thu, 2008-01-31 at 14:30 +0800, Zhang Wei wrote: > > > -Original Message- > > From: Kumar Gala [mailto:[EMAIL PROTECTED] > > > > On Jan 31, 2008, at 12:15 AM, Kumar Gala wrote: > > > > > > > > On Jan 30, 2008, at 11:57 PM, Zhang Wei wrote: > > > > > >> > > >> > > >>> -Original Message- > > >>> From: Kumar Gala [mailto:[EMAIL PROTECTED] > > >>> > > >>> On Jan 30, 2008, at 4:30 AM, Zhang Wei wrote: > > >>> > > Change lots of static variable to mport private. And add > > >>> mport to some > > function declaration. > > >>> > > >>> Can you explain this patch further. Its not clear > > exactly from this > > >>> commit message why we are doing this. > > >>> > > >>> - k > > >> > > >> Sorry about I have a little hurry about it. > > >> > > >> The original RapidIO driver suppose there is only one mpc85xx RIO > > >> controller > > >> in system. So, some data structures are defined as mpc85xx_rio > > >> global, > > >> such as 'regs_win', 'dbell_ring', 'msg_tx_ring'. Now, I > > changed them > > >> to > > >> mport's private members. And you can define multi RIO > > OF-nodes in dts > > >> file > > >> for multi RapidIO controller in one processor, such as PCI/PCI-Ex > > >> host > > >> controllers > > >> in Freescale's silicon. And the mport operation function > > declaration > > >> should be changed > > >> to know which RapidIO controller is target. > > > > > > thanks, this makes a lot of sense and now reviewing the patch will > > > make some sense to me :) > > > > when we have multiple ports are the device IDs on the ports intended > > to be unique only to a port or unique across all ports? > > > I consider each RIO controller will has its own network, the device IDs > should be > unique only in its port network. Hmmm, I see two cases: 1. I have two mport to two controllers each connected to different physical fabrics. This system can act as an application bridge between the two fabrics. 2. I have two mports to two controllers each connected directly or indirectly to the same fabric. I want to use the extra bandwidth and load balance and/or have a fall back redundant connection via an alternate physical connection to the fabric etc. What should be the rules for allocating the initial IDs to the two mports to allow system wide enumeration to work in both of the above cases? What do you expect the semantics of higher level addressing to be: a pair , where is a different device from , a pair , where is the same device as ,or a singleton n, where n is unique and identifies the first routing step of which controller, x or y, to use. I smell a can of worms :-) Cheers Phil > > Cheers! > Wei > ___ > 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
Re: [RFC] [POWERPC] bootwrapper: build multiple cuImages
On 1/31/08, Scott Wood <[EMAIL PROTECTED]> wrote: > On Wed, Jan 30, 2008 at 07:40:28PM -0700, Grant Likely wrote: > > mpc866ads, mpc885ads and ep88xc are oddities in that they build > > zImages with embedded device tree blobs. > > What about ep8248e? And the mpc8xxads boards use cuImage, not zImage. Oops, those are just mistakes. I can fix them > > > One option would be to add two new targets: zImage.dtb.% and > > zImage.initrd.dtb.%, but I'm not sure if it is a good idea. > > I'd much prefer that over having several lines per board in the makefile. Okay, I can change that. Another option is to modify the wrapper to specifically look for targets which need the dtb. At the moment, that list includes ps3, ep8248e, mpc885ads and ep88xc. All four could be using a common build target. Cheers, 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] [XILINX][HWICAP] Xilinx Internal Configuration Access Port device driver.
Peter,
Sorry, this has taken so long... I've undertaken some significant
refactorings, and included support for the new EDK9.2 xps_hwicap.
Responses below.
> Please don't put the HWICAP option in the middle of the HVC options.
oops! fixed.
>
> > +config XILINX_HWICAP
> > + tristate "Xilinx OPB HWICAP Support"
> > + depends on XILINX_VIRTEX
> > + help
> > + This option enables support for Xilinx Internal
> Configuration Access Port (ICAP) driver.
>
> Line too long.
fixed. checkpatch passes now.
> > +obj-$(CONFIG_XILINX_HWICAP) += xilinx_hwicap_m.o
> > +
> > +xilinx_hwicap_m-y := xilinx_hwicap.o xhwicap_srp.o
>
> Those files are both quite small, couldn't you merge them and get rid
> of the global symbols and the xilinx_hwicap directory?
Its somewhat an artifact of the original EDK code that it is derived
from,
but your probably right. I've refactored the code to look a little bit
nicer, and now there is a new C file for the fifo-based xps_hwicap. I
think it really does make sense to have multiple files, now.
> Could you please you a smaller / standard GPL header instead?
Although most copyrights are shorter, in poking through the code, there
others which are of comparable size/language.
> Please use std kerneldoc format.
Fixed.
> No CamelCase, Uppercase parameters.
Fixed.
> > + if (XHwIcap_mGetDoneReg(InstancePtr->baseAddress) ==
> XHI_NOT_FINISHED) {
> > + return -EBUSY;
> > + }
>
> No curly brackets around single statement. In general, please run the
> patch through checkpatch.pl and fixup stuff.
Gah... force of habit. Does anyone have an emacs mode that comes close
to the linux coding style?
> Why don't you request official major/minor numbers?
> (Documentation/devices.txt)
I sent a request to lanana over amonth ago, but haven't received a
response. For embedded targets the dynamically allocated device is
annoying, but without a static number I don't see what else to do. In
any event, it is easy to change when a static device number is
allocated.
> > +static struct device_driver xhwicap_module_driver = {
> > + .name = DRIVER_NAME,
> > + .bus = &platform_bus_type,
> > +
> > + .probe = xhwicap_drv_probe,
> > + .remove = xhwicap_drv_remove,
> > +};
>
> Please use struct platform_driver instead.
That's what I get for copying old code. I also realized that there is a
better way of dealing with the of_platform_device part. It's been
rewritten to follow the pattern that Grant and I have been following.
> > +
> > +static int __init xhwicap_module_init(void)
> > +{
> > + dev_t devt;
> > + int retval;
> > +
> > + icap_class = class_create(THIS_MODULE, "xilinx_config");
>
> What's that for?
To get this:
-bash-3.00# pwd
/sys/class
-bash-3.00# find xilinx_config
xilinx_config
xilinx_config/xilinx_icap
xilinx_config/xilinx_icap/subsystem
xilinx_config/xilinx_icap/uevent
xilinx_config/xilinx_icap/dev
I started trying to do more with this, but I could never quite figure
out how to get sysfs to do what I wanted to. There's a couple of things
(like the IDCODE) that would be interesting to see here, I think.
> > +#ifdef CONFIG_XILINX_VIRTEX_4_FX
> > +#define XHI_FAMILY virtex4
> > +#else
> > +#define XHI_FAMILY virtex2
> > +#endif
>
> So having a single kernel with v2p/v4 support is not an option?
I've fixed this to add a level of indirection, and to select the right
value based on the device tree. This required a slight modification to
the mhs->dts generator to make the 'xlnx,family' attribute visible.
Note that we currently can't build a real v2/v4 kernel because of some
v2pro errata. Currently, I enable the errata even in v4, which is not
so nice.
> > +#define XHwIcap_mGetSizeReg(BaseAddress) \
> > +(in_be32((u32 *)((BaseAddress) + XHI_SIZE_REG_OFFSET)))
> > +
> >
> +/
> /
>
> Why not a single getter with a offset/register parameter instead of
> all these? And use inline functions instead of macros.
Historical artifact to some extent, but I think it makes cleaner code
than trying to read the constants, and in some cases, it's not a
straightforward register read. In any event, they've been changed to be
static inlines. In general, I cleaned the code up alot.
> Bye, Peter Korsgaard
Thanks! An update will be coming around shortly.
Steve
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: build fails for adder875 for new pulls of powerpc.git
Hi Rognlien,
> The latest commits to powerpc.git removes commproc.h files used by
> arch/powerpc/platforms/8xx/adder875.c
>
> The kernel fails to build for the adder configs.
This should fix it:
diff --git a/arch/powerpc/platforms/8xx/adder875.c
b/arch/powerpc/platforms/8xx/adder875.c
index c6bc078..b49d62a 100644
--- a/arch/powerpc/platforms/8xx/adder875.c
+++ b/arch/powerpc/platforms/8xx/adder875.c
@@ -15,12 +15,12 @@
#include
#include
-#include
+#include
#include
#include
#include
-#include
+#include "mpc8xx.h"
struct cpm_pin {
int port, pin, flags;
Thanks,
Jochen
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: build fails for adder875 for new pulls of powerpc.git
On Jan 31, 2008, at 12:20 PM, Jochen Friedrich wrote:
> Hi Rognlien,
>
>> The latest commits to powerpc.git removes commproc.h files used by
>> arch/powerpc/platforms/8xx/adder875.c
>>
>> The kernel fails to build for the adder configs.
>
> This should fix it:
>
> diff --git a/arch/powerpc/platforms/8xx/adder875.c b/arch/powerpc/
> platforms/8xx/adder875.c
> index c6bc078..b49d62a 100644
> --- a/arch/powerpc/platforms/8xx/adder875.c
> +++ b/arch/powerpc/platforms/8xx/adder875.c
> @@ -15,12 +15,12 @@
>
> #include
> #include
> -#include
> +#include
> #include
> #include
> #include
>
> -#include
> +#include "mpc8xx.h"
>
> struct cpm_pin {
> int port, pin, flags;
>
> Thanks,
> Jochen
I'll take scott's version as its more complete and fixes another board.
- k
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
RE: Kernel oops while duming user core.
Kumar Gala wrote: > This doesn't look like ppc disasm to me :) > Helps if i use the cross-compiler gdb instead of the x86 native one... here is the disasembly dump for NIP (gdb) disassemble 0xc000f0a0 Dump of assembler code for function __flush_dcache_icache: 0xc000f08c <__flush_dcache_icache+0>: blr 0xc000f090 <__flush_dcache_icache+4>: rlwinm r3,r3,0,0,19 0xc000f094 <__flush_dcache_icache+8>: li r4,128 0xc000f098 <__flush_dcache_icache+12>: mtctr r4 0xc000f09c <__flush_dcache_icache+16>: mr r6,r3 0xc000f0a0 <__flush_dcache_icache+20>: dcbst r0,r3 0xc000f0a4 <__flush_dcache_icache+24>: addir3,r3,32 0xc000f0a8 <__flush_dcache_icache+28>: bdnz+ 0xc000f0a0 <__flush_dcache_icache+20> 0xc000f0ac <__flush_dcache_icache+32>: sync 0xc000f0b0 <__flush_dcache_icache+36>: mtctr r4 0xc000f0b4 <__flush_dcache_icache+40>: icbir0,r6 0xc000f0b8 <__flush_dcache_icache+44>: addir6,r6,32 0xc000f0bc <__flush_dcache_icache+48>: bdnz+ 0xc000f0b4 <__flush_dcache_icache+40> 0xc000f0c0 <__flush_dcache_icache+52>: sync 0xc000f0c4 <__flush_dcache_icache+56>: isync 0xc000f0c8 <__flush_dcache_icache+60>: blr End of assembler dump. (gdb) registers were: NIP: c000f0a0 LR: c0011fec CTR: 0080 REGS: eebe9b70 TRAP: 0300 Tainted: P (2.6.24-test) MSR: 9032 CR: 24004442 XER: DAR: 48024000, DSISR: 2000 TASK = eeba9780[2554] 'armd_crash' THREAD: eebe8000 GPR00: eea44d00 eebe9c20 eeba9780 48024000 0080 37a56181 48024000 GPR08: 37a56181 eea44d00 c200 44004422 10100f38 ef336600 bfff GPR16: eeff0300 0030 eea44d00 eebe9cdc 0011 eebe9cd8 eebca480 GPR24: eea44d00 37a56181 48024000 eebad580 eebad580 37a56181 48024000 c26f4ac0 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
RE: Kernel oops while duming user core.
Kumar Gala wrote: > Can you git-bisect to narrow this down further. Not easilly, as the board port to arch/powerpc was done on 2.6.24-rc7 and up. Is there an somewhat esy way in git to apply the differences from master branch to our board branch to a branch created by bisect? And I don't even know where this started to happen. Would trying arch/ppc help any? I have our arch/ppc port in a semiworking state for kernels up to 2.6.23 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Kernel oops while duming user core.
On Jan 31, 2008, at 10:26 AM, Rune Torgersen wrote: > Nathan Lynch wrote: >> Hmm, this is the second report of 2.6.24 crashing in >> __flush_dcache_icache during a core dump; see: >> http://ozlabs.org/pipermail/linuxppc-dev/2007-December/048662.html >> >> Is this easily recreatable? > > Yes. I have a binary that will do this every time it is started (on > this > particular system), > only takes about 10 seconds before it dumps. > > I was going to test HEAD of powerpc.git to see if it is still there. > I cannot test any earlier versions as our board port was done on > 2.6.24. > > Our older kernel port is 2.6.18 on arch/ppc, and it works just fine. > > > One potential clue: >> Unable to handle kernel paging request for data at address 0x48024000 > > this adddress is beyond our physical memory. We have 1GB of mem > (CONFIG_HIGH_MEM enabled) so 0x3fff_ is the last valid address. > 0x4000_ to 0x7fff_ are unused, 0x8000_ to 0x9fff_ is > used by PCI. Can you git-bisect to narrow this down further. - k ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Kernel oops while duming user core.
>} > (gdb) list *0xc000f0a0 > No source file for address 0xc000f0a0. > (gdb) disassemble 0xc000f0a0 > Dump of assembler code for function __flush_dcache_icache: > 0xc000f08c <__flush_dcache_icache+0>: dec%esi > 0xc000f08d <__flush_dcache_icache+1>: addb $0x20,(%eax) > 0xc000f090 <__flush_dcache_icache+4>: push %esp > 0xc000f091 <__flush_dcache_icache+5>: arpl %ax,(%eax) > 0xc000f093 <__flush_dcache_icache+7>: cmp%al,%es: > 0x897c8000(%eax) > 0xc000f09a <__flush_dcache_icache+14>: add0x781b667c(%esi),%esp > 0xc000f0a0 <__flush_dcache_icache+20>: jl 0xc000f0a2 > <__flush_dcache_icache+22> > 0xc000f0a2 <__flush_dcache_icache+22>: sbb%ch,0x63(%eax,%edi,1) > 0xc000f0a6 <__flush_dcache_icache+26>: add%ah,(%eax) > 0xc000f0a8 <__flush_dcache_icache+28>: inc%edx > 0xc000f0a9 <__flush_dcache_icache+29>: add%bh,%bh > 0xc000f0ab <__flush_dcache_icache+31>: clc > 0xc000f0ac <__flush_dcache_icache+32>: jl 0xc000f0ae > <__flush_dcache_icache+34> > 0xc000f0ae <__flush_dcache_icache+34>: add$0xac,%al > 0xc000f0b0 <__flush_dcache_icache+36>: jl 0xc000f03b > > 0xc000f0b2 <__flush_dcache_icache+38>: add0xac37007c(%esi),%esp > 0xc000f0b8 <__flush_dcache_icache+44>: cmp%al,%dh > 0xc000f0ba <__flush_dcache_icache+46>: add%ah,(%eax) > 0xc000f0bc <__flush_dcache_icache+48>: inc%edx > 0xc000f0bd <__flush_dcache_icache+49>: add%bh,%bh > 0xc000f0bf <__flush_dcache_icache+51>: clc > 0xc000f0c0 <__flush_dcache_icache+52>: jl 0xc000f0c2 > <__flush_dcache_icache+54> > 0xc000f0c2 <__flush_dcache_icache+54>: add$0xac,%al > 0xc000f0c4 <__flush_dcache_icache+56>: dec%esp > 0xc000f0c5 <__flush_dcache_icache+57>: add%al,(%ecx) > 0xc000f0c7 <__flush_dcache_icache+59>: sub$0x4e,%al > 0xc000f0c9 <__flush_dcache_icache+61>: addb $0x20,(%eax) > End of assembler dump. This doesn't look like ppc disasm to me :) - k ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Kernel oops in MPC8568MDS BSP
Hello, I am using MPC8568MDS BSP on my board, which has same memory map with MPC8568MDS board. However I have kernel Ooop at free_bootmem_with_active_regions() within do_init_bootmem(). Any idea on this issue? Thanks, Mike bootm 0x100 0x200 0x40 ## Booting image at 0100 ... Image Name: Linux-2.6.23 Created: 2008-01-31 18:52:45 UTC Image Type: PowerPC Linux Kernel Image (gzip compressed) Data Size:1370100 Bytes = 1.3 MB Load Address: Entry Point: Verifying Checksum ... OK Uncompressing Kernel Image ... OK ## Loading RAMDisk Image at 0200 ... Image Name: uboot ext2 ramdisk rootfs Created: 2007-11-26 2:28:38 UTC Image Type: PowerPC Linux RAMDisk Image (gzip compressed) Data Size:4001113 Bytes = 3.8 MB Load Address: Entry Point: Verifying Checksum ... OK Booting using flat device tree at 0x40 Loading Ramdisk to 1fb6e000, end 1ff3ed59 ... OK Using MPC85xx MDS machine description Memory CAM mapping: CAM0=256Mb, CAM1=256Mb, CAM2=0Mb residual: 0Mb Linux version 2.6.23 () (gcc version 4.1.2) #3 Thu Jan 31 13:52:40 EST 2008 Found initrd at 0xdfb6e000:0xdff3ed59 console [udbg0] enabled Kernel BUG at c0296a68 [verbose debug info unavailable] Oops: Exception in kernel mode, sig: 5 [#1] MPC85xx MDS Modules linked in: NIP: c0296a68 LR: c0298100 CTR: 1c00 REGS: c02c7ec0 TRAP: 0700 Not tainted (2.6.23) MSR: 00021000 CR: 24002028 XER: 2000 TASK = c02ac5e0[0] 'swapper' THREAD: c02c6000 GPR00: 0001 c02c7f70 c02ac5e0 c02daa2c 0001e401 2000 0356 GPR08: 0001 25e9 25e9 24002022 6000 1ffbd400 007fff00 GPR16: 1ffb9824 0004 1fffc830 0080 007ffeb0 003d0d59 GPR24: 1ff3fe50 1140 c02b c02a5320 0002 Call Trace: [c02c7f90] [c0291144] [c02c7fb0] [c028f250] [c02c7fc0] [c028681c] [c02c7ff0] [c388] Instruction dump: 5489e8fa 7d30 7d295a14 7d604828 7d6a0078 7d40492d 40a2fff4 7c095839 38840001 4182000c 4200ffd0 4e800020 <0fe0> 4800 3d20c02b 7c601b78 Kernel panic - not syncing: Attempted to kill the idle task! ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: build fails for adder875 for new pulls of powerpc.git
Hi Rognlien,
> Hi Rognlien,
>
>> The latest commits to powerpc.git removes commproc.h files used by
>> arch/powerpc/platforms/8xx/adder875.c
>>
>> The kernel fails to build for the adder configs.
>
> This should fix it:
>
> diff --git a/arch/powerpc/platforms/8xx/adder875.c
> b/arch/powerpc/platforms/8xx/adder875.c
> index c6bc078..b49d62a 100644
> --- a/arch/powerpc/platforms/8xx/adder875.c
> +++ b/arch/powerpc/platforms/8xx/adder875.c
> @@ -15,12 +15,12 @@
>
> #include
> #include
> -#include
> +#include
> #include
> #include
> #include
>
> -#include
> +#include "mpc8xx.h"
>
> struct cpm_pin {
> int port, pin, flags;
sorry, this fix was incomplete. Scott Wood just posted a correct fix.
Thanks,
Jochen
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] [POWERPC] Xilinx: hwicap driver
On 1/31/08, Stephen Neuendorffer <[EMAIL PROTECTED]> wrote:
> This includes code for new fifo-based xps_hwicap in addition to the
> older opb_hwicap, which has a significantly different interface. The
> common code between the two drivers is largely shared.
>
> Significant differences exists between this driver and what is
> supported in the EDK drivers. In particular, most of the
> architecture-specific code for reconfiguring individual FPGA resources
> has been removed. This functionality is likely better provided in a
> user-space support library. In addition, read and write access is
> supported. In addition, although the xps_hwicap cores support
> interrupt-driver mode, this driver only supports polled operation, in
> order to make the code simpler, and since the interrupt processing
> overhead is likely to slow down the throughput under Linux.
>
> Signed-off-by: Stephen Neuendorffer <[EMAIL PROTECTED]>
Comments below...
Also, I'm not sure if drivers/char/xilinx_hwicap is the best place for
this driver. drivers/misc/ might be better (but I'm not sure; poll
other people on this)
Finally, buffer_icap and fifo_icap are not huge blocks of code. Will
they be used by any other drivers? Can they be rolled into the
xilinx_hwicap.c file?
> +static int buffer_icap_device_read(struct hwicap_drvdata *drvdata,
> + u32 offset, u32 count)
> +{
> +
> + s32 retries = 0;
> + void __iomem *base_address = drvdata->base_address;
> +
> + if (buffer_icap_busy(base_address))
> + return -EBUSY;
> +
> + if ((offset + count) <= XHI_MAX_BUFFER_INTS) {
> + /* setSize count*4 to get bytes. */
> + buffer_icap_set_size(base_address, (count << 2));
> + buffer_icap_set_offset(base_address, offset);
> + buffer_icap_set_rnc(base_address, XHI_READBACK);
> +
> + while (buffer_icap_busy(base_address)) {
> + retries++;
> + if (retries > XHI_MAX_RETRIES)
> + return -EBUSY;
> + }
> + } else {
> + return -EINVAL;
> + }
Style comment: reverse the condition and bail with return -EINVAL at
the test point. It will simplify the code and better match with
common practice in the kernel.
> + return 0;
> +
> +};
> +
> +/**
> + * buffer_icap_device_write: Transfer bytes from ICAP to the storage buffer.
> + * @parameter drvdata: a pointer to the drvdata.
> + * @parameter offset: The storage buffer start address.
> + * @parameter count: The number of words (32 bit) to read from the
> + * device (ICAP).
> + **/
> +static int buffer_icap_device_write(struct hwicap_drvdata *drvdata,
> + u32 offset, u32 count)
> +{
> +
> + s32 retries = 0;
> + void __iomem *base_address = drvdata->base_address;
> +
> + if (buffer_icap_busy(base_address))
> + return -EBUSY;
> +
> + if ((offset + count) <= XHI_MAX_BUFFER_INTS) {
> + /* setSize count*4 to get bytes. */
> + buffer_icap_set_size(base_address, count << 2);
> + buffer_icap_set_offset(base_address, offset);
> + buffer_icap_set_rnc(base_address, XHI_CONFIGURE);
> +
> + while (buffer_icap_busy(base_address)) {
> + retries++;
> + if (retries > XHI_MAX_RETRIES)
> + return -EBUSY;
> + }
> + } else {
> + return -EINVAL;
> + }
Ditto
> +/**
> + * buffer_icap_set_configuration: Load a partial bitstream from system
> memory.
> + * @parameter drvdata: a pointer to the drvdata.
> + * @parameter data: Kernel address of the partial bitstream.
> + * @parameter size: the size of the partial bitstream in 32 bit words.
> + **/
> +int buffer_icap_set_configuration(struct hwicap_drvdata *drvdata, u32 *data,
> +u32 size)
> +{
> + int status;
> + s32 buffer_count = 0;
> + s32 num_writes = 0;
> + bool dirty = 0;
> + u32 i;
> + void __iomem *base_address = drvdata->base_address;
> +
> + /* Loop through all the data */
> + for (i = 0, buffer_count = 0; i < size; i++) {
> +
> + /* Copy data to bram */
> + buffer_icap_set_bram(base_address, buffer_count, data[i]);
> + dirty = 1;
> +
> + if (buffer_count == XHI_MAX_BUFFER_INTS - 1) {
> + /* Write data to ICAP */
> + status = buffer_icap_device_write(
> + drvdata,
> + XHI_BUFFER_START,
> + XHI_MAX_BUFFER_INTS);
> + if (status != 0) {
> + /* abort. */
> + buffer_icap_reset(drvdata);
> + return status;
> +
Re: Kernel oops while duming user core.
Rune Torgersen wrote: > Kumar Gala wrote: > > Can you git-bisect to narrow this down further. > > Not easilly, as the board port to arch/powerpc was done on 2.6.24-rc7 > and up. > Is there an somewhat esy way in git to apply the differences from master > branch to our board branch to a branch created by bisect? > > And I don't even know where this started to happen. > Would trying arch/ppc help any? I have our arch/ppc port in a > semiworking state for kernels up to 2.6.23 Well, we know this happens on other 32-bit powerpc machines (pmac at least)... perhaps someone could arrange to bisect on a machine that works with older powerpc kernels (assuming they have a good repro case). ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Kernel oops while duming user core.
On Thu, Jan 31, 2008 at 11:40:04AM -0600, Rune Torgersen wrote: > Unable to handle kernel paging request for data at address 0x48024000 > Faulting instruction address: 0xc000f0a0 > Oops: Kernel access of bad area, sig: 11 [#1] > PREEMPT Innovative Systems ApMax Does it happen without preempt? > Modules linked in: drv_wd(P) drv_scc devcom drv_pcir tipc drv_ss7 > drv_auxcpu drv_leds(P) drv_ethsw proc_sysinfo(P) i2c_8266(P) > NIP: c000f0a0 LR: c0011fec CTR: 0080 > REGS: eebe9b70 TRAP: 0300 Tainted: P (2.6.24-test) Does it happen without the modules? > MSR: 9032 CR: 24004442 XER: > DAR: 48024000, DSISR: 2000 Hmm, this doesn't look like a valid DSISR, so I'm guessing this was a TLB miss that got redirected to DataAccess (or is there something that causes DSRISR[2] to be set on 8280? I didn't see anything in the manual...). However, SRR1 in that case seems to indicate a store, which dcbst shouldn't generate (except on 8xx, according to the comment in update_mmu_cache). Do you have a simple test case that we could try to reproduce? I tried a simple core dump on an 8280, and it worked. Failing that, I'd add code to the page fault handler to dump what is (or isn't) supposed to be mapped at the faulting address, and something to track which (if any) TLB miss exception it came through. -Scott ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
RE: Kernel oops while duming user core.
Scott Wood wrote: > Does it happen without preempt? Will try shortly, just updated my git to HEAD of Linus's tree > >> Modules linked in: drv_wd(P) drv_scc devcom drv_pcir tipc drv_ss7 >> drv_auxcpu drv_leds(P) drv_ethsw proc_sysinfo(P) i2c_8266(P) >> NIP: c000f0a0 LR: c0011fec CTR: 0080 >> REGS: eebe9b70 TRAP: 0300 Tainted: P (2.6.24-test) > > Does it happen without the modules? Cannot test without most of them. > Do you have a simple test case that we could try to > reproduce? I tried a > simple core dump on an 8280, and it worked. I do not have a testcase, except a app for our board that does this reliably after about 10 seconds. > Failing that, I'd add code to the page fault handler to dump what is > (or isn't) supposed to be mapped at the faulting address, and > something to track which (if any) TLB miss exception it came through. I can test code. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
RE: Kernel oops while duming user core.
Scott Wood wrote: > Does it happen without preempt? Yes ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
RE: Kernel oops while duming user core.
Nathan Lynch wrote: > Scott Wood wrote: >> Do you have a simple test case that we could try to reproduce? I >> tried a simple core dump on an 8280, and it worked. > > Is the crashing program multithreaded? The first report had firefox > triggering the oops. The crashing program has 10 threads. (NPTL pthreads, glibc-2.5, gcc 4.1.2) ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Kernel oops while duming user core.
Nathan Lynch wrote: > I doubt the modules are the problem; there was a practically identical > report from someone with an untainted 2.6.24-rc kernel a few weeks ago > (see my first reply to Rune). I didn't think they were; I was just trying to eliminate the low hanging fruit and get a simpler testcase. :-) >> Do you have a simple test case that we could try to reproduce? I tried a >> simple core dump on an 8280, and it worked. > > Is the crashing program multithreaded? The first report had firefox > triggering the oops. OK, I've got a test program that triggers it now. I'll see if I can figure out what's going on. -Scott ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Reminder: removal of arch/ppc
On Friday 25 January 2008, Kumar Gala wrote: > Just a reminder that the plan is to remove arch/ppc this summer (June > 2008). The following boards still existing over in arch/ppc. Some of > them have been ported over to arch/powerpc. If you care about one of > these boards and its not ported speak up (it helps if you have access > to the board). Also, if you know a given board is free to die of > bitrot let us know so we know not to worry about it: > > PREP > PQ2ADS > TQM8260 > CPCI690 > EV64260 > CHESTNUT > LOPEC > KATANA > HDPU HDPU can die. The company is not maintaining the platform anymore. Thanks Brian ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Kernel oops while duming user core.
Scott Wood wrote: > On Thu, Jan 31, 2008 at 11:40:04AM -0600, Rune Torgersen wrote: > > Unable to handle kernel paging request for data at address 0x48024000 > > Faulting instruction address: 0xc000f0a0 > > Oops: Kernel access of bad area, sig: 11 [#1] > > PREEMPT Innovative Systems ApMax > > Does it happen without preempt? > > > Modules linked in: drv_wd(P) drv_scc devcom drv_pcir tipc drv_ss7 > > drv_auxcpu drv_leds(P) drv_ethsw proc_sysinfo(P) i2c_8266(P) > > NIP: c000f0a0 LR: c0011fec CTR: 0080 > > REGS: eebe9b70 TRAP: 0300 Tainted: P (2.6.24-test) > > Does it happen without the modules? I doubt the modules are the problem; there was a practically identical report from someone with an untainted 2.6.24-rc kernel a few weeks ago (see my first reply to Rune). > > > MSR: 9032 CR: 24004442 XER: > > DAR: 48024000, DSISR: 2000 > > Hmm, this doesn't look like a valid DSISR, so I'm guessing this was a TLB > miss that got redirected to DataAccess (or is there something that causes > DSRISR[2] to be set on 8280? I didn't see anything in the manual...). > However, SRR1 in that case seems to indicate a store, which dcbst shouldn't > generate (except on 8xx, according to the comment in update_mmu_cache). > > Do you have a simple test case that we could try to reproduce? I tried a > simple core dump on an 8280, and it worked. Is the crashing program multithreaded? The first report had firefox triggering the oops. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH] [POWERPC] Remove dead code at KernelAltiVec
Signed-off-by: Dale Farnsworth <[EMAIL PROTECTED]> --- This code doesn't seem to be referenced anywhere. arch/powerpc/kernel/head_32.S | 17 - arch/ppc/kernel/head.S| 17 - 2 files changed, 0 insertions(+), 34 deletions(-) diff --git a/arch/powerpc/kernel/head_32.S b/arch/powerpc/kernel/head_32.S index 0f4fac5..c16d135 100644 --- a/arch/powerpc/kernel/head_32.S +++ b/arch/powerpc/kernel/head_32.S @@ -763,23 +763,6 @@ load_up_altivec: b fast_exception_return /* - * AltiVec unavailable trap from kernel - print a message, but let - * the task use AltiVec in the kernel until it returns to user mode. - */ -KernelAltiVec: - lwz r3,_MSR(r1) - orisr3,r3,[EMAIL PROTECTED] - stw r3,_MSR(r1) /* enable use of AltiVec after return */ - lis r3,[EMAIL PROTECTED] - ori r3,r3,[EMAIL PROTECTED] - mr r4,r2 /* current */ - lwz r5,_NIP(r1) - bl printk - b ret_from_except -87:.string "AltiVec used in kernel (task=%p, pc=%x) \n" - .align 4,0 - -/* * giveup_altivec(tsk) * Disable AltiVec for the task given as the argument, * and save the AltiVec registers in its thread_struct. diff --git a/arch/ppc/kernel/head.S b/arch/ppc/kernel/head.S index 1b0ec72..e7e642b 100644 --- a/arch/ppc/kernel/head.S +++ b/arch/ppc/kernel/head.S @@ -701,23 +701,6 @@ load_up_altivec: b fast_exception_return /* - * AltiVec unavailable trap from kernel - print a message, but let - * the task use AltiVec in the kernel until it returns to user mode. - */ -KernelAltiVec: - lwz r3,_MSR(r1) - orisr3,r3,[EMAIL PROTECTED] - stw r3,_MSR(r1) /* enable use of AltiVec after return */ - lis r3,[EMAIL PROTECTED] - ori r3,r3,[EMAIL PROTECTED] - mr r4,r2 /* current */ - lwz r5,_NIP(r1) - bl printk - b ret_from_except -87:.string "AltiVec used in kernel (task=%p, pc=%x) \n" - .align 4,0 - -/* * giveup_altivec(tsk) * Disable AltiVec for the task given as the argument, * and save the AltiVec registers in its thread_struct. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [RFC] [POWERPC] bootwrapper: build multiple cuImages
On 01/30/2008 04:34 PM, Grant Likely wrote: > --- a/arch/powerpc/boot/Makefile > +++ b/arch/powerpc/boot/Makefile ... > $(obj)/zImage.ps3: vmlinux $(wrapper) $(wrapperbits) > $(srctree)/$(src)/dts/ps3.dts Seems like this could use $(dtstree). > $(STRIP) -s -R .comment $< -o vmlinux.strip > - $(call cmd,wrap,ps3,$(srctree)/$(src)/dts/ps3.dts,,) > + $(call cmd,wrap,ps3,$(dtstree)/ps3.dts,,) > > $(obj)/zImage.initrd.ps3: vmlinux $(wrapper) $(wrapperbits) > $(srctree)/$(src)/dts/ps3.dts $(obj)/ramdisk.image.gz Same here. > - $(call > cmd,wrap,ps3,$(srctree)/$(src)/dts/ps3.dts,,$(obj)/ramdisk.image.gz) > + $(call cmd,wrap,ps3,$(dtstree)/ps3.dts,,$(obj)/ramdisk.image.gz) ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Kernel oops while duming user core.
Scott Wood wrote: > Nathan Lynch wrote: >> Is the crashing program multithreaded? The first report had firefox >> triggering the oops. > > OK, I've got a test program that triggers it now. I'll see if I can > figure out what's going on. The problem seems to be that update_mmu_cache() is called on a guard page with no access rights. Changing update_mmu_cache() to always call flush_dcache_icache_page() fixes it, though a better performing fix would probably be to add an exception table entry for the dcbst. -Scott ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 1/2] Add RapidIO node into MPC8641HPCN dts file
Zhang Wei wrote:
> Signed-off-by: Zhang Wei <[EMAIL PROTECTED]>
> ---
> arch/powerpc/boot/dts/mpc8641_hpcn.dts | 13 +
> 1 files changed, 13 insertions(+), 0 deletions(-)
>
> diff --git a/arch/powerpc/boot/dts/mpc8641_hpcn.dts
> b/arch/powerpc/boot/dts/mpc8641_hpcn.dts
> index 556a9ca..1a0fce5 100644
> --- a/arch/powerpc/boot/dts/mpc8641_hpcn.dts
> +++ b/arch/powerpc/boot/dts/mpc8641_hpcn.dts
> @@ -25,6 +25,7 @@
> serial1 = &serial1;
> pci0 = &pci0;
> pci1 = &pci1;
> + rapidio0 = &rapidio0;
> };
>
> cpus {
> @@ -499,4 +500,16 @@
> 0 0010>;
> };
> };
> +
> + rapidio0: [EMAIL PROTECTED] {
> + #address-cells = <2>;
> + #size-cells = <2>;
> + compatible = "fsl,rapidio-delta";
> + reg = ;
> + ranges = <0 0 c000 0 2000>;
> + interrupt-parent = <&mpic>;
> + /* err_irq bell_outb_irq bell_inb_irq
> + msg1_tx_irq msg1_rx_irq msg2_tx_irq msg2_rx_irq */
> + interrupts = <30 2 31 2 32 2 35 2 36 2 37 2 38 2>;
> + };
> };
The 8641 DTS file has been converted to /dts-v1/ format now.
Please rewrite this patch with explicit hex numbers for
addresses, even if 0x0, and decimal for IRQs.
Thanks,
jdl
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
RE: Kernel oops while duming user core.
Scott Wood wrote: > Scott Wood wrote: >> Nathan Lynch wrote: >>> Is the crashing program multithreaded? The first report had firefox >>> triggering the oops. >> >> OK, I've got a test program that triggers it now. I'll see if I can >> figure out what's going on. > > The problem seems to be that update_mmu_cache() is called on a guard > page with no access rights. > > Changing update_mmu_cache() to always call flush_dcache_icache_page() > fixes it, though a better performing fix would probably be to add an > exception table entry for the dcbst. I can confirm that this seems to fix it. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
RE: [PATCH] [POWERPC] Xilinx: hwicap driver
> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of
Grant Likely
> Sent: Thursday, January 31, 2008 11:59 AM
> To: Stephen Neuendorffer
> Cc: linuxppc-dev@ozlabs.org; [EMAIL PROTECTED]
> Subject: Re: [PATCH] [POWERPC] Xilinx: hwicap driver
>
> On 1/31/08, Stephen Neuendorffer <[EMAIL PROTECTED]>
wrote:
> > This includes code for new fifo-based xps_hwicap in addition to the
> > older opb_hwicap, which has a significantly different interface.
The
> > common code between the two drivers is largely shared.
> >
> > Significant differences exists between this driver and what is
> > supported in the EDK drivers. In particular, most of the
> > architecture-specific code for reconfiguring individual FPGA
resources
> > has been removed. This functionality is likely better provided in a
> > user-space support library. In addition, read and write access is
> > supported. In addition, although the xps_hwicap cores support
> > interrupt-driver mode, this driver only supports polled operation,
in
> > order to make the code simpler, and since the interrupt processing
> > overhead is likely to slow down the throughput under Linux.
> >
> > Signed-off-by: Stephen Neuendorffer
<[EMAIL PROTECTED]>
>
> Comments below...
>
> Also, I'm not sure if drivers/char/xilinx_hwicap is the best place for
> this driver. drivers/misc/ might be better (but I'm not sure; poll
> other people on this)
I don't have strong opinions on this... If someone wants to say it
should be in drivers/misc, I'm more than happy to move it. However, it
doesn't seem like there is anything else that is a pure character device
there.
> Finally, buffer_icap and fifo_icap are not huge blocks of code. Will
> they be used by any other drivers? Can they be rolled into the
> xilinx_hwicap.c file?
They're not huge, but they are really independent from eachother.
Furthermore, I expect that future cores will have DMA capability to
increase bandwidth, which would result in a dma_icap file.
> Style comment: reverse the condition and bail with return -EINVAL at
> the test point. It will simplify the code and better match with
> common practice in the kernel.
good point, I'll fix them all.
> > +static ssize_t
> > +hwicap_read(struct file *file, char *buf, size_t count, loff_t
*ppos)
> > +{
> > + struct hwicap_drvdata *drvdata = file->private_data;
> > + ssize_t bytes_to_read = 0;
> > + u32 *kbuf;
> > + u32 words;
> > + u32 bytes_remaining;
> > + int status;
> > +
> > + if (drvdata->is_accessing)
> > + return -EBUSY;
> > +
> > + drvdata->is_accessing = 1;
>
> Race condition, you need to use a semaphore. Otherwise it is possible
> to get two processes (or even two threads of the same process) in the
> read() hook.
good point. On thinking about this more, does the whole function need
to be in a semaphore to protect against PREEMPT kernels?
> > +static int hwicap_open(struct inode *inode, struct file *file)
> > +{
> > + struct hwicap_drvdata *drvdata;
> > + int status;
> > +
> > + drvdata = container_of(inode->i_cdev, struct hwicap_drvdata,
cdev);
> > + if (drvdata->is_open)
> > + return -EBUSY;
> > +
> > + drvdata->is_open = 1;
>
> Also a race condition. Use a semaphore.
>
> Also, this isn't sufficient to prevent 2 processes from having the
> device open. If a process has already opened it and then calls
> fork(), then *both* processes will have it opened even though the open
> fop was only called once. (It might not matter for this particular
> driver as the use case is limited; but it is something you should be
> aware of.)
The fork I'm somewhat less concerned about, I think. If someone calls
fork(), then it's up to them to synchronize their code correctly and
only call close() once. The only reason to block the open is that it's
the simplest way to keep track of the state between reads and writes.
> > +static int __devinit hwicap_setup(struct device *dev, int id,
> > + const struct resource *regs_res,
> > + const struct hwicap_driver_config *config,
> > + const struct config_registers *config_regs)
> > +{
> > + dev_t devt;
> > + struct hwicap_drvdata *drvdata = NULL;
> > + int retval = 0;
> > +
> > + dev_info(dev, "Xilinx icap port driver\n");
> > +
> > + if (id < 0) {
> > + for (id = 0; id < HWICAP_DEVICES; id++)
> > + if (!probed_devices[id])
> > + break;
> > + }
> > + if (id < 0 || id >= HWICAP_DEVICES) {
> > + dev_err(dev, "%s%i too large\n", DRIVER_NAME, id);
> > + return -EINVAL;
> > + }
> > + if (probed_devices[id]) {
> > + dev_err(dev, "cannot assign to %s%i; it is already
in use\n",
> > + DRIVER_NAME, id);
> > + return -EBUSY;
> > + }
> > +
> > +
Re: Reminder: removal of arch/ppc
On Fri, Jan 25, 2008 at 10:55:25AM -0600, Kumar Gala wrote: > Just a reminder that the plan is to remove arch/ppc this summer (June > 2008). The following boards still existing over in arch/ppc. Some of > them have been ported over to arch/powerpc. If you care about one of > these boards and its not ported speak up (it helps if you have access > to the board). Also, if you know a given board is free to die of > bitrot let us know so we know not to worry about it: I guess I'm just not a nice guy but I say let them die. No need to worry. The code really isn't going anywhere -- git-checkout v2.6. and its back. /me's $0.02. Mark ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] [POWERPC] Xilinx: hwicap driver
On 1/31/08, Stephen Neuendorffer <[EMAIL PROTECTED]> wrote:
> > Also, this isn't sufficient to prevent 2 processes from having the
> > device open. If a process has already opened it and then calls
> > fork(), then *both* processes will have it opened even though the open
> > fop was only called once. (It might not matter for this particular
> > driver as the use case is limited; but it is something you should be
> > aware of.)
>
> The fork I'm somewhat less concerned about, I think. If someone calls
> fork(), then it's up to them to synchronize their code correctly and
> only call close() once. The only reason to block the open is that it's
> the simplest way to keep track of the state between reads and writes.
You're thinking of threads; not fork. When fork
is called you get a whole new process which has all the same file
descriptors open as the parent process. This is what the timeline
would look like:
p1: open(/dev/hwcap0)
--- open fop called here (and struct file is allocated)
p1: fork()
--- p2 is created
p1: do stuff
p2: do stuff
p1: close()
p2: do more stuff
p2: close()
--- release fop called here (and struct file is released)
Notice how close is called twice (the correct behavour) yet release is
only called once? :-) That means there are 2 processes sharing the
same file structure.
> > > +static int __devinit hwicap_setup(struct device *dev, int id,
> > > + const struct resource *regs_res,
> > > + const struct hwicap_driver_config *config,
> > > + const struct config_registers *config_regs)
> > > +{
> > > + dev_t devt;
> > > + struct hwicap_drvdata *drvdata = NULL;
> > > + int retval = 0;
> > > +
> > > + dev_info(dev, "Xilinx icap port driver\n");
> > > +
> > > + if (id < 0) {
> > > + for (id = 0; id < HWICAP_DEVICES; id++)
> > > + if (!probed_devices[id])
> > > + break;
> > > + }
> > > + if (id < 0 || id >= HWICAP_DEVICES) {
> > > + dev_err(dev, "%s%i too large\n", DRIVER_NAME, id);
> > > + return -EINVAL;
> > > + }
> > > + if (probed_devices[id]) {
> > > + dev_err(dev, "cannot assign to %s%i; it is already
> in use\n",
> > > + DRIVER_NAME, id);
> > > + return -EBUSY;
> > > + }
> > > +
> > > + probed_devices[id] = 1;
> >
> > Hmmm, I'm not thrilled with the fixed array of HWICAP devices. That
> > sort of thing just ends up causing headaches down the road. Can the
> > driver just allocate a new structure and the next available ID at
> > probe time? (I hold my nose every time I write something like the
> > above because I know I'm going to regret it later). sysfs/udev can
> > provide details about which one is which.
>
> Can you suggest a good driver to crib?
What I would do is use a static struct list_head to hold a list of all
instantiated devices. When you register a new device you can use
list_for_each_entry to look for a free id. That way you don't have to
preallocate an array for all the possible device numbers.
OTOH, how many of these devices are likely to be present on any one
bitstream? If it is only 1 or 2 then it might be that the overhead
isn't worth the savings. I won't complain if you decide it's better
the way it is now.
--
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: x86/non-x86: percpu, node ids, apic ids x86.git fixup
> So the percpu changes are innocent ... something else since 2.6.24 is > to blame. Only 5749 commits :-) I'll start bisecting. 12 bisections later ... nothing! I think I got lost in the maze. Bisection #5 had a crash, but it looked to be a very differnt crash (and looked to happen later than the bug I was hunting). So I marked that as "good" on the theory that it looked like this bug wasn't in the kernel. Same thing happened at bisection #9. But I ended up with: commit bfada697bd534d2c16fd07fbef3a4924c4d4e014 Author: Pavel Emelyanov <[EMAIL PROTECTED]> Date: Sun Dec 2 00:57:08 2007 +1100 [IPV4]: Use ctl paths to register devinet sysctls Which just looks too improbable to be the cause of the UP crash. Git won't revert it out from top of tree automatically so I can't easily test whether some weird magic means that this is the buggy commit. Perhaps the issue is another offset of object X in kernel w.r.t. object Y ... and so the good/bad choices in the bisection are actually pretty random depending on how much code is stuffed between X & Y at each bisection point. -Tony ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH] [POWERPC] pasemi: Fix thinko in dma_direct_ops setup
[POWERPC] pasemi: Fix thinko in dma_direct_ops setup
The first patch will just fall through and still set dma_data to a bad
value, make it return directly instead.
Signed-off-by: Olof Johansson <[EMAIL PROTECTED]>
---
Linus, thanks for picking up the patch so quickly. Unfortunately I
messed it up. Please apply this on top.
Thanks,
Olof
diff --git a/arch/powerpc/platforms/pasemi/iommu.c
b/arch/powerpc/platforms/pasemi/iommu.c
index c5cfd4b..5803f11 100644
--- a/arch/powerpc/platforms/pasemi/iommu.c
+++ b/arch/powerpc/platforms/pasemi/iommu.c
@@ -184,7 +184,7 @@ static void pci_dma_dev_setup_pasemi(struct pci_dev *dev)
if (dev->vendor == 0x1959 && dev->device == 0xa007 &&
!firmware_has_feature(FW_FEATURE_LPAR)) {
dev->dev.archdata.dma_ops = &dma_direct_ops;
- dev->dev.archdata.dma_data = 0;
+ return;
}
#endif
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
RE: [PATCH] [POWERPC] Xilinx: hwicap driver
> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of
Grant Likely
> Sent: Thursday, January 31, 2008 3:13 PM
> To: Stephen Neuendorffer
> Cc: linuxppc-dev@ozlabs.org; [EMAIL PROTECTED]
> Subject: Re: [PATCH] [POWERPC] Xilinx: hwicap driver
>
> On 1/31/08, Stephen Neuendorffer <[EMAIL PROTECTED]>
wrote:
> > > Also, this isn't sufficient to prevent 2 processes from having the
> > > device open. If a process has already opened it and then calls
> > > fork(), then *both* processes will have it opened even though the
open
> > > fop was only called once. (It might not matter for this
particular
> > > driver as the use case is limited; but it is something you should
be
> > > aware of.)
> >
> > The fork I'm somewhat less concerned about, I think. If someone
calls
> > fork(), then it's up to them to synchronize their code correctly and
> > only call close() once. The only reason to block the open is that
it's
> > the simplest way to keep track of the state between reads and
writes.
>
> You're thinking of threads; not fork. When fork
> is called you get a whole new process which has all the same file
> descriptors open as the parent process. This is what the timeline
> would look like:
>
> p1: open(/dev/hwcap0)
> --- open fop called here (and struct file is allocated)
> p1: fork()
> --- p2 is created
> p1: do stuff
> p2: do stuff
> p1: close()
> p2: do more stuff
> p2: close()
> --- release fop called here (and struct file is released)
>
> Notice how close is called twice (the correct behavour) yet release is
> only called once? :-) That means there are 2 processes sharing the
> same file structure.
Hmm... hadn't realized that. In most uses of fork I've seen/thought
of, the return value of fork is used to identify the parent and child
processes and typically the child code avoids accessing the open files
in order to avoid colliding output (and relies on the implicit close()
on exit). In any event, regardless of when close is called, all we
really care about is the release fop... Regardless, I'll be more
careful about distinguishing the close and the release in the future,
though :)
> > > > +static int __devinit hwicap_setup(struct device *dev, int id,
> > > > + const struct resource *regs_res,
> > > > + const struct hwicap_driver_config *config,
> > > > + const struct config_registers *config_regs)
> > > > +{
> > > > + dev_t devt;
> > > > + struct hwicap_drvdata *drvdata = NULL;
> > > > + int retval = 0;
> > > > +
> > > > + dev_info(dev, "Xilinx icap port driver\n");
> > > > +
> > > > + if (id < 0) {
> > > > + for (id = 0; id < HWICAP_DEVICES; id++)
> > > > + if (!probed_devices[id])
> > > > + break;
> > > > + }
> > > > + if (id < 0 || id >= HWICAP_DEVICES) {
> > > > + dev_err(dev, "%s%i too large\n", DRIVER_NAME,
id);
> > > > + return -EINVAL;
> > > > + }
> > > > + if (probed_devices[id]) {
> > > > + dev_err(dev, "cannot assign to %s%i; it is
already
> > in use\n",
> > > > + DRIVER_NAME, id);
> > > > + return -EBUSY;
> > > > + }
> > > > +
> > > > + probed_devices[id] = 1;
> > >
> > > Hmmm, I'm not thrilled with the fixed array of HWICAP devices.
That
> > > sort of thing just ends up causing headaches down the road. Can
the
> > > driver just allocate a new structure and the next available ID at
> > > probe time? (I hold my nose every time I write something like the
> > > above because I know I'm going to regret it later). sysfs/udev
can
> > > provide details about which one is which.
> >
> > Can you suggest a good driver to crib?
>
> What I would do is use a static struct list_head to hold a list of all
> instantiated devices. When you register a new device you can use
> list_for_each_entry to look for a free id. That way you don't have to
> preallocate an array for all the possible device numbers.
>
> OTOH, how many of these devices are likely to be present on any one
> bitstream? If it is only 1 or 2 then it might be that the overhead
> isn't worth the savings. I won't complain if you decide it's better
> the way it is now.
In this case, it is highly likely that there will be only 1 in the
system, and since the code is properly parameterized with respect to the
number of devices that are registered, I don't think it's worth it.
Steve
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
[RFC/PATCH v2] [POWERPC] bootwrapper: build multiple cuImages
From: Grant Likely <[EMAIL PROTECTED]> Currently, the kernel uses CONFIG_DEVICE_TREE to wrap a kernel image with a fdt blob which means for any given configuration only one dts file can be selected and so support for only one board can be built This patch moves the selection of the default .dts file out of the kernel config and into the bootwrapper makefile. The makefile chooses which images to build based on the kernel config and the dts source file name is taken directly from the image name. For example "cuImage.ebony" will use "ebony.dts" as the device tree source file. In addition, this patch allows a specific image to be requested from the command line by adding "cuImage.%" and "treeImage.%" targets to the list of valid built targets in arch/powerpc/Makefile. This allows the default dts selection to be overridden. Another advantage to this change is it allows a single defconfig to be supplied for all boards using the same chip family and only differing in the device tree. Important note: This patch adds two new zImage targets; zImage.dtb.% and zImage.dtb.initrd.% for zImages with embedded dtb files. Currently there are 5 platforms which require this: ps3, ep405, mpc885ads, ep88xc, adder875-redboot and ep8248e. This patch *changes the zImage filenames* for those platforms. ie. 'zImage.ps3' is now 'zImage.dtb.ps3'. This new zImage.dtb targets were added so that the .dts file could be part of the dependancies list for building them. Signed-off-by: Grant Likely <[EMAIL PROTECTED]> --- Please review and comment. I have not exhaustively tested this patch and I'm sure to have missed some boards. However, I think the concept is sound and will be a good change. This version fixes some bugs and adds new zImage.dtb and zImage.initrd.dtb targets. g. --- arch/powerpc/Kconfig | 19 - arch/powerpc/Makefile |9 +- arch/powerpc/boot/Makefile | 132 arch/powerpc/boot/cuboot-hpc2.c| 48 arch/powerpc/boot/cuboot-mpc7448hpc2.c | 48 arch/powerpc/boot/wrapper | 23 ++ 6 files changed, 157 insertions(+), 122 deletions(-) diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig index 2bf2f3f..4903796 100644 --- a/arch/powerpc/Kconfig +++ b/arch/powerpc/Kconfig @@ -415,25 +415,6 @@ config WANT_DEVICE_TREE bool default n -config DEVICE_TREE - string "Static device tree source file" - depends on WANT_DEVICE_TREE - help - This specifies the device tree source (.dts) file to be - compiled and included when building the bootwrapper. If a - relative filename is given, then it will be relative to - arch/powerpc/boot/dts. If you are not using the bootwrapper, - or do not need to build a dts into the bootwrapper, this - field is ignored. - - For example, this is required when building a cuImage target - for an older U-Boot, which cannot pass a device tree itself. - Such a kernel will not work with a newer U-Boot that tries to - pass a device tree (unless you tell it not to). If your U-Boot - does not mention a device tree in "help bootm", then use the - cuImage target and specify a device tree here. Otherwise, use - the uImage target and leave this field blank. - endmenu config ISA_DMA_API diff --git a/arch/powerpc/Makefile b/arch/powerpc/Makefile index f70df9b..6845482 100644 --- a/arch/powerpc/Makefile +++ b/arch/powerpc/Makefile @@ -151,14 +151,11 @@ core-$(CONFIG_XMON) += arch/powerpc/xmon/ drivers-$(CONFIG_OPROFILE) += arch/powerpc/oprofile/ # Default to zImage, override when needed -defaultimage-y := zImage -defaultimage-$(CONFIG_DEFAULT_UIMAGE) := uImage -KBUILD_IMAGE := $(defaultimage-y) -all: $(KBUILD_IMAGE) +all: zImage CPPFLAGS_vmlinux.lds := -Upowerpc -BOOT_TARGETS = zImage zImage.initrd uImage +BOOT_TARGETS = zImage zImage.initrd uImage treeImage.% cuImage.% PHONY += $(BOOT_TARGETS) @@ -180,7 +177,7 @@ define archhelp endef install: vdso_install - $(Q)$(MAKE) $(build)=$(boot) BOOTIMAGE=$(KBUILD_IMAGE) install + $(Q)$(MAKE) $(build)=$(boot) install vdso_install: ifeq ($(CONFIG_PPC64),y) diff --git a/arch/powerpc/boot/Makefile b/arch/powerpc/boot/Makefile index 122a270..bd2b98d 100644 --- a/arch/powerpc/boot/Makefile +++ b/arch/powerpc/boot/Makefile @@ -60,8 +60,9 @@ src-wlib := string.S crt0.S stdio.c main.c \ src-plat := of.c cuboot-52xx.c cuboot-824x.c cuboot-83xx.c cuboot-85xx.c holly.c \ cuboot-ebony.c treeboot-ebony.c prpmc2800.c \ ps3-head.S ps3-hvcall.S ps3.c treeboot-bamboo.c cuboot-8xx.c \ - cuboot-pq2.c cuboot-sequoia.c treeboot-walnut.c cuboot-bamboo.c \ - fixed-head.S ep88xc.c cuboot-hpc2.c ep405.c cuboot-taishan.c \ + cuboot-pq2.c cuboot-sequoia.c treeb
Re: Kernel oops while duming user core.
Rune Torgersen wrote: > Hi > > I get the following kernel core while a user program I have is dumping > core. > Any DIeas at what to look for? (this is runnign 2.6.24, arch/powerpc on > a 8280) > When runnign the program on 2.6.18 arch/ppc, the program gets a sig 11 > and dumps core. > On 2.6.24, I ghet the kernel oops, and then the program hangs sround > forever and is unkillable. Hmm, this is the second report of 2.6.24 crashing in __flush_dcache_icache during a core dump; see: http://ozlabs.org/pipermail/linuxppc-dev/2007-December/048662.html Is this easily recreatable? > > Unable to handle kernel paging request for data at address 0x48024000 > Faulting instruction address: 0xc000ef88 > Oops: Kernel access of bad area, sig: 11 [#1] > PREEMPT Innovative Systems ApMax > Modules linked in: drv_wd(P) drv_scc devcom drv_pcir tipc drv_ss7 > drv_auxcpu drv_leds(P) drv_ethsw proc_sysinfo(P) i2c_8266(P) > NIP: c000ef88 LR: c0012180 CTR: 0080 > REGS: eebc9b70 TRAP: 0300 Tainted: P (2.6.24) > MSR: 9032 CR: 24004442 XER: > DAR: 48024000, DSISR: 2000 > TASK = eebac3c0[3131] 'armd' THREAD: eebc8000 > GPR00: ee9b7d00 eebc9c20 eebac3c0 48024000 0080 399a4181 48024000 > > GPR08: 399a4181 ee9b7d00 c200 44004422 10100f38 ee82fc00 > bfff > GPR16: ef377060 0030 ee9b7d00 eebc9cdc 0011 eebc9cd8 > eeb96480 > GPR24: ee9b7d00 399a4181 48024000 eeb9a370 eeb9a370 399a4181 48024000 > c2733480 > NIP [c000ef88] __flush_dcache_icache+0x14/0x40 > LR [c0012180] update_mmu_cache+0x74/0x114 > Call Trace: > [eebc9c20] [eebc8000] 0xeebc8000 (unreliable) > [eebc9c40] [c005d060] handle_mm_fault+0x630/0xbc0 > [eebc9c80] [c005d9e4] get_user_pages+0x3f4/0x4fc > [eebc9cd0] [c00aa7c4] elf_core_dump+0x9a4/0xc5c > [eebc9d60] [c00779e4] do_coredump+0x6e0/0x748 > [eebc9e50] [c002a5b0] get_signal_to_deliver+0x40c/0x45c > [eebc9e80] [c0008ce8] do_signal+0x50/0x294 > [eebc9f40] [c000fb98] do_user_signal+0x74/0xc4 > --- Exception: 300 at 0x10044efc > LR = 0x10044ec0 > Instruction dump: > 4d820020 7c8903a6 7c001bac 38630020 4200fff8 7c0004ac 4e800020 6000 > 54630026 38800080 7c8903a6 7c661b78 <7c00186c> 38630020 4200fff8 > 7c0004ac > ---[ end trace 97db37eaf213da3c ]--- > note: armd[3131] exited with preempt_count 2 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH] powerpc: add rtc node to mpc8313erdb dts
the 8313 rdb has a ds1339 at address 0x68.
Signed-off-by: Kim Phillips <[EMAIL PROTECTED]>
---
arch/powerpc/boot/dts/mpc8313erdb.dts |4
1 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/arch/powerpc/boot/dts/mpc8313erdb.dts
b/arch/powerpc/boot/dts/mpc8313erdb.dts
index 2d6653f..e1f0dca 100644
--- a/arch/powerpc/boot/dts/mpc8313erdb.dts
+++ b/arch/powerpc/boot/dts/mpc8313erdb.dts
@@ -118,6 +118,10 @@
interrupts = <14 0x8>;
interrupt-parent = <&ipic>;
dfsrr;
+ [EMAIL PROTECTED] {
+ compatible = "dallas,ds1339";
+ reg = <0x68>;
+ };
};
[EMAIL PROTECTED] {
--
1.5.2.2
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH 0/5] ehea checkpatch fixups
A small set of fixups for checkpatch. Based on upstream pull from a few hours ago. drivers/net/ehea/ehea.h |3 + drivers/net/ehea/ehea_ethtool.c |4 +- drivers/net/ehea/ehea_hw.h |8 +- drivers/net/ehea/ehea_main.c| 87 +++-- drivers/net/ehea/ehea_phyp.c| 158 +++--- drivers/net/ehea/ehea_phyp.h| 22 +++--- drivers/net/ehea/ehea_qmr.c | 32 drivers/net/ehea/ehea_qmr.h | 16 ++-- 8 files changed, 169 insertions(+), 161 deletions(-) ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH 2/5] ehea: fix ethtool checkpatch complaints
Cc: Jan-Bernd Themann <[EMAIL PROTECTED]>
Signed-off-by: Doug Maxey <[EMAIL PROTECTED]>
---
drivers/net/ehea/ehea_ethtool.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/ehea/ehea_ethtool.c b/drivers/net/ehea/ehea_ethtool.c
index 679f40e..d768852 100644
--- a/drivers/net/ehea/ehea_ethtool.c
+++ b/drivers/net/ehea/ehea_ethtool.c
@@ -40,7 +40,7 @@ static int ehea_get_settings(struct net_device *dev, struct
ethtool_cmd *cmd)
return ret;
if (netif_carrier_ok(dev)) {
- switch(port->port_speed) {
+ switch (port->port_speed) {
case EHEA_SPEED_10M: cmd->speed = SPEED_10; break;
case EHEA_SPEED_100M: cmd->speed = SPEED_100; break;
case EHEA_SPEED_1G: cmd->speed = SPEED_1000; break;
@@ -78,7 +78,7 @@ static int ehea_set_settings(struct net_device *dev, struct
ethtool_cmd *cmd)
goto doit;
}
- switch(cmd->speed) {
+ switch (cmd->speed) {
case SPEED_10:
if (cmd->duplex == DUPLEX_FULL)
sp = H_SPEED_10M_F;
--
1.5.3.8
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH 4/5] ehea: fix phyp checkpatch complaints
Cc: Jan-Bernd Themann <[EMAIL PROTECTED]>
Signed-off-by: Doug Maxey <[EMAIL PROTECTED]>
---
drivers/net/ehea/ehea_phyp.c | 158 +-
drivers/net/ehea/ehea_phyp.h | 22 +++---
2 files changed, 90 insertions(+), 90 deletions(-)
diff --git a/drivers/net/ehea/ehea_phyp.c b/drivers/net/ehea/ehea_phyp.c
index 95c4a7f..156eb63 100644
--- a/drivers/net/ehea/ehea_phyp.c
+++ b/drivers/net/ehea/ehea_phyp.c
@@ -6,9 +6,9 @@
* (C) Copyright IBM Corp. 2006
*
* Authors:
- * Christoph Raisch <[EMAIL PROTECTED]>
- * Jan-Bernd Themann <[EMAIL PROTECTED]>
- * Thomas Klein <[EMAIL PROTECTED]>
+ * Christoph Raisch <[EMAIL PROTECTED]>
+ * Jan-Bernd Themann <[EMAIL PROTECTED]>
+ * Thomas Klein <[EMAIL PROTECTED]>
*
*
* This program is free software; you can redistribute it and/or modify
@@ -38,11 +38,11 @@ static inline u16 get_order_of_qentries(u16 queue_entries)
}
/* Defines for H_CALL H_ALLOC_RESOURCE */
-#define H_ALL_RES_TYPE_QP1
-#define H_ALL_RES_TYPE_CQ2
-#define H_ALL_RES_TYPE_EQ3
-#define H_ALL_RES_TYPE_MR5
-#define H_ALL_RES_TYPE_MW6
+#define H_ALL_RES_TYPE_QP 1
+#define H_ALL_RES_TYPE_CQ 2
+#define H_ALL_RES_TYPE_EQ 3
+#define H_ALL_RES_TYPE_MR 5
+#define H_ALL_RES_TYPE_MW 6
static long ehea_plpar_hcall_norets(unsigned long opcode,
unsigned long arg1,
@@ -137,77 +137,77 @@ u64 ehea_h_query_ehea_qp(const u64 adapter_handle, const
u8 qp_category,
const u64 qp_handle, const u64 sel_mask, void *cb_addr)
{
return ehea_plpar_hcall_norets(H_QUERY_HEA_QP,
- adapter_handle, /* R4 */
- qp_category, /* R5 */
- qp_handle, /* R6 */
- sel_mask,/* R7 */
+ adapter_handle, /* R4 */
+ qp_category, /* R5 */
+ qp_handle, /* R6 */
+ sel_mask,/* R7 */
virt_to_abs(cb_addr),/* R8 */
0, 0);
}
/* input param R5 */
-#define H_ALL_RES_QP_EQPO EHEA_BMASK_IBM(9, 11)
-#define H_ALL_RES_QP_QPP EHEA_BMASK_IBM(12, 12)
-#define H_ALL_RES_QP_RQR EHEA_BMASK_IBM(13, 15)
-#define H_ALL_RES_QP_EQEG EHEA_BMASK_IBM(16, 16)
-#define H_ALL_RES_QP_LL_QPEHEA_BMASK_IBM(17, 17)
-#define H_ALL_RES_QP_DMA128 EHEA_BMASK_IBM(19, 19)
-#define H_ALL_RES_QP_HSM EHEA_BMASK_IBM(20, 21)
-#define H_ALL_RES_QP_SIGT EHEA_BMASK_IBM(22, 23)
-#define H_ALL_RES_QP_TENURE EHEA_BMASK_IBM(48, 55)
-#define H_ALL_RES_QP_RES_TYP EHEA_BMASK_IBM(56, 63)
+#define H_ALL_RES_QP_EQPOEHEA_BMASK_IBM(9, 11)
+#define H_ALL_RES_QP_QPP EHEA_BMASK_IBM(12, 12)
+#define H_ALL_RES_QP_RQR EHEA_BMASK_IBM(13, 15)
+#define H_ALL_RES_QP_EQEGEHEA_BMASK_IBM(16, 16)
+#define H_ALL_RES_QP_LL_QP EHEA_BMASK_IBM(17, 17)
+#define H_ALL_RES_QP_DMA128 EHEA_BMASK_IBM(19, 19)
+#define H_ALL_RES_QP_HSM EHEA_BMASK_IBM(20, 21)
+#define H_ALL_RES_QP_SIGTEHEA_BMASK_IBM(22, 23)
+#define H_ALL_RES_QP_TENURE EHEA_BMASK_IBM(48, 55)
+#define H_ALL_RES_QP_RES_TYP EHEA_BMASK_IBM(56, 63)
/* input param R9 */
-#define H_ALL_RES_QP_TOKENEHEA_BMASK_IBM(0, 31)
-#define H_ALL_RES_QP_PD EHEA_BMASK_IBM(32,63)
+#define H_ALL_RES_QP_TOKEN EHEA_BMASK_IBM(0, 31)
+#define H_ALL_RES_QP_PD EHEA_BMASK_IBM(32, 63)
/* input param R10 */
-#define H_ALL_RES_QP_MAX_SWQE EHEA_BMASK_IBM(4, 7)
-#define H_ALL_RES_QP_MAX_R1WQEEHEA_BMASK_IBM(12, 15)
-#define H_ALL_RES_QP_MAX_R2WQEEHEA_BMASK_IBM(20, 23)
-#define H_ALL_RES_QP_MAX_R3WQEEHEA_BMASK_IBM(28, 31)
+#define H_ALL_RES_QP_MAX_SWQEEHEA_BMASK_IBM(4, 7)
+#define H_ALL_RES_QP_MAX_R1WQE EHEA_BMASK_IBM(12, 15)
+#define H_ALL_RES_QP_MAX_R2WQE EHEA_BMASK_IBM(20, 23)
+#define H_ALL_RES_QP_MAX_R3WQE EHEA_BMASK_IBM(28, 31)
/* Max Send Scatter Gather Elements */
-#define H_ALL_RES_QP_MAX_SSGE EHEA_BMASK_IBM(37, 39)
-#define H_ALL_RES_QP_MAX_R1SGEEHEA_BMASK_IBM(45, 47)
+#define H_ALL_RES_QP_MAX_SSGEEHEA_BMASK_IBM(37, 39)
+#define H_ALL_RES_QP_MAX_R1SGE EHEA_BMASK_IBM(45, 47)
/* Max Receive SG Elements RQ1 */
-#define H_ALL_RES_QP_MAX_R2SGEEHEA_BMASK_IBM(53, 55)
-#define H_ALL_RES_QP_MAX_R3SGEEHEA_BMASK_IBM(61, 63)
+#define H_ALL_RES_QP_MAX_R2SGE EHEA_BMASK_IBM(53, 55)
+#define H_ALL_RES_QP_MAX_R3SGE EHEA_BMASK_IBM(61, 63)
/* input param R11 */
-#define H_ALL_RES_QP_SWQE_IDL EHEA_BMASK_IBM(0, 7)
+#define H_ALL_RES_QP_SWQE_IDLEHEA_BMASK_IBM(0, 7)
/* max swq
[PATCH 3/5] ehea: fix main checkpatch complaints
Cc: Jan-Bernd Themann <[EMAIL PROTECTED]>
Signed-off-by: Doug Maxey <[EMAIL PROTECTED]>
---
drivers/net/ehea/ehea_main.c | 87 ++
1 files changed, 46 insertions(+), 41 deletions(-)
diff --git a/drivers/net/ehea/ehea_main.c b/drivers/net/ehea/ehea_main.c
index 869e160..99ea46a 100644
--- a/drivers/net/ehea/ehea_main.c
+++ b/drivers/net/ehea/ehea_main.c
@@ -6,9 +6,9 @@
* (C) Copyright IBM Corp. 2006
*
* Authors:
- * Christoph Raisch <[EMAIL PROTECTED]>
- * Jan-Bernd Themann <[EMAIL PROTECTED]>
- * Thomas Klein <[EMAIL PROTECTED]>
+ * Christoph Raisch <[EMAIL PROTECTED]>
+ * Jan-Bernd Themann <[EMAIL PROTECTED]>
+ * Thomas Klein <[EMAIL PROTECTED]>
*
*
* This program is free software; you can redistribute it and/or modify
@@ -54,11 +54,11 @@ static int rq1_entries = EHEA_DEF_ENTRIES_RQ1;
static int rq2_entries = EHEA_DEF_ENTRIES_RQ2;
static int rq3_entries = EHEA_DEF_ENTRIES_RQ3;
static int sq_entries = EHEA_DEF_ENTRIES_SQ;
-static int use_mcs = 0;
-static int use_lro = 0;
+static int use_mcs;
+static int use_lro;
static int lro_max_aggr = EHEA_LRO_MAX_AGGR;
static int num_tx_qps = EHEA_NUM_TX_QP;
-static int prop_carrier_state = 0;
+static int prop_carrier_state;
module_param(msg_level, int, 0);
module_param(rq1_entries, int, 0);
@@ -94,9 +94,9 @@ MODULE_PARM_DESC(lro_max_aggr, " LRO: Max packets to be
aggregated. Default = "
MODULE_PARM_DESC(use_lro, " Large Receive Offload, 1: enable, 0: disable, "
"Default = 0");
-static int port_name_cnt = 0;
+static int port_name_cnt;
static LIST_HEAD(adapter_list);
-u64 ehea_driver_flags = 0;
+u64 ehea_driver_flags;
struct work_struct ehea_rereg_mr_task;
struct semaphore dlpar_mem_lock;
@@ -121,12 +121,13 @@ static struct of_platform_driver ehea_driver = {
.remove = ehea_remove,
};
-void ehea_dump(void *adr, int len, char *msg) {
+void ehea_dump(void *adr, int len, char *msg)
+{
int x;
unsigned char *deb = adr;
for (x = 0; x < len; x += 16) {
printk(DRV_NAME " %s adr=%p ofs=%04x %016lx %016lx\n", msg,
- deb, x, *((u64*)&deb[0]), *((u64*)&deb[8]));
+ deb, x, *((u64 *)&deb[0]), *((u64 *)&deb[8]));
deb += 16;
}
}
@@ -518,7 +519,8 @@ static int ehea_proc_rwqes(struct net_device *dev,
last_wqe_index = wqe_index;
rmb();
if (!ehea_check_cqe(cqe, &rq)) {
- if (rq == 1) { /* LL RQ1 */
+ if (rq == 1) {
+ /* LL RQ1 */
skb = get_skb_by_index_ll(skb_arr_rq1,
skb_arr_rq1_len,
wqe_index);
@@ -531,10 +533,11 @@ static int ehea_proc_rwqes(struct net_device *dev,
if (!skb)
break;
}
- skb_copy_to_linear_data(skb, ((char*)cqe) + 64,
+ skb_copy_to_linear_data(skb, ((char *)cqe) + 64,
cqe->num_bytes_transfered - 4);
ehea_fill_skb(dev, skb, cqe);
- } else if (rq == 2) { /* RQ2 */
+ } else if (rq == 2) {
+ /* RQ2 */
skb = get_skb_by_index(skb_arr_rq2,
skb_arr_rq2_len, cqe);
if (unlikely(!skb)) {
@@ -544,7 +547,8 @@ static int ehea_proc_rwqes(struct net_device *dev,
}
ehea_fill_skb(dev, skb, cqe);
processed_rq2++;
- } else { /* RQ3 */
+ } else {
+ /* RQ3 */
skb = get_skb_by_index(skb_arr_rq3,
skb_arr_rq3_len, cqe);
if (unlikely(!skb)) {
@@ -592,7 +596,7 @@ static struct ehea_cqe *ehea_proc_cqes(struct ehea_port_res
*pr, int my_quota)
unsigned long flags;
cqe = ehea_poll_cq(send_cq);
- while(cqe && (quota > 0)) {
+ while (cqe && (quota > 0)) {
ehea_inc_cq(send_cq);
cqe_counter++;
@@ -643,7 +647,8 @@ static struct ehea_cqe *ehea_proc_cqes(struct ehea_port_res
*pr, int my_quota)
static int ehea_poll(struct napi_struct *napi, int budget)
{
- struct ehea_port_res *pr = container_of(napi, struct ehea_port_res,
napi);
+ struct ehea_port_res *pr = container_of(napi, struct ehea_port_res,
+ napi);
struct net_device *dev = pr->
[PATCH 5/5] ehea: fix qmr checkpatch complaints
Cc: Jan-Bernd Themann <[EMAIL PROTECTED]>
Signed-off-by: Doug Maxey <[EMAIL PROTECTED]>
---
drivers/net/ehea/ehea_qmr.c | 32
drivers/net/ehea/ehea_qmr.h | 16
2 files changed, 24 insertions(+), 24 deletions(-)
diff --git a/drivers/net/ehea/ehea_qmr.c b/drivers/net/ehea/ehea_qmr.c
index 83b7643..d522e90 100644
--- a/drivers/net/ehea/ehea_qmr.c
+++ b/drivers/net/ehea/ehea_qmr.c
@@ -33,8 +33,6 @@
struct ehea_busmap ehea_bmap = { 0, 0, NULL };
-extern u64 ehea_driver_flags;
-extern struct work_struct ehea_rereg_mr_task;
static void *hw_qpageit_get_inc(struct hw_queue *queue)
@@ -65,7 +63,7 @@ static int hw_queue_ctor(struct hw_queue *queue, const u32
nr_of_pages,
}
queue->queue_length = nr_of_pages * pagesize;
- queue->queue_pages = kmalloc(nr_of_pages * sizeof(void*), GFP_KERNEL);
+ queue->queue_pages = kmalloc(nr_of_pages * sizeof(void *), GFP_KERNEL);
if (!queue->queue_pages) {
ehea_error("no mem for queue_pages");
return -ENOMEM;
@@ -78,11 +76,11 @@ static int hw_queue_ctor(struct hw_queue *queue, const u32
nr_of_pages,
*/
i = 0;
while (i < nr_of_pages) {
- u8 *kpage = (u8*)get_zeroed_page(GFP_KERNEL);
+ u8 *kpage = (u8 *)get_zeroed_page(GFP_KERNEL);
if (!kpage)
goto out_nomem;
for (k = 0; k < pages_per_kpage && i < nr_of_pages; k++) {
- (queue->queue_pages)[i] = (struct ehea_page*)kpage;
+ (queue->queue_pages)[i] = (struct ehea_page *)kpage;
kpage += pagesize;
i++;
}
@@ -235,8 +233,8 @@ int ehea_destroy_cq(struct ehea_cq *cq)
return 0;
hcp_epas_dtor(&cq->epas);
-
- if ((hret = ehea_destroy_cq_res(cq, NORMAL_FREE)) == H_R_STATE) {
+ hret = ehea_destroy_cq_res(cq, NORMAL_FREE);
+ if (hret == H_R_STATE) {
ehea_error_data(cq->adapter, cq->fw_handle);
hret = ehea_destroy_cq_res(cq, FORCE_FREE);
}
@@ -301,13 +299,13 @@ struct ehea_eq *ehea_create_eq(struct ehea_adapter
*adapter,
if (i == (eq->attr.nr_pages - 1)) {
/* last page */
vpage = hw_qpageit_get_inc(&eq->hw_queue);
- if ((hret != H_SUCCESS) || (vpage)) {
+ if ((hret != H_SUCCESS) || (vpage))
goto out_kill_hwq;
- }
+
} else {
- if ((hret != H_PAGE_REGISTERED) || (!vpage)) {
+ if ((hret != H_PAGE_REGISTERED) || (!vpage))
goto out_kill_hwq;
- }
+
}
}
@@ -331,7 +329,7 @@ struct ehea_eqe *ehea_poll_eq(struct ehea_eq *eq)
unsigned long flags;
spin_lock_irqsave(&eq->spinlock, flags);
- eqe = (struct ehea_eqe*)hw_eqit_eq_get_inc_valid(&eq->hw_queue);
+ eqe = (struct ehea_eqe *)hw_eqit_eq_get_inc_valid(&eq->hw_queue);
spin_unlock_irqrestore(&eq->spinlock, flags);
return eqe;
@@ -364,7 +362,8 @@ int ehea_destroy_eq(struct ehea_eq *eq)
hcp_epas_dtor(&eq->epas);
- if ((hret = ehea_destroy_eq_res(eq, NORMAL_FREE)) == H_R_STATE) {
+ hret = ehea_destroy_eq_res(eq, NORMAL_FREE);
+ if (hret == H_R_STATE) {
ehea_error_data(eq->adapter, eq->fw_handle);
hret = ehea_destroy_eq_res(eq, FORCE_FREE);
}
@@ -546,7 +545,8 @@ int ehea_destroy_qp(struct ehea_qp *qp)
hcp_epas_dtor(&qp->epas);
- if ((hret = ehea_destroy_qp_res(qp, NORMAL_FREE)) == H_R_STATE) {
+ hret = ehea_destroy_qp_res(qp, NORMAL_FREE);
+ if (hret == H_R_STATE) {
ehea_error_data(qp->adapter, qp->fw_handle);
hret = ehea_destroy_qp_res(qp, FORCE_FREE);
}
@@ -559,7 +559,7 @@ int ehea_destroy_qp(struct ehea_qp *qp)
return 0;
}
-int ehea_create_busmap( void )
+int ehea_create_busmap(void)
{
u64 vaddr = EHEA_BUSMAP_START;
unsigned long high_section_index = 0;
@@ -595,7 +595,7 @@ int ehea_create_busmap( void )
return 0;
}
-void ehea_destroy_busmap( void )
+void ehea_destroy_busmap(void)
{
vfree(ehea_bmap.vaddr);
}
diff --git a/drivers/net/ehea/ehea_qmr.h b/drivers/net/ehea/ehea_qmr.h
index bc62d38..0bb6f92 100644
--- a/drivers/net/ehea/ehea_qmr.h
+++ b/drivers/net/ehea/ehea_qmr.h
@@ -41,8 +41,8 @@
#define EHEA_SECTSIZE (1UL << 24)
#define EHEA_PAGES_PER_SECTION (EHEA_SECTSIZE >> EHEA_PAGESHIFT)
-#if (1UL << SECTION_SIZE_BITS) < EHEA_SECTSIZE
-#error eHEA module can't work if kernel sectionsize < ehea sectionsize
+#if ((1UL << SECTION_SIZE_BITS) < EHEA_SECTSIZE)
+#error eHEA module cannot work if kernel sectionsize < ehea sectionsize
#endif
/* S
[PATCH 1/5] ehea: fix ehea.h checkpatch complaints
Cc: Jan-Bernd Themann <[EMAIL PROTECTED]> Signed-off-by: Doug Maxey <[EMAIL PROTECTED]> --- drivers/net/ehea/ehea.h|3 +++ drivers/net/ehea/ehea_hw.h |8 2 files changed, 7 insertions(+), 4 deletions(-) diff --git a/drivers/net/ehea/ehea.h b/drivers/net/ehea/ehea.h index 5f82a46..88fb53e 100644 --- a/drivers/net/ehea/ehea.h +++ b/drivers/net/ehea/ehea.h @@ -458,4 +458,7 @@ void ehea_set_ethtool_ops(struct net_device *netdev); int ehea_sense_port_attr(struct ehea_port *port); int ehea_set_portspeed(struct ehea_port *port, u32 port_speed); +extern u64 ehea_driver_flags; +extern struct work_struct ehea_rereg_mr_task; + #endif /* __EHEA_H__ */ diff --git a/drivers/net/ehea/ehea_hw.h b/drivers/net/ehea/ehea_hw.h index 1af7ca4..567981b 100644 --- a/drivers/net/ehea/ehea_hw.h +++ b/drivers/net/ehea/ehea_hw.h @@ -29,10 +29,10 @@ #ifndef __EHEA_HW_H__ #define __EHEA_HW_H__ -#define QPX_SQA_VALUE EHEA_BMASK_IBM(48,63) -#define QPX_RQ1A_VALUE EHEA_BMASK_IBM(48,63) -#define QPX_RQ2A_VALUE EHEA_BMASK_IBM(48,63) -#define QPX_RQ3A_VALUE EHEA_BMASK_IBM(48,63) +#define QPX_SQA_VALUE EHEA_BMASK_IBM(48, 63) +#define QPX_RQ1A_VALUE EHEA_BMASK_IBM(48, 63) +#define QPX_RQ2A_VALUE EHEA_BMASK_IBM(48, 63) +#define QPX_RQ3A_VALUE EHEA_BMASK_IBM(48, 63) #define QPTEMM_OFFSET(x) offsetof(struct ehea_qptemm, x) -- 1.5.3.8 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 0/5] ehea checkpatch fixups
Doug Maxey wrote: > > A small set of fixups for checkpatch. > > Based on upstream pull from a few hours ago. Er, ehea doesn't even build right now[1], maybe that could get fixed first? :-) [1] http://lkml.org/lkml/2008/1/28/337 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
RE: [PATCH 1/2] Add RapidIO node into MPC8641HPCN dts file
Hi, Jon,
> -Original Message-
> From: Loeliger Jon
>
> Zhang Wei wrote:
> > Signed-off-by: Zhang Wei <[EMAIL PROTECTED]>
> > ---
> > arch/powerpc/boot/dts/mpc8641_hpcn.dts | 13 +
> > 1 files changed, 13 insertions(+), 0 deletions(-)
> >
> > diff --git a/arch/powerpc/boot/dts/mpc8641_hpcn.dts
> b/arch/powerpc/boot/dts/mpc8641_hpcn.dts
> > index 556a9ca..1a0fce5 100644
> > --- a/arch/powerpc/boot/dts/mpc8641_hpcn.dts
> > +++ b/arch/powerpc/boot/dts/mpc8641_hpcn.dts
> > @@ -25,6 +25,7 @@
> > serial1 = &serial1;
> > pci0 = &pci0;
> > pci1 = &pci1;
> > + rapidio0 = &rapidio0;
> > };
> >
> > cpus {
> > @@ -499,4 +500,16 @@
> > 0 0010>;
> > };
> > };
> > +
> > + rapidio0: [EMAIL PROTECTED] {
> > + #address-cells = <2>;
> > + #size-cells = <2>;
> > + compatible = "fsl,rapidio-delta";
> > + reg = ;
> > + ranges = <0 0 c000 0 2000>;
> > + interrupt-parent = <&mpic>;
> > + /* err_irq bell_outb_irq bell_inb_irq
> > + msg1_tx_irq msg1_rx_irq msg2_tx_irq
> msg2_rx_irq */
> > + interrupts = <30 2 31 2 32 2 35 2 36 2 37 2 38 2>;
> > + };
> > };
>
> The 8641 DTS file has been converted to /dts-v1/ format now.
> Please rewrite this patch with explicit hex numbers for
> addresses, even if 0x0, and decimal for IRQs.
>
Thanks! I'm dropped by fashion. :) I'll re-do them.
Cheers!
Wei.
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
RE: [PATCH 1/2] Add RapidIO node into MPC8641HPCN dts file
> -Original Message-
> From: Loeliger Jon
>
> Zhang Wei wrote:
> > Signed-off-by: Zhang Wei <[EMAIL PROTECTED]>
> > ---
> > arch/powerpc/boot/dts/mpc8641_hpcn.dts | 13 +
> > 1 files changed, 13 insertions(+), 0 deletions(-)
> >
> > diff --git a/arch/powerpc/boot/dts/mpc8641_hpcn.dts
> b/arch/powerpc/boot/dts/mpc8641_hpcn.dts
> > index 556a9ca..1a0fce5 100644
> > --- a/arch/powerpc/boot/dts/mpc8641_hpcn.dts
> > +++ b/arch/powerpc/boot/dts/mpc8641_hpcn.dts
>
> > @@ -499,4 +500,16 @@
> > 0 0010>;
> > };
> > };
> > +
> > + rapidio0: [EMAIL PROTECTED] {
> > + #address-cells = <2>;
> > + #size-cells = <2>;
> > + compatible = "fsl,rapidio-delta";
> > + reg = ;
> > + ranges = <0 0 c000 0 2000>;
> > + interrupt-parent = <&mpic>;
> > + /* err_irq bell_outb_irq bell_inb_irq
> > + msg1_tx_irq msg1_rx_irq msg2_tx_irq
> msg2_rx_irq */
> > + interrupts = <30 2 31 2 32 2 35 2 36 2 37 2 38 2>;
> > + };
> > };
>
> Have updates to the booting-without-of.txt file for
> been made or proposed for the RapidIO node definition?
>
I remember Kumar has a patch for RapidIO node of booting-without-of.txt, is it?
Cheers!
Wei.
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 1/2] Add RapidIO node into MPC8641HPCN dts file
On Jan 31, 2008, at 9:21 PM, Zhang Wei wrote:
>
>
>> -Original Message-
>> From: Loeliger Jon
>>
>> Zhang Wei wrote:
>>> Signed-off-by: Zhang Wei <[EMAIL PROTECTED]>
>>> ---
>>> arch/powerpc/boot/dts/mpc8641_hpcn.dts | 13 +
>>> 1 files changed, 13 insertions(+), 0 deletions(-)
>>>
>>> diff --git a/arch/powerpc/boot/dts/mpc8641_hpcn.dts
>> b/arch/powerpc/boot/dts/mpc8641_hpcn.dts
>>> index 556a9ca..1a0fce5 100644
>>> --- a/arch/powerpc/boot/dts/mpc8641_hpcn.dts
>>> +++ b/arch/powerpc/boot/dts/mpc8641_hpcn.dts
>>
>>> @@ -499,4 +500,16 @@
>>> 0 0010>;
>>> };
>>> };
>>> +
>>> + rapidio0: [EMAIL PROTECTED] {
>>> + #address-cells = <2>;
>>> + #size-cells = <2>;
>>> + compatible = "fsl,rapidio-delta";
>>> + reg = ;
>>> + ranges = <0 0 c000 0 2000>;
>>> + interrupt-parent = <&mpic>;
>>> + /* err_irq bell_outb_irq bell_inb_irq
>>> + msg1_tx_irq msg1_rx_irq msg2_tx_irq
>> msg2_rx_irq */
>>> + interrupts = <30 2 31 2 32 2 35 2 36 2 37 2 38 2>;
>>> + };
>>> };
>>
>> Have updates to the booting-without-of.txt file for
>> been made or proposed for the RapidIO node definition?
>>
> I remember Kumar has a patch for RapidIO node of booting-without-
> of.txt, is it?
I do.. I'll post it and update the .dts patch once I sort through all
the patches.
- k
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Reminder: removal of arch/ppc
On Jan 31, 2008, at 4:54 PM, Mark A. Greer wrote: > On Fri, Jan 25, 2008 at 10:55:25AM -0600, Kumar Gala wrote: >> Just a reminder that the plan is to remove arch/ppc this summer (June >> 2008). The following boards still existing over in arch/ppc. Some >> of >> them have been ported over to arch/powerpc. If you care about one of >> these boards and its not ported speak up (it helps if you have access >> to the board). Also, if you know a given board is free to die of >> bitrot let us know so we know not to worry about it: > > I guess I'm just not a nice guy but I say let them die. No need > to worry. The code really isn't going anywhere -- git-checkout > v2.6. and its back. > > /me's $0.02. this is where I poke you about the sandpoint port ;) - k ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
RE: [PATCH 4/6] Add multi mport support.
Hi, Phil, > -Original Message- > From: Phil Terry [mailto:[EMAIL PROTECTED] > > On Thu, 2008-01-31 at 14:30 +0800, Zhang Wei wrote: > > > > > > > > I consider each RIO controller will has its own network, > the device IDs > > should be > > unique only in its port network. > Hmmm, I see two cases: Good questions! They are very important and also my concern now. > > 1. I have two mport to two controllers each connected to different > physical fabrics. This system can act as an application bridge between > the two fabrics. > The current driver just looks two mport as two independent fabrics. We can add bridge driver to implement your idea. > 2. I have two mports to two controllers each connected directly or > indirectly to the same fabric. I want to use the extra bandwidth and > load balance and/or have a fall back redundant connection via an > alternate physical connection to the fabric etc. > That's a terrible thing in the current driver. Two mports get the same ID in one fabric. About the port bound, it's a good idea, I also need a new driver to support it. In fact, our first mission is to make the RapidIO driver ported from ppc to powerpc can be compiled and run. Fortunately, there is no more than one port in processor now, we have time to implement it. > What should be the rules for allocating the initial IDs to the two > mports to allow system wide enumeration to work in both of the above > cases? > A choice is add ID option into dts node. I have some ideas about RapidIO driver in u-boot. U-boot can assign ID in dts and tell kernel. > What do you expect the semantics of higher level addressing to be: > a pair , where is a different device from , > a pair , where is the same device as ,or > a singleton n, where n is unique and identifies the first > routing step > of which controller, x or y, to use. It seems the address pair is a must-be selection as pci bus. But now, no connection between ports. Every operations in only in its own port view. > I smell a can of worms :-) A good nose! Thanks! :) Cheers! Wei ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
RE: [PATCH 1/2] Add RapidIO node into MPC8641HPCN dts file
Hi, Jon,
> -Original Message-
> From: Loeliger Jon
>
> Zhang Wei wrote:
> > Signed-off-by: Zhang Wei <[EMAIL PROTECTED]>
> > ---
> > arch/powerpc/boot/dts/mpc8641_hpcn.dts | 13 +
> > 1 files changed, 13 insertions(+), 0 deletions(-)
> >
> > diff --git a/arch/powerpc/boot/dts/mpc8641_hpcn.dts
> b/arch/powerpc/boot/dts/mpc8641_hpcn.dts
> > index 556a9ca..1a0fce5 100644
> > --- a/arch/powerpc/boot/dts/mpc8641_hpcn.dts
> > +++ b/arch/powerpc/boot/dts/mpc8641_hpcn.dts
> > @@ -25,6 +25,7 @@
> > serial1 = &serial1;
> > pci0 = &pci0;
> > pci1 = &pci1;
> > + rapidio0 = &rapidio0;
> > };
> >
> > cpus {
> > @@ -499,4 +500,16 @@
> > 0 0010>;
> > };
> > };
> > +
> > + rapidio0: [EMAIL PROTECTED] {
> > + #address-cells = <2>;
> > + #size-cells = <2>;
> > + compatible = "fsl,rapidio-delta";
> > + reg = ;
> > + ranges = <0 0 c000 0 2000>;
> > + interrupt-parent = <&mpic>;
> > + /* err_irq bell_outb_irq bell_inb_irq
> > + msg1_tx_irq msg1_rx_irq msg2_tx_irq
> msg2_rx_irq */
> > + interrupts = <30 2 31 2 32 2 35 2 36 2 37 2 38 2>;
> > + };
> > };
>
> The 8641 DTS file has been converted to /dts-v1/ format now.
> Please rewrite this patch with explicit hex numbers for
> addresses, even if 0x0, and decimal for IRQs.
>
I have seen other nodes in mpc8641_hpcn.dts still use old style.
Is it better to create an another new patch for correcting the style all?
Cheers!
Wei
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH powerpc] Fake NUMA emulation for PowerPC (Take 4)
* Michael Ellerman <[EMAIL PROTECTED]> [2008-01-30 00:04:58]:
> Why do you check !p after assigning to nid? I assume it's because we
> might have reached the end of the command line, ie. p == NULL, but we're
> still adding memory to the last node? If so it's a it's a little subtle
> and deserves a comment I think.
>
> Otherwise this looks pretty good.
>
> cheers
>
Hi, Paul,
Could you please consider version 4 for inclusion?
Changelong v4
1. Add more comments around the checks for command line arguments.
Changelog v3
1. Remove the side-effect of not setting nodes online if they end
up having no memory in them because of the memory limit.
Changelog v2
1. Get rid of the constant 5 (based on comments from
[EMAIL PROTECTED])
2. Implement suggestions from Olof Johannson
3. Check if cmdline is NULL in fake_numa_create_new_node()
Tested with additional parameters from Olof
numa=debug,fake=
numa=foo,fake=bar
Here's a dumb simple implementation of fake NUMA nodes for PowerPC. Fake
NUMA nodes can be specified using the following command line option
numa=fake=
node range is of the format ,,...
Each of the rangeX parameters is passed using memparse(). I find the patch
useful for fake NUMA emulation on my simple PowerPC machine. I've tested it
on a numa box with the following arguments
numa=fake=512M
numa=fake=512M,768M
numa=fake=256M,512M mem=512M
numa=fake=1G mem=768M
numa=fake=
without any numa= argument
The other side-effect introduced by this patch is that; in the case where we
don't have NUMA information, we now set a node online after adding each LMB.
This node could very well be node 0, but in the case that we enable fake
NUMA nodes, when we cross node boundaries, we need to set the new node online.
Signed-off-by: Balbir Singh <[EMAIL PROTECTED]>
---
arch/powerpc/mm/numa.c | 66 ++---
1 file changed, 63 insertions(+), 3 deletions(-)
diff -puN arch/powerpc/mm/numa.c~fakenumappc arch/powerpc/mm/numa.c
--- linux-2.6.24-rc8/arch/powerpc/mm/numa.c~fakenumappc 2008-01-28
17:05:34.0 +0530
+++ linux-2.6.24-rc8-balbir/arch/powerpc/mm/numa.c 2008-02-01
10:24:57.0 +0530
@@ -24,6 +24,8 @@
static int numa_enabled = 1;
+static char *cmdline __initdata;
+
static int numa_debug;
#define dbg(args...) if (numa_debug) { printk(KERN_INFO args); }
@@ -39,6 +41,53 @@ static bootmem_data_t __initdata plat_no
static int min_common_depth;
static int n_mem_addr_cells, n_mem_size_cells;
+static int __cpuinit fake_numa_create_new_node(unsigned long end_pfn,
+ unsigned int *nid)
+{
+ unsigned long long mem;
+ char *p = cmdline;
+ static unsigned int fake_nid;
+ static unsigned long long curr_boundary;
+
+ /*
+* Modify node id, iff we started creating NUMA nodes
+* We want to continue from where we left of the last time
+*/
+ if (fake_nid)
+ *nid = fake_nid;
+ /*
+* In case there are no more arguments to parse, the
+* node_id should be the same as the last fake node id
+* (we've handled this above).
+*/
+ if (!p)
+ return 0;
+
+ mem = memparse(p, &p);
+ if (!mem)
+ return 0;
+
+ if (mem < curr_boundary)
+ return 0;
+
+ curr_boundary = mem;
+
+ if ((end_pfn << PAGE_SHIFT) > mem) {
+ /*
+* Skip commas and spaces
+*/
+ while (*p == ',' || *p == ' ' || *p == '\t')
+ p++;
+
+ cmdline = p;
+ fake_nid++;
+ *nid = fake_nid;
+ dbg("created new fake_node with id %d\n", fake_nid);
+ return 1;
+ }
+ return 0;
+}
+
static void __cpuinit map_cpu_to_node(int cpu, int node)
{
numa_cpu_lookup_table[cpu] = node;
@@ -344,6 +393,9 @@ static void __init parse_drconf_memory(s
if (nid == 0x || nid >= MAX_NUMNODES)
nid = default_nid;
}
+
+ fake_numa_create_new_node(((start + lmb_size) >> PAGE_SHIFT),
+ &nid);
node_set_online(nid);
size = numa_enforce_memory_limit(start, lmb_size);
@@ -429,6 +481,8 @@ new_range:
nid = of_node_to_nid_single(memory);
if (nid < 0)
nid = default_nid;
+
+ fake_numa_create_new_node(((start + size) >> PAGE_SHIFT), &nid);
node_set_online(nid);
if (!(size = numa_enforce_memory_limit(start, size))) {
@@ -461,7 +515,7 @@ static void __init setup_nonnuma(void)
unsigned long top_of_ram = lmb_end_of_DRAM();
unsigned long total_ram = lmb_phys_mem_size();
unsigned long start_pfn, end_pfn;
- unsigned int i;
+
Re: [PATCH 0/5] ehea checkpatch fixups
On Thu, 31 Jan 2008 21:05:42 CST, Nathan Lynch wrote: > Doug Maxey wrote: > > > > A small set of fixups for checkpatch. > > > > Based on upstream pull from a few hours ago. > > Er, ehea doesn't even build right now[1], maybe that could get fixed > first? :-) > > [1] http://lkml.org/lkml/2008/1/28/337 For sure these won't break it any worse. ;) Think of these more as a janitorial thing vs. structural. Doesn't gregkh's patch work? At least for the interim? Jan-Bernd, What tools are looking in sysfs? distro scripts? I don't see any link between ethtool and the driver (other than the driver internal bits). Am I missing something obvious? ++doug ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Kernel oops in MPC8568MDS BSP
On Jan 31, 2008, at 1:28 PM, mike zheng wrote: > Hello, > > I am using MPC8568MDS BSP on my board, which has same memory map with > MPC8568MDS board. However I have kernel Ooop at > free_bootmem_with_active_regions() within do_init_bootmem(). Any idea > on this issue? such questions should be asked of the BSP provider. - k ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] [POWERPC] Xilinx: hwicap driver
On 1/31/08, Stephen Neuendorffer <[EMAIL PROTECTED]> wrote: > This includes code for new fifo-based xps_hwicap in addition to the > older opb_hwicap, which has a significantly different interface. The > common code between the two drivers is largely shared. > > Significant differences exists between this driver and what is > supported in the EDK drivers. In particular, most of the > architecture-specific code for reconfiguring individual FPGA resources > has been removed. This functionality is likely better provided in a > user-space support library. In addition, read and write access is > supported. In addition, although the xps_hwicap cores support > interrupt-driver mode, this driver only supports polled operation, in > order to make the code simpler, and since the interrupt processing > overhead is likely to slow down the throughput under Linux. > > Signed-off-by: Stephen Neuendorffer <[EMAIL PROTECTED]> > > Fixed to add spinlocks, and a few style issues. You're probably better off using a semaphore, or more specifically a MUTEX, to protect the whole fop instead of a spin lock and the flags. The semantics are simpler if do it with a mutex and the function can sleep while holding it. Cheers, g. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] [POWERPC] Xilinx: hwicap driver
Stephen Neuendorffer wrote:
>
> +static ssize_t
> +hwicap_read(struct file *file, char *buf, size_t count, loff_t *ppos)
> +{
> + struct hwicap_drvdata *drvdata = file->private_data;
> + ssize_t bytes_to_read = 0;
> + u32 *kbuf;
> + u32 words;
> + u32 bytes_remaining;
> + int status;
> +
> +spin_lock(&hwicap_spinlock);
> + if (drvdata->is_accessing)
> + return -EBUSY;
Need to unlock before returning (several places in this patch).
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 3/3] Add device tree compatible aliases to i2c drivers
On Wed, Jan 23, 2008 at 08:18:47PM +, Matt Sealey wrote:
>
>
> Jon Smirl wrote:
> > --- a/drivers/i2c/chips/tps65010.c
> > +++ b/drivers/i2c/chips/tps65010.c
> > @@ -571,6 +571,10 @@ static const struct i2c_device_id tps65010_id[] = {
> > { "tps65011", TPS65011 },
> > { "tps65012", TPS65012 },
> > { "tps65013", TPS65013 },
> > + OF_ID("ti,tps65010", TPS65010)
> > + OF_ID("ti,tps65011", TPS65011)
> > + OF_ID("ti,tps65012", TPS65012)
> > + OF_ID("ri,tps65013", TPS65013)
> > { },
>
> ti, ti, ti, ri?
>
> > --- a/drivers/rtc/rtc-ds1307.c
> > +++ b/drivers/rtc/rtc-ds1307.c
> > @@ -129,6 +129,12 @@ static const struct i2c_device_id ds1307_id[] = {
> > { "ds1339", ds_1339 },
> > { "ds1340", ds_1340 },
> > { "m41t00", m41t00 },
> > + OF_ID("dallas,ds1307", ds_1307)
> > + OF_ID("dallas,ds1337", ds_1337)
> > + OF_ID("dallas,ds1338", ds_1338)
> > + OF_ID("dallas,ds1339", ds_1339)
> > + OF_ID("dallas,ds1340", ds_1340)
> > + OF_ID("stm,m41t00", m41t00)
> > {},
> > };
>
> The convention is to use the stock ticker, capitalized, if a company
> has one, I guess dallas is MXIM these days, but dallas is a good
> substitute based on the fact that most people still remember Dallas
> clock chips and so on from the Ancient Days. STMicroelectronics is STM.
> I couldn't care less about case sensitivity, but the stock ticker
> thing was always a good idea.. it gives a sort of grounding in reality
> for the manufacturer names.
The stock ticker is a recent convention. "dallas," has been used in
existing IEEE1275 bindings, which to my mind trumps newer conventions.
--
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 2/4 v4] POWERPC: Add StorCenter DTS first draft.
On Wed, Jan 23, 2008 at 12:42:29PM -0600, Jon Loeliger wrote:
>
> Based on the Kurobox DTS files.
[snip]
> +/ {
> + model = "StorCenter";
> + compatible = "storcenter";
This really needs a vendor prefix.
> + chosen {
> + linux,stdout-path = "/soc/[EMAIL PROTECTED]";
You can now use a path reference here.
--
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 2/10] sbc8560: Add v1 device tree source for Wind River SBC8560 board
On Thu, Jan 24, 2008 at 06:41:24PM -0500, Paul Gortmaker wrote:
> This adds a v1 device tree source for the Wind River SBC8560 board. The
> biggest difference between this and the MPC8560ADS reference platform
> dts is the use of an external 16550 compatible UART instead of the CPM2.
>
> Signed-off-by: Paul Gortmaker <[EMAIL PROTECTED]>
[snip]
> +/dts-v1/;
> +
> +/ {
> + model = "SBC8560";
> + compatible = "SBC8560";
This is not the conventional format for board-level compatible
entries, which should generally be "vendor,model" and all in lower
case.
[snip]
> + enet0: [EMAIL PROTECTED] {
> + cell-index = <0>;
> + device_type = "network";
> + model = "TSEC";
> + compatible = "gianfar";
This looks like the old dodgy gianfar binding, and needs updating
(mdio node will probably also need changes).
[snip]
> + [EMAIL PROTECTED] {
> + compatible = "fsl,mpc8560-localbus";
> + #address-cells = <2>;
> + #size-cells = <1>;
> + reg = <0xff705000 0x100>; // BRx, ORx, etc.
> +
> + ranges = <
> + 0x0 0x0 0xff80 0x080// 8MB boot flash
> + 0x1 0x0 0xe400 0x400// 64MB flash
> + 0x3 0x0 0x2000 0x400// 64MB SDRAM
> + 0x4 0x0 0x2400 0x400// 64MB SDRAM
> + 0x5 0x0 0xfc00 0x0c0// EPLD
> + 0x6 0x0 0xe000 0x400// 64MB flash
> + 0x7 0x0 0x8000 0x020// ATM1,2
> + >;
> +
> + [EMAIL PROTECTED],0 {
I'm not entirely convinced on this two-level representation. I think
the FSL people need to get together and define a binding (or set of
bindings) for their various chipselect style external bus bridges.
> + compatible = "wrs,epld-localbus";
> + #address-cells = <2>;
> + #size-cells = <1>;
> + reg = <0x5 0x0 0xc0>;
> + ranges = <
> + 0x0 0x0 0x5 0x00 0x1fff // LED disp.
> + 0x1 0x0 0x5 0x10 0x1fff // switches
> + 0x2 0x0 0x5 0x20 0x1fff // ID reg.
> + 0x3 0x0 0x5 0x30 0x1fff // status reg.
> + 0x4 0x0 0x5 0x40 0x1fff // reset reg.
> + 0x5 0x0 0x5 0x50 0x1fff // Wind port
> + 0x7 0x0 0x5 0x70 0x1fff // UART #1
> + 0x8 0x0 0x5 0x80 0x1fff // UART #2
> + 0x9 0x0 0x5 0x90 0x1fff // RTC
> + 0xb 0x0 0x5 0xb0 0x1fff // EEPROM
> + >;
--
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] pasemi: Fix thinko in dma_direct_ops setup
On Thu, 2008-01-31 at 17:50 -0600, Olof Johansson wrote: > [POWERPC] pasemi: Fix thinko in dma_direct_ops setup > > The first patch will just fall through and still set dma_data to a bad > value, make it return directly instead. > > Signed-off-by: Olof Johansson <[EMAIL PROTECTED]> OK I get it now, sorry for the breakage. Acked-by: Michael Ellerman <[EMAIL PROTECTED]> 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
