Hardware Platform: Jetson AGX OrinSoftware
Version: JetPack [5.1.2] / L4T [35.4]
Description:
I am integrating a camera system using the MAX96724 deserializer with the Jetson Orin CSI interface.
Four sensors->two max96701 and two max96717 → max96724(a single MIPI CSI-2 link) → agx orin
The Configuration:
We have configured the MAX96724 to operate in a mode similar to “Force MIPI Out” (Continuous Clock Mode).
The MAX96724 outputs a continuous high-speed (HS) MIPI clock on the clock lane, even when there is no active video data transmission.
Consequently, the standard MIPI D-PHY LP-11 (Idle state) is not present on the clock lane before the data transmission starts.
The Problem:
We are observing a specific “handshake” failure between the Orin CSI DPHY and the continuous clock source. The behavior is as follows:
Initial State: Power on the system.
Step 1: Run v4l2-ctl --stream-mmap -d /dev/video0.
Result: The command hangs and eventually reports vi timeout. No data is received.
Step 2: Without stopping v4l2-ctl, I manually toggle (disable/enable) the MAX96724 MIPI output clock via I2C.
Result: The stream immediately starts working, and we capture valid video data.
Step 3: Stop the v4l2-ctl stream. Wait for a short period.
Step 4: Try to start the stream again.
Result: It fails with vi timeout again. I must toggle the MAX96724 output again to recover.
The Issue:
I need to verify if the Orin CSI D-PHY receiver can successfully establish a lock and capture data under these conditions.
Hardware Capability: Blind Lock Support: Does the Orin CSI receiver hardware support “Blind Lock” (clk lane entering HS receive mode without detecting the standard LP-11->01->00 sequence)?
If the Orin D-PHY supports blind clock locking, will it still establish a connection with the MAX96724 even if the Data Lane never asserts LP-11?
Could the following scenario be occurring:
The Orin wakes up and blindly locks onto the clock, but then indefinitely waits for an LP-11 transition on the Data Lane. However, since the MAX96724 is continuously transmitting dummy padding packets, the LP-11 state never arrives.
Consequently, the Orin remains stuck in this endless wait state until a timeout occurs—which explains the ‘hanging’ behavior you are observing.
I don’t think Jetson support it.
The LP-11 → LP-01 → LP-00 clock-lane sequence is must required for MIPI data receiving.
Thanks
Thank you for your response. I have a follow-up question:
After v4l2-ctl is terminated (i.e., after streamoff is called), does the Jetson AGX Orin D-PHY or the NVCSI enter a low-power or sleep state?
To be more specific, does this action cause the D-PHY link between the MAX96724 and the Jetson AGX Orin to break or disconnect?
Additionally, could you point me to any reference materials that support this conclusion? Is this behavior explicitly documented in the Technical Reference Manual (TRM)?
I look forward to your reply. Thanks.
Jetson is receive side don’t control the MIPI state only check the LP state to handshake to receive data from the sensor.
Does the link synchronization between the Deserializer D-PHY and the Orin D-PHY depend on the Device Tree clock settings? Specifically, what are the prerequisites for the Orin D-PHY to successfully lock onto the Deserializer’s clock?
If the D-PHYs have established a lock, is it possible for them to lose synchronization without any external operations?
The cil_settletime depend on the pix_clk_hz/serdes_pix_clk_hz.
You can check the MIPI spec for the settle time for handshake.
Thanks
cil_settletime is 0, the driver attempts to auto-calibrate according to the mclk_multiplier parameter.
mclk_multiplier :Deprecated. This switch is no longer needed because the value it specifies is calculated internally.
Will the Orin automatically calculate the value based on the pix_clk_hz or serdes_pix_clk_hz？or cil_settletime =pix_clk_hz/serdes_pix_clk_hz?
If pix_clk_hz < serdes_pix_clk_hz, is the pix_clk_hz parameter effectively ignored?
I suspect the D-PHYs on both ends are out of sync. Is there any register on the Orin side that I can read to verify the D-PHY or NVCSI status?
I enabled the logs, and when I repeated the steps above, I observed that after reconfiguring the MAX96724 output, the values of registers NVCSI_PHY_1_CILA_INTR_0_STATUS_CILA_0 and NVCSI_PHY_1_CILB_INTR_0_STATUS_CILB_0 changed from 0x0e000000 / 0x06000000 to 0x01c00000 / 0x00c00000.
Specifically, intr_dphy_cil_deskew_calib_err_lan1_a turned into intr_dphy_cil_deskew_calib_done_lan1_a.
Does this indicate that there is an issue with the deskew calibration? Or could it mean that the MAX96724 is unable to maintain the HS state continuously?
The deskew calibration error could be relative to the clocks.
Skew calibration is required if sensor or deserializer is using DPHY, and the output data rate is > 1.5Gbps.
An initiation deskew signal should be sent by sensor or deserializer to perform the skew calibration. If the deskew signals is not sent, the receiver will stall, and the capture will time out.
You can calculate the output data rate with the following equation:
Output data rate = (sensor or deserializer pixel clock in hertz) * (bits per pixel) / (number of CSI lanes)