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.0On 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
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.
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
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?
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
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";
> +};
>
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.
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
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
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
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
© 2016 - 2025 Red Hat, Inc.