Orin + tc358743 VIFALC_TDSTATE

Hello!

We have working system with tc358743 + Xavier AGX devkit with L4T 32.7.1. Now I try to run tc358743 on Jetson Agx Orin devkit with Jetpack 5.0.1 L4T 34.1.1, but video stream is not received by Orin.

I found some similar topics with following solution:

Skew calibration is required if sensor or deserializer is using DPHY, and the output data rate is > 1.5Gbps.

However:

  • I have not found how to enable Skew calibration on tc358743, suppose there is no such function on tc358743. Is it possible to disable waiting for skew calibration on Orin?
  • Output data rate from tc358743 seems less than 1.5Gbps per lane
    Output data rate = (sensor or deserializer pixel clock in hertz) * (bits per pixel) / (number of CSI lanes) = 74250000*16/2 = 594000000 = ~600Mbps.
    Does it mean that skew calibration is not required?
  • Oscilloscope shows that stream is present on CSI lanes, but I always have VIFALC_TDSTATE error. Please find logs below.

tc358743 status:

   [154030.580921] tc358743 2-000d: -----Chip status-----
   [154030.581237] tc358743 2-000d: Chip ID: 0x00
   [154030.581536] tc358743 2-000d: Chip revision: 0x00
   [154030.581671] tc358743 2-000d: Reset: IR: 1, CEC: 1, CSI TX: 0, HDMI: 0
   [154030.581845] tc358743 2-000d: Sleep mode: off
   [154030.581966] tc358743 2-000d: Cable detected (+5V power): yes
   [154030.582276] tc358743 2-000d: DDC lines enabled: yes
   [154030.582569] tc358743 2-000d: Hotplug enabled: yes
   [154030.582884] tc358743 2-000d: CEC enabled: no
   [154030.583014] tc358743 2-000d: -----Signal status-----
   [154030.583159] tc358743 2-000d: TMDS signal detected: yes
   [154030.583300] tc358743 2-000d: Stable sync signal: yes
   [154030.583444] tc358743 2-000d: PHY PLL locked: yes
   [154030.583576] tc358743 2-000d: PHY DE detected: yes
   [154030.586223] tc358743 2-000d: Detected format: 1920x1080p30.00 (2200x1125)
   [154030.586431] tc358743 2-000d: horizontal: fp = 0, -sync = 280, bp = 0
   [154030.586608] tc358743 2-000d: vertical: fp = 0, -sync = 45, bp = 0
   [154030.587498] tc358743 2-000d: pixelclock: 74250000
   [154030.592420] tc358743 2-000d: flags (0x0):
   [154030.596607] tc358743 2-000d: standards (0x0):
   [154030.601071] tc358743 2-000d: Configured format: 1920x1080p30.00 (2200x1125)
   [154030.607980] tc358743 2-000d: horizontal: fp = 0, -sync = 280, bp = 0
   [154030.614280] tc358743 2-000d: vertical: fp = 0, -sync = 45, bp = 0
   [154030.620579] tc358743 2-000d: pixelclock: 74250000
   [154030.625392] tc358743 2-000d: flags (0x0):
   [154030.629591] tc358743 2-000d: standards (0x0):
   [154030.633880] tc358743 2-000d: -----CSI-TX status-----
   [154030.639128] tc358743 2-000d: Lanes needed: 2
   [154030.643436] tc358743 2-000d: Lanes in use: 2
   [154030.647993] tc358743 2-000d: Waiting for particular sync signal: no
   [154030.654452] tc358743 2-000d: Transmit mode: yes
   [154030.659004] tc358743 2-000d: Receive mode: no
   [154030.663376] tc358743 2-000d: Stopped: no
   [154030.667400] tc358743 2-000d: Color space: YCbCr 422 16-bit
   [154030.673326] tc358743 2-000d: -----DVI-D status-----
   [154030.678156] tc358743 2-000d: HDCP encrypted content: no
   [154030.683580] tc358743 2-000d: Input color space: RGB full range

dmesg output:

