Date: Sun, 8 Sep 1996 23:31:13 -0700 (PDT) From: "Rodney W. Grimes" <rgrimes@GndRsh.aac.dev.com> To: se@zpr.uni-koeln.de (Stefan Esser) Cc: se@zpr.uni-koeln.de, rgrimes@freefall.freebsd.org, CVS-committers@freefall.freebsd.org, cvs-all@freefall.freebsd.org, cvs-sys@freefall.freebsd.org Subject: Re: cvs commit: src/sys/pci pcisupport.c Message-ID: <199609090631.XAA17591@GndRsh.aac.dev.com> In-Reply-To: <199609061854.UAA17465@x14.mi.uni-koeln.de> from Stefan Esser at "Sep 6, 96 08:54:54 pm"
next in thread | previous in thread | raw e-mail | index | archive | help
> Rodney W. Grimes writes: > > > > Well, I did make sure I got that right, > > > but the #if defined (Ix86_CPU) will all > > > go away again, since it was an outright > > > silly idea ... > > > > Not really a silly idea, just the implementation of how it is makes > > it kinda messy, not that I have a better way to do it :-(. I'll > > think on it for a while... > > No, my idea was to have a few KB less of kernel bloat, > by only having the relevant descriptions in a custom > kernel. But P5 type processors go into 486 motherboards > (PODP) and 386 type processors (Cyrix 6x86) into P5 > boards, and a few support chip are shared between > several chip set families (the Triton II and Natoma > both use the PIIX3). Some 3/4 of the definitions will > go in, anyway, if the #ifdefs are CPU specific. And > I'd rather not have a CPU socket (I486_SOCKET, ... :) > define just to get rid of a few KB of tables. Okay, this portion of your recent changes has been backed out. > > Okay. This simplifies my next round of patches a lot, I'll wait until > > after this is cleaned up. > > > > > I'll back those changes out, if you don't > > > beat me on it (which shouldn't be too hard > > > given your much better connectivity to > > > Freefall :) > > > > If you don't get to it today, I'll probably back them out tomarrow some > > time. Oh, and are you doing any more major work in there? I want to > > do some reorg and major comment cleanup (I'll pass a diff by the list > > first). Then I will be adding full register dump support for 439HX, > > 440FX and associated functions/chips (got to figure out how to get > > the USB function of the 82371SB turned on first though :-)). Got that figured out on Natoma, but for some reason the T2 boards don't have it turned on, nor can I find a way to turn it on easily (probably because ASUS left off the USB connector on the PCI/I-P55T2P4 board, though there are pads to solder one on. Guess I'll have to disassemble the BIOS and add a chunk of code to initialize it... :-( > > Regarding the pure informational output generated by > pcisupport: > > Feel free to do whatever you want. If you are going to > work on this, then I'll let you take out the #ifdefs, too, > since you most probably will rearrange the different cases > again. (I moved a few to group them by CPU type, but this > does not seem to make too much sense any more ...) I just removed the #ifdefs for now, that cut the diff down between -current and -stable so that I can try and get them synced (I have to support clients on -stable, and some of the things I am doing in here is for them). Once I get them synced I am going to take a good hard look at pcisupport.c and do some thinking about what the best way is to product full pci configuration space dumps for the following chip sets: Aries, Saturn-II, Triton-I, Triton-II, Natoma and Orion (I have all of these inhouse except the Saturn-II) along with the data books. Also the DEC PCI-PCI bridge, and more complete stuff for the standard PCI configuration header area common to classes of PCI functions(devices). One though that just came to mind was perhaps split pcisupport.c into 2 files, moving the long detailed register dumps into pcichipsets.c and leaving the otherstuff behind. This detailed file could be included via a config option, or perhaps even moved to user land as a PCI register dump utility. Anyone have thoughs on that? > The chip set register dump code went in when I was curious > about my Saturn chips configuration, since I had heard that > some VGA BIOS might turn off burst mode without telling. > And after I found that this doesn't happen on my system, I > only left it in because I assumed other people might be as > curious as I :) Some of us out here are very interested in the state of chipset registers for similiar reasons, like just what it takes to get the extended caching turned on with Triton-II boards and WTF SMC has done on the 8434 dual 21040 board with 21050 bridge when it gomes to the interrupt mapping. > > But I plan to radically change the PCI code based on last > years experiences. Most of the special case handling can go, > but Subvendor ID support has to be added (though I don't know > any card that actually uses that feature, currently) and the > bridge chip support has to be changed a lot. (And then there > will finally be some config support for PCI, too, and ressource > checking with other buses ...) Good, that area could use some work... > I already have a concept for this, and if you intend to change > the actual probe/attach, I'd like to know about your plans early ... No, I don't currently plan to change the probe/attaching code, though I do plan to rewrite the ``Catchall driver'' for VGA devices, it should be able to report the vendor, and return something meaniful for prehistoric devices. -- Rod Grimes rgrimes@gndrsh.aac.dev.com Accurate Automation Company Reliable computers for FreeBSD
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199609090631.XAA17591>