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 [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
