On Thu, Aug 26, 2010 at 06:30:02PM +0900, FUJITA Tomonori wrote:

On Thu, 26 Aug 2010 11:06:20 +0200 (CEST)
Guennadi Liakhovetski [off-list ref] wrote:

quoted

On Thu, 26 Aug 2010, FUJITA Tomonori wrote:

quoted

On Thu, 26 Aug 2010 09:04:14 +0300
Marin Mitov [off-list ref] wrote:

quoted

On Thursday, August 26, 2010 08:40:47 am FUJITA Tomonori wrote:

quoted

On Fri, 20 Aug 2010 14:50:12 +0300
Marin Mitov [off-list ref] wrote:

quoted

On Friday, August 20, 2010 11:35:06 am FUJITA Tomonori wrote:

quoted

On Fri, 20 Aug 2010 11:13:45 +0300
Marin Mitov [off-list ref] wrote:

quoted

quoted

quoted

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, we should avoid using coherent memory as I exaplained before. In
addition, dma_alloc_coherent can't provide large enough contigous
memory for some drivers so this patch doesn't help much.

Please, look at drivers/media/video/videobuf-dma-contig.c. Using coherent memory
is inavoidable for now, there is no alternative for it for now. The two new functions,
which I propose are just helpers for those of us who already use coherent memory
(via videobuf-dma-contig API). May be adding these two functions to 
drivers/media/video/videobuf-dma-contig.c will be better solution?

If you add something to the videobuf-dma-contig API, that's fine by me
because drivers/media/video/videobuf-dma-contig.c uses the own
structure and plays with dma_alloc_coherent. As long as a driver
doesn't touch device->dma_mem directly, it's fine, I think (that is,
dt3155v4l driver is broken). There are already some workarounds for
contigous memory in several drivers anyway.

No, this will not work - this API has to be used from board code and 
videobuf can be built modular.

quoted

We will have the proper API for contiguous memory. I don't think that
adding such workaround to the DMA API is a good idea.

We have currently a number of boards broken in the mainline. They must be 
fixed for 2.6.36. I don't think the mentioned API will do this for us. So, 
as I suggested earlier, we need either this or my patch series

http://thread.gmane.org/gmane.linux.ports.sh.devel/8595

for 2.6.36.

Why can't you revert a commit that causes the regression?

The related DMA API wasn't changed in 2.6.36-rc1. The DMA API is not
responsible for the regression. And the patchset even exnteds the
definition of the DMA API (dma_declare_coherent_memory). Such change
shouldn't applied after rc1. I think that DMA-API.txt says that
dma_declare_coherent_memory() handles coherent memory for a particular
device. It's not for the API that reserves coherent memory that can be
used for any device for a single device.

The patch that made the problem obvious for ARM is
309caa9cc6ff39d261264ec4ff10e29489afc8f8 aka v2.6.36-rc1~591^2~2^4~12.
So this went in before v2.6.36-rc1.  One of the "architectures which
similar restrictions" is x86 BTW.

And no, we won't revert 309caa9cc6ff39d261264ec4ff10e29489afc8f8 as it
addresses a hardware restriction.

Best regards
Uwe

-- 
Pengutronix e.K.                           | Uwe Kleine-K?nig            |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |