in how interrupts are down- the 23XX has not only a different place to check
for an interrupt, but unlike all other QLogic cards, you have to read the
status as a 32 bit word- not 16 bit words. Rather than have device specific
functions as called from the core module (in isp_intr), it makes more sense
to have the platform/bus modules do the gruntwork of splitting out the
isr, semaphore register and the first outgoing mailbox register (if needed)
*prior* to calling isp_intr (if calling isp_intr is necessary at all).
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
saves about 2.2MB under /usr/include/dev/. Discussed on tech-kern@
recently.
I HOPE to get the list right. The headers I left in are ones
used for MI tools and those whose usage I discovered by grep over tree sources.
Feel free to put needed includes back in if you encounter anything which
should not be removed from lists.
to last time.
It turns out that in fact, sparc64 was *not* working. There is a discussion
within the tech-kern@netbsd.org mail list as of just prior to this date
that contains the details.
Suffice to say that for sparc64 we have to add back in the usage
of BUS_DMA_COHERENT again to the call to bus_dmamap_load_raw. PK
added the usage of bus_dmamap_load_raw- which agrees with the
man page description of it- but now does not match what the
original BusDma author seems to think it's supposed to do.
While we're at it, do a specific set of steps for setting up and,
if necessary, tearing down, mailbox dma mappings.
right thing, don't use the illegal and "just worked by chance" addition
of BUS_DMA_COHERENT to bus_dmamap_load_raw. There still is a necessity
to add to the architecture to allow one to hint that this should be
a cache coherent mapping.
Fix offset argument to be zero for flushing data tranfers. Kudos to Izumi
for spotting this.
use interrupting mailbox commands for isp_init. Set default HBA role.
Rename request/response dma maps to be more consistent with PCI version.
Enable bus_dmamap_sync on request queue- we already do this for response
queue- better do it for the request queue as well.
Checked to be working against a Sparc10.
eeh