From patchwork Tue Mar 10 21:05:53 2020 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Suman Anna X-Patchwork-Id: 243486 List-Id: U-Boot discussion From: s-anna at ti.com (Suman Anna) Date: Tue, 10 Mar 2020 16:05:53 -0500 Subject: [PATCH 1/4] remoteproc: k3-dsp: Fix unbalanced state machine in k3_dsp_start In-Reply-To: <20200310210556.9053-1-s-anna@ti.com> References: <20200310210556.9053-1-s-anna@ti.com> Message-ID: <20200310210556.9053-2-s-anna@ti.com> The global module reset is deasserted through the ti_sci_power_domain_on() call in k3_dsp_start(), but is not asserted back if the local module reset fails. Fix this. While at this, remove the stale comment about assigned-clock-rates that seems to have been copied from the K3 ARM64 Remoteproc driver. Fixes: ab827b385718 ("remoteproc: Introduce K3 C66 and C71 remoteproc driver") Signed-off-by: Suman Anna --- drivers/remoteproc/ti_k3_dsp_rproc.c | 8 +++----- 1 file changed, 3 insertions(+), 5 deletions(-) diff --git a/drivers/remoteproc/ti_k3_dsp_rproc.c b/drivers/remoteproc/ti_k3_dsp_rproc.c index 09e050ffb2d3..ff5d7f7f464f 100644 --- a/drivers/remoteproc/ti_k3_dsp_rproc.c +++ b/drivers/remoteproc/ti_k3_dsp_rproc.c @@ -102,16 +102,14 @@ static int k3_dsp_start(struct udevice *dev) ret = ti_sci_proc_request(&dsp->tsp); if (ret) return ret; - /* - * Setting the right clock frequency would have taken care by - * assigned-clock-rates during the device probe. So no need to - * set the frequency again here. - */ + ret = ti_sci_proc_power_domain_on(&dsp->tsp); if (ret) goto proc_release; ret = reset_deassert(&dsp->dsp_rst); + if (ret) + ti_sci_proc_power_domain_off(&dsp->tsp); proc_release: ti_sci_proc_release(&dsp->tsp);