| Message ID | 20210701090413.3104-1-arnaud.pouliquen@foss.st.com (mailing list archive) |
|---|---|
| Headers | show |
| Series | rpmsg: char: introduce the rpmsg-raw channel | expand |
Hi, > > How to test it: > - This series can be applied on git/andersson/remoteproc.git for-next branch (7486f29e5e60) > + the "Restructure the rpmsg char to decorrelate the control part" series[3] > > [1] https://patchwork.kernel.org/project/linux-remoteproc/list/?series=475217 > [2] https://patchwork.kernel.org/project/linux-remoteproc/list/?series=505873 > [3] https://patchwork.kernel.org/project/linux-remoteproc/list/?series=483793Just did test this patchset v3 again. With the same protocol Works for me, /dev/rpmsg0 is created on NS announcement, and removed when stopping the remote processor. I can do a repeated series of open /read/write/close, and got EBUSY if I try to open it more than once at a time. Firmware used for testing is derived from: https://github.com/zephyrproject-rtos/zephyr/tree/main/samples/subsys/ipc/openamp_rsc_table with: #define RPMSG_CHAN_NAME "rpmsg-raw" Thanks Arnaud for your work. Tested-by: Julien Massot <julien.massot@iot.bzh>
Purpose: Allow the remote processor to instantiate a /dev/rpmsgX interface relying on the NS announcement of the "rpmsg-raw" service. This patchet is extracted from the series [1] with rework to add rpmsg_create_default_ept helper. Aim: There is no generic sysfs interface based on RPMsg that allows a user application to communicate with a remote processor in a simple way. The rpmsg_char dev solves a part of this problem by allowing an endpoint to be created on the local side. But it does not take advantage of the NS announcement mechanism implemented for some backends such as the virtio backend. So it is not possible to probe it from a remote initiative. Extending the char rpmsg device to support NS announcement makes the rpmsg_char more generic. By announcing a "rpmg-raw" service, the firmware of a remote processor will be able to instantiate a /dev/rpmsgX interface providing to the user application a basic link to communicate with it without any knowledge of the rpmsg protocol. Implementation details: - Register a rpmsg driver for the rpmsg_char driver, associated to the "rpmsg-raw" channel service. - In case of rpmsg char device instantiated by the rpmsg bus (on NS announcement) manage the channel default endpoint to ensure a stable default endpoint address, for communication with the remote processor. delta vs V2 [2]: - Fix typos. - Suppress useless check on eptdev->rpdev, in rpmsg_eptdev_ioctl. - Add the Reviewed-by: Mathieu Poirier <mathieu.poirier@linaro.org>. How to test it: - This series can be applied on git/andersson/remoteproc.git for-next branch (7486f29e5e60) + the "Restructure the rpmsg char to decorrelate the control part" series[3] [1] https://patchwork.kernel.org/project/linux-remoteproc/list/?series=475217 [2] https://patchwork.kernel.org/project/linux-remoteproc/list/?series=505873 [3] https://patchwork.kernel.org/project/linux-remoteproc/list/?series=483793 Arnaud Pouliquen (4): rpmsg: Introduce rpmsg_create_default_ept function rpmsg: char: Introduce __rpmsg_chrdev_create_eptdev function rpmsg: char: Add possibility to use default endpoint of the rpmsg device. rpmsg: char: Introduce the "rpmsg-raw" channel drivers/rpmsg/rpmsg_char.c | 120 ++++++++++++++++++++++++++++++++++--- drivers/rpmsg/rpmsg_core.c | 51 ++++++++++++++++ include/linux/rpmsg.h | 13 ++++ 3 files changed, 175 insertions(+), 9 deletions(-)