From: Shawn Guo <shengchao.guo@oss.qualcomm.com>
To: Krzysztof Kozlowski <krzk@kernel.org>
Cc: Bjorn Andersson <andersson@kernel.org>,
Mathieu Poirier <mathieu.poirier@linaro.org>,
Rob Herring <robh@kernel.org>,
Krzysztof Kozlowski <krzk+dt@kernel.org>,
Conor Dooley <conor+dt@kernel.org>,
Bartosz Golaszewski <brgl@kernel.org>,
Mukesh Ojha <mukesh.ojha@oss.qualcomm.com>,
linux-arm-msm@vger.kernel.org, linux-remoteproc@vger.kernel.org,
devicetree@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH 1/8] dt-bindings: remoteproc: qcom,nord-pas: Add qcom,cluster-root property
Date: Wed, 26 Aug 2026 10:42:11 +0800 [thread overview]
Message-ID: <ao5Sg6QE9NN0P2zk@QCOM-aGQu4IUr3Y> (raw)
In-Reply-To: <20260820-controversial-mussel-from-vega-aaba16@quoll>
On Thu, Aug 20, 2026 at 08:59:48AM +0200, Krzysztof Kozlowski wrote:
> On Sat, Aug 15, 2026 at 09:25:34PM +0800, Shawn Guo wrote:
> > Document the qcom,cluster-root phandle property used to describe HPASS's
> > ADSP0/1/2 cluster relationship. Every member of a cluster carries the
> > property, including the instance owning the shared resources, which
> > references itself; instances referencing the same node form one cluster
> > that boots in order and is torn down as a single unit.
> >
> > The relationship is described with a phandle rather than by containment
> > in a parent node, as ti,k3-r5f-rproc and xlnx,zynqmp-r5fss do, because
> > the hardware does not express it by containment either: the three QDSP6SS
> > blocks are register-independent, with no shared register window for a
> > container node to describe.
> >
> > Also add the qcom,nord-adsp1-pas and qcom,nord-adsp2-pas compatible
> > strings used by the non-root cluster members.
> >
> > Assisted-by: LLM
> > Signed-off-by: Shawn Guo <shengchao.guo@oss.qualcomm.com>
> > ---
> > .../bindings/remoteproc/qcom,nord-pas.yaml | 17 +++++++++++++++++
> > 1 file changed, 17 insertions(+)
> >
> > diff --git a/Documentation/devicetree/bindings/remoteproc/qcom,nord-pas.yaml b/Documentation/devicetree/bindings/remoteproc/qcom,nord-pas.yaml
> > index e90d2953ba69..58d88cb07e52 100644
> > --- a/Documentation/devicetree/bindings/remoteproc/qcom,nord-pas.yaml
> > +++ b/Documentation/devicetree/bindings/remoteproc/qcom,nord-pas.yaml
> > @@ -17,6 +17,8 @@ properties:
> > compatible:
> > enum:
> > - qcom,nord-adsp-pas
> > + - qcom,nord-adsp1-pas
> > + - qcom,nord-adsp2-pas
> > - qcom,nord-cdsp0-pas
> > - qcom,nord-cdsp1-pas
> > - qcom,nord-cdsp2-pas
> > @@ -89,6 +91,19 @@ properties:
> > maxItems: 1
> > description: The names of the state bits used for SMP2P output
> >
> > + qcom,cluster-root:
> > + $ref: /schemas/types.yaml#/definitions/phandle
> > + description:
> > + Reference to the Peripheral Authentication Service instance that owns the
> > + resources shared across this DSP's cluster. HPASS shares clock/reset/NoC
> > + resources between its ADSP0/1/2 QDSP6 instances, and the owning instance
> > + (ADSP0) has to boot first to initialize them before ADSP1/ADSP2 can cold
>
> This feels way too much SW. We design hardware resources in
> owner-independent, meaning each device is the owner. Most of Linux
> frameworks, including listed clock, reset and ICC, support resource
> sharing for multi-owner case.
It's my fault. I should have made it clear that the shared HPASS resources
(CRM_COMMON clock/reset and the AG_NOC bridge) are not visible to the OS.
Instead, they are programmed by TZ, on the owning ADSP's behalf.
> If this is not SW related, then I claim that compatible defines whether
> services is owner of the hardware or not.
Good point! I will drop the property and try to derive from compatibles.
> Also, unresponded Sashiko comments.
Yes, just wanted to get human/maintainer's view first.
Shawn
next prev parent reply other threads:[~2026-08-26 2:42 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-08-15 13:25 [PATCH 0/8] remoteproc: qcom: Support the Nord HPASS ADSP cluster Shawn Guo
2026-08-15 13:25 ` [PATCH 1/8] dt-bindings: remoteproc: qcom,nord-pas: Add qcom,cluster-root property Shawn Guo
2026-08-15 13:35 ` sashiko-bot
2026-08-20 6:59 ` Krzysztof Kozlowski
2026-08-26 2:42 ` Shawn Guo [this message]
2026-08-15 13:25 ` [PATCH 2/8] remoteproc: Add cluster field to struct rproc Shawn Guo
2026-08-15 13:25 ` [PATCH 3/8] remoteproc: qcom: sysmon: Suppress notify between cluster siblings Shawn Guo
2026-08-15 13:33 ` sashiko-bot
2026-08-15 13:25 ` [PATCH 4/8] rpmsg: qcom_glink_ssr: Suppress cleanup " Shawn Guo
2026-08-15 13:36 ` sashiko-bot
2026-08-15 13:25 ` [PATCH 5/8] remoteproc: qcom: pas: Track HPASS ADSP cluster membership Shawn Guo
2026-08-17 13:18 ` Konrad Dybcio
2026-08-26 3:18 ` Shawn Guo
2026-08-15 13:25 ` [PATCH 6/8] remoteproc: qcom: pas: Sequence HPASS ADSP cluster boot root-first Shawn Guo
2026-08-15 13:34 ` sashiko-bot
2026-08-15 13:25 ` [PATCH 7/8] remoteproc: qcom: pas: Enforce coupled stop/crash for HPASS ADSP clusters Shawn Guo
2026-08-15 13:39 ` sashiko-bot
2026-08-15 13:25 ` [PATCH 8/8] remoteproc: qcom: pas: Add Nord ADSP1/2 support Shawn Guo
2026-08-17 13:19 ` [PATCH 0/8] remoteproc: qcom: Support the Nord HPASS ADSP cluster Konrad Dybcio
2026-08-26 2:55 ` 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=ao5Sg6QE9NN0P2zk@QCOM-aGQu4IUr3Y \
--to=shengchao.guo@oss.qualcomm.com \
--cc=andersson@kernel.org \
--cc=brgl@kernel.org \
--cc=conor+dt@kernel.org \
--cc=devicetree@vger.kernel.org \
--cc=krzk+dt@kernel.org \
--cc=krzk@kernel.org \
--cc=linux-arm-msm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-remoteproc@vger.kernel.org \
--cc=mathieu.poirier@linaro.org \
--cc=mukesh.ojha@oss.qualcomm.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.