kernel/drivers/media/platform/qcom, branch linux-5.1.y

media: venus: firmware: fix leaked of_node references

2019-07-26T07:12:25Z

[ Upstream commit 2c41cc0be07b5ee2f1167f41cd8a86fc5b53d82c ] The call to of_parse_phandle returns a node pointer with refcount incremented thus it must be explicitly decremented after the last usage. Detected by coccinelle with the following warnings: drivers/media/platform/qcom/venus/firmware.c:90:2-8: ERROR: missing of_node_put; acquired a node pointer with refcount incremented on line 82, but without a corresponding object release within this function. drivers/media/platform/qcom/venus/firmware.c:94:2-8: ERROR: missing of_node_put; acquired a node pointer with refcount incremented on line 82, but without a corresponding object release within this function. drivers/media/platform/qcom/venus/firmware.c:128:1-7: ERROR: missing of_node_put; acquired a node pointer with refcount incremented on line 82, but without a corresponding object release within this function. Signed-off-by: Wen Yang Acked-by: Stanimir Varbanov Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Sasha Levin

media: platform: fix several typos

2019-03-01T14:35:21Z

Use codespell to fix lots of typos over frontends. Manually verified to avoid false-positives. Reviewed-by: Niklas Söderlund Acked-by: Andrzej Pietrasiewicz Reviewed-by: Benoit Parrot Reviewed-by: Kieran Bingham Reviewed-by: Lad, Prabhakar Acked-by: Philipp Zabel Reviewed-by: Houlong Wei Reviewed-by: Yong Deng Signed-off-by: Mauro Carvalho Chehab

media: venus: helpers: drop setting of timestamp invalid flag

2019-01-25T20:43:55Z

The zero timestamp is really valid so fix that mistake by dropping the code which checks for zero timestamp. Reviewed-by: Alexandre Courbot Tested-by: Alexandre Courbot Signed-off-by: Stanimir Varbanov Signed-off-by: Mauro Carvalho Chehab

media: venus: core: correct frequency table for sdm845

2019-01-25T20:43:24Z

This corrects clock frequency table rates to be in sync with video clock controller frequency table. Reviewed-by: Alexandre Courbot Tested-by: Alexandre Courbot Signed-off-by: Stanimir Varbanov Signed-off-by: Mauro Carvalho Chehab

media: venus: core: correct maximum hardware load for sdm845

2019-01-25T20:42:27Z

This correct maximum hardware load constant in per SoC resources for sdm845 aka Venus v4. Reviewed-by: Alexandre Courbot Tested-by: Alexandre Courbot Signed-off-by: Stanimir Varbanov Signed-off-by: Mauro Carvalho Chehab

media: venus: firmware: check fw size against DT memory region size

2019-01-25T20:41:35Z

By historical reasons we defined firmware memory size to be 6MB even that the firmware size for all supported Venus versions is 5MBs. Correct that by compare the required firmware size returned from mdt loader and the one provided by DT reserved memory region. We proceed further if the required firmware size is smaller than provided by DT memory region. Reviewed-by: Alexandre Courbot Tested-by: Alexandre Courbot Signed-off-by: Stanimir Varbanov Signed-off-by: Mauro Carvalho Chehab

media: venus: core: Set dma maximum segment size

2018-12-07T13:28:10Z

