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

media: qcom: camss: csiphy-3ph: Add CSIPHY 2ph DPHY v2.0.1 init sequence

2025-11-13T20:37:17Z

[ Upstream commit ce63fbdf849f52584d9b5d9a4cc23cbc88746c30 ] This is the CSI PHY version found in QCS2290/QCM2290 SoCs. The table is extracted from downstream camera driver. Signed-off-by: Loic Poulain Reviewed-by: Bryan O'Donoghue Signed-off-by: Bryan O'Donoghue Signed-off-by: Hans Verkuil Signed-off-by: Sasha Levin

media: verisilicon: Explicitly disable selection api ioctls for decoders

2025-11-13T20:37:13Z

[ Upstream commit 73d50aa92f28ee8414fbfde011974fce970b82cc ] Call the dedicated v4l2_disable_ioctl helper instead of manually checking whether the current context is an encoder for the selection api ioctls. Signed-off-by: Paul Kocialkowski Reviewed-by: Nicolas Dufresne Signed-off-by: Nicolas Dufresne Signed-off-by: Hans Verkuil Signed-off-by: Sasha Levin

media: nxp: imx8-isi: Fix streaming cleanup on release

2025-11-13T20:37:10Z

[ Upstream commit 47773031a148ad7973b809cc7723cba77eda2b42 ] The current implementation unconditionally calls mxc_isi_video_cleanup_streaming() in mxc_isi_video_release(). This can lead to situations where any release call (like from a simple "v4l2-ctl -l") may release a currently streaming queue when called on such a device. This is reproducible on an i.MX8MP board by streaming from an ISI capture device using gstreamer: gst-launch-1.0 -v v4l2src device=/dev/videoX ! \ video/x-raw,format=GRAY8,width=1280,height=800,framerate=1/120 ! \ fakesink While this stream is running, querying the caps of the same device provokes the error state: v4l2-ctl -l -d /dev/videoX This results in the following trace: [ 155.452152] ------------[ cut here ]------------ [ 155.452163] WARNING: CPU: 0 PID: 1708 at drivers/media/platform/nxp/imx8-isi/imx8-isi-pipe.c:713 mxc_isi_pipe_irq_handler+0x19c/0x1b0 [imx8_isi] [ 157.004248] Modules linked in: cfg80211 rpmsg_ctrl rpmsg_char rpmsg_tty virtio_rpmsg_bus rpmsg_ns rpmsg_core rfkill nft_ct nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 nf_tables mcp251x6 [ 157.053499] CPU: 0 UID: 0 PID: 1708 Comm: python3 Not tainted 6.15.4-00114-g1f61ca5cad76 #1 PREEMPT [ 157.064369] Hardware name: imx8mp_board_01 (DT) [ 157.068205] pstate: 400000c5 (nZcv daIF -PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 157.075169] pc : mxc_isi_pipe_irq_handler+0x19c/0x1b0 [imx8_isi] [ 157.081195] lr : mxc_isi_pipe_irq_handler+0x38/0x1b0 [imx8_isi] [ 157.087126] sp : ffff800080003ee0 [ 157.090438] x29: ffff800080003ee0 x28: ffff0000c3688000 x27: 0000000000000000 [ 157.097580] x26: 0000000000000000 x25: ffff0000c1e7ac00 x24: ffff800081b5ad50 [ 157.104723] x23: 00000000000000d1 x22: 0000000000000000 x21: ffff0000c25e4000 [ 157.111866] x20: 0000000060000200 x19: ffff80007a0608d0 x18: 0000000000000000 [ 157.119008] x17: ffff80006a4e3000 x16: ffff800080000000 x15: 0000000000000000 [ 157.126146] x14: 0000000000000000 x13: 0000000000000000 x12: 0000000000000000 [ 157.133287] x11: 0000000000000040 x10: ffff0000c01445f0 x9 : ffff80007a053a38 [ 157.140425] x8 : ffff0000c04004b8 x7 : 0000000000000000 x6 : 0000000000000000 [ 157.147567] x5 : ffff0000c0400490 x4 : ffff80006a4e3000 x3 : ffff0000c25e4000 [ 157.154706] x2 : 0000000000000000 x1 : ffff8000825c0014 x0 : 0000000060000200 [ 157.161850] Call trace: [ 157.164296] mxc_isi_pipe_irq_handler+0x19c/0x1b0 [imx8_isi] (P) [ 157.170319] __handle_irq_event_percpu+0x58/0x218 [ 157.175029] handle_irq_event+0x54/0xb8 [ 157.178867] handle_fasteoi_irq+0xac/0x248 [ 157.182968] handle_irq_desc+0x48/0x68 [ 157.186723] generic_handle_domain_irq+0x24/0x38 [ 157.191346] gic_handle_irq+0x54/0x120 [ 157.195098] call_on_irq_stack+0x24/0x30 [ 157.199027] do_interrupt_handler+0x88/0x98 [ 157.203212] el0_interrupt+0x44/0xc0 [ 157.206792] __el0_irq_handler_common+0x18/0x28 [ 157.211328] el0t_64_irq_handler+0x10/0x20 [ 157.215429] el0t_64_irq+0x198/0x1a0 [ 157.219009] ---[ end trace 0000000000000000 ]--- Address this issue by moving the streaming preparation and cleanup to the vb2 .prepare_streaming() and .unprepare_streaming() operations. This also simplifies the driver by allowing direct usage of the vb2_ioctl_streamon() and vb2_ioctl_streamoff() helpers, and removal of the manual cleanup from mxc_isi_video_release(). Link: https://lore.kernel.org/r/20250813212451.22140-2-laurent.pinchart@ideasonboard.com Signed-off-by: Richard Leitner Co-developed-by: Laurent Pinchart Signed-off-by: Laurent Pinchart Tested-by: Richard Leitner # i.MX8MP Signed-off-by: Hans Verkuil Signed-off-by: Sasha Levin

