Add RPMsg API to get buffer size #565
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
arnopo
reviewed
Mar 18, 2024
| @@ -121,21 +131,12 @@ int app (struct rpmsg_device *rdev, void *priv) | |||
|
|
|||
| if (!i_payload) { | |||
| LPERROR("memory allocation failed.\r\n"); | |||
| rpmsg_destroy_ept(&lept); | |||
There was a problem hiding this comment.
reviewing the code I just see that an error returned rpmsg_send error not return a test failed. t
Could you also fix that by managing a ret variable and using go out?
if (!i_payload) {
LPERROR("memory allocation failed.\r\n");
ret = -1;
goto out;
}
[...]
if (ret) {
LPERROR("Failed to create RPMsg endpoint.\r\n");
ret = -1;
goto free_mem:
}
[...]
free_mem:
metal_free_memory(i_payload);
out:
LPRINTF("**********************************\r\n");
LPRINTF(" Test Results: Error count = %d \r\n", err_cnt);
LPRINTF("**********************************\r\n");
/* Destroy the RPMsg endpoint */
rpmsg_destroy_ept(&lept);
LPRINTF("Quitting application .. Echo test end\r\n");
return ret;
}
There was a problem hiding this comment.
I looked into that and it will introduce more churn than I'd think should be part of this series. Would it be better to address that issue in a separate PR?
Add an RPMsg API to get the buffer sizes supported by the backing transport layer. Add hooks so that transport layers can register functions to provide this data. Signed-off-by: Andrew Davis <[email protected]>
RPMsg provides functions to get a transport's backing buffer sizes. Connect this up for the virtio transport here. Signed-off-by: Andrew Davis <[email protected]>
The contents of app() in these examples is given a rpmsg_device. We should not have to know about the backing transport layer. We assume it is virtio and call into the virtio layer to get the buffer size. This information is now available from the rpmsg layer. Use those functions to make the app() agnostic to the backing layer. Signed-off-by: Andrew Davis <[email protected]>
glneo
force-pushed
the
rpmsg-get-buffer-size
branch
from
083e617
to
d5166b5
Compare
xiaoxiang781216
approved these changes
Apr 2, 2024
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
In patch 3 of this series you can see core of the issue, applications have no way of finding if the transport layer under RPMsg has a maximum supported message size. The examples end up having to look directly into the transport layer to find this info. With this API they can ask the RPMsg layer without having to know about the backing transport layer. This is better API layering and allows the core of the examples to work across any transport layer.