Linux-ARM-Kernel Archive on lore.kernel.org
 help / color / mirror / Atom feed
* [PATCH] arm64: dts: ti: k3-am62-mcu: Add power-domains property for M4FSS
@ 2026-09-22 17:19 Siddharth Karanam
  2026-09-29 16:37 ` Andrew Davis
  0 siblings, 1 reply; 4+ messages in thread
From: Siddharth Karanam @ 2026-09-22 17:19 UTC (permalink / raw)
  To: nm, vigneshr, kristo, robh, krzk+dt, conor+dt
  Cc: linux-arm-kernel, devicetree, linux-kernel, Siddharth Karanam

Assign the power domain to the MCU M4FSS (Cortex-M4F) node by following
the device ids info published in TI-SCI public documentation.

This will be useful in future patches that will attempt at abstracting
ti_sci_dev_ops's calls such as get_device and put_device via pm_runtime
calls.

Signed-off-by: Siddharth Karanam <sid9.karanam@gmail.com>
---
 arch/arm64/boot/dts/ti/k3-am62-mcu.dtsi | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm64/boot/dts/ti/k3-am62-mcu.dtsi b/arch/arm64/boot/dts/ti/k3-am62-mcu.dtsi
index 68e906796aefe..1ae0870893c16 100644
--- a/arch/arm64/boot/dts/ti/k3-am62-mcu.dtsi
+++ b/arch/arm64/boot/dts/ti/k3-am62-mcu.dtsi
@@ -181,6 +181,7 @@ mcu_m4fss: m4fss@5000000 {
 		      <0x00 0x5040000 0x00 0x10000>;
 		reg-names = "iram", "dram";
 		resets = <&k3_reset 9 1>;
+		power-domains = <&k3_pds 7 TI_SCI_PD_EXCLUSIVE>;
 		firmware-name = "am62-mcu-m4f0_0-fw";
 		ti,sci = <&dmsc>;
 		ti,sci-dev-id = <9>;
-- 
2.34.1



^ permalink raw reply related	[flat|nested] 4+ messages in thread

* Re: [PATCH] arm64: dts: ti: k3-am62-mcu: Add power-domains property for M4FSS
  2026-09-22 17:19 [PATCH] arm64: dts: ti: k3-am62-mcu: Add power-domains property for M4FSS Siddharth Karanam
@ 2026-09-29 16:37 ` Andrew Davis
  2026-10-04 15:39   ` Sidd
  0 siblings, 1 reply; 4+ messages in thread
From: Andrew Davis @ 2026-09-29 16:37 UTC (permalink / raw)
  To: Siddharth Karanam, nm, vigneshr, kristo, robh, krzk+dt, conor+dt
  Cc: linux-arm-kernel, devicetree, linux-kernel

On 9/22/26 12:19 PM, Siddharth Karanam wrote:
> Assign the power domain to the MCU M4FSS (Cortex-M4F) node by following
> the device ids info published in TI-SCI public documentation.
> 
> This will be useful in future patches that will attempt at abstracting
> ti_sci_dev_ops's calls such as get_device and put_device via pm_runtime
> calls.
> 
> Signed-off-by: Siddharth Karanam <sid9.karanam@gmail.com>
> ---
>   arch/arm64/boot/dts/ti/k3-am62-mcu.dtsi | 1 +
>   1 file changed, 1 insertion(+)
> 
> diff --git a/arch/arm64/boot/dts/ti/k3-am62-mcu.dtsi b/arch/arm64/boot/dts/ti/k3-am62-mcu.dtsi
> index 68e906796aefe..1ae0870893c16 100644
> --- a/arch/arm64/boot/dts/ti/k3-am62-mcu.dtsi
> +++ b/arch/arm64/boot/dts/ti/k3-am62-mcu.dtsi
> @@ -181,6 +181,7 @@ mcu_m4fss: m4fss@5000000 {
>   		      <0x00 0x5040000 0x00 0x10000>;
>   		reg-names = "iram", "dram";
>   		resets = <&k3_reset 9 1>;
> +		power-domains = <&k3_pds 7 TI_SCI_PD_EXCLUSIVE>;

The surrounding M4 subsystem's power domain is 7, but the core's power domain number
is 9 (see below in `ti,sci-dev-id`). Enabling 9 should also enable 7 as it is a
dependency. We probably should have modeled the M4 in DT the way we did the R5[0].
With the core being a subnode of the subsystem. Then 7 goes in subsystem and 9
goes in the core's subnode.

Anyway, the reason we don't use the normal "power-domains", and instead manage
the power using `ti,sci-dev-id`, is because the normal power domain framework
has a nasty habit of unconditionally powering up devices before the driver can
probe. Which in the case of remoteprocs can cause the core to start running
and executing random data. We have to do things in order,

  * Power up subsystem
  * Set reset line for core
  * Power up the core
  * Setup the core (load firmware and set boot address)
  * Release reset line for core to start it running

Andrew

[0] https://github.com/torvalds/linux/blob/master/arch/arm64/boot/dts/ti/k3-am62a-mcu.dtsi#L178

>   		firmware-name = "am62-mcu-m4f0_0-fw";
>   		ti,sci = <&dmsc>;
>   		ti,sci-dev-id = <9>;



^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: [PATCH] arm64: dts: ti: k3-am62-mcu: Add power-domains property for M4FSS
  2026-09-29 16:37 ` Andrew Davis
