From owner-freebsd-hackers@FreeBSD.ORG Wed Oct 26 15:54:26 2005 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9518016A421; Wed, 26 Oct 2005 15:54:26 +0000 (GMT) (envelope-from scottl@samsco.org) Received: from pooker.samsco.org (pooker.samsco.org [168.103.85.57]) by mx1.FreeBSD.org (Postfix) with ESMTP id CBC3B43D48; Wed, 26 Oct 2005 15:54:22 +0000 (GMT) (envelope-from scottl@samsco.org) Received: from [192.168.254.14] (imini.samsco.home [192.168.254.14]) (authenticated bits=0) by pooker.samsco.org (8.13.4/8.13.4) with ESMTP id j9QFsHOD023912; Wed, 26 Oct 2005 09:54:17 -0600 (MDT) (envelope-from scottl@samsco.org) Message-ID: <435FA6A9.4000600@samsco.org> Date: Wed, 26 Oct 2005 09:54:17 -0600 From: Scott Long User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.7.7) Gecko/20050416 X-Accept-Language: en-us, en MIME-Version: 1.0 To: John Baldwin References: <435EEC56.9080708@samsco.org> <435F428E.50609@alphaque.com> <200510261130.45506.jhb@freebsd.org> In-Reply-To: <200510261130.45506.jhb@freebsd.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-1.4 required=3.8 tests=ALL_TRUSTED autolearn=failed version=3.1.0 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on pooker.samsco.org Cc: freebsd-hackers@freebsd.org Subject: Re: [Fwd: Re: use of bus_dmamap_sync] X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Oct 2005 15:54:26 -0000 John Baldwin wrote: > On Wednesday 26 October 2005 04:47 am, Dinesh Nair wrote: > >>On 10/26/05 10:39 Scott Long said the following: >> >>>Apparently the original poster sent his question to me in private, then >>>sent it again to the mailing list right as I was responding in private. >> >>apologies on that, scott. an initial search only turned up your message in >>the archives, but spreading it wider (not confining the google to >>lists.freebsd.org) brought up more hits, and that made me post it into >>-hackers. >> >>do bear with me as i try to understand this. >> >> >>>Below is my response. Note that I edited it slightly to fix an error >>>that I found >>> >>> bus_dmamap_sync(tag, map, BUS_DMASYNC_PREREAD); >>> Ask hardware for data >>> bus_dmamap_sync(tag, map, BUS_DMASYNC_POSTREAD); >>> >>> >>>> read from readbuf (i'm assuming that device has put data in >>>> readbuf) >>>> POSITION B >>>>} >> >>in other words, the PREREAD/POSTREAD wrap around the device's access to >>memory, and not the CPU's ? > > > Yes, scott's notes are more correct than mine here. > > >>> bus_dmamap_sync(tag, map, BUS_DMASYNC_PREWRITE); >>> notify hardware of the write >>> bus_dmamap_sync(tag, map, BUS_DMASYNC_POSTWRITE); >>> >>>The point of the syncs is to do the proper memory barrier and cache >>>coherency magic between the CPU and the bus as well as do the memory >>>copies for bounce buffers. If you are dealing with statically mapped >>>buffers, i.e. for an rx/tx descriptor ring, then you'll want code >> >>however, reading thru the syscall code, bus_dmamem_alloc() sets the dmamap >>to NULL, and if it's null, bus_dmamap_sync() is not called at all. would >>this mean that if memory is allocated by bus_dmamem_alloc(), it does not >>need to be synced with bus_dmamap_sync() ? > The value of the map is an implementation detail, which is why it's an opaque typedef. Portable code should always assume that the map has valid data. Now, specifically for i386, if you have a device with a 4GB address limit, and it has no data alignment constraints (unlike twe), and you are not using PAE, then yes the map will be NULL and the syncs will do nothing. Assuming that all three of these cases are false is not good, though. > > Perhaps on i386. Each arch implements sync(). Argh, it does look like the > memory barriers needed on e.g., Alpha aren't used with static buffers because > of the map != NULL check in sys/busdma.h. *sigh* I guess archs that need > membars even without bounce buffers need to always allocate and setup a > bus_dmamap. None of that matters for i386 though. > Feel free to fix alpha. Again, long ago, I thought that alpha pretended to be coherent in the 2GB DMA window that we use so that it could be more like i386. If that's not true then that's fine. If you need to make structural changes to the MI code on order to fix alpha, please let me know. Scott