2.6 networking support for Redwood[56]

2004-06-23 Thread Matt Porter

On Wed, Jun 23, 2004 at 05:58:35AM -0700, Dale Farnsworth wrote:

 On Tue, Jun 22, 2004 at 12:41:11AM +, Dale Farnsworth wrote:
  On Mon, Jun 21, 2004 at 11:12:14PM +, Matt Porter wrote:
   On Mon, Jun 21, 2004 at 02:39:48PM -0700, Dale Farnsworth wrote:
   
I'm adding network support for the IBM Redwood5 and Redwood6 in 2.6.
   
It looks like the best supported driver for the smc9 chip
is used by the ARM folks and is found in drivers/net/arm/smc91x.[ch]
This driver recently went into the linux-2.5 tree.
   
I moved these two files into drivers/net so they are available for
PPC as well as ARM and added some Redwood-specific support.  That
was straightforward.  This driver calls a couple of ARM-specific
functions platform_get_resource() and platform_get_irq().  ARM
implements these functions in arch/arm/common/platform.c.  I
copied arch/arm/common/platform.c into arch/ppc/syslib/platform.c
which works fine, but I don't care for duplicated code.  Maybe a
better approach would be to add these functions to 
drivers/base/platform.c
  
   How about wrapping each arch-specific call up in something more abstract
   and then using OCP to get the PPC info?
  
   roughly...
  
   #ifdef CONFIG_PPC_OCP
   TO_SMC_DEVto_ocp_device()
   SMC_GET_BASE_ADDR dev-def-paddr
   ...
   #else /* ARM */
   TO_SMC_DEVto_platform_device()
   SMC_GET_BASE_ADDR platform_get_resource(dev, IORESOURCE_MEM, 1)
   ...
   #endif
  
   There's only about 4 places in the probe/remove calls to do this.
   Add an ocp_add_one_device in your redwood*.c to enable the smc9111
   device with the board-specific attributes.
  
   You may have to play a bit with the prove/remove calls since they
   want to deal with a resource struct, but it might be worth looking
   at.
 
  Sounds like a better approach.  I'll modify the driver to present
  either the ARM interface or the PPC_OCP interface.  Muddles the
  driver a bit, but should keep both archs happy.

 FYI, platform_get_resource() and platform_get_irq() just went into
 linux-2.5/drivers/base/platform.c so this issue is now moot.

Yep, I agree with that.

-Matt

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/





2.6 networking support for Redwood[56]

2004-06-21 Thread Dale Farnsworth

I'm adding network support for the IBM Redwood5 and Redwood6 in 2.6.

It looks like the best supported driver for the smc9 chip
is used by the ARM folks and is found in drivers/net/arm/smc91x.[ch]
This driver recently went into the linux-2.5 tree.

I moved these two files into drivers/net so they are available for
PPC as well as ARM and added some Redwood-specific support.  That
was straightforward.  This driver calls a couple of ARM-specific
functions platform_get_resource() and platform_get_irq().  ARM
implements these functions in arch/arm/common/platform.c.  I
copied arch/arm/common/platform.c into arch/ppc/syslib/platform.c
which works fine, but I don't care for duplicated code.  Maybe a
better approach would be to add these functions to drivers/base/platform.c

Comments?  Suggestions on how to go about getting this into linux-2.5?

Thanks,
-Dale Farnsworth

Do mv drivers/net/arm/smc91x.[ch] drivers/net before applying
the following patch.

= drivers/net/smc91x.h 1.2 vs edited =
--- 1.2/drivers/net/smc91x.h2004-06-21 10:16:40 -07:00
+++ edited/drivers/net/smc91x.h 2004-06-21 10:26:08 -07:00
@@ -59,6 +59,43 @@
 #define SMC_insw(a, r, p, l)   readsw((a) + (r), p, l)
 #define SMC_outsw(a, r, p, l)  writesw((a) + (r), p, l)

