Message ID | 20210607173032.30133-1-arnaud.pouliquen@foss.st.com (mailing list archive) |
---|---|
Headers | show |
Series | rpmsg: char: introduce the rpmsg-raw channel | expand |
Hi, On 6/7/21 7:30 PM, Arnaud Pouliquen wrote: > 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. > > How to test it: > - This series can be applied on git/andersson/remoteproc.git for-next branch (dc0e14fa833b) > + the "Restructure the rpmsg char to decorrelate the control part" series[2] > > [1] https://patchwork.kernel.org/project/linux-remoteproc/list/?series=475217 > [2] https://patchwork.kernel.org/project/linux-remoteproc/list/?series=483793 Just tested this whole series on remoteproc for-next branch + [2]. 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>
Hi Arnaud, Between remoteproc/RPMSG and CoreSight, I have 6 patchsets to review (including some of your work) before getting to this one. As such it will take a little while. Thanks, Mathieu On Mon, 7 Jun 2021 at 11:30, Arnaud Pouliquen <arnaud.pouliquen@foss.st.com> wrote: > > 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. > > How to test it: > - This series can be applied on git/andersson/remoteproc.git for-next branch (dc0e14fa833b) > + the "Restructure the rpmsg char to decorrelate the control part" series[2] > > [1] https://patchwork.kernel.org/project/linux-remoteproc/list/?series=475217 > [2] https://patchwork.kernel.org/project/linux-remoteproc/list/?series=483793 > > > > Arnaud Pouliquen (4): > rpmsg: Introduce rpmsg_create_default_ept function > rpmsg: char: Add possibility to create and reuse default endpoint > rpmsg: char: Introduce the "rpmsg-raw" channel > rpmsg: char: Return error if user tries to destroy a default endpoint. > > drivers/rpmsg/rpmsg_char.c | 92 +++++++++++++++++++++++++++++++++++--- > drivers/rpmsg/rpmsg_core.c | 51 +++++++++++++++++++++ > include/linux/rpmsg.h | 14 ++++++ > 3 files changed, 151 insertions(+), 6 deletions(-) > > -- > 2.17.1 >
Hi Mathieu, On 6/8/21 4:26 PM, Mathieu Poirier wrote: > Hi Arnaud, > > Between remoteproc/RPMSG and CoreSight, I have 6 patchsets to review > (including some of your work) before getting to this one. As such it > will take a little while. No worries, i knew you have already some patchsets in your pipe. As i used this series to test the rpmsg_ctrl [1], both were ready at the same time. So i decided to push it because it can also help you to perform tests on the series [1]. [1] https://patchwork.kernel.org/project/linux-remoteproc/list/?series=494021 Thanks, Arnaud > > Thanks, > Mathieu > > On Mon, 7 Jun 2021 at 11:30, Arnaud Pouliquen > <arnaud.pouliquen@foss.st.com> wrote: >> >> 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. >> >> How to test it: >> - This series can be applied on git/andersson/remoteproc.git for-next branch (dc0e14fa833b) >> + the "Restructure the rpmsg char to decorrelate the control part" series[2] >> >> [1] https://patchwork.kernel.org/project/linux-remoteproc/list/?series=475217 >> [2] https://patchwork.kernel.org/project/linux-remoteproc/list/?series=483793 >> >> >> >> Arnaud Pouliquen (4): >> rpmsg: Introduce rpmsg_create_default_ept function >> rpmsg: char: Add possibility to create and reuse default endpoint >> rpmsg: char: Introduce the "rpmsg-raw" channel >> rpmsg: char: Return error if user tries to destroy a default endpoint. >> >> drivers/rpmsg/rpmsg_char.c | 92 +++++++++++++++++++++++++++++++++++--- >> drivers/rpmsg/rpmsg_core.c | 51 +++++++++++++++++++++ >> include/linux/rpmsg.h | 14 ++++++ >> 3 files changed, 151 insertions(+), 6 deletions(-) >> >> -- >> 2.17.1 >>