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

[Michael Schmitz <schmitzmic@gmail.com>]

Hi Finn,
>>> However, atari never uses DMA here if cmd->device->borken.
>>>   
>>>       
>> Different semantics of borken, I presume. On Atari, this means a DMA 
>> transfer has failed earlier.
>>     
>
> Right. I suppose the question of using PIO in this situation on sun3 would 
> have to be put to the test.
>   

Yep - let's see whether Sam has a working test configuration with 
current kernels.

>   
>>> When cmd->device->borken, I assume sun3_NCR5380 inhibits PIO because 
>>> PIO was itself expected to be problematic?
>>>       

The sun3 driver does set the borken flag but never uses it later - can't 
see where it will inhibit PIO.

>>> OTOH, if PIO works up to 128 bytes in all cases, why not larger 
>>> transfers?
>>>   
>>>       
>> Performance, perhaps.
>>     
>
> Well, sun3_scsi has this:
>
> static inline unsigned long sun3scsi_dma_xfer_len(unsigned long wanted,
>                                                   struct scsi_cmnd *cmd,
>                                                   int write_flag)
> {
>         if (cmd->request->cmd_type == REQ_TYPE_FS)
>                 return wanted;
>         else
>                 return 0;
> }
>
> This does suggest that PIO does work beyond 128 bytes, even if it is 
> avoided for filesystem requests. Which suggests that the atari reselect 
> code might work on sun3.
>
> (As for performance, I don't know why the REQ_TYPE_FS is significant: why 
> not just raise the DMA size limit to 512 instead?)
>   

No idea really - the sun3 DMA allows to read the correct residual so it 
probably is not necessary to strictly avoid DMA on anything not 
guaranteed to transfer the requested size.  Not sure what commands will 
transfer between 128 and 512 bytes ...

>   
>> PIO would work, but hog the CPU. In fact, PIO for everything _does_ 
>> work, on Falcon as well as Mac (I tried the PIO only mode on the Falcon 
>> before trying on Mac). Did I eve mention how reallly incredibly 
>> painfully slow that is?
>>
>>     
>>> Does the sun3_scsi driver still work after removing #define REAL_DMA?
>>>
>>> For NCR5380_information_transfer() and PHASE_CMDOUT, the sun3 version 
>>> applies the same size limit but only does DMA setup if cmd type is 
>>> REQ_TYPE_FS (i.e. filesystem request). This command is then sent by 
>>> PIO, so the DMA setup here seems to assume that the next phase will 
>>> always be PHASE_DATAIN...
>>>   
>>>       
>> Might be a similar limitation to certain transfer sizes here. Block mode 
>> vs. char mode.
>>     

Commands need to be sent by PIO always because of the DMA size limit. 
The DMA setup early on may save time if the next phase is indeed DATAIN 
or DATAOUT - if a command disconnects the DMA just won't be started. I 
would have thought the DMA setup could just as easily be done inside 
NCR5380_transfer_dma instead of splitting it in DMA setup and DMA start 
- any particular reason for this, Sammy?

> That suggests that the test for REQ_TYPE_FS in 
> NCR5380_information_transfer() in sun3_NCR5380 could be improved upon by 
> using NCR5380_dma_xfer_len() when checking the size limit. That way it 
> would work on atari as well, without #ifdefs.
>   

The test for REQ_TYPE_FS could be done in the specific dma_xfer_len() 
function which would need to be used whenever DMA setup is going to be 
used. As it is, the separation of DMA setup from NCR5380_transfer_dma is 
a bit mysterious and makes it hard to merge the drivers without lots of 
ifdefs or runtime tests (think multiplatform kernels) anyway.

Cheers,

    Michael