Commit Graph

452 Commits

Author SHA1 Message Date
Stefan Eßer
2841b4feff Prepare for 64bit programming environment (e.g. Alpha):
Use "ncrcmd" or "u_int32_t" instead of "u_long", where appropriate.

Submitted by:	Gerard Roudier <groudier@club-internet.fr>
1997-08-31 19:42:31 +00:00
Stefan Eßer
7d4936dc38 Remove debug printf() that had been ommited by accident. 1997-08-31 19:36:56 +00:00
Stefan Eßer
71b8fb2a93 Fix problem with early revision 53c825a and 53c875 chips, which
could cause a solid system lockup in the driver attach:

These chips do not abort an access to the internal SRAM, when
the driver set the software reset bit in the istat register. But
the chip will never acknowledge the requested PCI bus transfer
in the situation, causing an infinite wait and a lockout of other
bus-masters.

The problem has been reported for rev 0x11 of the 53c825a and
rev 0x01 of the 53c875.
Revisions 0x13 of the 53c825a and 0x03 of the 53c875 are known
to support SRAM accesses, even in the software reset state.
1997-08-31 19:35:52 +00:00
Jun-ichiro itojun Hagino
9b95d17f6f Scsi RESERVATION CONFLICT and BUSY support for Tekram scsi cards.
Checked with DC390.  Pls mail me if you have any trouble with this patch.
1997-08-30 05:49:20 +00:00
Stefan Eßer
02d18b728b Go back to previous definition of FE_CACHE_SET, since the problem
caused by read-multiple on the 53c810a should have been fixed by
adjusting the alignment of the global header in rev 1.104 of ncr.c.
1997-08-24 06:24:51 +00:00
Stefan Eßer
230847098b Some cleanup and a fix for an assumed chip bug:
- Do not malloc SCRIPTS memory for those parts of the microcode that
  are to be loaded into the on-chip SRAM of the 53c825a or 875 ...
- Modify ncr_chip_lookup to make adding new entries easier.
- Disable use of on-chip SRAM for the 53c825 rev 0x10 to 0x12, since
  there seems to be a problem with rev 0x11, while 0x13 is known to
  work. (Tested by Chuck Robey <chuckr@glue.umd.edu>).

This code will be merged into 2.2-stable after a few more days of
testing in -current.
1997-08-23 22:01:49 +00:00
Stefan Eßer
e6344dbdaa Minor corrections to the code added in rev. 1.100 and 1.101:
- fix features of 53c860
- correctly adjust data structure to cache line boundary (32 bytes)

Submitted by:	Gerard Roudier <groudier@club-internet.fr>
1997-08-23 21:53:47 +00:00
Steve Passe
831b792e7f Yank the casts. 1997-08-21 08:42:59 +00:00
Steve Passe
d6f41fc926 Reorder function decls alphabetically. 1997-08-21 08:31:41 +00:00
Steve Passe
99216c6061 Add a cast to eliminate a compiler warning. 1997-08-21 07:35:23 +00:00
Steve Passe
1fa27e1c81 A few more casts and a function declaration for warning free kernel builds. 1997-08-21 07:05:54 +00:00
Steve Passe
737e75a810 Added frequencies for north american HRC cable.
Submitted by:	Yixin Jin <yjin@rain.cs.ucla.edu> (I think)
Resubmitted by:	Kenneth Merry <ken@gt.ed.net>
1997-08-17 05:50:56 +00:00
John Dyson
7197c8af33 SMP Natoma motherboards cannot know if you are booting a UP or SMP OS. This
mod makes sure that the Natoma chipset is set into the correct mode.  In
the case of my P6DNF, when booting a UP kernel, I see a substantial improvement
in the latency of certain operations.   It appears that the cache hit
latency is curiously improved the most, per lat_mem_rd.
1997-08-16 07:18:51 +00:00
Daniel O'Callaghan
26bb051a7b Add the NetVin 5000 series NE2000 PCI card vendor and device IDs. 1997-08-14 07:53:07 +00:00
Stefan Eßer
81473b0cdd Fix problem in the DC390_DefaultEEprom subroutine, which could lead
to spurious wites outside an alloccated array in the case of generic
AMD SCSI cards.

