Date: Fri, 6 Jul 2007 08:59:39 +0200 From: Hans Petter Selasky <hselasky@c2i.net> To: John Baldwin <jhb@freebsd.org> Cc: freebsd-hackers@freebsd.org, freebsd-usb@freebsd.org Subject: Re: New USB stack and Zero copy. Message-ID: <200707060859.39816.hselasky@c2i.net> In-Reply-To: <200707051935.32880.jhb@freebsd.org> References: <200707040901.33019.hselasky@c2i.net> <200707051625.17954.jhb@freebsd.org> <200707051935.32880.jhb@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Friday 06 July 2007 01:35, John Baldwin wrote: > 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(). The thing is that allocating memory on the fly will be slow, and especially when the xxxx_load() functions will allocate contiguous memory. This only works fine when you load mbufs and things with size less than PAGE_SIZE bytes ?? --HPS
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200707060859.39816.hselasky>