[lkml]   [2003]   [Jan]   [13]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: Linux 2.4.21-pre3-ac4
On 13 Jan 2003 20:03:29 +0100, Benjamin Herrenschmidt
<> wrote:

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

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2005-03-22 13:32    [W:0.071 / U:3.184 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site