Hello. Alan Cox wrote:
So, why was it serialized before? I assume that either someone noticed the corruption or someone read some datasheet noting the corruption or someone reverse engineered some other driver and saw the serialization.
The data sheet has some things to say for the 643 abd 646
In PIO mode it says you must check
CFR bit 2 (indicates primary interrupt) ARTIM23 bit 4 (secondary interrupt)
Both bits can be written 1 to clear the interrupt.
Not in the original PCI0646 datasheet -- it says that reading the register clears the interrupt bit. PCI0646U datashett however started talking about writing one to clear the bit.
The doc doesn't say anything about not touching status but it also uses the word "must" about the other bits so make what you will of it.
I think they use must in the sense that if the driver *really* needs to know from which channel the interrupt has come. Since most of the chip don't provide that capability, the real world Linux drivers, both old and new, had to get along without such knowledge. The IDE driver does read and clear the interrupt bits now though, in both PIO abnd DMA modes.
In DMA mode I would read the BMDMA status in preference to status but the doc doesn't specifically say to do so and simply say it works to the spec. it isn't clear if ARTIM23 and CFR work for reporting/clearing a DMA interrupt. You'd have to try it.
Earlier the IDE driver did chec CFR/ARTTIM23 bits before the BMIDE status interrupt bit in dma_test_irq() method and that used to work. Now it also does so, via the new test_irq() method.
ARTIM23 may well need some locking care
Locking WRT what? It's not shared between channels...
The 646U2 adds the MRDMODE register so you can check the bits more sanely
Yeah. The libata driver however doesn't make use of that register, unlike cmd64x. It doesn't even touch the interrupt bits on PCI0646, only manipulation the "old" bits on PCI-64[89]. It seems that I need to sync up these two, pata_cmd64x.c seems to be lagging behind the changes in cmd64x.c. Well, not only this one, at least pata_hpt* drivers are lagging behind too...
WBR, Sergei -- To unsubscribe from this list: send the line "unsubscribe linux-ide" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
