From owner-freebsd-hackers@FreeBSD.ORG Wed Oct 26 06:13:35 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 CA2A916A41F for ; Wed, 26 Oct 2005 06:13:35 +0000 (GMT) (envelope-from dinesh@alphaque.com) Received: from ns2.alphaque.com (ns2.alphaque.com [202.75.47.153]) by mx1.FreeBSD.org (Postfix) with SMTP id 83B3143D46 for ; Wed, 26 Oct 2005 06:13:32 +0000 (GMT) (envelope-from dinesh@alphaque.com) Received: (qmail 72013 invoked by uid 0); 26 Oct 2005 06:13:27 -0000 Received: from lucifer.net-gw.com (HELO prophet.alphaque.com) (202.75.47.153) by lucifer.net-gw.com with SMTP; 26 Oct 2005 06:13:27 -0000 Received: from [127.0.0.1] (localhost [127.0.0.1]) by prophet.alphaque.com (8.13.4/8.13.4) with ESMTP id j9Q6DCWA007073; Wed, 26 Oct 2005 14:13:12 +0800 (MYT) (envelope-from dinesh@alphaque.com) Message-ID: <435F1E77.30007@alphaque.com> Date: Wed, 26 Oct 2005 14:13:11 +0800 From: Dinesh Nair User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.8b) Gecko/20050915 MIME-Version: 1.0 To: John Baldwin References: <435E3003.4050609@alphaque.com> <200510251327.59965.jhb@freebsd.org> <435E7D8C.90401@alphaque.com> <200510251610.53127.jhb@freebsd.org> In-Reply-To: <200510251610.53127.jhb@freebsd.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@freebsd.org Subject: Re: correct 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 06:13:36 -0000 On 10/26/05 04:10 John Baldwin said the following: > Yes, and on some archs the sync() operations do have memory barriers in place, > but there isn't any bounce buffering with bus_dmamem_alloc() memory. and in _bus_dmamap_load() in /usr/src/sys/i386/i386/busdma_machdep.c, apparently if the second argument to bus_dmamap_load (the pointer to bus_dmamap_t)) is NULL, the syscall code sets it to &nobounce_dmamap, a static struct which doesnt seem to be used/allocated, except within the syscall. what would the implications of using NULL for the dmamap address be ? > Well, you need it to get the physical address to pass to your device for it to > do DMA against. on freebsd 4.x, vtophys(buffer) returns the same value as the this address. (i.e, when the callback function from bus_dmamap_load() is called, the address of the segment returned is the same as vtophys(buffer)). this is the current observed behaviour on 4.x. >>have things changed between freebsd 4.x (which i'm using) and freebsd 5.x ? > I don't think so as far as the interface. the values of the BUS_DMASYNC_XXXX constants have changed though. they're an enum with values 0-3 in 4.x but in 5.x they're defined as 0x01, 0x02, 0x04 and 0x08. due to this, combining BUS_DMASYNC_XXX thru an OR could possibly give different behaviour on 4.x and 5.x. an example would be using (BUS_DMASYNC_POSTREAD|BUS_DMASYNC_PREWRITE) which would be 0x03 in freebsd 4.x and 0x06 in freebsd 5.x. the gotcha is that 0x03 in freebsd 4.x is BUS_DMASYNC_POSTWRITE. so therefore, BUS_DMASYNC_POSTREAD|BUS_DMASYNC_PREWRITE will be BUS_DMASYNC_POSTWRITE in 4.x which in the syscall is actually a no op. also, in both 4.x and 5.x, only POSTREAD and PREWRITE have any real meaning, as PREREAD and POSTWRITE are no ops. it's due to these that the importance of correctly using the correct PRE/POST READ/WRITE and in the correct places seem important and the source of my confusion. :) >>>thus when you send data to your device, that is a WRITE operation (even >>>though your device is doing a DMA to read data), and when you get data >>>back from your device, that is a READ operation (even though your device >>>is doing a DMA to write the data into the buffer). taking ruslan's suggestion, i looked up the HEAD manpage at http://www.freebsd.org/cgi/man.cgi?query=bus_dmamap_sync&apropos=0&sektion=0&manpath=FreeBSD+6.0-current&format=html i've quoted the relevant descriptions below: BUS_DMASYNC_PREWRITE Perform any synchronization required after an update of memory by the CPU but prior to DMA write operations. BUS_DMASYNC_POSTREAD Perform any synchronization required after DMA read operations, but prior to CPU access of the memory. which would indicate that we'd need to use POSTREAD /before/ reading the buffer and PREWRITE /after/ the CPU writes to the buffer, for the following pseudo code: /*cpu reads from device */ bus_dmamap_sync(..., BUS_DMASYNC_POSTREAD) memcpy(myreceivebuf, mappedreceivebuf) /* do some computation on data read from device */ /* cpu writes to device */ memcpy(mappedtransmitbuf, mytransmitbuf) bus_dmamap_sync(..., BUS_DMASYNC_PREWRITE) where mappedreceivebuf and mappedtransmitbuf is the bufferspace allocated in bus_dmamem_alloc() and myreceivebuf/mytransmitbuf is a temporary holding area before writing to the device. is this reasoning correct ? -- Regards, /\_/\ "All dogs go to heaven." dinesh@alphaque.com (0 0) http://www.alphaque.com/ +==========================----oOO--(_)--OOo----==========================+ | for a in past present future; do | | for b in clients employers associates relatives neighbours pets; do | | echo "The opinions here in no way reflect the opinions of my $a $b." | | done; done | +=========================================================================+