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  and  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  &  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?
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.