From owner-freebsd-usb@FreeBSD.ORG Thu Jul 5 23:35:53 2007 Return-Path: X-Original-To: freebsd-usb@freebsd.org Delivered-To: freebsd-usb@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 0AE7C16A47A; Thu, 5 Jul 2007 23:35:53 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from server.baldwin.cx (66-23-211-162.clients.speedfactory.net [66.23.211.162]) by mx1.freebsd.org (Postfix) with ESMTP id 8A26113C4C7; Thu, 5 Jul 2007 23:35:52 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from localhost.corp.yahoo.com (john@localhost [127.0.0.1]) (authenticated bits=0) by server.baldwin.cx (8.13.8/8.13.8) with ESMTP id l65NZm2W028200; Thu, 5 Jul 2007 19:35:48 -0400 (EDT) (envelope-from jhb@freebsd.org) From: John Baldwin To: freebsd-hackers@freebsd.org Date: Thu, 5 Jul 2007 19:35:32 -0400 User-Agent: KMail/1.9.6 References: <200707040901.33019.hselasky@c2i.net> <200707050931.59256.hselasky@c2i.net> <200707051625.17954.jhb@freebsd.org> In-Reply-To: <200707051625.17954.jhb@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200707051935.32880.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0.2 (server.baldwin.cx [127.0.0.1]); Thu, 05 Jul 2007 19:35:48 -0400 (EDT) X-Virus-Scanned: ClamAV 0.88.3/3606/Thu Jul 5 13:50:01 2007 on server.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-4.4 required=4.2 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.1.3 X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on server.baldwin.cx Cc: freebsd-usb@freebsd.org Subject: Re: New USB stack and Zero copy. X-BeenThere: freebsd-usb@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: FreeBSD support for USB List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jul 2007 23:35:53 -0000 On Thursday 05 July 2007 04:25:17 pm John Baldwin wrote: > On Thursday 05 July 2007 03:31:59 am Hans Petter Selasky wrote: > > On Wednesday 04 July 2007 19:35, John-Mark Gurney wrote: > > > Hans Petter Selasky wrote this message on Wed, Jul 04, 2007 at 09:01 > +0200: > > > > Also: How is the easiest way to load memory pages into DMA ? And I want > > > > that the loadig works like this, that when the page must be bounced it > > > > should not allocate a bounce buffer, hence I already have a bounce > > > > buffer. I only need to know which pages I can forward directly to the > USB > > > > hardware, and the rest I will bounce somewhere else. > > > > > > Why do you not want to let bus_dma do the bouncing for you? If it's > > > to save a copy to another buffer, why don't you load the final buffer > > > into bus_dma? > > > > Because if I let bus_dma do the bounching, I cannot do this while holding a > > mutex, hence allocating DMA'able memory on the fly is not so good. > > This is not a hard problem to solve, every other driver using bus_dma solves > it. Just make sure your driver is in a sane state and drop the lock while > you let bus_dmamap_load() map/copy things for you. Bah, backwards (was thinking of the fact that if you get EINPROGRESS you will have to drop the lock and just wait until the callback is called to make further progress on the request). bus_dmamap_load() already _requires_ you to hold your mutex when you call it, so I don't really see what the issue is, unless you are assuming BUS_DMA_NOWAIT behavior and can't properly handle deferred callbacks. You do have to drop the lock around bus_dmamem_alloc(), but not bus_dmamap_load(). -- John Baldwin