ATA Patch #7 (Re: ATA Patch #6)

[Matthew Dillon]

:I took this way, but allowing the blahdelay to be zero(in which case
:DELAY() isn't called). I also made selection delay tunable, and made
:two delays tunable int's so that I can put it in the /boot/loader.conf
:  hw.ata.command_delay=0
:  hw.ata.selection_delay=0
:(it works on all of my DragonFly machines, but not sure on other machines)
:
:They both default to 10 for safety, but these DELAY()'s seem to have bigger
:impact on performance on slower machines. Does command-start delay really
:need to be 10us(=10000ns) which is far too larger than the required 400ns
:and taking into account the number of instructions between ATA_OUTB()
:and ATA_INB()?

    If I remember correctly there was some older hardware that did not
    bring BUSY up quickly enough, but I am all for having it under sysctl
    and making the default 0.

    However, for the 0 case the spec does seem to indicate that a one-IO
    delay is required.  i.e. you should do a dummy INB for the 0-delay case
    rather then do nothing.

:>     Here is a posit... if writing to ALTSTATUS (which controls IDS and 
:>     other bits) is illegal during DMAC, is reading STATUS or ALTSTATUS
:>     also illegal during DMAC?  The spec seems to indicate that it is
:>     not illegal but I'm beginning to think that it may be.
:>     If it is then we need to add more code to the interrupt handler, though
:>     I'm not sure exactly what we would be able to do.. I guess we could
:>     check the DMA controller to see if it indicates that DMA has completed,
:>     but that doesn't help us with the ATA_S_ERROR case.
:
:I don't know about that.. Alternate Status register and Device Control register
:are just two separate registers sharing the same address, so I don't think
:the same access restriction as Device Control register applies to Alternate
:Status register. But it may depend on controllers.

    Well, I guess the question is... is reading ALTSTAT doing a bus operation
    over the IDE cable?  If it is the DMA will interfere with it.

    Another alternative is, I think, we may be able to safely stop any running
    DMA, read ALTSTATUS, and then continue the DMA.

    (But for now I'm not going to worry about it).

:>     I've synchronized with your patch-7-take-2 so lets form a new basis
:>     relative to that.  Could you take another pass at the interlock calls
:>     you added and remove the ones for situations where no completion
:>     interrupt is expected?
:
:Thanks, attached(a diff against CVS-HEAD).
:
:Unfortunately, none of ATA Patch #7, #7 + patch-7-take2, or the patch
:attached to this message worked on a desktop in my office. It's has
:a PentiumIV 1.7GHz running SMP kernel(but HTT is unavailable). No timer
:problem, and not using TIMER_USE_1.
:It frequently timed out trying to identify the media in the CD-ROM drive,
:or when writing to the harddrive. Reading from the harddrive also timed
:out, but only once or so at the beginning.
:Inserting DELAY()'s after the call to ata_clear_interlock() seemed to
:reduce the number of timeouts, but it wasn't quite reproducible.
:Increasing or decreaing command_delay or selection_delay seemed to have
:little to do with the timeout. Sigh. I'll try a UP kernel later to see
:if running an SMP kernel has something to do with this.

    Oky doky.

						-Matt