kernel/linux.git/drivers/media/platform/st, branch v7.2-rc2

Replace by more specific (c files)

2026-07-03T05:38:17+00:00

Replace the #include of by the more specific where applicable. For most cases the include can be dropped completely, only a few drivers need one or two headers added. Acked-by: Danilo Krummrich Acked-by: Takashi Sakamoto Acked-by: Bjorn Helgaas Link: https://patch.msgid.link/1a3f2007c5c5dcf555c09a4035ce3ae8ef1b6c49.1782808461.git.u.kleine-koenig@baylibre.com Signed-off-by: Uwe Kleine-König (The Capable Hub)

media: stm32-dcmipp: Return queued buffers on start_streaming() failure

2026-05-12T07:39:02+00:00

The vb2 framework hands buffers to the driver via buf_queue() before calling start_streaming(). If start_streaming() returns an error without first returning those buffers via vb2_buffer_done(), vb2_start_streaming() fires WARN_ON(owned_by_drv_count) and the queued buffers leak. dcmipp_bytecap_start_streaming() returned -EINVAL when the source subdevice could not be resolved from the media graph, before pm_runtime_resume_and_get() and media_pipeline_start() had been called. The remaining error paths already converge on the err_buffer_done label, which calls dcmipp_bytecap_all_buffers_done(..., VB2_BUF_STATE_QUEUED). Jump to that label directly: the intermediate err_pm_put / err_media_pipeline_stop labels are skipped, which is correct because nothing they would undo has happened yet. This mirrors the uvcvideo fix in commit 4cf3b6fd54eb ("media: uvcvideo: Return queued buffers on start_streaming() failure"). Fixes: 28e0f3772296 ("media: stm32-dcmipp: STM32 DCMIPP camera interface driver") Cc: stable@vger.kernel.org Signed-off-by: Valery Borovsky Signed-off-by: Hans Verkuil

media: stm32: dcmi: unregister notifier on probe failure

2026-05-05T14:57:03+00:00

dcmi_graph_init() registers the async notifier before dcmi_probe() toggles the reset line. If reset_control_assert() or reset_control_deassert() fails afterwards, probe returns through err_cleanup and the driver core will not call dcmi_remove(). Unregister the notifier before cleaning it up on that error path, matching the successful remove path and the V4L2 async notifier lifetime rules. Signed-off-by: Myeonghun Pak Signed-off-by: Hans Verkuil Fixes: d079f94c9046 ("media: platform: Switch to v4l2_async_notifier_add_subdev") Cc: stable@vger.kernel.org [hverkuil: added Fixes tag]

media: stm32: dcmi: addition of DMA-MDMA chaining support

2026-03-11T00:05:33+00:00

Add possibility to rely on an additional MDMA channel and chain the DMA and MDMA channels allowing to achieve faster capture. Indeed, on the MP15 platform, the MDMA engine has an higher bandwidth to the DDR than the DMA engine. Relying on that it is possible to capture frames from the DCMI IP into the DDR by using two channels as follow: DCMI -> (DMA) -> SRAM -> (MDMA) -> DDR The DMA is able by himself to trigger a MDMA request hence, once properly configured, the DCMI IP can simply trigger the DMA in order to have the data pushed up to the DDR (via the SRAM and a MDMA channel). This behavior is detailed in the document Documentation/arch/arm/stm32/stm32-dma-mdma-chaining.rst Signed-off-by: Alain Volmat Signed-off-by: Sakari Ailus Signed-off-by: Mauro Carvalho Chehab

media: stm32: dcmi: continuous mode capture in JPEG

2026-03-11T00:05:33+00:00

Overall cleanup done allows to now have the JPEG handling done in the same way as other formats in continuous mode, allowing to achieve a faster framerate in all resolutions. Signed-off-by: Alain Volmat Signed-off-by: Sakari Ailus Signed-off-by: Mauro Carvalho Chehab

media: stm32: dcmi: use dmaengine_terminate_async in irq context

2026-03-11T00:05:33+00:00

Whenever receiving an OVERRUN event or an end of frame, the driver stops currently ongoing DMA transfer since the DCMI stops sending data to dma. Not doing this would lead to having DMA & DCMI no more synchronized in term of expected data to be copied. Since this is done in irq handler context, it is not possible to make any call that would lead to scheduling hence dmaengine_terminate_sync are not possible. Since the dcmi driver is NOT using dma callbacks, it is possible thus to call instead dmaengine_terminate_async (aka without synchronize) and call again right after a new dmaengine_submit to setup again a new transfer. And since this is now a dmaengine_submit_async, there is no need to release the spinlock around calls to the dmaengine_submit_async. Signed-off-by: Alain Volmat Signed-off-by: Sakari Ailus Signed-off-by: Mauro Carvalho Chehab

media: stm32: dcmi: perform all dma handling within irq_thread

2026-03-11T00:05:33+00:00

Move all the type of frame handling within the dcmi_irq_thread handler and do not rely on dma_callback as previously. This simplifies the code by having only a single path for both compressed and uncompressed data while also making the system more reactive since irq_handler have more chances to be called faster than the dma completion callback. Indeed, in case of the dma completion callback, this run as a tasklet created by the dma framework upon getting an interrupt from the dma and run at a lower priority level than other irq handlers. Signed-off-by: Alain Volmat Signed-off-by: Sakari Ailus Signed-off-by: Mauro Carvalho Chehab

media: stm32: dcmi: rework spin_lock calls

2026-03-11T00:05:33+00:00

Rework of the spin_lock calls in preparation of the rework of the data handling of the driver. Keep it straight forward with basically spin_lock protection around everything except dmaengine calls that might sleep (ex: synchronize / terminate) Signed-off-by: Alain Volmat Signed-off-by: Sakari Ailus Signed-off-by: Mauro Carvalho Chehab

media: stm32: dcmi: stop the dma transfer on overrun

2026-03-11T00:05:32+00:00

Ensure to stop the dma transfer whenever receiving a overrun to avoid having a buffer partially filled with a frame and partially with the next frame. Signed-off-by: Alain Volmat Signed-off-by: Sakari Ailus Signed-off-by: Mauro Carvalho Chehab

media: stm32: dcmi: only create dma descriptor once at buf_prepare

2026-03-11T00:05:32+00:00

Perform the dmaengine prep_slave_sg call within buf_prepare and mark the descriptor as reusable in order to avoid having to redo this at every start of the dma. This also allow to remove the mutex used by the driver to protect dma descriptors related piece of codes. Signed-off-by: Alain Volmat Signed-off-by: Sakari Ailus Signed-off-by: Mauro Carvalho Chehab