Re: [PATCH 10/15] V4L: Add camera 3A lock control
Hi Sylwester, Sylwester Nawrocki wrote: Hi Sakari, On 04/17/2012 06:09 PM, Sakari Ailus wrote: Hi Sylwester, On Tue, Apr 17, 2012 at 12:09:51PM +0200, Sylwester Nawrocki wrote: The V4L2_CID_3A_LOCK bitmask control allows applications to pause or resume the automatic exposure, focus and wite balance adjustments. It can be used, for example, to lock the 3A adjustments right before a still image is captured, for pre-focus, etc. The applications can control each of the algorithms independently, through a corresponding control bit, if driver allows that. How is disabling e.g. focus algorithm different from locking focus? The difference looks quite obvious to me. When some AUTO control is switched from auto to manual mode there is no guarantee about the related parameters the device will end up. E.g. lens may be positioned into default position, rather than kept at current one, exposure might be set to manual value from before AE was enabled, etc. I've seen separate registers at the sensor interfaces for AE, AWB locking/unlocking and for disabling/enabling those algorithms. With the proposed control applications can be sure that, for example, exposure is retained when the V4L2_CID_3A_LOCK is set. Does it answer your question ? Yes, it does. I was thinking how does the situation really differ from disabling the corresponding automatic algorithm. There may be subtle differences in practice albeit in principle the two are no different. And if some of the sensors implement it as lock, then I guess it gives us few options for the user space interface. -- Sakari Ailus sakari.ai...@iki.fi -- 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
Current status of SuperH soc-camera/CEU driver
Hi Guennadi Now I'm checking Soc-Camera/CEU driver, and I noticed that platform settings (maybe) weren't cared even though driver side was updated. I'm not sure for details, but it makes me misunderstand. Could you please update these ? 1) e1db704326c9a5164da4e24b01e487c0be687fa2 ([media] V4L: sh_mobile_ceu_camera: convert to the new mbus-config subdev operations) This patch removed SH_CEU_FLAG_USE_xxBIT_BUS flags from CEU driver, but below platform still has this flags. arch/sh/boards/mach-ap325rxa/ arch/sh/boards/mach-ecovec24/ arch/sh/boards/mach-kfr2r09/ arch/sh/boards/mach-migor/ arch/sh/boards/mach-se/7724/ arch/arm/mach-shmobile/board-ap4evb.c arch/arm/mach-shmobile/board-mackerel.c 2) ff51345832628eb641805a01213aeae0bb4a23c1 ([media] V4L: mt9t112: remove superfluous soc-camera client operations) this patch remoded MT9T112_FLAG_DATAWIDTH_xx flags from mt9t112 driver, but Ecovec platform still has it. arch/sh/boards/mach-ecovec24/ Best regards --- Kuninori Morimoto -- 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
HVR-1600 QAM recordings with slight glitches in them
Hi, I have an HVR-1600 on a 3GHz dual-core P4 running linux 3.2.0. Whenever I record from clearqam using this card I frequently get small "glitches" in playback. Playing these same files with mplayer yields things like: demux_mpg: 24000/1001fps progressive NTSC content detected, switching framerate. [mpeg2video @ 0x893a2e0]mb incr damaged [mpeg2video @ 0x893a2e0]Warning MVs not available [mpeg2video @ 0x893a2e0]concealing 66 DC, 66 AC, 66 MV errors demux_mpg: 3/1001fps NTSC content detected, switching framerate. Warning! FPS changed 23.976 -> 29.970 (-5.994005) [4] demux_mpg: 24000/1001fps progressive NTSC content detected, switching framerate. demux_mpg: 3/1001fps NTSC content detected, switching framerate. Warning! FPS changed 23.976 -> 29.970 (-5.994005) [4] demux_mpg: 24000/1001fps progressive NTSC content detected, switching framerate. [mpeg2video @ 0x893a2e0]invalid cbp at 4 12 [mpeg2video @ 0x893a2e0]Warning MVs not available [mpeg2video @ 0x893a2e0]concealing 198 DC, 198 AC, 198 MV errors [mpeg2video @ 0x893a2e0]ac-tex damaged at 11 24 [mpeg2video @ 0x893a2e0]Warning MVs not available [mpeg2video @ 0x893a2e0]concealing 99 DC, 99 AC, 99 MV errors demux_mpg: 3/1001fps NTSC content detected, switching framerate. Warning! FPS changed 23.976 -> 29.970 (-5.994005) [4] demux_mpg: 24000/1001fps progressive NTSC content detected, switching framerate. demux_mpg: 3/1001fps NTSC content detected, switching framerate. Warning! FPS changed 23.976 -> 29.970 (-5.994005) [4] demux_mpg: 24000/1001fps progressive NTSC content detected, switching framerate. demux_mpg: 3/1001fps NTSC content detected, switching framerate. Warning! FPS changed 23.976 -> 29.970 (-5.994005) [4] demux_mpg: 24000/1001fps progressive NTSC content detected, switching framerate. demux_mpg: 3/1001fps NTSC content detected, switching framerate. Warning! FPS changed 23.976 -> 29.970 (-5.994005) [4] demux_mpg: 24000/1001fps progressive NTSC content detected, switching framerate. [mpeg2video @ 0x893a2e0]ac-tex damaged at 27 0 [mpeg2video @ 0x893a2e0]ac-tex damaged at 1 1 [mpeg2video @ 0x893a2e0]ac-tex damaged at 6 2 [mpeg2video @ 0x893a2e0]slice mismatch [mpeg2video @ 0x893a2e0]mb incr damaged [mpeg2video @ 0x893a2e0]invalid cbp at 15 6 [mpeg2video @ 0x893a2e0]mb incr damaged [mpeg2video @ 0x893a2e0]ac-tex damaged at 4 8 [mpeg2video @ 0x893a2e0]slice mismatch [mpeg2video @ 0x893a2e0]invalid mb type in B Frame at 21 10 [mpeg2video @ 0x893a2e0]slice mismatch [mpeg2video @ 0x893a2e0]slice mismatch [mpeg2video @ 0x893a2e0]mb incr damaged [mpeg2video @ 0x893a2e0]slice mismatch [mpeg2video @ 0x893a2e0]ac-tex damaged at 12 15 [mpeg2video @ 0x893a2e0]mb incr damaged [mpeg2video @ 0x893a2e0]slice mismatch [mpeg2video @ 0x893a2e0]invalid cbp at 14 18 [mpeg2video @ 0x893a2e0]invalid mb type in B Frame at 12 20 [mpeg2video @ 0x893a2e0]slice mismatch [mpeg2video @ 0x893a2e0]mb incr damaged [mpeg2video @ 0x893a2e0]ac-tex damaged at 1 22 [mpeg2video @ 0x893a2e0]invalid cbp at 1 23 [mpeg2video @ 0x893a2e0]ac-tex damaged at 20 24 [mpeg2video @ 0x893a2e0]invalid cbp at 1 25 [mpeg2video @ 0x893a2e0]mb incr damaged [mpeg2video @ 0x893a2e0]slice mismatch [mpeg2video @ 0x893a2e0]mb incr damaged [mpeg2video @ 0x893a2e0]ac-tex damaged at 13 29 [mpeg2video @ 0x893a2e0]concealing 990 DC, 990 AC, 990 MV errors demux_mpg: 3/1001fps NTSC content detected, switching framerate. Warning! FPS changed 23.976 -> 29.970 (-5.994005) [4] demux_mpg: 24000/1001fps progressive NTSC content detected, switching framerate. demux_mpg: 3/1001fps NTSC content detected, switching framerate. Warning! FPS changed 23.976 -> 29.970 (-5.994005) [4] demux_mpg: 24000/1001fps progressive NTSC content detected, switching framerate. demux_mpg: 3/1001fps NTSC content detected, switching framerate. Warning! FPS changed 23.976 -> 29.970 (-5.994005) [4] demux_mpg: 24000/1001fps progressive NTSC content detected, switching framerate. [mpeg2video @ 0x893a2e0]ac-tex damaged at 14 10 [mpeg2video @ 0x893a2e0]ac-tex damaged at 9 10 [mpeg2video @ 0x893a2e0]invalid mb type in P Frame at 2 11 [mpeg2video @ 0x893a2e0]mb incr damaged [mpeg2video @ 0x893a2e0]ac-tex damaged at 24 14 [mpeg2video @ 0x893a2e0]ac-tex damaged at 9 14 [mpeg2video @ 0x893a2e0]ac-tex damaged at 3 18 [mpeg2video @ 0x893a2e0]ac-tex damaged at 16 16 [mpeg2video @ 0x893a2e0]ac-tex damaged at 10 17 [mpeg2video @ 0x893a2e0]ac-tex damaged at 10 18 [mpeg2video @ 0x893a2e0]invalid mb type in P Frame at 9 20 [mpeg2video @ 0x893a2e0]ac-tex damaged at 10 20 [mpeg2video @ 0x893a2e0]ac-tex damaged at 11 22 [mpeg2video @ 0x893a2e0]invalid cbp at 1 22 [mpeg2video @ 0x893a2e0]ac-tex damaged at 8 23 [mpeg2video @ 0x893a2e0]ac-tex damaged at 3 24 [mpeg2video @ 0x893a2e0]invalid cbp at 2 26 [mpeg2video @ 0x893a2e0]ac-tex damaged at 9 26 [mpeg2video @ 0x893a2e0]ac-tex damaged at 0 27 [mpeg2video @ 0x893a2e0]ac-tex damaged at 0 28 [mpeg2video @ 0x893a2e0]ac-tex damaged at 0 29 [mpeg2v
Problem with az007 and resume from suspend
When resume from suspend I get: [83245.571382] dvb-usb: found a 'TerraTec DTV StarBox DVB-T/C USB2.0 (az6007)' in cold state, will try to load a firmware [83245.571391] [ cut here ] [83245.571403] WARNING: at drivers/base/firmware_class.c:537 _request_firmware+0xea/0x3e5() [83245.571408] Hardware name: System Product Name [83245.571411] Modules linked in: mt2063(O) drxk(O) dvb_usb_az6007(O) hidp fuse ext2 nfsd lockd nfs_acl auth_rpcgss sunrpc p4_clockmod freq_table speedstep_lib rfcomm bnep rc_nec_terratec_cinergy_xs(O) nvidia(P) mxl5007t(O) ir_lirc_codec(O) lirc_dev(O) ir_mce_kbd_decoder(O) ir_sanyo_decoder(O) ir_sony_decoder(O) ir_jvc_decoder(O) ir_rc6_decoder(O) ir_rc5_decoder(O) af9033(O) ir_nec_decoder(O) dvb_usb_af9035(O) dvb_usb(O) dvb_core(O) rc_core(O) snd_hda_codec_hdmi snd_hda_codec_realtek snd_hda_intel snd_hda_codec snd_hwdep snd_seq snd_seq_device snd_pcm snd_timer snd btusb soundcore bluetooth microcode rfkill snd_page_alloc pcspkr serio_raw i2c_i801 iTCO_wdt iTCO_vendor_support xhci_hcd r8169 mii asus_atk0110 uinput ipv6 nouveau ttm drm_kms_helper drm i2c_algo_bit i2c_core mxm_wmi wmi video [last unloaded: r8712u] [83245.571508] Pid: 5740, comm: pm-suspend Tainted: PWC O 3.2.1 #1 [83245.571512] Call Trace: [83245.571522] [] warn_slowpath_common+0x83/0x9b [83245.571531] [] warn_slowpath_null+0x1a/0x1c [83245.571538] [] _request_firmware+0xea/0x3e5 [83245.571545] [] request_firmware+0x16/0x18 [83245.571559] [] dvb_usb_download_firmware+0x34/0xbe [dvb_usb] [83245.571570] [] dvb_usb_device_init+0x1d5/0x602 [dvb_usb] [83245.571581] [] az6007_usb_probe+0x25/0x27 [dvb_usb_az6007] [83245.571589] [] usb_probe_interface+0x14a/0x1b7 [83245.571598] [] driver_probe_device+0x136/0x25a [83245.571605] [] __device_attach+0x3a/0x3f [83245.571612] [] ? __driver_attach+0x7e/0x7e [83245.571619] [] bus_for_each_drv+0x56/0x8c [83245.571627] [] device_attach+0x7b/0x9f [83245.571633] [] usb_rebind_intf+0x65/0x81 [83245.571640] [] do_unbind_rebind+0x63/0x79 [83245.571647] [] usb_resume+0x65/0x7c [83245.571654] [] usb_dev_complete+0x10/0x12 [83245.571661] [] dpm_complete+0x137/0x1ad [83245.571669] [] dpm_resume_end+0x19/0x1d [83245.571677] [] suspend_devices_and_enter+0x1d6/0x21a [83245.571684] [] enter_state+0x129/0x16e [83245.571691] [] state_store+0xbc/0x106 [83245.571699] [] kobj_attr_store+0x17/0x19 [83245.571707] [] sysfs_write_file+0x101/0x13d [83245.571716] [] vfs_write+0xac/0xf3 [83245.571723] [] sys_write+0x4a/0x6e [83245.571732] [] system_call_fastpath+0x16/0x1b [83245.571737] ---[ end trace 46c4416a4ddedede ]--- [83245.571743] usb 1-5: firmware: dvb-usb-terratec-h7-az6007.fw will not be loaded [83245.571750] dvb-usb: did not find the firmware file. (dvb-usb-terratec-h7- az6007.fw) Please see linux/Documentation/dvb/ for more details on firmware- problems. (-16) [83245.571763] dvb_usb_az6007: probe of 1-5:1.0 failed with error -16 ¿Anybody know whats wrong? Jose Alberto -- 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: HVR-1600: Skipped encoder MPEG, MDL 63, 62 times - it must have dropped out of rotation
On Sun, 2012-04-22 at 12:03 -0400, Brian J. Murrell wrote: > I've got an HVR-1600 in a fairly fast machine (P4 3GHz, two cores) on a > 3.2.0 kernel and seem to be getting lots of this sort of thing: > > Apr 19 20:09:10 pvr kernel: [34651.015170] cx18-0: Skipped encoder MPEG, MDL > 63, 62 times - it must have dropped out of rotation > Apr 19 20:10:05 pvr kernel: [34705.375793] cx18-0: Skipped encoder IDX, MDL > 415, 2 times - it must have dropped out of rotation > Apr 19 20:12:45 pvr kernel: [34865.535784] cx18-0: Skipped encoder IDX, MDL > 426, 2 times - it must have dropped out of rotation > Apr 19 20:12:45 pvr kernel: [34865.609900] cx18-0: Skipped encoder IDX, MDL > 430, 1 times - it must have dropped out of rotation > Apr 19 20:12:45 pvr kernel: [34865.684180] cx18-0: Could not find MDL 426 for > stream encoder IDX > Apr 19 20:12:58 pvr kernel: [34878.912976] cx18-0: Could not find MDL 430 for > stream encoder IDX > Apr 19 20:13:00 pvr kernel: [34880.850172] cx18-0: Skipped encoder MPEG, MDL > 53, 62 times - it must have dropped out of rotation > Apr 19 20:15:25 pvr kernel: [35025.696747] cx18-0: Skipped encoder IDX, MDL > 435, 2 times - it must have dropped out of rotation > Apr 19 20:15:25 pvr kernel: [35025.771765] cx18-0: Skipped encoder IDX, MDL > 439, 1 times - it must have dropped out of rotation > Apr 19 20:15:25 pvr kernel: [35025.847732] cx18-0: Could not find MDL 435 for > stream encoder IDX > Apr 19 20:15:25 pvr kernel: [35025.901315] cx18-0: Skipped TS, MDL 82, 16 > times - it must have dropped out of rotation > Apr 19 20:15:32 pvr kernel: [35032.370364] cx18-0: Skipped encoder IDX, MDL > 435, 2 times - it must have dropped out of rotation > Apr 19 20:15:38 pvr kernel: [35039.074592] cx18-0: Could not find MDL 439 for > stream encoder IDX > Apr 19 20:15:40 pvr kernel: [35040.938552] cx18-0: Skipped encoder MPEG, MDL > 29, 62 times - it must have dropped out of rotation > Apr 19 20:18:05 pvr kernel: [35185.859652] cx18-0: Skipped encoder IDX, MDL > 445, 2 times - it must have dropped out of rotation > Apr 19 20:18:05 pvr kernel: [35185.933816] cx18-0: Skipped encoder IDX, MDL > 449, 1 times - it must have dropped out of rotation > Apr 19 20:18:05 pvr kernel: [35186.008176] cx18-0: Could not find MDL 445 for > stream encoder IDX > Apr 19 20:18:19 pvr kernel: [35199.237035] cx18-0: Could not find MDL 449 for > stream encoder IDX > Apr 19 20:18:19 pvr kernel: [35199.289870] cx18-0: Could not find MDL 49 for > stream encoder MPEG > Apr 19 20:18:25 pvr kernel: [35205.879310] cx18-0: Skipped encoder IDX, MDL > 450, 2 times - it must have dropped out of rotation > Apr 19 20:23:26 pvr kernel: [35506.147134] cx18-0: Skipped encoder IDX, MDL > 402, 2 times - it must have dropped out of rotation > Apr 19 20:24:19 pvr kernel: [35559.705155] cx18-0: Skipped encoder MPEG, MDL > 16, 62 times - it must have dropped out of rotation > > IIRC I was told previously that it was due to interrupts not being > serviced quickly enough. Am I recalling correctly? Yes. > Could that really be a problem even with a dual core 3GHz P4? Yes. You are looking at the evidence in those log messages. If, in your system, IRQ service for device A under some circumstances has precendence over IRQ service for the CX23418 and hence holds off its service; and the irq handler in the driver for device A decides to perform some some long I/O operations with device A; then it doesn't matter how fast your CPU is. You may wish to use perf or ftrace, or some other tool/method of measuring kernel interrupt handling latency to find out what causes any delays from the CX23418 raising its IRQ line to cx18_irq_handler() being called by the kernel. I can tell you that I have optimized cx18_irq_handler(), and the functions it calls, to death. I simply cannot make it perform significantly better. The required PCI MMIO operations to the CX23418 dominate the time consumed in cx18_irq_handler(). [I await "Challenge accepted" from anyone. ;) ] > Also, are those messages related to the clearqam path or the > MPEG2 hardware encoder path? i.e. are those digital recording > messages or analog recording messages? MPEG: analog video encoder DMA buffers IDX: MPEG index data DMA buffers from the analog video encoder TS: DTV (ATSC or QAM) DMA buffers Every message above in your log, indicates your system "lost" a notifcation from the CX23418 as it was too slow to respond to the CX23418's interrupt. Hence your recording/viewing of said stream missed some data. Note, the IDX stream only matters if you have an application that calls the VIDIOC_G_ENC_INDEX ioctl() to collect I-Frame offsets in the MPEG stream. That is very rare, so I would not worry about lost IDX buffers. > Cheers, > b. Regards, Andy -- 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
Using UVC webcam gadget with a real v4l2 device
Hi Laurent, I have been doing some experimentation with the UVC webcam gadget along with the UVC user-space application which you have written. The UVC webcam gadget works fine with the user space application handling the CONTROL events and providing DATA events. Now, I wish to interface a real v4l2 device, for e.g. VIVI or more particularly a soc_camera based host and subdev pair. Now, I see that I can achieve this by opening the UVC and V4L2 devices and doing MMAP -> REQBUF -> QBUF -> DQBUF calls on both the devices per the UVC control event received. But this will involve copying the video buffer in the user-space application from v4l2 (_CAPTURE) to uvc (_OUTPUT) domains, which will significantly reduce the video capture performance. Is there a better solution to this issue? Maybe doing something like a RNDIS gadget does with the help of u_ether.c like helper routines. But if I remember well it also requires the BRCTL (Bridge Control Utility) in userspace to route data arriving on usb0 to eth0 and vice-versa. Not sure though, if it does copying of a skb buffer from ethernet to usb domain and vice-versa. Any idea is much appreciated. Thanks for your help, Bhupesh -- 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:Sun Apr 22 19:00:16 CEST 2012 git hash:aa6d5f29534a6d1459f9768c591a7a72aadc5941 gcc version: i686-linux-gcc (GCC) 4.6.3 host hardware:x86_64 host os: 3.1-2.slh.1-amd64 linux-git-arm-eabi-exynos: WARNINGS linux-git-arm-eabi-omap: WARNINGS linux-git-armv5-ixp: WARNINGS linux-git-i686: OK linux-git-m32r: OK linux-git-mips: WARNINGS linux-git-powerpc64: OK linux-git-x86_64: WARNINGS linux-2.6.31.12-i686: WARNINGS linux-2.6.32.6-i686: WARNINGS linux-2.6.33-i686: WARNINGS linux-2.6.34-i686: WARNINGS linux-2.6.35.3-i686: WARNINGS linux-2.6.36-i686: WARNINGS linux-2.6.37-i686: WARNINGS linux-2.6.38.2-i686: WARNINGS linux-2.6.39.1-i686: WARNINGS linux-3.0-i686: OK linux-3.1-i686: OK linux-3.2.1-i686: OK linux-3.3-i686: WARNINGS linux-2.6.31.12-x86_64: WARNINGS linux-2.6.32.6-x86_64: WARNINGS linux-2.6.33-x86_64: WARNINGS linux-2.6.34-x86_64: WARNINGS linux-2.6.35.3-x86_64: WARNINGS linux-2.6.36-x86_64: WARNINGS linux-2.6.37-x86_64: WARNINGS linux-2.6.38.2-x86_64: WARNINGS linux-2.6.39.1-x86_64: WARNINGS linux-3.0-x86_64: WARNINGS linux-3.1-x86_64: WARNINGS linux-3.2.1-x86_64: WARNINGS linux-3.3-x86_64: WARNINGS apps: WARNINGS spec-git: WARNINGS sparse: ERRORS Detailed results are available here: http://www.xs4all.nl/~hverkuil/logs/Sunday.log Full logs are available here: http://www.xs4all.nl/~hverkuil/logs/Sunday.tar.bz2 The V4L-DVB specification from this daily build is here: http://www.xs4all.nl/~hverkuil/spec/media.html -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
HVR-1600: Skipped encoder MPEG, MDL 63, 62 times - it must have dropped out of rotation
I've got an HVR-1600 in a fairly fast machine (P4 3GHz, two cores) on a 3.2.0 kernel and seem to be getting lots of this sort of thing: Apr 19 20:09:10 pvr kernel: [34651.015170] cx18-0: Skipped encoder MPEG, MDL 63, 62 times - it must have dropped out of rotation Apr 19 20:10:05 pvr kernel: [34705.375793] cx18-0: Skipped encoder IDX, MDL 415, 2 times - it must have dropped out of rotation Apr 19 20:12:45 pvr kernel: [34865.535784] cx18-0: Skipped encoder IDX, MDL 426, 2 times - it must have dropped out of rotation Apr 19 20:12:45 pvr kernel: [34865.609900] cx18-0: Skipped encoder IDX, MDL 430, 1 times - it must have dropped out of rotation Apr 19 20:12:45 pvr kernel: [34865.684180] cx18-0: Could not find MDL 426 for stream encoder IDX Apr 19 20:12:58 pvr kernel: [34878.912976] cx18-0: Could not find MDL 430 for stream encoder IDX Apr 19 20:13:00 pvr kernel: [34880.850172] cx18-0: Skipped encoder MPEG, MDL 53, 62 times - it must have dropped out of rotation Apr 19 20:15:25 pvr kernel: [35025.696747] cx18-0: Skipped encoder IDX, MDL 435, 2 times - it must have dropped out of rotation Apr 19 20:15:25 pvr kernel: [35025.771765] cx18-0: Skipped encoder IDX, MDL 439, 1 times - it must have dropped out of rotation Apr 19 20:15:25 pvr kernel: [35025.847732] cx18-0: Could not find MDL 435 for stream encoder IDX Apr 19 20:15:25 pvr kernel: [35025.901315] cx18-0: Skipped TS, MDL 82, 16 times - it must have dropped out of rotation Apr 19 20:15:32 pvr kernel: [35032.370364] cx18-0: Skipped encoder IDX, MDL 435, 2 times - it must have dropped out of rotation Apr 19 20:15:38 pvr kernel: [35039.074592] cx18-0: Could not find MDL 439 for stream encoder IDX Apr 19 20:15:40 pvr kernel: [35040.938552] cx18-0: Skipped encoder MPEG, MDL 29, 62 times - it must have dropped out of rotation Apr 19 20:18:05 pvr kernel: [35185.859652] cx18-0: Skipped encoder IDX, MDL 445, 2 times - it must have dropped out of rotation Apr 19 20:18:05 pvr kernel: [35185.933816] cx18-0: Skipped encoder IDX, MDL 449, 1 times - it must have dropped out of rotation Apr 19 20:18:05 pvr kernel: [35186.008176] cx18-0: Could not find MDL 445 for stream encoder IDX Apr 19 20:18:19 pvr kernel: [35199.237035] cx18-0: Could not find MDL 449 for stream encoder IDX Apr 19 20:18:19 pvr kernel: [35199.289870] cx18-0: Could not find MDL 49 for stream encoder MPEG Apr 19 20:18:25 pvr kernel: [35205.879310] cx18-0: Skipped encoder IDX, MDL 450, 2 times - it must have dropped out of rotation Apr 19 20:23:26 pvr kernel: [35506.147134] cx18-0: Skipped encoder IDX, MDL 402, 2 times - it must have dropped out of rotation Apr 19 20:24:19 pvr kernel: [35559.705155] cx18-0: Skipped encoder MPEG, MDL 16, 62 times - it must have dropped out of rotation IIRC I was told previously that it was due to interrupts not being serviced quickly enough. Am I recalling correctly? Could that really be a problem even with a dual core 3GHz P4? Also, are those messages related to the clearqam path or the MPEG2 hardware encoder path? i.e. are those digital recording messages or analog recording messages? Cheers, b. signature.asc Description: OpenPGP digital signature
Re: [PATCH 01/15] V4L: Extend V4L2_CID_COLORFX with more image effects
On 04/17/2012 01:28 PM, Sylwester Nawrocki wrote: > On 04/17/2012 12:51 PM, Rémi Denis-Courmont wrote: >> On Tue, 17 Apr 2012 12:09:42 +0200, Sylwester Nawrocki >> wrote: >>> This patch adds definition of additional color effects: >>> - V4L2_COLORFX_AQUA, >>> - V4L2_COLORFX_ART_FREEZE, >>> - V4L2_COLORFX_SILHOUETTE, >>> - V4L2_COLORFX_SOLARIZATION, >>> - V4L2_COLORFX_ANTIQUE, >> >> There starts to be a lot of different color effects with no obvious way to >> determine which ones the current device actually suppots. Should this not >> be a menu control instead? > > Fortunately this has been a menu control, since it was introduced. Only > the DocBook erroneously defined it as an enum. This patch also fixes that, > please see the DocBook part. > >>> - V4L2_COLORFX_ARBITRARY. >>> >>> The control's type in the documentation is changed from 'enum' to 'menu' >>> - V4L2_CID_COLORFX has always been a menu, not an integer type control. >>> >>> The V4L2_COLORFX_ARBITRARY option enables custom color effects, which >> are >>> impossible or impractical to define as the menu items. For example, the >>> devices may provide coefficients for Cb and Cr manipulation, which yield >>> many permutations, e.g. many slightly different color tints. Such >> devices >>> are better exporting their own API for precise control of non-standard >>> color effects. >> >> I don't understand why you need a number for this, if it's going to use >> another control anyway... ? > > In my use case, the hardware has 3 registers: one of them selects the colour > effect and two others determine Cr, Cb coefficients (probably I could use > V4L2_CID_RED_BALANCE, V4L2_CID_BLUE_BALANCE for that, but so far these are > just private controls). > > If I would have removed the V4L2_COLORFX_ARBITRARY item, another control > would have to be added (let's say boolean V4L2_PRIV_IMG_EFFECT). Just to > enable the "arbitrary" effect. > > Then, to enable the arbitrary effect V4L2_CID_COLORFX would have to be set > to V4L2_COLORFX_NONE, and V4L2_PRIV_IMG_EFFECT to true. > > The CB, CR coefficients are meaningful only when the arbitrary effect is > selected. So having another option in the menu, which drivers can just mask > if they don't support it, appeared better to me. > > It's a bit similar to gain/autogain scenario, where gain is active only when > autogain is off. > Maybe I should just add another private control (V4L2_PRIV_IMG_EFFECT) and > remove V4L2_COLORFX_ARBITRARY item. Instead of an imprecise V4L2_COLORFX_ARBITRARY, I'm considering adding V4L2_COLORFX_CHROMA_BALANCE item and document that it should be used together with V4L2_CID_RED_BALANCE and V4L2_CID_BLUE_BALANCE controls. Would something like this be acceptable ? I'd like to avoid (many) private controls if possible. --- Regards, Sylwester -- 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: Fwd: Re: [PATCH 04/15] V4L: Add camera white balance preset control
Hi, > Original Message > Subject: Re: [PATCH 04/15] V4L: Add camera white balance preset control > Date: Fri, 20 Apr 2012 17:22:08 +0200 > From: Hans de Goede > To: Sylwester Nawrocki > > Hi, > > On 04/18/2012 10:46 AM, Sylwester Nawrocki wrote: >> On 04/17/2012 03:23 PM, Hans de Goede wrote: >>> On 04/17/2012 12:09 PM, Sylwester Nawrocki wrote: Add V4L2_CID_WHITE_BALANCE_PRESET control for camera white balance presets. The following items are defined: - V4L2_WHITE_BALANCE_NONE, - V4L2_WHITE_BALANCE_INCANDESCENT, - V4L2_WHITE_BALANCE_FLUORESCENT, - V4L2_WHITE_BALANCE_HORIZON, - V4L2_WHITE_BALANCE_DAYLIGHT, - V4L2_WHITE_BALANCE_FLASH, - V4L2_WHITE_BALANCE_CLOUDY, - V4L2_WHITE_BALANCE_SHADE, This is a manual white balance control, in addition to V4L2_CID_RED_BALANCE, V4L2_CID_BLUE_BALANCE and V4L2_CID_WHITE_BALANCE_TEMPERATURE. It's useful for camera devices running more complex firmware and exposing white balance preset selection in their user register interface. >>> >>> Hmm, how is this supposed to work together with the v4l2-ctrls framework? >>> The framework has a concept of a master control, which has a manual value, >>> and the slave controls will only get unlocked (V4L2_CTRL_FLAG_INACTIVE >>> will be cleared) when that master control is set at its manual value, now >>> lets >>> say that we've V4L2_CID_AUTO_WHITE_BALANCE as master with >>> V4L2_CID_WHITE_BALANCE_PRESET and V4L2_CID_RED_BALANCE and >>> V4L2_CID_BLUE_BALANCE >>> slaves. Then when the master control changes from auto to manual all 3 will >>> have their inactive flag cleared, but if the preset value != >>> V4L2_WHITE_BALANCE_NONE >>> then the red- and blue-balance should have kept their inactive flag. And >>> since >>> this >>> clearing of the inactive flag is done after v4l2-ctrls.c has called into the >>> driver there is no way for the driver to fix this. >>> >>> One could work-around this by not specifying the whitebalance control >>> cluster as >>> being an auto cluster, and doing all the auto cluster stuff from the >>> driver, but >>> that significantly complicates the driver, and we are trying to get away of >>> every >>> driver doing this kinda stuff for itself... >> >> I assumed in common cases there will be just pairs of auto/manual controls >> (or control groups) used, e.g. V4L2_CID_AUTO_WHITE_BALANCE and >> V4L2_CID_RED_BALANCE/V4L2_CID_BLUE_BALANCE, or V4L2_CID_AUTO_WHITE_BALANCE >> and >> V4L2_CID_WHITE_BALANCE_TEMPERATURE or V4L2_CID_AUTO_WHITE_BALANCE and >> V4L2_CID_WHITE_BALANCE_PRESET, etc. >> >> This is really what the control framework support now, i.e. one master >> cluster >> control with single value that swithes whole cluster into manual mode, >> AFAICS. > > Right, so my problem is that at least the pwc driver does not work that way. OK, let's discuss how we can proceed with the menu approach then. >> I assumed more complicated cases will have to be coded in drivers for now. Or >> can be handled my the control framework, if those patterns appear to be often >> used and the control framework is enhanced to better support them. >> >> I tried to come up with a solution that could be also used by the pwc driver >> and to expose all functionality available there. >> >>> I still believe that the solution I came up with for pwc is better, the auto >>> whitebalance control really is a tri state when you add presets whitebalance >>> is controlled through one of this 3 options: >>> 1) auto >>> 2) preset >>> 3) manual >> >> 2) and 3) will often be exclusive, so we cannot just unlock (clear the >> V4L2_CTRL_FLAG_INACTIVE flag) on them, when the WB menu is switched to value >> other than "auto". This would happen when the WB menu and 2), 3) would form >> an auto cluster. >> >> Moreover, we also have V4L2_CID_WHITE_BALANCE_TEMPERATURE as a manual WB >> control. >> I assumed the WB presets are just form of it, with names (labels). > > Another way of looking at the preset is as a special form of auto WB, it > really > is auto WB with a hint from the user about the lighting conditions, and the > auto > wb algorithm just happens to choose fixed values for temperature or red/green > balance > when it gets that user input, this is how the pwc driver currently handles it > and > this works well, currently the pwc driver has a menu with: > > manual > incandescent > fluorescent > daylight > auto > > This matches well with the control framework, because the red/blue balance > (or for other cameras the temperature) get unlocked when manual, and locked > in all other cases, which is exactly what we want. Also it avoids the user > confusion where the user chooses manual for awb, and then still cannot control > wb, because he must also move the preset to none, that is just bad UI design > IMHO. > > To be clear where I set tri state before, I really meant more then 2 states, > so: > > m
[PATCH v2] ARM: i.mx: mx3fb: add overlay support
This work is based on some earlier patch series
"i.MX31: dmaengine and framebuffer drivers" from 2008
by Guennadi Liakhovetski, the patch initializes overlay channel,
adds ioctl for configuring transparency of the overlay and graphics
planes, CONFIG_FB_MX3_OVERLAY is also supported.
In case that CONFIG_FB_MX3_OVERLAY is not defined, mx3fb is completely
backward compatible.
Blend mode, only global alpha blending has been tested.
Signed-off-by: Guennadi Liakhovetski
Signed-off-by: Alex Gershgorin
---
Applies to v3.4-rc4
Changes since v1:
*Some fixes after review
*Added ioctl for setting overlay windows position
---
drivers/video/Kconfig |7 +
drivers/video/mx3fb.c | 346
include/linux/mxcfb.h | 40 ++
3 files changed, 364 insertions(+), 29 deletions(-)
create mode 100644 include/linux/mxcfb.h
diff --git a/drivers/video/Kconfig b/drivers/video/Kconfig
index a290be5..acbfccc 100644
--- a/drivers/video/Kconfig
+++ b/drivers/video/Kconfig
@@ -2368,6 +2368,13 @@ config FB_MX3
far only synchronous displays are supported. If you plan to use
an LCD display with your i.MX31 system, say Y here.
+config FB_MX3_OVERLAY
+ bool "MX3 Overlay support"
+ default n
+ depends on FB_MX3
+ ---help---
+ Say Y here to enable overlay support
+
config FB_BROADSHEET
tristate "E-Ink Broadsheet/Epson S1D13521 controller support"
depends on FB
diff --git a/drivers/video/mx3fb.c b/drivers/video/mx3fb.c
index eec0d7b..09d7885 100644
--- a/drivers/video/mx3fb.c
+++ b/drivers/video/mx3fb.c
@@ -26,6 +26,7 @@
#include
#include
#include
+#include
#include
#include
@@ -238,6 +239,7 @@ static const struct fb_videomode mx3fb_modedb[] = {
struct mx3fb_data {
struct fb_info *fbi;
+ struct fb_info *fbi_ovl;
int backlight_level;
void __iomem*reg_base;
spinlock_t lock;
@@ -246,6 +248,9 @@ struct mx3fb_data {
uint32_th_start_width;
uint32_tv_start_width;
enum disp_data_mapping disp_data_fmt;
+
+ /* IDMAC / dmaengine interface */
+ struct idmac_channel*idmac_channel[2]; /* We need 2 channels */
};
struct dma_chan_request {
@@ -268,10 +273,19 @@ struct mx3fb_info {
struct dma_async_tx_descriptor *txd;
dma_cookie_tcookie;
struct scatterlist sg[2];
+ struct list_headovl_list; /* overlay buffer list */
u32 sync; /* preserve var->sync flags */
};
+/* Allocated overlay buffer */
+struct mx3fb_alloc_list {
+ struct list_headlist;
+ dma_addr_t phy_addr;
+ void*cpu_addr;
+ size_t size;
+};
+
static void mx3fb_dma_done(void *);
/* Used fb-mode and bpp. Can be set on kernel command line, therefore
file-static. */
@@ -303,7 +317,13 @@ static void sdc_fb_init(struct mx3fb_info *fbi)
struct mx3fb_data *mx3fb = fbi->mx3fb;
uint32_t reg;
- reg = mx3fb_read_reg(mx3fb, SDC_COM_CONF);
+ reg = mx3fb_read_reg(mx3fb, SDC_COM_CONF) & ~SDC_COM_GWSEL;
+
+ /* Also enable foreground for overlay graphic window is foreground */
+ if (mx3fb->fbi_ovl && fbi == mx3fb->fbi_ovl->par) {
+ reg |= SDC_COM_FG_EN | SDC_COM_GWSEL;
+ INIT_LIST_HEAD(&fbi->ovl_list);
+ }
mx3fb_write_reg(mx3fb, reg | SDC_COM_BG_EN, SDC_COM_CONF);
}
@@ -312,13 +332,24 @@ static void sdc_fb_init(struct mx3fb_info *fbi)
static uint32_t sdc_fb_uninit(struct mx3fb_info *fbi)
{
struct mx3fb_data *mx3fb = fbi->mx3fb;
- uint32_t reg;
+ uint32_t reg, chan_mask;
reg = mx3fb_read_reg(mx3fb, SDC_COM_CONF);
- mx3fb_write_reg(mx3fb, reg & ~SDC_COM_BG_EN, SDC_COM_CONF);
+ /*
+* Don't we have to automatically disable overlay when disabling
+* background? Attention: cannot test mx3fb->fbi_ovl->par, must
+* test mx3fb->fbi->par, because at the time this function is
+* called for the first time fbi_ovl is not assigned yet.
+*/
+ if (fbi == mx3fb->fbi->par)
+ chan_mask = SDC_COM_BG_EN;
+ else
+ chan_mask = SDC_COM_FG_EN | SDC_COM_GWSEL;
+
+ mx3fb_write_reg(mx3fb, reg & ~chan_mask, SDC_COM_CONF);
- return reg & SDC_COM_BG_EN;
+ return reg & chan_mask;
}
static void sdc_enable_channel(struct mx3fb_info *mx3_fbi)
@@ -412,13 +443,33 @@ static void sdc_disable_channel(struct mx3fb_info
*mx3_fbi)
static int sdc_set_window_pos(struct mx3fb_data *mx3fb, enum ipu_channel
channel,
int16_t x_pos, int16_t y_pos)
{
- if (channel != IDMAC_SDC_0)
- return -EINVAL;
-
x_pos += mx3fb->h_start_width;
y_pos +
[PATCH] drivers/media/video/au0828/au0828-video.c: add missing video_device_release
From: Julia Lawall
At the point of the call to video_register_device, both dev->vbi_dev and
dev->vdev have been allocated, and so should be freed on failure. The
error-handling code is moved to the end of the function, to avoid code
duplication.
Signed-off-by: Julia Lawall
---
drivers/media/video/au0828/au0828-video.c | 21 +
1 file changed, 13 insertions(+), 8 deletions(-)
diff --git a/drivers/media/video/au0828/au0828-video.c
b/drivers/media/video/au0828/au0828-video.c
index 0b3e481..141f9c2 100644
--- a/drivers/media/video/au0828/au0828-video.c
+++ b/drivers/media/video/au0828/au0828-video.c
@@ -1881,7 +1881,7 @@ int au0828_analog_register(struct au0828_dev *dev,
int retval = -ENOMEM;
struct usb_host_interface *iface_desc;
struct usb_endpoint_descriptor *endpoint;
- int i;
+ int i, ret;
dprintk(1, "au0828_analog_register called!\n");
@@ -1951,8 +1951,8 @@ int au0828_analog_register(struct au0828_dev *dev,
dev->vbi_dev = video_device_alloc();
if (NULL == dev->vbi_dev) {
dprintk(1, "Can't allocate vbi_device.\n");
- kfree(dev->vdev);
- return -ENOMEM;
+ ret = -ENOMEM;
+ goto err_vdev;
}
/* Fill the video capture device struct */
@@ -1971,8 +1971,8 @@ int au0828_analog_register(struct au0828_dev *dev,
if (retval != 0) {
dprintk(1, "unable to register video device (error = %d).\n",
retval);
- video_device_release(dev->vdev);
- return -ENODEV;
+ ret = -ENODEV;
+ goto err_vbi_dev;
}
/* Register the vbi device */
@@ -1981,13 +1981,18 @@ int au0828_analog_register(struct au0828_dev *dev,
if (retval != 0) {
dprintk(1, "unable to register vbi device (error = %d).\n",
retval);
- video_device_release(dev->vbi_dev);
- video_device_release(dev->vdev);
- return -ENODEV;
+ ret = -ENODEV;
+ goto err_vbi_dev;
}
dprintk(1, "%s completed!\n", __func__);
return 0;
+
+err_vbi_dev:
+ video_device_release(dev->vbi_dev);
+err_vdev:
+ video_device_release(dev->vdev);
+ return ret;
}
--
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
ics port for camera hal?
Hi, Is there an V4L Port in the camera hal implementations on android ice cream sandwich which makes use of panda v4l camera drivers. Thanks & Regards, Ryan -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/1] s5p-fimc: media_entity_pipeline_start() may fail
Take into account media_entity_pipeline_start() may fail. This patch is
dependent on "media: Add link_validate() op to check links to the sink pad".
Signed-off-by: Sakari Ailus
---
(Just correct Sylwester's e-mail. Sorry for the noise.)
The dependent patch is part of my pull req to Mauro here:
http://www.spinics.net/lists/linux-media/msg46296.html>
drivers/media/video/s5p-fimc/fimc-capture.c |4 +++-
1 files changed, 3 insertions(+), 1 deletions(-)
diff --git a/drivers/media/video/s5p-fimc/fimc-capture.c
b/drivers/media/video/s5p-fimc/fimc-capture.c
index dc18ba5..8fd8095 100644
--- a/drivers/media/video/s5p-fimc/fimc-capture.c
+++ b/drivers/media/video/s5p-fimc/fimc-capture.c
@@ -963,7 +963,9 @@ static int fimc_cap_streamon(struct file *file, void *priv,
if (fimc_capture_active(fimc))
return -EBUSY;
- media_entity_pipeline_start(&p->sensor->entity, p->pipe);
+ ret = media_entity_pipeline_start(&p->sensor->entity, p->pipe);
+ if (ret < 0)
+ return ret;
if (fimc->vid_cap.user_subdev_api) {
ret = fimc_pipeline_validate(fimc);
--
1.7.2.5
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/1] s5p-fimc: media_entity_pipeline_start() may fail
Take into account media_entity_pipeline_start() may fail. This patch is
dependent on "media: Add link_validate() op to check links to the sink pad".
Signed-off-by: Sakari Ailus
---
The dependent patch is part of my pull req to Mauro here:
http://www.spinics.net/lists/linux-media/msg46296.html>
drivers/media/video/s5p-fimc/fimc-capture.c |4 +++-
1 files changed, 3 insertions(+), 1 deletions(-)
diff --git a/drivers/media/video/s5p-fimc/fimc-capture.c
b/drivers/media/video/s5p-fimc/fimc-capture.c
index dc18ba5..8fd8095 100644
--- a/drivers/media/video/s5p-fimc/fimc-capture.c
+++ b/drivers/media/video/s5p-fimc/fimc-capture.c
@@ -963,7 +963,9 @@ static int fimc_cap_streamon(struct file *file, void *priv,
if (fimc_capture_active(fimc))
return -EBUSY;
- media_entity_pipeline_start(&p->sensor->entity, p->pipe);
+ ret = media_entity_pipeline_start(&p->sensor->entity, p->pipe);
+ if (ret < 0)
+ return ret;
if (fimc->vid_cap.user_subdev_api) {
ret = fimc_pipeline_validate(fimc);
--
1.7.2.5
--
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
linux-media@vger.kernel.org
The current condition is always true, so everything uses LOGICAL_DEV_CIR_REV2 (8). It should be that Fintek products 0x0408(F71809) and 0x0804(F71855) use logical device LOGICAL_DEV_CIR_REV1 (5) and other chip ids use logical device 8. In other words, this fixes hardware detection for 0x0408 and 0x0804. Signed-off-by: Dan Carpenter diff --git a/drivers/media/rc/fintek-cir.c b/drivers/media/rc/fintek-cir.c index 392d4be..fba611e 100644 --- a/drivers/media/rc/fintek-cir.c +++ b/drivers/media/rc/fintek-cir.c @@ -197,7 +197,7 @@ static int fintek_hw_detect(struct fintek_dev *fintek) /* * Newer reviews of this chipset uses port 8 instead of 5 */ - if ((chip != 0x0408) || (chip != 0x0804)) + if ((chip != 0x0408) && (chip != 0x0804)) fintek->logical_dev_cir = LOGICAL_DEV_CIR_REV2; else fintek->logical_dev_cir = LOGICAL_DEV_CIR_REV1; -- 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
