Re: [PATCH v4 2/2] media: i2c: ov02c10: Correct power-on sequence and timing

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

On 28/01/2026 03:41, Saikiran B wrote:
> Hi Bryan,
> 
>  > Does this reset fix the problem for you though?
> 
> The reset cleanup in this patch (v4) is for correctness (to match T1), 
> but the
> primary stability fix for my platform is indeed handling the regulator 
> brownout.

Hmm. Still not sure I agree with you that its browning out.

>  > It is also possible active-discharge is not set on the LDOs ... I 
> guess one way
>  > to know for sure ... is to never turn the regulators off.
> 
> You are spot on. My testing confirms exactly this: if the rail doesn't 
> toggle -
> (or is given enough time to discharge) tested and proven in v2 patchset 
> where I kept the regulator on after initial toggle and just handled the 
> camera via software reset, the sensor worked perfectly.

Just to be difficult - I'm specifically asking to test never switching 
the regulator off - not having a long delay.


>   The failure only occurs if we toggle the regulator off and on again 
> too fast for
> the bulk capacitors to discharge (passive discharge).

A statement I still don't believe is supported by the available evidence 
have you tested.

- The CCI pin change ?
   This is to see if the CCI pins are inadvertently supplying voltage

- The XSHUTDOWN pin floating change ?


> Regarding Active Discharge: The `qcom-rpmh-regulator` driver currently lacks
> support for the `regulator-pull-down` property (it doesn't send the required
> RPMh resource commands). I plan to investigate adding that support 
> separately,
> as it would be the ideal long-term fix.

I'm not sure RPMh supports that.

What I've done in previous email is show you how we should go about 
determining the setup and the state of the LDOs.

Linux -> RPMh -> SPMI -> LDOs

We can also do

Linux -> SPMI -> LDOs to look at the register state directly.

I have to say I am 100% against adding random delays in the order of 
_seconds_ without getting a good hard look at the LDOs, testing the CCI 
changes and/or testing to see if XSHUTDOWN is floating.

> For now, I have submitted a patch series to `linux-regulator` to add
> `regulator-off-on-delay-us` support to the `qcom-rpmh-regulator` driver.
> Mark Brown has already reviewed it and I have just sent v3.
> 
> Once that lands, the Yoga Slim 7x DTS will enforce the physical delay at the
> regulator level, which resolves the brownout cleanly.

I again.

- Do not believe we have root caused a regulator brown out
- Believe we should interrogate the LDO settings
   We can look at the bits and see if active-discharge is set.

Please do that !

> This media series (v4) is now purely to ensure the OV02C10 driver follows
> the datasheet power-up sequence correctly, independent of the platform- 
> specific
> brownout.

I have the data-sheet so while I think XSHUTDOWN at the start of 
power_on() would be justified IF it fixed the problem for you, we've 
established it does _not_ fix the problem for you.

Please, please, please - re-read the asks I have for you on debugging 
this and engage with them !

---
bod