Re: [RFC][PATCH] add dma_reserve_coherent_memory()/dma_free_reserved_memory() API
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. 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: HG has errors on kernel 2.6.32
Hi Jan, On Thu, Aug 26, 2010 at 4:54 PM, Jan Hoogenraad jan-conceptro...@hoogenraad.net wrote: Douglas: I see on that http://www.xs4all.nl/~hverkuil/logs/Thursday.log that building linux-2.6.32 yields ERRORS skip_spaces has only been included in string.h starting from linux-2.6.33. Should I have a look on how to fix this, or do you want to do this ? It's up to you. I can fix it, easily. -- second request: can we do some small changes to avoid the compiler warnings ? I will check on the git tree which patch touch on this and commit it. As backport tree, I cannot commit anything besides on existing source of git tree. Thanks Douglas -- 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
Hello, On Fri, Aug 27, 2010 at 02:57:59PM +0900, FUJITA Tomonori wrote: On Fri, 27 Aug 2010 07:19:07 +0200 Uwe Kleine-König 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önig 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önig 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. I really don't think that applying such patch after rc1 is senseble. So you suggest to revert 309caa9cc6ff39d261264ec4ff10e29489afc8f8 or at least restrict it to ARMv6+ and fix the problem during the next merge window? Russell? Best regards Uwe -- Pengutronix e.K. | Uwe Kleine-König| Industrial Linux Solutions | http://www.pengutronix.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: HG has errors on kernel 2.6.32
Douglas: Thanks in advance Douglas Schilling Landgraf wrote: Hi Jan, On Thu, Aug 26, 2010 at 4:54 PM, Jan Hoogenraad jan-conceptro...@hoogenraad.net wrote: Douglas: I see on that http://www.xs4all.nl/~hverkuil/logs/Thursday.log that building linux-2.6.32 yields ERRORS skip_spaces has only been included in string.h starting from linux-2.6.33. Should I have a look on how to fix this, or do you want to do this ? It's up to you. I can fix it, easily. Please: I would have to learn from scratch about the code -- second request: can we do some small changes to avoid the compiler warnings ? I will check on the git tree which patch touch on this and commit it. As backport tree, I cannot commit anything besides on existing source of git tree. Please: I have not installed the git tree. Thanks Douglas -- Jan Hoogenraad Hoogenraad Interface Services Postbus 2717 3500 GS Utrecht -- 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 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 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
Re: [RFC][PATCH] add dma_reserve_coherent_memory()/dma_free_reserved_memory() API
Hello, On Fri, Aug 27, 2010 at 03:32:14PM +0900, 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 I'm still trying to find out what you actually suggest we should do now. Maybe this is a request for a minimal fix without the cleanups Guennadi did? That is only patches 2(?), 4 and 5 of the series? Best regards Uwe -- Pengutronix e.K. | Uwe Kleine-König| Industrial Linux Solutions | http://www.pengutronix.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 -- 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: [PATCH/RFCv4 0/6] The Contiguous Memory Allocator framework
On Thu, 26 Aug 2010 18:36:24 +0900
Minchan Kim minchan@gmail.com wrote:
On Thu, Aug 26, 2010 at 1:30 PM, KAMEZAWA Hiroyuki
kamezawa.hir...@jp.fujitsu.com wrote:
On Thu, 26 Aug 2010 13:06:28 +0900
Minchan Kim minchan@gmail.com wrote:
On Thu, Aug 26, 2010 at 12:44 PM, KAMEZAWA Hiroyuki
kamezawa.hir...@jp.fujitsu.com wrote:
On Thu, 26 Aug 2010 11:50:17 +0900
KAMEZAWA Hiroyuki kamezawa.hir...@jp.fujitsu.com wrote:
128MB...too big ? But it's depend on config.
IBM's ppc guys used 16MB section, and recently, a new interface to
shrink
the number of /sys files are added, maybe usable.
Something good with this approach will be you can create cma memory
before installing driver.
But yes, complicated and need some works.
Ah, I need to clarify what I want to say.
With compaction, it's helpful, but you can't get contiguous memory larger
than MAX_ORDER, I think. To get memory larger than MAX_ORDER on demand,
memory hot-plug code has almost all necessary things.
True. Doesn't patch's idea of Christoph helps this ?
http://lwn.net/Articles/200699/
yes, I think so. But, IIRC, it's own purpose of Chirstoph's work is
for removing zones. please be careful what's really necessary.
Ahh. Sorry for missing point.
You're right. The patch can't help our problem.
How about changing following this?
The thing is MAX_ORDER is static. But we want to avoid too big
MAX_ORDER of whole zones to support devices which requires big
allocation chunk.
So let's add MAX_ORDER into each zone and then, each zone can have
different max order.
For example, while DMA[32], NORMAL, HIGHMEM can have normal size 11,
MOVABLE zone could have a 15.
This approach has a big side effect?
Hm...need to check hard coded MAX_ORDER usages...I don't think
side-effect is big. Hmm. But I think enlarging MAX_ORDER isn't an
important thing. A code which strips contiguous chunks of pages from
buddy allocator is a necessaty thing, as..
What I can think of at 1st is...
==
int steal_pages(unsigned long start_pfn, unsigned long end_pfn)
{
/* Be careful mutal execution with memory hotplug, because
reusing code */
split [start_pfn, end_pfn) to pageblock_order
for each pageblock in the range {
Mark this block as MIGRATE_ISOLATE
try-to-free pages in the range or
migrate pages in the range to somewhere.
/* Here all pages in the range are on buddy allocator
and free and never be allocated by anyone else. */
}
please see __rmqueue_fallback(). it selects migration-type at
1st.
Then, if you can pass start_migratetype of MIGLATE_ISOLATE,
you can automatically strip all MIGRATE_ISOLATE pages from
free_area[].
return chunk of pages.
}
==
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: [PATCH/RFCv4 0/6] The Contiguous Memory Allocator framework
On Fri, 2010-08-27 at 17:16 +0900, KAMEZAWA Hiroyuki wrote: How about changing following this? The thing is MAX_ORDER is static. But we want to avoid too big MAX_ORDER of whole zones to support devices which requires big allocation chunk. So let's add MAX_ORDER into each zone and then, each zone can have different max order. For example, while DMA[32], NORMAL, HIGHMEM can have normal size 11, MOVABLE zone could have a 15. This approach has a big side effect? The side effect of increasing MAX_ORDER is that page allocations get more expensive since the buddy tree gets larger, yielding more splits/merges. Hm...need to check hard coded MAX_ORDER usages...I don't think side-effect is big. Hmm. But I think enlarging MAX_ORDER isn't an important thing. A code which strips contiguous chunks of pages from buddy allocator is a necessaty thing, as.. Right, once we can explicitly free the pages we want, crossing MAX_ORDER isn't too hard like you say, we can simply continue with freeing the next in order page. -- 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: [PATCH 4/4] mx2_camera: implement forced termination of active buffer for mx25
Hi Baruch
On Tue, 27 Jul 2010, Baruch Siach wrote:
This allows userspace to terminate a capture without waiting for the current
frame to complete.
This is an improvement, not a fix, right? Without this patch the
termination just have to wait a couple of ms longer? so, it is ok to
schedule it for 2.6.37?
Thanks
Guennadi
Signed-off-by: Baruch Siach bar...@tkos.co.il
---
drivers/media/video/mx2_camera.c | 20
1 files changed, 16 insertions(+), 4 deletions(-)
diff --git a/drivers/media/video/mx2_camera.c
b/drivers/media/video/mx2_camera.c
index d327d11..396542b 100644
--- a/drivers/media/video/mx2_camera.c
+++ b/drivers/media/video/mx2_camera.c
@@ -648,15 +648,27 @@ static void mx2_videobuf_release(struct videobuf_queue
*vq,
* Terminate only queued but inactive buffers. Active buffers are
* released when they become inactive after videobuf_waiton().
*
- * FIXME: implement forced termination of active buffers, so that the
- * user won't get stuck in an uninterruptible state. This requires a
- * specific handling for each of the three DMA types that this driver
- * supports.
+ * FIXME: implement forced termination of active buffers for mx27 and
+ * mx27 eMMA, so that the user won't get stuck in an uninterruptible
+ * state. This requires a specific handling for each of the these DMA
+ * types.
*/
spin_lock_irqsave(pcdev-lock, flags);
if (vb-state == VIDEOBUF_QUEUED) {
list_del(vb-queue);
vb-state = VIDEOBUF_ERROR;
+ } else if (cpu_is_mx25() vb-state == VIDEOBUF_ACTIVE) {
+ if (pcdev-fb1_active == buf) {
+ pcdev-csicr1 = ~CSICR1_FB1_DMA_INTEN;
+ writel(0, pcdev-base_csi + CSIDMASA_FB1);
+ pcdev-fb1_active = NULL;
+ } else if (pcdev-fb2_active == buf) {
+ pcdev-csicr1 = ~CSICR1_FB2_DMA_INTEN;
+ writel(0, pcdev-base_csi + CSIDMASA_FB2);
+ pcdev-fb2_active = NULL;
+ }
+ writel(pcdev-csicr1, pcdev-base_csi + CSICR1);
+ vb-state = VIDEOBUF_ERROR;
}
spin_unlock_irqrestore(pcdev-lock, flags);
--
1.7.1
--
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: [PATCH 5/5] mx2_camera: add informative camera clock frequency printout
On Thu, 5 Aug 2010, Michael Grzeschik wrote: On Thu, Aug 05, 2010 at 10:30:39PM +0200, Guennadi Liakhovetski wrote: On Tue, 3 Aug 2010, Michael Grzeschik wrote: ported mx27_camera to 2.6.33.2 Sorry, do not understand what this description has to do with the contents The Description is of topic from a previous patchseries from Teresa Gamez and has nothin to do with the content, right! - adding a printk to a driver? I don't think this is something critical enough to be handled urgently now for 2.6.36, right? Yes you are right, this one isn't urgent. Michael Thanks Guennadi Signed-off-by: Teresa Gamez t.ga...@phytec.de Signed-off-by: Michael Grzeschik m.grzesc...@pengutronix.de --- drivers/media/video/mx2_camera.c |3 +++ 1 files changed, 3 insertions(+), 0 deletions(-) diff --git a/drivers/media/video/mx2_camera.c b/drivers/media/video/mx2_camera.c index 7f27492..fb1b1cb 100644 --- a/drivers/media/video/mx2_camera.c +++ b/drivers/media/video/mx2_camera.c @@ -1360,6 +1360,9 @@ static int __devinit mx2_camera_probe(struct platform_device *pdev) goto exit_dma_free; } + dev_info(pdev-dev, Camera clock frequency: %ld\n, + clk_get_rate(pcdev-clk_csi)); + INIT_LIST_HEAD(pcdev-capture); INIT_LIST_HEAD(pcdev-active_bufs); spin_lock_init(pcdev-lock); Well, in mx2_camera_remove() we have a message dev_info(pdev-dev, MX2 Camera driver unloaded\n); and currently no counterpart in probe. I don't think this unloaded message is particularly valuable, but we've already got it. So, we can either remove it or add one more in probe. If you prefer the latter - fine, but (1) I'd put it later - just before return 0; where we already know probe will not fail, and (2) make it even more informative like MX2 Camera (CSI) driver probed, clock frequency %ld\n if you really _do_ think the user is interested to know that;) Otherwise, make this and the unloaded dev_dbg(). 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
Re: [PATCH 0/3] Proposed ir-core (rc-core) changes
On Thu, August 26, 2010 21:14, Jarod Wilson wrote: On Wed, Aug 25, 2010 at 01:01:57AM +0200, David Härdeman wrote: The following series merges the different files that currently make up the ir-core module into a single-file rc-core module. In addition, the ir_input_dev and ir_dev_props structs are replaced by a single rc_dev struct with an API similar to that of the input subsystem. This allows the removal of all knowledge of any input devices from the rc drivers and paves the way for allowing multiple input devices per rc device in the future. The namespace conversion from ir_* to rc_* should mostly be done for the drivers with this patchset. I have intentionally not signed off on the patches yet since they haven't been tested. I'd like your feedback on the general approach before I spend the time to properly test the result. Also, the imon driver is not converted (and will thus break with this patchset). The reason is that the imon driver wants to generate mouse events on the input dev under the control of rc-core. I was hoping that Jarod would be willing to convert the imon driver to create a separate input device for sending mouse events to userspace :) Yeah, I could be persuaded to do that. Means that the imon driver, when driving one of the touchscreen devices, will bring up 3 separate input devices, but oh well. (I'd actually considered doing that when porting to ir-core in the first place, but went the lazy route. ;) That would be good. I'm pretty certain that the split will be necessary sooner or later. Comments please... Haven't tried it out at all yet or done more than a quick skim through the patches, but at first glance, I do like the idea of further abstracting away the input layer. I know I tanked a few things the first go 'round, thinking I needed to do both some rc-layer and input-layer setup and/or teardown. It becomes more cut and dry if you don't see anything input-related anywhere at all. Not to mention we will have a more consistent user experience. For example: some of the current hardware drivers are fiddling with the repeat values of the input dev...something which should be the same across the entire subsystem (you wouldn't expect the repetition rate for the exact same remote control to change just because you change the receiver). Also, it's necessary for any future support of multiple input devices (one per physical remote control being one example)...and it gives us more flexibility to make changes in rc-core when drivers do not muck around in subdevices (input devices that is). One thing I did note with the patches is that a lot of bits were altered from ir-foo to rc-foo, but not all of them... If we're going to make the change, why no go whole hog? (Or was it only things relevant to ir specifically right now that didn't get renamed?) The rule of thumb I followed was to rename stuff that I touched but leave unchanged code alone. Renaming the remaining functions can be done in later, separate, patches (some of them will be more invasive as file names need changing as well). On a related note, I'm getting confused wrt git the v4l-dvb git branches. The current patches are against staging/rc which hasn't seen much activity in a month or two but staging/other seems to carry some more recent rc-related patches...which one am I supposed to base my work on? -- David Härdeman -- 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: [PATCH v2 10/11] mt9m111: rewrite set_pixfmt
Robert, I'll need your ack / tested by on this one too. It actually
changes behaviour, for example, it sets MT9M111_OUTFMT_FLIP_BAYER_ROW in
the OUTPUT_FORMAT_CTRL register for the V4L2_MBUS_FMT_SBGGR8_1X8 8 bit
Bayer format. Maybe other things too - please have a look.
Thanks
Guennadi
On Tue, 3 Aug 2010, Michael Grzeschik wrote:
added more supported BE colour formats
and also support BGR565 swapped pixel formats
removed pixfmt helper functions and option flags
setting the configuration register directly in set_pixfmt
Signed-off-by: Philipp Wiesner p.wies...@phytec.de
Signed-off-by: Michael Grzeschik m.grzesc...@pengutronix.de
---
Changes v1 - v2
* removed unrelated OPMODE handling in this function
drivers/media/video/mt9m111.c | 143
-
1 files changed, 56 insertions(+), 87 deletions(-)
diff --git a/drivers/media/video/mt9m111.c b/drivers/media/video/mt9m111.c
index e865938..25b2317 100644
--- a/drivers/media/video/mt9m111.c
+++ b/drivers/media/video/mt9m111.c
@@ -101,7 +101,8 @@
#define MT9M111_OPMODE_AUTOEXPO_EN (1 14)
#define MT9M111_OPMODE_AUTOWHITEBAL_EN (1 1)
-
+#define MT9M111_OUTFMT_FLIP_BAYER_COL (1 9)
+#define MT9M111_OUTFMT_FLIP_BAYER_ROW (1 8)
#define MT9M111_OUTFMT_PROCESSED_BAYER (1 14)
#define MT9M111_OUTFMT_BYPASS_IFP(1 10)
#define MT9M111_OUTFMT_INV_PIX_CLOCK (1 9)
@@ -119,6 +120,7 @@
#define MT9M111_OUTFMT_SWAP_YCbCr_C_Y(1 1)
#define MT9M111_OUTFMT_SWAP_RGB_EVEN (1 1)
#define MT9M111_OUTFMT_SWAP_YCbCr_Cb_Cr (1 0)
+#define MT9M111_OUTFMT_SWAP_RGB_R_B (1 0)
/*
* Camera control register addresses (0x200..0x2ff not implemented)
@@ -161,7 +163,11 @@ static const struct mt9m111_datafmt
mt9m111_colour_fmts[] = {
{V4L2_MBUS_FMT_YUYV8_2X8_BE, V4L2_COLORSPACE_JPEG},
{V4L2_MBUS_FMT_YVYU8_2X8_BE, V4L2_COLORSPACE_JPEG},
{V4L2_MBUS_FMT_RGB555_2X8_PADHI_LE, V4L2_COLORSPACE_SRGB},
+ {V4L2_MBUS_FMT_RGB555_2X8_PADHI_BE, V4L2_COLORSPACE_SRGB},
{V4L2_MBUS_FMT_RGB565_2X8_LE, V4L2_COLORSPACE_SRGB},
+ {V4L2_MBUS_FMT_RGB565_2X8_BE, V4L2_COLORSPACE_SRGB},
+ {V4L2_MBUS_FMT_BGR565_2X8_LE, V4L2_COLORSPACE_SRGB},
+ {V4L2_MBUS_FMT_BGR565_2X8_BE, V4L2_COLORSPACE_SRGB},
{V4L2_MBUS_FMT_SBGGR8_1X8, V4L2_COLORSPACE_SRGB},
{V4L2_MBUS_FMT_SBGGR10_2X8_PADHI_LE, V4L2_COLORSPACE_SRGB},
};
@@ -184,10 +190,6 @@ struct mt9m111 {
unsigned int powered:1;
unsigned int hflip:1;
unsigned int vflip:1;
- unsigned int swap_rgb_even_odd:1;
- unsigned int swap_rgb_red_blue:1;
- unsigned int swap_yuv_y_chromas:1;
- unsigned int swap_yuv_cb_cr:1;
unsigned int autowhitebalance:1;
};
@@ -329,68 +331,6 @@ static int mt9m111_setup_rect(struct i2c_client *client,
return ret;
}
-static int mt9m111_setup_pixfmt(struct i2c_client *client, u16 outfmt)
-{
- int ret;
-
- ret = reg_write(OUTPUT_FORMAT_CTRL2_A, outfmt);
- if (!ret)
- ret = reg_write(OUTPUT_FORMAT_CTRL2_B, outfmt);
- return ret;
-}
-
-static int mt9m111_setfmt_bayer8(struct i2c_client *client)
-{
- return mt9m111_setup_pixfmt(client, MT9M111_OUTFMT_PROCESSED_BAYER |
- MT9M111_OUTFMT_RGB);
-}
-
-static int mt9m111_setfmt_bayer10(struct i2c_client *client)
-{
- return mt9m111_setup_pixfmt(client, MT9M111_OUTFMT_BYPASS_IFP);
-}
-
-static int mt9m111_setfmt_rgb565(struct i2c_client *client)
-{
- struct mt9m111 *mt9m111 = to_mt9m111(client);
- int val = 0;
-
- if (mt9m111-swap_rgb_red_blue)
- val |= MT9M111_OUTFMT_SWAP_YCbCr_Cb_Cr;
- if (mt9m111-swap_rgb_even_odd)
- val |= MT9M111_OUTFMT_SWAP_RGB_EVEN;
- val |= MT9M111_OUTFMT_RGB | MT9M111_OUTFMT_RGB565;
-
- return mt9m111_setup_pixfmt(client, val);
-}
-
-static int mt9m111_setfmt_rgb555(struct i2c_client *client)
-{
- struct mt9m111 *mt9m111 = to_mt9m111(client);
- int val = 0;
-
- if (mt9m111-swap_rgb_red_blue)
- val |= MT9M111_OUTFMT_SWAP_YCbCr_Cb_Cr;
- if (mt9m111-swap_rgb_even_odd)
- val |= MT9M111_OUTFMT_SWAP_RGB_EVEN;
- val |= MT9M111_OUTFMT_RGB | MT9M111_OUTFMT_RGB555;
-
- return mt9m111_setup_pixfmt(client, val);
-}
-
-static int mt9m111_setfmt_yuv(struct i2c_client *client)
-{
- struct mt9m111 *mt9m111 = to_mt9m111(client);
- int val = 0;
-
- if (mt9m111-swap_yuv_cb_cr)
- val |= MT9M111_OUTFMT_SWAP_YCbCr_Cb_Cr;
- if (mt9m111-swap_yuv_y_chromas)
- val |= MT9M111_OUTFMT_SWAP_YCbCr_C_Y;
-
- return mt9m111_setup_pixfmt(client, val);
-}
-
static int mt9m111_enable(struct i2c_client *client)
{
struct mt9m111 *mt9m111 = to_mt9m111(client);
@@ -518,41 +458,54 @@ static int mt9m111_g_fmt(struct v4l2_subdev *sd,
static int mt9m111_set_pixfmt(struct i2c_client *client,
[Query][videobuf-dma-sg] Pages in Highmem handling
Hi,
I see that in current videobuf library, for DMA SG code, these functions fail
when
Detecting a page in Highmem region:
- videobuf_pages_to_sg
- videobuf_vmalloc_to_sg
Now, what's the real reason to not allow handling of Highmem pages?
Is it an assumption that _always_ HighMem is not reachable by DMA?
I guess my point is, OMAP platform (and maybe other platforms) can handle
Highmem pages without any problem. I commented these validations:
65 static struct scatterlist *videobuf_vmalloc_to_sg(unsigned char *virt,
66 int nr_pages)
67 {
...
77 for (i = 0; i nr_pages; i++, virt += PAGE_SIZE) {
78 pg = vmalloc_to_page(virt);
79 if (NULL == pg)
80 goto err;
81 /* BUG_ON(PageHighMem(pg)); */
...
96 static struct scatterlist *videobuf_pages_to_sg(struct page **pages,
97 int nr_pages, int offset)
98 {
...
109 /* if (PageHighMem(pages[0])) */
110 /* DMA to highmem pages might not work */
111 /* goto highmem; */
112 sg_set_page(sglist[0], pages[0], PAGE_SIZE - offset, offset);
113 for (i = 1; i nr_pages; i++) {
114 if (NULL == pages[i])
115 goto nopage;
116 /* if (PageHighMem(pages[i]))
117 goto highmem; */
118 sg_set_page(sglist[i], pages[i], PAGE_SIZE, 0);
119 }
Can somebody shed any light on this?
Regards,
Sergio
--
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: [PATCH 04/11] mt9m111: added new bit offset defines
On Tue, 3 Aug 2010, Michael Grzeschik wrote: Signed-off-by: Philipp Wiesner p.wies...@phytec.de Signed-off-by: Michael Grzeschik m.grzesc...@pengutronix.de I don't see these being used in any of your patches... Thanks Guennadi --- drivers/media/video/mt9m111.c |6 ++ 1 files changed, 6 insertions(+), 0 deletions(-) diff --git a/drivers/media/video/mt9m111.c b/drivers/media/video/mt9m111.c index 8c076e5..1b21522 100644 --- a/drivers/media/video/mt9m111.c +++ b/drivers/media/video/mt9m111.c @@ -63,6 +63,12 @@ #define MT9M111_RESET_RESTART_FRAME (1 1) #define MT9M111_RESET_RESET_MODE (1 0) +#define MT9M111_RM_FULL_POWER_RD (0 10) +#define MT9M111_RM_LOW_POWER_RD (1 10) +#define MT9M111_RM_COL_SKIP_4X (1 5) +#define MT9M111_RM_ROW_SKIP_4X (1 4) +#define MT9M111_RM_COL_SKIP_2X (1 3) +#define MT9M111_RM_ROW_SKIP_2X (1 2) #define MT9M111_RMB_MIRROR_COLS (1 1) #define MT9M111_RMB_MIRROR_ROWS (1 0) #define MT9M111_CTXT_CTRL_RESTART(1 15) -- 1.7.1 --- 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: [PATCH 04/11] mt9m111: added new bit offset defines
On Fri, 27 Aug 2010, Michael Grzeschik wrote: On Fri, Aug 27, 2010 at 05:11:18PM +0200, Guennadi Liakhovetski wrote: On Tue, 3 Aug 2010, Michael Grzeschik wrote: Signed-off-by: Philipp Wiesner p.wies...@phytec.de Signed-off-by: Michael Grzeschik m.grzesc...@pengutronix.de I don't see these being used in any of your patches... Yes, these are not used. They are a left over from the previous patchstack. But they are checked against the datasheet and are correct. Is it a problem to take them anyway? It is not a problem, it is unneeded. You do not want to add all registers and all their fields to every driver, do you? There are some drivers in the kernel, that define more registers, than are used. Of course, say, if you use bits 0, 1, 2, and 4 of a register, you might as well define bit 3 - especially, if they are logically related. But this patch adds a whole family of parameters, none of which is used, so, I personally would avoid that. Thanks Guennadi Thanks, Michael --- drivers/media/video/mt9m111.c |6 ++ 1 files changed, 6 insertions(+), 0 deletions(-) diff --git a/drivers/media/video/mt9m111.c b/drivers/media/video/mt9m111.c index 8c076e5..1b21522 100644 --- a/drivers/media/video/mt9m111.c +++ b/drivers/media/video/mt9m111.c @@ -63,6 +63,12 @@ #define MT9M111_RESET_RESTART_FRAME (1 1) #define MT9M111_RESET_RESET_MODE (1 0) +#define MT9M111_RM_FULL_POWER_RD (0 10) +#define MT9M111_RM_LOW_POWER_RD (1 10) +#define MT9M111_RM_COL_SKIP_4X (1 5) +#define MT9M111_RM_ROW_SKIP_4X (1 4) +#define MT9M111_RM_COL_SKIP_2X (1 3) +#define MT9M111_RM_ROW_SKIP_2X (1 2) #define MT9M111_RMB_MIRROR_COLS (1 1) #define MT9M111_RMB_MIRROR_ROWS (1 0) #define MT9M111_CTXT_CTRL_RESTART(1 15) -- 1.7.1 -- Pengutronix e.K. | | Industrial Linux Solutions | http://www.pengutronix.de/ | Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0| Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- | --- 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: [PATCH 04/11] mt9m111: added new bit offset defines
On Fri, Aug 27, 2010 at 05:11:18PM +0200, Guennadi Liakhovetski wrote: On Tue, 3 Aug 2010, Michael Grzeschik wrote: Signed-off-by: Philipp Wiesner p.wies...@phytec.de Signed-off-by: Michael Grzeschik m.grzesc...@pengutronix.de I don't see these being used in any of your patches... Yes, these are not used. They are a left over from the previous patchstack. But they are checked against the datasheet and are correct. Is it a problem to take them anyway? Thanks, Michael --- drivers/media/video/mt9m111.c |6 ++ 1 files changed, 6 insertions(+), 0 deletions(-) diff --git a/drivers/media/video/mt9m111.c b/drivers/media/video/mt9m111.c index 8c076e5..1b21522 100644 --- a/drivers/media/video/mt9m111.c +++ b/drivers/media/video/mt9m111.c @@ -63,6 +63,12 @@ #define MT9M111_RESET_RESTART_FRAME(1 1) #define MT9M111_RESET_RESET_MODE (1 0) +#define MT9M111_RM_FULL_POWER_RD (0 10) +#define MT9M111_RM_LOW_POWER_RD(1 10) +#define MT9M111_RM_COL_SKIP_4X (1 5) +#define MT9M111_RM_ROW_SKIP_4X (1 4) +#define MT9M111_RM_COL_SKIP_2X (1 3) +#define MT9M111_RM_ROW_SKIP_2X (1 2) #define MT9M111_RMB_MIRROR_COLS(1 1) #define MT9M111_RMB_MIRROR_ROWS(1 0) #define MT9M111_CTXT_CTRL_RESTART (1 15) -- 1.7.1 -- Pengutronix e.K. | | Industrial Linux Solutions | http://www.pengutronix.de/ | Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0| Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- | -- 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: [PATCH 0/3] Proposed ir-core (rc-core) changes
David Härdeman da...@hardeman.nu wrote: On Thu, August 26, 2010 21:14, Jarod Wilson wrote: On Wed, Aug 25, 2010 at 01:01:57AM +0200, David Härdeman wrote: The following series merges the different files that currently make up the ir-core module into a single-file rc-core module. In addition, the ir_input_dev and ir_dev_props structs are replaced by a single rc_dev struct with an API similar to that of the input subsystem. This allows the removal of all knowledge of any input devices from the rc drivers and paves the way for allowing multiple input devices per rc device in the future. The namespace conversion from ir_* to rc_* should mostly be done for the drivers with this patchset. I have intentionally not signed off on the patches yet since they haven't been tested. I'd like your feedback on the general approach before I spend the time to properly test the result. Also, the imon driver is not converted (and will thus break with this patchset). The reason is that the imon driver wants to generate mouse events on the input dev under the control of rc-core. I was hoping that Jarod would be willing to convert the imon driver to create a separate input device for sending mouse events to userspace :) Yeah, I could be persuaded to do that. Means that the imon driver, when driving one of the touchscreen devices, will bring up 3 separate input devices, but oh well. (I'd actually considered doing that when porting to ir-core in the first place, but went the lazy route. ;) That would be good. I'm pretty certain that the split will be necessary sooner or later. Comments please... Haven't tried it out at all yet or done more than a quick skim through the patches, but at first glance, I do like the idea of further abstracting away the input layer. I know I tanked a few things the first go 'round, thinking I needed to do both some rc-layer and input-layer setup and/or teardown. It becomes more cut and dry if you don't see anything input-related anywhere at all. Not to mention we will have a more consistent user experience. For example: some of the current hardware drivers are fiddling with the repeat values of the input dev...something which should be the same across the entire subsystem (you wouldn't expect the repetition rate for the exact same remote control to change just because you change the receiver). Also, it's necessary for any future support of multiple input devices (one per physical remote control being one example)...and it gives us more flexibility to make changes in rc-core when drivers do not muck around in subdevices (input devices that is). One thing I did note with the patches is that a lot of bits were altered from ir-foo to rc-foo, but not all of them... If we're going to make the change, why no go whole hog? (Or was it only things relevant to ir specifically right now that didn't get renamed?) The rule of thumb I followed was to rename stuff that I touched but leave unchanged code alone. Renaming the remaining functions can be done in later, separate, patches (some of them will be more invasive as file names need changing as well). On a related note, I'm getting confused wrt git the v4l-dvb git branches. The current patches are against staging/rc which hasn't seen much activity in a month or two but staging/other seems to carry some more recent rc-related patches...which one am I supposed to base my work on? -- David Härdeman -- 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: linux-next: Tree for August 7 (IR)
On Mon, 09 Aug 2010 14:57:42 -0300 Mauro Carvalho Chehab wrote: Em 09-08-2010 14:41, Mauro Carvalho Chehab escreveu: Em 09-08-2010 11:52, Randy Dunlap escreveu: Hmm... clearly, there are some bad dependencies at the Kconfig. Maybe ir-core were compiled as module, while some drivers as built-in. Could you please pass the .config file for this build? Sorry, config-r5101 is now attached. Hmm... when building it, I'm getting an interesting warning: warning: (VIDEO_BT848 MEDIA_SUPPORT VIDEO_CAPTURE_DRIVERS VIDEO_DEV PCI I2C VIDEO_V4L2 INPUT || VIDEO_SAA7134 MEDIA_SUPPORT VIDEO_CAPTURE_DRIVERS VIDEO_V4L2 VIDEO_DEV PCI I2C INPUT || VIDEO_CX88 MEDIA_SUPPORT VIDEO_CAPTURE_DRIVERS VIDEO_V4L2 VIDEO_DEV PCI I2C INPUT || VIDEO_IVTV MEDIA_SUPPORT VIDEO_CAPTURE_DRIVERS VIDEO_V4L2 PCI I2C INPUT || VIDEO_CX18 MEDIA_SUPPORT VIDEO_CAPTURE_DRIVERS VIDEO_V4L2 DVB_CORE PCI I2C EXPERIMENTAL INPUT || VIDEO_EM28XX MEDIA_SUPPORT VIDEO_CAPTURE_DRIVERS VIDEO_V4L2 V4L_USB_DRIVERS USB VIDEO_DEV I2C INPUT || VIDEO_TLG2300 MEDIA_SUPPORT VIDEO_CAPTURE_DRIVERS VIDEO_V4L2 V4L_USB_DRIVERS USB VIDEO_DEV I2C INPUT SND DVB_CORE || VIDEO_CX231XX MEDIA_SUPPORT VIDEO_CAPTURE_DRIVERS VIDEO_V4L2 V4L_USB_DRIVERS USB VIDEO_DEV I2C INPUT || DVB_BUDGET_CI MEDIA_SUPPORT DVB! _CA PT URE_DRIVERS DVB_CORE DVB_BUDGET_CORE I2C INPUT || DVB_DM1105 MEDIA_SUPPORT DVB_CAPTURE_DRIVERS DVB_CORE PCI I2C INPUT || VIDEO_GO7007 STAGING !STAGING_EXCLUDE_BUILD VIDEO_DEV PCI I2C INPUT SND || VIDEO_CX25821 STAGING !STAGING_EXCLUDE_BUILD DVB_CORE VIDEO_DEV PCI I2C INPUT) selects VIDEO_IR which has unmet direct dependencies (IR_CORE) This warning seems to explain what's going wrong. I'll make patch(es) to address this issue. Ok, This patch (together with the previous one) seemed to solve the issue. Hi Mauro, Have you merged these 2 patches? I'm seeing very similar build errors in linux-next 20100827: ERROR: get_rc_map [drivers/media/video/saa7134/saa7134.ko] undefined! ERROR: ir_input_unregister [drivers/media/video/saa7134/saa7134.ko] undefined! ERROR: ir_raw_event_store_edge [drivers/media/video/saa7134/saa7134.ko] undefined! ERROR: __ir_input_register [drivers/media/video/saa7134/saa7134.ko] undefined! ERROR: ir_raw_event_handle [drivers/media/video/saa7134/saa7134.ko] undefined! ERROR: get_rc_map [drivers/media/video/cx88/cx88xx.ko] undefined! ERROR: ir_repeat [drivers/media/video/cx88/cx88xx.ko] undefined! ERROR: ir_input_unregister [drivers/media/video/cx88/cx88xx.ko] undefined! ERROR: ir_keydown [drivers/media/video/cx88/cx88xx.ko] undefined! ERROR: __ir_input_register [drivers/media/video/cx88/cx88xx.ko] undefined! ERROR: get_rc_map [drivers/media/video/bt8xx/bttv.ko] undefined! ERROR: ir_input_unregister [drivers/media/video/bt8xx/bttv.ko] undefined! ERROR: __ir_input_register [drivers/media/video/bt8xx/bttv.ko] undefined! ERROR: ir_g_keycode_from_table [drivers/media/IR/ir-common.ko] undefined! commit 0a706cf23aee2f6349f4b076f966038efb788a49 Author: Mauro Carvalho Chehab mche...@redhat.com Date: Mon Aug 9 14:45:02 2010 -0300 V4L/DVB: fix Kconfig to depends on VIDEO_IR warning: (VIDEO_BT848 MEDIA_SUPPORT VIDEO_CAPTURE_DRIVERS VIDEO_DEV PCI I2C VIDEO_V4L2 INPUT || VIDEO_SAA7134 MEDIA_SUPPORT VIDEO_CAPTURE_DRIVERS VIDEO_V4L2 VIDEO_DEV PCI I2C INPUT || VIDEO_CX88 MEDIA_SUPPORT VIDEO_CAPTURE_DRIVERS VIDEO_V4L2 VIDEO_DEV PCI I2C INPUT || VIDEO_IVTV MEDIA_SUPPORT VIDEO_CAPTURE_DRIVERS VIDEO_V4L2 PCI I2C INPUT || VIDEO_CX18 MEDIA_SUPPORT VIDEO_CAPTURE_DRIVERS VIDEO_V4L2 DVB_CORE PCI I2C EXPERIMENTAL INPUT || VIDEO_EM28XX MEDIA_SUPPORT VIDEO_CAPTURE_DRIVERS VIDEO_V4L2 V4L_USB_DRIVERS USB VIDEO_DEV I2C INPUT || VIDEO_TLG2300 MEDIA_SUPPORT VIDEO_CAPTURE_DRIVERS VIDEO_V4L2 V4L_USB_DRIVERS USB VIDEO_DEV I2C INPUT SND DVB_CORE || VIDEO_CX231XX MEDIA_SUPPORT VIDEO_CAPTURE_DRIVERS VIDEO_V4L2 V4L_USB_DRIVERS USB VIDEO_DEV I2C INPUT || DVB_BUDGET_CI MEDIA_SUPPORT D! VB_ CAPTURE_DRIVERS DVB_CORE DVB_BUDGET_CORE I2C INPUT || DVB_DM1105 MEDIA_SUPPORT DVB_CAPTURE_DRIVERS DVB_CORE PCI I2C INPUT || VIDEO_GO7007 STAGING !STAGING_EXCLUDE_BUILD VIDEO_DEV PCI I2C INPUT SND || VIDEO_CX25821 STAGING !STAGING_EXCLUDE_BUILD DVB_CORE VIDEO_DEV PCI I2C INPUT) selects VIDEO_IR which has unmet direct dependencies (IR_CORE) Signed-off-by: Mauro Carvalho Chehab mche...@redhat.com diff --git a/drivers/media/dvb/dm1105/Kconfig b/drivers/media/dvb/dm1105/Kconfig index 6952392..a6ceb08 100644 --- a/drivers/media/dvb/dm1105/Kconfig +++ b/drivers/media/dvb/dm1105/Kconfig @@ -9,7 +9,7 @@ config DVB_DM1105 select DVB_CX24116 if !DVB_FE_CUSTOMISE select DVB_SI21XX if !DVB_FE_CUSTOMISE select DVB_DS3000 if !DVB_FE_CUSTOMISE
Re: [PATCH 0/3] Proposed ir-core (rc-core) changes
Heh. Between where's the current base?, 1 hour rebuild times for the whole
kernel, and continual retooling of the IR core stuff, I can't keep up with the
time I have available.
Mauro did make an announcement a few weeks back. I thought it was the
media.git tree.
R,
Andy
David Härdeman da...@hardeman.nu wrote:
On Thu, August 26, 2010 21:14, Jarod Wilson wrote:
On Wed, Aug 25, 2010 at 01:01:57AM +0200, David Härdeman wrote:
The following series merges the different files that currently make up
the ir-core module into a single-file rc-core module.
In addition, the ir_input_dev and ir_dev_props structs are replaced
by a single rc_dev struct with an API similar to that of the input
subsystem.
This allows the removal of all knowledge of any input devices from the
rc drivers and paves the way for allowing multiple input devices per
rc device in the future. The namespace conversion from ir_* to rc_*
should mostly be done for the drivers with this patchset.
I have intentionally not signed off on the patches yet since they
haven't
been tested. I'd like your feedback on the general approach before I
spend
the time to properly test the result.
Also, the imon driver is not converted (and will thus break with this
patchset). The reason is that the imon driver wants to generate mouse
events on the input dev under the control of rc-core. I was hoping that
Jarod would be willing to convert the imon driver to create a separate
input device for sending mouse events to userspace :)
Yeah, I could be persuaded to do that. Means that the imon driver, when
driving one of the touchscreen devices, will bring up 3 separate input
devices, but oh well. (I'd actually considered doing that when porting to
ir-core in the first place, but went the lazy route. ;)
That would be good. I'm pretty certain that the split will be necessary
sooner or later.
Comments please...
Haven't tried it out at all yet or done more than a quick skim through the
patches, but at first glance, I do like the idea of further abstracting
away the input layer. I know I tanked a few things the first go 'round,
thinking I needed to do both some rc-layer and input-layer setup and/or
teardown. It becomes more cut and dry if you don't see anything
input-related anywhere at all.
Not to mention we will have a more consistent user experience. For
example: some of the current hardware drivers are fiddling with the repeat
values of the input dev...something which should be the same across the
entire subsystem (you wouldn't expect the repetition rate for the exact
same remote control to change just because you change the receiver).
Also, it's necessary for any future support of multiple input devices (one
per physical remote control being one example)...and it gives us more
flexibility to make changes in rc-core when drivers do not muck around in
subdevices (input devices that is).
One thing I did note with the patches is that a lot of bits were altered
from ir-foo to rc-foo, but not all of them... If we're going to make the
change, why no go whole hog? (Or was it only things relevant to ir
specifically right now that didn't get renamed?)
The rule of thumb I followed was to rename stuff that I touched but leave
unchanged code alone. Renaming the remaining functions can be done in
later, separate, patches (some of them will be more invasive as file names
need changing as well).
On a related note, I'm getting confused wrt git the v4l-dvb git branches.
The current patches are against staging/rc which hasn't seen much activity
in a month or two but staging/other seems to carry some more recent
rc-related patches...which one am I supposed to base my work on?
--
David Härdeman
--
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
N�r��yb�X��ǧv�^�){.n�+{���bj)w* jg��� �ݢj/���z�ޖ��2�ޙ�)ߡ�a���� �G���h��j:+v���w��٥
Re: [PATCH 04/11] mt9m111: added new bit offset defines
On Fri, Aug 27, 2010 at 06:30:28PM +0200, Guennadi Liakhovetski wrote: On Fri, 27 Aug 2010, Michael Grzeschik wrote: On Fri, Aug 27, 2010 at 05:11:18PM +0200, Guennadi Liakhovetski wrote: On Tue, 3 Aug 2010, Michael Grzeschik wrote: Signed-off-by: Philipp Wiesner p.wies...@phytec.de Signed-off-by: Michael Grzeschik m.grzesc...@pengutronix.de I don't see these being used in any of your patches... Yes, these are not used. They are a left over from the previous patchstack. But they are checked against the datasheet and are correct. Is it a problem to take them anyway? It is not a problem, it is unneeded. You do not want to add all registers and all their fields to every driver, do you? There are some drivers in the kernel, that define more registers, than are used. Of course, say, if you use bits 0, 1, 2, and 4 of a register, you might as well define bit 3 - especially, if they are logically related. But this patch adds a whole family of parameters, none of which is used, so, I personally would avoid that. Ok, no big deal. Personally i don't have a problem with additional inexpensive registers and fields. As they often can be a good hint to some functionality of a chip before you begin to scroll through the, sometimes not so easy to find, datasheets. But that is probably a pure matter of taste. Regards, Michael --- drivers/media/video/mt9m111.c |6 ++ 1 files changed, 6 insertions(+), 0 deletions(-) diff --git a/drivers/media/video/mt9m111.c b/drivers/media/video/mt9m111.c index 8c076e5..1b21522 100644 --- a/drivers/media/video/mt9m111.c +++ b/drivers/media/video/mt9m111.c @@ -63,6 +63,12 @@ #define MT9M111_RESET_RESTART_FRAME(1 1) #define MT9M111_RESET_RESET_MODE (1 0) +#define MT9M111_RM_FULL_POWER_RD (0 10) +#define MT9M111_RM_LOW_POWER_RD(1 10) +#define MT9M111_RM_COL_SKIP_4X (1 5) +#define MT9M111_RM_ROW_SKIP_4X (1 4) +#define MT9M111_RM_COL_SKIP_2X (1 3) +#define MT9M111_RM_ROW_SKIP_2X (1 2) #define MT9M111_RMB_MIRROR_COLS(1 1) #define MT9M111_RMB_MIRROR_ROWS(1 0) #define MT9M111_CTXT_CTRL_RESTART (1 15) -- 1.7.1 -- Pengutronix e.K. | | Industrial Linux Solutions | http://www.pengutronix.de/ | Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0| Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- | -- Pengutronix e.K. | | Industrial Linux Solutions | http://www.pengutronix.de/ | Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0| Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- | -- 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: [PATCH 0/3] Proposed ir-core (rc-core) changes
On Fri, Aug 27, 2010 at 11:55:47AM -0400, Andy Walls wrote: Heh. Between where's the current base?, 1 hour rebuild times for the whole kernel, and continual retooling of the IR core stuff, I can't keep up with the time I have available. Mauro did make an announcement a few weeks back. I thought it was the media.git tree. Yeah, the most recent patch I've done was against media_tree.git, branch staging/v2.6.36. http://git.linuxtv.org/media_tree.git?a=shortlog;h=refs/heads/staging/v2.6.36 I believe there's a slightly updated mceusb.c in there vs. what this patchset was against, and there are also streamzap.c and ene_ir.c in there, ported from lirc to ir-core in there that would also need to be updated for these changes. (Nb: there's a fairly major streamzap.c patch still pending, wouldn't start working on that port until it gets merged.) David Härdeman da...@hardeman.nu wrote: On Thu, August 26, 2010 21:14, Jarod Wilson wrote: On Wed, Aug 25, 2010 at 01:01:57AM +0200, David Härdeman wrote: The following series merges the different files that currently make up the ir-core module into a single-file rc-core module. In addition, the ir_input_dev and ir_dev_props structs are replaced by a single rc_dev struct with an API similar to that of the input subsystem. This allows the removal of all knowledge of any input devices from the rc drivers and paves the way for allowing multiple input devices per rc device in the future. The namespace conversion from ir_* to rc_* should mostly be done for the drivers with this patchset. I have intentionally not signed off on the patches yet since they haven't been tested. I'd like your feedback on the general approach before I spend the time to properly test the result. Also, the imon driver is not converted (and will thus break with this patchset). The reason is that the imon driver wants to generate mouse events on the input dev under the control of rc-core. I was hoping that Jarod would be willing to convert the imon driver to create a separate input device for sending mouse events to userspace :) Yeah, I could be persuaded to do that. Means that the imon driver, when driving one of the touchscreen devices, will bring up 3 separate input devices, but oh well. (I'd actually considered doing that when porting to ir-core in the first place, but went the lazy route. ;) That would be good. I'm pretty certain that the split will be necessary sooner or later. Comments please... Haven't tried it out at all yet or done more than a quick skim through the patches, but at first glance, I do like the idea of further abstracting away the input layer. I know I tanked a few things the first go 'round, thinking I needed to do both some rc-layer and input-layer setup and/or teardown. It becomes more cut and dry if you don't see anything input-related anywhere at all. Not to mention we will have a more consistent user experience. For example: some of the current hardware drivers are fiddling with the repeat values of the input dev...something which should be the same across the entire subsystem (you wouldn't expect the repetition rate for the exact same remote control to change just because you change the receiver). Also, it's necessary for any future support of multiple input devices (one per physical remote control being one example)...and it gives us more flexibility to make changes in rc-core when drivers do not muck around in subdevices (input devices that is). One thing I did note with the patches is that a lot of bits were altered from ir-foo to rc-foo, but not all of them... If we're going to make the change, why no go whole hog? (Or was it only things relevant to ir specifically right now that didn't get renamed?) The rule of thumb I followed was to rename stuff that I touched but leave unchanged code alone. Renaming the remaining functions can be done in later, separate, patches (some of them will be more invasive as file names need changing as well). On a related note, I'm getting confused wrt git the v4l-dvb git branches. The current patches are against staging/rc which hasn't seen much activity in a month or two but staging/other seems to carry some more recent rc-related patches...which one am I supposed to base my work on? -- David Härdeman -- 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 -- Jarod Wilson ja...@redhat.com -- 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
[cron job] v4l-dvb daily build 2.6.26 and up: ERRORS
This message is generated daily by a cron job that builds v4l-dvb for the kernels and architectures in the list below. Results of the daily build of v4l-dvb: date:Fri Aug 27 19:00:06 CEST 2010 path:http://www.linuxtv.org/hg/v4l-dvb changeset: 15138:a4c762698bcb git master: f6760aa024199cfbce564311dc4bc4d47b6fb349 git media-master: 1c1371c2fe53ded8ede3a0404c9415fbf3321328 gcc version: i686-linux-gcc (GCC) 4.4.3 host hardware:x86_64 host os: 2.6.32.5 linux-2.6.32.6-armv5: ERRORS linux-2.6.33-armv5: OK linux-2.6.34-armv5: WARNINGS linux-2.6.35.3-armv5: WARNINGS linux-2.6.36-rc2-armv5: ERRORS linux-2.6.32.6-armv5-davinci: ERRORS linux-2.6.33-armv5-davinci: WARNINGS linux-2.6.34-armv5-davinci: WARNINGS linux-2.6.35.3-armv5-davinci: WARNINGS linux-2.6.36-rc2-armv5-davinci: ERRORS linux-2.6.32.6-armv5-ixp: ERRORS linux-2.6.33-armv5-ixp: WARNINGS linux-2.6.34-armv5-ixp: WARNINGS linux-2.6.35.3-armv5-ixp: WARNINGS linux-2.6.36-rc2-armv5-ixp: ERRORS linux-2.6.32.6-armv5-omap2: ERRORS linux-2.6.33-armv5-omap2: WARNINGS linux-2.6.34-armv5-omap2: WARNINGS linux-2.6.35.3-armv5-omap2: WARNINGS linux-2.6.36-rc2-armv5-omap2: ERRORS linux-2.6.26.8-i686: WARNINGS linux-2.6.27.44-i686: WARNINGS linux-2.6.28.10-i686: WARNINGS linux-2.6.29.1-i686: WARNINGS linux-2.6.30.10-i686: WARNINGS linux-2.6.31.12-i686: WARNINGS linux-2.6.32.6-i686: ERRORS linux-2.6.33-i686: WARNINGS linux-2.6.34-i686: WARNINGS linux-2.6.35.3-i686: WARNINGS linux-2.6.36-rc2-i686: ERRORS linux-2.6.32.6-m32r: ERRORS linux-2.6.33-m32r: OK linux-2.6.34-m32r: WARNINGS linux-2.6.35.3-m32r: WARNINGS linux-2.6.36-rc2-m32r: ERRORS linux-2.6.32.6-mips: ERRORS linux-2.6.33-mips: WARNINGS linux-2.6.34-mips: WARNINGS linux-2.6.35.3-mips: WARNINGS linux-2.6.36-rc2-mips: ERRORS linux-2.6.32.6-powerpc64: ERRORS linux-2.6.33-powerpc64: WARNINGS linux-2.6.34-powerpc64: WARNINGS linux-2.6.35.3-powerpc64: WARNINGS linux-2.6.36-rc2-powerpc64: ERRORS linux-2.6.26.8-x86_64: WARNINGS linux-2.6.27.44-x86_64: WARNINGS linux-2.6.28.10-x86_64: WARNINGS linux-2.6.29.1-x86_64: WARNINGS linux-2.6.30.10-x86_64: WARNINGS linux-2.6.31.12-x86_64: WARNINGS linux-2.6.32.6-x86_64: ERRORS linux-2.6.33-x86_64: WARNINGS linux-2.6.34-x86_64: WARNINGS linux-2.6.35.3-x86_64: WARNINGS linux-2.6.36-rc2-x86_64: ERRORS linux-git-Module.symvers: ERRORS linux-git-armv5: ERRORS linux-git-armv5-davinci: ERRORS linux-git-armv5-ixp: ERRORS linux-git-armv5-omap2: ERRORS linux-git-i686: ERRORS linux-git-m32r: ERRORS linux-git-mips: ERRORS linux-git-powerpc64: ERRORS linux-git-x86_64: ERRORS spec: ERRORS spec-git: OK sparse: ERRORS Detailed results are available here: http://www.xs4all.nl/~hverkuil/logs/Friday.log Full logs are available here: http://www.xs4all.nl/~hverkuil/logs/Friday.tar.bz2 The V4L-DVB specification from this daily build is here: http://www.xs4all.nl/~hverkuil/spec/media.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: [PATCH/RFC] V4L2: add a generic function to find the nearest discrete format
On Sat, 7 Aug 2010, Laurent Pinchart wrote:
Hi Guennadi,
On Saturday 07 August 2010 15:20:58 Guennadi Liakhovetski wrote:
On Sat, 7 Aug 2010, lawrence rust wrote:
[snip]
A mean squared error metric such as hypot() could be better but requires
FP. An integer only version wouldn't be too difficult.
No FP in the kernel. And I don't think this simple task justifies any
numerical acrobatic. But we can just compare x^2 + y^2 - without an sqrt.
Is it worth it?
What about comparing areas ? The uvcvideo driver does (rw and rh are the
request width and request height, format is a structure containing an array
of
supported sizes)
/* Find the closest image size. The distance between image sizes is
* the size in pixels of the non-overlapping regions between the
* requested size and the frame-specified size.
*/
Well, nice, but, tbh, I have no idea what's better. With your metric
640x489 is further from 640x480 than 650x480, with my it's the other way
round. Which one is better? What we can do, if this really is important,
we could make a callback for user-provided metric function... Shall we?
Thanks
Guennadi
rw = fmt-fmt.pix.width;
rh = fmt-fmt.pix.height;
maxd = (unsigned int)-1;
for (i = 0; i format-nframes; ++i) {
__u16 w = format-frame[i].wWidth;
__u16 h = format-frame[i].wHeight;
d = min(w, rw) * min(h, rh);
d = w*h + rw*rh - 2*d;
if (d maxd) {
maxd = d;
frame = format-frame[i];
}
if (maxd == 0)
break;
}
--
Regards,
Laurent Pinchart
---
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
new kmemleak in kernel 2.6.35.4
Hello, compared to 2.6.34.x this kmemleak seems to be new at my ThinkPad T400 under an almost stable Gentoo Linux w/ a 'Terratec Cinergy T USB XXS (HD)/ T3' : tfoer...@n22 ~ $ cat /sys/kernel/debug/kmemleak unreferenced object 0xcabeb320 (size 32): comm modprobe, pid 9285, jiffies 16386098 (age 7416.020s) hex dump (first 32 bytes): 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 backtrace: [c122f8d7] kmemleak_alloc+0x27/0x50 [c109c34f] kmem_cache_alloc+0x9f/0xe0 [fcb8d91d] dib0700_rc_setup+0x7d/0x120 [dvb_usb_dib0700] [fcb8da54] dib0700_probe+0x94/0xb0 [dvb_usb_dib0700] [f86385b4] usb_probe_interface+0xf4/0x1c0 [usbcore] [c11892cb] driver_probe_device+0x7b/0x190 [c1189471] __driver_attach+0x91/0xa0 [c1188b88] bus_for_each_dev+0x48/0x70 [c1189159] driver_attach+0x19/0x20 [c1188567] bus_add_driver+0x187/0x250 [c1189705] driver_register+0x65/0x120 [f863829c] usb_register_driver+0x7c/0x140 [usbcore] [fcb9c030] 0xfcb9c030 [c100112d] do_one_initcall+0x2d/0x180 [c105ecf9] sys_init_module+0x99/0x1e0 [c1002d97] sysenter_do_call+0x12/0x26 -- MfG/Kind regards Toralf Förster pgp finger print: 7B1A 07F4 EC82 0F90 D4C2 8936 872A E508 7DB6 9DA3 -- 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
[PATCH] drm, video: fix use-before-NULL-check
Fix potential crashes due to use-before-NULL situations.
Signed-off-by: Kees Cook kees.c...@canonical.com
---
drivers/gpu/drm/drm_fb_helper.c |3 ++-
drivers/media/video/em28xx/em28xx-video.c |3 ++-
2 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c
index de82e20..8dd7e6f 100644
--- a/drivers/gpu/drm/drm_fb_helper.c
+++ b/drivers/gpu/drm/drm_fb_helper.c
@@ -94,10 +94,11 @@ static bool
drm_fb_helper_connector_parse_command_line(struct drm_fb_helper_conn
int i;
enum drm_connector_force force = DRM_FORCE_UNSPECIFIED;
struct drm_fb_helper_cmdline_mode *cmdline_mode;
- struct drm_connector *connector = fb_helper_conn-connector;
+ struct drm_connector *connector;
if (!fb_helper_conn)
return false;
+ connector = fb_helper_conn-connector;
cmdline_mode = fb_helper_conn-cmdline_mode;
if (!mode_option)
diff --git a/drivers/media/video/em28xx/em28xx-video.c
b/drivers/media/video/em28xx/em28xx-video.c
index 7b9ec6e..95a4b60 100644
--- a/drivers/media/video/em28xx/em28xx-video.c
+++ b/drivers/media/video/em28xx/em28xx-video.c
@@ -277,12 +277,13 @@ static void em28xx_copy_vbi(struct em28xx *dev,
{
void *startwrite, *startread;
int offset;
- int bytesperline = dev-vbi_width;
+ int bytesperline;
if (dev == NULL) {
em28xx_isocdbg(dev is null\n);
return;
}
+ bytesperline = dev-vbi_width;
if (dma_q == NULL) {
em28xx_isocdbg(dma_q is null\n);
--
1.7.1
--
Kees Cook
Ubuntu Security Team
--
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
[PATCH] IR/mceusb: add an ASUS device ID
Reported in lirc sf.net tracker
Signed-off-by: Jarod Wilson ja...@redhat.com
---
drivers/media/IR/mceusb.c |2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/drivers/media/IR/mceusb.c b/drivers/media/IR/mceusb.c
index ac6bb2c..f0b7e42 100644
--- a/drivers/media/IR/mceusb.c
+++ b/drivers/media/IR/mceusb.c
@@ -120,6 +120,8 @@ static struct usb_device_id mceusb_dev_table[] = {
{ USB_DEVICE(VENDOR_PHILIPS, 0x0613) },
/* Philips eHome Infrared Transceiver */
{ USB_DEVICE(VENDOR_PHILIPS, 0x0815) },
+ /* Philips/Spinel plus IR transceiver for ASUS */
+ { USB_DEVICE(VENDOR_PHILIPS, 0x2088) },
/* Realtek MCE IR Receiver */
{ USB_DEVICE(VENDOR_REALTEK, 0x0161) },
/* SMK/Toshiba G83C0004D410 */
--
1.7.2.2
--
Jarod Wilson
ja...@redhat.com
--
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: ibmcam (xrilink_cit) and konica webcam driver porting to gspca update
On Sun, Jul 4, 2010 at 6:29 AM, Hans de Goede hdego...@redhat.com wrote: Hi all, I've finished porting the usbvideo v4l1 ibmcam and konicawc drivers to gspcav2. The ibmcam driver is replaced by gspca_xirlink_cit, which also adds support for 2 new models (it turned out my testing cams where not supported by the old driver). This one could use more testing. I just tried using your driver. I get no video. using 2.6.35.3. Had to patch usb_buffer_[alloc free] otherwise no changes to your tree. /usr/bin/qv4l2 /dev/video2 Start Capture: Input/output error VIDIOC_STREAMON: Input/output error Start Capture: Input/output error VIDIOC_STREAMON: Input/output error -- info Model 2 KSX-X9903 0x0545 0x8080 3.0a Old, cheaper model Xirlink C-It /usr/sbin/v4l2-dbg -d /dev/video2 -D Driver info: Driver name : xirlink-cit Card type : USB IMAGING DEVICE Bus info : usb-:00:12.2-6.1 Driver version: 133376 Capabilities : 0x0501 Video Capture Read/Write Streaming Any Ideas Jonathan The konicawc driver is replaced by gspca_konica which is pretty much finished. You can get them both here: http://linuxtv.org/hg/~hgoede/ibmcam Once Douglas updates the hg v4l-dvb tree to be up2date with the latest and greatest from Mauro, then I'll rebase my tree (the ibmcam driver needs a very recent gspca core patch), and send a pull request. Regards, Hans p.s. 1) Many thanks to Patryk Biela for providing me a konica driver using camera. 2) Still to do the se401 driver. 3) I'll be on vacation the coming week and not reading email. -- 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 -- ASUS m3a78 motherboard AMD Athlon64 X2 Dual Core Processor 6000+ 3.1Ghz 2 Gigabytes of DDR2-800 Gigabyte nVidia 9400gt Graphics adapter KWorld ATSC 110 TV Capture Card KWorld ATSC 115 TV Capture Card -- 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
