On Friday, August 20, 2010 10:17:48 am FUJITA Tomonori wrote: > On Thu, 19 Aug 2010 18:18:35 +0300 > Marin Mitov <mi...@issp.bas.bg> wrote: > > > struct device contains a member: struct dma_coherent_mem *dma_mem; > > to hold information for a piece of memory declared dma-coherent. > > Alternatively the same member could also be used to hold preallocated > > dma-coherent memory for latter per-device use. > > I think that drivers/base/dma-coherent.c is for architectures to > implement dma_alloc_coherent(). So using it for drivers doesn't look > correct.
It depends. Imagine your frame grabber has built-in RAM buffer on board just as the frame buffer RAM on graphics cards, defined in BAR. You can use dma_declare_coherent_memory()/dma_release_declared_memory() in your driver and then use dma_alloc_coherent()/dma_free_coherent() to allocate dma buffers from it and falling back transparently to system RAM when this local resource is exhausted. > > > > This tric is already used in drivers/staging/dt3155v4l.c > > dt3155_alloc_coherent()/dt3155_free_coherent() > > > > Here proposed for general use by popular demand from video4linux folks. > > Helps for videobuf-dma-contig framework. > > What you guys exactly want to do? If you just want to pre-allocate > coherent memory for latter usage, Yes, just to preallocate not coherent, but rather contiguous memory for latter usage. We use coherent memory because it turns out to be contiguous. > why dma_pool API (mm/dmapool.c) doesn't work? I do not know why dma_pool API doesn't work for frame grabber buffers. May be they are too big ~400KB. I have tried dma_pool APIs without success some time ago, so I had to find some other way to solve my problem leading to the proposed dma_reserve_coherent_memory()/dma_free_reserved_memory(). Thanks. Marin Mitov -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