[153998.407804] bwmgr API not supported
[153998.480543] mc-err: (255) csr_vi2falr: EMEM address decode error
[153998.483329] mc-err:   status = 0x20001071; hi_addr_reg = 0x0000007d addr = 0x7df84fa060
[153998.483794] mc-err:   secure: no, access-type: read
[153998.484253] mc-err: mcerr: unknown intr source intstatus = 0x00000000, intstatus_1 = 0x00000000
[154001.108954] tegra-camrtc-capture-vi tegra-capture-vi: uncorr_err: request timed out after 2500 ms
[154001.109224] tegra-camrtc-capture-vi tegra-capture-vi: err_rec: attempting to reset the capture channel
[154001.110287] (NULL device *): vi_capture_control_message: NULL VI channel received
[154001.110490] t194-nvcsi 13e40000.host1x:nvcsi@15a00000: csi5_stream_close: Error in closing stream_id=3, csi_port=3
[154001.110765] (NULL device *): vi_capture_control_message: NULL VI channel received
[154001.110959] t194-nvcsi 13e40000.host1x:nvcsi@15a00000: csi5_stream_open: VI channel not found for stream- 3 vc- 0
[154001.111360] tegra-camrtc-capture-vi tegra-capture-vi: err_rec: successfully reset the capture channel
[154003.669030] tegra-camrtc-capture-vi tegra-capture-vi: uncorr_err: request timed out after 2500 ms
[154003.669302] tegra-camrtc-capture-vi tegra-capture-vi: err_rec: attempting to reset the capture channel
[154003.670192] (NULL device *): vi_capture_control_message: NULL VI channel received
[154003.670383] t194-nvcsi 13e40000.host1x:nvcsi@15a00000: csi5_stream_close: Error in closing stream_id=3, csi_port=3

camrtc trace:

        v4l2-ctl-34115   [000] .... 154803.133123: tegra_channel_open: vi-output, tc358743 2-000d
        v4l2-ctl-34115   [000] .... 154803.140596: tegra_channel_set_power: tc358743 2-000d : 0x1
        v4l2-ctl-34115   [000] .... 154803.140600: tegra_channel_set_power: 13e40000.host1x:nvcsi@15a00000- : 0x1
        v4l2-ctl-34115   [000] .... 154803.140602: csi_s_power: enable : 0x1
        v4l2-ctl-34115   [000] .... 154803.140666: tegra_channel_capture_setup: vnc_id 0 W 1920 H 1080 fmt 10
        v4l2-ctl-34115   [001] .... 154803.146800: tegra_channel_set_stream: enable : 0x1
        v4l2-ctl-34115   [001] .... 154803.155065: tegra_channel_set_stream: 13e40000.host1x:nvcsi@15a00000- : 0x1
        v4l2-ctl-34115   [001] .... 154803.155069: csi_s_stream: enable : 0x1
        v4l2-ctl-34115   [001] .... 154803.155603: tegra_channel_set_stream: tc358743 2-000d : 0x1
    kworker/10:1-32861   [010] .... 154803.164688: rtcpu_string: tstamp:4838152387111 id:0x04010000 str:"VM0 activating."
    kworker/10:1-32861   [010] .... 154803.164691: rtcpu_nvcsi_intr: tstamp:4838152811482 class:GLOBAL type:PHY_INTR0 phy:1 cil:1 st:0 vc:0 status:0x0e000000
    kworker/10:1-32861   [010] .... 154803.164692: rtcpu_vinotify_event: tstamp:4838152823453 cch:0 vi:1 tag:VIFALC_TDSTATE channel:0x23 frame:0 vi_tstamp:154820880018464 data:0xc55dd70010000000
    kworker/10:1-32861   [010] .... 154803.164692: rtcpu_vinotify_event: tstamp:4838152823585 cch:0 vi:1 tag:VIFALC_TDSTATE channel:0x23 frame:0 vi_tstamp:154820880025056 data:0x0000000031000001
    kworker/10:1-32861   [010] .... 154803.164692: rtcpu_vinotify_event: tstamp:4838152823734 cch:0 vi:1 tag:VIFALC_TDSTATE channel:0x23 frame:0 vi_tstamp:154820880066368 data:0xc55dd40010000000
    kworker/10:1-32861   [010] .... 154803.164692: rtcpu_vinotify_event: tstamp:4838152823864 cch:0 vi:1 tag:VIFALC_TDSTATE channel:0x23 frame:0 vi_tstamp:154820880073472 data:0x0000000031000002
    kworker/10:1-32861   [010] .... 154803.164693: rtcpu_nvcsi_intr: tstamp:4838152827972 class:GLOBAL type:PHY_INTR0 phy:1 cil:1 st:0 vc:0 status:0x00000044
    kworker/10:1-32861   [010] .... 154803.164693: rtcpu_nvcsi_intr: tstamp:4838152828339 class:GLOBAL type:PHY_INTR0 phy:1 cil:1 st:0 vc:0 status:0x00000044
    kworker/10:1-32861   [010] .... 154803.164693: rtcpu_nvcsi_intr: tstamp:4838152828707 class:GLOBAL type:PHY_INTR0 phy:1 cil:1 st:0 vc:0 status:0x00000044

hello nazaraa,

it looks your serdes pixel clock settings is 74250000, right?
could you please try reduce the value in the device tree for testing, thanks

Hello Jerry Chang,

We use standard Linux driver for TC358743 (kernel-5.10/drivers/media/i2c/tc358743.c). It has remark:

	/*
	 * FIXME: These things are from REF_02 for 594 Mbps per lane (297 MHz
	 * link frequency). In principle it should be possible to calculate
	 * them based on link frequency and resolution.
	 */
	if (bps_pr_lane != 594000000U)
		dev_warn(dev, "untested bps per lane: %u bps\n", bps_pr_lane);

So, all settings for TC358743 was done for 594Mbps per lane and hardcoded in this driver. Dts has has property link-frequencies = /bits/ 64 <297000000>;
I feel that it is not so easy to reduce the value for testing.
However I have just run tc358743 sucessfully on Xavier AGX devkit with L4T 34.1.1.
It seems that Orin wait for deskew signals ragardless of output data rate.

Is it possible to disable waiting for deskew signals on Orin?

sorry, skew calibration cannot configure as disabled.
if the deskew signals is not sent, the receiver will stall, and the capture will time out.

Skew calibration is required if sensor or deserializer is using DPHY, and the output data rate is > 1.5Gbps.

Could you confirm that if I set output data rate less than 1.5 Gbps per lane then Orin will start receive data without waiting for skew calibration?

Output data rate from tc358743 is less than 1.5Gbps per lane and equal 594 Mbps.
Or should I keep looking for a bug in my dts and driver settings?

hello nazaraa,

please have a try to reduce the values of serdes_pix_clk_hz.

Hello JerryChang,

I can confirm that pixelclock 74 MHz and 64 MHz does not work, however 25 MHz works.
Number of CSI lanes is 2. Output data rate per lane accordingly 594, 512, 200.

Waiting for clarification:

  • Which maximum output data rate per lane should I set to make Orin receive data without skew calibration?
  • We need to receive 1920x1080@30fps video over 2 CSI lanes from devices based on tc358743. It seems that it is impossible to do. Can we expect fixes in camera rtcpu firmware in the further Jetpack releases?

hello nazaraa,

please refer to developer guide, SerDes Pixel Clock.

Skew calibration is required if sensor or deserializer is using DPHY, and the output data rate is > 1.5Gbps.

according to the announcements, Topic 222842. JetPack 5 production release should be available soon, please check your use-case again with the latest release.

Hi JerryChang,

JP 5.0.2 L4T 35.1 has the same issue. Log attached.
Pixelclock 74 MHz does not work, 25 MHz works.

log.txt (7.9 KB)

hello nazaraa,

do you have several cameras connect to SerDes chip and the total bandwidth is exceed the 1.5 Gbps?
if yes, the Deserializer should send the deskew on behalf of the connected sensors.

We do not use SerDes. tc358743 is plugged directly to the Camera Connector (J509) Orin DevKit. The total bandwidth does not exceed the 1.5 Gbps.

hello nazaraa,

you may calculate the data rate with below formula, deskew is unnecessary when output data rate < 1.5Gbps.
i.e. Output data rate = (sensor or deserializer pixel clock in hertz) * (bits per pixel) / (number of CSI lanes)

could you please review the port bindings.
your device tree should defined tc358743 occupied CSI port, port-index, and the total lanes, bus-width it is used.

btw, may I know what’s the logs from kernel side, are you still see NULL VI channel failures?

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