summaryrefslogtreecommitdiffstats
path: root/sys/pci/ide_pci.c
Commit message (Collapse)AuthorAgeFilesLines
* Remove left over pci_ide* after wd removal.peter2000-03-151-1876/+0
|
* Remove #include "wd.h" and #if NWDC > 0 as that's always true as thispeter2000-01-291-6/+0
| | | | | file is 'optional wdc' (note wd.h has both NWDC and NWD in it because of config quirks)
* Remove some horrible #if 0'd code that has no hope of working now. Itpeter1999-12-121-71/+0
| | | | | | used to edit the old-style isa_devtab config tables to insert a mapping for a pci device into the isa tables so that the wdc driver could probe it later. This has been #if 0'd since April.
* $Id$ -> $FreeBSD$peter1999-08-281-1/+1
|
* Revert out part of the last patch that can be done better elsewhere.julian1999-07-221-8/+4
| | | | The complexity added isn't worth it.
* fix braino..julian1999-07-221-2/+2
| | | | | | accidentally replaced PAGE_MASK with PAGE_SIZE. (PAGE_MASK is PAGE_SIZE - 1) bug does not manifest itself on our hardware.....
* Hopefully make the CMD640B workaround actually work.peter1999-07-211-9/+6
|
* Slight cleanups of the Cyrix 5530 UDMA code.julian1999-07-201-100/+125
| | | | | | Also includes a workaround fro an apparent chip bug where UDMA mode 2 can overpower the UDMA engine enough that it will hog the PCI bus to the exclusion of the processor.
* Only have the pci component compiled if pci is specified at config.peter1999-07-031-4/+1
| | | | Remove #if NPCI > 0 as a result.
* Simplify the COMPAT_PCI_DRIVER/DATA_SET hack. We can add:peter1999-05-091-5/+1
| | | | | | | | #define COMPAT_PCI_DRIVER(name,data) DATA_SET(pcidevice_set,data) .. to 2.2.x and 3.x if people think it's worth it. Driver writers can do this if it's not defined. (The reason for this is that I'm trying to progressively eliminate use of linker_sets where it hurts modularity and runtime load capability, and these DATA_SET's keep getting in the way.)
* Use COMPAT_PCI_DRIVER() for registration if it exists. This shouldn'tpeter1999-04-241-1/+5
| | | | hurt the driver portability to 3.x too much for where drivers are shared.
* Bring the 'new-bus' to the i386. This extensively changes the way thepeter1999-04-161-2/+3
| | | | | | | | | | | | | | | | | | i386 platform boots, it is no longer ISA-centric, and is fully dynamic. Most old drivers compile and run without modification via 'compatability shims' to enable a smoother transition. eisa, isapnp and pccard* are not yet using the new resource manager. Once fully converted, all drivers will be loadable, including PCI and ISA. (Some other changes appear to have snuck in, including a port of Soren's ATA driver to the Alpha. Soren, back this out if you need to.) This is a checkpoint of work-in-progress, but is quite functional. The bulk of the work was done over the last few years by Doug Rabson and Garrett Wollman. Approved by: core
* Build the functionality of the wdc_p hack into the ide_pci.c code.peter1999-04-131-3/+12
| | | | | | | | | | | | All it did was match a specific device ID and turn on a quirk for the wdc driver. Incidently, at line 1462 there is a return that prevents the generic ide_pci code from trying to look at the device. I'd be interested to know if we can take out the return and let the generic code "see" it. I've left the return in because that's the way it worked before. (Be sure to rerun config after cvsup or you'll get undefined files!)
* Shoot the LKM support in the old wd/wdc/atapi driver set in the head andpeter1999-04-131-8/+3
| | | | | | | | | | | | | | | | | perform a cleanup/unifdef sweep over it to tidy things up. The atapi code is permanently attached to the wd driver and is always probed. I will add an extra option bit in the flags to disable an atapi probe on either the master or slave if needed, if people want this. Remember, this driver is destined to die some time. It's possible that it will loose all atapi support down the track and only be used for dumb non-ATA disks and all ata/atapi devices will be handled by the new ata system. ATAPI, ATAPI_STATIC and CMD640 are no longer options, all are implicit. Previously discussed with: sos
* Add support for SiS 5591/5595 chipset.grog1999-03-281-3/+224
| | | | | | | | | | | | | Contributed-by: "Richard Seaman, Jr." <dick@tar.com> Tested-by: Chris Piazza <cpiazza@home.net> Tugrul Galatali <tugrul@ianai.BlackSun.org> grog This code includes lots of stuff for verbose probing. I'm not 100% sure that the output of the verbose probe is correct, but everything else works fine, and -CURRENT was broken for the 5591 before, so I'm committing it anyway.
* Pass the unit number to the DMA cookie lookup routine and use itbde1999-01-171-5/+6
| | | | | | | | | | | | to look up cookies properly, at least for standard controllers. Cookies are used so that we don't have to pass around lots of args. All of the dmainit functions use the unit number so it is essential that we pass them a cookie with the correct unit number. This may break working configurations if there are bugs in the dmainit functions like the ones I just fixed for VIA chipsets. Broken in: rev 1.4 of ide_pci.c and rev.1.139 of wd.c.
* Fixed a 2-bit error in initializing MWDMA mode for VIA chipsets.bde1999-01-171-3/+2
| | | | | | | | | Prefetch/postwrite was enabled for the wrong controller. (VIA is bitwise big endian and we confused ourself by shifting left instead of right.) Extracted from: last set of patches from the author (john hood <cgull@smoke.marlboro.vt.us>) on 7 Feb 1998
* Fixed a 1-bit error in initializing UDMA mode for VIA chipsets.bde1999-01-161-2/+2
| | | | | | | | | | | | | | Instead of initializing UDMA mode, we turned it off and made sure that it stays off by turning on the "UDMA enable by SET FEATURES" disable. The damage was limited by bugs in cookie lookup, and suitable initialization by some BIOSes. The cookie list has slaves before masters, and the unit number is ignored when cookies are looked up, so cookie lookup always finds cookies for slaves and the bug only clobbers slaves, so the bug was harmless for common configurations with no slaves or only non-UDMA slaves. UDMA initialization for masters actually worked if the BIOS turns on the UDMA mode bit and turns off the "UDMA enable by SET FEATURES" disable.
* Spell "ctlr" consistently.msmith1999-01-161-4/+4
|
* Fix breakage in rev 1.19; the second argument to ide_pci_candma is amsmith1999-01-161-4/+4
| | | | controller number, not a unit number. Make this clear.
* Add support for the ACER LABS Aladin chipset UDMA controller.julian1999-01-131-5/+87
| | | | Submitted by: Lee Cremeans <lee@st-lcremean.tidalwave.net>
* Clean out warnings introduced in last commit.eivind1999-01-121-4/+4
|
* remove some unused variablesjulian1999-01-111-8/+7
|
* Add support for the Cyrix Cx5530 PCI/ISA bridge which also includesjulian1999-01-111-15/+208
| | | | a PCI UDMA IDE controller.
* Check for DMA capbility is against unit,not controller.msmith1998-12-211-2/+2
| | | | Submitted by: Lee Cremeans <lee@st-lcremean.tidalwave.net>
* Fix uninitialized variable warning by preinitializing 'class' to 0. Thisdillon1998-12-141-2/+2
| | | | wasn't a bug, just added to silence a warning.
* pci_device pd_probe function changed from returning char * to returningdillon1998-12-141-2/+2
| | | | | | const char *. Originally I was going to add casts from const char * to char * in some of the pci device drivers, but the reality is that the pci device probes return constant quoted strings.
* Eliminate compiler warning.archie1998-12-101-2/+5
|
* Fix typo: expression needs parenthesesarchie1998-12-041-3/+3
| | | | | PR: 8280 (3/3 patches contained in this PR) Submitted by: Sakari Jalovaara <sja@tekla.fi>
* Cast pointers to uintptr_t/intptr_t instead of to u_long/long,bde1998-07-151-2/+2
| | | | | | | respectively. Most of the longs should probably have been u_longs, but this changes is just to prevent warnings about casts between pointers and integers of different sizes, not to fix poorly chosen types.
* Fixed printf format errors.bde1998-07-111-13/+16
|
* Don't declare isa device structs or isa interrupt handlers in <sys/conf>,bde1998-06-171-2/+1
| | | | | | | and don't depend on them being declared there. This will cause lots of warnings for a few minutes until config is updated. Interrupt handlers should never have been configured by config, and the machine generated declarations get in the way of changing the arg type from int to void *.
* Fixed a misdeclaration. This unhides type mismatches which will bebde1998-06-171-2/+2
| | | | fixed soon.
* Support compiling with `gcc -ansi'.bde1998-04-151-5/+5
|
* Back out DIAGNOSTIC changes.eivind1998-02-061-3/+1
|
* Turn DIAGNOSTIC into a new-style option.eivind1998-02-041-1/+3
|
* Include pc98.h instead of isa.h when PC98 is defined.kato1998-01-141-1/+5
|
* Correct the check for multiword dma. It was incorrectly checkingdyson1997-12-191-2/+2
| | | | | for multiword dma mode 4 (which doesn't exist.) Submitted by: John Hood
* Remove a bunch of variables which were unused both in GENERIC and LINT.phk1997-11-071-7/+3
| | | | Found by: -Wunused
* Addition of support of the slightly rogue Promise IDE interface(Dyson), supportdyson1997-09-201-610/+1088
| | | | | | | | | | | of multiple PCI IDE controllers(Dyson), and some updates and cleanups from John Hood, who originally made our IDE DMA stuff work :-). I have run tests with 7 IDE drives connected to my system, all in DMA mode, with no errors. Modulo any bugs, this stuff makes IDE look really good (within it's limitations.) Submitted by: John Hood <cgull@smoke.marlboro.vt.us>
* Upgrade of EIDE DMA support, Johns comments:sos1997-09-041-245/+387
| | | | | | | | | | | | * lots of fixes to error handling-- mostly works now * improve DMA timing config for Triton chipsets-- PIIX4 and UDMA drive still untested * generally improve DMA config in many ways-- mostly cleanup * clean up boot-time messages * rewrite PRD generation algorithm * first wd timeout is now longer, to handle drive spinup Submitted by: John Hood <cgull@smoke.marlboro.vt.us>
* Removed unused #includes.bde1997-08-021-5/+1
|
* Add support for busmaster DMA on some PCI IDE chipsets.sos1997-07-291-0/+817
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
OpenPOWER on IntegriCloud