On 4/30/26 14:56, Beleswar Prasad Padhi wrote:
Hello Arnaud,
On 30/04/26 13:05, Arnaud POULIQUEN wrote:
Hello,
On 4/29/26 21:20, Mathieu Poirier wrote:
On Wed, 29 Apr 2026 at 12:07, Padhi, Beleswar <[email protected]> wrote:
Hi Mathieu,
On 4/29/2026 11:03 PM, Mathieu Poirier wrote:
On Wed, 29 Apr 2026 at 10:53, Shenwei Wang <[email protected]> wrote:
-----Original Message-----
From: Mathieu Poirier <[email protected]>
Sent: Wednesday, April 29, 2026 10:42 AM
To: Shenwei Wang <[email protected]>
Cc: Andrew Lunn <[email protected]>; Padhi, Beleswar <[email protected]>; Linus
Walleij <[email protected]>; Bartosz Golaszewski <[email protected]>; Jonathan
Corbet <[email protected]>; Rob Herring <[email protected]>; Krzysztof Kozlowski
<[email protected]>; Conor Dooley <[email protected]>; Bjorn Andersson
<[email protected]>; Frank Li <[email protected]>; Sascha Hauer
<[email protected]>; Shuah Khan <[email protected]>; linux-
[email protected]; [email protected]; [email protected];
Pengutronix Kernel Team <[email protected]>; Fabio Estevam
<[email protected]>; Peng Fan <[email protected]>;
[email protected]; [email protected];
[email protected]; [email protected]; dl-linux-imx <linux-
[email protected]>; Bartosz Golaszewski <[email protected]>
Subject: [EXT] Re: [PATCH v13 3/4] gpio: rpmsg: add generic rpmsg GPIO driver
On Tue, Apr 28, 2026 at 03:24:59PM +0000, Shenwei Wang wrote:
-----Original Message-----
From: Andrew Lunn <[email protected]>
Sent: Monday, April 27, 2026 3:49 PM
To: Shenwei Wang <[email protected]>
Cc: Padhi, Beleswar <[email protected]>; Linus Walleij
<[email protected]>; Bartosz Golaszewski <[email protected]>; Jonathan
Corbet <[email protected]>; Rob Herring <[email protected]>; Krzysztof
Kozlowski <[email protected]>; Conor Dooley <[email protected]>;
Bjorn Andersson <[email protected]>; Mathieu Poirier
<[email protected]>; Frank Li <[email protected]>; Sascha
Hauer <[email protected]>; Shuah Khan
<[email protected]>; [email protected]; linux-
[email protected]; [email protected]; Pengutronix
Kernel Team <[email protected]>; Fabio Estevam
<[email protected]>; Peng Fan <[email protected]>;
[email protected]; linux- [email protected];
[email protected]; linux-arm- [email protected];
dl-linux-imx <[email protected]>; Bartosz Golaszewski
<[email protected]>
Subject: [EXT] Re: [PATCH v13 3/4] gpio: rpmsg: add generic rpmsg
GPIO driver
struct virtio_gpio_response {
__u8 status;
__u8 value;
};
It is the same message format. Please see the message definition
(GET_DIRECTION) below:
+ +-----+-----+-----+-----+-----+----+
+ |0x00 |0x01 |0x02 |0x03 |0x04 |0x05|
+ | 1 | 2 |port |line | err | dir|
+ +-----+-----+-----+-----+-----+----+
Sorry, but i don't see how two u8 vs six u8 are the same message format.
Some changes to the message format are necessary.
Virtio uses two communication channels (virtqueues): one for requests and
replies, and a second one for events.
In contrast, rpmsg provides only a single communication channel, so a
type field is required to distinguish between different kinds of messages.
Since rpmsg replies and events share the same message format, an additional
line is introduced to handle both cases.
Finally, rpmsg supports multiple GPIO controllers, so a port field is added to
uniquely identify the target controller.
I have commented on this before - RPMSG is already providing multiplexing
capability by way of endpoints. There is no need for a port field. One
endpoint,
one GPIO controller.
You still need a way to let the remote side know which port the endpoint maps
to, either
by embedding the port information in the message (the current way), or by
sending it
separately.
An endpoint is created with every namespace request. There should be
one namespace request for every GPIO controller, which yields a unique
endpoint for each controller and eliminates the need for an extra
field to identify them.
Right, but this can still be done by just having one namespace request.
We can create new endpoints bound to an existing namespace/channel by
invoking rpmsg_create_ept(). This is what I suggested here too:
https://lore.kernel.org/all/[email protected]/
I will look at your suggestion (i.e link above) later this week or next week.
My mental model looks like this for the complete picture:
1. namespace/channel#1 = rpmsg-io
a. ept1 -> gpio-controller@1
b. ept2 -> gpio-controller@2
I've asked for one endpoint per GPIO controller since the very
beginning. I don't yet have a strong opinion on whether to use one
namespace request per GPIO controller or a single request that spins
off multiple endpoints. I'll have to look at your link and reflect on
that. Regardless of how we proceed on that front, multiplexing needs
to happen at the endpoint level rather than the packet level. This is
the only way this work can move forward.
I would be more in favor of Mathieu’s proposal: “An endpoint is created with
every namespace request.”
If the endpoint is created only on the Linux side, how do we match the Linux
endpoint address with the local port field on the remote side?
Simply by sending a message to the remote containing the newly created
endpoint and the port idx. Note that is this done just one time, after this
Linux need not have the port field in the message everytime its sending
a message.
With a multi-namespace approach, the namespace could be rpmsg-io-[addr], where
[addr] corresponds to the GPIO controller address in the DT. This would:
You will face the same problem in this case also that you asked above:
"how do we match the Linux endpoint address with the local port field
on the remote side?"
Sorry I probably introduced confusion here
my sentence should be;
With a multi-namespace approach, the namespace could be rpmsg-io-[port],
where [port] corresponds to the GPIO controller port in the DT.
For instance:
rpmsg {
rpmsg-io {
#address-cells = <1>;
#size-cells = <0>;
gpio@25 {
compatible = "rpmsg-gpio";
reg = <25>;
gpio-controller;
#gpio-cells = <2>;
#interrupt-cells = <2>;
interrupt-controller;
};
gpio@32 {
compatible = "rpmsg-gpio";
reg = <32>;
gpio-controller;
#gpio-cells = <2>;
#interrupt-cells = <2>;
interrupt-controller;
};
};
};
rpmsg-io-25 would match with gpio@25
rpmsg-io-32 would match with gpio@32
Because the endpoint that is created on a namespace request is also
dynamic in nature. How will the remote know which endpoint addr
Linux allocated for a namespace that it announced?
As an example/PoC, I created a firmware example which announces
2 name services to Linux, one is the standard "rpmsg_chrdev" and
the other is a TI specific name service "ti.ipc4.ping-pong". You can
see it created 2 different addresses (0x400 and 0x401) for each of
the name service request from the same firmware:
root@j784s4-evm:~# dmesg | grep virtio0 | grep -i channel
[ 9.290275] virtio_rpmsg_bus virtio0: creating channel ti.ipc4.ping-pong
addr 0xd
[ 9.311230] virtio_rpmsg_bus virtio0: creating channel rpmsg_chrdev addr 0xe
[ 9.496645] rpmsg_chrdev virtio0.rpmsg_chrdev.-1.14: DEBUG: Channel formed
from src = 0x400 to dst = 0xe
[ 9.707255] rpmsg_client_sample virtio0.ti.ipc4.ping-pong.-1.13: new channel:
0x401 -> 0xd!
So in this case, rpmsg-io-1 can have different ept addr than rpmsg-io-2
Back to same problem. Simple solution is to reply to remote with the
created ept addr and the index.
That why I would like to suggest to use the name service field to
identify the port/controller, instead of the endpoint address.
- match the RPMsg probe with the DT,
We can probe from all controllers with a single name service
announcement too.
- provide a simple mapping between the port and the endpoint on both sides,
We are trying to get rid of this mapping from Linux side to adapt
the gpio-virtio design.
- allow multiple endpoints on the remote side,
We can support this as well with single nameservice model.
There is no limitation. Remote has to send a message with
its newly created ept that's all.
- provide a simple discovery mechanism for remote capabilities.
A single announcement: "rpmsg-io" is also discovery mechanism.
Feel free to let me know if you have concerns with any of the
suggestions!
My only concern, whatever the solution, is that we find a smart
solution to associate the correct endpoint with the correct GPIO
port/controller defined in the DT.
I may have misunderstood your solution. Could you please help me
understand your proposal by explaining how you would handle three
GPIO ports defined in the DT, considering that the endpoint
addresses on the Linux side can be random?
If I assume there is a unique endpoint on the remote side,
I do not understand how you can match, on the firmware side,
the Linux endpoint address to the GPIO port.
Thanks and Regards,Arnaud
Thanks,
Beleswar
Regards,
Arnaud
2. namespace/channel#2 = rpmsg-i2c
a. ept1 -> i2c@1
b. ept2 -> i2c@2
c. ept3 -> i2c@3
etc...
This way device groups are isolated with each channel/namespace, and
instances within each device groups are also respected with specific
endpoints.
Thanks,
Beleswar
