i tested the cases with and without the patch and confirmed that only with this patch in CPHY mode v4l2-ctl runs ok.
(for DPHY mode, default config is ok)
The lane_polarity CAB for [1] and [3] is from Figure 3-3
I found that, the valid lane-polarity configuration for v4l2 is in csi5_fops.c, it’s already there in version 35.1.
And valid lane-polarity for argus is in sensor_common.c. The new 35.2.1 begins to read lane_polarity in device tree for argus.
I have two more questions:
what’s the difference between lane_polarity and lane_swizzle?
how to set “lane_polarity” property for argus in device-tree?
As the macro defines
/* 100 := A B C → C A B */ #define NVCSI_CPHY_POLARITY_CAB MK_U32(0x04)
should i set signal->lane_polarity = 0x04000400U for [1] & [3] to CAB?
(tested not ok)
thank you for your tips, it’s the lane_polarity problem.
We disable the firewall to directly read these two registers in linux.
0x15a1_1ce0 / 0x15a1_1de0
As in v4l2, the values are 0x0000_2000 both.
In argus case, they are always 0x0000_0000, even if i try to patch the sensor_common.c with correct polarity.
It seems, that the driver did not really send this info to RCE to write these two registers.
With disabled firewall, we start a thread with period 0.1s to overwrite these two values.
Then gst-launch preview is ok.
Now the problem is, how to set lane_polarity for CPHY for custom board in a regular way?
Hi,
We add lane_polarity property for DPHY in Argus in Jetpack 5.1. It is not supported in CPHY. Is it possible to rework for matching the ABC pins of CPHY?
Our board design is intended to be compatible for both D and C to support a flexible use for a quick prototype.
Hope in later version of Jetpack, the lane_polarity setting for C in augus case will also be added.
I think we can close this issue.
Thank you.
