On Mon, Dec 05, 2016 at 03:53:58PM +0000, Bryan O'Donoghue wrote:
On 05/12/16 15:41, Greg KH wrote:
On Mon, Dec 05, 2016 at 03:29:43PM +0000, Bryan O'Donoghue wrote:
On 05/12/16 15:20, Jim Wylder wrote:
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
I guess another approach to take is to start to cherry-pick the Moto Z patches and
- Ensure they don't break what we have upstream
- Try to add parallel support to gbsim to validate them
- The spec would definitely need some hand-holding (alot of) hand holding
If we try to take the Moto Z sources in - the Greybus spec should reflect the integrated set ... after all a formal spec is a good thing.
I agree.
I want to bump the spec version number soon to make it a "released" spec, but I worry about this merge. Should I just cut what we have today in the spec as a 1.0, and then we work to make the merge "2.0" to allow everyone to work together better?
Seems like the right way to do it from my POV anyway. It makes sense to baseline on a V1 and then go a munge together a V2.
I'm not sure how everybody else feels about taking in the Moto Z stuff but, it seems to me as if its the best fit for adding different transport layers while continuing to support UniPro anyway...
I want to get the two codebases, and specs, in sync as the Moto Z is important, being the first shipping implementation of this stuff. Having a fork that goes off on its own doesn't help anyone here, and will only cause confusion and duplicated effort over time.
Oh, and for those that might have missed it, we now have a proper license for the spec and implementing the spec, so everyone should be happy: https://github.com/projectara/greybus-spec/commit/7c76600bcbc372e35d1f654c12...
can't have been easy getting all that legalese done officially
You have no idea... :)
thanks,
greg k-h