smc91x support

smc91x support

[Matej Kupljen]

Hi

On 21st september Peter Popov modified:
arch/mips/au1000/common/platform.c

With the log message:
smc91x platform support; requires patch to smc91x.h which was sent
        upstream.

Any news about this?
What is the patch required for smc91x.h?

I also added support for smc91x.h to enable it on the DBAU1200,
but as I wrote in another mail, I get bad performance.
I enabled the debug mode and I now I see that I get a lot of 
overruns, like:
...
[4294761.172000] eth0: RX overrun (EPH_ST 0x0001)
[4294761.190000] eth0: RX overrun (EPH_ST 0x0001)
[4294761.198000] eth0: RX overrun (EPH_ST 0x0001)
...

Is there any solution to this?
Maybe to use DDMA?

BR,
Matej

Re: smc91x support

[Atsushi Nemoto]

>>>>> On Thu, 10 Nov 2005 15:52:11 +0100, Matej Kupljen <matej.kupljen@ultra.si> said:

matej> What is the patch required for smc91x.h?

I also want to know about the patch.

matej> I also added support for smc91x.h to enable it on the DBAU1200,
matej> but as I wrote in another mail, I get bad performance.  I
matej> enabled the debug mode and I now I see that I get a lot of
matej> overruns, like:
matej> ...
matej> [4294761.172000] eth0: RX overrun (EPH_ST 0x0001)
matej> [4294761.190000] eth0: RX overrun (EPH_ST 0x0001)
matej> [4294761.198000] eth0: RX overrun (EPH_ST 0x0001)
matej> ...

matej> Is there any solution to this?

I have similar problem on my several custom boards with SMC91C111.  I
see so many RX overrun, but I can not see why it happens.  Forcing to
10Mbps/HalfDuplex reduced the overrun count (and works better than
100Mbps), but it is not preferable, of course ...

---
Atsushi Nemoto

Re: smc91x support

[Pantelis Antoniou]

On Thursday 10 November 2005 17:15, Atsushi Nemoto wrote:
> >>>>> On Thu, 10 Nov 2005 15:52:11 +0100, Matej Kupljen <matej.kupljen@ultra.si> said:
> 
> matej> What is the patch required for smc91x.h?
> 
> I also want to know about the patch.
> 
> matej> I also added support for smc91x.h to enable it on the DBAU1200,
> matej> but as I wrote in another mail, I get bad performance.  I
> matej> enabled the debug mode and I now I see that I get a lot of
> matej> overruns, like:
> matej> ...
> matej> [4294761.172000] eth0: RX overrun (EPH_ST 0x0001)
> matej> [4294761.190000] eth0: RX overrun (EPH_ST 0x0001)
> matej> [4294761.198000] eth0: RX overrun (EPH_ST 0x0001)
> matej> ...
> 
> matej> Is there any solution to this?
> 
> I have similar problem on my several custom boards with SMC91C111.  I
> see so many RX overrun, but I can not see why it happens.  Forcing to
> 10Mbps/HalfDuplex reduced the overrun count (and works better than
> 100Mbps), but it is not preferable, of course ...
> 
> ---

I'm afraid there's not much that you can do...

The old driver just didn't report the overruns. The generic one 
does, that's why you see the overrun error.

And yes performance is bad with this chip. I'm not sure if DMA would
help much, since the overrun occurs because the chip does not have
enough internal buffers. I don't think that we can service the interrupts
fast enough to prevent the overruns...

IMHO the only solution is to use a decent chip...

> Atsushi Nemoto
> 
> 

Regards

Pantelis

Re: smc91x support

[Matej Kupljen]

Hi

> > matej> Is there any solution to this?
> > 
> > I have similar problem on my several custom boards with SMC91C111.  I
> > see so many RX overrun, but I can not see why it happens.  Forcing to
> > 10Mbps/HalfDuplex reduced the overrun count (and works better than
> > 100Mbps), but it is not preferable, of course ...

How did you achieve this? By software or by using 10 Mbps switch?

