Re: pmac_zilog debugging ...

2008-11-07 Thread Paul Mackerras
Kevin Diggs writes:

> pppd ttyS0 1200 satellites: netmask 255.255.255.0 lock crtscts mru 1064 
> noauth debug kdebug 7 
> logfile /tmp/pppd.log local
> 
> to connect an 8600 to a laptop via ppp the link will lock up in short
> order from "payloaded" pings. Any advice on how to figure out where it
> is locking up? This command works fine to connect two x86 laptops. At
> 1200 it does take a while for an xterm to show up, though.

Try it without the crtscts (actually, use nocrtscts instead of
crtscts).  That will tell us whether it is hardware flow control
causing problems.  IIRC, those mac serial ports didn't have all of
RTS, CTS, CD and DTR, but I don't recall which one(s) were missing.

Also make sure you don't have the xonxoff option.

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


Re: [PATCH] Fix BSR to allow mmap of small BSR on 64k kernel

2008-11-07 Thread Sonny Rao
On Fri, Nov 07, 2008 at 04:28:29PM +1100, Paul Mackerras wrote:
> Sonny Rao writes:
> 
> > Fix the BSR driver to allow small BSR devices, which are limited to a
> > single 4k space, on a 64k page kernel.  Previously the driver would
> > reject the mmap since the size was smaller than PAGESIZE (or because
> > the size was greater than the size of the device).  Now, we check for
> > this case use remap_4k_pfn(). Also, take out code to set vm_flags,
> > as the remap_pfn functions will do this for us.
> 
> Thanks.
> 
> Do we know that the BSR size will always be 4k if it's not a multiple
> of 64k?  Is it possible that we could get 8k, 16k or 32k or BSRs?
> If it is possible, what does the user need to be able to do?  Do they
> just want to map 4k, or might then want to map the whole thing?

Hi Paul, the BSR comes in 4 different sizes, 8, 16, 64, 128.

The 8 byte BSR registers are always contained to 4k pages and are
always representing a piece of a larger BSR, but can be assigned to
individual LPARs.  

The 16 byte BSR is contained in two 4k pages, and so the code as
patched would not allow both 4k pages to be mapped.  However, I don't
see any reason for the user to need both 4k pages.  

To give some background as to why the BSR exists in multiple pages at
all I'll say that one proposed way to use the BSR is to have each
participating cpu "own" a cache-line sized piece of the BSR mapped
page and write only to that piece.  The reasoning is that using this approach,
software could use either a BSR or regular cachable memory for the
barrier operation, and I would not need to know which it is actually
using.  So in this type of scenario, there should be enough
cache-lines sized pieces mappable. In the case of the 16 byte BSR, one
4k page contains 32 128byte cache-line pieces.  So this is enough to
still use the BSR in this way.

The 64 byte BSR is contained in 16 4k-pages -- so one 64k page works
there, and the 128 byte BSR is contained in 32 4k pages.

The case of the 16 byte BSR is the only one where it matters, I can
change the code to map both 4k pages if the user requests it, but I
don't see any extra utility.  For consistency though, maybe we should
reject a request to map more than 4k but less than 64k on a 64k kernel?

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


Re: pmac_zilog debugging ...

2008-11-07 Thread Benjamin Herrenschmidt
On Fri, 2008-11-07 at 13:38 -0800, Kevin Diggs wrote:
> to connect an 8600 to a laptop via ppp the link will lock up in short
> order from "payloaded" pings. Any advice on how to figure out where it
> is locking up? This command works fine to connect two x86 laptops. At
> 1200 it does take a while for an xterm to show up, though.

Flow control might be busted. You may need to revert the polarity of the
CTS line sampling. Let me know what you find out.

Cheers,
Ben.


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


pmac_zilog debugging ...

2008-11-07 Thread Kevin Diggs

Hi,

If I use a command similar to:

pppd ttyS0 1200 satellites: netmask 255.255.255.0 lock crtscts mru 1064 noauth debug kdebug 7 
logfile /tmp/pppd.log local


to connect an 8600 to a laptop via ppp the link will lock up in short
order from "payloaded" pings. Any advice on how to figure out where it
is locking up? This command works fine to connect two x86 laptops. At
1200 it does take a while for an xterm to show up, though.

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


MPC5200B and the CAN interface

2008-11-07 Thread Nick
Hi Everyone,

I am looking for information on how to use the CAN driver for the MPC5200b.  I 
have built the kernel (2.6.27) with the MPC5200b can bus drivers and I see them 
being initialized on start up.

[   37.122041] can: controller area network core (rev 20071116 abi 8)
[   37.128687] NET: Registered protocol family 29
[   37.133379] can: raw protocol (rev 20071116)
[   37.137807] can: broadcast manager protocol (rev 20080415)

Do I have to define a UDEV rule?  Has anyone already written a rule to make the 
can driver visible in /dev?

Any pointers or snippets of code would be greatly appreciated.

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


[PATCH] IB/ehca: Fix suppression of port activation events

2008-11-07 Thread Joachim Fenkes
A previous fix introduced a regression where port activation events were
dropped unconditionally if port autodetection was not enabled. Fixed.

Signed-off-by: Joachim Fenkes <[EMAIL PROTECTED]>
---

