freebsd-skq/sys/pci/pcisupport.c

926 lines
28 KiB
C
Raw Normal View History

/**************************************************************************
**
** $Id: pcisupport.c,v 1.52 1997/08/10 09:33:21 phk Exp $
**
** Device driver for DEC/INTEL PCI chipsets.
**
** FreeBSD
**
**-------------------------------------------------------------------------
**
** Written for FreeBSD by
** wolf@cologne.de Wolfgang Stanglmeier
** se@mi.Uni-Koeln.de Stefan Esser
**
**-------------------------------------------------------------------------
**
** Copyright (c) 1994,1995 Stefan Esser. All rights reserved.
**
** Redistribution and use in source and binary forms, with or without
** modification, are permitted provided that the following conditions
** are met:
** 1. Redistributions of source code must retain the above copyright
** notice, this list of conditions and the following disclaimer.
** 2. Redistributions in binary form must reproduce the above copyright
** notice, this list of conditions and the following disclaimer in the
** documentation and/or other materials provided with the distribution.
** 3. The name of the author may not be used to endorse or promote products
** derived from this software without specific prior written permission.
**
** THIS SOFTWARE IS PROVIDED BY THE AUTHOR ``AS IS'' AND ANY EXPRESS OR
** IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES
** OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED.
** IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR ANY DIRECT, INDIRECT,
** INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT
** NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
** DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY
** THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
** (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF
** THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
**
***************************************************************************
*/
#include <sys/param.h>
#include <sys/systm.h>
#include <sys/malloc.h>
#include <sys/kernel.h>
#include <pci/pcivar.h>
#include <pci/pcireg.h>
/*---------------------------------------------------------
**
** Intel chipsets for 486 / Pentium processor
**
**---------------------------------------------------------
*/
static char* chipset_probe (pcici_t tag, pcidi_t type);
static void chipset_attach(pcici_t tag, int unit);
static u_long chipset_count;
static struct pci_device chipset_device = {
"chip",
chipset_probe,
chipset_attach,
&chipset_count,
NULL
};
DATA_SET (pcidevice_set, chipset_device);
struct condmsg {
unsigned char port;
unsigned char mask;
unsigned char value;
char flags;
const char *text;
};
static char*
generic_pci_bridge (pcici_t tag)
{
char *descr, tmpbuf[120];
unsigned classreg = pci_conf_read (tag, PCI_CLASS_REG);
if ((classreg & PCI_CLASS_MASK) == PCI_CLASS_BRIDGE) {
unsigned id = pci_conf_read (tag, PCI_ID_REG);
switch (classreg >> 16 & 0xff) {
case 0: strcpy(tmpbuf, "Host to PCI"); break;
case 1: strcpy(tmpbuf, "PCI to ISA"); break;
case 2: strcpy(tmpbuf, "PCI to EISA"); break;
case 4: strcpy(tmpbuf, "PCI to PCI"); break;
case 5: strcpy(tmpbuf, "PCI to PCMCIA"); break;
case 7: strcpy(tmpbuf, "PCI to CardBus"); break;
default:
sprintf(tmpbuf, "PCI to 0x%x", classreg>>16 & 0xff);
break;
}
sprintf(tmpbuf+strlen(tmpbuf), " bridge (vendor=%04x device=%04x)",
id & 0xffff, (id >> 16) & 0xffff);
descr = malloc (strlen(tmpbuf) +1, M_DEVBUF, M_WAITOK);
strcpy(descr, tmpbuf);
return descr;
}
return 0;
}
/*
* XXX Both fixbushigh_orion() and fixbushigh_i1225() are bogus in that way,
* that they store the highest bus number to scan in this device's config
* data, though it is about PCI buses attached to the CPU independently!
*/
static void
fixbushigh_orion(pcici_t tag)
{
tag->secondarybus = pci_cfgread(tag, 0x4a, 1);
tag->subordinatebus = pci_cfgread(tag, 0x4b, 1);
}
static void
fixbushigh_i1225(pcici_t tag)
{
int sublementarybus;
sublementarybus = pci_cfgread(tag, 0x41, 1);
if (sublementarybus != 0xff)
tag->secondarybus = tag->subordinatebus = sublementarybus +1;
}
static void
fixwsc_natoma(pcici_t tag)
{
int pmccfg;
pmccfg = pci_cfgread(tag, 0x50, 2);
#if defined(SMP)
if (pmccfg & 0x8000) {
printf("Correcting Natoma config for SMP\n");
pmccfg &= ~0x8000;
pci_cfgwrite(tag, 0x50, 2, pmccfg);
}
#else
if ((pmccfg & 0x8000) == 0) {
printf("Correcting Natoma config for non-SMP\n");
pmccfg |= 0x8000;
pci_cfgwrite(tag, 0x50, 2, pmccfg);
}
#endif
}
static char*
chipset_probe (pcici_t tag, pcidi_t type)
{
unsigned rev;
char *descr;
switch (type) {
case 0x00088086:
/* Silently ignore this one! What is it, anyway ??? */
return ("");
case 0x04868086:
return ("Intel 82425EX PCI system controller");
case 0x04848086:
rev = (unsigned) pci_conf_read (tag, PCI_CLASS_REG) & 0xff;
if (rev == 3)
return ("Intel 82378ZB PCI to ISA bridge");
return ("Intel 82378IB PCI to ISA bridge");
case 0x04838086:
1995-07-27 22:14:25 +00:00
return ("Intel 82424ZX (Saturn) cache DRAM controller");
case 0x04828086:
return ("Intel 82375EB PCI-EISA bridge");
case 0x04961039:
return ("SiS 85c496");
case 0x04a38086:
rev = (unsigned) pci_conf_read (tag, PCI_CLASS_REG) & 0xff;
if (rev == 16 || rev == 17)
1995-07-27 22:14:25 +00:00
return ("Intel 82434NX (Neptune) PCI cache memory controller");
return ("Intel 82434LX (Mercury) PCI cache memory controller");
case 0x12258086:
fixbushigh_i1225(tag);
return ("Intel 824?? host to PCI bridge");
1995-07-27 22:14:25 +00:00
case 0x122d8086:
return ("Intel 82437FX PCI cache memory controller");
1995-07-27 22:14:25 +00:00
case 0x122e8086:
return ("Intel 82371FB PCI to ISA bridge");
Add support for busmaster DMA on some PCI IDE chipsets. I changed a few bits here and there, mainly renaming wd82371.c to ide_pci.c now that it's supposed to handle different chipsets. It runs on my P6 natoma board with two Maxtor drives, and also on a Fujitsu machine I have at work with an Opti chipset and a Quantum drive. Submitted by:cgull@smoke.marlboro.vt.us <John Hood> Original readme: *** WARNING *** This code has so far been tested on exactly one motherboard with two identical drives known for their good DMA support. This code, in the right circumstances, could corrupt data subtly, silently, and invisibly, in much the same way that older PCI IDE controllers do. It's ALPHA-quality code; there's one or two major gaps in my understanding of PCI IDE still. Don't use this code on any system with data that you care about; it's only good for hack boxes. Expect that any data may be silently and randomly corrupted at any moment. It's a disk driver. It has bugs. Disk drivers with bugs munch data. It's a fact of life. I also *STRONGLY* recommend getting a copy of your chipset's manual and the ATA-2 or ATA-3 spec and making sure that timing modes on your disk drives and IDE controller are being setup correctly by the BIOS-- because the driver makes only the lamest of attempts to do this just now. *** END WARNING *** that said, i happen to think the code is working pretty well... WHAT IT DOES: this code adds support to the wd driver for bus mastering PCI IDE controllers that follow the SFF-8038 standard. (all the bus mastering PCI IDE controllers i've seen so far do follow this standard.) it should provide busmastering on nearly any current P5 or P6 chipset, specifically including any Intel chipset using one of the PIIX south bridges-- this includes the '430FX, '430VX, '430HX, '430TX, '440LX, and (i think) the Orion '450GX chipsets. specific support is also included for the VIA Apollo VP-1 chipset, as it appears in the relabeled "HXPro" incarnation seen on cheap US$70 taiwanese motherboards (that's what's in my development machine). it works out of the box on controllers that do DMA mode2; if my understanding is correct, it'll probably work on Ultra-DMA33 controllers as well. it'll probably work on busmastering IDE controllers in PCI slots, too, but this is an area i am less sure about. it cuts CPU usage considerably and improves drive performance slightly. usable numbers are difficult to come by with existing benchmark tools, but experimentation on my K5-P90 system, with VIA VP-1 chipset and Quantum Fireball 1080 drives, shows that disk i/o on raw partitions imposes perhaps 5% cpu load. cpu load during filesystem i/o drops a lot, from near 100% to anywhere between 30% and 70%. (the improvement may not be as large on an Intel chipset; from what i can tell, the VIA VP-1 may not be very efficient with PCI I/O.) disk performance improves by 5% or 10% with these drives. real, visible, end-user performance improvement on a single user machine is about nil. :) a kernel compile was sped up by a whole three seconds. it *does* feel a bit better-behaved when the system is swapping heavily, but a better disk driver is not the fix for *that* problem. THE CODE: this code is a patch to wd.c and wd82371.c, and associated header files. it should be considered alpha code; more work needs to be done. wd.c has fairly clean patches to add calls to busmaster code, as implemented in wd82371.c and potentially elsewhere (one could imagine, say, a Mac having a different DMA controller). wd82371.c has been considerably reworked: the wddma interface that it presents has been changed (expect more changes), many bugs have been fixed, a new internal interface has been added for supporting different chipsets, and the PCI probe has been considerably extended. the interface between wd82371.c and wd.c is still fairly clean, but i'm not sure it's in the right place. there's a mess of issues around ATA/ATAPI that need to be sorted out, including ATAPI support, CD-ROM support, tape support, LS-120/Zip support, SFF-8038i DMA, UltraDMA, PCI IDE controllers, bus probes, buggy controllers, controller timing setup, drive timing setup, world peace and kitchen sinks. whatever happens with all this and however it gets partitioned, it is fairly clear that wd.c needs some significant rework-- probably a complete rewrite. timing setup on disk controllers is something i've entirely punted on. on my development machine, it appears that the BIOS does at least some of the necessary timing setup. i chose to restrict operation to drives that are already configured for Mode4 PIO and Mode2 multiword DMA, since the timing is essentially the same and many if not most chipsets use the same control registers for DMA and PIO timing. does anybody *know* whether BIOSes are required to do timing setup for DMA modes on drives under their care? error recovery is probably weak. early on in development, i was getting drive errors induced by bugs in the driver; i used these to flush out the worst of the bugs in the driver's error handling, but problems may remain. i haven't got a drive with bad sectors i can watch the driver flail on. complaints about how wd82371.c has been reindented will be ignored until the FreeBSD project has a real style policy, there is a mechanism for individual authors to match it (indent flags or an emacs c-mode or whatever), and it is enforced. if i'm going to use a source style i don't like, it would help if i could figure out what it *is* (style(9) is about half of a policy), and a way to reasonably duplicate it. i ended up wasting a while trying to figure out what the right thing to do was before deciding reformatting the whole thing was the worst possible thing to do, except for all the other possibilities. i have maintained wd.c's indentation; that was not too hard, fortunately. TO INSTALL: my dev box is freebsd 2.2.2 release. fortunately, wd.c is a living fossil, and has diverged very little recently. included in this tarball is a patch file, 'otherdiffs', for all files except wd82371.c, my edited wd82371.c, a patch file, 'wd82371.c-diff-exact', against the 2.2.2 dist of 82371.c, and another patch file, 'wd82371.c-diff-whitespace', generated with diff -b (ignore whitespace). most of you not using 2.2.2 will probably have to use this last patchfile with 'patch --ignore-whitespace'. apply from the kernel source tree root. as far as i can tell, this should apply cleanly on anything from -current back to 2.2.2 and probably back to 2.2.0. you, the kernel hacker, can figure out what to do from here. if you need more specific directions, you probably should not be experimenting with this code yet. to enable DMA support, set flag 0x2000 for that drive in your config file or in userconfig, as you would the 32-bit-PIO flag. the driver will then turn on DMA support if your drive and controller pass its tests. it's a bit picky, probably. on discovering DMA mode failures or disk errors or transfers that the DMA controller can't deal with, the driver will fall back to PIO, so it is wise to setup the flags as if PIO were still important. 'controller wdc0 at isa? port "IO_WD1" bio irq 14 flags 0xa0ffa0ff vector wdintr' should work with nearly any PCI IDE controller. i would *strongly* suggest booting single-user at first, and thrashing the drive a bit while it's still mounted read-only. this should be fairly safe, even if the driver goes completely out to lunch. it might save you a reinstall. one way to tell whether the driver is really using DMA is to check the interrupt count during disk i/o with vmstat; DMA mode will add an extremely low number of interrupts, as compared to even multi-sector PIO. boot -v will give you a copious register dump of timing-related info on Intel and VIAtech chipsets, as well as PIO/DMA mode information on all hard drives. refer to your ATA and chipset documentation to interpret these. WHAT I'D LIKE FROM YOU and THINGS TO TEST: reports. success reports, failure reports, any kind of reports. :) send them to cgull+ide@smoke.marlboro.vt.us. i'd also like to see the kernel messages from various BIOSes (boot -v; dmesg), along with info on the motherboard and BIOS on that machine. i'm especially interested in reports on how this code works on the various Intel chipsets, and whether the register dump works correctly. i'm also interested in hearing about other chipsets. i'm especially interested in hearing success/failure reports for PCI IDE controllers on cards, such as CMD's or Promise's new busmastering IDE controllers. UltraDMA-33 reports. interoperation with ATAPI peripherals-- FreeBSD doesn't work with my old Hitachi IDE CDROM, so i can't tell if I've broken anything. :) i'd especially like to hear how the drive copes in DMA operation on drives with bad sectors. i haven't been able to find any such yet. success/failure reports on older IDE drives with early support for DMA modes-- those introduced between 1.5 and 3 years ago, typically ranging from perhaps 400MB to 1.6GB. failure reports on operation with more than one drive would be appreciated. the driver was developed with two drives on one controller, the worst-case situation, and has been tested with one drive on each controller, but you never know... any reports of messages from the driver during normal operation, especially "reverting to PIO mode", or "dmaverify odd vaddr or length" (the DMA controller is strongly halfword oriented, and i'm curious to know if any FreeBSD usage actually needs misaligned transfers). performance reports. beware that bonnie's CPU usage reporting is useless for IDE drives; the best test i've found has been to run a program that runs a spin loop at an idle priority and reports how many iterations it manages, and even that sometimes produces numbers i don't believe. performance reports of multi-drive operation are especially interesting; my system cannot sustain full throughput on two drives on separate controllers, but that may just be a lame motherboard. THINGS I'M STILL MISSING CLUE ON: * who's responsible for configuring DMA timing modes on IDE drives? the BIOS or the driver? * is there a spec for dealing with Ultra-DMA extensions? * are there any chipsets or with bugs relating to DMA transfer that should be blacklisted? * are there any ATA interfaces that use some other kind of DMA controller in conjunction with standard ATA protocol? FINAL NOTE: after having looked at the ATA-3 spec, all i can say is, "it's ugly". *especially* electrically. the IDE bus is best modeled as an unterminated transmission line, these days. for maximum reliability, keep your IDE cables as short as possible and as few as possible. from what i can tell, most current chipsets have both IDE ports wired into a single buss, to a greater or lesser degree. using two cables means you double the length of this bus. SCSI may have its warts, but at least the basic analog design of the bus is still somewhat reasonable. IDE passed beyond the veil two years ago. --John Hood, cgull@smoke.marlboro.vt.us
1997-07-29 12:57:25 +00:00
#if 0
/* ide_pci takes care of this now */
case 0x12308086:
return ("Intel 82371FB IDE interface");
Add support for busmaster DMA on some PCI IDE chipsets. I changed a few bits here and there, mainly renaming wd82371.c to ide_pci.c now that it's supposed to handle different chipsets. It runs on my P6 natoma board with two Maxtor drives, and also on a Fujitsu machine I have at work with an Opti chipset and a Quantum drive. Submitted by:cgull@smoke.marlboro.vt.us <John Hood> Original readme: *** WARNING *** This code has so far been tested on exactly one motherboard with two identical drives known for their good DMA support. This code, in the right circumstances, could corrupt data subtly, silently, and invisibly, in much the same way that older PCI IDE controllers do. It's ALPHA-quality code; there's one or two major gaps in my understanding of PCI IDE still. Don't use this code on any system with data that you care about; it's only good for hack boxes. Expect that any data may be silently and randomly corrupted at any moment. It's a disk driver. It has bugs. Disk drivers with bugs munch data. It's a fact of life. I also *STRONGLY* recommend getting a copy of your chipset's manual and the ATA-2 or ATA-3 spec and making sure that timing modes on your disk drives and IDE controller are being setup correctly by the BIOS-- because the driver makes only the lamest of attempts to do this just now. *** END WARNING *** that said, i happen to think the code is working pretty well... WHAT IT DOES: this code adds support to the wd driver for bus mastering PCI IDE controllers that follow the SFF-8038 standard. (all the bus mastering PCI IDE controllers i've seen so far do follow this standard.) it should provide busmastering on nearly any current P5 or P6 chipset, specifically including any Intel chipset using one of the PIIX south bridges-- this includes the '430FX, '430VX, '430HX, '430TX, '440LX, and (i think) the Orion '450GX chipsets. specific support is also included for the VIA Apollo VP-1 chipset, as it appears in the relabeled "HXPro" incarnation seen on cheap US$70 taiwanese motherboards (that's what's in my development machine). it works out of the box on controllers that do DMA mode2; if my understanding is correct, it'll probably work on Ultra-DMA33 controllers as well. it'll probably work on busmastering IDE controllers in PCI slots, too, but this is an area i am less sure about. it cuts CPU usage considerably and improves drive performance slightly. usable numbers are difficult to come by with existing benchmark tools, but experimentation on my K5-P90 system, with VIA VP-1 chipset and Quantum Fireball 1080 drives, shows that disk i/o on raw partitions imposes perhaps 5% cpu load. cpu load during filesystem i/o drops a lot, from near 100% to anywhere between 30% and 70%. (the improvement may not be as large on an Intel chipset; from what i can tell, the VIA VP-1 may not be very efficient with PCI I/O.) disk performance improves by 5% or 10% with these drives. real, visible, end-user performance improvement on a single user machine is about nil. :) a kernel compile was sped up by a whole three seconds. it *does* feel a bit better-behaved when the system is swapping heavily, but a better disk driver is not the fix for *that* problem. THE CODE: this code is a patch to wd.c and wd82371.c, and associated header files. it should be considered alpha code; more work needs to be done. wd.c has fairly clean patches to add calls to busmaster code, as implemented in wd82371.c and potentially elsewhere (one could imagine, say, a Mac having a different DMA controller). wd82371.c has been considerably reworked: the wddma interface that it presents has been changed (expect more changes), many bugs have been fixed, a new internal interface has been added for supporting different chipsets, and the PCI probe has been considerably extended. the interface between wd82371.c and wd.c is still fairly clean, but i'm not sure it's in the right place. there's a mess of issues around ATA/ATAPI that need to be sorted out, including ATAPI support, CD-ROM support, tape support, LS-120/Zip support, SFF-8038i DMA, UltraDMA, PCI IDE controllers, bus probes, buggy controllers, controller timing setup, drive timing setup, world peace and kitchen sinks. whatever happens with all this and however it gets partitioned, it is fairly clear that wd.c needs some significant rework-- probably a complete rewrite. timing setup on disk controllers is something i've entirely punted on. on my development machine, it appears that the BIOS does at least some of the necessary timing setup. i chose to restrict operation to drives that are already configured for Mode4 PIO and Mode2 multiword DMA, since the timing is essentially the same and many if not most chipsets use the same control registers for DMA and PIO timing. does anybody *know* whether BIOSes are required to do timing setup for DMA modes on drives under their care? error recovery is probably weak. early on in development, i was getting drive errors induced by bugs in the driver; i used these to flush out the worst of the bugs in the driver's error handling, but problems may remain. i haven't got a drive with bad sectors i can watch the driver flail on. complaints about how wd82371.c has been reindented will be ignored until the FreeBSD project has a real style policy, there is a mechanism for individual authors to match it (indent flags or an emacs c-mode or whatever), and it is enforced. if i'm going to use a source style i don't like, it would help if i could figure out what it *is* (style(9) is about half of a policy), and a way to reasonably duplicate it. i ended up wasting a while trying to figure out what the right thing to do was before deciding reformatting the whole thing was the worst possible thing to do, except for all the other possibilities. i have maintained wd.c's indentation; that was not too hard, fortunately. TO INSTALL: my dev box is freebsd 2.2.2 release. fortunately, wd.c is a living fossil, and has diverged very little recently. included in this tarball is a patch file, 'otherdiffs', for all files except wd82371.c, my edited wd82371.c, a patch file, 'wd82371.c-diff-exact', against the 2.2.2 dist of 82371.c, and another patch file, 'wd82371.c-diff-whitespace', generated with diff -b (ignore whitespace). most of you not using 2.2.2 will probably have to use this last patchfile with 'patch --ignore-whitespace'. apply from the kernel source tree root. as far as i can tell, this should apply cleanly on anything from -current back to 2.2.2 and probably back to 2.2.0. you, the kernel hacker, can figure out what to do from here. if you need more specific directions, you probably should not be experimenting with this code yet. to enable DMA support, set flag 0x2000 for that drive in your config file or in userconfig, as you would the 32-bit-PIO flag. the driver will then turn on DMA support if your drive and controller pass its tests. it's a bit picky, probably. on discovering DMA mode failures or disk errors or transfers that the DMA controller can't deal with, the driver will fall back to PIO, so it is wise to setup the flags as if PIO were still important. 'controller wdc0 at isa? port "IO_WD1" bio irq 14 flags 0xa0ffa0ff vector wdintr' should work with nearly any PCI IDE controller. i would *strongly* suggest booting single-user at first, and thrashing the drive a bit while it's still mounted read-only. this should be fairly safe, even if the driver goes completely out to lunch. it might save you a reinstall. one way to tell whether the driver is really using DMA is to check the interrupt count during disk i/o with vmstat; DMA mode will add an extremely low number of interrupts, as compared to even multi-sector PIO. boot -v will give you a copious register dump of timing-related info on Intel and VIAtech chipsets, as well as PIO/DMA mode information on all hard drives. refer to your ATA and chipset documentation to interpret these. WHAT I'D LIKE FROM YOU and THINGS TO TEST: reports. success reports, failure reports, any kind of reports. :) send them to cgull+ide@smoke.marlboro.vt.us. i'd also like to see the kernel messages from various BIOSes (boot -v; dmesg), along with info on the motherboard and BIOS on that machine. i'm especially interested in reports on how this code works on the various Intel chipsets, and whether the register dump works correctly. i'm also interested in hearing about other chipsets. i'm especially interested in hearing success/failure reports for PCI IDE controllers on cards, such as CMD's or Promise's new busmastering IDE controllers. UltraDMA-33 reports. interoperation with ATAPI peripherals-- FreeBSD doesn't work with my old Hitachi IDE CDROM, so i can't tell if I've broken anything. :) i'd especially like to hear how the drive copes in DMA operation on drives with bad sectors. i haven't been able to find any such yet. success/failure reports on older IDE drives with early support for DMA modes-- those introduced between 1.5 and 3 years ago, typically ranging from perhaps 400MB to 1.6GB. failure reports on operation with more than one drive would be appreciated. the driver was developed with two drives on one controller, the worst-case situation, and has been tested with one drive on each controller, but you never know... any reports of messages from the driver during normal operation, especially "reverting to PIO mode", or "dmaverify odd vaddr or length" (the DMA controller is strongly halfword oriented, and i'm curious to know if any FreeBSD usage actually needs misaligned transfers). performance reports. beware that bonnie's CPU usage reporting is useless for IDE drives; the best test i've found has been to run a program that runs a spin loop at an idle priority and reports how many iterations it manages, and even that sometimes produces numbers i don't believe. performance reports of multi-drive operation are especially interesting; my system cannot sustain full throughput on two drives on separate controllers, but that may just be a lame motherboard. THINGS I'M STILL MISSING CLUE ON: * who's responsible for configuring DMA timing modes on IDE drives? the BIOS or the driver? * is there a spec for dealing with Ultra-DMA extensions? * are there any chipsets or with bugs relating to DMA transfer that should be blacklisted? * are there any ATA interfaces that use some other kind of DMA controller in conjunction with standard ATA protocol? FINAL NOTE: after having looked at the ATA-3 spec, all i can say is, "it's ugly". *especially* electrically. the IDE bus is best modeled as an unterminated transmission line, these days. for maximum reliability, keep your IDE cables as short as possible and as few as possible. from what i can tell, most current chipsets have both IDE ports wired into a single buss, to a greater or lesser degree. using two cables means you double the length of this bus. SCSI may have its warts, but at least the basic analog design of the bus is still somewhat reasonable. IDE passed beyond the veil two years ago. --John Hood, cgull@smoke.marlboro.vt.us
1997-07-29 12:57:25 +00:00
#endif
case 0x12508086:
return ("Intel 82439");
case 0x04061039:
return ("SiS 85c501");
case 0x00081039:
return ("SiS 85c503");
case 0x06011039:
return ("SiS 85c601");
case 0x70008086:
return ("Intel 82371SB PCI to ISA bridge");
Add support for busmaster DMA on some PCI IDE chipsets. I changed a few bits here and there, mainly renaming wd82371.c to ide_pci.c now that it's supposed to handle different chipsets. It runs on my P6 natoma board with two Maxtor drives, and also on a Fujitsu machine I have at work with an Opti chipset and a Quantum drive. Submitted by:cgull@smoke.marlboro.vt.us <John Hood> Original readme: *** WARNING *** This code has so far been tested on exactly one motherboard with two identical drives known for their good DMA support. This code, in the right circumstances, could corrupt data subtly, silently, and invisibly, in much the same way that older PCI IDE controllers do. It's ALPHA-quality code; there's one or two major gaps in my understanding of PCI IDE still. Don't use this code on any system with data that you care about; it's only good for hack boxes. Expect that any data may be silently and randomly corrupted at any moment. It's a disk driver. It has bugs. Disk drivers with bugs munch data. It's a fact of life. I also *STRONGLY* recommend getting a copy of your chipset's manual and the ATA-2 or ATA-3 spec and making sure that timing modes on your disk drives and IDE controller are being setup correctly by the BIOS-- because the driver makes only the lamest of attempts to do this just now. *** END WARNING *** that said, i happen to think the code is working pretty well... WHAT IT DOES: this code adds support to the wd driver for bus mastering PCI IDE controllers that follow the SFF-8038 standard. (all the bus mastering PCI IDE controllers i've seen so far do follow this standard.) it should provide busmastering on nearly any current P5 or P6 chipset, specifically including any Intel chipset using one of the PIIX south bridges-- this includes the '430FX, '430VX, '430HX, '430TX, '440LX, and (i think) the Orion '450GX chipsets. specific support is also included for the VIA Apollo VP-1 chipset, as it appears in the relabeled "HXPro" incarnation seen on cheap US$70 taiwanese motherboards (that's what's in my development machine). it works out of the box on controllers that do DMA mode2; if my understanding is correct, it'll probably work on Ultra-DMA33 controllers as well. it'll probably work on busmastering IDE controllers in PCI slots, too, but this is an area i am less sure about. it cuts CPU usage considerably and improves drive performance slightly. usable numbers are difficult to come by with existing benchmark tools, but experimentation on my K5-P90 system, with VIA VP-1 chipset and Quantum Fireball 1080 drives, shows that disk i/o on raw partitions imposes perhaps 5% cpu load. cpu load during filesystem i/o drops a lot, from near 100% to anywhere between 30% and 70%. (the improvement may not be as large on an Intel chipset; from what i can tell, the VIA VP-1 may not be very efficient with PCI I/O.) disk performance improves by 5% or 10% with these drives. real, visible, end-user performance improvement on a single user machine is about nil. :) a kernel compile was sped up by a whole three seconds. it *does* feel a bit better-behaved when the system is swapping heavily, but a better disk driver is not the fix for *that* problem. THE CODE: this code is a patch to wd.c and wd82371.c, and associated header files. it should be considered alpha code; more work needs to be done. wd.c has fairly clean patches to add calls to busmaster code, as implemented in wd82371.c and potentially elsewhere (one could imagine, say, a Mac having a different DMA controller). wd82371.c has been considerably reworked: the wddma interface that it presents has been changed (expect more changes), many bugs have been fixed, a new internal interface has been added for supporting different chipsets, and the PCI probe has been considerably extended. the interface between wd82371.c and wd.c is still fairly clean, but i'm not sure it's in the right place. there's a mess of issues around ATA/ATAPI that need to be sorted out, including ATAPI support, CD-ROM support, tape support, LS-120/Zip support, SFF-8038i DMA, UltraDMA, PCI IDE controllers, bus probes, buggy controllers, controller timing setup, drive timing setup, world peace and kitchen sinks. whatever happens with all this and however it gets partitioned, it is fairly clear that wd.c needs some significant rework-- probably a complete rewrite. timing setup on disk controllers is something i've entirely punted on. on my development machine, it appears that the BIOS does at least some of the necessary timing setup. i chose to restrict operation to drives that are already configured for Mode4 PIO and Mode2 multiword DMA, since the timing is essentially the same and many if not most chipsets use the same control registers for DMA and PIO timing. does anybody *know* whether BIOSes are required to do timing setup for DMA modes on drives under their care? error recovery is probably weak. early on in development, i was getting drive errors induced by bugs in the driver; i used these to flush out the worst of the bugs in the driver's error handling, but problems may remain. i haven't got a drive with bad sectors i can watch the driver flail on. complaints about how wd82371.c has been reindented will be ignored until the FreeBSD project has a real style policy, there is a mechanism for individual authors to match it (indent flags or an emacs c-mode or whatever), and it is enforced. if i'm going to use a source style i don't like, it would help if i could figure out what it *is* (style(9) is about half of a policy), and a way to reasonably duplicate it. i ended up wasting a while trying to figure out what the right thing to do was before deciding reformatting the whole thing was the worst possible thing to do, except for all the other possibilities. i have maintained wd.c's indentation; that was not too hard, fortunately. TO INSTALL: my dev box is freebsd 2.2.2 release. fortunately, wd.c is a living fossil, and has diverged very little recently. included in this tarball is a patch file, 'otherdiffs', for all files except wd82371.c, my edited wd82371.c, a patch file, 'wd82371.c-diff-exact', against the 2.2.2 dist of 82371.c, and another patch file, 'wd82371.c-diff-whitespace', generated with diff -b (ignore whitespace). most of you not using 2.2.2 will probably have to use this last patchfile with 'patch --ignore-whitespace'. apply from the kernel source tree root. as far as i can tell, this should apply cleanly on anything from -current back to 2.2.2 and probably back to 2.2.0. you, the kernel hacker, can figure out what to do from here. if you need more specific directions, you probably should not be experimenting with this code yet. to enable DMA support, set flag 0x2000 for that drive in your config file or in userconfig, as you would the 32-bit-PIO flag. the driver will then turn on DMA support if your drive and controller pass its tests. it's a bit picky, probably. on discovering DMA mode failures or disk errors or transfers that the DMA controller can't deal with, the driver will fall back to PIO, so it is wise to setup the flags as if PIO were still important. 'controller wdc0 at isa? port "IO_WD1" bio irq 14 flags 0xa0ffa0ff vector wdintr' should work with nearly any PCI IDE controller. i would *strongly* suggest booting single-user at first, and thrashing the drive a bit while it's still mounted read-only. this should be fairly safe, even if the driver goes completely out to lunch. it might save you a reinstall. one way to tell whether the driver is really using DMA is to check the interrupt count during disk i/o with vmstat; DMA mode will add an extremely low number of interrupts, as compared to even multi-sector PIO. boot -v will give you a copious register dump of timing-related info on Intel and VIAtech chipsets, as well as PIO/DMA mode information on all hard drives. refer to your ATA and chipset documentation to interpret these. WHAT I'D LIKE FROM YOU and THINGS TO TEST: reports. success reports, failure reports, any kind of reports. :) send them to cgull+ide@smoke.marlboro.vt.us. i'd also like to see the kernel messages from various BIOSes (boot -v; dmesg), along with info on the motherboard and BIOS on that machine. i'm especially interested in reports on how this code works on the various Intel chipsets, and whether the register dump works correctly. i'm also interested in hearing about other chipsets. i'm especially interested in hearing success/failure reports for PCI IDE controllers on cards, such as CMD's or Promise's new busmastering IDE controllers. UltraDMA-33 reports. interoperation with ATAPI peripherals-- FreeBSD doesn't work with my old Hitachi IDE CDROM, so i can't tell if I've broken anything. :) i'd especially like to hear how the drive copes in DMA operation on drives with bad sectors. i haven't been able to find any such yet. success/failure reports on older IDE drives with early support for DMA modes-- those introduced between 1.5 and 3 years ago, typically ranging from perhaps 400MB to 1.6GB. failure reports on operation with more than one drive would be appreciated. the driver was developed with two drives on one controller, the worst-case situation, and has been tested with one drive on each controller, but you never know... any reports of messages from the driver during normal operation, especially "reverting to PIO mode", or "dmaverify odd vaddr or length" (the DMA controller is strongly halfword oriented, and i'm curious to know if any FreeBSD usage actually needs misaligned transfers). performance reports. beware that bonnie's CPU usage reporting is useless for IDE drives; the best test i've found has been to run a program that runs a spin loop at an idle priority and reports how many iterations it manages, and even that sometimes produces numbers i don't believe. performance reports of multi-drive operation are especially interesting; my system cannot sustain full throughput on two drives on separate controllers, but that may just be a lame motherboard. THINGS I'M STILL MISSING CLUE ON: * who's responsible for configuring DMA timing modes on IDE drives? the BIOS or the driver? * is there a spec for dealing with Ultra-DMA extensions? * are there any chipsets or with bugs relating to DMA transfer that should be blacklisted? * are there any ATA interfaces that use some other kind of DMA controller in conjunction with standard ATA protocol? FINAL NOTE: after having looked at the ATA-3 spec, all i can say is, "it's ugly". *especially* electrically. the IDE bus is best modeled as an unterminated transmission line, these days. for maximum reliability, keep your IDE cables as short as possible and as few as possible. from what i can tell, most current chipsets have both IDE ports wired into a single buss, to a greater or lesser degree. using two cables means you double the length of this bus. SCSI may have its warts, but at least the basic analog design of the bus is still somewhat reasonable. IDE passed beyond the veil two years ago. --John Hood, cgull@smoke.marlboro.vt.us
1997-07-29 12:57:25 +00:00
#if 0
/* ide_pci takes care of this now */
case 0x70108086:
return ("Intel 82371SB IDE interface");
Add support for busmaster DMA on some PCI IDE chipsets. I changed a few bits here and there, mainly renaming wd82371.c to ide_pci.c now that it's supposed to handle different chipsets. It runs on my P6 natoma board with two Maxtor drives, and also on a Fujitsu machine I have at work with an Opti chipset and a Quantum drive. Submitted by:cgull@smoke.marlboro.vt.us <John Hood> Original readme: *** WARNING *** This code has so far been tested on exactly one motherboard with two identical drives known for their good DMA support. This code, in the right circumstances, could corrupt data subtly, silently, and invisibly, in much the same way that older PCI IDE controllers do. It's ALPHA-quality code; there's one or two major gaps in my understanding of PCI IDE still. Don't use this code on any system with data that you care about; it's only good for hack boxes. Expect that any data may be silently and randomly corrupted at any moment. It's a disk driver. It has bugs. Disk drivers with bugs munch data. It's a fact of life. I also *STRONGLY* recommend getting a copy of your chipset's manual and the ATA-2 or ATA-3 spec and making sure that timing modes on your disk drives and IDE controller are being setup correctly by the BIOS-- because the driver makes only the lamest of attempts to do this just now. *** END WARNING *** that said, i happen to think the code is working pretty well... WHAT IT DOES: this code adds support to the wd driver for bus mastering PCI IDE controllers that follow the SFF-8038 standard. (all the bus mastering PCI IDE controllers i've seen so far do follow this standard.) it should provide busmastering on nearly any current P5 or P6 chipset, specifically including any Intel chipset using one of the PIIX south bridges-- this includes the '430FX, '430VX, '430HX, '430TX, '440LX, and (i think) the Orion '450GX chipsets. specific support is also included for the VIA Apollo VP-1 chipset, as it appears in the relabeled "HXPro" incarnation seen on cheap US$70 taiwanese motherboards (that's what's in my development machine). it works out of the box on controllers that do DMA mode2; if my understanding is correct, it'll probably work on Ultra-DMA33 controllers as well. it'll probably work on busmastering IDE controllers in PCI slots, too, but this is an area i am less sure about. it cuts CPU usage considerably and improves drive performance slightly. usable numbers are difficult to come by with existing benchmark tools, but experimentation on my K5-P90 system, with VIA VP-1 chipset and Quantum Fireball 1080 drives, shows that disk i/o on raw partitions imposes perhaps 5% cpu load. cpu load during filesystem i/o drops a lot, from near 100% to anywhere between 30% and 70%. (the improvement may not be as large on an Intel chipset; from what i can tell, the VIA VP-1 may not be very efficient with PCI I/O.) disk performance improves by 5% or 10% with these drives. real, visible, end-user performance improvement on a single user machine is about nil. :) a kernel compile was sped up by a whole three seconds. it *does* feel a bit better-behaved when the system is swapping heavily, but a better disk driver is not the fix for *that* problem. THE CODE: this code is a patch to wd.c and wd82371.c, and associated header files. it should be considered alpha code; more work needs to be done. wd.c has fairly clean patches to add calls to busmaster code, as implemented in wd82371.c and potentially elsewhere (one could imagine, say, a Mac having a different DMA controller). wd82371.c has been considerably reworked: the wddma interface that it presents has been changed (expect more changes), many bugs have been fixed, a new internal interface has been added for supporting different chipsets, and the PCI probe has been considerably extended. the interface between wd82371.c and wd.c is still fairly clean, but i'm not sure it's in the right place. there's a mess of issues around ATA/ATAPI that need to be sorted out, including ATAPI support, CD-ROM support, tape support, LS-120/Zip support, SFF-8038i DMA, UltraDMA, PCI IDE controllers, bus probes, buggy controllers, controller timing setup, drive timing setup, world peace and kitchen sinks. whatever happens with all this and however it gets partitioned, it is fairly clear that wd.c needs some significant rework-- probably a complete rewrite. timing setup on disk controllers is something i've entirely punted on. on my development machine, it appears that the BIOS does at least some of the necessary timing setup. i chose to restrict operation to drives that are already configured for Mode4 PIO and Mode2 multiword DMA, since the timing is essentially the same and many if not most chipsets use the same control registers for DMA and PIO timing. does anybody *know* whether BIOSes are required to do timing setup for DMA modes on drives under their care? error recovery is probably weak. early on in development, i was getting drive errors induced by bugs in the driver; i used these to flush out the worst of the bugs in the driver's error handling, but problems may remain. i haven't got a drive with bad sectors i can watch the driver flail on. complaints about how wd82371.c has been reindented will be ignored until the FreeBSD project has a real style policy, there is a mechanism for individual authors to match it (indent flags or an emacs c-mode or whatever), and it is enforced. if i'm going to use a source style i don't like, it would help if i could figure out what it *is* (style(9) is about half of a policy), and a way to reasonably duplicate it. i ended up wasting a while trying to figure out what the right thing to do was before deciding reformatting the whole thing was the worst possible thing to do, except for all the other possibilities. i have maintained wd.c's indentation; that was not too hard, fortunately. TO INSTALL: my dev box is freebsd 2.2.2 release. fortunately, wd.c is a living fossil, and has diverged very little recently. included in this tarball is a patch file, 'otherdiffs', for all files except wd82371.c, my edited wd82371.c, a patch file, 'wd82371.c-diff-exact', against the 2.2.2 dist of 82371.c, and another patch file, 'wd82371.c-diff-whitespace', generated with diff -b (ignore whitespace). most of you not using 2.2.2 will probably have to use this last patchfile with 'patch --ignore-whitespace'. apply from the kernel source tree root. as far as i can tell, this should apply cleanly on anything from -current back to 2.2.2 and probably back to 2.2.0. you, the kernel hacker, can figure out what to do from here. if you need more specific directions, you probably should not be experimenting with this code yet. to enable DMA support, set flag 0x2000 for that drive in your config file or in userconfig, as you would the 32-bit-PIO flag. the driver will then turn on DMA support if your drive and controller pass its tests. it's a bit picky, probably. on discovering DMA mode failures or disk errors or transfers that the DMA controller can't deal with, the driver will fall back to PIO, so it is wise to setup the flags as if PIO were still important. 'controller wdc0 at isa? port "IO_WD1" bio irq 14 flags 0xa0ffa0ff vector wdintr' should work with nearly any PCI IDE controller. i would *strongly* suggest booting single-user at first, and thrashing the drive a bit while it's still mounted read-only. this should be fairly safe, even if the driver goes completely out to lunch. it might save you a reinstall. one way to tell whether the driver is really using DMA is to check the interrupt count during disk i/o with vmstat; DMA mode will add an extremely low number of interrupts, as compared to even multi-sector PIO. boot -v will give you a copious register dump of timing-related info on Intel and VIAtech chipsets, as well as PIO/DMA mode information on all hard drives. refer to your ATA and chipset documentation to interpret these. WHAT I'D LIKE FROM YOU and THINGS TO TEST: reports. success reports, failure reports, any kind of reports. :) send them to cgull+ide@smoke.marlboro.vt.us. i'd also like to see the kernel messages from various BIOSes (boot -v; dmesg), along with info on the motherboard and BIOS on that machine. i'm especially interested in reports on how this code works on the various Intel chipsets, and whether the register dump works correctly. i'm also interested in hearing about other chipsets. i'm especially interested in hearing success/failure reports for PCI IDE controllers on cards, such as CMD's or Promise's new busmastering IDE controllers. UltraDMA-33 reports. interoperation with ATAPI peripherals-- FreeBSD doesn't work with my old Hitachi IDE CDROM, so i can't tell if I've broken anything. :) i'd especially like to hear how the drive copes in DMA operation on drives with bad sectors. i haven't been able to find any such yet. success/failure reports on older IDE drives with early support for DMA modes-- those introduced between 1.5 and 3 years ago, typically ranging from perhaps 400MB to 1.6GB. failure reports on operation with more than one drive would be appreciated. the driver was developed with two drives on one controller, the worst-case situation, and has been tested with one drive on each controller, but you never know... any reports of messages from the driver during normal operation, especially "reverting to PIO mode", or "dmaverify odd vaddr or length" (the DMA controller is strongly halfword oriented, and i'm curious to know if any FreeBSD usage actually needs misaligned transfers). performance reports. beware that bonnie's CPU usage reporting is useless for IDE drives; the best test i've found has been to run a program that runs a spin loop at an idle priority and reports how many iterations it manages, and even that sometimes produces numbers i don't believe. performance reports of multi-drive operation are especially interesting; my system cannot sustain full throughput on two drives on separate controllers, but that may just be a lame motherboard. THINGS I'M STILL MISSING CLUE ON: * who's responsible for configuring DMA timing modes on IDE drives? the BIOS or the driver? * is there a spec for dealing with Ultra-DMA extensions? * are there any chipsets or with bugs relating to DMA transfer that should be blacklisted? * are there any ATA interfaces that use some other kind of DMA controller in conjunction with standard ATA protocol? FINAL NOTE: after having looked at the ATA-3 spec, all i can say is, "it's ugly". *especially* electrically. the IDE bus is best modeled as an unterminated transmission line, these days. for maximum reliability, keep your IDE cables as short as possible and as few as possible. from what i can tell, most current chipsets have both IDE ports wired into a single buss, to a greater or lesser degree. using two cables means you double the length of this bus. SCSI may have its warts, but at least the basic analog design of the bus is still somewhat reasonable. IDE passed beyond the veil two years ago. --John Hood, cgull@smoke.marlboro.vt.us
1997-07-29 12:57:25 +00:00
#endif
case 0x71108086:
return ("Intel 82371AB PCI to ISA bridge");
Add support for busmaster DMA on some PCI IDE chipsets. I changed a few bits here and there, mainly renaming wd82371.c to ide_pci.c now that it's supposed to handle different chipsets. It runs on my P6 natoma board with two Maxtor drives, and also on a Fujitsu machine I have at work with an Opti chipset and a Quantum drive. Submitted by:cgull@smoke.marlboro.vt.us <John Hood> Original readme: *** WARNING *** This code has so far been tested on exactly one motherboard with two identical drives known for their good DMA support. This code, in the right circumstances, could corrupt data subtly, silently, and invisibly, in much the same way that older PCI IDE controllers do. It's ALPHA-quality code; there's one or two major gaps in my understanding of PCI IDE still. Don't use this code on any system with data that you care about; it's only good for hack boxes. Expect that any data may be silently and randomly corrupted at any moment. It's a disk driver. It has bugs. Disk drivers with bugs munch data. It's a fact of life. I also *STRONGLY* recommend getting a copy of your chipset's manual and the ATA-2 or ATA-3 spec and making sure that timing modes on your disk drives and IDE controller are being setup correctly by the BIOS-- because the driver makes only the lamest of attempts to do this just now. *** END WARNING *** that said, i happen to think the code is working pretty well... WHAT IT DOES: this code adds support to the wd driver for bus mastering PCI IDE controllers that follow the SFF-8038 standard. (all the bus mastering PCI IDE controllers i've seen so far do follow this standard.) it should provide busmastering on nearly any current P5 or P6 chipset, specifically including any Intel chipset using one of the PIIX south bridges-- this includes the '430FX, '430VX, '430HX, '430TX, '440LX, and (i think) the Orion '450GX chipsets. specific support is also included for the VIA Apollo VP-1 chipset, as it appears in the relabeled "HXPro" incarnation seen on cheap US$70 taiwanese motherboards (that's what's in my development machine). it works out of the box on controllers that do DMA mode2; if my understanding is correct, it'll probably work on Ultra-DMA33 controllers as well. it'll probably work on busmastering IDE controllers in PCI slots, too, but this is an area i am less sure about. it cuts CPU usage considerably and improves drive performance slightly. usable numbers are difficult to come by with existing benchmark tools, but experimentation on my K5-P90 system, with VIA VP-1 chipset and Quantum Fireball 1080 drives, shows that disk i/o on raw partitions imposes perhaps 5% cpu load. cpu load during filesystem i/o drops a lot, from near 100% to anywhere between 30% and 70%. (the improvement may not be as large on an Intel chipset; from what i can tell, the VIA VP-1 may not be very efficient with PCI I/O.) disk performance improves by 5% or 10% with these drives. real, visible, end-user performance improvement on a single user machine is about nil. :) a kernel compile was sped up by a whole three seconds. it *does* feel a bit better-behaved when the system is swapping heavily, but a better disk driver is not the fix for *that* problem. THE CODE: this code is a patch to wd.c and wd82371.c, and associated header files. it should be considered alpha code; more work needs to be done. wd.c has fairly clean patches to add calls to busmaster code, as implemented in wd82371.c and potentially elsewhere (one could imagine, say, a Mac having a different DMA controller). wd82371.c has been considerably reworked: the wddma interface that it presents has been changed (expect more changes), many bugs have been fixed, a new internal interface has been added for supporting different chipsets, and the PCI probe has been considerably extended. the interface between wd82371.c and wd.c is still fairly clean, but i'm not sure it's in the right place. there's a mess of issues around ATA/ATAPI that need to be sorted out, including ATAPI support, CD-ROM support, tape support, LS-120/Zip support, SFF-8038i DMA, UltraDMA, PCI IDE controllers, bus probes, buggy controllers, controller timing setup, drive timing setup, world peace and kitchen sinks. whatever happens with all this and however it gets partitioned, it is fairly clear that wd.c needs some significant rework-- probably a complete rewrite. timing setup on disk controllers is something i've entirely punted on. on my development machine, it appears that the BIOS does at least some of the necessary timing setup. i chose to restrict operation to drives that are already configured for Mode4 PIO and Mode2 multiword DMA, since the timing is essentially the same and many if not most chipsets use the same control registers for DMA and PIO timing. does anybody *know* whether BIOSes are required to do timing setup for DMA modes on drives under their care? error recovery is probably weak. early on in development, i was getting drive errors induced by bugs in the driver; i used these to flush out the worst of the bugs in the driver's error handling, but problems may remain. i haven't got a drive with bad sectors i can watch the driver flail on. complaints about how wd82371.c has been reindented will be ignored until the FreeBSD project has a real style policy, there is a mechanism for individual authors to match it (indent flags or an emacs c-mode or whatever), and it is enforced. if i'm going to use a source style i don't like, it would help if i could figure out what it *is* (style(9) is about half of a policy), and a way to reasonably duplicate it. i ended up wasting a while trying to figure out what the right thing to do was before deciding reformatting the whole thing was the worst possible thing to do, except for all the other possibilities. i have maintained wd.c's indentation; that was not too hard, fortunately. TO INSTALL: my dev box is freebsd 2.2.2 release. fortunately, wd.c is a living fossil, and has diverged very little recently. included in this tarball is a patch file, 'otherdiffs', for all files except wd82371.c, my edited wd82371.c, a patch file, 'wd82371.c-diff-exact', against the 2.2.2 dist of 82371.c, and another patch file, 'wd82371.c-diff-whitespace', generated with diff -b (ignore whitespace). most of you not using 2.2.2 will probably have to use this last patchfile with 'patch --ignore-whitespace'. apply from the kernel source tree root. as far as i can tell, this should apply cleanly on anything from -current back to 2.2.2 and probably back to 2.2.0. you, the kernel hacker, can figure out what to do from here. if you need more specific directions, you probably should not be experimenting with this code yet. to enable DMA support, set flag 0x2000 for that drive in your config file or in userconfig, as you would the 32-bit-PIO flag. the driver will then turn on DMA support if your drive and controller pass its tests. it's a bit picky, probably. on discovering DMA mode failures or disk errors or transfers that the DMA controller can't deal with, the driver will fall back to PIO, so it is wise to setup the flags as if PIO were still important. 'controller wdc0 at isa? port "IO_WD1" bio irq 14 flags 0xa0ffa0ff vector wdintr' should work with nearly any PCI IDE controller. i would *strongly* suggest booting single-user at first, and thrashing the drive a bit while it's still mounted read-only. this should be fairly safe, even if the driver goes completely out to lunch. it might save you a reinstall. one way to tell whether the driver is really using DMA is to check the interrupt count during disk i/o with vmstat; DMA mode will add an extremely low number of interrupts, as compared to even multi-sector PIO. boot -v will give you a copious register dump of timing-related info on Intel and VIAtech chipsets, as well as PIO/DMA mode information on all hard drives. refer to your ATA and chipset documentation to interpret these. WHAT I'D LIKE FROM YOU and THINGS TO TEST: reports. success reports, failure reports, any kind of reports. :) send them to cgull+ide@smoke.marlboro.vt.us. i'd also like to see the kernel messages from various BIOSes (boot -v; dmesg), along with info on the motherboard and BIOS on that machine. i'm especially interested in reports on how this code works on the various Intel chipsets, and whether the register dump works correctly. i'm also interested in hearing about other chipsets. i'm especially interested in hearing success/failure reports for PCI IDE controllers on cards, such as CMD's or Promise's new busmastering IDE controllers. UltraDMA-33 reports. interoperation with ATAPI peripherals-- FreeBSD doesn't work with my old Hitachi IDE CDROM, so i can't tell if I've broken anything. :) i'd especially like to hear how the drive copes in DMA operation on drives with bad sectors. i haven't been able to find any such yet. success/failure reports on older IDE drives with early support for DMA modes-- those introduced between 1.5 and 3 years ago, typically ranging from perhaps 400MB to 1.6GB. failure reports on operation with more than one drive would be appreciated. the driver was developed with two drives on one controller, the worst-case situation, and has been tested with one drive on each controller, but you never know... any reports of messages from the driver during normal operation, especially "reverting to PIO mode", or "dmaverify odd vaddr or length" (the DMA controller is strongly halfword oriented, and i'm curious to know if any FreeBSD usage actually needs misaligned transfers). performance reports. beware that bonnie's CPU usage reporting is useless for IDE drives; the best test i've found has been to run a program that runs a spin loop at an idle priority and reports how many iterations it manages, and even that sometimes produces numbers i don't believe. performance reports of multi-drive operation are especially interesting; my system cannot sustain full throughput on two drives on separate controllers, but that may just be a lame motherboard. THINGS I'M STILL MISSING CLUE ON: * who's responsible for configuring DMA timing modes on IDE drives? the BIOS or the driver? * is there a spec for dealing with Ultra-DMA extensions? * are there any chipsets or with bugs relating to DMA transfer that should be blacklisted? * are there any ATA interfaces that use some other kind of DMA controller in conjunction with standard ATA protocol? FINAL NOTE: after having looked at the ATA-3 spec, all i can say is, "it's ugly". *especially* electrically. the IDE bus is best modeled as an unterminated transmission line, these days. for maximum reliability, keep your IDE cables as short as possible and as few as possible. from what i can tell, most current chipsets have both IDE ports wired into a single buss, to a greater or lesser degree. using two cables means you double the length of this bus. SCSI may have its warts, but at least the basic analog design of the bus is still somewhat reasonable. IDE passed beyond the veil two years ago. --John Hood, cgull@smoke.marlboro.vt.us
1997-07-29 12:57:25 +00:00
#if 0
/* ide_pci takes care of this now */
case 0x71118086:
return ("Intel 82371AB IDE interface");
Add support for busmaster DMA on some PCI IDE chipsets. I changed a few bits here and there, mainly renaming wd82371.c to ide_pci.c now that it's supposed to handle different chipsets. It runs on my P6 natoma board with two Maxtor drives, and also on a Fujitsu machine I have at work with an Opti chipset and a Quantum drive. Submitted by:cgull@smoke.marlboro.vt.us <John Hood> Original readme: *** WARNING *** This code has so far been tested on exactly one motherboard with two identical drives known for their good DMA support. This code, in the right circumstances, could corrupt data subtly, silently, and invisibly, in much the same way that older PCI IDE controllers do. It's ALPHA-quality code; there's one or two major gaps in my understanding of PCI IDE still. Don't use this code on any system with data that you care about; it's only good for hack boxes. Expect that any data may be silently and randomly corrupted at any moment. It's a disk driver. It has bugs. Disk drivers with bugs munch data. It's a fact of life. I also *STRONGLY* recommend getting a copy of your chipset's manual and the ATA-2 or ATA-3 spec and making sure that timing modes on your disk drives and IDE controller are being setup correctly by the BIOS-- because the driver makes only the lamest of attempts to do this just now. *** END WARNING *** that said, i happen to think the code is working pretty well... WHAT IT DOES: this code adds support to the wd driver for bus mastering PCI IDE controllers that follow the SFF-8038 standard. (all the bus mastering PCI IDE controllers i've seen so far do follow this standard.) it should provide busmastering on nearly any current P5 or P6 chipset, specifically including any Intel chipset using one of the PIIX south bridges-- this includes the '430FX, '430VX, '430HX, '430TX, '440LX, and (i think) the Orion '450GX chipsets. specific support is also included for the VIA Apollo VP-1 chipset, as it appears in the relabeled "HXPro" incarnation seen on cheap US$70 taiwanese motherboards (that's what's in my development machine). it works out of the box on controllers that do DMA mode2; if my understanding is correct, it'll probably work on Ultra-DMA33 controllers as well. it'll probably work on busmastering IDE controllers in PCI slots, too, but this is an area i am less sure about. it cuts CPU usage considerably and improves drive performance slightly. usable numbers are difficult to come by with existing benchmark tools, but experimentation on my K5-P90 system, with VIA VP-1 chipset and Quantum Fireball 1080 drives, shows that disk i/o on raw partitions imposes perhaps 5% cpu load. cpu load during filesystem i/o drops a lot, from near 100% to anywhere between 30% and 70%. (the improvement may not be as large on an Intel chipset; from what i can tell, the VIA VP-1 may not be very efficient with PCI I/O.) disk performance improves by 5% or 10% with these drives. real, visible, end-user performance improvement on a single user machine is about nil. :) a kernel compile was sped up by a whole three seconds. it *does* feel a bit better-behaved when the system is swapping heavily, but a better disk driver is not the fix for *that* problem. THE CODE: this code is a patch to wd.c and wd82371.c, and associated header files. it should be considered alpha code; more work needs to be done. wd.c has fairly clean patches to add calls to busmaster code, as implemented in wd82371.c and potentially elsewhere (one could imagine, say, a Mac having a different DMA controller). wd82371.c has been considerably reworked: the wddma interface that it presents has been changed (expect more changes), many bugs have been fixed, a new internal interface has been added for supporting different chipsets, and the PCI probe has been considerably extended. the interface between wd82371.c and wd.c is still fairly clean, but i'm not sure it's in the right place. there's a mess of issues around ATA/ATAPI that need to be sorted out, including ATAPI support, CD-ROM support, tape support, LS-120/Zip support, SFF-8038i DMA, UltraDMA, PCI IDE controllers, bus probes, buggy controllers, controller timing setup, drive timing setup, world peace and kitchen sinks. whatever happens with all this and however it gets partitioned, it is fairly clear that wd.c needs some significant rework-- probably a complete rewrite. timing setup on disk controllers is something i've entirely punted on. on my development machine, it appears that the BIOS does at least some of the necessary timing setup. i chose to restrict operation to drives that are already configured for Mode4 PIO and Mode2 multiword DMA, since the timing is essentially the same and many if not most chipsets use the same control registers for DMA and PIO timing. does anybody *know* whether BIOSes are required to do timing setup for DMA modes on drives under their care? error recovery is probably weak. early on in development, i was getting drive errors induced by bugs in the driver; i used these to flush out the worst of the bugs in the driver's error handling, but problems may remain. i haven't got a drive with bad sectors i can watch the driver flail on. complaints about how wd82371.c has been reindented will be ignored until the FreeBSD project has a real style policy, there is a mechanism for individual authors to match it (indent flags or an emacs c-mode or whatever), and it is enforced. if i'm going to use a source style i don't like, it would help if i could figure out what it *is* (style(9) is about half of a policy), and a way to reasonably duplicate it. i ended up wasting a while trying to figure out what the right thing to do was before deciding reformatting the whole thing was the worst possible thing to do, except for all the other possibilities. i have maintained wd.c's indentation; that was not too hard, fortunately. TO INSTALL: my dev box is freebsd 2.2.2 release. fortunately, wd.c is a living fossil, and has diverged very little recently. included in this tarball is a patch file, 'otherdiffs', for all files except wd82371.c, my edited wd82371.c, a patch file, 'wd82371.c-diff-exact', against the 2.2.2 dist of 82371.c, and another patch file, 'wd82371.c-diff-whitespace', generated with diff -b (ignore whitespace). most of you not using 2.2.2 will probably have to use this last patchfile with 'patch --ignore-whitespace'. apply from the kernel source tree root. as far as i can tell, this should apply cleanly on anything from -current back to 2.2.2 and probably back to 2.2.0. you, the kernel hacker, can figure out what to do from here. if you need more specific directions, you probably should not be experimenting with this code yet. to enable DMA support, set flag 0x2000 for that drive in your config file or in userconfig, as you would the 32-bit-PIO flag. the driver will then turn on DMA support if your drive and controller pass its tests. it's a bit picky, probably. on discovering DMA mode failures or disk errors or transfers that the DMA controller can't deal with, the driver will fall back to PIO, so it is wise to setup the flags as if PIO were still important. 'controller wdc0 at isa? port "IO_WD1" bio irq 14 flags 0xa0ffa0ff vector wdintr' should work with nearly any PCI IDE controller. i would *strongly* suggest booting single-user at first, and thrashing the drive a bit while it's still mounted read-only. this should be fairly safe, even if the driver goes completely out to lunch. it might save you a reinstall. one way to tell whether the driver is really using DMA is to check the interrupt count during disk i/o with vmstat; DMA mode will add an extremely low number of interrupts, as compared to even multi-sector PIO. boot -v will give you a copious register dump of timing-related info on Intel and VIAtech chipsets, as well as PIO/DMA mode information on all hard drives. refer to your ATA and chipset documentation to interpret these. WHAT I'D LIKE FROM YOU and THINGS TO TEST: reports. success reports, failure reports, any kind of reports. :) send them to cgull+ide@smoke.marlboro.vt.us. i'd also like to see the kernel messages from various BIOSes (boot -v; dmesg), along with info on the motherboard and BIOS on that machine. i'm especially interested in reports on how this code works on the various Intel chipsets, and whether the register dump works correctly. i'm also interested in hearing about other chipsets. i'm especially interested in hearing success/failure reports for PCI IDE controllers on cards, such as CMD's or Promise's new busmastering IDE controllers. UltraDMA-33 reports. interoperation with ATAPI peripherals-- FreeBSD doesn't work with my old Hitachi IDE CDROM, so i can't tell if I've broken anything. :) i'd especially like to hear how the drive copes in DMA operation on drives with bad sectors. i haven't been able to find any such yet. success/failure reports on older IDE drives with early support for DMA modes-- those introduced between 1.5 and 3 years ago, typically ranging from perhaps 400MB to 1.6GB. failure reports on operation with more than one drive would be appreciated. the driver was developed with two drives on one controller, the worst-case situation, and has been tested with one drive on each controller, but you never know... any reports of messages from the driver during normal operation, especially "reverting to PIO mode", or "dmaverify odd vaddr or length" (the DMA controller is strongly halfword oriented, and i'm curious to know if any FreeBSD usage actually needs misaligned transfers). performance reports. beware that bonnie's CPU usage reporting is useless for IDE drives; the best test i've found has been to run a program that runs a spin loop at an idle priority and reports how many iterations it manages, and even that sometimes produces numbers i don't believe. performance reports of multi-drive operation are especially interesting; my system cannot sustain full throughput on two drives on separate controllers, but that may just be a lame motherboard. THINGS I'M STILL MISSING CLUE ON: * who's responsible for configuring DMA timing modes on IDE drives? the BIOS or the driver? * is there a spec for dealing with Ultra-DMA extensions? * are there any chipsets or with bugs relating to DMA transfer that should be blacklisted? * are there any ATA interfaces that use some other kind of DMA controller in conjunction with standard ATA protocol? FINAL NOTE: after having looked at the ATA-3 spec, all i can say is, "it's ugly". *especially* electrically. the IDE bus is best modeled as an unterminated transmission line, these days. for maximum reliability, keep your IDE cables as short as possible and as few as possible. from what i can tell, most current chipsets have both IDE ports wired into a single buss, to a greater or lesser degree. using two cables means you double the length of this bus. SCSI may have its warts, but at least the basic analog design of the bus is still somewhat reasonable. IDE passed beyond the veil two years ago. --John Hood, cgull@smoke.marlboro.vt.us
1997-07-29 12:57:25 +00:00
#endif
case 0x71128086:
return ("Intel 82371AB USB host controller");
case 0x71138086:
return ("Intel 82371AB power management");
case 0x70308086:
return ("Intel 82437VX PCI cache memory controller");
case 0x12378086:
fixwsc_natoma(tag);
return ("Intel 82440FX (Natoma) PCI and memory controller");
case 0x84c48086:
fixbushigh_orion(tag);
return ("Intel 82454KX/GX (Orion) host to PCI bridge");
case 0x84c58086:
return ("Intel 82453KX/GX (Orion) PCI memory controller");
case 0x00221014:
return ("IBM 82351 PCI-PCI bridge");
case 0x00011011:
return ("DEC 21050 PCI-PCI bridge");
case 0x124b8086:
return ("Intel 82380FB mobile PCI to PCI bridge");
/* VLSI -- vendor 0x1004 */
case 0x01011004:
return ("VLSI 82C532 Eagle II Peripheral Controller");
case 0x01021004:
return ("VLSI 82C534 Eagle II PCI Bus bridge");
case 0x01031004:
return ("VLSI 82C538 Eagle II PCI Docking bridge");
case 0x01041004:
return ("VLSI 82C535 Eagle II System Controller");
case 0x01051004:
return ("VLSI 82C147 IrDA Controller");
};
if (descr = generic_pci_bridge(tag))
return descr;
return NULL;
}
#ifndef PCI_QUIET
#define M_XX 0 /* end of list */
#define M_EQ 1 /* mask and return true if equal */
#define M_NE 2 /* mask and return true if not equal */
#define M_TR 3 /* don't read config, always true */
#define M_EN 4 /* mask and print "enabled" if true, "disabled" if false */
#define M_NN 5 /* opposite sense of M_EN */
static const struct condmsg conf82425ex[] =
{
{ 0x00, 0x00, 0x00, M_TR, "\tClock " },
{ 0x50, 0x06, 0x00, M_EQ, "25" },
{ 0x50, 0x06, 0x02, M_EQ, "33" },
{ 0x50, 0x04, 0x04, M_EQ, "??", },
{ 0x00, 0x00, 0x00, M_TR, "MHz, L1 Cache " },
{ 0x50, 0x01, 0x00, M_EQ, "Disabled\n" },
{ 0x50, 0x09, 0x01, M_EQ, "Write-through\n" },
{ 0x50, 0x09, 0x09, M_EQ, "Write-back\n" },
{ 0x00, 0x00, 0x00, M_TR, "\tL2 Cache " },
{ 0x52, 0x07, 0x00, M_EQ, "Disabled" },
{ 0x52, 0x0f, 0x01, M_EQ, "64KB Write-through" },
{ 0x52, 0x0f, 0x02, M_EQ, "128KB Write-through" },
{ 0x52, 0x0f, 0x03, M_EQ, "256KB Write-through" },
{ 0x52, 0x0f, 0x04, M_EQ, "512KB Write-through" },
{ 0x52, 0x0f, 0x01, M_EQ, "64KB Write-back" },
{ 0x52, 0x0f, 0x02, M_EQ, "128KB Write-back" },
{ 0x52, 0x0f, 0x03, M_EQ, "256KB Write-back" },
{ 0x52, 0x0f, 0x04, M_EQ, "512KB Write-back" },
{ 0x53, 0x01, 0x00, M_EQ, ", 3-" },
{ 0x53, 0x01, 0x01, M_EQ, ", 2-" },
{ 0x53, 0x06, 0x00, M_EQ, "3-3-3" },
{ 0x53, 0x06, 0x02, M_EQ, "2-2-2" },
{ 0x53, 0x06, 0x04, M_EQ, "1-1-1" },
{ 0x53, 0x06, 0x06, M_EQ, "?-?-?" },
{ 0x53, 0x18, 0x00, M_EQ, "/4-2-2-2\n" },
{ 0x53, 0x18, 0x08, M_EQ, "/3-2-2-2\n" },
{ 0x53, 0x18, 0x10, M_EQ, "/?-?-?-?\n" },
{ 0x53, 0x18, 0x18, M_EQ, "/2-1-1-1\n" },
{ 0x56, 0x00, 0x00, M_TR, "\tDRAM: " },
{ 0x56, 0x02, 0x02, M_EQ, "Fast Code Read, " },
{ 0x56, 0x04, 0x04, M_EQ, "Fast Data Read, " },
{ 0x56, 0x08, 0x08, M_EQ, "Fast Write, " },
{ 0x57, 0x20, 0x20, M_EQ, "Pipelined CAS" },
{ 0x57, 0x2e, 0x00, M_NE, "\n\t" },
{ 0x57, 0x00, 0x00, M_TR, "Timing: RAS: " },
{ 0x57, 0x07, 0x00, M_EQ, "4" },
{ 0x57, 0x07, 0x01, M_EQ, "3" },
{ 0x57, 0x07, 0x02, M_EQ, "2" },
{ 0x57, 0x07, 0x04, M_EQ, "1.5" },
{ 0x57, 0x07, 0x05, M_EQ, "1" },
{ 0x57, 0x00, 0x00, M_TR, " Clocks, CAS Read: " },
{ 0x57, 0x18, 0x00, M_EQ, "3/1", },
{ 0x57, 0x18, 0x00, M_EQ, "2/1", },
{ 0x57, 0x18, 0x00, M_EQ, "1.5/0.5", },
{ 0x57, 0x18, 0x00, M_EQ, "1/1", },
{ 0x57, 0x00, 0x00, M_TR, ", CAS Write: " },
{ 0x57, 0x20, 0x00, M_EQ, "2/1", },
{ 0x57, 0x20, 0x20, M_EQ, "1/1", },
{ 0x57, 0x00, 0x00, M_TR, "\n" },
{ 0x40, 0x01, 0x01, M_EQ, "\tCPU-to-PCI Byte Merging\n" },
{ 0x40, 0x02, 0x02, M_EQ, "\tCPU-to-PCI Bursting\n" },
{ 0x40, 0x04, 0x04, M_EQ, "\tPCI Posted Writes\n" },
{ 0x40, 0x20, 0x00, M_EQ, "\tDRAM Parity Disabled\n" },
{ 0x48, 0x03, 0x01, M_EQ, "\tPCI IDE controller: Primary (1F0h-1F7h,3F6h,3F7h)" },
{ 0x48, 0x03, 0x02, M_EQ, "\tPCI IDE controller: Secondary (170h-177h,376h,377h)" },
{ 0x4d, 0x01, 0x01, M_EQ, "\tRTC (70-77h)\n" },
{ 0x4d, 0x02, 0x02, M_EQ, "\tKeyboard (60,62,64,66h)\n" },
{ 0x4d, 0x08, 0x08, M_EQ, "\tIRQ12/M Mouse Function\n" },
/* end marker */
{ 0 }
};
static const struct condmsg conf82424zx[] =
{
{ 0x00, 0x00, 0x00, M_TR, "\tCPU: " },
{ 0x50, 0xe0, 0x00, M_EQ, "486DX" },
{ 0x50, 0xe0, 0x20, M_EQ, "486SX" },
{ 0x50, 0xe0, 0x40, M_EQ, "486DX2 or 486DX4" },
{ 0x50, 0xe0, 0x80, M_EQ, "Overdrive (writeback)" },
{ 0x00, 0x00, 0x00, M_TR, ", bus=" },
{ 0x50, 0x03, 0x00, M_EQ, "25MHz" },
{ 0x50, 0x03, 0x01, M_EQ, "33MHz" },
{ 0x53, 0x01, 0x01, M_TR, ", CPU->Memory posting "},
{ 0x53, 0x01, 0x00, M_EQ, "OFF" },
{ 0x53, 0x01, 0x01, M_EQ, "ON" },
{ 0x56, 0x30, 0x00, M_NE, "\n\tWarning:" },
{ 0x56, 0x20, 0x00, M_NE, " NO cache parity!" },
{ 0x56, 0x10, 0x00, M_NE, " NO DRAM parity!" },
{ 0x55, 0x04, 0x04, M_EQ, "\n\tWarning: refresh OFF! " },
{ 0x00, 0x00, 0x00, M_TR, "\n\tCache: " },
{ 0x52, 0x01, 0x00, M_EQ, "None" },
{ 0x52, 0xc1, 0x01, M_EQ, "64KB" },
{ 0x52, 0xc1, 0x41, M_EQ, "128KB" },
{ 0x52, 0xc1, 0x81, M_EQ, "256KB" },
{ 0x52, 0xc1, 0xc1, M_EQ, "512KB" },
{ 0x52, 0x03, 0x01, M_EQ, " writethrough" },
{ 0x52, 0x03, 0x03, M_EQ, " writeback" },
{ 0x52, 0x01, 0x01, M_EQ, ", cache clocks=" },
{ 0x52, 0x05, 0x01, M_EQ, "3-1-1-1" },
{ 0x52, 0x05, 0x05, M_EQ, "2-1-1-1" },
{ 0x00, 0x00, 0x00, M_TR, "\n\tDRAM:" },
{ 0x55, 0x43, 0x00, M_NE, " page mode" },
{ 0x55, 0x02, 0x02, M_EQ, " code fetch" },
{ 0x55, 0x43, 0x43, M_EQ, "," },
{ 0x55, 0x43, 0x42, M_EQ, " and" },
{ 0x55, 0x40, 0x40, M_EQ, " read" },
{ 0x55, 0x03, 0x03, M_EQ, " and" },
{ 0x55, 0x43, 0x41, M_EQ, " and" },
{ 0x55, 0x01, 0x01, M_EQ, " write" },
{ 0x55, 0x43, 0x00, M_NE, "," },
{ 0x00, 0x00, 0x00, M_TR, " memory clocks=" },
{ 0x55, 0x20, 0x00, M_EQ, "X-2-2-2" },
{ 0x55, 0x20, 0x20, M_EQ, "X-1-2-1" },
{ 0x00, 0x00, 0x00, M_TR, "\n\tCPU->PCI: posting " },
{ 0x53, 0x02, 0x00, M_NE, "ON" },
{ 0x53, 0x02, 0x00, M_EQ, "OFF" },
{ 0x00, 0x00, 0x00, M_TR, ", burst mode " },
{ 0x54, 0x02, 0x00, M_NE, "ON" },
{ 0x54, 0x02, 0x00, M_EQ, "OFF" },
{ 0x00, 0x00, 0x00, M_TR, "\n\tPCI->Memory: posting " },
{ 0x54, 0x01, 0x00, M_NE, "ON" },
{ 0x54, 0x01, 0x00, M_EQ, "OFF" },
{ 0x00, 0x00, 0x00, M_TR, "\n" },
/* end marker */
{ 0 }
};
static const struct condmsg conf82434lx[] =
{
{ 0x00, 0x00, 0x00, M_TR, "\tCPU: " },
{ 0x50, 0xe3, 0x82, M_EQ, "Pentium, 60MHz" },
{ 0x50, 0xe3, 0x83, M_EQ, "Pentium, 66MHz" },
{ 0x50, 0xe3, 0xa2, M_EQ, "Pentium, 90MHz" },
{ 0x50, 0xe3, 0xa3, M_EQ, "Pentium, 100MHz" },
{ 0x50, 0xc2, 0x82, M_NE, "(unknown)" },
{ 0x50, 0x04, 0x00, M_EQ, " (primary cache OFF)" },
{ 0x53, 0x01, 0x01, M_TR, ", CPU->Memory posting "},
{ 0x53, 0x01, 0x01, M_NE, "OFF" },
{ 0x53, 0x01, 0x01, M_EQ, "ON" },
{ 0x53, 0x08, 0x00, M_NE, ", read around write"},
{ 0x70, 0x04, 0x00, M_EQ, "\n\tWarning: Cache parity disabled!" },
{ 0x57, 0x20, 0x00, M_NE, "\n\tWarning: DRAM parity mask!" },
{ 0x57, 0x01, 0x00, M_EQ, "\n\tWarning: refresh OFF! " },
{ 0x00, 0x00, 0x00, M_TR, "\n\tCache: " },
{ 0x52, 0x01, 0x00, M_EQ, "None" },
{ 0x52, 0x81, 0x01, M_EQ, "" },
{ 0x52, 0xc1, 0x81, M_EQ, "256KB" },
{ 0x52, 0xc1, 0xc1, M_EQ, "512KB" },
{ 0x52, 0x03, 0x01, M_EQ, " writethrough" },
{ 0x52, 0x03, 0x03, M_EQ, " writeback" },
{ 0x52, 0x01, 0x01, M_EQ, ", cache clocks=" },
{ 0x52, 0x21, 0x01, M_EQ, "3-2-2-2/4-2-2-2" },
{ 0x52, 0x21, 0x21, M_EQ, "3-1-1-1" },
{ 0x52, 0x01, 0x01, M_EQ, "\n\tCache flags: " },
{ 0x52, 0x11, 0x11, M_EQ, " cache-all" },
{ 0x52, 0x09, 0x09, M_EQ, " byte-control" },
{ 0x52, 0x05, 0x05, M_EQ, " powersaver" },
{ 0x00, 0x00, 0x00, M_TR, "\n\tDRAM:" },
{ 0x57, 0x10, 0x00, M_EQ, " page mode" },
{ 0x00, 0x00, 0x00, M_TR, " memory clocks=" },
{ 0x57, 0xc0, 0x00, M_EQ, "X-4-4-4 (70ns)" },
{ 0x57, 0xc0, 0x40, M_EQ, "X-4-4-4/X-3-3-3 (60ns)" },
{ 0x57, 0xc0, 0x80, M_EQ, "???" },
{ 0x57, 0xc0, 0xc0, M_EQ, "X-3-3-3 (50ns)" },
{ 0x58, 0x02, 0x02, M_EQ, ", RAS-wait" },
{ 0x58, 0x01, 0x01, M_EQ, ", CAS-wait" },
{ 0x00, 0x00, 0x00, M_TR, "\n\tCPU->PCI: posting " },
{ 0x53, 0x02, 0x02, M_EQ, "ON" },
{ 0x53, 0x02, 0x00, M_EQ, "OFF" },
{ 0x00, 0x00, 0x00, M_TR, ", burst mode " },
{ 0x54, 0x02, 0x00, M_NE, "ON" },
{ 0x54, 0x02, 0x00, M_EQ, "OFF" },
{ 0x54, 0x04, 0x00, M_TR, ", PCI clocks=" },
{ 0x54, 0x04, 0x00, M_EQ, "2-2-2-2" },
{ 0x54, 0x04, 0x00, M_NE, "2-1-1-1" },
{ 0x00, 0x00, 0x00, M_TR, "\n\tPCI->Memory: posting " },
{ 0x54, 0x01, 0x00, M_NE, "ON" },
{ 0x54, 0x01, 0x00, M_EQ, "OFF" },
{ 0x57, 0x01, 0x01, M_EQ, "\n\tRefresh:" },
{ 0x57, 0x03, 0x03, M_EQ, " CAS#/RAS#(Hidden)" },
{ 0x57, 0x03, 0x01, M_EQ, " RAS#Only" },
{ 0x57, 0x05, 0x05, M_EQ, " BurstOf4" },
{ 0x00, 0x00, 0x00, M_TR, "\n" },
/* end marker */
{ 0 }
};
static const struct condmsg conf82378[] =
{
{ 0x00, 0x00, 0x00, M_TR, "\tBus Modes:" },
{ 0x41, 0x04, 0x04, M_EQ, " Bus Park," },
{ 0x41, 0x02, 0x02, M_EQ, " Bus Lock," },
{ 0x41, 0x02, 0x00, M_EQ, " Resource Lock," },
{ 0x41, 0x01, 0x01, M_EQ, " GAT" },
{ 0x4d, 0x20, 0x20, M_EQ, "\n\tCoprocessor errors enabled" },
{ 0x4d, 0x10, 0x10, M_EQ, "\n\tMouse function enabled" },
{ 0x4e, 0x30, 0x10, M_EQ, "\n\tIDE controller: Primary (1F0h-1F7h,3F6h,3F7h)" },
{ 0x4e, 0x30, 0x30, M_EQ, "\n\tIDE controller: Secondary (170h-177h,376h,377h)" },
{ 0x4e, 0x28, 0x08, M_EQ, "\n\tFloppy controller: 3F0h,3F1h " },
{ 0x4e, 0x24, 0x04, M_EQ, "\n\tFloppy controller: 3F2h-3F7h " },
{ 0x4e, 0x28, 0x28, M_EQ, "\n\tFloppy controller: 370h,371h " },
{ 0x4e, 0x24, 0x24, M_EQ, "\n\tFloppy controller: 372h-377h " },
{ 0x4e, 0x02, 0x02, M_EQ, "\n\tKeyboard controller: 60h,62h,64h,66h" },
{ 0x4e, 0x01, 0x01, M_EQ, "\n\tRTC: 70h-77h" },
{ 0x4f, 0x80, 0x80, M_EQ, "\n\tConfiguration RAM: 0C00h,0800h-08FFh" },
{ 0x4f, 0x40, 0x40, M_EQ, "\n\tPort 92: enabled" },
{ 0x4f, 0x03, 0x00, M_EQ, "\n\tSerial Port A: COM1 (3F8h-3FFh)" },
{ 0x4f, 0x03, 0x01, M_EQ, "\n\tSerial Port A: COM2 (2F8h-2FFh)" },
{ 0x4f, 0x0c, 0x00, M_EQ, "\n\tSerial Port B: COM1 (3F8h-3FFh)" },
{ 0x4f, 0x0c, 0x04, M_EQ, "\n\tSerial Port B: COM2 (2F8h-2FFh)" },
{ 0x4f, 0x30, 0x00, M_EQ, "\n\tParallel Port: LPT1 (3BCh-3BFh)" },
{ 0x4f, 0x30, 0x04, M_EQ, "\n\tParallel Port: LPT2 (378h-37Fh)" },
{ 0x4f, 0x30, 0x20, M_EQ, "\n\tParallel Port: LPT3 (278h-27Fh)" },
{ 0x00, 0x00, 0x00, M_TR, "\n" },
/* end marker */
{ 0 }
};
static const struct condmsg conf82437fx[] =
{
/* PCON -- PCI Control Register */
{ 0x00, 0x00, 0x00, M_TR, "\tCPU Inactivity timer: " },
{ 0x50, 0xe0, 0xe0, M_EQ, "8" },
{ 0x50, 0xe0, 0xd0, M_EQ, "7" },
{ 0x50, 0xe0, 0xc0, M_EQ, "6" },
{ 0x50, 0xe0, 0xb0, M_EQ, "5" },
{ 0x50, 0xe0, 0xa0, M_EQ, "4" },
{ 0x50, 0xe0, 0x90, M_EQ, "3" },
{ 0x50, 0xe0, 0x80, M_EQ, "2" },
{ 0x50, 0xe0, 0x00, M_EQ, "1" },
{ 0x00, 0x00, 0x00, M_TR, " clocks\n\tPeer Concurrency: " },
{ 0x50, 0x08, 0x08, M_EN, 0 },
1996-01-23 21:31:51 +00:00
{ 0x00, 0x00, 0x00, M_TR, "\n\tCPU-to-PCI Write Bursting: " },
{ 0x50, 0x04, 0x00, M_NN, 0 },
{ 0x00, 0x00, 0x00, M_TR, "\n\tPCI Streaming: " },
{ 0x50, 0x02, 0x00, M_NN, 0 },
{ 0x00, 0x00, 0x00, M_TR, "\n\tBus Concurrency: " },
{ 0x50, 0x01, 0x00, M_NN, 0 },
/* CC -- Cache Control Regsiter */
{ 0x00, 0x00, 0x00, M_TR, "\n\tCache:" },
{ 0x52, 0xc0, 0x80, M_EQ, " 512K" },
{ 0x52, 0xc0, 0x40, M_EQ, " 256K" },
{ 0x52, 0xc0, 0x00, M_EQ, " NO" },
{ 0x52, 0x30, 0x00, M_EQ, " pipelined-burst" },
{ 0x52, 0x30, 0x10, M_EQ, " burst" },
{ 0x52, 0x30, 0x20, M_EQ, " asynchronous" },
{ 0x52, 0x30, 0x30, M_EQ, " dual-bank pipelined-burst" },
{ 0x00, 0x00, 0x00, M_TR, " secondary; L1 " },
{ 0x52, 0x01, 0x00, M_EN, 0 },
{ 0x00, 0x00, 0x00, M_TR, "\n" },
/* DRAMC -- DRAM Control Register */
{ 0x57, 0x07, 0x00, M_EQ, "Warning: refresh OFF!\n" },
{ 0x00, 0x00, 0x00, M_TR, "\tDRAM:" },
{ 0x57, 0xc0, 0x00, M_EQ, " no memory hole" },
{ 0x57, 0xc0, 0x40, M_EQ, " 512K-640K memory hole" },
{ 0x57, 0xc0, 0x80, M_EQ, " 15M-16M memory hole" },
{ 0x57, 0x07, 0x01, M_EQ, ", 50 MHz refresh" },
{ 0x57, 0x07, 0x02, M_EQ, ", 60 MHz refresh" },
{ 0x57, 0x07, 0x03, M_EQ, ", 66 MHz refresh" },
/* DRAMT = DRAM Timing Register */
{ 0x00, 0x00, 0x00, M_TR, "\n\tRead burst timing: " },
{ 0x58, 0x60, 0x00, M_EQ, "x-4-4-4/x-4-4-4" },
{ 0x58, 0x60, 0x20, M_EQ, "x-3-3-3/x-4-4-4" },
{ 0x58, 0x60, 0x40, M_EQ, "x-2-2-2/x-3-3-3" },
{ 0x58, 0x60, 0x60, M_EQ, "???" },
{ 0x00, 0x00, 0x00, M_TR, "\n\tWrite burst timing: " },
{ 0x58, 0x18, 0x00, M_EQ, "x-4-4-4" },
{ 0x58, 0x18, 0x08, M_EQ, "x-3-3-3" },
{ 0x58, 0x18, 0x10, M_EQ, "x-2-2-2" },
{ 0x58, 0x18, 0x18, M_EQ, "???" },
{ 0x00, 0x00, 0x00, M_TR, "\n\tRAS-CAS delay: " },
{ 0x58, 0x04, 0x00, M_EQ, "3" },
{ 0x58, 0x04, 0x04, M_EQ, "2" },
{ 0x00, 0x00, 0x00, M_TR, " clocks\n" },
/* end marker */
{ 0 }
};
static const struct condmsg conf82437vx[] =
{
/* PCON -- PCI Control Register */
{ 0x00, 0x00, 0x00, M_TR, "\n\tPCI Concurrency: " },
{ 0x50, 0x08, 0x08, M_EN, 0 },
/* CC -- Cache Control Regsiter */
{ 0x00, 0x00, 0x00, M_TR, "\n\tCache:" },
{ 0x52, 0xc0, 0x80, M_EQ, " 512K" },
{ 0x52, 0xc0, 0x40, M_EQ, " 256K" },
{ 0x52, 0xc0, 0x00, M_EQ, " NO" },
{ 0x52, 0x30, 0x00, M_EQ, " pipelined-burst" },
{ 0x52, 0x30, 0x10, M_EQ, " burst" },
{ 0x52, 0x30, 0x20, M_EQ, " asynchronous" },
{ 0x52, 0x30, 0x30, M_EQ, " dual-bank pipelined-burst" },
{ 0x00, 0x00, 0x00, M_TR, " secondary; L1 " },
{ 0x52, 0x01, 0x00, M_EN, 0 },
{ 0x00, 0x00, 0x00, M_TR, "\n" },
/* DRAMC -- DRAM Control Register */
{ 0x57, 0x07, 0x00, M_EQ, "Warning: refresh OFF!\n" },
{ 0x00, 0x00, 0x00, M_TR, "\tDRAM:" },
{ 0x57, 0xc0, 0x00, M_EQ, " no memory hole" },
{ 0x57, 0xc0, 0x40, M_EQ, " 512K-640K memory hole" },
{ 0x57, 0xc0, 0x80, M_EQ, " 15M-16M memory hole" },
{ 0x57, 0x07, 0x01, M_EQ, ", 50 MHz refresh" },
{ 0x57, 0x07, 0x02, M_EQ, ", 60 MHz refresh" },
{ 0x57, 0x07, 0x03, M_EQ, ", 66 MHz refresh" },
/* DRAMT = DRAM Timing Register */
{ 0x00, 0x00, 0x00, M_TR, "\n\tRead burst timing: " },
{ 0x58, 0x60, 0x00, M_EQ, "x-4-4-4/x-4-4-4" },
{ 0x58, 0x60, 0x20, M_EQ, "x-3-3-3/x-4-4-4" },
{ 0x58, 0x60, 0x40, M_EQ, "x-2-2-2/x-3-3-3" },
{ 0x58, 0x60, 0x60, M_EQ, "???" },
{ 0x00, 0x00, 0x00, M_TR, "\n\tWrite burst timing: " },
{ 0x58, 0x18, 0x00, M_EQ, "x-4-4-4" },
{ 0x58, 0x18, 0x08, M_EQ, "x-3-3-3" },
{ 0x58, 0x18, 0x10, M_EQ, "x-2-2-2" },
{ 0x58, 0x18, 0x18, M_EQ, "???" },
{ 0x00, 0x00, 0x00, M_TR, "\n\tRAS-CAS delay: " },
{ 0x58, 0x04, 0x00, M_EQ, "3" },
{ 0x58, 0x04, 0x04, M_EQ, "2" },
{ 0x00, 0x00, 0x00, M_TR, " clocks\n" },
/* end marker */
{ 0 }
};
static const struct condmsg conf82371fb[] =
{
/* IORT -- ISA I/O Recovery Timer Register */
{ 0x00, 0x00, 0x00, M_TR, "\tI/O Recovery Timing: 8-bit " },
{ 0x4c, 0x40, 0x00, M_EQ, "3.5" },
{ 0x4c, 0x78, 0x48, M_EQ, "1" },
{ 0x4c, 0x78, 0x50, M_EQ, "2" },
{ 0x4c, 0x78, 0x58, M_EQ, "3" },
{ 0x4c, 0x78, 0x60, M_EQ, "4" },
{ 0x4c, 0x78, 0x68, M_EQ, "5" },
{ 0x4c, 0x78, 0x70, M_EQ, "6" },
{ 0x4c, 0x78, 0x78, M_EQ, "7" },
{ 0x4c, 0x78, 0x40, M_EQ, "8" },
{ 0x00, 0x00, 0x00, M_TR, " clocks, 16-bit " },
{ 0x4c, 0x04, 0x00, M_EQ, "3.5" },
{ 0x4c, 0x07, 0x05, M_EQ, "1" },
{ 0x4c, 0x07, 0x06, M_EQ, "2" },
{ 0x4c, 0x07, 0x07, M_EQ, "3" },
{ 0x4c, 0x07, 0x04, M_EQ, "4" },
{ 0x00, 0x00, 0x00, M_TR, " clocks\n" },
/* XBCS -- X-Bus Chip Select Register */
{ 0x00, 0x00, 0x00, M_TR, "\tExtended BIOS: " },
{ 0x4e, 0x80, 0x80, M_EN, 0 },
{ 0x00, 0x00, 0x00, M_TR, "\n\tLower BIOS: " },
{ 0x4e, 0x40, 0x40, M_EN, 0 },
{ 0x00, 0x00, 0x00, M_TR, "\n\tCoprocessor IRQ13: " },
{ 0x4e, 0x20, 0x20, M_EN, 0 },
{ 0x00, 0x00, 0x00, M_TR, "\n\tMouse IRQ12: " },
{ 0x4e, 0x10, 0x10, M_EN, 0 },
{ 0x00, 0x00, 0x00, M_TR, "\n" },
{ 0x00, 0x00, 0x00, M_TR, "\tInterrupt Routing: " },
#define PIRQ(x, n) \
{ 0x00, 0x00, 0x00, M_TR, n ": " }, \
{ x, 0x80, 0x80, M_EQ, "disabled" }, \
{ x, 0xc0, 0x40, M_EQ, "[shared] " }, \
{ x, 0x8f, 0x03, M_EQ, "IRQ3" }, \
{ x, 0x8f, 0x04, M_EQ, "IRQ4" }, \
{ x, 0x8f, 0x05, M_EQ, "IRQ5" }, \
{ x, 0x8f, 0x06, M_EQ, "IRQ6" }, \
{ x, 0x8f, 0x07, M_EQ, "IRQ7" }, \
{ x, 0x8f, 0x09, M_EQ, "IRQ9" }, \
{ x, 0x8f, 0x0a, M_EQ, "IRQ10" }, \
{ x, 0x8f, 0x0b, M_EQ, "IRQ11" }, \
{ x, 0x8f, 0x0c, M_EQ, "IRQ12" }, \
{ x, 0x8f, 0x0e, M_EQ, "IRQ14" }, \
{ x, 0x8f, 0x0f, M_EQ, "IRQ15" }
/* Interrupt routing */
PIRQ(0x60, "A"),
PIRQ(0x61, ", B"),
PIRQ(0x62, ", C"),
PIRQ(0x63, ", D"),
PIRQ(0x70, "\n\t\tMB0"),
PIRQ(0x71, ", MB1"),
{ 0x00, 0x00, 0x00, M_TR, "\n" },
#undef PIRQ
/* XXX - do DMA routing, too? */
{ 0 }
};
static const struct condmsg conf82371fb2[] =
{
/* IDETM -- IDE Timing Register */
{ 0x00, 0x00, 0x00, M_TR, "\tPrimary IDE: " },
{ 0x41, 0x80, 0x80, M_EN, 0 },
{ 0x00, 0x00, 0x00, M_TR, "\n\tSecondary IDE: " },
{ 0x43, 0x80, 0x80, M_EN, 0 },
{ 0x00, 0x00, 0x00, M_TR, "\n" },
/* end of list */
{ 0 }
};
static char confread (pcici_t config_id, int port)
{
unsigned long portw = port & ~3;
unsigned long ports = (port - portw) << 3;
unsigned long l = pci_conf_read (config_id, portw);
return (l >> ports);
}
static void
writeconfig (pcici_t config_id, const struct condmsg *tbl)
{
while (tbl->flags != M_XX) {
const char *text = 0;
if (tbl->flags == M_TR) {
text = tbl->text;
} else {
unsigned char v = (unsigned char) confread(config_id, tbl->port);
switch (tbl->flags) {
case M_EQ:
if ((v & tbl->mask) == tbl->value) text = tbl->text;
break;
case M_NE:
if ((v & tbl->mask) != tbl->value) text = tbl->text;
break;
case M_EN:
text = (v & tbl->mask) ? "enabled" : "disabled";
break;
case M_NN:
text = (v & tbl->mask) ? "disabled" : "enabled";
}
}
if (text) printf ("%s", text);
tbl++;
}
}
#ifdef DUMPCONFIGSPACE
static void
dumpconfigspace (pcici_t tag)
{
int reg;
printf ("configuration space registers:");
for (reg = 0; reg < 0x100; reg+=4) {
if ((reg & 0x0f) == 0)
printf ("\n%02x:\t", reg);
printf ("%08x ", pci_conf_read (tag, reg));
}
printf ("\n");
}
#endif /* DUMPCONFIGSPACE */
#endif /* PCI_QUIET */
static void
chipset_attach (pcici_t config_id, int unit)
{
#ifndef PCI_QUIET
if (!bootverbose)
return;
switch (pci_conf_read (config_id, PCI_ID_REG)) {
case 0x04868086:
writeconfig (config_id, conf82425ex);
break;
case 0x04838086:
writeconfig (config_id, conf82424zx);
break;
case 0x04a38086:
writeconfig (config_id, conf82434lx);
break;
case 0x04848086:
writeconfig (config_id, conf82378);
break;
case 0x122d8086:
writeconfig (config_id, conf82437fx);
break;
case 0x70308086:
writeconfig (config_id, conf82437vx);
break;
case 0x70008086:
case 0x122e8086:
writeconfig (config_id, conf82371fb);
break;
case 0x70108086:
case 0x12308086:
writeconfig (config_id, conf82371fb2);
break;
#if 0
case 0x00011011: /* DEC 21050 */
case 0x00221014: /* IBM xxx */
writeconfig (config_id, conf_pci2pci);
break;
#endif
};
#endif /* PCI_QUIET */
}
/*---------------------------------------------------------
**
** Catchall driver for VGA devices
**
** By Garrett Wollman
** <wollman@halloran-eldar.lcs.mit.edu>
**
**---------------------------------------------------------
*/
static char* vga_probe (pcici_t tag, pcidi_t type);
static void vga_attach (pcici_t tag, int unit);
static u_long vga_count;
static struct pci_device vga_device = {
"vga",
vga_probe,
vga_attach,
&vga_count,
NULL
};
DATA_SET (pcidevice_set, vga_device);
static char* vga_probe (pcici_t tag, pcidi_t type)
{
int data = pci_conf_read(tag, PCI_CLASS_REG);
switch (data & PCI_CLASS_MASK) {
case PCI_CLASS_PREHISTORIC:
if ((data & PCI_SUBCLASS_MASK)
!= PCI_SUBCLASS_PREHISTORIC_VGA)
break;
case PCI_CLASS_DISPLAY:
if ((data & PCI_SUBCLASS_MASK)
== PCI_SUBCLASS_DISPLAY_VGA)
return ("VGA-compatible display device");
else
return ("Display device");
};
return ((char*)0);
}
static void vga_attach (pcici_t tag, int unit)
{
/*
** If the assigned addresses are remapped,
** the console driver has to be informed about the new address.
*/
#if 0
vm_offset_t va;
vm_offset_t pa;
int reg;
for (reg = PCI_MAP_REG_START; reg < PCI_MAP_REG_END; reg += 4)
(void) pci_map_mem (tag, reg, &va, &pa);
#endif
}
/*---------------------------------------------------------
**
** Hook for loadable pci drivers
**
**---------------------------------------------------------
*/
static char* lkm_probe (pcici_t tag, pcidi_t type);
static void lkm_attach (pcici_t tag, int unit);
static u_long lkm_count;
static struct pci_device lkm_device = {
"lkm",
lkm_probe,
lkm_attach,
&lkm_count,
NULL
};
DATA_SET (pcidevice_set, lkm_device);
static char*
lkm_probe (pcici_t tag, pcidi_t type)
{
/*
** Not yet!
** (Should try to load a matching driver)
*/
return ((char*)0);
}
static void
lkm_attach (pcici_t tag, int unit)
{}
/*---------------------------------------------------------
**
** Devices to ignore
**
**---------------------------------------------------------
*/
static char* ign_probe (pcici_t tag, pcidi_t type);
static void ign_attach (pcici_t tag, int unit);
static u_long ign_count;
static struct pci_device ign_device = {
NULL,
ign_probe,
ign_attach,
&ign_count,
NULL
};
DATA_SET (pcidevice_set, ign_device);
static char*
ign_probe (pcici_t tag, pcidi_t type)
{
switch (type) {
case 0x10001042ul: /* wd */
return ("");
1995-07-27 22:14:25 +00:00
/* return ("SMC FDC 37c665");*/
};
return ((char*)0);
}
static void
ign_attach (pcici_t tag, int unit)
{}