All of lore.kernel.org
 help / color / mirror / Atom feed
From: Mathieu Poirier <mathieu.poirier@linaro.org>
To: Suman Anna <s-anna@ti.com>
Cc: Loic PALLARDY <loic.pallardy@st.com>,
	"bjorn.andersson@linaro.org" <bjorn.andersson@linaro.org>,
	"ohad@wizery.com" <ohad@wizery.com>,
	"peng.fan@nxp.com" <peng.fan@nxp.com>,
	Arnaud POULIQUEN <arnaud.pouliquen@st.com>,
	Fabien DESSENNE <fabien.dessenne@st.com>,
	"linux-remoteproc@vger.kernel.org"
	<linux-remoteproc@vger.kernel.org>
Subject: Re: [PATCH v2 00/17] remoteproc: Add support for synchronisation with MCU
Date: Wed, 1 Apr 2020 15:39:53 -0600	[thread overview]
Message-ID: <20200401213953.GF17383@xps15> (raw)
In-Reply-To: <172c8ba5-f365-5e63-cc39-94dfe1bafa9f@ti.com>

On Tue, Mar 31, 2020 at 05:51:44PM -0500, Suman Anna wrote:
> Hi Mathieu,
> 
> On 3/27/20 12:20 PM, Loic PALLARDY wrote:
> > Hi Mathieu,
> > 
> >>
> >> This is the second revision of this set that tries to address the
> >> problem of synchronising with an MCU with as much flexibility as
> >> possible.
> >>
> >> New in this revision is a fix for a couple of bugs I found while
> >> testing things.  First with the helper macro in patch 09 and the
> >> suppression of a boot message when synchronising with an MCU
> >> in patch 12.  I have completely removed what used to be patch 18,
> >> the example on how to use the new API.  This will be the subject
> >> of an upcoming patchset.
> >>
> >> Tested on ST's mp157c platform.  Applies on v5.6-rc7 to keep things
> >> simple.
> > 
> > Thanks Mathieu for the 2 series. I tested on my STM32MP157-DK2 the different
> > synchronization use cases (on_init, after_stop, after_crash), mixing the values and
> > I succeed to start/stop/restart M4 coprocessor with or without reloading firmware
> > according to sync values. (I only applied the correction I proposed in patch 16 review
> > to allow to resync with a preloaded or an already running coprocessor.
> > 
> > Regards,
> > Loic
> >>
> >> Comments would be much appreciated.
> 
> Thank you for the enhanced series to implement the logic in remoteproc
> core. I have provided my comments on most of the patches.
> 
> Overall, I can see my early-boot scenarios work with the series, and the
> slightly different userspace-loading support usecase would need some
> additional support.
> 
> As I commented on patch 1 in v1, I would rather reuse the the generic
> "rproc" instead of adding a new "mcu" terminology to code.. Let's just
> stick with the rproc

You got it.

> 
> Another thing I would prefer (echoing my comments on patch 7) is to just
> use an API for modifying the sync states, that can be used between
> rproc_alloc() and rproc_add(). The state-machine really doesn't kick in
> until rproc_add() is invoked. The memory for the driver private rproc
> structure is allocated using rproc_alloc() normally, and most of the
> DT-parsing in platform drivers is generally done directly into this
> allocated memory. I see it a bit cumbersome having to maintain a
> separate structure, and then do a memcpy, especially given that the
> rproc_alloc_state_machine() logic requires that you detect the state
> before calling the rproc_alloc().

You raise an interesting point... As my work on the mp157c [1] proved, mandating
to know if the core should sync before calling rproc_alloc_state_machine()
requires a fair amount of refactoring.  I will follow your recommendation for
the next revision.

Thanks,
Mathieu


[1]. https://patchwork.kernel.org/project/linux-remoteproc/list/?series=261083

> 
> regards
> Suman
> 
> >>
> >> Thanks,
> >> Mathieu
> >>
> >> Mathieu Poirier (17):
> >>   remoteproc: Add new operation and state machine for MCU
> >>     synchronisation
> >>   remoteproc: Introduce function rproc_set_mcu_sync_state()
> >>   remoteproc: Split firmware name allocation from rproc_alloc()
> >>   remoteproc: Split rproc_ops allocation from rproc_alloc()
> >>   remoteproc: Get rid of tedious error path
> >>   remoteproc: Introduce function rproc_alloc_internals()
> >>   remoteproc: Introduce function rproc_alloc_state_machine()
> >>   remoteproc: Allocate synchronisation state machine
> >>   remoteproc: Call the right core function based on synchronisation
> >>     state
> >>   remoteproc: Decouple firmware load and remoteproc booting
> >>   remoteproc: Repurpose function rproc_trigger_auto_boot()
> >>   remoteproc: Rename function rproc_fw_boot()
> >>   remoteproc: Introducting new functions to start and stop an MCU
> >>   remoteproc: Refactor function rproc_trigger_recovery()
> >>   remoteproc: Correctly deal with MCU synchronisation when changing FW
> >>     image
> >>   remoteproc: Correctly deal with MCU synchronisation when changing
> >>     state
> >>   remoteproc: Make MCU synchronisation state changes on stop and crashed
> >>
> >>  drivers/remoteproc/remoteproc_core.c     | 387 ++++++++++++++++++-----
> >>  drivers/remoteproc/remoteproc_debugfs.c  |  31 ++
> >>  drivers/remoteproc/remoteproc_internal.h |  91 ++++--
> >>  drivers/remoteproc/remoteproc_sysfs.c    |  57 +++-
> >>  include/linux/remoteproc.h               |  28 +-
> >>  5 files changed, 487 insertions(+), 107 deletions(-)
> >>
> >> --
> >> 2.20.1
> > 
> 

      reply	other threads:[~2020-04-01 21:39 UTC|newest]

Thread overview: 73+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-03-24 21:45 [PATCH v2 00/17] remoteproc: Add support for synchronisation with MCU Mathieu Poirier
2020-03-24 21:45 ` [PATCH v2 01/17] remoteproc: Add new operation and state machine for MCU synchronisation Mathieu Poirier
2020-03-30 22:46   ` Suman Anna
2020-03-30 22:49     ` Suman Anna
2020-04-01 21:53       ` Mathieu Poirier
2020-04-09 21:38         ` Suman Anna
2020-04-09 21:38           ` Suman Anna
2020-03-24 21:45 ` [PATCH v2 02/17] remoteproc: Introduce function rproc_set_mcu_sync_state() Mathieu Poirier
2020-03-30 22:55   ` Suman Anna
2020-03-24 21:45 ` [PATCH v2 03/17] remoteproc: Split firmware name allocation from rproc_alloc() Mathieu Poirier
2020-03-27 11:05   ` Loic PALLARDY
2020-03-30 19:47     ` Suman Anna
2020-04-01 21:58       ` Mathieu Poirier
2020-03-24 21:45 ` [PATCH v2 04/17] remoteproc: Split rproc_ops " Mathieu Poirier
2020-03-30 19:54   ` Suman Anna
2020-03-24 21:45 ` [PATCH v2 05/17] remoteproc: Get rid of tedious error path Mathieu Poirier
2020-03-30 20:31   ` Suman Anna
2020-03-24 21:45 ` [PATCH v2 06/17] remoteproc: Introduce function rproc_alloc_internals() Mathieu Poirier
2020-03-27 11:10   ` Loic PALLARDY
2020-03-30 20:38     ` Suman Anna
2020-04-01 20:29       ` Mathieu Poirier
2020-04-09 21:53         ` Suman Anna
2020-03-30 23:07     ` Mathieu Poirier
2020-03-24 21:45 ` [PATCH v2 07/17] remoteproc: Introduce function rproc_alloc_state_machine() Mathieu Poirier
2020-03-27 13:12   ` Loic PALLARDY
2020-03-30 23:10     ` Suman Anna
2020-04-01 20:41       ` Mathieu Poirier
2020-04-09 18:35         ` Suman Anna
2020-03-30 23:13     ` Mathieu Poirier
2020-03-24 21:45 ` [PATCH v2 08/17] remoteproc: Allocate synchronisation state machine Mathieu Poirier
2020-03-27 13:47   ` Loic PALLARDY
2020-03-30 23:16     ` Mathieu Poirier
2020-03-30 23:20     ` Suman Anna
2020-04-01 20:46       ` Mathieu Poirier
2020-03-24 21:45 ` [PATCH v2 09/17] remoteproc: Call the right core function based on synchronisation state Mathieu Poirier
2020-03-31 15:10   ` Suman Anna
2020-04-02 20:16     ` Mathieu Poirier
2020-04-09 18:48       ` Suman Anna
2020-04-09 18:48         ` Suman Anna
2020-03-24 21:45 ` [PATCH v2 10/17] remoteproc: Decouple firmware load and remoteproc booting Mathieu Poirier
2020-03-31 21:27   ` Suman Anna
2020-03-24 21:45 ` [PATCH v2 11/17] remoteproc: Repurpose function rproc_trigger_auto_boot() Mathieu Poirier
2020-03-31 21:32   ` Suman Anna
2020-03-24 21:45 ` [PATCH v2 12/17] remoteproc: Rename function rproc_fw_boot() Mathieu Poirier
2020-03-31 21:42   ` Suman Anna
2020-03-24 21:45 ` [PATCH v2 13/17] remoteproc: Introducting new functions to start and stop an MCU Mathieu Poirier
2020-03-31 18:08   ` Suman Anna
2020-03-31 21:46     ` Suman Anna
2020-04-01 21:55       ` Mathieu Poirier
2020-03-24 21:46 ` [PATCH v2 14/17] remoteproc: Refactor function rproc_trigger_recovery() Mathieu Poirier
2020-03-31 21:52   ` Suman Anna
2020-04-02 20:35     ` Mathieu Poirier
2020-04-09 19:02       ` Suman Anna
2020-04-09 19:02         ` Suman Anna
2020-03-24 21:46 ` [PATCH v2 15/17] remoteproc: Correctly deal with MCU synchronisation when changing FW image Mathieu Poirier
2020-03-27 13:50   ` Loic PALLARDY
2020-03-30 23:21     ` Mathieu Poirier
2020-03-31 22:14       ` Suman Anna
2020-04-01 20:55         ` Mathieu Poirier
2020-04-22 21:29         ` Mathieu Poirier
2020-04-22 22:56           ` Suman Anna
2020-03-24 21:46 ` [PATCH v2 16/17] remoteproc: Correctly deal with MCU synchronisation when changing state Mathieu Poirier
2020-03-27 14:04   ` Loic PALLARDY
2020-03-30 23:49     ` Mathieu Poirier
2020-03-31 22:35       ` Suman Anna
2020-04-01 21:29         ` Mathieu Poirier
2020-04-09 20:55           ` Suman Anna
2020-04-02 20:42         ` Mathieu Poirier
2020-04-09 20:40           ` Suman Anna
2020-03-24 21:46 ` [PATCH v2 17/17] remoteproc: Make MCU synchronisation state changes on stop and crashed Mathieu Poirier
2020-03-27 17:20 ` [PATCH v2 00/17] remoteproc: Add support for synchronisation with MCU Loic PALLARDY
2020-03-31 22:51   ` Suman Anna
2020-04-01 21:39     ` Mathieu Poirier [this message]

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=20200401213953.GF17383@xps15 \
    --to=mathieu.poirier@linaro.org \
    --cc=arnaud.pouliquen@st.com \
    --cc=bjorn.andersson@linaro.org \
    --cc=fabien.dessenne@st.com \
    --cc=linux-remoteproc@vger.kernel.org \
    --cc=loic.pallardy@st.com \
    --cc=ohad@wizery.com \
    --cc=peng.fan@nxp.com \
    --cc=s-anna@ti.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.