On Wed, Aug 06, 2014 at 11:25:18AM +1000, Finn Thain wrote:
On Tue, 5 Aug 2014, Michael Schmitz wrote:
On Sun3, the code is not even configured from what I've seen
(SUPPORT_TAGS not defined)
[...]
That's what I meant to say before - sun3_NCR5380.c does peek at the
message byte without invoking NCR5380_transfer_pio() (needs to manually
set/clear ACK for that resason, finds the disconnected command at issue,
does some DMA setup stuff for that command, and then goes ahead to fetch
the tag message bytes if the phase is still at message in. No idea where
the variable 'phase' gets set in that routine so it might never get to
read tag messages.
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.
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. 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.
-- Sam
--
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
