summaryrefslogtreecommitdiffstats
path: root/sys/pci
Commit message (Collapse)AuthorAgeFilesLines
* Add support for another ATI IGP 340M (RS200M) AGP bridge.anholt2006-09-011-1/+4
| | | | | | PR: kern/100958 Submitted by: Kazuo Dohzono <dohzono@axion-software.com> MFC after: 1 week
* Use aperture base address from north bridge. Some BIOS does not encodejkim2006-08-211-10/+5
| | | | | | | misc. control registers correctly and it is inconsistent with north bridge. In fact, there are too many broken BIOS implementations out there and we cannot fix every possible combination but at least it is consistent with what we advertise with ioctl(2).
* Add more nForce4 SMBus 2.0 PCI IDs.ru2006-08-181-0/+9
|
* Don't reset Tx threshold value whenever xl_init_locked() is called.yongari2006-08-121-1/+3
| | | | | | Instead the threshould is initialized in device attach. Later the threshold could be increased in Tx underrun error and the new threshold should be used in xl_init_locked().
* Make sure to check frames in Tx queue are empty before clearingyongari2006-08-121-4/+4
| | | | watchdog timer.
* Explicitly set v3 mode only when it is requested. Don't bother otherwise.jkim2006-08-111-1/+6
|
* Commit the results of the typo hunt by Darren Pilgrim.yar2006-08-041-1/+1
| | | | | | | | | | This change affects documentation and comments only, no real code involved. PR: misc/101245 Submitted by: Darren Pilgrim <darren pilgrim bitfreak org> Tested by: md5(1) MFC after: 1 week
* Another small update to the re(4) driver:wpaul2006-08-011-0/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | - Change the workaround for the autopad/checksum offload bug so that instead of lying about the map size, we actually create a properly padded mbuf and map it as usual. The other trick works, but is ugly. This approach also gives us a chance to zero the pad space to avoid possibly leaking data. - With the PCIe devices, it looks issuing a TX command while there's already a transmission in progress doesn't have any effect. In other words, if you send two packets in rapid succession, the second one may end up sitting in the TX DMA ring until another transmit command is issued later in the future. Basically, if re_txeof() sees that there are still descriptors outstanding, it needs to manually resume the TX DMA channel by issuing another TX command to make sure all transmissions are flushed out. (The PCI devices seem to keep the TX channel moving until all descriptors have been consumed. I'm not sure why the PCIe devices behave differently.) (You can see this issue if you do the following test: plug an re(4) interface into another host via crossover cable, and from the other host do 'ping -c 2 <host with re(4) NIC>' to prime the ARP cache, then do 'ping -c 1 -s 1473 <host with re(4) NIC>'. You're supposed to see two packets sent in response, but you may only see one. If you do 'ping -c 1 -s 1473 <host with re(4) NIC>' again, you'll see two packets, but one will be the missing fragment from the last ping, followed by one of the fragments from this ping.) - Add the PCI ID for the US Robotics 997902 NIC, which is based on the RTL8169S. - Add a tsleep() of 1 second in re_detach() after the interrupt handler is disconnected. This should allow any tasks queued up by the ISR to drain. Now, I know you're supposed to use taskqueue_drain() for this, but something about the way taskqueue_drain() works with taskqueue_fast queues doesn't seem quite right, and I refuse to be tricked into fixing it.
* Fix the following bugs in re(4)wpaul2006-07-301-19/+19
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | - Correct the PCI ID for the 8169SC/8110SC in the device list (I added the macro for it to if_rlreg.h before, but forgot to use it.) - Remove the extra interrupt spinlock I added previously. After giving it some more thought, it's not really needed. - Work around a hardware bug in some versions of the 8169. When sending very small IP datagrams with checksum offload enabled, a conflict can occur between the TX autopadding feature and the hardware checksumming that can corrupt the outbound packet. This is the reason that checksum offload sometimes breaks NFS: if you're using NFS over UDP, and you're very unlucky, you might find yourself doing a fragmented NFS write where the last fragment is smaller than the minimum ethernet frame size (60 bytes). (It's rare, but if you keep NFS running long enough it'll happen.) If checksum offload is enabled, the chip will have to both autopad the fragment and calculate its checksum header. This confuses some revs of the 8169, causing the packet that appears on the wire to be corrupted. (The IP addresses and the checksum field are mangled.) This will cause the NFS write to fail. Unfortunately, when NFS retries, it sends the same write request over and over again, and it keeps failing, so NFS stays wedged. (A simple way to provoke the failure is to connect the failing system to a network with a known good machine and do "ping -s 1473 <badhost>" from the good system. The ping will fail.) Someone had previously worked around this using the heavy-handed approahch of just disabling checksum offload. The correct fix is to manually pad short frames where the TCP/IP stack has requested checksum offloading. This allows us to have checksum offload turned on by default but still let NFS work right. - Not a bug, but change the ID strings for devices with hardware rev 0x30000000 and 0x38000000 to both be 8168B/8111B. According to RealTek, they're both the same device, but 0x30000000 is an earlier silicon spin.
* Properly detect the RTL8168(B?) again. RealTek sent me a bunch of samplewpaul2006-06-281-1/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | cards: the chips are all marked "RTL8111B", but they put stickers on the back that say "RTL8168B/8111B". The manual says there's only one HWREV code for both the 8111B and 8168B devices, which is 0x30000000, but the cards they sent me actually report HWREV of 0x38000000. Deciding to trust the hardware in front of me rather than a possibly incorrect manual (it wouldn't be the first time the HWREVs were incorrectly documented), I changed the 8168 revision code. It turns out this was a mistake though: 0x30000000 really is a valid for the 8168. There are two possible reasons for there to be two different HWREVs: 1) 0x30000000 is used only for the 8168B and 0x38000000 is only for the 8111B. 2) There were 8111/8168 rev A devices which both used code 0x30000000, and the 8111B/8168B both use 0x38000000. The product list on the RealTek website doesn't mention the existence of any 8168/8111 rev A chips being in production though, and I've never seen one, so until I get clarification from RealTek, I'm going to assume that 0x30000000 is just for the 8168B and 0x38000000 is for the 8111B only. So, the HWREV code for the 8168 has been put back to 0x30000000, a new 8111 HWREV code has been added, and there are now separate entries for recognizing both devices in the device list. This will allow all devices to work, though if it turns out I'm wrong I may need to change the ID strings
* Fix breakage of CHIP_I855 in the last revision.anholt2006-06-271-3/+4
| | | | Submitted by: Ted Faber <faber@ISI.EDU>
* Add support for the RealTek 8169SC/8110SC and RTL8101E devices. Thewpaul2006-06-261-17/+68
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | latter is a PCIe 10/100 chip. Finally fix the EEPROM reading code so that we can access the EEPROMs on all devices. In order to access the EEPROM, we must select 'EEPROM programming' mode, and then set the EEPROM chip select bit. Previously, we were setting both bits simultaneously, which doesn't work: they must be set in the right sequence. Always obtain the station address from the EEPROM, now that EEPROM reading works correctly. Make the TX interrupt moderation code based on the internal timer optional and turned off by default. Make the re_diag() routine conditional and off by default. When it is on, only use it for the original 8169, which was the only device that that really needed it. Modify interrupt handling to use a fast interrupt handler and fast taskqeueue. Correct the rgephy driver so that it only applies the DSP fixup for PHY revs 0 and 1. Later chips are fixed and don't need the fixup. Make the rgephy driver advertise both 1000_FD and 1000_HD bits in autoneg mode. A couple of the devices don't autoneg correctly unless configured this way.
* Replace the three copies of the list of pci ids with a single centralized list.anholt2006-06-251-143/+122
| | | | | Add the i945 PCI IDs commented out -- I think it should just work, but it hasn't been tested yet.
* Move SiS 760 to where it belongs.jkim2006-05-302-2/+2
| | | | | PR: 98094 Submitted by: Mike M < mmcgus at yahoo dot com >
* Rename device name in the last commit. According to PR, the ID isglebius2006-05-241-2/+2
| | | | | | | more likely to belong to chips of 8168 family. PR: kern/96734 Submitted by: Sven Petai <hadara bsd.ee>
* Add support for allocating one larger than page-sized contiguous block of memoryanholt2006-05-161-26/+110
| | | | | with a physical address. This is used for hardware ARGB cursor support on newer chipsets.
* Since DELAY() was moved, most <machine/clock.h> #includes have beenphk2006-05-164-4/+0
| | | | unnecessary.
* Replace references to lnc(4) with references to le(4) (so far the notesmarius2006-05-151-4/+4
| | | | | still apply to le(4)) now that lnc(4) is removed and le(4) is going to replace it.
* Remove various bits of conditional Alpha code and fixup a few comments.jhb2006-05-129-51/+0
|
* The sk(4) driver has moved to /sys/dev/skyongari2006-04-274-5146/+0
|
* Add support for RTL8111B chip, that can be found on some mainboards,glebius2006-03-221-0/+2
| | | | | | for example ASUS P5PL2. Tested by: Vadim Frolov <vadim uch.net>
* Remove de driver from old location.imp2006-02-263-6580/+0
|
* Add support for the Intel E7205 chipset.anholt2006-02-171-0/+6
| | | | | PR: kern/91315 Submitted by: Joerg Pulz <Joerg.Pulz@frm2.tum.de>
* Do not touch ifp->if_baudrate in miibus aware drivers.glebius2006-02-149-10/+0
|
* Don't add an agp child in vgapci's attach routine if the PCIY_AGPjhb2006-02-011-0/+10
| | | | | | | capability is present as not all devices supported by the agp_i810 driver (such as i915) have the AGP capability. Instead, add an identify routine to the agp_i810 driver that uses the PCI ID to determine if it should create an agp child device.
* Check ifp before dereferencing it in xl_detach(). xl_detach() can be calledglebius2006-01-181-1/+1
| | | | | | from xl_attach(), when ifp is not defined yet. Found with: Coverity Prevent(tm)
* Fix a memory leak I introduced with the hostb/vgapci stuff.jhb2006-01-171-4/+8
| | | | Reported by: Coverity (via dfr's clue-bat)
* The number of ticks per usec for YUKON_EC is 125.yongari2006-01-171-1/+1
|
* fix interrupt moderation timer frequencies for Yukonyongari2006-01-172-7/+21
| | | | Obtained from: OpenBSD
* remove trailing spacesyongari2006-01-171-11/+11
|
* Remove unused code.bz2006-01-151-3/+0
| | | | Found with: Coverity Prevent(tm)
* Use the copy of the card's MAC address saved in tulip_enaddr() in the softcjhb2005-12-221-3/+12
| | | | | | | if we need a valid MAC address (for probing the media for example) before ether_ifattach() has been called since IF_LLADDR() is NULL then. Tested by: tisco
* Drivers for AMD-8111 and NVIDIA nForce2/3/4 SMBus 2.0 controllers.ru2005-12-212-0/+1077
|
* Use ETHER_ADDR_LEN rather than hardcoding 6.jhb2005-12-211-1/+1
|
* - Use PCIR_BAR() macro for the BAR for the aperture.jhb2005-12-201-7/+1
| | | | | - Axe macros used for walking PCI capabilities list. We now ask the PCI bus to find caps for us rather than doing it in the drm and agp drivers.
* - Bump FreeBSD version for the hostb(4) and vgapci(4) drivers as well asjhb2005-12-201-36/+4
| | | | | | | | | the addition of pci_find_extcap(). - Change the drm drivers to attach to vgapci. This is #ifdef'd so the code can be shared across branches. - Use pci_find_extcap() to look for AGP and PCIE capabilities in drm. - GC all the drmsub stuff for i810/i830/i915. The agp and drm devices are now both children of vgapci.
* Change the various AGP drivers that attach to the Host-PCI bridge device tojhb2005-12-208-16/+8
| | | | | | | | | attach to the hostb driver instead. This means that agp can now be loaded at runtime (in theory at least). Also, the drivers no longer have to explicity call device_verbose() to cancel out any earlier calls to device_quiet() by the hostb(4) driver (this shows a limitation in new-bus, drivers really shouldn't be doing device_quiet() until they know they are going to drive that device, i.e. in attach).
* Change the agp_find_device() to return the first agp device that has beenjhb2005-12-201-2/+11
| | | | attached to a driver rather than always returning agp0.
* Don't map the AGP aperture into contiguous KVA. The various graphicsjhb2005-12-202-4/+1
| | | | | | | | drivers already map sections into KVA as needed anyway. Note that this will probably break the nvidia driver, but I will coordinate to get that fixed. MFC after: 2 weeks
* Destroy the /dev device before destroying the mutex or releasing resourcesjhb2005-12-201-1/+2
| | | | | | rather than afterwards. MFC after: 1 week
* Use pci_find_extcap() to search for AGP capabilities (PCIY_AGP).jhb2005-12-201-25/+4
|
* Backout pseudo nForce2/3/4 support. These devices (as well asru2005-12-161-160/+25
| | | | | | | | | | | | | | AMD-8111 SMBus 2.0 controller) are all SMBus 2.0 controllers, and need another implementation of SMBus access methods, while this driver supports AMD-756 SMBus 1.0 controller and clones, including AMD-8111 SMBus 1.0 controller. Tested by: Vladimir Timofeev (0x006410de), mezz (0x008410de), ru (0x00d410de) All of us got the same(!) nonsense when running ``mbmon -S'', repeated every four rows.
* Fix PCI ID of the AMD-8111 System Management controller so it matchesru2005-12-161-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | SMBus 1.0 and not SMBus 2.0. AMD-8111 hub (datasheet is publically available) implements both SMBus 2.0 (a separate PCI device) and SMBus 1.0 (a subfunction of the System Management Controller device with the base I/O address is accessible through the CSR 0x58). This driver only supports AMD-756 SMBus 1.0 compatible devices. With the patched sysutils/xmbmon port (to also fix PCI ID and to enable smb(4) support), I now get: pciconf: none0@pci0:7:2: class=0x0c0500 card=0x746a1022 chip=0x746a1022 rev=0x02 hdr=0x00 vendor = 'Advanced Micro Devices (AMD)' device = 'AMD-8111 SMBus 2.0 Controller' class = serial bus subclass = SMBus amdpm0@pci0:7:3: class=0x068000 card=0x746b1022 chip=0x746b1022 rev=0x05 hdr=0x00 vendor = 'Advanced Micro Devices (AMD)' device = 'AMD-8111 ACPI System Management Controller' class = bridge dmesg: amdpm0: <AMD 756/766/768/8111 Power Management Controller> port 0x10e0-0x10ff at device 7.3 on pci0 smbus0: <System Management Bus> on amdpm0 # mbmon -A -d Summary of Detection: * SMB monitor(s)[ioctl:AMD8111]: ** Winbond Chip W83627HF/THF/THF-A found at slave address: 0x50. ** Analog Dev. Chip ADM1027 found at slave address: 0x5C. * ISA monitor(s): ** Winbond Chip W83627HF/THF/THF-A found. I think the confusion comes from the fact that nobody really tried SMBus with xmbmon :-), since sysutils/xmbmon port doesn't come with SMBus support enabled, neither in FreeBSD 4, nor in later versions, so mbmon(1) was just showing the values from the Winbond sensors accessible through the ISA I/O method (mbmon -I), for me anyway. On my test machine, the amdpm(4) didn't even attach due to I/O port allocation failure (who knows what the hell it read from CSR 0x58 of the SMBus 2.0 device :-), which isn't in the CSR space). I've also checked that lm_sensors.org uses correct PCI ID for SMBus 1.0 of AMD-8111: i2c-amd756.c: {PCI_VENDOR_ID_AMD, 0x746B, PCI_ANY_ID, PCI_ANY_ID, 0, 0, AMD8111 }, This driver is analogous to our amdpm.c which supports SMBus 1.0 AMD-756 and compatible devices, including SMBus 1.0 on AMD-8111. i2c-amd8111.c: { 0x1022, 0x746a, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0 }, This driver is analogous to nForce-2/3/4, i2c-nforce2.c, which supports SMBus 2.0, and which our amdpm.c does NOT support (SMBus 2.0 uses a different, ACPI-unified, API to talk to SMBus). At least I know for sure it doesn't work with my nForce3. :-) (The xmbmon port will be fixed to correct the PCI ID too and to enable the smb(4) support.)
* Add support for the nForce2/3/4 SMBus controllers which all contain twojhb2005-12-141-25/+160
| | | | | | | SMBus busses. Because of limitations in smbus_if.m, the second smbus is attached to an amdpm1 device that is a child of amdpm0. Submitted by: Artemiev Igor ai (at) bmc dot brk dot ru
* The if_ti Tigon I/II driver has moved to /sys/dev/tiscottl2005-12-104-14450/+0
|
* Fix -Wundef from compiling the amd64 LINT.ru2005-12-041-4/+4
|
* Add support for i915 GMCH AGP. This diff is a combination of work by myselfanholt2005-12-022-31/+160
| | | | | | | | | | | and some fixes from Motomichi Matsuzaki. Testing involved many people, but the final, successful testing was from rwatson who endured several rounds of "it crashes at XYZ stage" "oh, please correct this typo and try again." The Linux driver, and to a small extent the limited specs, were both used as a reference for how to program the chipset. PR: kern/80396 Submitted by: Martin Mersberger
* Fix the type of "eaddr" to guarantee the required alignment.ru2005-12-011-8/+8
| | | | Suggested by: marcel
* Byte copy IF_LLADDR() on stack to align it to be safe for typecasts.ru2005-11-302-21/+20
| | | | Tested by: jhb
* Add support for the i855GM, tested by an r300 user.anholt2005-11-291-1/+6
|
OpenPOWER on IntegriCloud