Subject: Rewrite of Acorn ASC SCSI driver
To: None <port-arm32@netbsd.org>
From: Richard Earnshaw <rearnsha@arm.com>
List: port-arm32
Date: 09/24/1999 13:53:27
For those of you that don't follow current-users:

I don't know how many people have one of these cards, but in if you have 
then you may well be interested in taking a look at pr-8484 that I have 
just submitted.  This contains a re-write of the driver for these cards 
which boosts performance significantly (5 to 10 x).

I'm not going to repost the code here (you can find it in the PR), but 
I've enclosed the 'text' part of the message.  There is one small 
correction to this: I've been testing with an AKA-31 card (not the AKA-32 
card as stated), but I believe the cards are effectively equivalent in 
hardware terms.

I'd be interested to know if anyone else is using one of these with NetBSD.

Richard.

	The following uu-encoded file contains patches to re-implement the
	SCSI driver interface for the Acorn AKA-30/31/32 SCSI cards, which
	use the WD33C93A chip.  This new implementation has the following
	benefits:

	1) The sbic code has been rewritten to use the bus_space_... and
	bus_dma_... bus-independent functions and is now independent
	of the low-level implementation of the IO interface.
	2) The sbic code has been tuned to give approximately 30%
	performance increase when reading in polled mode.  (A similar minor
	performance enhancement for writing is probably also possible, but
	has not been implemented.
	3) The ASC specific code has been almost completely rewritten to 
	provide bus_dma functions that bounce via the on-board SRAM.
	Code to program the on-board uPD71071 DMA controller chip has
	been added.
	4) Highly optimized assembler routines for transfering data to
	and from the SRAM card.

	Performance with the new driver shows that peek transfer rates are
	now about 1.1 MB/s (using dd with 64K buffers) which is somewhere
	between 5 & 10 times better than before (I've lost my original
	figures).  In normal operation I've seen up to around 900K/s; but
	probably more importantly, the load on the cpu is much lower than
	it was before.

	I've tested the new code fairly heavily on my system (AKA-32
	with 2 scsi hard disks and 1 zip-250 drive) over the last couple of
	months without seeing any problems.  I haven't tested it with scsi
	tapes or scanners.

	Note: the code was developed on a machine running the 1.4 release,
	I haven't tested it under later versions (or -current), but
	AFAIK no commits have been made to the relevent source files 
	since then, so it should all just work(TM).