Message-Id: <201008201450.12585.mitov@issp.bas.bg>
Date:	Fri, 20 Aug 2010 14:50:12 +0300
From:	Marin Mitov <mitov@...p.bas.bg>
To:	FUJITA Tomonori <fujita.tomonori@....ntt.co.jp>
Cc:	linux-kernel@...r.kernel.org, linux-media@...r.kernel.org
Subject: Re: [RFC][PATCH] add dma_reserve_coherent_memory()/dma_free_reserved_memory() API

On Friday, August 20, 2010 11:35:06 am FUJITA Tomonori wrote:
> On Fri, 20 Aug 2010 11:13:45 +0300
> Marin Mitov <mitov@...p.bas.bg> wrote:
> 
> > > > 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.
> 
> Hmm, you don't care about coherency? You just need contiguous memory?

Yes. We just need contiguous memory. Coherency is important as far as when dma
transfer finishes user land is able to see the new data. Could be done by something like
dma_{,un}map_single()

> 
> Then, I prefer to invent the API to allocate contiguous
> memory. Coherent memory is precious on some arches.

Sure, but in any case videobuf-dma-contig framework in drivers/media/video
is already built around dma-coherent (nevertheless it is precious), so the two new
functions are just a helpful extension to the existing use of dma-coherent memory.

In any case, as far as these two functions will be mainly used by media/video folks
they could be added not to the drivers/base/dma-coherent.c (where I see their place),
but to drivers/media/video/videobuf-dma-contig.c. In that case the disadvantage will be
that if someone out of the media tree will need this functionality he(she) will need to
compile media/videobuf-dma-contig.c
> 
> 
> > > 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().
> 
> I think that dma_pool API is for small coherent memory (smaller than
> PAGE_SIZE) 

Yes.

> so it might not work for you. However, the purpose of
> dma_pool API is exactly for what you want to do, creating a pool for
> coherent memory per device for drivers.
> 
> I don't see any reason why we can't extend the dma_pool API for your
> case. And it looks better to me rather than inventing the new API.

That will help. I will be happy if someone can do it. I am inpaciently waiting for 
alloc_huhepages()/free_hugepages() API - (transparent hugepages patches, may be)
That also could be a solution for media/video folks with hardware that cannot do 
scatter/gatter. Another solution will be an IOMMU that could present a scattered
user land buffer as contiguous dma address range (I have played in the past with 
AGP-GART without great success).

Thanks.

Marin Mitov

 
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists