| 87ebce19 | 06-Jan-2026 |
Alain Volmat <alain.volmat@foss.st.com> |
media: stm32: dcmi: addition of DMA-MDMA chaining support
Add possibility to rely on an additional MDMA channel and chain
the DMA and MDMA channels allowing to achieve faster capture.
Indeed, on the
media: stm32: dcmi: addition of DMA-MDMA chaining support
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 <alain.volmat@foss.st.com>
Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
show more ...
|
| fd239fef | 06-Jan-2026 |
Alain Volmat <alain.volmat@foss.st.com> |
media: stm32: dcmi: continuous mode capture in JPEG
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 f
media: stm32: dcmi: continuous mode capture in JPEG
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 <alain.volmat@foss.st.com>
Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
show more ...
|
| 04e04744 | 06-Jan-2026 |
Alain Volmat <alain.volmat@foss.st.com> |
media: stm32: dcmi: use dmaengine_terminate_async in irq context
Whenever receiving an OVERRUN event or an end of frame, the driver stops
currently ongoing DMA transfer since the DCMI stops sending
media: stm32: dcmi: use dmaengine_terminate_async in irq context
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 <alain.volmat@foss.st.com>
Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
show more ...
|
| c1cde657 | 06-Jan-2026 |
Alain Volmat <alain.volmat@foss.st.com> |
media: stm32: dcmi: perform all dma handling within irq_thread
Move all the type of frame handling within the dcmi_irq_thread
handler and do not rely on dma_callback as previously.
This simplifies
media: stm32: dcmi: perform all dma handling within irq_thread
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 <alain.volmat@foss.st.com>
Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
show more ...
|
| c0216d07 | 06-Jan-2026 |
Alain Volmat <alain.volmat@foss.st.com> |
media: stm32: dcmi: rework spin_lock calls
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
media: stm32: dcmi: rework spin_lock calls
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 <alain.volmat@foss.st.com>
Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
show more ...
|
| 4847286b | 06-Jan-2026 |
Alain Volmat <alain.volmat@foss.st.com> |
media: stm32: dcmi: stop the dma transfer on overrun
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 f
media: stm32: dcmi: stop the dma transfer on overrun
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 <alain.volmat@foss.st.com>
Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
show more ...
|
| 9b6f6208 | 06-Jan-2026 |
Alain Volmat <alain.volmat@foss.st.com> |
media: stm32: dcmi: only create dma descriptor once at buf_prepare
Perform the dmaengine prep_slave_sg call within buf_prepare and
mark the descriptor as reusable in order to avoid having to redo
th
media: stm32: dcmi: only create dma descriptor once at buf_prepare
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 <alain.volmat@foss.st.com>
Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
show more ...
|
| bc901885 | 06-Jan-2026 |
Alain Volmat <alain.volmat@foss.st.com> |
media: stm32: dcmi: perform dmaengine_slave_config at probe
Perform the dma channel configuration at probe time right after
the channel allocation since this is fixed for the whole lifetime
of the d
media: stm32: dcmi: perform dmaengine_slave_config at probe
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 <alain.volmat@foss.st.com>
Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
show more ...
|
| 8e3c7238 | 19-Dec-2025 |
Alain Volmat <alain.volmat@foss.st.com> |
media: stm32: dcmipp: bytecap: remove useless cmier variable
The struct dcmipp_bytecap_device embeds a cmier variable which is
actually only set once and then used in several places for interrupt
ma
media: stm32: dcmipp: bytecap: remove useless cmier variable
The struct dcmipp_bytecap_device embeds a cmier variable which is
actually only set once and then used in several places for interrupt
mask or interrupt enable/disable. Use the DCMIPP_CMIER_P0ALL
bitfield macro directly instead of using it through the cmier
variable.
There is also no need to mask again vcap->cmsr2 against enabled
interrupts bit since this has already been done when storing the
interrupt status into the cmsr2 variable.
Signed-off-by: Alain Volmat <alain.volmat@foss.st.com>
Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
Signed-off-by: Hans Verkuil <hverkuil+cisco@kernel.org>
show more ...
|
| 8a71f1f8 | 19-Dec-2025 |
Alain Volmat <alain.volmat@foss.st.com> |
media: stm32: dcmipp: byteproc: only allow compose with 8/16bit fmts
Since the byteproc is working at byte level, it is not possible to
perform decimation with formats other than 8 or 16 bit per pix
media: stm32: dcmipp: byteproc: only allow compose with 8/16bit fmts
Since the byteproc is working at byte level, it is not possible to
perform decimation with formats other than 8 or 16 bit per pixel.
Ensure any other format won't be able to set a compose.
Signed-off-by: Alain Volmat <alain.volmat@foss.st.com>
Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
Signed-off-by: Hans Verkuil <hverkuil+cisco@kernel.org>
show more ...
|
| 0085da13 | 19-Dec-2025 |
Alain Volmat <alain.volmat@foss.st.com> |
media: stm32: dcmipp: add Y10-Y12-Y14 in all subdevs
DCMIPP can handle Y8 to Y14 input formats however until now only
Y8 was handled. Add support for Y10-Y12-Y14 in all relevant
subdevs.
Signed-off
media: stm32: dcmipp: add Y10-Y12-Y14 in all subdevs
DCMIPP can handle Y8 to Y14 input formats however until now only
Y8 was handled. Add support for Y10-Y12-Y14 in all relevant
subdevs.
Signed-off-by: Alain Volmat <alain.volmat@foss.st.com>
Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
Signed-off-by: Hans Verkuil <hverkuil+cisco@kernel.org>
show more ...
|
| f29f8bfc | 19-Dec-2025 |
Alain Volmat <alain.volmat@foss.st.com> |
media: stm32: dcmipp: Add RGB888 format support overall
Add entries within several subdevs in order to handle RGB888 format.
Signed-off-by: Alain Volmat <alain.volmat@foss.st.com>
Signed-off-by: Sa
media: stm32: dcmipp: Add RGB888 format support overall
Add entries within several subdevs in order to handle RGB888 format.
Signed-off-by: Alain Volmat <alain.volmat@foss.st.com>
Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
Signed-off-by: Hans Verkuil <hverkuil+cisco@kernel.org>
show more ...
|
| 3363aa26 | 19-Dec-2025 |
Alain Volmat <alain.volmat@foss.st.com> |
media: stm32: dcmipp: byteproc: disable compose for all bayers
Avoid possibility to perform compose on all frames which mbus code is
within the bayer range or jpeg format.
Fixes: 822c72eb1519 ("med
media: stm32: dcmipp: byteproc: disable compose for all bayers
Avoid possibility to perform compose on all frames which mbus code is
within the bayer range or jpeg format.
Fixes: 822c72eb1519 ("media: stm32: dcmipp: add bayer 10~14 bits formats")
Cc: stable@vger.kernel.org
Signed-off-by: Alain Volmat <alain.volmat@foss.st.com>
Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
Signed-off-by: Hans Verkuil <hverkuil+cisco@kernel.org>
show more ...
|
| 222f1279 | 19-Dec-2025 |
Alain Volmat <alain.volmat@foss.st.com> |
media: stm32: dcmipp: bytecap: clear all interrupts upon stream stop
Ensure that there are no pending interrupts after we have stopped the
pipeline. Indeed, it could happen that new interrupt has be
media: stm32: dcmipp: bytecap: clear all interrupts upon stream stop
Ensure that there are no pending interrupts after we have stopped the
pipeline. Indeed, it could happen that new interrupt has been generated
during the stop_streaming processing hence clear them in order to avoid
getting a new interrupt right from the start of a next start_streaming.
Fixes: 28e0f3772296 ("media: stm32-dcmipp: STM32 DCMIPP camera interface driver")
Cc: stable@vger.kernel.org
Signed-off-by: Alain Volmat <alain.volmat@foss.st.com>
Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
Signed-off-by: Hans Verkuil <hverkuil+cisco@kernel.org>
show more ...
|
| 27796674 | 10-Aug-2025 |
Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com> |
media: Reset file->private_data to NULL in v4l2_fh_del()
Multiple drivers that use v4l2_fh and call v4l2_fh_del() manually reset
the file->private_data pointer to NULL in their video device .release
media: Reset file->private_data to NULL in v4l2_fh_del()
Multiple drivers that use v4l2_fh and call v4l2_fh_del() manually reset
the file->private_data pointer to NULL in their video device .release()
file operation handler. Move the code to the v4l2_fh_del() function to
avoid direct access to file->private_data in drivers. This requires
adding a file pointer argument to the function.
Changes to drivers have been generated with the following coccinelle
semantic patch:
@@
expression fh;
identifier filp;
identifier release;
type ret;
@@
ret release(..., struct file *filp, ...)
{
<...
- filp->private_data = NULL;
...
- v4l2_fh_del(fh);
+ v4l2_fh_del(fh, filp);
...>
}
@@
expression fh;
identifier filp;
identifier release;
type ret;
@@
ret release(..., struct file *filp, ...)
{
<...
- v4l2_fh_del(fh);
+ v4l2_fh_del(fh, filp);
...
- filp->private_data = NULL;
...>
}
@@
expression fh;
identifier filp;
identifier release;
type ret;
@@
ret release(..., struct file *filp, ...)
{
<...
- v4l2_fh_del(fh);
+ v4l2_fh_del(fh, filp);
...>
}
Manual changes have been applied to Documentation/ to update the usage
patterns, to drivers/media/v4l2-core/v4l2-fh.c to update the
v4l2_fh_del() prototype and reset file->private_data, and to
include/media/v4l2-fh.h to update the v4l2_fh_del() function prototype
and its documentation.
Additionally, white space issues have been fixed manually in
drivers/usb/gadget/function/uvc_v4l2.c
Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
Signed-off-by: Hans Verkuil <hverkuil+cisco@kernel.org>
show more ...
|