drivers: video: video_mcux_smartdma: add SMARTDMA video driver

[danieldegrasse]

Add SMARTDMA video driver. This driver uses the SMARTDMA engine as a
parallel camera interface, which can read QVGA frames from a camera
device. Due to SRAM constraints, the video driver divides the camera
stream into multiple horizontal video buffers as it streams them back to
an application.

Note that this PR also contains two additional major changes:

• an addition to the video API to enable streaming partial frames within one video buffer
• a rework of the SMARTDMA driver interface to better support custom firmware use cases like the camera in this PR

This PR depends on #72826 for camera support

PR has been tested on the following boards:

• frdm_mcxn947//cpu0: samples/subsys/video/capture
• mimxrt595_evk//cm33: samples/subsys/display/lvgl (using G1120B0MIPI shield)

[zephyrbot]

The following west manifest projects have been modified in this Pull Request:

Name	Old Revision	New Revision	Diff

Note: This message is automatically posted and updated by the Manifest GitHub Action.

[josuah]

• an addition to the video API to enable streaming partial frames within one video buffer

Some news about it there, with a proposed API: #66994 (comment)

[josuah]

here (need to click on "load diff") is a new API that seems underway:

	if (drv_data->fifo_length == 0) {
		vbuf->flags = VIDEO_BUF_EOF;
	} else {
		vbuf->flags = VIDEO_BUF_FRAG;
		k_work_submit_to_queue(&ac_work_q, &drv_data->buf_work);
	}

[danieldegrasse]

here (need to click on "load diff") is a new API that seems underway:

No issues with this API, I suppose we would like to make this PR dependent on that API merging? I could also cherry pick the commits adding the API from that PR (@ArduCAM would you be ok with that approach?)

[ArduCAM]

here (need to click on "load diff") is a new API that seems underway:

No issues with this API, I suppose we would like to make this PR dependent on that API merging? I could also cherry pick the commits adding the API from that PR (@ArduCAM would you be ok with that approach?)

Yes, have marked resolved

[danieldegrasse]

No worries, I'll work on getting this PR updated

PR has been updated- something I realized while working on this was that we can't really provide framebuffer size bounds until the format is set- therefore, I chose to report the min/max number of frame lines rather than the buffer size, as this should be independent of format (I think).

[loicpoulain]

Looks good, is it ok to merge @danieldegrasse ?

[josuah]

It is true that many video processing cores have a line buffer, or a 5-line buffers (i.e. small kernels) rather than an XYZ bytes buffers.

A line-based min/max size sounds good.

[danieldegrasse]

Looks good, is it ok to merge @danieldegrasse ?

Yes, provided you are ok with the API changes. Let me rebase to fix conflicts.

[josuah]

Thank you for adjusting all the other drivers too!