>On 13 Jan 2003 20:03:29 +0100, Benjamin Herrenschmidt
><benh@kernel.crashing.org> wrote:
>
>
>
>>Exactly. My problem right now is with enforcing that 400ns delay on
>>non-DMA path as with PCI write posting on one side, and other fancy bus
>>store queues etc... you are really not sure when your outb for the
>>command byte will really reach the disk.
>>
>>So the problem turns down to: is it safe for commands with no data
>>transfer and commands with a PIO data transfer to read back from
>>some other task file register right after issuing the command byte
>>(the select register looks like a good choice, better than status
>>for sure) and before doing the delay of 400ns ? On any sane bus
>>architecture, that read will make sure the previous write will
>>have reached the device or your IO accessors are broken...
>>
>>
>>
>You could simplify the problem somewhat by forcing all interaction and
>interrupt processing to a single CPU.
>
>john
>
>
I don't think that helps. The problem can still occur if the PCI write
post is long enough for an interrupt to get through. We could read the
alt status twice in drive_is_ready and only take the second one.
Ross
-
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/