Turning on CONFIG_DMA_API_DEBUG_SG results in the following error: [ 460.308650] ------------[ cut here ]------------ [ 460.313490] qcom-venus aa00000.video-codec: DMA-API: mapping sg segment longer than device claims to support [len=4194304] [max=65536] [ 460.326017] WARNING: CPU: 3 PID: 3555 at src/kernel/dma/debug.c:1301 debug_dma_map_sg+0x174/0x254 [ 460.338888] Modules linked in: venus_dec venus_enc videobuf2_dma_sg videobuf2_memops hci_uart btqca bluetooth venus_core v4l2_mem2mem videobuf2_v4l2 videobuf2_common ath10k_snoc ath10k_core ath lzo lzo_compress zramjoydev [ 460.375811] CPU: 3 PID: 3555 Comm: V4L2DecoderThre Tainted: G W 4.19.1 #82 [ 460.384223] Hardware name: Google Cheza (rev1) (DT) [ 460.389251] pstate: 60400009 (nZCv daif +PAN -UAO) [ 460.394191] pc : debug_dma_map_sg+0x174/0x254 [ 460.398680] lr : debug_dma_map_sg+0x174/0x254 [ 460.403162] sp : ffffff80200c37d0 [ 460.406583] x29: ffffff80200c3830 x28: 0000000000010000 [ 460.412056] x27: 00000000ffffffff x26: ffffffc0f785ea80 [ 460.417532] x25: 0000000000000000 x24: ffffffc0f4ea1290 [ 460.423001] x23: ffffffc09e700300 x22: ffffffc0f4ea1290 [ 460.428470] x21: ffffff8009037000 x20: 0000000000000001 [ 460.433936] x19: ffffff80091b0000 x18: 0000000000000000 [ 460.439411] x17: 0000000000000000 x16: 000000000000f251 [ 460.444885] x15: 0000000000000006 x14: 0720072007200720 [ 460.450354] x13: ffffff800af536e0 x12: 0000000000000000 [ 460.455822] x11: 0000000000000000 x10: 0000000000000000 [ 460.461288] x9 : 537944d9c6c48d00 x8 : 537944d9c6c48d00 [ 460.466758] x7 : 0000000000000000 x6 : ffffffc0f8d98f80 [ 460.472230] x5 : 0000000000000000 x4 : 0000000000000000 [ 460.477703] x3 : 000000000000008a x2 : ffffffc0fdb13948 [ 460.483170] x1 : ffffffc0fdb0b0b0 x0 : 000000000000007a [ 460.488640] Call trace: [ 460.491165] debug_dma_map_sg+0x174/0x254 [ 460.495307] vb2_dma_sg_alloc+0x260/0x2dc [videobuf2_dma_sg] [ 460.501150] __vb2_queue_alloc+0x164/0x374 [videobuf2_common] [ 460.507076] vb2_core_reqbufs+0xfc/0x23c [videobuf2_common] [ 460.512815] vb2_reqbufs+0x44/0x5c [videobuf2_v4l2] [ 460.517853] v4l2_m2m_reqbufs+0x44/0x78 [v4l2_mem2mem] [ 460.523144] v4l2_m2m_ioctl_reqbufs+0x1c/0x28 [v4l2_mem2mem] [ 460.528976] v4l_reqbufs+0x30/0x40 [ 460.532480] __video_do_ioctl+0x36c/0x454 [ 460.536610] video_usercopy+0x25c/0x51c [ 460.540572] video_ioctl2+0x38/0x48 [ 460.544176] v4l2_ioctl+0x60/0x74 [ 460.547602] do_video_ioctl+0x948/0x3520 [ 460.551648] v4l2_compat_ioctl32+0x60/0x98 [ 460.555872] __arm64_compat_sys_ioctl+0x134/0x20c [ 460.560718] el0_svc_common+0x9c/0xe4 [ 460.564498] el0_svc_compat_handler+0x2c/0x38 [ 460.568982] el0_svc_compat+0x8/0x18 [ 460.572672] ---[ end trace ce209b87b2f3af88 ]--- >From above warning one would deduce that the sg segment will overflow the device's capacity. In reality, the hardware can accommodate larger sg segments. So, initialize the max segment size properly to weed out this warning. Based on a similar patch sent by Sean Paul for mdss: https://patchwork.kernel.org/patch/10671457/ Signed-off-by: Vivek Gautam Acked-by: Stanimir Varbanov Signed-off-by: Hans Verkuil Signed-off-by: Mauro Carvalho Chehab

media: venus: Support V4L2 QP parameters in Venus encoder

2018-12-07T13:27:29Z

Support V4L2 QP parameters in Venus encoder: * V4L2_CID_MPEG_VIDEO_H264_I_FRAME_QP * V4L2_CID_MPEG_VIDEO_H264_B_FRAME_QP * V4L2_CID_MPEG_VIDEO_H264_MIN_QP * V4L2_CID_MPEG_VIDEO_H264_MAX_QP Signed-off-by: Kelvin Lawson Acked-by: Stanimir Varbanov Signed-off-by: Hans Verkuil Signed-off-by: Mauro Carvalho Chehab

media: venus: add support for key frame

2018-12-07T13:14:20Z

When client requests for a keyframe, set the property to hardware to generate the sync frame. Signed-off-by: Malathi Gottam Acked-by: Tomasz Figa Acked-by: Stanimir Varbanov Signed-off-by: Hans Verkuil Signed-off-by: Mauro Carvalho Chehab

media: camss: Take in account sensor skip frames

2018-12-03T19:27:17Z

When streaming is starting ask the sensor for its skip frames value. Max supported frame skip is 29 frames, so clip it if it is higher. Signed-off-by: Todor Tomov Signed-off-by: Hans Verkuil Signed-off-by: Mauro Carvalho Chehab