Release 28.2.1 nvcamera-daemon

Hi Jerry,

As phabsch has mentioned in the very beginning of this post, we can use v4l2-ctrl to do frame capture (bypass ISP) without issue in both TX2 dev kit our our system, the issue is when using nvcamerasrc.

hello dk1900,

the sensor driver should works if you’re able to access camera stream with v4l2 stand controls,
there should be issues with device tree property settings,
please enable the VI tracing logs from debugfs, and share the messages for reference,
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

Hi @JerryChang, those enhanced logs don’t help. It looks like the capture is never initialized, so nothing is in the logs after I try to capture:

 tracer: nop                                                 
         
 entries-in-buffer/entries-written: 3/3   #P:6 
                                           
                          _-----=> irqs-off 
                         / _----=> need-resched 
                        | / _---=> hardirq/softirq 
                        || / _--=> preempt-depth   
                        ||| /     delay          
       TASK-PID   CPU#  ||||    TIMESTAMP  FUNCTION 
          | |       |   ||||       |         |      
 kworker/0:3-804   [000] ...1   246.504712: rtos_queue_peek_from_isr_failed: tstamp:7841904657 queue:0x0b4a3c58
 kworker/0:3-804   [000] ...1   246.504717: rtcpu_start: tstamp:7841906518                                     
 kworker/0:3-804   [000] ...1   246.556712: rtos_queue_peek_from_isr_failed: tstamp:7843009207 queue:0x0b4a3c58

hello phabsch,

please review your [Port Binding], to check you’d correct device tree definitions of VI, NvCSI, and sensors.
next, you may have a try to boost the clocks, for example, VI, NvCSI to maximum for testing.

Yes, we already run a script ‘max_clocks.sh’

echo 1 > /sys/kernel/debug/bpmp/debug/clk/vi/mrq_rate_locked
echo 1 > /sys/kernel/debug/bpmp/debug/clk/isp/mrq_rate_locked
echo 1 > /sys/kernel/debug/bpmp/debug/clk/nvcsi/mrq_rate_locked
MAX_VI_RATE=cat /sys/kernel/debug/bpmp/debug/clk/vi/max_rate
MAX_ISP_RATE=cat /sys/kernel/debug/bpmp/debug/clk/isp/max_rate
MAX_NVCSI_RATE=cat /sys/kernel/debug/bpmp/debug/clk/nvcsi/max_rate
echo ${MAX_VI_RATE} > /sys/kernel/debug/bpmp/debug/clk/vi/rate
echo ${MAX_ISP_RATE} > /sys/kernel/debug/bpmp/debug/clk/isp/rate
echo ${MAX_NVCSI_RATE} > /sys/kernel/debug/bpmp/debug/clk/nvcsi/rate

hello phabsch,

please share the media device information with $ media-ctl -p,
you may review your pix_clk_hz settings in sensor device tree, you may also have a try to increase it to see if that do the trick.
thanks

I solved the problem by comparing the steps used to get the reference system up and running. It looks like we were missing a file. We selectively copied certain files from the drivers package. In this case we needed var/nvidia/nvcam/input/model_frontal.xml from the nvidia_drivers.tbz2 archive. Once I copied this file on to our system everything started working.

It would have been nice if the logs showed that it couldn’t load this file.