On Wed May 21, 2025 at 10:46 PM EDT, Alex Elder wrote:
On 5/14/25 5:52 PM, Damien Riégel wrote:
On Tue May 13, 2025 at 5:53 PM EDT, Andrew Lunn wrote:
On Tue, May 13, 2025 at 05:15:20PM -0400, Damien Riégel wrote:
On Mon May 12, 2025 at 1:07 PM EDT, Andrew Lunn wrote:
On Sun, May 11, 2025 at 09:27:33PM -0400, Damien Riégel wrote:
Hi,
This patchset brings initial support for Silicon Labs CPC protocol, standing for Co-Processor Communication. This protocol is used by the EFR32 Series [1]. These devices offer a variety for radio protocols, such as Bluetooth, Z-Wave, Zigbee [2].
Before we get too deep into the details of the patches, please could you do a compare/contrast to Greybus.
Thank you for the prompt feedback on the RFC. We took a look at Greybus in the past and it didn't seem to fit our needs. One of the main use case that drove the development of CPC was to support WiFi (in coexistence with other radio stacks) over SDIO, and get the maximum throughput possible. We concluded that to achieve this we would need packet aggregation, as sending one frame at a time over SDIO is wasteful, and managing Radio Co-Processor available buffers, as sending frames that the RCP is not able to process would degrade performance.
Greybus don't seem to offer these capabilities. It seems to be more geared towards implementing RPC, where the host would send a command, and then wait for the device to execute it and to respond. For Greybus' protocols that implement some "streaming" features like audio or video capture, the data streams go to an I2S or CSI interface, but it doesn't seem to go through a CPort. So it seems to act as a backbone to connect CPorts together, but high-throughput transfers happen on other types of links. CPC is more about moving data over a physical link, guaranteeing ordered delivery and avoiding unnecessary transmissions if remote doesn't have the resources, it's much lower level than Greybus.
As is said, i don't know Greybus too well. I hope its Maintainers can comment on this.
Also, this patch adds Bluetooth, you talk about Z-Wave and Zigbee. But the EFR32 is a general purpose SoC, with I2C, SPI, PWM, UART. Greybus has support for these, although the code is current in staging. But for staging code, it is actually pretty good.
I agree with you that the EFR32 is a general purpose SoC and exposing all available peripherals would be great, but most customers buy it as an RCP module with one or more radio stacks enabled, and that's the situation we're trying to address. Maybe I introduced a framework with custom bus, drivers and endpoints where it was unnecessary, the goal is not to be super generic but only to support coexistence of our radio stacks.
This leads to my next problem.
https://www.nordicsemi.com/-/media/Software-and-other-downloads/Product-Brie... Nordic Semiconductor has what appears to be a similar device.
https://www.microchip.com/en-us/products/wireless-connectivity/bluetooth-low... Microchip has a similar device as well.
https://www.ti.com/product/CC2674R10 TI has a similar device.
And maybe there are others?
Are we going to get a Silabs CPC, a Nordic CPC, a Microchip CPC, a TI CPC, and an ACME CPC?
How do we end up with one implementation?
Maybe Greybus does not currently support your streaming use case too well, but it is at least vendor neutral. Can it be extended for streaming?
I get the sentiment that we don't want every single vendor to push their own protocols that are ever so slightly different. To be honest, I don't know if Greybus can be extended for that use case, or if it's something they are interested in supporting. I've subscribed to greybus-dev so hopefully my email will get through this time (previous one is pending approval).
Greybus was designed for a particular platform, but the intention was to make it extensible. It can be extended with new protocols, and I don't think anyone is opposed to that.
Unfortunately, we're deep down the CPC road, especially on the firmware side. Blame on me for not sending the RFC sooner and getting feedback earlier, but if we have to massively change our course of action we need some degree of confidence that this is a viable alternative for achieving high-throughput for WiFi over SDIO. I would really value any input from the Greybus folks on this.
I kind of assumed this. I'm sure Andrew's message was not that welcome for that reason, but he's right about trying to agree on something in common if possible. If Greybus can solve all your problems, the maintainers will support the code being modified to support what's needed.
(To be clear, I don't assume Greybus will solve all your problems. For example, UniPro provides a reliable transport, so that's what Greybus currently expects.)
I don't really know about UniPro and I'm learning about it as the discussion goes, but one of the point listed on Wikipedia is "reliability - data errors detected and correctable via retransmission"
This is where CPC could come in, probably with a different name and a reduced scope, as a way to implement reliable transmission over UART, SPI, SDIO, by ensuring data errors are detected and packets retransmitted if necessary, and be limited to that.
What's missing for us in Greybus, as discussed in a subthread, is asynchronous operations to fit better with the network stack, but I think that could easily be added.