Read CSI Register on Jetson Tx2

Hi,

I’m trying to read CSI registers on the TX2 using devmem2 tool.

The following CSI registers were attempted :

CSI memory base address as per TX2 TRM : 0x150c0000

Register offset: 0x4027
Register byte offset : 0x1009C

Resultant address : 0x150D40C3.

I have followed the following thread https://forums.developer.nvidia.com/t/debugging-csi-on-tx1/59308 . As per this thread, we can only access the 32-bit address i.e. end with the 4 times like 0, 4, 8, C.

So, I have executed following command:

sudo devmem2 0x150D40C4

for which I am getting following message:

/dev/mem opened.
Memory mapped at address 0x7fb5172000.
Bus error

Same is happening for other registers.

I have also tried for other module like I2C, UART, VI at their base Address. In case I2C i am getting Value. but for other My system is crashing.

Q1: Another observation is that each time I run " sudo devmem2 0x150D40C4 “, I get different value for " Memory mapped at address 0x7fb5172000”. I am not able to understand this aspect.

Q2: Please suggest that how can I read register at above address without bus error.

Q3: Is it possible that the CSI module has not been enabled at all by driver ? Is there a register where I can check if CSI module is enabled ?

Q3: Please provide specific register Address for CSI status/error as I am unable to understand from TRM. I hope that once I am able to read at 0x150D40C4,

Regards,
Vikas Dwevedi

hello vikas.wfh,

may I have your confirmation that you would like to check CSI register of NVCSI_STREAM_0_ERROR_STATUS2VI_VC2_0 ?
you may enable camera stream and gather the register dumps.
you should also have actual memory address by adding NVCSI address start with byte offset,
hence, it should be: 0x150C0000 + 0x1009C = 150D009C

Hello JerryChang,

