On Fri, Aug 08, 2014 at 08:46:08PM +1200, Michael Schmitz wrote: > 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).
PIO definitely works on the Sun3 implementation under the right circumstances, I ran it in PIO mode only for a while (much like the Mac driver). I can't remember the bus configuration offhand. > > > >>>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)? Yes, I still have hardware. I'll try to dig something out and make sure the last kernel I've actually tested still works before trying anything new... -- Sam > Cheers, > > Michael > -- 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
