From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 9988934CFBB; Wed, 28 Jan 2026 09:47:13 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1769593633; cv=none; b=DHye5cDgw2D+3NbKTBBdBeVqbHhzDzAWx8dNA5K23o9HjCZcqqT9KVmsGPrtbFhWBJroMzj6MWp25EUNVVGPYBe4POVgjDWjyIId8r5RyIp+FAJPKoGWIST4t+TO1T4L2zgvwUEI5F0C74vovvNt00vjDXp0Qe+cuCDti4UP4J0= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1769593633; c=relaxed/simple; bh=Q6azG1vWq1WpeiNInU90UPoiaAsKiqcUe9jUJhuU6mQ=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=W7WVIayKu/q2leKvVa7eYsLmmO28P/DGqAoTyJYZqpd6ngJQzJaJbdsBktRJmOG8fJiizMVv9GE+3ohGY0PZzwEHTdZb2qPZSaV63u39At0i630njUsRLlYWcMbHg0WfYpTUk42tYfHnKaJFVodK8g0Uu3h616LIEEmsM/3k1NM= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=E7ICIGUw; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="E7ICIGUw" Received: by smtp.kernel.org (Postfix) with ESMTPSA id BA56DC4CEF1; Wed, 28 Jan 2026 09:47:10 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1769593633; bh=Q6azG1vWq1WpeiNInU90UPoiaAsKiqcUe9jUJhuU6mQ=; h=Date:Subject:To:Cc:References:From:In-Reply-To:From; b=E7ICIGUw2BkNw+pJJZxA/ia7RhW19i7NjqihWjuHuR+BDI7BDxarkamUW8MCUO+bC IkyAZnuTykvjLEN4Ie5QG9uz1vdtTyA7WVCr8SPS0fthvVkWtE+f3ELWPFd+J3QrXR Pwx9lcjuq3E2OxEzQsAEx79iqKc3JARLWdproOf70n1j4m83wdZu+SsjNzbtBisIT4 7BTdTzJ30/b8PsHekgfR4GrFXITwM5JNlawnLK8C0ksMNbLYLU29038aqR1C2GC1nD xzzieVIEDXkdytgnqZ0qzr4mwO0ND1ZFNeMY9Py62Nk3g6odpVm1cXtqHAWPcf533z AF01O8Xmn39VQ== Message-ID: <92131a67-471e-41e8-83d6-4f802103db7b@kernel.org> Date: Wed, 28 Jan 2026 09:47:08 +0000 Precedence: bulk X-Mailing-List: linux-media@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v4 2/2] media: i2c: ov02c10: Correct power-on sequence and timing To: Saikiran B Cc: Sakari Ailus , linux-media@vger.kernel.org, linux-arm-msm@vger.kernel.org, rfoss@kernel.org, todor.too@gmail.com, Bryan O'Donoghue , vladimir.zapolskiy@linaro.org, hansg@kernel.org, mchehab@kernel.org, stable@vger.kernel.org References: <20260127165024.46156-1-bjsaikiran@gmail.com> <20260127165024.46156-3-bjsaikiran@gmail.com> From: Bryan O'Donoghue Content-Language: en-US In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit 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