video: emul: virtual driver for an imager and RX engine#79482
video: emul: virtual driver for an imager and RX engine#79482nashif merged 2 commits intozephyrproject-rtos:mainfrom
Conversation
|
I note that the frame interval API was merged, this will need to include it. |
eb4a7a4 to
cfa3bfb
Compare
|
64e0235 to
9a1a450
Compare
|
In the process of implementing these emulated drivers, I introduced more video API helpers to reduce boilerplate. If introducing helpers does not make sense in this same PR, I can integrate them back into the emulated drivers to reduce the amount of things this introduces. |
|
I will try to review this whenever possible, thanks ! |
eb2d81e to
87e71dd
Compare
include/zephyr/drivers/video.h
Outdated
There was a problem hiding this comment.
Could this be a simple inline helper?
There was a problem hiding this comment.
Yes I agree. Done now.
8cef8e6 to
b29dbdc
Compare
|
force-push:
[EDIT: the above is this on Linux: |
Introduce a video_get_format_index() utility to help finding a caps entry out of a given format. Introduce several utilities to seek and apply frame intervals. Signed-off-by: Josuah Demangeon <me@josuah.net>
Add a new implementation of a test pattern generator, with the same architecture as real drivers: split receiver core and I2C-controlled sub-device, with changes of video format in "zephyr,emul-imager" leads to different data produced by "zephyr,emul-rx". Signed-off-by: Josuah Demangeon <me@josuah.net>
b29dbdc to
fc94165
Compare
| * @return 0 when a format is found. | ||
| * @return -ENOENT when no matching format is found. | ||
| */ | ||
| int video_format_caps_index(const struct video_format_cap *fmts, const struct video_format *fmt, |
There was a problem hiding this comment.
All the introduced functions here are supposed for drivers uses only ?. I think it should be put in an internal header rather in the public header video.h.
There was a problem hiding this comment.
The users can access the format cap structure, so they could be interested in verifying: "for this particular width/height/pixelformat, what is the min/max/step?
Not sure this would ever get used that way though! Glad with putting it on a drivers/video/video_common.h header like often done for driver helper functions.
|
Sorry that I couldn't manage to review this before it gets merged (but I think this is merged a bit too fast though, seeing the number of new functions introduced in |
| return 0; | ||
| } | ||
|
|
||
| /* See #80649 */ |
There was a problem hiding this comment.
As this was merged first, I will fix the conflict in #80649 then.
There was a problem hiding this comment.
s/the better way/the correct way
|
I had them on Let me know which one would be a better fit in I also wanted to introduce IMX219 and others following this template. |

This takes inspiration on the other skeleton.c drivers through Zephyr tree:
https://github.com/zephyrproject-rtos/zephyr/blob/main/drivers/usb/udc/udc_skeleton.c
https://github.com/zephyrproject-rtos/zephyr/blob/main/drivers/display/display_dummy.c
It acts as a starting point and as a puppet to explain API changes affecting image sensors.
Be used for providing test cases for the entire API, as required for stable APIs.
Utilities are introduced in the process to reduce boilerplate.
Twister command (new with this PR):
Fixes: #73867