On Thu, 5 Mar 2020 at 10:29, <nikita.shubin@xxxxxxxxxxx> wrote:
>
>
>
> 05.03.2020, 19:17, "Mathieu Poirier" <mathieu.poirier@xxxxxxxxxx>:
> > On Wed, 4 Mar 2020 at 07:25, Nikita Shubin <NShubin@xxxxxxxxxx> wrote:
> >> add kick method that does nothing, to avoid errors in rproc_virtio_notify.
> >>
> >> Signed-off-by: Nikita Shubin <NShubin@xxxxxxxxxx>
> >> ---
> >> drivers/remoteproc/imx_rproc.c | 6 ++++++
> >> 1 file changed, 6 insertions(+)
> >>
> >> diff --git a/drivers/remoteproc/imx_rproc.c b/drivers/remoteproc/imx_rproc.c
> >> index 3e72b6f38d4b..796b6b86550a 100644
> >> --- a/drivers/remoteproc/imx_rproc.c
> >> +++ b/drivers/remoteproc/imx_rproc.c
> >> @@ -240,9 +240,15 @@ static void *imx_rproc_da_to_va(struct rproc *rproc, u64 da, int len)
> >> return va;
> >> }
> >>
> >> +static void imx_rproc_kick(struct rproc *rproc, int vqid)
> >> +{
> >> +
> >> +}
> >> +
> >
> > If rproc::kick() is empty, how does the MCU know there is packets to
> > fetch in the virtio queues?
>
> Well, of course it doesn't i understand this perfectly - just following documentation citing:
>
> | Every remoteproc implementation should at least provide the ->start and ->stop
> | handlers. If rpmsg/virtio functionality is also desired, then the ->kick handler
> | should be provided as well.
>
> But i as i mentioned in "remoteproc: Fix NULL pointer dereference in rproc_virtio_notify" kick method will be called if
> "resource_table exists in firmware and has "Virtio device entry" defined" anyway, the imx_rproc is not in control of what
> exactly it is booting, so such situation can occur.
If I understand correctly, the MCU can boot images that have a virtio
device in its resource table and still do useful work even if the
virtio device/rpmsg bus can't be setup - is this correct?
Thanks,
Mathieu
>
> >
> >> static const struct rproc_ops imx_rproc_ops = {
> >> .start = imx_rproc_start,
> >> .stop = imx_rproc_stop,
> >> + .kick = imx_rproc_kick,
> >> .da_to_va = imx_rproc_da_to_va,
> >> };
> >>
> >> --
> >> 2.24.1
