FreeBSD source tree https://cgit-dev.freebsd.org/src-test2/atom?h=release%2F5.2.0_cvs 2004-01-10T05:53:29Z 2004-01-10T05:53:29Z cvs2svn cvs2svn@FreeBSD.org 2004-01-10T05:53:29Z urn:sha1:58c9ff44c8041f394c663cb9640e9b77fe07bb13 'RELENG_5_2_0_RELEASE'. This commit was manufactured to restore the state of the 5.2-RELEASE image. Releases prior to 5.3-RELEASE are omitting the secure/ and crypto/ subdirs. 2003-11-07T23:29:42Z Scott Long scottl@FreeBSD.org 2003-11-07T23:29:42Z urn:sha1:eb3b7bf69f759b71d10ca82f588f2c94d2c3d962 the busdma headers. 2003-09-23T08:22:34Z Yoshihiro Takahashi nyan@FreeBSD.org 2003-09-23T08:22:34Z urn:sha1:33e38a2cc803aff0524deee574cfea00029feaa7 a bus_handle, but currently it does only initializing a bus_handle. 2003-07-27T13:52:10Z Maxime Henrion mux@FreeBSD.org 2003-07-27T13:52:10Z urn:sha1:d5afecd06846870c41e2850d88fa9a34d67382fa memory in bus_dmamem_alloc(). This is possible now that contigmalloc() supports the M_ZERO flag. - Remove the locking of Giant around calls to contigmalloc() since contigmalloc() now grabs Giant itself. 2003-07-01T15:52:06Z Scott Long scottl@FreeBSD.org 2003-07-01T15:52:06Z urn: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 2003-05-30T20:40:33Z Hiten Pandya hmp@FreeBSD.org 2003-05-30T20:40:33Z urn:sha1:b77c32a07e04dcf379bc7720f920c2d83c8939e8 The current name is confusing, because it indicates to the client that a bus_dmamap_sync() operation is not necessary when the flag is specified, which is wrong. The main purpose of this flag is to hint the underlying architecture that DMA memory should be mapped in a coherent way, but the architecture can ignore it. But if the architecture does supports coherent mapping of memory, then it makes bus_dmamap_sync() calls cheap. This flag is the same as the one in NetBSD's Bus DMA. Reviewed by: gibbs, scottl, des (implicitly) Approved by: re@ (jhb) 2003-05-27T04:59:59Z Scott Long scottl@FreeBSD.org 2003-05-27T04:59:59Z urn:sha1:7e71df93390826733b07b547c105326fc6ba2a74 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) 2003-05-26T04:00:52Z Scott Long scottl@FreeBSD.org 2003-05-26T04:00:52Z urn:sha1:c87d464f286deec38dfb140c964ff299b36d7840 No need for it to pollute the 5.x API any further. Approved by: re (bmah) 2003-04-10T23:03:33Z Maxime Henrion mux@FreeBSD.org 2003-04-10T23:03:33Z urn:sha1:141bacb048addb7fc663332ac1fcf7f54fb6a8f1 enum to an int and redefine the BUS_DMASYNC_* constants as flags. This allows us to specify several operations in one call to bus_dmamap_sync() as in NetBSD. 2003-02-26T02:16:06Z Maxime Henrion mux@FreeBSD.org 2003-02-26T02:16:06Z urn:sha1:f6c912dd0c8dd1e4a5466ae1995cf502a0ef10fb It was bogusly set to 64 * 1024 or 128 * 1024 because it was bogusly reused in the BUS_DMAMAP_NSEGS definition.