- 04 Mar, 2013 36 commits
-
-
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 <mchehab@redhat.com>
-
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 Schäfer <fschaefer.oss@googlemail.com> 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:
Hans Verkuil <hans.verkuil@cisco.com> 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:
-
Frank Schaefer authored
Signed-off-by:
-
Frank Schaefer authored
[media] em28xx: make ioctl VIDIOC_DBG_G_CHIP_IDENT available without CONFIG_VIDEO_ADV_DEBUG selected VIDIOC_DBG_G_CHIP_IDENT is a "normal" and not an "advanced" debug functionality. Signed-off-by:
-
Frank Schaefer authored
v4l2_device_disconnect() is called when the device is disconnected, so that the v4l2-core rejects all ioctl calls. Signed-off-by:
-
Frank Schaefer authored
The tuner type is set by the v4l2-core based on the device type. Signed-off-by:
-
Frank Schaefer authored
vidioc_s_fmt_vbi_cap() is a 100% duplicate of vidioc_g_fmt_vbi_cap() and therefore can be removed. Signed-off-by:
-
Frank Schaefer authored
The em28xx driver doesn't support the VIDIOC_G_CROP and VIDIOC_S_CROP ioctls, so VIDIOC_CROPCAP is useless and has the potential to confuse applications, because it can be interpreted as indicator for cropping support. Signed-off-by:
-
Frank Schaefer authored
With the current code V4L2_BUF_TYPE_VIDEO_CAPTURE is accepted only, but for VBI devices only buffer type V4L2_BUF_TYPE_VBI_CAPTURE is used/valid. Signed-off-by:
-
Frank Schaefer authored
VIDIOC_S_PARM doesn't make sense for VBI device nodes, because we don't support selecting the number of read buffers to use. Signed-off-by:
-
Frank Schaefer authored
Instead of checking the device type and returning -ENOTTY inside the ioctl function, use v4l2_disable_ioctl() to disable the ioctl VIDIOC_S_PARM if the device is not a camera. Signed-off-by:
-
Frank Schaefer authored
Instead of checking the device type and returning -EINVAL inside the ioctl functions, use v4l2_disable_ioctl() to disable the ioctls VIDIOC_G_AUDIO and VIDIOC_S_AUDIO if the device doesn't support audio. Signed-off-by:
-
Frank Schaefer authored
Disable the ioctls VIDIOC_G_TUNER, VIDIOC_S_TUNER, VIDIOC_G_FREQUENCY and VIDIOC_S_FREQUENCY for video and VBI devices without tuner. Signed-off-by:
-
Frank Schaefer authored
Instead of checking the device type and returning -ENOTTY inside the ioctl functions, use v4l2_disable_ioctl() to disable the ioctls VIDIOC_QUERYSTD, VIDIOC_G_STD and VIDIOC_S_STD if the device is a camera. Signed-off-by:
-
Mauro Carvalho Chehab authored
Linux 3.9-rc1 * tag 'v3.9-rc1': (10698 commits) Linux 3.9-rc1 btrfs/raid56: Add missing #include <linux/vmalloc.h> fix compat_sys_rt_sigprocmask() SUNRPC: One line comment fix ext4: enable quotas before orphan cleanup ext4: don't allow quota mount options when quota feature enabled ext4: fix a warning from sparse check for ext4_dir_llseek ext4: convert number of blocks to clusters properly ext4: fix possible memory leak in ext4_remount() jbd2: fix ERR_PTR dereference in jbd2__journal_start metag: Provide dma_get_sgtable() metag: prom.h: remove declaration of metag_dt_memblock_reserve() metag: copy devicetree to non-init memory metag: cleanup metag_ksyms.c includes metag: move mm/init.c exports out of metag_ksyms.c metag: move usercopy.c exports out of metag_ksyms.c metag: move setup.c exports out of metag_ksyms.c metag: move kick.c exports out of metag_ksyms.c metag: move traps.c exports out of metag_ksyms.c metag: move irq enable out of irqflags.h on SMP ...
-
- 03 Mar, 2013 4 commits
-
-
Linus Torvalds authored
-
git://git.infradead.org/users/dhowells/linux-headersLinus Torvalds authored
Pull fbdev UAPI disintegration from David Howells: "You'll be glad to here that the end is nigh for the UAPI patches. Only the fbdev/framebuffer piece remains now that the SCSI stuff has gone in. Here are the UAPI disintegration bits for the fbdev drivers. It appears that Florian hasn't had time to deal with my patch, but back in December he did say he didn't mind if I pushed it forward." Yay. No more uapi movement. And hopefully no more big header file cleanups coming up either, it just tends to be very painful. * tag 'disintegrate-fbdev-20121220' of git://git.infradead.org/users/dhowells/linux-headers: UAPI: (Scripted) Disintegrate include/video
-
Linus Torvalds authored
Merge tag 'stable/for-linus-3.9-rc1-tag' of git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen Pull Xen bug-fixes from Konrad Rzeszutek Wilk: - Update the Xen ACPI memory and CPU hotplug locking mechanism. - Fix PAT issues wherein various applications would not start - Fix handling of multiple MSI as AHCI now does it. - Fix ARM compile failures. * tag 'stable/for-linus-3.9-rc1-tag' of git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen: xenbus: fix compile failure on ARM with Xen enabled xen/pci: We don't do multiple MSI's. xen/pat: Disable PAT using pat_enabled value. xen/acpi: xen cpu hotplug minor updates xen/acpi: xen memory hotplug minor updates
-
git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfsLinus Torvalds authored
Pull more VFS bits from Al Viro: "Unfortunately, it looks like xattr series will have to wait until the next cycle ;-/ This pile contains 9p cleanups and fixes (races in v9fs_fid_add() etc), fixup for nommu breakage in shmem.c, several cleanups and a bit more file_inode() work" * 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs: constify path_get/path_put and fs_struct.c stuff fix nommu breakage in shmem.c cache the value of file_inode() in struct file 9p: if v9fs_fid_lookup() gets to asking server, it'd better have hashed dentry 9p: make sure ->lookup() adds fid to the right dentry 9p: untangle ->lookup() a bit 9p: double iput() in ->lookup() if d_materialise_unique() fails 9p: v9fs_fid_add() can't fail now v9fs: get rid of v9fs_dentry 9p: turn fid->dlist into hlist 9p: don't bother with private lock in ->d_fsdata; dentry->d_lock will do just fine more file_inode() open-coded instances selinux: opened file can't have NULL or negative ->f_path.dentry (In the meantime, the hlist traversal macros have changed, so this required a semantic conflict fixup for the newly hlistified fid->dlist)
-
