Re: [PULL] http://www.linuxtv.org/hg/~hverkuil/v4l-dvb-utils
Hans Verkuil wrote: Hi Mauro, Please address patches to v4l2-apps and other non-upstream stuff directly to Douglas ;) Cheers, Mauro -- 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: [PULL] http://www.linuxtv.org/hg/~hverkuil/v4l-dvb-utils
On Monday 22 February 2010 16:07:15 Mauro Carvalho Chehab wrote: Hans Verkuil wrote: Hi Mauro, Please address patches to v4l2-apps and other non-upstream stuff directly to Douglas ;) Oops! I've corrected my script :-) Regards, Hans -- Hans Verkuil - video4linux developer - sponsored by TANDBERG -- 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: [PULL] http://www.linuxtv.org/hg/~hverkuil/v4l-dvb
Hans Verkuil wrote: Hi Mauro, On Fri, 29 Jan 2010, Hans Verkuil wrote: (resent: forgot to mail it to the linux-media list) Hi Mauro, Please pull from http://www.linuxtv.org/hg/~hverkuil/v4l-dvb for the following: - saa7134: remove stray unlock_kernel This is a high-prio bugfix that must go to 2.6.33! Dmitri, this patch will fix the kernel oops in your latest stack trace. Just to remind you: When will this regression fix be merged? It is important that this is sent upstream for 2.6.33! Sent today. I need to wait for a couple days between the -git merge and sending upstream, to allow the patch to go to linux-next. Cheers, Mauro -- 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: [PULL] http://www.linuxtv.org/hg/~hverkuil/v4l-dvb
Hi Mauro, On Fri, 29 Jan 2010, Hans Verkuil wrote: (resent: forgot to mail it to the linux-media list) Hi Mauro, Please pull from http://www.linuxtv.org/hg/~hverkuil/v4l-dvb for the following: - saa7134: remove stray unlock_kernel This is a high-prio bugfix that must go to 2.6.33! Dmitri, this patch will fix the kernel oops in your latest stack trace. Just to remind you: When will this regression fix be merged? It is important that this is sent upstream for 2.6.33! Regards, Hans Thanks, Hans diffstat: saa7134-empress.c |8 +++- 1 file changed, 3 insertions(+), 5 deletions(-) -- Hans Verkuil - video4linux developer - sponsored by TANDBERG -- 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: [PULL] http://www.linuxtv.org/hg/~hverkuil/v4l-dvb-davinci
Hans, Thanks for this pull request.. I gather that Murali and you have figured out the right order to merge this, so I leave the details to the both of you. Not really :( I haven't seen a response to my last email on this. Note that I agree with Mauro's suggestion that the v4l parts of the platform code are split off into a separate platform source. That would make it much easier to make changes in the platform code for v4l devices without running into conflicts with non-v4l platform code changes. We could even make that v4l platform source part of the hg tree. Do you suggest creating separate arch part source for hg tree and upstream? (I see you have arch folders in the hg tree, but only few architectures currently supported mx*/px*). If so, how is the upstream merge of arch code handled in your case? My question is when the v4l part is merged, the corresponding arch part has to be merged as well to compile the upstream code base. So this is not going to solve the issue that we are facing currently. May be I am not getting the full picture here. BTW, I am okay to have an account in the hg tree. Is there a quick tutorial to understand the process and tools needed to get me started? Regards, Murali Karicheri Software Design Engineer Texas Instruments Inc. Germantown, MD 20874 phone: 301-407-9583 email: m-kariche...@ti.com -Original Message- From: Hans Verkuil [mailto:hverk...@xs4all.nl] Sent: Wednesday, December 30, 2009 8:49 AM To: linux-media@vger.kernel.org Cc: Mauro Carvalho Chehab; Karicheri, Muralidharan; khil...@deeprootsystems.com Subject: [PULL] http://www.linuxtv.org/hg/~hverkuil/v4l-dvb-davinci Hi Mauro, Please pull from http://www.linuxtv.org/hg/~hverkuil/v4l-dvb-davinci for the following: - v4l: vpfe_capture: remove clock and ccdc resource handling - v4l: vpfe capture: convert dm355 ccdc driver to a platform driver - v4l: vpfe capture: convert dm644x ccdc module to a platform driver - V4L: vpfe capture: header files for ISIF driver - V4L: vpfe capture: source for ISIF driver on DM365 - V4L: vpfe capture: vpss driver enhancements for DM365 - V4L: vpfe_capture: bug fixes and enhancements - V4L: vpfe capture: build environment for isif driver And after the first three patches are pulled in, then this arch patch should also be merged for git: http://patchwork.kernel.org/patch/67669/ And after the other four patches are pulled in, then this arch patch should be merged for git: http://patchwork.kernel.org/patch/68876/ Note that I agree with Mauro's suggestion that the v4l parts of the platform code are split off into a separate platform source. That would make it much easier to make changes in the platform code for v4l devices without running into conflicts with non-v4l platform code changes. We could even make that v4l platform source part of the hg tree. I also think it is a good idea if you ask for an account on linuxtv.org so that you can set up your own hg trees and you don't have to wait for me. Thanks, Hans diffstat: b/linux/drivers/media/video/davinci/isif.c | 1512 +++ b/linux/drivers/media/video/davinci/isif_regs.h | 269 b/linux/include/media/davinci/isif.h | 531 linux/drivers/media/video/Kconfig| 14 linux/drivers/media/video/davinci/Makefile |1 linux/drivers/media/video/davinci/dm355_ccdc.c | 413 +++--- linux/drivers/media/video/davinci/dm644x_ccdc.c | 362 +++-- linux/drivers/media/video/davinci/vpfe_capture.c | 254 +-- linux/drivers/media/video/davinci/vpss.c | 289 +++- linux/include/media/davinci/vpfe_capture.h | 12 linux/include/media/davinci/vpss.h | 41 11 files changed, 3180 insertions(+), 518 deletions(-) -- Hans Verkuil - video4linux developer - sponsored by TANDBERG
Re: [PULL] http://www.linuxtv.org/hg/~hverkuil/v4l-dvb-davinci
Karicheri, Muralidharan wrote: Hans, Thanks for this pull request.. I gather that Murali and you have figured out the right order to merge this, so I leave the details to the both of you. Not really :( I haven't seen a response to my last email on this. Note that I agree with Mauro's suggestion that the v4l parts of the platform code are split off into a separate platform source. That would make it much easier to make changes in the platform code for v4l devices without running into conflicts with non-v4l platform code changes. We could even make that v4l platform source part of the hg tree. Do you suggest creating separate arch part source for hg tree and upstream? (I see you have arch folders in the hg tree, but only few architectures currently supported mx*/px*). If so, how is the upstream merge of arch code handled in your case? My question is when the v4l part is merged, the corresponding arch part has to be merged as well to compile the upstream code base. So this is not going to solve the issue that we are facing currently. May be I am not getting the full picture here. The issue is that non-v4l platform data changes that happens on the same headers where you have also v4l platform data changes cause lots of merge troubles. This happens with -hg, but this also would happen if I just merge from a -git tree. So, the problem is not about having a different procedure due to -hg, but having a way to avoid having merge conflicts every time an omap driver (or another driver that uses the platform_data stuff) is merged. On my experiences, the non-Intel arch headers used by V4L drivers got renamed, had several api changes and mixed several different subsystems at the same header, causing all sorts of merge conflicts. Since the soc_camera and omap drivers got merged, on every single kernel version, we had some sort of conflict to manage. On several cases, git bisect got broken, and we had even some worse case scenarios where the arch compilation got broken for some time, due to those conflicts. BTW, I am okay to have an account in the hg tree. Is there a quick tutorial to understand the process and tools needed to get me started? I can send you one, but maybe it is a little late for it, since my intention is to start discussing and working to replace -hg to -git at the beginning of 2010, if time allows me to do that. Cheers, Mauro. -- 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: [PULL] http://www.linuxtv.org/hg/~hverkuil/v4l-dvb-davinci
Mauro, What do you suggest for the existing 2 pull requests from Hans? I had suggested something in my last email to do this in 2 steps based on Kevin's proposal. 1) Merge the patches (including arch patches) to linux-next tree based on Hans's pull request. 2) When upstream merge window opens and Kevin's davinci tree is merged to Linus tree, drop the arch patches from v4l-dvb. We could re-work the dropped patches based on Linus tree and send the same to you. Do you think this is doable? If so, please merge these pull requests to linux-next. Murali Karicheri Software Design Engineer Texas Instruments Inc. Germantown, MD 20874 phone: 301-407-9583 email: m-kariche...@ti.com -Original Message- From: Mauro Carvalho Chehab [mailto:mche...@infradead.org] Sent: Wednesday, December 30, 2009 5:25 PM To: Karicheri, Muralidharan Cc: Hans Verkuil; linux-media@vger.kernel.org; khil...@deeprootsystems.com Subject: Re: [PULL] http://www.linuxtv.org/hg/~hverkuil/v4l-dvb-davinci Karicheri, Muralidharan wrote: Hans, Thanks for this pull request.. I gather that Murali and you have figured out the right order to merge this, so I leave the details to the both of you. Not really :( I haven't seen a response to my last email on this. Note that I agree with Mauro's suggestion that the v4l parts of the platform code are split off into a separate platform source. That would make it much easier to make changes in the platform code for v4l devices without running into conflicts with non-v4l platform code changes. We could even make that v4l platform source part of the hg tree. Do you suggest creating separate arch part source for hg tree and upstream? (I see you have arch folders in the hg tree, but only few architectures currently supported mx*/px*). If so, how is the upstream merge of arch code handled in your case? My question is when the v4l part is merged, the corresponding arch part has to be merged as well to compile the upstream code base. So this is not going to solve the issue that we are facing currently. May be I am not getting the full picture here. The issue is that non-v4l platform data changes that happens on the same headers where you have also v4l platform data changes cause lots of merge troubles. This happens with -hg, but this also would happen if I just merge from a - git tree. So, the problem is not about having a different procedure due to -hg, but having a way to avoid having merge conflicts every time an omap driver (or another driver that uses the platform_data stuff) is merged. On my experiences, the non-Intel arch headers used by V4L drivers got renamed, had several api changes and mixed several different subsystems at the same header, causing all sorts of merge conflicts. Since the soc_camera and omap drivers got merged, on every single kernel version, we had some sort of conflict to manage. On several cases, git bisect got broken, and we had even some worse case scenarios where the arch compilation got broken for some time, due to those conflicts. BTW, I am okay to have an account in the hg tree. Is there a quick tutorial to understand the process and tools needed to get me started? I can send you one, but maybe it is a little late for it, since my intention is to start discussing and working to replace -hg to -git at the beginning of 2010, if time allows me to do that. Cheers, Mauro.
Re: [PULL] http://www.linuxtv.org/hg/~hverkuil/v4l-dvb-davinci
Hans Verkuil wrote: Hi Mauro, Please pull from http://www.linuxtv.org/hg/~hverkuil/v4l-dvb-davinci for the following: - v4l: vpfe_capture: remove clock and ccdc resource handling - v4l: vpfe capture: convert dm355 ccdc driver to a platform driver - v4l: vpfe capture: convert dm644x ccdc module to a platform driver And after these three patches are pulled in, then this arch patch should also be merged for git: http://patchwork.kernel.org/patch/67669/ Hmm... It seems that git bisect will break if I merge first the conversion and then the platform_data patches. Also, we had some bad merge dependency troubles last time I merged an arch patch on my tree, as those omap arch header files are highly volatile. I bet that, if I merge the patch #67669 on my tree it will cause conflicts when I send it during the next merge window (and it is too late for sending those patches to linux-next, wait for a couple days and send upstream before -rc1). Cheers, Mauro. -- 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: [PULL] http://www.linuxtv.org/hg/~hverkuil/v4l-dvb-davinci
Hans Verkuil wrote: Hi Mauro, Please pull from http://www.linuxtv.org/hg/~hverkuil/v4l-dvb-davinci for the following: - v4l: vpfe_capture: remove clock and ccdc resource handling - v4l: vpfe capture: convert dm355 ccdc driver to a platform driver - v4l: vpfe capture: convert dm644x ccdc module to a platform driver And after these three patches are pulled in, then this arch patch should also be merged for git: http://patchwork.kernel.org/patch/67669/ Hmm... It seems that git bisect will break if I merge first the conversion and then the platform_data patches. Murali, what is the correct merge order? I assumed that the order you gave me was 'safe' (as in, it always compiles after each patch). I did compile the v4l patches, but I did not check if there was any breakage if I build the full kernel. Also, we had some bad merge dependency troubles last time I merged an arch patch on my tree, as those omap arch header files are highly volatile. I bet that, if I merge the patch #67669 on my tree it will cause conflicts when I send it during the next merge window (and it is too late for sending those patches to linux-next, wait for a couple days and send upstream before -rc1). Cheers, Mauro. So what do you want me or Murali to do? Wait until rc1 is released and then make sure that the arch patch will apply correctly to what is in rc1? Regards, Hans -- Hans Verkuil - video4linux developer - sponsored by TANDBERG Telecom -- 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: [PULL] http://www.linuxtv.org/hg/~hverkuil/v4l-dvb-davinci
Hans Verkuil wrote: Hans Verkuil wrote: Hi Mauro, Please pull from http://www.linuxtv.org/hg/~hverkuil/v4l-dvb-davinci for the following: - v4l: vpfe_capture: remove clock and ccdc resource handling - v4l: vpfe capture: convert dm355 ccdc driver to a platform driver - v4l: vpfe capture: convert dm644x ccdc module to a platform driver And after these three patches are pulled in, then this arch patch should also be merged for git: http://patchwork.kernel.org/patch/67669/ Hmm... It seems that git bisect will break if I merge first the conversion and then the platform_data patches. Murali, what is the correct merge order? I assumed that the order you gave me was 'safe' (as in, it always compiles after each patch). I did compile the v4l patches, but I did not check if there was any breakage if I build the full kernel. To be safe, it needs not only to compile, but also to not break the driver, otherwise bisecting the affected drivers will not work. So what do you want me or Murali to do? Wait until rc1 is released and then make sure that the arch patch will apply correctly to what is in rc1? This won't solve, since, between 2.6.33-rc1 and the next open window (2.6.34 window), I bet that the *.h file will change enough for the merge to not apply. I see two ways: 1) (if it is safe to apply the platform_data patch without the v4l changes) send the patch to the -arch maintainer, as he'll handle the other changes to the same header file; 2) create a platform_data glue module/file that will handle the arch/platform_data glue for omap drivers and maintain it together with arch. All V4L specific code should be kept maintained on V4L subsystem. (2) is better, but will probably require more time to happen, but IMHO, this is the solution to avoid having troubles like that on all merge windows. Cheers, Mauro. -- 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: [PULL] http://www.linuxtv.org/hg/~hverkuil/v4l-dvb-davinci
Mauro, Kevin is going to merge the arch part #67669 as we did last time. Please merge only the v4l2 part. I have copied Kevin in this email. Murali Karicheri Software Design Engineer Texas Instruments Inc. Germantown, MD 20874 phone: 301-407-9583 email: m-kariche...@ti.com -Original Message- From: Mauro Carvalho Chehab [mailto:mche...@infradead.org] Sent: Thursday, December 17, 2009 6:18 AM To: Hans Verkuil Cc: linux-media@vger.kernel.org; Karicheri, Muralidharan Subject: Re: [PULL] http://www.linuxtv.org/hg/~hverkuil/v4l-dvb-davinci Hans Verkuil wrote: Hi Mauro, Please pull from http://www.linuxtv.org/hg/~hverkuil/v4l-dvb-davinci for the following: - v4l: vpfe_capture: remove clock and ccdc resource handling - v4l: vpfe capture: convert dm355 ccdc driver to a platform driver - v4l: vpfe capture: convert dm644x ccdc module to a platform driver And after these three patches are pulled in, then this arch patch should also be merged for git: http://patchwork.kernel.org/patch/67669/ Hmm... It seems that git bisect will break if I merge first the conversion and then the platform_data patches. Also, we had some bad merge dependency troubles last time I merged an arch patch on my tree, as those omap arch header files are highly volatile. I bet that, if I merge the patch #67669 on my tree it will cause conflicts when I send it during the next merge window (and it is too late for sending those patches to linux-next, wait for a couple days and send upstream before -rc1). Cheers, Mauro. -- 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: [PULL] http://www.linuxtv.org/hg/~hverkuil/v4l-dvb-davinci
Hans Mauro, I have already replied to Mauro's email. This is what we had followed last time for vpfe capture. Mauro will merge the v4l2 part and Kevin will merge the arch part. These needs be done in sync so that it will compile fine in the upstream. Let me know if this cannot be done this time. Murali Karicheri Software Design Engineer Texas Instruments Inc. Germantown, MD 20874 phone: 301-407-9583 email: m-kariche...@ti.com -Original Message- From: Hans Verkuil [mailto:hverk...@xs4all.nl] Sent: Thursday, December 17, 2009 6:30 AM To: Mauro Carvalho Chehab Cc: linux-media@vger.kernel.org; Karicheri, Muralidharan Subject: Re: [PULL] http://www.linuxtv.org/hg/~hverkuil/v4l-dvb-davinci Hans Verkuil wrote: Hi Mauro, Please pull from http://www.linuxtv.org/hg/~hverkuil/v4l-dvb-davinci for the following: - v4l: vpfe_capture: remove clock and ccdc resource handling - v4l: vpfe capture: convert dm355 ccdc driver to a platform driver - v4l: vpfe capture: convert dm644x ccdc module to a platform driver And after these three patches are pulled in, then this arch patch should also be merged for git: http://patchwork.kernel.org/patch/67669/ Hmm... It seems that git bisect will break if I merge first the conversion and then the platform_data patches. Murali, what is the correct merge order? I assumed that the order you gave me was 'safe' (as in, it always compiles after each patch). I did compile the v4l patches, but I did not check if there was any breakage if I build the full kernel. Also, we had some bad merge dependency troubles last time I merged an arch patch on my tree, as those omap arch header files are highly volatile. I bet that, if I merge the patch #67669 on my tree it will cause conflicts when I send it during the next merge window (and it is too late for sending those patches to linux-next, wait for a couple days and send upstream before -rc1). Cheers, Mauro. So what do you want me or Murali to do? Wait until rc1 is released and then make sure that the arch patch will apply correctly to what is in rc1? Regards, Hans -- Hans Verkuil - video4linux developer - sponsored by TANDBERG Telecom -- 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: [PULL] http://www.linuxtv.org/hg/~hverkuil/v4l-dvb-timings
Hans, Thanks for sending this pull request. No problem in my name being mentioned in the spec. Thanks. Murali Karicheri Software Design Engineer Texas Instruments Inc. Germantown, MD 20874 phone: 301-407-9583 email: m-kariche...@ti.com -Original Message- From: Hans Verkuil [mailto:hverk...@xs4all.nl] Sent: Wednesday, December 02, 2009 11:40 PM To: linux-media@vger.kernel.org Cc: Mauro Carvalho Chehab; Karicheri, Muralidharan Subject: [PULL] http://www.linuxtv.org/hg/~hverkuil/v4l-dvb-timings Hi Mauro, Please pull from http://www.linuxtv.org/hg/~hverkuil/v4l-dvb-timings for the following: - v4l: Adding Digital Video Timings APIs - v4l2-spec: Digital Video Timings API documentation - v4l2-spec: updated revision history, updated version to 2.6.33. Murali, I've added you as one of the authors of the v4l2-spec (you did this timings API after all) and included your email as well. If that is a problem for you (either being mentioned at all, or that your email is mentioned), then let me know asap and I'll remove it. I don't expect it to be a problem since all this information is already public. Mauro, before adding these documentation patches it is probably a good idea to build and release a final 2.6.32 version of the documentation on http://www.linuxtv.org/docs.php. If you want to see an example of this api being used, then take a look at the tvp7002 driver patches that have been posted recently. I expect that driver to be merged soon after this pull request is merged. Thanks, Hans diffstat: b/linux/Documentation/DocBook/v4l/vidioc-enum-dv-presets.xml | 238 +++ b/linux/Documentation/DocBook/v4l/vidioc-g-dv-preset.xml | 111 + b/linux/Documentation/DocBook/v4l/vidioc-g-dv-timings.xml| 224 ++ b/linux/Documentation/DocBook/v4l/vidioc-query-dv-preset.xml | 85 +++ linux/Documentation/DocBook/media-entities.tmpl | 18 linux/Documentation/DocBook/media-indices.tmpl |4 linux/Documentation/DocBook/v4l/common.xml | 35 + linux/Documentation/DocBook/v4l/compat.xml | 16 linux/Documentation/DocBook/v4l/v4l2.xml | 26 + linux/Documentation/DocBook/v4l/videodev2.h.xml | 116 + linux/Documentation/DocBook/v4l/vidioc-enuminput.xml | 36 + linux/Documentation/DocBook/v4l/vidioc-enumoutput.xml| 36 + linux/drivers/media/video/v4l2-compat-ioctl32.c |6 linux/drivers/media/video/v4l2-ioctl.c | 147 ++ linux/include/linux/videodev2.h | 116 + linux/include/media/v4l2-ioctl.h | 15 linux/include/media/v4l2-subdev.h| 21 media-specs/Makefile | 14 18 files changed, 1252 insertions(+), 12 deletions(-)
Re: [PULL] http://www.linuxtv.org/hg/~hverkuil/v4l-dvb
Hans Verkuil wrote: Hi Mauro, Please pull from http://www.linuxtv.org/hg/~hverkuil/v4l-dvb for the following: - spec: unexpand initial spaces when generating xml sources - spec: regenerated xml source files Hans, I'm not sure if this is the right way. The tabs are replaced by spaces there for some reason. I'm not a DocBook expert, but maybe this will cause some document messing. If not then the better is to just not expanding tabs at all. I think it would be easier to just prevent make rmspaces to run the script against *.[ch].xml. Cheers, Mauro. -- 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: [PULL] http://www.linuxtv.org/hg/~hverkuil/v4l-dvb
On Wednesday 25 November 2009 19:42:15 Mauro Carvalho Chehab wrote: Hans Verkuil wrote: Hi Mauro, Please pull from http://www.linuxtv.org/hg/~hverkuil/v4l-dvb for the following: - spec: unexpand initial spaces when generating xml sources - spec: regenerated xml source files Hans, I'm not sure if this is the right way. The tabs are replaced by spaces there for some reason. I'm not a DocBook expert, but maybe this will cause some document messing. If not then the better is to just not expanding tabs at all. The reason the tabs are replaced has to do with 'non-leading' tabs, e.g. tabs that are not at the start of the line, but for example between a statement and a comment. Since the xml generation will replace some types or structs with hyperlinks the following text is no longer tab-aligned. This is not however a problem with leading spaces: these can still safely be converted back to tabs. I think it would be easier to just prevent make rmspaces to run the script against *.[ch].xml. I think you are right. I'll make another pull request for this. My solution is OK, but it is just simpler to not run rmspaces for these files. Definitely easier to understand as well. Hans Cheers, Mauro. -- Hans Verkuil - video4linux developer - sponsored by TANDBERG -- 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: [PULL] http://www.linuxtv.org/hg/~hverkuil/v4l-dvb-pms
Hans Verkuil wrote: Hi Mauro, Please pull from http://www.linuxtv.org/hg/~hverkuil/v4l-dvb-pms for the following: - pms: source code cleanup, use struct v4l2_device. - pms: convert from V4L1 to V4L2. It's time to get this merged. I always wanted to allow this driver to be used with 'cat /dev/video0 x' instead of requiring 'dd', but it's pretty unlikely that I'll find the time to do that any time soon. It's not exactly the most used driver :-) Congratulations for the conversion! It is really cool to see such old devices keeping being supported by the subsystem! Cheers, Mauro -- 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: [PULL] http://www.linuxtv.org/hg/~hverkuil/v4l-dvb
Hans Verkuil wrote: On Wednesday 25 November 2009 19:42:15 Mauro Carvalho Chehab wrote: Hans Verkuil wrote: Hi Mauro, Please pull from http://www.linuxtv.org/hg/~hverkuil/v4l-dvb for the following: - spec: unexpand initial spaces when generating xml sources - spec: regenerated xml source files Hans, I'm not sure if this is the right way. The tabs are replaced by spaces there for some reason. I'm not a DocBook expert, but maybe this will cause some document messing. If not then the better is to just not expanding tabs at all. The reason the tabs are replaced has to do with 'non-leading' tabs, e.g. tabs that are not at the start of the line, but for example between a statement and a comment. Since the xml generation will replace some types or structs with hyperlinks the following text is no longer tab-aligned. This is not however a problem with leading spaces: these can still safely be converted back to tabs. I think it would be easier to just prevent make rmspaces to run the script against *.[ch].xml. I think you are right. I'll make another pull request for this. Ok. FYI, I've already cherry-picked the other two patches. My solution is OK, but it is just simpler to not run rmspaces for these files. Definitely easier to understand as well. Agreed. Cheers, Mauro. -- 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: [PULL] http://www.linuxtv.org/hg/~hverkuil/v4l-dvb
On Wednesday 25 November 2009 23:32:31 Hans Verkuil wrote: Hi Mauro, Please pull from http://www.linuxtv.org/hg/~hverkuil/v4l-dvb for the following: - dib8000: fix compile warning - valj5jf8007s/t: fix compile warnings - dvb-bt8xx: fix compile warning - firedtv: require at least version 2.6.23. - se401: fix 2.6.17 compile error. - cx18: only build for kernels = 2.6.17 Added one more: - firedtv-1394: do not build for kernels 2.6.30 With this one added we should indeed have no more build errors. BTW: I've enabled the sparse check again in the build. It was disabled for a long time due to sparse producing a huge amount of unrelated warnings. This seems to be fixed now, either in the latest sparse or in the latest kernels. So it is on again and we should take a look at the output of tonight's run and see if there is anything interesting in the sparse log. Regards, Hans I have good hope that after this set of small fixes we just might perhaps possibly achieve an OK result during the daily build. Maybe. If we're lucky. Thanks, Hans diffstat: linux/drivers/media/dvb/bt8xx/dvb-bt8xx.c |2 +- linux/drivers/media/dvb/frontends/dib8000.c |2 +- linux/drivers/media/dvb/pt1/va1j5jf8007s.c |2 +- linux/drivers/media/dvb/pt1/va1j5jf8007t.c |2 +- linux/drivers/media/video/se401.h |4 v4l/versions.txt| 11 ++- 6 files changed, 14 insertions(+), 9 deletions(-) -- Hans Verkuil - video4linux developer - sponsored by TANDBERG -- 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: [PULL] http://www.linuxtv.org/hg/~hverkuil/v4l-dvb-timings
Hans Verkuil wrote: Hi Mauro, Please pull from http://www.linuxtv.org/hg/~hverkuil/v4l-dvb-timings for the following: - v4l: Adding Digital Video Timings APIs This adds an important missing piece to the V4L2 API: the ability to receive and transmit HDTV video. The documentation needs another review cycle, mostly for grammar and style, but that should prevent this patch from going in. I had some bad experiences of not merging both specs and patches at the same time... DVB S2 API were added one year ago, and the promises were that the doc patches would be sent 1-2 weeks after the merge... we're still waiting for it... So, please submit both specs and code changes at the same pull request. As a bonus, reviewing both docs and patches at the same time are easier than doing it in separate. Many thanks to Murali and everyone else who has been involved in the discussions and reviews for this new API. Thanks, Hans diffstat: drivers/media/video/v4l2-compat-ioctl32.c |6 + drivers/media/video/v4l2-ioctl.c | 147 ++ include/linux/videodev2.h | 116 +++ include/media/v4l2-ioctl.h| 15 +++ include/media/v4l2-subdev.h | 21 5 files changed, 303 insertions(+), 2 deletions(-) -- 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: [PULL] http://www.linuxtv.org/hg/~hverkuil/v4l-dvb-timings
Mauro, I have submitted the doc patch for review. But no comments so far. Murali Karicheri Software Design Engineer Texas Instruments Inc. Germantown, MD 20874 phone: 301-407-9583 email: m-kariche...@ti.com -Original Message- From: Mauro Carvalho Chehab [mailto:mche...@infradead.org] Sent: Tuesday, November 24, 2009 11:42 AM To: Hans Verkuil Cc: v4l-dvb; Karicheri, Muralidharan Subject: Re: [PULL] http://www.linuxtv.org/hg/~hverkuil/v4l-dvb-timings Hans Verkuil wrote: Hi Mauro, Please pull from http://www.linuxtv.org/hg/~hverkuil/v4l-dvb-timings for the following: - v4l: Adding Digital Video Timings APIs This adds an important missing piece to the V4L2 API: the ability to receive and transmit HDTV video. The documentation needs another review cycle, mostly for grammar and style, but that should prevent this patch from going in. I had some bad experiences of not merging both specs and patches at the same time... DVB S2 API were added one year ago, and the promises were that the doc patches would be sent 1-2 weeks after the merge... we're still waiting for it... So, please submit both specs and code changes at the same pull request. As a bonus, reviewing both docs and patches at the same time are easier than doing it in separate. Many thanks to Murali and everyone else who has been involved in the discussions and reviews for this new API. Thanks, Hans diffstat: drivers/media/video/v4l2-compat-ioctl32.c |6 + drivers/media/video/v4l2-ioctl.c | 147 ++ include/linux/videodev2.h | 116 +++ include/media/v4l2-ioctl.h| 15 +++ include/media/v4l2-subdev.h | 21 5 files changed, 303 insertions(+), 2 deletions(-) -- 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: [PULL] http://www.linuxtv.org/hg/~hverkuil/v4l-dvb-timings
Mauro, I have submitted the doc patch for review. But no comments so far. I'll review it tomorrow. I did a quick scan earlier and saw several things that needs improvement, but I simply did not have time to write it all down in a review. Regards, Hans Murali Karicheri Software Design Engineer Texas Instruments Inc. Germantown, MD 20874 phone: 301-407-9583 email: m-kariche...@ti.com -Original Message- From: Mauro Carvalho Chehab [mailto:mche...@infradead.org] Sent: Tuesday, November 24, 2009 11:42 AM To: Hans Verkuil Cc: v4l-dvb; Karicheri, Muralidharan Subject: Re: [PULL] http://www.linuxtv.org/hg/~hverkuil/v4l-dvb-timings Hans Verkuil wrote: Hi Mauro, Please pull from http://www.linuxtv.org/hg/~hverkuil/v4l-dvb-timings for the following: - v4l: Adding Digital Video Timings APIs This adds an important missing piece to the V4L2 API: the ability to receive and transmit HDTV video. The documentation needs another review cycle, mostly for grammar and style, but that should prevent this patch from going in. I had some bad experiences of not merging both specs and patches at the same time... DVB S2 API were added one year ago, and the promises were that the doc patches would be sent 1-2 weeks after the merge... we're still waiting for it... So, please submit both specs and code changes at the same pull request. As a bonus, reviewing both docs and patches at the same time are easier than doing it in separate. Many thanks to Murali and everyone else who has been involved in the discussions and reviews for this new API. Thanks, Hans diffstat: drivers/media/video/v4l2-compat-ioctl32.c |6 + drivers/media/video/v4l2-ioctl.c | 147 ++ include/linux/videodev2.h | 116 +++ include/media/v4l2-ioctl.h| 15 +++ include/media/v4l2-subdev.h | 21 5 files changed, 303 insertions(+), 2 deletions(-) -- Hans Verkuil - video4linux developer - sponsored by TANDBERG Telecom -- 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: [PULL] http://www.linuxtv.org/hg/~hverkuil/v4l-dvb-timings
Hans Verkuil wrote: Hi Mauro, Please pull from http://www.linuxtv.org/hg/~hverkuil/v4l-dvb-timings for the following: - v4l: Adding Digital Video Timings APIs This adds an important missing piece to the V4L2 API: the ability to receive and transmit HDTV video. The documentation needs another review cycle, mostly for grammar and style, but that should prevent this patch from going in. I had some bad experiences of not merging both specs and patches at the same time... DVB S2 API were added one year ago, and the promises were that the doc patches would be sent 1-2 weeks after the merge... we're still waiting for it... So, please submit both specs and code changes at the same pull request. The big difference is that the documentation patch is available already. It just needs one extra round of editing. Regards, Hans As a bonus, reviewing both docs and patches at the same time are easier than doing it in separate. Many thanks to Murali and everyone else who has been involved in the discussions and reviews for this new API. Thanks, Hans diffstat: drivers/media/video/v4l2-compat-ioctl32.c |6 + drivers/media/video/v4l2-ioctl.c | 147 ++ include/linux/videodev2.h | 116 +++ include/media/v4l2-ioctl.h| 15 +++ include/media/v4l2-subdev.h | 21 5 files changed, 303 insertions(+), 2 deletions(-) -- 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 -- Hans Verkuil - video4linux developer - sponsored by TANDBERG Telecom -- 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: [PULL] http://www.linuxtv.org/hg/~hverkuil/v4l-dvb-timings
Hi Murali, Karicheri, Muralidharan wrote: Mauro, I have submitted the doc patch for review. But no comments so far. It is very hard to track massive sets of individual patches. That's why we offer some hosting space for developer trees at linuxtv website. This way, we can better analyze such patches. Due to the very high traffic of OMAP messages at the ML, and due to the large number of versions OMAP patches are taking to be mature, and due to the fact that all those patches require dedicated hardware that only the developers that are actually doing the work have for testing, I've opted to keep away from such discussions and to mark every patch related to it at Patchwork as RFC, waiting for the patches to be more mature for me to review. So, I'm basically trusting that one of you will do the sub-maintainers job of adding the patches on a tree and asking me to pull. Currently, Sakari and Hans have accounts at linuxtv that can be used for that purpose. You may also host your -hg trees on any other place and ask me to pull from it. If you (TI) think that you need another -hg account, feel free to send me a private email for me to create it, but please don't ask me to dig into individual patches, since it won't scale. In the specific case of the V4L/DVB timings API, if you think that the current doc proposal is OK, please merge it with the patches into some -hg tree and ask me to pull from it. Thanks, Mauro. -- 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: [PULL] http://www.linuxtv.org/hg/~hverkuil/v4l-dvb
Hans Verkuil wrote: Hi Mauro, Please pull from http://www.linuxtv.org/hg/~hverkuil/v4l-dvb for the following: As agreed at the #v4l irc channel, I've cherry picked the patches. I needed to do a few small fixes. Please double check when you have some time. - v4l2-spec: add missing V4L2-PIX-FMT-STV0680 description. I've applied here the modified version. - decode_tm6000: fix compilation I had to solve a conflict with a previous patch that partially fixed this issue. - davinci: add missing vpif_capture.c/h files - Davinci VPFE Capture: Specify device pointer in videobuf_queue_dma_contig_init - Davinci VPFE Capture: add i2c adapter id in platform data - Davinci VPFE Capture: Take i2c adapter id through platform data - Davinci VPFE Capture:Replaced IRQ_VDINT1 with vpfe_dev-ccdc_irq1 - V4L2: Added CID's V4L2_CID_ROTATE/BG_COLOR - v4l2 doc: Added ROTATE and BG_COLOR control documentation - Davinci VPFE Capture: Add support for Control ioctls - V4L2: Add Capability and Flag field for Chroma Key - v4l2 doc: Added FBUF_CAP_SRC_CHROMAKEY/FLAG_SRC_CHROMAKEY - v4l2-dbg: report fail reason to the user I've already applied the original version. I've applied the diff. - libv4l: fix Makefile include dir references Cheers, Mauro. -- 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: [PULL] http://www.linuxtv.org/hg/~hverkuil/v4l-dvb
Hans Verkuil wrote: Hi Mauro, Please pull from http://www.linuxtv.org/hg/~hverkuil/v4l-dvb for the following: As agreed at the #v4l irc channel, I've cherry picked the patches. I needed to do a few small fixes. Please double check when you have some time. - v4l2-spec: add missing V4L2-PIX-FMT-STV0680 description. I've applied here the modified version. Ack. - decode_tm6000: fix compilation I had to solve a conflict with a previous patch that partially fixed this issue. Ack. - davinci: add missing vpif_capture.c/h files - Davinci VPFE Capture: Specify device pointer in videobuf_queue_dma_contig_init - Davinci VPFE Capture: add i2c adapter id in platform data - Davinci VPFE Capture: Take i2c adapter id through platform data - Davinci VPFE Capture:Replaced IRQ_VDINT1 with vpfe_dev-ccdc_irq1 - V4L2: Added CID's V4L2_CID_ROTATE/BG_COLOR - v4l2 doc: Added ROTATE and BG_COLOR control documentation - Davinci VPFE Capture: Add support for Control ioctls - V4L2: Add Capability and Flag field for Chroma Key - v4l2 doc: Added FBUF_CAP_SRC_CHROMAKEY/FLAG_SRC_CHROMAKEY - v4l2-dbg: report fail reason to the user I've already applied the original version. I've applied the diff. Hmm... We are now back to the original version. Something went wrong here. If you reapply the patch from my v4l-dvb tree, then you should have the correct end result. BTW: isn't it better to merge the pull requests before any posted patches? Pull requests might contain patches that were posted earlier (esp. if they were reviewed first, as happened with this particular patch), so doing those first will prevent such conflicts. Regards, Hans - libv4l: fix Makefile include dir references Cheers, Mauro. -- 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 -- Hans Verkuil - video4linux developer - sponsored by TANDBERG Telecom -- 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: [PULL] http://www.linuxtv.org/hg/~hverkuil/v4l-dvb-timings
Mauro, So, I'm basically trusting that one of you will do the sub-maintainers job of adding the patches on a tree and asking me to pull. Currently, Sakari and Hans have accounts at linuxtv that can be used for that purpose. You may also host your -hg trees on any other place and ask me to pull from it. Currently all the patches go through Hans. If you (TI) think that you need another -hg account, feel free to send me a private email for me to create it, but please don't ask me to dig into I think we will have to do it eventually. We will work on this and let you know once we have this ready. Even in that case, H individual patches, since it won't scale. In the specific case of the V4L/DVB timings API, if you think that the current doc proposal is OK, please merge it with the patches into some -hg tree and ask me to pull from it. See email from Hans. Once he gives me his comments, I will work on it and provide an updated patch. But IMO you should go ahead and merge the video timing API patch for which Hans had sent you a pull request (since we have the documentation part being reviewed in the list). We are waiting for this to be merged to send additional patches that depends on it. So this is a high priority patch for 2.6.33. Thanks and regards, Murali Thanks, Mauro. -- 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: [PULL] http://www.linuxtv.org/hg/~hverkuil/v4l-dvb-staging
Hans Verkuil wrote: On Friday 20 November 2009 22:06:02 Devin Heitmueller wrote: On Fri, Nov 20, 2009 at 3:38 PM, Hans Verkuil hverk...@xs4all.nl wrote: Hi Mauro, Please pull from http://www.linuxtv.org/hg/~hverkuil/v4l-dvb-staging for the following: - Enable staging drivers by default when building v4l-dvb - go7007: Add struct v4l2_device. - s2250: Change module structure - s2250: subdev conversion - go7007: subdev conversion I have to admit that I am not sure that enabling staging drivers by default is a good idea. Staging drivers can be highly unstable, and can potentially damage hardware. I can totally imagine less experienced users with one of these devices building the current code and then being confused why their hardware is detected but is totally broken, or worse becomes damaged. If there are drivers in the staging tree that are so unreliable that they can break the hardware, then those should be explicitly disabled, rather than disabling all drivers in the staging tree. Or perhaps do not belong there at all, or belong under the CONFIG_STAGING_BROKEN option. A driver like the go7007 is under active development, and it does work. It only needs more cleanup before it can be moved to drivers/media/video, so there was no reason that it should be disabled. Mauro, what are the risks of always compiling the tm6000 and cx25821 drivers? Let me know if you think that either one or both should be disabled for now and I'll make a patch for it. Even on upstream, drivers in staging are not compiled by default. To enable them, you need to answer yes to two questions. If the driver is OK, it shouldn't be in staging. The drivers that are in staging have issues that may be just coding style, can be the usage of wrong API's, or can be something serious. Also, since the criteria for a driver to be in staging are weak, they may not be prepared to be used widely, since they is likely doing some evil things, like duplicating existing code or creating non-accepted API's. In the go7007 case, among other things, the driver duplicates existing code at the saa7115 driver still uses the already deprecated DECODER ioctl's, and creates its own API (see go7007.h). So, I'm against of enabling any staging drivers to be compiled by default. Of course, in the case of auto-compilation tests tools like what you have, it is valuable if you add a patch there that enables their compilations inside the tool, but such patch shouldn't be committed at the development tree, simply because staging drivers aren't ready yet. The developers and testers of the staging drivers should manually enable it, after being warned about the risks of using them. By not compiling you run the very high risk of bit rot: code getting seriously out-of-sync with the rest of the tree. Possibly requiring a lot of work later. If the driver is being maintained, this risk is low, since the driver maintainer will take care of it. It helps if your automatic build scripts could point that the driver compilation broke for some kernels, but, as the driver is being prepared for upstream submission, the developer should already being using the latest -rc kernel for its development. If they aren't maintained, they'll be removed from staging tree on a few kernel cycles, so patches fixing the compilation for those unmaintained drivers just means that someone lost his time fixing a dead driver. Cheers, Mauro -- 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: [PULL] http://www.linuxtv.org/hg/~hverkuil/v4l-dvb-staging
Hans Verkuil wrote: On Friday 20 November 2009 22:06:02 Devin Heitmueller wrote: On Fri, Nov 20, 2009 at 3:38 PM, Hans Verkuil hverk...@xs4all.nl wrote: Hi Mauro, Please pull from http://www.linuxtv.org/hg/~hverkuil/v4l-dvb-staging for the following: - Enable staging drivers by default when building v4l-dvb - go7007: Add struct v4l2_device. - s2250: Change module structure - s2250: subdev conversion - go7007: subdev conversion I have to admit that I am not sure that enabling staging drivers by default is a good idea. Staging drivers can be highly unstable, and can potentially damage hardware. I can totally imagine less experienced users with one of these devices building the current code and then being confused why their hardware is detected but is totally broken, or worse becomes damaged. If there are drivers in the staging tree that are so unreliable that they can break the hardware, then those should be explicitly disabled, rather than disabling all drivers in the staging tree. Or perhaps do not belong there at all, or belong under the CONFIG_STAGING_BROKEN option. A driver like the go7007 is under active development, and it does work. It only needs more cleanup before it can be moved to drivers/media/video, so there was no reason that it should be disabled. Mauro, what are the risks of always compiling the tm6000 and cx25821 drivers? Let me know if you think that either one or both should be disabled for now and I'll make a patch for it. Even on upstream, drivers in staging are not compiled by default. To enable them, you need to answer yes to two questions. If the driver is OK, it shouldn't be in staging. The drivers that are in staging have issues that may be just coding style, can be the usage of wrong API's, or can be something serious. Also, since the criteria for a driver to be in staging are weak, they may not be prepared to be used widely, since they is likely doing some evil things, like duplicating existing code or creating non-accepted API's. In the go7007 case, among other things, the driver duplicates existing code at the saa7115 driver still uses the already deprecated DECODER ioctl's, and creates its own API (see go7007.h). So, I'm against of enabling any staging drivers to be compiled by default. Of course, in the case of auto-compilation tests tools like what you have, it is valuable if you add a patch there that enables their compilations inside the tool, but such patch shouldn't be committed at the development tree, simply because staging drivers aren't ready yet. The developers and testers of the staging drivers should manually enable it, after being warned about the risks of using them. By not compiling you run the very high risk of bit rot: code getting seriously out-of-sync with the rest of the tree. Possibly requiring a lot of work later. If the driver is being maintained, this risk is low, since the driver maintainer will take care of it. It helps if your automatic build scripts could point that the driver compilation broke for some kernels, but, as the driver is being prepared for upstream submission, the developer should already being using the latest -rc kernel for its development. If they aren't maintained, they'll be removed from staging tree on a few kernel cycles, so patches fixing the compilation for those unmaintained drivers just means that someone lost his time fixing a dead driver. I've reverted that patch and respun my v4l-dvb-staging tree. Regards, Hans -- Hans Verkuil - video4linux developer - sponsored by TANDBERG Telecom -- 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: [PULL] http://www.linuxtv.org/hg/~hverkuil/v4l-dvb-staging
Hans Verkuil wrote: Hans Verkuil wrote: On Friday 20 November 2009 22:06:02 Devin Heitmueller wrote: On Fri, Nov 20, 2009 at 3:38 PM, Hans Verkuil hverk...@xs4all.nl wrote: Hi Mauro, Please pull from http://www.linuxtv.org/hg/~hverkuil/v4l-dvb-staging for the following: - Enable staging drivers by default when building v4l-dvb - go7007: Add struct v4l2_device. - s2250: Change module structure - s2250: subdev conversion - go7007: subdev conversion I have to admit that I am not sure that enabling staging drivers by default is a good idea. Staging drivers can be highly unstable, and can potentially damage hardware. I can totally imagine less experienced users with one of these devices building the current code and then being confused why their hardware is detected but is totally broken, or worse becomes damaged. If there are drivers in the staging tree that are so unreliable that they can break the hardware, then those should be explicitly disabled, rather than disabling all drivers in the staging tree. Or perhaps do not belong there at all, or belong under the CONFIG_STAGING_BROKEN option. A driver like the go7007 is under active development, and it does work. It only needs more cleanup before it can be moved to drivers/media/video, so there was no reason that it should be disabled. Mauro, what are the risks of always compiling the tm6000 and cx25821 drivers? Let me know if you think that either one or both should be disabled for now and I'll make a patch for it. Even on upstream, drivers in staging are not compiled by default. To enable them, you need to answer yes to two questions. If the driver is OK, it shouldn't be in staging. The drivers that are in staging have issues that may be just coding style, can be the usage of wrong API's, or can be something serious. Also, since the criteria for a driver to be in staging are weak, they may not be prepared to be used widely, since they is likely doing some evil things, like duplicating existing code or creating non-accepted API's. In the go7007 case, among other things, the driver duplicates existing code at the saa7115 driver still uses the already deprecated DECODER ioctl's, and creates its own API (see go7007.h). So, I'm against of enabling any staging drivers to be compiled by default. Of course, in the case of auto-compilation tests tools like what you have, it is valuable if you add a patch there that enables their compilations inside the tool, but such patch shouldn't be committed at the development tree, simply because staging drivers aren't ready yet. The developers and testers of the staging drivers should manually enable it, after being warned about the risks of using them. By not compiling you run the very high risk of bit rot: code getting seriously out-of-sync with the rest of the tree. Possibly requiring a lot of work later. If the driver is being maintained, this risk is low, since the driver maintainer will take care of it. It helps if your automatic build scripts could point that the driver compilation broke for some kernels, but, as the driver is being prepared for upstream submission, the developer should already being using the latest -rc kernel for its development. If they aren't maintained, they'll be removed from staging tree on a few kernel cycles, so patches fixing the compilation for those unmaintained drivers just means that someone lost his time fixing a dead driver. I've reverted that patch and respun my v4l-dvb-staging tree. Thanks. I should be pulling from all pending requests today, after finishing the pending stuff at patchwork. Cheers, Mauro. -- 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: [PULL] http://www.linuxtv.org/hg/~hverkuil/v4l-dvb
Hans Verkuil wrote: Hi Mauro, Please pull from http://www.linuxtv.org/hg/~hverkuil/v4l-dvb for the following: - v4l2-spec: add missing V4L2-PIX-FMT-STV0680 description. Something went wrong here: $ less /tmp/newpatches/hg_v4l-dvb_01.patch|diffstat -p1 linux/Documentation/DocBook/v4l/pixfmt.xml |5 linux/Documentation/DocBook/v4l/videodev2.h.xml | 1097 2 files changed, 554 insertions(+), 548 deletions(-) Why a simple patch like this is changing 1097 lines at videodev2.h.xml? Cheers, Mauro. -- 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: [PULL] http://www.linuxtv.org/hg/~hverkuil/v4l-dvb
Mauro Carvalho Chehab wrote:
Hans Verkuil wrote:
Hi Mauro,
Please pull from http://www.linuxtv.org/hg/~hverkuil/v4l-dvb for the
following:
- v4l2-spec: add missing V4L2-PIX-FMT-STV0680 description.
Something went wrong here:
$ less /tmp/newpatches/hg_v4l-dvb_01.patch|diffstat -p1
linux/Documentation/DocBook/v4l/pixfmt.xml |5
linux/Documentation/DocBook/v4l/videodev2.h.xml | 1097
2 files changed, 554 insertions(+), 548 deletions(-)
Why a simple patch like this is changing 1097 lines at videodev2.h.xml?
I've applied it here, reverted the videodev2.h.xml and did a make -C
media-specs. The produced
changes at videodev2.h.xml were coherent...
Maybe you used the legacy v4l2-specs tree to make the driver?
IMO, we can remove it and the dvb-specs directories, since I don't see
much sense on keeping compiling the separate specs. Comments?
Cheers,
Mauro.
diff --git a/linux/Documentation/DocBook/v4l/pixfmt.xml
b/linux/Documentation/DocBook/v4l/pixfmt.xml
--- a/linux/Documentation/DocBook/v4l/pixfmt.xml
+++ b/linux/Documentation/DocBook/v4l/pixfmt.xml
@@ -770,6 +770,11 @@ kernel sources in the file filenameDoc
entry'S920'/entry
entryYUV 4:2:0 format of the gspca sn9c20x driver./entry
/row
+ row id=V4L2-PIX-FMT-STV0680
+ entryconstantV4L2_PIX_FMT_STV0680/constant/entry
+ entry'S680'/entry
+ entryBayer format of the gspca stv0680 driver./entry
+ /row
row id=V4L2-PIX-FMT-WNVA
entryconstantV4L2_PIX_FMT_WNVA/constant/entry
entry'WNVA'/entry
diff --git a/linux/Documentation/DocBook/v4l/videodev2.h.xml
b/linux/Documentation/DocBook/v4l/videodev2.h.xml
--- a/linux/Documentation/DocBook/v4l/videodev2.h.xml
+++ b/linux/Documentation/DocBook/v4l/videodev2.h.xml
@@ -363,6 +363,7 @@ struct link linkend=v4l2-pix-formatv
#define link linkend=V4L2-PIX-FMT-OV511V4L2_PIX_FMT_OV511/link
v4l2_fourcc('O', '5', '1', '1') /* ov511 JPEG */
#define link linkend=V4L2-PIX-FMT-OV518V4L2_PIX_FMT_OV518/link
v4l2_fourcc('O', '5', '1', '8') /* ov518 JPEG */
#define link linkend=V4L2-PIX-FMT-TM6000V4L2_PIX_FMT_TM6000/link
v4l2_fourcc('T', 'M', '6', '0') /* tm5600/tm60x0 */
+#define link linkend=V4L2-PIX-FMT-STV0680V4L2_PIX_FMT_STV0680/link
v4l2_fourcc('S', '6', '8', '0') /* stv0680 bayer */
/*
* F O R M A T E N U M E R A T I O N
--
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: [PULL] http://www.linuxtv.org/hg/~hverkuil/v4l-dvb
On Monday 23 November 2009 18:14:26 Mauro Carvalho Chehab wrote:
Mauro Carvalho Chehab wrote:
Hans Verkuil wrote:
Hi Mauro,
Please pull from http://www.linuxtv.org/hg/~hverkuil/v4l-dvb for the
following:
- v4l2-spec: add missing V4L2-PIX-FMT-STV0680 description.
Something went wrong here:
$ less /tmp/newpatches/hg_v4l-dvb_01.patch|diffstat -p1
linux/Documentation/DocBook/v4l/pixfmt.xml |5
linux/Documentation/DocBook/v4l/videodev2.h.xml | 1097
2 files changed, 554 insertions(+), 548
deletions(-)
Why a simple patch like this is changing 1097 lines at videodev2.h.xml?
I've applied it here, reverted the videodev2.h.xml and did a make -C
media-specs. The produced changes at videodev2.h.xml were coherent...
Maybe you used the legacy v4l2-specs tree to make the driver?
IMO, we can remove it and the dvb-specs directories, since I don't see
much sense on keeping compiling the separate specs. Comments?
I'm all for removing v4l2-specs and dvb-specs. These are only confusing
people.
Regarding the videodev2.h.xml: all those whitespace changes have to do with
the whitespace cleanups that 'make commit' does. When videodev2.h is changed,
'make spec' will regenerate videodev2.h.xml and 'make commit' will change that
xml file again by modifying all the whitespace. I think it would be good if
the whitespace checker script didn't mess with xml files. I don't know how
easy it is to change that script, though.
Regards,
Hans
Cheers,
Mauro.
diff --git a/linux/Documentation/DocBook/v4l/pixfmt.xml
b/linux/Documentation/DocBook/v4l/pixfmt.xml ---
a/linux/Documentation/DocBook/v4l/pixfmt.xml
+++ b/linux/Documentation/DocBook/v4l/pixfmt.xml
@@ -770,6 +770,11 @@ kernel sources in the file filenameDoc
entry'S920'/entry
entryYUV 4:2:0 format of the gspca sn9c20x driver./entry
/row
+ row id=V4L2-PIX-FMT-STV0680
+ entryconstantV4L2_PIX_FMT_STV0680/constant/entry
+ entry'S680'/entry
+ entryBayer format of the gspca stv0680 driver./entry
+ /row
row id=V4L2-PIX-FMT-WNVA
entryconstantV4L2_PIX_FMT_WNVA/constant/entry
entry'WNVA'/entry
diff --git a/linux/Documentation/DocBook/v4l/videodev2.h.xml
b/linux/Documentation/DocBook/v4l/videodev2.h.xml ---
a/linux/Documentation/DocBook/v4l/videodev2.h.xml
+++ b/linux/Documentation/DocBook/v4l/videodev2.h.xml
@@ -363,6 +363,7 @@ struct link linkend=v4l2-pix-formatv
#define link linkend=V4L2-PIX-FMT-OV511V4L2_PIX_FMT_OV511/link
v4l2_fourcc('O', '5', '1', '1') /* ov511 JPEG */ #define link
linkend=V4L2-PIX-FMT-OV518V4L2_PIX_FMT_OV518/linkv4l2_fourcc('O',
'5', '1', '8') /* ov518 JPEG */ #define link
linkend=V4L2-PIX-FMT-TM6000V4L2_PIX_FMT_TM6000/link
v4l2_fourcc('T', 'M', '6', '0') /* tm5600/tm60x0 */ +#define link
linkend=V4L2-PIX-FMT-STV0680V4L2_PIX_FMT_STV0680/link
v4l2_fourcc('S', '6', '8', '0') /* stv0680 bayer */
/*
* F O R M A T E N U M E R A T I O N
--
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: [PULL] http://www.linuxtv.org/hg/~hverkuil/v4l-dvb
Hans Verkuil wrote:
On Monday 23 November 2009 18:14:26 Mauro Carvalho Chehab wrote:
Mauro Carvalho Chehab wrote:
Hans Verkuil wrote:
Hi Mauro,
Please pull from http://www.linuxtv.org/hg/~hverkuil/v4l-dvb for the
following:
- v4l2-spec: add missing V4L2-PIX-FMT-STV0680 description.
Something went wrong here:
$ less /tmp/newpatches/hg_v4l-dvb_01.patch|diffstat -p1
linux/Documentation/DocBook/v4l/pixfmt.xml |5
linux/Documentation/DocBook/v4l/videodev2.h.xml | 1097
2 files changed, 554 insertions(+), 548
deletions(-)
Why a simple patch like this is changing 1097 lines at videodev2.h.xml?
I've applied it here, reverted the videodev2.h.xml and did a make -C
media-specs. The produced changes at videodev2.h.xml were coherent...
Maybe you used the legacy v4l2-specs tree to make the driver?
IMO, we can remove it and the dvb-specs directories, since I don't see
much sense on keeping compiling the separate specs. Comments?
I'm all for removing v4l2-specs and dvb-specs. These are only confusing
people.
Ok. I'll later prepare a patch for it.
Regarding the videodev2.h.xml: all those whitespace changes have to do with
the whitespace cleanups that 'make commit' does.
Hmm.. this is wrong for the generated xml files.
When videodev2.h is changed,
'make spec' will regenerate videodev2.h.xml and 'make commit' will change
that
xml file again by modifying all the whitespace. I think it would be good if
the whitespace checker script didn't mess with xml files. I don't know how
easy it is to change that script, though.
I haven't checked, but I suspect it shouldn't be hard to modify it to not handle
*.[ch].xml files.
While we don't fix it, please avoid committing such changes with make commit.
Regards,
Hans
Cheers,
Mauro.
diff --git a/linux/Documentation/DocBook/v4l/pixfmt.xml
b/linux/Documentation/DocBook/v4l/pixfmt.xml ---
a/linux/Documentation/DocBook/v4l/pixfmt.xml
+++ b/linux/Documentation/DocBook/v4l/pixfmt.xml
@@ -770,6 +770,11 @@ kernel sources in the file filenameDoc
entry'S920'/entry
entryYUV 4:2:0 format of the gspca sn9c20x driver./entry
/row
+ row id=V4L2-PIX-FMT-STV0680
+entryconstantV4L2_PIX_FMT_STV0680/constant/entry
+entry'S680'/entry
+entryBayer format of the gspca stv0680 driver./entry
+ /row
row id=V4L2-PIX-FMT-WNVA
entryconstantV4L2_PIX_FMT_WNVA/constant/entry
entry'WNVA'/entry
diff --git a/linux/Documentation/DocBook/v4l/videodev2.h.xml
b/linux/Documentation/DocBook/v4l/videodev2.h.xml ---
a/linux/Documentation/DocBook/v4l/videodev2.h.xml
+++ b/linux/Documentation/DocBook/v4l/videodev2.h.xml
@@ -363,6 +363,7 @@ struct link linkend=v4l2-pix-formatv
#define link linkend=V4L2-PIX-FMT-OV511V4L2_PIX_FMT_OV511/link
v4l2_fourcc('O', '5', '1', '1') /* ov511 JPEG */ #define link
linkend=V4L2-PIX-FMT-OV518V4L2_PIX_FMT_OV518/linkv4l2_fourcc('O',
'5', '1', '8') /* ov518 JPEG */ #define link
linkend=V4L2-PIX-FMT-TM6000V4L2_PIX_FMT_TM6000/link
v4l2_fourcc('T', 'M', '6', '0') /* tm5600/tm60x0 */ +#define link
linkend=V4L2-PIX-FMT-STV0680V4L2_PIX_FMT_STV0680/link
v4l2_fourcc('S', '6', '8', '0') /* stv0680 bayer */
/*
* F O R M A T E N U M E R A T I O N
--
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: [PULL] http://www.linuxtv.org/hg/~hverkuil/v4l-dvb-high-prio
Hans Verkuil wrote: Hi Mauro, As mentioned in my email High prio fixes for 2.6.32: urgent! I have made a tree with just the high-prio fixes: http://www.linuxtv.org/hg/~hverkuil/v4l-dvb-high-prio Ok, I merged from it. Please, be sure that you've removed those two patches from the other trees, otherwise hg will merge the patch again. Cheers, Mauro. -- 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: [PULL] http://www.linuxtv.org/hg/~hverkuil/v4l-dvb-high-prio
On Friday 20 November 2009 16:33:51 Mauro Carvalho Chehab wrote: Hans Verkuil wrote: Hi Mauro, As mentioned in my email High prio fixes for 2.6.32: urgent! I have made a tree with just the high-prio fixes: http://www.linuxtv.org/hg/~hverkuil/v4l-dvb-high-prio Ok, I merged from it. Please, be sure that you've removed those two patches from the other trees, otherwise hg will merge the patch again. I'll respin those trees and post new pull requests. Thanks for commiting these high-prio patches! Regards, Hans -- Hans Verkuil - video4linux developer - sponsored by TANDBERG -- 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: [PULL] http://www.linuxtv.org/hg/~hverkuil/v4l-dvb-staging
On Fri, Nov 20, 2009 at 4:45 PM, Hans Verkuil hverk...@xs4all.nl wrote: If there are drivers in the staging tree that are so unreliable that they can break the hardware, then those should be explicitly disabled, rather than disabling all drivers in the staging tree. Or perhaps do not belong there at all, or belong under the CONFIG_STAGING_BROKEN option. A driver like the go7007 is under active development, and it does work. It only needs more cleanup before it can be moved to drivers/media/video, so there was no reason that it should be disabled. Mauro, what are the risks of always compiling the tm6000 and cx25821 drivers? Let me know if you think that either one or both should be disabled for now and I'll make a patch for it. I'm certainly much more worried about the tm6000 stuff than the cx25821, primarily because the cx25821 is pretty rare and the tm6000 is used by several fairly popular consumer products, but is completely broken. I agree that we should be periodically ensuring the modules still compile, but I think that by default they should need to be explicitly enabled by a developer who knows what he/she is doing and understands the ramifications/risks. By not compiling you run the very high risk of bit rot: code getting seriously out-of-sync with the rest of the tree. Possibly requiring a lot of work later. Our tree is primarily for developers, not for end-users. So we need to see any code breakages as early as possible. Sure, in a perfect world that would be true. In reality though, I'm confident that a *huge* percentage of people who compile the v4l-dvb code have absolutely no idea what the hell they are doing. They are end-users who just want to see their device work because the changes haven't made it into their distro yet. I can certainly appreciate the concerns about the bit-rot issue. I am just worried that perhaps we set the bar too low in terms of what got into staging if it's going to be compiled by default. Devin -- Devin J. Heitmueller - Kernel Labs http://www.kernellabs.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: [PULL] http://www.linuxtv.org/hg/~hverkuil/v4l-dvb
On Mon, Aug 31, 2009 at 10:59:14PM +0200, ext Hans Verkuil wrote: Hi Mauro, Please pull from http://www.linuxtv.org/hg/~hverkuil/v4l-dvb for the following: - compat: don't build si4713 for kernels 2.6.26 - compat: don't build soc-camera modules for kernels 2.6.28. - si4713: simplify the code to remove a compiler warning. - cx25840: fix determining the firmware name The last one fixes this bug: https://bugzilla.redhat.com/show_bug.cgi?id=480728 Thanks, Hans diffstat: linux/drivers/media/radio/si4713-i2c.c | 17 ++--- On si4713-i2c.c behalf: Acked-by: Eduardo Valentin eduardo.valen...@nokia.com linux/drivers/media/video/cx25840/cx25840-firmware.c | 35 +++ v4l/versions.txt | 19 +++--- 3 files changed, 40 insertions(+), 31 deletions(-) -- Hans Verkuil - video4linux developer - sponsored by TANDBERG Telecom -- Eduardo Valentin -- 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: [PULL] http://www.linuxtv.org/hg/~hverkuil/v4l-dvb
Em Sun, 16 Aug 2009 15:24:51 +0200 Hans Verkuil hverk...@xs4all.nl escreveu: Hi Mauro, Please pull from http://www.linuxtv.org/hg/~hverkuil/v4l-dvb for the following: - v4l2-spec: document the new string control type. revnumber0.26/revnumber - date2009-06-15/date + date2009-07-23/date Hmm... No. Please create a new revision entry for it. + entry=0/entry + entry=1/entry + entry=0/entry Hmm... is it valid to use char outside a tag? maybe docbook may accept, but, IMHO, this is not recommended (or allowed) on XML specs. Anyway, it is probably better to use an escape sequence like gt; instead of above as used on other parts of the document, or, even better: ge; for greater or equal to. - v4l2-spec: Add documentation description for FM TX extended control class There's also a missing revision tag for it. As both changes will be merged together, you can increment it by just one (to 0.29), provided that both changes are properly documented at the revision tag. Except for those, the series looks ok to my eyes. Cheers, Mauro -- 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: [PULL] http://www.linuxtv.org/hg/~hverkuil/v4l-dvb
On Wednesday 26 August 2009 21:16:53 Mauro Carvalho Chehab wrote: Em Sun, 16 Aug 2009 15:24:51 +0200 Hans Verkuil hverk...@xs4all.nl escreveu: Hi Mauro, Please pull from http://www.linuxtv.org/hg/~hverkuil/v4l-dvb for the following: - v4l2-spec: document the new string control type. revnumber0.26/revnumber - date2009-06-15/date + date2009-07-23/date Hmm... No. Please create a new revision entry for it. Why? IMHO the revision only changes for each new kernel release. The spec documents the V4L2 API as is appears in a certain kernel. It's similar in that respect to the kernel's version number: that also only changes with each new kernel release. And furthermore, that's the way the version number was handled in the past as well. I did toy with the idea in the past to bump this version number to be in sync with the kernel: i.e. since this spec documents the upcoming 2.6.32 kernel the version should be 0.32 as well. That makes the link between spec and kernel more explicit. + entry=0/entry + entry=1/entry + entry=0/entry Hmm... is it valid to use char outside a tag? maybe docbook may accept, but, IMHO, this is not recommended (or allowed) on XML specs. Anyway, it is probably better to use an escape sequence like gt; instead of above as used on other parts of the document, or, even better: ge; for greater or equal to. Good point, I'll update this. - v4l2-spec: Add documentation description for FM TX extended control class There's also a missing revision tag for it. As both changes will be merged together, you can increment it by just one (to 0.29), provided that both changes are properly documented at the revision tag. Except for those, the series looks ok to my eyes. I'll wait for your clarification on the spec's version number and then I'll make this final small change and post a new pull request. Regards, Hans -- Hans Verkuil - video4linux developer - sponsored by TANDBERG Telecom -- 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: [PULL] http://www.linuxtv.org/hg/~hverkuil/v4l-dvb
Em Wed, 26 Aug 2009 21:35:59 +0200 Hans Verkuil hverk...@xs4all.nl escreveu: On Wednesday 26 August 2009 21:16:53 Mauro Carvalho Chehab wrote: Em Sun, 16 Aug 2009 15:24:51 +0200 Hans Verkuil hverk...@xs4all.nl escreveu: Hi Mauro, Please pull from http://www.linuxtv.org/hg/~hverkuil/v4l-dvb for the following: - v4l2-spec: document the new string control type. revnumber0.26/revnumber - date2009-06-15/date + date2009-07-23/date Hmm... No. Please create a new revision entry for it. Why? IMHO the revision only changes for each new kernel release. The spec documents the V4L2 API as is appears in a certain kernel. It's similar in that respect to the kernel's version number: that also only changes with each new kernel release. And furthermore, that's the way the version number was handled in the past as well. I did toy with the idea in the past to bump this version number to be in sync with the kernel: i.e. since this spec documents the upcoming 2.6.32 kernel the version should be 0.32 as well. That makes the link between spec and kernel more explicit. Hmm... This is a good idea, but then, IMO, the better is to just jump the API version to 2.32 - or - even better - to 2.6.32. This will avoid any further sync issues in the future. Anyway, we had several changes at the spec between the last version and the 2.6.32 version (at least 3 of them having a revision increment). + entry=0/entry + entry=1/entry + entry=0/entry Hmm... is it valid to use char outside a tag? maybe docbook may accept, but, IMHO, this is not recommended (or allowed) on XML specs. Anyway, it is probably better to use an escape sequence like gt; instead of above as used on other parts of the document, or, even better: ge; for greater or equal to. Good point, I'll update this. - v4l2-spec: Add documentation description for FM TX extended control class There's also a missing revision tag for it. As both changes will be merged together, you can increment it by just one (to 0.29), provided that both changes are properly documented at the revision tag. Except for those, the series looks ok to my eyes. I'll wait for your clarification on the spec's version number and then I'll make this final small change and post a new pull request. Hmm... I tried to reach you at IRC. As you weren't there anymore, I've assumed you've already sleeping ;) As I want to finish the pending PULL requests today, I've merged it as-is (just removing the revision update hunk) and added a patch at the end of the series properly fixing the docs, and including the proper changes documentation at compat.sgml. Cheers, Mauro -- 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: [PULL] http://www.linuxtv.org/hg/~hverkuil/v4l-dvb
On Wednesday 26 August 2009 22:06:20 Mauro Carvalho Chehab wrote: Em Wed, 26 Aug 2009 21:35:59 +0200 Hans Verkuil hverk...@xs4all.nl escreveu: On Wednesday 26 August 2009 21:16:53 Mauro Carvalho Chehab wrote: Em Sun, 16 Aug 2009 15:24:51 +0200 Hans Verkuil hverk...@xs4all.nl escreveu: Hi Mauro, Please pull from http://www.linuxtv.org/hg/~hverkuil/v4l-dvb for the following: - v4l2-spec: document the new string control type. revnumber0.26/revnumber - date2009-06-15/date + date2009-07-23/date Hmm... No. Please create a new revision entry for it. Why? IMHO the revision only changes for each new kernel release. The spec documents the V4L2 API as is appears in a certain kernel. It's similar in that respect to the kernel's version number: that also only changes with each new kernel release. And furthermore, that's the way the version number was handled in the past as well. I did toy with the idea in the past to bump this version number to be in sync with the kernel: i.e. since this spec documents the upcoming 2.6.32 kernel the version should be 0.32 as well. That makes the link between spec and kernel more explicit. Hmm... This is a good idea, but then, IMO, the better is to just jump the API version to 2.32 - or - even better - to 2.6.32. This will avoid any further sync issues in the future. I think tracking the kernel version number (i.e. 2.6.32) is a good idea. Anyway, we had several changes at the spec between the last version and the 2.6.32 version (at least 3 of them having a revision increment). + entry=0/entry + entry=1/entry + entry=0/entry Hmm... is it valid to use char outside a tag? maybe docbook may accept, but, IMHO, this is not recommended (or allowed) on XML specs. Anyway, it is probably better to use an escape sequence like gt; instead of above as used on other parts of the document, or, even better: ge; for greater or equal to. Good point, I'll update this. - v4l2-spec: Add documentation description for FM TX extended control class There's also a missing revision tag for it. As both changes will be merged together, you can increment it by just one (to 0.29), provided that both changes are properly documented at the revision tag. Except for those, the series looks ok to my eyes. I'll wait for your clarification on the spec's version number and then I'll make this final small change and post a new pull request. Hmm... I tried to reach you at IRC. For future reference: I'm generally only on irc during working hours. If you want to discuss something on irc in the evening then just mail me and I will usually appear within 30-60 minutes as I tend to keep an eye on my email during the evening. As you weren't there anymore, I've assumed you've already sleeping ;) As I want to finish the pending PULL requests today, I've merged it as-is (just removing the revision update hunk) and added a patch at the end of the series properly fixing the docs, and including the proper changes documentation at compat.sgml. Excellent, I'm very glad to see this series merged. It was a lot of fun working with Eduardo on this very first radio modulator and RDS encoder driver! Eduardo, thank you for your hard work on this! Regards, Hans -- Hans Verkuil - video4linux developer - sponsored by TANDBERG Telecom -- 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: [PULL] http://www.linuxtv.org/hg/~hverkuil/v4l-dvb-core2
Hi Mauro On Sun, 23 Aug 2009, Mauro Carvalho Chehab wrote: Em Mon, 17 Aug 2009 08:26:28 +0200 (CEST) Guennadi Liakhovetski g.liakhovet...@gmx.de escreveu: ...speaking about which, we should at some point start merging the soc-camera patch stack, which, however, requires some patches that are currently in next. Shall we pull those into the hg trees with the kernel-sync tag? Yes, that's fine. The only issue then is, that we will have to remember to push the patches to Linus in the 2.6.32 merge window after those 3 patches are there. The patches update 3 PXA platforms to the new soc-camera API. Ok. please put Priority: low on those patches. My scripts will put this at the pending tree, where I have already the DaVinci patches. They also have the same kind of restriction. So, I'll delay the pending -git tree to be sent after having the arch patches merged Ok, good, now, is there a git kernel tree to which I could rebase? If the current development tree is so far only available in hg, could you maybe push it into some git branch somewhere or just produce a patch series? 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: [PULL] http://www.linuxtv.org/hg/~hverkuil/v4l-dvb-core2
Em Mon, 24 Aug 2009 18:26:10 +0200 (CEST) Guennadi Liakhovetski g.liakhovet...@gmx.de escreveu: Hi Mauro On Sun, 23 Aug 2009, Mauro Carvalho Chehab wrote: Em Mon, 17 Aug 2009 08:26:28 +0200 (CEST) Guennadi Liakhovetski g.liakhovet...@gmx.de escreveu: ...speaking about which, we should at some point start merging the soc-camera patch stack, which, however, requires some patches that are currently in next. Shall we pull those into the hg trees with the kernel-sync tag? Yes, that's fine. The only issue then is, that we will have to remember to push the patches to Linus in the 2.6.32 merge window after those 3 patches are there. The patches update 3 PXA platforms to the new soc-camera API. Ok. please put Priority: low on those patches. My scripts will put this at the pending tree, where I have already the DaVinci patches. They also have the same kind of restriction. So, I'll delay the pending -git tree to be sent after having the arch patches merged Ok, good, now, is there a git kernel tree to which I could rebase? If the current development tree is so far only available in hg, could you maybe push it into some git branch somewhere or just produce a patch series? You may use my linux-next tree. Be warned that I almost always rebase it, due to our (broken) upstream proccess of using an -hg tree. I used to push also the devel tree upstream, but, as sometimes I was needing to rebase (less often than linux-next, but still often), I've dropped it, since rebasing is very bad for kernel.org mirrors, so I've minimized the problem by just pushing my trees when I'm about to ask a merge. Thanks Guennadi --- Guennadi Liakhovetski, Ph.D. Freelance Open-Source Software Developer http://www.open-technology.de/ Cheers, Mauro -- 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: [PULL] http://www.linuxtv.org/hg/~hverkuil/v4l-dvb
On Sunday 16 August 2009 15:24:51 Hans Verkuil wrote: Hi Mauro, Please pull from http://www.linuxtv.org/hg/~hverkuil/v4l-dvb for the following: - v4l: introduce string control support. - v4l2-spec: document the new string control type. - v4l2-ctl: modulator bug fixes - v4l2-ctl: add support for string controls - v4l2-subdev.h: Add g/s_modulator callbacks to subdev api - v4l2: video device: Add V4L2_CTRL_CLASS_FM_TX controls - v4l2: video device: Add FM TX controls default configurations - v4l2-spec: Add documentation description for FM TX extended control class - FM TX: si4713: Add files to add radio interface for si4713 - FM TX: si4713: Add files to handle si4713 i2c device - FM TX: si4713: Add Kconfig and Makefile entries - FM TX: si4713: Add document file Hi Mauro, Any idea when this might be merged? Regards, Hans Same series as before except for the following changes: - the FM_TX control IDs have been renumbered to leave room for future control additions to the various 'subsections': RDS, audio limiter, audio compression, pilot tone and tune properties. - the compat32 code for extended controls has been reworked a bit as my first code to copy string pointers was incorrect. I've verified that this version works on my 64-bit machine. The ctrl_is_pointer() function is still there. It will be possible to remove it once we integrate control handling in the v4l2 framework. I'm currently testing out my control code on the cx18 driver which uses the cx2341x.c module that has by far the most complex control code in v4l-dvb. So if the framework can handle that, then it can handle anything :-) Thanks, Hans diffstat: b/linux/Documentation/video4linux/si4713.txt| 176 ++ b/linux/drivers/media/radio/radio-si4713.c | 367 b/linux/drivers/media/radio/si4713-i2c.c| 2067 b/linux/drivers/media/radio/si4713-i2c.h | 237 ++ b/linux/include/media/radio-si4713.h| 30 b/linux/include/media/si4713.h | 49 linux/drivers/media/radio/Kconfig | 23 linux/drivers/media/radio/Makefile |2 linux/drivers/media/video/v4l2-common.c | 52 linux/drivers/media/video/v4l2-compat-ioctl32.c | 79 linux/drivers/media/video/v4l2-ioctl.c | 10 linux/include/linux/videodev2.h | 40 linux/include/media/v4l2-subdev.h |2 v4l2-apps/util/v4l2-ctl.cpp | 257 +- v4l2-spec/Makefile |2 v4l2-spec/compat.sgml |3 v4l2-spec/controls.sgml | 220 ++ v4l2-spec/v4l2.sgml |4 v4l2-spec/vidioc-g-ext-ctrls.sgml | 79 v4l2-spec/vidioc-queryctrl.sgml | 42 20 files changed, 3588 insertions(+), 153 deletions(-) -- Hans Verkuil - video4linux developer - sponsored by TANDBERG -- 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: [PULL] http://www.linuxtv.org/hg/~hverkuil/v4l-dvb
Em Sun, 23 Aug 2009 21:33:43 +0200 Hans Verkuil hverk...@xs4all.nl escreveu: On Sunday 16 August 2009 15:24:51 Hans Verkuil wrote: Hi Mauro, Please pull from http://www.linuxtv.org/hg/~hverkuil/v4l-dvb for the following: - v4l: introduce string control support. - v4l2-spec: document the new string control type. - v4l2-ctl: modulator bug fixes - v4l2-ctl: add support for string controls - v4l2-subdev.h: Add g/s_modulator callbacks to subdev api - v4l2: video device: Add V4L2_CTRL_CLASS_FM_TX controls - v4l2: video device: Add FM TX controls default configurations - v4l2-spec: Add documentation description for FM TX extended control class - FM TX: si4713: Add files to add radio interface for si4713 - FM TX: si4713: Add files to handle si4713 i2c device - FM TX: si4713: Add Kconfig and Makefile entries - FM TX: si4713: Add document file Hi Mauro, Any idea when this might be merged? I was expecting to have some time during this weekend to work on it, but my I hadn't enough time, and my Internet connection was very unstable today (and a downtime at infradead.org). I'll seek for some time during the week to better examine this changeset. Cheers, Mauro -- 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: [PULL] http://www.linuxtv.org/hg/~hverkuil/v4l-dvb-core2
Em Sun, 23 Aug 2009 21:35:29 +0200 Hans Verkuil hverk...@xs4all.nl escreveu: On Monday 17 August 2009 08:19:51 Hans Verkuil wrote: On Monday 17 August 2009 02:49:01 Mauro Carvalho Chehab wrote: Em Sat, 15 Aug 2009 11:18:20 +0200 Hans Verkuil hverk...@xs4all.nl escreveu: On Saturday 15 August 2009 10:59:19 Hans Verkuil wrote: On Tuesday 11 August 2009 08:35:47 Hans Verkuil wrote: Hi Mauro, Please pull from http://www.linuxtv.org/hg/~hverkuil/v4l-dvb-core2 for the following: - v4l: simplify v4l2_i2c_new_subdev and friends - v4l: remove video_register_device_index The first patch simplifies v4l2_i2c_new_subdev and removes v4l2_i2c_new_probed_subdev and v4l2_i2c_new_probed_subdev_addr. This was initially proposed for inclusion in 2.6.31 but that was considered too soon. I think it is now a good time to merge this so this will go into 2.6.32. The second patch removes the unused video_register_device_index function. This patch is part of a larger series of patches I'm working on to improve v4l2-dev.c. But since this patch is pretty straightforward I like to get this one in first. Mauro, Please disregard this pull request. I've found a serious bug that needs to be resolved first. OK, that was a false alarm. It's working fine after all so it's safe to pull this tree. Sorry for the confusion. The patches look fine to me. Yet, I see two merge conflict issues: 1) if a latter patch needs to touch at the subdev probing sequence to fix a bug, it will conflict with this patch, meaning that we'll have merge troubles on this tree and at my -git devel, linux-next and linux-2.6; 2) as Guennadi is converting soc_camera to v4l2 dev/subdev, this patch may conflict with his patch series. Due to that, I prefer to keep holding it until the beginning of the next merge window, since, if a merge conflict would rise, it would be just at -hg, instead of having it at the 4 trees. I thought things were pretty stable by now since we reached -rc6. And we have seen no bugs at all with respect to the subdev API. The disadvantage of waiting that long is that this patch has had no testing in v4l-dvb but goes straight into the mainline. I personally prefer to have it in earlier so it gets a few weeks testing before the merge window opens. Anyway, that's just my opinion. In the meantime, can you at least merge the second patch (remove video_register_device_index)? I can make a new tree if you don't want to cherry-pick it. Hi Mauro, Do you want me to make a new tree, or can you cherry-pick? I would like to prepare some more core cleanups to make the code more understandable, but it's much easier to do that if this second patch is merged first. I did an effort to cleanup the patchwork patches on friday, since I wanted to merge everything else before this API change. There are still a few work there to be handled, but as far as I noticed, none will be affected by this series. Yet, I intend to handle the remaining ones before applying this series. The only pending work I'm aware of that could be affected are the Guennadi's patches. As we are already at -rc7, it is probably time to thing on merging this series. So, after receiving his series, I intend to merge this tree probably during this week. If you have any priority: high patch, please apply on another tree and ask me to pull Cheers, Mauro -- 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: [PULL] http://www.linuxtv.org/hg/~hverkuil/v4l-dvb-core2
On Monday 17 August 2009 02:49:01 Mauro Carvalho Chehab wrote: Em Sat, 15 Aug 2009 11:18:20 +0200 Hans Verkuil hverk...@xs4all.nl escreveu: On Saturday 15 August 2009 10:59:19 Hans Verkuil wrote: On Tuesday 11 August 2009 08:35:47 Hans Verkuil wrote: Hi Mauro, Please pull from http://www.linuxtv.org/hg/~hverkuil/v4l-dvb-core2 for the following: - v4l: simplify v4l2_i2c_new_subdev and friends - v4l: remove video_register_device_index The first patch simplifies v4l2_i2c_new_subdev and removes v4l2_i2c_new_probed_subdev and v4l2_i2c_new_probed_subdev_addr. This was initially proposed for inclusion in 2.6.31 but that was considered too soon. I think it is now a good time to merge this so this will go into 2.6.32. The second patch removes the unused video_register_device_index function. This patch is part of a larger series of patches I'm working on to improve v4l2-dev.c. But since this patch is pretty straightforward I like to get this one in first. Mauro, Please disregard this pull request. I've found a serious bug that needs to be resolved first. OK, that was a false alarm. It's working fine after all so it's safe to pull this tree. Sorry for the confusion. The patches look fine to me. Yet, I see two merge conflict issues: 1) if a latter patch needs to touch at the subdev probing sequence to fix a bug, it will conflict with this patch, meaning that we'll have merge troubles on this tree and at my -git devel, linux-next and linux-2.6; 2) as Guennadi is converting soc_camera to v4l2 dev/subdev, this patch may conflict with his patch series. Due to that, I prefer to keep holding it until the beginning of the next merge window, since, if a merge conflict would rise, it would be just at -hg, instead of having it at the 4 trees. I thought things were pretty stable by now since we reached -rc6. And we have seen no bugs at all with respect to the subdev API. The disadvantage of waiting that long is that this patch has had no testing in v4l-dvb but goes straight into the mainline. I personally prefer to have it in earlier so it gets a few weeks testing before the merge window opens. Anyway, that's just my opinion. In the meantime, can you at least merge the second patch (remove video_register_device_index)? I can make a new tree if you don't want to cherry-pick it. Regards, Hans -- Hans Verkuil - video4linux developer - sponsored by TANDBERG Telecom -- 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: [PULL] http://www.linuxtv.org/hg/~hverkuil/v4l-dvb-core2
On Sun, 16 Aug 2009, Mauro Carvalho Chehab wrote: The patches look fine to me. Yet, I see two merge conflict issues: 1) if a latter patch needs to touch at the subdev probing sequence to fix a bug, it will conflict with this patch, meaning that we'll have merge troubles on this tree and at my -git devel, linux-next and linux-2.6; 2) as Guennadi is converting soc_camera to v4l2 dev/subdev, this patch may conflict with his patch series. ...speaking about which, we should at some point start merging the soc-camera patch stack, which, however, requires some patches that are currently in next. Shall we pull those into the hg trees with the kernel-sync tag? The only issue then is, that we will have to remember to push the patches to Linus in the 2.6.32 merge window after those 3 patches are there. The patches update 3 PXA platforms to the new soc-camera API. Due to that, I prefer to keep holding it until the beginning of the next merge window, since, if a merge conflict would rise, it would be just at -hg, instead of having it at the 4 trees. 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: [PULL] http://www.linuxtv.org/hg/~hverkuil/v4l-dvb-core2
Em Sat, 15 Aug 2009 11:18:20 +0200 Hans Verkuil hverk...@xs4all.nl escreveu: On Saturday 15 August 2009 10:59:19 Hans Verkuil wrote: On Tuesday 11 August 2009 08:35:47 Hans Verkuil wrote: Hi Mauro, Please pull from http://www.linuxtv.org/hg/~hverkuil/v4l-dvb-core2 for the following: - v4l: simplify v4l2_i2c_new_subdev and friends - v4l: remove video_register_device_index The first patch simplifies v4l2_i2c_new_subdev and removes v4l2_i2c_new_probed_subdev and v4l2_i2c_new_probed_subdev_addr. This was initially proposed for inclusion in 2.6.31 but that was considered too soon. I think it is now a good time to merge this so this will go into 2.6.32. The second patch removes the unused video_register_device_index function. This patch is part of a larger series of patches I'm working on to improve v4l2-dev.c. But since this patch is pretty straightforward I like to get this one in first. Mauro, Please disregard this pull request. I've found a serious bug that needs to be resolved first. OK, that was a false alarm. It's working fine after all so it's safe to pull this tree. Sorry for the confusion. The patches look fine to me. Yet, I see two merge conflict issues: 1) if a latter patch needs to touch at the subdev probing sequence to fix a bug, it will conflict with this patch, meaning that we'll have merge troubles on this tree and at my -git devel, linux-next and linux-2.6; 2) as Guennadi is converting soc_camera to v4l2 dev/subdev, this patch may conflict with his patch series. Due to that, I prefer to keep holding it until the beginning of the next merge window, since, if a merge conflict would rise, it would be just at -hg, instead of having it at the 4 trees. Cheers, Mauro -- 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: [PULL] http://www.linuxtv.org/hg/~hverkuil/v4l-dvb-core2
On Tuesday 11 August 2009 08:35:47 Hans Verkuil wrote: Hi Mauro, Please pull from http://www.linuxtv.org/hg/~hverkuil/v4l-dvb-core2 for the following: - v4l: simplify v4l2_i2c_new_subdev and friends - v4l: remove video_register_device_index The first patch simplifies v4l2_i2c_new_subdev and removes v4l2_i2c_new_probed_subdev and v4l2_i2c_new_probed_subdev_addr. This was initially proposed for inclusion in 2.6.31 but that was considered too soon. I think it is now a good time to merge this so this will go into 2.6.32. The second patch removes the unused video_register_device_index function. This patch is part of a larger series of patches I'm working on to improve v4l2-dev.c. But since this patch is pretty straightforward I like to get this one in first. Mauro, Please disregard this pull request. I've found a serious bug that needs to be resolved first. Regards, Hans Thanks, Hans diffstat: Documentation/video4linux/v4l2-framework.txt | 33 + drivers/media/video/au0828/au0828-cards.c |4 drivers/media/video/bt8xx/bttv-cards.c| 44 +++ drivers/media/video/cafe_ccic.c |2 drivers/media/video/cx18/cx18-i2c.c | 14 +- drivers/media/video/cx231xx/cx231xx-cards.c |4 drivers/media/video/cx23885/cx23885-cards.c |2 drivers/media/video/cx23885/cx23885-video.c |6 drivers/media/video/cx88/cx88-cards.c | 14 +- drivers/media/video/cx88/cx88-video.c |6 drivers/media/video/davinci/vpif_display.c|4 drivers/media/video/em28xx/em28xx-cards.c | 34 ++--- drivers/media/video/ivtv/ivtv-i2c.c | 18 +- drivers/media/video/mxb.c | 14 +- drivers/media/video/pvrusb2/pvrusb2-hdw.c | 10 - drivers/media/video/saa7134/saa7134-cards.c | 12 - drivers/media/video/saa7134/saa7134-core.c|6 drivers/media/video/usbvision/usbvision-i2c.c | 12 - drivers/media/video/v4l2-common.c | 157 -- drivers/media/video/v4l2-dev.c| 55 ++--- drivers/media/video/vino.c|8 - drivers/media/video/w9968cf.c |4 drivers/media/video/zoran/zoran_card.c|8 - include/media/v4l2-common.h | 30 +--- include/media/v4l2-dev.h |2 25 files changed, 151 insertions(+), 352 deletions(-) -- Hans Verkuil - video4linux developer - sponsored by TANDBERG Telecom -- 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: [PULL] http://www.linuxtv.org/hg/~hverkuil/v4l-dvb-core2
On Saturday 15 August 2009 10:59:19 Hans Verkuil wrote: On Tuesday 11 August 2009 08:35:47 Hans Verkuil wrote: Hi Mauro, Please pull from http://www.linuxtv.org/hg/~hverkuil/v4l-dvb-core2 for the following: - v4l: simplify v4l2_i2c_new_subdev and friends - v4l: remove video_register_device_index The first patch simplifies v4l2_i2c_new_subdev and removes v4l2_i2c_new_probed_subdev and v4l2_i2c_new_probed_subdev_addr. This was initially proposed for inclusion in 2.6.31 but that was considered too soon. I think it is now a good time to merge this so this will go into 2.6.32. The second patch removes the unused video_register_device_index function. This patch is part of a larger series of patches I'm working on to improve v4l2-dev.c. But since this patch is pretty straightforward I like to get this one in first. Mauro, Please disregard this pull request. I've found a serious bug that needs to be resolved first. OK, that was a false alarm. It's working fine after all so it's safe to pull this tree. Sorry for the confusion. Regards, Hans -- Hans Verkuil - video4linux developer - sponsored by TANDBERG Telecom -- 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: [PULL] http://www.linuxtv.org/hg/~hverkuil/v4l-dvb
On Wednesday 12 August 2009 03:05:28 Mauro Carvalho Chehab wrote: Em Tue, 11 Aug 2009 17:08:27 +0200 Hans Verkuil hverk...@xs4all.nl escreveu: I also agree with Trent that, instead of having to maintain some sort of list or code to identify string controls, the better would be to reserve one bit to indicate pointer controls (like bit 31). People tend to forget about v4l2-compat32 layer, and I bet that, if we do some sort of list, people will forget to update it when adding a new control, and compat32 layer will break. So, ctrl_is_pointer() can be just: #define ctrl_is_pointer(id) (id (1 31)) Now THAT is ugly. Anyway, you can't do it like that. Control IDs are not random but are grouped in control classes so that similar controls are together when you enumerate them. Adding flags to mark it as a specific type is 1) an ugly hack to work around an infrastructure problem, and 2) will make it impossible to group string controls together with controls that have a similar purpose. You just need to create separate groups for strings. As there are very few cases where passing a string to a control is valid, I don't see this as a big issue. Yes it is. You are moving strings into a separate class for no good reason. Why would RDS-related controls be split over two control classes? That makes not sense whatsoever. I absolutely categorically refuse to do something like that. The point here is that compat layer adds an extra parsing time, since it needs to repeat what is done later at v4l2-ioctl. That's said, once we have all drivers migrated to use video_ioctl2, we can work on optimizing it by removing the compat layer parser from it and letting this job to be done after parsed, at v4l2-ioctl. This will help to save the costs added by this layer. The root of all evil is premature optimization. You are trying to fix something that isn't a problem. There are no performance issues with any of the V4L2 APIs. We have complexity problems, making it hard to write drivers and, in some cases, applications (inconsistent control handling is IMHO a big problem for applications). What should have happened is that we could test whether the size field is non-zero. Unfortunately, some apps do not set that field (currently a reserved field) to 0 and we never checked that in the kernel. So sadly we have to do it another way. It is not a Kernel task to check if the userspace is bad coded. If the userspace apps are not respecting V4L2 API by not zeroing the reserved fields, they need to be fixed, or they'll break sooner or later. What applications are know to break with such change? Both mythtv and mplayer. vlc is OK. And yes, we should have checked. We check other arguments as well, so if we require that reserved should be zeroed, then we should check that as well. If we had done that, then I could have just checked the 'size' value. Also note that it is very likely that these two functions will disappear again in a few months: once the v4l framework has proper control support these functions should no longer be needed since this information can then be obtained directly from the framework. This don't change the fact that you'll need a sort of list or code that associates a control id with a type, called by the compat layer. Testing for a bit costs less than any table seek method. O(log N) where N is the number of registered controls. It's implemented as a binary search. It is generic and will work with whatever types we might create in the future. Since you'll probably need to run it again when parsing the control code at the framework, it will be, in fact, doubled, since you'll need to run this code twice. On the other hand, a bit seek or a a test if size is zero is O(0) And when the framework is in place then all the O(N) comparisons that are currently used in drivers to lookup the controls are also replaced by O(log N). Of course, let's not forget the usual end-result of these ioctls: an i2c read or write: these are orders of magnitudes slower than anything else we are doing. I'm NOT going to fuck with the API just to shave of that single nanosecond of performance that you get when using extended controls running a 32-bit app in a 64 bit OS. As an alternative, I'm willing to make patches for mplayer and mythtv. Then we can check whether size is non-zero. Of course, this will break using extended controls in a 32-bit app in a 64-bit OS as long as these updated apps are not available upstream. I'm personally not willing to risk that just for that single nanosecond. Regards, Hans -- Hans Verkuil - video4linux developer - sponsored by TANDBERG Telecom -- 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: [PULL] http://www.linuxtv.org/hg/~hverkuil/v4l-dvb
Hi Mauro,
Em Thu, 6 Aug 2009 22:04:13 +0200
Hans Verkuil hverk...@xs4all.nl escreveu:
Hi Mauro,
Please pull from http://www.linuxtv.org/hg/~hverkuil/v4l-dvb for the
following:
- v4l: introduce string control support.
- v4l2-spec: document the new string control type.
- v4l2-ctl: modulator bug fixes
- v4l2-ctl: add support for string controls
It's the same as the previous version, except for reverting the variable
renaming and for improving the comments above the ctrl_is_value64 and
ctrl_is_pointer functions. I've decided to keep the ctrl_is_value64()
function because I want to keep the correct value64 conversion code in
compat32 rather than having to do that work again at some point in the
future.
I agree with Trent, this really sucks:
static inline int ctrl_is_value64(u32 id)
{
- return 0;
+ switch (id) {
+ case V4L2_CID_RDS_TX_PS_NAME:
+ case V4L2_CID_RDS_TX_RADIO_TEXT:
+ return 1;
+ default:
+ return 0;
+ }
}
Yet, by looking on how the struct is defined:
struct v4l2_ext_control {
__u32 id;
__u32 reserved2[2];
union {
__s32 value;
__s64 value64;
void *reserved;
};
} __attribute__ ((packed));
Except on the strings case, I don't see why we need a compat stuff for
this
routine at the first place, copying field by field. Correct me if I'm
wrong,
but, on both 32 and 64 bit cases, the fields will be at the same position
on
both 32 and 64 bits. So, the code could be just:
copy_in_user(kcontrols, ucontrols, sizeof(ucontrols));
if (ctrl_is_pointer(id)) {
/* get_user/compat_ptr magic */
}
OK, makes sense.
I also agree with Trent that, instead of having to maintain some sort of
list
or code to identify string controls, the better would be to reserve one
bit to
indicate pointer controls (like bit 31). People tend to forget about
v4l2-compat32 layer, and I bet that, if we do some sort of list, people
will
forget to update it when adding a new control, and compat32 layer will
break.
So, ctrl_is_pointer() can be just:
#define ctrl_is_pointer(id) (id (1 31))
Now THAT is ugly. Anyway, you can't do it like that. Control IDs are not
random but are grouped in control classes so that similar controls are
together when you enumerate them. Adding flags to mark it as a specific
type is 1) an ugly hack to work around an infrastructure problem, and 2)
will make it impossible to group string controls together with controls
that have a similar purpose.
Anyway, I've started working on a proper control handling framework that
will make it possible for the compat module to query the type. That will
solve this. But that probably won't be ready for the upcoming 2.6.32,
while the si4713 is ready right now.
What should have happened is that we could test whether the size field is
non-zero. Unfortunately, some apps do not set that field (currently a
reserved field) to 0 and we never checked that in the kernel. So sadly we
have to do it another way.
Also note that it is very likely that these two functions will disappear
again in a few months: once the v4l framework has proper control support
these functions should no longer be needed since this information can
then be obtained directly from the framework.
This don't change the fact that you'll need a sort of list or code that
associates a control id with a type, called by the compat layer. Testing
for a
bit costs less than any table seek method.
O(log N) where N is the number of registered controls. It's implemented as
a binary search. It is generic and will work with whatever types we might
create in the future.
I will prepare a new pull request where I use copy_in_user.
Regards,
Hans
--
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: [PULL] http://www.linuxtv.org/hg/~hverkuil/v4l-dvb
Em Tue, 11 Aug 2009 17:08:27 +0200 Hans Verkuil hverk...@xs4all.nl escreveu: I also agree with Trent that, instead of having to maintain some sort of list or code to identify string controls, the better would be to reserve one bit to indicate pointer controls (like bit 31). People tend to forget about v4l2-compat32 layer, and I bet that, if we do some sort of list, people will forget to update it when adding a new control, and compat32 layer will break. So, ctrl_is_pointer() can be just: #define ctrl_is_pointer(id) (id (1 31)) Now THAT is ugly. Anyway, you can't do it like that. Control IDs are not random but are grouped in control classes so that similar controls are together when you enumerate them. Adding flags to mark it as a specific type is 1) an ugly hack to work around an infrastructure problem, and 2) will make it impossible to group string controls together with controls that have a similar purpose. You just need to create separate groups for strings. As there are very few cases where passing a string to a control is valid, I don't see this as a big issue. The point here is that compat layer adds an extra parsing time, since it needs to repeat what is done later at v4l2-ioctl. That's said, once we have all drivers migrated to use video_ioctl2, we can work on optimizing it by removing the compat layer parser from it and letting this job to be done after parsed, at v4l2-ioctl. This will help to save the costs added by this layer. What should have happened is that we could test whether the size field is non-zero. Unfortunately, some apps do not set that field (currently a reserved field) to 0 and we never checked that in the kernel. So sadly we have to do it another way. It is not a Kernel task to check if the userspace is bad coded. If the userspace apps are not respecting V4L2 API by not zeroing the reserved fields, they need to be fixed, or they'll break sooner or later. What applications are know to break with such change? Also note that it is very likely that these two functions will disappear again in a few months: once the v4l framework has proper control support these functions should no longer be needed since this information can then be obtained directly from the framework. This don't change the fact that you'll need a sort of list or code that associates a control id with a type, called by the compat layer. Testing for a bit costs less than any table seek method. O(log N) where N is the number of registered controls. It's implemented as a binary search. It is generic and will work with whatever types we might create in the future. Since you'll probably need to run it again when parsing the control code at the framework, it will be, in fact, doubled, since you'll need to run this code twice. On the other hand, a bit seek or a a test if size is zero is O(0) Cheers, Mauro -- 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: [PULL] http://www.linuxtv.org/hg/~hverkuil/v4l-dvb-misc
Acked-By: Mike Isely is...@pobox.com -Mike On Fri, 7 Aug 2009, Hans Verkuil wrote: Hi Mauro, Please pull from http://www.linuxtv.org/hg/~hverkuil/v4l-dvb-misc for the following: - pvrusb2: fix compile warning - cx24113: fix mips compiler warning - hdpvr: add missing initialization of current_norm - v4l2-ioctl: fix G_STD and G_PARM default handlers - v4l2-ctl: fix get/set-parm bugs and add get/set-output-parm support Thanks, Hans diffstat: linux/drivers/media/dvb/frontends/cx24113.c |6 + linux/drivers/media/video/hdpvr/hdpvr-video.c |2 linux/drivers/media/video/pvrusb2/pvrusb2-audio.c |5 - linux/drivers/media/video/v4l2-ioctl.c| 15 ++- v4l2-apps/util/v4l2-ctl.cpp | 98 +- 5 files changed, 101 insertions(+), 25 deletions(-) -- Mike Isely isely @ isely (dot) net PGP: 03 54 43 4D 75 E5 CC 92 71 16 01 E2 B5 F5 C1 E8 -- 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: [PULL] http://www.linuxtv.org/hg/~hverkuil/v4l-dvb
Em Sun, 2 Aug 2009 12:10:04 +0200
Hans Verkuil hverk...@xs4all.nl escreveu:
Hi Mauro,
Please pull from http://www.linuxtv.org/hg/~hverkuil/v4l-dvb for the
following:
- v4l: introduce string control support.
Hans,
This looks very weird:
+/* The following two functions really belong in v4l2-common, but that
causes
+ a circular dependency between modules. We need to think about this,
but
+ for now this will do. */
+
+/* Return non-zero if this control is of type VALUE64.
+ *
+ * This information is used inside v4l2_compat_ioctl32. */
+static int ctrl_is_value64(u32 id)
+{
+ return 0;
+}
+
+/* Return non-zero if this control is a pointer type. Currently only
+ * type STRING is a pointer type.
+ *
+ * This information is used inside v4l2_compat_ioctl32. */
+static int ctrl_is_pointer(u32 id)
+{
+ return 0;
+}
+
...
+ } else if (ctrl_is_value64(kctrl-id)) {
+ if (copy_in_user(kctrl-value64, uctrl-value64,
+sizeof(uctrl-value64)))
+ return -EFAULT;
...
+ if (ctrl_is_value64(kctrl-id)) {
+ if (copy_in_user(uctrl-value64, kctrl-value64,
+sizeof(uctrl-value64)))
+ return -EFAULT;
+ } else if (!ctrl_is_pointer(kctrl-id)
+ copy_in_user(uctrl-value, kctrl-value,
+sizeof(uctrl-value))) {
Why do you need two routines that will always return zero? Why to create a
code
that will never be used? v4l2-compat-ioctl32.c is already complex enough
without adding any bogus code.
When the RDS encoder driver from Eduardo is added, then he will add the
string controls to ctrl_is_pointer() since his driver is the first to
actually implement string controls.
There is indeed no value64 control yet, but I think it is wise to at least
have the code in place to correctly handle such controls. I can remove
that if you want.
I noticed that you're also renaming the names of some fields there:
- struct v4l2_ext_control __user *ucontrols;
- struct v4l2_ext_control __user *kcontrols = kp-controls;
+ struct v4l2_ext_control __user *uctrl;
+ struct v4l2_ext_control __user *kctrl = kp-controls;
I dunno why you decided to do it, but having this together with the
changes at
v4l2-compat-ioctl32.c makes the code even harder to understand. Could you
please move the v4l2-compat-ioctl32 cosmetic changes like above into a
separate patch?
OK. It was done to avoid creating lots of 'longer than 80 characters'
warnings.
Regards,
Hans
--
Hans Verkuil - video4linux developer - sponsored by TANDBERG
--
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: [PULL] http://www.linuxtv.org/hg/~hverkuil/v4l-dvb
On Thursday 06 August 2009 20:10:38 Trent Piepho wrote: On Thu, 6 Aug 2009, Hans Verkuil wrote: Why do you need two routines that will always return zero? Why to create a code that will never be used? v4l2-compat-ioctl32.c is already complex enough without adding any bogus code. When the RDS encoder driver from Eduardo is added, then he will add the string controls to ctrl_is_pointer() since his driver is the first to actually implement string controls. Could one of the upper bits of the control id be used as a flag? It would make it a lot easier to check the control's type than by using some inline function with a giant case statement that needs to be updated each time a new control is added. No, you can't. That would require users to OR that flag each time you want to use such a control. My original plan was to just check for a non-zero size field, the theory being that applications would set the old reserved field to 0. Unfortunately, several apps do not init those reserved fields, so they would fail. Note to ourselves: the next time we require apps to zero reserved fields we really have to check that they do and return an error otherwise... Anyway, I expect that these functions are a temporary measure anyway. Once we can move the control handling to the v4l2 framework this sort of info should be available readily from the framework without requiring such ugly switches. Regards, Hans -- Hans Verkuil - video4linux developer - sponsored by TANDBERG Telecom -- 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: [PULL] http://www.linuxtv.org/hg/~hverkuil/v4l-dvb
On Thu, 6 Aug 2009, Hans Verkuil wrote: On Thursday 06 August 2009 20:10:38 Trent Piepho wrote: On Thu, 6 Aug 2009, Hans Verkuil wrote: Why do you need two routines that will always return zero? Why to create a code that will never be used? v4l2-compat-ioctl32.c is already complex enough without adding any bogus code. When the RDS encoder driver from Eduardo is added, then he will add the string controls to ctrl_is_pointer() since his driver is the first to actually implement string controls. Could one of the upper bits of the control id be used as a flag? It would make it a lot easier to check the control's type than by using some inline function with a giant case statement that needs to be updated each time a new control is added. No, you can't. That would require users to OR that flag each time you want to use such a control. My original plan was to just check for a non-zero There is no reason we need to allocated control IDs sequentially, is there? So just give string controls IDs in the range 0x8000 to 0x and then one can tell if a control is a string control be ANDing the id with (131). -- 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: [PULL] http://www.linuxtv.org/hg/~hverkuil/v4l-dvb-vpfe-cap
Mauro, You might be able to apply my original patch in the attached email. I just want to make sure your merge of vpfe capture to upstream is not blocked. I have another set of patches based on vpfe capture and it is difficult to create subsequent patches (will have similar merge issues as well) with out getting this to upstream. So please let me know if you have any issues in merging the vpfe capture patch to upstream. I don't want vpfe capture merge blocked because of dm6467 display patch issues. So please let me know if you require any help from me in this regard. I think attached patch might be used to overcome the Makefile issue you have reported. If there is any difficulty in applying this, I can help you to resolve the same. Regards, Murali Karicheri Software Design Engineer Texas Instruments Inc. Germantown, MD 20874 Phone : 301-515-3736 email: m-kariche...@ti.com -Original Message- From: Karicheri, Muralidharan Sent: Tuesday, July 21, 2009 10:32 AM To: 'Mauro Carvalho Chehab' Cc: Subrahmanya, Chaithrika; 'Hans Verkuil'; linux-media@vger.kernel.org Subject: RE: [PULL] http://www.linuxtv.org/hg/~hverkuil/v4l-dvb-vpfe-cap Mauro and Hans, Not sure if you are referring to vpfe capture patch or DM6467 display patch. I think Makefile and Kconfig changes needs to be cherry picked... Murali Karicheri Software Design Engineer Texas Instruments Inc. Germantown, MD 20874 Phone : 301-515-3736 email: m-kariche...@ti.com -Original Message- From: Mauro Carvalho Chehab [mailto:mche...@infradead.org] Sent: Tuesday, July 21, 2009 2:46 AM To: Karicheri, Muralidharan Cc: Subrahmanya, Chaithrika; 'Hans Verkuil'; linux-media@vger.kernel.org Subject: Re: [PULL] http://www.linuxtv.org/hg/~hverkuil/v4l-dvb-vpfe-cap Em Wed, 15 Jul 2009 09:41:53 -0500 Karicheri, Muralidharan m-kariche...@ti.com escreveu: Mauro, Thanks for taking care of this. Anytime. Yet, it seems that those patches depend on Chaithrika DM646x patches that weren't accepted yet by arm maintainer: File to patch: linux/drivers/media/video/davinci/Makefile linux/drivers/media/video/davinci/Makefile: No such file or directory Did you also apply dm6467 display patch from Chaithrika? dm646x is on my -hg tree and on a local branch at one of my -git's. However, I can't proceed with this without the ack. Cheers, Mauro ---BeginMessage--- From: Muralidharan Karicheri m-kariche...@ti.com Makefile and config files for the driver This adds Makefile and Kconfig changes to build vpfe capture driver. No change in this version Reviewed by: Hans Verkuil hverk...@xs4all.nl Reviewed by: Laurent Pinchart laurent.pinch...@skynet.be Signed-off-by: Muralidharan Karicheri m-kariche...@ti.com --- Applies to v4l-dvb repository drivers/media/video/Kconfig | 49 ++ drivers/media/video/Makefile |2 + drivers/media/video/davinci/Makefile |9 ++ 3 files changed, 60 insertions(+), 0 deletions(-) create mode 100644 drivers/media/video/davinci/Makefile diff --git a/drivers/media/video/Kconfig b/drivers/media/video/Kconfig index 94f4405..8a1bd1c 100644 --- a/drivers/media/video/Kconfig +++ b/drivers/media/video/Kconfig @@ -497,6 +497,55 @@ config VIDEO_VIVI Say Y here if you want to test video apps or debug V4L devices. In doubt, say N. +config VIDEO_VPSS_SYSTEM + tristate VPSS System module driver + depends on ARCH_DAVINCI + help + Support for vpss system module for video driver + default y + +config VIDEO_VPFE_CAPTURE + tristate VPFE Video Capture Driver + depends on VIDEO_V4L2 ARCH_DAVINCI + select VIDEOBUF_DMA_CONTIG + help + Support for DM VPFE based frame grabber. This is the + common V4L2 module for following DMXXX SoCs from Texas + Instruments:- DM6446 DM355. + + To compile this driver as a module, choose M here: the + module will be called vpfe-capture. + +config VIDEO_DM6446_CCDC + tristate DM6446 CCDC HW module + depends on ARCH_DAVINCI_DM644x VIDEO_VPFE_CAPTURE + select VIDEO_VPSS_SYSTEM + default y + help + Enables DaVinci CCD hw module. DaVinci CCDC hw interfaces + with decoder modules such as TVP5146 over BT656 or + sensor module such as MT9T001 over a raw interface. This + module configures the interface and CCDC/ISIF to do + video frame capture from slave decoders. + + To compile this driver as a module, choose M here: the + module will be called vpfe. + +config VIDEO_DM355_CCDC + tristate DM355 CCDC HW module + depends on ARCH_DAVINCI_DM355 VIDEO_VPFE_CAPTURE + select VIDEO_VPSS_SYSTEM + default y + help + Enables DM355 CCD hw module. DM355 CCDC hw interfaces + with decoder modules such as TVP5146 over BT656 or + sensor module such as MT9T001 over a raw interface. This + module
Re: [PULL] http://www.linuxtv.org/hg/~hverkuil/v4l-dvb-vpfe-cap
Em Wed, 15 Jul 2009 09:41:53 -0500 Karicheri, Muralidharan m-kariche...@ti.com escreveu: Mauro, Thanks for taking care of this. Anytime. Yet, it seems that those patches depend on Chaithrika DM646x patches that weren't accepted yet by arm maintainer: File to patch: linux/drivers/media/video/davinci/Makefile linux/drivers/media/video/davinci/Makefile: No such file or directory Did you also apply dm6467 display patch from Chaithrika? dm646x is on my -hg tree and on a local branch at one of my -git's. However, I can't proceed with this without the ack. Cheers, Mauro -- 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: [PULL] http://www.linuxtv.org/hg/~hverkuil/v4l-dvb-misc
Hi, Am Dienstag, den 21.07.2009, 08:36 +0200 schrieb Hans Verkuil: Hi Mauro, Please pull from http://www.linuxtv.org/hg/~hverkuil/v4l-dvb-misc for the following: that link fails. You have it in http://linuxtv.org/hg/~hverkuil/v4l-dvb-strctrl - flexcop: fix compile error When this fix is committed I'll start another daily build run. Thanks, Hans diffstat: flexcop-fe-tuner.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) Cheers, Hermann -- 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: [PULL] http://www.linuxtv.org/hg/~hverkuil/v4l-dvb-misc
Am Dienstag, den 21.07.2009, 11:04 +0200 schrieb hermann pitton: Hi, Am Dienstag, den 21.07.2009, 08:36 +0200 schrieb Hans Verkuil: Hi Mauro, Please pull from http://www.linuxtv.org/hg/~hverkuil/v4l-dvb-misc for the following: that link fails. You have it in http://linuxtv.org/hg/~hverkuil/v4l-dvb-strctrl Oops, Mauro has it already. Hermann -- 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: [PULL] http://www.linuxtv.org/hg/~hverkuil/v4l-dvb-vpfe-cap
Mauro and Hans, Not sure if you are referring to vpfe capture patch or DM6467 display patch. I think Makefile and Kconfig changes needs to be cherry picked... Murali Karicheri Software Design Engineer Texas Instruments Inc. Germantown, MD 20874 Phone : 301-515-3736 email: m-kariche...@ti.com -Original Message- From: Mauro Carvalho Chehab [mailto:mche...@infradead.org] Sent: Tuesday, July 21, 2009 2:46 AM To: Karicheri, Muralidharan Cc: Subrahmanya, Chaithrika; 'Hans Verkuil'; linux-media@vger.kernel.org Subject: Re: [PULL] http://www.linuxtv.org/hg/~hverkuil/v4l-dvb-vpfe-cap Em Wed, 15 Jul 2009 09:41:53 -0500 Karicheri, Muralidharan m-kariche...@ti.com escreveu: Mauro, Thanks for taking care of this. Anytime. Yet, it seems that those patches depend on Chaithrika DM646x patches that weren't accepted yet by arm maintainer: File to patch: linux/drivers/media/video/davinci/Makefile linux/drivers/media/video/davinci/Makefile: No such file or directory Did you also apply dm6467 display patch from Chaithrika? dm646x is on my -hg tree and on a local branch at one of my -git's. However, I can't proceed with this without the ack. Cheers, Mauro -- 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: [PULL] http://www.linuxtv.org/hg/~hverkuil/v4l-dvb-misc
On Monday 20 July 2009 15:04:31 Hans Verkuil wrote: Hi Mauro, Please pull from http://www.linuxtv.org/hg/~hverkuil/v4l-dvb-misc for the following: - mt312: fix build for kernels 2.6.24 - versions.txt: freezer routines appeared in 2.6.24, not 2.6.23 Thanks, Hans diffstat: linux/drivers/media/dvb/frontends/mt312.c |1 + v4l/versions.txt |6 -- 2 files changed, 5 insertions(+), 2 deletions(-) Added this fix as well: - v4l2-ctl: fix broken camera control support. Regards, Hans -- Hans Verkuil - video4linux developer - sponsored by TANDBERG Telecom -- 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: [PULL] http://www.linuxtv.org/hg/~hverkuil/v4l-dvb-vpfe-cap
Mauro, Thanks for taking care of this. Did you also apply dm6467 display patch from Chaithrika? Snip li...@arm.linux.org.uk in cc. A patch for VPIF updates has also been posted[2] . Applied on my tree. Not sure if I'll send this week upstream. My middle finger was damaged due to a very heavy box that fall on it, and it is hard for me to type with it immobilized. Sorry to hear that. Hope you recover soon. Take care, Murali. Regards, Chaithrika [1] http://www.mail-archive.com/linux-media@vger.kernel.org/msg07385.html [2] http://www.mail-archive.com/linux-media@vger.kernel.org/msg07384.html Cheers, Mauro -- 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 Regards, Chaithrika Cheers, Mauro -- 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: [PULL] http://www.linuxtv.org/hg/~hverkuil/v4l-dvb-vpfe-cap
Em Tue, 14 Jul 2009 10:24:19 +0530 chaithrika chaithr...@ti.com escreveu: On Sat, Jul 11, 2009 at 01:49:46, Mauro Carvalho Chehab wrote: Em Mon, 6 Jul 2009 20:24:44 +0200 Hans Verkuil hverk...@xs4all.nl escreveu: Hi Mauro, Please pull from http://www.linuxtv.org/hg/~hverkuil/v4l-dvb-vpfe-cap for the following: - tvp514x: Migration to sub-device framework - tvp514x: formatting comments as per kernel documentation - v4l: vpfe capture bridge driver for DM355 and DM6446 - v4l: ccdc hw device header file for vpfe capture - v4l: dm355 ccdc module for vpfe capture driver - v4l: dm644x ccdc module for vpfe capture driver - v4l: ccdc types used across ccdc modules for vpfe capture driver - v4l: common vpss module for video drivers - v4l: Makefile and config files for vpfe capture driver - v4l: davinci drivers should only be compiled for kernels = 2.6.31. Hopefully these changes can be merged into 2.6.31. I have attached two arch/arm patches that need to be applied to the git tree. These patches should be applied after merging this tree. I'm not seeing Rusell (arm maintainer) ack on those patches. Could you please send him those patches C/C me, and asking his ack? Btw. I'm still waiting for the fixes asked by him in order to forward the arm dm646x patch (and the rest of the series) upstream. Mauro, I have submitted the updated patch last week[1]. I have marked li...@arm.linux.org.uk in cc. A patch for VPIF updates has also been posted[2] . Applied on my tree. Not sure if I'll send this week upstream. My middle finger was damaged due to a very heavy box that fall on it, and it is hard for me to type with it immobilized. Regards, Chaithrika [1] http://www.mail-archive.com/linux-media@vger.kernel.org/msg07385.html [2] http://www.mail-archive.com/linux-media@vger.kernel.org/msg07384.html Cheers, Mauro -- 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 Regards, Chaithrika Cheers, Mauro -- 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: [PULL] http://www.linuxtv.org/hg/~hverkuil/v4l-dvb-vpfe-cap
On Sat, Jul 11, 2009 at 01:49:46, Mauro Carvalho Chehab wrote: Em Mon, 6 Jul 2009 20:24:44 +0200 Hans Verkuil hverk...@xs4all.nl escreveu: Hi Mauro, Please pull from http://www.linuxtv.org/hg/~hverkuil/v4l-dvb-vpfe-cap for the following: - tvp514x: Migration to sub-device framework - tvp514x: formatting comments as per kernel documentation - v4l: vpfe capture bridge driver for DM355 and DM6446 - v4l: ccdc hw device header file for vpfe capture - v4l: dm355 ccdc module for vpfe capture driver - v4l: dm644x ccdc module for vpfe capture driver - v4l: ccdc types used across ccdc modules for vpfe capture driver - v4l: common vpss module for video drivers - v4l: Makefile and config files for vpfe capture driver - v4l: davinci drivers should only be compiled for kernels = 2.6.31. Hopefully these changes can be merged into 2.6.31. I have attached two arch/arm patches that need to be applied to the git tree. These patches should be applied after merging this tree. I'm not seeing Rusell (arm maintainer) ack on those patches. Could you please send him those patches C/C me, and asking his ack? Btw. I'm still waiting for the fixes asked by him in order to forward the arm dm646x patch (and the rest of the series) upstream. Mauro, I have submitted the updated patch last week[1]. I have marked li...@arm.linux.org.uk in cc. A patch for VPIF updates has also been posted[2] . Regards, Chaithrika [1] http://www.mail-archive.com/linux-media@vger.kernel.org/msg07385.html [2] http://www.mail-archive.com/linux-media@vger.kernel.org/msg07384.html Cheers, Mauro -- 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 Regards, Chaithrika -- 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: [PULL] http://www.linuxtv.org/hg/~hverkuil/v4l-dvb-vpfe-cap
Em Thu, 9 Jul 2009 09:18:47 -0500 Karicheri, Muralidharan m-kariche...@ti.com escreveu: Mauro, Could you please let me know what your plans are for this pull request? Murali, The arm Maintainer should ack on the patches that touch arch/arm. After having it, I'll analyze the patches again and, if not too late, and if Russell acks on having this for 2.6.31, I'll send it upstream. Cheers, Mauro -- 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: [PULL] http://www.linuxtv.org/hg/~hverkuil/v4l-dvb-vpfe-cap
Em Mon, 6 Jul 2009 20:24:44 +0200 Hans Verkuil hverk...@xs4all.nl escreveu: Hi Mauro, Please pull from http://www.linuxtv.org/hg/~hverkuil/v4l-dvb-vpfe-cap for the following: - tvp514x: Migration to sub-device framework - tvp514x: formatting comments as per kernel documentation - v4l: vpfe capture bridge driver for DM355 and DM6446 - v4l: ccdc hw device header file for vpfe capture - v4l: dm355 ccdc module for vpfe capture driver - v4l: dm644x ccdc module for vpfe capture driver - v4l: ccdc types used across ccdc modules for vpfe capture driver - v4l: common vpss module for video drivers - v4l: Makefile and config files for vpfe capture driver - v4l: davinci drivers should only be compiled for kernels = 2.6.31. Hopefully these changes can be merged into 2.6.31. I have attached two arch/arm patches that need to be applied to the git tree. These patches should be applied after merging this tree. I'm not seeing Rusell (arm maintainer) ack on those patches. Could you please send him those patches C/C me, and asking his ack? Btw. I'm still waiting for the fixes asked by him in order to forward the arm dm646x patch (and the rest of the series) upstream. Cheers, Mauro -- 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: [PULL] http://www.linuxtv.org/hg/~hverkuil/v4l-dvb-vpfe-cap
Mauro, Thanks for your support. I will wait for the comments. Murali Karicheri Software Design Engineer Texas Instruments Inc. Germantown, MD 20874 Phone : 301-515-3736 email: m-kariche...@ti.com -Original Message- From: Mauro Carvalho Chehab [mailto:mche...@infradead.org] Sent: Friday, July 10, 2009 4:25 PM To: Karicheri, Muralidharan Cc: Hans Verkuil; linux-media@vger.kernel.org Subject: Re: [PULL] http://www.linuxtv.org/hg/~hverkuil/v4l-dvb-vpfe-cap Em Thu, 9 Jul 2009 09:18:47 -0500 Karicheri, Muralidharan m-kariche...@ti.com escreveu: Mauro, Could you please let me know what your plans are for this pull request? Murali, The arm Maintainer should ack on the patches that touch arch/arm. After having it, I'll analyze the patches again and, if not too late, and if Russell acks on having this for 2.6.31, I'll send it upstream. Cheers, Mauro -- 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: [PULL] http://www.linuxtv.org/hg/~hverkuil/v4l-dvb-vpfe-cap
Oops! I thought you are going to merge the pull request from Hans and send them for comments like you did for DM6467 patches. Please confirm. Murali Karicheri Software Design Engineer Texas Instruments Inc. Germantown, MD 20874 Phone : 301-515-3736 email: m-kariche...@ti.com -Original Message- From: Karicheri, Muralidharan Sent: Friday, July 10, 2009 4:51 PM To: 'Mauro Carvalho Chehab' Cc: Hans Verkuil; linux-media@vger.kernel.org Subject: RE: [PULL] http://www.linuxtv.org/hg/~hverkuil/v4l-dvb-vpfe-cap Mauro, Thanks for your support. I will wait for the comments. Murali Karicheri Software Design Engineer Texas Instruments Inc. Germantown, MD 20874 Phone : 301-515-3736 email: m-kariche...@ti.com -Original Message- From: Mauro Carvalho Chehab [mailto:mche...@infradead.org] Sent: Friday, July 10, 2009 4:25 PM To: Karicheri, Muralidharan Cc: Hans Verkuil; linux-media@vger.kernel.org Subject: Re: [PULL] http://www.linuxtv.org/hg/~hverkuil/v4l-dvb-vpfe-cap Em Thu, 9 Jul 2009 09:18:47 -0500 Karicheri, Muralidharan m-kariche...@ti.com escreveu: Mauro, Could you please let me know what your plans are for this pull request? Murali, The arm Maintainer should ack on the patches that touch arch/arm. After having it, I'll analyze the patches again and, if not too late, and if Russell acks on having this for 2.6.31, I'll send it upstream. Cheers, Mauro -- 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: [PULL] http://www.linuxtv.org/hg/~hverkuil/v4l-dvb-vpfe-cap
Em Fri, 10 Jul 2009 15:54:21 -0500 Karicheri, Muralidharan m-kariche...@ti.com escreveu: Oops! I thought you are going to merge the pull request from Hans and send them for comments like you did for DM6467 patches. In the case of dm6467, I only noticed the lack of Russell ack after merging it at -hg. Due to that, I needed to do a hack on my local -git copy. It is much better if we do the opposite: get first the arm ack, and then merge everything on -hg and -git. In order to speedup the process, could you please send the two patches to Russell, c/c me and linux-media ML (one patch per email, inlined)? Thanks, Mauro. Cheers, Mauro -- 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: [PULL] http://www.linuxtv.org/hg/~hverkuil/v4l-dvb-vpfe-cap
Mauro, Please excuse me to ask these silly questions. Since I am not much familiar with the process, I need some help here. The arm patches are attached in Hans original pull request. Is it Okay to 1) forward the same to Russel, cc you and request his comment or 2) forward the original patches I had sent to Hans. In the case of DaVinci drivers, Hans is integrating and sending pull request. So option 1) seems right to me. Any comments? Murali Karicheri Software Design Engineer Texas Instruments Inc. Germantown, MD 20874 Phone : 301-515-3736 email: m-kariche...@ti.com -Original Message- From: Mauro Carvalho Chehab [mailto:mche...@infradead.org] Sent: Friday, July 10, 2009 5:08 PM To: Karicheri, Muralidharan Cc: Karicheri, Muralidharan; Hans Verkuil; linux-media@vger.kernel.org Subject: Re: [PULL] http://www.linuxtv.org/hg/~hverkuil/v4l-dvb-vpfe-cap Em Fri, 10 Jul 2009 15:54:21 -0500 Karicheri, Muralidharan m-kariche...@ti.com escreveu: Oops! I thought you are going to merge the pull request from Hans and send them for comments like you did for DM6467 patches. In the case of dm6467, I only noticed the lack of Russell ack after merging it at -hg. Due to that, I needed to do a hack on my local -git copy. It is much better if we do the opposite: get first the arm ack, and then merge everything on -hg and -git. In order to speedup the process, could you please send the two patches to Russell, c/c me and linux-media ML (one patch per email, inlined)? Thanks, Mauro. Cheers, Mauro -- 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: [PULL] http://www.linuxtv.org/hg/~hverkuil/v4l-dvb-vpfe-cap
Mauro, I have forwarded the two patches to Russell as asked in your email. Let me if it doesn't look right. Thanks. Murali Karicheri Software Design Engineer Texas Instruments Inc. Germantown, MD 20874 Phone : 301-515-3736 email: m-kariche...@ti.com -Original Message- From: Mauro Carvalho Chehab [mailto:mche...@infradead.org] Sent: Friday, July 10, 2009 4:20 PM To: Hans Verkuil Cc: linux-media@vger.kernel.org; Karicheri, Muralidharan Subject: Re: [PULL] http://www.linuxtv.org/hg/~hverkuil/v4l-dvb-vpfe-cap Em Mon, 6 Jul 2009 20:24:44 +0200 Hans Verkuil hverk...@xs4all.nl escreveu: Hi Mauro, Please pull from http://www.linuxtv.org/hg/~hverkuil/v4l-dvb-vpfe-cap for the following: - tvp514x: Migration to sub-device framework - tvp514x: formatting comments as per kernel documentation - v4l: vpfe capture bridge driver for DM355 and DM6446 - v4l: ccdc hw device header file for vpfe capture - v4l: dm355 ccdc module for vpfe capture driver - v4l: dm644x ccdc module for vpfe capture driver - v4l: ccdc types used across ccdc modules for vpfe capture driver - v4l: common vpss module for video drivers - v4l: Makefile and config files for vpfe capture driver - v4l: davinci drivers should only be compiled for kernels = 2.6.31. Hopefully these changes can be merged into 2.6.31. I have attached two arch/arm patches that need to be applied to the git tree. These patches should be applied after merging this tree. I'm not seeing Rusell (arm maintainer) ack on those patches. Could you please send him those patches C/C me, and asking his ack? Btw. I'm still waiting for the fixes asked by him in order to forward the arm dm646x patch (and the rest of the series) upstream. Cheers, Mauro -- 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: [PULL] http://www.linuxtv.org/hg/~hverkuil/v4l-dvb-vpfe-cap
Em Fri, 10 Jul 2009 16:13:05 -0500 Karicheri, Muralidharan m-kariche...@ti.com escreveu: Mauro, Please excuse me to ask these silly questions. Since I am not much familiar with the process, I need some help here. The arm patches are attached in Hans original pull request. Is it Okay to 1) forward the same to Russel, cc you and request his comment or 2) forward the original patches I had sent to Hans. In the case of DaVinci drivers, Hans is integrating and sending pull request. So option 1) seems right to me. Kernel maintainers don't like to see more than one patch per email, since this breaks all merge scripts and require manual work. So, people should always send one patch per email. So, answering your question, (2) is the proper way. You should warn Russell that the merge will happen via my tree, to avoid merge conflicts between his and my tree. Cheers, Mauro -- 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: [PULL] http://www.linuxtv.org/hg/~hverkuil/v4l-dvb-vpfe-cap
Em Fri, 10 Jul 2009 16:35:09 -0500 Karicheri, Muralidharan m-kariche...@ti.com escreveu: Mauro, I have forwarded the two patches to Russell as asked in your email. Let me if it doesn't look right. OK. The emails you sent him is the proper way ;) Cheers, Mauro -- 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: [PULL] http://www.linuxtv.org/hg/~hverkuil/v4l-dvb-vpfe-cap
Mauro, Could you please let me know what your plans are for this pull request? Murali Karicheri Software Design Engineer Texas Instruments Inc. Germantown, MD 20874 Phone : 301-515-3736 email: m-kariche...@ti.com -Original Message- From: Karicheri, Muralidharan Sent: Tuesday, July 07, 2009 10:42 AM To: 'Hans Verkuil'; linux-media@vger.kernel.org Cc: Mauro Carvalho Chehab Subject: RE: [PULL] http://www.linuxtv.org/hg/~hverkuil/v4l-dvb-vpfe-cap Mauro, Will you be able to pull this for 2.6.31 ? Thanks. Murali Karicheri Software Design Engineer Texas Instruments Inc. Germantown, MD 20874 Phone : 301-515-3736 email: m-kariche...@ti.com -Original Message- From: Hans Verkuil [mailto:hverk...@xs4all.nl] Sent: Monday, July 06, 2009 2:25 PM To: linux-media@vger.kernel.org Cc: Karicheri, Muralidharan; Mauro Carvalho Chehab Subject: [PULL] http://www.linuxtv.org/hg/~hverkuil/v4l-dvb-vpfe-cap Hi Mauro, Please pull from http://www.linuxtv.org/hg/~hverkuil/v4l-dvb-vpfe-cap for the following: - tvp514x: Migration to sub-device framework - tvp514x: formatting comments as per kernel documentation - v4l: vpfe capture bridge driver for DM355 and DM6446 - v4l: ccdc hw device header file for vpfe capture - v4l: dm355 ccdc module for vpfe capture driver - v4l: dm644x ccdc module for vpfe capture driver - v4l: ccdc types used across ccdc modules for vpfe capture driver - v4l: common vpss module for video drivers - v4l: Makefile and config files for vpfe capture driver - v4l: davinci drivers should only be compiled for kernels = 2.6.31. Hopefully these changes can be merged into 2.6.31. I have attached two arch/arm patches that need to be applied to the git tree. These patches should be applied after merging this tree. I've compiled this driver against the latest Linus' git tree. Thanks, Hans diffstat: b/linux/drivers/media/video/davinci/ccdc_hw_device.h | 110 b/linux/drivers/media/video/davinci/dm355_ccdc.c | 978 +++ b/linux/drivers/media/video/davinci/dm355_ccdc_regs.h | 310 ++ b/linux/drivers/media/video/davinci/dm644x_ccdc.c | 878 +++ b/linux/drivers/media/video/davinci/dm644x_ccdc_regs.h | 145 + b/linux/drivers/media/video/davinci/vpfe_capture.c | 2124 + b/linux/drivers/media/video/davinci/vpss.c | 301 ++ b/linux/include/media/davinci/ccdc_types.h | 43 b/linux/include/media/davinci/dm355_ccdc.h | 321 ++ b/linux/include/media/davinci/dm644x_ccdc.h| 184 + b/linux/include/media/davinci/vpfe_capture.h | 198 + b/linux/include/media/davinci/vpfe_types.h | 51 b/linux/include/media/davinci/vpss.h | 69 linux/drivers/media/video/Kconfig | 49 linux/drivers/media/video/Makefile |2 linux/drivers/media/video/davinci/Makefile |6 linux/drivers/media/video/tvp514x.c| 1154 - linux/drivers/media/video/tvp514x_regs.h | 10 linux/include/media/tvp514x.h |4 v4l/versions.txt |7 20 files changed, 6284 insertions(+), 660 deletions(-) -- Hans Verkuil - video4linux developer - sponsored by TANDBERG Telecom
RE: [PULL] http://www.linuxtv.org/hg/~hverkuil/v4l-dvb-vpfe-cap
Mauro,
Will you be able to pull this for 2.6.31 ?
Thanks.
Murali Karicheri
Software Design Engineer
Texas Instruments Inc.
Germantown, MD 20874
Phone : 301-515-3736
email: m-kariche...@ti.com
-Original Message-
From: Hans Verkuil [mailto:hverk...@xs4all.nl]
Sent: Monday, July 06, 2009 2:25 PM
To: linux-media@vger.kernel.org
Cc: Karicheri, Muralidharan; Mauro Carvalho Chehab
Subject: [PULL] http://www.linuxtv.org/hg/~hverkuil/v4l-dvb-vpfe-cap
Hi Mauro,
Please pull from http://www.linuxtv.org/hg/~hverkuil/v4l-dvb-vpfe-cap for
the following:
- tvp514x: Migration to sub-device framework
- tvp514x: formatting comments as per kernel documentation
- v4l: vpfe capture bridge driver for DM355 and DM6446
- v4l: ccdc hw device header file for vpfe capture
- v4l: dm355 ccdc module for vpfe capture driver
- v4l: dm644x ccdc module for vpfe capture driver
- v4l: ccdc types used across ccdc modules for vpfe capture driver
- v4l: common vpss module for video drivers
- v4l: Makefile and config files for vpfe capture driver
- v4l: davinci drivers should only be compiled for kernels = 2.6.31.
Hopefully these changes can be merged into 2.6.31.
I have attached two arch/arm patches that need to be applied to the git
tree.
These patches should be applied after merging this tree.
I've compiled this driver against the latest Linus' git tree.
Thanks,
Hans
diffstat:
b/linux/drivers/media/video/davinci/ccdc_hw_device.h | 110
b/linux/drivers/media/video/davinci/dm355_ccdc.c | 978 +++
b/linux/drivers/media/video/davinci/dm355_ccdc_regs.h | 310 ++
b/linux/drivers/media/video/davinci/dm644x_ccdc.c | 878 +++
b/linux/drivers/media/video/davinci/dm644x_ccdc_regs.h | 145 +
b/linux/drivers/media/video/davinci/vpfe_capture.c | 2124
+
b/linux/drivers/media/video/davinci/vpss.c | 301 ++
b/linux/include/media/davinci/ccdc_types.h | 43
b/linux/include/media/davinci/dm355_ccdc.h | 321 ++
b/linux/include/media/davinci/dm644x_ccdc.h| 184 +
b/linux/include/media/davinci/vpfe_capture.h | 198 +
b/linux/include/media/davinci/vpfe_types.h | 51
b/linux/include/media/davinci/vpss.h | 69
linux/drivers/media/video/Kconfig | 49
linux/drivers/media/video/Makefile |2
linux/drivers/media/video/davinci/Makefile |6
linux/drivers/media/video/tvp514x.c| 1154 -
linux/drivers/media/video/tvp514x_regs.h | 10
linux/include/media/tvp514x.h |4
v4l/versions.txt |7
20 files changed, 6284 insertions(+), 660 deletions(-)
--
Hans Verkuil - video4linux developer - sponsored by TANDBERG Telecom
N�r��yb�X��ǧv�^�)޺{.n�+{���bj)w* jg��� �ݢj/���z�ޖ��2�ޙ�)ߡ�a���� �G���h��j:+v���w��٥
RE: [PULL] http://www.linuxtv.org/hg/~hverkuil/v4l-dvb-vpfe-cap
Hans,
That was quick. Thanks for your support.
Murali Karicheri
Software Design Engineer
Texas Instruments Inc.
Germantown, MD 20874
Phone : 301-515-3736
email: m-kariche...@ti.com
-Original Message-
From: Hans Verkuil [mailto:hverk...@xs4all.nl]
Sent: Monday, July 06, 2009 2:25 PM
To: linux-media@vger.kernel.org
Cc: Karicheri, Muralidharan; Mauro Carvalho Chehab
Subject: [PULL] http://www.linuxtv.org/hg/~hverkuil/v4l-dvb-vpfe-cap
Hi Mauro,
Please pull from http://www.linuxtv.org/hg/~hverkuil/v4l-dvb-vpfe-cap for
the following:
- tvp514x: Migration to sub-device framework
- tvp514x: formatting comments as per kernel documentation
- v4l: vpfe capture bridge driver for DM355 and DM6446
- v4l: ccdc hw device header file for vpfe capture
- v4l: dm355 ccdc module for vpfe capture driver
- v4l: dm644x ccdc module for vpfe capture driver
- v4l: ccdc types used across ccdc modules for vpfe capture driver
- v4l: common vpss module for video drivers
- v4l: Makefile and config files for vpfe capture driver
- v4l: davinci drivers should only be compiled for kernels = 2.6.31.
Hopefully these changes can be merged into 2.6.31.
I have attached two arch/arm patches that need to be applied to the git
tree.
These patches should be applied after merging this tree.
I've compiled this driver against the latest Linus' git tree.
Thanks,
Hans
diffstat:
b/linux/drivers/media/video/davinci/ccdc_hw_device.h | 110
b/linux/drivers/media/video/davinci/dm355_ccdc.c | 978 +++
b/linux/drivers/media/video/davinci/dm355_ccdc_regs.h | 310 ++
b/linux/drivers/media/video/davinci/dm644x_ccdc.c | 878 +++
b/linux/drivers/media/video/davinci/dm644x_ccdc_regs.h | 145 +
b/linux/drivers/media/video/davinci/vpfe_capture.c | 2124
+
b/linux/drivers/media/video/davinci/vpss.c | 301 ++
b/linux/include/media/davinci/ccdc_types.h | 43
b/linux/include/media/davinci/dm355_ccdc.h | 321 ++
b/linux/include/media/davinci/dm644x_ccdc.h| 184 +
b/linux/include/media/davinci/vpfe_capture.h | 198 +
b/linux/include/media/davinci/vpfe_types.h | 51
b/linux/include/media/davinci/vpss.h | 69
linux/drivers/media/video/Kconfig | 49
linux/drivers/media/video/Makefile |2
linux/drivers/media/video/davinci/Makefile |6
linux/drivers/media/video/tvp514x.c| 1154 -
linux/drivers/media/video/tvp514x_regs.h | 10
linux/include/media/tvp514x.h |4
v4l/versions.txt |7
20 files changed, 6284 insertions(+), 660 deletions(-)
--
Hans Verkuil - video4linux developer - sponsored by TANDBERG Telecom
N�r��yb�X��ǧv�^�)޺{.n�+{���bj)w* jg��� �ݢj/���z�ޖ��2�ޙ�)ߡ�a���� �G���h��j:+v���w��٥
Re: [PULL] http://www.linuxtv.org/hg/~hverkuil/v4l-dvb-dm646x
Em Fri, 26 Jun 2009 21:01:50 +0200 Hans Verkuil hverk...@xs4all.nl escreveu: Hi Mauro, Please pull from http://www.linuxtv.org/hg/~hverkuil/v4l-dvb-dm646x for the following: - ARM: DaVinci: DM646x Video: VPIF driver - ARM: DaVinci: DM646x Video: Add VPIF display driver - ARM: DaVinci: DM646x Video: Makefile and config files modifications for Display - ARM: DaVinci: DM646x Video: Fix compile time warnings for mutex locking Note that these four patches depend on the attached platform patch that should be applied to the git tree first. If possible, it would be great if this (like the vpfe capture driver) can be merged for 2.6.31. One note about your changesets: Please, don't use both Reviewed-by and Signed-off-by. The first tag is meant for patches that you reviewed, but you are not part of the submission chain, while the second one means that you reviewed and you're submitting to a maintainer. I'm fixing this at the -git patches. Cheers, Mauro -- 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: [PULL] http://www.linuxtv.org/hg/~hverkuil/v4l-dvb-dm646x
On Sun, Jul 05, 2009 at 09:51:55AM -0300, Mauro Carvalho Chehab wrote:
Hmm... I'm not seeing Russel ack on the arch/arm patch. Russel, could you
please review the enclosed patch? Would this be ok for 2.6.31?
I'm not sure who this Russel is!
@@ -207,6 +220,40 @@ static struct at24_platform_data eeprom_info = {
.context= (void *)0x7f00,
};
+static struct i2c_client *cpld_client;
+
+static int cpld_video_probe(struct i2c_client *client,
+ const struct i2c_device_id *id)
+{
+ cpld_client = client;
+ return 0;
+}
+
+static int __devexit cpld_video_remove(struct i2c_client *client)
+{
+ cpld_client = NULL;
+ return 0;
+}
...
+static int set_vpif_clock(int mux_mode, int hd)
+{
+ int val = 0;
+ int err = 0;
+ unsigned int value;
+ void __iomem *base = IO_ADDRESS(DAVINCI_SYSTEM_MODULE_BASE);
+
+ /* disable the clock */
+ value = __raw_readl(base + VSCLKDIS_OFFSET);
+ value |= (VIDCH3CLK | VIDCH2CLK);
+ __raw_writel(value, base + VSCLKDIS_OFFSET);
+
+ val = i2c_smbus_read_byte(cpld_client);
+ if (val 0)
+ return val;
+
+ if (mux_mode == 1)
+ val = ~0x40;
+ else
+ val |= 0x40;
+
+ err = i2c_smbus_write_byte(cpld_client, val);
+ if (err)
+ return err;
So what prevents this 'cpld_client' being removed mid-operation? What if
'cpld_client' isn't found for whatever reason?
+static struct platform_device vpif_display_dev = {
+ .name = vpif_display,
+ .id = -1,
+ .dev= {
+ .dma_mask = vpif_dma_mask,
+ .coherent_dma_mask = DMA_32BIT_MASK,
Shouldn't this be DMA_BIT_MASK(32) ?
--
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: [PULL] http://www.linuxtv.org/hg/~hverkuil/v4l-dvb-dm646x
Em Sun, 5 Jul 2009 15:46:32 +0100 Russell King - ARM Linux li...@arm.linux.org.uk escreveu: On Sun, Jul 05, 2009 at 09:51:55AM -0300, Mauro Carvalho Chehab wrote: Hmm... I'm not seeing Russel ack on the arch/arm patch. Russel, could you please review the enclosed patch? Would this be ok for 2.6.31? I'm not sure who this Russel is! Sorry for the typo, Russell. As double consonants are forbidden on my mother tong (except for ss), sometimes my fingers refuse to type a double consonant :) Cheers, Mauro -- 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: [PULL] http://www.linuxtv.org/hg/~hverkuil/v4l-dvb-vpfe-cap
Em Tue, 30 Jun 2009 14:39:55 -0500
Karicheri, Muralidharan m-kariche...@ti.com escreveu:
Mauro,
Thanks for responding...
You should note that I'm not asking you to remove that code, but just to
use
the already existing color balance ioctls, for the existing features, or
otherwise to discuss the need of extra controls.
Ok.
The case of image color controlling, we already have several controls:
#define V4L2_CID_SATURATION (V4L2_CID_BASE+2)
#define V4L2_CID_RED_BALANCE(V4L2_CID_BASE+14)
#define V4L2_CID_BLUE_BALANCE (V4L2_CID_BASE+15)
#define V4L2_CID_GAMMA (V4L2_CID_BASE+16)
#define V4L2_CID_GAIN (V4L2_CID_BASE+19)
Also, some got deprecated, since they were just duplicating existing
controls,
using a different way, as discussed at ML:
Ok. I need to investigate this when I support control IOCTLs in vpfe
capture. As of now control IOCTLs are not supported in vpfe capture.
#define V4L2_CID_BLACK_LEVEL(V4L2_CID_BASE+11) /* Deprecated */
#define V4L2_CID_WHITENESS (V4L2_CID_GAMMA) /* Deprecated */
So, you basically need to rewrite your logic in order to control the device
in
terms of gain and red/blue balance.
Ok. I get it.
Hans had an issue with the way we implemented control IOCTL handling in the
driver. So the piece of code you had objected to is redundant. I will clean
it up or modify it when I support control IOCTLs handling in vpfe capture or
alternately remove it using a separate patch. So please go ahead and merge
the patches if everything else looks good.
I guess you didn't understand me. For me to pull from this pull request, I need
to be sure that no uneeded/duplicated/undocumented userspace controls are added
to V4L2 API.
So, we need to solve all PRIVATE controls:
$ grep PRIVATE /tmp/newpatches/hg_v4l-dvb-vpfe-cap_*
/tmp/newpatches/hg_v4l-dvb-vpfe-cap_02.patch:+#define
VPFE_CMD_S_CCDC_RAW_PARAMS _IOW('V', BASE_VIDIOC_PRIVATE + 1, \
/tmp/newpatches/hg_v4l-dvb-vpfe-cap_05.patch:+#define CCDC_CID_R_GAIN
(V4L2_CID_PRIVATE_BASE + 0)
/tmp/newpatches/hg_v4l-dvb-vpfe-cap_05.patch:+#define CCDC_CID_GR_GAIN
(V4L2_CID_PRIVATE_BASE + 1)
/tmp/newpatches/hg_v4l-dvb-vpfe-cap_05.patch:+#define CCDC_CID_GB_GAIN
(V4L2_CID_PRIVATE_BASE + 2)
/tmp/newpatches/hg_v4l-dvb-vpfe-cap_05.patch:+#define CCDC_CID_B_GAIN
(V4L2_CID_PRIVATE_BASE + 3)
/tmp/newpatches/hg_v4l-dvb-vpfe-cap_05.patch:+#define CCDC_CID_OFFSET
(V4L2_CID_PRIVATE_BASE + 4)
/tmp/newpatches/hg_v4l-dvb-vpfe-cap_05.patch:+#define CCDC_CID_MAX
(V4L2_CID_PRIVATE_BASE + 5)
(btw, the grep above also showed another of such control at the second patch)
Most of the above controls are duplicated, in the sense that the current color
controls (eventually with some math) are capable of controlling the color gains.
The CCDC_CID_MAX is not even implemented.
The VPFE_CMD_S_CCDC_RAW_PARAMS and CCDC_CID_OFFSET are not properly documented,
so, I have no idea about what you want to control with them.
One quick alternative for them, while they are being under discussions, would
be to put them into #if 0/#endif blocks, but you need to provide a patch to
solve it for me to merge VPFE
Cheers,
Mauro
--
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: [PULL] http://www.linuxtv.org/hg/~hverkuil/v4l-dvb-vpfe-cap
Mauro,
I will recreate the patches to take out these controls from
the code and take care of other comments you have and
request Hans to send you a pull request.
Regards,
Murali Karicheri
Software Design Engineer
Texas Instruments Inc.
Germantown, MD 20874
Phone : 301-515-3736
email: m-kariche...@ti.com
-Original Message-
From: Mauro Carvalho Chehab [mailto:mche...@infradead.org]
Sent: Thursday, July 02, 2009 7:39 AM
To: Karicheri, Muralidharan
Cc: Hans Verkuil; linux-media@vger.kernel.org
Subject: Re: [PULL] http://www.linuxtv.org/hg/~hverkuil/v4l-dvb-vpfe-cap
Em Tue, 30 Jun 2009 14:39:55 -0500
Karicheri, Muralidharan m-kariche...@ti.com escreveu:
Mauro,
Thanks for responding...
You should note that I'm not asking you to remove that code, but just to
use
the already existing color balance ioctls, for the existing features, or
otherwise to discuss the need of extra controls.
Ok.
The case of image color controlling, we already have several controls:
#define V4L2_CID_SATURATION (V4L2_CID_BASE+2)
#define V4L2_CID_RED_BALANCE(V4L2_CID_BASE+14)
#define V4L2_CID_BLUE_BALANCE (V4L2_CID_BASE+15)
#define V4L2_CID_GAMMA (V4L2_CID_BASE+16)
#define V4L2_CID_GAIN (V4L2_CID_BASE+19)
Also, some got deprecated, since they were just duplicating existing
controls,
using a different way, as discussed at ML:
Ok. I need to investigate this when I support control IOCTLs in vpfe
capture. As of now control IOCTLs are not supported in vpfe capture.
#define V4L2_CID_BLACK_LEVEL(V4L2_CID_BASE+11) /* Deprecated
*/
#define V4L2_CID_WHITENESS (V4L2_CID_GAMMA) /* Deprecated
*/
So, you basically need to rewrite your logic in order to control the
device
in
terms of gain and red/blue balance.
Ok. I get it.
Hans had an issue with the way we implemented control IOCTL handling in
the driver. So the piece of code you had objected to is redundant. I will
clean it up or modify it when I support control IOCTLs handling in vpfe
capture or alternately remove it using a separate patch. So please go ahead
and merge the patches if everything else looks good.
I guess you didn't understand me. For me to pull from this pull request, I
need
to be sure that no uneeded/duplicated/undocumented userspace controls are
added
to V4L2 API.
So, we need to solve all PRIVATE controls:
$ grep PRIVATE /tmp/newpatches/hg_v4l-dvb-vpfe-cap_*
/tmp/newpatches/hg_v4l-dvb-vpfe-cap_02.patch:+#define
VPFE_CMD_S_CCDC_RAW_PARAMS _IOW('V', BASE_VIDIOC_PRIVATE + 1, \
/tmp/newpatches/hg_v4l-dvb-vpfe-cap_05.patch:+#define CCDC_CID_R_GAIN
(V4L2_CID_PRIVATE_BASE + 0)
/tmp/newpatches/hg_v4l-dvb-vpfe-cap_05.patch:+#define CCDC_CID_GR_GAIN
(V4L2_CID_PRIVATE_BASE + 1)
/tmp/newpatches/hg_v4l-dvb-vpfe-cap_05.patch:+#define CCDC_CID_GB_GAIN
(V4L2_CID_PRIVATE_BASE + 2)
/tmp/newpatches/hg_v4l-dvb-vpfe-cap_05.patch:+#define CCDC_CID_B_GAIN
(V4L2_CID_PRIVATE_BASE + 3)
/tmp/newpatches/hg_v4l-dvb-vpfe-cap_05.patch:+#define CCDC_CID_OFFSET
(V4L2_CID_PRIVATE_BASE + 4)
/tmp/newpatches/hg_v4l-dvb-vpfe-cap_05.patch:+#define CCDC_CID_MAX
(V4L2_CID_PRIVATE_BASE + 5)
(btw, the grep above also showed another of such control at the second
patch)
Most of the above controls are duplicated, in the sense that the current
color
controls (eventually with some math) are capable of controlling the color
gains.
The CCDC_CID_MAX is not even implemented.
The VPFE_CMD_S_CCDC_RAW_PARAMS and CCDC_CID_OFFSET are not properly
documented,
so, I have no idea about what you want to control with them.
One quick alternative for them, while they are being under discussions,
would
be to put them into #if 0/#endif blocks, but you need to provide a patch to
solve it for me to merge VPFE
Cheers,
Mauro
--
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: [PULL] http://www.linuxtv.org/hg/~hverkuil/v4l-dvb-vpfe-cap
Em Thu, 2 Jul 2009 10:13:08 -0500 Karicheri, Muralidharan m-kariche...@ti.com escreveu: Mauro, I will recreate the patches to take out these controls from the code and take care of other comments you have and request Hans to send you a pull request. Ok. for me, it is also fine if you just send the new patches, provided that you ask me to pull together with the previous ones. Cheers, Mauro -- 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: [PULL] http://www.linuxtv.org/hg/~hverkuil/v4l-dvb-rds
On Tuesday 30 June 2009 17:16:03 Mauro Carvalho Chehab wrote: Em Sat, 20 Jun 2009 14:30:41 +0200 Hans Verkuil hverk...@xs4all.nl escreveu: Hi Mauro, Please pull from http://www.linuxtv.org/hg/~hverkuil/v4l-dvb-rds for the following: - v4l2: add RDS API to videodev2.h - v4l2-spec: finalize the RDS specification. From: Hans Verkuil hverk...@xs4all.nl Priority: normal Signed-off-by: Hans Verkuil hverk...@xs4all.nl --- a/v4l2-spec/biblio.sgml Sat Jun 20 10:37:27 2009 +0200 +++ b/v4l2-spec/biblio.sgml Sat Jun 20 10:49:43 2009 +0200 @@ -158,54 +158,23 @@ 1125-Line High-Definition Production/t 1125-Line High-Definition Production/title /biblioentry -biblioentry id=v4l - abbrevV4L/abbrev +biblioentry id=en50067 + abbrevENnbsp;50067/abbrev authorgroup - author - firstnameAlan/firstname - surnameCox/surname - affiliation - orgnameRed Hat, Inc./orgname - address - emaila...@redhat.com/email - /address - /affiliation - /author + corpauthorEuropean Committee for Electrotechnical Standardization +(ulink url=http://www.cenelec.eu;http://www.cenelec.eu/ulink)/corpauthor /authorgroup - titleVideo4Linux API Specification/title - abstract - paraThis file is part of the Linux kernel sources under -filenameDocumentation/video4linux/filename./para - /abstract + titleSpecification of the radio data system (RDS) for VHF/FM sound broadcasting +in the frequency range from 87,5 to 108,0 MHz/title /biblioentry -biblioentry id=v4lprog - abbrevV4LPROG/abbrev +biblioentry id=nrsc4 + abbrevNRSC-4/abbrev authorgroup - author - firstnameAlan/firstname - surnameCox/surname - affiliation - orgnameRed Hat, Inc./orgname - address - emaila...@redhat.com/email - /address - /affiliation - /author + corpauthorNational Radio Systems Committee +(ulink url=http://www.nrscstandards.org;http://www.nrscstandards.org/ulink)/corpauthor /authorgroup - titleVideo4Linux Programming (a.k.a. The Video4Linux -Book)/title - abstract - paraAbout V4L emphasisdriver/emphasis programming. This -book is part of the Linux kernel DocBook documentation, for example at -ulink url=http://kernelnewbies.org/documents/; -http://kernelnewbies.org/documents//ulink. SGML sources are included -in the kernel sources./para - /abstract - copyright - year2000/year - holderAlan Cox/holder - /copyright + titleNTSC-4: United States RBDS Standard/title /biblioentry /bibliography Hmm.. why are you removing Alan Cox authorship, and adding other organizations there? AFAIK, they never submitted a contribution to V4L2 API, nor I have their and Alan Ack/SOB, that are required for such changes. These are the bibliography entries, not copyright statements or anything. The v4lprog bibliography entry is 1) unused, and 2) the document it refers to does not exist. Hence I removed it. It's a bogus entry, probably a left-over from a very old version of the v4l documentation. The nrsc4 bibliography entry points to the RBDS standard and is referred to from the RDS chapter. This is a bibliography and that has nothing to do with authorship or copyrights or anything like that. Regards, Hans -- Hans Verkuil - video4linux developer - sponsored by TANDBERG Telecom -- 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: [PULL] http://www.linuxtv.org/hg/~hverkuil/v4l-dvb-vpfe-cap
On Tuesday 30 June 2009 17:19:39 Mauro Carvalho Chehab wrote: Em Tue, 30 Jun 2009 10:06:17 -0500 Karicheri, Muralidharan m-kariche...@ti.com escreveu: - tvp514x: Migration to sub-device framework As already pointed, here we have those comments regression. Also, some functions were changed, but the comments still mentions the older parameters. Please fix it on a later patch. I had sent a patch to fix the comment formatting. If you wish, you could apply it and wait for another that fix the old parameter descriptions. Fine. It would be better if Hans could add this on his tree, for me to import it together with the other patches. I have added this in my vpfe-cap tree. Regards, Hans -- Hans Verkuil - video4linux developer - sponsored by TANDBERG Telecom -- 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: [PULL] http://www.linuxtv.org/hg/~hverkuil/v4l-dvb-vpfe-cap
Em Fri, 19 Jun 2009 14:39:14 +0200 Hans Verkuil hverk...@xs4all.nl escreveu: Hi Mauro, Please pull from http://www.linuxtv.org/hg/~hverkuil/v4l-dvb-vpfe-cap for the following: - tvp514x: Migration to sub-device framework As already pointed, here we have those comments regression. Also, some functions were changed, but the comments still mentions the older parameters. Please fix it on a later patch. - v4l: vpfe capture bridge driver for DM355 and DM6446 - vpfe_capture: add missing newlines and fix an incorrect error code. - v4l: ccdc hw device header file for vpfe capture - v4l: dm355 ccdc module for vpfe capture driver Hmm... +#define CCDC_CID_R_GAIN(V4L2_CID_PRIVATE_BASE + 0) +#define CCDC_CID_GR_GAIN (V4L2_CID_PRIVATE_BASE + 1) +#define CCDC_CID_GB_GAIN (V4L2_CID_PRIVATE_BASE + 2) +#define CCDC_CID_B_GAIN(V4L2_CID_PRIVATE_BASE + 3) This is not nice. Such gains are common to other webcam drivers, and should be part of the common part of V4L2 API. In fact, currently, we have it mapped as a general gain as red/blue balance. +#define CCDC_CID_OFFSET(V4L2_CID_PRIVATE_BASE + 4) What does it control? +#define CCDC_CID_MAX (V4L2_CID_PRIVATE_BASE + 5) This one doesn't seem to be used. - v4l: dm644x ccdc module for vpfe capture driver - v4l: ccdc types used across ccdc modules for vpfe capture driver - v4l: common vpss module for video drivers - v4l: Makefile and config files for vpfe capture driver - v4l: davinci drivers should only be compiled for kernels = 2.6.31. The other patches are ok. Hopefully these changes can be merged into 2.6.31. After having the entire series committed, I'll see if it is still possible to submit it. There are two arch/arm patches that need to be applied to the git tree. These patches should be applied last. They are: http://patchwork.kernel.org/patch/30968/ http://patchwork.kernel.org/patch/30974/ Note that I had to move patch 9 (vpss) in the original patch series before patch 6 (the Makefile changes) to make sure everything would still compile. Thanks, Hans diffstat: b/linux/drivers/media/video/davinci/Makefile |9 b/linux/drivers/media/video/davinci/ccdc_hw_device.h | 110 b/linux/drivers/media/video/davinci/dm355_ccdc.c | 1163 + b/linux/drivers/media/video/davinci/dm355_ccdc_regs.h | 310 ++ b/linux/drivers/media/video/davinci/dm644x_ccdc.c | 878 ++ b/linux/drivers/media/video/davinci/dm644x_ccdc_regs.h | 145 + b/linux/drivers/media/video/davinci/vpfe_capture.c | 2136 + b/linux/drivers/media/video/davinci/vpss.c | 301 ++ b/linux/include/media/davinci/ccdc_types.h | 43 b/linux/include/media/davinci/dm355_ccdc.h | 336 ++ b/linux/include/media/davinci/dm644x_ccdc.h| 184 + b/linux/include/media/davinci/vpfe_capture.h | 188 + b/linux/include/media/davinci/vpfe_types.h | 51 b/linux/include/media/davinci/vpss.h | 69 linux/drivers/media/video/Kconfig | 49 linux/drivers/media/video/Makefile |2 linux/drivers/media/video/davinci/vpfe_capture.c | 27 linux/drivers/media/video/tvp514x.c| 879 ++ linux/drivers/media/video/tvp514x_regs.h | 10 linux/include/media/tvp514x.h |4 v4l/versions.txt |7 21 files changed, 6346 insertions(+), 555 deletions(-) Cheers, Mauro -- 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: [PULL] http://www.linuxtv.org/hg/~hverkuil/v4l-dvb-vpfe-cap
Mauro, Thanks for looking into this. - tvp514x: Migration to sub-device framework As already pointed, here we have those comments regression. Also, some functions were changed, but the comments still mentions the older parameters. Please fix it on a later patch. I had sent a patch to fix the comment formatting. If you wish, you could apply it and wait for another that fix the old parameter descriptions. - v4l: vpfe capture bridge driver for DM355 and DM6446 - vpfe_capture: add missing newlines and fix an incorrect error code. - v4l: ccdc hw device header file for vpfe capture - v4l: dm355 ccdc module for vpfe capture driver Hmm... +#define CCDC_CID_R_GAIN(V4L2_CID_PRIVATE_BASE + 0) +#define CCDC_CID_GR_GAIN (V4L2_CID_PRIVATE_BASE + 1) +#define CCDC_CID_GB_GAIN (V4L2_CID_PRIVATE_BASE + 2) +#define CCDC_CID_B_GAIN(V4L2_CID_PRIVATE_BASE + 3) This is not nice. Such gains are common to other webcam drivers, and should be part of the common part of V4L2 API. In fact, currently, we have it mapped as a general gain as red/blue balance. +#define CCDC_CID_OFFSET(V4L2_CID_PRIVATE_BASE + 4) What does it control? This is to adjust the black level I suppose. But I will re-visit it when I do control IOCTL handling as per Hans comment against the patch. +#define CCDC_CID_MAX (V4L2_CID_PRIVATE_BASE + 5) This one doesn't seem to be used. This is part of my TODO list as per comments from Hans. So could we merge this and later fix it as part another patch that adds control ioctl handling? - v4l: dm644x ccdc module for vpfe capture driver - v4l: ccdc types used across ccdc modules for vpfe capture driver - v4l: common vpss module for video drivers - v4l: Makefile and config files for vpfe capture driver - v4l: davinci drivers should only be compiled for kernels = 2.6.31. The other patches are ok. Hopefully these changes can be merged into 2.6.31. After having the entire series committed, I'll see if it is still possible to submit it. There are two arch/arm patches that need to be applied to the git tree. These patches should be applied last. They are: http://patchwork.kernel.org/patch/30968/ http://patchwork.kernel.org/patch/30974/ Note that I had to move patch 9 (vpss) in the original patch series before patch 6 (the Makefile changes) to make sure everything would still compile. Thanks, Hans diffstat: b/linux/drivers/media/video/davinci/Makefile |9 b/linux/drivers/media/video/davinci/ccdc_hw_device.h | 110 b/linux/drivers/media/video/davinci/dm355_ccdc.c | 1163 + b/linux/drivers/media/video/davinci/dm355_ccdc_regs.h | 310 ++ b/linux/drivers/media/video/davinci/dm644x_ccdc.c | 878 ++ b/linux/drivers/media/video/davinci/dm644x_ccdc_regs.h | 145 + b/linux/drivers/media/video/davinci/vpfe_capture.c | 2136 + b/linux/drivers/media/video/davinci/vpss.c | 301 ++ b/linux/include/media/davinci/ccdc_types.h | 43 b/linux/include/media/davinci/dm355_ccdc.h | 336 ++ b/linux/include/media/davinci/dm644x_ccdc.h| 184 + b/linux/include/media/davinci/vpfe_capture.h | 188 + b/linux/include/media/davinci/vpfe_types.h | 51 b/linux/include/media/davinci/vpss.h | 69 linux/drivers/media/video/Kconfig | 49 linux/drivers/media/video/Makefile |2 linux/drivers/media/video/davinci/vpfe_capture.c | 27 linux/drivers/media/video/tvp514x.c| 879 ++ linux/drivers/media/video/tvp514x_regs.h | 10 linux/include/media/tvp514x.h |4 v4l/versions.txt |7 21 files changed, 6346 insertions(+), 555 deletions(-) Cheers, Mauro -- 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: [PULL] http://www.linuxtv.org/hg/~hverkuil/v4l-dvb-rds
Em Sat, 20 Jun 2009 14:30:41 +0200 Hans Verkuil hverk...@xs4all.nl escreveu: Hi Mauro, Please pull from http://www.linuxtv.org/hg/~hverkuil/v4l-dvb-rds for the following: - v4l2: add RDS API to videodev2.h - v4l2-spec: finalize the RDS specification. From: Hans Verkuil hverk...@xs4all.nl Priority: normal Signed-off-by: Hans Verkuil hverk...@xs4all.nl --- a/v4l2-spec/biblio.sgml Sat Jun 20 10:37:27 2009 +0200 +++ b/v4l2-spec/biblio.sgml Sat Jun 20 10:49:43 2009 +0200 @@ -158,54 +158,23 @@ 1125-Line High-Definition Production/t 1125-Line High-Definition Production/title /biblioentry -biblioentry id=v4l - abbrevV4L/abbrev +biblioentry id=en50067 + abbrevENnbsp;50067/abbrev authorgroup - author - firstnameAlan/firstname - surnameCox/surname - affiliation - orgnameRed Hat, Inc./orgname - address - emaila...@redhat.com/email - /address - /affiliation - /author + corpauthorEuropean Committee for Electrotechnical Standardization +(ulink url=http://www.cenelec.eu;http://www.cenelec.eu/ulink)/corpauthor /authorgroup - titleVideo4Linux API Specification/title - abstract - paraThis file is part of the Linux kernel sources under -filenameDocumentation/video4linux/filename./para - /abstract + titleSpecification of the radio data system (RDS) for VHF/FM sound broadcasting +in the frequency range from 87,5 to 108,0 MHz/title /biblioentry -biblioentry id=v4lprog - abbrevV4LPROG/abbrev +biblioentry id=nrsc4 + abbrevNRSC-4/abbrev authorgroup - author - firstnameAlan/firstname - surnameCox/surname - affiliation - orgnameRed Hat, Inc./orgname - address - emaila...@redhat.com/email - /address - /affiliation - /author + corpauthorNational Radio Systems Committee +(ulink url=http://www.nrscstandards.org;http://www.nrscstandards.org/ulink)/corpauthor /authorgroup - titleVideo4Linux Programming (a.k.a. The Video4Linux -Book)/title - abstract - paraAbout V4L emphasisdriver/emphasis programming. This -book is part of the Linux kernel DocBook documentation, for example at -ulink url=http://kernelnewbies.org/documents/; -http://kernelnewbies.org/documents//ulink. SGML sources are included -in the kernel sources./para - /abstract - copyright - year2000/year - holderAlan Cox/holder - /copyright + titleNTSC-4: United States RBDS Standard/title /biblioentry /bibliography Hmm.. why are you removing Alan Cox authorship, and adding other organizations there? AFAIK, they never submitted a contribution to V4L2 API, nor I have their and Alan Ack/SOB, that are required for such changes. --- a/v4l2-spec/compat.sgml Sat Jun 20 10:37:27 2009 +0200 +++ b/v4l2-spec/compat.sgml Sat Jun 20 10:49:43 2009 +0200 @@ -1273,9 +1273,8 @@ request code, thus older V4L2 devices wi request code, thus older V4L2 devices will respond with an EINVAL; to the new VIDIOC-QUERYCAP; ioctl./para - paraThere are new fields to identify the driver, a new (as -of yet unspecified) device function -constantV4L2_CAP_RDS_CAPTURE/constant, the + paraThere are new fields to identify the driver, a new RDS +device function constantV4L2_CAP_RDS_CAPTURE/constant, the constantV4L2_CAP_AUDIO/constant flag indicates if the device has any audio connectors, another I/O capability constantV4L2_CAP_ASYNCIO/constant can be flagged. In response to @@ -2291,6 +2290,15 @@ was renamed to structname id=v4l2-chip- /listitem listitem paraNew control constantV4L2_CID_COLORFX/constant was added./para + /listitem + /orderedlist + /section +section + titleV4L2 in Linux 2.6.32/title + orderedlist + listitem + paraFinalized the RDS capture API. See xref linkend=rds for +more information./para /listitem /orderedlist /section --- a/v4l2-spec/dev-rds.sgml Sat Jun 20 10:37:27 2009 +0200 +++ b/v4l2-spec/dev-rds.sgml Sat Jun 20 10:49:43 2009 +0200 @@ -2,38 +2,154 @@ paraThe Radio Data System transmits supplementary information in binary format, for example the station name or travel -information, on a inaudible audio subcarrier of a radio program. This -interface aims at devices capable of receiving and decoding RDS +information, on an inaudible audio subcarrier of a radio program. This +interface is aimed at devices capable of receiving and decoding RDS information./para - paraThe V4L API defines its RDS API as follows./para + paraFor more information see the core RDS standard xref linkend=en50067 +and the RBDS standard xref linkend=nrsc4./para - paraFrom radio devices supporting it, RDS data can be read -with the func-read; function. The
Re: [PULL] http://www.linuxtv.org/hg/~hverkuil/v4l-dvb-vpfe-cap
Em Tue, 30 Jun 2009 10:06:17 -0500 Karicheri, Muralidharan m-kariche...@ti.com escreveu: - tvp514x: Migration to sub-device framework As already pointed, here we have those comments regression. Also, some functions were changed, but the comments still mentions the older parameters. Please fix it on a later patch. I had sent a patch to fix the comment formatting. If you wish, you could apply it and wait for another that fix the old parameter descriptions. Fine. It would be better if Hans could add this on his tree, for me to import it together with the other patches. Hmm... +#define CCDC_CID_R_GAIN(V4L2_CID_PRIVATE_BASE + 0) +#define CCDC_CID_GR_GAIN (V4L2_CID_PRIVATE_BASE + 1) +#define CCDC_CID_GB_GAIN (V4L2_CID_PRIVATE_BASE + 2) +#define CCDC_CID_B_GAIN(V4L2_CID_PRIVATE_BASE + 3) This is not nice. Such gains are common to other webcam drivers, and should be part of the common part of V4L2 API. In fact, currently, we have it mapped as a general gain as red/blue balance. +#define CCDC_CID_OFFSET(V4L2_CID_PRIVATE_BASE + 4) What does it control? This is to adjust the black level I suppose. But I will re-visit it when I do control IOCTL handling as per Hans comment against the patch. In the specific case of the userspace API changes like the above, I prefer to have it merged at the original patch Cheers, Mauro -- 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: [PULL] http://www.linuxtv.org/hg/~hverkuil/v4l-dvb-vpfe-cap
I had sent a patch to fix the comment formatting. If you wish, you could apply it and wait for another that fix the old parameter descriptions. Fine. It would be better if Hans could add this on his tree, for me to import it together with the other patches. I have done so. Hmm... +#define CCDC_CID_R_GAIN(V4L2_CID_PRIVATE_BASE + 0) +#define CCDC_CID_GR_GAIN (V4L2_CID_PRIVATE_BASE + 1) +#define CCDC_CID_GB_GAIN (V4L2_CID_PRIVATE_BASE + 2) +#define CCDC_CID_B_GAIN(V4L2_CID_PRIVATE_BASE + 3) This is not nice. Such gains are common to other webcam drivers, and should be part of the common part of V4L2 API. In fact, currently, we have it mapped as a general gain as red/blue balance. +#define CCDC_CID_OFFSET(V4L2_CID_PRIVATE_BASE + 4) What does it control? This is to adjust the black level I suppose. But I will re-visit it when I do control IOCTL handling as per Hans comment against the patch. In the specific case of the userspace API changes like the above, I prefer to have it merged at the original patch So do you expect anything from me on this or will be merged as is? I prefer the second option and I can send another patch to remove this code. Cheers, Mauro -- 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: [PULL] http://www.linuxtv.org/hg/~hverkuil/v4l-dvb-vpfe-cap
Em Tue, 30 Jun 2009 11:50:29 -0500 Karicheri, Muralidharan m-kariche...@ti.com escreveu: I had sent a patch to fix the comment formatting. If you wish, you could apply it and wait for another that fix the old parameter descriptions. Fine. It would be better if Hans could add this on his tree, for me to import it together with the other patches. I have done so. Hmm... +#define CCDC_CID_R_GAIN(V4L2_CID_PRIVATE_BASE + 0) +#define CCDC_CID_GR_GAIN (V4L2_CID_PRIVATE_BASE + 1) +#define CCDC_CID_GB_GAIN (V4L2_CID_PRIVATE_BASE + 2) +#define CCDC_CID_B_GAIN(V4L2_CID_PRIVATE_BASE + 3) This is not nice. Such gains are common to other webcam drivers, and should be part of the common part of V4L2 API. In fact, currently, we have it mapped as a general gain as red/blue balance. +#define CCDC_CID_OFFSET(V4L2_CID_PRIVATE_BASE + 4) What does it control? This is to adjust the black level I suppose. But I will re-visit it when I do control IOCTL handling as per Hans comment against the patch. In the specific case of the userspace API changes like the above, I prefer to have it merged at the original patch So do you expect anything from me on this or will be merged as is? I prefer the second option and I can send another patch to remove this code. Hmm... the second option is ok, provided that it is at the same pull request of the original patch. I don't want to duplicate controls for existing features. You should note that I'm not asking you to remove that code, but just to use the already existing color balance ioctls, for the existing features, or otherwise to discuss the need of extra controls. The case of image color controlling, we already have several controls: #define V4L2_CID_SATURATION (V4L2_CID_BASE+2) #define V4L2_CID_RED_BALANCE(V4L2_CID_BASE+14) #define V4L2_CID_BLUE_BALANCE (V4L2_CID_BASE+15) #define V4L2_CID_GAMMA (V4L2_CID_BASE+16) #define V4L2_CID_GAIN (V4L2_CID_BASE+19) Also, some got deprecated, since they were just duplicating existing controls, using a different way, as discussed at ML: #define V4L2_CID_BLACK_LEVEL(V4L2_CID_BASE+11) /* Deprecated */ #define V4L2_CID_WHITENESS (V4L2_CID_GAMMA) /* Deprecated */ So, you basically need to rewrite your logic in order to control the device in terms of gain and red/blue balance. Cheers, Mauro -- 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: [PULL] http://www.linuxtv.org/hg/~hverkuil/v4l-dvb-vpfe-cap
Mauro, Thanks for responding... You should note that I'm not asking you to remove that code, but just to use the already existing color balance ioctls, for the existing features, or otherwise to discuss the need of extra controls. Ok. The case of image color controlling, we already have several controls: #define V4L2_CID_SATURATION (V4L2_CID_BASE+2) #define V4L2_CID_RED_BALANCE(V4L2_CID_BASE+14) #define V4L2_CID_BLUE_BALANCE (V4L2_CID_BASE+15) #define V4L2_CID_GAMMA (V4L2_CID_BASE+16) #define V4L2_CID_GAIN (V4L2_CID_BASE+19) Also, some got deprecated, since they were just duplicating existing controls, using a different way, as discussed at ML: Ok. I need to investigate this when I support control IOCTLs in vpfe capture. As of now control IOCTLs are not supported in vpfe capture. #define V4L2_CID_BLACK_LEVEL(V4L2_CID_BASE+11) /* Deprecated */ #define V4L2_CID_WHITENESS (V4L2_CID_GAMMA) /* Deprecated */ So, you basically need to rewrite your logic in order to control the device in terms of gain and red/blue balance. Ok. I get it. Hans had an issue with the way we implemented control IOCTL handling in the driver. So the piece of code you had objected to is redundant. I will clean it up or modify it when I support control IOCTLs handling in vpfe capture or alternately remove it using a separate patch. So please go ahead and merge the patches if everything else looks good. Thanks once again for your help. Regards, Murali Cheers, Mauro -- 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: [PULL] http://www.linuxtv.org/hg/~hverkuil/v4l-dvb-subdev2
Em Fri, 26 Jun 2009 08:52:58 +0200 Hans Verkuil hverk...@xs4all.nl escreveu: On Friday 26 June 2009 08:17:05 Hans Verkuil wrote: On Thursday 25 June 2009 20:18:06 Karicheri, Muralidharan wrote: Hans, I have tried to pull the latest from git://git.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-2.6.git It is there, at for_linus branch. If you pull master branch, you'll just get a (probably outdated) copy of Linus tree. I can't see it part of this. Which GIT tree can I use to see the sub dev api changes or latest that went into 2.6.31? Is vpfe capture part of 2.6.31? Ah, it is not yet pulled into the git tree. Mauro did send a pull request for this to Linus, though. So I hope it will appear soon. Oops, I didn't look carefully enough. These API changes *are* merged in 2.6.31. I'm using Linus' git tree. Cheers, Mauro -- 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: [PULL] http://www.linuxtv.org/hg/~hverkuil/v4l-dvb-subdev2
On Friday 26 June 2009 08:17:05 Hans Verkuil wrote: On Thursday 25 June 2009 20:18:06 Karicheri, Muralidharan wrote: Hans, I have tried to pull the latest from git://git.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-2.6.git I can't see it part of this. Which GIT tree can I use to see the sub dev api changes or latest that went into 2.6.31? Is vpfe capture part of 2.6.31? Ah, it is not yet pulled into the git tree. Mauro did send a pull request for this to Linus, though. So I hope it will appear soon. Oops, I didn't look carefully enough. These API changes *are* merged in 2.6.31. I'm using Linus' git tree. Regards, Hans Regards, Hans Thanks. Murali Karicheri Software Design Engineer Texas Instruments Inc. Germantown, MD 20874 email: m-kariche...@ti.com -Original Message- From: Hans Verkuil [mailto:hverk...@xs4all.nl] Sent: Thursday, June 25, 2009 11:18 AM To: Karicheri, Muralidharan Cc: linux-media@vger.kernel.org; Mauro Carvalho Chehab Subject: RE: [PULL] http://www.linuxtv.org/hg/~hverkuil/v4l-dvb-subdev2 Hi, Mauro, I am using the v4l2_i2c_new_subdev_board() API for the next set of vpfe capture driver patches. So when do you think this will be merged? This has already been merged and is also in the 2.6.31 git tree. I'm very pleased that this is in as that will make life easier for several embedded system developments. Regards, Hans Murali Karicheri Software Design Engineer Texas Instruments Inc. Germantown, MD 20874 email: m-kariche...@ti.com -Original Message- From: linux-media-ow...@vger.kernel.org [mailto:linux-media- ow...@vger.kernel.org] On Behalf Of Hans Verkuil Sent: Saturday, June 20, 2009 9:11 AM To: linux-media@vger.kernel.org Cc: Mauro Carvalho Chehab Subject: Re: [PULL] http://www.linuxtv.org/hg/~hverkuil/v4l-dvb-subdev2 On Tuesday 09 June 2009 22:40:35 Hans Verkuil wrote: Hi Mauro, Please pull from http://www.linuxtv.org/hg/~hverkuil/v4l-dvb-subdev2 for the following: - v4l2: add new s_config subdev ops and v4l2_i2c_new_subdev_cfg/board calls - v4l2-device: fix incorrect kernel check - v4l-compat: add I2C_ADDRS macro. - v4l2: update framework documentation. - v4l2-subdev: remove unnecessary check This time I've only added new functions and left the existing ones in place. I did add a bit of code to the existing v4l2_i2c_new_(probed_)subdev functions to call the new s_config op if it is available. Existing subdev drivers never set this new op, so this code will not effect current behavior. But for new drivers that do set s_config it is important that it is called no matter what flavor of these functions is used. At the end of the 2.6.31 cycle we can replace the current v4l2_i2c_new_(probed_)subdev calls with the new one I had in my earlier patches. Hi Mauro, I've posted these changes as an RFC more than a week ago, but since there were no comments I hope you can pull from this tree for 2.6.31. I would really, really like to get this into 2.6.31. It will help anyone who is working with subdevs on embedded platforms. Regards, Hans Thanks, Hans diffstat: linux/Documentation/video4linux/v4l2-framework.txt | 24 +++ linux/drivers/media/video/v4l2-common.c| 166 + linux/drivers/media/video/v4l2-device.c|2 linux/include/media/v4l2-common.h | 18 ++ linux/include/media/v4l2-subdev.h |9 - v4l/compat.h |6 6 files changed, 222 insertions(+), 3 deletions(-) -- Hans Verkuil - video4linux developer - sponsored by TANDBERG Telecom -- 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 -- Hans Verkuil - video4linux developer - sponsored by TANDBERG -- Hans Verkuil - video4linux developer - sponsored by TANDBERG Telecom -- 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: [PULL] http://www.linuxtv.org/hg/~hverkuil/v4l-dvb-misc
On Tuesday 23 June 2009 08:45:51 Hans Verkuil wrote: Hi Mauro, Please pull from http://www.linuxtv.org/hg/~hverkuil/v4l-dvb-misc for the following: - v4l2-spec: add missing V4L2_PIX_FMT_OV511 documentation. Added this patch: - v4l2-common: fix uninitialized variable Note that this variable was only uninitialized when compiled for kernels older than 2.6.26. Regards, Hans Hans, when you modify the videodev2.h header you should also do a 'make spec' to check whether the v4l2-spec still builds. It's easy to forget that, but it's important to keep the spec up to date. Thanks, Hans diffstat: pixfmt.sgml |7 ++- 1 file changed, 6 insertions(+), 1 deletion(-) -- Hans Verkuil - video4linux developer - sponsored by TANDBERG Telecom -- 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: [PULL] http://www.linuxtv.org/hg/~hverkuil/v4l-dvb-misc
On Tuesday 23 June 2009 08:45:51 Hans Verkuil wrote: Hi Mauro, Please pull from http://www.linuxtv.org/hg/~hverkuil/v4l-dvb-misc for the following: - v4l2-spec: add missing V4L2_PIX_FMT_OV511 documentation. Added this patch: - v4l2-common: fix uninitialized variable Note that this variable was only uninitialized when compiled for kernels older than 2.6.26. And this patch: - em28xx: enable new-style i2c API for kernels = 2.6.26, not 2.6.22. This fixes the em28xx driver when v4l-dvb is compiled for kernels 2.6.22-2.6.25. Regards, Hans -- Hans Verkuil - video4linux developer - sponsored by TANDBERG -- 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: [PULL] http://www.linuxtv.org/hg/~hverkuil/v4l-dvb-dm646x
On Friday 26 June 2009 21:01:50 Hans Verkuil wrote: Hi Mauro, Please pull from http://www.linuxtv.org/hg/~hverkuil/v4l-dvb-dm646x for the following: - ARM: DaVinci: DM646x Video: VPIF driver - ARM: DaVinci: DM646x Video: Add VPIF display driver - ARM: DaVinci: DM646x Video: Makefile and config files modifications for Display - ARM: DaVinci: DM646x Video: Fix compile time warnings for mutex locking Minor update: by request from Kevin I've removed the 'ARM: ' prefix in the patch subject lines. Regards, Hans -- Hans Verkuil - video4linux developer - sponsored by TANDBERG Telecom -- 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: [PULL] http://www.linuxtv.org/hg/~hverkuil/v4l-dvb-subdev2
Hi, Mauro, I am using the v4l2_i2c_new_subdev_board() API for the next set of vpfe capture driver patches. So when do you think this will be merged? Murali Karicheri Software Design Engineer Texas Instruments Inc. Germantown, MD 20874 email: m-kariche...@ti.com -Original Message- From: linux-media-ow...@vger.kernel.org [mailto:linux-media- ow...@vger.kernel.org] On Behalf Of Hans Verkuil Sent: Saturday, June 20, 2009 9:11 AM To: linux-media@vger.kernel.org Cc: Mauro Carvalho Chehab Subject: Re: [PULL] http://www.linuxtv.org/hg/~hverkuil/v4l-dvb-subdev2 On Tuesday 09 June 2009 22:40:35 Hans Verkuil wrote: Hi Mauro, Please pull from http://www.linuxtv.org/hg/~hverkuil/v4l-dvb-subdev2 for the following: - v4l2: add new s_config subdev ops and v4l2_i2c_new_subdev_cfg/board calls - v4l2-device: fix incorrect kernel check - v4l-compat: add I2C_ADDRS macro. - v4l2: update framework documentation. - v4l2-subdev: remove unnecessary check This time I've only added new functions and left the existing ones in place. I did add a bit of code to the existing v4l2_i2c_new_(probed_)subdev functions to call the new s_config op if it is available. Existing subdev drivers never set this new op, so this code will not effect current behavior. But for new drivers that do set s_config it is important that it is called no matter what flavor of these functions is used. At the end of the 2.6.31 cycle we can replace the current v4l2_i2c_new_(probed_)subdev calls with the new one I had in my earlier patches. Hi Mauro, I've posted these changes as an RFC more than a week ago, but since there were no comments I hope you can pull from this tree for 2.6.31. I would really, really like to get this into 2.6.31. It will help anyone who is working with subdevs on embedded platforms. Regards, Hans Thanks, Hans diffstat: linux/Documentation/video4linux/v4l2-framework.txt | 24 +++ linux/drivers/media/video/v4l2-common.c| 166 + linux/drivers/media/video/v4l2-device.c|2 linux/include/media/v4l2-common.h | 18 ++ linux/include/media/v4l2-subdev.h |9 - v4l/compat.h |6 6 files changed, 222 insertions(+), 3 deletions(-) -- Hans Verkuil - video4linux developer - sponsored by TANDBERG Telecom -- 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