+#elif defined(CONFIG_REDWOOD_5) || defined(CONFIG_REDWOOD_6)
+
+/* We can only do 16-bit reads and writes in the static memory space. */
+#define SMC_CAN_USE_8BIT   0
+#define SMC_CAN_USE_16BIT  1
+#define SMC_CAN_USE_32BIT  0
+#define SMC_NOWAIT 1
+
+#define SMC_IO_SHIFT   0
+
+#define SMC_inw(a, r)  in_be16((volatile u16 *)((a) + (r)))
+#define SMC_outw(v, a, r)  out_be16((volatile u16 *)((a) + (r)), v)
+#define SMC_insw(a, r, p, l)   \
+   do {\
+   unsigned long __port = (a) + (r);   \
+   u16 *__p = (u16 *)(p);  \
+   int __l = (l);  \
+   insw(__port, __p, __l); \
+   while (__l  0) {   \
+   *__p = swab16(*__p);\
+   __p++;  \
+   __l--;  \
+   }   \
+   } while (0)
+#define SMC_outsw(a, r, p, l)  \
+   do {\
+   unsigned long __port = (a) + (r);   \
+   u16 *__p = (u16 *)(p);  \
+   int __l = (l);  \
+   while (__l  0) {   \
+   /* Believe it or not, the swab isn't needed. */ \
+   outw( /* swab16 */ (*__p++), __port);   \
+   __l--;  \
+   }   \
+   } while (0)
+#define set_irq_type(irq, type)
+
 #elif defined(CONFIG_SA1100_ASSABET)

diff -Nru a/arch/ppc/platforms/4xx/redwood5.c 
b/arch/ppc/platforms/4xx/redwood5.c
--- a/arch/ppc/platforms/4xx/redwood5.c 2004-06-21 13:52:45 -07:00
+++ b/arch/ppc/platforms/4xx/redwood5.c 2004-06-21 13:52:45 -07:00
@@ -14,8 +14,41 @@
 #include linux/config.h
 #include linux/init.h
 #include linux/pagemap.h
+#include linux/device.h
+#include linux/ioport.h
 #include asm/io.h
 #include asm/machdep.h
+#include syslib/platform.h
+
+static struct resource smc91x_resources[] = {
+   [0] = {
+   .start  = SMC9_BASE_ADDR,
+   .end= SMC9_BASE_ADDR + SMC9_REG_SIZE - 1,
+   .flags  = IORESOURCE_MEM,
+   },
+   [1] = {
+   .start  = SMC9_IRQ,
+   .end= SMC9_IRQ,
+   .flags  = IORESOURCE_IRQ,
+   },
+};
+
+static struct platform_device smc91x_device = {
+   .name   = smc91x,
+   .id = 0,
+   .num_resources  = ARRAY_SIZE(smc91x_resources),
+   .resource   = smc91x_resources,
+};
+
+static struct platform_device *redwood5_devs[] __initdata = {
+   smc91x_device,
+};
+
+static int __init
+redwood5_platform_add_devices(void)
+{
+   return platform_add_devices(redwood5_devs, ARRAY_SIZE(redwood5_devs));
+}

 void __init
 redwood5_setup_arch(void)
@@ -44,7 +77,7 @@

printk(\n);
 #endif
-
+   device_initcall(redwood5_platform_add_devices);
 }

 void __init
diff -Nru a/arch/ppc/platforms/4xx/redwood5.h 
b/arch/ppc/platforms/4xx/redwood5.h
--- a/arch/ppc/platforms/4xx/redwood5.h 2004-06-21 13:52:45 -07:00
+++ b/arch/ppc/platforms/4xx/redwood5.h 

2.6 networking support for Redwood[56]

2004-06-21 Thread Matt Porter

