On 3/14/07, Jeff Garzik <jeff@xxxxxxxxxx> 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. ... I'm new to the code, so I want to double check with your guys to see if this is a valid case and if the code can handle it. Thanks, Fajun - To unsubscribe from this list: send the line "unsubscribe linux-ide" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
