diff mbox series

[v7,1/6] DONOTMERGE: arm64: dts: ti: Add TI TPS65219 PMIC support for AM642 SK board.

Message ID 20221104152311.1098603-2-jneanne@baylibre.com (mailing list archive)
State New, archived
Headers show
Series Add support for TI TPS65219 PMIC. | expand

Commit Message

jerome Neanne Nov. 4, 2022, 3:23 p.m. UTC
From: Jerome NEANNE <jneanne@baylibre.com>

Add support fot the TI Power Management IC TPS65219
on the AM642 SKEVM board.

Needed for driver testing but official board support pending.
TI commitment is required before board upstream kick-off.

Signed-off-by: Jerome NEANNE <jneanne@baylibre.com>
Signed-off-by: Markus Schneider-Pargmann <msp@baylibre.com>
---
 arch/arm64/boot/dts/ti/k3-am642-sk.dts | 104 +++++++++++++++++++++++++
 1 file changed, 104 insertions(+)

Comments

Wadim Egorov Dec. 15, 2022, 3:09 p.m. UTC | #1
Hi Jerome,

is this setup working for you on the AM642 SK board?

I am testing your PMIC patches on a AM62 based board with a similar setup and
running into the following error

    VDDSHV5_SDIO: bypassed regulator has no supply!
    VDDSHV5_SDIO: will resolve supply early: ldo1
    VDDSHV5_SDIO: supplied by regulator-dummy
    VDDSHV5_SDIO: failed to get the current voltage: -EINVAL

Have you noticed problems with LDO1 and bypass mode?

Regards,
Wadim