PR:		kern/4217
Submitted by:	Erik H. Moe <ehm@cris.com>
1997-08-11 08:49:08 +00:00
Poul-Henning Kamp
2d4fbd8761 Fix the VLSI chipset name from "Eagle" to "Eagle II". 1997-08-10 09:33:21 +00:00
Poul-Henning Kamp
fdfbeb33ae Add ID's for 5 VLSI chips. They're not very friendly, so this info was
found by taking my HP800CT apart, perusing HPs (Very good!) service
manual and inference from a bad gif file I found in Finland.
Sigh...  But it's a nice machine :-)
1997-08-08 21:11:40 +00:00
Stefan Eßer
6d529e4303 Remove two features that have been reported to cause problems with
certain variants of the NCR chip from FE_CACHE_SET: FE_CLSE (enable
cache-line size register) and FE_ERMP (enable read-multiple). They
will be re-enabled, if a fix for the underlying problem (a restriction
in the memory to memory move logic of some chips) has been implemented.
1997-08-06 20:25:54 +00:00
Peter Wemm
a7065bd54f Merge Matt's if_de.c changes in. 1997-08-03 13:00:42 +00:00
Peter Wemm
7658bc7e94 This commit was generated by cvs2svn to compensate for changes in r27859,
which included commits to RCS files with non-trunk default branches.
1997-08-03 12:17:39 +00:00
Peter Wemm
fd03752a5d Import Matt's if_de driver 970703 release. This (apparently) supports
some newer Cogent (Adaptec) cards and has some other internal changes.
1997-08-03 12:17:39 +00:00
Bruce Evans
1fd0b0588f Removed unused #includes. 1997-08-02 14:33:27 +00:00
Stefan Eßer
5a6006b912 Fix problem caused by a chunk of the previous patch having been
applied to the wrong source code lines (non-fatal, since it just
made an auto variable become visible at the global level).
1997-07-29 21:50:04 +00:00
Søren Schmidt
8b8a0b53b1 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
Stefan Eßer
3334aa04d9 Add support for loading the SCRIPTS microcode into the on-chip RAM
of the Symbios 53c825A, 53c875 and 53c895 SCSI chips.

Submitted by:	Gerard Roudier <groudier@club-internet.fr>
1997-07-28 21:32:05 +00:00
David Greenman
dd0ebb7f08 Added support for the Seeq 80c24 PHY; does nothing except disable the
unsupported warning message for it.
1997-07-25 23:41:12 +00:00
Stefan Eßer
c6d84f7c3e Add Ultra-SCSI support and enable more features for advanced
Symbios/NCR SCSI chips (no-flush option, large fifo, ...).

Submitted by:	Gerard Roudier <groudier@club-internet.fr>
1997-07-25 20:45:09 +00:00
Stefan Eßer
478f9549f4 Assign correct chip set register dump functions to Triton II device IDs.
PR:		i386/4092
Submitted by:	Steve Bauer <sbauer@rock.sdsmt.edu>
1997-07-18 19:47:23 +00:00
Stefan Eßer
01cb2f9493 Fix "unexpected phase change" interrupt handler: Do not access the
dstat register twice, pass the value read the first time to the fixup
code instead.

Submitted by:	Gerard Roudier <groudier@club-internet.fr>
1997-07-18 19:33:56 +00:00
Bruce Evans
48792cfc18 Don't cast function pointers to (void *). This will cause warnings.
They should be fixed when similar warnings for the general interrupt
attach routines are fixed.

Removed unused #include.
1997-07-01 00:45:45 +00:00
Justin T. Gibbs
d144ffea1f Modify my copyright notice to allow the sequencer to be used with GPLed
software (aka Linux).
1997-06-27 19:39:34 +00:00
Steve Passe
91f7398bca Modified to use renamed get_pci_apic_irq() -> pci_apic_pin() function. 1997-06-25 20:56:29 +00:00
Peter Wemm
2adb88c953 Superceded by dc21040reg.h 1997-06-22 09:50:09 +00:00
Peter Wemm
12e96047fa Initial set of patches to get it to compile on >= 3.0. Most of the
changes relative to the 2.2 compatable version are include file
related, the new multicast interface (!) and the new PCI interface.

This should work "as-is" but has not been tested (I have not been able
to get a dc21x4x based card for testing).
1997-06-22 09:48:42 +00:00
Peter Wemm
e5d6c2c9e7 Clean import of if_de.c as of 970513, if_de.c rev 1.86. This should
have optional if_media support.

