pci_attach_args *" instead of from four separate parameters which in
all cases were extracted from the same "struct pci_attach_args".
This both simplifies the driver api, and allows for alternate PCI
interrupt mapping schemes, such as one using the tables described in
the Intel Multiprocessor Spec which describe interrupt wirings for
devices behind pci-pci bridges based on the device's location rather
the bridge's location.
Tested on alpha and i386; welcome to 1.5Q
timeout()/untimeout() API:
- Clients supply callout handle storage, thus eliminating problems of
resource allocation.
- Insertion and removal of callouts is constant time, important as
this facility is used quite a lot in the kernel.
The old timeout()/untimeout() API has been removed from the kernel.
* QUIRK_NOMSG only has any meaning when NCR_GETCC_WITHMSG
is defined. Therefore, there's no harm in using it when
NCR_GETCC_WITHMSG is not defined. so, simplify the table
by removing the #ifdef.
* there's really no point in having table entries after
an entry which will match everything.
* add some comments, clean up spacing.
* add an entry for "QUANTUM"/"ATLAS IV" drives with flags
QUIRK_NOTAGS|QUIRK_NOMSG. (I included the latter flag only
because everything else had it before! ... which means that
all the functionality added with the NCR_GETCC_WITHMSG define
would never get used! *sigh*) The latter fixes the problems
I was having on an Atlas, and should fix the problems mentioned
by Hans Hoppe <hopha@casema.net> in comments on PR#7694.
1.4.x and i have concerns (but no concrete proof) they will cause/have caused
problems in -current as well. Really, the right way to fix this is to
rewrite the driver, and push up tagged queueing handling into a common
middle layer that'll do it right in a low-level-driver-independent manner.
I'll fix my particular issues by using the ncr driver quirk mechanism.
already involve byte swapping on big-endian systems due to bus_space_*().
However, the use is self-consistent, and the value is not interpreted
by the chip, so it probably does not matter. Leave them in for now; we
can always look at their removal later.
do a gross hack which allows seemingly-broken quantum drives to function
with this driver. The gross hack is to disable tagged queueing completely
when QUEUE FULL is received. That costs performance on drives which
do tagged queueing properly and which return QUEUE FULL, but given the way
this driver works it's seems to be the only thing short of significant
recoding which will make it function with the quantum drives in question.
queueing support that decreases the number of openings on a device; it
previously assumed that a scsipi_link's `openings' were descreased as
commands were issued, which is not longer the case (`active' is increased).
directly. That would require that we map the scsipi_xfer into DMA
space. Instead, copy to/from the NCR CCB, which the script already
has to DMA to/from. These copies are small, and don't seem to affect
performance.
Separate the ncb (i.e. softc) members that are accessed by the script into
a separate structure. Allocate one of these structures in DMA safe memory
using bus_dma, and change RELOC_SOFTC to use the DMA address of this
structure.
struct scsipi_adapter; they were not used.
Add a scsipi_ioctl entry point to struct scsipi_adapter. This will be
used to issue ioctl commands to the host adapters.
Inspired by PR #6090, from Matt Jacob.
associated with any observed lossage...it was just noticed while reading
ncr_start().
g/c some now-unreachable code produced by the earlier race condition fix.
(currently only CD-ROM drives on i386). The sys/dev/scsipi system provides 2
busses to which devices can attach (scsibus and atapibus). This needed to
change some include files and structure names in the low level scsi drivers.
by default if it's usable, but falling back to I/O space if mem isn't usable.
If NCR_IOMAPPED is defined (default on the x86), prefer I/O space
then fall back to mem. Also, clean up the various memory consistency checks
so that they can deal with run-time determination of whether or not the
device is to be memory- or I/O-mapped.
