Received: by 2002:a05:6902:102b:0:0:0:0 with SMTP id x11csp3862847ybt; Tue, 23 Jun 2020 12:40:51 -0700 (PDT) X-Google-Smtp-Source: ABdhPJyZSdqIEmLsaHe9yZ0j/00W+RtHH7KoN/6FVyRLwsYSswLpKf8PCw7oa02HhXFW+IE6BN55 X-Received: by 2002:aa7:dad6:: with SMTP id x22mr24013343eds.265.1592941250842; Tue, 23 Jun 2020 12:40:50 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1592941250; cv=none; d=google.com; s=arc-20160816; b=kjwFJ77KzQ92HdM6DT6TlzdhM6DcFtwWUaql723gttWLmUcWp2se+cyskBEqMph1DW l1rHuqvB2yVHfzk6KylbxDdhHTLuj2iU7LKG68YHYSQVakPPKJjujsDIkA3gH33/pctm TenmuuXWwhUgqMZ2Oc52cmfdOvobjv68Q2ubNzm/NDoqr8HO8TeEPrMFMWBOUaGv6Twd Rka6i8ewR7QBZLM8xq5oTGslBQyk2+lXRPlRjT9621QXxI7P6LKV++I/9tR0W0TwrP9e 81Bl/P6vtiF55pvfwAhzXOTkeVfM3yLciQf1fNCVjUn5HcjDptqEpcBu8Lpj65nQN1oy FJOw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:in-reply-to:content-disposition :mime-version:references:message-id:subject:cc:to:from:date :dkim-signature; bh=8tcoG/srDe41M/d7sumygMyJ7BaeM73/Bo5ylqI3GKA=; b=cRLutmdDwN9a7tYjtCOfWhOoPlcEKN5Ayfy6MVNcez7qz5FjkWyAClExQ5abSBdSRX hh0KPGYCkDIUGKP8N2GoriV5nSh9xPgUuJuHkNIs6x+ZE3ySbPJPhAecNCc1m6cAy3TF IHg8YWRnu8d9Xvwx0oIVqVdJ1agwF0aAe6cm5mB/CjmIN001B0WeymrGJPcmePMi675r KeZktE0PQbEzZELfQAr61WJ9T1Al/Ia1OuuSX7xnV20btmu5kwIZcCVBYfX0wsoRkF53 JmA1N/Z0tj8eRnb376v25D5IpU320wRA4XTrbCU+ugBwzUnZhvIaUMHUpGKsu/0BjEph ohXw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linaro.org header.s=google header.b="Cqkg6S/8"; 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 n15si11849097ejd.527.2020.06.23.12.40.27; Tue, 23 Jun 2020 12:40:50 -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="Cqkg6S/8"; 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 S2387502AbgFWThb (ORCPT + 99 others); Tue, 23 Jun 2020 15:37:31 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:45660 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1733220AbgFWTh3 (ORCPT ); Tue, 23 Jun 2020 15:37:29 -0400 Received: from mail-pf1-x444.google.com (mail-pf1-x444.google.com [IPv6:2607:f8b0:4864:20::444]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 78A2BC061573 for ; Tue, 23 Jun 2020 12:37:28 -0700 (PDT) Received: by mail-pf1-x444.google.com with SMTP id z63so10571508pfb.1 for ; Tue, 23 Jun 2020 12:37:28 -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=8tcoG/srDe41M/d7sumygMyJ7BaeM73/Bo5ylqI3GKA=; b=Cqkg6S/8/9qXa9Wew7R7+tLH85WimVGdrzM9LUVwPd7s+V25vQHgnxXWWCiQReHRFx 8fZONY8wJi90pYuiLeHlN6TWAUD9Dcss/PS8ZBlTuLPAoSCR26ewDjmztbjO4Ux2++3z W3gK/vzRiNCET6NC8a8lBWp4A63GFYjRoxFWSMnrPKlXOXrtasIlbTNDfUIKTdR4xgX2 Stokz60sbrxxGWsqbpSN+m6WLFdG0B5IvYd6JwYzPEa51FZBlN6/QdgphAyDBiaK2qne UGUAMTb9k5QtNzdGADHtHgJu6JAMMyW//r/acCrmE7jEuEuW7cpGQ89hzklUXgEURUjr ZmSQ== 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=8tcoG/srDe41M/d7sumygMyJ7BaeM73/Bo5ylqI3GKA=; b=I1XIE6UAG4tIBvkxJ1OVxFok/UgepWflKiRMwvAxuYcHrYj7QR4ld2J3R/Vj5Fx9UC XUn0bsw4YLkRH1gHt/Q66t76cu9YXrdNP3lmM8lSnic8D1LCQg5SYqKiGcqAVJd8fGZs I9caOe6s8sYVtZmHas/pWTLRDs18XTm3wAYCqWFP5xnDCRq0kUZNT5EX0jQR5hC4hNP4 +ZZ2isO//HUvgwyz8F0SZftE5/a/zAczKZzl/ZJm38gv105YdOrpKYlAH0Zso/bCSzrd mXmwihdE+rw24ORO8cMh7KGxTR+4Sf0jSQp+z6/g6GBvXTLZ1xHrO0MM4SZWPrN1uSR0 73Mw== X-Gm-Message-State: AOAM532XFz3z6qp48pu/+MFDKBbm3m6+pTEgg4Y2HhElZp9AmaLyVviS 3G6naYXVPs70fm9iUQRxyu4M6w== X-Received: by 2002:a63:fe0a:: with SMTP id p10mr13015187pgh.255.1592941047943; Tue, 23 Jun 2020 12:37:27 -0700 (PDT) Received: from xps15 (S0106002369de4dac.cg.shawcable.net. [68.147.8.254]) by smtp.gmail.com with ESMTPSA id n4sm18301557pfq.9.2020.06.23.12.37.26 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 23 Jun 2020 12:37:27 -0700 (PDT) Date: Tue, 23 Jun 2020 13:37:25 -0600 From: Mathieu Poirier To: Bjorn Andersson Cc: ohad@wizery.com, linux-remoteproc@vger.kernel.org, linux-kernel@vger.kernel.org, loic.pallardy@st.com, arnaud.pouliquen@st.com, s-anna@ti.com Subject: Re: [PATCH v4 3/9] remoteproc: Introducing function rproc_attach() Message-ID: <20200623193725.GA1908098@xps15> References: <20200601175139.22097-1-mathieu.poirier@linaro.org> <20200601175139.22097-4-mathieu.poirier@linaro.org> <20200622070727.GD149351@builder.lan> <20200622071804.GE149351@builder.lan> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20200622071804.GE149351@builder.lan> Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi, On Mon, Jun 22, 2020 at 12:18:04AM -0700, Bjorn Andersson wrote: > On Mon 22 Jun 00:07 PDT 2020, Bjorn Andersson wrote: > > > On Mon 01 Jun 10:51 PDT 2020, Mathieu Poirier wrote: > > > > > Introducing function rproc_attach() to enact the same actions as > > > rproc_start(), but without the steps related to the handling of > > > a firmware image. That way we can properly deal with scenarios > > > where the remoteproc core needs to attach with a remote processsor > > > that has been booted by another entity. > > > > > > Signed-off-by: Mathieu Poirier > > > --- > > > drivers/remoteproc/remoteproc_core.c | 42 ++++++++++++++++++++++++++++ > > > 1 file changed, 42 insertions(+) > > > > > > diff --git a/drivers/remoteproc/remoteproc_core.c b/drivers/remoteproc/remoteproc_core.c > > > index 9f04c30c4aaf..0b323f6b554b 100644 > > > --- a/drivers/remoteproc/remoteproc_core.c > > > +++ b/drivers/remoteproc/remoteproc_core.c > > > @@ -1370,6 +1370,48 @@ static int rproc_start(struct rproc *rproc, const struct firmware *fw) > > > return ret; > > > } > > > > > > +static int __maybe_unused rproc_attach(struct rproc *rproc) > > > +{ > > > + struct device *dev = &rproc->dev; > > > + int ret; > > > + > > > > For the case where we're going DETACHED -> RUNNING - > OFFLINE we > > need to consider the pm_runtime (and prepare/unprepare) state of the > > device as well... > > > > Missed that you do indeed pm_runtime_get() in the calling function, so I > think we're good on that part. Still need how to actually implement > that (and the prepare/unprepare), in particular if we're moving into > detaching a remoteproc. I had planned to look at the interaction between the PM runtime and prepare/unprepare callbacks later today. Depending on what I find I may end up modifying this patch... > > > > > Apart from that I think this looks good. > > > > Reviewed-by: Bjorn Andersson > > Regards, > Bjorn > > > Regards, > > Bjorn > > > > > + ret = rproc_prepare_subdevices(rproc); > > > + if (ret) { > > > + dev_err(dev, "failed to prepare subdevices for %s: %d\n", > > > + rproc->name, ret); > > > + goto out; > > > + } > > > + > > > + /* Attach to the remote processor */ > > > + ret = rproc_attach_device(rproc); > > > + if (ret) { > > > + dev_err(dev, "can't attach to rproc %s: %d\n", > > > + rproc->name, ret); > > > + goto unprepare_subdevices; > > > + } > > > + > > > + /* Start any subdevices for the remote processor */ > > > + ret = rproc_start_subdevices(rproc); > > > + if (ret) { > > > + dev_err(dev, "failed to probe subdevices for %s: %d\n", > > > + rproc->name, ret); > > > + goto stop_rproc; > > > + } > > > + > > > + rproc->state = RPROC_RUNNING; > > > + > > > + dev_info(dev, "remote processor %s is now attached\n", rproc->name); > > > + > > > + return 0; > > > + > > > +stop_rproc: > > > + rproc->ops->stop(rproc); > > > +unprepare_subdevices: > > > + rproc_unprepare_subdevices(rproc); > > > +out: > > > + return ret; > > > +} > > > + > > > /* > > > * take a firmware and boot a remote processor with it. > > > */ > > > -- > > > 2.20.1 > > >