How does a camera's DT modeX node associate with the camera driver tables?

I have a frmfmt table that looks like:

enum {
        CHARM100_MODE_1920x1080P30,
        CHARM100_MODE_1280x720P60,
};

static const int charm100_camera_30fps[] = {
        30,
};

static const int charm100_camera_60fps[] = {
        60,
};

static const struct camera_common_frmfmt charm100_camera_frmfmt[] = {
        {{1920, 1080},  charm100_camera_30fps, 1, 0, CHARM100_MODE_1920x1080P30},
        {{1280, 720},   charm100_camera_60fps, 1, 0, CHARM100_MODE_1280x720P60},
};

I had assumed that the enum value would give me mode0 if I use 1920x1080p30.

The DT entry has:

charm100_camera@10 {
                        reg = <0x10>;
                        mclk = "extperiph1";
                        devnode = "video0";

                        compatible = "mycompany,charm100_camera";
                        clock-names = "extperiph1";
                        reset-gpios = <0x27 0x0 0x0>;
                        physical_h = "4.930";
                        physical_w = "5.095";
                        clocks = <0xd 0x59>;
                        sensor_model = "charm100_camera";
                        status = "okay";
                        dovdd-supply = <&csi_io_1v8>;
                        iovdd-reg = "dovdd";
                        vana-supply = <&en_vdd_cam_hv_2v8>;
                        avdd-reg = "vana";
                        vdig-supply = <&en_vdd_sys_1v2>;
                        dvdd-reg = "vdig";
                        phandle = <0x116d>;
                        linux,phandle = <0x116d>;

                        mode0 {
                                inherent_gain = "1";
                                pix_clk_hz = "74250000";
                                max_gain_val = "16.0";
                                min_hdr_ratio = "1";
                                min_framerate = "1.462526";
                                cil_settletime = "0";
                                max_exp_time = "683709";
                                active_h = "1080";
                                active_w = "1920";
                                mclk_khz = "24000";
                                min_gain_val = "1.0";
                                max_hdr_ratio = "64";
                                max_framerate = "30";
                                tegra_sinterface = "serial_a";
                                line_length = "2200";
                                mode_type = "yuv";
                                pixel_phase = "uyvy";
                                csi_pixel_bit_depth = "8";
                                dynamic_pixel_bit_depth = "8";
                                readout_orientation = "0";
                                mclk_multiplier = "25";
                                num_lanes = "4";
                                discontinuous_clk = "no";
                                min_exp_time = "13";
                                embedded_metadata_height = "0";
                        };

                        mode1 {
                                inherent_gain = "1";
                                pix_clk_hz = "74250000";
                                max_gain_val = "16.0";
                                min_hdr_ratio = "1";
                                min_framerate = "1.462526";
                                cil_settletime = "0";
                                max_exp_time = "683709";
                                active_h = "720";
                                active_w = "1280";
                                mclk_khz = "37125";
                                min_gain_val = "1.0";
                                max_hdr_ratio = "64";
                                max_framerate = "30";
                                tegra_sinterface = "serial_a";
                                line_length = "1650";
                                mode_type = "yuv";
                                pixel_phase = "uyvy";
                                csi_pixel_bit_depth = "8";
                                dynamic_pixel_bit_depth = "8";
                                readout_orientation = "0";
                                mclk_multiplier = "25";
                                num_lanes = "4";
                                discontinuous_clk = "no";
                                min_exp_time = "13";
                                embedded_metadata_height = "0";
                        };

                        ports {
                                #address-cells = <0x1>;
                                #size-cells = <0x0>;

                                port@0 {
                                        reg = <0x0>;

                                        endpoint {
                                                bus-width = <4>;
                                                remote-endpoint = <0x25>;
                                                phandle = <0x116e>;
                                                csi-port = <0>;
                                                linux,phandle = <0x116e>;
                                        };
                                };
                        };
                };

When I tru to capture from video0 with yavta /dev/video0 -c10 -n8 -s1920x1080 -fUYUV -Fov.raw, I only see PXL_SOF timeouts. Capturing with nvcamerasrc causes the camera daemon to crash:

