video pipeline on rt10xx: Fix chicken-egg issue in init priority

[ngphibang]

Similar to the mcxn947 (ov7670/smartDMA) issue, the CSI needs to be initialized BEFORE the camera sensor to provide clock to the camera sensor. However, the CSI node refers to the camera sensor node in the DT so it has to be initialized AFTER the sensor to be able to compile.

This is a deadlock/chicken-egg issue as Zephyr currently does not allow circular dependency. Disable the init priority check as a work-around for this.

[ngphibang]

We knew and did take the work-around internally but I think this should go into upstream so that people have an "out-of-the-box" working sample on i.MX RT10xx.

[josuah]

If I understand correctly, the init dependency is in the opposite direction than the source = <&ov7670>; suggests: phandles are considered as dependencies by the python scripts, whereas it is the opposite here.

If source = <&ov7670>; is replaced by remote-endpoint-label = "ov7670_out"; (for instance), would that also be a workaround? In this case, there would not need to disable CONFIG_CHECK_INIT_PRIORITIES as there would be no more phandle at all?

Besides this, the workaround looks logical and avoids a compilation error, so seems necessary.

[danieldegrasse]

If I understand correctly, the init dependency is in the opposite direction than the source = <&ov7670>; suggests: phandles are considered as dependencies by the python scripts, whereas it is the opposite here.

If source = <&ov7670>; is replaced by remote-endpoint-label = "ov7670_out"; (for instance), would that also be a workaround? In this case, there would not need to disable CONFIG_CHECK_INIT_PRIORITIES as there would be no more phandle at all?

Besides this, the workaround looks logical and avoids a compilation error, so seems necessary.

I think this would work, but I'm not sure Zephyr's DT tooling is capable of getting a device object via another method than a phandle. We could probably use something like DT_NODELABEL(DT_STRING_TOKEN(remote_endpoint_label)) to get the node ID in this case? @decsny do you have any thoughts here?

[josuah]

We could probably use something like DT_NODELABEL(DT_STRING_TOKEN(remote_endpoint_label)) to get the node ID in this case? @decsny do you have any thoughts here?

Absolutely! This is this PR and while I did not add ztests yet, this works as a workaround:
https://github.com/zephyrproject-rtos/zephyr/pull/73023/files#diff-d95b579605c12a2d00175b8b293dd3b30688ceed11edc95f473d4e3dc40b5babR3851

[ngphibang]

Yes, the intentional purpose of presenting remote-endpoint-label is to be able to find a way to work around the "circular dependency" issue but I didn't know that we can retrieve the object from the string (rather easily) with DT_STRING_TOKEN. Glad to know this through this PR.

I think both are work-around but this one (remote-endpoint-label with DT_STRING_TOKEN) is much better. Then we will need to pay attention when retrieving the object with DT_STRING_TOKEN to make sure that the peer device is already intialized.

I initially made this PR just in waiting for #73023 to get in first but yes, we can actually use DT_STRING_TOKEN individually in each driver while waiting for a common macro in device.h or video.h. Will change to this approach after checking that DT_STRING_TOKEN actually works

[ngphibang]

To broaden the discussion scope, Linux has all the mechanism to parse and retrieve the peer (sub-)device for example with some helper functions v4l2_async_notifier_parse_fwnode_endpoints_by_port(), etc.

And I think this circular dependency issue here is a sub-problem that we don't have "async init" in Zephyr where each device wait for each other to complete the initialization phase as each of them depends on others in different steps of initialization.

[josuah]

So if I this gets merged first, it gives more time to design the DT endpoint API, and in the meantime the samples are working.

[ngphibang]

I think I will close this PR and move the 3 commits in this PR to #76475 as they strongly depend on that PR and also fall in the same theme "Improve NXP csi, mipi csi2rx drivers".