Unipro is quite capable of using i2c as a control path, but the ARM processor on the TSB doesn't have enough power gates. We have to completely power off the TSB to meet current drain targets for idle state. We do not currently have a gbsim. Jim On Mon, Dec 5, 2016 at 9:06 AM, Bryan O'Donoghue <pure.logic@xxxxxxxxxxxxxxxxx> wrote: > 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
|