[RFC] greybus: support combined Host + SVC

[RFC] greybus: support combined Host + SVC

[Ayush Singh]

Hello everyone,

I’ve recently been experimenting with chaining multiple Greybus nodes to 
a single host over I²C (QWIIC port [0]). This general idea is not new 
(see MicroMod Qwiic Pro Kit [1]), although those setups do not use Greybus.

Since I²C does not allow a slave to initiate transfers, it is not well 
suited for node-initiated events (e.g. interrupts, SVC-initiated 
control). However, for my current use case I am primarily interested in 
polling-based functionality, so this limitation is acceptable.

In a typical Greybus topology, an Application Processor (AP), an SVC, 
and one or more modules are connected via UniPro. In practice, because 
most application processors lack a native UniPro interface, they connect 
through a bridge device that also implements the SVC.

For the I²C-based setup described above, I have considered the following 
topologies:

1. Separate co-processor (SVC/Bridge)

    This approach is reasonable on SoCs such as TI AM6254, which include 
an M4F core that can serve as the SVC/bridge and control the I²C bus. 
However, on devices like TI AM62L, which lack such a core, introducing 
an additional processor solely for Greybus does not seem justified. 
Also, this would make the above much less portable, since it expects a 
hardware component, not all BeagleBoard.org boards have.

    ```
        +----+                  +---------------+ +----------+
        | AP | <--- bus ---->   | SVC / Bridge  | <--- I2C ---->   | 
Module   |
        +----+                  +---------------+ +----------+
                                       |
                                       | +----------+
                                       `----------- I2C ---->  | Module   |
  +----------+
    ```

2. SVC per node

    Each node implements its own SVC. Since an I²C slave cannot initiate 
communication, the AP must already know the address of each SVC/module. 
This also seems inefficient when chaining multiple nodes.

    ```
        +----+                +----------------+
        | AP | <--- I2C --->  | SVC / Module   |
        +----+                +----------------+
                                    |
                                    |  +----------------+
                                    `---- I2C ---->   | SVC / Module   |
  +----------------+
    ```

3. SVC/Bridge functionality inside the AP

    For this use case, this seems to be the most practical option.

    To clarify, I am not proposing any new data paths in the Greybus 
pipeline. The idea is to have a reusable an SVC/bridge implementation 
similar to what exists in greybus-zephyr [2][3], but hosted within the AP.

    ```
        +-------------+                +-----------+
        | AP / SVC    | <--- I2C --->  | Module    |
        +-------------+                +-----------+
                                        |
                                        |             +----------+
                                        `-- I2C --->  | Module  |
                                                      +----------+
    ```

Before proceeding further, I would appreciate feedback on this 
approach—particularly whether there are concerns with option 3, or if 
there are alternative designs I should consider.

Best regards,
Ayush Singh

[0]: https://www.sparkfun.com/qwiic
[1]: 
https://www.digikey.in/en/maker/projects/micromod-qwiic-pro-kit-project-guide/a3d7fa1a063f42ecb2c2b3c337249bdd
[2]: 
https://github.com/beagleboard/greybus-zephyr/blob/main/subsys/greybus/svc.c#L81
[3]: 
https://github.com/beagleboard/greybus-zephyr/blob/main/subsys/greybus/apbridge.c#L42 

Re: [RFC] greybus: support combined Host + SVC

[Damien Riégel]

On Sat Feb 28, 2026 at 8:47 AM EST, Ayush Singh wrote:
> 2. SVC per node
>
>     Each node implements its own SVC. Since an I²C slave cannot initiate
> communication, the AP must already know the address of each SVC/module.
> This also seems inefficient when chaining multiple nodes.
>
> [...]
>
> 3. SVC/Bridge functionality inside the AP
>
>     For this use case, this seems to be the most practical option.
>
>     To clarify, I am not proposing any new data paths in the Greybus
> pipeline. The idea is to have a reusable an SVC/bridge implementation
> similar to what exists in greybus-zephyr [2][3], but hosted within the AP.

We discussed internally at Silicon Labs of this solution to get rid of
the SVC on the device but haven't actually implemented it, good to know
that we were not alone. I think it's a great avenue to explore because
it keeps existing SVC code as is, so we keep a single data path in
Greybus' core while offering the capability to handle SVC requests on
the host.

Just to help me get a better mental picture, in hd->message_send you
would either handle the message immediately if cport_id == 0, or convert
that cport_id to an (interface, intf_cport_id) and pass the message to
that interface's cport, something like that?

    static int message_send(..., u16 cport_id, struct gb_message *msg, ...)
    {
    	if (cport_id == GB_SVC_CPORT_ID) {
    		return svc_bridge_handle_msg(msg);
    	} else {
    		struct connection *connection = svc_bridge_get_connection(cport_id);
    		// ... or you could directly look up in hd->connections,
    		// the whole list of connections is already there, so
		// no need to maintain another one separately

    		// somewhow convert connection->intf to an i2c address
    		// and use connection->intf_cport_id to address the cport
    		i2c_transfer(adap, msgs, 1);
    	}
    }

>     ```
>         +-------------+                +-----------+
>         | AP / SVC    | <--- I2C --->  | Module    |
>         +-------------+                +-----------+
>                                         |
>                                         |             +----------+
>                                         `-- I2C --->  | Module  |
>                                                       +----------+
>     ```

