Re: PATA Sil680 Command Timeout on ARM XScale

[Albert Lee <albertcc@tw.ibm.com>]

Fajun Chen wrote:
> On 3/14/07, Jeff Garzik <jeff@garzik.org> wrote:
> 
>> Fajun Chen wrote:
>> > Since primary channel and secondary channel share the same IRQ,  the
>> > ISR could be called to service one or both channels. So I would think
>> > it's normal to see "irq trap" traces when both channels are in IO
>> > operation, correct?
>>
>> The irq trap code only occurs after a certain number of unhandled
>> interrupts.
>>
> 
> If an interrupt fires for IDE1 while IDE0 is busy handling commands,
> the irq trap code will count one unhandled interrupts on IDE0 but the
> interrupt was not targeted for IDE0 to start with.  So  this irq trap
> code if enabled could generate false alarms even in a perfert working
> system and ata_irq_ack() function should not be called based on false
> alarm.   Please correct me if I misunderstand the intention of the
> code.
> 
>>
>> > I have another question in regard to ata_host_intr() function in
>> > libata-core.c. For PIO read/write, the status of interrupt pin was not
>> > checked before moving the host state machine.  Sil680 spec. recommend
>> > checking IDE channel interupt (bit 11 in the IDEx Task File Timing and
>> > Config + Status register) though.  Could someone explain why interrupt
>> > status does not need to be checked for PIO?
>>
>> Reading the Status register (as opposed to AltStatus) should clear the
>> interrupt condition, on standard hardware.
>>
> 
> Could this piece of code handle the sequence below well?
> 1.  A interrupt fires for IDE1 to indicate command finish
> 2.  At the same time,    IDE0 just started PIO read and its status
> register has not been updated to busy.
> 3. As part of the interrupt handling, ata_host_intr() will be called
> for IDE0 as well. Since this code doesn't check interrupt validity on
> IDE0 and count on status register to make decision,  it will be misled
> to read data register which has not been populated by the target
> device yet.

The host->lock is acquired when a command is being issued to the device.
After writing the command register, libata reads Alt Status and
waits for a short period of time (ndelay(400)) to ensure that the device
is BSY before releasing the host lock. (Please see ata_exec_command().)

So, the above scenario won't happen, unless the device is faulty and
doesn't set BSY after 400+ ns. Even under such situation, libata won't
read the data register blindly as worried. It will be detected as
HSM violation and EH will be activated to handle such situation.

--
albert