[Gta04-owner] GTA04-Kernel 3.17.0

Dr. H. Nikolaus Schaller hns at goldelico.com
Mon Oct 27 10:15:09 CET 2014

Hi Neil,

Am 26.10.2014 um 22:50 schrieb NeilBrown <neilb at suse.de>:

> On Sun, 26 Oct 2014 13:22:03 +0100 "Dr. H. Nikolaus Schaller"
> <hns at goldelico.com> wrote:
>>> I've also added a proof-of-concept for a new approach to managing devices
>>> attached via UART.
>> Please can you describe how it works in detail? We are currently discussing on
>> LKML (and you are on CC:) to upstream the “old” approach and it would be nice
>> for that discussion if we knew it.
> There a comments in the commit, and the code is fairly simple, however:
> Any uart in devicetree can have a child device listed.
> e.g.
> &uart1 {
> 	bluetooth {
> 		compatible = "tty,regulator";
> 		vdd-supply = <&vaux4>;
> 	};
> };
> That device is probed as a platform-device.  The resulting device is attached
> to the driver-model tree as a child of the tty device (itself a child of the
> uart device).
> The probe function of this platform-device can call new function
> tty_set_slave():
> 	err = tty_set_slave(pdev->dev.parent, &pdev->dev, &tty_reg_ops);
> "tty_reg_ops" is a struct of function pointers so that the tty can tell the
> driver when interesting things happen.
> Currently there is just an ‘open’ and a 'close'.  

Ok. It changes user-space behaviour a little that you can’t enable/disable
the GPS through tcsetattr/ioctl by modifying the DTR line - but that is something
I don’t care. Because I assume that gpsd is not using this “feature”.

> I expect to add "receive"
> or similar so a driver for the GPS can know when data is being received.

Ah, ok. One thing to be solved is that for GPS we just need to know if we
receive something in case the uart is closed. The question is how that can
be properly represented in the uart driver. I don’t know how that work there.
E.g. if receive interrupts are disabled and the uart is powered down if it
is closed.

> As I said, this is just a proof-of-concept.  I'll very likely change the
> exact behaviour and possibly even the names of 'open' and 'close' before I am
> happy with it.  At the very least I need to add some locking.
> Then we can see if Mark Rutland and others can be made to be happy.

Well, before discussing with them it must be complete and work for the
GPS chip. Including the pinmux/interrupt thing or a good replacement of it.

>> While I really appreciate what you have done, I am not happy at all how we
>> coordinate work in our small community.
> I guess we see things quite differently.  In terms of kernel development, I
> don't see us as a small community, but as a small part of a big community -
> the kernel community.  Or maybe as a small part of several communities:
> devicetree, omap, mmc, tty, …..

Yes if you see kernel developers as a community.

But you can name the subset of kernel developers who are interested in the
GTA04 on one hand. This is what I mean with “our small community”.

So I don’t excpect the device tree, omap, mmc, tty community members to
contribute anything specific for the GTA04. They just do general things which
might make our life easier (because e.g. OMAP3 is used elsewhere) to adapt
the mainline kernel to the GTA04.

>> In fact: we do not coordinate it at all (or don’t use the existing tools).
> *The* way to co-ordinate in kernel development is to get code upstream.

Why can’t we do better by discussing things before they are submitted upstream?

> I very much appreciate the work you and Marek have been doing in getting
> things upstream - it helps me a lot.  Thanks.
>> Even where a bug tracker exists: http://projects.goldelico.com/p/gta04-kernel/issues
>> and is just waiting to be used (someone can be registered to be the “owner” of the
>> issue and everyone else knows that there is already someone working on it).
> I hate bug-trackers - sorry.
> They do have a place in commercial settings - they can be used to track
> things that no-one wants to work on.  And then be used as leverage to force
> people to do particular work.

Yes, in commercial setup they are used to force people to do the necessary things.

But we still can use it for reference. And just ask people for self-commitment.

E.g. if I think I want to solve the GPS driver issue, I make it public by self-committing
me on the issue tracker. So that others know that I am working on it.

