Re: [RFC][PATCH] add dma_reserve_coherent_memory()/dma_free_reserved_memory() API
On Wednesday, October 13, 2010 11:04:57 am KAMEZAWA Hiroyuki wrote:
On Sun, 10 Oct 2010 23:08:22 +0900
FUJITA Tomonori fujita.tomon...@lab.ntt.co.jp wrote:
On Fri, 20 Aug 2010 14:50:12 +0300
Marin Mitov mi...@issp.bas.bg wrote:
On Friday, August 20, 2010 11:35:06 am FUJITA Tomonori wrote:
On Fri, 20 Aug 2010 11:13:45 +0300
Marin Mitov mi...@issp.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()
Anyone is working on this?
KAMEZAWA posted a patch to improve the generic page allocator to
allocate physically contiguous memory. He said that he can push it
into mainline.
I said I do make an effort ;)
New one here.
http://lkml.org/lkml/2010/10/12/421
I like the patch. The possibility to allocate a contiguous chunk of memory
(or few of them) is what I need. The next step will be to get a dma handle
(for dma transfers to/from) and then mmap them to user space.
Thanks.
Marin Mitov
Thanks,
-Kame
--
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
Re: [RFC][PATCH] add dma_reserve_coherent_memory()/dma_free_reserved_memory() API
On Sunday, October 10, 2010 05:08:22 pm FUJITA Tomonori wrote:
On Fri, 20 Aug 2010 14:50:12 +0300
Marin Mitov mi...@issp.bas.bg wrote:
On Friday, August 20, 2010 11:35:06 am FUJITA Tomonori wrote:
On Fri, 20 Aug 2010 11:13:45 +0300
Marin Mitov mi...@issp.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()
Anyone is working on this?
I am not, sorry.
KAMEZAWA posted a patch to improve the generic page allocator to
allocate physically contiguous memory. He said that he can push it
into mainline.
I am waiting for the new videobuf2 framework to become part of the kernel.
Then KAMEZAWA's improvements can help.
Marin Mitov
The approach enables us to solve this issue without adding any new
API.
--
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
Re: [RFC][PATCH] add dma_reserve_coherent_memory()/dma_free_reserved_memory() API
On Sunday, October 10, 2010 09:21:50 pm Guennadi Liakhovetski wrote:
On Sun, 10 Oct 2010, Marin Mitov wrote:
On Sunday, October 10, 2010 05:08:22 pm FUJITA Tomonori wrote:
On Fri, 20 Aug 2010 14:50:12 +0300
Marin Mitov mi...@issp.bas.bg wrote:
On Friday, August 20, 2010 11:35:06 am FUJITA Tomonori wrote:
On Fri, 20 Aug 2010 11:13:45 +0300
Marin Mitov mi...@issp.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()
Anyone is working on this?
I am not, sorry.
KAMEZAWA posted a patch to improve the generic page allocator to
allocate physically contiguous memory. He said that he can push it
into mainline.
I am waiting for the new videobuf2 framework to become part of the kernel.
Then KAMEZAWA's improvements can help.
You probably have seen this related thread:
http://marc.info/?t=12864447364r=1w=2
Thanks.
Marin Mitov
Thanks
Guennadi
Marin Mitov
The approach enables us to solve this issue without adding any new
API.
--
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
---
Guennadi Liakhovetski, Ph.D.
Freelance Open-Source Software Developer
http://www.open-technology.de/
--
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
Re: [RFC][PATCH] add dma_reserve_coherent_memory()/dma_free_reserved_memory() API
On Friday, August 27, 2010 09:32:14 am FUJITA Tomonori wrote: On Fri, 27 Aug 2010 09:23:21 +0300 Marin Mitov mi...@issp.bas.bg wrote: On Friday, August 27, 2010 08:57:59 am FUJITA Tomonori wrote: On Fri, 27 Aug 2010 07:19:07 +0200 Uwe Kleine-K$(D+S(Bnig u.kleine-koe...@pengutronix.de wrote: Hey, On Fri, Aug 27, 2010 at 02:00:17PM +0900, FUJITA Tomonori wrote: On Fri, 27 Aug 2010 06:41:42 +0200 Uwe Kleine-K$(D+S(Bnig u.kleine-koe...@pengutronix.de wrote: On Thu, Aug 26, 2010 at 07:00:24PM +0900, FUJITA Tomonori wrote: On Thu, 26 Aug 2010 11:53:11 +0200 Uwe Kleine-K$(D+S(Bnig u.kleine-koe...@pengutronix.de wrote: 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. How these drivers were able to work without hitting the hardware restriction? In my case the machine in question is an ARMv5, the hardware restriction is on ARMv6+ only. You could argue that so the breaking patch for arm should only break ARMv6, but I don't think this is sensible from a maintainers POV. We need an API that works independant of the machine that runs the code. Agreed. But insisting that the DMA API needs to be extended wrongly after rc2 to fix the regression is not sensible too. The related DMA API wasn't changed in 2.6.36-rc1. The API isn't responsible for the regression at all. I think this isn't about responsiblity. Someone in arm-land found that the way dma memory allocation worked for some time doesn't work anymore on new generation chips. As pointing out this problem was expected to find some matches it was merged in the merge window. One such match is the current usage of the DMA API that doesn't currently offer a way to do it right, so it needs a patch, no? No, I don't think so. We are talking about a regression, right? On new generation chips, something often doesn't work (which have worked on old chips for some time). It's not a regresiion. I don't think that it's sensible to make large change (especially after rc1) to fix such issue. If you say that the DMA API doesn't work on new chips and proposes a patch for the next merge window, it's sensible, I suppose. Btw, the patch isn't a fix for the DMA API. It tries to extend the DMA API (and IMO in the wrong way). In addition, the patch might break the current code. To break the current code is simply not possible. Sorry to oppose. As you have written it extend the DMA API, so if you do not use the new API (and no current code is using it) you cannot break the current code. Looks like that the patch adds the new API that touches the exisitng code. It means the existing code could break. So the exsising API could break too. http://thread.gmane.org/gmane.linux.ports.sh.devel/8595 The above reference is not my patch. I am speaking for my patch: http://lkml.org/lkml/2010/8/19/200 The only point my patch touches the existing code is struct device's member dma_mem and that is in condition you __use__ the new API, so you could decide yourself if it could break the current code. As far as one does not use the new API - nothing is touched, nothing can break. If one uses the new API, only the user can suffer if the new API have bugs. 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
Re: [RFC][PATCH] add dma_reserve_coherent_memory()/dma_free_reserved_memory() API
On Saturday, August 28, 2010 10:10:28 am FUJITA Tomonori wrote: On Sat, 28 Aug 2010 09:14:25 +0300 Marin Mitov mi...@issp.bas.bg wrote: On Friday, August 27, 2010 09:32:14 am FUJITA Tomonori wrote: On Fri, 27 Aug 2010 09:23:21 +0300 Marin Mitov mi...@issp.bas.bg wrote: On Friday, August 27, 2010 08:57:59 am FUJITA Tomonori wrote: On Fri, 27 Aug 2010 07:19:07 +0200 Uwe Kleine-K$(D+S(Bnig u.kleine-koe...@pengutronix.de wrote: Hey, On Fri, Aug 27, 2010 at 02:00:17PM +0900, FUJITA Tomonori wrote: On Fri, 27 Aug 2010 06:41:42 +0200 Uwe Kleine-K$(D+S(Bnig u.kleine-koe...@pengutronix.de wrote: On Thu, Aug 26, 2010 at 07:00:24PM +0900, FUJITA Tomonori wrote: On Thu, 26 Aug 2010 11:53:11 +0200 Uwe Kleine-K$(D+S(Bnig u.kleine-koe...@pengutronix.de wrote: 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. How these drivers were able to work without hitting the hardware restriction? In my case the machine in question is an ARMv5, the hardware restriction is on ARMv6+ only. You could argue that so the breaking patch for arm should only break ARMv6, but I don't think this is sensible from a maintainers POV. We need an API that works independant of the machine that runs the code. Agreed. But insisting that the DMA API needs to be extended wrongly after rc2 to fix the regression is not sensible too. The related DMA API wasn't changed in 2.6.36-rc1. The API isn't responsible for the regression at all. I think this isn't about responsiblity. Someone in arm-land found that the way dma memory allocation worked for some time doesn't work anymore on new generation chips. As pointing out this problem was expected to find some matches it was merged in the merge window. One such match is the current usage of the DMA API that doesn't currently offer a way to do it right, so it needs a patch, no? No, I don't think so. We are talking about a regression, right? On new generation chips, something often doesn't work (which have worked on old chips for some time). It's not a regresiion. I don't think that it's sensible to make large change (especially after rc1) to fix such issue. If you say that the DMA API doesn't work on new chips and proposes a patch for the next merge window, it's sensible, I suppose. Btw, the patch isn't a fix for the DMA API. It tries to extend the DMA API (and IMO in the wrong way). In addition, the patch might break the current code. To break the current code is simply not possible. Sorry to oppose. As you have written it extend the DMA API, so if you do not use the new API (and no current code is using it) you cannot break the current code. Looks like that the patch adds the new API that touches the exisitng code. It means the existing code could break. So the exsising API could break too. http://thread.gmane.org/gmane.linux.ports.sh.devel/8595 The above reference is not my patch. I am speaking for my patch: http://lkml.org/lkml/2010/8/19/200 I think that I already NACK'ed the patch. OK. Thanks, Marin Mitov 1) drivers/media/videobuf-dma-contig.c should not use dma_alloc_coherent
Re: [RFC][PATCH] add dma_reserve_coherent_memory()/dma_free_reserved_memory() API
On Friday, August 27, 2010 08:57:59 am FUJITA Tomonori wrote: On Fri, 27 Aug 2010 07:19:07 +0200 Uwe Kleine-K$(D+S(Bnig u.kleine-koe...@pengutronix.de wrote: Hey, On Fri, Aug 27, 2010 at 02:00:17PM +0900, FUJITA Tomonori wrote: On Fri, 27 Aug 2010 06:41:42 +0200 Uwe Kleine-K$(D+S(Bnig u.kleine-koe...@pengutronix.de wrote: On Thu, Aug 26, 2010 at 07:00:24PM +0900, FUJITA Tomonori wrote: On Thu, 26 Aug 2010 11:53:11 +0200 Uwe Kleine-K$(D+S(Bnig u.kleine-koe...@pengutronix.de wrote: 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. How these drivers were able to work without hitting the hardware restriction? In my case the machine in question is an ARMv5, the hardware restriction is on ARMv6+ only. You could argue that so the breaking patch for arm should only break ARMv6, but I don't think this is sensible from a maintainers POV. We need an API that works independant of the machine that runs the code. Agreed. But insisting that the DMA API needs to be extended wrongly after rc2 to fix the regression is not sensible too. The related DMA API wasn't changed in 2.6.36-rc1. The API isn't responsible for the regression at all. I think this isn't about responsiblity. Someone in arm-land found that the way dma memory allocation worked for some time doesn't work anymore on new generation chips. As pointing out this problem was expected to find some matches it was merged in the merge window. One such match is the current usage of the DMA API that doesn't currently offer a way to do it right, so it needs a patch, no? No, I don't think so. We are talking about a regression, right? On new generation chips, something often doesn't work (which have worked on old chips for some time). It's not a regresiion. I don't think that it's sensible to make large change (especially after rc1) to fix such issue. If you say that the DMA API doesn't work on new chips and proposes a patch for the next merge window, it's sensible, I suppose. Btw, the patch isn't a fix for the DMA API. It tries to extend the DMA API (and IMO in the wrong way). In addition, the patch might break the current code. To break the current code is simply not possible. Sorry to oppose. As you have written it extend the DMA API, so if you do not use the new API (and no current code is using it) you cannot break the current code. Thanks, Marin Mitov I really don't think that applying such patch after rc1 is senseble. -- 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
Re: [RFC][PATCH] add dma_reserve_coherent_memory()/dma_free_reserved_memory() API
On Friday, August 27, 2010 09:32:14 am FUJITA Tomonori wrote: On Fri, 27 Aug 2010 09:23:21 +0300 Marin Mitov mi...@issp.bas.bg wrote: On Friday, August 27, 2010 08:57:59 am FUJITA Tomonori wrote: On Fri, 27 Aug 2010 07:19:07 +0200 Uwe Kleine-K$(D+S(Bnig u.kleine-koe...@pengutronix.de wrote: Hey, On Fri, Aug 27, 2010 at 02:00:17PM +0900, FUJITA Tomonori wrote: On Fri, 27 Aug 2010 06:41:42 +0200 Uwe Kleine-K$(D+S(Bnig u.kleine-koe...@pengutronix.de wrote: On Thu, Aug 26, 2010 at 07:00:24PM +0900, FUJITA Tomonori wrote: On Thu, 26 Aug 2010 11:53:11 +0200 Uwe Kleine-K$(D+S(Bnig u.kleine-koe...@pengutronix.de wrote: 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. How these drivers were able to work without hitting the hardware restriction? In my case the machine in question is an ARMv5, the hardware restriction is on ARMv6+ only. You could argue that so the breaking patch for arm should only break ARMv6, but I don't think this is sensible from a maintainers POV. We need an API that works independant of the machine that runs the code. Agreed. But insisting that the DMA API needs to be extended wrongly after rc2 to fix the regression is not sensible too. The related DMA API wasn't changed in 2.6.36-rc1. The API isn't responsible for the regression at all. I think this isn't about responsiblity. Someone in arm-land found that the way dma memory allocation worked for some time doesn't work anymore on new generation chips. As pointing out this problem was expected to find some matches it was merged in the merge window. One such match is the current usage of the DMA API that doesn't currently offer a way to do it right, so it needs a patch, no? No, I don't think so. We are talking about a regression, right? On new generation chips, something often doesn't work (which have worked on old chips for some time). It's not a regresiion. I don't think that it's sensible to make large change (especially after rc1) to fix such issue. If you say that the DMA API doesn't work on new chips and proposes a patch for the next merge window, it's sensible, I suppose. Btw, the patch isn't a fix for the DMA API. It tries to extend the DMA API (and IMO in the wrong way). In addition, the patch might break the current code. To break the current code is simply not possible. Sorry to oppose. As you have written it extend the DMA API, so if you do not use the new API (and no current code is using it) you cannot break the current code. Looks like that the patch adds the new API that touches the exisitng code. It means the existing code could break. So the exsising API could break too. http://thread.gmane.org/gmane.linux.ports.sh.devel/8595 -- 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 -- 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
Re: [RFC][PATCH] add dma_reserve_coherent_memory()/dma_free_reserved_memory() API
On Thursday, August 26, 2010 08:40:47 am FUJITA Tomonori wrote:
On Fri, 20 Aug 2010 14:50:12 +0300
Marin Mitov mi...@issp.bas.bg wrote:
On Friday, August 20, 2010 11:35:06 am FUJITA Tomonori wrote:
On Fri, 20 Aug 2010 11:13:45 +0300
Marin Mitov mi...@issp.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, 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?
Thanks.
Marin Mitov
We need the proper API for contiguous memory. Seem that we could have
something:
http://lkml.org/lkml/2010/8/20/167
--
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
Re: [RFC][PATCH] add dma_reserve_coherent_memory()/dma_free_reserved_memory() API
On Thursday, August 26, 2010 09:24:19 am FUJITA Tomonori wrote:
On Thu, 26 Aug 2010 09:04:14 +0300
Marin Mitov mi...@issp.bas.bg wrote:
On Thursday, August 26, 2010 08:40:47 am FUJITA Tomonori wrote:
On Fri, 20 Aug 2010 14:50:12 +0300
Marin Mitov mi...@issp.bas.bg wrote:
On Friday, August 20, 2010 11:35:06 am FUJITA Tomonori wrote:
On Fri, 20 Aug 2010 11:13:45 +0300
Marin Mitov mi...@issp.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, 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,
Why, my understanding is that device-dma_mem is designed exactly for keeping
some chunk of coherent memory for device's private use via
dma_alloc_from_coherent()
(and that is what dt3155v4l driver is using it for).
I think (that is, dt3155v4l driver is broken).
If you mean that allocating some coherent memory (4MB in case of dt3155v4l)
during
pci probe() (during system booting) for device's latter use (that is dead for
the rest
of the system) you are right. But this gives me at least 8 full size buffers
warranted for
latter use. Without this hack the hardware will not work on strongly fragmented
system.
With this hack even if the system is strongly fragmented, this chunk of 4MB is
available
for use (though videobuf-dma-contig APIs and dma_alloc_from_coherent())
__transparently__
for users of videobuf-dma-contig (that is the gain - the transparency).
There are already some workarounds for
contigous memory in several drivers anyway.
Sure, can these workarounds be exposed as API for general use?
Thanks,
Marin Mitov
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.
--
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
Re: [RFC][PATCH] add dma_reserve_coherent_memory()/dma_free_reserved_memory() API
On Thursday, August 26, 2010 12:43:22 pm FUJITA Tomonori wrote: On Thu, 26 Aug 2010 10:01:52 +0300 Marin Mitov mi...@issp.bas.bg wrote: 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, Why, my understanding is that device-dma_mem is designed exactly for keeping some chunk of coherent memory for device's private use via dma_alloc_from_coherent() (and that is what dt3155v4l driver is using it for). I don't think so. device-dma_mem can be accessed only via the DMA-API. I think that the DMA-API says that dma_declare_coherent_memory declares coherent memory that can be access exclusively by a certain device. Here I agree with you: that can be access exclusively by a certain device It's not for reserving coherent memory that can be used for any device for a device. Here I disagree with you: that can be used for any device for a device. Reserved coherent memory can be only and exclusively used by the __same__ device whose device-dma_mem is touched. No other devices are influenced because their device-dma_mem are NULL. and dma_alloc_from_coherent() is not invoked for them. That is why I think this hack is not dangerous. If some device driver decide to reserve some chunk of memory it is for its private use and no other device in the system is influenced. Anway, you don't need coherent memory. So using the API for coherent memory isn't a good idea. Here I agree with you, but for now we have no alternative in media/video framework. There are already some workarounds for contigous memory in several drivers anyway. Sure, can these workarounds be exposed as API for general use? I don't think that's a good idea. Adding temporary workaround to the generic API and removing it soon after that doesn't sound a good developing maner. Yes, it is just a temporary solution. Just enhancing an existing temporary solution. 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
Re: [RFC][PATCH] add dma_reserve_coherent_memory()/dma_free_reserved_memory() API
On Thursday, August 26, 2010 12:17:25 pm Uwe Kleine-König wrote:
Hello,
On Thu, Aug 26, 2010 at 11:06:20AM +0200, Guennadi Liakhovetski wrote:
On Thu, 26 Aug 2010, FUJITA Tomonori wrote:
On Thu, 26 Aug 2010 09:04:14 +0300
Marin Mitov mi...@issp.bas.bg wrote:
On Thursday, August 26, 2010 08:40:47 am FUJITA Tomonori wrote:
On Fri, 20 Aug 2010 14:50:12 +0300
Marin Mitov mi...@issp.bas.bg wrote:
On Friday, August 20, 2010 11:35:06 am FUJITA Tomonori wrote:
On Fri, 20 Aug 2010 11:13:45 +0300
Marin Mitov mi...@issp.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, 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.
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
this seems to be more mature to me. The original patch in this thread
uses a symbol DT3155_COH_FLAGS which seems misplaced in generic code and
doesn't put the new functions in a header.
You are right. DT3155_COH_FLAGS should be defined, and a declaration should be
put in the headers.
But it is just RFC :-)
Marin Mitov
Best regards
Uwe
--
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
Re: [RFC][PATCH] add dma_reserve_coherent_memory()/dma_free_reserved_memory() API
On Thursday, August 26, 2010 08:49:09 pm Russell King - ARM Linux wrote: On Thu, Aug 26, 2010 at 06:51:48PM +0900, FUJITA Tomonori wrote: On Thu, 26 Aug 2010 11:45:58 +0200 (CEST) Guennadi Liakhovetski g.liakhovet...@gmx.de wrote: On Thu, 26 Aug 2010, FUJITA Tomonori wrote: Why can't you revert a commit that causes the regression? See this reply, and the complete thread too. http://marc.info/?l=linux-shm=128130485208262w=2 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. Anyway, we need a way to fix the regression. Needs to find a different way. No. ioremap on memory mapped by the kernel is just plain not permitted with ARMv6 and ARMv7 architectures. Hi Russell, Just because ioremap on memory mapped by the kernel is just plain not permitted I have proposed a new pair of functions: dma_reserve_coherent_memory()/dma_free_reserved_memory() http://lkml.org/lkml/2010/8/19/200 but it is not quite well accepted from the community. What is your opinion? Thanks, Marin Mitov It's not something you can say oh, need to find another way because there is _no_ software solution to having physical regions mapped multiple times with different attributes. It's an architectural restriction. We can't unmap the kernel's memory mapping either, as I've already explained several times this month - and I'm getting frustrated at having to keep on explaining that point. Just accept the plain fact that multiple mappings of the same physical regions have become illegal. What we need is another alternative other than using ioremap on memory already mapped by the kernel - eg, by reserving a certain chunk of memory for this purpose at boot time which his _never_ mapped by the kernel, except via ioremap. -- 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 -- 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
Re: [RFC][PATCH] add dma_reserve_coherent_memory()/dma_free_reserved_memory() API
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
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 mi...@issp.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-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] [PATCH 1/6] SoC Camera: add driver for OMAP1 camera interface
On Thursday, August 19, 2010 02:39:47 pm Guennadi Liakhovetski wrote: On Thu, 19 Aug 2010, Janusz Krzysztofik wrote: Hi Marin, Since I've finaly managed to make use of your method without any previously observerd limitations (see below), I'm interested in it being implemented system-wide. Are you going to submit a patch? It is ready, I just wait for the invitation. Marin Mitov I'm about to submit a patch, which you'll be most welcome to test. Just give me a couple more hours. I would suggest creating one common function that allocates and fills the dev-dma_mem structure, and two wrappers that call it: a dma_declare_coherent_memory() replacement, that passes an ioremapped device memory address to the common fuction, and your proposed dma_reserve_coherent_memory(), that passes a pointer returned by the dma_alloc_coherent() instead. No, I don't think you should go to the next power of 2 - that's too crude. Try rounding your buffer size to the page size, that should suffice. Allocated coherent memory is always a power of 2. Thanks. Marin Mitov Thanks Guennadi --- Guennadi Liakhovetski, Ph.D. Freelance Open-Source Software Developer http://www.open-technology.de/ -- 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
[RFC][PATCH] add dma_reserve_coherent_memory()/dma_free_reserved_memory() API
Hi all,
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.
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.
Signed-off-by: Marin Mitov mi...@issp.bas.bg
==
--- a/drivers/base/dma-coherent.c 2010-08-19 15:50:42.0 +0300
+++ b/drivers/base/dma-coherent.c 2010-08-19 17:27:56.0 +0300
@@ -93,6 +93,83 @@ void *dma_mark_declared_memory_occupied(
EXPORT_SYMBOL(dma_mark_declared_memory_occupied);
/**
+ * dma_reserve_coherent_memory() - reserve coherent memory for per-device use
+ *
+ * @dev: device from which we allocate memory
+ * @size: size of requested memory area in bytes
+ * @flags: same as in dma_declare_coherent_memory()
+ *
+ * This function reserves coherent memory allocating it early (during probe())
+ * to support latter allocations from per-device coherent memory pools.
+ * For a given device one could use either dma_declare_coherent_memory() or
+ * dma_reserve_coherent_memory(), but not both, becase the result of these
+ * functions is stored in a single struct device member - dma_mem
+ *
+ * Returns DMA_MEMORY_MAP on success, or 0 if failed.
+ * (same as dma_declare_coherent_memory()
+ */
+int dma_reserve_coherent_memory(struct device *dev, size_t size, int flags)
+{
+ struct dma_coherent_mem *mem;
+ dma_addr_t dev_base;
+ int pages = size PAGE_SHIFT;
+ int bitmap_size = BITS_TO_LONGS(pages) * sizeof(long);
+
+ if ((flags DMA_MEMORY_MAP) == 0)
+ goto out;
+ if (!size)
+ goto out;
+ if (dev-dma_mem)
+ goto out;
+
+ mem = kzalloc(sizeof(*mem), GFP_KERNEL);
+ if (!mem)
+ goto out;
+ mem-virt_base = dma_alloc_coherent(dev, size, dev_base,
+ DT3155_COH_FLAGS);
+ if (!mem-virt_base)
+ goto err_alloc_coherent;
+ mem-bitmap = kzalloc(bitmap_size, GFP_KERNEL);
+ if (!mem-bitmap)
+ goto err_bitmap;
+
+ mem-device_base = dev_base;
+ mem-size = pages;
+ mem-flags = flags;
+ dev-dma_mem = mem;
+ return DMA_MEMORY_MAP;
+
+err_bitmap:
+ dma_free_coherent(dev, size, mem-virt_base, dev_base);
+err_alloc_coherent:
+ kfree(mem);
+out:
+ return 0;
+}
+EXPORT_SYMBOL(dma_reserve_coherent_memory);
+
+/**
+ * dma_free_reserved_memory() - free the reserved dma-coherent memoty
+ *
+ * @dev: device for which we free the dma-coherent memory
+ *
+ * same as dma_release_declared_memory()
+ */
+void dma_free_reserved_memory(struct device *dev)
+{
+ struct dma_coherent_mem *mem = dev-dma_mem;
+
+ if (!mem)
+ return;
+ dev-dma_mem = NULL;
+ dma_free_coherent(dev, mem-size PAGE_SHIFT,
+ mem-virt_base, mem-device_base);
+ kfree(mem-bitmap);
+ kfree(mem);
+}
+EXPORT_SYMBOL(dma_free_reserved_memory);
+
+/**
* dma_alloc_from_coherent() - try to allocate memory from the per-device
coherent area
*
* @dev: device from which we allocate memory
--
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
Re: [RFC] [PATCH 1/6] SoC Camera: add driver for OMAP1 camera interface
On Thursday, August 19, 2010 08:09:27 pm Janusz Krzysztofik wrote:
Thursday 19 August 2010 14:16:21 Marin Mitov napisał(a):
On Thursday, August 19, 2010 02:39:47 pm Guennadi Liakhovetski wrote:
No, I don't think you should go to the next power of 2 - that's too
crude. Try rounding your buffer size to the page size, that should
suffice.
Guennadi,
If you have a look at how a device reserved memory is next allocated to a
driver with drivers/base/dma-coherent.c::dma_alloc_from_coherent(), then than
you may find my conclusion on a power of 2 as true:
int dma_alloc_from_coherent(struct device *dev, ssize_t size,
dma_addr_t *dma_handle, void **ret)
{
...
int order = get_order(size);
...
pageno = bitmap_find_free_region(mem-bitmap, mem-size, order);
...
}
Allocated coherent memory is always a power of 2.
Marin,
For ARM, this seems true as long as allocated with the above from a device
assigned pool, but not true for a (pre)allocation from a generic system RAM.
See arch/arm/mm/dma-mapping.c::__dma_alloc_buffer(), where it looks like
extra
pages are freed:
static struct page *__dma_alloc_buffer(struct device *dev, size_t size, gfp_t
gfp)
{
unsigned long order = get_order(size);
...
page = alloc_pages(gfp, order);
...
split_page(page, order);
for (p = page + (size PAGE_SHIFT), e = page + (1 order); p e;
p++)
__free_page(p);
...
}
Thanks for the clarification.
Marin Mitov
Thanks,
Janusz
--
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
Re: [RFC] [PATCH 1/6] SoC Camera: add driver for OMAP1 camera interface
On Saturday, August 14, 2010 08:33:09 pm Guennadi Liakhovetski wrote: On Fri, 13 Aug 2010, Janusz Krzysztofik wrote: Friday 13 August 2010 11:11:52 Marin Mitov napisał(a): On Friday, August 13, 2010 11:52:41 am Guennadi Liakhovetski wrote: On Fri, 13 Aug 2010, Janusz Krzysztofik wrote: Thursday 12 August 2010 23:38:17 Guennadi Liakhovetski napisał(a): 1. We've discussed this dynamic switching a bit on IRC today. The first reaction was - you probably should concentrate on getting the contiguous version to work reliably. I.e., to reserve the memory in the board init code similar, how other contig users currently do it. I already tried before to find out how I could allocate memory at init without reinventing a new videobuf-dma-contig implementation. Since in the Documentation/video4linux/videobuf I've read that videobuf does not currently play well with drivers that play tricks by allocating DMA space at system boot time, I've implemented the alternate sg path. If it's not quite true what the documentation says and you can give me a hint how this could be done, I might try again. For an example look at arch/arm/mach-mx3/mach-pcm037.c::pcm037_camera_alloc_dma(). Yes, this is the solution that suffers from the already discussed limitation of not being able to remap a memory with different attributes, which affects OMAP1 as well. For preallocating dma-coherent memory for device personal use during device probe() time (when the memory is less fragmented compared to open() time) see also dt3155_alloc_coherent/dt3155_free_coherent in drivers/staging/dt3155v4l/dt3155vfl.c (for x86 arch, I do not know if it works for arm arch) With this workaround applied, I get much better results, thank you Marin. However, it seems not bullet proof, since mmap still happens to fail for a reason not quite clear to me: What exactly does this mean - happens to fail - you mean starting and stopping mplayer several times? Can you verify, that you're not leaking memory? That you're freeing all allocated DMA memory again? Are you using the same parameters to mplayer, right? As for the work-around - can you not do this in your board late-initcall function? Not sure whether and how one can get this in the mainline. This is in principle the same, as in the above dma_declare_coherent_memory() example, only open-coded without the ioremap. My believe is that dma_declare_coherent_memory() could be used if your frame grabber has local RAM buffer (like video buffer if the graphic adapters) defined by BAR - that is why you need ioremap(). If this RAM turns out to be coherent you use dma_declare_coherent_memory() and any further invocation of dma_alloc_coherent() will allocate from it (till it is exosted). My use of dt3155_alloc_coherent()/dt3155_free_coherent() is to allocate a block of coherent 4MB memory during driver probe() method and use it latter (via videobuff_dma_contig framework)). Maybe we can add a suitable function to the dma-alloc API... Could be of general use, I am thinking about this. This could be done by just renaming dt3155_alloc_coherent()/dt3155_free_coherent() to something acceptable (dma_reserve_coherent_memory()/dma_release_reserved_memory(), I am open for suggestions) and export them. Should be added to drivers/base/dma-coherent.c. Marin Mitov Thanks Guennadi [ 6067.22] omap1-camera omap1-camera.0: OMAP1 Camera driver attached to camera 0 [ 6067.65] omap1-camera omap1-camera.0: omap1_cam_try_fmt: format 32315659 not found [ 6067.68] omap1-camera omap1-camera.0: omap1_cam_try_fmt: format 32315559 not found [ 6068.48] mplayer: page allocation failure. order:6, mode:0xd0 [ 6068.50] Backtrace: [ 6068.52] [c0028950] (dump_backtrace+0x0/0x110) from [c0028ea8] (dump_stack+0x18/0x1c) [ 6068.56] r6:0006 r5:00d0 r4:c1bcf000 [ 6068.59] [c0028e90] (dump_stack+0x0/0x1c) from [c0074e24] (__alloc_pages_nodemask+0x504/0x560) [ 6068.62] [c0074920] (__alloc_pages_nodemask+0x0/0x560) from [c002ae14] (__dma_alloc+0x108/0x354) [ 6068.66] [c002ad0c] (__dma_alloc+0x0/0x354) from [c002b0ec] (dma_alloc_coherent+0x58/0x64) [ 6068.70] [c002b094] (dma_alloc_coherent+0x0/0x64) from [bf000a44] (__videobuf_mmap_mapper+0x10c/0x374 [videobuf_dma_contig]) [ 6068.74] r7:c16934c0 r6: r5:c171baec r4: [ 6068.77] [bf000938] (__videobuf_mmap_mapper+0x0/0x374 [videobuf_dma_contig]) from [c01f9a78] (videobuf_mmap_mapper+0xc4/0x108) [ 6068.81] [c01f99b4] (videobuf_mmap_mapper+0x0/0x108) from [c01fc1ac] (soc_camera_mmap+0x80/0x140) [ 6068.84] r5:c1a3b4e0 r4: [ 6068.87] [c01fc12c] (soc_camera_mmap+0x0/0x140) from [c01eeba8] (v4l2_mmap+0x4c/0x5c) [ 6068.90] r7:c145c000 r6:00ff r5:c16934c0 r4
Re: [RFC] [PATCH 1/6] SoC Camera: add driver for OMAP1 camera interface
On Friday, August 13, 2010 11:52:41 am Guennadi Liakhovetski wrote: On Fri, 13 Aug 2010, Janusz Krzysztofik wrote: Thursday 12 August 2010 23:38:17 Guennadi Liakhovetski napisał(a): On Sun, 1 Aug 2010, Janusz Krzysztofik wrote: Friday 30 July 2010 20:49:05 Janusz Krzysztofik napisaÅ(a): I think the right way would be if implemented at the videobuf-core level. Then, drivers should be able to initialize both paths, providing queue callbacks for both sets of methods, contig and sg, for videobuf sole use. Ok, here're my thoughts about this: 1. We've discussed this dynamic switching a bit on IRC today. The first reaction was - you probably should concentrate on getting the contiguous version to work reliably. I.e., to reserve the memory in the board init code similar, how other contig users currently do it. I already tried before to find out how I could allocate memory at init without reinventing a new videobuf-dma-contig implementation. Since in the Documentation/video4linux/videobuf I've read that videobuf does not currently play well with drivers that play tricks by allocating DMA space at system boot time, I've implemented the alternate sg path. If it's not quite true what the documentation says and you can give me a hint how this could be done, I might try again. For an example look at arch/arm/mach-mx3/mach-pcm037.c::pcm037_camera_alloc_dma(). For preallocating dma-coherent memory for device personal use during device probe() time (when the memory is less fragmented compared to open() time) see also dt3155_alloc_coherent/dt3155_free_coherent in drivers/staging/dt3155v4l/dt3155vfl.c (for x86 arch, I do not know if it works for arm arch) But given problems with this aproach in the current ARM tree [1], this might be a bit difficult. Still, those problems have to be and will be fixed somehow eventually, so, you might prefer to still just go that route. My board uses two drivers that allocate dma memory at boot time: drivers/video/omap/lcdc.c and sounc/soc/omap/omap-pcm.c. Both use alloc_dma_writecombine() for this and work without problems. dma_alloc_writecombine() also allocates contiguous RAM, right? And it doesn't use device local memory. So, it's chances to fail are the same as those of dma_alloc_coherent() in the absence of device own memory. I guess, the sound driver doesn't need much RAM, but if you build your LCDC driver as a module and load it later after startup, it might get problems allocating RAM for the framebuffer. 2. If you do want to do the switching - we also discussed, how forthcoming changes to the videobuf subsystem will affest this work. I do not think it would be possible to implement this switching in the videobuf core. OK, I should have probably said that it looked not possible for me to do it without any additional support implemented at videobuf-core (or soc_camera) level. Remember, with the videobuf API you first call the respective implementation init method, which doesn't fail. Then, in REQBUFS ioctl you call videobuf_reqbufs(), which might already fail but normally doesn't. The biggest problem is the mmap call with the contig videobuf implementation. This one is likely to fail. So, you would have to catch the failing mmap, call videobuf_mmap_free(), then init the SG videobuf, request buffers and mmap them... That's what I've already discovered, but failed to identify a place in my code where I could intercept this failing mmap without replacing parts of the videobuf code. Right, ATM soc-camera just calls videobuf_mmap_mapper() directly in its mmap method. I could add a callback to struct soc_camera_host_ops like int (*mmap)(struct soc_camera_device *, struct vm_area_struct *) and modify soc_camera_mmap() to check, whether the host driver has implemented it. If so - call it, otherwise call videobuf_mmap_mapper() directly just like now. So, other drivers would not have to be modified. And you could implement that .mmap() method, call videobuf_mmap_mapper() yourself, and if it fails for contig, fall back to SG. With my 2 patches from today, there is only one process (file descriptor, to be precise), that manages the videobuf queue. So, this all can only be implemented in your driver. The only way I'm yet able to invent is replacing the videobuf_queue-int_ops-mmap_mapper() callback with my own wrapper that would intercept a failing videobuf-dma-contig version of mmap_mapper(). This could be done in my soc_camera_host-ops-init_videobuf() after the videobuf-dma-contig.c version of the videobuf_queue-int_ops-mmap_mapper() is installed with the videobuf_queue_dma_contig_init(). Is this method close to what you have on mind? See, if the above idea would suit your needs. Thanks Guennadi --- Guennadi Liakhovetski,
Re: [RFC] [PATCH 1/6] SoC Camera: add driver for OMAP1 camera interface
On Friday, August 13, 2010 10:13:08 pm Janusz Krzysztofik wrote: Friday 13 August 2010 11:11:52 Marin Mitov napisał(a): On Friday, August 13, 2010 11:52:41 am Guennadi Liakhovetski wrote: On Fri, 13 Aug 2010, Janusz Krzysztofik wrote: Thursday 12 August 2010 23:38:17 Guennadi Liakhovetski napisał(a): 1. We've discussed this dynamic switching a bit on IRC today. The first reaction was - you probably should concentrate on getting the contiguous version to work reliably. I.e., to reserve the memory in the board init code similar, how other contig users currently do it. I already tried before to find out how I could allocate memory at init without reinventing a new videobuf-dma-contig implementation. Since in the Documentation/video4linux/videobuf I've read that videobuf does not currently play well with drivers that play tricks by allocating DMA space at system boot time, I've implemented the alternate sg path. If it's not quite true what the documentation says and you can give me a hint how this could be done, I might try again. For an example look at arch/arm/mach-mx3/mach-pcm037.c::pcm037_camera_alloc_dma(). Yes, this is the solution that suffers from the already discussed limitation of not being able to remap a memory with different attributes, which affects OMAP1 as well. For preallocating dma-coherent memory for device personal use during device probe() time (when the memory is less fragmented compared to open() time) see also dt3155_alloc_coherent/dt3155_free_coherent in drivers/staging/dt3155v4l/dt3155vfl.c (for x86 arch, I do not know if it works for arm arch) With this workaround applied, I get much better results, thank you Marin. However, it seems not bullet proof, since mmap still happens to fail for a reason not quite clear to me: This is just a preallocation of coherent memory kept for further private driver use, should not be connected to mmap problem. Maybe I should preallocate a few more pages than will be actually used by the driver? Anyways, I'm not sure if this piece of code could be accepted for inclusion into the mainline tree, perhaps only under drivers/staging. The idea for the piece of code I have proposed to you is taken from the functions dma_declare_coherent_memory()/dma_release_declared_memory() in mainline drivers/base/dma-coherent.c Thanks, Janusz -- 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
