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;
MIME-Version: 1.0
References: <20200601175139.22097-1-mathieu.poirier@linaro.org> <0780724c-4fc0-9f98-023e-aa1245b01888@st.com>
In-Reply-To: <0780724c-4fc0-9f98-023e-aa1245b01888@st.com>
From:   Mathieu Poirier <mathieu.poirier@linaro.org>
Date:   Thu, 4 Jun 2020 14:27:21 -0600
Message-ID: <CANLsYkwsBSaVJCi7xDXC6E+E_UzwKmZqDtzZUWTDusuQKjKiQA@mail.gmail.com>
Subject: Re: [PATCH v4 0/9] remoteproc: Add support for attaching with rproc
To:     Arnaud POULIQUEN <arnaud.pouliquen@st.com>
Cc:     "bjorn.andersson@linaro.org" <bjorn.andersson@linaro.org>,
        "ohad@wizery.com" <ohad@wizery.com>,
        "linux-remoteproc@vger.kernel.org" <linux-remoteproc@vger.kernel.org>,
        "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
        Loic PALLARDY <loic.pallardy@st.com>,
        "s-anna@ti.com" <s-anna@ti.com>
Content-Type: text/plain; charset="UTF-8"
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

On Thu, 4 Jun 2020 at 08:24, Arnaud POULIQUEN <arnaud.pouliquen@st.com> wrote:
>
> Hi Mathieu,
>
> On 6/1/20 7:51 PM, Mathieu Poirier wrote:
> > This fourth iteration implements a solution that is fairly different from
> > what was proposed in V3 and earlier versions.  Three aspects have been
> > revisited:
> >
> > 1) Only the scenario where the remoteproc core is attaching to the remote
> >    processor is implemented.  Other scenarios where actions need to be
> >    taken when the remote processor is stopped or crashes will be
> >    considered in subsequent versions.
> >
> > 2) The introduction of a new RPROC_DETACHED state to be set by platform
> >    drivers when needing to attach to an already running remote processor.
> >
> > 3) New functions are introduced to replicate the functionality provided by
> >    rproc_fw_boot() and rproc_start(), minus operations related to firmware
> >    management.
> >
> > Enhancement to the documentation has been left out intentionally until it
> > is agreed to move forward with this implementation.
>
> Look good to me, i have only a minor concerns about the code duplication
> introduced by the point 3)
>

This is an idea Bjorn and I have decided to try in the hope of making
the state machine, and the feature as a whole, easier to understand.
It might be one of those rare cases where more code is better.

> If you are agree with that, I plan to do a new review on the stm32 series
> when you will start the documentation :-)

A wise decision...

Thanks for taking the time to look at this,
Mathieu

>
> Regards,
> Arnaud
>
> >
> > Applies cleanly on rproc-next(7dcef3988eed) and will be rebased on v5.8-rc1
> > when it comes out in two weeks.
> >
> > Thanks,
> > Mathieu
> >
> > Mathieu Poirier (9):
> >   remoteproc: Add new RPROC_DETACHED state
> >   remoteproc: Add new attach() remoteproc operation
> >   remoteproc: Introducing function rproc_attach()
> >   remoteproc: Introducing function rproc_actuate()
> >   remoteproc: Introducing function rproc_validate()
> >   remoteproc: Refactor function rproc_boot()
> >   remoteproc: Refactor function rproc_trigger_auto_boot()
> >   remoteproc: Refactor function rproc_free_vring()
> >   remoteproc: Properly handle firmware name when attaching
> >
> >  drivers/remoteproc/remoteproc_core.c     | 226 +++++++++++++++++++++--
> >  drivers/remoteproc/remoteproc_internal.h |   8 +
> >  drivers/remoteproc/remoteproc_sysfs.c    |  17 +-
> >  include/linux/remoteproc.h               |   9 +-
> >  4 files changed, 243 insertions(+), 17 deletions(-)
> >