Hi Mathieu,
On 1/13/21 9:31 PM, Mathieu Poirier wrote:
> Hi Arnaud,
>
> [...]
>
>>
>> Arnaud Pouliquen (16):
>> rpmsg: introduce RPMsg control driver for channel creation
>> rpmsg: add RPMsg control API to register service
>> rpmsg: add override field in channel info
>> rpmsg: ctrl: implement the ioctl function to create device
>> rpmsg: ns: initialize channel info override field
>> rpmsg: add helper to register the rpmsg ctrl device
>> rpmsg: char: clean up rpmsg class
>> rpmsg: char: make char rpmsg a rpmsg device without the control part
>> rpmsg: char: register RPMsg raw service to the ioctl interface.
>> rpmsg: char: allow only one endpoint per device
>> rpmsg: char: check destination address is not null
>> rpmsg: virtio: use the driver_override in channel creation ops
>> rpmsg: virtio: probe the rpmsg_ctl device
>> rpmsg: glink: add create and release rpmsg channel ops
>> rpmsg: smd: add create and release rpmsg channel ops
>> rpmsg: replace rpmsg_chrdev_register_device use
>>
>> drivers/rpmsg/Kconfig | 8 +
>> drivers/rpmsg/Makefile | 1 +
>> drivers/rpmsg/qcom_glink_native.c | 96 +++++++--
>> drivers/rpmsg/qcom_smd.c | 59 +++++-
>> drivers/rpmsg/rpmsg_char.c | 246 ++++++-----------------
>> drivers/rpmsg/rpmsg_ctrl.c | 320 ++++++++++++++++++++++++++++++
>> drivers/rpmsg/rpmsg_internal.h | 14 --
>> drivers/rpmsg/rpmsg_ns.c | 1 +
>> drivers/rpmsg/virtio_rpmsg_bus.c | 38 +++-
>> include/linux/rpmsg.h | 40 ++++
>> include/uapi/linux/rpmsg.h | 14 ++
>> 11 files changed, 606 insertions(+), 231 deletions(-)
>> create mode 100644 drivers/rpmsg/rpmsg_ctrl.c
>
> I am finally coming around to review this set. I see that you already had an
> extensive conversation with Bjorn - did you want me to have a look as well or
> should I wait for the next revision?
Based on Bjorn first feedback, my understanding is that the management based on
create/destroy channel does not match with the QCOM RPMsg backend
implementation. I think this is the blocking point of my V2 implementation.
Before sending a new revision i would hope that we have a roundtable discussion
to clarify the direction to move forward, to avoid sending useless revisions.
As discussed in [1], there are different alternatives, that probably depend on
the features we expect to support.
I tried to sum-up the requirement I have in mind in [1].
The 2 main directions I can see are:
- rework the rpmsg_char to match with all rpmsg backend (V2 implementation)
to be honest i don't know how to move forward in this direction as QCOM and
virtio backends are rather different.
- not modify the rpmsg_char but create the rpmsg_ctrl (and perhaps also a
rpmsg_raw for a /dev/rpmsg data interface) that would use the create/destroy
channel such as the rpmsg ns (V1 implementation).
one advantage of this solution is that this does not impact QCOM drivers.
one drawback is that we duplicate the code.
[1]
https://patchwork.kernel.org/project/linux-remoteproc/patch/20201222105726.16906-5-arnaud.pouliquen@xxxxxxxxxxx/
[2] https://patchwork.kernel.org/project/linux-remoteproc/list/?series=327277
Thanks,
Arnaud
>
> Thanks,
> Mathieu
>
>>
>> --
>> 2.17.1
>>
