Re: [REVIEW PATCH 3/5] v4l2: pass std by value to the write-only s_std ioctl.
Hi Hans On Fri, 15 Mar 2013, Hans Verkuil wrote: From: Hans Verkuil hans.verk...@cisco.com This ioctl is defined as IOW, so pass the argument by value instead of by reference. I could have chosen to add const instead, but this is 1) easier to handle in drivers and 2) consistent with the s_std subdev operation. Signed-off-by: Hans Verkuil hans.verk...@cisco.com --- [snip] drivers/media/platform/sh_vou.c | 12 ++-- drivers/media/platform/soc_camera/soc_camera.c |4 ++-- For the above two: Acked-by: Guennadi Liakhovetski g.liakhovet...@gmx.de 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: [REVIEW PATCH 4/5] v4l2: add const to argument of write-only s_register ioctl.
On Fri, 15 Mar 2013, Hans Verkuil wrote: From: Hans Verkuil hans.verk...@cisco.com This ioctl is defined as IOW, so pass the argument as const. Signed-off-by: Hans Verkuil hans.verk...@cisco.com --- [snip] drivers/media/i2c/soc_camera/mt9m001.c |2 +- drivers/media/i2c/soc_camera/mt9m111.c |2 +- drivers/media/i2c/soc_camera/mt9t031.c |2 +- drivers/media/i2c/soc_camera/mt9t112.c |2 +- drivers/media/i2c/soc_camera/mt9v022.c |2 +- drivers/media/i2c/soc_camera/ov2640.c |2 +- drivers/media/i2c/soc_camera/ov5642.c |2 +- drivers/media/i2c/soc_camera/ov6650.c |2 +- drivers/media/i2c/soc_camera/ov772x.c |2 +- drivers/media/i2c/soc_camera/ov9640.c |2 +- drivers/media/i2c/soc_camera/ov9740.c |2 +- drivers/media/i2c/soc_camera/rj54n1cb0c.c |2 +- drivers/media/i2c/soc_camera/tw9910.c |2 +- [snip] drivers/media/platform/sh_vou.c |2 +- drivers/media/platform/soc_camera/soc_camera.c |2 +- For the above Acked-by: Guennadi Liakhovetski g.liakhovet...@gmx.de 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: [REVIEW PATCH 3/5] v4l2: pass std by value to the write-only s_std ioctl.
Hi Hans, Thanks for the patch! On Fri, Mar 15, 2013 at 3:57 PM, Hans Verkuil hverk...@xs4all.nl wrote: From: Hans Verkuil hans.verk...@cisco.com This ioctl is defined as IOW, so pass the argument by value instead of by reference. I could have chosen to add const instead, but this is 1) easier to handle in drivers and 2) consistent with the s_std subdev operation. Signed-off-by: Hans Verkuil hans.verk...@cisco.com --- [snip] drivers/media/platform/davinci/vpbe.c |8 drivers/media/platform/davinci/vpbe_display.c |2 +- drivers/media/platform/davinci/vpfe_capture.c | 12 ++-- drivers/media/platform/davinci/vpif_capture.c |6 +++--- drivers/media/platform/davinci/vpif_display.c | 10 +- [snip] drivers/staging/media/davinci_vpfe/vpfe_video.c |6 +++--- For the above Acked-by: Lad, Prabhakar prabhakar.cse...@gmail.com Cheers, --Prabhakar Lad http://www.linkedin.com/pub/prabhakar-lad/19/92b/955 -- 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: [REVIEW PATCH 4/5] v4l2: add const to argument of write-only s_register ioctl.
Hi Hans, Thanks for the patch! On Fri, Mar 15, 2013 at 3:57 PM, Hans Verkuil hverk...@xs4all.nl wrote: From: Hans Verkuil hans.verk...@cisco.com This ioctl is defined as IOW, so pass the argument as const. Signed-off-by: Hans Verkuil hans.verk...@cisco.com --- [snip] drivers/media/platform/davinci/vpbe_display.c |2 +- drivers/media/platform/davinci/vpif_capture.c |3 +- drivers/media/platform/davinci/vpif_display.c |3 +- For the above Acked-by: Lad, Prabhakar prabhakar.cse...@gmail.com Cheers, --Prabhakar Lad http://www.linkedin.com/pub/prabhakar-lad/19/92b/955 -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3] media: davinci: kconfig: fix incorrect selects
Hi Sekhar, Thanks for the patch! On Tue, Mar 12, 2013 at 2:44 PM, Sekhar Nori nsek...@ti.com wrote: drivers/media/platform/davinci/Kconfig uses selects where it should be using 'depends on'. This results in warnings of the following sort when doing randconfig builds. warning: (VIDEO_DM6446_CCDC VIDEO_DM355_CCDC VIDEO_ISIF VIDEO_DAVINCI_VPBE_DISPLAY) selects VIDEO_VPSS_SYSTEM which has unmet direct dependencies (MEDIA_SUPPORT V4L_PLATFORM_DRIVERS ARCH_DAVINCI) The VPIF kconfigs had a strange 'select' and 'depends on' cross linkage which have been fixed as well by removing unneeded VIDEO_DAVINCI_VPIF config symbol. Similarly, remove the unnecessary VIDEO_VPSS_SYSTEM and VIDEO_VPFE_CAPTURE. They don't select any independent functionality and were being used to manage code dependencies which can be handled using makefile. Selecting video modules is now dependent on all ARCH_DAVINCI instead of specific EVMs and SoCs earlier. This should help build coverage. Remove unnecessary 'default y' for some config symbols. While at it, fix the Kconfig help text to make it more readable and fix names of modules created during module build. Rename VIDEO_ISIF to VIDEO_DM365_ISIF as per suggestion from Prabhakar. This patch has only been build tested; I have tried to not break any existing assumptions. I do not have the setup to test video, so any test reports welcome. The series which I posted yesterday [1] for DM365 VPBE, uses a exported symbol 'vpss_enable_clock' so If I build vpbe as module it complains for following, arch/arm/mach-davinci/built-in.o: In function `dm365_venc_setup_clock': pm_domain.c:(.text+0x302c): undefined reference to `vpss_enable_clock' pm_domain.c:(.text+0x3038): undefined reference to `vpss_enable_clock' pm_domain.c:(.text+0x3060): undefined reference to `vpss_enable_clock' pm_domain.c:(.text+0x306c): undefined reference to `vpss_enable_clock' So how would you suggest to handle this VPSS config ? [1] http://www.mail-archive.com/davinci-linux-open-source@linux.davincidsp.com/msg25443.html Regards, --Prabhakar Reported-by: Russell King rmk+ker...@arm.linux.org.uk Signed-off-by: Sekhar Nori nsek...@ti.com --- Since v2, revisited config prompt texts and made them more meaningful/consistent. drivers/media/platform/davinci/Kconfig | 103 +++ drivers/media/platform/davinci/Makefile | 17 ++--- 2 files changed, 41 insertions(+), 79 deletions(-) diff --git a/drivers/media/platform/davinci/Kconfig b/drivers/media/platform/davinci/Kconfig index ccfde4e..c50d31d 100644 --- a/drivers/media/platform/davinci/Kconfig +++ b/drivers/media/platform/davinci/Kconfig @@ -1,79 +1,47 @@ config VIDEO_DAVINCI_VPIF_DISPLAY - tristate DM646x/DA850/OMAPL138 EVM Video Display - depends on VIDEO_DEV (MACH_DAVINCI_DM6467_EVM || MACH_DAVINCI_DA850_EVM) + tristate TI DaVinci VPIF V4L2-Display driver + depends on VIDEO_DEV ARCH_DAVINCI select VIDEOBUF2_DMA_CONTIG - select VIDEO_DAVINCI_VPIF select VIDEO_ADV7343 if MEDIA_SUBDRV_AUTOSELECT select VIDEO_THS7303 if MEDIA_SUBDRV_AUTOSELECT help Enables Davinci VPIF module used for display devices. - This module is common for following DM6467/DA850/OMAPL138 - based display devices. + This module is used for display on TI DM6467/DA850/OMAPL138 + SoCs. - To compile this driver as a module, choose M here: the - module will be called vpif_display. + To compile this driver as a module, choose M here. There will + be two modules called vpif.ko and vpif_display.ko config VIDEO_DAVINCI_VPIF_CAPTURE - tristate DM646x/DA850/OMAPL138 EVM Video Capture - depends on VIDEO_DEV (MACH_DAVINCI_DM6467_EVM || MACH_DAVINCI_DA850_EVM) + tristate TI DaVinci VPIF video capture driver + depends on VIDEO_DEV ARCH_DAVINCI select VIDEOBUF2_DMA_CONTIG - select VIDEO_DAVINCI_VPIF help - Enables Davinci VPIF module used for captur devices. - This module is common for following DM6467/DA850/OMAPL138 - based capture devices. + Enables Davinci VPIF module used for capture devices. + This module is used for capture on TI DM6467/DA850/OMAPL138 + SoCs. - To compile this driver as a module, choose M here: the - module will be called vpif_capture. + To compile this driver as a module, choose M here. There will + be two modules called vpif.ko and vpif_capture.ko -config VIDEO_DAVINCI_VPIF - tristate DaVinci VPIF Driver - depends on VIDEO_DAVINCI_VPIF_DISPLAY || VIDEO_DAVINCI_VPIF_CAPTURE - help - Support for DaVinci VPIF Driver. - - To compile this driver as a module, choose M here: the - module will be called vpif. - -config VIDEO_VPSS_SYSTEM - tristate VPSS
Re: [REVIEW PATCH 2/5] v4l2: add const to argument of write-only s_tuner ioctl.
Hi Hans, On Fri, Mar 15, 2013 at 2:27 PM, Hans Verkuil hverk...@xs4all.nl wrote: From: Hans Verkuil hans.verk...@cisco.com This ioctl is defined as IOW, so pass the argument as const. Signed-off-by: Hans Verkuil hans.verk...@cisco.com [snip] drivers/media/radio/dsbr100.c|2 +- drivers/media/radio/radio-ma901.c|2 +- drivers/media/radio/radio-mr800.c|2 +- Acked-by: Alexey Klimov klimov.li...@gmail.com for this three radio drivers. Thanks. -- Best regards, Klimov Alexey -- 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: dvb-apps: Additional channels for Netherlands
On 16-03-13 16:13, Dmitry Katsubo wrote: On 15.03.2013 13:07, Oliver Schinagl wrote: On 698 MHz we have NTS1 (Bouquet 2) which is on a code rate of 1/2. Still I cannot make them working. More exactly: This works (722 MHz): xine dvb://Nederland 1 xine dvb://Nederland 2 xine dvb://Nederland 3 These do not (522 MHz and 698 MHz): xine dvb://Nickelodeon xine dvb://RTL 4 ... I don't 522 or 698 MHz, RTL4 is on 768 MHz here in Eindhoven. Try scanning with w_scan; wscan tells you exactly where what exactly is. It can produce an inital scanning file. Send me and I'll fix it up for you. Thanks for hint. I have tried w_scan, it also does not show the signal level: tune to: QAM_AUTO f = 722000 kHz I999B8C999D999T999G999Y999 (time: 04:48) service = Nederland 1 (Digitenne) service = Nederland 2 (Digitenne) service = Nederland 3 (Digitenne) service = TV West (Digitenne) service = Radio West (Digitenne) service = Radio 1 (Digitenne) service = Radio 2 (Digitenne) service = 3FM (Digitenne) service = Radio 4 (Digitenne) service = Radio 5 (Digitenne) service = Radio 6 (Digitenne) service = FunX (Digitenne) new transponder: (QAM_64 f = 546000 kHz I999B8C12D0T8G4Y0) 0x405A new transponder: (QAM_64 f = 49 kHz I999B8C23D0T8G4Y0) 0x405A new transponder: (QAM_64 f = 474000 kHz I999B8C23D0T8G4Y0) 0x405A updating transponder: (QAM_64 f = 474000 kHz I999B8C23D0T8G4Y0) 0x405A to (QAM_64 f = 474000 kHz I999B8C12D0T8G4Y0) 0x405A new transponder: (QAM_64 f = 506000 kHz I999B8C12D0T8G4Y0) 0x405A I attach my channels.conf, generated by scan utility. It looks to be complete. It can be the case the signal is better on 722 MHz... Could you share your channels.conf? Are there any specific options you pass to scan utility? But it's likely I need to buy better antenna. Can scan utility show the signal level? Try tzap to tune to a channel, depending on your driver, it should output some rudimentary signal strength. tzap shows something in column signal but it is so cryptic: Yes, signal strenght isn't the best to read, but let it run for a little bit. Your ber isn't great but you have unc's UNC = Unrecoverable Error. This can usually be seen on screen or heard. unc should be 0 for 'perfect' image. So it looks like a bad signal reception to me, which could be the reason you are not receiving everything. $ tzap -c channels.conf Nederland 1 using '/dev/dvb/adapter0/frontend0' and '/dev/dvb/adapter0/demux0' reading channels from file 'channels.conf' tuning to 72200 Hz video pid 0x1b63, audio pid 0x1b64 status 0f | signal 8f7d | snr 006e | ber 001f | unc 010a | status 1f | signal 8e9f | snr 007b | ber 000a5010 | unc 000c | FE_HAS_LOCK status 1f | signal 8e2e | snr 0078 | ber 00084ed0 | unc 0005 | FE_HAS_LOCK Signal is indeed important, Remember that RTL4 etc are all encrypted and need a hardware cam or softcam (oscam) to properly work. Now I see! What channels are open? For example, are Nickelodeon and Investigation Discovery opened? What about radio (BBC/Radio West/...)? Nou, only Boequet 1 is Free to Air, that is NL1, NL2, NL3 and Omroep West in your case. The rest is all encrypted! I have found a description about how to watch encrypted DVB-T broadcasts in the Netherlands https://wiki.archlinux.org/index.php/Digitenne and also good oscam tips http://openpli.org/wiki/OScam. The first one reads that I need smartreader + Digitenne smartcard. I see that smartcards are sold on marktplaats for €10 http://www.marktplaats.nl/z/audio-tv-en-foto/smartcard-digitenne.html?query=smartcard+digitennecategoryId=31numberOfResultsPerPage=100. Digitenne claims that there are these channels available: but I don't see even half of them in my channels list. In general that's is a big challenge to make it running on Linux. Perhaps buying a receiver is easier. Have you any experience? Answering this off list, as its too offtopic. Thanks! -- With best regards, Dmitry -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
cron job: media_tree daily build: WARNINGS
This message is generated daily by a cron job that builds media_tree for the kernels and architectures in the list below. Results of the daily build of media_tree: date: Sat Mar 16 19:01:50 CET 2013 git branch: test git hash: 4d35435d3ffb853b491f5bb21a62529cd925d660 gcc version:i686-linux-gcc (GCC) 4.7.2 host hardware: x86_64 host os:3.8.03-marune linux-git-arm-davinci: WARNINGS linux-git-arm-exynos: WARNINGS linux-git-arm-omap: WARNINGS linux-git-blackfin: WARNINGS linux-git-i686: OK linux-git-m32r: OK linux-git-mips: WARNINGS linux-git-powerpc64: OK linux-git-sh: OK linux-git-x86_64: OK linux-2.6.31.14-i686: WARNINGS linux-2.6.32.27-i686: WARNINGS linux-2.6.33.7-i686: WARNINGS linux-2.6.34.7-i686: WARNINGS linux-2.6.35.9-i686: WARNINGS linux-2.6.36.4-i686: WARNINGS linux-2.6.37.6-i686: WARNINGS linux-2.6.38.8-i686: WARNINGS linux-2.6.39.4-i686: WARNINGS linux-3.0.60-i686: WARNINGS linux-3.1.10-i686: WARNINGS linux-3.2.37-i686: WARNINGS linux-3.3.8-i686: WARNINGS linux-3.4.27-i686: WARNINGS linux-3.5.7-i686: WARNINGS linux-3.6.11-i686: WARNINGS linux-3.7.4-i686: WARNINGS linux-3.8-i686: OK linux-3.9-rc1-i686: OK linux-2.6.31.14-x86_64: WARNINGS linux-2.6.32.27-x86_64: WARNINGS linux-2.6.33.7-x86_64: WARNINGS linux-2.6.34.7-x86_64: WARNINGS linux-2.6.35.9-x86_64: WARNINGS linux-2.6.36.4-x86_64: WARNINGS linux-2.6.37.6-x86_64: WARNINGS linux-2.6.38.8-x86_64: WARNINGS linux-2.6.39.4-x86_64: WARNINGS linux-3.0.60-x86_64: WARNINGS linux-3.1.10-x86_64: WARNINGS linux-3.2.37-x86_64: WARNINGS linux-3.3.8-x86_64: WARNINGS linux-3.4.27-x86_64: WARNINGS linux-3.5.7-x86_64: WARNINGS linux-3.6.11-x86_64: WARNINGS linux-3.7.4-x86_64: WARNINGS linux-3.8-x86_64: WARNINGS linux-3.9-rc1-x86_64: WARNINGS apps: WARNINGS spec-git: OK sparse: ERRORS Detailed results are available here: http://www.xs4all.nl/~hverkuil/logs/Saturday.log Full logs are available here: http://www.xs4all.nl/~hverkuil/logs/Saturday.tar.bz2 The Media Infrastructure API from this daily build is here: http://www.xs4all.nl/~hverkuil/spec/media.html -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
