Date: Tue, 7 Sep 1999 03:11:24 -0400 (EDT) From: Bill Paul <wpaul@skynet.ctr.columbia.edu> To: thorpej@nas.nasa.gov Cc: thorpej@nas.nasa.gov, wes@softweyr.com, hackers@freebsd.org Subject: Re: Tulip device driver question Message-ID: <199909070711.DAA05781@skynet.ctr.columbia.edu> In-Reply-To: <199909061949.MAA02493@lestat.nas.nasa.gov> from "Jason Thorpe" at Sep 6, 99 12:49:17 pm
next in thread | previous in thread | raw e-mail | index | archive | help
Of all the gin joints in all the towns in all the world, Jason Thorpe had to walk into mine and say: > On Fri, 03 Sep 1999 16:23:00 -0600 > Wes Peters <wes@softweyr.com> wrote: > > > > > See, for instance, the al, ax, mx, pn, vr, and wb drivers. ;^) > > > ^^ > > > Especially this one.. it's not a Tulip clone :-) > > > > Oh? vr(4) disagrees: > > > > The VIA Rhine chips use bus master DMA and have a software interface de- > > signed to resemble that of the DEC 21x4x "tulip" chips. > > I don't care what the manual page says; take a look at the respective > programming manuals for the chips. Hell, take a look at if_vrreg.h and > if_pnreg.h. The vast differences are *very* obvious. > > Really, the only thing that's even vaguely similar is that both of them > use chained descriptors which are 16 bytes long, with similar layout (but > not compatible bits within each longword). It sure looks to me like somebody was trying to duplicate the tulip descriptor layout though. No, it's not an exact copy, but there is a pretty close resemblance. > The registers are totally different. True. > ...tho, I guess he did say "resemble" ... The SiS 900 "resembles" a Tulip, > too (uses chained descriptors!), and the Tulip "resembles" the DEC SGEC > (a lot more than the Rhine "resembles" the Tulip, tho :-) The SiS 900 only has one combined status/control word in its descriptor structure (some of the bits mean different things depending on whether the descriptors are in the RX ring or TX ring) instead of a separate status and control word. The descriptors are also only 3 longwords in size. > The various Tulip clones are actually somewhat close to Tulips (e.g. same > registers, for the most part, same bits in the registers), and can be driven > by the same driver, with various special cases in them for the (usually slight) > differences [this is the approach I'm taking in NetBSD; why Bill didn't write > a single driver for all the clones I'm not sure I'll ever know...] I thought about that. But after seeing just how many tulip workalikes there are and just how many differences and peculiarities there were, I decided that I just couldn't combine everything into one driver and keep it all working right without the code ending up looking really ugly. There are also more than just a few slight differences between chipsets. Some of them have the standard tulip receive filter mechanism (DMA the setup frame via the TX DMA engine). Some of them have just a couple of registers to program, but there are at least three different variations of this. At least one of them uses the DEC RX filter scheme but with only a 128 bit multicast hash table (the PNIC II -- damned if I know why they did that). The ones that use only the register programming method only have a 64 bit hash table. At least one of them has its registers spaced only 4 bytes apart instead of 8 (the Winbond). Some of them can have either an MII transceiver accessed via an MDIO bit-bang interface, or a serial transceiver. Some of them have built-in MII-like transceivers, but out of those, some of them use the bit-bang interface while others let you access the PHY registers directly. Some of them have built-in NWAY implemented without using an MII-like interface (PNIC, Macronix). Some of them have built-in NWAY designed to look like an MII interface (Macronix 98713) while the next revision up uses custom registers (Macronix 98713A). Some of them have built-in NWAY that doesn't work right (PNIC 82c168). Some of them use the standard DEC serial I/O interface to access the EEPROM. Some of them have custom registers (PNIC). Some of them have bugs that require some off the wall software workarounds (PNIC, Winbond, Davicom). Some of them obey the DEC SROM spec. Some don't. Many of them have additional custom registers for various purposes usually related to wake on lan. And that's just the PCI devices: who knows what other oddities will turn up once we have cardbus support. (And we will have cardbus support some day soon, right Warner? Hello? Warner? You okay? Hm. Somebody want to call an ambulance for Warner? Thank you. Breathe, Warner. _Breathe._ That's better.) Is it possible to cram all this stuff into one driver? Well, sure: the Linux tulip driver does it, although I can't say whether or not the Linux driver handles all of the supported cards correctly all of the time. Could you do it? Sure, why not. Could *I* do it? I don't think so, at least not in an elegant fashion. I can only handle one catastrophe at a time. -Bill -- ============================================================================= -Bill Paul (212) 854-6020 | System Manager, Master of Unix-Fu Work: wpaul@ctr.columbia.edu | Center for Telecommunications Research Home: wpaul@skynet.ctr.columbia.edu | Columbia University, New York City ============================================================================= "It is not I who am crazy; it is I who am mad!" - Ren Hoek, "Space Madness" ============================================================================= To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199909070711.DAA05781>