- 16 Jun, 2009 40 commits
-
-
Jean-Francois Moine authored
The YUYV 640x480 format did not work with ov965x. Signed-off-by:
Jean-Francois Moine <moinejf@free.fr> Signed-off-by:
Mauro Carvalho Chehab <mchehab@redhat.com>
-
Jean-Francois Moine authored
Signed-off-by:
-
Jean-Francois Moine authored
Signed-off-by:
-
Andy Walls authored
Fix the burst gate delays to use a crystal value of 28636360 as assumed by the rest of the driver. Also have the initial color sub-carrier freq paramter use the src decimation ratio per the documentation, instead of the actual crystal/pixel clock ratio. The tracking circuit will find the correct color subcarrier in any case, as long as we're close. Also fix up some debug print statements. Signed-off-by:
Andy Walls <awalls@radix.net> Signed-off-by:
-
Andy Walls authored
Finish changes for sliced and raw VBI for 625 line systems. Tested with VPS and WSS being emitted by a PVR-350 in field 1 lines 16 and 23. Signed-off-by:
-
Andy Walls authored
Initial changes to get sliced VBI for 625 line system working. This is patch is untested. Signed-off-by:
-
Michael Krufky authored
Signed-off-by:
Michael Krufky <mkrufky@kernellabs.com> Signed-off-by:
-
Michael Krufky authored
The i2c quirk in the saa7134_i2c_xfer function does a bogus write to i2c address 0xfd, to work around a bug in the silicon that affects read transactions. Unfortunately, this hack is not working properly, since the bogus write is to 0xfd, an invalid i2c address. Fix this quirk by using an actual valid i2c address, 0xfe, which is still unlikely to be used as an i2c address for any actual i2c client. This is required in order to properly communicate with a TDA10048 DVB-T demod located at i2c address 0x10 on the primary i2c bus. Signed-off-by:
-
Michael Krufky authored
Steve missed the HVR1210 config struct for the TDA10048 in his IF freq patch. Signed-off-by:
-
Steven Toth authored
This was causing a lock failure in Australia. Signed-off-by:
Steven Toth <stoth@kernellabs.com> Signed-off-by:
-
Steven Toth authored
pvrusb2: Ensure we specify I/F's for all bandwidths Signed-off-by:
Mike Isely <isely@pobox.com> Signed-off-by:
-
Steven Toth authored
cx23885: Ensure we specify I/F's for all bandwidths Signed-off-by:
-
Steven Toth authored
TDA10048: Ensure the I/F changes during DVB-T 6/7/8 bandwidth changes. Signed-off-by:
-
figo.zhang authored
The variable minor have assigned value twice, the first time is in the initial "video_device" data struct in those drivers, pls see saa7134-video.c,line 2503. --- Signed-off-by:
Figo.zhang <figo.zhang@kolorific.com> Signed-off-by:
-
figo.zhang authored
saa7134-video.c: poll method lose race condition Signed-off-by:
-
Dean Anderson authored
Adding V4L2_MODE_HIGHQUALITY feature. Signed-off-by:
Dean Anderson <dean@sensoray.com> Signed-off-by:
-
Filipe Rosset authored
Update the 17ef:480b device comment to list Lenovo Thinkpad SL400. Signed-off-by:
Filipe Rosset <rosset.filipe@gmail.com> Signed-off-by:
Laurent Pinchart <laurent.pinchart@skynet.be> Signed-off-by:
-
Jean Delvare authored
Now that the ir-kbd-i2c driver has been converted to a new-style i2c driver, we can instantiate the ir_video I2C device by default. The pvr2_disable_ir_video is kept to disable the IR receiver, either because the user doesn't use it, or for debugging purpose. Signed-off-by:
Jean Delvare <khali@linux-fr.org> Acked-by:
-
Jean Delvare authored
Probe I2C addresses 0x71 and 0x6b for IR receiver devices (for the PVR150 and Adaptec cards, respectively.) Signed-off-by:
-
Jean Delvare authored
Now that we instantiate I2C IR devices explicitly, we can skip probing altogether on boards where the I2C IR device address is known. The AVerMedia Cardbus E506R is one of these boards. Tested-by:
Oldrich Jedlicka <oldium.pro@seznam.cz> Signed-off-by:
-
Jean Delvare authored
Now that we instantiate I2C IR devices explicitly, we can skip probing altogether on boards where the I2C IR device address is known. The MSI TV@nywhere Plus is one of these boards. Signed-off-by:
-
Jean Delvare authored
The code in ir_probe makes the dangerous assumption that all IR receivers are supported by the driver. The new i2c model makes it possible for bridge drivers to instantiate IR devices before they are supported, therefore the ir-kbd-i2c drivers must be made more robust to not spam the logs or even crash on unsupported IR devices. Simply, the driver will not bind to the unsupported devices. Signed-off-by:
-
Jean Delvare authored
For specific boards, pass initialization data to ir-kbd-i2c instead of modifying the settings after the device is initialized. This is more efficient and easier to read. Signed-off-by:
-
Jean Delvare authored
Let card drivers probe for IR receiver devices and instantiate them if found. Ultimately it would be better if we could stop probing completely, but I suspect this won't be possible for all card types. There's certainly room for cleanups. For example, some drivers are sharing I2C adapter IDs, so they also had to share the list of I2C addresses being probed for an IR receiver. Now that each driver explicitly says which addresses should be probed, maybe some addresses can be dropped from some drivers. Also, the special cases in saa7134-i2c should probably be handled on a per-board basis. This would be more efficient and less risky than always probing extra addresses on all boards. I'll give it a try later. Signed-off-by:
-
Jean Delvare authored
In the standard device driver binding model, the name field of struct i2c_client is used to match devices to their drivers, so we must stop using it for internal purposes. Define a separate field in struct IR_i2c as a replacement, and use it. Signed-off-by:
-
Alessio Igor Bogani authored
radio-mr800.c uses struct mutex, so while <linux/mutex.h> seems to be pulled in indirectly by one of the headers it already includes, the right thing is to include it directly. Signed-off-by:
Alessio Igor Bogani <abogani@texware.it> Signed-off-by:
Andrew Morton <akpm@linux-foundation.org> Acked-by:
Alexey Klimov <klimov.linux@gmail.com> Signed-off-by:
-
Simon Arlott authored
dvb_dvr_read may unlock the dmxdev mutex and return -ENODEV, except this function is a file op and will never be called with the mutex held. There's existing mutex_lock and mutex_unlock around the actual read but it's commented out. These should probably be uncommented but the read blocks and this could block another non-blocking reader on the mutex instead. This change comments out the extra mutex_unlock. [akpm@linux-foundation.org: cleanups, simplification] Signed-off-by:
Simon Arlott <simon@fire.lp0.eu> Signed-off-by:
-
Cohen David.A authored
Change kmalloc()/kfree() to vmalloc()/vfree() for sglist allocation during videobuf_dma_map() and videobuf_dma_unmap() High resolution sensors might require too many contiguous pages to be allocated for sglist by kmalloc() during videobuf_dma_map() (i.e. 256Kib for 8MP sensor). In such situations, kmalloc() could face some problem to find the required free memory. vmalloc() is a safer solution instead, as the allocated memory does not need to be contiguous. Signed-off-by:
David Cohen <david.cohen@nokia.com> Signed-off-by:
-
Laurent Pinchart authored
Most UVC camera include an interrupt endpoint to report control value changes, video streaming errors and camera button events. The USB controller continuously polls the interrupt endpoint to retrieve such events. This prevents the device from being auto-suspended, and thus consumes power. Reporting video streaming errors don't make sense when the V4L2 device is closed. Control value changes are probably useless as well if nobody listens to the events, although caching will probably have to be completely disabled then. No polling is thus be required when /dev/videoX is not opened. To enable auto-suspend and save power do not poll the interrupt endpoint until the device is open. We lose the ability to detect button events if no application is using the camera. http://bugzilla.kernel.org/show_bug.cgi?id=11948Signed-off-by:
-
Laurent Pinchart authored
Signed-off-by:
-
Laurent Pinchart authored
The UVC specification requires frame descriptors indexes to range from 1 to the number of frame descriptors. At least some Hercules Dualpix Infinite webcams erroneously use non-continuous index ranges. Make the driver support them. Signed-off-by:
-
Alan Nisota authored
I have been informed by the manufacturer that the patch currently in the v4l tree to support the Genpix-CW3K version of the hardware will actually damage the firmware on recent units. As he seems to not want this hardware supported in Linux, and I do not know how to detect the difference between affected and not-affected units, I am requesting the immediate removal of support for this device. This patch removes a portion of the changeset dce7e08ed2b1 applied 2007-08-18 relating to this specific device. Adapted patch to not remove code, but to only to comment it out. Signed-off-by:
Patrick Boettcher <pb@linuxtv.org> Signed-off-by:
-
matthieu castet authored
dibusb_i2c_xfer seems to do things very dangerous : it assumes that it get only write/read request or write request. That means that read can be understood as write. For example a program doing file = open("/dev/i2c-x", O_RDWR); ioctl(file, I2C_SLAVE, 0x50) read(file, data, 10) will corrupt the eeprom as it will be understood as a write. Signed-off-by:Matthieu CASTET <castet.matthieu@free.fr> Signed-off-by:
-
Patrick Boettcher authored
This patch adds the USB IDs for the Terratec devices T3 and T5. Signed-off-by:
-
tomas petr authored
"Leadtek WinFast DTV Dongle H" is a hybrid digital/analog USB-stick TV receiver. The code below allows the digital part to work with dvb_usb in linux. Signed-off-by:
tomas petr <tom-petr@seznam.cz> Signed-off-by:
-
Patrick Boettcher authored
This patch is reorganizing the frontend-attach mechanism in order to gain noise-less (superflous prints) deactivation of submodules. Credits go to Uwe Bugla for helping to clean and test the code. Signed-off-by:
Uwe Bugla <uwe.bugla@gmx.de> Signed-off-by:
-
Matthias Schwarzott authored
Reducing the print-levle of I2C error prints cleans some unwanted but unavoidable errors from default syslog-level. Signed-off-by:
Matthias Schwarzott <zzam@gentoo.org> Signed-off-by:
-
Mauro Carvalho Chehab authored
Signed-off-by: -
Mauro Carvalho Chehab authored
Signed-off-by: -
Devin Heitmueller authored
The em28xx actually has a register that tells the driver what the maximum packet size is (based on a value programmed into the eeprom). Make use of that register instead of assuming a hardcoded value of 564 (since 564 is not correct for devices that do QAM such as the KWorld 340u). Note that for now the em2874 code isn't there, falling back to the 564 value, however this is not a problem since there are not any em2874 based devices in the current v4l-dvb tree). Thanks to Jarod Wilson for detecting the initial problem and figuring out that the isoc configuration was wrong for his device. Cc: Jarod Wilson <jarod@wilsonet.com> Signed-off-by:
Devin Heitmueller <dheitmueller@kernellabs.com> Signed-off-by:
-