Contrary to the commercial setup there is still no deadline and hence no force involved.

But I also want to remind that Debian *has* an heavily used Issue tracker - although it
is not a commercial setup.

I would say that an issue tracker should be used if we are interested in getting
high quality code. I.e. remove all bugs. Independently of commercial vs. volunteer.

My goal is to get rid of all these nasty bugs that are stored in the issue tracker. Not
only those that I want to remember and work on :)

> But in the GTA04 world, I just work on what I want to work on, and I don't
> need an issue tracker to remind me.

It can also be used as sort of a “forum” where ideas and background material
can be changed.

>  If someone has a problem I expect them
> to post about it to the list (which they do).  If it interests me, I'll look
> at it.  If not, not.

Some projects copy messages and changes from the issue tracker to the project
mailing list. So that they are jsut two different interfaces between people and some
collective memory.

>> So you expect us to go through your patches and find out what is duplicate and
>> what is really new.
> I don't expect you do to anything.  I’m just letting you know as a courtesy.


> As I said, I plan to push these things upstream.
> For the omap3-gta04.dts patches I would certainly negotiate with Marek.
> For the little bug-fixes in a couple of input drivers I would just send them
> to the input maintainer.

This is exactly the duplication of work I suggest we should avoid.

For example if we take the vibra device tree modification, we already had sent
them to LKML in a big GTA04 batch. We got the feedback that this is too much
and we should submit small patches later.

>  The MMC patches to the MMC maintainer.  etc.
> I'll Cc all the patches to this list if you like (in fact I will now unless
> someone asks me not to).

Yes, I welcome this.

>> Our process is only coming from the other side of the street. We are not building
>> up something ion top of mainline, but tracking mainline and reducing the differences.
>> The question I have is: what is bad with this approach?
>> Currently we have approx, 131 different upstreamable files between gta04-3.18.rc1
>> and linus/v3.18-rc1 (some diffs are not even GTA04 related but for the Pyra handheld).
>> If you want I can generate the list.
> I can generate lists too.  Your tree (As of commit d10f2ada5789e5e4 on Oct
> 9th) has 911 non-merge commits that are separate from mainline.
> Some of them are nice clean patches,

most of them are in the discussion stage on LKML.

> some of them a reverts of other patches,

Yes, because things did not work as expected. or things had to be fixed a second time
during testing. This is why I don’t count the non-merge commits but the number of files
reported by git diff. This does only show if there really is a difference. I think there are
even one or two files where only formatting is different. In that case we could simply
switch to the linus/master version and the diff disappears - forever.

> some are temporary hacks,

because we want to have it working 100% first before submitting to mainline.

> some are (as you say) for devices that I don't care
> about.

