Skip to content

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

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
njhollinghurst opened this issue Jan 4, 2024 · 6 comments
Open
Assignees

Comments

@njhollinghurst
Copy link
Contributor

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 njhollinghurst self-assigned this Jan 4, 2024
@njhollinghurst
Copy link
Contributor Author

njhollinghurst commented Jan 4, 2024

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
Copy link
Contributor

naushir commented Jan 4, 2024

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
Copy link
Contributor Author

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
Copy link
Contributor

6by9 commented Jan 4, 2024

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
Copy link
Contributor Author

njhollinghurst commented Jan 4, 2024

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
Copy link
Contributor Author

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 added a commit to njhollinghurst/linux that referenced this issue May 19, 2025
To avoid lost frame start in a subsequent session, avoid setting
the number of lanes back to 1 or putting CSI-2 Host into reset.

It's not clear if this is a watertight fix -- what if the camera
itself produced a truncated or garbled packet, or continued to
send until the next start? -- but it does seem to fix the issue.

Signed-off-by: Nick Hollinghurst <nick.hollinghurst@raspberrypi.com>
njhollinghurst added a commit to njhollinghurst/linux that referenced this issue May 19, 2025
To avoid lost frame start in a subsequent session, avoid setting
the number of lanes back to 1 or putting CSI-2 Host into reset.

It's not clear if this is a watertight fix -- what if the camera
itself produced a truncated or garbled packet, or continued to
send until the next start? -- but it does seem to fix the issue.

Signed-off-by: Nick Hollinghurst <nick.hollinghurst@raspberrypi.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants