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


    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.027 / U:3.512 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site