CSI 1080p video input from FPGA

Autonomous Machines Jetson & Embedded Systems Jetson TX2
,
1

Hi,
I’m trying to display video sampled from an FGPA connected to a TX2 Jetson.
I’ve modified the imx185 driver to comply with the relevant resolution: 1920x1080x30 RGB888. but not CSI data is sampled by the Jetson.

The driver, device tree, booting terminal, video tracing and v4l2-ctl output is attached.

any ideas how to handle this issue?
camera-dummy.dtsi (17.7 KB)
imx185.c (18.1 KB)
imx185_mode_tbls.h (2.1 KB)
Terminal.txt (83.3 KB)
v4l2-ctl (2.6 KB)
Videotracing (17.6 KB)

3

Did you enable the trace and run the v4l2-ctl and cat the trace again the log didn’t show the information after the CSI power enable. If yes that tell the NVCSI/VI didn’t receive any validate data from MIPI bus you may need to probe the MIPI signal to confirm it.

4

@ShaneCCC,
thanks for the reply.

Why does the trace shows CSI power enable and disable for all availabe channels and not only the one that actualy running within the gstreamer command?

5

Please run the v4l2-ctl to capture the and check the trace log instead run the gstreamer.

Thanks

6

The CHANSEL_FAULT field states that the line is too short 0x00000200. Is it possible that although I was told that the input is rgb888 I need to set the input pixel size as 10 (in the DT):
dynamic_pixel_bit_depth , csi_pixel_bit_depth ?

i2c@3180000 {
imx185_a@36 {
compatible = “nvidia,imx185”;
reg = <0x36>;
clocks = <&tegra_car TEGRA186_CLK_EXTPERIPH1>, <&tegra_car TEGRA186_CLK_PLLP_OUT0>;
clock-names = “extperiph1”, “pllp_grtba”;
mclk = “extperiph1”;
clock-frequency = <24000000>;
status = “okay”;
mode0 { //imx185_MODE_1920x1080
mclk_khz = “24000”;
num_lanes = “2”;
tegra_sinterface = “serial_a”;
discontinuous_clk = “no”;
dpcm_enable = “false”;
cil_settletime = “0”;
phy_mode = “DPHY”;
dynamic_pixel_bit_depth = “8”; csi_pixel_bit_depth = “8”;
//mode_type = “bayer”;
//pixel_phase = “rggb”;
pixel_t = “rgb888”;
active_w = “1920”;
active_h = “1080”;
readout_orientation = “90”;
line_length = “2200”;
inherent_gain = “1”;
mclk_multiplier = “2”;
pix_clk_hz = “74250000”;

7

Yes, rgb888 the csi_pixel_bit_depth should be 24

8

Thanks, modified, yet the line is too short…
any other parameters might affect the FAULT?
I’ve attached the commands that I apply and the tracing log.
TraceVid0 (593 Bytes)
video0.txt (309.1 KB)

9

No, you can try to report less width step by step to check.

10

Do you mean to recompile the DT with decreasing values in?

11

No, should be the active_w and the width in sensor mode table like below.

static const struct camera_common_frmfmt ov5693_frmfmt[] = {
2388  	{{2592, 1944},	ov5693_30fps,	1, 0,	OV5693_MODE_2592X1944},
2389  	{{2592, 1458},	ov5693_30fps,	1, 0,	OV5693_MODE_2592X1458},
2390  	{{1280, 720},	ov5693_120fps,	1, 0,	OV5693_MODE_1280X720_120FPS},
12

This is the table in imx185_mode_tbls.h (2.1 KB)

static const struct camera_common_frmfmt imx185_frmfmt = {
{{1920, 1080}, imx185_30fps, 1, 0,
IMX185_MODE_1920X1080_CROP_30FPS},
{{1920, 1080}, imx185_30fps, 1, 0,
IMX185_MODE_1920X1080_CROP_10BIT_30FPS},
{{1920, 1080}, imx185_60fps, 1, 0,
IMX185_MODE_1920X1080_CROP_60FPS},
{{1920, 1080}, imx185_60fps, 1, 0,
IMX185_MODE_1920X1080_CROP_10BIT_60FPS},
{{1920, 1080}, imx185_30fps, 1, 1,
IMX185_MODE_1920X1080_CROP_HDR_30FPS},
/* Add modes with no device tree support after below */
};

So the active line width is 1920[pixels], and the full line width is 2200[pixels].

Could you please elaborate what did you mean by “you can try to report less width step by step to check”?

13

Current the driver report 1920 lines and got short line error.
You can modify the table to report less than 1920 lines to check if trace log like 1900, 1800 … to narrow down it.

14

I have changed to 1800 and still getting the line too short.
If I see that: “tegra_chanel_capture_setup: vnc_id 0 W 1800…” it prooves that the width was actually changed?
shouldn’t I change te full line length and not only the active one?
when I set the width to 720 I got line too long…I definitely was told that the video input from the FPGA is 1920x1080p30…
Eventualy I found the width: 1280
now the failure is PIXEL_RUN_AWAY on line 1080…
Isn’t it possible that I provided incorrect clocks?

15

Suppose don’t matter with the clocks, I mean the output size doesn’t matter with the clocks as my experience for general sensors, but I can’t tell for the FPGA.

16

So, all the following clock definition fields are used to generate a clock for an external device and not for the CSI internal clocks?:
clock-frequency, mclk_khz, mclk_multiplier, pix_clk_hz

17

Those value were reference to calculate the bandwidth and MIPI cil timing.

18

So what else is there for me todo?

19

May need to make sure output size exactly.

20

hi,
I’d like to verify a documentation issue I’m having with this issue.

  1. On the Jetson/l4t/Camera BringUp - eLinux.org site it states that the CHANSEL_FAULT 0x40 means PIXEL_RUNAWAY while in the TRM | DP-07281-001_v1.0p the only place PIXEL_RUNAWAY is indicated is in section 27.24.21 as a notifying mask . Does it means that the 32 bit value provided in the debug log is a reconstructed structure which summarizes all recently received events?

  2. Another question is, the Jetson/l4t/Camera BringUp - eLinux.org site also states that “CHANSEL_FAULT of PIXEL_RUNAWAY means VI receives more lines than expected” so I reduced the numbe of lines in the DT from 720 down to 100 and yet getting the same CHANSEL_FAULT. Could you please elaborate?

21

PIXEL_RUNAWAY means receive more pixels than expected instead more lines. You need to reduce the output width to check.