- 05 1月, 2013 1 次提交
-
-
由 Hans Verkuil 提交于
Signed-off-by: NHans Verkuil <hans.verkuil@cisco.com> Signed-off-by: NDevin Heitmueller <dheitmueller@kernellabs.com> Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>
-
- 23 12月, 2012 23 次提交
-
-
由 Frank Schaefer 提交于
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: NFrank Schäfer <fschaefer.oss@googlemail.com> Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>
-
由 Frank Schaefer 提交于
[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: NFrank Schäfer <fschaefer.oss@googlemail.com> Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>
-
由 Frank Schaefer 提交于
[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: NFrank Schäfer <fschaefer.oss@googlemail.com> Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>
-
由 Frank Schaefer 提交于
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: NFrank Schäfer <fschaefer.oss@googlemail.com> Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>
-
由 Frank Schaefer 提交于
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: NFrank Schäfer <fschaefer.oss@googlemail.com> Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>
-
由 Frank Schaefer 提交于
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: NFrank Schäfer <fschaefer.oss@googlemail.com> Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>
-
由 Frank Schaefer 提交于
Signed-off-by: NFrank Schäfer <fschaefer.oss@googlemail.com> Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>
-
由 Frank Schaefer 提交于
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: NFrank Schäfer <fschaefer.oss@googlemail.com> Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>
-
由 Frank Schaefer 提交于
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: NFrank Schäfer <fschaefer.oss@googlemail.com> Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>
-
由 Frank Schaefer 提交于
Signed-off-by: NFrank Schäfer <fschaefer.oss@googlemail.com> Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>
-
由 Frank Schaefer 提交于
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: NFrank Schäfer <fschaefer.oss@googlemail.com> Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>
-
由 Frank Schaefer 提交于
[media] em28xx: make sure the packet size is >= 4 before checking for headers in em28xx_urb_data_copy_vbi() Signed-off-by: NFrank Schäfer <fschaefer.oss@googlemail.com> Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>
-
由 Frank Schaefer 提交于
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: NFrank Schäfer <fschaefer.oss@googlemail.com> Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>
-
由 Frank Schaefer 提交于
The current enpoint logic ignores all bulk endpoints and uses a fixed mapping between endpint addresses and the supported data stream types (analog/audio/DVB): Ep 0x82, isoc => analog Ep 0x83, isoc => audio Ep 0x84, isoc => DVB Now that the code can also do bulk transfers, the endpoint logic has to be extended to also consider bulk endpoints. The new logic preserves backwards compatibility and reflects the endpoint configurations we have seen so far: Ep 0x82, isoc => analog Ep 0x82, bulk => analog Ep 0x83, isoc* => audio Ep 0x84, isoc => digital Ep 0x84, bulk => analog or digital** (*: audio should always be isoc) (**: analog, if ep 0x82 is isoc, otherwise digital) [mchehab@redhat.com: Fix a CodingStyle issue: don't break strings into separate lines] Signed-off-by: NFrank Schäfer <fschaefer.oss@googlemail.com> Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>
-
由 Frank Schaefer 提交于
Also improve the comments. Signed-off-by: NFrank Schäfer <fschaefer.oss@googlemail.com> Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>
-
由 Frank Schaefer 提交于
The URB data processing for bulk transfers is very similar to what is done with isoc transfers, so create a common function that works with both transfer types based on the existing isoc function. [mchehab@redhat.com: Fix a CodingStyle issue: don't break strings into separate lines] Signed-off-by: NFrank Schäfer <fschaefer.oss@googlemail.com> Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>
-
由 Frank Schaefer 提交于
The URB data processing for bulk transfers is very similar to what is done with isoc transfers, so create a common function that works with both transfer types based on the existing isoc function. [mchehab@redhat.com: Fix a CodingStyle issue: don't break strings into separate lines] Signed-off-by: NFrank Schäfer <fschaefer.oss@googlemail.com> Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>
-
由 Frank Schaefer 提交于
This check is already done in the URB handler em28xx_irq_callback before calling these functions. Signed-off-by: NFrank Schäfer <fschaefer.oss@googlemail.com> Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>
-
由 Frank Schaefer 提交于
- rename em28xx_init_isoc to em28xx_init_usb_xfer - add parameter for isoc/bulk transfer selection which is passed to em28xx_alloc_urbs - rename local variable isoc_buf to usb_bufs Signed-off-by: NFrank Schäfer <fschaefer.oss@googlemail.com> Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>
-
由 Frank Schaefer 提交于
This function will be used to uninitialize USB bulk transfers, too. Also rename the local variable isoc_bufs to usb_bufs. Signed-off-by: NFrank Schäfer <fschaefer.oss@googlemail.com> Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>
-
由 Frank Schaefer 提交于
Also rename the corresponding field isoc_ctl in struct em28xx to usb_ctl. We will use this struct for USB bulk transfers, too. Signed-off-by: NFrank Schäfer <fschaefer.oss@googlemail.com> Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>
-
由 Frank Schaefer 提交于
Rename EM28XX_NUM_PACKETS to EM28XX_NUM_ISOC_PACKETS and EM28XX_DVB_MAX_PACKETS to EM28XX_DVB_NUM_ISOC_PACKETS to clarify that these values are used only for isoc usb transfers. Also use the term num_packets instead of max_packets, as this is how these values are used and called in struct urb. Signed-off-by: NFrank Schäfer <fschaefer.oss@googlemail.com> Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>
-
由 Frank Schaefer 提交于
em28xx_copy_video uses a wrong offset for the target buffer when copying the data from an USB isoc packet. This happens only for the second and all following lines in the packet. The reason why this bug doesn't cause image corruption with my test device (SilverCrest Webcam 1.3 MPix) is, that this device never sends any packets that cross the end of a line. I don't know if all devices behave like this, so this patch should be considered for stable. With the upcoming patches to add support for USB bulk transfers, em28xx_copy_video will be called once per URB, which will always trigger this bug. Signed-off-by: NFrank Schäfer <fschaefer.oss@googlemail.com> Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>
-
- 21 12月, 2012 1 次提交
-
-
由 Sakari Ailus 提交于
Convert drivers using wall clock time (CLOCK_REALTIME) to timestamp from the monotonic timer (CLOCK_MONOTONIC). Signed-off-by: NSakari Ailus <sakari.ailus@iki.fi> Acked-by: NHans Verkuil <hans.verkuil@cisco.com> Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>
-
- 26 9月, 2012 1 次提交
-
-
由 Hans Verkuil 提交于
Write-only ioctls should have a const argument in the ioctl op. Do this conversion for vidioc_s_audio. Adding const for write-only ioctls was decided during the 2012 Media Workshop. Signed-off-by: NHans Verkuil <hans.verkuil@cisco.com> Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>
-
- 16 8月, 2012 2 次提交
-
-
由 Dan Carpenter 提交于
We need to move the unlock before the kfree(dev); Signed-off-by: NDan Carpenter <dan.carpenter@oracle.com> Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>
-
由 Mauro Carvalho Chehab 提交于
Rename all USB drivers with their own directory under drivers/media/video into drivers/media/usb and update the building system. Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>
-
- 10 8月, 2012 1 次提交
-
-
由 Hans Verkuil 提交于
Add proper locking to the file operations, allowing for the removal of the V4L2_FL_LOCK_ALL_FOPS flag. Signed-off-by: NHans Verkuil <hans.verkuil@cisco.com> Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>
-
- 19 5月, 2012 1 次提交
-
-
由 Ezequiel García 提交于
When the device is physically unplugged but there are still open file handles, resource release is defered until last opened handle is closed. This patch fixes a missing em28xx_fh struct release. Tested by compilation only. Signed-off-by: NEzequiel Garcia <elezegarcia@gmail.com> Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>
-
- 15 5月, 2012 1 次提交
-
-
由 Ezequiel García 提交于
Nobody ever waits on any of these wait_queue's, so this patch removes them completely. Tested by compilation only. Signed-off-by: NEzequiel Garcia <elezegarcia@gmail.com> Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>
-
- 14 5月, 2012 1 次提交
-
-
由 Hans Verkuil 提交于
This used to be the default if the lock pointer was set, but now that lock is by default only used for ioctl serialization. Those drivers that already used core locking have this flag set explicitly, except for some drivers where it was obvious that there was no need to serialize any file operations other than ioctl. The drivers that didn't need this flag were: drivers/media/radio/dsbr100.c drivers/media/radio/radio-isa.c drivers/media/radio/radio-keene.c drivers/media/radio/radio-miropcm20.c drivers/media/radio/radio-mr800.c drivers/media/radio/radio-tea5764.c drivers/media/radio/radio-timb.c drivers/media/video/vivi.c sound/i2c/other/tea575x-tuner.c The other drivers that use core locking and where it was not immediately obvious that this flag wasn't needed were changed so that the flag is set together with a comment that that driver needs work to avoid having to set that flag. This will often involve taking the core lock in the fops themselves. Eventually this flag should go and it should not be used in new drivers. There are a few reasons why we want to avoid core locking of non-ioctl fops: in the case of mmap this can lead to a deadlock in rare situations since when mmap is called the mmap_sem is held and it is possible for other parts of the code to take that lock as well (copy_from_user()/copy_to_user() perform a down_read(&mm->mmap_sem) when a page fault occurs). It is very unlikely that that happens since the core lock serializes all fops, but the kernel warns about it if lock validation is turned on. For poll it is also undesirable to take the core lock as that can introduce increased latency. The same is true for read/write. While it was possible to make flags or something to turn on/off taking the core lock for each file operation, in practice it is much simpler to just not take it at all except for ioctl and leave it to the driver to take the lock. There are only a handful fops compared to the zillion ioctls we have. I also wanted to make it obvious which drivers still take the lock for all fops, so that's why I chose to have drivers set it explicitly. Signed-off-by: NHans Verkuil <hans.verkuil@cisco.com> Acked-by: NHans de Goede <hdegoede@redhat.com> Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>
-
- 11 4月, 2012 1 次提交
-
-
由 Ezequiel García 提交于
dev->ctl_input() is always set before a call to video_mux(), but then video_mux() sets it again with the same value. Signed-off-by: NEzequiel Garcia <elezegarcia@gmail.com> Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>
-
- 08 3月, 2012 1 次提交
-
-
由 Gianluca Gennari 提交于
On MIPS/ARM set-top-boxes, as well as old x86 PCs, memory allocation failures in the em28xx driver are common, due to memory fragmentation over time, that makes impossible to allocate large chunks of coherent memory. A typical system with 256/512 MB of RAM fails after just 1 day of uptime (see the old thread for detailed reports and crashlogs). In fact, the em28xx driver allocates memory for USB isoc transfers at runtime, as opposite to the dvb-usb drivers that allocates the USB buffers when the device is initialized, and frees them when the device is disconnected. Moreover, in digital mode the USB isoc transfer buffers are freed, allocated and cleared every time the user selects a new channel, wasting time and resources. This patch solves both problems by allocating DVB isoc transfer buffers in em28xx_usb_probe(), and freeing them in em28xx_usb_disconnect(). In fact, the buffers size and number depend only on the max USB packet size that is parsed from the USB descriptors in em28xx_usb_probe(), so it can never change for a given device. This approach makes no sense in analog mode (as the buffer size depends on the alternate mode selected at runtime), the patch creates two separate sets of buffers for digital and analog modes. For digital-only devices, USB buffers are created when the device is probed and freed when the device is disconnected. For analog-only devices, nothing changes: isoc buffers are created at runtime. For hybrid devices, two sets of buffers are maintained: the digital-mode buffers are created when the device is probed, and freed when the device is disconnected; analog-mode buffers are created/destroyed at runtime as before. So, in analog mode, digital and analog buffers coexists at the same time: this can be justified by the fact that digital mode is by far more commonly used nowadays, so it makes sense to optimize the driver for this use case scenario. The patch has been tested in the last few days on a x86 PC and a MIPS set-top-box, with the PCTV 290e (digital only) and the Terratec Hybrid XS (hybrid device). With the latter, I switched several times between analog and digital mode (Kaffeine/TvTime) with no issue at all. I unplugged/plugged the devices several times with no problem. Also, after over 3 days of normal usage in the MPIS set-top-box, the PCTV 290e was still up and running. Signed-off-by: NGianluca Gennari <gennarone@gmail.com> Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>
-
- 11 1月, 2012 1 次提交
-
-
由 Sascha Sommer 提交于
The MaxPacketSize for em2800 based devices is too small to capture at full resolution. Therefore scale down when the maximum frame size is selected. The previous workaround that simply reduced the X resolution cannot be used because it crops a part of the input as the em2800 can only scale down with a factor of 0.5. reverts commits 1ca31892 and fb3de039. [mchehab@redhat.com: Fix CodingStyle] Signed-off-by: NSascha Sommer <saschasommer@freenet.de> Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>
-
- 19 10月, 2011 1 次提交
-
-
由 Mauro Carvalho Chehab 提交于
Pidgin uses gstreamer (and libv4l) to work. Without implementing this ioctl, it won't detect properly the size range, and driver will fail. So, this patch is required, in order to use an em27xx webcam, like Silvercrest. The pigdin/gstreamer/libv4l needs to be fixed, as it shouldn't assume that all drivers will implement this optional ioctl, but, at least now, devices with em28xx have a better chance of working with pidgin. Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>
-
- 08 10月, 2011 1 次提交
-
-
由 Mauro Carvalho Chehab 提交于
Allow subdevs to return the detected standards Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>
-
- 18 9月, 2011 1 次提交
-
-
由 Chris Rankin 提交于
Release the dev->alt_max_pkt_size buffer in all cases. Signed-off-by: NChris Rankin <rankincj@yahoo.com> Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>
-
- 28 7月, 2011 1 次提交
-
-
由 Mauro Carvalho Chehab 提交于
All the modified drivers didn't have any version increment since Jan, 1 2011. Several of them didn't have any version increment for a long time, even having new features and important bug fixes happening. As we're now filling the QUERYCAP version with the current Kernel Release, we don't need to maintain a per-driver version control anymore. So, let's just use the default. In order to preserve the Kernel module version history, a KERNEL_VERSION() macro were added to all modified drivers, and the extraver number were incremented. I opted to preserve the per-driver version control to a few pwc, pvrusb2, s2255, s5p-fimc and sh_vou. A few drivers are still using the legacy way to handle ioctl's. So, we can't do such change on them, otherwise, they'll break. Those are: uvc, et61x251 and sn9c102. The rationale is that the per-driver version control seems to be actively maintained on those. Yet, I think that the better for them would be to just use the default version numbering, instead of doing that by themselves. While here, removed a few uneeded include linux/version.h Acked-by: NHans Verkuil <hans.verkuil@cisco.com> Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>
-
- 31 3月, 2011 1 次提交
-
-
由 Lucas De Marchi 提交于
Fixes generated by 'codespell' and manually reviewed. Signed-off-by: NLucas De Marchi <lucas.demarchi@profusion.mobi>
-