Am 04.11.22 um 16:23 schrieb Jerome Neanne:
> From: Jerome NEANNE <jneanne@baylibre.com>
>
> Add support fot the TI Power Management IC TPS65219
> on the AM642 SKEVM board.
>
> Needed for driver testing but official board support pending.
> TI commitment is required before board upstream kick-off.
>
> Signed-off-by: Jerome NEANNE <jneanne@baylibre.com>
> Signed-off-by: Markus Schneider-Pargmann <msp@baylibre.com>
> ---
>   arch/arm64/boot/dts/ti/k3-am642-sk.dts | 104 +++++++++++++++++++++++++
>   1 file changed, 104 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/ti/k3-am642-sk.dts b/arch/arm64/boot/dts/ti/k3-am642-sk.dts
> index 738d0cf6c40a..d0121976491a 100644
> --- a/arch/arm64/boot/dts/ti/k3-am642-sk.dts
> +++ b/arch/arm64/boot/dts/ti/k3-am642-sk.dts
> @@ -219,6 +219,20 @@ led-7 {
>   			gpios = <&exp2 7 GPIO_ACTIVE_HIGH>;
>   		};
>   	};
> +
> +	vsel_sd_nddr: gpio-regulator {
> +		compatible = "regulator-gpio";
> +		pinctrl-names = "default";
> +		pinctrl-0 = <&vsel_sd_nddr_pins_default>;
> +		regulator-name = "tps65219-LDO1-SEL-SD";
> +		regulator-min-microvolt = <1800000>;
> +		regulator-max-microvolt = <3300000>;
> +		regulator-boot-on;
> +		vin-supply = <&ldo1_reg>;
> +		gpios = <&main_gpio0 45 GPIO_ACTIVE_HIGH>;
> +		states = <1800000 0x0>,
> +			 <3300000 0x1>;
> +	};
>   };
>   
>   &main_pmx0 {
> @@ -250,6 +264,13 @@ AM64X_IOPAD(0x02a8, PIN_OUTPUT, 0) /* (E19) USB0_DRVVBUS */
>   		>;
>   	};
>   
> +	main_i2c0_pins_default: main-i2c0-pins-default {
> +		pinctrl-single,pins = <
> +			AM64X_IOPAD(0x0260, PIN_INPUT_PULLUP, 0) /* (A18) I2C0_SCL */
> +			AM64X_IOPAD(0x0264, PIN_INPUT_PULLUP, 0) /* (B18) I2C0_SDA */
> +		>;
> +	};
> +
>   	main_i2c1_pins_default: main-i2c1-pins-default {
>   		pinctrl-single,pins = <
>   			AM64X_IOPAD(0x0268, PIN_INPUT_PULLUP, 0) /* (C18) I2C1_SCL */
> @@ -336,6 +357,12 @@ main_wlan_pins_default: main-wlan-pins-default {
>   			AM64X_IOPAD(0x00bc, PIN_INPUT, 7) /* (U8) GPIO0_46 */
>   		>;
>   	};
> +
> +	vsel_sd_nddr_pins_default: vsel-sd-nddr-pins-default {
> +		pinctrl-single,pins = <
> +			AM64X_IOPAD(0x00b8, PIN_INPUT, 7) /* (Y7) PRG1_PRU0_GPO0.GPIO0_45 */
> +		>;
> +	};
>   };
>   
>   &mcu_uart0 {
> @@ -384,6 +411,83 @@ &mcu_i2c1 {
>   	status = "disabled";
>   };
>   
> +&main_i2c0 {
> +	pinctrl-names = "default";
> +	pinctrl-0 = <&main_i2c0_pins_default>;
> +	clock-frequency = <400000>;
> +	status = "okay";
> +
> +	tps65219: pmic@30 {
> +		compatible = "ti,tps65219";
> +		reg = <0x30>;
> +		system-power-controller;
> +
> +		buck1-supply = <&vcc_3v3_sys>;
> +		buck2-supply = <&vcc_3v3_sys>;
> +		buck3-supply = <&vcc_3v3_sys>;
> +		ldo1-supply = <&vcc_3v3_sys>;
> +		ldo2-supply = <&buck2_reg>;
> +		ldo3-supply = <&vcc_3v3_sys>;
> +		ldo4-supply = <&vcc_3v3_sys>;
> +
> +		regulators {
> +			buck1_reg: buck1 {
> +				regulator-name = "VDD_CORE";
> +				regulator-min-microvolt = <750000>;
> +				regulator-max-microvolt = <1000000>;
> +				regulator-boot-on;
> +				regulator-always-on;
> +			};
> +
> +			buck2_reg: buck2 {
> +				regulator-name = "VCC1V8";
> +				regulator-min-microvolt = <1800000>;
> +				regulator-max-microvolt = <1800000>;
> +				regulator-boot-on;
> +				regulator-always-on;
> +			};
> +
> +			buck3_reg: buck3 {
> +				regulator-name = "VDD_LPDDR4";
> +				regulator-min-microvolt = <1100000>;
> +				regulator-max-microvolt = <1100000>;
> +				regulator-boot-on;
> +				regulator-always-on;
> +			};
> +
> +			ldo1_reg: ldo1 {
> +				regulator-name = "VDDSHV_SD_IO_PMIC";
> +				regulator-min-microvolt = <1000000>;
> +				regulator-max-microvolt = <3300000>;
> +				regulator-allow-bypass;
> +			};
> +
> +			ldo2_reg: ldo2 {
> +				regulator-name = "VDDAR_CORE";
> +				regulator-min-microvolt = <850000>;
> +				regulator-max-microvolt = <850000>;
> +				regulator-boot-on;
> +				regulator-always-on;
> +			};
> +
> +			ldo3_reg: ldo3 {
> +				regulator-name = "VDDA_1V8";
> +				regulator-min-microvolt = <1800000>;
> +				regulator-max-microvolt = <1800000>;
> +				regulator-boot-on;
> +				regulator-always-on;
> +			};
> +
> +			ldo4_reg: ldo4 {
> +				regulator-name = "VDD_PHY_2V5";
> +				regulator-min-microvolt = <2500000>;
> +				regulator-max-microvolt = <2500000>;
> +				regulator-boot-on;
> +				regulator-always-on;
> +			};
> +		};
> +	};
> +};
>   &main_i2c1 {
>   	pinctrl-names = "default";
>   	pinctrl-0 = <&main_i2c1_pins_default>;
jerome Neanne Dec. 15, 2022, 3:51 p.m. UTC | #2
On 15/12/2022 16:09, Wadim Egorov wrote:
> Hi Jerome,
> 
> is this setup working for you on the AM642 SK board?
> 
> I am testing your PMIC patches on a AM62 based board with a similar setup and
> running into the following error
> 
>      VDDSHV5_SDIO: bypassed regulator has no supply!
>      VDDSHV5_SDIO: will resolve supply early: ldo1
>      VDDSHV5_SDIO: supplied by regulator-dummy
>      VDDSHV5_SDIO: failed to get the current voltage: -EINVAL
> 
> Have you noticed problems with LDO1 and bypass mode?

Wadim,

I did not noticed this on am642 board but IIRC this rail was not used. I 
heard about similar issue reported to me by Nishanth M with a fix 
proposal here:
https://gist.github.com/nmenon/e4dd6ef6afe31bc9750fa6cbee8d3e25

I did not have time yet to investigate on this but will do soon.

Regards,
Jerome
Mark Brown Dec. 15, 2022, 4:09 p.m. UTC | #3
On Thu, Dec 15, 2022 at 04:51:40PM +0100, jerome Neanne wrote:
> On 15/12/2022 16:09, Wadim Egorov wrote:

> > I am testing your PMIC patches on a AM62 based board with a similar setup and
> > running into the following error

> >      VDDSHV5_SDIO: bypassed regulator has no supply!
> >      VDDSHV5_SDIO: will resolve supply early: ldo1
> >      VDDSHV5_SDIO: supplied by regulator-dummy
> >      VDDSHV5_SDIO: failed to get the current voltage: -EINVAL

> > Have you noticed problems with LDO1 and bypass mode?

> I did not noticed this on am642 board but IIRC this rail was not used. I
> heard about similar issue reported to me by Nishanth M with a fix proposal
> here:
> https://gist.github.com/nmenon/e4dd6ef6afe31bc9750fa6cbee8d3e25

That proposal looks really non-idiomatic and quite unusual, if there's a
fixed voltage supply to the LDO I'd expect to see it modeled as a fixed
voltage regulator.  I'm not sure what the use of bypass here is trying
to accomplish TBH.
Nishanth Menon Dec. 15, 2022, 5:54 p.m. UTC | #4
On 16:09-20221215, Mark Brown wrote:
> On Thu, Dec 15, 2022 at 04:51:40PM +0100, jerome Neanne wrote:
> > On 15/12/2022 16:09, Wadim Egorov wrote:
> 
> > > I am testing your PMIC patches on a AM62 based board with a similar setup and
> > > running into the following error
> 
> > >      VDDSHV5_SDIO: bypassed regulator has no supply!
> > >      VDDSHV5_SDIO: will resolve supply early: ldo1
> > >      VDDSHV5_SDIO: supplied by regulator-dummy
> > >      VDDSHV5_SDIO: failed to get the current voltage: -EINVAL
> 
> > > Have you noticed problems with LDO1 and bypass mode?
> 
> > I did not noticed this on am642 board but IIRC this rail was not used. I
> > heard about similar issue reported to me by Nishanth M with a fix proposal
> > here:
> > https://gist.github.com/nmenon/e4dd6ef6afe31bc9750fa6cbee8d3e25
> 
> That proposal looks really non-idiomatic and quite unusual, if there's a
> fixed voltage supply to the LDO I'd expect to see it modeled as a fixed
> voltage regulator.  I'm not sure what the use of bypass here is trying
> to accomplish TBH.


Correct - My hack was based on a time crunch hack ;)...

The problem is this - the default NVM in the PMIC is setup such that
VSET value =3.3v and bypass bit set (makes sense since the vin=3.3v).

Now the constraint is bypass bit cannot be changed without the LDO
being switched off.

regulator-allow-bypass property allows us to control bypass bit, but we
should'nt toggle it when LDO is active. Not providing the property
implies the bit wont be toggled by regulator core either.

What we need is a scheme that will disable the bypass bit with the
intent of operating the LDO with just the vset field. I did'nt find it
possible atm.. unless I am mistaken..
Mark Brown Dec. 15, 2022, 6:22 p.m. UTC | #5
On Thu, Dec 15, 2022 at 11:54:11AM -0600, Nishanth Menon wrote:
> On 16:09-20221215, Mark Brown wrote:

> > That proposal looks really non-idiomatic and quite unusual, if there's a
> > fixed voltage supply to the LDO I'd expect to see it modeled as a fixed
> > voltage regulator.  I'm not sure what the use of bypass here is trying
> > to accomplish TBH.

> The problem is this - the default NVM in the PMIC is setup such that
> VSET value =3.3v and bypass bit set (makes sense since the vin=3.3v).

This implies no voltage drop over the LDO?  Sounds a bit suspect.

> Now the constraint is bypass bit cannot be changed without the LDO
> being switched off.

> regulator-allow-bypass property allows us to control bypass bit, but we
> should'nt toggle it when LDO is active. Not providing the property
> implies the bit wont be toggled by regulator core either.

> What we need is a scheme that will disable the bypass bit with the
> intent of operating the LDO with just the vset field. I did'nt find it
> possible atm.. unless I am mistaken..

Can the consumer just disable the supply as part of startup?  Though
that's starting to feel rather board specific.  There's not really a
good place to put a board specific setup process like that in the kernel
at the minute, you'd ideally want the firmware to leave the device at
least disabled if not actually out of bypass on startup so we don't have
to deal with this.  Ugh...
Nishanth Menon Dec. 15, 2022, 9:41 p.m. UTC | #6
On 18:22-20221215, Mark Brown wrote:
> On Thu, Dec 15, 2022 at 11:54:11AM -0600, Nishanth Menon wrote:
> > On 16:09-20221215, Mark Brown wrote:
> 
> > > That proposal looks really non-idiomatic and quite unusual, if there's a
> > > fixed voltage supply to the LDO I'd expect to see it modeled as a fixed
> > > voltage regulator.  I'm not sure what the use of bypass here is trying
> > > to accomplish TBH.
> 
> > The problem is this - the default NVM in the PMIC is setup such that
> > VSET value =3.3v and bypass bit set (makes sense since the vin=3.3v).
> 
> This implies no voltage drop over the LDO?  Sounds a bit suspect.

Not the choice I'd probably have made ;)

> 
> > Now the constraint is bypass bit cannot be changed without the LDO
> > being switched off.
> 
> > regulator-allow-bypass property allows us to control bypass bit, but we
> > should'nt toggle it when LDO is active. Not providing the property
> > implies the bit wont be toggled by regulator core either.
> 
> > What we need is a scheme that will disable the bypass bit with the
> > intent of operating the LDO with just the vset field. I did'nt find it
> > possible atm.. unless I am mistaken..
> 
> Can the consumer just disable the supply as part of startup?  Though
> that's starting to feel rather board specific.  There's not really a

Yeah - this happens to be SDcard supply (at least in my case).. I'd
rather not change the mmc host or core layer to handle a case where
LDO happened to be in bypass. it is a regulator driver's problem, IMHO
how to provide the stated voltage OR fail to transition the voltage.

In this driver's case, it happily accepts and set the VSET voltage - for
example to 1.8V, but then, since the bypass bit is set, well, voltage
sticks around at 3.3v.

> good place to put a board specific setup process like that in the kernel
> at the minute, you'd ideally want the firmware to leave the device at
> least disabled if not actually out of bypass on startup so we don't have
> to deal with this.  Ugh...

Yeah - that would be the other option - I could plug this bypass clear
in the u-boot or someplace early so that the LDO behaves

Also the reason why I did'nt send the mentioned patch (or the like
upstream and the patch was done just a couple of days back) were the following
questions:
a) Why would'nt we handle the case where bypass bit
   is set AND voltage change implies bypass bit needs to be disabled? (i
   would expect it to fail but if i did provide regulator-allow-bypass,
   then if bypass is set AND requested-voltage != vin-supply, then i'd
   have expected framework to probably disable bypass and switch voltage
   to new voltage - which this driver, based on it's constraint will say
   "nope, cant do" - but that would be better than silently telling me
   all good, setting vset and leaving the bypass bit on.)
