Commit 64149e4df6 added an "#if defined()"
for configuring DMA channels differently depending on SOC family of the
STM32 HAL, but did not include the STM32H7 family in the same group as
STM32F7. Fix it by adding the STM32H7 in the same #ifdef filter.
Fixes#92015
Signed-off-by: Josuah Demangeon <me@josuah.net>
DMA callback is wrongly named as dmci in the source code,
correct the name to be dcmi_dma_callback.
Signed-off-by: Alain Volmat <alain.volmat@foss.st.com>
The STM32 DMA LL api differ between the STM32F7 and the STM32L4
in order to get the CHANNEL instance information. For that
reason, enclose within preproc statements STM32F7 specific code
and add STM32L4 code related to the DMA configuration for the
DCMI peripheral.
Signed-off-by: Alain Volmat <alain.volmat@foss.st.com>
This commit fixes an error introduced by commit c0dae0c9ac
("video: stm32: dcmi: perform config based on endpoint properties")
in which incorrect instance was being access leading to usage of
the default value for pixel clock / hsync / vsync polarities and bus
width.
Signed-off-by: Alain Volmat <alain.volmat@foss.st.com>
Now that video api functions have __ASSERT_NO_MSG calls, drivers
do not need to check the entry point functions pointers.
Signed-off-by: Alain Volmat <alain.volmat@foss.st.com>
The format pitch (bytesperline) field is typically set by the bridge
drivers, i.e. DMA, ISP drivers who actually handle the memory as they
know exactly the memory layout constraints.
Application just set the pixel format and resolution and must always
read back this field to see what the driver actually sets (to allocate
buffers for example).
Also, drop format pitch setting in sensor drivers as this is not needed.
Signed-off-by: Phi Bang Nguyen <phibang.nguyen@nxp.com>
Drop video_stm32_dcmi_is_fmt_valid() as it is not needed. In this
function, (i) checking against a format based on another utility
function video_bits_per_pixel() is not robust, this check is done in
the sensor driver, (ii) checking against the heap size is not
appropriate because this should be done when allocating buffers, not
in get/set format.
Signed-off-by: Phi Bang Nguyen <phibang.nguyen@nxp.com>
M2M devices like ISPs or PxP have two separate buffer queues, i.e.
incoming and outcoming queues. For each API, the driver needs to
distinguish on which queue it needs to take action.
Add video buffer type to support this kind of devices.
- get_caps(), set/get_format(), enqueue()/dequeue(): the buffer type
is embeded in the video_caps, video_format and video_buffer structs
- video_stream_start/stop() : buffer type needs is sent as a parameter
Signed-off-by: Phi Bang Nguyen <phibang.nguyen@nxp.com>
The video endpoints are already described in the devicetree. The
video_endpoint_id parameter in each video API is not necessary and has
no usage. Drop it.
Signed-off-by: Phi Bang Nguyen <phibang.nguyen@nxp.com>
Implement the video API frame interval handling in order
to control the framerate of capture.
This allow to remove the capture-rate DT property as well.
Signed-off-by: Alain Volmat <alain.volmat@foss.st.com>
This commit mainly correct the get/set format handling and how
DCMI format is stored within the driver. struct video_format
within the data structure is used to store the format.
Reworked way to handle get format to avoid calling the sensor
set_fmt whenever performing the get_fmt.
Slightly adjusted code to as much as possible reuse return
values provided by functions.
Signed-off-by: Alain Volmat <alain.volmat@foss.st.com>
Perform sensor interface properties parsing based on values
retrieved via the endpoint rather than the root of the node.
Use DT_PROP_OR to ensure proper configuration of optional
settings.
Signed-off-by: Alain Volmat <alain.volmat@foss.st.com>
In Clang 16 run with some flags, the compiler does not accept a static
const variables as struct initializer. This caused build errors in only
some contexts. Always use the devicetree macros to access the source
device node as a workaround.
Signed-off-by: Josuah Demangeon <me@josuah.net>
Implement the video control framework with the following features:
- Drivers initialize the control with a valid value range at boot which
guides the application developer and the framework. Hence, the video
framework could do all common works for drivers e.g., sanity check.
- Controls need to be cached to memory. Video framework handles
get_ctrl(), drivers don't need to implement this API. It is because
reading control value directly from registers are not only inefficient
but also sometimes impossible, e.g. controls that scatter through
several registers. Only "volatile" control needs to be updated at
runtime.
- Only the devices (e.g., sensors) owning the controls need to
implement set_ctrl(). Other devices of the pipeline do not need to
propagate set_ctrl() and hence, do not need to implement this API
Signed-off-by: Phi Bang Nguyen <phibang.nguyen@nxp.com>
Introduce a new video device structure representing a device in a
video pipeline. Each video device embeds a pointer to its "source"
device and other "video" characteristics.
This structure give the video framework an access to all video features
of the device and a hierachical view of the video pipeline that the
device belongs to.
Signed-off-by: Phi Bang Nguyen <phibang.nguyen@nxp.com>
The video_stream_start/stop() APIs are counter-symetric and have
the same function signature. Also, the implementation logic for
those driver APIs is generally the same. Merge them to save memory
and code lines.
For the sake of simplicity, still keep the user APIs to preserve
backward compatibility with downstream applications.
Signed-off-by: Phi Bang Nguyen <phibang.nguyen@nxp.com>
Add a check to ensure the frame size does not exceed the video buffer
size defined by `CONFIG_VIDEO_BUFFER_POOL_SZ_MAX`. Even if the sensor
supports the resolution, the frame size could overflow the buffer.
Signed-off-by: Ibrahim Abdalkader <i.abdalkader@gmail.com>
Ensure the DCMI video buffer is released only after the DCMI
has been fully stopped. This prevents potential access to the
buffer while the DCMI is still active, avoiding undefined behavior.
Signed-off-by: Ibrahim Abdalkader <i.abdalkader@gmail.com>
Instead of reserving a static (possibly unaligned) buffer for DCMI,
this patch reserves and holds one of the video buffers to use as the
main DCMI buffer. This buffer will be aligned (using the alignment
specified in the config) and will either be allocated from `video_common`
pool or a shared multi-heap (if enabled).
Signed-off-by: Ibrahim Abdalkader <i.abdalkader@gmail.com>
This was present in the form of video_pix_fmt_bpp() inside ST and NXP
drivers, and was returning the number of bytes, which does not allow
support for 10-bits, 4-bits or non-byte aligned video formats.
The helper leverages the VIDEO_PIX_FMT_*_BITS macros.
Signed-off-by: Josuah Demangeon <me@josuah.net>
As getting bytes per pixel of a pixel format is a very common operation,
add an utility function for it instead of repeating the same codes in
different drivers.
Signed-off-by: Phi Bang Nguyen <phibang.nguyen@nxp.com>
Since all video drivers in tree use a full frame, their video buffers
will always start at a line_offset of 0 within the frame.
Signed-off-by: Daniel DeGrasse <daniel.degrasse@nxp.com>
Update existing video drivers to handle the min/max line count field
within the video_caps structure. All drivers work with full frames
currently, so use the special LINE_COUNT_HEIGHT value to indicate this.
Signed-off-by: Daniel DeGrasse <daniel.degrasse@nxp.com>
Zephyr drivers have typically one log level defined per class. The video
drivers were making exception. This adds the missing log level for video
drivers.
Since all headers had to be modified, this also:
- Update the log initialization to the new syntax from 5e34681
- Sort the #include list to something like #41543
Signed-off-by: Josuah Demangeon <me@josuah.net>
The current video drivers did not allow VIDEO_EP_ALL to be selected,
as used by video_stream_stop().
This adds the VIDEO_EP_ALL to each video driver that filtered endpoints.
Signed-off-by: Josuah Demangeon <me@josuah.net>
The frame event callback unconditionally copies into the enqueued video
buffer. The driver only supports fixed length frames, so reject enqueued
buffers that are not large enough to prevent invalid memory access.
Signed-off-by: Brett Witherspoon <brett@witherspoon.engineering>
Josuah Demangeon
Alain Volmat
Phi Bang Nguyen
Ibrahim Abdalkader
Pieter De Gendt
Daniel DeGrasse
Charles Dias
Brett Witherspoon