Re: converting the NCR5380 drivers away from scsi_register

[Michael Schmitz <schmitzmic@gmail.com>]

Hi Finn,
>>
>> If you rather want to do this - either use the ATARIHW_PRESENT() macros 
>> to test for ST_SCSI (Falcon, interrupt no. IRQ_MFP_FSCSI) or TT_SCSI 
>> (TT, interrupt no. IRQ_TT_MFP_SCSI). Or else, replicate the logic from 
>> config_atari()
>>     
>
> Yes, that was my plan. A patch that replicates that logic is easier to 
> review and less likely to cause regressions (of course, I'd follow the 
> existing conventions in arch/m68k/atari/config.c).
>   

Sounds good to me.

> Converting three drivers at once is a win because the first conversion is 
> always the more difficult one. Therefore I'm planning to use the same 
> logic three times over and therefore I'm not intending to address the 
> peculiarities of different ports (that would be better done by you, me and 
> Sam separately).
>   

OK, I'll think some more about what could be done to merge the quirks 
into a shared core.

> However, I'll will need you and Sam to test some patches (if they meet 
> with approval once you and Sam get to review them, of course).
>
>   
>> - the SCSI chip directly mapped only in the TT integration, the Falcon 
>> needs to access SCSI registers through the ST-DMA chip, and needs the 
>> weird ST-DMA locking scheme plus a few other quirks.
>>
>> Looking at atari_scsi.c - the code is full of IS_A_TT() macros and other 
>> Atari specfic macros that could be replaced by testing bits in a feature 
>> map. One bit (TT or Falcon style SCSI integration) rather - that still 
>> leaves the register access functions for TT and Falcon to sort out.  Do 
>> you plan to do all that in one go?
>>     
>
> No, not in one go. That would be a separate patch, so that each patch has 
> a single well defined purpose.
>
> I'm not particularly concerned about atari_scsi.c. I am concerned about 
> the three forks of the core driver (not least because of the shared 
> header) that's why I've sent patches for sun3_NCR5380 and atari_NCR5380 in 
> the past.
>   

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. 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.

The rest of the differences were tweaks added by the Atari SCSI author 
to make the driver behave with borderline standards compliant hardware 
(long reset delay for some CD drives, tweaks to bus settle delays). 
Probably not that critical in the first instance.

>> Might need another platform device for the ST-DMA as well ...
>>     
>
> I don't think that relates to scsi_register() deprecation.
>   

Not at all - just to the platform device conversion. Not sure I fully 
understand what you have in mind, though.

Cheers,

    Michael