[Gta04-owner] GTA04-Kernel 3.17.0

Dr. H. Nikolaus Schaller hns at goldelico.com
Sun Oct 26 13:22:03 CET 2014


Hi Neil,

Am 26.10.2014 um 12:25 schrieb NeilBrown <neilb at suse.de>:

> On Mon, 6 Oct 2014 13:03:39 +0200 "Dr. H. Nikolaus Schaller"
> <hns at goldelico.com> wrote:
> 
>> Hi all,
>> Linus has released the Kernel 3.17.0 tonight and I have upgraded our kernel sources as well.
> 
> It's been a while .... but SUSE declared last week to be "hackweek" for the
> engineer so I combined it with a hackweekend and have been exploring 3.17.
> 
> I started with vanilla 3.17 - which boots and quite a lot works.  A lot has
> changed in the 12 months since I last spent much time on this - thanks for
> all the bits that have been pushed upsteam!
> 
> With a booting 3.17, I started looking for problems and fixing things, partly
> with reference to your kernel, but mostly just hunting around to try to
> understand what was going on.
> 
>> 
>> And, we still have not yet fixed all kernel bugs in our GTA04 extensions. Most notably are:
>> * WiFi power management
> 
> I spent about two days on this, mostly beating my head against a brick wall.

That is what we also do all the time :)

> I think I have it mostly working.  There are a couple of unresolved issues
> and I got the driver to hang a couple of times, but in general the power
> management works and I get 6Mb/sec.

Great!

> 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.

> I have the bluetooth powering up/down correctly.

Yes, that works as well in out 3.18 - so it is no big progress.

>  I haven't looked at GPS yet
> (ran out of time), but it should be fairly straight forward.

It works.

> 
> Strangely the bma150 driver isn't working properly even though it hasn't
> changed.  It always returns zeros.

Oops. 

> I looked at the code and  bma150_set_mode is basically a no-op, so I don't
> know how it ever worked.  But the iio bma180 driver works OK, so I'll use
> that.

Well, using the bma150 /dev/input driver for the bma180 in 3.7 and earlier was a real
hack and we simply were lucky because the bma180 does ignore the false write commands
that are issued assuming a bma150. The register set of both chips is *not* the same
and we just were lucky that the data registers are the same.

In fact the bma150 driver just happens to be able to read the bma180 if there is *no*
initialization in the kernel.

So if you get always 0, your bma180 is probably not initialized in auto-conversion
mode.

It is a known issue:

<http://projects.goldelico.com/p/gta04-kernel/issues/583/>

> 
> Things that I know don't work include:
> - gyroscope -- I get a strange i2c error
> - GSM audio routing
> - headset detection
> - camera, FM radio, TV-out .. all things that I have never used.

Yes, they all don’t work with device tree (but board file in 3.12.7).

> 
> I haven't tested the USB port at all as the socket broke off my test board.
> Similarly I haven't looked at charging much, so various enhancement aren't
> present.

Works.

> I also haven’t measured power usage.

The biggest power hog I currently know is WiFi - because it is not turned off if not needed.

> 
> I’ll try sending some of the simple stuff up-stream in the next week or two,

With upstream you mean to LKML?

Please do not do this!!!

It hurts much if we work on something for months and then someone else submits
something incompatible and reinveted directly to LKML without discussion. The worst
we have experienced was that the UART DTR driver was removed from upstream
because we were not informed or otherwise else involved in that discussion.

If you submit patches for our gta04 kernel here on this list (and I have asked the list
members several times for submitting patches) it is fine and really really welcome.

We will integrate them and then upstream. This is a much better flow of patches.

And IMHO a better answer to the question how we get to a new, feature complete
and bug free kernel for our GTA04 device.

> and hope to find time to get the audio working properly.  Then I'll try it
> on my main phone and see how it goes.

Yes, audio is an important task: 

<http://projects.goldelico.com/p/gta04-kernel/issues/587/>

> 
> The code can be found in the "3.17-gta04" branch of my git tree:
>  git://neil.brown.name/gta04
> 
> and
> 
>  http://git.neil.brown.name/?p=gta04.git;a=shortlog;h=refs/heads/3.17-gta04
> 
> it at least, it should appear there soon one the ‘git push' completes.

While I really appreciate what you have done, I am not happy at all how we
coordinate work in our small community.

In fact: we do not coordinate it at all (or don’t use the existing tools).

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).

After a first glance I see that you have reinvented several things we already have
solved because you have started from scratch on top 3.17.0 instead on our 3.18.

For example “add twl4030 vibra support”:

<http://git.neil.brown.name/?p=gta04.git;a=blobdiff;f=arch/arm/boot/dts/omap3-gta04.dts;h=6b034f9054112d880772a1f95f7fbfe4aaded5ae;hp=adfaf5586f940c83f7af1cf72d96adbf8ffc186e;hb=8edac826c45e648b610ab7df6119058dbe54709d;hpb=239cc5ebeb697ec2fb79a578f5afe0bac9fc0010>

It already works (and was tested) in the 3.18 kernel so you have done work that
we already have solved some months ago. It could have saved you some time and given
more to fix the bugs.

<http://git.goldelico.com/?p=gta04-kernel.git;a=blobdiff;f=arch/arm/boot/dts/omap3-gta04.dts;h=452abd040471f57226b8432485e02799b262a382;hp=ab27d496a60259f3145f2659c31a33facbdd62f1;hb=061f0323bcbd600aaa008f446e73ae50b7f09809;hpb=0da73e5f63e9f482e3aae1c0c66cb72e31c58ebd>

The only missing piece is to get it upstream. Not writing a completely new patch
with slightly different formatting.

So you expect us to go through your patches and find out what is duplicate and
what is really new.

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.

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).

Sorry if I am a little upset and apologise if I did understand something wrong.

BR,
Nikolaus



More information about the Gta04-owner mailing list