So I finally understand why 4-lane MIPI CSI-2 doesn't work with the #Librem5'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)
@dos are you share why all 4 lanes can't be used?
@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 🐌
@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 🤷
@dos thank you for explaining.
@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.
@dubstar_04 5 Gbps* 😂