2000-12-06 00:52:28 +00:00
|
|
|
/* $FreeBSD$ */
|
Add first pass of the Intel Gigabit Ethernet (wiseman) driver. This
driver seems relatively functional, but could use some souping up,
particularly in the performance area. This has both NetBSD and FreeBSD
attachment code and a fair amount of effort has been put into making
it easy to port to different *BSD platforms.
The basic design is a one tfd per mbuf transmit (with no transmit
related interrupts- tfds are gc'd as needed). The receive ring
uses a 2K buffer per rfd with a +2 byte adjust for the ethernet
header (so the payload is aligned). There's support that *almost*
works for doing large packets- the rfd chaining code works, but there's
some problem with getting good checksums at the IP reassembly level
(ditto for doing short tfd's too).
The chip has support for TCP checksums insertion for transmit and
TCP checksum calculation on receive (for both you have to do some
appropriate backoff && twiddling), but this isn't in place.
This is nearly entirely reverse engineered from the released Intel
driver, so there's a lot of "We have to do this but do not know why"
stuff. There is somebody who has the chip specs who works in FreeBSD
but they're being a bit standoffish about even sharing hints which
is somewhat annoying. It's also apparent that all I had to work with
were the first rev boards.
This driver has been lightly tested on intel && alpha, but only
point-to-point. There may be some issues with switches- use of
boot time environment variables that override EEPROM settings
(e.g., 'set wx_ilos=1' which inverts the sense of optical signal
loss) may help with this.
I had this out for review for three weeks, and nobody said anything
negative or positive, ergo, this checkin has no 'reviewed by' field
which I would have preferred.
2000-01-04 11:12:42 +00:00
|
|
|
/*
|
2001-04-09 21:48:50 +00:00
|
|
|
* Principal Author: Matthew Jacob
|
|
|
|
|
* Copyright (c) 1999, 2001 by Traakan Software
|
Add first pass of the Intel Gigabit Ethernet (wiseman) driver. This
driver seems relatively functional, but could use some souping up,
particularly in the performance area. This has both NetBSD and FreeBSD
attachment code and a fair amount of effort has been put into making
it easy to port to different *BSD platforms.
The basic design is a one tfd per mbuf transmit (with no transmit
related interrupts- tfds are gc'd as needed). The receive ring
uses a 2K buffer per rfd with a +2 byte adjust for the ethernet
header (so the payload is aligned). There's support that *almost*
works for doing large packets- the rfd chaining code works, but there's
some problem with getting good checksums at the IP reassembly level
(ditto for doing short tfd's too).
The chip has support for TCP checksums insertion for transmit and
TCP checksum calculation on receive (for both you have to do some
appropriate backoff && twiddling), but this isn't in place.
This is nearly entirely reverse engineered from the released Intel
driver, so there's a lot of "We have to do this but do not know why"
stuff. There is somebody who has the chip specs who works in FreeBSD
but they're being a bit standoffish about even sharing hints which
is somewhat annoying. It's also apparent that all I had to work with
were the first rev boards.
This driver has been lightly tested on intel && alpha, but only
point-to-point. There may be some issues with switches- use of
boot time environment variables that override EEPROM settings
(e.g., 'set wx_ilos=1' which inverts the sense of optical signal
loss) may help with this.
I had this out for review for three weeks, and nobody said anything
negative or positive, ergo, this checkin has no 'reviewed by' field
which I would have preferred.
2000-01-04 11:12:42 +00:00
|
|
|
* All rights reserved.
|
|
|
|
|
*
|
|
|
|
|
* Redistribution and use in source and binary forms, with or without
|
|
|
|
|
* modification, are permitted provided that the following conditions
|
|
|
|
|
* are met:
|
|
|
|
|
* 1. Redistributions of source code must retain the above copyright
|
|
|
|
|
* notice unmodified, this list of conditions, and the following
|
|
|
|
|
* disclaimer.
|
|
|
|
|
* 2. Redistributions in binary form must reproduce the above copyright
|
|
|
|
|
* notice, this list of conditions and the following disclaimer in the
|
|
|
|
|
* documentation and/or other materials provided with the distribution.
|
|
|
|
|
*
|
|
|
|
|
* THIS SOFTWARE IS PROVIDED BY THE AUTHOR AND CONTRIBUTORS ``AS IS'' AND
|
|
|
|
|
* ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
|
|
|
|
|
* IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
|
|
|
|
|
* ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIABLE
|
|
|
|
|
* FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
|
|
|
|
|
* DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
|
|
|
|
|
* OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
|
|
|
|
|
* HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
|
|
|
|
|
* LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
|
|
|
|
|
* OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
|
|
|
|
|
* SUCH DAMAGE.
|
|
|
|
|
*
|
2001-04-09 21:48:50 +00:00
|
|
|
* Additional Copyright (c) 2001 by Parag Patel
|
|
|
|
|
* under same licence for MII PHY code.
|
Add first pass of the Intel Gigabit Ethernet (wiseman) driver. This
driver seems relatively functional, but could use some souping up,
particularly in the performance area. This has both NetBSD and FreeBSD
attachment code and a fair amount of effort has been put into making
it easy to port to different *BSD platforms.
The basic design is a one tfd per mbuf transmit (with no transmit
related interrupts- tfds are gc'd as needed). The receive ring
uses a 2K buffer per rfd with a +2 byte adjust for the ethernet
header (so the payload is aligned). There's support that *almost*
works for doing large packets- the rfd chaining code works, but there's
some problem with getting good checksums at the IP reassembly level
(ditto for doing short tfd's too).
The chip has support for TCP checksums insertion for transmit and
TCP checksum calculation on receive (for both you have to do some
appropriate backoff && twiddling), but this isn't in place.
This is nearly entirely reverse engineered from the released Intel
driver, so there's a lot of "We have to do this but do not know why"
stuff. There is somebody who has the chip specs who works in FreeBSD
but they're being a bit standoffish about even sharing hints which
is somewhat annoying. It's also apparent that all I had to work with
were the first rev boards.
This driver has been lightly tested on intel && alpha, but only
point-to-point. There may be some issues with switches- use of
boot time environment variables that override EEPROM settings
(e.g., 'set wx_ilos=1' which inverts the sense of optical signal
loss) may help with this.
I had this out for review for three weeks, and nobody said anything
negative or positive, ergo, this checkin has no 'reviewed by' field
which I would have preferred.
2000-01-04 11:12:42 +00:00
|
|
|
*/
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* Softc definitions for the Intel Gigabit Ethernet driver.
|
|
|
|
|
*
|
|
|
|
|
* Guidance and inspiration from David Greenman's
|
|
|
|
|
* if_fxp driver gratefully acknowledged here.
|
|
|
|
|
*/
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* Platform specific defines and inline functions go here.
|
|
|
|
|
* Look further below for more generic structures.
|
|
|
|
|
*/
|
|
|
|
|
|
2000-12-06 00:52:28 +00:00
|
|
|
/*
|
|
|
|
|
* Enable for FreeBSD 5.0 SMP code
|
|
|
|
|
*/
|
2001-10-02 00:13:44 +00:00
|
|
|
#define SMPNG 1
|
2000-12-06 00:52:28 +00:00
|
|
|
|
Add first pass of the Intel Gigabit Ethernet (wiseman) driver. This
driver seems relatively functional, but could use some souping up,
particularly in the performance area. This has both NetBSD and FreeBSD
attachment code and a fair amount of effort has been put into making
it easy to port to different *BSD platforms.
The basic design is a one tfd per mbuf transmit (with no transmit
related interrupts- tfds are gc'd as needed). The receive ring
uses a 2K buffer per rfd with a +2 byte adjust for the ethernet
header (so the payload is aligned). There's support that *almost*
works for doing large packets- the rfd chaining code works, but there's
some problem with getting good checksums at the IP reassembly level
(ditto for doing short tfd's too).
The chip has support for TCP checksums insertion for transmit and
TCP checksum calculation on receive (for both you have to do some
appropriate backoff && twiddling), but this isn't in place.
This is nearly entirely reverse engineered from the released Intel
driver, so there's a lot of "We have to do this but do not know why"
stuff. There is somebody who has the chip specs who works in FreeBSD
but they're being a bit standoffish about even sharing hints which
is somewhat annoying. It's also apparent that all I had to work with
were the first rev boards.
This driver has been lightly tested on intel && alpha, but only
point-to-point. There may be some issues with switches- use of
boot time environment variables that override EEPROM settings
(e.g., 'set wx_ilos=1' which inverts the sense of optical signal
loss) may help with this.
I had this out for review for three weeks, and nobody said anything
negative or positive, ergo, this checkin has no 'reviewed by' field
which I would have preferred.
2000-01-04 11:12:42 +00:00
|
|
|
#include <sys/param.h>
|
|
|
|
|
#include <sys/systm.h>
|
|
|
|
|
#include <sys/mbuf.h>
|
|
|
|
|
#include <sys/protosw.h>
|
|
|
|
|
#include <sys/socket.h>
|
|
|
|
|
#include <sys/malloc.h>
|
|
|
|
|
#include <sys/kernel.h>
|
|
|
|
|
#include <net/if.h>
|
|
|
|
|
#include <net/if_dl.h>
|
|
|
|
|
#include <net/if_media.h>
|
|
|
|
|
#ifdef NS
|
|
|
|
|
#include <netns/ns.h>
|
|
|
|
|
#include <netns/ns_if.h>
|
|
|
|
|
#endif
|
|
|
|
|
#include <net/bpf.h>
|
|
|
|
|
#include <sys/sockio.h>
|
|
|
|
|
#include <sys/bus.h>
|
|
|
|
|
#include <machine/bus.h>
|
|
|
|
|
#include <sys/rman.h>
|
|
|
|
|
#include <machine/resource.h>
|
|
|
|
|
#include <net/ethernet.h>
|
|
|
|
|
#include <net/if_arp.h>
|
|
|
|
|
#include <vm/vm.h>
|
|
|
|
|
#include <vm/pmap.h>
|
|
|
|
|
#include <machine/clock.h>
|
|
|
|
|
#include <pci/pcivar.h>
|
|
|
|
|
#include <pci/pcireg.h>
|
|
|
|
|
#include <pci/if_wxreg.h>
|
2001-04-09 21:48:50 +00:00
|
|
|
#include <dev/mii/mii.h>
|
|
|
|
|
#include <dev/mii/miivar.h>
|
|
|
|
|
|
|
|
|
|
#define NBPFILTER 1
|
|
|
|
|
|
2001-10-02 00:13:44 +00:00
|
|
|
MODULE_DEPEND(wx, miibus, 1, 1, 1);
|
2001-04-09 21:48:50 +00:00
|
|
|
#include "miibus_if.h"
|
Add first pass of the Intel Gigabit Ethernet (wiseman) driver. This
driver seems relatively functional, but could use some souping up,
particularly in the performance area. This has both NetBSD and FreeBSD
attachment code and a fair amount of effort has been put into making
it easy to port to different *BSD platforms.
The basic design is a one tfd per mbuf transmit (with no transmit
related interrupts- tfds are gc'd as needed). The receive ring
uses a 2K buffer per rfd with a +2 byte adjust for the ethernet
header (so the payload is aligned). There's support that *almost*
works for doing large packets- the rfd chaining code works, but there's
some problem with getting good checksums at the IP reassembly level
(ditto for doing short tfd's too).
The chip has support for TCP checksums insertion for transmit and
TCP checksum calculation on receive (for both you have to do some
appropriate backoff && twiddling), but this isn't in place.
This is nearly entirely reverse engineered from the released Intel
driver, so there's a lot of "We have to do this but do not know why"
stuff. There is somebody who has the chip specs who works in FreeBSD
but they're being a bit standoffish about even sharing hints which
is somewhat annoying. It's also apparent that all I had to work with
were the first rev boards.
This driver has been lightly tested on intel && alpha, but only
point-to-point. There may be some issues with switches- use of
boot time environment variables that override EEPROM settings
(e.g., 'set wx_ilos=1' which inverts the sense of optical signal
loss) may help with this.
I had this out for review for three weeks, and nobody said anything
negative or positive, ergo, this checkin has no 'reviewed by' field
which I would have preferred.
2000-01-04 11:12:42 +00:00
|
|
|
|
|
|
|
|
#include "opt_bdg.h"
|
|
|
|
|
#ifdef BRIDGE
|
|
|
|
|
#include <net/if_types.h>
|
|
|
|
|
#include <net/bridge.h>
|
|
|
|
|
#endif
|
|
|
|
|
|
|
|
|
|
struct wxmdvar {
|
2001-10-02 00:13:44 +00:00
|
|
|
/*
|
|
|
|
|
* arpcom must be first
|
|
|
|
|
*/
|
Add first pass of the Intel Gigabit Ethernet (wiseman) driver. This
driver seems relatively functional, but could use some souping up,
particularly in the performance area. This has both NetBSD and FreeBSD
attachment code and a fair amount of effort has been put into making
it easy to port to different *BSD platforms.
The basic design is a one tfd per mbuf transmit (with no transmit
related interrupts- tfds are gc'd as needed). The receive ring
uses a 2K buffer per rfd with a +2 byte adjust for the ethernet
header (so the payload is aligned). There's support that *almost*
works for doing large packets- the rfd chaining code works, but there's
some problem with getting good checksums at the IP reassembly level
(ditto for doing short tfd's too).
The chip has support for TCP checksums insertion for transmit and
TCP checksum calculation on receive (for both you have to do some
appropriate backoff && twiddling), but this isn't in place.
This is nearly entirely reverse engineered from the released Intel
driver, so there's a lot of "We have to do this but do not know why"
stuff. There is somebody who has the chip specs who works in FreeBSD
but they're being a bit standoffish about even sharing hints which
is somewhat annoying. It's also apparent that all I had to work with
were the first rev boards.
This driver has been lightly tested on intel && alpha, but only
point-to-point. There may be some issues with switches- use of
boot time environment variables that override EEPROM settings
(e.g., 'set wx_ilos=1' which inverts the sense of optical signal
loss) may help with this.
I had this out for review for three weeks, and nobody said anything
negative or positive, ergo, this checkin has no 'reviewed by' field
which I would have preferred.
2000-01-04 11:12:42 +00:00
|
|
|
struct arpcom arpcom; /* per-interface network data */
|
2001-10-02 00:13:44 +00:00
|
|
|
struct device * dev; /* backpointer to device */
|
Add first pass of the Intel Gigabit Ethernet (wiseman) driver. This
driver seems relatively functional, but could use some souping up,
particularly in the performance area. This has both NetBSD and FreeBSD
attachment code and a fair amount of effort has been put into making
it easy to port to different *BSD platforms.
The basic design is a one tfd per mbuf transmit (with no transmit
related interrupts- tfds are gc'd as needed). The receive ring
uses a 2K buffer per rfd with a +2 byte adjust for the ethernet
header (so the payload is aligned). There's support that *almost*
works for doing large packets- the rfd chaining code works, but there's
some problem with getting good checksums at the IP reassembly level
(ditto for doing short tfd's too).
The chip has support for TCP checksums insertion for transmit and
TCP checksum calculation on receive (for both you have to do some
appropriate backoff && twiddling), but this isn't in place.
This is nearly entirely reverse engineered from the released Intel
driver, so there's a lot of "We have to do this but do not know why"
stuff. There is somebody who has the chip specs who works in FreeBSD
but they're being a bit standoffish about even sharing hints which
is somewhat annoying. It's also apparent that all I had to work with
were the first rev boards.
This driver has been lightly tested on intel && alpha, but only
point-to-point. There may be some issues with switches- use of
boot time environment variables that override EEPROM settings
(e.g., 'set wx_ilos=1' which inverts the sense of optical signal
loss) may help with this.
I had this out for review for three weeks, and nobody said anything
negative or positive, ergo, this checkin has no 'reviewed by' field
which I would have preferred.
2000-01-04 11:12:42 +00:00
|
|
|
struct resource * mem; /* resource descriptor for registers */
|
|
|
|
|
struct resource * irq; /* resource descriptor for interrupt */
|
|
|
|
|
void * ih; /* interrupt handler cookie */
|
|
|
|
|
u_int16_t cmdw;
|
|
|
|
|
struct callout_handle sch; /* handle for timeouts */
|
|
|
|
|
char name[8];
|
|
|
|
|
bus_space_tag_t st; /* bus space tag */
|
|
|
|
|
bus_space_handle_t sh; /* bus space handle */
|
|
|
|
|
struct ifmedia ifm;
|
2001-04-09 21:48:50 +00:00
|
|
|
device_t miibus;
|
Add first pass of the Intel Gigabit Ethernet (wiseman) driver. This
driver seems relatively functional, but could use some souping up,
particularly in the performance area. This has both NetBSD and FreeBSD
attachment code and a fair amount of effort has been put into making
it easy to port to different *BSD platforms.
The basic design is a one tfd per mbuf transmit (with no transmit
related interrupts- tfds are gc'd as needed). The receive ring
uses a 2K buffer per rfd with a +2 byte adjust for the ethernet
header (so the payload is aligned). There's support that *almost*
works for doing large packets- the rfd chaining code works, but there's
some problem with getting good checksums at the IP reassembly level
(ditto for doing short tfd's too).
The chip has support for TCP checksums insertion for transmit and
TCP checksum calculation on receive (for both you have to do some
appropriate backoff && twiddling), but this isn't in place.
This is nearly entirely reverse engineered from the released Intel
driver, so there's a lot of "We have to do this but do not know why"
stuff. There is somebody who has the chip specs who works in FreeBSD
but they're being a bit standoffish about even sharing hints which
is somewhat annoying. It's also apparent that all I had to work with
were the first rev boards.
This driver has been lightly tested on intel && alpha, but only
point-to-point. There may be some issues with switches- use of
boot time environment variables that override EEPROM settings
(e.g., 'set wx_ilos=1' which inverts the sense of optical signal
loss) may help with this.
I had this out for review for three weeks, and nobody said anything
negative or positive, ergo, this checkin has no 'reviewed by' field
which I would have preferred.
2000-01-04 11:12:42 +00:00
|
|
|
struct wx_softc * next;
|
2000-12-06 00:52:28 +00:00
|
|
|
#ifdef SMPNG
|
|
|
|
|
struct mtx wxmtx;
|
|
|
|
|
#else
|
|
|
|
|
int spl;
|
|
|
|
|
#endif
|
Add first pass of the Intel Gigabit Ethernet (wiseman) driver. This
driver seems relatively functional, but could use some souping up,
particularly in the performance area. This has both NetBSD and FreeBSD
attachment code and a fair amount of effort has been put into making
it easy to port to different *BSD platforms.
The basic design is a one tfd per mbuf transmit (with no transmit
related interrupts- tfds are gc'd as needed). The receive ring
uses a 2K buffer per rfd with a +2 byte adjust for the ethernet
header (so the payload is aligned). There's support that *almost*
works for doing large packets- the rfd chaining code works, but there's
some problem with getting good checksums at the IP reassembly level
(ditto for doing short tfd's too).
The chip has support for TCP checksums insertion for transmit and
TCP checksum calculation on receive (for both you have to do some
appropriate backoff && twiddling), but this isn't in place.
This is nearly entirely reverse engineered from the released Intel
driver, so there's a lot of "We have to do this but do not know why"
stuff. There is somebody who has the chip specs who works in FreeBSD
but they're being a bit standoffish about even sharing hints which
is somewhat annoying. It's also apparent that all I had to work with
were the first rev boards.
This driver has been lightly tested on intel && alpha, but only
point-to-point. There may be some issues with switches- use of
boot time environment variables that override EEPROM settings
(e.g., 'set wx_ilos=1' which inverts the sense of optical signal
loss) may help with this.
I had this out for review for three weeks, and nobody said anything
negative or positive, ergo, this checkin has no 'reviewed by' field
which I would have preferred.
2000-01-04 11:12:42 +00:00
|
|
|
};
|
|
|
|
|
#define wx_dev w.dev
|
|
|
|
|
#define wx_enaddr w.arpcom.ac_enaddr
|
|
|
|
|
#define wx_cmdw w.cmdw
|
|
|
|
|
#define wx_media w.ifm
|
|
|
|
|
#define wx_next w.next
|
|
|
|
|
|
|
|
|
|
#define wx_if w.arpcom.ac_if
|
|
|
|
|
#define wx_name w.name
|
2000-12-06 00:52:28 +00:00
|
|
|
#define wx_mtx w.wxmtx
|
Add first pass of the Intel Gigabit Ethernet (wiseman) driver. This
driver seems relatively functional, but could use some souping up,
particularly in the performance area. This has both NetBSD and FreeBSD
attachment code and a fair amount of effort has been put into making
it easy to port to different *BSD platforms.
The basic design is a one tfd per mbuf transmit (with no transmit
related interrupts- tfds are gc'd as needed). The receive ring
uses a 2K buffer per rfd with a +2 byte adjust for the ethernet
header (so the payload is aligned). There's support that *almost*
works for doing large packets- the rfd chaining code works, but there's
some problem with getting good checksums at the IP reassembly level
(ditto for doing short tfd's too).
The chip has support for TCP checksums insertion for transmit and
TCP checksum calculation on receive (for both you have to do some
appropriate backoff && twiddling), but this isn't in place.
This is nearly entirely reverse engineered from the released Intel
driver, so there's a lot of "We have to do this but do not know why"
stuff. There is somebody who has the chip specs who works in FreeBSD
but they're being a bit standoffish about even sharing hints which
is somewhat annoying. It's also apparent that all I had to work with
were the first rev boards.
This driver has been lightly tested on intel && alpha, but only
point-to-point. There may be some issues with switches- use of
boot time environment variables that override EEPROM settings
(e.g., 'set wx_ilos=1' which inverts the sense of optical signal
loss) may help with this.
I had this out for review for three weeks, and nobody said anything
negative or positive, ergo, this checkin has no 'reviewed by' field
which I would have preferred.
2000-01-04 11:12:42 +00:00
|
|
|
|
|
|
|
|
#define IOCTL_CMD_TYPE u_long
|
|
|
|
|
#define WXMALLOC(len) malloc(len, M_DEVBUF, M_NOWAIT)
|
|
|
|
|
#define WXFREE(ptr) free(ptr, M_DEVBUF)
|
|
|
|
|
#define SOFTC_IFP(ifp) ifp->if_softc
|
|
|
|
|
#define WX_BPFTAP_ARG(ifp) ifp
|
|
|
|
|
#define VTIMEOUT(sc, func, arg, time) (void) timeout(func, arg, time)
|
|
|
|
|
#define TIMEOUT(sc, func, arg, time) (sc)->w.sch = timeout(func, arg, time)
|
|
|
|
|
#define UNTIMEOUT(f, arg, sc) untimeout(f, arg, (sc)->w.sch)
|
|
|
|
|
#define INLINE __inline
|
2000-12-06 00:52:28 +00:00
|
|
|
#ifdef SMPNG
|
Change and clean the mutex lock interface.
mtx_enter(lock, type) becomes:
mtx_lock(lock) for sleep locks (MTX_DEF-initialized locks)
mtx_lock_spin(lock) for spin locks (MTX_SPIN-initialized)
similarily, for releasing a lock, we now have:
mtx_unlock(lock) for MTX_DEF and mtx_unlock_spin(lock) for MTX_SPIN.
We change the caller interface for the two different types of locks
because the semantics are entirely different for each case, and this
makes it explicitly clear and, at the same time, it rids us of the
extra `type' argument.
The enter->lock and exit->unlock change has been made with the idea
that we're "locking data" and not "entering locked code" in mind.
Further, remove all additional "flags" previously passed to the
lock acquire/release routines with the exception of two:
MTX_QUIET and MTX_NOSWITCH
The functionality of these flags is preserved and they can be passed
to the lock/unlock routines by calling the corresponding wrappers:
mtx_{lock, unlock}_flags(lock, flag(s)) and
mtx_{lock, unlock}_spin_flags(lock, flag(s)) for MTX_DEF and MTX_SPIN
locks, respectively.
Re-inline some lock acq/rel code; in the sleep lock case, we only
inline the _obtain_lock()s in order to ensure that the inlined code
fits into a cache line. In the spin lock case, we inline recursion and
actually only perform a function call if we need to spin. This change
has been made with the idea that we generally tend to avoid spin locks
and that also the spin locks that we do have and are heavily used
(i.e. sched_lock) do recurse, and therefore in an effort to reduce
function call overhead for some architectures (such as alpha), we
inline recursion for this case.
Create a new malloc type for the witness code and retire from using
the M_DEV type. The new type is called M_WITNESS and is only declared
if WITNESS is enabled.
Begin cleaning up some machdep/mutex.h code - specifically updated the
"optimized" inlined code in alpha/mutex.h and wrote MTX_LOCK_SPIN
and MTX_UNLOCK_SPIN asm macros for the i386/mutex.h as we presently
need those.
Finally, caught up to the interface changes in all sys code.
Contributors: jake, jhb, jasone (in no particular order)
2001-02-09 06:11:45 +00:00
|
|
|
#define WX_LOCK(_sc) mtx_lock(&(_sc)->wx_mtx)
|
|
|
|
|
#define WX_UNLOCK(_sc) mtx_unlock(&(_sc)->wx_mtx)
|
|
|
|
|
#define WX_ILOCK(_sc) mtx_lock(&(_sc)->wx_mtx)
|
|
|
|
|
#define WX_IUNLK(_sc) mtx_unlock(&(_sc)->wx_mtx)
|
2000-12-06 00:52:28 +00:00
|
|
|
#else
|
|
|
|
|
#define WX_LOCK(_sc) _sc->w.spl = splimp()
|
|
|
|
|
#define WX_UNLOCK(_sc) splx(_sc->w.spl)
|
|
|
|
|
#define WX_ILOCK(_sc)
|
|
|
|
|
#define WX_IUNLK(_sc)
|
|
|
|
|
#endif
|
2001-04-09 21:48:50 +00:00
|
|
|
#define WX_SOFTC_FROM_MII_ARG(x) device_get_softc(x)
|
2001-10-02 00:13:44 +00:00
|
|
|
#define WX_MII_FROM_SOFTC(x) device_get_softc((x)->w.miibus)
|
2000-12-06 00:52:28 +00:00
|
|
|
|
Add first pass of the Intel Gigabit Ethernet (wiseman) driver. This
driver seems relatively functional, but could use some souping up,
particularly in the performance area. This has both NetBSD and FreeBSD
attachment code and a fair amount of effort has been put into making
it easy to port to different *BSD platforms.
The basic design is a one tfd per mbuf transmit (with no transmit
related interrupts- tfds are gc'd as needed). The receive ring
uses a 2K buffer per rfd with a +2 byte adjust for the ethernet
header (so the payload is aligned). There's support that *almost*
works for doing large packets- the rfd chaining code works, but there's
some problem with getting good checksums at the IP reassembly level
(ditto for doing short tfd's too).
The chip has support for TCP checksums insertion for transmit and
TCP checksum calculation on receive (for both you have to do some
appropriate backoff && twiddling), but this isn't in place.
This is nearly entirely reverse engineered from the released Intel
driver, so there's a lot of "We have to do this but do not know why"
stuff. There is somebody who has the chip specs who works in FreeBSD
but they're being a bit standoffish about even sharing hints which
is somewhat annoying. It's also apparent that all I had to work with
were the first rev boards.
This driver has been lightly tested on intel && alpha, but only
point-to-point. There may be some issues with switches- use of
boot time environment variables that override EEPROM settings
(e.g., 'set wx_ilos=1' which inverts the sense of optical signal
loss) may help with this.
I had this out for review for three weeks, and nobody said anything
negative or positive, ergo, this checkin has no 'reviewed by' field
which I would have preferred.
2000-01-04 11:12:42 +00:00
|
|
|
|
|
|
|
|
#define READ_CSR(sc, reg) \
|
|
|
|
|
bus_space_read_4((sc)->w.st, (sc)->w.sh, (reg))
|
|
|
|
|
#define WRITE_CSR(sc, reg, val) \
|
|
|
|
|
bus_space_write_4((sc)->w.st, (sc)->w.sh, (reg), (val))
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* Transmit soft descriptor, used to manage packets as they come in.
|
|
|
|
|
*/
|
|
|
|
|
typedef struct rxpkt {
|
|
|
|
|
struct mbuf *dptr; /* pointer to receive frame */
|
|
|
|
|
u_int32_t dma_addr; /* dma address */
|
|
|
|
|
} rxpkt_t;
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* Transmit soft descriptor, used to manage packets as they are transmitted.
|
|
|
|
|
*/
|
|
|
|
|
typedef struct txpkt {
|
|
|
|
|
struct txpkt *next; /* next in a chain */
|
|
|
|
|
struct mbuf *dptr; /* pointer to mbuf being sent */
|
|
|
|
|
u_int32_t sidx; /* start index */
|
|
|
|
|
u_int32_t eidx; /* end index */
|
|
|
|
|
} txpkt_t;
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
typedef struct wx_softc {
|
|
|
|
|
/*
|
|
|
|
|
* OS dependent storage... must be first...
|
|
|
|
|
*/
|
|
|
|
|
struct wxmdvar w;
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* misc goodies
|
|
|
|
|
*/
|
2001-10-02 00:13:44 +00:00
|
|
|
u_int32_t : 23,
|
|
|
|
|
wx_mii : 1, /* non-zero if we have a PHY */
|
Add first pass of the Intel Gigabit Ethernet (wiseman) driver. This
driver seems relatively functional, but could use some souping up,
particularly in the performance area. This has both NetBSD and FreeBSD
attachment code and a fair amount of effort has been put into making
it easy to port to different *BSD platforms.
The basic design is a one tfd per mbuf transmit (with no transmit
related interrupts- tfds are gc'd as needed). The receive ring
uses a 2K buffer per rfd with a +2 byte adjust for the ethernet
header (so the payload is aligned). There's support that *almost*
works for doing large packets- the rfd chaining code works, but there's
some problem with getting good checksums at the IP reassembly level
(ditto for doing short tfd's too).
The chip has support for TCP checksums insertion for transmit and
TCP checksum calculation on receive (for both you have to do some
appropriate backoff && twiddling), but this isn't in place.
This is nearly entirely reverse engineered from the released Intel
driver, so there's a lot of "We have to do this but do not know why"
stuff. There is somebody who has the chip specs who works in FreeBSD
but they're being a bit standoffish about even sharing hints which
is somewhat annoying. It's also apparent that all I had to work with
were the first rev boards.
This driver has been lightly tested on intel && alpha, but only
point-to-point. There may be some issues with switches- use of
boot time environment variables that override EEPROM settings
(e.g., 'set wx_ilos=1' which inverts the sense of optical signal
loss) may help with this.
I had this out for review for three weeks, and nobody said anything
negative or positive, ergo, this checkin has no 'reviewed by' field
which I would have preferred.
2000-01-04 11:12:42 +00:00
|
|
|
wx_no_flow : 1,
|
|
|
|
|
wx_ilos : 1,
|
|
|
|
|
wx_no_ilos : 1,
|
2001-04-09 21:48:50 +00:00
|
|
|
wx_verbose : 1,
|
Add first pass of the Intel Gigabit Ethernet (wiseman) driver. This
driver seems relatively functional, but could use some souping up,
particularly in the performance area. This has both NetBSD and FreeBSD
attachment code and a fair amount of effort has been put into making
it easy to port to different *BSD platforms.
The basic design is a one tfd per mbuf transmit (with no transmit
related interrupts- tfds are gc'd as needed). The receive ring
uses a 2K buffer per rfd with a +2 byte adjust for the ethernet
header (so the payload is aligned). There's support that *almost*
works for doing large packets- the rfd chaining code works, but there's
some problem with getting good checksums at the IP reassembly level
(ditto for doing short tfd's too).
The chip has support for TCP checksums insertion for transmit and
TCP checksum calculation on receive (for both you have to do some
appropriate backoff && twiddling), but this isn't in place.
This is nearly entirely reverse engineered from the released Intel
driver, so there's a lot of "We have to do this but do not know why"
stuff. There is somebody who has the chip specs who works in FreeBSD
but they're being a bit standoffish about even sharing hints which
is somewhat annoying. It's also apparent that all I had to work with
were the first rev boards.
This driver has been lightly tested on intel && alpha, but only
point-to-point. There may be some issues with switches- use of
boot time environment variables that override EEPROM settings
(e.g., 'set wx_ilos=1' which inverts the sense of optical signal
loss) may help with this.
I had this out for review for three weeks, and nobody said anything
negative or positive, ergo, this checkin has no 'reviewed by' field
which I would have preferred.
2000-01-04 11:12:42 +00:00
|
|
|
wx_debug : 1,
|
2000-06-16 06:28:31 +00:00
|
|
|
ane_failed : 1,
|
Add first pass of the Intel Gigabit Ethernet (wiseman) driver. This
driver seems relatively functional, but could use some souping up,
particularly in the performance area. This has both NetBSD and FreeBSD
attachment code and a fair amount of effort has been put into making
it easy to port to different *BSD platforms.
The basic design is a one tfd per mbuf transmit (with no transmit
related interrupts- tfds are gc'd as needed). The receive ring
uses a 2K buffer per rfd with a +2 byte adjust for the ethernet
header (so the payload is aligned). There's support that *almost*
works for doing large packets- the rfd chaining code works, but there's
some problem with getting good checksums at the IP reassembly level
(ditto for doing short tfd's too).
The chip has support for TCP checksums insertion for transmit and
TCP checksum calculation on receive (for both you have to do some
appropriate backoff && twiddling), but this isn't in place.
This is nearly entirely reverse engineered from the released Intel
driver, so there's a lot of "We have to do this but do not know why"
stuff. There is somebody who has the chip specs who works in FreeBSD
but they're being a bit standoffish about even sharing hints which
is somewhat annoying. It's also apparent that all I had to work with
were the first rev boards.
This driver has been lightly tested on intel && alpha, but only
point-to-point. There may be some issues with switches- use of
boot time environment variables that override EEPROM settings
(e.g., 'set wx_ilos=1' which inverts the sense of optical signal
loss) may help with this.
I had this out for review for three weeks, and nobody said anything
negative or positive, ergo, this checkin has no 'reviewed by' field
which I would have preferred.
2000-01-04 11:12:42 +00:00
|
|
|
linkup : 1,
|
2000-10-16 23:08:45 +00:00
|
|
|
all_mcasts : 1;
|
|
|
|
|
u_int32_t wx_idnrev; /* chip revision && PCI ID */
|
Add first pass of the Intel Gigabit Ethernet (wiseman) driver. This
driver seems relatively functional, but could use some souping up,
particularly in the performance area. This has both NetBSD and FreeBSD
attachment code and a fair amount of effort has been put into making
it easy to port to different *BSD platforms.
The basic design is a one tfd per mbuf transmit (with no transmit
related interrupts- tfds are gc'd as needed). The receive ring
uses a 2K buffer per rfd with a +2 byte adjust for the ethernet
header (so the payload is aligned). There's support that *almost*
works for doing large packets- the rfd chaining code works, but there's
some problem with getting good checksums at the IP reassembly level
(ditto for doing short tfd's too).
The chip has support for TCP checksums insertion for transmit and
TCP checksum calculation on receive (for both you have to do some
appropriate backoff && twiddling), but this isn't in place.
This is nearly entirely reverse engineered from the released Intel
driver, so there's a lot of "We have to do this but do not know why"
stuff. There is somebody who has the chip specs who works in FreeBSD
but they're being a bit standoffish about even sharing hints which
is somewhat annoying. It's also apparent that all I had to work with
were the first rev boards.
This driver has been lightly tested on intel && alpha, but only
point-to-point. There may be some issues with switches- use of
boot time environment variables that override EEPROM settings
(e.g., 'set wx_ilos=1' which inverts the sense of optical signal
loss) may help with this.
I had this out for review for three weeks, and nobody said anything
negative or positive, ergo, this checkin has no 'reviewed by' field
which I would have preferred.
2000-01-04 11:12:42 +00:00
|
|
|
u_int16_t wx_cfg1;
|
|
|
|
|
u_int16_t wx_txint_delay;
|
|
|
|
|
u_int32_t wx_ienable; /* current ienable to use */
|
|
|
|
|
u_int32_t wx_dcr; /* dcr used */
|
|
|
|
|
u_int32_t wx_icr; /* last icr */
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* Statistics, soft && hard
|
|
|
|
|
*/
|
|
|
|
|
u_int32_t wx_intr;
|
|
|
|
|
u_int32_t wx_linkintr;
|
|
|
|
|
u_int32_t wx_rxintr;
|
|
|
|
|
u_int32_t wx_xmitgc;
|
|
|
|
|
u_int32_t wx_xmitpullup;
|
|
|
|
|
u_int32_t wx_xmitcluster;
|
|
|
|
|
u_int32_t wx_xmitputback;
|
|
|
|
|
u_int32_t wx_xmitwanted;
|
|
|
|
|
u_int32_t wx_xmitblocked;
|
|
|
|
|
u_int32_t wx_xmitblocked1;
|
|
|
|
|
u_int32_t wx_xmitrunt;
|
|
|
|
|
u_int32_t wx_rxnobuf;
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* Soft copies of multicast addresses. We're only
|
|
|
|
|
* using (right now) the rest of the receive address
|
|
|
|
|
* registers- not the hashed multicast table.
|
|
|
|
|
*/
|
|
|
|
|
u_int8_t wx_mcaddr[WX_RAL_TAB_SIZE-1][6];
|
|
|
|
|
u_int8_t wx_nmca; /* # active multicast addrs */
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* Receive Management
|
|
|
|
|
* We have software and shared memory rings in a buddy store format.
|
|
|
|
|
*/
|
|
|
|
|
wxrd_t *rdescriptors; /* receive descriptor ring */
|
|
|
|
|
rxpkt_t *rbase; /* base of soft rdesc list */
|
|
|
|
|
u_int16_t rnxt; /* next descriptor to check */
|
|
|
|
|
u_int16_t _pad;
|
2000-01-23 01:41:17 +00:00
|
|
|
struct mbuf *rpending; /* pending partial packet */
|
Add first pass of the Intel Gigabit Ethernet (wiseman) driver. This
driver seems relatively functional, but could use some souping up,
particularly in the performance area. This has both NetBSD and FreeBSD
attachment code and a fair amount of effort has been put into making
it easy to port to different *BSD platforms.
The basic design is a one tfd per mbuf transmit (with no transmit
related interrupts- tfds are gc'd as needed). The receive ring
uses a 2K buffer per rfd with a +2 byte adjust for the ethernet
header (so the payload is aligned). There's support that *almost*
works for doing large packets- the rfd chaining code works, but there's
some problem with getting good checksums at the IP reassembly level
(ditto for doing short tfd's too).
The chip has support for TCP checksums insertion for transmit and
TCP checksum calculation on receive (for both you have to do some
appropriate backoff && twiddling), but this isn't in place.
This is nearly entirely reverse engineered from the released Intel
driver, so there's a lot of "We have to do this but do not know why"
stuff. There is somebody who has the chip specs who works in FreeBSD
but they're being a bit standoffish about even sharing hints which
is somewhat annoying. It's also apparent that all I had to work with
were the first rev boards.
This driver has been lightly tested on intel && alpha, but only
point-to-point. There may be some issues with switches- use of
boot time environment variables that override EEPROM settings
(e.g., 'set wx_ilos=1' which inverts the sense of optical signal
loss) may help with this.
I had this out for review for three weeks, and nobody said anything
negative or positive, ergo, this checkin has no 'reviewed by' field
which I would have preferred.
2000-01-04 11:12:42 +00:00
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* Transmit Management
|
|
|
|
|
* We have software and shared memory rings in a buddy store format.
|
|
|
|
|
*/
|
|
|
|
|
txpkt_t *tbase; /* base of soft soft management */
|
|
|
|
|
txpkt_t *tbsyf, *tbsyl; /* linked busy list */
|
|
|
|
|
wxtd_t *tdescriptors; /* transmit descriptor ring */
|
|
|
|
|
u_int16_t tnxtfree; /* next free index (circular) */
|
|
|
|
|
u_int16_t tactive; /* # active */
|
|
|
|
|
} wx_softc_t;
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* We offset the the receive frame header by two bytes so that the actual
|
|
|
|
|
* payload is 32 bit aligned. On platforms that require strict structure
|
|
|
|
|
* alignment, this means that the ethernet frame header may have to be shifted
|
|
|
|
|
* to align it at interrupt time, but because it's such a small amount
|
|
|
|
|
* (fourteen bytes) and processors have gotten pretty fast, that's okay.
|
|
|
|
|
* It may even turn out on some platforms that this doesn't have to happen.
|
|
|
|
|
*/
|
|
|
|
|
#define WX_RX_OFFSET_VALUE 2
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* Tunable Parameters.
|
|
|
|
|
*
|
|
|
|
|
* Descriptor lengths must be in multiples of 8.
|
|
|
|
|
*/
|
|
|
|
|
#define WX_MAX_TDESC 256 /* number of transmit descriptors */
|
|
|
|
|
#define T_NXT_IDX(x) ((x + 1) & (WX_MAX_TDESC - 1))
|
2000-01-23 03:18:14 +00:00
|
|
|
#define T_PREV_IDX(x) ((x - 1) & (WX_MAX_TDESC - 1))
|
2001-10-02 00:13:44 +00:00
|
|
|
#define WX_MAX_RDESC 256 /* number of receive descriptors */
|
2000-01-23 01:41:17 +00:00
|
|
|
#ifdef PADDED_CELL
|
|
|
|
|
#define RXINCR 2
|
|
|
|
|
#else
|
|
|
|
|
#define RXINCR 1
|
|
|
|
|
#endif
|
|
|
|
|
#define R_NXT_IDX(x) ((x + RXINCR) & (WX_MAX_RDESC - 1))
|
|
|
|
|
#define R_PREV_IDX(x) ((x - RXINCR) & (WX_MAX_RDESC - 1))
|
2000-06-16 06:28:31 +00:00
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* Link Up timeout, in milliseconds.
|
|
|
|
|
*/
|
|
|
|
|
|
|
|
|
|
#define WX_LINK_UP_TIMEOUT 500
|