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: > > I want to get rid of the copying between DMA'able memory and non-DMA'able > > memory. > > > > Currently I allocate N memory-pages for each USB transfer like separate > > pages. > > How do you allocate these pages? With malloc(9) or w/ bus_dmamem_alloc(9)?
bus_dmamem_alloc(). > > > The bus-dma system then assigns all of these pages each their virtual > > address. > > > > What I see is that when I allocate more than PAGE_SIZE bytes using > > bus-dma, I get physically contiguous memory. I don't need that for the > > USB stack. > > That is a limitation of how bus_dma currently allocates memory... It > calls contigmalloc, which doesn't handle multi-segment memory allocations > yet.. > > > The question is: > > > > Should we change bus-dma to support so called scatter and gather > > allocations, where the physical allocation is non-contiguous, and the > > virtual allocation is contiguous accross all the scattered pages ? > > You can already support this by using malloc, and loading that buffer > into your bus_dma map... or using the passing in userland buffer, and > loading that into the map... > > > 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. --HPS _______________________________________________ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
