| lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
|
Open Source and information security mailing list archives
| ||
|
Message-ID: <ec664db0-ae0f-5046-25c4-315d0a2c8a3f@quicinc.com>
Date: Tue, 30 May 2023 17:10:31 +0530
From: Rohit Agarwal <quic_rohiagar@...cinc.com>
To: Konrad Dybcio <konrad.dybcio@...aro.org>, <agross@...nel.org>,
<andersson@...nel.org>, <robh+dt@...nel.org>,
<krzysztof.kozlowski+dt@...aro.org>, <conor+dt@...nel.org>,
<tglx@...utronix.de>, <maz@...nel.org>, <will@...nel.org>,
<robin.murphy@....com>, <joro@...tes.org>, <robimarko@...il.com>,
<quic_gurus@...cinc.com>
CC: <linux-arm-msm@...r.kernel.org>, <devicetree@...r.kernel.org>,
<linux-kernel@...r.kernel.org>,
<linux-arm-kernel@...ts.infradead.org>, <iommu@...ts.linux.dev>
Subject: Re: [PATCH 5/8] arm64: dts: qcom: Add SDX75 platform and IDP board
support
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@...cinc.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?
>
>> +
>> +};
>> +
>> +&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@...00000 {
> reserved memory subnodes should have meaningful node names, e.g.
>
> hypervisor@......
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@...0000 {
>> + compatible = "qcom,tcsr-mutex";
>> + reg = <0x0 0x01f40000 0x0 0x40000>;
>> + #hwlock-cells = <1>;
>> + };
>> +
>> + pdc: interrupt-controller@...0000 {
>> + 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@...0000 {
>> + 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@...00000 {
>> + 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@...00000 {
>> + 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@...20000 {
>> + 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
>> + };
>> +};
Powered by blists - more mailing lists