Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.kernel > #1567182
| From | Finn Thain <fthain@telegraphics.com.au> |
|---|---|
| Newsgroups | linux.kernel |
| Subject | Re: [PATCH 0/3] ata: add m68k/Atari Falcon PATA support |
| Date | 2017-01-26 09:50 +0100 |
| Message-ID | <t3NUJ-57D-1@gated-at.bofh.it> (permalink) |
| References | (8 earlier) <sZI7g-4PS-3@gated-at.bofh.it> <sZKVr-6yh-1@gated-at.bofh.it> <t1C7n-4pX-15@gated-at.bofh.it> <t1Yrg-1gy-19@gated-at.bofh.it> <t2HRo-3Xz-21@gated-at.bofh.it> |
| Organization | linux.* mail to news gateway |
On Mon, 23 Jan 2017, Michael Schmitz wrote: > > Am 21.01.2017 um 20:37 schrieb Finn Thain: > > > > > 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)? Sure, why not? > How much overhead and latency would polling for DMA completion add? > A polled DMA transfer should be faster than PDMA (i.e. mac_scsi, g_NCR5380 etc). mac_scsi gets about 0.5 MBps from PDMA with sg_tablesize == 1, and I hope that DMA could get twice that (notwithstanding dumb hardware design). This would imply CPU overhead that is half of that which mac_scsi incurs. That's the best case, but I see no reason to expect worse performance than PDMA gets. > atari_irq_pending(IRQ_MFP_FSCSI) should show the interrupt pending > condition if you want to poll for it. The difficulty will be arranging for disabled FDC & IDE interrupt sources during SCSI DMA, and disabled SCSI & IDE interrupt sources during FDC DMA. (Not all 5380 interrupts can be disabled; no idea about the IDE device or WD1772 FDC.) But if that is impossible, we just have to detect the short DMA that might result from an undesired interrupt. > That's actually given me another idea to pursue - if we can ensure the > IDE interrupt handler is always run first, There are no interrupts from the ATA driver you're testing, right? If you would re-introduce them, the whole polled DMA idea is moot. > 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. > The ATA driver will never have to cope with a spurious interrupt under my simplifying assumptions discussed earlier, so the spurious interrupt question seems to belong to some alternative approach... > 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. > ... "Both ways"? I don't follow. I don't see how IDE can share the FDC and SCSI interrupt line without sharing the stdma.c locking scheme. What is the alternative approach (i.e not polled DMA) that you alude to? --
Back to linux.kernel | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread
Re: [PATCH 0/3] ata: add m68k/Atari Falcon PATA support Michael Schmitz <schmitzmic@gmail.com> - 2017-01-20 08:50 +0100
Re: [PATCH 0/3] ata: add m68k/Atari Falcon PATA support Finn Thain <fthain@telegraphics.com.au> - 2017-01-21 08:40 +0100
Re: [PATCH 0/3] ata: add m68k/Atari Falcon PATA support Michael Schmitz <schmitzmic@gmail.com> - 2017-01-23 09:10 +0100
Re: [PATCH 0/3] ata: add m68k/Atari Falcon PATA support Finn Thain <fthain@telegraphics.com.au> - 2017-01-26 09:50 +0100
Re: [PATCH 0/3] ata: add m68k/Atari Falcon PATA support Geert Uytterhoeven <geert@linux-m68k.org> - 2017-01-26 10:10 +0100
Re: [PATCH 0/3] ata: add m68k/Atari Falcon PATA support Finn Thain <fthain@telegraphics.com.au> - 2017-01-27 03:00 +0100
Re: [PATCH 0/3] ata: add m68k/Atari Falcon PATA support Michael Schmitz <schmitzmic@gmail.com> - 2017-01-27 05:30 +0100
csiph-web