[PATCH v2 0/2] arm64: dts: ti: k3-j784s4: Mark tps659413 regulators as bootph-all

[PATCH v2 0/2] arm64: dts: ti: k3-j784s4: Mark tps659413 regulators as bootph-all

[Andrew Halaney]

This series marks tps659413's regulators as bootph-all in order for
the nodes (and parent nodes) to be accessible during MCU's u-boot SPL.

This in turn is desired since the tps659413 needs its MCU ESM
state machine setup in order for the watchdog to reset the board.

This took me a little while to track down, as enabling the ESM, TPS6594,
etc in u-boot would result in the below boot failure:

    U-Boot SPL 2024.10-rc4-00007-g44b12cbcd1b3-dirty (Sep 06 2024 - 14:25:52 -0500)
    SYSFW ABI: 3.1 (firmware rev 0x0009 '9.2.4--v09.02.04 (Kool Koala)')
    Initialized 4 DRAM controllers
    SPL initial stack usage: 13408 bytes
    ### ERROR ### Please RESET the board ###

Which turns out to actually have failed far earlier in spl_early_init(),
due to these nodes not being accessible in u-boot. That's hard to tell
though since console isn't setup until later (and for that reason I
think spl_early_init()'s return value in j784s4_init.c isn't
evaluated since a panic() at that point would leave a user with *no*
information at all).

I've tested this in conjunction with a u-boot series which I'll link in
a follow-up response on the k3-j784s4-evm. I'd appreciate someone testing
on the k3-am69-sk at a minimum, as it should suffer the same fate if things
aren't setup appropriately.

Signed-off-by: Andrew Halaney <ahalaney@redhat.com>
---
Changes in v2:
- Only mark the regulator nodes as bootph-all since parents are implied
- Link to v1: https://lore.kernel.org/r/20240906-j784s4-tps6594-bootph-v1-0-c5b58d43bf04@redhat.com

---
Andrew Halaney (2):
      arm64: dts: ti: k3-j784s4-evm: Mark tps659413 regulators as bootph-all
      arm64: dts: ti: k3-am69-sk:  Mark tps659413 regulators as bootph-all

 arch/arm64/boot/dts/ti/k3-am69-sk.dts    | 8 ++++++++
 arch/arm64/boot/dts/ti/k3-j784s4-evm.dts | 8 ++++++++
 2 files changed, 16 insertions(+)
---
base-commit: 9aaeb87ce1e966169a57f53a02ba05b30880ffb8
change-id: 20240906-j784s4-tps6594-bootph-19d3f00fb98a

Best regards,
-- 
Andrew Halaney <ahalaney@redhat.com>

[PATCH v2 1/2] arm64: dts: ti: k3-j784s4-evm: Mark tps659413 regulators as bootph-all

[Andrew Halaney]

In order for the MCU domain to access this PMIC, a regulator
needs to be marked appropriately otherwise it is not seen by SPL and
therefore not configured.

This is necessary if the MCU domain is to program the TPS6594 MCU ESM
state machine, which is required to wire up the watchdog in a manner
that will reset the board.

Signed-off-by: Andrew Halaney <ahalaney@redhat.com>
---
 arch/arm64/boot/dts/ti/k3-j784s4-evm.dts | 8 ++++++++
 1 file changed, 8 insertions(+)

