video pipeline on rt10xx: Fix chicken-egg issue in init priority #80052
Conversation
ngphibang
force-pushed
the
camera_sample_add_10xx_workaround
branch
from
d1c1d92 to
9268c4e
Compare
zephyrbot
requested review from
danieldegrasse,
dbaluta,
decsny,
manuargue and
MarkWangChinese
ngphibang
force-pushed
the
camera_sample_add_10xx_workaround
branch
from
9268c4e to
6d345c3
Compare
|
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. |
There was a problem hiding this comment.
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 |
Absolutely! This is this PR and while I did not add ztests yet, this works as a workaround: |
|
Yes, the intentional purpose of presenting I think both are work-around but this one ( 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 |
|
To broaden the discussion scope, Linux has all the mechanism to parse and retrieve the peer (sub-)device for example with some helper functions 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. |
|
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. |
As getting bytes per pixel of a pixel format is a very common operation, add an utility function for it instead of repeating the same codes in different drivers. Signed-off-by: Phi Bang Nguyen <[email protected]>
Remove the obsolete comment about the init order of the CSI and the camera sensors (e.g. mt9m114) which is not true anymore. Signed-off-by: Phi Bang Nguyen <[email protected]>
When stopping, video_flush() moves all the remaining buffers from the fifo_in to the fifo_out queue. When restarting, we have two issues: - There might be insufficient or no buffers in the fifo_in queue to get the pipeline started. - When dequeuing, users might immediatly get the incorrect buffers in the fifo_out which do not come from interruption. Fix it by moving all the remaining buffers from the fifo_out to the fifo_in before starting the video capture. Signed-off-by: Trung Hieu Le <[email protected]> Signed-off-by: Phi Bang Nguyen <[email protected]>
Add support for changing frame rate Signed-off-by: Trung Hieu Le <[email protected]> Signed-off-by: Phi Bang Nguyen <[email protected]>
The mcux csi is an NXP IP and the driver has been recently changed much by NXP, so add NXP copyright to it. Signed-off-by: Phi Bang Nguyen <[email protected]>
Switch to use the new video interfaces bindings Signed-off-by: Phi Bang Nguyen <[email protected]>
Switch to use the new video interfaces bindings Signed-off-by: Phi Bang Nguyen <[email protected]>
Switch to use the new video interfaces binding Signed-off-by: Phi Bang Nguyen <[email protected]>
Switch to use the new video interfaces binding Signed-off-by: Phi Bang Nguyen <[email protected]>
The csi, mipicsi2rx, ov5640 devices now use the new video interface bindings. Change the test accordingly to take into account this. Signed-off-by: Phi Bang Nguyen <[email protected]>
As CSI now uses the new video-interfaces binding, this shield needs to be changed too. Signed-off-by: Phi Bang Nguyen <[email protected]>
The ov5640 camera driver now supports both MIPI CSI2 (DPHY) and DVP modes. It is in MIPI CSI2 mode in this overlay. Add bus-type property for this. In this mode, data-lanes property is required as well. Signed-off-by: Phi Bang Nguyen <[email protected]>
Get number of data lanes from device tree instead of hard-coding it. Signed-off-by: Phi Bang Nguyen <[email protected]>
Add set_ctrl callback to propagate controls to the sensor. Signed-off-by: Farah Fliss <[email protected]> Signed-off-by: Phi Bang Nguyen <[email protected]>
Instead of fixing csi2rx clock frequencies, set them according to the pixel rate got from the camera sensor. Signed-off-by: Trung Hieu Le <[email protected]> Signed-off-by: Phi Bang Nguyen <[email protected]>
Add support for changing frame rate. Signed-off-by: Trung Hieu Le <[email protected]> Signed-off-by: Phi Bang Nguyen <[email protected]>
The peer remote device "sensor_dev" can be retrieved from the remote-endpoint-label. Direct reference via phandle is not needed. Signed-off-by: Phi Bang Nguyen <[email protected]>
The peer remote device "source_dev" can be retrieved from the remote-endpoint-label. Direct reference via phandle is not needed. Signed-off-by: Phi Bang Nguyen <[email protected]>
The CSI needs to be initialized BEFORE the camera sensor to provide clock to the camera sensor. It is now possible to do so as direct reference to the sensor via phandle is now not needed, so there is no failed check on the init order anymore when compiling. Signed-off-by: Phi Bang Nguyen <[email protected]>
ngphibang
force-pushed
the
camera_sample_add_10xx_workaround
branch
from
6d345c3 to
6c68e6b
Compare
|
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". |
ngphibang
changed the title
ngphibang
changed the title
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.