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