Reconcile with kernel.org version

[gregkh]

Hi all,

Now that the greybus driver subsystem is merged into the upstream kernel.org trees (it is in linux-next at the moment, should show up in 4.9-rc1), how do you want to go about reconciling this branch with the upstream versions of the files? We have only minor differences from what I can see, and a new camera driver, which is great. Any plans of sending this back for review and acceptance?

[gregkh]

I am talking to you, the owners of this repo, with the fork of the greybus code. It differs now from what is in the Linux kernel tree, how is that going to be resolved? Do you need help with that effort?

[charleseb]

Hi Greg Kroah-Hartman,

I'm checking the best way to handle this.

---

Thanks, Charles

On Fri, Sep 23, 2016 at 8:57 AM, Greg Kroah-Hartman < notifications@github.com> wrote:

I am talking to you, the owners of this repo, with the fork of the greybus code. It differs now from what is in the Linux kernel tree, how is that going to be resolved? Do you need help with that effort?

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/MotorolaMobilityLLC/motorola-external-greybus/issues/2#issuecomment-249173031, or mute the thread https://github.com/notifications/unsubscribe-auth/ALhvzQvT56BUQ85kAs1bjQ5rsXGmcBeYks5qs76PgaJpZM4KEu8i .

[jwylder1]

We would definitely be interested in working towards reconciling the differences between the two code bases. That said, there are a lot of details to work out that we would need your help and advice with. Probably the first concern would be what type of hardware target would we work to support. Currently our phone's base kernel lags behind the latest and relies on a few hardware specific implementation details to create a working device. On the other hand, I don't believe the upstream Ara project released any hardware publicly that could be used as a reference. Are there any future plans for the Ara/GMP code base that we would want to coordinate with?

One possible solution would be to create a third platform (Raspberry Pi Hat?) that might represent the coordinated reference?

Other issues:

Protocol Changes: We had to freeze our code base in January and lost out on some good protocol changes made upstream, but they were made in without support for backward compatibility. We would have to come up with an approach that would handle changes such as the replacement of battery with the power supply protocol.

Bridge Interfaces: Some of our protocols (Display, Audio, USB-ext) use a bridge interface to connect with internal kernel functions. There were some changes that would cause dependency problems. These would need to be cleaned up. If these protocols were interesting to upstream.

TTY Interface: For support to our APBA chip on the phone side, we exposed a few calls into the tty subsystem that will probably viewed as unacceptable.

Switch/Networking: Our hardware does not have a separate physical switch for routing to multiple destinations. We added support in our implementation to do this in the kernel.

SVC: This is done in our kernel since we don't have a separate SVC chip.

[ohporter]

Are any of the shipping or announced Moto Z variants able to be used as a kernel development platform by others in the community? It would help to have information on replacing the kernel and getting access to a debug UART to allow others to help out getting general Moto Z support as well as these forked bits of greybus upstream.

[gregkh]

There is the virtual simulator of the greybus protocol, gbsim, which could be used as a place to unify things (and for testing), that runs very well on a beaglebone black, and is what we used for initial prototyping as well as semi-automated testing with a virtual machine image.

Yes, we know about the protocol changes, and we should be able to handle them by versioning the protocol (there is a version, but we don't check for it...) Adding support to the kernel side for that shouldn't be that difficult and would allow both types of devices to run at the same time.

Battery vs. Power supply is interesting, we ran into problems with the battery protocol, hence the use of power supply instead. I have no problem bringing back battery if it turned out to be useful to you, should be pretty simple to do that.

I am interested in your new protocols (display, audio, usb-ext), and would like to see them brought in to make things more unified if at all possible. Perhaps spec changes would be the easiest way forward for those things? I'll gladly take patches for our spec to help out with this.

TTY: what type of hooks in the tty layer were needed? Have a pointer to some commits that I could see to get an idea? Being the upstream tty maintainer, I am interested in that :)

As for the switch and svc, I understand your system is different here, and future systems will also not have a switch (there is a Greybus over IP prototype being shown in a few weeks), so integrating support for no svc and "simple" networks is something we would love to do.

[jhrycay]

I think there are a lot of sub-items being discussed so will try to address them all:

1) At this current time there are no 'developer' editions of the Moto Z and I can't speak to if there are any planned in the future for the phone side of development. Perhaps, as Greg suggested, the gbsim would be the common point for validation, but its not something we've used either since early prototyping.

---

2) Battery/PTP versus power supply; we always planned to align with upstream greybus on the protocols and would have rather migrated to the power supply version but at the time of your transition we had already begun internal testing of devices with the battery/PTP already in use. It was then decided to stick with our implementation for better or worse.

The problem now arises is that BATTERY and POWER SUPPLY protocols would share the same protocol identifier. It might be alleviated if the major version was bumped in your tree to 1.0 for POWER SUPPLY so that our major version 0 of BATTERY would not find a match.

As you mentioned the protocol version matching would need to be added which we did add with commits such as:

protocol: Only drop protocol ref on success protocol: Only allow one major per protocol protocol: Negotiate the protocol driver to use protocol: Add 'get_latest' supported protocol

Mind you they were designed in attempt to minimize changes to the upstream greybus code to allow us to rebase onto your HEAD as pain-free as possible. Although, we ended up freezing back in January making that effort moot. So it could be re-written and integrated better.

---

3) As far as our other added protocols (camera, display, usb, audio, etc), they are pretty much control protocols that tell our 'mods' how to behave in order to interact with additional hardware connections; i.e USB with D+/D-, Audio with I2S, Display with myDP, etc. They really only make sense for hardware which has these additional signals routed to the external 'mod'. It's not sending any of the actual payload data over greybus.

---

4) For TTY, the commit we used to export some functions/structures is here:

tty: Minor changes to allow kernel modules to use tty ports

At the time it was planned to route greybus over UART to our "APBA" but it eventually just became a custom control protocol. However, we still needed ability at a driver level to access read/write/ioctl capabilities; perhaps there exists a better way to accomplish this that we'd happily move towards.

---

5) For the software switching and SVC, these again were both designed with the idea to minimize changes to the upstream greybus implementation and allow us the ability to route greybus traffic over various busses at the same time: UART, I2C, SPI, and in theory whatever else we came up with. In the final shipping configuration only a single bus is ever used for greybus at a time. As such, the SVC could have just as well been implemented over on the MOD side, but we do have the flexibility to extend this now in the future.

---

There are a few other changes that are probably fine with some updates to send upstream for memory leaks, minor bugs, etc. We're still looking at the last push you made a few weeks ago to see which are still applicable as some are already fixed on your side as well.

-jason

[vinimed]

Ticket is too old. If you are still interested on request, please re-open the issue.