Hi,
those following source-changes will have noticed I've done some haking on the
siop driver these days.
I've added a new driver, esiop, which match the siop chips with the
requested properties (basically enouth general purpose registers, the
load/store instruction and "aithmetic ops on 2 registers). This should
match the 53c825, 875 and newer, and the 53c770 (although I think no
front-end exists for a 770 yet). the siop front end should still work for
these controllers, esiop will be prefered if present.
The largest part of the code is shared with siop, so the size increase of
the kernel is really small (~20k if esiop is added, about 1k if esiop remplaces
siop). More code will probably be shared in the future.

esiop uses a different script, taking advantages of the features not present
in older chips. This allows a more efficient interface between the host and
adapter (which is the main reason it's a different driver).
The way to pass commands to the script require less overhead (less read/write
from both the script and the host), and more commands can be queued at once
(up to 256). For normal command completion, the script doesn't need to send
an interrupt to the host and halt. This allows the controller to start a new
command or handle a reselect quicker, and reduce the interrupt load on the
host. In heavy disk operation, I've seen in general between 1 and 1.5
interrupts per tranfers, sometimes much less than 1 with multiple disks
(for example, a raid parity rebuild would generate 2000 interrupts per seconds
with the old driver, and around 750 with esiop for the same I/O rate).
esiop can also start 256 tagged commands per device, vs 15 for siop.

I also added Ultra/160 support to esiop for the 53x1010. It would be trivial
to add it to siop as well, but I'm not sure we want that: we may want to keep
siop as small as possible, for boot floppy, etc ...

I will probably continue to tweak the script and interrupt routines for
performances and code sharing in the next few days; however I think
esiop should be useable as is, and improve things for modern hardware.

As usual, report any problem with send-pr.

-- 
Manuel Bouyer <bouyer@antioche.eu.org>
--