ADV7282A-M configuration


I have a ADV7282A-M chip on a custom TX2i-based board, and I have some issues configuring it.
I have modified the adv7180.c driver to integrate the latest fixes from mainline, as well as some changes shown in this post, then I’ve taken snippets from other posts on the subject to write the dts entries.
When the system boots, it correctly detects the video chip:

$ dmesg | grep adv
[    1.185839] adv7180 0-0021: adv7182_init: I2P init
[    1.186614] adv7180 0-0021: adv7182_init: change to color bar
[    1.186813] adv7180 0-0021: adv7180_set_field_mode: disable I2P
[    1.187879] adv7180 0-0021: chip found @ 0x21 (3160000.i2c)
[    1.407564] tegra-vi4 subdev adv7180 0-0021 bound
[    1.407731] adv7180 0-0021: adv7180_mbus_fmt: w=720, h=240
[    3.346003] adv7180 0-0021: adv7180_mbus_fmt: w=720, h=240
[    3.398513] adv7180 0-0021: adv7180_set_power: 1
[    3.416612] adv7180 0-0021: adv7180_set_power: 0

and the /dev/video0 device is created.
However, any operation results in the kernel throwing me errors, for instance:
gst-launch-1.0 -v v4l2src ! 'video/x-raw, framerate=(fraction)30/1' ! nvoverlaysink
(taken from a similar post) results in:

adv7180 0-0021: adv7180_set_power: 1
adv7180 0-0021: NTSC detected
adv7180 0-0021: adv7180_mbus_fmt: w=720, h=240
adv7180 0-0021: adv7180_mbus_fmt: w=720, h=240
adv7180 0-0021: adv7180_mbus_fmt: w=720, h=240
adv7180 0-0021: adv7180_set_power: 0
adv7180 0-0021: adv7180_set_field_mode: enable I2P
adv7180 0-0021: adv7180_set_power: 1
adv7180 0-0021: adv7180_mbus_fmt: w=720, h=480
Unable to handle kernel read from unreadable memory at virtual address 000000a0
Mem abort info:
  ESR = 0x96000005
  Exception class = DABT (current EL), IL = 32 bits
  SET = 0, FnV = 0
  EA = 0, S1PTW = 0
Data abort info:
  ISV = 0, ISS = 0x00000005
  CM = 0, WnR = 0
