My WDC MDMA-only (non-UDMA) drives did not work on the Acard controllers,
but it turns out that the problem was not Acard specific.
These WDC drives do not work on the ESS ISAPnP wdc port nor on
macppc obio wdc port neither, and another Quantum MDMA-only drive
works fine on the Acard.
These WDC drives work fine on my i386 pciide (which is initialized
by the BIOS), so maybe we have to do something in MI wdc to initialize
such drives properly...
Ultra/100 for revs >= 0xC4.
The the generic PCIIDE interupt routine for chipsets rev >= 0xC2 in native
mode, it seems that newer chipsets don't have the ACER_CHIDS register :(
From Linux and FreeBSD.
with some differences to the original patch: don't assume all controllers with
rev >= HPT370_REV are HPT370, and explicitely print if we have a chip with a
rev the driver does't know.
Different chipsets have the same vendor/device/rev ID for the IDE controller,
but only one of them is buggy. So check dev/rev ID of the function 0
(pchb on the buggy one) of the same device to detect the buggy controller.
them define __HAVE_PCIIDE_MACHDEP_COMPAT_INTR_ESTABLISH
in pci_machdep.h and pciide_map_compat_intr() only calls
pciide_machdep_compat_intr_establish() if that preprocessor
define exists.
Ports that don't need to do this no longer need to supply a
dummy function.
to guess the pciide capabilities, rather than trying to guess it by ourselve.
Add preliminary support for the 686b (Ultra/100) guessed from FreeBSD/linux
driver (datasheet not publically available, I contacted via).
Let chip-specific map routine do the autoconf printf if ide_name is NULL
(they may have more details about the controller than we have in pciide_attach)
XXX Currently disabled by default because it has some problems on macppc.
XXX Maybe some more initialization is needed, but there is few information
XXX about the chips.
Paul Kranenburg, many thanks !): the control register I/O is 4 byte long
although only one is used, but the control register is at offset 2, and not
0 as expected by IC code. Use bus_space_subregion() to get a handle which
points to the control register, and is one byte long.
is the same for the Ultra/33 and Ultra/66 version, so test writability of
the U66 enable bit (idea from Chris Cappuccio).
Thanks to David Carrel for testings.
XXX the datasheet for the HPT370 is wrong
While I'm there clear the DRIVE_DMA flag when we're going to use Ultra/DMA
where it was missed, so that wdc_print_modes() only prints what's used.
pci_attach_args *" instead of from four separate parameters which in
all cases were extracted from the same "struct pci_attach_args".
This both simplifies the driver api, and allows for alternate PCI
interrupt mapping schemes, such as one using the tables described in
the Intel Multiprocessor Spec which describe interrupt wirings for
devices behind pci-pci bridges based on the device's location rather
the bridge's location.
Tested on alpha and i386; welcome to 1.5Q
immediately with a lost interrupt on udma mode 2, downgrades to mode 1
at which point it silently corrupts data on high disk activity. This
happens on two out of 3 machines I own that exhibit high disk activity.
wdc drivers (like macppc's obio IDE interface) can use it. Also add
support to both wd attach line and to wdc_print_modes() to print
Ultra/{33,66,100} for respective UDMA modes (From Manuel Bouyer).
tsutsui