Using pdc202xx_setup_channel() for PDC20268 and newer is wrong, and will
cause trap trying to read from a non-existent register on some arches
(e.g. macppc).
pointed out by Makoto Fujiwara on port-macppc.
Note: The code is written a little more cruftily than it should be. It's also
only tested on the OSB4. I'm not sure it even makes sense to have support for
`native' mode, but I put it in just in case.
turned off. It seems that IDEDMA_CTL_INTR is asserted before DMA transfer
is complete, leading to race condition in case of interrupt sharing.
Discovered reading the FreeBSD code.
Love <lha@stacken.kth.se>.
I suspect this is true for the 648 too; if someone with a 648 and one device
on each channel could test that all works with one_channel = 1, it would
be great !
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.
cjs