[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <5cde9477-d73c-03c4-4dc0-c63fa0f8c8d9@foss.st.com>
Date: Wed, 23 Mar 2022 11:17:57 +0100
From: Arnaud POULIQUEN <arnaud.pouliquen@...s.st.com>
To: Deepak Kumar Singh <quic_deesin@...cinc.com>,
<bjorn.andersson@...aro.org>, <swboyd@...omium.org>,
<quic_clew@...cinc.com>, <mathieu.poirier@...aro.org>
CC: <linux-kernel@...r.kernel.org>, <linux-arm-msm@...r.kernel.org>,
<linux-remoteproc@...r.kernel.org>
Subject: Re: [PATCH V2 0/3] rpmsg and glink signaling API support
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.
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@foss.st.com/
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(-)
>
Powered by blists - more mailing lists