Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1552332 > unrolled thread

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

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: [PATCH 0/3] ata: add m68k/Atari Falcon PATA support Michael Schmitz <schmitzmic@gmail.com> - 2017-01-05 22:10 +0100
    Re: [PATCH 0/3] ata: add m68k/Atari Falcon PATA support Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com> - 2017-01-10 14:00 +0100
      Re: [PATCH 0/3] ata: add m68k/Atari Falcon PATA support Michael Schmitz <schmitzmic@gmail.com> - 2017-01-10 21:10 +0100
        Re: [PATCH 0/3] ata: add m68k/Atari Falcon PATA support Finn Thain <fthain@telegraphics.com.au> - 2017-01-13 03:40 +0100
          Re: [PATCH 0/3] ata: add m68k/Atari Falcon PATA support Michael Schmitz <schmitzmic@gmail.com> - 2017-01-14 10:00 +0100
            Re: [PATCH 0/3] ata: add m68k/Atari Falcon PATA support Finn Thain <fthain@telegraphics.com.au> - 2017-01-15 00:50 +0100
              Re: [PATCH 0/3] ata: add m68k/Atari Falcon PATA support Michael Schmitz <schmitzmic@gmail.com> - 2017-01-15 02:50 +0100
                Re: [PATCH 0/3] ata: add m68k/Atari Falcon PATA support Finn Thain <fthain@telegraphics.com.au> - 2017-01-15 05:50 +0100

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

Hi Bartlomiej,

thanks for caring to support our legacy PATA systems!

On Sat, Dec 31, 2016 at 3:01 AM, Bartlomiej Zolnierkiewicz
<b.zolnierkie@samsung.com> wrote:
> Hi,
>
> This patchset adds m68k/Atari Falcon PATA support to libata.
> The major difference in the new libata's pata_falcon host
> driver when compared to legacy IDE's falconide host driver is
> that we are using polled PIO mode and thus avoiding the need
> for STDMA locking magic altogether.

I don't suppose this is the default libata mode for PIO?

How is polling implemented in libata? Sleeping for something
approximating the average seek latency shouldn't hurt but spinning
wont be acceptable for a low performance single CPU architecture like
the Falcon.

> Tested under ARAnyM emulator.

Not sure that the emulator is really feature complete enough - I'll
get this tested on my Falcon in the next few weeks. I'm a bit worried
about IDE still generating interrupts on seek completion (did you spot
anything like that, Geert?).

Cheers,

  Michael

[toc] | [next] | [standalone]

#1555231

Hi,

On Friday, January 06, 2017 10:01:49 AM Michael Schmitz wrote:
> Hi Bartlomiej,
> 
> thanks for caring to support our legacy PATA systems!
> 
> On Sat, Dec 31, 2016 at 3:01 AM, Bartlomiej Zolnierkiewicz
> <b.zolnierkie@samsung.com> wrote:
> > Hi,
> >
> > This patchset adds m68k/Atari Falcon PATA support to libata.
> > The major difference in the new libata's pata_falcon host
> > driver when compared to legacy IDE's falconide host driver is
> > that we are using polled PIO mode and thus avoiding the need
> > for STDMA locking magic altogether.
> 
> I don't suppose this is the default libata mode for PIO?

No, by default it is used only for some commands (i.e. IDENTIFY,
SET FEATURES - XFER MODE).

> How is polling implemented in libata? Sleeping for something
> approximating the average seek latency shouldn't hurt but spinning
> wont be acceptable for a low performance single CPU architecture like
> the Falcon.

You can find actual implementation in libata-sff.c.

Please see ata_sff_pio_task() for the main polling logic:

