This is a completely rewritten scsipi_xfer execution engine, and the
associated changes to HBA drivers. Overview of changes & features:
- All xfers are queued in the mid-layer, rather than doing so in an
ad-hoc fashion in individual adapter drivers.
- Adapter/channel resource management in the mid-layer, avoids even trying
to start running an xfer if the adapter/channel doesn't have the resources.
- Better communication between the mid-layer and the adapters.
- Asynchronous event notification mechanism from adapter to mid-layer and
peripherals.
- Better peripheral queue management: freeze/thaw, sorted requeueing during
recovery, etc.
- Clean separation of peripherals, adapters, and adapter channels (no more
scsipi_link).
- Kernel thread for each scsipi_channel makes error recovery much easier
(no more dealing with interrupt context when recovering from an error).
- Mid-layer support for tagged queueing: commands can have the tag type
set explicitly, tag IDs are allocated in the mid-layer (thus eliminating
the need to use buggy tag ID allocation schemes in many adapter drivers).
- support for QUEUE FULL and CHECK CONDITION status in mid-layer; the command
will be requeued, or a REQUEST SENSE will be sent as appropriate.
Just before the merge syssrc has been tagged with thorpej_scsipi_beforemerge
This adds the missing wbflush() calls after writing register data.
At same time tidy up several comments and make several KNF changes.
XXX: The z8530 MI driver doesn't support bus_space access to the registers
(lacks a hook for storing a bus space tag, and stores register
addresses directly)
Until other ports catch up (this is the first) we have overlayed
the missing data in the MD structures
Give rest of clock interrupt code a revamp. Because we are using an external
cycle counter we can now handle loosing several hundred interrupts without
the time slipping.
If the machine uses a Z85230 ESCC device with deep buffers, we observe
output glitches when printing the zstty{0,1} probe lines when the device
is reset & reprogrammed during startup.
There is no easy 'hook' in the MI Z8530 driver, so we wait for output
buffer to drain before changing the baud rate generator prescaler value.
If the DMA chaning interrupt couldn't be serviced immediately (higher spl
level when kernel doing something else) a few microseconds later the NCR
controller will fill its FIFO and also interrupt the CPU.
The SCSI interrupt sees the terminal count has been reached, calls
asc_dma_intr to finish the job off. The FIFO cannot be flushed because
the block count hasn't been setup for the last dma segment (DMA chaining
still wasn't serviced).
Since the NCR 53c94 FIFO is only 16 bytes in size, any short DMA in this
size combined with the machine 'doing something else' causes the problem
to occur.
Servicing the DMA chaining interrupt before the NCR SCSI interrupt solves
this problem.
Add tests to ensure the DMA FIFO has been flushed correctly at the end of
each DMA operation just to be on the safe side.
- Using the prom getenv function determine the correct console port
- Remove old prom function hooks
- Tidy up bootflags (remove upper case names, fixup RB_ASKNAME) as
recommended by Jaromír Doleèek
handler to hook up device interrupts and softc callbacks.
Suggested by: Jason Thorpe and Toru Nishimura
* Fixup the indenting in a few places to conform to NetBSD style
the DMA FIFO on non block aligned writes. Not doing this causes large
writes (>4k) that are not aligned to incorrectly write 64bytes
of data every 4k interval. This only occurs on raw devices - typically
newfs fails to create a clean filesystem.
mrg