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.

This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.