Hello. Russell King wrote:
That's not the problem here - with the printk's I've added, there's no way for the IO read/writes to come that fast. Slowing down the IO accesses made no difference what so ever.
Doing it within 400nS of command setup is suspect at the ATA level and can trivially fixed.
Sane PCI controllers (and quite a few less than sane ones) all implement an AltStatus which can be checked for busy bits with DMA running or stall that access until the DMA completes (wrongly in some CMD64x cases).
The 20246 implements its own magic 'am I busy' flag which old IDE supports and libata doesn't. So as well as the ndelay(400) fix for PIO controllers it needs pdc202xx_test_irq porting over to complete the fix.
Yes, but please use a non-buggy version of pdc202xx_test_irq() as per my recent patch. Testing for the DMA FIFOs being non-empty to qualify an interrupt is Very Bad News too.
Sorry about that -- I was the author of pdc202xx_test_irq()...
It's interesting to note that SFF 8038 suggests an approach to dealing with IDE interrupts connected to a SFF compatible host interface:
3) Software issues the appropriate DMA transfer command to the disk device. 4) Engage the bus master function by writing a '1' to the Start bit in the Bus Master IDE Command Register for the appropriate channel. 5) The controller transfers data to/from memory responding to DMA requests from the IDE device. 6) at the end of the transfer the IDE device signals an interrupt . 7) In response to the interrupt, software resets the Start/Stop bit in the command register. It then reads the controller status and then the drive status to determine if the transfer completed successfully.
It goes on to say that the interrupt status bit in the BM-DMA status register will only be set after buffered data has been transferred - which means reading the altstatus register to determine when the device has finished would give a premature indication and doesn't take any account of the BM-DMA buffering.
Yes.
So I think Jeff is not right on the "must read altstatus" point.
Frankly speaking, I'm not sure why Jeff insisted on that, at least for the DMA case...
I would not be surprised if lots of host controllers were actually buggy in respect of reading any ATA device register mid-transfer - firstly a started UDMA operation can't be stopped before at least one word has been transferred, nor can it be stopped without first transferring the CRC bytes. That's an awful lot of logic (and overhead) to be randomly interacting with due to other shared devices interrupt activity.
Reading the BM-DMA status register (or equivalent on hosts) seems to be the right way to tell if an interrupt is pending.
Except the BMDMA interrupt bit (generally) doesn't get set for the PIO transfers. Anyway, the IDE core eventually reads that register for the DMA transfers. I'm sure libata also does eventually read it; looking at the code in ata_sff_host_intr(), it even reads the BMDMA status first, before touching any of the IDE status registers.
MBR, Sergei -- 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
