Fail to recevie v4l2 with new sensor

I am implementing a new driver for a new sensor.
I get the follwoing error in dmesg:

[  708.774818] tegra194-vi5 15c10000.vi: no reply from camera processor
[  708.776198] tegra194-vi5 15c10000.vi: uncorr_err: request timed out after 2500 ms
[  708.777449] tegra194-vi5 15c10000.vi: err_rec: attempting to reset the capture channel
[  708.797590] tegra194-vi5 15c10000.vi: err_rec: successfully reset the capture channe

When I activate the trace I see the following:

     kworker/1:2-1296  [001] .......   708.802073: rtcpu_nvcsi_intr: tstamp:22761638420 class:CORRECTABLE_ERR type:PHY_INTR phy:2 cil:1 st:0 vc:0 status:0x00000060
     kworker/1:2-1296  [001] .......   708.802073: rtcpu_nvcsi_intr: tstamp:22761638949 class:GLOBAL type:PHY_INTR0 phy:2 cil:1 st:0 vc:0 status:0x00000060
     kworker/1:2-1296  [001] .......   708.802073: rtcpu_nvcsi_intr: tstamp:22761638949 class:CORRECTABLE_ERR type:PHY_INTR phy:2 cil:1 st:0 vc:0 status:0x00000060
     kworker/1:2-1296  [001] .......   708.802073: rtcpu_nvcsi_intr: tstamp:22761639477 class:GLOBAL type:PHY_INTR0 phy:2 cil:1 st:0 vc:0 status:0x00000060
     kworker/1:2-1296  [001] .......   708.802074: rtcpu_nvcsi_intr: tstamp:22761639477 class:CORRECTABLE_ERR type:PHY_INTR phy:2 cil:1 st:0 vc:0 status:0x00000060
     kworker/1:2-1296  [001] .......   708.802074: rtcpu_nvcsi_intr: tstamp:22761640006 class:GLOBAL type:PHY_INTR0 phy:2 cil:1 st:0 vc:0 status:0x00000060
     kworker/1:2-1296  [001] .......   708.802074: rtcpu_nvcsi_intr: tstamp:22761640006 class:CORRECTABLE_ERR type:PHY_INTR phy:2 cil:1 st:0 vc:0 status:0x00000060
     kworker/1:2-1296  [001] .......   708.802074: rtcpu_nvcsi_intr: tstamp:22761640536 class:GLOBAL type:PHY_INTR0 phy:2 cil:1 st:0 vc:0 status:0x00000060
     kworker/1:2-1296  [001] .......   708.802074: rtcpu_nvcsi_intr: tstamp:22761640536 class:CORRECTABLE_ERR type:PHY_INTR phy:2 cil:1 st:0 vc:0 status:0x00000

On this linked thread, it is said that clocks are too slow.

Continuing the discussion from rtcpu_nvcsi_intr on Jetson Xavier

Now I am wondering if it happens because the sensor streams 1782Mbit/s, which is more than the magic 1500Mbit with CSI. Before we only had sensor below 1000Mbit/s, but the XAVIER NX should support up to 2500MBit/s.

Are there any changes I have to make to support this?
I also set line_length and pix_clk_hz higher than the calculated values in ():

active_w = "2688";
active_h = "2080";
line_length = "3688"; (2688)
inherent_gain = "1";
 pix_clk_hz = "1012800000"; (712800000)

Here I increased to 2500000:

num_csi_lanes = <8>;
max_lane_speed = <2500000>;
min_bits_per_pixel = <10>;
vi_peak_byte_per_pixel = <2>;
vi_bw_margin_pct = <25>;
max_pixel_rate = <240000>;
isp_peak_byte_per_pixel = <5>;
isp_bw_margin_pct = <25>;

Am I missing something?

Best,
Johannes

hello busch.johannes,

may I also know which Jetpack release version you’re working with.
please check the release tag for confirmation, i.e. $ cat /etc/nv_tegra_release

your tracing logs show PHY interrupts, for instance, PHY_INTR0 phy:2 cil:1 st:0 vc:0 status:0x00000060
the error code 0x60 it means there’re bit error detected on data-lane, which usually due to the erroneous packets on CSI channel.

please note that, if that’s a case. skew calibration is required if sensor or deserializer is using DPHY, and the output data rate is > 1.5Gbps.

Hello I am using Jetpack 4.6.

please note that, if that’s a case. skew calibration is required if sensor or deserializer is using DPHY, and the output data rate is > 1.5Gbps.

Can you hint me a little bit more about what skew calibration actually and how to do it with jetson? I didnt need to do it yet since it always worked instantly with <1.5Gbps.

Follow up question:

your tracing logs show PHY interrupts, for instance, PHY_INTR0 phy:2 cil:1 st:0 vc:0 status:0x00000060
the error code 0x60 it means there’re bit error detected on data-lane, which usually due to the erroneous packets on CSI channel.

Does that mean Skew calibration is already happening and worked?

hello busch.johannes,

it should not deskew issue since JP-4.6 software flow it doesn’t check deskew signaling.
you may expect there’re signaling on the CSI channel, but erroneous packets. it’s suggest to send a reset signal before s_stream for verificaiton.

Am I understanding correct: Deskew is not the problem then?

it’s suggest to send a reset signal before s_stream for verificaiton.

You mean to send reset from sensor? I would not know how. Or what do you mean exactly? Send reset from where to where?

hello busch.johannes,

the idea is camera sensor to toggle a reset while API calling s_stream.

Am i correct that these bits are set:

#define NVCSI_INTR_FLAG_CIL_INTR0_DATA_LANE_ERR1_SOT_SB||(U32_C(1) << 5)
#define NVCSI_INTR_FLAG_CIL_INTR0_DATA_LANE_ERR1_SOT_MB||(U32_C(1) << 6)

Why do you think does it mean erronous packets?
What does it mean exactly?

hello busch.johannes,

yes, there’re error reported by PHY_INTR0, you may also check TRM for NVCSI_PHY_0_CILA_INTR_0_MASK_CILA_0.
furthermore,
SOT_SB: it means there’s one bit error detected on the data-lane sync word
SOT_MB: it means more than one bit error has detected on the data-lane sync word.

in my experience, this usually due to sensor side did not output frames correctly.
please also review your pixel clock settings,
FYI, I usually use below formula to calculate sensor pixel clock for sensor bring-up.
pixel_clk_hz = sensor data rate per lane (Mbps) * number of lanes / bits per pixel

besides, here’s see-also Topic 260685 for your reference.

In this topic you mention updating to JP-5.1.2 with this benefit:

(3) Deskew calibration support for high data rate sensors (i.e. DPHY data-rate > 1.5 Gbps)

Should I update, too?

hello busch.johannes,

don’t you said it’s under 1.5Gbps?

anyways,
JP-5 public release do support with Xavier series.
you may also refer to Camera Driver Porting since it’s now moving to kernel v5.10

So do I NEED to update for >1.5Gbps support? Cause it will be some work for me, I’ll need to make sure it is necessary.

hello busch.johannes,

no.
sorry for misunderstanding,
CSI it supports all data-rates (up-to 2.5-Gbps per lane), skew calibration is extra required only when the output data-rate is > 1.5Gbps.

hey jerryChang,
no worries, sorry from my side, too!
But I still do not get it.

For a sensor with >1.5Gbps, (1.782Gbps), do I need to update from Jetpack 4.6 to Jetpack 5, so it can work?

Best,
Johannes

yes, but you need to confirm you have deskew signal output from the sensor side.