b) If I wanted the LDO to poweroff the bypass bit at start (define the
   startup hardware condition), I dont seem to have a description for
   that either.
Vignesh Raghavendra Dec. 16, 2022, 6:21 a.m. UTC | #7
On 16/12/22 03:11, Nishanth Menon wrote:
> On 18:22-20221215, Mark Brown wrote:
>> On Thu, Dec 15, 2022 at 11:54:11AM -0600, Nishanth Menon wrote:
>>> On 16:09-20221215, Mark Brown wrote:
>>
>>>> That proposal looks really non-idiomatic and quite unusual, if there's a
>>>> fixed voltage supply to the LDO I'd expect to see it modeled as a fixed
>>>> voltage regulator.  I'm not sure what the use of bypass here is trying
>>>> to accomplish TBH.
>>
>>> The problem is this - the default NVM in the PMIC is setup such that
>>> VSET value =3.3v and bypass bit set (makes sense since the vin=3.3v).
>>
>> This implies no voltage drop over the LDO?  Sounds a bit suspect.
> 
> Not the choice I'd probably have made ;)
> 
>>
>>> Now the constraint is bypass bit cannot be changed without the LDO
>>> being switched off.
>>

Per https://www.ti.com/lit/ds/symlink/tps65219.pdf (7.3.6 Linear
Regulators).