Yes, I’m trying to check CSI register of `NVCSI_STREAM_0_ERROR_STATUS2VI_VC2_0’.

I have executed the address as per your suggestion, but getting same ‘Bus error’.

Now about camera stream, In our system we are taking input from VGA which is going to the decoder and then output of decoder goes to FPGA. FPGA will convert the data to CSI format and gives to the CSI.

We are very sure that decoder is working and giving correct output to FPGA, but we are not sure that CSI is getting data or not from FPGA.

So we are trying to debug if CSI is able to receive data or not because we do not have any mechanism to debug FPGA. Can you suggest any way to find out if CSI is getting data or any register that we can read?

I also want to know what ‘Bus error’ exactly mean.

Regards,
Vikas

hello vikas.wfh,

did you configure sensor stream to stream-0, may I know what’s your port binding results?
you may refer to developer guide, To verify the port binding result.

BTW,
please also enable the VI tracing logs from debugfs.
for example,

echo 1 > /sys/kernel/debug/tracing/tracing_on
echo 30720 > /sys/kernel/debug/tracing/buffer_size_kb
echo 1 > /sys/kernel/debug/tracing/events/tegra_rtcpu/enable
echo 1 > /sys/kernel/debug/tracing/events/freertos/enable
echo 2 > /sys/kernel/debug/camrtc/log-level
echo > /sys/kernel/debug/tracing/trace

there’re two different approaches you may gather logs for reference,

  1. you may gather logs as below.
$ cat /sys/kernel/debug/tracing/trace
  1. Or, there’s commands to check tracing logs in real-time,
$ cat /sys/kernel/debug/tracing/trace_pipe

Hello JerryChang,

Please find the binding results below:

> sds@sds-desktop:~$ media-ctl -pd /dev/media0
> Media controller API version 0.1.0
>
> Media device information
> 
> driver          tegra-vi4
> model           NVIDIA Tegra Video Input Device
> serial          
> bus info        
> hw revision     0x3
> driver version  0.0.0
> 
> Device topology
> - entity 1: 150c0000.nvcsi--2 (2 pads, 2 links)
>             type V4L2 subdev subtype Unknown flags 0
>             device node name /dev/v4l-subdev0
> 	pad0: Sink
> 		<- "adv7604 30-0020":6 [ENABLED]
> 	pad1: Source
> 		-> "vi-output, adv7604 30-0020":0 [ENABLED]
> 
> - entity 4: adv7604 30-0020 (7 pads, 1 link)
>             type V4L2 subdev subtype Unknown flags 0
>             device node name /dev/v4l-subdev1
> 	pad0: Sink
> 		[dv.caps:BT.656/1120 min:0x0@25000000 max:1920x1200@225000000 stds:CEA-861,DMT,CVT,GTF caps:progressive,reduced-blanking,custom]
> 	pad1: Sink
> 		[dv.caps:BT.656/1120 min:0x0@25000000 max:1920x1200@225000000 stds:CEA-861,DMT,CVT,GTF caps:progressive,reduced-blanking,custom]
> 	pad2: Sink
> 		[dv.caps:BT.656/1120 min:0x0@25000000 max:1920x1200@225000000 stds:CEA-861,DMT,CVT,GTF caps:progressive,reduced-blanking,custom]
> 	pad3: Sink
> 		[dv.caps:BT.656/1120 min:0x0@25000000 max:1920x1200@225000000 stds:CEA-861,DMT,CVT,GTF caps:progressive,reduced-blanking,custom]
> 	pad4: Sink
> 		[dv.caps:BT.656/1120 min:0x0@25000000 max:1920x1200@225000000 stds:CEA-861,DMT,CVT,GTF caps:progressive,reduced-blanking,custom]
> 	pad5: Sink
> 		[dv.caps:BT.656/1120 min:0x0@25000000 max:1920x1200@225000000 stds:CEA-861,DMT,CVT,GTF caps:progressive,reduced-blanking,custom]
> 	pad6: Source
> 		[fmt:RGB888_1X24/1600x1200 field:none colorspace:srgb
> 		 crop.bounds:(0,0)/1600x1200
> 		 crop:(0,0)/1600x1200]
> 		[dv.caps:BT.656/1120 min:0x0@25000000 max:1920x1200@225000000 stds:CEA-861,DMT,CVT,GTF caps:progressive,reduced-blanking,custom]
> 		[dv.query:no-link]
> 		[dv.current:BT.656/1120 1600x1200p60 (2160x1250) stds:DMT flags:]
> 		-> "150c0000.nvcsi--2":0 [ENABLED]
> 
> - entity 12: vi-output, adv7604 30-0020 (1 pad, 1 link)
>              type Node subtype V4L flags 0
>              device node name /dev/video0
> 	pad0: Sink
> 		<- "150c0000.nvcsi--2":1 [ENABLED]
> 
> - entity 24: 150c0000.nvcsi--1 (2 pads, 2 links)
>              type V4L2 subdev subtype Unknown flags 0
>              device node name /dev/v4l-subdev2
> 	pad0: Sink
> 		<- "adv7604 32-0020":6 [ENABLED]
> 	pad1: Source
> 		-> "vi-output, adv7604 32-0020":0 [ENABLED]
> 
> - entity 27: adv7604 32-0020 (7 pads, 1 link)
>              type V4L2 subdev subtype Unknown flags 0
>              device node name /dev/v4l-subdev3
> 	pad0: Sink
> 		[dv.caps:BT.656/1120 min:0x0@25000000 max:1920x1200@225000000 stds:CEA-861,DMT,CVT,GTF caps:progressive,reduced-blanking,custom]
> 	pad1: Sink
> 		[dv.caps:BT.656/1120 min:0x0@25000000 max:1920x1200@225000000 stds:CEA-861,DMT,CVT,GTF caps:progressive,reduced-blanking,custom]
> 	pad2: Sink
> 		[dv.caps:BT.656/1120 min:0x0@25000000 max:1920x1200@225000000 stds:CEA-861,DMT,CVT,GTF caps:progressive,reduced-blanking,custom]
> 	pad3: Sink
> 		[dv.caps:BT.656/1120 min:0x0@25000000 max:1920x1200@225000000 stds:CEA-861,DMT,CVT,GTF caps:progressive,reduced-blanking,custom]
> 	pad4: Sink
> 		[dv.caps:BT.656/1120 min:0x0@25000000 max:1920x1200@225000000 stds:CEA-861,DMT,CVT,GTF caps:progressive,reduced-blanking,custom]
> 	pad5: Sink
> 		[dv.caps:BT.656/1120 min:0x0@25000000 max:1920x1200@225000000 stds:CEA-861,DMT,CVT,GTF caps:progressive,reduced-blanking,custom]
> 	pad6: Source
> 		[fmt:RGB888_1X24/1600x1200 field:none colorspace:srgb
> 		 crop.bounds:(0,0)/1600x1200
> 		 crop:(0,0)/1600x1200]
> 		[dv.caps:BT.656/1120 min:0x0@25000000 max:1920x1200@225000000 stds:CEA-861,DMT,CVT,GTF caps:progressive,reduced-blanking,custom]
> 		[dv.query:no-link]
> 		[dv.current:BT.656/1120 1600x1200p60 (2160x1250) stds:DMT flags:]
> 		-> "150c0000.nvcsi--1":0 [ENABLED]
> 
> - entity 35: vi-output, adv7604 32-0020 (1 pad, 1 link)
>              type Node subtype V4L flags 0
>              device node name /dev/video1
> 	pad0: Sink
> 		<- "150c0000.nvcsi--1":1 [ENABLED]

Please find the real time trace log:

root@sds-desktop:/home/sds# cat /sys/kernel/debug/tracing/trace_pipe
  gst-launch-1.0-9368  [000] ....  5101.000877: tegra_channel_close: vi-output, adv7604 30-0020
  gst-launch-1.0-9368  [000] ....  5101.000949: tegra_channel_set_power: adv7604 30-0020 : 0x0
  gst-launch-1.0-9368  [000] ....  5101.000953: tegra_channel_set_power: 150c0000.nvcsi--2 : 0x0
  gst-launch-1.0-9368  [000] ....  5101.000958: csi_s_power: enable : 0x0
  gst-launch-1.0-10356 [000] ....  5102.727617: tegra_channel_open: vi-output, adv7604 30-0020
  gst-launch-1.0-10356 [000] ....  5102.728641: tegra_channel_set_power: adv7604 30-0020 : 0x1
  gst-launch-1.0-10356 [000] ....  5102.728649: tegra_channel_set_power: 150c0000.nvcsi--2 : 0x1
  gst-launch-1.0-10356 [000] ....  5102.728651: csi_s_power: enable : 0x1
  gst-launch-1.0-10356 [000] ....  5102.730323: tegra_channel_close: vi-output, adv7604 30-0020
  gst-launch-1.0-10356 [000] ....  5102.730333: tegra_channel_set_power: adv7604 30-0020 : 0x0
  gst-launch-1.0-10356 [000] ....  5102.730333: tegra_channel_set_power: 150c0000.nvcsi--2 : 0x0
  gst-launch-1.0-10356 [000] ....  5102.730334: csi_s_power: enable : 0x0
  gst-launch-1.0-10356 [000] ....  5102.730621: tegra_channel_open: vi-output, adv7604 32-0020
  gst-launch-1.0-10356 [000] ....  5102.730633: tegra_channel_set_power: adv7604 32-0020 : 0x1
  gst-launch-1.0-10356 [000] ....  5102.730634: tegra_channel_set_power: 150c0000.nvcsi--1 : 0x1
  gst-launch-1.0-10356 [000] ....  5102.730635: csi_s_power: enable : 0x1
  gst-launch-1.0-10356 [000] ....  5102.730661: tegra_channel_close: vi-output, adv7604 32-0020
  gst-launch-1.0-10356 [000] ....  5102.730663: tegra_channel_set_power: adv7604 32-0020 : 0x0
  gst-launch-1.0-10356 [000] ....  5102.730664: tegra_channel_set_power: 150c0000.nvcsi--1 : 0x0
  gst-launch-1.0-10356 [000] ....  5102.730665: csi_s_power: enable : 0x0
  gst-launch-1.0-10356 [004] ....  5102.747569: tegra_channel_open: vi-output, adv7604 30-0020
  gst-launch-1.0-10356 [004] ....  5102.747586: tegra_channel_set_power: adv7604 30-0020 : 0x1
  gst-launch-1.0-10356 [004] ....  5102.747591: tegra_channel_set_power: 150c0000.nvcsi--2 : 0x1
  gst-launch-1.0-10356 [004] ....  5102.747593: csi_s_power: enable : 0x1

I am not able to understand which sensor stream-0 configuration you are talking about. Please explain in detail so that we can debug our problem easily.

Regards
Vikas

hello vikas.wfh,

please refer to Port Index session, it’s related to which CSI port you’re using for the index of the video stream.
there’s no MIPI signaling coming to VI engine according to the tracing logs. please also check Debugging Tips session to examine your sensor drivers.
thanks

Hello JerryChang.

Thanks for your kind suggestions. we are using port 0 and port 2. we also referred Debugging Tips and made changes in driver the driver accordingly:

static const struct camera_common_frmfmt adv7604_frmfmt[] = {
	{{1600, 1200},	adv7604_60fps, 1, 1, ADV7604_MODE_1600X1200},
	{{1024, 768},	adv7604_60fps, 1, 1, ADV7604_MODE_1024X768},
	{{800, 600},	adv7604_60fps, 1, 1, ADV7604_MODE_800X600},
};

Accordingly filling in following functions to for frame size and frame intervals:

	.enum_frame_size = adv7604_enum_framesizes,
	.enum_frame_interval = adv7604_enum_frameintervals,

After doing all this I am still getting following supported formats:

sds@sds-desktop:~$ v4l2-ctl -d /dev/video0 --list-formats-ext
ioctl: VIDIOC_ENUM_FMT
	Index       : 0
	Type        : Video Capture
	Pixel Format: 'AR24'
	Name        : 32-bit BGRA 8-8-8-8

Index       : 1
Type        : Video Capture
Pixel Format: 'UYVY'
Name        : UYVY 4:2:2

Index       : 2
Type        : Video Capture
Pixel Format: 'VYUY'
Name        : VYUY 4:2:2

Index       : 3
Type        : Video Capture
Pixel Format: 'YUYV'
Name        : YUYV 4:2:2

Index       : 4
Type        : Video Capture
Pixel Format: 'YVYU'
Name        : YVYU 4:2:2

Index       : 5
Type        : Video Capture
Pixel Format: 'NV16'
Name        : Y/CbCr 4:2:2

Index       : 6
Type        : Video Capture
Pixel Format: 'YUYV'
Name        : YUYV 4:2:2

Index       : 7
Type        : Video Capture
Pixel Format: 'YVYU'
Name        : YVYU 4:2:2

But when we running following command get fail response for followings

  • VIDIOC_G/S/TRY_EXT_CTRLS: FAIL
  • VIDIOC_ENUM_FMT/FRAMESIZES/FRAMEINTERVALS: FAIL
  • VIDIOC_ENUM/G/S/QUERY_DV_TIMINGS: FAIL
  • VIDIOC_G_FMT: FAIL
  • fail: v4l2-test-formats.cpp(434): pixelformat 33424752 (RGB3) for buftype 1 not reported by ENUM_FMT

sds@sds-desktop:~$ v4l2-compliance -d /dev/video0
v4l2-compliance SHA : not available

Driver Info:
	Driver name   : tegra-video
	Card type     : vi-output, adv7604 30-0020
	Bus info      : platform:15700000.vi:0
	Driver version: 4.9.140
	Capabilities  : 0x84200001
		Video Capture
		Streaming
		Extended Pix Format
		Device Capabilities
	Device Caps   : 0x04200001
		Video Capture
		Streaming
		Extended Pix Format

Compliance test for device /dev/video0 (not using libv4l2):

Required ioctls:
	test VIDIOC_QUERYCAP: OK

Allow for multiple opens:
	test second video open: OK
	test VIDIOC_QUERYCAP: OK
	test VIDIOC_G/S_PRIORITY: OK
	test for unlimited opens: OK

Debug ioctls:
	test VIDIOC_DBG_G/S_REGISTER: OK (Not Supported)
	test VIDIOC_LOG_STATUS: OK

Input ioctls:
	test VIDIOC_G/S_TUNER/ENUM_FREQ_BANDS: OK (Not Supported)
	test VIDIOC_G/S_FREQUENCY: OK (Not Supported)
	test VIDIOC_S_HW_FREQ_SEEK: OK (Not Supported)
	test VIDIOC_ENUMAUDIO: OK (Not Supported)
	test VIDIOC_G/S/ENUMINPUT: OK
	test VIDIOC_G/S_AUDIO: OK (Not Supported)
	Inputs: 1 Audio Inputs: 0 Tuners: 0

Output ioctls:
	test VIDIOC_G/S_MODULATOR: OK (Not Supported)
	test VIDIOC_G/S_FREQUENCY: OK (Not Supported)
	test VIDIOC_ENUMAUDOUT: OK (Not Supported)
	test VIDIOC_G/S/ENUMOUTPUT: OK (Not Supported)
	test VIDIOC_G/S_AUDOUT: OK (Not Supported)
	Outputs: 0 Audio Outputs: 0 Modulators: 0

Input/Output configuration ioctls:
	test VIDIOC_ENUM/G/S/QUERY_STD: OK (Not Supported)
		fail: v4l2-test-io-config.cpp(212): field != V4L2_FIELD_NONE
		fail: v4l2-test-io-config.cpp(253): Timings check failed for input 0.
	test VIDIOC_ENUM/G/S/QUERY_DV_TIMINGS: FAIL
	test VIDIOC_DV_TIMINGS_CAP: OK
	test VIDIOC_G/S_EDID: OK

Test input 0:

	Control ioctls:
		test VIDIOC_QUERY_EXT_CTRL/QUERYMENU: OK
		test VIDIOC_QUERYCTRL: OK
		test VIDIOC_G/S_CTRL: OK
		fail: v4l2-test-controls.cpp(633): did not check against size
		test VIDIOC_G/S/TRY_EXT_CTRLS: FAIL
		test VIDIOC_(UN)SUBSCRIBE_EVENT/DQEVENT: OK
		test VIDIOC_G/S_JPEGCOMP: OK (Not Supported)
		Standard Controls: 10 Private Controls: 14

	Format ioctls:
		fail: v4l2-test-formats.cpp(273): duplicate format 56595559 (YUYV)
		test VIDIOC_ENUM_FMT/FRAMESIZES/FRAMEINTERVALS: FAIL
		test VIDIOC_G/S_PARM: OK (Not Supported)
		test VIDIOC_G_FBUF: OK (Not Supported)
		fail: v4l2-test-formats.cpp(434): pixelformat 33424752 (RGB3) for buftype 1 not reported by ENUM_FMT
		test VIDIOC_G_FMT: FAIL
		test VIDIOC_TRY_FMT: OK (Not Supported)
		test VIDIOC_S_FMT: OK (Not Supported)
		test VIDIOC_G_SLICED_VBI_CAP: OK (Not Supported)
		test Cropping: OK (Not Supported)
		test Composing: OK (Not Supported)

After this when we are checking the kernel log we are getting following kernel crash reported in __tegra_channel_try_format function which is in channel.c

Nov  5 19:17:26 sds-desktop kernel: [  260.679769] Internal error: Accessing user space memory outside uaccess.h routines: 96000005 [#1] PREEMPT SMP
Nov  5 19:17:26 sds-desktop kernel: [  260.689674] Modules linked in: bnep fuse zram uvcvideo overlay bcmdhd mcp251x can_dev cfg80211 nvgpu bluedroid_pm ip_tables x_tables
Nov  5 19:17:26 sds-desktop kernel: [  260.701756] CPU: 4 PID: 9903 Comm: v4l2-compliance Not tainted 4.9.140-tegra-tegra #5
Nov  5 19:17:26 sds-desktop kernel: [  260.709575] Hardware name: quill (DT)
Nov  5 19:17:26 sds-desktop kernel: [  260.713231] task: ffffffc1974e8e00 task.stack: ffffffc127484000
Nov  5 19:17:26 sds-desktop kernel: [  260.719144] PC is at __tegra_channel_try_format+0x44/0x210
Nov  5 19:17:26 sds-desktop kernel: [  260.724618] LR is at __tegra_channel_try_format+0x1f4/0x210
Nov  5 19:17:26 sds-desktop kernel: [  260.730178] pc : [<ffffff8008b2e054>] lr : [<ffffff8008b2e204>] pstate: 60400145
Nov  5 19:17:26 sds-desktop kernel: [  260.737558] sp : ffffffc127487a60
Nov  5 19:17:26 sds-desktop kernel: [  260.740865] x29: ffffffc127487a60 x28: 0000000000000000 
Nov  5 19:17:26 sds-desktop kernel: [  260.746186] x27: ffffffc1eb302030 x26: 0000000000000000 
Nov  5 19:17:26 sds-desktop kernel: [  260.751505] x25: ffffffc11cdb9d80 x24: 0000000000000000 
Nov  5 19:17:26 sds-desktop kernel: [  260.756825] x23: ffffffc15cdd3400 x22: 0000000000000000 
Nov  5 19:17:26 sds-desktop kernel: [  260.760050] x21: ffffffc1eb302018 
Nov  5 19:17:26 sds-desktop kernel: [  260.760051] x20: ffffffc1e97f5888 x19: ffffffc15cdd3408 x18: 0000007ff8c6e697 
Nov  5 19:17:26 sds-desktop kernel: [  260.760056] x17: 0000000000000000 x16: 0000000000000000 
Nov  5 19:17:26 sds-desktop kernel: [  260.760058] x15: 000000000000000a x14: 0000000000000000 
Nov  5 19:17:26 sds-desktop kernel: [  260.760060] x13: 0000000000000000 x12: 0000000000000006 
Nov  5 19:17:26 sds-desktop kernel: [  260.760062] x11: 0000000000000000 x10: 0000000000000498 
Nov  5 19:17:26 sds-desktop kernel: [  260.760064] x9 : 0000000000000001 x8 : ffffffc1f67d7dd3 
Nov  5 19:17:26 sds-desktop kernel: [  260.760066] x7 : 0000000000000000 x6 : ffffffc1f7097bf0 
Nov  5 19:17:26 sds-desktop kernel: [  260.760068] x5 : ffffffc1f7097bf0 x4 : 0000000055595659 
Nov  5 19:17:26 sds-desktop kernel: [  260.760070] x3 : ffffffc1eb3028d8 x2 : ffffffc1eb3028d8 
Nov  5 19:17:26 sds-desktop kernel: [  260.760072] x1 : 0000000042474752 x0 : 0000000000000000 
Nov  5 19:17:26 sds-desktop kernel: [  260.760072] 
Nov  5 19:17:26 sds-desktop kernel: [  260.760074] Process v4l2-compliance (pid: 9903, stack limit = 0xffffffc127484000)
Nov  5 19:17:26 sds-desktop kernel: [  260.760076] Call trace:
Nov  5 19:17:26 sds-desktop kernel: [  260.760080] [<ffffff8008b2e054>] __tegra_channel_try_format+0x44/0x210
Nov  5 19:17:26 sds-desktop kernel: [  260.760082] [<ffffff8008b2e2a0>] tegra_channel_set_format+0x40/0x1b8
Nov  5 19:17:26 sds-desktop kernel: [  260.760086] [<ffffff8008b08c54>] v4l_s_fmt+0x4cc/0x540
Nov  5 19:17:26 sds-desktop kernel: [  260.760089] [<ffffff8008b07994>] __video_do_ioctl+0x204/0x2c8
Nov  5 19:17:26 sds-desktop kernel: [  260.760091] [<ffffff8008b07340>] video_usercopy+0x2a0/0x6a0
Nov  5 19:17:26 sds-desktop kernel: [  260.760093] [<ffffff8008b0777c>] video_ioctl2+0x3c/0x50
Nov  5 19:17:26 sds-desktop kernel: [  260.760095] [<ffffff8008b012b0>] v4l2_ioctl+0x88/0x118
Nov  5 19:17:26 sds-desktop kernel: [  260.760099] [<ffffff8008273170>] do_vfs_ioctl+0xb0/0x8d8
Nov  5 19:17:26 sds-desktop kernel: [  260.760101] [<ffffff8008273a24>] SyS_ioctl+0x8c/0xa8
Nov  5 19:17:26 sds-desktop kernel: [  260.760104] [<ffffff80080838c0>] el0_svc_naked+0x34/0x38
Nov  5 19:17:26 sds-desktop kernel: [  260.760107] ---[ end trace d4a7f59d6a971c14 ]---

I am not able to understand why kernel is getting crashed at this point and getting fail responses for above mentioned V4L2 IOCTLs. Please guide me to resolve this issue.

Thanks & Regards
Vikas Dwivedi

hello vikas.wfh,

may I know why you got some many pixel formats reported by v4l2-ctl -d /dev/video0 --list-formats-ext,
there’s also a duplicate pixel format, (i.e. index-3 YUYV and index-6 YUYV).

it’s VI driver to determine buffer types by checking the pixel formats and also sensor capability you’d report in the sensor device tree.
please also examine your sensor device tree property settings, you may compare it with the reference driver (i.e. imx185).
thanks

Hello Jerrychang,

We have taken the reference of TC358840 (HDMI to CSI converter). We are getting multiple pixel formats because for 6 sink pad and 1 source pad in our ADV7604.

Here is my device tree, please review it and correct me I have done some mistake in writing device tree:

	i2c@3180000 {       //set this to correct i2c bus
        tca9546@70 {
            i2c@2 {
                #address-cells = <1>;
                #size-cells = <0>;
     			adv7604_c@20 { 
					compatible = "adi,adv7604";
					reset-gpios = <&gpio_i2c_0_74 1 GPIO_ACTIVE_HIGH>;
					
					interrupt-gpio = <&gpio_i2c_0_74 0 GPIO_ACTIVE_HIGH>;

		      		reg = <0x20>; /*<0x42>, <0x40>, <0x3e>, <0x38>, <0x3c>, <0x26>, <0x32>, <0x36>, <0x34>, <0x30>, <0x22>, <0x24>;*/
					//reg-names = "io", "avlink", "cec", "infoframe", "esdp", "epp", "afe", "rep", "edid", "hdmi", "test", "cp", "vdp"; 
                    devnode = "video1"; 

					single-source-max-width = "1920";
					mclk = "extperiph2";

					vif-supply = <&en_vdd_cam>;
					vdig-supply = <&en_vdd_cam_1v2>;
					refclk_hz = <162000000>; /* 40 - 50 MHz */

					ddc5v_delay = <1>;        /* 50 ms */

					/* HDCP */
					/* TODO: Not yet implemented */
					enable_hdcp = <0>;

					/* CSI Output */
					csi_port = <3>;            /* Enable TX0 and TX1 */

					lineinitcnt = <0x00000FA0>;
					lptxtimecnt = <0x00000004>;
					tclk_headercnt = <0x00180203>;
					tclk_trailcnt = <0x00040005>;
					ths_headercnt = <0x000D0004>;
					twakeup = <0x00003E80>;
					tclk_postcnt = <0x0000000A>;
					ths_trailcnt = <0x00080006>;
					hstxvregcnt = <0x00000020>;
					btacnt = <0>;


					default-input = <0>;
			
                    ports {
                        #address-cells = <1>;
                        #size-cells = <0>;

                        port@0 {
                            reg = <0>;
                        };

						port@1 {
                            reg = <1>;
                        };

						port@2 {
                            reg = <2>;
                        };

						port@3 {
                            reg = <3>;
                        };

						port@4 {

                        };

						port@5 {
                            reg = <5>;
                        };

						port@6 {
                            reg = <0>;
                            adv7604_out2: endpoint@6 {
								status = "okay";
                                port-index = <2>;
                                bus-width = <4>;
                                remote-endpoint = <&adv7604_csi_in1>;
                            };
                        };
                    };
                };
            };

Here you can find the driver my device driver. Reference I have taken for device tree from here.

Shall I add all the properties in device tree required for sensor common and camera common drivers? Because I have added some properties from TC358840 device tree.

Please guide us to debug in which particular section of VI driver it looks for pixel formats and buffer types.

Thanks & Regards,
Vikas Dwivedi

hello vikas.wfh,

were you also working with a HDMI to CSI bridge driver?
please also check developer guide, you may check Port Binding for the node definitions of VI, NvCSI, and sensor modules.
thanks

Hi JerryChang,

We are not working on HDMI to CSI bridge Driver though our requirement is very similar.

In our Architecture we have ADV7604 which converts analog VGA to parallel VGA in 24-bit RGB format. This parallel output is given to FPGA. This FPGA converts the parallel data into CSI format and is connected to CSI interface of TX2. Our FPGA is non-programmable.

ADV7604 has a driver based on V4l2 , but FPGA does not have any driver.

I have take reference of TC358840 device tree. which output is directly connected to CSI. Should I take reference of TC358840 as our usage scenario may be little different ? It is possible that we use TC358840 but modify it to reflect our architecture. What would be the changes at device tree and device driver level ?

We have ported our ADV7604 driver according to TC358840, but we have not use all the functions as our chip set is different. The driver is probed successfully but it seems like there is no connection between ADV7604.parallel output & CSI input of TX2 as FPGA is coming in between. We think that we have not handled this aspect properly in our device driver and/or device tree.

Please suggest approach for our architecture.

Regards,
VIkas

hello vikas.wfh,

may I know which JetPack release version you’re working with.

may I have more details about what’s “parallel VGA”.

you may access L4T sources package and check the VI driver.
there’s camera_common_colorfmt to define default support pixel format types.
for example,
$L4T_Sources/r32.4.3/Linux_for_Tegra/source/public/kernel/nvidia/drivers/media/platform/tegra/camera/camera_common.c

FYI,
VI driver did not support RGB888 memory formats,
please check similar discussion thread, Topic 108194, and Topic 74804 for reference.

is it possible to probe the MIPI signaling, or, enable the test-pattern-generator to ensure the connections?
by checking the output signal of ADV7604 or FPGA would be helpful for issue narrow down.

Hi JerryChang,

We are using JetPack release 4.2.2 .

“parallel VGA” :- Parallel RGB888 24-bit Data.

Also, we know that VI does not support RGB888 24-bit format. VI only support 16/32 -bit memory formats. Correct me if i am wrong.

We have checked the output signal of ADV7604 and it is working fine.

NVcsi supports RGB888 as per TRM. CSI to VI it will convert the RGB888 24-bit format to RGB8888 32-bit memory format of VI.

ADV7604 driver will program ADV7604 chip and there is no direct link between ADV7604 and CSI also we have to tell CSI some way that it is getting RGB888 (CSI memory format) serial Data from FPGA.

I am Attaching my ADV7604 Driver. can you look at it and tell me what changes or any refrance i can take and port my driver according to that.
adv7604.c (116.6 KB)
Regards,
Vikas

hello vikas.wfh,

please try to resolve kernel panic by revise your duplicate pixel format definitions,
you may also refer to https://elinux.org/Jetson_TX2_Camera_BringUp for debug tips, and also steps to enable more debug logs.
thanks

Hi Jerry Chang,

Thanks for your reply.

We are looking into the Kernel panic problem mentioned in the previous post due to duplicate pixel format. We are already using Trace log tips as suggested by you. But we are not getting any information in that.

We are having another problem regarding communication of our driver to CSI and VI modules.

So, now we trying to understand how TC358840 driver is linked to NVCSI and VI. Please guide us in this regard.

Regards,
Vikas

hello vikas.wfh,

just consider it as same as CSI bayer sensors. the pipeline line should be…

TC358840 --> NVCSI --> VI

BTW,
you may also found that TC358840 were using 8-lane configuration, i.e. bus-width = <8>;
according to Port Index, each CSI brick only able to support 4-lane configuration.
it’s VI driver to receive sensor signal from two CSI brick and handle the gang mode combination for further usage.
for example,
$L4T_Sources/r32.4.3/Linux_for_Tegra/source/public/kernel/nvidia/drivers/media/platform/tegra/camera/vi/channel.c

static void update_gang_mode(struct tegra_channel *chan)
{
...
        if ((width > 1920) && (height > 1080)) {
                chan->gang_mode = CAMERA_GANG_L_R;
                chan->valid_ports = chan->total_ports;
...

Hello JerryChang,

Thank you for letting us know about the gang mode as we were wondering how 8 lane mode was being used.

While we are trying to resolve duplicate pixel format problem we observed another thing in the reference device tree: sources/hardware/nvidia/platform/t18x/quill/kernel-dts/quill-modules/tegra186-camera-imx274.dtsi that the following section only includes imx270 sensor camera module, TC358840 is not added.

tegra-camera-platform {
		compatible = "nvidia, tegra-camera-platform";
		
		num_csi_lanes = <4>;
		max_lane_speed = <1500000>;
		min_bits_per_pixel = <10>;
		vi_peak_byte_per_pixel = <2>;
		vi_bw_margin_pct = <25>;
		max_pixel_rate = <750000>;
		isp_peak_byte_per_pixel = <2>;
		isp_bw_margin_pct = <25>;

		modules {
			module0 {
				badge = "imx274_front_A6V24";
				position = "rear";
				status = "okay";
				orientation = "1";
				drivernode0 {
					/* Declare PCL support driver (classically known as guid)  */
					pcl_id = "v4l2_sensor";
					devname = "imx274 2-001a";
					status = "okay";
					/* Declare the device-tree hierarchy to driver instance */
					proc-device-tree = "/proc/device-tree/i2c@3180000/imx274_a@1a";
				};
			};
		};

As per our understanding IMX270 is included in tegra-camera-platform because it requires ISP and further processing but TC358840 does not requires ISP processing. So it is not included in tegra-camera-platform.

We have the case in our system architecture where TC358840 is present and IMX270 is not present. Further we are following direct V4L2 interface camera programming path where ISP support is not available, not the Camera Core Library Interface path. Hence we have commented complete tegra-camera-platform section. Is our understanding is correct? Or there is some dependency on NVCSI and VI even for non ISP operations.

But after disabling tegra-camera-platform kernel is getting crashed and the log is as follows:

[   16.316597] registered taskstats version 1
[   16.325159] isp 15600000.isp: initialized
[   16.330263] isp 15600000.isp: isp_probe: failed
[   16.335873] isp: probe of 15600000.isp failed with error -22
[   16.347190] nvcsi 150c0000.nvcsi: initialized
[   16.352576] PD: inside tegra_csi_channel_init_one
[   16.358344] PD:numports:1
[   16.358344] 
PD: inside tegra_csi_channel_init_one
[   16.368933] PD:numports:1
[   16.368933] 
[   16.375148] nvcsi: probe of 150c0000.nvcsi failed with error -22
[   16.386894] gpio tegra-gpio-aon wake29 for gpio=56(FF:0)
[   16.388859] tegra-vi4 15700000.vi: initialized
[   16.389883]  VD: inside tegra_channel_fmt_align
[   16.389957]  VD: inside tegra_channel_fmt_align
[   16.389958] Unable to handle kernel read from unreadable memory at virtual address 00000000
[   16.389960] Mem abort info:
[   16.389971]   ESR = 0x96000005
[   16.389974]   Exception class = DABT (current EL), IL = 32 bits
[   16.389976]   SET = 0, FnV = 0
[   16.389978]   EA = 0, S1PTW = 0
[   16.389980] Data abort info:
[   16.389982]   ISV = 0, ISS = 0x00000005
[   16.389984]   CM = 0, WnR = 0
[   16.389987] [0000000000000000] user address but active_mm is swapper
[   16.389996] Internal error: Oops: 96000005 [#1] PREEMPT SMP
[   16.390002] Modules linked in:
[   16.390008] CPU: 1 PID: 1489 Comm: kworker/u12:9 Not tainted 4.9.140-tegra-tegra #28
[   16.390010] Hardware name: quill (DT)
[   16.390039] Workqueue: events_unbound async_run_entry_fn
[   16.390043] task: ffffffc1ebe1e200 task.stack: ffffffc1e6818000
[   16.390050] PC is at v4l2_async_notifier_register+0x130/0x198
[   16.390054] LR is at v4l2_async_notifier_register+0x114/0x198
[   16.390057] pc : [<ffffff8008b15708>] lr : [<ffffff8008b156ec>] pstate: 60400045
[   16.390060] sp : ffffffc1e681ba60
[   16.390070] x29: ffffffc1e681ba60 x28: 0000000000000000 
[   16.390078] x27: 0000000000000000 x26: ffffffc1e97fcf58 
[   16.390083] x25: 00000000024080c0 x24: 0000000000000000 
[   16.390088] x23: ffffff8009fd0000 x22: ffffff8009fd02c0 
[   16.390092] x21: ffffffc1e4d0c428 x20: fffffffffffffef0 
[   16.390097] x19: ffffffc1e97fcef8 x18: 0000000000000000 
[   16.390101] x17: 0000000000000000 x16: 0000000000000000 
[   16.390106] x15: ffffffffffffffff x14: ffffffc1e97fd538 
[   16.390110] x13: ffffffc1e97fd52c x12: ffffff8009e84000 
[   16.390115] x11: 0000000000000038 x10: 0101010101010101 
[   16.390120] x9 : 0000000000000008 x8 : ffffffc1e4cc25c0 
[   16.390124] x7 : 0000000000000000 x6 : 0000000000000020 
[   16.390130] x5 : ffffffc1ebe1e200 x4 : ffffffc1e97fcf10 
[   16.390134] x3 : ffffffc1e4d0c938 x2 : 0000000000000000 
[   16.390141] x1 : ffffffc1e4c7f2b8 x0 : 0000000000000000 
[   16.390143] 
[   16.390145] Process kworker/u12:9 (pid: 1489, stack limit = 0xffffffc1e6818000)
[   16.390148] Call trace:
[   16.390153] [<ffffff8008b15708>] v4l2_async_notifier_register+0x130/0x198
[   16.390159] [<ffffff8008b32b00>] tegra_vi_graph_init+0x228/0x278
[   16.390178] [<ffffff8008b2c948>] tegra_vi_media_controller_init+0x1d0/0x208
[   16.390184] [<ffffff800855df34>] tegra_vi4_probe+0x244/0x380
[   16.390191] [<ffffff800876f7d8>] platform_drv_probe+0x60/0xc0
[   16.390207] [<ffffff800876ce58>] driver_probe_device+0xd8/0x408
[   16.390212] [<ffffff800876d264>] __driver_attach+0xdc/0x128
[   16.390216] [<ffffff800876a8d4>] bus_for_each_dev+0x5c/0xa8
[   16.390220] [<ffffff800876c658>] driver_attach+0x30/0x40
[   16.390240] [<ffffff800876ae90>] driver_attach_async+0x20/0x60
[   16.390244] [<ffffff80080dfc48>] async_run_entry_fn+0x48/0x158
[   16.390251] [<ffffff80080d4f3c>] process_one_work+0x1e4/0x4b0
[   16.390258] [<ffffff80080d5258>] worker_thread+0x50/0x4c8
[   16.390263] [<ffffff80080dbee4>] kthread+0xec/0xf0
[   16.390268] [<ffffff8008083850>] ret_from_fork+0x10/0x40    tegra-camera-platform {
        compatible = "nvidia, tegra-camera-platform";
  
        num_csi_lanes = <8>;
        max_lane_speed = <1500000>;
        min_bits_per_pixel = <8>; /* VD: ?*/
        vi_peak_byte_per_pixel = <2>;
        vi_bw_margin_pct = <25>;
        max_pixel_rate = <750000>; /* VD: ?*/
        isp_peak_byte_per_pixel = <5>;
        isp_bw_margin_pct = <25>;

        modules {

           module1 {
                badge = "adv7604_top_c";
                position = "top";
                orientation = "1";
                status = "okay";
                drivernode0 {
                status = "okay";
                    pcl_id = "v4l2_sensor";
                    devname = "adv7604 32-0020";
                    proc-device-tree = "/proc/device-tree/i2c@3180000/tca9546@70/i2c@2/adv7604_c@20";
                };
            };

            module0 {
                badge = "adv7604_bottom_a";
                position = "bottom";
                orientation = "0";
                status = "okay";
                drivernode0 {
                    status = "okay";
                    pcl_id = "v4l2_sensor";
                    devname = "adv7604 30-0020";
                    proc-device-tree = "/proc/device-tree/i2c@3180000/tca9546@70/i2c@0/adv7604_a@20";
                };
            };
        };
    };
[   16.390273] ---[ end trace fdea460159e45c9e ]---
[   16.399464] Unable to handle kernel paging request at virtual address ffffffffffffffd8
[   16.399466] Mem abort info:
[   16.399473]   ESR = 0x96000005
[   16.399475]   Exception class = DABT (current EL), IL = 32 bits
[   16.399477]   SET = 0, FnV = 0
[   16.399479]   EA = 0, S1PTW = 0
[   16.399480] Data abort info:
[   16.399482]   ISV = 0, ISS = 0x00000005
[   16.399483]   CM = 0, WnR = 0
[   16.399486] swapper pgtable: 4k pages, 39-bit VAs, pgd = ffffff800a1d4000
[   16.399492] [ffffffffffffffd8] *pgd=0000000000000000, *pud=0000000000000000
[   16.399500] Internal error: Oops: 96000005 [#2] PREEMPT SMP
[   16.399503] Modules linked in:
[   16.399508] CPU: 1 PID: 1489 Comm: kworker/u12:9 Tainted: G      D         4.9.140-tegra-tegra #28
[   16.399510] Hardware name: quill (DT)
[   16.399530] task: ffffffc1ebe1e200 task.stack: ffffffc1e6818000
[   16.399534] PC is at kthread_data+0x24/0x30
[   16.399538] LR is at wq_worker_sleeping+0x20/0xd0
[   16.399541] pc : [<ffffff80080dcad4>] lr : [<ffffff80080d6380>] pstate: 804000c5
[   16.399543] sp : ffffffc1e681b660
[   16.399548] x29: ffffffc1e681b660 x28: ffffffc1ebe1e200 
[   16.399553] x27: ffffffc1ecb30000 x26: 0000000000000000 
[   16.399557] x25: ffffff80080ec17c x24: ffffffc1f7056cc0 
[   16.399562] x23: ffffffc1ebe1e8c8 x22: ffffff8009825000 
[   16.399566] x21: ffffff8009e68000 x20: ffffff8009832000 
[   16.399571] x19: ffffffc1ebe1e200 x18: 000000000000001e 
[   16.399575] x17: 0000000000000000 x16: 0000000000000000 
[   16.399579] x15: 0000000000000000 x14: 0000000000000019 
[   16.399583] x13: 0000000000000033 x12: 000000000000004c 
[   16.399587] x11: 0000000000000068 x10: 0000000000000031 
[   16.399592] x9 : 0000000000000000 x8 : 0000000000000400 
[   16.399596] x7 : 0000000000000000 x6 : 0000000000000400 
[   16.399601] x5 : 000000000000c400 x4 : 0000000000bd8370 
[   16.399606] x3 : 0000000000000000 x2 : 000000016f2e94ee 
[   16.399610] x1 : ffffffc1f7056cc0 x0 : 0000000000000000 
[   16.399611] 
[   16.399614] Process kworker/u12:9 (pid: 1489, stack limit = 0xffffffc1e6818000)
[   16.399616] Call trace:
[   16.399621] [<ffffff80080dcad4>] kthread_data+0x24/0x30
[   16.399629] [<ffffff8008f50088>] __schedule+0x418/0x780
[   16.399634] [<ffffff80080ec17c>] do_task_dead+0x74/0x78
[   16.399639] [<ffffff80080b9aa8>] do_exit+0x6f8/0xa08
[   16.399647] [<ffffff800808c528>] bug_handler.part.2+0x0/0x88
[   16.399653] [<ffffff80080a31fc>] __do_kernel_fault.isra.1+0x144/0x218
[   16.399656] [<ffffff80080a3408>] do_page_fault+0x60/0x518
[   16.399661] [<ffffff80080a392c>] do_translation_fault+0x6c/0x80
[   16.399664] [<ffffff8008080954>] do_mem_abort+0x54/0xb0
[   16.399668] [<ffffff8008082904>] el1_da+0x24/0xb4
[   16.399672] [<ffffff8008b32b00>] tegra_vi_graph_init+0x228/0x278
[   16.399677] [<ffffff8008b2c948>] tegra_vi_media_controller_init+0x1d0/0x208
[   16.399682] [<ffffff800855df34>] tegra_vi4_probe+0x244/0x380
[   16.399688] [<ffffff800876f7d8>] platform_drv_probe+0x60/0xc0
[   16.399692] [<ffffff800876ce58>] driver_probe_device+0xd8/0x408
[   16.399696] [<ffffff800876d264>] __driver_attach+0xdc/0x128
[   16.399700] [<ffffff800876a8d4>] bus_for_each_dev+0x5c/0xa8
[   16.399704] [<ffffff800876c658>] driver_attach+0x30/0x40
[   16.399707] [<ffffff800876ae90>] driver_attach_async+0x20/0x60
[   16.399712] [<ffffff80080dfc48>] async_run_entry_fn+0x48/0x158
[   16.399718] [<ffffff80080d4f3c>] process_one_work+0x1e4/0x4b0
[   16.399722] [<ffffff80080d5258>] worker_thread+0x50/0x4c8
[   16.399726] [<ffffff80080dbee4>] kthread+0xec/0xf0
[   16.399729] [<ffffff8008083850>] ret_from_fork+0x10/0x40
[   16.399733] ---[ end trace fdea460159e45c9f ]---
[   16.408841] Fixing recursive fault but reboot is needed!

If keeping our driver node in tegra-camera-platform as follows then kernel is not getting crashed but getting earlier duplicate pixel format issue. Could inclusion of tegra-camera-platform be the reason of duplicate pixel format issue?

tegra-camera-platform {
        compatible = "nvidia, tegra-camera-platform";
  
        num_csi_lanes = <8>;
        max_lane_speed = <1500000>;
        min_bits_per_pixel = <8>;
        vi_peak_byte_per_pixel = <2>;
        vi_bw_margin_pct = <25>;
        max_pixel_rate = <750000>; 
        isp_peak_byte_per_pixel = <5>;
        isp_bw_margin_pct = <25>;

        modules {

           module1 {
                badge = "adv7604_top_c";
                position = "top";
                orientation = "1";
                status = "okay";
                drivernode0 {
                status = "okay";
                    pcl_id = "v4l2_sensor";
                    devname = "adv7604 32-0020";
                    proc-device-tree = "/proc/device-tree/i2c@3180000/tca9546@70/i2c@2/adv7604_c@20";
                };
            };

            module0 {
                badge = "adv7604_bottom_a";
                position = "bottom";
                orientation = "0";
                status = "okay";
                drivernode0 {
                    status = "okay";
                    pcl_id = "v4l2_sensor";
                    devname = "adv7604 30-0020";
                    proc-device-tree = "/proc/device-tree/i2c@3180000/tca9546@70/i2c@0/adv7604_a@20";
                };
            };
        };
    };

I am not able to understand why NVCSI and VI is not getting probed. Is it because of tegra-camera-platform changes in device tree.

Regards,
Vikas

Hello JerryChang,

We have referred suggested link and tried to enable trace for more information but no luck. But we are able to see real time log by following command.

$ cat /sys/kernel/debug/tracing/trace_pipe

Please let me know why we are not able to see the trace log?

Regards,
Vikas

hello vikas.wfh,

FYI,
there’re several camera device definition included in the device tree.
you may also check Device Registration session, it’s plugin manager to register device by checking onboard EEPROM when system kernel boots.

you may check the documentation for TC358840’s device tree description,
for example,
$L4T_Sources/r32.4.3/Linux_for_Tegra/source/public/kernel/nvidia/Documentation/devicetree/bindings/media/i2c/tc358840.txt