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: 100142 Delivered-To: patch@linaro.org Received: by 10.140.96.100 with SMTP id j91csp45143qge; Thu, 18 May 2017 15:10:24 -0700 (PDT) X-Received: by 10.84.222.131 with SMTP id x3mr7601403pls.33.1495145423983; Thu, 18 May 2017 15:10:23 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1495145423; cv=none; d=google.com; s=arc-20160816; b=aSPlo1EvZ9rnE4bgrDtV+2fCTHGEUOuWAwmTyPIuWmMhMlBWJfZR4sC8pL4w+QpYUi 91+wdwwYg78TEmp9d/FJUBO2Y7cUTpOSt5P9JG+czqnMugCfqPh7VV4+h1kmFekZE2K2 GICecQlckwPtvUl0fVgF5wyfAPe9QIf6N1fuVVYE601JnQg9aHP8aonqOs712FomB7QO hjyFAhHI8HAZfVRpG0uHvUlbjJKxkTiqibrEJZ8nZiy5lVcDC1InGm7UxxVm5ZFY18fa re9uTjOHY5z/UmDykjQzMqszSDR4rrolJVPOVdvbyMrdnBPeshwjT2jlkp5BNZ8fLrHi ZM2Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:dkim-signature :arc-authentication-results; bh=GMGIQ21yoONUoUvD0kJILTnrW5CZ+3YhpjqxGn0aqVo=; b=K4h7U73gCOsJ1o4O77ZhTEKtwUbRskPE1HJbXM3cy3ULu7fmU0gXO8+wabTAEzGTaI HcobVJGA8waJSVFctktJlYm4O8WR5VBQ5LNH4neHeKUW0ZKU4/2LBoShBBhirgf+TcZW 7fkE7L+liYq5cfEXB03pVJGWZg0A+0Q0rZD3ED80+yHvKZ9C2B2lpL06bUrS0L8YagTk Sa2ZdlKecIcbkZ3p5rlyKA16nJ1TChNNSip68/qjoTUdGeQ/g331qEolm1I0TfSoYknj V5T0dala2h2VAyEYJSb5+/gogPOgwlaFhhwM0tg1aR0sFSvaEzlA/D2Qt/vTHDH2rDb7 PenA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@ti.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=QUARANTINE sp=NONE dis=NONE) header.from=ti.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id d71si4810907pgc.68.2017.05.18.15.10.23; Thu, 18 May 2017 15:10:23 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@ti.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=QUARANTINE sp=NONE dis=NONE) header.from=ti.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756293AbdERWKE (ORCPT + 25 others); Thu, 18 May 2017 18:10:04 -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-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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(-) -- 2.12.0 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.