Re: [PATCH V3] greybus: gb-beagleplay: Ensure le for values in transport

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 




On 12/6/23 20:22, Alex Elder wrote:
On 12/5/23 2:32 PM, Ayush Singh wrote:
On 12/6/23 01:15, Greg KH wrote:

I'm confused, what exactly is needed here to be sent that isn't in the
existing message definition.

And as to your original statement, the protocol definition was not
designed for any specific use case that would make IoT "special" here
that I can see.  It was designed to provide a discoverable way to
describe and control hardware on an unknown transport layer for devices
that are not discoverable by definition (serial, i2c, etc.)

The fact that we implemented this on both USB and unipro successfully
provided that the transport layer for the data should be working and
agnositic.

thanks,

greg k-h

So, the missing information is the AP cport which is sending the message/for which the message is intended. Each AP cport will be connected to a cport in some greybus node. For a simple case like USB, where AP can directly talk to the node, and we do not really need the cport information outside of kernel driver.

I think I lack some context here, but as Greg said Greybus
is intended to be a pure transport, and anything using it
should be able to get all information it needs as a layered
protocol on top of it.

If the BeaglePlay stuff requires CPort information, it sounds
like it's not managing the layering of abstractions properly.
Well, I used gbridge as a reference during my GSoC work. So I just followed it's lead of using pad bytes for cport information.

I think under normal circumstances, the kernel driver is supposed to directly communicate with the node. However, in beagle play, the subghz transport is only present in CC1352 coprocessor. This means CC1352 needs to act as the middle man between AP and node (aka perform the APBridge tasks). So it needs to maintain a way to keep track of all active greybus connections, and route the messages between AP and Node cports.

I am not quite sure where SVC is supposed to be in Linux kernel greybus setup. Since SVC needs to be able to detect module insertion/removal, it needs to be able to access the same transport as APBridge. Thus, CC1352 (and gbridge in old setup) are responsible for both SVC and APBridge roles.

It sounds like CC1352 is serving in an SVC role... sort of? Again, I don't have enough context right now to understand.

Greybus was developed for a particular hardware platform, and it
included an SVC.  The SVC was an independent processor that managed
the "endo", or the basic hardware "backplane" that held modules).
The AP bridge was how the AP connected to that, and the GP bridge
was how a given module interface connected to that.

It seems to me (this is partly from an impression I had a few years
ago) that the BeaglePlay model doesn't align perfectly with that.
And if that's the case, we need to figure out how to resolve any
mismatches.

(I'm not sure this is very helpful, but it's a little background.)

                    -Alex

Yes, the BeaglePlay (and older gbridge) model does deviate from that. You can read more about beagle connect technology here [1] and the initial presentation [2].

However, to put it simply, it is trying to use greybus over transports other than Unipro. This means we do not have a Unipro switch. Instead, we use a coprocessor (CC1352) running specialized firmware to handle all the things Unipro switch would.

The current focus is 6lowpan (due to it's range). However, CC1352 also has a 2.4 and 5 ghz antenna, so in the future, that might also be used for transportation.

Since I am not much aware of greybus use outside of beagle connect, I do not have much knowledge of how it is supposed to be used in a traditional setting.

I have submitted new patches that remove the need for using pad bytes.


Ayush Singh


[1]: https://docs.beagleboard.org/latest/projects/beagleconnect/index.html

[2]: https://www.youtube.com/watch?v=7H50pv-4YXw

_______________________________________________
greybus-dev mailing list -- greybus-dev@xxxxxxxxxxxxxxxx
To unsubscribe send an email to greybus-dev-leave@xxxxxxxxxxxxxxxx




[Index of Archives]     [Asterisk App Development]     [PJ SIP]     [Gnu Gatekeeper]     [IETF Sipping]     [Info Cyrus]     [ALSA User]     [Fedora Linux Users]     [Linux SCTP]     [DCCP]     [Gimp]     [Yosemite News]     [Deep Creek Hot Springs]     [Yosemite Campsites]     [ISDN Cause Codes]     [Asterisk Books]

  Powered by Linux