Hi Finn,
Am 21.01.2017 um 20:37 schrieb Finn Thain:
The MFP interrupt in question is the same as the one used by IDE
(wired-OR of IDE, FDC and SCSI), so we would still have to figure out
where the interrupt originated.
I thought you said the driver you're testing does not use any interrupt --
I was assuming that only atari_scsi and ataflop drivers share the
interupt.
My mistake - I was considering options to allow IDE to share the
interrupt, without the complexities of the old locking scheme.
Polling instead of taking the interrupt does not change that fundamental
problem (unless I'm missing something).
Actually, the fundamental problem you are describing is partly solved. By
polling for DMA completion with local irqs disabled, we mostly avoid the
need for the stdma.c "lock" because FDC/SCSI/IDE interrupt handlers can
never interfere with a FDC/SCSI DMA process that might be underway.
I hadn't considered that. Can PDMA for Falcon SCSI coexist with
interrupt-using DMA for TT SCSI in the same driver (i.e. as runtime
options)? How much overhead and latency would polling for DMA completion
add?
Maybe the DMA address register can be used to check for DMA completion
... it's used to check for residual or lost bytes anyway so that appears
to work. And the FDC driver does use the same strategy to check if
enough track data have been read.
Leaves the case where DMA hasn't completed but may have been aborted by
a NCR5380 interrupt. I suppose we can detect that by checking for any
change in the DMA address while repeatedly reading the DMA address
register. No change means the DMA has got stuck. Not exactly pretty but
all I can come up with.
We don't have to poll any DMA registers (and I don't believe that it is
viable to do so). I was talking about polling for end of DMA by polling
for the interrupt (as per docs) but with local irqs disabled for the
duration of the transfer (which provides exlusive access to the DMA chip).
atari_irq_pending(IRQ_MFP_FSCSI) should show the interrupt pending
condition if you want to poll for it. That's actually given me another
idea to pursue - if we can ensure the IDE interrupt handler is always
run first, and check whether the interrupt is still pending when the
SCSI or floppy interrupt handler runs and DMA has been in progress, we
should be able to avoid calling the respective handlers unnecessarily.
(The output of atari_irq_pending() does not directly reflect the status
of the MFP IRQ inputs - that would require testing bits in
st_mfp.par_dt_reg instead. )
I don't think the IDE/ATA driver needs to be included. atari_scsi and
ataflop would though (if both drivers need DMA transfers).
If we manage to separate interrupt sharing from DMA access locking, IDE
would not need to take part in the locking. I'm assuming that IDE can
cope with spurious interrupts and won't get confused by a SCSI interrupt.
For example, the 5380 SCSI bus reset interrupt is not maskable, which
could affect FDC transfers. If this terminated the polling for DMA
completion, the FDC driver then has to access the FDC registers and
confirm that the transfer was not terminated early.
We'll have to make sure FDC and SCSI don't clash in their DMA and
interrupt use.
The point I was trying to make above is that stdma lock only gets you so
far: if SCSI or FDC generate an interrupt that can't be disabled, it could
mess up the interrupt polling (and the interrupt polling is a necessary
consequence of IDE operating without stdma lock). This would lead to a
short transfer (which could be easily detected).
Point taken - that problem still remains but is already being detected
(though not properly handled IIRC),
So the chips clash in their interrupt line use (rarely). The drivers need
not clash at all.
Anyway, we seem to be talking past each other somewhat. I suggest we start
coding and discuss actual patches ... unless you can convince me that this
won't work ...
I think it could work both ways - polling for DMA completion or avoiding
to call the SCSI interrupt handler the interrupt was caused by IDE only.
But it's indeed time to put that to the test.
Cheers,
Michael
--
To unsubscribe from this list: send the line "unsubscribe linux-m68k" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
