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