Date: Sat, 28 Jun 2003 10:31:43 -0600 From: Scott Long <scottl@freebsd.org> To: John Baldwin <jhb@freebsd.org> Cc: freebsd-arch@freebsd.org Subject: Re: API change for bus_dma Message-ID: <3EFDC2EF.1060807@freebsd.org> In-Reply-To: <XFMail.20030627112702.jhb@FreeBSD.org> References: <XFMail.20030627112702.jhb@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
John Baldwin wrote: > Using this approach is more flexible in case there is a driver > that uses a sx lock or a (not yet implemented) reader-writer lock > or a critical section, or whatever. This just means that the > callback uses a wrapper function but that really isn't that hard to > do and there are other cases (callouts in general) that need this. > To me this seems to be adding a special case to the API that won't > work for all situations anyways. I also don't see wrapper functions > as being all that hard. > Ok, after many semi-private discussions, how about this: 1) New flag, BUS_DMA_INSWI, to signal that the caller is busdma_swi(). 2) Remove callback_mtx and replace it with callback2, a function pointer that wraps the callback with driver-dependent locking. This makes thing more flexible for alternate locking strategies. 3) Move vm_swi to be INTR_MPSAFE. On every single arch, vm_swi only exists to call busdma_swi(). This should not preclude other tasks from being added to this SWI as long as appropriate locking is done. 4) Have busdma_swi() check that callback2==NULL. If it does, grab Giant before calling bus_dmamap_load(). If it doesn't, call bus_dmamap_load() with callback2 instead of the original callback. 5) bus_dmamap_load() checks BUS_DMA_INSWI==0 before overwriting the callback and callback_args fields of the map. It will blindly call 'callback' and rely on the caller (either the driver or busdma_swi) giving it the right pointer. Scott
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3EFDC2EF.1060807>