On 02/12/16 18:18, Jim Wylder wrote: > A couple of items about how Motorola used Greybus: > > We were rebasing on the upstream code, with hopes of maintaining > compatibility, but had to freeze before some significant changes > upstream. > > We added support to make greybus less dependent on unipro by adding a > switching layer and SPI and I2C as transports. Interesting, that sounds a lot like what we were discussing here i.e. adding a new transport but, keeping the UniPro specific bits. Note: our greybus has some UniPro connection tear-down support that is probably worth keeping, though some of that is undoubtedly TSB specific quirkiness. > We also support unipro > but ended up not using greybus over unipro because the idle current on > the TSB was too high to leave up when not actively transmitting high > speed data. So we don't use unipro for greybus. > > We ended up using greybus primarily as a control channel for other > speed buses (mydp, csi and dsi over unipro, usb), but also for a few > low speed protocols like battery and lights. Funny. On connection tear down I was always of the opinion UniPro could do with a simple side-band/control path - like i2c or whatever - you've done it the other way around :) > We faked out the SVC to maintain compatibility and support multiple > module support. May not be how you would want approach the problem. I think most of the SVC stuff is very much specific to our particular PCB setup TBH. > The only portion of SVC we really utilized was the CREATE/DESTROY > messages in order to route traffic between the interface:cport pairs. > Everything else is either stubbed out or faked/hard-coded (i.e. DME > Attributes) to keep the core greybus initialization happy. I thought the DME attributes were TSB specific extensions - not actually UniPro per se. Do you have a functional version of gbsim ? If so maybe the most sensible way to try to integrate the two code bases is that way ? Our gbsim is ~reasonably~ representative I think (I may get laughed at for saying that)... If you had functioning gbsim for the Moto Z - we could integrate both simulators and the (just about) validate the integrated kernel code. > Protocol versioning required some changes to get to work as the > greybus implementation at the time of our fork was hard-coding > everything to 0.1. We had to add additional logic to support multiple > major versions and implement a 'best match' algorithm. This can > probably be done better as well as we were trying to minimize changes > to core greybus at the time. Understood. I wonder where we realistically begin trying to smoosh the two code-bases together - gbsim + parallel kernel work ? --- bod _______________________________________________ greybus-dev mailing list greybus-dev@xxxxxxxxxxxxxxxx https://lists.linaro.org/mailman/listinfo/greybus-dev
|