> And yes performance is bad with this chip. 

Probably I'll try and switch it to 10 Mbps, because NFS is terrible
because it gets a lot of timeouts because of dropped packets.

> I'm not sure if DMA would
> help much, since the overrun occurs because the chip does not have
> enough internal buffers. I don't think that we can service the interrupts
> fast enough to prevent the overruns...

I found this mail from Nicolas on ARM mailing list:
http://lists.arm.linux.org.uk/pipermail/linux-arm-kernel/2005-October/031736.html

Maybe we could try DMA and see what happens.
Any hints how to try this, because I haven't worked with DDMA before?

BR,
Matej

Re: smc91x support

[Atsushi Nemoto]

>>>>> On Thu, 10 Nov 2005 18:44:30 +0100, Matej Kupljen <matej.kupljen@ultra.si> said:
matej> How did you achieve this? By software or by using 10 Mbps
matej> switch?

I did by just change default settings like this:

	/* Set default parameters */
	lp->msg_enable = NETIF_MSG_LINK;
	lp->ctl_rfduplx = 0;
	lp->ctl_rspeed = 10;

#if 0	/* too many rx overruns on 100M... why? (less overruns on 10M) */
	if (lp->version >= (CHIP_91100 << 4)) {
		lp->ctl_rfduplx = 1;
		lp->ctl_rspeed = 100;
	}
#endif

matej> I found this mail from Nicolas on ARM mailing list:
matej> http://lists.arm.linux.org.uk/pipermail/linux-arm-kernel/2005-October/031736.html

Hmm... Thanks.

---
Atsushi Nemoto

Re: smc91x support

[Pete Popov]

