Skip to content

legacy_apps: xlnx: add api to poll apps on vdev status#100

Open
tnmysh wants to merge 1 commit intoOpenAMP:mainfrom
tnmysh:add_poll_on_vdev_reset_api
Open

legacy_apps: xlnx: add api to poll apps on vdev status#100
tnmysh wants to merge 1 commit intoOpenAMP:mainfrom
tnmysh:add_poll_on_vdev_reset_api

Conversation

@tnmysh
Copy link
Collaborator

@tnmysh tnmysh commented Mar 17, 2026

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.

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>
@tnmysh tnmysh requested review from arnopo, edmooring and wmamills March 17, 2026 23:44
break;
}
}
platform_poll_on_vdev_reset(priv, rdev);
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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?

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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?

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants