- 26 Feb, 2010 40 commits
-
-
Devin Heitmueller authored
Fix codingstyle issues, and make the minimum version for cx18-alsa required to be 2.6.17, so that we don't need all the #ifdefs related to the changes to ALSA structures. This work was sponsored by ONELAN Limited. Signed-off-by:
Devin Heitmueller <dheitmueller@kernellabs.com> Signed-off-by:
Mauro Carvalho Chehab <mchehab@redhat.com>
-
Devin Heitmueller authored
Address coding style issue with cx18-alsa-main.c This work was sponsored by ONELAN Limited. Signed-off-by:
-
Devin Heitmueller authored
If the stream is already in use, make sure we free up the memory allocated earlier. Thanks to Andy Wall for reviewing and pointing this out. This work was sponsored by ONELAN Limited. Signed-off-by:
-
Devin Heitmueller authored
Remove a couple of warnings from dead code during driver development. Signed-off-by:
-
Devin Heitmueller authored
Use the cx18 board name in the ALSA description, to make it easier for users who run "arecord -l" to see which device they should be looking for. Also, use strlcpy() instead of strcpy(). Signed-off-by:
-
Devin Heitmueller authored
Fix the debug macro so that it is dependent on the modprobe parameter. This work was sponsored by ONELAN Limited. Signed-off-by:
-
Devin Heitmueller authored
Restructure the way the module gets loaded so that it gets loaded automatically when cx18 is loaded, and make it work properly if there are multiple cards present (since the old code would only take one opportunity to connect to cx18 instances when the module first loaded). This work was sponsored by ONELAN Limited. Signed-off-by:
-
Devin Heitmueller authored
Remove an unneeded debug line, which was preventing the cx18-alsa module from loading. This work was sponsored by ONELAN Limited. Signed-off-by:
-
Devin Heitmueller authored
Export a couple of more symbols required by the cx18-alsa module. This work was sponsored by ONELAN Limited. Signed-off-by:
-
Devin Heitmueller authored
Add cx18-alsa to the Makefile and Kconfig This work was sponsored by ONELAN Limited. Signed-off-by:
-
Devin Heitmueller authored
Add code so that the PCM ALSA device actually works, and update the cx18-streams mechanism so that it passes the data off to the cx18-alsa module. This work was sponsored by ONELAN Limited. Signed-off-by:
-
Devin Heitmueller authored
Expose a couple of symbols in the cx18 module so that locking of the PCM stream can be shared with the cx18-alsa module. This work was sponsored by ONELAN Limited. Signed-off-by:
-
Devin Heitmueller authored
Fix some basic compilation issues with Andy's original code. In particular, temporarily #ifdef out the mixer code, add some additional exception handling, fix a couple of typos, and add a copyright line. This work was sponsored by ONELAN Limited. Signed-off-by:
-
Devin Heitmueller authored
Rename cx18-alsa.c to cx18-alsa-main.c so that we can call the final .ko file cx18-alsa.ko Signed-off-by:
-
Andy Walls authored
Signed-off-by:
Andy Walls <awalls@radix.net> Signed-off-by:
-
Andy Walls authored
Initial cx18-alsa module files check-in to avoid losing work. Signed-off-by:
-
Igor M. Liplianin authored
This is for better readability and smaller size of code lines. Also it is for future improvements like GPIO handling. Signed-off-by:
Igor M. Liplianin <liplianin@me.by> Signed-off-by:
-
Igor M. Liplianin authored
This is for better readability and smaller size of code. Also it is similar to other drivers. Signed-off-by:
-
Igor M. Liplianin authored
Signed-off-by:
-
JD Louw authored
This patch enables LNB power on newer revision d1 Compro S350 and S300 DVB-S cards. Signed-off-by:
JD Louw <jd.louw@mweb.co.za> Signed-off-by:
-
Igor M. Liplianin authored
The PCI card contains dm1105 PCI bridge and ds3000 demod. Signed-off-by:
-
Andy Walls authored
Martin Dauskardt <martin.dauskardt@gmx.de> has done extensive testing on what values can be used and and concluded that only 300 ms total is required to avoid bad video effects such as occasional black screen and short sync disturbances. Furthermore he determined how this 300 ms was split between the two msleep()s did matter very much, so he suggested 150ms/150ms as one acceptable alternative that is implemented here. Many thanks go to Martin. Tested-by:
Martin Dauskardt <martin.dauskardt@gmx.de> Signed-off-by:
-
Andy Walls authored
This change attempts to fix the ivtv tinny audio problem by keeping digitizer to encoder audio clocks running, while disabling the video clocks as needed to avoid unpredictable PCI bus hangs. To accomplish this, for the cx25840 module enabling of audio streaming had to be separated from enabling video streaming, requiring an additional v4l2_subdev_audio_op and calls to this new op in the pvrusb2 and ivtv drivers. The cx231xx and cx23885 driver use the cx25840 module for affecting only video on s_stream calls, so those drivers needed no change. The CX23418 hardware does not exhibit either the tinny audio problem nor the PCI bus hang, so the cx18 driver did not need corresponding changes. CX2341[56] based cards that are not using the CX2584x family of chips do not seem to be affected by the tinny audio problem, and this change should not affect how they are configured. It will delay their first capture by starting by another 300 msec though. Many thanks go to Argus <pthorn-ivtvd@styx2002.no-ip.org> and Martin Dauskardt <martin.dauskardt@gmx.de> whose persistent testing and investigation of this problem will hopefully fix this problem once and for all for many ivtv users. Reported-by:
Argus <pthorn-ivtvd@styx2002.no-ip.org> Signed-off-by:
-
Ian Armstrong authored
There are several DMA related interrupts which wake up the dma_waitq. The udma routines use this queue while they wait for their transfer to complete. When woken, the udma routine will check the IVTV_F_I_UDMA_PENDING & IVTV_F_I_UDMA flags to see if the transfer is still queued or has finished. However, a small window exists between the IVTV_F_I_UDMA_PENDING flag being cleared and the IVTV_F_I_UDMA flag being set. Given that the completion of an unrelated DMA transfer may wake up the udma routine, it's possible for this check to fail and the udma routine will start unmapping pages when the transfer has only just started. The result of this is unpredictable. This fix simply delays the clearing of the IVTV_F_I_UDMA_PENDING flag until after IVTV_F_I_UDMA has been set. Signed-off-by:
Ian Armstrong <ian@iarmst.demon.co.uk> Signed-off-by:
-
Abylay Ospan authored
22-kHz tone can be driven in two ways: 1. LNBH24 can produce 22kHz continuous tone when TEN=1 ( 22 KHz tone output is always activated ). 2. LNBH24 can reproduce 22kHz tone timings from DSQIN or EXTM pin's when TEN=0. From LNBH24 datasheet: "In order to improve design flexibility an external tone input pin is available (EXTM). The EXTM is a Logic input pin which activates the 22 kHz tone output, on the VoTX pin, by using the LNBH24 integrated tone generator (similar to the DSQIN pin function). In fact, the output tone waveform characteristics will always be internally controlled by the LNBH24 tone generator and the EXTM signal will be used as a timing control for DiSEqC tone data encoding on the VoTX output." In NetUP Dual DVB-S2-CI card 22kHz tone timings on EXTM pin produced by STV0900 demod: .set_tone = stv0900_set_tone redefine to "set_tone = lnbp21_set_tone" is not correct for "NetUP Dual DVB-S2-CI card". Signed-off-by:
Abylay Ospan <aospan@netup.ru> Signed-off-by:
Oliver Endriss <o.endriss@gmx.de> Signed-off-by:
-
Hans de Goede authored
We have some duplicate functionality between the zc0301 and gspca-zc3xx, the sn9c102 and gspca-sonixb + gspca-sonix, and et61x251 and gscpa-etoms drivers. The non gspca versions of these drivers not only show a lot of code duplicty (amongsth each other), as they all copy the same generic usb webcam code instead of using some sort of framework. They also have not seen any updates for more then 2 years, where as the gspca drivers are actively maintained. So it is time for the non gspca versions of these drivers to go away, marking them as deprecated is the first step in this. Signed-off-by:
Hans de Goede <hdegoede@redhat.com> Signed-off-by:
-
Hans de Goede authored
drivers/media/video/Kconfig: Turn deprecated drivers off by default Signed-off-by:
-
Hans de Goede authored
This new driver supports USB PIA CPiA version 1 cams, replacing the old v4l1 driver. Signed-off-by:
-
Theodore Kilgore authored
gscpa_sq905c: Better detection of CIF resolution cameras Signed-off-by:
Theodore Kilgore <kilgota@banach.math.auburn.edu> Signed-off-by:
-
Hans de Goede authored
When both the gspca_sonixb and the sn9c102 driver are enabled, make the gspca_sonixb driver handle cams with usb-id of 0c45:6007. The sn9c102 driver is being phased out and gspca driver has been successfully tested with an 0c45:6007 camara. Signed-off-by:
-
Hans de Goede authored
Our hstart value was wrong for tas5110d sensor using sonixb cams, this patch fixes this. Many thanks to Paulus (laudaka) for donating me a camera with such a sensor IC. Signed-off-by:
-
Hans de Goede authored
ov764x remove setting of AEC limits, as the custom values cause AEC oscilation in 320x240. Signed-off-by:
-
Hans de Goede authored
gspca_ov519: remove non functioning contrast control for ov764x sensor Signed-off-by:
-
Hans de Goede authored
Differentiate between ov7640 and ov7648 and handle the ov7648 320x240 on the ov519 bridge specially to fix r and b being swapped. Signed-off-by:
-
Hans de Goede authored
Michael Deegan <michael@ucc.gu.uwa.edu.au>, has reported issues with using 640x480 mode on his ov518+ webcam. The fix for this breaks things on my ov518+ cam (Trust 320 Sp@cecam), this patch thus adds differentiation in the driver between the OV7620 sensor his cam has and the OV7620AE sensor my cam has, and then only changes the init sequence for the ov518+ + OV7620 combo which was not working for Michael. Signed-off-by:
-
Hans de Goede authored
Streaming of VGA stv0680 based cams (instead of CIF ones) failed, because we were using the wrong control pipe for certain commands, this patch fixes this. Signed-off-by:
-
Hans de Goede authored
Mark led on eyetoy II as inverted, I have the feeling the led needs to be inverted for all 519 based cams (iow we got the set led code wrong), but lets just deal with this one cam at a time to avoid breaking currently working cams. Signed-off-by:
-
Hans de Goede authored
stv0680 cameras currently only work when already plugged in when the system boots (or when manually re-loading the driver after boot). This patch fixes this. Signed-off-by:
-
Theodore Kilgore authored
gspca.txt: add cams supported by mr97310a, sq905(c) and sn9c2028 drivers Signed-off-by:
-
Theodore Kilgore authored
New gspca subdriver adding support for SN9C2028 dual-mode cameras. Signed-off-by:
-
