Received: by 2002:a05:6a10:6744:0:0:0:0 with SMTP id w4csp472659pxu; Fri, 23 Oct 2020 05:59:35 -0700 (PDT) X-Google-Smtp-Source: ABdhPJyxlcB/+gSOW9qyht+TGKpdc3dQU6n0xBH9L0ynw1VZbn3UTdJwBlwNErW+gpZvvLgNsY9B X-Received: by 2002:a17:906:3150:: with SMTP id e16mr1802572eje.266.1603457975065; Fri, 23 Oct 2020 05:59:35 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1603457975; cv=none; d=google.com; s=arc-20160816; b=cVO3wKVK44ErpxsvqpQjcMlvRFneh2DRTCv8QVIYXtQfplNCG1YRN/YpTSdDjcjhIA XSr5VBYri301BpyVEpO3ovjRxMGQixRHEiIDFWMgQN/1abSWBgluOpV4GrNx79UXgy+B 6e6akoEFKcrksEkE59WBXdivbvnLIjxUmfP+44BpsNtBmfkokoXzon1fmi/J7Fo/aj4S UPkEJSducS6xP8sXn/3Opid30b16mURsZ0Uj+uHZFcgACKvIrWjsnAyePtZtWDyMa0J8 xiC22ztLeoBgnvRKkjAztiZgZngLryP+uCKnQIf42gNkuMP5N252G9v11R/jTobs16W1 q+7A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-disposition:mime-version :references:message-id:subject:cc:to:from:date:dkim-signature; bh=+wVwzNPq/m5a8z79nf57WeG0wpvPOYgMcQgxD6E+uTI=; b=m5h2KBGEbO1Gc+xobl5V9ZBAeCrCJ9aiIQLMFs2b5GBUoBxIe8DaOTCqgJISOclITO Sbtf4gDhznEWZHJyEkPjDhYYCw3th0ebRbYH/ZkcjaAGm9tgL7U1R/8DL1EHzXXFP16k SBVfjcUJW1NF8JiJxxo1R5MLv6dY605+1QaqbuC2PmK/kvqO9Gh/5JpyCzb3NZhBHGC2 4U6NzRDHdeW8/S3y2x5HX+jR9YeFeErgsveCvaGyB9HYq0yGlcXU8jpLhYL1srMzxh83 ZgFg2SNNTPahZ/6206cohbZus170dwmx9XWrGG2FrhWhGACOLKzj3qhMKvU3uoLN75dM T6Vw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linaro.org header.s=google header.b=za5mhyMS; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linaro.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id ec23si775016ejb.575.2020.10.23.05.59.13; Fri, 23 Oct 2020 05:59:35 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@linaro.org header.s=google header.b=za5mhyMS; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linaro.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S372480AbgJVVvq (ORCPT + 99 others); Thu, 22 Oct 2020 17:51:46 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:45426 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S2897894AbgJVVvq (ORCPT ); Thu, 22 Oct 2020 17:51:46 -0400 Received: from mail-pf1-x441.google.com (mail-pf1-x441.google.com [IPv6:2607:f8b0:4864:20::441]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id EB04CC0613CF for ; Thu, 22 Oct 2020 14:51:45 -0700 (PDT) Received: by mail-pf1-x441.google.com with SMTP id e7so2080457pfn.12 for ; Thu, 22 Oct 2020 14:51:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=+wVwzNPq/m5a8z79nf57WeG0wpvPOYgMcQgxD6E+uTI=; b=za5mhyMSIBmhfe83oq+5Dt3diKbGLhXKkTuTXMsGC2HqNgttYgcXVS6/wZ9VvBQ7RE aD9RRqORvUVLNS+/k4iv/UXHamoabW7gpiNW7h62VZ9vInIO0lMmdQk4fW+p6IHi31NV 29LqJs4DD/97ykDGqUgWy0DSds/FzdbCEAx2bcN/28o9GiDyO5UWqVEoRgJm0NoB1Aag RYnlh/Q9uKrLqaXmhwDEP7c5VQSp+f7jasAY8X799p3X3OgoY4dKcjGULx5T76UN7bYb m31Addwx8crKcNjhKTqXPx/gvhSy1UFVPMpjI73adp0VxeS643DrtonLPgns5XWUEv0D 7gsA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=+wVwzNPq/m5a8z79nf57WeG0wpvPOYgMcQgxD6E+uTI=; b=E610w3jl7XBSFsY38QhIfBMxWFINfjB8jo1ICcGuUChKD9QUlK3lJAY+ILRI0eczqK k6Wsxdlq12ni0MnuZ7fetbrs7hpxgSrA61v3wW57ZTASAV0s6agOqwVGDUnYbg0jwoCr Yd8wydalknmlnwxQl0lPXerhjwCIR+q4c/+2uVTu+YCilKRIpIi5zO7UjXmLnWhGlZeG hbrmZZxoAQmq92yvxUNpJ/3CmtZCTn2pYLmsrdHbSFZBdB3R2DOjI++PsIAWjdfrFmzA H4FnSC13ewBtxIug59Xuzq8T9Er2AZligCEQYABuRcco4OH5C5bj579tt0KFM8NMQpvC NkpA== X-Gm-Message-State: AOAM531VM8EJwMYIV/Y5qpKgSPN0HnSMkQnyY8TlejUjTSwXLVjVdO6s 2196k/h2yjww4RFl5G/oEVPAjw== X-Received: by 2002:a17:90b:190a:: with SMTP id mp10mr4008741pjb.183.1603403505371; Thu, 22 Oct 2020 14:51:45 -0700 (PDT) Received: from xps15 (S0106002369de4dac.cg.shawcable.net. [68.147.8.254]) by smtp.gmail.com with ESMTPSA id e2sm2373014pgd.27.2020.10.22.14.51.44 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 22 Oct 2020 14:51:44 -0700 (PDT) Date: Thu, 22 Oct 2020 15:51:43 -0600 From: Mathieu Poirier To: Peng Fan Cc: "bjorn.andersson@linaro.org" , "ohad@wizery.com" , "linux-remoteproc@vger.kernel.org" , "linux-kernel@vger.kernel.org" Subject: Re: [PATCH 05/13] remoteproc: Add new detach() remoteproc operation Message-ID: <20201022215143.GA729430@xps15> References: <20200826164529.224476-1-mathieu.poirier@linaro.org> <20200826164529.224476-6-mathieu.poirier@linaro.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Peng - I restarting work on this topic. On Thu, Oct 15, 2020 at 01:37:42AM +0000, Peng Fan wrote: > > Subject: [PATCH 05/13] remoteproc: Add new detach() remoteproc operation > > > > Add an new detach() operation in order to support scenarios where the > > remoteproc core is going away but the remote processor is kept operating. > > This could be the case when the system is rebooted or when the platform > > driver is removed. > > > > Signed-off-by: Mathieu Poirier > > --- > > include/linux/remoteproc.h | 2 ++ > > 1 file changed, 2 insertions(+) > > > > diff --git a/include/linux/remoteproc.h b/include/linux/remoteproc.h index > > fe383392a821..1a57e165da2c 100644 > > --- a/include/linux/remoteproc.h > > +++ b/include/linux/remoteproc.h > > @@ -361,6 +361,7 @@ enum rsc_handling_status { > > * @start: power on the device and boot it > > * @stop: power off the device > > * @attach: attach to a device that his already powered up > > + * @detach: tell the remote processor that the core is going away > > * @kick: kick a virtqueue (virtqueue id given as a parameter) > > * @da_to_va: optional platform hook to perform address translations > > * @parse_fw: parse firmware to extract information (e.g. resource table) > > @@ -382,6 +383,7 @@ struct rproc_ops { > > int (*start)(struct rproc *rproc); > > int (*stop)(struct rproc *rproc); > > int (*attach)(struct rproc *rproc); > > + int (*detach)(struct rproc *rproc); > > void (*kick)(struct rproc *rproc, int vqid); > > void * (*da_to_va)(struct rproc *rproc, u64 da, size_t len); > > int (*parse_fw)(struct rproc *rproc, const struct firmware *fw); > > -- > > This look useful for i.MX8 partitioned case, M4 and A53 could reboot without > impacting the other. When A53 reboot, detach is invoked if I understand correct. You are correct (for this patchset). Since this heuristic is quite stringent we are contemplating different solutions that would allow platforms to decide what they want to do based on the usecase they care about. Thanks, Mathieu > > Reviewed-by: Peng Fan