Obtained from: Matt Thomas via http://www.3am-software.com/
1997-06-22 09:36:50 +00:00
Peter Wemm
172d6524df This commit was generated by cvs2svn to compensate for changes in r26790,
which included commits to RCS files with non-trunk default branches.
1997-06-22 09:32:32 +00:00
Peter Wemm
cb031f1c21 Clean import of Matt Thomas's if_de.c driver as of 970508, rev 1.85. The
slightly later one with optional if_media will be imported shortly as well.

Obtained from: Matt Thomas via http://www.3am-software.com/
1997-06-22 09:32:32 +00:00
David Greenman
3729f8481a Minor optimization in fxp_intr. 1997-06-16 04:45:57 +00:00
Steve Passe
cc81bca6be Added 2 new defines:
- OVERRIDE_TUNER: allows you to manually choose the tuner type for those
                   cards that fail to probe properly.  See source for legal
                   values.
 - OVERRIDE_DBX:   allows you to manually choose DBX or NO DBX for those
                   cards that fail to probe properly.
                   0 == no DBX circuit present, 1 == DBX circuit present.
1997-06-14 19:10:53 +00:00
David Greenman
854d14213e Added support for the Intel 82555 PHY chip which is being used on newer
Pro/100B cards. Full duplex should work now, although it hasn't been
tested.
1997-06-13 22:34:52 +00:00
Stefan Eßer
9744aa88bd Add device IDs for new Symbios SCSI chips (53c875J,885,895,896), which
should work with no driver changes, though not all features are currently
used.

Remove code that was conditional on NEW_SCSICONF not being defined. This
was temporary code, that at a time got excluded correctly, until the new
scsiconf became the default, and NEW_SCSICONF was no longer specified.

Add support for quirks defined in scsiconf.c. For now only the HP3724/5
needs an entry, since that drive can't be used with tags.
1997-06-11 22:36:02 +00:00
Stefan Eßer
1a26f4c024 Move call of pci_addcfg() before test of cfg->subordinatebus, since the
device probe of a host to PCI bridge may modify that value, based on
its knowledge of device specific registers. This makes the Intel XXpress
work, as verified by: Terje Marthinussen <terjem@cc.uit.no>.
1997-06-02 19:59:01 +00:00
Peter Wemm
2ac7b161fb PCI_CLASS_MASS_STORAGE (under PCI_COMPAT) was used in a driver in LINT
still (stallion.c).
1997-06-01 16:00:43 +00:00
Stefan Eßer
8e1b97b626 Add code to correctly probe all buses on the Intel XXPRESS motherboard.
Add a few Intel PCI chip-set names (VX) and fix Orion entries.
1997-05-30 21:01:47 +00:00
Stefan Eßer
575d95316f Remove use of intrec*, use void* instead.
Disable test entries for wired PCI devices on bus 1.
1997-05-30 20:58:04 +00:00
Stefan Eßer
b9d14bed1d Add one more compatibility define to make the Adaptec driver compile
with option AHC_ALLOW_MEMIO again ....
1997-05-28 20:37:19 +00:00
Stefan Eßer
903f376ec8 Define command register enable bits, which are required for a consitency
test added to pci_compat.c
1997-05-28 11:15:18 +00:00
Stefan Eßer
8ae85778a3 Add consistency check to the functions that map port or memory ranges:
Return failure, if the enable bit corresponding to the map type has not
been set in the command register. This feature was requested by Justin
Gibbs, who pointed out that some early PCI to PCI bridges do not correctly
support memory windows (I assume because of the risk of deadlocks that
have been taken care of in the PCI 2.2 spec) and that some BIOS clears
the memory address decode enable bit in the command register of the PCI
device, if it finds them behind such a bridge.
1997-05-28 10:10:02 +00:00
Stefan Eßer
a9ad937362 Two minor changes to the code that builds the pci map array:
1) Stop at the first map register that contains a zero value.
2) When testing for the map size work up from low values, since
   this works around a bug in some BusLogic SCSI card, which has
   the 16 upper port base address bits hardwired to zero.

The config register dump printed in the bootverbose case has
been slightly rearranged.
1997-05-28 10:01:03 +00:00
Steve Passe
6ef807e505 Minor cleanup of APIC_IO code.
Submitted by:	Stefan Esser <se@freebsd.org>
1997-05-27 19:24:36 +00:00