regulator: qcom-rpmh: Add support for off-on-delay and debounce-delay - #1951
Open
jprakash-qc wants to merge 4 commits into
Open
jprakash-qc wants to merge 4 commits into
jprakash-qc wants to merge 4 commits into
Conversation
…perty Add a new property 'regulator-off-on-delay-us' to specify a minimum delay between disabling and re-enabling a regulator. This is useful in cases where a regulator discharges slowly and needs significant time to reach a safe reset level, and re-enabling it too early may lead to a brownout event. Link: https://lore.kernel.org/all/20261001-regulator-off-on-delay-v4-1-258ba9612da8@oss.qualcomm.com/ Suggested-by: Saikiran <bjsaikiran@gmail.com> Signed-off-by: Jishnu Prakash <jishnu.prakash@oss.qualcomm.com>
…elay property Add 'qcom,regulator-off-debounce-delay-us' to describe the time to wait for an enable vote after a disable vote, before actually sending the disable request to RPMh. Some consumers toggle a regulator off and back on in quick succession as part of their normal operation, a behavior this driver has no control over. The appropriate debounce window to absorb this varies by which consumer(s) are wired to a given rail and how they use it, so it is exposed as a per-regulator property rather than a fixed value. It is placed in the qcom,rpmh-regulator binding and vendor-prefixed because the underlying deferred-disable mechanism is specific to this driver's RPMh command handling. Link: https://lore.kernel.org/all/20261001-regulator-off-on-delay-v4-3-258ba9612da8@oss.qualcomm.com/ Assisted-by: Claude:claude-sonnet-5 Signed-off-by: Jishnu Prakash <jishnu.prakash@oss.qualcomm.com>
…egulator Some consumers rapidly toggle a regulator off and back on again, for example a driver that disables its supply on -EPROBE_DEFER and re-enables it on the next probe attempt. Sending the disable request to RPMh immediately in this case causes needless power cycling of the rail, and in some cases the driver instead avoids calling regulator_disable() altogether to sidestep this, at the cost of leaving the regulator enabled and triggering the core's "unbalanced disables" and late-cleanup warnings. Add support for a new 'qcom,regulator-off-debounce-delay-us' property. When set, a disable vote is not sent to RPMh immediately; instead a cancelable delayed work item is queued to send it after the configured delay. If an enable vote arrives before the delay expires, the pending work is canceled and the rail is left untouched, avoiding the unnecessary disable/enable bounce. If no enable vote arrives, the disable request is sent once the delay elapses. This complements the existing 'regulator-off-on-delay-us' handling: that property enforces a minimum time the rail must stay physically off before it can be safely re-enabled (a hardware discharge/POR constraint), whereas this new delay defers sending the disable request in the first place, absorbing quick bounces before they ever reach the hardware. The two have no dependency on each other and can be used together. The deferred disable work item can run after the regulator has been registered, so cache the regulator_dev pointer in struct rpmh_vreg and thread it explicitly through _rpmh_regulator_set_enable_state() rather than relying on the regulator_dev argument that was previously only available at the regulator core's enable()/disable() call sites. Link: https://lore.kernel.org/all/20261001-regulator-off-on-delay-v4-4-258ba9612da8@oss.qualcomm.com/ Assisted-by: Claude:claude-sonnet-5 Signed-off-by: Jishnu Prakash <jishnu.prakash@oss.qualcomm.com>
qcomlnxci
requested review from
a team,
QUIC-kamalw,
fenglinw-qcom and
kotarake
and removed request for
a team
October 1, 2026 13:39
…off-on-delay-us" This reverts commit e4ae86b. The 'regulator-off-on-delay-us' property is now documented in the common regulator.yaml schema (see "regulator: dt-bindings: Add 'regulator-off-on-delay-us' property"), which qcom,rpmh-regulator.yaml already references via $ref: regulator.yaml#. The explicit per-node allow-list entries added here are therefore redundant. Signed-off-by: Jishnu Prakash <jishnu.prakash@oss.qualcomm.com>
jprakash-qc
force-pushed
the
tech/pmic/misc
branch
from
October 1, 2026 14:03
fcd9148 to
0c22b9d
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
This series adds support for two related delay properties for the Qualcomm
RPMh regulator driver:
regulator-off-on-delay-us(enforces a minimumphysical off-time before re-enable) and
qcom,regulator-off-debounce-delay-us(defers sending a disable request to RPMh so quick disable/enable bounces
never reach the hardware).
Motivation:
On the Lenovo Yoga Slim 7x (Snapdragon X Elite), the camera regulators
(LDO1, LDO3, LDO7) have large bulk capacitors and rely on passive discharge.
When these regulators are disabled, the voltage decays very slowly. If
re-enabled too quickly, the sensor experiences a brownout and fails to
initialize. This can be prevented by specifying a minimum off-time.
Separately, some consumers rapidly toggle a regulator off and on again,
for example, a driver that disables its supply on -EPROBE_DEFER and
re-enables it on the next probe attempt. Sending the disable vote to RPMh
immediately in this case causes needless power cycling, so
qcom,regulator-off-debounce-delay-us lets this be deferred and canceled
if a quick re-enable follows.
CRs-Fixed: 4697023