Roland -- this patch is made against your for-linus branch. Please review
and apply if you think it's okay. Hope it's not too late for the next kernel.

Joachim

 drivers/infiniband/hw/ehca/ehca_irq.c |   45 +++-
 1 files changed, 27 insertions(+), 18 deletions(-)

diff --git a/drivers/infiniband/hw/ehca/ehca_irq.c 
b/drivers/infiniband/hw/ehca/ehca_irq.c
index 9e43459..757035e 100644
--- a/drivers/infiniband/hw/ehca/ehca_irq.c
+++ b/drivers/infiniband/hw/ehca/ehca_irq.c
@@ -359,34 +359,43 @@ static void notify_port_conf_change(struct ehca_shca 
*shca, int port_num)
*old_attr = new_attr;
 }
 
+/* replay modify_qp for sqps -- return 0 if all is well, 1 if AQP1 destroyed */
+static int replay_modify_qp(struct ehca_sport *sport)
+{
+   int aqp1_destroyed;
+   unsigned long flags;
+
+   spin_lock_irqsave(&sport->mod_sqp_lock, flags);
+
+   aqp1_destroyed = !sport->ibqp_sqp[IB_QPT_GSI];
+
+   if (sport->ibqp_sqp[IB_QPT_SMI])
+   ehca_recover_sqp(sport->ibqp_sqp[IB_QPT_SMI]);
+   if (!aqp1_destroyed)
+   ehca_recover_sqp(sport->ibqp_sqp[IB_QPT_GSI]);
+
+   spin_unlock_irqrestore(&sport->mod_sqp_lock, flags);
+
+   return aqp1_destroyed;
+}
+
 static void parse_ec(struct ehca_shca *shca, u64 eqe)
 {
u8 ec   = EHCA_BMASK_GET(NEQE_EVENT_CODE, eqe);
u8 port = EHCA_BMASK_GET(NEQE_PORT_NUMBER, eqe);
u8 spec_event;
struct ehca_sport *sport = &shca->sport[port - 1];
-   unsigned long flags;
 
switch (ec) {
case 0x30: /* port availability change */
if (EHCA_BMASK_GET(NEQE_PORT_AVAILABILITY, eqe)) {
-   /* only for autodetect mode important */
-   if (ehca_nr_ports >= 0)
-   break;
-
-   int suppress_event;
-   /* replay modify_qp for sqps */
-   spin_lock_irqsave(&sport->mod_sqp_lock, flags);
-   suppress_event = !sport->ibqp_sqp[IB_QPT_GSI];
-   if (sport->ibqp_sqp[IB_QPT_SMI])
-   ehca_recover_sqp(sport->ibqp_sqp[IB_QPT_SMI]);
-   if (!suppress_event)
-   ehca_recover_sqp(sport->ibqp_sqp[IB_QPT_GSI]);
-   spin_unlock_irqrestore(&sport->mod_sqp_lock, flags);
-
-   /* AQP1 was destroyed, ignore this event */
-   if (suppress_event)
-   break;
+   /* only replay modify_qp calls in autodetect mode;
+* if AQP1 was destroyed, the port is already down
+* again and we can drop the event.
+*/
+   if (ehca_nr_ports < 0)
+   if (replay_modify_qp(sport))
+   break;
 
sport->port_state = IB_PORT_ACTIVE;
dispatch_port_event(shca, port, IB_EVENT_PORT_ACTIVE,
-- 
1.5.5




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


Re: [PATCH] powerpc: Watchdog timer support for GE Fanuc SBC610

2008-11-07 Thread Kumar Gala


On Nov 7, 2008, at 9:16 AM, Martyn Welch wrote:


On Fri, 7 Nov 2008 08:44:45 -0600
Kumar Gala <[EMAIL PROTECTED]> wrote:


On Nov 7, 2008, at 8:38 AM, Martyn Welch wrote:


Support for the SBC610 VPX Single Baord Computer from GE Fanuc
(PowerPC
MPC8641D).

This patch adds support for the watchdog timer in the devices main
FPGA.
There are two identical watchdog timers at different offsets in the
main
FPGA, this driver is capable of supporting one of them. The watchdog
timers
are also capable of generating interrupts at a user-configurable
threshold,
though support for this operation is currently not supported by the
driver.

Signed-off-by: Martyn Welch <[EMAIL PROTECTED]>
---

arch/powerpc/boot/dts/gef_sbc610.dts   |   19 +
arch/powerpc/configs/86xx/gef_sbc610_defconfig |1
drivers/watchdog/Kconfig   |6
drivers/watchdog/Makefile  |1
drivers/watchdog/gef_wdt.c |  333 + 
++

+
5 files changed, 360 insertions(+), 0 deletions(-)


Can you break this into two patches.  One for the driver and one for
the arch/powerpc stuff.  the driver should go via the watchdog
maintainer (and CC that list).



Yeah - sorry, didn't think about that.

Thinking about it, the driver is specific to GEF Fanuc boards,  
should this be
going into drivers/watchdog/ or would it be better for me to move it  
to

arch/powerpc?


It should still be in drivers/watchdog.

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


Re: [PATCH] powerpc: Watchdog timer support for GE Fanuc SBC610

2008-11-07 Thread Martyn Welch
On Fri, 7 Nov 2008 08:44:45 -0600
Kumar Gala <[EMAIL PROTECTED]> wrote:
> 
> On Nov 7, 2008, at 8:38 AM, Martyn Welch wrote:
> 
> > Support for the SBC610 VPX Single Baord Computer from GE Fanuc  
> > (PowerPC
> > MPC8641D).
> >
> > This patch adds support for the watchdog timer in the devices main  
> > FPGA.
> > There are two identical watchdog timers at different offsets in the  
> > main
> > FPGA, this driver is capable of supporting one of them. The watchdog  
> > timers
> > are also capable of generating interrupts at a user-configurable  
> > threshold,
> > though support for this operation is currently not supported by the  
> > driver.
> >
> > Signed-off-by: Martyn Welch <[EMAIL PROTECTED]>
> > ---
> >
> > arch/powerpc/boot/dts/gef_sbc610.dts   |   19 +
> > arch/powerpc/configs/86xx/gef_sbc610_defconfig |1
> > drivers/watchdog/Kconfig   |6
> > drivers/watchdog/Makefile  |1
> > drivers/watchdog/gef_wdt.c |  333 +++ 
> > +
> > 5 files changed, 360 insertions(+), 0 deletions(-)
> 
> Can you break this into two patches.  One for the driver and one for  
> the arch/powerpc stuff.  the driver should go via the watchdog  
> maintainer (and CC that list).
> 

Yeah - sorry, didn't think about that.

Thinking about it, the driver is specific to GEF Fanuc boards, should this be 
going into drivers/watchdog/ or would it be better for me to move it to 
arch/powerpc?

Martyn

> - k


-- 
Martyn Welch MEng MPhil MIET (Principal Software Engineer)   T:+44(0)1327322748
GE Fanuc Intelligent Platforms Ltd,|Registered in England and Wales
Tove Valley Business Park, Towcester,  |(3828642) at 100 Barbirolli Square,
Northants, NN12 6PF, UK T:+44(0)1327359444 |Manchester,M2 3AB  VAT:GB 729849476
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev


Re: [PATCH] powerpc/86xx: Correct SOC bus-frequency in GE Fanuc SBC610 DTS

2008-11-07 Thread Martyn Welch
On Fri, 7 Nov 2008 08:45:11 -0600
Kumar Gala <[EMAIL PROTECTED]> wrote:
> 
> On Nov 7, 2008, at 7:43 AM, Martyn Welch wrote:
> 
> > This patch corrects the bus-frequency value provided in the SBC610's  
> > dts.
> >
> > Signed-off-by: Martyn Welch <[EMAIL PROTECTED]>
> > ---
> >
> > arch/powerpc/boot/dts/gef_sbc610.dts |2 +-
> > 1 files changed, 1 insertions(+), 1 deletions(-)
> >
> > diff --git a/arch/powerpc/boot/dts/gef_sbc610.dts b/arch/powerpc/ 
> > boot/dts/gef_sbc610.dts
> > index fd2b606..1f7833c 100644
> > --- a/arch/powerpc/boot/dts/gef_sbc610.dts
> > +++ b/arch/powerpc/boot/dts/gef_sbc610.dts
> > @@ -114,7 +114,7 @@
> > compatible = "simple-bus";
> > ranges = <0x0 0xfef0 0x0010>;
> > reg = <0xfef0 0x10>;// CCSRBAR 1M
> > -   bus-frequency = <0>;
> > +   bus-frequency = <>;
> >
> > i2c1: [EMAIL PROTECTED] {
> > #address-cells = <1>;
> 
> are we not fixing this up in u-boot?
> 

The SBC610 has uboot 1.2.0, which doesn't seem to be changing this.

> - k


-- 
Martyn Welch MEng MPhil MIET (Principal Software Engineer)   T:+44(0)1327322748
GE Fanuc Intelligent Platforms Ltd,|Registered in England and Wales
Tove Valley Business Park, Towcester,  |(3828642) at 100 Barbirolli Square,
Northants, NN12 6PF, UK T:+44(0)1327359444 |Manchester,M2 3AB  VAT:GB 729849476
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev


Re: [PATCH] powerpc/86xx: Correct SOC bus-frequency in GE Fanuc SBC610 DTS

2008-11-07 Thread Kumar Gala


On Nov 7, 2008, at 7:43 AM, Martyn Welch wrote:

This patch corrects the bus-frequency value provided in the SBC610's  
dts.


Signed-off-by: Martyn Welch <[EMAIL PROTECTED]>
---

arch/powerpc/boot/dts/gef_sbc610.dts |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/arch/powerpc/boot/dts/gef_sbc610.dts b/arch/powerpc/ 
boot/dts/gef_sbc610.dts

index fd2b606..1f7833c 100644
--- a/arch/powerpc/boot/dts/gef_sbc610.dts
+++ b/arch/powerpc/boot/dts/gef_sbc610.dts
@@ -114,7 +114,7 @@
compatible = "simple-bus";
ranges = <0x0 0xfef0 0x0010>;
reg = <0xfef0 0x10>;  // CCSRBAR 1M
-   bus-frequency = <0>;
+   bus-frequency = <>;

i2c1: [EMAIL PROTECTED] {
#address-cells = <1>;


are we not fixing this up in u-boot?

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


Re: [PATCH] powerpc: Watchdog timer support for GE Fanuc SBC610

2008-11-07 Thread Kumar Gala


On Nov 7, 2008, at 8:38 AM, Martyn Welch wrote:

Support for the SBC610 VPX Single Baord Computer from GE Fanuc  
(PowerPC

MPC8641D).

This patch adds support for the watchdog timer in the devices main  
FPGA.
There are two identical watchdog timers at different offsets in the  
main
FPGA, this driver is capable of supporting one of them. The watchdog  
timers
are also capable of generating interrupts at a user-configurable  
threshold,
though support for this operation is currently not supported by the  
driver.


Signed-off-by: Martyn Welch <[EMAIL PROTECTED]>
---

arch/powerpc/boot/dts/gef_sbc610.dts   |   19 +
arch/powerpc/configs/86xx/gef_sbc610_defconfig |1
drivers/watchdog/Kconfig   |6
drivers/watchdog/Makefile  |1
drivers/watchdog/gef_wdt.c |  333 +++ 
+

5 files changed, 360 insertions(+), 0 deletions(-)


Can you break this into two patches.  One for the driver and one for  
the arch/powerpc stuff.  the driver should go via the watchdog  
maintainer (and CC that list).


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


[PATCH] powerpc: Watchdog timer support for GE Fanuc SBC610

2008-11-07 Thread Martyn Welch
Support for the SBC610 VPX Single Baord Computer from GE Fanuc (PowerPC
MPC8641D).

This patch adds support for the watchdog timer in the devices main FPGA.
There are two identical watchdog timers at different offsets in the main
FPGA, this driver is capable of supporting one of them. The watchdog timers
are also capable of generating interrupts at a user-configurable threshold,
though support for this operation is currently not supported by the driver.

Signed-off-by: Martyn Welch <[EMAIL PROTECTED]>
---

 arch/powerpc/boot/dts/gef_sbc610.dts   |   19 +
 arch/powerpc/configs/86xx/gef_sbc610_defconfig |1 
 drivers/watchdog/Kconfig   |6 
 drivers/watchdog/Makefile  |1 
 drivers/watchdog/gef_wdt.c |  333 
 5 files changed, 360 insertions(+), 0 deletions(-)

diff --git a/arch/powerpc/boot/dts/gef_sbc610.dts 
b/arch/powerpc/boot/dts/gef_sbc610.dts
index 1f7833c..5c7a38a 100644
--- a/arch/powerpc/boot/dts/gef_sbc610.dts
+++ b/arch/powerpc/boot/dts/gef_sbc610.dts
@@ -88,6 +88,25 @@
compatible = "gef,fpga-regs";
reg = <0x4 0x0 0x40>;
};
+
+   [EMAIL PROTECTED],2000 {
+   #interrupt-cells = <2>;
+   device_type = "watchdog";
+   compatible = "gef,fpga-wdt";
+   reg = <0x4 0x2000 0x8>;
+   interrupts = <0x1a 0x4>;
+   interrupt-parent = <&gef_pic>;
+   };
+   /* Second watchdog available, driver currently supports one.
+   [EMAIL PROTECTED],2010 {
+   #interrupt-cells = <2>;
+   device_type = "watchdog";
+   compatible = "gef,fpga-wdt";
+   reg = <0x4 0x2010 0x8>;
+   interrupts = <0x1b 0x4>;
+   interrupt-parent = <&gef_pic>;
+   };
+   */
gef_pic: [EMAIL PROTECTED],4000 {
#interrupt-cells = <1>;
interrupt-controller;
diff --git a/arch/powerpc/configs/86xx/gef_sbc610_defconfig 
b/arch/powerpc/configs/86xx/gef_sbc610_defconfig
index 312d7af..99fe882 100644
--- a/arch/powerpc/configs/86xx/gef_sbc610_defconfig
+++ b/arch/powerpc/configs/86xx/gef_sbc610_defconfig
@@ -1109,6 +1109,7 @@ CONFIG_WATCHDOG=y
 # Watchdog Device Drivers
 #
 # CONFIG_SOFT_WATCHDOG is not set
+CONFIG_GEF_WDT=y
 
 #
 # PCI-based Watchdog Cards
diff --git a/drivers/watchdog/Kconfig b/drivers/watchdog/Kconfig
index 1a22fe7..df91e88 100644
--- a/drivers/watchdog/Kconfig
+++ b/drivers/watchdog/Kconfig
@@ -778,6 +778,12 @@ config BOOKE_WDT
  Please see Documentation/watchdog/watchdog-api.txt for
  more information.
 
+config GEF_WDT
+   tristate "GE Fanuc Watchdog Timer"
+   depends on GEF_SBC610
+   ---help---
+ Watchdog timer found in a number of GE Fanuc single board computers.
+
 # PPC64 Architecture
 
 config WATCHDOG_RTAS
diff --git a/drivers/watchdog/Makefile b/drivers/watchdog/Makefile
index e352bbb..be7e1d3 100644
--- a/drivers/watchdog/Makefile
+++ b/drivers/watchdog/Makefile
@@ -114,6 +114,7 @@ obj-$(CONFIG_MPC5200_WDT) += mpc5200_wdt.o
 obj-$(CONFIG_8xxx_WDT) += mpc8xxx_wdt.o
 obj-$(CONFIG_MV64X60_WDT) += mv64x60_wdt.o
 obj-$(CONFIG_BOOKE_WDT) += booke_wdt.o
+obj-$(CONFIG_GEF_WDT) += gef_wdt.o
 
 # PPC64 Architecture
 obj-$(CONFIG_WATCHDOG_RTAS) += wdrtas.o
diff --git a/drivers/watchdog/gef_wdt.c b/drivers/watchdog/gef_wdt.c
new file mode 100644
index 000..f82ef9c
--- /dev/null
+++ b/drivers/watchdog/gef_wdt.c
@@ -0,0 +1,333 @@
+/*
+ * GE Fanuc watchdog userspace interface
+ *
+ * Author:  Martyn Welch <[EMAIL PROTECTED]>
+ *
+ * Copyright 2008 GE Fanuc Intelligent Platforms Embedded Systems, 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
+ * Free Software Foundation;  either version 2 of the  License, or (at your
+ * option) any later version.
+ *
+ * Based on: mv64x60_wdt.c (MV64X60 watchdog userspace interface)
+ *   Author: James Chapman <[EMAIL PROTECTED]>
+ */
+
+/* TODO:
+ * This driver does not provide support for the hardwares capability of sending
+ * an interrupt at a programmable threshold.
+ *
+ * This driver currently can only support 1 watchdog - there are 2 in the
+ * hardware that this driver supports. Thus one could be configured as a
+ * process-based watchdog (via /dev/watchdog), the second (using the interrupt
+ * capabilities) a kernel-based watchdog.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+
+/*
+ * The watchdog configuration register contains a pair of 2-bit fields,
+ *   1.  a reload field, bits 27-26, which triggers a reload of
+ *   

[PATCH v4] powerpc: Basic GPIO support for GE Fanuc SBC610

2008-11-07 Thread Martyn Welch
Basic support for the GPIO available on the SBC610 VPX Single Board Computer
from GE Fanuc (PowerPC MPC8641D).

This patch adds basic support for the GPIO in the devices I/O FPGA, the GPIO
functionality is exposed through the AFIX pins on the backplane, unless used
by an AFIX card.

This code currently does not support switching between totem-pole and
open-drain outputs (when used as outputs, GPIOs default to totem-pole).
The interrupt capabilites of the GPIO lines is also not currently supported.

Signed-off-by: Martyn Welch <[EMAIL PROTECTED]>
---

Anton: Thank you for your fast response.

Changes since version 3:
 * Removed repetitive and obvious comments
 * Removed stray empty line

 arch/powerpc/boot/dts/gef_sbc610.dts   |6 +
 arch/powerpc/platforms/86xx/Kconfig|2 
 arch/powerpc/platforms/86xx/Makefile   |3 -
 arch/powerpc/platforms/86xx/gef_gpio.c |  143 
 4 files changed, 153 insertions(+), 1 deletions(-)

diff --git a/arch/powerpc/boot/dts/gef_sbc610.dts 
b/arch/powerpc/boot/dts/gef_sbc610.dts
index 6ed6083..fd2b606 100644
--- a/arch/powerpc/boot/dts/gef_sbc610.dts
+++ b/arch/powerpc/boot/dts/gef_sbc610.dts
@@ -98,6 +98,12 @@
interrupt-parent = <&mpic>;
 
};
+   gef_gpio: [EMAIL PROTECTED],14000 {
+   #gpio-cells = <2>;
+   compatible = "gef,sbc610-gpio";
+   reg = <0x7 0x14000 0x24>;
+   gpio-controller;
+   };
};
 
[EMAIL PROTECTED] {
diff --git a/arch/powerpc/platforms/86xx/Kconfig 
b/arch/powerpc/platforms/86xx/Kconfig
index 77dd797..8e56939 100644
--- a/arch/powerpc/platforms/86xx/Kconfig
+++ b/arch/powerpc/platforms/86xx/Kconfig
@@ -34,6 +34,8 @@ config MPC8610_HPCD
 config GEF_SBC610
bool "GE Fanuc SBC610"
select DEFAULT_UIMAGE
+   select GENERIC_GPIO
+   select ARCH_REQUIRE_GPIOLIB
select HAS_RAPIDIO
help
  This option enables support for GE Fanuc's SBC610.
diff --git a/arch/powerpc/platforms/86xx/Makefile 
b/arch/powerpc/platforms/86xx/Makefile
index 4a56ff6..31e540c 100644
--- a/arch/powerpc/platforms/86xx/Makefile
+++ b/arch/powerpc/platforms/86xx/Makefile
@@ -7,4 +7,5 @@ obj-$(CONFIG_SMP)   += mpc86xx_smp.o
 obj-$(CONFIG_MPC8641_HPCN) += mpc86xx_hpcn.o
 obj-$(CONFIG_SBC8641D) += sbc8641d.o
 obj-$(CONFIG_MPC8610_HPCD) += mpc8610_hpcd.o
-obj-$(CONFIG_GEF_SBC610)   += gef_sbc610.o gef_pic.o
+gef-gpio-$(CONFIG_GPIOLIB) += gef_gpio.o
+obj-$(CONFIG_GEF_SBC610)   += gef_sbc610.o gef_pic.o $(gef-gpio-y)
diff --git a/arch/powerpc/platforms/86xx/gef_gpio.c 
b/arch/powerpc/platforms/86xx/gef_gpio.c
new file mode 100644
index 000..85b2800
--- /dev/null
+++ b/arch/powerpc/platforms/86xx/gef_gpio.c
@@ -0,0 +1,143 @@
+/*
+ * Driver for GE Fanuc's FPGA based GPIO pins
+ *
+ * Author: Martyn Welch <[EMAIL PROTECTED]>
+ *
+ * 2008 (c) GE Fanuc Intelligent Platforms Embedded Systems, Inc.
+ *
+ * This file is licensed under the terms of the GNU General Public License
+ * version 2.  This program is licensed "as is" without any warranty of any
+ * kind, whether express or implied.
+ */
+
+/* TODO
+ *
+ * Configuration of output modes (totem-pole/open-drain)
+ * Interrupt configuration - interrupts are always generated the FPGA relies on
+ * the I/O interrupt controllers mask to stop them propergating
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define GEF_GPIO_DIRECT0x00
+#define GEF_GPIO_IN0x04
+#define GEF_GPIO_OUT   0x08
+#define GEF_GPIO_TRIG  0x0C
+#define GEF_GPIO_POLAR_A   0x10
+#define GEF_GPIO_POLAR_B   0x14
+#define GEF_GPIO_INT_STAT  0x18
+#define GEF_GPIO_OVERRUN   0x1C
+#define GEF_GPIO_MODE  0x20
+
+#define NUM_GPIO 19
+
+static void _gef_gpio_set(void __iomem *reg, unsigned int offset, int value)
+{
+   unsigned int data;
+
+   data = ioread32be(reg);
+   /* value: 0=low; 1=high */
+   if (value & 0x1)
+   data = data | (0x1 << offset);
+   else
+   data = data & ~(0x1 << offset);
+
+   iowrite32be(data, reg);
+}
+
+
+static int gef_gpio_dir_in(struct gpio_chip *chip, unsigned offset)
+{
+   unsigned int data;
+   struct of_mm_gpio_chip *mmchip = to_of_mm_gpio_chip(chip);
+
+   data = ioread32be(mmchip->regs + GEF_GPIO_DIRECT);
+   data = data | (0x1 << offset);
+   iowrite32be(data, mmchip->regs + GEF_GPIO_DIRECT);
+
+   return 0;
+}
+
+static int gef_gpio_dir_out(struct gpio_chip *chip, unsigned offset, int value)
+{
+   unsigned int data;
+   struct of_mm_gpio_chip *mmchip = to_of_mm_gpio_chip(chip);
+
+   /* Set direction before switching to input */
+   _gef_gpio_set(mmchip->regs + GEF_GPIO_OUT, offset, value);
+
+   data = ioread32be(mmchip->regs + GEF_GPIO_DIRECT);

Re: [PATCH 3/3] powerpc/ppc64/kdump: better flag for running relocatable

2008-11-07 Thread Milton Miller

On Oct 23, 2008, at 10:15 AM, Mohan Kumar M wrote:

Hi Milton,
My suggestions:
Milton Miller wrote:

The __kdump_flag ABI is overly constraining for future development.

...

Now that we have eliminated the use of __kdump_flag in favor of
the standard is_kdump_kernel(), this flag only controls run without
relocating the kernel to PHYSICAL_START (0), so rename it 
__run_at_load.


We could try both of our approaches. Instead of passing the 
information that next kernel should be relocatable from kexec_sequence 
to purgatory code, we will do it from kexec-tools path (following your 
approach). But instead of setting the __run_at_load value in the 
purgatory code (ie at physical address 0x5c), we will set the variable 
__run_at_load at kernel  image itself.


i.e.,
[code snip 1]
lwz r7,__run_at_load-_stext(r26)
cmplwi  cr0,r7,1/* kdump kernel ? - stay where we are */
bne 1f
add r25,r25,r26

lwz r7,__run_at_load-_stext(r26)
cmplwi  cr0,r7,1
bne 3f

kexec-tools
[code snip 2]
LOADADDR(6,run_at_load)
ld  18,0(6)
cmpd18,1
bne skip
li  7,1
stw 7,92(4) # mark __run_at_load flag at kernel
skip:
lwz 7,0(4)  # get the first instruction that we stole
stw 7,0(0)  # and put it in the slave loop at 0
# skip cache flush, do we care?

[code snip 3]
if (info->kexec_flags & KEXEC_ON_CRASH) {

elf_rel_set_symbol(&info->rhdr, "run_at_load",
&my_run_at_load, 			 
sizeof(my_run_at_load));

}



This elf_rel_set_symbol sets the copy in purgatory,
after we have copied the code from the kernel.  It
is this copy that gets copied to address 0.

However this information is not in the code that
is at the start of the kernel.  We don't have any
symbols for the kernel itself, it might be stripped.
So we can't use the elf_set_symbol api.  (The kernel
may not be relocatable either).


Using this approach we are not breaking the kexec_sequence
ABI and we directly modifying the flag in kernel image.

Regards,
Mohan.


I'll prepare a patch, but it might be a few days
while I catch up from my 2 week vacation.

milton

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


Re: [PATCH v3] powerpc: Basic GPIO support for GE Fanuc SBC610

2008-11-07 Thread Anton Vorontsov
On Fri, Nov 07, 2008 at 01:00:15PM +, Martyn Welch wrote:
> Basic support for the GPIO available on the SBC610 VPX Single Board Computer
> from GE Fanuc (PowerPC MPC8641D).
> 
> This patch adds basic support for the GPIO in the devices I/O FPGA, the GPIO
> functionality is exposed through the AFIX pins on the backplane, unless used
> by an AFIX card.
> 
> This code currently does not support switching between totem-pole and
> open-drain outputs (when used as outputs, GPIOs default to totem-pole).
> The interrupt capabilites of the GPIO lines is also not currently supported.
> 
> Signed-off-by: Martyn Welch <[EMAIL PROTECTED]>

Looks great.

Reviewed-by: Anton Vorontsov <[EMAIL PROTECTED]>

[...]
> +static void gef_gpio_set(struct gpio_chip *chip, unsigned offset, int value)
> +{
> + struct of_mm_gpio_chip *mmchip;
> +
> + /* Find memory mapped gpio chip structure from gpio_chip, this contains
> +  * the mapped location of the GPIO controller
> +  */

Just nitpicking, you might want to remove this repetitive
comment, it is quite obvious anyway. Will save 5 lines of code per
function, 20 lines in sum.

struct of_mm_gpio_chip *mmchip = to_of_mm_gpio_chip(chip);

> + mmchip = to_of_mm_gpio_chip(chip);
> +
> + _gef_gpio_set(mmchip->regs + GEF_GPIO_OUT, offset, value);
> +

Stray empty line here.

> +}
> +

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


Re: [PATCH 3/3] powerpc/ppc64/kdump: better flag for running relocatable

2008-11-07 Thread Milton Miller

On Oct 22, 2008, at 10:43 PM, Paul Mackerras wrote:

Paul Mackerras writes:

Milton Miller writes:

Move the flag to 0x5c, 1 word before the secondary cpu entry point at
0x60.  Use the copy at address 0 not the one in the base kernel 
image to

make it easier on kexec-tools.


Why is it easier on kexec-tools?  Doesn't kexec-tools know where it
put the kernel?


The archictecture code calls cross-platform code to identify what is
loaded.   It isn't specified if this is a shared mmap or a read into
a buffer.



I'd much rather keep the flag inside the kdump kernel image, rather
than having kexec/kdump start using random fixed locations outside the
new kernel image.


In fact the cliching argument is that when the kernel is loaded by OF
or yaboot, we have no way to tell what will be at location 0x5c,
whereas we know that the word at offset 0x5c in the kernel image will
have been initialized to 0.  So we had better put the flag inside the
kernel image.


Well, prom_init will copy the 256 bytes to 0 before the code checks
that location.

However, there is an arguement for using the same code from an epapr
or book-e relocatable, and that would need it at 0.   And today
the kexec tool does not do a shared mmap.  Since the change has
been made, I will make a new patch for kexec-tools.

milton

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


[PATCH] powerpc/86xx: Correct SOC bus-frequency in GE Fanuc SBC610 DTS

2008-11-07 Thread Martyn Welch
This patch corrects the bus-frequency value provided in the SBC610's dts.

Signed-off-by: Martyn Welch <[EMAIL PROTECTED]>
---

 arch/powerpc/boot/dts/gef_sbc610.dts |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/arch/powerpc/boot/dts/gef_sbc610.dts 
b/arch/powerpc/boot/dts/gef_sbc610.dts
index fd2b606..1f7833c 100644
--- a/arch/powerpc/boot/dts/gef_sbc610.dts
+++ b/arch/powerpc/boot/dts/gef_sbc610.dts
@@ -114,7 +114,7 @@
compatible = "simple-bus";
ranges = <0x0 0xfef0 0x0010>;
reg = <0xfef0 0x10>;// CCSRBAR 1M
-   bus-frequency = <0>;
+   bus-frequency = <>;
 
i2c1: [EMAIL PROTECTED] {
#address-cells = <1>;

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


[PATCH v3] powerpc: Basic GPIO support for GE Fanuc SBC610

2008-11-07 Thread Martyn Welch
Basic support for the GPIO available on the SBC610 VPX Single Board Computer
from GE Fanuc (PowerPC MPC8641D).

This patch adds basic support for the GPIO in the devices I/O FPGA, the GPIO
functionality is exposed through the AFIX pins on the backplane, unless used
by an AFIX card.

This code currently does not support switching between totem-pole and
open-drain outputs (when used as outputs, GPIOs default to totem-pole).
The interrupt capabilites of the GPIO lines is also not currently supported.

Signed-off-by: Martyn Welch <[EMAIL PROTECTED]>
---

Anton: Thank you for your input.

The folowing changes have been made in version 3:
 * Use 2 gpio-cells rather than 1 (Will be used in future)
 * Added linux/compiler.h
 * Removed un-needed debugging
 * _gef_gpio_set changed from inline to static
 * Corrected comment style
 * Removed potential memory leak
 * Made ".compatible" more specific (Not as generic as I had first thought)
 * Simplified driver registration

 arch/powerpc/boot/dts/gef_sbc610.dts   |6 +
 arch/powerpc/platforms/86xx/Kconfig|2 
 arch/powerpc/platforms/86xx/Makefile   |3 -
 arch/powerpc/platforms/86xx/gef_gpio.c |  167 
 4 files changed, 177 insertions(+), 1 deletions(-)

diff --git a/arch/powerpc/boot/dts/gef_sbc610.dts 
b/arch/powerpc/boot/dts/gef_sbc610.dts
index 6ed6083..fd2b606 100644
--- a/arch/powerpc/boot/dts/gef_sbc610.dts
+++ b/arch/powerpc/boot/dts/gef_sbc610.dts
@@ -98,6 +98,12 @@
interrupt-parent = <&mpic>;
 
};
+   gef_gpio: [EMAIL PROTECTED],14000 {
+   #gpio-cells = <2>;
+   compatible = "gef,sbc610-gpio";
+   reg = <0x7 0x14000 0x24>;
+   gpio-controller;
+   };
};
 
[EMAIL PROTECTED] {
diff --git a/arch/powerpc/platforms/86xx/Kconfig 
b/arch/powerpc/platforms/86xx/Kconfig
index 77dd797..8e56939 100644
--- a/arch/powerpc/platforms/86xx/Kconfig
+++ b/arch/powerpc/platforms/86xx/Kconfig
@@ -34,6 +34,8 @@ config MPC8610_HPCD
 config GEF_SBC610
bool "GE Fanuc SBC610"
select DEFAULT_UIMAGE
+   select GENERIC_GPIO
+   select ARCH_REQUIRE_GPIOLIB
select HAS_RAPIDIO
help
  This option enables support for GE Fanuc's SBC610.
diff --git a/arch/powerpc/platforms/86xx/Makefile 
b/arch/powerpc/platforms/86xx/Makefile
index 4a56ff6..31e540c 100644
--- a/arch/powerpc/platforms/86xx/Makefile
+++ b/arch/powerpc/platforms/86xx/Makefile
@@ -7,4 +7,5 @@ obj-$(CONFIG_SMP)   += mpc86xx_smp.o
 obj-$(CONFIG_MPC8641_HPCN) += mpc86xx_hpcn.o
 obj-$(CONFIG_SBC8641D) += sbc8641d.o
 obj-$(CONFIG_MPC8610_HPCD) += mpc8610_hpcd.o
-obj-$(CONFIG_GEF_SBC610)   += gef_sbc610.o gef_pic.o
+gef-gpio-$(CONFIG_GPIOLIB) += gef_gpio.o
+obj-$(CONFIG_GEF_SBC610)   += gef_sbc610.o gef_pic.o $(gef-gpio-y)
diff --git a/arch/powerpc/platforms/86xx/gef_gpio.c 
b/arch/powerpc/platforms/86xx/gef_gpio.c
new file mode 100644
index 000..352d131
--- /dev/null
+++ b/arch/powerpc/platforms/86xx/gef_gpio.c
@@ -0,0 +1,167 @@
+/*
+ * Driver for GE Fanuc's FPGA based GPIO pins
+ *
+ * Author: Martyn Welch <[EMAIL PROTECTED]>
+ *
+ * 2008 (c) GE Fanuc Intelligent Platforms Embedded Systems, Inc.
+ *
+ * This file is licensed under the terms of the GNU General Public License
+ * version 2.  This program is licensed "as is" without any warranty of any
+ * kind, whether express or implied.
+ */
+
+/* TODO
+ *
+ * Configuration of output modes (totem-pole/open-drain)
+ * Interrupt configuration - interrupts are always generated the FPGA relies on
+ * the I/O interrupt controllers mask to stop them propergating
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define GEF_GPIO_DIRECT0x00
+#define GEF_GPIO_IN0x04
+#define GEF_GPIO_OUT   0x08
+#define GEF_GPIO_TRIG  0x0C
+#define GEF_GPIO_POLAR_A   0x10
+#define GEF_GPIO_POLAR_B   0x14
+#define GEF_GPIO_INT_STAT  0x18
+#define GEF_GPIO_OVERRUN   0x1C
+#define GEF_GPIO_MODE  0x20
+
+#define NUM_GPIO 19
+
+/* Let's create a common inlined function to commonise the code and so we don't
+ * have to resolve the chip structure multiple times.
+ */
+static void _gef_gpio_set(void __iomem *reg, unsigned int offset, int value)
+{
+   unsigned int data;
+
+   data = ioread32be(reg);
+   /* value: 0=low; 1=high */
+   if (value & 0x1)
+   data = data | (0x1 << offset);
+   else
+   data = data & ~(0x1 << offset);
+
+   iowrite32be(data, reg);
+}
+
+
+static int gef_gpio_dir_in(struct gpio_chip *chip, unsigned offset)
+{
+   struct of_mm_gpio_chip *mmchip;
+   unsigned int data;
+
+   /* Find memory mapped gpio chip structure from gpio_chip, this contains
+* the mapped location of the GPIO controller
+*/
+