Skip to content
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

video: emul: virtual driver for an imager and RX engine #79482

Merged
merged 2 commits into from
Dec 6, 2024

Conversation

josuah
Copy link
Collaborator

@josuah josuah commented Oct 6, 2024

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):

west twister --inline-logs --platform native_sim --scenario tests/drivers/video/api/drivers.video.api

Fixes: #73867

@josuah
Copy link
Collaborator Author

josuah commented Oct 6, 2024

I note that the frame interval API was merged, this will need to include it.

@josuah josuah added DNM This PR should not be merged (Do Not Merge) and removed DNM This PR should not be merged (Do Not Merge) labels Oct 6, 2024
@josuah josuah marked this pull request as draft October 6, 2024 23:23
@josuah josuah force-pushed the pr-video-sensor-skeleton branch 5 times, most recently from eb4a7a4 to cfa3bfb Compare October 13, 2024 13:20
@josuah josuah marked this pull request as ready for review October 13, 2024 13:20
@zephyrbot zephyrbot added the area: Base OS Base OS Library (lib/os) label Oct 13, 2024
@josuah
Copy link
Collaborator Author

josuah commented Oct 13, 2024

  • Aims to cover the most frequent use-cases and facilitate modifications on top
  • Assume that image sensor drivers are apply modes described by pixelformat+resolution+framerate
  • For every new sensor, require filling a few tables and let the ready-made functions hook them to the Zephyr video API

@josuah josuah requested review from pillo79 and uLipe October 13, 2024 13:36
@josuah josuah force-pushed the pr-video-sensor-skeleton branch 2 times, most recently from 64e0235 to 9a1a450 Compare October 14, 2024 12:02
@zephyrbot zephyrbot added platform: STM32 ST Micro STM32 area: Watchdog Watchdog labels Oct 14, 2024
@zephyrbot zephyrbot requested review from erwango and FRASTM October 14, 2024 12:03
josuah added a commit to tinyvision-ai-inc/zephyr that referenced this pull request Nov 21, 2024
PR zephyrproject-rtos#79482 is where this commit would be added

Signed-off-by: Josuah Demangeon <[email protected]>
@josuah
Copy link
Collaborator Author

josuah commented Nov 27, 2024

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.

@ngphibang
Copy link
Contributor

I will try to review this whenever possible, thanks !

drivers/video/video_emul_imager.c Outdated Show resolved Hide resolved
drivers/video/video_emul_rx.c Outdated Show resolved Hide resolved
*
* @return The frame interval value in microseconds.
*/
uint64_t video_frmival_nsec(const struct video_frmival *frmival);
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Could this be a simple inline helper?

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes I agree. Done now.

@josuah josuah force-pushed the pr-video-sensor-skeleton branch 3 times, most recently from 8cef8e6 to b29dbdc Compare December 2, 2024 07:11
@josuah
Copy link
Collaborator Author

josuah commented Dec 2, 2024

force-push:

  • applied recommendations from review
  • fix the RGB565 pattern generator (wrong color order)
  • cfg seems more frequently used than conf
  • endpoint@0 (IN) first, endpoint@1 (OUT) after, in devicetree, to have the source upstream and sinks downstream in the dts files, which also matches the media-ctl --print-dot numbering

scrot_20241202_081623_1271x138

[EDIT: the above is this on Linux: media-ctl --print-dot | circo -Tpdf >media-ctl-pipeline.pdf]

josuah added a commit to tinyvision-ai-inc/zephyr that referenced this pull request Dec 3, 2024
PR zephyrproject-rtos#79482 is where this commit would be added

Signed-off-by: Josuah Demangeon <[email protected]>
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 <[email protected]>
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 <[email protected]>
@josuah josuah force-pushed the pr-video-sensor-skeleton branch from b29dbdc to fc94165 Compare December 3, 2024 01:09
Copy link
Collaborator

@loicpoulain loicpoulain left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

@nashif nashif removed the area: Base OS Base OS Library (lib/os) label Dec 5, 2024
@nashif nashif merged commit 9e908b1 into zephyrproject-rtos:main Dec 6, 2024
25 checks passed
* @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,
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

@ngphibang
Copy link
Contributor

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 video.h).

return 0;
}

/* See #80649 */
Copy link
Contributor

@ngphibang ngphibang Dec 6, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This uses all the macros defined in #80649 by copying them here. I think the better way is to make this PR depending on #80649 or cherry-pick the commits.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

As this was merged first, I will fix the conflict in #80649 then.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

s/the better way/the correct way

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This was opened 2 weeks before #80649, so got started with putting some custom macros, and then forgot to rebase it on #80649. Thank you for fixing these macros on #80649!

@josuah josuah deleted the pr-video-sensor-skeleton branch December 6, 2024 13:21
@josuah
Copy link
Collaborator Author

josuah commented Dec 6, 2024

I had them on video_common.h at first, but noticed they could also be used from the application for some purpose... so I moved them to video.h.

Let me know which one would be a better fit in video_common.h.

I also wanted to introduce IMX219 and others following this template.
So reviews will help even post-merge!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

drivers: video: sensors: add a sensor_skeleton.c to speed-up contribution of simple sensors
8 participants