fsm_start:
	WARN_ON_ONCE(ap->hsm_task_state == HSM_ST_IDLE);

	/*
	 * This is purely heuristic.  This is a fast path.
	 * Sometimes when we enter, BSY will be cleared in
	 * a chk-status or two.  If not, the drive is probably seeking
	 * or something.  Snooze for a couple msecs, then
	 * chk-status again.  If still busy, queue delayed work.
	 */
	status = ata_sff_busy_wait(ap, ATA_BUSY, 5);
	if (status & ATA_BUSY) {
		spin_unlock_irq(ap->lock);
		ata_msleep(ap, 2);
		spin_lock_irq(ap->lock);

		status = ata_sff_busy_wait(ap, ATA_BUSY, 10);
		if (status & ATA_BUSY) {
			ata_sff_queue_pio_task(link, ATA_SHORT_PAUSE);
			goto out_unlock;
		}
	}

	/*
	 * hsm_move() may trigger another command to be processed.
	 * clean the link beforehand.
	 */
	ap->sff_pio_task_link = NULL;
	/* move the HSM */
	poll_next = ata_sff_hsm_move(ap, qc, status, 1);

	/* another command or interrupt handler
	 * may be running at this point.
	 */
	if (poll_next)
		goto fsm_start;
out_unlock:


ata_sff_busy_wait()'s last argument is number of 10uS waits so
first check (50uS) should be quite quick.  If device is still
busy we sleep for 2ms.  Then we quickly (100uS) busy wait and
if needed  queue delayed work (with ATA_SHORT_PAUSE == 16 ms
delay).

Overall the current heuristic looks fine and spinning should be
minimal.

> > Tested under ARAnyM emulator.
> 
> Not sure that the emulator is really feature complete enough - I'll
> get this tested on my Falcon in the next few weeks. I'm a bit worried

Great!

> about IDE still generating interrupts on seek completion (did you spot
> anything like that, Geert?).
> 
> Cheers,
> 
>   Michael

BTW according to comment in arch/m68k/atari/stdma.c:

/* On the Falcon, the IDE bus uses just the ACSI/Floppy interrupt, but */
/* not the ST-DMA chip itself. So falhd.c needs not to lock the        */
/* chip. The interrupt is routed to falhd.c if IDE is configured, the  */
/* model is a Falcon and the interrupt was caused by the HD controller */
/* (can be determined by looking at its status register).              */

it should be okay to use IDE at the same time as SCSI/Floppy which
is what the new driver does (the old one is serialized operations by
ST-DMA related IRQ handling magic).

Also the comment itself may need some fixups as on Falcon it is SCSI
not ACSI (according to the earlier comment in same file) and the old
IDE host driver name is not falhd.c but falconide.c.

Best regards,
--
Bartlomiej Zolnierkiewicz
Samsung R&D Institute Poland
Samsung Electronics

[toc] | [prev] | [next] | [standalone]

#1555887

Bartlomiej,


>> How is polling implemented in libata? Sleeping for something
>> approximating the average seek latency shouldn't hurt but spinning
>> wont be acceptable for a low performance single CPU architecture like
>> the Falcon.
>
> You can find actual implementation in libata-sff.c.
>
> Please see ata_sff_pio_task() for the main polling logic:
>
> fsm_start:
>         WARN_ON_ONCE(ap->hsm_task_state == HSM_ST_IDLE);
>
>         /*
>          * This is purely heuristic.  This is a fast path.
>          * Sometimes when we enter, BSY will be cleared in
>          * a chk-status or two.  If not, the drive is probably seeking
>          * or something.  Snooze for a couple msecs, then
>          * chk-status again.  If still busy, queue delayed work.
>          */
>         status = ata_sff_busy_wait(ap, ATA_BUSY, 5);
>         if (status & ATA_BUSY) {
>                 spin_unlock_irq(ap->lock);
>                 ata_msleep(ap, 2);
>                 spin_lock_irq(ap->lock);
>
>                 status = ata_sff_busy_wait(ap, ATA_BUSY, 10);
>                 if (status & ATA_BUSY) {
>                         ata_sff_queue_pio_task(link, ATA_SHORT_PAUSE);
>                         goto out_unlock;
>                 }
>         }
>
>         /*
>          * hsm_move() may trigger another command to be processed.
>          * clean the link beforehand.
>          */
>         ap->sff_pio_task_link = NULL;
>         /* move the HSM */
>         poll_next = ata_sff_hsm_move(ap, qc, status, 1);
>
>         /* another command or interrupt handler
>          * may be running at this point.
>          */
>         if (poll_next)
>                 goto fsm_start;
> out_unlock:
>
>
> ata_sff_busy_wait()'s last argument is number of 10uS waits so
> first check (50uS) should be quite quick.  If device is still
> busy we sleep for 2ms.  Then we quickly (100uS) busy wait and
> if needed  queue delayed work (with ATA_SHORT_PAUSE == 16 ms
> delay).
>
> Overall the current heuristic looks fine and spinning should be
> minimal.

