* [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 [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
all inboxes | Powered by JetHome®