@ 2026-10-04 15:39   ` Sidd
  2026-10-07 16:16     ` Andrew Davis
  0 siblings, 1 reply; 4+ messages in thread
From: Sidd @ 2026-10-04 15:39 UTC (permalink / raw)
  To: Andrew Davis
  Cc: nm, vigneshr, kristo, robh, krzk+dt, conor+dt, linux-arm-kernel,
	devicetree, linux-kernel

> Anyway, the reason we don't use the normal "power-domains", and instead manage
> the power using `ti,sci-dev-id`, is because the normal power domain framework
> has a nasty habit of unconditionally powering up devices before the driver can
> probe. Which in the case of remoteprocs can cause the core to start running
> and executing random data.

Oh I was not aware of this issue, seemed logical and a straightforward
issue to me, I'll drop this patch then.
I also figured this would in turn nicely move into wrapping all ti sci
handle's device ops through pmruntime (such as get_device and
put_device functions) but I believe that won't work as well.

  > * Power up subsystem
  > * Set reset line for core
  > * Power up the core
  > * Setup the core (load firmware and set boot address)
  > * Release reset line for core to start it running

Right, I see, thanks for the input :)

Thanks,
Siddharth Karanam

On Tue, Sep 29, 2026 at 10:09 PM Andrew Davis <afd@ti.com> wrote:
>
> On 9/22/26 12:19 PM, Siddharth Karanam wrote:
> > Assign the power domain to the MCU M4FSS (Cortex-M4F) node by following
> > the device ids info published in TI-SCI public documentation.
> >
> > This will be useful in future patches that will attempt at abstracting
> > ti_sci_dev_ops's calls such as get_device and put_device via pm_runtime
> > calls.
> >
> > Signed-off-by: Siddharth Karanam <sid9.karanam@gmail.com>
> > ---
> >   arch/arm64/boot/dts/ti/k3-am62-mcu.dtsi | 1 +
> >   1 file changed, 1 insertion(+)
> >
> > diff --git a/arch/arm64/boot/dts/ti/k3-am62-mcu.dtsi b/arch/arm64/boot/dts/ti/k3-am62-mcu.dtsi
> > index 68e906796aefe..1ae0870893c16 100644
> > --- a/arch/arm64/boot/dts/ti/k3-am62-mcu.dtsi
> > +++ b/arch/arm64/boot/dts/ti/k3-am62-mcu.dtsi
> > @@ -181,6 +181,7 @@ mcu_m4fss: m4fss@5000000 {
> >                     <0x00 0x5040000 0x00 0x10000>;
> >               reg-names = "iram", "dram";
> >               resets = <&k3_reset 9 1>;
> > +             power-domains = <&k3_pds 7 TI_SCI_PD_EXCLUSIVE>;
>
> The surrounding M4 subsystem's power domain is 7, but the core's power domain number
> is 9 (see below in `ti,sci-dev-id`). Enabling 9 should also enable 7 as it is a
> dependency. We probably should have modeled the M4 in DT the way we did the R5[0].
> With the core being a subnode of the subsystem. Then 7 goes in subsystem and 9
> goes in the core's subnode.
>
> Anyway, the reason we don't use the normal "power-domains", and instead manage
> the power using `ti,sci-dev-id`, is because the normal power domain framework
> has a nasty habit of unconditionally powering up devices before the driver can
> probe. Which in the case of remoteprocs can cause the core to start running
> and executing random data. We have to do things in order,
>
>   * Power up subsystem
>   * Set reset line for core
>   * Power up the core
>   * Setup the core (load firmware and set boot address)
>   * Release reset line for core to start it running
>
> Andrew
>
> [0] https://github.com/torvalds/linux/blob/master/arch/arm64/boot/dts/ti/k3-am62a-mcu.dtsi#L178
>
> >               firmware-name = "am62-mcu-m4f0_0-fw";
> >               ti,sci = <&dmsc>;
> >               ti,sci-dev-id = <9>;
>


^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: [PATCH] arm64: dts: ti: k3-am62-mcu: Add power-domains property for M4FSS
  2026-10-04 15:39   ` Sidd
@ 2026-10-07 16:16     ` Andrew Davis
  0 siblings, 0 replies; 4+ messages in thread
From: Andrew Davis @ 2026-10-07 16:16 UTC (permalink / raw)
  To: Sidd
  Cc: nm, vigneshr, kristo, robh, krzk+dt, conor+dt, linux-arm-kernel,
	devicetree, linux-kernel

On 10/4/26 10:39 AM, Sidd wrote:
>> Anyway, the reason we don't use the normal "power-domains", and instead manage
>> the power using `ti,sci-dev-id`, is because the normal power domain framework
>> has a nasty habit of unconditionally powering up devices before the driver can
>> probe. Which in the case of remoteprocs can cause the core to start running
>> and executing random data.
> 
> Oh I was not aware of this issue, seemed logical and a straightforward
> issue to me, I'll drop this patch then.
> I also figured this would in turn nicely move into wrapping all ti sci
> handle's device ops through pmruntime (such as get_device and
> put_device functions) but I believe that won't work as well.