media: imx-mipi-csis: Only set clock rate when specified in DT

2025-11-13T20:37:10Z

[ Upstream commit 65673c6e33cf46f220cc5774166b373b3c087739 ] The imx-mipi-csis driver sets the rate of the wrap clock to the value specified in the device tree's "clock-frequency" property, and defaults to 166 MHz otherwise. This is a historical mistake, as clock rate selection should have been left to the assigned-clock-rates property. Honouring the clock-frequency property can't be removed without breaking backwards compatibility, and the corresponding code isn't very intrusive. The 166 MHz default, on the other hand, prevents configuration of the clock rate through assigned-clock-rates, as the driver immediately overwrites the rate. This behaviour is confusing and has cost debugging time. There is little value in a 166 MHz default. All mainline device tree sources that enable the CSIS specify a clock-frequency explicitly, and the default wrap clock configuration on supported platforms is at least as high as 166 MHz. Drop the default, and only set the clock rate manually when the clock-frequency property is specified. Link: https://lore.kernel.org/r/20250822002734.23516-10-laurent.pinchart@ideasonboard.com Signed-off-by: Laurent Pinchart Reviewed-by: Frank Li Signed-off-by: Hans Verkuil Signed-off-by: Sasha Levin

media: amphion: Delete v4l2_fh synchronously in .release()

2025-11-13T20:36:59Z

[ Upstream commit 19fb9c5b815f70eb90d5b545f65b83bc9c490ecd ] The v4l2_fh initialized and added in vpu_v4l2_open() is delete and cleaned up when the last reference to the vpu_inst is released. This may happen later than at vpu_v4l2_close() time. Not deleting and cleaning up the v4l2_fh when closing the file handle to the video device is not ideal, as the v4l2_fh will still be present in the video device's fh_list, and will store a copy of events queued to the video device. There may also be other side effects of keeping alive an object that represents an open file handle after the file handle is closed. The v4l2_fh instance is embedded in the vpu_inst structure, and is accessed in two different ways: - in vpu_notify_eos() and vpu_notify_source_change(), to queue V4L2 events to the file handle ; and - through the driver to access the v4l2_fh.m2m_ctx pointer. The v4l2_fh.m2m_ctx pointer is not touched by v4l2_fh_del() and v4l2_fh_exit(). It is set to NULL by the driver when closing the file handle, in vpu_v4l2_close(). The vpu_notify_eos() and vpu_notify_source_change() functions are called in vpu_set_last_buffer_dequeued() and vdec_handle_resolution_change() respectively, only if the v4l2_fh.m2m_ctx pointer is not NULL. There is therefore a guarantee that no new event will be queued to the v4l2_fh after vpu_v4l2_close() destroys the m2m_ctx. The vpu_notify_eos() function is also called from vpu_vb2_buf_finish(), which is guaranteed to be called for all queued buffers when vpu_v4l2_close() calls v4l2_m2m_ctx_release(), and will not be called later. It is therefore safe to assume that the driver will not touch the v4l2_fh, except to check the m2m_ctx pointer, after vpu_v4l2_close() destroys the m2m_ctx. We can safely delete and cleanup the v4l2_fh synchronously in vpu_v4l2_close(). Signed-off-by: Laurent Pinchart Reviewed-by: Ming Qian Signed-off-by: Hans Verkuil Signed-off-by: Sasha Levin

media: nxp: imx8-isi: m2m: Fix streaming cleanup on release

2025-10-23T14:24:26Z

[ Upstream commit 178aa3360220231dd91e7dbc2eb984525886c9c1 ] If streamon/streamoff calls are imbalanced, such as when exiting an application with Ctrl+C when streaming, the m2m usage_count will never reach zero and the ISI channel won't be freed. Besides from that, if the input line width is more than 2K, it will trigger a WARN_ON(): [ 59.222120] ------------[ cut here ]------------ [ 59.226758] WARNING: drivers/media/platform/nxp/imx8-isi/imx8-isi-hw.c:631 at mxc_isi_channel_chain+0xa4/0x120, CPU#4: v4l2-ctl/654 [ 59.238569] Modules linked in: ap1302 [ 59.242231] CPU: 4 UID: 0 PID: 654 Comm: v4l2-ctl Not tainted 6.16.0-rc4-next-20250704-06511-gff0e002d480a-dirty #258 PREEMPT [ 59.253597] Hardware name: NXP i.MX95 15X15 board (DT) [ 59.258720] pstate: 80400009 (Nzcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 59.265669] pc : mxc_isi_channel_chain+0xa4/0x120 [ 59.270358] lr : mxc_isi_channel_chain+0x44/0x120 [ 59.275047] sp : ffff8000848c3b40 [ 59.278348] x29: ffff8000848c3b40 x28: ffff0000859b4c98 x27: ffff800081939f00 [ 59.285472] x26: 000000000000000a x25: ffff0000859b4cb8 x24: 0000000000000001 [ 59.292597] x23: ffff0000816f4760 x22: ffff0000816f4258 x21: ffff000084ceb780 [ 59.299720] x20: ffff000084342ff8 x19: ffff000084340000 x18: 0000000000000000 [ 59.306845] x17: 0000000000000000 x16: 0000000000000000 x15: 0000ffffdb369e1c [ 59.313969] x14: 0000000000000000 x13: 0000000000000000 x12: 0000000000000000 [ 59.321093] x11: 0000000000000000 x10: 0000000000000000 x9 : 0000000000000000 [ 59.328217] x8 : ffff8000848c3d48 x7 : ffff800081930b30 x6 : ffff800081930b30 [ 59.335340] x5 : ffff0000859b6000 x4 : ffff80008193ae80 x3 : ffff800081022420 [ 59.342464] x2 : ffff0000852f6900 x1 : 0000000000000001 x0 : ffff000084341000 [ 59.349590] Call trace: [ 59.352025] mxc_isi_channel_chain+0xa4/0x120 (P) [ 59.356722] mxc_isi_m2m_streamon+0x160/0x20c [ 59.361072] v4l_streamon+0x24/0x30 [ 59.364556] __video_do_ioctl+0x40c/0x4a0 [ 59.368560] video_usercopy+0x2bc/0x690 [ 59.372382] video_ioctl2+0x18/0x24 [ 59.375857] v4l2_ioctl+0x40/0x60 [ 59.379168] __arm64_sys_ioctl+0xac/0x104 [ 59.383172] invoke_syscall+0x48/0x104 [ 59.386916] el0_svc_common.constprop.0+0xc0/0xe0 [ 59.391613] do_el0_svc+0x1c/0x28 [ 59.394915] el0_svc+0x34/0xf4 [ 59.397966] el0t_64_sync_handler+0xa0/0xe4 [ 59.402143] el0t_64_sync+0x198/0x19c [ 59.405801] ---[ end trace 0000000000000000 ]--- Address this issue by moving the streaming preparation and cleanup to the vb2 .prepare_streaming() and .unprepare_streaming() operations. This also simplifies the driver by allowing direct usage of the v4l2_m2m_ioctl_streamon() and v4l2_m2m_ioctl_streamoff() helpers. Fixes: cf21f328fcaf ("media: nxp: Add i.MX8 ISI driver") Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/20250821135123.29462-1-laurent.pinchart@ideasonboard.com Signed-off-by: Guoniu Zhou Co-developed-by: Laurent Pinchart Signed-off-by: Laurent Pinchart Tested-by: Guoniu Zhou Reviewed-by: Frank Li Signed-off-by: Hans Verkuil [ added bypass parameter to mxc_isi_channel_chain() call ] Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman

media: iris: Allow stop on firmware only if start was issued.

2025-10-19T14:37:40Z

commit 56a2d85ee8f9b994e5cd17039133218c57c5902b upstream. For HFI Gen1, the instances substate is changed to LOAD_RESOURCES only when a START command is issues to the firmware. If STOP is called without a prior START, the firmware may reject the command and throw some erros. Handle this by adding a substate check before issuing STOP command to the firmware. Fixes: 11712ce70f8e ("media: iris: implement vb2 streaming ops") Cc: stable@vger.kernel.org Reviewed-by: Vikash Garodia Tested-by: Vikash Garodia # X1E80100 Tested-by: Neil Armstrong # on SM8550-HDK Tested-by: Neil Armstrong # on SM8650-HDK Signed-off-by: Dikshita Agarwal Tested-by: Bryan O'Donoghue # x1e80100-crd Signed-off-by: Bryan O'Donoghue Signed-off-by: Hans Verkuil Signed-off-by: Greg Kroah-Hartman

media: iris: Fix format check for CAPTURE plane in try_fmt

2025-10-19T14:37:40Z

commit 2dbd2645c07df8de04ee37b24f2395800513391e upstream. Previously, the format validation relied on an array of supported formats, which only listed formats for the OUTPUT plane. This caused failures when validating formats for the CAPTURE plane. Update the check to validate against the only supported format on the CAPTURE plane, which is NV12. Fixes: fde6161d91bb ("media: iris: Add HEVC and VP9 formats for decoder") Cc: stable@vger.kernel.org Reviewed-by: Vikash Garodia Tested-by: Vikash Garodia # X1E80100 Tested-by: Neil Armstrong # on SM8550-HDK Tested-by: Neil Armstrong # on SM8650-HDK Signed-off-by: Dikshita Agarwal Tested-by: Bryan O'Donoghue # x1e80100-crd Signed-off-by: Bryan O'Donoghue Signed-off-by: Hans Verkuil Signed-off-by: Greg Kroah-Hartman

media: iris: Fix missing LAST flag handling during drain

2025-10-19T14:37:40Z

commit 8172f57746d68e5c3c743f725435d75c5a4db1ac upstream. Improve drain handling by ensuring the LAST flag is attached to final capture buffer when drain response is received from the firmware. Previously, the driver failed to attach the V4L2_BUF_FLAG_LAST flag when a drain response was received from the firmware, relying on userspace to mark the next queued buffer as LAST. This update fixes the issue by checking the pending drain status, attaching the LAST flag to the capture buffer received from the firmware (with EOS attached), and returning it to the V4L2 layer correctly. Fixes: d09100763bed ("media: iris: add support for drain sequence") Cc: stable@vger.kernel.org Reviewed-by: Vikash Garodia Tested-by: Vikash Garodia # X1E80100 Reviewed-by: Bryan O'Donoghue Tested-by: Neil Armstrong # on SM8550-HDK Tested-by: Neil Armstrong # on SM8650-HDK Signed-off-by: Dikshita Agarwal Tested-by: Bryan O'Donoghue # x1e80100-crd Signed-off-by: Bryan O'Donoghue Signed-off-by: Hans Verkuil Signed-off-by: Greg Kroah-Hartman

media: iris: Send dummy buffer address for all codecs during drain

2025-10-19T14:37:40Z

commit dec073dd8452e174a69db8444e0932e6b4f31c99 upstream. Firmware can handle a dummy address for buffers with the EOS flag. To ensure consistent behavior across all codecs, update the drain command to always send a dummy buffer address. This makes the drain handling uniform and avoids any codec specific assumptions. Fixes: 478c4478610d ("media: iris: Add codec specific check for VP9 decoder drain handling") Cc: stable@vger.kernel.org Reviewed-by: Vikash Garodia Tested-by: Vikash Garodia # X1E80100 Reviewed-by: Bryan O'Donoghue Tested-by: Neil Armstrong # on SM8550-HDK Tested-by: Neil Armstrong # on SM8650-HDK Signed-off-by: Dikshita Agarwal Tested-by: Bryan O'Donoghue # x1e80100-crd Signed-off-by: Bryan O'Donoghue Signed-off-by: Hans Verkuil Signed-off-by: Greg Kroah-Hartman