raspberrypi
CFE odd behaviour if MIPI setup is incomplete
Describe the bug
As just discussed with @njhollinghurst.
I was wanting to deliberately trigger the libcamera "no image data" reset mechanism, so configured an imx290 on Pi5 with dtoverlay=imx290,4lane to enable 4 lane mode, but only used a 15pin FFC in between to connect up 2 data lanes.
I was expecting to get no frames through, however instead I get frames signaled (with a significant number of frame drops) but no image data.
With the MIPI lane assignment strategy you will lose the 3rd and 4th bytes of every 4 byte sequence. For a Frame Start or End short packet that would mean you got the Data ID, LS byte of word count, but MS byte of word count and ECC would be 0. The ECC should therefore fail, and one would expect some form of error to be signaled.
You've also got the fact that 2 of the lanes will never reach HS state which could have raised an error.
Steps to reproduce the behaviour
As above
Device (s)
Raspberry Pi 5
System
6.12.34+rpt-rpi-2712 #1 SMP PREEMPT Debian 1:6.12.34-1+rpt1~bookworm (2025-06-26) aarch64 GNU/Linux
Logs
No response
Additional context
No response
ECC is far from foolproof. It can reliably correct single-bit errors and detect two-bit errors. When more than 2 bits are wrong, I reckon it will detect (and reject) about 50% of packets; which does appear to happen.
Most of the rest will be spuriously 'corrected' with a bit-flip. About 1/4 of those flips might change the {VC,DT} combination and CSI2AXI should reject them. That leaves about 3/8 of packets with correct {VC,DT}.
For short packets like FS/FE, the word count field is re-used as a frame counter, and ignored, so there's no obvious indication of error. For long packets the length and CRC mismatches will be obvious, but come too late to be useful.
This doesn't let the CSI-2 Host off the hook entirely. It ought to be able to detect that the "wrong" number of lanes were active in HS mode. Somehow it doesn't seem to care?
What CSI-2 Host can do is record various ECC, CRC and FS<->FE matching errors. It can generate an interrupt, which we don't currently handle. We probably should handle it.
There remains the question of how to interpret these errors, and distinguish if they are fatal or transient. It might not be obvious if they can be attributed to the 2-lanes-of-4-lanes scenario. And finally, how to report them up the stack?