Re: [REGRESSION] Suspend to RAM does not work anymore with k3-am62-ti-ipc-firmware.dtsi

[Francesco Dolcini <francesco@dolcini.it>]

On Tue, Oct 21, 2025 at 02:33:10PM +0530, Beleswar Prasad Padhi wrote:
> On 20/10/25 19:47, Hiago De Franco wrote:
> > DM R5 sends a message that is never consumed, since no firmware is
> > running on the M4 (the core is offline).
> 
> 
> May I know why you are not running any firmware on the M4
> rproc? If the intention is just to run the DM R5 core on the SoC,
> you can disable the IPC by NOT including the
> "k3-am62-ti-ipc-firmware.dtsi". That was the motivation for the
> refactoring.

Verdin AM62 and AM62P are generic SoMs, that can be used for a multitude
of different use cases. And not having anything running on the M4 is the
default use case.

I think having the node in the DT is the correct way forward, if you
want to start the M4 firmware you need such a node, so this is enabling
a valid and useful use case.

> List of suggestions/solutions in order of preference:
> 1. If no intention to enable IPC on rprocs:
>       Do _not_ include k3-am62-ti-ipc-firmware.dtsi
> 2. If intention is to enable IPC on rprocs:
>       Make sure rproc firmware is available in rootfs.
>       rproc would boot up and consume the mbox
>       msg, suspend would be successful. Tested this
>       on TI AM62x-sk with commit 1d6161617c, works
> 3. Add support in mbox driver to flush the pending
>     queues.

2 is not applicable here, and 1 to me is not a good solution. So this
means that we need #3.

> > #regzbot introduced: 1d6161617c
> 
> Would not see this as a regression, but rather a new
> bug for the omap-mailbox driver...

As a user this is just a regression. It worked fine before, it's not
working anymore now.

The fact that the solution might not be in the same file that introduced
the issue is not a reason for this not being considered a regression.

Francesco