On Thu, 14 Mar 2002 09:18:08 +0100, Vojtech Pavlik wrote:
>> Vendor
>> | Device
>> | | Revision ATA ATAPI ATA66 ATA133
>> | | | south/host bridge id PIO DMA PIO DMA ATA33 | ATA100| Docs
>> | | | | south/host bridge rev. 32bit | 32bit | | | | | avail
>> | | | | | | | | | | | | | |
>> v v v v v v v v v v v v v v
>>
>> 0x8086 Intel
>> 0x1230 PIIX x x x x - - - - x
>> < 02 x - x - - - - - x
>
>I suppose this means on PIIXes with rev 00 and 01 of the IDE controller
>DMA transfers don't work reliably, right?
True.
>> 0x84C4 Orion
>> < 04 x - x - - - - - x
>
>And this means that if there is an 84c4 PCI bridge in the system with
>rev less than 04 (04 is OK), then DMA transfers are broken again.
True.
>> 0x84CA PIIX4 NX x x x x x - - - x
>
>This one confuses me, because the 0x84ca chip doesn't seem to have any
>IDE capability. Is this id by any chance taken from the linux kernel?
I can't remember. The driver has its roots more than 10 years ago, and
there are so many open and closed driver sources around.
>> 0x7601 ICH x x x x x x - - x
>
>This one is actually a PIIX5, not ICH.
May be, but who cares about names ;-)
>> known bugs:
>> - PIIX3: some chips 'forget' to assert the IRQ sometimes. These chips are not
>> detectable in advance.
>
>Is there any workaround for that? Or there isn't to do anything about
>the bug and we just have to live with it ...
There is no known workaround. My driver has the option to tune the
command timeouts such that missing interrupts have no noticable impact.
The choice is up to the user.
>> 0x1106 VIA
>> 0x1571 571 x x x x - - - - -
>
>Irq unmasking during PIO transfers is known to cause problems on
>these. Also, some have wrong ISA bridge vendor ID of 1107.
True, but this is stone-age technology. I don't really care about
non-UltraDMA capable chips at all.
>> 0x0571 571
>> 0x0586
>> < 0x20 586 x x x x - - - - -
>
>I have docs on this one.
>
>> >=0x20 586A/B x x x x x - - - x
>
>00..1f 586
>20..2f 586a
>30..3f 586b
>40..46 586b 3040 silicon
>Has a bug where the preq# til ddack# bit must be cleared or can cause
>spontaneous reboots.
>47..4f 586b 3041 silicon
True. I leave this particular setup to the BIOS which is supposed to
take care of such idiosyncrasies...
>> 0x0596
>> < 0x10 596/A x x x x x - - - x
>> < 0x10 596B x x x x x x - - x
>
>That probably should be >= 10
Oops - fixed :-)
>> 0x0686
>> < 0x10 686 x x x x x - - - -
>> < 0x40 686A x x x x x x - - x
>> >=0x40 686B x x x x x x x - -
>
>I have docs here as well.
>
>> 0x8231 VT8231 x x x x x x x - -
>> 0x3074 VT8233 x x x x x x x - -
>
>And for this, too.
>
>> 0x3109 VT8233c x x x x x x x - -
>> 0x3147 VT8233a x x x x x x x x -
>>
>> known bugs:
>> - all: no host side cable type detection.
>
>Not true, for the UDMA100 and UDMA133 capable ones, there are defined
>bits in the UDMA_TIMING register. Not all BIOSes use those, though.
Interesting. None of the user reports ever indicated that.
>> --------------------------------------------------------------------------------
>> 0x10DE Nvidia
>> 0x01BC nForce x x x x x x x - -
>>
>> known bugs:
>> - nForce: no host side cable type detection.
>
>Do you have any info on this one? I'd really like to have a Linux driver
>for it ...
I have no docs, but my father's machine has this chip built in :-) My
driver is running it just fine. In fact, this is a clone of the ATA/100
capable AMD IDE chip cell with all config register addresses shifted up
by 0x10.
I'm looking forward to the new ATI chipset, let's bet where their IDE
cell is licenced from :-)
Ciao,
Dani
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Daniela Engert, systems engineer at MEDAV GmbH
Gräfenberger Str. 34, 91080 Uttenreuth, Germany
Phone ++49-9131-583-348, Fax ++49-9131-583-11
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Fri Mar 15 2002 - 22:00:17 EST