Hi Sam,
atari_NCR5390.c does things a bit different - instead of peeking at the
message byte, NCR5380_transfer_pio() is used for the first message byte
(ACK set there, cleared manually later). NCR5380_transfer_pio() sets the
current phase, so the subsequent transfer of the tag message may work
there (again ACK raised in NCR5380_transfer_pio(), cleared manually
later).
Yes, but why the discrepancy?
Not unlike the use of DMA in NCR5380_reselect(), the sun3 version of
NCR5380_information_transfer() also uses DMA in one situation where the
atari version uses PIO. That is, when phase == PHASE_DATA_IN &&
cmd->device->borken.
Can we just use the PIO code from atari_NCR5380, or should we keep the DMA
versions with #ifdef CONFIG_SUN3? Sam?
Oof, my memory is hazy around this one, but I would strongly hesitate
to use the PIO version from the atari driver. IIRC, the DMA
controller for the sun3's NCR5380 implementation is extremely fussy
about what happens in which phase, and it's quick to anger if you
don't handle everything exactly how it expects.
Does the DMA controller also sit in between the bus and the NCR chip, as
on Falcon? Otherwise, I can't see how it would matter if we just bypass
it and use PIO instead.
The PIO code from the Atari driver worked just fine for the Mac 5380 (in
fact, the first Mac driver used PIO for everything, including data in/out).
From what I've checked both should work, but the sun3 code never sets
'phase' so it should never actually have worked. It should not even
compile.
I guess that's why sun3_scsi leaves SUPPORT_TAGS undefined. I suppose we
can ignore all the code in sun3_NCR5380.c that is conditional upon #ifdef
SUPPORT_TAGS. (That's actually how I did my preliminary merge patches.)
I guess having two versions of the NCR5380_transfer_dma() routine is
reasonable but it would be nice if some of the other discrepancies could
be resolved. Without knowledge of the Sun 3 DMA hardware it is difficult
to avoid some questionable #ifdefs.
I definitely remember that the DMA setup logic from the atari version
did not work at all on sun3.
No surprise there - DMA is implementation specific and needs to be
handled on a per-case basis.
Unfortunatly working from 15 year old
memories, I can't quickly recall what the discrepencies were. I never
did find any documentation for that DMA chip, so there was a heck of a
lot of trial and error on getting to a working driver.
Do you still have the hardware to test (PIO in reselection, to be
specific)?
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