[-- Attachment #1: Type: text/plain, Size: 1182 bytes --]

On Thu, 2005-11-10 at 15:52 +0100, Matej Kupljen wrote:
> Hi
> 
> On 21st september Peter Popov modified:
> arch/mips/au1000/common/platform.c
> 
> With the log message:
> smc91x platform support; requires patch to smc91x.h which was sent
>         upstream.
> 
> Any news about this?
> What is the patch required for smc91x.h?

I have to check with Nicolas Pitre.

Meanwhile I've attached the patch here.

> I also added support for smc91x.h to enable it on the DBAU1200,
> but as I wrote in another mail, I get bad performance.

So do I. That part is just a low performance part plus the bus settings
on the db1200 are set for the slowest part on the local bus. Depending
on which peripherals you use on the local bus, you may be able to change
the settings and get better performance from the Ethernet. Jordan may
have more hints about this.

Pete

> I enabled the debug mode and I now I see that I get a lot of 
> overruns, like:
> ...
> [4294761.172000] eth0: RX overrun (EPH_ST 0x0001)
> [4294761.190000] eth0: RX overrun (EPH_ST 0x0001)
> [4294761.198000] eth0: RX overrun (EPH_ST 0x0001)
> ...
> 
> Is there any solution to this?
> Maybe to use DDMA?
> 
> BR,
> Matej
> 
> 

[-- Attachment #2: smc91x_au1x.patch --]
[-- Type: text/x-patch, Size: 1897 bytes --]

diff -Naur --exclude=CVS linux-2.6-orig/drivers/net/Kconfig linux-2.6-dev/drivers/net/Kconfig
--- linux-2.6-orig/drivers/net/Kconfig	2005-09-15 08:45:33.000000000 -0700
+++ linux-2.6-dev/drivers/net/Kconfig	2005-09-21 11:40:13.000000000 -0700
@@ -800,7 +800,7 @@
 	tristate "SMC 91C9x/91C1xxx support"
 	select CRC32
 	select MII
-	depends on NET_ETHERNET && (ARM || REDWOOD_5 || REDWOOD_6 || M32R || SUPERH)
+	depends on NET_ETHERNET && (ARM || REDWOOD_5 || REDWOOD_6 || M32R || SUPERH || SOC_AU1X00)
 	help
 	  This is a driver for SMC's 91x series of Ethernet chipsets,
 	  including the SMC91C94 and the SMC91C111. Say Y if you want it
diff -Naur --exclude=CVS linux-2.6-orig/drivers/net/smc91x.h linux-2.6-dev/drivers/net/smc91x.h
--- linux-2.6-orig/drivers/net/smc91x.h	2005-09-15 08:45:41.000000000 -0700
+++ linux-2.6-dev/drivers/net/smc91x.h	2005-09-21 11:42:49.000000000 -0700
@@ -289,6 +289,38 @@
 #define RPC_LSA_DEFAULT		RPC_LED_TX_RX
 #define RPC_LSB_DEFAULT		RPC_LED_100_10
 
+#elif defined(CONFIG_SOC_AU1X00)
+
+#include <au1xxx.h>
+
+/* 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_IO_SHIFT		0
+#define SMC_NOWAIT		1
+
+#define SMC_inw(a, r)		au_readw((unsigned long)((a) + (r)))
+#define SMC_insw(a, r, p, l)	\
+	do {	\
+		unsigned long _a = (unsigned long)((a) + (r)); \
+		int _l = (l); \
+		u16 *_p = (u16 *)(p); \
+		while (_l-- > 0) \
+			*_p++ = au_readw(_a); \
+	} while(0)
+#define SMC_outw(v, a, r)	au_writew(v, (unsigned long)((a) + (r)))
+#define SMC_outsw(a, r, p, l)	\
+	do {	\
+		unsigned long _a = (unsigned long)((a) + (r)); \
+		int _l = (l); \
+		const u16 *_p = (const u16 *)(p); \
+		while (_l-- > 0) \
+			au_writew(*_p++ , _a); \
+	} while(0)
+
+#define set_irq_type(irq, type) do {} while (0)
+
 #else
 
 #define SMC_CAN_USE_8BIT	1

Re: smc91x support

[Matej Kupljen]

Hi

> Meanwhile I've attached the patch here.

Thank you.
I'll check it with mine and let you know, what I did.

Just one think:
-       depends on NET_ETHERNET && (ARM || REDWOOD_5 || REDWOOD_6 ||
M32R || SUPERH)
+       depends on NET_ETHERNET && (ARM || REDWOOD_5 || REDWOOD_6 ||
M32R || SUPERH || SOC_AU1X00)

Wouldn't it be better to use SOC_AU1200 instead of SOC_AU1X00, because
only AU1200 does not have integrated Ethernet controller?

BR,
Matej

Re: smc91x support

[Peter Popov]

> Wouldn't it be better to use SOC_AU1200 instead of
> SOC_AU1X00, because
> only AU1200 does not have integrated Ethernet
> controller?

Perhaps. But the Au1x could use it ... depending on
the HW design. Right now only the Db1200 has this
chip.

Pete

Re: smc91x support

[Matej Kupljen]

Hi 

> > smc91x platform support; requires patch to smc91x.h which was sent
> >         upstream.
> > 
> > Any news about this?
> > What is the patch required for smc91x.h?
> 
> I have to check with Nicolas Pitre.

Pete, did you see this:
http://lists.arm.linux.org.uk/pipermail/linux-arm-kernel/2006-January/033064.html

Will it work for MIPS and especially for DBAU12100?

BR,
Matej

Re: smc91x support

[Pete Popov]

On Wed, 2006-01-04 at 22:23 +0100, Matej Kupljen wrote:
> Hi 
> 
> > > smc91x platform support; requires patch to smc91x.h which was sent
> > >         upstream.
> > > 
> > > Any news about this?
> > > What is the patch required for smc91x.h?
> > 
> > I have to check with Nicolas Pitre.
> 
> Pete, did you see this:
> http://lists.arm.linux.org.uk/pipermail/linux-arm-kernel/2006-January/033064.html
> 
> Will it work for MIPS and especially for DBAU12100?

Someone has to try it and send Nicolas an incremental patch if it
doesn't work for the dbau1200.  I have a dbau1200 so I'll try it at some
point but Jordan might beat me to it.

Pete