- 01 May, 2015 40 commits
-
-
Hans Verkuil authored
I cannot get this format to work, the colors keep coming out wrong. Since this has never worked I just drop support for this. Signed-off-by:
Hans Verkuil <hans.verkuil@cisco.com> Acked-by:
Jonathan Corbet <corbet@lwn.net> Signed-off-by:
Mauro Carvalho Chehab <mchehab@osg.samsung.com>
-
Hans Verkuil authored
These were calculated incorrectly for the planar formats. Signed-off-by:
-
Hans Verkuil authored
Even though the format is Y'CbCr, the colorspace used by the sensor is almost certainly SRGB. The sensor is also not generating JPEG data, so it makes no sense to use V4L2_COLORSPACE_JPEG here. Signed-off-by:
-
Hans Verkuil authored
This driver appeared to support the JPEG format when in reality that was just dead code. Remove it. Signed-off-by:
-
Hans Verkuil authored
The dma-vmalloc implementation didn't support planar formats, but with a little bit of refactoring that is easy to fix. Signed-off-by:
-
Hans Verkuil authored
If start_streaming fails or stop_streaming is called, then all queued buffers need to be given back to vb2. This prevents vb2 from calling WARN_ON when it detects that this is not done correctly. Signed-off-by:
-
Hans Verkuil authored
- fill in timestamp - fill in field - start the sequence counter at 0, not 1 Signed-off-by:
-
Hans Verkuil authored
Add VB2_DMABUF and VIDIOC_EXPBUF support. Also add VB2_USERPTR support for the vmalloc DMA mode which was missing for no good reason. Signed-off-by:
-
Hans Verkuil authored
This fixes the final v4l2-compliance warning. Signed-off-by:
-
Hans Verkuil authored
Use the V4L2 core locking system instead of rolling your own. Switch to the vb2 fop and ioctl helpers to get rid of a lot of code. This also made it easy to add VB2_READ to the DMA modes, since you get read() for free with vb2 and these helpers. Finally remove the users field: this information is also available from the core framework, no need to keep track of it in the driver. Signed-off-by:
-
Hans Verkuil authored
Now that this driver uses v4l2_fh, it is trivial to add support for control events. Again, this fixes a v4l2-compliance failure. Signed-off-by:
-
Hans Verkuil authored
Use struct v4l2_fh to represent a filehandle. This fixes the missing g/s_priority handling of this driver that v4l2-compliance complained about. Signed-off-by:
-
Hans Verkuil authored
No controls were reported, even though the ov7670 does have controls. Two reasons for this: the v4l2_ctrl_handler_init() call must come before the ov7670 is loaded (otherwise the ov7670 won't know that its controls should be added to the bridge driver), and the v4l2_ctrl_handler_free() call at the end should only be called if the ret value is non-zero (otherwise you would just free all the controls that were just added). Signed-off-by:
-
Hans Verkuil authored
The colorspace field wasn't filled in properly. This fixes a v4l2-compliance failure. Signed-off-by:
-
Hans Verkuil authored
The width and height should be checked in the enum_frame_interval op. This fixes a v4l2-compliance failure. Signed-off-by:
-
Hans Verkuil authored
TV standards make no sense for webcam drivers, so drop these dummy functions. This stops v4l2-compliance from complaining about this. Signed-off-by:
-
Hans Verkuil authored
The bus_info field of struct v4l2_querycap wasn't filled in and v4l2-compliance complained about that. Fix this. Signed-off-by:
-
Hans Verkuil authored
We must set timestamp_flags in vb2_queue otherwise vb2 will complain loudly about it. Signed-off-by:
-
Hans Verkuil authored
Running v4l2-compliance on my usbtv stick revealed two failures: 1) Correct handling of CREATE_BUFS in usbtv_queue_setup was missing. Added this. 2) The sequence counter wasn't reset to 0 when starting streaming. Signed-off-by:
-
Hans Verkuil authored
The cx18 PCM video device didn't have any capabilities set, which caused a warnings in the v4l2 core: [ 6.229393] ------------[ cut here ]------------ [ 6.229414] WARNING: CPU: 1 PID: 593 at drivers/media/v4l2-core/v4l2-ioctl.c:1025 v4l_querycap+0x41/0x70 [videodev]() [ 6.229415] Modules linked in: cx18_alsa mxl5005s s5h1409 tuner_simple tuner_types cs5345 tuner intel_rapl iosf_mbi x86_pkg_temp_thermal coretemp raid1 snd_hda_codec_realtek kvm_intel snd_hda_codec_generic snd_hda_codec_hdmi kvm snd_oxygen(+) snd_hda_intel snd_oxygen_lib snd_hda_controller snd_hda_codec snd_mpu401_uart iTCO_wdt snd_rawmidi iTCO_vendor_support snd_hwdep crct10dif_pclmul crc32_pclmul crc32c_intel snd_seq cx18 snd_seq_device ghash_clmulni_intel videobuf_vmalloc tveeprom cx2341x snd_pcm serio_raw videobuf_core vfat dvb_core fat v4l2_common snd_timer videodev snd lpc_ich i2c_i801 joydev mfd_core mei_me media soundcore tpm_infineon soc_button_array tpm_tis mei shpchp tpm nfsd auth_rpcgss nfs_acl lockd grace sunrpc binfmt_misc i915 nouveau mxm_wmi wmi e1000e ttm i2c_algo_bit drm_kms_helper [ 6.229444] drm ptp pps_core video [ 6.229446] CPU: 1 PID: 593 Comm: v4l_id Not tainted 3.19.3-200.fc21.x86_64 #1 [ 6.229447] Hardware name: Gigabyte Technology Co., Ltd. Z87-D3HP/Z87-D3HP-CF, BIOS F6 01/20/2014 [ 6.229448] 0000000000000000 00000000d12b1131 ffff88042dacfc28 ffffffff8176e215 [ 6.229449] 0000000000000000 0000000000000000 ffff88042dacfc68 ffffffff8109bc1a [ 6.229451] ffffffffa0594000 ffff88042dacfd90 0000000000000000 ffffffffa04e2140 [ 6.229452] Call Trace: [ 6.229466] [<ffffffff8176e215>] dump_stack+0x45/0x57 [ 6.229469] [<ffffffff8109bc1a>] warn_slowpath_common+0x8a/0xc0 [ 6.229472] [<ffffffff8109bd4a>] warn_slowpath_null+0x1a/0x20 [ 6.229474] [<ffffffffa04ca401>] v4l_querycap+0x41/0x70 [videodev] [ 6.229477] [<ffffffffa04ca6cc>] __video_do_ioctl+0x29c/0x320 [videodev] [ 6.229479] [<ffffffff81227131>] ? do_last+0x2f1/0x1210 [ 6.229491] [<ffffffffa04cc776>] video_usercopy+0x366/0x5d0 [videodev] [ 6.229494] [<ffffffffa04ca430>] ? v4l_querycap+0x70/0x70 [videodev] [ 6.229497] [<ffffffffa04cc9f5>] video_ioctl2+0x15/0x20 [videodev] [ 6.229499] [<ffffffffa04c6794>] v4l2_ioctl+0x164/0x180 [videodev] [ 6.229501] [<ffffffff8122e298>] do_vfs_ioctl+0x2f8/0x500 [ 6.229502] [<ffffffff8122e521>] SyS_ioctl+0x81/0xa0 [ 6.229505] [<ffffffff81774a09>] system_call_fastpath+0x12/0x17 [ 6.229506] ---[ end trace dacd80d4b19277ea ]--- Added the necessary capabilities to stop this warning. Signed-off-by:
Laura Abbott <labbott@redhat.com> Cc: <stable@vger.kernel.org> # for v3.19 and up Signed-off-by:
-
Mauro Carvalho Chehab authored
The patches that added support for HVR2255 and HVR2205 added some CodingStyle issues. Better to fix it sooner than latter. Cc: Steven Toth <stoth@kernellabs.com> Signed-off-by: -
Hans Verkuil authored
Fix the VIDIOC_QUERYCAP warning due to the missing device_caps. Don't fill in the version field, the V4L2 core will do that for you. Signed-off-by:
-
Steven Toth authored
QAM mode in the LGDT3306 auto detects inversion. VSB does not. Forgot to include tis fact in the original patch set. Tested with QAM and VSB after this patch, working fine. Signed-off-by:
Steven Toth <stoth@kernellabs.com> Signed-off-by:
-
Steven Toth authored
Updates the copyright notes at the saa7164 driver. Signed-off-by:
-
Steven Toth authored
Adding support for the Hauppauge HVR2255 and Hauppauge HVR2205 PCIe cards. Digital TV for DVB-T and ATSC/US-Cable is known to work. Support for analog RF tuners does not work due to a lack of analog support in the upstream SI2157 driver. Signed-off-by:
-
Steven Toth authored
Workaround oddball I2C issues caused by using newer SILABS devices. Signed-off-by:
-
Steven Toth authored
Assists with debugging difficult I2C devices. Signed-off-by:
-
Steven Toth authored
SI2168/SI2157 issue single byte address reads. Add support for these. Signed-off-by:
-
Dan Carpenter authored
This needs to be signed or there is a risk of hitting a forever loop. Fixes: c4c0283a ('[media] media: i2c: add support for omnivision's ov2659 sensor') Signed-off-by:
Dan Carpenter <dan.carpenter@oracle.com> Acked-by:
Lad, Prabhakar <prabhakar.csengg@gmail.com> Acked-by:
Benoit Parrot <bparrot@ti.com> Signed-off-by:
-
Jan Kara authored
Currently vb2 core acquires mmap_sem just around call to __qbuf_userptr(). However since commit f035eb4e (videobuf2: fix lockdep warning) it isn't necessary to acquire it so early as we no longer have to drop queue mutex before acquiring mmap_sem. So push acquisition of mmap_sem down into .get_userptr and .put_userptr memops so that the semaphore is acquired for a shorter time and it is clearer what it is needed for. Signed-off-by:
Jan Kara <jack@suse.cz> Signed-off-by:
-
Prashant Laddha authored
This change will not change timing calculation. In CVT generator spreadsheet the nominal value of hsync (as a percentage of line) is 8 percent. Cc: Martin Bugge <marbugge@cisco.com> Signed-off-by:
Prashant Laddha <prladdha@cisco.com> Signed-off-by:
-
Prashant Laddha authored
Wrong values of hfreq and image height can lead to strange timings. Avoid timing calculations for such values. Suggested By: Martin Bugge <marbugge@cisco.com> Cc: Martin Bugge <marbugge@cisco.com> Signed-off-by:
-
Prashant Laddha authored
Changed the rounding calculation for hblank and hsync to match it to equations in cvt and gtf standards. In cvt calculation, hsync needs to be rounded down. In gtf calculations, hblank needs to be rounded to nearest multiple of twice the cell granularity and hsync needs to be rounded to the nearest multiple of cell granularity. Cc: Martin Bugge <marbugge@cisco.com> Signed-off-by:
-
Prashant Laddha authored
Changed the rounding offsets used in vsync_bp calculation in cvt and gtf timings. The results for vsync_bp should now match with results from timing generator spreadsheets for cvt and gtf standards. In the vsync_bp calculation for cvt, always round down the value of (CVT_MIN_VSYNC_BP / h_period_est) and then add 1. It thus, reflects the equation used in timing generator spreadsheet. Using 1999999 as rounding offset, could pontentially lead to bumping up the vsync_bp value by extra 1. In the vsync_bp calculations for gtf, instead of round up or round down, round the (CVT_MIN_VSYNC_BP / h_period_est) to the nearest integer. Thanks to Martin Bugge <marbugge@cisco.com> for validating with standards and suggestions on equations. Cc: Martin Bugge <marbugge@cisco.com> Signed-off-by:
-
Geert Uytterhoeven authored
If NO_DMA=y: warning: (TOUCHSCREEN_SUR40 && VIDEO_TW68 && VIDEO_CX23885 && VIDEO_CX25821 && VIDEO_CX88 && VIDEO_SAA7134) selects VIDEOBUF2_DMA_SG which has unmet direct dependencies (MEDIA_SUPPORT && HAS_DMA) ERROR: "dma_unmap_sg" [drivers/media/v4l2-core/videobuf2-dma-sg.ko] undefined! ERROR: "dma_map_sg" [drivers/media/v4l2-core/videobuf2-dma-sg.ko] undefined! ERROR: "dma_sync_sg_for_cpu" [drivers/media/v4l2-core/videobuf2-dma-sg.ko] undefined! TOUCHSCREEN_SUR40 selects VIDEOBUF2_DMA_SG, which bypasses its dependency on HAS_DMA. Make TOUCHSCREEN_SUR40 depend on HAS_DMA to fix this. Signed-off-by:Geert Uytterhoeven <geert@linux-m68k.org> Signed-off-by:
-
Geert Uytterhoeven authored
If NO_DMA=y: ERROR: "dma_unmap_sg" [drivers/media/v4l2-core/videobuf2-dma-sg.ko] undefined! ERROR: "dma_map_sg" [drivers/media/v4l2-core/videobuf2-dma-sg.ko] undefined! ERROR: "dma_sync_sg_for_cpu" [drivers/media/v4l2-core/videobuf2-dma-sg.ko] undefined! VIDEOBUF2_DMA_SG cannot be enabled manually by the user, it's always selected automatically by drivers that need it. Several of those drivers already have an explicit dependency on HAS_DMA. Make VIDEOBUF2_DMA_SG depend on HAS_DMA. This makes it easier to find drivers that select VIDEOBUF2_DMA_SG without depending on HAS_DMA, as Kconfig will give a warning. Signed-off-by: -
Geert Uytterhoeven authored
If NO_DMA=y: warning: (VIDEO_XILINX && VIDEO_DM365_VPFE && VIDEO_DT3155 && VIDEO_OMAP4) selects VIDEOBUF2_DMA_CONTIG which has unmet direct dependencies (MEDIA_SUPPORT && HAS_DMA) media/v4l2-core/videobuf2-dma-contig.c: In function ‘vb2_dc_mmap’: media/v4l2-core/videobuf2-dma-contig.c:207: error: implicit declaration of function ‘dma_mmap_coherent’ media/v4l2-core/videobuf2-dma-contig.c: In function ‘vb2_dc_get_base_sgt’: media/v4l2-core/videobuf2-dma-contig.c:390: error: implicit declaration of function ‘dma_get_sgtable’ VIDEO_XILINX selects VIDEOBUF2_DMA_CONTIG, which bypasses its dependency on HAS_DMA. Make VIDEO_XILINX depend on HAS_DMA to fix this. Signed-off-by: -
Hans Verkuil authored
When using VIDIOC_G_EDID there is a special case where start_blocks and blocks are both set to 0. In that case the driver just has to set blocks to the total number of available blocks and return 0. Even though the drivers do this right and v4l2-compliance tests for it, it turned out not to be documented in the spec. Fix this. Signed-off-by:
Mats Randgaard <matrandg@cisco.com> Signed-off-by:
-
Hans Verkuil authored
Fix copy-and-paste errors: Source -> Process Signed-off-by:
Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by:
-
Cheolhyun Park authored
Fix several typos inside the driver's comments. Signed-off-by:
Cheolhyun Park <pch851130@gmail.com> Signed-off-by:
-
