| author | Suman Anna <s-anna@ti.com> | |
| Wed, 24 Oct 2018 22:15:03 +0000 (17:15 -0500) | ||
| committer | Suman Anna <s-anna@ti.com> | |
| Thu, 25 Oct 2018 15:52:16 +0000 (10:52 -0500) | ||
| commit | 2419f21396b9958fe2b25a9ecae791b29bd30fe7 | |
| tree | d03289a4f256bbf1b3a8914b9ec7abfbb343e8ca | tree | snapshot (tar.xz tar.gz zip) |
| parent | 6069b8049e7fca86f1b2073955874462382f2c81 | commit | diff |
remoteproc/k3-r5: fix the R5 boot state machine for multiple combinations
The R5F processors on TI K3 SoCs require a specific sequence for booting
and shutting down the processors. This sequence is also dependent on the
mode (LockStep or Split) the R5F cluster is configured for. The R5F cores
have a Memory Protection Unit (MPU) that has a default configuration that
does not allow the cores to run out of DDR out of reset. This is resolved
by using the TCMs for boot-strapping code that applies the appropriate
executable permissions on desired DDR memory. The loading into the TCMs
requires that the resets be released first with the cores in halted state.
The Power Sleep Controller (PSC) module on K3 SoCs requires that the cores
be in WFI/WFE states with no active bus transactions before the cores can
be put back into reset.
The existing code uses an asymmetric logic for asserting and deasserting
the resets to satisfy the above conditions. The resets are released before
the rproc is registered (during probe), with the cores unhalted in .start()
ops. The cores are halted, resets asserted and released again in .stop()
ops to allow the remoteprocs to be started and stopped repeatedly using
the sysfs 'state' file. The resets are also asserted during remove, and
the deassertion logic in .stop() is done conditionally only if it not
invoked through the remove path. This covers the repeated insmod/rmmod
or sysfs stop/start sequences. This however causes a rproc boot hang
with sysfs stop, rmmod followed by an insmod, since the cores are not
in WFE/WFI during rmmod.
Fix the above issue and the asymmetrical usage properly leveraging the
newly introduce .prepare() and .unprepare() ops in the remoteproc core.
The .prepare() ops is invoked before any loading, and the .unprepare()
ops is invoked after the remoteproc resource cleanup. The R5F core resets
are deasserted in .prepare() and asserted in .unprepare() eliminating the
need for the previous complex logic.
Signed-off-by: Suman Anna <s-anna@ti.com>
The R5F processors on TI K3 SoCs require a specific sequence for booting
and shutting down the processors. This sequence is also dependent on the
mode (LockStep or Split) the R5F cluster is configured for. The R5F cores
have a Memory Protection Unit (MPU) that has a default configuration that
does not allow the cores to run out of DDR out of reset. This is resolved
by using the TCMs for boot-strapping code that applies the appropriate
executable permissions on desired DDR memory. The loading into the TCMs
requires that the resets be released first with the cores in halted state.
The Power Sleep Controller (PSC) module on K3 SoCs requires that the cores
be in WFI/WFE states with no active bus transactions before the cores can
be put back into reset.
The existing code uses an asymmetric logic for asserting and deasserting
the resets to satisfy the above conditions. The resets are released before
the rproc is registered (during probe), with the cores unhalted in .start()
ops. The cores are halted, resets asserted and released again in .stop()
ops to allow the remoteprocs to be started and stopped repeatedly using
the sysfs 'state' file. The resets are also asserted during remove, and
the deassertion logic in .stop() is done conditionally only if it not
invoked through the remove path. This covers the repeated insmod/rmmod
or sysfs stop/start sequences. This however causes a rproc boot hang
with sysfs stop, rmmod followed by an insmod, since the cores are not
in WFE/WFI during rmmod.
Fix the above issue and the asymmetrical usage properly leveraging the
newly introduce .prepare() and .unprepare() ops in the remoteproc core.
The .prepare() ops is invoked before any loading, and the .unprepare()
ops is invoked after the remoteproc resource cleanup. The R5F core resets
are deasserted in .prepare() and asserted in .unprepare() eliminating the
need for the previous complex logic.
Signed-off-by: Suman Anna <s-anna@ti.com>
| drivers/remoteproc/ti_k3_r5_remoteproc.c | diff | blob | history |