- 10 Nov, 2019 15 commits
-
-
Hans Verkuil authored
Running the contrib/test/test-media script in v4l-utils with the vim2m argument will cause this kernel warning: [ 554.430157] ------------[ cut here ]------------ [ 554.433034] DEBUG_LOCKS_WARN_ON(lock->magic != lock) [ 554.433064] WARNING: CPU: 0 PID: 616 at kernel/locking/mutex.c:938 __mutex_lock+0xd7a/0x1380 [ 554.439736] Modules linked in: vim2m v4l2_mem2mem vivid rc_cec videobuf2_dma_contig v4l2_dv_timings cec videobuf2_vmalloc videobuf2_memops v4l2_tpg videobuf2_v4l2 videobuf2_common videodev mc rc_core [last unloaded: vivid] [ 554.445794] CPU: 0 PID: 616 Comm: sleep Not tainted 5.4.0-rc1-virtme #1 [ 554.448481] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.12.0-0-ga698c8995f-prebuilt.qemu.org 04/01/2014 [ 554.453088] RIP: 0010:__mutex_lock+0xd7a/0x1380 [ 554.454955] Code: d2 0f 85 de 05 00 00 44 8b 05 82 d9 f7 00 45 85 c0 0f 85 bf f3 ff ff 48 c7 c6 e0 30 a6 b7 48 c7 c7 e0 2e a6 b7 e8 5c 76 36 fe <0f> 0b e9 a5 f3 ff ff 65 48 8b 1c 25 80 ef 01 00 be 08 00 00 00 48 [ 554.462836] RSP: 0018:ffff88803a4cfad0 EFLAGS: 00010282 [ 554.465129] RAX: 0000000000000000 RBX: 0000000000000000 RCX: ffffffffb5a3d24f [ 554.468143] RDX: 0000000000000000 RSI: 0000000000000004 RDI: ffffffffb85273f4 [ 554.471000] RBP: ffff88803a4cfc50 R08: fffffbfff701e681 R09: fffffbfff701e681 [ 554.473990] R10: fffffbfff701e680 R11: ffffffffb80f3403 R12: 0000000000000000 [ 554.476831] R13: dffffc0000000000 R14: ffffffffb9714f00 R15: ffff888053103fc8 [ 554.479622] FS: 00007fac6358a540(0000) GS:ffff88805d000000(0000) knlGS:0000000000000000 [ 554.482673] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 554.484949] CR2: 00007fac6343faf0 CR3: 0000000036c22000 CR4: 00000000003406f0 [ 554.487811] Call Trace: [ 554.488860] ? v4l2_release+0x1b8/0x390 [videodev] [ 554.490818] ? do_exit+0x946/0x2980 [ 554.492269] ? mutex_lock_io_nested+0x1250/0x1250 [ 554.494128] ? __lock_acquire+0xe90/0x3c30 [ 554.495774] ? fsnotify_first_mark+0x120/0x120 [ 554.497487] ? vim2m_device_release+0x50/0x50 [vim2m] [ 554.499469] ? v4l2_release+0x1b8/0x390 [videodev] [ 554.501493] v4l2_release+0x1b8/0x390 [videodev] [ 554.503430] __fput+0x256/0x790 [ 554.504711] task_work_run+0x109/0x190 [ 554.506145] do_exit+0x95e/0x2980 [ 554.507421] ? vfs_lock_file+0x21/0xf0 [ 554.509013] ? find_held_lock+0x33/0x1c0 [ 554.510382] ? __close_fd+0xee/0x190 [ 554.511862] ? release_task.part.21+0x1310/0x1310 [ 554.513701] ? lock_downgrade+0x6d0/0x6d0 [ 554.515299] do_group_exit+0xeb/0x2d0 [ 554.516862] __x64_sys_exit_group+0x35/0x40 [ 554.518610] do_syscall_64+0x90/0x450 [ 554.520142] entry_SYSCALL_64_after_hwframe+0x49/0xbe [ 554.522289] RIP: 0033:0x7fac6348ecf6 [ 554.523876] Code: Bad RIP value. [ 554.525294] RSP: 002b:00007ffe6373dc58 EFLAGS: 00000246 ORIG_RAX: 00000000000000e7 [ 554.528555] RAX: ffffffffffffffda RBX: 00007fac6357f760 RCX: 00007fac6348ecf6 [ 554.531537] RDX: 0000000000000000 RSI: 000000000000003c RDI: 0000000000000000 [ 554.534709] RBP: 0000000000000000 R08: 00000000000000e7 R09: ffffffffffffff80 [ 554.536752] R10: 00007ffe6373db24 R11: 0000000000000246 R12: 00007fac6357f760 [ 554.538643] R13: 0000000000000002 R14: 00007fac63588428 R15: 0000000000000000 [ 554.540634] irq event stamp: 21731 [ 554.541618] hardirqs last enabled at (21731): [<ffffffffb75b3cd4>] _raw_spin_unlock_irq+0x24/0x30 [ 554.544145] hardirqs last disabled at (21730): [<ffffffffb75b3ada>] _raw_spin_lock_irq+0xa/0x40 [ 554.547027] softirqs last enabled at (20148): [<ffffffffb780064d>] __do_softirq+0x64d/0x906 [ 554.550385] softirqs last disabled at (19857): [<ffffffffb5926bd5>] irq_exit+0x175/0x1a0 [ 554.553668] ---[ end trace a389c80c2ca84244 ]--- This is caused by media_device_cleanup() which destroys v4l2_dev->mdev->req_queue_mutex. But v4l2_release() tries to lock that mutex after media_device_cleanup() is called. By moving media_device_cleanup() to the video_device's release function it is guaranteed that the mutex is valid whenever v4l2_release is called. Signed-off-by:
Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by:
Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
-
Jernej Skrabec authored
There are few variations of 4k resolutions. The biggest one is 4096x2304 which is also supported by HW. It has also nice property that both width and size are divisible by maximum HEVC CTB size, which is 64. Signed-off-by:
Jernej Skrabec <jernej.skrabec@siol.net> Acked-by:
Paul Kocialkowski <paul.kocialkowski@bootlin.com> Signed-off-by:
-
Jernej Skrabec authored
H264 decoder needs additional or bigger buffers in order to decode 4k videos. Signed-off-by:
-
Jernej Skrabec authored
Mode register also holds information if video width is bigger than 2048 and if it is equal to 4096. Rework cedrus_engine_enable() to properly signal this properties. Signed-off-by:
Mauro Carvalho Chehab <mchehab@kernel.org>
-
Pi-Hsun Shih authored
There's a race condition between the list_del_init in the v4l2_ctrl_request_complete, and the list_add_tail in the v4l2_ctrl_request_queue, since they can be called in different thread and the requests_queued list is not protected by a lock. This can lead to that the v4l2_ctrl_handler is still in the requests_queued list while the request_is_queued is already set to false, which would cause use-after-free if the v4l2_ctrl_handler is later released. Fix this by locking the ->lock of main_hdl (which is the owner of the requests_queued list) when doing list operations on the ->requests_queued list. Signed-off-by:
Pi-Hsun Shih <pihsun@chromium.org> Signed-off-by:
-
Chuhong Yuan authored
The driver misses calling v4l2_ctrl_handler_free and v4l2_device_unregister in remove like what is done in probe failure. Add the calls to fix it. Signed-off-by:
Chuhong Yuan <hslester96@gmail.com> Signed-off-by:
-
Philipp Zabel authored
Disable output side crop selections for the decoder. This fixes the following v4l2-compliance complaint: fail: v4l2-test-formats.cpp(1576): IS_DECODER(node) test Cropping: FAIL Signed-off-by:
Philipp Zabel <p.zabel@pengutronix.de> Signed-off-by:
-
Hans Verkuil authored
v4l2_vbi_format, v4l2_sliced_vbi_format and v4l2_sdr_format have a reserved array at the end that should be zeroed by drivers as per the V4L2 spec. Older drivers often do not do this, so just handle this in the core. Signed-off-by:
-
Philipp Zabel authored
Disable capture side compose selections for the encoder. This fixes the following v4l2-compliance complaint: fail: v4l2-test-formats.cpp(1662): IS_ENCODER(node) test Composing: FAIL Signed-off-by:
-
Hirokazu Honda authored
MediaTek encoder allocates non pixel data area for an input buffer every plane. As the input buffer should be read-only, the driver should not write anything in the buffer. Therefore, the extra data should be unnecessary. Signed-off-by:
Hirokazu Honda <hiroh@chromium.org> Reviewed-by:
Tomasz Figa <tfiga@chromium.org> Signed-off-by:
-
Dafna Hirschfeld authored
Userspace can disable links and create pipelines that do not start with a source entity. Trying to stream from such a pipeline should fail with -EPIPE currently this is not handled and cause kernel crash. Reproducing the crash: media-ctl -d0 -l "5:1->21:0[0]" -v v4l2-ctl -z platform:vimc -d "RGB/YUV Capture" -v width=1920,height=1440 v4l2-ctl --stream-mmap --stream-count=100 -d /dev/video2 Panic message: [ 39.078841][ T248] BUG: kernel NULL pointer dereference, address: 0000000000000000 [ 39.079338][ T248] #PF: supervisor read access in kernel mode [ 39.079704][ T248] #PF: error_code(0x0000) - not-present page [ 39.080071][ T248] PGD 0 P4D 0 [ 39.080279][ T248] Oops: 0000 [#1] SMP PTI [ 39.080546][ T248] CPU: 0 PID: 248 Comm: vimc-streamer t Not tainted 5.4.0-rc1+ #17 [ 39.081030][ T248] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.12.0-0-ga698c8995f-prebuilt.qemu.org 04/01/2014 [ 39.081779][ T248] RIP: 0010:vimc_sca_process_frame+0xdb/0x210 [vimc] [ 39.082191][ T248] Code: 44 8d 0c 28 8b 93 a4 01 00 00 48 8b 8b 98 01 00 00 85 d2 74 40 48 8b 74 24 10 8d 7a ff 4c 01 c9 31 d2 4c 01 fe eb 03 4c 89 c2 <44> 0f b6 04 16 44 88 04 11 4c 8d 42 01 48 39 fa 75 eb 8b 93 a4 01 [ 39.083436][ T248] RSP: 0018:ffffb15a005abe90 EFLAGS: 00010246 [ 39.083808][ T248] RAX: 0000000000000000 RBX: ffffa3fdc46d2e00 RCX: ffffb15a02579000 [ 39.084298][ T248] RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000002 [ 39.084792][ T248] RBP: 0000000000000000 R08: 0000000000000000 R09: 0000000000000000 [ 39.085280][ T248] R10: 0000000000000001 R11: 0000000000000000 R12: 0000000000000000 [ 39.085770][ T248] R13: ffffa3fdc46d2ee0 R14: 0000000000000000 R15: 0000000000000000 [ 39.086258][ T248] FS: 0000000000000000(0000) GS:ffffa3fdc7800000(0000) knlGS:0000000000000000 [ 39.086806][ T248] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 39.087217][ T248] CR2: 0000000000000000 CR3: 0000000003c92005 CR4: 0000000000360ef0 [ 39.087706][ T248] Call Trace: [ 39.087909][ T248] ? vimc_streamer_pipeline_terminate+0x90/0x90 [vimc] [ 39.088318][ T248] vimc_streamer_thread+0x7c/0xe0 [vimc] [ 39.088663][ T248] kthread+0x10d/0x130 [ 39.088919][ T248] ? kthread_park+0x80/0x80 [ 39.089205][ T248] ret_from_fork+0x35/0x40 [ 39.089475][ T248] Modules linked in: vimc videobuf2_vmalloc videobuf2_memops v4l2_tpg videobuf2_v4l2 videobuf2_common videodev mc [ 39.090208][ T248] CR2: 0000000000000000 [ 39.090463][ T248] ---[ end trace 697650fefbf78bee ]--- [ 39.090796][ T248] RIP: 0010:vimc_sca_process_frame+0xdb/0x210 [vimc] [ 39.091209][ T248] Code: 44 8d 0c 28 8b 93 a4 01 00 00 48 8b 8b 98 01 00 00 85 d2 74 40 48 8b 74 24 10 8d 7a ff 4c 01 c9 31 d2 4c 01 fe eb 03 4c 89 c2 <44> 0f b6 04 16 44 88 04 11 4c 8d 42 01 48 39 fa 75 eb 8b 93 a4 01 [ 39.092417][ T248] RSP: 0018:ffffb15a005abe90 EFLAGS: 00010246 [ 39.092789][ T248] RAX: 0000000000000000 RBX: ffffa3fdc46d2e00 RCX: ffffb15a02579000 [ 39.093278][ T248] RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000002 [ 39.093766][ T248] RBP: 0000000000000000 R08: 0000000000000000 R09: 0000000000000000 [ 39.094254][ T248] R10: 0000000000000001 R11: 0000000000000000 R12: 0000000000000000 [ 39.094742][ T248] R13: ffffa3fdc46d2ee0 R14: 0000000000000000 R15: 0000000000000000 [ 39.095309][ T248] FS: 0000000000000000(0000) GS:ffffa3fdc7800000(0000) knlGS:0000000000000000 [ 39.095974][ T248] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 39.096372][ T248] CR2: 0000000000000000 CR3: 0000000003c92005 CR4: 0000000000360ef0 Signed-off-by:
Dafna Hirschfeld <dafna.hirschfeld@collabora.com> Acked-by:
Helen Koike <helen.koike@collabora.com> Signed-off-by:
-
Navid Emamdoost authored
In the implementation of aspeed_video_probe() the allocated memory for video should be released if either devm_ioremap_resource() or aspeed_video_init() or aspeed_video_setup_video() fails. Replace kzalloc() with devm_kzalloc to avoid explicit release for video. Fixes: d2b4387f ("media: platform: Add Aspeed Video Engine driver") Signed-off-by:
Navid Emamdoost <navid.emamdoost@gmail.com> Reviewed-by:
Jae Hyun Yoo <jae.hyun.yoo@linux.intel.com> Reviewed-by:
Eddie James <eajames@linux.ibm.com> Signed-off-by:
-
Pragnesh Patel authored
$id doesn't match the actual filename, so update the $id Signed-off-by:
Pragnesh Patel <pragnesh.patel@sifive.com> Acked-by:
Maxime Ripard <mripard@kernel.org> Acked-by:
Rob Herring <robh@kernel.org> Signed-off-by:
-
zhong jiang authored
It's more clear to use FIELD_SIZEOF instead of its implementation. Signed-off-by:
zhong jiang <zhongjiang@huawei.com> Acked-by:
Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by:
-
Simon Horman authored
Remove the SH Mobile CEU bindings documentation as the corresponding driver was removed v5.1 by the following commit: 43a445f1 ("media: sh_mobile_ceu_camera: remove obsolete soc_camera driver") Signed-off-by:
Simon Horman <horms+renesas@verge.net.au> Acked-by:
Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by:
-
- 09 Nov, 2019 19 commits
-
-
Clément Péron authored
Beelink GS1 ships with a NEC remote control. Add the rc keymap to the device-tree. Signed-off-by:
Clément Péron <peron.clem@gmail.com> Signed-off-by:
Sean Young <sean@mess.org> Signed-off-by:
-
Clément Péron authored
Beelink GS1 Andoid TV Box ships with a simple NEC remote. Signed-off-by:
-
Jan Pieter van Woerkom authored
remove unused code Signed-off-by:
Jan Pieter van Woerkom <jp@jpvw.nl> Signed-off-by:
-
Colin Ian King authored
An earlier commit hard coded a return 0 to function flexcop_usb_i2c_req even though the an -EIO was intended to be returned in the case where ret != buflen. Fix this by replacing the return 0 with the return of ret to return the error return code. Addresses-Coverity: ("Unused value") Fixes: b430eaba ("[media] flexcop-usb: don't use stack for DMA") Signed-off-by:Colin Ian King <colin.king@canonical.com> Signed-off-by:
-
Oliver Neukum authored
The driver needs an isochronous endpoint to be present. It will oops in its absence. Add checking for it. Reported-by: syzbot+d93dff37e6a89431c158@syzkaller.appspotmail.com Signed-off-by:
Oliver Neukum <oneukum@suse.com> Signed-off-by:
-
Philipp Zabel authored
The irqlock spinlock has been unused from the start. Remove it. Signed-off-by:
-
Mike Isely authored
In some device configurations there's no radio or radio support in the driver. That's OK, as the driver sets itself up accordingly. However on tear-down in these caes it's still trying to tear down radio related context when there isn't anything there, leading to dereferences through a null pointer and chaos follows. How this bug survived unfixed for 11 years in the pvrusb2 driver is a mystery to me. [hverkuil: fix two checkpatch warnings] Signed-off-by:
Mike Isely <isely@pobox.com> Signed-off-by:
-
Neil Armstrong authored
Update the path to the ao-cec bindings after conversion to DT Schemas. Suggested-by:
Neil Armstrong <narmstrong@baylibre.com> Signed-off-by:
-
Arnd Bergmann authored
v4l2_compat_ioctl32() is the function that calls into v4l2_file_operations->compat_ioctl32(), so setting that back to the same function leads to a trivial endless loop, followed by a kernel stack overrun. Remove the incorrect assignment. Cc: stable@vger.kernel.org Fixes: 7472c1c6 ("[media] media: venus: vdec: add video decoder files") Fixes: aaaa93ed ("[media] media: venus: venc: add video encoder files") Signed-off-by:
Arnd Bergmann <arnd@arndb.de> Acked-by:
Stanimir Varbanov <stanimir.varbanov@linaro.org> Signed-off-by:
-
Jernej Skrabec authored
Hold buf flag is set on output queue, not capture. Fix that. Fixes: f07602ac ("media: v4l2-mem2mem: add new_frame detection") Signed-off-by:
-
Dafna Hirschfeld authored
The field kthread_sen in the vimc_sen_device is not set and used. So remove the field and the code that check if it is non NULL Signed-off-by:
-
Francois Buergisser authored
The picture order count table only makes sense for profiles higher than Baseline. This is confirmed by the H.264 specification (See 8.2.1 Decoding process for picture order count), which clarifies how POC are used for features not present in Baseline. """ Picture order counts are used to determine initial picture orderings for reference pictures in the decoding of B slices, to represent picture order differences between frames or fields for motion vector derivation in temporal direct mode, for implicit mode weighted prediction in B slices, and for decoder conformance checking. """ As a side note, this change matches various vendors downstream codebases, including ChromiumOS and IMX VPU libraries. Fixes: dea0a82f ("media: hantro: Add support for H264 decoding on G1") Signed-off-by:
Francois Buergisser <fbuergisser@chromium.org> Signed-off-by:
Ezequiel Garcia <ezequiel@collabora.com> Signed-off-by:
Jonas Karlman <jonas@kwiboo.se> Reviewed-by:
Boris Brezillon <boris.brezillon@collabora.com> Tested-by:
-
Francois Buergisser authored
The setting of the motion vectors usage and the setting of motion vectors address are currently done under different conditions. When decoding pre-recorded videos, this results of leaving the motion vectors address unset, resulting in faulty memory accesses. Fix it by using the same condition everywhere, which matches the profiles that support motion vectors. Fixes: dea0a82f ("media: hantro: Add support for H264 decoding on G1") Signed-off-by:
-
Jonas Karlman authored
TRM specify supported image size 48x48 to 4096x2304 at step size 16 pixels, change frmsize max_width/max_height to match TRM at [1]. This patch makes it possible to decode the 4096x2304 sample at [2]. [1] http://www.t-firefly.com/download/firefly-rk3288/docs/TRM/rk3288-chapter-25-video-encoder-decoder-unit-(vcodec).pdf [2] https://4ksamples.com/puppies-bath-in-4k/ Fixes: 76032793 ("media: hantro: Enable H264 decoding on rk3288") Signed-off-by:
-
Jonas Karlman authored
Scaling list supplied from userspace should be in matrix order and can be used without applying the inverse scanning process. The HW also only support 8x8 scaling list for the Y component, indices 0 and 1 in the scaling list supplied from userspace. Remove reordering and write the scaling matrix in an order expected by the VPU, also only allocate memory for the two 8x8 lists supported. Fixes: a9471e25 ("media: hantro: Add core bits to support H264 decoding") Signed-off-by:
-
Jonas Karlman authored
Documentation now defines the expected order of scaling lists, change to use correct indices. Fixes: 6eb9b758 ("media: cedrus: Add H264 decoding support") Signed-off-by:
-
Jonas Karlman authored
Clarify that the expected order of scaling lists should follow the order they are listed in the H264 standard. The expected scaling list order, for 4x4: Intra Y, Intra Cb, Intra Cr, Inter Y, Inter Cb, Inter Cr, for 8x8: Intra Y, Inter Y, Intra Cb, Inter Cb, Intra Cr, Inter Cr. Also clarify that the values in a scaling list should be in matrix order, the same value order that vaapi, vdpau and nvdec use. Signed-off-by:
-
Jernej Skrabec authored
Accessing capture queue structue directly is not safe. Use helpers for that. Acked-by:
-
Jernej Skrabec authored
It seems that for some H264 videos at least one bitstream parsing trigger must be called in order to be decoded correctly. There is no explanation why this helps, but it was observed that two sample videos with this fix are now decoded correctly and there is no regression with others. Acked-by:
-
- 08 Nov, 2019 6 commits
-
-
Hans Verkuil authored
Fix typo: putss -> puts Signed-off-by:
-
Ricardo Ribalda Delgado authored
After adding a const pointer to ctrl_ptr, lets use it where it make sense. Suggested-by:
Ricardo Ribalda Delgado <ribalda@kernel.org> Signed-off-by:
-
Ricardo Ribalda Delgado authored
Describe p_area field from v4l2_ext_ctrl Signed-off-by:
-
Ricardo Ribalda Delgado authored
Allow accessing V4L2_CTRL_TYPE_AREA controls without any casting. Signed-off-by:
-
Ricardo Ribalda Delgado authored
This control represents a generic read/write area. Suggested-by:
-
Ricardo Ribalda Delgado authored
This pointer is used to point to data that is constant. Thanks to this we can avoid a lot of casting and we make more clear when the data is constant or variable. Suggested-by:
-
