It is currently Thu, 20 Jan 2022 10:06:20 GMT



 
Author Message
 NCR5380 generic driver code, ALPHA T128/128F/228 SCSI driver
I was contracted by Yggdrasil computing to do a device driver for the
Trantor T128 SCSI boards often bundled with CDROMs, and it's now ready
for alpha test.  Obviously, owners of Trantor SCSI boards
(T128,128F,228) will be interested in this, owners of other NCR5380
based boards (such as the PAS16 with SCSI port) might want to take a
look at it since the heart of it is an easily adaptable generic NCR5380
driver, and developers may be interested in some of the design descisions
I made.  If you fall into any of these groups, read on.

I'd rather spend my time finishing a rewrite of the SCSI FAQ
(the FAQ people want to call these things "HOW TOs", I'll call
it a FAQ because it's only the questions I spend far too much
time answering), doing some benchmarking, and hacking code than
handholding.  There are also some environments that I don't have
access to, so I'd like some feedback from testing in those
environments.  I want alpha testers who

- Will patch the pl12 kernel and compile it themselves

- Can live with the fact that the autoprobe probably won't work
  for them until they come up with a BIOS signature, which they'll
  mail to me.

- Won't {*filter*} at me if it doesn't work for them, and if it doesn't
  are willing to play with the various debugging controls to see
  where it isn't working.

- Are willing to run a few benchmarks for me.  I'm really
  interested in how different parameters on the queue handling
  affects performance.  I've observed a 20-30% performance increase
  on reads (the change to writes is negligible) if I allow two commands
  per LUN to be outstanding (ie, to have propogated to the lowest
  driver level).  I'm really interested in seeing how this affects
  faster devices (the drive I used was interleaved 3:1, giving a
  330K/second head rate), and SCSI-II devices supporting tagged
  queueing where commands can propogate all the way to the
  device.

If you can't fit these criteria, please wait for the public release.

Testers that are especially welcome include

- People with multiple SCSI devices

- People with SCSI-II devices (the code supports SCSI-II tagged queing)

Design things, with quotes from the comments :

Often autoprobe routines screws up, so (Thanks to Pat Mackinlay for
the Seagate driver command line override patches, without them
I wouldn't have thought about letting the user configure the driver
at boot time)

 * The card is detected and initialized in one of several ways :
 * 1.  Autoprobe (default) - since the board is memory mapped,
 *     a BIOS signature is scanned for to locate the registers.
 *     An interrupt is triggered to autoprobe for the interrupt
 *     line.
 *
 * 2.  With command line overrides - t128=address,irq may be
 *     used on the LILO command line to override the defaults.
 *
 * 3.  With the T128_OVERRIDE compile time define.  This is
 *     specified as an array of address, irq tupples.  Ie, for
 *     one board at the default 0xcc000 address, IRQ5, I could say
 *     -DT128_OVERRIDE={{0xcc000, 5}}
 *
 *     Note that if the override methods are used, place holders must
 *     be specified for other boards in the system.

 * Design
 * Issues :
 *
 * The other Linux SCSI drivers were written when Linux was Intel PC-only,
 * and specifically for each board rather than each chip.  This makes their
 * adaptation to platforms like the Amiga (which uses the same WD/AMD
 * SCSI chip as the 7000FASST) more difficult than it has to be.
 *
 * Also, many of the SCSI drivers were written before the command queing
 * routines were implemented, meaning their implementations of queued
 * commands were hacked on rather than designed in from the start.
 *
 * Finally, when I designed the Linux SCSI drivers I figured that
 * while having two different SCSI boards in a system might be useful
 * for debugging things, two of the same type wouldn't be used.
 * Well, I was wrong and a number of users have mailed me about running
 * multiple high-performance SCSI boards in a server.
 *
 * This driver attempts to address these problems :
 * This is a generic 5380 driver.  To use it on a different platform,
 * one simply writes appropriate system specific macros (ie, data
 * transfer - some PC's will use the I/O bus, 68K's must use
 * memory mapped) and drops this file in their 'C' wrapper.
 *
 * As far as command queueing, a pair of queues are maintained for
 * each 5380 in the system - commands that haven't been issued yet,
 * and commands that are currently executing.  This means that an
 * unlimited number of commands may be queued, letting more commands
 * propogate from the higher driver levels giving higher througput.
 * Note that both I_T_L and I_T_L_Q nexuses are supported, allowing
 * multiple commands to propogate all the way to a SCSI-II device
 * while a command is allready executing.
 *
 * To solve the multiple-boards-in-the-same-system problem,
 * there is a separate instance structure for each instance
 * of a 5380 in the system.  So, mutliple NCR5380 drivers will
 * be able to coexist with appropriate changes to the high level
 * SCSI code.  
 *
 * Issues specific to the NCR5380 :
 *
 * When used in a PIO or pseudo-dma mode, the NCR5380 is a braindead
 * piece of hardware that requires you to sit in a loop polling for
 * the REQ signal as long as you are connected.  Some devices are
 * brain dead (ie, many TEXEL CD ROM drives) and won't disconnect
 * while doing long seek operations.
 *
 * The workarround for this is to keep track of devices that have
 * disconnected.  If the device hasn't disconnected, for commands that
 * should disconnect, we do something like
 *
 * while (!REQ is asserted) { sleep for N usecs; poll for M usecs }
 *
 * Some tweaking of N and M needs to be done.  An algorithm based
 * on "time to data" would give the best results as long as short time
 * to datas (ie, on the same track) were considered, however these
 * broken devices are the exception rather than the rule and I'd rather
 * spend my time optomizing for the normal case.
 *
 * Architecture :
 *
 * At the heart of the design is a corroutine, NCR5380_main,
 * which is started when not running by the interrupt handler,
 * timer, and queue command function.  It attempts to establish
 * I_T_L or I_T_L_Q nexuses by removing the commands from the
 * issue queue and calling NCR5380_select() if a nexus is not
 * established.
 *
 * Once a nexus is established, the NCR5380_information_transfer()
 * phase goes through the various phases as instructed by the target.
 * if the target goes into MSG IN and sends a DISCONNECT message,
 * the command structure is placed into the per instance disconnected
 * queue, and NCR5380_main tries to find more work.  If USLEEP
 * was defined, and the target is idle for too long, the system
 * will try to sleep.
 *
 * If a command has disconnected, eventually an interrupt will trigger,
 * calling NCR5380_intr, which will inturn call NCR5380_reselect
 * to restablish a nexus.  This will run main if necessary.
 *
 * On command termination, the done function will be called as
 * appropriate.
 *
 * SCSI pointers are maintained in the SCp field of SCSI command
 * structures, being initialized after the command is connected
 * in NCR5380_select, and set as appropriate in NCR5380_information_transfer.
 * Note that in violation of the standard, an implicit SAVE POINTERS operation
 * is done, since some BROKEN disks fail to issue an explicit SAVE POINTERS.

