[PATCH] devres: support addresses greater than an unsigned long via dev_ioremap

2008-04-29 Thread Kumar Gala
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 [EMAIL PROTECTED]
---
 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

___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev


build failure on efika

2008-04-29 Thread Paul Mackerras
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?

Paul.
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev


Re: [PATCH] devres: support addresses greater than an unsigned long via dev_ioremap

2008-04-29 Thread Tejun Heo

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 [EMAIL PROTECTED]


Acked-by: Tejun Heo [EMAIL PROTECTED]

Thanks.

--
tejun
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev


Re: [PATCH] devres: support addresses greater than an unsigned long via dev_ioremap

2008-04-29 Thread Jeff Garzik

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 [EMAIL PROTECTED]


Acked-by: Tejun Heo [EMAIL PROTECTED]


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...


Jeff



___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev


[no subject]

2008-04-29 Thread Chen Gong
this patch only makes a few fixes for latest kernel git tree
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev


[PATCH] Watchdog on MPC85xx SMP system

2008-04-29 Thread Chen Gong
On Book-E SMP systems each core has its own private watchdog.
If only one watchdog is enabled, when the core that doesn't
enable the watchdog is hung, system can't reset because no
watchdog is running on it. That's bad. It means we must
enable watchdogs on both cores.

We can use smp_call_function() to send appropriate messages to
all the other cores to enable and update the watchdog.

Signed-off-by: Chen Gong [EMAIL PROTECTED]
---
Now Tested on MPC8572DS platform.

 drivers/watchdog/booke_wdt.c |   31 +++
 1 files changed, 23 insertions(+), 8 deletions(-)

diff --git a/drivers/watchdog/booke_wdt.c b/drivers/watchdog/booke_wdt.c
index d362f5b..8a4e7f0 100644
--- a/drivers/watchdog/booke_wdt.c
+++ b/drivers/watchdog/booke_wdt.c
@@ -1,12 +1,12 @@
 /*
- * drivers/char/watchdog/booke_wdt.c
+ * drivers/watchdog/booke_wdt.c
  *
  * Watchdog timer for PowerPC Book-E systems
  *
  * Author: Matthew McClintock
  * Maintainer: Kumar Gala [EMAIL PROTECTED]
  *
- * Copyright 2005 Freescale Semiconductor Inc.
+ * Copyright 2005, 2008 Freescale Semiconductor Inc.
  *
  * 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
@@ -16,6 +16,7 @@
 
 #include linux/module.h
 #include linux/fs.h
+#include linux/smp.h
 #include linux/miscdevice.h
 #include linux/notifier.h
 #include linux/watchdog.h
@@ -47,23 +48,31 @@ u32 booke_wdt_period = WDT_PERIOD_DEFAULT;
 #define WDTP(x)(TCR_WP(x))
 #endif
 
+static DEFINE_SPINLOCK(booke_wdt_lock);
+
+static void __booke_wdt_ping(void *data)
+{
+   mtspr(SPRN_TSR, TSR_ENW|TSR_WIS);
+}
+
 /*
  * booke_wdt_ping:
  */
 static __inline__ void booke_wdt_ping(void)
 {
-   mtspr(SPRN_TSR, TSR_ENW|TSR_WIS);
+   smp_call_function(__booke_wdt_ping, NULL, 0, 0);
+   __booke_wdt_ping(NULL);
 }
 
 /*
- * booke_wdt_enable:
+ * __booke_wdt_enable:
  */
-static __inline__ void booke_wdt_enable(void)
+static inline void __booke_wdt_enable(void *data)
 {
u32 val;
 
/* clear status before enabling watchdog */
-   booke_wdt_ping();
+   __booke_wdt_ping(NULL);
val = mfspr(SPRN_TCR);
val |= (TCR_WIE|TCR_WRC(WRC_CHIP)|WDTP(booke_wdt_period));
 
@@ -137,12 +146,15 @@ static int booke_wdt_ioctl (struct inode *inode, struct 
file *file,
  */
 static int booke_wdt_open (struct inode *inode, struct file *file)
 {
+   spin_lock(booke_wdt_lock);
if (booke_wdt_enabled == 0) {
booke_wdt_enabled = 1;
-   booke_wdt_enable();
+   __booke_wdt_enable(NULL);
+   smp_call_function(__booke_wdt_enable, NULL, 0, 0);
printk (KERN_INFO PowerPC Book-E Watchdog Timer Enabled 
(wdt_period=%d)\n,
booke_wdt_period);
}
+   spin_unlock(booke_wdt_lock);
 
return nonseekable_open(inode, file);
 }
@@ -183,11 +195,14 @@ static int __init booke_wdt_init(void)
return ret;
}
 
+   spin_lock(booke_wdt_lock);
if (booke_wdt_enabled == 1) {
printk (KERN_INFO PowerPC Book-E Watchdog Timer Enabled 
(wdt_period=%d)\n,
booke_wdt_period);
-   booke_wdt_enable();
+   __booke_wdt_enable(NULL);
+   smp_call_function(__booke_wdt_enable, NULL, 0, 0);
}
+   spin_unlock(booke_wdt_lock);
 
return ret;
 }
-- 
1.5.4

___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev


overloading existing PTRACE_GET_DEBUGREG/PTRACE_SET_DEBUGREG commands

2008-04-29 Thread Kumar Gala
It looks like when Anton added the PTRACE_GET_DEBUGREG/ 
PTRACE_SET_DEBUGREG he envisioned future chips having more than one  
IABR/DABR.


I'm wondering what the feeling is about using the commands for  
handling some of the sub-arch variants we have:


e300 (603 style machine) - adds IABR2, DABR2, IBCR (control) and DBCR  
(control).  We can use IABR1/2 (and DABR1/2) either as unique  
addresses or for various ranges (inclusive or exclusive)


Book-e class machines can have the following registers: DBCR[0-2],  
IAC1-4, DAC1-2, DVC1-2, DBSR.  IACs are roughly equivalent to IABRs,  
DACs are roughly equivalent to DABRs.  Booke has similar ability to  
the e300 to do inclusive, exclusive ranges as well as some other  
features.


My question is how to handle providing access to the debug resources  
we have on these other machine types.  Should we just use GET_DEBUGREG/ 
SET_DEBUGREG and specify what the buffers look like for these specific  
machine types?  Is it ok to overload the commands this way?  How does  
this play with utrace?


Also, what functionality can GDB take advantage of today?  Does it  
comprehend the idea of breakpoints or watchpoints that cover a range?


- k
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev


Re: [PATCH 2/2] Raise the upper limit of NR_CPUS and move the pacas into the BSS.

2008-04-29 Thread Arnd Bergmann
On Thursday 24 April 2008, Tony Breeds wrote:
 This patch adds the required functionality to fill in all pacas at runtime.
 
 With NR_CPUS=1024
 text    data     bss     dec     hex filename
  137 1704032       0 1704169  1a00e9 arch/powerpc/kernel/paca.o :Before
  121 1179744  524288 1704153  1a00d9 arch/powerpc/kernel/paca.o :After
 
 Also remove unneeded #includes from arch/powerpc/kernel/paca.c
 
 Signed-off-by: Tony Breeds [EMAIL PROTECTED]

Maybe we can go even further than this: Since it is now a substantial amount
of .bss, maybe the unused parts can be returned to the buddy allocator
using free_bootmem or similar once you know how many CPUs there are?

I know that this would be an evil hack, but it may still be worth it.
Your patch should certainly go in first though, freeing the memory would
be an additional extension.

Arnd 
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev


[PATCH 0/2 v2] i2c: Add support for device alias names

2008-04-29 Thread Jean Delvare
Hi all,

This is yesterday's patch set updated to apply cleanly (and hopefully
work) on top of 2.6.25-git13. Basically the only change since yesterday
is the sync with the rtc subsystem updates, which converted 3 drivers
(rtc-x1205, rtc-pcf8563 and rtc-isl1208).

The plan is to send this to Linus this evening. The more testing it
gets, the better. Thanks to Wolfram and Jochen for yesterday's test
reports!

-- 
Jean Delvare
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev


[PATCH 1/2 v2] i2c: Add support for device alias names

2008-04-29 Thread Jean Delvare
Based on earlier work by Jon Smirl and Jochen Friedrich.

This patch allows new-style i2c chip drivers to have alias names using
the official kernel aliasing system and MODULE_DEVICE_TABLE(). At this
point, the old i2c driver binding scheme (driver_name/type) is still
supported.

Signed-off-by: Jean Delvare [EMAIL PROTECTED]
Cc: Jochen Friedrich [EMAIL PROTECTED]
Cc: Jon Smirl [EMAIL PROTECTED]
Cc: Kay Sievers [EMAIL PROTECTED]
---
 Documentation/i2c/writing-clients  |3 +
 drivers/gpio/pca953x.c |3 +
 drivers/gpio/pcf857x.c |3 +
 drivers/hwmon/f75375s.c|8 ++--
 drivers/i2c/chips/ds1682.c |3 +
 drivers/i2c/chips/menelaus.c   |3 +
 drivers/i2c/chips/tps65010.c   |3 +
 drivers/i2c/chips/tsl2550.c|3 +
 drivers/i2c/i2c-core.c |   51 +++-
 drivers/media/video/cs5345.c   |3 +
 drivers/media/video/cs53l32a.c |3 +
 drivers/media/video/cx25840/cx25840-core.c |3 +
 drivers/media/video/m52790.c   |3 +
 drivers/media/video/msp3400-driver.c   |2 -
 drivers/media/video/mt9m001.c  |3 +
 drivers/media/video/mt9v022.c  |3 +
 drivers/media/video/saa7115.c  |3 +
 drivers/media/video/saa7127.c  |3 +
 drivers/media/video/saa717x.c  |3 +
 drivers/media/video/tcm825x.c  |3 +
 drivers/media/video/tlv320aic23b.c |3 +
 drivers/media/video/tuner-core.c   |3 +
 drivers/media/video/tvaudio.c  |2 -
 drivers/media/video/upd64031a.c|3 +
 drivers/media/video/upd64083.c |3 +
 drivers/media/video/v4l2-common.c  |5 +-
 drivers/media/video/vp27smpx.c |3 +
 drivers/media/video/wm8739.c   |3 +
 drivers/media/video/wm8775.c   |3 +
 drivers/rtc/rtc-ds1307.c   |3 +
 drivers/rtc/rtc-ds1374.c   |3 +
 drivers/rtc/rtc-isl1208.c  |2 -
 drivers/rtc/rtc-m41t80.c   |3 +
 drivers/rtc/rtc-pcf8563.c  |3 +
 drivers/rtc/rtc-rs5c372.c  |3 +
 drivers/rtc/rtc-s35390a.c  |3 +
 drivers/rtc/rtc-x1205.c|3 +
 include/linux/i2c.h|5 +-
 include/linux/mod_devicetable.h|   11 ++
 include/media/v4l2-common.h|4 +-
 include/media/v4l2-i2c-drv-legacy.h|2 -
 include/media/v4l2-i2c-drv.h   |2 -
 scripts/mod/file2alias.c   |   13 +++
 43 files changed, 146 insertions(+), 54 deletions(-)

--- linux-2.6.26-rc0.orig/Documentation/i2c/writing-clients 2008-04-29 
08:13:00.0 +0200
+++ linux-2.6.26-rc0/Documentation/i2c/writing-clients  2008-04-29 
08:37:43.0 +0200
@@ -164,7 +164,8 @@ I2C device drivers using this binding mo
 kind of driver in Linux:  they provide a probe() method to bind to
 those devices, and a remove() method to unbind.
 
-   static int foo_probe(struct i2c_client *client);
+   static int foo_probe(struct i2c_client *client,
+const struct i2c_device_id *id);
static int foo_remove(struct i2c_client *client);
 
 Remember that the i2c_driver does not create those client handles.  The
--- linux-2.6.26-rc0.orig/drivers/gpio/pca953x.c2008-04-29 
08:13:00.0 +0200
+++ linux-2.6.26-rc0/drivers/gpio/pca953x.c 2008-04-29 08:37:43.0 
+0200
@@ -192,7 +192,8 @@ static void pca953x_setup_gpio(struct pc
gc-owner = THIS_MODULE;
 }
 
-static int __devinit pca953x_probe(struct i2c_client *client)
+static int __devinit pca953x_probe(struct i2c_client *client,
+  const struct i2c_device_id *did)
 {
struct pca953x_platform_data *pdata;
struct pca953x_chip *chip;
--- linux-2.6.26-rc0.orig/drivers/gpio/pcf857x.c2008-04-29 
08:13:00.0 +0200
+++ linux-2.6.26-rc0/drivers/gpio/pcf857x.c 2008-04-29 08:37:43.0 
+0200
@@ -142,7 +142,8 @@ static void pcf857x_set16(struct gpio_ch
 
 /*-*/
 
-static int pcf857x_probe(struct i2c_client *client)
+static int pcf857x_probe(struct i2c_client *client,
+const struct i2c_device_id *id)
 {
struct pcf857x_platform_data*pdata;
struct pcf857x  *gpio;
--- linux-2.6.26-rc0.orig/drivers/hwmon/f75375s.c   2008-04-29 
08:13:00.0 +0200
+++ linux-2.6.26-rc0/drivers/hwmon/f75375s.c2008-04-29 08:37:43.0 
+0200
@@ -117,7 +117,8 @@ struct f75375_data {
 static int f75375_attach_adapter(struct i2c_adapter *adapter);
 static int f75375_detect(struct i2c_adapter *adapter, int address, int kind);
 

[PATCH 2/2 v2] i2c: Convert most new-style drivers to use module aliasing

2008-04-29 Thread Jean Delvare
Based on earlier work by Jon Smirl and Jochen Friedrich.

Update most new-style i2c drivers to use standard module aliasing
instead of the old driver_name/type driver matching scheme. I've
left the video drivers apart (except for SoC camera drivers) as
they're a bit more diffcult to deal with, they'll have their own
patch later.

Signed-off-by: Jean Delvare [EMAIL PROTECTED]
Cc: Jon Smirl [EMAIL PROTECTED]
Cc: Jochen Friedrich [EMAIL PROTECTED]
---
 arch/arm/mach-at91/board-csb337.c |3 -
 arch/arm/mach-at91/board-dk.c |3 -
 arch/arm/mach-at91/board-eb9200.c |3 -
 arch/arm/mach-iop32x/em7210.c |3 -
 arch/arm/mach-iop32x/glantank.c   |4 -
 arch/arm/mach-iop32x/n2100.c  |4 -
 arch/arm/mach-ixp4xx/dsmg600-setup.c  |2 
 arch/arm/mach-ixp4xx/nas100d-setup.c  |2 
 arch/arm/mach-ixp4xx/nslu2-setup.c|2 
 arch/arm/mach-omap1/board-h2.c|2 
 arch/arm/mach-omap1/board-h3.c|3 -
 arch/arm/mach-omap1/board-osk.c   |1 
 arch/arm/mach-orion5x/db88f5281-setup.c   |4 -
 arch/arm/mach-orion5x/dns323-setup.c  |7 --
 arch/arm/mach-orion5x/kurobox_pro-setup.c |4 -
 arch/arm/mach-orion5x/rd88f5182-setup.c   |4 -
 arch/arm/mach-orion5x/ts209-setup.c   |3 -
 arch/arm/mach-pxa/pcm990-baseboard.c  |5 -
 arch/blackfin/mach-bf533/boards/stamp.c   |3 -
 arch/blackfin/mach-bf537/boards/stamp.c   |3 -
 arch/blackfin/mach-bf548/boards/ezkit.c   |2 
 arch/powerpc/sysdev/fsl_soc.c |   27 --
 arch/sh/boards/renesas/migor/setup.c  |3 -
 arch/sh/boards/renesas/r7780rp/setup.c|3 -
 drivers/gpio/pca953x.c|   23 +---
 drivers/gpio/pcf857x.c|   33 +++-
 drivers/hwmon/f75375s.c   |   23 
 drivers/i2c/busses/i2c-taos-evm.c |3 -
 drivers/i2c/chips/ds1682.c|7 ++
 drivers/i2c/chips/menelaus.c  |7 ++
 drivers/i2c/chips/tps65010.c  |   29 --
 drivers/i2c/chips/tsl2550.c   |7 ++
 drivers/media/video/mt9m001.c |7 ++
 drivers/media/video/mt9v022.c |7 ++
 drivers/rtc/rtc-ds1307.c  |   63 +--
 drivers/rtc/rtc-ds1374.c  |7 ++
 drivers/rtc/rtc-isl1208.c |7 ++
 drivers/rtc/rtc-m41t80.c  |   78 +++--
 drivers/rtc/rtc-pcf8563.c |7 ++
 drivers/rtc/rtc-rs5c372.c |   24 
 drivers/rtc/rtc-s35390a.c |7 ++
 drivers/rtc/rtc-x1205.c   |7 ++
 include/linux/i2c.h   |   12 ++--
 43 files changed, 211 insertions(+), 247 deletions(-)

--- linux-2.6.26-rc0.orig/arch/arm/mach-at91/board-csb337.c 2008-04-29 
07:40:33.0 +0200
+++ linux-2.6.26-rc0/arch/arm/mach-at91/board-csb337.c  2008-04-29 
08:55:08.0 +0200
@@ -79,8 +79,7 @@ static struct at91_udc_data __initdata c
 
 static struct i2c_board_info __initdata csb337_i2c_devices[] = {
{
-   I2C_BOARD_INFO(rtc-ds1307, 0x68),
-   .type   = ds1307,
+   I2C_BOARD_INFO(ds1307, 0x68),
},
 };
 
--- linux-2.6.26-rc0.orig/arch/arm/mach-at91/board-dk.c 2008-04-28 
22:58:32.0 +0200
+++ linux-2.6.26-rc0/arch/arm/mach-at91/board-dk.c  2008-04-29 
08:55:08.0 +0200
@@ -132,8 +132,7 @@ static struct i2c_board_info __initdata 
I2C_BOARD_INFO(x9429, 0x28),
},
{
-   I2C_BOARD_INFO(at24c, 0x50),
-   .type   = 24c1024,
+   I2C_BOARD_INFO(24c1024, 0x50),
}
 };
 
--- linux-2.6.26-rc0.orig/arch/arm/mach-at91/board-eb9200.c 2008-04-28 
22:58:32.0 +0200
+++ linux-2.6.26-rc0/arch/arm/mach-at91/board-eb9200.c  2008-04-29 
08:55:08.0 +0200
@@ -93,8 +93,7 @@ static struct at91_mmc_data __initdata e
 
 static struct i2c_board_info __initdata eb9200_i2c_devices[] = {
{
-   I2C_BOARD_INFO(at24c, 0x50),
-   .type   = 24c512,
+   I2C_BOARD_INFO(24c512, 0x50),
},
 };
 
--- linux-2.6.26-rc0.orig/arch/arm/mach-iop32x/em7210.c 2008-04-28 
22:58:32.0 +0200
+++ linux-2.6.26-rc0/arch/arm/mach-iop32x/em7210.c  2008-04-29 
08:55:08.0 +0200
@@ -50,8 +50,7 @@ static struct sys_timer em7210_timer = {
  */
 static struct i2c_board_info __initdata em7210_i2c_devices[] = {
{
-   I2C_BOARD_INFO(rtc-rs5c372, 0x32),
-   .type = rs5c372a,
+   I2C_BOARD_INFO(rs5c372a, 0x32),
},
 };
 
--- linux-2.6.26-rc0.orig/arch/arm/mach-iop32x/glantank.c   2008-04-28 
22:58:32.0 +0200
+++ linux-2.6.26-rc0/arch/arm/mach-iop32x/glantank.c2008-04-29 
08:55:08.0 +0200
@@ -176,12 +176,10 @@ static struct f75375s_platform_data glan
 
 

[git pull] Please pull powerpc.git master branch

2008-04-29 Thread Paul Mackerras
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/remove
  [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=m

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 table
  [RAPIDIO] Add serial RapidIO controller support, which includes MPC8548, 
MPC8641
  [RAPIDIO] Add RapidIO connection info print out and re-training for 
broken connections
  [RAPIDIO] Change RapidIO doorbell source and target ID field to 16-bit

Étienne Bersac (1):
  [POWERPC] windfarm: Add PowerMac 12,1 support

___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev


Re: build failure on efika

2008-04-29 Thread Grant Likely
On Tue, Apr 29, 2008 at 12:27 AM, Paul Mackerras [EMAIL PROTECTED] 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.
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev


Re: [PATCH 1/2 v2] i2c: Add support for device alias names

2008-04-29 Thread Jon Smirl
On 4/29/08, Jean Delvare [EMAIL PROTECTED] 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
[EMAIL PROTECTED]
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev


[PATCH] [POWERPC] mpc5200: Fix unterminated of_device_id table

2008-04-29 Thread Grant Likely
From: Grant Likely [EMAIL PROTECTED]

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 [EMAIL PROTECTED]
---

 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

___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev


Re: [PATCH 1/2 v2] i2c: Add support for device alias names

2008-04-29 Thread Jean Delvare
Hi Jon,

On Tue, 29 Apr 2008 08:16:13 -0400, Jon Smirl wrote:
 On 4/29/08, Jean Delvare [EMAIL PROTECTED] 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
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev


Please pull linux-2.6-mpc52xx.git

2008-04-29 Thread Grant Likely
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

[EMAIL PROTECTED] (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.
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev


Re: 2.6.25: pmac_newworld undefined

2008-04-29 Thread Adrian Bunk
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

___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev


[PATCH] [POWERPC] convert transfer_to_handler into a macro

2008-04-29 Thread Kumar Gala
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 [EMAIL PROTECTED]
---

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); \
+   slwir9,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,[EMAIL PROTECTED];  
   \
+   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,[EMAIL PROTECTED]; \
+   tophys(r11,r11);   \
+   addir11,r11,[EMAIL PROTECTED];  
   \
+   SMP_ADJUST_GLOBAL_DBCR0;   \
+   lwz r12,0(r11);\
+   mtspr   SPRN_DBCR0,r12;\
+   lwz r12,4(r11);\
+   addir12,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).
+ */
+
+#defineTRANSFER_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;  

[PATCH] of/gpio: use dynamic base allocation

2008-04-29 Thread Anton Vorontsov
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 [EMAIL PROTECTED]
---
 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
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev


Re: [PATCH] devres: support addresses greater than an unsigned long via dev_ioremap

2008-04-29 Thread Kumar Gala


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 [EMAIL PROTECTED]

Acked-by: Tejun Heo [EMAIL PROTECTED]


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
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev


Re: Enabling 64 bit data type for dma_addr_t on non PPC64 architecture

2008-04-29 Thread Becky Bruce


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

___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev


Re: [git pull] Please pull powerpc.git master branch

2008-04-29 Thread Linus Torvalds


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
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev


Re: [PATCH] devres: support addresses greater than an unsigned long via dev_ioremap

2008-04-29 Thread Greg KH
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 [EMAIL PROTECTED]
 Acked-by: Tejun Heo [EMAIL PROTECTED]

 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
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev


[PATCH][RESEND] devres: support addresses greater than an unsigned long via dev_ioremap

2008-04-29 Thread Kumar Gala
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 [EMAIL PROTECTED]
---

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

___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev


[PATCH] IB/ehca: Allocate event queue size depending on max number of CQs and QPs

2008-04-29 Thread Stefan Roscher


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 0x
 
 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 = 0x - 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, 

[PATCH 1/3] [NET] uli526x: initialize the hardware prior to requesting interrupts

2008-04-29 Thread Anton Vorontsov
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: 
[...]
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 4858 907f0010 80630088 2f83 419e0014

Signed-off-by: Anton Vorontsov [EMAIL PROTECTED]
---
 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

___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev


[PATCH 2/3] [NET] uli526x: fix endianness issues in the setup frame

2008-04-29 Thread Anton Vorontsov
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 [EMAIL PROTECTED]
---
 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++ = 0x;
-   *suptr++ = 0x;
-   *suptr++ = 0x;
+   *suptr++ = 0x  FLT_SHIFT;
+   *suptr++ = 0x  FLT_SHIFT;
+   *suptr++ = 0x  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 (; i14; i++) {
-   *suptr++ = 0x;
-   *suptr++ = 0x;
-   *suptr++ = 0x;
+   *suptr++ = 0x  FLT_SHIFT;
+   *suptr++ = 0x  FLT_SHIFT;
+   *suptr++ = 0x  FLT_SHIFT;
}
 
/* prepare the setup frame */
-- 
1.5.5.1

___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev


[PATCH 3/3] [POWERPC] 86xx: mpc8610_hpcd: use ULI526X driver for on-board ethernet

2008-04-29 Thread Anton Vorontsov
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 [EMAIL PROTECTED]
---

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
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev


Re: [PATCH] devres: support addresses greater than an unsigned long via dev_ioremap

2008-04-29 Thread Jon Loeliger

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
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev


[PATCH] [IDE] alim15x3: disable init_hwif_ali15x3 for PowerPC

2008-04-29 Thread Anton Vorontsov
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 [EMAIL PROTECTED]
---
 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
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev


[PATCH] [POWERPC] 86xx: mpc8610_hpcd: add support for PCI Express x8 slot

2008-04-29 Thread Anton Vorontsov
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 [EMAIL PROTECTED]
---
 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: [EMAIL PROTECTED] {
+   #address-cells = 3;
+   #size-cells = 2;
+   #interrupt-cells = 1;
+   device_type = pci;
+   compatible = fsl,mpc8641-pcie;
+   reg = 0xe0009000 0x1000;
+   ranges = 0x0200 0 0x9000 0x9000 0 0x1000
+ 0x0100 0 0x 0xe200 0 0x0010;
+   bus-range = 0 255;
+   interrupt-map-mask = 0xf800 0 0 7;
+   interrupt-map = 0x 0 0 1 mpic 4 1
+0x 0 0 2 mpic 5 1
+0x 0 0 3 mpic 6 1
+0x 0 0 4 mpic 7 1;
+   interrupt-parent = mpic;
+   interrupts = 25 2;
+   clock-frequency = ;
+   };
 };
-- 
1.5.5.1
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev


Re: [PATCH] IB/ehca: Allocate event queue size depending on max number of CQs and QPs

2008-04-29 Thread Roland Dreier
  
  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.
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev


EXT_IRQ0 @ MPC834x

2008-04-29 Thread Andre Schwarz
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   hwirqchip namehost name
   16  0xe   IPIC/[EMAIL PROTECTED]/[EMAIL PROTECTED]
   17  0xf   IPIC/[EMAIL PROTECTED]/[EMAIL PROTECTED]
   18  0x9   IPIC/[EMAIL PROTECTED]/[EMAIL PROTECTED]
   20  0x00010   IPIC/[EMAIL PROTECTED]/[EMAIL PROTECTED]
   32  0x00020   IPIC/[EMAIL PROTECTED]/[EMAIL PROTECTED]
   33  0x00021   IPIC/[EMAIL PROTECTED]/[EMAIL PROTECTED]
   34  0x00022   IPIC/[EMAIL PROTECTED]/[EMAIL PROTECTED]
   38  0x00026   IPIC/[EMAIL PROTECTED]/[EMAIL PROTECTED]
   48  0x00030   IPIC/[EMAIL PROTECTED]/[EMAIL PROTECTED]


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 :

06e8 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
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev


[PATCH] Fix a potential issue in mpc52xx uart driver

2008-04-29 Thread Andrew Liu

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 [EMAIL PROTECTED]

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);
 }
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev


cross tool netbsd 3.0 target

2008-04-29 Thread Joel Parker
With the demo-ppc405.sh I can create a cross compiler for gnu/linux does anyone 
know how to build one for netbsd 3.0. (ie. what to put in for the target in the 
.dat file)

-- Joel Parker




  

Be a better friend, newshound, and 
know-it-all with Yahoo! Mobile.  Try it now.  
http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

Re: [PATCH 3/3] [POWERPC] 86xx: mpc8610_hpcd: use ULI526X driver for on-board ethernet

2008-04-29 Thread Kumar Gala


On Apr 29, 2008, at 10:53 AM, Anton Vorontsov wrote:

 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.


I'm assuming patches that fix the uli526x driver have been accepted by  
jeff.


- k
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev


[REPOST][PATCH] IB/ehca: Allocate event queue size depending on max number of CQs and QPs

2008-04-29 Thread Stefan Roscher
If a lot of QPs fall into Error state at once and the EQ of the respective
HCA is too small, it might overrun, causing the eHCA driver to stop
processing completion events and call application software's completion
handlers, effectively causing traffic to stop.

Fix this by limiting available QPs and CQs to a customizable max count,
and determining EQ size based on these counts and a worst-case assumption.

Signed-off-by: Stefan Roscher stefan.roscher at de.ibm.com
---

Reposted based on Roland's comments:
- use atomic_add_unless instead of atomic_read
- inf% changelog increase ;)

 drivers/infiniband/hw/ehca/ehca_classes.h |5 
 drivers/infiniband/hw/ehca/ehca_cq.c  |   11 +
 drivers/infiniband/hw/ehca/ehca_main.c|   36 +++-
 drivers/infiniband/hw/ehca/ehca_qp.c  |   26 +++-
 4 files changed, 74 insertions(+), 4 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 0x
 
 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..5540b27 100644
--- a/drivers/infiniband/hw/ehca/ehca_cq.c
+++ b/drivers/infiniband/hw/ehca/ehca_cq.c
@@ -132,10 +132,19 @@ struct ib_cq *ehca_create_cq(struct ib_device *device, 
int cqe, int comp_vector,
if (cqe = 0x - 64 - additional_cqe)
return ERR_PTR(-EINVAL);
 
+   if (!atomic_add_unless(shca-num_cqs, 1, 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,
 device);
+   atomic_dec(shca-num_cqs);
return ERR_PTR(-ENOMEM);
}
 
@@ -305,6 +314,7 @@ create_cq_exit2:
 create_cq_exit1:
kmem_cache_free(cq_cache, my_cq);
 
+   atomic_dec(shca-num_cqs);
return cq;
 }
 