Yes. You should not have to care about them (unless you want to own one in some

The main reason is that form a GTA04++ project management point of view it
is important to have a single project repo and kernel that covers all device variants.
Everything else would become (and was) a nightmare.

> My goal has always been to have mainline Linux running on my phone.  

Ok, there is a small but important difference: I do not only want mainline Linux
running on my phone but have all features that I previously had. But I don’t
want to reimplement them from time to time. This is probably the main reason
why we did end up with this rolling development model.

> I
> haven't got there yet, but the number of commits of difference is getting
> smaller.

The same is true for the gt04-kernel.

> Using your kernel would (in my mind) be a step in the wrong
> direction.

Why that?

It does move away (“wrong direction”) from mainline only in two cases: if we
add a new feature (e.g. implement camera with device tree) or fix a bug.

The upstreaming process reduces the differences.

And if you want to develop a new and clean implementation of a subsystem or feature,
you could look up the differences to linus/master first, then checkout the originals
from linus/master, commit once (to get a log record for throwing away previous work)
and start from there until it works.

With this approach you would still be based on linus/master for a specific subtree but
all the other goodies would be immediately available to you. Without a need for
reimplementation (where others already have invested time and work).

> It is probably just a different development model.  

Yes. It is IMHO better suited for collaboration on patches. With people who are
better in just fixing bugs or adding new features while others are good
in formatting patches for upstreaming and running the discussion on LKML.

So one group is for making things work (you could call it “unstable”) and the
other for making it into mainline (“stable”).

> You seem to just
> accumulate stuff in your tree, occasionally

Exactly. There is a well defined occasion: if a subsystem has been tested and is complete.

> send things upstream, then
> resolve conflicts when changes appear in upstream.

Basically we have this equation:

neil-brown-kernel = 3.17.0  + set of clean patches to make 70% of things work on GTA04
gta04-kernel = linus/master + set of (non-clean) patches to make 100% work on GTA04 + make it work on other devices

> I don't like to work like that.  I like to keep a well defined set of patches
> on-top of mainline.

Ok, this is a slight difference - but it only works if you are the only developer
working on your well defined set of patches.

The gta04-kernel tree also has a defined set of patches on-top of mainline.

But not necessarily “well defined”. We do this reformatting afterwards before submission.

And, we (we = team of http://projects.goldelico.com/p/gta04-kernel/) also merge the reformatted
changes. So just before submission, the non-clean tree becomes identical to the clean tree. And
is tested as well.

With this model, it still shows the real history of patches (including the deviations of work) from a single
“clean patch”. And, it gives proper attribution to those who have contributed to make it work.

Finally I do not expect these changes to appear in Linus’ history.

>  I go back and revise the patches when I find problems
> (stgit is good for that).

I never heard about stgit. After looking what it does I have a little the impression that
it tries to keep the pre-git aera of quilt alive. Since I have never worked with it, this approach
does not look familiar to me. 

We simply handle patch-sets a little different: we just commit to our git branches and don’t work
on patch sets during development and testing. Patch sets for LKML will be formatted in the reshaping
phase before going upstream.

>  So when I send a patch upstream, it is exactly a
> patch that I have been testing against as-pure-as-possible mainline code.

Yes, this is what I meant with “we come from the other end”.

We aim at having a (rebased on linus/master) kernel plus all changes needed to make
it work. And then take these changes and reformat into patches for inclusion in linus/master).
As soon as it is included in linus/master, we will “merge” what we already have, and the
difference becomes zero.

Therefore the goal is to start upstreaming missing pieces from a feature complete tree.
Instead of rebuilding patches over and over again to make it feature complete.

>> And the goal and process of the GTA04 project is to get this number up by fixing the
>> remaining bugs and getting it down by upstreaming things that work.
>> So I am quite reluctant to go through your tree and look for useful things we could
>> integrate. And might have to invest a lot of time until they can be merged without conflicts.
>> Rather I invite you to provide patches against our 3.18-rc1 (or rc2 on Monday) that include
>> your experiences and knowledge (which both is very welcome).
> I'll be sending patches upstream.  With luck they'll get in 3.19-rc1, and you
> will get them when you pull that in.
> When the patches for powering on/off bluetooth and gps are ready, I'll
> certainly include you when I post them for discussion.
>> Sorry if I am a little upset and apologise if I did understand something wrong.
> No problem.  We do certainly have different perspectives on some things, but
> I’m sure we can still work together productively.


My main concern is that we could be even more productively work together if we
discuss such development models (which have relevance for quality, feature
completeness and testing) and maybe could agree to work on a single repository
in the future. And if we submit patches upstream as a group and not as individuals.

Here we are in the informal part of a network of git repos - how do patches flow
around and how are conflicts solved. Who is testing what repo. And how does it
fit into the hierarchy which ends at kernel.org?

My idea would be:

marek belisko
+ neil brown 
+ nikolaus schaller
+ others    —-> gta04-kernel —-> reformatting —-> upstreaming —-> linus/master  —-+
instead of
neil brown ————————————————————^

(I hope the drawing is readable)

Maybe another idea would be if you could (additionally) rebase your patches on top
of the gta04-kernel it could be as simple as a git pull from your server to merge them in.

But this is only a proposal. You do not have to accept it. I can just invite you.


More information about the Gta04-owner mailing list