- 19 Feb, 2016 20 commits
-
-
Laurent Pinchart authored
Not all VSP1 instances include a UDS. Make the renesas,#uds DT property optional and accept a number of UDS equal to 0 as valid. Signed-off-by:
Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com> Signed-off-by:
Mauro Carvalho Chehab <mchehab@osg.samsung.com>
-
Laurent Pinchart authored
The rwpf queue operation doesn't queue a buffer but sets the memory address for the next run. Rename it to set_memory and pass it a new structure independent of the video buffer than only contains memory information. Signed-off-by:
-
Laurent Pinchart authored
To make the video device nodes optional we need to decouple the [rw]pf instances from the video devices. Move video devices out of struct vsp1_rwpf and instantiate them dynamically in the core driver code. Signed-off-by:
-
Laurent Pinchart authored
The structure represent a vsp1 videobuf2 buffer, name it accordingly. Signed-off-by:
-
Laurent Pinchart authored
This removes the dependency of vsp1_rpf and vsp1_wpf on vsp1_video, making it possible to reuse the operations without a V4L2 video device node. Signed-off-by:
-
Laurent Pinchart authored
Move the format from struct vsp1_video to struct vsp1_rwpf to prepare for VSPD KMS support that will not instantiate V4L2 video device nodes. Signed-off-by:
-
Laurent Pinchart authored
The rwpf field contains a pointer to the rpf or wpf associated with the video node. Instead of storing it as a vsp1_entity, store the corresponding vsp1_rwpf pointer to allow accessing the vsp1_rwpf fields directly. Signed-off-by:
-
Laurent Pinchart authored
There's no need to spread the code across multiple source files. Signed-off-by:
-
Laurent Pinchart authored
Tri-planar memory formats store the Y, U and V components in separate planes. The VSP hardware supports them, the driver now does too. Signed-off-by:
-
Laurent Pinchart authored
The formats use three planes through the multiplanar API, allowing for non-contiguous planes in memory. Signed-off-by:
Hans Verkuil <hans.verkuil@cisco.com> Signed-off-by:
-
Benoit Parrot authored
Fix the following sparse warnings: ti-vpe/cal.c:387:26: warning: incorrect type in return expression (different address spaces) ti-vpe/cal.c:459:26: warning: incorrect type in return expression (different address spaces) ti-vpe/cal.c:503:27: warning: incorrect type in argument 6 (different address spaces) ti-vpe/cal.c:509:47: warning: incorrect type in argument 6 (different address spaces) ti-vpe/cal.c:518:47: warning: incorrect type in argument 6 (different address spaces) ti-vpe/cal.c:526:31: warning: incorrect type in argument 6 (different address spaces) ti-vpe/cal.c:1807:24: warning: Using plain integer as NULL pointer ti-vpe/cal.c:1844:16: warning: Using plain integer as NULL pointer Signed-off-by:
Benoit Parrot <bparrot@ti.com> Signed-off-by:
-
Wu-Cheng Li authored
There is a new control V4L2_CID_MPEG_VIDEO_FORCE_KEY_FRAME to force an encoder key frame. It is the same as requesting V4L2_MPEG_MFC51_VIDEO_FORCE_FRAME_TYPE_I_FRAME. Signed-off-by:
Wu-Cheng Li <wuchengli@chromium.org> Acked-by:
Sylwester Nawrocki <s.nawrocki@samsung.com> Signed-off-by:
-
Wu-Cheng Li authored
Some drivers also need a control like V4L2_CID_MPEG_MFC51_VIDEO_FORCE_FRAME_TYPE to force an encoder key frame. Add a general V4L2_CID_MPEG_VIDEO_FORCE_KEY_FRAME so the new drivers and applications can use it. Signed-off-by:
-
Hans de Goede authored
bytesperline should be the bytesperline for the first plane for planar formats, not that of all planes combined. This fixes a crash in xawtv caused by the wrong bpl. BugLink: https://bugzilla.redhat.com/show_bug.cgi?id=1305389Reported-and-tested-by:
Stas Sergeev <stsp@list.ru> Cc: stable@vger.kernel.org Signed-off-by:
Hans de Goede <hdegoede@redhat.com> Signed-off-by:
-
Sudip Mukherjee authored
The build of m32r allmodconfig fails with the error: drivers/media/v4l2-core/videobuf2-dma-contig.c:492:28: error: implicit declaration of function 'dma_get_cache_alignment' The build of videobuf2-dma-contig.c depends on HAS_DMA and it is correctly mentioned in the Kconfig but the symbol VIDEO_TI_CAL also selects VIDEOBUF2_DMA_CONTIG, so it is trying to compile videobuf2-dma-contig.c even though HAS_DMA is not defined. Fixes: 343e89a7 ("[media] media: ti-vpe: Add CAL v4l2 camera capture driver") Cc: Benoit Parrot <bparrot@ti.com> Signed-off-by:
Sudip Mukherjee <sudip@vectorindia.org> Signed-off-by:
-
Hans Verkuil authored
The Timberdale FPGA video driver has not seen any real development since 2011 (and very little before that). One of the problems with the timblogiw driver is that it uses videobuf instead of the newer vb2 framework. The long term goal is to either convert or remove any driver still using videobuf. Since none of the core v4l developers has the hardware, we cannot convert it ourselves. As far as I can tell it was only used in an Intel demo board in 2009 using Meego: http://www.chinait.com/intelcontent/intelprc/admin/PDFFile/20106411545.pdf which has since been superseded. Moving this driver to staging is the first step towards removal. After 2 or 3 kernel cycles it will be removed altogether unless someone steps up to clean up this driver. Signed-off-by:
Richard Röjfors <richard@puffinpack.se> Signed-off-by:
-
Hans Verkuil authored
The V4L2_CID_TX_EDID_PRESENT control reports if an EDID is present. The adv7511 however still reported the EDID present after disconnecting the HDMI cable. Fix the logic regarding this control. And when the EDID is disconnected also call ADV7511_EDID_DETECT to notify the bridge driver. This was also missing. Signed-off-by:
-
Dan Carpenter authored
It makes sense to make the min_t() cast unsigned here since we don't really want negative sizes. Making it signed causes a static checker warning in Smatch. Smatch knows "fw->size - i" is positive but it doesn't know that fw->size is less than INT_MAX so in theory casting it to int might lead to a negative. Signed-off-by:
Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by:
-
Insu Yun authored
Since kthread_run returns -ENOMEM if failed, it needs to be checked whether it is error, not whether it is null. Signed-off-by:
Insu Yun <wuninsu@gmail.com> Signed-off-by:
-
Javier Martinez Canillas authored
After sub-dev registration in v4l2_async_test_notify(), the v4l2-async core calls the registered_async callback but if a sub-dev driver does not implement it, v4l2_subdev_call() will return a -ENOIOCTLCMD which should not be considered an error. Reported-by:
Javier Martinez Canillas <javier@osg.samsung.com> Tested-by:
Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by:
-
- 16 Feb, 2016 20 commits
-
-
Mauro Carvalho Chehab authored
Currently, it is initializing the driver name using the wrong name ("usb"). Use the generic function, as its logic works best, and avoids repeating the very same code everywhere. Signed-off-by: -
Mauro Carvalho Chehab authored
smscore_getbuffer() calls internally wait_event(), with can sleep. As smsusb_onresponse() is called on interrupt context, this causes the following warning: BUG: sleeping function called from invalid context at drivers/media/common/siano/smscoreapi.c:1653 in_atomic(): 1, irqs_disabled(): 1, pid: 11084, name: systemd-udevd INFO: lockdep is turned off. irq event stamp: 0 hardirqs last enabled at (0): [< (null)>] (null) hardirqs last disabled at (0): [<ffffffff811480f7>] copy_process.part.7+0x10e7/0x56d0 softirqs last enabled at (0): [<ffffffff81148193>] copy_process.part.7+0x1183/0x56d0 softirqs last disabled at (0): [< (null)>] (null) CPU: 2 PID: 11084 Comm: systemd-udevd Tainted: G B W 4.5.0-rc3+ #47 Hardware name: /NUC5i7RYB, BIOS RYBDWi35.86A.0350.2015.0812.1722 08/12/2015 0000000000000000 ffff8803c6907a80 ffffffff81933901 ffff8802bd916000 ffff8802bd9165c8 ffff8803c6907aa8 ffffffff811c6af5 ffff8802bd916000 ffffffffa0ce9b60 0000000000000675 ffff8803c6907ae8 ffffffff811c6ce5 Call Trace: <IRQ> [<ffffffff81933901>] dump_stack+0x85/0xc4 [<ffffffff811c6af5>] ___might_sleep+0x245/0x3a0 [<ffffffff811c6ce5>] __might_sleep+0x95/0x1a0 [<ffffffffa0ce020a>] ? list_add_locked+0xca/0x140 [smsmdtv] [<ffffffffa0ce3b8d>] smscore_getbuffer+0x7d/0x120 [smsmdtv] [<ffffffff8123819d>] ? trace_hardirqs_off+0xd/0x10 [<ffffffffa0ce3b10>] ? smscore_sendrequest_and_wait.isra.5+0x120/0x120 [smsmdtv] [<ffffffffa0ce020a>] ? list_add_locked+0xca/0x140 [smsmdtv] [<ffffffffa0ce13ca>] ? smscore_putbuffer+0x3a/0x40 [smsmdtv] [<ffffffffa0d107bc>] smsusb_submit_urb+0x2ec/0x4f0 [smsusb] [<ffffffffa0d10e36>] smsusb_onresponse+0x476/0x720 [smsusb] Let's add a work queue to handle the bottom half, preventing this problem. Signed-off-by: -
Mauro Carvalho Chehab authored
As pointed by KASAN: BUG: KASAN: slab-out-of-bounds in memcpy+0x1d/0x40 at addr ffff880000038d8c Read of size 128 by task systemd-udevd/2536 page:ffffea0000000800 count:1 mapcount:0 mapping: (null) index:0x0 compound_mapcount: 0 flags: 0xffff8000004000(head) page dumped because: kasan: bad access detected CPU: 1 PID: 2536 Comm: systemd-udevd Not tainted 4.5.0-rc3+ #47 Hardware name: /NUC5i7RYB, BIOS RYBDWi35.86A.0350.2015.0812.1722 08/12/2015 ffff880000038d8c ffff8803b0f1f1e8 ffffffff81933901 0000000000000080 ffff8803b0f1f280 ffff8803b0f1f270 ffffffff815602c5 ffffffff8284cf93 ffffffff822ddc00 0000000000000282 0000000000000001 ffff88009c7c6000 Call Trace: [<ffffffff81933901>] dump_stack+0x85/0xc4 [<ffffffff815602c5>] kasan_report_error+0x525/0x550 [<ffffffff815606e9>] kasan_report+0x39/0x40 [<ffffffff8155f84d>] memcpy+0x1d/0x40 [<ffffffffa120cb90>] smscore_set_device_mode+0xee0/0x2560 [smsmdtv] Such error happens at the memcpy code below: 0x4bc0 is in smscore_set_device_mode (drivers/media/common/siano/smscoreapi.c:975). 970 sizeof(u32) + payload_size)); 971 972 data_msg->mem_addr = mem_address; 973 memcpy(data_msg->payload, payload, payload_size); 974 975 rc = smscore_sendrequest_and_wait(coredev, data_msg, 976 data_msg->x_msg_header.msg_length, 977 &coredev->data_download_done); 978 979 payload += payload_size; The problem is that the Siano driver uses a header to store the firmware, with requires a few more bytes than allocated. Tested with: PCTV 77e (2013:0257) Hauppauge WinTV MiniStick (2040:5510) Signed-off-by: -
Mauro Carvalho Chehab authored
Some macros were changed/removed at the material for v4.5. We need to sync with those changes here, in order to avoid troubles. * v4l_for_linus: [media] media.h: get rid of MEDIA_ENT_F_CONN_TEST [media] [for,v4.5] media.h: increase the spacing between function ranges [media] media: i2c/adp1653: probe: fix erroneous return value [media] media: davinci_vpfe: fix missing unlock on error in vpfe_prepare_pipeline()
-
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 authored
Defining it as a connector was a bad idea. Remove it while it is not too late. Signed-off-by: -
Hans Verkuil authored
Each function range is quite narrow and especially for connectors this will pose a problem. Increase the function ranges while we still can and move the connector range to the end so that range is practically limitless. [mchehab@osg.samsung.com: Rebased to apply at Linus tree] Signed-off-by:
-
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:
-
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:
-
