drivers: video: Introduce macro to deal with endpoints

[josuah]

This is part of a series of proposals for incremental changes for the Video API:

• drivers: video: API enhancement #72959

This depends on:

• dts: flatten video's device tree endpoints definition #72950

It introduces some way to point at devicetree objects and use them in the API.
It assumes that endpoint numbers can be passed where enum video_endpoint_id ep is present through the API.

Example:

vid0: videodev@10380000 {
	ports {
		#address-cells = <2>;
		#size-cells = <0>;

		vid0port0in: endpoint@0000 {
			reg = <0 0>;
			data-lanes = <0 1 2 3>;
			remote-endpoint = <&other>;
		};

		vid0port0out: endpoint@0001 {
			reg = <0 1>;
			data-lanes = <4 5 6 7>;
			remote-endpoint = <&other>;
		};

		vid0port1in: endpoint@0100 {
			reg = <1 0>;
			data-lanes = <0 1 2 3>;
			remote-endpoint = <&other>;
		};
	};
};

It is then possible to refer vid0port0out like this:

video_set_signal(DEVICE_DT_GET(DT_NODELABEL(vid0)), VIDEO_DT_ENDPOINT_ID(vid0port0out));

[josuah]

This needs testing after #72950 is merged.

[loicpoulain]

Looks promising, would it make sense to have in/out type encoded/described?

[josuah]

I picked the first nibble to encode a custom field that will say either "IN" or "OUT" or "EITHER" or "NONE", which is showcased here:

https://github.com/zephyrproject-rtos/zephyr/pull/73009/files#diff-70c4de6949b97c13ac893b4bfb16fbcc433593fbfa96ec8947bb5cb83c4d04bcR129-R136

[josuah]

This is now rebased on top of #73009.

[ngphibang]

@josuah : I will need sometimes to look at this closer. But does this resolve the "circular dependency" and the "chicken-egg" init order issues or this is just APIs to deal with endpoints ? So, my questions

• With these, can we obtain a reference to the video object pointed by the remote-endpoint so that we don't need to use direct phandle references in DT (currently this method is used extensively in Zephyr) ?
• If so, how do you handle the case that the "remote" video object is not available yet (due to the init order priority) ? As an example, the CSI driver needs to initialize before the mt9m114 camera sensor driver to provide the master clock for the sensor. But in the CSI driver, we need to obtain a reference to the mt9m114 sensor (to propagate formats, etc.)
• ports / endpoints / remote-endpoints are not only limit to video, they are used for display and other things too. Why don't we put these things in the zephyr core instead of the video subsystem ?

[josuah]

With these, can we obtain a reference to the video object pointed by the remote-endpoint so that we don't need to use direct phandle references in DT (currently this method is used extensively in Zephyr) ?

Yes, the various struct ..._dt_spec were the source if inspiration. Now this video_dt_spec is built to refer the local device: useful by the application only that would refer a VIDEO_DT_SPEC_GET(DT_NODELABEL(csi_0_out))...

The driver would still have to do something like this to follow the remote endpoint, and then call video_dt_spec on that:

spec = VIDEO_DT_SPEC_GET(DT_INST_PROP(DT_CHILD(DT_CHILD(n, ports), endpoint_0), remote_endpoint))

Maybe a VIDEO_DT_REMOTE_ENDPOINT_GET() could wrap that to help using it in drivers...

---

If so, how do you handle the case that the "remote" video object is not available yet (due to the init order priority) ? As an example, the CSI driver needs to initialize before the mt9m114 camera sensor driver to provide the master clock for the sensor. But in the CSI driver, we need to obtain a reference to the mt9m114 sensor (to propagate formats, etc.)

An application connecting two video ports might also face this problem, so maybe the solution is in the samples:
https://github.com/zephyrproject-rtos/zephyr/blob/main/samples/subsys/video/capture/src/main.c#L50
https://github.com/zephyrproject-rtos/zephyr/blob/main/samples/subsys/video/capture/src/main.c#L70

The calls that could be recursive (get/set feed parameters, and data movement) are set from application, after everything is initialized.

Is there a chance that recursive calls (get data/controls from this device that gets data/controls from this device [...]) happens during initialization?

One alternative would be to have an extra video_enable() API that allows all the initial recursive calls to be performed after initialization is done, like in USB:
https://docs.zephyrproject.org/latest/connectivity/usb/device_next/api/usbd.html#c.usbd_enable

---

ports / endpoints / remote-endpoints are not only limit to video, they are used for display and other things too. Why don't we put these things in the zephyr core instead of the video subsystem ?

This makes more sense as you said. And it looks like the "ports / port / endpoint / remote-endpoint" logic is even encoded into the devicetree tool itself:
https://github.com/torvalds/linux/blob/dccb07f2914cdab2ac3a5b6c98406f765acab803/scripts/dtc/checks.c#L1770