LDOs have two modes:

1. Load switch mode: in this case, output voltages of 1.5V up to 5.5V
are supported.

2 Linear regulator LDO mode where output voltage is programmable in the
range of 0.6V to 3.4V in 50mV-steps with possibility of bypass.

(CAUTION on page 25):
A mode change between LDO(/bypass) and LSW-mode must only be performed,
when this regulator is disabled!
A change between LDO and bypass-mode (supported by LDO1 and LDO2 only)
is supported during operation.

So, seems like bypass can be toggled even with LDO on?



[...]

Regards
Vignesh
jerome Neanne Dec. 16, 2022, 7:28 a.m. UTC | #8
On 16/12/2022 07:21, Vignesh Raghavendra wrote:
> 
> 
> On 16/12/22 03:11, Nishanth Menon wrote:
>> On 18:22-20221215, Mark Brown wrote:
>>> On Thu, Dec 15, 2022 at 11:54:11AM -0600, Nishanth Menon wrote:
>>>> On 16:09-20221215, Mark Brown wrote:
>>>
>>>>> That proposal looks really non-idiomatic and quite unusual, if there's a
>>>>> fixed voltage supply to the LDO I'd expect to see it modeled as a fixed
>>>>> voltage regulator.  I'm not sure what the use of bypass here is trying
>>>>> to accomplish TBH.
>>>
>>>> The problem is this - the default NVM in the PMIC is setup such that
>>>> VSET value =3.3v and bypass bit set (makes sense since the vin=3.3v).
>>>
>>> This implies no voltage drop over the LDO?  Sounds a bit suspect.
>>
>> Not the choice I'd probably have made ;)
>>
>>>
>>>> Now the constraint is bypass bit cannot be changed without the LDO
>>>> being switched off.
>>>
> 
> Per https://www.ti.com/lit/ds/symlink/tps65219.pdf (7.3.6 Linear
> Regulators).
> 
> LDOs have two modes:
> 
> 1. Load switch mode: in this case, output voltages of 1.5V up to 5.5V
> are supported.
> 
> 2 Linear regulator LDO mode where output voltage is programmable in the
> range of 0.6V to 3.4V in 50mV-steps with possibility of bypass.
> 
> (CAUTION on page 25):
> A mode change between LDO(/bypass) and LSW-mode must only be performed,
> when this regulator is disabled!
> A change between LDO and bypass-mode (supported by LDO1 and LDO2 only)
> is supported during operation.
> 
> So, seems like bypass can be toggled even with LDO on?
>I possibly miss-interpreted this caution statement which leads to that 
situation.

