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 D57C5C32793 for ; Wed, 18 Jan 2023 17:25:20 +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:MIME-Version:References: Message-ID:Subject:Cc:To:From:Date:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=iYOM/djxv/Hr7r/lqx1eQP7d33Gr2RLtzUFYk3TaMTQ=; b=p4kGQbrDQ8LQSZ Uaepi3bPM+DpeN3HXFbBiCGAuB05C2IbehCF0F99iCXJWFZDzBnku5wAPXYQrb0mSMlp/nM+hQytY vx8qYfim3zmR1ElAeQgm+hZpn7VO1FwDzouEbwnSYQMGplOwK4Dn0mH5LtypL5mY361wmycoXS0pd CH5ox+FPyEwRPFtdLeDYXK8jglnoK7EFBuqaAK+gI31gf6CEGZ+9t8yK3sBhwAYwAnWakhnGzXkf5 LOC28wHaotLJUQZ3fodccknsA2ik+kCTpSZ4lu/H/Azm9qXkBnxEFysq816LRAoUEFoajqk8qe6ys b0OT/2QrC8FL+oPocmng==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1pICAj-0020iv-Bd; Wed, 18 Jan 2023 17:24:25 +0000 Received: from mail-pj1-x102d.google.com ([2607:f8b0:4864:20::102d]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1pICAf-0020i0-T4 for linux-arm-kernel@lists.infradead.org; Wed, 18 Jan 2023 17:24:23 +0000 Received: by mail-pj1-x102d.google.com with SMTP id a14-20020a17090a70ce00b00229a2f73c56so3074385pjm.3 for ; Wed, 18 Jan 2023 09:24:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=/85bp1vP3MXzWpfyCclueqY4UFzXVuo4Z5G90xwNDEM=; b=oeQXKrGvKYFACksCj40O6ZOV+KsKYJTJcM15HKNJi2nGzi8DOXHzkQNmZAavcl1Zdr Nl9RNhA4kekUTTnQ7BntkiLaM946I2WRsNS6OeMgQBkpr6CqZ3Jo7njS8trzAz+OobJO R89kFIJOdngL4Bw3xngUPHhUQ/xsLCzJt8asUpWzNzuLYT8lwUUicK4InXO1Pu2DpzWm nzJALoexrT2nz568WkEl6I0OA0uLlH8yHJHNG7zpqJCin2ovij3MJQwQaUl65nDHEp2q 6T9UIvIPu7+oe8iQNx5H3QXxtSSxMf+BjJzELJ8O7aNBBD8x+TFyUXpBhke8Pg5DQ2hI k0Vw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=/85bp1vP3MXzWpfyCclueqY4UFzXVuo4Z5G90xwNDEM=; b=LSeZlOI6JMRQfG8O9Cb28qY2PxyUmejoLdGPBn/3VAtI+2VYhbqf5+LX/DibKpXt7c QN3N6NZAqV+ACSScT9nTQooKZmzg90knmQnhhsVFL0Ohwn5ckiBIWsVvTcmJphHfFklN Emq7Im8e7wkzWM/IzEC5/xl1/cB3zANKygDebk6iUHZ17HhBpbFmxAOyoLjsvG+iQD1K gVvN/E8+zwDaRTjyQZN/9iwHhzqz2UwyzcaaWPAFjlA33ohRkoAWvVZUmQqPZ9RJeK6a jhvZ2bmvAP/LM2ejBfEqkyp44e8nB/7C888/loNxdm+RlVb941p0YkMjI3tPtZjMLofF NLNQ== X-Gm-Message-State: AFqh2kqYa9Y+BttSBtqlaf8sHwKv+zPkuZwL2op/3eHzZZph6jhPDcbv FmeJBI48mE81fYWmSga+9+246g== X-Google-Smtp-Source: AMrXdXtiocEKCjs8eTcEsQA32wuVtG465QX3tzHebeE/Is8RJXfNhsdVvaN/MEfsH7q73N8hC/wbxQ== X-Received: by 2002:a05:6a21:3294:b0:a4:414c:84c5 with SMTP id yt20-20020a056a21329400b000a4414c84c5mr10069900pzb.12.1674062659386; Wed, 18 Jan 2023 09:24:19 -0800 (PST) Received: from p14s ([2604:3d09:148c:c800:4866:b240:c533:54ae]) by smtp.gmail.com with ESMTPSA id z7-20020a63e547000000b00476d1385265sm19156114pgj.25.2023.01.18.09.24.17 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 18 Jan 2023 09:24:18 -0800 (PST) Date: Wed, 18 Jan 2023 10:24:16 -0700 From: Mathieu Poirier To: "Iuliana Prodan (OSS)" Cc: Bjorn Andersson , Shawn Guo , Sascha Hauer , "S.J. Wang" , Fabio Estevam , Daniel Baluta , Iuliana Prodan , linux-imx , linux-remoteproc@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, Pengutronix Kernel Team Subject: Re: [PATCH v3] remoteproc: imx_dsp_rproc: add module parameter to ignore ready flag from remote processor Message-ID: <20230118172416.GB3394216@p14s> References: <20230117110357.15091-1-iuliana.prodan@oss.nxp.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20230117110357.15091-1-iuliana.prodan@oss.nxp.com> X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20230118_092421_963446_7B19B783 X-CRM114-Status: GOOD ( 26.46 ) 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 Iuliana, On Tue, Jan 17, 2023 at 01:03:57PM +0200, Iuliana Prodan (OSS) wrote: > From: Iuliana Prodan > > There are cases when we want to test a simple "hello world" > application on the DSP and we don't have IPC between the cores. > Therefore, skip the wait for remote processor to start. > > Added "ignore_dsp_ready" flag while inserting the module to ignore > remote processor reply after start. > By default, this is off - do not ignore reply from rproc. > > Signed-off-by: Iuliana Prodan > > --- > Changes since v2 > - s/ignoreready/ignore_dsp_ready > > Changes since v1 > - change BIT(31) to BIT(1) for REMOTE_SKIP_WAIT > > --- > drivers/remoteproc/imx_dsp_rproc.c | 17 +++++++++++++++++ > 1 file changed, 17 insertions(+) > > diff --git a/drivers/remoteproc/imx_dsp_rproc.c b/drivers/remoteproc/imx_dsp_rproc.c > index 95da1cbefacf..22e2ef068c67 100644 > --- a/drivers/remoteproc/imx_dsp_rproc.c > +++ b/drivers/remoteproc/imx_dsp_rproc.c > @@ -26,9 +26,20 @@ > #include "remoteproc_elf_helpers.h" > #include "remoteproc_internal.h" > > +#define IMX_DSP_IGNORE_REMOTE_READY 0 > + > +/* > + * Module parameters > + */ > +static unsigned int imx_dsp_rproc_ignore_ready = IMX_DSP_IGNORE_REMOTE_READY; Static variables are initialised to '0' and as such this is not needed. > +module_param_named(ignore_dsp_ready, imx_dsp_rproc_ignore_ready, int, 0644); > +MODULE_PARM_DESC(ignore_dsp_ready, > + "Ignore remote proc reply after start, default is 0 (off)."); > + > #define DSP_RPROC_CLK_MAX 5 > > #define REMOTE_IS_READY BIT(0) > +#define REMOTE_SKIP_WAIT BIT(1) > #define REMOTE_READY_WAIT_MAX_RETRIES 500 > > /* att flags */ > @@ -285,6 +296,9 @@ static int imx_dsp_rproc_ready(struct rproc *rproc) > if (!priv->rxdb_ch) > return 0; > > + if (priv->flags & REMOTE_SKIP_WAIT) > + return 0; > + This looks very hackish to me... Here priv->rxdb_ch is valid and as such the DB mailbox has been setup, which contradicts the commit log where it is stated that "we don't have IPC between cores". Moreover, the commit log mentions to "skip the wait for remote processor to start". How can the remote processor executed an sample application if it is not ready? Lastly, is there even a need to call imx_dsp_rproc_mbox_init() if an IPC is not needed? I'm fine with the module parameter but would much rather see a solution that does not configure any kind of IPC related mechanic when it is not needed. Thanks, Mathieu > for (i = 0; i < REMOTE_READY_WAIT_MAX_RETRIES; i++) { > if (priv->flags & REMOTE_IS_READY) > return 0; > @@ -903,6 +917,9 @@ static int imx_dsp_rproc_probe(struct platform_device *pdev) > priv->rproc = rproc; > priv->dsp_dcfg = dsp_dcfg; > > + if (imx_dsp_rproc_ignore_ready) > + priv->flags |= REMOTE_SKIP_WAIT; > + > dev_set_drvdata(dev, rproc); > > INIT_WORK(&priv->rproc_work, imx_dsp_rproc_vq_work); > -- > 2.17.1 > _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel