summaryrefslogtreecommitdiffstats
path: root/sys/pci
Commit message (Collapse)AuthorAgeFilesLines
* Make some cleanups related to miibus.wpaul1999-08-271-47/+21
|
* Convert the ThunderLAN driver to miibus. This took me a while because Iwpaul1999-08-272-878/+115
| | | | | | | | | | | | | | | | | | | | | | | | | | had to get the ML 6692 PHY driver working correctly, which is harder than it sounds. "Bitrate" ThunderLAN devices should still be supported (i.e the older 10Mbps Netflex 3/P, which use the TNETE110 chip that has no MII support). The ThunderLAN has an internal PHY which makes things a little complicated, but these are the basic rules: - For devices with just the ThunderLAN, the internal PHY is used to provide 10baseT, and 10base5/10baseT support. Autonegotiation will work, but only with 10baseT links. The only thing that really gets negotiated is whether the link is full or half duplex. - For devices with the ThunderLAN and an external 10/100 PHY (like the Compaq Netelligent 100Mbps cards, or the internal Netflex 3/P with 100Mbps upgrade daughter card), the external PHY is used for 10baseT and 100baseTX modes. The internal PHY is still used to support 10base5/10base2, though you have to select them manual with ifconfig. - For devices with the ThunderLAN and the ML6692 PHY, both the internal and external PHYs are used, though it will appear as though the 6692 PHY will be used to support 10baseT and 100baseTX modes. In reality, the internal PHY will be used for 10baseT, but this fact will be hidden from the user. The 10base5/10base2 modes can also be selected manually as with above.
* Properly re-enable the transmitter in the TX error handler.wpaul1999-08-261-5/+3
|
* Change PN_RXLEN from 1518 bytes to 1536 bytes. The chip always DMAs datawpaul1999-08-242-6/+6
| | | | | | | | | | | | | | | | | | in 4 byte chunks. It turns out that with the 82c169C on the Netgear FA-310TX Rev D2, if you tell the chip you have reserved a buffer of 1518 bytes, it will actually treat it as 1516 bytes since 1518 is divisible by four. Consequently, a packet of 1514 bytes will always end up consuming two buffers: the last coupleof bytes will spill over into the next descriptor. This causes the pn_rx_bug_war() routine to trip unnecessarily. I'm not sure if the 82c169B or 82c168 chips behave the same way; I'll have to check them. In any case, this change should work just as well with them. Note that the FA-310TX Rev D2 also has a Broadcom PHY instead of a Level One LXT970 PHY, however this shouldn't make any difference as far as the driver is concerned. This change also allows me to do a way with one rounding overation in pn_rx-buf_war().
* Cast pointers to uintptr_t instead of casting them to u_long, and/or vicebde1999-08-242-5/+5
| | | | versa. Cosmetic.
* Reset the UHCI controller when the device comes back from suspend.n_hibma1999-08-231-6/+33
| | | | | | | This should be replaced by proper support for suspend one day (global suspend). Submitted-by: Christopher Masto <chris@netmonger.net>
* Convert DEVFS hooks in (most) drivers to make_dev().phk1999-08-236-69/+20
| | | | | | | | | | | | | | | | Diskslice/label code not yet handled. Vinum, i4b, alpha, pc98 not dealt with (left to respective Maintainers) Add the correct hook for devfs to kern_conf.c The net result of this excercise is that a lot less files depends on DEVFS, and devtoname() gets more sensible output in many cases. A few drivers had minor additional cleanups performed relating to cdevsw registration. A few drivers don't register a cdevsw{} anymore, but only use make_dev().
* Slightly sanitize the isa/eisa bridge detection. The pci->eisa bridgepeter1999-08-221-13/+9
| | | | logic (I use the term loosely) was a bit whacky.
* Clean up after removing sys/eventhandler.h from sys/systm.h at the lastmsmith1999-08-216-6/+14
| | | | | minute. This should cover all of the missed cases (and should let LINT build again).
* Add missing include.billf1999-08-211-0/+1
| | | | | Submitted by: Mitsuru IWASAKI <iwasaki@jp.FreeBSD.org> Reviewed by: Alex Perel <veers@disturbed.net>
* Remove MII/PHY related junk from here. It's not needed anymore.wpaul1999-08-211-106/+1
|
* This commit adds device driver support for the Sundance Technologies ST201wpaul1999-08-212-0/+2284
| | | | | | | | | | | | | PCI fast ethernet controller. Currently, the only card I know that uses this chip is the D-Link DFE-550TX. (Don't ask me where to buy these: the only cards I have are samples sent to me by D-Link.) This driver is the first to make use of the miibus code once I'm sure it all works together nicely, I'll start converting the other drivers. The Sundance chip is a clone of the 3Com 3c90x Etherlink XL design only with its own register layout. Support is provided for ifmedia, hardware multicast filtering, bridging and promiscuous mode.
* Implement a new generic mechanism for attaching handler functions tomsmith1999-08-217-32/+39
| | | | | | | | | | | | | events, in order to pave the way for removing a number of the ad-hoc implementations currently in use. Retire the at_shutdown family of functions and replace them with new event handler lists. Rework kern_shutdown.c to take greater advantage of the use of event handlers. Reviewed by: green
* Fix power management register definitions.wpaul1999-08-211-5/+5
|
* Replace the tulip_delay_300ns() with a DELAY(1). Hammering the PCI buspeter1999-08-191-11/+2
| | | | | | | | | | | | | | | | | | | | | | | to achieve a delay is pretty mean. Andrew reports: "The tulip_delay_300ns() is, well, bloody stupid on machines with a heavily loaded PCI bus. It tries to do a delay by assuming PCI reads will take a certain amount of time & issues a large amount of (expensive, 5% CPU when your PCI bus is heavily loaded) pci reads. Locally, we've replaced the calls to tulip_delay_300ns(sc) in the EMIT macros with a simple DELAY(1) and not seen any problems. Plus we've gained about 50Mb/sec throughput on our gigabit network cards because of the added PCI bus bandwidth available." Also, I do not understand why, but this change appears to stop the Transmit Fifo underrun on one of my systems (but not the Alpha PC164SX). This shouldn't make that much of a difference since the mii bus isn't touched all that often, but perhaps when it does get accessed and hence hammers the register, it was causing the chip to get upset. Submitted by: Andrew Gallatin <gallatin@cs.duke.edu>
* Small tweak: in xl_rxeof(), rxstat should be u_int32_t, not u_int16_t.wpaul1999-08-191-3/+3
|
* 1) rename dev->self to be consistentn_hibma1999-08-182-76/+107
| | | | | 2) use device_printf 3) properly tear down and disable interrupts when init fails
* Differentiate between aic7895C chips and their earlier brethrengibbs1999-08-161-2/+6
| | | | via the PCI revid register.
* Set some correct return values. Prefer I/O map all the time unless configuredmjacob1999-08-161-13/+20
| | | | otherwise.
* Fix a long standing bug in the auto-termination control settings forgibbs1999-08-161-8/+9
| | | | | | | | | | | | the aic7890/91/96/97 cards. This could cause the system to go into a long retry/recovery loop during probe. Fix the alignment argument to bus_dma_tag_create(). Don't set the CACHETHEN bit in dscommand0 for Ultra2 controllers until we know more about its behavior. The description for this bit makes it sound like it could cause problems with certain PCI chipsets.
* Properly set the alignment argument to bus_dma_tag_create(). If wegibbs1999-08-167-13/+15
| | | | don't care about the alignment, set it to 1, meaning single byte alignment.
* Minor glitch in ti_newbuf_jumbo(): m_adj() was being called onwpaul1999-08-141-3/+3
| | | | | | m instead of m_new. Submitted by: Kenneth D. Merry <ken@kdm.org>
* Small tweak: remember to free the tx ring data (which is malloc()ed) ifwpaul1999-08-101-2/+3
| | | | we have to bail out of vr_attach().
* Convert the Winbond driver to newbus and have it compiled as a module.wpaul1999-08-102-83/+146
|
* Convert the VIA Rhine driver to newbus and set it up to be compiled aswpaul1999-08-102-103/+182
| | | | | | | | | | a module. Also modified the code to work on FreeBSD/alpha and added device vr0 to the alpha GENERIC config. While I was in the neighborhood, I noticed that I was still using #define NFPX 1 in all of the Makefiles that I'd copied from the fxp module. I don't really use #define Nfoo X so it didn't matter, but I decided to customize this correctly anyway.
* Add support for the Am79C978. (AMD PCHome/PCI Ethernet adapter)mdodd1999-08-101-1/+5
| | | | | | | See: http://www.amd.com/products/npd/overview/homenetworking/intro.html PR: kern/12275 Submitted by: Robert Watson <robert@cyrus.watson.org>
* chip0: <PCI to 0x80 bridge (vendor=10e0 device=8849)> at device 0.0 on pci0mdodd1999-08-091-1/+2
| | | | | | | | | | | | Isn't really that useful. chip0: <PCI to Other bridge (vendor=10e0 device=8849)> at device 0.0 on pci0 is more in keeping with the spirit of the rest of the code. Previous behavior with regard to truely unknown bridges unchanged. "<Anti-Bill> Tell you what: you have commit privs now. You do it."
* A little more tidying up.peter1999-08-092-63/+22
|
* Expand a heap of macros that obscure readability and are no longer neededpeter1999-08-092-237/+122
| | | | here, and do a bit of general tidy up.
* More pre-lite2 support zapped and some more tidy-up.peter1999-08-092-74/+1
|
* Unifdef -D__FreeBSD__ - and remove pre-lite2 support.peter1999-08-092-115/+12
|
* Unifdef -U__NetBSD__peter1999-08-092-258/+1
|
* Unifdef -U__bsdi__peter1999-08-092-305/+4
|
* s/Id/FreeBSD/peter1999-08-093-3/+6
|
* Strip __FreeBSD_version >= 300000 conditionals.peter1999-08-092-32/+9
|
* Merge changes from NetBSD rev 1.82 -> 1.86 via vendor branch.peter1999-08-091-15/+102
| | | | Among the changes: 1.84: support compex 4-port cards.
* s/TULUP/TULIP/ - from vendor branch.peter1999-08-081-3/+3
|
* Minor tweak for last commit: insert extra delay between issuing masterwpaul1999-08-021-2/+4
| | | | reset and RX/TX resets.
* Perform an RX reset and TX reset in xl_reset() along with the masterwpaul1999-08-021-6/+23
| | | | | | | | | | | | | | | | | | | | | | | | | | | reset command. I observed some anomalous behavior while testing a 3c905C with a Dell PowerEdge 4300/500 dual PIII 500Mhz system. The NIC would seem to work correctly most of the time but would sometimes fail to receive certain packets, in particular NFS create requests. I could mount an NFS filesystem from the PowerEdge and do an ls on it, but trying to do a "touch foo" would hang. Monitoring traffic from another host revealed that the client was properly sending an NFS create request but the server was not receiving it. It *did* receive it when I ran the same test with an Intel fxp card. I don't understand the exact mechanics of this strange behavior, but resetting the receiver and transmitter seems to get rid of it. I used to perform an RX and TX reset in xl_init(), but stopped doing it there because on 3c905B and later cards this causes the autoneg session to restart, which would lead to the NIC waiting a long time before exchanging traffic after being brought up the first time. Apparently the receiver and transmitter resets should be performed at least once when initializing the card. Hopefully this will cure problems that people have been having with the 3c905C -- this was the only strange behavior that I have observed with the 3c905C so far which does not appear with the 3c905B or 3c905.
* Alter the behavior of sys/kern/subr_bus.c:device_print_child()mdodd1999-07-295-45/+21
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | - device_print_child() either lets the BUS_PRINT_CHILD method produce the entire device announcement message or it prints "foo0: not found\n" Alter sys/kern/subr_bus.c:bus_generic_print_child() to take on the previous behavior of device_print_child() (printing the "foo0: <FooDevice 1.1>" bit of the announce message.) Provide bus_print_child_header() and bus_print_child_footer() to actually print the output for bus_generic_print_child(). These functions should be used whenever possible (unless you can just use bus_generic_print_child()) The BUS_PRINT_CHILD method now returns int instead of void. Modify everything else that defines or uses a BUS_PRINT_CHILD method to comply with the above changes. - Devices are 'on' a bus, not 'at' it. - If a custom BUS_PRINT_CHILD method does the same thing as bus_generic_print_child(), use bus_generic_print_child() - Use device_get_nameunit() instead of both device_get_name() and device_get_unit() - All BUS_PRINT_CHILD methods return the number of characters output. Reviewed by: dfr, peter
* Add support for SYS_RES_DENSE and SYS_RES_BWX resource types. These aredfr1999-07-282-30/+34
| | | | | | | | | equivalent to SYS_RES_MEMORY for x86 but for alpha, the rman_get_virtual() address of the resource is initialised to point into either dense-mapped or bwx-mapped space respectively, allowing direct memory pointers to be used to device memory. Reviewed by: Andrew Gallatin <gallatin@cs.duke.edu>
* Convert the PNIC driver to newbus.wpaul1999-07-282-167/+223
|
* Roar! Finish what I started last night: somehow only the header file changewpaul1999-07-271-5/+23
| | | | got committed.
* Case matters.mdodd1999-07-271-3/+3
| | | | DEv_METHOD to DEV_METHOD.
* Implement the BUS_PROBE_NOMATCH method for the PCI bus.mdodd1999-07-271-1/+32
| | | | | | | | | | | | | | | | | | | | | | | | This function is called for each device for which no driver was found. Output is similar to the eisa_probe_nomatch() function but with the added benefit of displaying the assigned IRQ (since PCI gives us this information up front.) Output is like so: pci0: unknown card CPQ0508 (vendor=0x0e11, dev=0x0508) at 11.0 irq 9 pci0: unknown card DFZ0508 (vendor=0x10da, dev=0x0508) at 11.0 irq 9 pci0: unknown card DBL0508 (vendor=0x104c, dev=0x0508) at 11.0 irq 9 pci0: unknown card DDM0011 (vendor=0x108d, dev=0x0011) at 11.0 irq 9 I'm not happy with the 3 lines of macro cruft that got added but I consider it a temporary annoyance as those bits will be moved to some place where PCI, EISA and ISAPNP code will be able to use them. (Not surprisingly, this message is longer than the code in question.) Reviewed by: peter, dfr
* On FreeBSD/i386, when you use the SYS_RES_MEMORY resource to allocatewpaul1999-07-271-1/+2
| | | | | | | | | | | | | | | | | | | | | | | a PCI memory mapped region, rman_get_bushandle() returns what happens to be a kernel virtual address pointing to the base of the PCI shared memory window. However this is not the behavior on all platforms: the only thing you should do with the bushandle is pass it to the bus_spare_read()/bus_space_write() routines. If you actually do want the kernel virtual address of the base of the PCI memory window, you need to use rman_get_virtual(). The problem is that at the moment, rman_get_virtual() returns a physical address, which is bad. In order to get the kernel virtual address we need, we have to play with it a little. Presumeably this behavior will be changed, but in the meantime the Tigon driver won't work. So for the moment, I'm adding a kludge to make things happy on the alpha: the correct kernel virtual address is calculated from the value returned by rman_get_virtual(). This should be removed once rman_get_virtual() starts doing the right thing. This should make the Tigon actuall work on the alpha now.
* Make this compile on the Alpha. I'm not 100% sure about this but Ipeter1999-07-251-19/+2
| | | | | think it's ok. ti_bhandle is fetched from newbus on both the Alpha and x86, the Alpha-only ti_vhandle is gone.
* Remember to clear the IFF_RUNNING and IFF_OACTIVE flags in sf_stop() andwpaul1999-07-252-4/+13
| | | | sk_stop().
* This commit adds device driver support for Adaptec Duralink PCI fastwpaul1999-07-252-0/+3008
| | | | | | | | | | | | | | | | | | | | | ethernet controllers based on the AIC-6915 "Starfire" controller chip. There are single port, dual port and quad port cards, plus one 100baseFX card. All are 64-bit PCI devices, except one single port model. The Starfire would be a very nice chip were it not for the fact that receive buffers have to be longword aligned. This requires buffer copying in order to achieve proper payload alignment on the alpha. Payload alignment is enforced on both the alpha and x86 platforms. The Starfire has several different DMA descriptor formats and transfer mechanisms. This driver uses frame descriptors for transmission which can address up to 14 packet fragments, and a single fragment descriptor for receive. It also uses the producer/consumer model and completion queues for both transmit and receive. The transmit ring has 128 descriptors and the receive ring has 256. This driver supports both FreeBSD/i386 and FreeBSD/alpha, and uses newbus so that it can be compiled as a loadable kernel module. Support for BPF and hardware multicast filtering is included.
* Convert the ASIX and Macronix drivers to newbus.wpaul1999-07-244-341/+384
|
OpenPOWER on IntegriCloud