From owner-freebsd-arch@FreeBSD.ORG Tue Oct 2 23:40:07 2007 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 517C516A417 for ; Tue, 2 Oct 2007 23:40:07 +0000 (UTC) (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 0DBEF13C4A6 for ; Tue, 2 Oct 2007 23:40:06 +0000 (UTC) (envelope-from scottl@samsco.org) Received: from phobos.samsco.home (phobos.samsco.home [192.168.254.11]) (authenticated bits=0) by pooker.samsco.org (8.13.8/8.13.8) with ESMTP id l92NdkdQ006496; Tue, 2 Oct 2007 17:39:47 -0600 (MDT) (envelope-from scottl@samsco.org) Message-ID: <4702D6B9.1080206@samsco.org> Date: Tue, 02 Oct 2007 17:39:37 -0600 From: Scott Long User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en-US; rv:1.8.1.6) Gecko/20070802 SeaMonkey/1.1.4 MIME-Version: 1.0 To: Hans Petter Selasky References: <200709260131.49156.hselasky@c2i.net> <200709262157.02712.hselasky@c2i.net> <46FB03B1.6020100@samsco.org> <200710022102.38495.hselasky@c2i.net> In-Reply-To: <200710022102.38495.hselasky@c2i.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0.2 (pooker.samsco.org [168.103.85.57]); Tue, 02 Oct 2007 17:39:47 -0600 (MDT) X-Spam-Status: No, score=-1.4 required=5.5 tests=ALL_TRUSTED autolearn=failed version=3.1.8 X-Spam-Checker-Version: SpamAssassin 3.1.8 (2007-02-13) on pooker.samsco.org Cc: freebsd-arch@freebsd.org Subject: Re: Request for feedback on common data backstore in the kernel X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Oct 2007 23:40:07 -0000 Hans Petter Selasky wrote: > On Thursday 27 September 2007, Scott Long wrote: >> Hans Petter Selasky wrote: > >>> I'm thinking about putting some wrappers around the "bus_dmamap_load()" >>> function like: >>> >>> void usbd_rx_buf_load(struct usbd_xfer *xfer, void *buf, >>> uint32_t framebuffer_offset, uint32_t framebuffer_index, uint32_t len); >>> >>> void usbd_tx_buf_load(struct usbd_xfer *xfer, void *buf, >>> uint32_t framebuffer_offset, uint32_t framebuffer_index, uint32_t len); >>> >>> But I haven't figured out all the details yet. The "usbd_xxx_load()" >>> functions should automagically figure out what is best to do and it won't >>> be more than a few lines of code. >> Can you describe what these two wrappers are supposed to do? > > Basically these wrappers will setup the DMA address for the USB HC driver. If > they need to copy data they will copy data. Bouncing/copying is built into the busdma API. If there's a reason to duplicate that logic in USB, please let me know. > >> Are you expecting bus_dmamap_load() to operate synchronously? > > Yes. I assume that "bus_dmamap_load()" can sleep and consequently needs a > thread context. Actually, it's the opposite. The API is meant to NOT block, it is meant to run in whatever context you want, and it'll provide it's own context for delayed loads to run in. This is very different than NetBSD, so if you haven't read the man page yet, I'd recommend doing so. Scott