Re: [PATCH] arm64: dts: ti: k3-am62-mcu: Add power-domains property for M4FSS

[Andrew Davis <afd@ti.com>]

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>;
>>