To  get other NCR5380 boards (ie, SCSI PAS16's, etc) supported, you
write a couple of macros and do a

#include "NCR5380.c" in a wrapper file

/*
 * Using this file :
 * This file a skeleton Linux SCSI driver for the NCR 5380 series
 * of chips.  To use it, you write a architecture specific functions
 * and macros and include this file in your driver.
 *
 * These macros control options :
 * PSEUDO_DMA - if defined, PSEUDO DMA is used during the data transfer phases.
 *
 * REAL_DMA - if defined, REAL DMA is used during the data transfer phases.
 *
 * SCSI2 - if defined, SCSI-2 tagged queing is used where possible
 *
 * USLEEP - if defined, on devices that aren't disconnecting from the
 *      bus, we will go to sleep so that the CPU can get real work done
 *      when we run a command that won't complete immediately.
 *
 * Note that if USLEEP is defined, NCR5380_TIMER *must* also be
 * defined.
 *
 * Defaults for these will be provided if USLEEP is defined, although
 * the user may want to adjust these to allocate CPU resources to
 * the SCSI driver or "real" code.
 *
 * USLEEP_SLEEP - amount of time, in jiffies, to sleep
 *
 * USLEEP_POLL - amount of time, in jiffies, to poll
 *
 * These macros MUST be defined :
 * NCR5380_local_declare() - declare any local variables needed for your transfer
 *      routines.
 *
 * NCR5380_setup(instance) - initialize any local variables needed from a given
 *      instance of the host adapter for NCR5380_{read,write,pread,pwrite}
 *
 * NCR5380_read(register)  - read from the specified register
 *
 * NCR5380_write(register, value) - write to the specific register
 *
 * NCR5380_implementation_fields  - additional fields needed for this
 *      specific implementation of the NCR5380
 *
 * Either real DMA *or* pseudo DMA may be implemented
 * REAL functions :
 * NCR5380_REAL_DMA should be defined if real DMA is to be used.
 * NCR5380_dma_write_setup(instance, src, count) - initialize
 * NCR5380_dma_read_setup(instance, dst, count) - initialize
 * NCR5380_dma_residual(); - residual count
 *
 * PSEUDO functions :
 * NCR5380_pwrite(instance, src, count)
 * NCR5380_pread(instance, dst, count);
 *
 * If nothing specific to this implementation needs doing (ie, with external
 * hardware), you must also define
 *  
 * NCR5380_intr
 * NCR5380_queue_command
 * NCR5380_reset
 * NCR5380_abort
 *
 * to be the global entry points into the specific driver, ie
 * #define NCR5380_queue_command t128_queue_command.
 *
 * If this is not done, the routines will be defined as static functions
 * with the NCR5380* names and the user must provide a globally
 * accessable wrapper function.

Comments concerning the code and discussion of the cleanest method
for multi-instance support in the higher level code are welcome,
whining and flames to /dev/null.

I'll mail a copy of the code to anyone who responds in e-mail,
but don't want to do a full public distribution at this point
because I only want testers who don't need handholding, and are
willing to run a few benchmarks.  Distributing the patches in
email means I can send updates out without effort, and can stay
in close contact with the people running benchmarks for me.
--
Boycott USL/Novell for their absurd anti-BSDI lawsuit. | Drew Eckhardt,
Condemn Colorado for Amendment Two.                    | Profesional Linux
Use Linux, the fast, flexible, and free 386 unix       | Consultant
Will administer Unix for food                          | d...@cs.Colorado.EDU

--
Send submissions for comp.os.linux.announce to: linux-annou...@tc.cornell.edu



 Thu, 22 Feb 1996 01:10:31 GMT   
 
   [ 1 post ] 

Similar Threads

1. T128 / NCR5380 driver, second release

2. 2.4.20 compile fix for drivers/scsi/t128.c

3. How to install a UMAX SCSI clone onto the NCR5380 driver, redux

4. How to install a UMAX SCSI clone onto the NCR5380 driver

5. 2.4.17 drivers/scsi/NCR5380.c

6. Need help with Generic NCR5380 SCSI Interface

7. Generic NCR5380 SCSI problem

8. PATCH: fix t128 for new NCR5380

9. Device driver question (generic device driver)


 
Powered by phpBB © 2000, 2002, 2005, 2007 phpBB Group.
Designed by ST Software