From: Konrad Dybcio <konrad.dybcio@linaro.org>
To: Komal Bajaj <quic_kbajaj@quicinc.com>,
Andy Gross <agross@kernel.org>,
Bjorn Andersson <andersson@kernel.org>,
Rob Herring <robh+dt@kernel.org>,
Krzysztof Kozlowski <krzysztof.kozlowski+dt@linaro.org>,
Conor Dooley <conor+dt@kernel.org>
Cc: linux-arm-msm@vger.kernel.org, devicetree@vger.kernel.org,
linux-kernel@vger.kernel.org,
Luca Weiss <luca.weiss@fairphone.com>
Subject: Re: [PATCH 2/2] arm64: dts: qcom: qcm6490: Add qcm6490 dts file
Date: Thu, 28 Sep 2023 15:46:39 +0200 [thread overview]
Message-ID: <661bd908-a056-4d46-97a3-d3b12b14c050@linaro.org> (raw)
In-Reply-To: <20230928133312.11371-3-quic_kbajaj@quicinc.com>
On 28.09.2023 15:33, Komal Bajaj wrote:
> Add qcm6490 devicetree file for QCM6490 SoC and QCM6490 IDP
> platform. QCM6490 is derived from SC7280 meant for various
> form factor including IoT.
>
> Supported features are, as of now:
> * Debug UART
> * eMMC
> * USB
>
> Signed-off-by: Komal Bajaj <quic_kbajaj@quicinc.com>
> ---
[...]
> +/ {
> + model = "Qualcomm Technologies, Inc. QCM6490 IDP platform";
Isomething Development Platform platform?
> + compatible = "qcom,qcm6490-idp", "qcom,qcm6490";
> +
> + aliases {
> + serial0 = &uart5;
> + };
> +
> + chosen {
> + stdout-path = "serial0:115200n8";
> + };
> +
> +};
Stray newline above
> +
> +&apps_rsc {
> + regulators-0 {
> + compatible = "qcom,pm7325-rpmh-regulators";
> + qcom,pmic-id = "b";
> +
> + vreg_s1b_1p8: smps1 {
> + regulator-min-microvolt = <1856000>;
> + regulator-max-microvolt = <2040000>;
Hm, you didn't specify regulator-initial-mode on any vregs
[...]
> --- /dev/null
> +++ b/arch/arm64/boot/dts/qcom/qcm6490.dtsi
> @@ -0,0 +1,137 @@
> +// SPDX-License-Identifier: BSD-3-Clause
> +/*
> + * Copyright (c) 2023 Qualcomm Innovation Center, Inc. All rights reserved.
> + */
> +
> +#include "sc7280.dtsi"
> +
> +/*
> + * Delete sc7280 lpass related nodes as qcm6490 intends to move away from
> + * bypass configuration
> + */
> +/delete-node/ &lpass_ag_noc;
> +/delete-node/ &lpass_aon;
> +/delete-node/ &lpass_audiocc;
> +/delete-node/ &lpass_core;
> +/delete-node/ &lpass_cpu;
> +/delete-node/ &lpass_hm;
> +/delete-node/ &lpass_rx_macro;
> +/delete-node/ &lpass_tx_macro;
> +/delete-node/ &lpass_va_macro;
> +/delete-node/ &lpass_tlmm;
> +/delete-node/ &lpasscc;
> +/delete-node/ &swr0;
> +/delete-node/ &swr1;
That's very unnecessary, most of these nodes are in use even
when routing audio through ADSP.
Ones that are not, are set to status = "reserved" and some
will need more work to function based on the configuration.
There was once a series from somebody at qc to introduce ADSP
audio on 7280, but it was full of hacks and NAKed
> +
> +/*
> + * Delete unused sc7280 memory nodes and define the memory regions
> + * required by qcm6490
> + */
That's specific to your board.
> +/delete-node/ &rmtfs_mem;
> +/delete-node/ &wlan_ce_mem;
> +
> +/{
> + reserved-memory {
> + secdata_apss_mem: secdata-apss@808ff000 {
> + reg = <0x0 0x808ff000 0x0 0x1000>;
> + no-map;
> + };
This is identical to the entry in sc7280.dtsi.
> +
> + cdsp_secure_heap_mem: cdsp-secure-heap@81800000 {
> + reg = <0x0 0x81800000 0x0 0x1e00000>;
> + no-map;
> + };
> +
> + camera_mem: camera@84300000 {
> + reg = <0x0 0x84300000 0x0 0x500000>;
> + no-map;
> + };
> +
> + adsp_mem: adsp@86100000 {
> + reg = <0x0 0x86100000 0x0 0x2800000>;
> + no-map;
> + };
> +
> + cdsp_mem: cdsp@88900000 {
> + reg = <0x0 0x88900000 0x0 0x1e00000>;
> + no-map;
> + };
> +
> + cvp_mem: cvp@8ac00000 {
> + reg = <0x0 0x8ac00000 0x0 0x500000>;
> + no-map;
> + };
> +
> + ipa_gsi_mem: ipa-gsi@8b110000 {
> + reg = <0x0 0x8b110000 0x0 0xa000>;
> + no-map;
> + };
> +
> + gpu_microcode_mem: gpu-microcode@8b11a000 {
> + reg = <0x0 0x8b11a000 0x0 0x2000>;
> + no-map;
> + };
> +
> + mpss_mem: mpss@8b800000 {
> + reg = <0x0 0x8b800000 0x0 0xf600000>;
> + no-map;
> + };
> +
> + wpss_mem: wpss@9ae00000 {
> + reg = <0x0 0x9ae00000 0x0 0x1900000>;
> + no-map;
> + };
This entry is in both chrome-common and fairphone (meaning all boards
use it), perhaps this one could be moved to 7280.dtsi
> +
> + tz_stat_mem: tz-stat@c0000000 {
> + reg = <0x0 0xc0000000 0x0 0x100000>;
> + no-map;
> + };
> +
> + tags_mem: tags@c0100000 {
> + reg = <0x0 0xc0100000 0x0 0x1200000>;
> + no-map;
> + };
> +
> + qtee_mem: qtee@c1300000 {
> + reg = <0x0 0xc1300000 0x0 0x500000>;
> + no-map;
> + };
> +
> + trusted_apps_mem: trusted_apps@c1800000 {
> + reg = <0x0 0xc1800000 0x0 0x3900000>;
> + no-map;
> + };
> + };
> +};
> +
> +&hyp_mem {
> + reg = <0x0 0x80000000 0x0 0x600000>;
This is identical to the entry in sc7280.dtsi.
> +};
> +
> +&mpss_mem {
> + reg = <0x0 0x8b800000 0x0 0xf600000>;
You're defining it here and overwriting it with an identical
value.
Looks like CrOS folks don't boot up the modem on non-LTE SKUs.
Weird. Normally it would host some more software..
> +};
> +
> +&remoteproc_mpss {
> + memory-region = <&mpss_mem>;
This is identical to the entry in sc7280.dtsi.
> +};
> +
> +&video_mem {
> + reg = <0x0 0x8a700000 0x0 0x500000>;
> +};
> +
> +&wifi {
> + memory-region = <&wlan_fw_mem>;
No CE region?
> +};
> +
> +&wlan_fw_mem {
> + reg = <0x0 0x80c00000 0x0 0xc00000>;
This is identical to the entry in sc7280.dtsi.
The memory map generally looks quite different to both chrome
and fairphone.. are you sure it's all correct?
Konrad
next prev parent reply other threads:[~2023-09-28 13:46 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-09-28 13:33 [PATCH 0/2] Initial support for the QCM6490 IDP Komal Bajaj
2023-09-28 13:33 ` [PATCH 1/2] dt-bindings: arm: qcom: Add QCM6490 IDP board Komal Bajaj
2023-09-30 15:43 ` Krzysztof Kozlowski
2023-09-28 13:33 ` [PATCH 2/2] arm64: dts: qcom: qcm6490: Add qcm6490 dts file Komal Bajaj
2023-09-28 13:46 ` Konrad Dybcio [this message]
2023-09-29 11:12 ` Komal Bajaj
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=661bd908-a056-4d46-97a3-d3b12b14c050@linaro.org \
--to=konrad.dybcio@linaro.org \
--cc=agross@kernel.org \
--cc=andersson@kernel.org \
--cc=conor+dt@kernel.org \
--cc=devicetree@vger.kernel.org \
--cc=krzysztof.kozlowski+dt@linaro.org \
--cc=linux-arm-msm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=luca.weiss@fairphone.com \
--cc=quic_kbajaj@quicinc.com \
--cc=robh+dt@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;
as well as URLs for NNTP newsgroup(s).