[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