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
--
To unsubscribe from this list: send the line "unsubscribe linux-m68k" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
