Re: [PATCH 3/3] arm64: dts: qcom: msm8953: Add device tree for Billion Capture+
On 6/23/25 4:49 PM, cristian_ci wrote: > On Monday, June 23rd, 2025 at 12:11, Konrad Dybcio > wrote: > >> On 6/21/25 9:31 PM, cristian_ci wrote: >> >>> On Saturday, June 21st, 2025 at 12:17, Konrad Dybcio >>> [email protected] 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
Re: [PATCH 3/3] arm64: dts: qcom: msm8953: Add device tree for Billion Capture+
On Monday, June 23rd, 2025 at 12:11, Konrad Dybcio wrote: > On 6/21/25 9:31 PM, cristian_ci wrote: > > > On Saturday, June 21st, 2025 at 12:17, Konrad Dybcio > > [email protected] 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+
On 6/21/25 9:31 PM, cristian_ci wrote:
> On Saturday, June 21st, 2025 at 12:17, Konrad Dybcio
> 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+
On Saturday, June 21st, 2025 at 12:17, Konrad Dybcio
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 3/3] arm64: dts: qcom: msm8953: Add device tree for Billion Capture+
On 6/21/25 12:53 PM, Luca Weiss wrote:
>
>
> Konrad Dybcio 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
wrote:
[...]
>>> which means that you should only have one value for address, and one for
>>> size, so "reg = <0x84a0 0x190>;". 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+
Konrad Dybcio 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 wrote:
>>>
> +
> + reserved-memory {
> + qseecom@0 {
qseecom@84a0 ?
> + reg = <0x00 0x84a0 0x00 0x190>;
> + 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 (@) 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 0x84a0 0x00 0x1e0>;
>>> };
>>>
>>> which will be 'qseecom' reserved-memory node in mainline devicetree.
>>>
>>> OTOH, 'qseecom' node in downstream devicetree also shows:
>>>
>>> qseecom@84a0 {
>>> compatible = "qcom,qseecom";
>>> reg = <0x84a0 0x190>;
>>> ...
>>>
>>> If you confirm what you suggest, 'qseecom' reserved-memory node will look
>>> like the following:
>>>
>>> qseecom_mem: qseecom@84a0 {
>>> reg = <0x0 0x84a0 0x0 0x190>;
>>> no-map;
>>> };
>>>
>>> [1]
>>> https://www.kernel.org/doc/Documentation/devicetree/bindings/reserved-memory/reserved-memory.yaml
>>
>> The name (qseecom@84a0) 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 = <0x84a0 0x190>;". 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+
On Saturday, June 21st, 2025 at 00:20, Luca Weiss wrote:
> > +
> > + reserved-memory {
> > + qseecom@0 {
>
>
> qseecom@84a0 ?
>
> > + reg = <0x00 0x84a0 0x00 0x190>;
> > + 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 (@) 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 0x84a0 0x00 0x1e0>;
};
which will be 'qseecom' reserved-memory node in mainline devicetree.
OTOH, 'qseecom' node in downstream devicetree also shows:
qseecom@84a0 {
compatible = "qcom,qseecom";
reg = <0x84a0 0x190>;
...
If you confirm what you suggest, 'qseecom' reserved-memory node will look like
the following:
qseecom_mem: qseecom@84a0 {
reg = <0x0 0x84a0 0x0 0x190>;
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 = ;
> > + 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 = <87>;
> > + regulator-max-microvolt = <1156000>;
> > + };
> > +
> > + pm8953_s3: s3 {
> > + regulator-min-microvolt = <1224000>;
> > + regulator-max-microvolt = <1224000>;
> > + };
> > +
> > + pm8953_s4: s4 {
> > + regulator-min-microvolt = <190>;
> > + regulator-max-microvolt = <205>;
> > + };
> > +
> > + pm8953_l1: l1 {
> > + regulator-min-microvolt = <100>;
> > + regulator-max-microvolt = <100>;
> > + };
> > +
> > + 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 = <180>;
> > + regulator-max-microvolt = <180>;
> > + };
> > +
> > + pm8953_l6: l6 {
> > + regulator-min-microvolt = <180>;
> > + regulator-max-microvolt = <180>;
> > + };
> > +
> > + pm8953_l7: l7 {
> > + regulator-min-microvolt = <180>;
> > + regulator-max-microvolt = <190>;
> > + };
> > +
> > + pm8953_l8: l8 {
> > + regulator-min-microvolt = <290>;
> > + regulator-max-microvolt = <290>;
> > + };
> > +
> > + pm8953_l9: l9 {
> > + regulator-min-microvolt = <300>;
> > + regulator-max-microvolt = <330>;
> > + };
> > +
> > + pm8953_l10: l10 {
> > + regulator-min-microvolt = <285>;
> > + regulator-max-microvolt = <285>;
> > + };
> > +
> > + pm8953_l11: l11 {
> > + regulator-min-microvolt = <295>;
> > + regulator-max-microvolt = <295>;
> > + };
> > +
> > + pm8953_l12: l12 {
> > + regulator-min-microvolt = <180>;
> > + regulator-max-microvolt = <295>;
> > + };
> > +
> > + pm8953_l13: l13 {
> > + regulator-min-microvolt = <3125000>;
> > + regulator-max-microvolt = <3125000>;
> > + };
> > +
> > + pm8953_l16: l16 {
> > + regulator-min-microvolt = <180>;
> > + regulator-max-microvolt = <180>;
> > + };
> > +
> > + pm8953_l17: l17 {
> > + regulator-min-microvolt = <285>;
> > + regulator-max-microvolt = <285>;
> > + };
> > +
> > + pm8953_l19: l19 {
> > + regulator-min-microvolt = <120>;
> > + regulator-max-microvolt = <135>;
> > + };
> > +
> > + pm8953_l22: l22 {
> > + regulator-min-microvolt = <280>;
> > + regulator-max-
Re: [PATCH 3/3] arm64: dts: qcom: msm8953: Add device tree for Billion Capture+
On 6/20/25 11:51 PM, Cristian Cozzolino via B4 Relay wrote:
> From: Cristian Cozzolino
>
> 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
> ---
[...]
> +
> + gpio-keys {
> + compatible = "gpio-keys";
> +
> + pinctrl-names = "default";
> + pinctrl-0 = <&gpio_key_default>;
property-n
property-names
please
[...]
> + reserved-memory {
> + qseecom@0 {
> + reg = <0x00 0x84a0 0x00 0x190>;
'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+
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 wrote:
>>
+
+ reserved-memory {
+ qseecom@0 {
>>>
>>>
>>> qseecom@84a0 ?
>>>
+ reg = <0x00 0x84a0 0x00 0x190>;
+ 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 (@) 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 0x84a0 0x00 0x1e0>;
>> };
>>
>> which will be 'qseecom' reserved-memory node in mainline devicetree.
>>
>> OTOH, 'qseecom' node in downstream devicetree also shows:
>>
>> qseecom@84a0 {
>> compatible = "qcom,qseecom";
>> reg = <0x84a0 0x190>;
>> ...
>>
>> If you confirm what you suggest, 'qseecom' reserved-memory node will look
>> like the following:
>>
>> qseecom_mem: qseecom@84a0 {
>> reg = <0x0 0x84a0 0x0 0x190>;
>> no-map;
>> };
>>
>> [1]
>> https://www.kernel.org/doc/Documentation/devicetree/bindings/reserved-memory/reserved-memory.yaml
>
> The name (qseecom@84a0) 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 = <0x84a0 0x190>;". 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+
On 21-06-2025 9:07 a.m., cristian_ci wrote:
On Saturday, June 21st, 2025 at 00:20, Luca Weiss wrote:
+
+ reserved-memory {
+ qseecom@0 {
qseecom@84a0 ?
+ reg = <0x00 0x84a0 0x00 0x190>;
+ 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 (@) 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 0x84a0 0x00 0x1e0>;
};
which will be 'qseecom' reserved-memory node in mainline devicetree.
OTOH, 'qseecom' node in downstream devicetree also shows:
qseecom@84a0 {
compatible = "qcom,qseecom";
reg = <0x84a0 0x190>;
...
If you confirm what you suggest, 'qseecom' reserved-memory node will look like
the following:
qseecom_mem: qseecom@84a0 {
reg = <0x0 0x84a0 0x0 0x190>;
no-map;
};
[1]
https://www.kernel.org/doc/Documentation/devicetree/bindings/reserved-memory/reserved-memory.yaml
The name (qseecom@84a0) 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 = <0x84a0 0x190>;". 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+
Hi Cristian,
On 20-06-2025 11:51 p.m., Cristian Cozzolino via B4 Relay wrote:
From: Cristian Cozzolino
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
---
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
..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 = ;
+ debounce-interval = <15>;
+ };
+ };
+
+ reserved-memory {
+ qseecom@0 {
qseecom@84a0 ?
+ reg = <0x00 0x84a0 0x00 0x190>;
+ 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 = ;
+ 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-
