So I finally understand why 4-lane MIPI CSI-2 doesn't work with the 's big cam.

Turns out it's not going to work - but I now at least understand why πŸ˜‚

(this limits streaming at full res to about 16 FPS 10-bit and 20 FPS 8-bit instead of the sensor's 30 FPS, but you won't really be able to process it at this speed anyway so it's not a big loss; lower res can still work with higher framerates; with the current driver up to 120 FPS but it could go even higher)

Follow

@dubstar_04 It's a result of two limitations combined:

1) i.MX 8M Quad's MIPI CSI-2 receiver handles one pixel at each rising edge of the UI clock, which has a maximum rate of 333 MHz. This means the bandwidth you can realize is effectively limited by the used pixel depth.

2) The 13 Mpx Samsung sensor can't really go slower than about 1 Gbit per lane with 25 MHz MCLK - various clocks go out of their ranges when you try.

So it turns out that with 4 lanes, it just can't go slow enough 🐌

Β· Tuba Β· 1 Β· 0 Β· 4

@dubstar_04 You can go slow enough with 3 lanes, but only for 10-bit pixels; with 8-bit ones, the slowest setting is too fast again.

4 lanes could theoretically work in this setup with 16-bit pixels, but even if the sensor could zero-pad its values to 16 bits it wouldn't let you achieve more FPS anyway, because then you'd hit the maximum supported MIPI CSI-2 bandwidth (5 Mbps).

So there's basically no combination of settings where 4 lanes are usable in this setup 🀷

@dubstar_04 Oh, and the 333 MHz pixel clock itself puts the hard limit on the framerate at 13 Mpx at about 25 FPS regardless of bit depth, and that's without counting blanking or protocol overhead - so we're hitting the ceiling anyway even with lane bandwidth left to spare.

Sign in to participate in the conversation
Librem Social

Librem Social is an opt-in public network. Messages are shared under Creative Commons BY-SA 4.0 license terms. Policy.

Stay safe. Please abide by our code of conduct.

(Source code)

image/svg+xml Librem Chat image/svg+xml