- 23 Dec, 2012 6 commits
-
-
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:
Mauro Carvalho Chehab <mchehab@redhat.com>
-
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 34 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:
-
Frank Schaefer authored
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:
-
Frank Schaefer authored
Extend function em28xx_set_alternate: - use alternate setting 0 for bulk transfers as default - respect module parameter 'alt'=0 for bulk transfers - set max_packet_size to 512 bytes for bulk transfers [mchehab@redhat.com: Fix a CodingStyle issue: don't break strings into separate lines] Signed-off-by:
-
Frank Schaefer authored
Signed-off-by:
-
Frank Schaefer authored
Also improve the comments. Signed-off-by:
-
Frank Schaefer authored
The URB data processing for DVB 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. Tested with device Hauppauge HVR-930c. Signed-off-by:
-
Frank Schaefer authored
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:
-
Frank Schaefer authored
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:
-
Frank Schaefer authored
This check is already done in the URB handler em28xx_irq_callback before calling these functions. Signed-off-by:
-
Frank Schaefer authored
[mchehab@redhat.com: Fix a CodingStyle issue: don't break strings into separate lines] Signed-off-by:
-
Frank Schaefer authored
- 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:
-
Frank Schaefer authored
Rename the existing function for isoc transfers em28xx_init_isoc to em28xx_init_usb_xfer and extend it. URB allocation and setup is now done depending on the USB transfer type, which is selected with a new function parameter. Signed-off-by:
-
Frank Schaefer authored
This function will be used to uninitialize USB bulk transfers, too. Also rename the local variable isoc_bufs to usb_bufs. Signed-off-by:
-
Frank Schaefer authored
em28xx_irq_callback can be used for isoc and bulk transfers. Signed-off-by:
-
Frank Schaefer authored
It isn't used anymore and uses constants which no longer exist. Signed-off-by:
-
Frank Schaefer authored
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:
-
Frank Schaefer authored
It will be used for USB bulk transfers, too. Signed-off-by:
-
Frank Schaefer authored
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:
-
Frank Schaefer authored
Signed-off-by:
-
