Re: [PATCH] Serialize CMD643 and CMD646 to fix a hardware bug with SSD

[Sergei Shtylyov <sshtylyov@ru.mvista.com>]

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