Benjamin Herrenschmidt wrote:
>
>
>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...
>
>
>
Ahh, good point. My experience with the promise controller says that it
is not safe to talk to the drive after a start of a DMA command. For
non-dma commands, it should be safe but I believe it would be an ATA
spec violation to do so. In particular from the ata-6 spec
HPIOI0: INTRQ_Wait State: This state is entered when the host has
written a PIO data-in command to the device and nIEN is cleared to zero,
or at the completion of a DRQ data block transfer if all the data for
the command has not been transferred and nIEN is cleared to zero. When
in this state, the host shall wait for INTRQ to be asserted.
So technically we are not allowed to talk to the drive, but must wait
for an irq. The problem becomes how to tell if the irq is meant for us.
My guess is that most drives will not care if nIEN is set or not at
this point and we can use
HPIOI1: Check_Status State: This state is entered when the host has
written a PIO data-in command to the device and nIEN is set to one, or
when INTRQ is asserted. When in this state, the host shall read the
device Status register. When entering this state from the HI4 state, the
host shall wait 400 ns before reading the Status register. When entering
this state from the HPIOI2 state, the host shall wait one PIO transfer
cycle time before reading the Status register. The wait may be
accomplished by reading the Alternate Status register and ignoring the
result.
and read the alt status register to get a delay.
This is technically a spec violation, but it's probably safe. I'm going
to send an email to a couple of the drive manufacturers and see what
they think.
Ross
-
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/
This archive was generated by hypermail 2b29 : Wed Jan 15 2003 - 22:00:46 EST