>On Mon, 2003-01-13 at 19:49, Ross Biro wrote:
>
>> The reason we need to enforce the 400nS delay is because of what is
>> going on on the other processor. If the other processor is in ide_intr
>> trying to grab the spinlock and we do not give the drive time to assert
>> the busy bit and the other processor makes it to the call to
>> drive_is_ready, then the drive could still return not busy and we could
>> think the command is done. This code path is probably less than 50
>> instructions, so I don't think it's taken anywhere near 400ns for a long
>> time.
>>
>> DMA is slightly different. We don't actually have to delay the 400ns if
>> we call ide_dma_begin from inside the spinlock.
>
>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
-
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/