I think factoring out the TI-SCI handle ops is still a good idea,
just not using pmruntime functions yet. We are discussing internally
about how we might enhance the PM framework to allow for marking
these devices so they are not auto-started but still allow manually
powering them using the normal PM functions. Will keep you posted,
or feel free to think up and suggest any better ideas.

Andrew

> 
>    > * Power up subsystem
>    > * Set reset line for core
>    > * Power up the core
>    > * Setup the core (load firmware and set boot address)
>    > * Release reset line for core to start it running
> 
> Right, I see, thanks for the input :)
> 
> Thanks,
> Siddharth Karanam
> 
> On Tue, Sep 29, 2026 at 10:09 PM Andrew Davis <afd@ti.com> wrote:
>>
>> On 9/22/26 12:19 PM, Siddharth Karanam wrote:
>>> Assign the power domain to the MCU M4FSS (Cortex-M4F) node by following
>>> the device ids info published in TI-SCI public documentation.
>>>
>>> This will be useful in future patches that will attempt at abstracting
>>> ti_sci_dev_ops's calls such as get_device and put_device via pm_runtime
>>> calls.
>>>
>>> Signed-off-by: Siddharth Karanam <sid9.karanam@gmail.com>
>>> ---
>>>    arch/arm64/boot/dts/ti/k3-am62-mcu.dtsi | 1 +
>>>    1 file changed, 1 insertion(+)
>>>
>>> diff --git a/arch/arm64/boot/dts/ti/k3-am62-mcu.dtsi b/arch/arm64/boot/dts/ti/k3-am62-mcu.dtsi
>>> index 68e906796aefe..1ae0870893c16 100644
>>> --- a/arch/arm64/boot/dts/ti/k3-am62-mcu.dtsi
>>> +++ b/arch/arm64/boot/dts/ti/k3-am62-mcu.dtsi
>>> @@ -181,6 +181,7 @@ mcu_m4fss: m4fss@5000000 {
>>>                      <0x00 0x5040000 0x00 0x10000>;
>>>                reg-names = "iram", "dram";
>>>                resets = <&k3_reset 9 1>;
>>> +             power-domains = <&k3_pds 7 TI_SCI_PD_EXCLUSIVE>;
>>
>> The surrounding M4 subsystem's power domain is 7, but the core's power domain number
>> is 9 (see below in `ti,sci-dev-id`). Enabling 9 should also enable 7 as it is a
>> dependency. We probably should have modeled the M4 in DT the way we did the R5[0].
>> With the core being a subnode of the subsystem. Then 7 goes in subsystem and 9
>> goes in the core's subnode.
>>
>> Anyway, the reason we don't use the normal "power-domains", and instead manage
>> the power using `ti,sci-dev-id`, is because the normal power domain framework
>> has a nasty habit of unconditionally powering up devices before the driver can
>> probe. Which in the case of remoteprocs can cause the core to start running
>> and executing random data. We have to do things in order,
>>
>>    * Power up subsystem
>>    * Set reset line for core
>>    * Power up the core
>>    * Setup the core (load firmware and set boot address)
>>    * Release reset line for core to start it running
>>
>> Andrew
>>
>> [0] https://github.com/torvalds/linux/blob/master/arch/arm64/boot/dts/ti/k3-am62a-mcu.dtsi#L178
>>
>>>                firmware-name = "am62-mcu-m4f0_0-fw";
>>>                ti,sci = <&dmsc>;
>>>                ti,sci-dev-id = <9>;
>>



^ permalink raw reply	[flat|nested] 4+ messages in thread

end of thread, other threads:[~2026-10-07 16:17 UTC | newest]

Thread overview: 4+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2026-09-22 17:19 [PATCH] arm64: dts: ti: k3-am62-mcu: Add power-domains property for M4FSS Siddharth Karanam
2026-09-29 16:37 ` Andrew Davis
2026-10-04 15:39   ` Sidd
2026-10-07 16:16     ` Andrew Davis

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox