src-test2/sys/dev/wds, branch release/9.2.0FreeBSD source treehttps://cgit-dev.freebsd.org/src-test2/atom?h=release%2F9.2.02013-06-18T00:36:53ZBig MFC of the physbio changes necessary for unmapped I/O. These changes2013-06-18T00:36:53ZScott Longscottl@FreeBSD.org2013-06-18T00:36:53Zurn:sha1:039e422c063977ba9073fd2c93883dd8a5a36d48
have been in production at Netflix for several months with significant
success.
MFC r246713:
Reform the busdma API so that new types may be added without modifying
every architecture's busdma_machdep.c. It is done by unifying the
bus_dmamap_load_buffer() routines so that they may be called from MI
code. The MD busdma is then given a chance to do any final processing
in the complete() callback.
MFC r249538:
Some compilers issue a warning when wider integer is casted to narrow
pointer. Supposedly shut down the warning by casting through
uintptr_t.
MFC r251479:
Simplify the checking of flags for cam_periph_mapmem(). This gets rid of
a lot of code redundancy and grossness at very minor expense.
MFC r251837:
MFC r251842:
Add infrastructure for doing compatibility shims, as has been sorely
needed for the last 10 years. Far too much of the internal API is
exposed, and every small adjustment causes applications to stop working.
To kick this off, bump the API version to 0x17 as should have been done
with r246713, but add shims to compensate. Thanks to the shims, there
should be no visible change in application behavior.
Submitted by: kib, jeffr
Approved by: kib
Obtained from: Netflix
MFC 232854,232874,232882,232883,232886 for bus_get_dma_tag()2012-03-16T08:46:58ZScott Longscottl@FreeBSD.org2012-03-16T08:46:58Zurn:sha1:03f15131ec6a584935fd83d33e1a1dc1500c3880Prepare for future integration between CAM and newbus. xpt_bus_register2007-06-17T05:55:54ZScott Longscottl@FreeBSD.org2007-06-17T05:55:54Zurn:sha1:b50569b71dfb110a58aa3e83f629115291802a74
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.
Remove Giant from CAM. Drivers (SIMs) now register a mutex that CAM will2007-04-15T08:49:19ZScott Longscottl@FreeBSD.org2007-04-15T08:49:19Zurn:sha1:2b83592fdcb9e7c201677f3605b9e8738a6b0737
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.
Catchup with filters2007-02-23T19:34:52ZWarner Loshimp@FreeBSD.org2007-02-23T19:34:52Zurn:sha1:21ab16bd5b7077b165e9264b71f964c66f6831f2Add MODULE_DEPENDS for cam, pci, mca, eisa and isa where needed.2006-12-11T18:28:31ZMatt Jacobmjacob@FreeBSD.org2006-12-11T18:28:31Zurn:sha1:b3d93fd0c96f430027eae8ba39f975341cec1648
PR: 106543
MFC after: 3 days
Since DELAY() was moved, most <machine/clock.h> #includes have been2006-05-16T14:37:58ZPoul-Henning Kampphk@FreeBSD.org2006-05-16T14:37:58Zurn:sha1:c40da00ca320a38816049edd21966bd4045b2303
unnecessary.
Start each of the license/copyright comments with /*-, minor shuffle of lines2005-01-06T01:43:34ZWarner Loshimp@FreeBSD.org2005-01-06T01:43:34Zurn:sha1:098ca2bda93c701c5331d4e6aace072495b4caaaUse __FBSDID().2003-08-24T17:55:58ZDavid E. O'Brienobrien@FreeBSD.org2003-08-24T17:55:58Zurn:sha1:aad970f1fee9a2a3e5a0f880be9b87c6193b3bd1
Also some minor style cleanups.
Mega busdma API commit.2003-07-01T15:52:06ZScott Longscottl@FreeBSD.org2003-07-01T15:52:06Zurn:sha1:f6b1c44d1f70d5f298b911f2c1dcd802b0d11339
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