* [git pull] Please pull powerpc.git master branch
From: Paul Mackerras @ 2008-04-29 11:29 UTC (permalink / raw)
To: torvalds; +Cc: linuxppc-dev, akpm, linux-kernel
Linus,
Please do:
git pull \
git://git.kernel.org/pub/scm/linux/kernel/git/paulus/powerpc.git master=
There are 14 commits there that Andrew Morton sent to me to merge,
from Badari Pulavarty (memory hot-remove stuff) and Zhang Wei (RapidIO
patches). Plus there are 5 other powerpc-related patches: a patch
from me adding a fast endian-switch system call, a patch from Kumar
Gala that lets 32-bit use separate stacks for hard and soft IRQs like
64-bit already does, a build fix from Tony Breeds, a patch from me to
make powerpc build OK if inline doesn't mean __always_inline, and a
thermal driver for one of the last G5 powermac models.
Thanks,
Paul.
Badari Pulavarty (3):
[POWERPC] Hotplug memory remove notifications for powerpc
[POWERPC] Update lmb data structures for hotplug memory add/remov=
e
[POWERPC] Provide walk_memory_resource() for powerpc
Kumar Gala (1):
[POWERPC] Add IRQSTACKS support on ppc32
Paul Mackerras (2):
[POWERPC] Add fast little-endian switch system call
[POWERPC] Use __always_inline for xchg* and cmpxchg*
Tony Breeds (1):
[POWERPC] Fix building of pmac32 when CONFIG_NVRAM=3Dm
Zhang Wei (11):
[RAPIDIO] Change RIO function mpc85xx_ to fsl_
[RAPIDIO] Add RapidIO option to kernel configuration
[RAPIDIO] Move include/asm-ppc/rio.h to asm-powerpc
[RAPIDIO] Add RapidIO multi mport support
[RAPIDIO] Add OF-tree support to RapidIO controller driver
[RAPIDIO] Auto-probe the RapidIO system size
[RAPIDIO] Add RapidIO node into MPC8641HPCN dts file
[RAPIDIO] Add RapidIO node probing into MPC86xx_HPCN board id tab=
le
[RAPIDIO] Add serial RapidIO controller support, which includes M=
PC8548, MPC8641
[RAPIDIO] Add RapidIO connection info print out and re-training f=
or broken connections
[RAPIDIO] Change RapidIO doorbell source and target ID field to 1=
6-bit
=C9tienne Bersac (1):
[POWERPC] windfarm: Add PowerMac 12,1 support
^ permalink raw reply
* Re: build failure on efika
From: Grant Likely @ 2008-04-29 12:08 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev
In-Reply-To: <18454.49097.53537.474679@cargo.ozlabs.ibm.com>
On Tue, Apr 29, 2008 at 12:27 AM, Paul Mackerras <paulus@samba.org> wrote:
> My test builds for efika currently fail with this message:
>
> FATAL: drivers/serial/mpc52xx_uart: struct of_device_id is not terminated with a NULL entry!
> make[2]: *** [__modpost] Error 1
> make[1]: *** [modules] Error 2
> make: *** [sub-make] Error 2
>
> Could you do a little patch to add the NULL entry please?
Will do.
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* Re: [PATCH 1/2 v2] i2c: Add support for device alias names
From: Jon Smirl @ 2008-04-29 12:16 UTC (permalink / raw)
To: Jean Delvare
Cc: Kay Sievers, linuxppc-dev list, Paul Mundt, Linux I2C, Scott Wood
In-Reply-To: <20080429124621.07e6efd6@hyperion.delvare>
On 4/29/08, Jean Delvare <khali@linux-fr.org> wrote:
> Based on earlier work by Jon Smirl and Jochen Friedrich.
> +/* Looks like: i2c:S */
> +static int do_i2c_entry(const char *filename, struct i2c_device_id *id,
> + char *alias)
> +{
> + sprintf(alias, I2C_MODULE_PREFIX "%s", id->name);
Do you want to add the colon?
> +
> + return 1;
> +}
--
Jon Smirl
jonsmirl@gmail.com
^ permalink raw reply
* [PATCH] [POWERPC] mpc5200: Fix unterminated of_device_id table
From: Grant Likely @ 2008-04-29 12:43 UTC (permalink / raw)
To: linuxppc-dev, linux_kernel, paulus
From: Grant Likely <grant.likely@secretlab.ca>
If CONFIG_PPC_MPC5121 is not set, then the of_device_id table for the
mpc5200 serial driver will not get terminated with a NULL entry.
Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
---
drivers/serial/mpc52xx_uart.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/serial/mpc52xx_uart.c b/drivers/serial/mpc52xx_uart.c
index d93b357..7a3625f 100644
--- a/drivers/serial/mpc52xx_uart.c
+++ b/drivers/serial/mpc52xx_uart.c
@@ -1221,8 +1221,8 @@ static struct of_device_id mpc52xx_uart_of_match[] = {
#endif
#ifdef CONFIG_PPC_MPC512x
{ .compatible = "fsl,mpc5121-psc-uart", .data = &mpc512x_psc_ops, },
- {},
#endif
+ {},
};
static int __devinit
^ permalink raw reply related
* Re: [PATCH 1/2 v2] i2c: Add support for device alias names
From: Jean Delvare @ 2008-04-29 12:49 UTC (permalink / raw)
To: Jon Smirl
Cc: Kay Sievers, linuxppc-dev list, Paul Mundt, Linux I2C, Scott Wood
In-Reply-To: <9e4733910804290516g1fd0b653jae63e811409e00f9@mail.gmail.com>
Hi Jon,
On Tue, 29 Apr 2008 08:16:13 -0400, Jon Smirl wrote:
> On 4/29/08, Jean Delvare <khali@linux-fr.org> wrote:
> > Based on earlier work by Jon Smirl and Jochen Friedrich.
> > +/* Looks like: i2c:S */
> > +static int do_i2c_entry(const char *filename, struct i2c_device_id *id,
> > + char *alias)
> > +{
> > + sprintf(alias, I2C_MODULE_PREFIX "%s", id->name);
>
> Do you want to add the colon?
Not yet. This can be added later anyway, so I'd rather push the
known-to-work patches as is for now, and we fix this detail between rc1
and rc2. For now I am still in favor of removing the "*" we don't need,
I'll send a patch doing this later today (I hope) for discussion.
> > +
> > + return 1;
> > +}
Thanks,
--
Jean Delvare
^ permalink raw reply
* Please pull linux-2.6-mpc52xx.git
From: Grant Likely @ 2008-04-29 13:34 UTC (permalink / raw)
To: Paul Mackerras, linuxppc-dev
The following changes since commit 6c39103ce5192bdb2195f3daab7323dfa44fb52e:
Zhang Wei (1):
[RAPIDIO] Change RapidIO doorbell source and target ID field to 16-bit
are available in the git repository at:
git://git.secretlab.ca/git/linux-2.6-mpc52xx.git for-2.6.26
Bartlomiej Sieka (1):
[POWERPC] mpc5200: defconfigs for CM5200, Lite5200B, Motion-PRO
and TQM5200
Grant Likely (2):
[POWERPC] mpc5200: Fix unterminated of_device_id table
[POWERPC] mpc5200: Switch mpc5200 dts files to dts-v1 format
Sascha Hauer (2):
[POWERPC] mpc5200: add interrupt type function
[POWERPC] mpc5200: Fix FEC error handling on FIFO errors
s.hauer@pengutronix.de (2):
[POWERPC] mpc5200: add gpiolib support for mpc5200
[POWERPC] mpc5200: add Phytec pcm030 board support
.../powerpc/mpc52xx-device-tree-bindings.txt | 12 +
arch/powerpc/boot/dts/cm5200.dts | 98 +-
arch/powerpc/boot/dts/lite5200.dts | 132 ++--
arch/powerpc/boot/dts/lite5200b.dts | 146 ++--
arch/powerpc/boot/dts/motionpro.dts | 118 +-
arch/powerpc/boot/dts/pcm030.dts | 363 ++++++
arch/powerpc/boot/dts/tqm5200.dts | 80 +-
arch/powerpc/configs/52xx/cm5200_defconfig | 1099 ++++++++++++++++++
arch/powerpc/configs/52xx/lite5200b_defconfig | 1049 +++++++++++++++++
arch/powerpc/configs/52xx/motionpro_defconfig | 1107 ++++++++++++++++++
arch/powerpc/configs/52xx/pcm030_defconfig | 1115 ++++++++++++++++++
arch/powerpc/configs/52xx/tqm5200_defconfig | 1214 ++++++++++++++++++++
arch/powerpc/platforms/52xx/Kconfig | 6 +
arch/powerpc/platforms/52xx/Makefile | 2 +
arch/powerpc/platforms/52xx/mpc5200_simple.c | 1 +
arch/powerpc/platforms/52xx/mpc52xx_gpio.c | 465 ++++++++
arch/powerpc/platforms/52xx/mpc52xx_pic.c | 38 +
drivers/net/fec_mpc52xx.c | 23 +-
drivers/serial/mpc52xx_uart.c | 2 +-
19 files changed, 6771 insertions(+), 299 deletions(-)
create mode 100644 arch/powerpc/boot/dts/pcm030.dts
create mode 100644 arch/powerpc/configs/52xx/cm5200_defconfig
create mode 100644 arch/powerpc/configs/52xx/lite5200b_defconfig
create mode 100644 arch/powerpc/configs/52xx/motionpro_defconfig
create mode 100644 arch/powerpc/configs/52xx/pcm030_defconfig
create mode 100644 arch/powerpc/configs/52xx/tqm5200_defconfig
create mode 100644 arch/powerpc/platforms/52xx/mpc52xx_gpio.c
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* Re: 2.6.25: pmac_newworld undefined
From: Adrian Bunk @ 2008-04-29 13:35 UTC (permalink / raw)
To: Sam Ravnborg; +Cc: linuxppc-dev, LKML
In-Reply-To: <20080428193324.GC13400@uranus.ravnborg.org>
On Mon, Apr 28, 2008 at 09:33:24PM +0200, Sam Ravnborg wrote:
> On Mon, Apr 28, 2008 at 02:20:44PM +1000, Tony Breeds wrote:
> > On Sun, Apr 27, 2008 at 08:03:46PM +0200, Christian Kujau wrote:
> > > Hi,
> > >
> > > the build failure reported[0] by Kamalesh back in 01/2008 is still
> > > present in today's 2.6.25-git with CONFIG_NVRAM=m (instead of =y):
> > >
> > > Building modules, stage 2.
> > > MODPOST 72 modules
> > > ERROR: "pmac_newworld" [arch/powerpc/platforms/powermac/nvram.ko] undefined!
> > > ERROR: "__alloc_bootmem" [arch/powerpc/platforms/powermac/nvram.ko]
> > > undefined!
> > > make[1]: *** [__modpost] Error 1
> >
> > Yeah that isn't really surprising. Essentially
> > arch/powerpc/platforms/powermac/nvram.c must be builtin (not modular)
> > but CONFIG_NVRAM is tristate, and your .config has CONFIG_NVRAM=m.
> >
> > We can probably "fix" this by adding another config config symbol and
> > "selecting" that from CONFIG_NVRAM. Then using this new symbol in
> > arch/powerpc/platforms/powermac/*
> >
> > so I think with we need is:
> > config NVRAM
> > bool "..." if PPC32
> > tristate "..." if !PPC32
> > ...
> > ...
> >
> > Sam is there some way to achieve that or should we just create an
> > secondary symbol?
>
> In the Makefile you could just do a:
>
> obj-$(CONFIG_NVRAM:m=y) += nvram.o
>
> Then you would force nvram to be build-in.
> That looks simpler than messing with Kconfig in this case.
You miss that this is only true on powerpc.
And for such issues Kconfig anyway is the right place - assume how your
solution would break if NVRAM would some day select or depend on some
helper code.
> Sam
cu
Adrian
--
"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
^ permalink raw reply
* [PATCH] [POWERPC] convert transfer_to_handler into a macro
From: Kumar Gala @ 2008-04-29 13:56 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev
We need to have unique transfer_to_handler paths for each exception level
that is supported. We need to use the proper xSRR0/1 depending on which
exception level the interrupt was from. The macro conversion lets up
templatize this code path.
Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
---
Paul,
I request you apply this for v2.6.26. I know its a bit late in the game
but I'd prefer to get this in so reduce churn later. Also, I've built this
version on pmac_defconfig, ppc40x_defconfig, and ppc44x_config and compared
the objdump output to ensure that the code is identical before and after
this patch.
- k
arch/powerpc/kernel/entry_32.S | 191 ++++++++++++++++++++++------------------
1 files changed, 106 insertions(+), 85 deletions(-)
diff --git a/arch/powerpc/kernel/entry_32.S b/arch/powerpc/kernel/entry_32.S
index 0c8614d..7710a02 100644
--- a/arch/powerpc/kernel/entry_32.S
+++ b/arch/powerpc/kernel/entry_32.S
@@ -43,6 +43,111 @@
#define LOAD_MSR_KERNEL(r, x) li r,(x)
#endif
+#if defined(CONFIG_40x) || defined(CONFIG_BOOKE)
+#ifdef CONFIG_SMP
+#define SMP_ADJUST_GLOBAL_DBCR0 \
+ rlwinm r9,r1,0,0,(31-THREAD_SHIFT); \
+ lwz r9,TI_CPU(r9); \
+ slwi r9,r9,3; \
+ add r11,r11,r9;
+#else
+#define SMP_ADJUST_GLOBAL_DBCR0
+#endif
+#define HANDLE_DBCR \
+ /* Check to see if the dbcr0 register is set up to debug. Use the \
+ internal debug mode bit to do this. */ \
+ lwz r12,THREAD_DBCR0(r12); \
+ andis. r12,r12,DBCR0_IDM@h; \
+ beq+ 3f; \
+ /* From user and task is ptraced - load up global dbcr0 */ \
+ li r12,-1; /* clear all pending debug events */ \
+ mtspr SPRN_DBSR,r12; \
+ lis r11,global_dbcr0@ha; \
+ tophys(r11,r11); \
+ addi r11,r11,global_dbcr0@l; \
+ SMP_ADJUST_GLOBAL_DBCR0; \
+ lwz r12,0(r11); \
+ mtspr SPRN_DBCR0,r12; \
+ lwz r12,4(r11); \
+ addi r12,r12,-1; \
+ stw r12,4(r11);
+#else
+#define HANDLE_DBCR
+#endif
+
+#ifdef CONFIG_6xx
+#define CHECK_DOZE_NAP \
+ rlwinm r9,r1,0,0,31-THREAD_SHIFT; \
+ tophys(r9,r9); /* check local flags */ \
+ lwz r12,TI_LOCAL_FLAGS(r9); \
+ mtcrf 0x01,r12; \
+ bt- 31-TLF_NAPPING,4f;
+#define RESTORE_DOZE_NAP \
+4: rlwinm r12,r12,0,~_TLF_NAPPING; \
+ stw r12,TI_LOCAL_FLAGS(r9); \
+ b power_save_6xx_restore;
+#else
+#define RESTORE_DOZE_NAP
+#define CHECK_DOZE_NAP
+#endif /* CONFIG_6xx */
+
+/*
+ * This code finishes saving the registers to the exception frame
+ * and jumps to the appropriate handler for the exception, turning
+ * on address translation.
+ * Note that we rely on the caller having set cr0.eq iff the exception
+ * occurred in kernel mode (i.e. MSR:PR = 0).
+ */
+
+#define TRANSFER_TO_HANDLER(prefix, exc_lvl_srr0, exc_lvl_srr1, exc_lvl_rfi) \
+ .globl prefix##transfer_to_handler_full; \
+prefix##transfer_to_handler_full: \
+ SAVE_NVGPRS(r11); \
+ /* fall through */ \
+ \
+ .globl prefix##transfer_to_handler; \
+prefix##transfer_to_handler: \
+ stw r2,GPR2(r11); \
+ stw r12,_NIP(r11); \
+ stw r9,_MSR(r11); \
+ andi. r2,r9,MSR_PR; \
+ mfctr r12; \
+ mfspr r2,SPRN_XER; \
+ stw r12,_CTR(r11); \
+ stw r2,_XER(r11); \
+ mfspr r12,SPRN_SPRG3; \
+ addi r2,r12,-THREAD; \
+ tovirt(r2,r2); /* set r2 to current */ \
+ beq 2f; /* if from user, fix up THREAD.regs */ \
+ \
+ addi r11,r1,STACK_FRAME_OVERHEAD; \
+ stw r11,PT_REGS(r12); \
+ HANDLE_DBCR; \
+ b 3f; \
+ \
+2: /* if from kernel, check interrupted DOZE/NAP mode and \
+ * check for stack overflow \
+ */ \
+ lwz r9,KSP_LIMIT(r12); \
+ cmplw r1,r9; /* if r1 <= ksp_limit */ \
+ ble- stack_ovf; /* then the kernel stack overflowed */ \
+5: \
+ CHECK_DOZE_NAP; \
+ \
+ .globl prefix##transfer_to_handler_cont; \
+prefix##transfer_to_handler_cont: \
+3: \
+ mflr r9; \
+ lwz r11,0(r9); /* virtual address of handler */ \
+ lwz r9,4(r9); /* where to go when done */ \
+ mtspr exc_lvl_srr0,r11; \
+ mtspr exc_lvl_srr1,r10; \
+ mtlr r9; \
+ SYNC; \
+ exc_lvl_rfi; /* jump to handler, enable MMU */ \
+ \
+ RESTORE_DOZE_NAP;
+
#ifdef CONFIG_BOOKE
#include "head_booke.h"
#define TRANSFER_TO_HANDLER_EXC_LEVEL(exc_level) \
@@ -80,91 +185,7 @@ crit_transfer_to_handler:
/* fall through */
#endif
-/*
- * This code finishes saving the registers to the exception frame
- * and jumps to the appropriate handler for the exception, turning
- * on address translation.
- * Note that we rely on the caller having set cr0.eq iff the exception
- * occurred in kernel mode (i.e. MSR:PR = 0).
- */
- .globl transfer_to_handler_full
-transfer_to_handler_full:
- SAVE_NVGPRS(r11)
- /* fall through */
-
- .globl transfer_to_handler
-transfer_to_handler:
- stw r2,GPR2(r11)
- stw r12,_NIP(r11)
- stw r9,_MSR(r11)
- andi. r2,r9,MSR_PR
- mfctr r12
- mfspr r2,SPRN_XER
- stw r12,_CTR(r11)
- stw r2,_XER(r11)
- mfspr r12,SPRN_SPRG3
- addi r2,r12,-THREAD
- tovirt(r2,r2) /* set r2 to current */
- beq 2f /* if from user, fix up THREAD.regs */
- addi r11,r1,STACK_FRAME_OVERHEAD
- stw r11,PT_REGS(r12)
-#if defined(CONFIG_40x) || defined(CONFIG_BOOKE)
- /* Check to see if the dbcr0 register is set up to debug. Use the
- internal debug mode bit to do this. */
- lwz r12,THREAD_DBCR0(r12)
- andis. r12,r12,DBCR0_IDM@h
- beq+ 3f
- /* From user and task is ptraced - load up global dbcr0 */
- li r12,-1 /* clear all pending debug events */
- mtspr SPRN_DBSR,r12
- lis r11,global_dbcr0@ha
- tophys(r11,r11)
- addi r11,r11,global_dbcr0@l
-#ifdef CONFIG_SMP
- rlwinm r9,r1,0,0,(31-THREAD_SHIFT)
- lwz r9,TI_CPU(r9)
- slwi r9,r9,3
- add r11,r11,r9
-#endif
- lwz r12,0(r11)
- mtspr SPRN_DBCR0,r12
- lwz r12,4(r11)
- addi r12,r12,-1
- stw r12,4(r11)
-#endif
- b 3f
-
-2: /* if from kernel, check interrupted DOZE/NAP mode and
- * check for stack overflow
- */
- lwz r9,KSP_LIMIT(r12)
- cmplw r1,r9 /* if r1 <= ksp_limit */
- ble- stack_ovf /* then the kernel stack overflowed */
-5:
-#ifdef CONFIG_6xx
- rlwinm r9,r1,0,0,31-THREAD_SHIFT
- tophys(r9,r9) /* check local flags */
- lwz r12,TI_LOCAL_FLAGS(r9)
- mtcrf 0x01,r12
- bt- 31-TLF_NAPPING,4f
-#endif /* CONFIG_6xx */
- .globl transfer_to_handler_cont
-transfer_to_handler_cont:
-3:
- mflr r9
- lwz r11,0(r9) /* virtual address of handler */
- lwz r9,4(r9) /* where to go when done */
- mtspr SPRN_SRR0,r11
- mtspr SPRN_SRR1,r10
- mtlr r9
- SYNC
- RFI /* jump to handler, enable MMU */
-
-#ifdef CONFIG_6xx
-4: rlwinm r12,r12,0,~_TLF_NAPPING
- stw r12,TI_LOCAL_FLAGS(r9)
- b power_save_6xx_restore
-#endif
+ TRANSFER_TO_HANDLER(, SPRN_SRR0, SPRN_SRR1, RFI);
/*
* On kernel stack overflow, load up an initial stack pointer
--
1.5.4.1
^ permalink raw reply related
* [PATCH] of/gpio: use dynamic base allocation
From: Anton Vorontsov @ 2008-04-29 14:05 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev, David Miller
Since gpiolib-dynamic-gpio-number-allocation.patch -mm patch was recently
merged into Linus' tree (commit 8d0aab2f16c4fa170f32e7a74a52cd0122bbafef),
we can use dynamic GPIO base allocation now.
This, in turn, removes number of gpios per chip constraint.
Signed-off-by: Anton Vorontsov <avorontsov@ru.mvista.com>
---
drivers/of/gpio.c | 38 +-------------------------------------
1 files changed, 1 insertions(+), 37 deletions(-)
diff --git a/drivers/of/gpio.c b/drivers/of/gpio.c
index 000681e..1c9cab8 100644
--- a/drivers/of/gpio.c
+++ b/drivers/of/gpio.c
@@ -137,38 +137,6 @@ int of_gpio_simple_xlate(struct of_gpio_chip *of_gc, struct device_node *np,
}
EXPORT_SYMBOL(of_gpio_simple_xlate);
-/* Should be sufficient for now, later we'll use dynamic bases. */
-#if defined(CONFIG_PPC32) || defined(CONFIG_SPARC32)
-#define GPIOS_PER_CHIP 32
-#else
-#define GPIOS_PER_CHIP 64
-#endif
-
-static int of_get_gpiochip_base(struct device_node *np)
-{
- struct device_node *gc = NULL;
- int gpiochip_base = 0;
-
- while ((gc = of_find_all_nodes(gc))) {
- if (!of_get_property(gc, "gpio-controller", NULL))
- continue;
-
- if (gc != np) {
- gpiochip_base += GPIOS_PER_CHIP;
- continue;
- }
-
- of_node_put(gc);
-
- if (gpiochip_base >= ARCH_NR_GPIOS)
- return -ENOSPC;
-
- return gpiochip_base;
- }
-
- return -ENOENT;
-}
-
/**
* of_mm_gpiochip_add - Add memory mapped GPIO chip (bank)
* @np: device node of the GPIO chip
@@ -205,11 +173,7 @@ int of_mm_gpiochip_add(struct device_node *np,
if (!mm_gc->regs)
goto err1;
- gc->base = of_get_gpiochip_base(np);
- if (gc->base < 0) {
- ret = gc->base;
- goto err1;
- }
+ gc->base = -1;
if (!of_gc->xlate)
of_gc->xlate = of_gpio_simple_xlate;
--
1.5.5.1
^ permalink raw reply related
* Re: [PATCH] devres: support addresses greater than an unsigned long via dev_ioremap
From: Kumar Gala @ 2008-04-29 14:08 UTC (permalink / raw)
To: Greg KH
Cc: Andrew Morton, Tejun Heo, lkml Mailing List, Jesse Barnes,
linuxppc-dev@ozlabs.org list, Jeff Garzik
In-Reply-To: <4816C214.60806@pobox.com>
On Apr 29, 2008, at 1:37 AM, Jeff Garzik wrote:
> Tejun Heo wrote:
>> Kumar Gala wrote:
>>> Use a resource_size_t instead of unsigned long since some arch's are
>>> capable of having ioremap deal with addresses greater than the
>>> size of a
>>> unsigned long.
>>>
>>> Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
>> Acked-by: Tejun Heo <htejun@gmail.com>
>
> Fine with me, too.
>
> I think devres changes should go via GregKH (device core) or Jesse
> (PCI) rather than my libata tree, unless there are obvious
> dependencies...
GregKH will you handle pushing this to Linus. Its a pretty trivial
patch and would be nice to go into 2.6.26. I would also consider it a
bug fix of shorts for any driver using devres and resource_size_t
being typedef'd to u64 on a 32-bit processor.
- k
^ permalink raw reply
* Re: Enabling 64 bit data type for dma_addr_t on non PPC64 architecture
From: Becky Bruce @ 2008-04-29 15:14 UTC (permalink / raw)
To: benh; +Cc: linuxppc-dev, Tushar Tyagi
In-Reply-To: <1209181131.5420.42.camel@pasglop>
On Apr 25, 2008, at 10:38 PM, Benjamin Herrenschmidt wrote:
>
> On Fri, 2008-04-25 at 19:52 -0700, Tushar Tyagi wrote:
>> Hello,
>> I'm working a new DMA hardware for PPC processors.
>> The processor is a 32 bit architecture having 40 bit physical address
>> space.
>> So we need the 32 bit processor code base but we want the type
>> dma_addr_t to represent 64 bit data, without enabling the
>> CONFIG_PPC64
>> flag.
>
> That shouldn't be a big issue, we already support 64 bits resources,
> extending dma_addr_t shouldn't too hard.
>
>> We want to use the Linux generic DMA layer to offload DMA
>> operations to
>> the hw and the Linux code path goes through function
>> dma_async_memcpy_buf_to_buf and then dma_map_single.
>>
>> Currently the dma_map_single function has 2 versions based upon
>> CONFIG_PPC64 defined or not.
>>
>> Is it possible to reuse the CONFIG_PPC64 based code only pertaining
>> to
>> DMA by doing the following:
>
> It's possible, it might be a good idea even as it would allow to have
> different implementations for different busses, which is in fact
> needed
> for some things like 4xx if we start changing the mapping between
> different PCI bridges vs. SoCs. In fact, I think there's been some
> patches from Becky Bruce posted in februrary for doing just that,
> which
> I totally forgot to review...
>
>> Add a new flag called CONFIG_DMA64 along with CONFIG_PPC64 and
>> __powerpc64__ flags, enabling our code to use the generic DMA layer
>> with
>> 64 bit data type for dma_addr_t.
>>
>> With the above modification, the function dma_map_single starts
>> returning 64 bit data type instead of 32.
>>
>> Do you have any comments or suggestions ?
>
> I'd suggest working with Becky on her initial patch and using that as
> the basis for your stuff. I'll try to give it a good review asap.
Actually, Ben, wait on that review - I've made significant changes to
those patches, including some bugfixes for HIGHMEM and will be posting
the revised version soon (hopefully later today or tomorrow). I'm
behind a bit on the top-of-tree so I'll need to bring them up to date
and do some testing before I post. I think the newer version is
cleaner than the last but can still probably use some improvement.
I've also got a patch that enables larger physical addressing in
general - it changes the page table/mmu handling to allow for larger
physical addresses on MPC8641; BookE parts will need a slightly
different set of changes (some of which are already in place, but I've
not done any work/testing on BookE at this point). I'll try to get a
version of that out this week as well - it needs some cleanup and
testing on the latest tree.
Cheers,
Becky
^ permalink raw reply
* Re: [git pull] Please pull powerpc.git master branch
From: Linus Torvalds @ 2008-04-29 15:21 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev, akpm, linux-kernel
In-Reply-To: <18455.1713.268188.906051@cargo.ozlabs.ibm.com>
On Tue, 29 Apr 2008, Paul Mackerras wrote:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/paulus/powerpc.git master
Umm, where did the diffstat go? I really want to see it to compare against
what I get. I checked the shortlog and everything matches, but please,
keep the diffstat coming too.
Linus
^ permalink raw reply
* Re: [PATCH] devres: support addresses greater than an unsigned long via dev_ioremap
From: Greg KH @ 2008-04-29 15:23 UTC (permalink / raw)
To: Kumar Gala
Cc: Andrew Morton, Tejun Heo, lkml Mailing List, Jesse Barnes,
linuxppc-dev@ozlabs.org list, Jeff Garzik
In-Reply-To: <C415A4D5-CE5A-4E48-B5D5-0B9A6C7A5CA6@kernel.crashing.org>
On Tue, Apr 29, 2008 at 09:08:14AM -0500, Kumar Gala wrote:
>
> On Apr 29, 2008, at 1:37 AM, Jeff Garzik wrote:
>> Tejun Heo wrote:
>>> Kumar Gala wrote:
>>>> Use a resource_size_t instead of unsigned long since some arch's are
>>>> capable of having ioremap deal with addresses greater than the size of a
>>>> unsigned long.
>>>>
>>>> Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
>>> Acked-by: Tejun Heo <htejun@gmail.com>
>>
>> Fine with me, too.
>>
>> I think devres changes should go via GregKH (device core) or Jesse (PCI)
>> rather than my libata tree, unless there are obvious dependencies...
>
> GregKH will you handle pushing this to Linus. Its a pretty trivial patch
> and would be nice to go into 2.6.26. I would also consider it a bug fix of
> shorts for any driver using devres and resource_size_t being typedef'd to
> u64 on a 32-bit processor.
Sure, I'd be glad to. But I don't see the patch, care to resend it to
me?
thanks,
greg k-h
^ permalink raw reply
* [PATCH][RESEND] devres: support addresses greater than an unsigned long via dev_ioremap
From: Kumar Gala @ 2008-04-29 15:25 UTC (permalink / raw)
To: Greg KH
Cc: Andrew Morton, Tejun Heo, lkml Mailing List, Jesse Barnes,
linuxppc-dev@ozlabs.org list, Jeff Garzik
In-Reply-To: <20080429152331.GC11329@kroah.com>
Use a resource_size_t instead of unsigned long since some arch's are
capable of having ioremap deal with addresses greater than the size of a
unsigned long.
Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
---
For GregKH to actually get the patch.
- k
include/linux/io.h | 4 ++--
lib/devres.c | 4 ++--
2 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/include/linux/io.h b/include/linux/io.h
index e3b2dda..831f57c 100644
--- a/include/linux/io.h
+++ b/include/linux/io.h
@@ -58,9 +58,9 @@ static inline void devm_ioport_unmap(struct device *dev, void __iomem *addr)
}
#endif
-void __iomem * devm_ioremap(struct device *dev, unsigned long offset,
+void __iomem * devm_ioremap(struct device *dev, resource_size_t offset,
unsigned long size);
-void __iomem * devm_ioremap_nocache(struct device *dev, unsigned long offset,
+void __iomem * devm_ioremap_nocache(struct device *dev, resource_size_t offset,
unsigned long size);
void devm_iounmap(struct device *dev, void __iomem *addr);
int check_signature(const volatile void __iomem *io_addr,
diff --git a/lib/devres.c b/lib/devres.c
index edc27a5..26c87c4 100644
--- a/lib/devres.c
+++ b/lib/devres.c
@@ -20,7 +20,7 @@ static int devm_ioremap_match(struct device *dev, void *res, void *match_data)
*
* Managed ioremap(). Map is automatically unmapped on driver detach.
*/
-void __iomem *devm_ioremap(struct device *dev, unsigned long offset,
+void __iomem *devm_ioremap(struct device *dev, resource_size_t offset,
unsigned long size)
{
void __iomem **ptr, *addr;
@@ -49,7 +49,7 @@ EXPORT_SYMBOL(devm_ioremap);
* Managed ioremap_nocache(). Map is automatically unmapped on driver
* detach.
*/
-void __iomem *devm_ioremap_nocache(struct device *dev, unsigned long offset,
+void __iomem *devm_ioremap_nocache(struct device *dev, resource_size_t offset,
unsigned long size)
{
void __iomem **ptr, *addr;
--
1.5.4.1
^ permalink raw reply related
* [PATCH] IB/ehca: Allocate event queue size depending on max number of CQs and QPs
From: Stefan Roscher @ 2008-04-29 15:44 UTC (permalink / raw)
To: LinuxPPC-Dev, LKML, OF-General, Roland Dreier, OF-EWG; +Cc: fenkes, raisch
Signed-off-by: Stefan Roscher <stefan.roscher at de.ibm.com>
---
drivers/infiniband/hw/ehca/ehca_classes.h | 5 ++++
drivers/infiniband/hw/ehca/ehca_cq.c | 10 ++++++++
drivers/infiniband/hw/ehca/ehca_main.c | 36 +++++++++++++++++++++++++++-
drivers/infiniband/hw/ehca/ehca_qp.c | 10 ++++++++
4 files changed, 59 insertions(+), 2 deletions(-)
diff --git a/drivers/infiniband/hw/ehca/ehca_classes.h b/drivers/infiniband/hw/ehca/ehca_classes.h
index 3d6d946..00bab60 100644
--- a/drivers/infiniband/hw/ehca/ehca_classes.h
+++ b/drivers/infiniband/hw/ehca/ehca_classes.h
@@ -66,6 +66,7 @@ struct ehca_av;
#include "ehca_irq.h"
#define EHCA_EQE_CACHE_SIZE 20
+#define EHCA_MAX_NUM_QUEUES 0xffff
struct ehca_eqe_cache_entry {
struct ehca_eqe *eqe;
@@ -127,6 +128,8 @@ struct ehca_shca {
/* MR pgsize: bit 0-3 means 4K, 64K, 1M, 16M respectively */
u32 hca_cap_mr_pgsize;
int max_mtu;
+ atomic_t num_cqs;
+ atomic_t num_qps;
};
struct ehca_pd {
@@ -344,6 +347,8 @@ extern int ehca_use_hp_mr;
extern int ehca_scaling_code;
extern int ehca_lock_hcalls;
extern int ehca_nr_ports;
+extern int ehca_max_cq;
+extern int ehca_max_qp;
struct ipzu_queue_resp {
u32 qe_size; /* queue entry size */
diff --git a/drivers/infiniband/hw/ehca/ehca_cq.c b/drivers/infiniband/hw/ehca/ehca_cq.c
index ec0cfcf..5b4f9a3 100644
--- a/drivers/infiniband/hw/ehca/ehca_cq.c
+++ b/drivers/infiniband/hw/ehca/ehca_cq.c
@@ -132,6 +132,14 @@ struct ib_cq *ehca_create_cq(struct ib_device *device, int cqe, int comp_vector,
if (cqe >= 0xFFFFFFFF - 64 - additional_cqe)
return ERR_PTR(-EINVAL);
+ if (atomic_read(&shca->num_cqs) >= ehca_max_cq) {
+ ehca_err(device, "Unable to create CQ, max number of %i "
+ "CQs reached.", ehca_max_cq);
+ ehca_err(device, "To increase the maximum number of CQs "
+ "use the number_of_cqs module parameter.\n");
+ return ERR_PTR(-ENOSPC);
+ }
+
my_cq = kmem_cache_zalloc(cq_cache, GFP_KERNEL);
if (!my_cq) {
ehca_err(device, "Out of memory for ehca_cq struct device=%p",
@@ -286,6 +294,7 @@ struct ib_cq *ehca_create_cq(struct ib_device *device, int cqe, int comp_vector,
}
}
+ atomic_inc(&shca->num_cqs);
return cq;
create_cq_exit4:
@@ -359,6 +368,7 @@ int ehca_destroy_cq(struct ib_cq *cq)
ipz_queue_dtor(NULL, &my_cq->ipz_queue);
kmem_cache_free(cq_cache, my_cq);
+ atomic_dec(&shca->num_cqs);
return 0;
}
diff --git a/drivers/infiniband/hw/ehca/ehca_main.c b/drivers/infiniband/hw/ehca/ehca_main.c
index 6504897..401907f 100644
--- a/drivers/infiniband/hw/ehca/ehca_main.c
+++ b/drivers/infiniband/hw/ehca/ehca_main.c
@@ -68,6 +68,8 @@ int ehca_port_act_time = 30;
int ehca_static_rate = -1;
int ehca_scaling_code = 0;
int ehca_lock_hcalls = -1;
+int ehca_max_cq = -1;
+int ehca_max_qp = -1;
module_param_named(open_aqp1, ehca_open_aqp1, bool, S_IRUGO);
module_param_named(debug_level, ehca_debug_level, int, S_IRUGO);
@@ -79,6 +81,8 @@ module_param_named(poll_all_eqs, ehca_poll_all_eqs, bool, S_IRUGO);
module_param_named(static_rate, ehca_static_rate, int, S_IRUGO);
module_param_named(scaling_code, ehca_scaling_code, bool, S_IRUGO);
module_param_named(lock_hcalls, ehca_lock_hcalls, bool, S_IRUGO);
+module_param_named(number_of_cqs, ehca_max_cq, int, S_IRUGO);
+module_param_named(number_of_qps, ehca_max_qp, int, S_IRUGO);
MODULE_PARM_DESC(open_aqp1,
"Open AQP1 on startup (default: no)");
@@ -104,6 +108,12 @@ MODULE_PARM_DESC(scaling_code,
MODULE_PARM_DESC(lock_hcalls,
"Serialize all hCalls made by the driver "
"(default: autodetect)");
+MODULE_PARM_DESC(number_of_cqs,
+ "Max number of CQs which can be allocated "
+ "(default: autodetect)");
+MODULE_PARM_DESC(number_of_qps,
+ "Max number of QPs which can be allocated "
+ "(default: autodetect)");
DEFINE_RWLOCK(ehca_qp_idr_lock);
DEFINE_RWLOCK(ehca_cq_idr_lock);
@@ -355,6 +365,25 @@ static int ehca_sense_attributes(struct ehca_shca *shca)
if (rblock->memory_page_size_supported & pgsize_map[i])
shca->hca_cap_mr_pgsize |= pgsize_map[i + 1];
+ /* Set maximum number of CQs and QPs to calculate EQ size */
+ if (ehca_max_qp == -1)
+ ehca_max_qp = min_t(int, rblock->max_qp, EHCA_MAX_NUM_QUEUES);
+ else if (ehca_max_qp < 1 || ehca_max_qp > rblock->max_qp) {
+ ehca_gen_err("Requested number of QPs is out of range (1 - %i) "
+ "specified by HW", rblock->max_qp);
+ ret = -EINVAL;
+ goto sense_attributes1;
+ }
+
+ if (ehca_max_cq == -1)
+ ehca_max_cq = min_t(int, rblock->max_cq, EHCA_MAX_NUM_QUEUES);
+ else if (ehca_max_cq < 1 || ehca_max_cq > rblock->max_cq) {
+ ehca_gen_err("Requested number of CQs is out of range (1 - %i) "
+ "specified by HW", rblock->max_cq);
+ ret = -EINVAL;
+ goto sense_attributes1;
+ }
+
/* query max MTU from first port -- it's the same for all ports */
port = (struct hipz_query_port *)rblock;
h_ret = hipz_h_query_port(shca->ipz_hca_handle, 1, port);
@@ -684,7 +713,7 @@ static int __devinit ehca_probe(struct of_device *dev,
struct ehca_shca *shca;
const u64 *handle;
struct ib_pd *ibpd;
- int ret, i;
+ int ret, i, eq_size;
handle = of_get_property(dev->node, "ibm,hca-handle", NULL);
if (!handle) {
@@ -705,6 +734,8 @@ static int __devinit ehca_probe(struct of_device *dev,
return -ENOMEM;
}
mutex_init(&shca->modify_mutex);
+ atomic_set(&shca->num_cqs, 0);
+ atomic_set(&shca->num_qps, 0);
for (i = 0; i < ARRAY_SIZE(shca->sport); i++)
spin_lock_init(&shca->sport[i].mod_sqp_lock);
@@ -724,8 +755,9 @@ static int __devinit ehca_probe(struct of_device *dev,
goto probe1;
}
+ eq_size = 2 * ehca_max_cq + 4 * ehca_max_qp;
/* create event queues */
- ret = ehca_create_eq(shca, &shca->eq, EHCA_EQ, 2048);
+ ret = ehca_create_eq(shca, &shca->eq, EHCA_EQ, eq_size);
if (ret) {
ehca_err(&shca->ib_device, "Cannot create EQ.");
goto probe1;
diff --git a/drivers/infiniband/hw/ehca/ehca_qp.c b/drivers/infiniband/hw/ehca/ehca_qp.c
index 57bef11..73d9c4a 100644
--- a/drivers/infiniband/hw/ehca/ehca_qp.c
+++ b/drivers/infiniband/hw/ehca/ehca_qp.c
@@ -421,6 +421,14 @@ static struct ehca_qp *internal_create_qp(
u32 swqe_size = 0, rwqe_size = 0, ib_qp_num;
unsigned long flags;
+ if (atomic_read(&shca->num_qps) >= ehca_max_qp) {
+ ehca_err(pd->device, "Unable to create QP, max number of %i "
+ "QPs reached.", ehca_max_qp);
+ ehca_err(pd->device, "To increase the maximum number of QPs "
+ "use the number_of_qps module parameter.\n");
+ return ERR_PTR(-ENOSPC);
+ }
+
if (init_attr->create_flags)
return ERR_PTR(-EINVAL);
@@ -797,6 +805,7 @@ static struct ehca_qp *internal_create_qp(
}
}
+ atomic_inc(&shca->num_qps);
return my_qp;
create_qp_exit6:
@@ -1948,6 +1957,7 @@ static int internal_destroy_qp(struct ib_device *dev, struct ehca_qp *my_qp,
if (HAS_SQ(my_qp))
ipz_queue_dtor(my_pd, &my_qp->ipz_squeue);
kmem_cache_free(qp_cache, my_qp);
+ atomic_dec(&shca->num_qps);
return 0;
}
--
1.5.5
^ permalink raw reply related
* RE: Virtex4FX12LC hangs in calibrating delay loop
From: Stephen Neuendorffer @ 2008-04-29 15:47 UTC (permalink / raw)
To: wangyanlong, linuxppc-embedded
In-Reply-To: <16955743.post@talk.nabble.com>
[-- Attachment #1: Type: text/plain, Size: 2364 bytes --]
I think I've seen this happen when the boot code doesn't have the workarounds for the cache errata. I'm not sure if that code ever made
it into grant's git server, but it's definitely is in the xilinx git tree at git.xilinx.com.
Steve
-----Original Message-----
From: linuxppc-embedded-bounces+stephen=neuendorffer.name@ozlabs.org on behalf of wangyanlong
Sent: Tue 4/29/2008 1:53 AM
To: linuxppc-embedded@ozlabs.org
Subject: Re: Virtex4FX12LC hangs in calibrating delay loop
I meet the same problem as yours , have you fix your problem now ??? I am
keep trying !!!!
Thomas Glanzmann wrote:
>
> Hello,
> I used the HEAD secretlabs kernel and used ml403 defconfig. I still see
> no serial output from the _kernel_ on the serial console. But I do see
> output from the in kernel embedded boot loader "load_kernel". I typed in
> stop in xmd and got an instruction pointer which points to:
>
> c00045a0 <__delay>:
> c00045a0: 2c 03 00 00 cmpwi r3,0
> c00045a4: 7c 69 03 a6 mtctr r3
> c00045a8: 4d 82 00 20 beqlr
> c00045ac: 42 00 00 00 bdnz- c00045ac <__delay+0xc>
> <<<<<<<<
> c00045b0: 4e 80 00 20 blr
>
> So I guess it is the calibrating delay loop and I am not sure. I can
> reproduce
> this. It is always in this function. Now I wonder is my board missing
> timer interrupts? What could be the reason for this. And of course one
> much more important question:
>
> - Is the serial console initialized before or after the
> calibrating delay loop?
>
> Is there a way to get a backtrace out of this? If that is the case what
> do I have to do? Recompile the Kernel with frame pointers and attach
> gdb?
>
> Thomas
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>
>
--
View this message in context: http://www.nabble.com/Virtex4FX12LC-hangs-in-calibrating-delay-loop-tp11235297p16955743.html
Sent from the linuxppc-embedded mailing list archive at Nabble.com.
_______________________________________________
Linuxppc-embedded mailing list
Linuxppc-embedded@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-embedded
[-- Attachment #2: Type: text/html, Size: 4076 bytes --]
^ permalink raw reply
* [PATCH 1/3] [NET] uli526x: initialize the hardware prior to requesting interrupts
From: Anton Vorontsov @ 2008-04-29 15:53 UTC (permalink / raw)
To: Jeff Garzik; +Cc: netdev, linuxppc-dev
The firmware on MPC8610HPCD boards enables ULI ethernet and leaves it
in some funky state before booting Linux. For drivers, it's always good
idea to (re)initialize the hardware prior to requesting interrupts.
This patch fixes the following oops:
Oops: Kernel access of bad area, sig: 11 [#1]
MPC86xx HPCD
NIP: c0172820 LR: c017287c CTR: 00000000
[...]
NIP [c0172820] allocate_rx_buffer+0x2c/0xb0
LR [c017287c] allocate_rx_buffer+0x88/0xb0
Call Trace:
[df82bdc0] [c017287c] allocate_rx_buffer+0x88/0xb0 (unreliable)
[df82bde0] [c0173000] uli526x_interrupt+0xe4/0x49c
[df82be20] [c0045418] request_irq+0xf0/0x114
[df82be50] [c01737b0] uli526x_open+0x48/0x160
[df82be70] [c0201184] dev_open+0xb0/0xe8
[df82be80] [c0200104] dev_change_flags+0x90/0x1bc
[df82bea0] [c035fab0] ip_auto_config+0x214/0xef4
[df82bf60] [c03421c8] kernel_init+0xc4/0x2ac
[df82bff0] [c0010834] kernel_thread+0x44/0x60
Instruction dump:
4e800020 9421ffe0 7c0802a6 bfa10014 7c7e1b78 90010024 80030060 83e30054
2b80002f 419d0078 3fa0c039 48000058 <907f0010> 80630088 2f830000 419e0014
Signed-off-by: Anton Vorontsov <avorontsov@ru.mvista.com>
---
drivers/net/tulip/uli526x.c | 8 ++++----
1 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/net/tulip/uli526x.c b/drivers/net/tulip/uli526x.c
index a59c1f2..1f077ac 100644
--- a/drivers/net/tulip/uli526x.c
+++ b/drivers/net/tulip/uli526x.c
@@ -434,10 +434,6 @@ static int uli526x_open(struct net_device *dev)
ULI526X_DBUG(0, "uli526x_open", 0);
- ret = request_irq(dev->irq, &uli526x_interrupt, IRQF_SHARED, dev->name, dev);
- if (ret)
- return ret;
-
/* system variable init */
db->cr6_data = CR6_DEFAULT | uli526x_cr6_user_set;
db->tx_packet_cnt = 0;
@@ -456,6 +452,10 @@ static int uli526x_open(struct net_device *dev)
/* Initialize ULI526X board */
uli526x_init(dev);
+ ret = request_irq(dev->irq, &uli526x_interrupt, IRQF_SHARED, dev->name, dev);
+ if (ret)
+ return ret;
+
/* Active System Interface */
netif_wake_queue(dev);
--
1.5.5.1
^ permalink raw reply related
* [PATCH 2/3] [NET] uli526x: fix endianness issues in the setup frame
From: Anton Vorontsov @ 2008-04-29 15:53 UTC (permalink / raw)
To: Jeff Garzik; +Cc: netdev, linuxppc-dev
This patch fixes uli526x driver's issues on a PowerPC boards: uli chip
is unable to receive the packets.
It appears that send_frame_filter prepares the setup frame in the
endianness unsafe manner. On a big endian machines we should shift
the address nibble by two bytes.
Signed-off-by: Anton Vorontsov <avorontsov@ru.mvista.com>
---
drivers/net/tulip/uli526x.c | 30 ++++++++++++++++++------------
1 files changed, 18 insertions(+), 12 deletions(-)
diff --git a/drivers/net/tulip/uli526x.c b/drivers/net/tulip/uli526x.c
index 1f077ac..2511ca7 100644
--- a/drivers/net/tulip/uli526x.c
+++ b/drivers/net/tulip/uli526x.c
@@ -1368,6 +1368,12 @@ static void update_cr6(u32 cr6_data, unsigned long ioaddr)
* This setup frame initialize ULI526X address filter mode
*/
+#ifdef __BIG_ENDIAN
+#define FLT_SHIFT 16
+#else
+#define FLT_SHIFT 0
+#endif
+
static void send_filter_frame(struct net_device *dev, int mc_cnt)
{
struct uli526x_board_info *db = netdev_priv(dev);
@@ -1384,27 +1390,27 @@ static void send_filter_frame(struct net_device *dev, int mc_cnt)
/* Node address */
addrptr = (u16 *) dev->dev_addr;
- *suptr++ = addrptr[0];
- *suptr++ = addrptr[1];
- *suptr++ = addrptr[2];
+ *suptr++ = addrptr[0] << FLT_SHIFT;
+ *suptr++ = addrptr[1] << FLT_SHIFT;
+ *suptr++ = addrptr[2] << FLT_SHIFT;
/* broadcast address */
- *suptr++ = 0xffff;
- *suptr++ = 0xffff;
- *suptr++ = 0xffff;
+ *suptr++ = 0xffff << FLT_SHIFT;
+ *suptr++ = 0xffff << FLT_SHIFT;
+ *suptr++ = 0xffff << FLT_SHIFT;
/* fit the multicast address */
for (mcptr = dev->mc_list, i = 0; i < mc_cnt; i++, mcptr = mcptr->next) {
addrptr = (u16 *) mcptr->dmi_addr;
- *suptr++ = addrptr[0];
- *suptr++ = addrptr[1];
- *suptr++ = addrptr[2];
+ *suptr++ = addrptr[0] << FLT_SHIFT;
+ *suptr++ = addrptr[1] << FLT_SHIFT;
+ *suptr++ = addrptr[2] << FLT_SHIFT;
}
for (; i<14; i++) {
- *suptr++ = 0xffff;
- *suptr++ = 0xffff;
- *suptr++ = 0xffff;
+ *suptr++ = 0xffff << FLT_SHIFT;
+ *suptr++ = 0xffff << FLT_SHIFT;
+ *suptr++ = 0xffff << FLT_SHIFT;
}
/* prepare the setup frame */
--
1.5.5.1
^ permalink raw reply related
* [PATCH 3/3] [POWERPC] 86xx: mpc8610_hpcd: use ULI526X driver for on-board ethernet
From: Anton Vorontsov @ 2008-04-29 15:53 UTC (permalink / raw)
To: Kumar Gala; +Cc: netdev, Jeff Garzik, linuxppc-dev
As of current mainline tree, TULIP driver is unusable on MPC8610HPCD
boards. There is a patch[1] floating around (and also included in the
BSP), which tries to heal the situation, though the ethernet is still
unusable. Practically it takes ages to mount NFS filesystem:
VFS: Mounted root (nfs filesystem).
Freeing unused kernel memory: 180k init
nfs: server 10.0.0.2 not responding, still trying
nfs: server 10.0.0.2 OK
nfs: server 10.0.0.2 not responding, still trying
nfs: server 10.0.0.2 not responding, still trying
nfs: server 10.0.0.2 not responding, still trying
nfs: server 10.0.0.2 not responding, still trying
nfs: server 10.0.0.2 OK
nfs: server 10.0.0.2 not responding, still trying
So, instead of trying to add uli526x functionality into TULIP driver
(which is already bloated enough), I fixed existing ULI526X driver
and now it works perfectly well here.
[1] http://www.bitshrine.org/gpp/0024-MPC8610-ETH-Lyra-native-ethernet.txt
Signed-off-by: Anton Vorontsov <avorontsov@ru.mvista.com>
---
This is for powerpc tree.
arch/powerpc/configs/mpc8610_hpcd_defconfig | 7 ++-----
1 files changed, 2 insertions(+), 5 deletions(-)
diff --git a/arch/powerpc/configs/mpc8610_hpcd_defconfig b/arch/powerpc/configs/mpc8610_hpcd_defconfig
index 9270afe..f9e53bd 100644
--- a/arch/powerpc/configs/mpc8610_hpcd_defconfig
+++ b/arch/powerpc/configs/mpc8610_hpcd_defconfig
@@ -567,14 +567,11 @@ CONFIG_MII=y
# CONFIG_NET_VENDOR_3COM is not set
CONFIG_NET_TULIP=y
# CONFIG_DE2104X is not set
-CONFIG_TULIP=y
-# CONFIG_TULIP_MWI is not set
-CONFIG_TULIP_MMIO=y
-# CONFIG_TULIP_NAPI is not set
+# CONFIG_TULIP is not set
# CONFIG_DE4X5 is not set
# CONFIG_WINBOND_840 is not set
# CONFIG_DM9102 is not set
-# CONFIG_ULI526X is not set
+CONFIG_ULI526X=y
# CONFIG_HP100 is not set
# CONFIG_IBM_NEW_EMAC_ZMII is not set
# CONFIG_IBM_NEW_EMAC_RGMII is not set
--
1.5.5.1
^ permalink raw reply related
* Re: [PATCH] devres: support addresses greater than an unsigned long via dev_ioremap
From: Jon Loeliger @ 2008-04-29 15:56 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev@ozlabs.org list
In-Reply-To: <C415A4D5-CE5A-4E48-B5D5-0B9A6C7A5CA6@kernel.crashing.org>
Kumar Gala wrote:
>
> Its a pretty trivial
> patch and would be nice to go into 2.6.26. I would also consider it a
> bug fix of shorts for any driver
Looked like a bugfix of longs to me... :-)
jdl
^ permalink raw reply
* [PATCH] [IDE] alim15x3: disable init_hwif_ali15x3 for PowerPC
From: Anton Vorontsov @ 2008-04-29 16:19 UTC (permalink / raw)
To: Bartlomiej Zolnierkiewicz; +Cc: linux-ide, linuxppc-dev
We don't need init_hwif_ali15x3() on the PowerPC systems either.
Before:
ALI15X3: IDE controller (0x10b9:0x5229 rev 0xc8) at PCI slot 0001:03:1f.0
ALI15X3: 100% native mode on irq 19
ide0: BM-DMA at 0x1120-0x1127
ide1: BM-DMA at 0x1128-0x112f
hda: SONY DVD RW AW-Q170A, ATAPI CD/DVD-ROM drive
hda: UDMA/66 mode selected
ide0: Disabled unable to get IRQ 14.
ide0: failed to initialize IDE interface
ide1: Disabled unable to get IRQ 15.
ide1: failed to initialize IDE interface
After:
ALI15X3: IDE controller (0x10b9:0x5229 rev 0xc8) at PCI slot 0001:03:1f.0
ALI15X3: 100% native mode on irq 19
ide0: BM-DMA at 0x1120-0x1127
ide1: BM-DMA at 0x1128-0x112f
hda: SONY DVD RW AW-Q170A, ATAPI CD/DVD-ROM drive
hda: UDMA/66 mode selected
ide0 at 0x1100-0x1107,0x110a on irq 19
ide1 at 0x1110-0x1117,0x111a on irq 19
hda: ATAPI 48X DVD-ROM DVD-R CD-R/RW drive, 2048kB Cache
ide0 works well, though I can't test ide1, it isn't traced out on
the board.
Signed-off-by: Anton Vorontsov <avorontsov@ru.mvista.com>
---
drivers/ide/pci/alim15x3.c | 10 +++++-----
1 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/ide/pci/alim15x3.c b/drivers/ide/pci/alim15x3.c
index b36a22b..c1922f9 100644
--- a/drivers/ide/pci/alim15x3.c
+++ b/drivers/ide/pci/alim15x3.c
@@ -412,14 +412,14 @@ static u8 __devinit ali_cable_detect(ide_hwif_t *hwif)
return cbl;
}
-#ifndef CONFIG_SPARC64
+#if !defined(CONFIG_SPARC64) && !defined(CONFIG_PPC)
/**
* init_hwif_ali15x3 - Initialize the ALI IDE x86 stuff
* @hwif: interface to configure
*
* Obtain the IRQ tables for an ALi based IDE solution on the PC
* class platforms. This part of the code isn't applicable to the
- * Sparc systems
+ * Sparc and PowerPC systems.
*/
static void __devinit init_hwif_ali15x3 (ide_hwif_t *hwif)
@@ -463,7 +463,9 @@ static void __devinit init_hwif_ali15x3 (ide_hwif_t *hwif)
hwif->irq = irq;
}
}
-#endif
+#else
+#define init_hwif_ali15x3 NULL
+#endif /* !defined(CONFIG_SPARC64) && !defined(CONFIG_PPC) */
/**
* init_dma_ali15x3 - set up DMA on ALi15x3
@@ -517,9 +519,7 @@ static const struct ide_dma_ops ali_dma_ops = {
static const struct ide_port_info ali15x3_chipset __devinitdata = {
.name = "ALI15X3",
.init_chipset = init_chipset_ali15x3,
-#ifndef CONFIG_SPARC64
.init_hwif = init_hwif_ali15x3,
-#endif
.init_dma = init_dma_ali15x3,
.port_ops = &ali_port_ops,
.pio_mask = ATA_PIO5,
--
1.5.5.1
^ permalink raw reply related
* [PATCH] [POWERPC] 86xx: mpc8610_hpcd: add support for PCI Express x8 slot
From: Anton Vorontsov @ 2008-04-29 16:41 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev
This patch adds pcie node which is resposible for PCI-E x8 slot
functioning. Though, this was tested using only x1 SKY2 NIC.
Signed-off-by: Anton Vorontsov <avorontsov@ru.mvista.com>
---
arch/powerpc/boot/dts/mpc8610_hpcd.dts | 21 +++++++++++++++++++++
1 files changed, 21 insertions(+), 0 deletions(-)
diff --git a/arch/powerpc/boot/dts/mpc8610_hpcd.dts b/arch/powerpc/boot/dts/mpc8610_hpcd.dts
index 1f2f1e0..fff0572 100644
--- a/arch/powerpc/boot/dts/mpc8610_hpcd.dts
+++ b/arch/powerpc/boot/dts/mpc8610_hpcd.dts
@@ -21,6 +21,7 @@
serial1 = &serial1;
pci0 = &pci0;
pci1 = &pci1;
+ pci2 = &pci2;
};
cpus {
@@ -322,4 +323,24 @@
};
};
};
+
+ pci2: pcie@e0009000 {
+ #address-cells = <3>;
+ #size-cells = <2>;
+ #interrupt-cells = <1>;
+ device_type = "pci";
+ compatible = "fsl,mpc8641-pcie";
+ reg = <0xe0009000 0x00001000>;
+ ranges = <0x02000000 0 0x90000000 0x90000000 0 0x10000000
+ 0x01000000 0 0x00000000 0xe2000000 0 0x00100000>;
+ bus-range = <0 255>;
+ interrupt-map-mask = <0xf800 0 0 7>;
+ interrupt-map = <0x0000 0 0 1 &mpic 4 1
+ 0x0000 0 0 2 &mpic 5 1
+ 0x0000 0 0 3 &mpic 6 1
+ 0x0000 0 0 4 &mpic 7 1>;
+ interrupt-parent = <&mpic>;
+ interrupts = <25 2>;
+ clock-frequency = <33333333>;
+ };
};
--
1.5.5.1
^ permalink raw reply related
* Re: [PATCH] IB/ehca: Allocate event queue size depending on max number of CQs and QPs
From: Roland Dreier @ 2008-04-29 16:43 UTC (permalink / raw)
To: Stefan Roscher; +Cc: fenkes, LKML, OF-EWG, LinuxPPC-Dev, raisch, OF-General
In-Reply-To: <200804291744.17235.ossrosch@linux.vnet.ibm.com>
>
> Signed-off-by: Stefan Roscher <stefan.roscher at de.ibm.com>
Kind of an inadequate changelog ;)
Is this a fix or an enhancement or what?
> + if (atomic_read(&shca->num_cqs) >= ehca_max_cq) {
> + if (atomic_read(&shca->num_qps) >= ehca_max_qp) {
These are racy in the sense that multiple simultaneous calls to
create_cq/create_qp might end up exceeding the ehca_max_cq limit. Is
that an issue?
You could close the race by using atomic_add_unless() and testing the
return value (and being careful to do atomic_dec() on error paths after
you bump num_cqs/num_qps).
- R.
^ permalink raw reply
* EXT_IRQ0 @ MPC834x
From: Andre Schwarz @ 2008-04-29 16:44 UTC (permalink / raw)
To: linux-ppc list
All,
actually I'm having trouble getting the IRQ0 work on a MPC8343 with
2.6.25-rc8.
There's an external PCI device connected to it ....
Regarding to the manual IRQ0 is somewhat special and has Vector 48 assigned.
Therefore my dts entry for this device looks like :
interrupt-map = <0x5800 0 0 1 &ipic 0x30 0x8
... >;
Having a look on virq mapping gives :
mvBL-M7> cat /sys/kernel/debug/powerpc/virq_mapping
virq hwirq chip name host name
16 0x0000e IPIC /soc@e0000000/pic@700
17 0x0000f IPIC /soc@e0000000/pic@700
18 0x00009 IPIC /soc@e0000000/pic@700
20 0x00010 IPIC /soc@e0000000/pic@700
32 0x00020 IPIC /soc@e0000000/pic@700
33 0x00021 IPIC /soc@e0000000/pic@700
34 0x00022 IPIC /soc@e0000000/pic@700
38 0x00026 IPIC /soc@e0000000/pic@700
48 0x00030 IPIC /soc@e0000000/pic@700
After loading the device driver (=mvbcdma) the irq shows up correctly.
mvBL-M7> cat /proc/interrupts
CPU0
16: 603 IPIC Level i2c-mpc
17: 8 IPIC Level i2c-mpc
18: 295 IPIC Level serial
20: 341 IPIC Level mpc83xx_spi
32: 2 IPIC Level enet_tx
33: 3 IPIC Level enet_rx
34: 0 IPIC Level enet_error
38: 0 IPIC Level ehci_hcd:usb1
48: 0 IPIC Level mvbcdma0
BAD: 0
As soon as the device generates an interrupt I get :
irq 48: nobody cared (try booting with the "irqpoll" option)
handlers:
[<d18d66e8>] (mvbcdma_irq+0x0/0x180 [mvbcdma])
Disabling IRQ #48
The handler _would_ have returned IRQ_RETVAL(1).
Obviously the handler isn't called at all - but why ?
Using "nm" on the kernel module gives :
000006e8 t mvbcdma_irq
->offset 0x6e8 inside module matches with output regarding handler.
Any help is welcome !
regards,
Andre Schwarz
MATRIX VISION GmbH, Talstraße 16, DE-71570 Oppenweiler - Registergericht: Amtsgericht Stuttgart, HRB 271090
Geschäftsführer: Gerhard Thullner, Werner Armingeon, Uwe Furtner
^ permalink raw reply
* [PATCH] Fix a potential issue in mpc52xx uart driver
From: Andrew Liu @ 2008-04-29 7:36 UTC (permalink / raw)
To: grant.likely, tnt; +Cc: linuxppc-dev
mpc52xx_uart_int and __uart_put_char both try to acquire the
port->lock. Therefore the function sequence of:
mpc52xx_uart_int--> ...-->flush_to_ldisc-->...-->__uart_put_char
can potentially trigger a deadlock. To avoid this deadlock a fix
similar to that found in the 8250.c serial driver is applied. The
deadlock is avoided by releasing the lock before pushing a buffer
and reacquiring it when completed.
Signed-off-by: Andrew Liu <shengping.liu@windriver.com>
diff --git a/drivers/serial/mpc52xx_uart.c b/drivers/serial/mpc52xx_uart.c
index d93b357..5f95e53 100644
--- a/drivers/serial/mpc52xx_uart.c
+++ b/drivers/serial/mpc52xx_uart.c
@@ -783,7 +783,9 @@ mpc52xx_uart_int_rx_chars(struct uart_port *port)
}
}
+ spin_unlock(&port->lock);
tty_flip_buffer_push(tty);
+ spin_lock(&port->lock);
return psc_ops->raw_rx_rdy(port);
}
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox