Date: Thu, 02 Mar 2006 15:26:42 -0700 From: Scott Long <scottl@samsco.org> To: Ruslan Ermilov <ru@FreeBSD.org> Cc: cvs-src@FreeBSD.org, gurney_j@resnet.uoregon.edu, src-committers@FreeBSD.org, cvs-all@FreeBSD.org, "M. Warner Losh" <imp@bsdimp.com> Subject: Re: cvs commit: src/share/man/man9 bus_dma.9 Message-ID: <44077122.20807@samsco.org> In-Reply-To: <20060302220129.GA67620@ip.net.ua> References: <20060302071849.GH29183@ip.net.ua> <20060302181629.GS840@funkthat.com> <20060302185507.GM29183@ip.net.ua> <20060302.141520.53336566.imp@bsdimp.com> <20060302220129.GA67620@ip.net.ua>
next in thread | previous in thread | raw e-mail | index | archive | help
I'd like to assert my maintainership over this file since I'm the one that has been cleaning it up and trying to make it match our API. Give me a few days to go over everyone's input. Scott Ruslan Ermilov wrote: > On Thu, Mar 02, 2006 at 02:15:20PM -0700, M. Warner Losh wrote: > >>Here's what I came up with earlier in the week. >> > > Looks mostly good but it doesn't fix the types of DMA ops > as in my patch. > > >>Index: bus_dma.9 >>=================================================================== >>RCS file: /home/ncvs/src/share/man/man9/bus_dma.9,v >>retrieving revision 1.31 >>diff -u -r1.31 bus_dma.9 >>--- bus_dma.9 13 Dec 2005 17:07:52 -0000 1.31 >>+++ bus_dma.9 2 Mar 2006 21:14:40 -0000 >>@@ -265,14 +265,41 @@ >> .It Dv BUS_DMASYNC_PREREAD >> Perform any synchronization required prior to an update of host memory by the >> DMA read operation. > > ^^^^ write > >>+.Pp >>+In other words, the driver is about to command the device to start >>+a DMA operation that transfers data from the > > ^ write > >>+device to the memory described by this map. >>+And pending writes to this part of memory that the CPU might have queued > > ^^^ Any > >>+up will either be discarded or be completed after this operation completes. >> .It Dv BUS_DMASYNC_PREWRITE >> Perform any synchronization required after an update of host memory by the CPU >> and prior to DMA write operations. > > ^^^^^ read > >>+.Pp >>+In other words, the CPU flushes any cached writes to the area of memory >>+described by this map so they are visible when the device does its >>+DMA READ operation on the memory described by the map. > > ^^^^ right > >>+An implementation may also use this to implement bounce buffers and >>+memory barriers. >> .It Dv BUS_DMASYNC_POSTREAD >> Perform any synchronization required after DMA read operations and prior to > > ^^^^ write > >> CPU access to host memory. >>+.Pp >>+In other words, the CPU discards the cached values for the memory range >>+described by the map. >>+Future reads to the memory range described by the map will fetch the values > > ^^ from > >>+from memory. >>+An implementation is free to reload the cache before any driver initiated > > driver-initiated > >>+reads to this memory. > > ^^ from > >>+An implementation may also use this to implement bounce buffers and >>+memory barriers. >> .It Dv BUS_DMASYNC_POSTWRITE >> Perform any synchronization required after DMA write operations. > > ^^^^^ read > >>+.Pp >>+In other words, this is completely useless. >>+The driver writer has noticed that the device has indicated the DMA READ >>+operation has completed. >>+It is theoretically possible that this would cause the device to do something >>+but it is unclear what. >> .El >> .It Vt bus_dma_lock_t >> Client specified lock/mutex manipulation method. > > > > Cheers,
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?44077122.20807>