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

media: qcom: camss: Fix ordering of pm_runtime_enable

2024-10-10T10:01:01Z

commit a151766bd3688f6803e706c6433a7c8d3c6a6a94 upstream. pm_runtime_enable() should happen prior to vfe_get() since vfe_get() calls pm_runtime_resume_and_get(). This is a basic race condition that doesn't show up for most users so is not widely reported. If you blacklist qcom-camss in modules.d and then subsequently modprobe the module post-boot it is possible to reliably show this error up. The kernel log for this error looks like this: qcom-camss ac5a000.camss: Failed to power up pipeline: -13 Fixes: 02afa816dbbf ("media: camss: Add basic runtime PM support") Reported-by: Johan Hovold Closes: https://lore.kernel.org/lkml/ZoVNHOTI0PKMNt4_@hovoldconsulting.com/ Tested-by: Johan Hovold Cc: Signed-off-by: Bryan O'Donoghue Reviewed-by: Konrad Dybcio Signed-off-by: Hans Verkuil Signed-off-by: Greg Kroah-Hartman

media: qcom: camss: Remove use_count guard in stop_streaming

2024-10-10T10:01:01Z

commit 25f18cb1b673220b76a86ebef8e7fb79bd303b27 upstream. The use_count check was introduced so that multiple concurrent Raw Data Interfaces RDIs could be driven by different virtual channels VCs on the CSIPHY input driving the video pipeline. This is an invalid use of use_count though as use_count pertains to the number of times a video entity has been opened by user-space not the number of active streams. If use_count and stream-on count don't agree then stop_streaming() will break as is currently the case and has become apparent when using CAMSS with libcamera's released softisp 0.3. The use of use_count like this is a bit hacky and right now breaks regular usage of CAMSS for a single stream case. Stopping qcam results in the splat below, and then it cannot be started again and any attempts to do so fails with -EBUSY. [ 1265.509831] WARNING: CPU: 5 PID: 919 at drivers/media/common/videobuf2/videobuf2-core.c:2183 __vb2_queue_cancel+0x230/0x2c8 [videobuf2_common] ... [ 1265.510630] Call trace: [ 1265.510636] __vb2_queue_cancel+0x230/0x2c8 [videobuf2_common] [ 1265.510648] vb2_core_streamoff+0x24/0xcc [videobuf2_common] [ 1265.510660] vb2_ioctl_streamoff+0x5c/0xa8 [videobuf2_v4l2] [ 1265.510673] v4l_streamoff+0x24/0x30 [videodev] [ 1265.510707] __video_do_ioctl+0x190/0x3f4 [videodev] [ 1265.510732] video_usercopy+0x304/0x8c4 [videodev] [ 1265.510757] video_ioctl2+0x18/0x34 [videodev] [ 1265.510782] v4l2_ioctl+0x40/0x60 [videodev] ... [ 1265.510944] videobuf2_common: driver bug: stop_streaming operation is leaving buffer 0 in active state [ 1265.511175] videobuf2_common: driver bug: stop_streaming operation is leaving buffer 1 in active state [ 1265.511398] videobuf2_common: driver bug: stop_streaming operation is leaving buffer 2 in active st One CAMSS specific way to handle multiple VCs on the same RDI might be: - Reference count each pipeline enable for CSIPHY, CSID, VFE and RDIx. - The video buffers are already associated with msm_vfeN_rdiX so release video buffers when told to do so by stop_streaming. - Only release the power-domains for the CSIPHY, CSID and VFE when their internal refcounts drop. Either way refusing to release video buffers based on use_count is erroneous and should be reverted. The silicon enabling code for selecting VCs is perfectly fine. Its a "known missing feature" that concurrent VCs won't work with CAMSS right now. Initial testing with this code didn't show an error but, SoftISP and "real" usage with Google Hangouts breaks the upstream code pretty quickly, we need to do a partial revert and take another pass at VCs. This commit partially reverts commit 89013969e232 ("media: camss: sm8250: Pipeline starting and stopping for multiple virtual channels") Fixes: 89013969e232 ("media: camss: sm8250: Pipeline starting and stopping for multiple virtual channels") Reported-by: Johan Hovold Closes: https://lore.kernel.org/lkml/ZoVNHOTI0PKMNt4_@hovoldconsulting.com/ Tested-by: Johan Hovold Cc: Signed-off-by: Bryan O'Donoghue Signed-off-by: Hans Verkuil Signed-off-by: Greg Kroah-Hartman

media: venus: fix use after free bug in venus_remove due to race condition

