Re: [PATCH v2 1/1] media: i2c: ov02c10: Keep power on and use reset for power management

[Bryan O'Donoghue <bod@kernel.org>]

On 26/01/2026 14:08, Saikiran B wrote:
> The exact issue is:
> 1. Open Camera -> Close -> Wait 3s -> Open: WORKS.
> 2. Open Camera -> Close -> Wait 1.5s -> Open: FAILS (I2C Timeout / 
> Device Busy).
> 
> If the VDD rail is floating in the brownout region (~1.0V) during that 
> 1.5s window, does the sensor's internal Reset Logic Gate even have 
> enough bias voltage to function?

I think the VDD rail floating is unlikely, this would require the 
description of the LDO configured by XBL to be incorrect - possible but, 
then you'd expect to see an update for Windows to fix it.

Have you gotten the latest firmware for the board from Lenovo ? A 
misconfigured LDO - without active discharge set, should receive a 
firmware update to address.

Another possibility is CCI is powering the chip in sleep.

Lets have a look at the CCI pins.

         cam_rgb_default: cam-rgb-default-state {
                 mclk-pins {
                         pins = "gpio100";
                         function = "cam_aon";
                         drive-strength = <16>;
                         bias-disable;
                 };

                 reset-n-pins {
                         pins = "gpio237";
                         function = "gpio";
                         drive-strength = <2>;
                         bias-disable;
                 };
         };

add
	cam_rgb_sleep: cam-rgb-sleep-state {
                 mclk-pins {
                         pins = "gpio100";
                         function = "cam_aon";
                         drive-strength = <2>;
                         bias-pull-down; // Force to Ground
                 };

                 reset-n-pins {
                         pins = "gpio237";
                         function = "gpio";
                         drive-strength = <2>;
                         bias-pull-down; // Force to Ground
                 };
         };


&cci1_i2c1 {
         camera@36 {
                 compatible = "ovti,ov02c10";
                 reg = <0x36>;

                 reset-gpios = <&tlmm 237 GPIO_ACTIVE_LOW>;
                 pinctrl-names = "default", "sleep";
                 pinctrl-0 = <&cam_rgb_default>;
                 pinctrl-1 = <&cam_rgb_sleep>;

Failing that we should try a more liberal power_on()

power_on():

     Assert Reset (GPIO Low).
     Wait 10ms.
     Enable all regulators (RPMh votes).
     Wait 20ms (Allow PM8010 to ramp and stabilize).
     Start the Clock (MCLK).
     Wait 10ms.
     De-assert Reset (GPIO High).
     Wait 5ms.

If that doesn't work, we will have to go and look at the LDO 
configuration via SPMI directly.

During the 2.3 second window can you run

Getting the kernel's view:
cat /sys/kernel/debug/regulator/regulator_summary

We are looking for use_count > 0 and open_count

We could also look at the SPMI LDO config register

Getting the firmware's view:
cat /sys/kernel/debug/regmap/spmi0-0x08/registers

It should be possible to interrogate the configruation of all of the 
relevant LDOs and ascertain if active-discharge is set, which TBH it 
should be.

> ​My testing suggests the sensor is physically incapable of processing 
> the Reset signal until the rail fully discharges (~2.3s), which is why 
> the 5ms delay has no effect.

Yes accepted but, a 2.3 second delay is avoidable if we root-cause.
P.S.
Please bottom post !

---
bod