Your understanding sounds correct. My mistake... Sorry for that


Regards,
Jerome.
Mark Brown Dec. 16, 2022, 1:41 p.m. UTC | #9
On Thu, Dec 15, 2022 at 03:41:49PM -0600, Nishanth Menon wrote:

> Yeah - this happens to be SDcard supply (at least in my case).. I'd
> rather not change the mmc host or core layer to handle a case where
> LDO happened to be in bypass. it is a regulator driver's problem, IMHO
> how to provide the stated voltage OR fail to transition the voltage.

Well, if the regulator is in bypass mode then it is by definition not
regulating and so it's like programming the voltage while switched off,
setting the target for when it starts regulating again.  It's a weirder
use case but it does feel like the consistent thing to do at least.
The driver shouldn't enter/leave bypass without being explicitly told to
so since there'll be a performance impact.

> b) If I wanted the LDO to poweroff the bypass bit at start (define the
>    startup hardware condition), I dont seem to have a description for
>    that either.

That's something we could add in constraints, though the actual process
of implementing it might get messy if there's restrictions like having
to power off (though from further down the thread I see that might not
apply to this device).
Wadim Egorov Dec. 28, 2022, 10:16 a.m. UTC | #10
Am 16.12.22 um 14:41 schrieb Mark Brown:
> On Thu, Dec 15, 2022 at 03:41:49PM -0600, Nishanth Menon wrote:
>
>> Yeah - this happens to be SDcard supply (at least in my case).. I'd
>> rather not change the mmc host or core layer to handle a case where
>> LDO happened to be in bypass. it is a regulator driver's problem, IMHO
>> how to provide the stated voltage OR fail to transition the voltage.
> Well, if the regulator is in bypass mode then it is by definition not
> regulating and so it's like programming the voltage while switched off,
> setting the target for when it starts regulating again.  It's a weirder
> use case but it does feel like the consistent thing to do at least.
> The driver shouldn't enter/leave bypass without being explicitly told to
> so since there'll be a performance impact.
>
>> b) If I wanted the LDO to poweroff the bypass bit at start (define the
>>     startup hardware condition), I dont seem to have a description for
>>     that either.
> That's something we could add in constraints, though the actual process
> of implementing it might get messy if there's restrictions like having
> to power off (though from further down the thread I see that might not
> apply to this device).

