linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Mathieu Poirier <mathieu.poirier@linaro.org>
To: Arnaud POULIQUEN <arnaud.pouliquen@st.com>
Cc: bjorn.andersson@linaro.org, ohad@wizery.com,
	mcoquelin.stm32@gmail.com, alexandre.torgue@st.com,
	loic.pallardy@st.com, linux-remoteproc@vger.kernel.org,
	linux-stm32@st-md-mailman.stormreply.com,
	linux-arm-kernel@lists.infradead.org,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH v2 12/12] remoteproc: stm32: Set synchronisation state machine if needed
Date: Fri, 1 May 2020 11:54:46 -0600	[thread overview]
Message-ID: <20200501175446.GF18004@xps15> (raw)
In-Reply-To: <defc59b2-4d64-a108-2e5e-ecc579f70a8b@st.com>

On Wed, Apr 29, 2020 at 04:47:19PM +0200, Arnaud POULIQUEN wrote:
> 
> 
> On 4/24/20 10:25 PM, Mathieu Poirier wrote:
> > Set the flags and operations to use if the M4 has been started
> > by another entity than the remoteproc core.
> > 
> > Signed-off-by: Mathieu Poirier <mathieu.poirier@linaro.org>
> > ---
> >  drivers/remoteproc/stm32_rproc.c | 16 +++++++++++++++-
> >  1 file changed, 15 insertions(+), 1 deletion(-)
> > 
> > diff --git a/drivers/remoteproc/stm32_rproc.c b/drivers/remoteproc/stm32_rproc.c
> > index dcae6103e3df..02dad3f51c7a 100644
> > --- a/drivers/remoteproc/stm32_rproc.c
> > +++ b/drivers/remoteproc/stm32_rproc.c
> > @@ -598,13 +598,20 @@ static struct rproc_ops st_rproc_ops = {
> >  	.get_boot_addr	= rproc_elf_get_boot_addr,
> >  };
> >  
> > -static __maybe_unused struct rproc_ops st_rproc_sync_ops = {
> > +static struct rproc_ops st_rproc_sync_ops = {
> >  	.start		= stm32_rproc_sync_start,
> >  	.stop		= stm32_rproc_stop,
> > +	.kick		= stm32_rproc_kick,
> 
> Seems independent of the path.

I agree - on the flip side I didn't find a better place to put it.  Had I did a
one line patch someone would have asked me to stuff it somewhere.  I'll have
another look to see if I can find something decent.

> 
> >  	.parse_fw       = stm32_rproc_sync_parse_fw,
> >  	.find_loaded_rsc_table = stm32_rproc_sync_elf_find_loaded_rsc_table,
> >  };
> >  
> > +static struct rproc_sync_flags st_sync_flags = {
> > +	.on_init = true, /* sync with MCU when the kernel boots */
> > +	.after_stop = false, /* don't resync with MCU if stopped from sysfs */
> > +	.after_crash = false, /* don't resync with MCU after a crash */
> > +};
> > +
> could be const

If I do make this a const I'll have to move the call to
rproc_set_state_machine() inside the "if (state == M4_STATE_CRUN)".  It also
means that people won't be able to make dynamic adjustment to the
synchronisation states based on specifics discovered at probe() time.  They will
need to declare different synchronisation ops for all the potential scenarios.

I don't have a strong opinion on any of this.  I'll wait a little to see what
other people think.  If nobody chimes in I'll make this a const in the next
revision.

> 
> >  static const struct of_device_id stm32_rproc_match[] = {
> >  	{ .compatible = "st,stm32mp1-m4" },
> >  	{},
> > @@ -803,6 +810,7 @@ static int stm32_rproc_probe(struct platform_device *pdev)
> >  	struct stm32_rproc *ddata;
> >  	struct device_node *np = dev->of_node;
> >  	struct rproc *rproc;
> > +	struct rproc_sync_flags sync_flags = {0};
> >  	unsigned int state;
> >  	bool auto_boot = false;
> >  	int ret;
> > @@ -837,11 +845,17 @@ static int stm32_rproc_probe(struct platform_device *pdev)
> >  	}
> >  
> >  	if (state == M4_STATE_CRUN) {
> > +		auto_boot = true;
> > +		sync_flags = st_sync_flags;
> 
> seems an useless copy 
> 
> Regards,
> Arnaud
> 
> >  		ret = stm32_rproc_get_loaded_rsc_table(pdev, ddata);
> >  		if (ret)
> >  			goto free_rproc;
> >  	}
> >  
> > +	ret = rproc_set_state_machine(rproc, &st_rproc_sync_ops, sync_flags);
> > +	if (ret)
> > +		goto free_rproc;
> > +
> >  	rproc->auto_boot = auto_boot;
> >  	rproc->has_iommu = false;
> >  	ddata->workqueue = create_workqueue(dev_name(dev));
> > 

  reply	other threads:[~2020-05-01 17:54 UTC|newest]

Thread overview: 30+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-04-24 20:24 [PATCH v2 00/12] remoteproc: stm32: Add support for synchronising with M4 Mathieu Poirier
2020-04-24 20:24 ` [PATCH v2 01/12] remoteproc: stm32: Decouple rproc from memory translation Mathieu Poirier
2020-05-14  4:57   ` Bjorn Andersson
2020-04-24 20:24 ` [PATCH v2 02/12] remoteproc: stm32: Request IRQ with platform device Mathieu Poirier
2020-05-14  4:57   ` Bjorn Andersson
2020-04-24 20:24 ` [PATCH v2 03/12] remoteproc: stm32: Decouple rproc from DT parsing Mathieu Poirier
2020-04-29 13:37   ` Arnaud POULIQUEN
2020-04-30 20:58     ` Mathieu Poirier
2020-05-14  4:59   ` Bjorn Andersson
2020-04-24 20:24 ` [PATCH v2 04/12] remoteproc: stm32: Remove memory translation " Mathieu Poirier
2020-05-14  5:03   ` Bjorn Andersson
2020-04-24 20:24 ` [PATCH v2 05/12] remoteproc: stm32: Parse syscon that will manage M4 synchronisation Mathieu Poirier
2020-05-14  5:03   ` Bjorn Andersson
2020-04-24 20:24 ` [PATCH v2 06/12] remoteproc: stm32: Get coprocessor state Mathieu Poirier
2020-04-29 13:38   ` Arnaud POULIQUEN
2020-05-01 17:40     ` Mathieu Poirier
2020-04-24 20:25 ` [PATCH v2 07/12] remoteproc: stm32: Get loaded resource table for synchronisation Mathieu Poirier
2020-04-24 20:25 ` [PATCH v2 08/12] remoteproc: stm32: Introduce new start ops " Mathieu Poirier
2020-04-29 14:50   ` Arnaud POULIQUEN
2020-04-24 20:25 ` [PATCH v2 09/12] remoteproc: stm32: Update M4 state in stm32_rproc_stop() Mathieu Poirier
2020-04-29 14:52   ` Arnaud POULIQUEN
2020-04-24 20:25 ` [PATCH v2 10/12] remoteproc: stm32: Introduce new parse fw ops for synchronisation Mathieu Poirier
2020-05-14  5:13   ` Bjorn Andersson
2020-04-24 20:25 ` [PATCH v2 11/12] remoteproc: stm32: Introduce new loaded rsc " Mathieu Poirier
2020-05-14  5:15   ` Bjorn Andersson
2020-04-24 20:25 ` [PATCH v2 12/12] remoteproc: stm32: Set synchronisation state machine if needed Mathieu Poirier
2020-04-29 14:47   ` Arnaud POULIQUEN
2020-05-01 17:54     ` Mathieu Poirier [this message]
2020-04-29 15:08 ` [PATCH v2 00/12] remoteproc: stm32: Add support for synchronising with M4 Arnaud POULIQUEN
2020-05-01 17:59   ` Mathieu Poirier

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20200501175446.GF18004@xps15 \
    --to=mathieu.poirier@linaro.org \
    --cc=alexandre.torgue@st.com \
    --cc=arnaud.pouliquen@st.com \
    --cc=bjorn.andersson@linaro.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-remoteproc@vger.kernel.org \
    --cc=linux-stm32@st-md-mailman.stormreply.com \
    --cc=loic.pallardy@st.com \
    --cc=mcoquelin.stm32@gmail.com \
    --cc=ohad@wizery.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).