[PATCH 0/3] Add initial device tree for Billion Capture+

[PATCH 0/3] Add initial device tree for Billion Capture+

[Cristian Cozzolino via B4 Relay]

Billion Capture+ is a handset using the MSM8953 SoC released in 2017
and sold by Flipkart.

Add a device tree with initial support for:

- GPIO keys
- SDHCI (internal and external storage)
- USB Device Mode
- Regulators
- Simple framebuffer

Signed-off-by: Cristian Cozzolino <cristian_ci@protonmail.com>
---
Cristian Cozzolino (3):
      dt-bindings: vendor-prefixes: Add Flipkart
      dt-bindings: arm: qcom: Add Billion Capture+
      arm64: dts: qcom: msm8953: Add device tree for Billion Capture+

 Documentation/devicetree/bindings/arm/qcom.yaml    |   1 +
 .../devicetree/bindings/vendor-prefixes.yaml       |   2 +
 arch/arm64/boot/dts/qcom/Makefile                  |   1 +
 .../arm64/boot/dts/qcom/msm8953-flipkart-rimob.dts | 251 +++++++++++++++++++++
 4 files changed, 255 insertions(+)
---
base-commit: 0ff41df1cb268fc69e703a08a57ee14ae967d0ca
change-id: 20250620-rimob-initial-devicetree-da86a5bffc8b

Best regards,
-- 
Cristian Cozzolino <cristian_ci@protonmail.com>

[PATCH 1/3] dt-bindings: vendor-prefixes: Add Flipkart

[Cristian Cozzolino via B4 Relay]

From: Cristian Cozzolino <cristian_ci@protonmail.com>

Add Flipkart to the vendor prefixes.

Signed-off-by: Cristian Cozzolino <cristian_ci@protonmail.com>
---
 Documentation/devicetree/bindings/vendor-prefixes.yaml | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/Documentation/devicetree/bindings/vendor-prefixes.yaml b/Documentation/devicetree/bindings/vendor-prefixes.yaml
index 86f6a19b28ae217643bf7a63a471f74819d18238..1516d670e3ac81e3e00fb687cda64d50eb3e2049 100644
--- a/Documentation/devicetree/bindings/vendor-prefixes.yaml
+++ b/Documentation/devicetree/bindings/vendor-prefixes.yaml
@@ -535,6 +535,8 @@ patternProperties:
     description: Foxconn Industrial Internet
   "^firefly,.*":
     description: Firefly
+  "^flipkart,.*":
+    description: Flipkart Inc.
   "^focaltech,.*":
     description: FocalTech Systems Co.,Ltd
   "^forlinx,.*":

-- 
2.49.0

[PATCH 2/3] dt-bindings: arm: qcom: Add Billion Capture+

[Cristian Cozzolino via B4 Relay]

From: Cristian Cozzolino <cristian_ci@protonmail.com>

Billion Capture+ (flipkart,rimob) is a smartphone based on Qualcomm
Snapdragon 625 (MSM8953).

Signed-off-by: Cristian Cozzolino <cristian_ci@protonmail.com>
---
 Documentation/devicetree/bindings/arm/qcom.yaml | 1 +
 1 file changed, 1 insertion(+)

diff --git a/Documentation/devicetree/bindings/arm/qcom.yaml b/Documentation/devicetree/bindings/arm/qcom.yaml
index 618a87693ac1dc32b40a2201bc219a4f12e9f3e8..dbe605557af82c2382702011276e920ea18d3bb8 100644
--- a/Documentation/devicetree/bindings/arm/qcom.yaml
+++ b/Documentation/devicetree/bindings/arm/qcom.yaml
@@ -274,6 +274,7 @@ properties:
 
       - items:
           - enum:
+              - flipkart,rimob
               - motorola,potter
               - xiaomi,daisy
               - xiaomi,mido

-- 
2.49.0

[PATCH 3/3] arm64: dts: qcom: msm8953: Add device tree for Billion Capture+

[Cristian Cozzolino via B4 Relay]

From: Cristian Cozzolino <cristian_ci@protonmail.com>

Billion Capture+ (flipkart,rimob) is a smartphone released in 2017, based
on Snapdragon 625 (MSM8953) SoC.

Add a device tree with initial support for:

- GPIO keys
- SDHCI (internal and external storage)
- USB Device Mode
- Regulators
- Simple framebuffer

Signed-off-by: Cristian Cozzolino <cristian_ci@protonmail.com>
---
 arch/arm64/boot/dts/qcom/Makefile                  |   1 +
 .../arm64/boot/dts/qcom/msm8953-flipkart-rimob.dts | 251 +++++++++++++++++++++
 2 files changed, 252 insertions(+)

diff --git a/arch/arm64/boot/dts/qcom/Makefile b/arch/arm64/boot/dts/qcom/Makefile
index 140b0b2abfb555b8ef61bd9ed0217d8997800809..af3757ca017b6e3d8c579e43f647a71fc64c62b3 100644
--- a/arch/arm64/boot/dts/qcom/Makefile
+++ b/arch/arm64/boot/dts/qcom/Makefile
@@ -70,6 +70,7 @@ dtb-$(CONFIG_ARCH_QCOM)	+= msm8939-samsung-a7.dtb
 dtb-$(CONFIG_ARCH_QCOM)	+= msm8939-sony-xperia-kanuti-tulip.dtb
 dtb-$(CONFIG_ARCH_QCOM)	+= msm8939-wingtech-wt82918.dtb
 dtb-$(CONFIG_ARCH_QCOM)	+= msm8939-wingtech-wt82918hd.dtb
+dtb-$(CONFIG_ARCH_QCOM)	+= msm8953-flipkart-rimob.dtb
 dtb-$(CONFIG_ARCH_QCOM)	+= msm8953-motorola-potter.dtb
 dtb-$(CONFIG_ARCH_QCOM)	+= msm8953-xiaomi-daisy.dtb
 dtb-$(CONFIG_ARCH_QCOM)	+= msm8953-xiaomi-mido.dtb
