Skip to content
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

openamp: decouple rpmsg virtio and remoteproc #549

Merged
merged 2 commits into from
Mar 18, 2024

Conversation

wyr8899
Copy link

@wyr8899 wyr8899 commented Jan 30, 2024

openamp: move notify_wait() in rpmsg virtio to rpmsg, this ops can do in rpmsg without coupling to virtio.

@@ -54,6 +54,7 @@ typedef void (*rpmsg_ept_release_cb)(struct rpmsg_endpoint *ept);
typedef void (*rpmsg_ns_unbind_cb)(struct rpmsg_endpoint *ept);
typedef void (*rpmsg_ns_bind_cb)(struct rpmsg_device *rdev,
const char *name, uint32_t dest);
typedef int (*rpmsg_notify_wait_cb)(struct rpmsg_device *rdev, uint32_t id);
Copy link
Collaborator

Choose a reason for hiding this comment

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

This is not related to the rpmsg but to the transport layer, I would expect that this is part of the rpmsg_virtio.

Copy link
Collaborator

Choose a reason for hiding this comment

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

but rpmsg could support other transport(e.g. uart/spi), this patch try to avoid couple the notify wait callback with the virtio transport.

Copy link
Collaborator

Choose a reason for hiding this comment

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

My point here is that "id" is related to the vring so the transport layer. the Id will probably be use then to identify the associated mailbox.

Copy link
Contributor

@CV-Bowen CV-Bowen Feb 2, 2024

Choose a reason for hiding this comment

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

@xiaoxiang781216 @arnopo So how about change the uint32_t id to void *arg to be compatible with all rpmsg transports ?

Copy link
Collaborator

Choose a reason for hiding this comment

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

This does not solve the issue for me as we would still need to interpret the args as a reference known by the transport layer.
The rpmsg_device struct should contain only fields related to the RPMsg service.
We can also assume that the notion of "notify" is linked to Virtio. For instance, for a UART transport, we will probably speak about an end-of-transfer callback.
Another question we have to answer is whether this callback is related to RPMsg Virtio or to Virtio. I wonder if this callback should not be in the Virtio layer to be able to reuse it for other Virtio services.

Copy link
Collaborator

Choose a reason for hiding this comment

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

@arnopo OK, move this callback to struct rpmsg_virtio_device is acceptable to me. About the second question, I think let virtio services handle the buffer question is better just like rpmsg virtio device does.

Ok let keep it here for the moment, if needed for some other virtio service, we will implement it at virtio level and make this one deprecated

Copy link
Contributor

Choose a reason for hiding this comment

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

@arnopo So you mean keep PR #518 and add new notify_wait() callback in struct rpmsg_virtio_device to support two ways to handle the get tx buffer failed problem, but default to use the notify_wait() callback in struct rpmsg_virtio_device way?

Copy link
Collaborator

Choose a reason for hiding this comment

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

@arnopo So you mean keep PR #518 and add new notify_wait() callback in struct rpmsg_virtio_device to support two ways to handle the get tx buffer failed problem, but default to use the notify_wait() callback in struct rpmsg_virtio_device way?

No, you can revert #518. My point here is that it is acceptable to implement this in rpmsg_virtio for the time being.
However, in the future, if this callback is also required for some other virtio services, we will have to rework it to implement something common in the virtio layer.

Copy link
Collaborator

@arnopo arnopo Feb 28, 2024

Choose a reason for hiding this comment

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

to sum -up the remaining work here is

  • move this callback to struct rpmsg_virtio_device
  • management of the cb in rpmsg_virtio ( remove code in rpmsg.c)

Copy link
Author

Choose a reason for hiding this comment

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

Ok, done.

…uffer get"

This reverts commit 95802c1.

Signed-off-by: Yongrong Wang <[email protected]>
@wyr8899 wyr8899 force-pushed the notify_dev branch 2 times, most recently from 0b5c3bd to f4ddcf5 Compare January 31, 2024 02:32
lib/rpmsg/rpmsg_virtio.c Show resolved Hide resolved
lib/include/openamp/rpmsg.h Outdated Show resolved Hide resolved
@wyr8899 wyr8899 force-pushed the notify_dev branch 2 times, most recently from 5d13981 to 7fc6e43 Compare January 31, 2024 02:51
Copy link
Contributor

@edmooring edmooring left a 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.

