Message-ID: <a637f52e-d70a-4b10-3998-9db5c2534d83@gmail.com>
Date:   Sun, 15 Jan 2017 14:48:28 +1300
From:   Michael Schmitz <schmitzmic@...il.com>
To:     Finn Thain <fthain@...egraphics.com.au>
Cc:     Bartlomiej Zolnierkiewicz <b.zolnierkie@...sung.com>,
        Tejun Heo <tj@...nel.org>,
        Geert Uytterhoeven <geert@...ux-m68k.org>,
        linux-ide@...r.kernel.org,
        Linux/m68k <linux-m68k@...ts.linux-m68k.org>,
        Linux Kernel Development <linux-kernel@...r.kernel.org>,
        Andreas Schwab <schwab@...ux-m68k.org>
Subject: Re: [PATCH 0/3] ata: add m68k/Atari Falcon PATA support

Hi Finn,

Am 15.01.2017 um 12:47 schrieb Finn Thain:

> For the sake of discussion, I'll assume that the FDC driver will not
> be using DMA. (Perhaps FDC and SCSI can share the ST-DMA chip, using
> the present locking mechanism, but it would not simplify things much:
> when IDE no longer participates in that locking mechanism then both
> FDC and SCSI drivers have to solve the same issues.)

Correct - IIRC the FDC registers are also accessible 'through' the
ST-DMA registers only so the same problem WRT DMA status arises.


> What compiler are you using, BTW? Are you still using the gcc-4.6.3
> m68k cross-compiler from kernel.org? I had to abandon it in order to
> get my SCSI driver patches to work.

4.6.3 is the version I still use. You had trouble with that one? I
recall some discussion on gcc versions on the m68k list a while back,
just never seemed to see any problems...

>> 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.
>> 
> 
> OK, so based on the above, we handle the possible IDE interrupt
> (without checking DMA registers), handle the possible FDC interrupt
> (again without checking DMA registers) and finally handle the
> possible SCSI interrupt.

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.

> The core 5380 driver knows whether or not it has started a DMA. The 
> atari_scsi driver also knows that no other Falcon driver uses DMA. So
> the atari_scsi handler only has to figure out whether the interrupt
> was asserted by the ST-DMA chip or the 5380 chip, or neither. (The
> "neither" possility arises when IDE ditches the the stdma.c lock
> mechanism.)
> 
> Without the stdma.c lock, any or all of these interrupts could be
> asserted simultaneously, so the IDE and FDC drivers need to be able
> to do the right thing in the presence of the other interrupts and do
> so without accessing the ST-DMA chip. And the SCSI interrupt handler
> needs to do the right thing when there is no DMA interrupt, and yet a
> DMA is running.

Again, whenever DMA was running (and it might still be), we have to stop
it in order to look at FDC or SCSI registers. Utter braindamage, but

> Perhaps we could reverse the algorithm in scsi_falcon_intr(): if 
> NCR5380_intr() completes with IRQ_HANDLED and the core 5380 driver is
> no longer in DMA, then check the ST-DMA registers for errors etc.
> 
> Alternatively, if NCR5380_intr() returns IRQ_NONE, then do nothing at
> all, on the basis that the interrupt was handled by FDC or IDE.

We may only call NCR5380_intr() if DMA hadn't been active (or we are
sure it's completed, i.e. transfer address == end address. If that's
even possible). If the DMA is still ongoing, we have the choice of
punting (hoping for a command timeout to happen and clean up the mess),
or terminate DMA (by selecting the SCSI chip registers instead of the
DMA ones) and deal with the fallout.

> In this situation, I gather that atari_scsi could miss out on a DMA
> completion interrupt from the ST-DMA chip, which could lead to
> command timeout?

Doing nothing if DMA is enabled (and IDE had successfully handled an
interrupt!) would cause us to miss a stacked interrupt, yes. Timeout
would likely ensue. Not sure it's wise to kludge around that using a
watchdog timer activated in case we're not sure of the DMA completion
state...

> 
>> 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 -
> 
> I can't comment on the Profibuch doc or the ST-DMA chip details
> (Andreas?)
> 
> I suspect it has to be tried.

Yes, I fear I'll have to just try what happens if SCSI and IDE raise an
interrupt at the same time.

For now, polled IDE might be working well enough (haven't seen a huge
impact in IDE-only test workloads, I'll have to check impact on lots of
seeks across the whole disk a lot harder though). I need to recheck the
old IDE driver with my current combined test workload though (my second
4 GB Seagate disk has finally kicked the bucket, after the latest power
brownout).

> 
>> 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).
>> 
> 
> Allowing the command to fail should be fine so long as the 5380
> driver sends the correct result code to the mid-layer. To attempt to
> complete the command after a failed DMA is needless complexity, and
> it's a trick that probably can't be pulled off reliably anyway.

Yep, we've been there before (when my CT60 caused SCSI DMA errors and
lost bytes). Not sure anymore what the correct result code was...

Cheers,

	Michael

Powered by blists - more mailing lists