The Linux Kernel Mailing List
 help / color / mirror / Atom feed
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
> 

  reply	other threads:[~2026-07-12 15:39 UTC|newest]

Thread overview: 12+ 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:20 ` [PATCH v5 2/7] arm64: dts: qcom: Add device tree for Nord GearVM variant Shawn Guo
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-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-09 13:20 ` [PATCH v5 7/7] arm64: dts: qcom: Add device tree for " Shawn Guo
2026-07-12 15:15   ` Bjorn Andersson

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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox