-
Notifications
You must be signed in to change notification settings - Fork 6.5k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add parallel interface (DVP) support for ov5640 driver #76124
base: main
Are you sure you want to change the base?
Add parallel interface (DVP) support for ov5640 driver #76124
Conversation
635e3a1
to
73e0ea7
Compare
73e0ea7
to
77c2eeb
Compare
Dear, Please, @ngphibang, @josuah, @erwango, and @loicpoulain, could you take a look at the draft PR to check if I am on the right path? Thanks! |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thank you for this addition!
Progressively, more features of these complex sensors can be integrated from Linux and other sources into Zephyr.
This looks like almost ready to go. See some few feedback inline. Feel free to dismiss it or address it as relevant.
drivers/video/ov5640.c
Outdated
if (ret) { | ||
LOG_ERR("Unable to set virtual channel"); | ||
LOG_ERR("Unable to initialize the sensor with DVP parameters"); | ||
return -EIO; | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This looks all correct, but it would be less confusing to have it inside the if to group it semantically.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Done.
drivers/video/ov5640.c
Outdated
fmt.width = 1280; | ||
fmt.height = 720; | ||
if (ov5640_is_dvp(dev)) { | ||
/* Set default format to 480x272 RGB565 */ |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Comment: This looks like one particular display rather than a common resolution format, though it is also good that the defaults did get tested on actual hardware.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Since this version of the DVP feature does not support the current resolution configuration (1280x720), it would be better to set it up for the minimal resolution supported by DVP.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ah right I understand better now thank you.
Did you try various resolutions and noticed that 480x272 RGB565 was the highest one supported by DVP?
I do not see this resolution anywhere on Linux or the datasheet.
Just curious. :)
DVP should support resolutions higher than 480x272, but due to my board's memory (I'm using only the internal SRAM) and display limitations, I was able to test 160x120, 320x240, and 480x272.
For future version, I'll try to use the external SDRAM and others resolution.
This might need rebasing once #76144 (not in draft state) is merged. |
dts/bindings/video/ovti,ov5640.yaml
Outdated
@@ -5,7 +5,7 @@ description: OV5640 CMOS video sensor | |||
|
|||
compatible: "ovti,ov5640" | |||
|
|||
include: i2c-device.yaml | |||
include: [i2c-device.yaml, video-interfaces.yaml] |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think this will not have any effects as the properties defined in video-interfaces.yaml
are for an endpoint node, not for the ov5640 node itself. The difficulty here (and the reason why I let #74415 always as draft) is that we cannot know the endpoint is actually a child or a grand child node of the video device node (e.g. ov5640) as ports node is optional, so that we don't know if we should use 1 or 2 levels of child-binding in the video-interfaces.yaml
:
- child-binding:
child-binding:
So, I think the solution for now is that either we:
- Don't include
video-interfaces.yaml
, and just declare the properties in the devicetree. It will compile without any problem. Thevideo-interfaces.yaml
will still serve as a reference. - Or add
compatible: "nxp,zephyr-endpoint"
in the endpoint node and invideo-interfaces.yaml
@josuah Do you have a solution for this ?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Dear, @ngphibang and @josuah,
If I change from include: [i2c-device.yaml, video-interfaces.yaml]
to include: i2c-device.yaml
, I got the compile error below:
devicetree error: 'bus-type' appears in /soc/i2c@58001c00/ov5640@3c in /home/charlesdias/zephyrproject/zephyr/build/zephyr/zephyr.dts.pre, but is not declared in 'properties:' in /home/charlesdias/zephyrproject/zephyr/dts/bindings/video/ovti,ov5640.yaml
I think that the video-interfaces.yaml
is making an effect on the ov5640 node. Does this make sense?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think it's because you declared these properties on the ov5640 node. All the properties in video-interfaces.yaml
should be declared in the endpoint subnode (together with remote-endpoint
)
Thanks, @josuah and @ngphibang for your suggestions. I'll fix them during the weekend. |
@CharlesDias Thanks for adding this dvp mode to the ov5640 driver. As being said last time in your raised issue, we were also working on supporting changing frame rates and some controls to the ov5640 driver at the same time. Here is the PR. Sorry that we couldn't push our PR earlier to facilitate your work due to some difficulties in the impelmentation. If possible, could you take into account our changes ? (IMO, some commits in our PR could make the dvp support easier and your PR is a bigger change so it seems easier to rebase your change on ours than vice versa ?) I am available for any helps if needed. |
For sure, @ngphibang, I'll do the rebase by the end of the week. Thanks for being available! |
Run clang format before making any changes. Signed-off-by: Phi Bang Nguyen <[email protected]>
Add some control IDs: - VIDEO_CID_CAMERA_HUE - VIDEO_CID_POWER_LINE_FREQUENCY - VIDEO_CID_PIXEL_RATE which is needed for changing frame rate Signed-off-by: Phi Bang Nguyen <[email protected]>
Color bar is one type of test patterns. Rename it to VIDEO_CID_CAMERA_TEST_PATTERN to be more generic. Signed-off-by: Phi Bang Nguyen <[email protected]>
Add some minor fixes and optimizations: - Fix coding style - Rename some variables - Use the array variable size directly instead of defining a macro Signed-off-by: Phi Bang Nguyen <[email protected]> Signed-off-by: Trung Hieu Le <[email protected]>
Add support for 4 test pattern modes: - Color bar - Color bar rolling - Square - Square rolling Signed-off-by: Phi Bang Nguyen <[email protected]>
Add some controls: - hue - saturation - brightness - contrast - gain - hflip - vflip - power line frequency filter - pixel rate (read-only) which is needed for changing frame rate Signed-off-by: Farah Fliss <[email protected]> Signed-off-by: Phi Bang Nguyen <[email protected]>
Add support for changing frame rate Signed-off-by: Trung Hieu Le <[email protected]> Signed-off-by: Phi Bang Nguyen <[email protected]>
77c2eeb
to
c0038bd
Compare
Rebase with #76144 |
Improve the ov5640 video driver to provide parallel interface (DVP) support Signed-off-by: Charles Dias <[email protected]>
c0038bd
to
7e2dfdf
Compare
Apply review suggestions. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hi @josuah, I considered this initial version ready to go (apart from the reviewer's suggestions and the PR dependencies). I added the [DNM] to avoid merging it before the dependencies. I'm not sure if this is the right approach. |
The DNM label gives me a hint that this might be made for this purpose but I would not bet an arm on it... |
Related to the issue #74353.
These PRs are requires:
This PR is related to:
Testing on STM32H7B3I-DK
west build -p -b stm32h7b3i_dk --shield st_b_cams_omv_mb1683 samples/subsys/video/capture_to_lvgl/
west build -p -b stm32h7b3i_dk --shield st_b_cams_omv_mb1683 samples/drivers/video/capture_to_lvgl/
document_5147857391924020551.mp4