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.
Dave Huang <khym@bga.com>
Tested on alpha by cgd, tested on several i386 boxes. Certainly causes
no harm to the goddamned mess, but the NCR driver only works when you
perform voodoo rituals on it anyway.
This is what Dave said (in email) has been added to the driver:
----------------------------------------------------------------------
This seems to be the most significant change:
General cleanup and new features for 53c875 based cards, especially the
Tekram DC390W/U/F, whose config EEPROM can now be dumped, if the kernel
is built with option NCR_TEKRAM_EEPROM.
Other changes:
- add brackets to expansion of OUTB/W/L macro arguments.
- remove unused NCB structure element ns_async
- support sync. SCSI offset of 16 (instead of only 8) on 825A and 875
- correctly identify 53c810A and 53c825A chips
- preserve SCSI BIOS settings of PCI performance options
- remove (already disabled) support for NCR reset because of command timeout
- reverse order of reading of SCSI and DMA specific interrupt cause registers
- add definition of Tekram config EEPROM contents (not currently used)
----------------------------------------------------------------------
2841, plus some fixes to make the patches work on the Alpha. Seems to
improve the NCR driver a lot. We probably should try to incorporate
any updates that have happened since, too.
(This fixes problems with the printf format fixes i checked in yesterday.
ptrdiff_t is an 'int' on the i386 but a 'long' on the alpha, so the cast
really is necessary... *sigh*)
