summaryrefslogtreecommitdiff
path: root/tools/perf/scripts/python
diff options
context:
space:
mode:
authorBeleswar Padhi <b-padhi@ti.com>2025-05-13 11:14:37 +0530
committerMathieu Poirier <mathieu.poirier@linaro.org>2025-05-20 11:02:16 -0600
commit701177511abd295e0fc2499796e466d8ff12165c (patch)
tree8edcd5f384ca251503bfffb14c1e15f0f037081e /tools/perf/scripts/python
parent349d62ab207f55f039c3ddb40b36e95c2f0b3ed0 (diff)
remoteproc: k3-r5: Refactor sequential core power up/down operations
The existing implementation of the waiting mechanism in "k3_r5_cluster_rproc_init()" waits for the "released_from_reset" flag to be set as part of the firmware boot process in "k3_r5_rproc_start()". The "k3_r5_cluster_rproc_init()" function is invoked in the probe routine which causes unexpected failures in cases where the firmware is unavailable at boot time, resulting in probe failure and removal of the remoteproc handles in the sysfs paths. To address this, the waiting mechanism is refactored out of the probe routine into the appropriate "k3_r5_rproc_{prepare/unprepare}()" functions. This allows the probe routine to complete without depending on firmware booting, while still maintaining the required power-synchronization between cores. Further, this wait mechanism is dropped from "k3_r5_rproc_{start/stop}()" functions as they deal with Core Run/Halt operations, and as such, there is no constraint in Running or Halting the cores of a cluster in order. Fixes: 61f6f68447ab ("remoteproc: k3-r5: Wait for core0 power-up before powering up core1") Signed-off-by: Beleswar Padhi <b-padhi@ti.com> Tested-by: Judith Mendez <jm@ti.com> Reviewed-by: Andrew Davis <afd@ti.com> Link: https://lore.kernel.org/r/20250513054510.3439842-4-b-padhi@ti.com Signed-off-by: Mathieu Poirier <mathieu.poirier@linaro.org>
Diffstat (limited to 'tools/perf/scripts/python')
0 files changed, 0 insertions, 0 deletions