Re: converting the NCR5380 drivers away from scsi_register

[Michael Schmitz <schmitzmic@gmail.com>]

Hi Finn,
>> OK, forget about atari_scsi.c for now. From memory, the major difference 
>> between atari_NCR5380.c and the others is handling of the ST-DMA/shared 
>> interrupt locking.
>>     
>
> Yes, sun3_NCR5380.c and NCR5380.c lack support for the ST-DMA chip.
>   

As should be.

> And both NCR5380.c and sun3_NCR5380.c dropped the code to support ISA 
> cards, as I mentioned.
>
> Both NCR5380.c and sun3_NCR5380.c lack merge_contiguous_buffers().
>   

I'm sure that was a tweak added by Roman Hodek to improve performance. 
Should not hurt to merge this one.

> NCR5380.c lacks support for tagged queueing, while sun3_NCR5380.c and 
> atari_NCR5380.c have divergent implementations of this.
>   

Might be equivalent for all I've seen - just array vs. bitmap to store 
tags..

> sun3_NCR5380.c and atari_NCR5380.c have divergent implementations of 
> NCR5380_transfer_dma().
>   

This is due to different DMA hardware in the three cases covered, so 
expected. There's quite a bit of additional DMA mumble in 
NCR5380_information_transfer and NCR5380_reselect.

> sun3_NCR5380.c and atari_NCR5380.c share the same implementation of the 
> NCR5380_main() co-routine, but it differs significantly from the algorithm 
> in NCR5380.c.
>   

atari_NCR5380.c was forked from NCR5380.c as early as 1994, and the 
changes to the NCR5380.c coroutine will be a later addition. NCR5380.c 
has seen development for a few years that we've never picked up.

> Each of sun3_NCR5380.c, atari_NCR5380.c and NCR5380.c have had some clean 
> up and modernization work that does not appear in any of the others.
>
> Despite all of that, I have a patch series that attempts to unify 
> atari_NCR5380.c and sun3_NCR5380.c. This seems like a sensible idea (in 
> theory) given that probably only the ISA cards actually need NCR5380.c.
>   

The diff between the two was amazingly clean and easy to parse (aside 
from the above mentioned DMA setup related stuff). Merging the two seems 
quite possible indeed.

Changes to NCR5380. are rather major though. I need to carefully go 
through the diff again. ISTR trying to run the coroutine as delayed 
workqueue instead of immediate but dropped that again for some reason.

> At some point I'll send some patches for comment, so that we might discuss 
> the issues with everyone on the same page. Until then, I'd prefer to focus 
> on the scsi_register() conversion.
>   

OK, do that first so scsi_register can go away.

>> We need to preserve that pretty much as is, or risk serious regressions. 
>> I mean, more serious trouble than I already have with the current driver 
>> because of the tendency of my Falcon to muck up the SCSI chip's clock 
>> signal under heavy load. Also note that there is still one of my patches 
>> unmerged (under review since early this year) that is necessary to avoid 
>> 'scheduling in interrupt' style panic.
>>     
>
> Can you re-send it please?
>   

I'll do that.

Cheers,

    Michael