Just for the record:

My reported problem was actually not the LDO1/bypass situation, but an issue in 
the process of resolving the regulator supplies.

It was resolved by
   commit 0debed5b117d ("regulator: core: Fix resolve supply lookup issue")

Now everything seems to work with my setup with LDO1 supplied by a fixed 
regulator and LDO1 acting in bypass mode on our hardware.

Regards,
Wadim
diff mbox series

Patch

diff --git a/arch/arm64/boot/dts/ti/k3-am642-sk.dts b/arch/arm64/boot/dts/ti/k3-am642-sk.dts
index 738d0cf6c40a..d0121976491a 100644
--- a/arch/arm64/boot/dts/ti/k3-am642-sk.dts
+++ b/arch/arm64/boot/dts/ti/k3-am642-sk.dts
@@ -219,6 +219,20 @@  led-7 {
 			gpios = <&exp2 7 GPIO_ACTIVE_HIGH>;
 		};
 	};
+
+	vsel_sd_nddr: gpio-regulator {
+		compatible = "regulator-gpio";
+		pinctrl-names = "default";
+		pinctrl-0 = <&vsel_sd_nddr_pins_default>;
+		regulator-name = "tps65219-LDO1-SEL-SD";
+		regulator-min-microvolt = <1800000>;
+		regulator-max-microvolt = <3300000>;
+		regulator-boot-on;
+		vin-supply = <&ldo1_reg>;
+		gpios = <&main_gpio0 45 GPIO_ACTIVE_HIGH>;
+		states = <1800000 0x0>,
+			 <3300000 0x1>;
+	};
 };
 
 &main_pmx0 {
@@ -250,6 +264,13 @@  AM64X_IOPAD(0x02a8, PIN_OUTPUT, 0) /* (E19) USB0_DRVVBUS */
 		>;
 	};
 
