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
o Cut out the probed stuff. We no longer need it since newbus implicitly
checks for this (likely bt can be changed as well in this way).
o Add preliminary support for unload. Untested because aha doesn't yet
support identify and there are some interactions with PnP that I've
not yet worked out.
With this I can boot the AHA-1542CP FW F.0. All the aha resources
appear to be picked up via pnp now.
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.
I386_BUS_SPACE_IO. Compiles now on the Alpha, but likely will not
work due to bus space address <-> virtual address mapping bogons that
work for i386 but not alpha.
work. Be more verbose when one cannot allocate IRQ, et al since this
is a common configuration problem. The cards have the IRQ soft wired
into their BIOS and do not try to do collision detection. This can
cause problems when this IRQ is the same as another card/device.
The PNP hasn't been tested. My PNP board is in a deployed system.
I'll sneak in testing of it sometime later. I've been able to mount
the 3.3R cdrom that arrived today and access files off it.
Submitted by: dfr
i386 platform boots, it is no longer ISA-centric, and is fully dynamic.
Most old drivers compile and run without modification via 'compatability
shims' to enable a smoother transition. eisa, isapnp and pccard* are
not yet using the new resource manager. Once fully converted, all drivers
will be loadable, including PCI and ISA.
(Some other changes appear to have snuck in, including a port of Soren's
ATA driver to the Alpha. Soren, back this out if you need to.)
This is a checkpoint of work-in-progress, but is quite functional.
The bulk of the work was done over the last few years by Doug Rabson and
Garrett Wollman.
Approved by: core
pnp system in freebsd, I'm not sure how useful this will be, but my
1542CP seems to work well in plug and play mode and does seem to
probe correctly at all the oddball addresses/irq/drqs that I tried.
[[
I was unable to get /kernel.conf or /kernel.config to read in, so
I wasn't able to verify that this method of userconfig works. that's
one thing that makes pnp so hard to use in the current scheme.
Pointers to the right new way of doing this accepted.
]]
o Add some kludges to maybe bring support for 1540A/1542A into the
driver. Since I have no 154xA cards, and the only person I know
that has them hasn't given me feedback, I'm making this commit
blind.
o Honor unit numbers that are in the config file now. This allows one
to hard wire the unit numbers (and have high unit numbers for plug
and pray devices, which can't seem to be hardwired) and have the
cards not migrate from aha1 -> aha0 should aha0 go on the fritz. I
didn't verify that hard wired scsi busses would work, but did verify
that hard wired aha addresses did work to a limited extent. Both
aha0 and aha1 must be hardwired, or when the card that was in aha0
goes away, the probe for aha0 might pick up the card that otherwise
would have been aha1.
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