You mention in point 2 that i2c slaves cannot initiate communication, so
I wonder how you would emulate the "MODULE_INSERTED" that flows from SVC
to the AP. Would your HD poll the bus for connected modules and "send" a
MODULE_INSERTED for each of them?

Besides that, I think it would work fine. I'll be happy to test and
review your patch when ready.

Regards,
damien

Re: [RFC] greybus: support combined Host + SVC

[Ayush Singh]

On 3/3/26 3:27 AM, Damien Riégel wrote:

> On Sat Feb 28, 2026 at 8:47 AM EST, Ayush Singh wrote:
>> 2. SVC per node
>>
>>      Each node implements its own SVC. Since an I²C slave cannot initiate
>> communication, the AP must already know the address of each SVC/module.
>> This also seems inefficient when chaining multiple nodes.
>>
>> [...]
>>
>> 3. SVC/Bridge functionality inside the AP
>>
>>      For this use case, this seems to be the most practical option.
>>
>>      To clarify, I am not proposing any new data paths in the Greybus
>> pipeline. The idea is to have a reusable an SVC/bridge implementation
>> similar to what exists in greybus-zephyr [2][3], but hosted within the AP.
> We discussed internally at Silicon Labs of this solution to get rid of
> the SVC on the device but haven't actually implemented it, good to know
> that we were not alone. I think it's a great avenue to explore because
> it keeps existing SVC code as is, so we keep a single data path in
> Greybus' core while offering the capability to handle SVC requests on
> the host.
>
> Just to help me get a better mental picture, in hd->message_send you
> would either handle the message immediately if cport_id == 0, or convert
> that cport_id to an (interface, intf_cport_id) and pass the message to
> that interface's cport, something like that?
>
>      static int message_send(..., u16 cport_id, struct gb_message *msg, ...)
>      {
>      	if (cport_id == GB_SVC_CPORT_ID) {
>      		return svc_bridge_handle_msg(msg);
>      	} else {
>      		struct connection *connection = svc_bridge_get_connection(cport_id);
>      		// ... or you could directly look up in hd->connections,
>      		// the whole list of connections is already there, so
> 		// no need to maintain another one separately
>
>      		// somewhow convert connection->intf to an i2c address
>      		// and use connection->intf_cport_id to address the cport
>      		i2c_transfer(adap, msgs, 1);
>      	}
>      }

Yes, that's the basic idea. The APIs will probably look a bit different, 
but let me see how much info linux greybus module already has.

