From: Rohit Agarwal <quic_rohiagar@quicinc.com>
To: Konrad Dybcio <konrad.dybcio@linaro.org>, <agross@kernel.org>,
<andersson@kernel.org>, <robh+dt@kernel.org>,
<krzysztof.kozlowski+dt@linaro.org>, <conor+dt@kernel.org>,
<tglx@linutronix.de>, <maz@kernel.org>, <will@kernel.org>,
<robin.murphy@arm.com>, <joro@8bytes.org>, <robimarko@gmail.com>,
<quic_gurus@quicinc.com>
Cc: <linux-arm-msm@vger.kernel.org>, <devicetree@vger.kernel.org>,
<linux-kernel@vger.kernel.org>,
<linux-arm-kernel@lists.infradead.org>, <iommu@lists.linux.dev>
Subject: Re: [PATCH 5/8] arm64: dts: qcom: Add SDX75 platform and IDP board support
Date: Mon, 5 Jun 2023 12:28:42 +0530 [thread overview]
Message-ID: <2a775d11-346a-0dea-615e-51c2647b818a@quicinc.com> (raw)
In-Reply-To: <f839fd42-2d04-30b2-65b4-23df37a52f81@linaro.org>
On 5/30/2023 11:19 PM, Konrad Dybcio wrote:
>
> On 30.05.2023 13:40, Rohit Agarwal wrote:
>> Thanks for reviewing. Sorry for the late reply was on leave.
>>
>> On 5/19/2023 10:58 PM, Konrad Dybcio wrote:
>>> On 19.05.2023 11:09, Rohit Agarwal wrote:
>>>> Add basic devicetree support for SDX75 platform and IDP board from
>>>> Qualcomm. The SDX75 platform features an ARM Cortex A55 CPU which forms
>>>> the Application Processor Sub System (APSS) along with standard Qualcomm
>>>> peripherals like GCC, TLMM, UART, QPIC, and BAM etc... Also, there
>>>> exists the networking parts such as IPA, MHI, PCIE-EP, EMAC, and Modem
>>>> etc..
>>>>
>>>> This commit adds basic devicetree support.
>>>>
>>>> Signed-off-by: Rohit Agarwal <quic_rohiagar@quicinc.com>
>>>> ---
>>>> arch/arm64/boot/dts/qcom/Makefile | 1 +
>>>> arch/arm64/boot/dts/qcom/sdx75-idp.dts | 19 ++
>>>> arch/arm64/boot/dts/qcom/sdx75.dtsi | 534 +++++++++++++++++++++++++++++++++
>>>> 3 files changed, 554 insertions(+)
>>>> create mode 100644 arch/arm64/boot/dts/qcom/sdx75-idp.dts
>>>> create mode 100644 arch/arm64/boot/dts/qcom/sdx75.dtsi
>>>>
>>>> diff --git a/arch/arm64/boot/dts/qcom/Makefile b/arch/arm64/boot/dts/qcom/Makefile
>>>> index d42c595..4fd5a18 100644
>>>> --- a/arch/arm64/boot/dts/qcom/Makefile
>>>> +++ b/arch/arm64/boot/dts/qcom/Makefile
>>>> @@ -173,6 +173,7 @@ dtb-$(CONFIG_ARCH_QCOM) += sdm845-xiaomi-polaris.dtb
>>>> dtb-$(CONFIG_ARCH_QCOM) += sdm845-shift-axolotl.dtb
>>>> dtb-$(CONFIG_ARCH_QCOM) += sdm850-lenovo-yoga-c630.dtb
>>>> dtb-$(CONFIG_ARCH_QCOM) += sdm850-samsung-w737.dtb
>>>> +dtb-$(CONFIG_ARCH_QCOM) += sdx75-idp.dtb
>>>> dtb-$(CONFIG_ARCH_QCOM) += sm4250-oneplus-billie2.dtb
>>>> dtb-$(CONFIG_ARCH_QCOM) += sm6115p-lenovo-j606f.dtb
>>>> dtb-$(CONFIG_ARCH_QCOM) += sm6125-sony-xperia-seine-pdx201.dtb
>>>> diff --git a/arch/arm64/boot/dts/qcom/sdx75-idp.dts b/arch/arm64/boot/dts/qcom/sdx75-idp.dts
>>>> new file mode 100644
>>>> index 0000000..e2e803b
>>>> --- /dev/null
>>>> +++ b/arch/arm64/boot/dts/qcom/sdx75-idp.dts
>>>> @@ -0,0 +1,19 @@
>>>> +// SPDX-License-Identifier: BSD-3-Clause
>>>> +/*
>>>> + * Copyright (c) 2023 Qualcomm Innovation Center, Inc. All rights reserved.
>>>> + */
>>>> +
>>>> +/dts-v1/;
>>>> +
>>>> +#include "sdx75.dtsi"
>>>> +
>>>> +/ {
>>>> + model = "Qualcomm Technologies, Inc. SDX75 IDP";
>>>> + compatible = "qcom,sdx75-idp", "qcom,sdx75";
>>>> + qcom,board-id = <0x2010022 0x302>;
>>> You should be able to get by without qcom,{msm,board}-id.
>> Actually the bootloader requires the msm and board id. Shouldn't this become a necessary field then?
> We generally discourage that, especially since at least on the LA front
> it became unnecessary (no msm-id and appended dtb -> abl picks the only
> one present).. I'm not sure at what point in product dev the SDX75 is,
> but if we could get rid of that requirement, it'd be very nice..
>
> OTOH getting rid of it just on one device and keeping it necessary with
> fw builds that have been distributed to vendors sounds wouldn't be
> very beneficial either :/
Going deeper in the ABL code, Got to know that ABL does support the
single appended DTB.
So will go ahead and remove the board-id and msm-id from this.
Thanks,
Rohit.
>
> Konrad
>>>> +
>>>> +};
>>>> +
>>>> +&tlmm {
>>>> + gpio-reserved-ranges = <110 6>;
>>>> +};
>>>> diff --git a/arch/arm64/boot/dts/qcom/sdx75.dtsi b/arch/arm64/boot/dts/qcom/sdx75.dtsi
>>>> new file mode 100644
>>>> index 0000000..c2b8810
>>>> --- /dev/null
>>>> +++ b/arch/arm64/boot/dts/qcom/sdx75.dtsi
>>>> @@ -0,0 +1,534 @@
>>>> +// SPDX-License-Identifier: BSD-3-Clause
>>>> +/*
>>>> + * SDX75 SoC device tree source
>>>> + *
>>>> + * Copyright (c) 2023 Qualcomm Innovation Center, Inc. All rights reserved.
>>>> + *
>>>> + */
>>>> +
>>>> +#include <dt-bindings/clock/qcom,rpmh.h>
>>>> +#include <dt-bindings/interrupt-controller/arm-gic.h>
>>>> +#include <dt-bindings/soc/qcom,rpmh-rsc.h>
>>>> +
>>>> +/ {
>>>> + #address-cells = <2>;
>>>> + #size-cells = <2>;
>>>> + qcom,msm-id = <556 0x10000>;
>>>> + interrupt-parent = <&intc>;
>>>> +
>>>> + chosen: chosen { };
>>>> +
>>>> + memory {
>>> The memory node should have a unit address.
>> Sure will update this.
>>>> + device_type = "memory";
>>>> + reg = <0 0 0 0>;
>>>> + };
>>>> +
>>>> + clocks { };
>>>> +
>>>> + cpus {
>>>> + #address-cells = <2>;
>>>> + #size-cells = <0>;
>>>> +
>>> [...]
>>>
>>>> +
>>>> + CLUSTER_PD: power-domain-cpu-cluster0 {
>>>> + #power-domain-cells = <0>;
>>>> + domain-idle-states = <&CLUSTER_SLEEP_0 &CX_RET &CLUSTER_SLEEP_1>;
>>> Is CLUSTER_SLEEP_1 deeper than CX retention?
>> Yes
>>>> + };
>>>> + };
>>>> +
>>>> + firmware {
>>>> + scm: scm {
>>>> + compatible = "qcom,scm-sdx75", "qcom,scm";
>>>> + };
>>>> + };
>>>> +
>>>> + pmu {
>>>> + compatible = "arm,armv8-pmuv3";
>>>> + interrupts = <GIC_PPI 7 IRQ_TYPE_LEVEL_HIGH>;
>>>> + };
>>>> +
>>>> + reserved-memory {
>>>> + #address-cells = <2>;
>>>> + #size-cells = <2>;
>>>> + ranges;
>>>> +
>>>> + gunyah_hyp_mem: memory@80000000 {
>>> reserved memory subnodes should have meaningful node names, e.g.
>>>
>>> hypervisor@800...
>> Will update this.
>>>> + reg = <0x0 0x80000000 0x0 0x800000>;
>>>> + no-map;
>>>> + };
>>>> +
>>> [...]
>>>
>>>> +
>>>> + smem: qcom,smem {
>>>> + compatible = "qcom,smem";
>>>> + memory-region = <&smem_mem>;
>>>> + hwlocks = <&tcsr_mutex 3>;
>>>> + };
>>>> +
>>>> + soc: soc {
>>>> + #address-cells = <2>;
>>>> + #size-cells = <2>;
>>>> + ranges;
>>> Are the SoC buses limited to 32b addresses?
>> No, Will fix this in the next.
>>>> + compatible = "simple-bus";
>>> Compatible should go first.
>> Yes, Ok.
>>>> +
>>>> + tcsr_mutex: hwlock@1f40000 {
>>>> + compatible = "qcom,tcsr-mutex";
>>>> + reg = <0x0 0x01f40000 0x0 0x40000>;
>>>> + #hwlock-cells = <1>;
>>>> + };
>>>> +
>>>> + pdc: interrupt-controller@b220000 {
>>>> + compatible = "qcom,sdx75-pdc", "qcom,pdc";
>>>> + reg = <0x0 0xb220000 0x0 0x30000>,
>>>> + <0x0 0x174000f0 0x0 0x64>;
>>>> + qcom,pdc-ranges = <0 147 52>,
>>>> + <52 266 32>,
>>>> + <84 500 59>;
>>>> + #interrupt-cells = <2>;
>>>> + interrupt-parent = <&intc>;
>>>> + interrupt-controller;
>>>> + };
>>>> +
>>>> + tlmm: pinctrl@f000000 {
>>>> + compatible = "qcom,sdx75-tlmm";
>>>> + reg = <0x0 0x0f000000 0x0 0x400000>;
>>>> + interrupts = <GIC_SPI 212 IRQ_TYPE_LEVEL_HIGH>;
>>>> + gpio-controller;
>>>> + #gpio-cells = <2>;
>>>> + gpio-ranges = <&tlmm 0 0 133>;
>>>> + interrupt-controller;
>>>> + #interrupt-cells = <2>;
>>>> + wakeup-parent = <&pdc>;
>>>> + };
>>>> +
>>>> + apps_smmu: iommu@15000000 {
>>>> + compatible = "qcom,sdx75-smmu-500", "arm,mmu-500";
>>>> + reg = <0x0 0x15000000 0x0 0x40000>;
>>>> + #iommu-cells = <2>;
>>>> + #global-interrupts = <2>;
>>>> + interrupts = <GIC_SPI 65 IRQ_TYPE_LEVEL_HIGH>,
>>>> + <GIC_SPI 68 IRQ_TYPE_LEVEL_HIGH>,
>>>> + <GIC_SPI 69 IRQ_TYPE_LEVEL_HIGH>,
>>>> + <GIC_SPI 70 IRQ_TYPE_LEVEL_HIGH>,
>>>> + <GIC_SPI 71 IRQ_TYPE_LEVEL_HIGH>,
>>>> + <GIC_SPI 72 IRQ_TYPE_LEVEL_HIGH>,
>>>> + <GIC_SPI 73 IRQ_TYPE_LEVEL_HIGH>,
>>>> + <GIC_SPI 94 IRQ_TYPE_LEVEL_HIGH>,
>>>> + <GIC_SPI 95 IRQ_TYPE_LEVEL_HIGH>,
>>>> + <GIC_SPI 96 IRQ_TYPE_LEVEL_HIGH>,
>>>> + <GIC_SPI 97 IRQ_TYPE_LEVEL_HIGH>,
>>>> + <GIC_SPI 98 IRQ_TYPE_LEVEL_HIGH>,
>>>> + <GIC_SPI 99 IRQ_TYPE_LEVEL_HIGH>,
>>>> + <GIC_SPI 100 IRQ_TYPE_LEVEL_HIGH>,
>>>> + <GIC_SPI 101 IRQ_TYPE_LEVEL_HIGH>,
>>>> + <GIC_SPI 102 IRQ_TYPE_LEVEL_HIGH>,
>>>> + <GIC_SPI 103 IRQ_TYPE_LEVEL_HIGH>,
>>>> + <GIC_SPI 104 IRQ_TYPE_LEVEL_HIGH>,
>>>> + <GIC_SPI 105 IRQ_TYPE_LEVEL_HIGH>,
>>>> + <GIC_SPI 106 IRQ_TYPE_LEVEL_HIGH>,
>>>> + <GIC_SPI 107 IRQ_TYPE_LEVEL_HIGH>,
>>>> + <GIC_SPI 108 IRQ_TYPE_LEVEL_HIGH>,
>>>> + <GIC_SPI 109 IRQ_TYPE_LEVEL_HIGH>,
>>>> + <GIC_SPI 110 IRQ_TYPE_LEVEL_HIGH>,
>>>> + <GIC_SPI 298 IRQ_TYPE_LEVEL_HIGH>,
>>>> + <GIC_SPI 299 IRQ_TYPE_LEVEL_HIGH>,
>>>> + <GIC_SPI 300 IRQ_TYPE_LEVEL_HIGH>,
>>>> + <GIC_SPI 301 IRQ_TYPE_LEVEL_HIGH>,
>>>> + <GIC_SPI 302 IRQ_TYPE_LEVEL_HIGH>,
>>>> + <GIC_SPI 303 IRQ_TYPE_LEVEL_HIGH>,
>>>> + <GIC_SPI 304 IRQ_TYPE_LEVEL_HIGH>,
>>>> + <GIC_SPI 305 IRQ_TYPE_LEVEL_HIGH>,
>>>> + <GIC_SPI 306 IRQ_TYPE_LEVEL_HIGH>;
>>> Many newer SoCs have dma-coherent SMMUs. Is this the case here?
>> Yes, Will add the dma-coherent property here.
>>>> + };
>>>> +
>>>> + intc: interrupt-controller@17200000 {
>>>> + compatible = "arm,gic-v3";
>>>> + #interrupt-cells = <3>;
>>>> + interrupt-controller;
>>>> + #redistributor-regions = <1>;
>>>> + redistributor-stride = <0x0 0x20000>;
>>>> + reg = <0x0 0x17200000 0x0 0x10000>,
>>>> + <0x0 0x17260000 0x0 0x80000>;
>>>> + interrupts = <GIC_PPI 9 IRQ_TYPE_LEVEL_HIGH>;
>>>> + };
>>>> +
>>>> + timer@17420000 {
>>>> + compatible = "arm,armv7-timer-mem";
>>>> + #address-cells = <2>;
>>>> + #size-cells = <2>;
>>>> + ranges;
>>>> + reg = <0x0 0x17420000 0x0 0x1000>;
>>>> + clock-frequency = <19200000>;
>>> clock-frequency is discouraged, unless strictly necessary.
>>>
>>> Since gh is running, the timer is already programmed so it should be
>>> fine to drop this.
>>>
>>> [...]
>>>
>>>> + timer {
>>>> + compatible = "arm,armv8-timer";
>>>> + interrupts = <GIC_PPI 13 (GIC_CPU_MASK_SIMPLE(8) | IRQ_TYPE_LEVEL_LOW)>,
>>>> + <GIC_PPI 14 (GIC_CPU_MASK_SIMPLE(8) | IRQ_TYPE_LEVEL_LOW)>,
>>>> + <GIC_PPI 11 (GIC_CPU_MASK_SIMPLE(8) | IRQ_TYPE_LEVEL_LOW)>,
>>>> + <GIC_PPI 12 (GIC_CPU_MASK_SIMPLE(8) | IRQ_TYPE_LEVEL_LOW)>;
>>>> + clock-frequency = <19200000>;
>>> Ditto
>> Ok Thanks for the info. Dropping the clock frequency property in the next version.
>>
>> Thanks,
>> Rohit.
>>> Konrad
>>>> + };
>>>> +};
next prev parent reply other threads:[~2023-06-05 6:59 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-05-19 9:09 [PATCH 0/8] Add devicetree support for SDX75 Modem and IDP Rohit Agarwal
2023-05-19 9:09 ` [PATCH 1/8] dt-bindings: arm: qcom: Document SDX75 platform and boards Rohit Agarwal
2023-05-19 15:57 ` Conor Dooley
2023-05-19 9:09 ` [PATCH 2/8] dt-bindings: firmware: scm: Add compatible for SDX75 Rohit Agarwal
2023-05-19 16:00 ` Conor Dooley
2023-05-19 9:09 ` [PATCH 3/8] dt-bindings: interrupt-controller: Add SDX75 PDC compatible Rohit Agarwal
2023-05-19 15:58 ` Conor Dooley
2023-05-19 9:09 ` [PATCH 4/8] dt-bindings: arm-smmu: Add SDX75 SMMU compatible Rohit Agarwal
2023-05-19 16:00 ` Conor Dooley
2023-05-19 9:09 ` [PATCH 5/8] arm64: dts: qcom: Add SDX75 platform and IDP board support Rohit Agarwal
2023-05-19 17:28 ` Konrad Dybcio
2023-05-30 11:40 ` Rohit Agarwal
2023-05-30 17:49 ` Konrad Dybcio
2023-06-05 6:58 ` Rohit Agarwal [this message]
2023-05-19 9:09 ` [PATCH 6/8] arm64: dts: qcom: Add support for GCC and RPMHCC for SDX75 Rohit Agarwal
2023-05-20 10:08 ` kernel test robot
2023-05-26 20:59 ` Bjorn Andersson
2023-05-19 9:09 ` [PATCH 7/8] arm64: dts: qcom: Add QUPv3 UART console node " Rohit Agarwal
2023-05-19 9:09 ` [PATCH 8/8] arm64: dts: qcom: Enable the QUPv3 UART console " Rohit Agarwal
2023-06-05 16:35 ` [PATCH 0/8] Add devicetree support for SDX75 Modem and IDP Will Deacon
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=2a775d11-346a-0dea-615e-51c2647b818a@quicinc.com \
--to=quic_rohiagar@quicinc.com \
--cc=agross@kernel.org \
--cc=andersson@kernel.org \
--cc=conor+dt@kernel.org \
--cc=devicetree@vger.kernel.org \
--cc=iommu@lists.linux.dev \
--cc=joro@8bytes.org \
--cc=konrad.dybcio@linaro.org \
--cc=krzysztof.kozlowski+dt@linaro.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-arm-msm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=maz@kernel.org \
--cc=quic_gurus@quicinc.com \
--cc=robh+dt@kernel.org \
--cc=robimarko@gmail.com \
--cc=robin.murphy@arm.com \
--cc=tglx@linutronix.de \
--cc=will@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).