linux/drivers/media/platform/st, branch master

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

2026-03-11T00:05:33Z

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:33Z

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:33Z

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:33Z

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:33Z

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:32Z

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:32Z

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

media: stm32: dcmi: perform dmaengine_slave_config at probe

2026-03-11T00:05:32Z

Perform the dma channel configuration at probe time right after the channel allocation since this is fixed for the whole lifetime of the driver. Signed-off-by: Alain Volmat Signed-off-by: Sakari Ailus Signed-off-by: Mauro Carvalho Chehab

media: stm32: dcmi: Switch from __maybe_unused to pm_ptr()

2026-03-11T00:05:32Z

Letting the compiler remove these functions when the kernel is built without CONFIG_PM_SLEEP support is simpler and less heavier for builds than the use of __maybe_unused attributes. Signed-off-by: Alain Volmat Signed-off-by: Sakari Ailus Signed-off-by: Mauro Carvalho Chehab

Convert 'alloc_obj' family to use the new default GFP_KERNEL argument

2026-02-22T01:09:51Z

This was done entirely with mindless brute force, using git grep -l '\