- 16 Oct, 2019 8 commits
-
-
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:
Mauro Carvalho Chehab <mchehab+samsung@kernel.org> Signed-off-by:
Sean Young <sean@mess.org>
-
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 32 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:
Hans Verkuil <hverkuil-cisco@xs4all.nl> 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:
-
Benoit Parrot authored
v4l2-compliance fails with this message: fail: v4l2-test-buffers.cpp(294): \ (int)g_sequence() < seq.last_seq + 1 fail: v4l2-test-buffers.cpp(740): \ buf.check(m2m_q, last_m2m_seq) fail: v4l2-test-buffers.cpp(974): \ captureBufs(node, q, m2m_q, frame_count, true) test MMAP: FAIL The driver is failing to update the source frame sequence number in the vb2 buffer object. Only the destination frame sequence was being updated. This is only a reporting issue if the user space app actually cares about the frame sequence number. But it is fixed nonetheless. Signed-off-by:
-
Benoit Parrot authored
v4l2-compliance fails with this message: fail: v4l2-test-formats.cpp(463): !pfmt.sizeimage fail: v4l2-test-formats.cpp(736): \ Video Capture Multiplanar is valid, \ but TRY_FMT failed to return a format test VIDIOC_TRY_FMT: FAIL This failure is causd by the driver failing to handle out range 'bytesperline' values from user space applications. VPDMA hardware is limited to 64k line stride (16 bytes aligned, so 65520 bytes). So make sure the provided or calculated 'bytesperline' is smaller than the maximum value. Signed-off-by:
-
Benoit Parrot authored
v4l2-compliance fails with this message: fail: v4l2-test-formats.cpp(672): \ Video Capture Multiplanar: TRY_FMT(G_FMT) != G_FMT fail: v4l2-test-formats.cpp(672): \ Video Output Multiplanar: TRY_FMT(G_FMT) != G_FMT ... test VIDIOC_TRY_FMT: FAIL The default pixel format was setup as pointing to a specific offset in the vpe_formats table assuming it was pointing to the V4L2_PIX_FMT_YUYV entry. This became false after the addition on the NV21 format (see above commid-id) So instead of hard-coding an offset which might change over time we need to use a lookup helper instead so we know the default will always be what we intended. Signed-off-by:
-
Benoit Parrot authored
v4l2-compliance warns with this message: warn: v4l2-test-formats.cpp(717): \ TRY_FMT cannot handle an invalid pixelformat. warn: v4l2-test-formats.cpp(718): \ This may or may not be a problem. For more information see: warn: v4l2-test-formats.cpp(719): \ http://www.mail-archive.com/linux-media@vger.kernel.org/msg56550.html ... test VIDIOC_TRY_FMT: FAIL We need to make sure that the returns a valid pixel format in all instance. Based on the v4l2 framework convention drivers must return a valid pixel format when the requested pixel format is either invalid or not supported. Signed-off-by:
-
Benoit Parrot authored
v4l2-compliance fails with this message: warn: v4l2-test-formats.cpp(717): \ TRY_FMT cannot handle an invalid pixelformat. test VIDIOC_TRY_FMT: FAIL This causes the following kernel panic: Unable to handle kernel paging request at virtual address 56595561 pgd = ecd80e00 *pgd=00000000 Internal error: Oops: 205 [#1] PREEMPT SMP ARM ... CPU: 0 PID: 930 Comm: v4l2-compliance Not tainted \ 4.14.62-01715-gc8cd67f49a19 #1 Hardware name: Generic DRA72X (Flattened Device Tree) task: ece44d80 task.stack: ecc6e000 PC is at __vpe_try_fmt+0x18c/0x2a8 [ti_vpe] LR is at 0x8 Because the driver fails to properly check the 'num_planes' values for proper ranges it ends up accessing out of bound data causing the kernel panic. Since this driver only handle single or dual plane pixel format, make sure the provided value does not exceed 2 planes. Signed-off-by:
-
Ram Prasad authored
VPE's max height supported MAX_H is set to 1184 which is the padded height from VC1 decoder output. In case of 90, 270 degree rotated video processing, input to VPE will be 1080x1920, 720x1280 etc and MAX_H needs to be set correct value. Setting MAX_H to 2048 as worst case height. Signed-off-by:
Ram Prasad <x0038811@ti.com> Signed-off-by:
-
Nikhil Devshatwar authored
In NV21 format, the chroma plane is written to memory such that the U and V components are swapped for NV12. Create a new entry in the VPDMA formats to describe the correct data types used in the data descriptors. Update all checks for NV12 and add NV21 there as well. Add support for V4L2_PIX_FMT_NV21 format for both capture and output streams. Signed-off-by:
Nikhil Devshatwar <nikhil.nd@ti.com> Signed-off-by:
-
Nikhil Devshatwar authored
SEQ_BT indicates the buffer for bottom field needs to be processed before the top field. Simplify the field selection logic to support SEQ_BT as well. Modify the interlace flags to include any of alternate, SEQ_TB, SEQ_BT. Update other format error checking to consider SEQ_BT. Replace SEQ_TB with SEQ_XX wherever applicable. Signed-off-by:
-
Benoit Parrot authored
Instead of saving a pointer to the 'fh' member of struct vpe_ctx to later have to use container_of to retrieve the actual pointer to the context structure, which seems to confuse static code analysis tool anyways, just save the pointer to the actual structure and then retrieve it directly. Signed-off-by:
-
Benoit Parrot authored
A few NULL pointer checks were missing. Add check with appropriate return code. Signed-off-by:
-
Benoit Parrot authored
commit 3dc2046c ("[media] media: ti-vpe: vpe: allow use of user specified stride") and commit da4414ea ("[media] media: ti-vpe: vpdma: add support for user specified stride") resulted in the Motion Vector stride to be the same as the image stride. This caused memory corruption in the output image as mentioned in commit 00db9699 ("[media] media: ti-vpe: vpe: Fix line stride for output motion vector"). Fixes: 3dc2046c ("[media] media: ti-vpe: vpe: allow use of user specified stride") Fixes: da4414ea ("[media] media: ti-vpe: vpdma: add support for user specified stride") Signed-off-by:
-
Benoit Parrot authored
When TI CAL was introduce as another driver under platform/ti-vpe adding a second entry into the ti-vpe directory in the platform Makefile caused issues during parallel build. Signed-off-by:
Jyri Sarha <jsarha@ti.com> Signed-off-by:
-
Ricardo Ribalda Delgado authored
According to the product brief, the unit cell size is 1120 nanometers^2. https://www.sony-semicon.co.jp/products_en/IS/sensor1/img/products/ProductBrief_IMX214_20150428.pdfSigned-off-by:
Ricardo Ribalda Delgado <ribalda@kernel.org> Signed-off-by:
-
Ricardo Ribalda Delgado authored
This helper function simplifies the code by not needing a union v4l2_ctrl_ptr and an assignment every time we need to use a ctrl_ptr. Suggested-by:
-
Ricardo Ribalda Delgado authored
New control to pass to userspace the width/height of a pixel. Which is needed for calibration and lens selection. Reviewed-by:
Philipp Zabel <p.zabel@pengutronix.de> Signed-off-by:
-
Ricardo Ribalda Delgado authored
This control returns the unit cell size in nanometres. The struct provides the width and the height in separated fields to take into consideration asymmetric pixels and/or hardware binning. This control is required for automatic calibration of sensors/cameras. Reviewed-by:
-
Ricardo Ribalda Delgado authored
A struct v4l2_area containing the width and the height of a rectangular area. Reviewed-by:
Jacopo Mondi <jacopo@jmondi.org> Reviewed-by:
-
Ricardo Ribalda Delgado authored
This type contains the width and the height of a rectangular area. Reviewed-by:
-
Ricardo Ribalda Delgado authored
Function for initializing compound controls with a default value. Suggested-by:
-
Ricardo Ribalda Delgado authored
Currently compound controls do not have a simple way of initializing its values. This results in ofuscated code with type_ops init. This patch introduces a new field on the control with the default value for the compound control that can be set with the brand new v4l2_ctrl_new_std_compound function Suggested-by:
-
Markus Elfring authored
Simplify these function implementations by using a known wrapper function. This issue was detected by using the Coccinelle software. Signed-off-by:
Markus Elfring <elfring@users.sourceforge.net> Reviewed-by:
Geert Uytterhoeven <geert+renesas@glider.be> Tested-by:
Niklas Söderlund <niklas.soderlund@ragnatech.se> Signed-off-by:
-
Niklas Söderlund authored
The image size is doubled for NV16 and is calculated as bytesperline * height * 2 to accommodate the split of UV data. When writing the offset to hardware, the width is used instead of bytesperline, fix this. Signed-off-by:
Niklas Söderlund <niklas.soderlund+renesas@ragnatech.se> Reviewed-by:
Kieran Bingham <kieran.bingham+renesas@ideasonboard.com> Signed-off-by:
-
Steve Longerbeam authored
If a subdevice is unregistered and then registered again without the driver being removed and re-probed (which will happen when the media device is removed and re-probed without also removing/re-probing the subdevice), media_device_register_entity() is called with a non-zero entity->num_pads, and then the subdevice's .registered callback calls media_entity_pads_init(). Thus the subdevice's pad objects are added to the media device pad list twice, causing list corruption. One way to fix this would be to create media_entity_pads_destroy(), and call it in the subdevice's .unregistered callback. But calling media_entity_pads_init() in the .registered callbacks was done for legacy reasons and is no longer necessary, so move the call to media_entity_pads_init() into the subdevice's probe functions. This fixes the duplicate pad obejcts in the media device pad list. Signed-off-by:
Steve Longerbeam <slongerbeam@gmail.com> Signed-off-by:
-
