Re: [PATCH 0/3] ata: add m68k/Atari Falcon PATA support

[Finn Thain]

On Fri, 20 Jan 2017, Michael Schmitz wrote:

> Am 15.01.2017 um 17:42 schrieb Finn Thain:
> 
> >> No, we can't check either FDC or SCSI interrupts (or indeed any chip 
> >> registers) without touching the ST-DMA. The moment we select a FDC or 
> >> SCSI register for read, DMA is terminated no questions asked.
> >>
> > 
> > Perhaps we can convert DMA operations to PDMA (by polling with local 
> > irqs disabled) and avoid the whole problem of interrupt handlers 
> > executing during DMA transfers. The docs suggest that it is doable.
> > 
> > "Poll or service the Disk Driver Controller interrupt on the MK68901 
> > MFP General Purpose I/O Register to detect the completion of a WD1772 
> > FDC command. Do not poll the FDC Busy or DMA Sector Count Zero status 
> > bits." -- ST HW Spec, p. 36. 
> > http://dev-docs.atariforge.org/files/ST_HW_Spec_1-7-1986.pdf
> 
> 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.

> 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.

> > 
> > On page 18 there is an algorithm for floppy writes which is 
> > interesting.
> 
> That one (and the ACSI algorithm which would apply to SCSI for Falcon) 
> does suggest it won't be possible to peek at the sector count register 
> to detect end of DMA. The addendum (note 841017G) makes it clear that a 
> write to the DMA mode register is required to look at the status 
> register error bit (which might terminate DMA).
> 
> 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).

> > 
> > I suspect that we will need to keep the FDC idle during SCSI transfers 
> > (and vice versa) much as the present stdma.c lock does.
> > 
> > "The interrupt outputs of the internal floppy disk controller and the 
> > external ACSI DMA port are logically OR'ed. The pin of the MFP GPIP 
> > will read as a '0' if either the FDC or a selected ACSI device 
> > controller is asserting its interrupt request." -- ACSI/DMA 
> > Integration Guide, p.16. 
> > http://dev-docs.atariforge.org/files/ACSI_DMA_Guide_6-28-1991.pdf
> 
> On Falcon, the IDE interrupt is also OR'ed to the above two interrupt 
> lines, hence the need for including IDE in the locking scheme there.
> 

I don't think the IDE/ATA driver needs to be included. atari_scsi and 
ataflop would though (if both drivers need DMA transfers).

> > 
> > Polling the logically OR'ed interrupt sources to detect end-of-DMA 
> > will not be reliable unless we disable those sources that aren't 
> > relevant. Otherwise we access the DMA registers too early (which IIUC 
> > would kill the transfer). I'm afraid we shall have to expect that a 
> > few transfers will be interrupted by other devices in this way, and 
> > carefully check for this.
> > 
> > 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).

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 ...

-- 

> 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
>