[Gta04-owner] We need an Android kernel

[Paul Kocialkowski]

Le mardi 16 juillet 2013 à 20:54 +0200, Dr. H. Nikolaus Schaller a
écrit :
> > * Using the Rowboat 2.6.37 kernel with gta04 board, defconfig and some
> > drivers on top
> > 
> > Suspend/resume pretty much works but there is a screen flickering issue
> > after resume, which I can't solve. This may be because of the lcd panel
> > driver that does not suspend/resume the panel properly or because of
> > omapdss suspend/resume. It does this with both PWM and GPIO backlight.
> 
> Flickering might also be some frame refresh clock not being restored correctly.

Yes indeed. Though I don't have the required equipment (not any
oscilloscope around) to check what is going on precisely.

> I think we should try to focus on the mainline kernels since we can't depend
> on a single company to support it. They may anytime decide to unplug
> development - like they did for OMAP4/5.

As far as I know, mainline is far from offering complete support for
DM37x, which is why there are so many platform-specific kernels out
there (such as rowboat). I guess they just don't have time to wait for
everything to be upstream and need to release the code early so that
they can sell devices without waiting and enable other to do so.
Moreover, some stuff will obviously never be uspstream, such as the
powervr drivers.

So that's the problem with upstream. Now the issue with the other way is
the one you're talking about: we shouldn't rely on TI or another company
to provide DM37x kernels. They seem to have dropped the idea long ago
anyway, as they decided not to add DM37x support to newer (than 2.6.37)
kernels. I think that's why we're stuck. Then maybe our best chances are
indeed taking a recent mainline (or close) kernel, that we can assume to
have gathered more and more DM37x features over time. Maybe 3.4 would be
a good fit since Android support is easy to integrate too.

> Since I also don't want to give up the idea of a really good Android/Replicant
> system for the GTA04, let's think a little about goals and coming back from the
> future.
> 
> I.e. we have to discuss and decide a strategy before starting to code.
> 
> First of all we (i.e. GTA04 business) needs the most modern kernel we
> can get. One that is maintained and close to the newest kernels, or we
> risk the problem that drivers will run out of sync and we need more and
> more time to maintain an ageing system. And users want to see the
> latest and greatest...

My point is that users won't really care whether they have 3.0, 3.4 or
3.10 as long as the kernel runs fine with the operating system and that
we merge stability/security fixes along with new versions.

> Let's draw some vision:
> 
> Going approx. 2 years into the future, Android 5.0 will use Linux 4.0
> and all required kernel features are mainline :) Then, we will simply
> have a single 4.0 kernel for Replicant, QtMoko, SHR, Debian, ...

That would be great, but I think we need a concrete solution that works
now (in the next few weeks) so that we can release images with decent
support and attract new users / customers for gta04.

> So coming back to fill the gap between now and this expectation (well,
> I know that open source projects hate to do the obvious :), I think
> we should focus to get as close as possible to the latest Android
> that is available (i.e. JB 4.3). Everything else is IMHO wasting efforts
> in view of the limited capacity we have.

The latest Android version is Jellybean 4.2 and the latest Replicant is
4.0. I will probably port all the currently-supported devices to 4.2 by
the end of August if there is nothing else to do, but frankly, I prefer
to add new features (hardware support) in 4.0 rather than porting the
devices to 4.2 with the same status (which is a big task).

Moreover, regarding the kernel, Jellybean 4.2 is known to work fine with
both 3.0 kernels from Ice Cream Sandwich 4.0 and 3.4 kernels that were
introduced with Jellybean 4.2. So I think if we get a working kernel for
Replicant 4.0, it'll be reusable for 4.2 and perhaps the next version
with very little work. I can handle moving the user-space from 4.0 to
4.2 without much trouble, though our biggest fear is the possibility of
using new versions of Android without the PowerVR blobs. We tricked 4.0
to deal with it and the result is fine, but we can't guarantee it'll be
the same on newer versions. So for now it's safer to keep going with 4.0
as this ensures that we'll be able to release usable images soon while
leading the path towards 4.2 and newer versions since most of the stuff
written for 4.0 is reusable in 4.2 and probably in newer versions with
vert little changes.

> If JB uses Linux 3.4 we are IMHO in a quite good situation since Neil Brown
> did start with Linux 3.4 to integrate the suspend/resume things to bring
> down power consumption:
> 
> http://git.neil.brown.name/?p=gta04.git;a=shortlog;h=refs/heads/3.4-gta04

I will start working on a 3.4 kernel in the next few days. I'll report
here about the issues I'm facing.

> On the other hand I researched that most special features of Android kernels
> (e.g. wakelocks) are either implemented in kernel driver modules or are
> already available in 3.7 and newer kernels. Maybe implemented in a different
> way or API than Google intended (the usual discussions when trying to
> upstream radically new features)...
> 
> So we still have to decide if we should do a "GTA04-3.7" + "android-features"
> or a "3.4-android" + "missing features like hardware adaptation"...

Basically as I said, the > 3.4 Android kernels are all marked as
experimental and nobody actually use them on devices, so it seems like a
really poor choice in terms of stability. It is also highly likely that
the Android-specific kernel interfaces were changed to comply with
mainline rules and thus that using them with 4.0 or 4.2 userspace will
draw compatibility issues.

> Since the goal should be to do the one with least efforts, much of this
> depends on how fast the Android kernel will come close to the Linux kernels
> in the future.
> 
> To come to a decision about this question, I think we should understand:
> 
> * how different are mainline-3.4 and android-3.4 kernels?

Basically, android-3.4 is the mainline 3.4 with android patches on top,
and they rebase the stability/security updates on top once in a while.
Though, the android patches don't add any particular omap-specific
features. There are TI Android kernels for 3.4 but they target omap4 so
we have very little interest in using them and it seems like they have
broken some omap3 support there and there (I remember trying one of
these on gta04, with terrible results).

> * what is the overall strategy of Google and Linux for this question?

The strategy of Android device manufacturers in general is that they
take the generic android kernel (say 3.4 for recent devices) and grab
platform-specific optimizations on top so that it works perfectly. 
Usually, when they upgrade to a new version (that requires a new kernel,
for instance when switching from Android 2.3 to Android 4.0), they start
over again with a more recent kernel and often rewrite big portions of
code in another way. Very clearly, they don't try to reuse the code they
wrote for older kernels, or just use it as reference.
Sometimes, they just refuse to upgrade to a new kernel version and let
the device sitting around with an old kernel, which makes Android
developers communities furious since they can't port the device to newer
Android versions anymore.
Google does the same for the Nexus line of Android phones.