New USB stack and Zero copy.

[John Baldwin]

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