From patchwork Thu May 18 22:09:01 2017 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Suman Anna X-Patchwork-Id: 9735313 Return-Path: Received: from mail.wl.linuxfoundation.org (pdx-wl-mail.web.codeaurora.org [172.30.200.125]) by pdx-korg-patchwork.web.codeaurora.org (Postfix) with ESMTP id 651E0601C8 for ; Thu, 18 May 2017 22:10:04 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 517F728A33 for ; Thu, 18 May 2017 22:10:04 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id 4629828A37; Thu, 18 May 2017 22:10:04 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on pdx-wl-mail.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-6.8 required=2.0 tests=BAYES_00,DKIM_SIGNED, RCVD_IN_DNSWL_HI,T_DKIM_INVALID autolearn=ham version=3.3.1 Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id E521928A33 for ; Thu, 18 May 2017 22:10:03 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756253AbdERWKC (ORCPT ); Thu, 18 May 2017 18:10:02 -0400 Received: from lelnx193.ext.ti.com ([198.47.27.77]:45639 "EHLO lelnx193.ext.ti.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932145AbdERWJb (ORCPT ); Thu, 18 May 2017 18:09:31 -0400 Received: from dlelxv90.itg.ti.com ([172.17.2.17]) by lelnx193.ext.ti.com (8.15.1/8.15.1) with ESMTP id v4IM95Kj008824; Thu, 18 May 2017 17:09:05 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ti.com; s=ti-com-17Q1; t=1495145345; bh=us/i3oELNmG9FuuM/VzjTGT2aGfv2B4ZmifMmpItzGw=; h=From:To:CC:Subject:Date:In-Reply-To:References; b=xMHDQz36X2P9w1k+tG1/8rthCvMkoUZVvtBhU5hoOx1Wg77384YhWx569k7dvA7yi mxHkFTlCfpvh8JCWbd5Kx94lw2AseJhsf4BK3VCKkP0p0Nwg3JdlNYKjTXNnUbx0MC iJon/oA/+ui0GUogHVPj8y9fjPEKg2tOVeR2gVmg= Received: from DFLE73.ent.ti.com (dfle73.ent.ti.com [128.247.5.110]) by dlelxv90.itg.ti.com (8.14.3/8.13.8) with ESMTP id v4IM95n6008802; Thu, 18 May 2017 17:09:05 -0500 Received: from dflp32.itg.ti.com (10.64.6.15) by DFLE73.ent.ti.com (128.247.5.110) with Microsoft SMTP Server id 14.3.294.0; Thu, 18 May 2017 17:09:04 -0500 Received: from legion.dal.design.ti.com (legion.dal.design.ti.com [128.247.22.53]) by dflp32.itg.ti.com (8.14.3/8.13.8) with ESMTP id v4IM94g1023208; Thu, 18 May 2017 17:09:04 -0500 Received: from localhost (irmo.dhcp.ti.com [128.247.58.167]) by legion.dal.design.ti.com (8.11.7p1+Sun/8.11.7) with ESMTP id v4IM94323055; Thu, 18 May 2017 17:09:04 -0500 (CDT) From: Suman Anna To: Bjorn Andersson CC: , Sekhar Nori , Robert Tivy , , , Suman Anna Subject: [PATCH 3/4] remoteproc/davinci: fix unbalanced reset between start and stop ops Date: Thu, 18 May 2017 17:09:01 -0500 Message-ID: <20170518220902.2846-4-s-anna@ti.com> X-Mailer: git-send-email 2.12.0 In-Reply-To: <20170518220902.2846-1-s-anna@ti.com> References: <20170518220902.2846-1-s-anna@ti.com> MIME-Version: 1.0 Sender: linux-remoteproc-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-remoteproc@vger.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP The davinci remoteproc driver is currently de-asserting the reset in its rproc .start() ops, but is not asserting the reset in its .stop() ops. This leaves the remote processor to not boot properly when using the sysfs 'state' variable between multiple start and stop operations. On the other hand, a reset is being asserted unconditionally in the driver remove function to alleviate some of these issues. Move this reset assertion logic into the .stop() ops implementation to fix the sysfs state-machine and the unbalanced reset. The logic from remove is still effective since .stop() ops will be invoked during the remove due to the enabled 'auto-boot' support. The probe already has support for asserting the reset in case the DSP is not in reset for some reason. Signed-off-by: Suman Anna --- drivers/remoteproc/da8xx_remoteproc.c | 11 +---------- 1 file changed, 1 insertion(+), 10 deletions(-) diff --git a/drivers/remoteproc/da8xx_remoteproc.c b/drivers/remoteproc/da8xx_remoteproc.c index fcd3cecb4967..99539cec1329 100644 --- a/drivers/remoteproc/da8xx_remoteproc.c +++ b/drivers/remoteproc/da8xx_remoteproc.c @@ -137,6 +137,7 @@ static int da8xx_rproc_stop(struct rproc *rproc) { struct da8xx_rproc *drproc = rproc->priv; + davinci_clk_reset_assert(drproc->dsp_clk); clk_disable(drproc->dsp_clk); return 0; @@ -256,16 +257,6 @@ static int da8xx_rproc_remove(struct platform_device *pdev) struct da8xx_rproc *drproc = (struct da8xx_rproc *)rproc->priv; /* - * It's important to place the DSP in reset before going away, - * since a subsequent insmod of this module may enable the DSP's - * clock before its program/boot-address has been loaded and - * before this module's probe has had a chance to reset the DSP. - * Without the reset, the DSP can lockup permanently when it - * begins executing garbage. - */ - davinci_clk_reset_assert(drproc->dsp_clk); - - /* * The devm subsystem might end up releasing things before * freeing the irq, thus allowing an interrupt to sneak in while * the device is being removed. This should prevent that.