* [RFC PATCH 0/2] Add support for qcm6490 idp and rb3 board @ 2023-11-03 18:46 Komal Bajaj 2023-11-03 18:46 ` [RFC PATCH 1/2] dt-bindings: arm: qcom: Add QCM6490 IDP and RB3 board Komal Bajaj 2023-11-03 18:46 ` [RFC PATCH 2/2] arm64: dts: qcom: qcm6490: Add qcm6490 idp and rb3 board Komal Bajaj 0 siblings, 2 replies; 20+ messages in thread From: Komal Bajaj @ 2023-11-03 18:46 UTC (permalink / raw) To: Andy Gross, Bjorn Andersson, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski, Conor Dooley Cc: linux-arm-msm, devicetree, linux-kernel, quic_nainmeht, Komal Bajaj The patch series is following from the discussion [1] and taking the suggestion, it is introducing a common dtsi, qcm6490-iot-common.dtsi, for IOT segment which would facilitate abstracting the memory map required for IOT without impacting SC7280 and avoid code duplication for the boards based on QCM6490. We would be posting the memory map changes subsequently once we converge on the approach. The series also introduces two boards for QCM6490, IDP and RB3. [1] https://lore.kernel.org/linux-arm-msm/d97ebf74-ad03-86d6-b826-b57be209b9e2@quicinc.com/ Komal Bajaj (2): dt-bindings: arm: qcom: Add QCM6490 IDP and RB3 board arm64: dts: qcom: qcm6490: Add qcm6490 idp and rb3 board .../devicetree/bindings/arm/qcom.yaml | 2 + arch/arm64/boot/dts/qcom/Makefile | 2 + arch/arm64/boot/dts/qcom/qcm6490-idp.dts | 33 ++ .../boot/dts/qcom/qcm6490-iot-common.dtsi | 291 ++++++++++++++++++ arch/arm64/boot/dts/qcom/qcm6490-rb3.dts | 26 ++ 5 files changed, 354 insertions(+) create mode 100644 arch/arm64/boot/dts/qcom/qcm6490-idp.dts create mode 100644 arch/arm64/boot/dts/qcom/qcm6490-iot-common.dtsi create mode 100644 arch/arm64/boot/dts/qcom/qcm6490-rb3.dts -- 2.42.0 ^ permalink raw reply [flat|nested] 20+ messages in thread
* [RFC PATCH 1/2] dt-bindings: arm: qcom: Add QCM6490 IDP and RB3 board 2023-11-03 18:46 [RFC PATCH 0/2] Add support for qcm6490 idp and rb3 board Komal Bajaj @ 2023-11-03 18:46 ` Komal Bajaj 2023-11-05 13:06 ` Krzysztof Kozlowski 2023-11-03 18:46 ` [RFC PATCH 2/2] arm64: dts: qcom: qcm6490: Add qcm6490 idp and rb3 board Komal Bajaj 1 sibling, 1 reply; 20+ messages in thread From: Komal Bajaj @ 2023-11-03 18:46 UTC (permalink / raw) To: Andy Gross, Bjorn Andersson, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski, Conor Dooley Cc: linux-arm-msm, devicetree, linux-kernel, quic_nainmeht, Komal Bajaj Document the qcom,qcm6490-idp and qcm6490-rb3 board based off qcm6490 SoC. Co-developed-by: Naina Mehta <quic_nainmeht@quicinc.com> Signed-off-by: Naina Mehta <quic_nainmeht@quicinc.com> Signed-off-by: Komal Bajaj <quic_kbajaj@quicinc.com> --- Documentation/devicetree/bindings/arm/qcom.yaml | 2 ++ 1 file changed, 2 insertions(+) diff --git a/Documentation/devicetree/bindings/arm/qcom.yaml b/Documentation/devicetree/bindings/arm/qcom.yaml index 76934f4772e9..6f8a08d2eb99 100644 --- a/Documentation/devicetree/bindings/arm/qcom.yaml +++ b/Documentation/devicetree/bindings/arm/qcom.yaml @@ -395,6 +395,8 @@ properties: - items: - enum: - fairphone,fp5 + - qcom,qcm6490-idp + - qcom,qcm6490-rb3 - const: qcom,qcm6490 - description: Qualcomm Technologies, Inc. Distributed Unit 1000 platform -- 2.42.0 ^ permalink raw reply related [flat|nested] 20+ messages in thread
* Re: [RFC PATCH 1/2] dt-bindings: arm: qcom: Add QCM6490 IDP and RB3 board 2023-11-03 18:46 ` [RFC PATCH 1/2] dt-bindings: arm: qcom: Add QCM6490 IDP and RB3 board Komal Bajaj @ 2023-11-05 13:06 ` Krzysztof Kozlowski 0 siblings, 0 replies; 20+ messages in thread From: Krzysztof Kozlowski @ 2023-11-05 13:06 UTC (permalink / raw) To: Komal Bajaj, Andy Gross, Bjorn Andersson, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski, Conor Dooley Cc: linux-arm-msm, devicetree, linux-kernel, quic_nainmeht On 03/11/2023 19:46, Komal Bajaj wrote: > Document the qcom,qcm6490-idp and qcm6490-rb3 board based off > qcm6490 SoC. > > Co-developed-by: Naina Mehta <quic_nainmeht@quicinc.com> > Signed-off-by: Naina Mehta <quic_nainmeht@quicinc.com> > Signed-off-by: Komal Bajaj <quic_kbajaj@quicinc.com> Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Best regards, Krzysztof ^ permalink raw reply [flat|nested] 20+ messages in thread
* [RFC PATCH 2/2] arm64: dts: qcom: qcm6490: Add qcm6490 idp and rb3 board 2023-11-03 18:46 [RFC PATCH 0/2] Add support for qcm6490 idp and rb3 board Komal Bajaj 2023-11-03 18:46 ` [RFC PATCH 1/2] dt-bindings: arm: qcom: Add QCM6490 IDP and RB3 board Komal Bajaj @ 2023-11-03 18:46 ` Komal Bajaj 2023-11-03 22:22 ` Dmitry Baryshkov 2023-11-04 12:32 ` Konrad Dybcio 1 sibling, 2 replies; 20+ messages in thread From: Komal Bajaj @ 2023-11-03 18:46 UTC (permalink / raw) To: Andy Gross, Bjorn Andersson, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski, Conor Dooley Cc: linux-arm-msm, devicetree, linux-kernel, quic_nainmeht, Komal Bajaj Add qcm6490 devicetree file for QCM6490 IDP and QCM6490 RB3 platform. QCM6490 is derived from SC7280 meant for various form factor including IoT. Supported features are, as of now: * Debug UART * eMMC (only in IDP) * USB Co-developed-by: Naina Mehta <quic_nainmeht@quicinc.com> Signed-off-by: Naina Mehta <quic_nainmeht@quicinc.com> Signed-off-by: Komal Bajaj <quic_kbajaj@quicinc.com> --- arch/arm64/boot/dts/qcom/Makefile | 2 + arch/arm64/boot/dts/qcom/qcm6490-idp.dts | 33 ++ .../boot/dts/qcom/qcm6490-iot-common.dtsi | 291 ++++++++++++++++++ arch/arm64/boot/dts/qcom/qcm6490-rb3.dts | 26 ++ 4 files changed, 352 insertions(+) create mode 100644 arch/arm64/boot/dts/qcom/qcm6490-idp.dts create mode 100644 arch/arm64/boot/dts/qcom/qcm6490-iot-common.dtsi create mode 100644 arch/arm64/boot/dts/qcom/qcm6490-rb3.dts diff --git a/arch/arm64/boot/dts/qcom/Makefile b/arch/arm64/boot/dts/qcom/Makefile index 73c3be0f8872..29cd77000970 100644 --- a/arch/arm64/boot/dts/qcom/Makefile +++ b/arch/arm64/boot/dts/qcom/Makefile @@ -82,6 +82,8 @@ dtb-$(CONFIG_ARCH_QCOM) += msm8998-sony-xperia-yoshino-maple.dtb dtb-$(CONFIG_ARCH_QCOM) += msm8998-sony-xperia-yoshino-poplar.dtb dtb-$(CONFIG_ARCH_QCOM) += msm8998-xiaomi-sagit.dtb dtb-$(CONFIG_ARCH_QCOM) += qcm6490-fairphone-fp5.dtb +dtb-$(CONFIG_ARCH_QCOM) += qcm6490-idp.dtb +dtb-$(CONFIG_ARCH_QCOM) += qcm6490-rb3.dtb dtb-$(CONFIG_ARCH_QCOM) += qcs404-evb-1000.dtb dtb-$(CONFIG_ARCH_QCOM) += qcs404-evb-4000.dtb dtb-$(CONFIG_ARCH_QCOM) += qdu1000-idp.dtb diff --git a/arch/arm64/boot/dts/qcom/qcm6490-idp.dts b/arch/arm64/boot/dts/qcom/qcm6490-idp.dts new file mode 100644 index 000000000000..b1d1b8f40bdb --- /dev/null +++ b/arch/arm64/boot/dts/qcom/qcm6490-idp.dts @@ -0,0 +1,33 @@ +// SPDX-License-Identifier: BSD-3-Clause +/* + * Copyright (c) 2023 Qualcomm Innovation Center, Inc. All rights reserved. + */ + +/dts-v1/; + +#include "qcm6490-iot-common.dtsi" + +/ { + model = "Qualcomm Technologies, Inc. QCM6490 IDP"; + compatible = "qcom,qcm6490-idp", "qcom,qcm6490"; + + aliases { + serial0 = &uart5; + }; + + chosen { + stdout-path = "serial0:115200n8"; + }; +}; + +&sdhc_1 { + non-removable; + no-sd; + no-sdio; + + vmmc-supply = <&vreg_l7b_2p952>; + vqmmc-supply = <&vreg_l19b_1p8>; + + status = "okay"; +}; + diff --git a/arch/arm64/boot/dts/qcom/qcm6490-iot-common.dtsi b/arch/arm64/boot/dts/qcom/qcm6490-iot-common.dtsi new file mode 100644 index 000000000000..01adc97789d0 --- /dev/null +++ b/arch/arm64/boot/dts/qcom/qcm6490-iot-common.dtsi @@ -0,0 +1,291 @@ +// SPDX-License-Identifier: BSD-3-Clause +/* + * Copyright (c) 2023 Qualcomm Innovation Center, Inc. All rights reserved. + */ + +#include <dt-bindings/regulator/qcom,rpmh-regulator.h> +#include "sc7280.dtsi" +#include "pm7325.dtsi" +#include "pm8350c.dtsi" +#include "pmk8350.dtsi" + +&apps_rsc { + regulators-0 { + compatible = "qcom,pm7325-rpmh-regulators"; + qcom,pmic-id = "b"; + + vreg_s1b_1p872: smps1 { + regulator-min-microvolt = <1840000>; + regulator-max-microvolt = <2040000>; + }; + + vreg_s2b_0p876: smps2 { + regulator-min-microvolt = <570070>; + regulator-max-microvolt = <1050000>; + }; + + vreg_s7b_0p972: smps7 { + regulator-min-microvolt = <535000>; + regulator-max-microvolt = <1120000>; + }; + + vreg_s8b_1p272: smps8 { + regulator-min-microvolt = <1200000>; + regulator-max-microvolt = <1500000>; + regulator-initial-mode = <RPMH_REGULATOR_MODE_RET>; + }; + + vreg_l1b_0p912: ldo1 { + regulator-min-microvolt = <825000>; + regulator-max-microvolt = <925000>; + regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>; + }; + + vreg_l2b_3p072: ldo2 { + regulator-min-microvolt = <2700000>; + regulator-max-microvolt = <3544000>; + regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>; + }; + + vreg_l3b_0p504: ldo3 { + regulator-min-microvolt = <312000>; + regulator-max-microvolt = <910000>; + regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>; + }; + + vreg_l4b_0p752: ldo4 { + regulator-min-microvolt = <752000>; + regulator-max-microvolt = <820000>; + regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>; + }; + + reg_l5b_0p752: ldo5 { + regulator-min-microvolt = <552000>; + regulator-max-microvolt = <832000>; + regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>; + }; + + vreg_l6b_1p2: ldo6 { + regulator-min-microvolt = <1140000>; + regulator-max-microvolt = <1260000>; + regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>; + }; + + vreg_l7b_2p952: ldo7 { + regulator-min-microvolt = <2400000>; + regulator-max-microvolt = <3544000>; + regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>; + }; + + vreg_l8b_0p904: ldo8 { + regulator-min-microvolt = <870000>; + regulator-max-microvolt = <970000>; + regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>; + }; + + vreg_l9b_1p2: ldo9 { + regulator-min-microvolt = <1200000>; + regulator-max-microvolt = <1304000>; + regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>; + }; + + vreg_l11b_1p504: ldo11 { + regulator-min-microvolt = <1504000>; + regulator-max-microvolt = <2000000>; + regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>; + }; + + vreg_l12b_0p751: ldo12 { + regulator-min-microvolt = <751000>; + regulator-max-microvolt = <824000>; + regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>; + }; + + vreg_l13b_0p53: ldo13 { + regulator-min-microvolt = <530000>; + regulator-max-microvolt = <824000>; + regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>; + }; + + vreg_l14b_1p08: ldo14 { + regulator-min-microvolt = <1080000>; + regulator-max-microvolt = <1304000>; + regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>; + }; + + vreg_l15b_0p765: ldo15 { + regulator-min-microvolt = <765000>; + regulator-max-microvolt = <1020000>; + regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>; + }; + + vreg_l16b_1p1: ldo16 { + regulator-min-microvolt = <1100000>; + regulator-max-microvolt = <1300000>; + regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>; + }; + + vreg_l17b_1p7: ldo17 { + regulator-min-microvolt = <1700000>; + regulator-max-microvolt = <1900000>; + regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>; + }; + + vreg_l18b_1p8: ldo18 { + regulator-min-microvolt = <1800000>; + regulator-max-microvolt = <2000000>; + regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>; + }; + + vreg_l19b_1p8: ldo19 { + regulator-min-microvolt = <1800000>; + regulator-max-microvolt = <2000000>; + regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>; + }; + }; + + regulators-1 { + compatible = "qcom,pm8350c-rpmh-regulators"; + qcom,pmic-id = "c"; + + vreg_s1c_2p19: smps1 { + regulator-min-microvolt = <2190000>; + regulator-max-microvolt = <2210000>; + }; + + vreg_s2c_0p752: smps2 { + regulator-min-microvolt = <750000>; + regulator-max-microvolt = <800000>; + }; + + vreg_s5c_0p752: smps5 { + regulator-min-microvolt = <465000>; + regulator-max-microvolt = <1050000>; + }; + + vreg_s7c_0p752: smps7 { + regulator-min-microvolt = <465000>; + regulator-max-microvolt = <800000>; + }; + + vreg_s9c_1p084: smps9 { + regulator-min-microvolt = <1010000>; + regulator-max-microvolt = <1170000>; + }; + + vreg_l1c_1p8: ldo1 { + regulator-min-microvolt = <1800000>; + regulator-max-microvolt = <1980000>; + regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>; + }; + + vreg_l2c_1p62: ldo2 { + regulator-min-microvolt = <1620000>; + regulator-max-microvolt = <1980000>; + regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>; + }; + + vreg_l3c_2p8: ldo3 { + regulator-min-microvolt = <2800000>; + regulator-max-microvolt = <3540000>; + regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>; + }; + + vreg_l4c_1p62: ldo4 { + regulator-min-microvolt = <1620000>; + regulator-max-microvolt = <3300000>; + regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>; + }; + + vreg_l5c_1p62: ldo5 { + regulator-min-microvolt = <1620000>; + regulator-max-microvolt = <3300000>; + regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>; + }; + + vreg_l6c_2p96: ldo6 { + regulator-min-microvolt = <1650000>; + regulator-max-microvolt = <3544000>; + regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>; + }; + + vreg_l7c_3p0: ldo7 { + regulator-min-microvolt = <3000000>; + regulator-max-microvolt = <3544000>; + regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>; + }; + + vreg_l8c_1p62: ldo8 { + regulator-min-microvolt = <1620000>; + regulator-max-microvolt = <2000000>; + regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>; + }; + + vreg_l9c_2p96: ldo9 { + regulator-min-microvolt = <2700000>; + regulator-max-microvolt = <35440000>; + regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>; + }; + + vreg_l10c_0p88: ldo10 { + regulator-min-microvolt = <720000>; + regulator-max-microvolt = <1050000>; + regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>; + }; + + vreg_l11c_2p8: ldo11 { + regulator-min-microvolt = <2800000>; + regulator-max-microvolt = <3544000>; + regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>; + }; + + vreg_l12c_1p65: ldo12 { + regulator-min-microvolt = <1650000>; + regulator-max-microvolt = <2000000>; + regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>; + }; + + vreg_l13c_2p7: ldo13 { + regulator-min-microvolt = <2700000>; + regulator-max-microvolt = <3544000>; + regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>; + }; + + vreg_bob_3p296: bob { + regulator-min-microvolt = <3008000>; + regulator-max-microvolt = <3960000>; + }; + }; +}; + +&qupv3_id_0 { + status = "okay"; +}; + +&uart5 { + compatible = "qcom,geni-debug-uart"; + status = "okay"; +}; + +&usb_1 { + status = "okay"; +}; + +&usb_1_dwc3 { + dr_mode = "peripheral"; +}; + +&usb_1_hsphy { + vdda-pll-supply = <&vreg_l10c_0p88>; + vdda33-supply = <&vreg_l2b_3p072>; + vdda18-supply = <&vreg_l1c_1p8>; + + status = "okay"; +}; + +&usb_1_qmpphy { + vdda-phy-supply = <&vreg_l6b_1p2>; + vdda-pll-supply = <&vreg_l1b_0p912>; + + status = "okay"; +}; diff --git a/arch/arm64/boot/dts/qcom/qcm6490-rb3.dts b/arch/arm64/boot/dts/qcom/qcm6490-rb3.dts new file mode 100644 index 000000000000..5b4c2826ac5c --- /dev/null +++ b/arch/arm64/boot/dts/qcom/qcm6490-rb3.dts @@ -0,0 +1,26 @@ +// SPDX-License-Identifier: BSD-3-Clause +/* + * Copyright (c) 2023 Qualcomm Innovation Center, Inc. All rights reserved. + */ + +/dts-v1/; + +/* PM7250B is configured to use SID8/9 */ +#define PM7250B_SID 8 +#define PM7250B_SID1 9 + +#include "qcm6490-iot-common.dtsi" +#include "pm7250b.dtsi" + +/ { + model = "Qualcomm Technologies, Inc. QCM6490 RB3"; + compatible = "qcom,qcm6490-rb3", "qcom,qcm6490"; + + aliases { + serial0 = &uart5; + }; + + chosen { + stdout-path = "serial0:115200n8"; + }; +}; -- 2.42.0 ^ permalink raw reply related [flat|nested] 20+ messages in thread
* Re: [RFC PATCH 2/2] arm64: dts: qcom: qcm6490: Add qcm6490 idp and rb3 board 2023-11-03 18:46 ` [RFC PATCH 2/2] arm64: dts: qcom: qcm6490: Add qcm6490 idp and rb3 board Komal Bajaj @ 2023-11-03 22:22 ` Dmitry Baryshkov 2023-11-05 13:08 ` Krzysztof Kozlowski [not found] ` <4d8c094f-07b0-2b38-4680-145eb2d7c4f5@quicinc.com> 2023-11-04 12:32 ` Konrad Dybcio 1 sibling, 2 replies; 20+ messages in thread From: Dmitry Baryshkov @ 2023-11-03 22:22 UTC (permalink / raw) To: Komal Bajaj Cc: Andy Gross, Bjorn Andersson, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski, Conor Dooley, linux-arm-msm, devicetree, linux-kernel, quic_nainmeht On Fri, 3 Nov 2023 at 20:49, Komal Bajaj <quic_kbajaj@quicinc.com> wrote: > > Add qcm6490 devicetree file for QCM6490 IDP and QCM6490 RB3 > platform. QCM6490 is derived from SC7280 meant for various > form factor including IoT. > > Supported features are, as of now: > * Debug UART > * eMMC (only in IDP) > * USB > > Co-developed-by: Naina Mehta <quic_nainmeht@quicinc.com> > Signed-off-by: Naina Mehta <quic_nainmeht@quicinc.com> > Signed-off-by: Komal Bajaj <quic_kbajaj@quicinc.com> > --- > arch/arm64/boot/dts/qcom/Makefile | 2 + > arch/arm64/boot/dts/qcom/qcm6490-idp.dts | 33 ++ > .../boot/dts/qcom/qcm6490-iot-common.dtsi | 291 ++++++++++++++++++ > arch/arm64/boot/dts/qcom/qcm6490-rb3.dts | 26 ++ > 4 files changed, 352 insertions(+) > create mode 100644 arch/arm64/boot/dts/qcom/qcm6490-idp.dts > create mode 100644 arch/arm64/boot/dts/qcom/qcm6490-iot-common.dtsi > create mode 100644 arch/arm64/boot/dts/qcom/qcm6490-rb3.dts > > diff --git a/arch/arm64/boot/dts/qcom/Makefile b/arch/arm64/boot/dts/qcom/Makefile > index 73c3be0f8872..29cd77000970 100644 > --- a/arch/arm64/boot/dts/qcom/Makefile > +++ b/arch/arm64/boot/dts/qcom/Makefile > @@ -82,6 +82,8 @@ dtb-$(CONFIG_ARCH_QCOM) += msm8998-sony-xperia-yoshino-maple.dtb > dtb-$(CONFIG_ARCH_QCOM) += msm8998-sony-xperia-yoshino-poplar.dtb > dtb-$(CONFIG_ARCH_QCOM) += msm8998-xiaomi-sagit.dtb > dtb-$(CONFIG_ARCH_QCOM) += qcm6490-fairphone-fp5.dtb > +dtb-$(CONFIG_ARCH_QCOM) += qcm6490-idp.dtb > +dtb-$(CONFIG_ARCH_QCOM) += qcm6490-rb3.dtb > dtb-$(CONFIG_ARCH_QCOM) += qcs404-evb-1000.dtb > dtb-$(CONFIG_ARCH_QCOM) += qcs404-evb-4000.dtb > dtb-$(CONFIG_ARCH_QCOM) += qdu1000-idp.dtb > diff --git a/arch/arm64/boot/dts/qcom/qcm6490-idp.dts b/arch/arm64/boot/dts/qcom/qcm6490-idp.dts > new file mode 100644 > index 000000000000..b1d1b8f40bdb > --- /dev/null > +++ b/arch/arm64/boot/dts/qcom/qcm6490-idp.dts > @@ -0,0 +1,33 @@ > +// SPDX-License-Identifier: BSD-3-Clause > +/* > + * Copyright (c) 2023 Qualcomm Innovation Center, Inc. All rights reserved. > + */ > + > +/dts-v1/; > + > +#include "qcm6490-iot-common.dtsi" > + > +/ { > + model = "Qualcomm Technologies, Inc. QCM6490 IDP"; > + compatible = "qcom,qcm6490-idp", "qcom,qcm6490"; > + > + aliases { > + serial0 = &uart5; > + }; > + > + chosen { > + stdout-path = "serial0:115200n8"; > + }; > +}; > + > +&sdhc_1 { > + non-removable; > + no-sd; > + no-sdio; > + > + vmmc-supply = <&vreg_l7b_2p952>; > + vqmmc-supply = <&vreg_l19b_1p8>; > + > + status = "okay"; > +}; > + > diff --git a/arch/arm64/boot/dts/qcom/qcm6490-iot-common.dtsi b/arch/arm64/boot/dts/qcom/qcm6490-iot-common.dtsi > new file mode 100644 > index 000000000000..01adc97789d0 > --- /dev/null > +++ b/arch/arm64/boot/dts/qcom/qcm6490-iot-common.dtsi I have mixed feelings towards this file. Usually we add such 'common' files only for the phone platforms where most of the devices are common. Do you expect that IDP and RB3 will have a lot of common code other than these regulator settings? > @@ -0,0 +1,291 @@ > +// SPDX-License-Identifier: BSD-3-Clause > +/* > + * Copyright (c) 2023 Qualcomm Innovation Center, Inc. All rights reserved. > + */ > + > +#include <dt-bindings/regulator/qcom,rpmh-regulator.h> > +#include "sc7280.dtsi" > +#include "pm7325.dtsi" > +#include "pm8350c.dtsi" > +#include "pmk8350.dtsi" > + > +&apps_rsc { > + regulators-0 { > + compatible = "qcom,pm7325-rpmh-regulators"; > + qcom,pmic-id = "b"; > + > + vreg_s1b_1p872: smps1 { > + regulator-min-microvolt = <1840000>; > + regulator-max-microvolt = <2040000>; > + }; > + > + vreg_s2b_0p876: smps2 { > + regulator-min-microvolt = <570070>; > + regulator-max-microvolt = <1050000>; > + }; > + > + vreg_s7b_0p972: smps7 { > + regulator-min-microvolt = <535000>; > + regulator-max-microvolt = <1120000>; > + }; > + > + vreg_s8b_1p272: smps8 { > + regulator-min-microvolt = <1200000>; > + regulator-max-microvolt = <1500000>; > + regulator-initial-mode = <RPMH_REGULATOR_MODE_RET>; > + }; > + > + vreg_l1b_0p912: ldo1 { > + regulator-min-microvolt = <825000>; > + regulator-max-microvolt = <925000>; > + regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>; > + }; > + > + vreg_l2b_3p072: ldo2 { > + regulator-min-microvolt = <2700000>; > + regulator-max-microvolt = <3544000>; > + regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>; > + }; > + > + vreg_l3b_0p504: ldo3 { > + regulator-min-microvolt = <312000>; > + regulator-max-microvolt = <910000>; > + regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>; > + }; > + > + vreg_l4b_0p752: ldo4 { > + regulator-min-microvolt = <752000>; > + regulator-max-microvolt = <820000>; > + regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>; > + }; > + > + reg_l5b_0p752: ldo5 { > + regulator-min-microvolt = <552000>; > + regulator-max-microvolt = <832000>; > + regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>; > + }; > + > + vreg_l6b_1p2: ldo6 { > + regulator-min-microvolt = <1140000>; > + regulator-max-microvolt = <1260000>; > + regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>; > + }; > + > + vreg_l7b_2p952: ldo7 { > + regulator-min-microvolt = <2400000>; > + regulator-max-microvolt = <3544000>; > + regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>; > + }; > + > + vreg_l8b_0p904: ldo8 { > + regulator-min-microvolt = <870000>; > + regulator-max-microvolt = <970000>; > + regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>; > + }; > + > + vreg_l9b_1p2: ldo9 { > + regulator-min-microvolt = <1200000>; > + regulator-max-microvolt = <1304000>; > + regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>; > + }; > + > + vreg_l11b_1p504: ldo11 { > + regulator-min-microvolt = <1504000>; > + regulator-max-microvolt = <2000000>; > + regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>; > + }; > + > + vreg_l12b_0p751: ldo12 { > + regulator-min-microvolt = <751000>; > + regulator-max-microvolt = <824000>; > + regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>; > + }; > + > + vreg_l13b_0p53: ldo13 { > + regulator-min-microvolt = <530000>; > + regulator-max-microvolt = <824000>; > + regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>; > + }; > + > + vreg_l14b_1p08: ldo14 { > + regulator-min-microvolt = <1080000>; > + regulator-max-microvolt = <1304000>; > + regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>; > + }; > + > + vreg_l15b_0p765: ldo15 { > + regulator-min-microvolt = <765000>; > + regulator-max-microvolt = <1020000>; > + regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>; > + }; > + > + vreg_l16b_1p1: ldo16 { > + regulator-min-microvolt = <1100000>; > + regulator-max-microvolt = <1300000>; > + regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>; > + }; > + > + vreg_l17b_1p7: ldo17 { > + regulator-min-microvolt = <1700000>; > + regulator-max-microvolt = <1900000>; > + regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>; > + }; > + > + vreg_l18b_1p8: ldo18 { > + regulator-min-microvolt = <1800000>; > + regulator-max-microvolt = <2000000>; > + regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>; > + }; > + > + vreg_l19b_1p8: ldo19 { > + regulator-min-microvolt = <1800000>; > + regulator-max-microvolt = <2000000>; > + regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>; > + }; > + }; > + > + regulators-1 { > + compatible = "qcom,pm8350c-rpmh-regulators"; > + qcom,pmic-id = "c"; > + > + vreg_s1c_2p19: smps1 { > + regulator-min-microvolt = <2190000>; > + regulator-max-microvolt = <2210000>; > + }; > + > + vreg_s2c_0p752: smps2 { > + regulator-min-microvolt = <750000>; > + regulator-max-microvolt = <800000>; > + }; > + > + vreg_s5c_0p752: smps5 { > + regulator-min-microvolt = <465000>; > + regulator-max-microvolt = <1050000>; > + }; > + > + vreg_s7c_0p752: smps7 { > + regulator-min-microvolt = <465000>; > + regulator-max-microvolt = <800000>; > + }; > + > + vreg_s9c_1p084: smps9 { > + regulator-min-microvolt = <1010000>; > + regulator-max-microvolt = <1170000>; > + }; > + > + vreg_l1c_1p8: ldo1 { > + regulator-min-microvolt = <1800000>; > + regulator-max-microvolt = <1980000>; > + regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>; > + }; > + > + vreg_l2c_1p62: ldo2 { > + regulator-min-microvolt = <1620000>; > + regulator-max-microvolt = <1980000>; > + regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>; > + }; > + > + vreg_l3c_2p8: ldo3 { > + regulator-min-microvolt = <2800000>; > + regulator-max-microvolt = <3540000>; > + regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>; > + }; > + > + vreg_l4c_1p62: ldo4 { > + regulator-min-microvolt = <1620000>; > + regulator-max-microvolt = <3300000>; > + regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>; > + }; > + > + vreg_l5c_1p62: ldo5 { > + regulator-min-microvolt = <1620000>; > + regulator-max-microvolt = <3300000>; > + regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>; > + }; > + > + vreg_l6c_2p96: ldo6 { > + regulator-min-microvolt = <1650000>; > + regulator-max-microvolt = <3544000>; > + regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>; > + }; > + > + vreg_l7c_3p0: ldo7 { > + regulator-min-microvolt = <3000000>; > + regulator-max-microvolt = <3544000>; > + regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>; > + }; > + > + vreg_l8c_1p62: ldo8 { > + regulator-min-microvolt = <1620000>; > + regulator-max-microvolt = <2000000>; > + regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>; > + }; > + > + vreg_l9c_2p96: ldo9 { > + regulator-min-microvolt = <2700000>; > + regulator-max-microvolt = <35440000>; > + regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>; > + }; > + > + vreg_l10c_0p88: ldo10 { > + regulator-min-microvolt = <720000>; > + regulator-max-microvolt = <1050000>; > + regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>; > + }; > + > + vreg_l11c_2p8: ldo11 { > + regulator-min-microvolt = <2800000>; > + regulator-max-microvolt = <3544000>; > + regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>; > + }; > + > + vreg_l12c_1p65: ldo12 { > + regulator-min-microvolt = <1650000>; > + regulator-max-microvolt = <2000000>; > + regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>; > + }; > + > + vreg_l13c_2p7: ldo13 { > + regulator-min-microvolt = <2700000>; > + regulator-max-microvolt = <3544000>; > + regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>; > + }; > + > + vreg_bob_3p296: bob { > + regulator-min-microvolt = <3008000>; > + regulator-max-microvolt = <3960000>; > + }; > + }; > +}; > + > +&qupv3_id_0 { > + status = "okay"; > +}; > + > +&uart5 { > + compatible = "qcom,geni-debug-uart"; Maybe we should add qcm6490.dtsi, which has this compat string (and other possible differences between sc7280 and qcm6490). > + status = "okay"; > +}; > + > +&usb_1 { > + status = "okay"; > +}; > + > +&usb_1_dwc3 { > + dr_mode = "peripheral"; > +}; > + > +&usb_1_hsphy { > + vdda-pll-supply = <&vreg_l10c_0p88>; > + vdda33-supply = <&vreg_l2b_3p072>; > + vdda18-supply = <&vreg_l1c_1p8>; > + > + status = "okay"; > +}; > + > +&usb_1_qmpphy { > + vdda-phy-supply = <&vreg_l6b_1p2>; > + vdda-pll-supply = <&vreg_l1b_0p912>; > + > + status = "okay"; > +}; > diff --git a/arch/arm64/boot/dts/qcom/qcm6490-rb3.dts b/arch/arm64/boot/dts/qcom/qcm6490-rb3.dts > new file mode 100644 > index 000000000000..5b4c2826ac5c > --- /dev/null > +++ b/arch/arm64/boot/dts/qcom/qcm6490-rb3.dts > @@ -0,0 +1,26 @@ > +// SPDX-License-Identifier: BSD-3-Clause > +/* > + * Copyright (c) 2023 Qualcomm Innovation Center, Inc. All rights reserved. > + */ > + > +/dts-v1/; > + > +/* PM7250B is configured to use SID8/9 */ > +#define PM7250B_SID 8 > +#define PM7250B_SID1 9 > + > +#include "qcm6490-iot-common.dtsi" > +#include "pm7250b.dtsi" > + > +/ { > + model = "Qualcomm Technologies, Inc. QCM6490 RB3"; Is this a marketing name of the platform? > + compatible = "qcom,qcm6490-rb3", "qcom,qcm6490"; chassis-type = ? > + > + aliases { > + serial0 = &uart5; > + }; > + > + chosen { > + stdout-path = "serial0:115200n8"; > + }; > +}; > -- > 2.42.0 > -- With best wishes Dmitry ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [RFC PATCH 2/2] arm64: dts: qcom: qcm6490: Add qcm6490 idp and rb3 board 2023-11-03 22:22 ` Dmitry Baryshkov @ 2023-11-05 13:08 ` Krzysztof Kozlowski 2023-11-06 11:41 ` Mukesh Ojha [not found] ` <4d8c094f-07b0-2b38-4680-145eb2d7c4f5@quicinc.com> 1 sibling, 1 reply; 20+ messages in thread From: Krzysztof Kozlowski @ 2023-11-05 13:08 UTC (permalink / raw) To: Dmitry Baryshkov, Komal Bajaj Cc: Andy Gross, Bjorn Andersson, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski, Conor Dooley, linux-arm-msm, devicetree, linux-kernel, quic_nainmeht On 03/11/2023 23:22, Dmitry Baryshkov wrote: > On Fri, 3 Nov 2023 at 20:49, Komal Bajaj <quic_kbajaj@quicinc.com> wrote: >> >> Add qcm6490 devicetree file for QCM6490 IDP and QCM6490 RB3 >> platform. QCM6490 is derived from SC7280 meant for various >> form factor including IoT. >> >> Supported features are, as of now: >> * Debug UART >> * eMMC (only in IDP) >> * USB >> ... >> + >> diff --git a/arch/arm64/boot/dts/qcom/qcm6490-iot-common.dtsi b/arch/arm64/boot/dts/qcom/qcm6490-iot-common.dtsi >> new file mode 100644 >> index 000000000000..01adc97789d0 >> --- /dev/null >> +++ b/arch/arm64/boot/dts/qcom/qcm6490-iot-common.dtsi > > I have mixed feelings towards this file. Usually we add such 'common' > files only for the phone platforms where most of the devices are > common. > Do you expect that IDP and RB3 will have a lot of common code other > than these regulator settings? I agree here. What exactly is common in the real hardware between IDP and RB3? Commit msg does not explain it, so I do not see enough justification for common file. Just because some DTS looks similar for different hardware does not mean you should creat common file. Best regards, Krzysztof ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [RFC PATCH 2/2] arm64: dts: qcom: qcm6490: Add qcm6490 idp and rb3 board 2023-11-05 13:08 ` Krzysztof Kozlowski @ 2023-11-06 11:41 ` Mukesh Ojha 2023-11-06 11:54 ` Dmitry Baryshkov 2023-11-06 13:05 ` Krzysztof Kozlowski 0 siblings, 2 replies; 20+ messages in thread From: Mukesh Ojha @ 2023-11-06 11:41 UTC (permalink / raw) To: Krzysztof Kozlowski, Dmitry Baryshkov, Komal Bajaj Cc: Andy Gross, Bjorn Andersson, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski, Conor Dooley, linux-arm-msm, devicetree, linux-kernel, quic_nainmeht On 11/5/2023 6:38 PM, Krzysztof Kozlowski wrote: > On 03/11/2023 23:22, Dmitry Baryshkov wrote: >> On Fri, 3 Nov 2023 at 20:49, Komal Bajaj <quic_kbajaj@quicinc.com> wrote: >>> >>> Add qcm6490 devicetree file for QCM6490 IDP and QCM6490 RB3 >>> platform. QCM6490 is derived from SC7280 meant for various >>> form factor including IoT. >>> >>> Supported features are, as of now: >>> * Debug UART >>> * eMMC (only in IDP) >>> * USB >>> > > ... > >>> + >>> diff --git a/arch/arm64/boot/dts/qcom/qcm6490-iot-common.dtsi b/arch/arm64/boot/dts/qcom/qcm6490-iot-common.dtsi >>> new file mode 100644 >>> index 000000000000..01adc97789d0 >>> --- /dev/null >>> +++ b/arch/arm64/boot/dts/qcom/qcm6490-iot-common.dtsi >> >> I have mixed feelings towards this file. Usually we add such 'common' >> files only for the phone platforms where most of the devices are >> common. >> Do you expect that IDP and RB3 will have a lot of common code other >> than these regulator settings? > > I agree here. What exactly is common in the real hardware between IDP > and RB3? Commit msg does not explain it, so I do not see enough > justification for common file. Just because some DTS looks similar for > different hardware does not mean you should creat common file. @Dmitry/@Krzysztof, Thank you for reviewing the RFC, we wanted to continue the suggestion/discussion given on [1] , where we discussed that this qcm6490 is going to be targeted for IOT segment and will have different memory map and it is going to use some of co-processors like adsp/cdsp which chrome does not use. So to your question what is common between RB3 and IDP, mostly they will share common memory map(similar to [2]) and regulator settings and both will use adsp/cdsp etc., we will be posting the memory map changes as well in coming weeks once this RFC is acked. Thanks, Mukesh [1] https://lore.kernel.org/linux-arm-msm/d97ebf74-ad03-86d6-b826-b57be209b9e2@quicinc.com/ [2] commit 90c856602e0346ce9ff234062e86a198d71fa723 Author: Douglas Anderson <dianders@chromium.org> Date: Tue Jan 25 14:44:20 2022 -0800 arm64: dts: qcom: sc7280: Factor out Chrome common fragment This factors out a device tree fragment from some sc7280 device trees. It represents the device tree bits that should be included for "Chrome" based sc7280 boards. On these boards the bootloader (Coreboot + Depthcharge) configures things slightly different than the bootloader that Qualcomm provides. The modem firmware on these boards also works differently than on other Qulacomm products and thus the reserved memory map needs to be adjusted. NOTES: - This is _not_ quite a no-op change. The "herobrine" and "idp" fragments here were different and it looks like someone simply forgot to update the herobrine version. This updates a few numbers to match IDP. This will also cause the `pmk8350_pon` to be disabled on idp/crd, which I belive is a correct change. - At the moment this assumes LTE skus. Once it's clearer how WiFi SKUs will work (how much of the memory map they can reclaim) we may add an extra fragment that will rejigger one way or the other. Signed-off-by: Douglas Anderson <dianders@chromium.org> Reviewed-by: Stephen Boyd <swboyd@chromium.org> Reviewed-by: Matthias Kaehlcke <mka@chromium.org> Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org> Link: https://lore.kernel.org/r/20220125144316.v2.3.Iac012fa8d727be46448d47027a1813ea716423ce@changeid > > Best regards, > Krzysztof > ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [RFC PATCH 2/2] arm64: dts: qcom: qcm6490: Add qcm6490 idp and rb3 board 2023-11-06 11:41 ` Mukesh Ojha @ 2023-11-06 11:54 ` Dmitry Baryshkov 2023-11-06 14:45 ` Mukesh Ojha 2023-11-06 13:05 ` Krzysztof Kozlowski 1 sibling, 1 reply; 20+ messages in thread From: Dmitry Baryshkov @ 2023-11-06 11:54 UTC (permalink / raw) To: Mukesh Ojha Cc: Krzysztof Kozlowski, Komal Bajaj, Andy Gross, Bjorn Andersson, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski, Conor Dooley, linux-arm-msm, devicetree, linux-kernel, quic_nainmeht On Mon, 6 Nov 2023 at 13:41, Mukesh Ojha <quic_mojha@quicinc.com> wrote: > > > On 11/5/2023 6:38 PM, Krzysztof Kozlowski wrote: > > On 03/11/2023 23:22, Dmitry Baryshkov wrote: > >> On Fri, 3 Nov 2023 at 20:49, Komal Bajaj <quic_kbajaj@quicinc.com> wrote: > >>> > >>> Add qcm6490 devicetree file for QCM6490 IDP and QCM6490 RB3 > >>> platform. QCM6490 is derived from SC7280 meant for various > >>> form factor including IoT. > >>> > >>> Supported features are, as of now: > >>> * Debug UART > >>> * eMMC (only in IDP) > >>> * USB > >>> > > > > ... > > > >>> + > >>> diff --git a/arch/arm64/boot/dts/qcom/qcm6490-iot-common.dtsi b/arch/arm64/boot/dts/qcom/qcm6490-iot-common.dtsi > >>> new file mode 100644 > >>> index 000000000000..01adc97789d0 > >>> --- /dev/null > >>> +++ b/arch/arm64/boot/dts/qcom/qcm6490-iot-common.dtsi > >> > >> I have mixed feelings towards this file. Usually we add such 'common' > >> files only for the phone platforms where most of the devices are > >> common. > >> Do you expect that IDP and RB3 will have a lot of common code other > >> than these regulator settings? > > > > I agree here. What exactly is common in the real hardware between IDP > > and RB3? Commit msg does not explain it, so I do not see enough > > justification for common file. Just because some DTS looks similar for > > different hardware does not mean you should creat common file. > > @Dmitry/@Krzysztof, > > Thank you for reviewing the RFC, we wanted to continue the > suggestion/discussion given on [1] , where we discussed that this > qcm6490 is going to be targeted for IOT segment and will have different > memory map and it is going to use some of co-processors like adsp/cdsp > which chrome does not use. > > So to your question what is common between RB3 and IDP, mostly they will > share common memory map(similar to [2]) and regulator settings and both > will use adsp/cdsp etc., we will be posting the memory map changes as > well in coming weeks once this RFC is acked. Is the memory map going to be the same as the one used on Fairphone5? Are ADSP and CDSP physically present on sc7280? I think that your goal should be to: - populate missing device in sc7280.dtsi - maybe add qcm6490.dtsi which defines SoC-level common data (e.g. memory map) - push the rest to board files. I don't think that putting regulators to the common file is a good idea. Platforms will further change and limit voltage limits and modes, so they usually go to the board file. > > > Thanks, > Mukesh > > [1] > https://lore.kernel.org/linux-arm-msm/d97ebf74-ad03-86d6-b826-b57be209b9e2@quicinc.com/ > > [2] > commit 90c856602e0346ce9ff234062e86a198d71fa723 > Author: Douglas Anderson <dianders@chromium.org> > Date: Tue Jan 25 14:44:20 2022 -0800 > > arm64: dts: qcom: sc7280: Factor out Chrome common fragment > > This factors out a device tree fragment from some sc7280 device > trees. It represents the device tree bits that should be included for > "Chrome" based sc7280 boards. On these boards the bootloader (Coreboot > + Depthcharge) configures things slightly different than the > bootloader that Qualcomm provides. The modem firmware on these boards > also works differently than on other Qulacomm products and thus the > reserved memory map needs to be adjusted. > > NOTES: > - This is _not_ quite a no-op change. The "herobrine" and "idp" > fragments here were different and it looks like someone simply > forgot to update the herobrine version. This updates a few numbers > to match IDP. This will also cause the `pmk8350_pon` to be disabled > on idp/crd, which I belive is a correct change. > - At the moment this assumes LTE skus. Once it's clearer how WiFi SKUs > will work (how much of the memory map they can reclaim) we may add > an extra fragment that will rejigger one way or the other. > > Signed-off-by: Douglas Anderson <dianders@chromium.org> > Reviewed-by: Stephen Boyd <swboyd@chromium.org> > Reviewed-by: Matthias Kaehlcke <mka@chromium.org> > Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org> > Link: > https://lore.kernel.org/r/20220125144316.v2.3.Iac012fa8d727be46448d47027a1813ea716423ce@changeid > > > > > > Best regards, > > Krzysztof > > -- With best wishes Dmitry ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [RFC PATCH 2/2] arm64: dts: qcom: qcm6490: Add qcm6490 idp and rb3 board 2023-11-06 11:54 ` Dmitry Baryshkov @ 2023-11-06 14:45 ` Mukesh Ojha 2023-11-06 22:32 ` Dmitry Baryshkov 0 siblings, 1 reply; 20+ messages in thread From: Mukesh Ojha @ 2023-11-06 14:45 UTC (permalink / raw) To: Dmitry Baryshkov Cc: Krzysztof Kozlowski, Komal Bajaj, Andy Gross, Bjorn Andersson, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski, Conor Dooley, linux-arm-msm, devicetree, linux-kernel, quic_nainmeht On 11/6/2023 5:24 PM, Dmitry Baryshkov wrote: > On Mon, 6 Nov 2023 at 13:41, Mukesh Ojha <quic_mojha@quicinc.com> wrote: >> >> >> On 11/5/2023 6:38 PM, Krzysztof Kozlowski wrote: >>> On 03/11/2023 23:22, Dmitry Baryshkov wrote: >>>> On Fri, 3 Nov 2023 at 20:49, Komal Bajaj <quic_kbajaj@quicinc.com> wrote: >>>>> >>>>> Add qcm6490 devicetree file for QCM6490 IDP and QCM6490 RB3 >>>>> platform. QCM6490 is derived from SC7280 meant for various >>>>> form factor including IoT. >>>>> >>>>> Supported features are, as of now: >>>>> * Debug UART >>>>> * eMMC (only in IDP) >>>>> * USB >>>>> >>> >>> ... >>> >>>>> + >>>>> diff --git a/arch/arm64/boot/dts/qcom/qcm6490-iot-common.dtsi b/arch/arm64/boot/dts/qcom/qcm6490-iot-common.dtsi >>>>> new file mode 100644 >>>>> index 000000000000..01adc97789d0 >>>>> --- /dev/null >>>>> +++ b/arch/arm64/boot/dts/qcom/qcm6490-iot-common.dtsi >>>> >>>> I have mixed feelings towards this file. Usually we add such 'common' >>>> files only for the phone platforms where most of the devices are >>>> common. >>>> Do you expect that IDP and RB3 will have a lot of common code other >>>> than these regulator settings? >>> >>> I agree here. What exactly is common in the real hardware between IDP >>> and RB3? Commit msg does not explain it, so I do not see enough >>> justification for common file. Just because some DTS looks similar for >>> different hardware does not mean you should creat common file. >> >> @Dmitry/@Krzysztof, >> >> Thank you for reviewing the RFC, we wanted to continue the >> suggestion/discussion given on [1] , where we discussed that this >> qcm6490 is going to be targeted for IOT segment and will have different >> memory map and it is going to use some of co-processors like adsp/cdsp >> which chrome does not use. >> >> So to your question what is common between RB3 and IDP, mostly they will >> share common memory map(similar to [2]) and regulator settings and both >> will use adsp/cdsp etc., we will be posting the memory map changes as >> well in coming weeks once this RFC is acked. > > Is the memory map going to be the same as the one used on Fairphone5? No, Fairphone5 looks to be using chrome memory map and i suggested here to move them into sc7280.dtsi https://lore.kernel.org/lkml/d5d53346-ca3b-986a-e104-d87c37115b62@quicinc.com/ > > Are ADSP and CDSP physically present on sc7280? Yes, they are present but not used. > > I think that your goal should be to: > - populate missing device in sc7280.dtsi > - maybe add qcm6490.dtsi which defines SoC-level common data (e.g. memory map) > - push the rest to board files. Agree to all of the point. We started with the same thought at[3] but it got lost in discussion due to its differentiation with mobile counter part(fairphone) which follow chrome memory map and hence we came up with qcm6490-iot-common. Do you think, qcm6490-iot.dtsi should be good ? [3] https://lore.kernel.org/linux-arm-msm/20231003175456.14774-3-quic_kbajaj@quicinc.com/ -Mukesh > > I don't think that putting regulators to the common file is a good > idea. Platforms will further change and limit voltage limits and > modes, so they usually go to the board file. > >> >> >> Thanks, >> Mukesh >> >> [1] >> https://lore.kernel.org/linux-arm-msm/d97ebf74-ad03-86d6-b826-b57be209b9e2@quicinc.com/ >> >> [2] >> commit 90c856602e0346ce9ff234062e86a198d71fa723 >> Author: Douglas Anderson <dianders@chromium.org> >> Date: Tue Jan 25 14:44:20 2022 -0800 >> >> arm64: dts: qcom: sc7280: Factor out Chrome common fragment >> >> This factors out a device tree fragment from some sc7280 device >> trees. It represents the device tree bits that should be included for >> "Chrome" based sc7280 boards. On these boards the bootloader (Coreboot >> + Depthcharge) configures things slightly different than the >> bootloader that Qualcomm provides. The modem firmware on these boards >> also works differently than on other Qulacomm products and thus the >> reserved memory map needs to be adjusted. >> >> NOTES: >> - This is _not_ quite a no-op change. The "herobrine" and "idp" >> fragments here were different and it looks like someone simply >> forgot to update the herobrine version. This updates a few numbers >> to match IDP. This will also cause the `pmk8350_pon` to be disabled >> on idp/crd, which I belive is a correct change. >> - At the moment this assumes LTE skus. Once it's clearer how WiFi SKUs >> will work (how much of the memory map they can reclaim) we may add >> an extra fragment that will rejigger one way or the other. >> >> Signed-off-by: Douglas Anderson <dianders@chromium.org> >> Reviewed-by: Stephen Boyd <swboyd@chromium.org> >> Reviewed-by: Matthias Kaehlcke <mka@chromium.org> >> Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org> >> Link: >> https://lore.kernel.org/r/20220125144316.v2.3.Iac012fa8d727be46448d47027a1813ea716423ce@changeid >> >> >>> >>> Best regards, >>> Krzysztof >>> > > > ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [RFC PATCH 2/2] arm64: dts: qcom: qcm6490: Add qcm6490 idp and rb3 board 2023-11-06 14:45 ` Mukesh Ojha @ 2023-11-06 22:32 ` Dmitry Baryshkov 2023-11-07 8:10 ` Mukesh Ojha 0 siblings, 1 reply; 20+ messages in thread From: Dmitry Baryshkov @ 2023-11-06 22:32 UTC (permalink / raw) To: Mukesh Ojha Cc: Krzysztof Kozlowski, Komal Bajaj, Andy Gross, Bjorn Andersson, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski, Conor Dooley, linux-arm-msm, devicetree, linux-kernel, quic_nainmeht On Mon, 6 Nov 2023 at 16:46, Mukesh Ojha <quic_mojha@quicinc.com> wrote: > > > > On 11/6/2023 5:24 PM, Dmitry Baryshkov wrote: > > On Mon, 6 Nov 2023 at 13:41, Mukesh Ojha <quic_mojha@quicinc.com> wrote: > >> > >> > >> On 11/5/2023 6:38 PM, Krzysztof Kozlowski wrote: > >>> On 03/11/2023 23:22, Dmitry Baryshkov wrote: > >>>> On Fri, 3 Nov 2023 at 20:49, Komal Bajaj <quic_kbajaj@quicinc.com> wrote: > >>>>> > >>>>> Add qcm6490 devicetree file for QCM6490 IDP and QCM6490 RB3 > >>>>> platform. QCM6490 is derived from SC7280 meant for various > >>>>> form factor including IoT. > >>>>> > >>>>> Supported features are, as of now: > >>>>> * Debug UART > >>>>> * eMMC (only in IDP) > >>>>> * USB > >>>>> > >>> > >>> ... > >>> > >>>>> + > >>>>> diff --git a/arch/arm64/boot/dts/qcom/qcm6490-iot-common.dtsi b/arch/arm64/boot/dts/qcom/qcm6490-iot-common.dtsi > >>>>> new file mode 100644 > >>>>> index 000000000000..01adc97789d0 > >>>>> --- /dev/null > >>>>> +++ b/arch/arm64/boot/dts/qcom/qcm6490-iot-common.dtsi > >>>> > >>>> I have mixed feelings towards this file. Usually we add such 'common' > >>>> files only for the phone platforms where most of the devices are > >>>> common. > >>>> Do you expect that IDP and RB3 will have a lot of common code other > >>>> than these regulator settings? > >>> > >>> I agree here. What exactly is common in the real hardware between IDP > >>> and RB3? Commit msg does not explain it, so I do not see enough > >>> justification for common file. Just because some DTS looks similar for > >>> different hardware does not mean you should creat common file. > >> > >> @Dmitry/@Krzysztof, > >> > >> Thank you for reviewing the RFC, we wanted to continue the > >> suggestion/discussion given on [1] , where we discussed that this > >> qcm6490 is going to be targeted for IOT segment and will have different > >> memory map and it is going to use some of co-processors like adsp/cdsp > >> which chrome does not use. > >> > >> So to your question what is common between RB3 and IDP, mostly they will > >> share common memory map(similar to [2]) and regulator settings and both > >> will use adsp/cdsp etc., we will be posting the memory map changes as > >> well in coming weeks once this RFC is acked. > > > > Is the memory map going to be the same as the one used on Fairphone5? > > No, Fairphone5 looks to be using chrome memory map and i suggested > here to move them into sc7280.dtsi > > https://lore.kernel.org/lkml/d5d53346-ca3b-986a-e104-d87c37115b62@quicinc.com/ > > > > > Are ADSP and CDSP physically present on sc7280? > > Yes, they are present but not used. So ADSP and CDSP should go into sc7280.dtsi. They will anyway have status = "disabled"; > > > > > I think that your goal should be to: > > - populate missing device in sc7280.dtsi > > - maybe add qcm6490.dtsi which defines SoC-level common data (e.g. memory map) > > - push the rest to board files. > > Agree to all of the point. > We started with the same thought at[3] but it got lost in discussion > due to its differentiation with mobile counter part(fairphone) which > follow chrome memory map and hence we came up with qcm6490-iot-common. > Do you think, qcm6490-iot.dtsi should be good ? No. DT describes hardware, and -iot is not a hardware abstraction / unification. If you consider your memory map to be generic for the qcm6490 (and FP5 being the only exception), add it to the qcm6490.dtsi (and let FP5 override it, like some of the phones do). If it can not be considered generic for the SoC, then you have no other choice than to replicate it to all board files. > > [3] > https://lore.kernel.org/linux-arm-msm/20231003175456.14774-3-quic_kbajaj@quicinc.com/ > > -Mukesh > > > > I don't think that putting regulators to the common file is a good > > idea. Platforms will further change and limit voltage limits and > > modes, so they usually go to the board file. > > > >> > >> > >> Thanks, > >> Mukesh > >> > >> [1] > >> https://lore.kernel.org/linux-arm-msm/d97ebf74-ad03-86d6-b826-b57be209b9e2@quicinc.com/ > >> > >> [2] > >> commit 90c856602e0346ce9ff234062e86a198d71fa723 > >> Author: Douglas Anderson <dianders@chromium.org> > >> Date: Tue Jan 25 14:44:20 2022 -0800 > >> > >> arm64: dts: qcom: sc7280: Factor out Chrome common fragment > >> > >> This factors out a device tree fragment from some sc7280 device > >> trees. It represents the device tree bits that should be included for > >> "Chrome" based sc7280 boards. On these boards the bootloader (Coreboot > >> + Depthcharge) configures things slightly different than the > >> bootloader that Qualcomm provides. The modem firmware on these boards > >> also works differently than on other Qulacomm products and thus the > >> reserved memory map needs to be adjusted. > >> > >> NOTES: > >> - This is _not_ quite a no-op change. The "herobrine" and "idp" > >> fragments here were different and it looks like someone simply > >> forgot to update the herobrine version. This updates a few numbers > >> to match IDP. This will also cause the `pmk8350_pon` to be disabled > >> on idp/crd, which I belive is a correct change. > >> - At the moment this assumes LTE skus. Once it's clearer how WiFi SKUs > >> will work (how much of the memory map they can reclaim) we may add > >> an extra fragment that will rejigger one way or the other. > >> > >> Signed-off-by: Douglas Anderson <dianders@chromium.org> > >> Reviewed-by: Stephen Boyd <swboyd@chromium.org> > >> Reviewed-by: Matthias Kaehlcke <mka@chromium.org> > >> Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org> > >> Link: > >> https://lore.kernel.org/r/20220125144316.v2.3.Iac012fa8d727be46448d47027a1813ea716423ce@changeid > >> > >> > >>> > >>> Best regards, > >>> Krzysztof > >>> > > > > > > -- With best wishes Dmitry ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [RFC PATCH 2/2] arm64: dts: qcom: qcm6490: Add qcm6490 idp and rb3 board 2023-11-06 22:32 ` Dmitry Baryshkov @ 2023-11-07 8:10 ` Mukesh Ojha 2023-11-13 15:51 ` Luca Weiss 0 siblings, 1 reply; 20+ messages in thread From: Mukesh Ojha @ 2023-11-07 8:10 UTC (permalink / raw) To: Dmitry Baryshkov, Luca Weiss Cc: Krzysztof Kozlowski, Komal Bajaj, Andy Gross, Bjorn Andersson, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski, Conor Dooley, linux-arm-msm, devicetree, linux-kernel, quic_nainmeht On 11/7/2023 4:02 AM, Dmitry Baryshkov wrote: > On Mon, 6 Nov 2023 at 16:46, Mukesh Ojha <quic_mojha@quicinc.com> wrote: >> >> >> >> On 11/6/2023 5:24 PM, Dmitry Baryshkov wrote: >>> On Mon, 6 Nov 2023 at 13:41, Mukesh Ojha <quic_mojha@quicinc.com> wrote: >>>> >>>> >>>> On 11/5/2023 6:38 PM, Krzysztof Kozlowski wrote: >>>>> On 03/11/2023 23:22, Dmitry Baryshkov wrote: >>>>>> On Fri, 3 Nov 2023 at 20:49, Komal Bajaj <quic_kbajaj@quicinc.com> wrote: >>>>>>> >>>>>>> Add qcm6490 devicetree file for QCM6490 IDP and QCM6490 RB3 >>>>>>> platform. QCM6490 is derived from SC7280 meant for various >>>>>>> form factor including IoT. >>>>>>> >>>>>>> Supported features are, as of now: >>>>>>> * Debug UART >>>>>>> * eMMC (only in IDP) >>>>>>> * USB >>>>>>> >>>>> >>>>> ... >>>>> >>>>>>> + >>>>>>> diff --git a/arch/arm64/boot/dts/qcom/qcm6490-iot-common.dtsi b/arch/arm64/boot/dts/qcom/qcm6490-iot-common.dtsi >>>>>>> new file mode 100644 >>>>>>> index 000000000000..01adc97789d0 >>>>>>> --- /dev/null >>>>>>> +++ b/arch/arm64/boot/dts/qcom/qcm6490-iot-common.dtsi >>>>>> >>>>>> I have mixed feelings towards this file. Usually we add such 'common' >>>>>> files only for the phone platforms where most of the devices are >>>>>> common. >>>>>> Do you expect that IDP and RB3 will have a lot of common code other >>>>>> than these regulator settings? >>>>> >>>>> I agree here. What exactly is common in the real hardware between IDP >>>>> and RB3? Commit msg does not explain it, so I do not see enough >>>>> justification for common file. Just because some DTS looks similar for >>>>> different hardware does not mean you should creat common file. >>>> >>>> @Dmitry/@Krzysztof, >>>> >>>> Thank you for reviewing the RFC, we wanted to continue the >>>> suggestion/discussion given on [1] , where we discussed that this >>>> qcm6490 is going to be targeted for IOT segment and will have different >>>> memory map and it is going to use some of co-processors like adsp/cdsp >>>> which chrome does not use. >>>> >>>> So to your question what is common between RB3 and IDP, mostly they will >>>> share common memory map(similar to [2]) and regulator settings and both >>>> will use adsp/cdsp etc., we will be posting the memory map changes as >>>> well in coming weeks once this RFC is acked. >>> >>> Is the memory map going to be the same as the one used on Fairphone5? >> >> No, Fairphone5 looks to be using chrome memory map and i suggested >> here to move them into sc7280.dtsi >> >> https://lore.kernel.org/lkml/d5d53346-ca3b-986a-e104-d87c37115b62@quicinc.com/ >> >>> >>> Are ADSP and CDSP physically present on sc7280? >> >> Yes, they are present but not used. > > So ADSP and CDSP should go into sc7280.dtsi. They will anyway have > status = "disabled"; > >> >>> >>> I think that your goal should be to: >>> - populate missing device in sc7280.dtsi >>> - maybe add qcm6490.dtsi which defines SoC-level common data (e.g. memory map) >>> - push the rest to board files. >> >> Agree to all of the point. >> We started with the same thought at[3] but it got lost in discussion >> due to its differentiation with mobile counter part(fairphone) which >> follow chrome memory map and hence we came up with qcm6490-iot-common. >> Do you think, qcm6490-iot.dtsi should be good ? > > No. DT describes hardware, and -iot is not a hardware abstraction / unification. > If you consider your memory map to be generic for the qcm6490 (and FP5 > being the only exception), add it to the qcm6490.dtsi (and let FP5 > override it, like some of the phones do). If it can not be considered > generic for the SoC, then you have no other choice than to replicate > it to all board files. Thanks for the suggestion. Let me add @Luca here for information, if he want to share anything about qcm6490 fp5 memory map. -Mukesh > >> >> [3] >> https://lore.kernel.org/linux-arm-msm/20231003175456.14774-3-quic_kbajaj@quicinc.com/ >> >> -Mukesh >>> >>> I don't think that putting regulators to the common file is a good >>> idea. Platforms will further change and limit voltage limits and >>> modes, so they usually go to the board file. >>> >>>> >>>> >>>> Thanks, >>>> Mukesh >>>> >>>> [1] >>>> https://lore.kernel.org/linux-arm-msm/d97ebf74-ad03-86d6-b826-b57be209b9e2@quicinc.com/ >>>> >>>> [2] >>>> commit 90c856602e0346ce9ff234062e86a198d71fa723 >>>> Author: Douglas Anderson <dianders@chromium.org> >>>> Date: Tue Jan 25 14:44:20 2022 -0800 >>>> >>>> arm64: dts: qcom: sc7280: Factor out Chrome common fragment >>>> >>>> This factors out a device tree fragment from some sc7280 device >>>> trees. It represents the device tree bits that should be included for >>>> "Chrome" based sc7280 boards. On these boards the bootloader (Coreboot >>>> + Depthcharge) configures things slightly different than the >>>> bootloader that Qualcomm provides. The modem firmware on these boards >>>> also works differently than on other Qulacomm products and thus the >>>> reserved memory map needs to be adjusted. >>>> >>>> NOTES: >>>> - This is _not_ quite a no-op change. The "herobrine" and "idp" >>>> fragments here were different and it looks like someone simply >>>> forgot to update the herobrine version. This updates a few numbers >>>> to match IDP. This will also cause the `pmk8350_pon` to be disabled >>>> on idp/crd, which I belive is a correct change. >>>> - At the moment this assumes LTE skus. Once it's clearer how WiFi SKUs >>>> will work (how much of the memory map they can reclaim) we may add >>>> an extra fragment that will rejigger one way or the other. >>>> >>>> Signed-off-by: Douglas Anderson <dianders@chromium.org> >>>> Reviewed-by: Stephen Boyd <swboyd@chromium.org> >>>> Reviewed-by: Matthias Kaehlcke <mka@chromium.org> >>>> Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org> >>>> Link: >>>> https://lore.kernel.org/r/20220125144316.v2.3.Iac012fa8d727be46448d47027a1813ea716423ce@changeid >>>> >>>> >>>>> >>>>> Best regards, >>>>> Krzysztof >>>>> >>> >>> >>> > > > ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [RFC PATCH 2/2] arm64: dts: qcom: qcm6490: Add qcm6490 idp and rb3 board 2023-11-07 8:10 ` Mukesh Ojha @ 2023-11-13 15:51 ` Luca Weiss 2023-11-14 12:48 ` Mukesh Ojha 0 siblings, 1 reply; 20+ messages in thread From: Luca Weiss @ 2023-11-13 15:51 UTC (permalink / raw) To: Mukesh Ojha, Dmitry Baryshkov Cc: Krzysztof Kozlowski, Komal Bajaj, Andy Gross, Bjorn Andersson, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski, Conor Dooley, linux-arm-msm, devicetree, linux-kernel, quic_nainmeht On Tue Nov 7, 2023 at 9:10 AM CET, Mukesh Ojha wrote: > > > On 11/7/2023 4:02 AM, Dmitry Baryshkov wrote: > > On Mon, 6 Nov 2023 at 16:46, Mukesh Ojha <quic_mojha@quicinc.com> wrote: > >> > >> > >> > >> On 11/6/2023 5:24 PM, Dmitry Baryshkov wrote: > >>> On Mon, 6 Nov 2023 at 13:41, Mukesh Ojha <quic_mojha@quicinc.com> wrote: > >>>> > >>>> > >>>> On 11/5/2023 6:38 PM, Krzysztof Kozlowski wrote: > >>>>> On 03/11/2023 23:22, Dmitry Baryshkov wrote: > >>>>>> On Fri, 3 Nov 2023 at 20:49, Komal Bajaj <quic_kbajaj@quicinc.com> wrote: > >>>>>>> > >>>>>>> Add qcm6490 devicetree file for QCM6490 IDP and QCM6490 RB3 > >>>>>>> platform. QCM6490 is derived from SC7280 meant for various > >>>>>>> form factor including IoT. > >>>>>>> > >>>>>>> Supported features are, as of now: > >>>>>>> * Debug UART > >>>>>>> * eMMC (only in IDP) > >>>>>>> * USB > >>>>>>> > >>>>> > >>>>> ... > >>>>> > >>>>>>> + > >>>>>>> diff --git a/arch/arm64/boot/dts/qcom/qcm6490-iot-common.dtsi b/arch/arm64/boot/dts/qcom/qcm6490-iot-common.dtsi > >>>>>>> new file mode 100644 > >>>>>>> index 000000000000..01adc97789d0 > >>>>>>> --- /dev/null > >>>>>>> +++ b/arch/arm64/boot/dts/qcom/qcm6490-iot-common.dtsi > >>>>>> > >>>>>> I have mixed feelings towards this file. Usually we add such 'common' > >>>>>> files only for the phone platforms where most of the devices are > >>>>>> common. > >>>>>> Do you expect that IDP and RB3 will have a lot of common code other > >>>>>> than these regulator settings? > >>>>> > >>>>> I agree here. What exactly is common in the real hardware between IDP > >>>>> and RB3? Commit msg does not explain it, so I do not see enough > >>>>> justification for common file. Just because some DTS looks similar for > >>>>> different hardware does not mean you should creat common file. > >>>> > >>>> @Dmitry/@Krzysztof, > >>>> > >>>> Thank you for reviewing the RFC, we wanted to continue the > >>>> suggestion/discussion given on [1] , where we discussed that this > >>>> qcm6490 is going to be targeted for IOT segment and will have different > >>>> memory map and it is going to use some of co-processors like adsp/cdsp > >>>> which chrome does not use. > >>>> > >>>> So to your question what is common between RB3 and IDP, mostly they will > >>>> share common memory map(similar to [2]) and regulator settings and both > >>>> will use adsp/cdsp etc., we will be posting the memory map changes as > >>>> well in coming weeks once this RFC is acked. > >>> > >>> Is the memory map going to be the same as the one used on Fairphone5? > >> > >> No, Fairphone5 looks to be using chrome memory map and i suggested > >> here to move them into sc7280.dtsi > >> > >> https://lore.kernel.org/lkml/d5d53346-ca3b-986a-e104-d87c37115b62@quicinc.com/ > >> > >>> > >>> Are ADSP and CDSP physically present on sc7280? > >> > >> Yes, they are present but not used. > > > > So ADSP and CDSP should go into sc7280.dtsi. They will anyway have > > status = "disabled"; > > > >> > >>> > >>> I think that your goal should be to: > >>> - populate missing device in sc7280.dtsi > >>> - maybe add qcm6490.dtsi which defines SoC-level common data (e.g. memory map) > >>> - push the rest to board files. > >> > >> Agree to all of the point. > >> We started with the same thought at[3] but it got lost in discussion > >> due to its differentiation with mobile counter part(fairphone) which > >> follow chrome memory map and hence we came up with qcm6490-iot-common. > >> Do you think, qcm6490-iot.dtsi should be good ? > > > > No. DT describes hardware, and -iot is not a hardware abstraction / unification. > > If you consider your memory map to be generic for the qcm6490 (and FP5 > > being the only exception), add it to the qcm6490.dtsi (and let FP5 > > override it, like some of the phones do). If it can not be considered > > generic for the SoC, then you have no other choice than to replicate > > it to all board files. > Hi Mukesh, > Thanks for the suggestion. > Let me add @Luca here for information, if he want to share > anything about qcm6490 fp5 memory map. Not sure I have much to share, just probably that on FP5 the memory setup and all the basics just come from a standard QCM6490.LA.3.0 release. I don't see any hint that our ODM changed something in the memory map for the device either. I'm also aware that other phones also use QCM6490 SoC, so I'm still wondering where the distinction between "FP5/ChromeOS memory map" vs this new QCM6490 memory map is. There's also e.g. this phone using QCM6490, I've not looked into this at all, but I'm guessing that phone uses the same memory map as FP5. https://www.crosscall.com/en_NL/core-z5-COZ5.MASTER.html Regards Luca > > -Mukesh > > > >> > >> [3] > >> https://lore.kernel.org/linux-arm-msm/20231003175456.14774-3-quic_kbajaj@quicinc.com/ > >> > >> -Mukesh > >>> > >>> I don't think that putting regulators to the common file is a good > >>> idea. Platforms will further change and limit voltage limits and > >>> modes, so they usually go to the board file. > >>> > >>>> > >>>> > >>>> Thanks, > >>>> Mukesh > >>>> > >>>> [1] > >>>> https://lore.kernel.org/linux-arm-msm/d97ebf74-ad03-86d6-b826-b57be209b9e2@quicinc.com/ > >>>> > >>>> [2] > >>>> commit 90c856602e0346ce9ff234062e86a198d71fa723 > >>>> Author: Douglas Anderson <dianders@chromium.org> > >>>> Date: Tue Jan 25 14:44:20 2022 -0800 > >>>> > >>>> arm64: dts: qcom: sc7280: Factor out Chrome common fragment > >>>> > >>>> This factors out a device tree fragment from some sc7280 device > >>>> trees. It represents the device tree bits that should be included for > >>>> "Chrome" based sc7280 boards. On these boards the bootloader (Coreboot > >>>> + Depthcharge) configures things slightly different than the > >>>> bootloader that Qualcomm provides. The modem firmware on these boards > >>>> also works differently than on other Qulacomm products and thus the > >>>> reserved memory map needs to be adjusted. > >>>> > >>>> NOTES: > >>>> - This is _not_ quite a no-op change. The "herobrine" and "idp" > >>>> fragments here were different and it looks like someone simply > >>>> forgot to update the herobrine version. This updates a few numbers > >>>> to match IDP. This will also cause the `pmk8350_pon` to be disabled > >>>> on idp/crd, which I belive is a correct change. > >>>> - At the moment this assumes LTE skus. Once it's clearer how WiFi SKUs > >>>> will work (how much of the memory map they can reclaim) we may add > >>>> an extra fragment that will rejigger one way or the other. > >>>> > >>>> Signed-off-by: Douglas Anderson <dianders@chromium.org> > >>>> Reviewed-by: Stephen Boyd <swboyd@chromium.org> > >>>> Reviewed-by: Matthias Kaehlcke <mka@chromium.org> > >>>> Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org> > >>>> Link: > >>>> https://lore.kernel.org/r/20220125144316.v2.3.Iac012fa8d727be46448d47027a1813ea716423ce@changeid > >>>> > >>>> > >>>>> > >>>>> Best regards, > >>>>> Krzysztof > >>>>> > >>> > >>> > >>> > > > > > > ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [RFC PATCH 2/2] arm64: dts: qcom: qcm6490: Add qcm6490 idp and rb3 board 2023-11-13 15:51 ` Luca Weiss @ 2023-11-14 12:48 ` Mukesh Ojha 2023-11-14 12:53 ` Dmitry Baryshkov 0 siblings, 1 reply; 20+ messages in thread From: Mukesh Ojha @ 2023-11-14 12:48 UTC (permalink / raw) To: Luca Weiss, Dmitry Baryshkov Cc: Krzysztof Kozlowski, Komal Bajaj, Andy Gross, Bjorn Andersson, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski, Conor Dooley, linux-arm-msm, devicetree, linux-kernel, quic_nainmeht On 11/13/2023 9:21 PM, Luca Weiss wrote: > On Tue Nov 7, 2023 at 9:10 AM CET, Mukesh Ojha wrote: >> >> >> On 11/7/2023 4:02 AM, Dmitry Baryshkov wrote: >>> On Mon, 6 Nov 2023 at 16:46, Mukesh Ojha <quic_mojha@quicinc.com> wrote: >>>> >>>> >>>> >>>> On 11/6/2023 5:24 PM, Dmitry Baryshkov wrote: >>>>> On Mon, 6 Nov 2023 at 13:41, Mukesh Ojha <quic_mojha@quicinc.com> wrote: >>>>>> >>>>>> >>>>>> On 11/5/2023 6:38 PM, Krzysztof Kozlowski wrote: >>>>>>> On 03/11/2023 23:22, Dmitry Baryshkov wrote: >>>>>>>> On Fri, 3 Nov 2023 at 20:49, Komal Bajaj <quic_kbajaj@quicinc.com> wrote: >>>>>>>>> >>>>>>>>> Add qcm6490 devicetree file for QCM6490 IDP and QCM6490 RB3 >>>>>>>>> platform. QCM6490 is derived from SC7280 meant for various >>>>>>>>> form factor including IoT. >>>>>>>>> >>>>>>>>> Supported features are, as of now: >>>>>>>>> * Debug UART >>>>>>>>> * eMMC (only in IDP) >>>>>>>>> * USB >>>>>>>>> >>>>>>> >>>>>>> ... >>>>>>> >>>>>>>>> + >>>>>>>>> diff --git a/arch/arm64/boot/dts/qcom/qcm6490-iot-common.dtsi b/arch/arm64/boot/dts/qcom/qcm6490-iot-common.dtsi >>>>>>>>> new file mode 100644 >>>>>>>>> index 000000000000..01adc97789d0 >>>>>>>>> --- /dev/null >>>>>>>>> +++ b/arch/arm64/boot/dts/qcom/qcm6490-iot-common.dtsi >>>>>>>> >>>>>>>> I have mixed feelings towards this file. Usually we add such 'common' >>>>>>>> files only for the phone platforms where most of the devices are >>>>>>>> common. >>>>>>>> Do you expect that IDP and RB3 will have a lot of common code other >>>>>>>> than these regulator settings? >>>>>>> >>>>>>> I agree here. What exactly is common in the real hardware between IDP >>>>>>> and RB3? Commit msg does not explain it, so I do not see enough >>>>>>> justification for common file. Just because some DTS looks similar for >>>>>>> different hardware does not mean you should creat common file. >>>>>> >>>>>> @Dmitry/@Krzysztof, >>>>>> >>>>>> Thank you for reviewing the RFC, we wanted to continue the >>>>>> suggestion/discussion given on [1] , where we discussed that this >>>>>> qcm6490 is going to be targeted for IOT segment and will have different >>>>>> memory map and it is going to use some of co-processors like adsp/cdsp >>>>>> which chrome does not use. >>>>>> >>>>>> So to your question what is common between RB3 and IDP, mostly they will >>>>>> share common memory map(similar to [2]) and regulator settings and both >>>>>> will use adsp/cdsp etc., we will be posting the memory map changes as >>>>>> well in coming weeks once this RFC is acked. >>>>> >>>>> Is the memory map going to be the same as the one used on Fairphone5? >>>> >>>> No, Fairphone5 looks to be using chrome memory map and i suggested >>>> here to move them into sc7280.dtsi >>>> >>>> https://lore.kernel.org/lkml/d5d53346-ca3b-986a-e104-d87c37115b62@quicinc.com/ >>>> >>>>> >>>>> Are ADSP and CDSP physically present on sc7280? >>>> >>>> Yes, they are present but not used. >>> >>> So ADSP and CDSP should go into sc7280.dtsi. They will anyway have >>> status = "disabled"; >>> >>>> >>>>> >>>>> I think that your goal should be to: >>>>> - populate missing device in sc7280.dtsi >>>>> - maybe add qcm6490.dtsi which defines SoC-level common data (e.g. memory map) >>>>> - push the rest to board files. >>>> >>>> Agree to all of the point. >>>> We started with the same thought at[3] but it got lost in discussion >>>> due to its differentiation with mobile counter part(fairphone) which >>>> follow chrome memory map and hence we came up with qcm6490-iot-common. >>>> Do you think, qcm6490-iot.dtsi should be good ? >>> >>> No. DT describes hardware, and -iot is not a hardware abstraction / unification. >>> If you consider your memory map to be generic for the qcm6490 (and FP5 >>> being the only exception), add it to the qcm6490.dtsi (and let FP5 >>> override it, like some of the phones do). If it can not be considered >>> generic for the SoC, then you have no other choice than to replicate >>> it to all board files. >> > > Hi Mukesh, > >> Thanks for the suggestion. >> Let me add @Luca here for information, if he want to share >> anything about qcm6490 fp5 memory map. > > Not sure I have much to share, just probably that on FP5 the memory > setup and all the basics just come from a standard QCM6490.LA.3.0 > release. > I don't see any hint that our ODM changed something in the memory map > for the device either. > > I'm also aware that other phones also use QCM6490 SoC, so I'm still > wondering where the distinction between "FP5/ChromeOS memory map" vs > this new QCM6490 memory map is. > There's also e.g. this phone using QCM6490, I've not looked into this at > all, but I'm guessing that phone uses the same memory map as FP5. > https://www.crosscall.com/en_NL/core-z5-COZ5.MASTER.html Was looking for your view on the things about qcm6490.dtsi one common dtsi file for all qcm6490.dtsi suggested in the mail, but looks like FP5 is following the memory map based out of sc7280, in that case we have to replicate the new memory map for all our IOT boards(idp/rb3) based on this SoC. -Mukesh > > Regards > Luca > >> >> -Mukesh >>> >>>> >>>> [3] >>>> https://lore.kernel.org/linux-arm-msm/20231003175456.14774-3-quic_kbajaj@quicinc.com/ >>>> >>>> -Mukesh >>>>> >>>>> I don't think that putting regulators to the common file is a good >>>>> idea. Platforms will further change and limit voltage limits and >>>>> modes, so they usually go to the board file. >>>>> >>>>>> >>>>>> >>>>>> Thanks, >>>>>> Mukesh >>>>>> >>>>>> [1] >>>>>> https://lore.kernel.org/linux-arm-msm/d97ebf74-ad03-86d6-b826-b57be209b9e2@quicinc.com/ >>>>>> >>>>>> [2] >>>>>> commit 90c856602e0346ce9ff234062e86a198d71fa723 >>>>>> Author: Douglas Anderson <dianders@chromium.org> >>>>>> Date: Tue Jan 25 14:44:20 2022 -0800 >>>>>> >>>>>> arm64: dts: qcom: sc7280: Factor out Chrome common fragment >>>>>> >>>>>> This factors out a device tree fragment from some sc7280 device >>>>>> trees. It represents the device tree bits that should be included for >>>>>> "Chrome" based sc7280 boards. On these boards the bootloader (Coreboot >>>>>> + Depthcharge) configures things slightly different than the >>>>>> bootloader that Qualcomm provides. The modem firmware on these boards >>>>>> also works differently than on other Qulacomm products and thus the >>>>>> reserved memory map needs to be adjusted. >>>>>> >>>>>> NOTES: >>>>>> - This is _not_ quite a no-op change. The "herobrine" and "idp" >>>>>> fragments here were different and it looks like someone simply >>>>>> forgot to update the herobrine version. This updates a few numbers >>>>>> to match IDP. This will also cause the `pmk8350_pon` to be disabled >>>>>> on idp/crd, which I belive is a correct change. >>>>>> - At the moment this assumes LTE skus. Once it's clearer how WiFi SKUs >>>>>> will work (how much of the memory map they can reclaim) we may add >>>>>> an extra fragment that will rejigger one way or the other. >>>>>> >>>>>> Signed-off-by: Douglas Anderson <dianders@chromium.org> >>>>>> Reviewed-by: Stephen Boyd <swboyd@chromium.org> >>>>>> Reviewed-by: Matthias Kaehlcke <mka@chromium.org> >>>>>> Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org> >>>>>> Link: >>>>>> https://lore.kernel.org/r/20220125144316.v2.3.Iac012fa8d727be46448d47027a1813ea716423ce@changeid >>>>>> >>>>>> >>>>>>> >>>>>>> Best regards, >>>>>>> Krzysztof >>>>>>> >>>>> >>>>> >>>>> >>> >>> >>> > ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [RFC PATCH 2/2] arm64: dts: qcom: qcm6490: Add qcm6490 idp and rb3 board 2023-11-14 12:48 ` Mukesh Ojha @ 2023-11-14 12:53 ` Dmitry Baryshkov 0 siblings, 0 replies; 20+ messages in thread From: Dmitry Baryshkov @ 2023-11-14 12:53 UTC (permalink / raw) To: Mukesh Ojha Cc: Luca Weiss, Krzysztof Kozlowski, Komal Bajaj, Andy Gross, Bjorn Andersson, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski, Conor Dooley, linux-arm-msm, devicetree, linux-kernel, quic_nainmeht On Tue, 14 Nov 2023 at 14:49, Mukesh Ojha <quic_mojha@quicinc.com> wrote: > > > > On 11/13/2023 9:21 PM, Luca Weiss wrote: > > On Tue Nov 7, 2023 at 9:10 AM CET, Mukesh Ojha wrote: > >> > >> > >> On 11/7/2023 4:02 AM, Dmitry Baryshkov wrote: > >>> On Mon, 6 Nov 2023 at 16:46, Mukesh Ojha <quic_mojha@quicinc.com> wrote: > >>>> > >>>> > >>>> > >>>> On 11/6/2023 5:24 PM, Dmitry Baryshkov wrote: > >>>>> On Mon, 6 Nov 2023 at 13:41, Mukesh Ojha <quic_mojha@quicinc.com> wrote: > >>>>>> > >>>>>> > >>>>>> On 11/5/2023 6:38 PM, Krzysztof Kozlowski wrote: > >>>>>>> On 03/11/2023 23:22, Dmitry Baryshkov wrote: > >>>>>>>> On Fri, 3 Nov 2023 at 20:49, Komal Bajaj <quic_kbajaj@quicinc.com> wrote: > >>>>>>>>> > >>>>>>>>> Add qcm6490 devicetree file for QCM6490 IDP and QCM6490 RB3 > >>>>>>>>> platform. QCM6490 is derived from SC7280 meant for various > >>>>>>>>> form factor including IoT. > >>>>>>>>> > >>>>>>>>> Supported features are, as of now: > >>>>>>>>> * Debug UART > >>>>>>>>> * eMMC (only in IDP) > >>>>>>>>> * USB > >>>>>>>>> > >>>>>>> > >>>>>>> ... > >>>>>>> > >>>>>>>>> + > >>>>>>>>> diff --git a/arch/arm64/boot/dts/qcom/qcm6490-iot-common.dtsi b/arch/arm64/boot/dts/qcom/qcm6490-iot-common.dtsi > >>>>>>>>> new file mode 100644 > >>>>>>>>> index 000000000000..01adc97789d0 > >>>>>>>>> --- /dev/null > >>>>>>>>> +++ b/arch/arm64/boot/dts/qcom/qcm6490-iot-common.dtsi > >>>>>>>> > >>>>>>>> I have mixed feelings towards this file. Usually we add such 'common' > >>>>>>>> files only for the phone platforms where most of the devices are > >>>>>>>> common. > >>>>>>>> Do you expect that IDP and RB3 will have a lot of common code other > >>>>>>>> than these regulator settings? > >>>>>>> > >>>>>>> I agree here. What exactly is common in the real hardware between IDP > >>>>>>> and RB3? Commit msg does not explain it, so I do not see enough > >>>>>>> justification for common file. Just because some DTS looks similar for > >>>>>>> different hardware does not mean you should creat common file. > >>>>>> > >>>>>> @Dmitry/@Krzysztof, > >>>>>> > >>>>>> Thank you for reviewing the RFC, we wanted to continue the > >>>>>> suggestion/discussion given on [1] , where we discussed that this > >>>>>> qcm6490 is going to be targeted for IOT segment and will have different > >>>>>> memory map and it is going to use some of co-processors like adsp/cdsp > >>>>>> which chrome does not use. > >>>>>> > >>>>>> So to your question what is common between RB3 and IDP, mostly they will > >>>>>> share common memory map(similar to [2]) and regulator settings and both > >>>>>> will use adsp/cdsp etc., we will be posting the memory map changes as > >>>>>> well in coming weeks once this RFC is acked. > >>>>> > >>>>> Is the memory map going to be the same as the one used on Fairphone5? > >>>> > >>>> No, Fairphone5 looks to be using chrome memory map and i suggested > >>>> here to move them into sc7280.dtsi > >>>> > >>>> https://lore.kernel.org/lkml/d5d53346-ca3b-986a-e104-d87c37115b62@quicinc.com/ > >>>> > >>>>> > >>>>> Are ADSP and CDSP physically present on sc7280? > >>>> > >>>> Yes, they are present but not used. > >>> > >>> So ADSP and CDSP should go into sc7280.dtsi. They will anyway have > >>> status = "disabled"; > >>> > >>>> > >>>>> > >>>>> I think that your goal should be to: > >>>>> - populate missing device in sc7280.dtsi > >>>>> - maybe add qcm6490.dtsi which defines SoC-level common data (e.g. memory map) > >>>>> - push the rest to board files. > >>>> > >>>> Agree to all of the point. > >>>> We started with the same thought at[3] but it got lost in discussion > >>>> due to its differentiation with mobile counter part(fairphone) which > >>>> follow chrome memory map and hence we came up with qcm6490-iot-common. > >>>> Do you think, qcm6490-iot.dtsi should be good ? > >>> > >>> No. DT describes hardware, and -iot is not a hardware abstraction / unification. > >>> If you consider your memory map to be generic for the qcm6490 (and FP5 > >>> being the only exception), add it to the qcm6490.dtsi (and let FP5 > >>> override it, like some of the phones do). If it can not be considered > >>> generic for the SoC, then you have no other choice than to replicate > >>> it to all board files. > >> > > > > Hi Mukesh, > > > >> Thanks for the suggestion. > >> Let me add @Luca here for information, if he want to share > >> anything about qcm6490 fp5 memory map. > > > > Not sure I have much to share, just probably that on FP5 the memory > > setup and all the basics just come from a standard QCM6490.LA.3.0 > > release. > > I don't see any hint that our ODM changed something in the memory map > > for the device either. > > > > I'm also aware that other phones also use QCM6490 SoC, so I'm still > > wondering where the distinction between "FP5/ChromeOS memory map" vs > > this new QCM6490 memory map is. > > There's also e.g. this phone using QCM6490, I've not looked into this at > > all, but I'm guessing that phone uses the same memory map as FP5. > > https://www.crosscall.com/en_NL/core-z5-COZ5.MASTER.html > > Was looking for your view on the things about qcm6490.dtsi one common > dtsi file for all qcm6490.dtsi suggested in the mail, but looks like FP5 > is following the memory map based out of sc7280, in that case we have to > replicate the new memory map for all our IOT boards(idp/rb3) based on > this SoC. You can have IoT memory map in the qcm6490.dtsi and have the board-specific memory map in the qcm6490-fp5.dtsi, if that makes life easier. I think the phone DT already provides the memory map, so you just have to add statements to remove conflicting data entries. > > -Mukesh > > > > Regards > > Luca > > > >> > >> -Mukesh > >>> > >>>> > >>>> [3] > >>>> https://lore.kernel.org/linux-arm-msm/20231003175456.14774-3-quic_kbajaj@quicinc.com/ > >>>> > >>>> -Mukesh > >>>>> > >>>>> I don't think that putting regulators to the common file is a good > >>>>> idea. Platforms will further change and limit voltage limits and > >>>>> modes, so they usually go to the board file. > >>>>> > >>>>>> > >>>>>> > >>>>>> Thanks, > >>>>>> Mukesh > >>>>>> > >>>>>> [1] > >>>>>> https://lore.kernel.org/linux-arm-msm/d97ebf74-ad03-86d6-b826-b57be209b9e2@quicinc.com/ > >>>>>> > >>>>>> [2] > >>>>>> commit 90c856602e0346ce9ff234062e86a198d71fa723 > >>>>>> Author: Douglas Anderson <dianders@chromium.org> > >>>>>> Date: Tue Jan 25 14:44:20 2022 -0800 > >>>>>> > >>>>>> arm64: dts: qcom: sc7280: Factor out Chrome common fragment > >>>>>> > >>>>>> This factors out a device tree fragment from some sc7280 device > >>>>>> trees. It represents the device tree bits that should be included for > >>>>>> "Chrome" based sc7280 boards. On these boards the bootloader (Coreboot > >>>>>> + Depthcharge) configures things slightly different than the > >>>>>> bootloader that Qualcomm provides. The modem firmware on these boards > >>>>>> also works differently than on other Qulacomm products and thus the > >>>>>> reserved memory map needs to be adjusted. > >>>>>> > >>>>>> NOTES: > >>>>>> - This is _not_ quite a no-op change. The "herobrine" and "idp" > >>>>>> fragments here were different and it looks like someone simply > >>>>>> forgot to update the herobrine version. This updates a few numbers > >>>>>> to match IDP. This will also cause the `pmk8350_pon` to be disabled > >>>>>> on idp/crd, which I belive is a correct change. > >>>>>> - At the moment this assumes LTE skus. Once it's clearer how WiFi SKUs > >>>>>> will work (how much of the memory map they can reclaim) we may add > >>>>>> an extra fragment that will rejigger one way or the other. > >>>>>> > >>>>>> Signed-off-by: Douglas Anderson <dianders@chromium.org> > >>>>>> Reviewed-by: Stephen Boyd <swboyd@chromium.org> > >>>>>> Reviewed-by: Matthias Kaehlcke <mka@chromium.org> > >>>>>> Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org> > >>>>>> Link: > >>>>>> https://lore.kernel.org/r/20220125144316.v2.3.Iac012fa8d727be46448d47027a1813ea716423ce@changeid > >>>>>> > >>>>>> > >>>>>>> > >>>>>>> Best regards, > >>>>>>> Krzysztof > >>>>>>> > >>>>> > >>>>> > >>>>> > >>> > >>> > >>> > > -- With best wishes Dmitry ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [RFC PATCH 2/2] arm64: dts: qcom: qcm6490: Add qcm6490 idp and rb3 board 2023-11-06 11:41 ` Mukesh Ojha 2023-11-06 11:54 ` Dmitry Baryshkov @ 2023-11-06 13:05 ` Krzysztof Kozlowski 2023-11-06 14:51 ` Mukesh Ojha 1 sibling, 1 reply; 20+ messages in thread From: Krzysztof Kozlowski @ 2023-11-06 13:05 UTC (permalink / raw) To: Mukesh Ojha, Dmitry Baryshkov, Komal Bajaj Cc: Andy Gross, Bjorn Andersson, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski, Conor Dooley, linux-arm-msm, devicetree, linux-kernel, quic_nainmeht On 06/11/2023 12:41, Mukesh Ojha wrote: >> I agree here. What exactly is common in the real hardware between IDP >> and RB3? Commit msg does not explain it, so I do not see enough >> justification for common file. Just because some DTS looks similar for >> different hardware does not mean you should creat common file. > > @Dmitry/@Krzysztof, > > Thank you for reviewing the RFC, we wanted to continue the > suggestion/discussion given on [1] , where we discussed that this > qcm6490 is going to be targeted for IOT segment and will have different > memory map and it is going to use some of co-processors like adsp/cdsp > which chrome does not use. > > So to your question what is common between RB3 and IDP, mostly they will > share common memory map(similar to [2]) and regulator settings and both The question was what is common hardware, not common in your DTS. > will use adsp/cdsp etc., we will be posting the memory map changes as > well in coming weeks once this RFC is acked. Sorry, that's not common part of hardware. Best regards, Krzysztof ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [RFC PATCH 2/2] arm64: dts: qcom: qcm6490: Add qcm6490 idp and rb3 board 2023-11-06 13:05 ` Krzysztof Kozlowski @ 2023-11-06 14:51 ` Mukesh Ojha 0 siblings, 0 replies; 20+ messages in thread From: Mukesh Ojha @ 2023-11-06 14:51 UTC (permalink / raw) To: Krzysztof Kozlowski, Dmitry Baryshkov, Komal Bajaj Cc: Andy Gross, Bjorn Andersson, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski, Conor Dooley, linux-arm-msm, devicetree, linux-kernel, quic_nainmeht On 11/6/2023 6:35 PM, Krzysztof Kozlowski wrote: > On 06/11/2023 12:41, Mukesh Ojha wrote: > >>> I agree here. What exactly is common in the real hardware between IDP >>> and RB3? Commit msg does not explain it, so I do not see enough >>> justification for common file. Just because some DTS looks similar for >>> different hardware does not mean you should creat common file. >> >> @Dmitry/@Krzysztof, >> >> Thank you for reviewing the RFC, we wanted to continue the >> suggestion/discussion given on [1] , where we discussed that this >> qcm6490 is going to be targeted for IOT segment and will have different >> memory map and it is going to use some of co-processors like adsp/cdsp >> which chrome does not use. >> >> So to your question what is common between RB3 and IDP, mostly they will >> share common memory map(similar to [2]) and regulator settings and both > > The question was what is common hardware, not common in your DTS. Got your point. Let me know if you agree with the suggestion shared here https://lore.kernel.org/lkml/CAA8EJpq89g9EeyKcogU+Mt9ie6Bk-rmgi=GqyycYBm_291i1Bw@mail.gmail.com/ -Mukesh > > >> will use adsp/cdsp etc., we will be posting the memory map changes as >> well in coming weeks once this RFC is acked. > > Sorry, that's not common part of hardware. > > Best regards, > Krzysztof > ^ permalink raw reply [flat|nested] 20+ messages in thread
[parent not found: <4d8c094f-07b0-2b38-4680-145eb2d7c4f5@quicinc.com>]
* Re: [RFC PATCH 2/2] arm64: dts: qcom: qcm6490: Add qcm6490 idp and rb3 board [not found] ` <4d8c094f-07b0-2b38-4680-145eb2d7c4f5@quicinc.com> @ 2023-11-17 9:33 ` Dmitry Baryshkov 2023-11-17 12:43 ` Komal Bajaj 0 siblings, 1 reply; 20+ messages in thread From: Dmitry Baryshkov @ 2023-11-17 9:33 UTC (permalink / raw) To: Komal Bajaj Cc: Andy Gross, Bjorn Andersson, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski, Conor Dooley, linux-arm-msm, devicetree, linux-kernel, quic_nainmeht On Fri, 17 Nov 2023 at 08:53, Komal Bajaj <quic_kbajaj@quicinc.com> wrote: No HTML mail on kernel mailing lists, please. Some developers can have 'MIME => junk' mail filters. And replying to the HTML mail messes up quotation level. > On 11/4/2023 3:52 AM, Dmitry Baryshkov wrote: > > On Fri, 3 Nov 2023 at 20:49, Komal Bajaj <quic_kbajaj@quicinc.com> wrote: > > Add qcm6490 devicetree file for QCM6490 IDP and QCM6490 RB3 > platform. QCM6490 is derived from SC7280 meant for various > form factor including IoT. > > Supported features are, as of now: > * Debug UART > * eMMC (only in IDP) > * USB > > Co-developed-by: Naina Mehta <quic_nainmeht@quicinc.com> > Signed-off-by: Naina Mehta <quic_nainmeht@quicinc.com> > Signed-off-by: Komal Bajaj <quic_kbajaj@quicinc.com> > --- > arch/arm64/boot/dts/qcom/Makefile | 2 + > arch/arm64/boot/dts/qcom/qcm6490-idp.dts | 33 ++ > .../boot/dts/qcom/qcm6490-iot-common.dtsi | 291 ++++++++++++++++++ > arch/arm64/boot/dts/qcom/qcm6490-rb3.dts | 26 ++ > 4 files changed, 352 insertions(+) > create mode 100644 arch/arm64/boot/dts/qcom/qcm6490-idp.dts > create mode 100644 arch/arm64/boot/dts/qcom/qcm6490-iot-common.dtsi > create mode 100644 arch/arm64/boot/dts/qcom/qcm6490-rb3.dts > > > [...] > > > diff --git a/arch/arm64/boot/dts/qcom/qcm6490-rb3.dts b/arch/arm64/boot/dts/qcom/qcm6490-rb3.dts > new file mode 100644 > index 000000000000..5b4c2826ac5c > --- /dev/null > +++ b/arch/arm64/boot/dts/qcom/qcm6490-rb3.dts > @@ -0,0 +1,26 @@ > +// SPDX-License-Identifier: BSD-3-Clause > +/* > + * Copyright (c) 2023 Qualcomm Innovation Center, Inc. All rights reserved. > + */ > + > +/dts-v1/; > + > +/* PM7250B is configured to use SID8/9 */ > +#define PM7250B_SID 8 > +#define PM7250B_SID1 9 > + > +#include "qcm6490-iot-common.dtsi" > +#include "pm7250b.dtsi" > + > +/ { > + model = "Qualcomm Technologies, Inc. QCM6490 RB3"; > > Is this a marketing name of the platform? > > > Sorry for the confusion, QCS6490 RB3gen2 is the correct marketing name for this board. > Will correct this in the next patchset. Then it is probably "Qualcomm Technologies, Inc. Robotics RB3gen2"? > + compatible = "qcom,qcm6490-rb3", "qcom,qcm6490"; > > chassis-type = ? > > > No, this won't be needed as it is an evaluation board and will be used for multiple use cases. > So, we don't want to mark it to any specific type. Then it is "embedded". We should probably update existing dragonboards/RB boards to have this type too. -- With best wishes Dmitry ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [RFC PATCH 2/2] arm64: dts: qcom: qcm6490: Add qcm6490 idp and rb3 board 2023-11-17 9:33 ` Dmitry Baryshkov @ 2023-11-17 12:43 ` Komal Bajaj 0 siblings, 0 replies; 20+ messages in thread From: Komal Bajaj @ 2023-11-17 12:43 UTC (permalink / raw) To: Dmitry Baryshkov Cc: Andy Gross, Bjorn Andersson, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski, Conor Dooley, linux-arm-msm, devicetree, linux-kernel, quic_nainmeht On 11/17/2023 3:03 PM, Dmitry Baryshkov wrote: > On Fri, 17 Nov 2023 at 08:53, Komal Bajaj <quic_kbajaj@quicinc.com> wrote: > > No HTML mail on kernel mailing lists, please. Some developers can have > 'MIME => junk' mail filters. > And replying to the HTML mail messes up quotation level. > >> On 11/4/2023 3:52 AM, Dmitry Baryshkov wrote: >> >> On Fri, 3 Nov 2023 at 20:49, Komal Bajaj <quic_kbajaj@quicinc.com> wrote: >> >> Add qcm6490 devicetree file for QCM6490 IDP and QCM6490 RB3 >> platform. QCM6490 is derived from SC7280 meant for various >> form factor including IoT. >> >> Supported features are, as of now: >> * Debug UART >> * eMMC (only in IDP) >> * USB >> >> Co-developed-by: Naina Mehta <quic_nainmeht@quicinc.com> >> Signed-off-by: Naina Mehta <quic_nainmeht@quicinc.com> >> Signed-off-by: Komal Bajaj <quic_kbajaj@quicinc.com> >> --- >> arch/arm64/boot/dts/qcom/Makefile | 2 + >> arch/arm64/boot/dts/qcom/qcm6490-idp.dts | 33 ++ >> .../boot/dts/qcom/qcm6490-iot-common.dtsi | 291 ++++++++++++++++++ >> arch/arm64/boot/dts/qcom/qcm6490-rb3.dts | 26 ++ >> 4 files changed, 352 insertions(+) >> create mode 100644 arch/arm64/boot/dts/qcom/qcm6490-idp.dts >> create mode 100644 arch/arm64/boot/dts/qcom/qcm6490-iot-common.dtsi >> create mode 100644 arch/arm64/boot/dts/qcom/qcm6490-rb3.dts >> >> >> [...] >> >> >> diff --git a/arch/arm64/boot/dts/qcom/qcm6490-rb3.dts b/arch/arm64/boot/dts/qcom/qcm6490-rb3.dts >> new file mode 100644 >> index 000000000000..5b4c2826ac5c >> --- /dev/null >> +++ b/arch/arm64/boot/dts/qcom/qcm6490-rb3.dts >> @@ -0,0 +1,26 @@ >> +// SPDX-License-Identifier: BSD-3-Clause >> +/* >> + * Copyright (c) 2023 Qualcomm Innovation Center, Inc. All rights reserved. >> + */ >> + >> +/dts-v1/; >> + >> +/* PM7250B is configured to use SID8/9 */ >> +#define PM7250B_SID 8 >> +#define PM7250B_SID1 9 >> + >> +#include "qcm6490-iot-common.dtsi" >> +#include "pm7250b.dtsi" >> + >> +/ { >> + model = "Qualcomm Technologies, Inc. QCM6490 RB3"; >> >> Is this a marketing name of the platform? >> >> >> Sorry for the confusion, QCS6490 RB3gen2 is the correct marketing name for this board. >> Will correct this in the next patchset. > Then it is probably "Qualcomm Technologies, Inc. Robotics RB3gen2"? Okay. > >> + compatible = "qcom,qcm6490-rb3", "qcom,qcm6490"; >> >> chassis-type = ? >> >> >> No, this won't be needed as it is an evaluation board and will be used for multiple use cases. >> So, we don't want to mark it to any specific type. > Then it is "embedded". We should probably update existing > dragonboards/RB boards to have this type too. Okay, will chassis-type. Thanks Komal > ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [RFC PATCH 2/2] arm64: dts: qcom: qcm6490: Add qcm6490 idp and rb3 board 2023-11-03 18:46 ` [RFC PATCH 2/2] arm64: dts: qcom: qcm6490: Add qcm6490 idp and rb3 board Komal Bajaj 2023-11-03 22:22 ` Dmitry Baryshkov @ 2023-11-04 12:32 ` Konrad Dybcio 2023-11-17 12:49 ` Komal Bajaj 1 sibling, 1 reply; 20+ messages in thread From: Konrad Dybcio @ 2023-11-04 12:32 UTC (permalink / raw) To: Komal Bajaj, Andy Gross, Bjorn Andersson, Rob Herring, Krzysztof Kozlowski, Conor Dooley Cc: linux-arm-msm, devicetree, linux-kernel, quic_nainmeht On 11/3/23 19:46, Komal Bajaj wrote: > Add qcm6490 devicetree file for QCM6490 IDP and QCM6490 RB3 > platform. QCM6490 is derived from SC7280 meant for various > form factor including IoT. > > Supported features are, as of now: > * Debug UART > * eMMC (only in IDP) > * USB > > Co-developed-by: Naina Mehta <quic_nainmeht@quicinc.com> > Signed-off-by: Naina Mehta <quic_nainmeht@quicinc.com> > Signed-off-by: Komal Bajaj <quic_kbajaj@quicinc.com> > --- [...] > + > +&sdhc_1 { > + non-removable; > + no-sd; > + no-sdio; > + > + vmmc-supply = <&vreg_l7b_2p952>; > + vqmmc-supply = <&vreg_l19b_1p8>; I think you also need to add regulator-allow-set-mode and something something regulator allowed modes to VQMMC [...] > + model = "Qualcomm Technologies, Inc. QCM6490 RB3"; Is the name just "QCM6490 RB3"? One already exists, based on SDM845. Otherwise, this looks very good to me now, thanks. With these nits addressed: Reviewed-by: Konrad Dybcio <konrad.dybcio@linaro.org> Konrad ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [RFC PATCH 2/2] arm64: dts: qcom: qcm6490: Add qcm6490 idp and rb3 board 2023-11-04 12:32 ` Konrad Dybcio @ 2023-11-17 12:49 ` Komal Bajaj 0 siblings, 0 replies; 20+ messages in thread From: Komal Bajaj @ 2023-11-17 12:49 UTC (permalink / raw) To: Konrad Dybcio, Andy Gross, Bjorn Andersson, Rob Herring, Krzysztof Kozlowski, Conor Dooley Cc: linux-arm-msm, devicetree, linux-kernel, quic_nainmeht On 11/4/2023 6:02 PM, Konrad Dybcio wrote: > > > On 11/3/23 19:46, Komal Bajaj wrote: >> Add qcm6490 devicetree file for QCM6490 IDP and QCM6490 RB3 >> platform. QCM6490 is derived from SC7280 meant for various >> form factor including IoT. >> >> Supported features are, as of now: >> * Debug UART >> * eMMC (only in IDP) >> * USB >> >> Co-developed-by: Naina Mehta <quic_nainmeht@quicinc.com> >> Signed-off-by: Naina Mehta <quic_nainmeht@quicinc.com> >> Signed-off-by: Komal Bajaj <quic_kbajaj@quicinc.com> >> --- > [...] > >> + >> +&sdhc_1 { >> + non-removable; >> + no-sd; >> + no-sdio; >> + >> + vmmc-supply = <&vreg_l7b_2p952>; >> + vqmmc-supply = <&vreg_l19b_1p8>; > I think you also need to add regulator-allow-set-mode and something > something regulator allowed modes to VQMMC Okay, will add properties "regulator-allow-set-load" and "regulator-allowed-modes" to regulator vreg_l19b_1p8. > > [...] > >> + model = "Qualcomm Technologies, Inc. QCM6490 RB3"; > Is the name just "QCM6490 RB3"? One already exists, based on SDM845. Yeah, I missed that, this board is RB3Gen2, will update that in next patchset. Thanks Komal > > Otherwise, this looks very good to me now, thanks. > > With these nits addressed: > > Reviewed-by: Konrad Dybcio <konrad.dybcio@linaro.org> > > Konrad ^ permalink raw reply [flat|nested] 20+ messages in thread
end of thread, other threads:[~2023-11-17 12:49 UTC | newest]
Thread overview: 20+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2023-11-03 18:46 [RFC PATCH 0/2] Add support for qcm6490 idp and rb3 board Komal Bajaj
2023-11-03 18:46 ` [RFC PATCH 1/2] dt-bindings: arm: qcom: Add QCM6490 IDP and RB3 board Komal Bajaj
2023-11-05 13:06 ` Krzysztof Kozlowski
2023-11-03 18:46 ` [RFC PATCH 2/2] arm64: dts: qcom: qcm6490: Add qcm6490 idp and rb3 board Komal Bajaj
2023-11-03 22:22 ` Dmitry Baryshkov
2023-11-05 13:08 ` Krzysztof Kozlowski
2023-11-06 11:41 ` Mukesh Ojha
2023-11-06 11:54 ` Dmitry Baryshkov
2023-11-06 14:45 ` Mukesh Ojha
2023-11-06 22:32 ` Dmitry Baryshkov
2023-11-07 8:10 ` Mukesh Ojha
2023-11-13 15:51 ` Luca Weiss
2023-11-14 12:48 ` Mukesh Ojha
2023-11-14 12:53 ` Dmitry Baryshkov
2023-11-06 13:05 ` Krzysztof Kozlowski
2023-11-06 14:51 ` Mukesh Ojha
[not found] ` <4d8c094f-07b0-2b38-4680-145eb2d7c4f5@quicinc.com>
2023-11-17 9:33 ` Dmitry Baryshkov
2023-11-17 12:43 ` Komal Bajaj
2023-11-04 12:32 ` Konrad Dybcio
2023-11-17 12:49 ` Komal Bajaj
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).