| Message ID | 20200311012429.3620-1-s-anna@ti.com |
|---|---|
| State | Accepted |
| Commit | 445b45042c63c79546124489362ba4e64b61bfdc |
| Headers | show |
| Series | remoteproc: k3-r5: Fix rproc init failure on Split-mode _only_ devices | expand |
On 11/03/20 6:54 AM, Suman Anna wrote: > The R5F subsystem/cluster on K3 SoCs can support both LockStep and > Split-modes (superset) or just Split-mode depending on an eFUSE > capability register. The LockStep configuration bit is Read-only > though on Split-mode _only_ devices and as such the System Firmware > does not allow the LockStep mode bit to be configured on such devices. > The current logic in k3_r5f_rproc_configure() fails on Split-mode > devices because of this unconditional programming of the LockStep > mode bit, and results in the probe failure shown during the > "rproc init" step at U-Boot prompt. > > Fix this by limiting the LockStep mode bit clear configuration only on > devices supporting both LockStep/Split-modes. > > Fixes: 4c850356a83f ("remoteproc: Introduce K3 remoteproc driver for R5F subsystem") > Signed-off-by: Suman Anna <s-anna at ti.com> > Signed-off-by: Andreas Dannenberg <dannenberg at ti.com> > Signed-off-by: Lokesh Vutla <lokeshvutla at ti.com> > --- > Hi Lokesh, > > Verified the behavior on top of the ti/next branch on a custom > board with the Split-mode only SoC. Applied to u-boot-ti/next Thanks and regards, Lokesh
diff --git a/drivers/remoteproc/ti_k3_r5f_rproc.c b/drivers/remoteproc/ti_k3_r5f_rproc.c index 2e2665f3750d..c01b29d90f1b 100644 --- a/drivers/remoteproc/ti_k3_r5f_rproc.c +++ b/drivers/remoteproc/ti_k3_r5f_rproc.c @@ -543,6 +543,7 @@ static int k3_r5f_rproc_configure(struct k3_r5f_core *core) { struct k3_r5f_cluster *cluster = core->cluster; u32 set_cfg = 0, clr_cfg = 0, cfg, ctrl, sts; + bool lockstep_permitted; u64 boot_vec = 0; int ret; @@ -560,8 +561,9 @@ static int k3_r5f_rproc_configure(struct k3_r5f_core *core) goto out; /* Sanity check for Lockstep mode */ - if (cluster->mode && is_primary_core(core) && - !(sts & PROC_BOOT_STATUS_FLAG_R5_LOCKSTEP_PERMITTED)) { + lockstep_permitted = !!(sts & + PROC_BOOT_STATUS_FLAG_R5_LOCKSTEP_PERMITTED); + if (cluster->mode && is_primary_core(core) && !lockstep_permitted) { dev_err(core->dev, "LockStep mode not permitted on this device\n"); ret = -EINVAL; goto out; @@ -573,7 +575,7 @@ static int k3_r5f_rproc_configure(struct k3_r5f_core *core) clr_cfg |= PROC_BOOT_CFG_FLAG_R5_TEINIT; if (cluster->mode == CLUSTER_MODE_LOCKSTEP) set_cfg |= PROC_BOOT_CFG_FLAG_R5_LOCKSTEP; - else + else if (lockstep_permitted) clr_cfg |= PROC_BOOT_CFG_FLAG_R5_LOCKSTEP; }
The R5F subsystem/cluster on K3 SoCs can support both LockStep and Split-modes (superset) or just Split-mode depending on an eFUSE capability register. The LockStep configuration bit is Read-only though on Split-mode _only_ devices and as such the System Firmware does not allow the LockStep mode bit to be configured on such devices. The current logic in k3_r5f_rproc_configure() fails on Split-mode devices because of this unconditional programming of the LockStep mode bit, and results in the probe failure shown during the "rproc init" step at U-Boot prompt. Fix this by limiting the LockStep mode bit clear configuration only on devices supporting both LockStep/Split-modes. Fixes: 4c850356a83f ("remoteproc: Introduce K3 remoteproc driver for R5F subsystem") Signed-off-by: Suman Anna <s-anna at ti.com> Signed-off-by: Andreas Dannenberg <dannenberg at ti.com> Signed-off-by: Lokesh Vutla <lokeshvutla at ti.com> --- Hi Lokesh, Verified the behavior on top of the ti/next branch on a custom board with the Split-mode only SoC. regards Suman drivers/remoteproc/ti_k3_r5f_rproc.c | 8 +++++--- 1 file changed, 5 insertions(+), 3 deletions(-)