Thanks, that looks entirely reasonable.

>> > Tested under ARAnyM emulator.
>>
>> Not sure that the emulator is really feature complete enough - I'll
>> get this tested on my Falcon in the next few weeks. I'm a bit worried
>
> Great!
>
>> about IDE still generating interrupts on seek completion (did you spot
>> anything like that, Geert?).
>>
>> Cheers,
>>
>>   Michael
>
> BTW according to comment in arch/m68k/atari/stdma.c:
>
> /* On the Falcon, the IDE bus uses just the ACSI/Floppy interrupt, but */
> /* not the ST-DMA chip itself. So falhd.c needs not to lock the        */
> /* chip. The interrupt is routed to falhd.c if IDE is configured, the  */
> /* model is a Falcon and the interrupt was caused by the HD controller */
> /* (can be determined by looking at its status register).              */

That comment is probably incorrect in part. Blame Linus :-)

Seriously though - that comment dates back to the dark ages (when m68k
was an entirely separate port and the IDE driver was indeed named
falhd.c). That would have been even before 2.2 or 2.4 times. The
comment just never got updated.

What is still correct is that the IDE driver does use the interrupt
only, not the ST-DMA chip. And a single IDE interrupt can be correctly
assigned to IDE by looking at the status register.

With the SCSI (and IIRC also floppy) interrupts, we don't have direct
access to the status registers without disturbing the state of the DMA
though. Unless we know for definite that either chips have raised the
interrupt (and DMA ops are in flight), we must not touch the DMA chip
at all.

The case I'm worried about is both IDE and SCSI raising an interrupt.
We don't currently mask the IDE/ST-DMA interrupt so a stacked
interrupt must be processed in the same pass as the initial interrupt
or it will get dropped. We'd have to peek at the DMA registers to
check the SCSI or floppy interrupt status, and we just can't safely do
that. So races of this kind are currently prevented by including IDE
in the IRQ locking process.

Whether it's possible to mask the interrupt, do one pass, unmask and
process the second interrupt I don't know. Maybe Andreas does?

Cheers,

  Michael


> it should be okay to use IDE at the same time as SCSI/Floppy which
> is what the new driver does (the old one is serialized operations by
> ST-DMA related IRQ handling magic).
>
> Also the comment itself may need some fixups as on Falcon it is SCSI
> not ACSI (according to the earlier comment in same file) and the old
> IDE host driver name is not falhd.c but falconide.c.
>
> Best regards,
> --
> Bartlomiej Zolnierkiewicz
> Samsung R&D Institute Poland
> Samsung Electronics
>

[toc] | [prev] | [next] | [standalone]

#1557967

On Wed, 11 Jan 2017, Michael Schmitz wrote:

> What is still correct is that the IDE driver does use the interrupt 
> only, not the ST-DMA chip. And a single IDE interrupt can be correctly 
> assigned to IDE by looking at the status register.
> 
> With the SCSI (and IIRC also floppy) interrupts, we don't have direct 
> access to the status registers without disturbing the state of the DMA 
> though. Unless we know for definite that either chips have raised the 
> interrupt (and DMA ops are in flight), we must not touch the DMA chip at 
> all.
> 
> The case I'm worried about is both IDE and SCSI raising an interrupt. We 
> don't currently mask the IDE/ST-DMA interrupt so a stacked interrupt 
> must be processed in the same pass as the initial interrupt or it will 
> get dropped. We'd have to peek at the DMA registers to check the SCSI or 
> floppy interrupt status, and we just can't safely do that. So races of 
> this kind are currently prevented by including IDE in the IRQ locking 
> process.
> 
> Whether it's possible to mask the interrupt, do one pass, unmask and 
> process the second interrupt I don't know.

