In a classic Greybus topology, there is an application processor, an SVC, and one or more modules, all connected to a UniPro bus. Most of the time, as the application processor doesn't have a UniPro interface, it is actually connected to a device acting as a bridge with the bus, and this bridge also acts as the SVC.
Sometimes, there is no UniPro bus at all, like for the BeaglePlay, which has the following topology:
+----+ +------------+ +--------+ | AP | <--- UART ---> | SVC/Bridge | <--- 802.15.4 ---> | Module | +----+ +------------+ +--------+ | | +--------+ `------------ 802.15.4 ---> | Module | +--------+
There are two main interesting aspects with Greybus: - the SVC protocol to monitor and configure the bus - other protocols, to expose module peripherals to the host
When the bus has a single module connected directly to the AP, then this module must also implement the SVC protocol:
+----+ +------------+ | AP | <--- bus ---> | SVC/Module | +----+ +------------+
The SVC doesn' really serve a purpose here, as there is no bus to manage, and adding its support only increase the complexity and the code size needed on memory-constrained devices.
The goal of this patchset is to let a single module expose some Greybus protocols without requiring the module to also implement SVC protocol. We call this mode "Point-To-Point". There are three main notable facts with the implementation of this patchset:
- most of the time, what this patchet does is just skipping calls that issue commands to the SVC, as they are not applicable without an SVC
- CPort ID allocation is a bit different as there is no SVC/Bridge to do translation between AP address space and interface address space, so the patchset forces allocation of AP CPort IDs that matches the ones found in interface's manifest
- enumeration of a module is normally started by a "Module Inserted" event issued by the SVC. As the SVC is absent, the host device driver must manually call a function to start the enumeration
We tested this patchset with the gb-beagleplay driver, slightly tweaked to only keep the HLDC over UART part of the driver, connected over UART to an EFR32MG24 running BeagleBoard's implementation of Greybus-Zephyr [1].
In the discussion to integrate this module into Zephyr [2] (it's currently as separate module not part of the main Zephyr code base), there seems to be interest in being able to have a single-node device on the bus without SVC [3]. If some features that were implemented by the SVC are missing, we can consider adding more callbacks to the gb_hd_driver structure at a later time, and let drivers decide how they want to support these features.
[1] https://github.com/beagleboard/greybus-zephyr [2] https://github.com/zephyrproject-rtos/zephyr/issues/98259 [3] https://github.com/zephyrproject-rtos/zephyr/issues/98259#issuecomment-35613...
Damien Riégel (8): greybus: add P2P interface type greybus: let gb_interface_create take additional p2p argument greybus: force CPort ID allocation in P2P mode greybus: split module creation function greybus: add function create module in P2P mode greybus: make host API work without SVC greybus: add function to create SVC-less host device greybus: add function to probe p2p module
drivers/greybus/connection.c | 15 ++++-- drivers/greybus/hd.c | 80 +++++++++++++++++++++++++++---- drivers/greybus/interface.c | 72 ++++++++++++++++++++-------- drivers/greybus/module.c | 55 ++++++++++++++++++--- include/linux/greybus/hd.h | 6 +++ include/linux/greybus/interface.h | 4 +- include/linux/greybus/module.h | 1 + 7 files changed, 193 insertions(+), 40 deletions(-)