-
Notifications
You must be signed in to change notification settings - Fork 294
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
remoteproc_virtio: optimize the remoteproc virtio transport layer #489
Conversation
ea14a9d
to
a94e0c6
Compare
hello @CV-Bowen , Could you details what was the issue you are facing that needs to move the virtio_create_virtqueues to the transport layer? |
@arnopo Hi, we want to support different transport layer (remoteproc, mmio) for virtio drivers. After this PR, we can implement the mmio tranport layer base on OpenAmp. |
I understand the objective., what is not clear to me as a first review is why you need to move |
I found only |
@arnopo @edmooring |
b9e7b3a
to
cda0080
Compare
@CV-Bowen 's change extract and generalize from #494, after this change get merged:
|
8617243
to
4161017
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This PR probably breaks a lot of implementations.
I haven't done a test, but I'm fairly convinced that it breaks all Zephyr and ST projects, for example.
One reason is that you introduce a dependency between remoteproc
and remoteproc_virtio
, using struct remoteproc
Another is that some projects don't use the remoteproc virtio at all but static vrings.
Could you also split the commit in 3 ( as described in your commit message) ?
This would help for the review...
8177549
to
f7e1a49
Compare
All the comments should have been addressed. Could you take a look again? @arnopo |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This PR seems Ok in its design but will require some tests to ensure that it does not introduce regression in legacy.
Please find some comments on code
a744b07
to
487fd33
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM, I approve it but will need few test before merging it
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good to go, but agree with @arnopo we need to test more. It would be nice if my comment about the comment was addressed, but it is not necessary.
@arnopo, @edmooring If you are okay, we can merge the change. |
@CV-Bowen, |
@arnopo Rebased. |
tests Ok on my side |
This pull request has been marked as a stale pull request because it has been open (more than) 45 days with no activity. |
1. Implement the rproc_virtio_create_virtqueues() and rproc_virtio_delete_virtqueues(). 2. Because 1, also modified the rpmsg init. Signed-off-by: Bowen Wang <[email protected]>
741c59a
to
f81e22f
Compare
@arnopo Rebase to the last to fix the conflict. Could we merge this PR? There isn’t much time until release in April. |
Sorry @CV-Bowen, it go out of my radar, @edmooring , @tnmysh , as requested could you confirm that it does not create regression on your platforms |
remoteproc_virtio: optimize the remoteproc virtio transport layer
rpmsg_init_vdev_with_config()
also