Re: [PATCH 1/2] remoteproc: imx_rproc: dummy kick method

[nikita . shubin]

That's totally okay - thank you for review.

05.03.2020, 21:36, "Mathieu Poirier" <mathieu.poirier@xxxxxxxxxx>:
> On Thu, 5 Mar 2020 at 11:07, <nikita.shubin@xxxxxxxxxxx> wrote:
>> Â05.03.2020, 20:54, "Mathieu Poirier" <mathieu.poirier@xxxxxxxxxx>:
>> Â> 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?
>>
>> ÂYes, this assumption is correct.
>>
>> ÂDespite this situation is not i desire at all - such thing can happen.
>> ÂI am currently using co-proc as a realtime part of UGV control,
>> Âso it must immediately stop the engines, if not provided with navigational information.
>>
>> ÂThe imx7d MCU have access to the most periphery that have the main processor.
>>
>> ÂOf course the kick method should do real work, but i decided to submit step by step if i am allowed to do so.
>
> Ok, the situation is clearer now and I have put your patches back in
> my queue. I am seriously back-logged at this time so it will take a
> little while before I get to them.
>
>> Â>
>> Â> 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