Would that require handling the SCSI DMA interrupt in the first pass? Or 
handling IDE first, and ensuring that the IDE handler does not access 
ST-DMA registers? What about FDC?

The atari_scsi handler accesses the ST-DMA registers; it can do so because 
it knows that any DMA must have completed -- it can infer this because a 
simultaneous pending interrupt from FDC or IDE is impossible due to 
stdma_lock().

Your suggestion would seem to allow other pending interrupts, hence the 
atari_scsi interrupt handler logic has to be tossed out. What logic would 
replace it?

If all else fails, perhaps we could inhibit DMA entirely when the new ATA 
driver is loaded. Then we can just dispatch the ST-DMA irq like a shared 
irq. I'm sure that atari_scsi can work without DMA. No idea about the FDC 
driver though (ataflop.c).

Another solution would be to dedicate the DMA function to atari_scsi, and 
then mask the FDC and IDE interrupts during each DMA transfer. But once 
again, this would mean changing the FDC driver to eliminate DMA, if that 
is possible. From the schematic it looks the the FDC chip, "AJAX", is 
another custom ...
http://dev-docs.atariforge.org/files/Falcon030_Schematic.pdf

Unfortunately my grasp of the ST hardware reflects my inability to read 
German; those who can may want to take a look at "ATARI Profibuch 
ST-STE-TT.pdf".

-- 

> Maybe Andreas does?
> 
> Cheers,
> 
>   Michael
> 
> 
> > it should be okay to use IDE at the same time as SCSI/Floppy which is 
> > what the new driver does (the old one is serialized operations by 
> > ST-DMA related IRQ handling magic).
> >
> > Also the comment itself may need some fixups as on Falcon it is SCSI 
> > not ACSI (according to the earlier comment in same file) and the old 
> > IDE host driver name is not falhd.c but falconide.c.
> >
> > Best regards,
> > --
> > Bartlomiej Zolnierkiewicz
> > Samsung R&D Institute Poland
> > Samsung Electronics
> >
> --
> To unsubscribe from this list: send the line "unsubscribe linux-m68k" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 

[toc] | [prev] | [next] | [standalone]

#1558880

Hi Finn,

Am 13.01.2017 um 15:33 schrieb Finn Thain:

>> The case I'm worried about is both IDE and SCSI raising an interrupt. We 
>> don't currently mask the IDE/ST-DMA interrupt so a stacked interrupt 
>> must be processed in the same pass as the initial interrupt or it will 
>> get dropped. We'd have to peek at the DMA registers to check the SCSI or 
>> floppy interrupt status, and we just can't safely do that. So races of 
>> this kind are currently prevented by including IDE in the IRQ locking 
>> process.
>>
>> Whether it's possible to mask the interrupt, do one pass, unmask and 
>> process the second interrupt I don't know.
> 
> Would that require handling the SCSI DMA interrupt in the first pass? Or 
> handling IDE first, and ensuring that the IDE handler does not access 
> ST-DMA registers? What about FDC?

Handling the IDE interrupt first I think, then looking at the DMA (for
SCSI or FDC).

> The atari_scsi handler accesses the ST-DMA registers; it can do so because 
> it knows that any DMA must have completed -- it can infer this because a 
> simultaneous pending interrupt from FDC or IDE is impossible due to 
> stdma_lock().

libata dropped the locking (and does not use IDE interrupts at present
so it seems to be safe. Still testing - I've seen IO errors, and that's
a bit of a worry).

> Your suggestion would seem to allow other pending interrupts, hence the 
> atari_scsi interrupt handler logic has to be tossed out. What logic would 
> replace it?

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.

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

> If all else fails, perhaps we could inhibit DMA entirely when the new ATA 
> driver is loaded. Then we can just dispatch the ST-DMA irq like a shared 
> irq. I'm sure that atari_scsi can work without DMA. No idea about the FDC 
> driver though (ataflop.c).

Yes, SCSI can work using PIO but's it a real dog. Been there, done that
(about 20 years ago). I know nothing about the FDC chip though.