user pgtable: 4k pages, 39-bit VAs, pgd = ffffffc1986d7000
[00000000000000a0] *pgd=0000000000000000, *pud=0000000000000000
Internal error: Oops: 96000005 [#1] PREEMPT SMP
Modules linked in: overlay qcserial usb_wwan zram spidev nvgpu bluedroid_pm ip_tables x_tables
CPU: 4 PID: 6612 Comm: vi-output, adv7 Not tainted 4.9.140-tegra #33
Hardware name: storm (DT)
task: ffffffc1acb1d400 task.stack: ffffffc1a2a48000
PC is at tegra_camera_update_clknbw+0x28/0x2a8
LR is at tegra_channel_set_stream+0x1a8/0x4f0
pc : [<ffffff8008535510>] lr : [<ffffff8008b683d0>] pstate: 20400045
sp : ffffffc1a2a4bcd0
x29: ffffffc1a2a4bcd0 x28: ffffffc1a8a1a018 
x27: ffffffc1a8a1a818 x26: ffffff800a1a6b10 
x25: 0000000000000001 x24: 0000000000000001 
x23: ffffffc1a8a1a018 x22: 0000000000000000 
x21: 0000000000000001 x20: 0000000000000000 
x19: ffffffc1a8a1a018 x18: 0000000000000154 
x17: 0000000000000005 x16: 0000000000000000 
x15: 0000000000000000 x14: 000000000137e445 
x13: 0000000000000f21 x12: 071c71c71c71c71c 
x11: 000000000000000b x10: 0000000000000a10 
x9 : ffffffc1a2a4bd70 x8 : ffffffc1acb1de70 
x7 : fefefeff646c606d x6 : 0000000059565955 
x5 : 00000000000100f0 x4 : 00000000000100f8 
x3 : ffffff800d5100f0 x2 : 0000000000010100 
x1 : 0000000000000001 x0 : 0000000000000000 

Process vi-output, adv7 (pid: 6612, stack limit = 0xffffffc1a2a48000)
Call trace:
[<ffffff8008535510>] tegra_camera_update_clknbw+0x28/0x2a8
[<ffffff8008b683d0>] tegra_channel_set_stream+0x1a8/0x4f0
[<ffffff8008b6e99c>] tegra_channel_kthread_capture_start+0x2dc/0x548
[<ffffff80080dbe64>] kthread+0xec/0xf0
[<ffffff80080838a0>] ret_from_fork+0x10/0x30
---[ end trace 6c675dfdf6fddb78 ]---

The decompiled DTB is attached.

Could you please help me figure out what’s wrong?
Thanks in advance!

decompiled_dtb.txt (304.2 KB)

hello rob7989,

there’s invalid memory access to cause kernel panic failures, I cannot find your sensor mode definition according to your decompiled DTB files,
since there’re necessary properties for stream initialization. you may also refer to Individual Imaging Device session for reference.

Dear JerryChang,

Thanks for your reply!
I’ve figured out (with printk()s) what’s the problem just minutes ago: in my DT I was using "nvidia,tegra-camera-platform" as compatible (without spaces), but the tegra camera platform driver requires a space after the comma (I was not aware that it was so important! I just assumed that spaces were ignored…). As a result, the camera probe() was not called and this resulted in the panic… :S
Now I have other errors due to issues from the DT, as you’ve pointed out. I’ll try to fix them myself and eventually post a follow-up!

Thanks again and have a nice day!


I’ve tried playing a bit with the DT, in particular I’ve copied the imx185 camera config and adapted to my chip. From other threads, I’ve figured out that I shouldn’t add a mode node, since the chip is only acting as a bridge.
I’ve commented out the config in tegra186-quill-camera-modules.dtsi and in tegra186-quill-camera-plugin-manager.dtsi, since I am enabling the nodes by hand in my camera’s dtsi file. The resulting decompiled DTB is in attachment.

When I issue a:
v4l2-ctl -d /dev/video0 -w --verbose --set-fmt-video=width=720,height=240,pixelformat=UYVY --stream-mmap --stream-count=30 --stream-to=test.raw
command (taken from another post), in /var/log/syslog I have:

[   50.258488] adv7180 0-0021: adv7180_set_power: 1
[   50.422287] adv7180 0-0021: NTSC detected
[   50.424122] adv7180 0-0021: adv7180_mbus_fmt: w=720, h=240
[   50.424168] adv7180 0-0021: adv7180_mbus_fmt: w=720, h=240
[   50.424183] adv7180 0-0021: adv7180_mbus_fmt: w=720, h=240
[   50.530288] adv7180 0-0021: video signal lost
[   50.742045] tegra-vi4 PXL_SOF syncpt timeout! err = -11
[   50.748512] tegra-vi4 tegra_channel_error_recovery: attempting to reset the capture channel
[   50.962040] tegra-vi4 PXL_SOF syncpt timeout! err = -11
[   50.968550] tegra-vi4 tegra_channel_error_recovery: attempting to reset the capture channel
[   51.182030] tegra-vi4 PXL_SOF syncpt timeout! err = -11
[   51.188513] tegra-vi4 tegra_channel_error_recovery: attempting to reset the capture channel
[   51.402026] tegra-vi4 PXL_SOF syncpt timeout! err = -11
[   51.408491] tegra-vi4 tegra_channel_error_recovery: attempting to reset the capture channel
[   51.622025] tegra-vi4 PXL_SOF syncpt timeout! err = -11
[   51.628486] tegra-vi4 tegra_channel_error_recovery: attempting to reset the capture channel
[   51.842147] tegra-vi4 PXL_SOF syncpt timeout! err = -11
[   51.848656] tegra-vi4 tegra_channel_error_recovery: attempting to reset the capture channel
[   51.860900] adv7180 0-0021: adv7180_set_power: 0

(I stop the execution with CTRL+C, otherwise the error stream would continue).

Do you have any pointer for me, please? I am a bit lost :-/

Thanks a lot in advance!

decompiled_dtb.txt (304.4 KB)

hello rob7989,

VI engine did not receive expect start-of-frame (i.e. SOF) signaling according to those VI errors,
for example,

since you’re having this chip act as bridge driver.
is it possible to enable test-pattern-generate from the bridge side to produce frames for issue narrow down?

Hello JerryChang,

A test pattern is generated by the ADV7282A-M, but even giving an input pattern via a generator I have no change in the behavior.
I have measured the signals with an oscilloscope and apparently the clock lines are not properly terminated by the Jetson, and I’m stuck in the same situation described here. Checking the content of the ADV7282A-M register 0x0F returned the same value (0x04) that the linked post.

I am using a single line, and I have specified this in the device tree, but is there anything else to specify in order to make the Jetson understand that I’m on the line 0? Could this be the problem?

From what I’ve seen, it really looks like that the Jetson cannot sense the incoming signal correctly, and thus adapt the terminations to make the clock (and, I guess, the data) lines compliant…

Thanks again!

hello rob7989,

VI engine expect the coming signaling follow as SoF/EoF/…EoF continuously.
it’ll also check the device tree property settings to allocate the software buffers, you must configure these values correctly as the signaling reports.
please enable the VI tracing logs from debugfs to gather more details.
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
cat /sys/kernel/debug/tracing/trace

Hello JerryChang,

The traces (even before I start using /dev/video0) are full of messages like

# tracer: nop
# entries-in-buffer/entries-written: 414/414   #P:4
#                              _-----=> irqs-off
#                             / _----=> need-resched
#                            | / _---=> hardirq/softirq
#                            || / _--=> preempt-depth
#                            ||| /     delay
#           TASK-PID   CPU#  ||||    TIMESTAMP  FUNCTION
#              | |       |   ||||       |         |
     kworker/5:3-3758  [005] ....    90.290178: rtos_queue_peek_from_isr_failed: tstamp:2959880745 queue:0x0b4b5f58
     kworker/5:3-3758  [005] ....    90.402202: rtos_queue_peek_from_isr_failed: tstamp:2964880737 queue:0x0b4b5f58
     kworker/5:3-3758  [005] ....    90.570137: rtos_queue_peek_from_isr_failed: tstamp:2969880717 queue:0x0b4b5f58
     kworker/5:3-3758  [005] ....    90.738107: rtos_queue_peek_from_isr_failed: tstamp:2974880713 queue:0x0b4b5f58
     kworker/5:3-3758  [005] ....    90.906059: rtos_queue_peek_from_isr_failed: tstamp:2979880706 queue:0x0b4b5f58
     kworker/5:3-3758  [005] ....    91.241978: rtos_queue_peek_from_isr_failed: tstamp:2989880701 queue:0x0b4b5f58
     kworker/5:3-3758  [005] ....    91.409916: rtos_queue_peek_from_isr_failed: tstamp:2994880695 queue:0x0b4b5f58
     kworker/5:3-3758  [005] ....    91.521893: rtos_queue_peek_from_isr_failed: tstamp:2999880689 queue:0x0b4b5f58
     kworker/5:3-3758  [005] ....    91.689872: rtos_queue_peek_from_isr_failed: tstamp:3004880683 queue:0x0b4b5f58
     kworker/5:3-3758  [005] ....    91.857836: rtos_queue_peek_from_isr_failed: tstamp:3009880676 queue:0x0b4b5f58

Once I issue a command that uses /dev/video0, some lines like

 kworker/5:3-3758  [005] ....   113.610900: rtos_queue_send_failed: tstamp:3690044629 queue:0x0b4a7258

start to appear in between the previous ones…
I’ll now try to set more parameters in the DT, as you’ve said I probably haven’t told the VI enough information about my input to make it detect correctly…

hello rob7989,

please have a try to set more parameters in device tree.
you should see something like CHANSEL_PXL_SOF to indicate the start-of-frame signaling to VI engine.

Ok, I’ve managed to acquire a video from a generator (still far from perfect and with a lot of configuration still to do, but it’s a start), thanks for the help!