On Mon, Jun 21, 2004 at 02:39:48PM -0700, Dale Farnsworth wrote:

 I'm adding network support for the IBM Redwood5 and Redwood6 in 2.6.

 It looks like the best supported driver for the smc9 chip
 is used by the ARM folks and is found in drivers/net/arm/smc91x.[ch]
 This driver recently went into the linux-2.5 tree.

 I moved these two files into drivers/net so they are available for
 PPC as well as ARM and added some Redwood-specific support.  That
 was straightforward.  This driver calls a couple of ARM-specific
 functions platform_get_resource() and platform_get_irq().  ARM
 implements these functions in arch/arm/common/platform.c.  I
 copied arch/arm/common/platform.c into arch/ppc/syslib/platform.c
 which works fine, but I don't care for duplicated code.  Maybe a
 better approach would be to add these functions to drivers/base/platform.c

How about wrapping each arch-specific call up in something more abstract
and then using OCP to get the PPC info?

roughly...

#ifdef CONFIG_PPC_OCP
TO_SMC_DEV  to_ocp_device()
SMC_GET_BASE_ADDR   dev-def-paddr
...
#else /* ARM */
TO_SMC_DEV  to_platform_device()
SMC_GET_BASE_ADDR   platform_get_resource(dev, IORESOURCE_MEM, 1)
...
#endif

There's only about 4 places in the probe/remove calls to do this.
Add an ocp_add_one_device in your redwood*.c to enable the smc9111
device with the board-specific attributes.

You may have to play a bit with the prove/remove calls since they
want to deal with a resource struct, but it might be worth looking
at.

 Comments?  Suggestions on how to go about getting this into linux-2.5?

Send a two part patch, 1/2 (file moves) 2/2 PPC changes to Nicolas
and cc jgarzik

-Matt

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/





2.6 networking support for Redwood[56]

2004-06-21 Thread Dale Farnsworth

On Mon, Jun 21, 2004 at 11:12:14PM +, Matt Porter wrote:
 On Mon, Jun 21, 2004 at 02:39:48PM -0700, Dale Farnsworth wrote:
 
  I'm adding network support for the IBM Redwood5 and Redwood6 in 2.6.
 
  It looks like the best supported driver for the smc9 chip
  is used by the ARM folks and is found in drivers/net/arm/smc91x.[ch]
  This driver recently went into the linux-2.5 tree.
 
  I moved these two files into drivers/net so they are available for
  PPC as well as ARM and added some Redwood-specific support.  That
  was straightforward.  This driver calls a couple of ARM-specific
  functions platform_get_resource() and platform_get_irq().  ARM
  implements these functions in arch/arm/common/platform.c.  I
  copied arch/arm/common/platform.c into arch/ppc/syslib/platform.c
  which works fine, but I don't care for duplicated code.  Maybe a
  better approach would be to add these functions to drivers/base/platform.c

 How about wrapping each arch-specific call up in something more abstract
 and then using OCP to get the PPC info?

 roughly...

 #ifdef CONFIG_PPC_OCP
 TO_SMC_DEVto_ocp_device()
 SMC_GET_BASE_ADDR dev-def-paddr
 ...
 #else /* ARM */
 TO_SMC_DEVto_platform_device()
 SMC_GET_BASE_ADDR platform_get_resource(dev, IORESOURCE_MEM, 1)
 ...
 #endif

 There's only about 4 places in the probe/remove calls to do this.
 Add an ocp_add_one_device in your redwood*.c to enable the smc9111
 device with the board-specific attributes.

 You may have to play a bit with the prove/remove calls since they
 want to deal with a resource struct, but it might be worth looking
 at.

Sounds like a better approach.  I'll modify the driver to present
either the ARM interface or the PPC_OCP interface.  Muddles the
driver a bit, but should keep both archs happy.

  Comments?  Suggestions on how to go about getting this into linux-2.5?

 Send a two part patch, 1/2 (file moves) 2/2 PPC changes to Nicolas
 and cc jgarzik

Yes without architectural changes, should be easier to get in.

Thanks,
-Dale

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/