[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <e54bcfcb-8e37-9caa-b330-a7411820b7ce@foss.st.com>
Date: Wed, 25 May 2022 10:57:06 +0200
From: Arnaud POULIQUEN <arnaud.pouliquen@...s.st.com>
To: Mathieu Poirier <mathieu.poirier@...aro.org>
CC: Bjorn Andersson <bjorn.andersson@...aro.org>,
<linux-remoteproc@...r.kernel.org>, <linux-kernel@...r.kernel.org>,
<linux-stm32@...md-mailman.stormreply.com>,
Deepak Kumar Singh <quic_deesin@...cinc.com>,
Chris Lew <quic_clew@...cinc.com>,
Xiang Xiao <xiaoxiang@...omi.com>
Subject: Re: [RFC PATCH 00/10] Introduction of rpmsg flow control service
Hi Mathieu,
On 5/24/22 17:34, Mathieu Poirier wrote:
> Hi Arnaud,
>
> I added your patchset to my review list. Unfortunately it sits behind
> a sizable backlog and as such I won't be able to get to it for some
> time.
No worries, I hope to get some feedbacks and to have discussion on the
topic from some other people as well
FYI, as a similar Pull request exists on OpenAMP github, I requsted in the
OpenAMP PR to centralize all the discussions around the design choice in this
thread. The aim is that we have a single discussion thread to find a consensus
on the way of implementing such service on virtio backend.
Creating a specific rpmsg service is one approach, some other can exist...
Regards,
Arnaud
>
> Thanks,
> Mathieu
>
> On Fri, 20 May 2022 at 02:30, Arnaud Pouliquen
> <arnaud.pouliquen@...s.st.com> wrote:
>>
>> This series proposes an implementation for the rpmsg virtio transport
>> backend, of the signaling API proposed by Deepak Kumar Singh:
>> "rpmsg and glink signaling API support" [1]
>>
>> The aim of the series is to offer the possibility for an endpoint to inform
>> a remote endpoint about its state, based on a software flow control[2].
>>
>> For this a new rpmsg service( with a fixed address 64) is proposed.
>> It is responsible for:
>> - transmitting local endpoint flow control information to the remote side,
>> - informing a local endpoint about a remote endpoint flow control.
>>
>> For the rpmsg virtio transport layer the service is negotiated thanks to the
>> virtio feature flag: VIRTIO_RPMSG_F_FC
>>
>> Notice that this pull request introduces new feature in the rpmsg protocol,
>> So it has to be aligned with OpenAMP implementation.
>> Pending OpenAMP pull request is available here:
>> https://github.com/OpenAMP/open-amp/pull/394
>>
>>
>> [1]https://lkml.org/lkml/2022/1/18/867
>> [2]https://en.wikipedia.org/wiki/Software_flow_control
>>
>> Arnaud Pouliquen (8):
>> rpmsg: core: Add rpmsg device remote flow control announcement ops
>> rpmsg: virtio: Implement the announce_remote_fc ops
>> rpmsg: Introduce flow control channel driver
>> rpmsg: virtio: Add support of the VIRTIO_RPMSG_F_FC feature
>> rpmsg: virtio: Implement the set_flow_control ops
>> rpmsg: Add the destination address in rpmsg_set_flow_control
>> rpmsg: tty : Add the support of the flow control
>> rpmsg: virtio: Set default dst address on flow control
>>
>> Deepak Kumar Singh (2):
>> rpmsg: core: Add signal API support
>> rpmsg: char: Add TIOCMGET/TIOCMSET ioctl support
>>
>> drivers/rpmsg/Kconfig | 11 +++
>> drivers/rpmsg/Makefile | 1 +
>> drivers/rpmsg/rpmsg_char.c | 56 +++++++++++++--
>> drivers/rpmsg/rpmsg_core.c | 47 +++++++++++++
>> drivers/rpmsg/rpmsg_fc.c | 113 +++++++++++++++++++++++++++++++
>> drivers/rpmsg/rpmsg_internal.h | 9 +++
>> drivers/rpmsg/virtio_rpmsg_bus.c | 111 +++++++++++++++++++++++++++++-
>> drivers/tty/rpmsg_tty.c | 50 ++++++++++++++
>> include/linux/rpmsg.h | 15 ++++
>> include/linux/rpmsg/fc.h | 51 ++++++++++++++
>> 10 files changed, 456 insertions(+), 8 deletions(-)
>> create mode 100644 drivers/rpmsg/rpmsg_fc.c
>> create mode 100644 include/linux/rpmsg/fc.h
>>
>> --
>> 2.25.1
>>
Powered by blists - more mailing lists