From: Bjorn Andersson <andersson@kernel.org>
To: Shawn Guo <shengchao.guo@oss.qualcomm.com>
Cc: Konrad Dybcio <konradybcio@kernel.org>,
Rob Herring <robh@kernel.org>,
Krzysztof Kozlowski <krzk+dt@kernel.org>,
Conor Dooley <conor+dt@kernel.org>,
Bartosz Golaszewski <brgl@kernel.org>,
Deepti Jaggi <deepti.jaggi@oss.qualcomm.com>,
devicetree@vger.kernel.org, linux-arm-msm@vger.kernel.org,
linux-kernel@vger.kernel.org,
Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
Subject: Re: [PATCH v5 5/7] arm64: dts: qcom: Add device tree for Nord Embedded variant
Date: Sun, 12 Jul 2026 10:39:44 -0500 [thread overview]
Message-ID: <alOwD1G9plyy3BO4@baldur> (raw)
In-Reply-To: <20260709132013.4096850-6-shengchao.guo@oss.qualcomm.com>
On Thu, Jul 09, 2026 at 09:20:11PM +0800, Shawn Guo wrote:
> Unlike the GearVM variant, Nord Embedded variant has platform resources
> (clocks, regulators, powerdomains, pins, etc.) directly controlled by
> Linux.
We're writing DeviceTree here, our job is solely to express the hardware
and firmware interfaces using the agreed upon bindings.
As such resources are "directly controlled by the operating system" -
not "Linux".
That said, this is a good structured commit message, starting with
problem description, nicely done.
> Add a separate dtsi file extending the existing top-level
> nord.dtsi with nodes representing these peripherals as well as describing
> how they are wired up with the already defined components.
>
> Co-developed-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
> Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
> Signed-off-by: Shawn Guo <shengchao.guo@oss.qualcomm.com>
> ---
> arch/arm64/boot/dts/qcom/nord-embedded.dtsi | 1731 +++++++++++++++++++
> 1 file changed, 1731 insertions(+)
> create mode 100644 arch/arm64/boot/dts/qcom/nord-embedded.dtsi
>
> diff --git a/arch/arm64/boot/dts/qcom/nord-embedded.dtsi b/arch/arm64/boot/dts/qcom/nord-embedded.dtsi
[..]
> +/ {
> + clk_virt: interconnect-clk-virt {
> + compatible = "qcom,nord-clk-virt";
> + #interconnect-cells = <2>;
> + qcom,bcm-voters = <&apps_bcm_voter>;
> + };
> +
> + mc_virt: interconnect-mc-virt {
> + compatible = "qcom,nord-mc-virt";
> + #interconnect-cells = <2>;
> + qcom,bcm-voters = <&apps_bcm_voter>;
> + };
> +};
> +
> +&crypto {
Just to document my concern here as well, splitting the definition of
IP-blocks like this across two separate files makes it very hard for a
human to reason about what the actual platform dtsi looks like.
If the benefit of this reuse is worth the added complexity, I'm
accepting it, but it does means that I expect that any changes to
nord.dtsi will be tested across both models!
> + interconnects = <&aggre1_noc_tile MASTER_CRYPTO_CORE0 QCOM_ICC_TAG_ALWAYS
> + &mc_virt SLAVE_EBI1 QCOM_ICC_TAG_ALWAYS>;
> + interconnect-names = "memory";
> +};
[..]
> +&ufs_mem_hc {
> + reg = <0x0 0x01d44000 0x0 0x3000>,
> + <0x0 0x01d60000 0x0 0x15000>;
> + reg-names = "std",
> + "mcq";
All other changes in this patch directly relates to resource providers,
why does the UFS controller's mmio ranges change?
> +
> + clocks = <&negcc NE_GCC_UFS_PHY_AXI_CLK>,
> + <&negcc NE_GCC_AGGRE_NOC_UFS_PHY_AXI_CLK>,
> + <&negcc NE_GCC_UFS_PHY_AHB_CLK>,
> + <&negcc NE_GCC_UFS_PHY_UNIPRO_CORE_CLK>,
> + <&tcsrcc TCSR_UFS_CLKREF_EN>,
> + <&negcc NE_GCC_UFS_PHY_TX_SYMBOL_0_CLK>,
> + <&negcc NE_GCC_UFS_PHY_RX_SYMBOL_0_CLK>,
> + <&negcc NE_GCC_UFS_PHY_RX_SYMBOL_1_CLK>;
> + clock-names = "core_clk",
> + "bus_aggr_clk",
> + "iface_clk",
> + "core_clk_unipro",
> + "ref_clk",
> + "tx_lane0_sync_clk",
> + "rx_lane0_sync_clk",
> + "rx_lane1_sync_clk";
> +
> + resets = <&negcc NE_GCC_UFS_PHY_BCR>;
> + reset-names = "rst";
> +
> + interconnects = <&aggre1_noc_tile MASTER_UFS_MEM QCOM_ICC_TAG_ALWAYS
> + &mc_virt SLAVE_EBI1 QCOM_ICC_TAG_ALWAYS>,
> + <&hscnoc MASTER_APPSS_PROC QCOM_ICC_TAG_ACTIVE_ONLY
> + &config_noc SLAVE_UFS_MEM_CFG QCOM_ICC_TAG_ACTIVE_ONLY>;
> + interconnect-names = "ufs-ddr",
> + "cpu-ufs";
> +
> + phys = <&ufs_mem_phy>;
> + phy-names = "ufsphy";
> +
> + power-domains = <&negcc NE_GCC_UFS_PHY_GDSC>;
> + operating-points-v2 = <&ufs_opp_table>;
> + required-opps = <&rpmhpd_opp_nom>;
> + qcom,ice = <&ice>;
> + #reset-cells = <1>;
> +
> + status = "disabled";
> +
> + ufs_opp_table: opp-table {
> + compatible = "operating-points-v2";
> +
> + opp-100000000 {
> + opp-hz = /bits/ 64 <100000000>,
> + /bits/ 64 <0>,
> + /bits/ 64 <0>,
> + /bits/ 64 <100000000>,
> + /bits/ 64 <0>,
> + /bits/ 64 <0>,
> + /bits/ 64 <0>,
> + /bits/ 64 <0>;
> + required-opps = <&rpmhpd_opp_low_svs>;
> + };
> +
> + opp-201500000 {
> + opp-hz = /bits/ 64 <201500000>,
> + /bits/ 64 <0>,
> + /bits/ 64 <0>,
> + /bits/ 64 <201500000>,
> + /bits/ 64 <0>,
> + /bits/ 64 <0>,
> + /bits/ 64 <0>,
> + /bits/ 64 <0>;
> + required-opps = <&rpmhpd_opp_svs>;
> + };
> +
> + opp-403000000 {
> + opp-hz = /bits/ 64 <403000000>,
> + /bits/ 64 <0>,
> + /bits/ 64 <0>,
> + /bits/ 64 <403000000>,
> + /bits/ 64 <0>,
> + /bits/ 64 <0>,
> + /bits/ 64 <0>,
> + /bits/ 64 <0>;
> + required-opps = <&rpmhpd_opp_nom>;
> + };
> + };
> +};
> --
> 2.43.0
>
next prev parent reply other threads:[~2026-07-12 15:39 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-07-09 13:20 [PATCH v5 0/7] Add initial device trees for Nord platform Shawn Guo
2026-07-09 13:20 ` [PATCH v5 1/7] arm64: dts: qcom: Add device tree for Nord SoC series Shawn Guo
2026-07-09 13:38 ` sashiko-bot
2026-07-09 13:20 ` [PATCH v5 2/7] arm64: dts: qcom: Add device tree for Nord GearVM variant Shawn Guo
2026-07-09 13:51 ` sashiko-bot
2026-07-09 13:20 ` [PATCH v5 3/7] dt-bindings: arm: qcom: Document SA8797P Ride board Shawn Guo
2026-07-09 13:20 ` [PATCH v5 4/7] arm64: dts: qcom: Add device tree for " Shawn Guo
2026-07-09 13:20 ` [PATCH v5 5/7] arm64: dts: qcom: Add device tree for Nord Embedded variant Shawn Guo
2026-07-12 15:39 ` Bjorn Andersson [this message]
2026-07-14 12:15 ` Shawn Guo
2026-07-09 13:20 ` [PATCH v5 6/7] dt-bindings: arm: qcom: Document Nord IQ10 RRD board Shawn Guo
2026-07-10 7:04 ` Krzysztof Kozlowski
2026-07-10 7:07 ` Krzysztof Kozlowski
2026-07-14 12:16 ` Shawn Guo
2026-07-09 13:20 ` [PATCH v5 7/7] arm64: dts: qcom: Add device tree for " Shawn Guo
2026-07-09 14:30 ` sashiko-bot
2026-07-12 15:15 ` Bjorn Andersson
2026-07-14 12:21 ` 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=alOwD1G9plyy3BO4@baldur \
--to=andersson@kernel.org \
--cc=bartosz.golaszewski@oss.qualcomm.com \
--cc=brgl@kernel.org \
--cc=conor+dt@kernel.org \
--cc=deepti.jaggi@oss.qualcomm.com \
--cc=devicetree@vger.kernel.org \
--cc=konradybcio@kernel.org \
--cc=krzk+dt@kernel.org \
--cc=linux-arm-msm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=robh@kernel.org \
--cc=shengchao.guo@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 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.