+	main_i2c0_pins_default: main-i2c0-pins-default {
+		pinctrl-single,pins = <
+			AM64X_IOPAD(0x0260, PIN_INPUT_PULLUP, 0) /* (A18) I2C0_SCL */
+			AM64X_IOPAD(0x0264, PIN_INPUT_PULLUP, 0) /* (B18) I2C0_SDA */
+		>;
+	};
+
 	main_i2c1_pins_default: main-i2c1-pins-default {
 		pinctrl-single,pins = <
 			AM64X_IOPAD(0x0268, PIN_INPUT_PULLUP, 0) /* (C18) I2C1_SCL */
@@ -336,6 +357,12 @@  main_wlan_pins_default: main-wlan-pins-default {
 			AM64X_IOPAD(0x00bc, PIN_INPUT, 7) /* (U8) GPIO0_46 */
 		>;
 	};
+
+	vsel_sd_nddr_pins_default: vsel-sd-nddr-pins-default {
+		pinctrl-single,pins = <
+			AM64X_IOPAD(0x00b8, PIN_INPUT, 7) /* (Y7) PRG1_PRU0_GPO0.GPIO0_45 */
+		>;
+	};
 };
 
 &mcu_uart0 {
@@ -384,6 +411,83 @@  &mcu_i2c1 {
 	status = "disabled";
 };
 
+&main_i2c0 {
+	pinctrl-names = "default";
+	pinctrl-0 = <&main_i2c0_pins_default>;
+	clock-frequency = <400000>;
+	status = "okay";
+
+	tps65219: pmic@30 {
+		compatible = "ti,tps65219";
+		reg = <0x30>;
+		system-power-controller;
+
+		buck1-supply = <&vcc_3v3_sys>;
+		buck2-supply = <&vcc_3v3_sys>;
+		buck3-supply = <&vcc_3v3_sys>;
+		ldo1-supply = <&vcc_3v3_sys>;
+		ldo2-supply = <&buck2_reg>;
+		ldo3-supply = <&vcc_3v3_sys>;
+		ldo4-supply = <&vcc_3v3_sys>;
+
+		regulators {
+			buck1_reg: buck1 {
+				regulator-name = "VDD_CORE";
+				regulator-min-microvolt = <750000>;
+				regulator-max-microvolt = <1000000>;
+				regulator-boot-on;
+				regulator-always-on;
+			};
+
+			buck2_reg: buck2 {
+				regulator-name = "VCC1V8";
+				regulator-min-microvolt = <1800000>;
+				regulator-max-microvolt = <1800000>;
+				regulator-boot-on;
+				regulator-always-on;
+			};
+
+			buck3_reg: buck3 {
+				regulator-name = "VDD_LPDDR4";
+				regulator-min-microvolt = <1100000>;
+				regulator-max-microvolt = <1100000>;
+				regulator-boot-on;
+				regulator-always-on;
+			};
+
+			ldo1_reg: ldo1 {
+				regulator-name = "VDDSHV_SD_IO_PMIC";
+				regulator-min-microvolt = <1000000>;
+				regulator-max-microvolt = <3300000>;
+				regulator-allow-bypass;
+			};
+
+			ldo2_reg: ldo2 {
+				regulator-name = "VDDAR_CORE";
+				regulator-min-microvolt = <850000>;
+				regulator-max-microvolt = <850000>;
+				regulator-boot-on;
+				regulator-always-on;
+			};
+
+			ldo3_reg: ldo3 {
+				regulator-name = "VDDA_1V8";
+				regulator-min-microvolt = <1800000>;
+				regulator-max-microvolt = <1800000>;
+				regulator-boot-on;
+				regulator-always-on;
+			};
+
+			ldo4_reg: ldo4 {
+				regulator-name = "VDD_PHY_2V5";
+				regulator-min-microvolt = <2500000>;
+				regulator-max-microvolt = <2500000>;
+				regulator-boot-on;
+				regulator-always-on;
+			};
+		};
+	};
+};
 &main_i2c1 {
 	pinctrl-names = "default";
 	pinctrl-0 = <&main_i2c1_pins_default>;