Hi, On 3/23/22 11:17, Arnaud POULIQUEN wrote: > Hi all, > > On 1/18/22 20:43, Deepak Kumar Singh wrote: >> [Change from V1] >> Fixed most of the review comments in V1. > > This implementation works for the glink transport, > But how to manage such flow control for other transport > layer? > From my POV it is important that it is also usable for > by transport backends which doe not have such signaling. > The idea here is not to implement in other backends yet, but > at least to determine how it could be handled to avoid that > tomorrow this has to be reworked. FYI, I've started some dev, trying to adapt the implementation to the virtio backend to move forward with this topic. It is only a POC for time being based on a new ROPMsg service for the flow control. Linux code is available here: https://github.com/arnopo/linux/commits/signalling openamp library associated code is available here: https://github.com/arnopo/open-amp/commits/flow_ctrl I hope to find some time next month to continue my dev and send patches to the mailing list. Regards, Arnaud > > More than that I wonder if the flow control could also be used > to solve the RPmsg protocol issue related to the channel > announcement [1][2] > > [1] https://github.com/OpenAMP/open-amp/pull/160 > [2] https://lore.kernel.org/lkml/20220316153001.662422-1-arnaud.pouliquen@xxxxxxxxxxx/ > > Thanks, > Arnaud > >> >> Deepak Kumar Singh (3): >> rpmsg: core: Add signal API support >> rpmsg: glink: Add support to handle signals command >> rpmsg: char: Add TIOCMGET/TIOCMSET ioctl support >> >> drivers/rpmsg/qcom_glink_native.c | 77 +++++++++++++++++++++++++++++++++++++++ >> drivers/rpmsg/rpmsg_char.c | 47 ++++++++++++++++++++++-- >> drivers/rpmsg/rpmsg_core.c | 21 +++++++++++ >> drivers/rpmsg/rpmsg_internal.h | 2 + >> include/linux/rpmsg.h | 14 +++++++ >> 5 files changed, 157 insertions(+), 4 deletions(-) >>