diff --git a/arch/arm64/boot/dts/qcom/msm8953-flipkart-rimob.dts b/arch/arm64/boot/dts/qcom/msm8953-flipkart-rimob.dts
new file mode 100644
index 0000000000000000000000000000000000000000..9fc58bb4dae7b463691659f8e84a634529642b69
--- /dev/null
+++ b/arch/arm64/boot/dts/qcom/msm8953-flipkart-rimob.dts
@@ -0,0 +1,251 @@
+// SPDX-License-Identifier: BSD-3-Clause
+/*
+ * Copyright (c) 2025, Cristian Cozzolino
+ */
+/dts-v1/;
+
+#include "msm8953.dtsi"
+#include "pm8953.dtsi"
+#include "pmi8950.dtsi"
+
+/delete-node/ &cont_splash_mem;
+/delete-node/ &qseecom_mem;
+
+/ {
+	model = "Billion Capture+";
+	compatible = "flipkart,rimob", "qcom,msm8953";
+	chassis-type = "handset";
+	qcom,msm-id = <293 0>;
+	qcom,board-id = <0x340008 0>;
+
+	chosen {
+		#address-cells = <2>;
+		#size-cells = <2>;
+		ranges;
+
+		framebuffer@90001000 {
+			compatible = "simple-framebuffer";
+			reg = <0 0x90001000 0 (1920 * 1080 * 3)>;
+
+			width = <1080>;
+			height = <1920>;
+			stride = <(1080 * 3)>;
+			format = "r8g8b8";
+
+			power-domains = <&gcc MDSS_GDSC>;
+
+			clocks = <&gcc GCC_MDSS_AHB_CLK>,
+				 <&gcc GCC_MDSS_AXI_CLK>,
+				 <&gcc GCC_MDSS_VSYNC_CLK>,
+				 <&gcc GCC_MDSS_MDP_CLK>,
+				 <&gcc GCC_MDSS_BYTE0_CLK>,
+				 <&gcc GCC_MDSS_PCLK0_CLK>,
+				 <&gcc GCC_MDSS_ESC0_CLK>;
+		};
+	};
+
+	gpio-keys {
+		compatible = "gpio-keys";
+
+		pinctrl-names = "default";
+		pinctrl-0 = <&gpio_key_default>;
+
+		key-volume-up {
+			label = "Volume Up";
+			gpios = <&tlmm 85 GPIO_ACTIVE_LOW>;
+			linux,code = <KEY_VOLUMEUP>;
+			debounce-interval = <15>;
+		};
+	};
+
+	reserved-memory {
+		qseecom@0 {
+			reg = <0x00 0x84a00000 0x00 0x1900000>;
+			no-map;
+		};
+
+		cont_splash_mem: cont-splash@90001000 {
+			reg = <0x0 0x90001000 0x0 (1080 * 1920 * 3)>;
+			no-map;
+		};
+	};
+
+	vph_pwr: vph-pwr-regulator {
+		compatible = "regulator-fixed";
+		regulator-name = "vph_pwr";
+		regulator-always-on;
+		regulator-boot-on;
+	};
+};
+
+
+&hsusb_phy {
+	vdd-supply = <&pm8953_l3>;
+	vdda-pll-supply = <&pm8953_l7>;
+	vdda-phy-dpdm-supply = <&pm8953_l13>;
+
+	status = "okay";
+};
+
+&pm8953_resin {
+	linux,code = <KEY_VOLUMEDOWN>;
+	status = "okay";
+};
+
+&rpm_requests {
+	regulators {
+		compatible = "qcom,rpm-pm8953-regulators";
+		vdd_s1-supply = <&vph_pwr>;
+		vdd_s2-supply = <&vph_pwr>;
+		vdd_s3-supply = <&vph_pwr>;
+		vdd_s4-supply = <&vph_pwr>;
+		vdd_s5-supply = <&vph_pwr>;
+		vdd_s6-supply = <&vph_pwr>;
+		vdd_s7-supply = <&vph_pwr>;
+		vdd_l1-supply = <&pm8953_s3>;
+		vdd_l2_l3-supply = <&pm8953_s3>;
+		vdd_l4_l5_l6_l7_l16_l19-supply = <&pm8953_s4>;
+		vdd_l8_l11_l12_l13_l14_l15-supply = <&vph_pwr>;
+		vdd_l9_l10_l17_l18_l22-supply = <&vph_pwr>;
+		vdd_l23-supply = <&pm8953_s3>;
+
+		pm8953_s1: s1 {
+			regulator-min-microvolt = <870000>;
+			regulator-max-microvolt = <1156000>;
+		};
+
+		pm8953_s3: s3 {
+			regulator-min-microvolt = <1224000>;
+			regulator-max-microvolt = <1224000>;
+		};
+
+		pm8953_s4: s4 {
+			regulator-min-microvolt = <1900000>;
+			regulator-max-microvolt = <2050000>;
+		};
+
+		pm8953_l1: l1 {
+			regulator-min-microvolt = <1000000>;
+			regulator-max-microvolt = <1000000>;
+		};
+
+		pm8953_l2: l2 {
+			regulator-min-microvolt = <975000>;
+			regulator-max-microvolt = <1225000>;
+		};
+
+		pm8953_l3: l3 {
+			regulator-min-microvolt = <925000>;
+			regulator-max-microvolt = <925000>;
+		};
+
+		pm8953_l5: l5 {
+			regulator-min-microvolt = <1800000>;
+			regulator-max-microvolt = <1800000>;
+		};
+
+		pm8953_l6: l6 {
+			regulator-min-microvolt = <1800000>;
+			regulator-max-microvolt = <1800000>;
+		};
+
+		pm8953_l7: l7 {
+			regulator-min-microvolt = <1800000>;
+			regulator-max-microvolt = <1900000>;
+		};
+
+		pm8953_l8: l8 {
+			regulator-min-microvolt = <2900000>;
+			regulator-max-microvolt = <2900000>;
+		};
+
+		pm8953_l9: l9 {
+			regulator-min-microvolt = <3000000>;
+			regulator-max-microvolt = <3300000>;
+		};
+
+		pm8953_l10: l10 {
+			regulator-min-microvolt = <2850000>;
+			regulator-max-microvolt = <2850000>;
+		};
+
+		pm8953_l11: l11 {
+			regulator-min-microvolt = <2950000>;
+			regulator-max-microvolt = <2950000>;
+		};
+
+		pm8953_l12: l12 {
+			regulator-min-microvolt = <1800000>;
+			regulator-max-microvolt = <2950000>;
+		};
+
+		pm8953_l13: l13 {
+			regulator-min-microvolt = <3125000>;
+			regulator-max-microvolt = <3125000>;
+		};
+
+		pm8953_l16: l16 {
+			regulator-min-microvolt = <1800000>;
+			regulator-max-microvolt = <1800000>;
+		};
+
+		pm8953_l17: l17 {
+			regulator-min-microvolt = <2850000>;
+			regulator-max-microvolt = <2850000>;
+		};
+
+		pm8953_l19: l19 {
+			regulator-min-microvolt = <1200000>;
+			regulator-max-microvolt = <1350000>;
+		};
+
+		pm8953_l22: l22 {
+			regulator-min-microvolt = <2800000>;
+			regulator-max-microvolt = <2800000>;
+		};
+
+		pm8953_l23: l23 {
+			regulator-min-microvolt = <975000>;
+			regulator-max-microvolt = <1225000>;
+		};
+	};
+};
+
+&sdhc_1 {
+	vmmc-supply = <&pm8953_l8>;
+	vqmmc-supply = <&pm8953_l5>;
+
+	status = "okay";
+};
+
+&sdhc_2 {
+	vmmc-supply = <&pm8953_l11>;
+	vqmmc-supply = <&pm8953_l12>;
+
+	cd-gpios = <&tlmm 133 GPIO_ACTIVE_HIGH>;
+
+	pinctrl-0 = <&sdc2_clk_on &sdc2_cmd_on &sdc2_data_on &sdc2_cd_on>;
+	pinctrl-1 = <&sdc2_clk_off &sdc2_cmd_off &sdc2_data_off>;
+	pinctrl-names = "default", "sleep";
+
+	status = "okay";
+};
+
+&tlmm {
+	gpio-reserved-ranges = <0 4>, <135 4>;
+
+	gpio_key_default: gpio-key-default-state {
+		pins = "gpio85";
+		function = "gpio";
+		drive-strength = <2>;
+		bias-pull-up;
+	};
+};
+
+&usb3 {
+	status = "okay";
+};
+
+&usb3_dwc3 {
+	dr_mode = "peripheral";
+};

-- 
2.49.0

Re: [PATCH 3/3] arm64: dts: qcom: msm8953: Add device tree for Billion Capture+

[Luca Weiss]

Hi Cristian,

On 20-06-2025 11:51 p.m., Cristian Cozzolino via B4 Relay wrote:
> From: Cristian Cozzolino <cristian_ci@protonmail.com>
> 
> Billion Capture+ (flipkart,rimob) is a smartphone released in 2017, based
> on Snapdragon 625 (MSM8953) SoC.
> 
> Add a device tree with initial support for:
> 
> - GPIO keys
> - SDHCI (internal and external storage)
> - USB Device Mode
> - Regulators
> - Simple framebuffer

Thanks for sending this upstream!

> 
> Signed-off-by: Cristian Cozzolino <cristian_ci@protonmail.com>
> ---
>   arch/arm64/boot/dts/qcom/Makefile                  |   1 +
>   .../arm64/boot/dts/qcom/msm8953-flipkart-rimob.dts | 251 +++++++++++++++++++++
>   2 files changed, 252 insertions(+)
> 
> diff --git a/arch/arm64/boot/dts/qcom/Makefile b/arch/arm64/boot/dts/qcom/Makefile
> index 140b0b2abfb555b8ef61bd9ed0217d8997800809..af3757ca017b6e3d8c579e43f647a71fc64c62b3 100644
> --- a/arch/arm64/boot/dts/qcom/Makefile
> +++ b/arch/arm64/boot/dts/qcom/Makefile
> @@ -70,6 +70,7 @@ dtb-$(CONFIG_ARCH_QCOM)	+= msm8939-samsung-a7.dtb
>   dtb-$(CONFIG_ARCH_QCOM)	+= msm8939-sony-xperia-kanuti-tulip.dtb
>   dtb-$(CONFIG_ARCH_QCOM)	+= msm8939-wingtech-wt82918.dtb
>   dtb-$(CONFIG_ARCH_QCOM)	+= msm8939-wingtech-wt82918hd.dtb
> +dtb-$(CONFIG_ARCH_QCOM)	+= msm8953-flipkart-rimob.dtb
>   dtb-$(CONFIG_ARCH_QCOM)	+= msm8953-motorola-potter.dtb
>   dtb-$(CONFIG_ARCH_QCOM)	+= msm8953-xiaomi-daisy.dtb
>   dtb-$(CONFIG_ARCH_QCOM)	+= msm8953-xiaomi-mido.dtb
> diff --git a/arch/arm64/boot/dts/qcom/msm8953-flipkart-rimob.dts b/arch/arm64/boot/dts/qcom/msm8953-flipkart-rimob.dts
> new file mode 100644
> index 0000000000000000000000000000000000000000..9fc58bb4dae7b463691659f8e84a634529642b69
> --- /dev/null
> +++ b/arch/arm64/boot/dts/qcom/msm8953-flipkart-rimob.dts
> @@ -0,0 +1,251 @@
> +// SPDX-License-Identifier: BSD-3-Clause
> +/*
> + * Copyright (c) 2025, Cristian Cozzolino
> + */
> +/dts-v1/;
> +
> +#include "msm8953.dtsi"
> +#include "pm8953.dtsi"
> +#include "pmi8950.dtsi"
> +
> +/delete-node/ &cont_splash_mem;
> +/delete-node/ &qseecom_mem;
> +
> +/ {
> +	model = "Billion Capture+";
> +	compatible = "flipkart,rimob", "qcom,msm8953";
> +	chassis-type = "handset";
> +	qcom,msm-id = <293 0>;
> +	qcom,board-id = <0x340008 0>;
> +
> +	chosen {
> +		#address-cells = <2>;
> +		#size-cells = <2>;
> +		ranges;
> +
> +		framebuffer@90001000 {
> +			compatible = "simple-framebuffer";
> +			reg = <0 0x90001000 0 (1920 * 1080 * 3)>;
> +
> +			width = <1080>;
> +			height = <1920>;
> +			stride = <(1080 * 3)>;
> +			format = "r8g8b8";
> +
> +			power-domains = <&gcc MDSS_GDSC>;
> +
> +			clocks = <&gcc GCC_MDSS_AHB_CLK>,
> +				 <&gcc GCC_MDSS_AXI_CLK>,
> +				 <&gcc GCC_MDSS_VSYNC_CLK>,
> +				 <&gcc GCC_MDSS_MDP_CLK>,
> +				 <&gcc GCC_MDSS_BYTE0_CLK>,
> +				 <&gcc GCC_MDSS_PCLK0_CLK>,
> +				 <&gcc GCC_MDSS_ESC0_CLK>;
> +		};
> +	};
> +
> +	gpio-keys {
> +		compatible = "gpio-keys";
> +
> +		pinctrl-names = "default";
> +		pinctrl-0 = <&gpio_key_default>;
> +
> +		key-volume-up {
> +			label = "Volume Up";
> +			gpios = <&tlmm 85 GPIO_ACTIVE_LOW>;
> +			linux,code = <KEY_VOLUMEUP>;
> +			debounce-interval = <15>;
> +		};
> +	};
> +
> +	reserved-memory {
> +		qseecom@0 {

qseecom@84a00000 ?

> +			reg = <0x00 0x84a00000 0x00 0x1900000>;
> +			no-map;
> +		};
> +
> +		cont_splash_mem: cont-splash@90001000 {
> +			reg = <0x0 0x90001000 0x0 (1080 * 1920 * 3)>;
> +			no-map;
> +		};
> +	};
> +
> +	vph_pwr: vph-pwr-regulator {
> +		compatible = "regulator-fixed";
> +		regulator-name = "vph_pwr";
> +		regulator-always-on;
> +		regulator-boot-on;
> +	};
> +};
> +
> +
> +&hsusb_phy {
> +	vdd-supply = <&pm8953_l3>;
> +	vdda-pll-supply = <&pm8953_l7>;
> +	vdda-phy-dpdm-supply = <&pm8953_l13>;
> +
> +	status = "okay";
> +};
> +
> +&pm8953_resin {
> +	linux,code = <KEY_VOLUMEDOWN>;
> +	status = "okay";
> +};
> +
> +&rpm_requests {
> +	regulators {
> +		compatible = "qcom,rpm-pm8953-regulators";
> +		vdd_s1-supply = <&vph_pwr>;
> +		vdd_s2-supply = <&vph_pwr>;
> +		vdd_s3-supply = <&vph_pwr>;
> +		vdd_s4-supply = <&vph_pwr>;
> +		vdd_s5-supply = <&vph_pwr>;
> +		vdd_s6-supply = <&vph_pwr>;
> +		vdd_s7-supply = <&vph_pwr>;
> +		vdd_l1-supply = <&pm8953_s3>;
> +		vdd_l2_l3-supply = <&pm8953_s3>;
> +		vdd_l4_l5_l6_l7_l16_l19-supply = <&pm8953_s4>;
> +		vdd_l8_l11_l12_l13_l14_l15-supply = <&vph_pwr>;
> +		vdd_l9_l10_l17_l18_l22-supply = <&vph_pwr>;
> +		vdd_l23-supply = <&pm8953_s3>;
> +
> +		pm8953_s1: s1 {
> +			regulator-min-microvolt = <870000>;
> +			regulator-max-microvolt = <1156000>;
> +		};
> +
> +		pm8953_s3: s3 {
> +			regulator-min-microvolt = <1224000>;
> +			regulator-max-microvolt = <1224000>;
> +		};
> +
> +		pm8953_s4: s4 {
> +			regulator-min-microvolt = <1900000>;
> +			regulator-max-microvolt = <2050000>;
> +		};
> +
> +		pm8953_l1: l1 {
> +			regulator-min-microvolt = <1000000>;
> +			regulator-max-microvolt = <1000000>;
> +		};
> +
> +		pm8953_l2: l2 {
> +			regulator-min-microvolt = <975000>;
> +			regulator-max-microvolt = <1225000>;
> +		};
> +
> +		pm8953_l3: l3 {
> +			regulator-min-microvolt = <925000>;
> +			regulator-max-microvolt = <925000>;
> +		};
> +
> +		pm8953_l5: l5 {
> +			regulator-min-microvolt = <1800000>;
> +			regulator-max-microvolt = <1800000>;
> +		};
> +
> +		pm8953_l6: l6 {
> +			regulator-min-microvolt = <1800000>;
> +			regulator-max-microvolt = <1800000>;
> +		};
> +
> +		pm8953_l7: l7 {
> +			regulator-min-microvolt = <1800000>;
> +			regulator-max-microvolt = <1900000>;
> +		};
> +
> +		pm8953_l8: l8 {
> +			regulator-min-microvolt = <2900000>;
> +			regulator-max-microvolt = <2900000>;
> +		};
> +
> +		pm8953_l9: l9 {
> +			regulator-min-microvolt = <3000000>;
> +			regulator-max-microvolt = <3300000>;
> +		};
> +
> +		pm8953_l10: l10 {
> +			regulator-min-microvolt = <2850000>;
> +			regulator-max-microvolt = <2850000>;
> +		};
> +
> +		pm8953_l11: l11 {
> +			regulator-min-microvolt = <2950000>;
> +			regulator-max-microvolt = <2950000>;
> +		};
> +
> +		pm8953_l12: l12 {
> +			regulator-min-microvolt = <1800000>;
> +			regulator-max-microvolt = <2950000>;
> +		};
> +
> +		pm8953_l13: l13 {
> +			regulator-min-microvolt = <3125000>;
> +			regulator-max-microvolt = <3125000>;
> +		};
> +
> +		pm8953_l16: l16 {
> +			regulator-min-microvolt = <1800000>;
> +			regulator-max-microvolt = <1800000>;
> +		};
> +
> +		pm8953_l17: l17 {
> +			regulator-min-microvolt = <2850000>;
> +			regulator-max-microvolt = <2850000>;
> +		};
> +
> +		pm8953_l19: l19 {
> +			regulator-min-microvolt = <1200000>;
> +			regulator-max-microvolt = <1350000>;
> +		};
> +
> +		pm8953_l22: l22 {
> +			regulator-min-microvolt = <2800000>;
> +			regulator-max-microvolt = <2800000>;
> +		};
> +
> +		pm8953_l23: l23 {
> +			regulator-min-microvolt = <975000>;
> +			regulator-max-microvolt = <1225000>;
> +		};
> +	};
> +};
> +
> +&sdhc_1 {
> +	vmmc-supply = <&pm8953_l8>;
> +	vqmmc-supply = <&pm8953_l5>;
> +
> +	status = "okay";
> +};
> +
> +&sdhc_2 {
> +	vmmc-supply = <&pm8953_l11>;
> +	vqmmc-supply = <&pm8953_l12>;
> +
> +	cd-gpios = <&tlmm 133 GPIO_ACTIVE_HIGH>;
> +
> +	pinctrl-0 = <&sdc2_clk_on &sdc2_cmd_on &sdc2_data_on &sdc2_cd_on>;
> +	pinctrl-1 = <&sdc2_clk_off &sdc2_cmd_off &sdc2_data_off>;
> +	pinctrl-names = "default", "sleep";
> +
> +	status = "okay";
> +};
> +
> +&tlmm {
> +	gpio-reserved-ranges = <0 4>, <135 4>;

Any ideas what's connected to these pins? If you do, good to document 
this like in other devices.

Regards
Luca

> +
> +	gpio_key_default: gpio-key-default-state {
> +		pins = "gpio85";
> +		function = "gpio";
> +		drive-strength = <2>;
> +		bias-pull-up;
> +	};
> +};
> +
> +&usb3 {
> +	status = "okay";
> +};
> +
> +&usb3_dwc3 {
> +	dr_mode = "peripheral";
> +};
> 

Re: [PATCH 3/3] arm64: dts: qcom: msm8953: Add device tree for Billion Capture+

[cristian_ci]

On Saturday, June 21st, 2025 at 00:20, Luca Weiss <luca@lucaweiss.eu> wrote:

> > +
> > + reserved-memory {
> > + qseecom@0 {
> 
> 
> qseecom@84a00000 ?
> 
> > + reg = <0x00 0x84a00000 0x00 0x1900000>;
> > + no-map;
> > + };

Looking at downstream devicetree, every reserved-memory nodes with "removed-dma-pool" compatible has unit address 0. OTOH, kernel documentation [1] says:
"  Following the generic-names recommended practice, node names should
  reflect the purpose of the node (ie. "framebuffer" or "dma-pool").
  Unit address (@<address>) should be appended to the name if the node
  is a static allocation."

In my case, downstream devicetree shows:

		other_ext_region@0 {
			compatible = "removed-dma-pool";
			no-map;
			reg = <0x00 0x84a00000 0x00 0x1e00000>;
		};

which will be 'qseecom' reserved-memory node in mainline devicetree.

OTOH, 'qseecom' node in downstream devicetree also shows:

		qseecom@84a00000 {
			compatible = "qcom,qseecom";
			reg = <0x84a00000 0x1900000>;
                        ...

If you confirm what you suggest, 'qseecom' reserved-memory node will look like the following:

		qseecom_mem: qseecom@84a00000 {
			reg = <0x0 0x84a00000 0x0 0x1900000>;
			no-map;
		};

[1] https://www.kernel.org/doc/Documentation/devicetree/bindings/reserved-memory/reserved-memory.yaml

> > + cont_splash_mem: cont-splash@90001000 {
> > + reg = <0x0 0x90001000 0x0 (1080 * 1920 * 3)>;
> > + no-map;
> > + };
> > + };
> > +
> > + vph_pwr: vph-pwr-regulator {
> > + compatible = "regulator-fixed";
> > + regulator-name = "vph_pwr";
> > + regulator-always-on;
> > + regulator-boot-on;
> > + };
> > +};
> > +
> > +
> > +&hsusb_phy {
> > + vdd-supply = <&pm8953_l3>;
> > + vdda-pll-supply = <&pm8953_l7>;
> > + vdda-phy-dpdm-supply = <&pm8953_l13>;
> > +
> > + status = "okay";
> > +};
> > +
> > +&pm8953_resin {
> > + linux,code = <KEY_VOLUMEDOWN>;
> > + status = "okay";
> > +};
> > +
> > +&rpm_requests {
> > + regulators {
> > + compatible = "qcom,rpm-pm8953-regulators";
> > + vdd_s1-supply = <&vph_pwr>;
> > + vdd_s2-supply = <&vph_pwr>;
> > + vdd_s3-supply = <&vph_pwr>;
> > + vdd_s4-supply = <&vph_pwr>;
> > + vdd_s5-supply = <&vph_pwr>;
> > + vdd_s6-supply = <&vph_pwr>;
> > + vdd_s7-supply = <&vph_pwr>;
> > + vdd_l1-supply = <&pm8953_s3>;
> > + vdd_l2_l3-supply = <&pm8953_s3>;
> > + vdd_l4_l5_l6_l7_l16_l19-supply = <&pm8953_s4>;
> > + vdd_l8_l11_l12_l13_l14_l15-supply = <&vph_pwr>;
> > + vdd_l9_l10_l17_l18_l22-supply = <&vph_pwr>;
> > + vdd_l23-supply = <&pm8953_s3>;
> > +
> > + pm8953_s1: s1 {
> > + regulator-min-microvolt = <870000>;
> > + regulator-max-microvolt = <1156000>;
> > + };
> > +
> > + pm8953_s3: s3 {
> > + regulator-min-microvolt = <1224000>;
> > + regulator-max-microvolt = <1224000>;
> > + };
> > +
> > + pm8953_s4: s4 {
> > + regulator-min-microvolt = <1900000>;
> > + regulator-max-microvolt = <2050000>;
> > + };
> > +
> > + pm8953_l1: l1 {
> > + regulator-min-microvolt = <1000000>;
> > + regulator-max-microvolt = <1000000>;
> > + };
> > +
> > + pm8953_l2: l2 {
> > + regulator-min-microvolt = <975000>;
> > + regulator-max-microvolt = <1225000>;
> > + };
> > +
> > + pm8953_l3: l3 {
> > + regulator-min-microvolt = <925000>;
> > + regulator-max-microvolt = <925000>;
> > + };
> > +
> > + pm8953_l5: l5 {
> > + regulator-min-microvolt = <1800000>;
> > + regulator-max-microvolt = <1800000>;
> > + };
> > +
> > + pm8953_l6: l6 {
> > + regulator-min-microvolt = <1800000>;
> > + regulator-max-microvolt = <1800000>;
> > + };
> > +
> > + pm8953_l7: l7 {
> > + regulator-min-microvolt = <1800000>;
> > + regulator-max-microvolt = <1900000>;
> > + };
> > +
> > + pm8953_l8: l8 {
> > + regulator-min-microvolt = <2900000>;
> > + regulator-max-microvolt = <2900000>;
> > + };
> > +
> > + pm8953_l9: l9 {
> > + regulator-min-microvolt = <3000000>;
> > + regulator-max-microvolt = <3300000>;
> > + };
> > +
> > + pm8953_l10: l10 {
> > + regulator-min-microvolt = <2850000>;
> > + regulator-max-microvolt = <2850000>;
> > + };
> > +
> > + pm8953_l11: l11 {
> > + regulator-min-microvolt = <2950000>;
> > + regulator-max-microvolt = <2950000>;
> > + };
> > +
> > + pm8953_l12: l12 {
> > + regulator-min-microvolt = <1800000>;
> > + regulator-max-microvolt = <2950000>;
> > + };
> > +
> > + pm8953_l13: l13 {
> > + regulator-min-microvolt = <3125000>;
> > + regulator-max-microvolt = <3125000>;
> > + };
> > +
> > + pm8953_l16: l16 {
> > + regulator-min-microvolt = <1800000>;
> > + regulator-max-microvolt = <1800000>;
> > + };
> > +
> > + pm8953_l17: l17 {
> > + regulator-min-microvolt = <2850000>;
> > + regulator-max-microvolt = <2850000>;
> > + };
> > +
> > + pm8953_l19: l19 {
> > + regulator-min-microvolt = <1200000>;
> > + regulator-max-microvolt = <1350000>;
> > + };
> > +
> > + pm8953_l22: l22 {
> > + regulator-min-microvolt = <2800000>;
> > + regulator-max-microvolt = <2800000>;
> > + };
> > +
> > + pm8953_l23: l23 {
> > + regulator-min-microvolt = <975000>;
> > + regulator-max-microvolt = <1225000>;
> > + };
> > + };
> > +};
> > +
> > +&sdhc_1 {
> > + vmmc-supply = <&pm8953_l8>;
> > + vqmmc-supply = <&pm8953_l5>;
> > +
> > + status = "okay";
> > +};
> > +
> > +&sdhc_2 {
> > + vmmc-supply = <&pm8953_l11>;
> > + vqmmc-supply = <&pm8953_l12>;
> > +
> > + cd-gpios = <&tlmm 133 GPIO_ACTIVE_HIGH>;
> > +
> > + pinctrl-0 = <&sdc2_clk_on &sdc2_cmd_on &sdc2_data_on &sdc2_cd_on>;
> > + pinctrl-1 = <&sdc2_clk_off &sdc2_cmd_off &sdc2_data_off>;
> > + pinctrl-names = "default", "sleep";
> > +
> > + status = "okay";
> > +};
> > +
> > +&tlmm {
> > + gpio-reserved-ranges = <0 4>, <135 4>;
> 
> 
> Any ideas what's connected to these pins? If you do, good to document
> this like in other devices.
> 
> Regards
> Luca
> 

Unfortunately, downstream devicetree's pinctrl (kernel sources not available) doesn't mention anywhere 'gpio0', 'gpio1', 'gpio2', 'gpio3', 'gpio135', 'gpio136', 'gpio137' and 'gpio138' (but, for example, 'gpio4' and 'gpio139' are shown, instead). So, I've no ideas what these reserved gpios are used for.

Re: [PATCH 3/3] arm64: dts: qcom: msm8953: Add device tree for Billion Capture+

[Luca Weiss]

On 21-06-2025 9:07 a.m., cristian_ci wrote:
> On Saturday, June 21st, 2025 at 00:20, Luca Weiss <luca@lucaweiss.eu> wrote:
> 
>>> +
>>> + reserved-memory {
>>> + qseecom@0 {
>>
>>
>> qseecom@84a00000 ?
>>
>>> + reg = <0x00 0x84a00000 0x00 0x1900000>;
>>> + no-map;
>>> + };
> 
> Looking at downstream devicetree, every reserved-memory nodes with "removed-dma-pool" compatible has unit address 0. OTOH, kernel documentation [1] says:
> "  Following the generic-names recommended practice, node names should
>    reflect the purpose of the node (ie. "framebuffer" or "dma-pool").
>    Unit address (@<address>) should be appended to the name if the node
>    is a static allocation."
> 
> In my case, downstream devicetree shows:
> 
> 		other_ext_region@0 {
> 			compatible = "removed-dma-pool";
> 			no-map;
> 			reg = <0x00 0x84a00000 0x00 0x1e00000>;
> 		};
> 
> which will be 'qseecom' reserved-memory node in mainline devicetree.
> 
> OTOH, 'qseecom' node in downstream devicetree also shows:
> 
> 		qseecom@84a00000 {
> 			compatible = "qcom,qseecom";
> 			reg = <0x84a00000 0x1900000>;
>                          ...
> 
> If you confirm what you suggest, 'qseecom' reserved-memory node will look like the following:
> 
> 		qseecom_mem: qseecom@84a00000 {
> 			reg = <0x0 0x84a00000 0x0 0x1900000>;
> 			no-map;
> 		};
> 
> [1] https://www.kernel.org/doc/Documentation/devicetree/bindings/reserved-memory/reserved-memory.yaml

The name (qseecom@84a00000) mostly does not matter at runtime, it's just 
a nice label we give it. The reg is the important bit that gets used in 
reserved-memory.

But actually re-checking, I don't think your reserved-memory works right 
now, msm8953.dtsi has

	soc: soc@0 {
		#address-cells = <1>;
		#size-cells = <1>;

which means that you should only have one value for address, and one for 
size, so "reg = <0x84a00000 0x1900000>;". This is different to most 
other Qualcomm arm64 SoCs.

Same for cont-splash below.

> 
>>> + cont_splash_mem: cont-splash@90001000 {
>>> + reg = <0x0 0x90001000 0x0 (1080 * 1920 * 3)>;
>>> + no-map;
>>> + };
>>> + };
>>> +>>
>> Any ideas what's connected to these pins? If you do, good to document
>> this like in other devices.
>>
>> Regards
>> Luca
>>
> 
> Unfortunately, downstream devicetree's pinctrl (kernel sources not available) doesn't mention anywhere 'gpio0', 'gpio1', 'gpio2', 'gpio3', 'gpio135', 'gpio136', 'gpio137' and 'gpio138' (but, for example, 'gpio4' and 'gpio139' are shown, instead). So, I've no ideas what these reserved gpios are used for.
That's fine from my side then.

Regards
Luca

Re: [PATCH 3/3] arm64: dts: qcom: msm8953: Add device tree for Billion Capture+

[Konrad Dybcio]

On 6/21/25 11:27 AM, Luca Weiss wrote:
> On 21-06-2025 9:07 a.m., cristian_ci wrote:
>> On Saturday, June 21st, 2025 at 00:20, Luca Weiss <luca@lucaweiss.eu> wrote:
>>
>>>> +
>>>> + reserved-memory {
>>>> + qseecom@0 {
>>>
>>>
>>> qseecom@84a00000 ?
>>>
>>>> + reg = <0x00 0x84a00000 0x00 0x1900000>;
>>>> + no-map;
>>>> + };
>>
>> Looking at downstream devicetree, every reserved-memory nodes with "removed-dma-pool" compatible has unit address 0. OTOH, kernel documentation [1] says:
>> "  Following the generic-names recommended practice, node names should
>>    reflect the purpose of the node (ie. "framebuffer" or "dma-pool").
>>    Unit address (@<address>) should be appended to the name if the node
>>    is a static allocation."
>>
>> In my case, downstream devicetree shows:
>>
>>         other_ext_region@0 {
>>             compatible = "removed-dma-pool";
>>             no-map;
>>             reg = <0x00 0x84a00000 0x00 0x1e00000>;
>>         };
>>
>> which will be 'qseecom' reserved-memory node in mainline devicetree.
>>
>> OTOH, 'qseecom' node in downstream devicetree also shows:
>>
>>         qseecom@84a00000 {
>>             compatible = "qcom,qseecom";
>>             reg = <0x84a00000 0x1900000>;
>>                          ...
>>
>> If you confirm what you suggest, 'qseecom' reserved-memory node will look like the following:
>>
>>         qseecom_mem: qseecom@84a00000 {
>>             reg = <0x0 0x84a00000 0x0 0x1900000>;
>>             no-map;
>>         };
>>
>> [1] https://www.kernel.org/doc/Documentation/devicetree/bindings/reserved-memory/reserved-memory.yaml
> 
> The name (qseecom@84a00000) mostly does not matter at runtime, it's just a nice label we give it. The reg is the important bit that gets used in reserved-memory.
> 
> But actually re-checking, I don't think your reserved-memory works right now, msm8953.dtsi has
> 
>     soc: soc@0 {
>         #address-cells = <1>;
>         #size-cells = <1>;
> 
> which means that you should only have one value for address, and one for size, so "reg = <0x84a00000 0x1900000>;". This is different to most other Qualcomm arm64 SoCs.

reserved-memory {
                #address-cells = <2>;
                #size-cells = <2>;
                ranges;


Konrad

Re: [PATCH 3/3] arm64: dts: qcom: msm8953: Add device tree for Billion Capture+

[Konrad Dybcio]

On 6/20/25 11:51 PM, Cristian Cozzolino via B4 Relay wrote:
> From: Cristian Cozzolino <cristian_ci@protonmail.com>
> 
> Billion Capture+ (flipkart,rimob) is a smartphone released in 2017, based
> on Snapdragon 625 (MSM8953) SoC.
> 
> Add a device tree with initial support for:
> 
> - GPIO keys
> - SDHCI (internal and external storage)
> - USB Device Mode
> - Regulators
> - Simple framebuffer
> 
> Signed-off-by: Cristian Cozzolino <cristian_ci@protonmail.com>
> ---

[...]

> +
> +	gpio-keys {
> +		compatible = "gpio-keys";
> +
> +		pinctrl-names = "default";
> +		pinctrl-0 = <&gpio_key_default>;

property-n
property-names

please

[...]

> +	reserved-memory {
> +		qseecom@0 {
> +			reg = <0x00 0x84a00000 0x00 0x1900000>;

'0x0'

[...]

> +
> +&sdhc_1 {
> +	vmmc-supply = <&pm8953_l8>;
> +	vqmmc-supply = <&pm8953_l5>;

you should add regulator-allow-set-load to these vregs

[...]

> +&tlmm {
> +	gpio-reserved-ranges = <0 4>,

These GPIOs correspond to I2C/SPI_1

<135 4>;

And these correspond to I2C/SPI_7

Without much more knowledge, I would guesstimate one of them is
for a fingerprint reader and the other for NFC eSE

Konrad

Re: [PATCH 3/3] arm64: dts: qcom: msm8953: Add device tree for Billion Capture+

[Luca Weiss]

Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> schreef op 21 juni 2025 12:11:00 CEST:
>On 6/21/25 11:27 AM, Luca Weiss wrote:
>> On 21-06-2025 9:07 a.m., cristian_ci wrote:
>>> On Saturday, June 21st, 2025 at 00:20, Luca Weiss <luca@lucaweiss.eu> wrote:
>>>
>>>>> +
>>>>> + reserved-memory {
>>>>> + qseecom@0 {
>>>>
>>>>
>>>> qseecom@84a00000 ?
>>>>
>>>>> + reg = <0x00 0x84a00000 0x00 0x1900000>;
>>>>> + no-map;
>>>>> + };
>>>
>>> Looking at downstream devicetree, every reserved-memory nodes with "removed-dma-pool" compatible has unit address 0. OTOH, kernel documentation [1] says:
>>> "  Following the generic-names recommended practice, node names should
>>>    reflect the purpose of the node (ie. "framebuffer" or "dma-pool").
>>>    Unit address (@<address>) should be appended to the name if the node
>>>    is a static allocation."
>>>
>>> In my case, downstream devicetree shows:
>>>
>>>         other_ext_region@0 {
>>>             compatible = "removed-dma-pool";
>>>             no-map;
>>>             reg = <0x00 0x84a00000 0x00 0x1e00000>;
>>>         };
>>>
>>> which will be 'qseecom' reserved-memory node in mainline devicetree.
>>>
>>> OTOH, 'qseecom' node in downstream devicetree also shows:
>>>
>>>         qseecom@84a00000 {
>>>             compatible = "qcom,qseecom";
>>>             reg = <0x84a00000 0x1900000>;
>>>                          ...
>>>
>>> If you confirm what you suggest, 'qseecom' reserved-memory node will look like the following:
>>>
>>>         qseecom_mem: qseecom@84a00000 {
>>>             reg = <0x0 0x84a00000 0x0 0x1900000>;
>>>             no-map;
>>>         };
>>>
>>> [1] https://www.kernel.org/doc/Documentation/devicetree/bindings/reserved-memory/reserved-memory.yaml
>> 
>> The name (qseecom@84a00000) mostly does not matter at runtime, it's just a nice label we give it. The reg is the important bit that gets used in reserved-memory.
>> 
>> But actually re-checking, I don't think your reserved-memory works right now, msm8953.dtsi has
>> 
>>     soc: soc@0 {
>>         #address-cells = <1>;
>>         #size-cells = <1>;
>> 
>> which means that you should only have one value for address, and one for size, so "reg = <0x84a00000 0x1900000>;". This is different to most other Qualcomm arm64 SoCs.
>
>reserved-memory {
>                #address-cells = <2>;
>                #size-cells = <2>;
>                ranges;

Huh, why this mix'n'match in this SoC... Fun

Then Cristian, disregard my email please :)

>
>
>Konrad

Re: [PATCH 3/3] arm64: dts: qcom: msm8953: Add device tree for Billion Capture+

[Konrad Dybcio]

On 6/21/25 12:53 PM, Luca Weiss wrote:
> 
> 
> Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> schreef op 21 juni 2025 12:11:00 CEST:
>> On 6/21/25 11:27 AM, Luca Weiss wrote:
>>> On 21-06-2025 9:07 a.m., cristian_ci wrote:
>>>> On Saturday, June 21st, 2025 at 00:20, Luca Weiss <luca@lucaweiss.eu> wrote:

[...]

>>> which means that you should only have one value for address, and one for size, so "reg = <0x84a00000 0x1900000>;". This is different to most other Qualcomm arm64 SoCs.
>>
>> reserved-memory {
>>                #address-cells = <2>;
>>                #size-cells = <2>;
>>                ranges;
> 
> Huh, why this mix'n'match in this SoC... Fun

I *think* some of these older SoCs should be able to address more than
32 bits of memory, so it makes sense in that way

Konrad

Re: [PATCH 3/3] arm64: dts: qcom: msm8953: Add device tree for Billion Capture+

[cristian_ci]

On Saturday, June 21st, 2025 at 12:17, Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> wrote:
> > +
> > +&sdhc_1 {
> > + vmmc-supply = <&pm8953_l8>;
> > + vqmmc-supply = <&pm8953_l5>;
> 
> 
> you should add regulator-allow-set-load to these vregs

So, do you mean I should add 'regulator-allow-set-load' property to 'pm8953_l5' and 'pm8953_l8' regulators? If so, should I do that for 'pm8953_l11' and 'pm8953_l12' regulators too (sdhc_2)?

> [...]
> 
> > +&tlmm {
> > + gpio-reserved-ranges = <0 4>,
> 
> 
> These GPIOs correspond to I2C/SPI_1
> 
> <135 4>;
> 
> 
> And these correspond to I2C/SPI_7
> 
> Without much more knowledge, I would guesstimate one of them is
> for a fingerprint reader and the other for NFC eSE
> 
> Konrad

I made that check in past and, while it looks like 'gpio16' and 'gpio17' are assigned to nfc pinctrl (though, nfc appears not to be implemented in this device, considering also the lack of 'phandle' for such pinctrls) in downstream dts, the devicetree pinctrl still doesn't mentions the gpios associated with the fingerprint node (which is, instead, implemented in this device). So, I'm not able to verify if gpios 0-3 and gpios 135-138 are related to fingerprint and secure element, respectively.

Re: [PATCH 0/3] Add initial device tree for Billion Capture+

[Rob Herring (Arm)]

On Fri, 20 Jun 2025 23:51:38 +0200, Cristian Cozzolino wrote:
> Billion Capture+ is a handset using the MSM8953 SoC released in 2017
> and sold by Flipkart.
> 
> Add a device tree with initial support for:
> 
> - GPIO keys
> - SDHCI (internal and external storage)
> - USB Device Mode
> - Regulators
> - Simple framebuffer
> 
> Signed-off-by: Cristian Cozzolino <cristian_ci@protonmail.com>
> ---
> Cristian Cozzolino (3):
>       dt-bindings: vendor-prefixes: Add Flipkart
>       dt-bindings: arm: qcom: Add Billion Capture+
>       arm64: dts: qcom: msm8953: Add device tree for Billion Capture+
> 
>  Documentation/devicetree/bindings/arm/qcom.yaml    |   1 +
>  .../devicetree/bindings/vendor-prefixes.yaml       |   2 +
>  arch/arm64/boot/dts/qcom/Makefile                  |   1 +
>  .../arm64/boot/dts/qcom/msm8953-flipkart-rimob.dts | 251 +++++++++++++++++++++
>  4 files changed, 255 insertions(+)
> ---
> base-commit: 0ff41df1cb268fc69e703a08a57ee14ae967d0ca
> change-id: 20250620-rimob-initial-devicetree-da86a5bffc8b
> 
> Best regards,
> --
> Cristian Cozzolino <cristian_ci@protonmail.com>
> 
> 
> 


My bot found new DTB warnings on the .dts files added or changed in this
series.

Some warnings may be from an existing SoC .dtsi. Or perhaps the warnings
are fixed by another series. Ultimately, it is up to the platform
maintainer whether these warnings are acceptable or not. No need to reply
unless the platform maintainer has comments.

If you already ran DT checks and didn't see these error(s), then
make sure dt-schema is up to date:

  pip3 install dtschema --upgrade


This patch series was applied (using b4) to base:
 Base: using specified base-commit 0ff41df1cb268fc69e703a08a57ee14ae967d0ca

If this is not the correct base, please add 'base-commit' tag
(or use b4 which does this automatically)

New warnings running 'make CHECK_DTBS=y for arch/arm64/boot/dts/qcom/' for 20250620-rimob-initial-devicetree-v1-0-8e667ea21f82@protonmail.com:

arch/arm64/boot/dts/qcom/msm8953-flipkart-rimob.dtb: gpu@1c00000 (qcom,adreno-506.0): clock-names:5: 'alwayson' is not one of ['core', 'iface', 'mem', 'mem_iface', 'alt_mem_iface', 'gfx3d', 'rbbmtimer', 'rbcpr']
	from schema $id: http://devicetree.org/schemas/display/msm/gpu.yaml#

Re: [PATCH 3/3] arm64: dts: qcom: msm8953: Add device tree for Billion Capture+

[Konrad Dybcio]

On 6/21/25 9:31 PM, cristian_ci wrote:
> On Saturday, June 21st, 2025 at 12:17, Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> wrote:
>>> +
>>> +&sdhc_1 {
>>> + vmmc-supply = <&pm8953_l8>;
>>> + vqmmc-supply = <&pm8953_l5>;
>>
>>
>> you should add regulator-allow-set-load to these vregs
> 
> So, do you mean I should add 'regulator-allow-set-load' property to 'pm8953_l5' and 'pm8953_l8' regulators? If so, should I do that for 'pm8953_l11' and 'pm8953_l12' regulators too (sdhc_2)?

Yes

>>> +&tlmm {
>>> + gpio-reserved-ranges = <0 4>,
>>
>>
>> These GPIOs correspond to I2C/SPI_1
>>
>> <135 4>;
>>
>>
>> And these correspond to I2C/SPI_7
>>
>> Without much more knowledge, I would guesstimate one of them is
>> for a fingerprint reader and the other for NFC eSE
>>
>> Konrad
> 
> I made that check in past and, while it looks like 'gpio16' and 'gpio17' are assigned to nfc pinctrl (though, nfc appears not to be implemented in this device, considering also the lack of 'phandle' for such pinctrls) in downstream dts, the devicetree pinctrl still doesn't mentions the gpios associated with the fingerprint node (which is, instead, implemented in this device). So, I'm not able to verify if gpios 0-3 and gpios 135-138 are related to fingerprint and secure element, respectively.

If we can't tell, then we can't tell, it's ok

Konrad

Re: [PATCH 3/3] arm64: dts: qcom: msm8953: Add device tree for Billion Capture+

[cristian_ci]

On Monday, June 23rd, 2025 at 12:11, Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> wrote:

> On 6/21/25 9:31 PM, cristian_ci wrote:
> 
> > On Saturday, June 21st, 2025 at 12:17, Konrad Dybcio konrad.dybcio@oss.qualcomm.com wrote:
> > 
> > > > +
> > > > +&sdhc_1 {
> > > > + vmmc-supply = <&pm8953_l8>;
> > > > + vqmmc-supply = <&pm8953_l5>;
> > > 
> > > you should add regulator-allow-set-load to these vregs
> > 
> > So, do you mean I should add 'regulator-allow-set-load' property to 'pm8953_l5' and 'pm8953_l8' regulators? If so, should I do that for 'pm8953_l11' and 'pm8953_l12' regulators too (sdhc_2)?
> 
> 
> Yes
> 

ACK, I'll do that in v2. BTW, since I've not such references in my downstream devicetree, IIUC what you mean, 'regulator-allow-set-load' property is now required in mainline for regulators supplying sdhc_{1|2}.

Also considering I've transferred every value _as_is_ (except for max and min microvolt values ​​of one regulator - after the kernel log complained ​about ​that) for regulators/rpm_requests from downstream
devicetree to mainline devicetree, since other msm8953 devicetrees seem to share the same situation of 'rimob' (I'm referring to
'potter', 'daisy', 'mido', 'tissot' and 'vince'), I wonder if it's not the case to standardize all these devicetrees in the same way. Any thoughts?

Re: [PATCH 3/3] arm64: dts: qcom: msm8953: Add device tree for Billion Capture+

[Konrad Dybcio]

On 6/23/25 4:49 PM, cristian_ci wrote:
> On Monday, June 23rd, 2025 at 12:11, Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> wrote:
> 
>> On 6/21/25 9:31 PM, cristian_ci wrote:
>>
>>> On Saturday, June 21st, 2025 at 12:17, Konrad Dybcio konrad.dybcio@oss.qualcomm.com wrote:
>>>
>>>>> +
>>>>> +&sdhc_1 {
>>>>> + vmmc-supply = <&pm8953_l8>;
>>>>> + vqmmc-supply = <&pm8953_l5>;
>>>>
>>>> you should add regulator-allow-set-load to these vregs
>>>
>>> So, do you mean I should add 'regulator-allow-set-load' property to 'pm8953_l5' and 'pm8953_l8' regulators? If so, should I do that for 'pm8953_l11' and 'pm8953_l12' regulators too (sdhc_2)?
>>
>>
>> Yes
>>
> 
> ACK, I'll do that in v2. BTW, since I've not such references in my downstream devicetree, IIUC what you mean, 'regulator-allow-set-load' property is now required in mainline for regulators supplying sdhc_{1|2}.

The sdhci driver calls regulator_set_load(), which requires that property

> Also considering I've transferred every value _as_is_ (except for max and min microvolt values ​​of one regulator - after the kernel log complained ​about ​that) for regulators/rpm_requests from downstream
> devicetree to mainline devicetree, since other msm8953 devicetrees seem to share the same situation of 'rimob' (I'm referring to
> 'potter', 'daisy', 'mido', 'tissot' and 'vince'), I wonder if it's not the case to standardize all these devicetrees in the same way. Any thoughts?

We've been there before, it's all good until one device stands out, and
then another, and then another..

Konrad