legacy_apps: xlnx: add api to poll apps on vdev status#100
legacy_apps: xlnx: add api to poll apps on vdev status#100tnmysh wants to merge 1 commit intoOpenAMP:mainfrom
Conversation
In case of the remoteproc repeat attach-detach, RPU firmware should be able to re-create the virtio devices. For this, the firmware should poll on the vdev status, and if the status is 0, then it should destroy the virtio and rpmsg devices. Then it should re-create them and wait for next driver ready status from the linux kernel. The vdev status 0 is usually done during remoteproc detach operation. Mailbox notification is expected from the Linux side on vdev status reset. Signed-off-by: Tanmay Shah <tanmay.shah@amd.com>
| break; | ||
| } | ||
| } | ||
| platform_poll_on_vdev_reset(priv, rdev); |
There was a problem hiding this comment.
This imposes that platform_poll_on_vdev_reset is defined in all machine. For instance this breaks build on Linux PC.
/usr/bin/ld: CMakeFiles/rpmsg-echo-shared.dir/rpmsg-echo.c.o: in function `rpmsg_echo_app':
rpmsg-echo.c:(.text+0x37f): undefined reference to `platform_poll_on_vdev_reset'
then platform_poll seems deprecated
Why not just keeping platform_poll but adding struct rpmsg_device *rpdev parameter?
There was a problem hiding this comment.
Hmm... But that means, all the current support will move to the virtio reset polling. Is that okay?
Sorry I missed the Linux build on PC.
There was a problem hiding this comment.
Hmm... But that means, all the current support will move to the virtio reset polling. Is that okay?
Not sure to understand your point, the implementation of platform_poll is already machine dependent.
There was a problem hiding this comment.
I mean all for all places where platform_poll is used, is it okay to use platform_poll_on_vdev_reset? Can we deprecate use of platform_poll ? I don't see any reason to keep platform_poll honestly. What do you think?
There was a problem hiding this comment.
Without platform_poll, there is no notification of new incoming rpmsg (see the remoteproc_get_notification() function). It seems to me that your platform_poll_on_vdev_reset function is an extension of platform_poll with added management of the vdev status reset.
From my point of view, platform_poll is a more generic name. I would update it instead of creating a new function.
In the openamp-system-reference, I don’t think there is a need to apply the deprecation process, as the objective is only to provide reference code.
In case of the remoteproc repeat attach-detach, RPU firmware should be able to re-create the virtio devices. For this, the firmware should poll on the vdev status, and if the status is 0, then it should destroy the virtio and rpmsg devices. Then it should re-create them and wait for next driver ready status from the linux kernel. The vdev status 0 is usually done during remoteproc detach operation. Mailbox notification is expected from the Linux side on vdev status reset.