Add two new arguments to bus_dma_tag_create(): lockfunc and lockfuncarg.
Lockfunc allows a driver to provide a function for managing its locking
semantics while using busdma. At the moment, this is used for the
asynchronous busdma_swi and callback mechanism. Two lockfunc implementations
are provided: busdma_lock_mutex() performs standard mutex operations on the
mutex that is specified from lockfuncarg. dftl_lock() is a panic
implementation and is defaulted to when NULL, NULL are passed to
bus_dma_tag_create(). The only time that NULL, NULL should ever be used is
when the driver ensures that bus_dmamap_load() will not be deferred.
Drivers that do not provide their own locking can pass
busdma_lock_mutex,&Giant args in order to preserve the former behaviour.
sparc64 and powerpc do not provide real busdma_swi functions, so this is
largely a noop on those platforms. The busdma_swi on is64 is not properly
locked yet, so warnings will be emitted on this platform when busdma
callback deferrals happen.
If anyone gets panics or warnings from dflt_lock() being called, please
let me know right away.
Reviewed by: tmm, gibbs
adv_free() as the ISA probe routine doesn't malloc() ccb_infos but does
call adv_free().
- Release the ISA-only overrun DMA tags, bufs, and maps if the probe fails.
Tested by: rwatson
hasseen_isadev so this will be less noisy when conflicts do exist.
Also eliminate redundant warnings about conflicts.
Requested by: bde
Reviewed by: gibbs
o For bt and aha only probe the one I/O range if a specific I/O is specified
in the config file.
o Don't even try to probe I/O ranges that have been seen already.
o If we conflict with an IRQ or DRQ, then fail the probe.
Requested by: bde, gibbs
Approved by: jkh
This will make a number of things easier in the future, as well as (finally!)
avoiding the Id-smashing problem which has plagued developers for so long.
Boy, I'm glad we're not using sup anymore. This update would have been
insane otherwise.
I have only tested the ABP5140 card and only with a single CDROM drive
but it seems to work fine. This driver relies on features found only in
the SCSI branch so will not work in -current until those changes
are brought in. It also doesn't have any error handling code *yet*.
The goal is to use this driver as the development platform for the new
generic SCSI layer error recovery/handling code.
PCI and EISA front ends will show up as soon as I get my hands on
the cards. There are also a few issues in the driver that I need
to clear up with AdvanSys before I can suggest sticking one of
these cards in your server. 8-)
Thanks to AdvanSys for releasing this code under a suitable copyright.
Obtained from: Ported from the Linux driver writen by
bobf@advansys.com (Bob Frey).