2024-10-10T10:01:01Z

commit c5a85ed88e043474161bbfe54002c89c1cb50ee2 upstream. in venus_probe, core->work is bound with venus_sys_error_handler, which is used to handle error. The code use core->sys_err_done to make sync work. The core->work is started in venus_event_notify. If we call venus_remove, there might be an unfished work. The possible sequence is as follows: CPU0 CPU1 |venus_sys_error_handler venus_remove | hfi_destroy | venus_hfi_destroy | kfree(hdev); | |hfi_reinit |venus_hfi_queues_reinit |//use hdev Fix it by canceling the work in venus_remove. Cc: stable@vger.kernel.org Fixes: af2c3834c8ca ("[media] media: venus: adding core part and helper functions") Signed-off-by: Zheng Wang Signed-off-by: Dikshita Agarwal Signed-off-by: Stanimir Varbanov Signed-off-by: Hans Verkuil Signed-off-by: Greg Kroah-Hartman

media: qcom: camss: Add check for v4l2_fwnode_endpoint_parse

2024-09-12T09:12:53Z

[ Upstream commit 4caf6d93d9f2c11d6441c64e1c549c445fa322ed ] Add check for the return value of v4l2_fwnode_endpoint_parse() and return the error if it fails in order to catch the error. Signed-off-by: Chen Ni Signed-off-by: Hans Verkuil Signed-off-by: Sasha Levin

media: venus: fix use after free in vdec_close

2024-08-03T07:00:33Z

commit a0157b5aa34eb43ec4c5510f9c260bbb03be937e upstream. There appears to be a possible use after free with vdec_close(). The firmware will add buffer release work to the work queue through HFI callbacks as a normal part of decoding. Randomly closing the decoder device from userspace during normal decoding can incur a read after free for inst. Fix it by cancelling the work in vdec_close. Cc: stable@vger.kernel.org Fixes: af2c3834c8ca ("[media] media: venus: adding core part and helper functions") Signed-off-by: Dikshita Agarwal Acked-by: Vikash Garodia Signed-off-by: Stanimir Varbanov Signed-off-by: Hans Verkuil Signed-off-by: Greg Kroah-Hartman

media: venus: flush all buffers in output plane streamoff

2024-08-03T07:00:03Z

[ Upstream commit e750a4b1224142bd8dd057b0d5adf8a5608b7e77 ] For scenarios, when source change is followed by VIDIOC_STREAMOFF on output plane, driver should discard any queued OUTPUT buffers, which are not decoded or dequeued. Flush with HFI_FLUSH_INPUT does not have any actual impact. So, fix it, by invoking HFI_FLUSH_ALL, which will flush all queued buffers. Fixes: 85872f861d4c ("media: venus: Mark last capture buffer") Signed-off-by: Dikshita Agarwal Tested-by: Nathan Hebert Reviewed-by: Bryan O'Donoghue Signed-off-by: Stanimir Varbanov Signed-off-by: Hans Verkuil Signed-off-by: Sasha Levin

media: qcom: camss: vfe-17x: Rename camss-vfe-170 to camss-vfe-17x

2024-04-08T13:46:33Z

vfe-170 and vfe-175 can be supported in the same file with some minimal indirection to differentiate between the silicon versions. sdm845 uses vfe-170, sc8280xp uses vfe-175-200. Lets rename the file to capture its wider scope than vfe-170 only. Acked-by: Konrad Dybcio Signed-off-by: Bryan O'Donoghue Signed-off-by: Hans Verkuil

media: qcom: camss: Add sc8280xp support

2024-04-08T13:46:32Z

Add in functional logic throughout the code to support the sc8280xp. Acked-by: Konrad Dybcio Signed-off-by: Bryan O'Donoghue Signed-off-by: Hans Verkuil

media: qcom: camss: Add sc8280xp resources

2024-04-08T13:46:32Z

This commit describes the hardware layout for the sc8280xp for the following hardware blocks: - 4 x VFE, 4 RDI per VFE - 4 x VFE Lite, 4 RDI per VFE - 4 x CSID - 4 x CSID Lite - 4 x CSI PHY Signed-off-by: Bryan O'Donoghue Acked-by: Konrad Dybcio Signed-off-by: Hans Verkuil

media: qcom: camss: Add CAMSS_SC8280XP enum

2024-04-08T13:46:32Z

Adds a CAMSS SoC identifier for the SC8280XP. Signed-off-by: Bryan O'Donoghue Signed-off-by: Hans Verkuil