now takes a device_t to be the parent of the bus that is being created.
Most SIMs have been updated with a reasonable argument, but a few exceptions
just pass NULL for now. This argument isn't used yet and the newbus
integration likely won't be ready until after 7.0-RELEASE.
use to synchornize and protect all data objects that are used for that
SIM. Drivers that are not yet MPSAFE register Giant and operate as
usual. RIght now, no drivers are MPSAFE, though a few will be changed
in the coming week as this work settles down.
The driver API has changed, so all CAM drivers will need to be recompiled.
The userland API has not changed, so tools like camcontrol do not need to
be recompiled.
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
BUS_DMASYNC_ definitions remain as before. The does not change the ABI,
and reverts the API to be a bit more compatible and flexible. This has
survived a full 'make universe'.
Approved by: re (bmah)
This allows us to successfully attach early Storage Dimension cards.
Allocate mailboxes for the 742A bellow the 16MB limit. Although these
cards seem to be able to deal with all other types of data anywhere
in a 32bit address space, 24bit addresses are required for mailboxes.
bt_eisa.c:
Add device IDs for all Storage Dimension products I could
find from their web site.
Thanks to Ted Mittelstaed for loaning me the equipment to diagnose
and fix these problems.
Collect together the components of several drivers and export eisa from
the i386-only area (It's not, it's on some alphas too). The code hasn't
been updated to work on the Alpha yet, but that can come later.
Repository copies were done a while ago.
Moving these now keeps them in consistant place across the 4.x series
as the newbusification progresses.
Submitted by: mdodd
resource_list_release. This removes the dependancy on the
layout of ivars.
* Move set_resource, get_resource and delete_resource from
isa_if.m to bus_if.m.
* Simplify driver code by providing wrappers to those methods:
bus_set_resource(dev, type, rid, start, count);
bus_get_resource(dev, type, rid, startp, countp);
bus_get_resource_start(dev, type, rid);
bus_get_resource_count(dev, type, rid);
bus_delete_resource(dev, type, rid);
* Delete isa_get_rsrc and use bus_get_resource_start instead.
* Fix a stupid typo in isa_alloc_resource reported by Takahashi
Yoshihiro <nyan@FreeBSD.org>.
* Print a diagnostic message if we can't assign resources to a PnP
device.
* Change device_print_prettyname() so that it doesn't print
"(no driver assigned)-1" for anonymous devices.
- Work around a problem not yet solved in the tree (but solved in mine.)
device_get_ivars() should never be cast to a struct resource_list *
The solution, under review, involves the creation of a
device_get_resource_list() function. More later.
MCA SCSI adapters.
bt_mca.c is going to live in sys/dev/buslogic instead of sys/dev/mca
as per a conversation with Peter, Doug and Mike.
Thanks to Andy Farkas <andyf@speednet.com.au> for being such a good
sport and doing all the testing for me (as I don't actually own one
of these cards. Yet.)
eisa_add_intr() which now takes an additional arguement (one of
EISA_TRIGGER_LEVEL or EISA_TRIGGER_EDGE).
The flag RR_SHAREABLE has no effect when passed to
bus_alloc_resource(dev, SYS_RES_IRQ, ...) in an EISA device context as
the eisa_alloc_resource() call (bus_alloc_resource method) now deals
with this flag directly, depending on the device ivars.
This change does nothing more than move all the 'shared = inb(foo + iobsse)'
nonesense to the device probe methods rather than the device attach.
Also, print out 'edge' or 'level' in the IRQ announcement message.
Reviewed by: dfr
