- 04 Mar, 2013 40 commits
-
-
Hans Verkuil authored
Signed-off-by:
Hans Verkuil <hans.verkuil@cisco.com> Acked-by:
Huang Shijie <shijie8@gmail.com> Signed-off-by:
Mauro Carvalho Chehab <mchehab@redhat.com>
-
Hans Verkuil authored
The input and audio ioctls are only valid for video/vbi nodes. Signed-off-by:
-
Hans Verkuil authored
The driver already does locking, so it is safe to switch to unlocked_ioctl. Signed-off-by:
-
Hans Verkuil authored
This driver now passes the tuner and frequency tests of v4l2-compliance. It's the usual bugs: frequency wasn't clamped to the valid frequency range, incorrect tuner capabilities and tuner fields not filled in, missing test for invalid tuner index, no initial frequency and incorrect error handling. Signed-off-by:
-
Hans Verkuil authored
Set the correct parent for v4l2_device_register and don't set the name anymore (that's now deduced from the parent). Also remove an unnecessary forward reference and fix two weird looking log messages. Signed-off-by:
-
Frank Schaefer authored
Signed-off-by:
Frank Schäfer <fschaefer.oss@googlemail.com> Signed-off-by:
-
Mauro Carvalho Chehab authored
Now that some devices initialize register 0x2a with different values, add the calculus formula, instead of hardcoding it. Signed-off-by: -
Mauro Carvalho Chehab authored
Up to now, the driver was simply assuming TV mode, 13 segs. Implement the logic to control the ISDB operational mode. Signed-off-by: -
Mauro Carvalho Chehab authored
Putting em28xx in suspend mode when a feed stops is just plain wrong. Every time a new PES filter is changed, the DVB demux code will stop the current feed, and then start a new one. If are there any code that switches off the frontend, via some GPIO setting, this would make the DVB fail. This condition was actually trigged with one device, during DVB scan, as, during scan, it is common that userspace apps to change the filter several times, in order to get all tables. Also, this is not needed at all, since the em28xx code already hooks into ops.ts_bus_ctrl(). This warrants that em28xx can check there if DVB frontend is in usage or not. The code there already puts the device on suspend mode, if the DVB frontend is not used (closed). Signed-off-by: -
Mauro Carvalho Chehab authored
Instead of using 3.3 MHz IF, use 4MHz. That's the standard value for the demod, and, while it can be adjusted, 3.3 MHz is out of the recommended range. So, let's stick with the default. With regards to the IF voltage level, instead of using 0.5 V(p-p) for IF, use 2V, giving a 12dB gain. The rationale is that, on PixelView SBTVD Hybrid, even 2V(p-p) would be in the nominal range for IF, as the maximum range on this particular device is 3V. A higher gain here should help to improve reception under weak signals. Signed-off-by: -
Mauro Carvalho Chehab authored
As the device got re-initialized, the stats should vanish until the device gets lock again. Signed-off-by: -
Mauro Carvalho Chehab authored
Signal strength is always available. There's no reason to reset it, as it has its own logic to reset it already. Signed-off-by: -
Mauro Carvalho Chehab authored
Always init the frontend when set_frontend is called. The rationale is: it was noticed that, on some devices, it fails to lock with a different channel. It seems that some other registers need to be restored to its initial state, when the channel changes. As it is better to reset everything, even wasting a few more miliseconds than to loose channel lock, let's change the logic to always reset. Signed-off-by: -
Mauro Carvalho Chehab authored
Use the AGC settings present on a newer device. The initial settings were taken from one of the first devices with mb86a20s, and there are several reports that this is not working properly on some places. So, instead of keeping using it, get the parameters taken from a newer device. Tests are welcomed. Tested also with cx231xx PixelView SBTVD Hybrid with no regressions noticed so far. Signed-off-by: -
Mauro Carvalho Chehab authored
Getting signal strength requires some loop poking with I2C. Don't let it happen too fast. Signed-off-by: -
Mauro Carvalho Chehab authored
A register typo made the calculation to not work. Fix it. Signed-off-by: -
Mauro Carvalho Chehab authored
State 9 means TS started to be output, and it should be associated with FE_HAS_SYNC. The mb86a20scan get CNR statistics at state 7, when frame sync is obtained. As CNR may help to adjust the antenna, provide it earlier. A latter patch could eventually start outputing MER measures earlier, but that would require a bigger change, and probably won't be better than the current way, as the time between changing from state 8 to 9 is generally lower than the time to get the stats collected. Signed-off-by: -
Mauro Carvalho Chehab authored
Instead of hardcoding a fixed IF frequency of 3.3 MHz, use the IF frequency provided by the tuner driver. Signed-off-by: -
Mauro Carvalho Chehab authored
There are a few debug tests that are shown with dev_err() or dev_info(). Replace them by dev_dbg(). Signed-off-by: -
Frank Schaefer authored
The new eeproms with 16 address width still have the the device config dataset (the content of the old 8 bit eeproms) embedded. Hauppauge also continues to include the tveeprom data structure inside this dataset in their devices. The start address of the dataset depends on the start address of the microcode and a variable additional offset. It should be mentioned that Camera devices seem to use a different dataset type, which is not yet supported. Tested with devices "Hauppauge HVR-930C". I've also checked the USB-log from the "MSI Digivox ATSC" and it works the same way. Signed-off-by:
-
Frank Schaefer authored
We currently reserve an array of 256 bytes for the eeprom content in the device struct. For eeproms with 16 bit address width it might even be necessary to increase the buffer size further. Having such a big chunk of memory reserved even if the device has no eeprom and keeping it after it has already been processed seems to be a waste of memory. Change the code to allocate + free the eeprom memory dynamically. This also makes it possible to handle different dataset sizes depending on what is stored/found in the eeprom. Signed-off-by:
-
Frank Schaefer authored
Add a helper function for reading data blocks from i2c devices with 8 or 16 bit address width and 8 bit register width. This allows us to reduce the size of new code added by the following patches. Works only for devices with activated register auto incrementation. Signed-off-by:
-
Frank Schaefer authored
Newer devices (em2874, em2884, em28174, em25xx, em27[6,7,8]x) use eeproms with 16 bit instead of 8 bit address width. The used eeprom type depends on the chip type, which makes sure eeproms can't be damaged. This patch adds basic support for 16 bit eeproms only, which includes - reading the content - calculating the eeprom hash - displaying the content The eeprom content uses a different format, for which support will be added with subsequent patches. Tested with the "Hauppauge HVR-930C" and the "Speedlink VAD Laplace webcam" (with additional experimental patches). Signed-off-by:
-
Frank Schaefer authored
The data is stored as little endian in the eeprom. Hence the correct data types should be used and the data should be converted to the machine endianess before using it. The eeprom id (key) also isn't a 32 bit value but 4 separate bytes instead. [mchehab@redhat.com: Fix CodingStyle] Signed-off-by:
-
Frank Schaefer authored
If the eeprom key isn't valid, either a different (currently unknown) format is used or the eeprom is corrupted. In both cases it doesn't make sense to interpret the data. Also print an error message. Signed-off-by:
-
Frank Schaefer authored
The current code uses only a single debug level and all debug messages are printed for i2c_debug >= 2 only. So debug level 1 is actually the same as level 0, which is odd. Users expect debugging messages to become enabled for anything else than debug level 0. Fix it and simplify the code a bit by printing the debug messages also at debug level 1; Signed-off-by:
-
Frank Schaefer authored
Reduces the number of characters/lines, unifies the code and improves readability. Signed-off-by:
-
Frank Schaefer authored
There is only a single place where the dprintk2 macro is used, so get rid of it. [mchehab@redhat.com: fix checkpathc.pl complain: ERROR: space prohibited before that close parenthesis ')'] Signed-off-by:
-
Frank Schaefer authored
The em28xx driver has changed much, especially since kernel 3.8. So it's time to bump the driver version. Changes since kernel 3.8: - converted the driver to videobuf2 - converted the driver to the v4l2-ctrl framework - added USB bulk transfer support - use USB bulk transfers by default for webcams (allows streaming from multiple devices at the same time) - added image quality bridge controls: contrast, brightness, saturation, blue balance, red balance, sharpness - removed dependency from module ir-kbd-i2c - cleaned up the frame data processing code - removed some unused/obsolete code - made remote controls of devices with external (i2c) receiver/decoder work again - fixed audio over USB for device "Terratec Cinergy 250" - several v4l2 compliance fixes and improvements (including fixes for ioctls enabling/disabling) - lots of further bug fixes and code improvements Signed-off-by:
-
Frank Schaefer authored
Signed-off-by:
-
Frank Schaefer authored
Signed-off-by:
-
Frank Schaefer authored
Add the image quality bridge controls contrast, brightness, saturation, blue balance, red balance and sharpness. These controls are enabled only if no subdevice provides them. Tested with the following devices: "Terratec Cinergy 200 USB" "Hauppauge HVR-900" "SilverCrest 1.3MPix webcam" "Hauppauge WinTV USB2" "Speedlink VAD Laplace webcam" Signed-off-by:
-
Frank Schaefer authored
The image quality default values will be used in at least two different places and by using #defines we make sure that they are always consistent. Signed-off-by:
-
Frank Schaefer authored
Signed-off-by:
-
Frank Schaefer authored
Signed-off-by:
-
Frank Schaefer authored
[media] em28xx: VIDIOC_ENUM_FRAMESIZES: consider the scaler limits when calculating the minimum frame size Output resolutions <=20% of the input resolution exceed the capabilities of the scaler. Signed-off-by:
-
Frank Schaefer authored
Signed-off-by:
-
Frank Schaefer authored
Signed-off-by:
-
Frank Schaefer authored
The maximum supported scaling value for registers 0x30+0x31 (horizontal scaling) and 0x32+0x33 (vertical scaling) is 0x3fff, which corresponds to 20% of the input frame size. Signed-off-by:
-
Frank Schaefer authored
Avoids registering a VBI device and streaming in VBI-mode if the device is a camera. Signed-off-by:
-
