summaryrefslogtreecommitdiffstats
path: root/sys/pci/if_xlreg.h
Commit message (Collapse)AuthorAgeFilesLines
* - Avoid calling pci_get_device() more than once in a single function.mdodd2003-09-141-0/+1
| | | | | - Provide a mechanism to prevent the use of MMIO. - Prevent the use of MMIO for all 3c575 cardbus cards.
* Support for large frames for VLANs was added by tweaking the packet sizewpaul2003-07-101-1/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | register, present only on 3c90xB and later NICs. This meant that you could not use a 1500 byte MTU with VLANs on original 3c905/3c900 cards (boomerang chipset). The boomerang chip does support large frames though, just not in the same way: you can set the 'allow large frames' bit in the MAC control register to receive frames up to 4K in size. Changes: - Set the 'allow large frames' bit for boomerang chips and increase the packet size register for cyclone and later chips. This allows us to use IFCAP_VLAN_MTU on all supported xl(4) NICs. - Actually set the IFCAP_VLAN_MTU flag in the capabilities word in xl_attach(). - Change the method used to detect older boomerang chips. My 3c575C cardbus NIC was being incorrectly identified as 3c90x chip instead of 3c90xB because the capabilities word in its EEPROM reports a bizzare value. In addition to checking for the supportsNoTxLength bit, also check for the absence of the supportsLargePackets bit. Both of these cases denote a 3c90xB chip. - Make RX and TX checksums configurable via the SIOCSIFCAP ioctl. - Avoid an unecessary le32toh() in xl_rxeof(): we already have the received frame size in the lower 16 bits of rxstat, no need to read it again. Tested with 3c905-TX, 3c900-TPO, 3c980C and 3c575C NICs.
* Instead of relying on a compile time define to determine whether the xlsilby2003-03-181-0/+1
| | | | | | | | | driver should use port or memory based IO, determine it dynamically at runtime, preferring MMIO where possible. This helps us support newer arches which dislike port based access better. Tested on i386 & sparc64, with 3c900, 905, 905b, and 905C cards. (in varying combinations by both jake and myself)
* - Fix mbuf leak when we successfully allocate a new mbuf but fail tomux2003-02-181-0/+1
| | | | | | | | | bus_dmamap_load() it. - Make it so reusing mbufs when we can't allocate (or map) new ones actually works. We were previously trying to reuse a mbuf which was already bus_dmamap_unload()'ed. Reviewed by: silby
* Correctly identify the 3C920B chipset; although it may ship with some Nforce2silby2003-01-221-1/+1
| | | | | | boards, it's definitely not an Nvidia chip. Info from: Nvidia's Linux Network driver & pciids.sourceforge.net
* Make the xl driver work on sparc64:tmm2003-01-191-0/+1
| | | | | | | | | | | | | | | | - Add conversions to/from little endian for fields that the NIC accesses by DMA as required. - Add some bus_dmamap_sync() calls, and correct some existing ones. - Read the receiver information from the EEPROM in an endian-neutral manner. - Load all RX and TX descriptors in a single DMA map up front, and get the bus addresses of individual descriptors by address arithmetic; this fixes multiple use of the descriptor tags, which would have undesired effects. It seems that xl still does not work on e250 boxen, for reasons which are not clear yet. Reviewed by: mux
* Partial support for the nVidia nForce2 chipset's on-board Broadcom/Altima PHYobrien2003-01-121-0/+1
| | | | | | | and 3com MAC. Specifications for the Altima PHY are available at: http://www.altimacom.com/products/ac101L.html Submitted by: Mikko S. Hyvarinen <morphy@morphy.iki.fi>
* Add support for the 3c555 miniPCI chipset.silby2003-01-061-0/+1
| | | | | | Submitted by: johannes <johannes@paradise.net.nz> PR: 46603 MFC after: 3 days
* Convert the xl(4) driver to the busdma API. This should makemux2002-12-171-18/+21
| | | | | | | it possible to use this driver under ia64, sparc64 (though there may be endianness issues with this one) and other archs. Tested on: i386, alpha (gallatin)
* Add some magic bits necessary to turn the transmitter on for somesilby2002-10-221-0/+3
| | | | | | | | | (newer) 556B chips. Requested & tested by: Dinesh Nambisan <dinesh@nambisan.net> Magic bits found by: Dave Dribin & Donald Becker MFC After: 3 days
* Turn off the premature locking in xl. The driver tries to use the mutexespeter2002-10-141-0/+6
| | | | | | as spl replacements, but you cant sleep while holding mutexes. This change has been made on many other drivers.
* Fix a problem where stats overflow interrupts would causesilby2001-12-171-1/+1
| | | | | | | | | | a major slowdown, and re-enable stats overflow interrupts. For future reference, the bug was in our code, and not some bug in the 3com chips. Reviewed by: wpaul MFC after: 2 days
* Add support for the 3c656B cardbus adapter. This is one half of awpaul2001-08-281-1/+3
| | | | | | | | | | | dual function card. It needs pretty much the same flags as the 656C, except that it seems to need both the INVERT_MII_PWR and INVERT_LED_PWR flags set. Tested with cardbus in -current as of today. Also added support for the 3c656, which looks to be the same as the 656B, except it doesn't need the EEPROM_8BIT flag. I think. This one is untested, but the added support should not break any of the other cards.
* Close PR #27742: allow the xl driver to receive VLAN tagged frames bywpaul2001-05-311-1/+2
| | | | | | | | | | | | | | | setting the 'max packet size' register in window 3. This only works for cards based on the cyclone or newer chipsets (i.e. it won't work with the original 3c905/boomerang cards). There is a trick which will work with the boomerang, which is to turn on the 'large packets ok' bit in the MAC control register, however this lets the chip accept any frame up to 4K in length, which is larger than the mbuf cluster buffers we use to receive frames. If somebody sends us such a frame and the chip DMAs it to us, it could write past the end of the cluster buffer and clobber something. PR: kern/27742
* Disable the 'stats counter overflow' interrupts since they can happenwpaul2001-05-111-1/+1
| | | | | | much more often that expected and negatively impact performance when running at 100mbps. I need to figure out if there's a better way to handle this, but for now this shouldn't hurt anything.
* Change and clean the mutex lock interface.bmilekic2001-02-091-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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)
* Add device ID for the 3c565C card. I followed exactly the 3c575c, butimp2000-12-011-0/+1
| | | | | further tweaks may be necessary down the road. This does nothing with the serial side of the card.
* add support for 3Com 3c575TX Fast Etherlink XL.sanpei2000-11-021-0/+1
| | | | | | | Device information for 3C575-TX is from NetBSD, sys/dev/cardbus/if_ex_cardbus.c file. Reviewed by: wpaul, imp
* Add support for cardbus card's chips. This will make the 3c575 cardsimp2000-10-161-0/+8
| | | | | | work once the rest of the cardbus infrastructure has been committed. Submitted by: Jonathan Chen <jon@spook.org>
* First round of converting network drivers from spls to mutexes. Thiswpaul2000-10-131-0/+4
| | | | | | | | takes care of all the 10/100 and gigE PCI drivers that I've done. Next will be the wireless drivers, then the USB ones. I may pick up some stragglers along the way. I'm sort of playing this by ear: if anyone spots any places where I've screwed up horribly, please let me know.
* Add support for the 3Com 556 and 556B mini-pci adapters used on somewpaul2000-08-281-0/+13
| | | | | | | laptops. I've checked that this still works with the other cards and it works with the 3c556 that I have access to, but I want to check that it works with the 556B mentioned in PR #20878 before I close out the PR and merge to -stable.
* Update the xl driver to recognize yet another 3c905B/3c905C class NIC:wpaul1999-12-161-0/+1
| | | | | | | | | | | | | | | | | the 3c450-TX HomeConnect. Like the 3cSOHO100-TX OfficeConnect, this NIC uses the same ASIC as the 3c905B/3c905C but is targeted for a particular market segment (home users). It is somewhat less expensive than the 3c905B/3c905C ($49, according to the 3Com web site), comes with its own custom driver kit and is bundled with various goofy Windows software packages designed to demonstrate the niftyness of home networking (networked game demos, etc...). Changes are: - Add PCI ID to list in if_xlreg.h. - Update xl_devs table in if_xl.c. - Update xl_choose_xcvr() to consider the HomeConnect the same as all the other 10baseT/100baseTX cards.
* Make some small tweaks:wpaul1999-10-141-0/+1
| | | | | | | | | | | | - When setting/clearing promisc mode, just update the filter, don't reset the whole interface. - Call xl_init() in xl_ifmedia_upd() when setting miibus media modes. This fixes a problem with the 3c905B-COMBO where switching from 10base5/AUI or 10base2/BNC to a 10/100 mode doesn't always work right. - Attempt to reset the interface in xl_init() so that we know we're getting the receive and transmit rings reset properly.
* Add an alternate transmit strategy for 3c90xB adapters based on the transmitwpaul1999-09-201-2/+17
| | | | | | | | | | | | | | | strategy used in the 3Com Linux driver. The new strategy is to use transmit descriptor polling -- that is, the NIC polls the descriptors to see when new packets are available for transmission. The advantage to the new scheme is that no register accesses are needed in the transmit routine. The old scheme requires several register accesses to stall the TX engine, update the TX DMA list pointer register, then unstall the TX engine. Hopefully the new scheme will provide improved transmit performance with less CPU overhead. This only affects the 3c90xB or 3c90xC cards, not the 3c90x cards. This means the original 3c900 and 3c905 cards are unaffected. Newer cards include the 3c900B series, the 3c905B, 3c980, 3c980B, 3c905C and 3c905C, and the 3cSOHO100-TX OfficeConnect.
* 3Com has produced their own Linux driver for the 3c90x/3c90xB series cards.wpaul1999-09-151-0/+1
| | | | | | | | It's GPL'ed of course, but looking over it tonight I learned of Yet Another Fast EtherLink XL Adapter: the 3c980C server adapter. This is basically an updated version of the 3c980 that uses the Tornado ASIC instead of the earlier Hurricane ASIC. The only change here is to add the new PCI device ID (0x9805) and corresponding table entries.
* Convert the 3Com XL driver to miibus. This one is a little trickywpaul1999-08-291-154/+1
| | | | | | | | | | | | | | | | due to the fact that there are non-MII cards supported by the same driver and I don't have all of the cards available for testing. There's also the 3c905B-COMBO which has MII, AUI and BNC media ports all in one package. Supporting the COMBO is difficult because we have to add the 10base5 and 10base2 media types to the same ifmedia struct as the MII-attached types, however there is no way to force the miibus and child PHYs into existence before xl_attach() completes, so there is no ifmedia struct available in xl_attach(). What we do inistead is use the mediainit method as a callback: when a child PHY is attached, it calls the miibus mediainit routine which selects a default media. This routing also calls the NIC driver's mediainit method (if it implements one) at which point we can safely add the other media types.
* $Id$ -> $FreeBSD$peter1999-08-281-1/+1
|
* Convert the xl driver to newbus. It is now possible to make this driverwpaul1999-07-201-1/+4
| | | | | | | | | | into a loadable module, and all of the platform dependencies are gone (except for the alpha_XXX_dmamap() thing, which is another issue -- I still don't know how to use the busdma stuff with a network driver). Also increase the delay in xl_reset(); testing on a 486/66 with a 3c905C shows that reading the EEPROM fails immediately after a reset. Waiting a little longer after the reset completes seems to fix it.
* Head for the hills friends and neighbors, 3Com has yet another 3c90Xwpaul1999-05-301-1/+2
| | | | | | | | chipset. First you thrilled to the 3c905, then you trembled at the 3c905B, now gaze in wonder at: the 3c905C! This appears to be another 3c90X series chip called the Tornado (PCI ID 0x10B7/0x9200) and should be equivalent (from the driver API perspective) to the 3c905B, so all we have to do is add the PCI ID to the list.
* Allow chipset drivers to specify the direct-mapped DMA window's mask ingallatin1999-05-261-3/+3
| | | | | | | | | | preparation for tsunami support. Previous chipsets' direct-mapped DMA mask was always 1024*1024*1024. The Tsunami chipset needs it to be 2*1024*1024*1024 These changes should not affect the i386 port Reviewed by: Doug Rabson <dfr@nlsystems.com>
* Dynamically increase TX start threshold if TX underruns are detected.wpaul1999-05-051-1/+2
|
* Bunch of updates:wpaul1999-04-301-9/+12
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | - Try to unbreak what I broke by screwing with the tx queuing again. I'm waiting for a few more people to test out this code and report back before I move it into current. Hopefully it will be soon. Basically I reverted to the old TX queuing strategy. - Add experimental support for the 3c900B-FL (10mbps ST fiber). The card should be detected properly and the 10baseFL mode supported, but again I'm still waiting for word from a tester to see if this actually works. It shouldn't affect the other cards though; all the differences are in media selection. - Set the TX start threshold register to get better performance. - Increase the size of the RX and TX rings. UDP performance was pretty bad because the TX ring was too small. Should be substantially better now (I can saturate the link with either TCP or UDP now). - Change some of the #defines to reflect proper 3Com ASIC names (boomerang, cyclone, krakatoa, hurricane). - Simplify and reorganize interrupt handler; ack all interrupts right away and then process them. This avoids a potential race condition. (Noted by Matt Dillon.) - Reorganize the bridging code to eliminate using a goto to jump into the middle of an if() {} clause. Sorry, that just made my brain itch. - Use m_adj() in xl_rxeof(). - Make the payload alignment in xl_newbuf() the default (instead of just conditionally defined for the alpha) to improve NFS performance (avoids need for nfs_realign()).
* - Close PR #11136: add PCI ID for another new cyclone device: thewpaul1999-04-151-1/+4
| | | | | | | | | | | | 3c900B-TPC (twisted pair and coax). Treated similarly to the 3c900B-COMBO, except no AUI port. - Fix media selection so that it's possible to select the AUI and BNC ports on the 3c905B-COMBO. This board is now fully supported. - Change TX queueing strategy to hopefully be more efficient by avoiding register accesses in xl_start(). Should provide small performance improvement and a little better reliability.
* Add support for the 3cSOHO100-TX, which is a "hurricane" chipsetwpaul1999-04-121-1/+2
| | | | | | (cut-down version of the "cyclone" for the small office/home office "cheap bastard" market). Basically the same as a 3c905B but without Wake-on-LAN, ROM socket, etc...
* Some small updates:wpaul1999-04-111-1/+2
| | | | | | | | | | | | | | | | - Wait longer for the reset to complete in xl_attach() to try and avoid 'command never completed' warnings. - Clean up a few odds and ends in xl_attach(). - Add PCI ID for the 3c905B-COMBO (a new card). Right now this is treated as a 3c905B; I need to dig up one of these cards for testing before I can make the AUI and BNC ports work. - Add a hack to force reading the I/O address directly from the PCI registers if pci_map_port() fails. I SHOULD NOT HAVE TO DO THIS: SOMEBODY WITH MORE PCI CLUES THAN I SHOULD INVESTIGATE WHY THIS HAPPENS.
* Make the xl and pn drivers work on FreeBSD/alpha and add them towpaul1999-03-271-31/+19
| | | | | | | | | | | | | | | sys/alpha/conf/GENERIC. Note: the PNIC ignores the lower few bits of the RX buffer DMA address, which means we have to add yet another kludge to make it happy. Since we can't offset the packet data, we copy the first few bytes of the received data into a separate mbuf with proper alignment. This puts the IP header where it needs to be to prevent unaligned accesses. Also modified the PNIC driver to use a non-interrupt driven TX strategy. This improves performance somewhat on x86/SMP systems where interrupt delivery doesn't seem to be as fast with an SMP kernel as with a UP kernel.
* Close PR #8384:wpaul1998-10-221-2/+2
| | | | | | | | | | | | Revert the transmission packet queueing strategy changes. Clearly I missed something while debugging this, although I never encountered any problems on my test machines. Also make one other minor change: jack up the TX reclaim threshold for 3c90xB adapters in order to stave off 'transmission error: 82' errors. Document the existence of the tx reclaim register (for inspecting the current reclaim threshold) in register window 5 (if_xlreg.h).
* Modify the transmit packet queuing strategy a bit to be a little lesswpaul1998-10-191-1/+2
| | | | | | | | | | | | | | agressive. With the old code, if a descriptor chain was already on its way to the chip, xl_start() would try to splice new chains onto the end of the current chain by stopping the transmitter, modifying the tail pointer of the current chain to point to the head of the new chain, then restart the transmitter. The manual says you're allowed to do this and it works, but I'm not too keen on it anymore. The new code waits until the eixsting chain has been sent and then queues the next waiting chain in the 'transmit ok' handler. Performance still looks good one way or the other.
* Add support for yet another "cyclone" board, with PCI device id 0x905A.wpaul1998-10-091-1/+2
| | | | | | | This is a 100BaseFX board with SC fiber media connectors. I don't actually have one of these but I've been told it works with the xl driver. Submitted by: Jason Wright from the openbsd group
* Apply patch graciously provided by Jason Wright <jason@thought.net> fromwpaul1998-09-251-2/+2
| | | | | | | | | | | | | | | the OpenBSD group to fix a problem with the default ifmedia not being set properly in some cases with a 3c905B, leading to a panic in ifmedia_set(). Also apply a patch to force the transmit start routine to check the transmitter to make sure it isn't wedged if the outbound tx queue appears full. This seems to cure some problems with 'watchdog timeout' errors cropping up in some cases. I tried to do this before by checking for the IFF_OACTIVE flag on entry to xl_start(), but if the IFF_OACTIVE flag is set, ether_output() won't even call xl_start(). It should work now. Lastly, increase the size of the TX queue from 10 descriptors to 16 to hopefully make it less likely that the TX queue will fill up.
* Modify the xl_mediacheck() routine to also test for the case where thewpaul1998-09-041-2/+2
| | | | | | | | | | | | | | | | XCVR value read from the EEPROM is completely wrong. I've had one report of a 3c900 card that returns an xcvr value of 14, which is impossible (the manual states that all vales above 8 are reserved). If the value is out of the expe Add PCI vendor ID for the 3c980-TX server adapter card, which apparently also uses the cyclone chip. Graciously supplied Mats O Jansson <maja@cntw.com>. Also noted by Mats, the 10mpbs cyclone adapters should be named 3c900B, not 3c905B. I haven't actually encountered a 10mbps only cyclone adapter yet, nor anybody who has one, but this makes sense given the naming scheme used for the older boomerang adapters.
* - #define mask of enabled interrupts/indications in if_xlreg.h instead ofwpaul1998-08-241-1/+8
| | | | | | constructing local copy in xl_init() - disable interrupts on entry to xl_intr(), re-enable them on exit. - fix a few typos in some comments
* Increase the number of descriptors (and, as a consequence, the numberwpaul1998-08-211-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | of associated mbuf clusters) in the RX ring from 4 to 16. On my really fast PI 400Mhz test machines, 4 descriptors (and associated mbuf clusters) is enough to achieve decent performance without any RX overruns. However, one person reported problems with the following scenario: - P90 system running FreeBSD with a 3c905B-TX adapter, slow IDE hard disk (Quantum Bigfoot?) - PII 266 with SCSI disks running LoseNT and also with a 3c905B-TX - Both machines connected together via crossover cable at 100Mbps full-duplex - LoseNT machine writing largs amounts of data (2.5 GB work of files each in the neighborhood of 1 to 2 MB in size) via samba to the FreeBSD machine In this case, the LoseNT machine is sending data very fast. Apparently there weren't any problems initially because the user was writing to one particular disk which was relatively fast, however after this disk filled up and the user started writing to the second slower disk, RX overruns would occur and sometimes the RX DMA engine would stall after a 100 to 500MB had been transfered. The xl_rxeof() handler is supposed to detect this condition and restart the upload engine; I'm not sure why it doesn't, unless interrupts are being lost and the rx handler isn't getting called. This is still an improvement over the Linux driver, which uses 32 descriptors in its receive ring. :) Problem reported by: Heiko Schaefer <hschaefer@fto.de>
* Import the (Fast) Etherlink XL driver. I'm reasonally confident in itswpaul1998-08-161-0/+815
stability now. ALso modify /sys/conf/files, /sys/i386/conf/GENERIC and /sys/i386/conf/LINT to add entries for the XL driver. Deactivate support for the XL adapters in the vortex driver. LAstly, add a man page. (Also added an MLINKS entry for the ThunderLAN man page which I forgot previously.)
OpenPOWER on IntegriCloud