When using max9295d 9296a to light up imx415, there is a high probability of no image and a small probability of an image. Using jetson 6.0.
this is the fail log message：
dmesg-fail-02.txt (105.0 KB)
trace-fail-02.txt (10.7 KB)
success log message：
source file:
nv_gmsl_imx415.txt (27.3 KB)
tegra234-p3768-pcai-camera-gmsl-imx415.txt (47.9 KB)
tegra234-p3768-pcai-camera-gmsl-imx415-overlay.txt (7.7 KB)
hello 2450732921,
BTW, is it a must to stay-on JP-6.0?
is it possible for moving forward to the latest JetPack 6.2 for verificaiton?
Hi JerryChang,
Yes, it can only be developed in version 6.0 at this time. Any troubleshooting methods please?
Best Regards
hello 2450732921,
just double check it’s JetPack 6.0/L4T 36.3, right?
there’re total 8 cameras, four camera on CSI-A/CSI-C with VCs.
since you’ve serdes_pix_clk_hz = "2000000000";, which need to have skew calibration due to the output data rate is > 1.5Gbps.
may I also what’s your capture pipeline?
BTW, is it possible to reduce the number of camera for testing the max9295d/9296a for issue narrow down?
Hi, Jerrychang,
yes, just jetson6.0.
And I’ve done the skew calibration in max9296.c:
I use the pipeX vcid0 for capturing,
even though it can support eight cameras, but the test just used an imx415(gmsl_testcam_module0 o or i2c@0/gmsl_testcam_a@17)
Best Regards.
hello 2450732921,
please examine your sensor pixel clock settings, it must be set correctly to avoid potential issues.
please see-also Camera Driver Porting if you’ve porting drivers from previous Jetpack release version.
you may dig into Debugging Tips section for troubleshooting.
Hi, Jerrychang,
Since my sensor outputs an image size of 1920*1080, I use the sensor clock： pixel_clk_hz = 2200 × 1125 × 30 = 74250000
Because my mipi-rate is 6Gbps, 2lane raw10
So my serdes_pix_clk_hz is： serdes_pix_clk_hz = 6000000000 x 2 / 10 = 120000000000
As far as I know, serdes_pix_clk_hz can be appropriately larger than the calculated value, so I used serdes_pix_clk_hz = “2000000000”
May I ask if my understanding and calculations are correct?
hello 2450732921,
is 6Gbps the total output? please double check the datasheet for confirmation.
even though it could have appropriately larger, you’ve added 66.7% to the serdes_pix_clk_hz. FYI, normally 15% is enough for extra clock rate.
Hi, Jerrychang,
According to max9296a’s datasheet, having two serdes is 6Gbps * 2, so I’m assuming that 6Gbps is single-link. Since I will be using two imx415s, for calculations I use serdes_pix_clk_hz = 6000000000 x 2 / 10 = 120000000000 and then expand to 200000000000
Best Regards.
hello 2450732921,
serdes_pix_clk_hz that’s configuration on the SOC side.
even though it said.. “both links at 3Gbps or 6Gbps”, it’s routing to different CSI bricks.
so, you don’t need to multiple pixel clock by 2.
note,
max9295/max9296 just as a bridge for sending sensor’s MIPI packet to CSI channel.
since you’re now reducing the number of camera for testing (single IMX415), you may calculated from sensor side and using the pixel clock for sensor bringup.
Hi Jerrychang,
Since my sensor outputs an image size of 1920*1080, I use the sensor clock： pixel_clk_hz = 2200 × 1125 × 30 = 74250000
Because of what you said about using the pixel clock on the sensor side for calculations, I used 80000000 as the value for serdes_pix_clk_hz (74250000 is slightly increased upwards) but the result doesn’t come out of the stream
Best Regards.
hello 2450732921,
that’s the calculation from IMX185’s sensor settings.
is your sensor’s line-length/frame-length as same as IMX185’s 2200/1125?
Hi Jerrychang,
Here’s the Pixel Arrangement I’m using for imx415
But the size I used is 1920 * 1080, and the line-length/frame-length of this size is usually 2200/1125, so I used these two values of 2200/1125 for the calculation：
pixel_clk_hz = 2200 × 1125 × 30 = 74250000
Best Regards.
hello 2450732921,
please verify the port bindings results.. $ sudo media-ctl -p -d /dev/media0
you may also check sensor capability with.. $ v4l2-ctl -d /dev/video0 --list-formats-ext
please check the Applications Using V4L2 IOCTL Directly.
for instance, $ v4l2-ctl -d /dev/video0 --set-fmt-video=width=1920,height=1080,pixelformat=RG10 --set-ctrl bypass_mode=0 --stream-mmap --stream-count=100
Hi Jerrychang,
I’ll verify the results right away.
By the way, did I do the math correctly in the last comment?
hello 2450732921,
that mathematics looks okay. though you’re pasting the active pixel with 3840x2160, it depends-on your sensor init mode table of which mode (i.e. 1920x1080) you’re streaming actually.
for instance,
please see-also IMX185’s sensor driver, it’s imx185_frmfmt to list all available sensor modes.
static const struct camera_common_frmfmt imx185_frmfmt[] = {
...
Hi Jerrychang,
Therefore, how can I make my sensor output data normally?
hello 2450732921,
may I know the latest failure logs for reference.
had you tried boosting clocks for testing?
