One thing we could do to solve this entire problem is wait for the
interrupt to finish before sending the command to the drive in the first
place. Basically in ide_do_request we just have to change
if (masked_irq && hwif->irq != masked_irq)
disable_irq_nosync(hwif->irq);
to
if (masked_irq && hwif->irq != masked_irq) {
BUG();
}
if (!masked_irq) {
disable_irq_sync(hwif->irq);
}
But that means that we will only queue up new commands to a drive when
its interrupt is not currently active.
Ross
Ross Biro wrote:
> 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:47 EST