rpicam-jpeg failed to capture "Camera frontend has timed out!"

[will127534]

Camera failed to capture jpeg using rpicam-jpeg --cam 0 -o default.jpg
The issue is related to the camera mode transition between the preview default SRGGB12_CSI2P,2784x1828 to the still pipeline's SRGGB12_CSI2P,5568x3664/0, for some reason the cmos sensor is not sending a complete frame after the transition that causes the camera frontend to timeout.

A workaround is to ask rpicam-jpeg to use the same mode for preview:
rpicam-jpeg --cam 0 --viewfinder-mode 5568:3664:12:P --mode 5568:3664:12:P -o default.jpg

Using the logic analyzer on the XVS and XHS pin shows that after the transition, hblank is still sending signals but no vblank were asserted. From the pulse measurement it looks like the sensor is stuck at the same hblank interval as the 2.7K state (~4.8us) and hasn't been updated to the correct hblank of ~10us.

Interestingly no other mode is impacted, only mode 0 (SRGGB12_CSI2P,5568x3664), if we use rpicam-jpeg --cam 0 --mode 5568:3664:10:P -o default.jpg the camera app works just fine, and the hblank duration update can be seen.

[will127534]

Judging from the I2C write traces, the transition to mode 0 is missing the IMX283_REG_HMAX(0x3036) write.

[will127534]

rpicam-jpeg --cam 0 --mode 5568:3664:10:P -o default.jpg

rpicam-jpeg --cam 0 --mode 5568:3664:12:P -o default.jpg

[will127534]

Ok I think there must be some issue with the logic analyzer, or that causes the I2C low level floor being to high for the Mosfet level shifter, using the new V1.4 board I can see the HSYNC changes.

But also found out that the power management doesn't seems to be working, as the enable pin is keep at asserted through out the test.

Comparing with the imx477.c driver I noticed that we have enable runtime PM with autosuspend:

	/*
	 * Enable runtime PM with autosuspend. As the device has been powered
	 * manually, mark it as active, and increase the usage count without
	 * resuming the device.
	 */
	pm_runtime_set_active(dev);
	pm_runtime_get_noresume(dev);
	pm_runtime_enable(dev);
	pm_runtime_set_autosuspend_delay(dev, 1000);
	pm_runtime_use_autosuspend(dev);

And here is the IMX477 driver

	pm_runtime_set_active(dev);
	pm_runtime_enable(dev);
	pm_runtime_idle(dev);

Changing the code to the one in IMX477 I can see the camera capture is working, and enable pins are being used.

@kbingham Do you know if the autosuspend is a feature on newer kernel or it should be also on Kernel v6.1 and v6.6?

[will127534]

Temporary rollback the pm_autosupend in the driver for v6.6 and v6.1

[kbingham]

Argh, so I've probably messed up the runtime pm :-( sorry, I'll take a look.

[will127534]

No worries! I'm just ping you here so you can check the upstream driver.

[kbingham]

@uajain could you check the runtime pm on the latest imx283 please?

[kbingham]

@uajain could you check the runtime pm on the latest imx283 please?

[uajain]

Runtime PM is available from v6.0 onwards (haven't checked earlier than that), so v6.1 to v6.6 should also have it.

(sorry it seems I missed the earlier ping on this issue)

What is the issue exactly? Is runtime PM breaking and not letting you capture for IMX283 with latest upstream driver? [1]

[1] https://lore.kernel.org/linux-media/20240402-kernel-name-extraversion-v4-0-fb776893e4ec@ideasonboard.com/

[will127534]

The issue looks like the power management isn't working as intended (It isn't powering down the sensor when unused).
Can you probe the enable pin on the camera to see if mainline driver will power down the camera?

[uajain]

The issue looks like the power management isn't working as intended (It isn't powering down the sensor when unused).

Oh, then it is probably my fault. I will try to look through the code and identify what explains such behaviour.

Can you probe the enable pin on the camera to see if mainline driver will power down the camera?

This seems I should have a logic analyser on my end (which I don't). Is there any other method @kbingham ?

[kbingham]

@uajain you can use i2c-detect to see if it's powered up I think. Or rwmem etc.

[uajain]

@will127534 Can you tell when driver variant you are using (is the some versoin of the mainline driver that was posted) ? Also the device tree?

Note that we recently changed the handling of the reset pin, so I have to check if that's the one causing issues. I am keeping to infer the 'reset' and 'enable' pin - are they the same or different etc, but yes we did have changes there - so I am suspecting that didn't go right.

[uajain]

@will127534 Can you tell when driver variant you are using (is the some versoin of the mainline driver that was posted) ? Also the device tree?

Note that we recently changed the handling of the reset pin, so I have to check if that's the one causing issues. I am keeping to infer the 'reset' and 'enable' pin - are they the same or different etc, but yes we did have changes there - so I am suspecting that didn't go right.

This was being discussed internally and we think that the reset device polarity (since we reversed it) is what causing the issue. It is a DT issue

Can you invert the polarity in DT and check again please @will127534 with autosuspend

[kbingham]

Will shouldn't be using the reset gpio pin. His camera module is connected to a raspberry pi 5 and only has the power regulator enable. It should be the same set up as yours.

[uajain]

Will shouldn't be using the reset gpio pin. His camera module is connected to a raspberry pi 5 and only has the power regulator enable. It should be the same set up as yours.

ah okay, I should be reading the pin status then (trying to read it through commandline, figuring out how) ..

How is rwmem possible to see through this? It only reads register address no?

[kbingham]

Will shouldn't be using the reset gpio pin. His camera module is connected to a raspberry pi 5 and only has the power regulator enable. It should be the same set up as yours.

ah okay, I should be reading the pin status then (trying to read it through commandline, figuring out how) ..

How is rwmem possible to see through this? It only reads register address no?

Exactly. If you can read the registers, it's powered on. If you can't, it's powered off.

If you can read when it should be off ... Then the runtime pm is broken and isn't turning the camera off.

It's harder to read the gpio pin state on an output. But maybe there's a way to read the expected state from either libgpiod Or just check by adding prints to the power functions in imx283.c ... Lots of options...

[uajain]

I can read the registers when camera is not streaming,so indeed the pm runtime is broken

[uajain]

I can read the registers when camera is not streaming,so indeed the pm runtime is broken

Ok, fhe PM runtime is fine, it's the single stream case which is causing this symptom. In this case, (as we already know earlier - .enable_streams() wouldn't be called unless a special hack) - the .disable_streams() suffers from a similar problem. Hence no .disable_streams() is called on camera stop (and hence no, pm_runtime_put_*() calls gets executed) - so sensor is kept powered on...

I did a similar workaround on .disable_streams() to check the hypothesis, and after .disable_streams() is called by the driver- sensors gets powered-off correctly in my testing.

We need to wait a bit before this enable/disable streams issue gets fixed upstream [1]. But that is the core issue, not the pm_runtime_management part of the driver

@will127534 I am not sure which driver you have tested (custom or any version of upstream, mention if any?) - but this is what I noticed on my latest upstream IMX283 driver.

[1] : https://lore.kernel.org/linux-media/20240410-enable-streams-impro-v3-0-e5e7a5da7420@ideasonboard.com/T/#t