Pi 5 CSI-2: Camera can drop the first frame after stop and restart

[njhollinghurst]

Describe the bug

When using a CSI-2 camera with Raspberry Pi 5 (RP1 CFE), after stopping streaming and starting anew (e.g. using rpicam-vid), the first frame seems intermittently to be lost.

It's most likely because the CFE driver puts the SNPS CSI-2 Host into reset during cfe_stop_streaming() -> csi2_close_rx() -> dphy_stop(). Simulations suggest that this can result in a truncated data packet over the IDI bus, which confuses CSI2AXI and causes one or more later packets to be discarded before it gets back into sync.

Possibly the fix (if there is one) is either to reset CSI-2 Host less aggressively or reset CSI2AXI more aggressively, so that they remain in sync; or failing that, to defer stopping CFE until the camera has finished streaming.

cc @naushir @6by9

Steps to reproduce the behaviour

Not easily - need e.g. IM477 with synchronized cameras or external trigger to show the lost frame.

Device (s)

Other

System

rpi-6.1.y

Logs

No response

Additional context

No response

[njhollinghurst]

Moving the call to dw_csi_host_write(dphy, RESETN, 0); out of dphy_stop() and into the start of of dphy_start() [sic], and removing dw_csi_host_write(dphy, NLANES, 0); altogether, seems to help.

But now we are never shutting down the CSI-2 receiver. There may be power consumption implications. Not clear if leaving it active unused might open the door to some other bad state?

Maybe it would be better to use a timer to delay the shutdown (assuming the camera will stop). Will have a think about it and might PR it.

[naushir]

Perhaps we call dphy_stop() when we close all the nodes, i.e. v4l2_file_operations.release? We use the default handler for this right now, but could easily override that.

[njhollinghurst]

It may depend on the camera and whether it has a "fast stop" setting (in which case it might stop after a scanline?) or not (in which case it might be an entire frame time?)

[6by9]

It may depend on the camera and whether it has a "fast stop" setting (in which case it might stop after a scanline?) or not (in which case it might be an entire frame time?)

I was about to say that the power to the sensor is normally killed fairly soon after stop, however that can't now be guaranteed with the DT updates to make external trigger modes happy.

[njhollinghurst]

Yikes, that opens up another dimension -- what will CSI-2 Host signal when the camera goes to LP00 (and stops the clock lane) in the middle of a data packet? Though I would hope it doesn't break the IDI bus in the way that resetting it does...

I suppose my point being that we don't just want the camera to stop; we may need to ensure that CSI2AXI knows that the camera has stopped and doesn't get stuck in some state that could cause it to miss the next FS.

[njhollinghurst]

Ho hum. Strictly, resetting CSI-2 Host while the camera is still transmitting, can cause a timing violation on the IDI link (signals change out of sync with byteclock). I don't think that's the primary problem but is another reason to consider changing the driver.

[njhollinghurst]

Closing as a workaround is now in place (don't reset CSI-2 Host after use), until we find evidence of any further problems.