Subject: nell driver working now
To: None <port-sparc@NetBSD.ORG>
From: Martin Husemann <martin@duskware.de>
List: port-sparc
Date: 03/10/2002 18:40:53
--x+6KMIRAuhnl3hBn
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline

Since several people here expressed interest in the nell @ sbus pcmcia bridge,
I thought I'd let you know I consider it more or less done now. There are
one minor and one major issue with it left (the minor one pending review
from Paul, the major one see below) - but it works enough so that I moved
my production wavelan gateway (using Orinoco wi0 cards) to my LX now:

nell0 at sbus0 slot 0 offset 0x0 level 4 (ipl 7) level 7 (ipl 13): rev 1
pcmcia0 at nell0 socket 0
pcmcia1 at nell0 socket 1
wi0 at pcmcia1 function 0: Lucent Technologies, WaveLAN/IEEE, Version 01.01
wi0: 802.11 address 00:02:2d:21:10:7b
wi0: using Lucent chip or unknown chip

The majore issue is: I didn't find any knob to make it swap the byteorder
in hardware. This means we now see a big endian pcmcia bus - which is not
what NetBSD drivers expect.

For some cards this does not matter. The ray0 for example is a pure 8 bit
card, it works out of the box (after I fixed the ray driver in the course
of debugging nell). I tried a modem card and that worked out of the box too.

Any 16bit cards will not work. I hacked the wi driver (which is the only one
that I myself need for now) to cope, see the attached patch.

This should be fixed, in theory, by making the sparc port abide to the laws
of bus space. But I'm not the one going to do the commit that will be known
to have broken the performance of all the sparc's out there!

What we could do is:

 1) Find a magic toggle to make nell swap byte order on pcmcia card
    access. This would be the prefered way (this is how Krups handles
    the PCI bus)

 2) Make the bus_space_{read,write}_* macros use the bus_space_tag_t,
    maybe special casing t = NULL for native access.

 3) Declare some busses as bi-endian and provide a machine dependend
    macro that drivers can use to do the right thing. This would get us
    optimal performance, paid by code duplication.

IMHO (2) is the right thing to do. I doubt there is something to do (1).
Going for (3) would need another discussion elsewhere.

Martin

--x+6KMIRAuhnl3hBn
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment; filename="wi-sparc-fix.patch"

Index: wireg.h
===================================================================
RCS file: /cvsroot/syssrc/sys/dev/ic/wireg.h,v
retrieving revision 1.19
diff -c -u -r1.19 wireg.h
--- wireg.h	2002/03/10 00:16:47	1.19
+++ wireg.h	2002/03/10 16:36:21
@@ -95,6 +95,30 @@
 /*
  * register space access macros
  */
+#ifdef __sparc__
+
+#define CSR_WRITE_4(sc, reg, val)	\
+	bus_space_write_4(sc->sc_iot, sc->sc_ioh,	\
+			(sc->sc_pci? reg * 2: reg) , htole32(val))
+#define CSR_WRITE_2(sc, reg, val)	\
+	bus_space_write_2(sc->sc_iot, sc->sc_ioh,	\
+			(sc->sc_pci? reg * 2: reg), htole16(val))
+#define CSR_WRITE_1(sc, reg, val)	\
+	bus_space_write_1(sc->sc_iot, sc->sc_ioh,	\
+			(sc->sc_pci? reg * 2: reg), val)
+
+#define CSR_READ_4(sc, reg)		\
+	le32toh(bus_space_read_4(sc->sc_iot, sc->sc_ioh,	\
+			(sc->sc_pci? reg * 2: reg)))
+#define CSR_READ_2(sc, reg)		\
+	le16toh(bus_space_read_2(sc->sc_iot, sc->sc_ioh,	\
+			(sc->sc_pci? reg * 2: reg)))
+#define CSR_READ_1(sc, reg)		\
+	bus_space_read_1(sc->sc_iot, sc->sc_ioh,	\
+			(sc->sc_pci? reg * 2: reg))
+
+#else
+
 #define CSR_WRITE_4(sc, reg, val)	\
 	bus_space_write_4(sc->sc_iot, sc->sc_ioh,	\
 			(sc->sc_pci? reg * 2: reg) , val)
@@ -114,6 +138,7 @@
 #define CSR_READ_1(sc, reg)		\
 	bus_space_read_1(sc->sc_iot, sc->sc_ioh,	\
 			(sc->sc_pci? reg * 2: reg))
+#endif
 
 #ifndef __BUS_SPACE_HAS_STREAM_METHODS
 #define bus_space_write_stream_2	bus_space_write_2

--x+6KMIRAuhnl3hBn--