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-gui…
[2]:
https://github.com/beagleboard/greybus-zephyr/blob/main/subsys/greybus/svc.…
[3]:
https://github.com/beagleboard/greybus-zephyr/blob/main/subsys/greybus/apbr…
Standardize code in the file:
drivers/staging/greybus/Documentation/firmware/authenticate.c
by making the following changes:
1. Remove redundant 'int' from 'unsigned long long int' as suggested by
checkpatch when printing the obtained device UID:
printf("UID received: 0x%llx\n", *(unsigned long long *)(uid.uid));
2. Fix alignment of multi-line printf statement to match opening
parentheses:
printf("Authenticated, result (%02x), sig-size (%02x)\n",
authenticate.result_code, authenticate.signature_size);
Signed-off-by: Prithvi Tambewagh <activprithvi(a)gmail.com>
---
drivers/staging/greybus/Documentation/firmware/authenticate.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/staging/greybus/Documentation/firmware/authenticate.c b/drivers/staging/greybus/Documentation/firmware/authenticate.c
index 3d2c6f88a138..ba4b16b04557 100644
--- a/drivers/staging/greybus/Documentation/firmware/authenticate.c
+++ b/drivers/staging/greybus/Documentation/firmware/authenticate.c
@@ -58,7 +58,7 @@ int main(int argc, char *argv[])
goto close_fd;
}
- printf("UID received: 0x%llx\n", *(unsigned long long int *)(uid.uid));
+ printf("UID received: 0x%llx\n", *(unsigned long long *)(uid.uid));
/* Get certificate */
printf("Get IMS certificate\n");
@@ -85,7 +85,7 @@ int main(int argc, char *argv[])
}
printf("Authenticated, result (%02x), sig-size (%02x)\n",
- authenticate.result_code, authenticate.signature_size);
+ authenticate.result_code, authenticate.signature_size);
close_fd:
close(fd);
base-commit: eb71ab2bf72260054677e348498ba995a057c463
--
2.34.1
This series cleans up dead code in the Greybus audio manager.
gb_audio_manager_get_module() has no in-tree callers. The previously
reported NULL dereference is therefore unreachable. Per review feedback,
the unused function is removed to avoid carrying dead code.
Patch 2 performs a small cleanup in the same area.
Changes in v3:
- Replaced the NULL-deref fix with removal of gb_audio_manager_get_module()
since there are no in-tree callers (per Greg KH).
- No functional changes otherwise.
Thanks for the review.
Signed-off-by: Hardik Phalet <hardik.phalet(a)pm.me>
Hardik Phalet (2):
staging: greybus: audio: remove unused gb_audio_manager_get_module()
staging: greybus: audio: drop stale TODO comment
drivers/staging/greybus/audio_manager.c | 12 ------------
drivers/staging/greybus/audio_manager.h | 7 -------
drivers/staging/greybus/audio_manager_module.c | 1 -
3 files changed, 20 deletions(-)
--
2.53.0