- 24 Oct, 2019 11 commits
-
-
Paul Kocialkowski authored
This introduces the required definitions for HEVC decoding support with stateless VPUs. The controls associated to the HEVC slice format provide the required meta-data for decoding slices extracted from the bitstream. They are not exported to the public V4L2 API since reworking this API will likely be needed for covering various use-cases and new hardware. Multi-slice decoding is exposed as a valid decoding mode to match current H.264 support but it is not yet implemented. The interface comes with the following limitations: * No custom quantization matrices (scaling lists); * Support for a single temporal layer only; * No slice entry point offsets support; * No conformance window support; * No VUI parameters support; * No support for SPS extensions: range, multilayer, 3d, scc, 4 bits; * No support for PPS extensions: range, multilayer, 3d, scc, 4 bits. Signed-off-by:
Paul Kocialkowski <paul.kocialkowski@bootlin.com> [hverkuil-cisco@xs4all.nl: use 1ULL in flags defines in hevc-ctrls.h] Signed-off-by:
Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by:
Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
-
Paul Kocialkowski authored
DIV_ROUND_UP's first argument doesn't need to be wrapped in parenthesis since that is already being taken care of in the macro's definition. Signed-off-by:
-
Paul Kocialkowski authored
We need to shift and mask values at different occasions to fill up cedrus registers. This was done using macros that don't explicitly treat arguments as unsigned, leading to possibly undefined behavior. Introduce the SHIFT_AND_MASK_BITS macro and use it where possible. In cases where it doesn't apply as-is, explicitly cast to unsigned instead. This macro should be moved to include/linux/bits.h eventually. Signed-off-by:
-
Vandana BN authored
Support metadata output in vivid driver. Metadata output is used to set brightness, contrast, saturation and hue. Adds new files for metadata output. Signed-off-by:
Vandana BN <bnvandana@gmail.com> Signed-off-by:
-
Vandana BN authored
Add new metadata format to support metadata output in vivid. Signed-off-by:
-
Vandana BN authored
Adds new file for describing new metadata format V4L2_META_FMT_VIVID added in vivid driver. Signed-off-by:
-
Vandana BN authored
This patch adds meatadata capture support in vivid driver. Adds new files for metadata capture. Adds vivid controls to generate PTS and SCR for metadata stream. also fixes v4l2-compliance issues seen on metadata device. Signed-off-by:
-
Hans Verkuil authored
Touch devices have obviously no tuner, so don't attempt to enable those ioctls for such devices. Signed-off-by:
Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by:
-
Hans Verkuil authored
Touch devices mark too many ioctls as valid. Restrict the list of valid ioctls for touch devices. Signed-off-by:
-
Hans Verkuil authored
In determine_valid_ioctls() we can use SET_VALID_IOCTL to enable ioctls for SDR, simplifying the code. Signed-off-by:
-
Vandana BN authored
If the type is VFL_TYPE_GRABBER, then also check device_caps to see if the video device supports video and/or metadata and disable unneeded ioctls. Without this change, format ioctls for both video and metadata devices could be called on both device nodes. This is true for other ioctls as well, even if the device supports only video or metadata. Metadata devices act similar to VBI devices w.r.t. which ioctls should be enabled. This makes sense since VBI *is* metadata. Signed-off-by:
-
- 21 Oct, 2019 7 commits
-
-
Alexandre Courbot authored
Documents the protocol that user-space should follow when communicating with stateless video decoders. The stateless video decoding API makes use of the new request and tags APIs. While it has been implemented with the Cedrus driver so far, it should probably still be considered staging for a short while. Signed-off-by:
Alexandre Courbot <acourbot@chromium.org> Signed-off-by:
-
Jernej Skrabec authored
With recent changes, support for decoding multi-slice frames can be easily added now. Signal VPU if current slice is first in frame or not and add information about first macroblock coordinates. When frame contains multiple slices and driver works in slice mode, it's more efficient to hold capture buffer in queue until all slices of a same frame are decoded. Add support for that to Cedrus driver by exposing and implementing V4L2_BUF_CAP_SUPPORTS_M2M_HOLD_CAPTURE_BUF capability. Signed-off-by:
Jernej Skrabec <jernej.skrabec@siol.net> [hverkuil-cisco@xs4all.nl: rewritten to use v4l2_m2m_buf_done_and_job_finish] [hverkuil-cisco@xs4all.nl: removed unnecessary (u32) cast] [hverkuil-cisco@xs4all.nl: use new_frame v4l2_m2m_ctx bool] Signed-off-by:
-
Hans Verkuil authored
Drivers that support VB2_V4L2_FL_SUPPORTS_M2M_HOLD_CAPTURE_BUF typically want to know if a new frame is started (i.e. the first slice is about to be processed). Add a new_frame bool to v4l2_m2m_ctx and set it accordingly. Signed-off-by:
-
Jernej Skrabec authored
These helpers are used by stateless codecs when they support multiple slices per frame and hold capture buffer flag is set. It's expected that all such codecs will use this code. Signed-off-by:
-
Hans Verkuil authored
Add this new V4L2_DEC_CMD_FLUSH decoder command and document it. Reviewed-by:
Boris Brezillon <boris.brezillon@collabora.com> Reviewed-by:
-
Hans Verkuil authored
Check for held buffers that are ready to be returned to vb2 in __v4l2_m2m_try_queue(). This avoids drivers having to handle this case. Add v4l2_m2m_buf_done_and_job_finish() to correctly return source and destination buffers and mark the job as finished while taking a held destination buffer into account (i.e. that buffer won't be returned). This has to be done while job_spinlock is held to avoid race conditions. Signed-off-by:
-
Hans Verkuil authored
This patch adds support for the V4L2_BUF_FLAG_M2M_HOLD_CAPTURE_BUF flag. It also adds a new V4L2_BUF_CAP_SUPPORTS_M2M_HOLD_CAPTURE_BUF capability. Drivers should set vb2_queue->subsystem_flags to VB2_V4L2_FL_SUPPORTS_M2M_HOLD_CAPTURE_BUF to indicate support for this flag. Signed-off-by:
-
- 16 Oct, 2019 13 commits
-
-
Hariprasad Kelam authored
Fix below issue reported by coccicheck drivers/staging//media/omap4iss/iss.c:915:1-15: WARNING: Use devm_platform_ioremap_resource for iss -> regs [ res ] Signed-off-by:
Hariprasad Kelam <hariprasad.kelam@gmail.com> Signed-off-by:
-
Nachammai Karuppiah authored
This patch modifies NULL comparison to fix checkpatch.pl warning. Signed-off-by:
Nachammai Karuppiah <nachukannan@gmail.com> Acked-by:
Julia Lawall <julia.lawall@lip6.fr> Signed-off-by:
-
Christophe JAILLET authored
It is likely that it should be UVC_METADATA_BUF_SIZE instead. Fix it and use it. Signed-off-by:
Christophe JAILLET <christophe.jaillet@wanadoo.fr> Signed-off-by:
-
Laurent Pinchart authored
When parsing the UVC control descriptors fails, the error path tries to cleanup a media device that hasn't been initialised, potentially resulting in a crash. Fix this by initialising the media device before the error handling path can be reached. Fixes: 5a254d75 ("[media] uvcvideo: Register a v4l2_device") Reported-by: syzbot+c86454eb3af9e8a4da20@syzkaller.appspotmail.com Signed-off-by:
-
Mauro Carvalho Chehab authored
I2C ops are expensive, as the I2C bus typical speed is 100kbps. Also, stats reading take some time, as it requires to retrieve a certain number of packets to complete. While we don't know the minimal for CXD2841er, trying to do it too quickly is still a very bad idea. So, add some sanity logic there, preventing to retrieve stats faster than one second. This shouldn't cause any issues with well behavior apps, as they usually take stats on a polling rate slower than 1 second. Signed-off-by:
Sean Young <sean@mess.org>
-
Mauro Carvalho Chehab authored
While 99% of the implementation of the bitrate estimation routine for ISDB-T is generic, the current approach mangles it with some mb86a20s-specific thing. Split the calculus from the specific stuff, in order to make easier to use the same approach on other drivers requiring a similar formula. Signed-off-by:
-
Vito Caputo authored
Don't use uninitialized ircode[] in cxusb_rc_query() when cxusb_ctrl_msg() fails to populate its contents. syzbot reported: dvb-usb: bulk message failed: -22 (1/-30591) ===================================================== BUG: KMSAN: uninit-value in ir_lookup_by_scancode drivers/media/rc/rc-main.c:494 [inline] BUG: KMSAN: uninit-value in rc_g_keycode_from_table drivers/media/rc/rc-main.c:582 [inline] BUG: KMSAN: uninit-value in rc_keydown+0x1a6/0x6f0 drivers/media/rc/rc-main.c:816 CPU: 1 PID: 11436 Comm: kworker/1:2 Not tainted 5.3.0-rc7+ #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 Workqueue: events dvb_usb_read_remote_control Call Trace: __dump_stack lib/dump_stack.c:77 [inline] dump_stack+0x191/0x1f0 lib/dump_stack.c:113 kmsan_report+0x13a/0x2b0 mm/kmsan/kmsan_report.c:108 __msan_warning+0x73/0xe0 mm/kmsan/kmsan_instr.c:250 bsearch+0x1dd/0x250 lib/bsearch.c:41 ir_lookup_by_scancode drivers/media/rc/rc-main.c:494 [inline] rc_g_keycode_from_table drivers/media/rc/rc-main.c:582 [inline] rc_keydown+0x1a6/0x6f0 drivers/media/rc/rc-main.c:816 cxusb_rc_query+0x2e1/0x360 drivers/media/usb/dvb-usb/cxusb.c:548 dvb_usb_read_remote_control+0xf9/0x290 drivers/media/usb/dvb-usb/dvb-usb-remote.c:261 process_one_work+0x1572/0x1ef0 kernel/workqueue.c:2269 worker_thread+0x111b/0x2460 kernel/workqueue.c:2415 kthread+0x4b5/0x4f0 kernel/kthread.c:256 ret_from_fork+0x35/0x40 arch/x86/entry/entry_64.S:355 Uninit was stored to memory at: kmsan_save_stack_with_flags mm/kmsan/kmsan.c:150 [inline] kmsan_internal_chain_origin+0xd2/0x170 mm/kmsan/kmsan.c:314 __msan_chain_origin+0x6b/0xe0 mm/kmsan/kmsan_instr.c:184 rc_g_keycode_from_table drivers/media/rc/rc-main.c:583 [inline] rc_keydown+0x2c4/0x6f0 drivers/media/rc/rc-main.c:816 cxusb_rc_query+0x2e1/0x360 drivers/media/usb/dvb-usb/cxusb.c:548 dvb_usb_read_remote_control+0xf9/0x290 drivers/media/usb/dvb-usb/dvb-usb-remote.c:261 process_one_work+0x1572/0x1ef0 kernel/workqueue.c:2269 worker_thread+0x111b/0x2460 kernel/workqueue.c:2415 kthread+0x4b5/0x4f0 kernel/kthread.c:256 ret_from_fork+0x35/0x40 arch/x86/entry/entry_64.S:355 Local variable description: ----ircode@cxusb_rc_query Variable was created at: cxusb_rc_query+0x4d/0x360 drivers/media/usb/dvb-usb/cxusb.c:543 dvb_usb_read_remote_control+0xf9/0x290 drivers/media/usb/dvb-usb/dvb-usb-remote.c:261 Signed-off-by:
Vito Caputo <vcaputo@pengaru.com> Reported-by:
syzbot <syzkaller@googlegroups.com> Signed-off-by:
-
Jisheng Zhang authored
Some MACROS such as RC_MAP_SU3000 and RC_MAP_HAUPPAUGE are not alphabetically sorted. Sort names alphabetically. Signed-off-by:
Jisheng Zhang <Jisheng.Zhang@synaptics.com> Signed-off-by:
-
Christian Hewitt authored
Add a keymap for the Tronsmart Vega S95 and S96 Android (Amlogic S905/S912) STB devices. Both use the same IR remote. Signed-off-by:
Christian Hewitt <christianshewitt@gmail.com> Signed-off-by:
-
zhong jiang authored
The kernel.h macro DIV_ROUND_CLOSEST performs the computation (x + d/2)/d but is perhaps more readable. Signed-off-by:
Zhong Jiang <zhongjiang@huawei.com> Signed-off-by:
-
zhong jiang authored
The kernel.h macro DIV_ROUND_CLOSEST performs the computation (x + d/2)/d but is perhaps more readable. Signed-off-by:
-
Sean Young authored
The code for pulse and space is the same so remove duplication. Signed-off-by:
-
Thomas Voegtle authored
Adds USB ID for the eyeTV Geniatech T2 lite to the dvbsky driver. This is a Geniatech T230C based stick without IR and a different USB ID. Signed-off-by:
Thomas Voegtle <tv@lio96.de> Tested-by:
Jan Pieter van Woerkom <jp@jpvw.nl> Signed-off-by:
-
- 10 Oct, 2019 9 commits
-
-
Benoit Parrot authored
Up to now VPE was relying on the colorspace value of struct v4l2_format as an indication to perform color space conversion from YUV to RGB or not. Instead we should used the source/destination fourcc codes as a more reliable indication to perform color space conversion or not. To do so, we rework the csc module to use "struct v4l2_format *" as parameters, and reorganize the coefficients tables in a more logical way. Signed-off-by:
Benoit Parrot <bparrot@ti.com> Signed-off-by:
-
Benoit Parrot authored
Add RGB565 and RGB555 to the v4l2_format_info table. Signed-off-by:
-
Benoit Parrot authored
It is often useful to figure out if a pixel_format is either YUV or RGB especially for driver who can perform the pixel encoding conversion. Instead of having each driver implement its own "is_this_yuv/rgb" function based on a restricted set of pixel value, it is better to do this in centralized manner. We therefore add a pixel_enc member to the v4l2_format_info structure to quickly identify the related pixel encoding. And add helper functions to check pixel encoding. Signed-off-by:
-
Benoit Parrot authored
The RGB to YUV HD full range coefficients did not match the TRM values and appeared to be a cut-n-paste from the YUV to RGB section. Replace the entries with the values from the TRM. Signed-off-by:
-
Benoit Parrot authored
All 4 of the "colorspace" components were not originally handled. Causing issue related to xfer_func not being initialized properly. This was found with v4l2-compliance test. Signed-off-by:
-
Benoit Parrot authored
For each queue we need to maintain resolutions, pixel format, bytesperline, sizeimage, colorspace, etc. Instead of manually adding more entries in the vpe_q_data struct, it is better to just add a "struct v4l2_format" member and use that to store all needed information. Signed-off-by:
-
Benoit Parrot authored
VPE uses VPDMA (built-in dma engine) to transfer data to and from the IP and memory. VPDMA expect 32 bits addresses. To make sure that is always the case set the DMA mask and coherent mask for the device. Signed-off-by:
-
Benoit Parrot authored
Using dma_addr_t as the type to hold address inside of a fix sized descriptor used by the vpdma firmware is prone to fail when the expected width is 32 bits and suddenly when CONFIG_LPAE is enabled the data size is now 64 bits shifted the remaining members of the descriptor in memory which confuses the firmware. Signed-off-by:
-
Benoit Parrot authored
v4l2-compliance fails with this message: fail: v4l2-test-buffers.cpp(691): ret == 0 fail: v4l2-test-buffers.cpp(974): captureBufs(node, q, m2m_q, frame_count, true) test MMAP: FAIL This caused the following Kernel Warning: WARNING: CPU: 0 PID: 961 at drivers/media/v4l2-core/videobuf2-core.c:1658 __vb2_queue_cancel+0x174/0x1d8 ... CPU: 0 PID: 961 Comm: v4l2-compliance Not tainted 4.14.62-01720-g20ecd717e87a #6 Hardware name: Generic DRA72X (Flattened Device Tree) Backtrace: [<c020b5bc>] (dump_backtrace) from [<c020b8a0>] (show_stack+0x18/0x1c) r7:00000009 r6:60070013 r5:00000000 r4:c1053824 [<c020b888>] (show_stack) from [<c09232e8>] (dump_stack+0x90/0xa4) [<c0923258>] (dump_stack) from [<c022b740>] (__warn+0xec/0x104) r7:00000009 r6:c0c0ad50 r5:00000000 r4:00000000 [<c022b654>] (__warn) from [<c022b810>] (warn_slowpath_null+0x28/0x30) r9:00000008 r8:00000000 r7:eced4808 r6:edbc9bac r5:eced4844 r4:eced4808 [<c022b7e8>] (warn_slowpath_null) from [<c0726f48>] (__vb2_queue_cancel+0x174/0x1d8) [<c0726dd4>] (__vb2_queue_cancel) from [<c0727648>] (vb2_core_queue_release+0x20/0x40) r10:ecc7bd70 r9:00000008 r8:00000000 r7:edb73010 r6:edbc9bac r5:eced4844 r4:eced4808 r3:00000004 [<c0727628>] (vb2_core_queue_release) from [<c0729528>] (vb2_queue_release+0x10/0x14) r5:edbc9810 r4:eced4800 [<c0729518>] (vb2_queue_release) from [<c0724d08>] (v4l2_m2m_ctx_release+0x1c/0x30) [<c0724cec>] (v4l2_m2m_ctx_release) from [<bf0e8f28>] (vpe_release+0x74/0xb0 [ti_vpe]) r5:edbc9810 r4:ed67a400 [<bf0e8eb4>] (vpe_release [ti_vpe]) from [<c070fccc>] (v4l2_release+0x3c/0x80) r7:edb73010 r6:ed176aa0 r5:edbc9868 r4:ed5119c0 [<c070fc90>] (v4l2_release) from [<c033cf1c>] (__fput+0x8c/0x1dc) r5:ecc7bd70 r4:ed5119c0 [<c033ce90>] (__fput) from [<c033d0cc>] (____fput+0x10/0x14) r10:00000000 r9:ed5119c0 r8:ece392d0 r7:c1059544 r6:ece38d80 r5:ece392b4 r4:00000000 [<c033d0bc>] (____fput) from [<c0246e00>] (task_work_run+0x98/0xb8) [<c0246d68>] (task_work_run) from [<c022f1d8>] (do_exit+0x170/0xa80) r9:ece351fc r8:00000000 r7:ecde3f58 r6:ffffe000 r5:ece351c0 r4:ece38d80 [<c022f068>] (do_exit) from [<c022fb6c>] (do_group_exit+0x48/0xc4) r7:000000f8 [<c022fb24>] (do_group_exit) from [<c022fc00>] (__wake_up_parent+0x0/0x28) r7:000000f8 r6:b6c6a798 r5:00000001 r4:00000001 [<c022fbe8>] (SyS_exit_group) from [<c0207c80>] (ret_fast_syscall+0x0/0x4c) These warnings are caused by buffers which not properly cleaned up/release during an abort use case. In the abort cases the VPDMA desc buffers would still be mapped and the in-flight VB2 buffers would not be released properly causing a kernel warning from being generated by the videobuf2-core level. Signed-off-by:
Tomi Valkeinen <tomi.valkeinen@ti.com> Signed-off-by:
-
