Hi Finn, Am 13.01.2017 um 15:33 schrieb Finn Thain: >> The case I'm worried about is both IDE and SCSI raising an interrupt. We >> don't currently mask the IDE/ST-DMA interrupt so a stacked interrupt >> must be processed in the same pass as the initial interrupt or it will >> get dropped. We'd have to peek at the DMA registers to check the SCSI or >> floppy interrupt status, and we just can't safely do that. So races of >> this kind are currently prevented by including IDE in the IRQ locking >> process. >> >> Whether it's possible to mask the interrupt, do one pass, unmask and >> process the second interrupt I don't know. > > Would that require handling the SCSI DMA interrupt in the first pass? Or > handling IDE first, and ensuring that the IDE handler does not access > ST-DMA registers? What about FDC? Handling the IDE interrupt first I think, then looking at the DMA (for SCSI or FDC). > The atari_scsi handler accesses the ST-DMA registers; it can do so because > it knows that any DMA must have completed -- it can infer this because a > simultaneous pending interrupt from FDC or IDE is impossible due to > stdma_lock(). libata dropped the locking (and does not use IDE interrupts at present so it seems to be safe. Still testing - I've seen IO errors, and that's a bit of a worry). > Your suggestion would seem to allow other pending interrupts, hence the > atari_scsi interrupt handler logic has to be tossed out. What logic would > replace it? I need to think about that some more - if no DMA is in progress we can safely peek at the SCSI registers. So the logic could be changed to test for DMA operation first, and just try and service the interrupt if DMA wasn't active. If DMA has been in progress, I'm not sure that we can figure out if it's still active from looking at the status register (that is, whether bits 0 or 1 are set while DMA is ongoing). We'd have to peek at the DMA status register (or DMA address registers) without first stopping DMA, which the current driver does. The docs seem to advise against that. If DMA was in progress, stopping it would likely leave us with residual bytes to be transferred - we'd have to handle that transfer as we would any other DMA error (from memory, probably best to retry the entire command, or transfer the remaining bytes using PIO if we're sure no bytes have been lost). > If all else fails, perhaps we could inhibit DMA entirely when the new ATA > driver is loaded. Then we can just dispatch the ST-DMA irq like a shared > irq. I'm sure that atari_scsi can work without DMA. No idea about the FDC > driver though (ataflop.c). Yes, SCSI can work using PIO but's it a real dog. Been there, done that (about 20 years ago). I know nothing about the FDC chip though. > Another solution would be to dedicate the DMA function to atari_scsi, and > then mask the FDC and IDE interrupts during each DMA transfer. But once > again, this would mean changing the FDC driver to eliminate DMA, if that > is possible. From the schematic it looks the the FDC chip, "AJAX", is > another custom ... > http://dev-docs.atariforge.org/files/Falcon030_Schematic.pdf > > Unfortunately my grasp of the ST hardware reflects my inability to read > German; those who can may want to take a look at "ATARI Profibuch > ST-STE-TT.pdf". I'll reread the ST-DMA description (and the FDC one). Let me know if you think this could work ... Cheers, Michael -- 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
