From: Saikiran <bjsaikiran@gmail.com>
To: linux-media@vger.kernel.org
Cc: linux-arm-msm@vger.kernel.org, rfoss@kernel.org,
todor.too@gmail.com, bryan.odonoghue@linaro.org, bod@kernel.org,
vladimir.zapolskiy@linaro.org, hansg@kernel.org,
sakari.ailus@linux.intel.com, mchehab@kernel.org,
Saikiran <bjsaikiran@gmail.com>
Subject: [PATCH 0/3] Fix OV02C10 camera stability on Snapdragon X Elite
Date: Sat, 24 Jan 2026 12:47:48 +0530 [thread overview]
Message-ID: <20260124071751.5885-1-bjsaikiran@gmail.com> (raw)
This patch series fixes critical stability issues with the OV02C10 camera
sensor on Snapdragon X Elite platforms, specifically tested on the Lenovo
Yoga Slim 7x (x1e80100).
Problems addressed:
===================
1. Camera pipeline permanently locked after application closes
- Affects qcom-camss driver
- Caused by early return in video_stop_streaming() on subdev errors
- Result: Camera unusable until reboot
2. Silent failure in sensor disable path
- Affects ov02c10 driver
- I2C write errors during stream stop are silently ignored
- Hinders debugging of power management issues
3. Brownout/latch-up from rapid power cycling
- Affects ov02c10 driver
- Occurs during browser WebRTC permission flows (rapid open/close/open)
- Sensor microcontroller locks up requiring full system reboot
- Root cause: Incomplete regulator discharge between power cycles
Without these fixes, the camera becomes permanently unusable after rapid
open/close cycles and requires a full system reboot to recover.
Testing:
========
All patches tested together on Linux 6.19-rc5 with:
- 50+ camera open/close/open rapid cycles (< 100ms between operations)
- Browser WebRTC permission flows (Chrome, Firefox, Brave)
- qcam stress testing
- libcamera/pipewire integration testing
Hardware tested:
- Lenovo Yoga Slim 7x (Snapdragon X Elite x1e80100)
- OmniVision OV02C10 2MP RGB camera sensor
Ubuntu bug tracking:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2138756
Patch overview:
===============
Patch 1: Fix qcom-camss pipeline lock leak
- Ensures pipeline is always released even when subdevices fail to stop
- Prevents permanent camera lockup
- Improves error messages to identify failing subdevice
Patch 2: Add error logging to ov02c10 disable_streams
- Captures and logs I2C write failures during stream stop
- Still returns 0 to prevent pipeline lock leaks
- Aids in debugging power management issues
Patch 3: Enforce 2-second power cycle cool-down in ov02c10
- Tracks last power-off timestamp
- Enforces minimum 2-second gap between power cycles
- Tested delays: 900ms (failed), 1500ms (failed), 2000ms (reliable)
- Improves power sequencing (MCLK off before regulators)
- Zero performance penalty for normal usage (camera opened after >2s)
Impact:
=======
These patches resolve a critical user-facing issue where the camera becomes
completely unusable and requires a full system reboot to recover. This
commonly occurs during:
- Browser WebRTC permission prompts
- Video conferencing application startup
- Rapid application switching
- Camera application crashes with immediate restart
The fixes are conservative, well-tested, and maintain backward compatibility
while significantly improving system stability.
Saikiran (3):
media: qcom: camss: Fix pipeline lock leak in stop_streaming
media: i2c: ov02c10: Check for errors in disable_streams
media: i2c: ov02c10: Enforce cool-down period to prevent brownout
drivers/media/i2c/ov02c10.c | 75 +++++++++++++++++----
drivers/media/platform/qcom/camss/camss-video.c | 13 ++--
2 files changed, 74 insertions(+), 14 deletions(-)
--
2.51.0
next reply other threads:[~2026-01-24 7:17 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-01-24 7:17 Saikiran [this message]
2026-01-24 7:17 ` [PATCH] media: qcom: camss: Fix pipeline lock leak in stop_streaming Saikiran
2026-01-25 12:23 ` Bryan O'Donoghue
2026-01-24 7:17 ` [PATCH] media: i2c: ov02c10: Check for errors in disable_streams Saikiran
2026-01-25 12:26 ` Bryan O'Donoghue
2026-01-26 10:18 ` Hans de Goede
2026-01-24 7:17 ` [PATCH] media: i2c: ov02c10: Enforce cool-down period to prevent brownout Saikiran
2026-01-25 13:21 ` Bryan O'Donoghue
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20260124071751.5885-1-bjsaikiran@gmail.com \
--to=bjsaikiran@gmail.com \
--cc=bod@kernel.org \
--cc=bryan.odonoghue@linaro.org \
--cc=hansg@kernel.org \
--cc=linux-arm-msm@vger.kernel.org \
--cc=linux-media@vger.kernel.org \
--cc=mchehab@kernel.org \
--cc=rfoss@kernel.org \
--cc=sakari.ailus@linux.intel.com \
--cc=todor.too@gmail.com \
--cc=vladimir.zapolskiy@linaro.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox