From: Wenmeng Liu <wenmeng.liu@oss.qualcomm.com>
To: Lee Jones <lee@kernel.org>, Rob Herring <robh@kernel.org>,
Krzysztof Kozlowski <krzk+dt@kernel.org>,
Conor Dooley <conor+dt@kernel.org>,
Loic Poulain <loic.poulain@oss.qualcomm.com>,
Robert Foss <rfoss@kernel.org>,
Andi Shyti <andi.shyti@kernel.org>
Cc: mfd@lists.linux.dev, devicetree@vger.kernel.org,
linux-kernel@vger.kernel.org, linux-arm-msm@vger.kernel.org,
linux-i2c@vger.kernel.org, vikram.sharma@oss.qualcomm.com,
nihal.gupta@oss.qualcomm.com, vtumati@quicinc.com,
bryan.odonoghue@linaro.org,
Wenmeng Liu <wenmeng.liu@oss.qualcomm.com>
Subject: [PATCH RFC 0/3] Support the Nord CCI CCU output mux
Date: Thu, 05 Nov 2026 19:10:58 +0800 [thread overview]
Message-ID: <20261105-ccu-v1-0-3accc4b901de@oss.qualcomm.com> (raw)
On Nord, the CCI controllers are wrapped by a CCU. After reset, the
CCI I2C ports are routed to the CCU, and the CCU output mux must select
the CCI before it can be used.
The mux register is part of CAM_TOP, a register block shared by
multiple camera components and outside the CCI and CAMSS register
ranges. Accessing the block requires the camera subsystem top power
domain and AHB clock, and its state is lost when the power domain is
turned off.
This RFC describes CAM_TOP as a syscon and lets each CCI reference its
mux configuration through a phandle, register offset and mask. The CCI
driver selects the CCI at probe and runtime resume, right after enabling
the CCI clocks and before the CCI is reset or configured.
titan_cam_top: syscon@<addr> {
compatible = "qcom,nord-titan-cam-top", "syscon";
reg = <...>;
};
cci2: cci@<addr> {
compatible = "qcom,nord-cci", "qcom,msm8996-cci";
...
qcom,ccu-mux-sel = <&titan_cam_top OFFSET MASK>;
};
The CAM_TOP syscon does not describe its clock or power domain. A clock
attached to a syscon is kept prepared for the lifetime of the regmap,
which would keep the camera clock controller runtime active even when
the camera is idle. Instead, the CCI, as the consumer, writes the mux
with its own power domain and clocks, which include the AHB clock,
enabled.
An alternative is to introduce a dedicated CAM_TOP driver which owns
the clock and power domain, provides the regmap through
of_syscon_register_regmap() and handles runtime PM in its accessors.
This describes the hardware resources more completely and avoids the
debugfs issue, but adds a driver for a block currently used only by
the CCI.
We would like feedback on whether using a plain syscon with power and
clock management left to its consumer is acceptable, or whether CAM_TOP
should instead have a dedicated binding and driver.
---
Wenmeng Liu (3):
dt-bindings: mfd: syscon: Add Qualcomm Nord Titan CAM_TOP
dt-bindings: i2c: qcom-cci: Document Nord compatible
i2c: qcom-cci: Support the CCU output mux
.../devicetree/bindings/i2c/qcom,i2c-cci.yaml | 41 +++++++++++++++++++++
Documentation/devicetree/bindings/mfd/syscon.yaml | 1 +
drivers/i2c/busses/Kconfig | 1 +
drivers/i2c/busses/i2c-qcom-cci.c | 42 ++++++++++++++++++++++
4 files changed, 85 insertions(+)
---
base-commit: 8b7179210b22f8e48a82c5ceacb9d56a9c4cfec4
change-id: 20261105-ccu-99785a56dcd0
Best regards,
--
Wenmeng Liu <wenmeng.liu@oss.qualcomm.com>
next reply other threads:[~2026-11-05 11:11 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-11-05 11:10 Wenmeng Liu [this message]
2026-11-05 11:10 ` [PATCH RFC 1/3] dt-bindings: mfd: syscon: Add Qualcomm Nord Titan CAM_TOP Wenmeng Liu
2026-11-05 11:11 ` [PATCH RFC 2/3] dt-bindings: i2c: qcom-cci: Document Nord compatible Wenmeng Liu
2026-11-05 11:11 ` [PATCH RFC 3/3] i2c: qcom-cci: Support the CCU output mux Wenmeng Liu
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=20261105-ccu-v1-0-3accc4b901de@oss.qualcomm.com \
--to=wenmeng.liu@oss.qualcomm.com \
--cc=andi.shyti@kernel.org \
--cc=bryan.odonoghue@linaro.org \
--cc=conor+dt@kernel.org \
--cc=devicetree@vger.kernel.org \
--cc=krzk+dt@kernel.org \
--cc=lee@kernel.org \
--cc=linux-arm-msm@vger.kernel.org \
--cc=linux-i2c@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=loic.poulain@oss.qualcomm.com \
--cc=mfd@lists.linux.dev \
--cc=nihal.gupta@oss.qualcomm.com \
--cc=rfoss@kernel.org \
--cc=robh@kernel.org \
--cc=vikram.sharma@oss.qualcomm.com \
--cc=vtumati@quicinc.com \
/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
all inboxes | Powered by JetHome®