@@ -359,6 +369,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..482103e 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])
  

Re: [REPOST][PATCH] IB/ehca: Allocate event queue size depending on max number of CQs and QPs

2008-04-29 Thread Roland Dreier
thanks, makes sense, applied.

fast turnaround too ;)
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev


Re: [PATCH] [POWERPC] convert transfer_to_handler into a macro

2008-04-29 Thread Scott Wood
On Tue, Apr 29, 2008 at 08:56:56AM -0500, Kumar Gala wrote:
 +#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); \
 + slwir9,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,[EMAIL PROTECTED];  
\

Can we use assembler macros rather than preprocessor macros to get rid of
the backslashes?

-Scott
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev


Re: [PATCH] Add fast little-endian switch system call

2008-04-29 Thread Christoph Hellwig
On Tue, Apr 29, 2008 at 08:40:47PM +0200, Wolfgang Denk wrote:
 This probably depends a bit on  the  performance  of  the  system  in
 question. Did you measure it - for example - on a 50 MHz MPC850 ?

You got a 64bit kernel to run on a MPC850? wow :)

Not sure what the slowest supported 64bit cpu is (RS64-II?), but Paul
might be right and in this case it really doesn't matter.

___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev


[PATCH 0/6 v4] Few more patches for Kumar's powerpc.git

2008-04-29 Thread Anton Vorontsov
Hi Kumar,

Here is the fourth version. Old one started to cause non trivial merge
conflicts.

Also, I re-exported the gtm_timer structure, so drivers could actually
use its irq member.

Thanks.

-- 
Anton Vorontsov
email: [EMAIL PROTECTED]
irc://irc.freenode.net/bd2
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev


[PATCH 1/6] [POWERPC] sysdev: implement FSL GTM support

2008-04-29 Thread Anton Vorontsov
GTM stands for General-purpose Timers Module and able to generate
timer{1,2,3,4} interrupts. These timers are used by the drivers that
need time precise interrupts (like for USB transactions scheduling for
the Freescale USB Host controller as found in some QE and CPM chips),
or these timers could be used as wakeup events from the CPU deep-sleep
mode.

Things unimplemented:
1. Cascaded (32 bit) timers (1-2, 3-4).
   This is straightforward to implement when needed, two timers should
   be marked as requested and configured as appropriate.
2. Super-cascaded (64 bit) timers (1-2-3-4).
   This is also straightforward to implement when needed, all timers
   should be marked as requested and configured as appropriate.

Signed-off-by: Anton Vorontsov [EMAIL PROTECTED]
---
 Documentation/powerpc/booting-without-of.txt |   37 +++-
 arch/powerpc/Kconfig |5 +
 arch/powerpc/sysdev/Makefile |1 +
 arch/powerpc/sysdev/fsl_gtm.c|  424 ++
 include/asm-powerpc/fsl_gtm.h|   47 +++
 5 files changed, 513 insertions(+), 1 deletions(-)
 create mode 100644 arch/powerpc/sysdev/fsl_gtm.c
 create mode 100644 include/asm-powerpc/fsl_gtm.h

diff --git a/Documentation/powerpc/booting-without-of.txt 
b/Documentation/powerpc/booting-without-of.txt
index 1d2a772..fc7a235 100644
--- a/Documentation/powerpc/booting-without-of.txt
+++ b/Documentation/powerpc/booting-without-of.txt
@@ -57,7 +57,10 @@ Table of Contents
   n) 4xx/Axon EMAC ethernet nodes
   o) Xilinx IP cores
   p) Freescale Synchronous Serial Interface
- q) USB EHCI controllers
+  q) USB EHCI controllers
+  r) Freescale Display Interface Unit
+  s) Freescale on board FPGA
+  t) Freescale General-purpose Timers Module
 
   VII - Marvell Discovery mv64[345]6x System Controller chips
 1) The /system-controller node
@@ -2870,6 +2873,38 @@ platforms are moved over to use the 
flattened-device-tree model.
reg = 0xe800 32;
};
 
+t) Freescale General-purpose Timers Module
+
+Required properties:
+  - compatible : should be
+fsl,chip-gtm, fsl,gtm for SOC GTMs
+fsl,chip-qe-gtm, fsl,qe-gtm, fsl,gtm for QE GTMs
+fsl,chip-cpm2-gtm, fsl,cpm2-gtm, fsl,gtm for CPM2 GTMs
+  - reg : should contain gtm registers location and length (0x40).
+  - interrupts : should contain four interrupts.
+  - interrupt-parent : interrupt source phandle.
+  - clock-frequency : specifies the frequency driving the timer.
+
+Example:
+
+[EMAIL PROTECTED] {
+   compatible = fsl,mpc8360-gtm, fsl,gtm;
+   reg = 0x500 0x40;
+   interrupts = 90 8 78 8 84 8 72 8;
+   interrupt-parent = ipic;
+   /* filled by u-boot */
+   clock-frequency = 0;
+};
+
+[EMAIL PROTECTED] {
+   compatible = fsl,mpc8360-qe-gtm, fsl,qe-gtm, fsl,gtm;
+   reg = 0x440 0x40;
+   interrupts = 12 13 14 15;
+   interrupt-parent = qeic;
+   /* filled by u-boot */
+   clock-frequency = 0;
+};
+
 VII - Marvell Discovery mv64[345]6x System Controller chips
 ===
 
diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
index 4e40c12..4070a78 100644
--- a/arch/powerpc/Kconfig
+++ b/arch/powerpc/Kconfig
@@ -538,6 +538,11 @@ config FSL_LBC
help
  Freescale Localbus support
 
+config FSL_GTM
+   bool
+   help
+ Freescale General-purpose Timers support
+
 # Yes MCA RS/6000s exist but Linux-PPC does not currently support any
 config MCA
bool
diff --git a/arch/powerpc/sysdev/Makefile b/arch/powerpc/sysdev/Makefile
index 6d386d0..9d3ddd2 100644
--- a/arch/powerpc/sysdev/Makefile
+++ b/arch/powerpc/sysdev/Makefile
@@ -13,6 +13,7 @@ obj-$(CONFIG_MMIO_NVRAM)  += mmio_nvram.o
 obj-$(CONFIG_FSL_SOC)  += fsl_soc.o
 obj-$(CONFIG_FSL_PCI)  += fsl_pci.o
 obj-$(CONFIG_FSL_LBC)  += fsl_lbc.o
+obj-$(CONFIG_FSL_GTM)  += fsl_gtm.o
 obj-$(CONFIG_RAPIDIO)  += fsl_rio.o
 obj-$(CONFIG_TSI108_BRIDGE)+= tsi108_pci.o tsi108_dev.o
 obj-$(CONFIG_QUICC_ENGINE) += qe_lib/
diff --git a/arch/powerpc/sysdev/fsl_gtm.c b/arch/powerpc/sysdev/fsl_gtm.c
new file mode 100644
index 000..8b35cc4
--- /dev/null
+++ b/arch/powerpc/sysdev/fsl_gtm.c
@@ -0,0 +1,424 @@
+/*
+ * Freescale General-purpose Timers Module
+ *
+ * Copyright (c) Freescale Semicondutor, Inc. 2006.
+ *   Shlomi Gridish [EMAIL PROTECTED]
+ *   Jerry Huang [EMAIL PROTECTED]
+ * Copyright (c) MontaVista Software, Inc. 2008.
+ *   Anton Vorontsov [EMAIL PROTECTED]
+ *
+ * This program is free software; you can redistribute  it and/or modify it
+ * under  the terms of  the GNU General  Public License as published by the
+ * Free Software Foundation;  either version 2 of the  License, or (at your
+ * option) any later version.
+ */
+
+#include linux/kernel.h

[PATCH 2/6] [POWERPC] QE: add support for QE USB clocks routing

2008-04-29 Thread Anton Vorontsov
This patch adds a function to the qe_lib to setup QE USB clocks routing.
To setup clocks safely, cmxgcr register needs locking, so I just reused
ucc_lock since it was used only to protect cmxgcr.

The idea behind placing clocks routing functions into the qe_lib is that
later we'll hopefully switch to the generic Linux Clock API, thus, for
example, FHCI driver may be used for QE and CPM chips without nasty #ifdefs.

This patch also fixes QE_USB_RESTART_TX command definition in the qe.h.

Signed-off-by: Anton Vorontsov [EMAIL PROTECTED]
---
 arch/powerpc/sysdev/qe_lib/Kconfig  |4 ++
 arch/powerpc/sysdev/qe_lib/Makefile |1 +
 arch/powerpc/sysdev/qe_lib/ucc.c|7 ++--
 arch/powerpc/sysdev/qe_lib/usb.c|   56 +++
 include/asm-powerpc/qe.h|   23 +-
 5 files changed, 87 insertions(+), 4 deletions(-)
 create mode 100644 arch/powerpc/sysdev/qe_lib/usb.c

diff --git a/arch/powerpc/sysdev/qe_lib/Kconfig 
b/arch/powerpc/sysdev/qe_lib/Kconfig
index adc6621..76ffbc4 100644
--- a/arch/powerpc/sysdev/qe_lib/Kconfig
+++ b/arch/powerpc/sysdev/qe_lib/Kconfig
@@ -20,3 +20,7 @@ config UCC
bool
default y if UCC_FAST || UCC_SLOW
 
+config QE_USB
+   bool
+   help
+ QE USB Host Controller support
diff --git a/arch/powerpc/sysdev/qe_lib/Makefile 
b/arch/powerpc/sysdev/qe_lib/Makefile
index 874fe1a..e9ff888 100644
--- a/arch/powerpc/sysdev/qe_lib/Makefile
+++ b/arch/powerpc/sysdev/qe_lib/Makefile
@@ -6,3 +6,4 @@ obj-$(CONFIG_QUICC_ENGINE)+= qe.o qe_ic.o qe_io.o
 obj-$(CONFIG_UCC)  += ucc.o
 obj-$(CONFIG_UCC_SLOW) += ucc_slow.o
 obj-$(CONFIG_UCC_FAST) += ucc_fast.o
+obj-$(CONFIG_QE_USB)   += usb.o
diff --git a/arch/powerpc/sysdev/qe_lib/ucc.c b/arch/powerpc/sysdev/qe_lib/ucc.c
index 0e348d9..d3c7f5a 100644
--- a/arch/powerpc/sysdev/qe_lib/ucc.c
+++ b/arch/powerpc/sysdev/qe_lib/ucc.c
@@ -26,7 +26,8 @@
 #include asm/qe.h
 #include asm/ucc.h
 
-static DEFINE_SPINLOCK(ucc_lock);
+DEFINE_SPINLOCK(cmxgcr_lock);
+EXPORT_SYMBOL(cmxgcr_lock);
 
 int ucc_set_qe_mux_mii_mng(unsigned int ucc_num)
 {
@@ -35,10 +36,10 @@ int ucc_set_qe_mux_mii_mng(unsigned int ucc_num)
if (ucc_num  UCC_MAX_NUM - 1)
return -EINVAL;
 
-   spin_lock_irqsave(ucc_lock, flags);
+   spin_lock_irqsave(cmxgcr_lock, flags);
clrsetbits_be32(qe_immr-qmx.cmxgcr, QE_CMXGCR_MII_ENET_MNG,
ucc_num  QE_CMXGCR_MII_ENET_MNG_SHIFT);
-   spin_unlock_irqrestore(ucc_lock, flags);
+   spin_unlock_irqrestore(cmxgcr_lock, flags);
 
return 0;
 }
diff --git a/arch/powerpc/sysdev/qe_lib/usb.c b/arch/powerpc/sysdev/qe_lib/usb.c
new file mode 100644
index 000..69ce78c
--- /dev/null
+++ b/arch/powerpc/sysdev/qe_lib/usb.c
@@ -0,0 +1,56 @@
+/*
+ * QE USB routines
+ *
+ * Copyright (c) Freescale Semicondutor, Inc. 2006.
+ *   Shlomi Gridish [EMAIL PROTECTED]
+ *   Jerry Huang [EMAIL PROTECTED]
+ * Copyright (c) MontaVista Software, Inc. 2008.
+ *   Anton Vorontsov [EMAIL PROTECTED]
+ *
+ * This program is free software; you can redistribute  it and/or modify it
+ * under  the terms of  the GNU General  Public License as published by the
+ * Free Software Foundation;  either version 2 of the  License, or (at your
+ * option) any later version.
+ */
+
+#include linux/kernel.h
+#include linux/errno.h
+#include linux/io.h
+#include linux/of.h
+#include asm/immap_qe.h
+#include asm/qe.h
+
+int qe_usb_clock_set(enum qe_clock clk, int rate)
+{
+   struct qe_mux __iomem *mux = qe_immr-qmx;
+   unsigned long flags;
+   u32 val;
+
+   switch (clk) {
+   case QE_CLK3:  val = QE_CMXGCR_USBCS_CLK3;  break;
+   case QE_CLK5:  val = QE_CMXGCR_USBCS_CLK5;  break;
+   case QE_CLK7:  val = QE_CMXGCR_USBCS_CLK7;  break;
+   case QE_CLK9:  val = QE_CMXGCR_USBCS_CLK9;  break;
+   case QE_CLK13: val = QE_CMXGCR_USBCS_CLK13; break;
+   case QE_CLK17: val = QE_CMXGCR_USBCS_CLK17; break;
+   case QE_CLK19: val = QE_CMXGCR_USBCS_CLK19; break;
+   case QE_CLK21: val = QE_CMXGCR_USBCS_CLK21; break;
+   case QE_BRG9:  val = QE_CMXGCR_USBCS_BRG9;  break;
+   case QE_BRG10: val = QE_CMXGCR_USBCS_BRG10; break;
+   default:
+   pr_err(%s: requested unknown clock %d\n, __func__, clk);
+   return -EINVAL;
+   }
+
+   if (qe_clock_is_brg(clk))
+   qe_setbrg(clk, rate, 1);
+
+   spin_lock_irqsave(cmxgcr_lock, flags);
+
+   clrsetbits_be32(mux-cmxgcr, QE_CMXGCR_USBCS, val);
+
+   spin_unlock_irqrestore(cmxgcr_lock, flags);
+
+   return 0;
+}
+EXPORT_SYMBOL(qe_usb_clock_set);
diff --git a/include/asm-powerpc/qe.h b/include/asm-powerpc/qe.h
index c3be6e2..d217288 100644
--- a/include/asm-powerpc/qe.h
+++ b/include/asm-powerpc/qe.h
@@ -16,6 +16,7 @@
 #define _ASM_POWERPC_QE_H
 #ifdef __KERNEL__
 
+#include linux/spinlock.h
 #include asm/immap_qe.h
 
 #define QE_NUM_OF_SNUM 28
@@ -74,6 +75,13 @@ enum 

[PATCH 3/6] [POWERPC] QE: prepare QE PIO code for GPIO LIB support

2008-04-29 Thread Anton Vorontsov
- split and export __par_io_config_pin() out of par_io_config_pin(), so we
  could use the prefixed version with GPIO LIB API;
- rename struct port_regs to qe_pio_regs, and place it into qe.h;
- rename #define NUM_OF_PINS to QE_PIO_PINS, and place it into qe.h.

Signed-off-by: Anton Vorontsov [EMAIL PROTECTED]
---
 arch/powerpc/sysdev/qe_lib/qe_io.c |   94 +---
 include/asm-powerpc/qe.h   |   19 +++
 2 files changed, 64 insertions(+), 49 deletions(-)

diff --git a/arch/powerpc/sysdev/qe_lib/qe_io.c 
b/arch/powerpc/sysdev/qe_lib/qe_io.c
index 93916a4..7c87460 100644
--- a/arch/powerpc/sysdev/qe_lib/qe_io.c
+++ b/arch/powerpc/sysdev/qe_lib/qe_io.c
@@ -28,21 +28,7 @@
 
 #undef DEBUG
 
-#define NUM_OF_PINS32
-
-struct port_regs {
-   __be32  cpodr;  /* Open drain register */
-   __be32  cpdata; /* Data register */
-   __be32  cpdir1; /* Direction register */
-   __be32  cpdir2; /* Direction register */
-   __be32  cppar1; /* Pin assignment register */
-   __be32  cppar2; /* Pin assignment register */
-#ifdef CONFIG_PPC_85xx
-   u8  pad[8];
-#endif
-};
-
-static struct port_regs __iomem *par_io;
+static struct qe_pio_regs __iomem *par_io;
 static int num_par_io_ports = 0;
 
 int par_io_init(struct device_node *np)
@@ -64,69 +50,79 @@ int par_io_init(struct device_node *np)
return 0;
 }
 
-int par_io_config_pin(u8 port, u8 pin, int dir, int open_drain,
- int assignment, int has_irq)
+void __par_io_config_pin(struct qe_pio_regs __iomem *par_io, u8 pin, int dir,
+int open_drain, int assignment, int has_irq)
 {
-   u32 pin_mask1bit, pin_mask2bits, new_mask2bits, tmp_val;
-
-   if (!par_io)
-   return -1;
+   u32 pin_mask1bit;
+   u32 pin_mask2bits;
+   u32 new_mask2bits;
+   u32 tmp_val;
 
/* calculate pin location for single and 2 bits information */
-   pin_mask1bit = (u32) (1  (NUM_OF_PINS - (pin + 1)));
+   pin_mask1bit = (u32) (1  (QE_PIO_PINS - (pin + 1)));
 
/* Set open drain, if required */
-   tmp_val = in_be32(par_io[port].cpodr);
+   tmp_val = in_be32(par_io-cpodr);
if (open_drain)
-   out_be32(par_io[port].cpodr, pin_mask1bit | tmp_val);
+   out_be32(par_io-cpodr, pin_mask1bit | tmp_val);
else
-   out_be32(par_io[port].cpodr, ~pin_mask1bit  tmp_val);
+   out_be32(par_io-cpodr, ~pin_mask1bit  tmp_val);
 
/* define direction */
-   tmp_val = (pin  (NUM_OF_PINS / 2) - 1) ?
-   in_be32(par_io[port].cpdir2) :
-   in_be32(par_io[port].cpdir1);
+   tmp_val = (pin  (QE_PIO_PINS / 2) - 1) ?
+   in_be32(par_io-cpdir2) :
+   in_be32(par_io-cpdir1);
 
/* get all bits mask for 2 bit per port */
-   pin_mask2bits = (u32) (0x3  (NUM_OF_PINS -
-   (pin % (NUM_OF_PINS / 2) + 1) * 2));
+   pin_mask2bits = (u32) (0x3  (QE_PIO_PINS -
+   (pin % (QE_PIO_PINS / 2) + 1) * 2));
 
/* Get the final mask we need for the right definition */
-   new_mask2bits = (u32) (dir  (NUM_OF_PINS -
-   (pin % (NUM_OF_PINS / 2) + 1) * 2));
+   new_mask2bits = (u32) (dir  (QE_PIO_PINS -
+   (pin % (QE_PIO_PINS / 2) + 1) * 2));
 
/* clear and set 2 bits mask */
-   if (pin  (NUM_OF_PINS / 2) - 1) {
-   out_be32(par_io[port].cpdir2,
+   if (pin  (QE_PIO_PINS / 2) - 1) {
+   out_be32(par_io-cpdir2,
 ~pin_mask2bits  tmp_val);
tmp_val = ~pin_mask2bits;
-   out_be32(par_io[port].cpdir2, new_mask2bits | tmp_val);
+   out_be32(par_io-cpdir2, new_mask2bits | tmp_val);
} else {
-   out_be32(par_io[port].cpdir1,
+   out_be32(par_io-cpdir1,
 ~pin_mask2bits  tmp_val);
tmp_val = ~pin_mask2bits;
-   out_be32(par_io[port].cpdir1, new_mask2bits | tmp_val);
+   out_be32(par_io-cpdir1, new_mask2bits | tmp_val);
}
/* define pin assignment */
-   tmp_val = (pin  (NUM_OF_PINS / 2) - 1) ?
-   in_be32(par_io[port].cppar2) :
-   in_be32(par_io[port].cppar1);
+   tmp_val = (pin  (QE_PIO_PINS / 2) - 1) ?
+   in_be32(par_io-cppar2) :
+   in_be32(par_io-cppar1);
 
-   new_mask2bits = (u32) (assignment  (NUM_OF_PINS -
-   (pin % (NUM_OF_PINS / 2) + 1) * 2));
+   new_mask2bits = (u32) (assignment  (QE_PIO_PINS -
+   (pin % (QE_PIO_PINS / 2) + 1) * 2));
/* clear and set 2 bits mask */
-   if (pin  (NUM_OF_PINS / 2) - 1) {
-   out_be32(par_io[port].cppar2,
+   if (pin  (QE_PIO_PINS / 2) - 1) {
+   

[PATCH 4/6] [POWERPC] QE: implement support for the GPIO LIB API

2008-04-29 Thread Anton Vorontsov
This is needed to access QE GPIOs via Linux GPIO API.

Signed-off-by: Anton Vorontsov [EMAIL PROTECTED]
---
 Documentation/powerpc/booting-without-of.txt |   37 ---
 arch/powerpc/sysdev/qe_lib/Kconfig   |9 ++
 arch/powerpc/sysdev/qe_lib/Makefile  |1 +
 arch/powerpc/sysdev/qe_lib/gpio.c|  145 ++
 include/asm-powerpc/qe.h |1 +
 5 files changed, 180 insertions(+), 13 deletions(-)
 create mode 100644 arch/powerpc/sysdev/qe_lib/gpio.c

diff --git a/Documentation/powerpc/booting-without-of.txt 
b/Documentation/powerpc/booting-without-of.txt
index fc7a235..4fefc44 100644
--- a/Documentation/powerpc/booting-without-of.txt
+++ b/Documentation/powerpc/booting-without-of.txt
@@ -1723,24 +1723,35 @@ platforms are moved over to use the 
flattened-device-tree model.
information.
 
Required properties:
-   - device_type : should be par_io.
+   - #gpio-cells : should be 2.
+   - compatible : should be fsl,chip-qe-pario-bank,
+ fsl,mpc8323-qe-pario-bank.
- reg : offset to the register set and its length.
-   - num-ports : number of Parallel I/O ports
+   - gpio-controller : node to identify gpio controllers.
 
-   Example:
-   [EMAIL PROTECTED] {
-   reg = 1400 100;
-   #address-cells = 1;
-   #size-cells = 0;
-   device_type = par_io;
-   num-ports = 7;
-   [EMAIL PROTECTED] {
-   ..
-   };
+   For example, two QE Par I/O banks:
+   qe_pio_a: [EMAIL PROTECTED] {
+   #gpio-cells = 2;
+   compatible = fsl,mpc8360-qe-pario-bank,
+fsl,mpc8323-qe-pario-bank;
+   reg = 0x1400 0x18;
+   gpio-controller;
+   };
 
+   qe_pio_e: [EMAIL PROTECTED] {
+   #gpio-cells = 2;
+   compatible = fsl,mpc8360-qe-pario-bank,
+fsl,mpc8323-qe-pario-bank;
+   reg = 0x1460 0x18;
+   gpio-controller;
+   };
 
vi) Pin configuration nodes
 
+   NOTE: pin configuration nodes are obsolete. Usually, their existance
+ is an evidence of the firmware shortcomings. Such fixups are
+ better handled by the Linux board file, not the device tree.
+
Required properties:
- linux,phandle : phandle of this node; likely referenced by a QE
  device.
diff --git a/arch/powerpc/sysdev/qe_lib/Kconfig 
b/arch/powerpc/sysdev/qe_lib/Kconfig
index 76ffbc4..4bb18f5 100644
--- a/arch/powerpc/sysdev/qe_lib/Kconfig
+++ b/arch/powerpc/sysdev/qe_lib/Kconfig
@@ -24,3 +24,12 @@ config QE_USB
bool
help
  QE USB Host Controller support
+
+config QE_GPIO
+   bool QE GPIO support
+   depends on QUICC_ENGINE
+   select GENERIC_GPIO
+   select HAVE_GPIO_LIB
+   help
+ Say Y here if you're going to use hardware that connects to the
+ QE GPIOs.
diff --git a/arch/powerpc/sysdev/qe_lib/Makefile 
b/arch/powerpc/sysdev/qe_lib/Makefile
index e9ff888..f1855c1 100644
--- a/arch/powerpc/sysdev/qe_lib/Makefile
+++ b/arch/powerpc/sysdev/qe_lib/Makefile
@@ -7,3 +7,4 @@ obj-$(CONFIG_UCC)   += ucc.o
 obj-$(CONFIG_UCC_SLOW) += ucc_slow.o
 obj-$(CONFIG_UCC_FAST) += ucc_fast.o
 obj-$(CONFIG_QE_USB)   += usb.o
+obj-$(CONFIG_QE_GPIO)  += gpio.o
diff --git a/arch/powerpc/sysdev/qe_lib/gpio.c 
b/arch/powerpc/sysdev/qe_lib/gpio.c
new file mode 100644
index 000..ae9edea
--- /dev/null
+++ b/arch/powerpc/sysdev/qe_lib/gpio.c
@@ -0,0 +1,145 @@
+/*
+ * QUICC Engine GPIOs
+ *
+ * Copyright (c) MontaVista Software, Inc. 2008.
+ *
+ * Author: Anton Vorontsov [EMAIL PROTECTED]
+ *
+ * This program is free software; you can redistribute  it and/or modify it
+ * under  the terms of  the GNU General  Public License as published by the
+ * Free Software Foundation;  either version 2 of the  License, or (at your
+ * option) any later version.
+ */
+
+#include linux/kernel.h
+#include linux/spinlock.h
+#include linux/io.h
+#include linux/of.h
+#include linux/of_gpio.h
+#include linux/gpio.h
+#include asm/qe.h
+
+struct qe_gpio_chip {
+   struct of_mm_gpio_chip mm_gc;
+   spinlock_t lock;
+
+   /* shadowed data register to clear/set bits safely */
+   u32 cpdata;
+};
+
+static inline struct qe_gpio_chip *
+to_qe_gpio_chip(struct of_mm_gpio_chip *mm_gc)
+{
+   return container_of(mm_gc, struct qe_gpio_chip, mm_gc);
+}
+
+static void qe_gpio_save_regs(struct of_mm_gpio_chip *mm_gc)
+{
+   struct qe_gpio_chip *qe_gc = to_qe_gpio_chip(mm_gc);
+   struct qe_pio_regs __iomem *regs = mm_gc-regs;
+
+   qe_gc-cpdata = in_be32(regs-cpdata);
+}
+
+static int qe_gpio_get(struct gpio_chip *gc, unsigned int gpio)
+{
+   struct of_mm_gpio_chip *mm_gc = to_of_mm_gpio_chip(gc);
+   struct qe_pio_regs __iomem *regs = mm_gc-regs;
+   u32 pin_mask = 1  (QE_PIO_PINS - 1 - gpio);
+
+   return !!(in_be32(regs-cpdata)  

[PATCH 5/6] [POWERPC] 83xx: new board support: MPC8360E-RDK

2008-04-29 Thread Anton Vorontsov
This is patch adds board file, device tree, and defconfig for the new
board, made by Freescale Semiconductor Inc. and Logic Product Development.

Currently supported:
1. UEC{1,2,7,4};
2. I2C;
3. SPI;
4. NS16550 serial;
5. PCI and miniPCI;
6. Intel NOR StrataFlash X16 64Mbit PC28F640P30T85;
7. Graphics controller, Fujitsu MB86277.

Not supported in this patch:
1. StMICRO NAND512W3A2BN6E, 512 Mbit (supported with FSL UPM NAND driver);
2. FHCI USB (supported with FHCI driver).
3. QE Serial UCCs (tested to not work with ucc_uart driver, reason
   unknown, yet);
4. ADC AD7843 (tested to work, but support via device tree depends on
   major SPI rework, GPIO API, etc);

Signed-off-by: Anton Vorontsov [EMAIL PROTECTED]
---
 arch/powerpc/boot/dts/mpc836x_rdk.dts   |  397 +
 arch/powerpc/configs/83xx/mpc836x_rdk_defconfig | 1090 +++
 arch/powerpc/platforms/83xx/Kconfig |   11 +
 arch/powerpc/platforms/83xx/Makefile|1 +
 arch/powerpc/platforms/83xx/mpc836x_rdk.c   |  111 +++
 5 files changed, 1610 insertions(+), 0 deletions(-)
 create mode 100644 arch/powerpc/boot/dts/mpc836x_rdk.dts
 create mode 100644 arch/powerpc/configs/83xx/mpc836x_rdk_defconfig
 create mode 100644 arch/powerpc/platforms/83xx/mpc836x_rdk.c

diff --git a/arch/powerpc/boot/dts/mpc836x_rdk.dts 
b/arch/powerpc/boot/dts/mpc836x_rdk.dts
new file mode 100644
index 000..3402d26
--- /dev/null
+++ b/arch/powerpc/boot/dts/mpc836x_rdk.dts
@@ -0,0 +1,397 @@
+/*
+ * MPC8360E RDK Device Tree Source
+ *
+ * Copyright 2006 Freescale Semiconductor Inc.
+ * Copyright 2007-2008 MontaVista Software, Inc.
+ *
+ * Author: Anton Vorontsov [EMAIL PROTECTED]
+ *
+ * This program is free software; you can redistribute  it and/or modify it
+ * under  the terms of  the GNU General  Public License as published by the
+ * Free Software Foundation;  either version 2 of the  License, or (at your
+ * option) any later version.
+ */
+
+/dts-v1/;
+
+/ {
+   #address-cells = 1;
+   #size-cells = 1;
+   compatible = fsl,mpc8360rdk;
+
+   aliases {
+   serial0 = serial0;
+   serial1 = serial1;
+   serial2 = serial2;
+   serial3 = serial3;
+   ethernet0 = enet0;
+   ethernet1 = enet1;
+   ethernet2 = enet2;
+   ethernet3 = enet3;
+   pci0 = pci0;
+   };
+
+   cpus {
+   #address-cells = 1;
+   #size-cells = 0;
+
+   PowerPC,[EMAIL PROTECTED] {
+   device_type = cpu;
+   reg = 0;
+   d-cache-line-size = 32;
+   i-cache-line-size = 32;
+   d-cache-size = 32768;
+   i-cache-size = 32768;
+   /* filled by u-boot */
+   timebase-frequency = 0;
+   bus-frequency = 0;
+   clock-frequency = 0;
+   };
+   };
+
+   memory {
+   device_type = memory;
+   /* filled by u-boot */
+   reg = 0 0;
+   };
+
+   [EMAIL PROTECTED] {
+   #address-cells = 1;
+   #size-cells = 1;
+   device_type = soc;
+   compatible = fsl,mpc8360-immr, fsl,immr, fsl,soc,
+simple-bus;
+   ranges = 0 0xe000 0x20;
+   reg = 0xe000 0x200;
+   /* filled by u-boot */
+   bus-frequency = 0;
+
+   [EMAIL PROTECTED] {
+   compatible = mpc83xx_wdt;
+   reg = 0x200 0x100;
+   };
+
+   [EMAIL PROTECTED] {
+   #address-cells = 1;
+   #size-cells = 0;
+   cell-index = 0;
+   compatible = fsl-i2c;
+   reg = 0x3000 0x100;
+   interrupts = 14 8;
+   interrupt-parent = ipic;
+   dfsrr;
+   };
+
+   [EMAIL PROTECTED] {
+   #address-cells = 1;
+   #size-cells = 0;
+   cell-index = 1;
+   compatible = fsl-i2c;
+   reg = 0x3100 0x100;
+   interrupts = 16 8;
+   interrupt-parent = ipic;
+   dfsrr;
+   };
+
+   serial0: [EMAIL PROTECTED] {
+   device_type = serial;
+   compatible = ns16550;
+   reg = 0x4500 0x100;
+   interrupts = 9 8;
+   interrupt-parent = ipic;
+   /* filled by u-boot */
+   clock-frequency = 0;
+   };
+
+   serial1: [EMAIL PROTECTED] {
+   device_type = serial;
+

[PATCH 6/6] [POWERPC] booting-without-of: add FHCI USB, FSL MCU, FSL UPM and GPIO LEDs bindings

2008-04-29 Thread Anton Vorontsov
This patch adds few bindings for the new drivers to be submitted through
appropriate maintainers.

Signed-off-by: Anton Vorontsov [EMAIL PROTECTED]
---
 Documentation/powerpc/booting-without-of.txt |  125 ++
 1 files changed, 125 insertions(+), 0 deletions(-)

diff --git a/Documentation/powerpc/booting-without-of.txt 
b/Documentation/powerpc/booting-without-of.txt
index 4fefc44..6564e0a 100644
--- a/Documentation/powerpc/booting-without-of.txt
+++ b/Documentation/powerpc/booting-without-of.txt
@@ -61,6 +61,10 @@ Table of Contents
   r) Freescale Display Interface Unit
   s) Freescale on board FPGA
   t) Freescale General-purpose Timers Module
+  u) Freescale QUICC Engine USB Controller
+  v) LEDs on GPIOs
+  w) Freescale MCU with MPC8349E-mITX compatible firmware
+  x) Freescale Localbus UPM programmed to work with NAND flash
 
   VII - Marvell Discovery mv64[345]6x System Controller chips
 1) The /system-controller node
@@ -2916,6 +2920,127 @@ platforms are moved over to use the 
flattened-device-tree model.
clock-frequency = 0;
 };
 
+u) Freescale QUICC Engine USB Controller
+
+Required properties:
+  - compatible : should be fsl,chip-qe-usb, fsl,mpc8323-qe-usb;
+  - reg : the first two cells should contain gtm registers location and
+length, the next two two cells should contain PRAM location and
+length.
+  - interrupts : should contain USB interrupt.
+  - interrupt-parent : interrupt source phandle.
+  - fsl,fullspeed-clock : specifies the full speed USB clock source in
+clknum or brgnum format.
+  - fsl,lowspeed-clock : specifies the low speed USB clock source in
+clknum or brgnum format.
+  - fsl,usb-mode : should be host.
+  - linux,hub-power-budget : optional, USB power budget for the root hub
+in mA.
+  - gpios : should specify GPIOs in this order: USBOE, USBTP, USBTN, USBRP,
+USBRN, SPEED (optional), and POWER (optional).
+
+Example:
+
+   [EMAIL PROTECTED] {
+   compatible = fsl,mpc8360-qe-usb, fsl,mpc8323-qe-usb;
+   reg = 0x6c0 0x40 0x8b00 0x100;
+   interrupts = 11;
+   interrupt-parent = qeic;
+   fsl,fullspeed-clock = clk21;
+   fsl,usb-mode = host;
+   gpios = qe_pio_b  2 0 /* USBOE */
+qe_pio_b  3 0 /* USBTP */
+qe_pio_b  8 0 /* USBTN */
+qe_pio_b  9 0 /* USBRP */
+qe_pio_b 11 0 /* USBRN */
+qe_pio_e 20 0 /* SPEED */
+qe_pio_e 21 0 /* POWER */;
+   };
+
+v) LEDs on GPIOs
+
+Required properties:
+  - compatible : should be linux,gpio-led.
+  - linux,name : LED name.
+  - linux,active-low : property should be present if LED wired as
+active-low.
+  - linux,default-trigger : Linux default trigger for this LED.
+  - linux,brightness : default brightness.
+  - gpios : should specify LED GPIO.
+
+Example:
+
+   [EMAIL PROTECTED] {
+   compatible = linux,gpio-led;
+   linux,name = pwr;
+   linux,brightness = 1;
+   linux,active-low;
+   gpios = mcu_pio 0;
+   };
+
+   [EMAIL PROTECTED] {
+   compatible = linux,gpio-led;
+   linux,name = hdd;
+   linux,default-trigger = ide-disk;
+   linux,active-low;
+   gpios = mcu_pio 1;
+   };
+
+w) Freescale MCU with MPC8349E-mITX compatible firmware
+
+Required properties:
+  - compatible : fsl,mcu-chip-board, fsl,mcu-mpc8349emitx;
+  - reg : should specify I2C address (0x0a).
+  - #address-cells : should be 0.
+  - #size-cells : should be 0.
+  - #gpio-cells : should be 2.
+  - gpio-controller : should be present;
+
+Example:
+
+   mcu_pio: [EMAIL PROTECTED] {
+   #address-cells = 0;
+   #size-cells = 0;
+   #gpio-cells = 2;
+   compatible = fsl,mc9s08qg8-mpc8349emitx,
+fsl,mcu-mpc8349emitx;
+   reg = 0x0a;
+   gpio-controller;
+   };
+
+x) Freescale Localbus UPM programmed to work with NAND flash
+
+  Required properties:
+  - #address-cells : should be 0;
+  - #size-cells : should be 0;
+  - compatible : fsl,upm-nand.
+  - reg : should specify localbus chip select and size used for the chip.
+  - fsl,upm-addr-offset : UPM pattern offset for the address latch.
+  - fsl,upm-cmd-offset : UPM pattern offset for the command latch.
+  - gpios : may specify optional GPIO connected to the Ready-Not-Busy pin.
+
+  Example:
+
+   [EMAIL PROTECTED],0 {
+   #address-cells = 0;
+   #size-cells = 0;
+   compatible = fsl,upm-nand;
+   reg = 1 0 1;
+   

Re: SKB corruption on heavy traffic

2008-04-29 Thread Scott Wood
On Tue, Apr 29, 2008 at 07:39:07PM +0100, Franca, Jose (NSN - PT/Portugal - 
MiniMD) wrote:
   We are developing a MPC8247 based telecom board (512MB), using
 linux 2.4 with some proprietary changes on IP stack and we are facing
 some problems when we have heavy traffic on our Ethernet interfaces...

Do you see these problems without the proprietary changes, and with a
current kernel?

-Scott
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev


Re: 2.6.25: pmac_newworld undefined

2008-04-29 Thread Sam Ravnborg
On Tue, Apr 29, 2008 at 04:35:14PM +0300, Adrian Bunk wrote:
 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 so is the Makefile - right?
Or is this only true for 32 bit powerpc - in that case it is the wrong fix.

 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.

So something like:

config PPC32_NVRAM
bool
depends on NVRAM

obj-$(CONFIG_PPC32_NVRAM) += nvram.o
obj-$(CONFIG_NVRAM)   += nvram.o

Or did you have another solution in mind?

Sam
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev


Re: [PATCH] [POWERPC] convert transfer_to_handler into a macro

2008-04-29 Thread Kumar Gala


On Apr 29, 2008, at 1:35 PM, Scott Wood wrote:

On Tue, Apr 29, 2008 at 08:56:56AM -0500, Kumar Gala wrote:

+#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); \
+   slwir9,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,[EMAIL PROTECTED];  
   \


Can we use assembler macros rather than preprocessor macros to get  
rid of

the backslashes?


what's an assembler macro look like?  I don't believe we use them  
anywhere else.


- k
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev


Re: [PATCH] [POWERPC] convert transfer_to_handler into a macro

2008-04-29 Thread Scott Wood
On Tue, Apr 29, 2008 at 02:36:32PM -0500, Kumar Gala wrote:
 what's an assembler macro look like?

.macro macroname arg1 arg2
do something with \arg1
do something with \arg2
.endm

  I don't believe we use them anywhere else.

arch/powerpc/boot/ps3-hvcall.S uses them, as well as lots of asm code in
other architectures.

-Scott
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev


Re: 2.6.25: pmac_newworld undefined

2008-04-29 Thread Adrian Bunk
On Tue, Apr 29, 2008 at 09:17:53PM +0200, Sam Ravnborg wrote:
...
 So something like:
 
 config PPC32_NVRAM
   bool
   depends on NVRAM
 
 obj-$(CONFIG_PPC32_NVRAM) += nvram.o
 obj-$(CONFIG_NVRAM)   += nvram.o
 
 Or did you have another solution in mind?

I start to understand the problem, and I'm currently wondering why 
powerpc uses CONFIG_NVRAM although the code CONFIG_NVRAM enables on 
other platforms is not enabled on powerpc.

Can we rename it and move drivers/char/generic_nvram.c under 
arch/powerpc/ ?

Can some powerpc person bring some background what's going on and why 
it's this way?

   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

___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev


Re: [PATCH 2/6] [POWERPC] QE: add support for QE USB clocks routing

2008-04-29 Thread Timur Tabi
Anton Vorontsov wrote:
 This patch adds a function to the qe_lib to setup QE USB clocks routing.
 To setup clocks safely, cmxgcr register needs locking, so I just reused
 ucc_lock since it was used only to protect cmxgcr.
 
 The idea behind placing clocks routing functions into the qe_lib is that
 later we'll hopefully switch to the generic Linux Clock API, thus, for
 example, FHCI driver may be used for QE and CPM chips without nasty #ifdefs.
 
 This patch also fixes QE_USB_RESTART_TX command definition in the qe.h.
 
 Signed-off-by: Anton Vorontsov [EMAIL PROTECTED]

Acked-By: Timur Tabi [EMAIL PROTECTED]

Anton, please be sure to CC: me on any QE library patches you send out.

-- 
Timur Tabi
Linux kernel developer at Freescale
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev


Re: [PATCH 3/6] [POWERPC] QE: prepare QE PIO code for GPIO LIB support

2008-04-29 Thread Timur Tabi
Anton Vorontsov wrote:
 - split and export __par_io_config_pin() out of par_io_config_pin(), so we
   could use the prefixed version with GPIO LIB API;
 - rename struct port_regs to qe_pio_regs, and place it into qe.h;
 - rename #define NUM_OF_PINS to QE_PIO_PINS, and place it into qe.h.
 
 Signed-off-by: Anton Vorontsov [EMAIL PROTECTED]

Acked-By: Timur Tabi [EMAIL PROTECTED]

-- 
Timur Tabi
Linux kernel developer at Freescale
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev


Re: [patch v11 1/4] USB: add Cypress c67x00 low level interface code

2008-04-29 Thread Grant Likely
On Sun, Apr 27, 2008 at 12:59 AM, Peter Korsgaard [EMAIL PROTECTED] wrote:
 This patch adds the low level support code for the Cypress c67x00 family of
  OTG controllers.  The low level code is responsible for register access and
  implements the software protocol for communicating with the 16bit
  microcontroller inside the c67x00 device.

  Communication is done over the HPI interface (16bit SRAM-like parallel bus).

  Signed-off-by: Peter Korsgaard [EMAIL PROTECTED]
  Acked-by: David Brownell [EMAIL PROTECTED]
Acked-by: Grant Likely [EMAIL PROTECTED]

  ---
   drivers/usb/c67x00/c67x00-ll-hpi.c |  405 
 +
   drivers/usb/c67x00/c67x00.h|  285 ++
   2 files changed, 690 insertions(+)

  Index: linux-2.6/drivers/usb/c67x00/c67x00.h
  ===
  --- /dev/null
  +++ linux-2.6/drivers/usb/c67x00/c67x00.h
  @@ -0,0 +1,285 @@
  +/*
  + * c67x00.h: Cypress C67X00 USB register and field definitions
  + *
  + * Copyright (C) 2006-2008 Barco N.V.
  + *Derived from the Cypress cy7c67200/300 ezusb linux driver and
  + *based on multiple host controller drivers inside the linux kernel.
  + *
  + * 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., 51 Franklin Street, Fifth Floor, Boston,
  + * MA  02110-1301  USA.
  + */
  +
  +#ifndef _USB_C67X00_H
  +#define _USB_C67X00_H
  +
  +#include linux/spinlock.h
  +#include linux/platform_device.h
  +#include linux/completion.h
  +#include linux/mutex.h
  +
  +/* -
  + * Cypress C67x00 register definitions
  + */
  +
  +/* Hardware Revision Register */
  +#define HW_REV_REG 0xC004
  +
  +/* General USB registers */
  +/* = */
  +
  +/* USB Control Register */
  +#define USB_CTL_REG(x) ((x) ? 0xC0AA : 0xC08A)
  +
  +#define LOW_SPEED_PORT(x)  ((x) ? 0x0800 : 0x0400)
  +#define HOST_MODE  0x0200
  +#define PORT_RES_EN(x) ((x) ? 0x0100 : 0x0080)
  +#define SOF_EOP_EN(x)  ((x) ? 0x0002 : 0x0001)
  +
  +/* USB status register - Notice it has different content in hcd/udc mode */
  +#define USB_STAT_REG(x)((x) ? 0xC0B0 : 0xC090)
  +
  +#define EP0_IRQ_FLG0x0001
  +#define EP1_IRQ_FLG0x0002
  +#define EP2_IRQ_FLG0x0004
  +#define EP3_IRQ_FLG0x0008
  +#define EP4_IRQ_FLG0x0010
  +#define EP5_IRQ_FLG0x0020
  +#define EP6_IRQ_FLG0x0040
  +#define EP7_IRQ_FLG0x0080
  +#define RESET_IRQ_FLG  0x0100
  +#define SOF_EOP_IRQ_FLG0x0200
  +#define ID_IRQ_FLG 0x4000
  +#define VBUS_IRQ_FLG   0x8000
  +
  +/* USB Host only registers */
  +/* === */
  +
  +/* Host n Control Register */
  +#define HOST_CTL_REG(x)((x) ? 0xC0A0 : 0xC080)
  +
  +#define PREAMBLE_EN0x0080  /* Preamble enable */
  +#define SEQ_SEL0x0040  /* Data Toggle Sequence Bit 
 Select */
  +#define ISO_EN 0x0010  /* Isochronous enable  */
  +#define ARM_EN 0x0001  /* Arm operation */
  +
  +/* Host n Interrupt Enable Register */
  +#define HOST_IRQ_EN_REG(x) ((x) ? 0xC0AC : 0xC08C)
  +
  +#define SOF_EOP_IRQ_EN 0x0200  /* SOF/EOP Interrupt Enable  */
  +#define SOF_EOP_TMOUT_IRQ_EN   0x0800  /* SOF/EOP Timeout Interrupt Enable  
 */
  +#define ID_IRQ_EN  0x4000  /* ID interrupt enable */
  +#define VBUS_IRQ_EN0x8000  /* VBUS interrupt enable */
  +#define DONE_IRQ_EN0x0001  /* Done Interrupt Enable  */
  +
  +/* USB status register */
  +#define HOST_STAT_MASK 0x02FD
  +#define PORT_CONNECT_CHANGE(x) ((x) ? 0x0020 : 0x0010)
  +#define PORT_SE0_STATUS(x) ((x) ? 0x0008 : 0x0004)
  +
  +/* Host Frame Register */
  +#define HOST_FRAME_REG(x)  ((x) ? 0xC0B6 : 0xC096)
  +
  +#define HOST_FRAME_MASK0x07FF
  +
  +/* USB Peripheral only registers */
  +/* = */
  +
  +/* Device n Port Sel reg */
  +#define DEVICE_N_PORT_SEL(x)   ((x) ? 0xC0A4 : 0xC084)
  +
  +/* Device n Interrupt Enable Register */
  +#define DEVICE_N_IRQ_EN_REG(x) ((x) ? 0xC0AC : 0xC08C)
  +
  +#define 

Re: [patch v11 2/4] USB: add Cypress c67x00 OTG controller core driver

2008-04-29 Thread Grant Likely
On Sun, Apr 27, 2008 at 12:59 AM, Peter Korsgaard [EMAIL PROTECTED] wrote:
 This patch add the core driver for the c67x00 USB OTG controller.  The core
  driver is responsible for the platform bus binding and creating either
  USB HCD or USB Gadget instances for each of the serial interface engines
  on the chip.

  This driver does not directly implement the HCD or gadget behaviours; it
  just controls access to the chip.

  Signed-off-by: Peter Korsgaard [EMAIL PROTECTED]
  Acked-by: David Brownell [EMAIL PROTECTED]
Acked-by: Grant Likely [EMAIL PROTECTED]


  ---
   MAINTAINERS |6 +
   drivers/usb/c67x00/c67x00-drv.c |  230 
 
   include/linux/usb/c67x00.h  |   48 
   3 files changed, 284 insertions(+)

  Index: linux-2.6/drivers/usb/c67x00/c67x00-drv.c
  ===
  --- /dev/null
  +++ linux-2.6/drivers/usb/c67x00/c67x00-drv.c
  @@ -0,0 +1,230 @@
  +/*
  + * c67x00-drv.c: Cypress C67X00 USB Common infrastructure
  + *
  + * Copyright (C) 2006-2008 Barco N.V.
  + *Derived from the Cypress cy7c67200/300 ezusb linux driver and
  + *based on multiple host controller drivers inside the linux kernel.
  + *
  + * 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., 51 Franklin Street, Fifth Floor, Boston,
  + * MA  02110-1301  USA.
  + */
  +
  +/*
  + * This file implements the common infrastructure for using the c67x00.
  + * It is both the link between the platform configuration and subdrivers and
  + * the link between the common hardware parts and the subdrivers (e.g.
  + * interrupt handling).
  + *
  + * The c67x00 has 2 SIE's (serial interface engine) wich can be configured
  + * to be host, device or OTG (with some limitations, E.G. only SIE1 can be 
 OTG).
  + *
  + * Depending on the platform configuration, the SIE's are created and
  + * the corresponding subdriver is initialized (c67x00_probe_sie).
  + */
  +
  +#include linux/device.h
  +#include linux/io.h
  +#include linux/list.h
  +#include linux/usb.h
  +#include linux/usb/c67x00.h
  +
  +#include c67x00.h
  +
  +static void c67x00_probe_sie(struct c67x00_sie *sie,
  +struct c67x00_device *dev, int sie_num)
  +{
  +   spin_lock_init(sie-lock);
  +   sie-dev = dev;
  +   sie-sie_num = sie_num;
  +   sie-mode = c67x00_sie_config(dev-pdata-sie_config, sie_num);
  +
  +   switch (sie-mode) {
  +   case C67X00_SIE_UNUSED:
  +   dev_info(sie_dev(sie),
  +Not using SIE %d as requested\n, sie-sie_num);
  +   break;
  +
  +   default:
  +   dev_err(sie_dev(sie),
  +   Unsupported configuration: 0x%x for SIE %d\n,
  +   sie-mode, sie-sie_num);
  +   break;
  +   }
  +}
  +
  +static void c67x00_remove_sie(struct c67x00_sie *sie)
  +{
  +}
  +
  +static irqreturn_t c67x00_irq(int irq, void *__dev)
  +{
  +   struct c67x00_device *c67x00 = __dev;
  +   struct c67x00_sie *sie;
  +   u16 msg, int_status;
  +   int i, count = 8;
  +
  +   int_status = c67x00_ll_hpi_status(c67x00);
  +   if (!int_status)
  +   return IRQ_NONE;
  +
  +   while (int_status != 0  (count-- = 0)) {
  +   c67x00_ll_irq(c67x00, int_status);
  +   for (i = 0; i  C67X00_SIES; i++) {
  +   sie = c67x00-sie[i];
  +   msg = 0;
  +   if (int_status  SIEMSG_FLG(i))
  +   msg = c67x00_ll_fetch_siemsg(c67x00, i);
  +   if (sie-irq)
  +   sie-irq(sie, int_status, msg);
  +   }
  +   int_status = c67x00_ll_hpi_status(c67x00);
  +   }
  +
  +   if (int_status)
  +   dev_warn(c67x00-pdev-dev, Not all interrupts handled! 
  +status = 0x%04x\n, int_status);
  +
  +   return IRQ_HANDLED;
  +}
  +
  +/* 
 - */
  +
  +static int __devinit c67x00_drv_probe(struct platform_device *pdev)
  +{
  +   struct c67x00_device *c67x00;
  +   struct c67x00_platform_data *pdata;
  +   struct resource *res, *res2;
  +   int 

[PATCH v3] sysdev,mv64x60: MV64x60 device bus

2008-04-29 Thread Remi Machet
Follow up of my email of 4/16/2008 titled MV64x60 device bus.
For each mv64360 entry in the OpenFirmware database, add the 
registration of an of_bus to take care of devices connected to
the MV64x60 asynchronous devices controller.

Signed-off-by: Remi Machet ([EMAIL PROTECTED])
---
Use the compatible field to detect devices to register (on Dale Farnsworth
suggestion).
Added __initdata to variable of_mv64x60_devices (thanks to Stephen Rothwell 
for pointing that out).

 arch/powerpc/sysdev/mv64x60_dev.c |   10 ++
 1 files changed, 10 insertions(+)

diff --git a/arch/powerpc/sysdev/mv64x60_dev.c 
b/arch/powerpc/sysdev/mv64x60_dev.c
index 41af122..c38695e 100644
--- a/arch/powerpc/sysdev/mv64x60_dev.c
+++ b/arch/powerpc/sysdev/mv64x60_dev.c
@@ -15,6 +15,7 @@
 #include linux/console.h
 #include linux/mv643xx.h
 #include linux/platform_device.h
+#include linux/of_platform.h
 
 #include asm/prom.h
 
@@ -25,6 +26,11 @@
  * PowerPC of_platform_bus_type.  They support platform_bus_type instead.
  */
 
+static struct of_device_id __initdata of_mv64x60_devices[] = {
+   { .compatible = marvell,mv64306-devctrl, },
+   {}
+};
+
 /*
  * Create MPSC platform devices
  */
@@ -482,6 +488,10 @@ static int __init mv64x60_device_setup(void)
of_node_put(np);
}
 
+   /* Now add every node that is on the device bus (type is devicectrl */
+   for_each_compatible_node(np, NULL, marvell,mv64360)
+   of_platform_bus_probe(np, of_mv64x60_devices, NULL);
+
return 0;
 }
 arch_initcall(mv64x60_device_setup);


