From: Brian Norris <briannorris@chromium.org>
To: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
Cc: Bjorn Andersson <andersson@kernel.org>,
Konrad Dybcio <konradybcio@kernel.org>,
Georgi Djakov <djakov@kernel.org>,
Odelu Kukatla <quic_okukatla@quicinc.com>,
Douglas Anderson <dianders@chromium.org>,
Krzysztof Kozlowski <krzk+dt@kernel.org>,
Konrad Dybcio <konrad.dybcio@linaro.org>,
linux-arm-msm@vger.kernel.org, linux-kernel@vger.kernel.org,
devicetree@vger.kernel.org, Conor Dooley <conor+dt@kernel.org>,
Rob Herring <robh@kernel.org>,
cros-qcom-dts-watchers@chromium.org
Subject: Re: [RFC PATCH] arm64: dts: qcom: sc7280: Drop aggre{1,2}_noc QOS clocks on Herobrine
Date: Mon, 25 Aug 2025 15:19:52 -0700 [thread overview]
Message-ID: <aKzhiPIDszlMocIQ@google.com> (raw)
In-Reply-To: <3i7pdzata6gxsc3svb3eygubfdfmnetlekxdd25bb4ljkdrlh7@bvufiwmdusqz>
Hi Dmitry,
Thanks for the response.
On Mon, Aug 25, 2025 at 12:22:03PM +0300, Dmitry Baryshkov wrote:
> On Sat, Aug 23, 2025 at 12:37:18PM -0700, Brian Norris wrote:
> > Specifically, they fail in qcom_icc_set_qos() when trying to write the
> > QoS settings for qhm_qup1. Several of the previous nodes (qhm_qspi,
> > qhm_qup0, ...) seem to configure without crashing.
> >
> > I don't really know what's unique about Herobrine systems vs other
> > sc7280 systems that presumably work fine. I'd guess there's some
> > conflict with something configured by the boot firmware.
>
> I think it well might be that Herobrine's TZ doesn't export QoS regions
> to Linux.
That may be. I don't really know what to look for to verify that without
a lot of research, aside from crashes like this though. I'm fine with
assuming this though.
> > I'm submitting as an RFC just to get thoughts from people who hopefully
> > know better than me what might be going wrong here.
> >
> > Fixes: fbd908bb8bc0 ("interconnect: qcom: sc7280: enable QoS configuration")
> > Fixes: 2b5004956aff ("arm64: dts: qcom: sc7280: Add clocks for QOS configuration")
> > Signed-off-by: Brian Norris <briannorris@chromium.org>
> > ---
> >
> > arch/arm64/boot/dts/qcom/sc7280-herobrine.dtsi | 10 ++++++++++
> > 1 file changed, 10 insertions(+)
> >
> > diff --git a/arch/arm64/boot/dts/qcom/sc7280-herobrine.dtsi b/arch/arm64/boot/dts/qcom/sc7280-herobrine.dtsi
> > index 2ba4ea60cb14..59203ce58c61 100644
> > --- a/arch/arm64/boot/dts/qcom/sc7280-herobrine.dtsi
> > +++ b/arch/arm64/boot/dts/qcom/sc7280-herobrine.dtsi
> > @@ -394,6 +394,16 @@ &vreg_l2c_1p8 {
> >
> > /* ADDITIONS TO NODES DEFINED IN PARENT DEVICE TREE FILES */
> >
> > +/* QoS seems to have conflicts with boot firmware on these devices. */
> > +&aggre1_noc {
> > + /delete-property/ clocks;
>
> While it might be enough for Linux to make it skip the QoS, I think a
> more correct fix would be to remove the 'reg' instead / in addition.
That should work too. However, besides simply violating
Documentation/devicetree/bindings/interconnect/qcom,sc7280-rpmh.yaml
(which is easy enough to tweak), that also violates basic simple-bus
rules:
arch/arm64/boot/dts/qcom/sc7280-herobrine-crd.dtb: soc@0 (simple-bus): interconnect@16e0000: 'anyOf' conditional failed, one must be fixed:
'reg' is a required property
'ranges' is a required property
from schema $id: http://devicetree.org/schemas/simple-bus.yaml#
[...]
> On the other hand, having those boards used by only a few people it
> might be easier to just pick up the simple fix rather than implementing
> a 'proper' one.
>
> Nevertheless, this would require changing the schema too, see
> Documentation/devicetree/bindings/interconnect/qcom,sc7280-rpmh.yaml
Sure, I've tested out a change just to tweak the clock requirements.
I'll plan on submitting that if no solution arises for the 'reg' schema.
Brian
next prev parent reply other threads:[~2025-08-25 22:19 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-08-23 19:37 [RFC PATCH] arm64: dts: qcom: sc7280: Drop aggre{1,2}_noc QOS clocks on Herobrine Brian Norris
2025-08-25 9:22 ` Dmitry Baryshkov
2025-08-25 22:19 ` Brian Norris [this message]
2025-08-25 21:22 ` Rob Herring (Arm)
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=aKzhiPIDszlMocIQ@google.com \
--to=briannorris@chromium.org \
--cc=andersson@kernel.org \
--cc=conor+dt@kernel.org \
--cc=cros-qcom-dts-watchers@chromium.org \
--cc=devicetree@vger.kernel.org \
--cc=dianders@chromium.org \
--cc=djakov@kernel.org \
--cc=dmitry.baryshkov@oss.qualcomm.com \
--cc=konrad.dybcio@linaro.org \
--cc=konradybcio@kernel.org \
--cc=krzk+dt@kernel.org \
--cc=linux-arm-msm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=quic_okukatla@quicinc.com \
--cc=robh@kernel.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