| 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 ...
|
| 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 ...
|
| 5954ad7d | 10-Jun-2025 |
Arnd Bergmann <arnd@arndb.de> |
media: st-delta: avoid excessive stack usage
Building with a reduced stack warning limit shows that delta_mjpeg_decode() copies a giant structure to the stack each time but only uses three of its me
media: st-delta: avoid excessive stack usage
Building with a reduced stack warning limit shows that delta_mjpeg_decode() copies a giant structure to the stack each time but only uses three of its members:
drivers/media/platform/st/sti/delta/delta-mjpeg-dec.c: In function 'delta_mjpeg_decode': drivers/media/platform/st/sti/delta/delta-mjpeg-dec.c:427:1: error: the frame size of 1296 bytes is larger than 1280 bytes [-Werror=frame-larger-than=]
Open-code the passing of the structure members that are actually used here.
Fixes: 433ff5b4a29b ("[media] st-delta: add mjpeg support") Signed-off-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Hans Verkuil <hverkuil+cisco@kernel.org>
show more ...
|
| ecdcfa45 | 10-Aug-2025 |
Jacopo Mondi <jacopo.mondi@ideasonboard.com> |
media: stm32: dma2d: Access v4l2_fh from file
The v4l2_fh associated with an open file handle is now guaranteed to be available in file->private_data, initialised by v4l2_fh_add().
Access the v4l2_
media: stm32: dma2d: Access v4l2_fh from file
The v4l2_fh associated with an open file handle is now guaranteed to be available in file->private_data, initialised by v4l2_fh_add().
Access the v4l2_fh, and from there the driver-specific structure, from the file * in all ioctl handlers.
Signed-off-by: Jacopo Mondi <jacopo.mondi@ideasonboard.com> Signed-off-by: Hans Verkuil <hverkuil+cisco@kernel.org>
show more ...
|
| 1b213591 | 10-Aug-2025 |
Jacopo Mondi <jacopo.mondi@ideasonboard.com> |
media: st: delta: Access v4l2_fh from file
The v4l2_fh associated with an open file handle is now guaranteed to be available in file->private_data, initialised by v4l2_fh_add().
Access the v4l2_fh,
media: st: delta: Access v4l2_fh from file
The v4l2_fh associated with an open file handle is now guaranteed to be available in file->private_data, initialised by v4l2_fh_add().
Access the v4l2_fh, and from there the driver-specific structure, from the file * in all ioctl handlers.
Signed-off-by: Jacopo Mondi <jacopo.mondi@ideasonboard.com> Co-developed-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com> Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.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 ...
|