>>      ```
>>          +-------------+                +-----------+
>>          | AP / SVC    | <--- I2C --->  | Module    |
>>          +-------------+                +-----------+
>>                                          |
>>                                          |             +----------+
>>                                          `-- I2C --->  | Module  |
>>                                                        +----------+
>>      ```
> You mention in point 2 that i2c slaves cannot initiate communication, so
> I wonder how you would emulate the "MODULE_INSERTED" that flows from SVC
> to the AP. Would your HD poll the bus for connected modules and "send" a
> MODULE_INSERTED for each of them?
>
> Besides that, I think it would work fine. I'll be happy to test and
> review your patch when ready.
>
> Regards,
> damien


I am currently thinking of having a debugfs entry to manually add and 
remove modules for the demo I am working on. Generally, I would prefer 
not doing continuous polling on linux. But I am thinking of doing the 
polling based discovery on the driver probe.


Best Regards,

Ayush Singh

Re: [RFC] greybus: support combined Host + SVC

[Ayush Singh]

On 3/3/26 11:55 AM, Ayush Singh wrote:

> On 3/3/26 3:27 AM, Damien Riégel wrote:
>
>> On Sat Feb 28, 2026 at 8:47 AM EST, Ayush Singh wrote:
>>> 2. SVC per node
>>>
>>>      Each node implements its own SVC. Since an I²C slave cannot 
>>> initiate
>>> communication, the AP must already know the address of each SVC/module.
>>> This also seems inefficient when chaining multiple nodes.
>>>
>>> [...]
>>>
>>> 3. SVC/Bridge functionality inside the AP
>>>
>>>      For this use case, this seems to be the most practical option.
>>>
>>>      To clarify, I am not proposing any new data paths in the Greybus
>>> pipeline. The idea is to have a reusable an SVC/bridge implementation
>>> similar to what exists in greybus-zephyr [2][3], but hosted within 
>>> the AP.
>> We discussed internally at Silicon Labs of this solution to get rid of
>> the SVC on the device but haven't actually implemented it, good to know
>> that we were not alone. I think it's a great avenue to explore because
>> it keeps existing SVC code as is, so we keep a single data path in
>> Greybus' core while offering the capability to handle SVC requests on
>> the host.
>>
>> Just to help me get a better mental picture, in hd->message_send you
>> would either handle the message immediately if cport_id == 0, or convert
>> that cport_id to an (interface, intf_cport_id) and pass the message to
>> that interface's cport, something like that?
>>
>>      static int message_send(..., u16 cport_id, struct gb_message 
>> *msg, ...)
>>      {
>>          if (cport_id == GB_SVC_CPORT_ID) {
>>              return svc_bridge_handle_msg(msg);
>>          } else {
>>              struct connection *connection = 
>> svc_bridge_get_connection(cport_id);
>>              // ... or you could directly look up in hd->connections,
>>              // the whole list of connections is already there, so
>>         // no need to maintain another one separately
>>
>>              // somewhow convert connection->intf to an i2c address
>>              // and use connection->intf_cport_id to address the cport
>>              i2c_transfer(adap, msgs, 1);
>>          }
>>      }
>
> Yes, that's the basic idea. The APIs will probably look a bit 
> different, but let me see how much info linux greybus module already has.
>
>>>      ```
>>>          +-------------+                +-----------+
>>>          | AP / SVC    | <--- I2C --->  | Module    |
>>>          +-------------+                +-----------+
>>>                                          |
>>>                                          | +----------+
>>>                                          `-- I2C --->  | Module  |
>>> +----------+
>>>      ```
>> You mention in point 2 that i2c slaves cannot initiate communication, so
>> I wonder how you would emulate the "MODULE_INSERTED" that flows from SVC
>> to the AP. Would your HD poll the bus for connected modules and "send" a
>> MODULE_INSERTED for each of them?
>>
>> Besides that, I think it would work fine. I'll be happy to test and
>> review your patch when ready.
>>
>> Regards,
>> damien
>
>
> I am currently thinking of having a debugfs entry to manually add and 
> remove modules for the demo I am working on. Generally, I would prefer 
> not doing continuous polling on linux. But I am thinking of doing the 
> polling based discovery on the driver probe.
>
>
> Best Regards,
>
> Ayush Singh


I do have a working SVC kernel module now [0]. Need to brush up some 
things on I2C transport side, but the svc node code seems to be in good 
state. Tested with BeagleConnect Freedom running Greybus-Zephyr over I2C.


Best Regards,

Ayush Singh


[0]: 
https://github.com/Ayush1325/linux/blob/b4/gb-i2c-transport/drivers/greybus/svc_node.c