2.6 networking support for Redwood[56]
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]
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_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. > > 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. -Dale Farnsworth ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
2.6 networking support for Redwood[56]
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/
2.6 networking support for Redwood[56]
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]
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
#include
#include
+#include
+#include
#include
#include
+#include
+
+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 2004-06-21 13:52:45 -07:00
@@ -34,6 +34,7 @@
#define SMC9_BASE_ADDR 0xf2000300
+#define SMC9111
