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
with a call to macfb_clear().
[The purpose of macfb_init() is almost exclusively to initialize the
raster console blitter. We really, really do not want to do this unless
we are actually initializing the console device, else we'll give rcons
the attributes of the last-seen fb device. These will not necessarily
correspond to the attributes of the actual console device!]
addresses, it makes sense to print the actual address of the device rather
than the original address. The latter is useful to distinguish the type
of device only, so we maintain that data internally (as we always have).
This closes PR 10557 from Dave Huang.
respond in the allotted time if they're told to TALK immediately after
completing a LISTEN command. Experimentation with adb_op_sync() yielded
consistent results when the timeout was increased from the documented
6900 usec to 8000 usec, so we'll make that change here.
(Accurate and complete documentation of the hardware sure would help...)
"off_t" and the return value is a "paddr_t" to allow mappings
at offsets past 2^31 bytes. Somewhat inspired by FreeBSD, which
only changed the offset to a "vm_offset_t".
Includes updates for the i386, pc532 and sh3 mmmmap from Jason Thorpe.
a keyboard event before wskbd is attached. Make sure we've done that before
passing an event to kbd_intr(), which in turn hands off to wskbd_input().
This is another part of the fix for PR 10086.
had set splhigh() but returned without restoring the previous spl.
The PowerBook keyboard works better, now, but still starts to flake
out pretty badly at 70+ wpm.
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.
a serial console; the direct driver didn't care, but the MRG driver
wouldn't probe ADB when using a serial console. Remove the check from
the MRG version of the code to resolve this difference.
funk when they misbehave and give us unexpected results. Specifically:
- Don't assume that the first free slot is at the top of the table if
we can't find one.
- Don't increment ADBNumDevices when backfilling "holes" left by devices
that didn't respond to a TALK R3 during the initial device scan.
- Don't assume that an address reassignment worked; make sure something
responds on the new address before plowing forward.
- If after device reassignment there are no free slots, make sure to
indicate this fact.
- Failing all else, handle the situation where we run out of slots in
the device table -- which now should "never" happen -- gracefully.
While the Power Manager driver still sometimes misbehaves, it shouldn't
cause the system to crash/hang due to us walking off the end of the
device table.
jdolecek