summaryrefslogtreecommitdiffstats
path: root/sys/pci
Commit message (Collapse)AuthorAgeFilesLines
* Add support for AMD766 and AMD768 chipsets.dfr2003-09-011-3/+9
| | | | PR: 41812
* All davicom cards seem to need DC_TX_ALIGN.mbr2003-08-271-2/+1
|
* Revision 1.126 broke the interface of the bktr driver'snectar2003-08-261-14/+13
| | | | | | | | | | | | METEORSSIGNAL ioctl. Applications use this ioctl with the value METEOR_SIG_MODE_MASK (0xFFFF0000, -65536) to reset signal delivery, but revision 1.126 caused the driver to return EINVAL in this case. Interestingly, the same METEORSSIGNAL ioctl in the meteor driver uses 0 to reset signal delivery. This commit allows METEOR_SIG_MODE_MASK as a synonym for 0 in the bktr driver, and restructures the code a bit so that it is otherwise identical between the bktr and meteor drivers.
* Make TX on davicom 9102A working again. This chip needsmbr2003-08-241-0/+2
| | | | | | | its mbufs aligned on TX. PR: 53656, 42714 MFC after: 3 days
* PCI header files live in dev/pci.mdodd2003-08-231-2/+2
|
* Report media status for bitrate PHYs.mdodd2003-08-231-0/+8
|
* AGP GART driver for NVIDIA nForce/nForce2 chipsets.mdodd2003-08-232-0/+466
|
* dev/pci/meteor_reg.h doesn't exist. Revert this part of last commit.imp2003-08-231-1/+1
|
* Revert previous change for ncrreg.h. The header really lives inmarcel2003-08-231-1/+1
| | | | sys/pci.
* Prefer new location of pci include files (which have only been in theimp2003-08-2228-59/+59
| | | | | tree for two or more years now), except in a few places where there's code to be compatible with older versions of FreeBSD.
* Change instances of callout_init that specify MPSAFE behaviour tosam2003-08-191-1/+1
| | | | | use CALLOUT_MPSAFE instead of "1" for the second parameter. This does not change the behaviour; it just makes the intent more clear.
* "short cable" fix for DP8315sam2003-08-191-0/+23
| | | | | Derived from: netbsd and tech note at soekris web site MFC after: 1 week
* Argh. Last commit only had the __FBSDID() fix. Really add the device IDwpaul2003-08-152-0/+3
| | | | for the 8100 this time.
* It appears in some configurations with an on-board RTL8100 chip (in thiswpaul2003-08-151-2/+0
| | | | | | | | | | case, a "Vortex86" mini PC), the PCI device ID value in the EEPROM (0x8100) does not agree with the PCI device ID returned by pci_get_device() (0x8139). This means that while rl_probe() matches the device, rl_attach() doesn't. Work around this by adding an entry to the rl_devs table for the 8100 with a device ID of 0x8100. Also, get rid of extra instance of __FBSDID(). One is enough.
* Set the TX hardware checksum offload bits on all the descriptors of awpaul2003-08-132-17/+23
| | | | | | | multi-fragment transmission. I'm not sure if this is a bug or a requirement that I overlooked with going through the documentation, but the sample 8169 NIC that I have seems to require it at least some of the time or else it botches TCP checksums on segments that span multiple descriptors.
* Add or correct range checking of signal numbers in system calls andnectar2003-08-101-0/+2
| | | | | | | | | ioctls. In the particular case of ptrace(), this commit more-or-less reverts revision 1.53 of sys_process.c, which appears to have been erroneous. Reviewed by: iedowse, jhb
* Grrr. There is a gratuitous difference in the RX descriptor statuswpaul2003-08-101-0/+18
| | | | | | | | | | | | word between the 8139C+ and the 8169. The 8139C+ has a 'frame alignment error bit' (bit 27) but the 8169 does not. Rather than simply mark this bit as reserved, RealTek removed it completely and shifted the remaining status bits one space to the left. This was causing rl_rxeofcplus() to misparse the error and checksum bits. To workaround this, rl_rxeofcplus() now shifts the rxstat word one bit to the right before testing any of the status bits (but after the frame length has been extracted).
* - Update some comments regarding hardware details of the 8169 andwpaul2003-08-102-40/+60
| | | | | | | | | | | | | | | | | note the existence of the 8169S and 8110S components. (The 8169 is just a MAC, the 8169S and 8110S contain both a MAC and PHY.) - Properly handle list and buffer addresses as 64-bit. The RX and TX DMA list addresses should be bus_addr_t's. Added RL_ADDR_HI() and RL_ADDR_LO() macros to obtain values for writing into chip registers. - Set a slightly different TIMERINT value for 8169 NICs for improved performance. - Change left out of previous commit log: added some additional hardware rev codes for other 10/100 chips and for the 8169S/8110S 'rev C' gigE MACs.
* Add preliminary support for the RealTek 8169 gigE chip. Changes:wpaul2003-08-072-4/+101
| | | | | | | | | | | | | | | | | | | | | - Fix a bug in rl_dma_map_desc(): set the 'end of ring' bit in the right descriptor (DESC_CNT - 1, not DESC_CNT). The 8139C+ is limited to 64 descriptors and automatically wraps at 64 descriptors even if the EOR bit isn't set, but the 8169 NIC can have up to 1024 descriptors per ring, so we must set the wrap point in the right place. - RealTek moved the RL_TIMERINT register from offset 0x54 to 0x58 in the 8169 -- account for this. - Added rl_gmii_readreg() and rl_gmii_writereg() routines. - Fix rl_probe() to deal with the case where the base type is not RL_8139. The next step is to add jumbo buffer support. Tested with the Xterasys XN-152 NIC (hard to beat $29 for a gigE NIC).
* Enable IFCAP_VLAN_MTU and increase MTU for it.simokawa2003-08-051-2/+3
| | | | Reviewed by: wpaul
* Use the BUS_DMA_ZERO flag.mux2003-07-272-12/+5
|
* Use the BUS_DMA_ZERO flag.mux2003-07-271-2/+1
|
* Use the BUS_DMA_ZERO flag instead of bzero()'ing DMA memory.mux2003-07-271-5/+2
|
* Changed the type of the variable `qidx' from u_int8_t to int,robert2003-07-271-2/+3
| | | | | | | | | | | | | | | | | | | mainly to quiet a warning emitted by GCC 3.3 about comparing a variable to a value which is larger than the former can hold. The value was checked to make sure the `np->squeue' array is not accessed behind its boundary. This worked due to possibly accidental truncation when (np->squeueput + 1) was larger than or equal to MAX_START (256) when it was assigned to `qidx'. `qidx' is used to hold the next position in the start queue for an insertion. The new type was chosen because some other code in the function ncr_freeze_devq() also uses plain integers to hold those indices. Wrapped the line after the closing parenthesis of an `if' condition.
* Erm, my previous commit was wrong and sis_tick() was only called each timecognet2003-07-222-1/+6
| | | | | | | | | | sis_ioctl() was called, so one had to use ifconfig each time the cable got plugged in to be able to use the connection. Do it a better way now, add a "in_tick" field in the softc structure, call timeout() in sis_tick() and don't call it in sis_init() if in_tick is non-zero. Reported by: Landmark Networks Pointy hat to: cognet
* Add support for FA-511; Submitted by: Kenneth P. Stox; Pr 42858imp2003-07-192-0/+5
|
* Fix a busdma bogon:wpaul2003-07-181-3/+3
| | | | | | Some of the calls to bus_dmamap_sync() were syncing the DMA descriptor ring maps using the mbuf tag, when they should have been using the descriptor ring tag instead.
* Add support for the 8139C+ chipset. Unlike the other chips in the 8139wpaul2003-07-102-111/+1433
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | series, the 8139C+ has a descriptor-based DMA mechanism, and its performance is actually pretty respectable. Note: the 8139D chip does not support C+ mode. Only the 8139C+ and 8169 gigE chips support C+ mode. Supported features: - RX and TX checksum offload - hardware VLAN tag insertion/extraction - TX interrupt moderation using the 8139's on-board timer Everything should be properly busdma'ed and endian-independent, so things should work ok on non-x86 platforms. Unfortunately, my call for testers on this code was met with deafening silence, and I don't have access to any non-x86 FreeBSD boxes at the moment, so this is speculation. The device detection code has been cleaned up a little as well (thanks to Michal Mertl) for the patches. There are also updates to the rl(4) man page (which I accidentally checked in before when I updated the dc(4) man page. Oops.) Todo: finish support for the 8169 gigabit ethernet chip. This mainly requires writing an rlgphy driver to handle the 8169's built-in PHY. This will have to wait until I actually get my hands on an 8169 card for testing though. (I still can't find a source for one in the U.S. Suggestions/pointers welcome.)
* Add support for a bunch of Microsoft networking products:wpaul2003-07-102-0/+34
| | | | | | | | - MN-110 10/100 USB ethernet (ADMtek Pegasus II, if_aue) - MN-120 10/100 cardbus (ADMtek Centaur-C, if_dc) - MN-130 10/100 PCI (ADMtek Centaur-P, if_dc) Also update dc(4) man page to mention support for MN-120 and MN-130.
* Support for large frames for VLANs was added by tweaking the packet sizewpaul2003-07-102-8/+47
| | | | | | | | | | | | | | | | | | | | | | | | | | | | 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.
* Make the dc(4) driver endian-clean, so to that it works on sparc64.mux2003-07-092-45/+56
| | | | | | | There are such cards in Netra X1 boxes, which should thus be fully supported now. Tested by: jake
* Convert the dc(4) driver to the busdma API. This is a necessary stepmux2003-07-062-117/+304
| | | | | | | | | | | | | | | to have this driver working on sparc64. It still needs to be made endian-clean before it can work there. Special thanks to dragonk@evilcode.net for sending me a dc(4) card so that I was able to do this work. Many cheers to all the people that tested this change, thanks to them, this change shouldn't break anything :-). Tested by: marcel (i386 and ia64), ru (i386), wilko (alpha), mbr (i386), wpaul (i386) and Will Saxon <WillS@housing.ufl.edu> (i386)
* Fix a bug that could cause dc(4) to m_freem() an already freedmux2003-07-061-1/+2
| | | | | | mbuf or something that isn't an mbuf. MFC after: 3 days
* Various style(9) and readability fixes.mux2003-07-061-14/+22
|
* - Ensure that the busdma API won't do deferred loads by using themux2003-07-041-9/+9
| | | | | | BUS_DMA_NOWAIT flag, since the code can't handle this. - Use NULL, NULL for the lockfunc and lockfuncarg parameters of bus_dma_tag_create() since deferred loads can't happen now.
* Due to extreme bogusness in the pci bus layer, these drivers wereimp2003-07-0310-22/+26
| | | | | | | | | forced to do slightly bogus power state manipulation. However, this is one of those features that is preventing further progress, so mark them as BURN_BIRDGES like I did for the drivers in sys/dev/... This, like the other change, are a no-op unless you have BURN_BRIDGES in your kernel.
* Mega busdma API commit.scottl2003-07-013-3/+16
| | | | | | | | | | | | | | | | | | | | | | | | Add two new arguments to bus_dma_tag_create(): lockfunc and lockfuncarg. Lockfunc allows a driver to provide a function for managing its locking semantics while using busdma. At the moment, this is used for the asynchronous busdma_swi and callback mechanism. Two lockfunc implementations are provided: busdma_lock_mutex() performs standard mutex operations on the mutex that is specified from lockfuncarg. dftl_lock() is a panic implementation and is defaulted to when NULL, NULL are passed to bus_dma_tag_create(). The only time that NULL, NULL should ever be used is when the driver ensures that bus_dmamap_load() will not be deferred. Drivers that do not provide their own locking can pass busdma_lock_mutex,&Giant args in order to preserve the former behaviour. sparc64 and powerpc do not provide real busdma_swi functions, so this is largely a noop on those platforms. The busdma_swi on is64 is not properly locked yet, so warnings will be emitted on this platform when busdma callback deferrals happen. If anyone gets panics or warnings from dflt_lock() being called, please let me know right away. Reviewed by: tmm, gibbs
* In order to set the MAC address on RealTek NICs, you must flip WRITECFGwpaul2003-06-291-5/+9
| | | | | | | | | | bit in the EEPROM mode register on. Also, the address must be written in two 32-bit register accesses instead of 6 8-bit accesses. Tested with my 8139B cardbus NIC. PR: kern/35900 Submitted by: Mark Kettenis <kettenis@chello.nl>
* Modify the xl_reset() routine slightly so that, if we're using memorywpaul2003-06-291-0/+10
| | | | | | | | | | | | | | | | | | mapped I/O mode, we pause for .1 seconds after issuing the reset command before trying to poll the 'command busy' bit in the status register. With my 3c575C cardbus NIC, my Sony Picturebook locks up when it tries to read the status register immediately after the reset. This appears to be a problem only with certain NICs on certain hardware, but the added delay should not hurt cards that already work. This bug seems to have been brought to light by the fact that the xl driver now defaults to memory mapped I/O mode instead of programmed I/O mode like it used to. With PIO mode, the delay isn't needed and everything works (which is why this NIC worked with 5.0-RELEASE but not 5.1). I suspect that what's happening is that when the chip is reset, it takes a little while for the memory-mapped decoding logic to recover. Trying to access the chip's registers during this period causes an error condition of some kind that wedges the system.
* Sort the list of PCI ID's in numerical order and fix a whitespace bogon.jhb2003-06-271-4/+4
|
* Add a PCI ID for the Apollo Pro 133A.mdodd2003-06-231-0/+2
| | | | | PR: kern/46983 Submitted by: David Holm <david@realityrift.com>
* Add PCI IDs for the i82855 and i82875P AGP bridges.mdodd2003-06-231-0/+12
| | | | | PR: i386/53136, i386/51802 Submitted by: Kyunghwan Kim <redjade@atropos.snu.ac.kr>, Norikatsu Shigemura <nork@FreeBSD.org>
* Add ID for VT8233A.mdodd2003-06-221-0/+2
| | | | | PR: i386/38299 Submitted by: Rob Schulhof <rrs@there.net>
* Add vm object locking.alc2003-06-191-0/+6
|
* Repo-copy of sys/pci/if_en_pci.c to the rest of the midway driver (sys/dev/en)harti2003-06-161-485/+0
| | | | | so that all of the driver sources are in one place. Adjust the configuration files and the module build.
* Merge common XPT_CALC_GEOMETRY functions into a single convenience function.njl2003-06-141-20/+1
| | | | | | | | | | | | | Devices below may experience a change in geometry. * Due to a bug, aic(4) never used extended geometry. Changes all drives >1G to now use extended translation. * sbp(4) drives exactly 1 GB in size now no longer use extended geometry. * umass(4) drives exactly 1 GB in size now no longer use extended geometry. For all other controllers in this commit, this should be a no-op. Looked over by: scottl
* Fix alignment requirements of tulip_rombuf by further increasingticso2003-06-131-4/+4
| | | | | | tulip_boardid size. Add a comment to tulip_rombuf about this requirement. I have had panics on alpha while probing a de card.
* Remove code that tries to detect if the MCLSHIFT and MSIZE macrosmux2003-06-131-46/+0
| | | | | | | are the same that those of the kernel in the KLD_MODULE case. If we ever want to detect that kind of problems, this is not the right place to do this since every network driver would be affected by such desynchronisation.
* Make the midway driver use the new ATM phy driver. This allows one toharti2003-06-131-0/+3
| | | | | | | toggle several media options (sonet/sdh, for example) with ifconfig and to see the carrier state in ifconfig's output. It gives also read/write access (given the right privilegs) to the S/Uni registers to user space programs.
* Add vm object locking.alc2003-06-131-1/+8
|
OpenPOWER on IntegriCloud