___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev


Re: [PATCH 4/6] [POWERPC] QE: implement support for the GPIO LIB API

2008-04-29 Thread Timur Tabi
Anton Vorontsov wrote:
 This is needed to access QE GPIOs via Linux GPIO API.
 
 Signed-off-by: Anton Vorontsov [EMAIL PROTECTED]
 ---
  Documentation/powerpc/booting-without-of.txt |   37 ---
  arch/powerpc/sysdev/qe_lib/Kconfig   |9 ++
  arch/powerpc/sysdev/qe_lib/Makefile  |1 +
  arch/powerpc/sysdev/qe_lib/gpio.c|  145 
 ++
  include/asm-powerpc/qe.h |1 +
  5 files changed, 180 insertions(+), 13 deletions(-)
  create mode 100644 arch/powerpc/sysdev/qe_lib/gpio.c
 
 diff --git a/Documentation/powerpc/booting-without-of.txt 
 b/Documentation/powerpc/booting-without-of.txt
 index fc7a235..4fefc44 100644
 --- a/Documentation/powerpc/booting-without-of.txt
 +++ b/Documentation/powerpc/booting-without-of.txt
 @@ -1723,24 +1723,35 @@ platforms are moved over to use the 
 flattened-device-tree model.
 information.
  
 Required properties:
 -   - device_type : should be par_io.
 +   - #gpio-cells : should be 2.
 +   - compatible : should be fsl,chip-qe-pario-bank,
 + fsl,mpc8323-qe-pario-bank.
 - reg : offset to the register set and its length.
 -   - num-ports : number of Parallel I/O ports
 +   - gpio-controller : node to identify gpio controllers.
  
 -   Example:
 - [EMAIL PROTECTED] {
 - reg = 1400 100;
 - #address-cells = 1;
 - #size-cells = 0;
 - device_type = par_io;
 - num-ports = 7;
 - [EMAIL PROTECTED] {
 - ..
 - };
 +   For example, two QE Par I/O banks:
 + qe_pio_a: [EMAIL PROTECTED] {

I think this change will break a number of boards, because a lot of them do 
this:

if ((np = of_find_node_by_name(NULL, par_io)) != NULL) {
par_io_init(np);

So if you're going to change the par_io nodes, you need to change the code as 
well.

A patch that changes the documentation should also change the code.  And if
you're code changes the device tree, it should also maintain compatibility for
older device trees.

 + #gpio-cells = 2;
 + compatible = fsl,mpc8360-qe-pario-bank,
 +  fsl,mpc8323-qe-pario-bank;
 + reg = 0x1400 0x18;
 + gpio-controller;
 + };
  
 + qe_pio_e: [EMAIL PROTECTED] {
 + #gpio-cells = 2;
 + compatible = fsl,mpc8360-qe-pario-bank,
 +  fsl,mpc8323-qe-pario-bank;
 + reg = 0x1460 0x18;
 + gpio-controller;
 + };
  
 vi) Pin configuration nodes
  
 +   NOTE: pin configuration nodes are obsolete. Usually, their existance
 + is an evidence of the firmware shortcomings. Such fixups are
 + better handled by the Linux board file, not the device tree.

You can't just delete the par_io documentation without updating the code and
planning for feature removal.  Almost all of the existing code out there for QE
boards expects a par_io node, and the device trees still have them.

 +static int qe_gpio_get(struct gpio_chip *gc, unsigned int gpio)
 +{
 + struct of_mm_gpio_chip *mm_gc = to_of_mm_gpio_chip(gc);
 + struct qe_pio_regs __iomem *regs = mm_gc-regs;
 + u32 pin_mask = 1  (QE_PIO_PINS - 1 - gpio);
 +
 + return !!(in_be32(regs-cpdata)  pin_mask);

Do we need to do !!?  I thought as long as the result was non-zero, it didn't
matter what the actual value is.  !! converts non-zero to 1.

 +static int qe_gpio_dir_in(struct gpio_chip *gc, unsigned int gpio)
 +{
 + struct of_mm_gpio_chip *mm_gc = to_of_mm_gpio_chip(gc);
 + struct qe_gpio_chip *qe_gc = to_qe_gpio_chip(mm_gc);
 + unsigned long flags;
 +
 + spin_lock_irqsave(qe_gc-lock, flags);
 +
 + __par_io_config_pin(mm_gc-regs, gpio, 2, 0, 0, 0);

No magic numbers, please.

 +void __init qe_add_gpiochips(void)
 +{
 + int ret;
 + struct device_node *np;
 +
 + for_each_compatible_node(np, NULL, fsl,mpc8323-qe-pario-bank) {
 + struct qe_gpio_chip *qe_gc;
 + struct of_mm_gpio_chip *mm_gc;
 + struct of_gpio_chip *of_gc;
 + struct gpio_chip *gc;
 +
 + qe_gc = kzalloc(sizeof(*qe_gc), GFP_KERNEL);
 + if (!qe_gc) {
 + ret = -ENOMEM;
 + goto err;
 + }
 +
 + spin_lock_init(qe_gc-lock);
 +
 + mm_gc = qe_gc-mm_gc;
 + of_gc = mm_gc-of_gc;
 + gc = of_gc-gc;
 +
 + mm_gc-save_regs = qe_gpio_save_regs;
 + of_gc-gpio_cells = 2;
 + gc-ngpio = QE_PIO_PINS;
 + gc-direction_input = qe_gpio_dir_in;
 + gc-direction_output = qe_gpio_dir_out;
 + gc-get = qe_gpio_get;
 + gc-set = qe_gpio_set;
 +
 + ret = of_mm_gpiochip_add(np, mm_gc);
 + if (ret)
 + goto err;
 + }
 +
 + return;
 +err:
 + pr_err(%s: registration failed with 

MPC5200b problem configuring PSC6 as a serial port

2008-04-29 Thread Nick

Hi Everyone,

Has anyone setup and used the MPC5200b PSC6 port as a serial port?  I am 
having trouble getting mine to work.  I am using PSC1, 2 and 3 already, 
and they work fine.  In my DTS file,  I have PSC6 configured like this:


[EMAIL PROTECTED] {  // PSC6
   device_type = serial;
   compatible = mpc5200b-psc-uart,mpc5200-psc-uart;
   port-number = 5;
   reg = 2c00 100;
   interrupts = 2 4 0.;
   interrupt-parent = mpc5200_pic;
};

Is there anything special I need to do to get this port working?

Thanks,

Nick

___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev


Re: [PATCH v3] sysdev,mv64x60: MV64x60 device bus

2008-04-29 Thread Dale Farnsworth
On Tue, Apr 29, 2008 at 01:26:38PM -0700, Remi Machet wrote:
 Follow up of my email of 4/16/2008 titled MV64x60 device bus.
 For each mv64360 entry in the OpenFirmware database, add the 
 registration of an of_bus to take care of devices connected to
 the MV64x60 asynchronous devices controller.
 
 Signed-off-by: Remi Machet ([EMAIL PROTECTED])

Acked-by: Dale Farnsworth [EMAIL PROTECTED]
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev


Re: [PATCH] Add fast little-endian switch system call

2008-04-29 Thread Paul Mackerras
Wolfgang Denk writes:

 This probably depends a bit on  the  performance  of  the  system  in
 question. Did you measure it - for example - on a 50 MHz MPC850 ?

The patch only affects arch/powerpc/kernel/entry_64.S.  So no, I
didn't measure it on a 50MHz MPC850, or indeed any 32-bit system. :)

Paul.
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev


Re: [PATCH 4/6] [POWERPC] QE: implement support for the GPIO LIB API

2008-04-29 Thread Anton Vorontsov
On Tue, Apr 29, 2008 at 03:29:00PM -0500, Timur Tabi wrote:
 Anton Vorontsov wrote:
  This is needed to access QE GPIOs via Linux GPIO API.
  
  Signed-off-by: Anton Vorontsov [EMAIL PROTECTED]
  ---
   Documentation/powerpc/booting-without-of.txt |   37 ---
   arch/powerpc/sysdev/qe_lib/Kconfig   |9 ++
   arch/powerpc/sysdev/qe_lib/Makefile  |1 +
   arch/powerpc/sysdev/qe_lib/gpio.c|  145 
  ++
   include/asm-powerpc/qe.h |1 +
   5 files changed, 180 insertions(+), 13 deletions(-)
   create mode 100644 arch/powerpc/sysdev/qe_lib/gpio.c
  
  diff --git a/Documentation/powerpc/booting-without-of.txt 
  b/Documentation/powerpc/booting-without-of.txt
  index fc7a235..4fefc44 100644
  --- a/Documentation/powerpc/booting-without-of.txt
  +++ b/Documentation/powerpc/booting-without-of.txt
  @@ -1723,24 +1723,35 @@ platforms are moved over to use the 
  flattened-device-tree model.
  information.
   
  Required properties:
  -   - device_type : should be par_io.
  +   - #gpio-cells : should be 2.
  +   - compatible : should be fsl,chip-qe-pario-bank,
  + fsl,mpc8323-qe-pario-bank.
  - reg : offset to the register set and its length.
  -   - num-ports : number of Parallel I/O ports
  +   - gpio-controller : node to identify gpio controllers.
   
  -   Example:
  -   [EMAIL PROTECTED] {
  -   reg = 1400 100;
  -   #address-cells = 1;
  -   #size-cells = 0;
  -   device_type = par_io;
  -   num-ports = 7;
  -   [EMAIL PROTECTED] {
  -   ..
  -   };
  +   For example, two QE Par I/O banks:
  +   qe_pio_a: [EMAIL PROTECTED] {
 
 I think this change will break a number of boards, because a lot of them do 
 this:
 
   if ((np = of_find_node_by_name(NULL, par_io)) != NULL) {
   par_io_init(np);
 
 So if you're going to change the par_io nodes, you need to change the code as 
 well.
 
 A patch that changes the documentation should also change the code.  And if
 you're code changes the device tree, it should also maintain compatibility for
 older device trees.

Well, I'm indeed removing [further] support for the par_io nodes,
overwriting it with gpio nodes. That way we'll stop new use cases of
these nodes.

Eventually I plan to adjust the existing code/device trees accordingly.
If you think that code should be adjusted at the same time as
documentation, I'm fine with it as well. I'll just add new documentation
instead of replacing the old.

  +   #gpio-cells = 2;
  +   compatible = fsl,mpc8360-qe-pario-bank,
  +fsl,mpc8323-qe-pario-bank;
  +   reg = 0x1400 0x18;
  +   gpio-controller;
  +   };
   
  +   qe_pio_e: [EMAIL PROTECTED] {
  +   #gpio-cells = 2;
  +   compatible = fsl,mpc8360-qe-pario-bank,
  +fsl,mpc8323-qe-pario-bank;
  +   reg = 0x1460 0x18;
  +   gpio-controller;
  +   };
   
  vi) Pin configuration nodes
   
  +   NOTE: pin configuration nodes are obsolete. Usually, their existance
  + is an evidence of the firmware shortcomings. Such fixups are
  + better handled by the Linux board file, not the device tree.
 
 You can't just delete the par_io documentation without updating the code and
 planning for feature removal.  Almost all of the existing code out there for 
 QE
 boards expects a par_io node, and the device trees still have them.

Yup, exactly. Old device tree still use them, but don't we want to get
rid of this? If so, we should remove documentation, or someone will
use it for the new device trees. ;-)

  +static int qe_gpio_get(struct gpio_chip *gc, unsigned int gpio)
  +{
  +   struct of_mm_gpio_chip *mm_gc = to_of_mm_gpio_chip(gc);
  +   struct qe_pio_regs __iomem *regs = mm_gc-regs;
  +   u32 pin_mask = 1  (QE_PIO_PINS - 1 - gpio);
  +
  +   return !!(in_be32(regs-cpdata)  pin_mask);
 
 Do we need to do !!?  I thought as long as the result was non-zero, it 
 didn't
 matter what the actual value is.  !! converts non-zero to 1.

Just checked with the Documentation/gpio.txt... yup we don't need this.
The values are boolean, zero for low, nonzero for high.

  +static int qe_gpio_dir_in(struct gpio_chip *gc, unsigned int gpio)
  +{
  +   struct of_mm_gpio_chip *mm_gc = to_of_mm_gpio_chip(gc);
  +   struct qe_gpio_chip *qe_gc = to_qe_gpio_chip(mm_gc);
  +   unsigned long flags;
  +
  +   spin_lock_irqsave(qe_gc-lock, flags);
  +
  +   __par_io_config_pin(mm_gc-regs, gpio, 2, 0, 0, 0);
 
 No magic numbers, please.

Ok.

  +void __init qe_add_gpiochips(void)
  +{
  +   int ret;
  +   struct device_node *np;
  +
  +   for_each_compatible_node(np, NULL, fsl,mpc8323-qe-pario-bank) {
  +   struct qe_gpio_chip *qe_gc;
  +   struct of_mm_gpio_chip *mm_gc;
  +   struct of_gpio_chip *of_gc;
  +   struct gpio_chip *gc;
  +
  +   qe_gc = 

Re: [PATCH 4/6] [POWERPC] QE: implement support for the GPIO LIB API

2008-04-29 Thread Timur Tabi
Anton Vorontsov wrote:

 Well, I'm indeed removing [further] support for the par_io nodes,
 overwriting it with gpio nodes. That way we'll stop new use cases of
 these nodes.

I have no problem with replacing par_io nodes with gpio nodes.

 Eventually I plan to adjust the existing code/device trees accordingly.
 If you think that code should be adjusted at the same time as
 documentation, I'm fine with it as well. I'll just add new documentation
 instead of replacing the old.

Yes, please.

 You can't just delete the par_io documentation without updating the code and
 planning for feature removal.  Almost all of the existing code out there for 
 QE
 boards expects a par_io node, and the device trees still have them.
 
 Yup, exactly. Old device tree still use them, but don't we want to get
 rid of this? If so, we should remove documentation, or someone will
 use it for the new device trees. ;-)

It should still be documented, but marked as deprecated.  The documentation can
be removed only when all the DTS files *and* the code are scrubbed of those
kinds of nodes.  And you can't remove backwards compatibility for those from the
code until at least the next major revision of the kernel.

Look at function of_get_mac_address() for an example.  mac-address was removed
mid last year, but we still support them.  Try to isolate the code that support
the newer gpio nodes and the  older par_io nodes into one function, and it'll be
easier to deal with.

-- 
Timur Tabi
Linux kernel developer at Freescale
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev


Re: filenames with spaces in /sys?

2008-04-29 Thread Christian Kujau

On Mon, 28 Apr 2008, Scott Wood wrote:

Wouldn't ../pmu-battery.0/power_supply/PMU_battery_0/power be feasible too?


Feasible, yes, but uglier


I did not want to argue about ugliness, as this is a matter of 
personal taste.



If userspace tools make it awkward to deal with filenames with spaces,
let's fix the userspace tools.


Usually I would agree. I was only puzzled that filenames in /sys have 
spaces at all - I was under the impression spaces should be omitted in 
/sys (and /proc, too) for ease of handling (userspace has to specialcase 
spaces). And looking at these directories only very few filenames contain 
spaces, so it looked like ../PMU battery 0/ somehow slipped through, as 
there's no point in having spaces when almost everything else was using 
an unserscore.


/sys is certainly not the only place they'll be found, and waging war 
against them is a battle best left for a couple decades ago.


Hm, I guess the real solution would be a statement about special 
characters in special filesystems in CodingStyle and a travel back in 
time to have this rule applied of course :)


C.
--
BOFH excuse #190:

Proprietary Information.
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev


[PATCH] [POWERPC] mpc5200: Allow for fixed speed MII configurations

2008-04-29 Thread Grant Likely
From: Grant Likely [EMAIL PROTECTED]

Various improvements for configuring the MPC5200 MII link from the
device tree:
* Look for 'current-speed' property for fixed speed MII links
* Look for 'fsl,7-wire-mode' property for boards using the 7 wire mode
* move definition of private data structure out of the header file

Signed-off-by: Grant Likely [EMAIL PROTECTED]
---

 .../powerpc/mpc52xx-device-tree-bindings.txt   |   11 ++
 drivers/net/fec_mpc52xx.c  |   96 +++-
 drivers/net/fec_mpc52xx.h  |   19 
 3 files changed, 85 insertions(+), 41 deletions(-)

diff --git a/Documentation/powerpc/mpc52xx-device-tree-bindings.txt 
b/Documentation/powerpc/mpc52xx-device-tree-bindings.txt
index cda7a7d..6f12f1c 100644
--- a/Documentation/powerpc/mpc52xx-device-tree-bindings.txt
+++ b/Documentation/powerpc/mpc52xx-device-tree-bindings.txt
@@ -237,6 +237,17 @@ Each GPIO controller node should have the empty property 
gpio-controller and
 according to the bit numbers in the GPIO control registers. The second cell
 is for flags which is currently unsused.
 
+8) FEC nodes
+The FEC node can specify one of the following properties to configure
+the MII link:
+fsl,7-wire-mode - An empty property that specifies the link uses 7-wire
+mode instead of MII
+current-speed   - Specifies that the MII should be configured for a fixed
+speed.  This property should contain two cells.  The
+first cell specifies the speed in Mbps and the second
+should be '0' for half duplex and '1' for full duplex
+phy-handle  - Contains a phandle to an Ethernet PHY.
+
 IV - Extra Notes
 
 
diff --git a/drivers/net/fec_mpc52xx.c b/drivers/net/fec_mpc52xx.c
index d21b7ab..eeb4433 100644
--- a/drivers/net/fec_mpc52xx.c
+++ b/drivers/net/fec_mpc52xx.c
@@ -43,6 +43,29 @@
 
 #define DRIVER_NAME mpc52xx-fec
 
+#define FEC5200_PHYADDR_NONE   (-1)
+#define FEC5200_PHYADDR_7WIRE  (-2)
+
+/* Private driver data structure */
+struct mpc52xx_fec_priv {
+   int duplex;
+   int speed;
+   int r_irq;
+   int t_irq;
+   struct mpc52xx_fec __iomem *fec;
+   struct bcom_task *rx_dmatsk;
+   struct bcom_task *tx_dmatsk;
+   spinlock_t lock;
+   int msg_enable;
+
+   /* MDIO link details */
+   int phy_addr;
+   unsigned int phy_speed;
+   struct phy_device *phydev;
+   enum phy_state link;
+};
+
+
 static irqreturn_t mpc52xx_fec_interrupt(int, void *);
 static irqreturn_t mpc52xx_fec_rx_interrupt(int, void *);
 static irqreturn_t mpc52xx_fec_tx_interrupt(int, void *);
@@ -223,7 +246,7 @@ static int mpc52xx_fec_phy_start(struct net_device *dev)
struct mpc52xx_fec_priv *priv = netdev_priv(dev);
int err;
 
-   if (!priv-has_phy)
+   if (priv-phy_addr  0)
return 0;
 
err = mpc52xx_fec_init_phy(dev);
@@ -243,7 +266,7 @@ static void mpc52xx_fec_phy_stop(struct net_device *dev)
 {
struct mpc52xx_fec_priv *priv = netdev_priv(dev);
 
-   if (!priv-has_phy)
+   if (!priv-phydev)
return;
 
phy_disconnect(priv-phydev);
@@ -255,7 +278,7 @@ static void mpc52xx_fec_phy_stop(struct net_device *dev)
 static int mpc52xx_fec_phy_mii_ioctl(struct mpc52xx_fec_priv *priv,
struct mii_ioctl_data *mii_data, int cmd)
 {
-   if (!priv-has_phy)
+   if (!priv-phydev)
return -ENOTSUPP;
 
return phy_mii_ioctl(priv-phydev, mii_data, cmd);
@@ -265,7 +288,7 @@ static void mpc52xx_fec_phy_hw_init(struct mpc52xx_fec_priv 
*priv)
 {
struct mpc52xx_fec __iomem *fec = priv-fec;
 
-   if (!priv-has_phy)
+   if (priv-phydev)
return;
 
out_be32(fec-mii_speed, priv-phy_speed);
@@ -704,7 +727,7 @@ static void mpc52xx_fec_start(struct net_device *dev)
rcntrl = FEC_RX_BUFFER_SIZE  16;  /* max frame length */
rcntrl |= FEC_RCNTRL_FCE;
 
-   if (priv-has_phy)
+   if (priv-phy_addr != FEC5200_PHYADDR_7WIRE)
rcntrl |= FEC_RCNTRL_MII_MODE;
 
if (priv-duplex == DUPLEX_FULL)
@@ -864,7 +887,10 @@ mpc52xx_fec_probe(struct of_device *op, const struct 
of_device_id *match)
struct net_device *ndev;
struct mpc52xx_fec_priv *priv = NULL;
struct resource mem;
-   const phandle *ph;
+   struct device_node *phy_node;
+   const phandle *phy_handle;
+   const u32 *prop;
+   int prop_size;
 
phys_addr_t rx_fifo;
phys_addr_t tx_fifo;
@@ -950,24 +976,36 @@ mpc52xx_fec_probe(struct of_device *op, const struct 
of_device_id *match)
priv-msg_enable = netif_msg_init(debug, MPC52xx_MESSAGES_DEFAULT);
priv-duplex = DUPLEX_FULL;
 
-   /* is the phy present in device tree? */
-   ph = of_get_property(op-node, phy-handle, NULL);
-   if (ph) {
-   const unsigned int *prop;
-   struct 

Re: [PATCH] [POWERPC] convert transfer_to_handler into a macro

2008-04-29 Thread Paul Mackerras
Kumar Gala writes:

 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.

It seems to me that this implies you are assuming that you will never
ever get a synchronous normal interrupt such as a TLB miss while you
are in a critical or machine check handler.

Wouldn't it be better and safer to have the exception prolog for
critical interrupts save SRR0/1 in the stack frame, and have the
prolog for machine checks save SRR0/1 and CSRR0/1 likewise?

Paul.
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev


Re: [PATCH] [POWERPC] convert transfer_to_handler into a macro

2008-04-29 Thread Kumar Gala


On Apr 29, 2008, at 4:28 PM, Paul Mackerras wrote:

Kumar Gala writes:

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.


It seems to me that this implies you are assuming that you will never
ever get a synchronous normal interrupt such as a TLB miss while you
are in a critical or machine check handler.


Grr.. one more thing to fix :)


Wouldn't it be better and safer to have the exception prolog for
critical interrupts save SRR0/1 in the stack frame, and have the
prolog for machine checks save SRR0/1 and CSRR0/1 likewise?


If we do this I guess we can use SRR0/1 regardless of which level we  
came from.


- k
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev


Re: [PATCH] [POWERPC] Add struct iommu_table argument to iommu_map_sg()

2008-04-29 Thread Mark Nelson

Olof Johansson wrote:

On Tue, Apr 29, 2008 at 03:17:45PM +1000, Mark Nelson wrote:

Make iommu_map_sg take a struct iommu_table. It did so before commit
740c3ce66700640a6e6136ff679b067e92125794 (iommu sg merging: ppc: make
iommu respect the segment size limits).

This stops the function looking in the archdata.dma_data for the iommu
table because in the future it will be called with a device that has
no table there.


The logical thing would be to add the archdata.dma_data to said device
instead, no? Without seeing the rest of the code that makes use of it
it's hard to tell anyway, so please post that.


I'll post the follow on series of patches as an RFC to give you a better
understanding of what I'm trying to do; but basically I'm building on
the new dma_*map*_attrs() interfaces that Andrew Morton sent to Linus
last night and implementing them for powerpc (in particular the Cell
platform). To cut a longish story short, the fixed linear mapping for
the Cell's IOMMU can be set to either be weakly or strongly ordered,
and so a device that has been identified as being able to use the
fixed mapping can later request a mapping that cannot be satisfied using
the fixed mapping (eg: it may request a weakly ordered mapping when
the fixed mapping is strongly ordered, or vice versa). Devices that
use the fixed mapping use the dma_direct_ops with their dma_data being
the necessary offset, but for the case above they have to use the
iommu_map*() functions that the dma_iommu_ops use. So that's how we end
up calling iommu_map_sg() with a device that doesn't have the table
in the dma_data (and already has something useful in dma_data).

I'll try to get the follow on series of patches cleaned up today and
send them out asap, so if my ramblings above turned out to be too
obscure the code will hopefully clear things up.

Thanks!

Mark.




This also has the nice side effect of making iommu_map_sg() match the
other map functions.


Consistency is good, but I wonder if the opposite wouldn't be the better
way to go here: always just pass down just the dev pointer instead. The
table can be reached from it.


-Olof


___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev


Re: [RESEND][PATCH][POWERPC] PIKA Warp: Update platform code to supportRev B boards

2008-04-29 Thread Josh Boyer
On Mon, 28 Apr 2008 18:07:17 -0400
Sean MacLennan [EMAIL PROTECTED] wrote:

 On Mon, 28 Apr 2008 16:54:24 -0500
 Scott Wood [EMAIL PROTECTED] wrote:
 
  Why can't the existing partition binding be used with NAND?  It's
  what we do with Freescale FCM NAND.
 
 I guess I could put the partitions in the dts. But I would have to
 read them and dynamically create an array to pass to the ndfc driver.
 
 It seems simpler to just statically initialize the array. Once the ndfc
 is modified to use the dts, I will switch to that method.

Right.  It's a limitation of NDFC, which isn't WARP specific and needs
fixing in general.

josh
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev


[PATCH] Make emergency stack safe for current_thread_info() use

2008-04-29 Thread Michael Ellerman
The current_thread_info() macro, used by preempt_count(), assumes the
stack is THREAD_SIZE aligned. It should probably also be THREAD_SIZE
in size.

The emergency stack currently isn't either of these things, which could
potentially cause problems anytime we're running on the emergency
stack. That includes when we detect a bad kernel stack pointer, and also
during early_setup_secondary().

Signed-off-by: Michael Ellerman [EMAIL PROTECTED]

---
Booted on P6 LPAR and QS21.


 arch/powerpc/kernel/setup_64.c |9 ++---
 1 files changed, 6 insertions(+), 3 deletions(-)

diff --git a/arch/powerpc/kernel/setup_64.c b/arch/powerpc/kernel/setup_64.c
index dff6308..25e3fd8 100644
--- a/arch/powerpc/kernel/setup_64.c
+++ b/arch/powerpc/kernel/setup_64.c
@@ -487,9 +487,12 @@ static void __init emergency_stack_init(void)
 */
limit = min(0x1000UL, lmb.rmo_size);
 
-   for_each_possible_cpu(i)
-   paca[i].emergency_sp =
-   __va(lmb_alloc_base(HW_PAGE_SIZE, 128, limit)) + HW_PAGE_SIZE;
+   for_each_possible_cpu(i) {
+   unsigned long sp;
+   sp  = lmb_alloc_base(THREAD_SIZE, THREAD_SIZE, limit);
+   sp += THREAD_SIZE;
+   paca[i].emergency_sp = __va(sp);
+   }
 }
 
 /*
-- 
1.5.5

___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev


Re: [PATCH] [POWERPC] convert transfer_to_handler into a macro

2008-04-29 Thread Paul Mackerras
Kumar Gala writes:

  Wouldn't it be better and safer to have the exception prolog for
  critical interrupts save SRR0/1 in the stack frame, and have the
  prolog for machine checks save SRR0/1 and CSRR0/1 likewise?
 
 If we do this I guess we can use SRR0/1 regardless of which level we  
 came from.

That's the idea.  I actually thought the booke exception prologs
already did that, but it seems I'm wrong.

What sort of things do you expect critical and machine-check handlers
to be needing to do?

Paul.
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev


Re: [PATCH v3] sysdev,mv64x60: MV64x60 device bus

2008-04-29 Thread Paul Mackerras
Remi Machet writes:

 Follow up of my email of 4/16/2008 titled MV64x60 device bus.
 For each mv64360 entry in the OpenFirmware database, add the 
 registration of an of_bus to take care of devices connected to
 the MV64x60 asynchronous devices controller.

Your patch description should also explain what good things will come
of doing this, or what bad things will be avoided.  Also please put
the Follow up... sentence below the 3 dashes so I don't have to edit
it out.

If there are no further review comments, and if you resend with a
better patch description, I'll queue this up for the next merge window
(for 2.6.27).

Paul.
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev


[PATCH] Fix crashkernel= handling when no crashkernel= specified

2008-04-29 Thread Michael Ellerman
Commit edd8ce67436851a62f99f1d9707b40ea6a8e5323 (Use extended crashkernel
command line on ppc64), changed the logic in reserve_crashkernel()
which deals with the crashkernel= command line option.

This introduced a bug in the case when there is no crashkernel= option,
or it is incorrect. We would fallthrough and calculate the crash_size
based on the existing values in crashk_res. If both start and end are 0,
the default, we calculate the crash_size as 1 byte - which is wrong.

Rework the logic so that we use crashk_res, regardless of whether it's
set by the command line or via the device tree (see prom.c). Then check
if we have an empty range (end == start), and if so make sure to set
both end and start to zero (this is checked in machine_kexec_64.c). Then
we calculate the crash_size once we know we have a non-zero range.

Finally we always want to warn the user if they specify a base != 32MB,
so remove the special case for that in the command line parsing case.

Signed-off-by: Michael Ellerman [EMAIL PROTECTED]
---
 arch/powerpc/kernel/machine_kexec.c |   12 ++--
 1 files changed, 6 insertions(+), 6 deletions(-)

diff --git a/arch/powerpc/kernel/machine_kexec.c 
b/arch/powerpc/kernel/machine_kexec.c
index 2d202f2..29a0e03 100644
--- a/arch/powerpc/kernel/machine_kexec.c
+++ b/arch/powerpc/kernel/machine_kexec.c
@@ -74,20 +74,20 @@ void __init reserve_crashkernel(void)
ret = parse_crashkernel(boot_command_line, lmb_phys_mem_size(),
crash_size, crash_base);
if (ret == 0  crash_size  0) {
-   if (crash_base == 0)
-   crash_base = KDUMP_KERNELBASE;
crashk_res.start = crash_base;
-   } else {
-   /* handle the device tree */
-   crash_size = crashk_res.end - crashk_res.start + 1;
+   crashk_res.end = crash_base + crash_size - 1;
}
 
-   if (crash_size == 0)
+   if (crashk_res.end == crashk_res.start) {
+   crashk_res.start = crashk_res.end = 0;
return;
+   }
 
/* We might have got these values via the command line or the
 * device tree, either way sanitise them now. */
 
+   crash_size = crashk_res.end - crashk_res.start + 1;
+
if (crashk_res.start != KDUMP_KERNELBASE)
printk(Crash kernel location must be 0x%x\n,
KDUMP_KERNELBASE);
-- 
1.5.5

___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev


[RFC] [PATCH] vmemmap fixes to use smaller pages

2008-04-29 Thread Benjamin Herrenschmidt
This patch changes vmemmap to use a different region (region 0xf) of the
address space whose page size can be dynamically configured at boot.

The problem with the current approach of always using 16M pages is that
it's not well suited to machines that have small amounts of memory such
as small partitions on pseries, or PS3's.

In fact, on the PS3, failure to allocate the 16M page backing vmmemmap
tends to prevent hotplugging the HV's additional memory, thus limiting
the available memory even more, from my experience down to something
like 80M total, which makes it really not very useable.

The logic used by my match to choose the vmemmap page size is:

 - If 16M pages are available and there's 1G or more RAM at boot, use that size.
 - Else if 64K pages are available, use that
 - Else use 4K pages

I've tested on a POWER6 (16M pages) and on an iSeries POWER3 (4K pages)
and it seems to work fine.

However, when attempting to test on a PS3, it didn't boot.

In fact, it doesn't boot without my patch with current upstream. I tried
booting 2.6.25 with a ps3_defconfig and that doesn't work neither
(though at least when doing the later, I do get a black screen  no
sync, like of ps3fb failed monitor detection, while with current
upstream, I just get the last kexec messages and nothing happens).

Since the PS3 boot failures are impossible to debug unless your email is
@sony* and you have the special magic tools, I'll let Geoff try the
patch out.

Note that I intend to change the way we organize the kernel regions 
SLBs so the actual region will change from 0xf back to something else at
one point, as I simplify the SLB miss handler, but that will be for a
later patch.

Index: linux-work/arch/powerpc/mm/hash_utils_64.c
===
--- linux-work.orig/arch/powerpc/mm/hash_utils_64.c 2008-04-30 
15:00:54.0 +1000
+++ linux-work/arch/powerpc/mm/hash_utils_64.c  2008-04-30 15:01:00.0 
+1000
@@ -94,6 +94,9 @@ unsigned long htab_hash_mask;
 int mmu_linear_psize = MMU_PAGE_4K;
 int mmu_virtual_psize = MMU_PAGE_4K;
 int mmu_vmalloc_psize = MMU_PAGE_4K;
+#ifdef CONFIG_SPARSEMEM_VMEMMAP
+int mmu_vmemmap_psize = MMU_PAGE_4K;
+#endif
 int mmu_io_psize = MMU_PAGE_4K;
 int mmu_kernel_ssize = MMU_SEGSIZE_256M;
 int mmu_highuser_ssize = MMU_SEGSIZE_256M;
@@ -387,11 +390,32 @@ static void __init htab_init_page_sizes(
}
 #endif /* CONFIG_PPC_64K_PAGES */
 
+#ifdef CONFIG_SPARSEMEM_VMEMMAP
+   /* We try to use 16M pages for vmemmap if that is supported
+* and we have at least 1G of RAM at boot
+*/
+   if (mmu_psize_defs[MMU_PAGE_16M].shift 
+   lmb_phys_mem_size() = 0x4000)
+   mmu_vmemmap_psize = MMU_PAGE_16M;
+   else if (mmu_psize_defs[MMU_PAGE_64K].shift)
+   mmu_vmemmap_psize = MMU_PAGE_64K;
+   else
+   mmu_vmemmap_psize = MMU_PAGE_4K;
+#endif /* CONFIG_SPARSEMEM_VMEMMAP */
+
printk(KERN_DEBUG Page orders: linear mapping = %d, 
-  virtual = %d, io = %d\n,
+  virtual = %d, io = %d
+#ifdef CONFIG_SPARSEMEM_VMEMMAP
+  , vmemmap = %d
+#endif
+  \n,
   mmu_psize_defs[mmu_linear_psize].shift,
   mmu_psize_defs[mmu_virtual_psize].shift,
-  mmu_psize_defs[mmu_io_psize].shift);
+  mmu_psize_defs[mmu_io_psize].shift
+#ifdef CONFIG_SPARSEMEM_VMEMMAP
+  ,mmu_psize_defs[mmu_vmemmap_psize].shift
+#endif
+  );
 
 #ifdef CONFIG_HUGETLB_PAGE
/* Init large page size. Currently, we pick 16M or 1M depending
Index: linux-work/arch/powerpc/mm/init_64.c
===
--- linux-work.orig/arch/powerpc/mm/init_64.c   2008-04-30 15:00:54.0 
+1000
+++ linux-work/arch/powerpc/mm/init_64.c2008-04-30 15:05:02.0 
+1000
@@ -19,6 +19,8 @@
  *
  */
 
+#undef DEBUG
+
 #include linux/signal.h
 #include linux/sched.h
 #include linux/kernel.h
@@ -208,12 +210,12 @@ int __meminit vmemmap_populated(unsigned
 }
 
 int __meminit vmemmap_populate(struct page *start_page,
-   unsigned long nr_pages, int node)
+  unsigned long nr_pages, int node)
 {
unsigned long mode_rw;
unsigned long start = (unsigned long)start_page;
unsigned long end = (unsigned long)(start_page + nr_pages);
-   unsigned long page_size = 1  mmu_psize_defs[mmu_linear_psize].shift;
+   unsigned long page_size = 1  mmu_psize_defs[mmu_vmemmap_psize].shift;
 
mode_rw = _PAGE_ACCESSED | _PAGE_DIRTY | _PAGE_COHERENT | PP_RWXX;
 
@@ -235,11 +237,11 @@ int __meminit vmemmap_populate(struct pa
start, p, __pa(p));
 
mapped = htab_bolt_mapping(start, start + page_size,
-   __pa(p), mode_rw, mmu_linear_psize,
+   __pa(p), mode_rw,