diff --git a/arch/arm64/boot/dts/ti/k3-j784s4-evm.dts b/arch/arm64/boot/dts/ti/k3-j784s4-evm.dts
index 6695ebbcb4d0..6ed628c2884e 100644
--- a/arch/arm64/boot/dts/ti/k3-j784s4-evm.dts
+++ b/arch/arm64/boot/dts/ti/k3-j784s4-evm.dts
@@ -663,6 +663,7 @@ tps659413: pmic@48 {
 
 		regulators {
 			bucka12: buck12 {
+				bootph-all;
 				regulator-name = "vdd_ddr_1v1";
 				regulator-min-microvolt = <1100000>;
 				regulator-max-microvolt = <1100000>;
@@ -671,6 +672,7 @@ bucka12: buck12 {
 			};
 
 			bucka3: buck3 {
+				bootph-all;
 				regulator-name = "vdd_ram_0v85";
 				regulator-min-microvolt = <850000>;
 				regulator-max-microvolt = <850000>;
@@ -679,6 +681,7 @@ bucka3: buck3 {
 			};
 
 			bucka4: buck4 {
+				bootph-all;
 				regulator-name = "vdd_io_1v8";
 				regulator-min-microvolt = <1800000>;
 				regulator-max-microvolt = <1800000>;
@@ -687,6 +690,7 @@ bucka4: buck4 {
 			};
 
 			bucka5: buck5 {
+				bootph-all;
 				regulator-name = "vdd_mcu_0v85";
 				regulator-min-microvolt = <850000>;
 				regulator-max-microvolt = <850000>;
@@ -695,6 +699,7 @@ bucka5: buck5 {
 			};
 
 			ldoa1: ldo1 {
+				bootph-all;
 				regulator-name = "vdd_mcuio_1v8";
 				regulator-min-microvolt = <1800000>;
 				regulator-max-microvolt = <1800000>;
@@ -703,6 +708,7 @@ ldoa1: ldo1 {
 			};
 
 			ldoa2: ldo2 {
+				bootph-all;
 				regulator-name = "vdd_mcuio_3v3";
 				regulator-min-microvolt = <3300000>;
 				regulator-max-microvolt = <3300000>;
@@ -711,6 +717,7 @@ ldoa2: ldo2 {
 			};
 
 			ldoa3: ldo3 {
+				bootph-all;
 				regulator-name = "vds_dll_0v8";
 				regulator-min-microvolt = <800000>;
 				regulator-max-microvolt = <800000>;
@@ -719,6 +726,7 @@ ldoa3: ldo3 {
 			};
 
 			ldoa4: ldo4 {
+				bootph-all;
 				regulator-name = "vda_mcu_1v8";
 				regulator-min-microvolt = <1800000>;
 				regulator-max-microvolt = <1800000>;

-- 
2.46.0

[PATCH v2 2/2] arm64: dts: ti: k3-am69-sk: Mark tps659413 regulators as bootph-all

[Andrew Halaney]

In order for the MCU domain to access this PMIC, a regulator
needs to be marked appropriately otherwise it is not seen by SPL and
therefore not configured.

This is necessary if the MCU domain is to program the TPS6594 MCU ESM
state machine, which is required to wire up the watchdog in a manner
that will reset the board.

Signed-off-by: Andrew Halaney <ahalaney@redhat.com>
---
 arch/arm64/boot/dts/ti/k3-am69-sk.dts | 8 ++++++++
 1 file changed, 8 insertions(+)

diff --git a/arch/arm64/boot/dts/ti/k3-am69-sk.dts b/arch/arm64/boot/dts/ti/k3-am69-sk.dts
index 1e36965a1403..f4d158a0b97d 100644
--- a/arch/arm64/boot/dts/ti/k3-am69-sk.dts
+++ b/arch/arm64/boot/dts/ti/k3-am69-sk.dts
@@ -750,6 +750,7 @@ tps659413: pmic@48 {
 
 		regulators {
 			bucka12: buck12 {
+				bootph-all;
 				regulator-name = "vdd_ddr_1v1";
 				regulator-min-microvolt = <1100000>;
 				regulator-max-microvolt = <1100000>;
@@ -758,6 +759,7 @@ bucka12: buck12 {
 			};
 
 			bucka3: buck3 {
+				bootph-all;
 				regulator-name = "vdd_ram_0v85";
 				regulator-min-microvolt = <850000>;
 				regulator-max-microvolt = <850000>;
@@ -766,6 +768,7 @@ bucka3: buck3 {
 			};
 
 			bucka4: buck4 {
+				bootph-all;
 				regulator-name = "vdd_io_1v8";
 				regulator-min-microvolt = <1800000>;
 				regulator-max-microvolt = <1800000>;
@@ -774,6 +777,7 @@ bucka4: buck4 {
 			};
 
 			bucka5: buck5 {
+				bootph-all;
 				regulator-name = "vdd_mcu_0v85";
 				regulator-min-microvolt = <850000>;
 				regulator-max-microvolt = <850000>;
@@ -782,6 +786,7 @@ bucka5: buck5 {
 			};
 
 			ldoa1: ldo1 {
+				bootph-all;
 				regulator-name = "vdd_mcuio_1v8";
 				regulator-min-microvolt = <1800000>;
 				regulator-max-microvolt = <1800000>;
@@ -790,6 +795,7 @@ ldoa1: ldo1 {
 			};
 
 			ldoa2: ldo2 {
+				bootph-all;
 				regulator-name = "vdd_mcuio_3v3";
 				regulator-min-microvolt = <3300000>;
 				regulator-max-microvolt = <3300000>;
@@ -798,6 +804,7 @@ ldoa2: ldo2 {
 			};
 
 			ldoa3: ldo3 {
+				bootph-all;
 				regulator-name = "vds_dll_0v8";
 				regulator-min-microvolt = <800000>;
 				regulator-max-microvolt = <800000>;
@@ -806,6 +813,7 @@ ldoa3: ldo3 {
 			};
 
 			ldoa4: ldo4 {
+				bootph-all;
 				regulator-name = "vda_mcu_1v8";
 				regulator-min-microvolt = <1800000>;
 				regulator-max-microvolt = <1800000>;

-- 
2.46.0

Re: [PATCH v2 0/2] arm64: dts: ti: k3-j784s4: Mark tps659413 regulators as bootph-all

[Andrew Halaney]

On Wed, Sep 11, 2024 at 12:19:01PM GMT, Andrew Halaney wrote:
> This series marks tps659413's regulators as bootph-all in order for
> the nodes (and parent nodes) to be accessible during MCU's u-boot SPL.
> 
> This in turn is desired since the tps659413 needs its MCU ESM
> state machine setup in order for the watchdog to reset the board.
> 
> This took me a little while to track down, as enabling the ESM, TPS6594,
> etc in u-boot would result in the below boot failure:
> 
>     U-Boot SPL 2024.10-rc4-00007-g44b12cbcd1b3-dirty (Sep 06 2024 - 14:25:52 -0500)
>     SYSFW ABI: 3.1 (firmware rev 0x0009 '9.2.4--v09.02.04 (Kool Koala)')
>     Initialized 4 DRAM controllers
>     SPL initial stack usage: 13408 bytes
>     ### ERROR ### Please RESET the board ###
> 
> Which turns out to actually have failed far earlier in spl_early_init(),
> due to these nodes not being accessible in u-boot. That's hard to tell
> though since console isn't setup until later (and for that reason I
> think spl_early_init()'s return value in j784s4_init.c isn't
> evaluated since a panic() at that point would leave a user with *no*
> information at all).
> 
> I've tested this in conjunction with a u-boot series which I'll link in
> a follow-up response on the k3-j784s4-evm. I'd appreciate someone testing
> on the k3-am69-sk at a minimum, as it should suffer the same fate if things
> aren't setup appropriately.
> 
> Signed-off-by: Andrew Halaney <ahalaney@redhat.com>

Link to the u-boot series: https://lore.kernel.org/all/3bf2177d-178f-46bf-abfe-6f00a52c623b@ti.com/#t

Udit, it seems you tested the am69-sk patch from this series in the above
u-boot link, thanks! If that's correct mind adding your Tested-by on
the patch here then as well?

Thanks,
Andrew

> ---
> Changes in v2:
> - Only mark the regulator nodes as bootph-all since parents are implied
> - Link to v1: https://lore.kernel.org/r/20240906-j784s4-tps6594-bootph-v1-0-c5b58d43bf04@redhat.com
> 
> ---
> Andrew Halaney (2):
>       arm64: dts: ti: k3-j784s4-evm: Mark tps659413 regulators as bootph-all
>       arm64: dts: ti: k3-am69-sk:  Mark tps659413 regulators as bootph-all
> 
>  arch/arm64/boot/dts/ti/k3-am69-sk.dts    | 8 ++++++++
>  arch/arm64/boot/dts/ti/k3-j784s4-evm.dts | 8 ++++++++
>  2 files changed, 16 insertions(+)
> ---
> base-commit: 9aaeb87ce1e966169a57f53a02ba05b30880ffb8
> change-id: 20240906-j784s4-tps6594-bootph-19d3f00fb98a
> 
> Best regards,
> -- 
> Andrew Halaney <ahalaney@redhat.com>
> 

Re: [PATCH v2 0/2] arm64: dts: ti: k3-j784s4: Mark tps659413 regulators as bootph-all

[Kumar, Udit]

On 9/12/2024 9:32 PM, Andrew Halaney wrote:
> On Wed, Sep 11, 2024 at 12:19:01PM GMT, Andrew Halaney wrote:
>> This series marks tps659413's regulators as bootph-all in order for
>> the nodes (and parent nodes) to be accessible during MCU's u-boot SPL.
>>
>> This in turn is desired since the tps659413 needs its MCU ESM
>> state machine setup in order for the watchdog to reset the board.
>>
>> This took me a little while to track down, as enabling the ESM, TPS6594,
>> etc in u-boot would result in the below boot failure:
>>
>>      U-Boot SPL 2024.10-rc4-00007-g44b12cbcd1b3-dirty (Sep 06 2024 - 14:25:52 -0500)
>>      SYSFW ABI: 3.1 (firmware rev 0x0009 '9.2.4--v09.02.04 (Kool Koala)')
>>      Initialized 4 DRAM controllers
>>      SPL initial stack usage: 13408 bytes
>>      ### ERROR ### Please RESET the board ###
>>
>> Which turns out to actually have failed far earlier in spl_early_init(),
>> due to these nodes not being accessible in u-boot. That's hard to tell
>> though since console isn't setup until later (and for that reason I
>> think spl_early_init()'s return value in j784s4_init.c isn't
>> evaluated since a panic() at that point would leave a user with *no*
>> information at all).
>>
>> I've tested this in conjunction with a u-boot series which I'll link in
>> a follow-up response on the k3-j784s4-evm. I'd appreciate someone testing
>> on the k3-am69-sk at a minimum, as it should suffer the same fate if things
>> aren't setup appropriately.
>>
>> Signed-off-by: Andrew Halaney <ahalaney@redhat.com>
> Link to the u-boot series: https://lore.kernel.org/all/3bf2177d-178f-46bf-abfe-6f00a52c623b@ti.com/#t
>
> Udit, it seems you tested the am69-sk patch from this series in the above
> u-boot link, thanks! If that's correct mind adding your Tested-by on
> the patch here then as well?


Yes, Please use for this series on both platforms

Tested-by: Udit Kumar <u-kumar1@ti.com>


>
> Thanks,
> Andrew
>
>> ---
>> Changes in v2:
>> - Only mark the regulator nodes as bootph-all since parents are implied
>> - Link to v1: https://lore.kernel.org/r/20240906-j784s4-tps6594-bootph-v1-0-c5b58d43bf04@redhat.com
>>
>> ---
>> Andrew Halaney (2):
>>        arm64: dts: ti: k3-j784s4-evm: Mark tps659413 regulators as bootph-all
>>        arm64: dts: ti: k3-am69-sk:  Mark tps659413 regulators as bootph-all
>>
>>   arch/arm64/boot/dts/ti/k3-am69-sk.dts    | 8 ++++++++
>>   arch/arm64/boot/dts/ti/k3-j784s4-evm.dts | 8 ++++++++
>>   2 files changed, 16 insertions(+)
>> ---
>> base-commit: 9aaeb87ce1e966169a57f53a02ba05b30880ffb8
>> change-id: 20240906-j784s4-tps6594-bootph-19d3f00fb98a
>>
>> Best regards,
>> -- 
>> Andrew Halaney <ahalaney@redhat.com>
>>

Re: [PATCH v2 1/2] arm64: dts: ti: k3-j784s4-evm: Mark tps659413 regulators as bootph-all

[Beleswar Prasad Padhi]

Hi Andrew,

On 11/09/24 22:49, Andrew Halaney wrote:
> In order for the MCU domain to access this PMIC, a regulator
> needs to be marked appropriately otherwise it is not seen by SPL and
> therefore not configured.
>
> This is necessary if the MCU domain is to program the TPS6594 MCU ESM
> state machine, which is required to wire up the watchdog in a manner
> that will reset the board.
>
> Signed-off-by: Andrew Halaney <ahalaney@redhat.com>
> ---
>   arch/arm64/boot/dts/ti/k3-j784s4-evm.dts | 8 ++++++++
>   1 file changed, 8 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/ti/k3-j784s4-evm.dts b/arch/arm64/boot/dts/ti/k3-j784s4-evm.dts
> index 6695ebbcb4d0..6ed628c2884e 100644
> --- a/arch/arm64/boot/dts/ti/k3-j784s4-evm.dts
> +++ b/arch/arm64/boot/dts/ti/k3-j784s4-evm.dts
> @@ -663,6 +663,7 @@ tps659413: pmic@48 {
>   
>   		regulators {
>   			bucka12: buck12 {
> +				bootph-all;
>   				regulator-name = "vdd_ddr_1v1";
>   				regulator-min-microvolt = <1100000>;
>   				regulator-max-microvolt = <1100000>;


In my opinion, bootph-all property should come after other standard 
properties like regulator-name etc., as it is least important to Linux. 
Same comment for other nodes wherever applicable. What is your opinion?


https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/devicetree/bindings/dts-coding-style.rst#n130


Thanks,

Beleswar

> @@ -671,6 +672,7 @@ bucka12: buck12 {
>   			};
>   
>   			bucka3: buck3 {
> +				bootph-all;
>   				regulator-name = "vdd_ram_0v85";
>   				regulator-min-microvolt = <850000>;
>   				regulator-max-microvolt = <850000>;
> @@ -679,6 +681,7 @@ bucka3: buck3 {
>   			};
>   
>   			bucka4: buck4 {
> +				bootph-all;
>   				regulator-name = "vdd_io_1v8";
>   				regulator-min-microvolt = <1800000>;
>   				regulator-max-microvolt = <1800000>;
> @@ -687,6 +690,7 @@ bucka4: buck4 {
>   			};
>   
>   			bucka5: buck5 {
> +				bootph-all;
>   				regulator-name = "vdd_mcu_0v85";
>   				regulator-min-microvolt = <850000>;
>   				regulator-max-microvolt = <850000>;
> @@ -695,6 +699,7 @@ bucka5: buck5 {
>   			};
>   
>   			ldoa1: ldo1 {
> +				bootph-all;
>   				regulator-name = "vdd_mcuio_1v8";
>   				regulator-min-microvolt = <1800000>;
>   				regulator-max-microvolt = <1800000>;
> @@ -703,6 +708,7 @@ ldoa1: ldo1 {
>   			};
>   
>   			ldoa2: ldo2 {
> +				bootph-all;
>   				regulator-name = "vdd_mcuio_3v3";
>   				regulator-min-microvolt = <3300000>;
>   				regulator-max-microvolt = <3300000>;
> @@ -711,6 +717,7 @@ ldoa2: ldo2 {
>   			};
>   
>   			ldoa3: ldo3 {
> +				bootph-all;
>   				regulator-name = "vds_dll_0v8";
>   				regulator-min-microvolt = <800000>;
>   				regulator-max-microvolt = <800000>;
> @@ -719,6 +726,7 @@ ldoa3: ldo3 {
>   			};
>   
>   			ldoa4: ldo4 {
> +				bootph-all;
>   				regulator-name = "vda_mcu_1v8";
>   				regulator-min-microvolt = <1800000>;
>   				regulator-max-microvolt = <1800000>;
>

Re: [PATCH v2 1/2] arm64: dts: ti: k3-j784s4-evm: Mark tps659413 regulators as bootph-all

[Andrew Halaney]

On Fri, Sep 13, 2024 at 04:27:47PM GMT, Beleswar Prasad Padhi wrote:
> Hi Andrew,
> 
> On 11/09/24 22:49, Andrew Halaney wrote:
> > In order for the MCU domain to access this PMIC, a regulator
> > needs to be marked appropriately otherwise it is not seen by SPL and
> > therefore not configured.
> > 
> > This is necessary if the MCU domain is to program the TPS6594 MCU ESM
> > state machine, which is required to wire up the watchdog in a manner
> > that will reset the board.
> > 
> > Signed-off-by: Andrew Halaney <ahalaney@redhat.com>
> > ---
> >   arch/arm64/boot/dts/ti/k3-j784s4-evm.dts | 8 ++++++++
> >   1 file changed, 8 insertions(+)
> > 
> > diff --git a/arch/arm64/boot/dts/ti/k3-j784s4-evm.dts b/arch/arm64/boot/dts/ti/k3-j784s4-evm.dts
> > index 6695ebbcb4d0..6ed628c2884e 100644
> > --- a/arch/arm64/boot/dts/ti/k3-j784s4-evm.dts
> > +++ b/arch/arm64/boot/dts/ti/k3-j784s4-evm.dts
> > @@ -663,6 +663,7 @@ tps659413: pmic@48 {
> >   		regulators {
> >   			bucka12: buck12 {
> > +				bootph-all;
> >   				regulator-name = "vdd_ddr_1v1";
> >   				regulator-min-microvolt = <1100000>;
> >   				regulator-max-microvolt = <1100000>;
> 
> 
> In my opinion, bootph-all property should come after other standard
> properties like regulator-name etc., as it is least important to Linux. Same
> comment for other nodes wherever applicable. What is your opinion?
> 
> 
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/devicetree/bindings/dts-coding-style.rst#n130

I think that does align better with the dts-coding-style doc!

Looking at the tree though, the standard currently in the TI folder
is to put it first. In my opinion if changing the ordering is desired
it should be done in one fell swoop (outside this series). I'd do
it one big patch, but I'm curious if that's decided the way forward what
the TI maintainers would like to see. I can send that patch if desired.

For now I think sticking with the current practice in this series
makes sense until that fell swoop happens.

Please let me know if you feel strongly otherwise.

Thanks,
Andrew

Re: [PATCH v2 1/2] arm64: dts: ti: k3-j784s4-evm: Mark tps659413 regulators as bootph-all

[Beleswar Prasad Padhi]

On 14/09/24 00:27, Andrew Halaney wrote:
> On Fri, Sep 13, 2024 at 04:27:47PM GMT, Beleswar Prasad Padhi wrote:
>> Hi Andrew,
>>
>> On 11/09/24 22:49, Andrew Halaney wrote:
>>> In order for the MCU domain to access this PMIC, a regulator
>>> needs to be marked appropriately otherwise it is not seen by SPL and
>>> therefore not configured.
>>>
>>> This is necessary if the MCU domain is to program the TPS6594 MCU ESM
>>> state machine, which is required to wire up the watchdog in a manner
>>> that will reset the board.
>>>
>>> Signed-off-by: Andrew Halaney <ahalaney@redhat.com>
>>> ---
>>>    arch/arm64/boot/dts/ti/k3-j784s4-evm.dts | 8 ++++++++
>>>    1 file changed, 8 insertions(+)
>>>
>>> diff --git a/arch/arm64/boot/dts/ti/k3-j784s4-evm.dts b/arch/arm64/boot/dts/ti/k3-j784s4-evm.dts
>>> index 6695ebbcb4d0..6ed628c2884e 100644
>>> --- a/arch/arm64/boot/dts/ti/k3-j784s4-evm.dts
>>> +++ b/arch/arm64/boot/dts/ti/k3-j784s4-evm.dts
>>> @@ -663,6 +663,7 @@ tps659413: pmic@48 {
>>>    		regulators {
>>>    			bucka12: buck12 {
>>> +				bootph-all;
>>>    				regulator-name = "vdd_ddr_1v1";
>>>    				regulator-min-microvolt = <1100000>;
>>>    				regulator-max-microvolt = <1100000>;
>>
>> In my opinion, bootph-all property should come after other standard
>> properties like regulator-name etc., as it is least important to Linux. Same
>> comment for other nodes wherever applicable. What is your opinion?
>>
>>
>> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/devicetree/bindings/dts-coding-style.rst#n130
> I think that does align better with the dts-coding-style doc!
>
> Looking at the tree though, the standard currently in the TI folder
> is to put it first. In my opinion if changing the ordering is desired
> it should be done in one fell swoop (outside this series). I'd do


There is a series[0] under review which takes care of this bootph- 
addition and order correction. In that series, looks like bootph- is 
placed at the end of the list of all standard properties. So, it is 
better if we align these patches to follow the same.

[0]: 
https://lore.kernel.org/all/20240814-b4-upstream-bootph-all-v4-2-f2b462000f25@ti.com/


Thanks,
Beleswar

> it one big patch, but I'm curious if that's decided the way forward what
> the TI maintainers would like to see. I can send that patch if desired.
>
> For now I think sticking with the current practice in this series
> makes sense until that fell swoop happens.
>
> Please let me know if you feel strongly otherwise.
>
> Thanks,
> Andrew
>

Re: [PATCH v2 1/2] arm64: dts: ti: k3-j784s4-evm: Mark tps659413 regulators as bootph-all

[Andrew Halaney]

On Mon, Sep 16, 2024 at 04:14:43PM GMT, Beleswar Prasad Padhi wrote:
> 
> On 14/09/24 00:27, Andrew Halaney wrote:
> > On Fri, Sep 13, 2024 at 04:27:47PM GMT, Beleswar Prasad Padhi wrote:
> > > Hi Andrew,
> > > 
> > > On 11/09/24 22:49, Andrew Halaney wrote:
> > > > In order for the MCU domain to access this PMIC, a regulator
> > > > needs to be marked appropriately otherwise it is not seen by SPL and
> > > > therefore not configured.
> > > > 
> > > > This is necessary if the MCU domain is to program the TPS6594 MCU ESM
> > > > state machine, which is required to wire up the watchdog in a manner
> > > > that will reset the board.
> > > > 
> > > > Signed-off-by: Andrew Halaney <ahalaney@redhat.com>
> > > > ---
> > > >    arch/arm64/boot/dts/ti/k3-j784s4-evm.dts | 8 ++++++++
> > > >    1 file changed, 8 insertions(+)
> > > > 
> > > > diff --git a/arch/arm64/boot/dts/ti/k3-j784s4-evm.dts b/arch/arm64/boot/dts/ti/k3-j784s4-evm.dts
> > > > index 6695ebbcb4d0..6ed628c2884e 100644
> > > > --- a/arch/arm64/boot/dts/ti/k3-j784s4-evm.dts
> > > > +++ b/arch/arm64/boot/dts/ti/k3-j784s4-evm.dts
> > > > @@ -663,6 +663,7 @@ tps659413: pmic@48 {
> > > >    		regulators {
> > > >    			bucka12: buck12 {
> > > > +				bootph-all;
> > > >    				regulator-name = "vdd_ddr_1v1";
> > > >    				regulator-min-microvolt = <1100000>;
> > > >    				regulator-max-microvolt = <1100000>;
> > > 
> > > In my opinion, bootph-all property should come after other standard
> > > properties like regulator-name etc., as it is least important to Linux. Same
> > > comment for other nodes wherever applicable. What is your opinion?
> > > 
> > > 
> > > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/devicetree/bindings/dts-coding-style.rst#n130
> > I think that does align better with the dts-coding-style doc!
> > 
> > Looking at the tree though, the standard currently in the TI folder
> > is to put it first. In my opinion if changing the ordering is desired
> > it should be done in one fell swoop (outside this series). I'd do
> 
> 
> There is a series[0] under review which takes care of this bootph- addition
> and order correction. In that series, looks like bootph- is placed at the
> end of the list of all standard properties. So, it is better if we align
> these patches to follow the same.
> 
> [0]: https://lore.kernel.org/all/20240814-b4-upstream-bootph-all-v4-2-f2b462000f25@ti.com/
> 

Ahh, ok. I'll post v3 with things ordered in that fashion!

Thanks,
Andrew