> Another solution would be to dedicate the DMA function to atari_scsi, and 
> then mask the FDC and IDE interrupts during each DMA transfer. But once 
> again, this would mean changing the FDC driver to eliminate DMA, if that 
> is possible. From the schematic it looks the the FDC chip, "AJAX", is 
> another custom ...
> http://dev-docs.atariforge.org/files/Falcon030_Schematic.pdf
> 
> Unfortunately my grasp of the ST hardware reflects my inability to read 
> German; those who can may want to take a look at "ATARI Profibuch 
> ST-STE-TT.pdf".

I'll reread the ST-DMA description (and the FDC one).

Let me know if you think this could work ...

Cheers,

	Michael

[toc] | [prev] | [next] | [standalone]

#1559117

On Sat, 14 Jan 2017, Michael Schmitz wrote:

> Am 13.01.2017 um 15:33 schrieb Finn Thain:
> 
> >> The case I'm worried about is both IDE and SCSI raising an interrupt. 
> >> We don't currently mask the IDE/ST-DMA interrupt so a stacked 
> >> interrupt must be processed in the same pass as the initial interrupt 
> >> or it will get dropped. We'd have to peek at the DMA registers to 
> >> check the SCSI or floppy interrupt status, and we just can't safely 
> >> do that. So races of this kind are currently prevented by including 
> >> IDE in the IRQ locking process.
> >>
> >> Whether it's possible to mask the interrupt, do one pass, unmask and 
> >> process the second interrupt I don't know.
> > 
> > Would that require handling the SCSI DMA interrupt in the first pass? 
> > Or handling IDE first, and ensuring that the IDE handler does not 
> > access ST-DMA registers? What about FDC?
> 
> Handling the IDE interrupt first I think, then looking at the DMA (for 
> SCSI or FDC).
> 

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

> > The atari_scsi handler accesses the ST-DMA registers; it can do so 
> > because it knows that any DMA must have completed -- it can infer this 
> > because a simultaneous pending interrupt from FDC or IDE is impossible 
> > due to stdma_lock().
> 
> libata dropped the locking (and does not use IDE interrupts at present 
> so it seems to be safe. Still testing - I've seen IO errors, and that's 
> a bit of a worry).
> 

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.

> > Your suggestion would seem to allow other pending interrupts, hence 
> > the atari_scsi interrupt handler logic has to be tossed out. What 
> > logic would replace it?
> 
> 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.

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.

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

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

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

-- 

> > If all else fails, perhaps we could inhibit DMA entirely when the new 
> > ATA driver is loaded. Then we can just dispatch the ST-DMA irq like a 
> > shared irq. I'm sure that atari_scsi can work without DMA. No idea 
> > about the FDC driver though (ataflop.c).
> 
> Yes, SCSI can work using PIO but's it a real dog. Been there, done that 
> (about 20 years ago). I know nothing about the FDC chip though.
> 
> > Another solution would be to dedicate the DMA function to atari_scsi, 
> > and then mask the FDC and IDE interrupts during each DMA transfer. But 
> > once again, this would mean changing the FDC driver to eliminate DMA, 
> > if that is possible. From the schematic it looks the the FDC chip, 
> > "AJAX", is another custom ... 
> > http://dev-docs.atariforge.org/files/Falcon030_Schematic.pdf
> > 
> > Unfortunately my grasp of the ST hardware reflects my inability to 
> > read German; those who can may want to take a look at "ATARI Profibuch 
> > ST-STE-TT.pdf".
> 
> I'll reread the ST-DMA description (and the FDC one).
> 
> Let me know if you think this could work ...
> 
> Cheers,
> 
> 	Michael
> 

[toc] | [prev] | [next] | [standalone]

#1559128

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

[toc] | [prev] | [next] | [standalone]

#1559161

On Sun, 15 Jan 2017, Michael Schmitz wrote:

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

I had not considered that limitation.

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

... none that could be easily blamed on the compiler, anyway.

The gcc 4.6.3 issue affecting my builds was discussed back in 
November. There are alternative compilers available:
http://marc.info/?l=linux-m68k&m=147859596303294&w=2
http://marc.info/?l=linux-m68k&m=147859567903210&w=2

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

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

On page 18 there is an algorithm for floppy writes which is interesting.

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

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.

-- 

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web