left out as it was a no-op on the R3000 processor. However, recent changes
to the Mips cache ops highlighted we should DTRT in case the MI/MD layer
choses to invalidate the cache ahead of the DMA instead of after it.
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
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.
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.