@wyr8899 wyr8899 force-pushed the notify_dev branch 5 times, most recently from 6ec1958 to 613fb79 Compare March 7, 2024 08:42
lib/include/openamp/rpmsg.h Outdated Show resolved Hide resolved
if (rvdev->notify_wait_cb)
return rvdev->notify_wait_cb(&rvdev->rdev, vring_info->notifyid);

return RPMSG_ERR_NXIO;
Copy link
Contributor

Choose a reason for hiding this comment

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

RPMSG_EOPNOTSUPP

Copy link
Author

Choose a reason for hiding this comment

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

Ok, done

Copy link
Contributor

@CV-Bowen CV-Bowen left a comment

Choose a reason for hiding this comment

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

@arnopo Could you take a look?

@@ -43,7 +43,7 @@ extern "C" {
#define RPMSG_ERR_INIT (RPMSG_ERROR_BASE - 6)
#define RPMSG_ERR_ADDR (RPMSG_ERROR_BASE - 7)
#define RPMSG_ERR_PERM (RPMSG_ERROR_BASE - 8)
#define RPMSG_EOPNOTSUPP (RPMSG_ERROR_BASE - 9)
#define RPMSG_EOPNOTSUPP (RPMSG_ERROR_BASE - 9)
Copy link
Contributor

Choose a reason for hiding this comment

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

align

Copy link
Author

Choose a reason for hiding this comment

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

done

Copy link
Collaborator

@arnopo arnopo left a comment

Choose a reason for hiding this comment

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

Few comment,
Please rework also the commit message of the second commit. It should reflect the changes.
you should be able to reuse, with few adaptation, the commit message of
commit 95802c1.

@@ -358,6 +358,19 @@ static void rpmsg_virtio_release_rx_buffer(struct rpmsg_device *rdev,
metal_mutex_release(&rdev->lock);
}

static int rpmsg_virtio_notify_wait(struct rpmsg_virtio_device *rvdev,
struct virtqueue *vq)
Copy link
Collaborator

Choose a reason for hiding this comment

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

squash declaration on 1 line (up to 100 char is OK)

Copy link
Author

Choose a reason for hiding this comment

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

Ok, done

lib/rpmsg/rpmsg_virtio.c Show resolved Hide resolved
* use metal_sleep_usec() method by default.
*/
status = rpmsg_virtio_notify_wait(rvdev, rvdev->rvq);
if (status != RPMSG_SUCCESS) {
Copy link
Collaborator

Choose a reason for hiding this comment

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

if status is different from RPMSG_EOPNOTSUPP we should leave the loop

if (status == RPMSG_EOPNOTSUPP) {
		metal_sleep_usec(RPMSG_TICKS_PER_INTERVAL);
		tick_count--;
} else if (status == RPMSG_SUCCESS) {
		break;
}

Copy link
Author

Choose a reason for hiding this comment

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

Ok, done

@@ -111,6 +111,8 @@ rpmsg_get_ept_from_addr(struct rpmsg_device *rdev, uint32_t addr)
return rpmsg_get_endpoint(rdev, NULL, addr, RPMSG_ADDR_ANY);
}

int rpmsg_notify_wait(struct rpmsg_device *rdev, uint32_t id);
Copy link
Contributor

Choose a reason for hiding this comment

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

remove no need

Copy link
Author

Choose a reason for hiding this comment

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

done

Copy link
Collaborator

@arnopo arnopo left a comment

Choose a reason for hiding this comment

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

LGTM after addressing @CV-Bowen comment

@arnopo arnopo requested review from edmooring and tnmysh March 12, 2024 09:56
@arnopo
Copy link
Collaborator

arnopo commented Mar 12, 2024

@edmooring @tnmysh
Few updates since your last review. please, Could you do a new review?

Give users a chance to handle the no tx buffer situation when get tx
buffer, with this patch, user can set the notify_wait_cb in driver
and this callback function will be called to handle the wait when no
tx buffer in tx virtqueue.

Signed-off-by: Yongrong Wang <[email protected]>
Copy link
Contributor

@CV-Bowen CV-Bowen left a comment

Choose a reason for hiding this comment

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

LGTM !

Copy link
Collaborator

@tnmysh tnmysh left a comment

Choose a reason for hiding this comment

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

LGTM.

Copy link
Contributor

@edmooring edmooring left a 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.

@arnopo arnopo merged commit 15b4a8b into OpenAMP:main Mar 18, 2024
3 checks passed
@arnopo arnopo added this to the Release V2024.04 milestone Mar 18, 2024
@arnopo arnopo mentioned this pull request Apr 2, 2024
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.

7 participants