Received: by 2002:a05:6a10:16a7:0:0:0:0 with SMTP id gp39csp2156884pxb; Sat, 21 Nov 2020 10:52:01 -0800 (PST) X-Google-Smtp-Source: ABdhPJynO/pf61pns8WztKrWCO6Lsr8flOX6KJjdqNiBETYOC7IkTbWUTZbRwz4AFV2PEbxwriV9 X-Received: by 2002:a05:6402:1243:: with SMTP id l3mr17053970edw.151.1605984720899; Sat, 21 Nov 2020 10:52:00 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1605984720; cv=none; d=google.com; s=arc-20160816; b=g6KzYrF5GAapgcAlaWKBrmogHnZIdYHYF9ztsy4bTrQQeT4VeT59BgjMjVc/NqckU+ 4KMRMQ9pgVgFwJ6WK5jOfnOkHNY+w0oqI20XCt60rSbPH7lZ65aQ2fp+slUYEgjLP2F0 iIwa8MYX3yNOpC5q9x0JrCsNmZRxp1O6CygeSG8bnuKdxbG5ivtFYjZ01aLA9JUKkmcM eCYBqcdCYGIg7yt/zEbcYiiGPKr8AsYjVo7z2TEcusQqo7rZGyxr9FFg4lVf4NSXXZx0 8bLVWlqalR1zv6wupG/49aWysAAWiPBCq+FEZfdEj1Y3chyKagZFMmI/NSO5cmgPQeN1 wmgg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :references:in-reply-to:message-id:cc:to:subject:from:date; bh=pS5JvilahlIVHRYUNEC3AsgdQIj8BjDN0/TUP4n0xds=; b=zSdZS8lP2fYEgyHLIDTxLi9dVQE1fo0LTl6cPUEWvJHr44oMGBH8L8KbAmNAP8mDYc 8dT7C6JsEJ6EEeXqDIxNCw3YO6eY3Q6mQJxkyKIsrCd9XPba2YdF2aHR97iuqh6tTaeu +udxqK5o0i9fFp+lWIT22ydeVFhLNF0JHCEbCkeD5yQpuwpnslAjHeqjVImXBVZNPKUV CXlyNRxcAaOcs1lQtIfbueUM2AQtpieBUclzkJCGySekBF1t4EEK7WS7WVrjqo//AFVK owC0ySzqoAkmqqda1MoZhw/FQCjjaJ4sH64QYFslzRHgw9K/fcHH0ZRC+aONzalKebpw /Nkg== ARC-Authentication-Results: i=1; mx.google.com; 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=fail (p=NONE sp=NONE dis=NONE) header.from=crapouillou.net Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id s16si3821206edt.488.2020.11.21.10.51.38; Sat, 21 Nov 2020 10:52:00 -0800 (PST) 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; 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=fail (p=NONE sp=NONE dis=NONE) header.from=crapouillou.net Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727919AbgKUSsF convert rfc822-to-8bit (ORCPT + 99 others); Sat, 21 Nov 2020 13:48:05 -0500 Received: from aposti.net ([89.234.176.197]:50982 "EHLO aposti.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726305AbgKUSsE (ORCPT ); Sat, 21 Nov 2020 13:48:04 -0500 Date: Sat, 21 Nov 2020 18:47:48 +0000 From: Paul Cercueil Subject: Re: [PATCH] remoteproc: Add module parameter 'auto_boot' To: Suman Anna Cc: Mathieu Poirier , Ohad Ben-Cohen , Bjorn Andersson , od@zcrc.me, linux-remoteproc@vger.kernel.org, linux-kernel@vger.kernel.org Message-Id: In-Reply-To: <65e4ed08-9709-533f-57bb-cb570165a461@ti.com> References: <20201115115056.83225-1-paul@crapouillou.net> <20201120223701.GF4137289@xps15> <65e4ed08-9709-533f-57bb-cb570165a461@ti.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1; format=flowed Content-Transfer-Encoding: 8BIT Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Suman, Le ven. 20 nov. 2020 ? 17:06, Suman Anna a ?crit : > Hi Paul, > > On 11/20/20 4:37 PM, Mathieu Poirier wrote: >> Hi Paul, >> >> On Sun, Nov 15, 2020 at 11:50:56AM +0000, Paul Cercueil wrote: >>> Until now the remoteproc core would always default to trying to >>> boot the >>> remote processor at startup. The various remoteproc drivers could >>> however override that setting. >>> >>> Whether or not we want the remote processor to boot, really >>> depends on >>> the nature of the processor itself - a processor built into a WiFi >>> chip >>> will need to be booted for the WiFi hardware to be usable, for >>> instance, >>> but a general-purpose co-processor does not have any >>> predeterminated >>> function, and as such we cannot assume that the OS will want the >>> processor to be booted - yet alone that we have a single do-it-all >>> firmware to load. >>> >> >> If I understand correctly you have various remote processors that >> use the same firmware >> but are serving different purposes - is this correct? >> >>> Add a 'auto_boot' module parameter that instructs the remoteproc >>> whether >>> or not it should auto-boot the remote processor, which will >>> default to >>> "true" to respect the previous behaviour. >>> >> >> Given that the core can't be a module I wonder if this isn't >> something that >> would be better off in the specific platform driver or the device >> tree... Other >> people might have an opinion as well. > > I agree. Even it is a module, all it is setting up is default > behavior, and > doesn't buy you much. If you have one or more remoteproc drivers > supporting > different instances, and each one wants different behavior, you would > have to > customize it in the drivers anyway. ST drivers are customizing this > using a DT flag. Devicetree is supposed to describe the hardware, not how you're supposed to use the hardware... > Given that the individual platform drivers have to be modules, is > there any > issue in customizing this in your platform driver? No, I can patch the platform driver instead, but to me it clearly is a core issue. Cheers, -Paul > regards > Suman > >> >> Thanks, >> Mathieu >> >>> Signed-off-by: Paul Cercueil >>> --- >>> drivers/remoteproc/remoteproc_core.c | 7 ++++++- >>> 1 file changed, 6 insertions(+), 1 deletion(-) >>> >>> diff --git a/drivers/remoteproc/remoteproc_core.c >>> b/drivers/remoteproc/remoteproc_core.c >>> index dab2c0f5caf0..687b1bfd49db 100644 >>> --- a/drivers/remoteproc/remoteproc_core.c >>> +++ b/drivers/remoteproc/remoteproc_core.c >>> @@ -44,6 +44,11 @@ >>> >>> #define HIGH_BITS_MASK 0xFFFFFFFF00000000ULL >>> >>> +static bool auto_boot = true; >>> +module_param(auto_boot, bool, 0400); >>> +MODULE_PARM_DESC(auto_boot, >>> + "Auto-boot the remote processor [default=true]"); >>> + >>> static DEFINE_MUTEX(rproc_list_mutex); >>> static LIST_HEAD(rproc_list); >>> static struct notifier_block rproc_panic_nb; >>> @@ -2176,7 +2181,7 @@ struct rproc *rproc_alloc(struct device >>> *dev, const char *name, >>> return NULL; >>> >>> rproc->priv = &rproc[1]; >>> - rproc->auto_boot = true; >>> + rproc->auto_boot = auto_boot; >>> rproc->elf_class = ELFCLASSNONE; >>> rproc->elf_machine = EM_NONE; >>> >>> -- >>> 2.29.2 >>> >