- 16 Feb, 2016 15 commits
-
-
Mauro Carvalho Chehab authored
Defining it as a connector was a bad idea. Remove it while it is not too late. Signed-off-by:Mauro Carvalho Chehab <mchehab@osg.samsung.com>
-
Mauro Carvalho Chehab authored
MEDIA_ENT_F_CONN_TEST is not really a connector, it is actually a signal generator. Also, as other drivers use the V4L2_CID_TEST_PATTERN control for signal generators, let's change the driver accordingly. Tested with Terratec Grabster AV350. Signed-off-by: -
Mauro Carvalho Chehab authored
This macro is not used inside the driver. get rid of it. Acked-by:
Hans Verkuil <hans.verkuil@cisco.com> Signed-off-by:
-
Mauro Carvalho Chehab authored
This is not used on the driver. remove it. Acked-by:
-
Mauro Carvalho Chehab authored
This fixes this warning: v4l2-mc.c: In function 'v4l2_mc_create_media_graph': v4l2-mc.c:60:69: warning: variable 'sensor' set but not used [-Wunused-but-set-variable] We could solve it the other way: don't do the second loop for webcams. However, that would fail if a chip would have two sensors plugged. This is not the current case, but it doesn't hurt to be future-safe here, specially since this code runs only once during device probe. So, performance is not an issue here. Reported-by:
Hans Verkuil <hverkuil@xs4all.nl> Signed-off-by:
-
Mauro Carvalho Chehab authored
We need to add connectors to the cx231xx graph. Signed-off-by: -
Mauro Carvalho Chehab authored
As si2157 doesn't use the subdev, but has instead a binding logic that doesn't have any core framework, we need to manually pass the media_device struct via platform data on every place it is called. This fixes support for HVR-955Q when MC is enabled. Signed-off-by: -
Mauro Carvalho Chehab authored
As this tuner doesn't use the usual subdev interface, we need to register it manually. Signed-off-by: -
Mauro Carvalho Chehab authored
Instead of having its own routine, use the one defined at the core, as it is generic enough to handle the cx231xx usecases. Signed-off-by: -
Mauro Carvalho Chehab authored
When in analog mode, the RF connector will be created by em28xx-video. However, when the device is in digital mode only, the RF connector is not shown. In this case, let the DVB core to create it for us. Signed-off-by: -
Mauro Carvalho Chehab authored
Except for the usbuvc driver (with has an embedded media_device struct on it), the other drivers have a pointer to media_device. On those drivers, replace their own implementation for the core one. That warrants that those subdev drivers will fill the media_device info the same way. Signed-off-by: -
Mauro Carvalho Chehab authored
On USB drivers, the dev struct is usually filled with the USB device. That would mean that the name of the driver specified by media_device.dev.driver.name would be "usb", instead of the name of the actual driver that created the media entity. Add an optional field at the internal struct to allow drivers to override the driver name. Signed-off-by: -
Mauro Carvalho Chehab authored
The mutex lock at rc_register_device() was added by commit 08aeb7c9 ("[media] rc: add locking to fix register/show race"). It is meant to avoid race issues when trying to open a sysfs file while the RC register didn't complete. Adding a lock there causes troubles, as detected by the Kernel lock debug instrumentation at the Kernel: ====================================================== [ INFO: possible circular locking dependency detected ] 4.5.0-rc3+ #46 Not tainted ------------------------------------------------------- systemd-udevd/2681 is trying to acquire lock: (s_active#171){++++.+}, at: [<ffffffff8171a115>] kernfs_remove_by_name_ns+0x45/0xa0 but task is already holding lock: (&dev->lock){+.+.+.}, at: [<ffffffffa0724def>] rc_register_device+0xb2f/0x1450 [rc_core] which lock already depends on the new lock. the existing dependency chain (in reverse order) is: -> #1 (&dev->lock){+.+.+.}: [<ffffffff8124817d>] lock_acquire+0x13d/0x320 [<ffffffff822de966>] mutex_lock_nested+0xb6/0x860 [<ffffffffa0721f2b>] show_protocols+0x3b/0x3f0 [rc_core] [<ffffffff81cdaba5>] dev_attr_show+0x45/0xc0 [<ffffffff8171f1b3>] sysfs_kf_seq_show+0x203/0x3c0 [<ffffffff8171a6a1>] kernfs_seq_show+0x121/0x1b0 [<ffffffff81617c71>] seq_read+0x2f1/0x1160 [<ffffffff8171c911>] kernfs_fop_read+0x321/0x460 [<ffffffff815abc20>] __vfs_read+0xe0/0x3d0 [<ffffffff815ae90e>] vfs_read+0xde/0x2d0 [<ffffffff815b1d01>] SyS_read+0x111/0x230 [<ffffffff822e8636>] entry_SYSCALL_64_fastpath+0x16/0x76 -> #0 (s_active#171){++++.+}: [<ffffffff81244f24>] __lock_acquire+0x4304/0x5990 [<ffffffff8124817d>] lock_acquire+0x13d/0x320 [<ffffffff81717d3a>] __kernfs_remove+0x58a/0x810 [<ffffffff8171a115>] kernfs_remove_by_name_ns+0x45/0xa0 [<ffffffff81721592>] remove_files.isra.0+0x72/0x190 [<ffffffff8172174b>] sysfs_remove_group+0x9b/0x150 [<ffffffff81721854>] sysfs_remove_groups+0x54/0xa0 [<ffffffff81cd97d0>] device_remove_attrs+0xb0/0x140 [<ffffffff81cdb27c>] device_del+0x38c/0x6b0 [<ffffffffa0724b8b>] rc_register_device+0x8cb/0x1450 [rc_core] [<ffffffffa1326a7b>] dvb_usb_remote_init+0x66b/0x14d0 [dvb_usb] [<ffffffffa1321c81>] dvb_usb_device_init+0xf21/0x1860 [dvb_usb] [<ffffffffa13517dc>] dib0700_probe+0x14c/0x410 [dvb_usb_dib0700] [<ffffffff81dbb1dd>] usb_probe_interface+0x45d/0x940 [<ffffffff81ce7e7a>] driver_probe_device+0x21a/0xc30 [<ffffffff81ce89b1>] __driver_attach+0x121/0x160 [<ffffffff81ce21bf>] bus_for_each_dev+0x11f/0x1a0 [<ffffffff81ce6cdd>] driver_attach+0x3d/0x50 [<ffffffff81ce5df9>] bus_add_driver+0x4c9/0x770 [<ffffffff81cea39c>] driver_register+0x18c/0x3b0 [<ffffffff81db6e98>] usb_register_driver+0x1f8/0x440 [<ffffffffa074001e>] dib0700_driver_init+0x1e/0x1000 [dvb_usb_dib0700] [<ffffffff810021b1>] do_one_initcall+0x141/0x300 [<ffffffff8144d8eb>] do_init_module+0x1d0/0x5ad [<ffffffff812f27b6>] load_module+0x6666/0x9ba0 [<ffffffff812f5fe8>] SyS_finit_module+0x108/0x130 [<ffffffff822e8636>] entry_SYSCALL_64_fastpath+0x16/0x76 other info that might help us debug this: Possible unsafe locking scenario: CPU0 CPU1 ---- ---- lock(&dev->lock); lock(s_active#171); lock(&dev->lock); lock(s_active#171); *** DEADLOCK *** 3 locks held by systemd-udevd/2681: #0: (&dev->mutex){......}, at: [<ffffffff81ce8933>] __driver_attach+0xa3/0x160 #1: (&dev->mutex){......}, at: [<ffffffff81ce8941>] __driver_attach+0xb1/0x160 #2: (&dev->lock){+.+.+.}, at: [<ffffffffa0724def>] rc_register_device+0xb2f/0x1450 [rc_core] In this specific case, some error happened during device init, causing IR to be disabled. Let's fix it by adding a var that will tell when the device is initialized. Any calls before that will return a -EINVAL. That should prevent the race issues. Signed-off-by:
-
Mauro Carvalho Chehab authored
Instead of copying exactly the same code on all USB devices, add an ancillary routine that will create and fill the struct media_device with the values imported from the USB device. Signed-off-by: -
Mauro Carvalho Chehab authored
Don't let it be included twice, to avoid compiler issues. Acked-by:
-
- 11 Feb, 2016 3 commits
-
-
Javier Martinez Canillas authored
The tvp5150 decoder has different input connectors. The actual list of HW inputs depends on the device version but all have at least these 3: 1) Composite0 2) Composite1 3) S-Video and some variants have a 4th possible input connector: 4) Signal generator The driver currently uses the .s_routing callback to switch the input connector but since these are separate HW blocks, it's better to use media entities to represent the input connectors and their source pads linked with the decoder's sink pad. This allows user-space to use the MEDIA_IOC_SETUP_LINK ioctl to choose the input connector. For example using the media-ctl user-space tool: $ media-ctl -r -l '"Composite0":0->"tvp5150 1-005c":0[1]' Signed-off-by:
Javier Martinez Canillas <javier@osg.samsung.com> Signed-off-by:
-
Javier Martinez Canillas authored
The tvp5150 decoder has different input connectors so extend the device tree binding to allow device tree source files to define the connectors that are available on a given board. Signed-off-by:
-
Javier Martinez Canillas authored
Add a header file for the tvp5150 input connectors constants that can be shared between the driver and Device Tree source files. [mchehab@osg.samsung.com: rename tvp5150.h also at em28xx-cards.c] Signed-off-by:
-
- 10 Feb, 2016 22 commits
-
-
Javier Martinez Canillas authored
Some tvp5150 variants, have an internal generator that can generate a black screen output. Since this is a HW block, it should be in the HW inputs list. Signed-off-by:
-
Javier Martinez Canillas authored
Not all tvp5150 variants support the same, for example some have an internal signal generator that can output a black screen. So the device id and rom version have to be stored in the driver's state to know what variant is a given device. While being there, remove some redundant comments about the device version since there is already calls to v4l2_info() with that info. Signed-off-by:
-
Javier Martinez Canillas authored
If the parallel mbus configuration is not correct, the endpoint device node isn't currently put again in the error path. Fix it. Signed-off-by:
-
Javier Martinez Canillas authored
V4L2 sub-devices might need to do initialization that depends on being registered with a V4L2 device. As an example, sub-devices with Media Controller support may need to register entities and create pad links. Execute the registered_async callback after the sub-device has been registered with the V4L2 device so the driver can do any needed init. Signed-off-by:
-
Javier Martinez Canillas authored
V4L2 sub-devices that are registered asynchronously have no way to know when they have been registration with a V4L2 device but they might need to take some action after this. So let's add a callback that can be executed by the V4L2 async core to allow sub-devices drivers to do any needed initialization that depends on the registration. Signed-off-by:
-
Andy Shevchenko authored
The module is used only as a library for now. Remove module init and exit routines to show this. While here, remove FSF snail address and attach EXPORT_SYMBOL() macros to corresponding functions. Signed-off-by:
Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by:
-
Vladimir Zapolskiy authored
v4l2_ctrl_add_ctrl() interface has no users since its introduction in commit 0996517c ("V4L/DVB: v4l2: Add new control handling framework") and its functionality is covered by v4l2_ctrl_new() and derivative interfaces, so it is safe to remove the interface from the kernel. Signed-off-by:
Vladimir Zapolskiy <vz@mleia.com> Signed-off-by:
-
Hans Verkuil authored
This transmitter now supports configuring the IT content type of the incoming video. Signed-off-by:
-
Hans Verkuil authored
This receiver now supports reading the IT content type of the incoming video. Signed-off-by:
-
Hans Verkuil authored
This receiver now supports reading the IT content type of the incoming video. Signed-off-by:
-
Hans Verkuil authored
Document these new controls. Signed-off-by:
-
Hans Verkuil authored
HDMI and DisplayPort both support IT Content Type information that tells the receiver what type of material the video is, graphics such as from a PC desktop, Photo, Cinema or Game (low-latency). This patch adds controls for receivers and transmitters to get/set this information. Signed-off-by:
-
Jean-Michel Hautbois authored
Use the helper to enumerate and set DV timings instead of a custom code. This will ease debugging too, as it is consistent with other drivers. Signed-off-by:
Jean-Michel Hautbois <jean-michel.hautbois@veo-labs.com> Signed-off-by:
-
Amitoj Kaur Chawla authored
Remove an unnecassary cast in the argument to kfree. Found using Coccinelle. The semantic patch used to find this is as follows: //<smpl> @@ type T; expression *f; @@ - kfree((T *)(f)); + kfree(f); //</smpl> Signed-off-by:
Amitoj Kaur Chawla <amitoj1606@gmail.com> Signed-off-by:
-
Guennadi Liakhovetski authored
Auto-gain and auto-exposure clusters in the ov9650 driver have both a size of 2, not 3 controls. Fix this. Signed-off-by:
Guennadi Liakhovetski <g.liakhovetski@gmx.de> Reviewed-by:
Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by:
-
Mauro Carvalho Chehab authored
Instead of having lots of #ifdefs inside au0828-core due to V4L2, move the dependencies to au0828-video.c. That allows removing all those ifdefs, as au0828-video is only compiled if CONFIG_VIDEO_AU0828_V4L2. This fixes the following warnings reported by Kbuild test with a random config with au0828 enabled, but V4L2 is disabled. All warnings (new ones prefixed by >>): drivers/media/usb/au0828/au0828-core.c: In function 'au0828_usb_probe': >> drivers/media/usb/au0828/au0828-core.c:463:1: warning: label 'done' defined but not used [-Wunused-label] done: ^ drivers/media/usb/au0828/au0828-core.c: At top level: drivers/media/usb/au0828/au0828-core.c:250:12: warning: 'au0828_create_media_graph' defined but not used [-Wunused-function] static int au0828_create_media_graph(struct au0828_dev *dev) ^ Tested with a WinTV HVR 950Q (USB ID: 2040:7200) Signed-off-by: -
Mauro Carvalho Chehab authored
It doesn't make sense to try to create the analog TV graph, if the device fails to register at V4L2, or if it doesn't have V4L2 support. Thanks to Shuah for pointing this issue. Reported-by:
Shuah Khan <shuahkh@osg.samsung.com> Signed-off-by:
-
Mauro Carvalho Chehab authored
Register saa7134 at the media controller core and provide support for both analog TV and DVB. Signed-off-by: -
Mauro Carvalho Chehab authored
Instead of copyping the same code on all PCI devices that would have a media controller, add a core ancillary routine. Signed-off-by: -
Mauro Carvalho Chehab authored
The saa7134_input.tv field was used to indicate if an input had a RF signal for TV input. This is not needed anymore, as the input type can be checked directly by the driver. Also, due to a past bug when setting the TV standard at the demod, all inputs should have this field set, with is wrong. This reduces the size of the saa7134_boards by about 8KB, on i386 (and probably twice on 64 bits), with is a nice colateral effect: text data bss dec hex filename 241047 136831 66356 444234 6c74a drivers/media/pci/saa7134/saa7134.o.old 240851 128895 66292 436038 6a746 drivers/media/pci/saa7134/saa7134.o Signed-off-by: -
Mauro Carvalho Chehab authored
It doesn't make any sense to only update the TV standard for TV, as composite and S-Video inputs also need it. Signed-off-by: -
Mauro Carvalho Chehab authored
Currently, the saa7134 driver is hardcoding input names on each board entry. More modern drivers define, instead, an enum for each input type. While the current logic works, it adds extra complexity at the driver, as it needs to discover the type of the input using some euristics. Instead, let's standardize the input types and use a type, instead of a name on all places. That will allow further patches to properly report the input type via VIDIOC_G_INPUT and to remove an extra field from the struct to identify if the input is for TV. Please notice that several boards define an input for receiving composite signals via a S-Video connector. The name of such input was inconsistent, so this patch cleans it and make it to be properly reported the same way for all boards. Signed-off-by:
-
