lkml.org 
[lkml]   [2017]   [Jan]   [26]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [PATCH 0/3] ata: add m68k/Atari Falcon PATA support

    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?

    --

    \
     
     \ /
      Last update: 2017-01-26 09:47    [W:4.014 / U:0.512 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site