- 23 Dec, 2012 1 commit
-
-
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:Mauro Carvalho Chehab <mchehab@redhat.com>
-
- 22 Dec, 2012 36 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:
-
Frank Schaefer authored
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:
-
Frank Schaefer authored
When em28xx_ir_init() fails due to an configuration error, it frees the memory of struct em28xx_IR *ir, but doesn't set the corresponding pointer in the device struct to NULL. On device removal, em28xx_ir_fini() gets called, which then calls rc_unregister_device() with a pointer to freed memory. Fixes bug 26572 (http://bugzilla.kernel.org/show_bug.cgi?id=26572) Signed-off-by:
-
- 21 Dec, 2012 3 commits
-
-
Mauro Carvalho Chehab authored
Newer em28xx chipsets (em2874 and upper) are capable of supporting RC6 codes, on both mode 0 (command mode, 16 bits payload size, similar to RC5, also called "Philips mode") and mode 6a (OEM command mode, with offers a few alternatives with regards to the payload size). I don't have any mode 6a control ATM to test it, so, I opted to add support only to mode 0. After this patch, adding support to mode 6a should not be hard. Tested with a Philips television remote controller. Signed-off-by: -
Mauro Carvalho Chehab authored
By disabling the NEC parity check, it is possible to handle all 3 NEC protocol variants (32, 24 or 16 bits). Change the driver in order to handle all of them. Unfortunately, em2860/em2863 provide only 16 bits for the IR scancode, even when NEC parity is disabled. So, this change should affect only em2874 and newer devices, with provides up to 32 bits for the scancode. Tested with one NEC-16, one NEC-24 and one RC5 IR. Signed-off-by: -
Mauro Carvalho Chehab authored
Those two tuners may also be needed. Signed-off-by:
-
