Re: Sun3 SCSI DMA, was Re: converting the NCR5380 drivers away from scsi_register

[Michael Schmitz <schmitzmic@gmail.com>]

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