- 27 Dec, 2012 11 commits
-
-
Simon Farnsworth authored
The SAA7134 appears to have trouble buffering more than one line of video when doing DMA. Rather than try to fix the driver to cope (as has been done by Andy Walls for the cx18 driver), put in a pm_qos_request to limit deep sleep exit latencies. The visible effect of not having this is that seemingly random lines are only partly transferred - if you feed in a static image, you see a portion of the image "flicker" into place. [mchehab@redhat.com: Fix ABI breakage due to some renames at pm_qos] Signed-off-by:
Simon Farnsworth <simon.farnsworth@onelan.co.uk> Signed-off-by:
Mauro Carvalho Chehab <mchehab@redhat.com>
-
Oleh Kravchenko authored
This patch provide only analog support. The device is based on AF9013 demodulator, XC3028 tuner and CX23885 chipset; subsystem id: 1461:d939 Signed-off-by:
Oleh Kravchenko <oleg@kaa.org.ua> Signed-off-by:
-
Nikolaus Schulz authored
Since most dvb ioctls wrap their real work with dvb_usercopy, the static mutex used in dvb_usercopy effectively is a global lock for dvb ioctls. Unfortunately, frontend ioctls can be blocked by the frontend thread for several seconds; this leads to unacceptable lock contention. Mitigate that by pushing the mutex from dvb_usercopy down to the individual, device specific ioctls. There are 10 such ioctl functions using dvb_usercopy, either calling it directly, or via the trivial wrapper dvb_generic_ioctl. The following already employ their own locking and look safe: • dvb_demux_ioctl (as per dvb_demux_do_ioctl) • dvb_dvr_ioctl (as per dvb_dvr_do_ioctl) • dvb_osd_ioctl (as per single non-trivial callee) • fdtv_ca_ioctl (as per callees) • dvb_frontend_ioctl The following functions do not, and are thus changed to use a device specific mutex: • dvb_net_ioctl (as per dvb_net_do_ioctl) • dvb_ca_en50221_io_ioctl (as per dvb_ca_en50221_io_do_ioctl) • dvb_video_ioctl • dvb_audio_ioctl • dvb_ca_ioctl Signed-off-by:Nikolaus Schulz <schulz@macnetix.de> Signed-off-by:
Michael Krufky <mkrufky@linuxtv.org> Signed-off-by:
-
Juergen Lock authored
That likely fixes this MythTV ticket: http://code.mythtv.org/trac/ticket/10830 (which btw affects all usb tuners I tested as well, pctv452e, dib0700, af9015) pctv452e is still possibly broken with MythTV even after this fix; it does work with VDR here tho despite I2C errors. Reduced testcase: http://people.freebsd.org/~nox/tmp/ioctltst.c Thanx to devinheitmueller and crope from #linuxtv for helping with this fix! :) Signed-off-by:
Juergen Lock <nox@jelal.kn-bremen.de> Signed-off-by:
-
Luis R. Rodriguez authored
spinlock_t should always be used. Could not get this to build with allmodconfig: mcgrof@frijol ~/linux-next (git::(no branch))$ make C=1 M=drivers/media/platform/s5p-jpeg WARNING: Symbol version dump /home/mcgrof/linux-next/Module.symvers is missing; modules will have no dependencies and modversions. Building modules, stage 2. MODPOST 0 modules Reported-by:Hauke Mehrtens <hauke@hauke-m.de> Signed-off-by:
Luis R. Rodriguez <mcgrof@do-not-panic.com> Cc: Kyungmin Park <kyungmin.park@samsung.com> Cc: Sylwester Nawrocki <s.nawrocki@samsung.com> Signed-off-by:
-
Luis R. Rodriguez authored
spinlock_t should always be used. Could not get this to build with allmodconfig: mcgrof@frijol ~/linux-next (git::(no branch))$ make C=1 M=drivers/media/platform/s5p-fimc/ WARNING: Symbol version dump /home/mcgrof/linux-next/Module.symvers is missing; modules will have no dependencies and modversions. LD drivers/media/platform/s5p-fimc/built-in.o Building modules, stage 2. MODPOST 0 modules Reported-by: -
Mauro Carvalho Chehab authored
Resolves the following warning that appears with allmodconfig on -arm: warning: (VIDEO_OMAP2_VOUT && DRM_OMAP) selects OMAP2_DSS which has unmet direct dependencies (HAS_IOMEM && ARCH_OMAP2PLUS) Signed-off-by: -
Mauro Carvalho Chehab authored
Fix a Kconfig warning that appears with allmodconfig on arm: warning: (DVB_USB_PCTV452E) selects TTPCI_EEPROM which has unmet direct dependencies (MEDIA_SUPPORT && MEDIA_PCI_SUPPORT && MEDIA_DIGITAL_TV_SUPPORT && I2C) Signed-off-by: -
Alf Høgemark authored
This patch adds support for the Elgato Video Capture, version 2, device. The device is added based on the code for CX231XX_BOARD_HAUPPAUGE_USBLIVE2, it is simply a copy of the code for that board, with the proper USB device info for the Elgato Video Capture V2 device. Signed-off-by:
Alf Høgemark <alf@i100.no> Signed-off-by:
-
Dan Carpenter authored
This error path is missing the unlock. [mchehab@redhat.com: Merged two equal patches into one] Signed-off-by:
Sasha Levin <sasha.levin@oracle.com> Acked-by:
David Härdeman <david@hardeman.nu> Signed-off-by:
Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by:
-
Mauro Carvalho Chehab authored
Linux 3.8-rc1 * tag 'v3.8-rc1': (10696 commits) Linux 3.8-rc1 Revert "nfsd: warn on odd reply state in nfsd_vfs_read" ARM: dts: fix duplicated build target and alphabetical sort out for exynos dm stripe: add WRITE SAME support dm: remove map_info dm snapshot: do not use map_context dm thin: dont use map_context dm raid1: dont use map_context dm flakey: dont use map_context dm raid1: rename read_record to bio_record dm: move target request nr to dm_target_io dm snapshot: use per_bio_data dm verity: use per_bio_data dm raid1: use per_bio_data dm: introduce per_bio_data dm kcopyd: add WRITE SAME support to dm_kcopyd_zero dm linear: add WRITE SAME support dm: add WRITE SAME support dm: prepare to support WRITE SAME dm ioctl: use kmalloc if possible ... Conflicts: MAINTAINERS
-
- 26 Dec, 2012 6 commits
-
-
Dan Carpenter authored
We recently introduced a new return -ENODEV in this function but we need to unlock before returning. [mchehab@redhat.com: found two patches with the same fix. Merged SOB's/acks into one patch] Acked-by:
Herton R. Krzesinski <herton.krzesinski@canonical.com> Signed-off-by:
Douglas Bagnall <douglas@paradise.net.nz> Signed-off-by:
-
Scott Jiang authored
Bf60x soc has a new PPI called Enhanced PPI version 3. HD video is supported now. To achieve this, we redesign ppi params and add dv timings feature. Signed-off-by:
Scott Jiang <scott.jiang.linux@gmail.com> Signed-off-by:
-
Scott Jiang authored
Other drivers can make use of it. Signed-off-by:
-
Kirill Smelkov authored
I was testing my video-over-ethernet subsystem recently, and vivi seemed to be perfect video source for testing when one don't have lots of capture boards and cameras. Only its framerate was hardcoded to NTSC's 30fps, while in my country we usually use PAL (25 fps) and I needed that to precisely simulate bandwidth. That's why here is this patch with ->enum_frameintervals() and ->{g,s}_parm() implemented as suggested by Hans Verkuil which passes v4l2-compliance and manual testing through v4l2-ctl -P / -p <fps>. Regarding newly introduced __get_format(u32 pixelformat) I decided not to convert original get_format() to operate on fourcc codes, since >= 3 places in driver need to deal with v4l2_format and otherwise it won't be handy. [mchehab@redhat.com: Some CodingStyle fixes] Signed-off-by:Kirill Smelkov <kirr@mns.spb.ru> Acked-by:
Hans Verkuil <hans.verkuil@cisco.com> Signed-off-by:
-
Cyril Roelandt authored
The return values of copy_to_user() and copy_from_user() cannot be negative. Found using the following semantich patch: <spml> @exists@ identifier ret; statement S; expression E; @@ ( * ret = copy_to_user(...); | * ret = copy_from_user(...); ) ... when != ret = E when != if (ret) { <+... ret = E; ...+> } * if (ret < 0) S </spml> Signed-off-by:Cyril Roelandt <tipecaml@gmail.com> Signed-off-by:
-
Sachin Kamat authored
devm_gpio_request is a device managed function and will make error handling and cleanup a bit simpler. Signed-off-by:
Sachin Kamat <sachin.kamat@linaro.org> Acked-by:
Tomasz Stanislawski <t.stanislaws@samsung.com> Signed-off-by:
-
- 23 Dec, 2012 7 commits
-
-
Malcolm Priestley authored
I kept the count as the hardware default with dvb-usb-v2, with 5, users can still run in to trouble with Video PIDs. I have traced it to an incorrect endpoint size when the PID filter is enabled. It also affected USB 2.0 with the filter on. Reported-by:
Antti Palosaari <crope@iki.fi> Tested-by:
Malcolm Priestley <tvboxspy@gmail.com> Signed-off-by:
-
Alfredo Jesús Delaiti authored
This series add remote control support for MyGica X8507. I test for 2 month under OpenSuse(X64) 11.4 and 12.2 with kernel 3.4, 3.5, 3.6 also 3.7-rc2 and rc3. [mchehab@redhat.com: fixed whitespacing - it seems that Alfredo's emailer mangled it] Signed-off-by:
Alfredo J. Delaiti <alfredodelaiti@netscape.net> Signed-off-by:
-
Alfredo Jesús Delaiti authored
Add RC-5 remote keytable definition for MyGica X8507. [mchehab@redhat.com: fixed whitespacing - it seems that Alfredo's emailer mangled it] Signed-off-by:
-
Mauro Carvalho Chehab authored
Using bulk mode allows more than one webcam, as the maximum fps is low at 640x480 resolution. So, prefer it, if the device is a webcam. Tested with Silvercrest 1.3 Mpixel webcam (em2710) on both bulk and isoc modes. Tested analog with HVR-950 model 65201/A1C0 (em2883), where only ISOC endpoints are available for both DVB and Analog. Tested on Hauppauge WinTV USB 2 (em2840) on both bulk and isoc modes. It should be noticed that enabling bulk mode by default with TV boards is a bad idea; what happens is that, while with ISOC the USB logic will prevent the concurrent usage of two devices that spends more than 100% of the USB2 traffic, it doesn't care with bulk transfers. On my tests, I started two streams, one with a WinTV at 640x480x30fps and the other one with a Silvercrest webcam at 640x480, on a lower fps) both on bulk mode. One of the streams always silently failed. Signed-off-by: -
Mauro Carvalho Chehab authored
In order to make easier to analize the logs when multiple devices are plugged, change the device name accordingly with the chip version. Signed-off-by: -
Mauro Carvalho Chehab authored
As both bulk and isoc modes can be available, display what it was found for both DVB and analog. While here, also displays if audio is provided via USB Audio Class or via vendor's extension. Signed-off-by: -
Mauro Carvalho Chehab authored
As the bulk mode is set at device's probe, it is not possible to change it later. So, change the parameter to be read only after modprobing. Signed-off-by:
-
- 22 Dec, 2012 16 commits
-
-
Frank Schaefer authored
Signed-off-by:
Frank Schäfer <fschaefer.oss@googlemail.com> Signed-off-by:
-
Frank Schaefer authored
The code in em28xx_vbi_copy can be simplified a lot. Also rename some variables to something more meaningful and fix+add the function descriptions. Signed-off-by:
-
Frank Schaefer authored
[media] em28xx: move the em2710/em2750/em28xx specific frame data processing code to a separate function em28xx_urb_data_copy() actually consists of two parts: USB urb processing (checks, data extraction) and frame data packet processing. Move the latter to a separate function and call it from em28xx_urb_data_copy() for each data packet. The em25xx, em2760, em2765 (and likely em277x) chip variants are using a different frame data format, for which support will be added later with another function. This reduces the size of em28xx_urb_data_copy() and makes the code much more readable. While we're at it, clean up the code a bit (rename some variables to something more meaningful, improve some comments etc.) Signed-off-by:
-
Frank Schaefer authored
[media] em28xx: em28xx_urb_data_copy(): move duplicate code for capture_type=0 and capture_type=2 to a function Reduce code duplication by moving the duplicate code for dev->capture_type=0 (vbi start) and dev->capture_type=2 (video start) to a function. The same function will also be called by the (not yet existing) em25xx frame data processing code. Signed-off-by:
-
Frank Schaefer authored
In the current code em28xx_urb_data_copy() caches the pointer to the vmalloc memory in videobuf locally. The alternative would be to call videobuf_to_vmalloc() for each processed USB data packet (isoc USB transfers => 64 times per URB) in the em28xx_copy_*() functions. With the next commits, the data processing code will be split into functions for serveral reasons: - em28xx_urb_data_copy() is generally way to long, making it less readable - there is code duplication between VBI and video data processing - support for em25xx data processing (uses a different header and frame end signaling mechanism) will be added This would require extensive usage of pointer-pointers, which usually makes the code less readable and prone to bugs. The better solution is to cache the pointer in struct em28xx_buffer. This also improves consistency, because we already track the buffer fill count there. Signed-off-by:
-
Frank Schaefer authored
When a new frame header is detected in em28xx_urb_data_copy() and the data packet contains both, VBI data and video data, the prevoius VBI buffer doesn't get finished and is overwritten with the new VBI data. This bug is not triggered with isochronous USB transfers, because the data packetes are much smaller than the VBI data size. But when using USB bulk transfers, the whole data of an URB is treated as single packet, which is usually much larger then the VBI data size. Refactor the VBI data processing code to fix this bug, but also to simplify the code and make it similar to the video data processing code part (which allows further code abstraction/unification in the future). The changes have been tested with device "Hauppauge HVR-900". Signed-off-by:
-
Frank Schaefer authored
This field is used to keep track of the current memory position in the buffer, not in the dma queue, so move it to right place. This also allows us to get rid of the struct em28xx_dmaqueue pointer parameter in functions em28xx_copy_video() and em28xx_copy_vbi(). Signed-off-by:
-
Frank Schaefer authored
Signed-off-by:
-
Frank Schaefer authored
Signed-off-by:
-
Frank Schaefer authored
get_next_buf() and vbi_get_next_buf() do exactly the same just with a different dma queue and buffer. Saving the new buffer pointer back to the device struct in em28xx_urb_data_copy() instead of doing this from inside these functions makes it possible to get rid of one of them. Also refactor the function parameters and return type: - pass a pointer to struct em28xx as parameter (instead of obtaining the pointer from the dma queue pointer with the container_of macro) like we do it in all other functions - instead of using a pointer-pointer, return the pointer to the new buffer as return value of the function Signed-off-by:
-
Frank Schaefer authored
em28xx_urb_data_copy_vbi() is actually an extended version of em28xx_urb_data_copy(). With the preceding fixes and improvements, it works fine with both, vbi and non-vbi data streams without performance impacts. So rename em28xx_urb_data_copy_vbi() to em28xx_urb_data_copy(), delete the the old implementation of em28xx_urb_data_copy() and change the code to use this function for both data stream types. Tested with "SilverCrest 1.3 MPix webcam" (progressive, non-vbi) and "Hauppauge HVR-900 (65008/A1C0)" (interlaced, vbi enabled and disabled). Signed-off-by:
-
Frank Schaefer authored
Signed-off-by:
-
Frank Schaefer authored
Set capture type to 1 (video start) when the video frame start header is detected. This bug didn't cause any trouble, because this type of header is never received in vbi mode. Fix it, because we want to use this function with disabled vbi in the future. Also start with capture type -1 to avoid processing of corrupted/incomplete frame data which is usually received at streaming start (especially when USB bulk transfers are used). Signed-off-by:
-
Frank Schaefer authored
[media] em28xx: make sure the packet size is >= 4 before checking for headers in em28xx_urb_data_copy_vbi() Signed-off-by:
-
Frank Schaefer authored
The header check/removal code at the end of function em28xx_urb_data_copy_vbi() is obsolete, because this is already done earlier in this function. In fact it is incomplete (doesn't check for vbi header) and causes trouble when the first data bytes are the same as header bytes (which is fortunately very unlikely). Signed-off-by:
-
Frank Schaefer authored
By default, isoc transfers are used if possible. With the new module parameter, bulk can be selected as the preferred USB transfer type. Signed-off-by:
-