root@tegra-ubuntu:~# export enableCamPclLogs=1
root@tegra-ubuntu:~# export enableCamPclLogs=1
root@tegra-ubuntu:~# /usr/sbin/nvcamera-daemon
Thread 1 getting next capture
Thread 1 is waiting
Thread 2 getting next capture
Thread 2 is waiting
Thread 3 getting next capture
Thread 3 is waiting
Thread 4 getting next capture
Thread 4 is waiting
Thread 5 getting next capture
Thread 5 is waiting
Thread 6 getting next capture
Thread 6 is waiting
Thread 7 getting next capture
Thread 7 is waiting
Thread 8 getting next capture
Thread 8 is waiting
Thread 9 getting next capture
Thread 9 is waiting
Thread 10 getting next capture
Thread 10 is waiting
Thread 11 getting next capture
Thread 11 is waiting
Thread 12 getting next capture
Thread 12 is waiting
Starting services...
Worker thread IspHw statsComplete start
Worker thread IspHw frameComplete start
Worker thread CaptureScheduler checkFramePending start
Worker thread CaptureScheduler frameStart start
Worker thread V4L2CaptureScheduler checkCaptureComplete start
Worker thread V4L2CaptureScheduler issueCaptures start
[ 3449.342571] nvcamera-daemon[3946]: unhandled level 2 translation fault (11) a                                                         t 0x00000028, esr 0x92000006
[ 3449.352139] pgd = ffffffc13b126000
[ 3449.355552] [00000028] *pgd=00000001df376003, *pud=00000001df376003, *pmd=000                                                         0000000000000
[ 3449.363851]
[ 3449.365339] CPU: 4 PID: 3946 Comm: nvcamera-daemon Not tainted 4.4.38-charm10                                                         0-28.2-rc #33
[ 3449.373596] Hardware name: charm100 (DT)
[ 3449.377524] task: ffffffc05cea2580 ti: ffffffc049868000 task.ti: ffffffc04986                                                         8000
[ 3449.385005] PC is at 0x7f95005628
[ 3449.388321] LR is at 0x7f95005618
[ 3449.391637] pc : [<0000007f95005628>] lr : [<0000007f95005618>] pstate: 60000                                                         000
[ 3449.399025] sp : 0000007f947f4400
[ 3449.402342] x29: 0000007f947f99d0 x28: 0000000000000000
[ 3449.407679] x27: 000000000000043f x26: 0000007f8c6dcfb0
[ 3449.413005] x25: 0000007f8c7c7970 x24: 0000000000200000
[ 3449.418331] x23: 0000000fc1800000 x22: 0000007f8c7c7990
[ 3449.423668] x21: 0000007f8c7c7990 x20: 0000007f8c7c76f0
[ 3449.429005] x19: 0000000000000000 x18: 000000000000000f
[ 3449.434334] x17: 0000007f9606cfb0 x16: 0000007f9566f348
[ 3449.439675] x15: 0000007f96a62000 x14: 0000000000000000
[ 3449.445003] x13: 0000000000000000 x12: 0000000000000000
[ 3449.450331] x11: 0000000000000000 x10: 0000000000000000
[ 3449.455670] x9 : 0000007f8c9770e0 x8 : 0000000000000000
[ 3449.461002] x7 : 0000000000000000 x6 : 0000000000000000
[ 3449.466331] x5 : 0000000000000f6a x4 : 0000007f8c6dec80
[ 3449.471668] x3 : 0000007f947fa1e0 x2 : 0000000000000000
[ 3449.477001] x1 : 0000000000000000 x0 : 0000000000000000
[ 3449.482328]
[ 3449.483856] Library at 0x7f95005628: 0x7f94d95000 /usr/lib/aarch64-linux-gnu/                                                         tegra/libcuda.so.1.1
[ 3449.492739] Library at 0x7f95005618: 0x7f94d95000 /usr/lib/aarch64-linux-gnu/                                                         tegra/libcuda.so.1.1
[ 3449.501610] vdso base = 0x7f96a61000
Segmentation fault (core dumped)

But, even though mode0 above calls for an mclk of 24MHz, probing the pin with a 'scope shows me a 37.125MHz clock, which is the default clock set in my driver. This makes me thing that the modeX entries are not being used and all the settings could be wrong.

My driver appear to be bound correctly and passes v4l2-compliance with no failures. media-ctl shows:

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-0 (2 pads, 2 links)
            type V4L2 subdev subtype Unknown flags 0
            device node name /dev/v4l-subdev0
        pad0: Sink
                <- "charm100_camera 2-0010":0 [ENABLED]
        pad1: Source
                -> "vi-output, charm100_camera 2-00":0 [ENABLED]

- entity 2: charm100_camera 2-0010 (1 pad, 1 link)
            type V4L2 subdev subtype Sensor flags 0
            device node name /dev/v4l-subdev1
        pad0: Source
                [fmt:UYVY/1920x1080 field:none]
                -> "150c0000.nvcsi-0":0 [ENABLED]

- entity 3: vi-output, charm100_camera 2-00 (1 pad, 1 link)
            type Node subtype V4L flags 0
            device node name /dev/video0
        pad0: Sink
                <- "150c0000.nvcsi-0":1 [ENABLED]

That output is more or less as I was expecting. but I am concerned that the camera device “charm100_camera 2-0010” doesn’t match the csi and vi cross references “charm100_camera 2-00”. In the documentation these do match.

Can anybody give me some helpful suggestions?

Many thanks!

@Ratbert
Due to nvcamerasrc didn’t support YUV sensor and the modex in DT is report to it. For your case you can focus on the v4l2 driver and use v4l2-ctl to bring your sensor up. Please check below link it could be help.

https://elinux.org/Jetson_TX2/28.1_Camera_BringUp

Thanks for reply ShaneCCC.

The settings for mode0, follow those suggested, except for “embedded_metadata_height = “1”;” we don’t have any embedded data so I set this to zero.

I ran the trace and got:

root@tegra-ubuntu:~# cat /sys/kernel/debug/tracing/trace
# tracer: nop
#
# entries-in-buffer/entries-written: 115/115   #P:4
#
#                              _-----=> irqs-off
#                             / _----=> need-resched
#                            | / _---=> hardirq/softirq
#                            || / _--=> preempt-depth
#                            ||| /     delay
#           TASK-PID   CPU#  ||||    TIMESTAMP  FUNCTION
#              | |       |   ||||       |         |
     kworker/4:0-30    [004] ...1   267.158031: rtos_queue_peek_from_isr_failed: tstamp:8583360091 queue:0x0b4a3c58
     kworker/4:0-30    [004] ...1   267.158038: rtcpu_start: tstamp:8583360919
     kworker/4:0-30    [004] ...1   267.314061: rtos_queue_peek_from_isr_failed: tstamp:8588361190 queue:0x0b4a3c58
     kworker/4:0-30    [004] ...1   267.470062: rtos_queue_peek_from_isr_failed: tstamp:8593361570 queue:0x0b4a3c58
     kworker/4:0-30    [004] ...1   267.626118: rtos_queue_peek_from_isr_failed: tstamp:8598362083 queue:0x0b4a3c58
     kworker/4:0-30    [004] ...1   267.782112: rtos_queue_peek_from_isr_failed: tstamp:8603362709 queue:0x0b4a3c58
     kworker/4:0-30    [004] ...1   267.990102: rtos_queue_peek_from_isr_failed: tstamp:8608363217 queue:0x0b4a3c58
(and more similar lines)

I used yavta for the capture, as well as trying v4l2-ctl and they both give the same trace output:

kworker/4:1-3454  [004] ...1   865.528205: rtos_queue_peek_from_isr_failed: tstamp:27281404447 queue:0x0b4a3c58
     kworker/4:1-3454  [004] ...1   865.528217: rtcpu_start: tstamp:27281405489
     kworker/4:1-3454  [004] ...1   865.684218: rtos_queue_peek_from_isr_failed: tstamp:27286405406 queue:0x0b4a3c58
     kworker/4:1-3454  [004] ...1   865.840190: rtos_queue_peek_from_isr_failed: tstamp:27291405862 queue:0x0b4a3c58
     kworker/4:1-3454  [004] ...1   865.996182: rtos_queue_peek_from_isr_failed: tstamp:27296406415 queue:0x0b4a3c58

In both cases I see the log errors:

...
[  878.523764] tegra-vi4 15700000.vi: PXL_SOF syncpt timeout! err = -11
[  879.527728] tegra-vi4 15700000.vi: ATOMP_FE syncpt timeout!

But I still don’t know if the camera’s mode0 from the DT is being used. Is the output mclk supposed to be configurable from the DT? If it is why can I not see 24000kHz for mclk and only see 37125kHz?

Thanks.

1 Like

@Ratbert
Use v4l2-ctl instead of yavta. Make sure the bypass_mode=0 like below command.
For the trace looks like didn’t get any invalidate frame from MIPI bus. Probe the MIPI bus to make sure it.

v4l2-ctl -d /dev/video0 --set-fmt-video=width=1920,height=1080,pixelformat=RG10 --set-ctrl bypass_mode=0 --stream-mmap --stream-count=1 --stream-to=ov1080.raw