video: dcmi: add endpoint usage in dcmi & update dma property in dtsi #89627

avolmat-st · 2025-05-07T19:39:36Z

This PR update the DCMI driver / bindings and all users of this driver in order to rely on the video-interfaces bindings rather that having its own properties.
In a second step, considering that the DMA settings are closely linked to the IP itself and the way it is connected internally, I propose to move the dma property from within the board dts into the dtsi so that each board / shield overlay do not have to copy again the same property. As a matter of fact the dcmi driver is also setting most of the DMA settings from within the driver itself.

avolmat-st · 2025-05-07T19:43:58Z

Sadly I do not have the HW to test it right now so I have only been able to compile test it. Could someone having those setup perform a sanity check that I didn't broke anything ?

ngphibang · 2025-05-07T20:14:51Z

cc @CharlesDias so that he is aware of this to avoid duplicate work. I think part of this has been started in #85452 but this one is more complete.

Could you add an overlay and test case in video's build_all tests as well so that the DCMI driver can get in the CI (#85178) ?

Thanks !

ngphibang · 2025-05-07T20:33:17Z

dts/bindings/video/st,stm32-dcmi.yaml

-      hsync-active = <0>;
-      vsync-active = <0>;
-      pixelclk-active = <1>;
-      capture-rate = <1>;


This seems analogy with the camera framerate ? Would you support of changing framerate with the video API after removing this propperty ?

Actually I only removed it from the example, it is still present in the bindings itself. However it is optional and within the driver I took care of having DT_PROP_OR with a default to 1, aka no frame skip. So since this is the default (and actually quite natural), I thought it is simply not necessary to mention it here.

Regarding the already started work, sorry, I wasn't aware about it hence I did that. Sure I can add the remaining bits within the build_all tests.

Ok I just had a look at the PR #85452 now so I understand better your point. The DCMI IP is actually capable of frame dropping. The capture-rate mentioned here is actually more like a drop rate. 1 means keep 1/1 frames (aka all), 2 means keep 1 frame out of 2 and 4 would mean keep 1 frame out of 4.
So, basically, it would be possible to map this on the framerate API by first checking the framerate up the pipeline to figure out (if possible) the source framerate (might have to go quite far there might be a bridge or so in the middle), and then compute the rate between the framerate expected by the caller compared to the framerate of the source. Not an impossible thing. I can give it a shot, however again, I will only be able to blindly check it since I don't have currently a working setup with the DCMI on it.

Hi, @avolmat-st. Thanks for your contribution.

@ngphibang, it's ok for me to continue with this PR instead of #85452. :-)

I tested this PR with the west build -p -b stm32h7b3i_dk --shield st_b_cams_omv_mb1683 samples/drivers/video/capture_to_lvgl/ and worked!

avolmat-st · 2025-05-08T23:09:31Z

frmival set/get/enum support added and simply tested using a stm32l4r9i using the video shell.
I also added an additionnal commit to change a bit handling of the set/get fmt.

Last commit adds a testcase within test/drivers/build_all/video in order to test build the dcmi. For that purpose I am using one of the board and its shield so that dcmi get enabled and thus build. I ran this with twister and it seems to build, however couldn't figure out how to see the full log and really ensure that dcmi get enabled in this configuration.

@ngphibang is that what you were expecting regarding the testcase ? I saw that in case of the NXP board there is an overlay within the build_all folder, it seems to me that if really shield get enabled then it should be enough to enable the build of the driver no ?

ngphibang · 2025-05-10T00:17:33Z

Last commit adds a testcase within test/drivers/build_all/video in order to test build the dcmi. For that purpose I am using one of the board and its shield so that dcmi get enabled and thus build. I ran this with twister and it seems to build, however couldn't figure out how to see the full log and really ensure that dcmi get enabled in this configuration.

@ngphibang is that what you were expecting regarding the testcase ? I saw that in case of the NXP board there is an overlay within the build_all folder, it seems to me that if really shield get enabled then it should be enough to enable the build of the driver no ?

Yes, the driver get built by just adding the shield as an extra args in the test case as you did (if we have only one platform_allow).

The NXP's case is a bit different. We have CSI which is common on 2 platforms, and if I remember well, when I did:

  drivers.video.mcux_csi.build:
    platform_allow:
      - mimxrt1064_evk
      - mimxrt1170_evk/mimxrt1176/cm7
    extra_args:
      - platform:mimxrt1064_evk:SHIELD=dvp_fpc24_mt9m114
      - platform:mimxrt1170_evk/mimxrt1176/cm7:SHIELD=nxp_btb44_ov5640

It didn't get built because "platform" is not taken into account. I didn't know why.

Another reason is that I see this in the app.overlay of the build_all video:

/*
 * Copyright (c) 2022, Kumar Gala <galak@kernel.org>
 *
 * SPDX-License-Identifier: Apache-2.0
 *
 * Application overlay for testing driver builds
 *
 * Names in this file should be chosen in a way that won't conflict
 * with real-world devicetree nodes, to allow these tests to run on
 * (and be extended to test) real hardware.
 */

So, I supposed that for CI testing, we should declare "fake" nodes to avoid conflicting with real-world device tree node, and so, should not use the real shield (?). So, to simplify things for two above reasons, I made the overlay.

I am not expert in test, so if you find some thing, I am willing to learn.

ngphibang

Looks very nice to me ! Thank you for doing the migration of the driver.

Waiting for your finding on the build_all video test (to see if overlay is the right thing to do or the simple extra args).

drivers/video/video_stm32_dcmi.c

erwango

Otherwise LGTM

doc/releases/migration-guide-4.2.rst

Update the bindings of the stm32-dcmi driver rely on properties described within the endpoints and already detailed within the video-interfaces.yaml. With that, several properties located at the node root are now moved into the port / endpoint: sensor -> endpoint: remote-endpoint-label vsync-active -> endpoint: vsync-active hsync-active -> endpoint: hsync-active pixelclk-active -> endpoint: pclk-sample bus-width -> endpoint: bus-width 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>

Update overlay following usage of video-interfaces based endpoint properties by the dcmi driver. Signed-off-by: Alain Volmat <alain.volmat@foss.st.com>

Usage of dma is mandatory for the dcmi and this property is tightly coupled with the soc itself since the configuration of the dma depends on the source/destination, and the request line is also fixed for an ip. Instead of having to always have the dma property part of the board or shield dts/overlay, add the dma property into the dcmi node of the stm32h7.dtsi. Signed-off-by: Alain Volmat <alain.volmat@foss.st.com>

With the addition of the dma property within the soc dtsi, it is no more necessary to add it within the board dts. 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>

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>

Add a testcase for building the stm32 dcmi driver on all currently supported platforms / shields. Signed-off-by: Alain Volmat <alain.volmat@foss.st.com>

avolmat-st · 2025-05-12T14:16:43Z

PR rebased to correct merge conflict

Add note regarding the move of the video/dcmi driver to the usage of endpoint based video-interfaces bindings. Signed-off-by: Alain Volmat <alain.volmat@foss.st.com>

avolmat-st · 2025-05-12T14:20:14Z

Otherwise LGTM

migration-guide message formatting update.

dts/bindings/video/st,stm32-dcmi.yaml

sonarqubecloud · 2025-05-12T14:49:53Z

Quality Gate passed

Issues
1 New issue
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud

github-actions bot added platform: STM32 ST Micro STM32 area: Video Video subsystem area: Shields Shields (add-on boards) labels May 7, 2025

github-actions bot requested review from avisconti, djiatsaf-st, erwango, facchinm, FRASTM, gautierg-st, GeorgeCGV, jfischer-no, josuah, kartben, loicpoulain, marwaiehm-st, mathieuchopstm, ngphibang and pillo79 May 7, 2025 19:40

github-actions bot assigned kartben May 7, 2025

avolmat-st force-pushed the video_stm32h7_dcmi_dt_dma branch from fd75c83 to 1edadce Compare May 7, 2025 19:45

avolmat-st marked this pull request as draft May 7, 2025 19:47

This was linked to issues May 7, 2025

meta: Track progress on moving video drivers and devicetree to use the video-interfaces binding and the endpoint DT macros #80514

Open

Some video drivers lack of CI tests #85178

Closed

ngphibang reviewed May 7, 2025

View reviewed changes

ngphibang previously approved these changes May 10, 2025

View reviewed changes

JarmouniA reviewed May 10, 2025

View reviewed changes

drivers/video/video_stm32_dcmi.c Outdated Show resolved Hide resolved

avolmat-st dismissed josuah’s stale review via 1de5a6a May 12, 2025 07:36

github-actions bot added the Release Notes To be mentioned in the release notes label May 12, 2025

josuah previously approved these changes May 12, 2025

View reviewed changes

erwango requested changes May 12, 2025

View reviewed changes

doc/releases/migration-guide-4.2.rst Outdated Show resolved Hide resolved

Alain Volmat added 10 commits May 12, 2025 16:14

shields: weact_ov2640_cam_module: use endpoint based properties

afe3433

Update overlay following usage of video-interfaces based endpoint properties by the dcmi driver. Signed-off-by: Alain Volmat <alain.volmat@foss.st.com>

shields: st_b_cams_omv_mb1683: use endpoint based properties

29d8cbe

Update overlay following usage of video-interfaces based endpoint properties by the dcmi driver. Signed-off-by: Alain Volmat <alain.volmat@foss.st.com>

boards: arduino_nicla_vision: use endpoint based properties

eb33bf3

Update overlay following usage of video-interfaces based endpoint properties by the dcmi driver. Signed-off-by: Alain Volmat <alain.volmat@foss.st.com>

dts: bindings: video: dcmi: remove the dma in board dts example

e5191a1

With the addition of the dma property within the soc dtsi, it is no more necessary to add it within the board dts. Signed-off-by: Alain Volmat <alain.volmat@foss.st.com>

video: stm32-dcmi: implement frame interval handling

7e4c582

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>

tests: drivers: build_all: video: add testcase of stm32 dcmi

7ff24e1

Add a testcase for building the stm32 dcmi driver on all currently supported platforms / shields. Signed-off-by: Alain Volmat <alain.volmat@foss.st.com>

avolmat-st dismissed josuah’s stale review via 9f4fc29 May 12, 2025 14:15

avolmat-st force-pushed the video_stm32h7_dcmi_dt_dma branch from 1de5a6a to 9f4fc29 Compare May 12, 2025 14:15

doc: releases: add note regarding dcmi binding update

dba3ba4

Add note regarding the move of the video/dcmi driver to the usage of endpoint based video-interfaces bindings. Signed-off-by: Alain Volmat <alain.volmat@foss.st.com>

avolmat-st force-pushed the video_stm32h7_dcmi_dt_dma branch from 9f4fc29 to dba3ba4 Compare May 12, 2025 14:18

erwango approved these changes May 12, 2025

View reviewed changes

josuah approved these changes May 12, 2025

View reviewed changes

JarmouniA reviewed May 12, 2025

View reviewed changes

dts/bindings/video/st,stm32-dcmi.yaml Show resolved Hide resolved

ngphibang approved these changes May 12, 2025

View reviewed changes

erwango assigned erwango and unassigned kartben May 13, 2025

JarmouniA approved these changes May 13, 2025

View reviewed changes

nashif merged commit 34622c0 into zephyrproject-rtos:main May 14, 2025
28 checks passed

ngphibang mentioned this pull request May 14, 2025

video: Drop video endpoint id in video APIs #87070

Merged

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Uh oh!

video: dcmi: add endpoint usage in dcmi & update dma property in dtsi #89627

video: dcmi: add endpoint usage in dcmi & update dma property in dtsi #89627

Uh oh!

avolmat-st commented May 7, 2025 •

edited

Loading

Uh oh!

avolmat-st commented May 7, 2025

Uh oh!

ngphibang commented May 7, 2025 •

edited

Loading

Uh oh!

ngphibang May 7, 2025 •

edited

Loading

Uh oh!

avolmat-st May 7, 2025

Uh oh!

avolmat-st May 7, 2025

Uh oh!

CharlesDias May 8, 2025

Uh oh!

avolmat-st commented May 8, 2025 •

edited

Loading

Uh oh!

ngphibang commented May 10, 2025 •

edited

Loading

Uh oh!

ngphibang left a comment

Uh oh!

Uh oh!

erwango left a comment

Uh oh!

Uh oh!

avolmat-st commented May 12, 2025

Uh oh!

avolmat-st commented May 12, 2025

Uh oh!

Uh oh!

sonarqubecloud bot commented May 12, 2025

Uh oh!

Uh oh!

Uh oh!

video: dcmi: add endpoint usage in dcmi & update dma property in dtsi #89627

video: dcmi: add endpoint usage in dcmi & update dma property in dtsi #89627

Uh oh!

Conversation

avolmat-st commented May 7, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

avolmat-st commented May 7, 2025

Uh oh!

ngphibang commented May 7, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

ngphibang May 7, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

avolmat-st May 7, 2025

Choose a reason for hiding this comment

Uh oh!

avolmat-st May 7, 2025

Choose a reason for hiding this comment

Uh oh!

CharlesDias May 8, 2025

Choose a reason for hiding this comment

Uh oh!

avolmat-st commented May 8, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

ngphibang commented May 10, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

ngphibang left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

erwango left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

avolmat-st commented May 12, 2025

Uh oh!

avolmat-st commented May 12, 2025

Uh oh!

Uh oh!

sonarqubecloud bot commented May 12, 2025

Quality Gate passed

Uh oh!

Uh oh!

Uh oh!

avolmat-st commented May 7, 2025 •

edited

Loading

ngphibang commented May 7, 2025 •

edited

Loading

ngphibang May 7, 2025 •

edited

Loading

avolmat-st commented May 8, 2025 •

edited

Loading

ngphibang commented May 10, 2025 •

edited

Loading