From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 220DCC433F5 for ; Mon, 14 Feb 2022 18:43:16 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:In-Reply-To:From:References:CC:To: Subject:MIME-Version:Date:Message-ID:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=JwEp2FjwcLZLCffl707JlHIM0Umq7xZP+bVRBoP34wA=; b=lSc5VjcUR+L1lz keKHFW85Gj074l1srm5KUIAS31ekDWfFax8bfy9AFt9f2n01OV3hy/NnJ8pWIHf7XLvuJrvNayvA6 Y59hEauBhxo3h0t86diS6qMMk3a4xEM3xEphZw3oljDOYKBDcQrbL89bXdNYcy91UAz5ElIziDJwN aAn+Q/kgI6Ft6hYjgvXJozJMOck84iIp7/nSkr5UvtKqN/4nWpGvt070h8+sV42GO1xF9c/p2mzeA RP+g9k1+ddbGpHOc9aMsNUaQBFciEqRsGReDTVMGA6ScrzlHip4O/hiRMW49a1aOswHGs41UmwdfA 2B6JOaxU2AuH5/5AyqUw==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1nJgIO-00GYpl-A6; Mon, 14 Feb 2022 18:41:56 +0000 Received: from mx07-00178001.pphosted.com ([185.132.182.106]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1nJgIJ-00GYof-Ip for linux-arm-kernel@lists.infradead.org; Mon, 14 Feb 2022 18:41:54 +0000 Received: from pps.filterd (m0288072.ppops.net [127.0.0.1]) by mx07-00178001.pphosted.com (8.16.1.2/8.16.1.2) with ESMTP id 21EFbae7002001; Mon, 14 Feb 2022 19:41:42 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=foss.st.com; h=message-id : date : mime-version : subject : to : cc : references : from : in-reply-to : content-type : content-transfer-encoding; s=selector1; bh=KGz2678pGQbIbcVEydZQMC3hC9P2ytNR+Hdz3Z+2McY=; b=s+2QXTxsdXXVHNmJusjAWCUcRA5/Pf/8M48NOyWKLzUEpKst0u80bF8101lORhKqbOb2 afRQjXGiQBdLsYQmYc+zRrUwvQN2X+QgecGTB0TVGFzzs/CwqzQ+h7sanAAvHgXQz8bR A+mJLRvHSeJmBGdYdvDptL6b0k6SjfGuNpymlYgMK8pi2OKD/kDxXoVo2BQG0p0GFmM6 +M+TGM5CfSS8dcef5knA8kfaQXlrsJ99gRv9QTfgJOEt5iTKy4v6imaqvxzLJFD8LD7v A4NxJapkr0JstTLptPflFtG7685ac3LSwQ0gvjSL42qQEYMle8F42+hpId/kblPx1MZ2 sA== Received: from beta.dmz-eu.st.com (beta.dmz-eu.st.com [164.129.1.35]) by mx07-00178001.pphosted.com (PPS) with ESMTPS id 3e7pj7j9yw-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 14 Feb 2022 19:41:42 +0100 Received: from euls16034.sgp.st.com (euls16034.sgp.st.com [10.75.44.20]) by beta.dmz-eu.st.com (STMicroelectronics) with ESMTP id B92D310002A; Mon, 14 Feb 2022 19:41:41 +0100 (CET) Received: from Webmail-eu.st.com (sfhdag2node2.st.com [10.75.127.5]) by euls16034.sgp.st.com (STMicroelectronics) with ESMTP id AC008231DE5; Mon, 14 Feb 2022 19:41:41 +0100 (CET) Received: from [10.211.3.63] (10.75.127.49) by SFHDAG2NODE2.st.com (10.75.127.5) with Microsoft SMTP Server (TLS) id 15.0.1497.26; Mon, 14 Feb 2022 19:41:40 +0100 Message-ID: <67ddf940-6f87-d8cc-8dc6-29a39a022265@foss.st.com> Date: Mon, 14 Feb 2022 19:41:40 +0100 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.5.0 Subject: Re: [PATCH V2] remoteproc: support self recovery after rproc crash Content-Language: en-US To: "Peng Fan (OSS)" , , , , , CC: Peng Fan References: <20220126085120.3397450-1-peng.fan@oss.nxp.com> From: Arnaud POULIQUEN In-Reply-To: <20220126085120.3397450-1-peng.fan@oss.nxp.com> X-Originating-IP: [10.75.127.49] X-ClientProxiedBy: SFHDAG2NODE3.st.com (10.75.127.6) To SFHDAG2NODE2.st.com (10.75.127.5) X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.205,Aquarius:18.0.816,Hydra:6.0.425,FMLib:17.11.62.513 definitions=2022-02-14_07,2022-02-14_03,2021-12-02_01 X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20220214_104152_522507_500DA95E X-CRM114-Status: GOOD ( 39.66 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org Hi Peng, On 1/26/22 09:51, Peng Fan (OSS) wrote: > From: Peng Fan > > Current logic only support main processor to stop/start the remote > processor after rproc crash. However to SoC, such as i.MX8QM/QXP, the > remote processor could do self recovery after crash and trigger watchdog > reboot. It does not need main processor to load image, stop/start M4 > core. On stm32mp1 platform the remote processor watchdog generates an early interrupt that could be used to detach and reattach before the reset of the remote processor. I need to test race condition,but I suppose that this should works if the resource table is not reinitialized by the remote processor firmware. Another option for the stm32mp1 is that remoteproc manages the reset of the remote processor. For instance this allows to save a core-dump before manually resetting the remote processor. But looks like this use case can be handled later, as mentioned below. > > This patch add a new flag to indicate whether the SoC has self recovery > capability. And introduce two functions: rproc_self_recovery, > rproc_assisted_recovery for the two cases. Assisted recovery is as > before, let main processor to help recovery, while self recovery is > recover itself withou help. To self recovery, we only do detach and > attach. > > Signed-off-by: Peng Fan > --- > > V2: > Nothing change in V2. > Only move this patch out from > https://patchwork.kernel.org/project/linux-remoteproc/list/?series=604364 > > drivers/remoteproc/remoteproc_core.c | 66 ++++++++++++++++++++-------- > include/linux/remoteproc.h | 2 + > 2 files changed, 49 insertions(+), 19 deletions(-) > > diff --git a/drivers/remoteproc/remoteproc_core.c b/drivers/remoteproc/remoteproc_core.c > index 69f51acf235e..4bd5544dab8f 100644 > --- a/drivers/remoteproc/remoteproc_core.c > +++ b/drivers/remoteproc/remoteproc_core.c > @@ -1887,6 +1887,49 @@ static int __rproc_detach(struct rproc *rproc) > return 0; > } > > +static int rproc_self_recovery(struct rproc *rproc) > +{ > + int ret; > + > + mutex_unlock(&rproc->lock); > + ret = rproc_detach(rproc); > + mutex_lock(&rproc->lock); > + if (ret) > + return ret; Here we would want to perform a core dump and manually reset the co-processor. I suppose that a new rproc ops could be called here in a next step. > + > + if (atomic_inc_return(&rproc->power) > 1) > + return 0; Do you identify a use case that needs to test rproc->power to skip the attach? If yes could you add a comment to describe it? > + return rproc_attach(rproc); > +} > + > +static int rproc_assisted_recovery(struct rproc *rproc) > +{ > + const struct firmware *firmware_p; > + struct device *dev = &rproc->dev; > + int ret; > + > + ret = rproc_stop(rproc, true); > + if (ret) > + return ret; > + > + /* generate coredump */ > + rproc->ops->coredump(rproc); > + > + /* load firmware */ > + ret = request_firmware(&firmware_p, rproc->firmware, dev); > + if (ret < 0) { > + dev_err(dev, "request_firmware failed: %d\n", ret); > + return ret; > + } > + > + /* boot the remote processor up again */ > + ret = rproc_start(rproc, firmware_p); > + > + release_firmware(firmware_p); > + > + return ret; > +} > + > /** > * rproc_trigger_recovery() - recover a remoteproc > * @rproc: the remote processor > @@ -1901,7 +1944,6 @@ static int __rproc_detach(struct rproc *rproc) > */ > int rproc_trigger_recovery(struct rproc *rproc) > { > - const struct firmware *firmware_p; > struct device *dev = &rproc->dev; > int ret; > > @@ -1915,24 +1957,10 @@ int rproc_trigger_recovery(struct rproc *rproc) > > dev_err(dev, "recovering %s\n", rproc->name); > > - ret = rproc_stop(rproc, true); > - if (ret) > - goto unlock_mutex; > - > - /* generate coredump */ > - rproc->ops->coredump(rproc); > - > - /* load firmware */ > - ret = request_firmware(&firmware_p, rproc->firmware, dev); > - if (ret < 0) { > - dev_err(dev, "request_firmware failed: %d\n", ret); > - goto unlock_mutex; > - } > - > - /* boot the remote processor up again */ > - ret = rproc_start(rproc, firmware_p); > - > - release_firmware(firmware_p); > + if (rproc->self_recovery) > + ret = rproc_self_recovery(rproc); If some platforms have to manually reset the remote processor (without reloading the firmware) the name could not be relevant... Following comments are only suggestions that needs to be commented by maintainers What about rproc_attach_recovery ? > + else > + ret = rproc_assisted_recovery(rproc); and rproc_firmware_recovery ? > > unlock_mutex: > mutex_unlock(&rproc->lock); > diff --git a/include/linux/remoteproc.h b/include/linux/remoteproc.h > index e0600e1e5c17..b32ef46f8aa4 100644 > --- a/include/linux/remoteproc.h > +++ b/include/linux/remoteproc.h > @@ -529,6 +529,7 @@ struct rproc_dump_segment { > * @elf_machine: firmware ELF machine > * @cdev: character device of the rproc > * @cdev_put_on_release: flag to indicate if remoteproc should be shutdown on @char_dev release > + * @self_recovery: flag to indicate if remoteproc support self recovery > */ > struct rproc { > struct list_head node; > @@ -568,6 +569,7 @@ struct rproc { > u16 elf_machine; > struct cdev cdev; > bool cdev_put_on_release; > + bool self_recovery; This bool seems needed because we have lost the previous state before crash. I wonder if a new rproc->state such as RPROC_REBOOT could avoid this boolean. I will try to test you patch on stm32mp1 next week Regards, Arnaud > }; > > /** _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel