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 60E79155757; Mon, 26 Jan 2026 15:04:17 +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=1769439857; cv=none; b=dOb1yaEVqToSvaFp3T2z0MN+YP51LBMtLEPvlsIMDsH2cOy4eogEHuiGadaYwwbyUb/yRVpZpsozpRGxxoAc+A5SstbMNoj6MNzDpmZt1b17Lh/h/Y6D8XSLOWrVif6xwz2RWPxrJC2EfthT7Gle5ycFtYp2JsEZah5kxCnj9oQ= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1769439857; c=relaxed/simple; bh=90wXXQLghKcVYE4mkja/yflNq8gl5ZORNyekyzBhurA=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=EAQfgDI4Ig76WgzB7bN0jF77UG25DsEyj7ZtuTXHNRDlm2YH3rPXznoOpK/rzeGKNtbdEOrUw4ie1EWmrywtprmsnj4VEi5dg2ZC+PuY7/rWqB07/MC3TCneem0zplod67hS41tspzS77dr2mySNIAzZvFuTisDBHhgKFt8G3dI= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=NYolDgiO; 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="NYolDgiO" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 9E27BC116C6; Mon, 26 Jan 2026 15:04:14 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1769439856; bh=90wXXQLghKcVYE4mkja/yflNq8gl5ZORNyekyzBhurA=; h=Date:Subject:To:Cc:References:From:In-Reply-To:From; b=NYolDgiOir0gLmB1iXukU+T5Yx8o9+UfkV9lJp9m2+/PAg7D5a6oJEh7p1H8mtRfe z42HzPqTBvYF2zHGcq4nbZI0ihdqiPnBfJ+nMNr0oaJhlBgO7PbElnEWf8XsjNV74O jf0oBfve2VEX82AsXj8qrRyMP24XMDa0f1PuL9KKqWsEQdaL73fEbZOtAil4vzccyX kVq4jAfNw7MaZe4Pl3X94NvIaK5+OQ6cDbbmCVaAZPYZeaMByVWZX5nh+QHoFusaeo C5fW+NidaJuaYZNqWUJz+aZhPqaHU8m4xcJrW+lXBRot7le5e+GVaNhcgl+WA5ZlU2 N3P8jhtvPnGJw== Message-ID: <371b38d5-9322-4629-b378-ec62e0924fd4@kernel.org> Date: Mon, 26 Jan 2026 15:04:12 +0000 Precedence: bulk X-Mailing-List: linux-arm-msm@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2 1/1] media: i2c: ov02c10: Keep power on and use reset for power management To: Saikiran B , Hans de Goede Cc: Bryan O'Donoghue , linux-media@vger.kernel.org, linux-arm-msm@vger.kernel.org, rfoss@kernel.org, todor.too@gmail.com, vladimir.zapolskiy@linaro.org, sakari.ailus@linux.intel.com, mchehab@kernel.org, stable@vger.kernel.org References: <20260125171745.484806-1-bjsaikiran@gmail.com> <20260126061528.63785-1-bjsaikiran@gmail.com> <20260126061528.63785-2-bjsaikiran@gmail.com> <2084a247-053b-41c0-84ef-c56af640aa74@kernel.org> 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 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