From: Shawn Guo <shengchao.guo@oss.qualcomm.com>
To: Jagadeesh Kona <jagadeesh.kona@oss.qualcomm.com>
Cc: Bjorn Andersson <andersson@kernel.org>,
Abel Vesa <abelvesa@kernel.org>, Stephen Boyd <sboyd@kernel.org>,
Brian Masney <bmasney+clk@redhat.com>,
Jerome Brunet <jbrunet+clk@baylibre.com>,
Rob Herring <robh@kernel.org>,
Krzysztof Kozlowski <krzk+dt@kernel.org>,
Conor Dooley <conor+dt@kernel.org>,
Konrad Dybcio <konradybcio@kernel.org>,
Taniya Das <taniya.das@oss.qualcomm.com>,
Jagadeesh Kona <quic_jkona@quicinc.com>,
Bryan O'Donoghue <bryan.odonoghue@linaro.org>,
linux-arm-msm@vger.kernel.org, linux-clk@vger.kernel.org,
devicetree@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH 2/3] arm64: dts: qcom: glymur: Add videocc sleep clock
Date: Sat, 26 Sep 2026 08:18:29 +0800 [thread overview]
Message-ID: <arcPVcaWqnX-tG6O@QCOM-aGQu4IUr3Y> (raw)
In-Reply-To: <0e80efa9-9377-474e-99f5-d458d81bfcde@oss.qualcomm.com>
On Fri, Sep 25, 2026 at 09:19:49PM +0530, Jagadeesh Kona wrote:
>
> On 9/24/2026 9:41 PM, Shawn Guo wrote:
> > The videocc node supplies only the two XO inputs. videocc-glymur.c
> > expects a third input, DT_SLEEP_CLK, and uses it as the parent of
> > video_cc_sleep_clk_src, so that RCG cannot resolve its parent and ends
> > up as an orphan clock: any clk_set_rate() on it fails, and it shows up
> > parentless in /sys/kernel/debug/clk/clk_summary.
> >
> > Nothing is broken at runtime today because VIDEO_CC_SLEEP_CLK (0x8138)
> > is listed in video_cc_glymur_critical_cbcrs and is therefore force
> > enabled through regmap, bypassing the clock framework; the sleep source
> > simply keeps whatever rate the bootloader left. The orphan still blocks
> > any future rate management of the video sleep path.
> >
>
> Hi Shawn,
>
> The sleep clock supports only a fixed 32KHz frequency and does not support
> any other frequencies. Additionally, this clock is not currently used or voted
> on by any consumers. Therefore, leaving it in its default bootloader configured
> rate should be sufficient, and this change isn't really required.
Hi Jagadeesh,
Agreed on both facts, and the commit message says as much: nothing is
broken at runtime and there is no rate to manage. The patch is not
about fixing a functional failure though, it is about the DT describing
the hardware inputs the block actually has.
video_cc_sleep_clk_src's parent_map contains P_SLEEP_CLK and its
freq_tbl has F(32000, P_SLEEP_CLK, 1, 0, 0), so the RCG really does
take a sleep clock input in hardware, and videocc-glymur.c asks the DT
for it via DT_SLEEP_CLK. A DT that stops at two inputs leaves that
input undescribed regardless of whether anyone votes on it today.
It also matters for the binding. The schema currently documents two
inputs for every compatible, which is wrong for qcom,glymur-videocc,
and I am fixing that in the preceding patch of this series. If the
DTS keeps only two entries it no longer matches its own binding.
Shawn
next prev parent reply other threads:[~2026-09-26 0:18 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-24 16:11 [PATCH 0/3] qcom: videocc: Fix sleep clock on Glymur/SM8750 Shawn Guo
2026-09-24 16:11 ` [PATCH 1/3] dt-bindings: clock: qcom,sm8450-videocc: Fix clock inputs for Glymur Shawn Guo
2026-09-24 16:11 ` [PATCH 2/3] arm64: dts: qcom: glymur: Add videocc sleep clock Shawn Guo
2026-09-25 9:48 ` Abel Vesa
2026-09-25 15:35 ` Shawn Guo
2026-09-25 15:49 ` Jagadeesh Kona
2026-09-26 0:18 ` Shawn Guo [this message]
2026-09-24 16:11 ` [PATCH 3/3] arm64: dts: qcom: sm8750: Fix videocc clock inputs Shawn Guo
2026-09-25 9:47 ` Abel Vesa
2026-09-25 15:29 ` Shawn Guo
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=arcPVcaWqnX-tG6O@QCOM-aGQu4IUr3Y \
--to=shengchao.guo@oss.qualcomm.com \
--cc=abelvesa@kernel.org \
--cc=andersson@kernel.org \
--cc=bmasney+clk@redhat.com \
--cc=bryan.odonoghue@linaro.org \
--cc=conor+dt@kernel.org \
--cc=devicetree@vger.kernel.org \
--cc=jagadeesh.kona@oss.qualcomm.com \
--cc=jbrunet+clk@baylibre.com \
--cc=konradybcio@kernel.org \
--cc=krzk+dt@kernel.org \
--cc=linux-arm-msm@vger.kernel.org \
--cc=linux-clk@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=quic_jkona@quicinc.com \
--cc=robh@kernel.org \
--cc=sboyd@kernel.org \
--cc=taniya.das@oss.qualcomm.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®