Re: Linux 2.4.21-pre3-ac4

[Benjamin Herrenschmidt <benh@kernel.crashing.org>]

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...

Ben.