Subject: ncr53cxxx driver design issues
To: None <email@example.com>
From: Manuel Bouyer <firstname.lastname@example.org>
Date: 04/16/2000 21:49:48
developers already know, I'm rewriting a driver for the ncr53c8xx SCSI
controllers from scratch (the in-tree ncr driver suffers from enouth
problems to just drop it).
I've been playing with hardware for a week now; with some success as
I can mount my HD or MO drive R/W, without sync or disconnect though (I've
even been able to compile a kernel on my scsi drive). I hope to commit an
initial version in about a week.
Before going further I've a main design issue to sort.
I think the rigth way to go is to split ncr53c8xx support in 2 drivers;
one for older boards without script RAM, and one for the newer with
script RAM (these are the 825, 875/876 and 895/896). Appart from the
RAM these controlles also have an extended instruction set and
10 scratch registers instead of 2. This (especially the extended instruction
set) makes it possible to write much more efficient scripts.
On the opposite the earlier 53x8xx chips are close enouth to the 53c720
(I believe the 815 and the 720 have the same instruction set, although I didn't
find much docs other than drivers for the 720 yet).
So I think a more natural way of doing thing is to have a driver for
the 720, 810, 815 and 860; and another one for the 825, 875 and 895.
The 53c710 has different registers offset, so it will be hard to support
it in the same driver as the 720. However it should be possible to
use the same source code with compile-time #defines.
Another issue is endianess: all 53c8xx are assumed to be little endian (as
they live behind a PCI bus); but I guess the 720 can be either big or little
depending on which bus it's connected. A flag set by the bus front end
will probably be needed so that the bus-independant part can use htole/htobe
Comments or suggestions ?
Manuel Bouyer <email@example.com>